Newsgroup: it.comp.sicurezza.varie
Titolo: Attacco hacker con spoofed address (?)

Salve a tutti, spero di non essere OT.
Il mio firewall linux ha registrato in due differenti occasioni ha
registrato una scansione delle porte che mi sembra piuttosto strana: l'IP
della macchina remota è un indirizzo di rete privata del tipo 172.16.x.x che
non potrebbe essere usato nella rete pubblica.
Ecco un estratto del log file del firewall:
Jun  1 02:21:06 firewall kernel: from_pub: IN=eth0 OUT=
MAC=00:40:c7:95:6c:fa:00:01:c9:2e:f4:54:08:00 SRC=172.16.3.4 DST=<mio IP
pubblico> LEN=92 TOS=0x00 PREC=0x00 TTL=244 ID=4473 DF PROTO=TCP SPT=119
DPT=1363 WINDOW=8760 RES=0x00 ACK PSH URGP=0
... messaggio ripetuto 6 volte
Jun  1 02:25:37 firewall kernel: from_pub: IN=eth0 OUT=
MAC=00:40:c7:95:6c:fa:00:01:c9:2e:f4:54:08:00 SRC=172.16.3.4 DST=<mio IP
pubblico> LEN=92 TOS=0x00 PREC=0x00 TTL=244 ID=48232 DF PROTO=TCP SPT=119
DPT=1363 WINDOW=8760 RES=0x00 ACK PSH FIN URGP=0
e poi:
Jun 18 13:02:31 firewall kernel: from_pub: IN=eth0 OUT=
MAC=00:40:c7:95:6c:fa:00:01:c9:2e:f4:54:08:00 SRC=172.16.3.4 DST=<mio IP
pubblico> LEN=92 TOS=0x00 PREC=0x00 TTL=244 ID=61211 DF PROTO=TCP SPT=119
DPT=1057 WINDOW=8760 RES=0x00 ACK PSH URGP=0
... messaggio ripetuto 6 volte
Jun 18 13:07:00 firewall kernel: from_pub: IN=eth0 OUT=
MAC=00:40:c7:95:6c:fa:00:01:c9:2e:f4:54:08:00 SRC=172.16.3.4 DST=<mio IP
pubblico> LEN=92 TOS=0x00 PREC=0x00 TTL=244 ID=2641 DF PROTO=TCP SPT=119
DPT=1057 WINDOW=8760 RES=0x00 ACK PSH FIN URGP=0
Ho verificato il mio box linux e non ci sono processi riconducibili a trojan
e nemmeno porte o connessioni aperte, quindi credo che la macchina non sia
stata violata.
La mia rete interna non utilizza quella famiglia di indirizzi, ma la
famiglia 192.168.x.x, inoltre soltanto io ho accesso alle macchine e quindi
escludo categoricamente un attacco dall'interno.
Con tracepath riesco a fare il primo hop, ma al secondo mi blocca.
Ecco le mie supposizioni: il mio provider ha configurato male il nodo a cui
sono collegato, lasciando passare anche il traffico illecito che invece il
secondo nodo filtra in maniera corretta. Qualcuno che si collega  al mio
stesso nodo si è accorto del buco e gioca a fare l'hacker, facendo scansioni
di porte sui pc che riesce a raggiungere tramite il nodo non filtrato.
Il mio provider cade dalle nuvole e dice di verificare se ho installato il
programma Startron, che però x quanto ne so io è un gioco multiplayer in
rete per Winzozz. Pare che il provider stia cascando dalle nuvole....
Qualcuno di voi ha idea di cosa stia accadendo? Credete che le mie
supposizioni siano corrette? Altre idee?
Grazie a tutti per ogni suggerimento.
Wizard

 supposizioni siano corrette? Altre idee?
Tanto per dovere di cronaca: chi č il tuo provider?
No, perchč'sta storia delgioco multiplayer fa ridere: o ammette che lui non
filtra gli IP privati, oppure dice che li filtra e quindi cerca l'errore
nella *sua* configurazione: mica puoi avertelo inventato quel pacchetto
dall'esterno! E' arrivato, quindi lui ha sbagliato. Punto.
Ciao. Radel
--
PS. Per risposte in email togliere le due ".remove" dall'indirizzo
      To reply remove both ".remove" in the address.

di porte sui pc che riesce a raggiungere tramite il nodo non filtrato.
Difficile individuare l'origine dei pacchetti senza essere telepatici,
ma visto che sono innocui ignorerei la cosa.
-- 
ciao, | The Internet is full. Go away.  -- Joel Furr      | #156856496
Marco | (Ri)scoprire fidonet: 
http://bbs.bofh.it
          | 
m...@jabber.linux.it

 Qualcuno di voi ha idea di cosa stia accadendo
...
Credo molto semplicemente che tu stai puntando a un news-server free 
che ha qualche problema di NAT.
metti una regola sul firewall per loggarti i pacchetti destinati alla
porta 119 per vedere chi genera il traffico:
iptables -I to_pub -p tcp --dport 119 -j LOG
(ipotizzando che tu abbia una chain "to_pub")
ciao
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Altre idee?
1) non preoccuparsi minimamente della cosa.
2) diversi server inviano dei FIN in soporannumero al termine della
   connessione. Succede anche con i server web e i server di posta.
   A me succede spessissimo che arrivi traffico FIN per cui non c'e'
   uno stato da cluster di server di advertising. Penso che siano i
   sistemi di load balancing che creano questa situazione ma e' una
   ipotesi senza molti fondamenti.
3) quello indicato e' probabilmente uno degli indirizzi ip del news
   server che tu usi e, per qualche motivo, i FIN sono stati emessi
   con quell'ip. I motivi non li so, ma, essendo che non c'e' nulla
   di cui preoccuparsi...
4) il fatto che siano tanti e' perche' droppi il traffico invece di
   inviare un RST.
Fabio

    inviare un RST.
...ahemm... e' ovvio che e' irrilevante cosa fai tu con gli RST, visto
che comunque non arriverebbero mai a destinazione. Stavo solo pensando
al mio caso.
Fabio

    inviare un RST.
Comunque droppare č una buona norma di security per un firewall.
Altre idee?
Wizard

 ma visto che sono innocui ignorerei la cosa.
Come fai a essere sicuro che siano innocui?
Wizard


E' Cities on line, ma non credo che altri, Tin in testa, saprebbero dare
risposte più sensate, anzi!
Comunque in molti, anche in un NG inglese mi dicono che non c'è da
preoccuparsi e che spesso i router non filtrano corettamente, spero bene.
Ciao. Wizard

 porta 119 per vedere chi genera il traffico:
Proverò, grazie.
Wizard

 Altre idee?
Traccia con tcpdump, tethereal o quello che vuoi le connessioni sulla
119 e poi accedi un po' al server di news. Lascia li' il tutto per un
po' di giorni, visto che a quanto pare erano giorni che non accedevi.
Assicurati che il packet logger che userai sia configrato per loggare
i numeri di acknowlegment e di sequenza del traffico.
L'effetto che ti ho citato (traffico FIN proveniente da server di ad)
proveniva da ip vicini (ma diversi) da quelli del traffico per cui e'
esistito uno stato ed aveva ack e seq uguali a quelli dei FIN con cui
si era conclusa la sessione. Peccato che arrivassero senza uno stato,
visto che l'ip era diverso, e da un paio di minuti a circa 6 ore dopo
che il socket era stato chiuso. Non ho avuto spiegazioni, ne da parte
dei sysadmin, ne da parte dei ng su cui ho chiesto lumi. Il tuo caso,
forse, potrebbe essere simile.
Fabio
PS. non te la prendere per l'ironia con cui a volte scrivo. Se non si
    sdrammatizza un po'...
[1] a meno di non compromettere i router, ma e' un po' eccessivo ;)

    inviare un RST.
Sto pensando di convertire tutti i miei drop con dei reject, infatti.
-- 
don't feed the troll
partecipa anche tu all'iniziativa:
"il primo fanculo ? quello che conta"
killa in silenzio, vivi felice

Come fai a essere sicuro che siano innocui?
Visto che le risposte non possono tornare indietro è ovvio che fare un
port scan in questo modo (e comunque non credo che sia quello che ti è
successo) è inutile.


     sdrammatizza un po'...
Grazie x l'aiuto.
L'ironia, quando non č fuori luogo, č sintomo di intelligenza.
Wizard

 L'ironia, quando non č fuori luogo, č sintomo di intelligenza.
Beh, spero che in questo caso fosse... in luogo.
Fabio per lo piu' asintomatico