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. All I want is a friendlier output from conntrack, why should I reinvent the wheel? //richard -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
