Domanda:
Devo cambiare la porta SSH predefinita sui server Linux?
sharp12345
2013-03-09 18:09:56 UTC
view on stackexchange narkive permalink

C'è qualche vantaggio nel cambiare la porta SSH, ho visto persone farlo, ma non riesco a trovare il motivo.

Se hai una password complessa e / o un certificato, è utile per qualcosa?

Modifica:

Devo anche menzionare che sto usando le regole di iptables per limitare gli attacchi forzati bruti, sono consentiti solo 5 tentativi di accesso al minuto per IP indirizzo.

Apprezzerei se potesse chiarire se questo requisito proviene da un ambiente di ufficio professionale?
@asadz No, non è così, ha acquistato personalmente server dedicati / vps utilizzati per ospitare alcuni siti Web e altri servizi. - ma sentiti libero di rispondere per entrambi gli scenari, in modo che la risposta possa beneficiare entrambi i tipi di ambienti.
Ho appena cancellato il mio post che avevo precedentemente cancellato perché ricevevo feedback negativo dagli anziani del sito :). Grazie per aver fornito lo spazio per esprimere i miei pensieri.
Ho cambiato la porta SSH sulla mia unità NAS accessibile da Internet in modo che l'unità non girasse inutilmente due volte all'ora solo per registrare un tentativo di accesso non riuscito.
Ci sono ragioni per cui "sicurezza per oscurità" è considerata una parola scortese.
@sharp12345 non posso darti l'altro lato perché è ritenuto troppo ostile per il sito. Chiedo scusa.
Questo post del blog ha una spiegazione abbastanza buona del motivo per cui _non_ dovresti_ mettere SSH su una porta diversa. Immagino che ci siano punti per entrambi i punti di vista, ma mi ha fatto riflettere. > Perché mettere SSH su una porta diversa dalla 22 è una cattiva idea> http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea /
Otto risposte:
#1
+88
Scott Pack
2013-03-09 19:21:03 UTC
view on stackexchange narkive permalink

Internet è un luogo selvaggio e spaventoso, pieno di malcontento le cui motivazioni vanno dalla curiosità fino all'impresa criminale. Questi sgradevoli cercano costantemente computer che eseguono servizi che sperano di sfruttare; di solito i servizi più comuni come SSH, HTTP, FTP, ecc. Le scansioni tipicamente rientrano in una delle due categorie:

  1. Scansioni di ricognizione per vedere quale indirizzo IP hanno quei servizi aperti.
  2. Exploit esegue la scansione su indirizzi IP che si è scoperto che eseguono un servizio specifico.

Considerando quanto è grande Internet, in genere non è possibile cercare su ogni porta di ogni indirizzo IP per trovare ciò che ascolta ovunque. Questo è il punto cruciale del consiglio per cambiare la porta predefinita. Se queste persone disamorate vogliono trovare server SSH, inizieranno a sondare ogni indirizzo IP sulla porta 22 (possono anche aggiungere alcune alternative comuni come 222 o 2222). Quindi, una volta aperto il loro elenco di indirizzi IP con la porta 22, inizieranno la forza bruta della password per indovinare nomi utente / password o lanciano il loro kit di exploit preferito e inizieranno a testare le vulnerabilità note (almeno a loro) sul sistema di destinazione.

Ciò significa che se modifichi la tua porta SSH in 34887, lo sweep ti passerà davanti, probabilmente con il risultato che non sarai preso di mira dall'irruzione successiva.

Sembra roseo giusto? Tuttavia, ci sono alcuni svantaggi.

  1. Supporto client: chiunque si connetta al tuo server dovrà conoscere e utilizzare la porta modificata. Se ti trovi in ​​un ambiente fortemente gestito, questa configurazione può essere trasferita ai client oppure, se hai pochi utenti a sufficienza, dovrebbe essere facile comunicare.
  2. Eccezioni nella documentazione: la maggior parte dei dispositivi di rete, come firewall e IDS, è preimpostata per consentire l'esecuzione di servizi comuni su porte comuni. Eventuali regole firewall relative a questo servizio su questo dispositivo dovranno essere ispezionate ed eventualmente modificate. Allo stesso modo, le firme IDS verranno ottimizzate in modo da eseguire l'ispezione SSH solo sulla porta 22. Sarà necessario modificare ogni firma, ogni volta che vengono aggiornate, con la nuova porta. (Come punto dati ci sono attualmente 136 firme VRT ed ET snort che coinvolgono SSH).
  3. Protezioni del sistema: i Linux moderni spesso vengono forniti con sistemi MAC e / o RBAC a livello del kernel (ad esempio, SELinux su RedHat o AppAmor su base Debian) e che sono progettati per consentire solo alle applicazioni di fare esattamente ciò che dovrebbero fare. Ciò potrebbe variare dall'accesso al file / etc / hosts , alla scrittura su un file specifico o all'invio di un pacchetto sulla rete. A seconda di come è configurato questo sistema, per impostazione predefinita potrebbe impedire a sshd di collegarsi a una porta non standard. È necessario mantenere una politica locale che lo consenta.
  4. Monitoraggio di altre parti: se si dispone di una divisione esterna per la sicurezza delle informazioni o di un monitoraggio in outsourcing, sarà necessario informarli del cambiamento. Quando eseguo una valutazione della sicurezza, o analizzo i registri alla ricerca di minacce alla sicurezza, se vedo un server SSH in esecuzione su una porta non standard (o un server SSH su un non UNIX / Linux per quella materia) lo tratto come una potenziale backdoor e invoca la parte di sistema compromessa della procedura di gestione degli incidenti. A volte viene risolto in 5 minuti dopo aver effettuato una chiamata all'amministratore e aver ricevuto la notifica che è legittimo, a quel punto aggiorno la documentazione, altre volte è davvero il male che viene curato. In ogni caso, ciò può comportare tempi di inattività per te o, almeno, una chiamata snervante quando rispondi al telefono e senti: "Salve, sono Bob dell'ufficio per la sicurezza delle informazioni. Ho alcune domande per te . "

Prima di cambiare la tua porta devi tenere in considerazione tutto questo in modo da sapere che stai prendendo la decisione migliore. Alcuni di questi svantaggi potrebbero non essere applicabili, ma alcuni sì. Considera anche da cosa stai cercando di proteggerti. Spesso è semplicemente più semplice configurare il firewall per consentire l'accesso solo a 22 da host specifici, al contrario dell'intera Internet.

Inoltre, software come [fail2ban] (http://www.fail2ban.org/wiki/index.php/Main_Page) aiuterà a proteggere il tuo sistema molto meglio di quanto non faccia la modifica arbitraria dei numeri di porta.
@Shadur In effetti, o denyhosts sono ottime difese attive.
@Shadur: Vedi [http://en.wikipedia.org/wiki/Defense_in_depth_(computing))(http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29). Se X è una strategia di sicurezza migliore di Y, allora potrebbe essere un motivo per usare X, ma non è (di per sé) un motivo per evitare Y. La risposta di Scott Pack fornisce ragioni reali per cui potrebbe essere meglio restare con la porta predefinita ; il tuo commento no.
Si noti che l'esecuzione di SSH su una porta superiore a 1024 (ovvero una porta non privata) è in realtà potenzialmente una vulnerabilità * di sicurezza *. Solo `root` può collegarsi a porte privilegiate (<1024), quindi puoi sapere che i servizi in esecuzione qui sono almeno avviati da` root`. Diciamo che esegui SSH sulla porta 2222 e il tuo sshd si arresta in modo anomalo per qualche motivo. Ora qualsiasi utente locale può avviare il proprio (falso) `sshd` sulla porta 2222 che potrebbe fare cose cattive come rubare la tua password!
@TomMarthenal: Yuppers. Questo è uno dei motivi per cui invoco immediatamente le procedure di gestione degli incidenti se vedo un comportamento SSH su una porta non standard.
Questo post è il modo più elegante che abbia mai visto di dire: cambia la tua porta SSH predefinita per accelerare il tuo traffico. Complimenti per andare oltre e spiegare i dettagli che lo circondano.
@RandomUs1r: Credo che almeno uno di noi stia fraintendendo l'altro. La modifica della porta non avrà alcun impatto sulle velocità di trasferimento.
-1 a causa del cattivo consiglio segnalato da @TomMarthenal (rispetto all'esecuzione di SSH su una porta alta).Sarà +1 se la risposta viene modificata per notare questo.
Puoi discutere gli eventuali svantaggi nel caso in cui la porta cambi in una porta di un altro servizio come 80 ma nessun server http viene eseguito sullo stesso host?
Per quanto riguarda l'utente che si arresta in modo anomalo sshd originale sulla porta 2222: Se ciò fosse stato fatto, la mia prossima connessione mi avviserebbe a causa della chiave del server modificata.Sì, sono sulla stessa macchina, ma lo scenario riguardava un attacco non root ei file sono leggibili solo da root.
#2
+15
Lucas Kauffman
2013-03-09 18:14:25 UTC
view on stackexchange narkive permalink

Sì, può essere, non aumentando la sicurezza, ma puoi ridurre il numero di tentativi di accesso falliti sul tuo server. Cambio sempre il mio ssh predefinito per ridurre gli avvisi che ricevo da ossec. Inoltre, se utilizzi una porta davvero casuale e qualcuno cerca ancora di accedere alla tua macchina, è molto probabile che si tratti di un attacco mirato piuttosto che di uno scanner casuale.

#3
+10
ThoriumBR
2015-04-29 18:45:10 UTC
view on stackexchange narkive permalink

Come altri hanno detto, mettere SSH su una porta diversa dalla 22 renderà più improbabile che venga colpito con una scansione casuale. Sarai preso di mira se l'aggressore sta cercando di ottenere il tuo server, non qualsiasi server.

Ho un server con ssh associato a un alto casuale porta. E ho un honeypot ssh sulla porta 22, che risponderà a ogni tentativo di accesso con un messaggio di "accesso negato".

Non credo che sia una difesa dall'oscurità , ma difesa in profondità : per attaccare il mio server, l'attaccante deve prima trovare la porta. Se ho alcuni falsi honeypot (molte porte che reindirizzano allo stesso honeypot), l'attaccante colpirà molti falsi e non avrà modo di sapere se ha colpito il vero ssh o no.

È solo la difesa, però. Ho anche portsentry attivo, quindi se qualcuno prova un portscan, verrà bloccato per un'ora. Se impongono la password all'ssh giusto, riceveranno "accesso negato" per un'ora. Se riescono a indovinare la password, verrà presentato con un prompt PAM che richiede il token di Google Auth.

Il costo per cambiare la porta è molto basso e penso che i lati negativi siano giustificati dai lati positivi.

#4
+8
Matija Nalis
2016-01-17 20:31:51 UTC
view on stackexchange narkive permalink

Poiché la maggior parte di tutti parla principalmente di svantaggi (che sono reali), vorrei condividere qui diversi vantaggi:

  • vuoi davvero evitare attacchi automatici. A meno che tu non sia un utente di alto profilo, la stragrande maggioranza degli attacchi non sarà mirata a te, ma attacchi automatizzati al massimo sforzo che proverebbero semplicemente le porte predefinite. Evitarli aiuta in diversi modi:

    • riduci la superficie di attacco (la maggior parte degli attacchi automatizzati)
    • riduci la tua esposizione a causa di bug nelle librerie sshd o crittografiche che utilizza
    • alcuni bug come heartbleed consentono di sfruttare i tuoi server semplicemente connettendoti a una porta aperta, anche senza conoscere password o chiavi. Utilizzando porte non standard lo eviti.
    • alcuni bug come chiavi private deboli consentono agli attacchi automatici di eliminare il tuo server prima di applicare le patch. L'utilizzo di porte non standard evita nuovamente le prime ondate di aggressori e ti dà più tempo per applicare le patch.
    • riduci il disordine nei tuoi log, il che ti fa risparmiare molto tempo per l'amministratore durante la revisione dei log, permettendoti di concentrare i tuoi sforzi su attacchi mirati più problematici
    • fornisce una migliore protezione con meno funziona rispetto a kludge che hai menzionato nell'aggiornamento (blocco dell'IP dopo 5 accessi errati - che consentirà alcuni degli attacchi soprattutto se l'IP continua a cambiare; specialmente nel mondo IPv6 dove ogni attaccante avrà miliardi di loro da risparmiare; e il kludge può produrre falsi positivi che bloccano gli utenti legittimi e producono più chiamate di supporto)
    • a volte, anche le buone password vengono compromesse (tramite altri bug altrove, forse, o utenti incuranti che le inseriscono su macchine con keylogging) e memorizzate nei dizionari usati per attacca in seguito. Ancora una volta, la porta casuale eviterà la stragrande maggioranza di questa classe di attacchi automatici (la maggior parte dei keylogger salverà solo le coppie nome utente / password e non andrà a cercare le porte nelle configurazioni).
  • qualunque cosa l'attaccante non si aspetti, o lo spegne completamente, crea più lavoro per lui o ti rende un bersaglio meno interessante. E aumenta anche il tempo per rilevare e difendersi dagli attacchi.

  • in esecuzione sulla porta> 1024 non richiede che sshd venga eseguito come root, il che consente di eseguirlo è solo un utente per cui è necessario, evitando un'intera classe di bug (vero anche quando alcune implementazioni di sshd prestano particolare attenzione a essere eseguite con privilegi ridotti quando non sono necessari).

#5
+2
Jamie H
2013-03-09 23:37:21 UTC
view on stackexchange narkive permalink

La modifica della porta interrompe solo gli attacchi automatici contro il tuo SSH e alcuni script kiddie. Se qualcuno ti prendeva di mira, potrebbe multare la nuova porta SSH. Il vantaggio è che interrompe i tentativi di accesso non riusciti nei log. In genere ho qualcosa come Logwatch e SSH su una porta diversa in esecuzione con PasswordAuthentication impostato su no nel mio sshd_config.

#6
+2
David Rothera
2013-03-18 20:32:31 UTC
view on stackexchange narkive permalink

Suppongo che dipenda da quanto sarai aggiornato con l'applicazione delle patch al tuo server e se hai qualche tipo di firewall davanti al server.

Se lasci il server aperto al mondo e non hai nulla da impostare per avvisarti o per installare automaticamente le patch di OpenSSH, quindi suggerirei di spostare il server su porte con numeri alti casuali.

In definitiva, anche se il solo spostamento del numero di porta non scoraggia tutti, certo che scoraggia gli script kiddies che stanno solo controllando le porte 80, 22, 23 ecc. ma non se qualcuno dovesse eseguire una scansione 1-65535.

Ma sono necessarie molte risorse per eseguire una scansione 1-65535 per ogni host in un elenco di destinazione, quindi è improbabile che accada. Coloro che controllano solo le porte comuni non sono solo script kiddies; anche gli aggressori esperti lo fanno per trovare rapidamente gli host più vulnerabili (cioè se trovano SSH ed è su una porta diversa, significa che l'amministratore è intelligente e probabilmente ha altre misure di sicurezza nella manica, quindi è un obiettivo difficile e non vale nemmeno la pena cercare).
#7
+2
Psychonaut
2015-04-29 16:46:07 UTC
view on stackexchange narkive permalink

Come altri hanno già notato, cambiare la porta SSH predefinita non ti fa guadagnare molto dal punto di vista della sicurezza. Tuttavia, può comunque essere vantaggioso farlo se si intende connettersi alla macchina da una rete in cui gli amministratori hanno bloccato la porta 22 (molte scuole, luoghi di lavoro e hotspot WiFi gratuiti bloccano tutto il traffico in uscita tranne quello predefinito Porte DNS, HTTP e HTTPS.) In questo caso, cambiare la porta SSH a 53, 80 o 443 (o fare in modo che il router inoltri una di queste porte a 22) di solito ti consentirà di accedere a ssh sulla tua macchina quando studi / lavori / in viaggio.

In rari casi queste reti potrebbero non semplicemente bloccare le porte, ma anche ispezionare il traffico per filtrare le connessioni ssh. Per questa situazione è necessario esaminare altre alternative.

#8
+2
Robert Weaver
2015-04-29 18:19:12 UTC
view on stackexchange narkive permalink

Questa è una domanda filosofica: "il controllo X è utile?" E come ha sottolineato la migliore risposta, dovresti anche considerare "quali sono i costi (supporto client, esenzioni di documenti, supporto di sistema, supporto per il monitoraggio e aggiungerei costi diretti, costi di licenza, ecc.) Del controllo X?"

Tutto è utile in determinati contesti. È una buona idea chiedersi in quale contesto ci si trova. A volte il contesto è quello della conformità: si utilizza il controllo X per soddisfare un particolare requisito. "Devo spostare la mia porta ssh perché la politica di sistema vieta gli ascoltatori sulla porta 22." Quindi fallo, richiedi un'eccezione o lavora per modificare la politica. [Sarebbe, imho, una politica poco saggia.]

Qui, il contesto è probabilmente "Sono un ragazzo a caso, con un host su una rete non controllata, e non voglio perdere il controllo della mia scatola. " Gli attacchi hanno sempre una fase di indagine: se l'indagine è "invia un SYN sulla porta 22 e vedi chi risponde", allora stai proteggendo contro quello specifico vettore di minaccia. (Se l'indagine è "eseguire un port sweep, raccogliere banner e vedere se viene visualizzato qualcosa di interessante", il tuo controllo non ha alcun effetto.) Ma ora hai lavorato molto per te stesso - se stai usando uno strumento per collegarti al server, devi capire come lavorare su quella porta non standard - e con alcuni strumenti, potrebbe non essere nemmeno possibile. A conti fatti, e in questo contesto, non consiglierei di cambiare le porte.

Un vantaggio notato è stata la riduzione degli eventi di log associati a falsi positivi. In realtà lo trovo negativo! Il flusso costante di attacchi in entrata sulla porta 22 può effettivamente essere utile: se si interrompono, sai che c'è un problema con il tuo feed Internet. Penso che il vantaggio percepito sia falso: la risposta giusta è ottimizzare il sistema di rilevamento delle anomalie per filtrare i tentativi di accesso non riusciti da reti esterne.



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