Interesting idea. Reading through the threads it becomes apparent that the attackers are targeting home wired/wifi routers. The attacker sits on your gateway and passively monitors your traffic with you being none the wiser!
For this case specifically, if you're running openwrt you could try 'ps aux|grep syslgd' and see if you find anything. Then use 'lsof -p PID#' to see what files it's using. Or use 'lsof -i' to see what software has open connections. This can be very telling. Maybe 'netstat -anp| and looks for syslogd connecting out to the internet.
You should really follow basic security best practices and disable sshd on the outside interfaces, firewall unknown address, and switch sshd to a different port (security through obscurity will prevent the mass drive by port scanning).
Big ups for this -- since moving SSH to port 8022 I get zero bruteforce attacks. Even blacklisting tools like fail2ban can't get that kind of result. Of course it can't be the only defense, but I've always configured my SSH daemons to be key login only (no passwords). Moving SSH just cuts down on the CPU cycles burned at rejecting drone scans.
Every time I come across posts like this I consider maybe setting up a honeypot but I'm not sure what I'd do with the results other than look over them every few months for my own amusement. Are there any honeypots that can automatically forward information about the attacks to a central location?
Of course, this only applies to linux systems where you don't trust local unprivileged users. Or software that you are running as an unprivileged user. So every system.
Good point, but
> they could start up a counterfeit one and collect your password.
you missed the part where I disable password logins on all of my boxes :-) The important point was that the system was already secure enough due to the key requirement, and moving the port was indeed just to stop the "doorknob rattling". If I suddenly find that a box I control is asking me for a password, I'm not going to just type my social security number in and hope for the best.
One could argue that using a port < 1024 makes it easier for the scanners to find, but frankly anything other than 22 (or a frequently scanned port) would work well enough.
It's really pretty easy to set up with iptables in Linux.
The only thing I do externally from sshd is have a cronscript run every 15 seconds to grep my authlog file to find any IP addresses that fail authentication and put them in a global blacklist for my PF firewall. It cuts down the ssh authlog noise considerably, and rarely accidentally blacklists myself.
I think if you can go without enabling remote access to a router, then you should. This will protect the router itself from direct login attacks from the outside, but if somebody compromises a machine on your LAN, you're boned. If you can't, and you have security concerns, you need to establish metrics of verifying whether or not the router is behaving the same way it was when it came out of the box and (presumably) was not compromised. Like I mentioned, software/firmware checksums are a possibility (these could be hard, though...getting a router to dump its internals out probably isn't a feasible solution for everything), but YMMV depending on what you do and what you need your router to do. My biggest guess at the tell-tale sign of a compromised router is that it just starts slowing down.
Obviously, just like moving SSH off of 22, this isn't a real defense, but it'll make it that much harder.
Definitely wise to prevent remote login from outside your LAN though. Also you can always run an IDS like Snort on your router; a proper IDS is probably the cleanest solution to this problem.