Det här inlägget kommer att hjälpa dig att skriva effektiva Snort-regler för att väsentligt förbättra din säkerhetsställning. Vi börjar med en uppdelning av hur en regel konstrueras och utforskar sedan bästa praxis med exempel för att fånga upp så många skadliga aktiviteter som möjligt samtidigt som du använder så få regler som möjligt.
Snort är ett nätverksintrångsdetekteringssystem (NIDS) med öppen källkod som ger paketanalys i realtid och är en del av Coralogix STA-lösning. Om du är Coralogix STA-kund ska du också se till att kolla in mitt tidigare inlägg om hur du redigerar Snort-regler i STA.
Anatomi av Snort-regler
För att dyka ner i de olika strategierna för att skriva dina bästa Snort-regler börjar vi med att dissekera ett exempel på en Snort-regel:
alert: talar om för Snort att rapportera det här beteendet som en varning (det är obligatoriskt i regler skapade för STA).
tcp: innebär att den här regeln endast gäller för trafik i TCP.
any: i det här sammanhanget betyder det ”från vilken källport som helst”, sedan finns det en pil ”->” som betyder ”en anslutning till” (det finns ingen ”<-”-operatör, men du kan helt enkelt vända på argumenten runt operatören. Du kan använda operatören ”<>” för att ange att anslutningsriktningen är irrelevant för den här regeln), sedan ett IP-område som anger destinations-IP-adressen och därefter porten. Du kan ange ett portintervall genom att använda kolon, t.ex. 0:1024 som betyder 0-1024. I den runda parentesen finns några direktiv för att ställa in varningsmeddelandet, metadata om regeln samt ytterligare kontroller.
msg: är ett direktiv som helt enkelt ställer in meddelandet som ska skickas (till Coralogix i STA-fallet) om en matchande trafik upptäcks.
flow: är ett direktiv som anger om det innehåll som vi ska definiera som vår signatur måste förekomma i kommunikationen till servern (”to_server”) eller till klienten (”to_client”). Detta kan vara mycket användbart om vi till exempel vill upptäcka serverns svar som visar att den har blivit kränkt.
established: är ett direktiv som gör att Snort begränsar sin sökning efter paket som matchar den här signaturen till endast paket som ingår i etablerade anslutningar. Detta är användbart för att minimera belastningen på Snort.
uricontent: är ett direktiv som instruerar Snort att leta efter en viss text i det normaliserade HTTP URI-innehållet. I det här exemplet letar vi efter en url som är exakt texten ”/root.exe”.
nocase: är ett direktiv som anger att vi vill att Snort ska utföra en sökning som inte tar hänsyn till stor- och små bokstäver.
classtype: är ett direktiv som är ett metadataattribut som anger vilken typ av aktivitet den här regeln upptäcker.
reference: är ett direktiv som är ett metadataattribut som länkar till ett annat system för mer information. I vårt exempel länkar värdet url,<https://….> till en URL på Internet.
sid: är ett direktiv som är ett metadataattribut som anger signatur-ID. Om du skapar en egen signatur (även om du bara ersätter en inbyggd regel), använd ett värde över 9 000 000 000 för att förhindra en kollision med en annan redan existerande regel.
rev: är ett direktiv som anger regelns version.
Det finns mycket mer att lära sig om Snort-regler, som stöder RegEx-analysering, protokollspecifik analysering (precis som uricontent för HTTP), letar efter binärdata (icke-textuell data) med hjälp av bytes-hex-värden, och mycket mycket mer. Om du vill veta mer kan du börja här.
Bästa metoder för att skriva effektiva Snort-regler
- Rikta dig mot sårbarheten, inte mot exploiten – Undvik att skriva regler för att upptäcka ett specifikt exploit-kit eftersom det finns otaliga exploits för samma sårbarhet och vi kan vara säkra på att nya exploits skrivs medan du läser detta. Till exempel såg många av de tidiga signaturerna för att upptäcka buffer overrun-attacker ut så här:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Anledningen till detta är naturligtvis att för att kunna genomföra en lyckad buffer overrun-attack måste angriparen fylla bufferten med en viss variabel och lägga till sin skadliga nyttolast i slutet så att den blir körbar. De tecken han väljer att använda för att fylla bufferten är helt obetydliga och efter att sådana signaturer dök upp använde många attackverktyg helt enkelt en eller flera andra bokstäver för att fylla bufferten och undgick helt och hållet denna typ av signaturdetektering. Ett mycket bättre sätt skulle vara att försöka upptäcka den här typen av attacker genom att upptäcka felaktig inmatning i fält baserat på deras typ och längd.
- Din egenhet är din bästa tillgång, så använd den – Varje organisation har saker som gör den unik. Många av dessa kan vara ganska användbara när du försöker fånga upp skadlig verksamhet i din organisation – både extern och intern. Genom att använda denna djupa interna kunskap till din fördel omvandlar du i huvudsak problemet från ett tekniskt problem till ett rent gammaldags underrättelseproblem, vilket tvingar angriparna att ha en mycket mer ingående förståelse för din organisation för att kunna dölja sina spår på ett effektivt sätt. Dessa saker kan vara av teknisk karaktär eller baserade på din organisations särskilda arbetsvanor och interna riktlinjer. Här är några exempel:
- Typiska arbetstider: Vissa organisationer som jag arbetade på tillät inte anställda att arbeta hemifrån överhuvudtaget och majoriteten av de anställda skulle redan ha lämnat kontoret vid 19.00-tiden. För liknande organisationer skulle det vara vettigt att ställa in en varning som meddelar dig om anslutningar från kontoret efter en viss timme. En angripare som skulle installera skadlig programvara i din organisation skulle behöva känna till detta beteende och ställa in sin skadlig programvara så att den kommunicerar med sina Command & Control-servrar vid exakt samma tidpunkt, så att sådan kommunikation skulle gå obemärkt förbi.
- Typisk webbläsare: Anta att din organisation har beslutat att använda webbläsaren Brave som huvudwebbläsare och att den installeras automatiskt på alla nya bärbara datorer på företaget och att du har tagit bort skrivbordsgenvägarna till webbläsaren IE/Edge från alla dina bärbara datorer på företaget. Om detta är fallet bör en anslutning från organisationen, både till interna och externa adresser som använder en annan webbläsare som IE/Edge, konfigureras så att en varning utlöses.
- IP-områden baserade på roller: Om det är möjligt att tilldela olika IP-områden för olika servrar baserat på deras roll, t.ex. att ha alla DB-servrar på 192.168.0.0/24, webbservrarna på 192.168.1.0/24 osv. så skulle det vara möjligt och till och med enkelt att sätta upp smarta regler baserade på servrarnas förväntade beteende baserat på deras roll. Till exempel brukar databasservrar inte ansluta till andra servrar på egen hand, skrivare försöker inte ansluta till domänkontrollanter osv.
- Ovanliga anslutningsförsök: Många organisationer använder en offentlig delning på en filserver för att hjälpa användarna att dela filer mellan dem och använder nätverksaktiverade skrivare så att användarna kan skriva ut direkt från sina datorer. Detta innebär att klientdatorer inte bör ansluta till varandra, även om du (klokt nog) har valt att blockera sådan åtkomst i en brandvägg eller vid växeln, bör själva försöket att ansluta från en klient till en annan klientdator ge upphov till en varning och undersökas grundligt.
- Ovanliga portar: Vissa organisationer använder ett särskilt bibliotek för kommunikationsoptimering mellan tjänster så att all HTTP-kommunikation mellan servrar använder en annan port än de vanliga portarna (t.ex. 80, 443, 8080 osv.). I det här fallet är det en bra idé att skapa en regel som utlöses av all kommunikation på dessa normalt vanliga portar.
- Honeytokens – På ett slagfält som Internet, där alla kan vara precis vem som helst, fungerar bedrägeri lika bra för försvararna som för angriparna, om inte bättre. Tricks som att byta namn på det inbyggda administratörskontot till ett annat, mindre attraktivt namn och skapa ett nytt konto med namnet Administratör som du aldrig kommer att använda och skapa en Snort-regel för att upptäcka om detta användarnamn, e-post eller lösenord någonsin används i nätverket. Det skulle vara näst intill omöjligt för angriparna att märka att Snort har upptäckt deras försök att använda den falska administratörsanvändaren. Ett annat exempel är att skapa falska produkter, kunder, användare och kreditkortsposter i databasen och sedan matcha Snort-regler för att upptäcka dem i nätverkstrafiken.
Vi hoppas att du fann den här informationen användbar. För mer information om Coralogix STA, kolla in de senaste funktionerna som vi nyligen släppte.