Responding to a Brute Force SSH Attack

by Jamie Riden

It was a bad start to a Monday morning: I arrived at work to find the intrusion detection system so bogged down in alerts that it was barely responsive.

Something bad had happened over the weekend. The IDS — in this case, a couple of snort sensors logging to a postgresql database — had been extremely busy logging alerts over pretty much the whole weekend. To review the alerts, I used the BASE front-end, and it was this latter that was taking such a long time to tell me anything, since it was querying a database which was around ten times as large as I had originally envisaged using in production.

A few minutes digging in the BASE console suggested that most of the 200,000 alerts had been generated by the potential SSH scan rule from Bleeding Threats. Since the usual daily load was nearer 20,000 alerts, it was a fair guess that a lot of malicious activity had been going on over the weekend. The snort rules that were firing were mainly the latter out of the two shown below, but this would depend on the location of your snort sensor and how you have $HOME_NET and $EXTERNAL_NET defined.  Read More

This entry was posted in IT Compliance, Security Awareness. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *