Newsgroup: it.comp.sicurezza.varie
Titolo: conseal

Salve sapete interpretarmi questa linea?
2002/03/27 15.24.08 GMT +0100: Dispositivo di Ac..[0000][No matching rule]
Blocking incoming TCP: src=195.130.225.152, dst=62.211.44.149, sport=110,
dport=31663.
la porta 31663 a che è adibita?
l'ip 195.130.225.15 corrisponde a 
mail-6.tiscalinet.it
, ma nn capisco che
succede.
Caso strano non riesco a controllare la posta su tiscali da Outlook
Express...
Illuminatemi...
Grazie
--
----------------------------------------------------------------------
"Un Anello per domarli, Un Anello per trovarli,
 Un Anello per ghermirli e ne buio incatenarli."
----------------------------------------------------------------------

 evidenetemente, blocca pacchetti di ritorno da 
mail-6.tiscalinet.it
Non penso che sia per un problema di stateful inspection (che in
effetti conseal non ha) ma che lui abbia chiuso il socket mentre
c'erano ancora pacchetti in rete destinati alla sua interfaccia.
Quando sono arrivati non esisteva piu' nessun socket a riceverli
e il firewall li ha segati.
Fabio

la porta 31663 a che è adibita?
I casi sono due: o e' una porta effimera mooolto alta (pol'essere), o
hai "condivisione internet" abilitata, Conseal e' sul "server", tu ti
vai a connettere a Tiscali da un altro client, eccetera.
In tutti i casi, lo scambio con Tiscali avviene cosi':
	Tu:31663 ----> TCP (SYN) ----> Tiscali:110
	Tu:31663 <---- TCP (SYN+ACK)-- Tiscali:110
e siccome Conseal non ha una regola che gli dica
	rhost = tiscali
	sport = 110
	action= ACCEPT
ecco che applica "No Matching Rule" (v.), ovvero, droppa il pkt.
E Outlook resta a bocca asciutta.
Il che, a ben pensarci, forse e' un bene.
Leonardo
-- 
"Open Source programs are designed and developed.
 Our products are tested."
 Steve Lipner, manager, Microsoft Security Response Center

 Del resto, e' lui che ha detto che non riesce a scaricare la posta.
Ho letto di fretta e mi sono perso quel pezzo di post. Eh si: sembra
che abbia fatto un qualche cosa del tipo deny-all senza poi inserire
le regole per accettare il traffico in ingresso. Apologizzo.
Fabio

 mille motivi per cui un pacchetto potrebbe arrivare in ritardo.
Ad esempio, se il FIN+ACK di risposta arriva dopo lo scadere del timeout, 
in risposta al primo (Ovvero: parte fin+ack, timout, parte il 2. fin+ack, 
arriva il fin+ack in risposta al primo...)
E che dire del fin+psh che talvolta spediscono certi server, e che il mio 
firewall intercettava come port scan (credo un xmas-tree)?
-- 
HappyCactus - Registered Linux User #209744
http://utenti.tripod.it/happycactus
Made with 100% recycled electrons

 firewall intercettava come port scan (credo un xmas-tree)?
Non me ne parlare:\ Ormai e' una delle entry piu' frequenti dei miei log.
Quasi tutti da cluster di server web di advertising ma anche tanti server
di posta. Certo che se gli mandassi un rst invece di stare zitto... :)
Ma che diavolo di firewall e' che ti prendeva come Xmas-tree il PUSH+URG?
Fabio

 ha scritto nel messaggio >


Devo inserire o modificare qualche regola?
Queste: accettare tutto il traffico sulle porte 25 e 110 dei servers
di posta di Tiscali.
Leonardo

 Ma che diavolo di firewall e' che ti prendeva come Xmas-tree il PUSH+URG?
No, ack+push+fin, non push+urg. 
Poi non so se fosse proprio xmas tree, andavo a memoria ;)


 Appunto, io li ignoro e basta, senza loggarli. Mi son un po' rotto...
Mi annoto subito che sulla tua macchina posso fare impunemente un
FIN+ACK+PUSH scan (si, si... lo so che non funziona :))
Fabio

 FIN+ACK+PUSH scan (si, si... lo so che non funziona :))
Tanto e' quella di casa.... ;)
