Clearly, script kiddies are scanning and jamming with brute force. If they had done any footprinting, they would not be trying to log in as admin or ubnt.

We are using the -P option and a simple regex to catch lines with IPv4 addresses. It's worth noting this will also grab valid login lines from your own access if you are connecting over IPv4.

So that's what our lines look like, then we add the -o option to grep so we can output just the IPv4 address of matching lines. We also add the -h option to suppress the filename, so we don't count any source that spans log files more than once. Next, we pipe into the classic UNIX idiom sort |uniq -c to sort all lines (just IPv4 addresses at this point), and pull unique entries, with a count for each (uniq -c). The sort -n is an artifact of me looking as I was building the output interactively, and sorts IPv4 addreses by the number of lines (attempts). I wanted to see where the bulk of these requests originated.

This is what things look like so far. I added a |tail so we can see the top offenders from the interactive output:

I'm probably never going to log in from Korea. If I ever find myself in Korea, it's likely I would be using a VPN anyway, so I feel pretty comfortable with blocking the range of this attacker. We'll get to that part later.

Lastly, we pipe to another UNIX classic awk '{sum +=$1 ; count ++} END {print sum, count}'. Here, awk is generating a sum of attempts based on the first field (sum), and incrementing a counter (count) once for each line while reading the input. The END block prints the values of the sum and count variables, giving us the final count of attempts over IPv4 and unique IPv4 addresses.

The fix for this is very simple; Restrict access to instances from limited IP ranges using Security Groups. By looking at valid logins in the output of the last command and a trivial amount of additional parsing of /var/log/secure*, it is very easy to find the ranges I actually use to legitimately access this instance. I actually already knew these ranges, since they are present in other security groups, but that's a good way to find them if you need to tune up your security by paring down access. Once you specify the legitimate ranges for your SSH access in your Security Groups, other ranges are blocked implicitly, including all of the attackers we found through parsing /var/log/secure* in this example.

After cutting down the range for ssh access to this same instance, some time and a log rotation, the output of the command at the beginning of this post is now empty.