6

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

  • 0: 192.168.0.5/255.255.255.0
  • 1: 192.168.1.5/255.255.255.0

with /etc/defaultrouter set to 192.168.0.1

If a connection (either TCP or UDP) comes in on port 0, but it is from 192.168.1.6 (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.

12
  • If port 0 is connected to the internet it can not have a 192.168.x.x address
    – this.josh
    Commented Jul 25, 2011 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
    Commented Jul 25, 2011 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
    Commented Jul 25, 2011 at 18:50
  • also, your firewall and IDS should pick this up fairly easy.
    – Ormis
    Commented Jul 25, 2011 at 18:52
  • 1
    If i remember correctly, it should be as simple as.... iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP
    – Ormis
    Commented Jul 25, 2011 at 19:08

3 Answers 3

5

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 192.168.2.0/24 was also routed over interface 1, then I'm not sure Solaris would drop a packet from 192.168.2.5 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.

2
  • 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. Commented Jul 25, 2011 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. Commented Jul 25, 2011 at 22:53
3

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 192.168.0.0/24 -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 **

1
  • This was not as clearly worded as the original comments. But yes, software firewalls such as ipfilter are probably sufficient Commented Jul 26, 2011 at 20:00
2

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
  • +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. Commented Jul 27, 2011 at 16:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .