Tämä viesti auttaa sinua kirjoittamaan tehokkaita Snort-sääntöjä, jotka parantavat tietoturvaa merkittävästi. Aloitamme erittelyllä siitä, miten sääntö rakennetaan, ja sen jälkeen tarkastelemme parhaita käytäntöjä esimerkkien avulla, jotta voit kaapata mahdollisimman paljon haitallisia toimintoja käyttämällä mahdollisimman vähän sääntöjä.
Snort on avoimen lähdekoodin verkon tunkeutumisen havaitsemisjärjestelmä (Network Intrusion Detection System, NIDS), joka tarjoaa reaaliaikaista pakettianalyysiä ja on osa Coralogixin STA-ratkaisua. Jos olet Coralogix STA -asiakas, muista lukea myös aiempi kirjoitukseni siitä, miten Snortin sääntöjä muokataan STA:ssa.
Snortin sääntöjen anatomia
Ennen kuin sukellamme erilaisiin strategioihin parhaiden Snort-sääntöjen kirjoittamiseksi, aloitetaan purkamalla esimerkki Snort-sääntöä:
alert: käskee Snortia raportoimaan tämän käyttäytymisen hälytyksenä (se on pakollinen STA:ta varten luoduissa säännöissä).
tcp: tarkoittaa, että tätä sääntöä sovelletaan vain TCP-liikenteeseen.
any: tässä yhteydessä se tarkoittaa ”mistä tahansa lähdeportista”, sitten on nuoli ’-
msg: on direktiivi, jolla yksinkertaisesti asetetaan viesti, joka lähetetään (STA-tapauksessa Coralogixille) siinä tapauksessa, että havaitaan täsmäävää liikennettä.
flow: on direktiivi, jolla ilmoitetaan, pitääkö sisällön, jonka määrittelemme allekirjoitukseksemme, näkyä palvelimelle suuntautuvassa tietoliikenteessä (”to_server”) vai asiakkaalle suuntautuvassa tiedonsiirrossa (”to_client”). Tämä voi olla erittäin hyödyllistä, jos haluamme esimerkiksi havaita palvelimen vastauksen, joka osoittaa, että sitä on rikottu.
established: on direktiivi, joka saa Snortin rajoittamaan tämän allekirjoituksen mukaisten pakettien etsimisen vain paketteihin, jotka ovat osa vakiintuneita yhteyksiä. Tämä on hyödyllistä Snortin kuormituksen minimoimiseksi.
uricontent: on direktiivi, joka ohjaa Snortia etsimään tiettyä tekstiä normalisoidun HTTP URI:n sisällöstä. Tässä esimerkissä etsitään url-osoitetta, joka on täsmälleen teksti ”/root.exe”.
nocase: on direktiivi, joka ilmaisee, että haluamme Snortin tekevän isoja ja pieniä kirjaimia erittelemättömän haun.
classtype: on direktiivi, joka on metatietoattribuutti, joka ilmaisee, minkä tyyppistä toimintaa tämä sääntö havaitsee.
reference: on direktiivi, joka on metatietoattribuutti, joka on linkki johonkin muuhun järjestelmään, josta saa lisätietoja. Esimerkissämme arvo url,<https://….> linkittää URL-osoitteeseen Internetissä.
sid: on direktiivi, joka on metatietoattribuutti, joka ilmaisee allekirjoituksen ID:n. Jos olet luomassa omaa allekirjoitusta (vaikka vain korvaisit sisäänrakennetun säännön), käytä arvoa, joka on suurempi kuin 9 000 000, jotta estät törmäyksen toisen jo olemassa olevan säännön kanssa.
rev: on direktiivi, joka ilmaisee säännön version.
Snortin säännöistä on paljon muutakin opittavaa, sillä ne tukevat RegEx-jäsennystä, protokollakohtaista jäsennystä (kuten uricontent HTTP:n osalta), binäärisen (ei-tekstimuotoisen) datan etsimistä tavujen heksa-arvojen avulla ja paljon paljon muuta. Jos haluat tietää lisää, voit aloittaa täältä.
Parhaat käytännöt tehokkaiden Snort-sääntöjen kirjoittamiseen
- Tähtää haavoittuvuuteen, älä hyväksikäyttöön – Vältä kirjoittamasta sääntöjä tietyn hyväksikäyttösarjan havaitsemiseksi, koska samaan haavoittuvuuteen on olemassa lukemattomia hyväksikäyttöjä ja voimme olla varmoja siitä, että uusia kirjoitetaan sillä aikaa, kun luet tätä. Esimerkiksi monet varhaiset allekirjoitukset puskurin ylikulkuhyökkäysten havaitsemiseksi näyttivät tältä:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Syy tähän on tietenkin se, että onnistuneen puskurin ylikulkuhyökkäyksen käynnistämiseksi hyökkääjän on täytettävä tietyn muuttujan puskuri ja lisättävä haitallista hyötykuormaa loppuun, jotta siitä tulisi suoritettava. Merkit, joita hän käyttää puskurin täyttämiseen, ovat täysin merkityksettömiä, ja itse asiassa tällaisten allekirjoitusten ilmestymisen jälkeen monet hyökkäystyökalupaketit yksinkertaisesti käyttivät eri kirjainta tai kirjaimia puskurin täyttämiseen ja välttivät täysin tämäntyyppisen allekirjoituksen havaitsemisen. Paljon parempi tapa olisi yrittää havaita tällaiset hyökkäykset havaitsemalla kenttien virheellinen syöttö niiden tyypin ja pituuden perusteella.
- Erikoisuutesi on paras voimavarasi, joten käytä sitä – Jokaisessa organisaatiossa on asioita, jotka tekevät siitä ainutlaatuisen. Monet näistä voivat olla varsin hyödyllisiä, kun yrität saada kiinni organisaatiossasi tapahtuvaa haitallista toimintaa – sekä ulkoista että sisäistä. Käyttämällä tätä syvää sisäistä tietämystä hyödyksesi muutat ongelman teknologisesta ongelmasta puhtaasti vanhan koulukunnan tiedusteluongelmaksi ja pakotat hyökkääjät tuntemaan organisaatiosi paljon paremmin, jotta he voivat piilottaa jälkensä tehokkaasti. Nämä asiat voivat olla luonteeltaan teknologisia tai perustua organisaatiosi erityisiin työskentelytapoihin ja sisäisiin ohjeisiin. Tässä muutamia esimerkkejä:
- Tyypilliset työajat: Joissakin organisaatioissa, joissa työskentelin, työntekijät eivät saaneet työskennellä kotoa käsin lainkaan, ja suurin osa työntekijöistä oli lähtenyt toimistolta jo klo 19:00 mennessä. Vastaavissa organisaatioissa olisi järkevää asettaa hälytys, joka ilmoittaa toimistosta lähtevistä yhteyksistä tietyn kellonajan jälkeen. Hyökkääjän, joka asentaisi organisaatioonne haittaohjelmia, olisi tiedettävä tämä käyttäytyminen ja viritettävä haittaohjelmansa kommunikoimaan komento- & ohjauspalvelimiensa kanssa juuri samaan aikaan, jolloin tällainen kommunikointi jäisi huomaamatta.
- Tyypillinen selain: Oletetaan, että organisaatiosi on päättänyt käyttää Brave-selainta pääasiallisena selaimenaan, ja se asennetaan jokaiseen uuteen yrityskannettavaan automaattisesti, ja olet poistanut IE/Edge-selaimen työpöydän pikakuvakkeet kaikista yrityskannettavistasi. Jos näin on, organisaatiosta tuleva yhteys sekä sisäisiin että ulkoisiin osoitteisiin, jotka käyttävät eri selainta, kuten IE/Edgeä, olisi määritettävä niin, että se herättää hälytyksen.
- IP-alueita roolien perusteella: Esimerkiksi kaikki tietokantapalvelimet ovat osoitteessa 192.168.0.0/24, verkkopalvelimet osoitteessa 192.168.1.0/24 jne., jolloin olisi mahdollista ja jopa helppoa laatia älykkäitä sääntöjä, jotka perustuvat palvelinten odotettuun käyttäytymiseen niiden roolin perusteella. Esimerkiksi tietokantapalvelimet eivät yleensä muodosta yhteyttä muihin palvelimiin yksinään, tulostimet eivät yritä muodostaa yhteyttä toimialueen ohjaimiin jne.
- Epätavalliset yhteysyritykset: Monet organisaatiot käyttävät tiedostopalvelimen julkista jakoa auttaakseen käyttäjiään jakamaan tiedostoja keskenään ja käyttävät verkkokäyttöisiä tulostimia, jotta käyttäjät voivat tulostaa suoraan tietokoneistaan. Tämä tarkoittaa, että asiakastietokoneet eivät saisi muodostaa yhteyksiä toisiinsa, vaikka olisit (viisaasti) päättänyt estää tällaisen pääsyn palomuurissa tai kytkimessä, pelkkä yritys muodostaa yhteys yhdeltä asiakastietokoneelta toiselle asiakastietokoneelle pitäisi herättää hälytyksen ja tutkia perusteellisesti.
- Epätavalliset portit: Jotkin organisaatiot käyttävät erityistä kirjastoa palveluiden välisen viestinnän optimointiin niin, että kaikki palvelimien välinen HTTP-viestintä käyttää eri porttia kuin yleiset portit (kuten 80, 443, 8080 jne.). Tässä tapauksessa on hyvä luoda sääntö, joka laukeaa, jos viestintä tapahtuu näillä tavallisesti yleisillä porteilla.
- Honeytokenit – Internetin kaltaisella taistelukentällä, jossa jokainen voi olla melkein kuka tahansa, harhauttaminen, toimii puolustajille yhtä hyvin kuin hyökkääjillekin, ellei jopa paremmin. Kikkoja, kuten sisäänrakennetun ylläpitäjätilin nimeäminen uudelleen eri, vähemmän houkuttelevaksi nimeksi ja uuden tilin luominen nimellä Administrator, jota et koskaan käytä, ja Snortin säännön luominen sen havaitsemiseksi, jos tätä käyttäjänimeä, sähköpostia tai salasanaa käytetään koskaan verkossa. Hyökkääjien olisi lähes mahdotonta huomata, että Snort on havainnut heidän yrityksensä käyttää väärennettyä järjestelmänvalvojan käyttäjätiliä. Toinen esimerkki on luoda tietokantaan valetuotteita, -asiakkaita, -käyttäjiä ja -luottokorttitietueita ja sitten sovittaa yhteen Snort-säännöt niiden havaitsemiseksi verkkoliikenteessä.
Toivomme, että näistä tiedoista oli apua. Jos haluat lisätietoja Coralogix STA:sta, tutustu uusimpiin ominaisuuksiin, jotka olemme hiljattain julkaisseet.