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