mrash/fwknopAutorizzazione a singolo pacchetto > Port Knocking
fwknop implementa uno schema di autorizzazione noto come Single Packet Authorization (SPA) per un forte occultamento dei servizi. SPA richiede un singolo pacchetto crittografato, non riproducibile e autenticato tramite un HMAC per comunicare l'accesso desiderato a un servizio nascosto dietro un firewall in una politica di default-drop. L'applicazione principale di SPA è quella di utilizzare un firewall per bloccare tutti i tentativi di connessione a servizi come SSH, rendendo più difficile lo sfruttamento di vulnerabilità (sia 0-day che codice non aggiornato). Poiché non ci sono porte aperte, qualsiasi servizio occultato da SPA non può essere scansionato con Nmap. Il progetto fwknop supporta quattro diversi firewall: iptables, firewalld, PF e ipfw su Linux, OpenBSD, FreeBSD e Mac OS X. È inoltre disponibile il supporto per script personalizzati in modo che fwknop possa essere adattato per supportare altre infrastrutture come ipset o nftables.
SPA è essenzialmente la successiva generazione del Port Knocking (PK), ma risolve molte delle limitazioni mostrate dal PK mantenendone i vantaggi principali. Le limitazioni del PK includono una generale difficoltà nella protezione dagli attacchi di replay, i cifrari asimmetrici e gli schemi HMAC non sono solitamente supportabili in modo affidabile, ed è banalmente facile effettuare un attacco DoS contro un server PK semplicemente spoofando un pacchetto aggiuntivo in una sequenza PK mentre attraversa la rete (convincendo così il server PK che il client non conosca la sequenza corretta). Tutte queste carenze sono risolte da SPA. Allo stesso tempo, SPA nasconde i servizi dietro una politica firewall di default-drop, acquisisce i dati SPA passivamente (di solito tramite libpcap o altri mezzi) e implementa operazioni crittografiche standard per l'autenticazione e la crittografia/decifratura dei pacchetti SPA.
I pacchetti SPA generati da fwknop sfruttano HMAC per la crittografia autenticata nel modello encrypt-then-authenticate. Sebbene l'uso di un HMAC sia attualmente opzionale (abilitato tramite l'opzione da riga di comando --use-hmac), è fortemente raccomandato per tre motivi:
L'ultimo motivo sopra è il motivo per cui un HMAC dovrebbe essere utilizzato anche quando i pacchetti SPA sono crittografati con GnuPG, poiché i dati SPA non vengono inviati attraverso le funzioni libgpgme a meno che l'HMAC non venga prima verificato. GnuPG e libgpgme sono corpi di codice relativamente complessi, quindi limitare la capacità di un potenziale aggressore di interagire con questo codice tramite un'operazione HMAC aiuta a mantenere una posizione di sicurezza più forte. La generazione di un HMAC per le comunicazioni SPA richiede una chiave dedicata in aggiunta alla normale chiave di crittografia, ed entrambe possono essere generate con l'opzione --key-gen.
fwknop crittografa i pacchetti SPA o con il cifrario a blocchi Rijndael o tramite GnuPG e il relativo cifrario asimmetrico. Se viene scelto il metodo di crittografia simmetrica, come di consueto la chiave di crittografia è condivisa tra client e server (vedere il file /etc/fwknop/access.conf per i dettagli). La chiave di crittografia effettiva utilizzata per la crittografia Rijndael viene generata tramite il derivatore di chiave standard PBKDF1 e viene impostata la modalità CBC. Se viene scelto il metodo GnuPG, le chiavi di crittografia derivano dai portachiavi GnuPG.
Le persone che utilizzano Single Packet Authorization (SPA) o il suo cugino meno sicuro Port Knocking (PK) di solito accedono a SSHD in esecuzione sullo stesso sistema in cui è distribuito il software SPA/PK. Cioè, un firewall in esecuzione su un host ha una politica di default-drop contro tutte le connessioni SSH in arrivo, in modo che SSHD non possa essere scansionato, ma un demone SPA riconfigura il firewall per concedere temporaneamente l'accesso a un client SPA autenticato passivamente:
"Utilizzo base di SPA per accedere a SSHD"
fwknop supporta quanto sopra, ma va anche molto oltre e fa un uso robusto del NAT (per firewall iptables/firewalld). Dopo tutto, i firewall importanti sono solitamente gateway tra reti, piuttosto che essere distribuiti solo su host autonomi. Il NAT è comunemente utilizzato su tali firewall (almeno per comunicazioni IPv4) per fornire accesso a Internet a reti interne che si trovano nello spazio di indirizzi RFC 1918, e anche per consentire a host esterni di accedere a servizi ospitati su sistemi interni.
Poiché fwknop si integra con il NAT, SPA può essere sfruttato per accedere a servizi interni attraverso il firewall da parte di utenti su Internet esterno. Sebbene ciò abbia molte applicazioni nelle reti tradizionali moderne, consente anche a fwknop di supportare ambienti di cloud computing come Amazon AWS:
"Utilizzo di SPA in ambienti cloud Amazon AWS"
L'interfaccia utente ufficiale del client fwknop multipiattaforma fwknop-gui
(download, github)
è sviluppata da Jonathan Bennett. Sono supportate la maggior parte delle modalità SPA lato client, incluse richieste NAT, chiavi HMAC e Rijndael (GnuPG non è ancora supportato), salvataggio di stanze fwknoprc e altro. Attualmente fwknop-gui funziona su Linux, Mac OS X e Windows - ecco uno screenshot da OS X:
"fwknop-gui su Mac OS X"
Allo stesso modo, è disponibile anche un
client Android
aggiornato.
Un tutorial completo su fwknop può essere trovato qui:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
Di seguito è riportato un elenco completo delle funzionalità supportate dal progetto fwknop:
tcpdump -w <file>), dal writer pcap iptables ULOG, o direttamente tramite un socket UDP in modalità --udp-server.Il progetto fwknop è rilasciato come software open source secondo i termini della GNU General Public License (GPL v2) o (a tua scelta) qualsiasi versione successiva. L'ultima release può essere trovata su http://www.cipherdyne.org/fwknop/
Questo file README descrive lo stato attuale del progetto fwknop a partire dalla
release 2.5 effettuata a luglio 2013. Attualmente, abbiamo un'implementazione della
libreria Firewall Knock Operator; libfko, così come le applicazioni client e server fwknop.
La libreria fornisce l'API e la funzionalità di back-end per la gestione dei dati di Single Packet Authorization (SPA) impiegati dagli altri componenti fwknop.
Può anche essere utilizzata da altri programmi che necessitano di funzionalità SPA
(vedere la directory perl per il modulo perl FKO come esempio,
e ci sono anche bindings Python nella directory python).
Se stai eseguendo l'aggiornamento da una versione precedente di fwknop (e questo include anche l'implementazione perl originale), ti consigliamo di leggere il seguente link per garantire una transizione fluida a fwknop-2.5 o successivo:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility
Questa distribuzione utilizza GNU autoconf per impostare la compilazione. Consultare il file INSTALL per le nozioni di base generali sull'uso di autoconf.
Ci sono alcune opzioni "configure" specifiche per fwknop. Sono (estratte da ./configure --help):
--disable-client Non compilare il componente client fwknop. L'impostazione
predefinita è compilare il client.
--disable-server Non compilare il componente server fwknop. L'impostazione
predefinita è compilare il server.
--with-gpgme supporto per la crittografia gpg tramite libgpgme
[default=check]
--with-gpgme-prefix=PFX prefisso in cui è installato GPGME (opzionale)
--with-gpg=/path/to/gpg Specifica il percorso dell'eseguibile gpg che gpgme userà
[default=check path]
--with-firewalld=/path/to/firewalld
Specifica il percorso dell'eseguibile firewalld
[default=check path]
--with-iptables=/path/to/iptables
Specifica il percorso dell'eseguibile iptables
[default=check path]
--with-ipfw=/path/to/ipfw
Specifica il percorso dell'eseguibile ipfw [default=check
path]
--with-pf=/path/to/pfctl
Specifica il percorso dell'eseguibile pf [default=check
path]
--with-ipf=/path/to/ipf Specifica il percorso dell'eseguibile ipf [default=check
path]
Esempi:
./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no
Per coloro che attualmente utilizzano la versione Perl e intendono migrare a questa versione, ci sono alcune cose da tenere presenti:
Non tutte le caratteristiche e funzionalità di fwknop basata su Perl sono state portate in questa implementazione. Abbiamo ritenuto importante mantenere la versione C il più snella e leggera possibile. La maggior parte delle funzionalità omesse (come gli avvisi email) possono essere realizzate con altri mezzi (ad esempio, utilizzare uno script esterno per monitorare i file di log e inviare avvisi in base a messaggi di log appropriati).
Ci sono alcune differenze nelle direttive e nei valori dei file di configurazione e di accesso di fwknop. Alcune di queste sono piuttosto sottili. È necessario prestare attenzione alla documentazione e ai commenti in quei file.
Se stai scaricando questa distribuzione da git, dovresti eseguire lo
script autogen.sh per generare i file autoconf. Se ricevi errori riguardanti directory o file mancanti, prova a eseguire autogen.sh di nuovo. Successivamente puoi eseguire autoreconf -i quando desideri rigenerare la configurazione.
Se, per qualche motivo, autoreconf non funziona per te, lo script autogen.sh
dovrebbe essere sufficiente.
I sorgenti nroff delle pagine man di fwknop e fwknopd sono inclusi nelle rispettive directory (client e server). Questi file nroff derivano dai sorgenti asciidoc nella directory 'docs'. Consultare il README in docs per i dettagli.