Porta 22 (ssh) aperta, problema di sicurezza?

[D_fool]

Salve a tutti, vorrei porre un quesito.
Telnettando qui e lì per il web, ho trovato diversi siti aventi la porta 22 aperta ( ho detto bene? xD ), ho letto un po' ciò che riguarda l' ssh, tuttavia non capisco se il fatto di avere tale porta aperta, rappresenta una falla di sicurezza, se si... come sfruttarla? ( non chiedo exploit )
Grazie.

 

[Oromis92]

RE: Ssh

non è per nulla una falla di sicurezza.
la porta serve semplicemente per permettere la connessione di SSH

SSH (Secure SHell, shell sicura) è un protocollo che permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host.

Il client SSH ha una interfaccia a linea di comando simile a quella di telnet e rlogin, ma l'intera comunicazione (ovvero sia l'autenticazione che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è diventato uno standard di fatto per l'amministrazione remota di sistemi unix e di dispositivi di rete, rendendo obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni.

Il client ed il server SSH sono installati o installabili su molte versioni di UNIX, Linux, Mac OS X e Microsoft Windows. Inoltre è disponibile come strumento di amministrazione su alcuni apparati di rete

La sintassi su sistemi UNIX-like è la seguente:

% ssh [opzioni] nomeutente@host [comando]

dove con "%" si intende il prompt della shell utilizzata

esempio: se tu fossi su un sistema all'indirizzo 10.20.30.40 , con nome utente xyzutente e la porta 22 aperta
io col comando

$ ssh -l xyzutente 10.20.30.40

e inserendo la password, utilizzerei il TUO computer da riga di comando

 

[s0ph3r]

RE: Ssh

e' vulnerabile ... si ovviamente (man-in-the-middle attack e' un classico)
non direi che sia una falla in quanto ssh passa per la porta 22 come standard
teoricamente e in pratica si puo' cambiare ma non e' difficile trovare comunque l'accesso ssh
(e' ovvio che se la porta e' aperta in ascolto e solitamente viene usata per ssh ci si prova ad entrare)
ssh e' una secure shell e a meno che non usi user/password non e' cosi' facile da fare un hack
se usi AllowedUsers, Client KeyAuthentication, DisallowRoot non dovrebbero esserci grossi problemi

 

[D_fool]

RE: Ssh

Vi ringrazio entrambi per la spiegazione, molto esaudienti

 

[orakool]

RE: Ssh

Edito il titolo, siate più specifici!

 

[imported_BlackLight]

e' vulnerabile ... si ovviamente (man-in-the-middle attack e' un classico)

È un po' difficile fare un MITM su SSH al di fuori della rete locale, e sniffando del traffico cifrato che potrà essere decifrato solo dalla chiave privata del destinatario...
In ogni caso la 22 può essere anche aperta. Ma se l'autenticazione è possibile solo con chiave RSA, e ci sono al massimo 1-2 chiavi autorizzate, e ogni chiave ha una passphrase non intuitiva, avere la propria shell remota è decisamente difficile.

 

[Bl@ster]

Ma dai, la 22 è la porta di default, cosa temete

 

[D_fool]

Formulo un altra domanda, dato che fa parte del contesto.
Avendo disponibili diverse porte aperte, con un utilizzo sconosciuto, tipo 12077/30042, cosa potrei fare? Come sfruttare una porta a proprio vantaggio? Nell'ipotetico caso essa sia aperta per una qualsiasi ragione.
Grazie.

 

[Langy]

per utilizzare una porta bisogna sapere necessariamente il servizio che c'e' dietro.

se non sai che servizio c'e' non puoi fare nulla...

 

[s0ph3r]

per utilizzare una porta bisogna sapere necessariamente il servizio che c'e' dietro.

se non sai che servizio c'e' non puoi fare nulla...

io uso nessus

 

[shecfhoirmhfuhgoieg]

come dice langy, una porta aperta ti può essere utile solo se il server che sta in ascolto ha un bug di qualche tipo, altrimenti non ci fai nulla....quindi prima scopri che server c'è e che versione è, poi cerchi qualche bug e poi vinci

 

[furios_angel]

Formulo un altra domanda, dato che fa parte del contesto.
Avendo disponibili diverse porte aperte, con un utilizzo sconosciuto, tipo 12077/30042, cosa potrei fare? Come sfruttare una porta a proprio vantaggio? Nell'ipotetico caso essa sia aperta per una qualsiasi ragione.
Grazie.

Microsoft ISA Server 2004 e successivi possono adottare il "mascheramento delle porte" o lo switching di porte TCP nel senso che se per problemi di sicurezza è richiesto questo metodo...utilizzo ISA. Potrebbe depistare scansioni remote e eventuali attacchi.

Comunque nel tuo caso questo è inutile. Quindi utilizza la porta 22 TCP.
Inoltre ssh è quasi vulnerabile a attacchi MITM in quanto i pacchetti che fluiscono attraverso lo stack TCP/IP sono quasi prevedibili.

 

[Langy]

pero' guarda che la porta 22 che vedi aperta potrebbe essere aperta solo sul firewall senza che il server ssh sia attivo.

 

[furios_angel]

pero' guarda che la porta 22 che vedi aperta potrebbe essere aperta solo sul firewall senza che il server ssh sia attivo.

Io invece abilitavo il servizio ssh, lo filtravo (a seconda degli utilizzi della rete) e aprivo una porta 22 TCP su una DMZ della rete...così anche se l'utente remoto può effettuare un tunneling nella rete, i suoi tentativi verranno bloccati dal firewall (naturalmente bloccando sul firewall la 22 TCP!).

 

[imported_BlackLight]

Inoltre ssh è quasi vulnerabile a attacchi MITM in quanto i pacchetti che fluiscono attraverso lo stack TCP/IP sono quasi prevedibili.

Scusa eh questo è l'hexdump di un pacchetto SSH...

4510 0064 7b0f 4000     E..d{.@.
4006 3c1d c0a8 0102     @.<.....
c0a8 0105 b1a4 0016     ........
a218 dfd7 2389 d6fd     ....#...
8018 03ea 83ae 0000     ........
0101 080a 0069 679c     .....ig.
22a7 3c8f c77c c0f1     ".<..|..
dfcb 3e4d 317e d2a0     ..>M1~..
b115 957c 196d 5be2     ...|.m[.
ce17 fa28 c188 e884     ...(....
c73a fafa 3838 cfc1     .:..88..
888d 1b0a 45af eb25     ....E..%
2ce0

Cosa ci vedi di prevedibile?
SSH è un protocollo ormai altamente affidabile e sicuro, la cifratura dei pacchetti è fatta con una coppia di chiavi RSA. E credimi, un testo cifrato in RSA non è tanto facile da decifrare senza conoscere la chiave privata, a meno che non lasci andare un supercomputer per 2 anni andando di brute force. Il più che puoi fare dopo aver fatto un MITM su una sessione SSH è interromperla mandando un pacchetto di RST, una volta che conosci i SEQ number giusti della sessione TCP, ma di più assolutamente non puoi fare. Non c'è modo di decifrare la comunicazione senza essere in possesso delle chiavi.

Per l'altra domanda, in molti casi basta fare un nc host porta per sapere, dal banner di benvenuto, che servizio c'è in listen.

blacklight@wintermute:~$ nc localhost 22
SSH-2.0-OpenSSH_5.1
blacklight@wintermute:~$ nc nemesis 25
220 BlackLight ESMTP service - and I did it for the lulz

 

[Capablanca]

penso fosse ironico

 

[shecfhoirmhfuhgoieg]

Inoltre ssh è quasi vulnerabile a attacchi MITM in quanto i pacchetti che fluiscono attraverso lo stack TCP/IP sono quasi prevedibili.

Cosa ci vedi di prevedibile?

forse parlava di debian

 

[furios_angel]

Inoltre ssh è quasi vulnerabile a attacchi MITM in quanto i pacchetti che fluiscono attraverso lo stack TCP/IP sono quasi prevedibili.

Cosa ci vedi di prevedibile?

forse parlava di debian

Non mi stavo riferendo a nessun sistema operativo in particolare. Pensavo che fosse così nella maggior parte dei casi! Come argomento me lo devo rivedere!
Perdonate lo sbaglio!

 

[MEME]

ricordo di un pandemonio causato dall'aggiornamento dopo la scoperta di una vulerabilità di ssh

ora non ricordo bene se era su ssh, anche perchè poi non mi sono informato

 

[shecfhoirmhfuhgoieg]

Inoltre ssh è quasi vulnerabile a attacchi MITM in quanto i pacchetti che fluiscono attraverso lo stack TCP/IP sono quasi prevedibili.

Cosa ci vedi di prevedibile?

forse parlava di debian

Non mi stavo riferendo a nessun sistema operativo in particolare. Pensavo che fosse così nella maggior parte dei casi! Come argomento me lo devo rivedere!
Perdonate lo sbaglio!

la mia era una battuta riferita a un "vecchio" bug si openssl su debian (a cui forse fa riferimentoa nche silent_death) che consentiva di scoprire facilmente le chiavi RSA.
Ma era solo una battuta....

 

[imported_BlackLight]

la mia era una battuta riferita a un "vecchio" bug si openssl su debian (a cui forse fa riferimentoa nche silent_death) che consentiva di scoprire facilmente le chiavi RSA.

Lol, c'è ancora la vignetta, la portavo in firma un po' di tempo fa...

Il problema era dovuto al fatto che uno dei mantainer di Debian, per rimuovere un warning che saltava fuori nel profiling di OpenSSL con Valgrind, warning che era dovuto al fatto che OpenSSL usa delle variabili non inizializzate per aumentare l'entropia nella generazione delle chiavi, ha ben pensato di lasciare la generazione delle chiavi dipendente solo dal PID del processo e da un altro parametro, con il risultato che è stato possibile per un bel po' fare un brute di una chiave in poche centinaia di tentativi. Per fortuna la pezza è stata messa quasi subito e il bug è stato segnalato come critical, però all'epoca l'umorismo e le vignette come quelle sopra si sono sprecati...

 

[Oromis92]

[...] E credimi, un testo cifrato in RSA non è tanto facile da decifrare senza conoscere la chiave privata, a meno che non lasci andare un supercomputer per 2 anni andando di brute force. [...]

solo 2 anni ?
l'RSA è moooooolto sicuro e un bruteforce impiegherebbe un'eternità.
a meno che naturalmente qaulcuno scopra un metodo veloce per fattorizzare i numeri primi, e allora...

guardate qui: http://it.wikipedia.org/wiki/RSA_Factoring_Challenge#Premi_e_annotazioni
dei 54 numeri solo 12 sono stati fattorizzati

questo è il numero più grande:

25195908475657893494027183240048398571429282126204032027777137836043662020
70759555626401852588078440691829064124951508218929855914917618450280848912
00728449926873928072877767359714183472702618963750149718246911650776133798
59095700097330459748808428401797429100642458691817195118746121515172654632
28221686998754918242243363725908514186546204357679842338718477444792073993
42365848238242811981638150106748104516603773060562016196762561338441436038
33904414952634432190114657544454178424020924616515723350778707749817125772
46796292638635637328991215483143816789988504044536402352738195137863656439
1212010397122822120720357

vale ben 200000$ e ha solo due fattori primi

 

[stoner]

[...] E credimi, un testo cifrato in RSA non è tanto facile da decifrare senza conoscere la chiave privata, a meno che non lasci andare un supercomputer per 2 anni andando di brute force. [...]

solo 2 anni ?

Ha parlato di SuperComputer, Roadrunner o Blue Gene dell'IBM potrebbero anche cavarsela in due anni.

 

[shecfhoirmhfuhgoieg]

[...] E credimi, un testo cifrato in RSA non è tanto facile da decifrare senza conoscere la chiave privata, a meno che non lasci andare un supercomputer per 2 anni andando di brute force. [...]

solo 2 anni ?
l'RSA è moooooolto sicuro e un bruteforce impiegherebbe un'eternità.
a meno che naturalmente qaulcuno scopra un metodo veloce per fattorizzare i numeri primi, e allora...

guardate qui: http://it.wikipedia.org/wiki/RSA_Factoring_Challenge#Premi_e_annotazioni
dei 54 numeri solo 12 sono stati fattorizzati

questo è il numero più grande:

25195908475657893494027183240048398571429282126204032027777137836043662020
70759555626401852588078440691829064124951508218929855914917618450280848912
00728449926873928072877767359714183472702618963750149718246911650776133798
59095700097330459748808428401797429100642458691817195118746121515172654632
28221686998754918242243363725908514186546204357679842338718477444792073993
42365848238242811981638150106748104516603773060562016196762561338441436038
33904414952634432190114657544454178424020924616515723350778707749817125772
46796292638635637328991215483143816789988504044536402352738195137863656439
1212010397122822120720357

vale ben 200000$ e ha solo due fattori primi

:O non sapevo pagassero così tanto.... ho deciso cosa farò per i prossimi 50 anni

 

[stoner]

:O non sapevo pagassero così tanto.... ho deciso cosa farò per i prossimi 50 anni

Perderesti solo il tuo tempo

Il concorso finì nel 2007. Secondo la RSA "Ora che l'industria ha una comprensione molto più avanzata della forza crittanalitica dei comuni algoritmi a chiave simmetrica e a chiave pubblica, queste sfide non saranno più attive."