Newsgroup: it.comp.os.linux.sys
Titolo: Under Attack ?!?!? tentativi di login!

Salve a tutti.
Il processo pppd poco fà è andato nello statolimbico
defunct...non c'è stato verso di killarlo e alla fine ho
miseramente riavviato.
Però mentre guardavo il log da /var/log messages ho notato alcune
rige molto sospette...poi ho scoperto che ve ne sono molte e mi
sono convinto che sono tentativi di login, pare via sshd.
Cosa ne dite?
====== alcune righe sono del tipo:
Sep  2 20:47:01 nome-host sshd[22525]: Failed password for invalid
                 user haitac from xxx.xxx.xxx.xxx port 39480 ssh2
Sep  2 20:51:22 nome-host sshd[22686]: Failed password for invalid
                      user eddy from xxx.xxx.xxx.xxx port 54898 ssh2
Sep  2 20:51:24 nome-host sshd[22688]: Failed password for invalid
                       user pam from xxx.xxx.xxx.xxx port 55204 ssh2
Sep  2 20:51:25 nome-host sshd[22691]: Failed password for invalid
                      user hugo from xxx.xxx.xxx.xxx port 55586 ssh2
=================================================================
E chi diavolo sono hugo pam eddy e pincopallino?!?
====== Qualcuno più intraprendente ha cercato direttamente di
loggarsi come root:
Sep 15 12:54:37 nome-host sshd[16711]: Failed password for root
                          from xxx.xxx.xxx.xxx port 46347 ssh2
=================================================================
Ma dico io...chi si permette questa invadenza?
Cosa tenatano di fare? perchè? a che fine?
Come difendersi?
Dal canto mio per quanto ne so, meno server sono accesi e più si
sta al sicuro...quindi prima ho killato il server sshd, quindi
dopo aver googolato un po' e preso atto della situazione ho
impostato il file /etc/hosts.deny così:
ALL:ALL
mantre /etc/hosts.allow è intonso.
Ho esagerato? però dovrebbe essere efficace non vi pare? almeno i
tentativi di login non dovrebbero neanche avvenire...
Poi un altra cosa: sempre dal file di log ho visto un
avvertimento:
================================================================
Aug 31 17:06:17 slack-12 sshd[8379]: Did not receive
           identification string from xxx.xxx.xxx.xxx
Aug 31 17:10:36 slack-12 sshd[8384]: Did not receive
           identification string from xxx.xxx.xxx.xxx
Aug 31 17:22:51 slack-12 sshd[8774]: reverse mapping checking
           getaddrinfo for 
xxx.xxx.xxx.xxx.static.vsnl.net.in
           [xxx.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT!
=================================================================
POSSIBLE BREAK-IN ATTEMPT!
cosa significa e chi mi sta avvertendo di questo? come funziona
grosso modo questo meccanismo di riconoscimento dei furbi?
Grazie in anticipo e scusate ma non mi intendo di questi aspetti.
anche per questo un intervento sul semplice sarebbe gradito...
Saluti  :-)

 Cosa ne dite?
Di un po', la parola Firewall ti e' un po' sconosciuta, vero? :)
iptables ti consente gia' di fare degli ottimi Firewalls! Leggiti la
documentazione e mettine in piedi uno!
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 documentazione e mettine in piedi uno!
Oppure.. cambia la porta di sshd. Quelli s{o,embra}no tentativi di bruteforce
"alla cieca" :)
M2C,
David
-- 
 . ''`.  Debian maintainer | 
http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- 
http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- 
http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

 non mi risulta che sshd usi hosts.deny.
ci sono una serie di programmini tipo denyhosts che sperano nel contrario.

 non mi risulta che sshd usi hosts.deny.
Tempo fa ho provato a mettere su una rete virtuale con VDE tra il
sistema operativo reale e uno virtualizzato al suo interno con
qemu, rete tra guest e host in pratica.
Mi serviva passare dei file tra i due sistemi per questo ero
ricorso a vde (nel frattempo non sapendone nulla di reti...ho
approfittato per toccarle un po' con mano).
bene, alla fine avevo usato scp, ma se non ricordo male, e mi
pare rsync via ssh. Tuttavia sui sistemi avevo dovuto impostare
/etc/hosts.deny consentendo l'accesso almeno all'ip del sistema
host/guest. Per questo dico... Secondo te ricordo male?
Quindi ricapitolando, per prevenire questi tentatividi bruteforce
via ssh l'unica è:
1. disabilitare sshd (io non l'ho attivato, ma probabilmente
all'installazione del pacchetto, viene messo qualche script in
quelli di avvio, così sshd si ritrova in piedi).
Questa soluzione probabilmente sarà quella che perseguirò almeno
per il momento.
2. Mettere in piedi un firewall, che peraltro in effetti non ho
mai avuto...senza danni da me percettibili dopotutto.
3. Cambiare porta al server sshd
Volete aggiungere altro?

 wrote:

Sì, installare un programmino simile a fail2ban che ti blocchi
automaticamente questi tentativi di login

 3. Cambiare porta al server sshd
Disabilitare l'accesso diretto come root

 Cosa tenatano di fare? perchè? a che fine?
secondo te?

 Di un po', la parola Firewall ti e' un po' sconosciuta, vero? :)
[..]
Ti viene in mente che ... MAGARI ... uno ha SSH pubblicato perchè GLI 
SERVE, e non per negligenza ?
Come dire ... se il server scalda troppo, la soluzione per te è ... 
spegnerlo ?
PS: sembrano scripts che tentano del "bruteforcing" un po' a caso ... a 
volte trovo roba del genere nei miei server.
Soluzioni (serie): Limitare l'accesso SSH ai soli pochi utenti che ne 
necessitano, non indiscriminatamente a tutti gli utenti della macchina. 
In genere mi creo un gruppo ssh_users e limito l'accesso via sshd_config 
a quel gruppo. In genere in quel gruppo ci stanno due o tre persone 
scelte bene.
Usare delle "politiche" di complessità per le passwords.
In alternativa, permettere *SOLO* la login tramite chiave. Anche se - 
devo dirlo - questa pratica ha rischiato di ritorcermisi contro usando 
... ehm ... debian (vedi recente pasticcio con openSSL).
ciao, f.

 Volete aggiungere altro?
Usare *esclusivamente* l'autenticazione via chiave, che dovra`
*necessariamente* avere una passphrase, e che dovra` essere creata con
l'ultima versione di OpenSSH disponibile nei repository se ci si trova
su Debian Etch (si, ricordiamo tutti il casino relativo al "bug" in
OpenSSL...)
Enrico

 (si, ricordiamo tutti il casino relativo al "bug" in OpenSSL...)
EH SI, 'tacci sua ...
ciao, f.

 /etc/hosts.deny così:
Io utilizzo BlockHosts, che implementa una politica di accesso basata sul 
numero di tentativi, e poi modifica /etc/hosts.allow di conseguenza. Puo' 
controllare tentativi su diversi servizi: ssh, ftp, ecc. Info sul sito
http://www.aczoom.com/cms/blockhosts/
Ciao, Mauro

 necessariamente avere una passphrase,
forse è un po' troppo
bastano delle password non banali, difficili da scoprire con attacchi basati
su dizionari

 spegnerlo ?
No, gli metto delle ventole, semmai!:)
Quello che pero', **IO**, non farei **MAI**, e' proprio mettere su un
Server attaccato ad Internet e NON installare un Firewall.
Ovvio che SSH serva, ma perche' ammetterlo da tutti? IP dinamico? Ce l'ho
anch'io! Con DynDNS e uno script lato Server lascio scoperti (aperti ad UN
IP che non e' piu' il mio) i Servizi per al massimo 3 minuti al giorno.


 
http://www.aczoom.com/cms/blockhosts/
Grazie per la rispsota.
Sulla questione /etc/{hosts.deny,hosts.allow} non mi è chiara
bene una cosa.
consideariamo la configurazione:
------------
hosts.deny:
ALL:ALL
hosts.allow:
vuoto
-------------
Alla luce della mia poca esperienza, e degli interveti di Mauro e
un altro intervento precedente. Con la configurazione sopra non
dovrebbe essere accessibile ne il server sshd ne altri.
A quanto dice Davide invece, pare che possa esserci la
possibilità...o il dubbio che le cose non stiano precisamente
così.
Mi farebbe comodo una conferma univoca circa l'efficacia di una
soluzione del genere, che per quanto poco elegante mi pare più
semplice e sbrigativa di un firewall (per il quale dovrei anche
mettermi a leggere perchè sono a zero)...almeno temporaneamente.
Col tempo e tempo permettendo mi piacerebbe comunque dedicarmi
alla messa in piedi di un firewall usando iptables...ma come ho
detto devo leggermi la documentazione prima di cimentarmi
nell'impresa.
grazie in anticipo.

 così.
Dipende se sshd è avviato da tcp_wrapper o meno.
Sulla Slackware di default per esempio non lo è, e quindi quel file non
influisce sugli accessi di ssh
Quel che parte con tcp_wrapper, lo puoi gestire con inetd o xinetd
-- 
:cf

 Quel che parte con tcp_wrapper, lo puoi gestire con inetd o xinetd
Scusa l'ignoranza, ma non conosco tcp_wrapper (probabilmente è
grave in questo ng, lo so)...ehm a dire il vero sono piuttosto a
secco anche per quanto riguarda inetd e il suo x-parente  :-\
Niente... Facciamo che disattivo sshd e tanti saluti, tanto ora
non mi serve. E appena avrò il tempo cercherò di capire come
funziona iptables....un firewall dovrebbe bastare no?
Ah, stasera sono finito da google ad un bel sito subgenico, farò
un po' di pubblicità nel thread apposito su ICOLI.
Saluti e grazie mille.  :-D

 forse è un po' troppo
Dipende dal tuo livello di paranoia. Personalmente uso il trittico
chiave + passphrase + cambio porta e, fin'ora, devo dire di non aver mai
avuto problemi[1]
Enrico
[1] tocchiamoci che e` meglio...

 
non c'entra se viene avviato da xinetd o meno, dipende se il demone ha il
supporto per il wrapper tcp.
se dai:
# strings -f /usr/sbin/sshd | grep access
e ti restituisce:
/usr/sbin/sshd: hosts_access
vuol dire che sshd è compilato con il supporto per il wrapper tcp e quindi,
anche se avviato autonomamente, terrà conto di hosts.allow e hosts.deny.

 influisce sugli accessi di ssh
Non e' strettamente necessario che l'esecuzione sia subordinata a
inetd/xinetd, basta che usi le libwrap di suo. Ad esempio, su debian
e' cosi'.
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 anche se avviato autonomamente, terrą conto di hosts.allow e hosts.deny.
Potreste darmi un'ulteriore conferma?
Stando all'output sopra, nel mio caso, come ho editato
/etc/hosts.deny (ALL:ALL), permette o no l'accesso tramite ssh?

 /etc/hosts.deny (ALL:ALL), permette o no l'accesso tramite ssh?
non fai prima a provare?
$ ssh 127.0.0.1
se ti risponde qualcosa del genere:
ssh_exchange_identification: Connection closed by remote host
allora funziona.
quello che mi sfugge è perché vuoi bloccare l'accesso a ALL, spegni
direttamente il servizio.

 direttamente il servizio.
Vero...ma un domani magari dovessi aprirlo a qualcuno, in questo
modo potrei mantenere la "sicurezza" che tutti siano esclusi,
tranne quelli (ip) compresi in hosts.allow:
infatti ho visto che mettendo per esempio:
ALL:ALL
in hosts.deny
e
sshd:127.0.0.1
in hosts.allow
ssh 127.0.0.1 mi presenta il login.

 tranne quelli (ip) compresi in hosts.allow:
ah, va bene, se è per eventuali usi futuri meglio impostare un po' di
sicurezza già da subito.

 Quel che parte con tcp_wrapper, lo puoi gestire con inetd o xinetd
./configure --with-libwrap

 un po' di pubblicità nel thread apposito su ICOLI.
Grazie, ma se prendo queste "cantonate" faccio una figura meschina :-)
In effetti il discorso della compilazione è vero, i'm sorry.
tcp_wrapper serve per lanciare programmi che non hanno il supporto nativo a
host_access quindi?
Il fatto è che io per far "ascoltare" ssh solo dal pc o dalla rete locale,
uso la direttiva ListenAddress del file di configurazione.
Per esempio
ListenAddress 192.168.1.100
Anche se è sicuramente meno "malleabile" è corretto?
-- 
cf

 Anche se è sicuramente meno "malleabile" è corretto?
E' corretto, ma con host_access hai ovviamente un controllo
molto più granulare.