Newsgroup: it.comp.os.linux.sys
Titolo: iptables e traffico droppato

Ciao a tutti,
sto tirando su un firewall iptables sul mio serverino d'ufficio, su
quale gira, tra le altre cose, samba.
Ho lasciato attivo il log dei pacchetti droppati durante il weekend per
vedere cosa succedeva, e mi ritrovo stamani con un log che scoppia di
richieste sulle porte 137 e 138 con protocollo UDP, provenienti un pň
dappertutto.
Ho dato un'occhiata ai vecchi post, e pare sia abbastanza normale:
confermate o devo provvedere a qualche riparo?
Inoltre, c'č un'altra cosa che non capisco: mi trovo dei record di log
come il seguente:
May 10 09:13:34 pippo kernel: DROPPED_INPUT: IN=eth0 OUT=
SRC=xxx.xxx.xxx.77 DST=xxx.xxx.xxx.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128
ID=944 PROTO=UDP SPT=137 DPT=137 LEN=58
Gli indirizzi SRC e DST fanno parte della rete aziendale (il 255 č il
broadcast, no?). Che sti' pacchetti siano stati droppati mi č chiaro, in
base alle regole che ho scritto, ma non capisco perchč sono arrivati al
mio server (forse non ho ancora capito il concetto di broadcast).
Potete aiutarmi a capire per favore?
Vi ringrazio
Saluti
Roberto
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Potete aiutarmi a capire per favore?
Più che da icols è da reti.locali..
Il traffico broadcast è destinato a tutte le macchine della subnet, ergo,
anche alla tua samba...

 anche alla tua samba...
Ok, ma mi sarebbe chiaro se il broadcast fosse il sorgente del
pacchetto,
ma nel mio caso è il destinatario. E' per questo che non capisco.
Ciao


 ma nel mio caso è il destinatario. E' per questo che non capisco.
Forse dico una caXXata, ma...
Quando mandi un pacchetto in broadcast (cioè a tutta la subnet) lo mandi
proprio all'indirizzo di broadcast.
-- 
CyberPax
http://www.cyberpax.tk

 ma nel mio caso č il destinatario. E' per questo che non capisco.
Direi piuttosto l'esatto contrario: un ip sorgente non puň mai essere un
ip di broadcast (salvo configurazioni sballate, ovvio...)
L'indirizzo di destinazione č quello di broadcast, quindi:
- viene incapsulato in un frame ethernet con indirizzo HW di destinazione
broadcast a sua volta. Ciň fa sě che venga recepito da tutte le schede
ethernet che lo vedono passare e da queste passato ai rispettivi driver, i
quali ci troveranno gli estremi per passarli a loro volta allo stack
TCP/IP (perchč, sempre, la destination layer 2 č un broadcast)
- lo stack della macchina analizza la destinazione di layer 3 (ovvero
l'ip) e quindi accetta il pacchetto per passarlo all'applicazione che ha
bindato la porta cui questo era diretto.
Netfilter va a piazzarsi tra il primo ed il secondo, per intenderci...
Quindi, č normale che lo vedi lě... per te č un pacchetto in ingresso
sulla interfaccia di rete.
Il fatto che non sia diretto al tuo specifico ip non ha rilevanza...

 Il fatto che non sia diretto al tuo specifico ip non ha rilevanza...
Ah, ok. Era proprio questo che mi mandava in confusione, tanto che
pensavo
di aver commesso qualche casino sulla rete e che il mio server stesse 
"intercettando" traffico d'altri  :-)
Quindi, forse non è del tutto corretto droppare così tali pacchetti?
penso che dovrei fare almeno un controllo sulla porta cui sono diretti,
no?
Il fatto poi che siano tutti destinati alle porte 137 e 138 può
significare
qualcosa?
Grazie


 wrote in message
news:pan.2004.05.10....@netscape.net

Credo di sì, ma il fatto è che io sono un passo indietro e ancora non mi
è chiaro "perché" si inviano i pacchetti al broadcast (in particolare, 
sulle porte 137 e 138).
Saluti e grazie


 qualcosa?
Si, probabilmente che ci sono macchine Uindous nella rete che mandano
schifezze NetBios in broadcast, la normalita' quindi..
-- 
| Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).      |
| CSLUG: http:/
cslug.linux.it
                           |
|        email: 
in...@cslug.linux.it
                     |
|        IRC: 
irc.freenode.net
 #cslug, #linux-cazzeggio |

quello è inidicativo del fatto che qualcuno stava facendo
semplicemente uno "sfoglia rete" ... in quel caso , a meno che non sia
installato un wins e configurato il client , non manda pacchetti di
broadcast sulla 137 e 139 .

 semplicemente uno "sfoglia rete" ... in quel caso ,
Uhm...non credo sia solo questo perché il log di sabato e domenica
è letteralmente pieno di questi pacchetti (10 MB di log per pacchetti
come quelli che ho descritto).
Saluti


 
La porta 137/UDP e' usata per la risoluzioe dei nomi del netbios. Quando
una macchina win* non ha risoluzione wins, manda un pacchetto a tutti
sulla subnet (un broadcast ethernet, con ip destinaz. tua.subnet.255)
chiedendo chi ha il nome XYZ. La macchina che ha quel nome risponde cun un
pacchetto che ovviamente contiene in sorgente il proprio indirizzo, e
quindi l'ambaradam funziona. Se blocchi il traffico su queste due porte,
la macchina linux avra' problemi a rispondere alle richieste di
risoluzione del proprio nome.
Quanto al grosso traffico, controlla se nella rete hai macchine infettate
dal virus Gaobot/Agobo/Phatbot, che in questi giorni sta facendo dannare i
miei colleghi della rete uffici (io rido sotto i baffi, ho tutto linux).
Ho messo una macchina trappola (un portatile con linux e samba con una
condivisione accessibile in scrittura, e cosi' posso segnalare ai colleghi
con che nome si replica il virus e da quali macchine arriva l'infezione.
-- 
Mario "Reliant" Pascucci
Linux Registered user #327002 
http://counter.li.org/
http://ilpettegolo.altervista.org/