Re: restrict implicit binding to addresses

David Schwartz wrote:

How can I do that, I mean: If a program requests to be bound
to a certain interface explicitly, then and only then it bound
to that interface. Otherwise it's just bound implicitly to the
not restricted interfaces.

Programs don't bind to interfaces. Your question doesn't make
any sense.

s/interface/address/ then. Well in my case that's equivalent
(for IPv4), as two of the networks (read, logical networks,
address/netmask level) use private IP address ranges, thus
my wrong naming. I'm thinking mostly in secure and insecure
interfaces right now.

(Anyway, some programs _do_ bind to interfaces, think about
dhcpd; alas, that's on the raw level).

In the particular case it's a proxy server (the deamon is not
buggy, so explicit binding works, but I'd like to have some
fallback). Squid shall listen only to the internal network, so
it can't be abused from outside.

Programs don't listen to networks. Again, your question doesn't
make any sense.

With network I didn't mean physical network, but logical
network like in IP subnet.

Can you state precisely what it is you are trying to do? What
is the rule for whether a connection should or should not be
allowed to the proxy?

If a socket is bound to a port only, it will listen to connection
attempts on all addresses of the machine. One can of course bind
to certain addresses explicitly.

Now I'd like, that programs/sockets not bound to a certain address
won't get an incomming connection for all but a set of selected
addresses, whereas programs/sockets bound explicitly to an address
not in that set, will get a connection.

Let's have a look at `netstat -lnp` on one of my private
systems that has two interfaces/addresses on separate subnets
(in this case the interfaces are also connected to those
physical networks in which the machines are using addresses
from the assigned subnet). It's not the system I'm referring
to, but it makes a good example case. Two networks, where
some logical segregation makes sense, but the machine itself
is also router between both networks.

192.168.1./24
192.168.2./24

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 6188/smbd
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 6188/smbd
tcp6 0 0 192.168.1.2:53 :::* LISTEN 6172/dnscache
tcp6 0 0 :::22 :::* LISTEN 11152/sshd
udp 0 0 0.0.0.0:137 0.0.0.0:* 6198/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 6198/nmbd
udp 0 0 0.0.0.0:123 0.0.0.0:* 6224/ntpd
udp6 0 0 127.0.0.1:53 :::* 6166/tinydns
udp6 0 0 192.168.1.2:53 :::* 6172/dnscache
udp6 0 0 fe80::2e0:81ff:feb3:123 :::* 6224/ntpd
udp6 0 0 ::1:123 :::* 6224/ntpd
udp6 0 0 :::123 :::* 6224/ntpd

You can see, that there's a program dnscache, listening on .1.2:53
Using a interface based iptables rule it's easy to block all
incoming connection requests from (sub)nets not designated to
that interface. No problems there. In this case dnscache is
bound to a specific address explicitly, because it must so.
The same goes for tinydns, which is turn cached by dnscache.

Now there's also a Samba and a NTP running on the system. And
those are not bound explicitly to a certain address. What I'd
like to have, independent of ports on which a socket listens,
is that all sockets, which are not bound to an address explicitly,
behave as if the had been bound to a preselected set of addresses,
and that addresses only, so that programs, that can't be configured
to listen on specific addresses, or a buggy won't attach to those.

A iptables makes it then easy to block all traffic from a certain
interface, designated to that set of addresses.

The machine will be something like a major data storage and exchange
hub, providing services for private internal and public external
users, but only certain services/programs shall be made public.
Normally one would do that using separate machines or
paravirtualization. In that case it was ruled out for performance
reasons: huge DB, full access to the RDBS from two intern
(sub)networks (physical and logical), access from extern network
only through special proxy daemons.

You seem to be under the misconception that addresses belong to
interfaces.

Nah, I'm just sketching out stuff on the physical level for 2
weeks now, and I seem to default into thinking and writing that
way ATM.

Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@xxxxxxxxxx, ICQ: 134682867

.

Relevant Pages

  • Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.
    ... that explicit mechanisms are better than implicit contracts. ... is very hard with thousands of exported symbol. ... There are still classes of drivers. ... use interfaces that are really generic driver interfaces and fairly stable ...
    (Linux-Kernel)
  • Re: Explicit and implicit interfaces
    ... struck by the inappropriateness of the word "explicit" for interfaces ... subprograms in question follow CONTAINS. ... An explicit interface is an explicit ... muddy the water by talking about externals. ...
    (comp.lang.fortran)
  • Re: Delphi to C++ project ends and Dennis Landi wins a pizza
    ... Cleaning up after you is very explicit, ... Delphi as well, with interfaces. ...
    (borland.public.delphi.non-technical)
  • Re: dynamic type checking - a pauline conversion?
    ... We were stating that in the absense of an explicit common interface ... In a language without explicit interfaces Ilja's new notion will ... In a language with explicit interfaces, we are left to wonder what the ...
    (comp.object)
  • Re: workstation authentication
    ... Having a machine connected to two networks can cause some odd things to happen, because there are two IP addresses linked to the computer's name. ... the wired connection and the wireless connection? ... or should both interfaces be attached to the same computer name? ... When I look at the computer name in DHCP, ...
    (microsoft.public.windows.server.networking)