F2B inserts just about all rules at the top of whichever chain it is
using. The exceptionis the RETURN rule at the end of each jail chain
and this rule is redundant so I have removed it. RETURN is the
default action of any custom chain.
I personally think f2b should be reloaded at the end of each
firewall restart to guarantee that its rules are at or near the top
on the INPUT chain. Things like IPS will insert above it but that
does not matter.
Nick
On 30/09/2015 20:46, Harrison Johnson
wrote:
Christian,
Iptables has several tables and each table can have several
chains. When a packet hits the interface it is sent to one of the
tables for example NAT for network address translation or FILTER
for packet filtering. The filter table has the INPUT, FORWARD
& OUTPUT chains predefined and these chains can have a default
policy ACCEPT, DENY or DROP are the most common so when a packet
gets to the end of a chain and it has not matched a rule the
default policy is applied to the packet.
You or an application like Fail2ban can define a new chain and
and rules for that chain, but user defined rules can't have a
default policy. When fail2ban starts it adds a new chain to the
filter table and a new rule to the INPUT chain that "jumps" to the
new chain. When it bans an IP it adds a new rule to the new chain
to block packets from that IP, pretty straight forward stuff.
Where you put the new jump rule is very important, if you put it
after a rule that allows the packet, then Iptables will never
block that packet because it has already been processed. A packet
is only processed for each chain.
if my rules set is:
-A INPUT -j ACCEPT
-A INPUT -j blacklist
and I add an IP to the blacklist with:
-A blacklist -s 70.32.128.0/19 -j DROP
That packet will never be dropped because it matches the INPUT -j
ACCEPT before we get to the -j blacklist rule.
But if my rule set is:
-A INPUT -j blacklist
-A INPUT -j ACCEPT
Then every packet will be checked by the blacklist chain,
additionally if the last rule in the blacklist chain is -j RETURN
then the second rule will also be checked, otherwise the packet
falls off the end of the chain blacklist and the default policy
for the INPUT chain is applied.
Now I don't know how Fail2ban decides which line to put the new
jump rule in at. I would hazard a guess that during install it
greps your rule set looking for something like ".*-j ACCEPT" and
then writes the conf files in the action.d directory with the line
"actionstart = iptables -I <chain> X -p <protocol> -j
f2b-<name>" with X set to 1 less than the line number for
the ACCEPT rule that it found, but that is just a guess on my
part. It maybe that the action files are all set to insert the new
rule at line number 9. But you can go into the action files and
change the line number to match your rules. If other rules are
added or removed and you don't adjust the insert position then
when Fail2ban starts it will be putting the rule in the wrong
place and may not be blocking the offender. I have also had an
issue where sqlite was causing problems and Fail2ban just kept
adding the jump rule. I think at one point before I disabled the
database I had 17,000 lines in my rules. To make it easy for
Fail2ban and to block bad packets as quickly as possible. My
first rule is "iptables -A INPUT -j blacklist", this is a list of
ip's that I maintain myself then I changed the all the files in
the /etc/fail2ban/action.d/ conf files to "iptales -I INPUT 2 -j
f2b-<name>". This way all packets that I consider bad based
on past behavior are dropped before they have a chance to sneak
in. I hope this helps you out some.
------------------------------------------------------------------------------
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
|
------------------------------------------------------------------------------
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
