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.

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.

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.

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).

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.

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.

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.

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.