Newsgroup: it.comp.sicurezza.varie
Titolo: Email senza destinatario e generazione random delle porte... :-)

Salve.
Avrei due domande da porvi e a cui non so rispondere.
Non so se sono OT, so solo che qui c'è gente competente su questi temi e
a cui non credo dispiacerà parlare di reti. :-) Ecco a voi:
 1) Tempo fa mi iscrissi ad una mailing list con uno dei miei indirizzi
email. Ora ho dimenticato quell'indirizzo quale fosse. Vado nell'header
dell'email ma... non c'è traccia del mio indirizzo email! Possibile?
(be', direi di sì ;D) Come fare ad inviare una mail senza specificare
espressamente l'indirizzo email di destinazione (immagino che il mio
server pop sappia come rigirarmi la mail... ma come?).
 2) Ogni volta che ci si deve connettere ad un [host]:[porta], a livello
applicazione viene generato un numero "random" di porta maggiore di 1024
(le well-known). Giusto? E' vero che, ad ogni nuova connessione ad un
host, il sistema operativo "ricorda" le precedenti (quante? per quanto
tempo?) porte generate casualmente e non le usa? E' scritto da qualche
parte, in qualche RFC? Dove potrei cercare per avere altre informazioni
riguardo questo problema delle implementazioni degli stack tcp/ip dei
vari sistemi operativi?
Grazie infinite!
Alessandro K.

 casualmente e non le usa? 
credo che ricordi lo stato di CLOSE_WAIT e TIME_WAIT più che altro :)
Sentiamo cosa dice il Serni che su queste cose e su tante altre [1] è 
un maghetto :)
[1] /me ovviamente invidioso e rosicante :))
-- 
Ciao, Dmitry

 operativi?
qual e' il problema?
-- 
su questo post guariniello ha aperto un'inchiesta.

(le well-known). Giusto?
Non necessariamente. In genere viene generato un nuovo numero di porta in
un intervallo (tipo: da 1025 a 5000, da 1025 a 32767 o 65535), usando una
formula del tipo P(N+1)=F(P(N)).
Il caso banale e' P(N+1)=((P(N)+BASE-1)%WINDOW)+BASE, cioe' avanzi di uno
e se arrivi oltre BASE+WINDOW torni indietro a BASE.
Ci sono altri algoritmi per randomizzare il numero di porta, che usano un
PRNG (PseudoRandom Number Generator) in modo che il legame P(N)... P(N+1)
non sia immediatamente ovvio, e avendo P(N), P(N+1), ...P(N+K) sia sempre
difficile prevedere P(N+K+1) per K piu' grande possibile.
In tutti i casi e' possibile una collisione, ovvero, P(N+1) e' occupata e
non si puo' usare... in quel caso il sistema non fa altro che avanzare di
uno scatto, e usare P(N+2) invece che P(N+1).
Cerca "source port number generation" o "ephemeral port generation".
http://www.usenix.org/publications/library/proceedings/usenix99/full_papers/deraadt/deraadt_html/node18.html
(incidentalmente c'e' un sistema anche migliore di creare la "random dir"
anche usando un PID sequenziale, usando il Murphy Programming ;-) )
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.

  2) Ogni volta che ci si deve connettere ad un [host]:[porta], a livello
Il maestro ha già risposto. Non mi intrigo... :-)

 E' scritto da qualche parte, in qualche RFC? 
Un buon punto di partenza e' la 1122.
Fabio

 indirizzo di consegna (envelope sender) [...]
L'envelope e' "to", non "sender".
Fabio

 salvo accrocchi mostruosi che sovvertano il senso del layering originale...
Se non sono invadente .), che tipo di accrocchi?
Grazie!
Alessandro K.

 anche usando un PID sequenziale, usando il Murphy Programming ;-) )
Murphy Murphy, quello delle famose Laws oppure c'è qualcosa che dovrei
conoscere e che non mi hanno mai detto? :-)
Grazie!
Alessandro K.

 Se non sono invadente .), che tipo di accrocchi?
Certo, il problema è l'uso che se ne fa, il che vale anche per gli ICBM, 
a voler ben vedere...
Comunque, immagina una situazione tipo
A: mailserver di un ISP
B: mailserver di una utenza aziendale
Immaginiamo che A contenga delle mailbox per tutti gli utenti della 
azienda in questione. B avrà una un fetchmail con una configurazione per 
ognuno degli utenti.
L'utente Pippo manda una mail a 
gi...@azienda.it
, mettendo 
ca...@azienda.it
 in BCC.
Quello che accade è che su A ci saranno in un certo due mailbox che 
contengono la mail. Poi passa fetchmail che fa il retrieve e le elimina 
da A; a questo punto ci sono due mailbox su B che contengono la mail.
Tutto è come avrebbe dovuto essere, la Contea vive in pace e Bilbo 
finalmente si è levato dalle balle.
Ora immagina che A non abbia una mailbox per utente, ma una unica 
mailbox in multidrop in cui finisce tutta la posta di @
azienda.it
.
Pippo, che ha voglia di rompere le balle (deve avere sangue hobbit nelle 
vene) rimanda la sua maledetta mail, che arriva su A.
Poichè ci sono due destinatari che in realtà corrispondono ad un unico 
utente (la mailbox), la mail viene scritta nella mailbox una volta sola.
Poi passa fetchmail. Questi guarda dentro la mailbox e vede una mail con 
mittente Pippo e destinatario gigi. Quindi la prende e la mette nella 
mailbox di gigi. E il capo?!?
Poichè la mail era diretta a lui solo in BCC, non vi è nulla nel campo 
To: che dicesse a fetchmail di metterla anche nella mailbox sua. 
Viceversa, gli envelope recipient non esistono più, perchè durante la 
fase di local delivery gli vengon levati.
Il capo si incazza, fetchmail fa spallucce e Aragorn, che dopo la morte 
di Sauron si è dato all'amministrazione di sistema, perde il lavoro.
Tanto per cambiare, per colpa di uno stracazzo di hobbit...
Ah, e non solo Bilbo è ancora tra le balle, ma adesso ha anche un nipote...
Per far sì che fetchmail sia in grado di operare, A deve indicare in 
qualche modo nel contenuto della mail chi erano i destinatari originali, 
almeno ogni qual volta capiti che la mail sia diretta "due volte" nella 
stessa mailbox.
Il problema è che l'esperienza (fin da quanto ci tramanda Ainulindale 
[1]) ci mostra come uscire dalla via ben scritta e tracciata dagli 
antenati è cosa malvagia; e che quando la persona sbagliata si mette in 
testa di farlo il mondo va verso la distruzione, i mari iniziano a 
ribollire e Numenor sprofonda negli abissi.
E questo è ciò che accade con i POP3 retriever e il BCC. Hanno la 
sgradevole tendenza a non funzionare...
Tutto per un cazzo di hobbit.
Saluti a tutti tranne a quelli coi piedi pelosi.
[1] Chi ha capito al volo questa senza usare Google ha bisogno di una 
cura disintossicante.
-- 
cat: .signature: No such file or directory