Domanda:
Port Knocking è una buona idea?
Mark Davidson
2010-12-16 23:22:33 UTC
view on stackexchange narkive permalink

Normalmente per un server mi piace bloccare SSH e altri servizi non pubblici per essere accessibili solo da determinati indirizzi IP. Tuttavia, ciò non è sempre pratico se l'azienda non dispone di indirizzi IP statici o se gli sviluppatori esterni necessitano dell'accesso.

Ho sentito parlare di Port Knocking qualche tempo fa e ho finalmente avuto la possibilità di esaminarlo come una soluzione al problema di cui sopra. Di conseguenza ho un sacco di domande che spero che le persone possano aiutarmi.

  • Qualcuno l'ha implementato nella propria azienda / organizzazione e può offrire qualche consiglio?
  • Qual è il miglior Daemon da far girare sotto Linux?
  • Quali sono i migliori client per Linux, Windows e OSX?
  • Qual è la lunghezza consigliata per la sequenza di knock ed è meglio usare TCP, UDP o entrambi?
  • Quali sono gli svantaggi e i problemi associati all'utilizzo?
  • È solo sicurezza attraverso l'oscurità?
  • Esistono alternative al port knockingapproach?
Sicurezza attraverso l'oscurità?Non è certo un dato di fatto.Più simile a Security Through Policy.
Sette risposte:
#1
+35
Michael Trausch
2010-12-17 02:53:46 UTC
view on stackexchange narkive permalink

Anche se non l'ho ancora implementato, conosco molte persone che l'hanno implementato. Di conseguenza, ognuno di loro ha notato una riduzione significativa della quantità di larghezza di banda consumata da cose come gli attacchi di forza bruta SSH.

Tuttavia, questo non vuol dire che non ci siano svantaggi. AFAIK, non sono disponibili implementazioni di port knocking basate su kernel, che per me sarebbero la vera chiave per l'adozione. I daemon di blocco delle porte si basano sulla lettura delle voci del file di registro non riuscite (e filtrate / vietate) da un sistema firewall. Va tutto bene e va bene, ma cosa succede se il filesystem si riempie? Cosa succede quando il daemon viene ucciso a causa di un processo in fuga che consuma la RAM del sistema e lo scambia? Cosa succede se qualcos'altro da cui dipende una di queste due cose e smette di funzionare? Molto probabilmente ti ritroverai con un server a cui dovrai accedere fisicamente. Ciò potrebbe risultare più costoso del ragionevole, soprattutto se sei a più di poche decine di miglia dal server e non hai nessuno che puoi chiamare per arrivarci in fretta.

Uno cosa che posso dire è che non è "sicurezza attraverso l'oscurità". Il port knocking è una forma di autenticazione e, come qualsiasi sistema di autenticazione, può essere reso semplice o complesso come si desidera. Può essere fatto qualcosa di semplice come "knock on port 10.000 + realPortNumber", il che equivarrebbe a una banale interruzione, oppure il port knocking potrebbe essere esso stesso utilizzato per trasmettere una qualche forma di autenticazione reale (ad esempio, 1 blocco di dati codificati AES dato un chiave derivata da un altro metodo). Non sarebbe possibile utilizzare il port knocking per trasmettere grandi quantità di dati, tuttavia, perché richiederebbe molto più tempo rispetto al semplice invio di un singolo pacchetto e se il pacchetto è su TCP di quanto si possa almeno sapere se è stato ricevuto con successo o ha riscontrato qualche forma di errore.

Una domanda interessante che questo solleva, tuttavia, è come gestire i file di log: le implementazioni userland richiedono principalmente i file di log per determinare se un knock è stato inviato con successo e cosa succede se quei log sono trapelate? I dati di autenticazione vengono resi noti, e questa ovviamente non è una buona cosa.

Non posso dirti se usare o meno il port knocking nella tua configurazione. Non lo sono ancora, e non sono certo al 100% che lo sarò mai. Per me ha più senso utilizzare sistemi di autenticazione avanzati basati su una crittografia avanzata (come un'infrastruttura PKI) piuttosto che ostacolare le porte. Inoltre, aggiungere un singolo punto di errore per accedere alle infrastrutture critiche, comunque, mi sembra una cattiva idea e molto più difficile da supportare adeguatamente con qualsiasi tipo di garanzia. Anche in questo caso, però, ciò si basa sul concetto che il software port-knocking non è integrato con il firewall a livello di kernel del sistema operativo; se questo dovesse cambiare, potrei anche cambiare il modo in cui mi sento di usarlo.

+1, risposta molto carina - e mi ha dato almeno un'idea migliore del port knocking.
Se sei abbastanza preoccupato per la sicurezza da considerare il port knocking, perché non andare semplicemente con una vera autenticazione a due fattori invece di aggiungere un altro livello di autenticazione in testo normale?
Sono assolutamente d'accordo. Tra le opzioni che sto considerando per la distribuzione nella mia configurazione di rete ci sono i token crittografici e i one-time-pad.
Se è un sistema basato su Linux (anche se immagino che l'approccio sarebbe portabile per la maggior parte dei firewall di filtraggio dei pacchetti con stato) puoi implementare una soluzione completa in iptables, che elimina molti dei problemi di complessità / affidabilità di un programma in spazio utente o di un modulo kernel personalizzato . Avere google.
qualcosa del genere - [utilizzando solo iptables] (https://www.digitalocean.com/community/tutorials/how-to-configure-port-knocking-using-only-iptables-on-an-ubuntu-vps) ** ??? **
Il secondo paragrafo è fonte di confusione, come altri hanno sottolineato, esistono soluzioni solo kernel per Linux e non dovresti preoccuparti di riempire i log poiché la maggior parte del software di port knocking richiede solo 10 minuti di log al massimo, se il tuo demone viene ucciso, sshd èmorirà anche tu, quindi perché questo è il problema principale?nessuna quantità di "driver del kernel" aiuterà quando il sistema non risponde completamente.qualsiasi amministratore di sistema decente può impostare limiti ragionevoli per i log e modificare i criteri di eliminazione delle app.
#2
+14
Michael Rash
2010-12-17 09:42:11 UTC
view on stackexchange narkive permalink

Il port knocking non è solo un'altra password in testo semplice, almeno quando viene utilizzata per proteggere i servizi in ascolto su una porta TCP come SSH. Il port knocking implica che il rilevamento del servizio con nmap non è più possibile a causa dell'uso di una policy firewall di default. Anche SSHD ha avuto vulnerabilità sfruttabili da remoto e queste non hanno nulla a che fare con password deboli. Non voglio che nessuno sia in grado di avviare nmap e vedere che sto ascoltando SSHD.

Inoltre, esiste una variante più forte di port knocking chiamata "Single Packet Authorization", ma è anche una schema di autenticazione completamente passivo in modo che mantenga i vantaggi del port knocking ma risolva i suoi limiti (gli attacchi di replay sono facili, gli attacchi DoS sono facili, ecc.).

#3
+9
Nakedible
2010-12-18 00:21:13 UTC
view on stackexchange narkive permalink

È un fatto facilmente verificabile che tutti i servizi connessi a Internet hanno relativamente spesso vulnerabilità di sicurezza: servizi come SSH, OpenSSL, ecc. Gli attacchi a questi vengono tentati in massa su Internet, prendendo di mira tutti i sistemi che dispongono di porte aperte adatte.

Port knocking, nella mia mente, ha lo scopo di tenere lontani questi aggressori casuali da Internet, che sono alla ricerca di vulnerabilità generiche. Cioè, non dovrebbe tenere lontano un utente malintenzionato dedicato o fare parte della sicurezza effettiva dei servizi. Il vantaggio del port knocking dovrebbe essere che sarebbe, in realtà, abbastanza semplice da non essere probabile che ci siano bug sfruttabili in esso, mai.

Questo utilizzo significa che il port knocking può essere il più rilassato possibile, purché tenga lontana la maggioranza degli aggressori. potrebbe essere solo sicurezza per oscurità, ma un modo migliore è averla come una forma debole di autenticazione "password".

Quindi il "miglior" servizio di port knocking sarebbe uno contro il quale è inconcepibile immaginare attacchi, ma abbastanza banale da poter essere utilizzato da qualsiasi utente legittimo da qualsiasi tipo di macchina client.

#4
+8
symcbean
2010-12-17 16:15:37 UTC
view on stackexchange narkive permalink

Secondo i miei commenti altrove, sebbene ci siano molte implementazioni che usano ogni sorta di trucchi speciali per rispondere al knock, può essere implementato usando esclusivamente iptables su un sistema Linux. cioè questa è effettivamente una implementazione del port knocking basata sul kernel

Poiché il knock è visibile sulla rete, l'uso di sequenze di più di 3 knock dà poco vantaggio. Consiglierei di usare TCP - anche se sarà più lento, hai maggiori garanzie che il knock è stato consegnato.

Tuttavia, sebbene si basi su programmi in spazio utente, la mia preferenza è per fail2ban dal momento che non richiede passaggi / software aggiuntivi per la connessione, funziona in modo affidabile e se non dovesse mai fallire non mi impedirebbe di accedere ai server.

Mi sorprende che ci sia così poco adozione dell'identità crittografata, sebbene RFC1413 menzioni semplicemente questo un possibile approccio utilizzando il protocollo piuttosto che definire come dovrebbe funzionare.

Ma ovviamente dovresti assicurarti di aver limitato l'accesso il più possibile indipendentemente da (cioè nessun login di root, limitare l'accesso al gruppo nominato, se pratico, richiede coppie di chiavi). SSH è progettato per essere sicuro e storicamente ci sono state relativamente poche vulnerabilità nelle implementazioni del flusso principale. Il motivo per cui gli attacchi hanno successo di solito è dovuto a una combinazione di nomi utente indovinabili, password semplici e attacchi di forza bruta o ingegneria sociale. Nota che non sto sostenendo che tu imponga una convalida di passphrase complessa (diversa dalla lunghezza minima) né che tu richieda agli utenti di continuare a cambiare le loro password, ci sono approcci migliori (ad esempio a due fattori), ma sfortunatamente pochissime implementazioni.

#5
+8
jl6
2014-05-15 01:56:12 UTC
view on stackexchange narkive permalink

Il port knocking non è sicurezza attraverso l'oscurità. È difesa in profondità. È come parcheggiare la tua auto accanto a un'auto più bloccabile: non servirà a molto per prevenire un attacco mirato, ma potrebbe semplicemente inviare opportunisti a guardare nella direzione opposta.

Questo è corretto ... anche se non risponde alla domanda, affronta il fatto che tutti gli altri commenti finora affermano che il knocking è un meccanismo di autenticazione che sostituisce qualche altro meccanismo.Non è così: è semplicemente un modo per eseguire un comando con una sequenza pw semi segreta.In genere, il comando consiste nel consentire a una porta di essere collegata a ... uno o tutti gli altri livelli di autenticazione rimangono intatti.La domanda non implicava che sarebbe stato utilizzato come unico meccanismo di autorizzazione.
#6
+4
Tok
2010-12-17 20:14:51 UTC
view on stackexchange narkive permalink

Non ho implementato il port knocking da diversi anni, tuttavia, sospetto che non sia cambiato in modo significativo in linea di principio. Altri commenti contengono molti punti validi e non li ripeterò semplicemente qui.

Un aspetto del port knocking che ho sempre implementato come ovvio è quello di basare la sequenza di knock su uno pseudo-casuale ma ripetibile valore, come la data e l'ora correnti. Questa strategia non elimina completamente il pericolo di un attacco replay, tuttavia limita l'esposizione di una data sequenza di colpi. Ovviamente affinché questo abbia successo un tempo sincronizzato, nel mio esempio, sarebbe necessaria la fonte per coerenza.

Tuttavia è cambiato.
#7
+2
Alex Holst
2010-12-17 03:53:01 UTC
view on stackexchange narkive permalink

Port Knocking è solo un'altra password di testo semplice. Può essere forzata, scoperta, catturata e riprodotta come qualsiasi altra password di testo normale. Perché reinventare gli accessi telnet?

Devi fidarti di qualcosa. Quindi supponiamo che ti fidi dello stack di rete del tuo sistema operativo e ti fidi di sshd quando viene eseguito con compressione ritardata, separazione dei privilegi e consente solo una forma ragionevole di autenticazione a due fattori (ad esempio, basata su chiave).

Puoi usare servizi "semplici" come sshd che invoca authpf per proteggere i tuoi servizi più complessi e vulnerabili.

authpf ti consente di modificare i set di regole dei firewall in base a chi si autentica con successo contro sshd, quindi solo gli indirizzi IP che riescono ad accedere a i tuoi gateway ssh possono connettersi alla tua farm di compilazione / calcolo / database.

Per essere onesti, il port knocking è posto sopra SSH, quindi non è lo stesso di telnet. Inoltre, anche se è in chiaro, il tuo aggressore ora deve acquisire quella password e quindi provare SSH bruto. Le persone che forzano brutalmente gli account SSH, generalmente non sono le stesse persone che hanno modi per fiutare il tuo traffico.
Port knocking non è una password in testo normale.
Inserisco la sezione 4 di rfp2k03.txt come prova che il port knocking è solo un'altra password. Se non c'è crittografia, è anche testo normale. http://www.wiretrip.net/rfp/txt/rfp2k03.txt
Il link nel commento sopra è apparso morto, ecco un alt: https://packetstormsecurity.com/files/17647/RFP2K03.txt.html.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...