Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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"?

share|improve this question

closed as not a real question by voretaq7 Aug 25 '12 at 2:25

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

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 2: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 6: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
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

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

share|improve this answer
    
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

Not the answer you're looking for? Browse other questions tagged or ask your own question.