Установка и настройка filtering firewall

Обновлено: 03.07.2024

Правильная настройка межсетевого экрана способна ограничивать данные, которые входят в компьютер из интернета или исходят из него.

Многие программы после установки пытаются сразу выйти в сеть и даже отправлять своим разработчикам какие-то ваши данные.

По причинам безопасности, в первую очередь, нежелательно, чтобы это происходило. Поэтому приходится использовать на компьютере такую программу, как межсетевой экран.

Содержание:

Межсетевой экран или Firewall, в переводе Огненная стена, это специальная программа, которая применяется на компьютерах, чтобы ограничить такие самовольные действия.

С помощью файрвола можно жестко обрубать действия любой программы, которые каждую неделю надоедают о выходе в свет последней версии. Поэтому подобная программа может пригодиться практически всем.

Установка межсетевого экрана Comodo

Часто применяется файрвол компании Comodo, в частности потому, что он не конфликтует с другим антивирусным программным обеспечением, установленным на компьютере.

Начинается загрузка, файл нужно сохранить и затем запустить. Лучше не забыть, что кроме файрвола на компьютер необходимо установить какое-либо антивирусное решение.

При установке предлагается выбрать русский язык, жмем OK. Затем убираем все чекбоксы, чтобы избавиться от ненужной информации.

Затем жмем на кнопку Согласен. Перейти на предыдущем скриншоте и начинается процесс установки.

Если все пройдет успешно, то на рабочем столе появится виджет. Его можно сразу отключить, потому как излишние сведения на рабочем столе ни к чему.

Настройка межсетевого экрана

Правой кнопкой мыши нажимаем по нему и убираем чекбокс Виджет – Показать. После небольшой паузы межсетевой экран приступит к нахождению сети. Указываем программе, где мы находимся – Я нахожусь дома, например.

После чего программе нужно перезагрузиться. Затем появится окно приветствия, внизу устанавливаем чекбокс Больше не показывать это окно.

Внизу справа в трее находим значок firewall и запускаем программу. В открывшемся окне нажимаем Задачи – Расширенные настройки.

В окошке в левой части находим Настройки Файервола и изменяем вверху Безопасный режим на Режим обучения.

Вначале экран сам разберется, каким приложениям необходим интернет, когда мы их запускаем.

После того, как обучение пройдет, то для всех остальных программ на компьютере доступ к интернету можно запретить. Чтобы межсетевой экран нормально функционировал, требуется выполнить еще кое-какие настройки.

Нужно убрать чекбокс Использовать HIPS. Это достаточно назойливая опция, которая старается взять на себя функцию антивируса.

Файрвол имеет игровой режим и если есть желание играть в онлайн игры, то эту функцию можно включить, чтобы не возникало никаких проблем.

Обучение Comodo

Для того, чтобы быстро научить межсетевой экран разрешать всем нужным приложениям выход в интернет, их необходимо запускать. Эти программы будут просить выход в интернет, файрвол начнет их выпускать и при этом самостоятельно составлять правило.

После того, как все приложения будут запущены, нужно запретить их выход в интернет без нашего разрешения. Затем в меню настройки файрвола необходимо заменить режим обучения на Пользовательский набор правил.

Таким образом, установка и правильная настройка межсетевого экрана дает возможность целиком и полностью держать под контролем канал выхода в интернет и входа из него на своем компьютере, что значительно повышает вашу безопасность.

Файрвол, как и многое другое в RouterOS, пришел из Linux и представляет собой доработанный iptables. Поэтому многие мануалы по настройке iptables легко можно сконвертировать в формат RouterOS. Файрвол состоит из следующих таблиц:

Filter — занимается фильтрацией трафика — определяет, пропустить пакет в сеть или отбросить его. Мы будем рассматривать работу только этой таблицы;
NAT — Network Address Translation. Изменяет проходящие пакеты. Поменять адрес источника или порт назначения — дело именно этой таблицы. В основном она используется для обеспечения доступа в интернет из локалки и обратно. Иногда без NAT невозможно работать в плохо спроектированных сетях, а еще его, бывает, используют в качестве «костыля»;
Mangle — классифицирует и маркирует трафик и может менять некоторые поля в заголовке (TTL, ToS, DF). Применяется для построения сложных путей трафика (например, когда подключено два провайдера или нужны разные пути трафика для RDP и VoIP);
Raw — обрабатывает пакеты до их попадания в Connection Tracking. Пригодится для защиты от DoS или при работе с большими объемами трафика.

Таблицы состоят из цепочек. Цепочки в разных таблицах могут отличаться. Чуть позже станет ясно почему. В нашей таблице Filter три цепочки:

input — трафик к самому роутеру. Обязательное условие попадания в input — адресом назначения пакета должен быть один из адресов роутера, широковещательный адрес сети или широковещательный адрес работающей на роутере службы. Сюда попадает WinBox, SSH, WebFig, ping, VPN и другой трафик, предназначенный роутеру. Полный список можешь посмотреть в вики. В этой цепочке мы должны защищать сам роутер;
output — трафик от роутера. Ответы на прилетевшее в input или новые пакеты от роутера (пинг, VPN, SSH-сессия с самого роутера). Эта цепочка редко используется, так как часто роутер считается доверенным звеном и пакеты, генерируемые им, по умолчанию легитимны. Но, как показывает история взломов, контроль исходящего трафика может выявить заражение на начальных этапах;
forward — трафик, проходящий через роутер (когда пакет прилетел в один интерфейс и вылетел с другого или того же самого). Трафик из локалки в интернет, из интернета в локалку, из одного VLAN локалки в другой;
user chains — пользовательские цепочки. Админ может создавать цепочки правил по своему усмотрению. Это бывает полезно для декомпозиции больших конфигураций. К примеру, можно весь трафик на порты 80 и 443 завернуть в отдельную цепочку WEB и в ней уже делать десятки правил для фильтрации — это визуально упростит настройку, хотя качественно на прохождение трафика не повлияет.

Два важных момента, о которых нужно помнить.

Момент первый. У трафика в forward всегда есть входящий и исходящий интерфейсы — трафик влетел в input, обработался процессом маршрутизации и должен вылететь в output. У входного трафика не может быть исходящего интерфейса — он обработается внутри роутера и никуда дальше не полетит. Также у выходного трафика не может быть входящего интерфейса — этот трафик генерируется самим роутером (это либо новый трафик, либо созданный роутером ответ на трафик, пришедший в input).

Момент второй. У трафика не существует «внешнего» или «внутреннего» интерфейсов. Роутеру плевать, что ты считаешь внешним, — для него есть интерфейс, в который трафик вошел, и интерфейс, с которого трафик уйдет.

Правила образуют цепочки. У каждого правила может быть только одна цепочка. По умолчанию политика у всех цепочек — все разрешено. Правила срабатывают в таблицах в зависимости от их порядка: сначала пакет обработается первым правилом, затем вторым и так далее. Хорошим тоном считается упорядочивать правила внутри таблиц по цепочкам: сначала — пачка правил input, затем — forward, в конце — output.

Трафик будет проходить по правилам только в пределах своей цепочки. И если сначала идет input, потом forward, затем снова input, то трафик input все равно никогда не попадет в forward, то есть такое расположение правил не повлияет на прохождение трафика, а только запутает админа. В пределах одной таблицы пакет не перепрыгнет из одной цепочки в другую, пока админ это явно не укажет.

table_chain_rule

Connection Tracking

Еще одна важная вещь для понимания работы файрвола — механизм определения состояния соединений — Connection Tracking (или просто ConnTrack). У RouterOS есть специальная таблица, в которой хранятся данные о состоянии соединений. Благодаря ей работает NAT и многие другие части файрвола.

Механизмы ConnTrack проверяют, принадлежит ли пришедший на роутер пакет какому-либо из потоков, чтобы применить к нему политики всего потока или как-то упорядочить пакеты в пределах одного или нескольких потоков (например, для нарезки скорости).

Для ConnTrack существуют четыре состояния пакетов:

new — новый пакет, не принадлежащий ни одному из известных потоков. Это может быть первый пакет для коннекта к серверу RDP, или первый пакет в потоке WinBox, или запрос к DNS. Система запоминает Source IP, Source Port, Destination IP, Destination Port и некоторые другие параметры и записывает эти данные в таблицу. Следующий пакет с такими же данными будет относиться к записанному потоку;
established — пакет, принадлежащий существующему потоку. То есть пакет, у которого Source IP, Source Port, Destination IP, Destination Port подходят под одну из записей таблицы ConnTrack (или обратный пакет);
related — пакет, порожденный другим потоком. Некоторые протоколы, такие как FTP, SIP, PPTP, используют для работы несколько потоков. Например, управляющие команды FTP ходят по порту TCP 21, но данные передаются с порта TCP 20. При попытке получения или отправки данных на FTP в потоке на порт 21 сервер сообщает: «А сейчас я открою 20-й порт, и ты забирай данные с него», после этого клиент посылает пакет на 20-й порт сервера. Этот пакет будет считаться related, так как он порожден потоком 21-го порта;
invalid — все, что не относится к перечисленным выше состояниям. Пример: сессия корректно закрылась, но из-за ошибок маршрутизации часть пакетов из середины сессии улетела другим путем. Когда они пришли, их сессия уже закрыта и роутер о них ничего не знает. Они не new и не относятся к существующим соединениям, поэтому считаем их invalid.

Состояние потока не связано с флагами TCP: SYN, ACK, FIN. Для UDP и других stateless-протоколов в таблице ConnTrack тоже содержатся все возможные состояния.

Работа ConnTrack требует ресурсов процессора и при больших объемах трафика может существенно нагрузить CPU. Но ConnTrack нужен не везде, и его можно отключить. Например, у провайдеров на стыке с вышестоящим провайдером стоят роутеры, которые молотят десятки гигабит трафика. На этих роутерах, как правило, нет NAT (прямая маршрутизация), а трафик фильтруется уровнем ниже, чтобы не перегружать и без того нагруженный бордер. То есть в этом случае ни к чему проверять каждый пакет на принадлежность какому-либо потоку.

Нажав кнопку Tracking, можно отключить механизм ConnTrack или подкрутить таймеры. В большинстве случаев тебе не понадобится заходить в эти настройки, но знать о них нужно. Режима ConnTrack три: что такое yes и no , думаю, понятно, а в режиме auto ConnTrack выключен до тех пор, пока хотя бы один пакет не попадет в существующие правила таблицы NAT или Filter.

WARNING

Выключенный ConnTrack ломает NAT и фичи файрвола, основанные на трекинге потоков: connection-bytes, connection-mark, connection-type, connection-state, connection-limit, connection-rate, layer7-protocol, new-connection-mark, tarpit.

Траблшутинг

Когда файрвол не работает или работает не так, как подразумевалось при настройке, виноват админ. Магии не бывает. Первое, на что стоит обратить внимание при траблшутинге, — счетчики пакетов. Если счетчик не увеличивается, значит, трафик в него не попадает. А если трафик не попадает, значит, либо этого трафика просто нет, либо он был обработан стоящим выше правилом.

Ты же помнишь, что правила файрвола работают по принципу «кто первый встал — того и тапки»? Если пакет попал под действие правила, то дальше он уже не пойдет. Значит, нужно искать проблему выше. Просто копируем наше правило, action ставим accept (для траблшутинга не делай дроп — так при проверке можно сломать себе доступ или нарушить работу сети) и постепенно двигаем его наверх до первого увеличения счетчиков в этом правиле. Если через это правило уже проходил трафик, то счетчики будут ненулевые и можно пропустить нужные нам пакеты, — просто сбрось счетчики в этом правиле или во всех кнопками Reset Counters.

Reset Counters

Предположим, мы нашли правило, в которое попадает наш трафик, а попадать не должен. Нужно понять, почему так происходит. В этом нам поможет опция Log. Во вкладке Action ставим галочку Log (можно написать префикс для правила, чтобы было проще отлавливать его в логах) и смотрим логи, где написаны все характеристики пакетов, попадающих под правило. Среди характеристик: цепочка, входящий и исходящий интерфейсы, адреса и порты источника и получателя, протокол, флаги, размер пакета, действия NAT.

Если даже в самом верху в правиле не будут увеличиваться счетчики, убирай правила из условия по одному. Начинай с интерфейсов — админы часто путаются в своих представлениях о том, откуда или куда должен идти трафик (например, при коннекте к провайдеру через PPPoE или в туннелях между филиалами или сложном роутинге). Счетчики пошли? Включаем лог и смотрим интерфейсы и другие параметры.

Если и это не помогает — пришло время тяжелой артиллерии. Идем в Tools → Torch и изучаем трафик на роутере. Может, ожидаемого трафика вовсе нет. Еще один крутой инструмент — аналог tcpdump — Tools → Packet Sniffer. Разбор работы этих инструментов тянет на отдельную статью (если она тебе интересна — сообщи об этом в комментариях к статье).

Чтобы упростить траблшутинг, можно использовать функцию комментирования. Если из-за комментов окно становится слишком большим и это мешает смотреть на правила, воспользуйся инлайновыми комментариями (Inline Comments). Так комменты встанут с правилом в одну строку и в окно будет умещаться больше правил.

Inline Comments

Также рекомендую распределять правила по порядку, следуя какой-то определенной логике. И старайся ее поддерживать на всех роутерах.

Итоги

В этой статье приведены только основы настройки файрвола и главные методы диагностики. Кроме RouterOS, эти принципы применимы и для Linux. В следующей статье разберем более сложные правила, которые позволяют защититься от не самых простых атак, и разберем цепочку Forward, а также создадим свои цепочки.

Типовая настройка firewall MikroTik, адаптированная для большинства случаев. часть 1

За несколько лет работы, мы для себя нашли некоторую золотую середину в настройке Firewall MikroTik, и естественно хотим поделится её с вами.

MikroTik Firewall Filter

Хочу признаться мне не очень нравиться дефолтный конфиг Firewall, но я прекрасно понимаю, что тем кто его придумал, была задача найти условно общую конфигурацию которая бы подходила к большинству и покрывала решение зада большенства, но мы не большинство, и будем "лепить" свой конфиг.

Естественно чистим конфигурацию или просто очищаем полностью Filter Firewall-а.

В первую очередь мы должны защитить наш маршрутизатор от условных проблем, атак или злоумышленников из сети интернет.

Interface List ISP

В моём случае для примера у меня три провайдера ether1, ether2, ether3 и поверх ether3 запущен PPPoE туннель для получения доступа к интернету.

Создадим лист интерфейсов в котором перечисляем все интерфейсы подключенные к сетям провайдеров. Причём не важно один или два или десять у вас таковых интерфейсов.

Как вы его назовёте, не имеет значения, главное чтобы вам был понятен смысл имени и наверное очень важно, то что-бы было понятно любому другому человеку который взглянет на ваши настройки. Ведь согласитесь если вы его назовёте "Bla-bla-bla" смысл для любого человека будет непонятен, хотя возможно для вас он и будет иметь сакральный смысл.

Я предпочитаю называть данный лист ISP, что обозначает Internet Service Provider.

Соответственно добавляем в данный лист все интерфейсы провайдеров.

Обратите вниманию я добавил ether3 и PPPoE интерфейс которые поднят через него же. По поводу наименование PPPoE туннеля не удивляйтесь у меня есть привычка использовать в наименовании интерфейсов точку в случае если данные интерфейс является sub интерфейсом другого интерфейса. К примеру если у меня будет vlan 100 на первом интерфейсе его имя будет ether1.100.

На данный момент, мы закончили с настройкой листа ISP и может приступить непосредственно к настройке Firewall.

Firewall Filter

Начнём непосредственно настраивать наш filter.

Firewall Filter Input

Первым делом мы будем настраивать трафик который пришёл на маршрутизатор, и является потенциально опасным для маршрутизатора.

Все дальнейшие правила мы делаем в разделе фильтра, я не буду указывать в приведённых примерах.

Самым первым правилом отправляем весь трафик с интерфейсов провайдеров в кастомную цепочку (custom chain) с помощью jump.

С этого момента мы будет работать ТОЛЬКО с цепочкой ISP-Input , про цепочку input можете пока забыть, хотя она нам ещё понадобится.

Следующим правило мы разрешаем, пакеты established которые возвращаются на уже установленное соединение, такие пакеты необходимо разрешать.

Обратите внимание что я не указываю не интерфейсы не список интерфейсов, нам нет необходимости этого делать, так как самое первое правило отправило в данную цепочку только трафик которые приходит с интерфейсов провайдеров перечисленных в листе ISP.

Следующее правило разрешаем related , это пакеты которые создали вторичное соединение, такие пакеты помечаются когда на основании какого либо payload создаются новые соединения, например если вы используете NAT-helper ftp или SIP. Также related в некоторых случаях это ICMP ответ маршрутизатора.

Мы часто используем возможность снижение нагрузки на connection-tracker с помощью исключения пакетов с помощью raw untracked, также используется для обхода NAT в случае когда необходимо исключить процедуру изменения заголовка пакета.

Кто-то из вас скажет, "Стоп-стоп но ведь мы может все эти три последние правила описать одним, просто перечислив состояния через запятую. Зачем создавать три правила?!" Да можем, но моя задача во-первых показать вам все правила наглядно, а во вторых у нас появляется возможность видеть количество трафика и нагрузку pps по каждому конкретному типу пакетов, и в случае необходимости изменить порядок для оптимизации.

Ну что-же наше первое запрещающее правило, мы должны запретить пакеты с состоянием invalid , таким состоянием помечаются пакеты в нескольких случаях:

Если на вашем маршрутизаторе закончится память и connection-tracker не сможет создать запись для соединения, но это редкий случай.
Если пакет принадлежит к одному из протоколов GRE , ICMP или TCP то RouterOS умеет понимать по содержимому пакетов данных протоколов должен являться данный пакет частью существующего соединения или нет. Если по признакам он является частью соединения, но соединения нет в connection-tracker, то такой пакет помечается как invalid . Пример на маршрутизатор пришёл один пакет TCP с флагами syn и ack , т.е. Какой-то хост "по идеи" ответил на посылку syn пакета, но если соединения нет, то нам такой пакет не нужен. Также это простая защита от TCP RST Flood.

Как вы наверное знаете в RouterOS с включенным connection-tracker существует пять состояний пакетов, четыре из которых мы описали, а так как правила в firewall терминирующие, т.е после срабатывания правила пакет прекращает обработку в filter. У нас остаётся всего один тип пакетов это new это те самые пакеты которые создают соединения, другими словами когда кто-то инициализирует соединение к маршрутизатору такой пакет имеет состояние new . Но так как мы описали четыре состояния, нет смысла указывать состояние, так как подразумевается по остаточному принципу, что в следующем правиле и так будут только new .

Мне часто приходится настраивать RouterOS под проекты, и зачастую я подготавливаю оборудование так чтобы с ним было комфортно работать заказчику, так как со временем у заказчика могут появится дополнительные кейсы, и чтобы было однотипность в настройках мы поступаем следующим образом.

Выносим все разрешающие правила в отдельную цепочку например с именем ISP-Input-Allow . В таком случае нет необходимости думать в каком месте по порядку разместить правила, чтобы они были правильно расположены относительно всех других правил.

Следующим правилом мы запрещает все остальные пакеты, которые дошли до следующего правила. Будте аккуратны, возможно если вы подключены через провайдера к маршрутизатору, вы не сможете подключится к маршрутизатору в случае разрыва соединения.

Ну вот пожалуй с каркасом закончили, теперь нам необходимо разрешить какойто-то трафик на сам маршрутизатор.

Для закрепления результата представим, что у нас поднят на RouterOS l2tp сервер и мы хотим иметь возможность подключаться по ssh, а также маршрутизатор должен отвечать на запросы icmp.

Мы будем использовать кастомную цепочку ISP-Input-Allow и порядок правил в нём не важен, а также не важно расположение правил в этой цепочке относительно всех других правил, хоть в разнобой, хоть в конце, хоть в начале. Это не принципиально. Наверное всё таки для удобства желательно расположить их по порядку и в одном месте, но это только для тех кто использует winbox для настроек, а для тех кто используется CLI или как-то оркестратор типа ansible, как раз проявляется удобство в том, что вам не надо думать о прядке правил.

Опишу правила одним блоком

Если пакет которых поступает в данную цепочку дойдёт до конца её, то он перейдёт на следующее правило после которого он попал в данную цепочку.

Вот таким образом у вас должен выглядеть filter в winbox.

Я отформатировал вывод убрав отображение некоторых столбцов.

А теперь давайте посмотрим как будут работать данные правила, при поступления трафика в цепочку INPUT.

Первый пример HOST 5.5.5.5 хочет установить соединение с SSH MikroTik с адресом 2.2.2.2.

Хост 5.5.5.5 отправляет syn пакет для установления соединения с ssh сервером на MikroTik

Такой пакет первым же правилом попадает под jump и отправляется к custom chain ISP-Input

Далее маршрутизатор находит все правила в кастомной цепочке ISP-Input переберать соответствию пакета дял правила

В первых 4 правилах в цепочке ISP-Input он не найдёт соответствия, а вот в пятом правиле сделает jump на ещё одну цепочку. Соответственно выберет все правила из новой цепочке ISP-Input-Allow

И будет снова сверять по порядку, соответствия пакета правилу.

Как только найдено терминирующее правило, а в нашем случае это accept, маршрутизатор заканчивает обработку данного пакета в filter firewall и отправляет пакет в Local Process.

SSH сервер ответит пакетом TCP c флагами syn,ack после получения такого пакета клиент отправит пакет с флагом ACK и такой пакет уже будет обрабатываться как established .

А теперь давайте попробуем разобраться, что будет если хост отправит пакет на порт Winbox TCP 8291, который мы явно не запрещали.

Начало будет одинаковое

Когда пакет будет проверяться соответствиям правилам в цепочке ISP-Input-Allow, для него не найдётся не одного подходящего правила.

В этом случае произойдёт автоматически return, и обработка выйдет из цепочки ISP-Input-Allow и продолжит обрабатываться в цепочке ISP-Input, а у нас есть правило, которое отбрасывает все пакеты DROP всё, такой пакет не когда не попадёт в Local Process.

Т.е если в custom chain не найдено соответствие не с одним правилом, то обработка такого пакета возвращается обратно и продолжает обработку по порядку со следующего правила места входа.

Для удобства восприятия поставил слева номера, чтобы был понятен порядок обработки

И ещё раз порядок правил имеет значения только для каждой отдельной цепочки, а не относительно всех цепочек.

На этом этапе мы закончили работу с трафиком Input и переходим к Forward.

Firewall Filter Forward

Естественно нам необходимо защитить трафик которых проходит со стороны провайдеров через маршрутизатор.

Вот вам маленькая история.

Мне провайдер выдаёт внутренней адрес из сети /22 и со всеми соседями я нахожусь в одном брудкаст домене. Получилось так, что пропустил платёж и мне провайдер на шлюзе зарезал интернет, но он не отключил порт на коммутаторе, и мне всё также была доступна внутренняя сеть. Запустил LLDP на интерфейсе провайдера и увидел что со мной в одной сети находятся как минимум пять маршрутизаторов MikroTik. И логика была у меня такая:

По умолчания в RouterOS на первом порту отключен LLDP, а если я вижу это значит что либо конфигурации была сброшена либо используется порт не ether1. Соответственно возможно, что на нём неправильно настроен firewall.

Так и получилось я на своём маршрутизаторе прописал адрес MikroTik первого из списка и у меня появился интернет, да с другого IP адреса, но этого достаточно. Сразу скажу, что на всех пяти MikroTik-ах которые я видел, и кстати до сих пор я наблюдаю в сети данные MikroTik c таким образом настроенным Firewall, что я в любой момент могу получить доступ в интернет через них.

Вот именно от таких ситуаций нам необходимо защитится.

И опять же мы будем использовать кастомную цепочку.

Первым правилом мы отправляем весь проходящий forward трафик с интерфейсов провайдеров в цепочку ISP-Forward.

Следующие правила вам должны быть уже знакомы. Не буду повторять описание

Единственно, что необходимо уточнить, что в случае если вы используете BGP или у вас возникает ситуация, что у вас может быть асинхронная маршрутизация. То вам необходимо разрешать трафик invalid. Но в большинстве случаев это не так.

Далее вы помните, что по типу исключения у нас остаётся только пакеты которые имеют состояние new, и если по думать то такие пакеты могут проходить через маршрутизатор со стороны провайдера только если они попадают под процедуру изменения адреса назначения.

Поэтому нам необходимо разрешить пакеты new которые попадают под dst Нат.

И последний правилом мы закрывает доступ из вне всем отвальным пакетам.

Давайте взглянем на наши правила.

Соответственно, если вам необходимо разрешить подключаться к маршрутизатору, будь то по VPN или ещё как-то, вы всегда можете добавить правило в цепочку ISP-Input-Allow и не думать о порядке правил.

Уверен, что у большинства системных администраторов или сетевых инженеров возникал вопрос: "Правильно ли я настроил межсетевой экран и что еще можно сделать для лучшей защиты?". Естественно, в этом вопросе стоит опираться на различные руководства (PCI DSS, ISO, NIST и т.д.) и здравый смысл. Помощь более опытных коллег также приветствуется.

В рамках же данной статьи мы попробуем описать основные рекомендации или лучшие практики (best practices) по настройке межсетевых экранов. Это некий “чек-лист”, следуя которому можно существенно повысить качество защиты сети. Руководство составлено специально для оборудования Check Point, однако оно также может быть использовано, как основа для самостоятельного аудита сети, построенной на оборудовании других вендоров (Cisco, Fortinet, Palo Alto и т.д.). Если вас это заинтересовало, то добро пожаловать под кат…

Compliance Blade

Вообще говоря, в случае с Check Point аудит «правильности» настроек можно выполнять в автоматическом режиме. Осуществляется это с помощью программного блейда Compliance, который активируется на менеджмент сервере:

Данный блейд выполняет следующие функции:

Постоянный контроль за тем, чтобы система управления, программные блейды и шлюзы безопасности были настроены оптимально.
Показывает неправильные настройки конфигурации и уязвимости в защите.
Предоставляет рекомендации по укреплению безопасности.

Показывает, как изменение конфигурации повлияет на безопасность.
Уведомляет об изменениях политик, негативно влияющих на безопасность.
Обучает пользователей, какими будут последствия желаемых изменений.

Переводит тысячи требований регуляторов на язык практических рекомендаций.
Постоянная оценка совместимости с требованиями регуляторов (PCI DSS, ISO, NIST, DSD и так далее).

Оценка соответствия требованиям регуляторов:

Оценка производительности отдельных шлюзов и блейдов:

Блейд Compliance поставляется бесплатно с подпиской на 1 год при покупке сервера управления (будь то физический appliance Smart-1 или виртуальная машина). Этого времени вполне достаточно для комплексной настройки средств защиты с последующей оценкой конфигураций. Таким образом, в первый год вы получаете бесплатный аудит сетевой безопасности (настроек Check Point).

Если вы еще ни разу не активировали данный блейд, то это весьма просто сделать в свойствах сервера управления (Management Server), как это было показано на картинке выше. После этого проинсталлировать политики и подождать некоторое время (в зависимости от размеров сети и количества шлюзов). С результатом оценки конфигураций можно ознакомиться на соответствующей вкладке Compliance в консоли SmartDashboard:

Стоит заметить, что дальнейшее использование блейда Compliance требует продления соответствующей подписки, цена которой не всегда соответствует бюджету малых и средних компаний.

Что же делать после окончания подписки?
Специально для таких случаев мы создали данное руководство, которое позволит в ручном режиме проверить “адекватность” и безопасность текущих настроек в соответствии с рекомендациями Check Point. При этом мы не будем рассматривать стандарты различных регуляторов (PCI DSS, ISO и т.д.), а лишь затронем лучшие практики (Best Practices) по настройке средств сетевой защиты.

Firewall Best Practices
1. Присутствует правило Management (название может отличаться):

Данное правило используется для доступа с сервера управления (Management Server) и компьютера администратора к шлюзу безопасности (Security Gateway). Остальным доступ должен быть запрещен.

2. Присутствует правило Stealth (название может отличаться):

Данное правило используется для блокирования любой попытки доступа к самому шлюзу, что делает его “невидимым” и исключает возможность несанкционированного доступа. Убедитесь, что это правило расположено ниже чем Management.

3. Присутствует правило Clean up rule (название может отличаться):

По умолчанию Check Point блокирует все соединения, которые явно не разрешены. Данное правило используется исключительно для логирования всех пакетов, которые и без этого были бы заблокированы. Правило должно быть самым последним в списке.

4. Присутствует правило Do Not Log (название может отличаться) для которого отключено логирование:

Данное правило используется для фильтрования “паразитного” широковещательного трафика. К такому трафику относятся: udp-high-ports (UDP ports > 1024-65535), domain-udp, bootp, NBT (NetBios), rip (список может отличаться, в зависимости от вашей сети). Логирование отключается намеренно, дабы не перегружать логи межсетевого экрана бесполезной информацией. Правило должно находиться как можно выше в списке (лучше первым).

5. В списках доступа в колонке источник (source) отсутствует значение Any, т.е. любой трафик. Всегда указывайте конкретный источник в правилах, будь то сеть или хост. За исключением правил Stealth, Clean up rule, Do Not Log.

6. Отсутствуют правила разрешающие весь трафик (any any accept).

7. Запрещен входящий Internet трафик для сегментов Бухгалтерии (Finance) и Отдела кадров (HR).

8. Запрещен FTP трафик из сети Internet в DMZ.

9. Отсутствуют неиспользуемые правила. В консоли SmartDashboard можно просматривать счетчик совпадений по каждому списку доступа:

Если счетчик показывает нулевое значение или последнее совпадение (Last hit) было более чем 6 месяцев назад, то рекомендуется удалить данное правило, дабы не перегружать общий список.

10. Для всех правил в поле Track выставлена опция Log. Кроме правила Do Not Log. Так вы сможете логировать все важные события исключая широковещательный трафик.

11. Для всех правил указано “адекватное” имя и присутствует комментарий, поясняющий назначение этого правила.

12. На всех шлюзах включено логирование.

В качестве Лог-сервера может выступать сервер управления (Management Server) либо другое стороннее решение (возможно использование SIEM или Log Management систем).

14. На всех шлюзах также включена функция локального хранения логов. Это позволит сохранить информацию о событиях в случае недоступности Лог-сервер.

15. На всех шлюзах настроено создание нового Лог-файла при достижении определенного размера старого.

Это значительно ускорит обработку логов (отображение, поиск). Вернуться к более старым логам можно будет переключив Лог-файл.

16. На всех шлюзах настроены уведомления сигнализирующие о заканчивающемся дисковом пространстве. Уровень срабатывания выбирается в зависимости от общего объема жесткого диска. Как правило порог выставляется в районе 50-100 МБайт.

17. На всех шлюзах настроено удаление старых Лог-файлов при заканчивающемся дисковом пространстве. Уровень срабатывания выбирается в зависимости от общего объема жесткого диска. Как правило порог выставляется в районе 50 МБайт.

18. На всех шлюзах настроены скрипты, которые выполняются перед удалением старых Лог-файлов.

С помощью данной функции можно убедиться, что созданы бэкапы логов.

19. В глобальных настройках включено логирование для “VPN packet handling errors”, “VPN successful key exchange”, “VPN configuration & key exchange errors”, “Administrative notifications”, “Packet is incorrectly tagged” и “Packet tagging brute force attack”:

20. На всех шлюзах включен Anti-Spoofing в режиме prevent (для всех интерфейсов):

21. В глобальных настройках (global properties) проверьте значения временных интервалов по умолчанию для stateful inspection:

В случае необходимости измените в соответствии с требованиями вашей сети.

22. Для полей “Drop out of state TCP packets”, “Drop out of state ICMP packets” и “Drop out of state SCTP packets” включено Log on drop (смотри картинку выше).

23. В свойствах каждого шлюза включен счетчик Hit Count:

Это позволит видеть кол-во совпадений по каждому правилу (списку доступа) и удалять неиспользуемые.

24. В настройках оптимизации шлюза укажите максимальное количество конкурентных сессий.

Этот параметр зависит от модели шлюза и позволяет предотвратить перегрузку.

25. В глобальных настройках (global properties) пароли учетных записей пользователей (User Accounts) и администраторов (Administartor Accounts) истекают не позднее чем через 180 дней.

Также должно быть настроено оповещение об истекающем пароле.

26. При интеграции с Active Directory настроена смена пароля:

27. В глобальных настройках (global properties) активирована блокировка Администраторов. Учетная запись блокируется на 30 минут в случае 3-х неудачных попыток входа.

Также настроено уведомление о блокировке и сброс сессии управления, неактивной в течении 15 минут.

28. В свойствах шлюзов выставлена опция “Rematch connections”.

Это позволит блокировать запрещенные соединения сразу после установки новой политики и не ждать окончания сессии.

29. Настроена синхронизация времени (NTP)

Это позволит видеть актуальную дату и время для всех событий (логов).

Таковы рекомендации Check Point по настройке блейда Firewall. Но думаю многие заметили, что большинство советов применимы и к другим вендорам. Подобные рекомендации есть по всем блейдам (IPS, DLP, Application Control, URL Filtering и т.д.), которые мы возможно рассмотрим в следующих статьях.
Больше информации по Check Point можно найти в нашем корпоративном блоге. А чтобы бесплатно провести настроек безопасности Check Point, нажмите сюда.

Читайте также: