Как и в сценарии для простой реализации сети с DMZ, первоначально определяются слу­жебные переменные, которые будут использоваться в новом сценарии - firewall.sh. Описание каждой переменной можно найти в этом же разделе. Начало сценария будет таким:

     Защита брандмауэра.

     В сценарии nat.sh доступ к брандмауэру был оставлен:

     Самым простым решением будет простое удаление этих двух правил и запрещение входящего и исходящего трафика для брандмауэра (это не касается Forward-трафика) - ведь брандмауэр должен только передавать (forward) трафик, ему не нужно ни устанавливать соединения, ни принимать запросы на соединения. Следовательно, эти два правила изменятся следующим образом:

     Здесь запрещены новые исходящие соединения (цепочка OUTPUT). Пока что разрешен только трафик для уже установленных соединений (ESTABLISHED) и относящийся к ним трафик (RELATED). Создание но­вых соединений будет управляться другими правилами.

     DNS-трафик.

     Если правила IPTables содержат имена узлов (а не только IP-адреса), нуж­но разрешить DNS-трафик для трансляции имен в IP-адреса:

     Если нет своего DNS-сервера, можно использовать сервер про­вайдера:     Непосредственно будет использоваться внешний интерфейс $IF_EXT (а не IF_ DMZ), а вместо IP-адреса внутреннего сервера будет IP-адрес DNS-сервера провайдера.

     Правила SSH-доступа.

     Предоставлять SSH-доступ к брандмауэру удаленным клиентам - крайне плохая идея. Если брандмауэр будет скомпрометирован, злоумышленник сможет контролировать всю сеть. В идеале доступ к брандмауэру должен быть ограничен лишь консолью, при этом должен быть разрешен только физический доступ к брандмауэру - никакого удаленного доступа. Но для удобства временами полезно разрешить SSH-доступ узлам внутренней сети (но не узлам нейтральной зоны):

     Если возможно, доступ к брандмауэру должен быть ограничен определенными машинами:

     В хорошо защищенной модели сети удаленный доступ не используется вообще. Безопасной альтернативой разрешения уда­ленного доступа удаленным узлам является создание специального SSH-cepвера, расположенного в нейтральной зоне. Обязательно надо, чтобы в качестве SSH-сервера использовалась отдельная машина.

     Правила IPTables на брандмауэре должны быть сконфигурированы следу­ющим образом: SSH-доступ к брандмауэру разрешается только SSH-серверу нейтральной зоны:

     Соответствующее правило требуется NAT:

     SSH - это только одна из форм удаленного доступа, можно использовать и другие формы, например виртуальные частные сети (VPN).

     DHCP.

     Протокол DHCP (Dynamic Host Configuration Protocol) используется для динамического конфигурирования узла: назначения IP-адреса узла, адреса шлюза и других параметров. Как правило, протокол DHCP используется или в сетях провайдеров, или в больших корпоративных сетях.

     В первом случае диапазон IP-адресов ограничен, что не позволяет каждо­му клиенту назначить реальный IP-адрес. Следовательно, провайдеру выделяется определенный диапазон реальных адресов, например 100. 70 (по количеству входящих линий) из них может использоваться для dial-up-клиентов, ко­торые подключаются к модемному пулу провайдера, а остальные 30 могут быть использованы для других нужд (для серверов провайдера и для кли­ентов, использующих постоянные соединения).

     В случае с корпоративной сетью ситуация чуть другая: DHCP может использоваться или для подключения удаленных клиентов, или же для удобства администратора - чтобы не настраивать все компьютеры в сети.

     Протокол DHCP работает на двух портах - 68 (порт отправителя) и 67 (порт получателя). Когда DHCP-клиент подключается к сети, он посы­лает широковещательное сообщение DHCPDISCOVER, используя порт отправителя 68, а порт получателя - 67. Получив это сообщение, DHCP-сервер отправляет клиенту сообщение DHCPOFFER. Получив это сообщение, DHCP-клиент отправляет со­общение-запрос DHCPREQUEST. В ответ на это сообщение DHCP-сервер отправляет клиенту сообщение DHCPACK, содержащее IP-адрес и другую конфигурационную информацию.

     Сначала нужно разрешить начальное сообщение DHCPDISCOVER и ответы на это сообщение - DHCPOFFER:

     Чтобы предотвратить попытки установки клиентами нашего ISP в сети еще одного DHCP-сервера, нужно принимать ответы только от своего DHCP-сервера:

     Так как сообщения DHCPACK исходят от сервера, которому было от­правлено сообщение DHCPREQUEST, они будут помечены как ESTAB­LISHED, следовательно, будут пропущены брандмауэром.