Newsgroup: it.comp.sicurezza.varie
Titolo: Log e tentativi di accesso

Salve a tutto l'NG,
sono un sysop che gestisce alcune macchine connesse ad Internet.
I log sono spesso zeppi di tentativi di accesso abusivi, come ad 
esempio:
[CUT]
Dec  6 16:49:07 sftp sshd[17984]: Illegal user govanni from [x]
Dec  6 16:49:07 sftp sshd[17986]: Illegal user antonio from [x]
Dec  6 16:49:07 sftp sshd[17988]: Illegal user piero from [x]
Dec  6 16:49:08 sftp sshd[17990]: Illegal user francesco from [x]
Dec  6 16:49:08 sftp sshd[17992]: Illegal user iacopo from [x]
Dec  6 16:49:08 sftp sshd[17994]: Illegal user bartolomeo from [x]
Dec  6 16:49:09 sftp sshd[17996]: Illegal user niccolo from [x]
[CUT]
Ho fatto un whois sull'IP [x] e sarei tentato di mandare un'email a 
chi di dovere. Voi che fareste al posto mio? 
Vale la pena intervenire oppure è meglio semlicemente ignorare tali 
sciocche attività?
Ed inoltre, questi log hanno qualche valenza legale? (Secondo me no).
-- 
Gabriele Chervatin

 Ed inoltre, questi log hanno qualche valenza legale? (Secondo me no).
Probabilmente la macchina da cui vengono quei tentativi di accesso e'
stata compromessa, ed il legittimo utilizzatore e' ignaro di quel che
accade. Tienine conto, nelle tue valutazioni sul da farsi.
Fabio

 farsi. 
Si c'è da aspettarselo. Il mio amletico dubbio è se decidessi di 
intervenire farei più male che bene.
Sinceramente non ho nessuna voglia di creare dei problemi (magari 
seri) ad un utente poco accorto della sicurezza della propria 
macchina, ma se questo mio intervento potesse sensibilizzare l'utenza 
in generale, allora il tuto avrebbe un senso.
Grazie per le tue opinioni
-- 
Gabriele Chervatin

 in generale, allora il tuto avrebbe un senso.
Ti posso dire quel che faccio io in genere: se ho immediata evidenza 
che dall'altra parte c'e' un interlocutore che e' anche responsabile
del'utilizzo delle macchine (azienda, universita', ecc ecc) cerco di
contattare un sysadmin per notificare l'accaduto, mentre nel caso di
dialup o roba non identificata, lascio perdere. Questo probabilmente
e' sbagliato, perche' non sensibilizza ne' l'utenza, ne' gli isp, ma
purtroppo non ho tempo per fare tutto. Penso che non sia fuori luogo
pretendere che sia chi si trova dall'"altra parte del cavo", sia chi
fornisce la connettivita', si sbattano per fronteggiare gli abusi.
Se segui it.news.net-abuse, c'e' anche chi comincia a seguire le vie
legali nei confronti, addirittura, degli isp, per fronteggiare casi,
in fondo, non poi cosi' dissimili nella sostanza (macchine -=0wn3d=-
che pacioccano a piacimento in rete senza che nessuno faccia nulla).
Fabio

esempio:
Una soluzione - giusto per non avere i log pieni di porcherie - e' usare
ipchains e il modulo "string", per riconoscere quei pacchetti e buttarli
via. QUELLO specifico worm utilizza una libreria specifica e si riesce a
riconoscerla.
Altrimenti si puo' fare in modo di scartare tutte le connessioni SSH che
*NON* hanno una specifica version string (magari tarocca) pero' e' molto
piu' complesso.
Sperando di non aver fatto bischerate:
$IPTABLES -t filter -N lame
Il primo pacchetto di un certo host che matcha la regola di laming viene
respinto macari con un REJECT se possibile (se no DROP e ėsati):
$IPTABLES -t filter -A lame -j LOG --log-prefix 'lame: '
$IPTABLES -t filter -A lame -m recent --name lame --set -j REJECT
I pacchetti successivi vanno tutti in DROP finche' non c'e' stata quiete
per almeno un'ora:
$IPTABLES -A incoming -m recent --name lame --seconds 3600 --update \
	-j DROP
I pacchetti di questo tipo sono pacchetti TCP, porta 22, con la firma di
quel particolare worm (altri esistono):
$IPTABLES -A incoming -j lame -p tcp --dport 22 \
	-m string --algo bm --string "SSH-2.0-libssh-0.1"
E ora una bischerata :-), ovvero un sistema potenzialmente pericoloso di
tirare uno stronchino ai tizi che mandano i popup di WinMessenger usando
il noto exploit del flag fantasma, beccando i pacchetti con quel flag:
$IPTABLES -A incoming -j lame \
        -p udp --dport 1025:1032 \
        -m string --from=20 --to=32 \
        --algo bm --hex-string "|04 00 28 00 10|"
(Il problema e' che questo non e' TCP, e' UDP; sicche' sarebbe meglio un
-j DROP - anche perche' la strategia di sweeping dello spam-worm e' tale
che uno stesso host non riceve piu' di un messaggio ogni quattro ore, da
un qualsiasi dato IP, per cui -j lame serve un po' a poco, anzi intasa i
log per niente).
Leonardo S.E.&O.
-- 
La societa' londinese mi2g, specializzata in digital risk management,
ha assegnato la palma del "sistema operativo piu' sicuro al mondo" al
Commodore VIC 20, su cui non si registrano falle da oltre tre anni.
http://punto-informatico.it/p.asp?i=50281
  (lies, damned lies and...)

 sistemi di blacklisting automatico, ratelimiting, analisi dei log...
un bel reject a livello di routing e via :-)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
E' un pubblico di gente davvero dura.  Sono soliti legare i loro pomodori
a degli yo-yo, cosi' te li possono tirare due volte.
		-- Bob Hope

sciocche attività?
sono una sorta di worm o script che dir si voglia e anche decisamente 
stupidi. Ne ho fatto loggare uno e lui si è sloggatto e ha continuato 
imperterrito tentando altri user e passoword senza svolgere alcuna 
attività (cmq castrata). 
Sembra che si limitino a prender a informazioni da passare all'umano 
che ci stat dietro .

Signori grazie mille per i vostri interventi.
Un ringraziamento particolare a Leonardo Serni per le sue indicazioni 
sempre puntuali ed uno a Il Poeta della Corteccia per aver condiviso 
la sua esperienza su quel tipo di worm.
All'inizio il mio dubbio era se fosse utile intervenire presso i 
network owner di certe macchine, ma dopo il  vostro intervento ho 
scoperto come (nel caso specifico) proteggersi maggiormente.
Ancora un sentito grazie.
-- 
Gabriele Chervatin

 	-m string --algo bm --string "SSH-2.0-libssh-0.1"
Poiche' il match e' stateless, si potrebbe montare un DoS all'host 
protetto inviando dei pacchetti tcp con <ip> sorgente qualsivoglia
et payload matchante, bloccando, cosi', il traffico tra <ip> ed il
nostro host. Poiche' la direttiva recent nomata "lame" e' priva di
match su protocollo e stato, il DoS sarebbe esteso ad ogni tipo di
traffico entrante.
Il match string deve essere limitato al solo traffico ESTABLISHED.
Con questo accorgimento l'unica controindicazione rimanente per un
approccio come questo sarebbe (a parte l'essere specifico per quel
bot) il fatto che i socket aperti dagli scannerz sugli host target
rimarrebbero appesi in una sessione che non si chiudera' mai salvo
timeout dell'applicazione relativa. Non sarebbe un grosso problema
con questi scanz ssh ma, in generale, occorrerebbe valutare questo
aspetto (se si fosse fatto ai tempi, su http, per nimda e codered,
sarebbe potuto essere disastroso). Per eliminare questo problemino
si puo' inserire una regola active response di snort ma la cosa si
comincerebbe a fare un po' piu' complicata.
Fabio

 E comunque in generale, quali potrebbero essere gli effetti?
Consunzione di risorse del server.
I fattori da considerare sono il timeout della sessione lato server e
la frequenza delle connessioni "malevole" provenienti da ip distinti. 
Nel caso a cui si fa riferimento (openssh?), il timeout di default e'
di 10m e la frequenza, oggi, e' molto bassa, quindi non c'e' certo un
gran rischio ad adottare, ora e per ssh, questi metodi di filtraggio.
Ma...
Fabio pessimista
[1] il client malevolo completa il three way handshake con il server;
    il server invia la sua stringa identificativa al client (1 pkt) e
    e attendera' una risposta. Il client risponde con un pacchetto il
    cui payload matcha con la direttiva "string". Il pacchetto verra'
    DROPpato, sparendo dalla nostra dimensione spazio-temporale, o lo
    si REJECTera', rispondendo unreachable (ma meglio RST) al client.
    Per buona norma, una cattivissima direttiva recent blocchera' sul
    nascere ogni altra interazione tra il nostro server e quel client
    specifico. Il nostro server ora e' rimasto senza un interlocutore
    e rimarra' sospeso in un limbo. Netfilter, da solo, non puo' fare
    altro. Aggiungendo un pizzico di snort, e' possibile inserire una
    regola che faccia lo stesso match di string e resetti la sessione
    tcp anche lato server, chiudendo il processo e liberando risorse.

timeout
Be', per ssh il timeout non e' un problema:
Dec  9 21:52:48 puffin kernel: ssh-attack: IN=eth2 OUT=eth0
SRC=212.80.64.190 DST=10.0.0.44 LEN=72 TOS=0x00 PREC=0x00 TTL=45 ID=14436
DF PROTO=TCP SPT=50194 DPT=22 WINDOW=1460 RES=0x00 ACK PSH URGP=0
Dec  9 21:55:25 pantarkes sshd[11175]: fatal: Timeout before
authentication for 212.80.64.190
...sshd apparentemente si stanca dopo 150 secondi (e, si', mi sono accorto
che i due host non sono sincronizzati :-) ).
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

>Il match string deve essere limitato al solo traffico ESTABLISHED.
Ripensandoci (e rileggendomi le altre rules) il discorso e' piu'
complicato di cosi'.
Il primo pacchetto che accetto per il servizio ssh passa sempre,
o non passa mai, senza passare dal match.
Un pacchetto in stato NEW o ha un SYN o non ce l'ha... se non ce
l'ha, e' morto; se ce l'ha, passa direttamente all'incasso, "se"
e' per un servizio che offro (se non lo e', inutile firewallarlo
in primo luogo: i worm noti vengono ignorati, e il resto loggato
considerandolo portscan, o un possibile errore di configurazione
del FW).
Se non ce l'ha - e' un bel busillis. Se lo accetto, mi trovo nel
caso che menzionavi: mi inviano un pacchetto spoofato che sembra
venire da un host nobile, non ha un SYN sicche' non va in corsia
preferenziale, viene esaminato dal match e contiene poppo', ergo
l'host viene flaggato 'lame' e tenuto a distanza per un'ora. DoS
simplex.
In realta' i pacchetti NEW privi di SYN vengono droppati perche'
ritenuti errori di altri host o strani scan, ma questa soluzione
ha i suoi bei problemi.
Diciamo che mi collego al firewall, da fuori; mando un SYN, e lo
vedo passare. SYN-ETC e La connessione si stabilisce. Quindici o
venti pacchetti dopo gli mando "firewall restart". Magari, viene
scaricato proprio il LKM critico. Poi viene ricaricato e magari,
volendomi sloggare, invio "logout". Una rule smarrita repente si
desta: quel pacchetto che ho mandato e' NEW perche' i dati della
sua sessione crepòrno col restart. Non ha un SYN, perche' il mio
SSH non lo sa (e se lo sapesse, potrebbe farci poco). Cala ratta
la mannaia, e io devo aprire un'altra sessione per rientrare.
Il che e' quello che faccio, o meglio il firewall lo restarto da
sloggato via crontab, quando devo cambiargli delle regole; tanto
gli esperimenti li ho gia' fatti a suo tempo e oggi le modifiche
sono tollerabilmente rare. Comunque rimane scomodo.
Bisognerebbe che venisse fatto un restart in due mandate, in una
vengono aggiunte regole temporanee per tenere aperte le sessioni
aperte finche' la state machine non si risincronizza; nell'altra
le regole vengono tolte. Nell'intervallo la macchina e' comunque
vulnerabile (be', non necessariamente) a DoS spoofati diretti al
modulo di matching.


 sono accorto che i due host non sono sincronizzati :-) ).
Probabilmente e' stata messa mano a LoginGraceTime, alzandolo a
150s dai 120s per default. Debian, addirittura, lo mette a 600.
Boh, mi chiedo a cosa servano valori simili se non a creare dei
problemi.
Fabo

 ha i suoi bei problemi.
Si', in generale (IMHO) porta piu' problemi di quanti ne risolva.
 
Fabio




Magari, se uno scrive moooolto piano... :-)
Leonardo (600?!?)


Si', in generale (IMHO) porta piu' problemi di quanti ne risolva.
Ma io spero sempre di trovare il santo Graal che accontenta tutti :-)
