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