Detecting automated penetration attempts (poor man's IDS)

[Lee Sharp]

On 12/17/2014 10:41 AM, Michael Jarvis wrote:
> Quick question for the group:
>
> Let's assume you have some public-facing Linux servers, providing web and mail and SSH access.
>
> Your servers are getting probed with automated tools on a regular basis. This is a fact for any Internet-connected server.
>
> Let's assume you have appropriate security measures in place. These probes are an irritating nuisance, not a serious threat.
>
> However, let's assume that your servers are running in a cloud-based VPS environment, and you want to reduce unnecessary CPU/bandwidth utilization as an efficiency measure. You're not worried about the probe, per se, you just don't want the same idiot to keep patiently banging away at your server, trying a brute-force dictionary attack against SMTP authentication, for example.
>
> One way to block attackers would be to use a script to parse various log files, and when you see probes, add a null route to the IP address in question. The null route would last until the next reboot, and future connection attempts from the attacker would time out when they don't receive TCP responses.
>
> - What pitfalls do you see to this null route solution, for a relatively low-traffic server?
>
> - What would be YOUR solution?
>
> - Is anyone aware of any open source projects out there that specifically address this issue? A full-blown IDS like Snort seems like overkill, IMHO.

I would think fail2ban would help first.  Extend the 3 minutes to 
something significantly longer, however.  But for distributed attacks, 
you need some horsepower.  Security Onion is a fantastic IDS, but it is 
VERY resource hungry.

			Lee