From: Richard Weinberger <richard@nod.at>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Jan Engelhardt <jengelh@medozas.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules
Date: Fri, 21 Jan 2011 14:38:31 +0100 [thread overview]
Message-ID: <201101211438.31772.richard@nod.at> (raw)
In-Reply-To: <4D398956.3030201@netfilter.org>
Am Freitag 21 Januar 2011, 14:25:42 schrieb Pablo Neira Ayuso:
> On 21/01/11 13:53, Richard Weinberger wrote:
> > Am Freitag 21 Januar 2011, 13:24:27 schrieb Pablo Neira Ayuso:
> >> On 21/01/11 12:56, Richard Weinberger wrote:
> >>> Am Freitag 21 Januar 2011, 12:26:09 schrieb Pablo Neira Ayuso:
> >>>> On 21/01/11 12:13, Richard Weinberger wrote:
> >>>>> Am Freitag 21 Januar 2011, 11:00:48 schrieb Pablo Neira Ayuso:
> >>>>>> On 21/01/11 00:02, Richard Weinberger wrote:
> >>>>>>> Am Donnerstag 20 Januar 2011, 23:52:25 schrieb Jan Engelhardt:
> >>>>>>>> On Thursday 2011-01-20 23:47, Richard Weinberger wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> as a firewall admin I would like to see which rules allow
> >>>>>>>>> the connections through my firewall.
> >>>>>>>>> A relationship between conntrack and firewall rules would be
> >>>>>>>>> nice. The next five patches bring this feature to the Linux
> >>>>>>>>> Netfilter.
> >>>>>>>>>
> >>>>>>>>> First a small example.
> >>>>>>>>> Consider this iptables rules:
> >>>>>>>>> -A INPUT -m state --state ESTABLISHED,RELATED -j APPROVE
> >>>>>>>>> --rule-id 1 -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED
> >>>>>>>>> -j APPROVE --rule-id 2 -A INPUT -p tcp --dport 22 -m state
> >>>>>>>>> --state NEW -j APPROVE --rule-id 3 -A INPUT -p icmp -m state
> >>>>>>>>> --state NEW -j APPROVE --rule-id 4
> >>>>>>>>>
> >>>>>>>>> The APPROVE target is the same as ACCEPT but it stores also a
> >>>>>>>>> rule id into the connection tracking entry.
> >>>>>>>>
> >>>>>>>> What about connmark? You could have used that. Perhaps combined
> >>>>>>>> with the use of -j TRACE that can show which rules were processed
> >>>>>>>> before a verdict was issued.
> >>>>>>>
> >>>>>>> Yeah, I know commark and TRACE but they are quite clumsy to use for
> >>>>>>> such a purpose.
> >>>>>>
> >>>>>> Why are the clumsy for this purpose?
> >>>>>
> >>>>> Because I would need more than one iptables command to model a
> >>>>> firewall rule. Or can you show me a simple iptables configuration
> >>>>> using connmark which achieves the same as my APPROVE example above?
> >>>>
> >>>> Just a couple of extra rules to restore and save the connmark. Right?
> >>>
> >>> With my extension you can see which rule accepted the connection
> >>> in the states ESTABLISHED, RELATED, NEW and REPLY.
> >>> So we have 4 rule ids per connection.
> >>>
> >>> Let's look again at this connection:
> >>> tcp 6 431999 ESTABLISHED src=192.168.1.1 dst=192.168.1.2
> >>> sport=51444 \
> >>>
> >>> dport=22 src=192.168.1.2 dst=192.168.1.1 sport=22 dport=51444
> >>> [ASSURED] \ mark=0 established=1 related=0 new=3 reply=2 use=1
> >>>
> >>> We can observe that the connection in state ESTABLISHED was allowed by
> >>> rule 1, NEW by rule 3 and REPLY by rule 2.
> >>>
> >>> To model this using conntrack we need more than a few more restore and
> >>> save rules... (Assuming all rule ids are 8bit, because connmark is
> >>> 32bit)
> >>>
> >>> This is why I've made this contribution.
> >>> It makes it very easy to model such tasks.
> >>
> >> I think that it's better to do this in user-space. You have the trace
> >> infrastructure which actually logs stuff via NFLOG. You can write some
> >> user-space tool using libnetfilter_log that can accumulate the trace for
> >> some traffic and display friendlier output (which seems to be what you
> >> want).
> >
> > Using the TRACE target the kernel would produce a lot of log messages
> > which may slow down the firewall. Especially when tracing ESTABLISHED
> > connections. My extension does not have this overhead.
>
> AFAICS, this is an ad-hoc optimization for a specific case that you
> need. So, it's basically a subset of the trace infrastructure.
But without the overhead...
> > All I want is a friendlier output from conntrack, why should I reinvent
> > the wheel?
>
> Why doing things in user-space is reinventing the wheel?
When I'm using TRACE I'll get a lot of log messages.
But I'm not interested in logs, I have already enough of them.
I want a session table where I can see what sessions are allowed by
which rules.
I would have to write a tool like conntrack which builds me a session table
from all these logs.
//richard
next prev parent reply other threads:[~2011-01-21 13:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-20 22:47 [PATCH 0/3][RFC] Relationship between conntrack and firewall rules Richard Weinberger
2011-01-20 22:47 ` [PATCH 1/3] netfilter: add ruleid extension Richard Weinberger
2011-01-20 22:47 ` [PATCH 2/3] netfilter: add APPROVE target Richard Weinberger
2011-01-20 22:47 ` [PATCH 3/3] netfilter: implement ctnetlink_dump_ruleid() Richard Weinberger
2011-01-20 22:47 ` [PATCH] iptables: Add APPROVE target Richard Weinberger
2011-01-20 22:47 ` [PATCH] conntrack: Implement ruleid support Richard Weinberger
2011-01-20 23:17 ` [PATCH 2/3] netfilter: add APPROVE target Jan Engelhardt
2011-01-20 23:22 ` Richard Weinberger
2011-01-20 23:27 ` Jan Engelhardt
2011-01-20 23:30 ` Richard Weinberger
2011-01-20 22:52 ` [PATCH 0/3][RFC] Relationship between conntrack and firewall rules Jan Engelhardt
2011-01-20 23:02 ` Richard Weinberger
2011-01-21 10:00 ` Pablo Neira Ayuso
2011-01-21 11:13 ` Richard Weinberger
2011-01-21 11:26 ` Pablo Neira Ayuso
2011-01-21 11:56 ` Richard Weinberger
2011-01-21 12:24 ` Pablo Neira Ayuso
2011-01-21 12:53 ` Richard Weinberger
2011-01-21 13:25 ` Pablo Neira Ayuso
2011-01-21 13:38 ` Richard Weinberger [this message]
2011-01-21 13:57 ` Pablo Neira Ayuso
2011-01-21 14:11 ` Richard Weinberger
2011-01-21 15:09 ` Mr Dash Four
2011-01-21 0:04 ` Mr Dash Four
2011-01-21 0:10 ` Richard Weinberger
2011-01-21 0:13 ` Mr Dash Four
2011-01-21 9:58 ` secctx support for conntrack-tools [was Re: [PATCH 0/3][RFC] Relationship between conntrack and firewall rules] Pablo Neira Ayuso
2011-01-21 9:56 ` [PATCH 0/3][RFC] Relationship between conntrack and firewall rules Pablo Neira Ayuso
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=201101211438.31772.richard@nod.at \
--to=richard@nod.at \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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).