Денис Колисниченко - Linux-сервер своими руками

ipchains –A prov –p tcp –destination-port 139 –j REJECT

ipchains –A prov –p udp –destination-port 139 –j REJECT

Можно запретить локальным процессам получать пакеты от определенных узлов. Например, я не хочу, чтобы мой Netscape тратил время на получения баннеров от машины с адресом 911.111.111.111. Для этого, возможно, удобнее было бы воспользоваться прокси-сервером, но сейчас нужно продемонстрировать, как это можно сделать с помощью IPChains.

ipchains –A output –d 911.111.111.111 –j REJECT

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

Для того, чтобы ваши правила были постоянными (при перезагрузке машины правила IPChains теряются), используйте сценарии ipchains-save и ipchains-restore. Настройте свои правила, затем выполните команду:

# ipchains-save > /etc/ipchains.rules

В листинге 14.1 представлен сценарий, управляющий пакетной фильтрацией.

#! /bin/sh

# Сценарий управления пакетной фильтрацией.,

# Если правил нет, то ничего не делать.

[ –f /etc/ipchains.rules ] || exit 0

case "51" in

start)

echo –n "Включение пакетной фильтрации:" /sbin/ipchains-restore < /etc/ipchains.rules || exit 1

echo 1 > /proc/sys/net/ipv4/ip_forward

echo ". "

;;

stop)

echo –n "Отключение пакетной фильтрации:"

echo 0 > /proc/sys/net/ipv4/ip_forward

/sbin/ipchains –X

/sbin/ipchains –F

/sbin/ipchains –P input ACCEPT

/sbin/ipchains –P output ACCEPT

/sbin/ipchains –P forward ACCEPT

echo " . "

;;

*)

echo "Использование: /etc/init.d/packetfliter {start|stop}"

exit 1

;;

esac

exit 0

Этот сценарий нужно добавить в сценарии загрузки системы.

В этом пункте представлены несколько примеров для обеспечения безопасности вашей сети.

Пакеты SYN используются для запроса на установку соединения. Вы можете отвергать эти пакеты для того, чтобы прервать попытки установить соединение.

Иногда это необходимо, если вы хотите получать пакеты только в одном направлении, например, рабочая станция должна соединяться с сервером, но сервер не должен соединяться с рабочей станцией.

Для фильтрации пакетов SYN нужно использовать опцию –у. Например, попытки соединения по протоколу TCP от узла 192.168.1.34 указываются так:

–р TCP –s 192.168.1.34 –у

Иногда передаваемый пакет слишком большой, чтобы его можно было бы передавать за один раз. Если такое происходит, то пакет делится на фрагменты, и эти фрагменты пересылаются. Компьютер, которому этот пакет предназначен, собирает эти фрагменты в один пакет.

Ядро должно анализировать начало пакета, которое содержится в первом фрагменте. Ведь только в первом фрагменте находится заголовок исходного пакета. Для решения этой проблемы вам нужно перекомпилировать ядро с включенной опцией IP: always defragment.

В результате любое правило фильтрации не будет работать для фрагментированных пакетов. При этом только первый фрагмент будет обработан как пакет, а остальные не будут обрабатываться. Однако можно определить правило специально для фрагментированных пакетов. Это можно сделать с помощью опции –f. Эту опцию нельзя применять при указании портов протоколов TCP или UDP, кода ICMP или пакетов SYN.

Следующая команда отбросит все фрагменты, приходящие на компьютер server.domain.com:

# ipchains –A output –f –d 192.168.1.1 –j DENY

Есть хорошая новость по этому поводу: ОС Linux невосприимчива к пингу смерти. Напомню, что пинг смерти заключается в посылке большого пакета ICMP, который переполняет буферы стека TCP на компьютере-получателе.

IP-спуфинг — это отправление пакетов с поддельным IP-адресом источника. Так как фильтрация пакета принимает решения на основании адреса источника, то IP-спуфинг используется, чтобы ввести пакетный фильтр в заблуждение.

Для решения этой проблемы мы можем использовать Проверку Адреса Источника (Source Address Verification) или использовать следующие команды IPChains:

ipchains –A prov –s 192.168.1.1/16 –l –j DENY

ipchains –A prov –s 127.0.0.1/8 –l –j DENY

Вторая команда нужна для ядер версий 2.0.x, но если мы ее укажем, явно хуже не будет. Опция –l позволяет протоколировать «плохие» пакеты. Файлом протокола является /var/log/messages. Ядра версий 2.1.x автоматически отклоняют пакеты, приходящие с адресов 127.*, которые зарезервированы для локального интерфейса.

Для включения проверки адреса источника можно воспользоваться сценарием, представленном в листинге 14.2.

# Наилучший способ: включить Source Address Verification и защитить

# от спуфинга все текущие и будущие интерфейсы.

if [ –e /proc/sys/net/ipv4/conf/all/rp_filter ] ; then

echo –n "Установка защиты от спуфинга… "

for f in /proc/sys/net/ipv4/conf/*/rp_fliter; do

echo 1 > $f

done

echo "готово."

else

echo ПРОБЛЕМЫ ПРИ ПОПЫТКЕ ВКЛЮЧИТЬ ЗАЩИТУ ОТ СПУФИНГА.

echo "Нажмите CONTROL-D для выхода в shell и продолжения сист. загрузки."

echo

# Запуск однопользовательской оболочки на консоли

/sbin/sulogin $CONSOLE

fi

Защита с использованием проверки адреса источника является более надежной.

Иногда возникает такая ситуация, когда на машину приходят не все фрагменты. Такое бывает при очень большом количестве фрагментов. Обычно при использовании ОС Linux данная проблема вообще отпадает, но все-таки некоторые администраторы предпочитают «перестраховаться».

Для решения этой проблемы вам нужно всего лишь перекомпилировать ядро с включенной опцией IP: always defragment. При этом нужно учитывать, чтобы ваш шлюз был единственным маршрутом для пакетов. Вторым способом является фильтрация фрагментов, но это может отразиться на нормальных пакетах. Честно говоря, я не особо забочусь об этой проблеме при настройке своего сервера.

А теперь рассмотрим более серьезный пример. Этот пример частично позаимствован мною из руководства DNS-HOWTO. Но прежде чем перейти непосредственно к практике, попробую объяснить некоторые термины, которые будут встречаться ниже.

Прежде всего, определимся, что называется маскарадингом. Объяснение я приведу на сугубо формальном языке. Маскарадинг перезаписывает заголовки пакетов, когда они проходят через шлюз так, чтобы казалось, что они всегда исходят от шлюза непосредственно. Затем он перезаписывает ответы так, чтобы клиенту казалось, что они пришли от первоначального получателя. Например, у вас есть шлюз и одна небольшая локальная сеть. Шлюз обладает реальным IP-адресом 1.1.1.1, а адрес вашей локальной сети — 192.168.1.0. Клиент с IP-адресом 192.168.1.5 пытается обратиться к узлу http://www.romb.net. IP-адрес этого узла 62.244.59.193. Пакет клиента проходит через шлюз. IP-адрес шлюза в локальной сети — 192.168.1.1. Шлюз перезаписывает заголовок пакета и устанавливает вместо адреса клиента свой собственный адрес, то есть 1.1.1.1. После получения ответа, он перед отправлением пакета клиенту опять перезаписывает заголовок пакета и изменяет свой адрес 1.1.1.1 на адрес узла www.romb.net — 62.244.59.193. С точки зрения узла www.romb.net соединение было установлено между адресами 1.1.1.1 и 62.244.59.193. С точки зрения клиента соединение произошло между интерфейсами с адресами 192.168.1.5 и 62.244.59.193.