Re: Safe bruteforce rule for mobile-friendly website

2013-02-08 Thread Mikkel Bang
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

2013-02-07 Thread 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

2013-02-07 Thread 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

2013-02-07 Thread Mikkel Bang
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

2013-02-06 Thread 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

2013-02-06 Thread Jan Stary
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-02-06 Thread Michał Markowski
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

2013-02-06 Thread Mikkel Bang
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!