I recently helped upgrade a customer's Watchguard Firebox II to a Firebox III (their choice, not mine). Both have switches on them which allow you to block (IIRC) "Address-space probes" and "Port-space probes", which after some testing I figured out meant portscans. The II model used to block me when I'd scan one machine with default nmap settings, after it got through about 1/4 of the scan. The new one would let me scan 4 or so boxes, all possible ports (ie, -p 1-), before it blocked me. Running a default scan I could get a dozen.
So I called to complain that this fancy new box actually took longer to detect a portscan. After getting the runaround for a while about how the III was "newer" and had "more features" and it "wasn't fair to compare this one feature" I finally got a straight answer. The reply was (paraphrasing a bit)
"The problem is the Firebox III has more memory, so it can see more connections. This is why it takes longer to see a portscan"
First time I've ever been told I had too much hardware. I was tempted to tell him to send someone out to install less memory.;-)
I won't list any other tools I use, as they've all been mentioned lots of times, but I will add to the list tethereal, which is the command-line version of ethereal.
Two very important general notes about analyzing the network, though. First you should know at least somewhat what your network looks like under normal circumstances. I can't tell you how many times I've beeen at a new organization looking at the network for strangeness and seen a long list of errors that some net admin saw and said "yeah, that's a misconfigured m$ box, haven't fixed it yet...yeah, that's a broken printer...yeah...". It helps if you know this stuff ahead of time.
Second, switching's a pain when it comes to network sniffing. The best tool in the world can't help you if the packet never gets to you. Make sure you know the layout of the network in question very well before you try looking for problems, and make sure you're either tapping as necessary or in the right spot to monitor. There are a number of tools that can just jump on a random switched port and sniff, but they often use dicey methods for dealing with the switch (arp poisoning, flooding, etc.) that you don't necessarily want to mess with if you're already having network issues. And if you're not, arp-flooding a switch or poisoning one of your production servers is a great way to cause some!;-)
I'll end with the obligatory war-story in response to a post I read that said (paraphrasing) "What would you need this kind of analysis for?" I had to troubleshoot a weird network problem that seemed to be network-wide (in this case, 3 buildings, total of about 30 switches; not too large). Symptoms were that a host would fail to start talking to another host about 1/2 the time, but once it did start, it was fine (for a while). Turns out that there was a busted switche that was bit-flipping and mangling the MAC address in the response. Thing was, we were using HP's with meshing turned on (I hate this feature; much prefer good old spanning-tee and, if you need, trunking) which black-box combines multiple uplinks between switches so you *NEVER* know what path a piece of data is taking. Hence, the only erroring out about 1/2 the time and working once it did go through (arp cache), and hence us having a real hard time figuring out which was the broken switch.
Ethereal was my friend that day. Had to run it in multiple spots though to see the arp change.
This is the case now, but it is changing as many linux distros are making themselves more accessible to the end-user and/or more desktop-friendly. Heck, you can download a fully-functional Linux distro like Knoppix or any of the many others, all of which work very well as desktop environments and many of which would be comfortable to M$ users. Indeed, working at a University as I do, I already see more and more students using Linux on the desktop, and that's encouraging. University environments can sometimes portend future technology trends and I'm hoping this will hold true here.
However, this means that more and more the "average" user may be getting put onto Linux. And it won't be long, then, before I think we do start seeing Sobig-like fun in Linux. This will be furthered as well when, as was stated somewhere in this thread, Linux gets used more and is therefore a useful platform for making a "big splash" via mass-infection.
Slashdot Mirror
So I called to complain that this fancy new box actually took longer to detect a portscan. After getting the runaround for a while about how the III was "newer" and had "more features" and it "wasn't fair to compare this one feature" I finally got a straight answer. The reply was (paraphrasing a bit)First time I've ever been told I had too much hardware. I was tempted to tell him to send someone out to install less memory.
I won't list any other tools I use, as they've all been mentioned lots of times, but I will add to the list tethereal, which is the command-line version of ethereal.
;-)
Two very important general notes about analyzing the network, though. First you should know at least somewhat what your network looks like under normal circumstances. I can't tell you how many times I've beeen at a new organization looking at the network for strangeness and seen a long list of errors that some net admin saw and said "yeah, that's a misconfigured m$ box, haven't fixed it yet...yeah, that's a broken printer...yeah...". It helps if you know this stuff ahead of time.
Second, switching's a pain when it comes to network sniffing. The best tool in the world can't help you if the packet never gets to you. Make sure you know the layout of the network in question very well before you try looking for problems, and make sure you're either tapping as necessary or in the right spot to monitor. There are a number of tools that can just jump on a random switched port and sniff, but they often use dicey methods for dealing with the switch (arp poisoning, flooding, etc.) that you don't necessarily want to mess with if you're already having network issues. And if you're not, arp-flooding a switch or poisoning one of your production servers is a great way to cause some!
I'll end with the obligatory war-story in response to a post I read that said (paraphrasing) "What would you need this kind of analysis for?" I had to troubleshoot a weird network problem that seemed to be network-wide (in this case, 3 buildings, total of about 30 switches; not too large). Symptoms were that a host would fail to start talking to another host about 1/2 the time, but once it did start, it was fine (for a while). Turns out that there was a busted switche that was bit-flipping and mangling the MAC address in the response. Thing was, we were using HP's with meshing turned on (I hate this feature; much prefer good old spanning-tee and, if you need, trunking) which black-box combines multiple uplinks between switches so you *NEVER* know what path a piece of data is taking. Hence, the only erroring out about 1/2 the time and working once it did go through (arp cache), and hence us having a real hard time figuring out which was the broken switch.
Ethereal was my friend that day. Had to run it in multiple spots though to see the arp change.
This is the case now, but it is changing as many linux distros are making themselves more accessible to the end-user and/or more desktop-friendly. Heck, you can download a fully-functional Linux distro like Knoppix or any of the many others, all of which work very well as desktop environments and many of which would be comfortable to M$ users. Indeed, working at a University as I do, I already see more and more students using Linux on the desktop, and that's encouraging. University environments can sometimes portend future technology trends and I'm hoping this will hold true here. However, this means that more and more the "average" user may be getting put onto Linux. And it won't be long, then, before I think we do start seeing Sobig-like fun in Linux. This will be furthered as well when, as was stated somewhere in this thread, Linux gets used more and is therefore a useful platform for making a "big splash" via mass-infection.