* ipsets for both source and target in one iptables-rule? @ 2005-12-01 14:02 Frank.Mayer 2005-12-01 15:53 ` Nikolai Alexandrov 2005-12-01 16:22 ` Jozsef Kadlecsik 0 siblings, 2 replies; 11+ messages in thread From: Frank.Mayer @ 2005-12-01 14:02 UTC (permalink / raw) To: netfilter Hello, I'd like to use two ipsets in a single iptables rule similar to iptables -A FORWARD -p tcp -m tcp --dport ssh -m set --set clients src -m set --set servers dst -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -p tcp -m tcp --sport ssh -m set --set servers src -m set --set clients dst -m state --state ESTABLISHED -j ACCEPT Can anyone tell me if that's just a syntax error or if this is entirely impossible? (Kernel 2.4.32, iptables 1.3.4, ipset 2.2.7) Thanks in Advance, Frank Mayer UNIX Systemadministration ---------------------------------------------------- KNAPP Systemintegration GmbH Waltenbachstrasse 9 8700 Leoben, Austria ---------------------------------------------------- Phone: +43 3842 805-921 Fax: +43 3842 82930-921 frank.mayer@knapp-systems.com www.knapp.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipsets for both source and target in one iptables-rule? 2005-12-01 14:02 ipsets for both source and target in one iptables-rule? Frank.Mayer @ 2005-12-01 15:53 ` Nikolai Alexandrov 2005-12-01 16:22 ` Jozsef Kadlecsik 1 sibling, 0 replies; 11+ messages in thread From: Nikolai Alexandrov @ 2005-12-01 15:53 UTC (permalink / raw) To: Frank.Mayer; +Cc: netfilter Frank.Mayer@knapp-systems.com wrote: >Hello, > >I'd like to use two ipsets in a single iptables rule similar to > >iptables -A FORWARD -p tcp -m tcp --dport ssh -m set --set clients src -m >set --set servers dst -m state --state NEW,ESTABLISHED -j ACCEPT >iptables -A FORWARD -p tcp -m tcp --sport ssh -m set --set servers src -m >set --set clients dst -m state --state ESTABLISHED -j ACCEPT > > > Have you tried without -m tcp? I think that -m tcp is wrong here. >Can anyone tell me if that's just a syntax error or if this is entirely >impossible? >(Kernel 2.4.32, iptables 1.3.4, ipset 2.2.7) > >Thanks in Advance, >Frank Mayer >UNIX Systemadministration >---------------------------------------------------- >KNAPP Systemintegration GmbH >Waltenbachstrasse 9 >8700 Leoben, Austria >---------------------------------------------------- >Phone: +43 3842 805-921 >Fax: +43 3842 82930-921 >frank.mayer@knapp-systems.com >www.knapp.com > > > > -- Ако не отговарям на писмата Ви - погледнете тук: http://6lyokavitza.org/mail ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: ipsets for both source and target in one iptables-rule? 2005-12-01 14:02 ipsets for both source and target in one iptables-rule? Frank.Mayer 2005-12-01 15:53 ` Nikolai Alexandrov @ 2005-12-01 16:22 ` Jozsef Kadlecsik 2005-12-01 18:05 ` Antwort: " Frank.Mayer 1 sibling, 1 reply; 11+ messages in thread From: Jozsef Kadlecsik @ 2005-12-01 16:22 UTC (permalink / raw) To: Frank.Mayer; +Cc: netfilter Hi, On Thu, 1 Dec 2005 Frank.Mayer@knapp-systems.com wrote: > I'd like to use two ipsets in a single iptables rule similar to > > iptables -A FORWARD -p tcp -m tcp --dport ssh -m set --set clients src -m > set --set servers dst -m state --state NEW,ESTABLISHED -j ACCEPT That is not possible due to the feature in iptables itself that one cannot specify two or more match extensions of the same time. It is a limitation of the userspace interface (i.e. iptables) and not that of the kernel. However, you can "workaround" the situation with using the binding functionality of ipset. Bind the servers set to the clients set as default and use the command iptables -A FORWARD -p tcp --dport ssh \ -m set --set clients src,dst \ -m state --state NEW,ESTABLISHED -j ACCEPT Thus the set match is forced to match the source against the clients set and because there's a default binding and the match is instructed to follow it by 'src,dst', match the destination in the servers set. The final result is true if both matches are true. In my opinion it's wasting of resources to specify any other matching together with '-m state --state NEW,ESTABLISHED' if you set up proper rules for matching NEW packets. But that you should do anyway to setup a proper firewall. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
* Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-01 16:22 ` Jozsef Kadlecsik @ 2005-12-01 18:05 ` Frank.Mayer 2005-12-02 7:48 ` Jozsef Kadlecsik 0 siblings, 1 reply; 11+ messages in thread From: Frank.Mayer @ 2005-12-01 18:05 UTC (permalink / raw) To: netfilter Hello, >> I'd like to use two ipsets in a single iptables rule similar to >> >> iptables -A FORWARD -p tcp -m tcp --dport ssh -m set --set clients src -m >> set --set servers dst -m state --state NEW,ESTABLISHED -j ACCEPT > > That is not possible due to the feature in iptables itself that one cannot > specify two or more match extensions of the same time. It is a limitation > of the userspace interface (i.e. iptables) and not that of the kernel. That's what I thought might be the case....... > However, you can "workaround" the situation with using the binding > functionality of ipset. Bind the servers set to the clients set as default > and use the command > ..... Ah! It looks like I didn't really understand that "bind"-thing from the docs. ;-) > In my opinion it's wasting of resources to specify any other matching > together with '-m state --state NEW,ESTABLISHED' if you set up proper > rules for matching NEW packets. I'm not sure I understand.... It's true I can (and often do) add a rule similar to iptables -A FORWARD -s 0/0 -d 0/0 -p tcp -m state --state ESTABLISHED -j ACCEPT as some "catch-it-all". Is this what you mean? - the second rule in my mail I just gave for clarity and completeness.... Best Regards and many thanks, Frank Mayer UNIX Systemadministration ---------------------------------------------------- KNAPP Systemintegration GmbH Waltenbachstrasse 9 8700 Leoben, Austria ---------------------------------------------------- Phone: +43 3842 805-921 Fax: +43 3842 82930-921 frank.mayer@knapp-systems.com www.knapp.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-01 18:05 ` Antwort: " Frank.Mayer @ 2005-12-02 7:48 ` Jozsef Kadlecsik 2005-12-02 11:42 ` Antwort: " Frank.Mayer 2005-12-02 11:59 ` Frank.Mayer 0 siblings, 2 replies; 11+ messages in thread From: Jozsef Kadlecsik @ 2005-12-02 7:48 UTC (permalink / raw) To: Frank.Mayer; +Cc: netfilter On Thu, 1 Dec 2005 Frank.Mayer@knapp-systems.com wrote: > > In my opinion it's wasting of resources to specify any other matching > > together with '-m state --state NEW,ESTABLISHED' if you set up proper > > rules for matching NEW packets. > I'm not sure I understand.... > It's true I can (and often do) add a rule similar to > iptables -A FORWARD -s 0/0 -d 0/0 -p tcp -m state --state > ESTABLISHED -j ACCEPT > as some "catch-it-all". The '-s 0/0 -d 0/0' matches buy nothing, they express the default. But why do you specify the protocol? Will you enter similar rules for UDP and ICMP as well? Then netfilter has to process two-three rules instead of one. And if you already let in the packet which created the connection, then the state matching is perfectly enough to match all subsequent packets in the same stream. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
* Antwort: Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-02 7:48 ` Jozsef Kadlecsik @ 2005-12-02 11:42 ` Frank.Mayer 2005-12-02 12:18 ` Rob Sterenborg 2005-12-02 11:59 ` Frank.Mayer 1 sibling, 1 reply; 11+ messages in thread From: Frank.Mayer @ 2005-12-02 11:42 UTC (permalink / raw) To: netfilter > On Thu, 1 Dec 2005 Frank.Mayer@knapp-systems.com wrote: > > > > In my opinion it's wasting of resources to specify any other matching > > > together with '-m state --state NEW,ESTABLISHED' if you set up proper > > > rules for matching NEW packets. > > I'm not sure I understand.... > > It's true I can (and often do) add a rule similar to > > iptables -A FORWARD -s 0/0 -d 0/0 -p tcp -m state --state > > ESTABLISHED -j ACCEPT > > as some "catch-it-all". > > The '-s 0/0 -d 0/0' matches buy nothing, they express the default. > But why do you specify the protocol? Will you enter similar rules for UDP > and ICMP as well? Then netfilter has to process two-three rules instead of > one. And if you already let in the packet which created the connection, > then the state matching is perfectly enough to match all subsequent > packets in the same stream. > > Best regards, > Jozsef Hello Jozsef, If the "-s 0/0 -d 0/0 .... -j ACCEPT" matches express the default or not does depend on the default, don't they? Of course, I could do without expressly stating source and destination addresses when defining the generic rule, but I don't think that's the point you wanted to make, is it? And yes, if and only if - which is not the case very often, given the network setup I have to cope with - I want ICMP and/or UDP from some client to some server, I expressly define such rules. On several occasions in the past, we had an ISDN connection to Mexico open over the weekend, just because some crazy programmer forgot he had started a ping to some machine there when he left Friday afternoon. This is why I don't generally allow ICMP (ICMP uses on the Internet do not apply for these connections). Similar arguments hold for UDP: some collegue had been connected to a remote network abroad, and forgot the printer connection he had configured on his notebook there. Therefore windows on his machine queried the printer via SNMP every couple of minutes even when he was back in Austria: now a way to keep your phone bill low, if you ask me. This and several other things led me to believe in being as restrictive as possible when configuring a firewall, and of course I try to minimize the number of rules netfilter needs to process to find a match when designing the rule sets. (Or did I completely misunderstand your statement?) Best Regards, Frank Mayer UNIX Systemadministration ---------------------------------------------------- KNAPP Systemintegration GmbH Waltenbachstrasse 9 8700 Leoben, Austria ---------------------------------------------------- Phone: +43 3842 805-921 Fax: +43 3842 82930-921 frank.mayer@knapp-systems.com www.knapp.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Antwort: Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-02 11:42 ` Antwort: " Frank.Mayer @ 2005-12-02 12:18 ` Rob Sterenborg 0 siblings, 0 replies; 11+ messages in thread From: Rob Sterenborg @ 2005-12-02 12:18 UTC (permalink / raw) To: netfilter On Fri, December 2, 2005 12:42, Frank.Mayer@knapp-systems.com wrote: >> The '-s 0/0 -d 0/0' matches buy nothing, they express the default. >> > If the "-s 0/0 -d 0/0 .... -j ACCEPT" matches express the default or > not does depend on the default, don't they? The default is 0/0 for both. > Of course, I could do without expressly stating source and > destination addresses when defining the generic rule, but I don't > think that's the point you wanted to make, is it? Since specifying -s 0/0 -d 0/0 is the same as not specifying these parameters, I think it is the point Jozsef wanted to make. Gr, Rob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Antwort: Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-02 7:48 ` Jozsef Kadlecsik 2005-12-02 11:42 ` Antwort: " Frank.Mayer @ 2005-12-02 11:59 ` Frank.Mayer 2005-12-02 12:19 ` Jozsef Kadlecsik 1 sibling, 1 reply; 11+ messages in thread From: Frank.Mayer @ 2005-12-02 11:59 UTC (permalink / raw) To: netfilter Hi Jozsef I just realized that I now think I understand what you meant by "But why do you specify the protocol?" I could have written the rule like iptables -A -m state --state ESTABLISHED -j ACCEPT Best Regards and sorry for the misunderstandings, Frank Mayer UNIX Systemadministration ---------------------------------------------------- KNAPP Systemintegration GmbH Waltenbachstrasse 9 8700 Leoben, Austria ---------------------------------------------------- Phone: +43 3842 805-921 Fax: +43 3842 82930-921 frank.mayer@knapp-systems.com www.knapp.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Antwort: Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-02 11:59 ` Frank.Mayer @ 2005-12-02 12:19 ` Jozsef Kadlecsik 2005-12-02 13:33 ` Antwort: " Frank.Mayer 0 siblings, 1 reply; 11+ messages in thread From: Jozsef Kadlecsik @ 2005-12-02 12:19 UTC (permalink / raw) To: Frank.Mayer; +Cc: netfilter On Fri, 2 Dec 2005 Frank.Mayer@knapp-systems.com wrote: > I just realized that I now think I understand what you meant by "But why > do you specify the protocol?" > > I could have written the rule like > iptables -A -m state --state ESTABLISHED -j ACCEPT Yes, conntrack hold entries of connections you had explicitly let to open up. So (usually) there is no point to add other matches to the rule above. Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
* Antwort: Re: Antwort: Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-02 12:19 ` Jozsef Kadlecsik @ 2005-12-02 13:33 ` Frank.Mayer 2005-12-02 21:48 ` Jozsef Kadlecsik 0 siblings, 1 reply; 11+ messages in thread From: Frank.Mayer @ 2005-12-02 13:33 UTC (permalink / raw) To: netfilter Hi Joszef & Rob, > On Fri, 2 Dec 2005 Frank.Mayer@knapp-systems.com wrote: > > > I just realized that I now think I understand what you meant by "But why > > do you specify the protocol?" > > > > I could have written the rule like > > iptables -A -m state --state ESTABLISHED -j ACCEPT > > Yes, conntrack hold entries of connections you had explicitly let to open > up. So (usually) there is no point to add other matches to the rule above. > > Best regards, > Jozsef In hindsight, I completely agree with you (I hadn't given my example(s) the same scrutinity I usually apply to actual rule sets - if I do have the time to do so). Nevertheless I like to expressly state "-s 0/0 -d 0/0" for understandability. I have one more request, if I may bother you once again: can you point me to some documentation that clarifies state matching from a user's point of view? I do understand "NEW" and "ESTABLISHED" related to TCP, but their meaning for e.g. UDP and ICMP mostly eludes me, as does the "RELATED" state: under which circumstances is one connection considered "related" to another one (does that depend on the interpretation of the respective conntrack-module, or is there a general definition)? Best Regards and many thanks again for your clarifications - and patience ;-) Frank Mayer UNIX Systemadministration ---------------------------------------------------- KNAPP Systemintegration GmbH Waltenbachstrasse 9 8700 Leoben, Austria ---------------------------------------------------- Phone: +43 3842 805-921 Fax: +43 3842 82930-921 frank.mayer@knapp-systems.com www.knapp.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Antwort: Re: Antwort: Re: Antwort: Re: ipsets for both source and target in one iptables-rule? 2005-12-02 13:33 ` Antwort: " Frank.Mayer @ 2005-12-02 21:48 ` Jozsef Kadlecsik 0 siblings, 0 replies; 11+ messages in thread From: Jozsef Kadlecsik @ 2005-12-02 21:48 UTC (permalink / raw) To: Frank.Mayer; +Cc: netfilter On Fri, 2 Dec 2005 Frank.Mayer@knapp-systems.com wrote: > Nevertheless I like to expressly state "-s 0/0 -d 0/0" for > understandability. Presently that's all right, because it does not cost anything (i.e. does bnot slow down the evaluation): source and destination address matchings are implicitly always applied. (However as sooner or later new packet classification algorithm will replace the current one, that can be untrue in the future and *can* mean wasted CPU cycles.) > I have one more request, if I may bother you once again: > can you point me to some documentation that clarifies state matching from > a user's point of view? > I do understand "NEW" and "ESTABLISHED" related to TCP, but their meaning > for e.g. UDP and ICMP mostly eludes me, as does the "RELATED" state: > under which circumstances is one connection considered "related" to > another one (does that depend on the interpretation of the respective > conntrack-module, or is there a general definition)? Oskar Andreasson's iptables tutorial is very good in explaining the details behind iptables/netfilter from user point of view: http://iptables-tutorial.frozentux.net/ Best regards, Jozsef - E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-12-02 21:48 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-12-01 14:02 ipsets for both source and target in one iptables-rule? Frank.Mayer 2005-12-01 15:53 ` Nikolai Alexandrov 2005-12-01 16:22 ` Jozsef Kadlecsik 2005-12-01 18:05 ` Antwort: " Frank.Mayer 2005-12-02 7:48 ` Jozsef Kadlecsik 2005-12-02 11:42 ` Antwort: " Frank.Mayer 2005-12-02 12:18 ` Rob Sterenborg 2005-12-02 11:59 ` Frank.Mayer 2005-12-02 12:19 ` Jozsef Kadlecsik 2005-12-02 13:33 ` Antwort: " Frank.Mayer 2005-12-02 21:48 ` Jozsef Kadlecsik
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.