“ Når kostnadene ved å innhente opplysningene stiger verdien realisert ved sin besittelse, er løsningen en effektiv en &rdquo.; - En praktisk guide til Red Hat Linux
av Mark G. Sobell, Third Edition (Prentice Hall), side 989.
Etter førti år i kommersiell databehandling virksomhet, er en idé som er boret inn i meg med sikkerhet fagfolk det faktum at det ikke finnes noe slikt som et sikkert datasystem, bare nivåer av usikkerhet. Derfor kostnadene ved å holde informasjon og system sikker må balanseres med kostnaden for å miste denne informasjonen eller system, eller å ha den skadet. Dessverre hastigheten og tilgjengeligheten av Internett kombinert med lave kostnader for svært kraftige datamaskiner og nettverkstjenester har gjort kostnadene “ cracking ” gå ned og kostnadene ved “ sikre ” gå opp .
viktigste i et sikkert system er å ha en god sikkerhetspolitikk. Uten det, er du fortapt og vil vandre ineffektivt. Derfor må du gi tanken om hvem som vil være i stand til å gjøre hva, om disse begrensningene er skjønnsmessig eller obligatorisk og hvordan du vil gjennomføre og håndheve disse retningslinjene. Et godt eksempel på ikke å ha en god politikk er selskapet som tvinger alle sine ansatte til å ha lange, kompliserte passord som endres en gang i uken, men tolererer folk skrive sine passord på gule lapper og lime den på sine LCD-paneler og ldquo; fordi de kan ikke huske passordene og rdquo; ..
De neste viktigste tingene er et godt sett med sikkerhetsverktøy og folk opplært til å distribuere dem og overvåke deres utgang
Mange stasjonære systemer gjemme seg bak en “ brannmur ” disse dager i næringslivet eller hjemmemiljø. Brannmuren er et spesialisert system som aksepterer data fra Internett og ruter dem til skrivebordene eller servere. Håpet er at brannmuren vil isolere de dårlige mennesker fra folk inne i brannmuren, og derfor systemene inne kan være mer “ avslappet ” i deres sikkerhet. Dessverre i dagene av mobil databehandling, kan bærbare datamaskiner flytte fra innsiden av beskyttede brannmur omkretsen til ubeskyttet “ wild west ” Starbucks (som et eksempel) der folk sipping lattes og “ surfer på nettet ” har sine bærbare PC-er infisert med virus og trojanere som de bringer tilbake til kontoret. Og i disse dager, angrepene noen ganger kommer fra innenfor organisasjonen (hvor brannmuren gir ingen beskyttelse), og ikke på utsiden .
Andre systemer kan ikke gjemme seg bak brannmurer, og kalles “ Bastion ” systemer. De er de systemer som kjører web-servere, e-postservere og andre “ tjenesten ” maskiner. Dette er systemer som må være “ helt (så mye som mulig) herdet ” .
Til slutt er konstant overvåking av sikkerhetslister, nettsider og rask aktivering av patcher nøkkelen til systemsikkerhet. Å ha kildekoden til systemet tilgjengelig betyr at du ikke trenger å vente på din distribusjon leverandøren for å forsyne deg med den konstruert, utarbeidet og testet patch. Du kan ta avgjørelsen av å bruke en fikse selv, avhengig av kritikalitet av angrepet .
Gitt filosofier og spørsmålene ovenfor, tror jeg at Free og Open Source Software plass den beste basen for å la dine usikre systemer for å nå mot sikkerhet, og det er det denne bloggen handler om .
Denne bloggen er ikke om er å være en grundig forklaring av nettverk sikkerhet, og heller ikke hvordan å blokkere spam, og heller ikke å være nøkkelen-takts-by-key-takts kokebok av systemsikkerhet. Sikkerhet er en kunstform, så vel som en vitenskap, og dette blogginnlegget kan ikke gjøre deg til en Michelangelo i 3000 ord. Hvis jeg kan vise deg her at systemet er for tiden på “ finger maleri ” nivå og at med fri programvare kan du håpe å gjøre “ akvareller, ” “ oljemaling ” og utover, så jeg fant ut at jeg har gjort en god jobb ..
En dag arbeidet kan være i " museum av sikkerhet fine art "

Historie og Arkitektur av Unix

I 1969 Ken Thompson og Dennis Ritchie startet utvikle Unix operativsystem, “ bare for moro &rdquo.; Hvorvidt Unix var ment å være et tidsdeling system i første omgang, ble det raskt et system som er tillatt for flere personer å dele systemet, med flere prosesser for hver person. Dette satte umiddelbart design for å være mer robust og sikker enn en enbruker-systemet siden begrepet stabilitet og sikkerhet måtte bygges i .
Gitt, i de tidlige årene av Bell Laboratories mye oppmerksomhet ikke ble betalt til passordstyrke eller sikkerhet på et personlig nivå, men i løpet av årene ting som passord aldring, passord styrke håndheving og skygget passord ble satt inn i systemet for å holde bedre sikkerheten.
Unix ble kritisert for sin tidlig modell av « superbruker ” versus “ alle andre ” i veien for å kjøre programmer (spesielt administrative programmer), og de grupperinger av eierskap for “ eieren, ” “ gruppe ” og “ annet ” (dvs. alle andre i verden) som har “ lese, ” “ skrive " og /eller “ henrette ” evner på filen. Mens denne relativt enkle, men likevel elegant tillatelse struktur jobbet godt for en rekke år, over tid tilgangskontrollister (ACL) ble aktivert, slik at folk kan lage klasser av kjøring privilegier og tilgang til filer og kataloger på en mer finkornet nivå. < o: p>
Som Unix rømt fra Bell Labs og inngått fagmiljøet ved universiteter, kom det under den klassiske “ ildprøve ” som studenter prøvde å bryte seg inn i systemet og utviklerne prøvde å holde dem ute. Unix ble de facto operativsystem for alvorlig informatikk studie, og derfor (i mange tilfeller) for seriøse studier av datasikkerhet .
Arkitektur av Linux

Som jeg nevnte tidligere, følger arkitekturen i Linux tett arkitekturen av Unix-systemer. En relativt liten monolittisk kjerne med biblioteker og verktøy som legger funksjonalitet til den .
Dette alene gir sikkerhet verdi, siden det gjør det mulig for sluttbrukeren å slå av en rekke tjenester (både vertskap og nettverkstjenester) at de ikke trenger, og hvis venstre for å kjøre på systemet vil skape flere veier og muligheter for angrep .
For eksempel, fungerer den gjennomsnittlige desktop system som klient for tjenester, ikke som en server. Slå av disse tjenestene betyr at andre mennesker over hele nettverket ikke kan feste til dem. I de tidlige dagene av Linux mye distribusjoner vil bli distribuert med tjenestene slått på når du installerte og startet dem første gang. Dette var under den feilaktige inntrykk at det å ha tjenester som kjører ville gjøre dem enklere å administrere, men sikkerhetsfolk raskt påpekt at det å ha tjenestene kjører på installasjonstiden (før nødvendige patcher kan brukes) forlot også systemene, men kort, åpen for angrep. Nå er de fleste, om ikke alle, distribusjoner installere med disse tjenestene slått av og du blir bedt om å slå dem på i rett tid, forhåpentligvis etter at du har påført nødvendige patcher .
Et annet eksempel er konseptet med å fjerne kompilatorer og andre software utviklingsverktøy fra systemet, som disse verktøyene gi system sprakk flere verktøy for å utnytte systemet. Fjerne disse verktøyene betyr at cracker har å bruke andre metoder for å bryte inn .
. I tillegg til dette basisfunksjonalitet har vært flere FOSS pakker i løpet av årene som har gitt Linux enda større sikkerhet < o: p>
Den første er “ PAM ” eller “ Pluggable Authentication Modules &rdquo.; I ethvert system, “ autentisering ” betyr at du har identifisert deg selv på en slik måte at systemet gir deg tilgang til tjenester. Som du logge inn med ditt brukernavn og passord du blir “ godkjent ” typisk av brukernavn og passord i /etc /passwd filen ved login-programmet. Likeledes ftpd, og andre “ tjenesten ” programmer ville godkjenne deg på samme måte .
Hvis du er koblet til et nettverk, kan du imidlertid være godkjent av en rekke metoder, enten det er LDAP, DCE, Kerberos eller nyere metoder , og en rekke programmer kan måtte endres for å gjenspeile den nye metoden for autentisering. PAM ble gitt for å tillate nye metoder for autentisering skal brukes på alle programmene i systemet som trenger godkjenning uten å måtte endre og integrere hver nye autentiseringsmetode .
En annen autentiseringsmetode tidligere nevnt var “ Access Control Lists ” eller “ ACL ”. En ACL tilskudd “ tilgang ” til en fil eller katalog basert på en forlengelse av de tradisjonelle Unix tillatelser “ eier /gruppe /annen ” og “ rwx ” nevnt ovenfor. Siden ACL er implementert som en del av filsystemet struktur, må du sørge for at kjernen har blitt bygget for å støtte dem, at filsystemet du bruker støtter dem, og at filsystemet er montert med ACL slått på. Men når det er gjort kan du tilordne tillatelser til flere brukere på en individuell bruker basis, flere grupper på en gruppe-by-gruppe basis, og så videre .
Dette ville tillate du enkelt kan sette opp en gruppe av aktører som kan starte eller stoppe en person databasemotor eller gjøre sikkerhetskopier, men kunne ikke stenge hele systemet ned, som et eksempel .
Til slutt, du må være klar over at ikke alle Linux-verktøy støtter ACL. Hvis du kopierer filer fra en katalog til en annen med cp-kommandoen bør du bruke p (bevare) eller -a (arkiv) alternativer på kommando. Noen av de trofaste “ Unix ” kommandoer som cpio, tjære og andre ikke støtter ACL kopiering, og derfor ACL informasjon vil gå tapt .
Kryptert Filsystemer


Kryptering dataene dine bør være en del av sikkerhetspolitikk i en verden av USB-tommel-stasjoner, bærbare harddisker og stjålne bærbare datamaskiner, og Linux lar deg kryptere enkeltfiler, filsystemer, swap partisjoner og selv filsystemer holdt innsiden av enkeltfiler .
Noen av disse krypteringsmetoder fungerer også med brukernivå filsystemer, som betyr at du kan konfigurere dem mens systemet er oppe og går.
Loop-AES bruker en loop-back teknikk for å tillate blokkenhet å gjøre kryptering uten å måtte endre noe i kjernen i det hele tatt. Loop-back teknikkene er også nyttig for å støtte filsystemer blir holdt i en enkelt fil, så denne metoden kan brukes til å lage en kryptert filsystem som finnes i en enkelt fil på maskinen din .
DM-Crypt bruker enheten-mapper funksjonalitet (også nyttig for software RAID, snapshotting og andre funksjoner) av kjernen til å kryptere filsystemer
CryptoFS er et filsystem i user space (FUSE) som lar deg montere et filsystem over en katalog, og deretter hver fil som er lagret i denne katalogen er kryptert, inkludert filnavnet. Når du avmontere filsystemet, blir filene kryptert og vil ikke bli de-kryptert inntil den skal monteres på nytt med samme nøkkel .
Det er enda flere metoder for å kryptere filer og filsystemer som EncFS og TrueCrypt .
Som en side, nylig et Microsoft Windows administrator jeg vet oppstartet en Live CD på en av deres maskiner og var forbauset over at Linux kan lese og skrive det Microsoft Windows-filsystemer, selv om han hadde satt de katalogene som privat under Microsofts operativsystem. Jeg forklarte ham at det var et annet operativsystem, og med mindre han krypterer alle data i sine filsystemer, bør han forventer at alle som bruker et annet operativsystem på maskinen hans ville være i stand til å se, endre og slette data i sitt Microsoft Windows filsystemer. Jeg visste ikke “ gjøre sin dag ” med at nyheter ....
SELinux

I de fleste av autentiseringsmetoder adgangskontroll er skjønnsmessig. Eieren av objektet (enten program eller data) kan endre tillatelsene for andre mennesker og grupper .
For flere år siden National Security Agency (NSA) opprettet et prosjekt for å håndheve obligatorisk Access Control (MAC) på innsiden av Linux Kernel. Dette prosjektet ble kjent som “ Security Enhanced Linux ” eller SELinux. MAC håndhever sikkerhetspolitikk som begrenser hva en bruker eller et program kan gjøre, og hvilke filer, porter, enheter og kataloger et program eller brukeren kan få tilgang til .
SELinux har tre moduser: deaktivert , ettergivende og håndheve. I deaktivert modus ingenting blir gjort. Dette er slik at du kan ha din politikk satt opp og klar til å gå, men ikke nødvendigvis ønsker å ha dem handlet på. Givende modus logger brudd til politikken til loggfiler for deg å inspisere eller på annen måte overvåke. Håndheving betyr at eventuelle brudd på sikkerhetspolitikk vil avslutte den fornærmende prosessen .
SELinux bruker omtrent 5-10 prosent av systemets ytelse når i givende eller håndheving modus
På samme måte SELinux kan kjøre i en “ målrettet ” politikk eller en “ streng ” politikk. Målrettet betyr at MAC styrer kun gjelde for visse prosesser. Strenge betyr at MAC kontrollene gjelder for alle
prosesser .
Folk bør advares om at ukritisk bruk av streng politikk SELinux kan gjengi et system nesten ubrukelig for enkelte brukere. Det må være en avveining av å holde systemet sikkert og tillater brukerne å gjøre arbeidet sitt
. Det argumenteres for at SELinux er “ kill ” på en “ single-user system ” men med dagens utnytter og makt “ enkelt brukersystemer, ” vi kan finne flere og flere programmer av SELinux på en enbruker-skrivebordet .
AppArmor

AppArmor er et annet system for obligatorisk tilgangskontroll, men en som er mer basert på et program-by-program basis enn SELinux og lar deg mikse å håndheve og ettergivende politikk i samme system på samme tid .
Gjennom sine “ profiler ” for hvert program, kan AppArmor begrense hva et program kan gjøre og hvilke filer det kan få tilgang til, skrive eller utføre .
Noen mennesker føler at AppArmor er enklere å konfigurere og kontroll enn SELinux.
Making Files “ uforanderlige ”
Hvis noen bryter seg inn i systemet ditt, kan de endre ulike kontrollfiler, for eksempel passwd fil. Du kan stoppe dette ved å gjøre filen “ uforanderlig &rdquo.; Når en fil er “ uforanderlige ” det kan ikke endres, enten ved å skrive eller slette eller omdøpt eller harde lenker gjort, selv av “ superbruker &rdquo.; Filen først må endres tilbake til å ha “ normal ” filrettigheter, og da kan det bli endret. Kommando for å lage en fil uforanderlig og tilbake til det normale er chattr, og hadde syntaks av dette skjemaet: chattr + i < filnavn >
Bruke chattr kommandoen med en “ en ” i stedet for en “ i ” gjør filen slik at den bare kan legges. Dette er nyttig for loggfiler, hvor du bare ønsker at systemet skal legge til ny informasjon, ikke slette gammel informasjon .
Når chattr kommandoen er utført mot en fil, selv root ikke kan endre eller slette denne filen inntil filen har blitt endret tilbake med en “ -i ” eller “ -en ” .
Igjen, må du kontrollere at filsystemet du bruker, støtter denne funksjonaliteten. Ext2 og Ext3 filsystemer støtter det .
Logger

Unix og Linux systemer har loggfiler. Dette er filer som logger ulike typer arrangementer, alt fra prosessen starter opp og slutter på meldinger eksplisitt om din e-postserver eller databasemotorer. De fleste Unix og Linux-systemer har muligheten til å rute ulike nivåer av informasjon fra “ hyggelig å vite ” til « kritisk ” inn i et sentralt register. Det systemansvarlig kan opprette filtre og skript for å hjelpe dem å overvåke disse loggfilene for aktiviteter som skulle tilsi folk bryte inn i systemet .
Disse loggfilene, selvfølgelig, bør beskyttes bruker chattr kommandoen nevnt ovenfor med “ -en ” alternativet .
Intrusion Detection Systems

Det er ulike Intrusion Detection Systems tilgjengelige for Linux. SNORT (http://www.snort.org/) er en av dem. SNORT bruker et sett av regler for å bestemme hvordan det skal bestemme og eskalere inntrenging.
Sikkerhetskopier

Til tross for alt arbeid, tid, svette og tårer, til slutt systemet ditt blir overtatt. Det er da du må finne ut når det ble kompromittert, hvor det ble kompromittert og være klar til å gjenopprette det som var skadet uten at andre mulige virus og trojanere til å forbli på systemet ditt .
Med mye arbeid, kan du være i stand til å bruke verktøy for å feie systemet se etter disse virus og trojanere. Eller du kan re-installere fra CD-ROM eller kjente, gode ISO image og alle dens tilknyttede patcher .
En siste måte er å ha en virkelig god systemnivå backup av alt av systemet arbeidet dere har gjort, og med jevne mellomrom oppdatere som backup for å sørge for at du har tatt alle sikkerhetsoppdateringer som har skjedd siden den siste. Hvis du kan finne ut nøyaktig når du ble kompromittert, kan du være i stand til å gjenopprette systemet fra en av disse systemnivå sikkerhetskopier. Ellers må du kanskje gå tilbake til installerer fra distribuert kode .
Sammendrag

Jeg er sikker på at mange fagfolk vil se på dette blogginnlegget og si “ virkelig elementære ”
Andre mennesker kan se på noen av disse funksjonene, og si “ hvordan kan jeg muligens holde opp med å vite alt om disse reglene og kommandoer på et system så komplisert som Unix eller Linux ” Svaret er at du sannsynligvis ikke kan holde tritt med alle disse hensynene på hvert system, og det er der sikkerhetspolitikk spiller inn. Gjør hvert system så sikker som det må være for sin spesielle jobb og for informasjonen som er lagret på den, og slik at du fortsatt har for å få arbeidet gjort
. I tillegg til å studere de ressursene listet opp nedenfor, bør du også se på nettsiden for din distribusjon. Fordi det er mange overlappende måter å gjøre filkryptering, kompilere en kjerne, og til å sikre et system, kan det hende at distribusjonen har utviklet en generell sikkerhetsarkitektur som ville kompliment dine politikk og gjøre å prøve å være mer sikre en mye enklere.
Resources

Det er mange gode bøker om både generell datasikkerhet og sikkerhet på Linux i bestemt. Jeg fant disse to for å være veldig bra:
“ Herde Linux, ” av James Turnbull (Apress, 2005)
“ Linux Server Security, ” av Michael D. Bauer (O'Reilly, 2005)
I tillegg er det nettsider:
http: //www.linux-sec.net/
http://www.linuxsecurity.com/
http: //www. bastille-unix.org/
http://tldp.org