PureOS scanning network for SNMP enabled devices

I put PureOS on my laptop a while ago and have discovered that it is scanning networks I’m connected to for SNMP enabled devices. I’ve found this because one of the places I go to has things locked down in a way that we get alerts when “an unauthorized user attempting to access the SNMP interface from (my IP)”.

Why would PureOS be doing this and what service do I need to disable to stop this? I disabled CUPS thinking it might be scanning for printers but that doesn’t appear to be it and I haven’t been able to see anything on port 161/162 via netstat but if there’s a better way to catch this I’m all ears.

Thank you!

I’m unfamiliar with anything in PureOS that will scan for SNMP devices aside from CUPS. A ‘man cups-snmp’ says;

The CUPS SNMP backend provides legacy discovery and identification of network printers using SNMPv1. When used for discovery through the scheduler, the backend will list all printers that respond to a broadcast SNMPv1 query with the “public” community name. Additional queries are then sent to printers that respond in order to determine the correct device URI, make and model, and other information needed for printing.

You can look at the /etc/cups/snmp.conf file to determine the community name and see if that is what has been scanning.

1 Like

I’ll see if maybe the alerts I got after stopping the cups service were delayed. Unfortunately I won’t know for certain until next week whether this was the only service doing this or not.

Thank you for the feedback.

If the package that is sending SNMP stuff is one that you really do want to have installed because it provides otherwise useful functionality (be it CUPS or something else), you could look at using an IP filtering capability (firewall) to drop the SNMP packets. Network administrator happy. You happy.

If it is CUPS then you can perhaps edit /etc/cups/snmp.conf and change the address to 127.0.0.1

You might have to work a bit harder if you want CUPS to use SNMP when you are at “home” but not when you are “on site”.

2 Likes

SNMP.conf has:

Address @LOCAL
Community public

I’m guessing @LOCAL is the local network and not localhost?

Unfortunately the more interesting thing is I have CUPS stopped and my laptop is still scanning SNMP devices so I believe there is another service doing this…

Any other ideas?

I believe that the following is the way (may be a bit hardcore for the ordinary user…) to troubleshoot and identify the party-breaker:

  1. open a TTY (e.g. Ctrl+Alt+F2) and start a tcpdump(1) capture for SNMP packets (something like “tcpdump -i any port snmp”).
  2. Check that you see SNMP packets in the dump.
  3. Log out from the graphical interface to minimize the number of processes running.
  4. Check that SNMP packets are still being captured by tcpdump (or not? If not - look for the process in the desktop session).
  5. Shut down system services one by one and look for the one after which SNMP packets will stop appearing in the network dump.

This should point you to the process which sends these packets.

2 Likes

So with this I’ve found that whatever it is runs about every hour and 20 minutes though it’s not that precise. Waiting between 1 and 2 hours per test is kind of brutal. Adding a -v to the end of that tcpdump command doesn’t appear to be very useful, unless the number part of computer-name.##### portion of the output happens to be the process if? (If so how can I see historical process ID’s because I didn’t see that process ID show up when this last occurred).

I also built a quick script that constantly runs netstat -anlpt | grep :161 >file.log however that appears to have not seen the last occurrence…

And even if that see’s the occurrence I’ll still need a way to see historical process ID’s.

At least with this method I can keep troubleshooting while not at this customer so that will hopefully net a solution sooner. Thank you very much for that.

Can confirm it is 100% not CUPS. I needed to add a network printer and that broadcast to my.subnet.255.255

Whereas the unknown service is broadcasting to 255.255.255.255

Progress I guess…

SNMP may be using UDP, not TCP, so you would want to replace -t with -u (or capture both, in two separate, concurrent commands).

2 Likes

On my machine I can see that the process cups-browserd broadcasts to 0.0.0.0 on all ports;

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
udp        0      0 0.0.0.0:631             0.0.0.0:*                           29307/cups-browsed 

I used this command to find it (thanks to @kieran)

netstat -anlpu

1 Like

Changing the command does look to be a good thing. When I go to browse for a network printer I see 36995/SNMP gets created during that scan.

I’m pretty sure the 0.0.0.0:port are the services listening not outbound. Though I could be wrong. I’m going to let this run every second and see if it can catch when the unknown SNMP broadcast happens. Hopefully this will finally let me know what’s doing this broadcast so I can kill it.

Thank you all for the insight and assistance.

In general, lsof -p <pid> works well to see what files (including network handles) a process has open. You can also do something like lsof | grep smtp to see what processes are using standard smtp ports. Of course, if it is intermitent activity, catching it could be a challenge, but there are solutions for that.

3 Likes

PS As I understand it, -a and -l are contradictory.

-a : show all sockets, whether LISTEN sockets (server sockets bound in order to accept incoming connections) or normal sockets (accepted incoming connections, or outgoing connections)

-l : show only LISTEN sockets

default if neither is specified : show only normal sockets

So if you are flailing about trying to track down some rogue send, you probably want -a and not -l (particularly as LISTEN really only makes sense for TCP, not UDP).

In case it helps, I had my laptop set up all day yesterday with tcpdump to show any SNMP packets and there were 0 packets - and that’s with CUPS installed and with /etc/cups/snmp.conf with factory default content (@LOCAL).

1 Like

Well after spending all day with TCP dump listening for UDP traffic, that it was seeing yesterday (but I missed with netstat), it saw nothing today… I’m starting to suspect that some other network device at the client site is doing something to cause my laptop to respond with an SNMP broadcast???

It might be odd to respond with a broadcast but I am not familiar with the details of SNMP.

Responding at all could definitely happen if you have attached printers (for example) but that seems a bit unlikely. ??

If you can capture any SNMP traffic then it should be possible to decode it (for some protocols tcpdump will do that for you) and then get more insight into who sent what and why.

1 Like

You might try a tool like snmpwalk as well.

1 Like