In questo articolo ti spiegherò, con un esempio, come mettere in sicurezza Rainloop. Se non conosci questo strumento leggi il mio articolo!
Un primo livello di sicurezza lo si ottiene definendo un IP virtuale deputato alla gestione delle richieste di accesso alle porte http ed https. Queste sono le porte del protocollo TCP/IP impiegate per accedere alla webmail Rainloop. Questo indirizzo IP virtuale può essere o associato ad un router/firewall o ad una load balancer virtuale offerti da un Provider di servizi su Internet.
Questa scelta consente di definire una prima linea di protezione da eventuali attacchi di tipo DDOS, garantendo inoltre un mascheramento sulla localizzazione interna del servizio di webmail.
A questo punto (secondo livello) è possibile innalzare il livello di sicurezza definendo un Reverse Proxy. Questo componente riceve il traffico TCP/IP delle porte http ed https indirizzare all’IP virtuale. Il Reverse Proxy potrà essere configurato con un Web Application Firewall per filtrare e prevenire attacchi che possano minare l’affidabilità e la sicurezza della webmail.
Una funzionalità aggiuntiva (terzo livello) potrebbe essere quella di implementare una configurazione per il bilanciamento del carico al fine di distribuire il carico di lavoro su più istanze dell’applicativo webmail.
Riepilogando, abbiamo definito un
1 -> un IP Virtuale;
2 -> un Reverse Proxy;
3 -> una o più istanze dell’applicativo per gestire le richieste.
Adesso vediamo come poter implementare questa istanza dell’applicativo webmail. Una possibile soluzione è quella di definire un container docker per singola istanza di applicativo. Questo approccio consente di raggiungere più obiettivi:
- confinare l’ambiente di esecuzione dell’applicativo Rainloop in un’area sottoposta a stringenti limitazioni in termini di accesso alle risorse allocate (CPU, RAM, spazio disco, accesso alle porzioni di file system allocate con precisi vincoli di accesso). Per come risulta strutturato l’applicativo sono presenti due cartelle ove l’applicativo webmail può accedere. Questo aspetto può essere sfruttato configurando il container con 2 risorse (aree di accesso) con privilegi di accesso diverso. La cartella che contiene il codice php può essere resa disponibile in sola lettura, mentre la sezione ove devono risiedere i dati modificati dall’applicativo può essere configurata in lettura scrittura;
- disporre di un supervisore, il gestore docker, che supervisiona sul corretto funzionamento dell’applicativo webmail consentendo un eventuale riavvio del container in caso di crash applicativo;
- avere a disposizione un ambiente operativo per la webmail indipendente da dove risiede o risulta in esecuzione. Questo consente di definire una configurazione ottimizzata per l’esecuzione della webmail;
- predisporre più repliche della medesima configurazione del container per ottenere un ridondanza dell’applicativo, consentendo di innalzare il livello di disponibilità ed affidabilità del servizio.
Abbiamo innalzato il livello di sicurezza rispetto alla classica soluzione in hosting classico impiegato da molti per installare delle proprie applicazioni php.
È stata definita una protezione in ingresso, cioè da Internet verso l’applicativo.
È possibile applicare una serie di ulteriori politiche di accesso dall’interno verso Internet al fine di blindare l’applicativo.
Come fare per ottenere tutto questo?
Configurando un firewall che definisce regole ben precise sull’accesso dell’applicativo Rainloop verso Internet, ad esempio decidendo di aprire solo le porte imaps e smtps e, in modo ancora più restrittivo, solo verso alcuni provider di posta elettronica.
Riporto un esempio di configurazione del file docker-compose da poter impiegare per realizzare una singola istanza dell’applicativo webmail Rainloop.
services: rainloop1: image: php:7-apache restart: always container_name: rainloop1 ports: - 8881:80 volumes: - "/data/repository/rainloop1/html:/var/www/html:ro" - "/data/repository/rainloop1/data:/var/www/html/data:rw" - "./000-default.conf:/etc/apache2/sites-enabled/000-default.conf:ro" - "/etc/apt/apt.conf.d/01proxy:/etc/apt/apt.conf.d/01proxy" - "/etc/timezone:/etc/timezone:ro" - "/etc/localtime:/etc/localtime:ro" - "./php.ini:/usr/local/etc/php/php.ini:ro" - "./openssl.cnf:/etc/ssl/openssl.cnf:ro"
Come indicato nelle sezioni evidenziate sono montate file o porzioni di spazio fisico nel container al fine di ottenere un’ambiente di esecuzione minimale limitato nell’operatività dell’applicativo. Oltre ad aver previsto di montare delle cartelle applicative, vengono anche personalizzare dei file di sistema del container, in particolare:
- php.ini: in questo file vengono personalizzati delle configurazioni rispetto a quello presente nell’immagine docker, per parametrizzare meglio l’ambiente php;
- openssl.cnf: in questo file viene variata la direttiva CipherString in DEFAULT@SECLEVEL=1.
- 000-default.conf: in questo file vengo impostati le regole di protezione come indicate su sito di Rainloop
Ricordo che è necessario disabilitare alcune Secure Rule del WAF (Web Application Firewall) quali quelle con id: 949110, 980130, 941100, 941160, 200004.
