In dit hele document gebruiken we
vette tekst om te verwijzen naar een
commando of applicatie en een monospaced
lettertype om te verwijzen naar specifieke commando's.
Protocollen staan vermeld in een normaal lettertype. Dit
typografische onderscheid is zinvol omdat bijvoorbeeld ssh
zowel een protocol als een commando is.
In de volgende onderdelen behandelen we de methodes uit de vorige paragraaf om een FreeBSD-systeem te beveiligen.
Om te beginnen: doe geen moeite om medewerkersaccounts
te beveiligen als de root
account niet
beveiligd is. Op de meeste systemen heeft de
root
account een wachtwoord. Als eerste
moet aangenomen worden dat dit wachtwoord
altijd gecompromitteerd is. Dit betekent
niet dat het wachtwoord verwijderd moet worden. Het wachtwoord
is namelijk bijna altijd nodig voor toegang via het console van
de machine. Het betekent wel dat het niet mogelijk gemaakt
moet worden om het wachtwoord te gebruiken buiten het console
om en mogelijk zelfs niet via het su(1) commando. Pty's
moeten bijvoorbeeld gemarkeerd staan als onveilig
(“insecure”) in het bestand
/etc/ttys
zodat direct aanmelden met
root
via telnet
of rlogin
niet wordt toegestaan. Als andere
aanmelddiensten zoals sshd gebruikt
worden, dan hoort direct aanmelden via
root
uitgeschakeld staat. Dit kan door
het bestand /etc/ssh/sshd_config
te
bewerken en ervoor te zorgen dat
PermitRootLogin
op no
staat. Dit moet gebeuren voor iedere methode van toegang
– diensten zoals FTP worden vaak over het hoofd gezien.
Het direct aanmelden van root
hoort alleen
te mogen via het systeemconsole.
Natuurlijk moet een systeembeheerder de mogelijkheid hebben
om root
te worden. Daarvoor kunnen een
paar gaatjes geprikt worden. Maar dan moet ervoor gezorgd
worden dat er voor deze gaatjes extra aanmelden met een
wachtwoord nodig is. Eén manier om
root
toegankelijk te maken is door het
toevoegen van de juiste medewerkersaccounts aan de
wheel
groep (in
/etc/group
). De medewerkers die lid zijn
van de groep wheel
mogen
su
–en naar root
.
Maak medewerkers nooit “native” lid van de groep
wheel
door ze in de groep
wheel
te plaatsen in
/etc/group
. Medewerkersaccounts horen lid
te zijn van de groep staff
en horen dan
pas toegevoegd te worden aan de groep
wheel
in het bestand
/etc/group
. Alleen medewerkers die ook
echt toegang tot root
nodig hebben horen
in de groep wheel
geplaatst te worden.
Het is ook mogelijk, door een autenticatiemethode als Kerberos
te gebruiken, om het bestand .k5login
van
Kerberos in de root
account te gebruiken
om een ksu(1) naar root
toe te staan
zonder ook maar iemand lid te maken van de groep
wheel
. Dit is misschien wel een
betere oplossing, omdat het
wheel
-mechanisme het nog steeds mogelijk
maakt voor een inbreker root
te breken als
de inbreker een wachtwoordbestand te pakken heeft gekregen en
toegang kan krijgen tot één van de
medewerkersaccounts. Hoewel het instellen van het
wheel
-mechanisme beter is dan niets, is
het niet per se de meest veilige optie.
Om een account volledig op slot te zetten, dient het commando pw(8) gebruikt te worden:
#
pw lock staff
Dit voorkomt dat de gebruiker zich aanmeldt via enig mechanisme, inclusief ssh(1).
Een andere manier om toegang tot accounts te blokkeren is om
het versleutelde wachtwoord door een enkel
“*
”-karakter te vervangen. Dit
karakter zal nooit overeenkomen met het versleutelde wachtwoord
en dus gebruikerstoegang blokkeren. Het volgende
medewerkersaccount bijvoorbeeld:
foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
zou veranderd moeten worden in:
foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh
Dit voorkomt dat de gebruiker foobar
zich aanmeldt met conventionele methoden. Deze methode om
toegang te beperken werkt niet op sites die
Kerberos gebruiken of in situaties
waarin de gebruiker met ssh(1) sleutels heeft
geïnstalleerd.
Deze beveiligingsmechanismen hebben ook als uitgangspunt dat vanaf een zwaarder beveiligde machine wordt aangemeld op een minder beveiligd systeem. Als een hoofdserver bijvoorbeeld allerlei servers draait, zou het werkstation er geen moeten draaien. Om een werkstation redelijk veilig te laten zijn, dienen er zo min mogelijk servers op te draaien, bij voorkeur zelfs geen en er zou een schermbeveiliging met wachtwoordbeveiliging op moeten draaien. Maar als een aanvaller fysieke toegang heeft tot een werkstation, dan kan hij elke beveiliging die erop is aangebracht omzeilen. Dit probleem dient echt overwogen te worden, net als het feit dat de meeste aanvallen van een afstand plaatsvinden, via het netwerk, door mensen die geen fysieke toegang hebben tot werkstations of servers.
Het gebruik van iets als Kerberos geeft de mogelijkheid om het wachtwoord van de account van een medewerker buiten gebruik te stellen of te wijzigen op één plaats, waarbij het meteen actief is op alle machines waarop die medewerker een account heeft. Als de account van een medewerker gecompromitteerd raakt, moet vooral de mogelijkheid om per direct het wachtwoord voor machines te kunnen aanpassen niet onderschat worden. Met afzonderlijke wachtwoorden kan het veranderen van wachtwoorden op N systemen een puinhoop worden. Met Kerberos kunnen ook wachtwoordrestricties opgelegd worden: het is niet alleen mogelijk om een Kerberos “ticket” na een bepaalde tijd te laten verlopen, maar het Kerberos systeem kan afdwingen dat de gebruiker na een bepaalde tijd een nieuw wachtwoord kiest (na bijvoorbeeld een maand).
Een voorzichtige systeembeheerder draait alleen die servers
die nodig zijn, niets meer, niets minder. Bedenk dat
servers van derde partijen vaak de meeste neiging hebben tot
het vertonen van bugs. Zo staat bijvoorbeeld het draaien van
een oude versie van imapd of
popper gelijk aan het weggeven van
de root
account aan de hele wereld. Draai
nooit een server die niet zorgvuldig is onderzocht. Veel
servers hoeven niet te draaien als root
.
Zo kunnen de ntalk,
comsat en
finger daemons bijvoorbeeld draaien
in speciale gebruikerszandbakken
(“sandboxes”). Een zandbak
is niet perfect, tenzij er heel veel moeite gedaan wordt, maar
de meerlagenbenadering blijft bestaan: als iemand via een
server die in een zandbak draait weet in te breken, dan moeten
ze eerst nog uit de zandbak komen. Hoe groter het aantal lagen
is waar een inbreker doorheen moet, hoe kleiner de kans op
succes is. root
gaten zijn historisch
gezien aanwezig geweest in vrijwel iedere server die ooit als
root
gedraaid heeft, inclusief de
basisservers van een systeem. Op een machine waarop mensen
alleen aanmelden via sshd en nooit
via telnetd of
rshd of
rlogind dienen die servers
uitgeschakeld te worden!
FreeBSD draait ntalkd,
comsat en
finger tegenwoordig standaard in een
zandbak. Een ander programma dat misschien beter in een
zandbak kan draaien is named(8). In
/etc/defaults/rc.conf
staat als commentaar
welke parameters er nodig zijn om
named in een zandbak te draaien.
Afhankelijk van of het een nieuwe systeeminstallatie of het
bijwerken van een bestaand systeem betreft, worden de speciale
gebruikersaccounts die bij die zandbakken horen misschien niet
geïnstalleerd. Een voorzichtige systeembeheerder
onderzoekt en implementeert zandbakken voor servers waar dat
ook maar mogelijk is.
Er zijn een aantal diensten die vooral niet in een zandbak
draaien: sendmail,
popper,
imapd,
ftpd en andere. Voor sommige
servers zijn alternatieven, maar dat kost misschien meer tijd
dan er te besteden is (gemak dient de mens). Het kan voorkomen
dat deze servers als root
moeten draaien
en dat er vertrouwd moet worden op andere mechanismen om een
inbraak via die servers te detecteren.
De andere grote mogelijkheid voor root
gaten in een systeem zijn de suid-root en sgid-binaire
bestanden die geïnstalleerd zijn op een systeem. Veel van
die bestanden, zoals rlogin, staan in
/bin
,
/sbin
,
/usr/bin
of
/usr/sbin
. Hoewel het niet 100%
veilig is, mag aangenomen worden dat de suid- en sgid-binaire bestanden
van een standaardsysteem redelijk veilig zijn. Toch worden er
nog wel eens root
gaten gevonden in deze
bestanden. Zo is er in 1998 een root
gat
gevonden in Xlib
waardoor
xterm (die normaliter suid is)
kwetsbaar bleek. Een voorzichtige systeembeheerder kiest voor
“better to be safe than sorry” door de
suid-bestanden die alleen medewerkers hoeven uit te voeren aan
een speciale groep toe te wijzen en de suid-bestanden die
niemand gebruikt te lozen (chmod 000
). Een
server zonder monitor heeft normaal gezien
xterm niet nodig. Sgid-bestanden
kunnen bijna net zo gevaarlijk zijn. Als een inbreker een
sgid-kmem stuk kan krijgen, dan kan hij wellicht
/dev/kmem
lezen en dus het gecodeerde
wachtwoordbestand, waardoor mogelijk ieder account met
een wachtwoord besmet is. Een inbreker toegang tot de groep
kmem
kan krijgen, zou bijvoorbeeld mee
kunnen kijken met de toetsaanslagen die ingegeven worden via de
pty's, inclusief die pty's die gebruikt worden door gebruikers
die via beveiligde methodes aanmelden. Een inbreker die
toegang krijgt tot de groep tty
kan naar
bijna alle tty's van gebruikers schrijven. Als een gebruiker
een terminalprogramma of een terminalemulator met een
toetsenbordsimulatieoptie draait, dan kan de inbreker in
potentie een gegevensstroom genereren die ervoor zorgt dat de
terminal van de gebruiker een commando echot, dat dan wordt
uitgevoerd door die gebruiker.
Gebruikersaccounts zijn gewoonlijk het meest lastig om te beveiligen. Hoewel er allerlei draconische maatregelen genomen kunnen worden met betrekking tot de medewerkers en hun wachtwoorden “weggesterd” kunnen worden, gaat dat waarschijnlijk niet lukken met de gewone gebruikersaccounts. Als er toch voldoende vrijheid is, dan prijst de beheerder zich gelukkig en is het misschien toch mogelijk de accounts voldoende te beveiligen. Als die vrijheid er niet is, dan moeten die accounts gewoon netter gemonitord worden. Het gebruik van ssh en Kerberos voor gebruikersaccounts is problematischer vanwege het extra beheer en de ondersteuning, maar nog steeds een prima oplossing in vergelijking met een versleuteld wachtwoordbestand.
De enige echte oplossing is zoveel mogelijk wachtwoorden
wegsterren en ssh
of Kerberos gebruiken voor toegang
tot die accounts. Hoewel een gecodeerd wachtwoordbestand
(/etc/spwd.db
) alleen gelezen kan worden
door root
, is het wel mogelijk dat een
inbreker leestoegang krijgt tot dat bestand zonder dat de
aanvaller root-schrijftoegang krijgt.
Beveiligingsscripts moeten altijd controleren op en rapporteren over wijzigingen in het wachtwoordbestand (zie ook Bestandsintegriteit Controleren hieronder).
Als een aanvaller toegang krijgt tot
root
dan kan hij ongeveer alles, maar er
zijn een paar slimmigheidjes. Zo hebben bijvoorbeeld de meeste
moderne kernels een ingebouwd pakketsnuffelstuurprogramma
(“packet sniffing”). Bij FreeBSD is dat het
bpf
apparaat. Een inbreker zal in het
algemeen proberen een pakketsnuffelaar te draaien op een
gecompromitteerde machine. De inbreker hoeft deze mogelijkheid
niet te hebben en bij de meeste systemen is het niet verplicht
het bpf
apparaat mee te
compileren.
Maar zelfs als het bpf
apparaat is uitgeschakeld, dan zijn er nog
/dev/mem
en
/dev/kmem
. De inbreker kan namelijk nog
schrijven naar ruwe schrijfapparaten. En er is ook nog een
optie in de kernel die modulelader (“module
loader”) heet, kldload(8). Een ondernemende
inbreker kan een KLD-module gebruiken om zijn eigen
bpf
-apparaat of een ander
snuffelapparaat te installeren in een draaiende kernel. Om
deze problemen te voorkomen, moet de kernel op een hoger
veiligheidsniveau draaien, ten minste securelevel 1.
Het veiligheidsniveau van de kernel kan op een aantal
manieren worden ingesteld. De eenvoudigste manier om het
veiligheidsniveau van een draaiende kernel te verhogen is met
sysctl
op de kernelvariabele
kern.securelevel
:
#
sysctl kern.securelevel=1
Standaard start de kernel van FreeBSD op met een
veiligheidsniveau van -1. Het veiligheidsniveau blijft -1
tenzij het is veranderd, òfwel door de beheerder
òfwel door init(8) vanwege een instelling in de
opstartscripts. Het veiligheidsniveau kan tijdens het opstarten
van het systeem verhoogd worden door de variabele
kern_securelevel_enable
op
YES
te zetten in het bestand
/etc/rc.conf
, en de waarde van de variabele
kern_securelevel
op het gewenste
veiligheidsniveau in te stellen.
Het standaard veiligheidsniveau van een FreeBSD-systeem direct nadat de opstartscripts zijn uitgevoerd is -1. Dit wordt “onveilige modus” genoemd omdat de onveranderlijke bestandsvlag uitgezet kan worden, er van/naar alle apparaten mag worden gelezen en geschreven, enzovoorts.
Als eenmaal het veiligheidsniveau op 1 of een hogere waarde is ingesteld, worden de alleen-toevoegen en onveranderlijke bestanden gehonoreerd, deze kunnen niet worden uitgezet, en wordt toegang tot rauwe apparaten ontzegd. Hogere niveaus beperken nog meer bewerkingen. Lees, voor een volledige beschrijving van het effect van de verschillende veiligheidsniveaus, de handleidingpagina security(7).
Het ophogen van het veiligheidsniveau naar 1 of hoger kan
enkele problemen met X11 (toegang tot
/dev/io
zal worden geblokkeerd), of met
de installatie van FreeBSD wanneer die vanaf de broncode is
gebouwd (het gedeelte installword
van
het proces moet tijdelijk de alleen-toevoegen en
onveranderlijke vlaggen van sommige bestanden uitzetten), en
met enkele andere gevallen veroorzaken. Soms, zoals het geval
is met X11, is het mogelijk om dit te omzeilen door
xdm(1) behoorlijk vroeg in het opstartproces te starten,
wanneer het veiligheidsniveau nog laag genoeg is.
Omzeilmethoden zoals deze zijn misschien niet voor alle
veiligheidsniveaus of voor alle beperkingen die ze opleggen
mogelijk. Wat vooruit plannen is een goed idee. Het is
belangrijk om de beperkingen die door elk veiligheidsniveau
worden opgelegd te begrijpen omdat ze het gebruiksgemak van
het systeem sterk verminderen. Het vergemakkelijkt ook het
kiezen van eens standaardinstelling en voorkomt allerlei
verassingen.
Als het veiligheidsniveau van de kernel naar 1 of hoger
wordt verhoogd, kan het nuttig zijn om de vlag
schg
aan te zetten voor kritieke
opstartprogramma's, mappen, en scriptbestanden (i.e., alles dat
gedraaid wordt tot het punt waar het veiligheidsniveau wordt
ingesteld). Dit kan overdreven zijn, en het bijwerken van het
systeem is veel moeilijker wanneer het op een hoog
veiligheidsniveau werkt. Een minder beperkend compromis is om
het systeem op een hoger veiligheidsniveau te draaien maar het
aanzetten van de vlag schg
voor elk
systeembestand en -map onder de zon over te slaan. Een andere
mogelijkheid is om /
en
/usr
simpelweg als alleen-lezen
aan te koppelen. Het dient opgemerkt te worden dat het te draconisch
zijn over wat is toegestaan het belangrijke detecteren van een
inbraak kan verhinderen.
Als puntje bij paaltje komt kan de kern van een systeem
maar tot een bepaald punt beveiligd worden zonder dat het
minder prettig werken wordt. Zo werk het zetten van de
schg
bit met chflags
op
de meeste bestanden in /
en
/usr
waarschijnlijk averechts,
omdat, hoewel de bestanden beschermd zijn, ook het venster waarin
detectie plaats kan vinden is gesloten. De laatste laag van
beveiliging is waarschijnlijk de meest belangrijke: detectie.
Alle overige beveiliging is vrijwel waardeloos (of nog erger:
geeft een vals gevoel van beveiliging) als een mogelijke inbraak
niet gedetecteerd kan worden. Een belangrijk doel van het
meerlagenmodel is het vertragen van een aanvaller, nog meer dan
hem te stoppen, om hem op heterdaad te kunnen betrappen.
De beste manier om te zoeken naar een inbraak is zoeken naar gewijzigde, ontbrekende of onverwachte bestanden. De beste manier om te zoeken naar gewijzigde bestanden is vanaf een ander (vaak gecentraliseerd) systeem met beperkte toegang. Met zelfgeschreven scripts op dat extra beveiligde systeem met beperkte toegang is een beheerder vrijwel onzichtbaar voor mogelijke aanvallers en dat is belangrijk. Om het nut te maximaliseren moeten in het algemeen dat systeem met beperkte toegang best veel rechten gegeven worden op de andere machines in het netwerk, vaak via een alleen-lezen NFS-export van de andere machines naar het systeem met beperkte toegang of door ssh sleutelparen in te stellen om het systeem met beperkte toegang een ssh verbinding te laten maken met de andere machines. Buiten het netwerkverkeer, is NFS de minst zichtbare methode. Hierdoor kunnen de bestandssystemen op alle cliëntmachines vrijwel ongezien gemonitord worden. Als de server met beperkte toegang verbonden is met de cliëntmachines via een switch, dan is de NFS-methode vaak de beste keus. Als de server met beperkte toegang met de andere machines is verbonden via een hub of door meerdere routers, dan is de NFS-methode wellicht niet veilig genoeg (vanuit een netwerk standpunt) en kan beter ssh gebruikt worden, ondanks de audit-sporen die ssh achterlaat.
Als de machine met beperkte toegang eenmaal minstens
leestoegang heeft tot een cliëntsysteem dat het moet gaan
monitoren, dan moeten scripts gemaakt worden om dat monitoren
ook echt uit te voeren. Uitgaande van een NFS-koppeling, kunnen
de scripts gebruik maken van eenvoudige systeem hulpprogramma's
als find(1) en md5(1). We adviseren minstens
één keer per dag een md5 te maken van alle
bestanden op de cliëntmachine en van instellingenbestanden
als in /etc
en
/usr/local/etc
zelfs vaker.
Als er verschillen worden aangetroffen ten opzichte van de basis md5
informatie op het systeem met beperkte toegang, dan hoort het
script te gillen om een beheerder die het moet gaan uitzoeken.
Een goed beveiligingsscript controleert ook op onverwachte
suid-bestanden en op nieuwe en verwijderde bestanden op
systeempartities als /
en
/usr
.
Als ssh in plaats van NFS wordt
gebruikt, dan is het schrijven van het script lastiger. Dan
moeten de scripts met scp
naar de cliënt
verplaatst worden om ze uit te voeren, waardoor ze zichtbaar
worden. Voor de veiligheid dienen ook de binaire bestanden die
het script gebruikt, zoals find(1), gekopieerd te
worden. De ssh-cliënt op de
cliënt zou al gecompromitteerd kunnen zijn. Het is
misschien noodzakelijk ssh te gebruiken over onveilige
verbindingen, maar dat maakt alles een stuk lastiger.
Een goed beveiligingsscript voert ook controles uit op de
instellingenbestanden van gebruikers en medewerkers:
.rhosts
, .shosts
,
.ssh/authorized_keys
, enzovoort.
Dat zijn bestanden die buiten het bereik van de
MD5
-controle vallen.
Als gebruikers veel schijfruimte hebben, dan kan het te lang
duren om alle bestanden op deze partitie te controleren. In dat
geval is het verstandig de koppelvlaggen zo in te stellen dat
suid-binaire bestanden op die partities niet zijn toegestaan.
Zie daarvoor de optie nosuid
(zie
mount(8)). Die partities moeten wel toch nog minstens eens
per week doorzocht worden, omdat het doel van deze
beveiligingslaag het ontdekken van een inbraakpoging is, of die
nu succesvol is of niet.
Procesverantwoording (zie accton(8)) kost relatief gezien weinig en kan bijdragen aan een evaluatie mechanisme voor na inbraken. Het is erg handig om uit te zoeken hoe iemand precies heeft ingebroken op het systeem, mits het bestand nog onbeschadigd is na de inbraak.
Tenslotte horen beveiligingsscripts de logboekbestanden te verwerken en de logboekbestanden zelf horen zo veilig mogelijk tot stand te komen. “remote syslog” kan erg zinvol zijn. Een aanvaller zal proberen zijn sporen uit te wissen en logboekbestanden zijn van groot belang voor een systeembeheerder als het gaat om uitzoeken wanneer en hoe er is ingebroken. Een manier om logboekbestanden veilig te stellen is door het systeemconsole via een seriële poort aan te sluiten op een veilige machine en zo informatie te verzamelen.
Een beetje paranoia is niet verkeerd. Eigenlijk kan de systeembeheerder zoveel beveiligingsopties inschakelen als hij wil, als deze maar geen impact hebben op het gebruiksgemak en de beveiligingsopties die wel impact hebben op het gebruiksgemak kunnen ingeschakeld worden als daar zorgvuldig mee wordt omgegaan. Nog belangrijker is misschien dat er een juiste combinatie wordt gevonden. Als de aanbevelingen uit dit document woord voor woord worden opgevolgd, dan worden daarmee de methodes aan een toekomstige aanvaller verraden, die ook toegang heeft tot dit document.
In deze paragraaf worden Ontzeggen van Dienst aanvallen (“Denial of Service” of DoS) behandeld. Een DoS-aanval wordt meestal uitgevoerd als pakketaanval. Hoewel er weinig gedaan kan worden tegen de huidige aanvallen met gefingeerde pakketten die een netwerk kunnen verzadigen, kan de schade geminimaliseerd worden door ervoor te zorgen dat servers er niet door plat gaan door:
Limiteren van server forks.
Limiteren van springplank (“springboard”) aanvallen (ICMP response aanvallen, ping broadcast, etc.).
De Kernel Route Cache overloaden.
Een veelvoorkomende DoS-aanval is om een server aan te
vallen door het zoveel kindprocessen aan te laten maken dat het
hostsysteem uiteindelijk geen bestandsdescriptors, geheugen
enzovoort meer heeft en het dan opgeeft.
inetd (zie inetd(8)) kent een
aantal instellingen om dit type aanval af te zwakken. Hoewel
het mogelijk is ervoor te zorgen dat een machine niet plat
gaat, is het in het algemeen niet mogelijk te voorkomen dat de
dienstverlening door de aanval wordt verstoord. Meer is te
lezen in de handleiding van inetd
en het advies is in het bijzonder aandacht aan de
-c
, -C
en -R
opties te besteden. Aanvallen met gefingeerde
IP adressen omzeilen de -C
optie naar inetd, dus in het
algemeen moet een combinatie van opties gebruikt worden.
Sommige op zichzelf staande servers hebben parameters waarmee
het aantal forks gelimiteerd kan worden.
Sendmail heeft de optie
-OMaxDaemonChildren
die veel beter blijkt te
werken dan het gebruik van de opties van
Sendmail waarmee de werklast
gelimiteerd kan worden. De parameter
MaxDaemonChildren
moet zodanig ingesteld
worden dat als sendmail start; deze
hoog genoeg is om de te verwachten belasting aan te kunnen,
maar niet zo hoog is dat de computer het aantal instanties van
Sendmails niet aankan zonder plat te
gaan. Het is ook verstandig om
Sendmail in de wachtrijmodus
(-ODeliveryMode=queued
) te draaien en de
daemon (sendmail -bd
) los te koppelen van de
verwerking van de wachtrij (sendmail -q15m
).
Als de verwerking van wachtrij real-time moet, kunnen de
tussenpozen voor verwerking verkort worden door deze
bijvoorbeeld op -q1m
in te stellen, maar dan
is een redelijke instelling van
MaxDaemonChildren
van belang om
die Sendmail te
beschermen tegen trapsgewijze fouten.
Syslogd kan direct aangevallen
worden en het is sterk aan te raden de -s
optie te gebruiken waar dat ook maar mogelijk is en anders de
-a
optie.
Er dient voorzichtig omgesprongen te worden met diensten die terugverbinden zoals TCP Wrapper's reverse-identd die direct aangevallen kan worden. In het algemeen is het hierom onverstandig gebruik te maken van de reverse-ident optie van TCP Wrapper.
Het is een goed idee om interne diensten af te schermen
voor toegang van buitenaf door ze te firewallen op de routers
aan de rand van een netwerk (“border routers”).
Dit heeft als achtergrond dat verzadigingsaanvallen voorkomen
van buiten het LAN voorkomen kunnen worden. Daarmee wordt geen
aanval op root
via het netwerk en die
diensten daaraan voorkomen. Er dient altijd een exclusieve
firewall te zijn, dat wil zeggen “firewall alles
behalve poorten A, B, C, D en M-Z”.
Zo worden alle lage poorten gefirewalled behalve die voor
specifieke diensten als named (als
er een primary is voor een zone),
ntalkd,
sendmail en andere diensten die
vanaf Internet toegankelijk moeten zijn. Als de firewall
andersom wordt ingesteld, als een inclusieve of tolerante
firewall, dan is de kans groot dat er wordt vergeten een aantal
diensten af te “sluiten” of dat er een nieuwe
interne dienst wordt toegevoegd en de firewall niet wordt
bijgewerkt. Er kan nog steeds voor gekozen worden de hoge
poorten open te zetten, zodat een tolerante situatie ontstaat,
zonder de lage poorten open te stellen. FreeBSD biedt ook de
mogelijkheid een reeks poortnummers die gebruikt worden voor
dynamische verbindingen in te stellen via de verscheidene
net.inet.ip.portrange
sysctl
s (sysctl -a | fgrep
portrange
), waardoor ook de complexiteit van de
firewall instellingen kan vereenvoudigen. Zo kan bijvoorbeeld
een normaal begin tot eindbereik ingesteld worden van 4000 tot
5000 en een hoog poortbereik van 49152 tot 65535. Daarna kan
alles onder 4000 op de firewall geblokkeerd worden (met
uitzondering van bepaalde poorten die vanaf Internet bereikbaar
moeten zijn natuurlijk).
Een andere veelvoorkomende DoS-aanval is de
springplankaanval: een server zo aanvallen dat de respons van
die server de server zelf, het lokale netwerk of een andere
machine overbelast. De meest voorkomende aanval van dit type is
de ICMP ping broadcast aanval. De
aanvaller fingeert ping-pakketten die naar het broadcast-adres
van het LAN worden gezonden met als bron het
IP-adres van de machine die hij eigenlijk aan
wil vallen. Als de routers aan de rand van het netwerk niet
zijn ingesteld om een ping-pakketten aan een broadcast-adres te
blokkeren, dan kan het LAN genoeg antwoorden produceren om de
verbinding van het slachtoffer (het gefingeerde bronadres) te
verzadigen, zeker als de aanvaller hetzelfde doet met tientallen
andere netwerken. Broadcastaanvallen met een volume van meer
dan 120 megabit zijn al voorgekomen. Een tweede
springplankaanval is er een tegen het ICMP-foutmeldingssysteem.
Door een pakket te maken waarop een ICMP-foutmelding komt, kan
een aanvaller de inkomende verbinding van een server verzadigen
en de uitgaande verbinding laten verzadigen met
ICMP-foutmeldingen. Dit type aanval kan een server ook laten
crashen door te zorgen dat het geheugen ervan vol zit, zeker als
de server de ICMP-antwoorden niet zo snel kwijt kan als dat het
ze genereert. Gebruik de
sysctl-variabele
net.inet.icmp.icmplim
om deze aanvallen te
beperken. De laatste belangrijke klasse springplankaanvallen
hangt samen met een aantal interne diensten van
inetd zoals de UDP-echodienst. Een
aanvaller fingeert eenvoudigweg een UDP-pakket met als
bronadres de echopoort van Server A en als bestemming de
echopoort van Server B, waar Server A en B allebei op een LAN
staan. Die twee servers gaan dat pakket dan heen en weer
kaatsen. Een aanvaller kan beide servers overbelasten door een
aantal van deze pakketten te injecteren. Soortgelijke problemen
kunnen ontstaan met de poort chargen.
Een competente systeembeheerder zal al deze interne
inetd testdiensten
uitschakelen.
Gefingeerde pakketten kunnen ook gebruikt worden om de
kernel route cache te overbelasten. Raadpleeg daarvoor de
net.inet.ip.rtexpire
,
rtminexpire
en rtmaxcache
sysctl
parameters. Een aanval met
gefingeerde pakketten met een willekeurig bron-IP zorgt ervoor
dat de kernel een tijdelijke gecachede route maakt in de
routetabel, die uitgelezen kan worden met netstat -rna
| fgrep W3
. Deze routes hebben een levensduur van
ongeveer 1600 seconden. Als de kernel merkt dat de gecachede
routetabel te groot is geworden, dan wordt
rtexpire
dynamisch verkleind, maar deze
waarde wordt nooit lager dan rtminexpire
.
Er zijn twee problemen:
De kernel reageert niet snel genoeg als een laag belaste server wordt aangevallen.
rtminexpire
is niet laag genoeg om
de kernel de aanval te laten overleven.
Als servers verbonden zijn met het Internet via een E3
of sneller, dan is het verstandig om handmatig
rtexpire
en rtminexpire
aan te passen via sysctl(8). Als de een van de parameters
op nul wordt gezet, dan crasht de machine. Het instellen van
beide waarden op 2 seconden is voldoende om de routetabel
tegen een aanval te beschermen.
Er zijn een aantal aandachtspunten die in acht genomen
moeten worden als Kerberos of ssh gebruikt worden. Kerberos 5
is een prima autenticatieprotocol, maar er zitten bugs in de
Kerberos-versies van telnet en
rlogin waardoor ze niet geschikt
zijn voor binair verkeer. Kerberos codeert standaard de sessie
niet, tenzij de optie -x
wordt gebruikt.
ssh codeert standaard wel
alles.
Ssh werkt prima, maar het stuurt coderingssleutels
standaard door. Dit betekent dat als gegeven een veilig
werkstation met sleutels die toegang geven tot de rest van het
systeem en ssh wordt gebruikt om verbinding te maken met een
onveilige machine, die sleutels gebruikt kunnen worden. De
sleutels zelf zijn niet bekend, maar ssh stelt een
doorstuurpoort in zolang als een gebruikers aangemeld blijft.
Als de aanvaller root
toegang heeft op de
onveilige machine, dan kan hij die poort gebruiken om toegang
te krijgen tot alle machines waar de sleutels van de gebruiker
toegang toe geven.
Het advies is ssh in combinatie met Kerberos te gebruiken
voor het aanmelden door medewerkers wanneer dat ook maar
mogelijk is. Ssh kan gecompileerd
worden met Kerberos-ondersteuning. Dit vermindert de kans op
blootstelling van ssh-sleutels en beschermt tegelijkertijd
de wachtwoorden met Kerberos. Ssh-sleutels zouden alleen
gebruikt moeten worden voor geautomatiseerde taken vanaf
veilige machines (iets waar Kerberos ongeschikt voor is). Het
advies is om het doorsturen van sleutels uit te schakelen in de
ssh-instellingen of om de from=IP/DOMAIN
optie te gebruiken die ssh in staat stelt het bestand
authorized_keys
te gebruiken om de
sleutel alleen bruikbaar te maken voor entiteiten die zich
aanmelden vanaf vooraf aangewezen machines.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.