Daniels Blog
30Dez/140

Debian Jessie LXC networking. Containers with public and NATed IPs

It took me some time to get this working so it's time for a blog post:

Scenario
This was a setup for a server in a data center with a public IP address. The server has one physical interface with a public routable IP address. Additionaly I ordered another public IP address for the server to be used in one of the LXC containers.

I have two containers.

Container A
"A" gets a public routable IP-address to be reachable from the internet without NATing

Container B
"B" gets a private IP address and can only be reached thru NAT and port-mappings

Host
Host has 5.5.5.1 as main public IP
Container A has 5.5.5.2 as "virtual" IP
Container B has 10.10.10.1 as NATed private IP

HOST SETUP:



#NETWORKING CONFIG ON HOST
#/etc/network/interfaces

auto lo
iface lo inet loopback


allow-hotplug eth0
iface eth0 inet manual
   pre-up   ifconfig eth0 up
   pre-down ifconfig eth0 down


auto  br0
iface br0 inet static
  address   5.5.5.1
  broadcast broadcast.ip
  netmask   netmask.ip
  gateway   gateway.ip
  bridge_ports eth0
  bridge_fd 0
  bridge_maxwait 0


auto  br1
iface br1 inet static
  address   10.10.10.100
  netmask   255.255.255.0
  bridge_fd 0
  bridge_maxwait 0
  pre-up brctl addbr br1
  up iptables -t nat -F POSTROUTING

  # Exclude boxes with static IPs from Natting
  up iptables -A PREROUTING -t nat -i br0 -p tcp -s 5.5.5.2 -j ACCEPT


  # Enable Forwarding for NATed boxes
  up iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o br0 -j MASQUERADE

  # example PORT FORWARDINGS FOR Mailserver
  up iptables -A PREROUTING -t nat -i br0 -p tcp --dport 25 -j DNAT --to 10.10.10.1:25
  up iptables -A PREROUTING -t nat -i br0 -p tcp --dport 465 -j DNAT --to 10.10.10.1:465
  up iptables -A PREROUTING -t nat -i br0 -p tcp --dport 587 -j DNAT --to 10.10.10.1:587

  # example PORT FORWARDINGS FOR Webserver
  up iptables -A PREROUTING -t nat -i br0 -p tcp --dport 80 -j DNAT --to 10.10.10.2:80
  up iptables -A PREROUTING -t nat -i br0 -p tcp --dport 443 -j DNAT --to 10.10.10.2:443

  post-down iptables -F
  post-down iptables -t nat -F
  post-down brctl delbr br1



#IP forwarding must be enabled in the kernel as well (don't forget reboot)
#/etc/sysctl.conf
net.ipv4.ip_forward=1

CONTAINER A Setup (static virtual public IP):

lxc.utsname = containershostname
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0

# This is the MAC for the public IP i got from my provider
# container gets IP by providers DHCP
lxc.network.hwaddr = 00:11:22:33:44:55

CONTAINER B Setup (static NATed private IP):

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br1
lxc.network.ipv4= 10.10.10.1
lxc.network.ipv4.gateway = 10.10.10.100
20Apr/100

Auf Trojanerjagd mit einer sniffenden Netzbrücke

Vor einigen Tagen erhielt ich einen Anruf mit der Bitte um Hilfe. Aus einem Firmen-LAN mit ca. 10 Clients konnte keine E-Mail mehr versandt werden. Alle Mails blieben in der Warteschlange des lokalen SMTP stecken, der sie an einen Remote-SMTP beim Provider weiterreichen sollte. Eine manuelle Telnet-Session zum SMTP des Providers brachte schnelle Klarheit: "Your IP is blacklisted in Spamcop.net's Spam-Database". Ups. Ich dachte zunächst nichts Böses und ging davon aus, dass das Problem dadurch entstanden ist, dass durch Pech beim täglichen IP-Wechsel eine Ex-Adresse eines Spammers zugewiesen worden war. Nach einem mauellen Reset des Routers, der dadurch eine neue IP bekam, war das Problem auch gelöst (dachte ich zumindest). Die Mails gingen raus.

Einen Tag später: "Wir können keine Mails mehr verschicken!" Oh nein, eine Workstation hat einen Trojaner. Der Spammer ist im LAN. Avira Workstation Pro läuft auf allen XP-Clients im LAN und hat in der Regel auch zuverlässig funktioniert. Hier ist aber wohl etwas schief gelaufen.

Um herauszufinden wer der Übeltäter ist, habe ich den SMTP-Traffic zwischen DSL-Router und LAN gesnifft. Da alle Clients an Switchen hängen, war passives Mithören am selben Switch mit einem Client nicht möglich (Das geht nur mit HUB's). Deshalb habe ich mit einer Debian-Kiste, 2 Netzwerkkarten und 2 Switches ziemlich umständlich einen Wiretap gebaut. Dabei war mir dieser Artikel von heise netze sehr nützlich.

Im Endeffekt muss nur die Verkablung des Sniff-Rechners stimmen, danach muss eine
Netzwerkbrücke erstellt werden:

Die beiden Netzwerkkarten im Rechner wurden gebridged, damit der ganze LAN-INTERNET Traffic auch durch den Pinguin fliessen konnte. Ein Sniff mit Wireshark auf TCP/25 brachte dann sehr schnell die Lösung. In Sekundenschnelle füllte sich das Livelog mit SMTP-Verbindungen eines LAN-CLients zu externen SMTPs.

Den Übeltäter habe ich mit dem Avira Rescue System gebootet. Die Live-CD hat einen Trojaner (TR/Trojan.GEN) festgestellt, konnte ihn aber nicht löschen. Ich habe die infizierte Datei (Zufallsname in system32/drivers) danach mit einer Ubuntu-Live-CD entfernt. Die Spamflut hatte aufgehört. Ich muss es noch einige Zeit beobachten, aber ich glaube der Client ist wieder Herr seiner Sinne.

Ich werde mir mal so einen USB LAN NIC besorgen. Dann geht das ganze auch mit dem Notebook. Das wäre viel angenehmer beim nächsten Mal.

Die heise Schnüffel-Bridge:

apt-get install brctl

ifconfig eth0 -arp promisc 0.0.0.0 up 
ifconfig eth1 -arp promisc 0.0.0.0 up 
brctl addbr br0 
brctl addif br0 eth0
brctl addif br0 eth1 
ifconfig br0 -arp promisc 0.0.0.0 up