it-swarm.dev

A che punto qualcosa conta come "sicurezza attraverso l'oscurità"?

Quindi, continuo a trovare la saggezza convenzionale secondo cui "la sicurezza attraverso l'oscurità non è affatto sicurezza", ma ho il problema (forse stupido) di non essere in grado di dire esattamente quando qualcosa è "buona sicurezza" e quando qualcosa è giusto " oscurare'.

Ho verificato altre domande relative tangenzialmente a questo, e non sono riuscito a capire la differenza precisa.

Ad esempio: qualcuno ha detto che usare SSH su una porta non standard conta come sicurezza attraverso l'oscurità. Stai solo contando sull'altra persona per non verificarlo. Tuttavia, tutto ciò che SSH sta facendo è oscurare le informazioni. Si basa sulla speranza che un aggressore non penserà di indovinare la chiave crittografica corretta.

Ora so che la prima circostanza (che qualcuno penserebbe di controllare porte non standard per un particolare servizio) è molto più probabile della seconda (che qualcuno indovinerebbe casualmente una chiave crittografica), ma la probabilità è davvero la differenza?

E, in caso affermativo, come potrei (un infosec n00b, se ciò non è già abbondantemente chiaro) essere in grado di distinguere il buono (vale a dire ciò che vale la pena implementare) dal cattivo (cosa non lo è)?

Ovviamente, gli schemi di crittografia che si sono dimostrati vulnerabili non dovrebbero essere utilizzati, quindi a volte è più chiaro di altri, ma quello con cui sto lottando è come so dove si applica la saggezza convenzionale e non si applica.

Perché, a prima vista, è perfettamente chiaro, ma quando in realtà provo a estrapolare un algoritmo duro e veloce, costantemente applicabile per le idee di verifica, mi imbatto in problemi.

105
root

L'idea sbagliata che stai avendo è che la sicurezza attraverso l'oscurità è cattiva. In realtà non lo è, la sicurezza solo attraverso l'oscurità è terribile.

Detto in questo modo. Volete che il vostro sistema sia completamente sicuro se qualcuno ne conoscesse il pieno funzionamento, a parte il componente segreto chiave che controllate. La crittografia ne è un perfetto esempio. Se fai affidamento sul fatto che 'non vedono il tuo algoritmo' usando qualcosa come un codice ROT13 è terribile. D'altro canto, se riescono a vedere esattamente l'algoritmo utilizzato eppure non possono praticamente fare nulla, vediamo la situazione di sicurezza ideale.

La cosa da capire è che non vuoi mai contare sull'oscurità ma certamente non fa mai male . Devo proteggere con password/utilizzare le chiavi per la mia connessione SSH? Assolutamente. Devo fare affidamento sulla modifica del server da 22 a 2222 per mantenere sicura la mia connessione? Assolutamente no. È male cambiare il mio server SSH sulla porta 2222 usando anche una password? No, semmai questa è la soluzione migliore. Cambiando ("Oscurando") la porta si ridurrà semplicemente su un mucchio di scanner di exploit automatici che cercano porte normali. Otteniamo un vantaggio in termini di sicurezza attraverso l'oscurità, il che è positivo, ma non stiamo contando sull'oscurità. Se l'hanno trovato, devono ancora decifrare la password.

TL; DR: solo contare sull'oscurità è male. Volete che il vostro sistema sia al sicuro con l'attaccante sapendo che è un funzionamento completo a parte informazioni segrete specificamente controllabili (ad esempio password). L'oscurità in sé, tuttavia, non è male e può effettivamente essere una buona cosa.

Modifica: per rispondere più precisamente alla tua domanda di probabilità, sì, in un modo in cui potresti guardarla in quel modo, ma apprezzando così le differenze. Le porte vanno da 1-65535 e possono essere rapidamente controllate entro 1 minuto con uno scanner come nmap. "Indovinare" una parola casuale a 10 cifre di tutti i caratteri ASCII è 1/1.8446744e + 19 e impiegherebbe 5,8 milioni di anni a indovinare 100.000 password al secondo.

Modifica 2: per rispondere al commento di seguito. Le chiavi possono essere generate con entropia sufficiente per essere considerate veramente casuali ( http://tools.ietf.org/html/rfc4086 ). Altrimenti è un difetto nell'implementazione piuttosto che nella filosofia. Hai ragione nel dire che tutto dipende dal fatto che gli aggressori non conoscono le informazioni (password) e che la definizione di oscurità del dizionario sia "Lo stato di essere sconosciuto", quindi puoi dire correttamente che tutto sta contando a un livello di oscurità.

Ancora una volta, però, il valore dipende dalla sicurezza pratica, date le informazioni che si possono controllare rimanendo sconosciute. Le chiavi, siano esse password o certificati ecc., Sono (relativamente) semplici da mantenere segrete. Gli algoritmi e altri metodi facili da controllare sono difficili da mantenere segreti. "Vale la pena" si riduce a determinare cosa è possibile mantenere sconosciuto e a giudicare la possibilità di un compromesso sulla base di tali informazioni sconosciute.

87
Peleus

I segreti sono difficili da mantenere segreti. Più un segreto è grande e più persone lo conoscono, prima è probabile che vi siano perdite.

I buoni segreti sono:

  • Piccolo.
  • Conosciuto solo da una persona.
  • Facile da cambiare.

Quando accusiamo qualcuno della sicurezza attraverso l'oscurità ciò che stiamo veramente dicendo in quanto pensiamo il loro segreto potrebbe essere più piccolo, conosciuto da un minor numero di persone e/o più facile da modificare.

Algoritmi, numeri di porta e password condivise falliscono il secondo e il terzo punto sopra. Anche gli algoritmi falliscono nel primo punto.

La distinzione tra quando qualcosa è un segreto appropriato e solo oscuro è se conosciamo un modo per raggiungere lo stesso livello di sicurezza con un segreto più piccolo che è più facile da cambiare ed è conosciuto da meno persone.


Non sono d'accordo con l'affermazione che l'oscurità aggiuntiva non guasta mai.

Nel caso dei numeri di porta SSH, è necessario un piccolo periodo di tempo aggiuntivo per digitare -p 1234 ogni volta che usi SSH. Questo è solo un secondo o due, ma con il numero di volte in cui utilizzo SSH, questo finirebbe in modo significativo. C'è il sovraccarico di ricordare che questo cliente è leggermente diverso e di insegnare lo stesso ai nuovi assunti. C'è il caso in cui ti dimentichi che questo client si trova su una strana porta e perde minuti guardando le configurazioni del firewall e i monitor di uptime cercando di capire perché non riesci a connetterti.

Poiché i numeri di porta sono così facili da scoprire con una scansione delle porte, dovrai anche implementare un IPS che rileva la scansione delle porte e impedisce alla porta corretta di rispondere quando viene selezionata o implementare qualcosa come la porta -knocking. Entrambi questi metodi possono essere superati e non aggiungono altro che più oscurità, ma occupano il tuo tempo giocando a cat-and-mouse con il tuo aggressore.

Lo stesso tempo dedicato alla disattivazione degli accessi e delle password di root e al passaggio alle chiavi avrà un impatto migliore sulla sicurezza. Sprecare tempo per oscurare i dettagli toglie vere misure di sicurezza.

Nel caso di un algoritmo segreto, l'algoritmo manca del controllo aggiuntivo che molti ricercatori di sicurezza possono fornire. L'oscurità (o la segretezza) dell'algoritmo probabilmente lo rende meno sicuro.

42
Ladadadada

La sicurezza per oscurità è dove fai affidamento su un fatto che speri non sia noto a un utente malintenzionato. Un grosso problema è che una volta che il fatto è stato reso noto, lo schema di sicurezza è reso inutile.

Tuttavia, tutto ciò che SSH sta facendo è oscurare le informazioni. Si basa sulla speranza che un aggressore non penserà di indovinare la chiave crittografica corretta.

Quando si discute la frase " Sicurezza per oscurità", spesso si riferisce ai processi coinvolti, piuttosto che alle informazioni segrete . La cosa su SSH è che come processo è stato ampiamente controllato per garantire che l'unica cosa che devi tenere segreta sia la chiave crittografica. Questo non è possibile in linea di principio per l'attaccante "pensare e indovinare", perché lo spazio in cui vivono le chiavi crittografiche è vasto .

Bruce Schneier ha dimostrato che per forzare la forza di una chiave AES a 256 bit sarebbe necessario come minimo , per catturare l'intera energia del Sole uscita per 32 anni (!). Non importa quanto sia veloce il tuo computer. Questo è solo un risultato teorico delle informazioni che vale indipendentemente dal computer che usi (nonostante l'informatica quantistica).

Questo è totalmente impraticabile con la tecnologia attuale. Questo non vuol dire che SSH usi AES, ma è uno dei principi della buona crittografia.

Un esempio potrebbe essere la scoperta di un bug in un software in cui un utente (attendibile) trova un input specifico che consente un bypass di autenticazione. Un manager scadente potrebbe dire "ah, ma è davvero improbabile che qualsiasi utente non fidato lo scoprirà mai, perché preoccuparsi di risolverlo". Questa è sicurezza per oscurità.

21
pwaller

È stato toccato in molte altre risposte, ma ci sono tre pezzi di questo puzzle.

  1. Meccanismi
  2. Implementazione/Configurazione
  3. Dati

Un esempio di meccanismo potrebbe essere AES, o SHA-1, o per il tuo esempio, SSH.
Un esempio di implementazione/configurazione potrebbe essere la porta su cui SSH è in ascolto o quale algoritmo di crittografia hai scelto di crittografare i dati della tua applicazione. Un esempio di dati è una chiave privata o una password.

Un meccanismo non dovrebbe mai essere oscuro. "È sicuro perché non sai come funziona" non è sicurezza. Dovrebbe poter essere esaminato nei minimi dettagli senza che le implementazioni siano sfruttabili in assenza di dati segreti.

Un'implementazione può essere o meno oscurata. In generale, non fa male né aiuta materialmente la sicurezza quando lo fai. Potresti vedere un numero inferiore di scansioni delle porte che identificano la tua porta SSH, oppure potresti essere in grado di nascondere l'algoritmo di crittografia utilizzato per un particolare testo cifrato, ma per un meccanismo sicuro senza i dati segreti, non dovrebbe importare. Il meccanismo dovrebbe essere ancora inopportuno. C'è un'argomentazione secondo cui c'è un vantaggio marginale in termini di sicurezza e un danno marginale all'usabilità. Il tuo chilometraggio può variare.

I dati segreti dovrebbero sempre essere oscuri. Se qualcuno ottiene le tue chiavi o password private, le revoca, crei nuovi dati segreti e prometti di proteggerli meglio la prossima volta.

5
Xander

La sicurezza all'oscurità si applica a tutto ciò che riguarda il non correggere la debolezza particolare a livello di codice/sorgente, invece di trovare una soluzione alternativa per coprire i buchi. Quando questo livello di protezione viene rimosso, la vulnerabilità è aperta per essere sfruttata.

Uno di questi esempi sono i hook di programma che offrono agli sviluppatori una sorta di mezzo nascosto per connettersi alle applicazioni nell'ambiente di produzione. Questa è davvero una minaccia, un mito della sicurezza; ma è rapidamente offuscato da qualcuno che ha abbastanza conoscenze per decodificare e talvolta solo annusando la rete.

Di solito il motivo principale per cui queste minacce sfuggono allo stato selvatico quando vengono perse nella fase SDLC della progettazione di sistemi/applicazioni; quindi quando si va in ambiente di produzione è troppo costoso per le cose da riparare da quel momento in poi. È lì che iniziano a emergere soluzioni alternative o insabbiamenti.

Un altro esempio Persone che scrivono la loro password su pezzi di carta e la mettono sotto la tastiera.

Anche come fattore di mercato dovresti sapere che tali pratiche sono normalmente seguite da venditori/comunità chiusi; per un progetto open source questo concetto non applica alcuno scopo pratico poiché il codice viene rilasciato al pubblico per la revisione e quasi tutti possono rispondere alle preoccupazioni attraverso tecniche come la revisione del codice. Il modo migliore e più affidabile per catturarlo.

Sconfiggere la sicurezza SSH attraverso esempi pratici di concetto di oscurità

  1. Esegui la scansione nessus su una rete mirata ti porterebbe i servizi vulnerabili e le porte mappate
  2. Esegui nmap scan su rete mirata per servizi aperti.
3
Saladin

La sicurezza attraverso l'oscurità non è forse la sicurezza forse dichiarata più accuratamente come "Un sistema di sicurezza è sicuro tanto quanto i suoi segreti sono difficili da indovinare". In realtà, quando ci si arriva, si potrebbe sostenere che la crittografia è sicurezza attraverso l'oscurità poiché la chiave di crittografia è oscura. La differenza è che è così oscuro che è matematicamente impossibile da trovare e quindi sicuro.

In qualsiasi sistema di sicurezza basato sul segreto, vuoi che il segreto sia il più limitato possibile e il più difficile da indovinare possibile. Più un segreto è complesso, più è probabile che ci sia un difetto. Inoltre, limitare la quantità che deve essere tenuta segreta rende più facile mantenerla segreta.

L'affermazione "sicurezza attraverso l'oscurità non è sicurezza" deriva dall'idea che molte idee "intelligenti" stanno semplicemente inventando modi contorti di fare qualcosa per cercare di rendere più difficile per un aggressore capire qualcosa, ma spesso un dettaglio di tali approcci influenzeranno altri dettagli di altri passaggi, quindi è impossibile dire quanto sarà difficile per un attaccante con una conoscenza parziale di un algoritmo segreto determinare il resto dell'algoritmo.

Le chiavi d'altra parte dovrebbero essere casuali, conoscere alcuni bit di una chiave crittografica, ad esempio, non dovrebbe aiutarti a capire gli altri bit della chiave. Allo stesso modo, la difficoltà nel capire la chiave è abbastanza ben compresa. Poiché la sicurezza relativa dell'algoritmo non è influenzata in modo significativo (o affidabile quantificabile) dalla segretezza dell'algoritmo, non aggiunge sicurezza statisticamente significativa.

Ciò che ha un impatto statisticamente significativo sulla sicurezza di un algoritmo sono eventuali problemi con l'algoritmo. In generale, gli algoritmi pubblicati sono stati esaminati in modo molto più approfondito per eventuali difetti che li rompono e quindi in genere forniranno una maggiore fiducia nella sicurezza che forniscono.

Quindi, in conclusione, la maggior parte della sicurezza comporta un certo livello di oscurità, ma il trucco è ridurre al minimo la quantità e massimizzare la facilità di protezione di quei segreti, cercando anche di garantire che non vi siano difetti non rilevati che causeranno il malfunzionamento del sistema e rivelino il segreti.

2
AJ Henderson

In ogni algoritmo di crittografia, ad ogni accesso il prompt "security by obscurity" è un componente importante. Si basa sempre su una sorta di conoscenza segreta (ad eccezione dell'autenticazione a due fattori).

La differenza tra buona sicurezza e cattiva sicurezza è connessa alle proprietà della conoscenza segreta : Rimane segreta?

Un cattivo esempio è un sistema in cui è possibile ricavare informazioni su questo segreto da altri canali. Supponiamo che tu abbia inventato il tuo algoritmo di crittografia, ad esempio "Zip then XOR con la tua chiave". Un utente malintenzionato analizza il tuo sistema e potrebbe determinare l'algoritmo di compressione dal momento in cui lo schema di crittografia impiega per codificare diversi messaggi di testo semplice. L'attaccante ha acquisito conoscenza del proprio sistema, conosce gli interni dell'algoritmo Zip e potrebbe essere in grado di utilizzare questi dati per determinare la chiave. Dall'esterno sembra un algoritmo perfettamente buono, compresso e xor'ed i dati sembreranno piuttosto casuali, ma rappresentano solo una piccola sfida per un aggressore sofisticato. La chiave potrebbe essere molto lunga ma ciò non ti aiuta a distinguere tra oscurità cattiva e buona. Hai accidentalmente incorporato un percorso per acquisire conoscenza del tuo chiave segreta nell'algoritmo:

Il controesempio è la crittografia della chiave pubblica RSA. Qui la chiave segreta è un numero primo grande. La chiave pubblica è il prodotto della chiave segreta e di un altro numero primo grande. Ora anche con l'algoritmo RSA noto che posso darti la mia chiave pubblica, puoi codificare qualunque dato tu voglia con esso ma non perde alcuna informazione sulla chiave segreta .

È così importante distinguere tra sicurezza buona e cattiva la quantità di tempo che qualcuno ha bisogno per accedere ai tuoi dati. Nel tuo esempio specifico che va dalla porta 22 a 2222 do c'è un'altra informazione di cui l'autore dell'attacco ha bisogno, quindi questo è un vantaggio di sicurezza. Poiché questo è facile da capire in breve tempo, aggiunge solo una quantità molto piccola ma non perde nulla sulla tua chiave. Poiché questa scansione delle porte è banale e un costo una tantum solo la quantità totale di informazioni necessarie per conoscere la tua chiave segreta rimane costante, ecco perché non è considerato per migliorare la sicurezza totale, quindi il detto comune che "sicurezza per oscurità" non aiuta.

1
Alexander

L '"oscurità" riguarda ipotesi

Penso che la "sicurezza per oscurità" si riferisca effettivamente a ipotesi errate.

Ad esempio, se uso ingenuamente la mia crittografia arrotolata a mano, pensando "nessuno saprà come romperla perché è unica":

  • I sapere può essere rotto da qualcuno che ha la chiave.
  • I presumo non può essere rotto con altri mezzi. Questo è probabilmente falso.

Se utilizzo un metodo di crittografia comprovato:

  • I sapere può essere rotto da qualcuno che ha la chiave.
  • I ho una buona prova che non può essere rotto con altri mezzi.

Faccio ancora affidamento sull'oscurità della mia chiave. Ma questa è l'unica cosa che devo proteggere.

Quindi, per rilevare la "sicurezza per oscurità", sfida le ipotesi. Se qualcuno dice "nessuno potrebbe indovinare o rilevare che stiamo facendo X", la risposta corretta è quante prove hai? Lo standard di sicurezza è molto, molto alto.

1
Nathan Long

Lo formulerei in questo modo:

"Sicurezza attraverso l'oscurità" si riferisce a una situazione in cui un attaccante viene deliberatamente fornito tutti i mezzi/le informazioni necessari per rompere il meccanismo di sicurezza, sperando o supponendo che l'attaccante non spenda lo sforzo di rivelarlo.

A volte si può osservare che alcuni programmi tentano di ottenere la sicurezza mediante uno schema di crittografia "automatica", dove alla fine, oltre all'algoritmo di crittografia, la chiave di crittografia è contenuta da qualche parte nel programma stesso. Il programma stesso non avrà bisogno di ulteriori informazioni per poter decifrare i suoi dati "segreti"; e nemmeno un attaccante.

La sicurezza "reale" proverà a garantire che un utente malintenzionato non abbia mai tutto le informazioni necessarie per romperlo. Quando si utilizza la crittografia, in pratica non importa se l'attaccante ha accesso a entrambi i messaggi di cifratura e l'algoritmo per crearlo fintanto che la crittografia chiave non gli viene divulgata . In questo modo, gli vengono negate le informazioni critiche e non può dalle informazioni che ha semplicemente bypassato il meccanismo di sicurezza.

1
JimmyB

Immagino che quell'oscurità possa essere misurata confrontando il suo valore di sicurezza con quanto complicherà l'uso del mezzo protetto. Qualcuno ha già detto che cambiare la porta SSH aumenterà un po 'la tua sicurezza, ma allo stesso tempo complicherà molto l'uso della Shell, perché dovrai ricordare, su quale porta si trova, insegnare a tutti i nuovi dipendenti di questa sicurezza misura, e alla fine finirà come una nota adesiva allegata ai display dell'utente o agli script automatici con la porta hardcoded, annullando così il suo valore di sicurezza.

Allo stesso modo, puoi offuscare il codice sorgente per proteggerlo. Ma se qualcuno vi accede, è solo una questione di tempo prima che ripristini i significati originali di funzioni e variabili (ad esempio con un attento debug) rendendo inutile l'offuscamento. D'altra parte, devi ricordare di eseguire un programma speciale prima di compilare il codice o (cosa ancora peggio, ma l'ho visto) lavorare sul codice con una strana convenzione di denominazione.

Secondo me, perdi più di quanto guadagni usando l'oscurità ed è per questo che la sicurezza per oscurità è considerata una cattiva pratica.

0
Spook

Puoi usare quello che vuoi per la "chiave segreta", ma le porte fanno una scelta sbagliata; ce ne sono solo 2 ^ 16, possono essere annusati e sono (di solito) statici per la durata della connessione.

Tuttavia, in passato sono stati utilizzati come (parte di) la chiave segreta, quando non esiste altra buona scelta. In particolare, la randomizzazione della porta è stata utilizzata per contrastare attacco di avvelenamento della cache del DNS Kaminsky di alcuni anni fa. In combinazione con la randomizzazione dell'ID query a 16 bit, questo ci offre 32 bit di sicurezza, che è più che sufficiente per proteggerci per la durata di una tipica query DNS (~ 0,1 secondi). La chiave segreta può ancora essere sniffata, ma è considerata "non è un grosso problema" poiché il DNS è sempre stato vulnerabile agli attacchi MITM. C'est la vie.

Quindi, se il tuo esempio è "sicurezza per oscurità" o meno dipende davvero dal contesto.

Se disponi di un'intera serie di meccanismi di protezione, potresti dire che uno di questi meccanismi di protezione è solo "sicurezza attraverso l'oscurità", ma è più importante considerare la sicurezza del sistema nel suo insieme.

Individualmente, un meccanismo di protezione è considerato "sicurezza attraverso l'oscurità" se quel meccanismo di protezione dipende da un attaccante che non si aspetta qualcosa, o se quel meccanismo di protezione dipende dall'essere insolito piuttosto che dal punto di vista crittografico. In altre parole, mettere SSH sulla porta 2222 è sicurezza attraverso l'oscurità perché un attaccante non si aspetterebbe che ci fosse (non sarebbe la prima ipotesi) e perché quella non è la porta normale. Tuttavia, proteggere SSH con una password ad alta resistenza è una vera sicurezza perché è destinato a essere crittograficamente forte. Inoltre, cambiare il tuo nome utente da "root" a qualcosa che non può essere facilmente indovinato è anche una vera sicurezza perché c'è una misura della forza crittografica lì: se l'attaccante non riesce a capire il nome utente non può entrare nel sistema molto bene anche se ottengono la password corretta.

0
KyleM

Per oscurità capisco che la tua sicurezza si basa sul fatto che l'hacker non è a conoscenza del tuo algoritmo di crittografia. Basta ripristinare i caratteri nelle tue parole, come PASS -> SAPP, o eseguire offuscamenti più complessi, e puoi comunicare finché nessuno individua l'algoritmo. Se svelare l'algoritmo di crittografia rompe tutta la tua sicurezza, allora è oscurità, non sicurezza. La vera sicurezza inizia quando gli hacker non saranno in grado di decrittografare il tuo messaggio, dati gli algoritmi di crittografia e decrittografia.

0
Val

La sicurezza si ottiene autenticando che l'utente o il destinatario è previsto. Esistono 3 fattori di autenticazione

  • Qualcosa che l'utente conosce (ad es. Password, PIN, sequenza)
  • Qualcosa che l'utente ha (ad es. Bancomat, smart card)
  • Qualcosa che l'utente è (ad esempio, caratteristica biometrica, come un'impronta digitale)

La maggior parte delle misure di sicurezza utilizza l'autenticazione a fattore singolo. SSH, ad esempio, richiede la conoscenza di una password o una chiave privata (suppongo che si possa dire che richiedere una passphrase per la chiave sarebbe un'autenticazione a due fattori).

L'autenticazione a due fattori è qualcosa che recentemente è stato implementato da molti fornitori di servizi e software. Ciò richiede due dei fattori sopra elencati, in genere una password e un numero di telefono. Con l'autenticazione a due fattori, un utente malintenzionato può accedere a una delle credenziali di sicurezza e non essere ancora in grado di accedere al sistema protetto.

La sicurezza attraverso l'oscurità è un'autenticazione a fattore zero. Non è necessario conoscere alcun segreto, possedere qualcosa o essere una persona in particolare. Senza autenticazione non esiste autenticazione e quindi nessuna sicurezza reale.

0
Eric

L'oscurità può farti del male solo se pensi che ti fornisca vera sicurezza e adotti pratiche deboli. Tuttavia, l'oscurità può aiutare leggermente poiché ti fa guadagnare tempo da vulnerabilità future sconosciute, se provi a mantenere le migliori pratiche (passphrase forti, applicare aggiornamenti di sicurezza, utilizzare algoritmi e protocolli controllati per la sicurezza, ecc.). L'oscurità non impedisce un attacco da parte di qualcuno che ti ha preso di mira se il tuo sistema è vulnerabile, ma non fa pubblicità al fatto che sei vulnerabile al mondo intero.

Se avessi un Ruby on Rails app e pubblicizzato quello e ti è capitato di essere in vacanza lo scorso gennaio, le persone avrebbero potuto eseguire comandi arbitrari sul tuo server web. Infatti la pubblicità consentirebbe agli aggressori di trovarti molto più velocemente rispetto a se dovessero indovinare in modo casuale quale tipo di stack tecnologico stavi eseguendo e provare ogni sito Web casuale.

O diciamo che c'è una debolezza zero-day in SSH; un po 'come il problema della generazione della chiave SSH Debian di qualche anno fa. Le persone inizieranno la scansione in modo casuale per trovare ssh in esecuzione sulla porta 22 su indirizzi IP casuali e quindi eseguire l'exploit. Sicuramente potrebbero fare prima una scansione port per cercare ssh, ma gli attaccanti cercheranno prima i frutti bassi. Una ricerca completa renderebbe la loro scansione più di 10000 volte più lenta. Spero che a quel punto tu abbia risolto il problema. La maggior parte degli indirizzi IP casuali non avrà ssh o qualcos'altro in esecuzione su di essi, quindi ha senso per gli aggressori interrompere la scansione dopo la porta 22 (e forse anche un paio di altri 222 e 2222 e 22222). Se il tuo server di casa non risponde ai ping e rilascia tutti i pacchetti alle porte ma diversi da 39325, probabilmente passeranno prima di trovare il tuo server SSH. Questa è l'oscurità che ti aiuta. Sì, un intercettatore di rete potrebbe banalmente trovare la tua porta in ascolto su una connessione ssh. Ma per la stragrande maggioranza degli aggressori che ti hanno preso di mira in modo casuale, non avranno osservato una connessione ssh ascoltando il tuo traffico di rete. Inoltre, anche per quegli aggressori, il 99,9% delle volte ti aspetti che la tua configurazione ssh sia sicura e non abbia vulnerabilità.

E per la seccatura aggiuntiva di digitare ssh -p 39325 -Y [email protected], chiunque usi ssh spesso imposta un ~/.ssh/config file (insieme a authorized_keys e id_rsa.pub/id_rsa) in modo che possano semplicemente digitare ssh foo per connettersi dopo aver digitato la passphrase delle chiavi private. Ora il tuo file di configurazione ricorda il nome di dominio completo, il tuo nome utente, la porta (se non 22) e qualsiasi altro flag. Per ssh, cambierò le porte se si affaccia su Internet e solo io lo uso (la mia macchina di casa, il mio VPS) come una seccatura per convincere tutti a usare la stessa porta come te. Per roba interna multiutente al lavoro, la mantengo protetta da firewall su Internet esterno e richiedo l'accesso esterno per passare attraverso una VPN.

Per la cronaca, il mio VPS utilizzava ssh sulla porta 22 e registrava circa 10000/giorno di tentativi di autenticazione errati (tutti con nomi utente inesistenti) registrati nei file di registro. Negli ultimi tre mesi di file di registro, ho ottenuto esattamente zero in esecuzione su una porta diversa.

0
dr jimbob