Компания Netfilter coreteam выпустила новую версию популярного инструмента для построения защиты(брандмауэра) операционной системы Linux - Iptables 1.4.9.

     В последней версии Iptables была проведена работа для совместимости с  ядром Linux 2.6.35, которое вышло совсем недавно.

     Для упрощения работы с IPTables было разработано много графи­ческих оболочек. Здесь расмотренны некоторые из них. Основная функция этих оболочек: управление правилами IPTables. Нужно помнить: той гибкости, которой позволяет достичь командная строка, вы не получите ни от одной оболочки.

Далее...

Динамические IP-адреса обычно применяются при dial-up-до­ступе, а также в больших корпоративных сетях с большим количес­твом машин, где индивидуальная настройка компьютеров отнимает очень много времени.

     Для автоматического конфигурирования узла в Ethernet-сетях использу­ется протокол DHCP. Кроме назначения IP-адреса, этот протокол дает возможность установить различные сетевые параметры узла, в частности IP-адрес шлюза, IP-адреса серверов имен и т.д.

     Использование динамических адресов создает лишние проблемы при конфигурировании брандмауэра. Следовательно, нужно синхронизировать правила IPTables с DHCP-сервером.

Далее...

     До этого IPTables использовался централизованно - только на бранд­мауэре. Но это нельзя рассматривать как полную защиту сети - ведь защищать нужно не только сеть в целом, но и отдельную машину.

     Возьмем, к примеру, ситуацию, в отдельных случаях крекеру удается каким-то образом проникнуть в нейтральную зону - он получил доступ к серверу из нейтральной зоны. В настоящее время он пытается расширить свои «пра­ва», то есть получить доступ к другим машинам, в том числе и брандмауэру. Следовательно, брандмауэр IPTables нужно запускать и на других машинах сети - чтобы защитить эти машины.

Далее...

     Loopback-адреса.

     Адреса обратной петли (127.0.0.0 - 127.255.255.255) никогда не могут ис­пользоваться за пределами интерфейса lo. Если пакеты с loopback-адресами появились на интерфейсе, отличном от lo, значит, они были подделаны (spoffed).

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

Далее...

     Блокирование нежелательных узлов.

     Временами возникает необходимость заблокировать нежелательные узлы или даже всю не­желательную сеть. Для этого лучше всего подходит цель DROP. Надо помнить, что цепочка INPUT содержит пакеты, предназначенные только для машины брандмауэра. Следовательно, нужно контролировать обе цепоч­ки - INPUT и FORWARD, если нужно заблокировать прием данных от нежелательного узла:

Далее...

     Защита нейтральной зоны (DMZ).

     Правила, заданные в сценарии nat.sh, ограничивали поток трафика в нейтральную зону, но не определяли ограничения на ис­ходящий от DMZ-серверов трафик, который может передаваться или в ло­кальную сеть, или в Интернет. В идеале нужно разрешить только ESTABLISED- и RELATED-трафик, так как DMZ-серверы будут только обрабатывать запросы клиен­тов и не будут устанавливать новых соединений.

     Но есть определенная проблема, которая заключается в том, что сервисы, в частности DNS и SMTP, будут устанавливать новые соединения. Если запретить созда­ние новых соединений для DNS-серверов, то прервется работа этих сер­висов. В этом случаем нужно написать более точные правила.

Далее...