Συμβουλές σχετικά με security practices

[Blondeamon]

Έχω αναλάβει μια εργασία , μέρος ενος project της σχολής μου (χωρις βαθμολογική συνέπεια) στο οποίο πρέπει να αναφέρω σύντομα (6-7) σελίδες μερικά σημαντικά ζητήματα για πρακτικές ασφαλείας σε open source web environment.

 

Όχι κάτι τρομερό , αλλά συγκεκριμένα πράγματα πάνω σε ζητήματα ασφαλείας που μπορείς να συναντήσεις σε open source περιβάλλον και πως να τα αντιμετωπίσεις. Πχ ο δικός μου server ειναι στημένος με debian και lighttpd και τρέχω SMF Forums και Joomla για μερικά domains. Τα πάντα δηλαδή ειναι ανοικτού κώδικα.

 

Σκέφτομαι να αναφέρω κάποια πράγματα για την σημασία του .htaccess , για αντιμετώπιση XSS attacks , κάποιες πρακτικές που εφαρμόζω για login με encryption στον server κλπ

 

Κάποιες παλιές καραβάνες έχουν καμιά ιδέα τι άλλο θα μπορούσα να συμπεριλάβω?

[Maniakos]

Άμα είναι κάτι open source (οπότε όλοι έχουνε πρόσβαση στο κώδικα) και βρεθεί bug που μπορεί να κάνει ζημιά δεν νομίζω ότι μπορείς να κάνεις και πολλά από το να βάλεις όσο πιο γρήγορα γίνεται το update

 

Άλλα προβλήματα που θα μπορούσες να αναφέρεις πάντως είναι αυτά που προέρχονται από SQL Injections (με το να μην κάνεις escape αυτά που στέλνεις στην βάση εν συντομία) ή από uploading scripts που δεν κάνουνε καλούς ελέγχους πχ το extension του file που ανεβάζει ένας χρηστης οπότε κάποιος θα μπορούσε να ανεβάσει ένα php script και μετά απλά να το κάνει execute από το browser του.

 

Επίσης θα μπορούσες να αναφέρεις για unencrypted user passwords στην βάση (το σωστό θα ήταν να είναι encrypted και ακόμα καλύτερα να υπάρχει και salting ) καθώς και για unencrypted remember me cookie που έχει μέσα του το username+password του χρήστη για να κάνει auto-login την επόμενη φορά που θα μπει στο site.

 

Βέβαια δεν είμαι σίγουρος άμα εννοούσες σαν end user ενός έτοιμου συστήματος τι μπορείς να κάνεις ή άμα είσαι ο developer γιατί στην 1η περίπτωση δεν νομίζω ότι μπορείς να κάνεις και πολλά πέρα του updating που είπαμε στην αρχή.

[Blondeamon]

Σαν server administrator μιλάμε πάντα , οχι admin σε joomla ή κατι παρόμοιο. Πλήρη έλεγχο ενςο dedicated που τρέχει τα παντα σε open source.

 

Ευχαριστώ για τις συμβουλές, πολλές απο αυτες τις ειχα υπολογίσει , μου αρεσε ειδικα το κομματι με το salting που ειχα ξεχασει.

[Maniakos]

Σαν server administrator δεν νομίζω ότι έχεις κάποια σχέση με το development κομμάτι. Άμα υπάρχει κακός κώδικας όπου μπορεί να δημιουργήσει πρόβλημα σοβαρό στο installation δεν μπορείς να κάνεις και πολλά. Σαν server admin η δουλειά σου περιορίζεται στο αν υπάρξει κακός κώδικας να μην επηρεάσει και τα υπόλοιπα accounts αλλά παραμόνο αυτό στο οποίο έγινε το hack. Απο εκεί και πέρα...βρίστε τους developers

[parsifal]

Μπορείς να κάνεις και μία αναφορά σε πιο χαμηλού επιπέδου μέτρα που υπάρχουν διαθέσιμα για το «σφίξιμο» του συστήματος, όπως SELinux [1] [2], AppArmor, kernel hardening [3] κ.ά.

[Blondeamon]

@maniakos: Ναι έχεις δίκιο , απλά πρέπει να αναφέρω ποιες πρακτικές θα πρέπει να χρησιμοποιώ για να κρατάω τον server πιο ασφαλή.

 

@parsifal: Super thanks , θα τα συμπεριλάβω

[nske]

Παραδείγματα που μπορώ να σκεφτώ αυτή τη στιγμή:

 

• Seperation των υπηρεσιών, σε virtual συστήματα (βλ. Linux Openvz ή FreeBSD jails)
  
• Ελαχιστοποίηση των πόρων στους οποίους θα έχει πρόσβαση κάθε εφαρμογή -και ειδικά οι υπηρεσίες- με κάποιο MAC system (βλ. SElinux ή GRsecurity)
  
• Αναλυτικό Logging οτιδήποτε μπορεί να παράγει syslog messages, οργάνωση των messages και αποστολή τους σε απομακρυσμένο syslog server
  
• Έλεγχος του traffic για ύποπτα patterns και λήψη αντιμέτρων (ενημέρωση διαχειριστή, αυτόματη προσθήκη σχετικών κανόνων στο firewall, κλπ) σε συγκεκριμένες ενέργειες (βλ. π.χ. Snort)
  
• Ελαχιστοποίηση των δημόσια προσβάσιμων υπηρεσιών, π.χ. χρήση VPN για οτιδήποτε σχετίζεται με διαχείριση
  
• Κρυπτογράφηση του swap space
  
• mount noexec τα filesystems των χρηστών
  
• Υποχρεωτική χρήση κρυπτογράφησης σε κάθε επικοινωνία που ενδέχεται να εξυπηρετήσει ευαίσθητα δεδομένα (https, imaps, sftp, κλπ)
  
• Διάφορα σκόρπια καλούδια που προσθέτει το GRsec patchset
  
• SSP - PaX και ASLR
  
• Τακτική αλλαγή κωδικών και κλειδιών κρυπτογράφησης
  
• Αναλυτικό φακέλωμα και alerts για οποιαδήποτε συμπεριφορά έξω από το σύνηθες παρατηρηθεί στο σύστημα, π.χ. αλλαγή υπαρχόντων αρχείων ή αδικαιολόγητη δημιουργία νέων.
  
• Για την PHP το Suhosin

Αλλά είναι μόνο μερικά ανάμεσα σε πολλά παραδείγματα, οι χρυσοί κανόνες είναι δύο:

1. Least privilege approach (αν δεν υπάρχει λόγος κάτι ή κάποιος να έχει πρόσβαση σε κάποιον πόρο, ή να μπορεί να πραγματοποιήσει μια ενέργεια, τότε να του απαγορεύεται, ή, πιο σωστά, να του απαγορεύονται όλα εκτός από αυτά ακριβώς που χρειάζεται)
   
2. Know your stuff (τι κάνουν, τι μπορούν να κάνουν και σε κάποιο βαθμό πώς το κάνουν, τα εργαλεία και οι τεχνολογίες που ούτως ή άλλως χρησιμοποιεί κάποιος -ο kernel, το PAM, το filesystem, ο httpd, ο sshd, οτιδήποτε)

Αν υπάρχουν αυτοί οι κανόνες στη νοοτροπία του διαχειριστή, όλα τα άλλα ακολουθούν -και υπάρχουν αμέτρητα εργαλεία, τεχνικές και ιδέες που μπορούν να χρησιμοποιηθούν.

[Blondeamon]

Moυ είπανε επίσης να κοιτάξω και SSL, SSH, SELinux ή AppArmor, denyhosts h fail2ban, ACL, logwatch ,ΟpenVPN.

 

Και recompile όλα τα προγράμματα με το FORTIFY_SOURCE feature του GCC compiler γιατι προσφέρει κάπιια ασφάλεια εναντια στα buffer overflow attacks

 

http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29

[Maniakos]

Blondeamon, αν τελικά σε ενδιαφέρει το server administration security αυτα που έγραψα ήταν άσχετα (καθώς και το XSS attacks που αναφέρεις) αφού δεν είναι καν στην ευθύνη του administrator οπότε μάλλον θα πρέπει να τα παραλήψεις από την εργασία σου.

[Blondeamon]

Blondeamon, αν τελικά σε ενδιαφέρει το server administration security αυτα που έγραψα ήταν άσχετα (καθώς και το XSS attacks που αναφέρεις) αφού δεν είναι καν στην ευθύνη του administrator οπότε μάλλον θα πρέπει να τα παραλήψεις από την εργασία σου.

 

Θα μπορούσες να βοηθήσεις με κάποια που δεν ανέφεραν τα παιδιά ή πάνω κάτω καλύφθηκαν τα περισσότερα?

[Maniakos]

Δεν νομίζω ότι είμαι ο καταλληλότερος για να δώσω κάποιες συμβουλές. Τα παιδιά παραπάνω είπαν κάποια χρήσιμα πράγματα και ίσως στο Linux section να πάρεις ακόμα περισσότερες απαντήσεις.

 

Μπορώ όμως να προτείνω δυο βιβλία που είχα διαβάσει κάποτε - καθαρά από ενδιαφέρον για το Linux security και όχι για κάτι παραπάνω - που θα μπορούσες να συμβουλευτείς.

 

1. Bob Toxen - Real World Linux Security (ISBN: 0-13-028187-5)

2. SAMS - Maximum Linux Security

 

Το 1ο είναι μακράν ανώτερο. Το 2ο εγώ έχω το 2nd Edition, πιθανόν να έχει βγεί και πιο φρέσκο. Αν εχεις χρόνο πάντως θα σου πρότεινα να διαβάσεις του Bob Toxen.

[apoikos]

Moυ είπανε επίσης να κοιτάξω και SSL, SSH, SELinux ή AppArmor, denyhosts h fail2ban, ACL, logwatch ,ΟpenVPN.

 

Και recompile όλα τα προγράμματα με το FORTIFY_SOURCE feature του GCC compiler γιατι προσφέρει κάπιια ασφάλεια εναντια στα buffer overflow attacks

 

http://fedoraproject.org/wiki/Security/Features#Compile_Time_Buffer_Checks_.28FORTIFY_SOURCE.29

 

Blondeamon:

 

Αν και σε γενικές γραμμές συμφωνώ με τον nske, θα ήθελα να προσθέσω 2-3 πιο αναλυτικά σχόλια.

 

Κατ' αρχάς ξεκινάς με μολύβι και χαρτί. Καταγράφεις τι πόρους χρειάζεται η υπηρεσία σου:

• Ανοίγει αρχεία; Αν ναι, ποια; Πόσα από αυτά πρέπει να είναι εγγράψιμα;
  
• Χρειάζεται δικτυακή πρόσβαση; Αν ναι, από που. Χρειάζεται να ανοίγει η ίδια η υπηρεσία νέες συνδέσεις προς τα έξω;
  
• Χρειάζεται να έχει από κοινού πρόσβαση σε αρχεία με άλλες υπηρεσίες; Έχει γενικά αλληλεξαρτήσεις;
  

 

Από 'κει και έπειτα, με βάση την καταγραφή, πρέπει να φροντίσεις τα εξής:

 

1. Filesystem permissions
   Εδώ είναι δύο οι βασικές αρχές:
   α) Προστατεύεις τα ευαίσθητα αρχεία και δίνεις read access μόνο όπου είναι απαραίτητο. Ένα world-readable ssl key file ας πούμε, μπορείς να το θεωρείς ήδη compromised
   β) Δίνεις write access, με απόλυτη προσοχή, μόνο όπου πραγματικά χρειάζεται. Η τυπική σύσταση που κάνουν όλα τα php-o-scripta («κάνε chmod 777 το τάδε») είναι επικίνδυνη και προέρχεται από ανθρώπους με μηδενικό ενδιαφέρον για την ασφάλεια. Ποτέ δεν κάνουμε κάτι world writable, εκτός και αν προορίζεται εξαρχής γι' αυτό το σκοπό (π.χ. /tmp, /var/tmp). Επιπλέον, στα world-writable directories βάζουμε πάντα το sticky bit (chmod 1777 αντί για σκέτο 777) και owner τον root, διαφορετικά δίνουμε δυνατότητα στους χρήστες να σβήνουν ο ένας τα αρχεία του άλλου. Επιπλεόν, αποφεύγουμε να βάζουμε server-writable πράγματα κάτω από το document root. 99% των πετυχημένων επιθέσεων που έχω δει ήταν επειδή μπορούσε ο web server να γράψει κάτω από το document root, επομένως ο επιτιθέμενος απλά ανέβαζε ένα ωραίο php script και μετά το καλούσε με το browser του.
    
   
2. Firewall
   Το firewall πρέπει πάντα να είναι της λογικής «απορρίπτω τα πάντα, αφήνω μόνο αυτά που θέλω». Αυτό θα σε γλιτώσει τόσο από δικά σου λάθη («σήκωσα το τάδε service για δοκιμές και το ξέχασα up»), όσο και από το server process που θα προσπαθήσει να σηκώσει ο επιτιθέμενος.
    
   
3. Γενικότερη πρόσβαση
   Γενικά η πρόσβαση στο μηχάνημα είναι ένα σημαντικό θέμα. Οι γενικές κατευθυντήριες γραμμές είναι οι εξής:
   
   • Όπου περνάει password, καλό είναι να είναι κρυπτογραφημένο. Αυτό σημαίνει χρήση SSH και όχι telnet, sftp/scp/sshfs αντί για ftp, προστασία με ssl του administrative interface της εφαρμογής κλπ.
     
   • Η πρόσβαση θα πρέπει να επιτρέπεται ρητά, αντί να απαγορεύεται ρητά. Όλες οι διανομές που ξέρω π.χ., επιτρέπουν σε οποιονδήποτε χρήστη του συστήματος να κάνει login μέσω SSH. Επειδή κατά 99% κάποια στιγμή θα φτιάξεις ένα χρήστη "test" με password "test", δε θα θες αυτός ο χρήστης να έχει ssh πρόσβαση. Αυτό που προσωπικά κάνω, είναι να χρησιμοποιώ το "AllowGroups" directive στο sshd_config, για να επιτρέπω την πρόσβαση μόνο στα μέλη ενός συγκεκριμένου group (π.χ. ssh_users), στο οποίο προσθέτω εγώ τους χρήστες που θέλω να έχουν πρόσβαση.
     
   • Αν κριθεί ότι η πρόσβαση πρέπει να είναι ακόμα πιο περιορισμένη, τότε θα πρέπει να εξεταστεί και η λύση του 2-component authentication: πρόσβαση SSH μόνο με κλειδιά με passphrase, πρόσβαση σε admin interfaces μόνο με SSL certificates κλπ
     

 

[*] Συντήρηση λογισμικού

Ένα πολύ σημαντικό κομμάτι της ασφάλειας είναι η συντήρηση του ίδιου του λειτουργικού συστήματος. Επειδή η υπηρεσία που τρέχεις (π.χ. lighttpd) δεν είναι μόνη της, αλλά επηρεάζεται από ένα σύνολο συστημάτων του λειτουργικού (από τον πυρήνα και τη glibc, μέχρι την οποιαδήποτε βιβλιοθήκη χρησιμοποιεί), είναι σημαντικό να βρίσκεται όλοκληρο το λειτουργικό σε καλή κατάσταση. Μερικές συμβουλές:

• Καλό είναι να χρησιμοποιούνται πακέτα της ίδιας της διανομής, εφόσον είναι διαθέσιμα. Αυτό εξασφαλίζει σε ένα βαθμό την ακεραιότητα του συστήματος (π.χ. μέσω των ψηφιακών υπογραφών). Αν κάπου δεν υπάρχει διαθέσιμο πακέτο, τότε θα τα sources που θα χρησιμοποιηθούν, πρέπει να προέρχονται ει δυνατόν από έμπιστη πηγή.
  
• Πρέπει να ενεργοποιούνται οι μηχανισμοί αυτόματης ενημέρωσης της διανομής. Π.χ. στο debian, με ένα apticron ή ένα cron-apt, μπορείς να έχεις αυτόματη ενημέρωση για τις νέες εκδόσεις πακέτων μέσω e-mail, ακόμα και αυτόματη εγκατάσταση.
  
• Γράψου στις λίστες ασφαλείας της διανομής (π.χ. debian-security-announce) και των 2-3 βασικών προγραμμάτων που χρησιμοποιείς. Αυτό θα σου επιτρέψει να έχεις έγκαιρη και πλήρη ενημέρωση για το τι ακριβώς συμβαίνει
  

 

Θα ήθελα να κλείσω τη (μακροσκελή) δημοσίευση με μια παρατήρηση: η ασφάλεια είναι πρώτα απ' όλα πληροφόρηση και γνώση. Αν κάτι δεν το γνωρίζεις καλά, είναι καλύτερο να μην το χρησιμοποιείς, μέχρι να καταλάβεις ακριβώς πως λειτουργεί. Αυτό ισχύει προτίστως για τα role-based access control systems (π.χ. selinux, apparmor κλπ), αφού η πολυπλοκότητα που εισάγουν είναι μια επιπλέον πηγή κενών ασφαλείας, εφόσον δε ρυθμιστούν σωστά. Εκ πείρας, οι standard μηχανισμοί του UNIX security model (permissions, permissions και permissions) δουλεύουν μια χαρά στο 99,9% των περιπτώσεων, αρκεί να ξέρεις να τους χρησιμοποιείς σωστά. Από 'κει και πέρα, για πιο απαιτητικές εφαρμογές, έχω αρχίσει να εκτιμώ τις λύσεις των containers (π.χ. OpenVZ), που προσφέρουν ένα απομονωμένο - αλλά πλήρες - περιβάλλον στις ευαίσθητες εφαρμογές. Έτσι, αν είσαι εξτρεμιστής, μπορείς να τρέξεις τα fcgi processes σε ένα container, και να δώσεις πρόσβαση στον apache μέσω ενός κανονικού filesystem socket.

[Blondeamon]

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

[NullScan]

Γαμώτο, πως και δεν το είδα το thread νωρίτερα.

100% σε αυτά που είπαν ο nske με τον apoiko προσθέτω μόνο ότι τα patches σε οποιοδήποτε mission critical σύστημα δεν περνιούνται απ' ευθείας εκεί, καλό είναι να υπάρχει ένα isolated και ελεγχόμενο περιβάλλον το οποίο θα προσομοιάζει το δυνατόν περισσότερο αυτό που έχεις και να περνάς πρώτα εκεί τα οποιαδήποτε patches για να είσαι σίγουρος οτι α. φτιάχνουν το πρόβλημα που λένε και β. δεν δημιουργούν κάποι άλλο εμφανές. Τρέχεις εκεί τα security scanners σου, δοκιμάζεις attacks απέναντι στο υποτίθεται φτιαγμένο bug και μετά από εύλογο χρονικό διάστημα ευθέως ανάλογο με το μέγεθος του bug αλλά και του patch, εφαρμόζεις το fix στο κανονικό σύστημα.

Και φυσικά θα επαναλάβω ότι όλες οι υπηρεσίες που θα μπορούσαν να αποδειχθούν security holes για το σύστημα τρέχουν σε chrooted περιβάλλον ή σε containers. Οι λύσεις εδώ αλλάζουν από λειτουργικό σε λειτουργικό.

Δεν θα πρέπει, τέλος, να ξεχάσεις το disaster recovery κομμάτι το οποίο θεωρώ μέρος του security συστήματος που θα εφαρμόσεις. Πώς γίνονται τα backups, ποια αρχεία κάνεις backup και που τα αποθηκεύεις. Προβλέπεις από πριν σε ποιες περιπτώσεις τραβάς το καλώδιο από το πριζάκι και σε ποιες αφήνεις τον εισβολέα να περιηγηθεί στο σύστημα όσο εσύ μαζεύεις logs και πληροφορίες για το ποιος είναι. Οι περιπτώσεις εδώ αλλάζουν ανάλογα με τη νομοθεσία της χώρας που βρίσκεσαι αλλά κει την σπουδαιότητα της διαθεσιμότητας του (έστω και compromised) συστήματος.

Κάνε bookmark το site του CVE (Common Vulnerabilities and Exposure) και παρακολούθησε το καθημερινά.

Επίσης αν δεν ξεφεύγει από το scope της εργασίας, μπορεί να χρειαστεί να ρυθμίσεις να κάνεις το logging σε άλλο σύστημα και όχι στον ίδιο το server. Τέλος, κοίταξε και λίγο την ιστορία με τα honey-pots όπου μπορείς να στήσεις ένα ολόκληρο εικονικό δίκτυο με ειδικά software ώστε να ξεγελάσεις τυχόν εισβολέα αλλά ρίξε και μια ματιά σε IDS (intrusion detection systems) που μπορούν αυτοματοποιημένα να σηκώνουν red flags σε περιπτώσεις όπως DDoS ή port scans ώστε να λάβει ο admin τα ανάλογα μέτρα.

Βέβαια, η ασφάλεια ενός συστήματος δεν είναι μονοδιάστατη όπως συζητάμε τώρα. Ασφάλεια του server πρέπει να θεωρείται και το configuration των routers/firewalls/proxy servers/DMZs μέσα από τα οποία περνάει η σύνδεση του συστήματος για να βγεί στο Internet, όσο περισσότερα στρώματα ασφαλείας υπάρχουν τόσο πιό ασφαλές είναι το σύστημα. Αν η εργασία σου περιλαμβάνει και αυτά ευχαρίστως να σου δώσουμε πληροφορίες. Σαν επιμύθιο: κανένα σύστημα δεν είναι ασφαλές 100%, υπάρχει μόνο ασφάλεια σε άμεση εξάρτηση με την σημαντικότητα των δεδομένων που κρατά και τα επίπεδα ασφάλειας (αριθμητικά αλλά και σε sophistication) που το προστατεύουν.

Αυτά τα ολίγα και τα ανακατεμένα.

EDIT: συγγνώμη προκαταβολικά για τα πολλά ανακατεμένα Ελληνικά και Αγγλικά.

[firewalker]

 

Καλησπέρα κύριοι.

 

Για τυχόν απορίες: