Pan Haller, všetky vaše články sú "pecka". A kedže Vás považujem za odborníka, chcem sa opýtať:
"Existuje nejaký spôsob ako simulovať pripojenie z inej IP adresy ako v skutočnosti mám? Resp. je možné uskutočniť požiadavku na webový server Apache z inej IP a následne odchytiť odpoveď z webového serveru (SYN,ACK,FIN)? Nemám v úmysle hackovať, len potrebujem vyriešiť problém z Googlebotom a kedže nemám prístup k apache logom, chcel by som si overiť ako server odpovedá na požiadavky z IP adresy Googlebota."
Zdravim,
pokud chcete videt jak se chova server pro googlebot, pak pravdepodobne bude nejlepsi zmenit hlavicku http a to tak aby user-agent obsahoval "googlebot"
pro firefox je na to primo plugin. Zkuste pohledat.
Dík za tip. O tom viem, ale mne nejde o to čo konkrétne posiela Apache, ale či vôbec Googlebot dostáva odpoveď. V Google Webmaster Tools mi totiž pravidelne pri každom pokuse Googlebota o "crawl" ukazuje DNS chybu (opakuje sa to už tretí mesiac). Server pritom beží OK, ostatné roboty aj bežný surferi podľa awstat problém nemajú.
Ohledne problemu s Googlebotem vam asi prilis nepomuzu.
Ovsem na otazku "Existuje nejaký spôsob ako simulovať pripojenie z inej IP adresy ako v skutočnosti mám?", vam odpovedet muzu.
Pozadavek se zfalsovanou adresou odeslat muzete, ovsem problem je v tom ze server bude odpovidat na tuto zfalsovanou IP adresu a odpoved bude smerovana uplne nekam jinam, to tedy znamena ze k vam odpoved neprijde.
Tento problem by jste mohl vyresit pouze pokud by jste byl v s lokalni siti s danym serverem, nebo na trase, kterou je pripojen do internetu. V tom pripade by jste slysel komunikaci a mohl reagovat (data dale nepropustit a odpovedet na ne).Existuji i protokoly, kterymi se da menit smerovani v internetu a vlastne tak presouvat toky dat, ovsem do tehle oblasti nevidim.
Dalsi moznosti by mohlo byt pozmeneni routovacich pravidel na serveru. Ovsem to vyzaduje mit administratorska prava k serveru. Napriklad na Linuxu by jste toho mohl docili pomoci natovani (pres IPTABLES). Data by prichazela na server s vasi IP adresou, ovsem server by prepsal zdrojovou IP adresu a pak teprve predal data ke zpracovani a pri odchozich datech by se cilova adresa opet prepsala na vasi.
Ďakujem za odpoveď. Myslel som, že to nepôjde. Je to škoda, pretože aj môj ISP je z toho problému zúfalý. Na Apachi bežia viaceré "virtual hosts" domény a problém s DNS a Googlebotom mám ja a ešte jedna. Je to zaujímavý problém, pretože nefunguje ani napr. Site Overlay v Google Analytics. A hlavne ťažko sa hľadá chyba. Keby sa aspoň dal vykonať reverzný dotaz na nejaký z nameserverov Google. Ale už dosť, toto nijako nesúvisí s článkom.
Chcem sa, ale opýtať koľko pokračovaní plánujete? Dúfam, že veľa. Z vašich článkov napriek tomu, že (chvalabohu) neuverejňujete detailné postupy som sa veľa naučil. Sú to najlepšie, čo kedy lupa uverejnila.
A ešte jedna otázka. Existuje nejaká šanca nastaviť iptables aby "prepúšťali" pakety pre aktívne ftp serverom naväzované spojenie. Nie som nijaký expert, ale keď som to dobre pochopil, tak spojenie medzi klientom vzniká požiadavkou klienta na port 21 (20?) ftp servera. Potom sa server snaží vytvoriť spojenie s klientom na nejakom vysokom porte. Aj keď ide o "odchodzie" spojenie iptables to štandartne zablokujú. Nechápem prečo, keď spojenie začal klient na porte 21 (20?) a v úvodných pravidlách iptables mám nastavené "ESTABLISHED" spojenia na "ACCEPT". V SUSE to riešim, tak že otvorím všetky highports.
Dík za odpoveď. Stále mi nie jasný význam portu 20, keď sa spojenie naväzuje na vysokých portoch. Alebo len klient načúva na vysokom porte a server posiela dáta vždy z portu 20? No asi sa budem musieť zmieriť s "it just works, no matter how".
Stači zaviesť tieto 2 moduly a je to v suchu aj ked si myslím , že v prípade NAT-ka je lepšie použiť ked sa da pasiv bo aktiv aj napriek modulom nejde uplne spolahlivo-
Vlastne to spojeni na portu 21 je spojeni pro vymenu prikazu a odpovedi.Vyhoda vytvareni noveho spojeni je v tom , ze muzete treba stahovat deset souboru najedno a pritom jeste dva uploadovat, vsechna komunikace probiha na jinych spojenich a to puvodni spojeni je volne, a diky nemu muzete navazovat dalsi spojeni (upload, download) aniz by jste se musel napriklad znovu prihlasovat.
Urcite to takto bylo udelano kvuli snadnejsi implementaci a prehlednosti. Protoze to nove datove spojeni je jakoby jednostrane (data proudi vzdy jenom jednim smerem), a uz v nem neproudi zadne prikazy, ale okamzite data. Jakmile jsou odeslana nebo prijata vsechna data je spojeni automaticky zavreno.
Jestli to bylo z jineho duvodu, tak me klidne kdokoliv opravte.
Planuju napsat jeste nejmene dva clanky a to RST Resetovaci utok a Unos TCP spojeni, potom se uvidi, ale se psanim bych nerad skoncil.