Межсетевые экраны: stateful-фильтрация и зонная модель

Про файл начнем, второй кусок нашей записи пятого дня, чтобы не запутаться в записях. Давайте дальше про ARP inspection — как он настраивается. Смотрите, самое интересное в принципе в настройке — как он включается. Включается очень просто: мы говорим, для какого VLAN нам включить инспекцию ARP, и она там будет работать, а потом просто определить доверенный интерфейс — всё. Дальше самое интересное — это то, с чем мы не сталкивались: ARP access-листы. Можно написать ARP access-лист, он будет выглядеть так же, как обычный access-лист, просто здесь будет

задаваться привязка IP-адреса к MAC-адресу. Можно использовать эти access-листы вместо базы DHCP snooping. Роман спрашивает — все остальные по умолчанию недоверенные? Да, единственное, что надо сказать — какие доверенные, все по умолчанию будут недоверенные, и там будет осуществляться проверка ARP. Напоминаю: доверенные — это те, где не идёт вообще никакая проверка ARP. Смотрите, про access-листы я не договорил. ARP access-лист — интересная вещь, которую раньше не видели. Пишется она просто, и можно её применить, сказав arp inspection filter, и для конкретного

VLAN включить конкретный access-лист. Если добавить static, то база DHCP snooping не будет вообще работать. Если static не добавлять, то будет сначала проверяться по этому access-листу, потом будет по базе DHCP snooping. И в базе DHCP snooping можно — то, что мы не говорили, когда про DHCP snooping был разговор — добавлять ручную привязку: делать в базе DHCP snooping binding конкретного MAC-адреса в конкретном VLAN к конкретному IP-адресу, указать интерфейс и через сколько он протухнет. Без ARP ACL, конечно, будет работать. Андрей, не на интерфейс вешается этот access-лист ARP — он работает только

для dynamic ARP inspection. На интерфейс — нет, зачем на все интерфейсы вешать ещё access-листы? Мы сразу для всего VLAN включаем этот access-лист, и всё. Мы просто говорим механизму ARP inspection: вот ещё у тебя access-лист, ещё по нему сначала проверяй. Для верификации есть много — там четыре команды, в которых можно посмотреть работу. Тут не стали расписывать, они все начинаются show ip arp inspection: либо интерфейсы посмотреть — какие у нас доверенные, какие недоверенные, можно лог посмотреть, либо статистику. Без параметров — это просто общая настройка. Здесь, наверное, ещё стоит сказать, что если вы будете править базу данных DHCP snooping, то она выполняется не в режиме конфигурации, а в exec mode, потому что база — то же самое, как база VLAN,

старая база VLAN, которую не в режиме конфигурации редактировать. То же самое — она отдельно конфигурируется и отдельно хранится. В running-config её вообще нет. Четвёртый модуль — мы поговорим про файрволы. Мы сейчас не будем никакие консоли открывать, поговорим просто о том, что такое firewall, об основах, которые нужно знать и понимать, какие они бывают, в том числе и для экзаменов, потому что я подозреваю, что вас точно спросят, какие бывают файрволы. А их бывает до фига. Принято считать, что firewall — это просто какая-то одна железка, которая у нас стоит на периметре и защищает наш периметр, просто фильтрует пакеты. На самом деле вопрос немножечко шире.

Давайте сначала про общие концепции поговорим, это очень важно. Для начала — концепция зон безопасности, которая всё-таки в современном мире более оправдана и более популярна, чем просто концепция интерфейсов. Намного удобнее всё разделить на зоны, и потом при настройке файрвола либо при написании правил безопасности в политике, даже на бумаге, эта концепция будет намного лучше укладываться в наших головах, намного лучше ложиться на бумагу и в конфигурацию в том числе. Сейчас все так работают. Мы уже поговорили немножко про то, какие бывают зоны: inside — защищённая

сеть предприятия, outside — внешняя сеть, демилитаризованная зона — DMZ. Они все имеют какую-то степень доверия, что очень важно, и их нужно по-разному защищать. Конечно, мы не будем защищать зону outside. С другой стороны, мы ещё говорили с вами про экстранет — какая-то зона может быть у наших партнёров, например. Смысл и значение DMZ — хороший вопрос, потому что иногда в этом путаются. В DMZ содержатся серверы, которые доступны извне. На этом слайде показано — может быть, стрелочки не очень хорошо нарисованы. Самый главный смысл DMZ — то, что извне в эту зону попасть можно,

к серверам, которые расположены в ней — демилитаризованной зоне. Изнутри в неё попасть можно, но вот из этой зоны попасть внутрь сети никаким образом нельзя — самый главный принцип этой зоны. Иногда говорят, что в этой зоне размещаются серверы с белыми адресами — это ерунда, там неважно, какая адресация и где настроена, это не про то. Самое главное — что из этой зоны нельзя выбраться в вашу внутреннюю сеть. Поэтому в ней размещают публичные серверы, например веб-сервер компании или почтовый сервер компании. Если ваш веб-сервер будет каким-то образом скомпрометирован, то дальше, чем из этой зоны, во внутреннюю сеть компании доступ будет невозможен. Вот это главная идея демилитаризованной

зоны. Из неё в интернет — да, можно. Это можно как-то ограничить: например, за обновлениями ходить, либо только отвечать на запросы извне — только ответный трафик разрешить. Во внутреннюю сеть — строго только ответный трафик. Всё, больше ничего, отсюда нельзя выбраться. Всё. Андрей, думаю, ответил на ваш вопрос. Давайте дальше — характеристики межсетевых экранов. Я уже сказал, что реализаций бывает много, это понятие довольно широкое. Быстро проговорим, какие они бывают. Во-первых, это фильтрация пакетов просто на коммутаторах или маршрутизаторах — всем нам известные access-листы либо какие-то другие функции. По реализации они могут быть встроенные в

какие-то другие устройства. Например, на маршрутизаторах у нас есть несколько типов файрволов даже на обычном Cisco IOS: мы можем использовать ZBF, и старый CBAC, он, по-моему, называется, если я правильно помню, либо reflective access-листы — ещё более старые, старинные. Мы можем использовать несколько типов фильтрации. Либо по реализации это могут быть какие-то выделенные устройства безопасности — тот же самый Cisco ASA, который является в первую очередь устройством безопасности, файрволом. Мы про ASA будем завтра, в понедельник, уже разговаривать. Просто запомните, что ASA — это всё-таки в первую очередь файрвол, и ставить его в качестве роутера не всегда оправданно. ASA не умеет быть хорошим роутером. С другой стороны, и роутер не умеет быть уж очень

хорошим файрволом, таким же как ASA. Какие ещё бывают реализации: просто в виде программного обеспечения на конечных хостах — либо это в UNIX-системах может быть iptables, или во FreeBSD что там сейчас модно — pf, и всякие. Windows тоже имеет свой firewall встроенный, который, кстати, не такой уж плохой, и я бы даже сказал — очень неплохой. Либо есть комплексные системы безопасности — это очень интересная вещь, которая стала развиваться в последние годы, может быть в последние 10 лет. Это системы, которые будут интегрировать ПО конечных устройств с устройствами безопасности. Мы немножечко про это обзорно поговорим в последнем модуле. Как пример: когда устройство безопасности видит вредоносный трафик, исходящий от хостовой системы, от конечной системы, и оно будет

управлять программным обеспечением на конечном хосте — не просто блокировать трафик у себя, железка, а ещё будет давать команду своему клиенту, грубо говоря, на конечный хост что-то там ещё сделать, заблокировать, например. И такие реализации есть сейчас, такие реализации практически у всех вендоров уже появляются. Тот же Cisco AMP, или вот у Fortinet, с которым я сейчас начинаю работать, — у него тоже такое есть, похожее. Сейчас это у всех вендоров. Какие требования предъявляются к реализации файрволов? Понятно, что они должны быть устойчивы к атакам. В первую очередь файрвол занимается фильтрацией трафика между сегментами, между зонами, но это не отменяет

того, что сам файрвол может являться вектором угрозы. Поэтому сам файрвол тоже должен иметь какие-то средства защиты самого себя, не просто периметр, который он защищает — это важная вещь. Как пример плохой реализации — производительность заведомо ограничена. Иннокентий, пожалуйста, можешь дополнить. Да, от DDoS-атак файрволом понятно, что не отбиться, потому что если DDoS-атака направлена на сам файрвол — тут уж пиши пропало. Но с другой стороны, от угроз он должен быть защищён. Просто как пример не очень хорошей реализации — файрвол

самодельный, на основе какого-нибудь пакетного фильтра типа iptables. Если кто-то работает с Linux-системами, он прекрасно знает, что iptables — достаточно гибкая, мощная и удобная штука, она классная. Но неправильное проектирование защиты с помощью iptables зачастую приводит к тому, что проходящий трафик будет фильтроваться прекрасно, а вот сам хост, на котором этот iptables работает, он к атакам может быть неустойчив — может быть за счёт какого-то дополнительного ПО, которое будет на этом же хосте крутиться. И часто так бывает: например, ставят какую-то обычную x86-машину в качестве файрвола, настраивают на ней файрвол и тут же прилепляют туда DNS-сервер,

какой-нибудь, который извне доступен, непропатченный, непонятно древней версии, и мы получаем вроде как файрвол, который прекрасно всё фильтрует, но с уязвимым DNS-сервером где-то сбоку. Такое встречается сплошь и рядом. Поэтому первое требование — что сам файрвол должен быть устойчив к атакам. Файрвол должен являться единственным способом транзита между зонами. Если файрвол можно как-то обойти — я не говорю сейчас про методики обхода файрволов специальные, а просто если есть какой-то ещё маршрут в обход — такой файрвол просто бесполезен и не нужен. Второй канал связи, например, — тогда смысла в этом файрволе никакого нет. Мы говорили про то, что система защищена настолько, насколько её самое слабое звено. Если есть какой-то просто

канал без защиты в обход файрвола — вся ценность файрвола будет равняться надёжности этого канала. Файрволы должны быть сконфигурированы на основе политик безопасности. Ещё раз повторяю свою мысль, которую я вам озвучил уже раз пятьдесят: сначала пишется политика безопасности, сначала в этой политике безопасности прописываются правила файрвола, какие-то правила фильтрации между зонами, и только потом на основе этого конфигурируется железо. Ни в коем случае не наоборот — не сначала написать правила, а потом их занести в документацию, а поступить так, как нужно. Это важная штука, и ей нельзя пренебрегать. И, как опять же мы говорили, firewall не должен являться единственным компонентом безопасности. Эшелонированную защиту никто не отменял, и это то, к чему нужно стремиться — просто одним файрволом в

настоящее время, увы, никаким образом нельзя защититься. Кирилл задаёт вопрос: интересно, если, скажем, ещё есть одна зона с серверами — тот же AD, с которым должны общаться серверы из DMZ. Кирилл, в таком случае, если говорить про Active Directory, есть такая вещь, как Read-Only Domain Controller, например, который специально для таких применений создан. Иннокентий меня поправит, если неправильно говорю, но есть возможность поместить один из домен-контроллеров в DMZ, который будет доступен только для чтения, с минимально ограниченными правами. Только таким образом. Либо же придумывать какие-то схемы. Можно в принципе access-листами,

можно каким-то образом организовать более-менее защищённый канал к домен-контроллеру внутри, то есть какой-то трафик разрешить, например, только LDAP к домен-контроллеру и обратно. Можно что-то разрешить — это всё будет зависеть от конкретного сценария. Но, например, антиспам на роли, который должен туда ходить, — ему же можно дать минимальные права в Active Directory: только на чтение чего-то, без возможности какой-то записи, и только к конкретным веткам нужной информации. Ничего страшного особо не будет: если тот же антиспам — если вдруг почтовый сервер будет взломан, то

единственное, что можно будет получить от контроллера домена, — эту информацию, нужную для антиспама, и всё. Так что здесь принципы эшелонированной защиты должны работать: надо подумать не только, как на файрволе разрешить только нужное, но и как на контроллере домена разрешить только то, что нужно, — принцип минимальных привилегий. Всё правильно. Теперь по типам файрволов — какие бывают файрволы. Самые простые файрволы — это пакетные фильтры, stateless. Stateless — это значит, что эти фильтры не умеют хранить никакого состояния. Они ничего не знают о потоках — мы с вами разобрали понятие «поток» — они ничего не знают о потоках, которые через них проходят. Они просто фильтруют пакет за пакетом, больше не делают ничего. Про состояние мы сейчас поговорим. Единственное, что они умеют делать: пакет пришёл,

они его по каким-то своим правилам сравнили — прошёл, пустили; не прошёл — выбросили. Access-лист, обычный access-лист на роутере — это пример такого пакетного фильтра. Он односторонний, он работает только в одну сторону, ничего не знает ни о сессиях, ни о чём. Состояние здесь имеется в виду, например, сессии TCP, либо потоки UDP, когда мы получаем какой-то пакет, запоминаем, откуда-куда этот пакет шёл, на какой порт, и ответный трафик разрешаем. Но это мы сейчас дальше будем про это говорить. Обычные пакетные фильтры этого ничего не умеют, они принимают решение просто на основании содержимого пакета. Они смотрят заголовки — Ethernet, IP, TCP, и на основе этого будут смотреть, например, номера портов, либо ICMP-типы

сообщений — всё, больше ничего не будут делать. В коммутаторах и маршрутизаторах — это access-листы у нас. Stateful firewall — это файрвол уже с сохранением состояния. Они будут работать на основании сессий, у них появляется понятие сессии. Например, TCP: когда изнутри проходит пакет с флагом SYN, они записывают в свою маленькую чёрную книжечку — в специальную таблицу, она общее название state table, таблица состояний, — они будут записывать, что от такого-то хоста на такой-то адрес прошёл пакет SYN, номера портов запишут, и они будут держать пометку: значит, потом пойдёт SYN-ACK, началось установление сессии. Они уже знают про эту сессию, и когда пойдёт ответный пакет SYN-ACK, они будут знать, что

тот хост внутри этого пакета ждёт, вот с этого адреса, от этого порта, и они его пропустят в обратную сторону. Если бы мы работали с обычными access-листами, с обычными пакетными фильтрами, stateless, нам пришлось бы писать и с одной стороны, и с другой стороны файрвола, на двух интерфейсах сложные правила, чтобы пускать обратный трафик, со всем этим заморачиваться — вот как раньше делали, всякие reflective access-листы, там, очень давно. Stateful firewall — они умеют это делать, они сами контролируют состояние, они уже будут принимать решение на основании состояния этих сессий. Они будут записывать: если дальше пойти, тот же флаг RST прошёл — всё, значит,

сессию нужно терминировать, они из своего списка, из таблицы состояний это вычёркивают. Они будут всё время это контролировать. Они могут контролировать уровни приложений даже, потому что сейчас мы посмотрим примеры. С помощью access-листа в такой конфигурации достаточно указать только стартовый пакет сессии — нам достаточно указать просто одно правило, что вот отсюда сюда можно, а дальше такие файрволы уже будут весь следующий трафик в этой конкретной сессии обрабатывать самостоятельно. Что важно: есть протоколы с динамическим согласованием параметров, например FTP, или SIP, когда SIP работает, потом RTP запускает — там очень много динамических согласований, они друг другу там говорят. Современные нормальные файрволы, stateful, они будут именно следить за

обменом на уровне приложений, на седьмом уровне, и на основании этого уже строить понятие сессии, отслеживать трафик приложений и разрешать трафик в одну и другую сторону. Очень жизненный пример — обработка FTP, как классический пример stateful firewall. Если кто-то не знает, то FTP — это абсолютно наркоманский протокол, разработанный в седые времена, когда не было файрволов. Роман, он действительно — я не знаю, кто его писал, но это Америка, шестидесятые годы, Вудсток, все эти дела, то ли BSD, то ли LSD — не поймёшь. Но правда, протокол

действительно сложный — сложный в смысле его работы в современной сети. В совсем современной сети с ним научились справляться, появилось множество костылей. А вот именно для классической фильтрации — там вообще ничего не понятно, как его фильтровать, как через NAT он будет работать. Тогда таких задач не было. Протокол в принципе очень простой. У него есть активный режим и пассивный режим. Активный режим — это когда клиент подключается к серверу, он использует 21-й порт для подключения к серверу и говорит: слушай, сервер, я тут хочу с тобой обмен делать, пожалуйста, вот мой порт для данных — там 1020. Клиент серверу говорит порт, а потом сервер в ответ подключается. Но с точки зрения обычного пакетного

фильтра: что за фигня, почему какой-то непонятный сервер подключается в нашу сеть на какой-то неизвестный порт — это ненормально. Потом сервер устанавливает соединение, и пошли данные. Такая ситуация для обычного пакетного фильтра, конечно, не очень хорошая. Активный режим как раз не будет работать в большинстве случаев именно с фильтрацией — только если firewall умеет отслеживать состояние сессии. Если у нас достаточно умный firewall, он умеет читать служебные сообщения протокола FTP — вот только тогда firewall догадается, что клиент сообщил серверу номер своего порта, и значит, надо серверу разрешить подключение на этот порт до клиента. Вот такая штука. Прошу прощения, 1010 у нас здесь неправильно. Иннокентий, можно голосом.

Пассивный режим, наверное, голосом будет проще. Иннокентий, по поводу FTP — немножко истории. Сегодня он управляется действительно по 21-му порту, ставишь сессию, и там в принципе plain text идёт управление. Если ты хочешь, можешь подключиться и отдать команду на открытие порта передачи данных, того самого 20-го, например. А исторически на самом деле там именно чистый классический Telnet был: ты подключался Telnet-ом на FTP-сервер и заказывал, куда сервер к тебе должен подключиться уже по протоколу передачи данных, уже по FTP самому. На самом деле вторичная сессия — FTP, 21-й порт — это командная сессия, которая когда-то исторически была Telnet-ом. Я вот не знал про это, спасибо большое. Там был прямо именно Telnet отдельный, можно было говорить, и потом передача данных была. Классно. Вот так активный режим. Пассивный —

он немножечко проще и файрволами обрабатывается лучше. Это когда клиент подключается на сервер, 21-й порт — он управляющий всегда, а сервер потом уже договаривается, конечно, и все современные реализации FTP — они сначала договариваются. Там можно клиенту принудительно сказать, чтобы он говорил, что я пассивный. В данном примере клиент говорит PASV — я пассивный, давай-ка мне свой порт, и тогда сервер сообщает номер порта, куда подключиться. Устанавливается вторая сессия, и здесь файрвол видит два исходящих: сначала первое исходящее соединение из нашей сети, потом второе исходящее соединение — здесь немножечко попроще, но всё равно firewall это должен уметь обрабатывать. И если это простой пакетный фильтр, то достаточно сложно будет

наладить работу того же самого FTP. Это такой простой пример приложения, которое в своей сессии, в своём обмене сообщениями согласует сетевые параметры. Также примерно похожее происходит в телефонии, когда есть протокол SIP для сигнализации. Обычно говорят: голос идёт по SIP. По SIP не идёт никакой голос — идёт просто сигнализация. По протоколу SIP клиент с сервером договариваются о портах, по которым дальше будет работать уже другой протокол — RTP, Real-time Protocol, по которым уже собственно пойдут голосовые данные. Современные файрволы умеют как раз уже на уровне приложений читать эту информацию — она обычно plain text идёт — и открывать нужные порты. Но в принципе задача файрвола — просто пустить пакет или не пустить пакет, если говорить про обычную фильтрацию.

Прокси-серверы — это тоже отдельный тип файрвола. Андрей, доброй ночи. Прокси-сервер — это тоже отдельный тип файрвола, но реализованный прямо для конкретного протокола уровня приложений. Когда мы говорим про прокси-сервер, мы не имеем в виду железку, которая умеет всё на свете. Нет, прокси-сервер — это узкоспециализированная штука, которая просто перехватывает соединение от клиента и уже от себя устанавливает соединение с сервером. Главная идея любого проксирования — то, что сервер не видит вообще, кто к нему подключился. Соединение с сервером будет устанавливать не клиент, а прокси. NAT нельзя назвать прокси-сервером, потому что всё-таки

во время NAT мы не устанавливаем соединение. Железки, которые занимаются NAT, — NAT — штука прозрачная. А в случае с прокси-сервером, например, обычного веб-прокси, всё-таки тот же браузер должен сначала установить соединение с прокси-сервером — в нём может быть браузер настроен, либо прозрачное перенаправление, но всё равно соединение устанавливается с прокси — прямо конкретное, в случае веб, TCP-соединение, а потом он уже от своего имени делает запросы. Вот это главный смысл прокси-сервера: сервер и клиент никаким образом не общаются напрямую. Фильтрация на прокси-серверах возможна — они будут фильтровать, заточены прямо под конкретный протокол. Мы сказали, что это узкоспециализированная штука. Плюс

у прокси-серверов всякие дополнительные функции: например, веб-прокси умеют рекламу всякую блокировать, либо антиспам, если говорить про почтовые прокси. Аутентификация, авторизация — это уже не задача фильтрации, это задача параллельная, но на прокси-сервере это тоже можно делать. Cisco Web Security Appliance — да, это прокси. WSA — это прокси именно. Другое дело, что он может работать в прозрачном режиме — на него перенаправляется трафик, но TCP-соединение с клиентом он устанавливает. Дальше — так называемые Next Generation Firewall — это то, что мы видим в последнее время, это комбайны. В последнее время

все функции фильтрации, иногда и проксирования, и всего остального уже сосредотачиваются на одном устройстве. Если раньше, я помню, 15 лет назад настраивал на разных устройствах — здесь у меня прокси-сервер, здесь у меня антиспам-сервер, здесь у меня прокси-сервер ещё и от вирусов фильтрует, может быть, а отдельно у меня firewall, который пакетной фильтрацией занимается, — то сейчас это всё вместе уже объединяется, и эти вещи называются Next Generation Firewall. Например, решение от Cisco, которое мы как пример приводим — курс всё-таки по Cisco — называется Firepower. Они умеют, кроме обычной классической фильтрации, и по

URL можно фильтровать, и контроль приложений — обрабатывать трафик приложений, каким-то образом уже на седьмом уровне работать. Обнаружение и предотвращение вторжений — тот же IPS. Сейчас отдельно, как отдельное железо или отдельное программное обеспечение, встречается всё реже и реже. Комплексные решения безопасности уже содержат и IPS, и защиту от вредоносного кода, и потоковые антивирусы, и антиспам, и всё на свете. Доступ на основе идентификации либо контекста доступа. Когда «контекст доступа» — здесь не надо путать с контекстом Cisco ASA, с виртуализацией встроенной. Контекст доступа здесь имеется в виду, что в настоящее время недостаточно уже производить какую-то фильтрацию только по IP-адресу, либо по имени пользователя.

В настоящее время такие системы безопасности, такие комбайны будут смотреть на контекст. Контекст будет объединять в себе совокупность понятий: кто пришёл, откуда пришёл, в какое время пришёл. Будет и аутентификация, и авторизация по времени, и проверяться источник. Плюс там может проверяться куча параметров — это не просто запрос на внешний веб-сервер с какого-то IP-адреса, а это будет конкретный Вася, который сидит сейчас на компьютере с таким-то IP-адресом, с такой-то операционной системой, где установлен конкретный антивирус без обновлений, и он ещё ночью зашёл — значит, Васю точно не пускать. Вот это контекст — именно в этом контексте

Вася сейчас находится. Не просто потому, что это Вася, на основе идентификации. Термин «песочница» больше относится к антивирусам, хотя сейчас термин «песочница» расширяется. Вообще, песочница — это какое-то безопасное окружение, где можно запустить какой-то программный продукт, там проверяются угрозы. Как пример — это всё-таки реализовано больше в антивирусах: когда файл, который недоверенный, который антивирус считает недоверенным, — он сначала предлагает либо пользователю запустить в безопасном окружении, так называемой песочнице — sandbox, либо может сам даже запустить этот файл. Исполняемый, скажем, экзешник — проверить его работу, не будет ли нарушена работа системы. Он запускает файл и смотрит системные вызовы, куда этот файл ломится,

какие он пытается прочитать директории на жёстком диске и так далее. Это запуск файла. Песочница больше к файлам относится — запуск файла в безопасном окружении, когда по факту ничего страшного произойти не может. Вот это песочница. Можно сказать, у Fortinet есть отдельное решение типа sandbox, централизованная песочница, но этих песочниц можно придумать не так много — либо это всё будет на конечном хосте обрабатываться, как делают обычные антивирусы, либо это будет обрабатываться централизованно на каком-то железе. Например, потоковый антивирус может файл,

проходящий через него, выцепить из трафика и посмотреть, что это за файл, даже у себя. Но если это потоковый антивирус, каждый экзешник подразумевает своё. С мишенью здесь очень просто — на конечном хосте с антивирусом всё понятно: если придёт исполняемый файл, написанный под систему FreeBSD, он не определится как исполняемый файл и не запустится на системе — зачем его проверять в таком случае, если на конечном хосте. А всё зависит только от реализации конкретного антивируса. Если этот антивирус может проверять исполняемые файлы для многих операционных систем, он это будет делать. Так что я не специалист по антивирусам, к сожалению, я просто могу объяснить, что такое песочница. А момент реализации, как это реализуется, я правда не могу объяснить. Я так думаю, что там можно очень много типов анализа хитрого придумать, так чтобы

в песочнице нет виртуальных машин, там даже... Грубо говоря, это как виртуальная машина — создаётся окружение. Что такое окружение? Окружение — это не виртуалка даже, это когда файл запускается, но ему не дают совершать никакие системные вызовы. Вызовы, например, обращение к диску — по факту не происходит. Просто запускается исполняемый файл, ему дают область памяти защищённую, и программа, которая организует песочницу, следит за его вызовами, а по факту никуда ему не разрешает ломиться — он ничего в системе не порушит. Безопасный запуск. Вот так эта штука работает. В смысле по временной лицензии работает? Он и со старыми сигнатурами работает, почему нет.

Я не знаю, я просто ещё раз оговорюсь — я сейчас не работаю с Cisco, с современными самыми последними решениями. Возможно, что может быть и так. Лицензия нужна, да, а с просроченными сигнатурами прошлого года — никто не запретит вам работать, я так думаю, хотя может что-то изменилось за последние годы. Кто знает. Да, Кирилл, я согласен, что песочница тоже не панацея. Они конечно могут обнаружить, потому что вредоносный вирус какой-нибудь запускается, пытается получить доступ к запуску файла или к ветке реестра. Если он обнаруживает, что ему этот доступ не дают, он просто дальше не работает или как-то модифицирует сам себя.

С другой стороны, приложения, которые его запускают, они тоже всё более интеллектуальными становятся — ему можно тоже подсунуть те вызовы, которые он просит, и подсунуть мнимые какие-то данные. Так что здесь кто кого перехитрит. Ладно, давайте дальше — мы про фаерволы сейчас говорим, но тема песочниц и антивирусов конечно интересна. По поводу журналирования — последнее напоминание нам о том, что фаерволы действительно генерируют огромное количество данных. Сохранение этих данных нам нужно по тем причинам: для обнаружения атак в момент их зарождения. Действительно, мы с вами говорили, что журналирование может служить не только как запись уже состоявшихся действий, но и как превентивная мера. Это важно понимать. Почему я всё время говорил, что только автоматизированными средствами должно производиться — потому что

реальная обработка логов в реальном времени тоже для безопасности может очень хорошую службу сослужить. Те же самые фаерволы будут генерировать какие-то данные, какие-то алерты в случае обнаружения непонятного трафика. Или как IPS — также поступает. IPS, система предотвращения вторжений, обнаружения — при обнаружении какого-то неясного трафика всегда сигнализирует в тот же самый syslog, и вовремя выцепить это сообщение из syslog и просигнализировать дальше куда-то администратору — это бесценно, это очень полезное действие. Поэтому реалтаймовая обработка логов тоже нужна. Не стоит рассматривать логи как просто журналирование того, что уже случилось — логи могут ещё сослужить хорошую службу. С другой стороны, есть ещё такие вещи, как SNMP. Мы вчера говорили немного о том, как мониторинг SNMP хорош, но в него тоже

не всё запишешь и не всё им прочитаешь. Системы защиты, как фаерволы либо фаерволы next generation, развиваются намного быстрее, чем развиваются системы мониторинга. Так что как средство управления он устарел уже сто лет назад. Давайте на этом сегодняшнее занятие заканчивать. Завтра мы будем говорить про CAS... Не завтра, прошу прощения, в понедельник. Я понял, что вы меня уже завтра за это завтра сейчас сожрёте. Запись останавливаю. Пятый день у нас курса прошёл продуктивно, я считаю.