Hardening SSH in Debian


Il server OpenSSH, per impostazione predefinita su Debian Linux, mette a disposizione protocolli di cifratura/cifrari abbastanza deboli.
Ecco in questo articolo un esempio di come rafforzare la sicurezza specificando cifrari più robusti.

Per Debian Jessie o versioni successive (OpenSSH 6.7+), modifica il file /etc/ssh/sshd_config.

In questo file, commenta le chiavi host ssh vulnerabili, lasciando abilitato solo quelle più sicure.

Specifica anche gli algoritmi di scambio di chiavi (kex o KexAlgorithms), i codici di integrità del messaggio supportati (mac) e i tipi di chiavi (key) o i crifrari (Ciphers) più robusti.

Il comando ssh -Q kex mostra gli algoritmi disponibili sul nostro sistema.

Il comando ssh -Q key mostra i tipi di chiave disponibili.

Il comando ssh -Q cipher mostra i cifrari.

Nota: se è necessario collegarsi da/verso client ssh meno recenti, lasciare (facoltativamente) abilitato anche ssh_host_rsa_key, che è uno dei cifrari più vecchi disponibili quasi ovunque.

Protocol 2
#HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

Su Debian, è possibile disabilitare facoltativamente anche la visualizzazione del banner Debian, se lo si desidera (sempre in /etc/ssh/sshd_config) :

DebianBanner no

Riavvia ssh

sudo service ssh restart

Fatto!

(Opzionale)

Controlla la sicurezza del tuo server ssh con questo script: https://github.com/arthepsy/ssh-audit

Ecco il risultato dopo aver applicato i rimedi:

Invece questo host usa cifrari non sicuri:

Questo il risultato dopo aver applicato le modifiche al file sshd_config.

Come aggiornare una distribuzione con Ansible

Nel precedente articolo Primi passi con Ansible, abbiamo visto come configurare l’ambiente Ansible e come predisporre i sistemi pronti ad essere controllati con Ansible. Ora vediamo come aggiornare i pacchetti delle distribuzioni che abbiamo nel nostro parco macchine.

La cosa in se è molto semplice, basta preparare un playbook che permetta l’aggiornamento con gli ultimi update. Eccolo qua:

- hosts: all
  user: ansible_service
  become: yes
  become_user: root
  tasks:
    - name: update all packages
      yum: name=* state=latest

Il tutto è molto succinto e funziona sia su distribuzioni derivate da Red Hat, SuSE e Debian derivate.

Per poter aggiornare un sistema dobbiamo essere root. Quindi il nostro utente di servizio, che abbiamo creato su tutti i server da gestire, chiamato ansible_service deve diventare root: questo è possibile perchè lo avevamo aggiunto nel file sudoers (vedi precedente articolo).

Notare anche che abbiamo fatto uso del modulo yum, che permette l’aggiornamento anche di sistemi senza il comando yum, perchè esso non è il comando yum ma corrisponde ad un modulo che fornisce gli strumenti per la gestione degli update su tutti i sistemi.

Il nostro file inventory contiene i seguenti host, il cui nome in parentesi quadre riporta la distribuzione:

[oracle_linux_8]
192.168.217.14
[suse_15]
192.168.217.10
[linux_mint]
192.168.217.11
[opensuse_15]
192.168.217.13

Dopo aver lanciato il playbook ci troviamo con questo risultato, non proprio “roseo”:

Il primo host con IP 192.168.217.10 (SuSE 15) è fallito.

L’host 192.168.217.11 (Linux Mint) e 192.168.217.13 (Opensuse) non sono stati aggiornati. Il motivo si può scoprire analizzando i log sui due server, ma il troubleshooting è semplice: nessun nuovo pacchetto è disponibile perchè le distribuzioni sono state aggiornate recentemente.

L’ultimo host, quello con IP 192.168.217.14 (Oracle Linux), in giallo è stato aggiornato; questo lo si può desumere perchè non è fallito (failed=0) e che è cambiato (changed=1). Il fatto che esso sia changed indica che il comando impartito ha provocato una modifica nel sistema e la cosa è ovvia visto che è stato aggiornato.

Un errore come “FAILED! => {“msg”: “Missing sudo password”}” può stare a significare che l’utente ansible non ha i privilegi di root, verificate di averli assegnati.

Ad ogni modo, vediamo perchè il primo host è fallito.

Nello screenshot sotto si può leggere che il primo host 192.168.217.10 non è stato aggiornato perchè si sono verificati degli errori, in particolare il tool zypper (l’equivalente di yum/dnf per SuSE) non è riuscito a raggiungere i server dove sono riposti gli update col messaggio “Problem retrieving the repository…” e “The requested URL returned error…”.

Forse leggere l’output in console per qualche server non è un grosso problema ma se avessimo anche solo una decina di host sarebbe preferibile avere un file con il log del comando.

Uno dei modi può semplici per fare ciò è quello di utilizzare il comando tee che consente l’output in console e anche l’output su file. Per esempio col comando:

ansible-playbook -i ~/ansible/inventory/inventory.list ~/ansible/playbooks/yum.yaml | tee ~/update.log

viene creato un file chiamato update.log nella home dell’utente. Il file ~/ansible/inventory/inventory.list è l’elenco dei server da aggiornare, ~/ansible/playbooks/yum.yaml è il playbook che abbiamo creato prima.

Fermare i tentativi di hacking di wordpress con fail2ban

Fail2ban è uno strumento per creare delle regole dinamiche di firewalling al fine di bloccare ripetuti tentativi di hacking o bruteforce.
Ecco un utile post rapido per fermare i tentativi di hacking al tuo server web WordPress come brute force alla wp-login.php e attacchi exploit a xmlrpc.
Installa fail2ban.

sudo apt-get install fail2ban

Dopo aver installato fail2ban, configuralo per rilevare e bloccaree i tuoi host dannosi, aggiungendo queste due regole al tuo file jail su /etc/fail2ban/jail.conf

[worpdress-xmlrpc]
enabled = true
port = http,https
filter = worpdress-xmlrpc
logpath = /var/log/apache/*access.log
maxretry = 3
 
[worpdress-wplogin]
enabled = true
port = http,https
filter = worpdress-wplogin
logpath = /var/log/apache/*access.log
maxretry = 3
bantime = 86400
findtime = 600

Modifica il percorso dove si trovano i file log di Apache o del tuo webserver (anche Nginx). Ora aggiungi due file in /etc/fail2ban/filter.d chiamati worpdress-xmlrpc.conf e worpdress-wplogin.conf con il seguente contenuto:

worpdress-xmlrpc.conf:
	
[Definition]
failregex = ^ .*POST .*xmlrpc\.php.*
ignoreregex =

worpdress-wplogin.conf:

[Definition]
failregex = ^\ \-.*\"POST\ \/wp-login.php HTTP\/1\..*\"
ignoreregex =

Riavvia fail2ban con il comando

systemctl restart fail2ban

Per verificare il corretto funzionamento delle regole si può consultare il log di fail2ban che è /var/log/fail2ban.log

L’aggiornamento del sistema operativo, kernel compreso, senza riavvio

Se c’è una cosa che i sistemi GNU/Linux erano decenni avanti rispetto alla controparte Windows è la gestione del patching.
Un sistemista Windows passava nottate intere a fare il cosidetto WSUS, ossia l’applicazione delle patch di sicurezza e funzionalità, di Windows; senza contare che ogni tot numero di patch installate si doveva riavviare il sistema.

Organizzandosi in una pianificazione trimestrale o semestrale, si finiva per installare oltre la decina di aggiornamenti alla volta riguardanti solo il software Microsoft: Office, Silverlight, .Net Framework, SQL server, Exchange e ovviamente anche quelli relativi il sistema operativo. Poi rimanevano i programmi di terze parti come Adobe, Java. Un incubo.

Con le distribuzioni GNU/Linux tutto è molto più semplice, l’operazione di upgrade è molto rapida: potendo utilizzare un repository software interno, la discriminante la fa la CPU del server e la velocità del disco rigido. Un tempo sicuramente inferiore a quello del patching di Windows a parità di hardware.
Quindi il sistemista Linux rispetto a quello Windows specialmente per sistemi critici da presidiare, lavora meno ore.

L’unica cosa che probabilmente era migliorabile nelle distribuzioni del pinguino era la necessità di dover riavviare la macchina dopo l’installazione di un nuovo kernel.
Un unico riavvio, a fonte dei multipli riavvii necessari a Windows, che però era migliorabile ed eliminabile con un po’ di sforzo; tutto questo per portare l’uptime dei sistemi verso quell’agognato 99,99% su base annua che significa un downtime complessivo di poco inferiore ai 53 minuti all’anno. Possibile?

Oggi, nel 2019, installare le patch di sicurezza e di funzionalità in sistemi GNU/Linux è possibile anche senza riavvio, pur aggiornando il kernel.

Storicamente la prima soluzione, nata circa 10 anni fa, che consente di aggiornare il kernel di un server Linux senza interrompere i processi del sistema e senza riavvio, è Ksplice.
La tecnologia Ksplice fu acquisita da Oracle nel 2011 e implementata, a pagamento, sulla distribuzione Oracle Linux, derivata da Red Hat. Questo ha fatto sì che i maggiori produttori di distribuzioni Linux commerciali Red Hat e SuSE si mettessero in corsa per trovare una loro soluzione. Così sono nati Kpatch (di Red Hat) e Kgraph (di SuSE).
Dalle due soluzioni, ovviamente opensource, come sintesi nel 2016 è nata la versione di Canonical Ubuntu chiamata Livepatch.
Livepatch è gratuita per uso personale fino a 3 sistemi ed è attivabile tramite registrazione sul sito di Ubuntu: https://auth.livepatch.canonical.com/. In seguito è arrivata KernelCare di CloudLinux che ha permesso di attivare la tecnologia su CentOS, Debian e altre distribuzioni.

Certificati SSL


Aggiornato il 22 maggio 2020 – Secondo una definizione più pratica che teorica, i certificati SSL sono dei file che contengono delle informazioni utili per garantire l’integrità dei dati, una comunicazione sicura e l’identità degli interlocutori di una connessione Internet.

SSL è l’acronimo di Secure Sockets Layer e indica il protocolli di sicurezza, nel corso degli anni le varie versioni del protocollo Secure Sockets Layer si sono dimostrate poco sicure per cui oggi, viene usato TLS (Transport Layer Security) che ne eredita le caratteristiche principali.

Quando ci si connette ad un sito di commercio elettronico tipicamente i nostri dati vengono cifrati al fine di evitare che qualcuno possa leggere ad esempio il numero della nostra carta di credito che consente, per chi non lo sapesse ancora, di prelevare il denaro senza possedere fisicamente il pezzo di plastica della carta di credito. Continua a leggere

Cracking WEP


Le reti wireless non sono molto utilizzate solo nelle grandi città  ma anche nei paesi più piccoli è possibile trovarne parecchie. Basta un semplice cellulare che supporti il WIFI per scoprire che passeggiando per una via sono visibili un discreto numero di reti wireless. I dati viaggiano su onde radio che sono in grado di attraversare i muri di uffici o abitazioni e raggiungere anche un centinaio di metri di distanza dall’access point. Continua a leggere

ModSecurity 2 per Debian Lenny


Per una serie di vicissitudini legate alla licenza di distribuzione, il modulo ModSecurity 2 non è stato incluso nei repository ufficiali di Debian Lenny.
Mod-Security è il componente di Apache dedicato alla sicurezza più conosciuto, tuttavia con grande dispiacere non è possibile trovarlo in forma pacchetizzata ufficiale.  Nonostante tutto, non bisogna scaricare i sorgenti per poter adoperare ModSecurity 2 su Lenny.

Continua a leggere

Sniffare le password wireless


phpTpDLhYA volte ci si preoccupa poco della protezione dei propri dati personali, una delle minacce più insidiose è il furto delle credenziali di accesso a un servizio. Se un malintenzionato riesce a rubare la coppia username e password può facilmente accedere agli account sui siti Internet, questo è particolarmente pericoloso quando si accede ad Internet usando una connessione wifi (wireless) non protetta. Come fanno i cracker a ottenere tali informazioni?

Continua a leggere

Sicurezza nelle virtual machine


sicurezza su macchina virtualeIn materia di sicurezza, le virtual machine dovrebbero essere trattate come se fossero dei sistemi fisici, pertanto il software installato andrà mantenuto aggiornato e dovranno essere applicate le varie ed eventuali patch che correggono bug di sicurezza. In più, la scelta dei programmi da eseguire sulla macchina virtuale è da farsi tra una rosa di servizi o applicazioni conosciuti come robusti (poco afflitte da bachi).

Continua a leggere