On 18/Apr/10 18:44, Jan Engelhardt wrote:
On Sunday 2010-04-18 15:46, Alessandro Vesely wrote:
actionban = iptables -I fail2ban-<name> 1 -s<ip> -j DROP
actionunban = iptables -D fail2ban-<name> -s<ip> -j DROP
I don't know whether fail2ban uses some other storage to remember frequently banned IPs.
If you are using iptables for actionban, it would not need to.
Right, but rather than deleting by number, it uses the same IP to
issue the unban command. If the IP is remembered even after unbanning
it, then it is possible to increase its next ban-period, in case it is
caught again.
How would you compare iptables and netfilter?
Like you compare a tree with soil?
Yeah, my question was short, but not formally sound...
I heard about some not better characterized performance degradation
that would occur when successively issuing a huge number of "iptables
-I" commands. How huge is "huge"? Where is this topic expounded?
I mean fail2ban actions versus looking up a b-tree file,
Where does that btree file come from, and what should it be useful for?
A b-tree can be used to store IPs: One has to remember them, at least
for some time, one way or another, if different IPs are to be treated
differently. One can use an "at" command for unbanning, and avoid
structured storage. Alternatively, one could use ipset, e.g. iptrees
with timeouts. As yet another alternative, one can use netfilter and
user-space storage. I mentioned b-trees because I use Berkeley DB with
the my netfilter daemon. MySQL or anything similar offer similar
functionality and performance.
When I started to use my daemon, I was afraid that accessing the disk
on each packet would have been a bottleneck. So, I only filtered new
connections. Later on, I added a rule to filter all packets, in order
to also terminate existing connections. Two rules, actually: a
netfilter rule to set a mark and another one to reject those packets, i.e.
iptables -t raw -A OUTPUT -p tcp ! --syn -m multiport --sports $X \
-j NFQUEUE --queue-num 4
iptables -A OUTPUT -p tcp ! --syn -m mark --mark 4 \
-j REJECT --reject-with tcp-reset
(For udp and --syn connections, a single netfilter rule is enough.)
The time taken for issuing verdicts used to be much less than that for
parsing the log file. The former has jumped to about the double of the
latter, after those additional two rules. Perhaps, I should have stuck
to using netfilter for new connections only. Existing connections can
be terminated with short-lived iptables rules, or by calling
nids_killtcp() or "ngrep -K" directly. In hindsight, that looks fairly
obvious. However, the above quoted fail2ban's actions don't seem to be
concerned with such kind of optimizations. Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
