Δεν είναι μυστικό ότι ο έλεγχος του αποκλεισμού στη λίστα των απαγορευμένων πληροφοριών στη Ρωσία παρακολουθείται από το αυτοματοποιημένο σύστημα "Inspector". Το πώς λειτουργεί γράφεται καλά εδώ σε αυτό , φωτογραφία από το ίδιο μέρος:
Εγκαθίσταται απευθείας στον πάροχο :
Η ενότητα "Agent Inspector" είναι ένα δομικό στοιχείο του αυτοματοποιημένου συστήματος "Inspector" (AS "Inspector"). Αυτό το σύστημα έχει σχεδιαστεί για να παρακολουθεί τη συμμόρφωση των τηλεπικοινωνιακών φορέων με τις απαιτήσεις περιορισμού πρόσβασης στο πλαίσιο των διατάξεων που θεσπίζονται από τα άρθρα 15.1-15.4 του ομοσπονδιακού νόμου της 27ης Ιουλίου 2006 αριθ. ”
Ο κύριος σκοπός της δημιουργίας του AS "Revizor" είναι να εξασφαλιστεί η παρακολούθηση της συμμόρφωσης των τηλεπικοινωνιακών φορέων με τις απαιτήσεις που ορίζονται από τα άρθρα 15.1-15.4 του ομοσπονδιακού νόμου της 27ης Ιουλίου 2006 αριθ. Προστασία» όσον αφορά τον εντοπισμό γεγονότων πρόσβασης σε απαγορευμένες πληροφορίες και τη λήψη υποστηρικτικού υλικού (δεδομένων) σχετικά με παραβιάσεις για τον περιορισμό της πρόσβασης σε απαγορευμένες πληροφορίες.
Λαμβάνοντας υπόψη το γεγονός ότι, αν όχι όλοι, τότε πολλοί πάροχοι έχουν εγκαταστήσει αυτήν τη συσκευή, θα έπρεπε να υπήρχε ένα μεγάλο δίκτυο ανιχνευτών beacon όπως και ακόμη περισσότερα, αλλά με κλειστή πρόσβαση. Ωστόσο, ένας φάρος είναι ένας φάρος για να στέλνει σήματα προς όλες τις κατευθύνσεις, αλλά τι γίνεται αν τα πιάσουμε και δούμε τι πιάσαμε και πόσα;
Πριν μετρήσουμε, ας δούμε γιατί αυτό μπορεί να είναι ακόμη δυνατό.
Λίγο θεωρίας
Οι πράκτορες ελέγχουν τη διαθεσιμότητα ενός πόρου, μεταξύ άλλων μέσω αιτημάτων HTTP(S), όπως αυτό:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /somepage HTTP/1.1"
TCP, 80 > 14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"
TCP, 14678 > 80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80 > 14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678 > 80, "[ACK] Seq=72 Ack=480"
Εκτός από το ωφέλιμο φορτίο, το αίτημα αποτελείται επίσης από μια φάση εγκατάστασης σύνδεσης: ανταλλαγή SYN и SYN-ACKκαι φάσεις ολοκλήρωσης της σύνδεσης: FIN-ACK.
Το μητρώο απαγορευμένων πληροφοριών περιέχει διάφορους τύπους αποκλεισμού. Προφανώς, εάν ένας πόρος αποκλειστεί από τη διεύθυνση IP ή το όνομα τομέα, τότε δεν θα δούμε κανένα αίτημα. Αυτοί είναι οι πιο καταστροφικοί τύποι αποκλεισμού, οι οποίοι οδηγούν στη μη πρόσβαση όλων των πόρων σε μία διεύθυνση IP ή όλων των πληροφοριών σε έναν τομέα. Υπάρχει επίσης ένας τύπος αποκλεισμού "κατά διεύθυνση URL". Σε αυτήν την περίπτωση, το σύστημα φιλτραρίσματος πρέπει να αναλύσει την κεφαλίδα αιτήματος HTTP για να καθορίσει τι ακριβώς θα αποκλείσει. Και πριν από αυτό, όπως φαίνεται παραπάνω, θα πρέπει να υπάρχει μια φάση δημιουργίας σύνδεσης που μπορείτε να προσπαθήσετε να παρακολουθήσετε, καθώς πιθανότατα το φίλτρο θα τη χάσει.
Για να το κάνετε αυτό, πρέπει να επιλέξετε έναν κατάλληλο δωρεάν τομέα με τον τύπο αποκλεισμού «URL» και HTTP για να διευκολύνετε τη λειτουργία του συστήματος φιλτραρίσματος, κατά προτίμηση εγκαταλειμμένου από καιρό, για να ελαχιστοποιήσετε την είσοδο ξένης κίνησης εκτός από τους πράκτορες. Αυτή η εργασία αποδείχθηκε ότι δεν ήταν καθόλου δύσκολη· υπάρχουν πάρα πολλοί δωρεάν τομείς στο μητρώο απαγορευμένων πληροφοριών και για κάθε γούστο. Επομένως, ο τομέας αγοράστηκε και συνδέθηκε με διευθύνσεις IP σε ένα VPS που εκτελείται tcpdump και άρχισε η καταμέτρηση.
Έλεγχος "Ελεγκτών"
Περίμενα να βλέπω περιοδικές εκρήξεις αιτημάτων, που κατά τη γνώμη μου θα έδειχναν ελεγχόμενη δράση. Είναι αδύνατο να πω ότι δεν το είδα καθόλου, αλλά σίγουρα δεν υπήρχε σαφής εικόνα:
Κάτι που δεν προκαλεί έκπληξη, ακόμη και σε έναν τομέα που δεν χρειάζεται κανείς και σε μια IP που δεν χρησιμοποιήθηκε ποτέ, θα υπάρχει απλώς ένας τόνος ανεπιθύμητων πληροφοριών, όπως είναι το σύγχρονο Διαδίκτυο. Αλλά ευτυχώς, χρειαζόμουν μόνο αιτήματα για μια συγκεκριμένη διεύθυνση URL, έτσι όλοι οι σαρωτές και οι κροτίδες κωδικών πρόσβασης βρέθηκαν γρήγορα. Επίσης, ήταν αρκετά εύκολο να καταλάβουμε πού βασίστηκε η πλημμύρα με τη μάζα παρόμοιων αιτημάτων. Στη συνέχεια, συγκέντρωσα τη συχνότητα εμφάνισης των διευθύνσεων IP και πέρασα χειροκίνητα ολόκληρη την κορυφή, διαχωρίζοντας όσους την έχασαν στα προηγούμενα στάδια. Επιπλέον, έκοψα όλες τις πηγές που στάλθηκαν σε ένα πακέτο, δεν υπήρχαν πια πολλές από αυτές. Και αυτό έγινε:
Μια μικρή λυρική παρέκβαση. Λίγο περισσότερο από μια μέρα αργότερα, ο πάροχος φιλοξενίας μου έστειλε μια επιστολή με μάλλον απλοποιημένο περιεχόμενο, λέγοντας ότι οι εγκαταστάσεις σας περιέχουν έναν πόρο από τη λίστα απαγορευμένων RKN, επομένως είναι αποκλεισμένος. Στην αρχή νόμιζα ότι ο λογαριασμός μου ήταν αποκλεισμένος, δεν ήταν έτσι. Τότε σκέφτηκα ότι απλώς με προειδοποιούσαν για κάτι που ήξερα ήδη. Αλλά αποδείχθηκε ότι ο οικοδεσπότης άνοιξε το φίλτρο του μπροστά από τον τομέα μου και ως αποτέλεσμα μπήκα σε διπλό φιλτράρισμα: από τους παρόχους και από τον οικοδεσπότη. Το φίλτρο πέρασε μόνο τα άκρα των αιτημάτων: FIN-ACK и RST αποκοπή όλων των HTTP σε απαγορευμένη διεύθυνση URL. Όπως μπορείτε να δείτε από το παραπάνω γράφημα, μετά την πρώτη μέρα άρχισα να λαμβάνω λιγότερα δεδομένα, αλλά παρόλα αυτά τα έλαβα, τα οποία ήταν αρκετά για την εργασία μέτρησης των πηγών αιτημάτων.
Φτανω στο σημειο. Κατά τη γνώμη μου, δύο εκρήξεις είναι καθαρά ορατές κάθε μέρα, η πρώτη μικρότερη, μετά τα μεσάνυχτα ώρα Μόσχας, η δεύτερη πιο κοντά στις 6 το πρωί με ουρά μέχρι τις 12 το μεσημέρι. Η αιχμή δεν συμβαίνει ακριβώς την ίδια στιγμή. Αρχικά, ήθελα να επιλέξω διευθύνσεις IP που έπεσαν μόνο σε αυτές τις περιόδους και καθεμία σε όλες τις περιόδους, με βάση την υπόθεση ότι οι έλεγχοι από τους πράκτορες εκτελούνται περιοδικά. Αλλά μετά από προσεκτική εξέταση, ανακάλυψα γρήγορα περιόδους που εμπίπτουν σε άλλα διαστήματα, με άλλες συχνότητες, έως και ένα αίτημα κάθε ώρα. Μετά σκέφτηκα τις ζώνες ώρας και ότι ίσως είχε να κάνει με αυτές, και μετά σκέφτηκα ότι γενικά το σύστημα μπορεί να μην συγχρονίζεται παγκοσμίως. Επιπλέον, το NAT πιθανότατα θα παίξει κάποιο ρόλο και ο ίδιος Agent μπορεί να κάνει αιτήματα από διαφορετικές δημόσιες IP.
Επειδή ο αρχικός μου στόχος δεν ήταν ακριβώς, μέτρησα όλες τις διευθύνσεις που έπεσα σε μια εβδομάδα και πήρα - 2791. Ο αριθμός των περιόδων σύνδεσης TCP που δημιουργούνται από μία διεύθυνση είναι κατά μέσο όρο 4, με διάμεσο 2. Κορυφαίες περιόδους σύνδεσης ανά διεύθυνση: 464, 231, 149, 83, 77. Το μέγιστο από το 95% του δείγματος είναι 8 περίοδοι σύνδεσης ανά διεύθυνση. Η διάμεσος δεν είναι πολύ υψηλή, επιτρέψτε μου να σας υπενθυμίσω ότι το γράφημα δείχνει μια ξεκάθαρη ημερήσια περιοδικότητα, επομένως θα μπορούσε κανείς να περιμένει κάτι περίπου 4 με 8 σε 7 ημέρες. Εάν πετάξουμε όλες τις συνεδρίες που πραγματοποιούνται μία φορά, θα λάβουμε διάμεσο ίσο με 5. Αλλά δεν θα μπορούσα να τις αποκλείσω με βάση ένα σαφές κριτήριο. Αντίθετα, ένας τυχαίος έλεγχος έδειξε ότι σχετίζονται με αιτήματα για απαγορευμένο πόρο.
Οι διευθύνσεις είναι διευθύνσεις, αλλά στο Διαδίκτυο, αυτόνομα συστήματα - AS, τα οποία αποδείχθηκαν πιο σημαντικά 1510, κατά μέσο όρο 2 διευθύνσεις ανά AS με διάμεσο 1. Κορυφαίες διευθύνσεις ανά AS: 288, 77, 66, 39, 27. Το μέγιστο 95% του δείγματος είναι 4 διευθύνσεις ανά AS. Εδώ αναμένεται ο διάμεσος - ένας Πράκτορας ανά πάροχο. Περιμένουμε επίσης την κορυφή - υπάρχουν μεγάλοι παίκτες σε αυτήν. Σε ένα μεγάλο δίκτυο, οι Agents θα πρέπει πιθανώς να βρίσκονται σε κάθε περιοχή της παρουσίας του χειριστή και μην ξεχνάτε το NAT. Αν το πάρουμε ανά χώρα, τα μέγιστα θα είναι: 1409 - RU, 42 - UA, 23 - CZ, 36 από άλλες περιοχές, όχι RIPE NCC. Αιτήματα εκτός Ρωσίας προσελκύουν την προσοχή. Αυτό μπορεί πιθανώς να εξηγηθεί από σφάλματα γεωγραφικής τοποθεσίας ή σφάλματα μητρώου κατά τη συμπλήρωση δεδομένων. Ή το γεγονός ότι μια ρωσική εταιρεία μπορεί να μην έχει ρωσικές ρίζες ή να έχει ξένη αντιπροσωπεία γιατί είναι πιο εύκολο, κάτι που είναι φυσικό όταν έχεις να κάνεις με έναν ξένο οργανισμό RIPE NCC. Κάποιο μέρος είναι αναμφισβήτητα περιττό, αλλά είναι αξιόπιστα δύσκολο να το διαχωριστεί, καθώς ο πόρος είναι υπό αποκλεισμό και από τη δεύτερη ημέρα υπό διπλό αποκλεισμό και οι περισσότερες συνεδρίες είναι απλώς μια ανταλλαγή πολλών πακέτων υπηρεσιών. Ας συμφωνήσουμε ότι αυτό είναι ένα μικρό κομμάτι.
Αυτοί οι αριθμοί μπορούν ήδη να συγκριθούν με τον αριθμό των παρόχων στη Ρωσία. άδειες για "Υπηρεσίες επικοινωνίας για μετάδοση δεδομένων, εξαιρουμένης της φωνής" - 6387, αλλά αυτή είναι μια πολύ υψηλή εκτίμηση από πάνω, δεν ισχύουν όλες αυτές οι άδειες ειδικά για παρόχους Διαδικτύου που πρέπει να εγκαταστήσουν έναν Agent. Στη ζώνη RIPE NCC υπάρχει παρόμοιος αριθμός AS που είναι εγγεγραμμένοι στη Ρωσία - 6230, εκ των οποίων δεν είναι όλοι πάροχοι. και έλαβε 3940 εταιρείες το 2017, και αυτό είναι μάλλον μια εκτίμηση από πάνω. Σε κάθε περίπτωση, έχουμε δυόμιση φορές λιγότερο αριθμό φωτιζόμενων AS. Αλλά εδώ αξίζει να καταλάβουμε ότι το AS δεν είναι αυστηρά ίσο με τον πάροχο. Ορισμένοι πάροχοι δεν έχουν δικό τους AS, κάποιοι έχουν περισσότερα από ένα. Αν υποθέσουμε ότι όλοι έχουν ακόμα Αντιπροσώπους, τότε κάποιος φιλτράρει πιο έντονα από άλλους, έτσι ώστε τα αιτήματά του να μην διακρίνονται από τα σκουπίδια, αν τους φτάνουν καθόλου. Αλλά για μια πρόχειρη εκτίμηση είναι αρκετά ανεκτό, ακόμα κι αν κάτι χάθηκε λόγω της παράβλεψής μου.
Σχετικά με το DPI
Παρά το γεγονός ότι ο πάροχος φιλοξενίας μου ενεργοποίησε το φίλτρο του ξεκινώντας από τη δεύτερη μέρα, με βάση τις πληροφορίες από την πρώτη μέρα μπορούμε να συμπεράνουμε ότι ο αποκλεισμός λειτουργεί με επιτυχία. Μόνο 4 πηγές μπόρεσαν να περάσουν και να έχουν ολοκληρώσει πλήρως τις συνεδρίες HTTP και TCP (όπως στο παραπάνω παράδειγμα). Άλλα 460 μπορούν να σταλούν GET, αλλά η συνεδρία τερματίζεται αμέσως από RST. Δώσε προσοχή στο TTL:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80 > 14678, "[ACK] Seq=1 Ack=294"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"
TTL 50, TCP, 14678 > 80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80 > 14678, "[FIN, ACK] Seq=171 Ack=295"
TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"
#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
Οι παραλλαγές αυτού μπορεί να είναι διαφορετικές: λιγότερες RST ή περισσότερες αναμεταδόσεις - εξαρτάται επίσης από το τι στέλνει το φίλτρο στον κόμβο πηγής. Σε κάθε περίπτωση, αυτό είναι το πιο αξιόπιστο πρότυπο, από το οποίο φαίνεται ξεκάθαρα ότι ήταν ένας απαγορευμένος πόρος που ζητήθηκε. Επιπλέον, υπάρχει πάντα μια απάντηση που εμφανίζεται στη συνεδρία με TTL μεγαλύτερο από ό,τι σε προηγούμενα και επόμενα πακέτα.
Δεν μπορείς να το δεις ούτε από τα υπόλοιπα GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
Ή έτσι:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
#Опять фильтр, много раз
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
Η διαφορά είναι σίγουρα ορατή TTL αν προέρχεται κάτι από το φίλτρο. Αλλά συχνά δεν μπορεί να φτάσει τίποτα:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...
Ή έτσι:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Прошло несколько секунд без трафика
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
Και όλα αυτά επαναλαμβάνονται και επαναλαμβάνονται και επαναλαμβάνονται, όπως φαίνεται στο γράφημα, περισσότερες από μία φορές, κάθε μέρα.
Σχετικά με το IPv6
Τα καλά νέα είναι ότι υπάρχει. Μπορώ να πω με αξιοπιστία ότι τα περιοδικά αιτήματα σε έναν απαγορευμένο πόρο προκύπτουν από 5 διαφορετικές διευθύνσεις IPv6, η οποία είναι ακριβώς η συμπεριφορά των Agents που περίμενα. Επιπλέον, μία από τις διευθύνσεις IPv6 δεν εμπίπτει στο φιλτράρισμα και βλέπω μια πλήρη περίοδο λειτουργίας. Από δύο ακόμη είδα μόνο μία ημιτελή συνεδρία, η μία από τις οποίες διεκόπη RST από το φίλτρο, δεύτερο σε χρόνο. Συνολικό ποσό 7.
Δεδομένου ότι είναι λίγες οι διευθύνσεις, τις μελέτησα όλες αναλυτικά και αποδείχτηκε ότι υπάρχουν μόνο 3 πάροχοι εκεί, μπορούν να τους χειροκροτήσουν! Μια άλλη διεύθυνση είναι το cloud hosting στη Ρωσία (δεν φιλτράρει), μια άλλη είναι ένα ερευνητικό κέντρο στη Γερμανία (υπάρχει φίλτρο, πού;). Αλλά γιατί ελέγχουν τη διαθεσιμότητα των απαγορευμένων πόρων σε ένα χρονοδιάγραμμα είναι μια καλή ερώτηση. Οι υπόλοιποι δύο έκαναν ένα αίτημα και βρίσκονται εκτός Ρωσίας, και το ένα είναι φιλτραρισμένο (κατά τη μεταφορά, τελικά;).
Το Blocking και οι Agents αποτελούν μεγάλο εμπόδιο για το IPv6, η υλοποίηση του οποίου δεν προχωρά πολύ γρήγορα. Είναι λυπηρό. Όσοι έλυσαν αυτό το πρόβλημα μπορούν να είναι πλήρως περήφανοι για τον εαυτό τους.
Εν κατακλείδι
Δεν προσπάθησα για 100% ακρίβεια, συγχωρέστε με για αυτό, ελπίζω κάποιος να θέλει να επαναλάβει αυτό το έργο με μεγαλύτερη ακρίβεια. Ήταν σημαντικό για μένα να καταλάβω αν αυτή η προσέγγιση θα λειτουργούσε κατ' αρχήν. Η απάντηση είναι ναι. Τα ληφθέντα στοιχεία, ως πρώτη προσέγγιση, νομίζω ότι είναι αρκετά αξιόπιστα.
Τι άλλο θα μπορούσε να είχε γίνει και αυτό που ήμουν πολύ τεμπέλης να κάνω ήταν να μετρήσω αιτήματα DNS. Δεν φιλτράρονται, αλλά επίσης δεν παρέχουν μεγάλη ακρίβεια αφού λειτουργούν μόνο για τον τομέα και όχι για ολόκληρη τη διεύθυνση URL. Η συχνότητα πρέπει να είναι ορατή. Εάν το συνδυάσετε με αυτό που είναι ορατό απευθείας στα ερωτήματα, αυτό θα σας επιτρέψει να ξεχωρίσετε τα περιττά και να λάβετε περισσότερες πληροφορίες. Είναι ακόμη δυνατό να προσδιοριστούν οι προγραμματιστές του DNS που χρησιμοποιούν οι πάροχοι και πολλά άλλα.
Δεν περίμενα ότι ο οικοδεσπότης θα περιλάμβανε επίσης το δικό του φίλτρο για το VPS μου. Ίσως αυτό είναι κοινή πρακτική. Στο τέλος, το RKN στέλνει ένα αίτημα διαγραφής του πόρου στον hoster. Αλλά αυτό δεν με εξέπληξε και κατά κάποιο τρόπο λειτούργησε ακόμη και προς όφελός μου. Το φίλτρο λειτούργησε πολύ αποτελεσματικά, αποκόπτοντας όλα τα σωστά αιτήματα HTTP σε μια απαγορευμένη διεύθυνση URL, αλλά όχι τα σωστά που είχαν προηγουμένως περάσει από το φίλτρο των παρόχων έφτασαν σε αυτά, αν και μόνο με τη μορφή καταλήξεων: FIN-ACK и RST - μείον για μείον και σχεδόν αποδείχθηκε ένα συν. Παρεμπιπτόντως, το IPv6 δεν φιλτραρίστηκε από τον κεντρικό υπολογιστή. Φυσικά, αυτό επηρέασε την ποιότητα του συλλεγόμενου υλικού, αλλά παρόλα αυτά επέτρεψε να δούμε τη συχνότητα. Αποδείχθηκε ότι αυτό είναι ένα σημαντικό σημείο κατά την επιλογή ενός ιστότοπου για την τοποθέτηση πόρων· μην ξεχάσετε να ενδιαφερθείτε για το θέμα της οργάνωσης εργασιών με τη λίστα των απαγορευμένων τοποθεσιών και των αιτημάτων από το RKN.
Στην αρχή συνέκρινα τον ΑΣ «Επιθεωρητή» με . Αυτή η σύγκριση είναι αρκετά δικαιολογημένη και ένα μεγάλο δίκτυο Αντιπροσώπων μπορεί να είναι επωφελές. Για παράδειγμα, ο προσδιορισμός της ποιότητας της διαθεσιμότητας πόρων από διαφορετικούς παρόχους σε διαφορετικά μέρη της χώρας. Μπορείτε να υπολογίσετε καθυστερήσεις, μπορείτε να δημιουργήσετε γραφήματα, μπορείτε να τα αναλύσετε όλα και να δείτε τις αλλαγές που συμβαίνουν τόσο σε τοπικό όσο και σε παγκόσμιο επίπεδο. Αυτός δεν είναι ο πιο άμεσος τρόπος, αλλά οι αστρονόμοι χρησιμοποιούν "τυποποιημένα κεριά", γιατί να μην χρησιμοποιούν τους πράκτορες; Γνωρίζοντας (έχοντας βρει) την τυπική συμπεριφορά τους, μπορείτε να προσδιορίσετε τις αλλαγές που συμβαίνουν γύρω τους και πώς αυτό επηρεάζει την ποιότητα των παρεχόμενων υπηρεσιών. Και ταυτόχρονα, δεν χρειάζεται να τοποθετήσετε ανεξάρτητα ανιχνευτές στο δίκτυο· η Roskomnadzor τους έχει ήδη εγκαταστήσει.
Ένα άλλο σημείο που θέλω να θίξω είναι ότι κάθε εργαλείο μπορεί να είναι ένα όπλο. Το AS "Inspector" είναι ένα κλειστό δίκτυο, αλλά οι Πράκτορες παραδίδουν τους πάντες στέλνοντας αιτήματα για όλους τους πόρους από την απαγορευμένη λίστα. Η κατοχή ενός τέτοιου πόρου δεν παρουσιάζει κανένα απολύτως πρόβλημα. Συνολικά, οι πάροχοι μέσω των Agents, άθελά τους, λένε πολλά περισσότερα για το δίκτυό τους από όσα πιθανώς αξίζει τον κόπο: τύποι DPI και DNS, τοποθεσία του Agent (κεντρικός κόμβος και δίκτυο υπηρεσιών;), δείκτες δικτύου καθυστερήσεων και απωλειών - και αυτό είναι μόνο το πιο προφανές. Ακριβώς όπως κάποιος μπορεί να παρακολουθεί τις ενέργειες των Agents για να βελτιώσει τη διαθεσιμότητα των πόρων τους, κάποιος μπορεί να το κάνει αυτό για άλλους σκοπούς και δεν υπάρχουν εμπόδια σε αυτό. Το αποτέλεσμα είναι ένα όργανο διπλής όψης και πολύ πολύπλευρο, αυτό μπορεί να το δει ο καθένας.
Πηγή: www.habr.com