Hardening SSH : prima di uscire chiudi bene la porta con knockd!

4

openssh

Se siamo così tanto attenti, quando usciamo di casa, a chiudere per bene porte e finestre, perché non dovremmo porre la stessa attenzione quando decidiamo di uscire dal nostro sistema, lasciandoci comunque la possibilità di potervi accedere da remoto ?

Dobbiamo sapere che il nostro sistema Linux, in modo completamente gratuito, ci da in dotazione un energumeno a guardia del nostro fortino: si chiama SSH – Secure SHell – e ne abbiamo già parlato varie volte su questo blog. Lo scopo di questo articolo non è quello di illustrare il funzionamento di SSH ma sarà quello di esplorare tre metodi per mettere un poco più in sicurezza la nostra porta di ingresso, ossia, addestreremo il nostro energumeno di guardia a riconoscere chi può entrare nel nostro prezioso computer e chi invece va…preso a calci.

Questi i tre metodi che illustreremo:

  • Cambiare la porta standard di ascolto del demone SSH e rinforzare la configurazione in modo da bloccare i tentativi di ingresso più semplici.
  • Definire esattamente chi è autorizzato ad entrare.
  • Nascondere completamente l’esistenza di un accesso SSH.

Il primo metodo è l’esempio classico di security through obscurity, un concetto ormai superato – e deriso – che cerca di offrire sicurezza contando sul fatto di essere stati bravi abbastanza a nascondere ciò che vogliamo proteggere. Ciò potrebbe scoraggiare i teneri script kiddies, ma certo non qualcuno veramente intenzionato ad entrare nel nostro sistema. Tuttavia, visto che non ci costa praticamente alcuno sforzo, perché no ? Basta modificare la seguente direttiva nel file di configurazione:

 /etc/ssh/sshd_config

e modificare la porta di ascolto di SSH. Chiaramente la porta non deve essere già in uso da qualche altro processo e soprattutto bisognerà aprirla sul nostro router/firewall.

Port 2022
LoginGraceTime 30
MaxAuthTries 3
Protocol 2
PermitRootLogin no

In questo modo il nostro demone SSH sarà in ascolto sulla porta 2022 (ogni porta superiore alla 1024 può andare bene), non permetterà il login se passano più di 30 secondi per completare l’autenticazione, se si sbaglia ad inserire le credenziali più di tre volte, se si vuole usare versioni di protocollo inferiori (più insicure) alla 2 e se ci si vuole autenticare come utente root.

Come si definisce chi è autorizzato e chi, invece, non lo è ? Molto semplice, sempre nello stesso file di configurazione ci sono le direttive DenyUsers, AllowUsers, DenyGroups e AllowGroups dove è possibile selezionare la pletora di utenti che hanno il permesso di entrare, o solo negare l’accesso ad alcuni. Come anche è possibile permettere o negare l’accesso solo a determinati gruppi. L’utilizzo è abbastanza intuitivo e, come al solito, i file di configurazione sono sempre molto chiari e auto esplicativi.

Ma non sarebbe molto meglio se la nostra porta di ingresso fosse completamente nascosta, anzi, invisibile ai possibili intrusi e magari renderla visibile solo quando serve? Avremo risolto un sacco di problemi con una mossa sola. La cosa è possibile se si sfrutta un semplice demone chiamato knockd.

Se siete dei fan della saga de Il Signore degli Anelli, per capire il funzionamento di knockd, basti pensare a quando la famosa Compagnia dell’Anello è bloccata alle porte della città nanica di Moria e c’è pronunciare delle parole magiche, una password in fin dei conti, per far comparire e aprire la porta. Ecco, knockd fa proprio questo. In questo caso specifico rende invisibile la porta SSH finché non si usa una speciale password per farla riapparire. A questo punto, si potrebbe pensare: password per password, tanto vale che uso quella di SSH, no ? No ! Perché in questo caso la password è rappresentata da una sequenza di knock (bussatine) che si dovranno fare in un certo ordine e su determinate porte. Ma cosa significa, in questo caso, fare dei knock ? In pratica significa inviare dei pacchetti TCP o UDP verso il nostro sistema liberamente raggiungibile su internet. Trattandosi di pacchetti TCP/UDP dovranno essere indirizzati verso una determinata porta che non deve essere già aperta o in uso da qualche altro processo. Il demone knockd è in ascolto su tutte le porte, a livello 2 dello stack ISO/OSI e se riconosce una sequenza stabilita, esegue dei comandi specifici definiti nel suo file di configurazione.

Vediamo in dettaglio come installare e configurare knockd. In questo caso specifico la procedura di installazione verrà effettuata su un sistema debian-like e quindi il gestore dei pacchetti utilizzato sarà apt-get.

$ sudo apt-get install knockd

Una volta installato il pacchetto, i file che ci interessano sono questi:

/usr/bin/knock
/usr/sbin/knockd
/etc/default/knockd
/etc/knockd.conf

Vediamo i file di configurazione /etc/knockd.conf

[options]
UseSyslog

[openSSH]
sequence    = 7000,8000,9000
seq_timeout = 5
command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 2022 -j ACCEPT
tcpflags    = syn

[closeSSH]
sequence    = 9000,8000,7000
seq_timeout = 5
command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 2022 -j ACCEPT
tcpflags    = syn

I file di configurazione sono sempre molto chiari: le due sezioni che ci interessano sono, ovviamente, quelle [openSSH] e [closeSSH]. Praticamente si sta chiedendo al demone knockd di eseguire il comando

/sbin/iptables -A INPUT -s %IP% -p tcp --dport 2022 -j ACCEPT

non appena arriva una sequenza di knock sulle porte 7000,8000,9000 e di eseguire il comando

/sbin/iptables -D INPUT -s %IP% -p tcp --dport 2022 -j ACCEPT

quando arriva una sequenza di knock sulle porte 9000,8000,7000. Capirete che knockd potrebbe essere utilizzato, modificando opportunamente la stringa command, per eseguire ogni genere di comando, di qui la potenza, unita alla sua assoluta semplicità, di questo demone.
Una volta modificato il file di configurazione a nostro piacimento, bisogna abilitare il demone in /etc/default/knockd con questa direttiva:

START_KNOCKD="1"

Vediamo adesso come effettuare i knock. Diciamo subito che i pacchetti possono essere inviati con qualunque programma sia in grado di farlo. Sono dei banali syn-packet TCP/UDP che dovranno essere inviati verso un indirizzo ip e verso una determinata porta.
Nel pacchetto che abbiamo appena installato ci viene fornita in dotazione l’utility knock :

$ knock

usage: knock [options]  <port[:proto]> [port[:proto]] ...
options:
  -u, --udp            make all ports hits use UDP (default is TCP)
  -v, --verbose        be verbose
  -V, --version        display version
  -h, --help           this help

example:  knock myserver.example.com 123:tcp 456:udp 789:tcp

Quindi per dare istruzioni al nostro demone knockd di aprire la porta SSH dovremo inviare tre pacchetti diretti alle porte 7000,8000,9000 dove il nostro host è 192.168.1.111:

 
$ knock -v 192.168.1.111 7000 8000 9000 
hitting tcp 192.168.1.111:7000
hitting tcp 192.168.1.111:8000
hitting tcp 192.168.1.111:9000

A questo punto, magicamente, la porta SSH sarà accessibile e quindi potremo collegarci attraverso le solite modalità. Successivamente, quando avremo finito le nostre attività, per chiudere nuovamente la porta, invieremo, così come descritto nel file di configurazione, una sequenza di tre pacchetti verso le porte (stavolta invertite) 9000,8000,7000. L’ordine, come si è detto, è importante.
Ci sono un sacco di modi per configurare la nostra sequenza magica: si possono definire sequenze di pacchetti tcp e udp, su più porte o su una singola,  istruire knockd ad eseguire comandi dopo un certo timeout, oppure definire un set di sequenze che vengono invalidate dopo il primo utilizzo. Insomma, un sacco di opzioni per gli smanettoni e paranoici come noi ! Come al solito, vi invito a leggere le pagine del manuale e a far riferimento alla pagina ufficiale del progetto knockd.

Alto biondo e ricciolino, ecco esattamente il contrario.

4 risposte a “Hardening SSH : prima di uscire chiudi bene la porta con knockd!”

  1. Avatar domvet

    Volevo segnalare un refuso: nelle regole iptables si usa la porta standard 22, invece che quella 2022 cambiata nell’esempio.

    Per hardenizzare ulteriormente ssh userei la public key authentication, invece che l’autenticazione con password.
    Volendo essere veramente paranoici, potrei pensare che, con molta ostinazione, una “bussata” potrebbe essere sniffata e per evitarlo potrei ricorrere ad un port knocking con single packet authorization (tipo fwknop).

  2. Avatar Mario Ciccarelli

    Hai ragione. Ora dovrebbe andare. Grazie ! 🙂

  3. Avatar Riccardo Cossu

    Non avevo mai fatto caso al fatto che si potessero limitare gli utenti che accedono, grazie!
    Per me il giusto compromesso è: no root (ovviamente), accesso solo con chiave, porta non standard; presto aggiungerò la white list di utenti.
    Non credo che imposterò il port knocking, mi sembra che complichi ulteriormente l’accesso quando si è dietro proxy (cosa che già rende non banale trovare una porta adatta come non standard).

  4. Avatar Mario Ciccarelli

    Sono d’accordo, ed infatti ho volutamente scritto ‘…liberamente accessibile da internet’ se c’è un proxy allora si complica tutto. Comunque, per noi comuni mortali, penso che i tuoi remediation siano più che abbastanza. Ma knockd può essere molto utile anche per eseguire comandi a…comando e che magari non possiamo/vogliamo CRONnare 😉

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *