Unix säkerhet - Unix security

Unix-säkerhet hänvisar till sätten att säkra ett Unix- eller Unix-liknande operativsystem . En säker miljö uppnås inte bara genom designkoncepten för dessa operativsystem, utan också genom vaksamma användar- och administrativa metoder.

Designkoncept

Behörigheter

En viktig säkerhetsfunktion i dessa system är filsystembehörigheterna . Alla filer i ett typiskt Unix -filsystem har inställda behörigheter som möjliggör olika åtkomst till en fil.

Behörigheter för en fil anges vanligtvis med kommandot chmod och ses genom kommandot ls . Till exempel: 

-r-xr-xr-x  1 root  wheel  745720 Sep  8  2002 /bin/sh

Unix -behörigheter tillåter olika användare tillgång till en fil. Olika användargrupper har olika behörigheter för en fil.

Mer avancerade Unix -filsystem inkluderar konceptet åtkomstkontrollista som gör det möjligt att bevilja behörighet till flera användare eller grupper. En åtkomstkontrollista kan användas för att ge ytterligare enskilda användare eller grupper tillstånd. Till exempel: 

/pvr [u::rwx,g::r-x,o::r-x/u::rwx,u:sue:rwx,g::r-x,m::rwx,o::r-x]

I det här exemplet, som är från den chacl kommando på Linux operativsystem användaren stämma beviljas skrivtillåtelse till / pvr katalogen.

Användargrupper

Användare under operativsystem i Unix -stil tillhör ofta hanterade grupper med specifika åtkomstbehörigheter. Detta gör det möjligt för användare att grupperas efter den åtkomstnivå de har till detta system. Många Unix implementeringar lägga ett extra lager av säkerhet genom att kräva att en användare vara medlem i den hjulanvändarrättigheter grupp för att få tillgång till sukommandot.

Root-åtkomst

De flesta Unix och Unix-liknande system har ett konto eller en grupp som gör det möjligt för en användare att utföra fullständig kontroll över systemet, ofta känt som ett rotkonto . Om åtkomst till detta konto erhålls av en oönskad användare resulterar detta i ett fullständigt brott mot systemet. Ett root -konto är dock nödvändigt för administrativa ändamål, och av ovanstående säkerhetsskäl används root -kontot sällan för dagliga ändamål ( sudoprogrammet används mer vanligt), så användningen av root -kontot kan övervakas närmare.

Rotåtkomst "som den ska vara" kan visualiseras av dem som känner till Superman -berättelserna med följande analogi :

Att använda ett rotkonto är snarare som att vara Superman; en administratörs vanliga användare liknar mer Clark Kent. Clark Kent blir Superman bara så länge det behövs för att rädda människor. Han återgår sedan till sin "förklädnad". Rootåtkomst bör användas på samma sätt. Clark Kent -förklädningen begränsar honom dock inte riktigt, eftersom han fortfarande kan använda sina superkrafter. Detta är analogt med att använda sudoprogrammet.

Användar- och administrativa tekniker

Unix har många verktyg som kan förbättra säkerheten om de används på rätt sätt av användare och administratörer.

Lösenord

Att välja ett starkt lösenord och skydda det ordentligt är förmodligen de viktigaste sakerna en användare kan göra för att förbättra Unix -säkerheten. I Unix -system lagras /etc/passwdviktig information om användare under filen. Denna fil håller reda på de användare som är registrerade i systemet och deras huvudsakliga definitioner. Lösenord, eller mer korrekt, hash av lösenordet, kan också lagras på samma plats. Posterna i /etc/passwdupptar exakt en rad vardera och har följande form: 

nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin

Ett exempel skulle vara: 

xfze:$$1zuW2nX3sslp3qJm9MYDdglEApAc36r/:1000:100:Daniel Ernesto Ortiz Costa:/home/xfze:/bin/bash

Eftersom alla användare måste ha läsåtkomst till /etc/passwdfilen för att kunna utföra många vanliga uppgifter ( ls -l /homekommer att använda för /etc/passwdatt mappa UID till till exempel inloggningsnamn), kan vem som helst också läsa andra användares lösenordshaschar. För att lösa detta problem /etc/shadowskapades filen för att lagra lösenordets hash, där endast root har läsåtkomst. Under lösenordskuggning ersätts det andra fältet ( lösenordshash ) med ett 'x' som uppmanar systemet att hämta motsvarande användares lösenord via /etc/shadowfilen.

Den /etc/shadowfilen ofta endast innehåller värden för de första två områden: 

xfze:$$1zuW2nX3sslp3qJm9MYDdglEApAc36r/:::::

De återstående fälten i /etc/shadowfilen inkluderar:

  1. Minsta antal dagar mellan lösenordsändringar
  2. Det maximala antalet dagar till lösenordet måste ändras
  3. Antalet varningsdagar som ges före lösenordet måste ändras
  4. Antalet dagar efter lösenordet måste ändras när kontot blir oanvändbart
  5. Datumet (uttryckt som antalet dagar sedan 1 januari 1970 ) då kontot har gått ut

Dessa fält kan användas för att förbättra Unix -säkerheten genom att tillämpa en säkerhetspolicy för lösenord.

Användare och konton

Administratörer bör radera gamla konton omedelbart.

  • su , sudo , endast ssh , inga fjärrrotinloggningar

Programvaruunderhåll

Patchning

Operativsystem, liksom all programvara, kan innehålla buggar som behöver åtgärdas eller kan förbättras med tillägg av nya funktioner. För att uppdatera operativsystemet på ett säkert sätt krävs att programvaran kommer från en pålitlig källa och inte har ändrats sedan den förpackades. Vanliga metoder för att verifiera att operativsystemets patchar inte har ändrats inkluderar användning av kryptografisk hash , till exempel en MD5- baserad kontrollsumma, eller användning av skrivskyddad media.

Ur säkerhetssynpunkt är den specifika förpackningsmetoden, till exempel RPM Package Manager -formatet ursprungligen från Red Hat Linux, inte lika viktig som användningen av funktioner som säkerställer själva korrigeringen.

Källfördelningar

Källdistributioner inkluderar möjligheten att undersöka koden för misstänkt innehåll. Nackdelen, frånvarande ett medföljande kryptografiskt hashvärde, är att användaren måste kunna utföra en säkerhetsanalys av koden själv.

RPM -paket

Linuxdistributioner som använder RPM Package Manager -formatet för att tillhandahålla basfunktioner och programuppdateringar använder MD5 och GPG för att säkerställa innehållets integritet. Hashvärdena förpackas med RPM -filen och verifieras när paketet installeras.

Debian -paket

Linuxdistributioner som använder paketformatet Debian .deb för att tillhandahålla basfunktioner och programuppdateringar använder GPG -signaturer för att säkerställa innehållets integritet. En signatur beräknas när paketet konstrueras och verifieras senare när paketet installeras.

Andra leverantörer och distributioner

Oavsett leverantör eller distribution bör alla programvarudistributioner tillhandahålla en mekanism för att verifiera att programvaran är legitim och inte har ändrats sedan den ursprungligen förpackades.

Tjänster

Onödig systemprogramvara bör inte installeras eller konfigureras på ett system. Programvara som inte längre behövs bör om möjligt tas bort helt.

  • Identifiera vilka tjänster som körs
    • netstat -na
    • lsof
    • nmap
    • sockstat -4 ( FreeBSD )

Kommandona inetd och xinetd fungerar som superservrar för en mängd olika nätverksprotokoll som rlogin , telnet och ftp .

Stänga av onödiga tjänster

  • använder update-rc.d på Debian
  • använder chkconfig på Red Hat Linux
  • med /etc/rc.conf och /usr/local/etc/rc.d på FreeBSD (nämn /etc/rc.local)
  • använder rc-update på Gentoo Linux

Detta tillvägagångssätt brukar kallas proaktiv säkerhet . Det finns vissa operativsystem som är säkra som standard . Bland annat är de fria BSD -smakerna ( FreeBSD , NetBSD och OpenBSD ) proaktivt säkra. Exempelvis beskriver utmatningen av netstat på en NetBSD 3.0 -arbetsstation tydligt denna teknik: 

$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        State
tcp        0      0  localhost.smtp         *.*                    LISTEN
tcp        0      0  *.ssh                  *.*                    LISTEN
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  localhost.smtp         *.*                    LISTEN
tcp6       0      0  *.ssh                  *.*                    LISTEN
Active UNIX domain sockets
Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
c0d10d80 dgram       0      0        0 c0cd8680        0 c0cb7000 -> /var/run/log
c0cb7000 dgram       0      0        0 c0cd8680        0        0 -> /var/run/log
c0cd8680 dgram       0      0 cb9639e8        0 c0d10d80        0 /var/run/log

Följande exempel från ett BSD -system 

$ sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sendmail   569    4 tcp    localhost.smtp        *.*
root     sshd       593    4 tcp    *.ssh                 *.*

Visar att på denna maskin bara SSH -tjänsten lyssnar på datorns offentliga nätverksgränssnitt . sendmail lyssnar bara på loopback -gränssnittet . Åtkomst till en tjänst kan begränsas ytterligare genom att använda en brandvägg .

Filsystem

Filsystemsäkerhet

Huvudartikel: Filsystemsbehörigheter

Filsystemsäkerhet inom UNIX och Unix-liknande system är baserat på 9 behörighetsbitar, användar- och grupp-ID-bitar och den klibbiga biten för totalt 12 bitar. Dessa behörigheter gäller nästan lika för alla filsystemobjekt som filer, kataloger och enheter.

De 9 tillståndsbitarna är indelade i tre grupper om tre bitar vardera. Den första gruppen beskriver behörigheterna för filägaren, den andra gruppen beskriver behörigheterna för en grupp som är associerad med filägaren eller katalogen som innehåller filen, och den tredje gruppen beskriver behörigheterna för alla processer som inte har samma användare ID som filen. Varje grupp med tre bitar innehåller en bit som anger att läs-, skriv- eller exekveringsåtkomst ges. När det gäller kataloger tolkas exekvering som behörighet att utföra ett filnamnsuppslag i katalogen.

Uppsättnings-användar-ID och uppsättningsgrupp-ID-bitar, vanligen förkortade set-UID respektive set-GID , används för att ändra identiteten för processen som kör en fil med endera eller båda av dessa bitar. En fil med set-UID- behörighetsbiten kommer att orsaka att en process som kör den filen tillfälligt byter det effektiva användar-ID till filägarens. En fil med set-GID- behörighetsbiten kommer att få en process som kör filen att tillfälligt byta det effektiva grupp-ID till filgruppens. En process kan sedan växla mellan det effektiva användar- eller grupp -ID som det ärvde från filen och det verkliga användar- eller grupp -ID som det ärvde när användaren loggade in på systemet. Detta ger en mekanism genom vilken en process kan begränsa de åtkomsträttigheter den har till de kodregioner som kräver dessa åtkomsträttigheter. Detta är en form av en säkerhetsteknik som kallas privilegieseparation och förbättrar programsäkerhet genom att begränsa oavsiktliga eller oönskade handlingar i en process.

En katalog med set-GID- behörighetsbiten kommer att orsaka att en nyskapad fil har ett initialt filgruppsvärde som är lika med filgruppen för katalogen. Detta ger en mekanism där ett delsystem, till exempel systemets e-postundersystem, kan skapa filer som har ett gemensamt filgruppsvärde så att set-GID- processer inom det undersystemet sedan kan läsa eller skriva filen.

Den klibbiga biten , formellt känd som den sparade texten på bytesbiten , har sitt namn från sitt ursprungliga syfte. Ursprungligen orsakade den klibbiga biten att en process ursprungliga minnesbild lagrades som en sammanhängande bild på hårddisken som användes för att lagra riktiga minnessidor när de inte användes. Detta förbättrade prestanda för vanligt utförda kommandon genom att göra den första minnesbilden lätt tillgänglig. Moderna UNIX -system utför inte längre den funktionen när biten är inställd, men namnet har ändå bevarats. När det gäller filer kan sticky-bit användas av systemet för att ange stilen för fillåsning som ska utföras. När det gäller kataloger förhindrar den klibbiga biten någon process, utom en som har superanvändarrättigheter eller en som har ett effektivt användar-ID för filägaren, från att ta bort en fil i den katalogen. Den klibbiga biten används oftast på offentligt skrivbara kataloger, till exempel de olika tillfälliga katalogerna i systemet.

Rot squash

Root squash är en speciell kartläggning av den fjärranslutna superanvändarens (root) identitet när identitetsautentisering används (lokal användare är samma som fjärranvändare). Under root squash mappas en klients uid 0 (root) till 65534 (ingen). Det är främst en funktion i NFS men kan också vara tillgänglig på andra system.

Root squash är en teknik för att undvika att privilegier eskalerar på klientmaskinen via Suid -körbara Setuid . Utan root squash kan en angripare generera suid -binärer på servern som körs som root på andra klienter, även om klientanvändaren inte har superanvändarprivilegier. Därför skyddar den klientmaskiner mot andra skadliga klienter. Det skyddar inte klienter mot en skadlig server (där root kan generera suid -binärer), inte heller skyddar den filer från någon annan användare än root (eftersom skadliga klienter kan utge sig för vilken användare som helst).

SELinux

SELinux är en uppsättning kärntillägg för att styra åtkomsten mer exakt och definierar strikt både om och hur filer, mappar, nätverksportar och andra resurser kan nås genom den begränsade processen. Detta system används mest för att begränsa processer (databas, server) snarare än mänskliga användare. Det kan också begränsa processer som körs som root. Andra distributioner använder jämförbara alternativ som AppArmor .

Virus och virusscannrar

Unix-liknande operativsystem är immuna mot de flesta Microsoft Windows-virus eftersom binära filer som skapats för att köras på Windows i allmänhet inte körs på andra plattformar. Många Unix -liknande installationer tillhandahåller emellertid fillagringstjänster till Microsoft Windows -klienter, till exempel genom användning av Samba -programvara , och kan oavsiktligt bli ett förråd för virus som lagras av användare. Det är vanligt att Unix -servrar fungerar som e -postöverföringsagenter och som en följd av detta installeras ofta virusskanning via e -post. Den ClamAV virusskydd finns i form av källkod och kan användas för att skanna Unix filsystem efter virus som infekterar andra operativsystem.

Det finns virus och maskar som riktar sig mot Unix-liknande operativsystem. Faktum är att den första datormask - Morris -masken - riktade sig mot Unix -system.

Brandväggar

Nätverksbrandvägg skyddar system och nätverk från nätverkshot som finns på motsatta sidan av brandväggen. Brandväggar kan blockera åtkomst till strikt interna tjänster, oönskade användare och i vissa fall filtrera nätverkstrafik efter innehåll.

iptables

iptables är aktuell användargränssnitt för att interagera med Linux kernel netfilter funktionalitet. Det ersatte ipchains . Andra Unix -liknande operativsystem kan ha sin egen inbyggda funktionalitet och andra brandväggsprodukter med öppen källkod finns. Mer detaljerad information om iptables finns på annat håll. En kort diskussion finns här för att beskriva hur iptables kan användas för att konfigurera en Linux -brandvägg.

netfilter tillhandahåller ett paketfilter med fullständigt tillstånd som kan konfigureras enligt nätverksgränssnitt , protokoll , käll- och/eller destinationsadress , källa och/eller destinationsport och paketets tillstånd. Ett nätverkspaket passerar flera kedjor mellan den tid det tas emot av ett nätverksgränssnitt och den tid det accepteras av värden eller vidarebefordras till en annan värd. De vanliga kedjorna är INGÅNG , UTGÅNG och FRAMÅT . Den INPUT kedjan genomkorsas för alla paket när de tas emot av en nätverksgränssnitt, oavsett om de skall accepteras av värden eller vidarebefordras till en annan värd. Den OUTPUT kedjan genomkorsas för alla paket när de sänds av ett nätverksgränssnitt. Den FORWARD kedjan förs tvärs för dessa paket håller på att dirigeras genom värd från ett nätverksgränssnitt till en annan, såsom är fallet för en multi-homing system (ett system med mer än en fysisk nätverksgränssnitt).

Var och en av de inbyggda kedjor har en standardpolicy som definierar vilken åtgärder vidtas för ett paket som når slutet av kedjan. Paketövergång slutar när en regel matchar paketet och har en åtgärd av ACCEPT , DROP , REJECT eller RETURN .

Den enklaste iptables -brandväggen består av regler för varje önskad tjänst, följt av en regel som anger att alla paket som når denna regel tappas. Ett system som endast tillåter till exempel inkommande e -posttrafik skulle ha en regel som accepterade anslutningar på SMTP -porten och sedan tappade andra. En regel skulle krävas som indikerade att alla etablerade anslutningar också var tillåtna så att utgående anslutningar skulle få svar från andra system.

INPUT -kedja

Följande exempel visar ett enkelt paketfilter för INPUT -kedjan för ovan beskrivna exempel: 

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt   in        out                 source               destination
    0     0 ACCEPT     all—any    any     anywhere             anywhere            state ESTABLISHED
    0     0 ACCEPT     tcp—any    any     anywhere             anywhere            tcp dpt:smtp
    0     0 LOG        all—any    any     anywhere             anywhere            LOG level warning
    0     0 DROP       all—any    any     anywhere             anywhere

Tillsatsen av en explicit DROP åtgärd säkerställer att paketen kasseras bör standardprincip av INPUT kedjan oavsiktligt ändras till ACCEPT .

OUTPUT -kedja

Det finns mindre behov av en OUTPUT kedja och standardpolicy för OUTPUT kedjan kan säkert sättas till acceptera . I vissa fall kan det vara önskvärt att en brandvägg begränsar vissa utgående anslutningar till en viss uppsättning godkända system. Detta kallas utgångsfiltrering och kan användas för att förhindra att virus i brandväggen flyr till andra system. Till exempel kan det vara ett nätverks policy att begränsa utgående e-postanslutningar till en enda auktoriserad e-postserver som ett sätt att bekämpa e-post spam . Detta kan uppnås genom följande exempel: 

Chain OUTPUT (policy ACCEPT)
 pkts bytes target     prot opt    in     out                  source              destination
    0     0 DROP       tcp—any    any    !server               anywhere            tcp dpt:smtp

Det finns inget behov av att inkludera några andra regler i detta exempel eftersom standardpolicyn för OUTPUT -kedjan är ACCEPTERA . Denna regel förutsätter att värden som fungerar som brandvägg inte kommer att skicka e -post själv, till exempel till e -postservern. Detta är ett bra antagande eftersom vanligtvis ett brandväggssystem innehåller den minimala mängd systemkod som behövs för att fungera som en brandvägg.

En mer restriktiv OUTPUT -kedja skulle innehålla tillåtande ( ACCEPT ) poster för de tjänster som kan komma åt utanför brandväggen och sedan en restriktiv ( DROP ) policy för själva kedjan.

Allmän

Säker nätverkskommunikation:

Paketnosning:

Angrepp:

Avancerad

Serviceinformation

Referenser

Allmän

  • Praktisk UNIX och internetsäkerhet, Simson Garfinkel och Gene Spafford, O'Reilly & Associates, 2003.

externa länkar