Re: Debian ISOs
* Remi Denis-Courmont <rdenis@simphalempin.com> [060825 15:10]:
> > Blocking incoming connections is a common and good starting points for
> > every firewall setup.
>
> This is only meaningful if there are any open ports by default. Quite many
> Linux distributions have all ports closed by *default* after installation. If
> root installs some software that happens to open ports, I tend to believe that
> (s)he actually intends these ports to be opened (since the installed
> application would likely need these to operate).
Except there are also firewalls not restricted to a packet filter on
every PC. For a whole corporate subnet, closing all incoming connections
with some special connections to some servers (well, best to keep them
in a special net), is a good start. There are enough programs listening
on 255.255.255.255 where 127.0.0.1 would suffice. And it's easy to
forget to configure some webserver installed for some development to
only listen to localhost.
Plus all kind of programs tend to open ports no other computer should
connect anyway. (startx without -nolisten tcp, sshd when getting a -X
connection...)
> > That NAT makes this mandatory does not change the
> > fact that protocols needing listening ports are a security hole many
> > people do not like to introduce.
>
> Any additionnal software comes with associated risks. If you can't accept
> them, don't install the software. And if you can't prevent others from
> installing them, use a stateful firewall or setup a non-routed-with-proxies
> network.
Protocols wanting open ports on the client still need support in the
stateful firewalls and often this additional complexity opens new
security holes. (The classical example are java applets opening an ftp
connection and claiming the data port the ftp server should send the
file to is 25 or anything else).
And a non-routed-with-proxies network closes too much for many use
cases. A NAT is a nice not-routed-inside network.
> I would never rely on the NAT function of my Internet gateway for this
> purpose. NAT implementations are completely inconsistent, and quite many of
> them are much more easy to dig hole through than a real firewall.
I didn't say relay on them. But a additional line of defense is a
additional line of defense.
> > If everything fails there still has to be some mechanism to translate
> > the intern IPs to extern addressable.
> However this security fallback depends on the upstream router (or any box that
> can send packets to the public interface of the NAT) being trustworthy: should
> it ever send your NAT a packet with a "intern IP" as destination, the NAT will
> be happy to forward it inside.
Which is essentially a "translate the intern IP to extern addressable",
or every single router up the tree has to be tricked in sending the
stuff this way.
> > So I hope someone will still make it available with IPv6...
> IPv6 NAT is a very bad idea. What is the point of investing billions into IPv6
> transition if you reintroduced problems that it is supposed to fix (NAT) in
> the first place?
Well, if you have no other point than removing NAT, I'd rather suggest
investing the money into removing the concrete from all streets. Walking
is much nicer when done on farm tracks... ;->
Hochachtungsvoll,
Bernhard R. Link
Reply to: