Newsgroup: it.comp.os.linux.sys
Titolo: Re: tentativo di brute force su ssh

 Esperienze simili in giro?
Come disse qualcuno, benvenuto in internet :-P
Io mi son fatto uno script per bloccare tali attacchi dopo x tentativi e
lo usavo prima di scoprire fail2ban :-D
E comunque ho sempre fatto tutto (nel caso di server con interfaccia
esterna) tramite vpn (su una porta diversa dal "normale") o ssh via
certificati digitali e comunque su una porta diversa.
Enrico

 p.s.: se mai dovessi aprire SSH all'esterno lo faro' su una porta diversa.
 
Se lo usi solo tu, potresti considerare il port knocking, cosi' non devi
aprire nulla.

 awk '{ print $( NF - 2 ) }' | uniq |wc -l
3133
$
(io ho gli auth.log (e molti altri log) gzippati...)
-- 
 . ''`.  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

 Esperienze simili in giro?
normale amministrazione, specie se sei su una dialup....
ilSimo
-- 
now playing: 
Gods of deliverance, how can I set free
Souls in the underworld
Calling out for me...They're in my head
                                Gammaray - Gods Of Deliverance

 Busso prima di entrare e qualcuno mi deve aprire??
Piu' o meno... 

 Esperienze simili in giro?
Hai voglia; dopo la prima volta, cambi la porta standard e te
ne dimentichi.

 
centinaia al giorno, perché?
Se hai le chiavi l'unico danno è il log che si ingrossa, se metti 
sshblacklist o similari li mandi a cagare dopo poco.
root@smtp:~# route -n |grep -c '!'
166
peccato che in caso di riavvio si perdano
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
There exist tasks which cannot be done by more than 10 men or fewer
than 100.
		-- Steele's Law

 Esperienze simili in giro?
Ah, questi novellini... Benvenuto fra i lupi.
Ci sono vari modi per evitarlo. Il primo, come dici tu, e' levarsi dalla 
porta 22. Molto probabilmente dopo non avrai piu' problemi.
Poi ci sono metodi piu' sofisticati.

 nel dettaglio 'sto port knocking e tutto il resto...
Roba da 5 minuti massimo. Ma secondo me e' gia' overkill.

 Roba da 5 minuti massimo. Ma secondo me e' gia' overkill.
Perche' dici cosi ?
Rizio

 diversa.
Io no, non è la soluzione, invece trovo molto più utile limitare il
numero di connessioni attivabili da un unico IP per un dato quanto
temporale, con shorewall ad esempio:
ACCEPT  net             dmz:12.34.56.78 tcp     ssh     -  -  3/min:5
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

 
L'ho gia' spiegato sopra. Gli attacchi di cui parliamo sono stupidi, non 
controllano altre porte.
Naturalmente lo knocking e' meglio. Ma se usi ssh da remoto una volta 
all'anno rischi di non ricordarti la sequenza. C'e' poi il problema di 
comunicarlo agli altri utenti, e farlo capire.

 


 comunicarlo agli altri utenti, e farlo capire.
non ti pare un po' esagerato?
i tentativi di login sono poco pericolosi perchè comunque le password che
tentano di inviare sono banali (test, demo, <userid>, cose così)
perchè semplicemente non ignorarli?

 minchia!
ah beh, io 2525....penso cambiero' porta a ssh...
Ciao Jack

 non ti pare un po' esagerato?
Uno che dice che cambiare porta non basta. L'altro che consiglia di 
ignorarli del tutto.
Il mondo e' bello perche' e' avariato (cit.)

 che tentano di inviare sono banali (test, demo, <userid>, cose così)
non ti è mai capitato l'utente che ha messo la password identica alla
login? <G>
(no, non c'era nessun controllo che la password fosse troppo facile
perché il capo non riusciva a trovarne una adeguata...)


 perché il capo non riusciva a trovarne una adeguata...)
la madre del cretino è sempre incinta

 wrote in news:g3dslc$kcf$
1...@aioe.org
:

pero', porca miseria, e' mai possibile che sia sempre il capo, ad avere 
cosi' tanti fratellini?
e tutti che gli somigliano, per giunta...
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 controllano altre porte.
La domanda riguarda il knocking, volevo capire perche' lo consideri off 
ed avere un paio di altri pareri in replica.
Rizio

 La domanda riguarda il knocking, volevo capire perche' lo consideri off
Off??? Mai detto questo.

 da una porta XXXX
Perchè non direttamente un bel Port XXXX in sshd_config?

 temporale, con shorewall ad esempio:
Periglioso.

 Se fai nmap su XXXX la porta risulta chiusa
Una porta tcp chiusa equivale a un bel reset-ack in risposta
ad un syn.
Il che equivale all'impossibilità di aprire alcuna connessione.
Quindi delle due l'una:
- o hai messo la regola in tabella di nat, catena di prerouting
ed hai dimenticato la regola in tabella di filter, catena di input
- o hai fatto nmap in una condizione in cui il tuo dnat non può
funzionare, tipo dal localhost avendo messo la regola di dnat solo
su eth0, o simili.

 awk '{ print $( NF - 2 ) }' | uniq |wc -l
4
Noi abbiamo la 22 delle macchine in serverfarm (remota, su fibra dedicata)
accessibile solo dall'ip dell'ufficio. Se da fuori voglio ssh-are faccio
vnc sulla macchina della segretaria e rimbalzo da li. 
Problema risolto alla radice firewallando.
-- 
g4b0, linux user n. 369000
http://gabo.homelinux.com

 Off??? Mai detto questo.
Va bene, ciao....
Rizio

 
certo che i vari server vnc sono "leggermente" + sputtanabili degli 
ssh.. :P ..
e comunque dopo che ti hanno piazzato un rootkit nella segretaria ti 
scippano anche l'accesso a ssh.
magari il pc della segretaria monta anche WinsozXP ?!


Eh, scusa tanto se non indovino subito cosa hai in testa, neh.

Mr. Braciola wrote:

Saggia affermazione.. Comunque la segretaria accende il server vnc quando le
telefono, altrimenti lo tiene staccato. In effetti non è il massimo, ma
succederà una volta all'anno una situazione simile. Comunque sto dando un
occhiata al port knocking, così mi evito ogni problema.
tnks


 user aarti ... Failed password for invalid user abdenace ... [...]
Oltre a cambiare la porta di default, installa denyhosts
$ aptitude show denyhosts
Package: denyhosts
[...]
Description: an utility to help sys admins thwart ssh hackers
DenyHosts is a program that automatically blocks ssh brute-force attacks 
by adding entries to /etc/hosts.deny. It will also inform Linux 
administrators about offending hosts, attacked users and suspicious 
logins. 
Syncronization with a central server is possible too.
Differently from other software that do same work, denyhosts doesn't need 
support for packet filtering or any other kind of firewall in your kernel

 e tutti che gli somigliano, per giunta...
Murphy insegna che gli idioti vengono sempre messi nei posti dove
possono fare il maggior danno col minimo sforzo.


 Periglioso.
Perché? 


 Perché?
Tutte le azioni proattive automatiche firewall-based possono
trasformarsi in un DoS-boomerang, se non valutate con attenzione.
Non conosco la sintassi di shorewall, ma immagino che quella regola
usi in qualche modo il modulo limit.
Beh, a seconda di come è effettivamente scritta la regola di iptables,
qualcuno che voglia negare l'accesso a ssh potrebbe sparare una raffica
periodica di pacchetti, magari spoofed, che azionino quella regola e negare
l'accesso a utenti legittimi.

 l'accesso a utenti legittimi.
Se usa connlimit il problema è fortemente mitigato.

 
Limit o connlimit? Anzi, più che di limit bisognerebbe parlare di hashlimit 
(che ti permette di impostare limiti per IP).
ipt_connlimit, da quello che capisco dalla man page e da una veloce lettura 
ai sorgenti, dovrebbe appoggiarsi al connection tracking di netfilter e 
tenere conto, ai fini delle soglie, delle connessioni TCP in stato "established".
Mi pare, pertanto, che un eventuale attacker non possa limitarsi a sparare 
pacchetti TCP con IP sorgente spoofato, ma debba simulare l'intero three-way 
handshake, cosa molto meno facile.
Cmq potrei sbagliarmi, io sono solo un hobbysta.

 Se usa connlimit il problema è fortemente mitigato.
Certamente, quanto meno elimini il problema dei DoS con sorgente
spoofata.

 l'intero three-way handshake, cosa molto meno facile.
In realtà la cosa è più complessa di quanto si possa credere, a rettifica
di quanto ti avevo precedentemente risposto.
Facciamo un esperimento.
Mi metto in listening su porta tcp 3333 con netcat su un host:
$nc -l -vv -p 3333
listening on [any] 3333 ...
$ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:50:56:af:4d:08
          inet addr:172.22.50.151  Bcast:172.22.50.255  Mask:255.255.255.128
          inet6 addr: fe80::250:56ff:feaf:4d08/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:891370 errors:140 dropped:0 overruns:0 frame:0
          TX packets:324791 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:344177936 (328.2 MiB)  TX bytes:172362512 (164.3 MiB)
          Interrupt:17 Base address:0x1424
A questo punto, carico il conntrack
$modprobe nf_conntrack_ipv4
Diamo un'occhiata al conntrack
$grep 3333 /proc/net/ip_conntrack
Nessun output.
Spostiamoci su un altro host, ora.
$hping -c 1 -S -p 3333 172.22.50.151
HPING 172.22.50.151 (eth0 172.22.50.151): S set, 40 headers + 0 data bytes
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=0 win=5840 rtt=3.1 ms
--- 172.22.50.151 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 3.1/3.1/3.1 ms
hping invia un SYN, riceve un SYN-ACK e manda a quel punto un RST.
Per cui, nuovamente
$grep 3333 /proc/net/ip_conntrack
sull'host bersaglio ha output nullo.
Impediamo a hping di mandare il RST e vediamo cosa accade.
Sull'host che fa hping mettiamo una regola ad hoc:
$iptables -A OUTPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -j DROP
ripetiamo hping
$hping -c 1 -S -p 3333 172.22.50.151
HPING 172.22.50.151 (eth0 172.22.50.151): S set, 40 headers + 0 data bytes
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=0 win=5840 rtt=0.2 ms
--- 172.22.50.151 hping statistic ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
Stesso risultato, ma vediamo cosa c'è nella conntrack table dell'host beraglio, ora:
$grep 3333 /proc/net/ip_conntrack
tcp      6 43 SYN_RECV src=172.22.50.150 dst=172.22.50.151 sport=1409 dport=3333 packets=1 
bytes=40 src=172.22.50.151 dst=172.22.50.150 sport=3333 dport=1409 packets=4 bytes=176 
mark=0 secmark=0 use=1
Ciò che non si sa molto, in generale, è che gli stati *interni* del kernel sono
più complessi di ESTABLISHED, RELATED, INVALID e NEW.
SYN_RECV è uno degli stati di netfilter.
Vediamo.
Sull'host bersaglio, inseriamo una regola con connlimit:
iptables -A INPUT -p tcp --dport 3333 -m connlimit --connlimit-above 3 -j REJECT
Ripetiamo ora hping con count 4 e vediamo cosa accade dopo il terzo SYN (ricordiamo
che stiamo impedendo ai reset di raggiungere l'host bersaglio)
e diamo un'occhiata alla conntrack table del bersaglio
$hping -c 4 -S -p 3333 172.22.50.151
HPING 172.22.50.151 (eth0 172.22.50.151): S set, 40 headers + 0 data bytes
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=0 win=5840 rtt=0.4 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=1 win=5840 rtt=0.3 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=2 win=5840 rtt=0.3 ms
ICMP Port Unreachable from ip=172.22.50.151 name=UNKNOWN
]$cat /proc/net/ip_conntrack|grep 3333                                  
tcp      6 59 SYN_RECV src=172.22.50.150 dst=172.22.50.151 sport=2998 dport=3333 packets=1 
bytes=40 src=172.22.50.151 dst=172.22.50.150 sport=3333 dport=2998 packets=5 bytes=220 
mark=0 secmark=0 use=1
tcp      6 59 SYN_RECV src=172.22.50.150 dst=172.22.50.151 sport=2999 dport=3333 packets=1 
bytes=40 src=172.22.50.151 dst=172.22.50.150 sport=3333 dport=2999 packets=5 bytes=220 
mark=0 secmark=0 use=1
tcp      6 58 SYN_RECV src=172.22.50.150 dst=172.22.50.151 sport=2997 dport=3333 packets=1 
bytes=40 src=172.22.50.151 dst=172.22.50.150 sport=3333 dport=2997 packets=5 bytes=220 
mark=0 secmark=0 use=1
Ops! Il DoS è servito.
In realtà la soluzione c'è: non bisogna utilizzare solo connlimit, ma anche ctstate:
iptables -R INPUT 1 -p tcp --dport 3333 -m conntrack --ctstate ESTABLISHED -m connlimit --connlimit-above 3 -j REJECT
A quel punto
HPING 172.22.50.151 (eth0 172.22.50.151): S set, 40 headers + 0 data bytes
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=0 win=5840 rtt=0.                                                                              3 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=1 win=5840 rtt=0.                                                                              3 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=2 win=5840 rtt=0.                                                                              2 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=3 win=5840 rtt=0.                                                                              2 ms
DUP! len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=0 win=5840 r                                                                              tt=3105.3 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=4 win=5840 rtt=0.                                                                              2 ms
DUP! len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=1 win=5840 r                                                                              tt=3705.2 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=5 win=5840 rtt=0.                                                                              2 ms
DUP! len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=2 win=5840 r                                                                              tt=3503.4 ms
len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=6 win=5840 rtt=0.                                                                              2 ms
DUP! len=50 ip=172.22.50.151 ttl=64 DF id=0 sport=3333 flags=SA seq=3 win=5840 r                                                                              tt=3702.9 ms
--- 172.22.50.151 hping statistic ---
7 packets transmitted, 11 packets received, -57% packet loss
In conclusione: iptables/netfilter sono strumenti di manipolazione
dei pacchetti estremamente potenti, ma vanno usati avendo cognizione
di causa; avendo tale cognizione, ti consentono quasi sempre di trovare
una soluzione ad un particolare problema di manipolazione dei pacchetti.
Usare connlimit, in questo caso, non basta: bisogna usare anche il ctstate
del modulo di conntrack, per mitigare la possibilità di brutti scherzetti.

 regola e negare l'accesso a utenti legittimi.
Verrebbe negato l'accesso solo dall'ip che spara la raffica, che è
quello che voglio. 8-)


 quello che voglio. 8-)
E se l'ip fosse uno dei "tuoi"? ;-)

 periodica di pacchetti, magari spoofed, 
Correggetemi se sbaglio, ma la connessione ssh è tcp, quindi un indirizzo
spoofed non riuscirebbe a completare l'handshake SYN, SYN-ACK, ACK e non
giungerebbe al punto da tentare il login.
Stefano



No, non sbagli, ma il punto era, ormai, un altro.

 E se l'ip fosse uno dei "tuoi"? ;-)
si avrebbe il grosso vantaggio di tenere lontano un CL che non sa
nemmeno scrivere la sua password. <G>


 gia' che ci sei *se ti va*, il mio host e' 
maxadamo.homelinux.org
Ok, it's running.

 nei file di configurazione.
nc 89.24.235.91 2222
SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2

 Ma hai usato un ciclo for ?
Spezzettato nmap in enne, anche perchè hai cambiato indirizzo, a
un certo punto.
Interesting ports on 
89-24-235-91.i4g.tmcz.cz
 (89.24.235.91):
PORT     STATE SERVICE VERSION
2222/tcp open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)

 perché il capo non riusciva a trovarne una adeguata...)


 ne dimentichi.
Meglio ancora... ho messo ssh in ascolto solo su IPv6
Così almeno iniziamo ad usarlo per qualcosa di utile :-)
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

Salve a tutti,
A proposito di SSH vorrei un piccolo aiuto :
Vorrei collegarmi tramite ssh ad una macchina nel mia rete anche
dall'esterno.
p.e.
ssh -l myaccount 
myhost.mydomain.com
tra la rete internet e lan c'è un firewall (una macchina Linux). Al
momento per collegarmi
al host nella LAN mi collego prima sulla macchina che funge da
firewall e da li mi collego nella sottorete,
vorrei evitare questo doppio passaggio e collegarmi direttamente con
il seguente comando
ssh -l myaccount 
myhost.mydomain.com
Spero di essere stato chiaro
Nicola.

 ssh -l myaccount 
myhost.mydomain.com
Un modo per risolvere il tuo problema è quello di usare il DNAT
di iptables.
iptables -t nat -A PREROUTING -i $interfaccia_internet \
-d $ip_pub_firewall -p tcp --dport 2222 - j DNAT --to \
$ip_server_lan:22
(dove eth
Occorrono poi le opportune regole di filtering nella catena di
FORWARD.


Con il NAT mi è tutto chiaro il problema è che vorrei inviare il
comanda ssh -l myuser 
host.mydomain.com
dove "
host.mydomain.com
" non è l'indirizzo IP ma un nome registrato
sul DNS. Il problema e che con il DNS io registro l'indirizzo pubblico
del firewall come faccio poi a rigirarlo sull'host.Ho un unico
indirizzo IP a disposizione. Per il protocollo HTTP uso Apache le
rewrite rule o proxy pass e giro le richieste verso i server di back-
end ma con il protoccolo ssh come faccio?.
Spero di essere stato chiaro
Nicola
 Con l'indirizzo IP tramite le regole di NAT riesco a farlo
tranquillamanete.

 Spero di essere stato chiaro
spero di aver capito ;-))
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.

Ti ringrazione per lqa risposta la tua potrebbe essere una soluzione
però vorrei rendere trasperente agli utenti
che devono collegarsi in ssh il doppio passaggio anche se richiede
solo una riga di comando.
E' possibile perchè l'ho utilizzato in passato per un'altra sottorete
non gestita da me.
Grazie

 2222/tcp open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
2222 ma e` sorprendente! E' la stessa porta su cui tengo l'SSH a casa 
anch'io :)
Bye,
  Gabry
PS: Scommetto che 12345 e` la combinazione sia della mia che della tua 
valigia!

 valigia!
Beh nessuno la proverebbe, è troppo semplice :-P
Enrico

 valigia!
Della mia?
Certamente, ma con quella combo lì ti scoppia in faccia. <g>