Hi,
Well, named is pretty smart and knew the requests were bogus, as
indicated by the "denied". My named is still resolving valid requests
for my domain.
And fail2ban does support this very circumstance. I had to edit
fail2ban's built in regex for named before it would work. I am guessing
that bind added a field into the security.log message that broke the regex.
For any that care, since I use shorewall as my firewall, I also had to
modify the fail2ban banaction to use shorewall instead of iptables, and
modify shorewall to dynamic blacklist ALL connections.
After all this is done, my ppp connection sees the bogus requests but
silently ignores them.
On 08/29/18 23:29, ac via talk wrote:
Hi,
normally, i would not respond to a post like yours :)
when people ask your dns server a question, they are not logging into
your system. - so fail2ban is not the correct tool
the correct answer is any of the below:
you need to write a program or a script
for example on a small single system - one that checks your logs and
then adds an iptables rule to your firewall - larger
systems/clusters simply customize bind or maybe rate limit
connections (check your named.conf - rate limit) and/or a
combination of these things - there are also many other ways to stop
this (for example forward write to your routers (if you have
routers) etc.
hth
Andre
On Wed, 29 Aug 2018 20:40:16 -0400
Michael Galea via talk <[email protected]> wrote:
I am experiencing what I believe is a DNS amplification attack on my
bind9 DNS server.
I'm seeing very of the following on different IPs
20:11:53.977254 IP 108.234.250.76.62926 > 69.265.222.253.53: 50679+
[1au] ANY? USADF.GOV. (38)
My server responds
20:11:53.977776 IP 69.265.222.253.53 > 108.234.250.76.62926: 50679
Refused- 0/0/1 (38)
I imagine the IPs are spoofed.
I have installed fail2ban in order to address the problem. Various
howtos detail how to configure bind to log to
/var/log/named/security.log and setup fail2ban.
The security.log is filling nicely with lots of "29-Aug-2018
20:23:07.798 client @0x7fa1d013b990 66.69.234.170#29024 (USADF.GOV):
query (cache) 'USADF.GOV/ANY/IN' denied" and fail2ban is indicating
"Jail 'named-refused' started" but it never actually bans an IP.
2) I used fail2ban-regex to test the security.log line against
fail2bans named-refused regex, but its doesn't match! So I have to
conclude either debian bind9 changed the log output or fail2ban git
it wrong.
I'm using the latest fail2ban from debian. Has anyone else got this
to work?
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
--
Michael Galea
---
Talk Mailing List
[email protected]
https://gtalug.org/mailman/listinfo/talk
