Migliora la sicurezza per utilizzare numeri di porta oscuri?

Does it improve security to use obscure port numbers?

Se stai già utilizzando password ad alta entropia o autenticazione con chiave pubblica, la risposta è "non proprio". Principalmente ti stai solo sbarazzando del rumore nei log.

I worry about the unintended consequences of deviating from these recommendations.

Dipende da quale porta è stata scelta. In Linux, per impostazione predefinita tutte le porte inferiori a 1024 richiedono l'accesso root per ascoltarle. Se utilizzi una porta superiore a 1024, qualsiasi account utente può ascoltarlo se non è già in ascolto un processo.

Perché questo è importante? Diciamo che hai scelto di impostare ssh per associare alla porta 20,000 . Se qualcuno potesse interrompere il processo SSH su un server (supponiamo che in qualche modo trovasse un modo per arrestare il processo) e avesse accesso locale a quel server, poteva quindi eseguire il proprio server SSH sulla porta 20,000 prima del riavvio del servizio. Chiunque effettui il login dovrebbe quindi accedere al server SSH dei cattivi.

Questo non è un grosso problema come in passato, dato che in questi giorni è solo il personale IT di fiducia a cui viene fornito l'accesso di accesso ai server. Ma ancora, ha il potenziale per l'escalation dei privilegi e altre cattiverie se un attaccante prende piede sul tuo server.

Oltre ad essere inferiore a 1024, non c'è nulla di speciale nel numero 22. In gran parte è stato scelto perché SSH era un sostituto per telnet alla porta 23 e 21 era già stato preso da FTP. Finché scegli una porta al di sotto di 1024 , la porta non ha molta importanza.

Is this good practice or not? Should we use well known ports?

Non direi che lo raccomando. Anche io non consiglierei contro di esso. Come ho detto, evita molto rumore nei file di registro, ma i vantaggi sono in gran parte limitati a ciò.

Per chiunque sia interessato alla storia di fondo su SSH, puoi trovarlo all'indirizzo: link

Sì, lo fa. La vera domanda è: da quanto?

Perché funziona? Hai già una protezione di base, quindi gli attacchi bot di tutti i giorni non ti preoccupano. Ma potrebbe esserci uno 0-day domani e gli hacker sanno che non passerà molto tempo prima che una patch sia fuori, quindi si affrettano a usarlo e non si preoccupano di qualcosa di complicato - si limiteranno a colpire quante più macchine possibili su la porta standard. Anche qualsiasi tipo di worm SSH teorico utilizzerà questa strategia. Saresti protetto da questo.

Quanta sicurezza aggiuntiva ti guadagna? Protegge da questo e forse 2-3 altri scenari specifici. Aggiungerà alcuni minuti al meglio a qualsiasi attacco mirato da parte di chiunque non sia un totale idiota. Non fa nulla per gli scenari in cui sei già adeguatamente protetto.

Collegando questi numeri al tuo metodo di analisi dei rischi preferito e dovresti trovare qualcosa di relativamente piccolo. Al ribasso si aggiunge lo sforzo di impostare un numero di porta non standard, documentandolo, forse non riuscendo a risolverlo e perdendo un po 'di tempo, ecc.

La mia ipotesi è che si otterrebbe un pareggio con un'analisi. O, in altre parole: Sì, migliora la sicurezza, ma non ne vale la pena perché il miglioramento è molto piccolo.

No, non sarà migliorare sicurezza. Può ridurre la confusione di log, poiché gli attacchi automatici proveranno solo le porte predefinite per es. ssh. Ma la porta verrà comunque visualizzata come SSH in una scansione della porta e shodan.io .

Questi attacchi automatici in genere mirano a un basso appeso di frutta, con nomi utente standard come root, smith e così via e password deboli. Se hanno successo, hai un problema in primo luogo.

Se si configura ssh per consentire solo l'autenticazione delle chiavi, disabilitare gli accessi di root e utilizzare password sensibili, utilizzare fail2ban o un meccanismo simile per bloccare i trasgressori, non rappresentano una minaccia reale.

Uso fail2ban configurato per bloccare temporaneamente per cinque minuti dopo tre tentativi falliti e per una settimana dopo 3 * 5 tentativi falliti. Ciò riduce il disordine del log e blocca qualsiasi progresso reale su un attacco di forza bruta.

Per un attaccante bersaglio non farà differenza su quale roba di porta stai ascoltando. È importante solo per gli attacchi automatici che, a mio avviso, sono un rischio trascurabile.

La modifica della porta predefinita può farti risparmiare dai port scan e dagli script kiddies ma potresti non essere in grado di resistere contro un attacco mirato in cui l'utente malintenzionato potrebbe identificare i servizi in esecuzione non pertinenti alle porte.

Se volevi solo scappare dai biddy script, questo potrebbe essere utile ma potresti non essere in grado di proteggerti dagli attacchi avanzati.

Il mio consiglio è di utilizzare la porta predefinita (potrebbe ridurre il sovraccarico amministrativo) e implementare difese di sicurezza multifaccia per mitigare gli attacchi.

Ad esempio con la porta predefinita in uso, l'autenticazione basata su certificato con SSH è consentita solo a determinate fonti attendibili.

Direi di sì, usare numeri di porta non normali in quanto questo filtrerà un sacco di robot automatici. ma non fare affidamento su di esso, poiché molti robot che ho notato eseguiranno la scansione di una rete / host per qualsiasi porta aperta e li proveremo.

La cosa migliore è implementare un po 'di sicurezza sulla porta SSH. disabilitare il login di root, gli IP della whitelist se possibile, non usare le password per i login (usare le chiavi), abilitare anche una notifica per qualsiasi login. E installa un firewall, questo è importante.

Oscurare le porte su numeri elevati come questo si ferma solo bot semplici che cercheranno porte ben note. Script kiddies e hacker determinati possono semplicemente eseguire una scansione del resto dell'intervallo di porte per trovare un servizio, quindi si limitano a limitare il rumore del registro.

Non ha importanza sulla convenzione di non ascoltare sulla porta standard per quel servizio. Gli sviluppatori di quel servizio ti danno la possibilità di eseguirlo su qualsiasi altra porta, e qualsiasi programma che possa interagire con esso avrà un'opzione per specificare a quale porta vuoi parlare.

Sono d'accordo con altri post qui che porte sensibili come SSH dovrebbero essere tenute in uno spazio di porta privilegiato a 1024.

Un modo migliore per oscurare SSH che effettivamente funziona è quello di fare un knockout. Ciò comporta la chiusura della porta su iptables fino a quando una sequenza di porte non è stata "bussata" che quindi aprirà la porta desiderata.

Ad esempio, è possibile inviare un pacchetto a 8000 4545 28882 7878. Una volta inserita la sequenza desiderata, iptables sbloccherà la porta desiderata. Questo impedisce davvero la maggior parte degli script kiddies e hacker in quanto nessuna porta viene pubblicizzata. Ma questo non si ferma agli attacchi di replay, ma al punto di avere problemi più grandi di cui preoccuparsi.

link .

In realtà dovresti usare TCPWrappers e lasciare che solo i punti noti e gli intervalli di rete accedano a porte come SSH. Hai bisogno di lasciare che gli IP della Cina accedano a SSH? O gli sviluppatori dovranno solo accedere dalla LAN dell'ufficio? Se funzionano in remoto, rendili VPN nella LAN

Come menzionato da altri, la migrazione a una porta non standard non è una soluzione di sicurezza perché filtri solo attacchi di livello naïve.

Allo stesso tempo, la migrazione può essere molto più preziosa se combinata con altre precauzioni. Ad esempio, si posiziona un honeypot sulla porta standard (un ambiente che è fisicamente isolato dal resto del sistema ma sembra un pezzo legittimo per l'attaccante). Quindi, se vedi qualcuno che ha rotto l'honeypot, è molto probabile che sia un hacker, quindi puoi eseguire l'auto-ban o così.

E sicuramente, non dovresti usare versioni obsolete del software con vulnerabilità note, a prescindere dal numero di porta che sono obbligate ad ascoltare.

No, non è così, o se voglio essere più preciso, è la protezione sbagliata contro la minaccia .

Fai un passo indietro: di quale minaccia vogliamo proteggere? La minaccia che stiamo cercando di proteggere è qualsiasi persona su Internet pubblico che può aggirare il normale meccanismo di autenticazione. Questo è ciò che questi "script kiddies" stanno cercando di fare: accedere al server usando SSH anche se non sono autorizzati. In particolare, i tuoi superiori desiderano impedire a questi aggressori di iniziare a stabilire una connessione SSH.

Qual è la tecnologia standard per impedire di stabilire connessioni di rete? Un firewall. La risposta standard a questo problema consiste nel bloccare completamente la porta 22 al traffico esterno. Il problema più grande qui è che SSH è disponibile al pubblico a tutti , e il firewall risolve completamente, mentre la porta oscura lo nasconde solo leggermente e in realtà non impedisce le connessioni. Se è richiesto l'accesso esterno, la risposta standard per consentire questo accesso autorizzato è una VPN nella rete. Questo bloccherebbe entrambi gli script kiddies e che potrebbero capire come trovare la porta che stai effettivamente utilizzando.

Se perdi l'1% di attaccanti, perdi ancora . Hai bisogno di protezioni che funzionano contro il 100% degli attaccanti. Se invece blocchi con successo il 100% degli attaccanti (fino ad ora), allora devi disporre di protezioni più robuste. Queste altre protezioni rendono irrilevante il porto oscuro, e se questo è (si spera) il caso, tutto ciò che usa l'altra porta è confondere le persone che hanno meno familiarità con le pratiche di sicurezza reali come te e, molto probabilmente , sprecare il tempo di persone che cercano di ottenere un accesso legittimo quando provano a connettersi (nuovo sistema non configurato e chiedere a qualcuno la porta corretta, l'amministratore ha dimenticato di dirlo alla porta non standard e la persona deve infastidirli di nuovo per diagnosticare il problema , ecc.).

Questo è il motivo per cui suoniamo su "sicurezza attraverso oscurità" e principio di Kerckhoffs . Dovremmo evitare di distrarci con pratiche che in realtà non ci proteggono. Dovremmo risparmiare tempo e sforzi per le protezioni che funzionano effettivamente ed evitare il falso senso di "sicurezza" che questi metodi di offuscamento ci danno.

Voglio aggiungere che, alla fine, la sicurezza è un gioco di risorse su entrambi i lati. Il tempo è una tale risorsa.

Questa misura sta sprecando il tempo dell'attaccante quindi non è poi così male. Puoi anche conoscere le risorse degli aggressori quando si connettono ancora alla tua porta personalizzata. Forse c'è un interesse più alto per indirizzarti in particolare.

Tuttavia, se aggiunge un sovraccarico significativo alle attività amministrative, potresti voler investire il tuo tempo da qualche altra parte. Altrimenti, fallo ma non fare affidamento su di esso.

L'uso di porte non standard per applicazioni altamente vulnerabili è una pratica MOLTO BUONA. SSH ha molte vulnerabilità e 22 è una porta predefinita comune alla forza bruta.

Detto questo, probabilmente dipende. È molto comune, soprattutto in un ambiente aziendale, vedere attacchi di forza bruta sui server DMZ contro la porta 22. Molte aziende, ad esempio nel settore finanziario, utilizzano una diversa porta predefinita per il traffico SSH / SFTP per un trasferimento dati valido tra le organizzazioni.

In questo caso, l'idea è più di filtrare parte del rumore (Port 22 Brute Forcing) in modo che l'altro traffico su una porta alternativa sia più facile da monitorare. Chiunque sia abbastanza bravo può trovare qualsiasi porta aperta su un server che fronteggia Internet.

Questo è considerato una forma di mitigazione del rischio o riduzione del rischio.

Modifica: dovrei aggiungere: quando dico buone pratiche, mi riferisco alle buone pratiche sui dispositivi che si affacciano su Internet. Qualsiasi cosa dietro i tuoi firewall è generalmente sicuro.