[freebsd] ipfilter blockt geen udp

[Verwijderd]

ik gebruik ipfilter als 'firewall' en dat werkt wel goed voor tcp poorten maar
om de een of andere rede houdt ie geen udp traffic buiten... dit zijn m'n ipf.rules:

block in on rl1 proto tcp from any to any port = 25 # sendmail
block in on rl1 proto udp from any to any port = 137 # nmbd
block in on rl1 proto udp from any to any port = 138 # nmbd
block in on rl1 proto tcp from any to any port = 139 # smbd
block in on rl1 proto udp from any to any port = 514 # syslogd
block in on rl1 proto udp from any to any port = 1331 # smbd
block in on rl1 proto udp from any to any port = 1359 # smbd
block in on rl1 proto udp from any to any port = 1363 # smbd

als ik op http://scan.sygatetech.com/ een tcp/udp scan doe blijkt dat
tcp dus wel wordt geblockt maar bij udp staan oa 137 en 138 nog 'open'
weet iemand of dit misschien een bug is of dat ik de rules verkeerd heb?
dank

[Predator]

maak er eens overal
block in quick on rl1 ...
en dan je rules herladen.

[ Voor 3% gewijzigd door Predator op 01-06-2003 22:16 ]

[Verwijderd]

hmz hij laat nog steeds udp door... maar is het wel nodig om udp tegen te houden? kunnen bad-ass hackers er wat mee?

[Predator]

Is dat je volledige ruleset of een stukje ?
Je hebt toch IPfilter support meegecompileerd, en rl1 is toch wel de externe interface ?

NT -> NOS

maar is het wel nodig om udp tegen te houden? kunnen bad-ass hackers er wat mee?

Met UDP niet, met services die het UDP protocol gebruiken en exploits bevatten wel

Maar je kijkt ook beter eens naar statefull firewalling (keep state).
Dat is wat handiger dan die poortjes 1 voor 1 te blokkeren

[ Voor 54% gewijzigd door Predator op 01-06-2003 23:28 ]

[Onno]

Verwijderd schreef op 01 juni 2003 @ 22:12:
als ik op http://scan.sygatetech.com/ een tcp/udp scan doe blijkt dat
tcp dus wel wordt geblockt maar bij udp staan oa 137 en 138 nog 'open'

Sommige scanners zien juist het uitblijven van een reactie als het openstaan van een poort bij UDP. Als een poort dichtstaat krijg je namelijk een port unreachable ICMP terug.

Probeer eens block return-icmp(port-unr) in plaats van block voor je UDP regels, en kijk wat die scanner dan zegt.

(ook voor TCP geldt dat block return-rst wat 'netter' is dan alleen block overigens)

[ Voor 9% gewijzigd door Onno op 01-06-2003 23:53 ]

[epias]

Ik heb die test zojuist ook even geprobeerd en heb die poorten ook open staan. Volgens mij blocked chello die poorten, want ik zie hier geen packets binnenkomen. Zal zelf eens even gaan scannen.

[Verwijderd]

yesz met return-icmp(port-unr) zegt de scan idd dat de port dicht is..
thanks:)

Predator: stateful firewalling lijkt me een ingewikkeld proces, en ik heb nu specifiek deze ports geblockt vanwege sendmail en samba, ik kan niet voor een 'mainly closed' config gaan want dan werkt m;n active ftp niet meer....

[AVL]

ipfilter kan prima overweg met active ftp, juist als je stateful firewalling gebruikt. Zoek op ipnat en ftp proxies. Voorbeelden zijn te vinden in /usr/share/examples/ipfilter/.

[Verwijderd]

pass out log quick proto udp from JE_EXTERNE_IP_ADRES to any keep state
block in log quick proto udp from any to JE_EXTERNE_IP_ADRES

werkt perfect hier met deze rules... (Op OpenBSD, maar dat maakt geen verschil, op FreeBSD is het me ook gelukt)

[ Voor 19% gewijzigd door Verwijderd op 02-06-2003 14:27 ]

[Verwijderd]

UDP bouwt in tegenstelling tot TCP GEEN verbinding op tussen cliënt en server !

De cliënt (b.v. Firewall tester) stuurt een UDP bericht (ook wel diagram) naar de server (Jou server met Firewall). En verder dus niks !!!!!!

Het diagram kan dus best verloren zijn gegaan of zijn tegengehouden door jou Firewall. Dat is niet te controleren door de cliënt.

Tenzij (zoals Onno ook al zij) je specifiek aangeeft dat de Firewall een ICMP bericht moet samenstellen waarin je de client op de hoogte brengt dat het diagram is tegengehouden.

Je Firewall kan op het gebied van UDP dus potdicht zitten zonder dat dit van buitenaf te controleren is.

[serkoon]

Met de kans een eikel gevonden te worden, maar dit moet toch echt gezegd worden: die firewall rules van jou stroken niet. Gelukkig is dat helemaal niet erg, je kunt ze immers makkelijk herschrijven. Herschrijf ze naar wat Data-XxX heeft, dat is Goed (TM).

Wat doe je verkeerd dan?

1) Je blokkeert expliciet. Dat wil zeggen: je geeft aan welke poorten DICHT moeten zitten. Dat is de verkeerde aanpak. Als een h4x0r nou een exploit toepast op je systeem die een shell over UDP openzet (ik bedenk maar wat stoms) op poort 32582, dan staat die gewoon nog open en kan h4x0r z'n shell bereiken. De juiste aanpak is dus: alles blokkeren en expliciet aangeven welke poorten je open wil hebben. Dit is doorgaans ook nog eens minder werk, wat wil je nog meer?

2) Je firewallt UDP poort 25. Mailservers luisteren niet op UDP poort 25, wel op TCP:25. Je firewallt drie poorten >1300 voor smbd en nmbd. Ik weet niet wat je met jouw samba installatie hebt uitgespookt, maar het hoort toch echt niet te luisteren op die poorten. Waarschijnlijk heb je een netstat -na of sockstat gedaan terwijl er een client verbonden was met smbd, waardoor je op die poorten bent gekomen. Toch: niet doen.

Trouwens: het is wel degelijk, al zij het gedeeltelijk, mogelijk om te zien of UDP gefirewalled wordt. Een scanner als nmap kan bijv. prima UDP scannen. Normaalgesproken wordt er nl bij 'dichte' UDP poorten een ICMP destination port unreachable packets teruggestuurd. Wanneer dit niet gebeurt zijn er twee mogelijkheden: 1) er draait een service op die poort die de packet ontvangt en niks terugstuurt of 2) er wordt gefirewalled. Als je dus een flinke zooi UDP poorten bijlangs gaat en er komt nooit wat terug weet je vrijwel zeker dat er gefirewalled wordt. Wanneer de firewall ICMP packets terugstuurt voor alles wat NIET open staat wordt het helemaal makkelijk: alles waar GEEN ICMP packet van terugkomt staat open

[Verwijderd]

tenzij de firewall voor bepaalde poorten een block return-icmp(port-unr) doet en voor andere poorten de packets gewoon dropt.

[Onno]

serkoon schreef op 02 juni 2003 @ 17:45:
2) Je firewallt UDP poort 25. Mailservers luisteren niet op UDP poort 25, wel op TCP:25.

Kweenie hoor, maar in mijn browser staat er gewoon tcp.

Verwijderd schreef op 01 June 2003 @ 22:12:
block in on rl1 proto tcp from any to any port = 25 # sendmail

Trouwens: het is wel degelijk, al zij het gedeeltelijk, mogelijk om te zien of UDP gefirewalled wordt. Een scanner als nmap kan bijv. prima UDP scannen. Normaalgesproken wordt er nl bij 'dichte' UDP poorten een ICMP destination port unreachable packets teruggestuurd. Wanneer dit niet gebeurt zijn er twee mogelijkheden: 1) er draait een service op die poort die de packet ontvangt en niks terugstuurt of 2) er wordt gefirewalled. Als je dus een flinke zooi UDP poorten bijlangs gaat en er komt nooit wat terug weet je vrijwel zeker dat er gefirewalled wordt. Wanneer de firewall ICMP packets terugstuurt voor alles wat NIET open staat wordt het helemaal makkelijk: alles waar GEEN ICMP packet van terugkomt staat open

Ik geloof dat dat al vermeld was.

[Verwijderd]

hmz okey, het idee is dus dat ik ipv bepaalde poorten block, alles dicht moet doen en bijv. 21, 22 en 80 open laat voor ftp ssh en web. maar ftp kiest toch willekeurig nog een paar poorten voor data connections?

en dat keep state schijnt dus de oplossing te zijn? dan ga ik dat nog eens helemaal doorlezen want de rules die ik nu heb zijn blijkbaar gebaseerd op zeer gebrekkige kennis op het gebied van IP etc... Maar dat geeft niet , ik ben hier om te leren ;p

[ Voor 6% gewijzigd door Verwijderd op 02-06-2003 18:59 ]

[serkoon]

Onno schreef op 02 June 2003 @ 17:56:
[...]

Kweenie hoor, maar in mijn browser staat er gewoon tcp.

Ga eens een dag lang naar allerlei presentaties van klasgenoten luisteren en je browser geeft ook UDP aan


TS: Het handigst is inderdaad keep-state. Daarmee ben je in 1 keer van alle gezeur af, vooral met UDP. TCP zou opzich nog zonder keep-state kunnen zonder al te veel problemen.

FTP is een geval apart (waardeloos protocol eigenlijk, maarja). Met ipnat z'n ftp proxy kom je echter een heel eind. Voorbeeldje:

map xl1 10.0.0.0/24 -> 0/32 proxy port ftp ftp/tcp

Dit laat ipnat dus FTP proxyen zodat de systemen op m'n LAN ook zonder problemen kunnen FTP'en. Een FTP-daemon op het systeem zelf zetten is weer een beetje een ander verhaal, maar ook dat is wel te fixen. Ikzelf heb daarvoor simpelweg de poorten >= 49152 opengezet, maar eigenlijk is dat niet netjes