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. > OK I may already know the reason why this isn't an elegant idea, and > correct me if I'm wrong. The synproxy could be proxying a > connection to another host (meaning my service listening on port > 8080 is running on a _different_ host than the pf machine). This is the main use-case that synproxy is intended for. Protecting other machines from resource exhaustion caused by an excess of uncompleted 3-way handshakes. > For example, let's say pf is configured to forward port 8080 to an > internal machine (like 192.168.0.2) that is running a service on port > 8080. Then, there is no way of predicting whether there is a service > running on port 8080 on that internal machine. Am I thinking along > clear lines here or am I missing something? This is correct. 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.
