Forbid connections on 0.0.0.0 address. - Networking

This is a discussion on Forbid connections on 0.0.0.0 address. - Networking ; As well as where in a kernel it is possible to forbid to open tcp/udp connections on 0.0.0.0 address? 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 ';...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Forbid connections on 0.0.0.0 address.

  1. Forbid connections on 0.0.0.0 address.

    As well as where in a kernel it is possible to forbid to open tcp/udp
    connections on 0.0.0.0 address?
    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 ';


  2. Re: Forbid connections on 0.0.0.0 address.

    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



  3. Re: Forbid connections on 0.0.0.0 address.

    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)



  4. Re: Forbid connections on 0.0.0.0 address.

    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 |
    |------------------------------------/-------------------------------------|

  5. Re: Forbid connections on 0.0.0.0 address.

    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 ?

  6. Re: Forbid connections on 0.0.0.0 address.

    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.


  7. Re: Forbid connections on 0.0.0.0 address.

    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.


  8. Re: Forbid connections on 0.0.0.0 address.

    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




  9. Re: Forbid connections on 0.0.0.0 address.

    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?



  10. Re: Forbid connections on 0.0.0.0 address.

    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 |
    |------------------------------------/-------------------------------------|

  11. Re: Forbid connections on 0.0.0.0 address.

    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 |
    |------------------------------------/-------------------------------------|

  12. Re: Forbid connections on 0.0.0.0 address.

    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

  13. Re: Forbid connections on 0.0.0.0 address.

    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.



  14. Re: Forbid connections on 0.0.0.0 address.

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


  15. Re: Forbid connections on 0.0.0.0 address.

    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

  16. Re: Forbid connections on 0.0.0.0 address.

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





  17. Re: Forbid connections on 0.0.0.0 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.)


+ Reply to Thread