iptables: nat met uitgaande poorten geblokkeerd

[Boudewijn]

Ik ben een iptables prutser, maar ben momenteel even aan het rommelen met een setupje.
Uiteraard heb ik de manual gelezen en gegoogled maar meestal gaat het om inkomende verbindingen.

De setup:


KVM Host op een 192.168.1.0/24 netwerk, en een los virtueel netwerk in KVM (192.168.122) , dat geNAT wordt door de host naar het 192.168.1.0 net.

Nu ben ik bezig met malware analyse op dat 122 netwerkje, waarbij ik nogal vervelende meuk draai in windows VMetjes. Ik wil per se voorkomen dat deze gaan lopen rotzooien op mijn netwerk/het internet, en daarom wil ik alleen verkeer op poorten 80 en 443 naar buiten toestaan (SMB/irc/smtp echt dicht dus ) vanaf dat netwerk.

Met wat tweaken kom ik bij deze config uit vanuit iptables-save:

code:

root@leiden:/var/lib/libvirt/images# cat /etc/iptables
# Generated by iptables-save v1.4.12 on Mon Dec 17 22:21:14 2012
*nat
:PREROUTING ACCEPT [612:100300]
:INPUT ACCEPT [37:10988]
:OUTPUT ACCEPT [156:20544]
:POSTROUTING ACCEPT [461:45335]
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -j MASQUERADE
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
# Completed on Mon Dec 17 22:21:14 2012
# Generated by iptables-save v1.4.12 on Mon Dec 17 22:21:14 2012
*mangle
:PREROUTING ACCEPT [4307843:4590223211]
:INPUT ACCEPT [85302:129886404]
:FORWARD ACCEPT [4222935:4460372846]
:OUTPUT ACCEPT [67197:236431336]
:POSTROUTING ACCEPT [4290160:4696810832]
-A POSTROUTING -o virbr1 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Mon Dec 17 22:21:14 2012
# Generated by iptables-save v1.4.12 on Mon Dec 17 22:21:14 2012
*filter
:INPUT ACCEPT [85292:129883054]
:FORWARD ACCEPT [4222943:4460381950]
:OUTPUT ACCEPT [67197:236431336]
-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.100.0/24 -o virbr1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -i virbr1 -j ACCEPT
-A FORWARD -i virbr1 -o virbr1 -j ACCEPT
-A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Mon Dec 17 22:21:14 2012

Alleen wil ik dus nu alleen die twee poorten naar buiten toe allowen.... dat is niet zo lastig in iptables zelf dacht ik:

  iptables -A FORWARD -s 192.168.122.0/24 -i virbr0 -j REJECT
  iptables -A FORWARD -s 192.168.122.0/24 -d 80 -i virbr0 -j ACCEPT
  iptables -A FORWARD -s 192.168.122.0/24 -d 443 -i virbr0 -j ACCEPT

maar... dit past niet in mijn iptables-save (ja ik kan op zich die rules toepassen en dan weer de config dumpen) en het werkt niet:

Ik kan nog steeds naar buiten connecten op poort 80 (woei, dat is 1) maar ik kan ook telnetten naar een router op poort 23, wat uiteraard niet de bedoeling is.

Kan iemand me vertellen wat hier mis gaat?

[Hero of Time]

Je uitgaande poort is random. Wat je in je regels hebt, is een destination poort die je toestaat. Je moet even iets verder gaan nadenken hoe het werkt. Pak tcpdump erbij om de stroom te zien die je krijgt als je een telnet of wget uitvoert.

Enne, forward rules voor iets wat je vanaf de initiatie wilt stoppen? Zoek eens hoe je poorten toestaat en blokkeert voor binnenkomend verkeer. Dat kan je dan omdraaien met enige iptables logica. Hint: output/input.

[Boudewijn]

Je uitgaande poort is random. Wat je in je regels hebt, is een destination poort die je toestaat. Je moet even iets verder gaan nadenken hoe het werkt. Pak tcpdump erbij om de stroom te zien die je krijgt als je een telnet of wget uitvoert.

Ja dat weet ik... ik verwoordde het gisteravond in mijn garigheid niet lekker... en zie ook dat ik inderdaad daar lekker dingen verkeer dom hep lopen doen.

Het blokkeren doe je toch gewoon door een REJECT actie (met -j) aan de chain toe te voegen, en daarna de dingen te allowen die je toe wil staan? (als in: closed by default)

[Hero of Time]

Ja, maar dan moet je 't niet met forward rules gaan doen. Dat heb je nodig om verkeer door te sturen met NAT. Maar als er een verbinding van binnenin de NAT geïnitieerd wordt, is het geen forward, maar output verkeer.

[sam.vimes]

De volgorde is ook van belang. Dus eerst -j ACCEPT voor de toegestande poorten, en daarna de rest afsluiten met -j REJECT.

[Tim]

Hero Of Time schreef op dinsdag 18 december 2012 @ 14:40:
Ja, maar dan moet je 't niet met forward rules gaan doen. Dat heb je nodig om verkeer door te sturen met NAT. Maar als er een verbinding van binnenin de NAT geïnitieerd wordt, is het geen forward, maar output verkeer.

Maar het verkeer word gegeneerd op een virtuele adapter (als het output verkeer was, dan was NAT ook niet nodig).

Verder ziten er enkele regels in je config die al het verkeer toestaan (zoals -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT). Die zal je dus moeten weghalen/aanpassen/verplaatsen naar het einde.

[Raymond P]

sam.vimes schreef op dinsdag 18 december 2012 @ 16:33:
De volgorde is ook van belang. Dus eerst -j ACCEPT voor de toegestande poorten, en daarna de rest afsluiten met -j REJECT.

Nee, want dan is de kans aanwezig dat je een REJECT vergeet. Net zoals het voorbeeld hierboven.
Vooral in complexere iptables met chains aan chains.

De makkelijkste basis is je default policies aanpassen naar DROP. (Reject is niet echt stealthy).
Dan weet je zeker dat iig alles geblokkeerd is, en vandaaruit ga je toelaten wat je wilt.

[Hero of Time]

Werkelijk? Iptables werkt met first come first serve met regels. Als je een allow all bovenaan zet, en daarna reject je een bepaalde poort, werkt het niet omdat het verkeer al aan de allow all voldoet. Elke firewall werkt op deze manier, iptables dus ook. Zie ook http://seclists.org/firewall-wizards/2002/Aug/20.

[CyBeR]

Hero Of Time schreef op woensdag 19 december 2012 @ 10:40:
Elke firewall werkt op deze manier, iptables dus ook.

Nah, dat is niet zo. OpenBSD pf gaat door tenzij je 'quick' gebruikt bijvoorbeeld en gebruikt zodoende de laatst matchende rule, en zo zijn er wel meer.

Maar inderdaad de meeste firewalls werken met 'rules checken tot er iets matcht met een actie en dan klaar zijn'.

Verder, de FORWARD tabel is idd voor gerouteerd verkeer zonder nat. Je kunt als 't goed is (ongetest en geen zin om een netwerk ergens tijdelijk te limiteren ) specifiek geNATte poorten blokkeren middels

iptables -t nat -A PREROUTING -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -j DROP

Vergeet niet dat je meestal ook wilt kunnen DNS'en.

[Raymond P]

Hero Of Time schreef op woensdag 19 december 2012 @ 10:40:
Werkelijk? Iptables werkt met first come first serve met regels. Als je een allow all bovenaan zet, en daarna reject je een bepaalde poort, werkt het niet omdat het verkeer al aan de allow all voldoet. Elke firewall werkt op deze manier, iptables dus ook. Zie ook http://seclists.org/firewall-wizards/2002/Aug/20.

Ik gok dat je m'n 'nee' verkeerd heb gelezen.
Ik doel niet op de flow van iptables maar vooral op wat ie doet aan het einde van de flow.

code:

*filter
:INPUT ACCEPT [85292:129883054]
:FORWARD ACCEPT [4222943:4460381950]
:OUTPUT ACCEPT [67197:236431336]

-A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT

:INPUT ACCEPT < Default policy (IPT commands).
Alles wat voorbij de laatste INPUT komt zal dus accepted worden.
De regel die dit voorbeeld mist is dus een DROP of REJECT.

Het is imho dus handiger om de default policy om te draaien zodat zulke fouten niet gemaakt worden:

Bash:

iptables -P INPUT DROP

iptables -A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT

Als nu het einde van de INPUT chain bereikt wordt dan wordt de connectie dus dropped ipv accepted.
Misschien is m'n 'vandaaruit' krom verwoord, maar echt fout is het ook niet.

Op het moment dat je chain na chain hebt is het haast wel een must omdat de leesbaarheid dan toch wel af neemt.
Ik snap dat ik jou dit niet uit hoef te leggen, maar voor de compleetheid van dit topic is het wel handig.

[Boudewijn]

Even weer ontopic


Ik heb deze setup staan:



waarbij ik dus inderdaad poorten 80+443+53(UDP) vanaf de VMs naar het 192.168.1.1 netwerk toe wil staan.
Dat is dus output verkeer gezien vanaf de KVM host, maar ik wil de KVM host zelf wel aan van alles en nogwat kunnen hangen.

Kan ik dit het beste doen door OUTPUT verkeer te allowen als het source adres een 192.168.1 adres is danwel localhost, en anders (dus in geval van een 192.168.122 adres) te deny'en?

offtopic:
En eigenlijk wil ik dan alle verkeer vanaf die VMs naar mijn netwerk verbieden, behalve naar de gateway maar dat zoek ik daarna wel uit.

[ Voor 11% gewijzigd door Boudewijn op 09-01-2013 22:28 ]

[Hero of Time]

Raymond P schreef op woensdag 19 december 2012 @ 11:38:
[verhaaltje]
Ik snap dat ik jou dit niet uit hoef te leggen, maar voor de compleetheid van dit topic is het wel handig.

Ik ben zeker geen expert op gebied van iptables. Je hebt mij wat geleerd Had niet aan die eerste drie regels met ACCEPT gedacht.


Boudewijn, hebben je VMs een eigen bridge interface, of is die bridge gedeeld met je fysieke NIC die tevens door de host gebruikt wordt? Anders kan je 't op interface niveau afschermen, ipv op adres niveau.

[Boudewijn]

Nee het is allemaal bridged. Eventueel zou ik wel met een aparte NIC aan de slag kunnen trouwens.
Op interface niveau, heeft dat nog voordelen boven adres niveau ? Wellicht kan men eea spoofen... maar het gaat hier om wat dingen voor automatische malware-analyse; ik denk niet dat malware met mijn thuissetupje rekening houdt.

[Hero of Time]

Daar gaat het niet direct om, maar meer voor het instellen/beheren ervan. Je kan dan namelijk voor die specifieke interface alle beperkingen instellen met alleen de gaatjes die je wilt, zonder je host buiten te sluiten. Het is wel te doen op adres niveau, alleen vergt het meer regels en denk werk hoe je 't gaat uitvoeren (hoe 't verkeer loopt zodat je 't kan blocken).