iptables 1.3.6 not using /etc/networks

iptables 1.3.6 not using /etc/networks

[Laurence J. Lane]

http://bugs.debian.org/398082

iptables 1.3.5 and 1.3.6 appear to read /etc/networks, but the
information is lost somewhere with 1.3.6.

  # cat /etc/networks
  foonet 10.0.0.0

  # strace -s 255 -o /tmp/foo iptables -v -A INPUT -s foonet/8 -j
ACCEPT #1.3.5 [1]
  ACCEPT  all opt -- in * out *  10.0.0.0/8  -> 0.0.0.0/0

  # strace -s 255 -o /tmp/bar iptables -v -A INPUT -s foonet/8 -j
ACCEPT #1.3.6 [2]
  iptables v1.3.6: host/network `foonet.0.0.0' not found
  Try `iptables -h' or 'iptables --help' for more information.

1. http://people.debian.org/~ljlane/stuff/strace-iptables-1.3.5.txt
2. http://people.debian.org/~ljlane/stuff/strace-iptables-1.3.6.txt

Re: iptables 1.3.6 not using /etc/networks

[Laurence J. Lane]

On 11/11/06, Laurence J. Lane <ljlane@debian.org> wrote:

>   # strace -s 255 -o /tmp/bar iptables -v -A INPUT -s foonet/8 -j
> ACCEPT #1.3.6 [2]
>   iptables v1.3.6: host/network `foonet.0.0.0' not found
>   Try `iptables -h' or 'iptables --help' for more information.

This looks like something with the pad_cidr() call in
parse_hostnetworkmask(). ltrace shows the code calling
getnetbyname("foonet.0.0.0")  instead of getentbyname("foonet").

Re: iptables 1.3.6 not using /etc/networks

[Phil Oester]

On Sat, Nov 11, 2006 at 09:35:08PM -0500, Laurence J. Lane wrote:
> On 11/11/06, Laurence J. Lane <ljlane@debian.org> wrote:
> 
> >  # strace -s 255 -o /tmp/bar iptables -v -A INPUT -s foonet/8 -j
> >ACCEPT #1.3.6 [2]
> >  iptables v1.3.6: host/network `foonet.0.0.0' not found
> >  Try `iptables -h' or 'iptables --help' for more information.
> 
> This looks like something with the pad_cidr() call in
> parse_hostnetworkmask(). ltrace shows the code calling
> getnetbyname("foonet.0.0.0")  instead of getentbyname("foonet").

Correct.  This was added between 1.3.5 and 1.3.6 to more sanely
handle CIDR notation.  See the commit:

https://lists.netfilter.org/pipermail/netfilter-cvslog/2006-July/005122.html

Not sure offhand how we can satisfy both cases here, but I'd posit
that more people use x.x.x/24 than use foonet/x notation.  

Phil

Re: iptables 1.3.6 not using /etc/networks

[Alexey Toptygin]

On Sun, 12 Nov 2006, Phil Oester wrote:

> On Sat, Nov 11, 2006 at 09:35:08PM -0500, Laurence J. Lane wrote:
>> On 11/11/06, Laurence J. Lane <ljlane@debian.org> wrote:
>>
>>>  # strace -s 255 -o /tmp/bar iptables -v -A INPUT -s foonet/8 -j
>>> ACCEPT #1.3.6 [2]
>>>  iptables v1.3.6: host/network `foonet.0.0.0' not found
>>>  Try `iptables -h' or 'iptables --help' for more information.
>>
>> This looks like something with the pad_cidr() call in
>> parse_hostnetworkmask(). ltrace shows the code calling
>> getnetbyname("foonet.0.0.0")  instead of getentbyname("foonet").
>
> Correct.  This was added between 1.3.5 and 1.3.6 to more sanely
> handle CIDR notation.  See the commit:
>
> https://lists.netfilter.org/pipermail/netfilter-cvslog/2006-July/005122.html
>
> Not sure offhand how we can satisfy both cases here, but I'd posit
> that more people use x.x.x/24 than use foonet/x notation.

Isn't it always true that foonet/y starts with a letter and x.x.x/y starts 
with a digit? In this case, checking that the string starts with a digit 
before searching it for '.' characters and appending '.0's should work.

 			Alexey

Re: iptables 1.3.6 not using /etc/networks

[Phil Oester]

On Sun, Nov 12, 2006 at 07:36:34PM +0000, Alexey Toptygin wrote:
> >Not sure offhand how we can satisfy both cases here, but I'd posit
> >that more people use x.x.x/24 than use foonet/x notation.
> 
> Isn't it always true that foonet/y starts with a letter and x.x.x/y starts 
> with a digit? In this case, checking that the string starts with a digit 
> before searching it for '.' characters and appending '.0's should work.

But if you use a FQDN such as www.domain.com/24, then shouldn't that
then imply <ip of www.domain.com>/24?  That's why I didn't make the
exception for letters vs. digits, as it could be used either way.

/etc/networks certainly throws a wrench in the works.

Phil

Re: iptables 1.3.6 not using /etc/networks

[Alexey Toptygin]

On Sun, 12 Nov 2006, Phil Oester wrote:

> On Sun, Nov 12, 2006 at 07:36:34PM +0000, Alexey Toptygin wrote:
>>> Not sure offhand how we can satisfy both cases here, but I'd posit
>>> that more people use x.x.x/24 than use foonet/x notation.
>>
>> Isn't it always true that foonet/y starts with a letter and x.x.x/y starts
>> with a digit? In this case, checking that the string starts with a digit
>> before searching it for '.' characters and appending '.0's should work.
>
> But if you use a FQDN such as www.domain.com/24, then shouldn't that
> then imply <ip of www.domain.com>/24?  That's why I didn't make the
> exception for letters vs. digits, as it could be used either way.

I don't understand what you mean. I think if it starts with a digit, it 
must be an IP (or part of an IP with 0's dropped), else it is a network 
name or a domain name (since neither of those can start with digits). If 
it's an IP by the above logic, then pad it with '.0's as necessary (or 
translate directly into a number without padding first). If it's not an 
IP, first call getnetbyname on it and if that returns NULL call 
gethostbyname. I think this algorithm works in all cases, unless I'm 
missing something.

 			Alexey

Re: iptables 1.3.6 not using /etc/networks

[Martijn Lievaart]

Alexey Toptygin wrote:

>
> I don't understand what you mean. I think if it starts with a digit, 
> it must be an IP (or part of an IP with 0's dropped), else it is a 
> network name or a domain name (since neither of those can start with 
> digits). If it's an IP by the above logic, then pad it with '.0's as 
> necessary (or translate directly into a number without padding first). 
> If it's not an IP, first call getnetbyname on it and if that returns 
> NULL call gethostbyname. I think this algorithm works in all cases, 
> unless I'm missing something.


Domains can legitimately start with digits. F.i. 9292ov.nl. However, 
checking for a valid IP address (in all forms) should be trivial.

M4

Re: iptables 1.3.6 not using /etc/networks

[Alexey Toptygin]

On Mon, 13 Nov 2006, Martijn Lievaart wrote:

> Alexey Toptygin wrote:
>
>> I don't understand what you mean. I think if it starts with a digit, it 
>> must be an IP (or part of an IP with 0's dropped), else it is a network 
>> name or a domain name (since neither of those can start with digits). If 
>> it's an IP by the above logic, then pad it with '.0's as necessary (or 
>> translate directly into a number without padding first). If it's not an IP, 
>> first call getnetbyname on it and if that returns NULL call gethostbyname. 
>> I think this algorithm works in all cases, unless I'm missing something.
>
> Domains can legitimately start with digits. F.i. 9292ov.nl. However, checking 
> for a valid IP address (in all forms) should be trivial.

No, domains can't start with a digit. See RFC 1034:

ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt

>From which I quote:

> <domain> ::= <subdomain> | " "
>
> <subdomain> ::= <label> | <subdomain> "." <label>
>
> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
>
> <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
>
> <let-dig-hyp> ::= <let-dig> | "-"
>
> <let-dig> ::= <letter> | <digit>
>
> <letter> ::= any one of the 52 alphabetic characters A through Z in
> upper case and a through z in lower case
>
> <digit> ::= any one of the ten digits 0 through 9

 			Alexey

Re: iptables 1.3.6 not using /etc/networks

[Martijn Lievaart]

Alexey Toptygin wrote:

> On Mon, 13 Nov 2006, Martijn Lievaart wrote:
>
>> Alexey Toptygin wrote:
>>
>>> I don't understand what you mean. I think if it starts with a digit, 
>>> it must be an IP (or part of an IP with 0's dropped), else it is a 
>>> network name or a domain name (since neither of those can start with 
>>> digits). If it's an IP by the above logic, then pad it with '.0's as 
>>> necessary (or translate directly into a number without padding 
>>> first). If it's not an IP, first call getnetbyname on it and if that 
>>> returns NULL call gethostbyname. I think this algorithm works in all 
>>> cases, unless I'm missing something.
>>
>>
>> Domains can legitimately start with digits. F.i. 9292ov.nl. However, 
>> checking for a valid IP address (in all forms) should be trivial.
>
>
> No, domains can't start with a digit. See RFC 1034:
>
> ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt
>
Domains can and do start with a digit, see RFC1912 section 2.1. Think 
3com.com.

M4

Re: iptables 1.3.6 not using /etc/networks

[Alexey Toptygin]

On Mon, 13 Nov 2006, Martijn Lievaart wrote:

>> No, domains can't start with a digit. See RFC 1034:
>> 
>> ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt
>> 
> Domains can and do start with a digit, see RFC1912 section 2.1. Think 
> 3com.com.

This is news to me, and isn't reflected in the current standard (which is 
still RFC 1034), but you are right that it's widely implemented. It seems 
wierd that the Host Requirements standard can override the DNS standard 
without the DNS standard being updated...

 			Alexey

offtopic Re: iptables 1.3.6 not using /etc/networks

[Amin Azez]

* Alexey Toptygin wrote, On 13/11/06 21:23:
> On Mon, 13 Nov 2006, Martijn Lievaart wrote:
> 
>>> No, domains can't start with a digit. See RFC 1034:
>>>
>>> ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt
>>>
>> Domains can and do start with a digit, see RFC1912 section 2.1. Think
>> 3com.com.
> 
> This is news to me, and isn't reflected in the current standard (which
> is still RFC 1034), but you are right that it's widely implemented. It
> seems wierd that the Host Requirements standard can override the DNS
> standard without the DNS standard being updated...


It's the same with SMTP, emails contain . in the left-hand-side despite
it being counter-RFC for years.

Perhaps the self depracating title of the standard has something to do
with it... anyway...

Sam

Re: iptables 1.3.6 not using /etc/networks

[Benny Amorsen]

>>>>> "AT" == Alexey Toptygin <alexeyt@freeshell.org> writes:

AT> No, domains can't start with a digit. See RFC 1034:

AT> ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt

>> From which I quote:

>> <domain> ::= <subdomain> | " "
>> 

You forgot to quote the section heading:

>> 3.5. Preferred name syntax

You also forgot this bit:

>> The following syntax will result in fewer problems with many
>> applications that use domain names (e.g., mail, TELNET).

as well as numerous other places in that section, where it is made
very clear that the syntax is merely a recommendation.

RFC 1034 is probably the most misread RFC in existence. Please do not
contribute further to this problem.


/Benny

Re: iptables 1.3.6 not using /etc/networks

[Phil Oester]

On Mon, Nov 13, 2006 at 12:58:48AM +0000, Alexey Toptygin wrote:
> >But if you use a FQDN such as www.domain.com/24, then shouldn't that
> >then imply <ip of www.domain.com>/24?  That's why I didn't make the
> >exception for letters vs. digits, as it could be used either way.
> 
> I don't understand what you mean. I think if it starts with a digit, it 
> must be an IP (or part of an IP with 0's dropped), else it is a network 
> name or a domain name (since neither of those can start with digits). If 
> it's an IP by the above logic, then pad it with '.0's as necessary (or 
> translate directly into a number without padding first). If it's not an 
> IP, first call getnetbyname on it and if that returns NULL call 
> gethostbyname. I think this algorithm works in all cases, unless I'm 
> missing something.

What I meant was some people might want to include the /24 a host sits
on, and use something like "mydomain.com/24".  When the name gets
translated to 1.2.3.4, the cidr would make it 1.2.3.0/24.

Also, as Martijn points out, just starting with digit doesn't imply
an IP, as hosts can start with digits also.

The difficulty here is we can't easily have /etc/networks be processed
and have shorthand CIDR notation (such as 10.10.10/24) work.

Phil

Re: iptables 1.3.6 not using /etc/networks

[Alexey Toptygin]

On Mon, 13 Nov 2006, Phil Oester wrote:

> On Mon, Nov 13, 2006 at 12:58:48AM +0000, Alexey Toptygin wrote:
>>> But if you use a FQDN such as www.domain.com/24, then shouldn't that
>>> then imply <ip of www.domain.com>/24?  That's why I didn't make the
>>> exception for letters vs. digits, as it could be used either way.
>>
>> I don't understand what you mean. I think if it starts with a digit, it
>> must be an IP (or part of an IP with 0's dropped), else it is a network
>> name or a domain name (since neither of those can start with digits). If
>> it's an IP by the above logic, then pad it with '.0's as necessary (or
>> translate directly into a number without padding first). If it's not an
>> IP, first call getnetbyname on it and if that returns NULL call
>> gethostbyname. I think this algorithm works in all cases, unless I'm
>> missing something.
>
> What I meant was some people might want to include the /24 a host sits
> on, and use something like "mydomain.com/24".  When the name gets
> translated to 1.2.3.4, the cidr would make it 1.2.3.0/24.
>
> Also, as Martijn points out, just starting with digit doesn't imply
> an IP, as hosts can start with digits also.

I think my mail server ate my replies to this, so here it is a third time. 
Sorry if this is a duplicate; if it is, please let me know and I'll shut 
up (my incoming mail seems to be working fine). DNS domain names are not 
allowed to start with digits; I quote RFC 1034:

> <domain> ::= <subdomain> | " "
> <subdomain> ::= <label> | <subdomain> "." <label>
> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
> <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
> <let-dig-hyp> ::= <let-dig> | "-"
> <let-dig> ::= <letter> | <digit>
> <letter> ::= any one of the 52 alphabetic characters A through Z in
> upper case and a through z in lower case
> <digit> ::= any one of the ten digits 0 through 9

Thus, if the first character is a digit, the string cannot be a domain name.
I guess it could still be a network name in /etc/networks, but that would 
be a bit pathological. If you still don't like this approach, then how 
about:

1) parse and remove any trailing /x
2) try to parse string you get from step 1 as a (partial) IP address. If
    it parses OK, it's an IP, otherwise
3) look the string you get from step 1 (with no added .0s from step 2, if
    any) up via getnetbyname. If that returns non-NULL, use this result,
    otherwise
4) look the string you get from step 1 (with no added .0s from step 2, if
    any) up via gethostbyname. If that returns non-NULL, use that, otherwise
5) fail.
 			Alexey

Re: iptables 1.3.6 not using /etc/networks

[scott comer (sccomer)]

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



Alexey Toptygin wrote:
> On Mon, 13 Nov 2006, Phil Oester wrote:
>
>> On Mon, Nov 13, 2006 at 12:58:48AM +0000, Alexey Toptygin wrote:
>>>> But if you use a FQDN such as www.domain.com/24, then shouldn't that
>>>> then imply <ip of www.domain.com>/24?  That's why I didn't make the
>>>> exception for letters vs. digits, as it could be used either way.
>>>
>>> I don't understand what you mean. I think if it starts with a digit, it
>>> must be an IP (or part of an IP with 0's dropped), else it is a network
>>> name or a domain name (since neither of those can start with 
>>> digits). If
>>> it's an IP by the above logic, then pad it with '.0's as necessary (or
>>> translate directly into a number without padding first). If it's not an
>>> IP, first call getnetbyname on it and if that returns NULL call
>>> gethostbyname. I think this algorithm works in all cases, unless I'm
>>> missing something.
>>
>> What I meant was some people might want to include the /24 a host sits
>> on, and use something like "mydomain.com/24".  When the name gets
>> translated to 1.2.3.4, the cidr would make it 1.2.3.0/24.
>>
>> Also, as Martijn points out, just starting with digit doesn't imply
>> an IP, as hosts can start with digits also.
>
> I think my mail server ate my replies to this, so here it is a third 
> time. Sorry if this is a duplicate; if it is, please let me know and 
> I'll shut up (my incoming mail seems to be working fine). DNS domain 
> names are not allowed to start with digits; I quote RFC 1034:
>
>> <domain> ::= <subdomain> | " "
>> <subdomain> ::= <label> | <subdomain> "." <label>
>> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
>> <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
>> <let-dig-hyp> ::= <let-dig> | "-"
>> <let-dig> ::= <letter> | <digit>
>> <letter> ::= any one of the 52 alphabetic characters A through Z in
>> upper case and a through z in lower case
>> <digit> ::= any one of the ten digits 0 through 9
>
the above is obsolete by rfc 1123, section 2.1, Host Names and Numbers. 
only a complete
parse of the name will show that you have the ipv4 address instead 
(#.#.#.#):

"..., then a full syntactic check must be made, because a segment of a 
host domain
name is now allowed to begin with a digit and could legally be entirely 
numeric
(see Section 6.1.2.4). However, a valid host name can never have the 
dotted-decimal
form #.#.#.#, since at least the highest-level component label will be 
alphabetic."
> Thus, if the first character is a digit, the string cannot be a domain 
> name.
> I guess it could still be a network name in /etc/networks, but that 
> would be a bit pathological. If you still don't like this approach, 
> then how about:
>
> 1) parse and remove any trailing /x
> 2) try to parse string you get from step 1 as a (partial) IP address. If
>    it parses OK, it's an IP, otherwise
> 3) look the string you get from step 1 (with no added .0s from step 2, if
>    any) up via getnetbyname. If that returns non-NULL, use this result,
>    otherwise
> 4) look the string you get from step 1 (with no added .0s from step 2, if
>    any) up via gethostbyname. If that returns non-NULL, use that, 
> otherwise
> 5) fail.
>             Alexey

Re: iptables 1.3.6 not using /etc/networks

[Laurence J. Lane]

On 11/12/06, Phil Oester <kernel@linuxace.com> wrote:

> Not sure offhand how we can satisfy both cases here, but I'd posit
> that more people use x.x.x/24 than use foonet/x notation.

I have another bug report saying it breaks stuff from /etc/hosts too.

How about something like this? I assume valid IP characters are in the
range of 0-9 and a dot. This will skip pad_cidr() if any characters
outside of that range are encountered. Plain bad IP addresses are
apparently validated elsewhere. Of course, I could be wrong about all
of this.

--- iptables.c.ORIG     2006-11-18 16:40:30.902915398 -0500
+++ iptables.c  2006-11-18 16:38:31.549789934 -0500
@@ -696,13 +696,15 @@
        char buf[256];
        char *p;
        int i, j, k, n;
+       char *vipchars = "0123456789.\0";

        strncpy(buf, name, sizeof(buf) - 1);
        buf[sizeof(buf) - 1] = '\0';
        if ((p = strrchr(buf, '/')) != NULL) {
                *p = '\0';
                addrp = parse_mask(p + 1);
-               if (strrchr(p + 1, '.') == NULL)
+               if (strrchr(p + 1, '.') == NULL
+                 && strspn(buf,vipchars) == strlen(buf))
                        pad_cidr(buf);
        } else
                addrp = parse_mask(NULL);


Simple tests:

  # echo "foonet0 3.2.1.0" > /etc/networks
  # for i in 8 16 24 32; do iptables -v -A INPUT -s foonet0/$i -j ACCEPT; done
  ACCEPT  0 opt -- in * out *  3.2.1.0  -> 0.0.0.0/0
  ACCEPT  0 opt -- in * out *  3.2.1.0/24  -> 0.0.0.0/0
  ACCEPT  0 opt -- in * out *  3.2.0.0/16  -> 0.0.0.0/0
  ACCEPT  0 opt -- in * out *  3.0.0.0/8  -> 0.0.0.0/0

  # echo 1.2.3.4 foo.bar.baz.quuz >> /etc/hosts
  # for i in 8 16 24 32; do iptables -v -A INPUT -s
foo.bar.baz.quuz/$i -j ACCEPT; done
  ACCEPT  0 opt -- in * out *  1.0.0.0/8  -> 0.0.0.0/0
  ACCEPT  0 opt -- in * out *  1.2.0.0/16  -> 0.0.0.0/0
  ACCEPT  0 opt -- in * out *  1.2.3.0/24  -> 0.0.0.0/0
  ACCEPT  0 opt -- in * out *  1.2.3.4  -> 0.0.0.0/0

Re: iptables 1.3.6 not using /etc/networks

[Laurence J. Lane]

On 11/18/06, Laurence J. Lane <ljlane@debian.org> wrote:

>   # echo "foonet0 3.2.1.0" > /etc/networks
>   # for i in 8 16 24 32; do iptables -v -A INPUT -s foonet0/$i -j ACCEPT; done

I pasted the wrong line there. The list is clearly reversed.

Re: iptables 1.3.6 not using /etc/networks

[Pablo Neira Ayuso]

Laurence J. Lane wrote:
> On 11/12/06, Phil Oester <kernel@linuxace.com> wrote:
> 
>> Not sure offhand how we can satisfy both cases here, but I'd posit
>> that more people use x.x.x/24 than use foonet/x notation.
> 
> I have another bug report saying it breaks stuff from /etc/hosts too.
> 
> How about something like this? I assume valid IP characters are in the
> range of 0-9 and a dot. This will skip pad_cidr() if any characters
> outside of that range are encountered. Plain bad IP addresses are
> apparently validated elsewhere. Of course, I could be wrong about all
> of this.

Apparently /etc/host accepts entries composed of dots, e.g.

foo.machine     192.168.100.100

So this assumption can be OK as soon as nobody is using such notation.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: iptables 1.3.6 not using /etc/networks

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Laurence J. Lane wrote:
> 
>>On 11/12/06, Phil Oester <kernel@linuxace.com> wrote:
>>
>>
>>>Not sure offhand how we can satisfy both cases here, but I'd posit
>>>that more people use x.x.x/24 than use foonet/x notation.
>>
>>I have another bug report saying it breaks stuff from /etc/hosts too.
>>
>>How about something like this? I assume valid IP characters are in the
>>range of 0-9 and a dot. This will skip pad_cidr() if any characters
>>outside of that range are encountered. Plain bad IP addresses are
>>apparently validated elsewhere. Of course, I could be wrong about all
>>of this.
> 
> 
> Apparently /etc/host accepts entries composed of dots, e.g.
> 
> foo.machine     192.168.100.100
> 
> So this assumption can be OK as soon as nobody is using such notation.

I haven't followed this fully, but seen a lot of patches floating
around. Is there already some consensus on which patch to use?

Re: iptables 1.3.6 not using /etc/networks

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> I haven't followed this fully, but seen a lot of patches floating
> around. Is there already some consensus on which patch to use?

I posted a patch that fixes the problem although I didn't get any 
feedback from people.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: iptables 1.3.6 not using /etc/networks

[Phil Oester]

On Thu, Nov 23, 2006 at 09:56:51PM +0100, Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
> >I haven't followed this fully, but seen a lot of patches floating
> >around. Is there already some consensus on which patch to use?
> 
> I posted a patch that fixes the problem although I didn't get any 
> feedback from people.

Sorry Pablo, I haven't had time to review your patch yet.  I'll
take a closer look at it this weekend.

Phil

Re: iptables 1.3.6 not using /etc/networks

[Patrick McHardy]

Phil Oester wrote:
> On Thu, Nov 23, 2006 at 09:56:51PM +0100, Pablo Neira Ayuso wrote:
> 
>>I posted a patch that fixes the problem although I didn't get any 
>>feedback from people.
> 
> 
> Sorry Pablo, I haven't had time to review your patch yet.  I'll
> take a closer look at it this weekend.


Thanks guys, please let me know when you want me to apply it.
I want to make another iptables release soon because of the
compilation errors with the endian annotations in 2.6.19.

Re: iptables 1.3.6 not using /etc/networks

[Phil Oester]

On Fri, Nov 24, 2006 at 09:43:30AM +0100, Patrick McHardy wrote:
> Thanks guys, please let me know when you want me to apply it.
> I want to make another iptables release soon because of the
> compilation errors with the endian annotations in 2.6.19.

I've reviewed Pablo's patch and it looks good to me.  It handles
the CIDR case nicely, as well as fixing up the breakage I 
introduced in /etc/{networks,hosts} handling.  

Thanks Pablo!

Phil

Re: iptables 1.3.6 not using /etc/networks

[Patrick McHardy]

Phil Oester wrote:
> On Fri, Nov 24, 2006 at 09:43:30AM +0100, Patrick McHardy wrote:
> 
>>Thanks guys, please let me know when you want me to apply it.
>>I want to make another iptables release soon because of the
>>compilation errors with the endian annotations in 2.6.19.
> 
> 
> I've reviewed Pablo's patch and it looks good to me.  It handles
> the CIDR case nicely, as well as fixing up the breakage I 
> introduced in /etc/{networks,hosts} handling.  

Thanks everyone, I've applied Pablo's patch.

Re: iptables 1.3.6 not using /etc/networks

[Amin Azez]

* Pablo Neira Ayuso wrote, On 20/11/06 00:00:
> Laurence J. Lane wrote:
>> On 11/12/06, Phil Oester <kernel@linuxace.com> wrote:
>>
>>> Not sure offhand how we can satisfy both cases here, but I'd posit
>>> that more people use x.x.x/24 than use foonet/x notation.
>> I have another bug report saying it breaks stuff from /etc/hosts too.
>>
>> How about something like this? I assume valid IP characters are in the
>> range of 0-9 and a dot. This will skip pad_cidr() if any characters
>> outside of that range are encountered. Plain bad IP addresses are
>> apparently validated elsewhere. Of course, I could be wrong about all
>> of this.
> 
> Apparently /etc/host accepts entries composed of dots, e.g.
> 
> foo.machine     192.168.100.100
> 
> So this assumption can be OK as soon as nobody is using such notation.

I do, so do lots of web developers I know; it helps them test websites
under  the correct domain.

Does the patch you suggested depend on this not being the case?

Sam

Re: iptables 1.3.6 not using /etc/networks

[Pablo Neira Ayuso]

Amin Azez wrote:
> * Pablo Neira Ayuso wrote, On 20/11/06 00:00:
>> Laurence J. Lane wrote:
>>> On 11/12/06, Phil Oester <kernel@linuxace.com> wrote:
>>>
>>>> Not sure offhand how we can satisfy both cases here, but I'd posit
>>>> that more people use x.x.x/24 than use foonet/x notation.
>>> I have another bug report saying it breaks stuff from /etc/hosts too.
>>>
>>> How about something like this? I assume valid IP characters are in the
>>> range of 0-9 and a dot. This will skip pad_cidr() if any characters
>>> outside of that range are encountered. Plain bad IP addresses are
>>> apparently validated elsewhere. Of course, I could be wrong about all
>>> of this.
>> Apparently /etc/host accepts entries composed of dots, e.g.
>>
>> foo.machine     192.168.100.100
>>
>> So this assumption can be OK as soon as nobody is using such notation.
> 
> I do, so do lots of web developers I know; it helps them test websites
> under  the correct domain.
> 
> Does the patch you suggested depend on this not being the case?

No, because I considered that such assumption is wrong.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: iptables 1.3.6 not using /etc/networks

[Pablo Neira Ayuso]

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

Phil Oester wrote:
> On Sat, Nov 11, 2006 at 09:35:08PM -0500, Laurence J. Lane wrote:
>> On 11/11/06, Laurence J. Lane <ljlane@debian.org> wrote:
>>
>>>  # strace -s 255 -o /tmp/bar iptables -v -A INPUT -s foonet/8 -j
>>> ACCEPT #1.3.6 [2]
>>>  iptables v1.3.6: host/network `foonet.0.0.0' not found
>>>  Try `iptables -h' or 'iptables --help' for more information.
>> This looks like something with the pad_cidr() call in
>> parse_hostnetworkmask(). ltrace shows the code calling
>> getnetbyname("foonet.0.0.0")  instead of getentbyname("foonet").
> 
> Correct.  This was added between 1.3.5 and 1.3.6 to more sanely
> handle CIDR notation.  See the commit:
> 
> https://lists.netfilter.org/pipermail/netfilter-cvslog/2006-July/005122.html
> 
> Not sure offhand how we can satisfy both cases here, but I'd posit
> that more people use x.x.x/24 than use foonet/x notation.  

I think that we have to fix this because it also breaks hostnames
defined in /etc/hosts, I have attached a patch to adress this issue.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3686 bytes --]

Index: iptables.c
===================================================================
--- iptables.c	(revisión: 6678)
+++ iptables.c	(copia de trabajo)
@@ -273,8 +273,13 @@
 		   "invalid port/service `%s' specified", port);
 }
 
-struct in_addr *
-dotted_to_addr(const char *dotted)
+enum {
+	IPT_DOTTED_ADDR = 0,
+	IPT_DOTTED_MASK
+};
+
+static struct in_addr *
+__dotted_to_addr(const char *dotted, int type)
 {
 	static struct in_addr addr;
 	unsigned char *addrp;
@@ -290,9 +295,21 @@
 
 	p = buf;
 	for (i = 0; i < 3; i++) {
-		if ((q = strchr(p, '.')) == NULL)
-			return (struct in_addr *) NULL;
+		if ((q = strchr(p, '.')) == NULL) {
+			if (type == IPT_DOTTED_ADDR) {
+				/* autocomplete, this is a network address */
+				if (string_to_number(p, 0, 255, &onebyte) == -1)
+					return (struct in_addr *) NULL;
 
+				addrp[i] = (unsigned char) onebyte;
+				while (i < 3)
+					addrp[++i] = 0;
+
+				return &addr;
+			} else
+				return (struct in_addr *) NULL;
+		}
+
 		*q = '\0';
 		if (string_to_number(p, 0, 255, &onebyte) == -1)
 			return (struct in_addr *) NULL;
@@ -310,6 +327,18 @@
 	return &addr;
 }
 
+struct in_addr *
+dotted_to_addr(const char *dotted)
+{
+	return __dotted_to_addr(dotted, IPT_DOTTED_ADDR);
+}
+
+struct in_addr *
+dotted_to_mask(const char *dotted)
+{
+	return __dotted_to_addr(dotted, IPT_DOTTED_MASK);
+}
+
 static struct in_addr *
 network_to_addr(const char *name)
 {
@@ -607,34 +636,6 @@
 	return (char *) NULL;
 }
 
-static void 
-pad_cidr(char *cidr)
-{
-	char *p, *q;
-	unsigned int onebyte;
-	int i, j;
-	char buf[20];
-
-	/* copy dotted string, because we need to modify it */
-	strncpy(buf, cidr, sizeof(buf) - 1);
-	buf[sizeof(buf) - 1] = '\0';
-
-	p = buf;
-	for (i = 0; i <= 3; i++) {
-		if ((q = strchr(p, '.')) == NULL)
-			break;
-		*q = '\0';
-		if (string_to_number(p, 0, 255, &onebyte) == -1)
-			return;
-		p = q + 1;
-	}
-
-	/* pad remaining octets with zeros */
-	for (j = i; j < 3; j++) {
-		strcat(cidr, ".0");
-	}
-}
-
 /*
  *	All functions starting with "parse" should succeed, otherwise
  *	the program fails.
@@ -674,7 +675,7 @@
 		maskaddr.s_addr = 0xFFFFFFFF;
 		return &maskaddr;
 	}
-	if ((addrp = dotted_to_addr(mask)) != NULL)
+	if ((addrp = dotted_to_mask(mask)) != NULL)
 		/* dotted_to_addr already returns a network byte order addr */
 		return addrp;
 	if (string_to_number(mask, 0, 32, &bits) == -1)
@@ -703,8 +704,6 @@
 	if ((p = strrchr(buf, '/')) != NULL) {
 		*p = '\0';
 		addrp = parse_mask(p + 1);
-		if (strrchr(p + 1, '.') == NULL)
-			pad_cidr(buf);
 	} else
 		addrp = parse_mask(NULL);
 	inaddrcpy(maskp, addrp);
Index: extensions/libipt_NETMAP.c
===================================================================
--- extensions/libipt_NETMAP.c	(revisión: 6678)
+++ extensions/libipt_NETMAP.c	(copia de trabajo)
@@ -86,7 +86,7 @@
 	range->min_ip = ip->s_addr;
 	if (slash) {
 		if (strchr(slash+1, '.')) {
-			ip = dotted_to_addr(slash+1);
+			ip = dotted_to_mask(slash+1);
 			if (!ip)
 				exit_error(PARAMETER_PROBLEM, "Bad netmask `%s'\n",
 					   slash+1);
Index: include/iptables.h
===================================================================
--- include/iptables.h	(revisión: 6678)
+++ include/iptables.h	(copia de trabajo)
@@ -154,6 +154,7 @@
 extern int service_to_port(const char *name, const char *proto);
 extern u_int16_t parse_port(const char *port, const char *proto);
 extern struct in_addr *dotted_to_addr(const char *dotted);
+extern struct in_addr *dotted_to_mask(const char *dotted);
 extern char *addr_to_dotted(const struct in_addr *addrp);
 extern char *addr_to_anyname(const struct in_addr *addr);
 extern char *mask_to_dotted(const struct in_addr *mask);

Re: iptables 1.3.6 not using /etc/networks

[Alexey Toptygin]

Sorry if this is a duplicate message, but I haven't seen the first copy 
show up in the list archives so I suspect my mail server ate it.

On Mon, 13 Nov 2006, Martijn Lievaart wrote:

> Alexey Toptygin wrote:
> 
>> I don't understand what you mean. I think if it starts with a digit, it must 
>> be an IP (or part of an IP with 0's dropped), else it is a network name or a 
>> domain name (since neither of those can start with digits). If it's an IP by 
>> the above logic, then pad it with '.0's as necessary (or translate directly 
>> into a number without padding first). If it's not an IP, first call 
>> getnetbyname on it and if that returns NULL call gethostbyname. I think this 
>> algorithm works in all cases, unless I'm missing something.
> 
> Domains can legitimately start with digits. F.i. 9292ov.nl. However, checking 
> for a valid IP address (in all forms) should be trivial.

No, domains can't start with a digit. See RFC 1034:

ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt

>From which I quote:

> <domain> ::= <subdomain> | " "
> 
> <subdomain> ::= <label> | <subdomain> "." <label>
> 
> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
> 
> <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
> 
> <let-dig-hyp> ::= <let-dig> | "-"
> 
> <let-dig> ::= <letter> | <digit>
> 
> <letter> ::= any one of the 52 alphabetic characters A through Z in
> upper case and a through z in lower case
> 
> <digit> ::= any one of the ten digits 0 through 9

 			Alexey

Re: iptables 1.3.6 not using /etc/networks

[G.W. Haywood]

Hi there,

On Mon, 13 Nov 2006 Alexey Toptygin wrote:

> No, domains can't start with a digit. See RFC 1034:

See also

http://www.3m.com

:)

--

73,
Ged.

Re: iptables 1.3.6 not using /etc/networks

[Grant Coady]

On Tue, 14 Nov 2006 10:17:31 +0000 (GMT), "G.W. Haywood" <ged@jubileegroup.co.uk> wrote:

>Hi there,
>
>On Mon, 13 Nov 2006 Alexey Toptygin wrote:
>
>> No, domains can't start with a digit. See RFC 1034:
>
>See also
>
>http://www.3m.com

http://3m.com/

Grant.