Το πιο συνηθισμένο πράγμα στον κόσμο όταν έχετε διακομιστή, είναι να σκεφτείτε την ασφάλεια και περισσότερη ασφάλεια, δεν μπορείτε ποτέ να είστε αρκετά παρανοϊκοί
Μία κάπως συνηθισμένη πρακτική και ΔΕΝ συνιστάται, είναι να χρησιμοποιείτε τον ίδιο χρήστη για όλες τις βάσεις δεδομένων, χειρότερα εάν χρησιμοποιείται root, το οποίο όσο απίστευτο φαίνεται, υπάρχουν εκείνοι που (λόγω αδαφίας ή άγνοιας) Κάντε αυτό, έχω ήδη μιλήσει γιατί δεν πρέπει να συμπεριφέρεστε έτσι μια άλλη θέσηΤώρα ήρθε η ώρα να εξηγήσουμε πώς και γιατί είναι καλύτερο να διαχωρίσουμε την επεξεργασία του διακομιστή ιστού σε διαφορετικούς χρήστες, αυτή τη φορά θα χρησιμοποιεί nginx.
Τι είναι αυτό των χρηστών και του διακομιστή ιστού;
Για να το εξηγήσουμε με έναν σύντομο και απλό τρόπο, ο διακομιστής διαδικτύου (apache, nginx, οτιδήποτε άλλο) χρειάζεται να ανοίξει διαδικασίες στο σύστημα, διαδικασίες που θα είναι αυτές που λαμβάνουν τα αρχεία από το σκληρό δίσκο (εικόνες κ.λπ.) και τα κάνουν διαθέσιμο στο πρόγραμμα περιήγησης του πελάτη. Ο διακομιστής ιστού δεν μπορεί απλώς να πάρει τα αρχεία και να τα χειριστεί ότι δεν είναι κανένας, δηλαδή, χρειάζεται ένας χρήστης που θα είναι αυτός που θα κάνει όλα αυτά στο τέλος και αυτός ο χρήστης είναι αυτός για τον οποίο μιλώ, καταλαβαίνετε;
Τι είναι αυτό του διαχωρισμού σε πολλούς χρήστες;
Ας υποθέσουμε ότι στον διακομιστή μας έχουμε 2 ιστότοπους, δικούς μας που είναι ένα προσωπικό έργο και έναν άλλο (ας φανταστούμε ότι είναι φίλη ή αδερφή μας). Ακόμα και όταν χρησιμοποιούμε ξεχωριστές βάσεις δεδομένων και διαφορετικούς χρήστες για πρόσβαση σε αυτές, στο τέλος τα αρχεία και των δύο ιστότοπων χειρίζονται από τον ίδιο χρήστη, η επεξεργασία της PHP διαχειρίζεται από τον ίδιο χρήστη για όλους τους ιστότοπους (συνήθως www-data). Αυτή είναι μια μη συνιστώμενη πρακτική, είναι καλύτερα να τα χωρίζετε όλα καλά, όπως λέει μια παλιά παροιμία, είναι καλύτερα να είστε ασφαλείς παρά να λυπάμαι.
Εντάξει, καταλαβαίνω, πώς το κάνω με το Nginx
Το πρώτο πράγμα που πρέπει να σημειωθεί είναι ότι το Nginx δεν έχει τη δική του μονάδα που χειρίζεται την επεξεργασία PHP όπως το Apache, για το Nginx πρέπει να χρησιμοποιήσουμε PHP-CGI ή PHP-FPM, το οποίο λειτουργεί εξίσου καλά (ή καλύτερα) από το Apache. Έτσι, για να διαχωρίσουμε την επεξεργασία PHP σε διαφορετικούς χρήστες, θα χρειαστεί να αλλάξουμε γραμμές σε αρχεία διαμόρφωσης PHP (CGI ή FPM), όχι στο ίδιο το Nginx.
Ας υποθέσουμε ότι χρησιμοποιείτε PHP-FPM, θα δημιουργήσουμε ένα αρχείο διαμόρφωσης του πισίνα Για έναν συγκεκριμένο ιστότοπο, δηλαδή, μια ομάδα είναι ο τρόπος για να διαχωρίσετε την επεξεργασία PHP από την PHP-FPM, αλλά πηγαίνουμε εν μέρει.
1. Πρώτα πρέπει να γνωρίζουμε ποιος χρήστης του συστήματος θα χρησιμοποιήσουμε, θα υποθέσω ότι ακόμα δεν έχουμε δημιουργήσει και, ας το δημιουργήσουμε:
adduser blog
Θα ξεκινήσουμε την κανονική διαδικασία δημιουργίας ενός χρήστη, θα εισάγουμε τον κωδικό πρόσβασης κ.λπ.
1. Αρχικά ας πάμε στο /etc/php5/fpm/pool.d/:
cd /etc/php5/fpm/pool.d/
2. Τώρα, θα δημιουργήσουμε ένα αρχείο που ονομάζεται blog.conf:
touch blog.conf
3. Τώρα θα βάλουμε τη διαμόρφωση του ομίλου που θα χρησιμοποιήσουμε για το ιστολόγιο VHost:
[blog] χρήστης = blog ομάδα = blog ακρόαση = / var / run / php5-fpm-blog.sock listen.owner = blog ακούω.ομάδα = blog pm = ondemand pm.max_children = 96 chdir = /
Σημείωση: Αυτό που τους επισημαίνω με κόκκινο χρώμα είναι αυτό που πρέπει να τροποποιήσουν ανάλογα με τον χρήστη που δημιούργησαν προηγουμένως. Για παράδειγμα, εάν δημιουργήσουν άλλο VHost με άλλο χρήστη (φόρουμ για παράδειγμα) στη συνέχεια, αντί του ιστολογίου απλώς να βάλετε φόρουμ σε κάθε μία από τις γραμμές, είναι κατανοητό;
4. Μόλις διαμορφωθεί η νέα ομάδα (το αρχείο blog.conf που μόλις δημιουργήσαμε και επεξεργαστήκαμεείναι η σειρά να πείτε στο Nginx VHost να χρησιμοποιήσει μια διαφορετική κάλτσα για αυτό το VHost, για αυτόν τον ιστότοπο. Η κάλτσα που θα χρησιμοποιηθεί θα είναι αυτή που είχαμε δηλώσει προηγουμένως (/var/run/php5-fpm-blog.sock). Ας επεξεργαστούμε το Nginx VHost και στο τμήμα επεξεργασίας PHP, υποδεικνύουμε να χρησιμοποιήσουμε αυτές τις κάλτσες. Για παράδειγμα:
τοποθεσία ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.κάλτσα;
συμπεριλάβετε fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }
Όπως μπορείτε να δείτε, δηλώνω ότι η επεξεργασία PHP αυτού του VHost (αυτές οι γραμμές είναι για παράδειγμα στο / etc / nginx / sites-enabled / vhost-blog) κάντε το με τις κάλτσες που βρέθηκαν στο /var/run/php5-fpm-blog.sock ... το οποίο είναι αυτό που δημιουργήσαμε προηγουμένως κατά την επεξεργασία του /etc/php5/fpm/pool.d/blog.conf ... είναι δεν κατάλαβε;
5. Μόλις γίνει αυτό, κάνουμε επανεκκίνηση και των δύο υπηρεσιών (php5-fpm και nginx) και voila, θα δούμε ότι η επεξεργασία αυτού του ιστότοπου (vhost) ΔΕΝ γίνεται από www-data ή root ή οποιονδήποτε παρόμοιο, αλλά από τον χρήστη που εμείς ορίστηκε προηγουμένως.
Εδώ σας δείχνω την έξοδο του a ps aux | grep fpm σε έναν από τους διακομιστές του κόμβου μου:
ps aux | grep fpm ebook 586 0.0 0.0 349360 1204; S Mar30 0:00 php-fpm: ebook ebook 589 0.0 0.0 349360 1204; S Mar30 0:00 php-fpm: ebook pool www 608 0.0 0.2 350084 5008; S Mar30 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048 30; S Mar0 00:3 php-fpm: pool www tv611 0.0 0.0 349360 1204 30; S Mar0 00:3 php-fpm: pool tv3 tv615 0.0 0.0 349360 1204 30; S Mar0 00:3 php-fpm: pool tv1818 περιοδικό 1.7 1.7 437576 36396 09; S 55:0 46:2264 php-fpm: περιοδικό pool pool 1.9 1.7 437332 35884 10; S 15:0 26:2338 php-fpm: μαθητής περιοδικών pool 4.3 1.0 428992 22196 10; S 18:0 53:2413 php-fpm: pool μαθητικό περιοδικό 1.8 1.7 437764 36152 10; S 22:0 18:2754 php-fpm: περιοδικό pool gutl 3.5 1.3 356724 27164 10; S 38:0 00:5624 php-fpm: pool gutl cgr 0.0 1.0 365168 22696 28; S Απρ 0 16:7900 php-fpm: pool cgr μαθητής 0.3 2.5 457052 52444 25; S Απρ 20 23:11021 php-fpm: pool μαθητής μαθητής 0.4 2.5 458316 52864 28; S Απρ 5 57:11254 php-fpm: pool μαθητής cgr 0.0 1.0 363152 21708 28; S Απρ 0 12:13184 php-fpm: pool cgr cgr 0.0 1.0 362872 21360 28; 0 Απριλίου 08:XNUMX php-fpm: pool cgr
Όπως μπορείτε να δείτε ... ο διαχωρισμός της επεξεργασίας PHP από χρήστες που χρησιμοποιούν το Nginx + PHP-FPM είναι πραγματικά εύκολος, εκεί βλέπετε ότι υπάρχουν πολλές ομάδες, καθώς υπάρχουν αρκετοί χρήστες.
Συμπεράσματα
Όσον αφορά τους διακομιστές, δεν είστε ποτέ παρανοϊκοί ... η ασφάλεια δεν είναι κάτι για να παίξετε, όσο περισσότερο προσπαθούμε πάντα να βελτιώσουμε την ασφάλεια των διακομιστών μας και των υπηρεσιών τους, τόσο λιγότερο πιθανό θα φοβηθούμε από ένα (επιτυχημένο) απόπειρα χακαρίσματος ή κάτι παρόμοιο 😉
Γκάρα, στις μέρες μας αυτά τα πράγματα πρέπει να αυτοματοποιηθούν όσο το δυνατόν περισσότερο, σας προτείνω να δοκιμάσετε το Ansible. Χωρίς πράκτορα, χρειάζεστε μόνο python στον απομακρυσμένο κεντρικό υπολογιστή, πολύ απλό στη διαμόρφωση, αρχεία yaml, πρότυπα Jinja.
https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx
Ας δούμε, αυτό δεν είναι πάντα μόνο για ιστότοπους WordPress, και ... χαχα, ίσως ο Ansible κάνει κλικ volao, αλλά προτιμώ να ξέρω ακριβώς πώς όλα λειτουργούν στον διακομιστή, ακόμα κι αν πρέπει να περάσω 1 λεπτό για να δημιουργήσω νέες κάλτσες και ένα νέο VHost 😀
Με το Ansible αυτοματοποιείτε τα πάντα, κάνετε σχεδόν ό, τι θέλετε, το πλεονέκτημα αυτής της μεθόδου είναι ότι ενσωματώνετε την πρακτική και στη συνέχεια εκτελεί κατά βούληση, φανταστείτε ότι έχετε έναν πολύ φορτωμένο ιστότοπο και θέλετε να κάνετε εξισορρόπηση φορτίου μεταξύ διακομιστών εφαρμογών, αυτοί πρέπει να διαμορφωθεί ακριβώς το ίδιο, δεν μπορείτε να παραλείψετε ένα βήμα ή να κάνετε κάτι διαφορετικό σε ένα από αυτά, μπορείτε να φανταστείτε να κάνετε τη διαδικασία βήμα προς βήμα 4 φορές; Με το Ansible είναι τόσο απλό όσο η προσθήκη του ονόματος κεντρικού υπολογιστή στο αρχείο αποθέματος και το Voilá !!
http://www.ansible.com/how-ansible-works
Λυπούμαστε για την λατρεία του Ansible, αλλά είναι μία από αυτές τις τεχνολογίες που ανακαλύπτετε και θέλετε όλοι να τη χρησιμοποιούν τώρα, επειδή είναι τόσο δροσερή και πρακτική, είναι σαν όταν ανακαλύπτετε το NGINX και θέλετε όλοι οι φίλοι σας να φύγουν αμέσως από τον Apache.
https://speakerdeck.com/slok/ansible-all-the-things
Είμαι βέβαιος ότι η ανάρτησή μου συμπληρώνει αυτό ...
http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/
Είμαι (ή μελετώ για να γίνω) προγραμματιστής και με το NGIX είχα πολλά προβλήματα κατά τη διαμόρφωση του nginx + php-fpm. Γνωρίζω ότι το archlinux distro δεν είναι το καλύτερο να το κάνεις ως διακομιστή, αλλά κάθε φορά που ενημερώνω μια έκδοση του ngix ή του php, όλα πάντα συντρίβω, γι 'αυτό εγκατέλειψα την προσπάθεια lol ... Για σήμερα μένω με το κλασικό Apache + PHP αλλά θα δω αν πάω ξανά στο NGIX ... ίσως σε μια εικονική μηχανή
Η νοοτροπία αλλάζει λίγο, το nginx εξυπηρετεί το στατικό περιεχόμενο και χρησιμεύει ως αντίστροφος διακομιστής μεσολάβησης για το php-fpm που είναι αυτός που τρέχει το πραγματικό PHP, πρέπει να ξεκινήσετε σε τμήματα και να επιτύχετε την ανάπτυξη βήμα προς βήμα, αναζητήστε έναν οδηγό για ανάπτυξη το πλαίσιο με το οποίο εργάζεστε, ο καθένας έχει τις λεπτομέρειες του με τα ονόματα του κοινού, στατικό, πόρους κ.λπ.
Κάνετε την κοινότητα τη μεγάλη εύνοια να εγκαταλείψετε τη λέξη "hostear", η οποία δεν υπάρχει. Από τον Θεό, είναι τόσο δύσκολο να πούμε "οικοδεσπότης";
Χαιρετισμούς, ακολουθώντας το παράδειγμά σας, θα ήθελα να μάθω αν θα μπορούσε να δημιουργηθεί μια ομάδα μόνο για το backpress wordpress, δηλαδή για το wp-admin που δημιουργεί μια νέα υποδοχή για εισερχόμενες συνδέσεις στο backend
τοποθεσία / wp-admin {
root /var/www/yoursite.com/wp-admin;
ευρετήριο index.php index.html index.htm;
τοποθεσία ~ ^ / wp-admin /(.+. php) $ {
try_files $ uri = 404;
root /var/www/yoursite.com/wp-admin;
περιλαμβάνουν / etc / nginx / fastcgi_params;
fastcgi_pass server unix:/run/php5-fpm2.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 4k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_read_timeout 1240;
}
location ~* ^/wp-admin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
root /var/www/tusitio.com/wp-admin/;
}
}