multiports

multiports

[Peggy Kam]

Hi,

Is it possible to match multiple source and destination ports at the
same time?  It seems to me that it is not possible.  I am using iptables
version 1.2.11 and I have tried the following command:

iptables -A INPUT -p tcp --src 192.168.1.0/255.255.255.0 -m tcp -m
multiport --sports 22,80  --dst 192.168.22.123 -m multiport --dports
22,80 -j ACCEPT

Please correct me if I have the wrong syntax.  Any advice is
appreciated.

Thanks in advance,
Peggy

Re: multiports

[Jan Engelhardt]

>Is it possible to match multiple source and destination ports at the
>same time?  It seems to me that it is not possible.  I am using iptables
>version 1.2.11 and I have tried the following command:
>
>iptables -A INPUT -p tcp --src 192.168.1.0/255.255.255.0 -m tcp -m
>multiport --sports 22,80  --dst 192.168.22.123 -m multiport --dports
>22,80 -j ACCEPT

Everything is ANDed, so the following combinations are only possible with your 
rule:

22/22
22/80
80/22
80/80

Probably not what you want, given that most HTTP clients connect from some 
high-random port.

You need to separate rules,
-m multiport --dports 22,80
-m multiport --sports 22,80
to get an OR behavior


Jan Engelhardt
-- 

Maximum number of ports?

[Peggy Kam]

Hi,

What is the maximum number of ports that I can define in the iptables?
What is the limitation?

Thanks in advance,
Peggy

Re: Maximum number of ports?

[/dev/rob0]

On Wednesday 2005-August-10 15:13, Peggy Kam wrote:
> What is the maximum number of ports that I can define in the
> iptables? What is the limitation?

Are you asking about the multiport match extension? If so please find 
the following in "man iptables" and post again if you do not understand 
it:

   multiport
       This  module matches a set of source or destination ports.
       Up to 15 ports can be specified.  It can only be used  in
       conjunction with -p tcp or -p udp

That particular limitation only applies to a single multiport command. 
You can have as many of those as you need. Perhaps you're asking about 
the maximum number of rules you can have? I don't know what that limit 
might be (if I was curious I would Google), but I bet it's higher than 
the 64K TCP ports plus the 64K UDP ports.

If you're writing a firewall with that many rules, it is probable that 
you could have done it better and more efficiently using a different 
approach. For instance, default policies of DROP and only ACCEPT the 
port/protocol combinations you need, plus the standard "-m state 
--state RELATED,ESTABLISHED -j ACCEPT" rules.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Maximum number of rules in iptables?

[Peggy Kam]

Hi,

What is the maximum number of policies I can define in the iptables?  
ie. how much memory is allocated for iptables?

Thanks in advance,
Peggy

Re: Maximum number of rules in iptables?

[Edmundo Carmona]

that's a NFI for me. A whole bunch.... I've seen red hat scripts that
are way longer than mine. ;-)

On 9/13/05, Peggy Kam <ppkam@n-dsi.com> wrote:
> Hi,
> 
> What is the maximum number of policies I can define in the iptables?
> ie. how much memory is allocated for iptables?
> 
> Thanks in advance,
> Peggy
> 
> 
> 
> 
>

Re: Maximum number of rules in iptables?

[/dev/rob0]

> On 9/13/05, Peggy Kam <ppkam@n-dsi.com> wrote:
> > What is the maximum number of policies I can define in the
> > iptables? ie. how much memory is allocated for iptables?

I'm sure the answer is in the kernel source code if you need it. This 
forum is more for users than developers. You could try asking on LKML 
or on netfilter-devel, but I don't think you would be well-received 
there unless you showed an effort to find your own answers.

Opinion as a user: it's probably dynamically allocated; more memory is 
used in cases where there are more rules, or where the rules require.

Remembered from Googling: it's not ever likely to be a factor.

Personal experience: an 8MB 80386 is quite capable of handling NAT for 
home and small business broadband connections. I increased the default 
number of connection tracking table (ip_conntrack_max) entries, but 
otherwise had no problem.

On Tuesday 2005-September-13 22:41, Edmundo Carmona wrote:
> that's a NFI for me. A whole bunch.... I've seen red hat scripts that
> are way longer than mine. ;-)

I think it's safe to say that if you're making that many rules, you're 
doing something wrong. :) I said the same thing in this thread to this 
poster over a month ago.

Red Hat iptables rules (that I have seen) are terrible. Do they have 
anyone on staff who understands firewalling? If so, they're not working 
on the firewalls.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Fwd: Maximum number of rules in iptables?

[Edmundo Carmona]

Tiem and time again.... I forgot to mail netfilter. I always remember
to do it half a second after I press "send". :-(

---------- Forwarded message ----------
From: Edmundo Carmona <eantoranz@gmail.com>
Date: Sep 14, 2005 9:41 AM
Subject: Re: Maximum number of rules in iptables?
To: /dev/rob0 <rob0@gmx.co.uk>


Well... I guess they happen to be so many rules in those scripts
because they <b>could</b> come out (programatically speaking) more
easily that way.... I'm not saying it's because of that (haven't sat
down to think about a firewall script generator tool)... but it could
play a part.

On 9/14/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> > On 9/13/05, Peggy Kam <ppkam@n-dsi.com> wrote:
> > > What is the maximum number of policies I can define in the
> > > iptables? ie. how much memory is allocated for iptables?
>
> I'm sure the answer is in the kernel source code if you need it. This
> forum is more for users than developers. You could try asking on LKML
> or on netfilter-devel, but I don't think you would be well-received
> there unless you showed an effort to find your own answers.
>
> Opinion as a user: it's probably dynamically allocated; more memory is
> used in cases where there are more rules, or where the rules require.
>
> Remembered from Googling: it's not ever likely to be a factor.
>
> Personal experience: an 8MB 80386 is quite capable of handling NAT for
> home and small business broadband connections. I increased the default
> number of connection tracking table (ip_conntrack_max) entries, but
> otherwise had no problem.
>
> On Tuesday 2005-September-13 22:41, Edmundo Carmona wrote:
> > that's a NFI for me. A whole bunch.... I've seen red hat scripts that
> > are way longer than mine. ;-)
>
> I think it's safe to say that if you're making that many rules, you're
> doing something wrong. :) I said the same thing in this thread to this
> poster over a month ago.
>
> Red Hat iptables rules (that I have seen) are terrible. Do they have
> anyone on staff who understands firewalling? If so, they're not working
> on the firewalls.
> --
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
>
>

iptables rules

[Peggy Kam]

Hi,

I have defined the following firewall rule in iptables:

iptables -I FORWARD -s 192.168.22.102 -d 192.168.1.112 -p tcp -m tcp -m
multiport --ports 22,23,24,25 -j ACCEPT

why were the packets able to get to 192.168.1.112 on port 22 when the
packets does not even come from ports 22,23,24 or 25?

Thanks in advance,
Peggy

Re: iptables rules

[Jörg Harmuth]

Peggy Kam wrote:
> Hi,
> 
> I have defined the following firewall rule in iptables:
> 
> iptables -I FORWARD -s 192.168.22.102 -d 192.168.1.112 -p tcp -m tcp -m
> multiport --ports 22,23,24,25 -j ACCEPT
> 
> why were the packets able to get to 192.168.1.112 on port 22 when the
> packets does not even come from ports 22,23,24 or 25?

man iptables:

--ports [!] port[,port[,port:port...]]
               Match if either the source or destination
               ports are equal to one
               of the given ports.

So, this is expected behaviour, provided that there are no other rules 
in the way.

HTH,

Joerg

Re: iptables rules

[Peggy Kam]

did the manpage gets changed recently?  the iptables manpage that I see
states that:

--port [port[,port]]
        Match if the both the source and destination ports are equal to
        each other and to one of the given ports.


On Thu, 2005-09-15 at 17:26 +0200, Jörg Harmuth wrote:
> Peggy Kam wrote:
> > Hi,
> > 
> > I have defined the following firewall rule in iptables:
> > 
> > iptables -I FORWARD -s 192.168.22.102 -d 192.168.1.112 -p tcp -m tcp -m
> > multiport --ports 22,23,24,25 -j ACCEPT
> > 
> > why were the packets able to get to 192.168.1.112 on port 22 when the
> > packets does not even come from ports 22,23,24 or 25?
> 
> man iptables:
> 
> --ports [!] port[,port[,port:port...]]
>                Match if either the source or destination
>                ports are equal to one
>                of the given ports.
> 
> So, this is expected behaviour, provided that there are no other rules 
> in the way.
> 
> HTH,
> 
> Joerg
> 
> 

Re: iptables rules

[Jörg Harmuth]

Peggy Kam wrote:
> did the manpage gets changed recently?  the iptables manpage that I see
> states that:
> 
> --port [port[,port]]
>         Match if the both the source and destination ports are equal to
>         each other and to one of the given ports.


I see. You are referring to -m mport --port*s* (by the way, there is a 
typo or are you referring to another module ?), which is different from 
-m multiport --port*s* port[...] - which I was referring to. Your rule was

... -m multiport --ports 22,23,24,25 -j ACCEPT

So I looked for multiport.

HTH,

Joerg

Re: iptables rules

[Realos]

Jörg Harmuth wanted us to know:


>I see. You are referring to -m mport --port*s* (by the way, there is a 
>typo or are you referring to another module ?), which is different from 
>-m multiport --port*s* port[...] - which I was referring to. Your rule was
>
>... -m multiport --ports 22,23,24,25 -j ACCEPT
>
>So I looked for multiport.

There seems to be an inconsistence between man pages Jörg Harmuth has installed
and of some other people (the original poster and myself at least).

man iptables:

mport
...
 --ports port[,port[,port...]]
	Match if the both the source and destination ports are
	equal to each other and to one  of  the  given
	ports.

multiport
...
	used in conjunction with -p tcp or -p udp.
	rts port[,port[,port...]]
	Match if the both the source and destination ports
	are equal to each other and to one  of  the  given
	ports.

Mar 09, 2002 IPTABLES(8)

BTW, what is the diffence between mport and multiport modules?


-- 
Realos

RE: iptables rules

[Rob Sterenborg]

> There seems to be an inconsistence between man pages Jörg
> Harmuth has installed and of some other people (the original poster
> and myself at least). 
> 
> man iptables:
> 
> mport
> ...
>  --ports port[,port[,port...]]
> 	Match if the both the source and destination ports are
> 	equal to each other and to one  of  the  given
> 	ports.
> 
> multiport
> ...
> 	used in conjunction with -p tcp or -p udp.
> 	rts port[,port[,port...]]
> 	Match if the both the source and destination ports
> 	are equal to each other and to one  of  the  given 	ports.
> 
> Mar 09, 2002 IPTABLES(8)
> 
> BTW, what is the diffence between mport and multiport modules?

Mport is obsoleted according to :
http://www.netfilter.org/projects/patch-o-matic/pom-obsolete.html

Searching the Netfilter site I read that mport was to be combined with
multiport :
http://www.netfilter.org/documentation/conferences/nf-workshop-2004-summ
ary.html (mport TODO: combine with multiport). So, I think this work has
been done.


Gr,
Rob

Re: iptables rules

[Jörg Harmuth]

Realos wrote:
> Jörg Harmuth wanted us to know:
> 
> 
>> I see. You are referring to -m mport --port*s* (by the way, there is a 
>> typo or are you referring to another module ?), which is different from 
>> -m multiport --port*s* port[...] - which I was referring to. Your rule was
>>
>> ... -m multiport --ports 22,23,24,25 -j ACCEPT
>>
>> So I looked for multiport.
> 
> There seems to be an inconsistence between man pages Jörg Harmuth has installed
> and of some other people (the original poster and myself at least).
> 
> man iptables:
> 
> mport
> ...
>  --ports port[,port[,port...]]
> 	Match if the both the source and destination ports are
> 	equal to each other and to one  of  the  given
> 	ports.
> 
> multiport
> ...
> 	used in conjunction with -p tcp or -p udp.
> 	rts port[,port[,port...]]
> 	Match if the both the source and destination ports
> 	are equal to each other and to one  of  the  given
> 	ports.
> 
> Mar 09, 2002 IPTABLES(8)
> 
> BTW, what is the diffence between mport and multiport modules?
> 
> 

Hmm, interesting. I looked again and I see:

man iptables:

  mport
    --ports port[,port[,port...]]
            Match if the both the source and destination ports are
            equal to each other and to one of the given ports.

  multiport
    --ports [!] port[,port[,port:port...]]
            Match if either the source or destination ports are
            equal to one of the given ports.

My iptables is a self compiled 1.3.3 running on Sarge, one box with 
kernel 2.4.31 the other box with kernel 2.6.13.1. May be an iptables 
version issue ?

Have a nice time,

Joerg

Re: iptables rules

[Jörg Harmuth]

For the sake of completeness :)

Peggy Kam wrote:
> Hi,
> 
> I have defined the following firewall rule in iptables:
> 
> iptables -I FORWARD -s 192.168.22.102 -d 192.168.1.112 -p tcp -m tcp -m
> multiport --ports 22,23,24,25 -j ACCEPT
> 
> why were the packets able to get to 192.168.1.112 on port 22 when the
> packets does not even come from ports 22,23,24 or 25?

man iptables:

multiport

...

       --ports [!] port[,port[,port:port...]]
               Match if either the source or destination
               ports are equal to one
               of the given ports.

So, this is expected behavior, provided that there are no other rules
in the way.

HTH,

Joerg



!DSPAM:43299390313231087616080!

RE: Iptables Rules

[Jan Engelhardt]

>On Wednesday 2008-04-09 00:01, Minh Cao wrote:
>>Hi, 
>>Is that matter if I placed the options/extensions ( -m
>>and -p ) in different orders ? 
>
>No, but it matters between multiple -m.

On Wednesday 2008-04-09 11:23, Ukeme Noah wrote:
>Howdy,
>The last two, the ones using the state machine might give you problems if
>you use only those without specifying to allow established ssh connections.
>
>So, I'd suggest you add ,ESTABLISHED right after NEW to make the line

Adding random states to rules of which you do not have the context
is unlikely to be fruitful.

RE: Iptables Rules

[Minh Cao]

Thanks for your help !

Please explain why these two acting differently.
On #2 I can login as anonymous, but ls.
Can I combine two rules into one ?

1/ 
-A INPUT -m state --state RELATED,ESTABLISHED -j
ACCEPT
-A INPUT -m state --state NEW -p tcp -m tcp --dport 21
-j ACCEPT

2/
-A INPUT -m state --state NEW,RELATED,ESTABLISHED -p
tcp -m tcp --dport 21 -j ACCEPT






--- Jan Engelhardt <jengelh@computergmbh.de> wrote:

> 
> >On Wednesday 2008-04-09 00:01, Minh Cao wrote:
> >>Hi, 
> >>Is that matter if I placed the options/extensions
> ( -m
> >>and -p ) in different orders ? 
> >
> >No, but it matters between multiple -m.
> 
> On Wednesday 2008-04-09 11:23, Ukeme Noah wrote:
> >Howdy,
> >The last two, the ones using the state machine
> might give you problems if
> >you use only those without specifying to allow
> established ssh connections.
> >
> >So, I'd suggest you add ,ESTABLISHED right after
> NEW to make the line
> 
> Adding random states to rules of which you do not
> have the context
> is unlikely to be fruitful.
> 
> --
> To unsubscribe from this list: send the line
> "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 

RE: Iptables Rules

[Jan Engelhardt]

On Wednesday 2008-04-09 19:01, Minh Cao wrote:
>Thanks for your help !
>
>Please explain why these two acting differently.
>On #2 I can login as anonymous, but ls.
                                ^ but not ls

That's because in #2, you limit RELATED to port 21,
which is essentially meaningless.
In #1, RELATED applies to any port (as does ESTABLISHED).

>Can I combine two rules into one ?
>
>1/ 
>-A INPUT -m state --state RELATED,ESTABLISHED -j
>ACCEPT
>-A INPUT -m state --state NEW -p tcp -m tcp --dport 21
>-j ACCEPT

No.

Iptables Rules

[Minh Cao]

Hi, 
Is that matter if I placed the options/extensions ( -m
and -p ) in different orders ? 

Please tell me these 4 configurations make any
difference ... in term allows ssh to my workstation. 


-A INPUT -s 1.2.3.0/24 -p tcp -m tcp --dport 22 -j
ACCEPT 


-A INPUT -s 1.2.3.0/24 -m tcp -p tcp --dport 22 -j
ACCEPT 


-A INPUT -s 1.2.3.0/24 -p tcp -m state --state NEW -m
tcp --dport 22 -j ACCEPT 


-A INPUT -s 1.2.3.0/24 -m state --state NEW -m tcp -p
tcp --dport 22 -j ACCEPT 


Thanks ! 

Re: Iptables Rules

[Jan Engelhardt]

On Wednesday 2008-04-09 00:01, Minh Cao wrote:
>Hi, 
>Is that matter if I placed the options/extensions ( -m
>and -p ) in different orders ? 

No, but it matters between multiple -m.

>-A INPUT -s 1.2.3.0/24 -p tcp -m tcp --dport 22 -j
>ACCEPT 
>-A INPUT -s 1.2.3.0/24 -m tcp -p tcp --dport 22 -j
>ACCEPT 

no

>-A INPUT -s 1.2.3.0/24 -p tcp -m state --state NEW -m
>tcp --dport 22 -j ACCEPT 
>
>
>-A INPUT -s 1.2.3.0/24 -m state --state NEW -m tcp -p
>tcp --dport 22 -j ACCEPT 

no.

(But "-m conntrack --ctstate NEW -m tcp" and 
     "-m tcp -m conntrack --ctstate NEW" would)

Iptables rules.

[Shams Fantar]

Hello,

I am writing iptables rules. Here is the rules, they are in a script : 
http://jumble.snurf.info/iptables-start

When I use it, It blocks all access to the network. Why ?

Do you have suggestions for my rules ?

Regards,

-- 
Shams Fantar (http://snurf.info)

Re: Iptables rules.

[Eljas Alakulppi]

Add:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Reason: You aren't allowing the incoming packets from the host you are  
connected to (you send a packet, server recieves the packet, server sends  
reply, your iptables rules drop it).

Shams Fantar <sfantar@snurf.info> kirjoitti Sat, 22 Sep 2007 21:57:21  
+0300:

> Hello,
>
> I am writing iptables rules. Here is the rules, they are in a script :  
> http://jumble.snurf.info/iptables-start
>
> When I use it, It blocks all access to the network. Why ?
>
> Do you have suggestions for my rules ?
>
> Regards,
>

Re: Iptables rules.

[Mike Wright]

Shams Fantar wrote:
> Hello,
> 
> I am writing iptables rules. Here is the rules, they are in a script : 
> http://jumble.snurf.info/iptables-start
> 
> When I use it, It blocks all access to the network. Why ?
> 
> Do you have suggestions for my rules ?

There has to be a way for replies to outbound traffic to get back in. 
Maybe this (probably near the top):

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

The rules -A OUTPUT aren't needed because OUTPUT's policy is already ACCEPT.

hth,
:m)

RE: Iptables rules...

[Didier Hung Wan Luk]

Thanks :-))

Didier Hung Wan Luk
FRCI, Sibotie House
L'Anse Courtois
Pailles
Tel: 230-2869636
Fax: 230-2869629


-----Original Message-----
From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk] 
Sent: Saturday, September 07, 2002 2:37 PM
To: Netfilter Mailing List
Subject: Re: Iptables rules...

On Saturday 07 September 2002 10:39 am, Didier Hung Wan Luk wrote:

> Hi All,
>
>
> I am new to firewall/iptables can someone help me to clear up some concepts
> about firewalling?
>
> If my default rule for the input chain of my external interface is DROP
> need I again specify to DROP packets in the INPUT chain of my external
> interface?

There is only one INPUT chain.   The rules and the default policy apply to 
all interfaces.

> #My Default rule
> iptables -P INPUT DROP
>
> #Drop all attempts on my ext. interface trough port 6000:6063
>
> iptables -A INPUT -i ppp0 -p tcp --dport 6000:6063 -j DROP
>
> If I am right I think that I need not include a rule again saying to drop
> packets to my 6000;6063 ports since I do not have a rule saying to accept
> connections on these ports...

If you have a default DROP policy, then you should not (normally) need to 
specify any DROP rules.   If you do not have a rule ACCEPTing certain 
packets, then they will be DROPped by default.   That is what the policy is 
for.

For example:

iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

will drop SMTP traffic on port 25, because there is no rule ACCEPTing it.

These rules will also drop POP3, IMAP, FTP, IDENT.......   everything except 
HTTP.

Antony.

-- 

90% of network problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.

Re: Iptables rules...

[ashivale]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

Hi,
The default policy you set is the default for all the packets in that chain. Hence you need not specify it again for the INPUT chain.
bye,
Amit

Didier Hung Wan Luk wrote:
> Hi All,
> 
> 
> I am new to firewall/iptables can someone help me to clear up some concepts about firewalling?
> 
> If my default rule for the input chain of my external interface is DROP need I again specify to DROP packets in the INPUT chain of my external interface?
> 
> i.e..
> 
> #My Default rule
> iptables -P INPUT DROP
> 
> #Drop all attempts on my ext. interface trough port 6000:6063
> 
> iptables -A INPUT -i ppp0 -p tcp --dport 6000:6063 -j DROP
> 
> If I am right I think that I need not include a rule again saying to drop packets to my 6000;6063 ports since I do not have a rule saying to accept connections on these ports...
> 
> Thanks,
> 
> Didier Hung Wan Luk
> 
> 

Iptables rules...

[Didier Hung Wan Luk]

Hi All,


I am new to firewall/iptables can someone help me to clear up some concepts about firewalling?

If my default rule for the input chain of my external interface is DROP need I again specify to DROP packets in the INPUT chain of my external interface?

i.e..

#My Default rule
iptables -P INPUT DROP

#Drop all attempts on my ext. interface trough port 6000:6063

iptables -A INPUT -i ppp0 -p tcp --dport 6000:6063 -j DROP

If I am right I think that I need not include a rule again saying to drop packets to my 6000;6063 ports since I do not have a rule saying to accept connections on these ports...

Thanks,

Didier Hung Wan Luk

Re: Iptables rules...

[Antony Stone]

On Saturday 07 September 2002 10:39 am, Didier Hung Wan Luk wrote:

> Hi All,
>
>
> I am new to firewall/iptables can someone help me to clear up some concepts
> about firewalling?
>
> If my default rule for the input chain of my external interface is DROP
> need I again specify to DROP packets in the INPUT chain of my external
> interface?

There is only one INPUT chain.   The rules and the default policy apply to 
all interfaces.

> #My Default rule
> iptables -P INPUT DROP
>
> #Drop all attempts on my ext. interface trough port 6000:6063
>
> iptables -A INPUT -i ppp0 -p tcp --dport 6000:6063 -j DROP
>
> If I am right I think that I need not include a rule again saying to drop
> packets to my 6000;6063 ports since I do not have a rule saying to accept
> connections on these ports...

If you have a default DROP policy, then you should not (normally) need to 
specify any DROP rules.   If you do not have a rule ACCEPTing certain 
packets, then they will be DROPped by default.   That is what the policy is 
for.

For example:

iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

will drop SMTP traffic on port 25, because there is no rule ACCEPTing it.

These rules will also drop POP3, IMAP, FTP, IDENT.......   everything except 
HTTP.

Antony.

-- 

90% of network problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.