restrict implicit binding to interfaces

Say I have 4 interfaces, eth0, eth1, tun0, ppp0. On the system
there are to be running several deamons, which shall be bound to
all interfaces, except ppp0. One way to do this, is binding them
explicitly to eth{0,1}, tun0 only. If however a program is
hardcoded to be bound to all interfaces or the configuration
code has a bug, then it might be bound to ppp0, too, which is,
what I want to prevent.

Also Say I have some daemon, which shall listen on ppp0, so just
closing of ppp0 using iptables is not what I want.

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.

Any ideas?

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. But there's a also a OpenVPN
running for incomming connections, to enable a route to the
storage server which won't permit incomming connections from the
internet. And then the system shall be also ordinary router,
routing traffic into the subnet (which is a public IP address
space). I know, that using paravirtualization and some network
trickery would do the trick, but I'd like to do it on a single
logical host.

However I considered to use a small UML process, that would
contain the ppp0 device, so that this one has it's own router.

Wolfgang Draxinger
--
E-Mail address works, Jabber: (E-Mail Removed), ICQ: 134682867

On Oct 29, 4:13*am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
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.

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

> But there's a also a OpenVPN
> running for incomming connections, to enable a route to the
> storage server which won't permit incomming connections from the
> internet. And then the system shall be also ordinary router,
> routing traffic into the subnet (which is a public IP address
> space). I know, that using paravirtualization and some network
> trickery would do the trick, but I'd like to do it on a single
> logical host.
>
> However I considered to use a small UML process, that would
> contain the ppp0 device, so that this one has it's own router.

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?

You seem to be under the misconception that addresses belong to
interfaces. They don't under Linux, they belong to the machine as a
whole. When you bind to an address, you accept packets sent to that
address regardless of what interface they arrive on. Otherwise, it
would be impossible to set up a functional router.

DS

David Schwartz wrote:
> On Oct 29, 4:13 am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
> 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.
>
>> 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.
>
>> But there's a also a OpenVPN
>> running for incomming connections, to enable a route to the
>> storage server which won't permit incomming connections from the
>> internet. And then the system shall be also ordinary router,
>> routing traffic into the subnet (which is a public IP address
>> space). I know, that using paravirtualization and some network
>> trickery would do the trick, but I'd like to do it on a single
>> logical host.
>>
>> However I considered to use a small UML process, that would
>> contain the ppp0 device, so that this one has it's own router.
>
> 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?

I think what he's asking is how he can control on what addresses an app
listener opens a socket. Most apps open sockets on 0.0.0.0 (i.e., every
interface) by default. Some let you specify listening addresses. He
appears to want a way to designate some interfaces as "restricted" and
others as "not restricted" so that apps open listeners on the "not
restricted" interfaces by default, but can open listeners on the
"restricted" interfaces if their configs specifically request it.

I doubt that what he wants is possible. It would take rethinking the
call to open a socket at the API in order to apply to apps (e.g., ntpd)
that don't let you specify listening on only some addresses. (I
understand there have been flame wars over ntpd on this point. I only
use it as an example, not as a spark for another war.)

> You seem to be under the misconception that addresses belong to
> interfaces. They don't under Linux, they belong to the machine as a
> whole. When you bind to an address, you accept packets sent to that
> address regardless of what interface they arrive on. Otherwise, it
> would be impossible to set up a functional router.

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: (E-Mail Removed), ICQ: 134682867

Allen Kistler wrote:

> I think what he's asking is how he can control on what
> addresses an app
> listener opens a socket. Most apps open sockets on 0.0.0.0
> (i.e., every
> interface) by default. Some let you specify listening
> addresses. He appears to want a way to designate some
> interfaces as "restricted" and others as "not restricted" so
> that apps open listeners on the "not restricted" interfaces by
> default, but can open listeners on the "restricted" interfaces
> if their configs specifically request it.

Yes, that's exactly what I want.

Wolfgang Draxinger
--
E-Mail address works, Jabber: (E-Mail Removed), ICQ: 134682867

David Schwartz <(E-Mail Removed)> wrote:
> On Oct 29, 4:13?am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
> 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.

While "Linux" is very much not such a stack on a "Strong End-System
Model" system binding to a given IP address is pretty much the same
thing since the traffic to that IP will only be accepted on that
interface.

> You seem to be under the misconception that addresses belong to
> interfaces. They don't under Linux, they belong to the machine as a
> whole. When you bind to an address, you accept packets sent to that
> address regardless of what interface they arrive on. Otherwise, it
> would be impossible to set up a functional router.

In fact, Linux takes the weak end-system mantra farther than any other
system I've encountered - by default ARP on any interface will be more
than happy to respond for any IP on the system, not just that on the
interface on which the ARP request was received. Leads to lots of
"fun" when connecting multiple interfaces to the same broadcast
domain, even if those interfaces are configured into different IP
subnets.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Oct 29, 3:49*pm, Allen Kistler <ackist...@oohay.moc> wrote:

> I think what he's asking is how he can control on what addresses an app
> listener opens a socket. *Most apps open sockets on 0.0.0.0 (i.e., every
> interface) by default. *Some let you specify listening addresses. *He
> appears to want a way to designate some interfaces as "restricted" and
> others as "not restricted" so that apps open listeners on the "not
> restricted" interfaces by default, but can open listeners on the
> "restricted" interfaces if their configs specifically request it.

I don't think that's what he's asking. As that would still allow
people to connect to the restricted services on the restricted
interfaces, simply by using an unrestricted destination address.

DS

On Oct 29, 4:55*pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:

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

Then the solution is to use the machine's firewalling capability to
block connections to restricted ports from untrusted source addresses.

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

Right, and that's not what you're talking about.

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

You need a firewall. The best solution is to block all incoming
traffic from untrusted sources to undesired ports.

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

That doesn't provide any level of security. It simply provides service
differentiation. It is a mistake to rely on this for security.

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

Right, that's what you want. You need a set of allow rules to allow
inbound connections to be established from untrusted addresses to
those services you want to allow, and to refuse them on those you
don't want to allow.

You need to configure allowed and un-allowed services, obviously, so
why not do it in the iptables? You can do it by user, by port, or by
any other method iptables allows.

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

Normally this would be done by a firewall. Why is iptables not the
answer?

DS

David Schwartz wrote:

> Normally this would be done by a firewall. Why is iptables not
> the answer?

Well, iptables will do the job, it just _must_ be configured
correctly.

The human factor is the problem: The system will be run mostly by
students, which don't care about such things. Important thing
is, that their simulation programs (running on the cluster in
one of the private networks) do their job. And on the data hub
they can install their own deamons for data selection and
proxying. A security nightmare, those programs won't be checked
for exploits and similiar stuff. The problem is, that the data
hub also needs reasonably fast connection to the local backbone
(Münchner Wissenschaftsnetz), either to transfer the data to the
supercomputer in the LRZ, the group sometimes get computing time
on it, or to feed a grid.

> You need to configure allowed and un-allowed services,
> obviously, so why not do it in the iptables? You can do it by
> user, by port, or by any other method iptables allows.

Tonight I figured, I could filter for programs pid, gid and
command line for outgoing packets. Then put a small helper
program around the daemon, that opens the firewall for the
programs that are started by it. Hmm, thinking about it, I could
also ptrace for bind and open the ports in the iptable on demand
(think about protocols, that are as brain dead like FTP...).

Wolfgang Draxinger
--
E-Mail address works, Jabber: (E-Mail Removed), ICQ: 134682867

On Oct 30, 1:40*am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:

> Well, iptables will do the job, it just _must_ be configured
> correctly.

That's true of any solution. Since you want to allow some things and
not others, somewhere there is going to have to be a configuration of
what's allowed and what isn't. I don't see that you have an
alternative.

> The human factor is the problem: The system will be run mostly by
> students, which don't care about such things. Important thing
> is, that their simulation programs (running on the cluster in
> one of the private networks) do their job. And on the data hub
> they can install their own deamons for data selection and
> proxying. A security nightmare, those programs won't be checked
> for exploits and similiar stuff. The problem is, that the data
> hub also needs reasonably fast connection to the local backbone
> (Münchner Wissenschaftsnetz), either to transfer the data to the
> supercomputer in the LRZ, the group sometimes get computing time
> on it, or to feed a grid.

You probably want a firewall that is not administered by the students.

> > You need to configure allowed and un-allowed services,
> > obviously, so why not do it in the iptables? You can do it by
> > user, by port, or by any other method iptables allows.

> Tonight I figured, I could filter for programs pid, gid and
> command line for outgoing packets. Then put a small helper
> program around the daemon, that opens the firewall for the
> programs that are started by it. Hmm, thinking about it, I could
> also ptrace for bind and open the ports in the iptable on demand
> (think about protocols, that are as brain dead like FTP...).

You really can't do it by port?

DS