* Ryan McBride <mcbr...@openbsd.org> [2010-10-23 11:56]: > On Sat, Oct 23, 2010 at 02:51:11AM +0300, Nerius Landys wrote: > > Thanks for the reply. But I don't _completely_ understand. I don't > > know too much about operating system calls, but let's say that I > > have a program that is bound to TCP port 8080 on my local machine > > (same machine that is running the pf in question). Let's say I > > launch another program that tries to listen on this port as well. > > Of course it will fail with "cannot bind to port" or something like > > that. So there _is_ something the operating system tells us > > regarding a > > port being bound on the local system, and this [presumably] does not > > require any packets to be sent. Could we do a similar check before > > completing a handshake with a client via synproxy? > > Yes, in the case where the synproxy rule is protecting connections to > a local machine, in theory PF could be modified to check whether there is > a service listening on that port. It would be a lot of code for not much > benefit, though.
last not least because "something listening" does not necessarily imply "will accept a connection". > To be 100% clear, the simplest solution to the synproxy problem you've > described is this: Don't use synproxy if you aren't sure that there will > be a service listening on the port. I'd go further - synproxy isn't there for everyday use, but as a temporarily measure when you're under attack and the synproxy shortcoming are the smaller problem. and for your subscription issues - I strongly believe the right mailing list is m...@openbsd.org anyway.
