Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 262 263 [264] 265 266 ... 375
3946
Ach jo. Docela mě mrzí, že vaše povědomí o bezpečnosti je takové jaké je. Jen doufám, že neprovozujete žádné webové služby. Nebo aspoň takové, kde byste mohl svým zákazníkům spíše uškodit. Nebo s tímhle přístupem raději žádné.
Tahle fáze je vždycky zábavná. Přijde někdo, kdo předvádí znalosti, jako by si právě přečetl knížku „Učebnice něčeho pro zelenáče“, a začne se pohoršovat nad tím, jak to všichni kolem dělají špatně. Přičemž obvykle není schopen to podpořit žádnými argumenty a protiargumenty ostatních nechápe, protože to v učebnici pro zelenáče nebylo.

Podle vás jsem měl obsah sdělení přepsat sem? Primárním účelem bylo varovat
Ono by vám to jedině prospělo, kdybyste měl jednou větou zformulovat, v čem je problém.

Jinak by asi bylo dobré uvědomit si, že tohle je diskusní fórum. Na diskusním fóru se diskutuje, neslouží k varování. Diskutovat se dá třeba o tom, jestli to, co vy považujete za chybu, je opravdu chyba. Jenže to byste musel napsat, že to a to považujete za chybu z toho a toho důvodu.

chce provozovat v Azure aplikaci na App Service, aby věděli, že pokud si nezabezpečí svoji aplikací tím, že ji napíšou správně (a věřte, že to nejde a vždy se najde nějaká chyba)
Nikoli. „Zabezpečit aplikaci“ v tomto případě znamená zajistit, aby s její pomocí útočník nemohl zapsat na server soubory, které by mohl server nebo klient interpretovat. To není zas až tak těžké, resp. programátor se musí trochu snažit, aby takovou chybu vůbec vyrobil. Pokud takovou chybu někdo vyrobí, je to proto, že na bezpečnost úplně kašle – a pak bude mít v aplikaci nejspíš ještě spoustu jiných bezpečnostních chyb, před kterými ho server zachránit stejně nemůže.

Ostatně je to vidět i na vás, kdy jste si sice uvědomil riziko interpretace kódu na serveru, ale úplně jste pominul riziko interpretace kódu (např. JavScriptu) na klientovi.

aby si by byli vědomi toho, že pomocí téhle zranitelnosti budou útočníci schopni v rámci daného oprávnění IIS udělat úplně všechno. Vykrást databázi, bezpečnostní klíče i vlastní  kód aplikace. A bohužel, mnohem hůře, vydeployovat si svou aplikaci a např. phishovat hesla.
Ne pomocí téhle zranitelnosti, pomocí té chyby v aplikaci. Víte, jak řeší WordPress ty autoaktualizace, když web server nemá práva zápisu do souborů webu? Vyžádá si od váš přihlašovací údaje pro FTP přístup a aktualizuje se přes něj. Ve vašem pojetí je FTP přístup „zranitelnost serveru“, přes kterou může útočník získat kontrolu nad serverem a v rámci jeho oprávnění udělat úplně všechno. Ano, je to tak, a proto se přístup k FTP drží v tajnosti a proto se neumožňuje komukoli zapisovat do souborového systému web serveru.

Ano, je rozumné umožnit správci serveru zakázat uživateli, pod kterým běží ten server, zápis do souborového systému. Pokud to aplikace nepotřebuje, může si to její správce nastavit jako další vrstvu ochrany – třeba jako hashování hesel. Ale není to primární ochrana. Když zakážete zápis do souborového systému, a nějaká aplikace ho bude potřebovat, bude si příslušná data místo toho ukládat do databáze – a jsme tam, kde jsme byli, když to bude napsané špatně, umožní to útočníkovi spouštět kód v kontextu webového serveru nebo prohlížeče.

upozornit na to, jak Microsoft reaguje na oznámení o bezpečnostních hrozbách
Poslali vás do háje? To by byla adekvátní reakce na někoho, kdo sotva pochytil nějaké základy, a hned sebevědomě tvrdí, že tam mají vážnou chybu, a nenechá si to vysvětlit.

s mým blogem to nemá nic společného. ten blog jsem založil jen kvůli tomu, abych tam zveřejnil tuhle zranitelnost. To až potom jsem se rozhodl přidat tam i další příspěvky.
Naopak, váš původní komentář je čistě jen propagace toho vašeho příspěvku na blogu. Z obsahu toho „diskusního“ příspěvku jsme se nedozvěděli nic, akorát pod čarou se dalo tušit, že zase další zelenáč zavítal do oblasti bezpečnosti, zaregistroval nějaký úplný základ a na jeho základě učinil objev, se kterým se hned musí pochlubit – místo aby se pokorně snažil to celé pochopit. Po rozkliknutí odkazu (udělal jsem to, až když tady byly nějaké komentáře – ráno jsem ten příspěvek rovnou nahlásil jako spam a odkaz jsem ani nerozklikával) se tušení potvrdilo.

zjistit, kolik lidí má o takovou informaci zájem
K informaci to má hodně daleko. Aby to byla informace, musel byste se oprostit od představy, že jste objevil bezpečnostní díru, a místo toho pro ostatní zelenáče popsat, že dovolit uživatelům vytvářet na serveru obsah je vždy rizikové. A že jedním z rizik je, když uživatelům dovolíte na server nahrávat soubory – že je pak potřeba si ověřit, jak je server nakonfigurovaný a co s těmi soubory bude dělat – na základě jejich umístění, názvu, obsahu.

kolik si jí zhruba přečete
Právě proto jsem na ten odkaz původně neklikal. Musíte si ale uvědomit, že když lidé klikají na odkaz, nevědí ještě, co je na cílové stránce. Takže když si přečtou to, co jste v úvodním komentáři napsal, mohou se řídit jenom tím – takže na odkaz kliknou ti naivnější, kteří si myslí, že je to o bezpečnostní díře v Azure AppService, a pak na to klikne ta většina, která se chce pobavit tím, co zase vyplodil někdo, kdo umí změnit obrázek na ploše Windows, tak už si o sobě myslí, že je bezpečnostní odborník.

I kdyby to mělo mít 1% dopad na povědomí o výše uvedeném nebo zvýšení povědomí o bezpečnosti obecně, je to pro mě obrovský úspěch.
Ano, kdyby tohle způsobilo zvýšení povědomí o bezpečnosti, byl by to opravdu nečekaný úspěch. Zatím to ale vypadá, že pro zvýšení průměrného povědomí o bezpečnosti můžete nejvíc udělat tak, že se budete sám vzdělávat.

A proč bych vás měl vodit za ručičku. Vy neumíte číst? Nebo použít Google?
Nejde o to, abyste za ručičku vodil mne. Jde o to, že kdybyste se to pokusil vysvětlit, třeba by vám došlo, že toho o problému zas tak moc nevíte a že si to nejdřív musíte lépe nastudovat.

Zjevně ano, když reagujete na něco, o čem, zase - jako jiní reagující, nic nevíte a předem si nic nezjistíte.
No, pokud jde o úroveň znalostí, jste v této diskusi na chvostu vy. Jsou tu i jiní diskutující, kteří jsou v obraze podstatně lépe než vy.

App Service je služba typu SAAS. To je software as a service. I když v tomhle případě je to mnohem více, zahrnul bych to do téhle kategorie. To znamená, že o komplet podvozek se vám stará provozovatel. Nicméně, u takového typu služeb máte jen minimální možnost, jak něco nakonfigurovat. A vězte, že tam rozhodně nemáte roota. Výhoda této služby je, že skutečně jen deployujete aplikaci a nemusíte se starat o instalaci, konfiguraci, ale hlavně zabezpečení a aktualizace celého toho ansáblu, který je k provozu vašeho businessu potřeba.
Jenže provozovatel se stará o vše od úrovně webového serveru níž. Samotná webová aplikace už je vaše starost, a to včetně zabezpečení. Tam vám provozovatel SaaS žádným způsobe nepomůže a musíte prostě počítat s tím, že veškerá práva, která máte jako provozovatel aplikace, můžete chybami ve vaší aplikaci zpřístupnit i útočníkům. Když v té aplikaci budete mít chybu SQL injection, může útočník manipulovat s databází – a není to chyba provozovatele webového serveru, ale chyba vaší aplikace. A když tam budete mít chybu file injection, je to zase chyba vaší aplikace.

máte 777 na wwwroot
Což nutně nemusí být chyba.

První pravidlo bezpečnosti je, že neexistuje žádná obecná bezpečnost, kterou buď máte nebo nemáte. Vždy se jedná o zabezpečení konkrétní aplikace, kterou musíte zabezpečit tak, aby dál poskytovala služby, které poskytovat má. Pokud ta aplikace má umožňovat nahrávání souborů na server, je samozřejmě obtížnější to zabezpečit – ale pokud to dělat má, tak je holt potřeba se tomu zabezpečení věnovat.

default admin admin
To je úplně něco jiného, k tomu není žádný důvod a pokud je tohle přístupné z venku, není to žádné zabezpečení. To, že může webový server zapisovat soubory, které může následně číst a případně interpretovat, samo o sobě žádná chyba není.

Opět. Další. Nic o tom nevíte a píšete. Proč si o tom nejdříve něco nepřečtete
Vy jste s tím začal.

Azure není obecný web server.
Ne? Vy tam nemůžete nahrát libovolný soubor, který od následně bude servírovat klientům? Už jen to samo o sobě by na funkci „obecný web server“ stačilo.

A jak jsem na to přišel? Asi tak, že jsem si s tím hrál a přečetl jsem si spoustu dokumentů jak o funkčnosti, tak o zabezpečení. A věřte, že je to moc pěkné čtení. Asi tak jako když vám šmejdi nabízí hrnce. To se taky pěkně poslouchá.
Pak byste si měl také přečíst nějaké základy. Třeba o tom, že za bezpečnost každé aplikace je zodpovědný její autor, a nikdy není možné zabezpečit aplikaci jenom tím, že pro její vytvoření nebo provoz použijete nějaké nástroje. Ty nástroje vám mohou pomoci (např. když se pro přístup k SQL databázi standardně používá binding parametrů a ne skládání stringů), ale nikdy bezpečnost nevyřeší za vás.

Já to právě, a asi i boužel, chápu moc dobře. Jenže ta autoaktualizace musí být spuštěná z důvěryhodných zdrojů, důvěryhodným uživatelem a ideálně odděleně od "nedůvěryhodného" (nebo raději méně důvěrného, aby mě zase netahal někdo za slovíčko).
Ne, bohužel to asi nechápete vůbec. Autoaktualizace znamená, že a aplikace aktualizuje sama sebe, s těmi oprávněními, které má jako webová aplikace, a dělá to automaticky, bez zásahu uživatele. Ano, je to šílené, je to berlička pro situace, kde neexistuje rozumná správa software, ale bohužel se tenhle mor z Windows šíří i na jiné systémy.

Správně je to tak, že autoupdate proces běží pod separátním účtem, stáhne si co potřebuje a aktualizuje wwwroot.
Ano, jenže to už pak není autoupdate (kdy aplikace aktualizuje sama sebe), ale běžný update správcem aplikací.

Protože nejdříve by se měla udělat revize a testování aktualizace ze všech pohledů, než se vůbec nasadí. Na wordpressu je o tom celý ansábl dokumentů, jak to dělat správně a bezpečně. Já to nečetl. Nemám ho rád. A naštěstí jsem ho nikdy nemusel deployovat nebo s ním něco dělat.
WordPress obvykle neprovozují lidé, kteří by byli schopní dělat nějaké testy před nasazením. Tam je úspěch to, že se to zaktualizuje dost rychle samo, takže těch nezabezpečených WordPressů není tolik, kolik by jich mohlo být. Ano, autoaktualizace jsou velmi špatné řešení, ale pořád výrazně lepší, než neaktualizovaný WordPress. To, že se prosadil zrovna takhle děravý systém, mne vůbec netěší, ale když už to tak dopadlo, je potřeba aspoň minimalizovat škody.

Mimochodem, přečetl jste si ten dokument, na který odkazuji v blogovém příspěvku? Hardening WordPress?
Pořád mne fascinuje, že si někdo přečte jeden článek někde na webu, a hned se považuje za experta.

Máte to napsané i v tom vlastním zápisku. „standard 755/644 respectively“ Víte, co znamená pro vlastníka adresáře práva 755? Důležitá je ta sedmička, a ta říká „právo pro čtení, zápis a procházení adresářů“. Pro soubory ta šestka znamená „čtení a zápis“. Víte, kdo je typicky vlastníkem těch souborů WordPressu? Uživatel, pod kterým běží webový server. V případech, kdy to tak není, musíte pro adresáře, do kterých WordPress dělá upload, nastavit práva jinak, aby tam mohl i ten webový server zapisovat. Což se v té příručce pro zelenáče nedozvíte, tam je jenom ten úplně nejjednodušší postup. Víte, co to celé znamená? Že ty webové servery, na kterých běží WordPress, jsou typicky nakonfigurované právě tak, jako Azure AppService – tedy že uživatel, pod kterým běží web server, má právo zápisu do oblasti, odkud web server servíruje obsah a odkud také spouští skripty. Díky tomu bylo třeba docela snadné do WordPressu naprogramovat tu autoaktualizaci nebo instalaci pluginů přes webové rozhraní, díky tomu se WordPress může „instalovat“ (ona je to spíš konfigurace) přímo přes webový prohlížeč. Ono by to šlo i bez toho, ty soubory by se ukládaly do databáze a interpretovaly odsud, ale to by jednak omezilo kešování na straně webového serveru, ale hlavně by to bylo ještě náchylnější na bezpečnostní díry, než současný WordPress. Takže díky za ta práva -w- na těch webových serverech.

Víte, ono to není o tom, že si přečtete půlku informací (nebo vlastně spíše žádné, ty se obvykle hledají, až když clověk neví jak dál), stáhnete si worpress, vyklikáte si tři volby v instalátoru a považujete svojí práci hotovou. Když to chcete brát vážně, je potřeba to nastudovat komplet. Že to je moc práce? Souhlasím. Nebo spousta let praxe.
Teoreticky to máte zmáknuté dobře. Tak teď ještě abyste se tím začal řídit.

3947
Akutualizace se da resit jen doplnovanim souboru, nemusi se prepisovat vubec nic. Implmentovano a provereno na tisicich nasazenich. A funguje o tak uz roky roukouci a ano jedna se o webovou aplikaci.
V mém komentáři nešlo ani tak o přepisování souborů, ale o změnu chování aplikace. Je celkem jedno, jestli tu změnu implementujete bez přepisování existujících souborů nebo dokonce bez zápisu souborů na disk (protože změny uložíte třeba do databáze).

Navíc pokud si řešíte routování v aplikaci kompletně po svém, pořád je tu možnost chyby v té routovací části aplikace, kterou bez změny souboru neodkážete opravit. Takže můžete aktualizovat velkou část aplikace, ale ne celou aplikaci.

3948
Hardware / Re:Koupě notebooku bez Windows
« kdy: 21. 05. 2017, 14:10:30 »
Asi budete muset upřesnit, co si představujete. CZC.cz má aktuálně v nabídce 71 notebooků bez Windows, z toho 18 zcela bez OS, Mironet 54 notebooků bez Windows, z toho 16 zcela bez OS.

Na takhle obecnou otázku je tedy odpověď: Ano, dá.

3949
Proc vzycky nekdo, kdo necemu nerozumi takhle hrozne machruje a sam si neuvedomuje, ze se strasne ztrapnuje?
Jediný z celé diskuse, na koho mi tohle tvrzení sedí, jste vy. A začalo to hned prvním příspěvkem, který je podle mého názoru jen komentářovým spamem – bombastický titulek, a pak nic, žádný dotaz ani doložené tvrzení, jenom odkaz na vlastní blog. Asi ten blog nikoho nezajímá, tak je potřeba přivést nějaké návštěvníky, které zajímá, co je to zase za nesmysl, že?

Mimochodem, nějak jste zapomněl vysvětlit, proč si myslíte, že Azure AppService je typ služby, kde by tohle mělo být ošetřeno provozovatelem služby a ne autorem aplikace. Normálně se totiž poskytují oba typy služeb – někdo vám poskytne čistý hardware nebo VPS a je zcela na vás, co si s tím uděláte. Máte na daném počítači roota nebo administrátora a je na vás, abyste si to zabezpečil. A nebo jsou na druhém konci škály služby, kdy vám někdo poskytuje nejčastěji konkrétní aplikaci (třeba GMail nebo Office365), a vy ji používáte jako uživatel – přičemž veškeré zabezpečení je na provozovateli té aplikace. Nevím, jak jste přišel na to, že Azure AppService má blíž k tomu druhému – podle mne bude obecný webový server vždy patřit do té první kategorie, tudíž je na tom, kdo tam nasazuje nějakou aplikaci, aby si zajistil, že je ta aplikace bezpečná – nejde vytvořit takový obecný web server, který zabrání nasazené aplikaci v čemkoli nebezpečném.

A k té poznámce na konec, jak jste nepochopil, jak funguje autoaktualizace webových aplikací, třeba WordPressu – pokud má ta aplikace umět zaktualizovat sama sebe, vždy musí mít právo na serveru přepsat soubory aplikace, které jsou „spustitelné“ webovým serverem. To je přece princip aktualizace – že původní aplikaci nahradíte novou verzí.

3950
Server / Re:Nelze odeslat mail z klienta
« kdy: 21. 05. 2017, 08:45:33 »
Tak proč většina poskytovatelu ma svuj poštovní servr?
Ze setrvačnosti. Protože před třiceti lety se předpokládalo, že internetové spojení je nestabilní, a tedy je dobré e-mail odeslat z klienta nejbližšímu serveru – protože se klient připojuje vytáčeným spojením přes modem a za chvilku bude od internetu odpojen, zatímco ten server je snad k internetu připojen přeci jen stabilněji a má čas řešit, kam e-mail poslat a řešit případné výpadky a opakování.
Jenže od té doby e-mail ovládl spam a viry, které používají k odesílání falešné adresy, a je tedy snaha adresu odesílatele ověřovat a přijímat e-maily jen od těch serverů, které danou adresu mohou oprávněně použít. ISP tohle nemůže zajistit (leda pro e-mailové adresy, které zákazníkům poskytne sám). Proto se pro odesílání e-mailů používají servery poskytovatele e-mailové adresy a proto jsou rozesílací servery ISP přežitek.

mit ho muze.. ale blokovat standardni port ? cas zmizet od toho ISP
U toho portu 25 se to ještě dá pochopit, i když i to měl ISP klientům oznámit a měl by umožnit nastavení výjimky. Ale u toho portu 587 to nedává žádný smysl, u toho se předpokládá, že si cílový server ověří klienta. Pokud někdo na portu 587 přijímá e-maily od kohokoli, je too jeho chyba.

3951
Software / Re:Otevření více stránek jedním klikem
« kdy: 20. 05. 2017, 14:23:08 »
Dejte si ty stránky v Chrome do jedné složky v záložkách a pak na tu složku klikněte pravým tlačítkem a zvolte „Otevřít všechny záložky“.

3952
Server / Re:Nelze odeslat mail z klienta
« kdy: 17. 05. 2017, 15:49:08 »
Tak to reklamujte u svého ISP. Port 587 je určený pro odeslání e-mailu svému poskytovateli e-mailových služeb. Je pak jeho starost, abyste přes něj nerozesílal spam. ISP do toho nemá co hrabat a nemá k tomu žádný důvod. (Do portu 25 by také neměl hrabat, ale tam se to ještě dá pochopit, protože to má nějaký důvod.)

3953
Pokud server nenaslouchá, spadlo by to už na TLS handshaku a nedostalo se to k SSL handshaku
Chvilku mi to trvalo, než jsem rozluštil, že to první měl být TCP handshake…

3954
Řešení: nahrát certifikát do cacerts na straně klienta a sice do jre\lib\security\cacerts, ledaže by bylo řečeno že jinam pomocí systémové proměnné javax.net.ssl.trustStore
To není moc dobrý nápad, protože pak tomu certifikátu/autoritě budou důvěřovat všechny javovské aplikace. A po aktualizaci JRE to musíte měnit znova.

V lepším případě umožňuje aplikace nakonfigurovat certifikát pro ten konkrétní typ komunikace. V horším případě to neumí a je potřeba určit truststore pro celou aplikaci – což se udělá právě pomocí té systémové proměnné javax.net.ssl.trustStore.

3955
Jak je v Synology nahrán OS? Na nějaké interní flešce?
Na těch discích, které do něj dáte.

3956
ma open FW, je OS open-source,...?
Synology má systém postavený na Linuxu, máte tam roota, pomocí ipkg si tam můžete instalovat libovolné balíčky.

3957
Dle mého tedy starý triviální http smysl má, u TLS spojení už by klidně http/2 mohlo zůstat.

Ničím jiným bych to nenahrazoval, protože tohle je poměrně jednoduché a interoperabilní.
Jak už jsem upozorňoval ve svém předchozím komentáři, ono  ani to „staré HTTP“ (1.1) není zas tak triviální. Jistě, pokud si řeknu, že budu používat jednoduchou podmnožinu HTTP, protože mám na obou stranách komunikace svůj software a můžu tak zaručit, že se používá jenom ta podmnožina, může to být velmi výhodné řešení. A může pak být dokonce výhodné napsat si pro to vlastního klienta a server, protože tím, že nebudu muset řešit některé záludnosti HTTP, můžu mít efektivnější kód. Ovšem je zase potřeba počítat s tím, že ta moje implementace bude mít mnohem méně testerů, takže je mnohem pravděpodobnější že tam budou nějaké chyby. A také musím důsledně zajistit to bezpečné prostředí – ne že budu tvrdit, že se tam používá HTTP, a pak se někdo, kdo nezná detaily aplikace, rozhodne, že vlastně kvůli zjednodušení může pár lidí jenom kvůli administraci pustit prohlížečem přímo na backend – vždyť je to přece HTTP.

A vždycky je otázka, zda se opravdu vyplatí psát vlastní řešení se všemi riziky z toho plynoucími, abych tím získal jedno procento výkonu – jestli nakonec není levnější v cloudu prostě nakoupit navíc to jedno procento výpočetního výkonu.


Problém bude v tom, že cokoliv nezabezpečeného se postupem času asi stane opravdu nebezpečným.
Na spojení backendu nešifrovaně mezi sebou a s edge TLS výstupem asi ideální stav.
Dneska je ještě běžné používat „uvnitř“ nešifrované spojení, ale myslím, že i tam se postupně bude přecházet na šifrování. Je to další stupeň zabezpečení, a není pak nutné složitě analyzovat, zda všechno, co je „uvnitř“, je opravdu dostatečně bezpečné. Ono je fajn, když můžete třeba při řešení výpadku komunikaci s backendem, která jde normálně přes bezpečnou síť, pustit přes internet, a nemusíte před tím řešit, že je vlastně nezabezpečená a je potřeba ji nejprve nějak zabezpečit.

3958
Mimochodem, nedávno jsem psal jednoduchého http klienta v C++ , měl 160 řádků i s komentářema. Nedokážu si představit, že bych psal http/2.0 klienta.
To asi bylo bez keepalive, co?

Pokud takové http stačí, tak je skutečně nesmysl byť jen uvažovat o http2.
No a taky asi bez komprese, bez chunked přenosu, bez podpory stovkových stavových kódů… Asi by bylo přesnější nazvat to „telnet klientem, který používá protokol připomínající HTTP/0.9“.

3959
Ale hlavně nevím, k čemu by bylo dobré Operu Mini pro J2ME pouštět na deskopu.
Třeba když vyvíjíš web, dostaneš bugreport, že v ní něco nejede, a nemáš kompatibilní mobil, na kterém by to šlo zkusit.
Tam je bohužel dost velké riziko, že se to v tom emulátoru na PC stejně bude chovat jinak, než na skutečném mobilu. Pak se honíte za chybami, které nastávají jen v emulátoru a na skutečném mobilu ne, a naopak nenasimulujete skutečné chyby reportované z mobilu.

Pokud už bych chtěl něco ladit pro Operu Mini, zkusil bych to nejdřív v té variantě pro Android. Předpokládám, že serverové zpracování bude stejné pro všechny varianty, a vykreslovací jádro by také mohlo mít alespoň stejnou architekturu.

3960
Windows a jiné systémy / Re:dotaz na hosts soubor v windows
« kdy: 07. 05. 2017, 08:52:23 »
konkretne

route -p add 96.30.5.209 mask 255.255.255.255 127.0.0.1
To ovšem není blokování komunikace, ale určení, že komunikace s IP adresou 96.30.5.209 se má navazovat prostřednictvím routeru 127.0.0.1. Co se ve výsledku stane závisí na dalších okolnostech.

Každopádně pokoušet se nahrazovat firewall routerem je dost šílený nápad a nechápu jeho smysl.

Stran: 1 ... 262 263 [264] 265 266 ... 375