Risposte:
Non è utile come alcuni sostengono, ma almeno ridurrà l'impatto sui file di registro poiché molti tentativi di accesso a forza bruta utilizzano solo la porta predefinita anziché la scansione per vedere se SSH è in ascolto altrove. Alcuni attacchi cercheranno SSH altrove, quindi non è un proiettile d'argento.
Se il tuo server sarà un host condiviso di qualche tipo, piuttosto che soddisfare solo le esigenze dei tuoi progetti, l'utilizzo di una porta non predefinita può essere un problema in quanto dovrai spiegarlo ripetutamente ai tuoi utenti e ancora e ancora e quando dimenticano e i loro programmi client non riescono a connettersi alla porta 22!
Un altro possibile problema con SSH su una porta non standard è se si incontra un client con un set di filtri in uscita restrittivo, che non può connettersi alla porta personalizzata perché il loro filtro consente, ad esempio, solo le porte 22, 53, 80 e 443 come destinazione per nuove connessioni in uscita. Questo è raro, ma certamente non inaudito. Su una questione simile, alcuni ISP potrebbero vedere il traffico crittografato su una porta diversa da quelle in cui è generalmente previsto (porta 443 o HTTPS, 22 per SSH e così via) come un tentativo di nascondere una connessione P2P e accelerare (o bloccare) la connessione in modo scomodo.
Personalmente tengo SSH sulla porta standard per comodità. Finché vengono prese le consuete precauzioni (password complessa / criteri chiave, limitazione degli accessi root, ...) non è necessario preoccuparsi e il problema di crescita del file di registro quando si viene colpiti da un attacco di forza bruta può essere mitigato utilizzando strumenti come come fial2ban per bloccare temporaneamente gli host che forniscono troppi insiemi errati di credenziali di autenticazione in un determinato lasso di tempo.
Qualunque porta tu scelga, se ti allontani da 22, assicurati che sia inferiore a 1024. Nella maggior parte delle configurazioni Unix-a-like nella loro configurazione predefinita, solo root (o utenti nel gruppo root) può ascoltare su porte inferiori a 1024, ma qualsiasi utente può ascoltare sulle porte più alte. L'esecuzione di SSH su una porta superiore aumenta le possibilità che un utente canaglia (o hackerato) riesca a bloccare il demone SSH e sostituirlo con il proprio o un proxy.
È una forma semplice (ma sorprendentemente efficace) di sicurezza attraverso l'oscurità .
Se il tuo server SSH non è sulla porta 22 è molto meno probabile che venga trovato da coloro che scansionano l'intera rete alla ricerca di password deboli su account predefiniti. Se stai analizzando l'intera rete non puoi permetterti di controllare tutte le 64k porte possibili per trovare il server SSH.
Tuttavia, se qualcuno ti sta attivamente prendendo di mira in modo specifico, non offre alcun vantaggio, poiché una semplice nmapscansione una tantum rivelerà la porta su cui è effettivamente in esecuzione.
Per evitare davvero attacchi di forza bruta, è sempre importante seguire alcuni passaggi:
Sì, è utile in quanto aiuta solo a evitare tutti gli attacchi di forza bruta e aiuta a mantenere chiari i registri :)
per quanto riguarda il numero di porta che spetta a te, ho visto le aziende utilizzare 1291 abbastanza spesso. Uso qualcosa di più alto anche solo per evitare alcuni degli script.
Non consentire accessi root ssh e cambiare il numero di porta e forse qualcosa come fail2ban e dovresti essere d'oro. aggiungi iptables per buona misura e tieniti aggiornato e non dovresti avere alcun tipo di problema.
L'uso di una porta ssh non standard richiederebbe maggiori spiegazioni e documentazione e rispondere alle e-mail "Non riesco ad accedere".
Considero i seguenti vantaggi dell'esecuzione di sshd su una porta non standard più importanti dei problemi che crea:
Inoltre, se vuoi essere davvero cattivo, puoi sempre eseguire un falso sshd (con DenyUsers * ) sulla porta standard 22, mentre il tuo normale sshd gira sulla porta 54321. Questo ti assicurerà che tutti i robot e gli aspiranti intrusi saranno eternamente prova ad accedere a un servizio che nega tutti gli accessi, perché nessuno penserà mai di provare a trovare il tuo vero servizio sshd.
I miei 2 centesimi.
Farlo per qualsiasi motivo di "sicurezza" è falso. È il miglior esempio di sicurezza per oscurità che non è sicurezza.
Se vuoi mantenere i tuoi log un po 'più leggeri e puliti, allora sì è utile in quanto non otterrai tanti tentativi di bruteforce di port knock / kiddy.
Perché ci sono molte persone cattive là fuori che scansionano tutti gli IP dei server alla ricerca di porte aperte nel tentativo di sfruttare. Avevo attacchi a martello sulla mia porta SSH per tutto il giorno fino a quando non l'ho spostato su un'altra porta e su un IP che non era più collegato a nessuno dei miei siti Web.
È utile in quanto i robot di script che tentano di indovinare la password con forza bruta in genere si concentrano sulla porta 22, quindi cambiare le porte di solito li getta via. Dovrai bilanciare il valore della mitigazione di tale rischio con il dolore di configurare i client ssh per connettersi alla porta non standard (non è un problema molto grande se non hai molti utenti che si connettono, è vero).
In alternativa, è possibile mitigare il rischio di forza bruta disattivando l'autenticazione con password e richiedendo invece l'autenticazione con chiave RSA.
Di solito non cambio la porta su SSHD, quindi non posso suggerire un altro numero, ma controlla l'elenco delle porte comunemente utilizzate per trovare un altro numero (cioè uno che non è utilizzato da qualcos'altro, e quindi potrebbe essere scansionato) .
Cambio sempre il mio SSHd per usare la porta 2222, tutti quelli che dovrebbero entrare nei miei server lo sanno e non è un segreto. In questo modo non si ottiene alcun vantaggio in termini di sicurezza (a meno che il potenziale hacker non sia un idiota assoluto).
L'unico vantaggio che ottengo da questo è che il registro di autenticazione non ha un milione di tentativi di accesso falliti per 'root', 'alice', 'bob', 'sally', 'admin', ecc.
La sicurezza attraverso l'oscurità si è rivelata inutile, di solito configuro l'accesso ssh con la porta standard per tutte le ragioni sopra menzionate (problemi del client nella riconfigurazione, problemi di firewall e proxy, ecc.).
Inoltre disabilito sempre il login root e l'autenticazione della password e come ultimo passo uso fail2ban per sbarazzarmi di quei fastidiosi messaggi nel syslog. In Debian / Ubuntu è semplice come scrivere aptitude install fail2ban. La configurazione predefinita funziona abbastanza bene, ma di solito sintonizzo alcuni parametri per essere più restrittivi avendo un tempo di ban più lungo (almeno un giorno) e solo 2 tentativi di autenticazione falliti come trigger per il ban.
Direi che la cosa che ti stai proteggendo di più quando cambi la porta SSH sono le scansioni automatizzate che proveranno ad ottenere l'accesso usando nomi utente / password standard, se i tuoi criteri password sono rigidi, non dovresti preoccuparti loro.
Se disabiliti gli accessi con password al tuo server (che è altamente raccomandato), cambiare la porta SSH è completamente inutile. Disabilitando gli accessi con password (e richiedendo l'autenticazione basata su chiave), si rimuove la possibilità di tentativi di password con forza bruta, quindi non si guadagna nulla andando in giro con i numeri di porta.
Se continui ad autorizzare l'autenticazione basata su password, ti stai lasciando aperto alla possibilità di tentare con successo la forza bruta o - più comunemente, secondo la mia esperienza - la tua password viene compromessa perché la digiti quando usi un sistema in esecuzione un keylogger.
man ssh-keygenper molte informazioni.
Non una risposta, ma troppo a lungo per un commento, quindi farò questo CW.
Ci sto pensando da un po 'e sono giunto alla conclusione che c'è molta verità in ciò che Juliano dice nei commenti alla risposta di Alnitak. Tuttavia, trovo che eseguendo SSH sulla porta 22 sia troppo facile lanciare attacchi di qualsiasi tipo contro di essa.
Per risolvere questo problema, eseguo i miei server SSH interni sulla porta 22 e utilizzo il firewall per il port forwarding della porta alta a 22 sui computer di destinazione. Questo dà un po 'di sicurezza attraverso l'oscurità pur mantenendo la sicurezza di un porto basso, come ha sottolineato Juliano.
La sicurezza attraverso l'oscurità non è un principio a cui normalmente sottoscrivo e viene spesso sottolineato che una semplice scansione della porta rivelerà la porta di destinazione, rendendo l'oscurità senza valore. Per risolvere il problema, i miei firewall (Smoothwall Express), sia al lavoro che a casa, usano uno script chiamato Guardian Active Response, che viene attivato dagli avvisi Snort. Dall'osservazione posso dirti che quando colpisci più di 3 porte diverse dalla stessa fonte i tuoi pacchetti vengono rilasciati fino al tempo di ripristino preimpostato. Ciò rende piuttosto difficile ed estremamente dispendioso eseguire una scansione delle porte, rendendo l'oscurità davvero degna di qualcosa. Questo infatti mi ha fatto chiudere così tante volte in passato che ho impostato un'esclusione per il mio indirizzo IP di origine (casa o ufficio).
Il problema che hai è che il firewall è impostato per consentire a determinati IP di connettersi e il capo è stanco di aprire specifici IP quando è in giro. Se stai bloccando determinati IP sul firewall, questo può essere un problema nel culo.
Due cose a cui penso qui. La modifica della porta protegge dagli attacchi automatici. Questo è tutto, ma è una grande parte del traffico di attacco medio là fuori ... reti di scansione automatizzate di script. Se si modifica la porta predefinita, tali attacchi dovrebbero scendere a zero. Quindi ha senso al riguardo. Ma non fa nulla contro un attacco diretto, poiché l'attaccante può semplicemente scansionare da Nessus o NMAP per determinare quale porta (e) stai usando se hai un piccolo amico speciale che ti odia abbastanza.
In secondo luogo, se si utilizzano server simili a UNIX, è possibile installare un'utilità come Denyhosts per bloccare gli attacchi. Se installi denyhosts, monitora i tentativi di accesso errati e dopo (qualunque cosa tu determini il numero) tentativi falliti, vieterà l'IP per un periodo di tempo specificato. Denyhosts può anche parlare con altri host denyhost e passare elenchi di ban, quindi se un attaccante viene bloccato dal sistema Linux di Fred in Montana, il tuo sistema riceverà anche quell'IP per il divieto. Molto utile se i tuoi utenti ricordano le loro password.
Tutto dipende dagli scenari di utilizzo. Quanti programmi hai che sono un "problema nel culo" per cambiare la porta di connessione per SSH / SCP (e se non lo consentono o lo rendono un problema, devi davvero considerare di cambiare fornitore, personalmente). Se è solo una potenziale paura, direi che non è un problema. E questo è il tuo capo, che chiede qualcosa che non sia del tutto stravagante poiché molti amministratori di sistema capovolgono la porta SSH (con un po 'di difetti da parte di persone che odiano tutto ciò che puzza anche leggermente di sicurezza attraverso l'oscurità ... ma in realtà si riduce rumore di sottofondo di innesto da scansioni automatizzate.)
Ridotto: la modifica delle porte blocca gli script automatici e la maggior parte del traffico non valido. Non fermerà gli attaccanti diretti. Prendi anche in considerazione l'installazione di un'utilità di divieto automatizzata. La sicurezza a strati non ti danneggia se eseguita correttamente e cambiare porta aiuta più di quanto faccia male nella maggior parte delle situazioni.
Uso SSH sulla porta> 1024 da oltre 5 anni. Da allora, non ho visto alcun tentativo di Portscan nel mio file di registro (tranne che da me stesso). Ci sono i miei server che gestisco in esecuzione usando la porta> 1024.
Molti server SSH che funzionano sulla porta> 1024, hanno i propri siti Web che sono abbastanza popolari.
Se il server SSH funziona nella mia stessa compagnia, forse ho già inserito l'indirizzo IP di quel server qui in modo che voi ragazzi possiate provare ad hackerare il server. Sfortunatamente il server SSH non è mio. ;-)
Ma ci sono altre cose che dovresti configurare per renderlo sicuro. SSH> 1024 da solo non sarebbe sufficiente. Il numero di porta non deve essere nei servizi / etc /, deve usare il port forwarding (es. Porta 1124-> 22), l'accesso diretto a Root deve essere disabilitato e altro.
Quindi, se vuoi discutere, esegui meglio SSH sulla porta> 1024 per alcuni anni.
p / s: 1124 non è la mia porta SSH n. Haha.
Lo spostamento di SSH in una porta diversa ha un senso, aiuta con la sicurezza ma non enormemente. Ovviamente per farlo devi avere il controllo dei tuoi firewall ma questo non è un problema per te. Ciò che penso annulla il vantaggio di spostare la porta è l'apertura del raggio accettato - in effetti direi che più che annulla il vantaggio e ti espone oltre ciò che sei oggi. Sono sicuro che puoi convincerlo a spostare entrambe le porte E ridurre significativamente l'intervallo in arrivo fascicolando un elenco di probabili punti di ingresso invece di aprirli tutti.
Cambiare la tua porta ssh è un esercizio inutile che ti offre solo una sicurezza limitata. Stai meglio disabilitando semplicemente l'autenticazione con password, che elimina il rischio di tentativi di password con forza bruta e affidandoti esclusivamente all'autenticazione basata su chiave ssh. Se il tuo ambiente richiede l'autenticazione con password, adotta un meccanismo a due fattori, come SecurID o Wikid.
Entrambi ti danno un reale aumento della sicurezza, mentre cambiare la porta ssh ti dà solo l'illusione della sicurezza.
Questo è un POV pratico: ho gestito server SSH privati visibili pubblicamente per più di quattro anni con la porta SSH cambiata e non ho avuto nessun tentativo di scansionare la password. Per amor di questo QA ho appena abilitato indietro 22 su uno di essi per un giorno. Di conseguenza, sono stato scansionato all'incirca ogni 10 minuti con una frequenza del tentativo di password di circa 5 al secondo. Inoltre "scan kiddies" cerca anche server con determinate vulnerabilità OpenSSH.
Di sicuro questa è la sicurezza per oscurità che non aiuta se hai un nemico.
Funziona alla grande, indipendentemente dal piagnucolio della folla "sicurezza attraverso l'oscurità".
Conigli sciocchi, TUTTA la sicurezza è sicurezza attraverso l'oscurità. Solo perché credi che l'oscuro protocollo crittografico Z [che richiede una combinazione di campioni di DNA, chiavi condivise e impossibile effettivamente digitare dalle password umane] sia effettivamente sicuro non lo rende. La verità è che qualsiasi misura di sicurezza si basa su probabilità e ipotesi da parte degli utenti. Peccato per te se so sfruttare questo presupposto, ma è così.
Comunque,
Lo facciamo da anni, insieme a a) limitando il tasso di tentativi di connessione (tuttavia, non so come lo abbiamo impostato, qualcosa nella configurazione ssh) eb) uno script per vietare qualsiasi host che esegue un attacco di dizionario con più di X ipotesi errate in Y minuti. Vietiamo l'host che effettua la connessione per un periodo di tempo e ciò semplifica l'adattamento alla topologia del cambiamento delle reti.
Se le tue password sono sufficientemente complesse e possono fare solo 3 tentativi in 15 minuti, non c'è molto da temere. Non è poi così difficile guardare per gli attacchi distribuiti - di solito raccogliamo per sottorete e ip per escludere quel tipo di cose.
Infine, tutto ciò che serve è un metodo di scoiattolo segreto per consentire le connessioni alla porta modificando le regole f / w. Può essere qualsiasi cosa ... smtp, web, query dns magiche. Roba come SecurID o Wikid fornisce informazioni a terzi. E non farmi iniziare su certificati sicuri tramite terze parti.