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.
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./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. umask
van je gebruikers zo beperkt
mogelijk in. Zie
umask instellingen./etc/exports
instelt met geschikte beperkingen. Kenmerkend is het gebruik van 'nodev',
`nosuid' en misschien `noexec' wenselijk.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./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 heeft op het normale systeemgebruik./etc/passwd
of
/etc/shadow
). Zie de chattr
(1) man pagina voor informatie
over het onveranderlijke bit.
Zoek alle SUID/SGID programma's op je systeem en houd bij wat ze
zijn, zodat je je bewust bent van enige veranderingen die kunnen duiden op
een mogelijke indringer. Gebruik het volgende commando om te zoeken naar
alle SUID/SGID programma's op je systeem:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
De Debian distributie voert elke nacht een taak uit om te bepalen welke
SUID programma's er bestaan. Het vergelijkt het dan met de uitvoer van de
vorige nacht. Je kunt kijken in /var/log/setuid*
voor deze log.
Je kunt de SUID of SGID permissies op een verdacht programma verwijderen
met chmod
en ze dan terugzetten als je denkt dat dat absoluut nodig
is.
root# find / -perm -2 ! -type l -ls
en verzeker je ervan dat je weet waarom deze bestanden schrijfpermissie
hebben. Bij normaal gebruik zullen verscheidene bestanden schrijfpermissie
voor iedereen hebben, inclusief enkele van /dev
en symbolische links,
dus middels ! -type l
worden deze niet meegenomen door het voorgaande
find
commando.
root# find / -nouser -o -nogroup -print
.rhosts
bestanden zou onderdeel uit moeten
maken van je vaste systeembeheertaken, omdat deze bestanden
niet toegestaan zouden mogen zijn op je systeem. Onthoud, een cracker heeft
slechts één onveilig account nodig om mogelijk toegang tot je
gehele netwerk te verkrijgen. Je kunt alle .rhosts
bestanden op je
systeem vinden met het volgende commando:
root# find /home -name .rhosts -print
Het umask
commando kan gebruikt worden om de standaard manier
waarop bestanden op je systeem aangemaakt worden te bepalen. Het is de achtste
aanvulling van de gewenste bestandsmodus. Als bestanden worden aangemaakt
zonder te letten op hun permissie-instellingen, kan de gebruiker onbewust
lees- of schrijfpermissie geven aan iemand die deze permissie niet mag
hebben. Kenmerkende umask
instellingen bevatten 022
,
027
en 077
(welke de meest beperkte is). Normaal
gesproken wordt umask ingesteld in /etc/profile
, zodat het van
toepassing is op alle gebruikers op het systeem. Het bestandsaanmaak-mask
kan worden berekend door de gewenste waarde af te trekken van 777. Met
andere woorden, een umask van 777 heeft tot gevolg dat nieuw aangemaakte
bestanden voor niemand lees-, schrijf- of uitvoerpermissies bevatten. Een
mask van 666 heeft tot gevolg dat nieuw aangemaakte bestanden een mask van
111 hebben. Je kunt bijvoorbeeld een regel hebben die er zo uitziet:
# Set the user's default umask
umask 033
Let erop dat je de umask van root 077
maakt, wat lees-, schrijf
en uitvoerpermissie voor andere gebruikers uitschakelt, tenzij het expliciet
is gewijzigd met chmod
. In dit geval zullen nieuw aangemaakte
directory's 744 permissies hebben, verkregen door 033 af te trekken van 777.
Nieuw aangemaakte bestanden die gebruik maken van de 033 umask, zullen
permissies van 644 hebben.
Als je Red Hat gebruikt en je houdt aan hun gebruiker- en groep-ID
aanmaakschema (User Private Groups), is het alleen noodzakelijk om
002
voor een umask
te gebruiken. Dit komt door het feit dat
de standaard instelling één gebruiker per groep is.
Het is belangrijk om je ervan te verzekeren dat je systeembestanden niet open staan voor aanpassingen door gebruikers en groepen die zulk systeemonderhoud niet zouden moeten doen.
Unix scheidt toegangsbeheer op bestanden en directory's volgens drie kenmerken: eigenaar, groep en anderen. Er is altijd exact één eigenaar, een willekeurig aantal leden van de groep en alle anderen.
Een korte uitleg van Unix permissies:
Eigendom - Welke gebruiker(s) en groep(en) heeft/hebben het beheer over de permissie-instellingen van de node en parent van de node.
Permissies - Bits die kunnen worden ingesteld of opnieuw ingesteld kunnen worden om bepaalde soorten toegang tot ze te kunnen verlenen. Permissies voor directory's kunnen een andere betekenis hebben dan dezelfde set permissies voor bestanden.
Lezen:
Schrijven:
Uitvoeren:
Het "sticky bit" heeft ook een andere betekenis als het toegepast wordt op
directory's dan wanneer het toegepast wordt op bestanden. Als het "sticky
bit" wordt ingesteld op een directory, mag een gebruiker alleen bestanden
verwijderen die zijn eigendom zijn of waarvoor hem expliciet
schrijfpermissie is verleend, zelfs wanneer hij schrijfpermissie heeft
voor de directory. Dit is ontworpen voor directory's als /tmp
, die
schrijfpermissie voor iedereen hebben, maar waar het misschien niet
wenselijk is dat elke gebruiker naar wens bestanden kan verwijderen. Het
"sticky bit" is te zien als een t
in een lange directory
opsomming.
Dit beschrijft set-uder-id permissies op het bestand. Als de set-user-ID access mode is ingesteld in de eigendomsrechten en het bestand is executable, zullen processen die het uitvoeren toegang verkrijgen tot systeembronnen, gebaseerd op de gebruiker die eigenaar van het bestand is, in tegenstelling tot de gebruiker die het proces heeft aangemaakt. Dit is de oorzaak van de vele "buffer overflow" misbruiken.
Indien ingesteld in de groeppermissies, beheert deze bit de "set-group-ID" status van een bestand. Dit gaat op dezelfde manier als SUID, behalve dat het nu op de groep betrekking heeft. Het bestand moet executable zijn voordat dit enig effect kan hebben.
Als je het SGID bit op een directory instelt (met chmod g+s directory
), hebben bestanden die in die directory aangemaakt
zijn hun groep ingesteld op de groep van de directory.
Jij - De eigenaar van het bestand
Groep - De groep waar je toe behoort
Iedereen - Iedereen op het systeem die niet de eigenaar is en geen deel uitmaakt van de groep
Bestandsvoorbeeld:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1e bit - directory? (nee)
2e bit - lezen door eigenaar? (ja, door kevin)
3e bit - schrijven door eigenaar? (ja, door kevin)
4e bit - uitvoeren door eigenaar? (nee)
5e bit - lezen door groep? (ja, door users)
6e bit - schrijven door groep? (nee)
7e bit - uitvoeren door groep? (nee)
8e bit - lezen door iedereen? (ja, door iedereen)
9e bit - schrijven door iedereen? (nee)
10e bit - uitvoeren door iedereen? (nee)
De volgende regels zijn voorbeelden van de minimale set van permissies die vereist zijn voor de beschreven toegang. Misschien wil je meer permissies geven dan hetgeen hier opgesomd is, maar dit zou moeten beschrijven wat deze minimale permissies op bestanden doen:
-r-------- Staat leestoegang op het bestand toe aan de eigenaar.
--w------- Staat het de eigenaar toe om het bestand aan te passen of te
verwijderen.(Merk op dat iedereen met schrijfpermissie op de
directory waar het bestand zich in bevindt, het kan overschrijven
en dus verwijderen.)
---x------ De eigenaar kan dit programma uitvoeren, maar geen shell scripts
waarvoor ook nog leestoegang nodig is.
---s------ Uitvoeren is mogelijk met een effectieve User-ID = naar eigenaar.
--------s- Uitvoeren is mogelijk met een effectieve Group-ID = naar groep.
-rw------T Geen update van "last modified time". Wordt meestal gebruikt voor
swap bestanden.
---t------ Geen effect.(voorheen sticky bit)
Directoryvoorbeeld:
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1e bit - directory? (ja, het bevat veel bestanden)
2e bit - lezen door eigenaar? (ja, door kevin)
3e bit - schrijven door eigenaar? (ja, door kevin)
4e bit - uitvoeren door eigenaar? (ja, door kevin)
5e bit - lezen door groep? (ja, door users)
6e bit - schrijven door groep? (nee)
7e bit - uitvoeren door groep? (ja, door users)
8e bit - lezen door iedereen? (ja, door iedereen)
9e bit - schrijven door iedereen? (nee)
10e bit - uitvoeren door iedereen? (ja, door iedereeen)
De volgende regels zijn voorbeelden van de minimale set van permissies die vereist zijn voor de beschreven toegang. Misschien wil je meer permissies geven dat hetgeen hier opgesomd is, maar dit zou moeten beschrijven wat deze minimale permissies op directory's doen:
dr-------- De inhoud kan opgesomd worden, maar bestandsattributen kunnen niet
gelezen worden.
d--x------ De directory is toegankelijk en kan in opdrachten worden verwerkt
waarin het directorypad wordt gebruikt.
dr-x------ Bestandsattributen kunnen gelezen worden door de eigenaar
d-wx------ Bestanden kunnen worden aangemaakt/verwijderd, zelfs als de
directory niet de huidige is.
d------x-t Voorkomt dat bestanden worden verwijderd door anderen met
schrijftoegang. Wordt gebruikt bij /tmp.
d---s--s-- Geen effect.
Systeemconfiguratie bestanden (meestal in /etc
) zijn meestal
modus 640
(-rw-r-----
) en eigendom van root. Afhankelijk van
de beveiligingsvereisten van je site kun je dit aanpassen. Laat nooit enige
systeembestanden beschrijfbaar zijn voor een groep of iedereen. Sommige
configuratiebestanden, waaronder /etc/shadow
, zouden alleen leesbaar
voor root moeten zijn en directory's in /etc
zouden op z'n minst niet
toegankelijk voor anderen moeten zijn.
SUID shell scripts vormen een serieus beveiligingsrisico en om deze reden zal de kernel ze niet toejuichen. Ongeacht hoe veilig je denkt dat een shell script is, het kan worden misbruikt om een cracker een root shell te geven.
Een andere zeer goede manier om lokale (en ook netwerk) aanvallen op je
systeem op te sporen is het uitvoeren van een "integrity checker" zoals
Tripwire
, Aide
of Osiris
. Deze "Integrity
checkers" voeren een aantal controles uit op al je belangrijke binary's en
configuratiebestanden en vergelijkt ze met een database van eerdere,
goed-bewezen waarden als een naslagwerk. Kortom, alle veranderingen in de
bestanden zullen genoteerd worden.
Het is een goed idee om dit soort programma's op een floppy te installeren en dan het floppy tegen schrijven te beveiligen. Op deze manier kunnen indringers niet knoeien met de "Integrity checker" of de database veranderen. Als je zoiets eenmaal hebt ingesteld, is het een goed idee om het uit te voeren als een onderdeel van je normale beveiligingsbeheertaken om te zien of er iets is veranderd.
Je kunt zelfs een crontab
entry toevoegen om het
controleprogramma vanaf je floppy elke nacht uit te voeren en de resultaten
in de ochtend per e-mail te krijgen. Iets als:
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
zal je elke morgen om 5.15 uur een verslag mailen.
"Integrety checkers" kunnen een uitkomst zijn om indringers op te sporen voordat je ze op een andere manier in de gaten krijgt. Omdat er op een doorsnee systeem veel bestanden wijzigen, moet je voorzichtig zijn in het bepalen van wat het werk van een cracker is en wat je zelf gedaan hebt.
Je kunt de open source versie van Tripwire
vinden op
http://www.tripwire.org, zonder kosten.
Handleidingen en ondersteuning kunnen aangeschaft worden.
Aide
vind je op
http://www.cs.tut.fi/~rammer/aide.html.
Osiris
vind je op
http://www.shmoo.com/osiris/.
"Trojan Horses" zijn genoemd naar de fabelachtige tactische zet in Homer's "Iliad". Het idee is dat een cracker een programma of binary dat er goed uitziet verspreidt en andere mensen aanmoedigt het te downloaden en het uit te voeren als root. Het programma kan vervolgens schade aanrichten op hun systeem als ze niet opletten. Terwijl ze denken dat de binary die ze zojuist hebben verkregen iets doet (en dat is wellicht ook zo), schaadt het ook hun beveiliging.
Je moet voorzichtig zijn welke programma's je installeert op je computer. Red Hat levert MD5 checksums en PGP signatures op zijn RPM bestanden, zodat je kunt verifiëren dat je het origineel installeert. Andere distributies hebben soortgelijke methoden. Je moet nooit enige onbekende binary, waarvan je de source niet hebt, als root uitvoeren! Er zijn maar weinig aanvallers bereid om source code vrij te geven, zodat het in het openbaar aan een nauwkeurig onderzoek kan worden onderworpen.
Hoewel het veelomvattend kan zijn, vergewis je er dan van dat je de source van een programma van de originele distributie site afhaalt. Als het programa uitgevoerd gaat worden als root, zorg dan dat of jij of iemand die je vertrouwt de source heeft bekeken en geverifieerd heeft.