39360.zip
Det skalerbare og effektive Snort open source Network Intrusion Detection System (NIDS) bruger en række veldefinerede regler til at registrere unormale pakker på dit netværk. Ved at vedligeholde disse regelsæt forbedres systemets effektivitet dramatisk. Et par regelhåndteringsteknikker kan hjælpe dig med at vedligeholde dit Snort IDS. For det første kan du forhindre en overbelastning af advarsler ved at stramme variabeldefinitionerne og pleje dine Snort-regler. Du kan også bevare dine brugerdefinerede regler på tværs af opgraderinger af regelsæt. Endelig kan du dekonstruere en regel for at forstå, hvordan du kan tilpasse reglerne til dit miljø.
Snort indeholder som standard mere end 1900 lagerregler i en række af næsten 50 tekstfiler, der er organiseret efter type, som det fremgår af figur 1. Disse regler definerer reaktionstriggere til mange kendte sårbarhedsudnyttelser vedrørende Windows, UNIX og udbredte programmer som f.eks. Microsoft IIS, Apache, Microsoft SQL Server og Oracle SQL. Reglerne hjælper også Snort med at levere rekognosceringsdata og eventuelle konfigurationsadvarsler for at advare dig om netværksscanninger eller om en maskine, der f.eks. udsender en SNMP-standardfællesskabsstreng. Som du måske kan forestille dig, kan Snort generere et enormt antal advarsler. For at reducere støjen fra lagerreglerne aktiverer standardkonfigurationen af Snort kun ca. 1300 af reglerne som standard og deaktiverer som standard hele regeltyper, f.eks. politik, chat og virus. (En regeltype er typisk indeholdt i sin egen tekstfil, så regler af typen virus er indeholdt i filen virus.rules). Gennemgå alle deaktiverede regelgrupper, og aktiver dem, der kan være relevante for dit miljø.
Prune dine regler
Selv med de mange regler, som Snort deaktiverer som standard, vil dit Snort IDS-system sandsynligvis generere mange advarsler. Hvis du skal trænges igennem alle disse advarsler, kan det sløve dine sanser for virkelig mistænkelig trafik. Når du har installeret Snort i dit miljø, skal du beskære reglerne for at fjerne de regler, der ikke vedrører dit miljø, eller som ikke vedrører dig. Hvis du f.eks. ikke har det HTML-indlejrede scriptingsprog PHP: Hypertext Preprocessor (PHP) ikke er installeret i dit miljø, kan du deaktivere regelfilen web-php.rules. Når du beslutter, hvilke regler du skal deaktivere, skal du dog tage hensyn til brugere, der måske har forskellige programmer på deres maskiner. En af dine Snort-sensorer kan f.eks. opfange mistænkelige pakker fra en kompromitteret hjemmecomputer via en VPN-forbindelse. Så hvis vi fortsætter med det foregående eksempel, kan en af dine slutbrugere have installeret PHP derhjemme, selv om du ikke har PHP installeret på nogen af dine virksomhedscomputere. Hvis denne hjemmecomputer blev kompromitteret via en PHP-sårbarhed, kan angriberen måske få adgang til dit virksomhedsnetværk, mens den kompromitterede computer er fjernforbundet til virksomhedsnetværket (f.eks. via en VPN).
De fleste advarsels- og rapporteringssystemer viser navnet og SID for hver regel for at gøre det nemt at henvise til den. Hvis du vil reducere listen over aktiverede regler yderligere, kan du overvåge dine systemer, notere navne eller SID’er på uvedkommende regler og derefter deaktivere disse regler. Hvis du vil deaktivere en Snort-regel manuelt, skal du åbne regelfilen og indsætte et pundtegn (#) foran reglen. Hvis du vil deaktivere en hel klasse af regler, skal du tilføje et pundtegn foran regelfilnavnet i Snort-konfigurationsfilen. Du skal genstarte Snort for at indlæse de ændrede regler.
Gennemgang af dine regler regelmæssigt og fortsat fjernelse af dem, der ikke gælder for dit netværk, vil reducere antallet af advarsler, som Snort genererer, dramatisk, og dermed gøre det lettere at opdage og identificere virkelig mistænkelige pakker. Og husk at genaktivere reglerne efter behov, når du introducerer ny teknologi, som de aktuelt deaktiverede regler ville beskytte.
Hold reglerne aktuelle
Snort.org er vært for to versioner af Snort-regler: snortrules-stable og snortrules-current, som fungerer med henholdsvis Snort 2.0x og Snort 1.9x. De nyere regler indeholder yderligere signaturer og opdateringer til eksisterende regler for at gøre brug af udvidede variabler. For eksempel definerer reglerne i version 2.0.0.0 variabler, der specifikt beskriver visse maskinfunktioner (f.eks. karakteriserer variablerne HTTP_SERVERS og HTTP_PORTS computere, der kører webtjenester og kan være udsat for webtjenesteangreb). Disse nye variabler fungerer i de nye regler til yderligere at screene indgående angreb. En gammel regel kan advare dig om en mistænkelig HTTP-forespørgsel, der er bestemt til en hvilken som helst computer på dit netværk, men den nye regel leder kun efter det samme angreb, når det er bestemt til en webserver, som HTTP_SERVERS-variablen definerer. Denne klassificeringsproces er med til at reducere antallet af falske alarmer.
Snort.org opdaterer regelsættene ofte for at holde sig ajour med nye opdagelser om udnyttelse. For at holde dig opdateret skal du regelmæssigt søge efter, downloade og anvende nye regler, der vil være nyttige i dit miljø. Bemærk dog, at når du downloader et sæt nye regler, overskriver tekstfilerne med de nye regler de tekstfiler, der indeholder de gamle regler. Du vil hurtigt opdage, at det er besværligt at kommentere alle dine ubrugte regler ud, hver gang du opdaterer dine regelfiler.
Oinkmaster til redning
Glædeligvis kan flere open source-værktøjer hjælpe dig med at overvinde dette problem. Et Perl-scriptprogram kaldet Oinkmaster, som du kan downloade fra http://www.algonet.se/~nitzer/oinkmaster, automatiserer download af nye regler og administrerer deaktiverede eller ændrede regler. Perl-scriptet er skræddersyet til UNIX-systemer og bruger wget-, tar- og gzip-værktøjerne til at hente og udvide nye regler, når scriptet kører. De fleste af disse værktøjer er installeret på UNIX-systemer, men du kan downloade værktøjerne til Windows. Husk, at open source-løsninger har begrænset dedikeret support (hvis overhovedet nogen), så søg online efter løsninger på eventuelle problemer eller spørgsmål, du måtte have. Fællesskabet for open source-software (OSS) bugner af nyttige oplysninger. Et godt sted at starte er ved at abonnere på en af Snort-mailinglisterne, som du kan tilmelde dig på http://www.snort.org/lists.html.
Sørg for at konsultere README-filen for detaljerede installationsinstruktioner for din platform. Den grundlæggende installationsprocedure for Oinkmaster består i at udvide filerne oinkmaster.pl og oinkmaster.conf til din Snort-mappe (eller en mappe, du angiver) og derefter bruge oinkmaster.conf til at konfigurere Oinkmaster.
Åbn oinkmaster.conf, og følg inline-kommentarerne for at konfigurere værktøjet. Først skal du bekræfte placeringen af de opdaterede regler som en webadresse (f.eks. http://www.snort.org/dl/signatures/snortrules.tar.gz). Sørg for at pege Oinkmaster til et pålideligt og velrenommeret websted, især hvis du vælger at downloade og installere reglerne automatisk. Ellers risikerer du at downloade beskadigede (eller endnu værre, manipulerede) regler, som kan kompromittere dit IDS.
Næst skal du angive de filer, der skal springes over, ændres og deaktiveres. Som standard behandler Oinkmaster ikke (dvs. den springer over) local.rules og snort.conf.
Scriptets modifysid-funktion giver dig mulighed for at ændre nyligt downloadede regler; tænk på modifysid som en søge- og erstatningsfunktion for en specifik regel, som du identificerer ved hjælp af SID. Med denne kommando kan du ændre teksten i en specifik regel. Du kan f.eks. bruge modifysid til at aktivere en regel, der som standard er deaktiveret. Det gør du ved at tilføje en ny modifysid-kommando, der identificerer den regel, du vil aktivere, og give den besked om at fjerne kommentartegnet (#). Hver gang der hentes et nyt regelsæt, vil dette kommentartegn blive fjernet, når Oinkmaster analyserer den pågældende regel. Du kan også bruge modifysid til at hæve en regels handlingstype. F.eks. hæver kommandoen
modifysid 2003 "alert" | "sev1"
alarm med et SID på 2003 til en brugerdefineret handlingstype på sev1. Oinkmaster gør dette ved at søge efter “alert” og erstatte det med “sev1”. Og ja, den vil foretage flere erstatninger, så brug den med omhu.
Den sidste og mest populære Oinkmaster-funktion, disablesid, lader dig deaktivere udvalgte regler. Angiv SID’erne for alle de regler, som du ønsker at beholde deaktiveret. Hvis du f.eks. vil deaktivere advarsler om netværksscanninger, kan du starte med en post, der ligner
disablesid 469, 615, 618, 620
Når Oinkmaster downloader og analyserer et nyt sæt regler, leder Oinkmaster efter de angivne SID’er og kommenterer reglerne. Så længe Oinkmaster administrerer dine regler, forbliver reglerne deaktiveret, selv på tværs af opdateringer af regelsæt.
Manuelt udføres scriptet, når du ønsker at opdatere dine regler. Hvis du føler dig modig, kan du planlægge scriptet til at køre og opdatere reglerne på et tilbagevendende grundlag. Oinkmaster henter reglerne, udvider dem og kopierer dem til din sensors regelmappe. Som med det meste OSS skal du bruge Oinkmaster med omtanke og først lære, hvad det gør, og hvordan det vil påvirke dit miljø. Test f.eks. et nyt sæt regler ved at køre Snort i selvtesttilstand (ved at bruge snort -T plus dine andre parametre), før du implementerer reglerne i dit produktionsmiljø.
Oinkmaster lader dig undgå risikoen ved at hente tvivlsomme opdateringer ved at give dig mulighed for at sikkerhedskopiere gamle regler og ved at levere en log over dens handlinger til konsollen. Gennemgå dette output, som viser fjernede regler, ændrede aktive regler, revisioner af ikke-regler og nye filer, for at bekræfte, at Oinkmaster har udført sine opgaver med succes, og for at bekræfte de regler, som Oinkmaster har ændret. Hvis du vælger at planlægge Oinkmaster til at køre automatisk, kan du overveje at sende resultaterne pr. e-mail for at lette gennemgangen, som det fremgår af figur 2. Følgende eksempel viser, hvordan du planlægger Oinkmaster til at køre dagligt kl. 6.15 ved hjælp af Linux crontab-kommandoen (crontab giver dig mulighed for at planlægge job i Linux):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Parametrene for Oinkmaster angiver regelmappen (-o), mappen med backupreglerne (-b) og en kommando til at sende resultaterne pr. e-mail til ejeren. Kommandoen 2>&1 sender StdErr-udgangen til StdOut (konsollen), før den sendes til e-mail-programmet.
Syn på en Snort-regel
Ud over at deaktivere eller foretage grundlæggende ændringer af standardreglerne kan du oprette dine egne regler og yderligere skræddersy Snort-reglerne direkte til dit miljø. Overvej f.eks. en sensorimplementering, der overvåger trafik inden for og uden for din firewall. Selv om det kan interessere dig at vide, hvor mange ormeangreb din firewall afviser, vil det sandsynligvis interessere dig endnu mere at vide, om nogle af disse angreb stammer fra dit netværk. På det seneste har Snort-regler inkluderet “tunede” regler som ovenstående eksempel, men der er stadig mange andre regler, som du måske ønsker at tilpasse på samme måde. Listing 1 viser en standardregel, der advarer dig, når den registrerer SQL Slammer (aka Sapphire) ormen. Lad os hurtigt dekonstruere denne regel. (For detaljerede oplysninger om alle tilgængelige parametre, der definerer reglerne, henvises til den grundige dokumentation af Snort-regler på http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Alle regler skal ligge på én linje og begynde med en regelhandling, som i dette tilfælde er
alert
Regelhandlingen definerer, hvordan Snort reagerer på reglen, hvis den udløses. Du kan ændre regeltypen (f.eks. til en streng som “sev1”) for at give en brugerdefineret håndtering – f.eks. for at eskalere handlingen i tilfælde af et match. Dette trin er forskelligt fra det foregående eksempel, hvor vi brugte Oinkmaster til at ændre alarmtypen for en eksisterende regel; i dette eksempel opretter vi en ny regel ved at bruge en eksisterende regel som skabelon.
Sættet af parametre
udp $EXTERNAL_NET any -> $HOME_NET 1434
giver protokollen, IP-adressen, portoplysningerne og trafikretningen for reglen. Denne regel fortæller Snort, at den skal finde enhver UDP-pakke fra en netværkskilde (som variablen $EXTERNAL_NET definerer), der forsøger at gå til variablen $HOME_NET på port 1434. De fleste standardregler anvender primært variablerne $EXTERNAL_NET og $HOME_NET. Nogle regler anvender dog mere specifikke variabler. F.eks. bruger de regler, der vedrører DNS-servere (i filen dns.rules), variablen $DNS_SERVERS. Disse variabler skal defineres i Snort-konfigurationsfilen (typisk snort.conf). Du kan eventuelt oprette dine egne variabler for at afspejle din topologi (f.eks. $MAIL_SERVERS) og til brug i brugerdefinerede regler. Definer en variabel ved at bruge dens navn (f.eks. var MAIL_SERVERS= 192.168.0.20/30), og henvis derefter til variablen ved at sætte et dollartegn foran ($ – f.eks. $MAIL_SERVERS). Regelhandlingen og disse parametre udgør regelhovedet.
Regelindstillingerne forfiner reglen yderligere, så en mistænkelig pakke (og kun en mistænkelig pakke) vil udløse et svar. Som du måske kan gætte, kan disse signaturer blive ret detaljerede og strækker sig langt ud over simpel portmatchning. For eksempel kan du forestille dig de falske positive resultater, der ville opstå, hvis denne Slammer-regel blot advarede dig om al UDP-port 1434-trafik.
Mmsg-indstillingen
msg:"MS-SQL Worm propagation attempt"
giver en simpel beskrivelse af advarslen til brug ved advarsels- og rapporteringsaktiviteter. Indstillingen content option
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
indeholder den case-sensitive payload-mønstermatchende streng, enten i ASCII- eller hexadecimale værdier (omslut hex-værdier med pipe-tegnet-|). Du kan angive flere indholdsindstillinger. Dybdeindstillingen følger efter hver indholdsindstilling og angiver, hvor mange bytes inde i nyttelasten du ønsker at søge efter det angivne indhold. I dette eksempel udløser en pakke et svar, hvis den indeholder hex-værdien 04 i den første byte eller det resterende indhold et hvilket som helst sted i nyttelasten.
Downloadede regler indeholder ofte henvisninger til detaljerede oplysninger om den mistænkelige udnyttelse eller årsagen til oprettelsen af reglen. Nogle rapporteringssystemer understøtter henvisningsmuligheden ved at give direkte links til disse oplysninger:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort tildeler regler til klasser og tildeler disse klasser en prioritet på høj, middel eller lav. I øjeblikket findes der mere end 30 klassifikationer, herunder forsøg på administration, trojan-aktivitet, forsøg på benægtelse af tjeneste og netværks-scanning. I vores eksempel er klassifikationen
classtype:misc-attack
Snort registrerer svarprioriteten for opdagede indbrud. Du kan bruge et eksternt værktøj eller script til yderligere at analysere denne prioritet og træffe foranstaltninger med dit rapporteringsprogram.
I det sidste segment
sid:2003; rev:2;
sid repræsenterer en unik Snort-regel, og rev angiver revisionsnummeret. Disse egenskaber identificerer reglen entydigt.
Spænder reglen
Lad os undersøge, hvordan denne regel kan ændres, så den giver en eskaleret advarsel, når den registrerer interne inficerede værter. Da vi har at gøre med den samme udnyttelse som i den oprindelige regel, forbliver indholdsdefinitionen af reglen den samme. Vi behøver kun at ændre IP-adresserne og trafikretningen. Lad os ændre kilde-IP-adressen til $HOME_NET som følger:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf definerer $EXTERNAL_NET som “any”, så denne regel vil stadig fange korrupte pakker, der er rettet mod interne værter (ligesom den oprindelige regel). Men nu, hvor vi har en dedikeret regel, der kun sporer interne kilde-IP-adresser, kan vi ændre handlingstypen til en brugerdefineret handlingstype, der udløser en eskaleret advarsel.
De nuværende Snort-regler omfatter denne regel til detektion af udgående Slammer-orm i standardregelsættet. Men når en ny orm, virus eller anden udnyttelse begynder at sprede sig, kan du overveje at oprette nye regler, der fremhæver specifikke indbrud.
Skabelse af dine regler
Ud over eksisterende eller brugerdefinerede regler, som du kan ændre eller oprette, kan du også inkludere regler, som du får fra en anden kilde. Når nyheder om en ny orm f.eks. spredes på internettet, er sikkerhedssider og nyhedsgrupper hurtige til at offentliggøre engangsregler for Snort, der kan registrere den nye orm. Indsæt disse nye regler i filen local.rules, og genstart derefter Snort for at få de nye regler til at træde i kraft.
Snort giver rammen for et billigt og tilpasseligt IDS. Båret af et regelsæt, der understøttes af fællesskabet, er Snort fortsat et fleksibelt og effektivt system. Hvis du holder dine regler ajour, vil du øge din årvågenhed og mindske den støj, der resulterer i ineffektive advarsler. Som med ethvert open source-projekt vil det at tage sig tid til at forstå, hvordan det fungerer, og gøre dig bekendt med de af fællesskabet udviklede tilføjelser dramatisk forbedre din komfort med systemet og øge dets effektivitet i dit miljø.