netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Firstname Lastname <forbiddentransition@gmail.com>
To: netfilter@vger.kernel.org
Subject: Re: iptables and the owner module
Date: Wed, 28 Mar 2012 12:43:32 -0400	[thread overview]
Message-ID: <20120328124332.66e7ad79@gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.01.1203280325160.14701@frira.zrqbmnf.qr>

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


  reply	other threads:[~2012-03-28 16:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-27 23:45 iptables and the owner module Firstname Lastname
2012-03-28  1:32 ` Jan Engelhardt
2012-03-28 16:43   ` Firstname Lastname [this message]
2012-03-28 20:48     ` Jan Engelhardt
2012-03-29 17:52       ` Firstname Lastname

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120328124332.66e7ad79@gmail.com \
    --to=forbiddentransition@gmail.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).