🚀 go-pugleaf

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.