Linux Security HOWTO
Kevin Fenzi, kevin@tummy.com & Dave Wreski, dave@linuxsecu
rity.com
v1.1.1, 17 maart 2000
Dit document is een algemeen overzicht van beveiligingskwesties waar
een beheerder van Linux systemen mee geconfronteerd wordt. Het behan
delt een algemene beveiligingsfilosofie en een aantal specifieke voor
beelden van hoe je je Linux-systeem beter tegen indringers kunt
beveiligen. Ook zijn er verwijzingen naar materiaal en programma's die
betrekking hebben op beveiliging. Verbeteringen, constructieve kri
tiek, toevoegingen en correcties worden dankbaar geaccepteerd. Stuur
je reactie alsjeblieft naar beide auteurs, met "Security HOWTO" als
onderwerp.
______________________________________________________________________
Inhoudsopgave
1. Inleiding
1.1 Nieuwe versies van dit document
1.2 Reacties
1.3 Disclaimer
1.4 Copyright informatie
2. Overzicht
2.1 Wat is het nut van beveiliging?
2.2 Hoe veilig is veilig?
2.3 Wat probeer je te beschermen?
2.4 Een beveiligingsbeleid ontwikkelen
2.5 Manieren om je site te beveiligen
2.5.1 Beveiliging van de host
2.5.2 Beveiliging van het lokale netwerk
2.5.3 Beveiliging door onduidelijkheid
2.6 Organisatie van dit document
3. Fysieke beveiliging
3.1 Computersloten
3.2 Beveiliging van de BIOS
3.3 Beveiliging van de Boot Loader
3.4 xlock en vlock
3.5 Fysieke beveiligingsgevaren opsporen
4. Lokale beveiliging
4.1 Nieuwe accounts aanmaken
4.2 Root beveiliging
5. Beveiliging van bestanden en bestandssystemen
5.1 Umask instellingen
5.2 Bestandspermissies
5.3 Controle op integriteit
5.4 Trojan Horses
6. Wachtwoordbeveiliging en -versleuteling
6.1 PGP en Public-Key versleuteling
6.2 SSL, S-HTTP, HTTPS en S/MIME
6.3 Linux IPSEC uitvoeringen
6.4 (TT
6.5 PAM - Pluggable Authentication Modules
6.6 Cryptographic IP Encapsulation (CIPE)
6.7 Kerberos
6.8 Shadow Passwords
6.9 "Crack" en "John the Ripper"
6.10 CFS - Cryptographic File System en TCFS - Transparent Cryptographic File System
6.11 X11, SVGA en beeldschermbeveiliging
6.11.1 X11
6.11.2 SVGA
6.11.3 GGI (Generic Graphics Interface project)
7. Beveiliging van de kernel
7.1 Opties om 2.0 kernels te compileren
7.2 Opties om 2.2 kernels te compileren
7.3 Kernel Devices
8. Beveiliging van het netwerk
8.1 Packet Sniffers
8.2 Systeemdiensten en tcp-wrappers
8.3 Verifieer je DNS informatie
8.4 (TT
8.5 SATAN, ISS en andere netwerk scanners
8.5.1 Poortscans detecteren
8.6 (TT
8.7 Denial of Service aanvallen
8.8 NFS (Network File System) beveiliging
8.9 NIS (Network Information Service) (voorheen YP)
8.10 Firewalls
8.11 IP Chains - Linux Kernel 2.2.x Firewalling
8.12 VPN's - Virtual Private Networks
9. Beveiligingsvoorbereidingen (voordat je on-line gaat)
9.1 Maak een volledige backup van je machine
9.2 Het kiezen van een goed backup schema
9.3 Maak een backup van je RPM of Debian File Database
9.4 Houd je systeemlog gegevens bij
9.5 Maak gebruik van alle nieuwe systeem updates
10. Wat te doen tijdens en na een inbraak
10.1 Een aanval op de beveiliging is aan de gang
10.2 Een aanval heeft reeds plaatsgevonden
10.2.1 Het gat dichten
10.2.2 De schade opnemen
10.2.3 Backups, backups, backups!
10.2.4 De indringer traceren
11. Bronnen
11.1 FTP Sites
11.2 Websites
11.3 Mailing Lists
11.4 Boeken - Gedrukt materiaal
12. Verklarende woordenlijst
13. Veel gestelde vragen
14. Conclusie
15. Dankbetuigingen
______________________________________________________________________
1. Inleiding
Dit document behandelt enkele van de belangrijkste kwesties die
betrekking hebben op beveiliging in Linux. Algemene filosofie en via
het netwerk ontstane middelen worden besproken.
In een aantal andere HOWTO documenten worden ook beveiligingskwesties
behandeld en naar deze documenten wordt verwezen als dat nodig is.
Dit document kan niet zo bijgewerkt zijn dat alle nieuwe
beveiligingslekken erin genoemd worden, aangezien er voortdurend
nieuwe beveiligingslekken worden ontdekt. Dit document zal je
vertellen waar je moet zoeken naar dergelijke up-to-date informatie en
zal je enkele algemene methoden geven om te voorkomen dat zulke
beveiligingslekken plaats hebben.
1.1. Nieuwe versies van dit document
Nieuwe versies van dit document zullen periodiek worden gestuurd naar
comp.os.linux.answers. Ze zullen ook worden toegevoegd aan de diverse
sites die zulke informatie archiveren, waaronder:
http://www.linuxdoc.org/
Bovendien zul je normaal gesproken dit document ook moeten kunnen
vinden op de Linux World Wide Web home page via:
http://metalab.unc.edu/mdw/linux.html
Tot slot zou de meest recente versie van dit document ook in
verschillende formaten beschikbaar moeten zijn op:
http://scrye.com/~kevin/lsh/
of
http://www.linuxsecurity.com/Security-HOWTO
of
http://www.tummy.com/security-howto
1.2. Reacties
Alle opmerkingen, foutmeldingen, aanvullende informatie en alle
mogelijke vormen van kritiek kunnen worden gestuurd naar:
kevin@tummy.com
en
dave@linuxsecurity.com
Let op: Stuur je reactie alsjeblieft naar beide auteurs. Ook moet je
voor de zekerheid "Linux", "security" of "HOWTO" in het onderwerp
zetten om Kevin's spamfilter te ontwijken.
1.3. Disclaimer
Voor de inhoud van dit document kan geen aansprakelijkheid worden
geaccepteerd. Gebruik de begrippen, voorbeelden en andere inhoud op
eigen risico. Bovendien is dit een concept, mogelijk met veel
onnauwkeurigheden of fouten.
Voor een aantal voorbeelden en beschrijvingen wordt gebruik gemaakt
van de RedHat(tm) pakket-layout en systeemsetup. De weg die jij moet
bewandelen om zover te komen kan anders zijn.
Voor zover we weten worden er alleen programma's beschreven die onder
bepaalde voorwaarden mogen worden gebruikt of geëvalueerd voor
persoonlijke doeleinden. De meeste programma's zijn beschikbaar,
compleet met broncode, onder GNU
<http://www.gnu.org/copyleft/gpl.html> voorwaarden.
1.4. Copyright informatie
Dit document is auteursrechtelijk beschermd (c)1998-2000 Kevin Fenzi
en Dave Wreski en wordt verspreid onder de volgende voorwaarden:
· Linux HOWTO documenten mogen worden gereproduceerd en in z'n geheel
of in gedeelten, in elk medium, fysiek of electronisch worden
verspreid, als deze copyright-vermelding maar behouden blijft op
alle copieën. Commerciële herverspreiding is toegestaan en wordt
aangemoedigd; echter, de auteurs willen graag op de hoogte gesteld
worden van zulke distributies.
· Alle vertalingen, afgeleide werken of verzamelde werken die te
maken hebben met enige Linux HOWTO documenten moeten deze
copyright-vermelding bevatten. Dat houdt in dat je geen afgeleid
werk van een HOWTO mag maken en aanvullende beperkingen op de
distributie mag opleggen. Uitzonderingen op deze regels kunnen
onder bepaalde voorwaarden toegestaan worden; neem alsjeblieft
contact op met de Linux HOWTO coördinator op het onderstaande
adres.
· Als je vragen hebt, neem dan alsjeblieft contact op met Tim Bynum,
de Linux HOWTO coördinator, op
tjbynum@metalab.unc.edu
2. Overzicht
Dit document zal enkele procedures en veelgebruikte software om je te
helpen je Linux systeem veiliger te maken proberen uit te leggen. Het
is belangrijk om, voordat we beginnen, eerst enkele basisbegrippen te
bespreken en een basisbeveiliging te creëren.
2.1. Wat is het nut van beveiliging?
In de altijd veranderende wereld van globale datacommunicatie,
goedkope Internetverbindingen en het hoge tempo van software
ontwikkeling, wordt beveiliging een steeds belangrijker onderwerp.
Beveiliging is nu een basisvereiste, omdat globale informatica
inherent onveilig is. Als je gegevens bijvoorbeeld van punt A naar B
op het Internet gaan, zou het onderweg via diverse andere punten
kunnen gaan, hetgeen andere gebruikers de gelegenheid geeft het te
onderscheppen en het zelfs te wijzigen. Zelfs andere gebruikers op je
systeem kunnen opzettelijk jouw gegevens veranderen in iets dat je
niet bedoelde. Onbevoegde toegang tot je systeem kan verkregen worden
door indringers, ook bekend als "crackers", die dan geavanceerde
kennis gebruiken om zich als jou voor te doen, informatie van je te
stelen of je zelfs de toegang tot je eigen middelen te ontzeggen. Als
je je afvraagt wat het verschil is tussen een "Hacker" en een
"Cracker", bekijk dan Eric Raymond's document "How to Become A
Hacker", beschikbaar op http://www.netaxs.com/~esr/faqs/hacker-
howto.html.
2.2. Hoe veilig is veilig?
Houd allereerst in gedachten dat geen enkel computersysteem ooit
volledig veilig kan zijn. Je kunt het alleen maar steeds moeilijker
voor iemand maken om je systeem in gevaar te brengen. Voor de
gemiddelde Linux thuisgebruiker is er niet veel nodig om de terloopse
cracker buiten de deur te houden. Voor professionele Linux gebruikers
(banken, telecommunicatie-bedrijven enz.) is echter veel meer werk
vereist.
Een andere factor om rekening mee te houden is dat hoe veiliger je
systeem is, hoe indringeriger je beveiliging wordt. Je moet een balans
zien te vinden zodat je systeem nog steeds bruikbaar is en toch veilig
voor jouw doeleinden. Je kunt bijvoorbeeld verlangen dat iedereen die
op je systeem inbelt een 'call-back modem' gebruikt om ze terug te
kunnen bellen op hun nummer thuis. Dit is veiliger, maar als iemand
niet thuis is, wordt het moeilijk voor hen om in te loggen. Je kunt je
Linux systeem ook instellen zonder netwerk of verbinding met het
Internet, maar dit beperkt zijn bruikbaarheid.
Als het een gemiddeld tot grote site betreft, zul je een
beveiligingsbeleid moeten vaststellen, waarin staat hoeveel
beveiliging voor jouw site vereist is en op welke wijze dit
gecontroleerd wordt. Je kunt een voorbeeld van een welbekend
beveiligingsbeleid vinden op http://www.faqs.org/rfcs/rfc2196.html.
Het is recent bijgewerkt en bevat een goede opzet om een
beveiligingsbeleid voor jouw bedrijf vast te kunnen stellen.
2.3. Wat probeer je te beschermen?
Voordat je probeert je systeem te beveiligen, moet je vaststellen
tegen welk niveau van bedreiging je je moet beschermen, welke risico's
je wel of niet moet nemen en hoe kwetsbaar je systeem als gevolg
hiervan is. Je moet je systeem analiseren om te weten wat je
beschermt, waarom je het beschermt, welke waarde het heeft en wie de
verantwoording voor je data en andere bezittingen heeft.
· Een risico is de mogelijkheid dat een indringer succesvol kan zijn
in zijn pogingen om toegang tot je computer te krijgen. Kan een
indringer bestanden lezen of schrijven of programma's uitvoeren die
schade kunnen veroorzaken? Kan hij kritieke data verwijderen? Kan
hij voorkomen dat jij of jouw bedrijf belangrijk werk gedaan
krijgt? Vergeet niet: iemand die zich toegang verschaft tot jouw
account of jouw systeem kan zich ook als jou voordoen. Bovendien
kan het hebben van één onveilig account erin resulteren dat je hele
netwerk in gevaar komt. Als je een enkele gebruiker toestaat om in
te loggen middels een .rhosts file of door gebruik te maken van een
onveilige service als tftp, riskeer je dat een indringer 'zijn voet
tussen de deur krijgt'. Als de indringer eenmaal een
gebruikersaccount op jouw of iemand anders z'n systeem heeft, kan
het gebruikt worden om toegang tot een ander systeem of account te
verkrijgen.
· Een bedreiging vormt iemand die gemotiveerd is om onbevoegd toegang
tot je netwerk of computer te krijgen. Je moet vaststellen wie je
vertrouwt om toegang tot je systeem te hebben en welke bedreiging
ze kunnen vormen.
Er zijn verschillende typen indringers en het is handig om hun ver
schillende karakteristieken in gedachten te houden als je je systemen
gaat beveiligen.
· De Nieuwsgierige - Dit type indringer is voornamelijk
geïnteresseerd in het uitvinden wat voor type systeem en gegevens
je hebt.
· De Kwaadwillige - Dit type indringer is erop uit om je systemen
ten val te brengen, je webpagina te ontsieren of je op een andere
manier te dwingen om geld en tijd te spenderen aan het herstellen
van de schade die hij heeft aangebracht.
· De Geavanceerde - Dit type indringer probeert je systeem te
gebruiken om populair en berucht te worden. Hij kan je systeem
gebruiken om aandacht te vragen voor zijn bekwaamheden.
· De Concurrentie - Dit type indringer is geïnteresseerd in wat voor
gegevens je op je systeem hebt. Het kan iemand zijn die denkt dat
je iets hebt waarvan hij kan profiteren, financieel of anderszins.
· De Lener - Dit type indringer is geïnteresseerd in het doeleinden
te gebruiken. Het typeert hem om chat of irq servers te draaien,
porno archiefsites of zelfs DNS servers.
· Haasje-over - Dit type indringer is alleen geïnteresseerd in je
systeem om het te gebruiken om andere systemen binnen te dringen.
Als je systeem voorzien is van veel verbindingen of een poort is
naar een aantal interne hosts, zou je dit type tegen kunnen komen
om te proberen je systeem te beschadigen.
· Kwetsbaarheid beschrijft hoe goed beveiligd je computer is vanaf
een ander netwerk en de mogelijkheid die iemand heeft om onbevoegd
toegang te verkrijgen.
Wat staat er op het spel als iemand inbreekt in je systeem? Natuurlijk
zullen de zorgen van een dynamische PPP thuisgebruiker verschillen van
die van een bedrijf die zijn machine met het Internet of een ander
groot netwerk heeft verbonden.
Hoeveel tijd zal het in beslag nemen om alle gegevens die verloren
zijn gegaan te herstellen/opnieuw aan te maken? Nu wat tijd investeren
kan tien keer zoveel tijd later besparen als je de gegevens die ver
loren zijn gegaan opnieuw aan moet maken. Heb je je back-up strategie
gecontroleerd en je gegevens recentelijk geverifieerd?
2.4. Een beveiligingsbeleid ontwikkelen
Creëer een eenvoudig, algemeen beleid voor je systeem dat je
gebruikers gemakkelijk kunnen begrijpen en volgen. Het moet zowel de
gegevens als de privacy van de gebruikers beschermen. Enkele dingen
die je kunt overwegen om toe te voegen zijn: wie heeft toegang tot het
systeem (Kan mijn vriend mijn account gebruiken?), wie is er bevoegd
om software op het systeem te installeren, wie bezit welke gegevens,
herstel na een ramp en passend gebruik van het systeem.
Een algemeen geaccepteerd beveiligingsbeleid begint met de zin:
Dat wat niet toegestaan is, is verboden.
Dit betekent dat, tenzij je een gebruiker toegang tot een dienst
toestaat, die gebruiker geen gebruik mag maken van die dienst totdat
je toegang toestaat. Verzeker jezelf ervan dat het beleid werkt op je
reguliere gebruikersaccount. Zeggen "Ach, ik word geen wijs uit dat
permissie-probleem, ik doe het wel als root", kan leiden tot
beveiligingslekken die erg voor de hand liggend zijn, zelfs degenen
die nog niet misbruikt zijn.
rfc1244 is een document dat beschrijft hoe je je eigen netwerk
beveiligingbeleid moet creëren.
rfc1281 is een document dat een voorbeeld van een beveiligingsbeleid
laat zien met een gedetaïlleerde beschrijving van elke stap.
Tot slot zou je het COAST-beleid archief op
ftp://coast.cs.purdue.edu/pub/doc/policy kunnen bekijken om na te gaan
hoe een beveiligingsbeleid er in werkelijkheid uitziet.
2.5. Manieren om je site te beveiligen
Dit document zal verschillende manieren bespreken waarop je de dingen
waar je hard voor hebt gewerkt kunt beveiligen: je lokale machine, je
gegevens, je gebruikers, je netwerk en zelfs je reputatie. Wat zou er
gebeuren met je reputatie als een indringer enkele gegevens van je
gebruikers zou wissen? Of je website zou ontsieren? Of het collectieve
project plan van je bedrijf voor het komend kwartaal zou publiceren?
Als je een netwerkinstallatie overweegt, zijn er vele factoren waar je
rekening mee moet houden alvorens een enkele machine aan je netwerk
toe te voegen.
Zelfs als je een enkel dialup PPP account hebt of slechts een kleine
site, houdt dit niet in dat indringers niet in jouw systemen
geïnteresseerd zijn. Grote geavanceerde sites zijn niet de enige
doelen -- veel indringers willen simpelweg zoveel mogelijk sites
binnendringen, ongeacht hun grootte. Bovendien kunnen ze een
beveiligingslek in jouw site gebruiken om toegang te verkrijgen tot
andere sites waarmee je bent verbonden.
Indringers hebben heel veel tijd en kunnen het gokken hoe je je
systeem verduisterd hebt voorkomen door gewoon alle mogelijkheden te
proberen. Er zijn ook een aantal redenen waarom een indringer in jouw
systeem geïnteresseerd zou kunnen zijn, welke we later zullen
bespreken.
2.5.1. Beveiliging van de host
Het gebied van beveiliging waar beheerders zich het meest op
concentreren is wellicht de host-gebaseerde beveiliging. Dit houdt
kenmerkend in het ervoor zorgen dat je eigen systeem veilig is en het
hopen dat iedereen op je netwerk hetzelfde doet. Goede wachtwoorden
kiezen, de lokale netwerkdiensten van je host beveiligen, de account-
bestanden goed bijhouden en programma's met bekende beveiligingslekken
verbeteren, zijn onder andere de dingen die onder de
verantwoordelijkheid vallen van de lokale beveiligingsbeheerder.
Hoewel dit absoluut noodzakelijk is, kan het een ontmoedigende taak
worden als je systeem groter wordt dan een paar machines.
2.5.2. Beveiliging van het lokale netwerk
Beveiliging van het netwerk is net zo belangrijk als beveiliging van
de lokale host. Met honderden, duizenden of meer computers op
hetzelfde netwerk kun je er niet op vertrouwen dat al deze systemen
veilig zijn. Je ervan verzekeren dat alleen geautoriseerde gebruikers
je netwerk kunnen gebruiken, firewalls bouwen, een hoge mate van
versleuteling gebruiken en zeker weten dat er geen "louche" (dus
onveilige) machines met je netwerk verbonden zijn, maakt allemaal deel
uit van de taken van de beveiligingsbeheerder van een netwerk.
Dit document behandelt enkele van de technieken die worden gebruikt om
je site te beveiligen en zal je hopelijk enkele manieren laten zien om
te voorkomen dat een indringer toegang krijgt tot wat je probeert te
beschermen.
2.5.3. Beveiliging door onduidelijkheid
Een soort beveiliging die besproken moet worden is "beveiliging door
onduidelijkheid". Dit betekent bijvoorbeeld het verplaatsen van een
dienst die bekende beveiligingskwetsbaarheden heeft naar een niet-
standaard poort in de hoop dat aanvallers het niet in de gaten hebben
en het dus niet misbruiken. Wees gerust dat ze kunnen vaststellen dat
het er is en dat ze het zullen misbruiken. Beveiliging door
onduidelijkheid is helemaal geen beveiliging. Simpelweg omdat het
feit dat je een kleine site hebt of niet te veel opvalt niet inhoudt
dat een indringer niet geïnteresseerd zal zijn in wat je hebt. We
zullen bespreken wat je beschermt in de volgende paragrafen.
2.6. Organisatie van dit document
Dit document is verdeeld in een aantal paragrafen. Ze behandelen
verscheidene algemene beveiligingskwesties. De eerste, ``Fysieke
beveiliging'', behandelt hoe je je fysieke machine moet beschermen
tegen geknoei. De tweede, ``Lokale beveiliging'', beschrijft hoe je je
systeem moet beschermen tegen geknoei van lokale gebruikers. De derde,
``Beveiliging van bestanden en bestandssystemen'', laat zien hoe je
bestandssystemen en permissies op bestanden moet instellen. De
volgende, ``Wachtwoordbeveiliging en -versleuteling'', bespreekt hoe
je versleuteling kunt gebruiken om je machine en netwerk beter te
beveiligen. ``Beveiliging van de kernel'' bespreekt welke
kernelopties je moet instellen of je bewust van moet zijn voor een
veiliger systeem. ``Beveiliging van het netwerk'' beschrijft hoe je je
Linux systeem beter kunt beveiligen tegen netwerkaanvallen.
``Beveiligingsvoorbereidingen'' bespreekt hoe je je machine(s) moet
voorbereiden voor je ze on-line brengt. De volgende, ``Wat te doen
tijdens en na een inbraak'', bespreekt wat te doen als je een aanval
op je systeem constateert of ontdekt dat dit recentelijk is gebeurd.
In ``Bronnen'' worden enkele primaire bronnen opgesomd waar je meer
over beveiliging kunt vinden. In de V en A paragraaf ``Veel gestelde
vragen'' worden enkele veel gestelde vragen beantwoord en tot slot
volgt een conclusie in ``Conclusie''.
De twee belangrijkste punten die je je moet realiseren als je dit
document leest, zijn:
· Wees je bewust van je systeem. Controleer systeemlogs zoals
/var/log/messages, houd een oogje op je systeem en
· Houd je systeem up-to-date door je ervan te verzekeren dat je de
meest recente software versies hebt geïnstalleerd en verbeteringen
hebt aangebracht bij beveiligingswaarschuwingen. Dit gewoonweg doen
zal helpen om je systeem merkbaar veiliger te maken.
3. Fysieke beveiliging
De eerste laag van beveiliging waar je rekening mee moet houden is de
fysieke beveiliging van je computersystemen. Wie heeft directe fysieke
toegang tot je machine? Zouden ze dat ook moeten hebben? Kun je je
machine beschermen tegen hun geknoei? Zou je dat ook moeten doen?
Hoeveel fysieke beveiliging je nodig hebt op je systeem is erg
afhankelijk van je situatie en/of budget.
Als je een thuisgebruiker bent, zul je waarschijnlijk niet veel nodig
hebben (alhoewel je misschien je machine wilt beschermen tegen het
geknoei van kinderen of hinderlijke familieleden). Als je in een
laboratorium bent, zul je aanzienlijk meer nodig hebben, maar
gebruikers moeten wel hun werk kunnen doen op hun machines. Veel van
de volgende paragrafen bieden uitkomst. Als je in een kantoor bent,
kun je wel of niet je machine beveiligen na kantoortijd of als je weg
bent. Bij sommige bedrijven leidt het onbeveiligd achterlaten van je
computer tot ontslag.
Voor de hand liggende fysieke beveiligingsmethoden als sloten op
deuren, kabels, afgesloten kasten en videobewaking zijn allemaal goede
ideeën, maar vallen buiten de strekking van dit document. :)
3.1. Computersloten
Veel moderne PC-kasten bieden een voorziening om ze "op slot te doen".
Gewoonlijk zal dit een socket aan de voorkant van de kast zijn,
waarmee je met een bijgeleverd sleuteltje de computer op slot kunt
zetten of van het slot kunt halen. Kastsloten kunnen helpen voorkomen
dat iemand je PC steelt of de kast opent en je hardware rechtstreeks
manipuleert/steelt. Soms kunnen ze ook voorkomen dat iemand je
computer opnieuw opstart vanaf z'n eigen floppy of andere hardware.
Deze kastsloten doen verschillende dingen al naar gelang de
ondersteuning in het moederbord en de wijze waarop de kast is gemaakt.
Op veel PC's is het zo gemaakt dat je de kast moet openbreken om hem
open te krijgen. Op enkele andere laten ze je geen nieuwe
toetsenborden of muizen aansluiten. Raadpleeg de voorschriften van je
moederbord of kast voor meer informatie. Dit kan soms een erg
bruikbare voorziening zijn, ondanks dat de sloten gewoonlijk van erg
lage kwaliteit zijn en makkelijk kunnen worden gesloopt door
aanvallers met slotenmakersgereedschap.
Sommige machines (voornamelijk SPARC's en Mac's) hebben een oog aan de
achterkant waar je een kabel door kunt halen, zodat aanvallers de
kabel moeten doorknippen of de kast moeten slopen om erin te kunnen
komen. Een hangslot of een combinatieslot erdoor is een
afschrikwekkend middel voor iemand die je machine wil stelen.
3.2. Beveiliging van de BIOS
De BIOS is het laagste niveau van software dat je x86-gebaseerde
hardware configureert of manipuleert. LILO en andere Linux
bootmethodes benaderen de BIOS om vast te stellen hoe je Linux machine
opgestart moet worden. Andere hardware waar Linux op draait heeft
vergelijkbare software (OpenFirmware op Mac's en nieuwe Sun's, Sun
boot PROM, enz...). Je kunt je BIOS gebruiken om te voorkomen dat
aanvallers je machine opnieuw opstarten en je Linux systeem
manipuleren.
In de BIOS van veel PC's kun je een boot wachtwoord instellen. Dit
verschaft niet zo heel veel beveiliging (de BIOS kan worden gereset of
verwijderd als iemand in de kast kan komen), maar het kan een goed
afschrikwekkend middel zijn (d.w.z. het kost tijd en laat sporen van
geknoei na). Op dezelfde wijze kan op S/Linux (Linux voor SPARC(tm)
processor machines) je EEPROM worden ingesteld om een boot-wachtwoord
te vereisen. Dit kan vertragend werken voor aanvallers.
Veel x86 BIOS'sen staan je ook toe om diverse andere goede
beveiligingsinstellingen te specificeren. Raadpleeg je BIOS
handleiding of bekijk het de volgende keer als je opstart. Sommige
BIOS'sen staan bijvoorbeeld het opstarten vanaf floppy drives niet toe
en sommigen vereisen wachtwoorden om toegang te krijgen tot enkele
BIOS voorzieningen.
Let op: Als je een server machine hebt en je stelt een boot
wachtwoord in, zal je machine niet onbeheerd opstarten. Houd in
gedachten dat je in geval van een stroomstoring moet komen opdagen om
het wachtwoord in te toetsen. ;(
3.3. Beveiliging van de Boot Loader
In de verschillende Linux boot loaders kan ook een wachtwoord
ingesteld worden. LILO heeft bijvoorbeeld password en restricted
instellingen; password vereist een wachtwoord bij het opstarten,
terwijl restricted alleen een wachtwoord bij het opstarten vereist als
je opties specificeert (zoals single) bij de LILO prompt.
Uit de lilo.conf man pagina:
password=password
The per-image option `password=...' (see below) applies to all images.
restricted
The per-image option `restricted' (see below) applies to all images.
password=password
Protect the image by a password.
restricted
A password is only required to boot the image if
parameters are specified on the command line
(e.g. single).
Houd in gedachten dat wanneer je al deze wachtwoorden instelt, je ze
ook moet onthouden. :) Onthoud ook dat deze wachtwoorden de
vastbesloten aanvaller louter zullen vertragen. Ze kunnen niet
voorkomen dat iemand opstart vanaf een floppy en je root partitie
mount. Als je beveiliging samen met een boot loader gebruikt, kun je
net zo goed het opstarten vanaf een floppy uitschakelen in de BIOS van
je computer en de BIOS met een wachtwoord beschermen.
Als iemand beveiligingsgerelateerde informatie van een andere boot
loader heeft, zouden we dat graag willen horen. (grub, silo, milo,
linload, enz.)
Let op: Als je een server machine hebt en je stelt een boot wachtwoord
in, zal je machine niet onbeheerd opstarten. Houd in gedachten dat je
in geval van een stroomstoring moet komen opdagen om het wachtwoord in
te toetsen. ;(
3.4. xlock en vlock
Als je af en toe van je machine afdwaalt, is het wel aardig dat je de
mogelijkheid hebt om je console te "vergrendelen" zodat niemand je
werk kan verknoeien of bekijken. Twee programma's die dat doen zijn
xlock en vlock.
xlock is een X beeldschermvergrendeling. Het zou bij elke Linux
distributie moeten zitten die X ondersteunt. Bekijk hiervoor de man
pagina voor meer opties, maar in het algemeen kun je xlock draaien
vanaf elke xterm op je console en het zal het beeldscherm vergrendelen
en om een wachtwoord vragen om te ontgrendelen.
vlock is een simpel klein programma waarmee je enkele of alle virtuele
consoles op je Linux box kunt vergrendelen. Je kunt alleen degene
waarop je aan het werk bent vergrendelen, of allemaal. Als je er maar
één afsluit, kunnen anderen binnenkomen en de console gebruiken; ze
kunnen alleen niet jouw virtuele console gebruiken totdat je hem
ontgrendelt. vlock wordt geleverd bij Redhat Linux, maar de weg die
jij moet bewandelen om zover te komen kan anders zijn.
Natuurlijk zal het vergrendelen van je console iemand ervan weerhouden
om met je werk te knoeien, maar het zal ze niet beletten om je machine
opnieuw op te starten of anderszins je werk te verstoren. Het
weerhoudt ze ook niet om je machine te benaderen vanaf een andere
machine op het netwerk en problemen te veroorzaken.
Maar belangrijker, het weerhoudt iemand niet om het X Window systeem
geheel te verlaten en naar een normale virtuele login prompt te gaan
of naar de virtuele console waarvan X11 is opgestart en het op non-
actief te zetten om zodoende jouw privileges te verkrijgen. Om deze
reden zou je moeten overwegen om het alleen in combinatie met xdm te
gebruiken.
3.5. Fysieke beveiligingsgevaren opsporen
Het eerste waar je altijd op moet letten is of je machine opnieuw is
opgestart. Omdat Linux een robuust en stabiel besturingssysteem is,
zijn de enige keren dat het opnieuw opgestart moet worden, de keren
dat jij het buiten gebruik stelt voor upgrades van het
besturingssysteem, wisseling van hardware of iets dergelijks. Als je
machine opnieuw is opgestart buiten jouw medeweten, kan dat een teken
zijn dat een indringer je systeem in gevaar brengt. Veel van de
manieren waarop je machine in gevaar kan worden gebracht, vereisen dat
de indringer je machine opnieuw opstart of hem uitschakelt.
Controleer op tekenen van geknoei met de kast of de omgeving van de
computer. Hoewel veel indringers hun sporen in de logbestanden
verwijderen, is het een goed idee om ze te controleren en enige
discrepantie op te merken.
Het is ook een goed idee om loggegevens op een veilige plaats op te
slaan, bijvoorbeeld op een toegewijde log server op je goed beschermde
netwerk. Als een machine eenmaal te maken heeft gehad met een aanval,
zijn loggegevens van weinig nut meer, omdat ze hoogstwaarschijnlijk
ook zijn aangepast door de indringer.
De syslog daemon kan zo worden ingesteld dat hij loggegevens
automatisch naar een centrale syslog server stuurt, maar dit wordt
kenmerkend ongecodeerd gedaan, zodat een indringer de mogelijkheid
heeft om de gegevens te bekijken terwijl ze worden verzonden. Dit kan
informatie over je netwerk blootgeven, waarvan het niet de bedoeling
is dat het openbaar wordt. Er zijn syslog daemons beschikbaar die de
gegevens coderen terwijl ze worden verzonden.
Wees je ook bewust dat het namaken van syslogberichten gemakkelijk is
-- met een speciaal programma dat reeds gepubliceerd is. Syslog
accepteert zelfs net log entries die het doen voorkomen alsof ze van
de lokale host afkomstig zijn, zonder enige aanwijzing over hun ware
herkomst.
Enkele dingen die je moet controleren in je logs:
· korte of onvolledige logs
· logs die vreemde tijdstippen bevatten
· logs met verkeerde permissies of eigendomsrecht
· registraties van het opnieuw opstarten van het systeem of diensten
· ontbrekende logs
· su entries of logins vanaf vreemde plaatsen
We zullen systeemloggegevens ``later'' in deze HOWTO bespreken.
4. Lokale beveiliging
Het volgende waar we naar gaan kijken is de beveiliging van je systeem
tegen aanvallen van lokale gebruikers. Zeiden we zojuist lokale
gebruikers? Ja!
Toegang verkrijgen tot een lokaal gebruikersaccount is een van de
eerste dingen die indringers op een systeem proberen op hun weg naar
het misbruiken van het root account. Met een lakse lokale beveiliging
kunnen ze hun normale gebruikerstoegang "upgraden" naar een
roottoegang door gebruik te maken van een verscheidenheid aan bugs en
minnetjes ingestelde lokale diensten. Als je ervoor zorgt dat je
lokale beveiliging waterdicht is, zal de indringer nog een hindernis
moeten nemen.
Lokale gebruikers kunnen ook een hoop schade aanrichten op je systeem,
zelfs (juist) als ze inderdaad diegene zijn die ze zeggen dat ze zijn.
Het verstrekken van accounts aan mensen die je niet kent of van wie je
geen achtergrondinformatie hebt, is een erg slecht idee.
4.1. Nieuwe accounts aanmaken
Je moet ervan overtuigd zijn dat je gebruikersaccounts verschaft met
slechts de minimale vereisten voor de taak die ze moeten doen. Als je
je zoon (10 jaar) een account verschaft, zul je wellicht willen dat
hij alleen toegang heeft tot een tekstverwerker of tekenprogramma,
maar geen gegevens kan verwijderen die niet van hem zijn.
Enkele goede vuistregels als je andere mensen rechtmatige toegang tot
je Linux-machine toestaat:
· Geef ze het minimale aantal privileges dat ze nodig hebben.
· Weet wanneer/waar vandaan ze inloggen of waar vandaan ze zouden
moeten inloggen.
· Verwijder niet gebruikte accounts.
· Het gebruik van hetzelfde gebruikers ID op alle computers en
netwerken is aan te raden om het onderhoud van accounts te
vereenvoudigen. Ook staat het een eenvoudigere analyse van
loggegevens toe.
· Het aanmaken van groeps-gebruiker ID's zou absoluut verboden moeten
zijn. Gebruikersaccounts zorgen ook voor verantwoordelijkheid en
dit is bij groepsaccounts niet mogelijk.
Veel lokale gebruikersaccounts die gebruikt worden bij een aanval zijn
in geen maanden of jaren meer gebruikt. Omdat niemand ze gebruikt,
zorgen ze voor een ideaal aanvalsvoertuig.
4.2. Root beveiliging
Het meest gewilde account op je machine is het root (superuser)
account. Dit account heeft zeggenschap over de gehele machine, wat
ook zeggenschap kan inhouden over andere machines op het netwerk.
Onthoud dat je het root account alleen moet gebruiken voor hele korte
specifieke taken en dat het meestal uitgevoerd moet worden als een
normale gebruiker. Zelfs kleine foutjes als je ingelogd bent als root
kunnen problemen veroorzaken. Hoe korter je ingelogd bent met root
privileges, hoe veiliger het is.
Enkele trucks om te voorkomen dat je je computer overhoop haalt als
root:
· Als je bezig bent met een complex commando, probeer het dan eerst
op een niet-destructieve manier ... vooral commando's die wildcards
gebruiken: als je bijvoorbeeld "rm foo*.bar" wilt doen, doe dan
eerst "ls foo*.bar" om zeker te weten dat je de bestanden
verwijdert die je wilde verwijderen. Het gebruik van echo in plaats
van destructieve commando's werkt soms ook.
· Voorzie je gebruikers van een standaard alias voor het rm commando
om een bevestiging te vragen voordat ze bestanden verwijderen.
· Wordt alleen root om enkele specifieke taken uit te voeren. Als je
jezelf erop betrapt dat je probeert uit te vinden hoe iets werkt,
ga dan eerst terug naar de gewone gebruiker-shell, totdat je zeker
weet wat er als root gedaan moet worden.
· Het command path voor de root gebruiker is erg belangrijk. Het
command path (dat wil zeggen de PATH omgevingsvariabele)
specificeert de directory's waarin de shell zoekt naar programma's.
Probeer het command path voor de root gebruiker zoveel mogelijk te
beperken en zet nooit een . (hetgeen betekent "de huidige
directory") in je PATH. Zorg er bovendien voor dat je nooit
directory's met schrijfpermissie in je zoekpad hebt, omdat dit
aanvallers toestaat om bestaande binary's aan te passen of nieuwe
binary's aan je zoekpad toe te voegen, hetgeen hen toestaat als
root te opereren de volgende keer dat je dat commando uitvoert.
· Gebruik nooit de rlogin/rsh/rexec tools (genaamd de r-utility's)
als root. Ze zijn onderhevig aan vele soorten aanvallen en zijn
ronduit gevaarlijk als je ze uitvoert als root. Maak nooit een
.rhosts bestand aan voor root.
· Het /etc/securetty bestand bevat een lijst met terminals waarop
root in kan loggen. Standaard (onder Red Hat Linux) is dit
ingesteld op alleen de lokale virtuele consoles (vty's). Wees erg
voorzichtig met het toevoegen van iets anders aan dit bestand. Je
zou indirect op je normale gebruikersaccount in moeten kunnen
loggen en vervolgens su als dat nodig is (hopelijk via ``ssh'' of
een ander versleuteld kanaal), zodat er geen reden is waarom je
direct als root in zou moeten loggen.
· Wees altijd langzaam en weloverwogen als je bezig bent als root. Je
acties kunnen een heleboel dingen beïnvloeden. Denk na voordat je
typt!
Als het absoluut noodzakelijk is om iemand (hopelijk erg vertrouwd)
roottoegang tot je machine toe te staan, zijn er een aantal tools die
kunnen helpen. sudo staat gebruikers toe hun wachtwoord te gebruiken
om toegang te krijgen tot een beperkte set commando's als root.
Zodoende kun je, bijvoorbeeld, een gebruiker in staat stellen om
verwijderbare media uit te werpen en te mounten op je Linux box, maar
verder geen andere root privileges te hebben. sudo houdt ook een log
bij van alle geslaagde en mislukte sudo pogingen, zodat je uit kunt
zoeken wie welk commando gebruikte om wat te doen. Om deze reden werkt
sudo zelfs goed op plaatsen waar een aantal mensen root toegang
hebben, omdat het je helpt om aangebrachte wijzigingen bij te houden.
Hoewel sudo gebruikt kan worden om bepaalde gebruikers bepaalde
privileges voor bepaalde taken te geven, heeft het een aantal
tekortkomingen. Het moet alleen gebruikt worden voor een beperkt
takenpakket, zoals een server opnieuw opstarten of nieuwe gebruikers
toevoegen. Elk programma waarbij het uitwijken naar een shell mogelijk
is, zal root toegang verschaffen aan een gebruiker die het aanroept
via sudo. Dit omvat de meeste tekstverwerkers bijvoorbeeld. Ook een
programma zo onschadelijk als /bin/cat kan worden gebruikt om
bestanden te overschrijven, waarmee het mogelijk zou kunnen worden om
root te misbruiken. Beschouw sudo als een middel voor het toekennen
van verantwoordelijkheden en verwacht niet dat het de root gebruiker
kan vervangen en tevens veilig is.
5. Beveiliging van bestanden en bestandssystemen
Een paar minuten van voorbereiding en planning vooraf, voordat je je
systemen online zet, kan helpen ze (en de gegevens die erop opgeslagen
zijn) te beschermen.
· Er zou nooit een reden mogen zijn om toe te staan dat SUID/SGID
programma's uitgevoerd mogen worden vanuit de home directory's van
gebruikers. Gebruik de nosuid optie in /etc/fstab voor partities
die beschrijfbaar zijn door anderen dan root. Je wilt misschien ook
nodev en noexec toepassen op de home partities van gebruikers,
evenals op /var, dus het uitvoeren van programma's is verboden, net
als het creëren van character of block devices, wat trouwens toch
nooit noodzakelijk zou moeten zijn.
· Als je bestandssystemen exporteert middels NFS, let er dan op dat
je /etc/exports instelt met de meest beperkte toegang mogelijk. Dit
houdt in dat je geen gebruik moet maken van wildcards, geen root
schrijfpermissie toestaat en waar mogelijk read-only exporteert.
· Stel de bestandsaanmaak umask van je gebruikers zo beperkt mogelijk
in. Zie ``umask instellingen''.
· Als je gebruik maakt van een netwerk bestandssysteem zoals NFS om
bestandssystemen te mounten, let er dan op dat je /etc/exports
instelt met geschikte beperkingen. Kenmerkend is het gebruik van
'nodev',
· Stel limieten in voor het bestandssysteem in plaats van het
toestaan van unlimited, wat standaard is. Je kunt de limieten per
gebruiker beheren door gebruik te maken van de resource-limits PAM
module en /etc/pam.d/limits.conf. De limieten voor de groep users
kunnen er bijvoorbeeld zo uit zien:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
Dit zegt: verbied het creëren van core bestanden, beperk het aantal
processen tot 50 en beperk het geheugengebruik tot 5M per gebruiker.
· De /var/log/wtmp en /var/run/utmp bestanden bevatten de login
records van alle gebruikers op je systeem. Hun zuiverheid moet
behouden blijven, omdat ze gebruikt kunnen worden om te bepalen
wanneer en waar vandaan een gebruiker (of een mogelijke indringer)
je systeem is binnengekomen. Deze bestanden moeten ook 644
permissies hebben, zonder dat het invloed
