Re: fail2ban for apache2
On Sunday 10 November 2019 14:37:58 Brian wrote:
> On Sun 10 Nov 2019 at 10:26:17 -0800, Kushal Kumaran wrote:
> > Brian <ad44@cityscape.co.uk> writes:
> > > On Sun 10 Nov 2019 at 11:01:07 +0100, Michael wrote:
> > >> On Saturday, November 9, 2019 7:01:00 PM CET, Gene Heskett wrote:
> > >> > I was able, with the help of another responder to carve up some
> > >> > iptables rules to stop the DDOS that semrush, yandex, bingbot,
> > >> > and 2 or 3 others were bound to do to me.
> > >>
> > >> using iptables directly is fine, because you get your results
> > >> fast, but it lacks some advantages over fail2ban, which i think
> > >> outweigh the simplicity of iptables:
> > >> - whith iptables you have to scan your log regularly for
> > >> misbehaving or unwanted clients, whereas fail2ban does this
> > >> automatically, constantly (!), and based on rules. from time to
> > >> time these rules have to be adapted, since bots are evolving, but
> > >> i think it's still less trouble than looking at log files every
> > >> day or so.
> > >> - fail2ban allows you to block only specific ports, in your case
> > >> maybe 80 and/or 443 for the web server.
> > >> - you have to remember which ip address you blocked, why and for
> > >> how long you want to block them. fail2ban does that for you.
> > >> - ... (too lazy right now to write more)
> > >
> > > This accords with my understanding of failtoban with exim. I use
> > > it to keep the logs clean and it is very effective. Offenders are
> > > banned for a year, although I do wonder sometimes whether this
> > > length of time is a little over the top. I also wonder whether, as
> > > the banned list builds up, there is a noticable affect on the
> > > machine's resources.
> >
> > Probably. But you have to balance that against the resources
> > required if you let the connection through to exim (or whatever
> > service you're protecting). iptables (even with a few hundred
> > rules) is likely to be more efficient than exim.
>
> Thank you for that, Kushal. I see your point. It is indeed efficiency,
> not security, I am after.
>
> > One thing you could try is to examine the iptables rule counters
> > daily/weekly. If the counters do not increase during some interval,
> > then the rule is no longer useful to you, so you could delete it.
> > This should be fairly straightforward to automate, but I don't know
> > if someone has already built this tooling.
>
> I hardly use iptables, so this is the first I have heard about rule
> counters. I'll work something out to accomodate it.
This is something I've been looking at/for, is something that can take this report. And something that has not had a hit in say a month,
should be removed.
#> iptables -L -nv --line-numbers
Chain INPUT (policy ACCEPT 2785K packets, 28G bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all -- * * 73.229.203.175 0.0.0.0/0
2 0 0 DROP all -- * * 77.88.5.200 0.0.0.0/0
3 0 0 DROP all -- * * 66.249.64.226 0.0.0.0/0
4 0 0 DROP all -- * * 40.77.167.82 0.0.0.0/0
5 0 0 DROP all -- * * 111.225.149.199 0.0.0.0/0
6 0 0 DROP all -- * * 40.77.167.142 0.0.0.0/0
7 4 240 DROP all -- * * 220.243.136.25 0.0.0.0/0
8 424 25440 DROP all -- * * 46.229.168.146 0.0.0.0/0
9 3 180 DROP all -- * * 141.8.143.160 0.0.0.0/0
10 4 240 DROP all -- * * 111.225.148.159 0.0.0.0/0
11 72 4320 DROP all -- * * 46.229.168.134 0.0.0.0/0
12 32 1920 DROP all -- * * 46.229.168.137 0.0.0.0/0
13 4 240 DROP all -- * * 111.225.148.49 0.0.0.0/0
14 0 0 DROP all -- * * 220.243.136.54 0.0.0.0/0
15 0 0 DROP all -- * * 110.249.202.57 0.0.0.0/0
16 740 44400 DROP all -- * * 111.225.149.0/24 0.0.0.0/0
17 711 42660 DROP all -- * * 110.249.201.0/24 0.0.0.0/0
18 658 39480 DROP all -- * * 110.249.202.0/24 0.0.0.0/0
19 608 36480 DROP all -- * * 111.225.148.0/24 0.0.0.0/0
20 552 33120 DROP all -- * * 46.229.168.0/24 0.0.0.0/0
21 78 3744 DROP all -- * * 157.55.39.0/24 0.0.0.0/0
22 178 10680 DROP all -- * * 220.243.135.0/24 0.0.0.0/0
23 530 32044 DROP all -- * * 109.95.253.0/24 0.0.0.0/0
This collection is over less than a week, but looks as if the first 6 could be
dropped, but I'd do this monthly in case they have a weekly new ip
that some like bingbot, yandex, and semrush are using now, along with bytespider.
The log that caused that to be generated was started at the same time
I reinstalled apache2 and started applying iptables rules to block the
jerks, is now 376211 entries long.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: