2.6.20: ipt_owner match and INPUT chain

2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

Hello together,

the ipt_owner match of 2.6.20 is not allowed to be used in the INPUT chain. 

The .hooks entry looks like this:
.hooks          = (1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING)

Back in the days it was allowed to be used in the INPUT chain for TCP/UDP.
I've searched the mailinglist archive but couldn't find anything useful.
What's the reason behind the change?

Cheers,
Thomas

Re: 2.6.20: ipt_owner match and INPUT chain

[Patrick McHardy]

Thomas Jarosch wrote:
> Hello together,
> 
> the ipt_owner match of 2.6.20 is not allowed to be used in the INPUT chain. 
> 
> The .hooks entry looks like this:
> .hooks          = (1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING)
> 
> Back in the days it was allowed to be used in the INPUT chain for TCP/UDP.
> I've searched the mailinglist archive but couldn't find anything useful.
> What's the reason behind the change?

The mainline kernel never supported this, you're thinking of the
owner socketlookup patch, which had multiple issues and was never
merged.

Re: 2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

Hello Patrick,

On Friday, 2. March 2007, Patrick McHardy wrote:
> > the ipt_owner match of 2.6.20 is not allowed to be used in the INPUT
> > chain.
> >
> > The .hooks entry looks like this:
> > .hooks          = (1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING)
> >
> > Back in the days it was allowed to be used in the INPUT chain for
> > TCP/UDP. I've searched the mailinglist archive but couldn't find anything
> > useful. What's the reason behind the change?
>
> The mainline kernel never supported this, you're thinking of the
> owner socketlookup patch, which had multiple issues and was never
> merged.

Thanks for your reply. You're right, on 2.4 I've applied the socketlookup 
patch. I use it to accept incoming connections for a socks v5 proxy.

Socks allows a client to bind a port on the external IP of the server
and then wait for an incoming connection. Would it make sense to write a 
conntrack module which parses the communication between socks client and 
server and then adds the incoming connection to conntrack?

The easier solution would be to patch the socks server to execute a script
if the client requests to bind a port on the server. The connection could be 
added via the userspace conntrack tool, right?

Cheers,
Thomas

Re: 2.6.20: ipt_owner match and INPUT chain

[Patrick McHardy]

Thomas Jarosch wrote:
> Hello Patrick,
> 
> On Friday, 2. March 2007, Patrick McHardy wrote:
> 
>>The mainline kernel never supported this, you're thinking of the
>>owner socketlookup patch, which had multiple issues and was never
>>merged.
> 
> 
> Thanks for your reply. You're right, on 2.4 I've applied the socketlookup 
> patch. I use it to accept incoming connections for a socks v5 proxy.
> 
> Socks allows a client to bind a port on the external IP of the server
> and then wait for an incoming connection. Would it make sense to write a 
> conntrack module which parses the communication between socks client and 
> server and then adds the incoming connection to conntrack?

Not sure if its worth the effort. It also doesn't seem to fit the helper
model really well since the expectation is only relevant for the proxy
itself, not for the firewalls in between. Or does the proxy open a new
connection to the client when an external connection arrives?

> The easier solution would be to patch the socks server to execute a script
> if the client requests to bind a port on the server. The connection could be 
> added via the userspace conntrack tool, right?

That should work. We could also add support for helperless expectations
for this, which will properly deal with NAT automatically.

Re: 2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

Hi Patrick,

On Saturday, 3. March 2007, Patrick McHardy wrote:
> > Socks allows a client to bind a port on the external IP of the server
> > and then wait for an incoming connection. Would it make sense to write a
> > conntrack module which parses the communication between socks client and
> > server and then adds the incoming connection to conntrack?
>
> Not sure if its worth the effort. It also doesn't seem to fit the helper
> model really well since the expectation is only relevant for the proxy
> itself, not for the firewalls in between. Or does the proxy open a new
> connection to the client when an external connection arrives?

The data gets passed over the existing connection. But you are right,
it's only useful if the proxy runs on the same machine. For socks
servers this is not uncommon, though the effort is not worth it.

> > The easier solution would be to patch the socks server to execute a
> > script if the client requests to bind a port on the server. The
> > connection could be added via the userspace conntrack tool, right?
>
> That should work. We could also add support for helperless expectations
> for this, which will properly deal with NAT automatically.

I'm not sure if I understand you correctly, shouldn't it already be possible 
to add an expectation via "conntrack -I expect"?

Another idea came to my mind today: If the socks server needs to be patched 
anyway, would it be useful to set a connmark via an ioctl on the socket?
Normal firewall rules could then be used for incoming and especially
outgoing connections from the socks server.

Cheers,
Thomas

Re: 2.6.20: ipt_owner match and INPUT chain

[Patrick McHardy]

Thomas Jarosch wrote:
> On Saturday, 3. March 2007, Patrick McHardy wrote:
> 
>>>The easier solution would be to patch the socks server to execute a
>>>script if the client requests to bind a port on the server. The
>>>connection could be added via the userspace conntrack tool, right?
>>
>>That should work. We could also add support for helperless expectations
>>for this, which will properly deal with NAT automatically.
> 
> 
> I'm not sure if I understand you correctly, shouldn't it already be possible 
> to add an expectation via "conntrack -I expect"?

Yes, but currently expectations always need a master connection
with a helper assigned.

> Another idea came to my mind today: If the socks server needs to be patched 
> anyway, would it be useful to set a connmark via an ioctl on the socket?

connmark isn't possible since the sending side of the socket
only deals with packets before the have been associated with
a conntrack entry. But you could use normal marks, IIRC
Balazs Scheidler <bazsi@balabit.hu> posted a patch for this
to netdev about 1.5 years ago.

> Normal firewall rules could then be used for incoming and especially
> outgoing connections from the socks server.

Incoming connections don't work, the receiving socket is not known
while the packet is handled by netfilter.

Re: 2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

Hello Patrick,

On Monday, 5. March 2007, you wrote:
> > I'm not sure if I understand you correctly, shouldn't it already be
> > possible to add an expectation via "conntrack -I expect"?
>
> Yes, but currently expectations always need a master connection
> with a helper assigned.

Thanks for clearing this up. Is this change easy to do, like it would
take you ten minutes or is it a more complex task?

> > Another idea came to my mind today: If the socks server needs to be
> > patched anyway, would it be useful to set a connmark via an ioctl on the
> > socket?
>
> connmark isn't possible since the sending side of the socket
> only deals with packets before the have been associated with
> a conntrack entry. But you could use normal marks, IIRC
> Balazs Scheidler <bazsi@balabit.hu> posted a patch for this
> to netdev about 1.5 years ago.

I was unable to find the patch, too bad the lovely patchwork system wasn't in 
place at that time. Anyway, ipt_owner works for outgoing connections so after 
giving it another thought it a) already works b) is one patch less to the 
socks proxy -> ipt_owner is fine for this.

> > Normal firewall rules could then be used for incoming and especially
> > outgoing connections from the socks server.
>
> Incoming connections don't work, the receiving socket is not known
> while the packet is handled by netfilter.

Ok, thanks.

I'm still wondering how other people are running a socks server
together with an iptables firewall. I can't imagine
they leave all incoming ports open...

Cheers,
Thomas

Re: 2.6.20: ipt_owner match and INPUT chain

[Patrick McHardy]

Thomas Jarosch wrote:
> Hello Patrick,
> 
> On Monday, 5. March 2007, you wrote:
> 
>>>I'm not sure if I understand you correctly, shouldn't it already be
>>>possible to add an expectation via "conntrack -I expect"?
>>
>>Yes, but currently expectations always need a master connection
>>with a helper assigned.
> 
> 
> Thanks for clearing this up. Is this change easy to do, like it would
> take you ten minutes or is it a more complex task?

Without having looked into this in detail, I guess it should be
in the tens of minutes range. We need this anyway for state
synchronization since the H.323 helper manually assigns
unregistered helpers to its children.

>>>Another idea came to my mind today: If the socks server needs to be
>>>patched anyway, would it be useful to set a connmark via an ioctl on the
>>>socket?
>>
>>connmark isn't possible since the sending side of the socket
>>only deals with packets before the have been associated with
>>a conntrack entry. But you could use normal marks, IIRC
>>Balazs Scheidler <bazsi@balabit.hu> posted a patch for this
>>to netdev about 1.5 years ago.
> 
> 
> I was unable to find the patch, too bad the lovely patchwork system wasn't in 
> place at that time. Anyway, ipt_owner works for outgoing connections so after 
> giving it another thought it a) already works b) is one patch less to the 
> socks proxy -> ipt_owner is fine for this.

Great. Just for reference, this is the patch I was talking about:

http://marc.theaimsgroup.com/?l=linux-netdev&m=112870885111441&w=4

> I'm still wondering how other people are running a socks server
> together with an iptables firewall. I can't imagine
> they leave all incoming ports open...

I have no idea. I can only assume most people simply don't allow
users to open their own external ports on a firewall at all.

Re: 2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

On Thursday, 8. March 2007, Patrick McHardy wrote:
> > Thanks for clearing this up. Is this change easy to do, like it would
> > take you ten minutes or is it a more complex task?
>
> Without having looked into this in detail, I guess it should be
> in the tens of minutes range. We need this anyway for state
> synchronization since the H.323 helper manually assigns
> unregistered helpers to its children.

Do expectations always need an associated conntrack entry
or could they be added as orphans? I can imagine it will be
quite difficult for the shell script to find
the correct client<->socks server conntrack.

> Great. Just for reference, this is the patch I was talking about:
>
> http://marc.theaimsgroup.com/?l=linux-netdev&m=112870885111441&w=4

Grrr, I really searched for the patch... :-)

> > I'm still wondering how other people are running a socks server
> > together with an iptables firewall. I can't imagine
> > they leave all incoming ports open...
>
> I have no idea. I can only assume most people simply don't allow
> users to open their own external ports on a firewall at all.

True that, but applications like ICQ or home banking software need this 
sometimes. I guess they don't firewall their socks server at all.

Cheers,
Thomas

Re: 2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hello Patrick,

On Friday, 9. March 2007, Thomas Jarosch wrote:
> > Without having looked into this in detail, I guess it should be
> > in the tens of minutes range. We need this anyway for state
> > synchronization since the H.323 helper manually assigns
> > unregistered helpers to its children.
>
> Do expectations always need an associated conntrack entry
> or could they be added as orphans? I can imagine it will be
> quite difficult for the shell script to find
> the correct client<->socks server conntrack.

In the meantime I've developed a small patch for the dante socks server
which I post here so anyone facing the same problem
has a starting point for a solution.

Also finding the conntrack via a shell script shouldn't be too hard at all
as the socks server knows the client ip/src port and the IP/port on the 
server. That should be enough to grep for the conntrack.

Could you take a shot at the helperless expectation, please?
I would happily test it :-)

Cheers,
Thomas

[-- Attachment #2: dante-firewall.patch --]
[-- Type: text/x-diff, Size: 1985 bytes --]

diff -u -r -p dante-1.1.19/sockd/sockd_request.c dante.socks/sockd/sockd_request.c
--- dante-1.1.19/sockd/sockd_request.c	Sat Jan  7 19:54:47 2006
+++ dante.socks/sockd/sockd_request.c	Thu Mar 15 16:32:53 2007
@@ -250,6 +250,10 @@ dorequest(mother, request)
 	char msg[256];
 	int failed, p, permit, out, failurecode = SOCKS_NOTALLOWED;
 
+	// Used by the firewall patch
+	int i, firewall_open = 0;
+	uid_t euid;
+
 	slog(LOG_DEBUG, "received request: %s",
 	socks_packet2string(&request->req, SOCKS_REQUEST));
 
@@ -841,6 +845,26 @@ dorequest(mother, request)
 			emfile = 0;
 			iolist = NULL;
 
+			// is bind request on external IP?
+		    	for (i = 0; i < sockscf.external.addrc; ++i) {
+			    if (sockscf.external.addrv[i].addr.ipv4.ip.s_addr == response.host.addr.ipv4.s_addr) {
+    				slog(LOG_DEBUG, "Firewall open: dst %s:%d", inet_ntoa(response.host.addr.ipv4), ntohs(response.host.port));
+				slog(LOG_DEBUG, "Firewall open: src %s:%d", inet_ntoa(io.src.host.addr.ipv4), ntohs(io.src.host.port));
+
+				// protocol
+				if (io.state.protocol == SOCKS_UDP)
+    				    slog(LOG_DEBUG, "Firewall open: protocol UDP");
+				else
+    				    slog(LOG_DEBUG, "Firewall open: protocol TCP");
+
+				// socks_seteuid(&euid, sockscf.uid.privileged);
+				firewall_open = 1;
+				// socks_reseteuid(sockscf.uid.privileged, euid);
+
+				break;
+			    }
+			}
+
 			/* CONSTCOND */
 			/* keep accepting connections until 
 			 * a) we get a remote address that matches what client asked for.
@@ -1200,6 +1224,15 @@ dorequest(mother, request)
 			}
 
 			closev(sv, ELEMENTS(sv));
+
+                        /* TOMJ: If expectation is related to conntrack entry
+                                 this code is not needed */
+		    	if (firewall_open == 1) {
+                           // Delete firewall rule
+			    // socks_seteuid(&euid, sockscf.uid.privileged);
+			    // socks_reseteuid(sockscf.uid.privileged, euid);
+			    firewall_open = 0;
+			}
 			break;
 		}
 

Re: 2.6.20: ipt_owner match and INPUT chain

[Patrick McHardy]

Thomas Jarosch wrote:
> Could you take a shot at the helperless expectation, please?
> I would happily test it :-)

I'm currently busy with a few other things, but I'll try to
look into it in the next time. Might take a bit longer than
I initially estimated though, since this will be exposed to
userspace and is also needed for userspace-helpers I want to
make sure its really what we need.

Re: 2.6.20: ipt_owner match and INPUT chain

[Thomas Jarosch]

Hello Patrick,

On Friday, 16. March 2007, Patrick McHardy wrote:
> > Could you take a shot at the helperless expectation, please?
> > I would happily test it :-)
>
> I'm currently busy with a few other things, but I'll try to
> look into it in the next time. Might take a bit longer than
> I initially estimated though, since this will be exposed to
> userspace and is also needed for userspace-helpers I want to
> make sure its really what we need.

Thanks. Would it be possible as a short term solution from an internal 
infrastructure point of view to write a "dummy" helper which
does nothing except registering itself as helper?

As far as I can see the dummy helper would have to "listen" on TCP port 1080
to own all conntracks to the socks server. Then it should be possible
to add expectations to these conntracks, right?

Cheers,
Thomas

Re: 2.6.20: ipt_owner match and INPUT chain

[Patrick McHardy]

Thomas Jarosch wrote:
> Thanks. Would it be possible as a short term solution from an internal 
> infrastructure point of view to write a "dummy" helper which
> does nothing except registering itself as helper?
> 
> As far as I can see the dummy helper would have to "listen" on TCP port 1080
> to own all conntracks to the socks server. Then it should be possible
> to add expectations to these conntracks, right?


Yes, that should work fine.