Enrico Marogna

Proteggere un sito con autenticazione HTTP su Apache

Enrico Marogna — Sat, 09 Nov 2024 00:00:00 +0000

Proteggere le Directory Apache con l'Autenticazione di Base

Se gestisci un sito web con Apache e hai bisogno di limitare l'accesso ad alcune directory, l'autenticazione di base rappresenta una soluzione semplice ed efficace. Questa guida ti spiegherà come configurare l'autenticazione di base su Apache per proteggere i tuoi contenuti con un file .htpasswd.

Installazione degli Strumenti Apache

Per iniziare, assicurati che il sistema sia aggiornato e installa apache2-utils, che include htpasswd, uno strumento per gestire le credenziali degli utenti:

sudo apt update
sudo apt install apache2-utils

Creazione degli Utenti

Dovrai creare un file .htpasswd per gestire gli utenti autorizzati. Puoi creare questo file e aggiungere il primo utente con il comando seguente:

sudo htpasswd -c /etc/apache2/.htpasswd username

L'opzione -c crea un nuovo file .htpasswd. Se devi aggiungere altri utenti, esegui il comando senza -c:

sudo htpasswd /etc/apache2/.htpasswd username2

Ogni volta che esegui questi comandi, ti verrà richiesto di inserire e confermare una password per l'utente specificato.

Configurazione del File Apache

Ora, devi modificare la configurazione del sito per abilitare l'autenticazione. Apri il file di configurazione del tuo dominio con nano o un altro editor di testo:

sudo nano /etc/apache2/sites-available/your_domain.conf

Configurazione Predefinita

Ecco un esempio di configurazione predefinita:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName your_domain
    ServerAlias www.your_domain
    DocumentRoot /var/www/your_domain
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory "/var/www/your_domain">
    </Directory>
</VirtualHost>

Aggiunta dell'Autenticazione

Modifica la sezione per abilitare l'autenticazione di base:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName your_domain
    ServerAlias www.your_domain
    DocumentRoot /var/www/your_domain
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory "/var/www/your_domain">
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
    </Directory>
</VirtualHost>

Ecco cosa fanno queste direttive:

AuthType Basic: Specifica il tipo di autenticazione (di base).
AuthName: Il messaggio visualizzato nel prompt di accesso.
AuthUserFile: Il percorso al file .htpasswd creato in precedenza.
Require valid-user: Richiede che l'utente fornisca credenziali valide.

Verifica della Configurazione

Per assicurarti che la configurazione di Apache sia corretta, esegui:

sudo apache2ctl configtest

Se non ci sono errori, dovresti vedere un messaggio che conferma che la sintassi del file è corretta.

Riavvio di Apache

Per applicare le modifiche, riavvia Apache:

sudo systemctl restart apache2

Ora, quando qualcuno tenterà di accedere alla directory protetta, verrà richiesto di inserire un nome utente e una password.

Conclusione

L'autenticazione di base è un ottimo modo per proteggere le sezioni sensibili del tuo sito web con credenziali semplici. Tuttavia, ricorda che questo metodo non cifra i dati. Per una maggiore sicurezza, considera di utilizzare HTTPS per proteggere le comunicazioni tra il server e i client.

Sincronizzare un sito, da un server ad un altro, con uno script Bash

Enrico Marogna — Sat, 24 Aug 2024 00:00:00 +0000

Quando si gestisce un sito, può rendersi necessario spostarlo o sincronizzarlo da un server a un altro. Ad esempio, si potrebbe voler replicare il sito in un ambiente di staging o trasferirlo su un nuovo hosting. In questo articolo, vedremo uno script bash che automatizza questo processo.

Introduzione

Lo script che presento qui permette di sincronizzare un sito da un server sorgente (SOURCE) a un server di destinazione (DESTINATION); effettua una copia dei file del sito e del database MySQL/Mariadb, sostituisce l'URL del sito nel dump del database e lo importa sul server di destinazione. Lo esamineremo passo dopo passo per poi vedere il codice completo.

Configurazione dello Script

Per utilizzare lo script, è necessario configurare alcune variabili che definiscono i percorsi e le credenziali sia del sito sorgente che di quello di destinazione.

In questo esempio si considera un sito WordPress, ma lo script può essere adattato per qualsiasi tipo di sito.

Ecco la sezione di configurazione:

# Configurazione
SOURCE_PATH="/var/www/source.domain.com/wordpress"
SOURCE_DB_NAME="db_source_domain_name"
SOURCE_URL="source.domain.com"

DESTINATION_USER="nome_utente"
DESTINATION_HOST="192.168.0.6"
DESTINATION_PATH="/var/www/destination.domain.com/wordpress"
DESTINATION_DB_NAME="db_destination_domain_name"
DESTINATION_URL="destination.domain.com"

SOURCE_PATH: Percorso completo della cartella del sito sorgente.
SOURCE_DB_NAME: Nome del database MySQL del sito sorgente.
SOURCE_URL: URL del sito sorgente (senza http:// o https://).
DESTINATION_USER: Nome utente per accedere al server di destinazione via SSH.
DESTINATION_HOST: Indirizzo IP o nome del server di destinazione.
DESTINATION_PATH: Percorso completo della cartella del sito di destinazione.
DESTINATION_DB_NAME: Nome del database MySQL del sito di destinazione.
DESTINATION_URL: URL del sito di destinazione (senza http:// o https://).

Come Funziona lo Script

1. Gestione degli Errori

Lo script include una funzione handle_error che gestisce eventuali errori durante l'esecuzione. Se uno dei comandi restituisce un errore, la funzione viene chiamata e lo script termina pulendo eventuali file temporanei creati.

function handle_error {
    echo "Errore su riga $1"
    rm -f /tmp/${SOURCE_DB_NAME}.sql
    ssh "${DESTINATION_USER}@${DESTINATION_HOST}" "rm -f /tmp/${DESTINATION_DB_NAME}.sql"
    exit 1
}

trap 'handle_error $LINENO' ERR

trap: Comando per impostare un'azione da eseguire quando si verifica un errore.

2. Verifica delle Dipendenze

Prima di iniziare la sincronizzazione, lo script verifica che i comandi essenziali (ssh, rsync, mysqldump, sed, scp, mysql) siano installati sulla macchina di origine.

for cmd in ssh rsync mysqldump sed scp mysql; do
    if ! command -v $cmd &> /dev/null; then
        echo "Errore: il comando '$cmd' non è installato." >&2
        exit 1
    fi
done

3. Richiesta di Conferma

Lo script informa l'utente su cosa farà e chiede conferma per procedere.

echo "Questo script sincronizza un sito web da un server SOURCE a un server DESTINATION."
read -p "Vuoi continuare? (s/n): " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Ss]$ ]]; then
    echo "Operazione annullata."
    exit 1
fi

4. Sincronizzazione dei File

Utilizzando rsync, lo script copia tutti i file dal percorso del sito sorgente a quello di destinazione, escludendo eventuali cartelle di cache.

rsync -avz --delete --no-times --no-perms --exclude 'cache/' "${SOURCE_PATH}/" "${DESTINATION_USER}@${DESTINATION_HOST}:${DESTINATION_PATH}/"

-a: Opzione per copiare i file in modalità archivio, mantenendo i permessi, le proprietà e i timestamp.
-v: Opzione per visualizzare l'output dettagliato.
-z: Opzione per comprimere i dati durante il trasferimento.
--delete: Opzione per eliminare i file sul server di destinazione che non esistono più sul server sorgente.
--no-times: Opzione per non copiare i timestamp dei file.
--no-perms: Opzione per non copiare i permessi dei file.
--exclude 'cache/': Opzione per escludere la cartella cache/ dal trasferimento.

5. Dump e Modifica del Database

Lo script esegue il dump del database MySQL sul server sorgente, sostituisce l'URL del sito sorgente con quello di destinazione e trasferisce il dump al server di destinazione.

mysqldump -u root -p"${SOURCE_DB_PASS}" "${SOURCE_DB_NAME}" > "/tmp/${SOURCE_DB_NAME}.sql"
sed -i "s|${SOURCE_URL}|${DESTINATION_URL}|g" "/tmp/${SOURCE_DB_NAME}.sql"
scp "/tmp/${SOURCE_DB_NAME}.sql" "${DESTINATION_USER}@${DESTINATION_HOST}:/tmp/${DESTINATION_DB_NAME}.sql"

mysqldump: Comando per eseguire il dump del database MySQL.
sed: Comando per sostituire il nome del sito nel dump del database.
scp: Comando per copiare il dump del database modificato dal server sorgente a quello di destinazione.

6. Importazione del Database

Infine, il database viene importato sul server di destinazione e vengono eliminati i file temporanei.

ssh "${DESTINATION_USER}@${DESTINATION_HOST}" "mysql -u root -p'${DESTINATION_DB_PASS}' ${DESTINATION_DB_NAME} < /tmp/${DESTINATION_DB_NAME}.sql"

Script Completo

#!/bin/bash

# LO SCRIPT DEVE ESSERE ESEGUITO SUL SERVER "SOURCE"

# ========================================
# Configurazione
# Modifica i valori delle variabili con i tuoi dati
# ATTENZIONE: gli URL devono essere inseriti senza http:// o https:// e senza slash finale, es. "example.com"
# ========================================
SOURCE_PATH="/var/www/source.domain.com/wordpress"
SOURCE_DB_NAME="db_source_domain_name"
SOURCE_URL="source.domain.com"
DESTINATION_USER="nome_utente"
DESTINATION_HOST="192.168.0.6"
DESTINATION_PATH="/var/www/destination.domain.com/wordpress"
DESTINATION_DB_NAME="db_destination_domain_name"
DESTINATION_URL="destination.domain.com"
# ========================================

# Funzione per la gestione degli errori
function handle_error {
    echo "Errore su riga $1"
    # Pulizia in caso di errore
    rm -f /tmp/${SOURCE_DB_NAME}.sql
    ssh "${DESTINATION_USER}@${DESTINATION_HOST}" "rm -f /tmp/${DESTINATION_DB_NAME}.sql"
    exit 1
}

# Imposta il trap per gestire gli errori
trap 'handle_error $LINENO' ERR

# Verifica le dipendenze
for cmd in ssh rsync mysqldump sed scp mysql; do
    if ! command -v $cmd &> /dev/null; then
        echo "Errore: il comando '$cmd' non è installato." >&2
        exit 1
    fi
done

# Spiega cosa fa lo script e chiedi all'utente se vuole continuare o meno
echo "Questo script sincronizza un sito web da un server SOURCE a un server DESTINATION."
echo "Il sito web sarà copiato da SOURCE a DESTINATION e il database sarà esportato da SOURCE, modificato e importato su DESTINATION."
read -p "Vuoi continuare? (s/n): " -n 1 -r
echo
if [[ ! $REPLY =~ ^[Ss]$ ]]; then
    echo "Operazione annullata."
    exit 1
fi

# Chiede la password del database di SOURCE e DESTINATION
read -s -p "Inserisci la password del database di SOURCE: " SOURCE_DB_PASS
echo
read -s -p "Inserisci la password del database di DESTINATION: " DESTINATION_DB_PASS
echo

# Controllo che le password non siano vuote
if [[ -z "${SOURCE_DB_PASS}" || -z "${DESTINATION_DB_PASS}" ]]; then
    echo "Errore: una o entrambe le password sono vuote."
    exit 1
fi

# Controllo la connessione al server DESTINATION
echo "Controllo la connessione al server DESTINATION..."
if ! ssh -q "${DESTINATION_USER}@${DESTINATION_HOST}" exit; then
    echo "Impossibile connettersi al server DESTINATION!"
    exit 1
fi

# Copia i file dal server SOURCE al server DESTINATION
echo "Copia dei file da SOURCE a DESTINATION..."
rsync -avz --delete --no-times --no-perms --exclude 'cache/' "${SOURCE_PATH}/" "${DESTINATION_USER}@${DESTINATION_HOST}:${DESTINATION_PATH}/"

# Dump del database su SOURCE
echo "Eseguo il dump del database su SOURCE..."
mysqldump -u root -p"${SOURCE_DB_PASS}" "${SOURCE_DB_NAME}" > "/tmp/${SOURCE_DB_NAME}.sql"

# Sostituisci il nome del sito nel dump del database
echo "Sostituisco il nome del sito nel dump del database..."
sed -i "s|${SOURCE_URL}|${DESTINATION_URL}|g" "/tmp/${SOURCE_DB_NAME}.sql"

# Copia del dump del database modificato da SOURCE a DESTINATION
echo "Copia del dump del database modificato da SOURCE a DESTINATION..."
scp "/tmp/${SOURCE_DB_NAME}.sql" "${DESTINATION_USER}@${DESTINATION_HOST}:/tmp/${DESTINATION_DB_NAME}.sql"

# Importa il database su DESTINATION
echo "Importo il database su DESTINATION..."
ssh "${DESTINATION_USER}@${DESTINATION_HOST}" "mysql -u root -p'${DESTINATION_DB_PASS}' ${DESTINATION_DB_NAME} < /tmp/${DESTINATION_DB_NAME}.sql"

# Rimuovi i file temporanei
echo "Pulizia dei file temporanei..."
rm -f "/tmp/${SOURCE_DB_NAME}.sql"
ssh "${DESTINATION_USER}@${DESTINATION_HOST}" "rm -f /tmp/${DESTINATION_DB_NAME}.sql"

echo "Sincronizzazione completata!"

Esecuzione dello Script

Per eseguire lo script, è necessario salvare il codice in un file .sh, ad esempio sync_wordpress.sh, e renderlo eseguibile:

chmod +x sync_wordpress.sh
./sync_wordpress.sh

Considerazioni Finali

Per ulteriori necessità di personalizzazione, lo script può essere facilmente adattato per includere altre funzionalità o per gestire scenari più complessi e ricorda che è sempre consigliabile eseguire un backup completo del sito prima di eseguire operazioni di sincronizzazione o migrazione.

Incrementare il volume di un container LXC su Proxmox

Enrico Marogna — Fri, 07 Jun 2024 00:00:00 +0000

In Proxmox, potrebbe essere necessario aumentare lo spazio su disco di un container LXC per gestire più dati o migliorare le prestazioni. Questa guida illustra i passaggi necessari per incrementare il volume di un LXC, verificare i volumi esistenti, ridimensionare il file system e aggiornare la configurazione del container.

Verifica e arresto del container

Prima di effettuare modifiche a un container LXC, è necessario individuarlo e fermarlo. Utilizzare il seguente comando per elencare tutti i container presenti nel sistema:

pct list

Una volta identificato l'ID del container LXC, è possibile arrestarlo utilizzando:

pct stop <ID-LXC>

Controllo del percorso del volume logico

Dopo aver fermato il container, è necessario individuare il percorso del volume logico associato al container specifico. Utilizzare il comando lvdisplay per trovare il volume, filtrandolo con il comando grep:

lvdisplay | grep "vm-<ID-LXC>-disk-0"

Questo comando restituisce il percorso completo del volume logico su cui risiede il container.

Controllo del file system

Prima di ridimensionare il volume logico, è consigliabile eseguire un controllo del file system per verificare l'integrità dei dati. Questo passaggio previene eventuali problemi durante il processo di ridimensionamento. Il controllo del file system può essere eseguito con il comando:

e2fsck -fy /dev/pve/vm-<ID-LXC>-disk-0

Ridimensionamento del volume logico

Una volta completato il controllo del file system, si può procedere con il ridimensionamento del volume logico. Specificare la nuova dimensione desiderata sostituendo XXG con la quantità di spazio desiderata in gigabyte:

lvresize --size XXG /dev/pve/vm-<ID-LXC>-disk-0

Ridimensionamento del file system

Dopo aver aumentato la dimensione del volume logico, è necessario espandere il file system per utilizzare lo spazio aggiuntivo. Questo viene fatto con il comando:

resize2fs /dev/pve/vm-<ID-LXC>-disk-0

Modifica della configurazione del container

Successivamente, è necessario aggiornare il file di configurazione del container per riflettere le nuove dimensioni del volume. Aprire il file di configurazione del container con il seguente comando:

nano /etc/pve/lxc/<ID-LXC>.conf

Nel file di configurazione, individuare la riga rootfs e aggiornare la dimensione del volume:

rootfs: local-lvm:vm-<ID-LXC>-disk-0,size=XXG

Sostituire XXG con la nuova dimensione impostata nel passaggio precedente.

Riavvio del container

Infine, è possibile riavviare il container per applicare tutte le modifiche effettuate:

pct start <ID-LXC>

Conclusione

Questi passaggi consentono di incrementare correttamente il volume di un container LXC su Proxmox, garantendo che lo spazio aggiuntivo sia correttamente allocato e utilizzato dal sistema. È sempre consigliabile eseguire backup regolari prima di apportare modifiche a un sistema di produzione.

Impostare i permessi dei file e delle cartelle su WordPress

Enrico Marogna — Wed, 17 Apr 2024 00:00:00 +0000

Quando si gestisce un sito WordPress, è fondamentale garantire che i permessi dei file e delle directory siano impostati correttamente per mantenere la sicurezza e la funzionalità del sito. Una configurazione errata può esporre il sito a potenziali attacchi, mentre permessi troppo restrittivi possono impedire al sito di funzionare correttamente.

Vediamo uno script Bash che consente di configurare i permessi ideali per un sito WordPress, assicurando che siano impostati in modo sicuro e conforme alle migliori pratiche.

Perché i permessi sono importanti

In un ambiente server, i permessi determinano chi può leggere, scrivere ed eseguire file e directory. Per un sito WordPress, una corretta impostazione dei permessi aiuta a prevenire:

Accessi non autorizzati ai file critici.
Modifiche accidentali o malevole ai file.
Problemi di funzionamento dovuti a permessi insufficienti.

Panoramica dello Script

Lo script proposto è progettato per essere eseguito da un utente con privilegi di root e configura automaticamente i permessi su un'installazione WordPress esistente. Ecco come funziona:

Proprietà dei file: I file e le directory vengono assegnati all'utente e al gruppo www-data, che è tipicamente l'utente del web server su sistemi basati su Linux.
Permessi di directory: Tutte le directory vengono impostate con permessi 755, che consentono al proprietario di leggere, scrivere ed eseguire, mentre altri utenti possono solo leggere ed eseguire.
Permessi dei file: Tutti i file vengono impostati con permessi 644, che consentono al proprietario di leggere e scrivere, mentre altri utenti possono solo leggere.
Permessi speciali: I file wp-config.php e .htaccess ricevono permessi più restrittivi per proteggere le informazioni sensibili e garantire che solo l'utente del web server possa gestirli.

Script bash per impostare i permessi

Di seguito è riportato lo script Bash:

#!/bin/bash

# Verifica se lo script è stato eseguito come root
if [ "$EUID" -ne 0 ]; then
  echo "Per favore, esegui questo script come root"
  exit
fi

# Richiede il nome del dominio per cui si vogliono impostare i permessi
echo "Inserisci il nome del dominio per cui vuoi settare i permessi (esempio.com oppure sub.esempio.com):"
read -p "Dominio: " domain

# Variabili per i permessi
WP_OWNER=www-data # <-- proprietario wordpress
WP_GROUP=www-data # <-- gruppo wordpress
WP_ROOT=/var/www/$domain/wordpress # <-- percorso wordpress
WS_GROUP=www-data # <-- gruppo web server

# Reset dei permessi predefiniti
find ${WP_ROOT} -exec chown ${WP_OWNER}:${WP_GROUP} {} \; # <-- imposta il proprietario e il gruppo
find ${WP_ROOT} -type d -exec chmod 755 {} \; # <-- imposta i permessi delle directory
find ${WP_ROOT} -type f -exec chmod 644 {} \; # <-- imposta i permessi dei file

# Imposta i permessi speciali 
chgrp ${WS_GROUP} ${WP_ROOT}/wp-config.php # <-- imposta il gruppo di wp-config.php
chmod 640 ${WP_ROOT}/wp-config.php # <-- imposta i permessi di wp-config.php

# Crea il file .htaccess se non esiste e imposta i permessi
touch ${WP_ROOT}/.htaccess # <-- crea il file .htaccess se non esiste
chgrp ${WS_GROUP} ${WP_ROOT}/.htaccess # <-- imposta il gruppo del file .htaccess
chmod 644 ${WP_ROOT}/.htaccess # <-- imposta i permessi del file .htaccess

# Imposta i permessi di wp-content
find ${WP_ROOT}/wp-content -exec chown -R ${WP_OWNER}:${WS_GROUP} {} \; # <-- imposta il proprietario e il gruppo di wp-content
find ${WP_ROOT}/wp-content -type d -exec chmod 775 {} \; # <-- imposta i permessi delle directory di wp-content
find ${WP_ROOT}/wp-content -type f -exec chmod 664 {} \; # <-- imposta i permessi dei file di wp-content

echo "I permessi sono stati impostati correttamente" # <-- messaggio di conferma

Come Utilizzare lo Script

Salva lo script: Salva il codice in un file, ad esempio imposta-permessi.sh.
Rendi eseguibile lo script: Usa il comando chmod +x imposta-permessi.sh per renderlo eseguibile.
Esegui lo script: Esegui lo script come root o utilizzando sudo, con il comando sudo ./imposta-permessi.sh.
Inserisci il dominio: Quando richiesto, inserisci il nome del dominio del sito WordPress per il quale desideri configurare i permessi.

Conclusioni

Impostare correttamente i permessi su un sito WordPress è una pratica essenziale per garantire la sicurezza e il corretto funzionamento del sito. Lo script fornito è un ottimo punto di partenza per automatizzare questo processo e assicurarsi che i permessi siano impostati secondo le migliori pratiche.

Recupero IP Originali con il Modulo Apache remoteip

Enrico Marogna — Wed, 17 Apr 2024 00:00:00 +0000

Quando si utilizza un servizio di proxy come Cloudflare, è possibile che l'indirizzo IP registrato nei log del server Apache non sia l'IP reale del visitatore, ma quello del proxy. Questo può rendere complesso monitorare il traffico reale verso il sito. Grazie al modulo remoteip di Apache, è possibile ripristinare l'indirizzo IP originale del visitatore nei log. Questa guida illustra come abilitare e configurare correttamente il modulo remoteip per ottenere gli IP reali dei visitatori.

1. Abilitazione del modulo remoteip

Il modulo remoteip deve essere abilitato sulla macchina. Se non lo è già, è possibile attivarlo con il seguente comando:

sudo a2enmod remoteip

Questo comando consente di abilitare il modulo remoteip, necessario per sostituire l'indirizzo IP del proxy con l'IP originale del visitatore.

2. Configurazione del file di configurazione di Apache

È necessario aggiungere l'intestazione RemoteIPHeader al file di configurazione di Apache per specificare quale header HTTP contiene l'IP originale del visitatore. Con Cloudflare, viene utilizzata l'intestazione CF-Connecting-IP.

Si procede con l'apertura del file di configurazione del sito. Ad esempio, se il file di configurazione si trova in /etc/apache2/sites-available/sub.dominio.it-le-ssl.conf, è possibile modificarlo con il seguente comando:

sudo nano /etc/apache2/sites-available/sub.dominio.it-le-ssl.conf

All'interno del blocco , si aggiunge la seguente direttiva:

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ServerName remoteip.andy.support
RemoteIPHeader CF-Connecting-IP
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Questa configurazione consente ad Apache di leggere l'header CF-Connecting-IP e registrare correttamente l'indirizzo IP originale del visitatore.

3. Aggiornamento del formato dei log di Apache

Per garantire che gli indirizzi IP siano correttamente registrati nei file di log, è necessario aggiornare il formato dei log di Apache. Di default, Apache utilizza il placeholder %h per indicare l'IP dell'host che si connette al server, ma questo potrebbe non riflettere l'IP originale del visitatore. È quindi opportuno sostituire %h con %a, che rappresenta l'IP effettivo corretto dopo l'elaborazione da parte del modulo remoteip.

Il file di configurazione principale di Apache /etc/apache2/apache2.conf deve essere modificato:

sudo nano /etc/apache2/apache2.conf

Si sostituiscono tutte le occorrenze di %h con %a nelle direttive LogFormat. Ad esempio, si modifica la riga seguente:

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

in:

LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined

In questo modo, gli indirizzi IP originali verranno correttamente registrati nei file di log.

4. Creazione del file di configurazione remoteip.conf

Se non è già stato creato, è necessario generare un nuovo file di configurazione chiamato remoteip.conf in /etc/apache2/conf-available/ per gestire le configurazioni globali del modulo remoteip.

Il file può essere creato eseguendo:

sudo nano /etc/apache2/conf-available/remoteip.conf

Al suo interno va inserita la seguente configurazione:

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 127.0.0.1

Questa configurazione indica ad Apache di fidarsi dell'header CF-Connecting-IP fornito da Cloudflare, oltre che del server stesso (127.0.0.1), che potrebbe fungere da proxy locale.

5. Abilitazione del file di configurazione remoteip.conf

Per abilitare la configurazione appena creata, si utilizza il comando:

sudo a2enconf remoteip

Questo comando attiva il file di configurazione remoteip.conf, applicando le modifiche al modulo remoteip.

6. Test della configurazione di Apache

Prima di riavviare Apache, è consigliabile eseguire un test della configurazione per verificare che non siano presenti errori di sintassi. Questo può essere fatto con il comando:

sudo apache2ctl configtest

Se tutto è configurato correttamente, verrà visualizzato il messaggio Syntax OK.

7. Riavvio di Apache

Solo se il test di configurazione ha avuto esito positivo (Syntax OK), è possibile riavviare Apache per applicare tutte le modifiche eseguite:

sudo systemctl restart apache2

Conclusione

Seguendo questi semplici passaggi, è possibile configurare correttamente il modulo remoteip su Apache per ripristinare l'indirizzo IP originale dei visitatori, anche quando si utilizza un servizio di proxy come Cloudflare. Questa configurazione è essenziale per garantire che i log siano accurati, migliorando la gestione e la sicurezza del server.

Backup Hosting: Come Eseguire Backup Crittografati di Virtualhost

Enrico Marogna — Sat, 22 Jul 2023 00:00:00 +0000

Eseguire backup regolari del proprio hosting è una pratica essenziale per garantire la sicurezza e la protezione dei dati. In questo articolo viene illustrato come creare un backup crittografato di tutti i virtualhost presenti su una macchina utilizzando uno script Bash. Questo approccio consente di proteggere i dati sensibili, come i file dei siti web e i database, utilizzando crittografia sicura tramite OpenSSL.

Introduzione

Lo script presentato esegue backup completi e crittografati di tutti i file associati ai virtualhost Apache e dei relativi database MySQL. Per ogni sito, viene generato un archivio contenente i dati e i dump dei database, successivamente crittografati con chiavi asimmetriche. Questo garantisce che solo chi possiede la chiave privata possa decrittare e ripristinare i dati.

Prerequisiti

OpenSSL: Assicurarsi che OpenSSL sia installato sulla macchina.
MySQL/MariaDB: Lo script esegue il backup dei database MySQL o MariaDB, ma può essere adattato per altri tipi di database.
Accesso root o privilegi sudo: Lo script richiede privilegi di amministratore per accedere ai file e ai database.

Preparazione: Generazione delle chiavi di crittografia

Prima di eseguire lo script, è necessario generare una coppia di chiavi RSA per la crittografia dei backup. Questa operazione può essere eseguita con il seguente comando:

openssl req -x509 -nodes -newkey rsa:2048 -keyout domains-key.priv.pem -out domains-key.pub.pem

Questo comando genera una chiave privata (domains-key.priv.pem) e una chiave pubblica (domains-key.pub.pem). La chiave pubblica viene utilizzata per crittografare i backup, mentre la chiave privata sarà necessaria per decrittarli.

Script di backup

Di seguito lo script per eseguire il backup:

#!/bin/bash

# ===== VARIABILI =====
DATE=`date +%Y-%m-%d-%H-%M-%S`
TARGET_FOLDER=/var/www_backups
PUBLIC_KEY=/root/domains-key.pub.pem
FILE_DB_PASSWORD=/root/.secrets/db_psswd.txt

DB_USER=root
DB_PASSWORD=$(cat ${FILE_DB_PASSWORD})

# ===== VERIFICO L'ESISTENZA DELLA CARTELLA DI BACKUP =====
if [ ! -d "$TARGET_FOLDER" ]; then
    echo "La cartella di destinazione non esiste, la creo: $TARGET_FOLDER"
    mkdir /var/www_backups
fi

# ===== VERIFICO L'ESISTENZA DELLA CHIAVE PUBBLICA =====
if [ ! -f "$PUBLIC_KEY" ]; then
    echo "La chiave pubblica non esiste: $PUBLIC_KEY"
    exit 1
fi

# ===== VERIFICO L'ESISTENZA DELLA PASSWORD DI ROOT =====
if [ ! -f "$FILE_DB_PASSWORD" ]; then
    echo "Il file con la password di root non esiste: $FILE_DB_PASSWORD"
    exit 1
fi

# ===== SCRIPT BACKUP DB =====
for dbname in $(mysql -u ${DB_USER} -p${DB_PASSWORD} -e 'show databases' -s --skip-column-names); do
  if [ "$dbname" != "information_schema" ] && [ "$dbname" != "performance_schema" ] && [ "$dbname" != "mysql" ] && [ "$dbname" != "sys" ]; then
    ARCHIVE_DB="${dbname}-dump-${DATE}.backup.sql.gz.enc"
    mysqldump -u ${DB_USER} -p${DB_PASSWORD} --single-transaction --routines --events --triggers --complete-insert "$dbname" \
    | gzip -9 -c \
    | openssl smime -encrypt -binary -text -aes256 -out ${TARGET_FOLDER}/${ARCHIVE_DB} -outform DER ${PUBLIC_KEY}  
  fi
done

# ===== SCRIPT BACKUP FILES =====
for virtual_host in /etc/apache2/sites-available/*.conf; do
    virtual_host=$(basename $virtual_host .conf)
    if [ ! -d "/var/www/$virtual_host" ]; then
        echo "La cartella /var/www/$virtual_host non esiste, passo al successivo"
        continue
    fi
    ARCHIVE_FILES="${virtual_host}-files-${DATE}.backup.tar.gz.enc"
    tar -cvpzf /root/${virtual_host}.${DATE}.tar.gz -C /var/www/ $virtual_host
    openssl smime -encrypt -binary -text -aes256 -in /root/${virtual_host}.${DATE}.tar.gz -out ${TARGET_FOLDER}/${ARCHIVE_FILES} -outform DER ${PUBLIC_KEY}
    rm /root/${virtual_host}.${DATE}.tar.gz
done

Spiegazione del codice

Variabili: Le variabili definiscono la data e l'ora attuali (DATE), la cartella di destinazione del backup (TARGET_FOLDER), il percorso della chiave pubblica (PUBLIC_KEY) e il file che contiene la password del database MySQL (FILE_DB_PASSWORD).
Verifica delle Cartelle e dei File: Prima di eseguire il backup, lo script verifica se la cartella di destinazione, la chiave pubblica e il file con la password del database esistono. Se la cartella non esiste viene creata, ma se la chiave pubblica o il file con la password non sono presenti, lo script termina con un messaggio di errore.
Backup dei Database: Per ogni database, viene eseguito un dump tramite mysqldump, compresso con gzip e crittografato utilizzando la chiave pubblica. I file di backup vengono salvati nella cartella di destinazione.
Backup dei File dei Virtualhost: Per ogni virtualhost configurato in Apache, viene creato un archivio compresso (tar.gz) contenente i file del sito web, crittografato con la chiave pubblica e salvato nella cartella di destinazione.

Ripristino dei backup

Per ripristinare i backup, è necessario decrittografare i file utilizzando la chiave privata. Ecco come eseguire il processo di decrittazione ed estrazione:

# DECRIPTAZIONE ED ESTRAZIONE
FILENAME=indicare_il_nome_del_file # ad esempio domain.local-files-2023-03-06-16-03-45.backup.tar
openssl smime -decrypt -in ${FILENAME}.gz.enc -binary -inform DER -inkey domains-key.priv.pem -out ${FILENAME}.gz
gzip -d ${FILENAME}.gz
tar -xvf ${FILENAME}

Considerazioni finali

Utilizzando questo script, è possibile eseguire backup regolari e crittografati di tutti i file e database ospitati su una macchina. La crittografia garantisce che i dati siano protetti da accessi non autorizzati, mantenendo al sicuro informazioni sensibili anche in caso di compromissione dei file di backup.

Questo script rappresenta una base solida per automatizzare il processo di backup su un hosting e può essere facilmente adattato a necessità specifiche, come l'invio di backup a un server remoto o l'aggiunta di notifiche in caso di errori.

Oh-My-ZSH su Synology NAS

Enrico Marogna — Fri, 06 May 2022 00:00:00 +0000

La Z shell, anche nota come zsh, è probabilmente la miglior shell multipiattaforma disponibile e non ha di certo bisogno delle mie presentazioni. Oh-my-zsh invece è il framework, essenziale e imprescindibile, da integrare a zsh per estenderne le sue funzionalità tra cui una marea di plugins e temi.

Utilizzarli sul NAS Synology è abbastanza semplice. Prima di tutto è necessario installare zsh in questo modo:

Qualora già non lo fossero, abilitare i pacchetti di SynoCommunity.
Successivamente installare dal Centro Pacchetti git(se non è ancora installato) e Z shell (NB: non la versione "with modules").

Facile facile.

Per installare oh-my-zsh sarà necessario procedere tramite ssh:

sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

Per tutta una serie di motivi di sicurezza non ho impostato zsh come shell di default ma la vado a richiamare nel momento in cui mi collego, tramite ssh, in questo modo:

rilevo la posizione di zsh:

which zsh

e ottengo qualcosa di simile a:

/usr/local/bin/zsh

aggiungo alla stringa per collegarmi a ssh -t '/usr/local/bin/zsh -l':

ssh paperino@192.168.0.2 -p 22 -i ~/.ssh/id_rsa_paperino -t '/usr/local/bin/zsh -l'

Non rimane che personalizzare il framework con temi e plugins, tra i quali consiglio git, docker-compose, aliases e z.

SYNOLOGY DS720+ - SSL Certificato Let’s Encrypt wildcard

Enrico Marogna — Thu, 14 Oct 2021 00:00:00 +0000

Testato su DSM 6.2.4

Collegarsi via SSH al server NAS come indicato in questo articolo dedicato, eottenere i ì permessi root

sudo -i

Posizionarsi nella cartella radice

cd /

A questo punto è neccesario scaricare lo script acme.sh

wget https://raw.githubusercontent.com/Neilpang/acme.sh/master/acme.sh

Assegnare i permessi di esecuzione allo script

chmod a+x acme.sh

Successivamente si emette il certificato, avendo cura di sostituire enricomarogna.com con il proprio dominio

./acme.sh --issue -d *.enricomarogna.com --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

Si ottiene un output di questo tipo

Registering account
Registered
ACCOUNT_THUMBPRINT='abjJHFIUTDGIBDYDDJBDJKkhHk'
Creating domain key
The domain key is here: /root/.acme.sh/*.enricomarogna.com/*.enricomarogna.com.key
Single domain='*.enricomarogna.com'
Getting domain auth token for each domain
Getting webroot for domain='*.enricomarogna.com'
You need to add the txt record manually.
Add the following TXT record:
Domain: '_acme-challenge.enricomarogna.com'
TXT value: 'ThIsISNoTtHeReAlKeY'
Please be aware that you prepend _acme-challenge. before your domain
so the resulting subdomain will be: _acme-challenge.enricomarogna.com
Please add the TXT records to the domains, and re-run with --renew.
Please add '--debug' or '--log' to check more details.

I dati di interesse sono Domain e TXT value e devono essere utilizzati nella gestione del DNS, nel mio esempio su Google Domain:

Una volta che il record è stato registrato, avviare lo script acme.sh con il flag --renew. Nota: Generalmente l'aggiornamento del DNS avviene in qualche minuto, ma il tempo potrebbe variare in base al provider. Lanciare lo stesso comando dopo 3 mesi per il rinnovo del certificato.

./acme.sh --renew -d *.enricomarogna.com --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please

Se tutto va bene, si ottiene un output come quello riportato di seguito:

Your cert is in /root/.acme.sh/*.enricomarogna.com/*.enricomarogna.com.cer
Your cert key is in /root/.acme.sh/*.enricomarogna.com/*.enricomarogna.com.key
The intermediate CA cert is in /root/.acme.sh/*.enricomarogna.com/ca.cer
And the full chain certs is there: /root/.acme.sh/*.enricomarogna.com/fullchain.cer

Adesso copia i file in una cartella accessibile sul NAS. Nel mio caso ho creato una cartella chiamata Certs con la sottocartella enricomarogna.com al suo interno.

cp "/root/.acme.sh/*.enricomarogna.com/*.enricomarogna.com.cer" "/volume1/Certs/enricomarogna.com/enricomarogna.com.cer"
cp "/root/.acme.sh/*.enricomarogna.com/*.enricomarogna.com.key" "/volume1/Certs/enricomarogna.com/enricomarogna.com.key"
cp "/root/.acme.sh/*.enricomarogna.com/ca.cer" "/volume1/Certs/enricomarogna.com/ca.cer"
cp "/root/.acme.sh/*.enricomarogna.com/fullchain.cer" "/volume1/Certs/enricomarogna.com/fullchain.cer"

Vedrai che i file saranno nella cartella dopo aver eseguito le azioni cp.

Puoi chiudere la sessione SSH ora e per motivi di sicurezza, puoi anche disabilitare SSH. Tutto ciò che devi fare ora è importare il certificato sul Synology se lo desideri o iniziare semplicemente a usarlo dove ne hai bisogno!

Se usi il tuo Synology come reverse proxy e ssl ofloader come me, questo è molto utile! Vai al Pannello di controllo, quindi Sicurezza e Certificato. Scegli Aggiungi.

Poi importa il certificato

Inserisci i file richiesti.

Ora sei a posto e hai un certificato Let’s Encrypt wildcard.

Connessione sicura via SSH al Synology NAS

Enrico Marogna — Thu, 14 Oct 2021 00:00:00 +0000

I NAS Synology consentono il collegamento via terminale tramite ssh e per farlo è necessario abilitare il servizio:

Pannello di Controllo > Terminale e SNMP > Attiva Servizo SSH

La porta standard è la 22, se ne consiglia però la personalizzazione con una differente.

Utilizzo i seguenti dati:

client: Macbook Pro
server: Synology NAS con DSM 6.2.4
username: paperino
indirizzo ip del server: 192.168.0.2
porta ssh del server: 22

Per connettersi tramite terminale dal client è necessario utilizzare la sintassi ssh -p numero_della_porta username@indirizzo_ip, quindi:

ssh -p 22 paperino@192.168.0.2

Viene richiesto a questo punto l'inserimento della password per l'utente paperino e la connessione al server dovrebbe essere stabilita.

È chiaro quindi che ogni volta si voglia connettersi mediante SSH al server remoto è necessario inserire la password ma questo, oltre ad essere molto scomodo soprattutto se viene utilizzata una password robusta, non è il massimo in termini di sicurezza.

E allora? E allora autenticazione a chiave pubblica.

L'utilizzo dell'autenticazione a chiave pubblica SSH per connettersi a un sistema remoto è un'alternativa solida e più sicura dell'accesso mediante password o passphrase. L'autenticazione a chiave pubblica SSH si basa su algoritmi crittografici asimmetrici che generano una coppia di chiavi, una privata e l'altra pubblica.

La chiave privata, di solito denominata id_rsa, è memorizzata sul client. Questa dovrebbe essere tenuta al sicuro, con le autorizzazioni debitamente impostate in modo che nessun altro utente sul computer possa leggere il file.

La chiave pubblica, solitamente denominata id_rsa.pub, è invece posizionata sul server remoto a cui si intende accedere. Questa può essere condivisa liberamente con chiunque.

Generarla è molto semplice:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_paperino

Dove ssh-keygen è il componente della suite Secure Shell dedicato alla generazione delle chiavi, -t rsa è la tipologia di algoritmo di firma digitale scelto, -b 4096 i bits e -f ~/.ssh/id_rsa_paperino il file di input. Rimando a ssh.com per maggiori specifiche.

Vengono generati due file all’interno del path ~/.ssh/, ovvero id_rsa_paperino e id_rsa_paperino.pub, dove il primo è la chiave privata da conservare all’interno del client e il secondo quella pubblica che, come detto, va inviata al server in questo modo:

ssh-copy-id -f -i ~/.ssh/id_rsa_paperino.pub paperino@192.168.0.2 -p 22

Dove ssh-copy-id è il componente dedicato all'installazione delle chiave sul server, -f ne forza la copia anche se questa è già installata, -i ~/.ssh/id_rsa_paperino.pub indica quale chiave copiare e paperino@192.168.0.2 -p 22 si connette al server su cui la si vuole copiare.

Tecnicamente questi passaggi sarebbero già sufficenti, se non fosse che di default il server NAS Synology non è abilitato per la connessione SSH a chiave pubblica. Per abilitarlo ci si collega via SSH con l'inserimento della password:

ssh -p 22 paperino@192.168.0.2

Io utlizzo l'editor nano, ma è utilizzabile qualunque editor:

sudo nano /etc/ssh/sshd_config

de commentare le righe PubkeyAuthentication yes e AuthorizedKeysFile .ssh/authorized_keys.

Passaggio fondamentale è quello dedicato all'essegnazione dei giusti permessi.

Sul server:

sudo chmod 755 .
sudo chmod 755 ~/.ssh
sudo chmod 644 ~/.ssh/authorized_keys

Sul client:

sudo chmod -R 755 ~/.ssh
sudo chmod -R 600 ~/.ssh/*

Riavviare il servizio sul server:

synoservicectl --restart sshd

oppure disabilitare e riabilitare il servizio SSH in Pannello di controllo > Terminale e SNMP

Aggiungere la nuova chiave all'ssh-agent:

eval "$(ssh-agent -s)"

Aggiungere la chiave alla keychain usando il comando:

ssh-add -K ~/.ssh/id_rsa_paperino

Questo dovrebbe essere sufficiente per potersi collegare via SSH senza inserire la password e in modo sicuro:

ssh paperino@192.168.0.2 -p 22 -i ~/.ssh/id_rsa_paperino

Per rendere la procedura di connessione sensibilmente più snella consiglio la creazione di un alias (rimando a DuckDuckGo se non si conosce l'argomento), qualcosa del tipo:

alias sshsynonas="ssh paperino@192.168.0.2 -p 22 -i ~/.ssh/id_rsa_paperino"

Per connettersi sarà sufficiente dare il comando:

sshsynonas

Homebrew: Il gestore di pacchetti per MacOS

Enrico Marogna — Wed, 13 Oct 2021 00:00:00 +0000

Homebrew è un gestore di pacchetti open-source, ampiamente utilizzato nell'ecosistema macOS, che semplifica l'installazione, l'aggiornamento e la gestione di software non inclusi nel sistema operativo. Grazie alla sua flessibilità e alla vasta comunità di sviluppatori, Homebrew è diventato uno strumento indispensabile per personalizzare ed estendere le funzionalità di macOS.

Prerequisiti

CPU 64-bit Intel
macOS 10.12 o superiore
Command Line Tools (CLT) per Xcode: xcode-select --install, developer.apple.com/downloads o Xcode
Una shell Bourne-compatibile come ad esempio bash o zsh

Installazione

L'installazione di Homebrew è rapida e intuitiva. È sufficiente eseguire il seguente comando nel terminale:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Al termine dell'installazione, è consigliabile aggiornare l'indice dei pacchetti disponibili:

brew update

Utilizzo

Usare Homebrew per gestire i nostri software preferiti è molto semplice, anche se non si è degli abitué della riga di comando, in questo modo brew <comando> <nome_del_pacchetto>. Vedremo qui i comandi più utilizzati ma per una lista completa ed esaustiva, come sempre, è bene fare riferimento alla documentazione ufficiale. Facciamo alcuni esempi. Supponiamo di voler installare speedtest-cli, un tool a riga di comando per testare la velocità della connessione internet.

brew install speedtest-cli

Digitando questo comando Homebrew procedere per noi a scaricare e installare il software:

==> Downloading https://github.com/sivel/speedtest-cli/archive/v2.1.1.tar.gz
==> Downloading from https://codeload.github.com/sivel/speedtest-cli/tar.gz/v2.1.1
######################################################################## 100.0%
🍺  /usr/local/Cellar/speedtest-cli/2.1.1: 7 files, 83.2KB, built in 4 seconds

Ma se invece avessimo installato il software errato e lo volessimo disinstallare completamente dal sistema? Anche in questo caso Homebrew si mostra molto semplice nell'utilizzo:

brew uninstall speedtest-cli

Procederà autonomamente ad eliminare ogni traccia di quanto precedentemente installato:

Uninstalling /usr/local/Cellar/speedtest-cli/2.1.1... (7 files, 83.2KB)

Cask

Con Homebrew i possibile installare anche software proprietari ad interfaccia grafica, come ad esempio Spotify. Supponiamo però di non conoscere il nome del pachetto (non sempre il nome di quest'ultimo è intuitivo, se volessi installare Telegram il nome del pacchetto è telegram-desktop-dev) possiamo utilizzare la funzione search in questo modo:

brew search spotify

Il risultato sarà una lista di pachetti (in questo caso spotify ha la spunta ✔ perchè ho già installato questo software sul mio Mac):

==> Casks
spotify ✔                         spotify ✔                         spotify-notifications            
spotify-notifications             spotify-now-playing               spotify-now-playing

I software ad interfaccia grafica vengono gestiti tramite la funzione cask, pertanto, in questo caso, procediamo in questo modo:

brew cask install spotify

Font

Tramite cask è possibile gestire anche i font con libera licenza di distribuzione. Ciò è reso possibile da homebrew-cask-fonts e si installa in questo modo:

brew tap homebrew/cask-fonts

per la ricerca di un font si usa la sintassi:

brew search font- | grep <nome_del_pacchetto>

esempio:

brew search font- | grep fira

ma è anche possibile avere l'elenco di tutti i font disponibili:

brew search font-

l'installazione avviene come un comune pacchetto cask:

brew cask install font-fira-code

e chiaramente anche la disinstallazione

brew cask uninstall font-fira-code

Mas

Homebrew permette anche la gestione di software presenti all'interno di Mac App Store tramite il pacchetto mas. Installiamolo:

brew install mas

Ad esempio, una delle mie applicazioni preferite del Mac App Store, utile nella gestione delle finestre, è Magnet e per installarla procedo in questo modo.

La cerco:

mas search magnet

Mi viene restituito in output un elenco di applicazioni e per ogni riga il numero dell'app, il suo nome e la versione:

[...]
441258766   Magnet   (2.4.6) 
[...]

Infine la installo per mezzo del numero app:

mas install 441258766

Semplice. Pulito. Sicuro.

List

Per ottenere una lista delle applicazioni installate da riga di comando:

brew list

Per la lista delle applicazioni ad interfaccia grafica:

brew cask list

Per la lista delle applicazioni del Mac App Store:

mas list

È possibile concatenare i comandi:

brew list && brew cask list && mas list

Upgrade

Per aggiornare tutte le applicazioni a riga di comando:

brew update

Per aggiornare tutte le applicazioni ad interfaccia grafica:

brew cask upgrade

Per aggiornare tutte le applicazioni del Mac App Store:

mas upgrade

È possibile concatenare i comandi:

brew upgrade && brew cask upgrade && mas upgrade

Per aggiornare una singola applicazione:

brew update <nome_del_pacchetto>

brew cask upgrade <nome_del_pacchetto>

mas upgrade <nome_del_pacchetto>

Ad esempio:

brew cask upgrade spotify

Backup e ripristino

Una delle funzioni che più amo di Homebrew è la possibilità di fare un backup della lista di tutte le applicazioni installate in modo da poterle ripristinare in modo semplice e veloce in caso, ad esempio, di ripristino del sistema operativo, per nuove installazioni o in caso di sostituzione del Mac. Vediamo come procedere:

Installo il pacchetto necessario:

brew tap Homebrew/bundle

Per generare un file di testo con l'elenco delle applicazioni installate:

brew bundle dump

Verrà generato il file Brewfile nella root del Mac aditabile con qualunque file editor. Non dobbiamo far altro che conservare questo file di testo.

Il ripristino è ancora più semplice. Ci portiamo col terminale nella cartella dove abbiamo salvato il Brewfile, ad esempio, supponendo di averlo nella cartella Documenti:

cd Documents

E poi:

brew bundle

Finito. Homebrew installerà per noi tutti le applicazioni del nostro elenco.

Connessioni SSH: Guida Completa per Principianti

Enrico Marogna — Wed, 13 Oct 2021 00:00:00 +0000

Le connessioni SSH (Secure Shell) sono uno strumento essenziale per amministratori di sistema, sviluppatori e chiunque abbia bisogno di gestire server remoti in modo sicuro. Con questa guida, esploreremo le basi delle connessioni SSH, la sintassi principale, le diverse modalità d'uso e i tunnel SSH.

Indice

Che cos'è SSH?

SSH è un protocollo di rete crittografico che consente di accedere e gestire dispositivi remoti tramite una connessione sicura. È ampiamente utilizzato per accedere a server Linux e Unix da remoto, ma è disponibile anche su altri sistemi operativi. La caratteristica principale di SSH è la sua sicurezza: grazie alla crittografia, i dati scambiati tra client e server non possono essere intercettati.

Installazione di SSH

Su molte distribuzioni Linux, SSH è preinstallato. Puoi verificare se SSH è installato con il seguente comando:

ssh -V

Se non è installato, puoi installarlo con:

Ubuntu/Debian:

sudo apt install openssh-client

CentOS/Fedora:

sudo yum install openssh-clients

macOS:

brew install openssh

Come funziona una connessione SSH

Una connessione SSH avviene tra due parti:

Client SSH: Il dispositivo locale che si connette al server remoto.
Server SSH: Il dispositivo remoto che accetta la connessione.

Per avviare una connessione SSH, si utilizza il comando ssh, seguito da alcune informazioni necessarie, come il nome utente e l'indirizzo del server.

Sintassi base di SSH

La sintassi di base del comando SSH è:

ssh [opzioni] utente@host

utente: Il nome dell'utente con cui vuoi accedere al server remoto.
host: L'indirizzo IP o il dominio del server remoto.

Esempio

Supponiamo di voler accedere a un server con l'utente root e l'indirizzo IP 192.168.1.100. Il comando sarà:

ssh root@192.168.1.100

Una volta inviato il comando, il client SSH ti chiederà la password del server remoto (a meno che non utilizzi l'autenticazione basata su chiavi, che vedremo più avanti).

Autenticazione tramite chiavi SSH

Un modo più sicuro per autenticarsi con SSH è tramite chiavi pubbliche e private, eliminando la necessità di inserire la password. Il processo prevede la generazione di una coppia di chiavi crittografiche: una chiave privata (che resta sul tuo dispositivo) e una chiave pubblica (che viene trasferita al server remoto).

Generare una coppia di chiavi SSH

Per generare una coppia di chiavi SSH, utilizza il comando:

ssh-keygen

Segui le istruzioni e salva le chiavi nel percorso predefinito (~/.ssh/id_rsa). Questo creerà due file:

id_rsa: La chiave privata.
id_rsa.pub: La chiave pubblica.

Nella generazione, oltre a poter specificare un nome diverso, è possibile utilizzare ulteriori parametri.

Ad esempio

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_paperino

Questo comando genera una coppia di chiavi RSA con una lunghezza di 4096 bit e le salva in ~/.ssh/id_rsa_paperino. Dove ssh-keygen è il componente della suite Secure Shell dedicato alla generazione delle chiavi, -t rsa è la tipologia di algoritmo di firma digitale scelto, -b 4096 i bits e -f ~/.ssh/id_rsa_paperino il file di input.

Oppure con curve ellittiche, che risultano essere al momento lo standard di sicurezza più elevato:

ssh-keygen -t ecdsa -b 521 -f ~/.ssh/id_ecdsa_paperino

Rimando a ssh.com per maggiori specifiche.

Copiare la chiave pubblica sul server remoto

Una volta generata la chiave, puoi copiarla sul server remoto utilizzando il comando:

ssh-copy-id utente@host

Ad esempio:

ssh-copy-id root@192.168.1.100

Questo comando trasferisce la chiave pubblica al server remoto e permette di accedere senza dover inserire la password ogni volta.

È chiaramente possibile specificare una chiave diverso da ~/.ssh/id_rsa.pub:

ssh-copy-id -i ~/.ssh/id_rsa_paperino.pub root@192.168.1.100

Opzioni avanzate di SSH

SSH supporta numerose opzioni che possono migliorare la tua esperienza di utilizzo e aggiungere funzionalità. Eccone alcune delle più utili:

Specificare una porta diversa

Di default, SSH utilizza la porta 22. Se il server remoto utilizza una porta diversa, puoi specificarla con l'opzione -p:

ssh -p [porta] utente@host

Eseguire comandi remoti

Puoi eseguire comandi su un server remoto senza avviare una sessione SSH interattiva. Basta specificare il comando alla fine della stringa SSH:

ssh utente@host "comando"

Ad esempio:

ssh root@192.168.1.100 "ls /var/www"

Questo comando mostrerà il contenuto della directory /var/www del server remoto.

Tunnel SSH

Una delle funzionalità avanzate di SSH è la possibilità di creare tunnel sicuri, che possono essere utilizzati per inoltrare il traffico da un dispositivo locale a uno remoto in modo sicuro. I tunnel SSH sono utili per proteggere connessioni altrimenti non sicure, come quando si accede a una rete interna o si bypassano restrizioni di rete.

Inoltro locale (Local Port Forwarding)

L'inoltro locale consente di reindirizzare il traffico da una porta del tuo dispositivo locale a una porta su un dispositivo remoto attraverso un server SSH.

Sintassi:

ssh -L [porta_locale]:[host_remoto]:[porta_remota] utente@host_ssh

Esempio:

ssh -L 8080:localhost:80 root@192.168.1.100

Questo comando reindirizzerà tutto il traffico inviato alla porta locale 8080 verso la porta 80 (HTTP) del server remoto attraverso il server SSH.

Inoltro remoto (Remote Port Forwarding)

L'inoltro remoto consente di esporre una porta del tuo dispositivo locale attraverso un server remoto, consentendo ad altri di connettersi a quella porta.

Sintassi:

ssh -R [porta_remota]:[host_locale]:[porta_locale] utente@host_ssh

Esempio:

ssh -R 9090:localhost:3000 root@192.168.1.100

In questo caso, chiunque si colleghi al server remoto sulla porta 9090 sarà reindirizzato alla porta 3000 del tuo dispositivo locale.

Inoltro dinamico (Dynamic Port Forwarding)

L'inoltro dinamico trasforma il tuo dispositivo locale in un proxy SOCKS5. Questo può essere utile per instradare tutto il traffico di rete attraverso il server SSH.

Sintassi:

ssh -D [porta] utente@host

Esempio:

ssh -D 1080 root@192.168.1.100

Dopo aver eseguito questo comando, puoi configurare le applicazioni per utilizzare localhost:1080 come proxy SOCKS5.

Permessi delle cartelle e dei file

Per garantire la sicurezza delle chiavi SSH, è importante impostare i permessi corretti sulle cartelle e sui file. Le chiavi private dovrebbero avere i permessi 600 (rw-------), le chiavi pubbliche 644 (rw-r--r--) e le cartelle .ssh dovrebbero avere i permessi 700 (rwx------).

Puoi impostare i permessi corretti con i seguenti comandi:

sudo chmod 700 ~/.ssh && \
sudo chmod -R 600 ~/.ssh/* && \
sudo chmod -R 644 ~/.ssh/*.pub

Aggiungere la nuova chiave all’ssh-agent del client

Per evitare di dover inserire la password della chiave privata ogni volta che si accede al server remoto, è possibile aggiungere la chiave all'ssh-agent del client.

eval "$(ssh-agent -s)"

ssh-add -K ~/.ssh/id_rsa_paperino

Configurazione di SSH

Puoi personalizzare il comportamento di SSH modificando il file di configurazione ~/.ssh/config. Questo file ti permette di definire alias per i server, specificare opzioni predefinite e configurare tunnel SSH.

Ecco un esempio di file di configurazione:

Host server1
    HostName
    User root
    Port 22
    IdentityFile ~/.ssh/id_rsa

Host server2
    HostName
    User root
    Port 2222
    IdentityFile ~/.ssh/id_rsa_paperino

Host *
    ServerAliveInterval 60
    Compression yes

In questo esempio, abbiamo definito due alias per i server server1 e server2, specificando l'indirizzo IP, l'utente, la porta e il file di chiave per ciascuno. Inoltre, abbiamo configurato alcune opzioni globali per tutti i server, come l'intervallo di keepalive e la compressione.

Conclusione

SSH è uno strumento potente e flessibile, essenziale per chiunque lavori con server remoti. Oltre alle connessioni di base, offre molte opzioni avanzate come l'autenticazione con chiavi, l'esecuzione di comandi remoti e la creazione di tunnel sicuri. Una volta padroneggiate queste funzionalità, sarai in grado di gestire server e applicazioni in modo sicuro ed efficiente.

Retropie su Raspberry Pi 3 - Guida completa

Enrico Marogna — Fri, 13 May 2016 00:00:00 +0000

RetroPie è un sistema operativo che consente di emulare alcune delle console più datate direttamente sul Raspberry Pi. Nintendo, Sega, Playstation, Atari, Game Boy e tanti altri. Qui una lista completa delle console supportate. Tutto quello di cui si ha bisogno per iniziare:

Raspberry Pi (A, A+, B, B+, Zero, 2, 3)
Un alimentatore da 5V 2.5A
Scheda SD da minimo 8GB su cui installare RetroPie
Cavo HDMI
Gamepad e/o tastiera
Cavo Ethernet o Wifi dongle (nel Raspberry Pi 3 e’ gia’ integrato)
Case per Raspberry Pi (opzionale ma e’ raccomandato)
Lettore di schede Micro SD
Memoria esterna per caricare le ROM dei giochi

Io ho acquistato direttamente il kit da Amazon a poco piu’ di 70€, che comprende:

Raspberry Pi 3
Alimentatore da 5V 2.5A originale
Micro SD “Sandisk” da 16 GB con adattatore SD
Cavo HDMI
Cavo di rete Ethernet
Case originale

Per la tastiera ho invece optato per una WiFi (comodissima anche come telecomando della smart TV), sempre su Amazon, a poco meno di 20 euro. Ma è possibile trovare validissime alternative.

Non ci rimane a questo punto che scaricare Retropie e copiarlo sulla scheda SD.

Installazione

Utilizzo per questa operazione un Mac quindi procedo tramite ApplePi Baker, intuitivo e facile da utilizzare. Per Windows potete utilizzare invece Win32DiskImager mentre per Linux Unetbootin. Selezioniamo la scheda da utilizzare (troviamo l’elenco delle unità in Pi-Crust) per prepararla alla scrittura e clicchiamo su Prep for NOOBS. Infine, su Pi-Ingredients, cerchiamo in IMG file l’immagine di RetroPie precedentemente scaricata e clicchiamo su Restore Backup. Terminato il caricamento di circa 5 minuti, visibile su Progress, la nostra console sarà pronta per il primo avvio.

Primo avvio e configurazione base

Colleghiamo il Raspberry Pi allo schermo tramite cavo HDMI e, dopo aver inserito la micro sd su cui abbiamo installato RetroPie, alimentiamolo (il Raspberry Pi é privo di un tasto di accensione/spegnimento, si gestisce tramite alimentazione).

La prima schermata ci chiede di configurare il nostro gamepad tenendo premuto un tasto qualsiasi.

Io utilizzo un un vecchio gamepad usb ma, se avete qualche euro in più, vi portate a casa questa meraviglia:

Come dicevo, tenendo premuto un tasto del controller usb, abbiamo la possibilità di configurare tutti i relativi tasti e la nostra console è pronta per portarci indietro con il divertimento.

Dove caricare le rom dei giochi

Per caricare le ROM dei giochi, utilizziamo una memoria esterna, va benissimo una chiavetta (la capienza dipende da quanti giochi volete metterci dentro) e creiamo nella root una cartelle denominata retropie, inseriamola nel Raspberry Pi e attendiamo che il led smetta di lampeggiare. RetroPie creerà, all’interno della cartella retropie della memoria esterna, delle ulteriori sotto-cartelle con i nomi delle varie console al cui interno andremmo ad inserire le ROM dei giochi.

Alcune immagini

SSH

E’ possibile collegarsi al Raspberry Pi tramite ssh utilizzando, come utenze predefinite, username pi e password raspberry. In questa guida, troverete i comandi più comuni che possono esservi utili nella gestione dei file. Qui, invece, un utile how to di per il trasferimento dei file via ssh.

Accensione e spegnimento

Il RPi, come noto, non ha un pulsante di accensione e spegnimento. Sul portale italiano Raspberryitaly è possibile trovare una esaustiva guida per poterne creare uno, riporto sotto l'how to. Se invece non volete perdere tempo, è possibile acquistare un alimentatore con pulsante di accensione/spegnimento integrato. A voi la scelta.

PARTE 0: PREMESSA

Come sappiamo, il RPi non ha un pulsante di accensione ne spegnimento di fabbrica: una volta alimentato si accende immediatamente e per spegnerlo si può usare il comando # poweroff; inoltre dopo essere stato spento, per riaccendere il RPi è necessario scollegarlo e ricollegarlo all’alimentazione (e tanti saluti al connettore!)

Il consumo del RPi è irrisorio, quindi (sotto questo punto di vista) forse non conviene neanche spegnerlo e riaccenderlo, ma potrebbe essere utile per varie ragioni: per esempio, una persona che vive in una zona soggetta a frequenti blackout, salva il RPi da arresti anomali, preservando così il file system. Altra argomentazione potrebbe essere il fatto che la scheda SD, essendo una memoria flash, è soggetta ad usura e più tempo il Raspberry sta acceso, più la SD si consuma.

Ma a inizio articolo abbiamo detto che esiste già un comando per spegnerlo: a cosa dovrebbe servire un pulsante? Può risultare comodo per media center o anche per RPi usati da remoto.

PARTE 1: IL PULSANTE DI ACCENSIONE

Per quanto riguarda il pulsante di accensione bisogna premettere anche che sono necessarie competenze elettroniche: è necessario saldare due cavetti sul nostro RPi (ammetto che anch’io quando l’ho fatto avevo un pò, come dire, di paura!)

Leggete questo articolo per sapere cosa saldare. Una volta saldato i due cavetti al connettore, non ci resta che saldarli alle due estremità di un pulsante NO (NA in italiano), ossia un pulsante che, quando premuto, crea un contatto fra i due morsetti.

Ecco fatto, abbiamo realizzato il nostro pulsante di accensione! Una volta spento il RPi possiamo usarlo per riaccenderlo: molto più comodo che scollegarlo e ricollegarlo!

N.B.: se premete il tasto mentre RPi è acceso, questo si riavvierà e ciò equivale a un arresto anomalo, quindi è da evitare!

PARTE 2: IL PULSANTE DI SPEGNIMENTO

Per quanto riguarda il pulsante di spegnimento: la parte hardware è più semplice ma è necessaria una parte software. che intercetta la pressione del pulsante ed impartisce il comando poweroff.

E’ infatti sufficiente collegare le due estremità di un pulsante NO una au una GPIO e una ad un GND (vi consiglio GPIO 10 così il codice d’esempio funziona senza problemi!).

Per il software invece create il file /root/shutdown_button

sudo nano /root/shutdown_button

E inserite il seguente codice:

#!/usr/bin/python
#-*- coding: utf-8 -*-
import RPi.GPIO as GPIO
import os
GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
#Nelle due righe seguenti, eventualmente sostituire 10 col numero del GPIO a cui avete collegato il pulsante (numerazione GPIO.BCM)
GPIO.setup(10,GPIO.IN,pull_up_down=GPIO.PUD_UP)
GPIO.wait_for_edge(10,GPIO.FALLING)
os.system(“poweroff”)

Diamo i giusti permessi al file coi seguenti comandi:

sudo chown root:root /root/shutdown_button

sudo chmod 770 /root/shutdown_button

Ora modificate il file /etc/rc.local per farlo eseguire in automatico

sudo nano /etc/rc.local

e aggiungete prima dell’ultima riga la seguente:

/root/shutdown_button & #mi raccomando la & finale

in modo che il file sia uguale al seguente (ovviamente se lo avete modificato prima per altri motivi ci avrete anche altre righe)

Premete CTRL+X, digitate Y ed invio.

Ora non ci resta che riavviare il RPi

sudo reboot

Ora, se premete il tasto di spegnimento, il Raspberry si spegne correttamente!

Per concludere vi mostro come ho aggiunto i tasti di accensione e spegnimento al RPi che uso come media center (troverò un modo per indicare qual è ON e qual è OFF, magari delle etichette con stampate le icone di font awesome).

Conclusioni

Questa guida é stata creata più come promemoria per mie future installazioni, in modo da avere tutto assieme ciò che ho trovato un po' sparso per il web, che per una guida definitiva da propinarvi. Non mi assumo quindi responsabilità in caso di malfunzionamenti. Se avete da chiedere delucidazioni o volete fare degli appunti/correzioni, lasciate pure un commento e sarò felice di rispondervi o apportare modifiche al testo. Buon divertimento.

Fonti: Github.com || Retropie.org.uk || Raspberryitaly.com