Några minuters förberedelse och planering innann du kopplar upp ditt system kan hjälpa till att skydda ditt system och den data som finns lagrad på det.
@users hard core 0
@users hard nproc 50
@users hard rss 5000
Detta säger att det är förbjudet att skapa core-filer, begränsar antalet processer till 50, och begränsar minnesanvändningen per användare till 5Mb.
Hitta alla SUID/SGID-program på ditt system, och håll reda på vad de gör, så att du är medveten om alla ändringar som tyder på en potentiell inkräktare. Använd följande kommando för att hitta alla SUID/SGID-program på ditt system:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
root# find / -perm -2 -print
och se till att du varför de filerna är skrivbara. I normal operation så är flera filer skrivbara, inklusive några från /dev och symboliska länkar.
Filer utan ägare kan också vara en indikation att en inkräktare har haft tillgång till ditt system. Du kan hitta filer som inte har någon ägare eller inte tillhör någon grupp med kommandot:
root# find / -nouser -o -nogroup -print
root# find /home -name .rhosts -print
Kommandot umask kan användas för att bestämma/ta reda på vilka rättigheter som skapade filer skall få som standard på ditt system. Det är det oktala komplementet till filrättigheterna. Om filer skapas utan hänsysn till rättigheter så kan en användare oavsiktligt ge läs eller skrivrättigheter till någon som inte borde ha det. Typiska umask-inställningar är 022, 027 och 077 (vilket är det mest restriktiva). Normalt sätts umask i /etc/profile så det gäller alla användare på systemet. Du kan till exempel ha en rad som ser ut så här:
# Set the user's default umask
umask 033
Om du använder RedHat, och använder deras sätt att skapa användare och grupper (User Private Groups), så räcker det att använda 002 som umask. Detta för att standardkonfigurationen är en användare per grupp. (Åtminstonde versionerna 1.3 och 2.0 av Debian gör också detta!(SvÖ))
Det är viktigt att du försäkrar dig om att dina systemfiler inte är öppna för slapphänt modifiering av användare och grupper som inte borde utöva sådant systemunderhåll.
UNIX delar upp accesskontroll på filer och kataloger i tre kategorier: ägare, grupp och andra. Det finns alltid exakt en användare, hur många medlemmar av gruppen som helst och alla andra.
En snabb förklaring av rättigheter i UNIX:
Den "klibbiga" (sticky) biten har också olika betydelse när den finns på kataloger. Om den är satt på en katalog så får en användare endast radera filer som användaren äger eller filer där han har explicit skrivrättighet, även om han har skrivrättighet till katalogen. Detta är gjort för kataloger som /tmp, vilken är skrivbar för alla, men det kanske inte är önskvärt att en användare kan ta bort filer som han vill. Denna biten ses som ett 't' i en lång kataloglistning.
Detta beskriver sätt-användar-id rättigheter för filen. När SUID är satt i ägarrättigheterna, och filen är exekverbar, så får processer som kör den tillgång till systemresurser baserat på användaren som startade processen. Detta är anledningen till många "buffer overflow"-attacker.
Om detta är satt i grupprättigheterna så kontrollerar denna biten sätt-grupp-id statusen för en fil. Detta beter sig på samma sätt som SUID, förutom att gruppen påverkas istället. Filen måste även vara exekverbar för att det skall ha någon effekt.
Om du sätter SGID biten för en katalog (med "chmod g+s katalognamn"), så kommer filer som skapas i den katalogen att ha sin grupp satt till katalogens grupp.
Du - Ägaren av filen
Grupp - Gruppen du tillhör
Alla - Vem som helst på systemet som inte är ägare eller medlem i gruppen.
Filexempel:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1st bit - katalog? (nej)
2nd bit - läsbar för ägaren? (ja, för kevin)
3rd bit - skrivbar för ägaren? (ja, för kevin)
4th bit - exekverbar för ägaren? (nej)
5th bit - läsbar för gruppen? (ja, för users)
6th bit - skrivbar för gruppen? (nej)
7th bit - exekverbar för gruppen?(nej)
8th bit - läsbar för alla? (ja, för alla)
9th bit - skrivbar för alla? (nej)
10th bit - exekverbar för alla? (nej)
-r-------- Tillåt läsacces til filen för ägaren.
--w------- Tillåter ägaren att ändra eller radera filen.
---x------ Ägaren kan exekvera detta program, men inte shellskript
där även läsrättigheter krävs.
---s------ Kommer att exekvera med användar-id = ägare.
-------s-- Kommer att exekvera med användar-id = grupp.
-rw------T Ingen uppdatering av "sista modifieringstid". Vanligtvis
för swapfiler.
---t------ Ingen effekt. (före detta "sticky bit")
Katalogexempel:
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1st bit - katalog? (ja, den kan innehålla filer)
2nd bit - läsbar för ägare? (ja, för kevin)
3rd bit - skrivbar för ägare? (ja, för kevin)
4th bit - exekverbar för ägare? (ja, för kevin)
5th bit - läsbar för grupp? (ja, för users)
6th bit - skrivbar för grupp? (nej)
7th bit - exekverbar för grupp? (ja, för users)
8th bit - läsbar för alla? (ja, för alla)
9th bit - skrivbar för alla? (nej)
10th bit - exekverbar för alla? (ja, för alla)
Följande rader är exempel på de minimala rättigheter som krävs för att kunna utföra den access som beskrivs. Du kanske vill ge mer rättigheter än vad som listas, men detta bör beskriva vad de minimala rättigheterna på kataloger gör:
dr-------- Innehållet kan listas men filattributen kan inte läsas.
d--x------ Man kan gå in i katalogen och den kan användas i fulla
exekveringssökvägar.
dr-x------ Filattribut kan nu läsas av ägaren.
d-wx------ Filer kan nu skapas/raderas, även om katalogen inte är
den aktuella.
d------x-t Förhindrar att filer kan raderas av andra med
skrivrättigheter. Används på /tmp
d---s--s-- Ingen effekt.
Filer för systemkonfiguration (vanligtvis i /etc) har oftast rättigheterna 640 (-rw-r-----) och ägs av root. Beroende på säkerhetskraven på din sajt, så kanske du vill ändra detta. Låt aldrig systemfiler vara skrivbara för en grupp eller för alla. Vissa konfigurationsfiler, som /etc/shadow, bör endast vara läsbara för root. Kataloger i /etc bör åtminstonde inte vara tillgängliga för alla.
Shellskript med SUID-biten satt är en allvarlig säkerhetsrisk, av denna anledningen så tillåter inte kerneln sådana. Oavsett hur säkert du tycker att skriptet är, så kan det attackeras för att ge en cracker ett root-shell.
Ett annat bra sätt att upptäcka lokala attacker (och även från nätverket) mot ditt system, är att köra en integritetskontrollerare som Tripwire. Tripwire kör ett antal checksummor på alladina viktiga binärfiler och konfigurationsfiler och jämför dem med en databas med tidigare värden som man vet är korrekta. Vilket betyder att ändringar i filer noteras.
Det är en bra ide att installera Tripwire på en diskett, och sedan fysiskt skrivskydda disketten. Nu kan inkräktare inte mixtra med själva Tripwire eller ändra i databasen. När du väl har installerat Tripwire så är det en bra ide att köra det som en del av ditt normalasystemunderhåll för att se om något har ändrats.
Du kan till och med lägga till en post i crontab för att köra Tripwire från din diskett varje natt och sedan e-posta dig resultaten på morgonen. Något som:
# set mailto
MAILTO=kevin
# run tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
Tripwire kan vara en gudagåva för att upptäcka inkräktare tidigare än du hade gjort annars. Eftersom det är många filer som ändras på ett normalt system, så måste du vara försiktig med vad som är crackeraktivitet och vad du själv gör.
Trojanska hästar benämns efter Homeros bra litteratur. Iden är att du lägger upp ett program eller binär som verkar jättebra, och får andra personer att ladda ner det och köra det som root. Sedan, kan du äventyra deras system medans de inte är uppmärksamma. Medans de tror att binären som de laddade ner gör en sak (som den mycket väl kan göra), så äventyrar den samtidigt deras säkerhet.
Du skall vara nogrann med vilka program som du installerar på din maskin. RedHat tillhandahåller MD5-summor och PGP-signaturer för RPM-filer så du kan verifiera att du installerar rätt program. Andra distributioner har liknande metoder. Du skall aldrig köra en binärfil som du inte har källkoden till eller som inte är välkänd som root. Få attackerare är villiga att släppa källkoden till allmänheten.
Även om det kan vara komplext, se till att du hämtar källkoden för program från dess riktiga distributionssajt. Om programmet skall köra som root, se till att antingen du eller någon du litar på tittar igenom källkoden och verifierar den.