lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 9 Jan 2016 10:57:31 +0100
From:	Hannes Frederic Sowa <>
To:, Robert Sander <>,,
Subject: Re: Configure ICMP error source address

On 09.01.2016 04:57, wrote:
>   The reason why is in the kernel documentation distributed with the source code.
> ‎Its not all immediately obvious why and where the kernel does this
unless you were involved in the original debates about it. The problems
with binding a public ip address to a loopback address are more
recently is partialy selinux but mostly of it is because of how routing
changed when iproute2 was introduced in the 2.2 kernel (if I remember
the versions correctly it was so long ago). The reason is security,
many processes bind to the loopback interface for IPC and just grab the
first address on the first lo device they find, some of the developers
of the applications weren't even aware they were doing it because in
some cases it was C libraries several layers deep doing it because odd
loopback addresses were common on UNIX ( I remember an AIX admin back
in the early 90's telling me I should always use addresses like on the loopback because it was valid made it harder for
script kiddies to attack processes ). This was fine when additional
addresses would need additiona
l alias on the interface for ifconfig (lo:1 for example) but with iproute2 you could now assign multiple ip addresses to an interface without creating an alias (commonly seen on the keepalived mailing list "why doesn't my VIP show up in ifconfig?")
> So there was a decision made to declare all subnets assigned to the loopback interface as unroutable to prevent a lot of very common security holes that were being seen in the wild.

selinux can only affect what happens between user space and kernel 
space, it cannot install policy what happens during forwarding if no 
user space is involved.

In general the kernel makes sure nothing leaves or enters the system 
with an address in the subnet. Albeit we have a sysctl 
nowadays to lift this restriction, sysctl_route_localnet.

Besides that I don't see any differences, as I bind addresses to the 
loopback interface from time to time and it works.

One must just be careful if the kernel is switched from weak end mode 
into a stong end mode by enabling more strict arp filters, but this 
would also break setups with dummy interfaces.

> That said you can make it work but you have to do a lot of things you should never do on a firewall like turn off selinux.‎ Or you can simply use the dummy driver and bind your public IP's to that and the problems magically go away. And it makes a lot of sense why else would there be a need for the dummy network driver?

I would also use dummy interfaces in production systems, merely to split 
the statistics from dummy.


Powered by blists - more mailing lists