Effectieve Snort regels schrijven met voorbeelden [Best Practices]

Dit bericht zal u helpen effectieve Snort regels te schrijven om uw veiligheidspositie wezenlijk te verbeteren. We beginnen met een uitsplitsing van hoe een regel is opgebouwd en verkennen dan de beste praktijken met voorbeelden om zoveel mogelijk kwaadaardige activiteiten vast te leggen met zo weinig mogelijk regels.

Snort is een open-source netwerk intrusion detection system (NIDS) dat real-time packet-analyse biedt en deel uitmaakt van de Coralogix STA-oplossing. Als je een Coralogix STA klant bent, bekijk dan ook mijn eerdere post over het bewerken van Snort Rules in STA.

Anatomie van Snort Rules

Voordat we duiken in de verschillende strategieën voor het schrijven van je beste Snort Rules, laten we beginnen met het ontleden van een voorbeeld Snort Rule:

alert: vertelt Snort om dit gedrag te rapporteren als een alert (het is verplicht in regels die zijn gemaakt voor de STA).

tcp: betekent dat deze regel alleen van toepassing is op verkeer in TCP.

any: betekent in deze context “van elke bronpoort”, dan is er een pijl ‘->’ wat betekent “een verbinding met” (er is geen ‘<-‘ operator, maar je kunt de argumenten gewoon omdraaien rond de operator. Je kan de ‘<>’ operator gebruiken om aan te geven dat de verbindingsrichting irrelevant is voor deze regel), dan een IP bereik dat het bestemming IP adres aangeeft en dan de poort. Je kunt een poortbereik aangeven door een dubbele punt te gebruiken zoals 0:1024 wat betekent 0-1024. In de ronde haakjes staan enkele directieven voor het instellen van het waarschuwingsbericht, metadata over de regel, en aanvullende controles.

msg: is een directief dat eenvoudigweg het bericht instelt dat zal worden verzonden (naar Coralogix in het STA geval) in het geval een overeenkomend verkeer zal worden gedetecteerd.

flow: is een directief dat aangeeft of de inhoud die we op het punt staan te definiëren als onze handtekening moet verschijnen in de communicatie naar de server (“to_server”) of naar de client (“to_client”). Dit kan erg nuttig zijn als we, bijvoorbeeld, het antwoord van de server willen detecteren dat aangeeft dat er inbreuk is gepleegd.

established: is een richtlijn die ervoor zorgt dat Snort het zoeken naar pakketten die overeenkomen met deze handtekening beperkt tot pakketten die alleen deel uitmaken van gevestigde verbindingen. Dit is nuttig om de belasting van Snort te minimaliseren.

uricontent: is een richtlijn die Snort instrueert om te zoeken naar een bepaalde tekst in de genormaliseerde HTTP URI inhoud. In dit voorbeeld zoeken we naar een url die precies de tekst “/root.exe” is.

nocase: is een directive die aangeeft dat we Snort een hoofdletterongevoelige zoekopdracht willen laten uitvoeren.

classtype: is een directive die een metadata attribuut is dat aangeeft welk type activiteit deze regel detecteert.

reference: is een directive die een metadata attribuut is dat linkt naar een ander systeem voor meer informatie. In ons voorbeeld verwijst de waarde url,<https://….> naar een URL op het internet.

sid: is een richtlijn die een metagegevensattribuut is dat de handtekening-ID aangeeft. Als u uw eigen handtekening maakt (zelfs als u alleen een ingebouwde regel vervangt), gebruik dan een waarde boven 9.000.000 om een botsing met een andere reeds bestaande regel te voorkomen.

rev: is een richtlijn die de versie van de regel aangeeft.

Er is nog veel meer te leren over Snort-regels die RegEx parsing, protocol-specifieke parsing (net als uricontent voor HTTP), zoeken naar binaire (niet-tekstuele) gegevens door hex-waarden van bytes te gebruiken, en nog veel meer. Als je meer wilt weten kun je hier beginnen.

Best Practices to Writing Effective Snort Rules

1. Richt je op de kwetsbaarheid, niet op de exploit – Vermijd het schrijven van regels voor het detecteren van een specifieke exploit kit omdat er ontelbare exploits zijn voor dezelfde kwetsbaarheid en we er zeker van kunnen zijn dat er nieuwe worden geschreven terwijl je dit leest. Veel van de vroege signatures voor het detecteren van buffer overrun aanvallen zagen er bijvoorbeeld als volgt uit:

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

   De reden daarvoor is natuurlijk dat om een succesvolle buffer overrun aanval te lanceren, de aanvaller de buffer van een bepaalde variabele moet vullen en zijn kwaadaardige payload aan het eind moet toevoegen zodat het uitvoerbaar wordt. De karakters die hij kiest om de buffer te vullen zijn totaal onbelangrijk en inderdaad, nadat zulke handtekeningen verschenen, gebruikten veel aanvalstoolkits gewoon een andere letter of letters om de buffer te vullen en omzeilden zo volledig de detectie van dit type handtekening. Een veel betere manier zou zijn om dit soort aanvallen te detecteren door onjuiste invoer in velden op basis van hun type en lengte te detecteren.

2. Uw eigenaardigheid is uw beste troef, dus gebruik het – Elke organisatie heeft dingen die haar uniek maken. Veel van deze kunnen heel nuttig zijn wanneer u probeert om kwaadaardige activiteiten in uw organisatie te vangen – zowel extern als intern. Door deze diepgaande interne kennis in uw voordeel te gebruiken, verandert u het probleem in wezen van een technologisch probleem in een puur ouderwets inlichtingenprobleem, waarbij aanvallers gedwongen worden uw organisatie veel beter te begrijpen om hun sporen effectief te kunnen verbergen. Deze zaken kunnen van technologische aard zijn of gebaseerd zijn op de specifieke werkgewoonten en interne richtlijnen van uw organisatie. Hier zijn enkele voorbeelden:
   • Typische werktijden: Sommige organisaties waar ik heb gewerkt, stonden werknemers helemaal niet toe om thuis te werken en de meerderheid van de werknemers zou het kantoor al tegen 19:00 uur hebben verlaten. Voor dergelijke organisaties zou het zinvol zijn om een waarschuwing in te stellen om u op de hoogte te brengen van verbindingen vanuit het kantoor na een bepaald uur. Een aanvaller die kwaadaardige software in uw organisatie zou installeren, zou dat gedrag moeten kennen en zijn malware zo moeten afstellen dat deze precies op dat tijdstip met zijn Command & Control servers communiceert, zodat dergelijke communicatie onopgemerkt blijft.
   • Typische Browser: Stel dat uw organisatie heeft besloten om de Brave browser te gebruiken als haar belangrijkste browser en deze wordt automatisch geïnstalleerd op elke nieuwe bedrijfslaptop en u heeft de desktop snelkoppelingen naar IE/Edge browser verwijderd van al uw bedrijfslaptops. Als dit het geval is, moet een verbinding vanuit de organisatie, zowel naar een intern als extern adres die een andere browser zoals IE/Edge gebruiken, worden geconfigureerd om een waarschuwing te geven.
   • IP Bereiken gebaseerd op Rollen: Als het mogelijk is voor u om verschillende IP ranges toe te wijzen voor verschillende servers op basis van hun rol, bijvoorbeeld om alle DB servers op 192.168.0.0/24 te hebben, de web servers op 192.168.1.0/24, enz dan zou het mogelijk zijn en zelfs gemakkelijk om slimme regels op te zetten op basis van het verwachte gedrag van uw servers op basis van hun rol. Bijvoorbeeld, database servers maken gewoonlijk geen verbinding met andere servers op zichzelf, printers proberen geen verbinding te maken met uw domeincontrollers, enz.
   • Ongebruikelijke Verbindingspogingen: Veel organisaties gebruiken een openbare share op een bestandsserver om hun gebruikers te helpen bestanden onderling te delen en gebruiken printers met netwerkondersteuning om hun gebruikers in staat te stellen rechtstreeks vanaf hun computers af te drukken. Dat betekent dat client computers geen verbinding met elkaar mogen maken, zelfs als u er (wijselijk) voor heeft gekozen om dergelijke toegang te blokkeren in een firewall of bij de switch, zou alleen al de poging om verbinding te maken van een client naar een andere client computer een waarschuwing moeten geven en grondig onderzocht moeten worden.
   • Ongebruikelijke Poorten: Sommige organisaties gebruiken een speciale bibliotheek voor communicatie-optimalisaties tussen diensten, zodat alle HTTP-communicatie tussen servers een andere poort gebruikt dan de gebruikelijke (zoals 80, 443, 8080, enz.). In dit geval is het een goed idee om een regel te maken die getriggerd zou worden door elke communicatie op deze normaal gebruikelijke poorten.
3. Honeytokens – In een slagveld als het Internet waar iedereen zo ongeveer iedereen kan zijn, werkt misleiding, voor verdedigers net zo goed als voor de aanvallers, zo niet beter. Trucs zoals het hernoemen van de ingebouwde administrator account naar een andere, minder aantrekkelijke naam en het aanmaken van een nieuwe account met de naam Administrator die je nooit zult gebruiken en het aanmaken van een Snort regel om te detecteren of deze gebruikersnaam, e-mail of wachtwoord ooit gebruikt worden op het netwerk. Het zou bijna onmogelijk zijn voor aanvallers om te merken dat Snort hun pogingen om de nep administrator gebruiker te gebruiken heeft gedetecteerd. Een ander voorbeeld is het creëren van nep producten, klanten, gebruikers en credit card records in de database en dan Snort regels afstemmen om ze te detecteren in het netwerkverkeer.

We hopen dat u deze informatie nuttig vond. Voor meer informatie over de Coralogix STA, bekijk de nieuwste functies die we onlangs hebben vrijgegeven.