October 2008 Archives

Brute Force attacks, Part 2

| No TrackBacks

Yesterday's article, Blocking brute force attacks, helped me put a great dent in attacks here, but also caused a bit of an inconvenience. Using IPTABLES to block such attacks has the inherent drawback of using the same restriction on both successful and failed connections, and the main system I check mail on here logs into quite a few separate mail accounts locally, all requiring a separate connection, so my default filter had to allow for a rather high number of incoming connections before any could be blocked. Enter the whitelist...

Additional reading online found a number of very similar articles, again all centered around SSH attacks to the router, not a separate system behind the router. After a few rounds of testing, I finally found the trick that would work here, the completed snipped of code is below, refer to yesterday's article for a more complete firewall.user file.

The greatest challenge was in determining exactly how to whitelist internal traffic. When such traffic is logged by my servers, the connection appears to be coming from outside, so my natural assumption was to whitelist the external IP. That just didn't work. Changing the code to whitelist my internal network did the trick, a streamlined version follows. This code may likely only be necessary for mail accounts, other types of connections are not as likely to have a high number of repeat connections for valid users, internally or externally.

iptables -N pop-whitelist
iptables -A pop-whitelist -s $network -m recent --remove --name POP -j ACCEPT

iptables -A forwarding_rule -p tcp --dport 110 -m state --state NEW -m recent --set --name POP
iptables -A forwarding_rule -p tcp --dport 110 -m state --state NEW -j pop-whitelist
iptables -A forwarding_rule -p tcp --dport 110 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name POP -j DROP

Blocking brute force attacks

| No TrackBacks

This one has had me baffled for a while. From time to time in my logs, I'd see repeated attempts by an unknown IP to connect to one of the services here, usually trying to log into the mail server via a POP account. Normally I'd simply update the /etc/firewall.user file to drop connections from that IP, and not worry about it, but I knew there had to be a way to stop such attacks in their tracks...

About this Archive

This page is an archive of entries from October 2008 listed from newest to oldest.

August 2008 is the previous archive.

November 2008 is the next archive.

Find recent content on the main index or look in the archives to find all content.



Powered by Movable Type 5.031