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
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.
On Mon, Feb 21, 2011, Stephen Harris wrote:
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.
That makes sense, and was one of the first things I thought of.
On the other hand "lsof -n -i" doesn't show any open connections to the IP address, and I would think that the forwarding and null route would prevent that.
Bill
-
Bill Campbell -
Stephen Harris