Parliamo di signature analysis (devo recuperare la prima parte perché sono entrato dopo e non ho capito l’introduzione della signature analysis). La signature potrebbe non essere specifica di un determinato attacco, quindi potremmo trovarla anche all’interno di messaggi normali. Dobbiamo pensare a fare delle firme che rappresentino la natura dell’attacco che altrimenti non potrebbe essere replicabile in situazioni normali. Potrebbe essere la firma del malware o qualcosa di simile.
Questione di attacchi zero day: attacchi che sono nuovissimi, questi non sono mai conosciuti e non ci sono signature sopra e questo attacco non lo posso andare a rilevare: falso negativo 100%
Posso anche andare a fare analisi dei pacchetti, l’unico problema è che l’attaccante potrebbe avere controllo di forgiare pacchetti specifici. La firma però potrebbe essere spezzata su due pacchetti diversi. Se l’approccio è stateless analisi di pacchetti è veramente facile da evitare. Dobbiamo andare a lavorare in modalità stateful. Devo andare a ricostruire la connessione tcp, devo rifare tutto lo stream di dati da client a server e da server a client. Ogni volta che arriva un pacchetto lo aggiungo e poi facico analisi su tutto quanto lo stream.
se ho tanti client che lavorano contemporaneamente è un casino, soprattutto se ho flussi udp. Ovviamente tutto questo non è praticabile e si usa un trucco: ri assemblo i dati fino a 10kb, tanto le mie firme saranno un centinaio di bytes, massimo un migliaio al massimo. Però anche qua abbiamo un problema. quando ho ri asseblato 10kb, se l’attaccante sa questa cosa, lui fa in modo che la firma eluda questo sistema di analisi. Non sono approcci perfetti, stiamo solamente cercando di rendere la vita difficile all’attaccante. Si cerca di lavorare per dimensioni di finestre random, così da non dare informazioni di alcun tipo all’attaccante.
L’incompletezza dei possibili attacchi ha portato enfasi ai sistemi basati su rilevazione di anomalie: non abbiamo più nemmeno intrusion detection, ma in questo caso stiamo cercando di andare a studiare anomalie. Sto cercando comportamenti peculiari. L’assunzione è che se ricevo un attacco anche se quello non lo conosco per diversi motivi, se l’attacco causa una deviazione rispetto al comportamento normale io con il sistema di anoally detection sono in grado di andare a rilevare l’attacco. Non sono sol gli attacchi a gneerare anomalie, ma qualsiasi cosa può andare a generare anomali (non attacchi) → fattori esterni, malfunzionamenti, user input strambi, modifiche al sistema, … Dovrei andare a definire una baseline della normalità e poi andare a definire che cosa potrebbe essere strano o no. Mi posso far io delle metriche medie che vadano a rappresentare l’attività normale del computer.
Alla fine della fiera di troviamo con un classificatore che mi può andare a rilevare una anomalia, ma in questo caso che cosa dobbiamo fare? come facciamo ad essere sicuri che sia un attacco, come lo confiniamo? Che si fa?? Generano allarmi tendenzialmente tanto generici, non è detto che siano actionable in alcun modo. Poi abbiamo il problema di falsi negativi e positivi che è ancora peggio dei sistemi basati su signatures. Qua vuol dire che un qualunque attacco che non causi uno scostamento sufficientemente alto dal sistema di sensing di anomalie mi da falsi negativi.
Abbiamo anche sistemi di self-learning che praticamente possono usare dei modelli che vanno a descrivere comportamenti normali del computer, tutto auto training e figate annesse e connesse. Solitamente però conviene andare a comprare modelli pre allenati per risparmiare tempo, il problema è che il training spesso vengono fatti su modelli diversi dal mio e quindi non ho una buona trasferibiltià → avrò falsi positivi e negativi. In realtà i sistemi di anomali detection e vengono usati, ma non sono delle black box che si usano così.
un’idea potrebbe essere una specializzazione di anomaly detection basata su modelli dello stack tcp/ip ottenuto partendo da specifiche rfc. Questo però non basta è sempre bene usare modelli di intrusion detection basati su signatures.
stateless → analizzo un pacchetto alla volta praticamente.
passive analysis →
active analysis → sono un host intrusion detection system, posso andare a stoppare processi, disinfettare files, eliminarli, … posso andare anche a chiudere connessioni con dati che hanno una firma interessante, così fermiamo un attacco e i dati non saranno mai processati dal sistema vulnerabile. Posso anche avere firewall con regole dinamiche. Posso anche andare a creare delle regole di routing che mi permetto di andare a gestire traffico con determinate regole di routing. Posso andare a eseguire script arbitrari, o reazioni complicate, che però estendono la finestra temporale sulla quale io vado a fare la mia reazione! Se ci metto troppo tempo capace che l’attacco va a buon fine!
se pensiamo ad inserire dei NIDS dobbiamo pensare a dove inserirli all’interno della rete e che tipo di allarmi andare a configurare, in termini anche di interfaccia che andiamo ad usare. Ho un problema sul traffico cifrato, perché se faccio analisi su una porta mirror e questo sito contiene ha malware, ma uso https, ho un tunnel tls da server a client e questo sistema di intrusion detection vede il pacchetto cifrato. Posso salvarmi se so che il sito che si presenta al client è malevole, ma lo devo sapere a priori se no sti cazzi.
Firewall è filtering attivo, fail-close, il pacchetto che passa è quello che voleva entrare. NIDS (network intrusion detection system) praticamente fa una copia dei pacchetti quindi è un casino in realtà, perché non lavora attivamente su pacchetti che entrano, ma fa una copia e poi analizza. E’ un filtering passivo e fail-open. La cosa interessante è che se muore il nids la connettività della rete funziona ancora, non smetto di funzionare. Potrebbe anche andare in bottleneck e iniziare a perdere pacchetti molto facilmente.
Posso andare a definire un firewall con delle signatures per renderlo più efficace, va configurato per essere in modalità fail-close e staco la mia rete da internet con nids o se ho problemi di dimensionamento, o se genero tanti falsi positivi.
Per questo motivo capita che si compri sistemi di nids ma poi si decida di fare solo detection e non prevention per non avere alcun tipo di degradazione delle prestazioni. Come faccio un deployment?
Se siamo in modalità nips, ho la prevention e in questo caso agiscono direttamente sui pacchetti veri fermandosi e poi generato un allarme.
Non abbiamo solamente host o server intrusion detection system classici ma abbiamo anche sistemi distribuiti per fare detection di intrusions.
un attaccante potrebbe iniziare a fare dei trucchi per il quale il nids o nips vedano dei pacchetti che alla fine siano leggermente diversi rispetto alle cose che vede il client alla fine. L’idea è che il sistema operativo della macchina target ricostruisce il flusso, il nids/nips non lo fa soprattutto se è stateless. se è stateful dipende, dovrò andare a sprecare tempo di cpu per andare a fare ordine e l’attaccante può comunque pacchetti che vedono solo da nids or nips e non arrivano mai a destinazione. Di solito una cosa che si fa e i pacchetti con checksum sbagliato sono scartati a priori dal so del client, ma dallo switch invece sono letti e non fa nulla praticamente. Questo permette al monitor di non vedere mai la firma ma il client si becca in faccia l’attacco.