Fórum Root.cz
Hlavní témata => Windows a jiné systémy => Téma založeno: Tunelář 18. 08. 2013, 11:41:38
-
Zdravím.
Můj občasný ISP - BLESKMobil se zbláznil a znefunkčnil službu Windows/Microsoft Update (od 15.8.2013 do "stále trvá"). Samotná Telefonica, pod svou původní značkou, tuto službu (poskytovanou zřejmě i skrze stejnou základovou stanici) nezařízla. Technicky: jsou špatné parametry pro připojení k serverům Akamai a Microsoft, vyprší timeout.
Než u BLESKMobilu utratím těch pár posledích stovek (bacha na jejich dobíjecí pobídku - pokud tuhle službu potřebujete, je to pro blázny co neví co s penězi) a skončím s nimi, napadlo mne tuto službu svést do tunelu "HTTP proxy --> TOR" který občas používám.
Použil jsem příkaz
netsh interface portproxy add v4tov4 listenadress=* listenport=* connectaddress="adresa proxy serveru" connectport="port proxy serveru" protocol=tcp
jenže výsledek se jaksi nedostavil.
Otázky:
- Neví někdo co dělám špatně?
- Chápu správně, že pokud namísto čísla portu použiji krátký název služby Windows Update - "wuauserv", automaticky boudou použity správné porty?
- Výchozí IPv4 brána má metriku 31. Mám přidělenou Teredo IPv6 adresu, metrika 36. Co by se přesně stalo kdybych metriku Tereda změnil? Chápu-li to správně musel bych metriku změnit u adresy odpovídající "Spojení - místní adresa IPv6"? Tato adresa se mění s každým novým připojením do Internetu?
Vidíte, že se příliš neorientuji, tak mne prosím ušetřete jízlivých poznámek. Děkuji za vysvětlení a pomoc. Jiné návrhy a doporučení vítám taktéž.
P.S.
Jen pro úplnost ještě uvádím, že z počátku jsem se domníval, že u mne dochází k podobné chybě jako popisuje KB836941 - Při použití webu Windows Update a Microsoft Update dochází k dočasným chybám souvisejícím s připojením (http://support.microsoft.com/kb/836941/cs).
Jenže jednak se mi to děje na Vistách, což nic neznamená. Jednak jednoznačně Microsoft Update skrze mobilní Internet od vlastní Telefoniky (prostě kurví systematicky) i T-Mobile funguje řádně. Nemobilní Internet také, i když zrovna ten od Telefoniky jsem nezkoušel.
-
- Chápu správně, že pokud namísto čísla portu použiji krátký název služby Windows Update - "wuauserv", automaticky boudou použity správné porty?
Huh? To není server, ale klient.
-
Lol: Tvůj povzdych nechápu. Bavím se pochopitelně o "listenport"
Použití: add v4tov4 [listenport=]<celé_číslo>|<název_služby>
[connectaddress=]<adresa IPv4>|<název_hostitele>
[[connectport=]<celé_číslo>|<název_služby>]
[[listenaddress=]<adresa IPv4>|<název_hostitele>]
[[protocol=]tcp]
Parametry:
Příznak Hodnota
listenport - Port IPv4, na kterém se má naslouchat.
connectaddress - Adresa IPv4, ke které se má provést připojení.
connectport - Port IPv4, ke kterému se má provést připojení.
listenaddress - Adresa IPv4, na které se má naslouchat.
protocol - Používaný protokol. Nyní je podporován pouze protokol TCP.
Poznámky: Přidá položku pro naslouchání pro port IPv4 a připojení přes server proxy prostřednictvím protokolu IPv4.
P.S.
Pro případ, že by měl někdo problém, ještě jednou. Chci na počítači nastavit globální proxy server (pomocí Net Shell-u) který by byl sveden do proxy serveru, který je dále napojen na TOR tunel. Ten proxy server pro TOR tunel je nutností protože TOR sám o sobě požívá SOCK.
Kromě jiného se ptám co se stane když metriku pseudo tunelu (IPv6, teredo) nastavím tak aby šlo o výchozí bránu. Je vůbec tento tunel použitelný i pro odchozí komunikaci?
-
Ano, a co jako? Co to má dělat se službou wuauserv? To je z tohohle hlediska normální HTTP/HTTPS klient, o jakých speciálních portech je proboha řeč?
-
Jo, a jinak to děláš na úplně blbém místě. Nastav si tu proxy v IE a napiš:
netsh winhttp import proxy source=ie
-
Díky Lole.
Takže import nastavení z IE funguje (netsh winhttp import proxy source=ie). Importovaná pravidla by se měla zobrazit ve výpisu.
Je ale potřeba změnit nastavení pro proxy kterou používá IE (inetcpl.cpl), tak aby se týkala uživatele - Správce. Nastavení jednotlivých uživatelů pro IE mohou zůstat zachována. Jak je to při více správcích na jednom počítači nevím, snad se musí použít globální nastavení stejné pro všechny uživatele počítače.
Vlastní HTTP Proxy (ten co směruje pakety pro TOR-tunel) může zůstat klidně spuštěný v kontextu uživatele který i vytvořil připojení do Internetu. Není třeba nic z toho spouštět nově jako služby dostupné pro celý počítač a všechny uživatele.
Jen pro úplnost uvádím, že odstranění pravidel importovaných z IE se odstraní příkazem "netsh winhttp reset".
Nakolik věříte TORu pro aktualizaci skrze něj nevím. Ale alespoň pro aktualizaci antiviru od Microsoftu, kdy certifikáty pro ověření necháte stahovat jinou cestou (výjimka v proxy) je to docela použitelné. Pochopitelně, pokud vám záleží na anonymitě, je to způsob jak se kompromitovat (spusttě si několik TOR-tunelů).
---
Co přesně má tedy dělat kontext PortProxy (netsh interface portproxy)? Myslel jsem, že jde o universální (ve smyslu IPv4 <--> IPv6) možnost jak nastavit globální proxy?
n krátký název služby
Jak je to s tím IPv6 tunelem a odchozí komunikací? Respektive tedy po změně metriky?
---
Služba "wuauserv". Z nápovědy, kterou jsem překopíroval i do diskuse, jsem měl za to, že není třeba porty vyplňovat ručně, ale stačí zadat název služby a porty se přiřadí automaticky, viz [listenport=]<celé_číslo> nebo <název_služby>.
V každém případě, Lole, díky za současnou nápovědu.
---
Co se děje s tím BLESKMobilem nevíte? Začátek spolupráce Telefonica - Vodafone, testovaná selektivně na uživatelích BLESKMobilu? Budoucí nový úžasný FUP limit, nebo prostě jen další kurvítko.
Jak je to s tím NATem náhodou nevíte? Stav služby Teredo mi teď ukazuje, že za NATem nejsem, ale vždy když jsem zkoušel nějakou službu tak jsem byl. Teď hned to vyzkoušet nemohu, protože teď jedu skrze TOR a nerad míchám komunikaci, obzvlášťe způsobem který nemám zmáknutý. Díky za případný komentář.
-
Co přesně má tedy dělat kontext PortProxy (netsh interface portproxy)?
Ten MU/WU kram taha neco pres BITS, "univerzalni" proxy tam nefunguje.
-
K těm dvěma TOR-tunelům. Prostě si spusťtě ještě jeden, jen pro danou činnost a mějte pod kontrolou všechny ExitNodes.
K té proxy. Jak nastavení proxy v IE, tak import/změna pomocí NetSh může mít značné zpoždění při aplikaci pravidel. Například resetovaná proxy se může klidně i po desítkách minut zůstávat nastavená, i po ukončení všech aktivních spojení. Zatím nevím přesně jak spolehlivě zajistit okamžitou změnu pravidel. Vůbec se to chová celé podivně (zapnout to jde snáze než vypnout).
Příkazy jsem nezadával přímo z NetSh (ten má navíc mód online/off-line... který je výchozí?) ale sakum prdum, tedy jak je vidíte "netsh winhttp ...". GPUpdate také nic nezajistí. Kdyby vás něco napadlo, napište.
-
Myslím, že bych změnil poskytovatele. Ušetřených několik stovek absolutně to nestojí za čas tím strávený. Mimochodem, i to Teredo je příšerný bazmek.
-
Však já mám těch ISP pro mobilní Internet několik. Zrovna mi udělal dočasnou nabídku na slevu pár stovek T-Mobile, ten mi navíc nic neblokuje a rychlost je maximální dostupná, jenže je taky nejdražší (0,4Kč/MB) a dělám opravdu jen to nejnutnější (zase mu neplatím žádný paušál).
V česku je na mobilní Internet nutné používat několika ISP. Pro různé lokality, pro různé neblokované služby,...
To abych okamžitě, bez změny připojení do Internetu, nemohl zkontolovat aktualizace a virové definice mi opravdu vadí a poskytovatele kvůli tomu změním. Myslím, že i pro ně škoda - rozhodně je nijak nepumpuji, jsem umírněný a měsíčně mi stačí 2-3 GB (pokud stahuji větší množství dat, tak jen proto že něco blokují a já musím použít okliku - update definic klienskou aplikací: 20-400 kB, update prostřednictvím souboru s definicemi: 5-80 MB).
Nikde navíc není napsáno, že příště je nenapadne blokovat něco jiného. Komunikovat se s nimi rozumně nedá, a já pokaždé nebudu přehazovat SIM kartu do telefonu abych provolal dvacku a oni mi řekli že v podmínkách služby zakazují úplně vše a ve smlouvě garantují jen rychlost 16kbps.
-
Tak ještě je všechno jinak.
Na začátek podotýkám, že Windows/Microsoft Update je nastavena tak, že ji může spouštět kterýkoli uživatel počítače.
TOR sám o sobě, ve výchozím nastavení, svede i spojení se servery Microsoftu do svého tunelu. Tato vlastnost se mi nelíbila a tak jsem tuto komunikaci, stahování certifikátů, aktualizaci času a ještě pár věcí směroval jinudy - standardní cestou, mimo TOR-tunel. ISP provedl změnu a tato standardní cesta (k serverům Microsoftu a Akamai) se uzavřela.
Vtip je v tom, že vůbec není třeba pomocí Net Shell-u importovat nastavení z IE proxy do globální proxy, po jejím nastavení.
Úplně stačí změnit nastavení IE proxy uživatele, který vytvořil připojení do Internetu a v jehož kontextu zrovna běží služba Windows Update. Nastavení IE proxy kteréhokoli jiného uživatele může zůstat beze změny.
Zajímavé je, a to právě vnášelo chaos, že pokud Windows Update blokuje nastavení IE proxy uživatele, ale natsavení IE proxy správce ho umožňuje tak se aktualizace provede pomocí takto definovaného spojení. Díky menší prodlevě při změně nastavení IE proxy, jsem hned nepoznal jak to funguje.
-
Tak je to musí být jinak, bohužel nevím jak. Ten import proxy pravidel se zřejmě někdy musí udělat. Jestli na to příjdu, tak sem časem napíši jak to je. Zatím mi v tom ta časová prodleva dělá neskutečný bordel. Jsem schopný to zprovoznit a ověřit funkčnost i bezpečnost, ale nemám dostatečnou kázeň, disciplínu, trpělivost a čas abych mohl zaručeně říci jak to funguje a několikrát to s časovým odstupem vyzkoušel.
Píši to jen, pro případ, že by mne chtěl někdo následovat. Problém je zřejmě v tom, že ne každá aktualizace běží ve stejném uživatelském kontextu, a i to musí být pro mnohé matoucí, protože jde o systémovou službu.
Zatím se mějte. Klidně sem dávejte poznámky, studijní zdroje,...
-
Samomluva je prvním příznakem šílenství, říkal náš matikář.
-
...Problém je zřejmě v tom, že ne každá aktualizace běží ve stejném uživatelském kontextu, a i to musí být pro mnohé matoucí, protože jde o systémovou službu....
Ahoj, mohl bys rozvést, jak to myslíš? Možná o tom píšeš, ale nějak to nechápu.
Jinak k tomu, že Blesk mobil blokuje Windows updates, pokud tomu opravdu tak je, tak určitě od nich pryč (zkus schválně změnit primární DNS server, místo toho, co ti poskytne Bleskmobil, dej jiný, nějaký veřejný, protože pokud se nemýlím, tak standardní WSUS servery od Micosoftu dostupné pro veřejnost by měly používát 80 a 443 porty, u XP tomu tak bylo, a vzhledem k tomu, že WSUS jde hromadně nastavit jak pro XP, tak i pro Visty, 7, 8 a samozřejmě i serverové edice, tak nevidím důvod, proč by měl mít jiné porty).
Pokud ti WSUS pojede - pak jej Bleskmobil blokuje na základě DNS záznamu (což mi příjde neetické), pokud ti to nepojede, tak ti pravděpodobně nepojede internet vůbec, protože Bleskmobil bude pravděpodobně blokovat ostatní DNS servery (firewallovací pravidlo není pro tento příúpad zas tak složité) (v tomto případě mi to příjde taky neetické).
Co se týče BITS, tak ten je nutný k tomu, aby ti to nevytížilo celou síťovku (velmi zjednodušeně řečeno, celá problematika je složitější, ale to je nad rámec tohoto tématu).
-
Čau Withy, čekal jsem zda se ozveš. Zkusím k tomu něco říci, ale... no však uvidíš sám. Bude to možná trochu nesourodé protože bych potřeboval prostorový zápis informací.
Jejich DNS, ani jiných ISP jsem nikdy nepoužíval, možná na zkoušku. Momentálně používám Open DNS a jako záložní mám Google DNS. Není problém použít cokoli, ale tady problém opravdu není.
Ono je to totiž celé trochu jinak. Jestli to správně chápu a mám vypozorováno, tak některé z těch nedostupných serverů Akamai právě dělají překlad pro servery ctldl.windowsupdate.com, *.download.windowsupdate.com, *.update.microsoft.com, crl.microsoft.com. Pokud vím tak systém Windows Update využívá jen IP adres (můžeš klidně mít blokované DNS) - překládá si sám názvy a určuje servery které budou použity pro poskytnutí služby (ony zmíněné servery Akamai a Microsft, znám i přesné sítě ale nemá cenu hovořit o stéble z kupky sena).
---
Analyzovat celý systém Windows Update je celkem fuška na moji představivost. Zejména proto, že si je snadné udělat zjednodušenou představu, která se vždy časem ukáže jako mylná. Kromě toho co jsem uvedl, jsem třeba vůbec neuváděl, že chování při blokovaném IE na firewallu je také odlišné, a odlišné je i při neomezené odchozí komunikaci.
Třeba Security Essentials Client přes svoji službu/cmd komunikuje se službou WU a ta se násle postará o získání aktualizace. Jenže se zdá, že u některých jiných aplikací, nebo prostě jen za jiné situace (možná automatické hledání nových aktualizací, nebo jen certifikátů) to může proběhnout odlišně. Podle mne v tom hraje roli právě to zda může IE komunikovat a pokud je nastavena proxy tak podle jakých pravidel.
Mám podezdření, že třeba mscrl.microsoft.com (který jsem z TOR-tunelu vyjmul) je služba běžící na nedostupném serveru, nebo není známa její adresa (tady se myslím již IP nepoužívají). Ale kupodivu pokud selže přímé (skrze ISP) stažení CRL, tak služba Windows Update zajistí nějak získání jinou cestou (zřejmě stejnou jakou se stahují samotné aktualizace). Osobně se mi ten TOR-tunel nelíbí, protože v poslední době vydím nustále jen komunikaci na portu 80 (serverů nabízejích službu), kdežto dříve bych přísahal, že šlo většinou o 443 (předpokládám tedy zabezpečené připojení).
Navíc jsem včera narazil na problém ne-MS aplikace (Media Player Classic - Home Cinema) u které jsem také přesně nepochopil jak komunikuje při získávání aktualizací. Je schopná domovský server sama kontaktovat (i když ve firewallu nemá vytvořené pravidlo), ale při zakázané komunikaci IE již není schopná se domluvit zda existují aktualizace. Problém je totiž v tom, že pro zjednošuení jsem povolil komunikovat všem službám které jsem v systému povolil a v tomto se perfektně zorientovat je docela problém.
Prostě to bez dlouhodobého monitorování a vytváření si funkčního modelu, odpovídajícímu mému současnému nastavení, zřejmě nepůjde. A pravděpodobně by bylo vhodné analyzovat i skutečnou komunikaci s danými servery, ne jen sledovat kdo se kam připojí. Na to zatím nemám dostatek znalostí ani čas. To je chaos, co? Časem se s tím nějak poperu a zkusím to zjednodušit.
P.S.
BITS zjednodušeně vím co umí, ale klidně ještě něco napiš, vždy se najde něco co nevím (MS je tajnůstkář jehož tajemství neodhalí ani celoživotní hacking větších machrů než jsem já). Co dělá ten "NetSh Interface PortProxy"? Jak je to s tou změnou metriky (routování) u tereda?
P.P.S
Hele možná se v tom ale plácám úplně zbytečně. Zamotal jsem právě do smyšlených představ, které vznikly na základě několika špatných pozorování. Jestli myslíš, že víš jak Windows Update funguje a jak je využíván aplikacemi, a není to složité popsat, tak to prosím popiš.
Zatím díky Lol-ovi i tobě za reakci.
-
Ahoj, tak dlouhé eseje na mě nemůžeš :D.
Co se týče nastavení Proxy v IE, tak je docela možná, že to dělá bordel (ve firemní sféře sem to nevypozoroval, ale tam se WSUS chová a ovládá jinak než doma, respektive doma se dotazuje drtivá většina uživatelů Windows přímo serverů MS, respektive jak si zmínil - Akamai, na ně se zapomněl, přitom se je kdysi musel explicitně ve firewallu povolit, ale to je tak 3-4 roky zpět).
Media Home Cinema komunikuje na 80, tudíž je těžké ji odchytit (zároveň je závislá na nastavení Proxy v IE, takže když zakážeš 80 port anebo nastavíš Proxynu, tak ano, může to tenhle program zmást).
Co se týče hlubšího popisu BITS, WSUS, tak se to mohu pokusit popsat (ale bude to na dýl a taky je nutné počítat s tím, že díky tomu, že MS technologie nejsou open-source, tak to mohu popsat jen z vlastní zkušenosti a praxe).
-
Napiš. Cokoli co mne o čemkoli poučí... budu se těšit.
Co se Windows Update skrze TOR-tunel týká. Ještě jsem původně chtěl vypnout protokol HTTP 1.1, ale nechci si přidělávat práci. Takhle jdou prakticky vždy všechny související požadavky ze stejné IP adresy. Kdo ví co by to dělalo, kdyby šel každý požadavek sólo, určitě by se stalo, že by alespoň některé přišly z odlišných adres.
Mimochodem, vůbec nevím zda nastavení IE má v tomto případě vliv na zbytek systému. To je další věc která způsobuje chaos. Některá nastavení týkající se IE jsou prostě svatá/přebírána pro celý systém.
-
Chybí mi kus skládačky.
Standardní nastavení firewalu (veřejný profil) je povolit veškerou odchozí komunikaci. Toto pravidlo jsem pochopitelně zrušil již dávno, ale protože se domnívám že Windows Update nepatří ani do "základních síťových služeb", ani do "služby Core Networking", ani do "vzdálené pomoci" měl jsem pro ni vytvořeno speciální pravidlo, později nahrazeno pravidlem pro povolení odchozí komunikace všech služeb (tedy těch povolených v systému). Teď jsem tuto komunikaci zakázal ale Windows Update funguje bez jakýchkoli problémů standardním způsobem dál. Nevíte o tom něco?
-
Nic mi nechybí. Kokot su. TOR-tunel má povolenou komunikaci a já Windows Update svedl do toho tunelu. Chaos mi to dělá, protože jeden firewall, který jsem používal kdysi dávno řešil komunikaci i na jiné úrovni než firewall Windows. Na otázku zapomeňte. Díky.
P.S.
Přesně takhle vzniká ten špatný model. Opravit svoje vlastní chybné úsudky je někdy nadlidský výkon.
-
**Myslím, že Windows/Microsoft Update probíhá zhruba takhle:**
Počítač (schválně zatím neuvádím konkrétní služby, pokud máte jistotu doplňte) kontaktuje servery Akamai (v podstatě jde o servery "download.windowsupdate.com" a "ds.download.windowsupdate.com"), jako servery na jemu známých IP adresách (jak se tyto adresy získávají, případně kde se uchovávají či jak se aktualizují nevím), skrze jejich porty 80 a zeptá se jich na adresu serveru Microsoftu (jde o server "update.microsoft.com"), se kterým pak komunikuje skrze jeho port 443.
Od toho serveru Microsoft Update pak počítač obdrží informaci, že má stáhnout to nebo ono a z jaké IP adresy. Toto stahování, nebo komunikace může probíhat jak přes porty 80, tak porty 443 serveru poskytujícího aktualizaci.
Do tohoto procesu má zřejmě co kecat aktuálnost "Microsoft Certificate Trust List Publisher (CTLs)", jejichž seznam se aktualizuje ze serveru "ctldl.windowsupdate.com" (opět Akamai). Zda a jak se překládají jména v tomto případě nevím. Pro funkčnost aktualizace seznamů musí být službě Windows Update povolena odchozí komunikace firewallem, ale skoro bych přísahal že stahování zajišťuje IE.
Aktuální CTLs musíte mít i pro spouštění celé řady certifikovaných aplikací. CTLs je známý také jako známý také jako "Microsoft Root Certificate (program)".
Jaký je rozdíl mezi "ctldl.windowsupdate.com" a "ctl.windowsupdate.com" netuším, ale zdá se že "ctl.windowsupdate.com" není server Akamai a zřejmě jde o jediný server. Možná se z něj nestahují žádné listy, ale provádí se k/proti němu dotazy. Zda je nutné nebo vhodné vytvořit nějaké pravidlo pro komunikaci s ním netuším.
**Další zajímavá a do jisté míry související může být komunikace se servery:**
• "crl.microsoft.com" (server Akamai, zřejmě revokace pro certifikáty vydané Microsoftem pro třetí strany)
• "mscrl.microsoft.com" (zřejmě revokace vlastních certifikátů Microsoftu, vydaných pro své vlastní potřeby)
Bez ověření odvolání certifikátů není možné některé procesy (třeba instalaci nových aplikací nebo aktualizací) dokončit. Tato komunikace se zdá probíhat skrze IE (je-li tento kanál ve firewallu otevřen), nicméně URLCache je jen podmnožinou spravovanou CertUtil, takže by to snad mohlo fungovat i samostatně, nebo ve spojitosti s jinou službou.
**Komunikace s těmito servery je zcela v režii IE:**
• "ie9cvlist.ie.microsoft.com" (seznam Kompatibilního zobrazení pro aplikaci IE9, možná i IE10 a IE11)
• "urs.microsoft.com" (Služba SmartScreen)
**Systémový čas:**
"time.windows.com" (jeden ze serverů pro aktualizaci času ve Windows)
**Poznámky k WinHTTP Proxy:**
• Pro nastavení musí mít uživatel práva správce.
• Nastavení WinHTTP Proxy lze importovat z nastavení IE Proxy daného uživatele.
• Při importu nastavení z IE Proxy je třeba dávat pozor zda se importovalo nastavení pro "místní síť" a nebo pro "telefonické připojení a VPN". Pokud totiž není "telefonické připojení a VPN" zrovna aktivní, automaticky je importováno nastavení pro "místní síť". Samotná WinHTTP Proxy má jen jedno nastavení platící pro všechna připojení.
• Kromě parametrů které uvádí nápověda je patrné, díky možnosti importu nastavení z IE, že lze ještě definovat přinejmenším ftp=, sock=
• Parametr "localhost" je použitelný
• Jaká je souvislost se službou WinHTTP WPAD (Win HTTP Auto Proxy) nevím
Doplňte, upřesněte, napomínejte! Jak je-libo, ale ať to má nějakou úroveň a ať se u toho taky člověk něco dozví.
P.S.
Jak se na Root-u používá HTML syntaxe?
-
Jak se ve Windows Vista/7 (snad i 8) dá povolit/blokovat odchozí PING a TRACERT na firewallu? Nechci slyšet o protokolu. Chci slyšet která ze služeb to je. Vytvořím nové pravidlo a povolím/zakáži službu ...
Díky. Je jich na mne moc a zatím jsem se netrefil.
-
Celkem by mne zajímalo k čemu přesně zamýšlel Microsoft tu WinHTTP proxy použít? Protože takhle jak je to vymyšlené se uživatel připraví o řízení komunikace na Firewallu. Pokud myslíte, že to používám špatně, nebo jsem něco nepochopil, nenastavil, nepřesměroval tak mne opravte.
Jak přesměrováváte, ideálně s nativními prostředky Windows, komunikaci vy, abyste si zachovali detailní kontrolu nad tokem dat který spravuje Firewall.
-
Jak se ve Windows Vista/7 (snad i 8) dá povolit/blokovat odchozí PING a TRACERT na firewallu? Nechci slyšet o protokolu. Chci slyšet která ze služeb to je. Vytvořím nové pravidlo a povolím/zakáži službu ...
Díky. Je jich na mne moc a zatím jsem se netrefil.
Zadna ICMP sluzba neni. A nechapu, proc to proboha blokovat???
Windows Firewall with Advanced Security > Outbound Rules> New Rule> Custom Rule> All Programs> Protocol type: ICMPv4 > Customize > Specific ICMP types > IP settings > Block Connection > Apply to Domain/Private/Public> Finish.
-
Zadna ICMP sluzba neni. A nechapu, proc to proboha blokovat???
Windows Firewall with Advanced Security > Outbound Rules> New Rule> Custom Rule> All Programs> Protocol type: ICMPv4 > Customize > Specific ICMP types > IP settings > Block Connection > Apply to Domain/Private/Public> Finish.
Díky za snahu Lole, ale nepsal jsem to "nechci slyšet o protokolu" pro nic za nic. To co píšeš ty je OK a každý to asi zná.
Od Vist dále má ping a tracert zabezpečen průchod standardně nastaveným firewallem (povolena veškerá odchozí komunikace, nastavení ICMP netřeba měnit).
Schválně si zkus zakázat tuto veškerou odchozí komunikaci, ponechej jen základní výchozí pravidla (snadno se to spravují centrem sítí). Ani si nepigneš ani nezjistíš trasu. Když povolíš odchozí komunikaci pro všechny služby dostaneš zpět komunikující ping i tracert.
Povolit všechny služby se mi zrovna nehodí.
Jenže těch služeb jsou mraky a zřejmě půjde o kombinaci několika z nich. Checkbox není dostupný. Zřejmě kvůli přehlednosti ručně definovaných pravidel, aby nemohly obsahovat na první či druhý pohled skrytou funkci. Podobně mi dávají zabrat dvě a více pravidel pravidel vzniklých kvůli různým protokolům.
Nikdo neříkal že chci něco zakázat. Prostě vím o situacích kdy je třeba toto povolit nebo naopak zakázat. Štve mne, že tak banální věc neznám a nemohu dostat snadno pod kontrolu. Nejde mi tedy ani tak o řízení vlastní komunikace (správu ICMP) jako spíše o detailní znalost funkce Windows.
Štve mne Microsoft, který neustále hrne dopředu s milionem zbytečností a dokumentaci, nebo alespoň vypouštění informací, zvládá stále hůře... Už jsem narazil i na to, že některé dokumenty byly staženy bez náhrady (začlenění informace jinam). Staré blogy vývojářů, alespoň obecně vysvětlující principy, tu také nebudou věčně.
Pravidelný redesign webu Microsoftu, s každou novou verzí Office či Windows, na přehlednosti také nepřidává. Připouštím, že knihovna Technetu je celkem konzervativní - snad až na ten zbytečný JS při hledání.
Proč bych si měl kupovat jejich nový SW systém, když jsem nestihl uspokojivě poznat ani vlastnosti jejich tři generace starého systému? Jediné co mne u Windows drží je to, že je celkem znám (a to sám vidíš jak mizerně) a že v těch systémech existuje určitá kontinuita v ovládání i v principech/technologiích. Protože jsem ale sklerotik, tak si neumíš ani představit jak rozsáhlou mám doma vlastní znalostní bázi - abych s tím krámem mohl vůbec pracovat. Když si představím, že bych měl stejným zkušebním obdobím projít znovu, u Linuxu, tak z toho mám osypky. Ale až se jednou naseru... tak ty Widle zahodím (i když nejspíš rovnou i s počítačem).
-
Zadna ICMP sluzba neni. A nechapu, proc to proboha blokovat???
Nejspíše měl na mysli echo-reply, echo-request a podobně (to zablokovat jide, nevím, jak to má nastavené Windows firewall, každopádně jde reject echo-reply nebo throw away echo-reply, prvni vrati "cilovy host odmitl dany packet" a druhy vrati "vypresel cas zadosti", ty zpravy z hlavy přesně nevím, akorát že u rejectu tazatel ví, že druhý konec existuje, u throw-away neví). Ve vnitřní síti mi to nepříjde účelné, ale mám to nastavené pro příchozí komunikaci zvenčí, už se párkrát stalo, že se mi někdo chtěl nabourat na nějaké služby.
K Windows Update - obecně celý systém je založen na registrech, takže tyto věci sou i v registrech uloženy (Linux registry nemá a i když je to položka, která dokáže časem zpomalit počítač,tak se přes ní dá ovládat téměř všechno ve Windows a to z jednoho centrálního místa, neberu samozřejmě v potaz aplikace, které registry nepouživají). Registry neobsahují přímý odkaz na Akamai nebo Windows Update servery (počítám, že to bude ukryto buď v nějakem configu nebo dllku), jen jaké je nastavení PC pro příjem updatů. Správně zmiňuješ certifikáty - systém se bez nich nezaktualizuje ba co víc, když mu posuneš datum na out of support (respektive end-of-support pro daný Windows, tak se ti nezaktualizuje a ještě bude na tebe něco řvát), proto se čas od času v aktualizacích objeví Aktualizace kořenových certifikátů. Jinak obecně k time.windows.com (nebo co to je) bych byl skeptický, ještě nikdy se mi nestalo, že by fungoval (respektive v doméně sem to řešil pomocí doménových řadičů). Jak sem psal, mohu vysvětlit, jak to tak nějak může fungovat, ale potřebuji na to čas (mám ve virtuálu připraven Windows server i klienta, ale nasimulovat chování Windows update s BITS na lokálu bude dost těžké, ne že by to nešlo, ale výsledky nebudou tak viditelné jako ve velké síti, budu to muset monitorovat Etherealem nebo něčím podobným, aby to aspoň šlo vidět v paketech).
-
Jinak tohle sem našel přímo na strńkách MS:
Control Panel / Windows firewall / Advanced settings (on left side) / Inbound rules / New rule (on right side) :
set "all programs" , protocol "ICMPv4" , ICMP settings click Customize button and choose "specific ICMP types / echo request. Choose "block".
Ale podotýkám, že tím zenmožníš funkcí všech programů, které toot použivají (a asi jich nebude málo, očekával bych, že jakýkoliv program, který se dotazuje na updaty, se na ně nedotáže, taky ti pravděpodobně přestane chodit internet, protože nebude korektně fungovat 3-way handshaking a pár dalších věcí).
-
*Místo inbound rules (příchozí pravidla) použij outbound (odchozí pravidla).
-
akorát že u rejectu tazatel ví, že druhý konec existuje, u throw-away neví).
Ale jiste ze to vi. Kdyz ten pakej dropnu, tak je uplne jasne, ze tam je firewall, ktery to zahazuje. Kdyby tam zadna masina nebyla, tak dostanu ICMP Destination Unreachable (ICMP Type 3) s kodem 0 - net unreachable, 1 - host unreachable atd.
Tohle zahazovani a blokovani ICMP je priserna hovadina.
-
"crl.microsoft.com" - Revokace certifikátů podepsaného SW Microsoftu.
"mscrl.microsoft.com" - V minulosti zřejmě revokace certifikátů podepsaných webů Microsoftu. Od roku 2013 je ale v těchto certifikátech vidět, že kopie CRL je umístěna i na serverech "mscrl.microsoft.com" a na jakémsi místě označeném "http://corppki/crl/..." Co to má představovat nevím, zda nějaké lokální úložiště korporátních systémů od MS?
"ctldl.windowsupdate.com" - Stahování CTLs funguje zcela jistě bez IE. Jak je to s "ctl.windowsupdate.com" stále nevím.
-
Ale jiste ze to vi. Kdyz ten pakej dropnu, tak je uplne jasne, ze tam je firewall, ktery to zahazuje. Kdyby tam zadna masina nebyla, tak dostanu ICMP Destination Unreachable (ICMP Type 3) s kodem 0 - net unreachable, 1 - host unreachable atd.
Tohle zahazovani a blokovani ICMP je priserna hovadina.
Když je mašina vyplá, a pokusíte se na ni pingnout, co dostanete za opdověď? Když pingnete IP adresu, která je nedostupná, co dostanete za odpověď? Když bude zahlcený síťový prvek v cestě, co dostanete za odpověď? Mám pokračovat?
-
Ješté dověetek - pokud ten packet dropne firewall, tak proč by měl dávat o tom vědět příjemci, to jako mu řekne něco ve stylu - hele já ten packet dropnul, protože to mám tak nařízené?, to torchu postrádá logiku. Najděte si na googlu rozdíl mezi drop (zahodí packet a a nedělá nic) a reject (yahodí packet a odešle destination unreachable). Tohle by mohli zvládat snad i ty nejlevnější krabičky.
-
Ufff, tak jsem se dnes konečně dostal k pročtení tohoto vlákna, celkem dlouho jsem se mu vyhýbal, protože jsem tušil, že v tom bude nějaká šílenost. :) Já jen doplním, že situace může být úplně jiná. Službu nemusel zaříznout BleskMobil, ale Telefonica pro BleskMobil, a pak je po technické stránce situace úplně jiná.
-
Ufff, tak jsem se dnes konečně dostal k pročtení tohoto vlákna, celkem dlouho jsem se mu vyhýbal, protože jsem tušil, že v tom bude nějaká šílenost. :) Já jen doplním, že situace může být úplně jiná. Službu nemusel zaříznout BleskMobil, ale Telefonica pro BleskMobil, a pak je po technické stránce situace úplně jiná.
Ale to já přeci vím, sám na to upozorňuji. Ona má Telefonica problémy i jinde, občas se sní někdo i soudí (vše jen proto že se snaží ušetřit tam kde na to neměla právo). Mne už teď problémy ISP nezajímají, ten problém jsem dávno vyřešil.
Teď se snažím vylepšit svoji znalost Windows a komunikace tohoto OS s domovskými servery. Podobných výpadků bývá více a řešívám je různě. Tunel pro specifické služby Windows jsem musel sestavit prvně. Je celkem zábavné dozvědět se něco o systému který roky používáte, těch drobných nejasností...
Snad jen jak to má telefonica s tím NATem. Klasický NAT to nebude, spíše firewall který některé služby z venku propouští. Třeba teredo client říká že za NATem není. Pokud ale například zkusím spustit TOR-relay, tak je moje IP detekována špatně a test by se provedl oproti IP adrese nějakého rozhraní ISP (adresa je dostupná i z mé strany, nejen zvenku z Internetu). Jak je možné že je moje IP detekována špatně nevím. Příjde mi to jako by požadavek na test neprošel klasickým TOR-tunelem, ale standardní cestou. Nikoho mezi sebou a prvním uzlem sítě TOR jsem ale nenašel. Zda se dostanu na své porty 80/443 z venku jsem zatím (v poslední době) nezkoušel.
-
Nikoho mezi sebou a prvním uzlem sítě TOR jsem ale nenašel. Zda se dostanu na své porty 80/443 z venku jsem zatím (v poslední době) nezkoušel.
A jak jste to skenoval mezi sebou a prvním uzlem TORu? Některé prvky mohou být skryté a jen "přihlížet", pak přihlížecí výsledky pošlou jinou cestou a tam se upraví.
-
Synchronizace času, komunikace s časovými servery.
- Je používán protokol TCP, nebo UDP. Jde o typ připojení "time" (obdoba http, https, socks, ftp).
- U WinHTTP Proxy můžete ručně nastavit server (např.: netsh winhttp set proxy "localhost:??" bypass-list="<local>", nebo definovat co s jednotlivými typy připojení (např.: netsh winhttp set proxy proxy-server="http=localhost:??;https=localhost:??;ftp=localhost:??;socks=localhost:??;time=localhost:??" bypass-list="<local>". Také můžete importovat nastavení z IE, zde není pro typ "time" kolonka.
- Zdá se, že WinHTTP Proxy je schopno zpracovat typ připojení "time", ale můj HTTP/HTTPS proxy server pro TOR ani samotný TOR (tedy skrze "socks") nejsou zřejmě schopni s tímto typem připojení pracovat.
- Je tedy zbytečné dávat časové servery do vyjímek pro úplnou proxy (tedy ne pouhou HTTP proxy).
- Pokud se komunikace s časovými servery nedaří, je naopak potřeba zkontrolovat nastavení firewallu a případně přidat povolující odchozí pravidla pro službu "Systémový čas" (u 32-bit Windows: W32Time) pro protokoly TCP a UDP.
- Pokud řešíte naprostou anonymitu, zakažte automatickou synchronizaci času, nebo zkontrolujte kdy k ní má dojít.
-
Možná se někdo rozhodnote vypnout automatické aktualizace, nebo automatické zjišťování aktualizací (ať již s automatickým stahovováním, nebo bez něj). Potom vás možná začne otravovat Centrum zabezpečení. Nevím jistě jak mají jaké verze Windows ošetřeno vypínání kterých varování... V každém případě, řešením je změna hodnoty klíče registru
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center]
"AutoUpdateDisableNotify"=dword:00000001
Aby se změna projevila ihned, spusťte Centrum zabezpečení, stačí jako obyčejný uživatel, a změňte způsob upozornění na jakoukoli hodnotu.
-
To Tunelář: Připravuj video s nastavením a konfigurací WSUS, snad ti to trochu přiblíží jak fungují updaty na Windows, uvídm zda to bude koukatelné), pak ho uploadnu nejspíše na youtube. Jinak obecně to bude takový malý úvod i do Windows domény (do týdne by mělo být hotové).
-
Pokud to někoho zajímá, tak Windows Update už zase funguje. Nevím jak dlouho, ale poslední dva dny to funguje.
Pro změnu jsem několik posledních dní zaznamenával snahu blokovat vícenásobné připojení ke stejnému serveru (šlo o šifrovaná připojení na první TOR uzel), ale zdá se že i to se pozvolna uklidnilo. Což je dobře, protože pro mne je odezva neúnosná a ISP taky musí pěkně zahlcovat když vznikají desítky-stovky nových připojení každou minutu jen proto, že někdo rozbíjí/zahazuje navazovaná spojení.
P.S.
Jestli někdy Withy to video, nebo poznámky dotvoříš tak sem nezapomeň dát ten odkaz. Díky. Ale nespěchej, radši si užij babí léto a podzim - já tohle roční období miluji.
-
V minulosti jsem nadával na svoji neschopnost pochopit správnou funkčnost a zmiňoval jsem časovou prodlevu při změně pravidel pro WinHTTP Proxy...
Teď se pokusím objasnit jinou část problému, další kamínek do mozaiky. Zatím stále (možná ještě více) platí, že Microsoft patří umlátit maličkým kladívečkem - aby to trvalo dlouho a hodně to bolelo.
***
Velmi snadno se dá u různých systémů Windows dosáhnout drobnou změnou nastavení naprosto odlišného chování. V některýh případech (zatím to nejsem schopen písemně rozebrat) platí, že určité části/komponenty Windows se řídí nastavením proxy serveru pro IE. Toto nastavení, samo o sobě, má zřejmě také několik naprosto nepochopitelných omezení. Tady jsou některá z nich:
- do výjimek nelze zadat jen "hlavní" doménu a spoléhat že se to vztahuje i na subdomény
- pokud použijete pro subdomény předpis hvězdička - tečka - "hlavní" doména, tak se zase nevztahuje na "hlavní" domény
- hvězdičkovou konvenci lze pravděpodobně použít jen v první úrovni (u "první" subdomény), složitější řetězce s vícero "tečkami" se chovají špatně popsatelně
Příklad:
Zakažte firewallem odchozí komunikaci pro IE. Nastavte IE proxy skrze TOR tunel, povolte firewallu propouštět komunikaci TOR tunelem a spusťte TOR. Nastavte IE tak aby k internetovým adresám automaticky nepřidával subdoménu WWW ani žádnou jinou. Zakažte vyhledávání z adresního řádku.
Do výjimek proxy serveru zadejte "seznam.cz" (poznámka: Seznam provádí automatický redirect na adresu www.seznam.cz).
Zadáte-li do adresního řádku "seznam.cz" tak, protože firewall nedovolí IE komunikovat, komunikace se serverem bude neúspěšná a vše skončí chybou. V případě, že jste vyhledávání z adresního řádku nezakázali, tak se vyhledávač (skrze TOR tunel, protože jeho adesa není ve výjimkách) pokusil najít heslo "seznam.cz".
Zadáte-li do adresního řádku "www.seznam.cz" tak IE skrze TOR tunel načte web na této adrese.
Nyní do výjimek proxy serveru zadejte "*.seznam.cz".
Zadáte-li do adresního řádku "seznam.cz" tak IE skrze TOR tunel bude kontaktovat server "seznam.cz", a ten ho přesměruje na svoji subdoménu "www.seznam.cz", ale toto spojení (již neuskutečněné skrze TOR tunel, kvůli výjimce) bude blokováno firewallem.
V případě zadání adresy ""www.seznam.cz" web načtený skrze TOR.
P.S.
No nebylo by hezké kdyby se nastavení proxy serveru IE, týkalo opravdu jen IE a ještě byla konvence v definování výjimek nějak rozumově uchopitelná a hlavně funkční (odpovídala skutečným potřebám uživatelů)? S tímto problémem souvisí i dříve zmíněná vlastnost, že pokud je komunikace IE firewallem povolena probíhá někdy jinak. Vůbec si ale nedovoluji hlubší výzkum tímto směrem.
-
Jde sice o Windows 8 a IE11, ale je tu zmíněna spousta zajímavých věcí i narážek na to jak to ve Windows vlastně fungovalo a funguje nově. Skoro jako by autor četl mé nářky a reagoval.
http://blogs.msdn.com/b/ieinternals/archive/2013/10/11/web-proxy-configuration-and-ie11-changes.aspx