iptables help for a host bridge and container veth

aitm1212 · 05-02-2018, 03:22 AM

i cant seem to get this right. been digging everywhere for info and examples but all i find are stuff talking about two phy network interfaces. the problem is i only have one and it loses its ip after i create a bridge so that lxc containers can get access to internet. Im trying to just lock it down i guess to open up output and accept established inputs. im kind of having trouble with nats because i dont know if i gotta set -o br0 or -o eno1 or whatever.

this is what i got so far. it works for the most part except keyservers cant be reached from host pc. i even tried to write a rule similar to
"#http traffic forward rule" i have down there, but it doesnt work.

PHP Code:



# close off POLICY 
iptables -P INPUT DROP 
iptables -P OUTPUT DROP 
iptables -P FORWARD DROP 
 
# accept established inbound 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT 
 
# Allow all outbound 
iptables -A OUTPUT -j ACCEPT 
 
# all outbound from container 
iptables -A FORWARD -i br0 -j ACCEPT 
 
# allow http traffic forwarded to container 
iptables -A INPUT -i eno1 -p tcp --dport 80  -j ACCEPT 
iptables -A FORWARD -i eno1 -p tcp --dport 80 -j ACCEPT 
 
# allow ping 
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
 
# forward to container 
iptables -A FORWARD -i eno1 -p tcp --dport 56881:56889 -j ACCEPT 
iptables -A FORWARD -i eno1 -p udp --dport 56881:56889 -j ACCEPT 
 
# reject all other 
iptables -A INPUT -j DROP 
iptables -A FORWARD -j DROP 
 
##### unfinihed 
## nat 
# forward http to container server? 
#iptables -A PREROUTING -i eno1 -p 
 
# 
#  
#iptables -A POSTROUTING -o eno1 -j MASQUERADE

that nat rule i have is incomplete becuase i dont have an ip for the host to complete it with. i think thats my bigggest obstacle right now.
really i want to lock it completly down, even with outputs and just allow ntp keyserver http dns output allowed and established inputs. But i dont even know how to start it. without the bridge it a piece of cake and i had it perfect....now it something frustrating.....please help.

aitm1212 · 05-02-2018, 08:12 PM

changed my current rules to this:

PHP Code:



# close off POLICY
$ipt -P INPUT DROP
$ipt -P OUTPUT DROP
$ipt -P FORWARD DROP
$ipt -t nat -P OUTPUT ACCEPT
$ipt -t nat -P PREROUTING ACCEPT
$ipt -t nat -P POSTROUTING ACCEPT
$ipt -t mangle -P PREROUTNG ACCEPT
$ipt -t mangle -P POSTROUTING ACCEPT

# necessary for loopback interface
$ipt -A INPUT -i lo -j ACCEPT

# enable ip masquerade
$ipt -t nat -A POSTROUTING -o eno1 -j MASQUERADE

# enable unrestricted outgoing traffic, incoming is
# restricted to locally-initaied sessions only
$ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A FORWARD -i eno1 -o br0 -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A FORWARD -i br0 -o eno1 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound
$ipt -A OUTPUT -j ACCEPT

# all outbound from container
$ipt -A FORWARD -i br0 -j ACCEPT

# accept important icmp
$ipt -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
$ipt -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
$ipt -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT

# forward to container
$ipt -A FORWARD -i eno1 -p tcp --dport 56881:56889 -j ACCEPT
$ipt -A FORWARD -i eno1 -p udp --dport 56881:56889 -j ACCEPT

# reject connection not initiated from inside
$ipt -A INPUT -p tcp --syn -j DROP
# reject all other
$ipt -A INPUT -j DROP
$ipt -A FORWARD -j DROP

so far it seems like its working.
but still can someone guide me in creating rules to open up ports to guest containers while at the same time keep it close to the host?
- eno1 is stopped and no longer has an ip
- veth is connected to br0 which is connected to the net?
- ip link set dev eno1 master br0
also can you explain how the host is receiving its connection?
and if any of the rules i have are not needed for my purpose?

MikeDeltaBrown · 05-03-2018, 01:51 PM

I think you may have an issue with layer-2 vs. layer-3 concepts.

First, when you create a bridge between two or more ports (physical or virtual) the ports loose their IP address and the bridge interface becomes, basically, a layer-3 parent. ARP broadcasts, for instance, should come in on one port and go out on all ports. This is a layer-2 protocol and is not affected by iptables (netfilter kernel code, actually). To control layer-2 traffic between ports in a bridge you need to use ebtables.

The following suggestions are presented just as opportunities for learning since the firewall code doesn't really apply for a bridged configuration:

You asked if any rules are not needed: You are setting a default policy of DROP for OUTPUT and then adding a specific rule to ACCEPT all output. Not really a big deal but....

Accepting --ctstate NEW packets effectively opens your firewall to all traffic. Better to only open specific ports with a DNAT rule.

A good reference for layer-3 firewalls on linux is Packt Publishing's "Designing and Implementing Linux Firewalls and QoS using netfilter, iproute2, NAT and l7-filter".

Check out Cisco articles on SVI's and BVI's for a little extra knowledge.

aitm1212 · 05-04-2018, 12:39 AM

thank you.

aitm1212 · 05-05-2018, 03:54 PM

I've order a used copy of that book and currently reading "ebtables/iptables interaction on a Linux-based bridge" @ ebtables.netfilter.org. this is a lot of information to take in for securing a box.

Right now there is one thing I can't figure out which will help me a lot with this is this:

does eno1 now belong to br0 where packets come in through br0 and distribute to eno1 or does it come in to eno1 then to br0?
eno1 is the phys interface thats connected to the internet.

MikeDeltaBrown · 05-05-2018, 04:33 PM

Here's another learning opportunity Re: Layer-2 vs. Layer-3 :-)

What actually comes in are ethernet frames (layer-2), with source and destination MAC addresses, with a Layer-3 packet enclosed. The bridge acts like a switch which determines which port to send the "data" which is determined by the IP address (layer-3). What associates ethernet Layer-2 MAC addresses with Layer-3 IP address is the ARP table. If the destination is on the LAN (same broadcast domain) then the frame is sent out the proper port. If the destination is not on the LAN the packet is stripped out of the frame(L2), a new frame(L2) is created around the packet(L3), then this new frame is sent on towards the destination (this is a result of the routing process).

So, to directly answer your question: yes, the physical port, eno1, belongs to the bridge. If the traffic you're interested in are the "packets" (L3) then look towards the br0 "interface". If you're interested in the "frames" (L2) then look at the physical interface eno1.

To see ARP in action get a command line prompt and type `tcpdump -i eno1 -n arp`. You should see something like:
13:27:08.565464 ARP, Request who-has 192.168.1.21 tell 192.168.1.65, length 28
13:27:08.566550 ARP, Reply 192.168.1.21 is-at 80:2a:a8:5c:e6:bc (oui Unknown), length 46

...this is how ARP fills in the ARP table.