Hlavní navigace

Názory k článku Použijte správný firewall pro ochranu své sítě

  • Článek je starý, nové názory již nelze přidávat.
  • 23. 3. 2010 16:05

    VViki (neregistrovaný) ---.bsc-ideas.com
    Děkuji všem odpovídajícím - nápad, realizovat "HTTPS Proxy" coby man-in-the-middle je jedna z jeotřesnějších věcí, co bych u produktu řešící zabezpečení čekal...

    Osobně by pro mě existence takové "feature" na seznamu podoporovaných "technologií" u firewallu byla zásadní překážkou k nákupu produktu (protože jak bych mohl důvěřovat implementaci ostatních zabezpečovacích funkcí s tímhle přístupem k bezpečnosti?). Kladné hodnocení už vůbec nechápu.

    VViki
  • 24. 3. 2010 23:57

    Aleš Kotmel (neregistrovaný) ---.static.adsl.vol.cz
    předem se omlouvám za následující větu, ale nemohu jinak: Pouze naprostý ignorant nedokáže nainstalovat Astaro Virtual Appliance pomocí Open Virtualization Format (OVF) souboru!

    Promiňte, ale muselo vám dát asi hodně práce naprosto ignorovat návod na instalaci do všech všeobecně používaných VMware prostředí která je krok za krokem kompletně popsaná v PDF souboru ASG_V7_Virtual_Appliance_readme.pdf na FTP serveru firmy Astaro -ftp://ftp.astaro.de/pub/ASG/v7/virtual_appliance/

    Ano, souhlasím s vámi že je daleko snažší napsat do recenze že instalace nefunguje, místo aby jste podle pravdy napsal že ani nejste schopen si najít a následně přečíst podrobný návod k instalci v PDF formátu, který je ještě navíc připojen k naprosto každé instalaci Astaro Virtual Appliance.

    Pro vaši informaci pro již zmíněnou instalaci pomocí OVF souboru musíte patnáctkrát kliknout myší aby jste kompletně nainstaloval Astaro Virtual Appliance.

    Jsem kdykoli připraven vám osobně demonstrovat jak je instalace Astaro Virtual Appliance jednoduchá a rychlá!

    A nyní k v diskusi velmi zmiňovanému filtrování HTTPS provozu. Opět jste se absolutně nenamáhal zjistit si relevantní informace, nebo čtenářům vysvětlit jak vlastní filtrování HTTPS provozu funguje. Prosím jděte na http://www.astaro.com/kb/ a do pole pro vyhledávání pouze vložte "HTTPS Filtering Feature Brief". Výsledkem vyhledávání bude soubor s již uvedeným jménem souboru ve kterém i vy sám naleznete odpovědi na veškeré otázky nebo nepřesnosti které byly následně zmíněny v diskusi.

    A nyní k vámi zmíněným nedostatkům na závěr vaší recenze Astaro řešení. Opět jste se absolutně nenamáhal zjistit si relevantní informace. Prosím podívejte se na http://feature.astaro.com a zajisté sám ke své velké nelibosti zjistíte že IPv6 bude plně implementována ve verzi 8, přičemž předpokládaný termín uvolnění verze 8 je v září tohoto roku.
    Jako jeden z hlavních vývojových cílů při vývoji nové verze 8 byl stanoven požadavek získání certifikace úrovně EAL4+. Jak tento vývojový cíl koresponduje s vaším závěrem recenze "Segment: malé a střední sítě s běžnými službami a se střední úrovní zabezpečení" když dlouhá léta je firma Astaro AG držitelem certifikátu od ICSA Labs?!

    Vážený pane Pecho, od samého počátku vašich článků o firewallech si stále dokola kladu otázku nakolik jsou vaše objektivně špatné články o firewallech pouze důsledkem vašich nevědových (nebo vědomých) neznalostí o firewallech nebo se jedná o záměrné poškozování konkurence z oboru bezpečnostních řešení?

    Prosím můžete se zde věřejně přihlásit k vaší příslušnosti k firmě Trusted Network Solutions, a.s., firmě která vyvíjí produkt KERNUN UTM?!

    Protože pokud se zde veřejně přihlásíte k příslušnosti k firmě Trusted Network Solutions není rozhodně možné považovat vaše články a recenze za nezávislý názor autora nebo recenzenta, ale pouze a jedině o nekalou obchodní soutěž.


    Ing. Aleš Kotmel
    jednatel společnosti Annex NET, s.r.o.
    distributor firmy Astaro AG pro Českou a Slovenskou republiku


    P.S. Všem slušným lidem se moc omlouvám za mé vulgární výrazy v úvodu mého příspěvku. Panu Pechovi se omluvit bohužel nedokážu.
  • 25. 3. 2010 13:48

    davro (neregistrovaný) ---.6.broadband13.iol.cz
    nechtěl byste prodávat radši něco jiného? Třeba bychom se od vás dozvěděli, že váš budoucí automobil bude umět létat.

    Vaše proklamace ohledně nové verze je úplně mimo, protože si ho dnes nikdo pořídit nemůže.

    PS: když už se vyjadřujete poměrně oficiálně jako zástupce firmy, tak si nechejte zkotrolovat pravopis, ať nevypadáte jako nevzdělanec.
  • 23. 3. 2010 11:59

    VViki (neregistrovaný) ---.bsc-ideas.com
    Může mi prosím někdo vysvětlit, jak může korektní HTTPS proxy něco (cokoliv) kontrolovat?

    Teče přes ni přeci šifrovaný stream dat, do kterých proxy nemůže vidět.

    Pokud by se data pokoušela rozšifrovat (tj. byla by koncem SSL tunelu), tak je nebude schopná zpět zašifrovaně předat dál klientovi a každá smysluplná implementace klienta je přeci musí odmítnout...

    VViki
  • 23. 3. 2010 13:43

    VViki (neregistrovaný) ---.bsc-ideas.com
    Že by HTTPS proxy komunikovala se serverem přes HTTP a pak to klientovi šifrovala (HTTPS), to mi přijde jako nesmysl - klient samozřejmě bude ověřovat, jestli URL v SSL certifikátu sedí s URL cílového serveru, což proxy nebude moct zajistit...

    VViki
  • 23. 3. 2010 15:21

    xpckar (neregistrovaný) ---.net.upc.cz
    podstrčena nějaká důvěryhodná CA
    =
    podstrčena nějaká CA nebo pseudoCA jako důvěryhodná

    Neboli sofistikovaný firemní man-in-middle
  • 23. 3. 2010 15:42

    mrak (neregistrovaný) ---.vscht.cz
    Vetsina techto reseni na kontrolu https co jsem mel tu "cest" videt dela nejaky man in middle
  • 23. 3. 2010 17:23

    davro (neregistrovaný) 2001:718:801:----:----:----:----:----
    Platnost certifikátu se imho dá zjistit i bez toho, aby dělal m-i-m, protože certifikáty se posílají nešifrovaně.
  • 23. 3. 2010 19:03

    x (neregistrovaný) ---.39.broadband10.iol.cz
    protoze jste zrejme nepochopil, stejne jako mnozi jini, ze se to pouziva _hlavne_ ve smeru "in" - tj. na strane site, ktera ma uvnitr prave ty svoje http servery, a ne ve smeru "out", tj. u odchoziho trafficu zamestancu ke svym bankam apod.
  • 23. 3. 2010 19:06

    Martin Kalenda (neregistrovaný) ---.klfree.cz
    +1


    už jsem myslel, že neumím číst. Cert nahraju normálně do zařízení a zvenku nikdo nic nepozná. Navíc bývají např F5 i akcelerované což je další plus.
  • 23. 3. 2010 20:18

    davro (neregistrovaný) ---.ics.muni.cz
    kecy v kleci, mrkněte se na web:

    A secure surfing session protects user data and privacy, but threatens the security of the company. Sites visited and files downloaded over HTTPS can contain malicious content that can enter the network while the security device remains blind. Astaro’s HTTPS filtering removes this unwanted network blind spot and gives you full visibility into this traffic.



    http://www.astaro.com/applications/web-security/https-scanning


    Jak z tohoto plyne nějaký frontend k https serverům mně není jasné.
  • 24. 3. 2010 8:18

    anonymní ---.anonymouse.org
    Ono staci vytahnout na nekoho jen ty logy, protoze stejne jako nevysvetlitelne najete kilometry s firemnim autem tak i komunikace s kubikem s horni dolni muzou vest k vyhazovu a je naprosto jedno kde jste s tim autem byl nebo co jste si s tim kubikem psal.

    A prosim odkaz na judikat te prohrane pre, abysme videli ze to bylo skutecne kvuli pouziti nelegalne ziskanych informaci.
  • 23. 3. 2010 22:32

    x (neregistrovaný) ---.39.broadband10.iol.cz
    ano je, napriklad pro FortiGate tady:

    http://docs.fortinet.com/fgt/archives/3.0/techdocs/FortiGate_Administration_Guide_01-30006-0203-20080313.pdf - strana 330, cast "SSL Offloading"

    - a naopak tam nikde nepisou ze by to umelo zachazet s https trafficem tak jak chcete vy (jenze ja narozdil od Vas samozrejme netvrdim ze to nejde jinak, a nebo ze se nenajdou pripady kdy by se to tak dalo pouzit)

    pro Astaro to podle vseho planuji na dalsi verzi (viz http://feature.astaro.com/forums/17359-astaro-gateway-feature-requests/suggestions/178298-http-reverse-proxy)


    kdyz jsem si ale znovu precetl clanek, tak tam je nespis opravdu myslena ta uzivatelska proxy kterou Astaro nejspis umi (a ktera zas takova prasarna to byt nemusi - to uz zalezi na impementaci)
  • 24. 3. 2010 0:10

    VViki (neregistrovaný) ---.bsc-ideas.com
    Aha, pokud jde o reverzní proxy, tak tam to smysl dává (i když osobně si myslím, že je vhodnější protáhnout chráněný kanál co nejdál k cílové serverové aplikaci).

    Pokud by ale mělo jít o klasickou proxy (nikoliv reverzní), tak je to zvrácená myšlenka. V mnoha případech nedokáže žádný software zkontrolovat, jestli SSL kanál je chráněný správným serverovým certifikátem. A tím, že zcela vezmu uživateli možnost certifikát ověřit, otevírám vrátka skutečnému man-in-the-middle útoku (nehledě na možnost odposlechu nechráněné komunikace ve vnitřní síti)...
    Pro mě jako uživatele se nasazení takového "proxy serveru" rovná znemožnění použití HTTPS.

    Podle mě je mnohem čistější řešení HTTPS obecně zakázat a povolovat je pouze pro cílové servery, kam se uživatelé prokazatelně potřebují dostat a kterým jako organizace důvěřuji...

    VViki
  • 24. 3. 2010 0:48

    x (neregistrovaný) ---.39.broadband10.iol.cz
    ja v podstate souhlasim s poslednim odstavcem, ale zase si na druhou stranu nemyslim ze by to proxy reseni nebylo rozumne realizovatelne (tj. s rozumnym snizenim bezpecnosti)

    - proxy server muze (mel by) overit ze vzdaleny certifikat je podepsany nejakou autoritou, ktere veri (ostatne stejne jako to dela browser) a pokud ne, tak spojeni dale nepustit nebo zobrazit nejakou error stranku

    - na klientske strane by pouzival certifikat narychlo podepisovany firemni certifikacni autoritou, kterou ma uzivatel naimportovanou ve svem browseru

    (tj. pri requestu na proxy podle CN z praveho certifikatu vygenerovat vlastni certifikat a ten podepsat - tady bych videl slabe misto v rychlosti generovani crt, ale to by zase bylo jen napoprve, navic by to imho mohlo jit castecne predgenerovat)

    to mi prijde sice ne uplne super, ale data necestuji nikde po siti v plain textu a zaroven ma uzivatel alespon trochu jistotu ze mluvi se spravnym serverem
  • 24. 3. 2010 13:06

    VViki (neregistrovaný) ---.bsc-ideas.com
    Kdyby byl svět ideální, tak byste mohl mít pravdu (ale pak by zas nemělo smysl používat HTTPS).

    Jenže svět ideální není a proto je tahle úvaha špatná.

    Pokud přistoupíte na řešení, které jste popsal, tak prostě ztrácíte kontrolu nad zabezpečeným kanálem a nedokážete jeho bezpečnost nadále posoudit.
    Nemůžete si být jistý, zda někdo na proxy server nedostal mezi důvěryhodné autority nějakou svou a nerealizuje man-in-the-middle útok ještě před proxy serverem. Nebo že nedělá totéž mezi proxy serverem a Vaším počítačem.
    Nemůžete se podívat, jaké algoritmy používá zabezpečený kanál mezi proxy a cílovým serverem (jestli jeho zabezpečení odpovídá Vašim požadavkům, bohužel, dnes už není zas takový problém podvrhnout za použití určitých algoritmů certifikát, který daná CA nevydala (ale podpis sedí)). Nebo jaké atributy má originální serverový certifikát (zda sedí EV atribut).

    Ve finále máte kanál, který >věříte<, že je zabezpečený. A špatné zabezpečení je horší než žádné (protože tam si každý případnou nebezpečnost uvědomuje).

    O nefunkčnosti klientské SSL autentizace ani nemluvím....

    VViki
  • 24. 3. 2010 13:29

    x (neregistrovaný) 89.187.132.---
    stejne jako Vy verite tomu, ze Vam nikdo do pocitace bez Vaseho vedomi nenainstaloval svoji CA jako duveryhodnou a nedela MITM nekde dal

    malokdo si pokazde overuje certificate chain, a to ze by si nekdo telefonicky overoval hash certikatu jsem jeste nevidel (a i kdyz urcite nekdo takovy existuje, tak to nebude ani promile lidi co https pouzivaji)

    btw. povezte mi, jak podvrhnete cerfikat s CN ktery Vam CA nepodepsala? hratky s UTF8? na to uz prohlizece nenaleti... brute force hadani klicu? good luck... jediny co slo, byl bug v ssl v debianu, ale to uz dneska taky nepouzijete

    ale jak uz tu nekdo psal, pokud se Vam tenhle zpusob zabezpecni ve firme nelibi, nikdo Vas nenuti to (obzvlaste k soukromym aktivitam) pouzivat. pokud firma takovou bezpecnosti politiku s vedomim rizik akceptuje, tak Vam do toho nic neni
  • 24. 3. 2010 13:42

    VViki (neregistrovaný) ---.bsc-ideas.com
    S tou důvěrou, to přeci není vůbec totéž - pokud se provádí kontrola až u mě, tak ji můžu prověřit.

    Já si taky vždycky certifikát neověřuju. Ale ten zásadní rozdíl je v tom, že to můžu udělat, když to bude charakter komunikace vyžadovat. Tady to tu možnost zcela odebírá. A tím to zabezpečení degraduje na víru.

    Co se týká podstrčení certifikátu - je to právě o těch algoritmech, o vytvoření kolizních certifikátů (tj. certifikátů, které budou mít stejnou hodnotu digestu).

    Nejde o to, že by se mi to nelíbilo, mě to přijde zvrácený :-). A jak jsem psal - produktu, jehož tvůrci mají takový přístup k zabezpečení bych prostě nemohl důvěřovat (protože jak už jsem psal, je pouze jedna věc horší než žádné zabezpečení a to je špatné zabezpečení, které dává lidem pocit falešného bezpečí).

    Ale já naprosto respektuju, že jiní lidé na to budou mít jiný názor (na druhou stranu, i když bude tisíc lidí vyfukovat cigaretový kouř do vody, zlato tím nevznikne ;-) ).

    VViki
  • 26. 3. 2010 15:11

    Aleš Kotmel (neregistrovaný) ---.annexnet.cz
    Dobrý den,
    články které jsem napsal a publikoval:
    Profesional Computing Softwarové firewally pro SOHO a SME, 2005
    Zabezpečte svůj e-shop, 2006
    Článek který jsem přeložil z anglického originálu a který jsem si dovolil z redakčních důvodů zkrátit a aktualizovat některé informace. Autorem článku je pan Udo Kerst z firmy Astaro AG:
    Security World Vzdálený přístup bez kompromisů, SSL VPN v porovnání s tradičním VPN řešením, 2008
    Aleš Kotmel
    Annex NET, s.r.o.
  • 29. 3. 2010 8:38

    Peter Pecho (neregistrovaný) ---.tns.cz
    Požiadavka na napísanie článku prišla od Lupy a k výslednému článku nemala redakcia námietky. Svoju príslušnosť k TNS som nijak netajil (viď. kontaktný email).
  • 1. 5. 2010 21:09

    bubu (neregistrovaný) ---.236.broadband5.iol.cz
    mno pokud by si chtel nekdo ověřit zmíněná tlachaní, a fakta bez nákladů tak jediné co se mi podařilo jednoduše donutit k download-u byl astrao.
  • 22. 6. 2012 12:58

    Fis (neregistrovaný) ---.trask.cz

    Me osobne prijde mnohem vetsi prasarna balit do HTTPS trafficu malware, viry, zneuzivat ho pro phishing ze strany serveru nebo napriklad P2P traffic ze strany uzivatelu. Bez ukonceni na proxy a opetovnem zasifrovani a duveryhodnem podepsani trafficu internim duveryhodnym klicem neni mozne se nijak uvedenym problemum branit. Obnasi to samozrejme dalsi bezpecnostni problemy s proxy serverem, ale obecne je toto reseni z bezpecnostniho hlediska jedine mozne a spravne.

  • 22. 6. 2012 13:04

    Fis (neregistrovaný) ---.trask.cz

    Podstatne jsou statistiky, ktere tvrdi, ze az 40% pracovniho casu lide travi jinak nez praci. A to neni jen z CR. Tak to proste je. A vite, kteri lide travi nejvice casu mimopracovnimi aktivitami? Presne takovi, ktere maji podobne reci jako vy.

  • 22. 6. 2012 13:09

    Fis (neregistrovaný) ---.trask.cz

    Souhlasim s vami, ale asi zalezi na implementaci. Pro vyjimky se dekrypce neprovadi vubec. Krome toho - co adminovi zabrani v MITM odchytavani provozu? Snad jen sptane svedomi, technicky to neresi v podstate nic. Ve vetsich firmach rozdeleni roli, v mensich je to v kyblu. Proto je nutno alespon vse bezpecne logovat, idealne tak, aby s logy nemohli administratori nijak nakladat.

  • 23. 3. 2010 17:19

    bman (neregistrovaný) ---.cluster-g.websense.net
    Berte to tak, že jsou tady technologie, které inspekci HTTPs provozu umožňují a záleží jen na dané firmě/organizaci jaká pravidla si určí v bezpečnostní politice.
    Některé firmy to vůbec neřeší, některé ano.

    A co druhý pohled na věc: Tímto řešením budete mít menší problémy, protože platnost a validnost certifikátů ověřuje/vynucuje HTTPs proxy a uživatel nemá možnost odklikat povolení podvrženého/neplatného certifikátu. Dva úhly pohledu/dva různé závěry a asi v každé organizaci bude jiný.
  • 23. 3. 2010 18:13

    bman (neregistrovaný) ---.cluster-g.websense.net
    Nevím co je na tom příspěvku demagogického.
    Asi máte nějaký problém přijmout existenci HTTPs inspekce a to že některé společnosti ji prostě implementují.
    Je-li to solidní společnost, jsou uživatelé informováni a seznámeni s bezpečnostní politikou, která se ve spol. používá.
  • 23. 3. 2010 21:04

    Martin Kalenda (neregistrovaný) ---.klfree.cz
    Chápu že to umí, ale nechápu jak to souvisí s tím že se to musí nastavit zrovna takto.

    Mj, pokud je s tím zaměstnanec seznámen tak nemá co remcat, nepracovní věci má dělat doma. Produktivitu nelze měřit tím co klikal neklikal, tj nemá smysl číst co kdo dělá. Myslím že auditování takovéhoto provozu je tam pro ex-post dokazování.
  • 23. 3. 2010 22:28

    bman (neregistrovaný) ---.cluster-e.websense.net
    Vetšinou se nastavuje vyřazení bankovních serverů z dekrypce (si můžete ověřit dle cert.) a pak u enterprise řešení co vím, tak admin nemá k těmto informacím přístup - dekrypce se provádí jen v paměti a nikam se neukládá.
  • 23. 3. 2010 23:32

    anonymní ---.net.upc.cz
    Nazor je to zajimavy - takze obecne http proxy je nezakona?

    Popr. co treba antivirova kontrola posty a mazani vadnych priloh?
  • 26. 3. 2010 11:37

    Dan1220 (neregistrovaný) ---.i4g.tmcz.cz
    Osobně jsem rád, když někdo z oboru něco dokáže srovnat vedle sebe a dát tomu formu uchopitelnou i běžnému uživateli. Je mi jedno, že je to z firmy, která se tím zabývá (kdo jiný by o tom měl vědět víc?). Více mi vadí, že pán v diskuzi si dělá nepokrytě reklamu a na druhé straně autor článku to psal docela nestranně (vždyť uvedl výhody a nedostatky u všech zařízení). Docela bych uvítal podobný článek i od pana diskutujícího a těším se, že mě taky něčím posune dopředu. Reklama do diskuze nepatří a bez milosti bych ji mazal.
  • 26. 3. 2010 14:47

    Peter Pecho (neregistrovaný) ---.tns.cz
    Pošlite, prosím, do diskusie odkazy na VLASTNÉ články, prípadne napíšte, v ktorých médiách sa dané články objavili. Som zvedavý na ich vysokú úroveň!!! Inak budem vaše príspevky považovať iba za "prázdne reči".
  • 26. 3. 2010 15:36

    Aleš Kotmel (neregistrovaný) ---.annexnet.cz
    Počkejme si tedy čím nás oblažíte vy, v některém dalším vašem článku.

    Pokud bude úroveň dalšího vašeho článku stejná jako doposud, pak se tedy máme vážně na co těšit.

    Aleš Kotmel
    Annex NET, s.r.o.

    P.S. Končím, začínáte reagovat histericky a afektovaně.
  • 23. 3. 2010 21:50

    anonymní ---.net.upc.cz
    Vas nazor, ze auditovani je nelegalni je zajimavy - muzu se zeptat oc se opira?
    Nejaky zakon nebo je to jen Vas subjektivni pocit?
  • 25. 3. 2010 14:19

    Dan1220 (neregistrovaný) ---.i4g.tmcz.cz
    Vážený pane Astaro,
    nevím, proč se tady v diskuzi navážíte do člověka (myslím tím pana Pecha), který si dal tu práci a nás, co se v tomto oboru pohybují pouze okrajově, posunul článkem kousek dál.
    Osobně mi tento článek pomohl v tom, že až budu opět řešit otázku zabezpečení, tak vím, na co si dát pozor.
    Vaše příspěvky v diskuzi jsou docela mimo mísu a pouze se snažíte ukazovat "kdo ho má většího". Zkuste se přenést přes to, že zastupujete nějakou firmu a napište taky něco, co nám - uživatelům pomůže.
    A myslím to vážně. Budeme bezpečnost řešit a nevím, jestli bych se chtěl setkat právě s Vámi...
  • 25. 3. 2010 15:20

    Aleš Kotmel (neregistrovaný) ---.annexnet.cz
    Dobrý den,
    bohužel pan Pecho vás rozhodně v oblasti bezpečnostních řešení neposunul dál, on vás zcela záměrně posunul zpět.
    Pan Pecho například zapoměl napsat že:
    - pokud jste domácí uživatel a potřebujete pro svojí byť malou síť (maximálně 50 vnitřních IP adres) odpovídající úroveň zabezpečení ( SMB a enterprice level), můžete na portálu firmy Astaro získat zcela zdarma licenci pro domácí použití. Jedinou podmínkou je potvrzení prohlášení že licence pro domácí použití bude sloužit pouze k nekomerčním účelům. Automaticky pak získáte plný firewall, NAT, DNAT/SNAT, IPS/IDS, VPN site-to-site a remote access protokoly IPsec, SSL VPN, L2TP, Cisco IPsec, IPhone atd. Dále záskáte bezplatně ochranu proti virům (SMTP, PO3, HTTP, HTTPS), trojským koňům, malware, spyware, URL filtering, možnost plně blokovat skype (i v HTTPS), řídit pásmo pro P2P/IM protokoly nebo tyto protokoly zcela zablokovat plně dle vašeho uvážení.
    - další funkcí, která je například velice důležitá pro firemní nasazení je High Availability řešení, tedy zajistění vysoké dostupnosti přístupu k Internetu. Funkci High Availability aktivujete v Astaro řešení pouze na čtyři kliknutí. Potřebujete rozložit zátěž přístupu do Internetu na více linek, nebo potřebujte failover funkci pro zálohování konektivity do Internetu? Není problém, Astaro podporuje až osm různých linek do Internetu pro rozkládání pásma nebo failover link.
    Tyto výše uvedené bezpečnostní funkce a vlastnosti (a mnoho dalších) pro domácí nebo firemní nasazení vám pan Pecho úspěšně zatajil.
    Můj příspěvek nebyl o tom "kdo ho má většího", ale o tom že pan Pecho vystupuje na Lupě jako nezávislý autor, ale přitom je zaměstnán ve firmě TNS která vyvíjí bezpečnostní řešení KERNUN, což je konkurenční produkt k Astaro řešení a z toho důvodu prostě nemůže být nezávislým autorem, protože vědomě zamlčuje čtenářům na Lupě vyšší technickou úroveň Astaro řešení.
    Nevím, zda jste zaregistroval, že jsem se ani jednou v mých příspěvcích "neotřel" o funkce a vlastnosti KERNUN řešení. Nevyjádřil, protože to nepovažuji na profesionální přístup, ale jsem si velice dobře vědom nedostatků v implementaci bezpečnostních funkcí v KERNUN řešení. Ještě stále mám ve svém mobilním telefonu uložené poznámky z prezentace, kterou měl šéf vývoje KERNUNU na LinuxExpo minulý rok a buďte ubezpečen, že do dnešního dne nejsou tyto bezpečnostní funkce implementované.
    Je mi skutečně líto že jste si na základě článku pana Pecha udělal názor že Astaro řešení není pro vás to pravé. To byl totiž hlavní cíl článku pana Pecha, vytvořit dojem že není nic lepšího než je KERNUN. Pokud se dokážete jenom trochu povznést nad článek pana Pecha a mojí reakci na dle mého názoru špatný článek pana Pecha neváhejte mi napsat nebo zavolat a já se vám pokusím vysvětlit, kde já vidím přednosti Astaro řešení oproti konkurenci.
    Pokud by jste měl dvě minuty volného času prosím podívejte se na následující link, doufám, že budete příjemně překvapen:
    http://www.astaro.com/landingpages/2min-explainer-red


    Aleš Kotmel
    Annex NET, s.r.o.
  • 25. 3. 2010 10:42

    Aleš Kotmel (neregistrovaný) ---.annexnet.cz
    nemám problém s vámi ale s vašimi velice malými znalostmi bezpečnostních řešení a vaší absolutní neobjektivitou co se týká posuzování konkurenčních bezpečnostních řešení.

    Pokud nedokážete napsat objektivní článek bude myslím lepší nepsat vůbec žádný. Takový článek prospěje možná vám (uspokojíte své ego) a firmě TNS (bude používat váš "objektivní" článek k přesvědčování potenciálních zákazníků), protože neobjektivně posoudíte funkce a vlastnosti konkurence a následně vyzdvihnete KERNUN, který firma ve které pracujete vyvíjí.

    Co je na takovém článku objektivního? Kromě uspokojení vašeho ega?!


    Aleš Kotmel

    P.S. Aby jste byl dopředu informován o připravovaných novinkách ve verzi 8 a mohl je opět předem "objektivně" posoudit:

    - Clientless SSL VPN přístup přes User-Portal (RDP, Citrix, SSH, Telnet, VNC)
    - Reverzní HTTP Proxy server
    - Detailní logování VPN přístupu/aktivity uživatele
    - Dvou faktorová autorizace pro SSL VPN vzdálený přístup
    - Export konfigurace v čitelné formě pro potřeby bezpečnostního auditu
    - Detailní logování administrativních a konfiguračních změn
    - Víceúrovňová přístupová práva pro administrátory
    - Podpora paravirtualizace pro VMware a XEN
    - Podpora IPV6
    - 64-bitový systém
    - Certifikace EAL4+ pro Astaro Security Gateway
  • 23. 3. 2010 15:15

    xpckar (neregistrovaný) ---.net.upc.cz
    Myslí se tím zavrženíhodná/odporná čuňárna typu:
    Jedno šifrovaný spojení prohlížeče k proxy, a jiné od proxy na příslušnou adresu (dle IP cílovýho serveru), přičemž uživateli je pokoutně do prohlížeče třeba doménovou politikou podstrčena nějaká důvěryhodná CA, v rámci níž se generuje v reálu falešnej certifikát s cílovým URL (a vůbec s podvrženými parametry), přičemž některý prohlížeče jsou tak neschopný a hloupý, že o tom, že se jim tam objevila nová důvěryhodná CA, ani uživateli nedají vědět.
    Neboli nejlepší by bylo v tomhle šmejd stavu kontrolovat vždy certifikát.
    Tudíž ve firmě je rozhodně důležitá kontrola certifikátu, a v případě, že je CA nesprávná, v případě nemožnosti to změnit použít jedině jiný zařízení neboli jinej kanál.
  • 23. 3. 2010 15:24

    TNK (neregistrovaný) ---.5-4.cable.virginmedia.com
    Je to tak, proxy se tvari jako server a tim padem klient se overuje proti ni (a ne proti serveru) takze vse vyapa ok a komunikace mezi serverem a proxy muze jet jen po http.

    Mozna je i varianta kterou bych popsal Man-In-The-Middle kde se klienti pripoji k interni proxy a k ni si vyjednaji i SSL autentikaci a proxy pak sama navaze spojeni se SSL serverem (a tak se interne muze divat do toho co skrz ni projde, protoze interne do trafficu vidi).

    Co me zarazi na tomto clanku je absolutni ignorace znamych firewallovych hracu predevsim svetove jednicky na trhu - Izraelske spolecnosti Check Point a druheho v poradi uspesnosti - Juniper. Zatimco jakesi podivne linuxove reseni je hned na prvnim miste

    Ostatne jeste je pomerne zajimave delat jakoukoliv proxy na firewallu...ale proti gustu
  • 23. 3. 2010 16:59

    davro (neregistrovaný) 2001:718:801:----:----:----:----:----
    Pokud je firma až tak paranoidní, tak nebude problém patřičné servery s https vyjmenovat a těm pak důvěřovat. Těžko vám bude banka nutit viry. Na další externí https věci prostě lidi vůbec nepouštět.

    Tímto způsobem man in the middle si akorát můžete způsobit problémy, protože koncový uživatel nemůže ověřit správnost certifikátu místa, ke kterému se připojuje.
  • 23. 3. 2010 17:40

    xpckar (neregistrovaný) ---.net.upc.cz
    Tenhle příspěvek je už tak demagogickej, že nemá smysl k tomu cokoliv dalšího psát...
  • 23. 3. 2010 21:52

    davro (neregistrovaný) ---.ics.muni.cz
    A je tam snad napsané, že se to dá nastavit jinak? K čemu by taková funkcionalita byla? Pokud mám servery ve své správě, tak si vstup od uživatele musím řádně ošetřit, pokud to neudělám, dopadnu blbě.

    Není problém v tom, že zaměstnanec nedělá co má. Problém je třeba v tom, že administrátor má přístup k autentizačním údajům třeba do banky, což by mít v žádném případě neměl.
  • 26. 3. 2010 9:23

    bman (neregistrovaný) ---.cluster-e.websense.net
    No, částečně bych se tady pana Kotmela zastal. Znám jako uživatel třetí popisované řešení a uváděné informace nejsou vždy zrovna přesné, některé jsou úplně mimo. Nevím jestli to byl záměr nebo málo času k testování, ale je otázkou, jestli zástupce společnosti jednoho z testovaných produktů může být objektivní v tomto směru.
  • 25. 3. 2010 9:23

    Peter Pecho (neregistrovaný) ---.tns.cz
    Vážený p. Kotmel,

    Váš názor ukazuje, že nemáte tak problém s článkom, ako skôr so mnou osobne. Mojím cieľom bolo poskytnúť PREHĽAD firewallových riešení, ktoré som mal možnost testovať, a NIE poskytnúť podrobnú recenziu po DLHODOBOM používaní. Vzhľadom k časovým možnostiam to ani nie je možné. Taktiež nemám pocit, že by daný článok bol zaujatý mojím zamestnaním, na rozdieľ od Vášho príspevku! Nepíšem(e) tu marketingové materiály a nielen môj príspevok chce trochu nadhľadu ;-)

    Problémy, ktoré som s inštaláciou virtuálnej appliance mal, nemusia súvisieť priamo s Astarom a to je aj napísané v článku. Prečítajte si ho ešte raz:

    "..., a proto se nemusí nutně jednat o chybu Astara."

    Taktiež nebolo mojím cieľom písať o tom, čo BUDE MAŤ dané riešenie v novej verzii (= nemá v súčasnej verzii). K tomu slúžia webové stránky výrobcov. To, čo bude v novej verzii obsiahnuté sa taktiež nedá užívateľsky otestovať.

    Namietate tiež voči nespomenutiu ICSA certifikácie. Túto certifikáciu má v súčasnosti už väčšina firewallových riešení. Táto certifikácia (rovnako ako EAL) je navyše vydávaná za dopredu definovaných podmienok nasadenia. Je otázke, či je dané podmienky (vrátane presnej konfigurácie) možné v praxi skutočne dosiahnuť u zákazníka. Netreba tiež zabúdať, že certifikácia je vydávaná na zariadenie a jeho nasadenie v praxi ešte nemusí byť nutne bezpečné. Zariadenie, ktoré danú certifikáciu nemá, nemusí byť taktiež nutne menej bezpečné. Nenamietam však, že certifikácia je dobrým ťahom (a na tom sa asi zhodneme).

    Pokiaľ máte pocit, že som nebol dostatočne objektívny, obráťte sa priamo na lupu, alebo ešte lepšie - ponúknite im VLASTNÝ OBJEKTÍVNY ČLÁNOK! Rád si ho prečítam ;-)
  • 26. 3. 2010 15:28

    Peter Pecho (neregistrovaný) ---.tns.cz
    Z vašej odpovede vyplýva, že ste napísal dva články, posledný bol publikovaný pred 4 rokmi. Oba už nie sú dohľadatelné a aktuálne. Časopis Professional computing som mal možnosť čítať a nepovažujem ho ani náhodou za "objektívne" médium ... ;-)

    Preložené články nie je možné považovať za relevantné - to dokáže každý schopnejší "angličtinár" ;-) Preložené články taktiež nie je možné považovať za vlastnú tvorbu ;-)

    S vašou tvorbou ste sa nakoniec zameral iba na "výkriky" v diskusiách ...
  • 26. 3. 2010 14:38

    Aleš Kotmel (neregistrovaný) ---.annexnet.cz
    Dobrý den,
    chápu vás že jste rád pokud někdo napíše článek ze kterého se poučíte. Ale opět musím zopakovat že články pana Pecha jsou tendenční a zavádějící. To mé vyjádření rozhodně není útokem na pana Pechu (jak se mi snažil ve své reakci podsunout) ale jedině a pouze mým osobním názorem na kvalitu jeho článků.
    Ve vašich očích je pan Pecho odborník který dokáže napsat pro vás srozumitelný článek a recenzovat bezpečnostní řešení, ale v mých očích je pan Pecho pouze schopný manipulátor který se tváří jako nezávislý autor. To že není nezávislý snadno zjistíte pokud kliknete na link s jeho jménem na začátku každého článku - peter (tečka) pecho (zavináč) tns (tečka) cz. Zkuste zadat do adresové řádky v prohlížeči www.tns.cz - jaké překvapení, dostal jste se na stránky projektu KERNUN!

    Jak můžete očekávat od zaměstnance firmy která vyvíjí konkurenční produkt objektivní a nezávislou recenzi konkurenčních produktů?!

    Zmínil jste se, že by jste uvítal článek i ode mne. Ano mohu takový článek napsat, to rozhodně není problém a mohu vám i takové články které jsem psal nebo překládal z anglických originálů poslat e-mailem a troufám si tvrdit že mají vyší úroveň něž články pana Pecha. Ale opět jak chcete ode mne jako zaujatého člověka nezávislý článek/recenzi o konkurečních produktech? Rozhodně nechci klesnout na úroveň článků pana Pecha.

    Co vám rozhodně mohu nabídnout je diskuse ať osobní nebo e-mailovou o firewallech, IPS/IDS, VPN, vzdáleném přístupu, filtrování obsahu, blokování virů, spamu, malware, spyware, tedy o řešeních třídy UTM/XTM jako takových.

    Aleš Kotmel
    Annex NET, s.r.o.
  • 27. 3. 2010 16:12

    100% Lenin (neregistrovaný) 85.90.127.---
    Ale, ale.
    To už nám to sklouzlo do pěkné manipulace typu:
    A ukažte co jste udělal vy!

    Ale to je již od dětství rituál poměřování pér.

    Osobně se klaním k tomu, aby autor jakékoliv publikace nepsal o těch věcech, se kterými je spojen komerčně.

    Příklad:
    Mám li příjem z výroby bot. Nemohu psát recenze na nové kolekce bot. Protože to prostě smrdí neobjektivním výsledkem.

    Mám li firmu na tvorbu www stránek. Nebudu recenzovat webové stránky jiných tvůrců. Protože to nebude objektivní.

    A toto nemusí být chyba Petera, ale přístupu společnosti k této problematice. On napsal to co napsal. Jako profesionál to měl odmítnout.
    Profesionální Lupa to, když už to napsal, měla odmítnout - protože je přeci profesionální a poskytuje nám jen objektivní a vyvážené informace.

    Lupa je Lupy. A Lupa má povinnost nám poskytnout informaci o tom, že autor je "zaujatý". Když už to neumí on.

    Lupa je tak obrazem pokleslých profesionálních mravů v oblasti publikace odborných informací.
    A lupa, opovrhujíce objektivitou, vytváří tlak na absenci profesionálního přístupu autorů k publikaci "čehokoliv".

    Takový přístup nám garantuje jedno jediné = BULVÁR

    Zdar.

    p.s.
    Dneska se v Ruské Federaci ruší 5 časových pásem.
    Vydal MS patch?
  • 23. 3. 2010 16:52

    Petr (neregistrovaný) 89.187.139.---
    Ale to že to nechápeš není problém technologie.
    Představ si situaci, kdy firma chce auditovat, jaké informace tečou skrze její infrastrukturu - https spojení je potom potřebné do dosažení perimetru sítě, ale vnitřní prostředí považuje za bezpečné (a zároveň auditovatelné), takže terminuje HTTPS na perimetru a dovnitř pustí jen pure HTTP. A uživatel nic vědět nemusí.
    Další scénář počítá naopak s tím, že zatímco integrita spojení je důležitá, tak případný útok na aplikační rovině může být kritický. A právě proto, že HTTPS se inspektovat nedá, tak si to musí někde otevřít.
    A vzhledem k tomu, že serverový certifikát má pod kontrolou, tak není problém ho nahrát i na danou proxy (při komunikaci dovnitř, samořejmě).
    Řešení je spousta, mají různé opodstatnění a často je to i naprosto nutný požadavek.
    O tom že článek se věnuje segmentu malých a středních řešení nemluvím, jinak by tam asi musel zmínit právě Checkpoint, Juniper, Cisco ASA, případně jiné.
  • 18. 5. 2010 13:17

    Artur Linhart
    Narazil jsem náhodou po čase na tento článek a nedá mi to, abych k tomu něco nenapsal.
    Nevím, jestli byla nutná ze strany pana Kotmela tak bouřlivá reakce, resp. zdali zvolil zcela vhodnou formu, ale faktem je, že pokud píšete recenzi a píšete o produktu Vaší firmy, připadá mi to opravdu neetické nezmínit to explicitně ve Vašem článku jak v úvodu, tak i přímo u recenze produktu Vaší firmy. Vyvolává to dosti značnou řadu otázek.

    Pokud se týká věcné stránky článku, mohu k tomu jakožto dlouholetý uživatel produktu Astaro (momentálně jich máme v provozu cca 6 včetně HA-clusteru) cosi napsat snad s vyšší znalostí věci.

    Určitě mi přijde velmi zavádějící že jste všeobecně nezmínil možnost použití vcelku plné verze Astaro pro domácí použití. Další zajímavostí je možnost použití "Essential Edition" (bez proxy a VPN funkčností) i komerčně zadarmo.

    Pokud se týká nepřesností ve Vašem článku, větu "Za nevýhodu také považuji nemožnost definice portů, na kterých požaduji proxy využívat" mne opravu překvapila, protože to možné je a dokonce vcelku komfortně - např. pro HTTP/S proxy stačí dokliknout na záložku "Advanced" kde je možno nastavovat jak port na kterém proxy poslouchá při netransparentním módu, tak i služby (porty) které mají být proxy monitorovány (např. v transparentním módu - o této možnosti, která mi připadá být z uživatelského hlediska dosti příjemná jste se také možná mohl zmínit).

    Osobně dále opravdu nemohu souhlasit s hodnocením, že není možno firewall použít i pro správu větších sítí... Co je třeba myslím v tomto ohledu např. zmínit, je velmi výhodné použití (pokud vím zdarma) produktu Astaro Command Center, což je speciální služba, která vám umožňuje agregovat výstupy a základní ovládání více Gatewayí pod jednou střechou.

    Naopak mne osobně mrzí, že se nedá webové rozhraní ovládat klávesnicí, ale v době web2.0 už se to asi nedá nikde. Vzhledem k tomu, že je Gateway doslova přecpána funkčností, po upgradech jsme mívali na starších kusech ASG nejnižších řad ASG110 a ASG120 problémy s výkonem pokud jsme chtěli aktivovat veškerou funkčnost (v článku je zmíněn opravdu jen velmi malý výřez funkčnosti Astara - ale to pravděpodobně u všech produktů). Musím ale říci, že postupnými patchi na dnešní verze 7.50x se situace stabilizovala a i mnohem bohatší funkčnost dnes zvládá docela starý HW. Sice bych možná v rámci maintenance uvítal vstřícnější politiku Astaro AG ohledně výměny staršího HW za nový, ale cesta optimalizace je vlastně taky relativně dostačující :-).
    Pěkná mi u Kernunu připadá možnost editace konfiguračního souboru ručně a to ne kvůli možnosti definice extravagantních služeb, které mohu u Astara pár kliknutími bez problémů definovat v uživatelském rozhraní, ale kvůli hromadným změnám v konfiguraci - např. pokud přejmenujete nějakou zónu nebo přesouváte IP adresy k jinému providerovi, dost si poklikáte, na to by to bylo pěkné... Zvláště pokud to musíte provádět na více strojích. Slyšel jsem ale, že ale v nových verzích ACC by mělo být možno definovat entity systému (např. definice sítí a služeb) napříč více firewally, což by pak nesmírně ulehčilo povinnou "klikačku" na každém firewallu při přidání nějaké enterprise-wide významné adresy nebo jiného elementu konfigurace... No, uvidíme.

    Dále mne k Vašemu článku ještě napadlo, že pokud se týká obecné části o clusteringu v úvodu, připadá mi, že věta "Zde je však potřebné upozornit na skutečnost, že ne všechny funkce kráčí ruku v ruce s bezpečností. Pro vysvětlení uvádím režim active-active s vysokou dostupností (tj. souběžnou činnost obou firewallů). V takovém případě již nemá vysoká bezpečnost funkci vysoké bezpečnosti, ale naopak v případě výpadku jednoho zařízení to vede k výpadku části spojení, které aktivní zařízení již nestihnou obsloužit." možná nemusí být díky povaze netypického aktivního clusteringu Astaro (kaskáda se specifickou funkčností) úplně pravdivá, nevím.

    Neznám produkt Kernun, ale z mého hlediska mi za celkem zásadní při použití u středních sítí připadá absence load balancingu, jejíž alternativní přidané řešení nejenom zvyšuje komplexnost síťové topologie, ale znamená i nutnost nákupu dalšího zařízení, což může znamenat nezanedbatelné náklady navíc - zvlášť pokud chcete docílit high-availability. Myslím si, že to naopak produkt poněkud u použití pro střední a menší firmy diskvalifikuje.
    Pokud se týká protokolu IPv6, pokud píšete, že je dnes u produktu Kernun k dispozici v experimentální formě, je to jako bych řekl, že mohu vyzkoušet beta verzi Astaro v8, která podporu v sobě má... Je ovšem možné že v době vzniku článku ještě betaverze nebyla dostupná, nevím - že ale IPv6 v další verzi bude je již známo delší dobu, stačilo trochu zapátrat na webu (obecně budoucí plány výrobců by u recenze asi chybět neměly a s výjimkou Fortinetu chybí). Čekal bych tedy nicméně, že v negativech Kernum firewallu by pouhá "experimentálnost" použití IPv6 mohla být zmíněna, pokud jde o tak důležitý bod, že ho bylo třeba u Astara zmínit, zvláště v zavádějící formulaci "Nevýhodou do budoucnosti může být také absence podpory IPv6" - když lze snadno zjistit že v budoucnu IPv6 podporováno bude.

    Pokud pak dále píšete, že Kernun firewall pracuje pouze s aplikačními proxy a nepoužívá stavové paketové filtry u běžných protokolů, velice by mne pak zajímala odolnost vzhledem k DoS útokům který někdo spustí na servery v DMZ chráněné tímto firewallem, které tedy odstiňuje jak jsem pochopil pouze aplikační proxy, tedy řádově komplexnější zpracování požadavků. Ale možná jsem to špatně pochopil, nevím, produkt Kernum vůbec neznám.

    Celkově se mi osobně opravdu zdá tendenčnost vašeho článku sice jemná, ale docela zřejmá.
  • 23. 3. 2010 13:35

    davro (neregistrovaný) ---.ics.muni.cz
    ...Na druhé straně vyzdvihuji implementaci HTTPS proxy, která skutečně ukončuje SSL/TLS „trubku“...

    Což je mimořádná prasárna a nechápu, jak může někdo, kdo se považuje za odborníka na bezpečnost, něco takového vyzdvihovat.
  • 23. 3. 2010 17:13

    xpckar (neregistrovaný) ---.net.upc.cz
    Je to podvod. Především zcela vynuceně by měli být uživatelé informováni, že použití SSL/TLS ve firmě se sleduje, aby se mohli podle toho zařídit (používat vlastní zařízení/PC/mobil). Často se to tak ovšem neděje, a firmy to dělají pokoutně uživatelům za zády.
    U tvýho "uživatel nic vědět nemusí" se mi otevírá kudla v kapse.
  • 23. 3. 2010 17:29

    anonymní 2001:470:9e70:----:----:----:----:----
    Ehm, ze ty nechapes co je zabezpeceni je zjevne jen tvuj problem. Jakmile se neco takoveho objevi v ceste, tak to znamena, ze kdokoli muze nahlizet do komunikace (trebas admin) a zaroven ji taktez nalezite upravovat. Neni pak prakticky zadny problem zobrazit prevod na ucet parnera, ale v realu si zmenit cislo uctu na sve. Ostatne i proto pouziva kazda rozumna bankovni aplikace nezavisly kanal, takze ani v pripade ze dojde k naruseni bezpecnosti by nemelo dojit k pozmeneni dat.

    Nehlede na to, ze existuje technologie SSL v HTTP => pro proxy se veskera komunikace tvari jako jakasi binarni http komunikace, v realu jde ale o ssl kanal.

    A co se auditovani (aneb smirovani) uzivatelu tyce, oni se zamestnanci jednoho krasneho dne nastvou a zamestnavateli to daji pekne sezrat. Ono je to totiz (mimo jine) v rozporu se zakonem a kdo myslis ze na to dojede ? Ano, spravne admin, ktery to ma nastarosti. Byl by blazen kdyby ve firme neco takoveho implementujici hodlal pracovat dyl nez tech 5 minut do vypovedi.
    Pokud nekdo chce vynaset firemni data, tak to stejne udela a nikdo mu v tom neni schopen zabranit, pokud k tem datum potrebuje mit pristup.
  • 23. 3. 2010 22:26

    anonymní 2001:470:9e70:----:----:----:----:----
    Presne tak a nejen to, datove schranky, komunikace s partnery (take casto https) .... Je to naprosto totez jako kdyz si admin zapisuje hesla useru aby se na ne mohl prihlasit (celkem bezna praxe v mnoha firmach).

    BTW: Pokud sef nedokaze zhodnotit a kontrolovat praci svych podrizenych jinak, nez jejich smirovanim, a zjistovanim jejich "nepracovnich" aktivit, tak si zaslouzi jedine a to vyhazov (variantne krach vlastni firmy). Pokud totiz nekomu zadavam nejaky ukol, je jen na mne abych zaroven pridelil odpovidajici cas.
    Pokud to dotycny udela o vikendu a pak si bude v tydnu chatovat na libimseti, je mi to fuk. Pokud mam pocit ze ma malo prace, je to moje chyba, pokud ji ma moc, je to opet moje chyba. V obou pripadech to bude firmu stat penize, v prvnim na promrhanem case, ve druhem za jineho pracovnika, jeho zaskoleni ... .

    Bohuzel v CR stale panuje uvazovani jak za sociku. Tudiz neni podstatne zda v praci pracujete, podstatne je si tam odsedet odpovidajici cas.

    Navic to jeste podporuji dementni redaktori a idioti z auditorskych firem (za dlouhe penize za audity = opet smirovani lidi) informacemi, ze se 70% casu lidi flakaj na facebooku. Mozna ano, ale to neni jejich chyba, to je chyba jejich sefa, ktery jim nepridelil zadnou praci.
  • 23. 3. 2010 22:42

    anonymní 2001:470:9e70:----:----:----:----:----
    Zeby zakon o telokomunikacich a nezakony odposlech ? Ze zakona jste opravnen zaznamenavat informace nutne k technickemu zajisteni provozu telekomunikacniho zarizeni = to jsou napriklad nejake logy. Rozhodne nejste opravnen zasahovat do spojeni jako takoveho, natoz jej zaznamenavat, navic v pripade https dokonce prolamujete sifrovane spojeni, da se tedy dovodit, ze si protistrany nepreji byt odposlouchavany.

    Zamestnanci muzete rikat co chcete, stejne porusite zakon + jako bonus vas trebas zazaluje protistrana (banka a dalsi na 100%), protoze prolamujete jejich zabezpeceni.

    Jestli jste nekdy mel napriklad v ruce smlouvu na provoz karetniho bankovniho terminalu, tak presne takoveto aktivity jsou tam vyslovne zakazany pod milionovymi penalizacemi + samozrejme hradite veskere skody atd.

    Napriklad co se tyce emailu, existuje dokonce nekolik rozsudku (vcetne nevyssiho soudu) ze email obsahujici identifikaci typu jmeno/prezdivka/... je soukromy bez ohledu na to, kdo jej provozuje. I pokud pak zamestnance upozornite a date mu mail pepa.voprsalek@firma.cz mate smulu, protoze nikdo zvenku neni schopen rozlisit zda jde o mail "firemni" nebo soukromy (trebas provozujete freemail ...). Takze az na nekoho vytahnete, ze si mailuje v pracovni dobe s kubikem z horni dolni a posila mu pozvanky napivo, prave ste si zadelal na 2roky v base natvrdo.

    (Jo zam jednu "cerstve na materske", ktere se firma chtela podobne zbavit a soud bleskove prohrala)