Лирическое про firewall
Аннотация.
Пятничное хулиганство.
Выдержки из текста, "наваявшегося сам по себе", когда тебя спросили "а где пояснения?" и на твоё "А вот, комментарии в теле кода!" ответили "Нет! Это слишком сложно! Давай напиши так, чтобы было и генеральному директору понятно!" Ну и вот, "избранные места из...", из которых выгрызено всё то, что может содержать намёки на служебную и / или коммерческую тайну, в том числе на реальную специфику работы системы информбезопасности корпорации... Конечно, думаю, что айтишники-юниксоиды оценят больше и лучше, но... Но можно попробовать и с непрофессиональной публикой! С пятницей!
Лирическое про firewall.
Firewall. Под этим названием мы понимаем средство защиты компьютера и, если возможно, находящейся за ним сети, иначе брандмауэр, будь он хоть программный, хоть аппаратный. Но внутри аппаратного firewall всё равно "крутится хитрая программка", а любой программный firewall по сути своей пребывает в трёх разных агрегатных состояниях:
а) в виде набора программных фильтров и правил, пребывающих в ОЗУ и исполняемых процессором при возниконовении указанных условий, то есть программы как отдельной сущности;
б) в виде последовательного набора команд, выполняемых над каждым поступающим в систему пакетом информации, то есть алгоритма обработки информации программой-firewall-ом;
в) в виде последовательного набора команд, выполняемых при загрузке-выгрузке программы firewall, формирующих вот ту самую программу (п.а), работающую с информацией по тому самому алгоритму (п.б).
Что первично, что вторично, что правильно, что ошибочно - вопрос философский. И, как любая философия, во-многом зависит от того, кто на firewall смотрит и с какой целью, но! Но от позиции взгляда на firewall зависит количество и качество инструментов, доступных для работы с этим самым firewall.
Если мы видим лишь программу как отдельную сущность (эксплуатационный, пользовательский подход), то всё, что нам доступно сделать с fw - это выгрузить его дамп на жесткий диск, а потом загрузить обратно. Даже изменения в дамп вносить опасно - "а вдруг не заработает?". Да и "что не заработает" при работе с дампом - не видно, "матюк эрроркода" относится ко всей программе, ко всему дампу, а не конкретно к тому, что мы наковырять изменили...
Как правило, "пользун" для, допустим, firewall iptables, лучше всего знает команды iptables-save и iptables-restore, запуск iptables -L -n --line-numbers подобен сеансу высшей боевой магии, о существовании ключика -S он не задумывается, различия с iptables-save не различаются, о потере функционала verify он не сожалеет (ибо не знает о нём), а с ключом -C (который check) корректно и правильно не сможет запустить и даже на второй год, не говоря про "на первый день".
Если firewall представляется нам набором программ для обработки информации (админский подход), то гораздо больше радости доставят встроенные ключи-команды -A, -R, -I и -D. В принципе, только при помощи их можно модифицировать firewall "до безобразия бесконечности", а совмещая эти команды с командами пользуна можно научиться форматировать дефолтный firewall практически бесконечно, делая из него именно то, что тебе нужно. Но основные принципы и ошибки строения, структуры firewall тебе всё так же будут недоступны.
В принципе, уже сейчас можно сравнить firewall с алкогольными напитками: пользовательский подход подразумевает нахождение всех возможностей "в крови": алкоголь уже действует, качество и количество алкоголя предопределяют качество и количество воздействия; админский подход подразумевает, что мы не просто "укладываем алкоголь в желудок, чтобы после загнать в кровь", но ещё и думаем, какой смешать коктейль и с чем, и, в зависимости от этого, получать разный эффект для разных информаций. Чем-то сродни действиям врача - анестезиолога или профессионального эстета-алкоголика. Но - но разве не только я предпочитаю алкоголь - и элитный, дорогой, и дешёвый, игристый, домашний - в бутылке, в том состоянии, когда только я решаю, что смешать, с чем смешать, в каком количестве, и смешивать ли вообще?
И вот как алкоголь в бутылке - возможность, программа и алгоритм выпивки, так и firewall для меня прежде всего стартовый скрипт, который сотворяет в ОЗУ компьютера нечто, причём нечто настолько же уникальное, приятное, полезное, убойное и красивое, как 50-летний коньяк или 15-летнее десертное марочное, но только при правильном и последовательном применении, загрузке, запуске! Так и firewall в ином состоянии, кроме стартового скрипта, для меня нет...
Итак, "загрузочная поллитра". Естественным способом загрузки жидкости в человека является перенасыщенный вкусовыми рецепторами рот, а естественной средой загрузки и исполнения всего в unix является shell. А значит, что "firewall на естественном языке" это написанный на shell загрузочный скрипт, и все новомодные python, perl, rubi или mysql/postgresql с тяжелючими графическими front-end типа firewalld/ufw не являются естественными: это всё равно, как потреблять коньяк через кальян, вино через противогаз или пипетку в ухо, а водку через клизму. И никакой "скоростью и простотой" это не оправдать: ведь всё равно, быстрее чем shell может быть только shell на незагруженной standalone машине, а "простота хуже воровства", особенно когда дело касается пользовательского интерфейса...
Однако "новомодность" не теряет своей популярности - почему? Не секрет, что в условиях плотной корпоративной работы любой программный firewall - хоть iptables, хоть ipcains, хоть ipfw - имеет свойство расширяться, разрастаться в прогрессии - и дело не только в "сколько не бери, за добавкой всё равно бежать придётся". Самый умный, самый классный, самый компактный firewall в процессе работы необходимо должен меняться, переосмысливаться, пере-создаваться. А процесс создания нового - он долгий! Всегда кажется проще "прохатчить", что-то где-то кусками написать наново, закомментировав старое. И в результате первоначальная стройная идея firewall погрязает в громадных простынях "сходу в лоб" не очень-то и опознаваемых данных. А "читать простыни" - та ещё задача... И очень хочется иметь что-то, что позволит "свернуть типологически однородное", чтобы увидеть "голую структуру" - и возникает необоримое стремление к gui-не...
Но тяжёлые и сырые "новомодники" проблему не решают, убирая одни неудобства, порождают другие - и люди начинают мечтать об аппаратных или программно-аппаратных firewall, начинают ныть "а давайте купим cisco! ну или хотя бы microtic!", что, конечно, облегчает проблему масштабируемости firewall, но, помимо того, что "больно бьёт по кошельку", порождает не меньшие проблемы с роутингом...
Возвращаемся к структуре firewall. И сразу вспоминаем, как пили древние греки: вино на всю пирушку выливалось в один большой кратер (среднее между миской и тазиком) и разбавлялось напополам водой с пряностями, мятой, т.п. добавками. Ну и оттуда уже черпалось. Когда уровень вина в кратере опускался ровно наполовину - разбавлялось ещё раз водой. Потом было третье разбавление, а вот уже четвёртое отдавалось "несознательным негражданам": женщинам, детям, рабам...
Где-то так же и в firewall: сначала следует самое "ядрёное", имеющее отношение к самому серверу, к его kernel, потом эту его основу "разбавляют приложениями и каналами", а потом "разбавленное разбавляют ещё раз - сервисами внутри сети". То есть на kernel базируется local apps security, на local apps security базируется network apps security. Разве что, в отличие от "очень древних местами греков", наша отечественная традиция требует "градус надо повышать": чем дальше от kernel, тем труднее точная настройка и быстрое управление, а потому чем ближе к network apps security, тем жёстче и однозначнее jump на действия.
Потому... Потому структура любого firewall состоит из трёх-четырёх частей: сначала следуют определения переменных и констант для самого этого firewall ("и слово было у Бога", но "определить равно о-предЕлить, положить предел, отделить"), потом настройка модулей и ядра, а потом сразу защита самого сервера как компьютера (и распространяется, по мере необходимости, на всю сеть): blacklist (drop определённых соединений просто по диапазону ip источника - что делать "игровым домашним" сетям в сети серьёзной производстенной корпорации?). Далее - разрешение средств управления, наблюдения и контроля (ssh, icmp), а дальше правила input/output: дроп гарантированного мусора, ненужных входящих-исходящих соединений по портам и протоколам, разрешение доступа к сервисам, "крутящимся" на этом сервере (dns, dhcp, т.п.), поддержка "капризных судьбоносных" приложений сервера типа ipsec/vpn/ppp/pptp (сервис, но сервис на этом сервере)...
Как можно видеть, в самом начале важность, судьбоносность задач и каждого правила - гораздо выше ("вино ещё не так разбавлено"), но чем ближе к концу, тем больше сложность правил и растёт набор критериев ("но градус нужно повышать"). В самом конце этой, второй, input/output-ной части - редиректы. То есть "повышение градуса" достигает уровня "спрятать привычный и, возможно, уязвимый сервис на непривычном, нестандартном порту с хитромудрым протоколом". Все redirect - это уже не только input/output, это уже pre/post-routing, а это уже "дорожка к forward-ам". Потому...
Потому, как "не хлебом единым", а в приложении к алкогольной теме firewall, "не только жидким хлебом", но и "закусывать надо!". А закусываем мы, особенно в долгой и основательной "поляне", всегда достаточно закономерным способом!
Вспомните, в начале застолья всегда присутствует некий лёгкий голод. Потому сначала "не столько закусываем, сколько кушаем" - и берём для этого те блюда, которые стоят поближе: и тянуться далеко не надо, и соседям просьбой передать не мешаем кушать. Но чем дальше "процесс превращается в ритуал", тем больше хочется не "покушать", а "попробовать", ощутить вкус, то есть и с едой "смешать и проэкспериментировать"! И потому начиная с середины застолья "а не затруднит вас передать-поделиться" и "от нашего края стола вашему краю стола" - самые типичные, распространённые фразы!
Потому между input/output и forward, как между тостами под разные перемены блюд, обязательно появляется "прослойка", "закуска": те сервисы, которые удобнее обрабатывать одним блоком команд! Ну, допустим, проброс web-сервера из dmz на порт на внешнем адресе нашего gateway требует как определённых команд настройки внешних интерфейсов gateway (и input/output, и forward), так и для возможности доступа к тому же web-серверу изнутри локальной сети, совсем других команд настройки внутренних интерфейсов, роутинга и firewall (input/output + forward) изнутри! И удобнее это всё хозяйство описать одним блоком, одним набором команд, пусть и относящимся к разным логическим частям firewall, чем "растаскивать" команды по логическим частям, а потом, при необходимости, лихорадочно искать-вспоминать "всё на этом, или ещё где что-то для web-ки порылось?".
И вот такой "закуской" я привычно заполняю пространство между двумя разными частями firewall, между между input/output-частью и forward-частью. Получаются такие себе "мини-firewall-чики для apps-ов", "фуршетики по задачам", "закуски", и таких частей в серьёзной корпоративной сети будет немало.
forward. Как правило, к тому моменту, когда мы добрались до этой секции, сервер у нас уже плотно защищён, да и если не все сетевые сервисы, то большинство их уже описаны в "переходных связках". Таким образом, forward-секция описывает и защищает в основе своей пользовательские компьютеры локальной сети. А в любой корпорации это очень и очень большое число!
Защищаем пользунов сети в таком же порядке, как и сервер: сначала защита ОТ интернета локалки (дроп из инета опасных портов), потом защита ДЛЯ интернета от локалки (кого не надо - не пускать, кого надо пускать не всюду - дроп), потом разрешения доступа, в конце - полный дроп. Да, если polisy drop, в принципе, может, и не надо, но... Но от того, что я пропишу несколько строк команд-дропов, я буду только увереннее, что "незаявленная кака не прорвётся" (хоть, может, и мнительнее), но, более того, сами строчки с полным drop служат для меня ограничителем: после этих строк ничего работать не будет! Ставить команды - только перед ними! Дисциплинирует.
Ну и "вишенкой на тортик" - финальный pre/post-routing, SNAT и DNAT. Как правило, те pre/post-routing-и, которые имеют отношение к сервисам, мы уже обработали - в части закуски. А gateway с firewall и так имеет внешний ip-адрес, то есть без сервисов в pre/post-routing-е нуждается крайне редко. То есть тут чаще всего оказывается то, что имеет отношение к "локалке целиком", то есть к той части, которая описывалась forward-ами. И по принципу "вино разбавляем, но градус повышаем", этот кусок "закуски к forward" оказывается самым сложным, требующим самого пристального внимания.
Это как "кусочек тортика к кофе с ликёром" - не спешить, смаковать, вдумчиво переваривать в конце праздника. Курящие могут под трубку или сигару, в крайнем случае, под сигарету с ароматизаторами. Не спешите, будьте вдумчивы и основательны: "служенье муз не терпит суеты, прекрасное должно быть величаво!"
