XEN

Το ΧΕΝ είναι ένα λογισμικό για την παροχή υπηρεσιών εικονικοποίησης. Ο hypervisor του ΧΕΝ δημιουργήθηκε, στα πλαίσια της ερευνητικής εργασίας XENOLINUX, στο Πανεπιστήμιο του Cambridge από τους Keir Fraser και Ian Pratt στα τέλη της δεκαετίας του 1990. Το Πανεπιστήμιο ανέπτυξε τις πρώτες εκδόσεις του λογισμικού ως το 2012. Έκτοτε η κοινότητα του ΧΕΝ συντηρεί και αναπτύσσει το εν λόγω λογισμικό ως ελεύθερο λογισμικό υπό την άδεια GNU General Public License (GPLv2).

XEN

Γενικά
Είδος	υπερεπόπτης, ελεύθερο λογισμικό
Διανομή
Έκδοση	4.19.0 (29 Ιουλίου 2024)
Λειτουργικά
Ανάπτυξη
Γραμμένο σε	C
Άδεια χρήσης	GPLv2
Σύνδεσμοι
Επίσημος ιστότοπος
https://xenproject.org/
Αποθετήριο κώδικα
https://xenbits.xen.org/gitweb/?p=xen.git

Οι οντότητες του ΧΕΝ

Οι βασικές οντότητες που υπάρχουν στο XEN είναι οι ακόλουθες:

Ο hypervisor

Ο hypervisor του XEN είναι ένα "στρώμα" λογισμικού το οποίο προσφέρει υπηρεσίες εικονικοποίησης, και "τρέχει" απευθείας στο υλικό αντικαθιστώντας το λειτουργικό σύστημα. Λόγω της θέσης που κατέχει ο hypervisor αποτελεί τον εξυπηρετητή όλων των κλήσεων προς το υλικό (CPU, είσοδος/έξοδος). Η χρήση του hypervisor αποτελεί θετικό στοιχείο για την αρχιτεκτονική του ΧΕΝ καθώς υπάρχει ουσιαστικός διαχωρισμός του υλικού από τα φιλοξενούμενα λειτουργικά συστήματα, με άμεση συνέπεια την αύξηση του επιπέδου ασφαλείας του συστήματος (πιθανές επιθέσεις στα φιλοξενούμενα λειτουργικά συστήματα δεν θα επηρεάσουν τον κεντρικό εξυπηρετητή).

Domain0 guest

Το Domain0, που αναφέρεται και ως Dom0 , ενεργοποιείται από τον hypervisor του ΧΕΝ κατά την αρχική εκκίνηση του συστήματος και μπορεί να τρέξει οποιοδήποτε λειτουργικό σύστημα εκτός από Windows.

DomU Guests

Τα φιλοξενούμενα domain που αναφέρονται και ως DomU , ελέγχονται από το Dom0 και λειτουργούν ξεχωριστά στο σύστημα. Τα φιλοξενούμενα Domain είτε τρέχουν με ένα ειδικά τροποποιημένο λειτουργικό σύστημα, κάτι το οποίο είναι γνωστό σαν paravirtualization, είτε με ένα μη-τροποποιημένο λειτουργικό σύστημα, το οποίο τρέχει σε ειδικό υλικό που το υποστηρίζει (επεξεργαστές Intel VT, AMD-V), κάτι το οποίο είναι γνωστό σαν εικονική μηχανή υλικού (Hardware Virtual Machine - HVM).

Είναι σημαντικό το γεγονός πως ενώ ο hypervisor έχει άμεση επαφή με το υλικό, η πρόσβαση των φιλοξενούμενων λειτουργικών συστημάτων στις φυσικές συσκευές, γίνεται μέσω του dom0.

Τεχνικές εικονικοποίησης στο ΧΕΝ

Paravirtualization

Είναι μια τεχνική εικονικοποίησης που επιτρέπει στο λειτουργικό σύστημα να “γνωρίζει” ότι τρέχει μέσω ενός hypervisor αντί να τρέχει απευθείας στο υλικό. Το λειτουργικό σύστημα θα πρέπει να είναι κατάλληλα τροποποιημένο για την ομαλή λειτουργία στην ειδική περίπτωση που δεν τρέχει απευθείας στο υλικό. Αυτό το ειδικά τροποποιημένο λειτουργικό σύστημα ονομάζεται Xenolinux.

Εικονική μηχανή υλικού (hardware virtual machine – HVM)

Ένας όρος που περιγράφει ένα λειτουργικό σύστημα που τρέχει σε ένα εικονικό περιβάλλον χωρίς να έχει μεταβληθεί, και αγνοώντας ότι δεν τρέχει απευθείας στο υλικό. Για να επιτραπεί αυτή η λειτουργία απαιτείται ειδικό υλικό.

Η Αρχιτεκτονική του ΧΕΝ

Η αρχιτεκτονική του ΧΕΝ βασίζεται στην λογική των δακτυλίων προστασίας. Βάσει της αρχιτεκτονικής των δακτυλίων, όσο βγαίνουμε από τον πυρήνα προς τα εξωτερικά στρώματα, τα δικαιώματα μειώνονται.

XEN architecture - ring based

Το πρώτο μέρος της αρχιτεκτονικής του ΧΕΝ είναι ο hypervisor που και τρέχει απευθείας στο υλικό – δακτύλιος 0. Η εκτέλεση του πυρήνα του domain0 που καλείται και ΧΕΝ0 γίνεται στον δακτύλιο-1.

Όταν χρησιμοποιείται η τεχνική του paravirtualization, το φιλοξενούμενο λειτουργικό σύστημα το οποίο «τρέχει» στο domain U ονομάζεται ΧΕΝΟLINUX και περιλαμβάνει έναν τροποποιημένο πυρήνα Linux που τρέχει επίσης στον δακτύλιο-1. Όταν το ΧΕΝ παρέχει τη δυνατότητα για full-virtualization (εικονική μηχανή υλικού), ο πυρήνας (kernel) του φιλοξενούμενου λειτουργικού συστήματος δεν χρειάζεται τροποποίηση. Σε αυτό βοηθάει η τεχνολογία των επεξεργαστών που υποστηρίζουν την εικονικοποίηση. Αυτοί είναι οι επεξεργαστές Ιntel / VT-x, και AMD / (secure virtual machine - SVM) (Pacifica).

Η επικοινωνία των φιλοξενούμενων λειτουργικών συστημάτων, με τις φυσικές συσκευές, γίνεται μέσω του domain0. Συγκεκριμένα, όταν υπάρξει κάποια κλήση από φιλοξενούμενο λειτουργικό σύστημα, για πρόσβαση στις φυσικές συσκευές, τότε επικοινωνεί ο front end εικονικός οδηγός συσκευής του φιλοξενούμενου λειτουργικού με το backend εικονικό οδηγό συσκευής του domain0 (XEN0). Το ΧΕΝ0 έχει πρόσβαση στις φυσικές συσκευές μέσω των native device drivers που είναι οι πραγματικοί οδηγοί (drivers) του υλικού που διαχειρίζεται το κάθε σύστημα.

Ασφάλεια στο ΧΕΝ

Η ασφάλεια στο ΧΕΝ θεωρείται καθοριστικής σημασίας για την ασφάλεια όλων των φιλοξενούμενων λειτουργικών συστημάτων, αλλά και την ασφάλεια του εξυπηρετητή, και καθορίζεται κατά κύριο λόγο από την ασφάλεια του hypervisor. Κάποια βασικά προβλήματα ασφάλειας στο ΧΕΝ είναι τα ακόλουθα.

1. Απομόνωση και διαμοιρασμός πόρων
2. Ασφάλεια του bottleneck του ΧΕΝ
3. Συγκαλυμμένο κανάλι
4. Ασφάλεια στο εικονικό δίκτυο και μη αποποίηση
5. Ασφάλεια των Hypercalls
6. Επιθέσεις δεδομένων ελέγχου στον Hypervisor

Απομόνωση και διαμοιρασμός πόρων

Το σημαντικότερο πρόβλημα ασφάλειας του ΧΕΝ προκύπτει από την επικοινωνία των διαφόρων μερών της αρχιτεκτονικής του. Εάν κάποια οντότητα αυτής της αρχιτεκτονικής, τεθεί υπό τον έλεγχο κάποιου κακόβουλου χρήστη, με οποιοδήποτε μέσο, αυτό δεν θα πρέπει να επηρεάσει το υπόλοιπο σύστημα. Επομένως συμπεραίνουμε ότι οι εικονικές μηχανές θα πρέπει να είναι πλήρως απομονωμένες μεταξύ τους. Αυτό το βασικό πρόβλημα ασφάλειας λύνεται στην έκδοση 2.0.7 του ΧΕΝ, επιτυγχάνοντας ασφαλή απομόνωση μεταξύ των εικονικών μηχανών, έλεγχο προσπέλασης μέσων, ποιότητα υπηρεσίας (QoS) και μετανάστευση των εικονικών μηχανών. Επίσης, το ΧΕΝ δεν έχει κανονική πολιτική ελέγχου πρόσβασης στους πόρους. Για αυτό το λόγο χρησιμοποιείται το sHype της IBM, το οποίο εφαρμόζει υποχρεωτικό έλεγχο πρόσβασης (ΜΑC) και αυστηρή απομόνωση.

sHype

Το sHype ελέγχει, κατά κύριο λόγο, την πρόσβαση στη διαμοιραζόμενη μνήμη και το κανάλι γεγονότων. Το sHype αποτελεί τον κορμό της ασφάλειας του ΧΕΝ και γενικότερα μια αρχιτεκτονική ασφάλειας επίβλεψης που δημιουργήθηκε για την επίτευξη των παρακάτω στόχων.

• Ισχυρή απομόνωση, ενδιάμεσος διαμοιρασμός και επικοινωνία μεταξύ των εικονικών μηχανών.

Όλες οι ανωτέρω απαιτήσεις ελέγχονται αυστηρά από μια ευέλικτη μηχανή που επιβάλλει έλεγχο πρόσβασης. Αυτή η μηχανή μπορεί να επιβάλει υποχρεωτική πολιτική όπως πολυεπίπεδη ασφάλεια (Multi Level Security) , πολιτική ελέγχου πρόσβασης βασισμένη σε ρόλους , πολιτική ελέγχου βασισμένη σε type enforcement. Με την τελευταία επιλογή, δίνεται προτεραιότητα στον υποχρεωτικό έλεγχο πρόσβασης (mandatory access control - MAC) έναντι του διακριτικού ελέγχου πρόσβασης (discretionary access control - DAC).

• Επιβεβαίωση ακεραιότητας για τον hypervisor και τις εικονικές μηχανές.

Με αυτή την επιλογή γίνεται επέκταση του προτύπου Trusted Computing Group (TCG), ώστε να περιλαμβάνονται και πλατφόρμες εξυπηρετών βασισμένες σε hypervisors. Ο στόχος σε αυτή την περίπτωση είναι η ασφάλεια στην εκκίνηση και η εγγύηση της ασφάλειας του boot, για την πλατφόρμα του hypervisor, τις εικονικές μηχανές, και επιλεκτικά για τα φιλοξενούμενα λειτουργικά συστήματα και τις εφαρμογές που εκτελούνται στις εικονικές μηχανές. Για την υποστήριξη ενός μεγάλου αριθμού εικονικών μηχανών, έχει σχεδιαστεί μια εικονική αρχιτεκτονική (v – TPM , virtual trusted platform module) η οποία έχει εφαρμοστεί στον hypervisor του ΧΕΝ.

• Έλεγχος πόρων και ακριβείς εγγυήσεις αντιπροσώπευσης (accounting guarantees)

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

• Ασφαλείς υπηρεσίες

Το sHype προσφέρει τη βασική υποδομή για διαχωρισμό των υπηρεσιών σε μικρότερα και ευκολότερα διαχειρίσιμα περιβάλλοντα. Αυτή η βασική υποδομή συνοψίζεται στη διαχείριση πολιτικών ασφάλειας και στην κατανεμημένη καταγραφή. Εκτός του υποχρεωτικού ελέγχου πρόσβασης υπάρχει και η δυνατότητα για πολύ-επίπεδες πολιτικές ελέγχου πρόσβασης, που επιτυγχάνεται πρόσβαση στους πόρους θέτοντας πολύ-επίπεδες πολιτικές ελέγχου. Η αρχιτεκτονική του sHype Στην ακόλουθη εικόνα παρουσιάζεται η αρχιτεκτονική του sHype και ο συσχετισμός του με την αρχιτεκτονική του ΧΕΝ. To sHype είναι σε θέση να υποστηρίξει ένα σύνολο ασφαλών λειτουργιών όπως ασφαλείς υπηρεσίες, επίβλεψη των πόρων, διαxείριση της πρόσβασης μεταξύ των εικονικών μηχανών.

Το κλειδί της αρχιτεκτονικής του ελέγχου πρόσβασης στο sHype είναι το reference monitor, το οποίο απομονώνει τις εικονικές μηχανές και επιτρέπει τον διαμοιρασμό των πόρων μεταξύ τους μόνο όταν αυτό επιτρέπεται από την υποχρεωτική πολιτική ελέγχου πρόσβασης (ΜAC policy). To sHype υποστηρίζει ένα σύνολο διαφορετικών υποχρεωτικών ελέγχων πρόσβασης όπως Biba, Bell-LaPadula, Caernarvon, Type Enforcement, καθώς επίσης και τις πολιτικές Chinese Wall. Το reference monitor βασίζεται σε τρεις βασικές αρχές. Μεσολαβεί σε όλες τις κρίσιμες εφαρμογές, μπορεί να προστατευθεί από κακόβουλες αλλαγές, είναι όσο το δυνατόν πιο απλό γίνεται, ώστε να γίνεται πιστοποίηση της πραγματικής υλοποίησης.

Ασφάλεια του bottleneck του ΧΕΝ

Η ασφάλεια του VMM είναι το σημαντικότερο ζήτημα, καθώς πολλοί κώδικες από το ΧΕΝ εισάγονται από το Linux που το επίπεδο ασφάλειας του είναι C2. Η συνολική ασφάλεια της εικονικής μηχανής θα καταρρεύσει αν ο επιτιθέμενος θέσει υπό έλεγχο το VMM ή το Domain 0.

Συγκαλυμμένο κανάλι

Το συγκαλυμμένο κανάλι είναι μια μορφή επίθεσης με την οποία είναι δυνατή η μεταφορά πληροφορίας από ένα σύστημα κρυφά, χωρίς να είναι δυνατός ο εντοπισμός αυτής της διαρρέουσας πληροφορίας. Μπορούν για να παράδειγμα να αξιοποιηθούν για τη μεταφορά πληροφορίας στοιχεία όπως, η χρήση του επεξεργαστή, η εμφάνιση σφαλμάτων, Το συγκαλυμμένο κανάλι είναι ένα δύσκολο πρόβλημα ασφάλειας που μπορεί να συναντηθεί στο ΧΕΝ.

Ασφάλεια στο εικονικό δίκτυο και μη αποποίηση

Η ασφάλεια στο εικονικό δίκτυο του ΧΕΝ βασίζεται κατά κύριο λόγο σε δύο παράγοντες. Οι χρήστες δεν θα πρέπει να μπορούν να λάβουν άλλες ταυτότητες στο δίκτυο (να υποδυθούν κάποιον άλλο χρήστη), και θα πρέπει να υπάρχει προστασία του Dom0 καθώς η κίνηση περνάει μέσα από αυτό προς τα υπόλοιπα domain (domU’s). Το πρώτο θέμα επιλύεται αναθέτοντας μια συγκεκριμένη ip σε κάθε χρήστη και ενεργοποιώντας κανόνες anti – spoofing, ενώ το δεύτερο ζήτημα επιλύεται κάνοντας χρήση κατάλληλων κανόνων των iptables.

Οι κανόνες antispoofing τίθενται στο ανάχωμα ασφαλείας (π.χ iptables), για να διασφαλίσουν πως το σύστημα δεν θα λάβει κακόβουλα πακέτα από το δίκτυο. Κακόβουλα πακέτα μπορούν να θεωρηθούν τα πακέτα που έχουν σαν στόχο την παραπλάνηση του παραλήπτη.

Πολλά συστήματα δεν στέλνουν την γεφυρωμένη κίνηση (bridged traffic) μέσω της αλυσίδας προώθησης (Forwarding chain), όπως θα αναμενόταν. Το σύστημα RHEL/CentOS 5.1 είναι παράδειγμα αυτού του προβλήματος.

Ασφάλεια των Hypercalls

Οι Hypercalls αποτελούν, για το ΧΕΝ, κλήσεις που γίνονται από κάποιο domain προς τον hypervisor, κατά αντιστοιχία των κλήσεων (syscall) που γίνονται προς το λειτουργικό σύστημα. Τα διάφορα domain θα εκτελέσουν hypercalls για να ζητήσουν εξουσιοδοτημένες λειτουργίες όπως η ανανέωση των πινάκων των σελίδων. Ένα hypercall μεταφέρει τον έλεγχο σε μια πιο εξουσιοδοτημένη κατάσταση του domain0. To XEN είναι ασφαλέστερο λογισμικό έναντι άλλων λειτουργικών συστημάτων βάσει των hypercalls που εκτελεί. Εκτελούνται μόνο 35 hypercalls έναντι των 324 που εκτελεί ο πυρήνας του Linux 2.6.34. Ένα από τα γνωστά σήμεία ευπάθειας των λειτουργικών συστημάτων είναι οι επιθέσεις που αφορούν τις κλήσεις συστήματος. Με τον ίδιο τρόπο είναι δυνατή η εκμετάλλευση των κλήσεων προς τον hypervisor, μέσω του interface που διαχειρίζεται αυτές τις κλήσεις. Αυτό μπορεί να επιτευχθεί με την εισαγωγή κακόβουλου κώδικα στο domain0. Ένα τυπικό σενάριο επίθεσης βάσει των hypercalls είναι το εξής : 1. Ο επιτιθέμενος καταφέρνει να θέσει υπό έλεγχο κάποια από τις εφαρμογές ενός φιλοξενούμενου λειτουργικού συστήματος. Αυτό μπορεί να συμβεί ακόμα και αν το φιλοξενούμενο σύστημα ξεκίνησε σε μια ακέραια κατάσταση, καθώς υπάρχει επικοινωνία με τον “εξωτερικό κόσμο”. Επομένως θα μπορούσαν εύκολα να μολυνθούν από κάποιο κακόβουλο λογισμικό. 2. Εάν υπάρχει επιτυχία στο πρώτο βήμα, ο επιτιθέμενος μπορεί να αυξήσει τα δικαιώματα με κοινές μεθόδους επίθεσης των syscalls. 3. Όταν ο επιτιθέμενος καταφέρει να εισχωρήσει στον πυρήνα του φιλοξενούμενου λειτουργικού (αντίστοιχη διαδικασία με την απόκτηση δικαιωμάτων στον δακτύλιο-1 της χ86 αρχιτεκτονικής προστασίας βάσει των δακτυλίων), μπορεί να εξαπολύσει επίθεση στον hypervisor μέσω των hypercalls.

Επιθέσεις δεδομένων ελέγχου στον Hypervisor

Οι επιθέσεις δεδομένων ελέγχου είναι επιθέσεις οι οποίες γίνονται, από την πλευρά του επιτιθέμενου, με στόχο τον έλεγχο των δεδομένων ελέγχου. Αυτές οι επιθέσεις εντάσσονται σε μια γενικότερη κατηγορία ευπαθειών που έχει σχέση με τη ροή εκτέλεσης και τον κύκλο ζωής. Τα δεδομένα ελέγχου τα οποία εισάγονται στον μετρητή (counter) κατά τη διάρκεια εκτέλεσης του προγράμματος, όπως είναι οι διευθύνσεις επιστροφής (return addresses) και οι δείκτες μετακίνησης (jump pointers), αποτελούν δυνητικά σημεία ευπάθειας λόγω της αλλαγής στην ροή ελέγχου του προγράμματος.

Μια μορφή επίθεσης στον ΧΕΝ που θα μπορούσε να ξεκινήσει με τις hypercalls είναι να ληφθεί ο έλεγχος και να μετακινηθεί σε εκτέλεση κακόβουλου κώδικα κατά τη διάρκεια κλήσης συστήματος σε κάποιο φιλοξενούμενο λειτουργικό σύστημα. Αυτός ο κώδικας θα μπορούσε να προκαλέσει ένα διαφορετικό είδος κλήσης συστήματος, εν αντιθέσει με το αρχικό, περνώντας διαφορετικές παραμέτρους στον πυρήνα του ΧΕΝ και θέτοντας υπό έλεγχο πόρους που το τρέχων φιλοξενούμενο λειτουργικό σύστημα δεν είχε στόχο να αιτηθεί.

Η βασική παράμετρος ασφάλειας στη συγκεκριμένη επίθεση είναι η αυθεντικοποίηση του hypercall. Αν ο κακόβουλος κώδικας είναι σε θέση να δημιουργήσει το ίδιο σύνολο αποτελεσμάτων-διαπιστευτηρίων (αυθεντικοποίησης) που μπορεί να προκαλέσει και ένα αυθεντικό hypercall, τότε είναι προφανές πως ο επιτιθέμενος μπορεί να εξαπολύσει επιθέσεις στο σύστημα. Η αυθεντικοποίηση στα hypercalls εκτελείται με μια κρυπτογραφική μέθοδο στην οποία κάθε hypercall έχει ένα συγκεκριμένο κωδικό (Message authentication code MAC) που προστίθεται σαν παράμετρος για την απόδειξη της εγκυρότητας του hypercall. Εναλλακτικά χρησιμοποιείται και μια τεχνική cashing μέσω ενός πίνακα, που ονομάζεται hypercall access table (HAC).

Κάθε φορά που γίνεται μια κλήση από ένα φιλοξενούμενο λειτουργικό σύστημα (1) θα κρυπτογραφηθεί χρησιμοποιώντας τον αλγόριθμο AES (2) , όπου για αυτό το σκοπό χρησιμοποιούνται δύο αρχεία rinjdael.c και aes.c (3). Τα εν λόγω δεδομένα θα πάνε στον πυρήνα του ΧΕΝ όπου και θα αποκρυπτογραφηθούν (προφανώς για να ελεγχθεί ο σκοπός τους) (4). Έπειτα, αυτά τα δεδομένα θα ξανακρυπτογραφηθούν με αντίστοιχο τρόπο (5), ώστε να μεταφερθούν στον πυρήνα του συστήματος που παρέχει την υπηρεσία (host enviroment) (6), για να ελεγθεί η αίτηση και να διανεμηθούν οι αντίστοιχοι πόροι. Η ανωτέρω διαδικασία περιγράφεται στην ακόλουθη εικόνα.

XEN hypercalls auth

Αντίμετρα

Αρχικά, κάποια μέτρα ασφάλειας για το Domain-0 είναι τα εξής.

• Εκτέλεση του μικρότερου δυνατού αριθμού υπηρεσιών.

- Μια υπηρεσία που εκτελείται με δικαιώματα διαχειριστή στο domain διαχείρισης (domain 0), έχει πλήρη πρόσβαση σε όλα τα υπόλοιπα domain του συστήματος, και επομένως μπορεί να καταστεί επικίνδυνη. Γενικότερα ισχύει η αρχή, όσο λιγότερες υπηρεσίες εκτελούνται, τόσο το καλύτερο. Αυτό βέβαια δεν θα πρέπει να αποτελεί λόγο για άρνηση υπηρεσίας.

• Χρήση αναχώματος ασφαλείας για τον περιορισμό της κίνησης στο dom0.

- Ένα ανάχωμα ασφαλείας με προκαθορισμένους κανόνες μπορεί να βοηθήσει στην πρόληψη επιθέσεων στο dom0.

• Απαγόρευση της πρόσβασης των χρηστών στο dom0.

- Είναι γνωστό ότι ο πυρήνας του Linux έχει ευπάθειες που μπορεί να επιτρέψουν σε έναν απλό χρήστη να αποκτήσει δικαιώματα διαχειριστή (root). Εάν λοιπόν, επιτρέπεται η πρόσβαση ενός απλού χρήστη στο dom0, τίθεται σε κίνδυνο όλη η υποδομή του ΧΕΝ, αφήνοντας ανοιχτό το ενδεχόμενο, κάποιος κακόβουλος χρήστης να εκμεταλλευθεί την ευπάθεια.

• NIST - Πολιτικές ασφάλειας για τον Hypervisor

1. Εγκατάσταση όλων των ενημερώσεων του hypervisor που δίνει ο κατασκευαστής (οι περισσότεροι hypervisor θα ελέγξουν και θα εγκαταστήσουν μόνοι τους αναβαθμίσεις).
2. Απαγόρευση πρόσβασης του διαχειριστή στην διεπαφή του hypervisor. Προστασία όλων των διαχειριστικών καναλιών επικοινωνίας, χρησιμοποιώντας δίκτυο κρυπτογραφημένο και αυθεντικοποιημένο βάσει [FIPS_140-2].
3. Συγχρονισμός όλων των στοιχείων σε κάποιον επίσημο και αξιόπιστο εξυπηρέτη.
4. Αποσύνδεση ασυνήθιστων συσκευών από το σύστημα (π.χ. μη χρησιμοποιούμενα usb).
5. Απενεργοποίηση όλων των υπηρεσιών του hypervisor που δεν χρειάζονται και αποτελούν δυνητικά σημεία ευπαθειών (π.χ. διαμοιρασμός αρχείων).
6. Χρήση εργαλείων για την παρακολούθηση της κίνησης μεταξύ των φιλοξενούμενων λειτουργικών συστημάτων.
7. Παρακολούθηση του hypervisor για ύποπτες ενδείξεις

• NIST - Πολιτικές ασφάλειας για τα φιλοξενούμενα λειτουργικά συστήματα

1. Διαχείριση βάσει της πολιτικής των “φυσικών” λειτουργικών συστημάτων. Συγχρονισμός, διαχείριση log αρχείων, αυθεντικοποίηση, απομακρυσμένη πρόσβαση, κλπ.
2. Εγκατάσταση ενημερώσεων
3. Τακτικό Backup των εικονικών δίσκων
4. Αποσύνδεση μη χρησιμοποιούμενου εικονικού υλικού σε κάθε φιλοξενούμενο λειτουργικό σύστημα.
5. Χρήση διαφορετικού είδους αυθεντικοποίησης για κάθε λειτουργικό σύστημα, εκτός αν υπάρχει λόγος για κάποια λειτουργικά συστήματα να μοιράζονται τα διαπιστευτήρια.
6. Έλεγχος ότι όλες οι εικονικές συσκευές είναι συσχετισμένες μόνο με τις κατάλληλες διευθύνσεις του φυσικού συστήματος
7. Εάν ένα guest λειτουργικό σύστημα βρίσκεται σε κίνδυνο, αποτελεί δυνητική απειλή για τα υπόλοιπα λειτουργικά συστήματα σε συγκεκριμένο hypervisor.
8. Ο πιο πιθανός τρόπος για να συμβεί αυτό είναι να μοιράζονται πόρους (δίσκο κλπ).

• Στρατηγικές

1. Υποθέτουμε ότι όλα τα φιλοξενούμενα λειτουργικά συστήματα βρίσκονται σε κίνδυνο. Επαναφέρουμε όλα τα λειτουργικά συστήματα σε κάποια, καλή, προηγούμενη κατάσταση που υπάρχει αποθηκευμένη.
2. Έλεγχος των λειτουργικών συστημάτων για κατάσταση επικινδυνότητας. Αν βρεθεί κακόβουλο λογισμικό εφαρμόζεται η πολιτική ασφάλειας της εταιρείας.

Καταγεγραμμένες ευπάθειες

Γνωστές και καταγεγραμμένες ευπάθειες του ΧΕΝ μπορούν να βρεθούν στον ακόλουθο ιστοχώρο.

Αναφορές

1. The book of XEN
2. Professional XEN virtualization.
3. XUE Haifeng,QING Sihan,ZHANG Huanguo, (2007) XEN Virtual Machine Technology and Its Security Analysis, Natural Sciences Volume 12, Number 1, 159-162, DOI: 10.1007/s11859-006-0277-9
4. https://web.archive.org/web/20110417075106/http://wiki.xensource.com/xenwiki/SecuringXen
5. https://web.archive.org/web/20080220200039/http://www.research.ibm.com/secure_systems_department/projects/hypervisor/
6. http://www.cs.ubc.ca/grads/resources/thesis/Nov09/Le_Cuong.pdf Αρχειοθετήθηκε 2015-08-26 στο Wayback Machine.
7. http://xen.org/files/Marketing/WhatisXen.pdf Αρχειοθετήθηκε 2012-02-17 στο Wayback Machine.
8. http://xen.org/files/Marketing/HowDoesXenWork.pdf Αρχειοθετήθηκε 2012-01-19 στο Wayback Machine.
9. http://www.iiitb.ac.in/uploads/pdf_docs/os2010_3c.pdf
10. http://searchservervirtualization.tech_target.com/tip/Paravirtualization-explained
11. http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf
12. http://www.dell.com/downloads/global/power/ps3q05-20050191-Abels.pdf
13. https://web.archive.org/web/20100922190000/http://bits.xensource.com/Xen/docs/user.pdf
14. http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf