Re: synproxy and RST (non-listener)
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.
Re: synproxy and RST (non-listener)
* 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.
Re: synproxy and RST (non-listener)
* Nerius Landys lan...@nerius.com [2010-10-20 22:30]: Is there a way to get synproxy to send the RST (I _think_ that's what it is called) when no service is running on that port? Or is this a feature? Or is there a reason it behaves this way? Intentional, bug, oversight, or missing modifier to my rule? Hrm I think, after doing a little bit more research, I understand why this isn't possible. Maybe you can tell me if I'm right. Seems that synproxy completes a TCP connect handshake completely with the client before even sending anything to the actual service it's proxying. This is the whole purpose of synproxy. So, it has a completed handshake, the client thinks he's connected, and pf tries to connect to the underlying service, but receives an RST or whatnot, which means the service isn't running. It's probably too late to send an RST to the client at this point, so pf just lets the connection from the client hang. that's about right I suppose there's not way to get around this problem... right. Maybe ask the operating system if the port is bound before completing the handshake with the client, otherwise send RST to the client? askin before isn't possible. you do not know that the backend will accept a connection based on a previous connection being accepted. and doing a check before replying with a syn defeats the prupose anyway. sending an RST back if the backend doesn't accept the connection, well, we could do that, but it still doesn't solve anything - clients treat established connection terminated very differently then connection not accepted. there is no way to solve this. synproxy is not for everyday use. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: synproxy and RST (non-listener)
Is there a way to get synproxy to send the RST (I _think_ that's what it is called) when no service is running on that port? Or is this a feature? Or is there a reason it behaves this way? Intentional, bug, oversight, or missing modifier to my rule? Hrm I think, after doing a little bit more research, I understand why this isn't possible. Maybe you can tell me if I'm right. Seems that synproxy completes a TCP connect handshake completely with the client before even sending anything to the actual service it's proxying. This is the whole purpose of synproxy. So, it has a completed handshake, the client thinks he's connected, and pf tries to connect to the underlying service, but receives an RST or whatnot, which means the service isn't running. It's probably too late to send an RST to the client at this point, so pf just lets the connection from the client hang. I suppose there's not way to get around this problem... Any thoughts? Maybe ask the operating system if the port is bound before completing the handshake with the client, otherwise send RST to the client?
