ISLAB HACK: Βασικές Έννοιες και Προγραμματισμός του Snort 2.0

Transcript

1 ISLAB HACK: Βασικές Έννοιες και Προγραμματισμός του Snort 2.0 Αθήνα

2 Περιεχόμενα 2

3 3

4 Κεφάλαιο 1 Snort Γενικά Με τα NIDS καθίσταται δυνατό να μπορεί να ειδοποιηθεί ο διαχειριστής του δικτύου για τέτοιου είδους επιθέσεις αλλά και να εμποδίζει αυτές τις επιθέσεις, αν το επιθυμεί, κόβοντας τα ύποπτα πακέτα πριν φτάσουν στον προορισμό τους και πετύχουν τον σκοπό τους. Σε αυτό το κεφάλαιο θα περιγραφεί το Snort2.0 πού είναι ένα από τα πλέων γνωστότερα open source NIDS. Συγκεκριμένα θα περιγραφεί η αρχή λειτουργίας του και οι μεθόδους που κάνει εντοπισμό. Ακόμα θα περιγραφεί ένα μέρος του μηχανισμού σε επίπεδο development ώστε να εξηγηθεί το πώς μπορεί κάποιος να φτιάξει ένα preprocessor σαν plug-in του snort. Σε όλο το κεφάλαιο θα τονίζονται βασικές διαφορές με το snort O στόχος αυτού του κεφαλαίου είναι αφενός να βοηθήσει τον αναγνώστη να καταλάβει το επόμενο κεφάλαιο αφετέρου να δώσεί συνοπτικά μια συνολική εικόνα για το Snort2.0 ώστε να μπορεί κάποιος που θέλει να ασχοληθεί με αυτό να χρησιμοποιήσει αυτό το κείμενο σαν κείμενο αναφοράς. 2.2 Γενική περιγραφή του Snort2.0 Το Snort είναι ένα Open Source και lightweight NIDS που μέχρι την έκδοση το χρησιμοποιούσαν σε δίκτυα μικρού σχετικά μεγέθους και με μικρό σχετικά bandwidth μέχρι 100Mbps. Όμως από την έκδοση 2.0 και μετά άλλαξε ριζικά ο μηχανισμός εντοπισμού (Detection engine) με την νέα Hi-performance Multi-Rule Inspection engine και έτσι το snort μπορεί να χρησιμοποιηθεί και σε δίκτυα με Gigabit Bandwidth.Ο δημιουργός του είναι ο Martin Roesch και ο κώδικας του είναι γραμμένος σε C. Το Snort εκτός από την λειτουργία του σαν NIDS μπορεί να δουλέψει και σαν ένας απλός sniffer ή σαν ένας sniffer που καταγράφει(logging) τα πακέτα που λαμβάνει σε log αρχεία σε μορφή απλού κειμένου ASCII. Έχει λοιπόν τρία mode λειτουργίας που περιγράφονται παρακάτω είναι : 1. Sniffer mode. 2. Packet logger mode. 3. NIDS mode Sniffer Mode Σε αυτό το mode λειτουργίας το Snort έχει την ικανότητα να διαβάζει τα πακέτα που περνάνε από το δίκτυο, να τα αποκωδικοποιεί και να τα εμφανίζει στην οθόνη σε φιλική προς τον χρήστη μορφή. Ο χρήστης με διάφορα BPF (Berkley Packet Filter) φίλτρα που μπορεί να χρησιμοποιήσει, έχει την δυνατότητα να ορίσει το είδος των πακέτων που θα εμφανίζονται όσο αναφορά το πρωτόκολλο, τον αποστολέα, τον παραλήπτη και διάφορα άλλα χαρακτηριστικά ενός πακέτου. Για παράδειγμα αν ο χρήστης γράψει την λέξη κλειδί icmp στο snort τότε αυτό θα δείχνει μόνο τα πακέτα που είναι τύπου ICMP. Η λειτουργία αυτή του Snort είναι παρόμοια με αυτή του γνωστού εργαλείου tcpdump, το οποίο διατίθεται κυρίως με τα περισσότερα λειτουργικά συστήματα της οικογένειας του Unix Packet Logger Mode Σε αυτό το mode λειτουργίας το Snort αποθηκεύει στο δίσκο τα πακέτα που διαβάζει από το δίκτυο, αντί απλά να τα εμφανίζει στην οθόνη. Η διαδικασία αυτή είναι αρκετά σημαντική στην περίπτωση που απαιτείται τα πακέτα αυτά να εξεταστούν με λεπτομέρεια σε επόμενο στάδιο. Το Snort μπορεί να αποθηκεύσει τα πακέτα αυτά σε διάφορα formats, ανάλογα με τις ανάγκες του χρήστη. Για παράδειγμα μπορεί να αποθηκεύσει τα πακέτα σε binary μορφή (tcpdump format), με την οποία μπορούν να χρησιμοποιηθούν σαν είσοδο σε διάφορα άλλα προγράμματα ανάλυσης πακέτων και πρωτοκόλλων, σε ASCII μορφή ώστε να είναι δυνατή η ανάγνωσή τους, σε XML μορφή ή και να οργανωθούν σε βάσεις δεδομένων. 4

5 Είναι σημαντικό να σημειωθεί εδώ ότι αυτό το mode μπορεί να λειτουργεί παράλληλα με το sniffer mode ή το NIDS mode και δεν λειτουργεί υποχρεωτικά ανεξάρτητα από τα αλλά mode NIDS Mode Αυτή είναι η κύρια λειτουργία του Snort. Όπως αναφέρθηκε προηγουμένως, το Snort είναι ένα IDS το οποίο ενεργεί σε επίπεδο δικτύου, δηλαδή τα γεγονότα που παρακολουθεί και εξετάζει για την εμφάνιση μίας πιθανής επίθεσης, αφορούν την δραστηριότητα που παρατηρείται σε ένα δίκτυο. Το Snort έχει την ικανότητα να ανιχνεύει ένα μεγάλο φάσμα από γνωστές δικτυακές επιθέσεις, όπως portscans, buffer overflows, OS fingerprints και πολλά άλλα. Η τεχνική που χρησιμοποιεί το Snort για την διαδικασία αυτή είναι κατά κύριο λόγο η Misuse Detection με την χρήση των Signatures ενός βλαβερού(malicious) πακέτου. To snort όμως ειδικά μετά την έκδοση 2.0 συνδυάζει στην λειτουργία της ανάλυσης των γεγονότων για την ανίχνευση πιθανών επιθέσεων και κάποιες από τις μεθόδους του Protocol Anomaly Detection και του Anomaly Detection. Οι μηχανισμοί αυτοί υλοποιούνται κατά κύριο λόγο από τους preprocessors που εξηγούνται αναλυτικά παρακάτω αλλά και από το νέο μηχανισμό του snort 2.0 να συντάσσει τα rules σε κατηγορίες Snort Rules Τα Rules Snort ονομάζονται είναι κανόνες οι οποίοι περιγράφουν τα χαρακτηριστικά ενός πακέτου που μπορεί να είναι μέρος μίας γνωστής επίθεσης. Κάθε ένα από τα Rules ουσιαστικά περιγράφει το snort ποία είναι η «εικόνα» του βλαβερού(malicious) πακέτου και επίσης πώς πρέπει να αντιδράει όταν συνετίσει αυτό το signature σε κάποια πακέτα. Μέρος του μηχανισμού της αντίδρασής είναι και η προτεραιότητα που μπορεί να περιγραφεί μέσα σε ένα rule του snort. Η προτεραιότητα όπως θα φανεί παρακάτω στην περιγραφή του μηχανισμού του snort έχει ιδιαίτερη σημασία ειδικά για το snort 2.0. NOTE Τα rules και τα signatures είναι ισοδύναμα σαν έννοιες και συνήθως χρησιμοποιούνται σαν συνώνυμες λέξεις. Οι διαφορές τους είναι οι εξής: Signatures είναι τα ειδικά χαρακτηρίστηκα του πακέτου που το χαρακτηρίζουν σαν ύποπτο ή βλαβερό(malicious). Τα χαρακτηριστικά αυτά είναι στο payload ή το header του πακέτου και είναι patterns από strings που χαρακτηρίζονται σαν υπογραφή (Signature) ενός «κακού» πακέτου. Γενικά η περιγραφή ενός πακέτου που είναι malicious όταν γίνεται με ένα signature είναι στατική. Δηλαδή ένα signature περιγράφει ένα υπαρκτό χαρακτηριστικό (positive pattern much) στο payload και μερικά χαρακτηριστικά στο header του πακέτου. Rules είναι κανόνες οι οποίοι περιγράφουν στο snort ή άλλο IDS τα χαρακτηριστικά ενός πακέτου που μπορεί να είναι μέρος μίας γνωστής επίθεσης καθώς και την ενέργεια που θα εκτελεστεί κατά τον εντοπισμό του. Η περιγραφή ενός πακέτου με ένα rule είναι αρκετά ποίο δυναμική. Αφενός σε ένα rule μπορεί να περιγράφονται περισσότερα του ενός υπαρκτά χαρακτηριστικά στο payload αφετέρου μπορούν να περιγράφονται χαρακτηριστικά που δεν πρέπει να έχει ένα πακέτο για να θεωρηθεί ύποπτο. Τέλος ένα rule μπορεί να περιγράφει ένα ολόκληρο steam και όχι ένα πακέτο μόνο για τις περιπτώσεις που γίνεται statefull intrusion detection. Τα Rules του Snort μπορούν να γραφτούν σε απλή περιγραφική γλώσσα σε ASCII μορφή και κάθε ένα από αυτά αποτελείται από δύο λογικά μέρη, τον Rule Header και τα Rule Options. 5

6 Στο Σχήμα που ακολουθεί περιγράφεται ένα Rule. Rule Header Rule Options log tcp /24 any-> /32 80 (flags:sf;msg: SYN-FIN Scan ;) Protocol Source ΙP Source Port Destination Port Destination IP Option Option Separator Keyword Option Argument Action Σχήμα 2.1 O Rule Header περιέχει τις εξής πληροφορίες: Action: Είναι η ενέργεια που θα εκτελέσει το Snort όταν ταιριάξει κάποιο πακέτο με ένα Rule. H ενέργεια αυτή έχει να κάνει με την αντίδραση (Response) του Snort κατά την ανίχνευση μίας πιθανής επίθεσης.το Action μπορεί να είναι : o Alert, το οποίο θα δημιουργήσει ένα alert για το γεγονός που εντόπισε και στη συνέχεια θα καταγράψει το πακέτο. Τα alerts είναι ο τρόπος με τον οποίο το Snort επισημαίνει τo γεγονός της ανίχνευσης μίας επίθεσης και θα παρουσιαστούν παρακάτω. o Log, το οποίο θα καταγράψει το πακέτο στον δίσκο. o Pass, το οποίο θα αγνοήσει το πακέτο. o Activate, το οποίο θα προκαλέσει ένα alert και στη συνέχεια θα ενεργοποιήσει ένα dynamic Rule. o Dynamic, το οποίο θα περιμένει μέχρι να ενεργοποιηθεί από ένα activate Rule και στη συνέχεια θα ενεργήσει σαν ένα log Rule. Ο χρήστης έχει την δυνατότητα να ορίσει και δικούς του τύπους από Actions. Protocol: Είναι το είδος του πρωτοκόλλου στο οποίο ανήκει το πακέτο που θα εξεταστεί. To πρωτόκολλο μπορεί να είναι ip, tcp, icmp, udp. Source IP: Είναι η IP διεύθυνση αποστολέα που βρίσκεται στον IP header του πακέτου, σε συνδυασμό με την μάσκα του δικτύου (netmask) στο οποίο μπορεί να ανήκει, εκφρασμένη με CIDR τρόπο γραφής. Με τoν CIDR τρόπο γραφής γίνεται δυνατό να ορισθεί μία ομάδα (block) από συνεχείς IP διευθύνσεις. Source Port: Είναι η πόρτα αποστολής που έχει νόημα στα tcp και udp πακέτα. Στο συγκεκριμένο παράδειγμα με το λεκτικό any εννοείται οποιαδήποτε πόρτα. Destination IP: Είναι η IP διεύθυνση του παραλήπτη του πακέτου. O τρόπος γραφής της είναι ο ίδιος με αυτόν που ισχύει για την Source IP και στο συγκεκριμένο παράδειγμα η IP διεύθυνση του παραλήπτη με την netmask που έχει ορισθεί, αντιπροσωπεύει έναν μόνο αριθμό τον Destination Port: Είναι η πόρτα προορισμού του πακέτου. Τα Rule Options περιέχουν πληροφορία που αναφέρεται στα χαρακτηριστικά για τα οποία θα ελεγχθεί το πακέτο. Επίσης στα Rule Options μπορούν να ορισθούν και κάποιες επιπρόσθετες ενέργειες που θα εκτελεστούν για κάποιο πακέτο που θα ταιριάξει με το Rule. Το κάθε option που περιέχεται στο Rule Options τμήμα του Rule, αποτελείται από τα Option Keyword και τα Option Arguments. Option Keyword: Είναι το λεκτικό που υποδηλώνει το όνομα-είδος του option. Το λεκτικό από την έκδοση snort 2.0 και μετά έχει την δυνατότητα να εκφραστεί σαν Regular Expression του UNIX. Αυτό δύνη την δυνατότητα να περιγραφούν τα rules με μία γενική μορφή ώστε να μπορούν να περιγράψουν γενικές επιπτώσεις επιθέσεων όπως το Buffer Overflow. Για παράδειγμα στην τελευταία περίπτωση μπορεί να περιγράφει ένα rule με τέτοια μορφή ώστε για παράδειγμα όταν συναντάτε ένας 6

7 μεγάλος αριθμός από NOPs σε ένα πακέτο αυτό να θεωρείται σαν ύποπτο για buffer overflow exploit. Έτσι δίνεται η δυνατότητα να εκφραστεί μέσα από ένα rule ένα Anomaly based τρόπος ανάλυσης ενός πακέτου ή stream. Παραίτηση: Ειδικά για την περίπτωση του Buffer Overflow παραμένει αρκετά δύσκολο να εντοπιστεί το Buffer Overflow με αυτό τον τρόπο αλλά είναι μία πόλη χρήσιμοι δυνατότητα για να πιάνονται όλες οι παραλλαγές ενός είδη γνωστού Buffer Overflow Exploit. H δυσκολία είναι ότι ένα τέτοιο είδος rule βασίζεται πάντα στο sledge και όχι στα αποτελέσματα του στο πακέτο ή στο stream. Στο τελευταίο βασίζεται ο Abstract Execution αλγόριθμος που περιγράφεται σε προηγούμενο κεφάλαιο και είναι τι κύριο αντικείμενο αυτής της πτυχιακής. Option Argument: Είναι οι παράμετροι που δέχεται το option σε σχέση με τις οποίες θα ελεγχθεί το πακέτο. Τα Option Arguments για κάθε option, πρέπει να διαχωρίζονται με τον χαρακτήρα : από το αντίστοιχο Option Keyword. Option Separator: Είναι ο χαρακτήρας διαχωρισμού ; μεταξύ δύο options. Το συγκεκριμένο Rule έχει δύο options. Το πρώτο είναι το option με το όνομα flags, το οποίο υποδηλώνει ότι θα ελεγχθούν τα flags του TCP header του πακέτου. Τα arguments αυτού του option είναι τα SF, το οποίο δηλώνει ότι θα ελεγχθεί αν ο TCP header του πακέτου έχει ενεργοποιημένα τα flags Syn και Fin. Το δεύτερο option έχει το όνομα msg, το οποίο δηλώνει ότι αν ταιριάξει κάποιο πακέτο με αυτό το Rule, τότε μαζί με το alert (ή το πακέτο που θα καταγραφεί) θα τυπωθεί και κάποιο μήνυμα, το οποίο είναι αυτό που ακολουθεί μέσα στα και το οποίο αποτελεί το Option Argument αυτού του option. Το Snort διανέμεται με πάνω από 2500 έτοιμα Rules, για χρήση τους στην ανίχνευση γνωστών επιθέσεων, ενώ για την δημιουργία νέων Rules προσφέρει μία μεγάλη γκάμα από options που μπορεί ο χρήστης να χρησιμοποιήσει, τα οποία του δίνουν την ευελιξία να εκτελεί λεπτομερής και σε βάθος περιγραφή των χαρακτηριστικών του κάθε πακέτου, για το οποίο θέλει να γίνει έλεγχος για τον εντοπισμό μίας επίθεσης. Τα Rules χωρίζονται σε δύο κατηγορίες στα Generic Rules και στα Unique Rules. Αυτά ορίζονται αυτόματος από το snort αναλόγως με της πληροφορίες που φέρει το header του Rule. Generic είναι τα Rules που στο ορισμό τον IP δικτύων ή πόρτων έχουν την λέξη κλειδί any. Αυτό σημαίνει ότι το rule είναι έτσι ορισμένο ώστε να ελέγχει οποιοδήποτε πακέτο που έχει Signature στο payload του αυτό που περιγράφεται στα options του rule. Unique Rules είναι αυτά που έχουν συγκεκριμένο range δικτύων και πόρτες που εξετάζουν. Σημείωση: Τα Unique και τα Generic Rules έχουν ιδιαίτερη σημασία για το πώς ο Rule Optimizer που θα δούμε παρακάτω, θα φτιάξει τις ομάδες των Rules και τι στρατηγική Anti- DoS εφαρμόζει όταν οργανώνει αυτά τα Rules στης ομάδες τους. 2.3 H Μηχανή του snort2.0 Σε αυτή την παράγραφο που θα περιγραφεί η ο μηχανισμός του snort θα αναφερόμαστε στο NIDS mode που κατά κάποιο τρόπο είναι ο συνδυασμός και των τριών mode λειτουργίας. Το Snort αποτελείται από τέσσερα υποσυστήματα λειτουργίας. Κάθε πακέτο που επεξεργάζεται το Snort, θα περάσει από κάθε ένα από αυτά τα υποσυστήματα : Packets capturing και decoding engine. Rules parsing και detection engine που αντικαταστάθηκε με την Hi-performance Multi- Rule Inspection engine. Logging ή Output engine. Detection plugins, Output plugins and Preprocessors handling engine. 7

8 2.3.1 Packets capturing και decoding engine Η δουλεία της Packet capturing και decode Engine ξεκινάει με το διάβασμα (sniffing) των πακέτων από το δίκτυο με την χρήση της βιβλιοθήκης libpcap, η οποία δίνει την δυνατότητα της μεταφοράς των πακέτων από επίπεδο πυρήνα του συστήματος σε επίπεδο χρήστη, από όπου θα μπορέσει το Snort να τα επεξεργαστεί. Το πώς λειτουργεί Packets capturing και decoding engine φαίνεται στο σχήμα. Σχήμα 2.2 Για να μπορέσει να γίνει αυτό η capture engine τίθεται η συνάρτηση σε ένα ατελείωτο βρόχο (Endless Loop). Έτσι κάθε πακέτο που φτάνει στο δίκτυο το πιάνει και το δίνει στην decode engine. Στην συνέχει επιλέγεται τι είδους πακέτο είναι με βάση το δεύτερο επίπεδο του OSI (OSI layer2) και από εκεί καλείται η κατάλληλη συνάρτηση που θα κάνει την πρώτη αποκωδικοποίηση του πακέτου για παράδειγμα αν είναι Ethernet framework τότε θα κληθεί η κατάλληλη συνάρτηση για Ethernet decoding. H διαδικασία αυτή συνεχίζεται για κάθε επίπεδο του OSI μέχρι το πακέτο να αποκωδικοποιηθεί πλήρως. Μέχρι σήμερα στη έκδοση 2.0 τα πρωτόκολλα που έχει την δυνατότητα να αποκωδικοποιεί είναι : ICMP, TCP, UDP για το layer 4. IPv6 μόνο από την έκδοση 2.0 και μετά, IP, ARP για το layer 3. Ethernet, FDDI, T/R, SLIP, PPP, ISDN, Raw για το layer 2. Τα αποτελέσματα της αποκωδικοποίησης για κάθε πακέτο δομούνται σε μία δομή την struct _Packet και στην συνέχεια προωθούνται στην Detection Engine. H Packet εκτός από τις αποκωδικοποιημένες πληροφορίες όπως το IP header μπορεί να δείχνει και σε πηγαία πληροφορία του πραγματικού πακέτου όπως original IP header όπως αυτό γίνεται capture από την capture engine. Στην συνέχεια η Packet δίνεται στην Rules parsing και detection engine. 8

9 Όταν τελειώσει η αποκωδικοποίηση το πακέτο γίνεται Logged όταν έχει ενεργοποιηθεί από τον χρήστη αυτός ο μηχανισμός ανεξάρτητα από το αν θα γίνει ενεργοποιηθεί η detection engine η όχι. DEVELOPERS NOTE Το Decode Engine του Snort υλοποιείται σχεδόν αποκλειστικά στο αρχείο decode.c, το οποίο περιέχει συναρτήσεις που εξάγουν την απαιτούμενη πληροφορία για το κάθε πακέτο, ξεκινώντας από τα πρωτόκολλα του Data Link Layer του OSI ανεβαίνοντας μέχρι και τα πρωτόκολλα του Application Layer. Για κάθε πρωτόκολλο υπάρχει και η αντίστοιχη συνάρτηση που θα ενεργήσει στο πακέτο. Παραδείγματα τέτοιων συναρτήσεων είναι DecodeEthPacket(), DecodePppPacket(), DecodeFDDIPacket(). Η struct _Packet βρίσκεται στο αρχείο decode.h. DEVELOPERS NOTE Η Pcap_loop() είναι η συνάρτηση που διαβάζει τα δεδομένα από το δίκτυο και τα δίνει στη detection engine. Αποτελεί κατά κάποιο τρόπο την capture engine του snort. H ProcessPacket() είναι η συνάρτηση που επιλέγει για το τι είδους πακέτο είναι το πακέτο που λαμβάνει από την Pcap_loop() και καλεί τις κατάλληλες συναρτήσεις ώστε να μπορέσει να από κωδικοποιήσει το πακέτο Rules parsing και detection engine που αντικαταστάθηκε με την Hiperformance Multi-Rule Inspection engine. Ο σκοπός αυτής την engine είναι να διαβάσεί τα rules που έχουν οριστεί από τον διαχειριστή του δικτύου και να ελέγξει το payload του κάθε IP πακέτου ή TCP stream της κάθε TCP connection αν έχουν signatures ίδια με αυτά που περιγράφονται από τα rules και να αντιδράσει κατάλληλα. Η rules parsing engine ενεργοποιείται κατά την εκκίνηση του Snort. Αφού ελέχθη αν θα εκτελεστεί σαν daemon ή σαν μια απλή εφαρμογή το Snort θα ελέγξει ο διαχειριστής του δικτύου ενεργοποίησε το NIDS mode έχοντας απλά δώσει παραμετρικά ένα αρχείο με ένα σύνολο από Rules. Στην συνέχεια διαβάζει τα Rules και τα βάζει σε μία κατάλληλη δομή από λίστες στην μνήμη ώστε να μπορεί να ελέγχει κάθε πακέτο που διαβάζει(sniffs). O μηχανισμός αυτό φαίνεται στο παρακάτω σχήμα. 9

10 Σχήμα 2.3 DEVELOPERS NOTE Το Detection Engine του Snort υλοποιείται στο αρχείο rules.c. ParseRulesFile() θα διαβάσει τα Rules από το κάθε αρχείο που παίρνει σαν παράμετρο. Στην ουσία η συνάρτηση αυτή θα διαβάσει το αρχείο γραμμή προς γραμμή, θα απαλείψει τα σχόλια και τα κενά που μπορεί να υπάρχουν και για κάθε Rule που θα εντοπίσει θα καλέσει την συνάρτηση ParseRule(). Από την έκδοση του snort 2.0 εγκαινιάστηκε για πρώτη φορά δύο νέοι μηχανισμοί. Ο πρώτος είναι ο Rule Optimizer και ο δεύτερος είναι η Multi-rule Inspection engine ουσιαστικά είναι η νέα Detection Engine του snort. Ο συνδυασμός αυτών των δύο μηχανισμών με τον Protocol Flow Analyzer που είναι μέρος της νέας detection engine, δίνουν την δυνατότητα στο snort να παρακολουθεί δίκτυα με μεγάλο bandwidth αλλά και με σχετικά μεγάλη πολυπλοκότητα. Συγκριτικό διάγραμμα των επιδόσεων του snort2.0 σε σχέση με το snort1.9.1 θα παρουσιαστή παρακάτω. 2.4 Rule Optimizer O Rule Optimizer δουλεύει σε δύο φάσης. Η μία φάση λειτουργίας του είναι άμεσος μετά από τον Rule Parser που εξηγήθηκε παραπάνω ενώ η δεύτερη φάση είναι ακριβώς πριν να δοθεί ένα πακέτο προς εξέταση(inspection) στην νέα Multi-rule Inspection engine. Στην πρώτη περίπτωση ο σκοπός του Optimizer είναι αν δομήσει τα rules με τέτοιο τρόπο ώστε να στην συνέχεια η Inspection engine να ελέγχει το πακέτο μόνο μία φορά. Για να το καταφέρει αυτό φτιάχνει μία νέα δομή που λέγεται rule-set. Η δομή αυτή είναι έτσι οργανωμένη ώστε να ομαδοποιεί τα rules με τέτοιο τρόπο ώστε αν ένα πακέτο δεν ταιριάζει με την ομάδα να προωθείται σε επόμενη ομάδα. Η ιδέα δεν διαφέρει και πολύ από την αρχική ιδέα που υπήρχε μέχρι την έκδοση αυτό όμως που αλλάζει ριζικά είναι οι παράγοντες που γίνεται η επιλογή των rules για να φτιαχτούν τα σύνολα(rule-sets). Οι παράγοντες που αποτελούν τα κριτήρια επιλογής για να διαχωριστούν τα rules και να δημιουργηθούν τα rule-sets εξαρτώνται από τον μηχανισμό που κάνει εξέταση(inspection). Με απλά λόγια οι δομές που θα παραχθούν πρέπει να είναι τέτοιες ώστε να βοηθούν την ταχύτερη και πιο αποδοτική λειτουργία του αλγορίθμου μου θα εκτελεστεί για να κάνει την εξέταση και να πάρει την απόφαση αν ένα πακέτο είναι βλαβερό ή όχι. Παρακάτω 10

11 περιγράφεται ο τρόπος που παράγονται οι δομές αυτές σε σχέση με τον τρόπο της έκδοσης και τον δομών που παράγονταν από αυτό Standard Snort Rule Processing vs. Rule Optimization Στην έκδοση το Snort εξέταζε τα πακέτα που διάβασε(sniffs) από το δίκτυο εκτελώντας ένα παραμετροποιημένο έλεγχο(parameterized search) όλων τον rule όπου οι παράμετροι της αναζήτησης ήταν το rule Options. Για να επιταχύνεται ο τερματισμός μιας αποτυχημένης αναζήτησης το snort είχε μερικές τρισδιάστατες λίστες όπου κάθε μία αντιστοιχούσε σε ένα από τα γνωστά πρωτοκόλλα όπως TCP,UDP,ICMP,IP. Στην καλύτερη υλοποίηση αυτής της ιδέας στην έκδοση ο αλγόριθμος απαιτούσε στην πρώτη διάσταση που ήταν τα rule headers και στην δεύτερη διάσταση που ήταν το rule options να είναι έτσι τοποθετημένα τα rules σε κάθε λίστα ώστε να μπορεί να σταματάει το δυνατόν συντομότερα ένα αποτυχημένο ταίριασμα. Οι παράγοντες που επηρέαζαν την δόμηση κάθε λίστας ήταν : 1. Source IP 2. Destination IP 3. Source Port range 4. Destination Port range Με αυτό τον τρόπο υπήρχαν ομαδοποιήσεις μασάς στις λίστες τέτοιες ώστε αν ταίριαζαν και οι τέσσερις παραπάνω παράγοντες ενός πακέτου με την ομάδα των rule τότε και μόνο τότε προχωρούσε σε περαιτέρω έλεγχο. Αυτός ο μηχανισμός ήταν ιδιαίτερα γρήγορος όταν οι ομάδες ήταν λίγες η ροή τον πακέτων ήταν μικρή. Όμως σε δίκτυα με μεγάλο bandwidth υπάρχει πρόβλημα. Το πρόβλημα λύθηκε σε μεγάλο βαθμό με τον rule optimizer. Στην ουσία ο rule optimizer είναι η εφαρμογή μερικών μεθοδολογιών εξέτασης βασισμένες στης ομάδες που προαναφέραμε (set-based inspection methodologies). Ο σκοπός λοιπών του rule optimizer είναι να παράγει αυτέ του δομές(rule-sets) και κατά την διάρκεια του έλεγχου να επιλέγει με ποίο set θα γίνει η σύγκριση. Για να καταφέρει να λειτουργήσει αποτελεσματικά η Multi-rule Inspection engine πρέπει ο Rule Optimizer: 1. Να δημιουργεί της μικρότερε και αποτελεσματικότερες το δυνατών ομάδες από rules (rule-sets). 2. να δομή τις ομάδες αυτές με τέτοια τρόπο ώστε κάθε εισερχόμενο πακέτο να ελέγχεται αν είναι δυνατόν MONO με μία ομάδα από rules(rule-set). O optimizer τής δομές αυτές την παράγει κατά το initialization όπως προαναφέρεται αναλυτικά παραπάνω. Αυτό που κάνει είναι να λαμβάνει υπόψη του μοναδικούς(unique) παράγοντες για να φίτξει τα sets. Οι παράγοντες αυτοί είναι ξεχωριστοί για κάθε πρωτόκολλο γιατί κάθε ένα έχει αλλά χαρακτηριστικά που μπορούν να χρησιμοποιηθούν σαν κριτήριο για να ξεχωρίσουν οι μοναδικές ομάδες. Τα κριτήρια επιλογής για κάθε πακέτο είναι: TCP/UDP : Οι βασική παράγοντες που λαμβάνονται υπόψη σε αυτή την περίπτωση είναι η Source Port και ή Destination Port όπως και παλιά στην έκδοση Όμως σε αυτή την περίπτωση ο λόγος που χρησιμοποιούνται αυτοί οι παράγοντες είναι γιατί τα rules χωρίζονται σε source και Destination. Αυτό σημαίνει ότι δημιουργούνται sets τέτοια ώστε να μην ελέγχονται άσκοπα πακέτα με rules που αφορούν τον server όταν αυτά ελέγχονται από τον client και αντίστροφος. Αυτή η βελτίωση μαζί με την ειδική προσθήκη για το Http αποτελούν το Protocol Flow Analyzer. Με αυτό τον τρόπο η ταχύτητα εξεργασίας της ροής τον πακέτων του δικτύου από snort γίνεται μέχρι και 18 φορές ταχύτερα. ICMP : Εδώ μόνο το ICMP type είναι παράγοντας που επηρεάζει τη ομαδοποίηση των ICMP πακέτων. IP : Τα πακέτα που δεν περιέχουν άλλο πρωτοκολλώ κατηγοριοποιούνται σε generic rule IP packet. Ουσιαστικά είναι η ομάδα των πακέτων που δεν έχουν μοναδικούς (Unique) παράγοντες (για παράδειγμα TCP source port) για να ομαδοποιηθούν. 11

12 1.4.2 Αντιμετώπιση του αποτελέσματος Unique conflict που προκύπτει από τον optimizer Όπως περιγράφεται στο κεφάλαιο από τις πρώτες εκδώσεις του snort υπάρχουν δύο είδη rules τα Unique και τα Generic. Στην περίπτωση τής νέας detection engine ο optimizer θα αντιμετώπιση το πρόβλημα να επιλέξει που θα βάλει ένα Rule που περιγράφεται με τέτοιο τρόπο ώστε να έχει πάνω από ένα μοναδικούς παράγοντες που ικανοποιούν το κριτήριο της μοναδικότητας για διαφορετικές προπτώσεις. Για παράδειγμα όταν περιγράφεται συγκεκριμένα και όχι με any και Source και Destination Port. H λύση σε αυτό το πρόβλημα λύνεται με διάφορες μεθόδους αναλόγως με τη επίπεδο επιδόσεων απαιτεί ο διαχειριστής για το δικτύου του. Οι λύσεις είναι οι εξής: Αν προκύψει Defined Unique Conflict τότε θα παραχθεί ένα ξεχωριστώ rule-set που ικανοποιεί και τα δύο οι περισσότερα κριτήρια. Aν προκύψει Undefined Unique Conflict τότε υπάρχουν τρεις λύσεις: o o o Double inspection: Όπου και τα δύο κριτήρια θα ελεγχθούν στο πακέτο ξεχωριστά δηλαδή θα περάσεί από όλες τις ομάδες που το rule τοποθετήθηκες. First-Hit Inspection: Όπου γίνεται Double inspection αλλά με το πρώτο ταίριασμα σταματά ο έλεγχος. Probablistic inspection : Εδώ επιλέγεται τυχαία και ελέγχεται το πακέτο μόνο με ένα rule-set και όχι με αλλά. Ο τρόπος επιλογής είναι τυχαίος και γίνεται μόνο μία φορά. Η πρώτη από αυτές τις τρεις περιπτώσεις είναι ευάλωτη σε DoS ή Decoy επιθέσεις γιατί ένας hacker μπορεί να στέλνει πακέτα έτσι διαμορφωμένα ώστε να μπορεί να προκαλεί συνεχείς έλεγχους σε τέτοια rules. Αλλά είναι σίγουρο ότι θα πιάσει όλες τής επίθεσης. Η δεύτερη περίπτωση είναι λιγότερο ευάλωτη σε DoS επιθέσεις αλλά μπορεί ο hacker να στέλνει πακέτα που θα ικανοποιεί τις συνθήκες του πρώτου rule άρα θα ελεηθεί με το set αυτού αλλά ο στόχος τους θα είναι να εκτελέσουν ένα exploit που περιγράφεται στο δεύτερο rule άρα το exploit δεν θα πιαστεί γιατί ο έλεγχος θα σταματήσει στο πρώτο set που δεν περιγράφεται το exploit. Με την τελευταία μέθοδο δεν υπάρχει πρόβλημα να πετύχει μια DoS επίθεση αλλά δεν μπορεί να πιαστούν όλες οι επιθέσεις. Όμως και ο hacker δεν μπορεί να ξέρει αν πότε να στείλει τη επίθεση για να μην πιαστεί Σύνοψη του Rule Optimizer Αυτό που προσφέρει ο Rule Optimizer στην νέα Detection engine του snort είναι να αυξάνεί την αποτελεσματικότητα της Multi-rule inspection engine αφού οι ελέγχει που γίνονται από τους αλγορίθμους αυτής της engine βασίζονται στις δομές που παράγει ο Optimizer. Ακόμα ο Rule Optimizer είναι αναπόσπαστο κομμάτι της συνολικής λειτουργίας του Detection engine του snort. Έτσι κάθε φορά που ελέγχεται ένα πακέτο ο Rule Optimizer είναι αυτό που θα επιλέξει με ποιο rule-set θα συγκρίνει η Multi-rule inspection engine το πακέτο. 1.5 Multi-Rule Inspection engine Ο σκοπός της λειτουργίας της Multi-rule Inspection Engine είναι να επιταχύνει την διαδικασία εξέτασης(inspection) ενός πακέτου με ένα rule-set που έχει παράγει ο Optimizer. Η detection engine του snort μέχρι την έκδοση χρησιμοποιούσε μία παραμετροποιημένη μέθοδο ελέγχου που λεγόταν Parameterized Rule Inspection. Ο μηχανισμός αυτό δεν καταργήθηκες αλλά πλέον χρησιμοποιείται μετά από τον Set Based Rule Inspection Συνδυασμός Set Based Rule Inspection και Parameterized Rule Inspection H Parameterized Rule Inspection μέθοδος ταιριάσματος των rules ήταν να ελέγχει κάθε μία παράμετρο ξεχωριστά με κάθε ένα από το κριτήρια του rule που βρίσκονται στην λίστα τριών διαστάσεων που αναφέραμε παραπάνω. Για να το κάνει αυτό χρησιμοποιούσε τις 12

13 συναρτήσεις που βρίσκονταν στην τρίτη διάσταση αυτής της λίστας. Στην συνέχεις αν έβλεπε ότι όλες οι συναρτήσεις επέστρεφαν True τότε κατέγραφε(logging) το κατάλληλο Alert. Στην συνεχεία προχώραγε στον έλεγχο όλων το επόμενων Rules που βρίσκονταν σε αυτή την ομάδα μέχρι να τελειώσει η λίστα. Αν το πακέτο ικανοποιούσε και τα κριτήρια και κάποιας άλλης από τις τρισδιάστατες λίστες τότε προχώραγε σε έλεγχο τον Rules και αυτής της ομάδας. Η Set Based Rule Inspection μέθοδος αντί να κάνει έλεγχο ένα προς ένα τα rules που βρίσκονται σε κάθε ομάδα (rule set) όπως γινόταν με την παραπάνω μέθοδο χρησιμοποιεί αλγορίθμους που κάνουν παράλληλα έλεγχο σε όλες τις παράμερους και έλεγχο πολλών Rule ταυτόχρονα για αυτό λέγεται και Multi-Rule η νέα αυτή engine. Για να το κάνει αυτό βασίζεται στις καλά δομημένες δομές rule-sets που παράγονται από τον Rule Optimizer. Εστί μεγάλες ροές πακέτων αν είναι κατάλληλα τα rule-sets θα ελέγχονται πολύ γρήγορα αφού μόνο με από αυτό θα γίνεται έλεγχο κάθε πακέτου. Έτσι το snort αποκτά μία μηχανή υψηλών επιδόσεων. Η νέα detection engine του snort2.0 εφαρμόζει πρώτα την Set Based Rule Inspection μέθοδο και συνεχίζουν στην Parameterized Rule Inspection μέθοδο σε δύο περιπτώσεις. Πρώτών όταν βρεθεί ότι κάποιο Rule από την ομάδα ταιριάζει για να επιβεβαιωθεί ότι πράγματι ταιριάζει. Όταν χρειάζεται ένας σύνθετος έλεγχος κάποιου Rule ή όταν. Έτσι για παράδειγμα ένα rule-set που αποτελείται μόνο από ένα Rule θα ελεηθεί με την παραδοσιακή μέθοδο του snort Αλγόριθμοι που χρησιμοποιούνται στην νέα Detection Engine για να υλοποιήσουν το Set Based Rule Inspection Οι αλγόριθμοι που χρησιμοποιούνται για αυτή την περιπρώσει είναι o Wu-Manber και ο Aho- Coraski για τον παράλληλο έλεγχο του rules ενός set. Ενώ για πολύ μικρά rule sets χρησιμοποιείται ο Boyer-Moore αλγόριθμος για pattern matching. Aυτός που χρησιμοποιείται από το snort2.0 είναι κύριος o πρώτος επειδή είναι αποδοτικότερος σε pattern matching μεγάλα strings και απαιτεί 2-3 φορές λιγότερη μνήμη. Ο δεύτερος χρησιμοποιείται μόνο αν υπάρχει ανάγκη που δεν καλύπτετε από τον πρώτο. Ο τελευταίως εξακολουθεί να χρησιμοποιείται όταν Parameterized Rule Inspection μέθοδος χρειάζεται να ενεργοποιηθεί. Τα κριτήρια της επιλογής του default αλγορίθμου για το snort 2.0 ήταν : 1. Έπρεπε να περιοριστεί η χρήση του Boyer-Moore αλγόριθμου γιατί έκανε τον εντοπισμό των Malicious πακέτων να έχει μεγάλο επεξεργαστικό κόστος άρα και χαμηλές επιδώσεις γιατί εξαρτιόταν όχι μόνο από τον αριθμό των εισερχόμενων πακέτων αλλά και από τον αριθμό των rules. Η απόδοση του συστήματος εξαρτάτε από τα data και από τα rules. 2. Επειδή έχει λιγότερα jump σε συνάρτηση και χρειάζεται λιγότερη μνήμη. Η απόδοση εξαρτάτε από την αρχιτεκτονική που υλοποιείται ο αλγόριθμος Κατηγορίες που χωρίζονται τα Rules και περιγραφή γενικού pattern Το snort2.0 έχει τέσσερις διαφορετικές κατηγορίες από Rules. Εδώ χρειάζεται να τονιστεί ότι οι κατηγορίες αυτές δεν είναι ορατές από τον εκάστοτε διαχειριστή δικτύου που χρησιμοποιεί το snort2.0. Ακόμα οι κατηγορίες αυτές έχουν σημασία για το πώς ο Rule Optimizer θα οργανώσει τα Rule Sets. Ακόμα ο διαχωρισμός αυτό είναι ένα ακόμα σύνολο κριτηρίων ταξινόμησης των rules και δεν αναιρεί συμπληρώνει τον διαχωρισμό των Generic και Unique. Οι τέσσερις αυτές κατηγορίες μπορούν να χωριστούν σε δύο ακόμα κατηγορίες αυτές που τα rules τους έχουν περιεχόμενο(content) και αυτές που δεν έχουν περιεχόμενο(νο Content). Οι τέσσερις αυτές κατηγορίες είναι : 1. Protocol Field Rules επιτρέπουν σε ένα Signature(Rule) να ορίζει ένα συγκεκριμένο πεδίο στο πακέτο για το οποίο ένα συγκεκριμένο string ταιριάζει. Τέτοιο rule είναι αυτό που ψάχνει να βρει τις λέξεις κλειδιά του HTTP πρωτοκόλλου όπως το GET. 13

14 2. Generic Content Rules είναι rules που περιγράφουν το ταίριασμά, μέσα στα Data (payload) του πακέτου, να βρουν σε οποιοδήποτε σημείο διάφορα string όπως για παράδειγμα root, crime, 90h90h90h κτλ. 3. Packet Anomaly Rules τα πακέτα αυτά είναι της κατηγορίας No Content δηλαδή το Rule δεν χρειάζεται να περιγράφει το περιεχόμενο του πακέτου. Αλλά ψάχνουν άλλα χαρακτηριστικά του πακέτου όμως από ποιο IP έρχονται αν έχουν κάποια Flags ενεργοποιημένα ή όχι ή άλλες πληροφορίες. 4. IP Rules αυτά τα Rules μπορεί να είναι Content ή No Content. Τα πακέτα που ελέγχονται με αυτά τα Rules είναι όλα τα πακέτα IP αλλά όχι πάντα. Αυτό εξαρτάτε πώς έχουν γίνει οι δομές (rule-sets) από τον Rule Optimizer Επιλογή του alert που θα καταγραφεί τελικά (Event Queue Processing) Τελειώνοντας η Multi-rule inspection engine κάθε rule που βρίσκει ο παράλληλος αλγόριθμος ότι ταιριάζει με το signature του πακέτου το βάζει σε μία δομή ουράς(queue). Κάθε ένα από αυτά τα ταιριάσματα ονομάζεται event(γεγονός). Κάθε ένα από αυτά τα γεγονότα θα εξεταστούν από τον παραδοσιακό αλγόριθμο του snort τον Parameterized Rule Inspection για να επιβεβαιωθεί ότι το Event ταιριάζει. Στην συνέχεια από την λίστα που θα περιέχει μόνο τα events που επιβεβαιώθηκαν(validated) ότι ταιριάζουν ένα θα επιλεχθεί με βάση τα παρακάτω κριτήρια αυτό καταγραφεί(logging). Τα κριτήρια επιλογής του Εvent είναι : Event processing order: log, alert and pass. Content events supercede anomalous events. Protocol content event such as HTTP events, supercede generic content event. Longer content length matches, if present, supercede shorter content length matches Στρατηγική αποφυγής επιθέσεων τύπου DoS του Snort2.0 Οι Multi-Pattern αλγόριθμοι του snort έχουν την δυνατότητα ταυτόχρονα βρίσκουν ποία από τα rules που ανήκουν σε μία ομάδα από αυτά(rule-set). Για να επιβεβαιωθεί όμώς ότι κάθε ένα από αυτά τα rules ταιριάζει ακριβός με το signature του πακέτου τότε θα πρέπει για το κάθε ένα να γίνεται λεπτομερής εξέταση με τον παλιό αλγόριθμο του snort. Αν ένα πακέτο καταφέρνει να προκαλεί(triggers) το ταίριασμα με όλα τα Rules ενός rule set συνεχώς τότε μπορεί να προκληθεί μια επίθεση τύπου DoS. Για να μπορέσει να αποφύγει τέτοιες επιθέσεις η νέα Detection engine του snort έχει μια εν γένη(build in) στρατηγική αποφυγής τέτοιων επιθέσεων που περιγράφεται ως εξής: 1. Σημαδεύεται με ένα flag κάθε rule που ελέγχθηκε κατά την διάρκεια της εξέτασης ενός πακέτου. 2. Δεν ελέγχονται τα rules, για κάθε πακέτο, που είναι σημαδεμένα(flagged) γιατί : a. Είτε το rule επιβεβαιώθηκε(validated) άρα υπάρχει ήδη στην event queue b. Είτε απέτυχε το ταίριασμα άρα δεν χρειάζεται να ξανά ελεγχθεί Protocol Flow Analyzer Η νέα Detection Engine του snort2.0 όπως προαναφέρθηκε και στην παράγραφο του Rule Optimizer έχει ένα μηχανισμό που λέγεται Flow analyzer. Ο σκωπώς αυτού του μηχανισμού είναι να κρατά πληροφορίες για της δύο πλευρές μίας σύνδεσης. Η πληροφορίες αυτές έχουν σαν σκοπό να ξεχωρίζουν την ροή(stream) και τα πακέτα που προέρχονται από τον client μίας υπηρεσίας και το ίδιο γιατί τον server. O λόγος της ύπαρξης αυτού του μηχανισμού είναι για να μείωση των άσκοπων ελέγχων τής κίνησης του δικτύου που παρακολουθείται από το snort. Ταυτόχρονα όμως πρέπει να ελέγχονται όλα τα πακέτα. Ο protocol analyzer με αυτόν τον τρόπο προσφέρει την δυνατότητα στο snort κρατώντας την κατάσταση(state) της σύνδεσης δύο πλευρών(client/server) που επικοινωνούν με ένα πρωτόκολλο επιπέδου σύνδεσης(tcp) εφαρμογής(application layer) όπως το HTTP. Για να το κάνει αυτό ελέγχει ποίος είναι ο client και ποίος ο server από το 3- way handshake που συμβαίνει για να εγκαινιάσει την σύνδεση. Οι πληροφορίες που κρατά ο μηχανισμός αυτός φαίνονται συνοπτικά στο παρακάτω σχήμα: 14

15 Σχήμα 1.3 Με αυτόν τον μηχανισμό δίνεται η δυνατότητα στον Rule Optimizer να φτιάχνει κατάλληλα rule-set ώστε να μπορεί να γίνεται έλεγχος τον πακέτων με rules που αφορούν μόνο signatures που μπορεί να παράγει ο server ή με signatures που μπορεί να παράγει ο client. Η διαφορά που προσφέρει στην αύξηση των επιδόσεων να οργανώνονται τα rule-sets βασισμένα στην δυνατότητα που προσφέρει ο Protocol Analyser μηχανισμός φαίνεται παρακάτω. Στο παράδειγμα του πρωτοκόλλου HTTP το Snort.org έκανε κατάλληλες μετρήσεις βρήκες τα εξής: 1. Από την συνολική κίνησης του δικτύου συνήθως to 75% οφείλεται σε Web Applications transactions. 2. Στο μοντέλο request-response του ΗΤΤP πρωτοκόλλου το 95% περίπου τις κίνησης οφείλεται στην ανταλλαγή δεδομένων και headers ενώ μόνο το 5% περίπου από αυτό οφείλεται στην μεταφορά των headers. 3. Η κίνηση από ένα προστατευμένο και εμπιστεύσιμο(trusted) web Server συνήθως είναι σε καλή κατάσταση άρα όχι ύποπτο. 4. Tα rules που αφορούν τον sever είναι θα είναι μόνο το 10% από το σύνολο τον rules που αφορούν HTTP transaction. Άρα επιβάλλεται ο Rule Optimizer να έχει την δυνατότητα να ελέγξει ένα πακέτο αυτής της κατηγορίας με τα κατάλληλα rules και όχι ακόμα με αυτό του client. Αυτή η δυνατότητα υπάρχει με τον Protocol flow analyzer μηχανισμό. 5. Ο Protocol Analyzer κρατά της πληροφορίες του state για τις δύο πλευρές. Για παράδειγμα αν είναι από την πόρτα 80 τότε θα ελεγχθεί μόνο με τα ruleς που αφορούν τον server. Από όλα αυτά είναι προφανές ότι ένας τέτοιος μηχανισμός προσφέρει τεράστιες δυνατότητες στο snort να εξετάζει ένα πακέτο μόνο με τα rules που πρέπεί και όχι να κάνει άσκοπες συγκρίσεις. Αν λάβουμε υπόψη μας ότι αντί να ελέγχεται το 95% τής κίνησης του δικτύου με τα rules που αφορούν τον server ελέγχεται μόνο το 5% που πραγματικά πρέπει να ελεγχθεί. Καθώς επίσης ότι το 75% από τής συνολική κίνηση οφείλεται στο web τότε είναι σαφές ότι οι επιδόσεις του snort αυξάνονται δραματικά Συνοψίζοντας την μηχανή του snort2.0 και παρουσίαση των επιδόσεων Η μηχανή του snort2.0 αποτελείται από τέσσερις βασικούς μηχανισμούς: 1. Rule Parser για το διάβασμα των Rules από αρχείο και η δόμηση τους στην μήνη 2. Rule Optimizer για να ομαδοποιηθούν τα rules σε rule-sets ώστε να γίνεται έλεγχος του κάθε πακέτου μόνο μία φορά για λόγους επιδόσεων. Ακόμα για να επιλέξει το κάθε πακέτο με πιο rule-set θα ελεγχθεί. 3. Multi-rule Inspection engine που με αλγόριθμους Multi-pattern matching ελέγχεται παράλληλα όλα τα rules σε σχέση με ένα πακέτο. 4. Protocol Analyzer που σαν κύριο στόχο έχει να κρατά το state των connections σε δύο διαφορετικές client και server ροές(flows). 15

16 Σχήμα 1.5 Το σχήμα αυτό απεικονίζει την γενική λειτουργία της νέας Detection engine του snort2.0.οι μηχανισμοί που περιγράφονται αναλυτικά παραπάνω δίνουν την δυνατότητα στο snort να είναι πολύ ταχύτερο στην εξέταση των πακέτων. Στο Snort.org έγιναν συγκριτικές μετρήσεις του snort με το snort 2.0. Σχήμα Logging ή Output engine Οι Output ή Logging engine υλοποιεί ουσιαστικέ δύο διαφορετικές ενέργειες με σκοπό να καταγράψει αυτό που εντόπισε το snort και να το κάνει γνωστός τον διαχειριστή του δικτύου. Οι δύο αυτές διαφορετικές λειτουργίες είναι το Alerting και το Logging με το πρώτο να έχει σαν κύριο σκοπό να προειδοποιήσει τον διαχειριστή του δικτύου ότι κάτι «ενδιαφέρον» συμβαίνει στο δίκτυο και το δεύτερο να καταγράφει πλήρως την πληροφορία που αφορά το πακέτο και το ίδιο το πακέτο. Η δεύτερη λειτουργία θα ενεργοποιηθεί επίσης από το snort όταν αυτό βρίσκεται σε Packet Logger Mode. 16

17 DEVELOPERS NOTE H Output Engine υλοποιείται στα αρχεία log.c, detection.c και event.h του Snort και είναι αυτά που θα εκτελέσουν την διαδικασία της γνωστοποίησης των αποτελεσμάτων του Snort. Το Log.c περιέχει τις συναρτήσεις που ήταν υπεύθυνες για το Alerting και Logging που δεν χρησιμοποιούνται αλλά και συναρτήσεις που διευκολύνουν στο να σχηματιστή ένα Alert περιέχοντας και άλλες πληροφορίες για παράδειγμα και το IP header χρησιμοποιώντας την αντίστοιχη συνάρτηση με πρόθεμα Print. Τέλος περιγράφει την κρίσιμη συνάρτηση SetEvent() που θα ορίσει το Event που είτε θα γίνει Logged είτε alert. To detection.h περιέχει της σημαντικές συναρτήσεις CallAlertFuncs(), CallLogFuncs() που παίρνουν σαν παράμετρο το Event και το μήνυμα σε σχέση με το event. To σημαντικό είναι ότι με τις συναρτήσεις αυτές το event δίνεται σε όλες τι συναρτήσεις που είναι υπεύθυνες για τα alert ή τα logs. Ακόμα αυτές οι συναρτήσεις καλούν δύο άλλες συναρτήσεις τις CallAlertPluginsFuncs (), CallLogPluginsFuncs() που αυτές με την σειρά τους έχουν την δυνατότητα να καλέσουν όλες τις συναρτήσεις των διαφόρων plug-ins του snort. Το event.h είναι το αρχείο που ορίζει την δομή Struct _Event που περιγράφει πληροφορίες όπως η προτεραιότητα ή η κατηγορία του Event είναι σαν Alert είτε σαν Plug-in. Ακόμα στον μηχανισμό αυτό του snort περιλαμβάνονται και κατάλληλες συναρτήσεις που έχουν σαν σκοπό να δώσουν ένα είδος API στους προγραμματιστές για να γράφουν πληροφορίες στα δικά τους Events ή σε δικά τους ξεχωριστά αρχεία. Η λειτουργία Alerting είναι εξειδικευμένη να αντιδρά ανάλογα όταν ένα Event συμβαίνει στο snort. Το snort καταγράφει το Event και για το Event αυτό κάνει Logging τόση πληροφορία όση ο μηχανισμός(preprocessor ή Detection Engine με τα Detection plug-ins) που προκάλεσε το Event θέλει να καταγράψει για αυτό. Η λειτουργία του Logging είναι για να καταγράφει ενδιαφέροντα πράγματα όπως telnet sessions χωρίς να χρειάζεται να παράγονται alert για κάθε πακέτο. Δηλαδή τα Event που παράγονται από το εκάστοτε μηχανισμό δεν θεωρούνται ικανά να προκαλέσουν κάποιο alert. Όταν είναι ενεργοποιημένα τα κατάλληλα modules για να καταγράφουν τα Events σε βάση δεδομένων τότε τα πράγματα διαφέρουν αρκετά. Τα DB plug-ins δεν ξεχωρίζουν τις δύο αυτές λειτουργίες του Alerting και του Logging. Συγκεκριμένα όταν το DB plug-in είναι στο alert mode τότε καταγράφονται μόνο τα events που έρχονται σαν Alerts αλλιώς αν είναι σε Log mode τότε καταγράφονται όλα. Η λειτουργίες της output engine από την έκδοση και μετά υλοποιείται από τα output plugging. Αυτό σημαίνει ότι οι συναρτήσεις που υλοποιούσαν την διαδικασία του output σε αρχεία στην οθόνη ή σε βάσεις δεδομένων δεν χρησιμοποιούνται ποία αλλά χρησιμοποιούνται οι αντίστοιχες των output plugging. Τελευταία υπάρχει η τάση ακόμα και τα output plugging να χρησιμοποιούνται εντός ενός κύριου μηχανισμού που λέγεται Barnyard. Το Output Engine για να εκτελέσει τις λειτουργίες του, δεν δέχεται είσοδο μόνο από το Detection Engine άλλα και από άλλα υποσυστήματα του Snort. Τέλος η μηχανή έχει την δυνατότητα να καταγράφει τις πληροφορίες σε διάφορα formats και όπως ASCII, Unicode, XML και διάφορες άλλες μορφές ανάλογα με ποία output plug-ins είναι ενεργοποιημένα. 1.7 Detection plugins, Output plugins and Preprocessors handling engine Τα plug-ins είναι κομμάτια κώδικα, με την λογική ξεχωριστών υποπρογραμμάτων που ενσωματώνονται στον υπόλοιπο κώδικα του Snort. Τα plug-ins επιτρέπουν την επέκταση των δυνατοτήτων του Snort χωρίς να χρειάζεται αλλαγή το κύριο σώμα του κώδικά του. Τα plugins έχουν σαν κύριο στόχο να επεκτείνουν τις δυνατότητες του snort προσθέτοντας του Anomaly Based Detection δυνατότητες πέρα από αυτή που παρέχεται πάνω στα Rules κανονικοποίηση πακέτων ή των streams ώστε να μπορούν να εφαρμόζονται 17

18 αποτελεσματικότερα τα rules. Ακόμα δίνεται η δυνατότητα με τα Plug-ins να επεκτείνεται η γλώσσα περιγραφής των rules.τέλος δίνεται η δυνατότητα να καταγράφονται με διάφορους τρόπου και διάφορα μέσα τα alerts και τα logs του snort. Το Snort αυτή τη στιγμή για κάθε μια από αυτές τις λειτουργίες υποστηρίζει τρία είδη plug-ins: τα preprocessor plug-ins τα detection plug-ins τα output plug-ins. DEVELOPERS NOTE Ο χειρισμός των plug-ins και η συνεργασία τους με το υπόλοιπο πρόγραμμα του Snort, επιτυγχάνεται μέσα από το αρχείο plugbase.c του κώδικα του Snort Preprocessors Plug-ins Οι preprocessors είναι plug-ins του Snort που εκτελούνται μετά το Decode Engine και πριν το Detection Engine. Οι preprocessors καλούνται προς εκτέλεση μία μόνο φορά για κάθε πακέτο και μέσω αυτών είναι δυνατόν να υλοποιηθούν εργασίες που έχουν να κάνουν είτε με την εξαγωγή διαφόρων στατιστικών που αφορούν τα πακέτα που επεξεργάζεται το Snort, είτε με την κατάλληλη προετοιμασία των πακέτων πριν αυτά προωθηθούν στο Detection Engine. Πρέπει να τονιστεί ότι για μερικές θεμελιώδεις λειτουργίες τής detection engine του snort οι preprocessors είναι απαραίτητοι. Παράδειγμα για το τελείται είναι o frag2 που ανασυνθέτει τα fragmented(κατακερματισμένα) πακέτα σε ένα νέο πακέτο ώστε τα περισσότερα rules να εφαρμόζονται σε αυτό και όχι στα κομμάτια τους. Παρακάτω περιγράφεται συνοπτικά τι είναι ένας preprocessor και τι δυνατότητες προσφέρει στο Snort : Οι Preprocessors αναπτύσσονται σαν plug-ins για δίνουν στο snort ευελιξία και επεκτασιμότητα. Και φυσικά για να μπορεί το snort να ρυθμίζεται ανάλογα με τις ανάγκες του περιβάλλοντος δικτύου που θα χρησιμοποιηθεί. Οι Preprocessors δίνουν την δυνατότητα στο snort να χειρίζεται δεδομένα που μοιράζονται σε πάνω από ένα πακέτα όπως τα TCP streams. Οι Preprocessors χρησιμοποιούνται στο snort για να κανονικοποιούν τα δεδομένα που περιγράφονται με πολλαπλούς τρόπους. Για παράδειγμα αν ένα http request μπορεί να είναι σε Unicode ή σε ASCII τότε ο αντίστοιχος preprocessor θα παράγει ένα output από Unicode σε ASCII ώστε rules που περιγράφονται με ASCII να μπορούν να εφαρμοστούν και σε αιτήματα(requests) σε Unicode. Οι Preprocessors ακόμα δίνουν την δυνατότητα στο snort να εφαρμόζει μεθόδους εντοπισμού που δεν μπορούν να εκφραστούν ακόμα και με τα ποιο ευέλικτα rules (anomaly based pattern matching με regular expressions.βλέπε παράγραφο για Rules). Για παράδειγμα ο portscan preprocessor που εντοπίζει τα port scans με anomaly based detection μηχανισμό preprocessors. Οι Preprocessors του snort μπορούν να προσφέρουν την δυνατότητα στο snort να εντοπίζει κάποιες επιθέσεις που δεν έχουν γίνει ακόμα rules. 18

19 DEVELOPERS NOTE Τα πηγαία αρχεία που τα αποτελούν τα Preprocessors plug-ins ξεκινάνε με το λεκτικό ssp_ και ακολουθούνται από το όνομα του plug-in. Υπάρχει σχετικό template μέσα στο πακέτο του snort για κάποιον που θέλει να γράψει το δικό του detection plug-in. Λεπτομέρειες για το πώς αναπτύσσεται ένα Preprocessor plug-in θα περιγραφή σε κεφάλαιο 2. Οι preprocessors που διαθέτει το snort επισήμως από το snort.org συνοψίζονται σε τέσσερις κατηγορίες και είναι οι εξής: Reassembling Packets Δυνατότητα σύνθεσης των πακέτων και των steams. o Steam4 χρησιμοποιείται για ανασύνθεση των TCP streams και κρατά του state των ροών(stream). o Frag2 χρησιμοποιείται για την ανασύνθεση(reassembly) των πακέτων στην αρχική τους μορφή. Τα πακέτα μπορεί να έχουν κατακερματιστεί επειδή μπορεί να πέρασαν από ένα δίκτυο με μικρότερο bandwidth από το αρχικό μέχρι αυτό να φτάσει στον τελικό του προορισμό. Decoding και Normalization Δυνατότητα κανονικοποίησης τον πακέτων. o Telnet_negotiation χρησιμοποιείται για να κανονικοποιεί την κίνηση που αφορά την επικοινωνία μέσο telnet αφαιρώντας τα inline feature-negotiation codes που είναι μέρος του telnet πρωτοκόλλου. o Http_decode χρησιμοποιείται για να κανονικοποιεί τα URL σε ένα αίτημα HTTP καθιστώντας ικανό το να γίνει Pattern-matching ακόμα και όταν χρησιμοποιείται διαφορετικό encoding (π.χ. Unicode) ή αλλά χαρακτηριστικά που προκαλούν διαφοροποιήσεις όπως η χρήση του συμβόλου ( \ ) αντί του ( / ). o Rcp_decode χρησιμοποιείται για να κανονικοποιεί την δικτυακή κίνηση του RPC βάζοντας όλα τα μηνύματα RPC σε ένα ενιαίο πακέτο. Anomaly Based Detection που δεν βασίζεται σε rules. o Portscan χρησιμοποιείται για να εντοπίζει τα port scans μετρώντας το αριθμό των εισερχομένων πακέτων από μία πηγή έχοντας ένα κατώφλι(threshold) χρόνου που καθορίζει αν η πηγή των πακέτων προσπαθεί να κάνει port scan. Ακόμα παρακολουθεί τα NMAP stealth πακέτα. Τον Portscan σύντομα θα τον διαδεχτεί από ο Portscan2. o The Back Orifice είναι ο preprocessor που εντοπίζει hosts στο εσωτερικό δίκτυο που ελέγχονται μέσο του Back Orifice παρακολουθώντας τα UDP πακέτα για να βρει τα 2 16 διαφορετικά κρυπτογραφημένα string του Back Orifice. Πειραματικοί Preprocessors o Arpspoof προσπαθεί να εντοπίζει επιθέσεις που χρησιμοποιούν το ARP spoof ελέγχοντας τις ARP απαντήσεις σε σχέση με ένα στατικό πίνακα από ARP-to- IP πίνακα διευθύνσεων. o Ans1_decode προσπαθεί να εντοπίζει κακοποιήσεις του ASN.1 πρωτοκόλλου που χρησιμοποιούνται από το SLL,SNMP και Χ.509. o Fnord προσπαθεί να εντοπίζει τα πολυμορφικά(polymorphic) shellcode (μαζί με το sledge) κοιτώντας όλες τις πιθανές ακολουθίες από string που μπορεί να είναι sledges πέρα από το κλασικό NOP. o Perfmonitor παράγει στατιστικές πληροφορίες για το snort. o Portscan2 είναι ο συνεχιστής του portscan και αυτό ο preprocessor είναι ο η καρδία του conversation preprocessor. Portscan2 πολύ σύντομα θα χρησιμοποιείται σαν ένας από τους κύριους preprocessors του snort 2. Αυτοί οι Preprocessors προτείνεται να μην χρησιμοποιούνται ειδικά σε περιπτώσει που το snort παρακολουθεί ένα παραγωγικό (production) δίκτυο αλλά μόνο για τις περιπτώσεις που ο Διαχειριστής του δικτύου θέλει να πειραματιστεί ή να έχει μία ένδειξη έστω και λιγότερο έγκυρη για το αν το δίκτυο του δέχεται επιθέσει σαν αυτές που προσπαθούν να πιάσουν οι preprocessors αυτοί. 19

20 Εκτός από τις τρεις βασικές δυνατότητες που αποκτά το snort με τους preprocessors δηλαδή την ανασύνθεση των πακέτων(reassembling Packets),την αποκωδικοποίηση των πρωτοκόλλων(decoding protocols), την δυνατότητα για anomaly based detection και αρκετές άλλες δυνατότητες όπως την παρουσίαση στατιστικών στοιχείών, αποκτά και ένα σημαντικό μειονέκτημα. Το πρόβλημα που μπορεί να αποκτήσει το snort από τους Preprocessors είναι να μειωθούν οι επιδώσεις του λόγο τής σημαντικά περισσότερης επεξεργαστικής ισχύς που απαιτείται για να γίνονται και άλλοι έλεγχοι από τους preprocessors εκτός από ένα απλό ή και ποιο σύνθετο(αλλά σίγουρα γρήγορο. Βλέπε multi-pattern inspection engine παραπάνω) pattern matching. Όπως θα δούμε και στο επόμενο κεφάλαιο είναι πολύ σημαντικό να μπορεί να γίνει η σωστή επιλογή των preprocessors και πώς αυτοί θα είναι ρυθμισμένοι(configured) «σωστά» ώστε το snort να αποδίδει «τα βέλτιστα» αναλόγως με το περιβάλλον δικτύου μέσα στο οποίο θα τοποθετηθεί. Detection Plug-ins εκτελούν διάφορες εργασίες ελέγχου ενός πακέτου σε σχέση με τα Rules. Με βάση την λειτουργία που περιγράψαμε παραπάνω για την Detection Engine του Snort κάθε ένα Detection plug-in μπορεί να εκτελεστεί αρκετές φορές για κάθε πακέτο. Το σημαντικότερο από όλα είναι ότι τα plug-in αυτά επεκτείνουν την Rules Language που βοηθά να περιγραφούν καλύτερα τα Rules και τα Signatures κάθε πακέτου. Ουσιαστικά αυτό που συμβαίνει είναι το κάθε ένα plug-in από αυτά να ενεργοποιείται από ένα rule που περιέχει μία λέξη κλειδί μα τις παραμέτρους της που αυτή θα ενεργοποιήσει το plug-in. Έτσι όταν ο Rule optimizer κρίνει ότι ένα πακέτο θα συγκριθεί με κάποιο rule-set τότε το όταν θα γίνει το maching με το rule είτε για λόγους validation είτε για να εκτελεστή γενικά μία ενεργεία θα καλεστεί το ανάλογο plug-in που περιγράφεται στο rule ή signature του snort. DEVELOPERS NOTE Τα πηγαία αρχεία που τα αποτελούν τα detection plug-ins ξεκινάνε με το λεκτικό sp_ και ακολουθούνται από το όνομα του plug-in. Τα Detection Plug-ins με τον καιρό αντικατέστησαν αρκετές από τις συναρτήσεις Output Plug-ins του αρχείου rules.c και μερικά από αυτά είναι το sp_ip_id_check το οποίο ελέγχει το πεδίο id του IP header, το sp_icmp_type_check το οποίο ελέγχει το πεδίο type του Icmp header κ.α. Υπάρχει σχετικό template μέσα στο πακέτο του snort για κάποιον που θέλει να γράψει το δικό του detection plug-in Output Plug-ins Τα Output Plug-ins όπως περιγράψαμε αναλυτικά στο output engine αυξάνουν την λειτουργικότητα του Output Engine του Snort, εκτελώντας εργασίες που έχουν να κάνουν με το Alerting και τo Logging. Με αυτά δίνεται η δυνατότητα στο snort να προβάλει τα alerts σε διάφορες μορφές όπως XML και σε διάφορους μηχανισμούs όπως to syslog ή το ή σε SMS ή βάσεις δεδομένων αναλόγως με τις ανάγκες του κάθε ενός διαχειριστή ενός μεγάλου ή μικρότερου δικτύου. Στην ουσία τα Output Plug-ins έχουν αντικαταστήσει ένα μεγάλο μέρος των συναρτήσεων εκτελούσε εξ ολοκλήρου τις λειτουργίες του Output Engine. DEVELOPERS NOTE Τα Output plug-ins ξεκινάνε με το λεκτικό spo_ και ακολουθούνται από το όνομα του plug-in. Υπάρχει σχετικό template μέσα στο πακέτο του snort για κάποιον που θέλει να γράψει το δικό του output plug-in αλλά η ίδια η κοινότητα του snort προτείνει να τα plug-ins να μην γράφονται πλέον για το Snort αλλά για το Barnyard 20

21 Μερικά γνωστά plug-ins τέτοιου είδους είναι: το spo_alert_full που καταγράφει σε ASCII μορφή κάθε alert που παράγει το Snort, με μεγάλη λεπτομέρεια όσο αναφορά το πακέτο που οδήγησε στην δημιουργία του, το spo_alert_fast το οποίο καταγράφει τα alerts με πιο συνοπτικό τρόπο το spo_log_tcpdump το οποίο αποθηκεύει σε binary μορφή τα πακέτα που περνάνε από το δίκτυο. Τελευταία υπάρχει η τάση ακόμα και τα output plugging να χρησιμοποιούνται εντός ενός κύριου μηχανισμού που λέγεται Barnyard. O μηχανισμός αυτός φτιαχτεί με την λογική ότι κάποια στιγμή θα μπορεί μέσο της τεχνολογίας των threads οι δυο μηχανισμοί αυτός του detection και αυτός του Barnyard(για output) θα δουλεύουν παράλληλα. Ο παραλληλισμός αυτός αφενός θα αυξήσει ακόμα περισσότερο τις επιδώσεις του snort αφετέρου θα μπορούν να γίνονται περισσότερο σοφιστικέ λειτουργίες και όχι απλά να καταγράφονται σε μία μορφή. Έτσι για παράδειγμα θα μπορούσε να γίνεται correlation με προηγούμενα Data πpοηγούμενων ημερών ή ωρών. Από την έκδοση snort2.0 και μετά αφού λύθηκαν τα κύρια προβλήματα του scaling σε σχέση με το detection έχει αρχίσει και δύνεται βάρος στον μηχανισμό του barnyard. Tο σχημα που ακολουθεί παρουσιάζει την δομή του Snort, όσο αναφορά τα υποσυστήματα από τα οποία αποτελείται και αναπαριστά την διαδρομή που ακολουθεί κάθε πακέτο κατά την επεξεργασία του από το Snort. Σχήμα