In un post precedente abbiamo spiegato come e perché dopo il 04/03/2020 i certificati Let’s Encrypt sarebbero stati revocati indistintamente anche con i processi avviati in auto-aggiornamento.
Leggete di più al post precedente: Let’s Encrypt scopre il bug CAA e revoca i certificati dei domini sui nostri siti.

Gli utenti i cui certificati sono programmati per essere revocati prima di allora, dovranno forzare manualmente il rinnovo. Questa piccola procedura ora si rivolge ai possessori di Pannelli Plesk, che non hanno ancora ufficializzato il bug. Questo per completare ed arricchire la soluzione del problema spiegato nel post precedente.

Saremo quindi in grado di aggiornare massivamente i certificati Let’s Encrypt anche per chi non ha dimestichezza nell’amministrazione di Web Server se non tramite l’uso del Pannello di Controllo Plesk, diffuso abbondantemente tra i nostri ISP come servizio aggiunto ai Server dedicati e VPS.

La Procedura

• Connettersi in SSH al proprio server
  Potete Utilizzare un qualunque client con protocollo SSH (sempre che il vostro server lo permetta e sia attivato) come ad esempio Putty per Windows, o con il terminale se usate Mac/UNIX base OS.
  
• Modificare o Creare il file /usr/local/psa/admin/conf/panel.ini con le seguenti informazioni:

[ext-letsencrypt]
renew-before-expiration = 365

• Eseguire il task di rinnovo dei certificati Let’s Encrypt

plesk php -dauto_prepend_file=sdk.php '/usr/local/psa/admin/plib/modules/letsencrypt/scripts/keep-secured.php'

• Ripristinare o Rimuovere le informazioni del punto 2

Se non siete amministratore di un server web, o non avete accesso alla console o ai servizi Plesk, chiedete informazioni al vostro ISP di fiducia per adempiere immediatamente alla soluzione del problema. Spesso molti siti sono ospitati in Hosting di servizio, dove non si ha il controllo dei certificati Let’s Encrypt.

Se avete bisogno di maggiori aggiornamenti, oppure chiarimenti su come configurare adeguatamente un server web, non esitate a contattarmi in privato, sono in grado di risolvere qualunque problema riscontriate nelle vostre configurazioni.

Non affidatevi al caso, ma in tema di sicurezza (in questo caso Certificati LET’S Encrypt HTTPS) affidatevi sempre ad una Persona di Competenza.

Un ringraziamento particolare a Lorenzo Crippa per la sua segnalazione.

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio

[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio

Questo articolo elenca alcune delle impostazioni predefinite per server Apache 2.4 installato su un Server Ubuntu. Spiega come applicarli in modo globale a livello server. Se abbiamo dei siti ospitati in in server dedicato o una VPS, questi trucchi ci aiuteranno ad aumentare la sicurezza della nostra permanenza in Rete.

I Nostri obiettivi:

1. Impedire di stampare la firma del server Apache come parte di una richiesta Web: questo non è necessario e fornisce agli aspiranti hacker informazioni sul nostro server.
2. Negare l’accesso diretto a determinati file (ad esempio .git, .json, .sql)
3. Impedire l’esplorazione delle directory: non consentire a estranei casuali di sniffare la nostrs struttura del server.
4. Non consentire di sostituire le config di Apache nelle directory (ad es. Non abilitare i file di configurazione .htaccess)

Tenete presente che se non autorizzate i file .htaccess dovrete probabilmente includere adeguate regole di riscrittura nella configurazione dell’host virtuale Apache in ogni sito. Le impostazioni e configurazioni elencate nel post, vi aiuteranno a rendere più sicuro il server, ma anche renderlo più veloce.

Configurazione Globale di Apache

Aprite il file di configurazione di Apache:

sudo nano /etc/apache2/conf-enabled/security.conf

Apportate le seguenti modifiche:

#...
ServerTokens Prod

#...
Set ServerSignature Off

#...
# Aggiungete il seguente blocco:
# ==============================================================================
# Impedisci l'accesso a qualsiasi directory .git
# ==============================================================================
<DirectoryMatch "/\.git">
    Require all denied
</DirectoryMatch>
# ==============================================================================
# # Proteggi un intervallo specificato di file dall'accesso diretto
# Da notare l'inserimento di files Standard WordPress
# ==============================================================================
<FilesMatch "^(wp-config\.php|php\.ini|php5\.ini|install\.php|php\.info|readme\.md|README\.md|readme\.html|bb-config\.php|\.htaccess|\.htpasswd|readme\.txt|timthumb\.php|error_log|error\.log|PHP_errors\.log|\.svn)">
    Require all denied
</FilesMatch>

# ==============================================================================
# Impedisci l'accesso ai file di configurazione JSON
# ==============================================================================
<FilesMatch "\.(json)$">
    Require all denied
</FilesMatch>

# ==============================================================================
# Impedisci l'accesso ai dump sql: questi NON dovrebbero trovarsi nella radice 
# del documento, ma nel caso non si sa mai...
# ==============================================================================
<FilesMatch "\.(sql)$">
    Require all denied
</FilesMatch>

# ==============================================================================
# Prevenire gli attacchi xmlrpc: se non si utilizza xmlrpc, bloccare questo file 
# per evitare tentativi di hacking. Specie per WordPress.
# ==============================================================================
<FilesMatch "^(xmlrpc\.php)">
  Require all denied
</FilesMatch>

Prevenire l’incorporamento e lo sniffing

Imposta le intestazioni per tutti i file pubblicati:

• L’intestazione NOSNIFF impedisce ai file IE di essere sniffati
• L’intestazione SAMEORIGIN impedisce l’incorporamento di contenuti in siti diversi dal nostro

ATTENZIONE!!!! Per essere operativa questa funzione e non mandare Apache in errore, il modulo headers dev’essere abilitato. Quindi abilitiamolo:

sudo a2enmod headers
# ...e riavviamo Apache con
sudo /etc/init.d/apache2 restart

Aggiungiamo quanto segue a /etc/apache2/conf-enabled/security.conf:

# L'impostazione di questa intestazione impedisce a MSIE di interpretare i file come qualcosa
# diverso da quello dichiarato dal tipo di contenuto nelle intestazioni HTTP.
# Richiede abilitazione mod_headers.
Header set X-Content-Type-Options: NOSNIFF

# L'impostazione di questa intestazione impedirà ad altri siti di incorporare pagine da questo
# sito come frame. Questo difende dagli attacchi clickjacking.
# Richiede abilitazione mod_headers.
Header set X-Frame-Options: SAMEORIGIN

Impedisci la navigazione nella directory

Aprire il file di configurazione pertinente per la modifica:

# Valuta di fare prima un backup dell'originale: 
cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.bak

# Apri il file per la modifica: 
sudo nano /etc/apache2/apache2.conf

Rimuovere o Commentare:

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

Aggiungere questo blocco:

# ------------------------------------------------------------------------------
# Disabilita la navigazione nella directory
# ------------------------------------------------------------------------------
<Directory /var/www/>
        Options -Indexes
        Options FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

… riavviare Apache:

sudo /etc/init.d/apache2 restart

Il vostro server Apache ora dovrebbe essere un po’ più sicuro. Le impostazioni di configurazione sono state applicate a livello globale, anziché in numerosi file .htaccess a livello di directory.

Se avete bisogno di maggiori aggiornamenti, oppure chiarimenti su come configurare adeguatamente un server web, non esitate a contattarmi in privato, sono in grado di risolvere qualunque problema riscontriate nelle vostre configurazioni.

Non affidatevi al caso, ma in tema di sicurezza (in questo caso sicurezza server Apache) affidatevi sempre ad una Persona di Competenza.

Buon Proseguimento.

Corsi e Affini sulla Sicurezza dei Siti Web

[CORSO – CS01LWSA218]

Linux Web Server Administrator

Per chi ha esigenze di gestire web server a livello professionale. Ottima opportunità di competenza da applicare su contratti di management.

Iscriviti Dettaglio

[CORSO – CS08SDR01]

Sistemista di Reti

Dedicato a chi comincia o a chi vuole approfondire le proprie competenze in Networking. Rivolto a CED, Professionisti e appassionati.

IscrivitiDettaglio