Devo cambiare la porta SSH predefinita sui server linux?

Internet è un luogo selvaggio e spaventoso, pieno di malcontenti i cui motivi vanno dalla curiosità fino all'impresa criminale. Questi unsavori sono costantemente alla ricerca di computer che eseguono servizi che sperano di sfruttare; solitamente i servizi più comuni come SSH, HTTP, FTP, ecc. Le scansioni tipicamente rientrano in una di queste due categorie:

1. Esegui scansioni per vedere quale indirizzo IP ha quei servizi aperti.
2. Sfrutta le scansioni contro gli indirizzi IP che sono stati trovati per eseguire un servizio specifico.

Considerando quanto sia grande Internet è tipicamente impossibile guardare ogni porta di ogni indirizzo IP per trovare ciò che ascolta ovunque. Questo è il punto cruciale del consiglio di cambiare la tua porta predefinita. Se questi individui insoddisfatti vogliono trovare server SSH, inizieranno a sondare ogni indirizzo IP sulla porta 22 (potrebbero anche aggiungere alcune alternative comuni come 222 o 2222). Quindi, una volta che hanno la loro lista di indirizzi IP con la porta 22 aperta, inizieranno la loro password brute force per indovinare nomi utente / password o lanciare il loro kit di exploit di scelta e avviare test noti (almeno a loro) vulnerabilità sul sistema di destinazione.

Questo significa che se cambi la tua porta SSH a 34887 allora quella sweep ti passerà sopra, probabilmente con il risultato che non sarai preso di mira dall'irruzione successiva.

Sembra roseo vero? Ci sono alcuni svantaggi però.

1. Supporto client: tutti coloro che si connettono al server devono conoscere e utilizzare la porta modificata. Se ci si trova in un ambiente con gestione intensiva, questa configurazione può essere trasferita ai client oppure se si dispone di un numero di utenti sufficiente dovrebbe essere facile da comunicare.
2. Eccezioni della documentazione: la maggior parte dei dispositivi di rete, come firewall e IDS, è preimpostata per l'esecuzione di servizi comuni su porte comuni. Eventuali regole firewall relative a questo servizio su questo dispositivo dovranno essere ispezionate e possibilmente modificate. Allo stesso modo, le firme IDS saranno ottimizzate in modo da eseguire solo l'ispezione SSH 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 e ET snort che coinvolgono SSH).
3. System Protections: i moderni Linux vengono spesso forniti con sistemi MAC e / o RBAC a livello kernel (ad es. SELinux su base RedHat o AppAmor su base Debian) e progettati per consentire alle applicazioni solo di fare esattamente ciò che intendono 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 può vietare sshd dal binding a una porta non standard. Dovresti mantenere un criterio locale che lo consenta.
4. Monitoraggio di altre parti: se si dispone di una divisione di sicurezza delle informazioni esterna o di monitoraggio esterno, sarà necessario renderle consapevoli del cambiamento. Quando eseguo una valutazione della sicurezza o analizzo i log 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 questione) lo considero una potenziale backdoor e invocare la parte del sistema compromessa della procedura di gestione degli incidenti. A volte si risolve in 5 minuti dopo aver fatto una chiamata all'amministratore e viene detto che è legittimo, a quel punto aggiorno la documentazione, altre volte si tratta di cattiveria che viene gestita. In ogni caso, questo può comportare un tempo di inattività per te o, al limite, una chiamata snervante quando rispondi al telefono e senti "Ciao, questo è Bob dell'Ufficio per la sicurezza delle informazioni. ".

Prima di cambiare porta devi tener conto di tutto ciò in modo che tu sappia che stai prendendo la decisione migliore. Alcuni di questi svantaggi potrebbero non essere applicabili, ma alcuni lo faranno sicuramente. Considera anche cosa stai cercando di proteggerti. Spesso è semplicemente più semplice configurare il firewall per consentire l'accesso a 22 solo da host specifici, anziché da tutto Internet.

Sì, può essere, non aumentando la sicurezza, ma puoi ridurre la quantità di tentativi di accesso falliti sul tuo server. Io cambio sempre il mio ssh predefinito per ridurre gli avvisi che ottengo da ossec. Inoltre, se utilizzi una porta veramente casuale e qualcuno tenta ancora di accedere alla tua macchina, è più probabile che si tratti di un attacco mirato piuttosto che di uno scanner casuale.

Come altri hanno detto, mettere SSH su una porta diversa da 22 renderà più improbabile essere colpiti da una scansione casuale. Verrai indirizzato se l'autore dell'attacco sta cercando di ottenere il tuo server, non alcun server.

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

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

Tuttavia, è solo la difesa. Anche io ho portsentry attivo, quindi se qualcuno prova un portscan, verrà bloccato per un'ora. Se applicano la password sulla destra ssh, riceveranno "accesso negato" per un'ora. Se riescono a indovinare la password, verranno presentati con un prompt PAM che richiede il token di autenticazione Google.

Il costo di cambiare la porta è molto basso, e penso che gli svantaggi siano giustificati dai lati positivi.

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

• vuoi davvero evitare gli attacchi automatici. A meno che tu non sia un utente di alto profilo, la maggior parte degli attacchi non sarà indirizzata a te, ma gli attacchi automatizzati best effort che proverebbero solo le porte predefinite. Evitarli aiuta in diversi modi:

  • riduci la superficie di attacco (la maggior parte degli attacchi automatici)
  • riduci la tua esposizione a causa di bachi nelle librerie sshd o cripto che usa
  • alcuni bug come heartbleed consentono di sfruttare i server semplicemente connettendosi a una porta aperta, anche senza conoscere password o chiavi. Usando le porte non standard puoi evitare questo.
  • alcuni bug come privato debole i tasti consentono gli attacchi automatici per bloccare il server prima di applicare le patch. L'uso di porte non standard di nuovo evita le prime ondate di aggressori e ti dà più tempo per applicare le patch.
  • riduci la confusione nei tuoi registri, consentendo di risparmiare un sacco di tempo da amministratore durante la revisione dei registri, consentendoti di concentrare i tuoi sforzi su attacchi mirati più problematici
  • fornisce una protezione migliore con meno lavoro di kludge che menzioni in aggiornamento (bloccando l'IP dopo 5 accessi errati - che permetteranno alcuni attacchi specialmente se l'IP continua a cambiare, specialmente nel mondo IPv6 in cui ogni attaccante ne avrà miliardi risparmiare e il kludge può produrre falsi positivi bloccando gli utenti legittimi e producendo più chiamate di supporto)
  • a volte, anche le buone password vengono compromesse (tramite altri bachi altrove, forse, o utenti negligenti che li inseriscono su macchine con keylogg) e archiviate nei dizionari utilizzati per gli attacchi successivi. 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à alla ricerca di porte nelle configurazioni).

• qualunque cosa l'attaccante non si aspetti, lo spegne sempre completamente, crea più lavoro per lui o ti rende un bersaglio meno interessante. E aumenta anche il tuo tempo per rilevare e difendersi dagli attacchi.

• in esecuzione su port > 1024 non richiede sshd per essere eseguito come root, il che consente di eseguirlo è solo un utente per il quale è necessario, evitando un'intera classe di bug (true anche quando alcune implementazioni di sshd prendono extra cura di eseguire con privilegi ridotti quando non è necessario).

Suppongo che dipenda da quanto sarai veloce sulla patch del tuo server e se hai qualche tipo di firewall davanti al server.

Se lasci il server aperto al mondo e non disponi di alcuna configurazione per avvisarti o per installare automaticamente le patch OpenSSH, ti suggerirei di spostare il server su porte con un numero elevato casuale.

In ultima analisi, anche se il semplice spostamento del numero di porta non scoraggia tutti, sicuramente dissuade gli script kiddies che stanno solo controllando la porta 80, 22, 23 ecc., ma non se qualcuno dovesse fare 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ò ancora 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, la modifica della porta SSH a 53, 80 o 443 (o il fatto che il router inoltra una di queste porte a 22) di solito consente di eseguire l'ssh sulla macchina quando si studia / lavora / viaggiare.

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

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

Qualsiasi cosa è utile in determinati contesti. È una buona idea chiedersi in che contesto ci si trova. A volte il contesto è di conformità - si sta implementando il controllo X per soddisfare un particolare requisito. "Devo spostare la mia porta ssh perché i criteri di sistema vietano gli ascoltatori sulla porta 22." Quindi esegui l'operazione, archivia un'eccezione o lavora per modificare la politica. [Questo sarebbe, imho, una politica poco prudente.]

Qui, il contesto è probabilmente "Sono un ragazzo a caso, con un host su una rete incontrollata, e non voglio perdere il controllo della mia scatola." Gli attacchi hanno sempre una fase investigativa - se l'indagine è "invia un SYN sulla porta 22 e vedi chi risponde", allora stai proteggendo contro quel vettore specifico di minacce. (Se l'indagine è "esegui uno sweep della porta, raccogli i banner e vedi se qualcosa di interessante appare", allora il tuo controllo non ha alcun effetto.) Ma ora hai fatto un sacco di lavoro per te stesso - se stai usando uno strumento per collegarsi al server, è necessario capire come lavorare su quella porta non standard e con alcuni strumenti che potrebbero non essere nemmeno possibili. Tutto considerato, e in questo contesto, non consiglierei di cambiare le porte.

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

La modifica della porta interrompe solo gli attacchi automatici contro SSH e alcuni script kiddies. Se qualcuno ti stava bersagliando, potrebbe mettere a posto la nuova porta SSH. Il vantaggio è che interrompe i tentativi di accesso falliti nei tuoi registri. Di solito ho qualcosa come Logwatch e SSH su una porta diversa che funziona con PasswordAuthentication impostata su no nel mio sshd_config.