IlPuntoTecnico
Hardware e Software => Networking => Topic aperto da: Kelevra - 28 Giugno 2018, 16:04
-
Salve
Vi segnalo dei tentativi di accesso non autorizzati al mio router che temporaneamente aveva attivo il servizio SSH sull'interfaccia WAN. L'IP di provenienza è ucraino e pare faccia uso di server di un hoster, http://infiumhost.com/, quindi non escludo possa trattarsi di un bot. Disabilitando l'SSH da WAN, i tentativi di accesso si sono interrotti. Allego lo screenshot dei log:
(http://oi67.tinypic.com/2u8c5jk.jpg)
Mi scuso in caso la categoria non sia quella giusta e spero di essere stato d'aiuto. In ogni caso, se avete l'SSH abilitato su WAN date un'occhiata ai log.
-
successo anche a me pochi giorni fa, ed io non avevo mai cambiato la password di root finora e me la sono trovata cambiata. proprio guardando i log me ne sono accorto...sempre con accesso dall'ucraina , quindi ho dovuto per forza resettare il router al piu' presto e riapplicare un file di configurazione recente e dopo aver cambiato la password ho disabilitato l'SSH da WAN come giustamente hai consigliato
-
Io lo uso quindi mi serve, ma cambiate la porta con una casuale e se possibile configurate l'accesso con chiave pubblica e privata.
In questo modo siete al sicuro
-
Chiave pubblica...e passphrase!
La sicurezza al giorno d'oggi non è MAI troppa.
(e laddove supportato suggerisco sempre di configurare anche knockd)
-
Concordo in toto.
Cambio porta, chiave pubblica passphrase.
Ed eventualmente anche accenderlo e spegnerlo all'occorrenza.
-
Io lo uso quindi mi serve, ma cambiate la porta con una casuale e se possibile configurate l'accesso con chiave pubblica e privata.
In questo modo siete al sicuro
Non ci ho nemmeno pensato, effettivamente potrebbe essere un'idea ma una scansione netstat potrebbe rilevare le porte aperte e si potrebbe tentare una sessione SSH in ognuna di esse.
Chiave pubblica...e passphrase!
La sicurezza al giorno d'oggi non è MAI troppa.
(e laddove supportato suggerisco sempre di configurare anche knockd)
Sarebbe ottimo, ma direttamente dal router non riesco a generarle perché non è presente ssh-keygen, nemmeno nel repository (che purtroppo è specifico per il brcm63xx-tch).
Aggiungo che dopo aver scaricato il log completo ho notato ulteriori tentativi da pool di indirizzi differenti (194.36.x.y, 112.226.x.y, 221.194.x.y, 5.118.x.y, ecc.) e molti di questi fanno riferimento a data center di servizi di hosting. Questo mi fa pensare a una cosa: come fanno in così tanti a conoscere il mio IP pubblico tenendo conto che è dinamico e che cambia almeno una volta a settimana? Io credo c'entri qualcosa con il servizio DDNS che ho attivato con dynu, ho come l'impressione che il mio dominio sia pubblico. Sarebbe interessante fare dei test.
-
Gli IP pubblici per definizione sono conosciuti pertanto i malintenzionati eseguono scansioni massive automatiche su intere classi di IP, non meravigliarti se pur cambiando di frequente IP riscontri tentati accessi.
-
Le chiavi le puoi generare con Putty e poi mettere la pubblica in .autorization_keys
-
Gli IP pubblici per definizione sono conosciuti pertanto i malintenzionati eseguono scansioni massive automatiche su intere classi di IP, non meravigliarti se pur cambiando di frequente IP riscontri tentati accessi.
Ah, forte :worry:
Le chiavi le puoi generare con Putty e poi mettere la pubblica in .autorization_keys
Ottimo, credevo fosse obbligatorio generarle dallo stesso dispositivo che ospita il server. ;)
-
consiglio spensierato, metti l'autenticazione solo con chiave ssh e levalo dalla wan, è normale che hai delle richieste di accesso __non autorizzate__ , essendoci dei bot che scannano le subnet ogni giorno... non preoccuparti.
-
Se lo toglie dalla WAN poi come ci entra in remoto ?
Se lo toglie dalla WAN l'autenticazione con chiave gli serve a poco, a meno di non avere i ladri "in casa".
-
Per cambiare la porta associata al servizio SSH quali files è corretto modificare ? e che resistano agli aggiornamenti della Gui
io ho visto che in questi files ci sono riferimenti al servizio SSH ed alla porta 22 ma non so se siano tutti da modificare o se ce ne siano altri :
in etc/config/dropbear
ed in etc/config/firewall
config rule 'SSH_wan'
config highrule 'highrule6'
config rule 'rule6'
e se possibile avere qualche indicazioni su come si creano le chiavi pubbliche
Grazie
-
Si è corretto. Va cambiato in Dropbear a nel firewall. Entrambi resistono all'aggiornamento della GUI. Mi sono occupato direttamente io di effettuare i test con Ansuel.
La regola è quella SSH Wan. Delle altre 2 non conosco nemmeno l'esistenza ma di sicuro si riferiscono a IPv6 che non uso.
ovviamente entrambi vanno riavviati
Per generare la chiavi puoi usare putty keygen. La chiave pubblica va poi messa dentro il file .authorized_keys nel profilo dell'utente (sarebbe meglio non sia root).
Poi si deve modificare ovviamente la config di dropbear. Qui puoi trovare una guida
https://askubuntu.com/questions/346857/how-do-i-force-ssh-to-only-allow-users-with-a-key-to-log-in
Si tratta di inibire autenticazione con password e accettare solo le chiavi