|
|
| | |||
|
Firewalling met Free Software Najaarsconferentie 1999 van de NLUUG Fred Mobach fred@mobach.nl Echteld, 1 october 1999 Inhoudsopgave 1 Beveiliging en firewalling 2 Hoe de services te beveiligen 3 Welke beveiligingsmaatregelen ? 4 Firewalling met GNU/Linux. 5 Kernel configuratie 6 De enkelvoudige firewall 7 De firewalls met een DMZ. 8 Wat nog meer. 9 Slot Literatuur 1 Beveiliging en firewalling. Dit stuk is niet alleen bedoeld voor diegene, die goed zijn opgeleid in de technische aspecten van het Internet maar ook voor hen, die een algemene kennis hebben van het gebruik van computers in netwerkomgevingen. Wellicht dat sommige delen voor de laatsten minder duidelijk zijn, maar in dat geval kan men het mij altijd nog vragen te duiden. Voordat men beveiliging en firewalling kan gaan toepassen zou ik graag poneren dat vakmensen in de IT beveiliging eerst naar hun klanten luisteren om te horen, wat die menen nodig hebben. Dat zal de klant graag aangeven, omdat je er anders niet bij betrokken was. In veel gevallen weten klanten weinig van beveiliging af en wordt er pas over gedacht nadat de netwerkapplicatie al gebouwd is. Veelal valt daar dan ook niet meer aan te veranderen. Aan de vakman de taak om het kennisniveau wat op te krikken en de beveiliging zodanig te ontwerpen, dat de netwerkapplicatie zo goed mogelijk wordt beveiligd. Dit stuk handelt over beveiliging. Doch het handelt tevens hoe die beveiliging wordt aangeboden. Als vakman ken je vele mogelijkheden en kun je door zowel je kennis als de wensen der klant te combineren passende oplossingen aanbieden. Tracht ook het kennisniveau op het gebied van netwerken en beveiliging van het beherend personeel der klant in te schatten. Indien dat niet voldoende is biedt de klant dan tevens aan om die taken, die zijn eigen personeel nog niet kan uitvoeren, als service tijdelijk uit te voeren of wellicht permanent op basis van een abonnement. Enkele van deze services zijn het monitoren van zijn netwerkverkeer, logging analyse, bijhouden van de mailinglists, bijdetijd houden van de gebruikte software, bijhouden van de configuraties enzovoort. Je kunt aanbieden om kennis aan zijn personeel over te dragen. Het aanbieden van deze services wordt in het algemeen zeer gewaardeerd. Naast de hiervoor al geschetste zaken als software en services is er ook hardware nodig. Voor je eigen organisatie is het geen bezwaar om daarvoor al wat oudere hardware te gebruiken, die overbodig is. Enkele oudere 486 systemen kunnen dan nog goed voldoen, zolang het onderhoud daarop in eigen hand kan blijven. Maar als de te beveiligen applicaties permanent beschikbaar moeten zijn, dan betwijfel ik zo'n keus. En zeker als de hardware bij een klant moet worden opgesteld is het verstandig om eerste klas apparatuur te gebruiken met zonodig een onderhoudscontract daarbij. Zeker als je verantwoordelijk bent voor het goed werken van de firewall zul je daarmee geld besparen doordat minder tijd aan onderhoud besteed hoeft te worden. Vertrouwen is van weerskanten vereist, maar vooral de klant zal dat vertrouwen moeten hebben. Biedt daarom eventueel een onafhankelijke security audit aan, dat schept in ieder geval een basis. Het Internet is een snel groeiende bedrijvigheid geworden. Steeds meer organisaties maken bijvoorbeeld gebruik van e-mail en websites. Het opzetten en beheren daarvan kost vrij veel geld, zowel aan personeel, apparatuur, programmatuur als bandbreedte. Bedragen van enkele tonnen zijn geen uitzondering. Velen hebben natuurlijk gehoord over de problemen, die zich voordoen bij aan het Internet gekoppelde systemen. Er wordt gesproken over crackers (abusivelijk soms hackers genoemd), virussen, macro-virussen enzovoort. Belangstellenden kunnen de Bugtraq mailinglist een poosje volgen of the NTBugtraq mailinglist. Die laatste ken ik niet, want ik gebruik geen Windows. Iedereen weet dus wel iets over de verkeerde praktijken, die plaatsvinden op het Internet. Wie wil zijn aangeboden services, welke zoveel geld gekost hebben, daaraan blootstellen ? Wie wil het risico lopen niet alleen die services te verliezen - en het daarmee gemoeide geld - maar ook klanten of klanttevredenheid ? En deze risico's zijn in veel verschillende vormen aanwezig, zoals verminkte schijven of gegevens, gestopte services, illigaal gebruik van gegevens enzovoort. Daarom denk ik vaak na over beveiliging en poog anderen daar ook over na te laten denken. Dat kost tijd, maar die kosten zijn lager dan de kosten die gemoeid zijn met het verlies van gegevens of services, zoals die hierboven omschreven zijn. Beveiliging betekent het nemen van een aantal maatregelen, zoals het opstellen van servers in een beveiligde ruimte, het laten beheren door vakkundige en vertrouwde medewerkers, het beperken van de toegang tot de services en het beveiligen van de applicaties. Het betekent tevens het maken van keuzes. Uw keuzes hoeven niet dezelfde te zijn als die van mij, maar erover nadenken is plicht. Dit stuk handelt verder alleen over firewalling in samenhang met applicatiebeveiliging via proxy en relay servers. Allerlei andere aspecten, waarvan een beperkt aantal genoemd zijn, worden verder niet behandeld. 2 Hoe de services te beveiligen. Een zeer globale keuze ligt er tussen security through obscurity en Open Source security. In het eerste geval hoop je, dat niemand weet hoe het werkt. De praktijk wijst echter uit dat na verloop van enige tijd de werkwijze bekend raakt en dat is dan een reden om de werkwijze weer te veranderen. In het laatste geval van Open Source gebaseerde security ga je ervan uit dat de beveiliging werkt, omdat er zoveel mensen naar hebben gekeken en, indien er fouten in zitten, deze snel worden opgelost. Vanwege deze redenen koos ik voor op Open Source gebaseerde oplossingen, omdat die op termijn goed werken. Het gebruik van bewezen technologie, welke tevens snel is te corrigeren, mondt daarmee uit in lagere onderhoudskosten. Er zijn vele oplossingen van verschillende leveranciers beschikbaar, gebaseerd op diverse operating systems, zoals routers en software pakketten voor firewalling. Indien daarmee echter een probleem ontstaat ben je volledig afhankelijk van de snelheid, waarmee die leverancier een oplossing voor dat probleem beschikbaar stelt. En niet iedere leverancier staat bekend om zijn snelheid in deze. Soms ben je dus overgeleverd aan de goden. Binnen de wereld van Open Source zijn er nog vele mogelijkheden, waarvan GNU/Linux en de BSD's al jaren bekend zijn. Mijn keus daartussen is gebaseerd op politieke, technische en emotionele redenen. De politieke ligt op het vlak van de licentie, ik prefereer de GNU GPL boven de BSD licentie, omdat de eerste je vrijwel alle vrijheden toekent behalve de vrijheid om op basis van andermans werk een eigen versie te verkopen en anderen minder rechten toe te kennen dan jezelf hebt gekregen. De technische redenen zijn enerzijds de enorm snelle ontwikkelingen bij GNU/Linux in vergelijking tot de BSD's. Tegenwoordig is er veel kans dat een gewenste optie eerder in GNU/Linux wordt ingebouwd dan in een BSD. Anderzijds is GNU/Linux op meer platformen te gebruiken dan bijvoorbeeld FreeBSD en het is bekend, dat betekent dus een extra keuzemogelijkheid. De emotionele reden is de indruk, dat de GNU/Linux gemeenschap meer gericht is op de gebruikers dan de FreeBSD gemeenschap. Let wel, dit is mijn indruk en mijn keuze. Anderen maken hun eigen keuze.
3 Welke beveiligingsmaatregelen ? Vele beveiligingsmaatregelen vallen te nemen. Het is overbodig ze alle te nemen, maar redundancy door het toepassen van meerdere lagen is verstandig. Hoe meer lagen er in de beveiliging zitten, hoe meer tijd een indringer nodig heeft om erdoorheen te breken en toegang tot de beveiligde systemen te krijgen. De eerste beveiligingsmaatregel wordt tijdens installatie genomen en bestaat uit het scheppen van verschillende partities voor /boot, /home, /tmp en /var en eventueel ten behoeve van extra services partities voor /var/spool, /var/squid enzovoort. Zo wordt het onmogelijk het root filesysteem te vullen met bijvoorbeeld log data en mail. Vervolgens kan het read-only mounten voorkome, dat al te eenvoudig programma's als ls en ps worden overschreven door andere versies met daarin opgenomen een trojaans paard. Bovendien worden in vele directories vrij zelden wijzigingen aangebracht, in /boot meestal alleen maar bij het installeren van een nieuwe kernel. Binnenkort hoop ik een test te doen, waarbij het filesysteem op een bootable CD-ROM staat en waarbij beschrijfbare directories zoals /var en /tmp op een schijf staan. Daarmee is het introduceren van trojaanse paarden weer wat lastiger geworden. Tenslotte kunnen bij het ext2 filesystem in GNU/Linux de uitgebreide attributen worden gebruikt, welke met het chattr commando worden ingesteld. Het immutable attribuut zorgt ervoor, dat een bestand niet kan worden gewijzigd, weggegooid, de naam niet kan worden gewijzigd en geen link ernaartoe kan worden gelegd. De volgende maatregel tijdens installatie is goed voor luie mensen : installeer alleen de services op een systeem, die nodig zijn. Het spaart niet alleen schijfruimte, geheugenruimte en cpu tijd, maar wat er niet op staat valt ook niet te kraken. In principe heeft een firewall niet meer nodig dan een toegang voor remote support. Tijdens het selecteren van services geldt de stelregel dat de service die je niet kent heb je ook niet nodig. Wil je een service leren kennen, dan zijn de boeken TCP/IP Illustrated van Stevens een aanrader. Na installatie dienen de toegangsrechten der bestanden en directories nader beschouwd te worden. Sommige distributies hebben deze toegangsrechten ook in een of meer configuratiebestanden onder /etc staan. Ook die dienen gecontroleerd te worden. Zorg ervoor dat protocollen zoals X, NFS en NIS niet op deze beveiligde systemen lopen, ze zijn erg onveilig. Ook de RPC's kunnen gemist worden als kiespijn. Telnet en ftp kunnen beter niet worden gebruikt buiten het kader van een VPN zoals FreeS/WAN. Of telnet en ftp worden vervangen door SSH. Door zo een poosje door te gaan heeft de firewall zelfs geen inetd meer nodig. Alleen mijn zoon vond dat minder prettig, omdat het kraken erg lastig werd. Gebruik een apart systeem voor het loggen van de router en de overige systemen in de gedemilitariseerde zone (DMZ). Een logger met gecodeerde uitvoer is aanbevolen, omdat een cracker dan minder eenvoudig zijn sporen kan uitwissen, zelfs als die de log server heeft kunnen kraken. Het gebruik van firewalling op deze log server is aanbe-volen, waarbij alleen de log invoer, VPN of SSH, de benodigde ICMP protocollen en het protocol voor het transporteren der logs naar de beheerder worden toegelaten. Verder is er op zo'n server niets nodig. De logs behoren dagelijks gecontroleerd te worden op ongebruikelijke meldingen en patronen. Het bestuderen van het netwerkverkeer met tcpdump of een sniffer kan niet snel genoeg gestart worden, op die manier leer de uitvoer kennen en de patronen in het netwerkverkeer herkennen. Ethereal, Karpski en Sniffit kunnen hierbij goede diensten verlenen. Tripware of iets dergelijks (er zijn er meer) is aanbevolen om te herkennen, of bestanden zijn gewijzigd, die niet gewijzigd behoren te worden. Wijzigingen kunnen worden geautoriseerd door de beheerder, maar dat vergt in ieder geval actie van hem. Indien Inetd op een bepaald systeem nodig is, is het gebruik van de tcpwrappers van Wietse Venema erg verstandig, hiermee laten zich de toegang tot services op een logische wijze inperken. Een intruder detection system is het overwegen waard, zij het dat het gebruik hiervan meer studie vergt dan een firewall opzet. Zelfs een deception toolkit hoort tot de mogelijkheden, hiermee wordt op inkomend berichtenverkeer gereageerd alsof er een geheel ander operating systeem op de server afloopt dan er daadwerkelijk draait. Vooral op een zogenaamde offergeit, een in de DMZ opgenomen systeem voor de krakers, kan zo'n deception toolkit goed functioneren. Zo'n offergeit moet voor de malicieuze gebruikers een ideaal doelwit lijken, waarop zij hun krachten kunnen verspillen. Firewalling kan op verschillende manieren worden gerealiseerd. Twee scenario's zullen in de volgende paragrafen worden uitgewerkt. De eerste is een enkelvoudige firewall, waarbij een systeem zowel de firewall functie als de Network Address Translation (NAT) verzorgt. Dit is een simpele opzet met beperkte toepassingsmogelijkheden. De tweede is een complete opzet, waarbij tussen twee firewalls een DMZ is gerealiseerd, waarbij zich in de DMZ zowel een proxy / relay server als een logging systeem bevinden. Hierbij is vrijwel geen netwerkverkeer toegestaan tussen het Internet en het interne netwerk.
4 Firewalling met GNU/Linux. Voordat de twee aangekondigde situaties in detail worden behandeld worden eerst enkele algemene punten, die voor beide geldig zijn, uitgelegd. Het verveelt menigeen dezelfde tekst in tweevoud te moeten lezen en het verveelt mij het te moeten dupliceren. Als er gecommuniceerd wordt op het Internet - danwel op dezelfde wijze op het eigen LAN -, dan is er communicatie tussen een werkstation enerzijds en een server ander-zijds. Deze communicatie bestaat uit pakketten, gevuld met gegevens en voorafgegaan door een berichtenkop, die worden uitgewisseld tussen het werkstation en de server. De eerste kop van deze pakketten bevat belangrijke informatie, waaronder het source IP adres van het zendende systeem, het destination IP adres van het ontvangende systeem en het protocoltype zoals ICMP, UDP of TCP. De tweede kop bevat nadere informatie afhankelijk van het protocoltype. Bij ICMP is dat het type en de code van het bericht en bij UDP en TCP de poortnummers van het werkstation en de server. Nadere informatie geeft de man page van ipchains (bijvoorbeeld). Firewalling in GNU/Linux is simpelweg niet meer dan het laten passeren van de pak-ketten, welke daartoe toestemming hebben en het weigeren van alle andere. Dat kan ook op de tegenovergestelde wijze, namelijk alle pakketten toegang verlenen behalve degeen, die worden afgewezen, maar dat is een minder veilige methode. In de eerste situatie weet je wat je doorlaat, in de laatste alleen wat je weigert. Selectie der pakketten is mogelijk op in principe alle informatie in de koppen van de pakketten : het source IP adres, het destination IP adres, het protocol type oftewel de verlangde service, of het pakket een verbindingsopbouw betreft enzovoort. De GNU/Linux kernel serie 2.2.x kreeg een compleet nieuw systeem voor firewalling genaamd ipchains. Deze nieuwe toepassing voor firewalling biedt de mogelijkheid om pakketten te selecteren als zij binnenkomen op een netwerkinterface, wanneer zij door-gezonden worden naar een ander netwerkinterface (forwarding) en wanneer zij een netwerkinterface willen verlaten. Op deze wijze kan elk pakket op maximaal 3 plaatsen worden gefilterd.
5 Kernel configuratie Natuurlijk heeft ieder zijn eigen voorkeur voor de kernel configuratie. De gustibus non disputandum est oftewel over smaak valt niet te twisten. Hier laat ik alleen enkele instellingen zien, die ik nuttig acht. Nalaadbare modules in firewalls zijn een extra potentieel risico, reden voor mij ze bij voorkeur uit te sluiten. De kernel wordt geacht stabiel te zijn en slechts de benodigde functionaliteit te bieden. Modules kunnen door krakers worden gebruikt om hun acti-viteiten te verbergen op een zodanige wijze, dat ze nauwelijks meer traceerbaar zijn. Maar voor NAT zijn ze nodig, dus is het zaak op een systeem, dat de NAT functie verzorgt, ze mogelijk te maken. Dit zijn de kernel configuratieparameters, nodig voor firewalling # De configuratieparameters voor netwerken in een firewall zijn : 6 De enkelvoudige firewall De enkelvoudige firewall is een eenvoudig concept, waarbij er tussen het eigen netwerk en het Internet een enkel systeem wordt opgesteld, dat zorg draagt voor zowel de firewalling als de masquerading (Network Address Translation). Bij masquerading wordt de combinatie van IP adres plus poort van het werkstation in het LAN vervangen door het publieke IP adres van de firewall met een ander (hoog) poortnummer bij uitgaand verkeer, bij binnenkomend verkeer wordt de omgekeerde vertaalslag gemaakt. De verbinding met het Internet, die kan bestaan uit een analoog modem, een ISDN adapter, een ADSL modem of via een ethernet adapter bereikbare router, is geen onderwerp in deze beschouwing. Bij masquerading moet er rekening mee worden gehouden, dat bij een pakketje naar het internet het source adres tijdens de verwerking van de firewall regels op de forward chain wordt gewijzigd. Het source adres op de input en de forward chains is daarmee het adres op het interne net, op de output chain echter het vertaalde adres. Van belang is, of de Internet Service Provider een statisch of een dynamisch publiek IP adres verstrekt. Bij een statisch IP adres kan dat IP adres bij de start van het systeem aan het interface worden toegekend en het firewalling script worden gestart voor het acti-veren van het interface. Bij een dynamisch IP adres kan het script pas worden gestart nadat de verbinding tot stand is gekomen, tevens dient het IP adres als variabele aan het script te worden doorgegeven. Onthoud dat na het opbouwen van de verbinding en voor het uitvoeren van het firewalling script elk pakket zal worden doorgelaten. Een extra reden om het script te laten beginnen met een standaard politiek om pakketten te wei-geren. De opbouw van het systeem is vrij elementair, er hoeven immers maar weinig software pakketten te worden opgenomen in het systeem. De meeste distributies vragen om niet meer dan de te gebruiken taal, het type toetsenbord, het soort beeldscherm en de tijdzone. Daarnaast zijn de netwerkgegevens van belang voor de (minimaal) twee interfaces, zoals IP adres, netmask, gateway en nameserver. De standaard installatiepakketten van de meeste distributies zijn niet zo handig, omdat ze te veel pakketten installeren. Daarom is de zogenaamde custom install mode raadzaam. Al die extra pakketten betekenen namelijk alleen maar schijfvulling, extra configuratiewerk, meer kans op fouten en meer risico's. Het is van belang de schijven goed te partitioneren, niet alleen de grootte maar ook de plaats der partities is van belang, zowel vanwege de gemiddelde access tijd als vanwege de leessnelheid. Die ligt bij moderne schijven aan de buitenzijde behoorlijk hoger dan aan de binnenzijde. De volgende indeling heb ik gekozen : /dev/hda1 /boot 8 MB Enkele van de pakketten die ik verkkos te gebruiken zijn zip, bzip2, tree, tcpdump, tra-ceroute, bind-utils, ipchains, caching-nameserver, netkit-base, tcp-wrappers and mc. Hoe minder hoe beter. Veel van de standaard te starten services werden uitgeschakeld voor dezelfde reden als hiervoor genoemd. Gemeenlijk kunnen boot parameters worden opgegeven via LILO tijdens het bootproces. Door het toevoegen van twee regels met 'restricted' en 'password='anywilldo' werd deze mogelijke wijze van ongewenst gedrag ingeperkt. Na installatie is het van belang om de gecorrigeerde pakketten over de voorgaande te installeren. Door BugTraq of Linux Today te lezen kun je op de hoogte blijven van de geconstateerde problemen en de verschenen correcties. Diverse distributeurs hebben hun eigen security mailing list, waarvan sommige echter niet altijd bij de tijd zijn. Kernel configuratie is niet zo'n probleem, zelfs voor relatief nieuwe gebruikers. Ga naar de directory waar de kernel source tree staat en start 'make menuconfig'. Dat is een script met grafische vormgeving. Het gebruik van een muis is aan te bevelen, dus de muis tijdens installatie configureren en gpm laten starten tijdens het boot proces. De benodigde kernel parameters staan in paragraaf 5 beschreven. Na het compileren en linken van de kernel met 'make && make bzImage && make install && make modules && make modules_install' dienen de System.map en arch/i386/boot/bzImage in de directory /boot te worden geplaatst, het configuratiebestand /etc/lilo.conf te worden aangepast en met het commando 'lilo' het volgende bootproces te worden voorbereid. Nu is het tijd om de opbouw van de firewall te laten zien. Het is alleen maar een script, dat zo snel mogelijk gestart moet worden zodra het IP adres van het interface bekend is gemaakt met het ifconfig commando. Als je van jouw ISP een vast IP adres toegewezen hebt gekregen, zoals demon.nl doet, is het het eenvoudigst om dat firewalling script te starten door het opnemen van een link in de directory /etc/rc/rc2.d. Zorg door het doordacht kiezen van het volgnummer in S..firewall en K..firewall dat die op het gewenste punt wordt gestart danwel gestopt. Als je een IP adres dynamisch krijgt toegewezen, dient het firewalling script gestart te worden zodra dat IP adres bekendgemaakt is. Het is minder veilig dan de voorgaande situatie, maar dat ligt niet aan mij. Een deel van het firewalling script met opgenomen commentaar staat hieronder. #!/bin/bash # # procedure : firewall-start.sh # doel : starten der firewalls op de DMZ. # argumenten : geen # auteur : Fred Mobach / Mendel Mobach # datum : 15-05-1999 # # # Firewall opzet. # --------------- # # # 1. Deze firewall opzet beschrijft de toegestane communicatie via het IP # protocol tussen de volgende netwerksegmenten : # a. het interne netwerksegment bedryf.nl (172.16.21.0/24) # b. de Boze Buitenwereld (0.0.0.0/0) # c. de gedemilitariseerde zone (DMZ) met haar firewalls # (201.202.203.136/29). # d. het externe segment tussen exmuros en router 201.202.203.128/29. # # De gedemilitarieerde zone (DMZ) bestaat in de huidige opzet uit : # - exmuros : de firewall tussen de DMZ en de Boze Buitenwereld, # - sciens : de logging server, waarop alle logs worden vastgelegd, en # - servans : de algemene server. # # Deze servers dragen zorg voor de onderstaande taken. Niet alle services # zijn hier genoemd, doch alleen de voor gebruikers merkbare. # - DNS Domain Name System voor hostname resolution, # dit wordt gebruikt door : # - de proxy server squid, # - de mailserver sendmail, # - de secure shell server, enz. # - de clients van het interne netwerk bij SSL (https protocol). # - firewall de firewall draagt zorg voor het filteren van alle ongewenste # berichtenpakketten tussen alle gebruikte netwerkinterfaces. # - ftp de file transfer service wordt gebruikt ten behoeve van de # proxy service bij de communicatie tussen het interne netwerk # en de boze buitenwereld. . . . # # 2. Definities. # # actie = reactie op een firewall selectieregel : # accept # doorlaten # deny # naar de bittebak # masq # Network Address Translation # no_spoof # naar de bittebak (geen -b in ipchains) # reject # melden : niet toegestaan. # chain = controlelijst voor de firewall : # any # forward # input # output # computer = host # destination = netwerk | netwerkinterface # host = computer : # exmuros = externe firewall # sciens = logging server # servans = algemene server # router = ISDN router # netwerk = bijeenbehorende groep van computers : # BB = 0.0.0.0/0 # DMZ = 201.202.203.136/29 # Extern = 201.202.203.128/29 # Intern = 172.16.21.0/24 # netwerkinterface = een soft- of hardware interface voor binding aan een # netwerk : # exmuros 201.202.203.137 # inmuros aan de zijde DMZ # exmuros2 201.202.203.130 # inmuros aan de zijde extern # local 127.0.0.1 # local loopback # sciens 201.202.203.139 # servans 201.202.203.138 # router 201.202.203.129 # opbouw = soort bericht : # any : alles # new : verbindingsopbouw # reply : bericht voor bestaande verbinding # poorten = TCP of UDP protocol : # ftp 21/tcp file transfer protocol # telnet 23/tcp TELetype NETwork remote login # ssh 22/tcp secure shell # ssh 22/udp secure shell # smtp 25/tcp mail # domain 53/tcp nameserver / name-domain server # domain 53/udp nameserver # www 80/tcp http WorldWideWeb HTTP # www 80/udp http HyperText Transfer Protocol . . . # protocol = soort IP protocol : # any # ICMP # TCP # UDP # source = netwerk | netwerkinterface # BB=0.0.0.0/0 # Netwerken. DMZ=201.202.203.136/29 # Extern=201.202.203.128/29 # Intern=172.16.21.0/24 # exmuros=201.202.203.137 # exmuros aan de zijde DMZ exmuros2=201.202.203.130 # exmuros aan de zijde extern local=127.0.0.1 # local loopback sciens=201.202.203.139 # servans=201.202.203.138 # router=201.202.203.129 # Routers="172.16.21.73 172.16.21.203" Servers="172.16.21.200 172.16.21.211" # # Alle netwerk- en broadcast adressen : # Extern DMZ Intern Trans # Networks="201.202.203.128 201.202.203.136 172.16.21.0 192.168.2.0" Broadcast="201.202.203.135 201.202.203.143 172.16.21.255 192.168.2.255" # PROG="ipchains" # # Alle in ipchains.c bekende ICMP typen en codes. # echo_reply=0 destination_unreachable=3 network_unreachable=0 host_unreachable=1 . . . # # ff fun laden . /root/procs/fun # de functie, die commando's opbouwd en uitvoerd. # # # 3. Services op de servers. # # Hieronder staan per service de datastromen tussen de netwerksegmenten c.q. # de netwerkcomponenten aangegeven. Hier staan alle gebruikte services, ook # degene, die voor gebruikers niet zichtbaar zijn. # # Toegevoegd dienen nog te worden : # - VPN vanuit extern naar exmuros, en # - alle services via VPN naar exmoros en DMZ. # # De onderstaande beschrijvingen bevatten per protocol : # - een beknopte omschrijving van het protocol, # - de toegestane logische datastromen, en # - de firewall regels. # De firewall regels bestaan uit (zie ook de definities) : # - hostnaam, # - netwerkinterface, # - protocol, # - poort, # - source, # - destination, # - chain, # - opbouw, # - actie. # # Eerst worden de bestaande chains leeggemaakt en de default # policy ingesteld. # $PROG -F $PROG -X $PROG -P input REJECT $PROG -P output REJECT # be sure logs will be send (maar niet op deze wijze). $PROG -P forward REJECT # # We weigeren elk pakket met een netwerk- of broadcastadres. # Daarmee zijn ook smurf amplifier attacks onmogelijk geworden. # for I in $Networks do fun exmuros $exmuros2 any 1:65535 $BB $I input any deny done for I in $Broadcast do fun exmuros $exmuros2 any 1:65535 $BB $I input any deny done # # Nu weigeren we tcp en udp pakketten met een source = DMZ of intern op de # exmuros2 en met source = DMZ of extern of transnet op de inmuros2. # Ook alle private Ip adressen worden op exmuros2 geblokkeerd. # IP spoofing is daarmee onmogelijk geworden. # fun exmuros $exmuros2 tcp 1:65535 $Intern $BB input any no_spoof fun exmuros $exmuros2 tcp 1:65535 $DMZ $BB input any no_spoof fun exmuros $exmuros2 tcp 1:65535 10.0.0.0/8 $BB input any no_spoof fun exmuros $exmuros2 tcp 1:65535 172.16.0.0/12 $BB input any no_spoof fun exmuros $exmuros2 tcp 1:65535 192.168.0.0/16 $BB input any no_spoof # fun exmuros $exmuros2 udp 1:65535 $Intern $BB input any no_spoof fun exmuros $exmuros2 udp 1:65535 $DMZ $BB input any no_spoof fun exmuros $exmuros2 udp 1:65535 10.0.0.0/8 $BB input any no_spoof fun exmuros $exmuros2 udp 1:65535 172.16.0.0/12 $BB input any no_spoof fun exmuros $exmuros2 udp 1:65535 192.168.0.0/16 $BB input any no_spoof # # fun inmuros $inmuros2 tcp 1:65535 $Extern $BB input any no_spoof # fun inmuros $inmuros2 tcp 1:65535 $DMZ $BB input any no_spoof # fun inmuros $inmuros2 tcp 1:65535 $Trans $BB input any no_spoof # # fun inmuros $inmuros2 udp 1:65535 $Extern $BB input any no_spoof # fun inmuros $inmuros2 udp 1:65535 $DMZ $BB input any no_spoof # fun inmuros $inmuros2 udp 1:65535 $Trans $BB input any no_spoof # # Ook de productie servers mogen niet met de DMZ praten ! # En de routers alleen via het RIP protocol. # #for I in $Servers # do # fun inmuros $inmuros2 tcp 1:65535 $I $BB input any deny # fun inmuros $inmuros2 udp 1:65535 $I $BB input any deny #done #for I in $Routers # do # fun inmuros $inmuros2 tcp 1:65535 $I $BB input any deny # fun inmuros $inmuros2 udp '! route' $I $BB input any deny #done # # De localhost mag op de localhost alles doen, overal en altijd ! # fun exmuros localhost any ' ' $BB $BB any any accept # fun inmuros localhost any ' ' $BB $BB any any accept fun sciens localhost any ' ' $BB $BB any any accept fun servans localhost any ' ' $BB $BB any any accept # # ICMP Internet Control Message Protocol # Deze draagt ondermeer pingberichten en foutmeldingen. # Andere, zoals Redirect, kunnen beter worden uitgefilterd. # # Regels : # # De buitenwereld mag / mag niet : # fun exmuros $exmuros2 icmp " " $echo_reply " " input any accept fun exmuros $exmuros2 icmp " " $echo_reply " " output any accept . . . # # De binnenwereld mag / mag niet : # # fun inmuros $inmuros2 icmp " " " " " " input any accept # fun inmuros $inmuros2 icmp " " " " " " output any accept # # De DMZ mag / mag niet : # fun exmuros $exmuros icmp " " " " " " input any accept fun exmuros $exmuros icmp " " " " " " forward any accept fun exmuros $exmuros icmp " " " " " " output any accept . . . # # # FTP File Transfer protocol (21/TCP) # ftp vanaf de DMZ naar de Boze buitenwereld. # # T.b.v. de zogenaamde passive mode (vaak in browsers) : # # start : intern -> inmuros -> servans # reply : servans -> inmuros -> intern # # Regels : # fun inmuros $inmuros2 tcp ftp $Intern $servans input any accept # fun inmuros $inmuros tcp ftp $Intern $servans forward any accept # fun inmuros $inmuros tcp ftp $Intern $servans output any accept fun servans $servans tcp ftp $Intern $servans input any accept # fun servans $servans tcp ftp $servans $Intern output any accept # fun inmuros $inmuros tcp ftp $servans $Intern input any accept # fun inmuros $inmuros tcp ftp $servans $Intern forward any accept # fun inmuros $inmuros2 tcp ftp $servans $Intern output any accept # # start : servans -> exmuros -> extern # reply : extern -> exmuros -> servans # # Regels : fun servans $servans tcp ftp $servans $BB output any accept fun exmuros $exmuros tcp ftp $servans $BB input any accept fun exmuros $exmuros tcp ftp $servans $BB forward any accept fun exmuros $exmuros2 tcp ftp $servans $BB output any accept # # Opbouw nieuw data kanaal naar buiten. # Regels : fun servans $servans tcp 1024: $servans $BB output any accept fun exmuros $exmuros tcp 1024: $servans $BB input any accept fun exmuros $exmuros tcp 1024: $servans $BB forward any accept fun exmuros $exmuros2 tcp 1024: $servans $BB output any accept # # # # TELNET TELetype NETwork remote login protocol (23/TCP) # telnet voor remote configuratie van news, routers etc. # # T.b.v. de router configuratie in het externe netwerk : # Tevens verkeer naar de wereld. # # start : servans -> exmuros -> extern # reply : extern -> exmuros -> servans # # Regels : fun servans $servans tcp telnet $servans $BB output any accept fun exmuros $exmuros tcp telnet $servans $BB input any accept fun exmuros $exmuros tcp telnet $servans $BB forward any accept fun exmuros $exmuros2 tcp telnet $servans $BB output any accept
7 De firewalls met een DMZ. Dit begint er op te lijken. Zoals in het diagram op de volgende bladzijde getoond wordt, bestaat deze DMZ met firewalls uit vier systemen, drie ervan waren systemen met een Pentium 133 MHz, 16 MB RAM, 1 GB IDE schijf en voldoende ethernet kaarten. De vierde had een Pentium 200 MHz, 64 MB RAM en een SCSI schijf van 9 GB. Een korte beschrijving der systemen : exmuros is de buitenste firewall, verbonden aan zowel het netwerksegment met de Internet router aan de ene zijde en de DMZ aan de andere zijde, offerans is de proxy en relay server in de DMZ, notans is de logging server in de DMZ, inmuros is de binnenste firewall, verbonden enerzijds aan de DMZ en aan de binnenkant aan twee verschillende netwerksegmenten (prodnet en testnet). Vragen over de hostnamen ? Van de ISP kregen we een C klasse reeks IP adressen, welke we splitsten in enkele subsegmenten. Daarom diende het netwerk masker en de routing tabel in de Internet router te worden aangepast. Dat kostte overigens wel wat tijd om aan de ISP uit te leggen. Een van deze segmenten werd gebruikt voor het deel tussen Internet router en exmuros, een ander deel voor de DMZ. Op de offerans werden enkele proxy en relay services geplaatst. Dat waren DNS voor de systemen in de DMZ en in de LAN's, NTP voor dezelfde systemen, mail voor de mailserver in het LAN, een squid proxy voor enkele aparte pc's in de DMZ en een webserver proxy voor een webserver in het LAN. De proxyservers zorgen ervoor, dat elk inkomend IP pakket vanaf het Internet - door mij vaak de Boze Buitenwereld genoemd - niet tot het LAN kan doordringen. Alle in GNU/Linux ingebakken controles van de TCP/IP stack op IP pakketten worden op die pakketten losgelaten. Elk pakket vanaf het Internet met private IP adres als source of destination adres wordt door de firewall weggegooid. Defragmentering zorgt voor het opschonen van menig misvorm pakket.Vele aanvallen worden zo al onmogelijk gemaakt. Met behulp van een schema van de netwerktopologie en daarin opgenomen de toege-stane berichtenstromen werd bepaald hoe het firewall script diende te werken. Dit schema werd vertaald naar een geformaliseerde documentatie, die was tevens de basis voor het script. De opgenomen formele beschrijvingen werden vervolgens vertaald naar een functie-aanroep; in die functie werd tenslotte het ipchains commando opgebouwd en uitgevoerd.
De hier gebruikte topologie biedt vele (redundante) mogelijkheden voor het filteren van IP pakketten, zoals je kunt zien wanneer de een pakket volgt op zijn weg vanuit het Internet naar het LAN. Dat pakket moet eerst de standaard TCP/IP controles van de kernel en vervolgens de input chain, de forwarding chain en de output chain op de exmuros, de buitenste firewall, doorlopen. Vervolgens moet het worden geaccepteerd door de input chain op de offerans teneinde de proxy of relay server daarop te bereiken. Die server zal dan een pakket gaan verzenden via de output chain op de offerans naar de server op het LAN, maar het pakket dient dan nog eerst de input, forward en output chain op de inmuros, de binnenste firewall, te doorlopen. Daarmee heeft een pakket in totaal 8 filters te passeren, alvorens de data vanuit het Internet tot een bepaalde server op het LAN kan doordringen. Hoezo redundant ? Het is niet te weinig, maar dat is bij beveiliging op zich niet verkeerd. Hieronder een korte opgave van de gebruikte proxy services. Sendmail. De default configzorgt voor het relay mail server probleem. De reply functie voor buitenstaanders is daarbij niet toegestaan en zo hoort dat ook. Na het vastleggen van enkele aliassen worden diverse berichten naar mijn eigen kantoor gezonden en dat werkt prettig. Apache. Squid DNS rinetd Met rinetd is het eenvoudig om verkeer door de firewalls heen te laten gaan vanaf het Internet naar een intern netwerk. Op de proxyserver wordt een combinatie van van IP adres en poortnummer vertaald naar een andere combinatie. Dit kan ook met ipchains, het verschil is dat ipchains loopt in kernel space en rinetd in user space. Het script voor de firewalling heeft in principe dezelfde structuur als in de eerste situatie, het is alleen nog wat langer omdat er meer systemen en interfaces in staan be-schreven. Als men belangstelling voor deze scripts heeft kan men mij dat berichten. 8 Wat nog meer. Natuurlijk is het werk hiermee niet klaar. Volgende versies van dit geschrift zijn dan ook te verwachten. Er ligt nog veel werk in de vorm van nadenken, onderzoek en testen te wachten. Enkele gedachten zijn hieronder vast vermeld. Elk van deze onderwerpen vraagt om een uitgebreide publicatie en aansluitende discussie. Als een ander het niet doet, dan kunt u nog wat van mij tegemoetzien. Encrypted filesystems. Deze zijn bedoeld om anderen geen inzage te geven in de inhoud van de schijven. Maar zodra een kraker een shell tot zijn beschikking heeft kan die gewoon zijn gang gaan en is deze beveiliging dus nutteloos. Dit helpt alleen tegen ongewenste toegang voor digenen, die een fysieke toegang tot de systemen hebben. Het nut hiervan is daarom twijfelachtig. Kernel modules. Bij voorkeur zou het gebruik van kernel modules onbenut moeten worden gelaten, daar het een extra inbraakrisico met zich meebrengt. Hiermee kunnen krakers immers op een perfecte en simpele wijze hun aanwezigheid verbergen op een nauwelijks te traceren manier. Maar soms zijn ze gewoon nodig, zoals toen ik drie 3C509B ethernet kaarten in de inmuros nodig had. Die kon ik niet aan de praat krijgen, als het module daarvoor statisch in de kernel was gelinked. Het werd ook duidelijk waarom na het lezen van het source van dat module. Sommige andere modules, zoals voor masquerading, kunnen zelfs nooit statisch worden gelinked, zij dienen altijd te worden nageladen. Read-only filesystems. Het voordeel van read-only filesystems is hierboven reeds vermeld. Het gebruik van een CD-ROM eenheid heeft echter de nadelen zowel een extra apparaat nodig te hebben als de inherente traagheid daarvan. Het gebruik van flash-roms is op zich mogelijk, gezien de beperkte ruimte, die nodig is. Remote support. Onderzoek naar SSH (secure shell) en VPN's zoals FreeS/WAN en CIPE. SSH, dat op zich vrij goed werkt, heeft zijn licentie als nadeel : het is geen Open Source. FreeS/WAN is dat wel, maar loopt momenteel alleen op de kernel 2.0.36. CIPE moet ik nog naar gaan kijken. Intrusion detection. Een gebied met valkuilen is dit. Zonder meer elke inbreker via zijn IP adres uitsluiten is niet verstandig vanwege mogelijke spoofing, omdat het dan in een fraaie Denial of Service (DoS) ontaard. Om dezelfde reden is terugpesten nog veel erger, onschuldigen kunnen er het slachtoffer van worden. Hier zal ik nog wel een tijd mee bezig blijven. Denial of Services aanvallen. Dit is een ontzettend uitgebreid gebied, waarin veel varianten op hetzelfde thema voorkomen : het blokkeren van de functionaliteit van servers. Een voorbeeld is het vele malen snel achter elkaar openen van een verbinding naar een service zoals telnet of ftp. Er zijn maatregelen tegen te treffen door bijvoorbeeld xinetd in combinatie met de tcp wrappers in te zetten, maar er verschijnen steeds nieuwe varianten. Geen reden om de werkloosheid te vrezen. Virtuele IP adressen Met vrituele IP adressen is het mogelijk om per netwerkinterface tot 256 extra IP adressen aan dat interface toe te kennen. Op deze wijze wordt multihomed hosting eenvoudig gemaakt. Het commando om dit te bereiken is ifconfig, bijvoorbeeld ifconfig eth0:nnn 172.16.21.111 broadcast 172.16.21.255 netmask 255.255.255.0 up Hierin kan nnn de waarden 0 tot met met 255 hebben. Mochten de adressen niet alle in hetzelfde netwerksegment zitten, dan dient de route tabel bijgewerkt te worden. 9 Slot Tot slot wordt ieder uitgenodigd om zijn op- en aanmerkingen aan mij te richten via electronische post. Het adres daarvan is fred@mobach.nl. In het algemeen beantwoord ik die post, maar op schimpscheuten reageer ik liever niet, want dan sterven die des te sneller uit. Mocht iemand de behoefte gevoelen om eens rond te kijken in een omgeving, waarin met deze materie wordt geexperimenteerd, dan is men van harte welkom, maar wel op afspraak. Welzeker rust er een copyright op deze informatie, maar zoals al te verwachten is, is dat een zeer vrijgevig copyright. Alle informatie in dit geschrift mag vrijelijk worden vermenigvuldigd, zolang dat gebeurt met het opnemen van dit copyright en de auteur. Tevens dient bij dat vermenigvuldigen alleen gebruik gemaakt te worden van open standaards, zoals die zijn vastgesteld en vastgelegd op de website van Debian. Daarmee is vermenigvuldiging via bijvoorbeeld ASCII, HTML, XML en Postscript toegestaan, maar via niet gepubliceerde protocollen zoals van Microsoft Word uitdrukkelijk verboden. Evenzo wordt het gebruik van JPEG en PNG aanbevolen, maar GIF ontraden. Dit alles in de hoop, dat het gebruik van die ongewenste geheim gehouden protocollen uiteindelijk zal uitsterven en wij daardoor niet meer geplaagd zullen worden. Literatuur. Enkele aan te bevelen boeken zijn - Building Internet Firewalls door D. Brent Chapman en Elizabeth D. Zwicky, O'Reilly & Associates, Inc. 1995 - TCP/IP Illustrated, 3 delen door W. Richard Stevens, Addison-Wesley 1994 - TCP/IP Network Administration door Craig Hunt, O'Reilly & Associates, Inc. 1998 - DNS and BIND door Paul Albitz en Cricket Liu, O'Reilly & Associates, Inc. 1997 - Sendmail door Bryan Costales met Eric Allman, O'Reilly & Associates, Inc. 1997 - c't magazine nummer 17/99 van augustus 1999, Hans Heise Verlag - Linux Today, secite security - Linux Weekly News, sectie security - BugTraq mailinglist De drie laatste bronnen bevatten vele links naar websites met voortreffelijke informatie over beveiliging, teveel om hier op te nemen. |
|
