I decided to use Nmap, Wireshark, and tcpdump to help identify what changes needed to be made to the filter. I could have taken several approaches to re-establish connectivity. Many mistakes were made that allowed this failure to occur in the first place. This troubleshooting opportunity arose from a real situation I faced as an administrator. The analyst made multiple changes until they became frustrated and sent me an email saying, "I don't know what is wrong.
The analyst did not back up the original filter configuration and kept no record of the changes.
The analyst decided there was a problem with the router's filter and began making changes. I was the only administrator in the company, and as luck would have it, I'd taken the day off. The rules were ad hoc and not in a terribly logical order, and the relevant application communicated between the client and server using non-standard ports. A router with strict packet filtering rules sat between the two segments. In my role, I inherited this environment and was told to accept the fact that non-administrators had administrative privileges.Ī client device sat on one internal segment, and a database server resided on another. Unfortunately, this individual did not have a solid understanding of these devices or their services, such as firewalls and packet filters, logs, or routing. In this scenario, a business analyst had administrative privileges on all network devices (routers, switches, servers, and clients).
At the very least, it can wreak havoc with steering filters on some NICs. On a physical NIC, this can be VERY expensive and may involve bouncing the link (behind your back) and dropping packets.
However, one of the worst things that tcpdump does is to put the NIC into promisc mode.
0 kommentar(er)
