Newsgroup: it.comp.os.linux.sys
Titolo: "strani" log ssh

Ricevo "strani" log ssh:
 
Dec 14 08:28:16 x sshd[14169]: Failed none for invalid user admin from 213.186.170.226 port 64805 ssh2
 
Dec 14 08:28:16 x sshd[14166]: Failed none for invalid user admin from 213.186.170.226 port 64804 ssh2
 
Dec 14 08:28:16 x sshd[14169]: Failed password for invalid user admin from 213.186.170.226 port 64805 ssh2
 
Dec 14 08:28:16 x sshd[14166]: Failed password for invalid user admin from 213.186.170.226 port 64804 ssh2
 
Dec 14 08:50:57 x sshd[14949]: Invalid user setup from 213.186.170.226
Dec 14 08:50:57 x sshd[14949]: Failed none for invalid user setup from 213.186.170.226 port 63201 ssh2
 
Dec 14 08:50:57 x sshd[14949]: Failed password for invalid user setup from 213.186.170.226 port 63201 ssh2
 
 
Il log è palese, nulla di anomalo.
Ciò che è anomale è che SSH è bloccato via firewall, ho appena controllato.
Come può un IP non mio tentare svariati accessi via SSH, se da remoto non ci si può accedere (verificato anche questo) ?

 
con geoiplookup 213.186.170.226
si vede
 
GeoIP Country Edition: JO, Jordan

Come può un IP non mio tentare svariati accessi via SSH, se da remoto non ci si può accedere (verificato anche questo) ?
 
Evidentemente, 213.186.170.226 ci può arrivare.
 
Ipotesi ottimistica: potrebbe esserci una regola ad hoc, immessa per errore,
che glielo consente. Questo secondo me copre il 90% delle probabilità.
 
Ipotesi paranoide: potrebbe esserci una regola ad hoc immessa con intenzione
che glielo consente, o un modo per bypassare l'interfaccia dove è installato
il firewall.
 
Ipotesi DAVVERO paranoide: potrebbe esserci una regola ad hoc o nel software
di netfilter o nel kernel.
 
I successivi due livelli di paranoia non sono autorizzati su Usenet :-). Non
posso né confermare né smentire che i miei livelli di paranoia si limitino a
cinque. Ma, in generale, è tristemente vero che non c'è limite al peggio.
 
Leonardo
 
-- 
 
Ya se escucha sonar la metralla, ya el clarín toca fuego graneado:
ahora o nunca, muchachos arriba a acabar a estos hijos del diablo.

 di netfilter o nel kernel.
 
E come si verifica se non tramite iptables ?

 
https://pastebin.com/raw/EREv16Hy
 
 
Porco cazzo:
 
    0     0 ACCEPT     tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpts:49152:65534 flags:0x17/0x02 

On Thu, 14 Dec 2017 02:12:27 -0800 (PST), 
gandalf.co...@gmail.com
 
wrote:

E quella da dove arriva? :-?


 
 
mettiti in ascolto con un tcpdump, cerca di capire. se vedi traffico il 
firewall è bypassato, in un modo o nell'altro.

 E quella da dove arriva? :-?
 
Dal firewall sul server, ma è una classica regola per l'ftp passivo
ed oltretutto SSH non è in ascolto su quelle porte li ma sulla classica 22.

 firewall è bypassato, in un modo o nell'altro.
 
Ho rifatto il firewall, ora non passa più.
Il mio problema però è sapere non se passa da fuori, ma *perchè* passa.
Il *se* lo so già: passa, per qualche motivo a me ignoto. (ho provato anche
da un altro mio server che non ha accesso ssh a questo: ci si connetteva)
 
C'è modo di bypassare "iptables" ed alterare le regole senza 
farle riflettere in iptables ? In /proc/ o /sys/ non mi pare ci sia nulla 
che elenchi le regole attive.
 
No, il binario "iptables" non è compromesso, l'ho ripristinato 
dal mirror ufficiale della distribuzione (e gli md5 corrispondevano)

farle riflettere in iptables?
 
Avoglia, ma ci vorrebbe un signor lavoro. Dovresti aggiungere un campo
"aumm" ad ogni regola per non farla comparire in output (e neanche nel
codice di numerazione).
 
O aggiungere una backdoor in netfilter, per esempio fare passare tutti
i pacchetti che hanno il bit "EVIL" impostato ad 1 aggirando il codice
di controllo. Questo forse è più facile.


 che elenchi le regole attive.
 
 
  Netfilter?
 
Alessandro
 
 

 da un altro mio server che non ha accesso ssh a questo: ci si connetteva)
 
 
Perdonami, forse mi sono spiegato male. Intendevo
 
tcpdump -ni TUAINT host 213.186.170.226
 
così da capire TUTTE le attività di quello che hai rilevato essere l'ip 
anomalo. Potresti scoprire backdoor e altre porte di controllo.

   Netfilter?
 
Si, ma come ?

 anomalo. Potresti scoprire backdoor e altre porte di controllo.
 
Non è un problema di backdoor.
Semplicemente perchè da un mio server sono riuscito a collegarmi via SSH nonostante ci fosse una regola in DROP.
 
In altre parole: il firewall non firewallava.
 
La domanda in realtà è: come è possibile che, nonostante le regole postate sopra,
l'accesso alla 22/tcp fosse comunque autorizzato ?
 
Forse mi sfugge qualcosa, magari c'è una regola sbagliata, le ho postate ieri,
non vedo anomalie, personalmente.
 
L'unica "apertura" è l'FTP passivo, ma io mi sono collegato diretto alla 22
e non a strane porte > 40000 come da regola del passivo.

> 
https://pastebin.com/raw/EREv16Hy
 
 
Allora, eliminando le regole sui tuoi IP, passivo, non-tcp, non-SSH, a me
**sembra** di leggere:
 
# iptables -L -n -v              
Chain INPUT (policy DROP 3 packets, 156 bytes)
 pkts bytes target     prot opt in     out     source destination         
  606 43140 fail2ban-SSH  tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
 
tcp dpt:22 
 
Il pacchetto arriva e passa a fail2ban.
 
Chain fail2ban-SSH (1 references)
 
  606 43140 RETURN     all  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
 
 
In fail2ban non c'è l'IP e si prosegue.
 
 8679 1143K ACCEPT     all  --  *      *      !mio.ip.1        
0.0.0.0/0
 
limit: avg 10/sec burst 5 
 
Il pacchetto viene accettato purché non sia troppo veemente.


 Il pacchetto viene accettato purché non sia troppo veemente.
 
Hai ragione.
E' sbagliata la regole di ratelimit. 
Ora non si presenta più il problema perchè tale regola è stata rimossa 
quando ho aggiornato la configurazione (ieri)