Given a Solaris machine with two network interfaces corresponding to the separate ethernet ports in the back.

  • 0:
  • 1:

with /etc/defaultrouter set to

If a connection (either TCP or UDP) comes in on port 0, but it is from (obviously spoofed), does that mean that any responses (the SYN-ACK packet in the case of a TCP server, or the DNS response in case of a DNS server) will be sent out on port 1 (due to the IP address).

Or will they be dropped, or worse, will they be sent back out on port 0?

I am attempting to asses the risk of IP spoofing across physical interfaces. If a server listens on all interfaces, but only authorizes connections from 192.168.1.*, I want to know how likely it is that it will accept connections from the wrong port.

Hypothetical threat environment: port 1 is connected to trusted, non-internet network. Port 0's subnet might have a compromised machine on it.

  • If port 0 is connected to the internet it can not have a 192.168.x.x address – this.josh Jul 25 '11 at 17:54
  • I don't have the knowledge to explain this in any more detail, but the Linux kernel has the functionality to track network connections (allowing for stateful inspection in firewalls). I would doubt that this is that much of a risk, but the easiest way to see is to test it... spin up an example with virtual machines and see what happens. – Ormis Jul 25 '11 at 18:48
  • P.S. are you looking at this issue within proprietary code or is this in regards to an already established service/application? – Ormis Jul 25 '11 at 18:50
  • also, your firewall and IDS should pick this up fairly easy. – Ormis Jul 25 '11 at 18:52
  • 1
    If i remember correctly, it should be as simple as.... iptables -A INPUT -i eth0 -s -j DROP – Ormis Jul 25 '11 at 19:08

Under Solaris, the ip_strict_dst_multihoming parameter will perform the anti-IP spoofing function you're looking for. To quote, "by setting the parameter ip_strict_dst_multihoming to 0 the system drops any packets that appear to originate from a network attached to another interface "Solaris Kernel Tuning for Security". So to answer your question: risk can be addressed by properly configuring the box not to forward spoofed packets.

Note that this addresses the simple case that you've outlined. I don't think it will help in the case of routing multiple networks via multiple interfaces. In other words, if you had a static route so that traffic for was also routed over interface 1, then I'm not sure Solaris would drop a packet from that came in on interface 0. I think only the networks defined by interface 1's bound address will be dropped.

If you're looking on turning a Solaris box into a router, you should carefully read guides such as the link above. Solaris is not, in my humble opinion, a great router system. Solaris 11 did add the ipfw firewall, however, which brings closer to par with your average BSD/Linux box. If you're going to route between networks of differing security levels, you should do it right and NAT and/or apply firewall rules.

  • I am not using static routes and I am not using Solaris as a router. The only routing instruction is in /etc/defaultrouter which is basically the default gateway for the internet side of things which happens to be on ethernet port 0. – 700 Software Jul 25 '11 at 22:50
  • +1 for the link. This will be helpful for our new standard server build. I will read it end to end when I have time. – 700 Software Jul 25 '11 at 22:53

Though there may be ways to deal with this issue via the system kernel, it is also very easy to mitigate via other means.

Some tools would include IPS and firewalls.

A simple example of this would be via IPTables. If you are working on a system that runs iptables, the following line should do the trick...

iptables -A INPUT -i eth0 -s -j DROP

This also depends on your network environment, it's plausible that the way the network is configured simply does not allow for this to happen (routing/NAT/firewalls).

** posted due to request **

  • This was not as clearly worded as the original comments. But yes, software firewalls such as ipfilter are probably sufficient – 700 Software Jul 26 '11 at 20:00

As the above post says, ip_strict_dst_multihoming parameter is what you want to prevent the INCOMING packet. That parameter is turned off by default, so you have to set it to '1' in order for it to work.

Assuming it's off, the outgoing packet will be sent out interface #1. The stack does not remember what port the packet came in on. All it knows is that it has a packet destined for an address 192.168.1.x. It doesn't know why it has the packet, where it came from, or even the contents. All it knows is the destination address, which means port #1.

  • +1 for "It doesn't know why it has the packet" :) But thanks, a direct answer to the question. I will be setting that flag anyway to achieve ideal behavior. This is a good second answer. – 700 Software Jul 27 '11 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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