Skrivning af effektive Snort-regler med eksempler [Best Practices]

Dette indlæg vil hjælpe dig med at skrive effektive Snort-regler for at forbedre din sikkerhedstilstand væsentligt. Vi vil begynde med en opdeling af, hvordan en regel er konstrueret, og derefter udforske bedste praksis med eksempler for at fange så mange skadelige aktiviteter som muligt, mens du bruger så få regler som muligt.

Snort er et open source network intrusion detection system (NIDS), der giver realtidspakkeanalyse og er en del af Coralogix STA-løsningen. Hvis du er Coralogix STA-kunde, skal du også huske at tjekke mit tidligere indlæg om, hvordan du redigerer Snort-regler i STA.

Anatomi af Snort-regler

Hvor vi dykker ned i de forskellige strategier til at skrive dine bedste Snort-regler, skal vi starte med at dissekere et eksempel på en Snort-regel:

alert: fortæller Snort, at det skal rapportere denne adfærd som en alarm (det er obligatorisk i regler, der er oprettet til STA).

tcp: betyder, at denne regel kun gælder for trafik i TCP.

any: i denne sammenhæng betyder det “fra enhver kildeport”, så er der en pil ‘->’, som betyder “en forbindelse til” (der er ikke en ‘<-‘-operator, men du kan simpelthen vende argumenterne rundt om operatoren. Du kan bruge operatoren ‘<>’ for at angive, at forbindelsesretningen er irrelevant for denne regel), derefter et IP-område, som angiver destinations-IP-adressen og derefter porten. Du kan angive et portområde ved at bruge kolon som f.eks. 0:1024, hvilket betyder 0-1024. I den runde parentes er der nogle direktiver til indstilling af advarselsmeddelelsen, metadata om reglen samt yderligere kontroller.

msg: er et direktiv, der blot indstiller den meddelelse, der skal sendes (til Coralogix i STA-tilfældet) i tilfælde af, at en matchende trafik bliver opdaget.

flow: er et direktiv, der angiver, om det indhold, vi er ved at definere som vores signatur, skal vises i kommunikationen til serveren (“to_server”) eller til klienten (“to_client”). Dette kan være meget nyttigt, hvis vi f.eks. gerne vil opdage serverens svar, der viser, at den er blevet overtrådt.

established: er et direktiv, der får Snort til at begrænse sin søgning efter pakker, der matcher denne signatur, til kun at omfatte pakker, der er en del af etablerede forbindelser. Dette er nyttigt for at minimere belastningen på Snort.

uricontent: er et direktiv, der instruerer Snort om at lede efter en bestemt tekst i det normaliserede HTTP URI-indhold. I dette eksempel leder vi efter en url, der præcis er teksten “/root.exe”.

nocase: er et direktiv, der angiver, at vi ønsker, at Snort skal foretage en søgning, der ikke tager hensyn til store og små bogstaver.

classtype: er et direktiv, der er en metadataattribut, der angiver, hvilken type aktivitet denne regel registrerer.

reference: er et direktiv, der er en metadataattribut, der linker til et andet system for at få flere oplysninger. I vores eksempel linker værdien url,<https://….> til en URL på internettet.

sid: er et direktiv, der er en metadataattribut, som angiver signatur-id’et. Hvis du opretter din egen signatur (selv hvis du blot erstatter en indbygget regel), skal du bruge en værdi over 9.000.000.000 for at forhindre en kollision med en anden allerede eksisterende regel.

rev: er et direktiv, der angiver reglens version.

Der er meget mere at lære om Snort-regler, som understøtter RegEx-parsing, protokolspecifik parsing (ligesom uricontent for HTTP), søgning efter binære (ikke-tekstuelle) data ved hjælp af bytes hex-værdier og meget, meget mere. Hvis du gerne vil vide mere, kan du starte her.

Best Practices to Writing Effective Snort Rules

1. Målret sårbarheden, ikke exploit – Undgå at skrive regler for at detektere et specifikt exploit kit, fordi der findes utallige exploits for den samme sårbarhed, og vi kan være sikre på, at der bliver skrevet nye, mens du læser dette. For eksempel så mange af de tidlige signaturer til detektering af bufferoverløbsangreb sådan ud:

   alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")

   Grunden til det er naturligvis, at for at iværksætte et vellykket bufferoverløbsangreb skal angriberen fylde bufferen for en bestemt variabel og tilføje sin skadelige nyttelast til sidst, så den bliver eksekverbar. De tegn, som han vælger at bruge til at fylde bufferen, er fuldstændig ligegyldige, og efter at sådanne signaturer dukkede op, brugte mange angrebsværktøjskits ganske enkelt et eller flere andre bogstaver til at fylde bufferen og undgik fuldstændig denne type signaturdetektion. En langt bedre måde ville være at forsøge at opdage denne type angreb ved at opdage forkert input til felter baseret på deres type og længde.

2. Dit særpræg er dit bedste aktiv, så brug det – Enhver organisation har ting, der gør den unik. Mange af disse kan være ganske nyttige, når du forsøger at fange skadelig aktivitet i din organisation – både ekstern og intern. Ved at bruge denne dybe interne viden til din fordel vil du i bund og grund konvertere problemet fra et teknologisk problem til et rent gammeldags efterretningsproblem, hvilket tvinger angriberne til at have en meget mere indgående forståelse af din organisation for at kunne skjule deres spor effektivt. Disse ting kan være af teknologisk art eller baseret på din organisations særlige arbejdsvaner og interne retningslinjer. Her er nogle eksempler:
   • Typiske arbejdstider: Nogle organisationer, jeg arbejdede i, tillod slet ikke, at medarbejderne arbejdede hjemmefra, og de fleste medarbejdere ville allerede have forladt kontoret kl. 19.00. For lignende organisationer ville det give mening at indstille en alarm til at give besked om forbindelser fra kontoret efter en bestemt time. En angriber, der ville installere skadelig software i din organisation, ville være nødt til at kende denne adfærd og indstille sin malware til at kommunikere med sine Command & Control-servere på præcis samme tidspunkt, så en sådan kommunikation ville gå ubemærket hen.
   • Typisk browser: Antag, at din organisation har besluttet at bruge Brave-browseren som hovedbrowser, og at den automatisk installeres på alle nye bærbare computere i virksomheden, og at du har fjernet genvejene til IE/Edge-browseren fra alle dine bærbare computere i virksomheden. Hvis dette er tilfældet, skal en forbindelse fra organisationen, både til en intern og ekstern adresse, der bruger en anden browser som IE/Edge, konfigureres til at udløse en advarsel.
   • IP-rækkevidder baseret på roller: Hvis det er muligt for dig at tildele forskellige IP-områder til forskellige servere baseret på deres rolle, f.eks. at have alle DB-servere på 192.168.0.0/24, webservere på 192.168.1.0/24 osv. så vil det være muligt og endda nemt at opsætte smarte regler baseret på den forventede adfærd for dine servere baseret på deres rolle. F.eks. plejer databaseservere normalt ikke at oprette forbindelse til andre servere på egen hånd, printere forsøger ikke at oprette forbindelse til dine domænecontrollere osv.
   • Usædvanlige forbindelsesforsøg: Mange organisationer bruger en offentlig deling på en filserver for at hjælpe deres brugere med at dele filer mellem dem og bruger netværksaktiverede printere for at give deres brugere mulighed for at udskrive direkte fra deres computere. Det betyder, at klientcomputere ikke bør oprette forbindelse til hinanden, selv om du (klogt nok) har valgt at blokere en sådan adgang i en firewall eller på switchen, bør selve forsøget på at oprette forbindelse fra en klient til en anden klientcomputer give anledning til en advarsel og undersøges grundigt.
   • Ualmindelige porte: Nogle organisationer anvender et særligt bibliotek til optimering af kommunikationen mellem tjenester, således at al HTTP-kommunikation mellem servere anvender en anden port end de almindelige porte (f.eks. 80, 443, 8080 osv.). I dette tilfælde er det en god idé at oprette en regel, der udløses af enhver kommunikation på disse normalt almindelige porte.
3. Honeytokens – På en slagmark som internettet, hvor alle kan være næsten hvem som helst, fungerer vildledning lige så godt for forsvarerne som for angriberne, hvis ikke bedre. Tricks som at omdøbe den indbyggede administratorkonto til et andet, mindre attraktivt navn og oprette en ny konto med navnet Administrator, som du aldrig vil bruge, og oprette en Snort-regel til at registrere, hvis dette brugernavn, e-mail eller password nogensinde bruges på netværket. Det vil være næsten umuligt for angribere at bemærke, at Snort har opdaget deres forsøg på at bruge den falske administratorbruger. Et andet eksempel er at oprette falske produkter, kunder, brugere og kreditkortposter i databasen og derefter matche Snort-regler til at detektere dem i netværkstrafikken.

Vi håber, at du fandt disse oplysninger nyttige. Du kan få flere oplysninger om Coralogix STA ved at tjekke de seneste funktioner, som vi for nylig har frigivet.