You are on page 1of 25

ΕΠΙΧΟΡΗΓΗΣΗ ΦΟΡΕΩΝ ΠΑΝΕΛΛΗΝΙΟΥ ΣΧΟΛΙΚΟΥ ΔΙΚΤΥΟΥ ΓΙΑ ΤΗΝ

ΥΠΟΣΤΗΡΙΞΗ ΧΡΗΣΤΩΝ ΚΑΙ ΗΛΕΚΤΡΟΝΙΚΩΝ ΥΠΗΡΕΣΙΩΝ ΠΑΝΕΛΛΗΝΙΟΥ


ΣΧΟΛΙΚΟΥ ΔΙΚΤΥΟΥ ΓΙΑ ΤΟ ΕΤΟΣ 2020

ΠΕ 2.9 Έλεγχος περιεχομένου web

Αναφορά 1-7-2020-31-12-2020

Μαρίνος Δημολιάνης, mdimolinanis@netmode.ntua.gr

Δημήτρης Καλογεράς, dkalo@noc.ntua.gr

Ερευνητικό Πανεπιστημιακό Ινστιτούτο Συστημάτων Επικοινωνιών και Υπολογιστών


Περιεχόμενα
1 Γενικά .......................................................................................................................................................... 3
2 Content Filtering - Εκτίμηση Πόρων ........................................................................................................... 4
2.1 Αιτήματα HTTP .................................................................................................................................... 4
2.2 Αναλογία κίνησης HTTP/HTTPS .......................................................................................................... 5
2.3 Εκτίμηση υπολογιστικών πόρων (απαιτήσεις σε CPU) ...................................................................... 5
2.4 Εκτίμηση δικτυακών πόρων (απαιτήσεις σε bandwidth) ................................................................... 7
2.5 Εκτίμηση Αιτημάτων ανά Σχολική Μονάδα/Τύπο Διασύνδεσης ....................................................... 7
2.6 Συμπεράσματα .................................................................................................................................... 7
3 Προστασία ιστοτόπων μονάδων και χρηστών ........................................................................................... 9
3.1 Δικτυακή τοπολογία και Ζώνες λειτουργίας .................................................................................... 10
3.2 Fortimanager και Fortianalyzer......................................................................................................... 12
3.3 Δημιουργία Πολιτικής προστασίας ................................................................................................... 13
3.4 Αποτελέσματα προστασίας για το https://schoolpress.sch.gr......................................................... 18
4 Στοιχεία Διαθεσιμότητας.......................................................................................................................... 21
4.1 Στατιστικά Στοιχεία Χρήσης .............................................................................................................. 21
5 Επιπρόσθετες Ενέργειες ........................................................................................................................... 22
6 Δελτία βλαβών ......................................................................................................................................... 23
7 Στοιχεία Χρήσης Υπηρεσίας ..................................................................................................................... 24
8 Στοιχεία Ανάλυσης επιθέσεων από Fortianalyzer ................................................................................... 25
ΠΕ 2.9 Έλεγχος περιεχομένου web

1 Γενικά
Το Πανελλήνιο Σχολικό Δίκτυο (ΠΣΔ) εξυπηρετεί τα σχολεία της επικράτειας όσον αφορά την προώθηση
δεδομένων των χρηστών του στο διαδίκτυο. Μία από τις βασικές υπηρεσίες που προσφέρονται είναι ο
έλεγχος περιεχομένου (content filtering), μέσω της οποίας αποκλείεται η πρόσβαση των χρηστών σε
κακόβουλους ιστότοπους, σε ιστότοπους πορνογραφικού υλικού, ιστότοπους με στοιχηματικές υπηρεσίες
κ.α. Στην τρέχουσα κατάσταση της υπηρεσίας αυτής ο έλεγχος περιεχομένου διεξάγεται σε δύο επίπεδα
(i) επίπεδο πρωτοκόλλου HTTP όπου ελέγχεται ο ιστότοπος που θέλει να αποκτήσει πρόσβαση ο χρήστης
και (ii) σε επίπεδο πρωτοκόλλου DNS με κατάλληλες ζώνες response policy zones (RPZ), όπου
φιλτράρονται τα αιτήματα των χρηστών βάσει του τομέα (domain) που ζητάνε να αντιστοιχίσουν σε
διεύθυνση IP.
Όπως έχει αναφερθεί και σε προηγούμενα παραδοτέα (π.χ. 2018), ένα από τα βασικότερα προβλήματα
που εντοπίζονται στη διαφανή έλεγχο περιεχομένου (transparent content filtering) είναι η αδυναμία
διαφανούς ελέγχου περιεχομένου κίνησης τύπου HTTPS. Οι περισσότερες πλέον ιστοσελίδες
χρησιμοποιούν το πρωτόκολλο HTTPS παρέχοντας στον τελικό χρήστη κρυπτογραφημένη επικοινωνία και
διαπιστευτήρια της εγκυρότητας του τελικού κόμβου.
Συνεπώς στόχος της παρούσας μελέτης είναι η εκτίμηση των πόρων που απαιτούνται για την αναβάθμιση
της τρέχουσας υπηρεσίας ελέγχου περιεχομένου για υποστήριξη και του πρωτοκόλλου
HTTPS. Παράλληλα με την μελέτη εκτίμησης πόρων θα παρατεθούν και εργαλεία προστασίας ιστοτόπων
με σκοπό το σχεδιασμό υπηρεσιών αναφορικά με τον περιορισμό κακόβουλης κίνησης προς ιστοτόπους
και χρήστες του ΠΣΔ.

3
ΠΕ 2.9 Έλεγχος περιεχομένου web

2 Content Filtering - Εκτίμηση Πόρων


Ένας από τους στόχους της παρούσας μελέτης είναι να εκτιμηθούν οι πόροι που απαιτούνται για να
εξυπηρετηθούν οι διάφορες σχολικές μονάδες και γενικότερα οι χρήστες του ΠΣΔ. Οι πόροι που
απαιτούνται για την εξυπηρέτηση της HTTPS κίνησης πρέπει να αντιστοιχιστούν με το πλήθος των HTTPS
αιτημάτων των χρηστών ανά δευτερόλεπτο, που αναμένονται να φτάνουν στην υπηρεσία για την
καλύτερη δυνατή εκτίμηση των πόρων. Με τα εργαλεία που έχουμε στην διάθεση μας αυτός ο αριθμός
δεν μπορεί να καθοριστεί ακριβώς αλλά μπορούμε να τον εκτιμήσουμε συσχετίζοντας το πλήθος των
αιτημάτων HTTP και την αναλογία δικτυακής κίνησης HTTP:HTTPS. Με αυτόν τον τρόπο μπορούμε να
εκτιμήσουμε το πλήθος των αιτημάτων HTTPS ανά δευτερόλεπτο που αναμένονται να δέχεται η υπηρεσία
ελέγχου περιεχομένου. Βάσει αυτής της εκτίμησης μπορούμε να προσεγγίσουμε και κατά αναλογία τους
απαιτούμενους υπολογιστικούς/δικτυακούς πόρους που απαιτούνται για την υποστήριξη της υπηρεσίας.
2.1 Αιτήματα HTTP
Για το πλήθος των αιτημάτων HTTP ανά δευτερόλεπτο που φθάνουν στην τρέχουσα αρχιτεκτονική
ελέγχου περιεχομένου του ΠΣΔ χρησιμοποιήσαμε τα στατιστικά που μας δίνονται από την ίδια την
υπηρεσία (συγκεκριμένα από το εργαλείο Calamaris που αναλύει δεδομένα τα οποία παράγονται από το
εργαλείο Squid). Από τα δεδομένα των cacheboxes για τους μήνες: Ιανουάριος, Φεβρουάριος, Μάρτιος,
Μάιος, Σεπτέμβριος και Οκτώβριος (αποκλείσαμε τους μήνες που τα σχολεία δεν ήταν υπό καθεστώς
φυσιολογικής λειτουργίας λόγω της πανδημίας COVID-19) υπολογίζουμε το top N% των αιτημάτων που
φθάνουν ανά δευτερόλεπτο στην υπηρεσία. Τα δεδομένα λήφθηκαν μόνο για τις ώρες αιχμής του
σχολικού δικτύου (08:00 - 14:00) καθώς σε αυτό το χρονικό διάστημα αναμένονται οι μέγιστες τιμές των
αιτημάτων ανά δευτερόλεπτο, που ενδιαφέρουν για την εκτίμηση του φόρτου. Οι τιμές 1 αυτές
παρουσιάζονται στο παρακάτω διάγραμμα:

Αιτήματα HTTP (top N%)


3500
Αιτήαμτα HTTP ανά δευτερόλεπτο

3000

2500

2000

1500

1000

500

0
90% 91% 92% 93% 94% 95% 96% 97% 98% 99%
Ποσοστό πλήθους αιτημάτων

1
Τα στατιστικά για τα αιτήματα HTTP καταγράφονται από το εργαλείο Squid σε επίπεδο ώρας, συνεπώς για την κατασκευή του
παραπάνω διαγράμματος έγινε αναγωγή σε δευτερόλεπτα.

4
ΠΕ 2.9 Έλεγχος περιεχομένου web

Παρατηρούμε ότι η τιμή 90% αντιστοιχεί περίπου σε 1000 αιτήματα ανά δευτερόλεπτο ενώ η τιμή top
99% σε 3000 αιτήματα ανά δευτερόλεπτο. Παρατηρήθηκε ιδιαίτερη αύξηση της κίνησης τον μήνα
Οκτώβριο με την οποία σχετίζονται και οι υψηλές τιμές για τα ποσοστά αυτά.
2.2 Αναλογία κίνησης HTTP/HTTPS

Όπως ήδη αναφέραμε, δεν μπορούμε να εξάγουμε ακριβώς τον αντίστοιχο αριθμό των HTTPS αιτημάτων
ανά δευτερόλεπτο για αυτό θα τον εκτιμήσουμε κατά προσέγγιση βάσει της αντιστοιχίας HTTP/HTTPS
κίνησης. Η βασική υπόθεση είναι το πλήθος των πακέτων-bytes που αντιστοιχεί σε αιτήματα HTTP θα
ακολουθεί παρόμοια κατανομή με το πλήθος των πακέτων-bytes που αντιστοιχεί σε αιτήματα HTTPS
και κατ' επέκταση και τα αντίστοιχα αιτήματα που θα φθάνουν στην υπηρεσία. Για να εξάγουμε αυτή
την αντιστοιχία HTTP/HTTPS χρησιμοποιούμε δεδομένα Netflow από τον κεντρικό δρομολογητή του ΠΣΔ.
Συγκεκριμένα χρησιμοποιούμε το εργαλείο Solarwinds Orion (nmc.att.sch.gr) που συλλέγει και αναλύει
δεδομένα NetFlow. Λαμβάνοντας δεδομένα για όλη την εισερχόμενη κίνηση, καταλήξαμε στις παρακάτω
αναλογίες όσων αφορά το πλήθος των HTTP και HTTPS πακέτων-bytes που εισέρχονται στο ΠΣΔ:

Ημερομηνία Συνολική Συνολική


Αναλογία Αναλογία
HTTP/HTTPS HTTP/HTTPS
πακέτων bytes

12/01/2021 08:00 - 14:00 58% 60%

Βάσει του παραπάνω πίνακα μπορούμε κατά προσέγγιση να θεωρήσουμε ότι στην χειρότερη
περίπτωση η αντιστοιχία πακέτων και bytes HTTPS:HTTP είναι κατά προσέγγιση 2:1. Επεκτείνοντας
αυτή την λογική όσον αφορά το πλήθος των αιτημάτων και θεωρώντας ότι το πλήθος των πακέτων/bytes
για τα HTTPS αιτήματα ακολουθεί κατανομή παρόμοια με το πλήθος των πακέτων στα HTTP αιτήματα
μπορούμε να επεκτείνουμε αυτόν το λόγο όσον αφορά και το πλήθος των αιτημάτων ανά δευτερόλεπτο.
Συνεπώς το αναμενόμενο πλήθος των HTTPS αιτημάτων θα είναι κατά προσέγγιση 2 φορές μεγαλύτερο
από τα HTTP αιτήματα το δευτερόλεπτο. Για παράδειγμα, χρησιμοποιώντας το 95th percentile1 (που
χρησιμοποιείται ευρέως για την κοστολόγηση υπηρεσιών) εκτιμάται η άφιξη 3134 HTTPS αιτημάτων το
δευτερόλεπτο.
Σημειώσεις/Παρατηρήσεις:
1. Συγκεκριμένα ασχοληθήκαμε με τα εισερχόμενα πακέτα του ΠΣΔ καθώς βάσει της
παραμετροποίησης του NetFlow (την τρέχουσα χρονική περίοδο), μπορούσαμε να εξάγουμε
συμπεράσματα μόνο για την εισερχόμενη κίνηση.
2.3 Εκτίμηση υπολογιστικών πόρων (απαιτήσεις σε CPU)

Οι υπολογιστικοί πόροι που απαιτούνται για την υποστήριξη της υπηρεσίας διαμεσολάβησης HTTPS δεν
μπορούν να εκτιμηθούν με ακρίβεια αφού σχετίζονται με ποικίλες επιλογές όσον αφορά την
υπολογιστική υποδομή:
 επιδόσεις υπολογιστικού κόμβου (server, virtual machine - VM)
 επιδόσεις επεξεργαστή
 δυνατότητες επεξεργαστή2

1
https://en.wikipedia.org/wiki/Percentile
2
https://en.wikipedia.org/wiki/AES_instruction_set

5
ΠΕ 2.9 Έλεγχος περιεχομένου web

Συνεπώς για την εκτίμηση των πόρων που απαιτούνται κατασκευάσαμε ένα σύγχρονο testbed
χρησιμοποιώντας εξυπηρετητές νέας γενιάς (DELL R730 με επεξεργαστή Intel Xeon E5-2620 v3 2.4GHz).
Συγκεκριμένα στόχος ήταν να πάρουμε ενδεικτικά αποτελέσματα για την απόδοση ενός
διαμεσολαβητή Squid σε επεξεργαστές νέας γενιάς και όχι σε κόμβους παλιάς γενιάς από τους οποίους
απαρτίζεται η τρέχουσα υποδομή ελέγχου περιεχομένου. Χρησιμοποιώντας το λειτουργικό Proxmox1
κατασκευάσαμε δύο εικονικά μηχανήματα για την εκτέλεση πειραμάτων. Ο κόμβος VM1
χρησιμοποιήθηκε για την αποστολή δοκιμαστικής HTTPS κίνησης (προς ένα συγκεκριμένο ιστότοπο) ενώ ο
κόμβος VM2 χρησιμοποιήθηκε για τον πειραματισμό με το λογισμικό Squid για HTTPS ερωτήματα. Ο
κόμβος VM2 έχει εγκατεστημένο λειτουργικό FreeBSD 12.1 και φιλοξενεί Squid v4.12. Το εικονικό
μηχάνημα αποτελείται από 8 vCPUs και 4GB RAM. Στο παρακάτω διάγραμμα παρουσιάζουμε για
διάστημα μιας ώρας τα αιτήματα που εξυπηρετούσε ο διακομιστής χρησιμοποιώντας διαφορετικό
πλήθος πυρήνων:

Squid: Εξυπηρέρητση Αιτημάτων HTTPS


30000

25000 Workers 1
Workers 2
20000
Workers 3
Αιτήματα

15000 Workers 4

10000 Workers 5
Workers 6
5000
Workers 7
0
0 10 20 30 40 50 60
Χρόνος (λεπτά)

Το τρέχον διάγραμμα αποτελεί μόνο μια ενδεικτική εκτίμηση των αιτημάτων που μπορούμε να
επεξεργαστούμε χρησιμοποιώντας διαφορετικό πλήθος από workers (processes). Η πραγματική τιμή
μπορεί να αποδοθεί με ακρίβεια μόνο κατά την εφαρμογή της διαμεσολάβησης HTTPS κίνησης στο
παραγωγικό περιβάλλον του ΠΣΔ. Οι αντίστοιχες τιμές αιτημάτων ανά δευτερόλεπτο που διαχειρίζεται ο
κάθε πυρήνας κατά μέσο όρο στις παραπάνω αρχιτεκτονικές είναι:

Πυρήνες 1 2 3 4 5 6 7

Αίτημα ανά Πυρήνα 130 114 96 84 75 69 64

Συνολικά Αιτήματα
ανά δευτερόλεπτο 130 228 288 336 376 415 447

Όπως ρητά αναφέρεται2, οι τιμές αυτές επηρεάζονται από την χρήση εικονικοποιημένων πυρήνων όπου
αναμένονται καλύτερες επιδόσεις όταν η εκτέλεση γίνει σε φυσικούς πυρήνες. Παράλληλα δεν

1
https://proxmox.com/en/

2
https://wiki.squid-cache.org/Features/SmpScale#How_to_configure_SMP_Squid_for_top_performance.3F

6
ΠΕ 2.9 Έλεγχος περιεχομένου web

χρησιμοποιήθηκαν λειτουργίες όπως CPU affinity που θα μπορούσαν να βελτιώσουν περισσότερο τις
πρωθύστερες επιδόσεις.
Οι προκύπτουσες τιμές είναι ενδεικτικές επειδή αναφέρονται σε ελεγχόμενα πειράματα. Για την
καλύτερη εκτίμηση των πόρων απαιτείται η πειραματική λειτουργία της υπηρεσίας με την υποδομή
που θα αποκτηθεί για τον έλεγχο HTTPS κίνησης.
2.4 Εκτίμηση δικτυακών πόρων (απαιτήσεις σε bandwidth)

Λαμβάνοντας δεδομένα από τα διαγράμματα Multi Router Traffic Grapher (MRTG)


(http://ngs.att.sch.gr/Stats/br.att.sch.gr/br.att.sch.gr_vlan120.html,
http://ngs.att.sch.gr/Stats/br.att.sch.gr/br.att.sch.gr_vlan600.html) για το σύνολο της κίνησης που
εισέρχεται/εξέρχεται από το δίκτυο του ΠΣΔ (αφορούν την διπλή όδευση του δρομολογητή άκρης του
ΠΣΔ με το δίκτυο ΕΔΥΤΕ) μπορούμε να θεωρήσουμε ότι η χρήση εξοπλισμού 10Gbit είναι επαρκείς για την
συνολική κίνηση που θα φτάνει στην υπηρεσία ελέγχου περιεχομένου. Σύγχρονες κάρτες δικτύου
χωρητικότητας 10Gbit, συνδεδεμένες στους αντίστοιχους εξυπηρετητές, μπορούν να ικανοποιήσουν
πλήρως όλη την κίνηση του ΠΣΔ και αντίστοιχα και το υποσύνολο που αντιστοιχεί σε HTTP και HTTPS.
2.5 Εκτίμηση Αιτημάτων ανά Σχολική Μονάδα/Τύπο Διασύνδεσης

Το βασικό που θέλουμε να εντοπίσουμε σε αυτή την ενότητα είναι ο τρόπος με τον οποίο η αναβάθμιση
της ζεύξης ενός σχολείου (π.χ. από ADSL σε VDSL) μπορεί να οδηγήσει και σε επικείμενη αύξηση των
αιτημάτων στην υπηρεσία ελέγχου περιεχομένου. Αν (i) γνωρίζαμε τις IP διευθύνσεις με τις οποίες
εξέρχεται η εκάστοτε σχολική μονάδα (ii) τον τρόπο διασύνδεσης της (ADSL, VDSL και MAN) και (iii) αν
γινόταν κατάλληλη συλλογή δεδομένων NetFlow, θα μπορούσαμε να υπολογίσουμε το πλήθος των
πακέτων HTTP και HTTPS ανά σχολείο. Στη συνέχεια για κάθε μία από τις παραπάνω περιπτώσεις
διασυνδέσεων θα μπορούσαμε να ανάγουμε το πλήθος των HTTP και των HTTPS πακέτων ανά μαθητή.
Κατά αυτόν τον τρόπο θα μπορούσαμε να συγκρίνουμε την διαφορετικές απαιτήσεις (αν υπάρχουν) σε
σχολικές μονάδες που έχουν διαφορετικό τρόπο διασύνδεσης.
2.6 Συμπεράσματα

Παραθέτουμε παρακάτω την τρέχουσα κατάσταση της υπηρεσίας content filtering και συγκεκριμένα τα
χαρακτηριστικά (CPU/Μνήμη) των 16 cacheboxes:

Cacheboxes CPU (Μοντέλο) Πυρήνες CPU Μνήμη RAM (GB)


Intel(R) Xeon(R) CPU
cache01.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache02.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache03.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache04.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache05.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache06.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache07.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache08.att.sch.gr E5420 @ 2.50GHz 8 8

7
ΠΕ 2.9 Έλεγχος περιεχομένου web

Intel(R) Xeon(R) CPU


cache09.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache10.att.sch.gr E5420 @ 2.50GHz 8 8
Intel(R) Xeon(R) CPU
cache11.att.sch.gr E5430 @ 2.66GHz 8 14
Intel(R) Xeon(R) CPU
cache12.att.sch.gr E5430 @ 2.66GHz 8 10
Intel(R) Xeon(R) CPU
cache13.att.sch.gr E5420 @ 2.50GHz 8 10
Intel(R) Xeon(R) CPU
cache14.att.sch.gr E5430 @ 2.66GHz 8 10
Intel(R) Xeon(R) CPU
cache15.att.sch.gr E5430 @ 2.66GHz 8 14
Intel(R) Xeon(R) CPU
cache16.att.sch.gr E5430 @ 2.66GHz 8 10

Συνολικά 128 148


Βάσει της εκτίμησης που έγινε στις προηγούμενες ενότητες, θα χρειαζόμασταν τουλάχιστον 7 εικονικά
μηχανήματα (όπως αυτό που διενεργήθηκε ο πειραματισμός) για την εξυπηρέτηση του top 95% των
αιτημάτων HTTPS. Κατά αντιστοιχία προτείνεται η χρήση δύο εξυπηρετητών με τουλάχιστον 56 πυρήνες
(αθροιστικά) καθώς και μέγεθος μνήμης τουλάχιστον ίσο η περισσότερο από δύο φορές το μέγεθος της
μνήμης που χρησιμοποιείται στην τρέχουσα υποδομή (καθώς όπως αναφέρθηκε παραπάνω ο λόγος
κίνησης HTTPS/HTTP είναι 2). Οι εξυπηρετητές πρέπει να είναι εξοπλισμένοι με δύο διπλές κάρτες
δικτύου των 10Gbit για (i) την πλήρη εξυπηρέτηση της κίνησης, (ii) ανοχή σε σφάλμα σε επίπεδο interface
και (iii) ανοχή σε σφάλμα σε επίπεδο συσκευής. Τέλος για την πλήρη ανοχή σε σφάλμα και για τον
πειραματισμό/δοκιμή νέων features της υπηρεσίας, κρίνεται αναγκαία η ύπαρξη ενός τρίτου εξυπηρετητή
όμοιο με τους δύο που θα εξυπηρετούν την HTTPS κίνηση.

8
ΠΕ 2.9 Έλεγχος περιεχομένου web

3 Προστασία ιστοτόπων μονάδων και χρηστών

To ΠΣΔ φιλοξενεί στους κεντρικούς εξυπηρετητές του ένα μεγάλο σύνολο από ιστοσελίδες σχολείων,
εκπαιδευτικών, οποίες γίνονται στόχος κακόβουλων δικτυακών επιθέσεων. Στον παρόν τμήμα της μελέτης
θα εξετάσουμε την δοκιμαστική προστασία τους από ένα συνδυασμό ειδικευμένων δικτυακών συσκευών
προστασίας (Intrusion Protection System-IPS) της εταιρείας Fortigate που παρέχονται από το ΕΔΕΤ στο
σύνορο της σύνδεσης με το ΠΣΔ.
Στην υποδομή του ΕΔΕΤ είναι εγκαταστημένα δύο (2x) Chassis Fortinet 5144c, και στο καθένα υπάρχουν
δύο (2x) Security blades 5001D για αυξημένη διαθεσιμότητα. Η εν λόγω ρύθμιση επιτρέπει την λειτουργία
υψηλής διαθεσιμότητας HA (high Availability) με το ένα Chassis να βρίσκεται στον EIE και το άλλο στη
Κωλέττη. Για την υπηρεσία, έχουν χρησιμοποιηθεί ένα FW blade (5001D) σε κάθε σημείο λειτουργίας σε
ένα cluster με 2 FW blades που λειτουργούν σε Active – Passive mode, με Primary site το κόμβο του ΕΙΕ.

To ΗΑ μπορεί να λειτουργήσει με περιβάλλον εικονικοποιήσης (virtualisartion) παρέχοντας «πολλαπλή


ενοικίαση» multitenancy το οποίο στην ορολογία της Fortigate ονομάζεται VDOM (Virtual Domain) και
δίνεται η δυνατότητα για Virtual Clustering (επέκταση του FGCP) που με κατάλληλη
παραμετροποίηση στις κάρτες (HA mode – group ID – group name – password – priority – override) για
ανταλλαγή πακέτων συγχρονισμού (heartbeats) ξεκινά η διαπραγμάτευση μεταξύ τους για την εκλογή της
Primary (πρωτεύουσας κάρτα). To FGCP αναθέτει εικονικές MAC διευθύνσεις βάση της παρακάτω
φόρμουλας της μορφής 00-09-0f-09-<group-id_hex><vcluster_integer><idx> σε όλα τα interfaces της
πρωτεύουσας κάρτας του FW. Έτσι στη περίπτωση που σταματήσει να λειτουργεί, τότε η καινούργια
πρωτεύουσα (πρώην Εφεδρική/Backup στο blade) να έχει τις ιδίες εικονικές MAC διευθύνσεις στα
interface του. Όταν το cluster ξεκινήσει μετά από βλάβη (δλδ failover), τότε η νέα πρωτεύουσα στέλνει
πακέτα gratuitous ARP για να ενημερώσει ότι πλέον τις εικονικές MAC θα τις βλέπουνε από άλλα
connected interfaces.
Με την διάρθρωση Virtual Clustering /VDOM επιτρέπεται:
 Device failover: σε περίπτωση μη λειτουργίας της πρωτεύουσας (Primary) φυσικής κάρτας – είτε
ακόμα και σε επίπεδο logical χάνοντας ένα VDOM, τότε αντικαθίσταται αυτόματα με τη Backup
κάρτα και γίνεται επανεκκίνηση τη κίνησης με ελάχιστη επίδραση στο δίκτυο.
 Link failover: Διατηρεί τη ροή της κυκλοφορίας αν πέσει ένα link. Σε αυτή την περίπτωση, η
πρωτεύουσα κάρτα δεν σταματά να λειτουργεί και ως εκ τούτου συμμετέχει στη διαπραγμάτευση
επιλογής μιας άλλης λειτουργικής.

9
ΠΕ 2.9 Έλεγχος περιεχομένου web

 Session failover: Με την ενεργοποίηση του session failover (που ονομάζεται επίσης session pick
up), η πρωτεύουσα κάρτα ενημερώνει τη εφεδρική (Back-up) για τις αλλαγές στα sessions και
στέλνει τα session tables, διατηρώντας τη ενήμερη. Μ αυτό το τρόπο εξασφαλίζεται η αυτόματη
επανεκκίνηση των live sessions που διατηρούσε η πρωτεύουσα.
 BGP failover: Όταν τα Fortigate είναι σε HA mode, ο BGP router daemon process τρέχει μόνο στη
πρωτεύουσα και η εφεδρική απλά λαμβάνει από τη πρωτεύουσα όλα τα routes τα οποία και τα
διατηρεί για να είναι σε συγχρονισμό. Σε περίπτωση failover της πρωτεύουσας καρτας, το BGP
process θα ξεκινήσει στη Backup και με τις απαραίτητες παραμετροποιήσεις ανάμεσα στους peers
δεν θα υπάρξει διακοπή της κίνησης. Οπότε από το πρωτεύοω FW υπάρχουν 2 BGP peers με τους
Carrier routers – ένα με EIE και ένα με ΚΟL πάνω από 2 διαφορετικά vlans, και αντιστοίχως άλλα 2
BGP peers προς EIER και KOLR σε άλλα 2 διαφορετικά vlans:

3.1 Δικτυακή τοπολογία και Ζώνες λειτουργίας


O συνοριακός δρομολογητής router του ΠΣΔ (Cisco 6800) έχει ενεργοποιήσει δύο BGP peering με τους
τους δρομολογητές του ΕΔΥΤΕ με το private AS του Carrier δικτύου του ΕΔΥΤΕ – AS65100.
Πάνω από τα peering το ΠΣΔ διαφημίζει τα δίκτυα που επιθυμεί να διέρχονται από το Firewall. Τα δίκτυα
του ΠΣΔ για τη δρομολόγηση μέσα στο Carrier τοποθετούνται σε L3VPN (VRF) τα οποία θα καταλήγουν
στο Firewall.
Για το VDOM του ΠΣΔ έχουν δημιουργηθεί sub-interfaces με 4 διαφορετικά vlans, εκ των οποίων τα 2
είναι για την κίνηση από το ΠΣΔ (Inside Zone) και τα άλλα 2 VLANs (Outside Zone) θα είναι για τη κίνηση
προς το internet. Πάνω από αυτά τα vlans θα σηκώνονται τα BGP με τους αντιστοίχους routers στο δίκτυο
της ΕΔΥΤΕ. Πιο συγκεκριμένα για την Inside Zone – 2 BGP Sessions προς τους Carrier και για την Outside
Zone 2 BGP session προς τους IP routers.
Το Inside zone BGP με το VRF του ΠΣΔ στο δρομολογητή του ΕΔΥΤΕ λαμβάνει default route με next hop το
Firewall και διαφημίζει τα routes που επιθυμεί το ΠΣΔ. Από την άλλη από το Outside Zone BGP με τους IP
routers θα διαφημίζονται τα routes που έχει λάβει από το Inside και θα λαμβάνει το default route με next
hop τους IP routers.

10
ΠΕ 2.9 Έλεγχος περιεχομένου web

Με τη παραπάνω αρχιτεκτονική παρέχεται εφεδρεία:


 Σε περίπτωση βλάβης της φυσικής γραμμής ή της κάρτας του FW, όλη η κίνηση θα γυρίσει στο
εφεδρικό Firewall. Κατά τη μετάβαση αυτή δεν θα υπάρξει διακοπή της κίνησης επειδή υπάρχει
προστασία των συνεδριών BGP μέσω (BGP graceful restart – BGP fine tuning timers) και επειδή τα
Sessions tables είναι συγχρονισμένα μεταξύ των δυο Firewall.
 Όλα τα BGP sessions από το FW προς τους routers είναι διπλά οπότε και σε περίπτωση failover
ενός από τους router, η κίνηση θα συνεχίσει να εξυπηρετείται.
Στο συνοριακό δρομολογητή του ΠΣΔ έχουν εγκατασταθεί δύο vlan: 4043 κ 4044
!
interface Vlan4043
description [PR-FWAAS.ATT] Primary Connection to GRNET Firewall [FWAAS-EIE] - VLAN
(10 Gbps)
bandwidth 10000000
ip address 10.82.48.3 255.255.255.254
end
!
interface Vlan4044
description [BKP-FWAAS.ATT] Backup Connection to GRNET Firewall [FWAAS-KOL] - VLAN
(10 Gbps)
bandwidth 10000000
ip address 10.82.48.5 255.255.255.254
end
και εφαρμόζεται source based routing από τα VLAN 125 και 126 φιλοξενεί blogs
!
interface Vlan125
description SCH DC PRIMARY (cswa.schdc) - 10 Gbps
ip address 10.0.1.101 255.255.255.252
ip access-group restrict_access_dc_new out
ip policy route-map dc_redirect_to_faas_eie
ip ospf network point-to-point
end
!
interface Vlan126
description SCH DC BACKUP (cswb.schdc) - 10 Gbps
ip address 10.0.1.105 255.255.255.252
ip access-group restrict_access_dc_new out
ip policy route-map dc_redirect_to_faas_eie

11
ΠΕ 2.9 Έλεγχος περιεχομένου web

ip ospf network point-to-point


end

route-map dc_redirect_to_faas_eie
route-map dc_redirect_to_faas_eie, deny, sequence 10
Match clauses:
ip address (access-lists): faas_bypass
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map dc_redirect_to_faas_eie, permit, sequence 20
Match clauses:
ip address (access-lists): dc_internet_access
Set clauses:
ip next-hop 194.63.239.190
Policy routing matches: 0 packets, 0 bytes
route-map dc_redirect_to_faas_eie, permit, sequence 30
Match clauses:
ip address (access-lists): faas_redirect
Set clauses:
ip next-hop 10.82.48.2
Policy routing matches: 0 packets, 0 bytes

Η επιλογή της κίνησης που θα δρομολογηθεί εξαρτάται από την ACL faas_redirect
show ip access-lists faas_redirect
Extended IP access list faas_redirect
10 permit ip 194.63.238.128 0.0.0.15 any

3.2 Fortimanager και Fortianalyzer


Όλες οι παραμετροποιήσεις του VDOM του ΠΣΔ γίνονται μέσω του web interface Fortimanager ( 195.251.25.4)
(https://fortimanager-cfw.grnet.gr). Η αποτίμηση των αποτελεσμάτων της αποκοπής κακόβουλης κίνησης γίνεται
μέσω του Fortianalyzer : 195.251.25.5 https://fortianalyzer-cfw.grnet.gr. Τόσο ο Fortimanager όσο και ο
Fortianalyzer παρέχουν web interface με ταυτοποίηση μέσω πρωτοκόλλου Radius Έχει ρυθμιστεί μέσω radius
Tο σχήμα που ακολουθείται για το διανομή των VDOM ΠΣΔ είναι η εξής:
1. Δημιουργία ADOM (Administrative Domain). Ανάθεση κωδικών διαχειριστών στον ADOMs (π.χ episey)
2. Επισύναψη VDOM σε ένα κωδικό χρήστη
Με αυτό τον τρόπο το ΠΣΔ αναλαμβάνει τη διαχείριση του VDOM του κάνοντας login στο ADOM. Η είσοδος στο
ADOM γίνεται μέσω του FortiManager και στο οποίο έχει αποκλειστικά view μόνο το δικό/ά του VDOM.

12
ΠΕ 2.9 Έλεγχος περιεχομένου web

Το Authentication/Authorization γίνεται από Radius server του ΠΣΔ με την απόδοση των παρακάτω radius
attributes. Το βασικό VSA RADIUS attribute που ενδιαφέρει είναι το Fortinet-Group-Name, το οποίο
πρέπει να επιστρέφεται με συγκεκριμένες τιμές για τους χρήστες που έχουν δικαιώματα διαχείρισης για
την υπηρεσία στα interfaces frtimanager και fortianalyzer. Συγκεκριμένα:
 Οι χρήστες με δικαιώματα Read-Only (RO) θα λαμβάνουν την τιμή SCH_RO.
 Οι χρήστες με δικαιώματα Read-Write (RW) θα λαμβάνουν την τιμή SCH_RW.
3.3 Δημιουργία Πολιτικής προστασίας
Από τον ιστότοπο https://fortimanager-cfw.grnet.gr/p/login/ αποκτάται πρόσβαση στον fortimanager

Εικόνα 1 Βασική πρόσβαση στο Fortimanager

Εικόνα 2 Βασική πρόσβασης

Στο βασικό παράθυρο φαίνεται για ποιο χρήστη (episey) και VDOM (SCH-VDOM) παρέχεται το περιβάλλον
διαχείρισης. Από το icon Policy objects θα γίνει βασικός ορισμός της πολιτικής προστασίας.
Στο policy objects εμφανίζεται η επόμενη σελίδα:

13
ΠΕ 2.9 Έλεγχος περιεχομένου web

Εικόνα 3 Βασικά στοιχεία παραθύρου πολιτικών

Με κόκκινο x εμφανίζεται μια ανενεργή πολιτική και με απλό χρώμα ενεργές πολιτικές. Οι διαφορετικές
είδους πολιτικές φαίνονται στην αριστερή λίστα που ξεκινά με το IPv4 policy. Επειδή υπάρχει το
ενδεχόμενο ταυτόχρονοι χρήστες να κάνουν αλλαγές στην πολιτική, ένας διαχειριστής χρειάζεται να πάρει
τον έλεγχο πατώντας το λουκέτο πάνω δεξιά.

Εικόνα 4 κλειδωμένη πρόσβαση

Οι υφιστάμενες πολιτικές έχουν πεδίο εφαρμογής σε αντικείμενα πολιτικών ( που φαίνονται στην
επόμενη εικόνα) που ανήκουν σε μια (Ζώνη/Zone) και επηρεάζουν τερματικούς σταθμό (From ) με
εφαρμογή μια πολιτικής ασφάλειας. Τα αντικείμενα ασφάλειας μπορούν να ρυθμιστούν επιλέγοντας το
object configuration.

Εικόνα 5 Αντικείμενα Πολιτικής

14
ΠΕ 2.9 Έλεγχος περιεχομένου web

Εν προκειμένω ορίζονται μέσω του menu Object Configurations οι ζώνες του ΠΣΔ

Εικόνα 6 Ορισμός Ζώνης ΠΣΔ (inside/outside)

Οι οποίες απαιτούνται για την κατασκευή μια πολιτικής

Εικόνα 7 Μενού Υπαρχόντων πολιτικών

που χρειάζεται για την εφαρμογή μιας πολιτικής. Το επόμενο βασικό συστατικό μιας πολιτικής είναι το
security profile που καθορίζει τι είναι αυτό που θα ελέγχεται και με ποιο τρόπο θα κοπεί. Στην επόμενη
εικόνα φαίνεται το προφίλ προστασία για web servers και πως ρυθμίζονται οι ενέργειες προστασίας.

15
ΠΕ 2.9 Έλεγχος περιεχομένου web

Εικόνα 8 Προφίλ προστασίας για web servers

Εικόνα 9 Μενού αντιμετώπισης επιθέσεων σε περιβάλλον web

Στην περίπτωση που ο server λειτουργεί σε περιβάλλον https, το περιβάλλον προστασίας χρειάζεται να
ξέρει το πιστοποιητικό για να μπορεί να διαβάσει τα κρυπτογραφημένα πακέτα και να επιβάλει το προφίλ
προστασίας. Σε αυτή την περίπτωση επιλέγεται / ενεργοποιείται το SSL inspection. Η επιλογή για SSL
inspection απαιτεί να έχει οριστεί το κατάλληλο αντικείμενο στο μενού των αντικειμένων

16
ΠΕ 2.9 Έλεγχος περιεχομένου web

Εικόνα 10 Ορισμός του κατάλληλου πιστοποιητικού για SSL inspection

και να εφαρμοστεί στο profile προστασίας π.χ LAMS εν προκειμένω:

Εικόνα 11 Προστασία με SSL

17
ΠΕ 2.9 Έλεγχος περιεχομένου web

3.4 Αποτελέσματα προστασίας για το https://schoolpress.sch.gr

O log analyzer https://fortianalyzer-cfw.grnet.gr παράγει αναλύσεις με βάση τις επιθέσεις που ανίχνευσε και
έκλεισε. Μια αναλυτική μορρφή είναι διαθέσιμη στο παράρτημα και ενδεικτικά στην συνέχεια:

Εικόνα 12 Ανάλυση στοιχείων επίθεσης με επικινδυνότητα

18
ΠΕ 2.9 Έλεγχος περιεχομένου web

Εικόνα 13 Ανάλυση με βάση τις διευθύνσεις IP

19
ΠΕ 2.9 Έλεγχος περιεχομένου web

Εικόνα 14 Ανάλυση με βάση το είδος της επίθεσης

20
ΠΕ 2.9 Έλεγχος περιεχομένου web

4 Στοιχεία Διαθεσιμότητας
Στατιστικά σε επίπεδο DNS θα πρέπει να αναζητηθούν στα αντίστοιχα στατιστικά της υπηρεσίας DNS. Για
την λειτουργία των εξυπηρετητών cache, η διαθεσιμότητα της υπηρεσίας είναι υψηλή, καθώς το
πρωτόκολλο WCCP εξασφαλίζει τη σωστή λειτουργία της υπηρεσίας, ανεξάρτητα από βλάβες σε
επιμέρους συσκευές. Ενδεικτικά δίνεται το διάγραμμα διαθεσιμότητας για τον εξυπηρετητή
cache05.att.sch.gr, ο οποίος για το τελευταίο έτος αποτελεί τον επιλεγμένο εξυπηρετητή που καθορίζει το
σχήμα διαμοιρασμού της κίνησης στους υπόλοιπους εξυπηρετητές cache, συμπεριλαμβανομένου και του
εαυτού του. Παρατίθεται αρχικά το διάγραμμα διαθεσιμότητας της υπηρεσίας για το 2ο εξάμηνο του
2020:

4.1 Στατιστικά Στοιχεία Χρήσης


Η συνολική κίνηση της υπηρεσίας για το έτος 2020, φαίνεται στο παρακάτω διάγραμμα:

21
ΠΕ 2.9 Έλεγχος περιεχομένου web

5 Επιπρόσθετες Ενέργειες
Παράλληλα με την παρούσα μελέτη στα πλαίσια της συνεργασίας με το ΠΣΔ έγιναν και οι κάτωθι
επιπρόσθετες ενέργειες: (1) Εγκατάσταση και παραμετροποίηση λογισμικού Cacti για την επίβλεψη
συσκευών και υπηρεσιών του ΠΣΔ, (2) Αναβάθμιση των πόρων του μηχανήματος που φιλοξενεί τις RPZ
ζώνες και (3) ανάλυση της τρέχουσας παραμετροποίησης Netflow καθώς και πρόταση για ανανέωση της
παραμετροποίησης με στόχο την πλήρη παρακολούθηση της δικτυακής κίνησης.

22
ΠΕ 2.9 Έλεγχος περιεχομένου web

6 Δελτία βλαβών

Ηλεκτρονική Διεύθυνση
URL Ονοματεπώνυμο χρήστη Διεύθυνση Υπολογιστή
http://154.57.7.107/microsystems/temp/20875058020201204171051.pdf ΚΟΝΤΟΣ ΑΝΤΩΝΙΟΣ (ankontos) ankontos@sch.gr 81.186.115.86
http://www.kyoceradocumentsolutions.ae/ Υπεύθυνος ΠΛΗΝΕΤ (plinetls) plinet@dide.les.sch.gr 81.186.117.146
ΜΠΟΥΜΠΟΥΚΗ ΣΟΦΙΑ
http://172.217.21.78/generate_204 (sofboumpou) sofboumpou@sch.gr 81.186.175.116
3ο ΔΗΜΟΤΙΚΟ ΣΧΟΛΕΙΟ ΑΓΡΙΝΙΟΥ mail@3dim-
http://cache15.att.sch.gr:8383/ H6 agrin.ait.sch.gr 81.186.72.58
http://cache11.att.sch.gr:8383/ ΜΠΙΓΓΟΣ ΧΡΗΣΤΟΣ (cbiggos) cbiggos@sch.gr 194.63.229.142
http://https://cf.noc.ntua.gr/ ΜΠΟΥΤΣΙΚΑΣ ΒΑΣΙΛΕΙΟΣ (vbout) vbout@sch.gr 81.186.63.164
http://www.cosmodata.gr/ ΜΟΥΚΙΔΟΥ ΣΟΦΙΑ (sofiamk) sofiamk@sch.gr 81.186.9.85
ΓΙΑΝΝΟΠΟΥΛΟΣ ΒΑΣΙΛΕΙΟΣ
http://agar.io/ (a421779) a421779@sch.gr 81.186.140.238
ΣΕΛΝΤΟΝ ΑΝΤΖΕΛΑ-ΑΝΝ
http://www.edmondo.com/ (aselnton) aselnton@sch.gr 81.186.63.76
ΝΙΚΟΛΑΟΥ ΑΛΚΙΝΟΟΣ
http://194.63.239.164/ (nikolaoa20) nikolaoa20@sch.gr 81.186.147.138
ΣΙΟΥΓΙΟΥΔΗΣ ΑΠΟΣΤΟΛΟΣ
http://totaljerkface.com/ (a472506) a472506@sch.gr 81.186.99.98
mail@1epal-
http://www.cosmodata.gr/ 1ο ΕΠΑΛ ΒΕΡΟΙΑΣ (1epal-veroias) veroias.ima.sch.gr 81.186.176.222

23
ΠΕ 2.9 Έλεγχος περιεχομένου web

7 Στοιχεία Χρήσης Υπηρεσίας

24
ΠΕ 2.9 Έλεγχος περιεχομένου web

8 Στοιχεία Ανάλυσης επιθέσεων από Fortianalyzer

25

You might also like