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:
