ipchains –A prov –p udp –destination-port 139 –j REJECT
Можно запретить локальным процессам получать пакеты от определенных узлов. Например, я не хочу, чтобы мой Netscape тратил время на получения баннеров от машины с адресом 911.111.111.111. Для этого, возможно, удобнее было бы воспользоваться прокси-сервером, но сейчас нужно продемонстрировать, как это можно сделать с помощью IPChains.
ipchains –A output –d 911.111.111.111 –j REJECT
В примере я специально привел несуществующий IP-адрес, чтобы не создать антирекламу какому-нибудь узлу Сети.
Для того, чтобы ваши правила были постоянными (при перезагрузке машины правила IPChains теряются), используйте сценарии ipchains-save и ipchains-restore. Настройте свои правила, затем выполните команду:
# ipchains-save > /etc/ipchains.rules
В листинге 14.1 представлен сценарий, управляющий пакетной фильтрацией.
Листинг 14.1. Сценарий управления пакетной фильтрацией#! /bin/sh
# Сценарий управления пакетной фильтрацией.,
# Если правил нет, то ничего не делать.
[ –f /etc/ipchains.rules ] || exit 0
case "51" in
start)
echo –n "Включение пакетной фильтрации:" /sbin/ipchains-restore < /etc/ipchains.rules || exit 1
echo 1 > /proc/sys/net/ipv4/ip_forward
echo ". "
;;
stop)
echo –n "Отключение пакетной фильтрации:"
echo 0 > /proc/sys/net/ipv4/ip_forward
/sbin/ipchains –X
/sbin/ipchains –F
/sbin/ipchains –P input ACCEPT
/sbin/ipchains –P output ACCEPT
/sbin/ipchains –P forward ACCEPT
echo " . "
;;
*)
echo "Использование: /etc/init.d/packetfliter {start|stop}"
exit 1
;;
esac
exit 0
Этот сценарий нужно добавить в сценарии загрузки системы.
14.3. Различные примеры
В этом пункте представлены несколько примеров для обеспечения безопасности вашей сети.
14.3.1. Пакеты SYN
Пакеты SYN используются для запроса на установку соединения. Вы можете отвергать эти пакеты для того, чтобы прервать попытки установить соединение.
Иногда это необходимо, если вы хотите получать пакеты только в одном направлении, например, рабочая станция должна соединяться с сервером, но сервер не должен соединяться с рабочей станцией.
Для фильтрации пакетов SYN нужно использовать опцию –у. Например, попытки соединения по протоколу TCP от узла 192.168.1.34 указываются так:
–р TCP –s 192.168.1.34 –у
14.3.2. Фрагментация пакетов
Иногда передаваемый пакет слишком большой, чтобы его можно было бы передавать за один раз. Если такое происходит, то пакет делится на фрагменты, и эти фрагменты пересылаются. Компьютер, которому этот пакет предназначен, собирает эти фрагменты в один пакет.
Ядро должно анализировать начало пакета, которое содержится в первом фрагменте. Ведь только в первом фрагменте находится заголовок исходного пакета. Для решения этой проблемы вам нужно перекомпилировать ядро с включенной опцией IP: always defragment.
В результате любое правило фильтрации не будет работать для фрагментированных пакетов. При этом только первый фрагмент будет обработан как пакет, а остальные не будут обрабатываться. Однако можно определить правило специально для фрагментированных пакетов. Это можно сделать с помощью опции –f. Эту опцию нельзя применять при указании портов протоколов TCP или UDP, кода ICMP или пакетов SYN.
Следующая команда отбросит все фрагменты, приходящие на компьютер server.domain.com:
# ipchains –A output –f –d 192.168.1.1 –j DENY
14.3.3. Пинг смерти
Есть хорошая новость по этому поводу: ОС Linux невосприимчива к пингу смерти. Напомню, что пинг смерти заключается в посылке большого пакета ICMP, который переполняет буферы стека TCP на компьютере-получателе.
14.3.4. IР-спуфинг
IP-спуфинг — это отправление пакетов с поддельным IP-адресом источника. Так как фильтрация пакета принимает решения на основании адреса источника, то IP-спуфинг используется, чтобы ввести пакетный фильтр в заблуждение.
Для решения этой проблемы мы можем использовать Проверку Адреса Источника (Source Address Verification) или использовать следующие команды IPChains:
ipchains –A prov –s 192.168.1.1/16 –l –j DENY
ipchains –A prov –s 127.0.0.1/8 –l –j DENY
Вторая команда нужна для ядер версий 2.0.x, но если мы ее укажем, явно хуже не будет. Опция –l позволяет протоколировать «плохие» пакеты. Файлом протокола является /var/log/messages. Ядра версий 2.1.x автоматически отклоняют пакеты, приходящие с адресов 127.*, которые зарезервированы для локального интерфейса.
Для включения проверки адреса источника можно воспользоваться сценарием, представленном в листинге 14.2.
Листинг 14.2. Запрещение IР-спуфинга# Наилучший способ: включить 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_fliter; do
echo 1 > $f
done
echo "готово."
else
echo ПРОБЛЕМЫ ПРИ ПОПЫТКЕ ВКЛЮЧИТЬ ЗАЩИТУ ОТ СПУФИНГА.
echo "Нажмите CONTROL-D для выхода в shell и продолжения сист. загрузки."
echo
# Запуск однопользовательской оболочки на консоли
/sbin/sulogin $CONSOLE
fi
Защита с использованием проверки адреса источника является более надежной.
14.3.5. Фильтрация фрагментированных бомб
Иногда возникает такая ситуация, когда на машину приходят не все фрагменты. Такое бывает при очень большом количестве фрагментов. Обычно при использовании ОС Linux данная проблема вообще отпадает, но все-таки некоторые администраторы предпочитают «перестраховаться».
Для решения этой проблемы вам нужно всего лишь перекомпилировать ядро с включенной опцией IP: always defragment. При этом нужно учитывать, чтобы ваш шлюз был единственным маршрутом для пакетов. Вторым способом является фильтрация фрагментов, но это может отразиться на нормальных пакетах. Честно говоря, я не особо забочусь об этой проблеме при настройке своего сервера.
14.4. Практический пример
А теперь рассмотрим более серьезный пример. Этот пример частично позаимствован мною из руководства DNS-HOWTO. Но прежде чем перейти непосредственно к практике, попробую объяснить некоторые термины, которые будут встречаться ниже.
Прежде всего, определимся, что называется маскарадингом. Объяснение я приведу на сугубо формальном языке. Маскарадинг перезаписывает заголовки пакетов, когда они проходят через шлюз так, чтобы казалось, что они всегда исходят от шлюза непосредственно. Затем он перезаписывает ответы так, чтобы клиенту казалось, что они пришли от первоначального получателя. Например, у вас есть шлюз и одна небольшая локальная сеть. Шлюз обладает реальным IP-адресом 1.1.1.1, а адрес вашей локальной сети — 192.168.1.0. Клиент с IP-адресом 192.168.1.5 пытается обратиться к узлу http://www.romb.net. IP-адрес этого узла 62.244.59.193. Пакет клиента проходит через шлюз. IP-адрес шлюза в локальной сети — 192.168.1.1. Шлюз перезаписывает заголовок пакета и устанавливает вместо адреса клиента свой собственный адрес, то есть 1.1.1.1. После получения ответа, он перед отправлением пакета клиенту опять перезаписывает заголовок пакета и изменяет свой адрес 1.1.1.1 на адрес узла www.romb.net — 62.244.59.193. С точки зрения узла www.romb.net соединение было установлено между адресами 1.1.1.1 и 62.244.59.193. С точки зрения клиента соединение произошло между интерфейсами с адресами 192.168.1.5 и 62.244.59.193.
Итак, приступим к рассмотрению практического примера. Предположим, у нас имеется соединение с Интернет и две подсети. Интерфейсу ррр0 назначен реальный IP-адрес — 111.1.1.1, интерфейсу eth0 назначен IP-адрес внутренней сети — 192.168.2.1, а интерфейсу eth1 – 192.168.1.1. (см. рис. 14.1).
Рис. 14.1. Структура сети
Нам нужно обеспечить маршрутизацию между тремя сетями: Интернет, 192.168.2.0 и 192.168.1.0. Другими словами, требуется таким образом настроить пакетную фильтрацию, чтобы можно было пропинговать любую сеть или выполнить трассировку пакетов через любую сеть. Пинговать сеть будем, естественно, с помощью программы ping, а выполнять трассировку будем программой traceroute. В ОС Windows NT те же операции можно выполнить с помощью программ ping и tracert с
