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 <talk@gtalug.org> 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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Michael Galea
yeah, this is the reason why I do not usually respond to this type of post... security is a wide and varying topic. and opinions are held by all and sundry. just for the record though: what i said was: fail2ban is not the right tool not that it cannot do it... anyway, at least you have a working solution and for ppp i guess it is all good and what i should have said is ymmv :) On Thu, 30 Aug 2018 02:27:27 -0400 Michael Galea via talk <talk@gtalug.org> wrote:
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 <talk@gtalug.org> 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 talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
participants (2)
-
ac -
Michael Galea