Новые книги

Iptables Tutorial 1.1.19

Автор: (C)

Oskar Andreasson

Copyright (C) 2001-2002 by Oskar Andreasson

Перевод: (C)

Андрей Киселев
The Windows Driver Model has two separate but equally important aspects. First, the core model describes the standard structure for device drivers. Second, Microsoft provides a series of bus and class drivers for common types of devices.

The core WDM model describes how device drivers are installed and started, and how they should service user requests and interact with hardware. A WDM device driver must fit into the Plug and Play (PnP) system that lets users plug in devices that can be configured in software.

Microsoft provides a series of system drivers that have all the basic functionality needed to service many standard types of device. The first type of system driver supports different types of bus, such as the Universal Serial Bus (USB), IEEE 1394 (FireWire) and Audio port devices. Other class drivers implement standard Windows facilities such as Human Input Devices (HID) and kernel streaming. Finally, the Still Image Architecture (STI) provides a framework for handling still images, scanners, etc.

These system class drivers can make it significantly easier to write some types of device driver. For example, the USB system drivers handle all the low-level communications across this bus. A well defined interface is made available to other drivers. This makes it fairly straightforward to issue requests to the USB bus.

Testing a Firewall Configuration

Проверка конфигурации Firewall

После того, как вы разработали соответствующую конфигурацию firewall, важно убедиться, что она делает именно то, что нужно. Один способ сделать это состоит в том, чтобы использовать тестовый компьютер вне вашей сети для попытки проникнуть через firewall. Но это может быть медленно и ограничено только теми адресами, которые Вы можете использовать.

Более быстрый и простой метод доступен в реализации Linux firewall. Он позволяет Вам вручную генерировать тесты и выполнять их через firewall точно так, как если бы Вы проверяли их с фактическими пакетами. Все варианты поддержки firewall ядром Linux (ipfwadm, ipchains и iptables) обеспечивают поддержку для этого стиля тестирования. Реализация включает использование соответствующей команды check.

Общая процедура теста следующая:

  1. Выберите тип firewall для использования: ipfwadm, ipchains или iptables.

  2. Разработайте ряд тестов, которые определят, работает ли ваш firewall так, как нужно. Для этих тестов Вы можете использовать любой источник или адрес отправителя, так что выберите комбинации адресов, которые должны быть приняты и другие, которые должны быть отвергнуты. Если Вы принимаете или отвергаете только некоторые диапазоны адресов, хорошей идеей будет проверить адреса с обеих сторон границы диапазона: по одному внутри границы и снаружи. Это будет гарантировать, что Вы имеете правильные границы, потому что иногда просто определить неправильную маску подсети в конфигурации. Если Вы фильтруете в соответствии с протоколом и номером порта, тесты должны также проверить все важные комбинации этих параметров. Например, если Вы предполагаете принимать только TCP-пакеты, проверьте, что UDP-пакеты отклоняются.

  3. Разработайте правила для ipfwadm, ipchains или iptables, чтобы выполнить каждый тест. Вероятно, стоит записать все правила в скрипт, так что Вы можете проверять и перепроверять все без проблем по мере исправления ошибок или изменений проекта. Тесты используют почти тот же самый синтаксис, поскольку определяют правила, но в качестве параметров берут немного другие значения. Например, исходный параметр адреса в спецификации правила определяет исходный адрес, с которого должен придти пакет, который будет соответствовать этому правилу. Исходный параметр адреса в синтаксисе теста, напротив определяет исходный адрес тестового пакета, который будет сгенерирован. Для ipfwadm Вы должны использовать опцию -c, чтобы определить, что эта команда является тестом, в то время как для ipchains и iptables Вы должны использовать опцию -C. Во всех случаях Вы должны всегда определять исходный адрес, адрес получателя, протокол и интерфейс, которые нужно использовать для теста. Другие параметры, типа номера порта или битов TOS, являются факультативными.

  4. Выполните каждую команду теста и обратите внимание на вывод. Вывод каждого теста будет одним словом, указывающим конечного адресата пакета после его прохождения через firewall. Для ipchains и iptables определенные пользователем цепочки будут проверены в дополнение к встроенным.

  5. Сравните вывод каждого теста с желательным результатом. Если имеются расхождения, Вы будете должны анализировать набор правил чтобы определить, где вы сделали ошибку. Если Вы записали команды теста в файл скрипта, Вы сможете легко повторно выполнить тест после исправления ошибок в конфигурации firewall. Это гарантирует, что активная конфигурация, которую Вы проверяете фактически, отражает набор команд в скрипте конфигурации.

А теперь практика! Напишем тест правил для ipchains. Наша локальная сеть в примере имеет адрес 172.16.1.0 с маской сети 255.255.255.0. Мы разрешаем внешние TCP-соединения с нашими web-серверами. Ничего больше не должно работать напрямую. Начнем с передачи, которая точно должна работать (из нашей локальной сети):

# ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 accepted

Заметьте, что в параметрах нужно передать и путь для описания пакета. Вывод команды указывает на то, что пакет был принят для пересылки, которая является именно тем, на что мы надеялись.

Теперь попробуйте другой тест, на сей раз с исходным адресом, который не принадлежит нашей сети. Этот должен быть отклонен:

# ipchains -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0 denied

Попробуйте несколько больше тестов, на сей раз с теми же самыми деталями, что и в первом тесте, но с различными протоколами. Они должны быть отклонены:

# ipchains -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied
# ipchains -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied

Попробуйте другой порт адресата, снова ожидая, что этот пакет должен быть отклонен:

# ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0 denied

Конечно, полная проверка дело трудное и долгое, порой столь же трудное, как и разработка правильной конфигурации firewall, но зато защита будет действительно надежной!