Этот раздел содержит всю информацию и FAQи, который я не мог вставить в приведенную выше структуру.
Этот вопрос требует некоторых размышлений. Вы можете попробовать организовать их, чтобы оптимизировать быстродействие (минимизировать число правил-проверок для большинства пакетов) или увеличить управляемость.
Если у вас непостоянная связь, скажем связь PPP, то вы могли бы захотеть установить первое правило в цепочке input "-i ppp0 -j DENY' во время загрузки системы, тогда помещаем нечто такое в ваш скрипт ip-up:
# Создать цепочку `ppp-in' заново.
ipchains-restore -f < ppp-in.firewall
# Заместить правило DENY на цепочку ppp-обработки.
ipchains -R input 1 -i ppp0 -j ppp-in
А в скрипт ip-down:
ipchains -R input 1 -i ppp0 -j DENY
Прежде, чем вы начинете фильтровать наружний трафик, вам надо знать несколько вещей.
ICMP пакеты используются (помимо прочего) для индикации состояний других протоколов (типа TCP и UDP). Пакеты "destination-unreachable" в частности. Блокирование этих пакетов означает, что вы никогда не получите сообщений об ошибках "Host unreachable' или "No route to host'; любые соединения будут только ожидать ответ, который никогда не придет. Это раздражает, но несмертельно.
Более коварная проблема - использование ICMP пакетов в проверках MTU. Все хорошие TCP реализации (включая Linux) используют проверки MTU, чтобы выяснить максимальный размер нефрагментированного пакета, который может принять адресат (фрагментация, снижает эффективность, особенно, когда при потере некоторых фрагментов). Проверка MTU осуществляется посылкой пакетов с установленным битом "Don't Fragment". Если в ответ на эти пакеты приходит ICMP-ответ "Fragmentation needed but DF set" -- то есть "необходима фрагментация, но установлен флаг DF". Это пакеты типа "destination unreachable', и если они не получены, локальный хост не будет уменьшать MTU, и эффективность будет крайне низкой или нулевой.
Также обратите внимание на ICMP сообщения перенаправления (тип 5); они могут использоваться для управления маршрутизацией (хотя хорошие IP стеки защищены), и считаются немного опасными.
Если вы попробуете заблокировать выходящие TCP соединения, не забудьте, что DNS не всегда использует UDP; если ответный пакет от сервера превышает 512 байтов, клиент использует TCP соединение (также на порту номер 53).
DNS в этом случае будет "в общем-то работать'; вы можете обнаружить странные длинные задержки и другие случайные DNS проблемы.
Если ваши DNS запросы всегда направляются на один и тот же самый внешний источник (либо непосредственно, с использованием строки nameserver в /etc/resolv.conf, либо с использованием forward в кеширующем серевере имен), то вам нужно всего лишь позволить TCP соединения между портом domain на этом сервере имен и локальным портом domain (при использовании кэширующего сервера имен) или с портом с большим номером (>1023) при использовании /etc/resolv.conf.
Классическая проблема при пакетной фильтрации - FTP. FTP имеет два режима; традиционный вызывается активным режимом и более современный называется пассивным режимом. Web-браузеры обычно по умолчанию работают в пассивном режиме, но консольные программы FTP обычно по умолчанию работают в активном режиме.
В активном режиме, когда удаленная сторона хочет послать файл (или даже результаты команд ls или dir), она пробует открыть TCP соединение с локальной машиной. Это означает, что вы не можете отфильтровывать эти TCP соединения без прерывания активного FTP.
Если у вас есть опция использования пассивного режима, то все прекрасно; пассивный режим создает соединения от клиента к серверу, даже для входящих данных. Вам рекомендуется разрешить только TCP соединения с номерами портов более 1024 и не 6000..6010 (используются для XWINDOWS).
Linux-машины теперь невосприимчивы к известному Пингу Смерти, который заключается в посылке чересчур большого ICMP пакета, который переполняет буфера TCP-стека на машине-приемнике и приводит к хаосу.
Если вы защищаете машины, которые могли бы быть уязвимы для "пинга смерти", то вы могжете просто фрагментировать блоки ICMP. Нормальный ICMP пакеты не настолько велики, чтобы требовать фрагментации, так что фрагментироваться будут только очень большие пакеты - такие как "пинги смерти". Я слышал (по непроверенным данным), что некоторые системы могут пострадать и от последних фрагментов больших пакетов ICMP, поэтому рекомендуется фрагментировать не только первый фрагмент.
Хотя все известные программы, использующие эту атаку, генерируют ICMP-пакеты, для той же цели можно использовать TCP или UDP-пакеты (или неизвестный протокол), так что эта защита может служить лишь как временная мера.
Teardrop и Bonk - две атаки (главным образом против машин Windows NT Microsoft), которые полагаются на накладывающиеся фрагменты. Решается это дефрагментацией пакетов на маршрутизаторе, либо запретом приема фрагментированных пакетов на уязвимых машинах.
Говорят, в некоторых "менее надежных" TCP стеках имеются проблемы, возникающие при большом количестве фрагментов пакетов, когда на машину приходят не все фрагменты. В Linux нет этой проблемы. Вы можете отфильтровывать фрагменты (что может отразиться и на нормальных пакетах) или скомпилировать ваше ядро с опцией "IP: always defragment "Y"" (только в том случае, если ваша машина Linux - единственный маршрут для этих пакетов).
Бывают ситуации, когда надо на лету поменять правила файервола. По неосторожности, вы можете пропустить некоторые пакеты во время изменений правил. Упрощенный подход заключается в следующем:
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
... вносим изменения ...
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
На время внесения изменений пакеты будут отбрасываться.
Если ваши изменения касаются только одной цепочки, то можно создать новую цепочку с новыми правилами, и затем заменить ("-R") правило, которое указывает на старую цепочку, на то, которое указывает на новую цепочку; затем вы можете удалить старую цепочку. Эта замена произойдет атомарно.
IP спуфинг - отправка пакетов с поддельным IP адресом источника. Так как фильтрация пакета принимает решения на основани адреса источника, то IP спуфинг используется, чтобы ввести пакетный фильтр в заблуждение.
Также он используется при комплексных атаках, с использованием SYN, Teardrop, "пинга смерти" и т.п.(если не знаете что это такое - не волнуйтесь), чтобы атакуемый хост не знал, что все это валится с одного адреса .
Самый лучший способ защититься от IP spoofing называется Source Address
Verification (проверка адреса источника). Эта проверка выполняется программами
маршрутизации, в не программами фильтрации. Поищите файл
/proc/sys/net/ipv4/conf/all/rp_filter.
Если он существует, то можно включать Source Address Verification при загрузке. Чтобы cделать это, вставьте следующие строки в скрипты инициализации перед инициализацией сетевых интерфейсов:
# Наилучший способ: включить Source Address Verification и защитить
# от спуфинга все текущие и будущие интерфейсы.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Установка защиты от спуфинга... "
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
echo "готово."
else
echo ПРОБЛЕМЫ ПРИ ПОПЫТКЕ ВКЛЮЧИТЬ ЗАЩИТУ ОТ СПУФИНГА.
echo "Нажмите CONTROL-D для выхода в shell и продолжения системной загрузки."
echo
# Запуск однопользовательского shell на консоли
/sbin/sulogin $CONSOLE
fi
Если вы не можете сделать это, то вы можете вручную вставлять правила для
защитыь каждого интерфейса. Это требует знаний о каждом интерфейсе. Ядра 2.1
автоматически отклоняют пакеты, приходящие с адресов 127.* (зарезервированных
для локального петлевого интерфейса, lo).
Например, скажем, мы имеем три интерфейса: eth0, eth1 и ppp0. Мы можем использовать ifconfig, чтобы узнать адреса и сетевые маски интерфейсов.
Допустим, что eth0 присоединен к сети 192.168.1.0 с сетевой маской 255.255.255.0, eth1 присоединен к сети 10.0.0.0 с сетевой маской 255.0.0.0, а ppp0 соединен с Internet (где разрешены любые адреса за исключением зарезервированных частных адресов IP), мы вставили бы следующие правила:
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
Такой подход не столь хорош как Source Address Verification, потому что
если ваши сетевые настройки изменились, вы должны изменить и правила фильтра.
Для ядер 2.0 вам желательно защитить и петлевой интерфейс:
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
Существует userspace библиотека, написанная мною, которая включена в исходный дистрибутив, называемая "libfw". Она использует возможность IP цепочек 1.3 и выше копировать пакет в userspace (используя опцию ядра IP_FIREWALL_NETLINK).
Значение метки может использоваться для определения параметров Quality of Service пакетов, или определения, на какой порт надо отфорвардить пакеты. Я никогда пользовался ни тем, ни другим, но если вы хотите написать об этом, пожалуйста, свяжитесь со мной.
Используя эту библиотеку могут быть выполнены в userspace вещи типа stateful проверки (я предпочитают термин динамический firewalling). Другие красивые идеи заключаются в управлении пакетами на основании пользователя, с помощью userspace daemon. Это должно быть довольно просто.
ftp://ftp.interlinx.bc.ca/pub/spf - это сайт SPF проекта Brian Murrell'а, который осуществляет трекинг соединения в userspace. Это значительно улучшает защиту низкопроизводительных сайтов.
В настоящее время документация довольно скупая, но имеется список почтовой рассылки, в котором Брайен ответил на некоторые вопросы:
> Я полагаю, это делает в точности то, что мне надо: установка временного
> "обратного"-правила, чтобы позволить приходить пакетам как бы ответом на
> исходящий запрос.Да, именно это он делает. Большинство протоколов его понимают, больше "обратные" правила it gets right. Прямо сейчас он поддерживается для (говорю навскидку, заранее извиняюсь за ошибки или пропуски) FTP (и активного, и пассивного и входящего и исходящего), некоторых RealAudio, traceroute, ICMP и основного ICQ (входящего от ICQ сервера и прямых TCP соединений, однако вторичные прямые TCP соединения для операций типа передач файлов и т.д. пока нет)
> Это замена ipchains или добавление?
Это - добавление. ipchains - это средство для ограничения прохождения пакетов через Linux машину. SPF - драйвер, постоянно контролирующий трафик и сообщающий ipchains как изменять политику фильтрации для отображения изменений в шаблонах трафика.
Michael Hasenstein из SuSE написал патч для ядра, который добавляет в ipchains трекинг ftp-соединений. Сейчас его можно найти на http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz
В ядрах 2.3 firewalling и NAT разрабатываются повторно. Планы и обсуждения можно найти в архиве netdev и списке рассылки ipchains-dev. Эти расширения должны прояснить много проблем применения (firewalling и маскарадинг не должны быть такими жесткими) и позволить создать гораздо более гибкий firewalling.