Newsgroup: it.comp.os.linux.iniziare
Titolo: Domanda su ssh

Ciao a tutti,
Ho un serverino Debian lenny con su ssh che è raggiungibile dall'esterno. Ho 
impostato l'accesso con chiave pubblica + password, insieme a una serie di 
altre misure per evitare accessi indesiderati (rifiuto il login di root, 
accetto solo il login di utenti appartenenti a un certo gruppo, ...). 
Periodicamente logcheck mi manda una mail avvisandomi delle cose "strane" 
che avvengono sul server. 
Oggi ho ricevuto un messaggio come questo:
Dec  9 10:32:00 gerlos sshd[10294]: Failed password for root from 
192.168.1.3 port 34852 ssh2
La cosa non mi avrebbe stupito se 192.168.1.3 non fosse l'indirizzo IP del 
mio sistema desktop su cui lavoro, che appartiene ala stessa rete locale del 
serverino... La mia domanda perciò è questa: è possibile che un intruso 
abbia falsificato l'IP sorgente della connessione facendo comparire un IP 
locale, o devo pensare che il mio sistema desktop è compromesso?
Il sistema desktop ha tutte le porte chiuse, salvo la 22 (così posso 
trasferirvi file via sftp dal portatile) e quelle associate a amule e 
bittorrent. Il router è configurato per instradare le connessioni di amule e 
bittorrent direttamente al desktop.
Che ne dite?
grazie a tutti
gerlos
-- 
"Solo lo scienziato è vero poeta: ci dà la luna, ci promette le stelle,
 ci farà un nuovo universo se sarà il caso."
                 < 
http://gerlos.altervista.org
 >
 gerlos  +- - - >  gnu/linux registred user #311588

 locale, o devo pensare che il mio sistema desktop � compromesso?
Inizia ad escludere i falsi positivi. Ad esempio, sei sicuro che non ci 
sia alcun servizio (backup, per esempio) che cerca di accedere al 
server via ssh? A volte si usa rsync in modalita' ssh, e si imposta una 
sincronizzazione ad intervalli regolari.
Comunque, se il server e' accessibile dalla rete pubblica, aspettati 
dozzine di tentativi di intrusione. Io uso Denyhosts per bloccarli, e 
ogni giorno vedo almeno due o tre tentativi.

 ogni giorno vedo almeno due o tre tentativi.
Interessante denyhosts, non lo conoscevo... 
Sì, effettivamente anche io ricevo un certo numero di tentativi di 
connessione, ma quasi totalmente *dall'esterno*. A parte le misure di 
sicurezza di sshd, di solito li tengo fuori usando iptables, che è 
configurato in modo da rifiutare le connessioni alla porta 22 troppo 
"rapide" da un certo IP, che va in una blacklist temporanea. Finora sembra 
aver funzionato, visto che al 4° tentativo di connessione non riscontro più 
tentativi da quell'IP.
Adesso sto controllando il desktop con rkhunter, chkrootkit e zeppoo, 
vediamo un po'...
grazie


 Entrambe le cose sono possibili. Verifica.
Ok, visto che non riesco ad immaginare come sia possibile la prima opzione 
in particolare (IP esterno falsificato come locale), sapresti dirmi di più 
in proposito?
Immagino che in un caso come quello il problema potrebbe essere 
controllabile agendo sul mio router linksys, giusto?
Hai qualche suggerimento su come potrei fare delle verifiche su questa e 
sull'altra opzione?
Scusa se queste domande possono sembrare banali, ma non sono molto informato 
in proposito...
grazie in anticipo 


 a un certo gruppo, ...).
Dimetichi quello forse migliore, cambiare la porta del demone.


A patto che il provider non filtri le connessioni in uscita. A me
e' capitato, potevo uscire solo sulla 22 (oltre che sulle porte http/https).


mi inserisco un istante:
pu� causare problemi mettere ssh in ascolto sulla 443 (a parte non 
seguire la RFC)?
--
sv.

 seguire la RFC)?
Se non c'è un analizzatore di traffico a L7 con apposita policy, no. 
-- 
Vide

 seguire la RFC)?
Non credo. Ma il problema resta: siccome non c'e' un essere umano, ma 
una macchina, a fare i tentativi, anche porte "strane" vengono subito 
individuate e attaccate. D'accordo, magari un terzo dei robot provano 
solo la 22, ma i restanti due terzi si accorgeranno subito del piccolo 
inganno.
Per qualche mese, ho tenuto il server ssh sulla 2222: alla fine non 
cambiava quasi nulla.

 ma puoi avere una password sul certificato.
Chiaramente, è questo il mio caso. Scusate se la spiegazione era infelice.
ciao


 e non ho un tentativo di connessione che e' uno...
Definisci la tua configurazione. Sulla mia macchina, nel giro di due 
giorni i tentativi
di intrusione si ripresentavano come prima. Poi ho rinunciato, anche perche' mi
serviva collegarmi dall'universita', che bloccava ssh in uscita eccetto 
che verso la porta 22.
D'altronde, se lanciavo nmap verso il mio server, la porta "strana" 
risultava subito aperta.
Deduco che il semplice spostamento di porta non sia la panacea di ogni male.

 login da parte dei soliti rompimarroni nei log.
Forse nel mio caso la colpa e' del fatto che la macchina fa parte di un 
pool di indirizzi pubblici
assegnati allo stesso ente, e i tentativi sono piu' mirati e raffinati. 
Se vuoi "bucare" una macchina
della rete del Pentagono, probabilmente userai strumenti meno scontati 
dei soliti robot.


ok, ma per poter connettersi al server da dietro un proxy che fa passare 
solo http/https esistono alternative?
--
sv.

 passare solo http/https esistono alternative?
Se il proxy lascia passare solo http(s), l'unica scelta elementare e' 
mettere in ascolto sshd sulla porta 80 (o 443). Personalmente, uso un 
tunnel vpn in ascolto sulla porta 80 della mia macchina remota. In 
questo modo ho tutti i vantaggi di un tunnel criptato verso l'esterno.