* Max Laier <[EMAIL PROTECTED]> [2008-12-04 18:28:33 +0100]: > On Thursday 04 December 2008 16:47:13 Max Laier wrote: > > On Thursday 04 December 2008 16:24:23 Vladimir Ermakov wrote: > > > problem is fixed in OpenBSD 4.4 > > > http://www.openbsd.org/plus44.html > > > > The bug this note refers to was introduced after OpenBSD 4.1 (our last > > import) and should not be present in the FreeBSD code. I'll double check > > in a bit to make sure synproxy is working, but I don't think it was broken > > after my last import ... do you have a particular test case that I could > > reproduce? > > Okay ... here is the story: First off, "synproxy state" is *NOT* broken! > But > you need to be careful how you use it. If you - like the OP - intend to use > it to protect a service running on the same box as your pf, you must make > sure > to "set skip on lo0" or it will not work. If you are protecting a box behind > the pf box, there is no need for that.
Without getting too far off-topic here. I personally find synproxy (or any stateful firewall for that matter) useless. The idea behind synproxy is to protect the actual server from a SYN-flood, which would cause all sockets to be filled up and the service would be unavailable. With this "protection" enabled, you simply limit the amount of SYN packets to respond to, to the amount of what your state-table allow. When the state-table is full, you're service will still be unavailable. During my personal testing, I could easily make a service hosted on a machine with a gigabit connection unavailable with approximenty 250kb/s of SYN-packets with random source addresses, using some lines of simple perl code. I would rather suggest using the "no state" option and use syncookies, as it's *way* more effective against this kind of attack. You can easily limit the outbound traffic using altq if needed. Using synstate will only make the real users fight against the attacker for an open spot in the states-table, where an attacker easily can create ~200k states a sec, using very little bandwidth. (note that pf's default size of the states-table is 10000) I would love if someone (I would do it myself if I had the knowledge of C/C++) could add some sort of "syn-cookies + pf" support, where pf took advantage of the syn-cookie feature when deciding if the states-table is full or not. Making it responding with SYN/ACK's even if the states-table is full, and use the syn-cookies algorithm when an ACK is recieved, and re-add the SYN-state into the table if the syn-cookie is valid. Regards, Jesper Wallin ps, seems like I forgot to forward this to the list. ;-) _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
