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.
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.
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”.
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.
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.
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.
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).
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???