Вітаю! Сардэчна запрашаем на шосты ўрок курса . На мы асвоілі асновы працы з тэхналогіяй NAT на , а таксама выпусцілі нашага тэставага карыстальніка ў Інтэрнет. Цяпер прыйшоў час паклапаціцца аб бяспецы карыстальніка на яго прасторах. У дадзеным уроку мы разгледзім наступныя профілі бяспекі: Web Filtering, Application Control, а таксама HTTPS інспекцыю.
Для таго, каб пачаць знаёмства з профілямі бяспекі, нам неабходна разабрацца яшчэ з адной рэччу - рэжымамі інспекцыі.
Па змаўчанні выкарыстоўваецца Flow Based рэжым. Ён правярае файлы, калі яны праходзяць праз FortiGate без буферызацыі. Як толькі пакет знаходзіцца, ён апрацоўваецца і перадаецца далей, без чакання атрымання цэлага файла ці вэб старонкі. Ён патрабуе менш рэсурсаў і забяспечвае большую прадукцыйнасць, чым Proxy рэжым, але ў той жа час у ім даступны не ўвесь Security функцыянал. Напрыклад, сістэму прадухілення ўцечкі дадзеных (DLP) можна выкарыстоўваць толькі ў Proxy рэжыме.
Proxy рэжым працуе інакш. Ён стварае два TCP злучэнні, адно паміж кліентам і FortiGate'ом, другое паміж FortiGate'oм і серверам. Гэта дазваляе яму буферызаваць трафік, г.зн. атрымліваць поўны файл або вэб старонку. Сканіраванне файлаў на розныя пагрозы пачынаецца толькі пасля таго, як забуферызаваўся ўвесь файл. Гэта дазваляе ўжываць дадатковыя магчымасці, якія недаступныя ва Flow based рэжыме. Як бачыце, гэты рэжым быццам бы супрацьлегласць Flow Based - бяспека тут гуляе галоўную ролю, а прадукцыйнасць адыходзіць на другі план.
Вельмі часта пытаюцца - які рэжым лепш? Але тут няма агульнага рэцэпта. Усё заўсёды індывідуальна і залежыць ад вашых патрэб і задач. Я ж далей на працягу курса пастараюся паказаць адрозненні профіляў бяспекі ва Flow і Proxy рэжымах. Гэта дапаможа параўнаць функцыянал і вырашыць, што лепш падыдзе вам.
Пяройдзем непасрэдна да профіляў бяспекі і першым разгледзім Web Filtering. Ён дапамагае кантраляваць ці адсочваць, якія вэб сайты наведваюць карыстачы. Думаю, не варта паглыбляцца ў тлумачэнні неабходнасці такога профіля ў цяперашніх рэаліях. Лепш разбяромся, як ён працуе.
Пасля таго, як усталявана TCP злучэнне, карыстач з дапамогай запыту GET запытвае змесціва вызначанага вэб сайта.
Калі вэб сервер адказвае станоўча, ён адсылае інфармацыю аб вэб сайце ў адказ. Тут у справу ўступае вэб фільтр. Ён правярае змесціва дадзенага адказу. Падчас праверкі FortiGate у рэжыме рэальнага часу адпраўляе запыт у FortiGuard Distribution Network (FDN), каб вызначыць катэгорыю дадзенага вэб сайта. Пасля вызначэння катэгорыі канкрэтнага вэб сайта, вэб фільтр у залежнасці ад налад выконвае канкрэтнае дзеянне.
Ва Flow рэжыме даступна тры дзеянні:
- Allow - дазволіць доступ да вэб сайту
- Block - забараніць доступ да вэб сайту
- Monitor - дазволіць доступ да вэб сайту і запісаць гэта ў логі
У Proxy рэжыме дадаюцца яшчэ два дзеянні:
- Warning - выдаваць карыстачу папярэджанне аб тым, што ён спрабуе наведаць пэўны рэсурс і даць карыстачу выбар - працягнуць або сысці з вэб сайта
- Authenticate - запытаць уліковыя дадзеныя карыстальніка - гэта дазваляе дазволіць пэўным групам доступ да забароненых катэгорый вэб сайтаў.
На сайце вы можаце азнаёміцца са ўсімі катэгорыямі і падкатэгорыямі вэб фільтра, а таксама пазнаць, да якой катэгорыі прыналежыць пэўны вэб сайт. Ды і ў цэлым, для карыстачоў рашэнняў Fortinet гэта даволі карысны сайт, раю ў вольны час пазнаёміцца з ім бліжэй.
Пра Application Control можна сказаць зусім няшмат. З назвы бачна, што ён дазваляе кантраляваць працу прыкладанняў. А робіць ён гэта з дапамогай патэрнаў розных прыкладанняў, так званых сігнатур. Па гэтых сігнатурах ён можа вызначыць канкрэтнае прыкладанне і прымяніць да яго пэўны дзеянне:
- Allow - дазволіць
- Monitor - дазволіць і запісаць гэта ў логі
- Block - забараніць
- Quarantine - запісаць падзею ў логі і заблакаваць IP адрас на пэўны час
Паглядзець існуючыя сігнатуры таксама можна на сайце .
Цяпер разгледзім механізм HTTPS інспекцыі. Згодна са статыстыкай, за канец 2018 года доля HTTPS трафіку перавысіла 70%. Гэта значыць, без выкарыстання HTTPS інспекцыі мы зможам прааналізаваць толькі каля 30% трафіку. Для пачатку разгледзім працу HTTPS у грубіянскім набліжэнні.
Кліент ініцыюе TLS запыт да вэб-сервера і атрымлівае TLS адказ, а таксама бачыць лічбавы сертыфікат, які павінен быць давераным для дадзенага карыстальніка. Гэта той неабходны мінімум, які нам трэба ведаць пра працу HTTPS, насамрэч схема яго працы нашмат складаней. Пасля паспяховага TLS хэндшэйка пачынаецца перадача дадзеных у зашыфраваным выглядзе. І гэта добра. Ніхто не можа атрымаць доступ да дадзеных, якімі вы абменьваецеся з вэб-серверам.
Аднак для бяспечнікаў кампаній гэта сапраўдны галаўны боль, паколькі яны не могуць бачыць гэты трафік і правяраць яго змесціва ні антывірусам, ні сістэмай прадухілення ўварванняў, ні DLP сістэмамі, нічым. Таксама гэта негатыўна адлюстроўваецца на якасці вызначэння выкарыстоўваюцца ўнутры сеткі прыкладанняў і вэб рэсурсаў - як раз тое, што адносіцца да нашай тэмы ўрока. Вырашыць дадзеную праблему заклікана тэхналогія HTTPS інспекцыі. Яе сутнасць вельмі простая - фактычна, прылада, якое займаецца HTTPS інспекцыяй, арганізуе атаку Man In The Middle. Выглядае гэта прыкладна наступным чынам: FortiGate перахапляе запыт карыстача, арганізуе з ім HTTPS злучэнне, і ўжо ад сябе паднімае HTTPS сесію з рэсурсам, да якога звярнуўся карыстач. Пры гэтым на кампутары карыстальніка будзе бачны сертыфікат, выпушчаны FortiGate'ам. Ён павінен быць давераным, каб браўзэр дазволіў падлучэнне.
Насамрэч HTTPS інспекцыя рэч даволі няпростая і мае мноства абмежаванняў, але ў рамках дадзенага курса мы гэта разглядаць не будзем. Дадам толькі, што ўкараненне HTTPS інспекцыі – не хвілінная справа, звычайна гэта займае прыкладна месяц. Неабходна сабраць інфармацыю аб неабходных выключэннях, зрабіць адпаведныя наладкі, сабраць зваротную сувязь ад карыстальнікаў, адкарэктаваць наладкі.
Прыведзеная тэорыя, а таксама практычная частка прадстаўлены ў дадзеным відэа ўроку:
У наступным уроку мы разгледзім іншыя профілі бяспекі: антывірус і сістэму прадухілення ўварванняў. Каб не прапусціць яго, сачыце за абнаўленнямі на наступных каналах:
Крыніца: habr.com