[iptables] port status op 'blocked' ipv. 'closed'

[Verwijderd]

ik heb afgelopen weekend een iptables firewall (.. packet filtering 'firewall' ) script geschreven. mijn eerste om eerlijk te zijn. - na wat kleine aanpassingen lijkt deze het uitstekend te doen, alle poorten hebben als status 'closed', met uitzondering van poort 22 (ssh) en 113 (ident), waarvoor ik expliciet heb opgegeven dat deze open moeten staan voor de buitenwereld.

als ik een online portscan (stealth scan) uitvoer @ sygate, krijg ik een lijstje met de meest gebruikte poorten (20 (ftp data), 21 (ftp), 23 (telnet), 25 (smtp), 53 (dns), etc.). alle poorten hebben als status 'closed', met uitzondering van 22 en 113 (open) en 25, 139 en 445 (blocked). alles is gesloten, maar 'closed' is wat mij betreft niet goed genoeg. ik wil alle poorten op status 'blocked' hebben. nu heb ik inmiddels ondervonden dat de target 'REJECT' een poort op 'blocked' zet. echter, deze target kan voor de chains in je filter table niet als default policy worden opgegeven, voor zover ik heb begrepen worden alleen ACCEPT en DROP geaccepteerd.
nu zou ik natuurlijk voor alle poorten uit dat lijstje een rule kunnen maken met als target 'REJECT', maar dit lijkt me zo omslachtig.
mijn vraag is dus: is er een wat minder omslachtige manier om ALLE poorten (uiteraard met uitzondering van 22 en 113) op status 'BLOCKED' te zetten (target 'REJECT')?

(ik heb overigens inmiddels meerdere 'howto's' gelezen, maar geen van de documenten heeft het over dit specifieke onderwerp)

dit is mijn huidige firewall script:
http://members.chello.nl/e.ruiten1/iptables_d_install

ps: poort tcp/25 stond vanochtend ook open. voor deze poort heb ik nu een rule aangemaakt met als target 'REJECT', en deze heeft dus nu als status 'blocked'. ik kan echter niet uitvinden waar dit vandaan kwam. ik heb poort 25 toch volgens mij nergens open gezet..

bvd.

[ Voor 13% gewijzigd door Verwijderd op 16-06-2003 09:44 ]

[Verwijderd]

: is er een wat minder omslachtige manier om ALLE poorten (uiteraard met uitzondering van 22 en 113) op status 'BLOCKED' te zetten (target 'REJECT')?

aan het eind van je keten een regel opnemen dat alle poorten blokt zonder uitzondering. Dan is je poort 25 ook meteen dicht.

DROP is trouwens veiliger dan REJECT afaik

[Verwijderd]

aan het eind van je keten een regel opnemen dat alle poorten blokt zonder uitzondering. dan is je poort 25 ook meteen dicht.

ik heb nu _voor_ de laatste 3 regels (logging) de volgende rule toegevoegd:

code:

iptables --table filter -A INPUT -i $ext_interface -p tcp --dport 0:1023 -j REJECT

... maar dit lijkt niets te veranderen.. de output van de sygate scan blijft hetzelfde..

DROP is trouwens veiliger dan REJECT afaik

dus.. dat zou betekenen dat dit script veiliger is als ik de default policy op DROP laat staan, en REJECT niet gebruik.. (sygate beweert overigens het tegenovergestelde: "Ideally your status should be "Blocked". This indicates that your ports are not only closed, but they are completely hidden (stealthed) to attackers.".)

[ Voor 17% gewijzigd door Verwijderd op 16-06-2003 10:32 ]

[Arzie]

Verwijderd schreef op 16 June 2003 @ 10:30:
[...]
dus.. dat zou betekenen dat dit script veiliger is als ik de default policy op DROP laat staan, en REJECT niet gebruik.. (sygate beweert overigens het tegenovergestelde: "Ideally your status should be "Blocked". This indicates that your ports are not only
closed, but they are completely hidden (stealthed) to attackers.".)

REJECT stuurt een berichtje terug dat de poort gesloten is. DROP gooit gewoon het inkomende pakketje weg en doet verder niks. Dat scheelt dus CPU-tijd en de 'aanvaller' krijgt minder informatie over je PC.

[Verwijderd]

Arzie schreef op 16 June 2003 @ 10:33:
[...]

REJECT stuurt een berichtje terug dat de poort gesloten is. DROP gooit gewoon het inkomende pakketje weg en doet verder niks. Dat scheelt dus CPU-tijd en de 'aanvaller' krijgt minder informatie over je PC.

ok.. REJECT is dus van de baan..

overigens heb ik inmiddels alle poorten op status 'BLOCKED' gekregen.. door bij de intialisatie, reset, en het stoppen van tcp connecties de state match extension toe te voegen (-m state --state ...) .. (het weglaten van deze extensie was overigens ook de reden van de openstaande poort tcp/25 (smtp).. na het toevoegen van deze extensie (en uiteraard het weghalen van de rule om specifiek poort 25 te sluiten) is ook dat probleem opgelost.)

bedankt voor jullie hulp en commentaar

(.. laatste versie van het firewall script heb ik overigens zojuist geupload, voor de geinteresseerden - link staat in de eerste post)

[ Voor 29% gewijzigd door Verwijderd op 16-06-2003 11:07 ]

[Wilke]

Daarentegen is het voordeel van 'reject' dat je geen eindeloze timeouts krijgt (handig op de ident-poort bv. - om te voorkomen dat inloggen op IRC e.d. eindeloos duurt).

Bovendien kun je, als je alles reject, niet zien dat jij een firewall draait. Immers, het verschil tussen geen firewall (standaardreactie = REJECT) en wel een firewall die allerlei poorten beschermt door een REJECT is van buitenaf niet te zien...

Het verschil tussen REJECT en DROP is dat DROP natuurlijk wel te zien van buitenaf, en zo kan een evt. attacker in ieder geval vaststellen dat je een firewall hebt.

[Arzie]

Wilke: dat is ook wel weer zo. Het kost alleen wat dataverkeer en CPU-tijd. Afweging die je zelf maakt dus.

[deadinspace]

Verwijderd schreef op 16 June 2003 @ 09:41:
ps: poort tcp/25 stond vanochtend ook open. voor deze poort heb ik nu een rule aangemaakt met als target 'REJECT', en deze heeft dus nu als status 'blocked'. ik kan echter niet uitvinden waar dit vandaan kwam. ik heb poort 25 toch volgens mij nergens open gezet..

Ehm, kweenie... SMTP server?

Verwijderd schreef op 16 June 2003 @ 10:02:
DROP is trouwens veiliger dan REJECT afaik

De een is niet veiliger dan de ander hoor... Of je nou een packet dropt, of een ICMP port-unreachable terugstuurt, het verkeer wordt verder niet verwerkt.

Arzie schreef op 16 juni 2003 @ 14:26:
Wilke: dat is ook wel weer zo. Het kost alleen wat dataverkeer en CPU-tijd. Afweging die je zelf maakt dus.

Die CPU tijd is compleet te verwaarlozen gok ik zo (in de orde van promilles)

[Verwijderd]

deadinspace schreef op 16 June 2003 @ 14:54:
[...]

Ehm, kweenie... SMTP server?

het is mij bekend _wat_ er achter die poort zit (iptables is enigzins nieuw voor me, networking niet zozeer (!)), het ging me meer om de vraag _waarom_ poort 25 open stond, ik dacht dat ik alles netjes gesloten had..

Wilke schreef op 16 June 2003 @ 13:16:
Daarentegen is het voordeel van 'reject' dat je geen eindeloze timeouts krijgt (handig op de ident-poort bv. - om te voorkomen dat inloggen op IRC e.d. eindeloos duurt).

timeouts worden nu voorkomen door AUTH requests te accepteren, en tcp/113 (ident) open te zetten, hoewel het misschien verstandiger is op tcp/113 ook de state match extension toe te passen of de poort misschien zelfs dicht te gooien.

[ Voor 79% gewijzigd door Verwijderd op 16-06-2003 17:06 ]

[deadinspace]

Verwijderd schreef op 16 June 2003 @ 16:39:
het is mij bekend _wat_ er achter die poort zit (iptables is enigzins nieuw voor me, networking niet zozeer (!)), het ging me meer om de vraag _waarom_ poort 25 open stond, ik dacht dat ik alles netjes gesloten had..

Oh, sorry, dan had ik je verkeerd begrepen

[Arzie]

deadinspace schreef op 16 June 2003 @ 14:54:

[...]

Die CPU tijd is compleet te verwaarlozen gok ik zo (in de orde van promilles)

Ik moet toch één argument voor DROPpen hebben