iptables and the owner module

iptables and the owner module

[Firstname Lastname]

Iptables is dropping network connections to google.com (and bing.com) for a reason that is unclear.
Iptables is configured with the owner module and is set to ACCEPT outgoing packets matching '--uid-owner 1000'.
Subsequently, packets that do not match '--uid-owner 1000' and are associated with an open socket are logged then dropped.
The relevant lines in the iptables configuration are indicated below:

...
-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --uid-owner 1000 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j LOG --log-tcp-options --log-ip-options --log-uid --log-level 7
-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j DROP
...

The following log output is generated prior to being dropped:

IN= OUT=eth0 SRC=192.168.2.2 DST=173.194.73.103 LEN=60 TOS=0x00 PREC=0x00 TTL=40 ID=7363 DF PROTO=TCP SPT=58642 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A1D88900B0000000001030307) UID=1000 GID=1000

As indicated in the log output, the packet socket's file structure is owned by userid 1000 and thus should match the preceding configuration line with the ACCEPT target.

Any suggestions as to why iptables is dropping the packet and/or why it's specific to google.com (and bing.com)?

Running Debian Squeeze (kernel 2.6.32 or 3.2.9) with iptables (1.4.8-3).
I can provide additional info if necessary.

Thanks in advance.

Re: iptables and the owner module

[Jan Engelhardt]

On Wednesday 2012-03-28 01:45, Firstname Lastname wrote:
>
>-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport
>--dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner
>--uid-owner 1000 -j ACCEPT
>
>The following log output is generated prior to being dropped:
>
>IN= OUT=eth0 SRC=192.168.2.2 DST=173.194.73.103 LEN=60 TOS=0x00
>PREC=0x00 TTL=40 ID=7363 DF PROTO=TCP SPT=58642 DPT=80 WINDOW=5840
>RES=0x00 SYN URGP=0 OPT (020405B40402080A1D88900B0000000001030307)
>UID=1000 GID=1000
>
>As indicated in the log output, the packet socket's file structure
>is owned by userid 1000 and thus should match the preceding
>configuration line with the ACCEPT target.

Not if a preceding match in the same rule returned false. Which is
what your log line indicates. Seeing it as that, the actual
ct state is not NEW nor EST.

Re: iptables and the owner module

[Firstname Lastname]

On Wed, 28 Mar 2012 03:32:13 +0200 (CEST)
Jan Engelhardt <jengelh@medozas.de> wrote:

> >-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport
> >--dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner
> >--uid-owner 1000 -j ACCEPT
> >
> >The following log output is generated prior to being dropped:
> >
> >IN= OUT=eth0 SRC=192.168.2.2 DST=173.194.73.103 LEN=60 TOS=0x00
> >PREC=0x00 TTL=40 ID=7363 DF PROTO=TCP SPT=58642 DPT=80 WINDOW=5840
> >RES=0x00 SYN URGP=0 OPT (020405B40402080A1D88900B0000000001030307)
> >UID=1000 GID=1000
> >
> >As indicated in the log output, the packet socket's file structure
> >is owned by userid 1000 and thus should match the preceding
> >configuration line with the ACCEPT target.  
> 
> Not if a preceding match in the same rule returned false. Which is
> what your log line indicates. Seeing it as that, the actual
> ct state is not NEW nor EST.  

If the ct state is not NEW nor EST, then its my understanding that none of the rules should match.

The order through the chain is as stated previously: 

  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --uid-owner 1000 -j ACCEPT
  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j LOG --log-tcp-options --log-ip-options --log-uid --log-level 7
  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j DROP

The 3 rules are nearly equivalent, the difference being the owner module option, --uid-owner vs. --socket-exists (and, of course, the target).
The initial SYN packet to google.com is not matched in the first rule, and thus passed to the second rule where the packet is matched and logged.
The packet is then passed to the third rule and dropped.

Oddly, though, if I add "173.194.73.103 www.google.com" to the hosts file, the intial SYN packet is matched in the first rule and thus accepted.
When google's IP is obtained from a DNS query, the initial SYN packet to google.com is not matched in the first rule, but is matched in the second and third rule.
So far, I've only observed this with google.com (and bing.com).

In any case, thanks for the response.

Bill

Re: iptables and the owner module

[Jan Engelhardt]

On Wednesday 2012-03-28 18:43, Firstname Lastname wrote:
>
>>>-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport
>>>--dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner
>>>--uid-owner 1000 -j ACCEPT
>>
>> ct state is [perhaps] not NEW nor EST.  
>
>If the ct state is not NEW nor EST, then its my understanding that none 
>of the rules should match.
>
>The order through the chain is as stated previously: 
>
>  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --uid-owner 1000 -j ACCEPT
>  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j LOG --log-tcp-options --log-ip-options --log-uid --log-level 7
>  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j DROP

But are these really all the rules? It has happened too often that users 
only ever appended rules, such that the trailing ones were never 
executed, since some old rules occurring before them already rendered a 
final verdict.
Never post iptables -L -- always post iptables-save, unabridged.

N.B.: Unrelated to the observed packet, as for rule content goes, 
32768:61000 looks highly suspicious of "I know better than the RFC"[sic] 
and is a recipe for some program to stumble and fall on.

>The 3 rules are nearly equivalent, the difference being the owner module option, --uid-owner vs. --socket-exists (and, of course, the target).
>The initial SYN packet to google.com is not matched in the first rule, and thus passed to the second rule where the packet is matched and logged.
>The packet is then passed to the third rule and dropped.
>
>Oddly, though, if I add "173.194.73.103 www.google.com" to the hosts file, the intial SYN packet is matched in the first rule and thus accepted.

So perhaps you have a specific (not shown) -d 173.194.73.103 match 
somewhere and ran afoul of google.com having multiple addresses.

>When google's IP is obtained from a DNS query, the initial SYN packet to google.com is not matched in the first rule, but is matched in the second and third rule.
>So far, I've only observed this with google.com (and bing.com).
>
>In any case, thanks for the response.
>
>Bill
>
>--
>To unsubscribe from this list: send the line "unsubscribe netfilter" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: iptables and the owner module

[Firstname Lastname]

On Wed, 28 Mar 2012 22:48:23 +0200 (CEST)
Jan Engelhardt <jengelh@medozas.de> wrote:

> On Wednesday 2012-03-28 18:43, Firstname Lastname wrote:
> >
> >>>-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --uid-owner 1000 -j ACCEPT
> >>
> >> ct state is [perhaps] not NEW nor EST.  
> >
> >If the ct state is not NEW nor EST, then its my understanding that none of the rules should match.
> >
> >The order through the chain is as stated previously: 
> >
> >  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --uid-owner 1000 -j ACCEPT
> >  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j LOG --log-tcp-options --log-ip-options --log-uid --log-level 7
> >  -A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j DROP
> 
> But are these really all the rules? It has happened too often that users only ever appended rules, such that the trailing ones were never executed, since some old rules occurring before them already rendered a final verdict.

Of course those 3 lines are not all the rules, they are the relevant ones.

The match occurs with the respective 2 rules I mentioned, not before and not after.
The actual logging rule I use is the following and might help to clarify why I'm certain of this.

-A OUTPUT -o eth0 -p tcp -m tcp --sport 32768:61000 -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -m owner --socket-exists -j ULOG --ulog-prefix "<!>SocketExists "

It is essentially the same logging rule I posted but defined with the prefix option to elucidate exactly where in the chain the drop occurs.
Every rule in my test configuration with a DROP or ACCEPT target has a matching rule with a target of ULOG --ulog-prefix "foo" for this very purpose.

> Never post iptables -L -- always post iptables-save, unabridged.

The format of the listed rules are equivalent to the output generated with "iptables -S" or iptables-save, and are unabridged.

> N.B.: Unrelated to the observed packet, as for rule content goes, 
> 32768:61000 looks highly suspicious of "I know better than the RFC"[sic] 
> and is a recipe for some program to stumble and fall on.

This appears to be a common range used in many configurations and I believe it may be a Debian default.
It has never resulted in any 'noticeable' problems, but I take your point.

> >The 3 rules are nearly equivalent, the difference being the owner module option, --uid-owner vs. --socket-exists (and, of course, the target).
> >The initial SYN packet to google.com is not matched in the first rule, and thus passed to the second rule where the packet is matched and logged.
> >The packet is then passed to the third rule and dropped.
> >
> >Oddly, though, if I add "173.194.73.103 www.google.com" to the hosts file, the intial SYN packet is matched in the first rule and thus accepted.
> 
> So perhaps you have a specific (not shown) -d 173.194.73.103 match 
> somewhere and ran afoul of google.com having multiple addresses.

I'm certain this is not the case.

The issue appears to be specific to connections to google.com when a DNS query is made prior to the initial SYN packet being sent to google.
It is the SYN packet to google.com that is being dropped.
The issue is transient and started about 2 weeks ago.
Yesterday evening connections to google.com proceeded as expected, i.e. no drops.
This morning the connections are being dropped as a result of the aforementioned rule.
The host was not rebooted and the iptables configuration was not modified in the interim.
Adding an entry for google.com to the hosts file, thus bypassing a DNS query, resolves the issue.
In any case, this issue appears to be beyond iptables.
And, again, I appreciate the response. 

Bill