The only problem I ever had with it was when sqlite crashed, it just add
the jumps to the input chain each time it restarted. At one point it was
restarting about 170 times an hour. I was out on a call and that went on
for 9 or 10 hours I had thousands of jumps for each jail in the INPUT
chain. I thought about changing Fail2ban to use Postgresql but instead I
just disabled the database and write the bans into text files. I set the
action files to insert the jump at line 2 so now the blacklist jump is
line 1 and fail2ban start on 2 like this:
-A INPUT -j blacklist
-A INPUT -p tcp -m multiport --dports
22,443,80,25,110,143,3128,11443 -j f2b-fail2bancluster
-A INPUT -j f2b-pam-root
-A INPUT -j f2b-supermax
-A INPUT -p tcp -m multiport --dports 5432 -j f2b-postgresql
-A INPUT -p tcp -m multiport --dports 5800,5900 -j f2b-vncserver
-A INPUT -p tcp -j f2b-recidive
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
then at the end of the INPUT chain these rules
-A INPUT -p tcp -m multiport --dports <...> -j ACCEPT
-A INPUT -p udp -m multiport --dports <...> -j ACCEPT
allow in anything not filtered by the previous rules and matching the
listed ports. Everything else gets dropped by the default policy on the
input chain. I have only one network interface and don't run any VM's so
my default FORWARD policy it DROP. I did modify the actions files to
read bans from the text files when Fail2ban starts. But now I just let
Fail2ban parse the log files for ssh, vnc & postgres. I do read in the
text files for pam-root, supermax & recidive.
This works well for me but I also don't run any public servers and
consider all inbound traffic that is not me to be an attack attempt so
my tolerance is pretty low. 2 failed attempts over 3 hours for ssh, vnc
& postgres gets the ip banned from the port for 13 minutes. 5 failed
attempts against any of those over 3 days get a IP banned from all ports
for a week. 8 fails in 13 days gets the IP banned forever. Any attempt
to log in root via ssh gets banned forever. The iptables-life.conf file
used by pam-root & supermax has the un-ban action set to "/usr/bin/true"
so at expire time Fail2ban states the IP is unbanned but the offender is
not removed from the chain.
On Wed, 2015-09-30 at 21:20 +0100, Nick Howitt wrote:
> 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
