Netfilter: новые возможности Linux-файрволла в новом ядре
"Свершилось! Долгожданное ядро Linux 2.4 увидело свет, и для большинства из нас — специалистов в области обеспечения безопасности — это в высшей степени радостное событие. В данной статье я попытался разъяснить суть улучшений подсистемы обеспечения безопасности ядра Linux, дабы и вы возрадовались столь же бурно, как и я ;)"Так начинается статья Jay Beale — дирекора коллектива специалистов по безопасности (Security Team) компании MandrakeSoft, ведущего разработчика проекта Bastille Linux, автора множества статей и книги по безопасности Unix/ Linux-систем, а также просто увлеченного линуксоида и сетевика. Судя по обилию восклицательных знаков и высокопарно-восторженных оборотов, Джэй действительно горячо болеет за правое дело обеспечения безопасности сетей и работает с таким увлечением, что IMHO по праву может считаться хакером в исходном и правильном значении этого слова, обозначающем компьютерного и сетевого фанатика. Кстати, на протяжении всей статьи вы ни разу не встретите слово "хакер" в качестве синонима "злоумышленник" или "атакующий", и мне кажется — это неспроста ;)
Переводя этот материал я старалась, по возможности, максимально сохранить стиль изложения исходного текста, отличающийся простотой, изобилием разговорных оборотов, сленга и т.п. И не только из уважения к автору, но и потому, что сама придерживаюсь мнения, что даже самые заоблачно высокие технологии могут — и должны — "разговаривать" на нормальном человеческом языке :)
техническое резюме
В начале мне хотелось бы поместить краткий обзор нововведений в области обеспечения безопасности в ядрах Linux 2.4, а в последующих разделах — для тех, кому интересно — предлагаются более подробные описания каждого из них.
Итак, Netfilter — подсистема фильтрации пакетов в ядрах 2.4 — это первый встроенный в ядро файрволл, обеспечивающий возможность контекстной фильтрации пакетов*. Контекстные фильтры представляют собой важнейший технологический скачок в интеллектуальности файрволлов и присутствуют во всех серьезных продуктах для обеспечения сетевой безопасности enterprise-класса. Наряду со многими улучшениями, контекстность позволяет Netfilter отслеживать и блокировать такую активность, как stealth-сканирование, что ранее было недоступно встроенным Linux-файрфоллам.
Новая система также намного легче и приятней в управлении. Архитектура Netfilter предлагает более простые, и вместе с тем более мощные возможности конфигурирования таких вещей, как NAT, прозрачные прокси, перенаправление трафика. Это дает возможность легко организовать такую, казалось бы, сложную штуку, как система балансировки нагрузки, например, прозрачную для конечного пользователя замену одного веб-сервера четырьмя. Далее, Netfilter способен блокировать большее по сравнению с предшественниками количество DoS-аттак за счет возможности задания правил по типу пакетов, что позволит вам бороться с такими напастями, как SYN flood.
Netfilter представляет собой новую редакцию файрволл-кода в Linux, однако остается весьма совместимым с ранними версиями, что сократит для большинства организаций время мигрирования и затраты на обучение персонала.
Итак, часть гуру в области сетей и безопасности в Linux наверняка уже поняли все, что им нужно из этого краткого резюме и деловито отправились конфигурировать новый файрволл. Остальные заинтересованные лица — продолжают читать статью, из которой они узнают подробности о каждом заявленном усовершенствовании.
что такое контекстный файрволлинг (Stateful Firewalling)
Как нам известно, сетевое взаимодействие обычно осуществляется с помощью передачи данных, нарезанных на маленькие куски, обзываемые пакетами. В случае с TCP некоторые из этих пакетов используются только для создания, поддержки и завершения соединения. Это связано с тем, что TCP использует концепцию соединения, дающую возможность автоматической коррекции ошибок, интерпретации приходящих пакетов в той же последовательности, в какой они были отправлены и др. Ну и какое это имеет отношение к файрволлам? — спросите вы.
Нормальные — неконтекстные фильтры пакетов, подобные тем, что присутствуют в большинстве маршрутизаторов, инспектируют каждый пакет индивидуально, не запоминая и не понимая его места в соединении. Теперь, допустим, вы, как и большинство администраторов, решили не разрешать внешним хостам инициировать соединения с компьютерами вашей внутренней сети. Неконтекстный файрфолл/маршрутизатор может отличить пакет, являющийся частью существующего соединения от пакета, участвующего в создании нового соединения, проанализировав его на наличие флага SYN.
Внимательно прочтите и вдумайтесь в последнее предложение: файрволл должен "доверять" самому пакету. Но постойте, этот пакет был создан чужим компьютером из внешней сети и... "чужие" в принципе могут расставлять в нем флаги как им только вздумается! Некоторые сканеры используют эту "неувязочку" для обхода файрволлов, сканируя сети, которые должны быть для них невидимыми. Ну и как в таком случае защититься? Правильно, поставить контекстный файрволл. Он держит в памяти информацию по каждому проходящему через него соединению.
Таким образом, если пакет из внешней сети пытается войти в сеть внутреннюю, выдавая себя за часть какого-то существующего соединения, файрволл может навести справки в своем списке соединений. Если выясняется, что пакет не соответствует ни одному существующих соединений, его можно отбросить, тем самым предотвратив сканирование.
Даже применительно к протоколу без установки соединения UDP контекстная проверка все-таки является весьма полезной фичей. Предположим, как и в предыдущем примере, что вы запрещаете внешним компьютерам организовывать взаимодействие с вашими внутренними машинами. Хорошо, для разрешения имен DNS обычно используется протокол UDP. Если ваши маршрутизаторы не могут отслеживать все запросы DNS, они должны пропускать внутрь все DNS-подобные пакеты (UDP порт 53), исходящие от любого DNS-сервера. Контекстный файрволл ведет учет всех исходящих от вас DNS-запросов и пропускает DNS-подобные пакеты только от тех серверов, у которых ваши хосты что-либо спрашивали, причем делает это столь интеллектуально, чтобы предотвратить возможность передачи данных после прихода первого же ответа.
А вот еще одно замечательное преимущество контекстных файрволлов: их в целом легче администрировать, используя меньшее количество правил для создания более точной и действенной политики безопасности. Хорошим примером тут будет активный FTP.
Когда ваш FTP-клиент подключается к FTP-серверу, устанавливается TCP-соединение, где в качестве порта источника выступает некий "высокий" порт на вашей клиентской станции, а портом получателя является 21-й — на сервере. Когда вы начинаете получать данные, будь то список содержимого каталога или передача файлов, открывается второе соединение. В случае с активным FTP, инициатором открытия этого соединения выступает сервер: порт отправителя — 20 на сервере, порт получателя — некий произвольный "высокий" порт на клиенте, о значении которого хосты предварительно договорились. То бишь выходит все наоборот: для канала передачи данных ваш клиент — это сервер! :) Ну и в чем тут проблема? — спросите вы. А вот в чем: в неконтекстном файрволле, организованном по принципу "по умолчанию все запрещено" (default deny firewall), вы вынуждены в ясной форме описать в правилах каждый тип пакета, который допускается для прохождения через файрволл. Поскольку непонятно, как охарактеризовать описанный выше тип соединения, вы просто одним из правил вписываете: "разрешать машинам из внешней сети организовывать соединения с 20-го порта на любой высокий порт хостов во внутренней сети". Это, господа, беспорядочек и преступная, так сказать, халатность! Самое очевидное, что может произойти из за такого правила, это то, что злоумышленники быстренько сообразят сканировать вашу сеть, ставя в поле "порт отправителя" номер 20 :)
Теперь, с использованием контекстного файрволлинга, мы оказываемся в лучшем положении. Файрволл достаточно умен, чтобы мониторить совещания клиента и сервера насчет назначения номеров портов для канала передачи данных и запоминать, на какой порт клиент ожидает соединения от сервера. И затем открыть доступ к этому и только этому порту, а не ко всем 64512 возможным! Заметьте, это не только более умное, но и более легкое в реализации решение, требующее наличия только одного правила.
Контекстный файрволлинг — это очевидно более продвинутая технология в сравнении с неконтекстным. Любой навороченный корпоративный файрволл содержит в себе эту замечательную фичу. Однако никто не говорит, что серьезные организации не используют также неконтекстных файрволлов/маршрутизаторов. Подумайте сами: отслеживание соединений — оно же черт знает сколько памяти жрет! Поэтому многие компании используют обычную фильтрацию для блокировки трафика, который ну ни при каких условиях нельзя пускать извне вовнутрь (скажем, совместное использование (sharing) файлов в локальной сети — smb, nfs), а контекстная фильтрация используется дополнительно, чтобы расправляться с остальными, более неоднозначными проблемами. В любом случае, контекстность дает вашему файерволлу память, а с ней — ум и силу. Использование этой техники в подсистеме фильтрации пакетов — неоспоримый выигрыш для Linux. А вообще-то я решительно рекомендую вам обратиться этой технологии файрволлинга вне зависимости от того, будете вы использовать ее под линуксом или нет.
защита от DoS-атак
Затопление SYN-пакетами (SYN flood) — это широко известная атака на отказ в обслуживании (DoS), базирующаяся на общеизвестной "вечной" теме: захват (исчерпание, приведение к нехватке) ресурсов (Resource Starvation).
По существу происходит следующее: атакующий посылает некоторое количество TCP SYN-сегментов на ваш хост, но на ваши ответы никак не реагирует. Ваш компьютер при этом наивно полагает, что это просто соединение между ним и атакующим хостом очень медленное, и из этих соображений относительно продолжительное время ожидает, прежде чем сбросить каждое из соединений. При этом, однако, ваш компьютер следит за тем, чтобы количество новоустанавливаемых соединений не превысило некоторый лимит. Таким образом, если атакующий пошлет достаточно этих самых SYN-пакетов, вы оказываетесь в положении, когда не можете обработать соединения , поступающие от кого-либо еще. В данном случае исчерпываемый ресурс — таблица соединений.
Теперь вы можете организовать на Linux'е прекрасную защиту против этой атаки и ей подобных — ввести ограничение на количество SYN-пакетов, приходящих от одного источника. Netfilter позволяет решение такого рода, поскольку в нем реализована технология ограничения скорости передачи (basic rate limiting). Впрочем, вы можете использовать эту фичу в различных целях. Например даже для того, чтобы быть уверенными, что какие-либо активно используемые машины в вашей сети (IRC-, веб-серверы) не пожирают всю имеющуюся у вас полосу пропускания. Это тоже очень полезная технология! Далее, на что еще мы можем теперь найти управу?
защита от Stealth-сканирования
Fyodor, где бы ты ни был, я уверен, что ты заплакал от счастья, узнав об этом нововведении! ;>
Этот человек — автор nmap — вывел сканирование сетей/хостов на принципиально новый уровень, обнаружив, что некоторые виды пакетов могут беспрепятственно пройти сквозь многие файрволлы и достигнуть многих хостов, оставшись незамеченными. Этот вид сканирования, названный stealth-сканирование, включает в себя все что угодно, начиная от посылки ACK-пакетов, притворяющихся частью открытого соединения, до использования "нелогичных" пакетков, как например XMAS-пакет, в котором выставлены все TCP-флаги или NULL-пакет, в котором все флаги отключены. Пока эти пакеты могут спокойно шастать через бесконтекстные файрволлы, а операционные системы имеют свойство отвечать на эти пакеты разными сообщениями об ошибках, у любопытных есть прекрасная возможность исследовать машины за файрволлом, чаще всего не будучи при этом обнаруженными.
Netfilter способен производить фильтрацию пакетов, базируясь на любой комбинации TCP-флагов, что было невозможно на ядрах 2.0/2.2, файерволл-модули которых справлялись только с распознаванием флага SYN.Эта и другие возможности защиты от атак стали возможны благодаря глобальным улучшениям архитектуры кода файерволлинга Linux в целом, которая предлагает простые возможности расширения. Прямым результатом этой расширяемости является, например, вот какая фича:
MAC-фильтрация
Каждая сетевая карта имеет свой MAC (Media Access Control) адрес, который должен быть уникальным не только в рамках вашей сети, но и во всем мире (на самом деле бывают ситуации, когда производитель дублирует MAC-адреса, но в таком случае карты с одинаковыми адресами поступают в продажу в очень удаленные друг от друга регионы, например, в Японию и Европу. — прим. ред). Теперь, если вам нужно ужесточить требования к внутренней безопасности сети, вы можете организовать фильтрацию не только по IP-, но и по MAC-адресам. Такая очевидно полезная фича, однако, была недоступна в ядрах 2.0/2.2.
При этом имейте в виду, что подобная мера будет эффективна как дополнение для обеспечения безопасности в коммутируемой сети. Она не остановит продвинутого злоумышленника в некоммутируемой (построенной на основе хабов) сети, хотя и может быть полезна как дополнительная мера защиты. Кстати вы можете комбинировать этот метод с технологией, описанной абзацем ниже, для создания виртуальных ЛВС (VLAN) "для бедных". Взгляните ка на:
более интеллектуальные NAT и прокси
Трансляция сетевых адресов (Network address translation, NAT), или, как некоторые любят говорить — "модификация пакетов", представляет собой технологию, когда файрволл изменяет информацию об источнике или получателе в пакетах, которые через него проходят.
NAT используется для решения широкого спектра задач и имеет массу разновидностей. Помимо прочих (см. статью "To NAT or not to NAT" в "СР" №1 за 1999 г"), существует классификация, разделяющая NAT на "трансляцию источника (отправителя)" и "трансляцию пункта назначения (получателя)".
Первая используется чаще всего в случае, когда множество клиентских станций совместно используют один выделенный провайдером IP-адрес. Многие организации используют это также чтобы оградить внутреннюю сеть от чужого любопытного глаза.
Трансляция отправителя была реализована и на предыдущих ядрах Linux, но в Netfilter она была сильно доработана и улучшена.
Трансляция получателя позволяет файрволлу отсылать все исходящие пакеты на заданный хост/порт. Например, мой файрволл может отлавливать все веб-соединения и прозрачно для пользователей перенаправлять их на прокси-сервер. Это позволяет увеличить скорость работы в вебе за счет кеширования данных на прокси. Также это позволяет фильтровать веб-контент, поскольку прокси работает как посредник.
Люди также используют трансляцию получателя для организации так называемого кластера для балансировки нагрузки, чаще всего для работы с веб-серверами базами данных.
Пример: Допустим, мои веб-сервера настроены для запросов к серверу баз данных по адресу 192.16.1.53. Таким образом, если между ними установить систему трансляции получателя, она будет преобразовывать этот адрес в один из пяти возможных адресов серверов, например из диапазона 10.0.0.1-10.0.0.5
улучшенные возможности протоколирования трафика
Netfilter теперь ведет логи более интеллектуально. Что важно, он может протоколировать пакеты на различных уровнях значимости и добавлять произвольные метки в лог, базируясь на определенных вами правилах. Поясню сказанное на нескольких примерах:
Пример 1: вы знаете, что не должны лицезреть никаких входящих в вашу сеть SMB-запросов. Вы устанавливаете правило, согласно которому в лог пишутся любые пакеты этого типа с пометкой значимости "warning". В дальнейшем можно заставить обработчик логов слать вам на e-mail все, что проходит с такой пометкой.
Пример 2: вы собираете фактический материал против кого-то, кто пытается вломиться в вашу систему в течение, допустим, двух недель. Вы вычислили его IP-адрес(а) и приказываете системе протоколирования записывать в лог каждый пакет, приходящий с этих адресов, с присвоением уровня значимости "emerg". Процесс обработки и слежения за логами шлет все эти записи прямо на заданный принтер для последующего надежного сохранения "вещественных доказательств" на бумаге. Ну и конечно вы должны использовать ограничение скорости передачи для предотвращения DoS-атак на систему протоколирования. Можно также потребовать отсылать вам предупреждения на пэйджер или мобильный телефон в случае, когда злоумышленник начинает соединения после, предположим, 2 часов бездействия.
Видите, система протоколирования здесь достаточно гибкая, как, впрочем, и остальные части Netfilter. То, что она может обнаруживать практически любые вторжения, не может не впечатлять. Если вы хотите обзавестись мощной системой обнаружения вторжений (Intrusion Detection System, IDS) — пожалуйста, подыщите себе такую. Но не брезгуйте использовать дополнительно и "родную" линуксовую систему протоколирования. Помните, могут обнаружиться баги, делающие даже продвинутую IDS бесполезной или неработоспособной, поэтому руководствуйтесь правилом "Defense in Depth" — используйте множественные методы защиты чтобы застраховатсья от выхода из строя одного из них.
* — На самом деле автор применяет в статье термины stateful/stateless firewall/filter. Посовещавшись с некоторыми сетевыми гуру и просмотрев русскоязычную литературу, я выясняю, что устоявшегося перевода этих понятий нет. Для stateful firewall/filter были найдены следующие варианты: "фильтр пакетов с контекстной проверкой", "фильтр с хранением состояния" и "фильтр, отслеживающий соединения".
Некоторые источники утверждают, что все это также является синонимом понятия "динамический файрволл", хотя другие с этим в корне не согласны. Таким образом я, набравшись наглости, ввожу термин "контекстный файрволл/фильтр": в любом случае большая часть статьи посвящена расшифровке этого понятия, а дальше уж вам самим решать — как это дело назвать ;)
Перевод Alice D. Saemon
Переводя этот материал я старалась, по возможности, максимально сохранить стиль изложения исходного текста, отличающийся простотой, изобилием разговорных оборотов, сленга и т.п. И не только из уважения к автору, но и потому, что сама придерживаюсь мнения, что даже самые заоблачно высокие технологии могут — и должны — "разговаривать" на нормальном человеческом языке :)
техническое резюме
В начале мне хотелось бы поместить краткий обзор нововведений в области обеспечения безопасности в ядрах Linux 2.4, а в последующих разделах — для тех, кому интересно — предлагаются более подробные описания каждого из них.
Итак, Netfilter — подсистема фильтрации пакетов в ядрах 2.4 — это первый встроенный в ядро файрволл, обеспечивающий возможность контекстной фильтрации пакетов*. Контекстные фильтры представляют собой важнейший технологический скачок в интеллектуальности файрволлов и присутствуют во всех серьезных продуктах для обеспечения сетевой безопасности enterprise-класса. Наряду со многими улучшениями, контекстность позволяет Netfilter отслеживать и блокировать такую активность, как stealth-сканирование, что ранее было недоступно встроенным Linux-файрфоллам.
Новая система также намного легче и приятней в управлении. Архитектура Netfilter предлагает более простые, и вместе с тем более мощные возможности конфигурирования таких вещей, как NAT, прозрачные прокси, перенаправление трафика. Это дает возможность легко организовать такую, казалось бы, сложную штуку, как система балансировки нагрузки, например, прозрачную для конечного пользователя замену одного веб-сервера четырьмя. Далее, Netfilter способен блокировать большее по сравнению с предшественниками количество DoS-аттак за счет возможности задания правил по типу пакетов, что позволит вам бороться с такими напастями, как SYN flood.
Netfilter представляет собой новую редакцию файрволл-кода в Linux, однако остается весьма совместимым с ранними версиями, что сократит для большинства организаций время мигрирования и затраты на обучение персонала.
Итак, часть гуру в области сетей и безопасности в Linux наверняка уже поняли все, что им нужно из этого краткого резюме и деловито отправились конфигурировать новый файрволл. Остальные заинтересованные лица — продолжают читать статью, из которой они узнают подробности о каждом заявленном усовершенствовании.
что такое контекстный файрволлинг (Stateful Firewalling)
Как нам известно, сетевое взаимодействие обычно осуществляется с помощью передачи данных, нарезанных на маленькие куски, обзываемые пакетами. В случае с TCP некоторые из этих пакетов используются только для создания, поддержки и завершения соединения. Это связано с тем, что TCP использует концепцию соединения, дающую возможность автоматической коррекции ошибок, интерпретации приходящих пакетов в той же последовательности, в какой они были отправлены и др. Ну и какое это имеет отношение к файрволлам? — спросите вы.
Нормальные — неконтекстные фильтры пакетов, подобные тем, что присутствуют в большинстве маршрутизаторов, инспектируют каждый пакет индивидуально, не запоминая и не понимая его места в соединении. Теперь, допустим, вы, как и большинство администраторов, решили не разрешать внешним хостам инициировать соединения с компьютерами вашей внутренней сети. Неконтекстный файрфолл/маршрутизатор может отличить пакет, являющийся частью существующего соединения от пакета, участвующего в создании нового соединения, проанализировав его на наличие флага SYN.
Внимательно прочтите и вдумайтесь в последнее предложение: файрволл должен "доверять" самому пакету. Но постойте, этот пакет был создан чужим компьютером из внешней сети и... "чужие" в принципе могут расставлять в нем флаги как им только вздумается! Некоторые сканеры используют эту "неувязочку" для обхода файрволлов, сканируя сети, которые должны быть для них невидимыми. Ну и как в таком случае защититься? Правильно, поставить контекстный файрволл. Он держит в памяти информацию по каждому проходящему через него соединению.
Таким образом, если пакет из внешней сети пытается войти в сеть внутреннюю, выдавая себя за часть какого-то существующего соединения, файрволл может навести справки в своем списке соединений. Если выясняется, что пакет не соответствует ни одному существующих соединений, его можно отбросить, тем самым предотвратив сканирование.
Даже применительно к протоколу без установки соединения UDP контекстная проверка все-таки является весьма полезной фичей. Предположим, как и в предыдущем примере, что вы запрещаете внешним компьютерам организовывать взаимодействие с вашими внутренними машинами. Хорошо, для разрешения имен DNS обычно используется протокол UDP. Если ваши маршрутизаторы не могут отслеживать все запросы DNS, они должны пропускать внутрь все DNS-подобные пакеты (UDP порт 53), исходящие от любого DNS-сервера. Контекстный файрволл ведет учет всех исходящих от вас DNS-запросов и пропускает DNS-подобные пакеты только от тех серверов, у которых ваши хосты что-либо спрашивали, причем делает это столь интеллектуально, чтобы предотвратить возможность передачи данных после прихода первого же ответа.
А вот еще одно замечательное преимущество контекстных файрволлов: их в целом легче администрировать, используя меньшее количество правил для создания более точной и действенной политики безопасности. Хорошим примером тут будет активный FTP.
Когда ваш FTP-клиент подключается к FTP-серверу, устанавливается TCP-соединение, где в качестве порта источника выступает некий "высокий" порт на вашей клиентской станции, а портом получателя является 21-й — на сервере. Когда вы начинаете получать данные, будь то список содержимого каталога или передача файлов, открывается второе соединение. В случае с активным FTP, инициатором открытия этого соединения выступает сервер: порт отправителя — 20 на сервере, порт получателя — некий произвольный "высокий" порт на клиенте, о значении которого хосты предварительно договорились. То бишь выходит все наоборот: для канала передачи данных ваш клиент — это сервер! :) Ну и в чем тут проблема? — спросите вы. А вот в чем: в неконтекстном файрволле, организованном по принципу "по умолчанию все запрещено" (default deny firewall), вы вынуждены в ясной форме описать в правилах каждый тип пакета, который допускается для прохождения через файрволл. Поскольку непонятно, как охарактеризовать описанный выше тип соединения, вы просто одним из правил вписываете: "разрешать машинам из внешней сети организовывать соединения с 20-го порта на любой высокий порт хостов во внутренней сети". Это, господа, беспорядочек и преступная, так сказать, халатность! Самое очевидное, что может произойти из за такого правила, это то, что злоумышленники быстренько сообразят сканировать вашу сеть, ставя в поле "порт отправителя" номер 20 :)
Теперь, с использованием контекстного файрволлинга, мы оказываемся в лучшем положении. Файрволл достаточно умен, чтобы мониторить совещания клиента и сервера насчет назначения номеров портов для канала передачи данных и запоминать, на какой порт клиент ожидает соединения от сервера. И затем открыть доступ к этому и только этому порту, а не ко всем 64512 возможным! Заметьте, это не только более умное, но и более легкое в реализации решение, требующее наличия только одного правила.
Контекстный файрволлинг — это очевидно более продвинутая технология в сравнении с неконтекстным. Любой навороченный корпоративный файрволл содержит в себе эту замечательную фичу. Однако никто не говорит, что серьезные организации не используют также неконтекстных файрволлов/маршрутизаторов. Подумайте сами: отслеживание соединений — оно же черт знает сколько памяти жрет! Поэтому многие компании используют обычную фильтрацию для блокировки трафика, который ну ни при каких условиях нельзя пускать извне вовнутрь (скажем, совместное использование (sharing) файлов в локальной сети — smb, nfs), а контекстная фильтрация используется дополнительно, чтобы расправляться с остальными, более неоднозначными проблемами. В любом случае, контекстность дает вашему файерволлу память, а с ней — ум и силу. Использование этой техники в подсистеме фильтрации пакетов — неоспоримый выигрыш для Linux. А вообще-то я решительно рекомендую вам обратиться этой технологии файрволлинга вне зависимости от того, будете вы использовать ее под линуксом или нет.
защита от DoS-атак
Затопление SYN-пакетами (SYN flood) — это широко известная атака на отказ в обслуживании (DoS), базирующаяся на общеизвестной "вечной" теме: захват (исчерпание, приведение к нехватке) ресурсов (Resource Starvation).
По существу происходит следующее: атакующий посылает некоторое количество TCP SYN-сегментов на ваш хост, но на ваши ответы никак не реагирует. Ваш компьютер при этом наивно полагает, что это просто соединение между ним и атакующим хостом очень медленное, и из этих соображений относительно продолжительное время ожидает, прежде чем сбросить каждое из соединений. При этом, однако, ваш компьютер следит за тем, чтобы количество новоустанавливаемых соединений не превысило некоторый лимит. Таким образом, если атакующий пошлет достаточно этих самых SYN-пакетов, вы оказываетесь в положении, когда не можете обработать соединения , поступающие от кого-либо еще. В данном случае исчерпываемый ресурс — таблица соединений.
Теперь вы можете организовать на Linux'е прекрасную защиту против этой атаки и ей подобных — ввести ограничение на количество SYN-пакетов, приходящих от одного источника. Netfilter позволяет решение такого рода, поскольку в нем реализована технология ограничения скорости передачи (basic rate limiting). Впрочем, вы можете использовать эту фичу в различных целях. Например даже для того, чтобы быть уверенными, что какие-либо активно используемые машины в вашей сети (IRC-, веб-серверы) не пожирают всю имеющуюся у вас полосу пропускания. Это тоже очень полезная технология! Далее, на что еще мы можем теперь найти управу?
защита от Stealth-сканирования
Fyodor, где бы ты ни был, я уверен, что ты заплакал от счастья, узнав об этом нововведении! ;>
Этот человек — автор nmap — вывел сканирование сетей/хостов на принципиально новый уровень, обнаружив, что некоторые виды пакетов могут беспрепятственно пройти сквозь многие файрволлы и достигнуть многих хостов, оставшись незамеченными. Этот вид сканирования, названный stealth-сканирование, включает в себя все что угодно, начиная от посылки ACK-пакетов, притворяющихся частью открытого соединения, до использования "нелогичных" пакетков, как например XMAS-пакет, в котором выставлены все TCP-флаги или NULL-пакет, в котором все флаги отключены. Пока эти пакеты могут спокойно шастать через бесконтекстные файрволлы, а операционные системы имеют свойство отвечать на эти пакеты разными сообщениями об ошибках, у любопытных есть прекрасная возможность исследовать машины за файрволлом, чаще всего не будучи при этом обнаруженными.
Netfilter способен производить фильтрацию пакетов, базируясь на любой комбинации TCP-флагов, что было невозможно на ядрах 2.0/2.2, файерволл-модули которых справлялись только с распознаванием флага SYN.Эта и другие возможности защиты от атак стали возможны благодаря глобальным улучшениям архитектуры кода файерволлинга Linux в целом, которая предлагает простые возможности расширения. Прямым результатом этой расширяемости является, например, вот какая фича:
MAC-фильтрация
Каждая сетевая карта имеет свой MAC (Media Access Control) адрес, который должен быть уникальным не только в рамках вашей сети, но и во всем мире (на самом деле бывают ситуации, когда производитель дублирует MAC-адреса, но в таком случае карты с одинаковыми адресами поступают в продажу в очень удаленные друг от друга регионы, например, в Японию и Европу. — прим. ред). Теперь, если вам нужно ужесточить требования к внутренней безопасности сети, вы можете организовать фильтрацию не только по IP-, но и по MAC-адресам. Такая очевидно полезная фича, однако, была недоступна в ядрах 2.0/2.2.
При этом имейте в виду, что подобная мера будет эффективна как дополнение для обеспечения безопасности в коммутируемой сети. Она не остановит продвинутого злоумышленника в некоммутируемой (построенной на основе хабов) сети, хотя и может быть полезна как дополнительная мера защиты. Кстати вы можете комбинировать этот метод с технологией, описанной абзацем ниже, для создания виртуальных ЛВС (VLAN) "для бедных". Взгляните ка на:
более интеллектуальные NAT и прокси
Трансляция сетевых адресов (Network address translation, NAT), или, как некоторые любят говорить — "модификация пакетов", представляет собой технологию, когда файрволл изменяет информацию об источнике или получателе в пакетах, которые через него проходят.
NAT используется для решения широкого спектра задач и имеет массу разновидностей. Помимо прочих (см. статью "To NAT or not to NAT" в "СР" №1 за 1999 г"), существует классификация, разделяющая NAT на "трансляцию источника (отправителя)" и "трансляцию пункта назначения (получателя)".
Первая используется чаще всего в случае, когда множество клиентских станций совместно используют один выделенный провайдером IP-адрес. Многие организации используют это также чтобы оградить внутреннюю сеть от чужого любопытного глаза.
Трансляция отправителя была реализована и на предыдущих ядрах Linux, но в Netfilter она была сильно доработана и улучшена.
Трансляция получателя позволяет файрволлу отсылать все исходящие пакеты на заданный хост/порт. Например, мой файрволл может отлавливать все веб-соединения и прозрачно для пользователей перенаправлять их на прокси-сервер. Это позволяет увеличить скорость работы в вебе за счет кеширования данных на прокси. Также это позволяет фильтровать веб-контент, поскольку прокси работает как посредник.
Люди также используют трансляцию получателя для организации так называемого кластера для балансировки нагрузки, чаще всего для работы с веб-серверами базами данных.
Пример: Допустим, мои веб-сервера настроены для запросов к серверу баз данных по адресу 192.16.1.53. Таким образом, если между ними установить систему трансляции получателя, она будет преобразовывать этот адрес в один из пяти возможных адресов серверов, например из диапазона 10.0.0.1-10.0.0.5
улучшенные возможности протоколирования трафика
Netfilter теперь ведет логи более интеллектуально. Что важно, он может протоколировать пакеты на различных уровнях значимости и добавлять произвольные метки в лог, базируясь на определенных вами правилах. Поясню сказанное на нескольких примерах:
Пример 1: вы знаете, что не должны лицезреть никаких входящих в вашу сеть SMB-запросов. Вы устанавливаете правило, согласно которому в лог пишутся любые пакеты этого типа с пометкой значимости "warning". В дальнейшем можно заставить обработчик логов слать вам на e-mail все, что проходит с такой пометкой.
Пример 2: вы собираете фактический материал против кого-то, кто пытается вломиться в вашу систему в течение, допустим, двух недель. Вы вычислили его IP-адрес(а) и приказываете системе протоколирования записывать в лог каждый пакет, приходящий с этих адресов, с присвоением уровня значимости "emerg". Процесс обработки и слежения за логами шлет все эти записи прямо на заданный принтер для последующего надежного сохранения "вещественных доказательств" на бумаге. Ну и конечно вы должны использовать ограничение скорости передачи для предотвращения DoS-атак на систему протоколирования. Можно также потребовать отсылать вам предупреждения на пэйджер или мобильный телефон в случае, когда злоумышленник начинает соединения после, предположим, 2 часов бездействия.
Видите, система протоколирования здесь достаточно гибкая, как, впрочем, и остальные части Netfilter. То, что она может обнаруживать практически любые вторжения, не может не впечатлять. Если вы хотите обзавестись мощной системой обнаружения вторжений (Intrusion Detection System, IDS) — пожалуйста, подыщите себе такую. Но не брезгуйте использовать дополнительно и "родную" линуксовую систему протоколирования. Помните, могут обнаружиться баги, делающие даже продвинутую IDS бесполезной или неработоспособной, поэтому руководствуйтесь правилом "Defense in Depth" — используйте множественные методы защиты чтобы застраховатсья от выхода из строя одного из них.
* — На самом деле автор применяет в статье термины stateful/stateless firewall/filter. Посовещавшись с некоторыми сетевыми гуру и просмотрев русскоязычную литературу, я выясняю, что устоявшегося перевода этих понятий нет. Для stateful firewall/filter были найдены следующие варианты: "фильтр пакетов с контекстной проверкой", "фильтр с хранением состояния" и "фильтр, отслеживающий соединения".
Некоторые источники утверждают, что все это также является синонимом понятия "динамический файрволл", хотя другие с этим в корне не согласны. Таким образом я, набравшись наглости, ввожу термин "контекстный файрволл/фильтр": в любом случае большая часть статьи посвящена расшифровке этого понятия, а дальше уж вам самим решать — как это дело назвать ;)
Перевод Alice D. Saemon
Сетевые решения. Статья была опубликована в номере 02 за 2001 год в рубрике software
