- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (48)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)


















![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | |
![]() | ||
Brány do podnikových sítí IV. díl
Bezpečnostní funkce
Další články seriálu:
Původním úkolem zařízení připojujících firemní LAN bylo především zajistit připojení k internetu, tzn. konverze různých fyzických médií (obvykle ethernetu na nějaký druh sériové linky) a směrování provozu mezi nimi. Jakési zabezpečení bylo tehdy spíše volitelnou funkcí pro nenapravitelné paranoiky, které obsahovalo nanejvýš překlad adres (NAT). Překlad adres má za úkol ve veškeré komunikaci z počítačů v LAN do internetu změnit zdrojovou adresu těchto počítačů a nahradit jí adresou vlastní. Server na internetu má pak dojem, že komunikuje s internetovou branou, a tak je původce této komunikace – počítač v LAN – z internetu neviditelný.
Tato technika ale primárně vznikla jako metoda pro šetření veřejnými IP adresami a bezpečnostní funkce je spíše jakýsi vedlejší efekt, případný útočník tedy nemá příliš práce s tím, obejít ji.


Ohlédnutí do minulosti – paketový filtr
Od konce minulého století do současnosti ušly krabičky zajištující spojení se světem pořádný kus cesty. První zmínka o tzv. firewallu ve smyslu, v jakém je používán dnes, se objevuje v roce 1988 u firmy DEC a jednalo se o takzvaný paketový filtr. Šlo o to, že tento speciální druh routeru nejenom uměl předat provoz mezi sítěmi, ale zároveň měl v konfiguraci pravidla stanovující, která spojení má propustit. Bezpečnostní mechanismus v těchto paketových firewallech obsahoval jen základní popis, odkud a kam lze komunikovat – bez možnosti podrobnějších nastavení. Tyto firewally tedy uměly povolit komunikaci jenom vybraným IP adresám na internetu a staly se tak základem skutečných bezpečnostních technik.
Zároveň při nastavování těchto přístupových pravidel (access lists) obstojně pily krev správcům nutností nastavovat oba směry komunikace (dotazy i odpovědi), pokud možno každý směr na jiném místě, a postaraly se jim tak o dostatek bezesných nocí a rozzuřených telefonátů časně ráno. Tento druh firewallu byl „oblíbený“ především u administrátorů FTP serverů, které komunikují odlišným způsobem než ostatní běžné internetové služby.
Stavový firewall
Mezitím v Bellových laboratořích vznikala další generace firewallů, a to stavový (statefull) firewall. Stejně jako jeho předchůdce prohlíží hlavičky paketů a podle kombinace zdroje, cíle a portu určuje, zda paket zpracuje, odmítne, nebo zahodí. Tato pravidla se ale nastavují pouze ve směru, ze kterého očekáváme první paket, firewall si sám udržuje tabulku aktivních spojení a relevantní provoz si již sám odvodí, což značně usnadnilo těžký život síťového administrátora. Nepsaným pravidlem se stala výchozí politika zahazující všechny pakety neodpovídající definovaným pravidlům a zpracovávání paketů určené pořadím pravidel (tzv. first match). Pouhou změnou pořadí těchto pravidel lze tedy měnit chování i výkon firewallu. Objevily se sice pokusy o jiné politiky (např. „best match" politika nějakou dobu používaná branami firmy Symantec), ale byly v praxi těžko použitelné, a tak zakrátko zmizely v propadlišti dějin.
Stavový firewall řeší přesně to, co se od něj očekává, tedy pouze rozhoduje, který provoz do sítě propustí, a který nikoli. Předpokládá ovšem (nebo alespoň jeho administrátor), že tento provoz je v pořádku a na cílových serverech nezpůsobí problémy.
Cesta k IDS
S tím, jak do původně poklidného internetového akademického kampusu vtrhla dravá komerce, se postupně internet stal drsným místem pro život aplikací a komunikace s digitálním světem začala být nebezpečná. Svět již předtím znal počítačové viry a červy, ty ale v době disket měly značně omezené možnosti šíření. Tato překážka s nástupem celosvětové sítě padla a viry, červi a trojské koně se radostně vydaly do světa. Pro výše popsané brány řídící provoz pouze na třetí vrstvě ISO/OSI modelu byly tyto programy neviditelné, a pokud přišly ze správného směru, byly propuštěny do sítě. Určitým druhem řešení se stala metoda „antivir do každého počítače“, v podstatě používaná dodnes. Postupně se však ukázalo výhodné odepřít škodlivým programům vstup přímo na internetové bráně a nevpustit je vůbec do vnitřní sítě. Dalším důvodem pro zvýšení „kvalifikace“ internetových bran (v boji proti hrozbám přicházejících ze sítí) se stal zvyšující se počet útoků na aplikační servery, které v principu nebylo možné označit za viry, nicméně využívaly specifické zranitelnosti těchto služeb. Antivirové programy tyto typy útoků ignorovaly – nejednalo se přece o viry – a přesto bylo třeba proti nim nějak bojovat. Jedním ze způsobů bylo co nejrychlejší záplatování známých děr v aplikacích. To však vzhledem k „rozmazlenosti“ vnitropodnikových aplikací bývá problematické. Například téměř každá větší záplata Microsoftu obsahuje alespoň jednu chybu komplikující přímé nasazení ve firemním prostředí. A proto internetové brány dostaly další úkol. Tím se stala kontrola vstupujícího provozu na známé hrozby. To ale znamená kontrolu nejenom hlavičky, ale celého paketu, a tedy vyžaduje několikanásobný výpočetní výkon. Dosavadní brány takovým výkonem nedisponovaly. Co s tím? Prvním řešením bylo vložit do cesty za internetovou bránu systém IDS (intrusion detection system), který kontroloval provoz podle známých kritérií. Jeho nevýhodou bylo velké množství falešných poplachů a také to, že problémy pouze detekoval, ale neřešil. Administrátor měl tedy ráno či dopoledne po příchodu do práce dokonalý přehled, odkud přišel nejnovější exploit, a pak se radostně pustil do dezinfekce postižených strojů.

Aplikační proxy server a IPS
Nové, výkonnější procesory umožnily vznik třetí generace firewallů, která pro ochranu aplikací používala tzv. aplikační proxy, služby, které se tvářily jako aplikační server a prováděly aplikační obdobu výše zmíněného NATu. Vybraným typům spojení stála tato aplikační proxy v cestě a přeposílala je serveru místo klienta. Pro klienta byl tento proces naprosto transparentní, měl tedy dojem, že komunikuje se serverem, přestože se bavil pouze s proxy. Funguje tedy jako jakýsi tlumočník mezi klientem a serverem, a tím pádem odstraňuje z provozu potenciálně nebezpečný kód. Aby internetová brána mohla vystupovat jako server každé požadované služby, musí obsahovat alespoň její základní implementaci – korektní odpovědi na dotazy klienta, reakce na příkazy apod. Vzhledem k rozmanitosti a množství používaných služeb brána obvykle umí komunikovat pouze těmi nejobvyklejšími aplikačními protokoly (např. HTTP, SMTP, POP3, ...) a vůči ostatním se chová jako běžný stavový firewall.
Posléze se u některých výrobců objevuje kombinace aplikačních proxy s antivirovým enginem, který stejně jako jeho softwarový bratříček na PC porovnával svou databázi virů s právě procházejícím provozem. Objevené incidenty pak řešil po svém – obvykle vysláním příkazu k přerušení komunikace s dotyčným strojem. Odtud už byl jenom krok ke zkoumání celého provozu nejenom na přítomnost známých virů, ale i na přítomnost dalších bezpečnostních hrozeb – červů, rootkitů, trojských koní apod.
To samozřejmě vyžadovalo odpovídající výkon, proto dnešní brány mají (s výjimkou různě vyspělých metod zkoumání paketů) i výkon, který si ničím nezadá se špičkou současných PC. Pro ilustraci například internetové brány SonicWall mají CPU obsahující až šestnáct jader na frekvenci 600 MHz a teoretickou datovou propustnost až 10 GBit na jádro.
S tímto výkonem už si můžeme dovolit zahodit omezené aplikační proxy a místo ní použít funkci IPS (intrusion prevention system), která bez ohledu na protokol zkoumá veškerý procházející provoz na všechny možné druhy hrozeb. To je aktuálně jedna z nejnáročnějších funkcí vyžadujících opravdu vysoký výpočetní výkon a zároveň velmi dobrý návrh vnitřní architektury brány – o komplikovanosti tohoto problému nejlépe vypovídají výkonnostní rozdíly mezi špičkovými zařízeními jednotlivých výrobců.
Další bezpečnostní funkce
Kromě těchto klíčových funkcí dnes internetové brány disponují celou řadou dalších funkcí. Příkladem může být například řízení rychlosti jednotlivých připojení podle stanovených pravidel (například administrátor může mít k terminálovému serveru vyhrazenou vyšší rychlost než běžný uživatel), podpora virtuálních sítí (VLAN), IP telefonie včetně upřednostňování provozu (QoS) a další a další funkce. V neposlední řadě i řízení přístupu uživatelů na jejich oblíbené stránky (content filtering).
Spornou otázkou při řešení hrozeb je obvykle přístup ke spamu jako specifickému druhu nevyžádaného provozu. Někteří výrobci se chlubí antispamovou funkcionalitou právě na branách, obvykle nejde o nic jiného než o různé implementace blacklistu. E-mail je na základě různých kritérií posouzen, tedy obvykle IP adresa odesílatele, někdy se pro větší jistotu používá i hash celého e-mailu. Následně je porovnán s on-line databázemi obsahujícími známé hříšníky. Vzhledem k principiálnímu zpoždění obsahu těchto databází za realitou a způsobu jejich naplňování lze blacklisting považovat za překonanou technologii. Antispam by tedy z principu internetová brána neměla řešit, pokud nedisponuje vestavěným mailserverem, dostatečným datovým úložištěm a dalšími – sofistikovanějšími technologiemi k odhalování spamu (bayesiánskými filtry, ověřováním odesílatele, graylistingem apod.).
Stále oblíbenější funkcí vyžadovanou na internetových branách je z logiky jejich umístění v topologii sítě terminace VPN tunelů. Tato technologie, která stále více nahrazuje drahé frame relay okruhy spojující pobočky firem, vítězí díky své flexibilitě i dostatečné bezpečnosti. Požadavek na silné šifrování provozu samozřejmě dále zvyšuje požadavky na výkon celé brány, výrobci jako třeba SonicWall tedy používají specializované koprocesory starající se výhradně o šifrování provozu určeného do VPN tunelů. Zároveň lze při využití této technologie řešit i připojování jednotlivých vzdálených uživatelů (road warriors) a řídit jejich přístupová práva.
Více připojení a rozložení zátěže
Se vzrůstajícím množstvím komunikace vedené po datových linkách se pro firmy i závislé jednotlivce stává dostupnost datového připojení kritickým faktorem jejich činnosti. I toto dokáží internetové brány řešit: můžete si pořídit více připojení od různých poskytovatelů a brána pohlídá, aby se vaše data dostala k cíli i při výpadku jednoho z ISP. Lze také zvýšit rychlost připojení rozkládáním zátěže na jednotlivé linky podle různých kritérií. V neposlední řadě by vás brána měla ochránit i při výpadku sama sebe, ať už duplikováním kritických součástí (typicky napájecí zdroje), nebo rovnou propojením dvou bran do clusteru. Při výpadku jedné z nich pak druhá přebírá kompletně její funkci včetně již navázaných spojení. Při svázání dvou bran do clusteru navíc kromě vysoké dostupnosti získáme i téměř dvojnásobný výkon pro všechny výše zmiňované síťové a bezpečnostní funkce.
Slovo závěrem
Internetové brány tak od konce minulého století prošly vývojem od jednoduchých převaděčů ethernet – sériová linka k sofistikovaným strážcům internetového pohraničí spolehlivě střežícím klid firemní i domácí LAN.
Autor působí jako technologický konzultant pro SonicWall ve společnosti Azlan.
Další články seriálu:


![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
Formulář pro přidání akce
15.5. | Konference SCADA Security |
22.5. | Akce pro automobilové dodavatele "3DEXPERIENCE... |
12.6. | Konference ABIA CZ 2025: setkání zákazníků a partnerů... |
29.9. | The Massive IoT Conference |