cosmos
20-02-04, 11:47
Το παρόν αποτελεί μία προσπάθεια για λίγη πληροφόρηση σε θέματα firewalls. Θα μπορούσε ίσως να τιτλοφορείται "Αλήθειες για ψέμματα σχετικά με την ασφάλεια" κτλ. Βασικός αποδέκτης του κειμένου είναι ο χρήστης με κάποιες γνώσεις για ασφάλεια, μια που για σοβαρή ασφάλεια σε επιχειρησιακό επίπεδο μάλλον χαροπαλεύω μεταξύ n00b και κάπως ελαφρά ενήμερου παίκτη. Καλό διάβασμα!
Βοήθεια, πώς μπλοκάρω τα ping;
To "ping" χρησιμοποιεί το πρωτόκολλο ICMP. Δείτε το 2.
Βοήθεια, πώς μπλοκάρω τα ICMP.
Δείτε το 4.
Τι σημαίνει γίνομαι "stealth";
"Φοράτε" μαύρες λαμαρίνες και με φόρα πηδάτε από το 8ο πάτωμα. Τέσπα, αν ζητάτε σοβαρότερη απάντηση, ας κάνω μία προσπάθεια.
Με μία χαλαρή "μετάφραση", σημαίνει ότι όταν σας στέλνει κάποιος υπολογιστής πακέτα πρωτοκόλλου ICMP, δεν τα απαντάτε. Έτσι, ο απομακρυσμένος υπολογιστής δεν παίρνει κάποιο σημάδι ότι ο δικός σας είναι ενεργός.
Το ότι δεν τα απαντάτε, μπορεί να σημαίνει ότι o firewall σας δεν τα αφήνει να τα δει καν το λειτουργικό σύστημα του υπολογιστή (όπως στην περίπτωση των προσωπικών firewalls). Ή ενδεχομένως να τα αφήνει, αλλά όταν το λειτουργικό σας σύστημα στέλνει απαντήσεις στο απομακρυσμένο σύστημα που έστειλε το αρχικό πακέτο, ο firewall μπλοκάρει αυτά τα εξερχόμενα πακέτα.
Βοήθεια, σκανάρισα το σύστημά μου και δεν είμαι "στελθ"!
Τo ICMP έχει κατακρεουργηθεί από τους πάντες και τα πάντα. Η αναζήτηση του "να γίνω stealth" έχει γίνει ιερότερη και από του Αγίου Δισκοπότηρου. Εμπεριέχεται βέβαια κάποια αλήθεια, αλλά εν γένει το ICMP είναι το κομμάτι του TCP/IP με το οποίο αναφέρονται προβλήματα. Είναι δλδ κρίσιμο κομμάτι του πρωτοκόλλου. Δεν είναι αμαρτία να μην είστε stealth!
Τότε γιατί τόση παράνοια; Από που μας προέκυψε αυτό το "stealth";
Από τις εταιρίες που δημιούργησαν μία αγορά παρανοϊκών πελατών, και απο ευαγγελιστές του δόγματος "Cyber-αδερφοί, κινδυνεύουμε!"
To "stealth" είναι κακό πράγμα δλδ;
IMHO ναι! Μπλοκάρεται χρήσιμη πληροφορία, η οποία δε βοηθάει την επικοινωνία άλλων συστημάτων προς το δικό μας ότι υπάρχει πρόβλημα. Ή του δικού μας συστήματος προς άλλα, για τον ίδιο λόγο.
Πέρα από αυτό όμως τρώει και bandwidth. Σκεφτείτε το εξής: κάποιος νομίζει ότι έχετε web server. Στέλνει λοιπόν ένα πακέτο πρωτοκόλλου TCP για να ξεκινήσει τη "συνομιλία" με το web server σας. Αν δεν έχετε web server, τότε τα ακόλουθα θα συμβούν ανάλογα με το αν είστε stealth ή όχι:
Αν δεν έχετε firewall, τότε θα απαντήσετε με ICMP Destination Unreachable. Αυτό το πακέτο θα το λάβει αυτός που επιθυμούσε την επικοινωνία με το web server σας και δε θα ξαναεπικοινωνήσει μαζί σας (εκτός και αν είναι και αυτός "stealth", οπότε δε θα πάρει το ICMP ποτέ :p ).
Αν έχετε firewall, τότε δε θα απαντήσετε καθόλου. Άρα γλυτώνετε bandwidth; Όχι ακριβώς, γιατί εφόσον ο "αποστολέας" δεν πήρε απάντηση από εσάς, θα σας ξαναστείλει πακέτο TCP για να αποκαταστήσει την επικοινωνία. Ξανά και ξανά, ώσπου τελικά να αποφασίσει (μέσω μηχανισμών timeout) ότι δεν έχει νόημα να προσπαθεί να σας μιλήσει... Με απλά λόγια, το ότι δεν απαντάτε καταλήγει σε κατανάλωση δικού σας bandwidth!
Μία άλλη περίπτωση είναι πάλι όταν συνδέεστε σε κανάλια IRC και είστε στελθαρισμένοι. Μπορεί να έχετε παρατηρήσει ότι ξεκινάτε να συνδεθείτε και υπάρχει μία καθυστέρηση δευτερολέπτων. Η καθυστέρηση μπορεί να οφείλεται στο εξής. Όταν συνδέεστε σε έναν IRC server, αυτός προσπαθεί να συνδεθεί στο δικό σας TCP port 113. Γιατί στο 113; 113 είναι το well-known port για την υπηρεσία AUTHentication. Δεν κάνει δλδ τίποτα κακό ο IRC server, απλά κοιτάζει για να πιστοποιήσει την ταυτότητά σας. Όλα σχεδόν τα IRC clients θα έχετε δει ότι "ανοίγουν" το port 113 για αυτό το σκοπό.
Και το πρόβλημα που είναι τότε, γιατί αυτή η καθυστέρηση; Εμ βρε παιδιά, είπαμε, αφού είστε stealth! :p Όπως και στο παράδειγμα της προηγούμενης παραγράφου, πριν σας βάλει μέσα ο IRC server, τσεκάρει ποιοί είστε. Τσεκάρει=στέλνει πακέτο TCP στο οποίο δεν πρόκεται να πάρει απάντηση, αν δεν αφήνετε εισερχόμενη κίνηση προς το τοπικό port 113. Ύστερα από λίγο, ο IRC server, ξαναστέλνει TCP πακέτο. Μία από τα ίδια. Η διαδικασία επαναλαμβάνεται, ώσπου εγκαταλείπει τις προσπάθειες (TCP timeout) και λέει "ok, ας τον αφήσω τον τύπο να συνδεθεί, γιατί με το AUTH δεν μπόρεσα να συνδεθώ και να βγάλω άκρη".
Αν αντ'αυτού είχατε firewall, αλλά όχι σε stealth λειτουργία, τότε θα στέλνατε ένα ICMP destination (port για την ακρίβεια) unreachable και θα τελείωνε η ιστορία. Αντ'αυτού η αναμονή για σύνδεση είναι το τίμημα της αναμονής.
Λύσεις για το συγκεκριμένο (διαλέξτε μία):
Ανοίξτε κανονικά το port 113 τοπικά
Ρυθμίστε το firewall ώστε να κάνει reject την εισερχόμενη κίνηση TCP για το τοπικό port 113 και όχι drop. Στην πρώτη περίπτωση, εισερχόμενα πακέτα TCP θα απαντηθούν με εξερχόμενα πακέτα TCP Reset (TCP RST). Το αποτέλεσμα θα είναι το ίδιο.Τι θα δείτε αν κάνετε κάτι από τα παραπάνω; Ότι μπαίνετε στον IRC server ακαριαία.
Δηλαδή δεν πρέπει να μπλοκάρω τα πακέτα ICMP;
Εδώ τα πράγματα περιπλέκονται... Και ναι και όχι.
Μας τα μπερδεύεις... Να μπλοκάρω ή να μην μπλοκάρω;
Κατ'αρχήν σε ένα "στεγανό" δίκτυο επιχείρησης δεν πρέπει να αφήνετε να περνάν τα ICMP (αλλά αυτό το ξέρατε ήδη).
Σε ένα δίκτυο public, φροντίζετε απλώς να έχετε κάποιο μέγιστο ρυθμό πακέτων ICMP, ώστε να μην πνιγεί το δίκτυο σε μία επίθεση ICMP (ICMP flood). Επίσης ενδεχομένως μπλοκάρετε τα ICMP που αφορούν διαφορετική δρομολόγηση (ICMP Redirect), αυτά είναι "δυνάμει επικίνδυνα", αν έχετε σε κάποιο μέρος του δημοσίου δικτύου και ένα προστατευμένο.
Τέσπα για το δικό σας υπολογιστή ή για το lan-άκι σας ισχύει ότι και στην αμέσως προηγούμενη παράγραφο. Που με απλά λόγια σημαίνει ότι αφήνετε και να βγαίνουν και να μπαίνουν όλα τα ICMP!
Αυτο-σκαναρίστηκα και είχα ανοικτές πόρτες
Ηρεμία, εδώ όντως μπορεί να έχετε κάποιο προβληματάκι. Ας πούμε ότι βρήκατε ότι το port 55555 είναι ανοικτό. Το Google είναι φίλος σας. Δώστε μία αναζήτηση εκεί με λέξεις κλειδιά "port 55555". Θα βρείτε κάποια πληροφορία σχετική. Ίσως να ανακαλύψετε ότι είναι υπηρεσία που ... την έχετε βάλει να τρέχει εσείς
Συνδεόμενος σε κάποιο web server, βλέπω μετά τα κατεβάσματα πολλά εισερχόμενα πακέτα TCP στο log του δικού μου firewall τα οποία "φυσικά" μπλοκάρονται, τα οποία προέρχονται από τη διεύθυνση του web server και του port του web server. Μου επιτίθεται;
Κατά πάσα πιθανότητα όχι. Εκείνο που βλέπετε είναι απομεινάρια των δικών σας κατεβασμάτων από το site. Εξηγούμαι: πάτε να συνδεθείτε σε ένα web server (τυπικά στο remote port 80). Στέλνετε ένα πακέτο TCP, o firewall το βλέπει (εννοείται ότι έχετε επιτρέψει την κίνηση αυτού του τύπου). Επειδή ο firewall καταλαβαίνει ότι "περιμένετε" ένα πακέτο TCP από το server, θα αφήσει πακέτα από το web server να εισέλθουν. Αν όλα πάνε καλά, ξεκινάτε να κατεβάζετε τη σελίδα που σας ενδιαφέρει. Σε όλη τη διάρκεια του κατεβάσματος πακέτα TCP πάνε και έρχονται και ο firewall τα βλέπει όλα ως νόμιμα (και είναι).
Κάποια στιγμή το κατέβασμα τελειώνει. Είτε ο web server είτε εσείς θα στείλετε ένα ειδικό πακέτο TCP που υποδηλώνει ότι το κανάλι TCP πάει για κλείσιμο. O firewall το βλέπει αυτό και αντιλαμβάνεται ότι πλέον δεν πρέπει να αφήσει άλλα εισερχόμενα πακέτα να έρθουν. Όπερ και εγένετο. Έλα όμως που όπως δουλεύει το πρωτόκολλο TCP/IP πρέπει και τα δύο μέρη να πουν ότι "έκλεισα το δικό μου σκέλος της επικοινωνίας". Επίσης, λόγω καθυστερήσεων στο Internet, μπορείτε να παρακολουθήσετε την ίδια συμπεριφορά. Το ρεσουμέ είναι ότι ο μεν firewall σας θεωρεί το θέμα λήξαν, δλδ ότι δεν υπάρχει πλέον επικοινωνία με το site, αλλά έρχονται πακέτα TCP από το web site (νομιμότατα πακέτα, τα οποία μπορεί να λένε "η κλήση έχει τερματιστεί και από εδώ") τα οποία το firewall πλέον τα θεωρεί άγνωστα/εχθρικά. No big deal τέσπα.
Συνδεόμενος σε κάποιο web server, βλέπω μετά τα κατεβάσματα πολλά εισερχόμενα πακέτα TCP στο log του δικού μου firewall τα οποία "φυσικά" μπλοκάρονται, τα οποία προέρχονται από ένα σύστημα με διεύθυνση την ίδια, ανεξάρτητα από το web site που βλέπω. Μου επιτίθεται αυτό το σύστημα;
Μήπως η πόρτα που αντιστοιχεί σε αυτό το σύστημα είναι 3128, 8080, 8000, 8888 (και σπανιότερα και 80); Αν ναι, κατά πάσα πιθανότητα έχετε proxy server ρυθμισμένο και είστε στην προηγούμενη περίπτωση, με τη διαφορά ότι η επικοινωνία που έχετε όταν κατεβάζετε μία σελίδα από κάποιο web site είναι μόνο με τον proxy server σας! Δεν υπάρχει πρόβλημα δλδ.
Στο log του firewall βλέπω άπειρα πακέτα με διεύθυνση προορισμού 224.0.0.Χ. Τι δουλειά έχουν με μένα;
Είναι πακέτα multicast. Δηλαδή πακέτα που εκπέμπονται και πάνε σε πολλούς αποδέκτες ταυτόχρονα. Ειδική περίπτωση broadcast εκπομπής αν θέλετε. Για παράδειγμα, οι συνδρομητές της Forthnet ίσως να έχουν προσέξει πακέτα με διεύθυνση προορισμού 224.0.0.2 (αν θυμάμαι καλά), τα οποία "εκπέμπονται" με συχνότητα 1 πακέτο κάθε 2 λεπτά. Τα πακέτα αυτά περιέχουν τη πληροφορία της χρηματιστηριακής υπηρεσίας SMART της Forthnet. (IMHO, εξυπνότατος τρόπος για μετάδοση μονόδρομης πληροφορίας σε πολλούς, με ελάχιστη κατανάλωση bandwidth).
Τι μπορώ να κάνω για να μην είμαι "ανοιχτός";
Ακολουθήστε τις οδηγίες στον οδηγό ασφάλειας για νέους χρήστες (http://www.adslgr.com/forum/showthread.php?t=4092) καταρχήν. Παίρνετε οπωσδήποτε αντίγραφα εφεδρείας των αρχείων σας ή, ακόμα καλύτερα, αν έχετε πολλούς/μεγάλους δίσκους αγοράστε το Symantec Ghost ή κάποιο ανάλογο πρόγραμμα και παίρνετε αντίγραφο όλου του συστήματος.
Έχω ένα router με ΝΑΤ και κάποιες εφαρμογές οι οποίες απαιτούν συνδέσεις εισερχόμενες προς τον υπολογιστή μου, στην τοπική θύρα ΧΧΧ, τι πρέπει να κάνω;
Πρέπει, όπως λένε, να κάνετε "port mapping" (αναφέρεται και ως "port forwarding"). Απλά δηλώνετε στις ρυθμίσεις του ΝΑΤ ότι θέλετε ό,τι έρχεται στη θύρα ΧΧΧ του router, να "προωθείται" (να μεταφέρεται δλδ) στη θύρα XXX ενός υπολογιστή μέσα στο δίκτυό σας.
Έχω ένα router με firewall μόνο και κάποιες εφαρμογές οι οποίες απαιτούν συνδέσεις εισερχόμενες προς τον υπολογιστή μου, στην τοπική θύρα ΧΧΧ, τι πρέπει να κάνω;
Εδώ θα πρέπει όπως λένε να "επιτρέψετε" ορισμένες εισερχόμενες κλήσεις. Δηλαδή να πάτε στις ρυθμίσεις firewall του router σας και να πείτε ότι θέλετε να επιτρέπεται ("allow") η κίνηση προς τη τοπική θύρα ΧΧΧ.
Ο δικός μου router έχει και firewall και ΝΑΤ, τι γίνεται σε παρόμοια περίπτωση;
Και τα δύο παραπάνω! Δλδ και το NAT πρέπει να ρυθμίσετε, αλλά και το firewall.
Αν η εφαρμογή χρειάζεται προσπέλαση στις τοπικές θύρες ΧΧΧ και ΥΥΥ τι γίνεται;
Θα κάνετε ότι χρειάζεται πρώτα για τη μία θύρα και μετά για τη δεύτερη. Το ίδιο αν υπάρχει και τρίτη και τέταρτη κτλ.
Αν η εφαρμογή χρειάζεται προσπέλαση στις τοπικές θύρες από ΧΧΧ έως ΥΥΥ τι γίνεται; Θα τις βάλω μία-μία;
Σε πολλούς firewalls-routers μπορείτε να δώσετε περιοχή τιμών, οπότε θα κάνετε μία φορά μόνο τη δουλειά.
Ο router μου έχει firewall ρυθμισμένο να επιτρέπει εξερχόμενες συνδέσεις, αλλά να μπλοκάρει τις εισερχόμενες. Όταν πάω να κάνω FTP από κάποιο server, συνδέομαι αλλά δεν μπορώ να κατεβάσω τίποτα. Τι φταίει;
Καλωσήρθατε στον κόσμο των ΝΑΤ/firewall-εχθρικών εφαρμογών :) Το πρόβλημα με το FTP, αλλά και με πολλά άλλα πρωτόκολλα (Η.323, SIP, DirectPlay) είναι ότι χρησιμοποιούν εκτός από μία εξερχόμενη σύνδεση (την οποία ο firewall με την ρύθμιση της ερώτησης θα επιτρέψει) και μία εισερχόμενη για την καθεαυτού μεταφορά αρχείων ή για τη μεταφορά φωνής (H.323, SIP) κτλ.
Ε, και λοιπόν; Δεν μπορώ να ανοίξω απλά την απαιτούμενη θύρα και ώστε να επιτραπεί αυτή η εισερχόμενη κίνηση;
Δυστυχώς όχι, γιατί η τοπική θύρα μεταβάλλεται κάθε φορά! Τη μία μπορεί να είναι η 2000, την άλλη η 45000 κτλ. Στο FTP λ.χ. η εισερχόμενη σύνδεση θα χρησιμοποιεί κάποιο τυχαίο port > 1024 κάθε φορά.
Ευτυχώς δεν έχω firewall, μόνο NAT. Οπότε δε θα έχω αυτό το πρόβλημα, σωστά;
Λάθος. Το πρόβλημα υφίσταται και στο firewall και στο NAT. Υπάρχουν όμως λύσεις.
Τι λύσεις;
Καταρχήν υπάρχουν έξυπνα firewalls/NAT τα οποία έχουν protocol inspectors, ένα για κάθε "δύσκολο" πρωτόκολλο που υποστηρίζουν. Έτσι, αν ένας router έχει FTP protocol inspector, τότε παρακολουθεί την εξερχόμενη κίνηση FTP και αν δει ότι πρόκειται να σκάσει μύτη εισερχόμενη κίνηση, αυτόματα ρυθμίζει το firewall/ΝΑΤ ώστε να την επιτρέψει. Μόνο όμως για τη διάρκεια της συνεδρίας FTP και μόνο για συγκεκριμένη θύρα.
Καλό ακούγεται! Υπάρχουν και άλλοι protocol inspectors εκτός από FTP;
Βέβαια, υπάρχουν για IRC DCC, H.323, SIP κτλ
Καλά όλα αυτά, αλλά έχω μία εφαρμογή με ένα τέτοιο δύσκολο πρωτόκολλο ΧΧΧ, στο οποίο ανοίγονται δυναμικά θύρες που αλλάζουν κάθε φορά. Πως δοκιμάζω αν ο δικός μου router έχει στο firewall/NAT protocol inspector για το πρωτόκολλο ΧΧΧ που με ενδιαφέρει;
Μέσω "δοκιμής και σφάλματος"! ;) Δοκιμάστε την εφαρμογή σας και αν δουλέψει, κατά πάσα πιθανότητα ο router σας έχει XXX protocol inspector.
Δοκίμασα και δε δουλεύει δυστυχώς. Ατύχησα;
Όχι ακόμα, υπάρχουν 1-2 πράγματα που μπορείτε να κάνετε.
Το απλούστερο όλων είναι να δείτε μήπως η εφαρμογή σας αν και χρησιμοποιεί δυναμικές θύρες, μπορεί να ρυθμιστεί εσωτερικά να χρησιμοποιεί μία συγκεκριμένη περιοχή τιμών. Λ.χ. από 9000 έως 9010. Aν είναι έτσι κάνετε τη ρύθμιση αυτή στην εφαρμογή και μετά συνεχίζετε όπως παραπάνω, σαν η εφαρμογή δλδ να χρησιμοποιούσε συγκεκριμένες σταθερές θύρες. Παράδειγμα είναι το γνωστό mIRC, στο οποίο οι μεταφορές αρχείων (DCC) μπορούν να ρυθμιστούν να χρησιμοποιούν ports από συγκεκριμένη περιοχή τιμών.
Ή ενδεχομένως η εφαρμογή να μπορεί να ρυθμιστεί ώστε να χρησιμοποιεί μόνο εξερχόμενες κλήσεις.
Χαρακτηριστικό παράδειγμα είναι το FTP, όπου ζητώντας να συνδεθούμε με λειτουργία passive οι συνδέσεις μας θα είναι μόνο εξερχόμενες.
Δυστυχώς η εφαρμογή μου δεν έχει τέτοια δυνατότητα...
Υπάρχουν μερικές ακόμα τεχνολογίες που μπορεί να βοηθήσουν. Αν για παράδειγμα η εφαρμογή και το λειτουργικό σύστημα του υπολογιστή μας χρησιμοποιούν την τεχνολογία UPnP και αυτή, επιπρόσθετα υποστηρίζεται από τον router μας, τότε ενεργοποιώντας την στον router, πρακτικά η ίδια η εφαρμογή θα του δίνει οδηγίες για το τι θα ανοίξει στο firewall και ποια θύρα κάθε φορά θα πρέπει να κάνει port mapping.
Έχω διαβάσει όμως ότι το UPnP αποτελεί τρύπα ασφαλείας, ισχύει αυτό;
Ισχύει, με την έννοια ότι αν ένα κακόβουλο πρόγραμμα καταφέρει να βρεθεί να εκτελείται μέσα στο δικό σας υπολογιστή, τότε μπορεί να "τηλεχειριστεί" το router σας, για να επιτρέχει εισερχόμενη κίνηση, η οποία φυσιολογικά δε θα περνούσε.
Αν και μόνο αν το εσωτερικό σας δίκτυο είναι ασφαλές, τότε το UPnP αποτελεί πλεονέκτημα: θύρες ανοίγονται και κλείνονται δυναμικά. Δεν παραμένουν μόνιμα δλδ κάποιες θύρες ανοικτές! Επιπρόσθετα, είναι πολλές πλέον οι εφαρμογές που εκμεταλλεύονται το UPnP (ΜSN/XP Messenger, παιχνίδια που χρησιμοποιούν DirectPlay, P2P προγράμματα όπως eMule/Azureus/μTorrent, προγράμματα και ATA για Voip κτλ).
Ούτε UPnP υπάρχει... Κάτι άλλο;
Η λύση που μένει είναι για το μεν ΝΑΤ να προωθήσετε όλα τα ports από 1024-65535, για το δε firewall να ανοίξετε την εισερχόμενη κίνηση για αυτά τα ports.
Υπάρχουν σε ορισμένους firewalls και τα "Triggers" πάντως. "Trigger" σημαίνει σκανδάλη. Ρυθμίζετε ένα trigger λέγοντας ότι "όποτε δεις εξερχόμενη κίνηση που μπορεί να υποδηλώνει ότι ξεκινάω δουλειά με ένα δύσκολο πρωτόκολλο, άνοιξε όλες τις θύρες 1024-65535". Κάπως καλύτερη κατάσταση δλδ.
Γιατί από τότε που ενεργοποίησα το firewall το σερφάρισμα έγινε αργό;
Ρίξτε μια ματιά στα αρχεία καταγραφής (logs) του firewall. Μήπως βλέπετε κάτι που να το χαρακτηρίζει attack απο το δικό σας εσωτερικό ip σε χ.χ.χ.χ:80;
Αν ναί τότε έχει να κάνει με το πόσες ταυτόχρονες συνδέσεις ανοίγει ο browser σας, και το firewall το βλέπει σαν απόπειρα "DDoS attack" (μίας μορφής επίθεσης δλδ). Για να το αποφύγετε πρέπει να ρυθμίσετε το firewall σας ώστε να είναι πιο "ανεκτικό" ως προς το πόσες συνδέσεις θεωρεί ότι αποτελούν επίθεση.
Τα έχω διαβάσει όλα αυτά, αλλά ακόμα δεν ξέρω τι να κάνω με το ΧΥΖ firewall για την ΑΒC δουλειά;
Εχμ, ψάξατε; Τί;;;; ΔΕΝ ψάξατε; Οι ειδικοί σας περιμένουν στην ομάδα συζητήσεων για firewalls (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.security.firewalls). 99% θα βρείτε εκεί αυτό που ψάχνετε!
Μπορώ με μια ματιά να αυτή τη στιγμή πόσο έντονη είναι η εχθρική δραστηριότητα στο δίκτυο;
Και βέβαια. Υπάρχουν "δείκτες επισφαλούς δραστηριότητας" στο δίκτυο. Αυτή η δραστηριότητα κατά 99,99% οφείλεται σε μολυσμένα συστήματα, τα οποία προσπαθούν να μολύνουν και άλλα. Μερικοί τέτοιοι δείκτες από αξιόπιστες πηγές, δίνονται παρακάτω, όπου φυσικά απεικονίζεται το τωρινό/τρέχων επίπεδο:
http://isc.sans.org/images/status.gif (http://isc.sans.org)
EDIT: Ευχαριστίες προς όλους για τα σχόλιά τους στο FAQ :)
Βοήθεια, πώς μπλοκάρω τα ping;
To "ping" χρησιμοποιεί το πρωτόκολλο ICMP. Δείτε το 2.
Βοήθεια, πώς μπλοκάρω τα ICMP.
Δείτε το 4.
Τι σημαίνει γίνομαι "stealth";
"Φοράτε" μαύρες λαμαρίνες και με φόρα πηδάτε από το 8ο πάτωμα. Τέσπα, αν ζητάτε σοβαρότερη απάντηση, ας κάνω μία προσπάθεια.
Με μία χαλαρή "μετάφραση", σημαίνει ότι όταν σας στέλνει κάποιος υπολογιστής πακέτα πρωτοκόλλου ICMP, δεν τα απαντάτε. Έτσι, ο απομακρυσμένος υπολογιστής δεν παίρνει κάποιο σημάδι ότι ο δικός σας είναι ενεργός.
Το ότι δεν τα απαντάτε, μπορεί να σημαίνει ότι o firewall σας δεν τα αφήνει να τα δει καν το λειτουργικό σύστημα του υπολογιστή (όπως στην περίπτωση των προσωπικών firewalls). Ή ενδεχομένως να τα αφήνει, αλλά όταν το λειτουργικό σας σύστημα στέλνει απαντήσεις στο απομακρυσμένο σύστημα που έστειλε το αρχικό πακέτο, ο firewall μπλοκάρει αυτά τα εξερχόμενα πακέτα.
Βοήθεια, σκανάρισα το σύστημά μου και δεν είμαι "στελθ"!
Τo ICMP έχει κατακρεουργηθεί από τους πάντες και τα πάντα. Η αναζήτηση του "να γίνω stealth" έχει γίνει ιερότερη και από του Αγίου Δισκοπότηρου. Εμπεριέχεται βέβαια κάποια αλήθεια, αλλά εν γένει το ICMP είναι το κομμάτι του TCP/IP με το οποίο αναφέρονται προβλήματα. Είναι δλδ κρίσιμο κομμάτι του πρωτοκόλλου. Δεν είναι αμαρτία να μην είστε stealth!
Τότε γιατί τόση παράνοια; Από που μας προέκυψε αυτό το "stealth";
Από τις εταιρίες που δημιούργησαν μία αγορά παρανοϊκών πελατών, και απο ευαγγελιστές του δόγματος "Cyber-αδερφοί, κινδυνεύουμε!"
To "stealth" είναι κακό πράγμα δλδ;
IMHO ναι! Μπλοκάρεται χρήσιμη πληροφορία, η οποία δε βοηθάει την επικοινωνία άλλων συστημάτων προς το δικό μας ότι υπάρχει πρόβλημα. Ή του δικού μας συστήματος προς άλλα, για τον ίδιο λόγο.
Πέρα από αυτό όμως τρώει και bandwidth. Σκεφτείτε το εξής: κάποιος νομίζει ότι έχετε web server. Στέλνει λοιπόν ένα πακέτο πρωτοκόλλου TCP για να ξεκινήσει τη "συνομιλία" με το web server σας. Αν δεν έχετε web server, τότε τα ακόλουθα θα συμβούν ανάλογα με το αν είστε stealth ή όχι:
Αν δεν έχετε firewall, τότε θα απαντήσετε με ICMP Destination Unreachable. Αυτό το πακέτο θα το λάβει αυτός που επιθυμούσε την επικοινωνία με το web server σας και δε θα ξαναεπικοινωνήσει μαζί σας (εκτός και αν είναι και αυτός "stealth", οπότε δε θα πάρει το ICMP ποτέ :p ).
Αν έχετε firewall, τότε δε θα απαντήσετε καθόλου. Άρα γλυτώνετε bandwidth; Όχι ακριβώς, γιατί εφόσον ο "αποστολέας" δεν πήρε απάντηση από εσάς, θα σας ξαναστείλει πακέτο TCP για να αποκαταστήσει την επικοινωνία. Ξανά και ξανά, ώσπου τελικά να αποφασίσει (μέσω μηχανισμών timeout) ότι δεν έχει νόημα να προσπαθεί να σας μιλήσει... Με απλά λόγια, το ότι δεν απαντάτε καταλήγει σε κατανάλωση δικού σας bandwidth!
Μία άλλη περίπτωση είναι πάλι όταν συνδέεστε σε κανάλια IRC και είστε στελθαρισμένοι. Μπορεί να έχετε παρατηρήσει ότι ξεκινάτε να συνδεθείτε και υπάρχει μία καθυστέρηση δευτερολέπτων. Η καθυστέρηση μπορεί να οφείλεται στο εξής. Όταν συνδέεστε σε έναν IRC server, αυτός προσπαθεί να συνδεθεί στο δικό σας TCP port 113. Γιατί στο 113; 113 είναι το well-known port για την υπηρεσία AUTHentication. Δεν κάνει δλδ τίποτα κακό ο IRC server, απλά κοιτάζει για να πιστοποιήσει την ταυτότητά σας. Όλα σχεδόν τα IRC clients θα έχετε δει ότι "ανοίγουν" το port 113 για αυτό το σκοπό.
Και το πρόβλημα που είναι τότε, γιατί αυτή η καθυστέρηση; Εμ βρε παιδιά, είπαμε, αφού είστε stealth! :p Όπως και στο παράδειγμα της προηγούμενης παραγράφου, πριν σας βάλει μέσα ο IRC server, τσεκάρει ποιοί είστε. Τσεκάρει=στέλνει πακέτο TCP στο οποίο δεν πρόκεται να πάρει απάντηση, αν δεν αφήνετε εισερχόμενη κίνηση προς το τοπικό port 113. Ύστερα από λίγο, ο IRC server, ξαναστέλνει TCP πακέτο. Μία από τα ίδια. Η διαδικασία επαναλαμβάνεται, ώσπου εγκαταλείπει τις προσπάθειες (TCP timeout) και λέει "ok, ας τον αφήσω τον τύπο να συνδεθεί, γιατί με το AUTH δεν μπόρεσα να συνδεθώ και να βγάλω άκρη".
Αν αντ'αυτού είχατε firewall, αλλά όχι σε stealth λειτουργία, τότε θα στέλνατε ένα ICMP destination (port για την ακρίβεια) unreachable και θα τελείωνε η ιστορία. Αντ'αυτού η αναμονή για σύνδεση είναι το τίμημα της αναμονής.
Λύσεις για το συγκεκριμένο (διαλέξτε μία):
Ανοίξτε κανονικά το port 113 τοπικά
Ρυθμίστε το firewall ώστε να κάνει reject την εισερχόμενη κίνηση TCP για το τοπικό port 113 και όχι drop. Στην πρώτη περίπτωση, εισερχόμενα πακέτα TCP θα απαντηθούν με εξερχόμενα πακέτα TCP Reset (TCP RST). Το αποτέλεσμα θα είναι το ίδιο.Τι θα δείτε αν κάνετε κάτι από τα παραπάνω; Ότι μπαίνετε στον IRC server ακαριαία.
Δηλαδή δεν πρέπει να μπλοκάρω τα πακέτα ICMP;
Εδώ τα πράγματα περιπλέκονται... Και ναι και όχι.
Μας τα μπερδεύεις... Να μπλοκάρω ή να μην μπλοκάρω;
Κατ'αρχήν σε ένα "στεγανό" δίκτυο επιχείρησης δεν πρέπει να αφήνετε να περνάν τα ICMP (αλλά αυτό το ξέρατε ήδη).
Σε ένα δίκτυο public, φροντίζετε απλώς να έχετε κάποιο μέγιστο ρυθμό πακέτων ICMP, ώστε να μην πνιγεί το δίκτυο σε μία επίθεση ICMP (ICMP flood). Επίσης ενδεχομένως μπλοκάρετε τα ICMP που αφορούν διαφορετική δρομολόγηση (ICMP Redirect), αυτά είναι "δυνάμει επικίνδυνα", αν έχετε σε κάποιο μέρος του δημοσίου δικτύου και ένα προστατευμένο.
Τέσπα για το δικό σας υπολογιστή ή για το lan-άκι σας ισχύει ότι και στην αμέσως προηγούμενη παράγραφο. Που με απλά λόγια σημαίνει ότι αφήνετε και να βγαίνουν και να μπαίνουν όλα τα ICMP!
Αυτο-σκαναρίστηκα και είχα ανοικτές πόρτες
Ηρεμία, εδώ όντως μπορεί να έχετε κάποιο προβληματάκι. Ας πούμε ότι βρήκατε ότι το port 55555 είναι ανοικτό. Το Google είναι φίλος σας. Δώστε μία αναζήτηση εκεί με λέξεις κλειδιά "port 55555". Θα βρείτε κάποια πληροφορία σχετική. Ίσως να ανακαλύψετε ότι είναι υπηρεσία που ... την έχετε βάλει να τρέχει εσείς
Συνδεόμενος σε κάποιο web server, βλέπω μετά τα κατεβάσματα πολλά εισερχόμενα πακέτα TCP στο log του δικού μου firewall τα οποία "φυσικά" μπλοκάρονται, τα οποία προέρχονται από τη διεύθυνση του web server και του port του web server. Μου επιτίθεται;
Κατά πάσα πιθανότητα όχι. Εκείνο που βλέπετε είναι απομεινάρια των δικών σας κατεβασμάτων από το site. Εξηγούμαι: πάτε να συνδεθείτε σε ένα web server (τυπικά στο remote port 80). Στέλνετε ένα πακέτο TCP, o firewall το βλέπει (εννοείται ότι έχετε επιτρέψει την κίνηση αυτού του τύπου). Επειδή ο firewall καταλαβαίνει ότι "περιμένετε" ένα πακέτο TCP από το server, θα αφήσει πακέτα από το web server να εισέλθουν. Αν όλα πάνε καλά, ξεκινάτε να κατεβάζετε τη σελίδα που σας ενδιαφέρει. Σε όλη τη διάρκεια του κατεβάσματος πακέτα TCP πάνε και έρχονται και ο firewall τα βλέπει όλα ως νόμιμα (και είναι).
Κάποια στιγμή το κατέβασμα τελειώνει. Είτε ο web server είτε εσείς θα στείλετε ένα ειδικό πακέτο TCP που υποδηλώνει ότι το κανάλι TCP πάει για κλείσιμο. O firewall το βλέπει αυτό και αντιλαμβάνεται ότι πλέον δεν πρέπει να αφήσει άλλα εισερχόμενα πακέτα να έρθουν. Όπερ και εγένετο. Έλα όμως που όπως δουλεύει το πρωτόκολλο TCP/IP πρέπει και τα δύο μέρη να πουν ότι "έκλεισα το δικό μου σκέλος της επικοινωνίας". Επίσης, λόγω καθυστερήσεων στο Internet, μπορείτε να παρακολουθήσετε την ίδια συμπεριφορά. Το ρεσουμέ είναι ότι ο μεν firewall σας θεωρεί το θέμα λήξαν, δλδ ότι δεν υπάρχει πλέον επικοινωνία με το site, αλλά έρχονται πακέτα TCP από το web site (νομιμότατα πακέτα, τα οποία μπορεί να λένε "η κλήση έχει τερματιστεί και από εδώ") τα οποία το firewall πλέον τα θεωρεί άγνωστα/εχθρικά. No big deal τέσπα.
Συνδεόμενος σε κάποιο web server, βλέπω μετά τα κατεβάσματα πολλά εισερχόμενα πακέτα TCP στο log του δικού μου firewall τα οποία "φυσικά" μπλοκάρονται, τα οποία προέρχονται από ένα σύστημα με διεύθυνση την ίδια, ανεξάρτητα από το web site που βλέπω. Μου επιτίθεται αυτό το σύστημα;
Μήπως η πόρτα που αντιστοιχεί σε αυτό το σύστημα είναι 3128, 8080, 8000, 8888 (και σπανιότερα και 80); Αν ναι, κατά πάσα πιθανότητα έχετε proxy server ρυθμισμένο και είστε στην προηγούμενη περίπτωση, με τη διαφορά ότι η επικοινωνία που έχετε όταν κατεβάζετε μία σελίδα από κάποιο web site είναι μόνο με τον proxy server σας! Δεν υπάρχει πρόβλημα δλδ.
Στο log του firewall βλέπω άπειρα πακέτα με διεύθυνση προορισμού 224.0.0.Χ. Τι δουλειά έχουν με μένα;
Είναι πακέτα multicast. Δηλαδή πακέτα που εκπέμπονται και πάνε σε πολλούς αποδέκτες ταυτόχρονα. Ειδική περίπτωση broadcast εκπομπής αν θέλετε. Για παράδειγμα, οι συνδρομητές της Forthnet ίσως να έχουν προσέξει πακέτα με διεύθυνση προορισμού 224.0.0.2 (αν θυμάμαι καλά), τα οποία "εκπέμπονται" με συχνότητα 1 πακέτο κάθε 2 λεπτά. Τα πακέτα αυτά περιέχουν τη πληροφορία της χρηματιστηριακής υπηρεσίας SMART της Forthnet. (IMHO, εξυπνότατος τρόπος για μετάδοση μονόδρομης πληροφορίας σε πολλούς, με ελάχιστη κατανάλωση bandwidth).
Τι μπορώ να κάνω για να μην είμαι "ανοιχτός";
Ακολουθήστε τις οδηγίες στον οδηγό ασφάλειας για νέους χρήστες (http://www.adslgr.com/forum/showthread.php?t=4092) καταρχήν. Παίρνετε οπωσδήποτε αντίγραφα εφεδρείας των αρχείων σας ή, ακόμα καλύτερα, αν έχετε πολλούς/μεγάλους δίσκους αγοράστε το Symantec Ghost ή κάποιο ανάλογο πρόγραμμα και παίρνετε αντίγραφο όλου του συστήματος.
Έχω ένα router με ΝΑΤ και κάποιες εφαρμογές οι οποίες απαιτούν συνδέσεις εισερχόμενες προς τον υπολογιστή μου, στην τοπική θύρα ΧΧΧ, τι πρέπει να κάνω;
Πρέπει, όπως λένε, να κάνετε "port mapping" (αναφέρεται και ως "port forwarding"). Απλά δηλώνετε στις ρυθμίσεις του ΝΑΤ ότι θέλετε ό,τι έρχεται στη θύρα ΧΧΧ του router, να "προωθείται" (να μεταφέρεται δλδ) στη θύρα XXX ενός υπολογιστή μέσα στο δίκτυό σας.
Έχω ένα router με firewall μόνο και κάποιες εφαρμογές οι οποίες απαιτούν συνδέσεις εισερχόμενες προς τον υπολογιστή μου, στην τοπική θύρα ΧΧΧ, τι πρέπει να κάνω;
Εδώ θα πρέπει όπως λένε να "επιτρέψετε" ορισμένες εισερχόμενες κλήσεις. Δηλαδή να πάτε στις ρυθμίσεις firewall του router σας και να πείτε ότι θέλετε να επιτρέπεται ("allow") η κίνηση προς τη τοπική θύρα ΧΧΧ.
Ο δικός μου router έχει και firewall και ΝΑΤ, τι γίνεται σε παρόμοια περίπτωση;
Και τα δύο παραπάνω! Δλδ και το NAT πρέπει να ρυθμίσετε, αλλά και το firewall.
Αν η εφαρμογή χρειάζεται προσπέλαση στις τοπικές θύρες ΧΧΧ και ΥΥΥ τι γίνεται;
Θα κάνετε ότι χρειάζεται πρώτα για τη μία θύρα και μετά για τη δεύτερη. Το ίδιο αν υπάρχει και τρίτη και τέταρτη κτλ.
Αν η εφαρμογή χρειάζεται προσπέλαση στις τοπικές θύρες από ΧΧΧ έως ΥΥΥ τι γίνεται; Θα τις βάλω μία-μία;
Σε πολλούς firewalls-routers μπορείτε να δώσετε περιοχή τιμών, οπότε θα κάνετε μία φορά μόνο τη δουλειά.
Ο router μου έχει firewall ρυθμισμένο να επιτρέπει εξερχόμενες συνδέσεις, αλλά να μπλοκάρει τις εισερχόμενες. Όταν πάω να κάνω FTP από κάποιο server, συνδέομαι αλλά δεν μπορώ να κατεβάσω τίποτα. Τι φταίει;
Καλωσήρθατε στον κόσμο των ΝΑΤ/firewall-εχθρικών εφαρμογών :) Το πρόβλημα με το FTP, αλλά και με πολλά άλλα πρωτόκολλα (Η.323, SIP, DirectPlay) είναι ότι χρησιμοποιούν εκτός από μία εξερχόμενη σύνδεση (την οποία ο firewall με την ρύθμιση της ερώτησης θα επιτρέψει) και μία εισερχόμενη για την καθεαυτού μεταφορά αρχείων ή για τη μεταφορά φωνής (H.323, SIP) κτλ.
Ε, και λοιπόν; Δεν μπορώ να ανοίξω απλά την απαιτούμενη θύρα και ώστε να επιτραπεί αυτή η εισερχόμενη κίνηση;
Δυστυχώς όχι, γιατί η τοπική θύρα μεταβάλλεται κάθε φορά! Τη μία μπορεί να είναι η 2000, την άλλη η 45000 κτλ. Στο FTP λ.χ. η εισερχόμενη σύνδεση θα χρησιμοποιεί κάποιο τυχαίο port > 1024 κάθε φορά.
Ευτυχώς δεν έχω firewall, μόνο NAT. Οπότε δε θα έχω αυτό το πρόβλημα, σωστά;
Λάθος. Το πρόβλημα υφίσταται και στο firewall και στο NAT. Υπάρχουν όμως λύσεις.
Τι λύσεις;
Καταρχήν υπάρχουν έξυπνα firewalls/NAT τα οποία έχουν protocol inspectors, ένα για κάθε "δύσκολο" πρωτόκολλο που υποστηρίζουν. Έτσι, αν ένας router έχει FTP protocol inspector, τότε παρακολουθεί την εξερχόμενη κίνηση FTP και αν δει ότι πρόκειται να σκάσει μύτη εισερχόμενη κίνηση, αυτόματα ρυθμίζει το firewall/ΝΑΤ ώστε να την επιτρέψει. Μόνο όμως για τη διάρκεια της συνεδρίας FTP και μόνο για συγκεκριμένη θύρα.
Καλό ακούγεται! Υπάρχουν και άλλοι protocol inspectors εκτός από FTP;
Βέβαια, υπάρχουν για IRC DCC, H.323, SIP κτλ
Καλά όλα αυτά, αλλά έχω μία εφαρμογή με ένα τέτοιο δύσκολο πρωτόκολλο ΧΧΧ, στο οποίο ανοίγονται δυναμικά θύρες που αλλάζουν κάθε φορά. Πως δοκιμάζω αν ο δικός μου router έχει στο firewall/NAT protocol inspector για το πρωτόκολλο ΧΧΧ που με ενδιαφέρει;
Μέσω "δοκιμής και σφάλματος"! ;) Δοκιμάστε την εφαρμογή σας και αν δουλέψει, κατά πάσα πιθανότητα ο router σας έχει XXX protocol inspector.
Δοκίμασα και δε δουλεύει δυστυχώς. Ατύχησα;
Όχι ακόμα, υπάρχουν 1-2 πράγματα που μπορείτε να κάνετε.
Το απλούστερο όλων είναι να δείτε μήπως η εφαρμογή σας αν και χρησιμοποιεί δυναμικές θύρες, μπορεί να ρυθμιστεί εσωτερικά να χρησιμοποιεί μία συγκεκριμένη περιοχή τιμών. Λ.χ. από 9000 έως 9010. Aν είναι έτσι κάνετε τη ρύθμιση αυτή στην εφαρμογή και μετά συνεχίζετε όπως παραπάνω, σαν η εφαρμογή δλδ να χρησιμοποιούσε συγκεκριμένες σταθερές θύρες. Παράδειγμα είναι το γνωστό mIRC, στο οποίο οι μεταφορές αρχείων (DCC) μπορούν να ρυθμιστούν να χρησιμοποιούν ports από συγκεκριμένη περιοχή τιμών.
Ή ενδεχομένως η εφαρμογή να μπορεί να ρυθμιστεί ώστε να χρησιμοποιεί μόνο εξερχόμενες κλήσεις.
Χαρακτηριστικό παράδειγμα είναι το FTP, όπου ζητώντας να συνδεθούμε με λειτουργία passive οι συνδέσεις μας θα είναι μόνο εξερχόμενες.
Δυστυχώς η εφαρμογή μου δεν έχει τέτοια δυνατότητα...
Υπάρχουν μερικές ακόμα τεχνολογίες που μπορεί να βοηθήσουν. Αν για παράδειγμα η εφαρμογή και το λειτουργικό σύστημα του υπολογιστή μας χρησιμοποιούν την τεχνολογία UPnP και αυτή, επιπρόσθετα υποστηρίζεται από τον router μας, τότε ενεργοποιώντας την στον router, πρακτικά η ίδια η εφαρμογή θα του δίνει οδηγίες για το τι θα ανοίξει στο firewall και ποια θύρα κάθε φορά θα πρέπει να κάνει port mapping.
Έχω διαβάσει όμως ότι το UPnP αποτελεί τρύπα ασφαλείας, ισχύει αυτό;
Ισχύει, με την έννοια ότι αν ένα κακόβουλο πρόγραμμα καταφέρει να βρεθεί να εκτελείται μέσα στο δικό σας υπολογιστή, τότε μπορεί να "τηλεχειριστεί" το router σας, για να επιτρέχει εισερχόμενη κίνηση, η οποία φυσιολογικά δε θα περνούσε.
Αν και μόνο αν το εσωτερικό σας δίκτυο είναι ασφαλές, τότε το UPnP αποτελεί πλεονέκτημα: θύρες ανοίγονται και κλείνονται δυναμικά. Δεν παραμένουν μόνιμα δλδ κάποιες θύρες ανοικτές! Επιπρόσθετα, είναι πολλές πλέον οι εφαρμογές που εκμεταλλεύονται το UPnP (ΜSN/XP Messenger, παιχνίδια που χρησιμοποιούν DirectPlay, P2P προγράμματα όπως eMule/Azureus/μTorrent, προγράμματα και ATA για Voip κτλ).
Ούτε UPnP υπάρχει... Κάτι άλλο;
Η λύση που μένει είναι για το μεν ΝΑΤ να προωθήσετε όλα τα ports από 1024-65535, για το δε firewall να ανοίξετε την εισερχόμενη κίνηση για αυτά τα ports.
Υπάρχουν σε ορισμένους firewalls και τα "Triggers" πάντως. "Trigger" σημαίνει σκανδάλη. Ρυθμίζετε ένα trigger λέγοντας ότι "όποτε δεις εξερχόμενη κίνηση που μπορεί να υποδηλώνει ότι ξεκινάω δουλειά με ένα δύσκολο πρωτόκολλο, άνοιξε όλες τις θύρες 1024-65535". Κάπως καλύτερη κατάσταση δλδ.
Γιατί από τότε που ενεργοποίησα το firewall το σερφάρισμα έγινε αργό;
Ρίξτε μια ματιά στα αρχεία καταγραφής (logs) του firewall. Μήπως βλέπετε κάτι που να το χαρακτηρίζει attack απο το δικό σας εσωτερικό ip σε χ.χ.χ.χ:80;
Αν ναί τότε έχει να κάνει με το πόσες ταυτόχρονες συνδέσεις ανοίγει ο browser σας, και το firewall το βλέπει σαν απόπειρα "DDoS attack" (μίας μορφής επίθεσης δλδ). Για να το αποφύγετε πρέπει να ρυθμίσετε το firewall σας ώστε να είναι πιο "ανεκτικό" ως προς το πόσες συνδέσεις θεωρεί ότι αποτελούν επίθεση.
Τα έχω διαβάσει όλα αυτά, αλλά ακόμα δεν ξέρω τι να κάνω με το ΧΥΖ firewall για την ΑΒC δουλειά;
Εχμ, ψάξατε; Τί;;;; ΔΕΝ ψάξατε; Οι ειδικοί σας περιμένουν στην ομάδα συζητήσεων για firewalls (http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=comp.security.firewalls). 99% θα βρείτε εκεί αυτό που ψάχνετε!
Μπορώ με μια ματιά να αυτή τη στιγμή πόσο έντονη είναι η εχθρική δραστηριότητα στο δίκτυο;
Και βέβαια. Υπάρχουν "δείκτες επισφαλούς δραστηριότητας" στο δίκτυο. Αυτή η δραστηριότητα κατά 99,99% οφείλεται σε μολυσμένα συστήματα, τα οποία προσπαθούν να μολύνουν και άλλα. Μερικοί τέτοιοι δείκτες από αξιόπιστες πηγές, δίνονται παρακάτω, όπου φυσικά απεικονίζεται το τωρινό/τρέχων επίπεδο:
http://isc.sans.org/images/status.gif (http://isc.sans.org)
EDIT: Ευχαριστίες προς όλους για τα σχόλιά τους στο FAQ :)