-2

My server has two physical NICs, interfaces are eth0 192.168.1/24 (lan) and eth1 192.168.3/24 (dmz). Both NICs are connected to a router via wire. Router has two vlans for lan and dmz with separated ports also, with a firewall between the zones (OpenWRT).

Problem object is the server and the way Linux prioritizes loopback interface. I want to have dmz -> lan initiating traffic blocked, for which the router firewall takes care of on the network, but as we know traffic going over server loopback interface between local NICs doesn't even reach the router. lan -> dmz direction all must be allowed.

As far as I can tell, this send-to-self kernel patch is one option that can force loopback traffic onto the wire. Anyone with confirmation, experiences, downsides?

How could this be achieved with iptables? Iptables needs to be generic rule that blankets all services and computers living within lan subnet from the dmz. Googling "iptables block loopback" with different quote-combos seems to be a dead end, since everybody talks about making sure all loopback is fully enabled.

What about network namespaces with the new-style "ip netns"?

lkraav
  • 786
  • 1
  • 8
  • 22
  • 3
    Can you elaborate on what you're trying to accomplish? The point of a DMZ is to contain the impact with isolation when systems are compromised; having the system on both networks defeats that isolation, regardless of whether you force its loopback traffic through a firewall.. – Shane Madden Dec 29 '11 at 02:34
  • 3
    I am baffled by what you're trying to accomplish. Local traffic cannot be DMZ->LAN or LAN->DMZ, it's just local. (The traffic originates on this machine and is destined for this machine, right?) This machine is not routing remote traffic and there's no conceivable security reason to stop the machine from communicating with itself. – David Schwartz Dec 29 '11 at 06:48
  • @ShaneMadden I'm looking to first of all map out different approaches to block some linux-vservers living on server in dmz subnet from initiating network traffic to lan. Including separate physical machines and full virtualization options, but because of the additional resources needed for these, they can only be implemented down the road. Yes, obviously putting all life on the single machine increases risks, but I'm not yet seeing a total dealbreaker. These vservers themselves are not random-purpose either, blocking the local network traffic, if possible, could be considered as icing on cake. – lkraav Dec 29 '11 at 10:45
  • @DavidSchwartz Main concern is that a bunch of perhaps not-so-secure services are running on server 192.168.1.x. They aren't a humongous risk, more like a nuisance, so a non-perfect solution is acceptable until something more substantial can be implemented (physical separation, Xen, ...). While "no conceivable" seems to imply 100% coverage of all scenarios, your comment doesn't make it clear why something "iptables -i lo -s 192.168.3.0/24 -d 192.168.1.0/24 -j LOGDROP" wouldn't work within an acceptable risk range. – lkraav Dec 29 '11 at 11:46
  • Re iptables vs send-to-self vs namespaces on server: the idea for pushing loopback traffic also out to the wire is it would allow for a single firewall on router, instead of having to maintain two. But that might be too much to ask considering the single machine life. – lkraav Dec 29 '11 at 11:55
  • 1
    @Ikraav Right, but if an attacker takes control of a process on the system, they won't be limited at all by the restrictions that you've placed on traffic between the interfaces, since they'll have both interfaces accessible to them. You're adding extra transit and overhead to your legitimate traffic, and completely circumventing the defense-in-depth strategy that a DMZ is designed for. – Shane Madden Dec 29 '11 at 15:54
  • @ShaneMadden Do you mean in the scenario where attacker is able to break out of a vserver? So far I'm considering trusting linux-vserver enough to not assess breakout as significant risk. If attacker gets root inside a vserver but the container stays intact (not certain at all yet, if this isn't mutually exclusive), AFAICT he cannot just get access to lan interface from within the vserver. In the meanwhile I've been doing "sudo lsof -i | grep "\*.*LISTEN" | sort", binding all services on eth0/192.168.1.2 and: iptables -I INPUT -s 192.168.3.0/24 -d 192.168.1.0/24 -i lo -j LOGDROP – lkraav Dec 29 '11 at 16:26
  • @ShaneMadden I know it's become a lengthy one which has probably crossed the "free internet work" barrier, but I'd really appreciate it if you could let me know if you're accounting for vserver containment in your last comment. I am waiting for an opinion from vserver developers as well. Aside from that I think I have a setup good enough to hold me over. – lkraav Dec 30 '11 at 16:39

1 Answers1

1

The whole point in the loopback interface is that it should never get to the router and it should just loop back to the host without getting to the NIC.

I suspect you need to change a setting somewhere to stop your particular application from using the loopback interface (127.0.0.1) if that is supported.

Robin Gill
  • 2,513
  • 14
  • 13
  • It's not about 127.0.0.1, but the lo interface. If you use for example wireshark to capture traffic on interfaces, you would see that traffic between two machine-local IPs actually doesn't touch their respective eth0 and eth1 interfaces, but instead moves over lo. – lkraav Dec 29 '11 at 11:35