From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Richard Weinberger <richard@nod.at>
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 13:24:27 +0100 [thread overview]
Message-ID: <4D397AFB.3050602@netfilter.org> (raw)
In-Reply-To: <201101211256.34778.richard@nod.at>
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).
next prev parent reply other threads:[~2011-01-21 12:24 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 [this message]
2011-01-21 12:53 ` Richard Weinberger
2011-01-21 13:25 ` Pablo Neira Ayuso
2011-01-21 13:38 ` Richard Weinberger
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=4D397AFB.3050602@netfilter.org \
--to=pablo@netfilter.org \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.