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 -- 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
