Detecting automated penetration attempts (poor man's IDS)

Michael Jarvis michael at jarvis.com
Thu Dec 18 16:16:03 UTC 2014


On Wed, Dec 17, 2014 at 05:00:34PM -0600, Matthew Wedgwood wrote:
> Here are a couple pitfalls:
>
>    - Users behind NAT (that is, with the same IP address) can get lumped
>    together and be blocked. Small/medium businesses often have this sort of
>    network setup. Depending on the intended audience for your services, that
>    might lock out real customers.
>    - For SMTP and web traffic, the variability in connection rate can make
>    it hard to choose a sensible value. Most browsers only make two
>    simultaneous connections to a given server (as determined by hostname), but
>    there's no rule. Mail clients can vary wildly from a single simultaneous
>    connection to one per message sent.
>
> That said, it's quite common to protect administrative (low-traffic)
> interfaces (like SSH) using fail2ban. I'm not sure how intelligent/tunable
> fail2ban is with regard to other type of services.


You make some good points, Matthew.

For my purposes, this would be for low-volume, non-commercial
purposes. I have no problem blocking everyone behind a NAT router, but
I agree this wouldn't make sense in a high-transaction commercial
environment.

What would nice would be to have fail2ban (or my home-grown scripts)
perform some analysis and then automate notifying the provider
responsible for the IP address using their "abuse" contact info.

Essentially you'd take the IP address, do a whois query to find the
abuse contact(s) for the handles, and then send an email with relevant
log file information and timestamps, and hope that they handle it.

That sort of thing is tedious to do manually, but it's really more
effective than just blocking the traffic, IMHO. I've done this
manually in the past, and I've noticed mixed responses. Some providers
are ethical and appreciate the notice, and shut down the offending
customer. Some are not, and you'll find yourself suddenly receiving
spam email from your sending email address. :-P

>From looking at the documentation, I think fail2ban can do some of
this, and if not, it wouldn't be hard to implement. The toughest part
would be testing the email functionality and ensuring that you don't
get into mail loops and get flagged as a spammer.


Thanks for the feedback, everyone!
Michael


--
Michael Jarvis <michael at jarvis.com>
McKinney, TX USA
http://www.jarvis.com/



More information about the Ubuntu-us-tx mailing list