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!
Without having access to a box that was compromised it's hard to tell since the attacker could hide his tracks.
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?
While it's a good idea to move ssh to a different port, if only to stop the annoying doorknob rattling in your log files, you should not pick an ssh port over 1024. Ports over 1024 are unprivileged ports, and if someone could somehow convince your ssh server to die, they could start up a counterfeit one and collect your password. A port under 1024 requires root access to be able to open it.
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.
> 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.
I had my internal monitoring system on a network I managed set up with port knocking. It ended up being more hassle than I thought it was worth, as it wasn't a box that was getting attacked much anyway.
It's really pretty easy to set up with iptables in Linux.
Lots of people seem to recommend port knocking still today, but I personally won't use it as I'd hate to get behind a firewall (e.g. hotel, airport, university) where I can't send the right sequence of knocks for whatever reason (outbound ports firewalled).
I set it up a few months ago and ended up disabling it after a few weeks due to this reason. All my SSH servers have password authentication disabled and a strict AllowUsers list, anyways.
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.
Analyze the firmware. If it doesn't pass a checksum, it could be compromised. If the software doesn't pass a checksum, it's compromised. Strange traffic coming out of the router is a bad sign. If the router is running analysis on your packet, you will likely experience diminished throughput on the high end because of limited resources on the router.
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.
Another "defense in depth" step would be to move your router off of 192.168.1.1. I recall seeing some browse-to-evil-webpage based attacks a while ago, and if the evil webpage can't guess your router IP (and it's not like it has access to your TCP settings in general) that can't work.
Obviously, just like moving SSH off of 22, this isn't a real defense, but it'll make it that much harder.
Firmware would not necessarily be modified in an attack like this, and this method would detect any persistent changes you make that are written back to NVRAM.
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.
Depends on the compromise, but generally speaking the observable difference in behavior (assuming you are unable to monitor upstream of the router) is very minor. Greater power drain, and evidence of compromised information being used that could only have been gained from that source.
