Re: iptables and the owner module

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 28 Mar 2012 03:32:13 +0200 (CEST)
Jan Engelhardt <jengelh@xxxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux