39360.zip
Det skalbara och effektiva Snort-nätverksintrångsdetekteringssystemet (NIDS) med öppen källkod använder en rad väldefinierade regler för att upptäcka onormala paket i nätverket. Genom att underhålla dessa regeluppsättningar förbättras systemets effektivitet dramatiskt. Några tekniker för regelhantering kan hjälpa dig att underhålla ditt Snort IDS. För det första kan du förhindra en överbelastning av varningar genom att strama upp variabeldefinitioner och trimma dina Snort-regler. Du kan också behålla dina anpassade regler vid uppgraderingar av regeluppsättningar. Slutligen kan du dekonstruera en regel för att förstå hur du kan anpassa reglerna för din miljö.
Snort innehåller som standard mer än 1900 lagerregler i en serie av nästan 50 textfiler som är organiserade efter typ, som figur 1 visar. Dessa regler definierar svarsutlösare för många kända sårbarhetsutnyttjanden som rör Windows, UNIX och allmänt använda program som Microsoft IIS, Apache, Microsoft SQL Server och Oracle SQL. Reglerna hjälper också Snort att tillhandahålla spaningsdata och eventuella konfigurationsvarningar för att varna dig om nätverksskanning eller om en maskin som sänder ut en SNMP-standardkommunitetssträng, till exempel. Som du kanske kan föreställa dig kan Snort generera ett enormt antal varningar. För att minska bruset från lagerreglerna aktiverar standardkonfigurationen av Snort endast cirka 1300 av reglerna som standard och inaktiverar hela regeltyper, t.ex. policy, chatt och virus, som standard. (En regeltyp finns vanligtvis i en egen textfil, så regler av typen virus finns i filen virus.rules). Granska alla inaktiverade regelgrupper och aktivera alla som kan gälla för din miljö.
Prune Your Rules
Även med de många regler som Snort inaktiverar som standard kommer ditt Snort IDS-system sannolikt att generera många varningar. Om du måste gå igenom alla dessa varningar kan det leda till att dina sinnen blir avtrubbade när det gäller verkligt misstänkt trafik. När du har installerat Snort i din miljö kan du rensa reglerna för att ta bort de regler som inte gäller din miljö eller som inte berör dig. Om du till exempel inte har det HTML-inbäddade skriptspråket PHP: Hypertext Preprocessor (PHP) är installerat i din miljö kan du inaktivera regelfilen web-php.rules. När du bestämmer vilka regler som ska inaktiveras bör du dock tänka på användare som kan ha olika programvaror på sina maskiner. En av dina Snort-sensorer kan till exempel fånga upp misstänkta paket från en komprometterad hemmamaskin via en VPN-anslutning. Så, om vi fortsätter med föregående exempel, även om du inte har PHP installerat på någon av dina företagsdatorer, kan en av dina slutanvändare ha installerat det hemma. Om den hemdatorn skulle äventyras genom en PHP-sårbarhet kan angriparen få tillgång till ditt företagsnätverk medan den infekterade datorn är fjärransluten till företagsnätverket (t.ex. via en VPN).
De flesta varnings- och rapporteringssystem visar namn och SID för varje regel för att underlätta referens. För att ytterligare reducera listan över aktiverade regler kan du övervaka dina system, anteckna namn eller SID för ovidkommande regler och sedan inaktivera dessa regler. Om du vill inaktivera en Snort-regel manuellt öppnar du regelfilen och sätter in ett pundtecken (#) framför regeln. Om du vill inaktivera en hel klass av regler lägger du till ett pundtecken framför filnamnet på regeln i konfigurationsfilen för Snort. Du måste starta om Snort för att läsa in de ändrade reglerna.
Om du ser över dina regler regelbundet och fortsätter att ta bort de regler som inte gäller för ditt nätverk minskar antalet varningar som Snort genererar dramatiskt, vilket gör det lättare att upptäcka och identifiera verkligt misstänkta paket. Och kom ihåg att återaktivera reglerna vid behov när du introducerar ny teknik som för närvarande inaktiverade regler skulle skydda.
Håller reglerna aktuella
Snort.org är värd för två versioner av Snort-regler: snortrules-stable och snortrules-current, som fungerar med Snort 2.0x respektive Snort 1.9x. De nyare reglerna innehåller ytterligare signaturer och uppdateringar av befintliga regler för att använda utökade variabler. Reglerna i version 2.0.0.0 definierar till exempel variabler som specifikt beskriver vissa maskinfunktioner (t.ex. variablerna HTTP_SERVERS och HTTP_PORTS som kännetecknar datorer som kör webbtjänster och som kan vara utsatta för attacker via webbtjänster). Dessa nya variabler fungerar i de nya reglerna för att ytterligare sortera inkommande attacker. En gammal regel kan varna dig för en misstänkt HTTP-förfrågan som är avsedd för vilken dator som helst i nätverket, men den nya regeln letar efter samma attack endast när den är avsedd för en webbserver som definieras av variabeln HTTP_SERVERS. Denna klassificeringsprocess bidrar till att minska antalet falska larm.
Snort.org uppdaterar regeluppsättningarna ofta för att hålla sig uppdaterad med nya upptäckter av exploateringar. För att hålla dig uppdaterad bör du regelbundet söka efter, ladda ner och tillämpa nya regler som kan vara användbara i din miljö. Observera dock att när du laddar ner en uppsättning nya regler överskriver textfilerna som innehåller de nya reglerna de som innehåller de gamla reglerna. Du kommer snabbt att upptäcka att det är betungande att kommentera ut alla oanvända regler varje gång du uppdaterar dina regelfiler.
Oinkmaster to the Rescue
Troligtvis kan flera verktyg med öppen källkod hjälpa dig att övervinna detta problem. Ett Perl-skriptprogram som heter Oinkmaster, som du kan ladda ner från http://www.algonet.se/~nitzer/oinkmaster, automatiserar nedladdningen av nya regler och hanterar inaktiverade eller ändrade regler. Perl-skriptet är anpassat för UNIX-system och använder verktygen wget, tar och gzip för att hämta och expandera nya regler när skriptet körs. De flesta av dessa verktyg är installerade på UNIX-system, men du kan ladda ner verktygen för Windows. Kom ihåg att lösningar med öppen källkod har begränsad dedikerad support (om någon), så leta på nätet efter lösningar på eventuella problem eller frågor du kan ha. Gemenskapen för programvara med öppen källkod (Open Source Software, OSS) är full av användbar information. En bra början är att prenumerera på en av Snorts sändlistor, som du kan anmäla dig till på http://www.snort.org/lists.html.
Se till att läsa README-filen för detaljerade installationsinstruktioner för din plattform. Den grundläggande installationsproceduren för Oinkmaster består av att expandera filerna oinkmaster.pl och oinkmaster.conf till din Snort-katalog (eller en katalog som du anger) och sedan använda oinkmaster.conf för att konfigurera Oinkmaster.
Öppna oinkmaster.conf och följ inlinekommentarerna för att konfigurera verktyget. Bekräfta först platsen för de uppdaterade reglerna som en webbadress (t.ex. http://www.snort.org/dl/signatures/snortrules.tar.gz). Var noga med att peka Oinkmaster till en betrodd och välrenommerad webbplats, särskilt om du väljer att hämta och installera reglerna automatiskt. Annars riskerar du att hämta skadade (eller ännu värre, manipulerade) regler som kan äventyra ditt IDS.
Nästan anger du vilka filer som ska hoppa över, ändras och inaktiveras. Som standard behandlar Oinkmaster inte (dvs. hoppar över) local.rules och snort.conf.
Skriptets funktion modifysid låter dig ändra nyligen nedladdade regler; tänk på modifysid som en sök- och ersättningsfunktion för en specifik regel som du identifierar med SID. Med det här kommandot kan du ändra texten i en specifik regel. Du kan till exempel använda modifysid för att aktivera en regel som är inaktiverad som standard. Lägg därför till ett nytt modifysid-kommando som identifierar regeln som du vill aktivera och beordra det att ta bort kommentarsymbolen (#). Varje gång en ny regeluppsättning laddas ner kommer detta kommentartecken att tas bort när Oinkmaster analyserar regeln. Du kan också använda modifysid för att höja en regels åtgärdstyp. Kommandot
modifysid 2003 "alert" | "sev1"
höjer till exempel varningen med SID 2003 till en anpassad åtgärdstyp sev1. Oinkmaster gör detta genom att söka efter ”alert” och ersätta det med ”sev1”. Och ja, den kommer att göra flera ersättningar, så använd den med försiktighet.
Den sista och mest populära funktionen i Oinkmaster, disablesid, låter dig inaktivera valda regler. Ange SID:erna för alla regler som du vill ha inaktiverade. Om du till exempel vill inaktivera varning vid nätverksskanning kan du börja med en post som liknar
disablesid 469, 615, 618, 620
När Oinkmaster hämtar och analyserar en ny uppsättning regler letar den efter de angivna SID:erna och kommenterar reglerna. Så länge Oinkmaster hanterar dina regler förblir reglerna inaktiverade, även vid uppdateringar av regeluppsättningar.
Hantera skriptet manuellt när du vill uppdatera dina regler. Om du känner dig djärv kan du schemalägga skriptet så att det körs och uppdaterar reglerna på återkommande basis. Oinkmaster hämtar reglerna, expanderar dem och kopierar dem till sensorns regelkatalog. Som med de flesta OSS ska du använda Oinkmaster med försiktighet och först lära dig vad det gör och hur det kommer att påverka din miljö. Testa till exempel en ny uppsättning regler genom att köra Snort i självtestläge (genom att använda snort -T plus dina andra parametrar) innan du distribuerar reglerna i din produktionsmiljö.
Oinkmaster låter dig undvika riskerna med att hämta tvivelaktiga uppdateringar genom att ge dig möjlighet att säkerhetskopiera gamla regler och genom att leverera en logg över sina åtgärder till konsolen. Granska den här utmatningen, som visar borttagna regler, ändrade aktiva regler, revideringar av icke-regler och nya filer, för att bekräfta att Oinkmaster framgångsrikt slutförde sina uppgifter och för att bekräfta de regler som Oinkmaster ändrade. Om du väljer att schemalägga Oinkmaster så att den körs automatiskt kan du överväga att skicka resultaten via e-post för att underlätta granskningen, vilket visas i figur 2. Följande exempel visar hur du schemalägger Oinkmaster så att den körs dagligen klockan 6:15 med hjälp av Linux crontab-kommandot (med crontab kan du schemalägga jobb i Linux):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Parametrarna för Oinkmaster anger regelkatalogen (-o), säkerhetskopieringsregelkatalogen (-b) och ett kommando för att maila resultaten till ägaren. Kommandot 2>&1 skickar StdErr-utmatningen till StdOut (konsolen) innan den skickas till e-postprogrammet.
Kontroll av en Snort-regel
Förutom att inaktivera eller göra grundläggande ändringar av standardreglerna kan du skapa egna regler och ytterligare anpassa Snort-reglerna direkt till din miljö. Tänk till exempel på en sensorinstallation som övervakar trafiken inom och utanför din brandvägg. Även om det kan intressera dig att veta hur många maskangrepp din brandvägg avvärjer, är det förmodligen ännu mer intressant att veta om någon av dessa attacker kom från ditt nätverk. På senare tid har Snort-reglerna inkluderat ”trimmade” regler som exemplet ovan, men det finns fortfarande många andra regler som du kanske vill anpassa på samma sätt. Listing 1 visar en standardregel som varnar dig när den upptäcker SQL Slammer (aka Sapphire)-masken. Låt oss snabbt dekonstruera den här regeln. (Detaljerad information om alla tillgängliga parametrar som definierar reglerna finns i den grundliga dokumentationen om Snort-regler på http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26.)
Alla regler måste finnas på en rad och börja med en regelåtgärd, som i det här fallet är
alert
Regelåtgärden definierar hur Snort reagerar på regeln om den utlöses. Du kan ändra regeltypen (t.ex. till en sträng som ”sev1”) för att tillhandahålla anpassad hantering, t.ex. för att trappa upp åtgärden vid en matchning. Det här steget skiljer sig från det föregående exemplet, där vi använde Oinkmaster för att ändra varningstypen för en befintlig regel; i det här exemplet skapar vi en ny regel genom att använda en befintlig regel som mall.
Den här uppsättningen parametrar
udp $EXTERNAL_NET any -> $HOME_NET 1434
ger protokoll, IP-adress, portinformation och trafikriktning för regeln. Den här regeln säger åt Snort att hitta alla UDP-paket från en nätverkskälla (som variabeln $EXTERNAL_NET definierar) som försöker gå till variabeln $HOME_NET på port 1434. De flesta standardregler använder främst variablerna $EXTERNAL_NET och $HOME_NET. Vissa regler använder dock mer specifika variabler. De regler som gäller DNS-servrar (i filen dns.rules) använder till exempel variabeln $DNS_SERVERS. Definiera dessa variabler i konfigurationsfilen för Snort (vanligtvis snort.conf). Du kan eventuellt skapa egna variabler för att återspegla din topologi (t.ex. $MAIL_SERVERS) och för användning i anpassade regler. Definiera en variabel genom att använda dess namn (t.ex. var MAIL_SERVERS= 192.168.0.20/30) och referera sedan till variabeln genom att sätta ett dollartecken ($ – t.ex. $MAIL_SERVERS) före variabeln. Regelåtgärden och dessa parametrar utgör regelhuvudet.
Regelalternativen förfinar regeln ytterligare så att ett misstänkt paket (och endast ett misstänkt paket) utlöser ett svar. Som du kanske kan gissa kan dessa signaturer bli ganska detaljerade och sträcka sig långt bortom enkel portmatchning. Föreställ dig till exempel de falska positiva resultat som skulle uppstå om den här Slammer-regeln bara varnade dig för all UDP-port 1434-trafik.
Missalternativet msg
msg:"MS-SQL Worm propagation attempt"
ger en enkel beskrivning av varningen som kan användas vid varning och rapportering. Alternativet content
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
innehåller den stor- och småskaliga strängen för matchning av nyttolastmönster, antingen i ASCII- eller hexadecimala värden (omsluta hexadecimala värden med pipe-tecknet-|). Du kan ange flera innehållsalternativ. Djupalternativet följer efter varje innehållsalternativ och anger hur många bytes i nyttolasten du vill söka efter det angivna innehållet. I det här exemplet utlöser ett paket ett svar om det innehåller hexvärdet 04 i den första byten eller det återstående innehållet någonstans i nyttolasten.
Nedladdade regler innehåller ofta hänvisningar till detaljerad information om den misstänkta exploateringen eller anledningen till att regeln skapades. Vissa rapporteringssystem stöder referensalternativet genom att tillhandahålla direkta länkar till denna information:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
Snort tilldelar regler till klasser och tilldelar dessa klasser en prioritet på hög, medelhög eller låg. För närvarande finns mer än 30 klassificeringar, bland annat försök till administration, trojanaktivitet, försök till överbelastning och nätverksskanning. I vårt exempel är klassificeringen
classtype:misc-attack
Snort registrerar svarsprioriteten för upptäckta intrång. Du kan använda ett externt verktyg eller skript för att ytterligare analysera denna prioritet och vidta åtgärder med ditt rapporteringsprogram.
I det sista segmentet
sid:2003; rev:2;
sid representerar en unik Snort-regel och rev anger revisionsnumret. Dessa egenskaper identifierar regeln på ett unikt sätt.
Skärpning av regeln
Nedan undersöker vi hur den här regeln kan ändras så att den ger en eskalerad varning när den upptäcker interna infekterade värddatorer. Eftersom vi har att göra med samma exploatering som i den ursprungliga regeln förblir innehållsdefinitionen för regeln densamma. Vi behöver bara ändra IP-adresserna och trafikriktningen. Vi ändrar källans IP-adress till $HOME_NET enligt följande:
udp $HOME_NET any -> $EXTERNAL_NET 1434
Snort.conf definierar $EXTERNAL_NET som ”any”, så den här regeln kommer fortfarande att fånga upp korrupta paket som riktar sig mot interna värdar (precis som den ursprungliga regeln). Men nu när vi har en dedikerad regel som endast spårar interna käll-IP-adresser kan vi ändra åtgärdstypen till en anpassad åtgärdstyp som utlöser en eskalerad varning.
De nuvarande Snort-reglerna innehåller den här regeln för upptäckt av utgående Slammer-mask i standardregeluppsättningen. Men när en ny mask, ett nytt virus eller en annan exploatering börjar spridas kan du överväga att skapa nya regler som belyser specifika intrång.
Skapa dina regler
Förutom befintliga eller anpassade regler som du kan modifiera eller skapa kan du även inkludera regler som du får från en annan källa. När till exempel nyheter om en ny mask sprids på Internet är säkerhetssajter och nyhetsgrupper snabba på att publicera enstaka Snort-regler som kan upptäcka den nya masken. Klistra in dessa nya regler i filen local.rules och starta sedan om Snort för att de nya reglerna ska träda i kraft.
Snort ger ramarna för ett billigt och anpassningsbart IDS. Med stöd av en regeluppsättning som stöds av gemenskapen förblir Snort ett flexibelt och effektivt system. Om du håller dina regler uppdaterade ökar din vaksamhet och minskar det brus som uppstår till följd av ineffektiva varningar. Som med alla projekt med öppen källkod, om du tar dig tid att förstå hur det fungerar och bekantar dig med de tillägg som utvecklats av samhället, kommer du att bli mycket bekvämare med systemet och öka dess effektivitet i din miljö.