Newsgroup: it.comp.sicurezza.varie
Titolo: Firewall, accessi da 127.0.0.1, verifica ipotesi

Sono tra quelli il cui firewall (Kerio) logga una moltitudine di tentativi
di accesso da 
127.0.0.1:80
 verso localhost:x (con x >1024 sempre diverso e
di quattro cifre).
Lo so che se n'è già parlato e ho letto con molta attenzione il msg di
qualche giorno fa sull'argomento (TUTORIAL Firewall,accessi, ecc. ecc.) di
Fabio Panigatti, che però mi lascia qualche punto oscuro. Soprattutto non è
chiaro se il ragionamento fatto dal Panigatti vale per computer infetti o
meno. Il mio non ha il blaster e ha tutte le patch installate, ma ricevo
continuamente i suddetti tentativi di "attacco".
In un thread (Port scannimg in locale?) su it.comp.sicurezza.windows
sull'argomento, grazie anche al contributo di barbun ho formulato un'ipotesi
sulla questione che vorrei sottoporre anche su questo gruppo, in particolare
all'attenzione di Fabio Panigatti, per avere un vostro parere.
1) il worm si trova in esecuzione su un host e tenta di risolvere
l'indirizzo 
windowsupdate.com
;
2) l'host contatta il DNS;
3) il DNS (previamente "istruito" dall'amministratore) gli risponde con l'IP
127.0.0.1
4) l'host quindi spedisce un pacchetto con flag SYN verso 127.0.0.1,
utilizzando come mittente un IP spoofato;
5) 127.0.0.1 (l'host stesso) risponde con flag RST, ma risponde all IP
spoofato;
6) all'IP spoofato (nello specifico sarebbe il mio) arriva il pacchetto il
cui header riporta come mittente 127.0.0.1, che però non è il vero
localhost, ma solo quello che il firewall legge com IP mittente. Tali
pacchetti sono quelli bloccati e loggati dal firewall.
Se il punto 6 regge (l'uso come mittente di 127.0.0.1) il tutto mi
sembrerebbe finalmente più chiaro.
Che ne pensate?

 pacchetti sono quelli bloccati e loggati dal firewall.
se ti consola dopo aver configurato iptables per loggare quella rumenta
oggi mi trovo tante hit di questo tipo:
in ingresso, da 127.0.0.1:x per 
127.0.0.1:80
, SYN
in "uscita", da 
127.0.0.1:80
 per 127.0.0.1:x, RST
e linux non e' certo infetto.
c'e' una cosa che mi sfugge pero': come fanno i pacchetti SYN ad arrivare
a me avendo come destinatario 127.0.0.1 ?
-- 
per leggere e postare su free.it.*:
http://infofreeit.altervista.org/polacco.zip

 in "uscita", da 
127.0.0.1:80
 per 127.0.0.1:x, RST
su che interfaccia? (posta il log)
-- 
HappyCactus - Linux User #209744 - 
 
www.google.com
 - 
groups.google.com

 a me avendo come destinatario 127.0.0.1 ?
Altroché se sfugge! E' proprio questa cosa che non riesco ancora a
spiegarmi.
Non che sia paranoicamente preoccupato per la sicurezza, ma mi piace capire
il perché delle cose, non ci posso fare niente :-)

 e linux non e' certo infetto.
Questo taglia una delle possibili spiegazioni a cui avevo pensato. 
Poiché, nel caso mio, i pacchetti sono cominciati ad arrivare dopo 
l'installazione di varie patch sul mio Win2k, avevo anche supposto 
(senza alcuna convinzione, peraltro) che una di queste patch si 
occupasse di fare una sorta di scanning delle porte locali per 
individuare eventuali problemi e porvi rimedio. Lo so che era un'ipotesi 
  più che fantasiosa, ma sono di quelle cose che ti vengono in mente 
mentre stai per addormentarti la sera ...beh non solo quelle ;-)

 su che interfaccia? (posta il log)
loopback (!)
Sep  3 21:37:51 here kernel: BLASTER - IN=lo OUT=
MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1
LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=16983 DF PROTO=TCP SPT=33745 DPT=80
WINDOW=32767 RES=0x00 SYN URGP=0
Sep  3 21:37:51 here kernel: BLASTER - IN= OUT=lo SRC=127.0.0.1
DST=127.0.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80
DPT=33745 WINDOW=0 RES=0x00 ACK RST URGP=0


 sembrerebbe finalmente piů chiaro.
E' cosi'.
Considera che se hai un personal firewall, il worm in esecuzione sul
tuo computer lascerebbe tracce nei log gia' al punto 2, quando tenta
di contattare il dns (anche se non e' vero per tutti i pf) mentre il
pacchetto in uscita potrebbe anche non lasciare nessuna traccia (con
kerio, soprattutto).
Sono andato a leggere il thread su ics.windows: kerio, nei suoi log,
chiama "localhost" l'ip dell'host su cui viene eseguito (no comment)
e, quindi, il nome che vedi come endpoint locale della comunicazione
non e' 127.0.0.1 risolto nel suo nome bensi' si riferisce all'ip del
tuo host al momento dell'arrivo del pacchetto [1]. Era questo che ti
confondeva le idee, forse.
Fabio
[1] penso che venga fatto per semplificare l'interpretazione dei log
    in caso di ip dinamico, ma potevano almeno usare un altro nome.

 WINDOW=32767 RES=0x00 SYN URGP=0
  ^^^^^^^^^^^^
Questo SYN sembra generato in locale usando la finestra TCP ed (almeno in
apparenza) le opzioni tcp di default di un kernel 2.4.20. Cosa sia non te
lo so mica dire, pero'. Non sarai tu che hai fatto un po' di prove e t'e'
scappato qualcosa di questo tipo? (anche se la porta src e' un po' alta).
O un processo locale che tenta di accedere ad un web server locale (senza
trovarlo) di cui non ti sei mai accorto finche' non hai scritto la regola
di netfilter che lo logga? In questo caso dovresti rivedere la regola, in
quanto potrebbe essere sbagliata [1]: posta, cosi' ci leviamo i dubbi. Mi
verrebbe da dirti che e' un innocuo processo locale, magari schedulato.
Aggiungerei anche i log delle opzioni tcp e dei numeri di sequenza: usano
poche risorse e forniscono utili indicazioni, a volte.
Fabio
[1] quel pacchetto non e' transitato per l'interfaccia esterna e proviene
    da una porta alta. Una regola BLASTER dovrebbe contenere una cosa del
    tipo (IMHO):
           ... -i <eth esterna> -p tcp -s 
127.0.0.0/8
 --sport 80 ...
    che non dovrebbe fare match sul pacchetto che hai postato. La mask da
    8 bit sugli indirizzi di loopback e' perche' pare che alcuni provider
    risolvano in 127.0.0.2, quindi, per tagliare la testa al toro...

 risolvano in 127.0.0.2, quindi, per tagliare la testa al toro...
interessante. modifico il source comprendendo 127.0.0.*


 DPT=33745 WINDOW=0 RES=0x00 ACK RST URGP=0
Scusa, ma questo traffico tramite loopback non ha nulla di strano... come
dice Fabio anche secondo me c'è qualche processo interno che fa queste
strane chiamate. I SYN ti arrivano semplicemente per il fatto che partono
dal tuo localhost, e gli RST perché non hai nulla in ascolto sulla porta
80. Inoltre, azzardo (nel senso che non so come hai impostato le regole di
iptables) che questi pacchetti passano perché consenti il traffico su
loopback...
Il traffico causato da Blaster arriva da interfacce di rete esterne, ti do
un piccolo assaggio da tcpdump (ovviamente, x.x.x.x è il mio ip, nascosto
per motivi di privacy e perché sennò mi andava a capo prima di finire la
riga...):
tcpdump: listening on ppp0
12:30:52.175737 127.0.0.1.www > x.x.x.x.1884: R 0:0(0) ack 565903361 win 0
12:30:58.546018 127.0.0.1.www > x.x.x.x.1884: R 0:0(0) ack 716963841 win 0
12:31:06.174179 127.0.0.1.www > x.x.x.x.1610: R 0:0(0) ack 482148353 win 0
12:31:25.545920 127.0.0.1.www > x.x.x.x.1370: R 0:0(0) ack 1131085825 win 0
12:31:37.331476 127.0.0.1.www > x.x.x.x.1312: R 0:0(0) ack 544800769 win 0
12:31:44.524613 127.0.0.1.www > x.x.x.x.1884: R 0:0(0) ack 1 win 0
12:31:45.850523 127.0.0.1.www > x.x.x.x.1465: R 0:0(0) ack 1179582465 win 0
Come vedi, a questo tipo di traffico si adatta molto bene la spiegazione di
Daneel, e anche il tutorial postato poco tempo fa da Fabio. Ciao!
Roberto
-- 
L'amore non ha età, il pisello sì.

 Il traffico causato da Blaster arriva da interfacce di rete esterne,
si, e' tutto ok infatti.


 19:40, 21:37. proprio poco fa una new entry alle 12:05.
D'altronde, come si evince dal MAC, quel pacchetto non puo' essere
passato dall'interfaccia esterna, eth o ppp che sia.
Potresti provare a droppare quel traffico, invece di resettarlo, e
usare un analizzatore di log in real-time (tipo logsurfer) per far
eseguire uno script di shell quando appare quella riga di log. Nel
tuo script ci saranno lsof, ps e fuser con gli opportuni parametri
per scrivere in un file la situazione della macchina. 
Fabio che mettiamoci anche un netstat, va.

> si, e' tutto ok infatti.
Ooops... come non detto :-)
Fabio

 interessante. modifico il source comprendendo 127.0.0.*
meglio 127.*.*.* (appunto: 
127.0.0.0/8
)


 confondeva le idee, forse.
Si, anche questo :)
Grazie per la tua risposta :)

 Cosa è il ttl?
Riguardo il protocollo IP, un contatore che viene impostato ad un certo
valore non specificato da chi crea il pacchetto da inviare, e che viene
decrementato ogni volta che attraversa una interfaccia di rete[1].
Quando raggiunge il valore zero, il pacchetto viene scartato,
eventualmente emettendo un pacchetto ICMP destinato al mittente
originario di tipo Time-To-Live-Exceeded.
In elettronica, una specifica relativa ai livelli di tensione
(Transistor/transistor logic) per logiche a 5V. v. anche CMOS.
In fotografia, acronimo di Through-The-Lens, ed indica la misurazione
dell'esposizione attraverso la lente principale dell'apparecchio
fotografico
[1] purche' non sia impostata in modalita' bridge
Tratto da: Enciclopedia Galattica Tascabile, MK-1


 fotografico
Sono un fotoamatore e questa è infatti la prima cosa a cui penso quando mi
si dice ttl ...  :)
Ciao

 meglio 127.*.*.* (appunto: 
127.0.0.0/8
)
avevo fatto pure di meglio loggando senza discriminazione tutto il
traffico in e out sulla 80


 passato dall'interfaccia esterna, eth o ppp che sia.
infatti erano richieste di banner fatte dal mio browser redirette dal file
hosts su localhost. mea culpa non averci pensato peccando di fantasia O:)


 quando mi si dice ttl ...  :)
io ciclo secondo le tre definizioni, generalmente con una maggior
frequenza per la seconda. Credo dipenda dal grado di stress.
