We use a home-brew system similar to fail2ban to block traffic from IP addresses which appear to be doing Nasty Things(tm). The main thing our system does that fail2ban doesn't is to use a central DNSRBL we maintain allowing it to immedatiately ban listed IP addresses the first time they make an attempt to connection without waiting for them to hit a sufficient number of times to bring up the block. This system sends e-mail messages to our security alias whenever a blocking even occurs, either from tcp_wrappers or swatch log watcher. My problem is that occassionally an IP addresses doesn't appear to be blocked as we continue to see the e-mail messages after the blocks are in place. Most frequently these occur from courier-imap failed login attempts, less frequently from sshd. To start, iptables is initialized by setting up a named rule set, say on eth0: # these two set up the rule set. iptables -N csblocks iptables -A csblocks -j RETURN # now add it to input, check csblocks on all new connections. iptables -i eth0 -m state --state NEW -j csblocks #Insert block IP address 1.2.3.4 as first rule in the set. iptables -I csblocks 1 -s 1.2.3.4 -j DROP # now add a rule to prevent IP forwarding on gateway machines. iptables -A FORWARD -s 1.2.3.4 -j DROP # for good measure, null route the IP route add -host 1.2.3.4 reject With all that incoming attempts still seem to get by for a few IP addresses, but certainly not all. Can anybody point out what I'm doing wrong, or why this may happen? Bill -- INTERNET: bill at celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792 An almost hysterical antagonism toward the gold standard is one issue which unites statists of all persuasions. They seem to sense that gold and economic freedom are inseparable. -- Alan Greenspan
On Mon, Feb 21, 2011 at 03:32:40PM -0800, Bill Campbell wrote:> My problem is that occassionally an IP addresses doesn't appear to be > blocked as we continue to see the e-mail messages after the blocks are in > place. Most frequently these occur from courier-imap failed login > attempts, less frequently from sshd. > > To start, iptables is initialized by setting up a named rule set, > say on eth0: > > # these two set up the rule set. > iptables -N csblocks > iptables -A csblocks -j RETURN > > # now add it to input, check csblocks on all new connections. > iptables -i eth0 -m state --state NEW -j csblocks> With all that incoming attempts still seem to get by for a few IP > addresses, but certainly not all. > > Can anybody point out what I'm doing wrong, or why this may happen?Connections that are already established may be blocked but traffic will continue to flow because you're only blocking on "NEW" traffic. eg <connection made> login fail login fail login fail <BLOCK HAPPENS - perhaps it's the 5th set of connections and it's just tripped the threshold> login fail login fail login fail <too many failed attempts, disconnected by server daemon> <new connection blocked> You'll see 3 login failures after the block occured because the connection was still open. -- rgds Stephen