Ospita più VHost con utenti diversi in Nginx

La cosa più normale al mondo quando hai un server è pensare alla sicurezza e più sicurezza, non puoi mai essere abbastanza paranoico

Una pratica un po 'comune e NULLA consigliata, è quella di utilizzare lo stesso utente per tutti i database, peggio se viene utilizzato root, il che per quanto incredibile possa sembrare, ci sono quelli che (a causa di vagabondaggio o ignoranza) fai questo, ho già parlato del motivo per cui NON dovresti agire in questo modo in messaggio per bambiniOra è il momento di spiegare come e perché è meglio separare l'elaborazione del server Web in diversi utenti, questa volta verrà utilizzato Nginx.

DedicatedServer_SubImage

Cos'è quello degli utenti e del web server?

Per spiegarlo in modo breve e semplice, il web server (apache, nginx, qualunque sia) ha bisogno di aprire processi nel sistema, processi che saranno quelli che prenderanno i file dall'HDD (immagini, ecc.) E li realizzeranno disponibile nel browser del cliente. Il server web non può semplicemente prendere i file e manipolarli non essendo nessuno, cioè ha bisogno di un utente che sarà quello che alla fine farà tutto questo, e quell'utente è quello di cui sto parlando, capisci?

Cos'è quello da separare in più utenti?

Supponiamo che sul nostro server abbiamo 2 siti web, il nostro che è un progetto personale e un altro (immaginiamo che sia la nostra ragazza o il nostro fratello). Anche quando utilizziamo database separati e utenti diversi per accedervi, alla fine i file di entrambi i siti web vengono manipolati dallo stesso utente, l'elaborazione PHP è gestita dallo stesso utente per tutti i siti (di solito è www-data). Questa è una pratica sconsigliata, è meglio avere tutto ben separato, come dice un vecchio proverbio, è meglio prevenire che curare.

Ok ho capito, come faccio con Nginx

2000px-Nginx_logo.svg

La prima cosa da notare è che Nginx non ha un proprio modulo che gestisce l'elaborazione PHP come fa Apache, per Nginx dobbiamo usare PHP-CGI o PHP-FPM, che funziona altrettanto bene (o meglio) di Apache. Quindi, per separare l'elaborazione PHP tra utenti diversi, dovremo modificare le righe nei file di configurazione PHP (CGI o FPM), non Nginx stesso.

Supponi di usare PHP-FPM, creeremo un file di configurazione di pool Per un sito specifico, cioè, un pool è il modo per separare l'elaborazione PHP da PHP-FPM, ma andiamo in parti.

1. Per prima cosa dobbiamo sapere quale utente del sistema useremo, presumo che ancora non ne abbiamo creato e bene, creiamolo:

Tutti i seguenti comandi DEVONO essere eseguiti con privilegi amministrativi, con root diretto o utilizzando sudo

adduser blog

Inizieremo il normale processo di creazione di un utente, immissione della password, ecc.

Blog l'utente solo per seguire l'esempio, che il primo sito che ospiteremo sarà un blog, beh quello ... per conoscere ogni utente con quale sito è correlato

1. Per prima cosa andiamo su /etc/php5/fpm/pool.d/:

cd /etc/php5/fpm/pool.d/

2. Ora creeremo un file chiamato blog.conf:

touch blog.conf

3. Adesso metteremo la configurazione del pool che useremo per il blog VHost:

Modifica il file blog.conf con nano ... ad esempio: sudo nanoblog.conf
[blog] utente = blog
gruppo = blog
ascolta = / var / run / php5-fpm-blog.sock listen.owner = blog
Listen.group = blog
pm = ondemand pm.max_children = 96 chdir = /

Nota: Quello che li contrassegno in rosso è ciò che devono modificare a seconda dell'utente che hanno creato in precedenza. Ad esempio, se creano un altro VHost con un altro utente (forum per esempio) quindi invece di blog metti semplicemente forum in ciascuna delle righe, è chiaro?

4. Una volta completata la configurazione della nuova piscina (il file blog.conf che abbiamo appena creato e modificato), è il turno di dire a Nginx VHost di utilizzare un calzino diverso per quel VHost, per questo sito. Il calzino che verrà utilizzato sarà quello che abbiamo dichiarato in precedenza (/var/run/php5-fpm-blog.sock). Modifichiamo il Nginx VHost e nella parte di elaborazione PHP, indichiamo di utilizzare quei calzini. Per esempio:

posizione ~ \ .php $ {if (! -f $ nome_file_Richiesta) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.calzino;
include fastcgi_params; parametro_fastcgi SCRIPT_FILENAME $ root_documento $ nome_script_fastcgi; fastcgi_read_timeout 300; }

Come puoi vedere, indico che l'elaborazione PHP di quel VHost (quelle righe sono per esempio all'interno di / etc / nginx / sites-enabled / vhost-blog) fallo con i calzini trovati in /var/run/php5-fpm-blog.sock ... che è quello che abbiamo creato in precedenza durante la modifica di /etc/php5/fpm/pool.d/blog.conf ... è non capito?

5. Fatto ciò, riavviamo entrambi i servizi (php5-fpm e nginx) e voilà, vedremo che l'elaborazione di quel sito (vhost) NON viene eseguita da www-data o root o altri simili, ma dall'utente che noi precedentemente definito.

Qui ti mostro l'output di un file ps ausiliario | grep fpm su uno dei server del mio nodo:

ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool ebook ebook 589 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool ebook www 608 0.0 0.2 350084 5008? S Mar30 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048? S Mar30 0:00 php-fpm: pool www tv3 611 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool tv3 tv3 615 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool tv3 magazine 1818 1.7 1.7 437576 36396? S 09:55 0:46 php-fpm: pool magazine 2264 1.9 1.7 437332 35884? S 10:15 0:26 php-fpm: pool magazine allievo 2338 4.3 1.0 428992 22196? S 10:18 0:53 php-fpm: pool pupil magazine 2413 1.8 1.7 437764 36152? S 10:22 0:18 php-fpm: pool gutl magazine 2754 3.5 1.3 356724 27164? S 10:38 0:00 php-fpm: pool gutl cgr 5624 0.0 1.0 365168 22696? S 28 aprile 0:16 php-fpm: pool cgr allievo 7900 0.3 2.5 457052 52444? S 25 aprile 20:23 php-fpm: piscina allievo allievo 11021 0.4 2.5 458316 52864? S 28 aprile 5:57 php-fpm: allievo della piscina cgr 11254 0.0 1.0 363152 21708? S 28 aprile 0:12 php-fpm: pool cgr cgr 13184 0.0 1.0 362872 21360? S 28 aprile 0:08 php-fpm: pool cgr

Come puoi vedere ... separare l'elaborazione PHP da parte degli utenti usando Nginx + PHP-FPM è davvero facile, lì vedi che ci sono diversi pool, poiché ci sono diversi utenti.

Conclusioni

Quando si tratta di server, non sei mai abbastanza paranoico ... la sicurezza non è qualcosa con cui giocare, più cerchiamo sempre di migliorare la sicurezza dei nostri server e dei loro servizi, meno è probabile che saremo spaventati da un (successo) tentativo di hacking o qualcosa di simile 😉


Lascia un tuo commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

*

*

  1. Responsabile dei dati: Miguel Ángel Gatón
  2. Scopo dei dati: controllo SPAM, gestione commenti.
  3. Legittimazione: il tuo consenso
  4. Comunicazione dei dati: I dati non saranno oggetto di comunicazione a terzi se non per obbligo di legge.
  5. Archiviazione dati: database ospitato da Occentus Networks (UE)
  6. Diritti: in qualsiasi momento puoi limitare, recuperare ed eliminare le tue informazioni.

  1.   cacciatore suddetto

    Gaara, al giorno d'oggi queste cose dovrebbero essere automatizzate il più possibile, ti consiglio di provare Ansible. Senza agente, hai solo bisogno di python sull'host remoto, molto semplice da configurare, file yaml, modelli Jinja.

    https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx

    1.    KZKG ^ Gaara suddetto

      Vediamo, questo non è sempre solo per i siti WordPress, e ... haha ​​forse Ansible fa clic su volao, ma preferisco sapere esattamente come funziona tutto sul server, anche se devo passare 1 minuto a creare un nuovo calzini e un nuovo VHost 😀

      1.    cacciatore suddetto

        Con Ansible automatizzi tutto, fai praticamente quello che vuoi, il vantaggio di questo metodo è che incapsuli la pratica e poi esegui a piacimento, immagina di avere un sito pesantemente caricato e vuoi fare il bilanciamento del carico tra i server delle applicazioni, questi devono essere configurati esattamente allo stesso modo non puoi saltare un passaggio o fare qualcosa di diverso in uno di essi, puoi immaginare di fare la procedura passo dopo passo 4 volte? Con Ansible è semplice come aggiungere il nome host al file di inventario e Voilá !!

        http://www.ansible.com/how-ansible-works

      2.    cacciatore suddetto

        Mi dispiace per il culto Ansible, ma è una di queste tecnologie che scopri e vuoi che tutti la usino ora perché è così bello e pratico, è come quando scopri NGINX e vuoi che tutti i tuoi amici lascino Apache immediatamente.

        https://speakerdeck.com/slok/ansible-all-the-things

  2.   mstaaravin suddetto
  3.   marcisce87 suddetto

    Sono (o studio per diventare) uno sviluppatore e con NGIX ho avuto molti problemi durante la configurazione di nginx + php-fpm. So che la distro archlinux non è la migliore per farla come server, ma ogni volta che aggiornavo una versione di ngix o php tutto andava sempre in crash quindi ho rinunciato al tentativo lol ... Per oggi rimango con il classico Apache + PHP ma vedrò se giro di nuovo NGIX ... magari in una macchina virtuale

    1.    cacciatore suddetto

      La mentalità cambia un po ', nginx serve il contenuto statico e funge da proxy inverso per il php-fpm che è che esegue il vero PHP, devi iniziare in parti e raggiungere il deploy passo dopo passo, cerca una guida da distribuire il framework con cui lavori, ognuno ha i suoi dettagli con i nomi del pubblico, statico, risorse, ecc ...

  4.   anonimo suddetto

    Fai alla comunità il grande favore di abbandonare la parola "hostear", che non esiste. Per Dio, è così difficile dire "ospite"?

  5.   VUOLE suddetto

    Saluti, seguendo il tuo esempio vorrei sapere se è possibile creare un pool solo per il backen di wordpress, ovvero per il wp-admin che crea un nuovo socket per le connessioni in entrata al backend

    location / wp-admin {
    root /var/www/yoursite.com/wp-admin;
    indice index.php index.html index.htm;
    posizione ~ ^ / wp-admin /(.+. php) $ {
    try_files $ uri = 404;
    root /var/www/yoursite.com/wp-admin;
    includere / 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/;
    }
    }