it-swarm-eu.dev

Port Knocking è una buona idea?

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 ha indirizzi IP statici o se gli sviluppatori esterni hanno bisogno di 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 all'interno della propria azienda/organizzazione e può offrire qualche consiglio?
  • Qual è il demone bussare migliore per funzionare su Linux?
  • Quali sono i migliori client per Linux, Windows e OSX?
  • Qual è la lunghezza consigliata per la sequenza knock ed è meglio usare TCP, UDP o Both?
  • Quali sono gli svantaggi e i problemi associati all'utilizzo?
  • È solo sicurezza attraverso l'oscurità?
  • Esistono alternative all'approccio del bussare al porto?
41
Mark Davidson

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

Tuttavia, ciò non significa che non ci siano aspetti negativi. AFAIK, non ci sono implementazioni port knocking basate su kernel disponibili, che per me sarebbe la vera chiave per l'adozione. I demoni port knocking si basano sulla lettura di voci di file di registro non riuscite (e filtrate/vietate) 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 un processo in fuga che consuma il sistema RAM e scambia? Cosa succede se qualcos'altro su cui una di queste due cose dipende solo da su e smette di funzionare? probabilmente finirai con un server a cui dovrai accedere fisicamente. Ciò potrebbe finire per essere più costoso di quanto sia ragionevole, specialmente se sei a qualche decina di miglia di distanza dal server e non hai nessuno a cui puoi chiamare arrivare in fretta.

Una cosa che posso dire è che non si tratta di "sicurezza attraverso l'oscurità". Il port knocking è una forma di autenticazione e, come qualsiasi sistema di autenticazione, può essere reso semplice o complesso come desiderato. Qualcosa di semplice come "bussare alla porta 10.000 + realPortNumber" può essere fatto, il che equivarrebbe a una banale interruzione, oppure il bussare alla porta potrebbe essere utilizzato per trasmettere una qualche forma di autenticazione reale (diciamo, 1 blocco di dati codificati AES dato un chiave derivata da qualche altro metodo). Non sarebbe possibile utilizzare il port knocking per trasmettere grandi quantità di dati, perché richiederebbe molto più tempo del semplice invio di un singolo pacchetto e se il pacchetto è oltre TCP almeno si può sapere se è stato ricevuto correttamente o si è verificato un errore.

Una domanda interessante che questo solleva, tuttavia, è come gestire i file di registro: le implementazioni di userland richiedono principalmente i file di registro per determinare se un colpo è stato inviato con successo e cosa succede se quei registri sono trapelati? I dati di autenticazione diventano noti e ovviamente non è una cosa molto positiva.

Non posso dirti se utilizzare o meno il port knocking nella tua configurazione. Non lo sono ancora e non sono sicuro al 100% di esserlo mai. Per me ha più senso usare sistemi di autenticazione forti basati su una crittografia avanzata (come un'infrastruttura PKI) che non buttare giù le porte. Inoltre, aggiungere un singolo punto di errore nell'accesso alle infrastrutture critiche, a me comunque, sembra una cattiva idea e molto più difficile da supportare adeguatamente con qualsiasi tipo di garanzia. Ancora una volta, tuttavia, ciò si basa sull'idea che il software port-knocking non sia integrato con il firewall a livello di kernel del sistema operativo; se dovesse mai cambiare, potrei anche cambiare il modo in cui mi sento di usarlo.

34
Michael Trausch

Il port knocking non è solo un'altra password di testo semplice, almeno quando viene utilizzato per proteggere i servizi in ascolto su un TCP come SSH. Il knocking delle porte implica che il rilevamento dei servizi con nmap non è più possibile a causa del utilizzo di una politica del firewall con drop predefinito. SSHD ha anche vulnerabilità sfruttabili in 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 ho l'ascolto SSHD.

Inoltre, esiste una variante più forte del port knocking denominata "Autorizzazione a pacchetto singolo", ma è anche uno schema di autenticazione completamente passivo, quindi conserva i vantaggi del knocking delle porte ma risolve i suoi limiti (gli attacchi di replay sono facili, gli attacchi DoS sono facili, ecc. .).

13
Michael Rash

È un dato facilmente verificabile che tutti i servizi di connessione a Internet hanno relativamente spesso vulnerabilità di sicurezza - servizi come SSH, OpenSSL, ecc. Gli attacchi a questi sono provati in massa su Internet, colpendo qualsiasi sistema che abbia porte aperte adeguate.

Il port knocking, secondo me, ha lo scopo di tenere lontani questi aggressori casuali da Internet, che sono alla ricerca di vulnerabilità generiche. Cioè, non dovrebbe tenere lontano un attaccante dedicato o fare parte della sicurezza effettiva dei servizi. Il vantaggio di bussare alle porte dovrebbe essere che sarebbe, in realtà, abbastanza semplice da non avere probabilità di avere bug sfruttabili al suo interno.

Questo utilizzo significa che il knocking delle porte può essere il più lento possibile, purché mantenga lontano il maggioranza degli attaccanti. può essere solo sicurezza per oscurità, ma un modo migliore è di averlo come una forma debole di autenticazione "password".

Quindi il "migliore" servizio di port knocking sarebbe quello su cui è inconcepibile immaginare eventuali attacchi, ma sarebbe abbastanza banale da consentire a qualsiasi utente legittimo di utilizzare da qualsiasi tipo di macchina client.

9
Nakedible

Il bussare al porto non è sicurezza attraverso l'oscurità. È la difesa in profondità. È come parcheggiare la tua auto accanto a un'auto più stealable: non farà molto per prevenire un attacco mirato, ma potrebbe semplicemente inviare opportunisti che guardano nella direzione opposta.

8
jl6

Come per i miei commenti altrove, anche se ci sono molte implementazioni che usano tutti i tipi di trucchi speciali per rispondere al bussare, può essere implementato sando puramente iptables su un sistema Linux. vale a dire che si tratta effettivamente di un'implementazione di port knocking basata sul kernel

Poiché il knock è visibile sulla rete, l'utilizzo di sequenze di più di 3 knock dà pochi vantaggi. Consiglierei di usare TCP - anche se sarà più lento, hai una migliore garanzia che il knock sia stato consegnato.

Tuttavia, sebbene si basi su programmi di spazio utente, la mia preferenza è per fail2ban poiché non richiede passaggi/software aggiuntivi per connettersi, funziona in modo affidabile e se non riuscisse mai non mi impedirebbe di accedere ai server .

Mi sorprende che l'adozione criptata di ident sia così scarsa - sebbene RFC1413 menzioni semplicemente questo possibile approccio usando il protocollo piuttosto che definire come dovrebbe funzionare.

Ma ovviamente dovresti assicurarti di aver limitato l'accesso il più possibile indipendentemente da questo (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. Si noti che non sto sostenendo che si imponga una convalida passphrase complessa (diversa dalla lunghezza minima) né che si richieda agli utenti di continuare a modificare le proprie password, esistono approcci migliori (ad esempio a due fattori), ma purtroppo pochissime implementazioni.

7
symcbean

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

Un aspetto del port knocking che ho sempre implementato come una cosa ovvia è quello di basare la sequenza knock su un valore pseudo-casuale ma ripetibile, come la data e l'ora correnti. Questa strategia non elimina all'ingrosso il pericolo di un attacco replay, tuttavia limita l'esposizione di una determinata sequenza di colpi. Ovviamente, per avere successo, un tempo sincronizzato, nel mio esempio, sarebbe necessario l'origine per coerenza.

4
Tok

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

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

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

authpf consente di modificare le regole dei firewall in base a chi esegue correttamente l'autenticazione con sshd, pertanto solo gli indirizzi IP che riescono ad accedere ai gateway ssh possono connettersi alla farm di compilazione/elaborazione/database.

2
Alex Holst