Операционные системы - статьи

         

Полезные советы


Меры безопасности во время изменения правил фильтрации

Во время изменения правил фильтрации некоторые нежелательные пакеты могут проскочить через 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'

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

Соответственно, скрипт ip-down может выглядеть так: 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

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

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

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

Какие пакеты не надо уничтожать

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

  • 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.


  • Защита от атак по IP

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


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


    • Teardrop и bonk - в основном применяются против Windows NT, основаны на пересекающихся фрагментах. Либо заставьте ваш шлюз дефрагментировать все пересылаемые пакеты, либо запретите пересылку фрагментов на чувствительные к этой атаке машины.


    • Фрагментированные бомбы - некоторые ненадежные реализации TCP/IP-стека не могут нормально обработать большое количество фрагментов, если не получают все необходимые фрагменты. Решение то же, что и в предыдущем случае: либо заставьте ваш шлюз дефрагментировать все пересылаемые пакеты, либо запретите пересылку фрагментов на чувствительные к этой атаке машины.


    • Внимание! Это далеко не полный перечень известных атак по протоколу 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



      Такое решение хуже, чем Проверка Адреса Отправителя, поскольку при изменении сетевой конфигурации вам придется переделывать правила фильтрации. Ядра 2.1.x и выше автоматически отвергают пакеты с адресом отправителя 127.*.*.*, если они приходят не с локального интерфейса. Если у вас ядро 2.0.x, вы можете таким же образом защитить интерфейс lo: ipchains -A input -I !lo -s 127.0.0.0/8 -j DENY

      Где взять

      На официальной странице ipchains: .

      Скрипты для ipchains:

      Ссылки

    • Официальная страница ipchains:


    • Руководство по ipchains by Paul Russell, на котором по большей части основывается эта статья


    • Руководство по настройке firewall'ов, в том числе и с помощью ipwfwadm by Mark Grennan:


    • Краткое руководство по IP-маскарадингу by Ambrose Au and David Ranch: . Там, в частности, есть советы по конфигурированию машин в локальной сети, которые ходят в интернет через маскарадящий шлюз, для многих операционных систем и конкретных программ.


    • Руководство сетевого администратора Линукса:


    • Официальная домашняя страница маскарадинга для Линукса:


    • Indyramp Consulting - дополнительная информация о маскарадинге, список рассылки по маскарадингу и его архив:


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



      Содержание раздела