Port Knocking è una buona idea?

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

Tuttavia, questo non vuol dire che non ci siano aspetti negativi. AFAIK, non ci sono implementazioni di knocking delle porte basate sul kernel disponibili, che per me sarebbe la vera chiave per l'adozione. I daemon di Port knocking si basano sulla lettura di voci di log non riuscite (e filtrate / proibite) da un sistema firewall. Va tutto bene e dandy, ma cosa succede se il filesystem si riempie? Cosa succede quando il demone viene ucciso a causa di qualche processo di fuga che consuma la RAM e lo scambio del sistema? Cosa succede se qualcos'altro che una di queste due cose dipende da solo e smette di funzionare? Molto probabilmente finirai con un server a cui dovrai accedere fisicamente. Questo potrebbe finire per essere più costoso di quanto sia ragionevole, specialmente se sei a più di poche decine di miglia dal server e non hai nessuno che puoi chiamare per arrivare in fretta.

Una cosa che posso dire è che non è "sicurezza attraverso l'oscurità". Port knocking è una forma di autenticazione e, come ogni sistema di autenticazione, può essere reso semplice o complesso come desiderato. Qualcosa di semplice come "knock on port 10.000 + realPortNumber" può essere fatto, il che equivarrebbe a una banale interruzione, o il knockoff potrebbe essere usato per trasmettere qualche forma di autentica autenticazione (diciamo, 1 blocco di dati codificati AES dati un chiave derivata da qualche altro metodo). Non sarebbe fattibile utilizzare il knocking della porta per trasmettere grandi quantità di dati, però, perché richiederebbe molto più tempo rispetto all'invio di un singolo pacchetto, e se il pacchetto è su TCP, almeno lo si può sapere se è stato ricevuto con successo o incontrato qualche forma di errore.

Una domanda interessante che questo porta in evidenza, 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 trapelati? I dati di autenticazione diventano noti e ovviamente non è una cosa molto buona.

Non posso dirti se usare o meno il knockout della porta nel tuo setup. Non lo sono ancora, e non sono sicuro al 100% di esserlo. Per me è più sensato usare sistemi di autenticazione forti basati su crittografia avanzata (come un'infrastruttura PKI) di quanto non facciano per ostacolare la porta. Inoltre, aggiungere un singolo punto di errore per accedere all'infrastruttura critica, a me comunque, sembra una cattiva idea, e molto più difficile da supportare adeguatamente con qualsiasi tipo di garanzia. Di nuovo, tuttavia, ciò si basa sulla nozione che il software port-knocking non sia integrato con il firewall a livello del kernel del sistema operativo; se questo dovesse cambiare, potrei anche cambiare il mio modo di usarlo.

Port knocking non è solo un'altra password in testo semplice, almeno quando viene utilizzata per proteggere i servizi che ascoltano su una porta TCP come SSH. Port knocking implica che l'individuazione dei servizi con nmap non è più possibile a causa dell'uso di un criterio di firewall con drop di default. L'SSHD ha anche avuto vulnerabilità da remoto, e queste non hanno nulla a che fare con password deboli. Non voglio che nessuno sia in grado di accendere nmap e vedere che ascolto SSHD.

Inoltre, esiste una variante più strong di "knock knock" chiamata "Single Packet Authorization", ma è anche uno schema di autenticazione completamente passivo in modo da conservare i benefici del knockout ma risolve i suoi limiti (gli attacchi di replay sono facili, gli attacchi DoS sono facile, ecc.).

Port knocking non è sicurezza attraverso l'oscurità. È difesa in profondità. È come parcheggiare l'auto accanto a un'auto più sveltabile - non farà molto per prevenire un attacco mirato, ma potrebbe semplicemente inviare opportunisti guardando nella direzione opposta.

Come per i miei commenti altrove, anche se ci sono molte implementazioni che usano tutti i tipi di trucchi speciali per rispondere al knock, può essere implementato puramente usando iptables su un sistema Linux. cioè questa è effettivamente una implementazione di knocking della porta basata sul kernel

Dato che la botta è visibile sulla rete, l'uso di sequenze di più di 3 colpi dà poco beneficio. Ti consiglio di usare TCP, anche se sarà più lento, hai una migliore garanzia che il knock è stato consegnato.

Tuttavia, sebbene si basi sui programmi userspace, la mia preferenza è per fail2ban poiché non richiede ulteriori passi / software per connettersi, funziona in modo affidabile, e se avesse mai fallito non mi avrebbe impedito di accedere ai server.

Mi sorprende che ci sia così poca adozione di identità crittografata, anche se RFC1413 menziona semplicemente questo approccio possibile usando il protocollo piuttosto che definire come dovrebbe funzionare.

Ma ovviamente dovresti assicurarti di limitare l'accesso il più possibile a prescindere da ciò (ad es. nessun accesso root, limitare l'accesso al gruppo nominato, se possibile, richiedere coppie di chiavi). SSH è progettato per essere sicuro e storicamente ci sono state relativamente poche vulnerabilità nelle implementazioni del flusso principale. La ragione per cui gli attacchi hanno successo dipende in genere da una combinazione di nomi utente ipotetici, password semplici e attacchi di forza bruta o ingegneria sociale. Si noti che non sto sostenendo che si imponga una convalida passphrase complessa (diversa dalla lunghezza minima) né che si richieda agli utenti di cambiare la propria password, ci sono approcci migliori (es. A due fattori), ma sfortunatamente pochissime implementazioni.

Non ho implementato il knockout del porto in un numero di 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 knock-out che ho sempre implementato naturalmente è basare la sequenza knock su un valore pseudo-casuale ma ripetibile, come la data e l'ora corrente. Questa strategia non elimina completamente il pericolo di un attacco di replay, tuttavia limita l'esposizione di una determinata sequenza di colpi. Ovviamente, per avere successo con un tempo sincronizzato, nel mio esempio, la fonte sarebbe richiesta per coerenza.

Port Knocking è solo un'altra password in testo semplice. Può essere forzato, scoperto, catturato e riprodotto come qualsiasi altra password di testo normale. Perché reinventare gli accessi telnet?

Devi fidarti di qualcosa. Assumiamo quindi la tua fiducia nello stack di rete del tuo sistema operativo e ti fidi di sshd quando esegui con compressione ritardata, separazione dei privilegi e solo alcune forme ragionevoli di autenticazione a due fattori (per esempio, basata su chiavi).

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

authpf ti consente di modificare i set di regole del firewall in base a chi autentica correttamente con sshd, quindi solo gli indirizzi IP che riescono ad accedere ai tuoi gateway ssh possono connettersi alla tua compilation / compute / database farm.