Steffen Dettmer wrote:
> I encountered multiple times that debian based containers use fail2ban by
> default with a max attempt value of 5, even for SSH logins using strong
> asymmetric keys.
There is no "debian based container" standard. Talk to whoever
built your container.
Hi,
I encountered multiple times that debian based containers use fail2ban by
default with a max attempt value of 5, even for SSH logins using strong
asymmetric keys.
(Again I just got locked out for 1h (fortunately a container, so I can
access anyway). Do you know what happened? My SSH key
On 20 May 2024 07:00 -0400, from d...@randomstring.org (Dan Ritter):
>> # fail2ban-server -V
>>
>> 0.11.2
>
> Bullseye became stable in August of 2021.
It's also perhaps worth noting that there seem to have been only two
interim releases.
https://github.com/fai
Maurizio Caloro wrote:
> Hello
>
> Please why on Debian Bullseye, 11.9 is a pretty old version available in the
> repository?
>
> # fail2ban-server -V
>
> 0.11.2
Bullseye became stable in August of 2021.
"Stable" means that packages don't change
Hello
Please why on Debian Bullseye, 11.9 is a pretty old version available in the
repository?
# fail2ban-server -V
0.11.2
I think this application arnt a big thing?
Available on github, Version 1.1.0
On Debian 10 and 11 hosts the e-mail logwatch generates has section like
this:
- fail2ban-messages Begin
Banned services with Fail2Ban: Bans:Unbans
postfix-sasl: [ 3:3
On Fri, 15 Mar 2024 14:59:49 - (UTC)
Curt wrote:
> I guess it's this old bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171
Yup, thank you. I added the following stanza to
/etc/fail2ban/jail.d/curley.conf:
[sshd]
backend = systemd
(The "enabled" pai
I have fail2ban working for sshd on Bookworm. My jail.local file looks like
this:
[sshd]
bantime = 2d
enabled = true
mode = extra
port =
filter = sshd[mode=aggressive]
backend = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd
maxretry = 1
findtime = 300
On 2024-03-14, Charles Curley wrote:
> I'm trying to set fail2ban up on bookworm. It refuses to run with the
> default configuration (sshd only), reporting:
I guess it's this old bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770171
> Failed during configuration: Hav
On Thu, 14 Mar 2024 22:27:36 +
Andy Smith wrote:
> I think you want to set "backend = journald" in
> /etc/fail2ban/jail.conf or its usual local override, but I have not
> tested this as I still use rsyslogd.
Thanks, but no cigar. I also tried setting backend to syste
Hi,
On Thu, Mar 14, 2024 at 04:01:54PM -0600, Charles Curley wrote:
> I'm trying to set fail2ban up on bookworm. It refuses to run with the
> default configuration (sshd only), reporting:
>
> Failed during configuration: Have not found any log file for sshd jail
I think you wan
I'm trying to set fail2ban up on bookworm. It refuses to run with the
default configuration (sshd only), reporting:
Failed during configuration: Have not found any log file for sshd jail
Near as I can figure, fail2ban expects sshd's log file to be
/var/log/auth.log. Which does not e
As already reported, when it's blocked, all traffic is blocked on IPv4,
including SSH & HTTP.
Le sam. 9 sept. 2023 à 06:42, Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> a écrit :
>
>
> On Fri, Sep 8, 2023 at 10:52 PM Max Nikulin wrote:
>
>> On 08/09/2023 04:39, Romain wrote:
>> > I c
On Fri, Sep 8, 2023 at 10:52 PM Max Nikulin wrote:
> On 08/09/2023 04:39, Romain wrote:
> > I can confirm that when this happens, it's the OVH server that fails to
> > send the response to my network.
> >
> > 35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping)
> > request id=0
On 08/09/2023 04:39, Romain wrote:
I can confirm that when this happens, it's the OVH server that fails to
send the response to my network.
35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping)
request id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 → MY_PUBLIC_
I'm able to reproduce.
I can confirm that when this happens, it's the OVH server that fails to
send the response to my network.
35 9.862648672 MY_PUBLIC_IP_AT_HOME → 54.38.38.159 ICMP 78 Echo (ping)
request id=0x4b30, seq=33150/32385, ttl=1
36 9.862704895 54.38.38.159 → MY_PUBLIC_IP_AT_HOME IC
I'll write my answer here as well, as the OP posted the same posts on
debian-french (also top-posting ...).
Some ISPs or service providers may use private IPs (RFC1918) or even
APIPA for their internal routers, to spare public IPs.
CG-NAT (which uses APIPAs) especially may create some weird pr
On 07/09/2023 17:32, Andy Smith wrote:
On Thu, Sep 07, 2023 at 12:20:18PM +0200, Romain wrote:
With -n (sometimes it stops at hop 7, sometimes 9):
└─# mtr -nr 54.38.38.159 -4
Start: 2023-09-07T08:17:12+
HOST: rpi4Loss% Snt Last Avg Best Wrst StDev
^^
Hello,
On Thu, Sep 07, 2023 at 12:20:18PM +0200, Romain wrote:
> With -n (sometimes it stops at hop 7, sometimes 9):
> └─# mtr -nr 54.38.38.159 -4
> Start: 2023-09-07T08:17:12+
> HOST: rpi4Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 192.168.0.10
No, I'm using the DNS server included in my ISP modem, in which I can only
select the last digits. It's impossible that an internal device has
received a public IP address in the DNS zone (or it's not something I've
done).
With -n (sometimes it stops at hop 7, sometimes 9):
└─# mtr -nr 54.38.38.15
On 07/09/2023 14:31, Romain wrote:
12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955.
0.0
May it happen that you associated a local device with the IP of your
remote server? Check configuration of the .home DNS zone. Try to add -n
option to suppress DNS lookup and comp
I can reproduce with OVH IPs, but not with Scaleway IPs. I smell filtering
on the OVH side.
Le jeu. 7 sept. 2023 à 09:48, Paul van der Vlis a
écrit :
> Op 06-09-2023 om 15:40 schreef Romain:
> > Next time it happens I'll run more tests from the server to my home.
> > I'm wondering if my modem at
Op 06-09-2023 om 15:40 schreef Romain:
Next time it happens I'll run more tests from the server to my home.
I'm wondering if my modem at home could not be the culprit. I'm prepared
for more tests here too.
If you have switches at home, those could be the problem too.
You could let log iptable
e of writing)
>
> Issues:
> - The OVH Debian 12 template for dedicated servers doesn't come with any
> pre-installed blocking tools (e.g., no fail2ban).
> - I haven't added any such tools since installing the server, only Apache
> (with mod_security), PHP, and MariaDB.
> - Fr
Next time it happens I'll run more tests from the server to my home.
I'm wondering if my modem at home could not be the culprit. I'm prepared
for more tests here too.
But yes I'm sure I don't have any rules on the server:
# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source
On Wed, Sep 06, 2023 at 10:59:29AM +0200, Romain wrote:
> >
> > So when this is happening mtr works but http, ssh and ping don't?
>
> Yes
I think there is definitely a firewall involved somewhere as that is
quite complicated selective blocking: it's allowing back the ICMP
Time Exceeded packets th
/443 from your home, how far
> does it get?
Will test it next time it's blocked.
Are there any firewall rules in place on your server?
No (no fail2ban, ...).
DO you have access to any other host so you can tell if it is just
> your home IP that has problems?
Yes, I have multiple se
Hi,
On Wed, Sep 06, 2023 at 08:39:55AM +0200, Romain wrote:
> When my IP is blocked, curl returns a "Connection refused," and ping
> returns "Destination Port Unreachable."
>
> I couldn't find any mentions of my IPv4 address in the server logs. MTR
> (-4) doesn't report any issues reaching the se
No but's this is what I plan to do next time :)
Le mer. 6 sept. 2023 à 10:41, Michel Verdier a écrit :
> On 2023-09-06, Romain wrote:
>
> > I couldn't find any mentions of my IPv4 address in the server logs. MTR
> > (-4) doesn't report any issues reaching the server.
>
> Did you run mtr from the
On 2023-09-06, Romain wrote:
> I couldn't find any mentions of my IPv4 address in the server logs. MTR
> (-4) doesn't report any issues reaching the server.
Did you run mtr from the both sides ?
e with any
pre-installed blocking tools (e.g., no fail2ban).
- I haven't added any such tools since installing the server, only Apache
(with mod_security), PHP, and MariaDB.
- From my home IP address last night, the only generated requests were from
my Uptime Kuma probe, which includes a ping eve
Martin McCormick wrote:
> I was attempting to setup a systemd timer and checking the syntax of
> that when I ran across a complaint from the fail2ban program which is
> a bit confusing. It reads:
> /lib/systemd/system/fail2ban.service:12: PIDFile= references path below
> legacy
Martin McCormick writes:
/lib/systemd/system/fail2ban.service:12: PIDFile= references path below
legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid →
/run/fail2ban/fail2ban.pid; please update the unit file accordingly.
So I looked in to that file and the actual
I was attempting to setup a systemd timer and checking the syntax
of that when I ran across a complaint from the fail2ban program
which is a bit confusing. It reads:
/lib/systemd/system/fail2ban.service:12: PIDFile= references path below legacy
directory /var/run/, updating /var/run/fail2ban
On Monday 02 December 2019 07:46:22 Alessandro Vesely wrote:
> On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote:
> > You might want to install iptables-persistent, otherwise you'll have
> > to roll-out your own solution.
>
> I'm not using iptables-persistent, but just looked at it out of
> c
Gene Heskett wrote:
> It, iptables, did not get restarted on the fresh boot, so obviously the
> systemd manager hasn't been informed to start iptables, reloading
> from /etc/iptables/saved-rules.
You would not be having these problems were you using Shorewall...
--
John Hasler
jhas...@newsguy
On Mon, Dec 02, 2019 at 01:46:22PM +0100, Alessandro Vesely wrote:
> ### BEGIN INIT INFO
> # Provides: netfilter-persistent
> # Required-Start:mountkernfs $remote_fs
> # Required-Stop: $remote_fs
> # Default-Start: S
> # Default-Stop: 0 1 6
> # Short-Description: Load boot
On Mon, Dec 02, 2019 at 01:46:22PM +0100, Alessandro Vesely wrote:
> On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote:
> >
> > You might want to install iptables-persistent, otherwise you'll have to
> > roll-out your own solution.
>
> I'm not using iptables-persistent, but just looked at i
On Mon 02/Dec/2019 10:35:26 +0100 Andrei POPESCU wrote:
>
> You might want to install iptables-persistent, otherwise you'll have to
> roll-out your own solution.
I'm not using iptables-persistent, but just looked at it out of curiosity.
Its LSB:
### BEGIN INIT INFO
# Provides: netfil
On Monday 02 December 2019 04:35:26 Andrei POPESCU wrote:
> On Du, 01 dec 19, 22:28:43, Gene Heskett wrote:
> > It, iptables, did not get restarted on the fresh boot, so obviously
> > the systemd manager hasn't been informed to start iptables,
> > reloading from /etc/iptables/saved-rules.
>
> To
On Du, 01 dec 19, 22:28:43, Gene Heskett wrote:
>
> It, iptables, did not get restarted on the fresh boot, so obviously the
> systemd manager hasn't been informed to start iptables, reloading
> from /etc/iptables/saved-rules.
To my knowledge Debian doesn't include anything like this by defau
On Tuesday 12 November 2019 21:35:49 Gene Heskett wrote:
> On Tuesday 12 November 2019 19:53:15 John Hasler wrote:
> > I wrote:
> > > Install Shorewall.
> >
> > Gene writes:
> > > Did, spent half an hour reading its man page, but I don't see a
> > > command that will extract and save an existing i
On Tuesday 12 November 2019 20:03:12 ghe wrote:
> On 11/12/19 5:46 PM, Gene Heskett wrote:
> > Oh goody and I get to name & pick the file and its location. Now,
> > wheres a good place to put the restore in the reboot path?
>
> How about /etc? Or /etc/init.d? That's where mine is...
I've already
On Tuesday 12 November 2019 19:53:15 John Hasler wrote:
> I wrote:
> > Install Shorewall.
>
> Gene writes:
> > Did, spent half an hour reading its man page, but I don't see a
> > command that will extract and save an existing iptables setup, and a
> > later reapply of that saved data.
>
> I meant
On 11/12/19 5:46 PM, Gene Heskett wrote:
> Oh goody and I get to name & pick the file and its location. Now, wheres
> a good place to put the restore in the reboot path?
How about /etc? Or /etc/init.d? That's where mine is...
--
Glenn English
I wrote:
> Install Shorewall.
Gene writes:
> Did, spent half an hour reading its man page, but I don't see a
> command that will extract and save an existing iptables setup, and a
> later reapply of that saved data.
I meant use it instead of using Iptables directly: the package takes
care of rest
On Tuesday 12 November 2019 16:04:07 to...@tuxteam.de wrote:
> On Tue, Nov 12, 2019 at 12:40:45PM -0500, Gene Heskett wrote:
>
> [...]
>
> > So I have to find all that in the history and re-invent
> > a 33 line filter DROP. I'll be baqck when I've stuck a hot tater in
> > semrushes exit port.
>
>
On Tuesday 12 November 2019 14:28:38 John Hasler wrote:
> Gene writes:
> > So I had been adding iptables rules but had to reboot this morning
> > to get a baseline cups start, only to find my iptables rules were
> > all gone and the bots are DDOSing me again.
>
> Install Shorewall.
Did, spent hal
On Tuesday 12 November 2019 13:30:24 ghe wrote:
> Gene wrote
>
> > So I had been adding iptables rules but had to reboot this
> > morning to get a baseline cups start, only to find my iptables rules
> > were all gone and the bots are DDOSing me again. Grrr
>
> 0) Can you block them with an ACL
On Tue, Nov 12, 2019 at 12:40:45PM -0500, Gene Heskett wrote:
[...]
> So I have to find all that in the history and re-invent
> a 33 line filter DROP. I'll be baqck when I've stuck a hot tater in
> semrushes exit port.
See iptables-save (will dump the currently active iptables to a file)
and ip
Gene writes:
> So I had been adding iptables rules but had to reboot this morning to
> get a baseline cups start, only to find my iptables rules were all
> gone and the bots are DDOSing me again.
Install Shorewall.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
Gene wrote
> So I had been adding iptables rules but had to reboot this
> morning to get a baseline cups start, only to find my iptables rules
> were all gone and the bots are DDOSing me again. Grrr
0) Can you block them with an ACL in your router/firewall? And wr mem so
the ACL will be the
On Tuesday 12 November 2019 11:01:08 Lee wrote:
> On 11/11/19, Gene Heskett wrote:
> > On Monday 11 November 2019 08:33:13 Greg Wooledge wrote:
>
> ... snip ...
>
> >> I *know* I told you to look at your log files, and to turn on
> >> user-agent logging if necessary.
> >>
> >> I don't remember
On 11/11/19, Gene Heskett wrote:
> On Monday 11 November 2019 08:33:13 Greg Wooledge wrote:
... snip ...
>> I *know* I told you to look at your log files, and to turn on
>> user-agent logging if necessary.
>>
>> I don't remember seeing you ever *post* your log files here, not even
>> a single li
On 11/11/19, Greg Wooledge wrote:
> On Mon, Nov 11, 2019 at 12:18:17PM -0500, Gene Heskett wrote:
>>
>> HTTP/1.1" 200 554724 "-" "Mozilla/5.0 (compatible; Daum/4.1;
>> +http://cs.daum.net/faq/15/4118.html?faqId=28966)"
>> coyote.coyote.den:80 203.133.169.54 - -
>> [11/Nov/2019:12:11:29 -0500] "GET
Sorry Gene. Hit reply instead of reply list.
On 11/11/19 12:18 PM, Gene Heskett wrote:
On Monday 11 November 2019 08:33:13 Greg Wooledge wrote:
I have a list of ipv4's I want fail2ban to block.
Not sure that fail2ban is the best tool for the job. Where you
already have a list of IPs
On Monday 11 November 2019 12:38:09 Greg Wooledge wrote:
> On Mon, Nov 11, 2019 at 12:18:17PM -0500, Gene Heskett wrote:
> > Only one log file seems to have useful data, the "other..." file,
> > and I have posted several single lines here, but here's a few more:
> >
> > coyote.coyote.den:80 40.94
On Mon, Nov 11, 2019 at 12:18:17PM -0500, Gene Heskett wrote:
> Only one log file seems to have useful data, the "other..." file, and I
> have posted several single lines here, but here's a few more:
>
> coyote.coyote.den:80 40.94.105.9 - -
> [11/Nov/2019:12:08:53 -0500] "GET /gene/ HTTP/1.1" 2
On Monday 11 November 2019 08:33:13 Greg Wooledge wrote:
> > > > I have a list of ipv4's I want fail2ban to block.
> > >
> > > Not sure that fail2ban is the best tool for the job. Where you
> > > already have a list of IPs that you want to block why
On Mon, Nov 11, 2019 at 02:52:36PM +0100, to...@tuxteam.de wrote:
> On Mon, Nov 11, 2019 at 08:33:13AM -0500, Greg Wooledge wrote:
> > > > > I have a list of ipv4's I want fail2ban to block.
>
> [...]
>
> > I don't remember seeing you ever *post* your
On Mon, Nov 11, 2019 at 08:33:13AM -0500, Greg Wooledge wrote:
> > > > I have a list of ipv4's I want fail2ban to block.
[...]
> I don't remember seeing you ever *post* your log files here, not even
> a single line from a single instance of this bot. Maybe I miss
> > > I have a list of ipv4's I want fail2ban to block.
> >
> > Not sure that fail2ban is the best tool for the job. Where you already
> > have a list of IPs that you want to block why not just directly create
> > the iptables rules?
>
> just did that,
On Sun, Nov 10, 2019 at 06:07:37PM -0500, Gene Heskett wrote:
> On Sunday 10 November 2019 16:07:22 to...@tuxteam.de wrote:
>
> > On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote:
> > > On Sunday 10 November 2019 08:02:46 Michael wrote:
> > >
> > > Which contains such gems as this:
> >
On Monday, November 11, 2019 12:07:37 AM CET, Gene Heskett wrote:
On Sunday 10 November 2019 16:07:22 to...@tuxteam.de wrote:
On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote: ...
I don't see an obvious field delimiter in this. Tomas. Is it definable?
like thomas told you earlier
On Sun, 2019-11-10 at 19:37 +, Brian wrote:
> On Sun 10 Nov 2019 at 10:26:17 -0800, Kushal Kumaran wrote:
> [...]
> > 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 usef
On Sunday 10 November 2019 18:07:37 Gene Heskett wrote:
> On Sunday 10 November 2019 16:07:22 to...@tuxteam.de wrote:
> > On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote:
> > > On Sunday 10 November 2019 08:02:46 Michael wrote:
> > >
> > > Which contains such gems as this:
> > > coyot
On Sunday 10 November 2019 16:07:22 to...@tuxteam.de wrote:
> On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote:
> > On Sunday 10 November 2019 08:02:46 Michael wrote:
> >
> > Which contains such gems as this:
> > coyote.coyote.den:80 40.77.167.79 - -
> > [10/Nov/2019:10:44:45 -0500] "G
> >> > 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 i
On Sun, Nov 10, 2019 at 10:55:03AM -0500, Gene Heskett wrote:
> On Sunday 10 November 2019 08:02:46 Michael wrote:
> Which contains such gems as this:
> coyote.coyote.den:80 40.77.167.79 - -
> [10/Nov/2019:10:44:45 -0500] "GET /gene/fence/18.html HTTP/1.1" 200
> 1121 "-" "Mozilla/5.0 (iPhone; CP
p 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
> &
On 11/10/19 8:55 AM, Gene Heskett wrote:
> Thats an approximate idea of my understanding how it works, but to
> gradually transit from manual reading of the logs and applying iptable
> rules to block the miscreants, the first step would seem to indicate
> training fail2ban to read
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
un, Nov 10, 2019 at 06:08:52AM -0500, Gene Heskett wrote:
> >
> > But... you can just configure your Apache to deny that user agent
> > itself. One less moving part (fail2ban) with all its configuration
> > joy.
>
> and, i think it's worth mentioning, the apache2
Apache to deny that user agent
itself. One less moving part (fail2ban) with all its configuration
joy.
and, i think it's worth mentioning, the apache2 config denies the request
__before__ it sends any data, whereas fail2ban has to wait until __after__
apache2 has finished handling the re
t; > 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
> un
trigger [...]
Bingo. You can let fail2ban pick up the UA off the log, block that
source IP.
But... you can just configure your Apache to deny that user agent
itself. One less moving part (fail2ban) with all its configuration
joy.
Fail2ban would come in whenever the traffic generated by the (n
On Sunday 10 November 2019 06:19:51 to...@tuxteam.de wrote:
> On Sun, Nov 10, 2019 at 06:08:52AM -0500, Gene Heskett wrote:
>
> [...]
>
> > But, I'm getting the impression that it has to fail before fail2ban
> > kicks in [...]
>
> No. It has to "succeed&quo
On Sun, Nov 10, 2019 at 06:08:52AM -0500, Gene Heskett wrote:
[...]
> But, I'm getting the impression that it has to fail before fail2ban kicks
> in [...]
No. It has to "succeed" once before fail2ban can do its job. It is:
- assess client behaviour
- http server writes
gt;
> no idea what you're talking about... i almost never read any tutorial,
> just man pages. that's what i think they're here for (althuogh i have
> to admit the quality varies a lot!).
>
> so, a jail is just a name for a set of blocking rules, filters and
>
ial, just
man pages. that's what i think they're here for (althuogh i have to admit
the quality varies a lot!).
so, a jail is just a name for a set of blocking rules, filters and actions.
- the rule (a file in /etc/fail2ban/jail.d/, e.g. genes-apache.conf)
describes what should be blocked
On Saturday 09 November 2019 15:07:51 mick crane wrote:
> On 2019-11-09 18:01, Gene Heskett wrote:
> > On Saturday 09 November 2019 08:59:14 Michael wrote:
> >> > Rather then to use fail2ban for this, I would create un ipset
> >> > that fail2ban can populat
On Sat 09 Nov 2019 at 20:07:51 +, mick crane wrote:
> I like Gene, he is trying to make something work.
The "something" is what is at issue.
> When all this stuff started there seemed to be some sort of logic to it and
> I can't say I understood much of it but the thing seems to be now that
On 2019-11-09 18:01, Gene Heskett wrote:
On Saturday 09 November 2019 08:59:14 Michael wrote:
> Rather then to use fail2ban for this, I would create un ipset that
> fail2ban can populate then use that ipset in iptables.
i agree, but:
> One advantage of this is that you can add/delet
Hello,
On Sat, Nov 09, 2019 at 01:34:11PM -0500, Gene Heskett wrote:
> On Saturday 09 November 2019 10:10:53 Andy Smith wrote:
> > You've repeatedly been advised to block these bots in Apache by
> > their UserAgent. Have you tried that yet? It would be a lot simpler
> >
On Saturday 09 November 2019 10:37:09 john doe wrote:
> On 11/9/2019 2:43 PM, Gene Heskett wrote:
> > On Saturday 09 November 2019 03:36:49 john doe wrote:
> >> On 11/9/2019 8:30 AM, Gene Heskett wrote:
> >>> I have a list of ipv4's I want fail2ban to block. But
t; > extremely determined and has switched to a 4th address I've not seen
> > before, but is no longer DDOSing my site.
>
> You've repeatedly been advised to block these bots in Apache by
> their UserAgent. Have you tried that yet? It would be a lot simpler
> than fa
On Saturday 09 November 2019 08:59:14 Michael wrote:
> > Rather then to use fail2ban for this, I would create un ipset that
> > fail2ban can populate then use that ipset in iptables.
>
> i agree, but:
> > One advantage of this is that you can add/delete ip from the ips
using, then if it is not enough, add fail2ban and iptables into the mix.
>
> --
> John Doe
>
>
--
“The cradle rocks above an abyss, and common sense tells us that our existence
is but a brief crack of light between two eternities of darkness.”
"Speak, Memory," Vladimir Nabokov
On 11/9/2019 2:43 PM, Gene Heskett wrote:
> On Saturday 09 November 2019 03:36:49 john doe wrote:
>
>> On 11/9/2019 8:30 AM, Gene Heskett wrote:
>>> I have a list of ipv4's I want fail2ban to block. But amongst the
>>> numerous subdirs for fail2ban, I cannot find
efore, but
> is no longer DDOSing my site.
You've repeatedly been advised to block these bots in Apache by
their UserAgent. Have you tried that yet? It would be a lot simpler
than fail2ban or trying to keep up with their IP addresses.
Regards,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Rather then to use fail2ban for this, I would create un ipset that
fail2ban can populate then use that ipset in iptables.
i agree, but:
One advantage of this is that you can add/delete ip from the ipset
without having to restart fail2ban/iptables.
RTFM
fail2ban allows you to 'unban&#
On Saturday 09 November 2019 04:01:32 to...@tuxteam.de wrote:
> On Sat, Nov 09, 2019 at 03:36:49AM -0500, Gene Heskett wrote:
> > On Saturday 09 November 2019 02:49:16 mett wrote:
> > > On 2019年11月9日 16:30:57 JST, Gene Heskett
wrote:
> > > >I have a list of ipv4&#
On Saturday 09 November 2019 03:36:49 john doe wrote:
> On 11/9/2019 8:30 AM, Gene Heskett wrote:
> > I have a list of ipv4's I want fail2ban to block. But amongst the
> > numerous subdirs for fail2ban, I cannot find one that looks suitable
> > to put this list of addre
On Sat, Nov 09, 2019 at 03:36:49AM -0500, Gene Heskett wrote:
> On Saturday 09 November 2019 02:49:16 mett wrote:
>
> > On 2019年11月9日 16:30:57 JST, Gene Heskett wrote:
> > >I have a list of ipv4's I want fail2ban to block. But amongst the
> > >numerous subd
On 11/9/2019 8:30 AM, Gene Heskett wrote:
> I have a list of ipv4's I want fail2ban to block. But amongst the
> numerous subdirs for fail2ban, I cannot find one that looks suitable to
> put this list of addresses in so the are blocked forever. Can someone
> more familiar with h
On Saturday 09 November 2019 02:55:45 darb wrote:
> * Gene Heskett wrote:
> > I have a list of ipv4's I want fail2ban to block. But amongst the
> > numerous subdirs for fail2ban, I cannot find one that looks suitable
> > to put this list of addresses in so the
On Saturday 09 November 2019 02:49:16 mett wrote:
> On 2019年11月9日 16:30:57 JST, Gene Heskett wrote:
> >I have a list of ipv4's I want fail2ban to block. But amongst the
> >numerous subdirs for fail2ban, I cannot find one that looks suitable
> > to
> >
> >pu
On 2019年11月9日 16:30:57 JST, Gene Heskett wrote:
>I have a list of ipv4's I want fail2ban to block. But amongst the
>numerous subdirs for fail2ban, I cannot find one that looks suitable to
>
>put this list of addresses in so the are blocked forever. Can someone
>more famili
* Gene Heskett wrote:
> I have a list of ipv4's I want fail2ban to block. But amongst the
> numerous subdirs for fail2ban, I cannot find one that looks suitable to
> put this list of addresses in so the are blocked forever. Can someone
> more familiar with how fail2ban wor
I have a list of ipv4's I want fail2ban to block. But amongst the
numerous subdirs for fail2ban, I cannot find one that looks suitable to
put this list of addresses in so the are blocked forever. Can someone
more familiar with how fail2ban works give me a hand? These are the
ipv4 addr
1 - 100 of 156 matches
Mail list logo
