== Large scale Internet SSH brute force attacks seem to have stopped here The last time I paid attention to what happened when you exposed an SSH port on the Internet was years and years ago, when I gave up being annoyed by log messages and either stopped paying attention or firewalled of my SSH ports from the general Internet. Back then, it was received wisdom (and my general experience) that having an SSH port open drew a constant stream of SSH brute force attacks against a revolving cast of whatever logins the attackers could come up with. Recently I set up a [[Grafana Loki https://grafana.com/oss/loki/]] setup that [[captures our systemd logs GrafanaLokiAvoidingJSON]]. As part of getting some use out of it ([[beyond questions about how server clocks drift GrafanaLokiNtpdateQueries]]), I built a Grafana dashboard that reports on SSH authentication failures across our Ubuntu fleet (among other things). What I saw surprised me, because what our exposed SSH servers experience today seems to be nothing like it was in the past. (One caution is that it may be that most attackers no longer direct their attention against universities at all, and now aim their scans at, say, cloud providers, which could be much richer territory for insecure SSH servers.) For the most part, SSH brute force attacks against [[us https://support.cs.toronto.edu/]] are gone. When they appear in some time period, they come in high volume from single IP addresses (or only a few IP addresses); some of the time these are cloud server IPs. Almost all of the brute force attacks are directed against the '_root_' account, and any single round tends to be directed against only a single one of our servers rather than being spread over multiple ones. As mentioned, attacks are bursty; there are periods with no login attempts and then periods where someone apparently fires up a single attacking IP address for an hour or a day. For some numbers, over the past 7 days we had 24,000 attempts against '_root_' and only 749 against the next most popular target, which is a login name ('_admin_') that doesn't even exist here. Just over 10,000 of those attempts came from a single IP address, and just four IPs made 1,000 or more attempts against anything. Besides _root_, only five login names had more than 100 attempts (and none of them exist here): 'admin', 'user', 'ubuntu', 'debian', and 'pi'. And only three machines saw more than 1,000 attempts (across all targeted login names). One of the things I've learned from this is that targeted blocking of only a few IPs is disproportionately effective at stopping brute force SSH attacks here. Also, since we already block Internet logins to '_root_', we're in almost no danger. No matter how many times they try, they have literally no chance of success. (It does make me curious about what sort of passwords they're trying for '_root_'. But not curious enough to set up a honeypot SSH server and then try to give it a hostname that's interesting enough to attract attackers.)