Кто не спрятался, я не виноват!

Во время изменения правил фильтрации некоторые нежелательные пакеты могут проскочить через firewall. Рекомендуется следующий подход:

# сначала вставляем во все цепочки правила, уничтожающие все пакеты
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

Если у вас есть непостоянный интерфейс, то во время начальной загрузки вы можете, например, установить первое правило во входной цепочке

'-i ppp0 -j DENY'

# восстановить цепочку ppp-in
ipchains-restore -f < ppp-in.firewall
# заменить первое правило входной цепочки
ipchains -R input 1 -I ppp0 -j ppp-in

ipchains -R input 1 -i ppp0 -j DENY

С помощью скрипта ipchains-save, входящего в комплект ipchains-scripts ( ftp://ftp.rustcorp.com/ipchains/ipchains-scripts-1.1.2.tar.gz) можно записать текущие правила одной или всех цепочек в файл. Это делается так:

ipchains-save > my-firewall

Для восстановления правил из фала применяется скрипт ipchains-restore:

ipchains-restore < my-firewall

Прежде чем уничтожать все ненужные вам пакеты, учтите следующее:

• ICMP-пакеты, помимо всего прочего, используются для индикации ошибок в других протоколах (например, в TCP и UDP). Блокирование таких пакетов приведет к тому, что вы никогда не получите сообщений Host unreachable или No route to host, и попытки соединиться с такими хостами будут ожидать ответа, который никогда не придет. Это плохо, но не фатально.

  Гораздо хуже другая проблема - использование ICMP для определения MTU (Maximum Transfer Unit - максимальный размер пакета для передачи по некоторому каналу связи). Все хорошие реализации TCP (в том числе и Линукс) используют определение MTU с целью вычислить максимальный размер пакета, который может дойти до получателя без промежуточной фрагментации. Фрагментация замедляет передачу данных, особенно если фрагменты иногда теряются. Определение MTU производится путем посылки получателю пакетов с установленным флагом "Don't Fragment" (Не фрагментировать). Если в ответ приходит ICMP-квитанция "Fragmentation needed but DF set" (требуется фрагментация, но установлен флаг Не фрагментировать), то посылается пакет меньшего размера. Если же такая квитанция не будет получена, то размер пакета не будет автоматически уменьшаться, что может привести к сильному замедлению или вообще блокированию передачи данных.

• TCP-соединения с DNS-серверами. Если вы запрещаете исходящие TCP-соединения, помните, что DNS не всегда использует UDP. Если размер ответа от сервера превышает 512 байт, то клиент использует TCP-соединение с сервером (также на 53 порт). Если ваши DNS-запросы всегда посылаются на один DNS-сервер, то вам надо разрешить TCP-соединения на 53 порт DNS-сервера либо с 53 порта вашей машины (если у вас установлен собственный кэширующий DNS-сервер), либо с непривилегированных портов (>1023). Либо и то, и другое.
• FTP может работать в двух режимах: один из них (стандартный) называется активным, а другой - пассивным. WWW-браузеры обычно работают в пассивном режиме, а обычные ftp-клиенты - в активном.

  В активном режиме если удаленный сервер хочет передать клиенту данные (не только файл, но даже результат выполнения команды ls или dir), он пытается установить соединение с клиентской машиной. Следовательно, вы не можете запрещать такие входящие TCP-соединения, не мешая нормальной работе активного ftp-клинета. Если у вашего клиента есть возможность работы в пассивном режиме, это прекрасно. В пассивном режиме соединение устанавливается от клиента к серверу, даже для приема данных. В противном случае рекомендуется разрешить входящие TCP-соединения на порты 1024 и выше, кроме портов 6000-6010, потому что они используются системой X-Windows.

Некоторые типы пакетов могут при определенных условиях вызывать нарушения в работе TCP/IP-стека протоколов, вплоть до полного зависания компьютеров. Ниже приводятся некоторые рекомендации по настройке фильтрации, если за вашим firewall'ом есть компьютеры, чувствительные к таким атакам. Свежие ядра Линукса нечувствительны к этим атакам, но другие системы могут нуждаться в защите.

• Ping of Death - основан на посылке ненормально больших ICMP-пакетов, которые вызывают переполнение входного буфера пакетов и зависание. Для защиты запретите пересылку фрагментов ICMP-пакетов. Нормальные ICMP-пакеты маленькие, фрагментации не подвергаются, и на них запрет не скажется. Хотя все известные программы, использующие эту атаку, генерируют ICMP-пакеты, никто не запрещает использовать для той же цели TCP или UDP-пакеты, так что эта защита не слишком надежна.
• Teardrop и bonk - в основном применяются против Windows NT, основаны на пересекающихся фрагментах. Либо заставьте ваш шлюз дефрагментировать все пересылаемые пакеты, либо запретите пересылку фрагментов на чувствительные к этой атаке машины.
• Фрагментированные бомбы - некоторые ненадежные реализации TCP/IP-стека не могут нормально обработать большое количество фрагментов, если не получают все необходимые фрагменты. Решение то же, что и в предыдущем случае: либо заставьте ваш шлюз дефрагментировать все пересылаемые пакеты, либо запретите пересылку фрагментов на чувствительные к этой атаке машины.

IP-спуфингом (spoofing) называется посылка пакетов с обратным адресом другой машины. Поскольку фильтрация пакетов во многом основывается на адресе отправителя, спуфинг может использоваться, чтобы обмануть фильтр пакетов. Кроме того, он используется для маскировки атакующего при атаках типа SYN, Teardrop, Ping of Death, и других. Если вы не знаете, что это такое, это не важно ;-)

Лучший способ защититься от IP-спуфинга называется Проверка Адреса Отправителя (Source Address Verification), и выполняется программами маршрутизации, а не фильтрации пакетов. Проверьте, существует ли у вас на машине файл /proc/sys/net/ipv4/conf/all/rp_filter. Если да, то верным решением будет включение Проверки Адреса Отправителя во время начальной загрузки машины. Для этого следует вставить следующие команды в один из ваших скриптов инициализации, до инициализации сетевых интерфейсов:

# Включаем Проверку Адреса Отправителя и получаем
# защиту от спуфинга на всех существующих и будущих интерфейсах
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
  echo -n "Setting up IP spoofing protection..."
  for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
      echo 1 > $f
  done
  echo "done."
else
  echo PROBLEMS SETTING UP IP SPOOFING PROTECTION.  BE WORRIED.
  echo "CONTROL-D will exit from this shell and continue system startup."
  echo
  # Start a single user shell on the console
  /sbin/sulogin $CONSOLE
fi

К примеру, у вас на машине 3 интерфейса - eth0, eth1, ppp0. Вы можете использовать ifconfig, чтобы узнать какие адреса и маски сети используются на каждом из интерфейсов. Предположим, eth0 соединен с сетью 192.168.1.0/255.255.255.0, eth1 - с сетью 10.0.0.0/255.0.0.0, а ppp0 - с остальным интернетом (поэтому на этом интерфейсе возможны любые адреса, кроме локальных сетей). Тогда надо добавить следующие правила:

ipchains -A input -i eth0 -s ! 192.168.1.0/24 -j DENY
ipchains -A input -i ! eth0 -s 192.168.1.0/24 -j DENY
ipchains -A input -i eth1 -s ! 10.0.0.0/8 -j DENY
ipchains -A input -i ! eth1 -s 10.0.0.0/8 -j DENY

ipchains -A input -I !lo -s 127.0.0.0/8 -j DENY

На официальной странице ipchains: http://www.rustcorp.com/linux/ipchains.

Скрипты для ipchains: ftp://ftp.rustcorp.com/ipchains/ipchains-scripts-1.1.2.tar.gz

• Официальная страница ipchains: http://www.rustcorp.com/linux/ipchains
• Руководство по ipchains by Paul Russell, на котором по большей части основывается эта статья Ipchains-HOWTO
• Руководство по настройке firewall'ов, в том числе и с помощью ipwfwadm by Mark Grennan: Firewall-HOWTO
• Краткое руководство по IP-маскарадингу by Ambrose Au and David Ranch: IP Masquerade mini HOWTO. Там, в частности, есть советы по конфигурированию машин в локальной сети, которые ходят в интернет через маскарадящий шлюз, для многих операционных систем и конкретных программ.
• Руководство сетевого администратора Линукса: http://metalab.unc.edu/mdw/LDP/nag/nag.html
• Официальная домашняя страница маскарадинга для Линукса: http://ipmasq.cjb.net
• Indyramp Consulting - дополнительная информация о маскарадинге, список рассылки по маскарадингу и его архив: http://www.indyramp.com/masq/
• Linux Documentation Project (LDP)

© Александр Дилевский 06-15.06.1999.