Profiling of persistent SSHD brute force attack

Proper setting up and regular monitoring of logs gives you the avenue to know what’s really happening with your box sitting out there in the internets, and to anticipate when bad things are about to happen.  One of the warning signs would be that someone has been poking around your box, looking for an (easy?) way in.

The natural thing that would jump out at you then, is that this someone has been accessing your box in far higher volumes/durations, especially on services that should not be accessed by others.

This is one example of such accesses on a linux box: SSHD brute forcing over long periods of time.

Added Layer Of Obscurity: Finding a non-standard port for your service

Designing your security model using only obscurity is always a bad idea, but after sound measures have been put in place, an added layer of obscurity might make the service/account harder to find for the malicious, and lower the resources wasted by their brute forcing, etc.

An example would be the changing of private services (e.g. SSH) to run on non-standard ports (I see this frequently recommended as part of hardening guides anyway; there’s port knocking too which could be even better, but that’s not the point of this post).

In the example of hiding SSH ports, the question then comes: what port to use? One of the many ways is to make use of nmap’s frequently used ports list to help make a decision.  Nmap scans using the top 1000 frequently used ports in a normal scan (although we change the scan to scan based on any top n used ports too).  So we run this in a shell to list the top 1000 (or n of your fancy) used ports:

cat /usr/share/nmap/nmap-services | 
awk '{print $3 "t" $2 "tt" $1}' | 
sort -nr | head -n1000 | less

 
Let’s break this command down:

cat /usr/share/nmap/nmap-services prints out the contents of the nmap-services file (used to track the probabilities of the ports used) to STDOUT.

awk ‘{print $3 “t” $2 “tt” $1}’ formats the contents of the nmap-services for the sort command to work on.

sort -nr sorts the entries by reverse numerical order.

head -n1000 shows only the top 1000 lines of output (change to any number you wish, or remove altogether to see the full list)

less displays the output in a scrollable, searchable manner.

On an ending note, it probably would be a bad idea to go straight for the last entries in the sorted list for your port selections.  Remember: we want to be unpredictable, and not simply different.

Visualizing sshd brute-force attempts (part 2)

It’s always better to Read The Fine Manual (or run perl afterglow.pl -h for the more updated helpfile)…though it’s not really that well documented 😛  Afterglow allows for two column inputs, rather than us having to do weird tricks to make them 3-column.

(Note to self: get the raw data with fields in the order that you want where possible/faster, rather than pumping it through sed.  Makes for good practice though.)

Using the csv file containing userids (visualized in yellow) and IPs (visualized in green) over the past few months from Splunk, here’re the results of some of the experiments.

Oh, for the Windows users, you can use type instead of cat 😉

First test using GraphViz’s neato to layout:

perl afterglow.pl -b 1 -i <infile> -c color.properties -t | neato -Tgif -o output.gif

Huge, but better visualized with -e 5 option (Resulting image for that is too huge to upload though :P). Note the single IP in the middle (the yellow explosion) that had been trying a LOT of userids to date.

Second test using fdp:

perl afterglow.pl -b 1 -i <infile> -c color.properties -t | fdp -Tgif -o output.gif

fdp doesn't seem to be well suited for this

Third test using sfdp:

No command here, you should have noticed the pattern from the first two…

_even_ less suited for this type of data...

Last test using twopi:

According to the GraphViz site, twopi’s more suited for visualizing stuff like telecommunications flows.

twopi