Citazione di: mattia.pascal
@ Sparc
Grazie per i complimenti al forum, fatti da una persona che non parla per sentito dire ed chiaramente informata sull'argomento e sicuramente non "alle prime armi" (in senso generico)... fanno ancora più piacere  
Ho modificato il tuo quote... per una questione di leggibilità... e anche perchè vorrei evitare che si scatenasse una gara a chi ha la lista più lunga  

Hai fatto benissimo, sapevo che non era esattamente una procedura corretta quotare includendo quel "listone" ma non ho saputo trattenermi... Salvo che per chiedere sommariamente scusa

Ho postato poi per avvertire che bluetack necessita donazioni per mantenere quella mostruosa banda cui anche noi utenti di PG2 attingiamo. Ad ogni cambiamento della struttura dei tipi di Bluetack segue di necessita' una nuova release di PG, visto che la Level 1 aggiornata dovra' pur andarla a cercare per fare l'update e che senza un update frequente l'ip filtering diviene strumento poco affidabile (ma immagino che tutti abbiate letto l'ottima guida).

Da alcuni giorni sono fuori linea la normal e la paranoid list, quindi se le usate e non riuscite ad aggiornarle non preoccupatevi: non sono proprio fisicamente presenti sul server. A voi la scelta, io, come ha intuito l'ottimo mattia.pascal, ho gia' qualche striatura bianca nella barba e 40$ di donazione posso farli senza problemi, se lo ritenete opportuno donate in funzione delle vostre possibilita', il minimo (suppongo per il passaggio via PayPal) e' 2$, con il supereuro praticamente un caffe'...  

Saluti

Sparc

Si, Bluetack ha dei problemi che sembrerebbero essere seri.
Per il momento in rete se parla pochissimo, probabilmente perchè finora le uniche liste ad essere off-line sono la normal e la paranoid.

Avevo riportato il comunicato nella discussione sull'IP-Filter interno a eMule (visto che per ora i problemi sono riferiti solo a quelle liste)
http://www.emuleitalia.eu/index.php?...st&p=191985

Le altre liste, Level 1/2 ecc.. attualmente sono disponibili ed aggiornate.

Una piccola nota: e' mia impressione che PG sia piu' efficiente dell'ipfilter interno di eMule.
Vi faccio un esempio, scusate per le tre righe di "verbose" ma e' l'unico modo per vedere certi eventi.

Questo viene correttamente filtrato
Ignored source (IP=83.233.181.92) received via source exchange - IP filter ([L2]Relakks security ser)

Questo NO, e la forma della richiesta mi lascia perplesso...
SXSend (Version 2): Client source request; 5553321@38.107.164.18 (XXX.XXX.XXX.XXX) 'nick_oscurato' (eMule v0.48a,Connected/Uploading/None), File="XXX"
SXRecv: Client source response; SX2=Yes, Ver=4, 5553321@38.107.164.18 (XXX.XXX.XXX.XXX) 'nick_oscurato' (eMule v0.48a,Connected/Uploading/None), File="XXX"

Allora: se non ho eMule attivo o se e' spento da un po', nei log di PG mi scompaiono praticamente del tutto gli spioni.
Viceversa, raggiunto un certo numero di fonti il log di PG si riempie di schifezze.
Verrebbe da pensare che il problema sia il source exchange, cosi' a naso.

Quell'indirizzo "XXX.XXX.XXX.XXX" corrisponde, controllato sul RIPE, ad un IP di un range di TRE indirizzi pubblici gestiti da FW per una ditta genovese che realizza risorse web, siti assortiti, biglietti da visita su CD e robetta simile.
Troppo piccoli per non essere un intermediario innocente. Pero' e' seccante.

La mia ipotesi e': il source exchange viene usato per aggirare l'ip filtering interno di eMule, ma PG blocca poi la connessione.
Plausibile?

Sinceramente non mi sento di poter escludere un "raggiro" dell'IP-Filter.
Teoricamente un Ip-Filter non fa altro che bloccare qualsiasi forma di contatto con gli IP nella lista, indipendentemente da come la fonte sia stata contattata ed è un fatto che di solito la maggior parte delle fonti vengono contattate via Scambio Fonte.

Nel log che hai postato c'è l'invio di una richiesta di fonti per un file e la ricezione della richiesta, quindi contatti con l'IP XXX.XXX.XXX.XXX ci sono stati, viceversa a seconda del tipo di contatto per quell'IP sarebbe dovuto apparire un messaggio del tipo Ignored source from server o Ignored kad contact o Ignored source via source exchange.

Quello che non ho capito, ma forse era scontato, l'IP era inserito tra quelli della lista caricata in eMule?
E come fai ad essere sicuro che la richiesta sia avvenuta via Scambio Fonte?
Ultima domanda    .. che versione di eMule usi?

Citazione di: mattia.pascal
Sinceramente non mi sento di poter escludere un "raggiro" dell'IP-Filter.
Teoricamente un Ip-Filter non fa altro che bloccare qualsiasi forma di contatto con gli IP nella lista, indipendentemente da come la fonte sia stata contattata ed è un fatto che di solito la maggior parte delle fonti vengono contattate via Scambio Fonte.

Nel log che hai postato c'è l'invio di una richiesta di fonti per un file e la ricezione della richiesta, quindi contatti con l'IP XXX.XXX.XXX.XXX ci sono stati, viceversa a seconda del tipo di contatto per quell'IP sarebbe dovuto apparire un messaggio del tipo Ignored source from server o Ignored kad contact o Ignored source via source exchange.

Quello che non ho capito, ma forse era scontato, l'IP era inserito tra quelli della lista caricata in eMule?
E come fai ad essere sicuro che la richiesta sia avvenuta via Scambio Fonte?
Ultima domanda    .. che versione di eMule usi?

Scusami, in effetti era un testo adatto ad un p.m. veloce e non all'acuta disamina di m.p.!  

Allora: no, l'IP mascherato NON e' in alcuna blacklist esistente al mondo, fatta forse eccezione per qualche cliente scontento di questa ditta    ; compare tuttavia un IP del range 38.107.160.0-38.107.167.255, ben presente nell'ipfilter list di eMule.
Ha qualche significato?
Uso la versione 48a.
Che la richiesta, non la prima filtrata, ovviamente, sia avvenuta per source exchange... No, non sono sicuro, anche perche' se non erro la versione (1 o 2) dovrebbe comparire esplicitamente dopo il nome del file nella stringa appesa al log (c'e' un classico operatore condizionale ternario "?" in DownloadClient). Ma ammetto di non aver mai guardato per bene i sorgenti, forse sarebbe ora (ad averne il tempo, anche... Bronchite resisti!)

Brancolo nel buio, attendo lumi...  

conviene caricare la lista spider delle bluetack, poichè mi blocca google?

@ Vortagor

Per navigare senza che PeerGuardian blocchi alcune pagine ti conviene disabilitare il blocco HTTP
guarda qui ---> Configurazione di base http://www.emuleitalia.eu/index.php?...st&p=170080
per maggiori informazioni  

Citazione di: Sparc

Brancolo nel buio, attendo lumi...  

Beh... non credo di essere in grado di "fornire lumi" , approfittiamo solo della possibilità di poter dialogare in un Forum per scambiarci le nostre reciproche conoscenze.  

Comunque se ho ben capito a farti "rizzare le antenne" è stato l'IP del range 38.107.160.0-38.107.167.255 presente nel Verboso.
Ricapitolando, anche con IP-Filter attivo sei venuto in contatto con un utente che ha fatto a te una richiesta di fonti ma non ha iniziato alcuna sessione di download/upload:

5553321@38.107.164.18 (XXX.XXX.XXX.XXX) 'nick_oscurato' (eMule v0.48a,Connected/Uploading/None)

Questo utente ha ID 5553321, è connesso al Server Razorback  38.107.164.18:4661, IP (facilmente ricostruibile dall'ID   )  (XXX.XXX.XXX.XXX) e 'nick_oscurato' .
Quindi in pratica sei venuto a contatto con uno dei tanti client che sono connessi a Server spia (esistono diversi Razorback che sono spy e messi su da M.D.)
http://ed2k.2x4u.de/list.html
http://peerates.net/peerates/ametfiles/pee...kedservers.html

visto che usi un IP -Filter tu non sei sicuramente connesso con questo Server e il contatto è avvenuto via Kad o (penso più probabilmente) via Scambio Fonte.. in pratica è quel client a correre dei rischi connettendosi a un Server spy.

Riguardo al possibile "raggiro" .... è sicuro che M.D. oltre che semplici Server abbia a disposizione diversi client spy (la maggior parte con IP sconosciuti in quanto si confondono troppo facilmente con gli utenti normali) ma mi sembrerebbe strano che questi client si connettano ai loro server spia.... da cui già possono trovare informazioni sugli utenti connessi  

Citazione di: Sparc
Scusami, in effetti era un testo adatto ad un p.m. veloce e non all'acuta disamina di m.p.!  

Questa l'ho capita "dopo" ma l'ho capita    

Citazione di: mattia.pascal
visto che usi un IP -Filter tu non sei sicuramente connesso con questo Server e il contatto è avvenuto via Kad o (penso più probabilmente) via Scambio Fonte.. in pratica è quel client a correre dei rischi connettendosi a un Server spy.

Riguardo al possibile "raggiro" .... è sicuro che M.D. oltre che semplici Server abbia a disposizione diversi client spy (la maggior parte con IP sconosciuti in quanto si confondono troppo facilmente con gli utenti normali) ma mi sembrerebbe strano che questi client si connettano ai loro server spia.... da cui già possono trovare informazioni sugli utenti connessi  
Questa l'ho capita "dopo" ma l'ho capita    

Grazie, come sempre sei stato estremamente chiaro ed hai spiegato tutto in modo semplice ma non banale.
Lieto che la "battutaccia" ti sia piaciuta  

Quindi: si riconferma che la sicurezza assoluta in rete non esiste, o meglio, esisteva ai bei tempi del mio primo account universitario perche'... Beh, era il 1992 circa ed internet non se la filava nessuno.
Oggi, come in effetti afferma il piu' volte citato studio sull'efficacia delle blacklist, se non hai protezione alcuna hai la certezza (probabilita' 1) di essere tracciato, viceversa... Anche con ogni sistema di filtraggio possibile non hai la sicurezza di non essere "raccolto", semplicemente la probabilita' che cio' avvenga si riduce in modo decisamente drastico, ai limiti della sigificativita', ma non diviene nulla!

Ora la mia domanda: se la richiesta e' passata attraverso un client connesso (a sua insaputa, suppongo) ad un server spia di Media Defender, e' possibile che ricevendo in ogni caso una risposta da me, anche senza che io sia in contatto col server spia, il client "ingannato" fornisca informazioni MIE (ad esempio l'IP) al server? In questo senso accennavo al source exchange come fonte di raggiri dell'ipfilter, supponendo la buona fede del client coinvolto (che voleva poi un whitepaper - invero enorme, per colmo dell'ironia).

Sul fatto che abbia censurato l'IP della ditta genovese e non il suo ID, beh, ammetto di non averci pensato: la funzione e' banalissima e bijettiva, quindi avrei dovuto censurare anche quello... Grazie per avermelo fatto notare  

Una cosa che ti divertira': questi contatti sono avvenuti solo in orario di ufficio! Per una ditta che offre servizi legati al web ed alla promozione, strano che non abbiano bloccato il P2P ai dipendenti... L'immagine, suvvia!!!  
(Quanto sopra e' ironico, e' evidente che usato su materiale non protetto da Copyright il P2P e' anzi un potentissimo metodo di reperimento e divulgazione delle informazioni, tanto che quando i database di letteratura scientifica liberamente accessibile sono stracarichi si ottiene quel che si vuole molto spesso piu' comodamente direttamente con eMule che non attendendo che i server interessati si "risveglino"...)

Mi sono accorto di essere stato poco chiaro.
Riconsideriamo lo scambio preso dal verbose:

SXSend (Version 2): Client source request; 5553321@38.107.164.18 (XXX.XXX.XXX.XXX) 'nick_oscurato' (eMule v0.48a,Connected/Uploading/None), File="XXX"
SXRecv: Client source response; SX2=Yes, Ver=4, 5553321@38.107.164.18 (XXX.XXX.XXX.XXX) 'nick_oscurato' (eMule v0.48a,Connected/Uploading/None), File="XXX"

Un client connesso ad un server spia mi ha chiesto se ho il file "XXX".
Il mio client gli ha risposto: "Yes".

Fino a questo punto ho compreso bene?

Adesso, il client connesso al server spia possiede queste informazioni:
i) il mio IP
ii) il fatto che io possieda il file "XXX"

DOMANDA FONDAMENTALE:
queste informazioni vengono comunicate dal client connesso al server spia al server spia stesso?

Perche' in tal caso l'ipfilter di eMule si rileva inadeguato a gestire la "fuga di informazioni" verso i server spia quando queste avvengano attraverso un client raggiunto con il source exchange.
Per essere un blocco realmente efficace, non dico efficiente me proprio efficace, dovrebbe bloccare anche ogni connessione proveniente da un server blacklistato, e non solo le connessioni dirette da ip blacklistati.

Sarebbe un blocco "pesante", lo ammetto: basterebbe lasciare la decisione all'utente ("vuoi filtrare anche i client connessi ad un server blacklistato?").

Spero di aver scritto una montagna di idiozie, ma se cosi' non fosse... Non sarebbe il source exchange capace di aggirare l'ipfilter di eMule? E' vero che KAD e' piu' sicura perche' serverless, ma se esiste un modo attraverso il quale server fake acquisiscono i miei dati come se mi ci collegassi...  

Peggio ancora, in questo caso sarebbe il client "XXX.XXX.XXX.XXX", che non e' certo blacklistato, a comunicare le informazioni al server di Media Defender, vanificando quindi in definitiva anche l'operato di PeerGuardian, non solo quello dell'ipfilter interno di eMule! Ditemi dove sbaglio perche' stento a crederci...

[!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]Peggio ancora, in questo caso sarebbe il client "XXX.XXX.XXX.XXX", che non e' certo blacklistato, a comunicare le informazioni al server di Media Defender, vanificando quindi in definitiva anche l'operato di PeerGuardian, non solo quello dell'ipfilter interno di eMule! Ditemi dove sbaglio perche' stento a crederci...
[/quote]

ma se mi dici che la cosa funziona cosi?????ma allora ce l'abbiamo propio........

ma mi stai dicendo che pg2 e diventato inefficace contro questa minaccia se cosi la vogliamo chiamare come possiamo difenderci????

Citazione di: Sparc
DOMANDA FONDAMENTALE:
queste informazioni vengono comunicate dal client connesso al server spia al server spia stesso?

per quanto ne so io, un client non comunica al server al quale è connesso la lista dei client dai quali sta effettuando un DW...

sarebbe un'informazione inutile al server (a meno che il server, essendo spy, non abbia qualche strumento particolare che abbia proprio lo scopo di ottenere tale informazione...)

correggettemi se sbaglio...

Citazione di: Koje
per quanto ne so io, un client non comunica al server al quale è connesso la lista dei client dai quali sta effettuando un DW...

sarebbe un'informazione inutile al server (a meno che il server, essendo spy, non abbia qualche strumento particolare che abbia proprio lo scopo di ottenere tale informazione...)

correggettemi se sbaglio...

tenicamente quello che hai detto mi sembra giusto.....ma nn si sa mai.....

servirebbe un aiuto dal povero mattia che ci sopporta

Citazione di: Malcolm
ma se mi dici che la cosa funziona cosi?????ma allora ce l'abbiamo propio........

ma mi stai dicendo che pg2 e diventato inefficace contro questa minaccia se cosi la vogliamo chiamare come possiamo difenderci????

Citazione di: Koje
per quanto ne so io, un client non comunica al server al quale è connesso la lista dei client dai quali sta effettuando un DW...

sarebbe un'informazione inutile al server (a meno che il server, essendo spy, non abbia qualche strumento particolare che abbia proprio lo scopo di ottenere tale informazione...)

correggettemi se sbaglio...

Citazione di: Malcolm
tenicamente quello che hai detto mi sembra giusto.....ma nn si sa mai.....

servirebbe un aiuto dal povero mattia che ci sopporta

Ehm, non era mia intenzione generare panico, solo mi e' venuto un dubbio e... Sapete come sia facile abituarsi a ricevere le risposte dal "Nume Tutelare", no?  

Citazione di: Koje
per quanto ne so io, un client non comunica al server al quale è connesso la lista dei client dai quali sta effettuando un DW...

sarebbe un'informazione inutile al server (a meno che il server, essendo spy, non abbia qualche strumento particolare che abbia proprio lo scopo di ottenere tale informazione...)

correggettemi se sbaglio...

Una curiosita': ma adesso si usa dw al posto di DL o D/L oppure e' qualcosa di diverso? Intendi download, no? Se e' cosi' mi son perso l'ennesimo effetto diacronico del lessico della rete, altrimenti mi son perso qualche informazione tecnica. Brutto segno in entrambi i casi.

Direi che e' dai tempi del primo ed2k che sui server viene mantenuta la corrispondenza (ID,PORT)-Hash di file, in modo da fornire tali associazioni in risposta ad una query di un client (tralasciamo lo scambio di informazioni server-server che segue una query).
Questo lo possiamo considerare ancora valido: l'analogia con l'elenco telefonico e' un classico.
Ora pero' mi chiedo cosa accade quando un client connesso ad un server acquisisce fonti con il source exchange. Se le tiene per se oppure le comunica al server? Il server ha le corrispondenze (ID,PORT)-Hash di TUTTI E SOLI i client DIRETTAMENTE ad esso connessi o, a parte la comunicazione con altri server, ne acquisisce dai client quando questi ne trovano di "nuove"?
In effetti il source exchange dovrebbe riguardare solo i client, anzi, dovrebbe proprio servire a migliorare l'efficienza di una query (fornendo source a cascata) e contemporaneamente ALLEGGERENDO il carico sui server, che quindi non dovrebbero subire alcun messaggio di ritorno dal client.
Quindi il server non dovrebbe venire a conoscenza di informazioni dai client salvo quelle che gia' possiede perche' ottenuti via connessione diretta (al momento dell'"hello" mi sembra che un client comunichi al server tutto quanto ha in condivisione).
Anche perche' se cosi' non fosse, non vi sarebbe bisogno di mod "spia" che loggano tutto su un DB...
Pronipoti del software Techland, ad esempio, che nelle fasi prototipali si vocifera (attendibilita' minima) fosse una versione modificata di shareaza connessa... Ad un DB di Access!!!  

Diciamo che il mio e' il classico dubbio da paranoia spinta ed irritazione da Media Defender nei log, e che un chiarimento mi rassicurerebbe molto. Ma e' un dubbio mio, di cui ho esplorato le peggiori ipotetiche conseguenze... Non e' certo mia intenzione scatenare allarmismi inutili, ma solo comprendere meglio i punti di forza e le debolezze dell'unica difesa disponibile, l'ipfiltering.
Detto questo, aspetto a gloria di essere corretto per aver scritto un sacco di castronerie  

nn e la prima volta che basta poco x generare il caos mi riferisco ad altri topic ovviamente     !!!

cmq la sigla di download può avere diverse diciture dl dw .....e altre D/L basta capirsi di solito io uso dw...