Rogue network traffic on Windows XP64
July 4, 2011 12:47 AM Subscribe
How to find out why my computer is broadcasting SNMP traps and shut it down? Complicating factor, the absence of SNMP and my ignorance of Windows server environments.
In which I go far outside the limits of my technical knowledge: so, my workplace is a Windows shop. Not my choice, but when I arrived, an XP64 machine was dumped on my desk. I mainly just use it to connect through to the serious computing clusters or host virtual machines. Not a big Windows user, me.
The other day, IT calls up and tells me that they've traced poor network performance in my section back to my computer which is "flooding the local switch with SNMP traps".
IT: You gotta switch that off. It's creating real problems.
Me: I didn't set it up, This machine was delivered pre-configured. Where do I switch off ?
IT: Oh, it's somewhere in there. I'm not certified for that. But you gotta switch it off, kthxbye.
Cue a day of poring through settings, rebooting the computer, etc., to no avail. What makes it even more headscratching is that - according to the lists of installed Windows components and services - SNMP isn't even installed on this machine. I'd be inclined to think that IT made a mistake, except they identified other network activity (e.g. Dropbox) on my machine. So:
* How do I switch off SNMP on a Windows XP64 box? (A Fujitisu Celsius box if that makes a difference.)
* Failing that, is there a good tool for sniffing network traffic on my own machine? On MacOS, I'd use LittleSnitch. What's the Windows equivalent?
* Could some third party software I've installed (e.g. VirtualBox?) be broadcasting SNMP traps instead?
In which I go far outside the limits of my technical knowledge: so, my workplace is a Windows shop. Not my choice, but when I arrived, an XP64 machine was dumped on my desk. I mainly just use it to connect through to the serious computing clusters or host virtual machines. Not a big Windows user, me.
The other day, IT calls up and tells me that they've traced poor network performance in my section back to my computer which is "flooding the local switch with SNMP traps".
IT: You gotta switch that off. It's creating real problems.
Me: I didn't set it up, This machine was delivered pre-configured. Where do I switch off ?
IT: Oh, it's somewhere in there. I'm not certified for that. But you gotta switch it off, kthxbye.
Cue a day of poring through settings, rebooting the computer, etc., to no avail. What makes it even more headscratching is that - according to the lists of installed Windows components and services - SNMP isn't even installed on this machine. I'd be inclined to think that IT made a mistake, except they identified other network activity (e.g. Dropbox) on my machine. So:
* How do I switch off SNMP on a Windows XP64 box? (A Fujitisu Celsius box if that makes a difference.)
* Failing that, is there a good tool for sniffing network traffic on my own machine? On MacOS, I'd use LittleSnitch. What's the Windows equivalent?
* Could some third party software I've installed (e.g. VirtualBox?) be broadcasting SNMP traps instead?
Best answer: If SNMP isn't installed on the windows box, it's one of the VMs. Use Wireshark to help figure out which one.
posted by mhoye at 1:33 AM on July 4, 2011
posted by mhoye at 1:33 AM on July 4, 2011
Are they sure it's Traps and not Queries? What are you running in the VMs? One thing I've seen is CUPS printing on Linux/Mac is often setup to use broadcast SNMP queries for printer discovery (quite annoying actually). I don't think I've ever seen anything that sends Traps without configuration, but network device discovery and mapping programs tend to blast broadcast SNMP queries and/or do brute force scans of the whole shubnet.
posted by zengargoyle at 1:43 AM on July 4, 2011
posted by zengargoyle at 1:43 AM on July 4, 2011
Response by poster: Do the SNMP traps still get sent with all virtual machines turned off?
Apparently. I haven't used any VMs recently, but got the impression that the issue was based on current network traffic.
Wireshark
Boom. Knew there'd be something. Thanks.
Are they sure it's Traps and not Queries?
This is what was said, along with an assertion that my computer was "probably unconfigured". The VMs aren't / weren't running anything special, mainly a bunch of analysis software and some web services demos distributed as images.
posted by outlier at 1:50 AM on July 4, 2011
Apparently. I haven't used any VMs recently, but got the impression that the issue was based on current network traffic.
Wireshark
Boom. Knew there'd be something. Thanks.
Are they sure it's Traps and not Queries?
This is what was said, along with an assertion that my computer was "probably unconfigured". The VMs aren't / weren't running anything special, mainly a bunch of analysis software and some web services demos distributed as images.
posted by outlier at 1:50 AM on July 4, 2011
Best answer: If you want to bounce the ball back into their side of the court for a while, ask them what address your desktop is trapping to, and tell them that whoever is in charge of the SNMP manager on that box is probably responsible for this behaviour on your desktop, and hence responsible for turning it off. This is probably not true, but it's no more nonsensical than insisting you find and disable some random service on a box that was delivered pre-configured to your desk.
(SNMP usually involves the manager asking the agent "what's your foo status?" and getting a response "my foo status is bar". A trap is when the agent decides off its own bat to just alert the manager "my foo status is bar" without having received a query for that data.)
posted by russm at 6:48 AM on July 4, 2011 [1 favorite]
(SNMP usually involves the manager asking the agent "what's your foo status?" and getting a response "my foo status is bar". A trap is when the agent decides off its own bat to just alert the manager "my foo status is bar" without having received a query for that data.)
posted by russm at 6:48 AM on July 4, 2011 [1 favorite]
Best answer: If it was queries it wouldn't be killing the switch. Also: why have they just noticed this now? Has anything changed recently on your system?
Anyway, Wireshark will solve this problem real quick, just do a packet capture on your network interface, type snmp in the display filter and click apply. Going through the payloads will probably give you enough clues to track down whatever is sending traps, if that is in fact the problem.
You can also try running "netstat -anop UDP" from your command line. Look for something listening on port 161 (SNMP inbound). If you find something, that's probably the culprit. You can then find the PID in your task manager (View->Select Columns) and show that process who is boss around here. If it's something like snmp.exe... are you sure the SNMP service is not running? Look for it in services.msc
Alternatively, install a firewall that can block outbound connections and just block UDP port 162 out.
posted by tracert at 4:53 PM on July 4, 2011
Anyway, Wireshark will solve this problem real quick, just do a packet capture on your network interface, type snmp in the display filter and click apply. Going through the payloads will probably give you enough clues to track down whatever is sending traps, if that is in fact the problem.
You can also try running "netstat -anop UDP" from your command line. Look for something listening on port 161 (SNMP inbound). If you find something, that's probably the culprit. You can then find the PID in your task manager (View->Select Columns) and show that process who is boss around here. If it's something like snmp.exe... are you sure the SNMP service is not running? Look for it in services.msc
Alternatively, install a firewall that can block outbound connections and just block UDP port 162 out.
posted by tracert at 4:53 PM on July 4, 2011
SNMP Queries can cause problems with switches. They can be to broadcast address causing broadcast floods. They can also cause other network equipment to send Authentication failure traps when they are repeatably probed with the wrong community. Plain brute force scanning can cause CPU load issues on the switches when the destination address isn't known and has to be flooded to al ports across the fabric each time. Normally these would not be issues and considered normal network operations, but a bad/misconfigured application could be doing this continuously causing actual network problems.
My switches are configured to disable automatically hosts that cause excessive flooding type traffic. Network devices should be protected via ACLs to drop broadcast SNMP queries (how I found out about CUPS). I still disable hosts that continuously cause Authentication Failure traps via directed SNMP queries. YMMV.
posted by zengargoyle at 7:22 PM on July 4, 2011 [1 favorite]
My switches are configured to disable automatically hosts that cause excessive flooding type traffic. Network devices should be protected via ACLs to drop broadcast SNMP queries (how I found out about CUPS). I still disable hosts that continuously cause Authentication Failure traps via directed SNMP queries. YMMV.
posted by zengargoyle at 7:22 PM on July 4, 2011 [1 favorite]
Response by poster: If you want to bounce the ball back into their side of the court for a while, ask them what address your desktop is trapping to, and tell them that whoever is in charge of the SNMP manager on that box is probably responsible for this behaviour on your desktop, and hence responsible for turning it off. This is probably not true, but it's no more nonsensical than insisting you find and disable some random service on a box that was delivered pre-configured to your desk.
Brother, amen.
You can also try running "netstat -anop UDP" from your command line.
Huh - didn't know Windows had netstat. And there's nothing listening to port 161.
Update: not fully resolved as yet but explorations with Wireshark are interesting. I can't see any SNMP traffic. I can however see my - and several other peoples - Dropboxes pinging the network repeatedly. Apparently the recent versions of Dropbox have a "LAN sync" feature, where they are able to synchronise locally without the central Dropbox server. Switched that guy off.
Working theory - IT has misdiagnosed things. I'm going to leave it with them.
posted by outlier at 11:32 PM on July 4, 2011
Brother, amen.
You can also try running "netstat -anop UDP" from your command line.
Huh - didn't know Windows had netstat. And there's nothing listening to port 161.
Update: not fully resolved as yet but explorations with Wireshark are interesting. I can't see any SNMP traffic. I can however see my - and several other peoples - Dropboxes pinging the network repeatedly. Apparently the recent versions of Dropbox have a "LAN sync" feature, where they are able to synchronise locally without the central Dropbox server. Switched that guy off.
Working theory - IT has misdiagnosed things. I'm going to leave it with them.
posted by outlier at 11:32 PM on July 4, 2011
« Older Metafilter's 11 Secret Herbs and Spices | Where can I go to upload a lot of data quickly? Newer »
This thread is closed to new comments.
posted by robtoo at 1:25 AM on July 4, 2011 [1 favorite]