In comp.os.linux.development.system Pavel Vasilyev wrote in part:
> As well as where in a kernel it is possible to forbid to
> open tcp/udp connections on 0.0.0.0 address?

For inbound connections, the standard place would be
/etc/hosts.allow and /etc/hosts.deny

> if (requet_open_addr == ' 0.0.0.0 ')
> return requet_open_addr = ' 192.168.0.1 ';

This looks more like outbound. You could probably
add an entry with /sbin/route .

-- Robert

On Apr 5, 7:08 am, "Pavel Vasilyev" wrote:
> As well as where in a kernel it is possible to forbid to open tcp/udp
> connections on 0.0.0.0 address?

You /do/ realize that the 0.0.0.0 address is an established standard
address that means "all IP addresses on this system", don't you? Be
aware that if you 'forbid' such connections, you'll break a fair
number of your networked apps.

You'll want to change the behaviour of ip_sockglue.c and ipconfig.c in
your linux/net source code and recompile a new kernel. Remove the
special handling for INADDR_ANY, and replace it with error handling
logic.

Luck be with you
--
Lew
(who is always amazed at the foolish things that people will do to
their computers when they don't know what they are doing)

In comp.os.linux.development.system Lew Pitcher wrote:
| On Apr 5, 7:08 am, "Pavel Vasilyev" wrote:
|> As well as where in a kernel it is possible to forbid to open tcp/udp
|> connections on 0.0.0.0 address?
|
| You /do/ realize that the 0.0.0.0 address is an established standard
| address that means "all IP addresses on this system", don't you? Be
| aware that if you 'forbid' such connections, you'll break a fair
| number of your networked apps.

It's not even clear exactly what he wants to do with this. A couple of
the possibilities I see are:

1. Prohibit binding to address 0.0.0.0 (yield EPERM or such for this).
And should this restriction also apply to root or just non-root.

2. Prohibit connection establishment from outside connections when
the listening port was bound to 0.0.0.0. Of course this can be
easily done by changing the binding to 127.0.0.1 unless the OP
might want to allow some local LAN connections.

The latter might be better done via a firewall or iptables.

I have been pondering a peculiar special handling of addresses in 0.0.0.0/8
via iptables. It would work like this. The kernel would have a set of IP
address maps much like routing tables, possibly implemented the same way.
Some interface would be provided to manipulate them. Each would have an ID
that is numeric. When a rule in iptables has an address like 0.1.X.Y, then
instead of doing the compare of the address in the rule to the address in
the packet buffer that the rule specifies, the address in the packet buffer
would be used as the index in a lookup of the map with ID X.Y to see if it
is present (or is in a subnet that is present). If so, the rule is then
handled as if the addresses matched. If absent, it is handled as if the
addresses did not match. The tools to handle iptables would not need to
be changed unless they would block use of 0.1.0.0/16. The kernel code to
handle this would have to be changed where the address compares take place.
And code would have to be added to manage the set of maps (perhaps by means
of root-only access to some new /proc file). This would make it easier to
manage iptables, allowing one to put logic, but not content, in the rule
tables, and use the maps to put content, updatable rapidly on the fly. For
this to be safe, we would have to be sure the special address range used is
never going to be used for something else. I don't know if that can be
safely assumed about 0.1.0.0/16.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-04-06-1530@ipal.net |
|------------------------------------/-------------------------------------|

Hello,

phil-news-nospam@ipal.net a écrit :
>
> I have been pondering a peculiar special handling of addresses in 0.0.0.0/8
> via iptables. It would work like this. The kernel would have a set of IP
> address maps much like routing tables, possibly implemented the same way.
> Some interface would be provided to manipulate them. Each would have an ID
> that is numeric. When a rule in iptables has an address like 0.1.X.Y, then
> instead of doing the compare of the address in the rule to the address in
> the packet buffer that the rule specifies, the address in the packet buffer
> would be used as the index in a lookup of the map with ID X.Y to see if it
> is present (or is in a subnet that is present). If so, the rule is then
> handled as if the addresses matched. If absent, it is handled as if the
> addresses did not match. The tools to handle iptables would not need to
> be changed unless they would block use of 0.1.0.0/16. The kernel code to
> handle this would have to be changed where the address compares take place.
> And code would have to be added to manage the set of maps (perhaps by means
> of root-only access to some new /proc file). This would make it easier to
> manage iptables, allowing one to put logic, but not content, in the rule
> tables, and use the maps to put content, updatable rapidly on the fly.

This looks like ipset.

By the way, what is special in 0.1.0.0/16 ?

On Apr 5, 4:08 am, "Pavel Vasilyev" wrote:
> As well as where in a kernel it is possible to forbid to open tcp/udp
> connections on 0.0.0.0 address?

0.0.0.0 isn't a valid address. You can't make connections to it. You
can't assign it to an interface.

This value can be specified in the bind() function. Often it is set up
like this:

struct sockaddr_in listening_address;
listening_address.sin_family = AF_INET;
listening_address.sin_addr.s_addr = htonl(INADDR_ANY);
listening_address.sin_port = htonl(/* port number */);

The byte order conversion is still done on the value for conceptual
correctness even though everyone knows that INADDR_ANY is just zero.

When you bind a passive (i.e. listening) socket to INADDR_ANY, it
means that it listens for datagrams (UDP messages or TCP connection
requests, as the case may be) on all network interfaces.

Those messages or connection requests do not have 0.0.0.0 as their
destination address. They are destined for the address by which this
host is known on their respective network.

> And it is better to insert the handler, type:
> if (requet_open_addr == ' 0.0.0.0 ')
> return requet_open_addr = ' 192.168.0.1 ';

A program that tries to send a datagram to 0.0.0.0, or tries to
connect TCP to that address, is broken.

Have you tried it?

I'm fairly certain that the attempt will be rejected.

On Apr 5, 5:17 am, Robert Redelmeier wrote:
> For inbound connections, the standard place would be
> /etc/hosts.allow and /etc/hosts.deny

This security mechanism only works with programs that use tcpwrappers.

This means programs which use libwrap, or programs which are launched
from inetd, but wrapped by tcpd.

> > if (requet_open_addr == ' 0.0.0.0 ')
> > return requet_open_addr = ' 192.168.0.1 ';
>
> This looks more like outbound. You could probably
> add an entry with /sbin/route .

In a route table, 0.0.0.0 represents the default route. It does not
represent a route to the (invalid) address 0.0.0.0. It's the route
over which packets are sent which don't match any other route.

On 5 ÁÐÒ, 16:39, "Lew Pitcher" wrote:
> > As well as where in a kernel it is possible to forbid to open tcp/udp
> > connections on 0.0.0.0 address?
>
> You /do/ realize that the 0.0.0.0 address is an established standard
> address that means "all IP addresses on this system", don't you? Be
> aware that if you 'forbid' such connections, you'll break a fair
> number of your networked apps.

It also is necessary to me
Look here - http://groups.google.ru/group/comp.o...3601551508fa98

On 5 ÁÐÒ, 16:17, Robert Redelmeier wrote:

> > As well as where in a kernel it is possible to forbid to
> > open tcp/udp connections on 0.0.0.0 address?
>
> For inbound connections, the standard place would be
> /etc/hosts.allow and /etc/hosts.deny
>
> > if (requet_open_addr == ' 0.0.0.0 ')
> > return requet_open_addr = ' 192.168.0.1 ';
>
> This looks more like outbound. You could probably
> add an entry with /sbin/route .

route add -net 0.0.0.0 gw 192.168.0.1 dev eth0

Whether so?

In comp.os.linux.development.system Pascal Hambourg wrote:
| Hello,
|
| phil-news-nospam@ipal.net a ?crit :
|>
|> I have been pondering a peculiar special handling of addresses in 0.0.0.0/8
|> via iptables. It would work like this. The kernel would have a set of IP
|> address maps much like routing tables, possibly implemented the same way.
|> Some interface would be provided to manipulate them. Each would have an ID
|> that is numeric. When a rule in iptables has an address like 0.1.X.Y, then
|> instead of doing the compare of the address in the rule to the address in
|> the packet buffer that the rule specifies, the address in the packet buffer
|> would be used as the index in a lookup of the map with ID X.Y to see if it
|> is present (or is in a subnet that is present). If so, the rule is then
|> handled as if the addresses matched. If absent, it is handled as if the
|> addresses did not match. The tools to handle iptables would not need to
|> be changed unless they would block use of 0.1.0.0/16. The kernel code to
|> handle this would have to be changed where the address compares take place.
|> And code would have to be added to manage the set of maps (perhaps by means
|> of root-only access to some new /proc file). This would make it easier to
|> manage iptables, allowing one to put logic, but not content, in the rule
|> tables, and use the maps to put content, updatable rapidly on the fly.
|
| This looks like ipset.

This is similar, but not alike. This creates sets with names, and requires
iptables and tools to be extensively modified to understand the sets exist.
My method is a hack that only requires hooks be added to the kernel part of
the filtering code, and only to test for a specific condition (high order
16 bit part part of address in rule == 1) and divert the test to a function.
If understanding of ipsets has been rolled into the iptables tools, and if
there is a direct kernel call that can be made to modify ipsets rapidly,
then my method would no longer have any advantages.


| By the way, what is special in 0.1.0.0/16 ?

The whole 0.0.0.0/8 is reserved as one network. There may well be special
things involved.

Of course some other address ranges are reserved, but I suspect there may be
technical design reasons for 0.0.0.0/8 to be reserved more so that for other
networks like 1.0.0.0/8 and 2.0.0.0/8 to be reserved. The possibility seems
to exist that 1.0.0.0/8 and 2.0.0.0/8 might actually get used for a purpose
more along the lines of real allocation (I actually use 1.0.0.0/8 as if it
were a private net, even though it is not).

So I figured that if a _technical_ use of IP space was being made, then some
ranges within 0.0.0.0/8 might work better.

I know the whole 127.0.0.0/8 is treated as localhost, and I have used that
in interesting ways. For example, I run all my web browser instances through
a local proxy for caching, tracking, and other reasons. The script that I
run to start each web browser instance rebuilds the config file for that one
to use a different IP address within 127.0.0.0/8 as the destination IP to
connect to the proxy. It makes it easier to see which browser is doing what
in tcpdump output (as opposed to source ports that are random per connect).

09:09:17.837703 IP 127.109.78.246.2576 > 127.109.78.246.88: F 486:486(0) ack 197461 win 12314
09:09:17.837730 IP 127.109.78.246.88 > 127.109.78.246.2576: . ack 487 win 8192
09:09:23.826965 IP 127.109.78.246.88 > 127.109.78.246.2575: F 12065:12065(0) ack 830 win 8192
09:09:23.866750 IP 127.109.78.246.2575 > 127.109.78.246.88: . ack 12066 win 8198 09:09:28.596365 IP 127.109.78.246.2575 > 127.109.78.246.88: F 830:830(0) ack 12066 win 8198
09:09:28.596395 IP 127.109.78.246.88 > 127.109.78.246.2575: . ack 831 win 8192

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-04-07-0858@ipal.net |
|------------------------------------/-------------------------------------|

In comp.os.linux.development.system Kaz Kylheku wrote:
| On Apr 5, 4:08 am, "Pavel Vasilyev" wrote:
|> As well as where in a kernel it is possible to forbid to open tcp/udp
|> connections on 0.0.0.0 address?
|
| 0.0.0.0 isn't a valid address. You can't make connections to it. You
| can't assign it to an interface.
|
| This value can be specified in the bind() function. Often it is set up
| like this:
|
| struct sockaddr_in listening_address;
| listening_address.sin_family = AF_INET;
| listening_address.sin_addr.s_addr = htonl(INADDR_ANY);
| listening_address.sin_port = htonl(/* port number */);
|
| The byte order conversion is still done on the value for conceptual
| correctness even though everyone knows that INADDR_ANY is just zero.

If INADDR_ANY expands to a constant, and htonl() is a macro, then compiler
optimization will end up removing the steps to reorder bytes and treating
it just like an assignment of 0 (usually very efficient machine code).


| When you bind a passive (i.e. listening) socket to INADDR_ANY, it
| means that it listens for datagrams (UDP messages or TCP connection
| requests, as the case may be) on all network interfaces.
|
| Those messages or connection requests do not have 0.0.0.0 as their
| destination address. They are destined for the address by which this
| host is known on their respective network.
|
|> And it is better to insert the handler, type:
|> if (requet_open_addr == ' 0.0.0.0 ')
|> return requet_open_addr = ' 192.168.0.1 ';
|
| A program that tries to send a datagram to 0.0.0.0, or tries to
| connect TCP to that address, is broken.

I just tried to connect to 0.0.0.0 in a test I ran, and it worked. But the
server end (another process) thought the source was 127.0.0.1. So it may be
a kernel "feature" to fix it up.

client side:

root@charon:/root 231# date | strace sock 0.0.0.0 4321
execve("/usr/local/bin/sock", ["sock", "0.0.0.0", "4321"], [/* 36 vars */]) = 0
uname({sys="Linux", node="charon.ipal.net", ...}) = 0
brk(0) = 0x804e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=110338, ...}) = 0
mmap2(NULL, 110338, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7b000
close(3) = 0
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20 O\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1441201, ...}) = 0
mmap2(NULL, 1240284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e4c000
mmap2(0xb7f75000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x128) = 0xb7f75000
mmap2(0xb7f79000, 7388, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e4b000
mprotect(0xb7f75000, 4096, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e4baa0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7f7b000, 110338) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
brk(0) = 0x804e000
brk(0x806f000) = 0x806f000
connect(3, {sa_family=AF_INET, sin_port=htons(4321), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
select(4, [0 3], NULL, NULL, NULL) = 1 (in [0])
read(0, "Sat Apr 7 09:39:36 CDT 2007\n", 1024) = 29
write(3, "Sat Apr 7 09:39:36 CDT 2007\n", 29) = 29
select(4, [0 3], NULL, NULL, NULL) = 1 (in [0])
read(0, "", 1024) = 0
close(3) = 0
exit_group(0) = ?
Process 19878 detached
root@charon:/root 232#

server side:

root@charon:/root 429# strace sock -A -s 4321
execve("/usr/local/bin/sock", ["sock", "-A", "-s", "4321"], [/* 36 vars */]) = 0
uname({sys="Linux", node="charon.ipal.net", ...}) = 0
brk(0) = 0x804e000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=110338, ...}) = 0
mmap2(NULL, 110338, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7eec000
close(3) = 0
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20 O\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1441201, ...}) = 0
mmap2(NULL, 1240284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7dbd000
mmap2(0xb7ee6000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x128) = 0xb7ee6000
mmap2(0xb7eea000, 7388, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eea000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7dbc000
mprotect(0xb7ee6000, 4096, PROT_READ) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7dbcaa0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7eec000, 110338) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(4321), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
brk(0) = 0x804e000
brk(0x806f000) = 0x806f000
listen(3, 5) = 0
accept(3, {sa_family=AF_INET, sin_port=htons(1710), sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "Sat Apr 7 09:39:36 CDT 2007\n", 1024) = 29
write(1, "Sat Apr 7 09:39:36 CDT 2007\n", 29Sat Apr 7 09:39:36 CDT 2007
) = 29
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "", 1024) = 0
close(4) = 0
exit_group(0) = ?
Process 19865 detached
root@charon:/root 430#

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-04-07-0930@ipal.net |
|------------------------------------/-------------------------------------|

On Sat, 07 Apr 2007 04:53:47 -0700, Pavel Vasilyev wrote:

> On 5 April, 16:39, "Lew Pitcher" wrote:
>> > As well as where in a kernel it is possible to forbid to open tcp/udp
>> > connections on 0.0.0.0 address?
>>
>> You /do/ realize that the 0.0.0.0 address is an established standard
>> address that means "all IP addresses on this system", don't you? Be
>> aware that if you 'forbid' such connections, you'll break a fair number
>> of your networked apps.
>
> It also is necessary to me
> Look here -
> http://groups.google.ru/group/comp.o...3601551508fa98

Modifying the kernel seems a very extreme way to achieve this, and I don't
believe it would work - I think it would make the VNC server fail.

If the VNC server has no option to listen on only a specific address (the
one I have - not VMware's - does not), then can you not achieve what you
want with iptables? Have a rule in the input chain to permit connections
to the desired address on the VNC port, followed by one to deny
connections to the port by default.

Regards, Ian

On 7 ÁÐÒ, 18:28, phil-news-nos...@ipal.net wrote:
> | This looks like ipset.

> My method is a hack that only requires hooks be added to the kernel part of
> the filtering code, and only to test for a specific condition (high order
> 16 bit part part of address in rule == 1)


Please, if to you it is not difficult, repeat step by step.
Where also that in the kernel source code, necessary to change,
replace, patch, etc.


P.S.
Or, maybe, at once - ready patch for 2.6.20+. Please.

On 7 ÁÐÒ, 19:53, Ian Northeast
wrote:
>
> > It also is necessary to me
> > Look here -
> >http://groups.google.ru/group/comp.o...browse_thread/...

> Have a rule in the input chain to permit connections
> to the desired address on the VNC port, followed by one to deny
> connections to the port by default.

Best, when vmware try open 0.0.0.0 address && 5900-5909 ports
replace on address eth0 interface. Like this:

if ( addr == 0.0.0.0 && port >= 5900 && port < 5910)
addr=inet_addr("192.168.0.1")

On Sun, 08 Apr 2007 15:33:14 -0700, Pavel Vasilyev wrote:

> On 7 April, 19:53, Ian Northeast
> wrote:
>>
>> > It also is necessary to me
>> > Look here -
>> >http://groups.google.ru/group/comp.o...browse_thread/...
>
>> Have a rule in the input chain to permit connections to the desired
>> address on the VNC port, followed by one to deny connections to the port
>> by default.
>
> Best, when vmware try open 0.0.0.0 address && 5900-5909 ports replace on
> address eth0 interface. Like this:
>
> if ( addr == 0.0.0.0 && port >= 5900 && port < 5910)
> addr=inet_addr("192.168.0.1")

I don't see why you want to muck with the kernel to solve a problem which
is easily solved by standard techniques as I suggested.

If my suggestion won't work, please tell us why.

If you don't tell us what you're really trying to do you won't get much
help.

Regards, Ian

On 9 ÁÐÒ, 04:20, Ian Northeast
wrote:
> On Sun, 08 Apr 2007 15:33:14 -0700, Pavel Vasilyev wrote:
> > On 7 April, 19:53, Ian Northeast
> > wrote:
>
> >> > It also is necessary to me
> >> > Look here - http://groups.google.ru/group/comp.o...browse_thread/...
>
> >> Have a rule in the input chain to permit connections to the desired
> >> address on the VNC port, followed by one to deny connections to the port
> >> by default.

> I don't see why you want to muck with the kernel to solve a problem which
> is easily solved by standard techniques as I suggested.
>
> If my suggestion won't work, please tell us why.

What your suggestion? I see only the reflections, not one suggestion.

> If you don't tell us what you're really trying to do you won't get much help.

Any server should not open connection with 0.0.0.0 address.
If the server will try to open such connection it is necessary to
replace the address on specified by me.


Example: strace -f -e bind sshd

..............
[pid 14019] bind(3, {sa_family=AF_INET, sin_port=htons(22),
sin_addr=inet_addr("0.0.0.0")}, 16
...............

That would appear as

bind(3, {sa_family=AF_INET, sin_port=htons(22),
sin_addr=inet_addr("192.168.0.1")},

Do not change sources of application, do not install iptables, and
other redirectors....

P.S.

That in /proc/net/tcp and on a command "netstat-tln" there were no
zero in a column "Local Address".

On Apr 7, 6:46 am, "Kaz Kylheku" wrote:

> When you bind a passive (i.e. listening) socket to INADDR_ANY, it
> means that it listens for datagrams (UDP messages or TCP connection
> requests, as the case may be) on all network interfaces.

But if you use INADDR_ANY when joining a multi-cast
group, this is not the case. (The multi-cast is NOT joined
on all interfaces...unless my single, hastily prepared
test case has an error.)