Re: Safe bruteforce rule for mobile-friendly website

[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

[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

[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.

Safe bruteforce rule for mobile-friendly website

[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!

Re: 5.2 PRE-ORDERS

[Mikkel Bang]

Can't you just put up a Spree shop or something? I'd like some cups
and stickers too, and maybe a teddybear version of that fish for my
kid. Some OpenBSD underwear for the wife would be great too.

Thanks.

Mikkel

2012/10/7 OpenBSD Europe :
> Excellent - if you need anything just let us know :-)
>
>
> mxb wrote:
>>
>> Great!
>>
>> I'll push my management to place an order.
>>
>> On 5 okt 2012, at 12:15, OpenBSD Europe  wrote:
>>
>>> We will be making the shipment from Canada soon. If you would like your
>>> 5.2 on time we request the orders ASAP :-)
>>>
>>> Thanks folks!

Re: More sensible and consistent rc.conf.local

[Mikkel Bang]

I'm just thinking that from a layman's perspective named_flags=""
doesn't make as much sense as named=YES if all you want to do is start
named.

The way it is right now seems more like monkey patching from the days
before OpenBSD became popular. I acknowledge the whole "it's been like
this for ages", but it's 2012 - it's time to make some power moves.

If OpenBSD was on Git / at GitHub, youngins like me would have patched
this baby up a long time ago.

Mikkel

2012/8/29 Stuart Henderson :
> On 2012-08-25, Mikkel Bang  wrote:
>> Hello!
>>
>> Is there a way to make my rc.conf.local more sensible and consistent, i.e. 
>> not
>>
>> pf=YES
>> sshd=""
>> named_flags=""
>>
>> but rather
>>
>> pf=YES
>> sshd=YES
>> named=YES?
>
> How about something like this?
>
> # system options
> pf=YES
>
> # daemons
> sshd_flags=""
> named_flags=""

More sensible and consistent rc.conf.local

[Mikkel Bang]

Hello!

Is there a way to make my rc.conf.local more sensible and consistent, i.e. not

pf=YES
sshd=""
named_flags=""

but rather

pf=YES
sshd=YES
named=YES?

Thanks!

Mikkel

Re: OpenBSD init script (rails+nginx+unicorn)

[Mikkel Bang]

For what it's worth, here she is:

https://gist.github.com/3447050

the Linux version sure is jealous now :-)

Mikkel

2012/8/24 Mikkel Bang 

> Can/should this init script be rewritten/simplified for OpenBSD?
>
> https://gist.github.com/3447050 (an application-specific init 
> script<http://blog.kiskolabs.com/post/722322392/unicorn-init-scripts>for a
> rails+nginx+unicorn <http://sirupsen.com/setting-up-unicorn-with-nginx/>
>  setup)
>
> I like how OpenBSD's init scripts reuse /etc/rc.d/rc.subr, but is this
> possible in my case?
>
> Thanks!
>
> Mikkel

OpenBSD init script (rails+nginx+unicorn)

[Mikkel Bang]

Can/should this init script be rewritten/simplified for OpenBSD?

https://gist.github.com/3447050 (an application-specific init
scriptfor
a
rails+nginx+unicorn 
 setup)

I like how OpenBSD's init scripts reuse /etc/rc.d/rc.subr, but is this
possible in my case?

Thanks!

Mikkel

NSD vs BIND

[Mikkel Bang]

Hello!

For authoritative nameservers - which do you guys prefer, NSD or BIND?

I've been using BIND all these years, but after Googling around, NSD seems
extremely attractive. Plus it follows BIND's zonefile format so I don't
really have to redesign my configs, how about that?

Mikkel

Re: The ultimate OpenBSD email server

[Mikkel Bang]

2012/8/15 Peter N. M. Hansteen 

>
> I beg to differ. spamd(8) in any configuration is a lot more lightweight
> than
> content filtering. You most likely will need content filtering in addition
> to greylisting+greytrapping, but stopping them earlier is a real plus.
> See eg http://undeadly.org/cgi?action=article&sid=20120604050025


Thanks a lot Peter. I forwarded your spamd article to the DSPAM guys and
they gave it tons of praise.

So here it is, OpenBSD + postfix-anti-UCE.txt + undeadly's spamd setup +
dspam:

https://gist.github.com/3417519

Feedback would be much appreciated.

Thanks!

Mikkel

The ultimate OpenBSD email server

[Mikkel Bang]

I'm trying to configure "the ultimate email server" for this webapp that
needs to send and receive / forward emails to and from thousands of users.

But with so many people recommending so many different tools, it gets hard
to come to a conclusion. Looks like I'm finally arriving at this though:
postfix (postfix-anti-UCE.txt) + dspam - what do you guys think?

Dropped:

- postscreen: Looked into http://www.postfix.org/POSTSCREEN_README.html but
couldn't really find anything concrete to add to my setup
- postgrey: Advised against by the dudes in Freenode #postfix - I've tried
it before and it was really effective, but I don't think my users will like
that 5 minute delay
- opendkim+spf+dmarc: Advised against by the dudes in Freenode ##freebsd,
saying its role in anti-spam protection is minimal
- spamassassin: Too old, too huge and too hard to set up (but maybe those
who advised against it had more against Perl than anything else)
- spamdb+greytrapping: Not necessary if I'm already running dspam
- mailscanner: Not necessary if I'm already running dspam

Mikkel