Een paar minuten van voorbereiding en planning voordat je je systemen online zet kan helpen om ze te beschermen en de data erop ook.
nosuid
optie in /etc/fstab
voor partities die
schrijf-baar zijn voor gebruikers die niet root zijn. Je kan ook nodev
en
noexec
gebruiken op de user's home partitie, en ook /var
, dit verbied
het draaien van programma's en het aanmaken van character en block devices, wat eigenlijk
nooit nodig is./etc/exports
dan
met de meest beperkende toegang mogelijk. Dit betekend geen wildcards, geen root schrijf
toegang, en zoveel mogelijk als read-only(alleen lezen) exporteren.umask
zo beperkt mogelijk.
Zie ook
umask settings./etc/pam.d/limits.conf
. Bijvoorbeeld, limieten voor de groep users
kan
er zo uitzien:
@users hard nproc 50
@users hard rss 5000
Dit zegt dat het verboden is om core files te maken, dat er maar 50 processen magen draaien, en maar 5M geheugen.
/var/log/wtml
en /var/run/utml
files bevatten de login lijst van
alle gebruikers op je systeem. Hun eenheid moet bewaard blijven, want
het kan gebruikt worden om vast te stellen wanneer en van waar een
gebruiker (of een mogelijke indringer) het systeem is binnen gekomen.
Deze files moeten ook de 644
permissie hebben, zonder het
beïnvloeden van het normale systeem.
/etc/passwd
en /etc/shadow
to gevolg hebben). Zie de chattr
(1) man page voor meer informatie over het
immutable bit.
Vindt alle SUIT/SGID programma's op je systeem en houdt deze in de gaten, dus wees bewust van elke verandering, die kan duiden op een waarschijnlijk indringer. Gebruik het volgende commando om alle SUID/SGID programma's op je systeem te vinden:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
De Debian distributie draait een job elke nacht om vast te stellen welke
SUID files er zijn. Het vergelijkt ze dan met de vorige nacht. Je kan
kijken in /var/log/suid*
voor een log.
Je kan het SUID of SQID permissie verwijderen op een verdacht
programma met chmod
, dan het terug veranderen als je het nodig
vindt.
root# find / -perm -2 ! -type l -ls
En weet zeker waarom deze files schrijf-baar zijn. In de normale gang van zaken
, zijn enkele files wereld leesbaar, inclusief enkele van /dev
,
en symbolische links, dus de ! -type l
haalt ze uit het vorige
find
commando.
Files zonder eigenaar kunnen ook ook een indicatie van een indringer zijn. Je kan alle files zonder eigenaar en groep op je systeem vinden door het volgende commando:
root# find / -nouser -o -nogroup -print
.rhosts
files vinden zou een van je reguliere taken moeten
zijn als systeem administrator, omdat deze files niet zijn toegestaan op
je systeem. Onthoud een cracker heeft maar een in-secure account nodig om
toegang te krijgen tot het hele netwerk. Je kunt alle .rhosts
files op je systeem vinden door het volgende commando:
root# find /home -name .rhosts -print
Tot slot, voordat je de permissies veranderen op iedere systeem file, weet dan zeker wat je doet. Verander nooit permissies op een files omdat dat je makkelijkste weg lijkt om iets werkende te krijgen. Altijd eerst vaststellen waarom de file die permissies heeft voordat je het veranderd.
Het umask
commando kan gebruikt worden om de standaard file creatie
mode op je systeem in te stellen.
Het is de octale aanvulling op de verzochte file mode.
Als een files is aangemaakt zonder om te kijken naar hun permissie
instellingen, kan de gebruiker lees en schrijf bevoegdheden
geven aan iemand die dat niet mag. Meestal bevatten de umask
instellingen 022
, 027
en 077
( wie het meest beperkt
is). Normaal is het umask ingesteld in /etc/profile
, zodat het betrekking
heeft op elke gebruiker op het systeem. Het file aanmaak mask kan uitgerekend worden
door de gewilde permissies van 777 af te trekken. In andere woorden, een umask
van 777 zou betekenen dat de file niet leesbaar, niet schrijf-baar of niet uitvoerbaar is
voor iedereen. Een mask van 666 zou betekenden dat de file een mask heeft van 111. Bij voorbeeld,
je kan een regel hebben als deze:
# Set the user's default umask
umask 033
Weet zeker dat je root's umask 077
maakt, dat schakeld lezen, schrijven en
uitvoer rechten voor iedere ander gebruiker uit, tenzij deze is veranderd met
chmod
.
Be sure to make root's umask 077
, which will disable read, write, and
execute permission for other users, unless explicitly changed using
chmod
. In dit geval zou een nieuwe directore de 744 permissies hebben,
verkregen door 033 van 777 aftetrekken. Nieuwe files met het 033 mask hebben de
644 permissie.
Als je Red Hat gebruik, en de gebruiker zit alleen in een groep met een zelfde naam
(User Private Groups), is 002
voldoen als umask
. Dit is doordat
de standaard configuratie is 1 gebruiker per groep.
Het is belangrijk dat je systeem files niet open zijn voor het zomaar bewerken van gebruikers en groepen die niet zulk systeem onderhoud moeten doen.
Unix verdeeld toegang controle op files en directories over drie groepen: owner(eigenaar), group(groep) en other(andere). Er is altijd een eigenaar, elk aantal leden van een groep, en de rest.
Een snelle uitleg over Unix rechten(permissions): A quick explanation of Unix permissions:
Eigendom(ownership) - Welke gebruiker(s) en groep(en) heeft(hebben) controle over de permissies over de node en de moeder node.
Permissies - Bits capable of being set or reset to allow certain types of access to it. Permissies van directories kunnen verschillende betekenissen hebben dan die van files.
Lezen:
Write:
Uitvoeren:
Het "sticky bit" heeft ook een andere betekenis op directories dan op files.
Als de sticky bit op een directory staat mag iemand alleen files weg gooien
als hij de eigenaar is, zelfs als hij schrijf rechten heeft op de directorie.
Alleen als er uitzonderlijke rechten worden toegewezen mag hij de file weggooien.
Dit is gemaakt voor directories als /tmp
, die voor iedereen schrijf-baar zijn,
maar waar het niet gewild is dat iedereen zomaar elke file kan weggooien. De sticky bit is
te zien als een t
in een lange directorie lijst.
Dit beschrijft het set-user-id recht op een file. Als de set user ID toegangs mode is ingesteld in de eigenaars rechten, en de file is uitvoerbaar, processen die het draaien hebben toegang de systeem bronnen als de eigenaar van de file, in tegenstelling to de gene die het proces startte. Dit is de oorzaak van veel "buffer overflow" misbruik.
Als dit ingesteld is in de groep permissies, houdt dit bit het "set group id" status van een file. Dit gedraagt zich net als SUID, alleen de groep is beïnvloed. De file moet uitvoerbaar zijn voor dit.
Als je het SGID bit op een directorie instelt (met chmod g+s directorie
),
files die aangemaakt worden in die dir hebben als groep de groep die eigenaar is van de directorie.
Jij - De eigenaar van de file
Groep - De groep waar de file aan toebehoord
Iedereen - Iedereen op het systeem die niet de eigenaar is of in de groep hoort.
File Voorbeeld:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1st bit - directorie? (nee)
2nd bit - lezen door eigenaar? (ja, door kevin)
3rd bit - schrijven door eigenaar? (ja, door kevin)
4th bit - uitvoeren door eigenaar? (nee)
5th bit - lezen door groep? (ja, door users)
6th bit - schrijven door groep? (nee)
7th bit - uitvoeren door groep? (nee)
8th bit - lezen door iedereen? (ja, door iedereen)
9th bit - schrijven door iedereen? (nee)
10th bit - uitvoeren door iedereen? (nee)
De volgende regels zijn voorbeelden van de minimale instellingen van rechten om aan de er achter getypte rechten te voldoen. Je kan meer rechten willen geven dan hieronder staan beschreven, maar dit moet beschrijven wat deze minimale rechten met files doen:
-r-------- Lees rechten op de file voor de eigenaar
--w------- Laat de eigenaar de file aanpassen of weggooien
(Notitie dat iedereen met schrijf rechten op de directory
de file kan overschrijven en dus verwijderen)
---x------ De eigenaar kan het programma uitvoeren, maar geen shell script
want deze hebben ook lees rechten nodig.
---s------ Laar de file uitvoeren met een effectief User ID = aan eigenaar
--------s- Laat de file uitvoeren met een effectief Group ID = aan de groep
-rw------T Geen update van "laatst veranderd tijd". Meestal voor swap files.
---t------ Geen effect. (sticky bit)
Directory Voorbeeld:
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1st bit - directorie? (ja, er staan veel files in)
2nd bit - lezen door eigenaar? (ja, door kevin)
3rd bit - schrijven door eigenaar? (ja, door kevin)
4th bit - uitvoeren door eigenaar? (ja, door kevin)
5th bit - lezen door groep? (ja, door users)
6th bit - schrijven door groep? (nee)
7th bit - uitvoeren door groep? (ja, door users)
8th bit - lezen door iedereen? (ja, door iedereen)
9th bit - schrijven door iedereen? (nee)
10th bit - uitvoeren door iedereen? (ja, door iedereen)
De volgende regels zijn voorbeelden van de minimale instellingen van rechten om aan de er achter getypte rechten te voldoen. Je kan meer rechten willen geven dan hieronder staan beschreven, maar dit moet beschrijven wat deze minimale rechten met directories doen:
dr-------- De inhoud kan bekeken worden, maar de file attributen kunnen niet gelezen worden
d--x------ Je kan de directory binnen gaan, en je kan hem gebruiken in een lang uitvoer path
dr-x------ De file attributen kunnen gelezen worden door eigenaar.
d-wx------ Files kunnen worden aangemaakt en verwijderd, zelfs als het niet de actieve directorie is
d------x-t Hou het tegen voor anderen met schrijf rechten om files weg te gooien. Gebruikt in /tmp
d---s--s-- Geen effect.
Systeem configuratie files (Normaal in /etc
) hebben meestal de 640
mode
(-rw-r-----
) en root is de eigenaar. Afhankelijk van je bedrijfs security eisen,
kun je dit veranderen. Laat een systeem file nooit schrijf-baar door een groep of
iedereen. Enkele configuratie files, zoals /etc/shadow
, moeten alleen leesbaar
zijn voor root, en directories in /etc
moeten op z'n minst niet toegankelijk
zijn voor anderen.
SUID shell scripts zijn een serieus security risico, en daardoor laat de kernel die scripts niet toe. Ongeacht van hoe secure je denkt dat je shell script is, het kan worden misbruikt om een cracker een root shell te geven.
Tripwire
Een ander zeer goede manier voor het detecteren van locale aanvallen (en ook op het netwerk)
op je systeem is het draaien van een intergeriteit controleur
zoals Tripwire
. Tripwire
draait een aantal controles op
alle belangrijke binaries en configuratie files en vergelijkt ze met een database
met de vorige files, goed voor een opmerking. Dus, elke verandering in een file
wordt aangegeven.
Het is een goed idee om Tripwire
te installeren op een floppy,
en dan het floppy fysiek op write protected zetten. Door dit kunnen indringers niet
met Tripwire
zelf knoeien en ook de database niet veranderen. Zodra
Tripwire
hebt geïnstalleerd, is het een goed idee om het te draaien
als een van je normale security administratie taken om te zien of er
iets is veranderd.
Je kan het ook toevoegen aan je crontab
en Tripwire
elke nacht
van je floppy laten draaien en je resulten 's morgens laten mailen. Zoiets als:
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
zal je elke morgen om 5:15 een verslag sturen.
Tripwire
kan een geluk zijn om indringers te detecteren voor dat
je ze zelf opmerkt. Doordat een hoop files veranderen op het gemiddelde
systeem, moet je onderscheid maken tussen wat je jouw werk is en wat
het werk van een cracker is.
Je kunt Tripwire
vinden op
http://www.tripwiresecurity.com,
Gratis. Handboeken en steun kan gekocht worden.
"Trojaanse paarden" zijn genoemd naar de fabelachtige strategie in Homer's "Iliad". Het idee is dat een cracker een programma maakt of een binary dat geweldig lijkt, en andere mensen aanmoedigt het te downloaden en het te draaien als root. Dan kan het programma hun systeem kraken als ze geen aandacht besteden. Terwijl ze denken dat het programmaatje dat ze net uitgevoerd hebben maar een ding doet, heeft het wel hun security doorbroken.
Je moet oppassen met de programma's die je installeert op je machine. Redhat heeft MD5 controles en PGP handtekeningen op hun RPM files zodat je kan verificeren dat het is wat je denk. Andere distributies hebben soortgelijke methoden. Je moet niet zomaar ieder onbekend programma draaien, vanwaar je geen source hebt, als root! Veel aanvallers willen een source code uitgeven aan het publieke onderzoek.
Hoewel het complex is, haal altijd je source van een echt distributie site. Als het gaat draaien als root, kijk dan eerst naar de source en bevestig deze.