Iptables debian

[beOnt]

Hallo iedereen

Ik zit hier al tijdje met iets wat ik niet volledig begrijp. Ik heb dus een linux server met 2 netwerkkaarten, 1e staat op NAT, andere staat op een virtueel netwerk.
Alles is ingesteld, alles werkt perfect.

Ik stel in via iptables:

Iptables –P FORWARD DROP
iptables –P OUTPUT DROP
iptables –P INPUT DROP

dus, op mijn client geen verkeer meer
vervolgens:

iptables -A FORWARD -p tcp --sport 53 -j ACCEPT
iptables -A FORWARD -p tcp --dport 53 -j ACCEPT
iptables -A FORWARD -p udp --sport 53 -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -j ACCEPT
Iptables –A FORWARD –p tcp - - dport 80 –j ACCEPT
Iptables –A FORWARD –p tcp - - sport 80 –j ACCEPT

Dus DNS verkeer laat ik door, en http verkeer.


nu heb ik volgende vragen:

1) Ik kan surfen op mijn client, maar waarom is dit? als ik kijk via netstat-a zie ik dat http verkeer dus poorten crieert (1000-65000)? Waarom laat mijn firewall dan dit verkeer door? Zou hij deze normalitter niet moeten blokkeren? Als ik kijk op mijn client met wireshark, zie ik als destination : nfa (1150) (dus port nummer achter nfa, maar wat is nfa?)

2) om dit alles in orde te krijgen heb ik hetvolgende gezet in sysctl.conf:
net.ipv4.ip_forward = 1
Vervolgens heb ik
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
eenmalig uitgevoerd, en was in orde, maar normaal moet je dit bovenstaande toch in een startup script plaatsen? Elke keer ik herstart werkt alles, maar toch voer ik die regel niet in, en staat ook niet in de iptables -n nat -L ?
Normaal gezien moet je toch deze elke keer ingeven?


Alvast bedankt

[WHiZZi]

1) Omdat je in de FORWARD inderdaad die blokkade hebt, maar niet in je NAT . FORWARD is geen NAT. Zou je het willen blokkeren, moet je dat in de NAT tabel doen,

code:

iptables -A OUTPUT -t nat -p tcp --dport 80 -j DROP

Kijk ook maar eens hoe je firewall er uit ziet met iptables-save, dan zul je zien dat je forward idd geblokt is (en je input en output ook), maar je nat I/O niet.

Zou je een router bouwen die geen nat doet, gaan die forward regels gelden. Bovenstaande regels doen in principe niet veel (behalve blokkeren van je in- en outbound poorten met uitzondering van DNS op forwarding (beetje vreemd, maar het kan )

2) Ook logisch, je past het sysctl.conf bestand aan (dus de forwarding blijft actief) en je flusht je IPTABLES ook niet (dus ook deze regels blijven bestaan). Wil je dus wel, moet je alles flushen en default terugzetten (iptables -X, iptables -F, iptables -Z en daarna niet vergeten om je allows weer toe te staan)

[ Voor 28% gewijzigd door WHiZZi op 01-06-2009 23:18 ]

[Kees]

De 2de regel (de masquarade) is wat het doet; he herschrijft (meestal) extern verkeer zodat het jouw IP adres gebruikt, en houd intern bij waar de return packets vandaan moeten komen. Dat is dus om een andere server/pc toegang te geven tot de netwerken waar de bak waar je het op uitvoert toegang toe heeft.

Masquarade doet niet meer dan 'maskeren' waar het verkeer van origine vandaan komt, en als het dus al vanaf je eigen bak komt, dan heeft het jouw eigen IP al, vandaar dat het ook helemaal niets doet.

Verder snap ik eerlijk gezegt niet waarom je op je client de FORWARD rule gebruikt, er is niets te forwarden, die regels lijken mij redelijk zinloos. Even een schema erbij pakken:



Hier zie je dat verkeer voor lokale processen nooit door de forward rule heenkomt in principe. Waarom jouw rules je dan wel toegang geven tot het internet is mij even een raadsel.

Verder, je client zal een random source-port creeeren voor vrijwel elke connectie die het opzet, wat je dus in jouw regels doet is het toestaan dat je client connect naar poort 53/80. Dat is normaal, dat gaat gewoon goed, ongeacht de sourcepoort (want zodra de destination port matched doe je ACCEPT, wat er daarna komt is niet meer van toepassing).

Verder is het accepten van verkeer op poort 53/80 een vrij zinloze bezigheid, _tenzij_ je zelf ook services op die poorten draait lokaal die bereikbaarbaar moeten zijn.

[WHiZZi]

Kees schreef op maandag 01 juni 2009 @ 23:16:
Hier zie je dat verkeer voor lokale processen nooit door de forward rule heenkomt in principe. Waarom jouw rules je dan wel toegang geven tot het internet is mij even een raadsel.

Omdat dit in de nat-tabel gebeurd, waar default de spullen op accept komen. De lokale server zal inderdaad niks kunnen op bijv poort 443, maar clients wel (omdat deze in de nat state terecht komen). NAT is ook een heel smerig iets wat eigenlijk nooit uitgevonden had mogen worden (maarja, dan hadden we ipv6 ook allang moeten hebben).

Verder is het accepten van verkeer op poort 53/80 een vrij zinloze bezigheid, _tenzij_ je zelf ook services op die poorten draait lokaal die bereikbaarbaar moeten zijn.

^^ with stupid

[raymonvdm]

Ik gebruik shorewall als firewall onder debian. Dit is beter te snappen dan iptables (ten minsten dat vind ik)

Misschien is het voor andere mensen ook handig?

[Verwijderd]

Hmmz, wij gebruiken op mijn werk Uruk voor al onze linux servers als iptables frontend. Werkt perfect

http://packages.debian.org/nl/lenny/uruk

[CyBeR]

raymonvdm schreef op maandag 01 juni 2009 @ 23:28:
Ik gebruik shorewall als firewall onder debian. Dit is beter te snappen dan iptables (ten minsten dat vind ik)

Misschien is het voor andere mensen ook handig?

Shorewall is gewoon een frontend voor iptables.

---

TS: Ik begrijp niet wat de moeilijkheid is. Je zet je policy op DROP, dus alles wordt tegengehouden. Vervolgens sta je in je FORWARD table (die gebruikt wordt voor packets die geforward moeten worden, gek genoeg) alle verkeer van en naar port 80 toe. Waarom snap je niet dat je daarna kunt webbrowsen, gezien dat dat op poort 80 werkt?

Als 't zonder NAT ook werkt heb je ergens verderop in je netwerk richting 't internet ook iets zitten dat NAT doet. Ondertussen doet jouw linux doosje gewoon normale routing.