NI Linux Real-Time Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Setting up iptables to block traffic just on one interface on the cRIO-9068

Hello,

I would like to setup iptables to block all incoming traffic on eth0, while not changing any of the default rules ( allow all ) for eth1 on the cRIO-9068.  From what I gather this should be possible.

From what I gather from this serverfault.com post ( http://serverfault.com/questions/244767/enable-iptables-on-one-interface ), this should be what I want to do:

    iptables -P INPUT ACCEPT
    iptables -P OUTPUT ACCEPT
    iptables -P FORWARD ACCEPT

    iptables -F

    iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

    iptables -A INPUT -i eth0 -j DROP

From a security stand point, could anyone shed some light on additioanl things I should be doing to ensure no connections are accepted on this port?

Thanks,

-TD

0 Kudos
Message 1 of 8
(13,020 Views)

Well, aside from checking the inteface Rx/Tx numbers and the iptables chain counters, you could attempt to connect to the target through the eth1 interface as an outside user to make sure that the rules are working as expected.

One other consideration (not exactly the same concern that you're addressing with the iptables setup) is using so-called policy-based routing. Basically, if eth0 is looking pretty good, routing-wise, some incoming traffic (if it routable and reachable from the protected eth0 interface) can be communicated to through eth0, even if the incoming traffic was from eth1. This can leak information about the internal network to outside parties as well as result in dropped/broken traffic (in the case that the incoming response to the initiator of the traffic is configured with policy routing, and would therefore ignore the incoming response on a different interface).

0 Kudos
Message 2 of 8
(12,028 Views)

Thanks for the quick response Brad.

To clarify, eth0 will be on a WAN IP address (a.b.c.d) and eth1 will be on an internal network (10.0.1.x).

I will be running openvpn on the box, and connecting out through eth0 to a server 'back home'.

I think I understand what you're trying to tell me in your second thought there, however it's not quite clear.  Is it possible you could re-phrase?  If I'm blocking all traffic on eth0, how could any information leak about eth1?

Thanks,

-TD

0 Kudos
Message 3 of 8
(12,028 Views)

You're blocking incoming traffic on eth0. It could be possible that traffic on eth1 (which is open) will be responded to out eth0 (which is fine, outgoing is allowed). If there's some nefarious agent listening to that interface's traffic, they can gather information about your intranet's structure.

Also, if the source of the traffic on eth1 is reachable from eth0, but the source is configured with policy routing, the source would drop the return traffic that comes from you target's eth0 port (since it will likely be the same setup: an outward-facing port for the source of the traffic will see the response-traffic, but since it's on a different port than the initial traffic, it will be rejected). This can result in broken connectivity.

0 Kudos
Message 4 of 8
(12,028 Views)

Ahh, very good.

So if I create an additional rule for eth0 that blocks all outgoing connections, other than 1194 UDP (for openvpn) that should assist in mitigating that.

I'm working on determining the configuration for the network on eth1, however I believe it will NOT have Internet access.

Thanks again Brad, I appreciate the thoroughness.

-TD

0 Kudos
Message 5 of 8
(12,028 Views)

`iptables -vL` is a good way to verify that packet filtering/rejection is doing what you think it's doing.

tduffy wrote:

Hello,

I would like to setup iptables to block all incoming traffic on eth0, while not changing any of the default rules ( allow all ) for eth1 on the cRIO-9068.  From what I gather this should be possible.

From what I gather from this serverfault.com post ( http://serverfault.com/questions/244767/enable-iptables-on-one-interface ), this should be what I want to do:

    iptables -P INPUT ACCEPT
    iptables -P OUTPUT ACCEPT

Be sure to save off the firewall config in /etc/natinst/share/iptables.conf using `iptables-save`. That way, /etc/rcS.d/S39firewall will pick up the config before any network interfaces are configured, and you won't have a hole in your firewall for a short period of time while you're reconfiguring it.

You might want to google "ARP flux" if you're super-paranoid about what information about eth1 might leak onto eth0. There are valid reasons to not worry about ARP flux though.

iptables -P FORWARD ACCEPT

This is not necessary unless you are trying to bridge eth1 to your VPN.

iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i eth0 -j DROP

Related to Brad's comments, I would also suggest adding OUTPUT filters to DROP anything that's not related to the VPN or network bringup (e.g. DHCP).

(warning, untested:) You should probably also set "deny-interfaces=eth0" in /etc/avahi/avahi-daemon.conf to prevent avahi from announcing mDNS services over eth0. (The OUTPUT DROP default rule would also catch this, but avahi will complain very loudly when its packets are dropped.)

0 Kudos
Message 6 of 8
(12,028 Views)

Richard,

Great insights here, thank you.  I'll work on implementing those things and report back any issues.

Thanks again,

-TD

0 Kudos
Message 7 of 8
(12,028 Views)

Richard,

Everything really came together nicely with this, thank you.  Here are the commands I settled on:

$ iptables -F

$ iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

$ iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT

$ iptables -A INPUT -i eth0 -j DROP

$ iptables-save > /etc/natinst/share/iptables.conf

Everything seems to be worknig as expected, and the openvpn connection makes it through without an issue.

Thank you again.

-TD

0 Kudos
Message 8 of 8
(12,028 Views)