From: Jörg Frings-F. <jf...@jf...> - 2012-07-21 11:12:59
Attachments:
signature.asc
|
Hi, in my query-log I got a lot of lines 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) or without print-time yes client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) My failregex: > [0-9]{1,2}\-\w{3}\-[0-9]{4} [:0-9.]{12} client <HOST>#.+: query: > ripe.net [[:print:]]+$ or / and > client <HOST>#.+: query: ripe.net [[:print:]]+$ But testing with fail2ban-regex results: > Running tests > ============= > > Use regex file : /etc/fail2ban/filter.d/named-ddos-ripe.conf > Use log file : /var/log/query.log.X > > > Results > ======= > > Failregex > |- Regular expressions: > | [1] [0-9]{1,2}\-\w{3}\-[0-9]{4} [:0-9.]{12} client <HOST>#.+: query: ripe.net [[:print:]]+$ > | [2] client <HOST>#.+: query: ripe.net [[:print:]]+$ > | > `- Number of matches: > [1] 0 match(es) > [2] 0 match(es) > > Ignoreregex > |- Regular expressions: > | > `- Number of matches: > > Summary > ======= > > Sorry, no match So I need same help while I don't see my error. Thank you, Jörg |
From: Fabian W. <fa...@we...> - 2012-07-21 16:03:36
|
Hello Jörg On 21.07.2012 12:54, Jörg Frings-Fürst wrote: > in my query-log I got a lot of lines > > 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN ANY > +ED (82.165.156.1) > > or without print-time yes > > client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) > > > My failregex: > >> [0-9]{1,2}\-\w{3}\-[0-9]{4} [:0-9.]{12} client<HOST>#.+: query: >> ripe.net [[:print:]]+$ > > or / and > >> client<HOST>#.+: query: ripe.net [[:print:]]+$ I am not sure if such complex regex do work in fail2ban. For your entry I would create something like this: client <HOST>#.*: query: ripe.net IN ANY \+ED \(.*\)$ And this works at least here with 0.8.6 (sorry for the line wrap, should be on one line): fail2ban-regex "21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1)" "client <HOST>#.*: query: ripe.net IN ANY \+ED \(.*\)$" Running tests ============= Use regex line : client <HOST>#.*: query: ripe.net IN ANY \+ED \(.*\)$ Use single line: 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: ... Results ======= Failregex |- Regular expressions: | [1] client <HOST>#.*: query: ripe.net IN ANY \+ED \(.*\)$ | `- Number of matches: [1] 1 match(es) Ignoreregex |- Regular expressions: | `- Number of matches: Summary ======= Addresses found: [1] 193.219.8.157 (Sat Jul 21 02:05:44 2012) Date template hits: 0 hit(s): MONTH Day Hour:Minute:Second 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second 0 hit(s): Year/Month/Day Hour:Minute:Second 0 hit(s): Day/Month/Year Hour:Minute:Second 0 hit(s): Day/Month/Year Hour:Minute:Second 0 hit(s): Day/MONTH/Year:Hour:Minute:Second 0 hit(s): Month/Day/Year:Hour:Minute:Second 0 hit(s): Year-Month-Day Hour:Minute:Second 0 hit(s): Year.Month.Day Hour:Minute:Second 2 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond] 0 hit(s): Day-Month-Year Hour:Minute:Second 0 hit(s): TAI64N 0 hit(s): Epoch 0 hit(s): ISO 8601 0 hit(s): Hour:Minute:Second 0 hit(s): <Month/Day/Year@Hour:Minute:Second> Success, the total number of match is 1 However, look at the above section 'Running tests' which could contain important information. bye Fabian |
From: Jörg Frings-F. <jf...@jf...> - 2012-07-21 16:38:13
Attachments:
signature.asc
|
Hello Fabian, Am Samstag, den 21.07.2012, 18:03 +0200 schrieb Fabian Wenk: > Hello Jörg > > On 21.07.2012 12:54, Jörg Frings-Fürst wrote: > > in my query-log I got a lot of lines > > > > 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN ANY > > +ED (82.165.156.1) > > > > or without print-time yes > > > > client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) > > > > > > My failregex: > > > >> [0-9]{1,2}\-\w{3}\-[0-9]{4} [:0-9.]{12} client<HOST>#.+: query: > >> ripe.net [[:print:]]+$ > > > > or / and > > > >> client<HOST>#.+: query: ripe.net [[:print:]]+$ > > I am not sure if such complex regex do work in fail2ban. For your > entry I would create something like this: > > client <HOST>#.*: query: ripe.net IN ANY \+ED \(.*\)$ > > And this works at least here with 0.8.6 (sorry for the line wrap, > should be on one line): > > fail2ban-regex "21-Jul-2012 02:05:44.395 client 193.219.8.157#53: > query: ripe.net IN ANY +ED (82.165.156.1)" "client <HOST>#.*: > query: ripe.net IN ANY \+ED \(.*\)$" > > Running tests > ============= > > Use regex line : client <HOST>#.*: query: ripe.net IN ANY \+ED > \(.*\)$ > Use single line: 21-Jul-2012 02:05:44.395 client > 193.219.8.157#53: ... > > > Results > ======= > > Failregex > |- Regular expressions: > | [1] client <HOST>#.*: query: ripe.net IN ANY \+ED \(.*\)$ > | > `- Number of matches: > [1] 1 match(es) > > Ignoreregex > |- Regular expressions: > | > `- Number of matches: > > Summary > ======= > > Addresses found: > [1] > 193.219.8.157 (Sat Jul 21 02:05:44 2012) > > Date template hits: > 0 hit(s): MONTH Day Hour:Minute:Second > 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year > 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second > 0 hit(s): Year/Month/Day Hour:Minute:Second > 0 hit(s): Day/Month/Year Hour:Minute:Second > 0 hit(s): Day/Month/Year Hour:Minute:Second > 0 hit(s): Day/MONTH/Year:Hour:Minute:Second > 0 hit(s): Month/Day/Year:Hour:Minute:Second > 0 hit(s): Year-Month-Day Hour:Minute:Second > 0 hit(s): Year.Month.Day Hour:Minute:Second > 2 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond] > 0 hit(s): Day-Month-Year Hour:Minute:Second > 0 hit(s): TAI64N > 0 hit(s): Epoch > 0 hit(s): ISO 8601 > 0 hit(s): Hour:Minute:Second > 0 hit(s): <Month/Day/Year@Hour:Minute:Second> > > Success, the total number of match is 1 > > However, look at the above section 'Running tests' which could > contain important information. > > > bye > Fabian it work very fine. Thanks und Grüezi in die Schweiz Jörg |
From: Yaroslav H. <li...@on...> - 2012-07-23 02:16:26
|
note though (citing from jail.conf a prefix to named-* jails): # !!! WARNING !!! # Since UDP is connection-less protocol, spoofing of IP and imitation # of illegal actions is way too simple. Thus enabling of this filter # might provide an easy way for implementing a DoS against a chosen # victim. See # http://nion.modprobe.de/blog/archives/690-fail2ban-+-dns-fail.html # Please DO NOT USE this jail unless you know what you are doing. On Sat, 21 Jul 2012, Jörg Frings-Fürst wrote: > > > in my query-log I got a lot of lines > > > 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN ANY > > > +ED (82.165.156.1) > > > or without print-time yes > > > client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik |
From: Jörg Frings-F. <jf...@jf...> - 2012-07-23 06:08:00
Attachments:
signature.asc
|
Am Sonntag, den 22.07.2012, 22:16 -0400 schrieb Yaroslav Halchenko: > note though (citing from jail.conf a prefix to named-* jails): > > # !!! WARNING !!! > # Since UDP is connection-less protocol, spoofing of IP and imitation > # of illegal actions is way too simple. Thus enabling of this filter > # might provide an easy way for implementing a DoS against a chosen > # victim. See > # http://nion.modprobe.de/blog/archives/690-fail2ban-+-dns-fail.html > # Please DO NOT USE this jail unless you know what you are doing. > > > On Sat, 21 Jul 2012, Jörg Frings-Fürst wrote: > > > > > in my query-log I got a lot of lines > > > > > 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN ANY > > > > +ED (82.165.156.1) > > > > > or without print-time yes > > > > > client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) > Hi Yaroslav, I know that the IPs are fakes. I use the jail(s) only for prevent my nameservers for to much load. Jörg |
From: Arturo 'B. B. <bu...@bu...> - 2012-07-23 11:48:42
|
Better use your firewall. You're spending resources on potentially spoofed IP addresses. On 7/23/12, Jörg Frings-Fürst <jf...@jf...> wrote: > Am Sonntag, den 22.07.2012, 22:16 -0400 schrieb Yaroslav Halchenko: >> note though (citing from jail.conf a prefix to named-* jails): >> >> # !!! WARNING !!! >> # Since UDP is connection-less protocol, spoofing of IP and imitation >> # of illegal actions is way too simple. Thus enabling of this filter >> # might provide an easy way for implementing a DoS against a chosen >> # victim. See >> # http://nion.modprobe.de/blog/archives/690-fail2ban-+-dns-fail.html >> # Please DO NOT USE this jail unless you know what you are doing. >> >> >> On Sat, 21 Jul 2012, Jörg Frings-Fürst wrote: >> >> > > > in my query-log I got a lot of lines >> >> > > > 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: ripe.net IN >> > > > ANY >> > > > +ED (82.165.156.1) >> >> > > > or without print-time yes >> >> > > > client 193.219.8.157#53: query: ripe.net IN ANY +ED (82.165.156.1) >> > > Hi Yaroslav, > > I know that the IPs are fakes. I use the jail(s) only for prevent my > nameservers for to much load. > > Jörg > -- Sent from my mobile device |
From: David C. M. <sto...@gm...> - 2012-07-23 12:33:47
Attachments:
signature.asc
|
El Mon, 23 Jul 2012 08:23:55 -0300 "Arturo 'Buanzo' Busleiman" <bu...@bu...> escribió: > Better use your firewall. You're spending resources on potentially > spoofed IP addresses. > > > > On 7/23/12, Jörg Frings-Fürst <jf...@jf...> wrote: > > Am Sonntag, den 22.07.2012, 22:16 -0400 schrieb Yaroslav Halchenko: > >> note though (citing from jail.conf a prefix to named-* jails): > >> > >> # !!! WARNING !!! > >> # Since UDP is connection-less protocol, spoofing of IP and > >> imitation # of illegal actions is way too simple. Thus enabling > >> of this filter # might provide an easy way for implementing a > >> DoS against a chosen # victim. See > >> # > >> http://nion.modprobe.de/blog/archives/690-fail2ban-+-dns-fail.html > >> # Please DO NOT USE this jail unless you know what you are doing. > >> > >> > >> On Sat, 21 Jul 2012, Jörg Frings-Fürst wrote: > >> > >> > > > in my query-log I got a lot of lines > >> > >> > > > 21-Jul-2012 02:05:44.395 client 193.219.8.157#53: query: > >> > > > ripe.net IN ANY > >> > > > +ED (82.165.156.1) > >> > >> > > > or without print-time yes > >> > >> > > > client 193.219.8.157#53: query: ripe.net IN ANY +ED > >> > > > (82.165.156.1) > >> > > > > Hi Yaroslav, > > > > I know that the IPs are fakes. I use the jail(s) only for prevent my > > nameservers for to much load. > > > > Jörg > > > Maybe it is offtopic, but how can be (efectivelly) detect whether address is spoofed or not? |
From: Yaroslav H. <li...@on...> - 2012-07-23 15:31:38
|
On Mon, 23 Jul 2012, David Carlos Manuelda wrote: > Maybe it is offtopic, but how can be (efectivelly) detect whether > address is spoofed or not? I can be utterly wrong but AFAIK for queries via UDP -- nohow, and only with adoption of DNSSEC http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik |
From: Fabian W. <fa...@we...> - 2012-07-23 18:08:22
|
Hello On 23.07.2012 17:31, Yaroslav Halchenko wrote: > On Mon, 23 Jul 2012, David Carlos Manuelda wrote: > >> Maybe it is offtopic, but how can be (efectivelly) detect whether >> address is spoofed or not? As far as I know, you can not detect if the first UDP packet received for a communication is spoofed or not. As I see it, this is nothing the firewall can filter. So the steps from Jörg are fine to do this with fail2ban. The only thing to keep in mind it, not to reject this packets, but just drop them so it will not send back traffic to a potential third party. I am using the named-refused filter on my system log, where named does logging like this: Jul 23 19:30:30 batman named[869]: client 50.7.164.42#43942: query (cache) 'example.com/ANY/IN' denied In this case, this are requests to a domain which was on my server, but has been removed since 8 month ago. > I can be utterly wrong but AFAIK for queries via UDP -- nohow, and only > with adoption of DNSSEC > http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions But DNSSEC does only work, when the resolver (client) is requesting it. But the server should always be able to also answer requests without DNSSEC. bye Fabian |
From: Tom H. <to...@wh...> - 2012-07-23 18:51:05
|
On 23-07-12 20:08, Fabian Wenk wrote: > >> I can be utterly wrong but AFAIK for queries via UDP -- nohow, and only >> with adoption of DNSSEC >> http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions > > But DNSSEC does only work, when the resolver (client) is > requesting it. But the server should always be able to also > answer requests without DNSSEC. > DNSSEC has nothing to do with securing communication between client and server: it cannot prove that the client (or the server) is to be trusted. Its purpose is to enable the client to check that *the answer* from the server is correct. It secures the message data, not the transport. Since f2b is only interested in the transport ip address, DNSSEC is completely out of scope here. At least if you don't include the fact that DNSSEC packets are much bigger than non-DNSSEC packets, which means that an attack as described above (spoofing source ip so your answers go to a unknowing third party in order to DDOS that party) is much easier to accomplish, But as already was said by Fabian, f2b is not the right tool for blocking such abuse. -- Tom |
From: Yaroslav H. <li...@on...> - 2012-07-23 22:57:51
|
On Mon, 23 Jul 2012, Tom Hendrikx wrote: > >> I can be utterly wrong but AFAIK for queries via UDP -- nohow, and only > >> with adoption of DNSSEC > >> http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions > > But DNSSEC does only work, when the resolver (client) is > > requesting it. But the server should always be able to also > > answer requests without DNSSEC. > >...< > Since f2b is only interested in the transport ip address, DNSSEC is > completely out of scope here. At least if you don't include the fact > that DNSSEC packets are much bigger than non-DNSSEC packets, which means > that an attack as described above (spoofing source ip so your answers go > to a unknowing third party in order to DDOS that party) is much easier > to accomplish, just for the sake of my own education: am I not correct that use of DNSSEC practically implies use of TCP due to large packet sizes, thus actually an additional difficulty of spoofing, thus such an attack would be actually more difficult to accomplish... ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik |
From: Tom H. <to...@wh...> - 2012-07-24 07:31:45
|
On 7/24/12 12:57 AM, Yaroslav Halchenko wrote: > > On Mon, 23 Jul 2012, Tom Hendrikx wrote: >>>> I can be utterly wrong but AFAIK for queries via UDP -- nohow, and only >>>> with adoption of DNSSEC >>>> http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions >>> But DNSSEC does only work, when the resolver (client) is >>> requesting it. But the server should always be able to also >>> answer requests without DNSSEC. >>> ...< >> Since f2b is only interested in the transport ip address, DNSSEC is >> completely out of scope here. At least if you don't include the fact >> that DNSSEC packets are much bigger than non-DNSSEC packets, which means >> that an attack as described above (spoofing source ip so your answers go >> to a unknowing third party in order to DDOS that party) is much easier >> to accomplish, > > just for the sake of my own education: am I not correct that use of > DNSSEC practically implies use of TCP due to large packet sizes, thus > actually an additional difficulty of spoofing, thus such an attack would > be actually more difficult to accomplish... ? > When you are a bona fide DNS client, you'll want complete packets so a tcp fallback/retransmission for DNSSEC is logical. But since attackers don't care about the payload, it's enough for them to get the abused server to send large UDP packets to the attacked ip address. 512 bytes (or up to 4096 bytes when EDNS0 is used) is still quite large, and the attacker knows that the answer packet size will be maximized because DNSSEC payload is large by design. -- Tom |
From: Fabian W. <fa...@we...> - 2012-07-24 07:38:15
|
Hello Yaroslav On 24.07.2012 00:57, Yaroslav Halchenko wrote: > just for the sake of my own education: am I not correct that use of > DNSSEC practically implies use of TCP due to large packet sizes, thus > actually an additional difficulty of spoofing, thus such an attack would > be actually more difficult to accomplish... ? I do not know such details about DNSSEC, but without DNSSEC the DNS server does use TCP, if the answer is to large for one packet (1500 bytes including IP headers). In this case the server ask the resolver back through UDP to redo the request through TCP. But currently there are to many possible requests through UDP with just a small request, e.g. for ANY, which usually gives in proportion a much larger (but less then 1500 byte) answer. About 3 years ago there was an attack with IN NS requests for the . (root) zone, which BIND has answered, even when it was not configured for recursion from the outside world. In this case the request is very small, but the answer is quite large (but still fits into one packet) with all the hostnames and IP addresses for the root nameserver from a to m. If requests with a faked source IP address would be done from many systems (a bot net) to a lot of non-involved DNS server, then the attacked IP address will get a lot more data traffic with the answers from all this non-involved DNS server. So it is a good idea to detect such abuse and block it, so your DNS server will not be part of this attack. It is very sad, that many ISPs do not implement best practice and only allow outbound traffic with source IP address from their own and customer IP ranges. If they would do it, such attacks would not be possible, or at least limited to the same ISP. BIND does not have any kind of rate limiting, but probably this is for good, as a lot of things will break when a DNS server does not answer the requests from legitimate clients. The only thing which safely could be blocked are DNS requests for IN ANY (use a reasonable maxretry and short findtime), as there is no technical reason for such requests. As far as I know, this are only manual request done from humans to debug a domain. Also blocking request for domains, for which your DNS server is not authoritative, is safe to do. Use it also with a reasonable maxretry and short findtime so that at least a few NX answers can get back. bye Fabian |
From: Vik K. <vip...@gm...> - 2014-04-02 14:36:19
|
new version of BIND has RRL for rate-limiting. in any case, i've written a jail and configuration for bind9 that protects against DDoS attacks. I'd like to post it on wiki. Can someone help me with setting up an account on the fail2ban wiki? Thanks On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk <fa...@we...> wrote: > Hello Yaroslav > > On 24.07.2012 00:57, Yaroslav Halchenko wrote: > > just for the sake of my own education: am I not correct that use of > > DNSSEC practically implies use of TCP due to large packet sizes, thus > > actually an additional difficulty of spoofing, thus such an attack would > > be actually more difficult to accomplish... ? > > I do not know such details about DNSSEC, but without DNSSEC the > DNS server does use TCP, if the answer is to large for one packet > (1500 bytes including IP headers). In this case the server ask > the resolver back through UDP to redo the request through TCP. > But currently there are to many possible requests through UDP > with just a small request, e.g. for ANY, which usually gives in > proportion a much larger (but less then 1500 byte) answer. > > About 3 years ago there was an attack with IN NS requests for the > . (root) zone, which BIND has answered, even when it was not > configured for recursion from the outside world. In this case the > request is very small, but the answer is quite large (but still > fits into one packet) with all the hostnames and IP addresses for > the root nameserver from a to m. > > If requests with a faked source IP address would be done from > many systems (a bot net) to a lot of non-involved DNS server, > then the attacked IP address will get a lot more data traffic > with the answers from all this non-involved DNS server. So it is > a good idea to detect such abuse and block it, so your DNS server > will not be part of this attack. > > It is very sad, that many ISPs do not implement best practice and > only allow outbound traffic with source IP address from their own > and customer IP ranges. If they would do it, such attacks would > not be possible, or at least limited to the same ISP. > > BIND does not have any kind of rate limiting, but probably this > is for good, as a lot of things will break when a DNS server does > not answer the requests from legitimate clients. The only thing > which safely could be blocked are DNS requests for IN ANY (use a > reasonable maxretry and short findtime), as there is no technical > reason for such requests. As far as I know, this are only manual > request done from humans to debug a domain. Also blocking request > for domains, for which your DNS server is not authoritative, is > safe to do. Use it also with a reasonable maxretry and short > findtime so that at least a few NX answers can get back. > > > bye > Fabian > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |
From: Tom H. <to...@wh...> - 2014-04-02 14:40:35
Attachments:
signature.asc
|
Hi, You should put the jail/config stuff in a github pull request I think. then everybody can actually use it:) Tom On 04/02/2014 04:36 PM, Vik Killa wrote: > new version of BIND has RRL for rate-limiting. > in any case, i've written a jail and configuration for bind9 that > protects against DDoS attacks. > I'd like to post it on wiki. > Can someone help me with setting up an account on the fail2ban wiki? > Thanks > > > > On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk <fa...@we... > <mailto:fa...@we...>> wrote: > > Hello Yaroslav > > On 24.07.2012 00 <tel:24.07.2012%2000>:57, Yaroslav Halchenko wrote: > > just for the sake of my own education: am I not correct that use of > > DNSSEC practically implies use of TCP due to large packet sizes, thus > > actually an additional difficulty of spoofing, thus such an attack > would > > be actually more difficult to accomplish... ? > > I do not know such details about DNSSEC, but without DNSSEC the > DNS server does use TCP, if the answer is to large for one packet > (1500 bytes including IP headers). In this case the server ask > the resolver back through UDP to redo the request through TCP. > But currently there are to many possible requests through UDP > with just a small request, e.g. for ANY, which usually gives in > proportion a much larger (but less then 1500 byte) answer. > > About 3 years ago there was an attack with IN NS requests for the > . (root) zone, which BIND has answered, even when it was not > configured for recursion from the outside world. In this case the > request is very small, but the answer is quite large (but still > fits into one packet) with all the hostnames and IP addresses for > the root nameserver from a to m. > > If requests with a faked source IP address would be done from > many systems (a bot net) to a lot of non-involved DNS server, > then the attacked IP address will get a lot more data traffic > with the answers from all this non-involved DNS server. So it is > a good idea to detect such abuse and block it, so your DNS server > will not be part of this attack. > > It is very sad, that many ISPs do not implement best practice and > only allow outbound traffic with source IP address from their own > and customer IP ranges. If they would do it, such attacks would > not be possible, or at least limited to the same ISP. > > BIND does not have any kind of rate limiting, but probably this > is for good, as a lot of things will break when a DNS server does > not answer the requests from legitimate clients. The only thing > which safely could be blocked are DNS requests for IN ANY (use a > reasonable maxretry and short findtime), as there is no technical > reason for such requests. As far as I know, this are only manual > request done from humans to debug a domain. Also blocking request > for domains, for which your DNS server is not authoritative, is > safe to do. Use it also with a reasonable maxretry and short > findtime so that at least a few NX answers can get back. > > > bye > Fabian > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > <mailto:Fai...@li...> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |
From: Tom H. <to...@wh...> - 2014-04-02 14:54:58
|
Hi Vik, please keep replies on-list... Just put it in github, it's easy to clean it up there. I'll take a look at it when it's there. But a wiki is no coding platform :) Tom On 04/02/2014 04:48 PM, Vik Killa wrote: > I think it could stand to be "cleaned up" as I am no expert with regex > and fail2ban... > I'd rather post it on wiki and have someone else push it to GIT after > it's been a bit refined... > Thanks > > > > On Wed, Apr 2, 2014 at 10:40 AM, Tom Hendrikx <to...@wh... > <mailto:to...@wh...>> wrote: > > > Hi, > > You should put the jail/config stuff in a github pull request I think. > then everybody can actually use it:) > > Tom > > On 04/02/2014 04:36 PM, Vik Killa wrote: > > new version of BIND has RRL for rate-limiting. > > in any case, i've written a jail and configuration for bind9 that > > protects against DDoS attacks. > > I'd like to post it on wiki. > > Can someone help me with setting up an account on the fail2ban wiki? > > Thanks > > > > > > > > On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk <fa...@we... > <mailto:fa...@we...> > > <mailto:fa...@we... <mailto:fa...@we...>>> wrote: > > > > Hello Yaroslav > > > > On 24.07.2012 00 <tel:24.07.2012%2000> > <tel:24.07.2012%2000>:57, Yaroslav Halchenko wrote: > > > just for the sake of my own education: am I not correct > that use of > > > DNSSEC practically implies use of TCP due to large packet > sizes, thus > > > actually an additional difficulty of spoofing, thus such an > attack > > would > > > be actually more difficult to accomplish... ? > > > > I do not know such details about DNSSEC, but without DNSSEC the > > DNS server does use TCP, if the answer is to large for one packet > > (1500 bytes including IP headers). In this case the server ask > > the resolver back through UDP to redo the request through TCP. > > But currently there are to many possible requests through UDP > > with just a small request, e.g. for ANY, which usually gives in > > proportion a much larger (but less then 1500 byte) answer. > > > > About 3 years ago there was an attack with IN NS requests for the > > . (root) zone, which BIND has answered, even when it was not > > configured for recursion from the outside world. In this case the > > request is very small, but the answer is quite large (but still > > fits into one packet) with all the hostnames and IP addresses for > > the root nameserver from a to m. > > > > If requests with a faked source IP address would be done from > > many systems (a bot net) to a lot of non-involved DNS server, > > then the attacked IP address will get a lot more data traffic > > with the answers from all this non-involved DNS server. So it is > > a good idea to detect such abuse and block it, so your DNS server > > will not be part of this attack. > > > > It is very sad, that many ISPs do not implement best practice and > > only allow outbound traffic with source IP address from their own > > and customer IP ranges. If they would do it, such attacks would > > not be possible, or at least limited to the same ISP. > > > > BIND does not have any kind of rate limiting, but probably this > > is for good, as a lot of things will break when a DNS server does > > not answer the requests from legitimate clients. The only thing > > which safely could be blocked are DNS requests for IN ANY (use a > > reasonable maxretry and short findtime), as there is no technical > > reason for such requests. As far as I know, this are only manual > > request done from humans to debug a domain. Also blocking request > > for domains, for which your DNS server is not authoritative, is > > safe to do. Use it also with a reasonable maxretry and short > > findtime so that at least a few NX answers can get back. > > > > > > bye > > Fabian > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > > Discussions > > will include endpoint security, mobile security and the latest in > > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Fail2ban-users mailing list > > Fai...@li... > <mailto:Fai...@li...> > > <mailto:Fai...@li... > <mailto:Fai...@li...>> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > Fail2ban-users mailing list > > Fai...@li... > <mailto:Fai...@li...> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > <mailto:Fai...@li...> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > |
From: Vik K. <vip...@gm...> - 2014-04-02 15:13:38
|
Sorry, I thought i was replying to list.... I just signed up for github, i think i did it correctly... https://github.com/fail2ban/fail2ban/pull/677 Thanks On Wed, Apr 2, 2014 at 10:54 AM, Tom Hendrikx <to...@wh...> wrote: > > Hi Vik, > > please keep replies on-list... > > Just put it in github, it's easy to clean it up there. I'll take a look > at it when it's there. But a wiki is no coding platform :) > > Tom > > On 04/02/2014 04:48 PM, Vik Killa wrote: > > I think it could stand to be "cleaned up" as I am no expert with regex > > and fail2ban... > > I'd rather post it on wiki and have someone else push it to GIT after > > it's been a bit refined... > > Thanks > > > > > > > > On Wed, Apr 2, 2014 at 10:40 AM, Tom Hendrikx <to...@wh... > > <mailto:to...@wh...>> wrote: > > > > > > Hi, > > > > You should put the jail/config stuff in a github pull request I > think. > > then everybody can actually use it:) > > > > Tom > > > > On 04/02/2014 04:36 PM, Vik Killa wrote: > > > new version of BIND has RRL for rate-limiting. > > > in any case, i've written a jail and configuration for bind9 that > > > protects against DDoS attacks. > > > I'd like to post it on wiki. > > > Can someone help me with setting up an account on the fail2ban > wiki? > > > Thanks > > > > > > > > > > > > On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk <fa...@we... > > <mailto:fa...@we...> > > > <mailto:fa...@we... <mailto:fa...@we...>>> wrote: > > > > > > Hello Yaroslav > > > > > > On 24.07.2012 00 <tel:24.07.2012%2000> > > <tel:24.07.2012%2000>:57, Yaroslav Halchenko wrote: > > > > just for the sake of my own education: am I not correct > > that use of > > > > DNSSEC practically implies use of TCP due to large packet > > sizes, thus > > > > actually an additional difficulty of spoofing, thus such an > > attack > > > would > > > > be actually more difficult to accomplish... ? > > > > > > I do not know such details about DNSSEC, but without DNSSEC the > > > DNS server does use TCP, if the answer is to large for one > packet > > > (1500 bytes including IP headers). In this case the server ask > > > the resolver back through UDP to redo the request through TCP. > > > But currently there are to many possible requests through UDP > > > with just a small request, e.g. for ANY, which usually gives in > > > proportion a much larger (but less then 1500 byte) answer. > > > > > > About 3 years ago there was an attack with IN NS requests for > the > > > . (root) zone, which BIND has answered, even when it was not > > > configured for recursion from the outside world. In this case > the > > > request is very small, but the answer is quite large (but still > > > fits into one packet) with all the hostnames and IP addresses > for > > > the root nameserver from a to m. > > > > > > If requests with a faked source IP address would be done from > > > many systems (a bot net) to a lot of non-involved DNS server, > > > then the attacked IP address will get a lot more data traffic > > > with the answers from all this non-involved DNS server. So it > is > > > a good idea to detect such abuse and block it, so your DNS > server > > > will not be part of this attack. > > > > > > It is very sad, that many ISPs do not implement best practice > and > > > only allow outbound traffic with source IP address from their > own > > > and customer IP ranges. If they would do it, such attacks would > > > not be possible, or at least limited to the same ISP. > > > > > > BIND does not have any kind of rate limiting, but probably this > > > is for good, as a lot of things will break when a DNS server > does > > > not answer the requests from legitimate clients. The only thing > > > which safely could be blocked are DNS requests for IN ANY (use > a > > > reasonable maxretry and short findtime), as there is no > technical > > > reason for such requests. As far as I know, this are only > manual > > > request done from humans to debug a domain. Also blocking > request > > > for domains, for which your DNS server is not authoritative, is > > > safe to do. Use it also with a reasonable maxretry and short > > > findtime so that at least a few NX answers can get back. > > > > > > > > > bye > > > Fabian > > > > > > > > > ------------------------------------------------------------------------------ > > > Live Security Virtual Conference > > > Exclusive live event will cover all the ways today's security > and > > > threat landscape has changed and how IT managers can respond. > > > Discussions > > > will include endpoint security, mobile security and the latest > in > > > malware > > > threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > > > Fail2ban-users mailing list > > > Fai...@li... > > <mailto:Fai...@li...> > > > <mailto:Fai...@li... > > <mailto:Fai...@li...>> > > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > Fail2ban-users mailing list > > > Fai...@li... > > <mailto:Fai...@li...> > > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Fail2ban-users mailing list > > Fai...@li... > > <mailto:Fai...@li...> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |
From: Vik K. <vip...@gm...> - 2014-04-02 15:33:09
|
Looks like my pull request failed...lol this is why i prefer just adding to wiki https://travis-ci.org/fail2ban/fail2ban/builds/22111129 On Wed, Apr 2, 2014 at 11:13 AM, Vik Killa <vip...@gm...> wrote: > > Sorry, I thought i was replying to list.... > I just signed up for github, i think i did it correctly... > https://github.com/fail2ban/fail2ban/pull/677 > > Thanks > > > On Wed, Apr 2, 2014 at 10:54 AM, Tom Hendrikx <to...@wh...> wrote: > >> >> Hi Vik, >> >> please keep replies on-list... >> >> Just put it in github, it's easy to clean it up there. I'll take a look >> at it when it's there. But a wiki is no coding platform :) >> >> Tom >> >> On 04/02/2014 04:48 PM, Vik Killa wrote: >> > I think it could stand to be "cleaned up" as I am no expert with regex >> > and fail2ban... >> > I'd rather post it on wiki and have someone else push it to GIT after >> > it's been a bit refined... >> > Thanks >> > >> > >> > >> > On Wed, Apr 2, 2014 at 10:40 AM, Tom Hendrikx <to...@wh... >> > <mailto:to...@wh...>> wrote: >> > >> > >> > Hi, >> > >> > You should put the jail/config stuff in a github pull request I >> think. >> > then everybody can actually use it:) >> > >> > Tom >> > >> > On 04/02/2014 04:36 PM, Vik Killa wrote: >> > > new version of BIND has RRL for rate-limiting. >> > > in any case, i've written a jail and configuration for bind9 that >> > > protects against DDoS attacks. >> > > I'd like to post it on wiki. >> > > Can someone help me with setting up an account on the fail2ban >> wiki? >> > > Thanks >> > > >> > > >> > > >> > > On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk <fa...@we... >> > <mailto:fa...@we...> >> > > <mailto:fa...@we... <mailto:fa...@we...>>> wrote: >> > > >> > > Hello Yaroslav >> > > >> > > On 24.07.2012 00 <tel:24.07.2012%2000> >> > <tel:24.07.2012%2000>:57, Yaroslav Halchenko wrote: >> > > > just for the sake of my own education: am I not correct >> > that use of >> > > > DNSSEC practically implies use of TCP due to large packet >> > sizes, thus >> > > > actually an additional difficulty of spoofing, thus such an >> > attack >> > > would >> > > > be actually more difficult to accomplish... ? >> > > >> > > I do not know such details about DNSSEC, but without DNSSEC >> the >> > > DNS server does use TCP, if the answer is to large for one >> packet >> > > (1500 bytes including IP headers). In this case the server ask >> > > the resolver back through UDP to redo the request through TCP. >> > > But currently there are to many possible requests through UDP >> > > with just a small request, e.g. for ANY, which usually gives >> in >> > > proportion a much larger (but less then 1500 byte) answer. >> > > >> > > About 3 years ago there was an attack with IN NS requests for >> the >> > > . (root) zone, which BIND has answered, even when it was not >> > > configured for recursion from the outside world. In this case >> the >> > > request is very small, but the answer is quite large (but >> still >> > > fits into one packet) with all the hostnames and IP addresses >> for >> > > the root nameserver from a to m. >> > > >> > > If requests with a faked source IP address would be done from >> > > many systems (a bot net) to a lot of non-involved DNS server, >> > > then the attacked IP address will get a lot more data traffic >> > > with the answers from all this non-involved DNS server. So it >> is >> > > a good idea to detect such abuse and block it, so your DNS >> server >> > > will not be part of this attack. >> > > >> > > It is very sad, that many ISPs do not implement best practice >> and >> > > only allow outbound traffic with source IP address from their >> own >> > > and customer IP ranges. If they would do it, such attacks >> would >> > > not be possible, or at least limited to the same ISP. >> > > >> > > BIND does not have any kind of rate limiting, but probably >> this >> > > is for good, as a lot of things will break when a DNS server >> does >> > > not answer the requests from legitimate clients. The only >> thing >> > > which safely could be blocked are DNS requests for IN ANY >> (use a >> > > reasonable maxretry and short findtime), as there is no >> technical >> > > reason for such requests. As far as I know, this are only >> manual >> > > request done from humans to debug a domain. Also blocking >> request >> > > for domains, for which your DNS server is not authoritative, >> is >> > > safe to do. Use it also with a reasonable maxretry and short >> > > findtime so that at least a few NX answers can get back. >> > > >> > > >> > > bye >> > > Fabian >> > > >> > > >> > >> ------------------------------------------------------------------------------ >> > > Live Security Virtual Conference >> > > Exclusive live event will cover all the ways today's security >> and >> > > threat landscape has changed and how IT managers can respond. >> > > Discussions >> > > will include endpoint security, mobile security and the >> latest in >> > > malware >> > > threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> > > _______________________________________________ >> > > Fail2ban-users mailing list >> > > Fai...@li... >> > <mailto:Fai...@li...> >> > > <mailto:Fai...@li... >> > <mailto:Fai...@li...>> >> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users >> > > >> > > >> > > >> > > >> > > >> > >> ------------------------------------------------------------------------------ >> > > >> > > >> > > >> > > _______________________________________________ >> > > Fail2ban-users mailing list >> > > Fai...@li... >> > <mailto:Fai...@li...> >> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users >> > > >> > >> > >> > >> > >> ------------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Fail2ban-users mailing list >> > Fai...@li... >> > <mailto:Fai...@li...> >> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users >> > >> > >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Fail2ban-users mailing list >> Fai...@li... >> https://lists.sourceforge.net/lists/listinfo/fail2ban-users >> > > |
From: Yaroslav H. <li...@on...> - 2014-04-11 04:03:44
|
On Wed, 02 Apr 2014, Vik Killa wrote: > My goal is not to get this committed to code-base. As I said before the > setup most likely need refinement. I tested it and it works. I only wanted > to share it as a resource where it could be edited by others which is why > I just wanted to post it on wiki for others... > How can I get a wiki account? I believe Yehuda Katz <ye...@ym...> did it last times... I forgot the regiment -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Senior Research Associate, Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik |
From: Yehuda K. <ye...@ym...> - 2014-04-11 21:22:41
|
I am a bit behind on my email, but as soon as I find the original request (so I can get the user details), I will create an account. - Y On Fri, Apr 11, 2014 at 12:03 AM, Yaroslav Halchenko <li...@on...>wrote: > > On Wed, 02 Apr 2014, Vik Killa wrote: > > > My goal is not to get this committed to code-base. As I said before > the > > setup most likely need refinement. I tested it and it works. I only > wanted > > to share it as a resource where it could be edited by others which is > why > > I just wanted to post it on wiki for others... > > How can I get a wiki account? > > I believe Yehuda Katz <ye...@ym...> did it last times... I forgot > the regiment > > -- > Yaroslav O. Halchenko, Ph.D. > http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org > Senior Research Associate, Psychological and Brain Sciences Dept. > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 > WWW: http://www.linkedin.com/in/yarik > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |
From: Fabian W. <fa...@we...> - 2012-07-23 20:12:12
|
Hello Tom On 23.07.2012 20:50, Tom Hendrikx wrote: > to accomplish, But as already was said by Fabian, f2b is not the right > tool for blocking such abuse. I said, that a firewall is probably not the right thing to block such spoofed UDP DNS request, but fail2ban is. If you can identify wrong requests which arrive at your DNS server, then fail2ban is perfect of blocking them. I still do get quite a lot of such requests, as f2b needs a little longer until banning, as this requests can arrive very fast. This jail is configures with maxretry = 5, findtime = 10 and I do ban them for 24 hours. Here are some numbers regarding the sample log line I posted in my last mail (only from the last 22 hours): root@batman:~ # grep -c "/ANY/IN' denied" /var/log/all.log 2379 root@batman:~ # grep "/ANY/IN' denied" /var/log/all.log | awk '{ print $7 }' | sed 's/\#.*://' | sort | uniq -c | sort -rn | head 147 59.34.197.243 78 122.224.48.58 77 61.160.247.20 75 121.12.106.117 70 122.224.51.90 70 122.224.49.202 62 122.224.48.53 60 171.34.32.180 56 221.5.106.89 56 118.186.38.227 root@batman:~ # root@batman:~ # grep 59.34.197.243 /var/log/all.log | head -2 Jul 23 06:57:32 batman named[869]: client 59.34.197.243#34700: query (cache) 'example.com/ANY/IN' denied Jul 23 06:57:32 batman named[869]: client 59.34.197.243#13087: query (cache) 'example.com/ANY/IN' denied root@batman:~ # root@batman:~ # grep 59.34.197.243 /var/log/all.log | tail -2 Jul 23 06:57:37 batman named[869]: client 59.34.197.243#15606: query (cache) 'example.com/ANY/IN' denied Jul 23 06:57:37 batman named[869]: client 59.34.197.243#896: query (cache) 'example.com/ANY/IN' denied root@batman:~ # The 147 requests from 59.34.197.243 arrived in only 6 seconds, then it was banned from f2b with an IPFW drop rule. If I would not ban them, this would run for much longer (even hours) with many more requests and also answers to the potential faked third party IP address. This requests are completely useless on my DNS server, as it is not authoritative for the requested domain. bye Fabian |
From: Arturo 'B. B. <bu...@bu...> - 2012-07-23 20:27:24
|
Firewall does not only mean "block". On 7/23/12, Fabian Wenk <fa...@we...> wrote: > Hello Tom > > On 23.07.2012 20:50, Tom Hendrikx wrote: >> to accomplish, But as already was said by Fabian, f2b is not the right >> tool for blocking such abuse. > > I said, that a firewall is probably not the right thing to block > such spoofed UDP DNS request, but fail2ban is. If you can > identify wrong requests which arrive at your DNS server, then > fail2ban is perfect of blocking them. > > I still do get quite a lot of such requests, as f2b needs a > little longer until banning, as this requests can arrive very > fast. This jail is configures with maxretry = 5, findtime = 10 > and I do ban them for 24 hours. > > Here are some numbers regarding the sample log line I posted in > my last mail (only from the last 22 hours): > > root@batman:~ # grep -c "/ANY/IN' denied" /var/log/all.log > 2379 > > root@batman:~ # grep "/ANY/IN' denied" /var/log/all.log | awk '{ > print $7 }' | sed 's/\#.*://' | sort | uniq -c | sort -rn | head > 147 59.34.197.243 > 78 122.224.48.58 > 77 61.160.247.20 > 75 121.12.106.117 > 70 122.224.51.90 > 70 122.224.49.202 > 62 122.224.48.53 > 60 171.34.32.180 > 56 221.5.106.89 > 56 118.186.38.227 > root@batman:~ # > > root@batman:~ # grep 59.34.197.243 /var/log/all.log | head -2 > Jul 23 06:57:32 batman named[869]: client 59.34.197.243#34700: > query (cache) 'example.com/ANY/IN' denied > Jul 23 06:57:32 batman named[869]: client 59.34.197.243#13087: > query (cache) 'example.com/ANY/IN' denied > root@batman:~ # > > root@batman:~ # grep 59.34.197.243 /var/log/all.log | tail -2 > Jul 23 06:57:37 batman named[869]: client 59.34.197.243#15606: > query (cache) 'example.com/ANY/IN' denied > Jul 23 06:57:37 batman named[869]: client 59.34.197.243#896: > query (cache) 'example.com/ANY/IN' denied > root@batman:~ # > > The 147 requests from 59.34.197.243 arrived in only 6 seconds, > then it was banned from f2b with an IPFW drop rule. > > If I would not ban them, this would run for much longer (even > hours) with many more requests and also answers to the potential > faked third party IP address. This requests are completely > useless on my DNS server, as it is not authoritative for the > requested domain. > > > bye > Fabian > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > -- Sent from my mobile device |
From: Tom H. <to...@wh...> - 2014-04-02 16:49:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The PR is ok, but the contents arentt (yet). The tests just make sure that it's easy to spot errors. Your PR seems to miss a log snippet that can be used to test if the jail actually works. Some documentation on how things should look like: https://github.com/fail2ban/fail2ban/blob/master/FILTERS If you run into issues, post the logs here, we'll help you. :) Tom On 02-04-14 17:33, Vik Killa wrote: > Looks like my pull request failed...lol this is why i prefer just > adding to wiki > https://travis-ci.org/fail2ban/fail2ban/builds/22111129 > > > > On Wed, Apr 2, 2014 at 11:13 AM, Vik Killa <vip...@gm... > <mailto:vip...@gm...>> wrote: > > > Sorry, I thought i was replying to list.... I just signed up for > github, i think i did it correctly... > https://github.com/fail2ban/fail2ban/pull/677 > > Thanks > > > On Wed, Apr 2, 2014 at 10:54 AM, Tom Hendrikx <to...@wh... > <mailto:to...@wh...>> wrote: > > > Hi Vik, > > please keep replies on-list... > > Just put it in github, it's easy to clean it up there. I'll take a > look at it when it's there. But a wiki is no coding platform :) > > Tom > > On 04/02/2014 04:48 PM, Vik Killa wrote: >> I think it could stand to be "cleaned up" as I am no expert > with regex >> and fail2ban... I'd rather post it on wiki and have someone else >> push it to > GIT after >> it's been a bit refined... Thanks >> >> >> >> On Wed, Apr 2, 2014 at 10:40 AM, Tom Hendrikx > <to...@wh... <mailto:to...@wh...> >> <mailto:to...@wh... <mailto:to...@wh...>>> wrote: >> >> >> Hi, >> >> You should put the jail/config stuff in a github pull > request I think. >> then everybody can actually use it:) >> >> Tom >> >> On 04/02/2014 04:36 PM, Vik Killa wrote: >>> new version of BIND has RRL for rate-limiting. in any case, >>> i've written a jail and configuration for > bind9 that >>> protects against DDoS attacks. I'd like to post it on wiki. Can >>> someone help me with setting up an account on the > fail2ban wiki? >>> Thanks >>> >>> >>> >>> On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk > <fa...@we... <mailto:fa...@we...> >> <mailto:fa...@we... <mailto:fa...@we...>> >>> <mailto:fa...@we... <mailto:fa...@we...> > <mailto:fa...@we... <mailto:fa...@we...>>>> wrote: >>> >>> Hello Yaroslav >>> >>> On 24.07.2012 00 <tel:24.07.2012%2000> > <tel:24.07.2012%2000> >> <tel:24.07.2012%2000>:57, Yaroslav Halchenko wrote: >>>> just for the sake of my own education: am I not > correct >> that use of >>>> DNSSEC practically implies use of TCP due to large > packet >> sizes, thus >>>> actually an additional difficulty of spoofing, > thus such an >> attack >>> would >>>> be actually more difficult to accomplish... ? >>> >>> I do not know such details about DNSSEC, but without > DNSSEC the >>> DNS server does use TCP, if the answer is to large > for one packet >>> (1500 bytes including IP headers). In this case the > server ask >>> the resolver back through UDP to redo the request > through TCP. >>> But currently there are to many possible requests > through UDP >>> with just a small request, e.g. for ANY, which > usually gives in >>> proportion a much larger (but less then 1500 byte) > answer. >>> >>> About 3 years ago there was an attack with IN NS > requests for the >>> . (root) zone, which BIND has answered, even when it > was not >>> configured for recursion from the outside world. In > this case the >>> request is very small, but the answer is quite large > (but still >>> fits into one packet) with all the hostnames and IP > addresses for >>> the root nameserver from a to m. >>> >>> If requests with a faked source IP address would be > done from >>> many systems (a bot net) to a lot of non-involved > DNS server, >>> then the attacked IP address will get a lot more > data traffic >>> with the answers from all this non-involved DNS > server. So it is >>> a good idea to detect such abuse and block it, so > your DNS server >>> will not be part of this attack. >>> >>> It is very sad, that many ISPs do not implement best > practice and >>> only allow outbound traffic with source IP address > from their own >>> and customer IP ranges. If they would do it, such > attacks would >>> not be possible, or at least limited to the same ISP. >>> >>> BIND does not have any kind of rate limiting, but > probably this >>> is for good, as a lot of things will break when a > DNS server does >>> not answer the requests from legitimate clients. The > only thing >>> which safely could be blocked are DNS requests for > IN ANY (use a >>> reasonable maxretry and short findtime), as there is > no technical >>> reason for such requests. As far as I know, this are > only manual >>> request done from humans to debug a domain. Also > blocking request >>> for domains, for which your DNS server is not > authoritative, is >>> safe to do. Use it also with a reasonable maxretry > and short >>> findtime so that at least a few NX answers can get back. >>> >>> >>> bye Fabian >>> >>> >> > ------------------------------------------------------------------------------ > > >> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's > security and >>> threat landscape has changed and how IT managers can > respond. >>> Discussions will include endpoint security, mobile security >>> and > the latest in >>> malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ Fail2ban-users >>> mailing list Fai...@li... > <mailto:Fai...@li...> >> <mailto:Fai...@li... > <mailto:Fai...@li...>> >>> <mailto:Fai...@li... > <mailto:Fai...@li...> >> <mailto:Fai...@li... > <mailto:Fai...@li...>>> >>> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users >>> >>> >>> >>> >>> >> > ------------------------------------------------------------------------------ > > >> >>> >>> >>> _______________________________________________ Fail2ban-users >>> mailing list Fai...@li... > <mailto:Fai...@li...> >> <mailto:Fai...@li... > <mailto:Fai...@li...>> >>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users >>> >> >> >> >> > ------------------------------------------------------------------------------ > > > >> _______________________________________________ Fail2ban-users >> mailing list Fai...@li... > <mailto:Fai...@li...> >> <mailto:Fai...@li... > <mailto:Fai...@li...>> >> https://lists.sourceforge.net/lists/listinfo/fail2ban-users >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Fail2ban-users mailing list Fai...@li... > <mailto:Fai...@li...> > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ Fail2ban-users > mailing list Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPD+UAAoJEJPfMZ19VO/134IQAM6wXi8HvQJuh8iUo4OyrzVl KtQpNAtddbs2clhS9wlcN4rDKMEaDY4RL8aSzxKVRWCJHRfNMBYiyGyaRMkd0bWs Gm+znsp1JRVlhyhpY3TlHmT7YTdUz62qW1rCcBOFkVV5RGjMpCcK0EdfSqe/rETt /dYBDt4S9NSNRGhLcVtBtV+3SspMEFSmUY1VfqPVtoU4tMfRjXCqfOHVM+FC9Wtj 49x5NgIsBAbPg+agTQqTu+IzkDZePtMxipEatt5PruHCoFUmlcyBcvUXtLBBLOkM VV4ObL2Mpx9/qvCSfV2d/brxaMbeOIcryeeLXkxgsBr0atLScYl9CHet8TTmPbgP gnkuQ4OrOLIoXCSHWBtU9uVsRPM6JZeEqdV70EbF0eThzprS1W9XZlj+87YE/FX5 DFJZkymrVM2hES0RJj5BrTeEq4AyEPmQdeWTI1M2FaZHvNL2WPlI0rNuZeUz5Fgs yFsM7E+g8o+cgM/Z7SARkIkSthd14ybQIJ/VUAch7bth2IxUQXhXNZr0KruVjij6 vetEgXywh8/utVubx51hQpUDq8uY0MDe46rNHDN5S0exrmFwNVfcvuRTH1rQDFhc jYBAxuhY68hKLhfu6Q62RHz9BuAlHrzDUCJm2BPtl/wzOgnK+t977B3NRFuxy+W5 JGf1GBtRdwwNyoLPkeQp =JEMy -----END PGP SIGNATURE----- |
From: Steven H. <ste...@hi...> - 2014-04-02 17:19:00
|
On 02/04/14 17:49, Tom Hendrikx wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > The PR is ok, but the contents arentt (yet). The tests just make sure > that it's easy to spot errors. Your PR seems to miss a log snippet > that can be used to test if the jail actually works. Some > documentation on how things should look like: > https://github.com/fail2ban/fail2ban/blob/master/FILTERS > > If you run into issues, post the logs here, we'll help you. :) > > Tom > I probably should have posted this earlier, but the development documents are now on readthedocs.org, which may be a bit easier to read. ☺ http://fail2ban.readthedocs.org/en/latest/filters.html#samples -- Steven Hiscocks |
From: Vik K. <vip...@gm...> - 2014-04-02 17:19:37
|
My goal is not to get this committed to code-base. As I said before the setup most likely need refinement. I tested it and it works. I only wanted to share it as a resource where it could be edited by others which is why I just wanted to post it on wiki for others... How can I get a wiki account? Thanks On Wed, Apr 2, 2014 at 12:49 PM, Tom Hendrikx <to...@wh...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > The PR is ok, but the contents arentt (yet). The tests just make sure > that it's easy to spot errors. Your PR seems to miss a log snippet > that can be used to test if the jail actually works. Some > documentation on how things should look like: > https://github.com/fail2ban/fail2ban/blob/master/FILTERS > > If you run into issues, post the logs here, we'll help you. :) > > Tom > > On 02-04-14 17:33, Vik Killa wrote: > > Looks like my pull request failed...lol this is why i prefer just > > adding to wiki > > https://travis-ci.org/fail2ban/fail2ban/builds/22111129 > > > > > > > > On Wed, Apr 2, 2014 at 11:13 AM, Vik Killa <vip...@gm... > > <mailto:vip...@gm...>> wrote: > > > > > > Sorry, I thought i was replying to list.... I just signed up for > > github, i think i did it correctly... > > https://github.com/fail2ban/fail2ban/pull/677 > > > > Thanks > > > > > > On Wed, Apr 2, 2014 at 10:54 AM, Tom Hendrikx <to...@wh... > > <mailto:to...@wh...>> wrote: > > > > > > Hi Vik, > > > > please keep replies on-list... > > > > Just put it in github, it's easy to clean it up there. I'll take a > > look at it when it's there. But a wiki is no coding platform :) > > > > Tom > > > > On 04/02/2014 04:48 PM, Vik Killa wrote: > >> I think it could stand to be "cleaned up" as I am no expert > > with regex > >> and fail2ban... I'd rather post it on wiki and have someone else > >> push it to > > GIT after > >> it's been a bit refined... Thanks > >> > >> > >> > >> On Wed, Apr 2, 2014 at 10:40 AM, Tom Hendrikx > > <to...@wh... <mailto:to...@wh...> > >> <mailto:to...@wh... <mailto:to...@wh...>>> wrote: > >> > >> > >> Hi, > >> > >> You should put the jail/config stuff in a github pull > > request I think. > >> then everybody can actually use it:) > >> > >> Tom > >> > >> On 04/02/2014 04:36 PM, Vik Killa wrote: > >>> new version of BIND has RRL for rate-limiting. in any case, > >>> i've written a jail and configuration for > > bind9 that > >>> protects against DDoS attacks. I'd like to post it on wiki. Can > >>> someone help me with setting up an account on the > > fail2ban wiki? > >>> Thanks > >>> > >>> > >>> > >>> On Tue, Jul 24, 2012 at 3:38 AM, Fabian Wenk > > <fa...@we... <mailto:fa...@we...> > >> <mailto:fa...@we... <mailto:fa...@we...>> > >>> <mailto:fa...@we... <mailto:fa...@we...> > > <mailto:fa...@we... <mailto:fa...@we...>>>> wrote: > >>> > >>> Hello Yaroslav > >>> > >>> On 24.07.2012 00 <tel:24.07.2012%2000> > > <tel:24.07.2012%2000> > >> <tel:24.07.2012%2000>:57, Yaroslav Halchenko wrote: > >>>> just for the sake of my own education: am I not > > correct > >> that use of > >>>> DNSSEC practically implies use of TCP due to large > > packet > >> sizes, thus > >>>> actually an additional difficulty of spoofing, > > thus such an > >> attack > >>> would > >>>> be actually more difficult to accomplish... ? > >>> > >>> I do not know such details about DNSSEC, but without > > DNSSEC the > >>> DNS server does use TCP, if the answer is to large > > for one packet > >>> (1500 bytes including IP headers). In this case the > > server ask > >>> the resolver back through UDP to redo the request > > through TCP. > >>> But currently there are to many possible requests > > through UDP > >>> with just a small request, e.g. for ANY, which > > usually gives in > >>> proportion a much larger (but less then 1500 byte) > > answer. > >>> > >>> About 3 years ago there was an attack with IN NS > > requests for the > >>> . (root) zone, which BIND has answered, even when it > > was not > >>> configured for recursion from the outside world. In > > this case the > >>> request is very small, but the answer is quite large > > (but still > >>> fits into one packet) with all the hostnames and IP > > addresses for > >>> the root nameserver from a to m. > >>> > >>> If requests with a faked source IP address would be > > done from > >>> many systems (a bot net) to a lot of non-involved > > DNS server, > >>> then the attacked IP address will get a lot more > > data traffic > >>> with the answers from all this non-involved DNS > > server. So it is > >>> a good idea to detect such abuse and block it, so > > your DNS server > >>> will not be part of this attack. > >>> > >>> It is very sad, that many ISPs do not implement best > > practice and > >>> only allow outbound traffic with source IP address > > from their own > >>> and customer IP ranges. If they would do it, such > > attacks would > >>> not be possible, or at least limited to the same ISP. > >>> > >>> BIND does not have any kind of rate limiting, but > > probably this > >>> is for good, as a lot of things will break when a > > DNS server does > >>> not answer the requests from legitimate clients. The > > only thing > >>> which safely could be blocked are DNS requests for > > IN ANY (use a > >>> reasonable maxretry and short findtime), as there is > > no technical > >>> reason for such requests. As far as I know, this are > > only manual > >>> request done from humans to debug a domain. Also > > blocking request > >>> for domains, for which your DNS server is not > > authoritative, is > >>> safe to do. Use it also with a reasonable maxretry > > and short > >>> findtime so that at least a few NX answers can get back. > >>> > >>> > >>> bye Fabian > >>> > >>> > >> > > > ------------------------------------------------------------------------------ > > > > > >> Live Security Virtual Conference > >>> Exclusive live event will cover all the ways today's > > security and > >>> threat landscape has changed and how IT managers can > > respond. > >>> Discussions will include endpoint security, mobile security > >>> and > > the latest in > >>> malware threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >>> _______________________________________________ Fail2ban-users > >>> mailing list Fai...@li... > > <mailto:Fai...@li...> > >> <mailto:Fai...@li... > > <mailto:Fai...@li...>> > >>> <mailto:Fai...@li... > > <mailto:Fai...@li...> > >> <mailto:Fai...@li... > > <mailto:Fai...@li...>>> > >>> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > >>> > >>> > >>> > >>> > >>> > >> > > > ------------------------------------------------------------------------------ > > > > > >> > >>> > >>> > >>> _______________________________________________ Fail2ban-users > >>> mailing list Fai...@li... > > <mailto:Fai...@li...> > >> <mailto:Fai...@li... > > <mailto:Fai...@li...>> > >>> https://lists.sourceforge.net/lists/listinfo/fail2ban-users > >>> > >> > >> > >> > >> > > > ------------------------------------------------------------------------------ > > > > > > > >> _______________________________________________ Fail2ban-users > >> mailing list Fai...@li... > > <mailto:Fai...@li...> > >> <mailto:Fai...@li... > > <mailto:Fai...@li...>> > >> https://lists.sourceforge.net/lists/listinfo/fail2ban-users > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > > Fail2ban-users mailing list Fai...@li... > > <mailto:Fai...@li...> > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ Fail2ban-users > > mailing list Fai...@li... > > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJTPD+UAAoJEJPfMZ19VO/134IQAM6wXi8HvQJuh8iUo4OyrzVl > KtQpNAtddbs2clhS9wlcN4rDKMEaDY4RL8aSzxKVRWCJHRfNMBYiyGyaRMkd0bWs > Gm+znsp1JRVlhyhpY3TlHmT7YTdUz62qW1rCcBOFkVV5RGjMpCcK0EdfSqe/rETt > /dYBDt4S9NSNRGhLcVtBtV+3SspMEFSmUY1VfqPVtoU4tMfRjXCqfOHVM+FC9Wtj > 49x5NgIsBAbPg+agTQqTu+IzkDZePtMxipEatt5PruHCoFUmlcyBcvUXtLBBLOkM > VV4ObL2Mpx9/qvCSfV2d/brxaMbeOIcryeeLXkxgsBr0atLScYl9CHet8TTmPbgP > gnkuQ4OrOLIoXCSHWBtU9uVsRPM6JZeEqdV70EbF0eThzprS1W9XZlj+87YE/FX5 > DFJZkymrVM2hES0RJj5BrTeEq4AyEPmQdeWTI1M2FaZHvNL2WPlI0rNuZeUz5Fgs > yFsM7E+g8o+cgM/Z7SARkIkSthd14ybQIJ/VUAch7bth2IxUQXhXNZr0KruVjij6 > vetEgXywh8/utVubx51hQpUDq8uY0MDe46rNHDN5S0exrmFwNVfcvuRTH1rQDFhc > jYBAxuhY68hKLhfu6Q62RHz9BuAlHrzDUCJm2BPtl/wzOgnK+t977B3NRFuxy+W5 > JGf1GBtRdwwNyoLPkeQp > =JEMy > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > _______________________________________________ > Fail2ban-users mailing list > Fai...@li... > https://lists.sourceforge.net/lists/listinfo/fail2ban-users > |