Στήσιμο LAMP σε VPS, συμβουλές για best practice;

[parsifal]

Καλημέρα και χρόνια πολλά!

 

 

«Παίζω» αυτήν την περίοδο με ένα VPS που έχω νοικιάσει στη Hetzner. Ξεκινώντας από Debian 6 minimal με το οποίο παραδίδεται το VPS (βέβαια υπάρχει επιλογή και για άλλες διανομές), έστησα LAMP και είμαι σε φάση να ξεκινήσω το deployment ενός PHP-based website.

 

Με προβληματίζουν όμως μερικά θεματάκια και θα ήθελα τις γνώμες και τις συμβουλές σας. Ας παραθέσω πρώτα τις «ιδιαιτερότητες» της περίπτωσης:

 

1. Για αρχή το VPS θα φιλοξενεί ένα μοναδικό Prestashop site, αλλά στο μέλλον πιθανότατα θα προστεθούν και άλλα

2. Τα Linux accounts που υπάρχουν στο VPS είναι αυτήν τη στιγμή δύο: το root για το οποίο έχει κλειδωθεί η SSH πρόσβαση και ένα δικό μου (ας το ονομάσω "webmaster") το οποίο ανήκει στο sudo group και με το οποίο συνδέομαι για να δουλέψω στο VPS

3. Θα ήθελα να προσθέσω στο μέλλον και άλλα accounts για να δώσω τη δυνατότητα και σε επιπλέον άτομα να δουλεύουν επάνω στα sites που στο μέλλον θα φιλοξενεί το VPS. Αλλά χωρίς να έχουν τη δυνατότητα παρεμβάσεων σε επίπεδο συστήματος!

4. Θα προτιμούσα τα παραπάνω να γίνουν χωρίς την εγκατάσταση panels τύπου ISPConfig κλπ. Είμαι fan των απλών, direct, κονσολάτων λύσεων

5. Η PHP αυτήν τη στιγμή είναι στημένη ως Apache module και "the Debian way", δηλαδή τρέχει με τα δικαιώματα του χρήστη www-data του Apache. Αυτό δεν έχω ξεκαθαρίσει ακόμη στο μυαλό μου αν είναι καλό, κακό ή αδιάφορο "security-wise" και τί επίπτωση μπορεί να έχει σχετικά με τα σημεία 1, 2 και 3

 

 

Έχει βρεθεί κανείς στην ίδια ή παρόμοια κατάσταση; Πώς στήνατε τα accounts, τα website directories και τα permissions τους; PHP να τρέχει ως module ή ως CGI με διαφορετικά credentials ανά website;

 

 

Ευχαριστώ εκ των προτέρων για συμβουλές, ιδέες και σκέψεις σας σχετικά με το θέμα!

[parsifal]

Για να μιλάμε και λίγο πιο πρακτικά:

 

Έστω ότι για το υποθετικό site mysite.gr που θα γίνεται host στο VPS υπάρχουν τα εξής directories:

/var/www/mysite.gr
/var/www/mysite.gr/logs
/var/www/mysite.gr/public_html

 

Πως μπορούμε να εξασφαλίσουμε τα παρακάτω;

1. Ο χρήστης www-data μπορεί να διαβάζει υπάρχοντα, να δημιουργεί νέα και να αλλάζει τα υπάρχοντα αρχεία και καταλόγους στο logs; Το αυτό και για τον χρήστη webmaster

2. Τα ίδια με το 1 για τον κατάλογο public_html, με την επιπρόσθετη απαίτηση ότι αν ο χρήστης webmaster δημιουργήσει ένα νέο αρχείο εκεί μέσα, ο χρήστης www-data θα μπορεί επίσης να το αλλάξει

 

 

Ένας τρόπος είναι ο εξής:

 Εγκατάσταση και ενεργοποίηση ACL

> sudo apt-get install acl
> sudo mount -o remount,acl /

 

Δημιουργία καταλόγων για το site με τα παρακάτω ownerships και permissions

> sudo mkdir -m 710 /var/www/mysite.gr
> sudo chown webmaster:www-data /var/www/mysite.gr
> mkdir -m 2770 /var/www/mysite.gr/logs
> sudo chown www-data /var/www/mysite.gr/logs
> sudo setfacl -dm g::rwx /var/www/mysite.gr/logs
> mkdir -m 2770 /var/www/mysite.gr/public_html
> sudo chgrp www-data /var/www/mysite.gr/public_html
> sudo setfacl -dm g::rwx /var/www/mysite.gr/public_html

 

 

 

Μία άλλη προσέγγιση που έχω σκεφτεί είναι η εξής:

Εγκατάσταση και ενεργοποίηση ACL

> sudo apt-get install acl
> sudo mount -o remount,acl /

Δημιουργία user group για το κάθε site

> sudo addgroup --force-badname mysite.gr
> sudo adduser webmaster mysite.gr
> sudo adduser www-data mysite.gr

Δημιουργία καταλόγων για το site

> sudo mkdir -m 710 /var/www/mysite.gr
> sudo chown webmaster:mysite.gr /var/www/mysite.gr
> mkdir -m 2770 /var/www/mysite.gr/logs
> sudo chown webmaster:mysite.gr /var/www/mysite.gr/logs
> sudo setfacl -dm g::rwx /var/www/mysite.gr/logs
> mkdir -m 2770 /var/www/mysite.gr/public_html
> sudo chown webmaster:mysite.gr /var/www/mysite.gr/public_html
> sudo setfacl -dm g::rwx /var/www/mysite.gr/public_html

 

Βλέπετε κάποιο πρόβλημα ή πιθανό κενό ασφαλείας στα παραπάνω; Υπάρχει μήπως καλύτερος τρόπος;

[parsifal]

Ένα bump πριν το αφήσω να αναπαυθεί εν ειρήνη!

[corrupted]

Γιατι δεν βαζεις το θεμα στη κατηγορια "Linux"?

Ειναι καθαρα linuxαδικο θεμα, και εκει θα βρεις Debian users...

[warlock9_0]

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

αυτό που καταλαβαίνω είναι οτι θες στο logs και το public html να έχουν τα ίδια δικαιώματα οι δύο χρήστες?

[parsifal]

Γιατι δεν βαζεις το θεμα στη κατηγορια "Linux"?

Ειναι καθαρα linuxαδικο θεμα, και εκει θα βρεις Debian users...

Είχε ήδη αρκετά views και self-explanatory τίτλο, οπότε δε νομίζω πως είναι θέμα καλύτερου visibility του θέματος από τα σωστά άτομα. Θα το δοκιμάσω κι έτσι όμως, ευχαριστώ!

 

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

αυτό που καταλαβαίνω είναι οτι θες στο logs και το public html να έχουν τα ίδια δικαιώματα οι δύο χρήστες?

OK, εξηγώ όσο πιο συμπυκνωμένα μπορώ:

1. Διαχειρίζομαι το VPS πότε μπαίνοντας με PuTTY και πότε με WinSCP

2. Δε θέλω να δουλεύω ως root, γι' αυτό έφτιαξα τον χρήστη webmaster που έχει και sudo rights

3. Μέσα στον /var/www όμως, κανονικά μπορεί να κάνει αλλαγές μόνο ο root. Έστω ότι για το πρώτο μου site (mysite1.gr) θέλω να χρησιμοποιήσω το PrestaShop. Φτιάχνω ως root ένα /var/www/mysite1.gr, μέσα σε αυτό ένα /var/www/mysite1.gr/public_html. Στο 2ο, κάνω extract τα αρχεία εγκατάστασης του PrestaShop και ορίζω ως owner τον www-data.

4. Αν αργότερα θέλω να κάνω μία διόρθωση σε κάποιο από τα core files του PrestaShop, πώς θα το κάνω συνδεόμενος με WinSCP ως χρήστης webmaster;

5. Αργότερα, έστω ότι το VPS θα φιλοξενεί κι ένα επιπλέον mysite2.gr. Αυτό θα το διαχειρίζεται ένα άλλο Debian account, έστω dev1. Πώς θα επιτύχω το ίδιο με το 4 για τον dev1, χωρίς αυτός να μπορεί να κάνει αλλαγές στο mysite1.gr αλλά μόνο στο mysite2.gr;

 

Πιθανολογώ ότι μπορεί να υπάρχει κάποιο elaborate, δοκιμασμένο σχήμα groups/users/rights/ownerships που χρησιμοποιείται από άτομα που βρίσκονται περίπου στο ίδιο σημείο που βρίσκομαι κι εγώ: δηλαδή δεν επιθυμούν να μεταπωλήσουν hosting στο VPS τους μέσω panels κλπ, αλλά θέλουν να έχουν τη δυνατότητα να φιλοξενούν σε αυτό άνω του ενός sites για φίλους/γνωστούς και ενδεχομένως να δίνουν γι' αυτόν το λόγο περιορισμένης έκτασης πρόσβαση στο VPS σε αντίστοιχα άτομα/accounts.

[warlock9_0]

αν είναι αυτό που λέω γιατί να μην το κάνεις απλά με groups?

βαζεις τους χρήστες που λες οτι θες να δουλεύουν στα site στο group του www-data και δίνεις στους φακέλους που θες write δικαίωμα στο group

[parsifal]

Έκανα επεξεργασία του προηγούμενου μηνύματός μου. Ευχαριστώ για το ενδιαφέρον!

[warlock9_0]

κατάλαβα τι λες
εγώ θα έλεγα να βάλεις σε κάθε site owner το χρήστη που θες

βασικά τώρα που το σκέφτομαι και λίγο είναι επικύνδινο να έχεις www-data ownership και write access οπότε μάλλον αυτό που σου είπα είναι και καλύτερο από άποψη ασφάλειας

 

edit.

από το debian wiki

 

Apache user (www-data)

Debian's Apache packages come configured to run as user 'www-data'. This is potentially confusing: files to be served by apache should not be owned by 'www-data', as apache should not normally be allowed to modify them (i.e. as long as you're not running a wiki).

[parsifal]

Το είχα διαβάσει αυτό το απόσπασμα από το Debian Wiki. Αλλά μου δημιούργησε την εντύπωση πως είναι συντηρητική/απηρχαιωμένη οπτική, ανταποκρινόμενη στην εποχή των στατικών HTML sites και όχι των PHP web apps όπως CMS, eCommerce platforms κ.ά., που πολλά εξ αυτών θεωρούν δεδομένο ότι θα γράφουν κιόλας στον κατάλογο (ή σε κάποιους από τους υποκαταλόγους του) από όπου σερβίρονται. Δες την «πισινή» που κρατάει στο τέλος ("as long as...").

 

Επιπλέον, αν τσεκάρεις τους οδηγούς εγκατάστασης πολλών από αυτά τα έτοιμα πακέτα PHP, θα δεις ότι προτείνουν υπερβολικά φιλελεύθερα δικαιώματα (775 ή ακόμη και 777!) στον κατάλογο εγκατάστασής τους, μιλάμε για τρέλα. Η αλήθεια είναι όμως πως το γράφουν αυτό λαμβάνοντας υπ' όψιν χρήστες shared hosting, που θα ανεβάζουν τα αρχεία εγκατάστασης των πακέτων μέσω WinSCP ή FileZilla σε κάποιο public_html με σφιχτά/περιορισμένα (από την εταιρεία hosting) δικαιώματα.

 

Έχω την εντύπωση ότι υπάρχουν και άλλες πρακτικές πρόσβασης που ίσως (δεν είμαι σίγουρος) να βοηθούν στην παραπάνω κατάσταση όπως chroot/FTP jails, αλλά δεν τις έχω δοκιμάσει ποτέ και γι' αυτόν το λόγο άνοιξα το θέμα.

[warlock9_0]

ftp jail είναι εύκολο να κάνεις και να τον κλείσεις μόνο στο φάκελο του site του

ssh είναι λίγο πιο δύσκολο αλλά και αυτό γίνεται

 

και τα δύο όμως σου προσφέρουν το ίδιο πράγμα όπως το σκέφτομαι με το να ρυθμίσεις σωστά δικαιώματα

 

σε μερικά drupal που έχω φτιάξει και κοίταγα τώρα πχ τα έχω κάνει όλα να είναι απλά readable από τον www-data και να μπορεί να γράψει μόνο σε αυτά που χρειάζεται όπως κάποιο φάκελοι που γίνονται upload εικόνες και τέτοια

όλα είναι του χρήστη που χρησιμοποιώ

κάπως έτσι

 

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

[parsifal]

Αααα, πολύ καλό το άρθρο στο link που δίνεις, ευχαριστώ!

[parsifal]

Καλησπέρα και πάλι. Έχω καταλήξει στο παρακάτω σχήμα πρόσβασης, αν βλέπετε κάτι χτυπητά εσφαλμένο, παρακαλώ επισημάνετέ το!

 

 

 

 

Για το τυχαίο site1.gr, έστω ότι θα έχουμε την παρακάτω υποδομή καταλόγων:

# sudo mkdir -m 710 /var/www/site1
# sudo mkdir -m 710 /var/www/site1/public_html

Δημιουργούμε κι έναν χρήστη π.χ. site1dev, στον οποίον θα δώσουμε παρακάτω πλήρη δικαιώματα παρέμβασης στα αρχεία του site:

 

# sudo adduser site1dev

Επειδή θέλουμε στα αρχεία του site1 να έχουν πρόσβαση read ο χρήστης webmaster καθώς και ο ειδικός χρήστης www-data του Apache, δημιουργούμε ένα σχετικό user group και τους προσθέτουμε σε αυτό:

 

 

# sudo addgroup site1access
# sudo adduser webmaster site1access
# sudo adduser www-data site1access

Τώρα, έστω ότι θέλουμε να εγκαταστήσουμε το τυχαίο PHP application phpapp στο site1. Αποσυμπιέζουμε το archive του στο public_html:

 

 

# sudo 7z x /tmp/phpapp.zip -o/var/www/site1/public_html/

Αλλάζουμε αναδρομικά σε όλους τους υποκαταλόγους του public_html, το user ownership στον χρήστη site1dev και το group ownership στο group site1access:

 

 

# sudo chown -R site1dev:site1access /var/www/site1/public_html

Αλλάζουμε αναδρομικά σε όλους τους υποκαταλόγους του public_html, τα δικαιώματα σε READ/WRITE/EXECUTE (750) για τον owner, READ/EXECUTE (750) για το group και ΤΙΠΟΤΑ (750) για τους υπόλοιπους/άσχετους χρήστες:

 

 

# sudo find /var/www/site1/public_html/ -type d -exec chmod 750 '{}' \;

Αλλάζουμε αναδρομικά σε όλα τα αρχεία του public_html, τα δικαιώματα σε READ/WRITE (640) για τον owner, READ (640) για το group και ΤΙΠΟΤΑ (640) για τους υπόλοιπους/άσχετους χρήστες:

 

 

# sudo find /var/www/site1/public_html/ -type f -exec chmod 640 '{}' \;

Έστω τώρα ότι υπάρχει ένας υποκατάλογος με όνομα upload, στον οποίον η PHP εφαρμογή πρέπει να έχει recursive δικαιώματα WRITE παντού εκεί μέσα. Αυτό τακτοποιείται ως εξής:

 

 

# sudo find /var/www/site1/public_html/upload -type d -exec chmod 770 '{}' \;
# sudo find /var/www/site1/public_html/upload -type f -exec chmod 660 '{}' \;

Έστω ότι υπάρχει κι ένα .htaccess αρχείο καθώς κι ένα sitemap.xml, στα οποία επίσης πρέπει να δοθούν δικαιώματα WRITE (π.χ. για να τοποθετήσει αργότερα εκεί η εφαρμογή μερικούς κανόνες για URL rewriting ή για να διορθώσει το Sitemap κατά το δοκούν):

 

 

# sudo chmod 660 /var/www/site1/public_html/.htaccess
# sudo chmod 660 /var/www/site1/public_html/sitemap.xml

 

 

 

 

Κάπως έτσι θα είναι ΟΚ, σωστά...;

[warlock9_0]

μια χαρά δουλεύουν έτσι με την προυπόθεση οτι είναι μόνο ένας ο dev του site που έχει write (πέρα από τους φακέλους που έχεις ορίσει με το χέρι να έχουν), ο webmaster που ήθελες έχει μόνο read εκτός αν χρησιμοποιήσει sudo

 

κάτι που σκέφτομαι αν έχεις πολλούς developers που θες να πειράζουν τα αρχεία, και τον webmaster μαζί είναι να αντιστρέψεις τα ownerships

δηλαδή να κάνεις owner χρήστη το www-data και group το site1devs πχ

μετά τα δικαιώματα αντίστοιχα με πριν, δηλαδή ο χρήστης θα έχει μόνο read εκτός από όπου χρειάζεται να βάλεις καρφωτά write και το group με όλους του devs και τον webmaster θα έχει και read και write, οι others τίποτα

 

δεν το έχω σκεφτεί καλά ακόμα αλλά νομίζω οτι δουλεύει και έχει την ίδια ασφάλεια με το προηγούμενο