Vlákno názorů k článku Kam pakety, kam jdete aneb odposlech sítí od MK - to musi byt rychlost :-)

to musi byt rychlost :-)

jo az ted mi tvo cvaklo :) me samozrejme taky ...jo me to chodi na pager a pak mi to nedojde na co je to reakce :) jo moje taky a mam to rano v mailu v polozce

CodeRed 237
CedeRed II 92

v reportem vedle portscanu neuspesnych pokudu dostat se pres Fw resp kdyz nekdo nahodou trefi sit ze ktere je pristupny SSH.

ne .ma tam regexp a pokud nesedi tak kaput

Do te proxy nekdo ta URL zadava?

Ja osobne davam prednost mit nakonfigurovane poradne ty servery :-)

protoze ta proxy je obecne-aplikacni a filtruje to ...nevim jak funguji veci jako paketovy nebo stavovy firewall a hlavne jak je to s licentovanim IMHO jedna slusna proxy schova nekolik desitek takovychto NT serveru. Nerikejte mi proboha proc Odpoved byla na to proc by to nekdo delal ne ze je to potreba. Ja sem rekl ze o takovychto instalacich vim i kdyz nejde o nic duleziteho. Nebo naopak je to proto ze poskytovatel chce mit infrastrukturu IN-HOUSE protoze to proste vyzaduje bezpecnostni politika dane instituce.

proboha proc? Na tyto dotazy vsechny moje servery odpovidaji "404 Not Found" ...

- bezpecnosti (schovat W2000S za proxy ktera filtruje nektere prilis smysluplne pozadavky :) nepr takove ktere obsahuji ..
194.176.164.181 - - [11/Feb/2002:10:45:21 +0100] "GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 400 328 "-" "-"

217.66.208.18 - - [11/Feb/2002:04:06:35 +0100] "GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/c
dir HTTP/1.0" 404 307 "-" "-"
217.66.208.18 - - [11/Feb/2002:04:06:36 +0100] "GET /scripts/..%c0%af../winnt/system32/cmd.exe?/c
dir HTTP/1.0" 404 307 "-" "-"
217.66.208.18 - - [11/Feb/2002:04:06:37 +0100] "GET /scripts/..%c1%9c../winnt/system32/cmd.exe?/c
dir HTTP/1.0" 404 307 "-" "-"
217.66.208.18 - - [11/Feb/2002:04:06:39 +0100] "GET /scripts/..%%35%63../winnt/system32/cmd.exe?/
+dir HTTP/1.0" 400 291 "-" "-"
217.66.208.18 - - [11/Feb/2002:04:06:40 +0100] "GET /scripts/..%%35c../winnt/system32/cmd.exe?/c+
ir HTTP/1.0" 400 291 "-" "-"
217.66.208.18 - - [11/Feb/2002:04:06:41 +0100] "GET /scripts/..%25%35%63../winnt/system32/cmd.exe
/c+dir HTTP/1.0" 404 308 "-" "-"
217.66.208.18 - - [11/Feb/2002:04:06:43 +0100] "GET

Ja si rovnez myslim, ze je mozne vysledky aproximovat s urcitou presnosti. Nicmene prave protoze dnesni Internet vypada tak jak vypada, tak na strane serveru nebo po ceste (stale hodne vzdalene od spotrebitele) merit udaje jako response time, zda-li odpoved vubec dorazila apod. mi pripada mirne receno zcestne - samozrejme urcite udaje beru a chapu, ze s urcitou pravdepodobnosti jsou spravne, ale tipl bych si, ze minimalne polovina Vasich 'on-line' zjistovanych udaju by byla v praxi zatizena tak vysokou chybou, ze by byla prakticky k nicemu (aspon pokud by byla merena nacrtnutymi postupy). Nejen v zaostalych zemich je NAt na dennim poradku, naopak davno neplatici predikat, ze v Internetu spolu komunikuji 'vysilac - prijimac', kde vysilac = server, prijimac = uzivatelovo zarizeni, zpusobuje velmi vazne problemy ve vsech nove vyvijenych technologiich...:-(

Clanek se tyka obecneho trendu v ziskavani dat pro clicksteam analyzu a ja neprezentuji muj vlastni produkt, ktery neexistuje jako neexistuje zadne obchodni oddeleni. Nezpochybnuji Vase znalosti v dane oblasti. Kazdopadne si myslim, ze je lepsi vyresit problem nepresne a dospet k pravde se znamou toleranci, nez lpet na presnem reseni a nedospet k pravde vubec. To je ale vec nazoru.

Pokud jsem zaujaty, tak pouze v tom smyslu, ze by mne zpusob, jak ziskat popsana data opravdu hodne zajimal a rad bych takove reseni komercne vyuzil (mi zakaznici maji eminentni zajem o takove reseni). Bohuzel vzhledem k tomu, ze krome marketingove omacky si troufam rici, ze jsem poctive nastudoval v prubehu nekolika let i ty ciste technicke aspekty veci, si to nemohu dovolit (ziskat tyto informace), protoze bych delal akorat ze zakaznika blbce a touto cestou se me podnikani neubira. Nerikam, ze data, o kterych pisete nejste schopen (pravdive!) ziskat, nicmene opravdu Vam neverim ze je ziskate (opravdova data) popsanym zpusobem. Pokud vydavate popsana data za realna, prominte mi ten ostry vyraz, ale v tom pripade lzete a pouze diky schopnemu obchodnimu oddeleni Vam to zatim prochazi.

Co se tyce reseni vs. komercni uspech - je to presne jak napsal kolega - mozna jste zaznamenal obycejne teplomery vs. merice mikrovlneho zareni apod. - merit skutecny vyznam a dopad technologie dle jeji komercni uspesnosti je jedna cesta, poctiva prace a fakta je vsak bohuzel casto o necem jinem - ovsem vzdyt mame prece kapitalismus, ne?

Windows 95 je uspesne komercni reseni, nicmene ja bych na nem opravdu jakykoliv system nepostavil.

Uspesnost komercniho reseni je pouze v tom, jak dokaze obchodnik za podpory marketingu zblbnout zakaznika.

Nejde o terminologii ISO/OSI, rodina protokolu TCP/IP obsahuje taktez koncepci transportni vrstvy, to Vam urcite neuniklo. Uvedl jsem, ze TCP musi realizovat end-to-end komunikaci, otazkou je, je-li na druhem konci pocitac uzivatele nebo nejaky prostrednik jako napr. proxy server. Takze netvrdim, ze vzdy jde o komunikaci uzivatelskeho pocitace a serveru.

Dle meho nazoru jste zbytecne zaujaty. At uz si myslite cokoliv, tak Vas mohu ujistit, ze existuje dostatek uspesnych komercnich reseni pro clickstream analyzu, jenz odposlech vyuzivaji.

Zapomnel jste na "Zjednodusene receno ...". Cilem bylo v omezenem rozsahu nastinit moznosti odposlechu site pro clickstream analyzu. Mozna zvolena "popularni" forma ctenarum nesedla. Nez vysek z vetsiho dila bych to oznacil jako redukci informaci na unosnou miru, ale vysledek muze vypadat stejne.

Co se tech predikatu tyce, on clanek trosicku vypada, jako by to byl vysek vetsiho dila, kteremu neco predchazelo. Alespon, kdyz se clanek jmenuje tak jak se jmenuje, tak bez dalsich predikatu pusobi tvrzeni jako "... je komunikace po síti koncipována do několika vrstev, přičemž vrstvou nejvyšší je v našem případě aplikační vrstva protokolu HTTP" jako ponekud podezrela a vytrzena ze souvislosti (nebo to, ze vrchni aplikacni vrstva je HTTP je obecna vlastnosti odposlechu ?). Takze, pokud jde skutecne o trochu nestastny vysek z vetsiho dila je mozne, ze nam proste urcite predpoklady z onoho dila vyrcene drive chybi.

I kdyz, je pravda, ze za muj dojem "vytrzenosti" mozna muze ten, kdo vybral neadekvatni titulek (ja vim, jde o pocet hitu ...), ktery rozhodne neevokuje dobrou predstavu toho, co bude obsahovat clanek - a proto jsou mozna ma (zklamana) ocekavani neduvodna ....

Prominte, ale motat sem terminologii modelu ISO/OSI v okamziku, kdy se bavime o TCP, IP apod. neni vhodne a nebo naznacuje, ze nevite o com mluvite.

Vezmu-li Vas doslova, pak tvrdite, ze transportni vrstva - ve Vasem pojeti protokol TCP - je komunikace uzivatelsky pocitac vs. server - dovolim si Vas vyvest z tohoto omylu - uz pri aplikaci zaklaniho NATu nekomunikuje server s uzivatelskym pocitacem, alebrz se strojem zajistujicim tento NAT. Ja se celou dobu nebavim o routerech (smerovacich, chcete-li cestinu) mostech (co jineho nez opakovac je most? - ja bych se drzel jasneho terminu bridge) a podobne, ktere konci na urovni IP protokolu (sitova vrstva), ale o TCP. IP protokol konci na urovni IP adres, ale jiz nikoli sluzeb, k tomu abyste byl schopen odlisit provoz na urovni aplikaci, potrebujete vedet pozadavky sluzby (TCP, UDP, RAW apod.) a tak se dostavate na transportni vrstvu. Rici, ze se neprovadi odposlech pod transportni vrstvou bohuzel svedci o tom, ze o vrstvove architekture zrejme moc nevite, jinak mi neni jasne, jak chcete zjistovat treba response time, chyby na siti apod. (protokol ICMP lezi presne na urovni IP protokolu, o transportnim layeru si nechte jenom zdat)...

Bez urazky bych Vam doporucoval nejprve patricnou problematiku nastudovat, zatim tu cim dal vice mlzite a ukazujete, ze skutecnost je asi nekde jinde, nez kam ji chcete dostat...

PS: Jak vite, ze transportni vrstva ma co do tuseni sitove komunikace, co kdyz je nizsi vrstva resena uplne jinym IPC mechanismem?

Ne tvar, ale nazev souboru cookie vypada napr. anyuser@lupa.cz.txt

Opomijite skutecnost, ze odposlech se provadi na urovni transportni vrstvy sitove komunikace, takze ani na urovni HTTP, ani na urovni IP. Dovolim si citovat z clanku pana J.Peterky:

Transportní vrstva je implementována až v koncových uzlech, a nikoli v "přestupních uzlech" v rámci přenosové části sítě (tedy například "uvnitř" veřejné datové sítě). Je to tedy vrstva, která se může zabývat pouze vzájemnou komunikací koncových uzlů, neboli koncových účastníků komunikace, a netýká se "přestupních uzlů". Transportní vrstvu tedy najdeme v koncových počítačích, ale nikoli již ve směrovačích (routerech), mostech či dokonce opakovačích.

Prenos od serveru k prvnimu prestupnemu bodu zajistuji nizsi vrstvy pod vrstvou transportni, ale na takove urovni se odposlech neprovadi.

"Mame-li na nasi strane proxy, je situace jednodussi, nebot muzeme vypnout cachovani."

Muzete mi prosim vysvetlit vyznam proxy na strane poskytovatele obsahu? (bez uvahy o throttlingu)

Dekuji

runner

Zalezi na OS. Pokud se musite v danem OS nejprve prihlasit do systemu, tak je to tak jak pisete. Pokud se nemusite prihlasit (typicky Win 95, 98), kde neni prihlaseni povinne, tak jste anonymni a cookie ma tvar napr. anyuser@lupa.cz. A "anyuser" muze byt kdokoliv, kdo na pocitaci bez prihlaseni pracuje.

zachazime s nim jako s anonymnim uzivatelem, ikdyz ma nas cookie file, nebot ten pouze identifikuje pocitac, nikoliv uzivatele.

Coze?

Cookie prece identifikuje uzivatele, nikoli pocitac (aspon pokud vim, tak ruzni uzivatele stejneho pocitace maji cookie file kazdy zvlast ve svem domovskem adresari).

-Yenya

Jak uz naznacili jini - z clanku jsem nabyl dojmu, ze jedna z velmi podstatnych analytickych informaci je jakym zpusobem se clovek po Webu pohybuje - tuto cast jste zodpovedel uspokojive, vice skutecne v technickych moznostech neni.

Ovsem je tu jeste druha cast a sice stravena doba a zda-li uzivatel obdrzel pozadovana data a jaky byl response time. Bohuzel, Vase informace mne rozhodne neuspokojily, naopak utvrdily v tom, co jsem si myslel, ze vydavate za realna data neco, co Vam 'vypadne' z analyzy a o cem jste mozna presvedceni, ze jsou to data, ktera jste v clanku pomerne rozsahle popsal. Domnivam se, ze nejen ja (coby clovek, zabyvajici se spise tim HTTP, TCP a nizsimi vrstvami) mam pocit, ze zrejme netusite co se muze na urovni HTTP, TCP a nizsich vrstev ve skutecnosti dit a ze to, co Vy namerite nejsou ve skutecnosti v zadnem pripade verohodna data, aspon ne ve smyslu, o kterem pisete. Jsou to data, ktera namerite, resp. analyzujete end-to-end komunikaci, ale nikoli od serveru k prostrednikovi (ci v lepsim pripade uzivateli), ale od serveru k prvnimu 'prestupnemu' bodu. Tvrdite, ze vychazite z pesimisticke varianty - v tom pripade Vase zavery nechapu o to vice, ze v tomto pripade v podstate nemate co merit, nic totiz nejste bez dodatecnych aplikaci (napr. applet na strane klienta) schopni zjistit. Tak jako ten proxy server nemusi byt v ceste osamocen (on totiz muze byt nastaven tak, aby si sam 'pushoval' data - uzivatel je tom irelevantni) - muze byt po ceste kaskada/strom cache serveru (rovnez realny stav), data mohou byt nekolikanasobne zpomalena/zahozena/duplikovana po ceste za tim prvnim 'end', ktere merite. Stejne tak jsem nemluvil jen o proxy serverech, coby aplikacnich aparatech, ale o obecnych NATovacich zarizenich - pokud si myslite, ze v ceste byva zpravidla maximalne jeden - mohu Vas vyvest z omylu, struktury VPN siti byvaji casto velmi slozite, nekdy az nad nutnou miru.

Obaval jsem se, ze je to opet spise marketing a penize nez skutecne dobre analyticke nastroje, Vase odpoved mne v tom utvrzuje cim dal vice, myslite si, ze se ve sve argumentaci (zustanme prosim v ciste technicke rovine) mylim?

Dle RFC2616 popisujici HTTP lze ovlivnit cachovani pomoci hlavicky Cache-Control. A konkretne zakazat cachovani lze pomoci: Cache-Control: no-cache. To vse samozrejme za predpokladu, ze proxy korektne implementuje prislusne RFC.

Spis by me zajimalo zda je mozne donutit (ci aspon poprosit :o) proxy server, aby stranky necachoval..(napr. nejakym meta tagem?)
Pripadne podle ceho proxy rozhoduje, zda stranku posle z cache nebo o ni zazada znova na serveru (mam na mysli staticke stranky).
(asi laicka otazka)

Ano. Je samozrejme mozno donutit proxy server, aby cachoval dynamicky generovane stranky, ale nedava to prilis smysl.

Myslim ze to bylo mineno takto:

proxy server je v ceste k zakaznikovi a pokud by byli stranky staticke, nemusela by se navstevnost projevit.. (v logu, odposlechu..), pac by se netahali ze serveru, ale prave z onoho proxy - jsou li ale dynamicke, natahuji se vzdy znova ze serveru (na kterem hostuji)

Oba: Pochopil jsem to spravne?

Vas konstruktivni prispevek do diskuse je milym zpestrenim. Velice rad se od Vas necham poucit.

Vzhledem k tomu, ze naprosta vetsina komercnich aplikaci je na principu dynamicky generovaneho obsahu, nemelo by cachovani obsahu serveru zpusobovat problemy.

Bud nevite, co je to dynamicky generovany obsah nebo nechapete jak funguje proxy server.

Je dobre rozlisit problematiku komunikace dvou koncovych bodu a problematiku identifikace uzivatelu. Odposlech komunikace se zamerne provadi na vrstve TCP, ktera ma zajistit doruceni informace na druhy pocitac. Samozrejme mate pravdu v tom, ze v ceste komunikace muze byt jeden nebo i vice proxy serveru. Pokud je uzivatelsky pozadavek vybaven proxy serverem na strane jeho ISP, mel by nas server o tom dostat nejakou zpravu, na to se ale neda spolehnout. Takze se muze stat, ze se to vubec nedozvime, ze byl uzivatelsky pozadavek obslouzen z cache, nehlede na ignorovani meta tagu ve strankach pro zabraneni cachovani obsahu. Netvrdim, ze data ziskana odposlechem jsou uplna, ale jsou rozhodne presnejsi a uplnejsi nez logy. U logovych souboru je tento problem jeste rozsahlejsi. Mame-li na nasi strane proxy, je situace jednodussi, nebot muzeme vypnout cachovani a pokud patri proxy nasemu ISP, tak se pokusit dohodnout s ISP o necachovani obsahu, takze vsechny pozadavky jsou obslouzeny nasim serverem.

Pokud jde o problematiku identifikace uzivatelu, zde je to samozrejme jeste slozitejsi. Pokud nepouzijeme cookie, nikdy nevime, jestli komunikujeme se stejnym pocitacem (IP nam nepomuze) a uz vubec nevime jestli se stejnym uzivatelem. Pro analyzu je dulezite, abychom nepredpokladali, ale staveli na faktech. Tedy volime pesimistickou variantu a pokud se uzivatel neprihlasi pod svym uzivatelskym jmenem, zachazime s nim jako s anonymnim uzivatelem, ikdyz ma nas cookie file, nebot ten pouze identifikuje pocitac, nikoliv uzivatele. Presto jsou clickstreamova data, ktera od nej ziskame dulezita pro analyzu. To ze nevime presne o koho jde nesnizuje jejich informacni dulezitost.

Jiste jste si vsimnul, ze i na neprodejnich webech se nas firmy snazi primet k registraci, napriklad vymenou za download dokumentace nebo ruznych freeware a shareware produktu. Potrebuji nas jednoznacne identifikovat, jak je to ucinne je dalsi otazka, nebot uzivatele obvykle neuvadeji pravdive udaje, predevsim diky tomu, ze registracni formular je neunosne obsahly.

TCP samozrejme musi realizovat end-to-end komunikaci, otazkou je, je-li na druhem konci pocitac uzivatele nebo nejaky prostrednik jako proxy server. Vzhledem k tomu, ze naprosta vetsina komercnich aplikaci je na principu dynamicky generovaneho obsahu, nemelo by cachovani obsahu serveru zpusobovat problemy.

Cela problematika je pomerne slozita a saha mimo ramec tohoto clanku.

Mozna nebylo od veci, aby autor nez zacal svuj popis rozebirat, nejprve stanovil predikaty, na nichz stavi.

Minimalne mi chybi jeden podstatny - a sice, ze predpoklada, ze komunikace je end-to-end, tedy ze se spolu skutecne bavi dva koncove body.

Bohuzel toto platilo v drevnich dobach internetu pred mozna jeste 7 lety, nikoli vsak pozdeji, nikoli dnes a do opravdoveho nasazeni IPv6 nikdy v budoucnu. To co popisuje je velmi zajimavy material, ktery vsak rozdhodne neidentifikuje a nepocita s jakymkoli prostrednikem a uz vubec to nehovori o uzivatelich v dnesni podobe internetu.

V uvedenem oboru (clickstream analyza) se nepohybuji, zrejme dokazi analytici ziskat zajimave udaje (verim, ze daleko hodnotnejsi nez Page Views, kterym jsem se smal od zacatku - coby material pro reklamni agentury), otazka vsak je, zda-li pote tyto udaje pravdive interpretuji tak, aby odpovidali skutecnosti, o kterych se tu pise...

Osobne se vsak domnivam, ze za soucasneho stavu veci je sniffing metoda, kterou nelze ziskat data, ktera jsou zde popisovana jednoduse proto, ze TCP spojeni, jak je ustanoveno, neidentifikuje end-to-end komunikaci (zejmena u firemnich zakazniku je to velmi podstatne).