Re: Safe bruteforce rule for mobile-friendly website
So is there any point in having bruteforce for httpd? Especially now that "mobile is the future"? Mikkel 2013/2/7 Mikkel Bang > > I forget if mobiles do more prefetching on dns and/or tcp on mobiles but > > perhaps that's worth considering as a culprit. > > My God Kevin, that's gotta be it! > > > Does the page have more than 15 links? > > Yep, like 16-17 or so :) > > Mikkel > > > 2013/2/7 Kevin Chadwick > >> > I had to disable it as soon as I found out so the relevant logs are >> > probably too far up the buffer, but I'll set up a test server ASAP and >> > study the tcpdump in detail. >> >> I forget if mobiles do more prefetching on dns and/or tcp on mobiles but >> perhaps that's worth considering as a culprit. >> >> Does the page have more than 15 links? >> >> -- >> ___ >> >> 'Write programs that do one thing and do it well. Write programs to work >> together. Write programs to handle text streams, because that is a >> universal interface' >> >> (Doug McIlroy) >> ___
Re: Safe bruteforce rule for mobile-friendly website
> I forget if mobiles do more prefetching on dns and/or tcp on mobiles but > perhaps that's worth considering as a culprit. My God Kevin, that's gotta be it! > Does the page have more than 15 links? Yep, like 16-17 or so :) Mikkel 2013/2/7 Kevin Chadwick > > I had to disable it as soon as I found out so the relevant logs are > > probably too far up the buffer, but I'll set up a test server ASAP and > > study the tcpdump in detail. > > I forget if mobiles do more prefetching on dns and/or tcp on mobiles but > perhaps that's worth considering as a culprit. > > Does the page have more than 15 links? > > -- > ___ > > 'Write programs that do one thing and do it well. Write programs to work > together. Write programs to handle text streams, because that is a > universal interface' > > (Doug McIlroy) > ___
Re: Safe bruteforce rule for mobile-friendly website
> I had to disable it as soon as I found out so the relevant logs are > probably too far up the buffer, but I'll set up a test server ASAP and > study the tcpdump in detail. I forget if mobiles do more prefetching on dns and/or tcp on mobiles but perhaps that's worth considering as a culprit. Does the page have more than 15 links? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: Safe bruteforce rule for mobile-friendly website
Thanks guys! I had to disable it as soon as I found out so the relevant logs are probably too far up the buffer, but I'll set up a test server ASAP and study the tcpdump in detail. > Somehow your mobiles hit either the fifteen new connections per five > seconds max (that's only three new connections per second) or the 100 > simultaneous connections. Impossible to say which one without studying > the actual session data via tcpdump. Unless the back end is too brittle, > consider loosening the rate limiting or discarding it altogether. > > You could try temporarily removing either the max-src-conn or the > max-src-conn-rate setting to see which one trips up the mobiles. Basically it's a social network geared towards teens, who tend to use mobile for everything. I'm guessing properly designed spam bots would go slow and at random intervals, so I'm not so sure how effective bruteforce for httpd would actually be? > Do you want to block >15/5 clients? I'm not so sure anymore. > Possibly relevant question: do all clients receive the same content, or > is there a separate version you serve to mobile clients? Currently it's all the same content. I'm planning to use Nginx to redirect to a dedicated mobile site later on though. Thank you! Mikkel 2013/2/6 Peter N. M. Hansteen > Mikkel Bang writes: > > > Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) > bans > > any IP connecting from mobile devices: > > Well, that document says a lot of other stuff too, so please be more > specific. > > > pass in on $ext_if inet proto tcp from any to any port 80 keep state > > (max-src-conn 100, max-src-conn-rate 15/5, overload flush > > global) > > > > Works fine when connecting from regular PCs though. Why is that? Do > mobile > > devices connect differently somehow? > > Somehow your mobiles hit either the fifteen new connections per five > seconds max (that's only three new connections per second) or the 100 > simultaneous connections. Impossible to say which one without studying > the actual session data via tcpdump. Unless the back end is too brittle, > consider loosening the rate limiting or discarding it altogether. > > You could try temporarily removing either the max-src-conn or the > max-src-conn-rate setting to see which one trips up the mobiles. > > Possibly relevant question: do all clients receive the same content, or > is there a separate version you serve to mobile clients? > > - P > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Safe bruteforce rule for mobile-friendly website
Mikkel Bang writes: > Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans > any IP connecting from mobile devices: Well, that document says a lot of other stuff too, so please be more specific. > pass in on $ext_if inet proto tcp from any to any port 80 keep state > (max-src-conn 100, max-src-conn-rate 15/5, overload flush > global) > > Works fine when connecting from regular PCs though. Why is that? Do mobile > devices connect differently somehow? Somehow your mobiles hit either the fifteen new connections per five seconds max (that's only three new connections per second) or the 100 simultaneous connections. Impossible to say which one without studying the actual session data via tcpdump. Unless the back end is too brittle, consider loosening the rate limiting or discarding it altogether. You could try temporarily removing either the max-src-conn or the max-src-conn-rate setting to see which one trips up the mobiles. Possibly relevant question: do all clients receive the same content, or is there a separate version you serve to mobile clients? - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Safe bruteforce rule for mobile-friendly website
On Feb 06 21:52:20, facebookman...@gmail.com wrote: > Hi, > > Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans > any IP connecting from mobile devices: > > pass in on $ext_if inet proto tcp from any to any port 80 keep state > (max-src-conn 100, max-src-conn-rate 15/5, overload flush > global) > Works fine when connecting from regular PCs though. Why is that? Do mobile > devices connect differently somehow? tcpdump such a session to see what kind of connection your mobile device does to port 80; my android's browser for example goes over 15/5 like nothing. > And can someone recommend a mobile-friendly bruteforce rule for port 80? It depends on your situation entirely. Do you want to block >15/5 clients?
Re: Safe bruteforce rule for mobile-friendly website
2013/2/6 Mikkel Bang : > Works fine when connecting from regular PCs though. Why is that? Do mobile > devices connect differently somehow? Start in /var/log, I suppose. -- Michał Markowski
Safe bruteforce rule for mobile-friendly website
Hi, Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans any IP connecting from mobile devices: pass in on $ext_if inet proto tcp from any to any port 80 keep state (max-src-conn 100, max-src-conn-rate 15/5, overload flush global) Works fine when connecting from regular PCs though. Why is that? Do mobile devices connect differently somehow? And can someone recommend a mobile-friendly bruteforce rule for port 80? Thanks!
