Een firewall voor OS/2

>Firewall Index <

De taken van een firewall

> Top <

Een firewall regelt het verkeer van en naar uw netwerk. De firewall bewaakt de internettoegang en legt netwerkactiviteiten vast. Dat kan op verschillende manieren. Zie het artikel over Firewall technieken.

Zo regelt een proxy server de verbindingen tussen actieve netwerkapplicaties. Een generieke SOCKS server sluist de data van zijn geautoriseerde gebruikers ongewijzigd door, maar zal wel netwerkadresvertaling geven. Een HTTP proxy als Privoxy zal ook de inhoud onderzoeken van het protocol dat hij beheerst.

Een packet filter firewall werkt op de IP laag. Zijn stuurbestanden analyseren het in- en uitgaande IP verkeer bij de netwerkadapters. Wat is herkomst (het opgegeven IP adres), wat is het protocol (poortnummer) en wat is de bestemming. Al voordat een pakketje de meer kwetsbare delen van de TCP/IP stack en de doelapplicaties heeft bereikt, evalueert het IP filter op grond van in configuratiebestanden vastgelegde Foreward en Deny regels of het pakketje door mag gaan of niet. Deze evaluaties worden in een logbestand vastgelegd.

Ook netwerkapplicaties kunnen wie-wat-waar vragen regelen. Zo kunt u in OS/2 Warps implementatie van het NetBIOS via TCP/IP protocol bepalen dat alleen gebruiker "sjoerd" met het wachtwoord "geheim" de bron "data" mag gebruiken. Gebruikersauthenticatie (hier de inlognaam en wachtwoord) zijn dan in de applicatie geïmplementeerd. Maar het is vervelend als ook onbekenden inlogpogingen kunnen doen. Het is zoiets als een dief die rond uw huis loopt en aan de deur morrelt. In zo'n geval kan de firewall dienst doen door uw poorten te verbergen (de stealth functie), open poorten voor ongewenste bezoekers af te sluiten en het in- en uitgaande netwerkverkeer te loggen.

Maar ook de best geconfigureerde firewall doet weinig tegen fouten in de door u gebruikte programma's. Om Denial of Service (DoS) attacks, bufferoverlopen en wachtwoordkrakers te voorkomen moet u uw applicaties en besturingssysteem zorgvuldig kiezen, configureren en onderhouden (patchen), voordat een cracker of virus ze op bekende gaten test. Daar begint het mee. Daarnaast kunt u een firewall en een virusscanner installeren. Een goed geconfigureerde firewall kan de toegang tot het internet van onveilige programma's beperken en houdt logbestanden bij.

Nu is het de vraag of u dit alles ook onder OS/2 nodig hebt. Ik ga hier nu niet op in. Zie hiervoor het artikel Lastige klanten en het internet.

Dit artikel gaat over de mogelijkheden van de in eComStation en Warp 4 Convenience Packages verborgen OS/2 firewall die veel lezers al zullen hebben.

Een firewall van OS/2

> Top <

De 32 bits TCP/IP v. 4.1 stack van OS/2 Warp Server for e-Business (WSeB, 1997) kreeg elementen van de AIX firewall mee. De AIX firewall was naar BSD UNIX 4.4 gemodelleerd. De hierop gebaseerde SecureWay Firewall heeft zich over de jaren heen geëvolueerd tot een betrouwbaar pakket om e-Business mee te bedrijven. Professionele versies kostten duizenden dollars. Het pakket bevat IP filters, proxies en socks ondersteuning en is voor Windows NT of AIX servers in grote bedrijfsnetwerken bedoeld.

De eComStation bèta cliënt installeerde standaard de 16 bits TCP/IP stack van Warp 4, maar bevatte een optioneel te installeren TCP/IP versie 4.3 voor OS/2. eComstation versie 1.1 installeert TCP/IP 4.3 zo uit de doos. Deze van Warp Server afkomstige 32 bits OS/2 TCP/IP stacks bevatten een packet filtering firewall met IPSecure Virtual Private Netwerk ondersteuning als onderdeel van MPTS. Maar helaas zijn de hiervoor bestemde programma's en stuurbestanden nauwelijks gedocumenteerd. Tcphelp DES.SYS levert niets op. Ook ontbreken socks en proxy servers. Het was dus maar de vraag of ik met zo'n allegaartje een bruikbare firewall kon opzetten. Het gaat bij de eCS cliënt immers om een minimaal door IBM ondersteund product: geen paradepaard, maar een stiefkind.

Gelukkig bleek dit wel het geval. U kunt er een solide firewall mee opzetten. Voor internettoegang op het netwerk is een open source proxy server van Hobbes nodig. NAT wordt niet of nauwelijks ondersteund (NAT built in to MPTS ?). Maar de differentiatie die u met de filterregels kunt aanbrengen is enorm. Hierdoor werd de open poort van mijn webserver vaak niet eens door een poortscanner gezien! De real-time logging van het IP verkeer is een genot om te zien. Ik zoek nog een partner om VPN tunnels mee te bouwen. Maar begin er alleen aan als u voldoende van IP netwerken weet, cryptische logbestanden kunt lezen en van netwerkpuzzels houdt. Want firewall Wizards ontbreken.

Onderstaande tekst kan u daarbij helpen. Neem echter niets klakkeloos over. Ieder netwerk ziet er weer wat anders uit. Wat dat betreft hoop ik dat de onvermijdelijke netwerkdetails de meerderheid van de lezers zullen afschrikken. Raadpleeg voor meer details de teksten en verwijzingen op mijn website (http://www.xs4all.nl/~vissesh/multiboot/firewall).

Wat dat betreft zijn personal firewalls als die van Injoy, SafeFire PPP en Internet Gate gemakkelijker op te zetten. Ze beschikken over NAT of proxy's om het internet voor het netwerk toegankelijk te maken. Injoy producten komen met eComStation.

Kabelmodem en ADSL gebruikers kan ik een hardware router met ingebouwde firewall aanbevelen. Vooral als u publieke servers draait en/of op met een multiboot PC op een lokaal netwerk zit. Met zo'n router hoeft u niet voor ieder besturingssysteem een aparte firewall te installeren. De router regelt de internettoegang en bewaakt het internetverkeer. Om op het internet te komen hoeft u slechts de router als default route in OS/2's TCP/IP instellingen op te geven. Zoek voor OS/2 naar een niet-USB ethernetrouter met een web-interface die vanuit ieder OS te configureren is.

De routersoftware is meestal tot in de puntjes via een cgi web interface te configureren (bijvoorbeeld: Draytek). De firmware (het besturingssysteem van de router) wordt via tftp of onder ODIN lopende Windows utilities bijgewerkt. Kortom een geschikte router is: geen gezeik, ieder OS een internet rijk.

Maar als u servers draait en/of veiligheid voorop stelt, zou ik een proxy achter de router inzetten (zie: Een semi-professionele firewall en Squid). En zet u de routing van OS/2 uit. Verder moet u heel goed nagaan of de router echt niet via zijn WAN interface vanaf het internet (telnet, HTTP) via een standaard wachtwoord is te benaderen.

Het feit dat u een zogenaamde hardware firewall kocht, biedt nog geen garantie dat die router ook als keiharde firewall is ingesteld... U koopt de hardware, maar de bijgeleverde software (firmware) moet u altijd zelf instellen en via poortscanners testen.

De firewall componenten installeren

> Top <

Voor het installeren van een Packet Filtering Firewall zijn twee stuurbestanden nodig.

DEVICE=H:\MPTN\PROTOCOL\FWIP.SYS 
DEVICE=H:\MPTN\PROTOCOL\IPSEC.SYS 
REM DEVICE=H:\MPTN\PROTOCOL\CDMF.SYS 
REM DEVICE=H:\MPTN\PROTOCOL\DES.SYS 
REM DEVICE=H:\MPTN\PROTOCOL\MD5.SYS 

Voor zover ik kon nagaan houden deze stuurbestanden zich met de volgende zaken bezig:

IP Packet filtering met Forward (FW) en Deny rules is een essentieel onderdeel van iedere firewall. FWIP.SYS voegt dit IP filter aan de 32 bits TCP/IP stack toe.

IP Security is onderdeel van het aanstaande Internet Protocol versie 6 (IPv6) van de IETF. Het beschrijft authentisering en encryptie op de IP laag van de TCP/IP stack. Het IPSEC.SYS stuurbestand voegt die functionaliteit aan de IPv4 stack van OS/2 toe, waardoor applicaties op de applicatielaag geen encryptie meer hoeven te ondersteunen en/of er versleuteling op meerdere niveaus kan plaatsvinden (bijv. S-HTTP en IPSecure). Het stuurbestand is hier geactiveerd om de firewall logfunctie te ondersteunen.

IBM's Commercial Data Masking Facility (CDMF) encryptie stuurbestand CDMF.SYS helpt bij de versleuteling van data over Virtual Private Networks. Het is een verbeterde versie van het veelgebruikte Data Encryption Standard (DES) algoritme (DES.SYS). Het zou sneller zijn en data in grotere blokken versturen.

Het Message Digest versie 5 (MD5) checksum protocol (DES.SYS) kan nagaan of de berichten onveranderd overgekomen te zijn. Het wordt o.a. door virusscanners gebruikt om de integriteit van bestanden te controleren.

De Device Drivers CDMF.SYS, DES.SYS en MD5.SYS kunt u gerust remmen, want ze zijn voor zover ik weet alleen van nut als u zich via een specifieke IBM Firewall en IP Secure server met een achterliggend virtual private network verbindt. Het zou mooi zijn als dit DES stuurbestand ook zijn nut had bij open source IP Secure servers, maar dat is bij mijn weten niet het geval.

Tijdens de installatie heb ik ServerConfig/2 for Apache, IPS and IBM Firewall gebruikt om de firewall te activeren en te deactiveren: de firewall legt standaard uw netwerk lam. Recente eComStation clients hebben Zampa als hulpmiddel bij de configuratie. Alex Taylor heeft een uitstekend INF bestand over de firewall gemaakt (The OS/2 Firewall).

Eenmaal ingesteld kan het IP packet filter automatisch bij het booten worden gestart door de volgende opdrachten aan \mptn\bin\setup.cmd toe te voegen. Toets voor details over afzonderlijke opdrachten tcphelp inetcfg.

route -fh
arp -f
ifconfig lo 127.0.0.1
ifconfig lan0 192.168.1.5 netmask 255.255.255.0 metric 1 mtu 1500
REM ###### Firewall starten ####
inetcfg -s firewall 1 
cfgfilt -u -i -d start
REM ##### Einde firewall ######
route add default 192.168.1.1 -hopcount 1
route add -net 10.0.0.0 192.168.1.1 -netmask 255.0.0.0 -hopcount 2
ipgate off

Een alternatief zou de aanmaak van het bestand \tcpip\bin\tcpexit.cmd kunnen zijn. Setup.cmd wordt immers door het TCP/IP configuratie notebook beschreven en daarbij zou ooit iets mis kunnen gaan. Ik heb dat echter nog niet meegemaakt.

REM Firewall starten 
inetcfg -s firewall 1 
cfgfilt -u -i -d
REM Einde firewall

U kunt hier nog wat regels (vlaggen) aan toevoegen tegen synflooding aanvallen.

inetcfg -s synattack 1
inetcfg -s syncookie 1

Voor een uitleg zie: SYN flooding en denial of service .

Voor meer inetcfg opties: inetcfg ? | more.

De volgende opdracht legt de inetcfg opties in een tekstbestand vast.

[H:\]inetcfg -g all
File :H:\MPTN\ETC\inetcfg.ini created.

Met de -g(et) optie kunt ze afzonderlijk opvragen en met de -s(et) optie instellen.

[F:\]inetcfg -set keepalive 7700

[F:\]inetcfg -get keepalive
#Inetcfg:       CURRENT DEFAULT MINIMUM MAXIMUM
keepalive       7700    7800    0       7800    KeepAlive (sec)

C:\Documents and Settings\sjoerd>net use P \\multiboot\P-drive
Systeemfout 67.

Kan de netwerknaam niet vinden.

inetcfg -s syncookie 0

inetcfg -s syncookie 1

Maar aangezien tcpstart.cmd niet altijd opstart (staat daarom in mijn startup.cmd), kunt u de hele opdrachten tevens in de startup.cmd kwijt.

call /min f:\tcpip\bin\tcpstart
inetcfg -s firewall 1 
cfgfilt -u -i -d start
inetcfg -s synattack 1
inetcfg -s syncookie 1
detach f:\mptn\bin\fssd.exe
detach syslogd
start /b /c /min f:\cmd\privoxy.cmd
start /min /b /c f:\cmd\squid.cmd

Verder moet u nog enige configuratiebestanden aanmaken.

De secure interfaces worden in het bestand %etc%\fwsecad.cnf vastgelegd. Het gaat om IP adressen die u veilig beschouwd. In Netwerkinterfaces: veilig of onveilig worden ze besproken. Plaats hier in ieder geval het IP adres van uw eigen computer "localhost":

127.0.0.1

Normaal gesproken zou de voor privé netwerken bestemde 192.168.1.5 lan0 adapter ook een veilige interface moeten zijn. Maar die netwerkaart heb ik direct op het internet gezet om de OS/2 firewall te kunnen testen. De OS/2 PC bevindt zich dan in de "gedemilitariseerde zone" van de hardware router.

De filterregels voor FWIP.SYS worden in het bestand %etc%\Security\fwfiltrs.cnf vastgelegd. Ze komen aan de orde in Regels opstellen. Maak hier regelmatig een backup van. U kunt de opdracht cfgfilt gebruiken om de firewall na een belangrijke configuratiewijziging te controleren. Het geeft de regels in ene overzichtelijke vorm weer. Plaats ook Internet URLs van betrouwbare poortscanners op uw desktop.

Het firewall logsysteem

> Top <

Het belang van het firewall-logsysteem

> Top <

Het logsysteem dat het IP verkeer aan uw netwerkingangen registreert, vertelt u nauwgezet wat er op uw PC gebeurt. Door de berichten van de firewall via tail of een grafisch hulpmiddel real-time te volgen, krijgt u een controle over het netwerkverkeer. Als u surft of een externe poortscan uitvoert schieten de (fout)meldingen voorbij, maar als u niets doet behoort het filter vrij stil te zijn. Bent u hier eenmaal mee vertrouwd, dan laat u de firewall alleen bijzonderheden registreren.

Vergelijk uw PC met uw huis. Op een warme zomerdag staan de ramen en deuren wijd open. Maar omdat u ogen en oren heeft, vertrouwt u vertrouwt erop dat u bezoek tijdig zult opmerken. U kent de typische geluiden. Dat is de kat en dat is die rammelende achterdeur. Het zijn voor u geen spookgeluiden meer. Maar als u uw huis verlaat, gaan de ramen en deuren weer dicht. Want als niemand het huis in de gaten houdt, kan er van alles gebeuren.

Op dezelfde manier is een slim ingesteld firewall logsysteem een onmisbaar zintuig op uw (inter)netwerk PC. U hebt misschien een gevoel van controle over uw PC omdat er niets zichtbaars gebeurt, maar u weet het niet als u uw netwerkverkeer niet registreert. Onwetendheid geeft slechts een gevoel van zekerheid. U merkt uw vergissing hoogstens als de inbreker al weer met de buit vertrokken is, of misschien wel nooit, omdat een virus "slechts" bestanden kopieerde en/of een verborgen server op uw PC aanbracht.

Denk dus niet dat u niets gebeuren kan. En vooral niet op uw PC. Net zo goed als uw woning geen Fort Knox is, is een PC vrij gemakkelijk te kraken. Niet alleen door niets ontziende virussen, maar ook door de boze buurman, een gefrustreerde werknemer of een concurrent. Voor het aftappen van uw telefoon is technische knowhow en een toestemming van de Officier van Justitie nodig, maar met het illegaal kraken van een Windows of Linux PC kan iedereen die Google weet te gebruiken meteen aan de slag. Maar zonder deugdelijk logsysteem kunt u een illegale poging tot inbraak niet eens bewijzen. Als u ook maar iets op uw PC heeft staan waarvan u de privacy fysiek en juridisch wilt beschermen, zet dan een firewall met een logsysteem in.

Het loggen is al helemaal onmisbaar als u de firewall opzet. U maakt immers altijd fouten. Er blijken bij de DENY ALL strategie waar de OS/2 firewall gebruik van maakt, altijd protocollen te zijn waar u geen rekening mee hield. Onbedoelde lekken kunt u met een poortscanner opsporen, maar als een server of cliënt programma niet loopt, kan het firewall logsysteem u precies vertellen welke poorten en interfaces in het geding waren. Door de firewall logbestanden exact te lezen kunt u precies bepalen welk regeltje nodig is om een programma doorgang te verlenen. U hoeft uw poorten niet wagenwijd open voor alles en iedereen te zetten. U kunt van iedere poort precies aangeven van welke locatie (poort en IP nummer) en met welk protocol (UDP, TCP, ACK) hij benaderd kan worden. Want dat is de kracht van deze op BSD gebaseerde firewall. U kunt precies aangeven wat u wel en niet wilt.

Logbestanden maken

> Top <

Zeker in het begin is het heel belangrijk dat u feedback krijgt door middel van het logsysteem. Later zult u het selectief loggen van activiteiten kunnen waarderen om ongewenste activiteiten op te sporen en netwerkproblemen op te lossen. Zet voor het automatisch inschakelen van het firewall logsysteem minimaal de volgende opdrachten in startup.cmd.

detach fssd
cfgfilt -u -i -d start

De eerste opdracht laadt de firewall log daemon (fssd) op de achtergrond en de tweede laadt de firewal (-u -i) met de logfunctie (-d start) aan. De FWIP.SYS en IPSEC.SYS stuurbestanden maken daarna iedere dag een logbestand met de naam fwMMDD in %ETC%. Het bestand \MPTN\ETC\fw1224 is dus op 24 december aangemaakt.

Maak ook een bestand fwlog.cnf in %ETC% met de tekst:

level=20 

Dit regelt het "verbosity" (spraakzaamheid) niveau. Oftewel de mate van feedback voor zover de filterregels het toelaten..

10(Debug -All messages are logged)
20(Informational -Information, warning, error and alert messages are logged)
30(Warning -Warning, error and alert messages are logged)
40(Errors -Error and alert messages are logged)
50(Alert -Only alert messages are logged)

Met de opdracht:

cfgfilt -d stop

zet de logfunctie weer uit. Dit kan nodig zijn als u over weinig schijfruimte beschikt. Na veranderingen in de configuratiebestanden typt (in een programmaobject (:-): cfgfilt -u -i -d start . U stopt de firewall met cfgfilt -c.

Idealiter wordt een firewall logbestand naar een vertrouwde computer of een seriële poort verzonden. Hiermee wordt voorkomen dat een hacker zijn sporen in de logbestanden wist en/of dat de computer vastloopt door opraken van schijfruimte. Het uitzetten van het alarm is immers het eerste doel van een hacker. Nu is het forwarden via de syslog daemon niet gedocumenteerd, maar met de variabele SET FWLOGS=j:\var\log kunt u wel een andere map dan ETC aangegeven voor het logbestand. Dat zou via het NetBIOS misschien ook op een andere PC kunnen staan (SET FWLOGS=\\zolder\samba\os2log), maar in de praktijk bleek dit nog niet te werken. Grote logbestanden zijn overigens uitstekend te comprimeren.

Logbestanden met fwlslog bekijken

> Top <

Een actueel (geopend) logbestand kunt u niet met een tekstbewerker bewerken, maar u kunt er met hulpmiddelen als cat, type, tail en fwlslog wel snapshots van maken. Het bij de firewall geleverde f(ire)w(all)l(i)s(t)log maakt de tekst meteen op. Een batch om de output van DDMM met E.exe te zien (fwlog.cmd 1231):

REM Toont het hele logbestand van MMDD (%1) met E.exe
REM Vervang %ETC% door %FWLOGS% als u die parameter gebruikt.
fwlslog file=%ETC%\fw%1 > %temp%\fwlog.tmp & e %temp%\fwlog.tmp

In dit geval plaatst u een [] of de actuele MMDD van de dag in het parameterveld van het programmaobject van de batch.

Nu is het handiger om de fwDDMM logbestanden als geformatteerde fwMMDD.txt teksten te bekijken. Sleep een logbestand naar een Programmaobject die verwijst naar een batch met de volgende inhoud (drag en drop Unix) en het ziet er al beter uit:

@echo off
rem fw2txt.cmd maakt een opgemaakt logbestand in %ETC% aan.  
fwlslog file=%1 > %1.log
start e %1.log
exit

Nu kan zo'n logbestand in korte tijd tot vele megabytes groeien en dan duurt het laden wel erg lang. Om die reden laat ik met de parameters strrec=0 numrec=200 alleen de laatste 200 regels zien.

@echo off
REM Show last (strrec=0) 200 (numrec=200) records of fwlog.
REM with the actual fiterrules. 
REM If required replace %ETC% by %FWLOGS%.
call setmmdd.cmd
type %ETC%\security\fwfiltrs.cnf > %temp%\fwlog.tmp
@echo ######################################################## >> %temp%\fwlog.tmp 
fwlslog file=%ETC%\fw%MMDD% strrec=0 numrec=100 >> %temp%\fwlog.tmp 
start e %temp%\fwlog.tmp & exit

Het REXX script setmmdd.cmd haalt hier de actuele systeemdatum voor u op:

/* Script om MMDD systeemvariabele aan te maken  */
Datum = Date('U') /* U - USA formaat MM/DD/YY */
Maand = Left(Datum,2)
Dag = SubStr(Datum,4,2)
'SET MMDD='||Maand||Dag
exit

Het combineren van logbestanden met de filterregels bleek wel handig om fouten op te sporen en oplossingen te documenteren. Bekijk ook de filteropties van fwlslog eens met tcphelp fwlslog. Vooral de "grep" achtige optie om met msgtxt="text string" de activiteiten van bepaalde hackers te volgen, is bereslim.

rem Doorzoekt het logbestand fw%1 op de %2 string.  
if "%2" == "" goto today
fwlslog file=%etc%\fw%1 msgtxt="%2" > %temp%/fwlog%1%2.tmp
start e %temp%/fwlog%1%2.tmp
exit
:today
call setmmdd.cmd
fwlslog file=%etc%\fw%MMDD% msgtxt="%1" > %temp%/fwlog%MMDD%%1.tmp
start e %temp%/fwlog%MMDD%%1.tmp
exit

Maar u kunt het ook gebruiken om te achterhalen hoe vaak een poort wordt benaderd of wat u maar wilt.

Helaas ondersteunt fwlslog de string file=%etc%\fw???? niet. Maar voor het doorzoeken van vele logbestanden is ook wel een batch of REXX script aan te maken. Ook bieden de tekst georienteerde UNIX utilities u nog gelegenheid genoeg om u voor te bereiden op het jaar 2007. Voor ideeën houdt ik me aanbevolen. NB. Als u vooral in de actuele logbestanden kijkt is het wijs om een variabele DDMM aan te maken.

Logbestanden met tail bekijken

> Top <

Met de onvolprezen -f(ollow) optie van het GNU text utility tail (staart) bereikt u hetzelfde maar dan in ongeformateerde vorm. Tail is op Hobbes in textutils-2_0-bin.zip te vinden. Ik gebruik deze batch om verdachte activiteiten te volgen:

REM fwtail.cmd toont de staart van het FireWall logbestand
REM fwMMDD in 132 kolommen en 50 regels 
@echo off
mode co132,50
if "%1" == "" goto today
tail -f -n 50 %ETC%\fw%1
exit
:today
call setmmdd.cmd
echo %MMDD%
tail -f -n 50 %ETC%\fw%MMDD%
exit

Tijdens een poortscan vliegen de foutmeldingen langs het scherm. Ziet u dat niet, dan is er een grote kans dat u een levensgevaarlijke PERMIT ALL in het fwfiltrs.cnf hebt staan (let op de interfaces!) of verzuimt hebt de DENY regels te loggen.

Als u met tail de standaardopmaak van fw0506 bekijkt ziet u een nogal kale tekst.

20030506 003558 ecs 32: 20; ICA1041w; 192.168.1.5;6;217.149.193.38;192.168.1.5;tcp;62717;25;local;non-secure;n;0;n;40;

Na opmaak door fwslslog staat er dit:

05/06/03 00:35:58 ICA1041w: Denied packet in.  Rule: 6  Source addr: 217.149.193.38  Destination addr: 192.168.1.5  Protocol: tcp  Source port: 62717  Destination Port: 25  Routing: local  Interface: non-secure  Adapter: 192.168.1.5  Fragment: n  Tunnel: 0  Encryption: n  Size: 40.

Oftewel: Iemand probeerde op eCS (192.168.1.5 door de in de DMZ ongecensureerde netwerkadresvertaling van de router!) een smtp server te scannen. Tevergeefs: "This port has not responded to any of our probes. It appears to be completely stealthed" zegt http://scan.sygate.com/quickscan.html ervan. Het komt echt niet door dat IP adres, maar door de genuanceerde filterregels van de BSD firewall. Hoe dat in de DMZ kan terwijl sendmail toch voor het 192.168.1.0 netwerk open kan staan vertel ik u verderop in TCP/IP servers voor de buitenwereld verborgen houden.

Fwlslog is dus een opmaakfilter voor de door fssd.exe aangemaakte fwMMDD firewall logbestanden, zoals ipformat dat voor de iptrace dmp-bestanden is. Maar vanwege het online gemak van tail is het goed om nog eens naar de door fssd.exe aangemaakte regels te kijken.

Bij verder onderzoek van de logbestanden zijn de UNIX tekst utilities als cat, sed, tee, tail, find en grep bijzonder handig. Sed is de streaming text editor en is een programmeertaal op zich. Met dergelijke hulpmiddelen kunt u zichzelf mailtjes of "start e" pop-up menu's sturen als er wat vreemds gebeurd. Ze zijn te vinden op Hobbes en hebben de EMX bibliotheek nodig. Let op: Ze zijn zo krachtig dat u ze buiten het pad moet houden als u publieke internetservers draait.

Netwerkinterfaces: veilig of onveilig

> Top <

Als u een firewall opzet, moet u weten wanneer en van wie u gevaar loopt. Maar net als in het gewone leven is dat soms moeilijk te beoordelen. Onze hersenen hebben hier criteria voor. We beoordelen, vaak in fracties van seconden, wie wat doet. En komen dan snel tot actie.

Meestal gaan we ervan uit dat (buiten de paringstijd om) onze groepsleden te vertrouwen zijn, maar vreemden niet. We pikken veel van onze gezinsleden, maar hanteren strenge regels voor de rest van de wereld.

Om het leven overzichtelijker te maken markeren we ons eigen territorium. De onze mogen zich in ons leefgebied bevinden, vreemden houden we buiten de deur. En wie ons territorium binnendringt jagen we weg of houden we goed in de gaten.

De OS/2 firewall houdt rekening met . In essentie verbiedt hij alles. Maar hij maakt een onderscheid tussen veilige en onveilige interfaces (verbindingen) en accepteert hier aparte regels voor. Zo kunt u de netwerkverbinding met uw LAN als een "vertrouwde verbinding" (secure interface) beschouwen, maar de modem verbinding met de rest van de wereld niet (non-secure interface).

Voor beide interfaces stelt u dan andere regels op. Voor de secure interface van een virusvrij LAN kunt u van open regels (alles toestaan, tenzij) uitgaan, terwijl u een op uitzonderingen gebaseerd systeem (verbiedt alles, tenzij) voor het internet hanteert. Het is een kwestie van vertrouwen: u geeft uw eigen netwerk het voordeel van de twijfel, maar u wilt u niet laten belazeren op het internet. Maar gemak speelt ook mee: door uw eigen netwerk op de veilige interface weinig beperkingen op te leggen, voorkomt u dat de firewall uw thuisnetwerk plat legt.

Binnendeuren en buitendeuren

> Top <

In het artikel Lastige klanten. Het thuisnetwerk en het internet worden de verbindingen van uw computer besproken. Ze lopen via netwerkinterfaces (lan0, lan1, ppp0) waar een of meer IP adressen aan zijn verbonden. In dit verband sprak ik van binnen- en buitendeuren. Het LAN werd met een huis vergeleken. En een interface met een deur.

Als het goed is kent uw netwerk een veilige zone waarbinnen u ongestoord kunt werken. Binnendeuren (veilige interfaces) verbinden de vertrouwde delen van uw huis. Ze mogen open staan. De buitendeuren die u met de rest van de wereld verbinden houdt u op slot. De interfaces van de op de buitenwereld aangesloten netwerkkaarten en modems kunt u niet als veilig beschouwen. Ook al worden ze door uw LAN gebruikt. De voordeur kan open staan, maar veilig is het niet.

In de regel zal een thuisgebruiker binnen zijn eigen netwerk (LAN) weinig verkeer willen tegenhouden. U gaat ervan uit dat de gebruikers van uw netwerk te vertrouwen zijn. De netwerkkaart die hen met u verbindt noemt u dan een secure interface. Met uw LAN gebruikers zijn afspraken te maken. Tenminste als u een bedraad netwerk (geen WLAN) heeft. Enige controle kan overigens geen kwaad. Een fout is zo gemaakt. Onbedoeld geïnstalleerde virussen en Trojaanse paarden zijn immers ook netwerkgebruikers. Daarom blijven in opzet veilige regels, virusscanners, backups en bestandspermissies van kritiek belang. U moet uw netwerkgebruikers op uw netwerketiquette (dit mag wel, dat niet) blijven aanspreken.

Voor de interface met het internet gelden heel andere regels. Dit is een per definitie onveilige interface. In de regel wilt u over de publieke bronnen van het World Wide Web beschikken, maar niet toestaan dat een iemand vanaf het internet bij uw bronnen komt. Met anonieme klanten kunt u geen afspraken maken. Uw wachtwoorden zijn te kraken. En als u niet uitkijkt gaat een Trojaans paard zijn gang. Op deze onveilige interface zijn dus keiharde maatregelen te nemen.

Bij de bepaling van veilige en onveilige interfaces speelt de structuur van uw netwerk een essentiële rol.

Op een bedrijfsnetwerk (WAN) zullen weer tussenvormen van beveiliging bestaan. Hier moeten ook de interne servers worden beschermd. Zo mag een medewerker geen "I Love You" mail naar de computer met uw core business sturen. Hier kan een netwerk besturingssysteem u helpen. Als u het veilig configureert.

Een draadloos netwerk vormt een verhaal apart. De veiligheid van de veilige interface hangt daar erg af van de gekozen wachtwoorden en encryptie. Maar als die encryptiemethode relatief onveilig is (geen WPA, maar WEP) of uitstaat moet u sterk overwegen uw servers op een ander netwerksegement te zetten dan uw basisstation.

U moet dus inzicht in de opbouw (topologie) van uw netwerk hebben. Maakt u hier beoordelingsfouten, dan brengt u de sloten op de verkeerde deuren aan. Ik geef enige praktische voorbeelden om u op weg te helpen.

Het netwerk onderzoeken: netstat

> Top <

De snelste manier om inzicht in uw netwerk te krijgen is het gebruik van het utility netstat. Netstat geeft informatie over het gebruik van de sockets van de TCP/IP stack.

Het begrip socket (contactdoos) komt uit programmeertaal (API) van de BSD TCP/IP stack (zie: EDM/2 - Plugging into OS/2 Socket Programming). Een socket is een interface naar de TCP/IP stack. Programma's kunnen drie soorten sockets aanroepen: STREAM (TCP), Datagram (UDP) en RAW sockets (ping, ICMP). Afhankelijk van het type socket zal het programma zich anders op het netwerk gedragen.

U kunt zo'n contactdoos voorstellen als een combinatie van een poort en IP adres. Programma's steken er als het ware hun stekkers in. Een actieve TCP/IP verbinding gebruikt twee sockets. Een aan de server en een aan de client kant. Zie het schema hieronder.

Het IP adres is aan een netwerkinterface (localhost, netwerkkaart, modem) verbonden. De poort wordt door het programma uitgekozen (de bekende poorten van servers) of op aanvraag van het programma dynamisch toegewezen. Iedere netwerkaart heeft in principe de beschikking over 65535 poorten. Dat zou een enorme wandcontactdoos per interface opleveren. Maar het aantal programma's is natuurlijk beperkt.

De netwerklaag van de TCP/IP stack zorgt ervoor dat de juiste netwerkkaarten met elkaar communiceren. En dat een programma op een dynamische of privé poort (49152 - 65535) de server op een geprivilegieerde poort vindt.

Een simpel batchbestand waarmee u op ieder moment de actieve verbindingen met netstat kunt controleren is handig:

@echo off
netstat -s > %temp%\netstat.txt
netstat -r >> %temp%\netstat.txt
e %temp%\netstat.txt

Met netstat -r(oute) of netstat - i(interfaces) kunt actieve interfaces achterhalen. Doe dit onder verschillende omstandigheden. Maak in ieder geval ook uw lokale netwerk actief. Door een dynamisch host configuratie protocol (DHCP) kunnen uw IP adressen veranderen. Ook een dial-up verbinding zal de in het TCP/IP configuratieblok opgegeven standaard route veranderen.

Netstat -r toont ook de routing tabel. Het toont de gebruikte IP adressen (destination), de weg daarnaar toe (router) en de gebruikte interface (intrf). Omdat de routing tabel een cache is geeft hij niet alleen de nu actieve verbindingen weer, maar ook adressen die u eerder bezocht hebt. Tijdens een internetsessie wordt hij dus langer.

Netstat -s(ocket) geeft de sockets van de TCP/IP stack weer. Deze is het meest bruikbaar.

Een open en/of actieve TCP verbinding krijgt in netstat status het label ESTABLISH(ed). Nu zult u de status ESTABLISH(ed) van HTTP verbindingen op poort 80 zelden zien: Want zodra het opgevraagde bestand binnen is zal de HTTP server de verbinding sluiten. Hierdoor hoeft de webserver minder sockets open te houden. De status ESTABLISH komt op mijn proxyservers op 8080 (squid, oops!) en 8118 (privoxy) veel vaker voor.

SOCK  TYPE FOREIGN  LOCAL   FOREIGN       STATE
           PORT     PORT     HOST
9   STREAM  0       8080   0.0.0.0      LISTEN    
515 STREAM  8118    64762  192.168.1.5  ESTABLISH 
516 STREAM  8080    64763  192.168.1.5  ESTABLISH 

Verbindingen als Secure Shell, Secure HTTP en Netbios via TCP/IP zullen daarentegen pas na te lange time-outs worden afgebroken. De Secure Shell en Secure HTTP protocollen hebben geen belang bij een voortijdige verbreking van de verbinding omdat de berichtgeving versleuteld verloopt. En ze niet voortdurend wachtwoorden willen verwisselen.

Hier luistert (LISTEN) de OS/2 NetBIOS via TCP/IP server naar alle (0.0.0.0) SYNchronisatieverzoeken, en is er een client verbinding met de samba server op 192.168.1.2:139 tot stand gebracht (ESTABLISH). TCP poort 2686 wordt door Norman Antivirus gebruikt. Oops gebruikt de poorten 8080 TCP en 3130 (UDP verbinding met squid) en Privoxy poort 8118.

                              AF_INET Address Family:
                              Total Number of sockets 19

  SOCK   TYPE       FOREIGN          LOCAL         FOREIGN         STATE
                     PORT             PORT            HOST
======  =====      ==========      ==========      ==========    ========
     1  DGRAM               0 netbios-dgm..138        0.0.0.0  UDP
     2  DGRAM               0 netbios-ns..137         0.0.0.0  UDP
     3 STREAM               0 netbios-ssn..139        0.0.0.0  LISTEN    
     4  DGRAM               0 emfis-data..140         0.0.0.0  UDP
     5 STREAM               0            2868         0.0.0.0  LISTEN    
     6 STREAM               0               0         0.0.0.0  CLOSED    
     7 STREAM               0            8118         0.0.0.0  LISTEN    
     9 STREAM               0            8080         0.0.0.0  LISTEN    
    10  DGRAM               0            3130         0.0.0.0  UDP
    12 STREAM               0               0         0.0.0.0  CLOSED    
    55  DGRAM               0           49175         0.0.0.0  UDP
    66  DGRAM               0           49232         0.0.0.0  UDP
    67  DGRAM               0               0         0.0.0.0  UDP
   925 STREAM           63588           63589       127.0.0.1  ESTABLISH 
   926 STREAM           63589           63588       127.0.0.1  ESTABLISH 
  5578  DGRAM               0           52770         0.0.0.0  UDP
  5582  DGRAM               0               0         0.0.0.0  UDP
  1952 STREAM netbios-ssn..139           64168    192.168.1.2  ESTABLISH 
  2060  DGRAM               0     syslog..514         0.0.0.0  UDP
--------------------------------------------------------------------------
                              AF_OS2 Address Family:
                              Total Number of sockets 1

Type: STREAM   State:    ---          
Local Name:    \socket\oopsctl          
Foreign Name:       

Een uitleg over de STATE (status) van de sockets staat in: Met netstat -s de TCP status opvragen .

Een dial-up verbinding met DOIP

> Top <

De OS/2 PC belt via DOIP in. De uitvoer van netstat -r staat hieronder aangegeven.

[H:\]netstat -r 
destination router netmask metric flags intrf 
A default 194.159.73.222 0.0.0.0 0 UGP ppp0 
B 127.0.0.1 127.0.0.1 255.255.255.255 0 UH lo 
C 139.130.51.36 194.159.73.222 255.255.255.255 0 UGHW ppp0 
D 192.168.1 192.168.1.5 255.255.255.0 0 UC lan0 
E 195.173.244 195.173.244.121 255.255.255.0 0 UP ppp0 
F 195.173.244.121 127.0.0.1 255.255.255.255 0 UH lo 

Interpretatie: De ISP geeft de OS/2 PC via het modem (ppp0) het IP adres 194.159.73.121 (F) en wijst 194.159.73.222 als de default route toe (A). Verbinding (C) koos deze weg. Via een hub is de OS/2 PC als 192.168.1.5 met de rest van het 192.168.1 LAN verbonden (D). De OS/2 PC fungeert echter niet als router (ipgate off). Hij draait een proxy server. Op de rest van het LAN is daarom geen default route opgegeven. Het lokale etc\hosts bestand voldoet als DNS. In de applicaties op 192.168.1.n geeft u 192.168.1.5 als proxy server op.

In schema gebracht:

De verbinding met het internet verloopt via de door DOIP gecreëerde ppp0 interface. Uw kant van de ppp0 interface zal een op het internet geldig IP adres hebben ( hier 194.159.73.221). De waarde doet er eigenlijk niet toe. U hoeft alleen maar de veilige interfaces te weten. Dat zijn de IP adressen van lan0 (192.168.1.1) en lo (127.0.0.1).

127.0.0.1 
192.168.1.1 

Alleen die waarden vult u %ETC%\fwsecad.cnf in.

NB. Het IP filter dient hier vooral ter bescherming van de servers op de OS/2 PC. Dat kunnen ook servers voor lokaal gebruik zijn (XFree86/OS2, proxies). De rest van het LAN kan via de proxy veilig internetten.

Een kabelmodem

> Top <

Een veel voorkomende situatie is deze. Een OS/2 PC met twee netwerkkaarten lan0 en lan1 verbindt het LAN met een ethernet kabelmodem. Cable Modems and OS/2 geeft een dergelijk opzet met Internet Gate als Firewall/proxy. OS/2 is geen router (ipgate off).

Wilt u dit zelf opzetten (zonder Internet Gate - Proxy/Firewall/Internet Sharing) dan zijn met de veilige interfaces van de OS/2 PC localhost en lan1 met IP adres 192.168.1.1 (de default route van het LAN):

127.0.0.1 
192.168.1.1 

In deze situatie zijn alle interfaces met 192.168.1.m adressen veilig. De onveilige interface lan0 geeft de OS/2 computer het IP adres van de provider (207.175.252.40). Vandaar dat een IP filter nodig is.

Let op: Het begrip veilige interface heeft op zich niets te maken met de gebruikte protocollen (NetBIOS versus NetBIOS via TCP/IP). Op NetBIOS en andere niet internet protocollen heeft de firewall geen grip. Bepalend is welke IP adressen de interface kan krijgen. Zit daar een op het internet geldig IP adres bij, dan is die interface (bijv. een netwerkkaart met meerdere IP adressen) voor die computer als onveilig te beschouwen. De onveilige omgeving zal meestal het internet zijn, maar in een bedrijfsnetwerk kunnen dat ook een privé netwerkadressen zijn...

Een hardwarerouter met ingebouwde switch

> Top <

Voor een multiboot PC of klein netwerk kan ik een hardwarerouter van harte aanbevelen. Zo'n router regelt de verbinding met de internet. Via een switch op de router worden de hosts met elkaar verbonden. De firewall van de router levert standaard netwerkadresvertaling op IP niveau, maar staat vaak ook andere vormen van internettoegang toe. Bijv. WAN to WAN toegang via ISDN lijnen of versleutelde "tunnels" over het internet. De LAN interface van de router is meestal de standaard route (default) van iedere host op het LAN (hier 192.168.1.1).

[H:\]netstat -r 
destination router netmask metric flags intrf 
default 192.168.1.1 0.0.0.0 1 UGSP lan0 
127.0.0.1 127.0.0.1 255.255.255.255 0 UH lo 
192.168.1 192.168.1.5 255.255.255.0 0 UC lan0 

Hier wordt een 192.168.1.0 (0 staat voor * =alles) ethernetwerk via 192.168.1.5 op de lan0 interface benaderd. Iets dat niet voor 192.168.1.* of 127.0.0.1 bestemd is, wordt naar de de router op 192.168.1.1 gezonden.

In deze luxe situatie valt natuurlijk geen firewall te testen. Er zit al een filter in de netwerkadresvertaling van de router en die is in dit werk gespecialiseerd.

Tijdens een internetsessie lopen alle verbindingen via lan0 naar de hardwarerouter.

[H:\]netstat -r 
destination router netmask metric flags intrf 
A default 192.168.1.1 0.0.0.0 1 UGSP lan0 
B 62.251.199.50 192.168.1.1 255.255.255.255 1 UGHW3 lan0 
C 127.0.0.1 127.0.0.1 255.255.255.255 0 UH lo 
D 168.215.82.33 192.168.1.1 255.255.255.255 1 UGHW3 lan0 
E 192.168.1 192.168.1.5 255.255.255.0 0 UC lan0 
F 206.65.191.129 192.168.1.1 255.255.255.255 1 UGHW lan0 
G 209.123.109.175 192.168.1.1 255.255.255.255 1 UGHW3 lan0 
H 209.123.205.210 192.168.1.1 255.255.255.255 1 UGHW lan0 

Bij mij zijn drie IP adressen van routers zichtbaar. Die "routers" zijn IP adressen van de interfaces van uw computer die u als veilig of onveilig bestempelen moet. Op een single-user systeem behoort localhost veilig te zijn. Maar bij twijfel kiest u voor onveilig.

De verbinding met de TCP/IP applicaties op mijn eigen PC verlopen via de dummy interface localhost (127.0.0.1). Localhost is geen echte interface. Maar als ik die uitschakel lopen TCP/IP applicaties als XFree86/OS2 vast. Een applicatie als StarOffice komt in de printproblemen. Aangezien ik met OS/2 niet onder Windows (met al zijn e-mailvirussen) zit, beschouw ik lo op 127.0.0.1 als een veilige interface.

De verbindingen met de UDP en TCP/IP applicaties op mijn ethernetwerk verlopen via 192.168.1.5. Dit is de OS/2 kant van mijn ethernetkaart (lan0). Maar zowel de internettoegang als de LAN toegang verlopen via dezelfde ethernetkaart! Het IP adres 192.168.1.5 is weliswaar veilig, maar de gebruikte interface lan0 nog niet!!! Dat zal alleen het geval zijn als de router een volledige netwerkadresvertaling voor deze interface biedt.

De verbinding met het internet verloopt altijd via de default route. Dat is hier het LAN IP adres 192.168.1.1 van de router die contact maakt met 192.168.1.5 op lan0.

Is 192.168.1.5 op lan0 nu een onveilige interface? Dat hangt van de configuratie van de router af. De netwerkadres vertaling van routersoftware kan de OS/2 PC zowel beschermen (maskeren) als op het internet te kijken zetten. Of met uw configuratie uw host op het internet te zien is, moet u met een externe poortscanner testen. Een goed ingestelde routerfirewall geeft op iedere poort de melding Stealth. Doe onder Windows ook regulier poortscans om te zien of u Trojaanse servers draait.

Als de default gateway op het 192.168.1 LAN een firewall is, die de internettoegang via NAT (Injoy, hardwarerouter) of een proxy server op privé internetadressen aflevert, dan is er niets aan de hand. U bent met het internet verbonden via een privé internetadres. Niemand kan de door u gebruikte computer zien. De Shields up! poortscanner van https://grc.com spreekt dan van Stealth.

Maar als de default gateway een router of computer is die geen of een aangepaste NAT setup heeft dan is het uitkijken geblazen. In het onderstaande geval krijgt de OS/2 PC (192.168.1.5) het IP adres van het Alcatel modem omdat hij zich in de gedemilitariseerde zone van de router bevindt.

De OS/2 PC zit in de gedemilitariseerde zone (DMZ) van de router, een gat in de verdediging, die ik heb aangelegd om de OS/2 firewall te testen. De OS/2 PC heeft dus het IP adres van mijn ADSL modem naast zijn LAN adres 192.168.1.5 op dezelfde interface lan0. Dit kunt u met netstat niet zien. Alleen een externe poortscanner zal het aangeven als er een server op de computer draait.

Het bestand %ETC%\fwsecad.cnf bevat de IP adressen met de veilige netwerkinterfaces. In deze DMZ opzet (de eerste rij in het schema) is dat alleen localhost. Het IP adres 192.168.1.5 van de interface lan0 moet ik er buiten houden omdat diezelfde interface lan0 ook een op het internet geldig IP adres heeft!

Bij FirewallConfig/2 stel ik de secure interfaces op het tabblad interface in.

127.0.0.1 

Een experimentele constructie met twee netwerkkaarten op dezelfde switch

> Top <

In de vorige opzet was de OS/2 PC via netwerkaart 192.168.1.5 (lan0) in de DMZ gezet, omdat hij als internetserver moest dienen. Het gevolg was dat ik superstrenge regels moest opstellen. Want ook de bediening van het LAN vond via dezelfde interface plaats. Het werkt, maar het is moeilijk waterdicht te maken. Een alles-in-een netwerkaart opzet is kwetsbaar voor DoS aanvallen. En IP spoofing is haast niet te voorkomen.

Om die reden besloot ik er een tweede netwerkaart bij te kopen en sloot ook die op de switch van de router aan. De extra kaart (lan1 op 192.168.2.55) werd in de DMZ van de router gezet en de eerste kaart (lan0 op 192.168.1.5) zou slechts voor het LAN en de netwerkadresvertaling van de router beschikbaar komen. Dit zou de filterregels vereenvoudigen. Bij de netwerkaart die als toegang tot de DMZ zou dienen, zou ik op de OS/2 firewall alles verbieden op die ene HTTP TCP/IP server na. Op de veilige LAN interface konden daarentegen open regels gelden. Deze interface werd immers door de netwerkadresvertaling van routerfirewall gedekt. Alleen op de LAN interface 192.168.1.5 (lan0) sloot ik NetBIOS via TCP/IP en de Virtual PC switch op aan. Net view \\ecs2 liet niets zien.

Het was lastig om de tweede netwerkaart zo te configureren dat hij wel de router, maar niet de eerste kaart kon zien. Ze mochten immers niet tot hetzelfde netwerk behoren. Uiteindelijk bracht een aangepast broadcastadres (192.168.255.255) uitkomst. IPGate stond uit.

Bij FirewallConfig/2 stelde ik de secure interface op het tabblad interface als volgt in.

192.168.1.5

Beide netwerkkaarten waren met netstat -n(ic) te zien, maar er ontstonden problemen met de routing. Een (virtuele) PC kan immers maar een default route hebben en de weg naar het internet (0.0.0.0 0.0.0.0.) is dus niet over twee IP adressen op te splitsen. Ik wilde dat het toegestane verkeer naar de server op de non-secure interface ook via die non-secure interface terugging, maar in de praktijk werd er slechts van de ecs.thuis (192.168.1.5) netwerkaart gebruik gemaakt. Omgekeerd kwam het ook voor dat Netscape a.h.w. aan de non-secure interface gebonden werd en dan niet over een DNS beschikte.

IP pakketjes filteren

> Top <

IP pakketjes

> Top <

Ter illustratie van een datagram een met iptrace onderschepte Netwerkheader, IP header, TCP header en enige data van een tekst die ik op de OS/2 PC tikte en via het SMB protocol naar Linux verzond. Wilt u uw netwerk op datagram niveau onderzoeken, draai dan hèèl eventjes iptrace (beëindigen met Ctrl-C), daarna ipformat datum.log en bekijk het vaak zeer omvangrijke logbestand met e. Ipformat zet het door iptrace aangemaakte iptrace.dmp dumpbestand om in leesbare tekst.

-------------------------- #:92 -------------------------- 
Delta Time: 0.000sec Packet Length: 1514 bytes (5EA hex) 
DIX: Dest: 00:00:B4:B8:1E:20 Source: 00:00:B4:A2:A2:8D 
DIX: Dest: 192.168.000.002 Source: 192.168.000.001 
----------------------- IP HEADER ----------------------- 
IP: Version: 4 Correct Header Length: 20 bytes 
IP: Type Of Service: 00 
IP: 000. .... Routine 
IP: ...0 .... Normal Delay 
IP: .... 0... Normal Throughput 
IP: .... .0.. Normal Reliability 
IP: Total Len: 1500 (x5DC) bytes Id: 1D5A 
IP: Flags: 2 
IP: .1.. Don't Fragment 
IP: ..0. Last Fragment 
IP: Fragment Offset: 000 
IP: Time To Live: 64 sec Protocol: 6 TCP 
IP: Header Checksum: 966E (Correct) 
IP: No Options 
---------------------- TCP HEADER ---------------------- 
TCP: Source Port: 54268 (Unassigned port) Dest Port: 139 (NETBIOS Session) 
TCP: Sequence #: 1972314261 
TCP: Ack #: 2921349513 
TCP: Offset: 20 bytes 
TCP: Flags: 10 
TCP: ..0. .... Urgent bit Off 
TCP: ...1 .... <ACK Ack bit On 
TCP: .... 0... Push bit Off 
TCP: .... .0.. Reset bit Off 
TCP: .... ..0. Synchronize bit Off 
TCP: .... ...0 Finish bit Off 
TCP: Window: 33580 Checksum: 8193 (Correct) 
TCP: No Options 
--------------------------------- DATA ----------------------------------- 
0000 73 74 65 65 6D 20 28 4E 46 53 29 20 76 61 6E 20 steem (NFS) van 
0010 65 43 6F 6D 53 74 61 74 69 6F 6E 2E 20 50 6F 6F eComStation. Poo 
0020 72 74 20 31 33 39 20 77 6F 72 64 74 20 67 65 61 rt 139 wordt gea 
0030 63 74 69 76 65 65 72 64 20 61 6C 73 20 75 20 4E ctiveerd als u N 

Er zijn vier componenten te onderscheiden.

(1). De netwerkheader bevat hier de bron en eindbestemming in termen die een ethernetkaart snapt: Het hardware address 0 :0 :b4:b8:1e:20 volgens de DEC-Intel-Xerox (DIX ) ethernet standaard. Iedere ethernetkaart heeft een uniek identificatienummer dat met het Address Resolution Protocol (ARP) is op te vragen.

H:\]arp zolder 
ARP table contents: 
interface hardware address IP address minutes since last use 
lan0 0 :0 :b4:b8:1e:20 192.168.0.2 10 

(2). De belangrijkste elementen van de IP Header zijn de IP adressen van de bron (Source: 192.168.000.001) en de eindbestemming (Dest: 192.168.000.002). Deze waren al via ARP naar het ethernetwerk vertaald. Wat resteert zijn de door traceroute gebruikte Time to Live (TTL), controleberekeningen en de voor routers belangrijke informatie over fragmentatie. De TTL kan gebruikt worden voor passieve OS fingerprinting: Windows 98/2000 hebben een standaard TTL van 128 seconden; Linux en OS/2 van 64 seconden.

(3). Het op de transportlaag aangemaakte TCP segment bevat belangrijke sessie-informatie:

Bron- en bestemmingspoorten: TCP: Source Port: 54268 (Unassigned port) en Dest Port: 139 kenmerken een sessie (hier: NETBIOS via TCP/IP Session).

Volgnummers zijn nodig voor het reconstrueren van de pakketjes in de juiste volgorde bij de bestemming (synchronisatie). Zodra het afgebeelde TCP segment met Sequence #: 1972314261 bij Linux aankomt (# staat voor nummer), zal Linux een bevestiging van ontvangst (ACKnowledgement, ACK) terugzenden. Het ACK # is altijd het te bevestigen Sequence # plus 1. OS/2 stuurt hier ook een ontvangstbevestiging (Ack #: 2921349513) voor een ontvangen TCP bericht van Linux. Zonder die bevestiging zal Linux het TCP pakketje # 2921349512 (Ack # minus 1) nog lange tijd blijven versturen. Tevens wordt een controleberekening (Checksum: 8193) meegeleverd.

Volgordenummers zijn dus te vergelijken met correspondentienummers in brieven. Omdat afzonderlijke pakketen geen datumstempel hebben, moet er een methode zijn om de pakketten in de goede volgorde te reconstrueren. Hiertoe worden de volgordenummers (Seq #) in ieder volgend pakket met 1 verhoogd. Volgordenummers zijn zowel voor UDP als TCP van belang. Streaming audio UDP pakketten moeten immers in de goede volgorde afgespeeld worden. Maar alleen TCP zal op een ontbrekend TCP pakketje wachten.

De aankomst van een ongeschonden TCP pakket zal door de ontvanger bevestigd moeten worden. Dit doet hij door een TCP pakket naar de afzender te retourneren met zijn eigen volgordenummer ("mijn referentie") en een ACKnowledge bit ("uw referentie"), waarin het volgordenummer van het ontvangen TCP pakket met de waarde 1 verhoogd is. Bij ontvangst van het TPC/ACK bericht, weet de server dat hij het bevestigde bericht niet opnieuw hoeft te versturen. Maar als een pakket ontbreekt (pakket 9005 wordt gevolgd door 9007 etc), zal de cliënt de server om het ontbrekende TCP pakket blijven verzoeken.

Deze controle van de overdracht is kenmerkend voor het verbindingsgeoriënteerde TCP protocol. De "administratieve handelingen" zorgen voor een aanzienlijke netwerkoverhead (50%). Bij telnet krijgt iedere toetsaanslag al een 40 bytes TCP/IP header. Dergelijke tinygrams kunnen het WAN verstoppen. Voor de filterregels is van belang dat er niet alleen verkeer gaat van de bron- naar de bestemmingspoort, maar ook terug (TCP/ACK). Dat levert per applicatieprotocol (HTTP, NetBIOS) minimaal twee filterregels op.

Het verbindingsloze (connectionless) User Datagram Protocol (UDP) laat die controle aan de applicaties over. Het is meer de manier van werken van cassettebandjes (of mp3), dan van de digitale CD. Programma's bepalen of ze grof (audio) of nauwkeurig (tape backup, cd-speler) willen werken. Tape backup programma's bereiken hun nauwkeurigheid dan ook met een merkbare overhead (hoge cpu-use). Ook het Network File System voert zijn eigen controleberekeningen en ACK's uit. Andere programma's zeggen "laat maar zitten": bij streaming audio hoor je liever geen door ongelukkig routering te laat aangekomen bits en ook een pixel meer of minder video maakt niet uit.

De UDP Header bevat alleen maar de bron- en bestemmingspoorten, de segmentlengte en een checksum voor de ontvanger. Een UDP/IP packet filter kan dus maar weinig controleren!

(4) Ten slotte bevat het pakketje de te verzenden data in het datasegment. U ziet dat de getransporteerde datagegevens bij een NetBIOS via TCP/IP sessie gewoon te lezen zijn. Iemand die ze langs de route met netwerksniffer (hier iptrace) onderschept kan ze gewoon lezen. Om dat te voorkomen wordt het netwerkverkeer steeds vaker versleuteld.

Het firewall filter

> Top <

Waar de XP firewall u slechts de keus geeft om een poort voor alles wagenwijd open te zetten of te sluiten, staat de OS/2 firewall filteren op maat toe. De XP firewall zet op eigen houtje bepaalde poorten open. Maar onder OS/2 TCP/IP 4.3 bepaalt u welk IP adres toegang krijgt en welke IP adressen worden geweigerd. De firewall is zo in te stellen, dat ieder pakketje dat maar even afwijkt van de door u gestelde norm (herkomst, bestemming, gefragmenteerd, gespooft) kan worden geweigerd en gelogd.

Onder OS/2 hoeft u dus geen enkele poort wagenwijd en onbewaakt open te laten staan. Via verfijnde filterregels kunt u precies aangeven wat wel en wat niet doorgelaten wordt. Ik ga nu op die filtercriteria in.

De firewall filter criteria

> Top <

Het packet filter (FWIP.SYS) bekijkt de TCP/IP header en filtert via goed (permit=toestaan) en kwaad (deny-weiger) regels op de volgende kenmerken:

IP protocol (zender en ontvanger)

• Het IP adres en netmasker van de bron (zender)

• De IP adres en netmasker van de bestemming (ontvanger)

IP adressen en netmaskers worden als volgt geduid (decimale notering).

Een IP adres 0.0.0.0 met netmasker 0.0.0.0 zal op alle IP adressen van alle netwerken slaan. Met zo'n ruim begrip valt natuurlijk niet te werken. De clou is dat u "alle IP adressen" met globale instellingen in grove categorieën als secure/non-secure, uitgaand, inkomend en verder kunt onderverdelen. Vooral TCP/IP netwerkverkeer kunt u op die manier fijn regelen.

De gebruikte protocollen

• Alle protocollen

• ICMP protocollen (ping)

• UDP protocol (DNS, NFS, SNMP, multimedia)

• TCP protocol (de meeste toepassingen)

• TCP/ACK protocol (acknowledge: "hallo hier ben ik")

• IBM IPSP protocol (IP security protocol, een IBM specifiek tunnel protocol nodig voor de Secured Network Gateway nodig voor Virtual Private Netweken)

Volgens Timur Kazimirov kan de firewall niet alleen TCP, TCP/ACK, UDP, en ICMP pakketjes, maar ook OSPF, IPIP, ESP en AH pakketjes filteren.

De poort van de bron (zender, source operation)

Hier hebt u verschillende opties: alle poortnummers (any), is gelijk aan (equals), is niet gelijk aan (not equal to), groter dan (greater then), kleiner dan (less then), groter of gelijk aan (greater or equals), kleiner of gelijk aan (less or equals) een bepaald poortnummer.

De poort van de bestemming (ontvanger, destination operation)

Hier geldt hetzelfde.

Om het configureren te vergemakkelijken bestaan er globale instellingen, waarvan de onderverdeling in veilige en onveilige netwerkinterfaces wel de belangrijkste is. Bepaalde delen van het netwerk mogen deels open staan en andere delen moeten streng worden bewaakt. Ik ga hier in Netwerkinterfaces: veilig of onveilig gedetailleerder op in.

• Secure (een lan adapter waar weinig gevaar van te duchten valt)

• Non-secure (ppp verbinding met het internet, uw neefje)

• Both (beide, vooral van belang voor deny regels)

De IP adressen van secure interfaces (bijv. 192.168.1.2 ) worden onder elkaar in het bestand %ETC%\fwsecad.cnf vastgelegd. Wat hier buiten valt geldt als non-secure. Dus ook het onbekend IP adres van een dynamisch dial-up verbinding.

Een andere globale instelling is de vraag of het om lokaal verkeer (van en/of naar de OS/2 firewall PC), of gerouterd netwerkverkeer (ipgate on) gaat.

• Local (van en/of naar de OS/2 firewall PC)

• Route (via de firewall naar een andere computer)

• Both (beide)

Advies: Probeer als het even kan met proxies de netwerktoegang lokaal (op, van en naar de firewall) te regelen. Vermijd both en route (routing), tenzij u de OS/2 PC met "ipgate on" als router met twee of meer netwerkadapters (modem, lan) inzet.

De richting (direction) van het IP verkeer over de netwerkadapter:

• Inbound (naar de interface op uw PC toe)

• Outbound (van interface op uw PC af)

• Both (beide kanten uit)

In beeld gebracht: het donkergrijze gebied is de OS/2 computer met zijn adapters. De firewall bewaakt het IP verkeer op de veilige en onveilige adapters lan0 en lan1. Inbound local verkeer op lan0 gaat van het internet naar de computer met de firewall toe. Gerouterd verkeer gaat via de OS/2 firewall PC naar een tweede adapter toe (lan0 <=> lan1).

Hier draait het LAN op privé adressen. De internettoegang kan via de netwerkadresvertaling van een proxy op de firewall PC tot stand komen. Dit gebeurt op de applicatielaag. Van routing van pakketjes op de IP laag is normaal geen sprake. Zet hier de routing dus uit, sta alleen lokaal verkeer toe en plaats regels tegen IP spoofing om de firewal te beschermen. Dan is het een veilige constructie.

VPN (Virtual Private Network): of uw al dan niet een Virtual Private Network via de firewall toe wilt staan. Het is in de praktijk alleen bruikbaar voor ADSL en kabelmodembezitters met vaste IP adressen en er kleven nogal wat beperkingen aan. Alexander Taylor heeft het in zijn firewall_doc_v11.zip in beeld gebracht. De invoer bestaat uit het tunnel-ID (0 betekent maak geen gebruik van VPN).

Of de transacties vastgelegd moeten worden (logging).

• Yes (standaard voor verboden acties)

• No (standaard voor toegestane acties)

Hoe er met fragmentatie omgegaan wordt:

• Yes (headers, fragmenten en ongefragmenteerde pakketen doorlaten of verbieden)

• No (alleen ongefragmenteerde pakketen doorlaten of verbieden)

• Only (alleen losse headers en fragmenten doorlaten of verbieden)

In de regel moet u geen gefragmenteerde pakketten op uw netwerk toelaten. Bij PERMIT regels zet ik fragmentatie daarom op NO (alleen ongefragmenteerde pakketten doorlaten), en bij DENY gebruik ik YES (alles verbieden) of ONLY (alleen gefragmenteerde pakketten verbieden). Voor meer info zie: Fragmentatie.

CFGFILT Opties

> Top <

Blokkeert uw IP filter ondanks PERMIT regels alle pakketten, dan is cfgfilt -f de beste optie: vrijwel zeker start de firewall door een vormfout met strenge alles verbiedende standaardregels op!

Regels opstellen

> Top <

Iedere firewall valt of staat bij zijn configuratie. De configuratiebestanden kunt u met een REXX script aanmaken: http://www.tavi.co.uk/os2pages/firewall/firestarter.cmd. Maar het configureren moet u zelf doen. Hierbij kunt u gebruik maken van het freeware programma FirewallConfig/2 (http://michelinakis.gr/Dimitris/sc/index.html). Het brengt de complexe permit en deny filterregels van het tekstbestand \MPTN\ETC\security\fwfiltrs.cnf aanschouwelijk in zicht.

Om de firewall optimaal in te stellen moet u te weten komen hoe uw netwerk in elkaar steekt. U moet weten wat de interfaces zijn en welke netwerkprotocollen er lopen. Hulpmiddelen als netstat en vooral batches m.b.t. het firewall logsysteem (tail) zullen hierbij helpen.

Ga steeds systematisch te werk. Pas de firewallregels in kleine stappen aan. Het steeds weer testen (poortscanners) en vastleggen van wat u via denkwerk, trial and error al aan filterregels is essentieel. Houdt de URLs van poortscanners paraat. Maak ook steeds backups van de filterregels en bijbehorende logbestanden waarin u ook vastlegt wat u in de praktijk ziet of mist.

Bedenk bij elke PERMIT regel dat het er niet alleen om gaat dat de door u gebruikte applicaties werken. Het gaat er om dat ze met minimale permissies werken. Gebruik uw gezonde verstand, de richtlijnen m.b.t. de protocollen en poortscanners om dat te controleren. Zodra een cliënt programma met minimale permissies werkt, hoeft u de hiervoor benodigde PERMIT regels niet meer te loggen. Misschien met uitzondering van gevaarlijke protocollen als IRC. Maar het is wel verstandig om de publieke PERMIT toegang tot uw servers en alle DENY regels te blijven loggen.

Een batch die ik gebruik om de filterregels op syntaxisfouten te controleren en ze meteen in de originele en een geformatteerde vorm op te slaan, kan hierbij van nut zijn. Voor de configuratie- en logbestanden maakte ik reflecties van de mappen %ETC% en %ETC%\security in een map firewall. Maar maak geen reflecties aan van het fwfiltrs.cnf bestand zelf, omdat die na een tijdje naar een bak bestand kan verwijzen. Die kunt u beter editen via "e %ETC%\security\fwfiltrs.cnf".

@echo off
rem Maakt backup van het filterbestand.
cfgfilt -f >%temp%\cfgfilt.txt
type %ETC%\security\fwfiltrs.cnf >> %ETC%\security\Firewaltest.log
type %temp%\cfgfilt.txt >> %ETC%\security\Firewaltest.log
start e %temp%cfgfilt.txt

Bedenk bij het opstellen van de filterregels dat het er niet alleen om gaat dat de door u gebruikte applicaties werken. Het gaat er om dat ze met minimale permissies werken. Gebruik uw gezonde verstand, de richtlijnen m.b.t. de protocollen en poortscanners om dat te controleren. Zodra een cliënt programma met minimale permissies werkt, hoeft u de hiervoor benodigde PERMIT regels niet meer te loggen. Misschien met uitzondering van de permissies voor gevaarlijke protocollen als IRC. Maar het is altijd verstandig om de publieke PERMIT toegang tot al uw servers en alle DENY regels te blijven loggen. Al was het alleen maar om te achterhalen wat al die Windows wormen (hier de W32/Deloder.A worm) op uw netwerk willen doen:

0030509 231155 ecs 32: 20; ICA1041w; 192.168.1.5;6;80.194.81.165;192.168.1.5;tcp;13058;445;local;non-secure;n;0;n;48;
20030509 232310 ecs 32: 20; ICA1041w; 192.168.1.5;6;213.105.216.215;192.168.1.5;tcp;8009;445;local;non-secure;n;0;n;64;

Een zoekactie onder Google "virus port 445" leverde mij alle informatie op. "Randon" spreads via IRC channels and local area networks and infects computers running Windows 2000 and Windows XP". Zoiets werkt uitstekend op mijn motivatie voor OS/2. Het is ook een reden waarom ik een firewall liever niet onder Windows test.

De filterregels zullen afhangen van meerdere factoren.

• de doelstelling van de computer (werkstation, router, server)

• het aantal interfaces (netwerkaarten) van de computer

• de door de applicaties gebruikte protocollen

In mijn beschrijving ga ik van uit van een OS/2 PC die allerlei internet-applicaties draait. Het doel van het filter is om crackers en virussen buiten de deur te houden en ongebruikelijke activiteiten te loggen. Maar bedenk dat een personal firewall op zich geen veilige opzet is. Een personal firewall biedt geen bescherming tegen lekkende internet-applicaties. Als u servers draait en/of een netwerk moet beveiligen dan moet u beslist een dedicated firewall en/of een hardwarerouter overwegen. Zie: Nadenken over veiligheid. Desalniettemin biedt het IPFW filter veel mogelijkheden om het internetverkeer te beheersen. Hierbij is basiskennis over het huishoudboekje van TCP verbindingen essentieel.

Zie voor meer veiliger constructies (OS/2 als screening router met twee netwerkkaarten) de Packet filtering firewall for OS/2 (TCP/IP v4.1+) van Magyar Nyelven en Firewalling met Linux van Fred Mobach. Een aardig artikel is OS/2 TCP/IP Filtering van Maarten Van Horenbeeck.

De volgorde van de filterregels

> Top <

De volgorde van de filterregels is van groot belang. De regel die het eerst van toepassing is telt.

FWIP.SYS leest de regels in %ETC%\Security\fwfiltrs.cnf van boven naar beneden.

• Als FWIP.SYS een passende PERMIT regel aantreft wordt het IP pakket geaccepteerd.

• Als FWIP.SYS een passende DENY regel aantreft wordt het IP pakket geblokkeerd.

• Als FWIP.SYS geen passende regel aantreft, wordt het pakket geblokkeerd.

De filterregel (PERMIT of DENY) die het eerst van toepassing is gaat door. Plaats uitzonderingen op de regel daarom vóór de globale hoofdregel. Dit loopt tegen de redeneertrant REGEL, tenzij SPECIFIEKE UITZONDERING in, maar het is duidelijk dat als het filterstuurbestand de regels van boven naar beneden leest, hij niet meer aan uw uitzondering zal toekomen.

Met de volgende regels al wordt uw lokale netwerk onbereikbaar:

DENY Alle verkeer (0.0.0.0 0.0.0.0 <-> 0.0.0.0 0.0.0.0) 
PERMIT Lokaal verkeer (192.168.1.0 255.255.255.0 <-> 192.168.1.0 255.255.255.0) 

De goede volgorde van deze pseudocode is:

PERMIT Lokaal verkeer (192.168.1.0 255.255.255.0 <-> 192.168.1.0 255.255.255.0) 
DENY Alle (overige) verkeer (0.0.0.0 0.0.0.0 <-> 0.0.0.0 0.0.0.0)  

In de praktijk zet u de specifieke regels vooraan en de meer globale regels achteraan, tenzij die globale regel EXACT is wat u wilt toestaan of verbieden. Bijv. een regel die alle fragmentatie verbiedt.

deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 both both both l=yes f=only t=0

Puur ongewenste zaken kunt u het best meteen EXPLICIET verbieden. Dit omdat de door u opgestelde PERMIT regels mogelijk toch meer toestaan dan u beoogt.

Wat niet expliciet is toegestaan is impliciet verboden. De laatste regel is de keiharde DENY van het filter zelf. Aan mijn 30 regels fwfiltrs.cnf, voegt het filter zijn eigen ongeschreven regel 31 toe (output van cfgfilt | more):

Rule 31: 
 Rule action : deny 
 Source Address : 0.0.0.0 
 Source Mask : 0.0.0.0 
 Destination Address : 0.0.0.0 
 Destination Mask : 0.0.0.0 
 Protocol : all 
 Source Port/ICMP/OSPF Type :any 0 
 Destination Port/ICMP Code :any 0 
 Interface : both 
 Routing : both 
 Direction : both 
 Logging control :yes 
 Fragment control :yes 
 Tunnel ID number : 0 
 Authenticate algorithm : none 
 Encryption algorithm : none 

Regel 31:
 Regelactie         : weigeren
 Bronadres         : 0.0.0.0
 Bronmasker         : 0.0.0.0
 Bestemmingsadres      : 0.0.0.0
 Bestemmingsmasker     : 0.0.0.0
 Protocol          : all  
 Bron-poort/-ICMP/-OSPF type:any 0
 Bestemmings-poort/ICMP-code:any 0
 Interface         : beide
 Routebepaling       : beide
 Richting          : beide
 Logboekbesturing      :ja
 Fragmentbesturing     :ja
 ID-nummer tunnel      : 0
 Verificeer algoritme    : geen
 Codeeralgoritme     : geen

Bedenk dus dat met een leeg filterconfiguratiebestand alles verboden is. Het plots opstarten van een nog niet geconfigureerde firewall zal al uw IP verbindingen blokkeren. Wees dus voorbereid op trammelant. Ook bij configuratiefouten zie je vastlopende TC/IP applicaties. Voordat u het filter met cfgfilt - u(pdate) laadt, kunt u het met cfgfilt -f(ormat) op syntaxisfouten testen.

[H:\]cfgfilt -f | more 
ICA1869e: Invalid protocol specification (allany) on line 30. 

Hier bevat regel 30 een syntaxisfout (ontbrekende spatie tussen all en any. Bij een syntaxisfout zal alleen de ongeschreven DENY ALL regel gelden. Het netwerk wordt onbereikbaar en Netscape zal vastlopen op de DNS. Ik gebruik Watchcat om hangende applicaties af te sluiten. Een goede cfgfilt -f output laat alle regels zien. Gebruik more of less of maak een batchbestandje met E.exe aan.

Wees er ook op bedacht dat u soms regeltjes invoert, maar vergeet op te slaan. Of dat de regels niet ingevoerd en opgeslagen worden zoals u oorspronkelijk bedoelde. Bijv. in een andere volgorde. Controleer de code dus regelmatig en maak backups van %ETC%\Security\fwfiltrs.cnf.

De 3-staps handdruk

> Top <

Een IP filter is het effectiefst als zo vroeg mogelijk kan ingrijpen: het liefst al voordat de TCP/IP stack een verbinding naar uw internet programma's opbouwt. Op die manier blijven uw servers buiten schot. Hoe komt zo'n TCP/IP verbinding tot stand? En zijn in dit stadium al mogelijkheden om in te grijpen? Het antwoord is ja, maar om hier filterregels voor op te stellen moet u iets van de TCP vlaggen SYN en ACK weten.

Tijdens het opzetten van een TCP/IP verbinding voeren de TCP/IP stacks van cliënt en server een 3-way handshake uit die in RFC 793 is vastgelegd. Het is een procedure om de initiële volgordenummers (Initial Sequeunce Numbers, ISN) uit te wisselen die cliënt en server voor hun huishoudboekjes zullen gebruiken. Pas zodra de client en de server elkaars TCP volgnummers kennen is controle over de transmissie mogelijk en kan de communicatie op toepassingsnivo beginnen.

Een nieuwe verbinding komt met (minimaal) drie TCP pakketen tot stand.

1). De cliënt stuurt op gezette tijden SYN(chronisatie)verzoeken naar de server totdat deze reageert (1b). Dit TCP- segment bevat het initiële volgnummer (initial sequence #, ISN) dat de cliënt voor de administratie van de verbinding wil gebruiken.

2). De server bevestigt de cliënt de ontvangst van zijn SYNchronisatie verzoek door hem een TCP pakket met bevestigingingsnummer (ACKnowledge #) van ISN+1 terug te sturen. De verbinding is nu half open. In datzelfde TCP pakket stuurt de server zijn eigen initiële volgnummer (SYN) op.

3). De cliënt bevestigt de ontvangst het SYN bericht van de server met een ACK(nowledge) segment (ISNserver+1). Nu zowel de client als de server elkaars TCP volgnummers kennen èn bevestigd hebben kan gecontroleerde communicatie beginnen. De TCP verbinding is nu volledig geopend.

Tabel: Opbouw van een TCP verbinding

Let op: Slechts het initiële TCP verkeer van de client die het SYNchronisatie verzoek doet, bevat geen ACK vlag. Al het overige TCP verkeer bevat een ACK vlag dat naar een voorgaand bericht van de andere partij verwijst. Door gebruik te maken van elkaars volgordenummers weten client en server de gegevens niet alleen in de juiste volgorde te herstellen, maar geven ze elkaar ook feedback over de ontvangst.

Met deze kennis kunt uw voordeel doen bij het opstellen van filterregels. Door alleen binnenkomende TCP/ACK berichten toe te laten, voorkomt u dat een client van buiten op eigen initiatief contact met uw TCP poorten legt. En dat is wat u doorgaans wilt.

Als u de 192.168.1.5 client TCP verbindingen met externe < 1024 poorten wilt toestaan, maar nooit ongevraagde (= zonder ACK) synchronisatieverzoeken van buiten met uw eigen poorten (hier > 49151) wilt toestaan, kunt u in theorie de regels van de drieweg handdruk als volgt opstellen:

permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/syn gt 49151 lt 1024 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack lt 1024 gt 49151 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack gt 49151 lt 1024 non-secure local outbound l=no f=no t=0

Omdat de voorgestelde permit tcp/syn syntactisch ongeldig is, moet u bovenstaande drie regels door deze twee vervangen.

permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 lt 1024 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack lt 1024 gt 49151 non-secure local inbound l=no f=no t=0

Het protocoltype "tcp" zonder vlagaanduiding slaat op al het TCP verkeer. Bij de aanduiding tcp/ack wordt op de aanwezigheid van de ACK vlag gecontroleerd. Tcp/ack komt overeen met de ! -y syntaxis van ipchains.

De eerste regel staat ieder uitgaand TCP verkeer vanaf een ongepriviligeerde "client" poort naar serverpoorten kleiner dan 1024 toe, maar de tweede regel staat allèèn binnenkomend TCP verkeer met de ACK vlag toe. Oftewel: Er komt alleen TCP verkeer naar binnen dat het door uw client gegenereerde TCP verkeer bevestigd. Hiermee houdt u het initiatief. Iemand van buiten kan geen eerste synchronisatieverzoek met uw poorten doen (dan zou er tcp moeten staan). En als iemand u ongevraagd met TCP ACK+SYN pakketjes bestookt (dat kan wel, stap 2), dan moet hij wel eerst de volgordenummers van de nog openstaande sockets raden voordat uw TCP/IP stack hem verder helpt.

Het afsluiten van TCP verbindingen

> Top <

Het afsluiten van een TCP verbinding gaat in 4 stappen. Al deze berichten bevatten een ACK vlag. Hiermee kan de TCP/IP stack van de server controleren dat degene die het FIN(ish) afsluitverzoek doet ook degene is met wie hij in verbinding was. Hiermee wordt voorkomen dat iemand met een gemaskeerde From header uw verbindingen zomaar kan afsluiten.

Zowel een client als een server kunnen een TCP/IP verbinding afsluiten. Hier bespreek ik een afsluiting van de client kant.

1. Als een programma of een verbinding netjes afgesloten wordt stuurt de TCP/IP stack van de client een FIN(ish) bericht naar de server. Het programma verstuurd geen data meer.

2. De TCP/IP stack server bevestigd de aankomst van het FIN verzoek, maar stack kan nog wel even doorgaan met het versturen van de eerder aangevraagde data. De verbinding is in de status half-closed. Ook al werkt een FIN verzoek als een noodrem, de trein dendert nog wel even door. De hoger gelegen applicatielaag van de server is niet meteen tot stilstand gebracht. Als de client-applicatie al uit de lucht is, moet de TCP/IP stack van de client de nog binnenkomende pakketjes opruimen (>DEVICE NULL).

3. Als de server klaar is verstuurd hij zijn "Ik ben met verzenden klaar" (FINished) bericht naar de TCP/IP stack van de client.

4. De TCP/IP stack van de client eindigt met een Final ACK en zet de client-poort in de status TIME_WAIT.

Tabel: Het afsluiten van een TCP verbinding

Na de Final ACK bevindt de client poort zich tijdelijk in een TIME_WAIT status. Na die time-out is hij weer voor uw computer weer beschikbaar en zal hij als CLOSED voor de buitenwereld verschijnen. Er hangt nu geen actieve client of server meer aan de poort, maar de poort staat wel open voor nieuwe verbindingen van uw kant. De vrijgeven poorten zijn gesloten (CLOSED) voor de buitenwereld, maar uw eigen programma's kunnen er wel gebruik van maken. Serverprogramma's kunnen van de poort gebruik maken en zullen dan bereikbaar (LISTENING) worden voor die netwerksegmenten die niet door een firewall afgeschermd zijn. Daarnaast zullen de poorten > 49151 dienst kunnen doen als TCP/IP sockets van OS/2 client programma's.

Met netstat -s de TCP status opvragen

> Top <

De hierboven beschreven stappen in het Transmision Control Protocol communicatie zijn met netstat -s (ockets) te volgen. Onderstaande tabel geeft de betekenis aan van de STATE kolom van netstats output aan. Zie ook Het netwerk onderzoeken: netstat .

Let op: UDP verbindingen zijn "statusloos". Netstat geeft hun "status" daarom alleen met het woordje "UDP" aan.

Welke poortnummers blokkeren?

> Top <

Publieke servers maken gebruik van de poorten 1 t/m 1023 om TCP SYN berichten te ontvangen. Dit zijn de bekende poorten uit de %etc%\services waar cliënten hun diensten zoeken. Om misbruik te voorkomen (telnet wachtwoord kapen, sessies omleiden) kon alleen de UNIX root ze voor serveerdiensten gebruiken. Daarom spreekt men van geprivilegieerde poorten.

Inmiddels zijn ook veel hogere poortnummers in het 1024 t/m 49151 bereik bij het Internet Assigned Numbers Authority (IANA) geregistreerd (http://www.iana.org/assignments/port-numbers).

Recente OS/2 cliënten gebruiken dynamische of privé poorten 49152-65535 om hun verbindingen op te bouwen. Windows, Linux en oude OS/2 clients bieden hun clients al dynamische poorten > 1023 aan. Een proxypoort als 8080 zou dan door een client bezet kunnen zijn.

Inmiddels zijn er zoveel geregistreerde en ongeregistreerde diensten bijgekomen, dat de hoogte van het poortnummer niet zoveel meer zegt. Spelletjes (Quake) en proxies (Squid, Junkbuster) gebruiken hoge poortnummers als 8080 en 8118 en netwerktools als de nmap poortscanner kunnen op lagere poorten ACK berichten ontvangen. Iedereen kan zijn TCP/IP poorten instellen zoals hij wil.

De OS/2 firwall zal standaard alle poorten te blokkeren; poorten die u wilt gebruiken moet u expliciet opgeven (de deny all strategie). Met netstat -s(ocket) of netstat -l(isten) kunt u achterhalen achter welke poorten lokale TCP servers draaien. Ook het logsysteem zal u aanwijzingen geven.

Voorbeelden

TCP/IP servers voor de buitenwereld verborgen houden

> Top <

Alle TCP verbindingen beginnen met een 3-staps handdruk. De eerste stap is het SYN-chronisatieverzoek. Het hierop volgende TCP verkeer moet een ACK vlag ("uw referentie") bevatten. Alleen het eerste SYN verbindingsverzoek heeft dat niet. Die heeft alleen uw eigen referentie.

Daarom is op iedere interface waar u toegang tot het internet wilt toestaan de volgende PERMIT strategie acceptabel.

# TCP client verbindingen (not active FTP!)
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 lt 1024 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack lt 1024 gt 49151 non-secure local inbound l=no f=no t=0

OS/2 clients kunnen hierbij alle serverpoorten < 1024 benaderen. De eerste regel staat uitgaande SYN verzoeken naar iedereen (0.0.0.0 0.0.0.0) toe. Dus zowel naar het internet als naar het LAN. De tweede regel staat het antwoord van de server toe. Dit antwoord moet de ACK vlag bevatten. Anders is het geen antwoord op een verzoek van de OS/2 client. Maar de omgekeerde weg - een client die uw server probeert te benaderen- is uitgesloten. Want de tweede regel staat geen synchronisatieverzoek doen.

Als u ook wel eens een poort als 8080 op het LAN of internet benadert, dan kunt u hiervoor een aparte regelset opstellen.

# http-alt      8080/tcp    HTTP Alternate (see port 80) Squid/oops! client
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 8080 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack lt 8080 gt 49151 non-secure local inbound l=no f=no t=0

Dat is veiliger dan alle verbindingen naar poorten < 8081 toestaan. Het best is natuurlijk een regel aan te maken voor ieder gebruikte protocol. Denk hierbij ook aan de de DNS en DHCP die via UDP gaan. Ze worden verderop besproken.

Het eigen netwerk beschikbaar stellen

> Top <

Standaard filtert het FWIP.SYS filtert alles. Maar dan hebt u meestal geen netwerkverbindingen meer. Alleen het buiten IP om werkende NetBIOS netwerk blijft het doen. Het NetBIOS is een prima protocol voor kleine Windows en OS/2 werkgroepen. Binnen een NetBIOS werkgroep kunt u probleemloos bestanden en printers delen. Zolang u deze bronnen maar niet via IP software als Limewire te kijk zet, blijven ze voor het internet verborgen.

Het grote gevaar komt steeds van software die ook in verbinding met de router naar het internet kan staan. Software, dus die toegang heeft tot uw onveilige interface. De software waarvan netstat zegt dat ze op poort x, y of z naar iedereen (0.0.0.0) luistert (LISTEN, UDP) en/of er al mee verbonden is (ESTABLISH, UDP).

LOCAL    FOREIGN      STATE
PORT     HOST
x        0.0.0.0      LISTEN
y        0.0.0.0      UDP
z        192.168.1.2  ESTABLISH

Om het uzelf niet moeilijk te maken zult u het IP verkeer op uw LAN interface (lan0) zoveel mogelijk vrij willen laten. Voor de internetverbindingen via het IP adres van uw provider (ppp0) stelt u strenge regels op. Het is verhaal van de binnendeuren en buitendeuren dat al eerder aan bod kwam.

In de situatie met twee netwerkinterfaces - bijvoorbeeld een netwerkkaart voor het LAN en een dial-up verbinding naar het internet - is dit het gemakkelijkst te implementeren. De netwerkaart naar het LAN noemt u de veilige interface en de inbelverbinding (waarvan u het IP adres niets eens hoeft te kennen) wordt dan de onveilige interface. Voor beide interfaces (toegangswegen/gatewaus naar het WAN of LAN) stelt u andere regels op.

Het instellen van een veilige interface kan alleen als u het LAN IP adres kent. Want dit IP adres moet u in in het configuratiebestand %etc%\fwsecad.cnf opgeven. Als het even kan geeft u iedere server en zeker een inbellende PC een vast IP adres. Zodat u precies op uw LAN gesneden regels kunt maken.

Hierbij maakt u gebruik van de voor het LAN en WAN bestemde privé internetadressen (Address Allocation for Private Internets). Berichten bestemd vòòr deze adressen zullen nooit op het internet terecht komen. Het gebruik van andere adressen is eigenlijk uit den boze.

10.*.*.* (1 klasse A netwerk) 
172.16.*.* tot en met 172.31.*.* (16 klasse B netwerken) 
192.168.0.* tot en met 192.168.255.* (255 klasse C netwerken) 

Deze regels zullen op een 24 bits 192.168.1.0 netwerk in veel gevallen volstaan.

# Alle verkeer van en naar localhost 
permit 127.0.0.1 255.0.0.0 127.0.0.1 255.0.0.0 all any 0 any 0 secure local both l=no f=no t=0
# LAN adressen (unsafe on WLAN!!!!!)
permit 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0 all any 0 any 0 secure local both l=no f=no t=0

Persoonlijk geef ik er echter de voorkeur aan om aparte regels aan te maken voor binnenkomend en uitgaand verkeer. De volgende regels geven toegang tot de meest voorkomende TCP server protocollen (>9000) vanaf het 192.168.1.0/24 LAN. Voor ICMP en UDP protocollen maak ik liever aparte regels aan. Ze worden verderop besproken.

# Alle verkeer van en naar localhost (secure interface)
permit 127.0.0.1 255.0.0.0 127.0.0.1 255.0.0.0 all any 0 any 0 secure local both l=no f=no t=0
# Verkeer op enige netwerkkaart en dial up verbindingen
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 lt 9000 secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack lt 9000 gt 1023 secure local outbound l=no f=no t=0

In dit geval is de lan0 netwerkaart met IP adres 192.168.1.5 als een veilige interface bestempeld. Maar het is niet vanzelfsprekend dat een lan interface met een privé-adres ook een veilige interface is.

De volgende regel PERMIT ALL regel is ook op een veilige interface bloedlink:

permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 secure both both l=no f=no t=0

Of een interface veilig is beoordeelt u niet aan de hand van het IP adres, maar na een analyse uw (oorlog)situatie. Bepalend zijn de applicaties (wat u doet) en de netwerktopologie (waar u het doet) waar ik in Netwerkinterfaces: veilig of onveilig met opzet veel aandacht aan geschonken heb.

Controleer uw netwerk met:

ShieldsUP!

Online Security Check

Sygate Online Services

Opnieuw Bob Courtney

> Top <

Opnieuw moet ik de simpele regels van de legendarische Bob Courtney aanhalen ("What would Courtney say?"):

Nothing useful can be said about security except in the context of an application and an environment.

Waarom is dat zo? Ik kan hier veel argumenten voor aandragen. Ik noem er slechts een paar.

1.) Vrij verkeer binnen het eigen netwerk kan misbruikt worden bij Denial of service (DOS) aanvallen. De omgeving (TCP/IP v4) en de voor deze omgeving gemaakte applicaties laten deze misbruik toe.

Iemand kan u vanaf het internet berichten sturen die van deze IP adressen afkomstig zèggen te zijn, maar in feite van een publiek internetadres afkomen. De From: header is met opzet veranderd om u de indruk te geven dat het bericht van uw eigen netwerk afkomstig is (IP spoofing). Als de netwerkadresvertaling van uw router vervolgens uw publieke adres in een privé adres vertaalt hebt u een probleem. Ook al zegt de afzender localhost te zijn, hij kan uw netwerkverkeer hiermee wel degenlijk ontregelen. Regels tegen IP spoofing moeten daarom zo vroeg mogelijk, bij voorkeur in routers van de internetprovider, en in ieder geval voordat de netwerkadresvertaling plaatsvindt, worden uitgevoerd.

2.) Als u slechts over èèn interface beschikt, dan komt zowel het LAN als het WAN of internet IP verkeer via deze interface aan. Dit is de situatie van de typische breedbandgebruiker die in Een hardwarerouter met ingebouwde switch beschreven werd. U moet dan - ondanks de op zich veilige netwerkadresvertaling van uw router- de LAN interface naar uw router als onveilig beschouwen. Slechts de interface naar localhost (127.0.01) die u voor Privoxy of een X server gebruikt, komt voor het label veilig in aanmerking. Maar al verkeer dat naar uw router gaat, moet u scherp in de gaten houden. En de hierop alle From:127.0.0.0 255.0.0.0 verkeer verbieden.

De OS/2 firewall zal hier de functie krijgen van een personal firewall, die vooral het uitgaande verkeer beheerst. De client programma's die u draait kunnen veel meer informatie naar buiten lekken dan u lief is. Slecht geconfigureerde Peer-to-Peer software zet complete partities te kijk. En regelmatig draait u "hier ben ik" internetprogramma's zonder dat u het weet. Omdat een netwerkadresvertalende router slechts de inkomende verbindingsverzoeken controleert, maakt u voor uw clients (en de per abuis te kijk gezette servers- shit happens) aparte regels aan.

3.) Degenen die een Wireless LAN gebruiken moeten er rekening mee houden dat er ook andere WLAN gebruikers zijn. En deze buren komen binnen via uw LAN interface. Iedere Windows WLAN gebruiker wordt daarom een personal firewall en een virusscanner aangeraden. Weliswaar komt hier het gevaar vooral vanaf het internet (m.n. fouten in chat, HTTP en emailapplicaties), maar OS/2 WLAN gebruikers hebben met WEP of helemaal geen encryptie een fundamenteel beveiligingsprobleem. Op het WLAN is een privé IP adres nooit een garantie voor bescherming. Als u veilig wilt zijn kunt u eigenlijk alleen als client in het netwerk optreden. Zie ook: Een minimale firewal voor een hotspot via DHCP.

4) Een veilige interface kan door een router te kijk gezet worden. Om de firewall te kunnen testen heb ik in mijn router het lan IP adres van de OS/2 PC (192.168.1.5) tot DeMilitarized Zone (DMZ) gemaakt. Zodra dit IP adres bij de router in beeld komt, zal de router alle servers die onder OS/2 draaien genadeloos op zijn publieke internetadres zetten. Ik moest wel, want anders test een externe poortscan slechts de netwerkadresvertaling en filterfuncties van de router. Maar niet de firewall functies van de OS/2 PC. Daarom zette ik de beschermende werking van de netwerkadresvertaling van de router uit. Maar doordat het IP adres van lan0 (192.168.123.5) onder OS/2 tevens de DMZ van de router werd, was dit geen veilige LAN interface!

Ruime PERMIT regels zijn bloedlink op een onveilige interface. En ze zijn onnodig op een veilige interface. Het IP adres zegt niet alles. Het al dan niet veilige gedrag van uw applicaties en routers spelen ook een rol. Bedenk dat een gehackte Windows PC als router kan optreden. En omdat u over uw omgeving niet altijd de gewenste controle heeft (hotspots, internet café, gehackte routers en hosts) moet u met alles rekening houden. Maak dus altijd en overal op iedere interface de PERMIT regels zo restrictief aan als u maar kunt. Sta alleen toe wat ù echt nodig hebt. En bestempel een interface pas als secure als u echt over twee netwerkinterfaces beschikt.

Het eigen netwerk beschikbaar stellen op een onveilige interface

> Top <

Op de hiervoor in punt 4.) beschreven onveilige interface die zowel voor het internet als het LAN bestemd is, leveren strenge DENY regels het probleem op, dat de OS/2 LAN servers voor het 192.168.1.0 netwerk onbereikbaar worden.

Om mijn LAN server te kunnen gebruiken moest ik dus PERMIT regels maken voor bepaalde IP adressen. De veiligste manier van werken was om voor ieder benodigd netwerkprotocol (smtp, HTTP-proxy) een PERMIT regel aan te maken voor die alleen voor bepaalde adressen op het 192.168.1.0 netwerk golden. Immers: Hoe concreter, hoe beter. Maar dat levert weer een zee van regels op, waarin je gemakkelijk het overzicht verliest.

Daarom maakte ik in eerste instantie globale regels voor het TCP verkeer binnen het 192.168.1.0 netwerk.

De eerder genoemde globale PERMIT regel om TCP verkeer met de buitenwereld toe te staan laten me ook van mijn eigen LAN diensten gebruik maken. Het netwerkadres 192.168.1.0 255.255.255.0 is immers een onderdeel van 0.0.0.0 0.0.0.0 netwerk, dat alle geldige IP adressen omvat.

# Permit active TCP client connections (not passive FTP)
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 lt 1024 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack lt 1024 gt 49151 non-secure local inbound l=no f=no t=0

Toegang tot de OS/2 TCP server poorten < 9000 is toegestaan vanaf de door OS/2 en Windows (> 1023) gebruikte client poorten. Maar dit kan alleen binnen het eigen 192.168.1.0/255.255.255.0 netwerk.

# Permit access to TCP servers from Local area network
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp lt 9000 gt 1023 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack gt 1023 lt 9000 non-secure local outbound l=no f=no t=0

NetBIOS via TCP/IP UDP verkeer kan hier niet langs te komen. Ook niet als u in voorgaande regels "all" in plaats van "tcp" had gezet. Zie ook: Netbios via TCP/IP .

Hoe specifieker de PERMIT regels, hoe beter. Zeker op een onveilige interface waar ook servers draaien. Daarom kunt u zo'n globale regel vervangen door meerdere regels die de hosts bij hun IP adres noemen. U kunt ze via knip en plak acties voor meerdere IP adressen herhalen. Deze regels vervangen de vorige regel voor host 192.168.1.2.

# Trusted host 192.168.1.2
permit 192.168.1.5 255.255.255.255 192.168.1.2 255.255.255.255 all any 0 any 0 both local both l=no f=no t=0 
permit 192.168.1.2 255.255.255.255 192.168.1.5 255.255.255.255 all any 0 any 0 both local both l=no f=no t=0 

Het voordeel hiervan is dat iemand die aan IP spoofing doet, niet alle IP adressen in uw netwerkbereik met succes kan gebruiken. Hij moet dus gokken. Zo geredeneerd kan een IP adres als 192.168.113.201 wel eens moeilijker te raden zijn dan de standaard DHCP adressen van de routers die vaak met 192.168.0.100 beginnen. Overigens hoeft een spammer uw IP adres niet meer te raden als u zo dom bent hem een mail (terug) te sturen. Want de mailheaders bevatten zowel uw publieke als privé internet adres. Waarschuwingen aan de afzender na ontvangst van virussen of bevestigingen van ontvangst van spammail zijn dus uit den boze!

Bedenk dat IP verkeer bijna altijd tweerichtingsverkeer is. Maar dat het IP filter wel kijkt naar de IP adressen in de afzonderlijke datagrams, maar niet naar stroom van datagrammen in hun hun context. Wie de ontvanger van een datagram is weten we, maar de zender ("van Sinterklaas") kan nadat de TCP verbinding eenmaal is gemaakt iedereen zijn. Daarvoor moet je de context begrijpen (of wachten op IPv6). Alleen intelligente routers houden bij of degene die volgens de regels met 192.168.1.5 contact maakt, tijdens de sessie zijn in de From: header opgegeven publieke internetadres heimelijk niet veranderd in een ander IP adres. Idealiter zouden de routers van uw internetproviders deze controle al moeten doen. Maar in de praktijk verkiezen internetproviders (net als hun klanten) snelheid boven veiligheid. En dat blijft ideaal voor hackers.

Controleer uw netwerk met:

ShieldsUP!

Online Security Check

Sygate Online Services

Dynamic Host Configuration Protocol (DHCP)

> Top <

Een firewall is geen geschikte DHCP client, in ieder geval niet op de veilige interface. Maar als u uw IP adres verkrijgt via DHCP dan moet uw wel.

Via DHCP monitor kunt u de procedure volgen.

15.16:28 DISCOVER-bericht versturen.
15.16:28 Aantal opgegeven opties = 6.
15.16:28 Aantal opgegeven opties = 6.
15.16:32 REQUEST-bericht versturen.
15.16:32 Aantal opgegeven opties = 6.
15.16:32 Client omschakelen naar werkstand REQUESTING.
15.16:33 Nieuw IP-adres opgehaald van server 192.168.1.100.
15.16:33 Lease van server 192.168.1.1 wordt gebruikt.
15.16:33 Vastgelegde invoer van 192.168.1.1(192.168.1.100:604800).
15.16:33 Adres toegewezen aan interface 102.168.1.100.
15.16:33 Client omschakelen naar werkstand BOUND.

Welke poorten en IP adressen horen hierbij?

In het begin heeft de DHCP client nog geen IP adres. Dan is slechts de aanduiding 0.0.0.0 (ieder adres) geldig. Om aan een IP adres te komen probeert de DHCP client contact op te nemen met de eerste de beste DHCP server in de buurt. De DHCP client zendt een DISCOVER bericht van UDP poort 68 naar iedere DHCP server poort 68 op zijn broadcastadres 255.255.255.255:

permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0

De DHCP servers die deze UDP broadcast ontvangen reageren met een DHCPOFFER. Dit UDP bericht bevat de configuratiegegegevens (default gateway, dns, dhcpserver):

permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

Als uw DHCP server altijd het IP adres 192.168.1.1 heeft kunt u voor zijn DHCP aanbieding het volgende invullen:

permit 192.168.1.1 255.255.255.255 255.255.255.255 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

De client kan meerdere aanbiedingen krijgen. Hij moet een keus maken en de de DHCP servers die reageerden van de keus op de hoogte stellen. Servers die afgewezen worden krijgen een DHCPDECLINE bericht. Hun IP adressen zijn bekend. Er hoeft nu niet meer gebroadcast te worden, maar zijn IP adres is nog geen feit (0.0.0.0):

permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0

De DHCP server bevestigt de lease met een DHCPACK (of geeft een DHCPNAK als iets niet klopt):

permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

In een 192.168.1.0/24 netwerk kan het netwerk-masker worden gebruikt:

permit 192.168.1.1 255.255.255.255 192.168.1.0 255.255.255.0 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

Latere berichtgeving is Point-to-Point. Bijvoorbeeld op een 192.168.1.0/24 netwerk:

permit 192.168.1.0 255.255.255.255 192.168.1.1 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 192.168.1.1 255.255.255.255 192.168.1.0 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

Kent u de IP adressen vooraf niet dan moet u weer bredere regels aanmaken:

permit 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

Alle DHCP client regels op een rijtje voor een 192.168.1.0/24 netwerk met slechts een DHCP server op router 192.168.1.1:

# Permit DHCP-server 192.168.1.1
permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0
permit 192.168.1.1 255.255.255.255 255.255.255.255 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.1 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.1 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 192.168.1.1 255.255.255.255 192.168.1.0 255.255.255.0 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

Alles op een rijtje voor een onbekende DHCP server (bijv. WLAN Acess Point):

# Permit unknown DHCP server (for WLAN hotspots).
permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0

Kortom: DHCP is een moeilijk te beveiligen protocol dat niet op een firewall thuishoort. Maar soms moet je er ermee werken. In dat geval kunt u ook meerdere configuratiescrips aanmaken. Waarbij u bijvoorbeeld de eerste via startup.cmd start (die met de DHCP server) en de ander vanuit de WPS startup folder. Of na een redelijke latentietijd vanuit startupcmd met een programma als process watchdog for OS/2 servers waarmee u de voor u noodzakelijke processen kunt (her)starten.

Domain Name Service

> Top <

De Domain Name Service is een hiërarchisch georganiseerde gedistribueerde database die hostnamen in IP adressen omzet. DNS servers bieden hun resolver-diensten aan op poort 53. Een DNS client die het IP adres van een host (domein) wil weten vraagt het op de UDP poort 53 van zijn DNS server op. Als de lokale DNS server het niet weet vraagt de DNS server het via zijn UDP poort 53 bij een andere DNS server op.

Een primaire DNS server is verantwoordelijk voor de hostnaam resolutie van zijn eigen domein (authoritative server). Onderling wisselen DNS servers DNS records (blokken van de gedistribueerde DNS databases, ooit eens het hele hostbestand) uit via het betrouwbare TCP (zonetransfer), maar hun DNS resolver dienst (de vertaalacties) voeren ze bij voorkeur uit onder het snelle UDP. De teruggeven resultaten (hostnaam - IP adres) worden in een cache bewaard.

Als u achter de firewall geen primaire DNS server (typisch de named daemon) draait kunt u voor vrijwel alle DNS verzoeken met het UDP gedeelte van de DNS poort 53 volstaan. Dit geldt ook voor pure caching DNS servers en proxies: deze wisselen zelf geen DNS records met andere DNS servers uit. Maar omdat DNS client het verzoek op TCP poort 53 herhaalt als het antwoord niet in een UDP pakket past (zeldzaam, maar bij configuratiefouten van de provider komt het voor), kunt u beter zowel de UDP als de TCP poort 53 open zetten voor uw vaste DNS server.

Vrijwel alle internetprogramma's maken gebruik van de DNS-resolverclient in de TCP/IP stack die vanaf een hoge UDP poort de DNS server op poort 53 benaderd. De DNS servers van uw provider worden ingesteld in het Tab Hosts van TCP/IP notebook. Er is een reboot nodig om ze te veranderen. Caching proxies als Squid en Oops! kunnen wel als zelfstandige DNS client optreden. Door ze slim te configureren zijn ze hiermee niet alleen sneller, maar ook veiliger. De DNS servers geeft u in het configuratiebestand op. Deze naamservers zijn zonder reboot te veranderen (reconfigure).

Als een internetapplicatie contact wil maken met een andere host, doet hij een systeemaanroep. De resolver van de TCP/IP stack vraagt het IP adres van de hostnaam bij de DNS server van uw provider op. Dit proces verloopt heel transparant; alleen de TCP/IP stack hoeft het IP adres van de DNS server te weten. In feite zijn het IP adres van de DNS server en die van de default route of het IP adres van zijn proxy de enige IP adressen die een met het internet verbonden computer (naast zijn eigen IP adres!) moet weten.

Om die reden geeft een DHCP server u niet alleen een IP adres, hostnaam en een default route ( gateway), maar ook de IP adressen van de naamservers door. Als u (of uw baas) geen naamservers opgeeft, beschikt de TCP/IP stack slechts over de ingangen in het hostbestand en moet u voor de rest IP adressen in uw browser opgeven. Ik zou dan voor Google's cache gaan (http://216.239.59.104) en na ieder zoekactie steeds op In cache klikken, maar helaas pindakaas schakelde mijn baas juist dat adres uit...

De regel die de TCP/IP stack achter de filtering firewall toegang geeft tot de UDP poort 53 op 192.168.1.1 (de caching DNS server van de router):

# DNS client: nameserver 192.168.1.1
permit 192.168.1.5 255.255.255.255 192.168.1.1 255.255.255.255 udp gt 49151 eq 53 secure local outbound l=no f=no t=0
permit 192.168.1.1 255.255.255.255 192.168.1.5 255.255.255.255 udp eq 53 gt 49151 secure local inbound l=no f=no t=0

In mijn praktijk is het meteen opvragen van de IP adressen bij de DNS server van de provider (hier 62.251.0.6) merkbaar sneller dan het gebruik maken van een caching DNS server van de router. Ik maak ook regels voor de tweede (backup) DNS server van de provider aan (hier niet afgebeeld).

# UDP DNS client: nameserver 62.251.0.6
permit 192.168.1.5 255.255.255.255 62.251.0.6 255.255.255.255 udp gt 49151 eq 53 non-secure local outbound l=no f=no t=0
permit 62.251.0.6 255.255.255.255 192.168.1.5 255.255.255.255 udp eq 53 gt 49151 non-secure local inbound l=no f=no t=0

Omdat een mislukte UDP aanvraag (de server geeft met een vlag aan dat de teruggestuurde gegevens van het UDP pakket onvolledig zijn) gevolgd wordt door een TCP verzoek naar poort 53 en de host ook wel eens type 3 ICMP berichten met de DNS server uitwisselt plaatste ik deze regels:

# Access to nameserver 62.251.0.6
permit 192.168.1.5 255.255.255.255 62.251.0.6 255.255.255.255 all gt 49151 eq 53 non-secure local outbound l=no f=no t=0
permit 62.251.0.6 255.255.255.255 192.168.1.5 255.255.255.255 all eq 53 gt 49151 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 62.251.0.6 255.255.255.255 icmp eq 3 any 0 non-secure local outbound l=no f=no t=0
permit 62.251.0.6 255.255.255.255 192.168.1.5 255.255.255.255 icmp eq 3 any 0 non-secure local inbound l=no f=no t=0

Als u het IP adres van uw DNS server niet specifiek kunt opgeven (misschien omdat u hem op het WLAN via een AP verkrijgt) hebt u een probleem. Het is namelijk onverstandig om de DNS van iedereen (0.0.0.0) toe te laten. Gelukkig veranderen de IP adressen van DNS servers zelden. U kunt ze met DHCPMON.EXE opvragen. En als u eens een keer vreemd gaat, dan kunt u daar beter een aparte firewall configuratie voor aanmaken.

De syslog daemon

> Top <

De syslog daemon gebruikt UDP poort 514. Hij wordt door mij gebruikt om feedback van routers en achtergrondprocessen te verkrijgen. Met tail kunt u de actuele routerberichten online lezen. Zie Loggen met de syslog deamon.

# syslog          514/udp (server)
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 udp eq 514 eq 514 non-secure local inbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 udp eq 514 eq 514 non-secure local outbound l=no f=no t=0

Om alleen de router op 192.168.1. 1 toegang tot de eCS syslog deamon te geven:

permit 192.168.1.1 255.255.255.255 192.168.1.5 255.255.255.255 udp eq 514 eq 514 non-secure local inbound l=no f=no t=0

Andere routers werken vanaf hogere poorten.

permit 192.168.2.1 255.255.255.255 192.168.1.5 255.255.255.255 udp gt 1023 eq 514 non-secure local inbound l=no f=no t=0

Wat voor u geschikte bronpoort (514 of gt 1023) is kunt u het best bekijken door de router (hier 192.168.1.1) naar de OS syslog server (hier: 192.168.1.5:514) te laten verwijzen en de overdracht te loggen.

permit 192.168.1.1 255.255.255.255 192.168.1.5 255.255.255.255 udp any eq 514 non-secure local inbound l=yes f=no t=0

Waarschuwing: het volstoppen van de vaste schijf met logbestanden is een bekende manier om Denial of Service te veroorzaken. Oude syslog daemon bestanden worden gewist, maar de firewall logbestanden niet. Log daarom alleen het noodzakelijke. En niet de oneindige poortscans naar de TCP poorten 135, 139 en 445. Of nog beter: lanceer via de OS/2 Warp scheduler een batch dat de logbestanden in %etc% regulier verplaatst naar een partitie met meer ruimte. En via email vanuit uw router loggen kan dus ook.

Tip: in uw router kunt u vaak het IP adres van een syslog deamon opgeven. Als u naar meer dan èèn computer wilt loggen, bijv. naar de syslog daemon van OS/2 om online met tail te bekijken en syslog van Linux om netjes te kunnen archiveren, vul dan als IP adres in de router het broadcastadres in: bijvoorbeeld 192.168.1.255:154 op een 192.168.1.0/24 netwerk. Dan zullen zowel de syslog servers op 192.168.1.5:154 als 192.168.1.2:154 de berichten kunnen ontvangen (mits uw routers en firewalls een 192.168.1.254:153 bestemmingsbericht permitteren).

permit 192.168.1.1 255.255.255.255 192.168.1.255 255.255.255.255 udp eq 514 eq 514 non-secure local inbound l=no f=no t=0

of:

permit 192.168.1.1 255.255.255.255 192.168.1.255 255.255.255.255 udp gt 1023 eq 514 non-secure local inbound l=no f=no t=0

UDP broadcast verkeer

> Top <

Veel diensten maken vaak gebruik van UDP broadcast adressen. Deze bestemmingsadressen eindigen vaak op .255 of .255.255. Het betekent zoiets als: voor iedereen (192.168.1.255) in dit subnetwerk (192.168.1.0/24). Via zijn broadcastadres kan een Samba server zich bij alle leden zijn werkgroep aanmelden.

Normaliter wordt het UDP broadcastadres door het netwerkadres bepaald, maar via de tweede pagina in het Tab netwerk van het TCP/IP Configuratie notebook kunt u ook een hiervan afwijkend broadcast adres opgeven. Bijvoorbeeld een 24 bits netwerkadres 192.168.1.0/255.255.255.0 met een 16 bits broadcastadres 192.168.255.255.

Het standaard omroepadres van een 192.168.1.0/255.255.255.0 netwerk is 192.168.1.255. Hiermee kunnen 254 hosts worden benaderd (8 bits min 2 =(2 tot de macht 8) minus 2) met IP adressen 192.168.1.1 t/m 102.168.1.254. Het netwerkadres (192.168.1.0) en het broadcastadres (192.168.1.254) zijn gereserveerd.

Het UDP broadcastadres 255.255.255.255 is aan iedereen gericht. DHCP maakt er gebruik van in de fase dat de DHCP server en client elkaars adressen nog niet kennen. Het IP adres en netmasker van de (eerst nog) IP loze client is 0.0.0.0/0.0.0.0. Dit is een gevaarlijk IP adres want het staat ook voor iedereen. Nu zullen de netmaskers van de routers en de beperkte time-to-live van de aan iedereen gerichte UDP pakketjes verspreiding over de hele wereld voorkomen, maar veilig is het niet.

IP is er op ingesteld broadcast berichten die binnen zijn netwerkmasker vallen te accepteren. De volgende regel staat heel veel broadcast verkeer toe en is eigenlijk alleen op een veilige interface bruikbaar.

permit 192.168.1.0 255.255.255.0 192.168.1.255 255.255.255.255 udp any 0 any 0 secure local outbound l=yes f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.255 255.255.255.255 udp any 0 any 0 secure local inbound l=yes f=no t=0

Let er op dat een UDP broadcastadres altijd een bestemmingsadres is. De bron is hier een client uit het 192.168.1.0/24 netwerk.

U kunt beter specifiekere regels maken. U kunt ze achterhalen door de vorige filterset te loggen en dan te bekijken hoe er daadwerkelijk gebruik van gemaakt wordt. Zowel UDP poorten 137 als 138 worden door Netbios via TCP/IP gebruikt.

Internet Control Message Protocol (ICMP)

> Top <

Het Internet Control Message Protocol (ICMP) speelt zich op de netwerklaag af. De verbindingsloze ICMP berichten gaan van computer naar computer. Vaak worden ze door routers gebruikt om andere routers en broncomputers op de hoogte te brengen van problemen bij de bezorging van IP pakketjes. ICMP berichten geen bron- en doelpoort. Wat u als "bronpoort" invult is het ICMP berichtentype, niet de poort. De volgende regel staat uitgaand ICMP Type 3 verkeer naar DNS server 62.251.0.6 toe:

permit 192.168.1.5 255.255.255.255 62.251.0.6 255.255.255.255 icmp eq 3 any 0 non-secure local outbound l=yes f=no t=0

U kunt het ook schrijven als:

permit 192.168.1.5 255.255.255.255 62.251.0.6 255.255.255.255 icmp eq 3 eq 3 non-secure local outbound l=yes f=no t=0

Het logbestand meldt in beide gevallen:

ICA1042i: geldig pakket uit.  Regel: 28  Adres bron: 192.168.1.5 Adres bestemming: 62.251.0.6  Protocol: icmp ICMP-type: 3  ICMP-code: 3  Routing: local  Interface: non-secure  Adapter: 192.168.123.5  Fragment: n Tunnel: 0  Codering: n Grootte: 56.

Ook de router vermeldt alleen het ICMP berichtype, de bron en de bestemming:

192.168.1.1:61823 -> 145.97.39.135:80 (TCP)Web
192.168.1.1:61823 -> 145.97.39.135:80 (TCP) close connection
192.168.1.1 -> 62.251.0.6 (ICMP) Destination Unreachable

ICMP berichten komen niet van programma's, maar van de netwerklaag. Net als het Adress Resolution Protocol (ARP) dienen ze de samenwerking op de netwerk (IP) laag. Het Adress Resolution Protocol wisselt de MAC adressen van netwerkkaarten door. De TCP/IP stacks van computers die "online" zijn verzenden elkaar dus op gezette tijden wederzijds ARP en IMCP berichten om de communicatie te verbeteren.

De vraag is echter hoe en met wie u wilt communiceren.

De ICMP berichten tussen routers hebben vaak een sturende (verkeersagent) werking. Routers zijn de flessenhals in het IP verkeer. Routers ontvangen pakketjes, onderzoeken ze op hun bestemming en sluizen ze naar de juiste interface door. Als een router meer IP pakketjes aangevoerd krijgt dan hij kan verwerken, dan zullen de IP pakketjes versturende computers langer op antwoord moeten wachten. Maar als hun TCP/IP stack na een bepaalde time-out geen antwoord krijgt versturen ze de niet beantwoorde TCP pakketjes automatisch opnieuw. Maar door dit op zich nuttige mechanisme neemt de belasting van de overbelaste router nog meer toe. Om dit te voorkomen stuurt router een Source Quench (ICMP type 4) bericht naar de TCP/IP stack van de broncomputer dat hem verzoekt zijn herhaalde berichten in een wat lager tempo te versturen. Na een tijdje schroeft de broncomputer het tempo weer op, totdat hij weer een nieuw Source Quench bericht ontvangt. Dit is een mooi voorbeeld van negatieve feedback dat in het belang is van beide partijen. Ik zou het niet blokkeren.

Stel uw wilt webrowser wil contact maken met poort 80 van 192.168.1.2. Maar deze poort wordt door een firewall afgeschermd of de webserver is online. In dat geval zal het SYN bericht nooit bij de webserver afgeleverd worden. Communicatie op de applicatielaag komt niet tot stand. De netwerklaag zal met het pakketje opgescheept zitten. Overigens niet lang, want zo'n pakketje heeft maar een bepaalde levensduur (Time To Live). Zodra het pakketje versterft zal de netwerklaag van de host (of router) waar het vertoeft een ICMP bericht naar de bron versturen dat de bestemming niet kon worden gevonden (ICMP type 3, Destination Unreachable). Een browser die dit ICMP bericht via zijn TCP/IP stack ontvangt hoeft niet meer "oneindig" lang (Mozilla vertoont een zandloper tot zijn time-out is verstreken) op antwoord te wachten. Na uw OK op de foutmelding van de browser hoeft de TCP/IP stack ook geen verwoede pogingen meer doen om u alsnog met die bestemming te verbinden.

permit 0.0.0.0 0.0.0.0 192.168.123.5 255.255.255.255 icmp any 0 eq 3 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 icmp eq 3 any 0 non-secure local outbound l=no f=no t=0

Op een veilige interface is deze feedback van de TCP/IP stack prettig. Maar op een onveilige interface zal het op zijn minst de aanwezigheid van een ICMP berichten generende TCP/IP stack verraden. En kan het een aangrijpingpunt voor een UDP Denial of Service aanval op de TCP/IP stack zijn.

Een voor u bestemd Echo Request (ICMP 4) bericht vraagt niet of u bepaalde diensten draait, maar of uw TCP/IP stack in de lucht is. De TCP/IP stack genereert een Echo Reply (ICMP type 1) bericht en verraadt hiermee de host.

Net als alle ICMP berichten zijn Echo Request berichten sessieloos. U verstuurt ze zonder ene antwoord te verwachten. Ping aanvallen met pakketjes die als bron een netwerkadres van uw eigen netwerk hebben, kunnen (zonder IP spoofing filters) vanaf ieder adres naar uw adres worden verzonden. Dit is de basis van een smurf aanval, waarbij uw PC uw eigen netwerk bestookt met Echo Replies.

Daarom is het verstandig om Denial of Service attacks met ping flooding (en varianten) op de onveilige interface te voorkomen:

deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 icmp any 0 any 0 non-secure route inbound l=no f=yes t=0 

Er zijn programma's in omloop waarmee men uw TCP/IP stack (het aanvalspunt) dodelijk kan pingen. De DENY ICMP ALL regel kan wel problemen geven als uw provider u ICMP berichten stuurt. Maar als u de PERMIT regels voor uw LAN (en ISP gateway) restrictief genoeg hebt ingesteld, zal de laatste DENY ALL regel van de firewall deze ICMP berichten al verbieden. Pas als men uw filterset aanvalt hoeft u van deze rigoureuze regel gebruik te maken.

NB: Als u een publieke internetserver wilt kunnen laten pingen, sta dan alleen pings vanaf enkele alleen aan u bekende netwerkadressen toe. Uw eigen adres hoort hier niet bij. De From: header van een ICMP bericht is gemakkelijk te spoofen.

Hypertext Transfer Protocol (HTTP)

> Top <

Een HTTP server draait standaard op poort 80. Er zijn drie regels nodig voor het aanmaken van de verbinding (3-way handshake). Een SYNchronisatieverzoek versturen, het TCP/ACKnowledge bericht van de server ontvangen en hierop weer een TCP bericht versturen.

# http             80/tcp    World Wide Web HTTP
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 80 non-secure local outbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 80 gt 49151 non-secure local inbound l=no f=no t=0

Is de TCP/IP verbinding eenmaal gelegd, dan gaat het dataverkeer via de in- en uitgaande TCP regels.

Externe HTTP proxy

> Top <

HTTP proxies draaien op diverse poorten. Deze regel om een proxyserver op het internet te bereiken is voor poort 8080 gemaakt.

# http-alt      8080/tcp    HTTP Alternate (see port 80)
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 8080 non-secure local outbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 8080 gt 49151 non-secure local inbound l=no f=no t=0

Als u goed ziet is het een kopie van de vorige regels m.b.t. het HTTP protocol. Alleen is poort 80 in poort 8080 veranderd.

Poort 8080 testen (normaal niet nodig).

HTTP Proxy Server voor het LAN

> Top <

Om een HTTP proxy als Squid of OOPS! (bij mij 8080) op 192.168.1.5 255.255.255.255 voor het LAN beschikbaar te maken, vervangt u 0.0.0.0 0.0.0.0 door 192.168.1.0 255.255.255.0 en draait u de regels om:

# http-alt      8080/tcp    HTTP Alternate (see port 80) Squid/oops! LAN SERVER
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 8080 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 8080 gt 1023 non-secure local outbound l=no f=no t=0

Poort 8080 testen (normaal niet nodig)

Oops! op OS/2 (192.168.1.5) werkt via UDP samen met squid op linux (192.168.1.2)

# icpv2         3130/udp   ICPv2 (squid, oops! server peer to peer)
permit 192.168.1.5 255.255.255.255 192.168.1.2 255.255.255.255 udp eq 3130 eq 3130 non-secure local outbound l=no f=no t=0
permit 192.168.1.2 255.255.255.255 192.168.1.5 255.255.255.255 udp eq 3130 eq 3130 non-secure local inbound l=no f=no t=0

HTTP server voor de buitenwereld

> Top <

Wilt u een eigen webserver op poort 80, dan zet u deze uitzonderingsregels boven de globale regels die netwerkverbindingen van buiten verbieden:

# http             80/tcp    World Wide Web HTTP server
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 80 non-secure local inbound l=yes f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 80 gt 1023 non-secure local outbound l=yes f=no t=0

Zoals u ziet zijn het dezelfde regels als bij de Proxy Server voor het LAN; alleen zijn de LAN IP adressen (192.168.1.0 255.255.255.0) door een globaal masker (0.0.0.0 0.0.0.0) vervangen. Overigens maakt u met zo'n publieke server de Stealth functie van de firewall weer ongedaan: want waar één poort zichtbaar luistert, zitten er meer.

Poort 80 testen (normaal niet nodig)

Secure Sockets Layer (SHTTP)

> Top <

Een Secure Sockets Layer Client maakt via een driewegs handruk contact met een HTTPS server op poort 443. De gegevens worden versleuteld (S, secure) verzonden. Proxies als SQUID bewerken deze gegevens niet. Voor IPFW is de routing gelijk aan HTTP , maar dan op poort 443.

# https           443/tcp    http protocol over TLS/SSL
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 443 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack gt eq 443 49151 non-secure local inbound l=no f=no t=0

Poort 443 testen (normaal niet nodig)

Pop3 mail

> Top <

POP3 mail zit op TCP poort 110. Twee regels volstaan.

# pop3            110/tcp    Post Office Protocol - Version 3
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 110 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 110 gt 49151 non-secure local inbound l=no f=no t=0

Om ellende te voorkomen kunt het best alleen postbestellingen toestaan vanaf uw eigen pop3 servers.

RC:0 [eCS]G:\Desktop->host pop3.demon.nl
pop3.mail.nl.demon.net =   194.159.73.30, 194.159.73.33, 194.159.73.22, 194.159.73.25

Voor iedere pop server maakt u een regelset aan:

# pop3            110/tcp    Post Office Protocol - Version 3 (ISP only)
permit 192.168.1.5 255.255.255.255 194.159.73.30 255.255.255.255 tcp gt 49151 eq 110 non-secure local outbound l=no f=no t=0
permit 194.159.73.30 255.255.255.255 192.168.1.5 255.255.255.255 tcp/ack eq 110 gt 49151 non-secure local inbound l=no f=no t=0

Poort 110 testen (normaal niet nodig)

Imap

> Top <

De gewone IMAP mail afhaaldienst werkt op poort 143.

# imap            143/tcp    Internet Message Access Protocol
permit 192.168.1.5 255.255.255.255 192.168.1.2 255.255.255.255 tcp gt 49151 eq 143 non-secure local outbound l=no f=no t=0
permit 192.168.1.2 255.255.255.255 192.168.1.5 255.255.255.255 tcp/ack eq 143 gt 49151 non-secure local inbound l=no f=no t=0

Maar op mijn thuisnetwerk draai ik secure IMAP die op poort 993 werkt.

# imaps         993/tcp    imap4 protocol over TLS/SSL
permit 192.168.1.5 255.255.255.255 192.168.1.2 255.255.255.255 tcp gt 49151 eq 993 non-secure local outbound l=no f=no t=0
permit 192.168.1.2 255.255.255.255 192.168.1.5 255.255.255.255 tcp/ack eq 993 gt 49151 non-secure local inbound l=no f=no t=0

Poort 143 testen

Poort 993 testen

SMTP client

> Top <

Programmama's als sendmail kunnen op een vreemde TCP poort 25 post ophalen en bestellen. Hiervoor hoeft uw eigen poort 25 niet open te staan. De postbestellingen worden vanaf het hoge (dynamische= even open en dan snel weer dicht) poorten gedaan.

# smtp 25/tcp Simple Mail Transfer (client)
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 25 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 25 gt 49151 non-secure local inbound l=no f=no t=0

Maar ook hier weer geldt: hoe specifieker, hoe beter. Bijv. omdat sendmail ook door anderen (bijv. via een REXX script) kan worden misbruikt. Wat dat betreft is er veel voor te zeggen om sendmail op een lokatie buiten het pad neer te zetten. De door u benodigde gegevens kunt u met host smtp.provider.nl (o.i.d.) opvragen.

RC:1 [eCS]G:\Desktop->host post.demon.nl
post.mail.nl.demon.net =   194.159.73.1, 194.159.73.20

Wordt:

# smtp 25/tcp Simple Mail Transfer 
permit 192.168.1.5 255.255.255.255 194.159.73.1 255.255.255.255 tcp gt 49151 eq 25 non-secure local outbound l=no f=no t=0
permit 194.159.73.1 255.255.255.255 192.168.1.5 255.255.255.255 tcp/ack eq 25 gt 49151 non-secure local inbound l=no f=no t=0

Poort 25 testen

Sendmail als SMPT server

> Top <

Hoe u sendmail als simple Mail Transfer Server instelt staat op de Linux sendmail sectie beschreven.

In de regel zult u alleen binnenkomend SMTP verkeer vanaf uw eigen netwerk willen toestaan:

# smtp 25/tcp Simple Mail Transfer (SENDMAIL LAN SERVER)
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 25 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 25 gt 1023 non-secure local outbound l=no f=no t=0

Voor het versturen van de post naar de internet provider maakt u gebruik van de smarthost functie van Sendmail die als client van de SMTP server van de provider werkt (zie SMTP client). Het smarthost IP adres is op te vragen met host smtp.provider.nl.

# smtp 25/tcp Simple Mail Transfer -> smarthost client
permit 192.168.1.5 255.255.255.255 smarthost 255.255.255.255 tcp gt 49151 eq 25 non-secure local outbound l=no f=no t=0
permit smarthost 255.255.255.255 192.168.1.5 255.255.255.255 tcp/ack eq 25 gt 49151 non-secure local inbound l=no f=no t=0

Poort 25 testen

> Top <

Internet nieuws

Internet nieuws ontvangt u op poort 119:

# nntp            119/tcp    Network News Transfer Protocol
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 119 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 119 gt 49151 non-secure local inbound l=no f=no t=0

Ook hier is het verstandiger om alleen het IP adres van uw "host news.provider.nl" in te vullen.

[D:\]host news.demon.nl
corp.supernews.com =   216.168.3.44

Wordt dan:

permit 192.168.1.5 255.255.255.255 216.168.3.44 255.255.255.255 tcp gt 49151 eq 119 non-secure local outbound l=no f=no t=0
permit 216.168.3.44 255.255.255.255  192.168.1.5 255.255.255.255 tcp/ack eq 119 gt 49151 non-secure local inbound l=no f=no t=0

Poort 119 testen

Limewire

> Top <

Limewire hoort niet op een firewall thuis. Niet alleen vanwege problemen met auteursrechten en de schending van uw privacy (bestandsdeling, IP adres doorgeven), maar vooral ook vanwege de onveiligheid. Anderzijds kunt u Limewire slechts achter een firewall draaien. Dan kunt u tenminste bepalen wat het programma wel en niet kan doen.

Standaard maakt Limewire veel gebruik van het onveilige UDP protocol. UDP is meestal sneller dan TCP, maar het stateless UDP laat geen scherpe packet filtering toe, laat staan de statefull inspection van gespecialiseerde firewalls.

Limewire is overigens een prachtige Java applicatie. Het is meerdradig (vaak > 40 java draden, tig sockets) en heeft het voordeel dat het onder de relatief veilige Java omgeving draait. Een met succes aangevallen Java applicatie geeft de aanvaller nog geen controle over het OS/2 systeem. Alleen maar over die ene Java omgeving. Java is onder OS/2 geen activeX.

De OS/2 Limewire client maakt contact vanaf hoge poorten.

# gnutella-svc client
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 6346 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 6346 gt 49151 non-secure local inbound l=no f=no t=0

Als u alleen deze regel gebruikt doet Limewire het en is de poort 6346 toch stealth volgens de GRC server.

ICA1041w: geweigerd pakket in.  Regel: 112  Adres bron: 4.79.142.206 Adres bestemming: 192.168.123.5  Protocol: tcp  Poort bron: 51593 Poort bestemming: 6346  Routing: local  Interface: non-secure  Adapter: 192.168.123.5 Fragment: n  Tunnel: 0  Codering: n  Grootte: 44

Ondanks het feit dat de Limewire wel degenlijk luistert volgens netstat-s en er veel (niet afgbeelde client verbindingen) lopen:

 
  SOCK   TYPE       FOREIGN          LOCAL         FOREIGN         STATE
                     PORT             PORT            HOST
   442  DGRAM               0               0         0.0.0.0  UDP
   448  DGRAM               0            6346         0.0.0.0  UDP
   449  DGRAM               0            6347         0.0.0.0  UDP
   450 STREAM               0            6346         0.0.0.0  LISTEN    

Windows clients die de OS/2 Java client Limewire als server gebruiken komen van poorten >1023. Ze benaderen vooral TCP poort 6436 en de door mij geblokkeerde UDP poorten 6346- 6348.

# gnutella-svc server 
# permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 6346 secure local inbound l=yes f=no t=0
# permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 6346 gt 1023 secure local outbound l=yes f=no t=0

Limewire maakt veel gebruik van UDP verkeer. Maar die poorten zet u liever niet open.

LimeWire under OS/2: Tips & Tricks

Poort 6346 testen

ICQ

> Top <

ICQ is zonder de netwerkadresvertaling van een proxy of router een gevaarlijk protocol. De ICQ client moet verbinding maken met een ICQ server. Bijvoorbeeld login.icq.com op TCP poort 5190.

# Inloggen op ICQ server TCP poort 5190

permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 5190 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp eq 5190 gt 49151 non-secure local inbound l=no f=no t=0

Het probleem onstaat bij de peer-to-peer verbindingen waar de ICQ client een hoge poorten (1024 - 65535) beschikbaar moet stellen voor andere ICQ clients. De poortnummers kunt u in de icq configuratie opgeven (hier 56840). Dat is beter dan alle dynamische poorten beschikbaar te stellen. Kies wel een poort die niet door Trojaanse Paarden wordt misbruikt (deze worden gescand).

# ICQ peer tot peer
# permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 56840 non-secure local inbound l=yes f=no t=0
# permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 56840 gt 1023 non-secure local outbound l=yes f=no t=0

De ICQ client treedt dan als peer-to-peer server op TCP poort 56840 ("bound port") op.

  SOCK   TYPE       FOREIGN          LOCAL         FOREIGN         STATE
                     PORT             PORT            HOST
  5775 STREAM               0           56840         0.0.0.0  LISTEN    
  5781 STREAM       aol..5190           56818   205.188.8.176  ESTABLISH 

In ICQ firewall centre worden wat suggesties gegeven voor veiliger oplossingen. Een oplossing is dat u uw ICQ client zelf geen poort open stelt en dus verbindingen maakt met de open poorten van een andere ICQ clients (gt 1023).

# ICQ client-peer to serving-peer
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 gt 1023 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack gt 1023 gt 49151 non-secure local inbound l=no f=no t=0

Een andere optie is gebruik te maken met een Socks of HTTPS proxyserver. De proxy doet dan het gevaarlijke werk. De proxy moet namelijk niet alleen als ICQ client optreden, maar ook een hoge poort kunnen open zetten aan de WAN/internet interface. Het probleem van de naar iedereen luisterende hoge poort wordt hiermee dus verplaatst naar de proxy op de firewall.

De toegang via een HTTPs proxy als squid of oops! is een hack. Squid zendt HTTPs onvervalst door en werkt voor HTTPS dus als een socks proxy.

Poort 5190 testen

X server op OS/2

> Top <

Om X programma's onder OS/2 te kunnen draaien hebt u een X server nodig. De client applicaties kunnen via telnet of ssh vanaf een Linux computer worden opgestart, maar de X server moet op uw eigen PC draaien. Zie: X applicaties via het netwerk draaien.

Let er op dat u de remote hosts ook via "xhost +clientnaam" X clients op afstand toegang tot de X server geeft. Dat kan in \home\gebruiker\xinitrc.cmd met de toevoeging:

'xhost +zolder' 
'twm'

De Hoblink en XFree86 X11 servers draaien op TCP poort 6000. Een tweede X server draait op poort 6001. Op een Unix systeem kunnen maximaal 64 X-servers draaien op poorten 6000-6063.

In dit geval staat de OS/2 XFree86 server alleen voor mijn Linux X Window applicatieserver op 192.168.1.2 open.

# x11             6000-6063/tcp   X Window System (SERVER:0.0)
permit 192.168.1.2 255.255.255.255 192.168.1.5 255.255.255.255 tcp gt 1023 eq 6000 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.2 255.255.255.255 tcp/ack eq 6000 gt 1023 non-secure local outbound l=no f=no t=0

De volgende regel staat mijn X client toe om met iedere X server op mijn LAN te verbinden:

# x11             6000-6063/tcp   X Window System (client)
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp gt 49151 eq 6000 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp/ack eq 6000 gt 49151 non-secure local inbound l=no f=no t=0

X-clients moet u in principe nooit verbindingen met de buitenwereld toestaan. Want dan kan een ander uw PC bedienen! Vandaar dat er alleen met 192.168.1.0 255.255.255.0 en localhost verbonden mag worden.

Mijn OS/2 X server maakt gebruik van een X font server (xfs) op tcp poort 7100.

# font-service    7100/tcp   
permit 192.168.1.5 255.255.255.255 192.168.1.2 255.255.255.255 tcp gt 49151 eq 7100 non-secure local outbound l=no f=no t=0
permit 192.168.1.2 255.255.255.255 192.168.1.5 255.255.255.255 tcp/ack eq 7100 gt 49151 non-secure local inbound l=no f=no t=0

De Font sectie van OS/2's XF86config bevat:

FontPath   "192.168.1.2/:7100"

Het Linux bestand /etc/X11/fs/config bevat:

# no-listen = tcp
port = 7100

Op een UNIX systeem bieden het gebruik van de lokale Unix Domain sockets en de bestandspermissies bescherming. Maar de OS/2 X servers maken van de AF_INET Address Family (lees TCP InterNET) sockets gebruik.

                              AF_INET Address Family:

  SOCK   TYPE       LOCAL          STATE    MAX   OVER
                     PORT                  QUEUED QUEUED
======  =====      ==========    ========  =====  =====
     3 STREAM netbios-ssn..139  LISTEN         1     0
     5 STREAM            2868  LISTEN         0     0
     6 STREAM            8118  LISTEN         4     0
     9 STREAM            8080  LISTEN         1     0
   419 STREAM           60077  LISTEN         0     0
   629 STREAM       x11..6000  LISTEN         2     0

De toegang tot poort 6000 moet u dus beperken tot localhost en eventueel het LAN.

De Linux X Fonts Server luistert standaard niet naar "publieke" internet TCP/IP verbindingen (no-listen = tcp) , maar gebruikt evenals de kernel syslog daemon lokale Unix domain sockets, die u met een netstat | more onder ssh kunt zien. Maar in dit geval lopen de verbindingen via "Active Internet connections" vanwege de noodzaak om met OS/2 te communiceren.

zolder:/home/sjoerd # netstat | more
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 zolder.thui:netbios-ssn deskpro.thuis:1192      ESTABLISHED
tcp        0      0 zolder.thuis:imaps      deskpro.thuis:1189      ESTABLISHED
tcp        0      0 zolder.thuis:imaps      deskpro.thu:hp-webadmin ESTABLISHED
tcp        0      0 zolder.thuis:imaps      deskpro.thuis:1190      ESTABLISHED
tcp        0      0 zolder.thui:netbios-ssn visser.thuis:60201   ESTABLISHED
tcp        0      0 zolder.thu:font-service visser.thuis:60136   ESTABLISHED
tcp        0      0 zolder.thuis:imaps      deskpro.thuis:1176      ESTABLISHED
tcp        0      0 zolder.thuis:2088       visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:lrp        visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:prp        visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:descent3   visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:nbx-au     visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:nbx-ser    visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.th:kme-trap-port visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:gnunet     visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:zephyr-hm  visser.thuis:6000    ESTABLISHED
tcp     4928      0 zolder.thuis:minipay    visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:comcam     visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:umsp       visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:dsatp      visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:nbx-dir    visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.t:jetformpreview visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.th:h2250-annex-g visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:amiganetfs visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:rtcm-sc104 visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.thuis:zephyr-srv visser.thuis:6000    ESTABLISHED
tcp        0      0 zolder.th:idware-router visser.thuis:6000    ESTABLISHED
tcp        0      0 192.168.1.2:ssh       192.168.1.5:60076     ESTABLISHED
tcp        0      0 192.168.1.2:ssh       192.168.1.5:60075     ESTABLISHED

Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node Path
unix  18     [ ]         DGRAM                    10391  /dev/log
unix  2      [ ]         DGRAM                    10393  /var/lib/ntp/dev/log
unix  2      [ ]         DGRAM                    10395  /var/lib/stunnel/dev/log
unix  3      [ ]         STREAM     CONNECTED     39136  /tmp/ksocket-sjoerd/klauncher7Tsiea.slave-socket
unix  3      [ ]         STREAM     CONNECTED     39135
unix  2      [ ]         DGRAM                    38956
unix  3      [ ]         STREAM     CONNECTED     36870  /tmp/.ICE-unix/dcop12356-1128456728

Localhost mag u als een veilige interface beschouwen.

Poort 6000 testen

Identification deamon en client

> Top <

Een indent server draait op poort 113. Ik heb hem deels geremd, want het gebruik ervan is dubieus.

# ident/auth       113/tcp    Authentication Service
# permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 113 non-secure local inbound l=no f=no t=0
# permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 113 gt 1023 non-secure local outbound l=no f=no t=0
permit 192.168.0.0 255.255.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 113 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.0.0 255.255.0.0 tcp/ack eq 113 gt 1023 non-secure local outbound l=no f=no t=0

Mailservers doen vaak een query op poort 113. De mailserver wil weten of gebruiker sjoerd ook sjoerd is. Op een UNIX server met zeer veel accounts kun je dat aan het IP adres niet raden. Ze kunnen het dan aan Ident/2 vragen.

Aug 06 18:12:59 : Identd/2 starting
Aug 06 18:12:59 : Options: Port 113  Timeout 30  Connects 10
Aug 06 18:12:59 : Options: Syslogd enabled
Aug 06 18:12:59 : RESPOND: <port-pair> : USERID : OS/2 , US-ASCII : sjoerd

Nu hoeft u waarschijnlijk geen Identd/2 te draaien. Maar als u trage verbindingen met uw mailserver hebt, kunt eventueel permit regels aanmaken voor poort 113. Als de mailserver op de poort geen identd vindt, zal hij ophouden u vergeefs om uw identiteit te vragen.

Poort 113 testen

Telnet en secure shell

> Top <

Ook voor een telnet client op TCP poort 23 volstaan twee regels.

# telnet           23/tcp    Telnet
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 23 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 23 gt 49151 non-secure local inbound l=no f=no t=0

Voor een shh client vervangt u de 23 door een 22.

# ssh              22/tcp    SSH Remote Login Protocol (client)
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 22 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 22 gt 49151 non-secure local inbound l=no f=no t=0

Er zijn (zie boek Linux firewalls) ssh implementaties die lagere clientpoorten gebruiken. Als ssh niet werk kunt u de logbestanden bekijken (zoeken naar poort 22) om te kijken of dit bij u opgaat.

De regels voor een telnet en een ssh server zijn als volgt:

# telnet           23/tcp    Telnet (server)
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 23 non-secure local inbound l=yes f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 23 gt 1023 non-secure local outbound l=yes f=no t=0
# ssh              22/tcp    SSH Remote Login Protocol (server)
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 22 non-secure local inbound l=yes f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 22 gt 1023 non-secure local outbound l=yes f=no t=0

Bovenstaande server configuraties staan alleen gebruik op het LAN toe. Voor de buitenwereld blijven de poorten onzichtbaar. Wilt u uw sshd vanaf ieder IP adres kunnen benaderen:

# ssh              22/tcp    SSH Remote Login Protocol (open server)
# permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 22 non-secure local inbound l=yes f=no t=0
# permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 22 gt 1023 non-secure local outbound l=yes f=no t=0

Overigens is het veiliger om voor 0.0.0.0 0.0.0.0 een specifiek 255.255.255.255 adres te maken!

Poort 22 testen

Poort 21 testen

Virtual Network Computing (VNC)

> Top <

Een VNC server is op twee manieren te bereiken. Via een vnc client programma als vncviewer kunt u de VNC server op poort 5900 bereiken Hebt u geen viewer, dan kunt u gebruik maken van een Java applicatie die de VNC server u aanbiedt als u met uw browser op http://server:5800 inlogt. De VNC server werkt dan niet alleen als X server, maar ook als web en (java)applicatie server.

Regels voor de OS/2 VNC client (vncview):

# Virtual Network Computing (VNC) client 5900 /tcp
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 5900 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 5900 gt 49151 non-secure local inbound l=no f=no t=0

Regels voor de OS/2 Java client:

# Virtual Network Computing (VNC) java client 5800 /tcp
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 5800 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 5800 gt 49151 non-secure local inbound l=no f=no t=0

De strengere regels van een VNC server voor uw eigen netwerk:

# Virtual Network Computing (VNC) LAN SERVER 5900/tcp
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 5900 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 5900 gt 1023 non-secure local outbound l=no f=no t=0

En als u ook de VNC Java applicatieserver opstart:

# Virtual Network Computing (VNC) WWW LAN SERVER 5800 /tcp
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 5800 non-secure local inbound l=yes f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 5800 gt 1023 non-secure local outbound l=no f=no t=0

De VNC server moet u met een wachtwoord beveiligen. Vergeet niet in het tabblad Advanced Password required aan te vinken en een tot uw netwerk beperkte Authhosts op te geven: in mijn geval het netwerk +192.168.1.

De VNC server moet TCP verbindingen van poorten >1023 accepteren voor oude OS/2 , Windows en Linux clients.

Poort 5800 testen

Poort 5900 testen

Netbios via TCP/IP

> Top <

Een programma die u beslist alle activiteit op het internet moet verbieden is het NetBIOS via TCP/IP (NetBEUI). Voor NetBIOS protocol onder OS/2 zijn in %ETC%\services de volgende poorten beschikbaar:

netbios-ns 137/tcp #NETBIOS Name Service
netbios-ns 137/udp #NETBIOS Name Service
netbios-dgm 138/tcp #NETBIOS Datagram Service
netbios-dgm 138/udp #NETBIOS Datagram Service
netbios-ssn 139/tcp #NETBIOS Session Service
netbios-ssn 139/udp #NETBIOS Session Service

NetBIOS via TCP/IP is volgens services onder OS/2 en Windows 9x dus op de TCP en UDP poorten 137-140 actief. Maar in de praktijk gaat het om TCP poort 139 (de NetBIOS sessie dienst) en de de UDP poorten 137 (de NETBIOS Name Service) en 138 (de NETBIOS Datagram Service).

Onder Windows, Linux en OS/2 is TCP poort 139 essentieel. Als die open staat kunt u bestanden en printers (onder OS/2 ook modems) delen. Via TCP poort 139 loggen niet alleen gebruikers en gasten met of zonder wachtwoord in, maar vinden ook de anonieme NULL sessies en NET opdrachten plaats.

De regels om een verbinding met een lokale SMB server op TCP poort 139 te maken:

permit 192.168.1.5 255.255.255.255 192.68.1.0 255.255.255.0 tcp gt 49151 eq 139 both local outbound l=no f=no t=0
permit 192.68.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp/ack eq 139 gt 49151 both local inbound l=no f=no t=0

De UDP poorten 137 en 138 worden gebruikt door de nmbd server van samba. De samba demon (smbd) gebruikt de TCP poorten 139, 445 en 135.

De NetBIOS namen dienst op UDP poort 137 zet NetBIOS namen om in IP adressen (WINS server). Computers die zich aanmelden (LM announce) worden geregistreerd.

Via UDP poort 138 van de NetBIOS Datagram Service is een Windows of OS/2 systeem in de Windows netwerkomgeving en OS/2's Resource-browser Bestanden en Printers Client te zien. Daarnaast lekt de NetBIOS datagram service ook client gegevens zoals de gebruikersnaam en computernaam. Met de server-hidden optie in IBMLAN.INI kunt u het browsen van de shares in- (no) en uitschakelen (yes).

Windows gebruikers hebben achter TCP poort 135 (en 1024+) een Distributed COM Service Control Manager draaien (Microsoft DCOM and SOAP). De verkenner gebruikt hem bij het browsen van de netwerkomgeving. OS/2 gebruikers hebben deze RPC (remote procedure call) dienst niet nodig.

20050725 222736 multiboot 32: 18; ICA1039i; 192.168.1.5;58;192.168.1.12;192.168.1.255;udp;137;137;local;non-secure;n;0;n;78;
20050725 222851 multiboot 32: 20; ICA1041w; 192.168.1.5;79;192.168.1.12;192.168.1.5;tcp;1058;135;local;non-secure;n;0;n;48;
20050725 222851 multiboot 32: 20; ICA1041w; 192.168.1.5;79;192.168.1.12;192.168.1.5;tcp;1058;135;local;non-secure;n;0;n;48;
20050725 222906 multiboot 32: 20; ICA1041w; 192.168.1.5;79;192.168.1.12;192.168.1.5;tcp;1058;135;local;non-secure;n;0;n;48;

Daarnaast maken Windows 2000 en XP en samba versie 3 onderling gebruik van TCP poort 445 van het SMB over TCP protocol. Deze dienst maakt niet gebruik van NetBEUI/NetBIOS (en dus NetBIOS namen), maar gebruikt de IP adressen van de DNS. OS/2 en Windows 9x firewalls hebben echter in de praktijk slechts te maken met de NetBIOS server die op TCP poort 139 bestanden exporteert. Windows 2000/XP clients en servers proberen namelijk eerst de TCP poort 445 uit en als ze daar geen respons krijgen schakelen ze over naar poort 139 om een klassieke SMB (NetBIOS via TCP) verbinding te leggen.

Deze verbindingen zijn in een netstat -s(ockets) terug te vinden:

--------------------------------------------------------------------------
AF_INET Address Family:
Total Number of sockets 44

SOCK TYPE FOREIGN LOCAL FOREIGN STATE
PORT PORT HOST
====== ===== ========== ========== ========== ========
1 DGRAM 0 netbios-dgm..138 0.0.0.0 UDP
2 DGRAM 0 netbios-ns..137 0.0.0.0 UDP
3 STREAM 0 netbios-ssn..139 0.0.0.0 LISTEN 
4 DGRAM 0 emfis-data..140 0.0.0.0 UDP
6 DGRAM 0 49153 0.0.0.0 UDP
8 DGRAM 0 3130 0.0.0.0 UDP
9 STREAM 0 0 0.0.0.0 CLOSED 
1274 STREAM netbios-ssn..139 61399 192.168.1.2 ESTABLISH 
1312 STREAM 1029 netbios-ssn..139 192.168.1.20 ESTABLISH 

Met de volgende regels stelt OS/2 als NetBIOS via TCP/IP server zijn TCP poort 139 beschikbaar voor OS/2 clients:

permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp gt 49151 eq 139 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp eq 139 gt 49151 non-secure local inbound l=yes f=no t=0

Let er echter wel op dat Windows Diensten vanaf relatief lage poorten als 1032-34 en 1061 poort 139 bezoeken. Ook Warp Connect begint al bij 1024.

permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 139 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp eq 139 gt 1023 non-secure local outbound l=no f=no t=0

Via UDP poort 137 verstrekt OS/2's de NetBIOS via TCP/IP aanroepen naar andere NetBEUI clients en via UDP poort 138 regelt het Datagram verkeer.

UDP wordt voor broadcasting gebruikt. Zo meldt de de OS/2 gebruiker "sjoerd" op host "visser.thuis" zich via de NETBIOS Name Service (UDP poort 137) niet alleen op zijn LAN, maar ook op zijn internetadres aan (zie: ShieldsUP!). Een wereldwijde broadcast moet u (0.0.0.0 0.0.0.0) u verbieden.

deny 192.168.1.0 255.255.255.0 0.0.0.0 0.0.0.0 udp eq 137 any 0 non-secure local outbound l=no f=yes t=0

De NetBIOS namendienst op UDP poort 137 wordt door een WINS server geleverd. Maar op een thuisnetwerk zonder WINS server zullen ingangen in het Windows LMhosts bestand volstaan. Voor OS/2 gebruikt u het bestand \ibmcom\rfcnames.lst (Zie: NetBIOS via TCP/IP). U kunt dan de laatste twee regels weglaten.

Overigens is het op de onveilige interface beter om standaard geen UDP toe te laten en alleen voor de door u benodigde DNS server een uitzondering te maken. Uiteindelijk is "verbiedt alles, tenzij" nog steeds de beste firewallstrategie.

UDP poort 139 werd bij niet gebruikt. Maar UDP poort 137 en 138 wel.

permit 192.168.1.5 255.255.255.255 192.168.1.255 255.255.255.255 udp eq 138 eq 138 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.255 255.255.255.255 udp eq 138 eq 138 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 udp eq 137 eq 137 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 udp eq 137 eq 137 non-secure local inbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.255 255.255.255.255 udp eq 137 eq 137 non-secure local inbound l=no f=no t=0

Wat u dan nog ziet is:

20030521 223330 ecs 32: 20; ICA1041w; 192.168.1.5;25;192.168.1.20;192.168.1.5;tcp;1044;445;local;non-secure;n;0;n;48;

Een TCP poort 1044 op w2k die contact zoekt met TCP poort 445 (Microsoft Domain Service) op eCS. Maar goed, die heb ik niet. Poort 445 is vanaf Windows 2000 in gebruik (The use of TCP port 445 in Windows 2000) en is de meest aangevallen poort volgens DShield.org.

Bovenstaande regels kunnen gedekt worden door een globale regel die het eigen netwerk vrijstelt. Als u op de LAN netwerkkaart buiten de non-secure interface kunt houden is dat wel zo gemakkelijk. Dat is het geval bij een dial-up verbinding.

Poort 135 testen

Poort 139 testen

Poort 445 testen

FTP client

> Top <

Het File Transfer Protocol is een lastig protocol. Bij FTP worden namelijk niet alleen bestanden verzonden, maar worden ook opdrachten op de server uitgevoerd. Om die reden moet de FTP cliënt eerst op de UNIX server inloggen, voordat hij zijn opdrachten kan geven. Bovendien treedt de FTP cliënt bij actieve FTP ook als server op.

De FTP prompt is een soort telnet die in een strak beheerde omgeving werkt. Een grafisch FTP programma geeft die tekstuele informatie slechts grafisch weer. Met telnet hebt u de beschikking over alle commando's in uw pad en de login-shell. De ftp prompt ondersteunt echter maar een beperkt aantal opdrachten:

OS/2 Command Interpreter version 4.5

RC:0 [eCS]F:\->ftp
IBM TCP/IP for OS/2 - FTP cliënt ver 10:47:01 on Aug 16 2000
ftp> help
Commands may be abbreviated. Commands are:

! delete ls pwd status
$ dir macdef quit struct
account disconnect mdelete quote sunique
append euc mget recv tenex
ascii form mkdir remotehelp trace
bell get mode rename type
binary glob mput reset user
bye hash nmap restart verbose
cd help ntrans rmdir ?
cdup image open runique
close iso2022 prompt send
cr keepdate proxy sendport
debug lcd put site
ftp> help get
get receive one file

ftp>

Om veiligheidsredenen zullen niet alle hierboven genoemde opdrachten door de FTP server worden ondersteund. Alleen de hoogst noodzakelijke. Bovendien geeft de FTP server u een aangepaste shell in een aangepaste (change root) omgeving. Opdrachten als set werken dus niet. Hiertoe horen de opdrachten waarmee u op de server bestandsinformatie weergeeft (dir), maneuvreert (cd), bestanden zendt (send), hernoemt (rename), wist (remove, rmdir) of ontvangt (get). De output van die FTP prompt wordt vanaf de datapoort 20 door de server naar uw FTP cliënt verzonden.

Een voorbeeld van een FTP sessie vanaf de prompt.

ftp> open homepages.demon.nl
Connected to homepages.demon.nl.
220 homepages.demon.nl FTP server (Demon/Academ/WU [11] Dec 4 10:44:41 GMT 2001)
ready.
Name (homepages.demon.nl): sjoerd-visser
331 Password required for sjoerd-visser.
Password: ...............
230-User sjoerd-visser logged in. Access restrictions apply.
230 Disk usage is 12432384 bytes. Quota is 20971520 bytes.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 464
drwxr-xr-x 13 webuser web 4096 Feb 2 00:56 .
drwxr-xr-x 6 internet web 4096 Sep 4 2002 ..
-rw------- 1 webuser web 123943 Mar 10 01:26 bgebruik.txt
-rw-rw-r-- 1 webuser web 5405 Jul 8 2002 blauw_wit.gif
-rw-r--r-- 1 webuser 60001 6 Feb 21 23:09 count.txt
drwxrwxr-x 3 webuser web 4096 Jul 8 2002 doip-os2
drwxrwxr-x 3 webuser web 4096 Jan 3 02:21 ecs-os2
drwxrwxr-x 2 webuser web 4096 Jul 8 2002 firewall
-rw-r--r-- 1 webuser web 7850 Jun 8 2000 fond_ora.jpg
-rw-r--r-- 1 webuser web 940 Jul 8 2002 frame.html
-rw-rw-r-- 1 webuser web 14118 Oct 7 17:07 index.html
-rw-r--r-- 1 webuser web 4143 Jul 8 2002 links.html
drwxrwxr-x 2 webuser web 4096 Feb 9 23:05 linux
drwxrwxr-x 3 webuser web 4096 Jul 8 2002 multiboot
drwxrwxr-x 3 webuser web 4096 Feb 2 14:43 net-linux
drwxrwxr-x 3 webuser web 4096 Jul 8 2002 net-os2
drwxrwxr-x 3 webuser web 4096 Oct 9 19:42 os2
-rw-r--r-- 1 webuser web 5248 Apr 8 2001 rechts.html
drwxrwxr-x 2 webuser web 4096 Jul 8 2002 staroffice
drwxrwxr-x 2 webuser web 4096 Jul 8 2002 vpc
drwxrwxr-x 3 webuser web 4096 Jul 26 2002 xfree86-os2
226 Transfer complete.
1357 bytes received in 0.02 seconds (66 Kbytes/s)
ftp> get bgebruik.txt
200 PORT command successful.
150 Opening ASCII mode data connection for bgebruik.txt (123943 bytes).
Received 126992 bytes
226 Transfer complete.
local: bgebruik.txt remote: bgebruik.txt
126992 bytes received in 1.74 seconds (71 Kbytes/s)
ftp> quit
421 Timeout (120 seconds): closing control connection.
RC:0 [eCS]F:\->

De twee sessies van het FTP protocol

> Top <

Aan de serverkant doen twee poorten mee: de commandopoort 21 en de datapoort 20. Deze stonden tijdens deze FTP sessie in verbinding met de commandopoort (57796) en een datapoort (57801) van mijn FTP cliënt. Tijdens het downloaden van bestanden of informatie (ls) geeft netstat -s(ockets) dit te zien:

SOCK TYPE FOREIGN LOCAL FOREIGN STATE
PORT PORT HOST
-------------------------------------------------------------------------
2437 STREAM ftp..21 57796 194.159.245.18 ESTABLISH 
2451 STREAM ftp-data..20 57801 194.159.245.18 ESTABLISH 

Tijdens een wachttoestand van de FTP server zult u alleen de eerste regel zien. Waar het hier om gaat is dat u twee FTP sessies ziet. De FTP cliënt neemt via poort 57796 contact met poort 21 van de FTP server op. En de FTP server is via ftp-data poort 20 met poort 57801 van de FTP client verbonden. De FTP server neemt dus weer actief contact met de FTP client op.

Hoe die laatste stap optreedt is van belang voor iedere firewall. Want standaard neem de FTP server zelf (=actief) vanaf poort 20 contact op met de FTP client. Maar omdat het initiatief nu bij de FTP server ligt, moet de FTP cliënt wel als dienstverlener (server) optreden. Men spreekt dan van actieve FTP sessie. Tijdens een (voor de FTP server) passieve FTP sessie zal de FTP server zelf een datapoort openzetten en treedt hij alleen als dienstverlener op.

Actieve FTP

> Top <

Bij actieve FTP zal de server na de acceptatie van de verbinding met de cliënt (2a) op eigen initiatief (= actief) via zijn datapoort 20 een verbinding met de al van tevoren geopende datapoort van de cliënt opzetten (2b). De cliënt geeft een commando (2a) en opent haar poort (2b), waarvan ze de locatie (poort 57801) van tevoren (in 1a en 1b) al aangeven heeft.

1a

cliënt A 
(cmd poort 57796)

SYN (mijn referentie: #c -->

SERVER (bezet)
(poort 21 )

1b

cliënt A
(cmd poort 57796)

SYN (mijn referentie: #c ) -->

SERVER (vrij)
(poort 21)

2a

2b

cliënt A 
(cmd poort 57796)
cliënt A 
(datapoort 57801)

<-- ACK (uw referentie: #c) 
<-- SYN (mijn referentie: #s)

<-- SYN (mijn referentie: #s)

SERVER 
(poort 21)
SERVER 
(poort 20)

3

cliënt A
(datapoort 57801)

ACK (uw referentie: #c) --- >
SYN (mijn referentie: #s) -- >

SERVER 
(poort 20)

Het openzetten van die hoge datapoort (hier 57801) door uw FTP cliënt voor verbindingen van buiten is een bekend veiligheidsprobleem. En als uw FTP cliënt achter een firewall zit dit open ("listen") zetten van hoge poorten en/of verbindingen met poort 20 blokkeert, zullen de berichten van de FTP server voor de cliënt verloren gaan. U kunt dus wel inloggen en actief opdrachten versturen, maar u krijgt geen bestanden (de output van ls of dir) te zien.

Welke regels horen hierbij?

Om te beginnen moet een verbinding met poort 21 worden opgebouwd (stap 1a en 1b):

# ftp              21/tcp    File Transfer [Control]
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 21 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 21 gt 49151 non-secure local inbound l=no f=no t=0

We gaan naar NetLabs.

230 Login OK.
SYST
215 UNIX type:OS/2
TYPE I
200 OK
PORT 192,168,1,5,247,21
200 Data port set
LIST /pub
150 OK, opening data connection.

En daarna zie je niets.... De firewall log geeft:

Denied packet in.  Rule: 22  Source addr: 212.12.41.77  Destination addr: 192.168.1.5  Protocol: tcp  Source port: 20  Destination Port: 63253  Routing: local  Interface: non-secure  Adapter: 192.168.1.5  Fragment: n  Tunnel: 0  Encryption: n  Size: 60.

Oftewel: Een hoge bestemmingspoort (hier 63253 ) van de FTP client moet openstaan voor de datapoort 20 van de FTP server. We voegen drie regels toe om het in- en uitgaande ("Denied packet out") FTP dataverkeer toe te staan:

# ftp-data         20/tcp    File Transfer [Default Data]
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 20 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 20 gt 49151 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp eq 20 gt 49151 non-secure local inbound l=no f=no t=0

Omdat tcp ook tcp/ack berichten omvat komen we uiteindelijk met vier FTP regels uit:

# ftp              21/tcp    File Transfer [Control]
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 21 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 21 gt 49151 non-secure local inbound l=no f=no t=0
# ftp-data         20/tcp    File Transfer [Default Data]
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 20 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp eq 20 gt 49151 non-secure local inbound l=no f=no t=0

Het feit dat de FTP client (of beter gezegd de TCP/IP stack) op commando van buiten (een FTP server of hacker) een dynamische poort vrijgeeft voor de FTP server op poort 20, is de kern van het FTP beveiligingsprobleem.

Poort 20 testen

Poort 21 testen

Passieve FTP

> Top <

Bij passieve FTP opent de cliënt beide poorten op de server. De FTP server is een passieve dienstverlener. De cliënt is actief. De cliënt hoeft niet zijn op dataverbinding te wachten, maar zet hem zelf op gang (2b) met de informatie die hij van de server krijgt (2a). Zie: Active FTP vs. Passive FTP, a Definitive Explanation.

Voor passieve FTP zijn de volgende regels nodig:

Verbinding maken gaan als bij actieve FTP (1a en 1b.)

# ftp              21/tcp    File Transfer [Control]
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 21 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 21 gt 49151 non-secure local inbound l=no f=no t=0
# ftp-data     passive mode
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 21 gt 49151 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 gt 1023 non-secure local outbound l=no f=no t=0

Samengevat:

# ftp passive mode           21/tcp    File Transfer [Control]
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 eq 21 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp/ack eq 21 gt 49151 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp gt 49151 gt 1023 non-secure local outbound l=no f=no t=0

Het belangrijkste verschil is dat er geen verkeer binnenkomt zonder ACK vlag.

FTP server

> Top <

De regels voor een OS/2 FTP server zijn omgekeerd aan die van een FTP client.

# ftp server       21/tcp    File Transfer [Control] FTP server
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 21 non-secure local inbound l=yes f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp/ack eq 21 gt 1023 non-secure local outbound l=yes f=no t=0
# ftp-data         20/tcp    File Transfer [Default Data] FTP server
permit 0.0.0.0 0.0.0.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 20 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 0.0.0.0 0.0.0.0 tcp eq 20 gt 1023 non-secure local outbound l=no f=no t=0

Een FTP server voor het 192.168.1.0/24 LAN is wel zo veilig:

# LAN ftp server       21/tcp    File Transfer [Control] FTP server
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 21 non-secure local inbound l=yes f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp/ack eq 21 gt 1023 non-secure local outbound l=yes f=no t=0
# ftp-data         20/tcp    File Transfer [Default Data] FTP server
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 tcp gt 1023 eq 20 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 tcp eq 20 gt 1023 non-secure local outbound l=no f=no t=0

FTP is ook voor servers een gevaarlijk protocol. De FTP server (ftpd.exe) van OS/2 is niet voor gebruik op het internet bedoeld. Wilt u meer dan een FTP server voor uw LAN of WAN, gebruik dan de FtpServer van Peter Moylan.

Poort 20 testen

Poort 21 testen

NFS client

NFS Server

Een NFS server maakt verbinding via de portmap daemon. Deze serveert SUN's remote procedure call voor NF netwerken. Zie Network File System op de eComStation sectie. De sunrpc portmap daemon loopt op poort 111 zoals netstat -s laat zien:

SOCK   TYPE       LOCAL          STATE    MAX    OVER
                   PORT                   QUEUED QUEUED
--------------------------------------------------------------------------
2651   STREAM     sunrpc..111    LISTEN   0      0

nfs             2049/tcp   #Network File System - Sun Microsystems
nfs             2049/udp   #Network File System - Sun Microsystems

De NFSD loopt op poort 2049. Omdat deze gedeeld wordt met "shilp" (zie etc/services)

# <== NOTE Conflict on 2049 !

shilp           2049/tcp   #
shilp           2049/udp   #
nfs             2049/tcp   #Network File System - Sun Microsystems
nfs             2049/udp   #Network File System - Sun Microsystems

zal neststat shilp als eigenaar van de poort opgeven.

2116 STREAM               0     shilp..2049         0.0.0.0  LISTEN    
2121  DGRAM               0     shilp..2049         0.0.0.0  UDP

                              AF_INET Address Family:

  SOCK   TYPE       LOCAL          STATE    MAX   OVER
                     PORT                  QUEUED QUEUED
--------------------------------------------------------------------------
  2066 STREAM     sunrpc..111  LISTEN         0     0
  2173 STREAM           54149  LISTEN         0     0
  2202 STREAM           54150  LISTEN         0     0
  2215 STREAM     shilp..2049  LISTEN         0     0
--------------------------------------------------------------------------

Grove aanvallen weren

> Top <

Denial of service (DOS) aanvallen

> Top <

Bij een Denial of Service (DOS) aanval bestookt de aanvaller uw host met IP pakketjes met de bedoeling uw computer of netwerk te ontregelen. Bij een DOS aanval gaat het meestal om heel veel IP pakketjes, vaak van verschillende bronnen (Distributed DOS). Maar de aanvaller kan u ook enkele kwalitatief afwijkende IP pakketjes sturen, die veel intern netwerkverkeer genereren of waarin de TCP/IP stack zich verslikt.

U weert DOS aanvallen het best aan de WAN poort van uw internet gateway/ router. Dus voor ze uw netwerk bereiken. De router moet toch alle IP pakketjes die uw netwerk in- en uitgaan bekijken. Hij is erin gespecialiseerd. De WAN poort van de router is ook de ideale plaats om anti-IP spoofing regels te implementeren. Via de WAN poort naar het internet horen geen privé-internetadressen te komen.

Hieronder ziet u de webinterface van mijn Draytek router. Ongeduldige internetclients die mijn servers 300 SYNChronisatieverzoeken per seconde doen, worden met een time-out van 10 seconden geweerd. Dit zijn de standaardwaarden.

Tegen massieve DOS aanvallen kunt u zich maar beperkt weren. Als ze van verschillende bronnen komen zijn ze moeilijk te blokkeren. En ook het onderzoeken kost tijd. Als de regels onder de laatste deny-all regel vallen gaan ze eerst overal langs om daarna het logsysteem te belasten.

Pakketjes waarvan u zeker weet dat ze niet op uw LAN thuishoren kunt u daarom het best meteen verbieden. U kunt er voor kiezen om ze te loggen, maar aan de logfunctie hebt u niet zoveel tijdens een DOS aanval. De buffers van de syslogd zullen snel overlopen. Ordinaire poortscans naar TCP poorten als 445, 139 en 135 log ik ook niet.

Fragmentatie

> Top <

Ethernetwerken werken standaard met pakketjes van 1500 bytes. U kunt die Maximum Transmission Unit (MTU) in de geavanceerde opties van de ethernetadapter verlagen, maar niet verhogen. Als pakketjes met een grootte van bijv. 4136 bytes (pppo) door een router naar een ethernetadapter (lan0) doorgesluisd worden ontstaat fragmentatie. De router zal de pakketjes in een kleiner formaat moeten herschrijven:

H:12345678 (ppp0) = H123 + H456 + H78 (lan0). 

Crackers kunnen pakketjes maken die ook IP adressen in de (meta)data bevatten. Als fragment kan zo'n niet in de header (H) opgeslagen adres (h) actief worden:

H:123h456h78 (ppp0) = H123 + H456 + h78 (lan0). 

Dit is een manier om de restricties van de alleen naar de header H kijkende firewall te omzeilen. Daarom kunt u beter geen gefragmenteerde pakketen toelaten (PERMIT: fragmentation: NO of DENY: fragmentation: ONLY).

deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 both both both l=no f=only t=0 

IP spoofing

> Top <

Bij IP spoofing (voor de gek houden, IP vermomming) verandert een indringer de kopjes van zijn IP pakketjes, zodat het lijkt alsof ze van andere hosts afkomstig zijn.

Gebrek aan authentificatie is een beperking van het huidige Internet Protocol IPv4. De routers op het internet controleren de herkomst van de pakketjes niet. Alleen de snelle bestelling telt. Een tussen normale pakketjes verstopte From: 192.168.1.2 IP header wordt gewoon doorgesluisd. De controle van ieder pakketje afzonderlijk kost teveel tijd.

Nadat iemand zich op de gewone manier op uw netwerk aangemeld heeft, kan hij het from: internetadres in zijn IP pakketjes veranderen in een lokaal netwerkadres (bijv. from: 192.168.1.2). Bij aankomst op uw LAN zal de geadresseerde 192.168.1.2 een ontvangstbevestiging zenden, maar die weet van niks. Misschien staat de computer wel uit. Zoiets (blind IP spoofing) geeft altijd netwerkoverhead en kan de basis zijn van veel onbegrip, heen en weer geroep en dus een Denial of Service Attack .

De aanvaller op het internet krijgt de aan 192.l68.1.2 gerichte ontvangstbevestigingen van de router nooit te zien, maar kan met gehaaide programma's wel doen alsof hij 192.l68.1.2 is en het ontvangstbericht heeft ontvangen. Hij zendt goed getimed een nieuw bericht en probeert zo nodig met een denial of service attack met SYN flooding 192.l68.1.2 de mond te snoeren. Dat is het begin van een TCP takeover. Zie: Introduction to IP Spoofing.

Een packet filter op de router van u of uw provider kan het best voorkomen dat bekende IP headers van hosts op private netwerken naar binnen of naar buiten gaan. Beschikt u over een veilige lan interface (in mijn DMOZ testsituatie dus niet), dan kunt u gerust al het dataverkeer met privé-adressen op de onveilige interface verbieden (CERT Advisory CA-1995-01 IP Spoofing Attacks and Hijacked Terminal Connections).

Lokaal verkeer voor het bastionhost gaat altijd via de LAN (192.168.1.1) of WAN poort (publiek IP) naar localhost. Pakketten die voor uw publiek adres bestemd zijn en uw eigen publieke IP adres als bron hebben moet u weren (en wel aan beide interfaces). De toegangsrechten voor de IP masquerading (wie wel, wie niet) moet u in de NAT firewall software (bijv. Injoy) regelen.

Treedt OS/2 slechts als screening filter op (permit .. both route), dan kunt u alle externe toegang tot de router zelf verbieden (deny .. both local).

deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 both local both l=no f=yes t=0 

De OS/2 firewall biedt geen IP masquerading. Netwerkadresvertaling zal van proxy software moeten komen. Om nodeloze problemen te voorkomen zet u de routerfunctie uit. Regels tegen IP spoofing blijven echter nuttig om de firewall (IP stack en applicatiesoftware) te beschermen.

Een host op het internet mag geen privé-netwerkadres als bronadres opgeven. Deze pakketjes kunt u op de WAN interface meteen naar de eeuwige bitvelden verwijzen.

# regels tegen IP spoofing op de WAN interface van de ISP
deny 10.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both inbound l=yes f=yes t=0 
deny 172.16.0.0 255.240.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both inbound l=yes f=yes t=0
deny 192.168.0.0 255.255.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both inbound l=yes f=yes t=0 

U kunt i.p.v. inbound ook both gebruiken. Maar op een onveilige interface die ook het LAN bediend (WLAN netwerkkaart) moet u ze vooraf laten gaan door gedetailleerde PERMIT regels die u toch toegang tot uw LAN geven. En dan hebt u toch weer een lek in de beveiliging.

Een gast die zich "localhost" noemt mag er bij mij zeker niet in. Sinterklaas gaat toch ook niet door uw schoorsteen? Het is wijs dit soort "nogal wiedus" beperkingen standaard in te bouwen. U moet wat paranoïde denken. De kans op een geslaagde inbraakpoging op uw firewall neemt hierdoor af.

# Localhost should remain local
deny 127.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure route inbound l=yes f=yes t=0 

Een broadcastadres is alleen geldig als bestemmingsadres:

# Misuse of broadcast address
deny 0.0.0.255 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both both l=yes f=yes t=0 
# Deny incoming broadcast
deny 0.0.0.0 0.0.0.0 0.0.0.255 0.0.0.0 all any 0 any 0 non-secure both inbound l=yes f=yes t=0

UDP multicastpaketten worden aan een verzendlijst toegestuurd. Het adres 224.0.0.0/4 is alleen als bestemmingsadres legitiem.

# Permit UDP 224.0.0.0/4 multicasting
# permit 192.168.1.5 255.255.255.255 224.0.0.0 224.0.0.0 udp any 0 any 0 non-secure local inbound l=no f=yes t=0
# Always deny non UDP or multicast adresses in source!!
deny 224.0.0.0 224.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both inbound l=yes f=yes t=0
deny 0.0.0.0 0.0.0.0 224.0.0.0 224.0.0.0 all any 0 any 0 non-secure both inbound l=yes f=yes t=0

Bij een onveilige interface die tevens de interface voor uw netwerk is, zijn anti-spoofing regels nauwelijks op te zetten. Dat is een belangrijke reden dat een professionele firewall altijd meerdere interfaces (en soms tussenstations) kent. In het thuisnetwerk zal een hardware firewall-router hierin kunnen voorzien. Daarnaast is de policy van uw ISP van belang.

Overigens moeten kabelmodembezitters wel bedenken dat met protocollen als NetBIOS over TCP/IP de buren in uw "werkgroep" uw poort 139 kunnen zien. Het filter van de ISP router betreft het eigen (sub)netwerk doorgaans niet. Dat moet u zelf doen.

deny 62.251.0.0 255.255.0.0 62.251.0.0 0.0.0.0 tcp any 0 eq 139 non-secure route inbound l=yes f=yes t=0 

WLAN gebruikers hebben een nog groter probleem.

SYN flooding en denial of service

> Top <

Tijdens het opzetten van een TCP/IP verbinding maken cliënt (opdrachtgever) en server (uitvoerder) een 3-way handshake.

1. De cliënt stuurt SYN(chronisatie)verzoeken naar de server totdat deze reageert. Dit TCP- segment bevat het initiële volgnummer (initial sequence #) dat de cliënt voor de administratie van de verbinding wil gebruiken.

2. De server stuurt de cliënt een bevestiging (ACKnowledge) van ontvangst van zijn SYNchronisatie verzoek en het initiële volgnummer (SYN) dat hij gaat gebruiken.

3. De cliënt bevestigt de ontvangst het SYN bericht van de server met een ACK(nowledge) segment.

SYN flooding is een techniek waarbij (meerdere) clients wel SYN(chronisatie)-verzoeken naar de server sturen, maar niet reageren op zijn SYN/ACK berichten (2ab). De verbinding staat dan half open. De server stuurt de cliënt in principe SYN/ACK berichten totdat hij een ACK-bericht van de cliënt krijgt (3b), met als resultaat een open verbinding, of hij het na een van tevoren vastgestelde time-out periode opgeeft (geannuleerde verbinding).

Als nu meerdere clients in hoog tempo SYN berichten naar de server sturen (SYN flooding), en vervolgens niet op zijn ACK berichten reageren (2b), raakt het bestellijstje waarin de server de gegevens van al die aangevraagde, maar onafgewerkte verbindingen bewaard, op een zeker moment vol. De aanvallers sturen meer SYN verzoeken dan de server kan annuleren. Deze buffer overflow zorgt voor een denial of service: In het volle huishoudboekje passen geen nieuwe klanten meer. De server zal geen nieuwe verbindingen accepteren.

Zie ook de aanbevelingen van het CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks .

Currently, the best method is to install a filtering router that restricts the input to your external interface (known as an input filter) by not allowing a packet through if it has a source address from your internal network. In addition, you should filter outgoing packets that have a source address different from your internal network to prevent a source IP spoofing attack from originating from your site.

NB. TCP/IP 4.1 biedt nog wat extra bescherming tegen SYN Flooding.

inetcfg -s synattack 1
inetcfg -s syncookie 1

Het nadeel (?) is dat XP uw shares dan niet ziet. Zie: syncookie activatie .

netstat - l geeft statistieken (listening socket queue info). U ziet alleen de open TCP servers. En niet de actuele situatie (netstat -s).

[H:\]netstat -l 
-------------------------------------------------------------------------- 
AF_INET Address Family: 
SOCK TYPE LOCAL STATE MAX   OVER 
PORT                  QUEUED QUEUED 
====== ==== ========= ======= ==== ===== 
3   STREAM netbios-ssn..139 LISTEN 0 0 
6   STREAM 3128 LISTEN 8 35 
827 STREAM hosts2-ns..81 LISTEN 0 0 
828 STREAM http..80 LISTEN 4 0 
829 STREAM ftp..21 LISTEN 1 0 
930 STREAM 56347 LISTEN 0 0 

Max Queued slaat op het maximaal aantal half open (niet afgewerkte) verzoeken. Over Queued slaat op niet gehonoreerde verzoeken. Een hoge waarde kan op een Denial off Service aanval wijzen. Maar ook op een trage server. De proxy van de WWW mirroring tool Sslurp op poort 3128 blijkt op een zeker moment overvraagd te zijn (OVER QUEUED). Deze is voor eigen gebruik. De WWW server Xitami (die ik met een heleboel Sslurpjes tegelijkertijd testte) gaf geen kik.

Eric Detoisien: Externe aanvallen

Nog enige bijzondere gevallen

Een minimale firewal voor een hotspot via DHCP

> Top <

Als u uw LAN IP adres niet kent, dan hebt u een probleem. De situatie kan zich voordoen bij DHCP op een WLAN hotspot. Dan kunt u eigenlijk alleen 127.0.0.1 als een veilige interface beschouwen en maakt u zeer kritische regels voor uw buren aan. Servers zult u nu niet willen draaien. Niet alleen het internet is een gevaarlijke omgeving, maar ook het LAN. Zelfs het NetBIOS kan nu problemen opleveren.

Ik maak nu weer gebruik van in principe veilige regels in %ETC%\security\fwfiltrs.cnf.

De uitgangspunten zijn:

• Alleen client verbindingen naar buiten toestaan met uitzondering van actieve ftp.

• De DHCP server bevindt zich in een privé-netwerk bereik.

• DNS en DHCP zijn de enige toegestane UDP protocollen.

permit 127.0.0.1 255.0.0.0 127.0.0.1 255.0.0.0 all any 0 any 0 secure local both l=no f=no t=0
permit 192.168.0.0 255.255.0.0 0.0.0.0 0.0.0.0 tcp gt 49151 lt 9000 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.0.0 255.255.0.0 tcp/ack lt 9000 gt 49151 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.0.0 255.255.0.0 tcp eq 20 gt 49151 non-secure local inbound l=no f=no t=0
permit 172.16.0.0 255.255.0.0 0.0.0.0 0.0.0.0 tcp gt 49151 lt 9000 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 172.16.0.0 255.255.0.0 tcp/ack lt 9000 gt 49151 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 172.16.0.0 255.255.0.0 tcp eq 20 gt 49151 non-secure local inbound l=no f=no t=0
permit 10.0.0.0 255.0.0.0 0.0.0.0 0.0.0.0 tcp gt 49151 lt 9000 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 10.0.0.0 255.0.0.0 tcp/ack lt 9000 gt 49151 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 10.0.0.0 255.0.0.0 tcp eq 20 gt 49151 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all gt 49151 eq 53 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all eq 53 gt 49151 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 255.255.255.255 255.255.255.255 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 68 eq 67 non-secure local outbound l=no f=no t=0
permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp eq 67 eq 68 non-secure local inbound l=no f=no t=0
deny 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure both both l=yes f=yes t=0

Wilt u op een 192.168.1.0/24 netwerken is NetBIOS via TCP/IP toegestaan (alleen als client), dan kunt u deze (praktijk)regels voor het UDP verkeer toevoegen. Doe dat wel voor de laatste deny regel.

# netbios-ns      137/udp    NETBIOS Name Service
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 udp eq 137 eq 137 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 udp eq 137 eq 137 non-secure local inbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.255 255.255.255.255 udp eq 137 eq 137 non-secure local inbound l=no f=no t=0
# netbios-dgm     138/udp    NETBIOS Datagram Service
permit 192.168.1.5 255.255.255.255 192.168.1.255 255.255.255.255 udp eq 138 eq 138 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.255 255.255.255.255 udp eq 138 eq 138 non-secure local inbound l=no f=no t=0
permit 192.168.1.5 255.255.255.255 192.168.1.0 255.255.255.0 udp eq 138 eq 138 non-secure local outbound l=no f=no t=0
permit 192.168.1.0 255.255.255.0 192.168.1.5 255.255.255.255 udp eq 138 eq 138 non-secure local inbound l=no f=no t=0

Het gewone NetBIOS is niet routerbaar. NetBEUI shares zijn dus voor iedereen in de WLAN te lezen! Die kunt u dus niet vrijgeven.

OS/2 als router

> Top <

Als u Virtual PC voor OS/2 op een eigen IP (hier 192.168.1.21) onder OS/2 draait, kan het ook aardig zijn om het netwerkverkeer via de OS/2 PC te sluizen, die dan (met ipgate on) als router moet optreden.

[D:\]ipgate
IPGATE.EXE: to enable or disable IP forwarding on a router.
Usage:
  ipgate {on,off}

[D:\]ipgate on

Deze regels staan nog geen lokaal verkeer met de firewall toe (route only).

permit 192.168.1.21 255.255.255.255 0.0.0.0 0.0.0.0 all any 0 any 0 non-secure route both l=no f=no t=0
permit 0.0.0.0 0.0.0.0 192.168.1.21 255.255.255.255 all any 0 any 0 non-secure route both l=no f=no t=0

Door hierbij de logging tijdelijk met l=yes aan te zetten, kunt u iedere stap van Windows volgen. Dat komt later van pas als u specifieke regels opstelt. Het logbestand zal hierdoor wel enorm groeien. Ieder IP pakketje (op ethernet max 1500 bytes) van en naar het LAN wordt gelogd.

> Top <