MCUserver

[Thomas Shaddack]

On Thu, 30 Sep 2004, MK wrote:

> Tak za prve, neni to omezeni pro nikoho, kdo pouziva korektni pristup na net. 
> To ze Vy, nebo Vas provider nema korektne nastaven reverzni DNS zaznam, 
> je Vas, nebo provideruv pruser, ne MCUserveru. 
> 
> MCUserver mel bezne denne vice jak 60% pristupu z neexistujicich domen, respektive
> z neidentifikovatelnych domen. To jsou vsecny ty anonymizery, etc

Nebo vetsina Dalneho Vychodu. Co se takhle podivat na WHOIS na nektere z 
IP co nemaji reverzni DNS zaznam? To hodne napovi.

> Podivejte se na RFC doporuceni :-)))

RFC pouziva formulaci "SHOULD have", nikoliv "MUST have". Nejedna se tedy 
o vylozene zasadni pozadavek.

Reverzni DNS se take daji docela squele falsovat, pokud ma dotycny pristup 
ke konfiguraci resolveru ke sve IP adrese. (To se da odhalit lookupem na 
IP vracene domeny, ale to pridava prodlevy do transakci a ve vetsine 
beznych scenaru to byva neprakticke. Pokud vylozene *potrebujeme* overit 
identitu protistrany, byva spolehlivejsi napr. SSL.)

Po svete se poflakuje spousta nezabezpecenych proxyserveru. Mnoho z nich 
ma korektni reverzni DNS zaznam, vase opatreni je proti takove metode 
obejiti filtru bezmocne. Muzete samozrejme zkouset scannovat protistranu, 
jestli nema otevrene nejdulezitejsi porty a na nich signatury proxyn (80 
pro Apache s mod_proxy, 3128, 8000, 8001, 4000, 1080, a spoustu dalsich), 
ale pak se pripravte na to, ze naprdnete spoustu adminu co protiscany 
nemaji radi, a ze pristupy v nekterych pripadech budou trvat dost dlouho. 
Take je zde CGIproxy, http://www.jmarshall.com/tools/cgiproxy/ - perlovy 
script pro anonymizaci a ochranu pristupu na Net bez pouziti jakehokoliv 
software nainstalovaneho na koncovem pocitaci (dobre v kombinaci s HTTPS 
pro obejiti rozlicnych filtru ve firmach nebo ve skolach). Mnoho 
technologii je popsanych na peacefire.org - i kdyz tam jsou zamereni spise 
na obchazeni restrikci ze strany ISP nez ze strany serveru.

Reverzni DNS lookup a nasledne blokovani se vcelku bezne pouziva pro email 
(i tam ale jde o problemy - pokud mate klienty nebo partnery v Cine, 
Koreji, nebo na Taiwanu, koledujete si o "odfiltrovani" jejich znacne 
casti). Pro web pak uz spise vzacneji, nebot legitmnim uzivatelum jenom 
prinasi problemy a i ti, proti kterym je namirene, jej mohou trivialne 
obejit.

Pokud se serverem existuje nejaky problem, je dobre jej korektne 
identifikovat a navrhnout reseni od problemu odvozena. Je-li potiz v 
prilis mnoha downloadech, da se server nakonfigurovat na omezeni poctu 
downloadu z jedne IP adresy za jednotku casu, nebo na omezeni prenosove 
rychlosti v jednom spojeni, omezeni poctu paralelnich spojeni, etc. - 
vicemene skoro kazdy problem miva nejake korektni a dobre[1] reseni. Ovsem 
prislusny administrator to taky musi umet.

[1] V pripade ze alternativy jsou "zmenit neco u sebe" nebo "trvat na tom, 
ze vsichni ostatni se prizpusobi" je prvni reseni praktictejsi. (Apropos, 
pokud se vratime k minulemu patku, prestoze je na to o den brzy, proc je 
vlastne pouzivani nestandardniho softwaroveho baliku - browseru ktery 
porusuje specifikace HTTP tim ze se pokousi uhodnout[2] MIME typ 
downloadovaneho objektu (a tim zaroven vystavuje uzivatele bezpecnostnim 
otvorum), ktery porusuje RFC1738[4], ktery zasadne porusuje W3C 
specifikace (a to HTML i CSS), browseru ktery v novejsich verzich umyslne 
porusuje RFC23996[3], groupware ktery porusuje RFC821 a RFC822[4] 
(Exchange), mail klientovi ktery se neridi doporucenim RFC2046[5] 
(Outlook), komunikacniho software porusujiciho LDAP protokol[6] 
(Netmeeting), a dalo by se pokracovat *dost* dlouho - proc je pouzivani 
tohoto typu software obhajitelnejsi, nez jinak vicemene neskodna absence 
reverzniho DNS zaznamu?
Pokud tohle neni dvoji metr, proc?

[2] http://support.microsoft.com/default.aspx?sd=msdn&scid=kb;en-us;293336

[3] http://simon.incutio.com/archive/2004/01/30/noMoreUsernames

[4] http://www.kom.com/%5Cnoms/

[5] http://www.netsys.com/ietf/2002/msg00159.html

[6] http://www.tldp.org/HOWTO/NetMeeting-HOWTO/a490.html

> A zacnete buzerovat sve providery, ci spravce siti, ci sami sebe, pokud 
> zamerne pouzivate pomucky, ci postupy, ktere RFC porusuji ci obchazeji

Bohuzel lide aplikujici nevhodna reseni na spatne specifikovane problemy 
si casto nasazeni podobnych reseni vynucuji.

Co se tyce volby providera, nekdy proste neni.