Как организовать избыточные соединения с двумя провайдерами Internet по разным каналам с помощью Linux.
C появлением высокоскоростных каналов, предоставляемых провайдерами Internet (Internet Service Provider, ISP), пользователям стало намного проще размещать различные службы на своих домашних компьютерах. Но что если связь прервется? Очевидное решение в такой ситуации — использовать резервное соединение с Internet от другого провайдера. В данной статье рассказывается о наиболее важных моментах, которые следует учитывать при настройке хоста Linux с избыточными соединениями Internet:
- о конфигурации хоста таким образом, чтобы он корректно поддерживал входящие сетевые соединения от нескольких провайдеров Internet;
- о балансировке трафика между исходящими сетевыми соединениями;
- o конфигурации различных служб для поддержания избыточности;
- о настройке защиты межсетевого экрана с помощью сценариев ipchains или iptables.
|
| Рисунок 1. Хост Linux с избыточными соединениями с Internet. |
На Рисунке 1 приведена конфигурация домашней компьютерной сети, на которую мы будем ссылаться по мере повествования. Хост Linux действует как межсетевой экран между Internet и внутренней локальной сетью. Интерфейс Ethernet eth1 использует DSL, а интерфейс Ethernet eth2 — кабельный модем. Хост Linux выполняет балансировку нагрузки между исходящими сетевыми соединениями с двумя провайдерами Internet. Такой подход не ограничивается только высокоскоростными сетевыми каналами — подобные методы могут применяться и для распределения нагрузки между двумя коммутируемыми соединениями.
Хост в тестовой конфигурации представлял собой компьютер с двумя процессорами Intel Celeron с тактовой частотой 533 МГц, на котором работала операционная система Red Hat 6.2 с ядром Linux 2.2.18. Испытания проводились также с версией Red Hat 7.1 и ядром Linux 2.4.13. Представленная конфигурация не требует наличия ни двухпроцессорной системы, ни процессоров с тактовой частотой 533 МГц. В качестве межсетевого экрана можно приспособить старую систему с процессором Pentium/100 МГц и оперативной памятью емкостью 32 Мбайт. Некоторые примеры, приведенные в статье, рассчитаны на Red Hat, но их можно легко изменить таким образом, чтобы они будут приложимы к другим распространенным вариантам Linux.
Объем публикации не позволяет детально, шаг за шагом, описать процесс конфигурации плат Ethernet, компиляцию ядер Linux и конфигурирование DNS. Эту информацию можно найти в Internet или в многочисленных публикациях по данной тематике. Начать лучше всего с посещения сайта http://www.linuxdoc.org/.
КОНФИГУРИРОВАНИЕ ЯДРА
Ядро Linux 2.2 и более поздних версий поддерживает усовершенствованные методы маршрутизации, которые необходимы для выполнения балансировки нагрузки и предоставления нескольких маршрутов по умолчанию на хосте Linux. Для поддержки нескольких соединений с Internet при компиляции ядра следует задать следующие сетевые опции:
CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y
Чтобы воспользоваться развитыми возможностями нового ядра, надо установить набор средств iproute. (Сейчас он распространяется вместе с версией Red Hat 7.1.) Инструментарий iproute можно найти по адресу: ftp://ftp.inr.ac.ru/ip-routing/.
Он поддерживает две специальные команды для доступа к развитым функциям маршрутизации: ip и tc. Документация с описанием команды ip находится по адресу: http:// snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html.
МАРШРУТИЗАЦИЯ IP ПО ИСТОЧНИКУ
По умолчанию, маршрутизация пакетов TCP/IP выполняется путем анализа IP-адресов назначения и поиска маршрута к указанной сети в таблице маршрутизации, просмотреть которую можно с помощью команды netstat -r. Если маршрут найден, пакет передается на этот сетевой интерфейс, в противном случае пересылается на шлюз, заданный по умолчанию. Для большинства систем, напрямую подключенных к Internet, по умолчанию в качестве шлюза выступает провайдер Internet. В нашем случае это означает, что все исходящие соединения Internet выходят из интерфейса DSL — не очень желательное явление в среде с избыточными соединениями. При добавлении в систему кабельного модема совсем не хочется, чтобы его соединения при ответе переходили на DSL.
Для решения этой проблемы с помощью команды ip создается несколько таблиц маршрутизации, а конкретная таблица выбирается в зависимости от IP-адреса отправителя исходящего пакета. Конфигурирование осуществляется посредством следующих команд.
#Задание правил маршрутизации IP по источнику для DSL ip rule add from 63.89.102.157 lookup 1 ip route add 10.0.0.0/24 via 10.0.0.1 table 1 ip route add 0/0 via 63.89.102.1 table 1 #Задание правил маршрутизации IP по источнику #для кабельного модема ip rule add from 65.3.17.133 lookup 2 ip route add 10.0.0.0/24 via 10.0.0.1 table 2 ip route add 0/0 via 65.3.17.1 table 2
Если исходящий пакет передается с адреса источника 63.89.102.157 (DSL), то поиск маршрута выполняется в Таблице маршрутизации 1, где имеются две записи:
>Список ip route в Таблице 1 10.0.0.0/24 via 10.0.0.1 dev eth0 default via 63.89.102.1 dev eth1
С помощью первой строки локальный трафик маршрутизируется во внутреннюю сеть, а благодаря второй все оставшиеся пакеты пересылаются провайдеру Internet через интерфейс DSL. Таблица маршрутизации 2 для интерфейса кабельного модема используется таким же образом.
БАЛАНСИРОВКА НАГРУЗКИ
Балансировка нагрузки между исходящими из внутренней сети соединениями осуществляется с помощью опции ядра CONFIG_IP_ROUTE_MULTIPATH, которая позволяет определить несколько шлюзов по умолчанию. Для этого необходимо удалить шлюз по умолчанию из файла /etc/sysconfig/network и задать шлюз по умолчанию с помощью расширенных функций маршрутизации посредством следующей команды:
# Добавление ip route по умолчанию с опцией equalize nexthop via 63.89.102.1 dev eth1 nexthop via 65.3.17.1 dev eth2
Следующая команда позволяет просмотреть усовершенствованную таблицу маршрутизации:
>Список ip route 255.255.255.255 dev eth0 scope link 255.255.255.255 dev eth2 scope link 255.255.255.255 dev eth1 scope link 10.0.0.1 dev eth0 scope link 63.89.102.157 dev eth1 scope link 65.3.17.133 dev eth2 scope link 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1 63.89.102.0/24 dev eth1 proto kernel scope link src 63.89.102.157 65.3.17.0/24 dev eth2 proto kernel scope link src 65.3.17.133 127.0.0.0/8 dev lo scope link default equalize nexthop via 63.89.102.1 dev eth1 weight 1 nexthop via 65.3.17.1 dev eth2 weight 1
Опция ядра CONFIG_IP_ROUTE_MULTIPATH заставляет Linux, как сказано в документации /usr/src/linux/Documentation/ Configure.help, «рассматривать все эти пути (маршруты, заданные по умолчанию) как имеющие равную «стоимость» и выбирать один из них произвольным образом». Опция equalize в команде ip route указывает ядру Linux на необходимость балансировки нагрузки между исходящими соединениями на основе IP-адреса. Для конкретного IP-адреса ядро выбирает интерфейс, куда будут передаваться исходящие пакеты; затем ядро сохраняет это решение как запись в кэше маршрутизации для данного IP-адреса. Последующие соединения с указанным IP-адресом будут осуществляться через тот же самый интерфейс до тех пор, пока не истечет срок действия записи в кэше маршрутизации, просмотреть который можно с помощью команды ip route list cache.
КОНФИГУРАЦИЯ СЕРвисОВ
Различные службы (DNS, SMTP, HTTP, LDAP, SSH и т. д.) можно сделать избыточными путем реализации циклической DNS. Избыточность DNS достигается за счет указания двух записей NS, по одной для каждого внешнего интерфейса. При желании, срок действия (Time To Live, TTL) каждой записи DNS сокращается таким образом, чтобы удаленные системы могли кэшировать информацию IP только в течение 30 мин. В результате входящий трафик будет распределяться между двумя IP-адресами циклически. Для входящих соединений SMTP две записи MX с равным весом (10) были добавлены к DNS так, чтобы при выходе из строя одного из интерфейсов входящая электронная почта доставлялась на другой интерфейс.
Проверить конфигурацию DNS можно с помощью команды dig (модификация команды nslookup):
>dig alphapager.org ; <<>>DiG 8.2 <<>>alphapager.org any ;; res options:init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<-opcode:QUERY,status:NOERROR,id:4 ;; flags:qr rd ra;QUERY:1,ANSWER:9,AUTHORITY:0 ,ADDITIONAL:5 ;; QUERY SECTION: ;; alphapager.org,type =ANY,class =IN ;; ANSWER SECTION: alphapager.org.30M IN A 63.89.102.157 alphapager.org.30M IN A 65.3.17.133 alphapager.org.30M IN NS ns.alphapager.org. alphapager.org.30M IN NS ns.herdejurgen.com. alphapager.org.30M IN SOA proxy.alphapager .org. root.proxy.alphapager.org.( 2001031000 ;serial 3H ;refresh 1H ;retry 1W ;expiry 30M );minimum alphapager.org.30M IN MX 10 ns.herdejurgen .com. alphapager.org.30M IN MX 10 ns.alphapager .org. ;; ADDITIONAL SECTION: ns.alphapager.org.30M IN A 63.89.102.157 ns.herdejurgen.com.30M IN A 65.3.17.133 ;; Total query time:98 msec ;; FROM:pandora to SERVER:default -192.168 .100.1 ;; WHEN:Sat Mar 10 22:15:22 2001 ;; MSG SIZE sent:32 rcvd:326
Все записи DNS (за исключением ns.alphapager.org и ns.herdejurgen.com) теперь разрешаются по двум IP-адресам. Например,
>nslookup seann.herdejurgen.com Server: proxy-in.alphapager.org Address: 10.0.0.1 Name: seann.herdejurgen.com Addresses: 65.3.17.133,63.89.102.157
Следующие записи в httpd.conf:
NameVirtualHost 63.89.102.157:80 NameVirtualHost 65.3.17.133:80
позволяют организовать несколько именованных виртуальных хостов для Apache.
Входящий трафик LDAP и SSH распределяется с помощью циклической DNS и не требует специальной конфигурации.
СЦЕНАРИИ НАЧАЛЬНОЙ ЗАГРУЗКИ
Для поддержки нашей сетевой конфигурации необходимо изменить несколько сценариев начальной загрузки. Они созданы для Red Hat, но легко модифицируются для любого другого варианта Linux. Команды ip rule нужно выполнять только после загрузки системы. Для этого в раздел начальной загрузки сценария /etc/rc.d/init.d/network следует добавить следующие строки:
# Добавление команд static-rules, #не связанных с конкретным интерфейсом if [ -f /etc/sysconfig/static-rules ];then sh /etc/sysconfig/static-rules fi
Файл /etc/sysconfig/static-rules содержит:
#Задание правил маршрутизации по IP-адресу источника ip rule add from 63.89.102.157 lookup 1 ip rule add from 65.3.17.133 lookup 2 #Настройка балансировки нагрузки ip route add default equalize nexthop via 63.89.102.1 dev eth1 nexthop via 65.3.17.1 dev eth2
Команды ip route должны выполняться каждый раз, когда инициируется ifup для соответствующего интерфейса. Добавьте следующие строки в /etc/sysconfig/ network-scripts/ifup-routes:
# Добавление любых нетривиальных маршрутов grep "^advanced " /etc/sysconfig/static -routes | while read ignore dev args;do if [ ""$dev"="$1"];then /sbin/ip route add $args fi done
Файл /etc/sysconfig/static-routes содержит:
advanced eth0 10.0.0.0/24 via 10.0.0.1 table 1 advanced eth0 10.0.0.0/24 via 10.0.0.1 table 2 advanced eth1 0/0 via 63.89.102.1 table 1 advanced eth2 0/0 via 65.3.17.1 table 2
МЕЖСЕТЕВЫЕ ЭКРАНЫ
Если ваш хост подключен к Internet, то для блокировки нежелательного трафика понадобится установить межсетевой экран. Выбрав, каким службам будет разрешен доступ к хосту через Internet, использование соединений всеми остальными службами следует запретить. Помните, что установка межсетевого экрана не означает, что ваша система защищена. Любая служба, которой разрешен доступ через межсетевой экран, имеет собственные изъяны в защите, чем не преминут воспользоваться хакеры, поэтому очень важно следить за тем, чтобы в приложениях были установлены все новейшие заплаты.
Большинство сценариев межсетевого экрана рассчитано только на одно внешнее сетевое соединение. Поддержку множества внешних сетевых интерфейсов можно реализовать с помощью нескольких специально разработанных сценариев. Первый использует поставляемый вместе с ядрами Linux 2.2 межсетевой экран под названием ipchains. Второй — поставляемый вместе с ядрами Linux 2.4 межсетевой экран под названием iptables. (Ядро Linux 2.4 позволяет установить межсетевой экран ipchains, но одновременная работа ipchains и iptables невозможна.)
По существу, iptables — это преемник ipchains, только более мощный, поскольку поддерживает контроль соединений, благодаря чему Linux получает межсетевой экран с контекстной проверкой. Кроме того, iptables является расширяемым, т. е. к нему можно добавлять новые функции (например, поиск соответствия строк), не изменяя при этом базовый исходный текст для iptables. Новые функции iptables описаны во врезке «Новые функции сценария межсетевого экрана iptables». И ipchains, и iptables разделяют трафик на несколько различных цепочек правил, которые определяют, нужно ли принять или отвергнуть пакет. В iptables для фильтрации пакетов применяются три таблицы цепочек, называемые filter, nat и mangle. При передаче пакета по цепочке последовательно проверяется каждое правило, пока не будет найдено соответствие.
Три стандартные цепочки в ipchains получили название INPUT, FORWARD и OUTPUT. Эти цепочки представлены в iptables в таблице фильтров: INPUT анализирует пакеты сразу же, как только они поступают на сетевой интерфейс; FORWARD исследует замаскированные пакеты; OUTPUT проверяет их до передачи на сетевой интерфейс. На Рисунке 2 представлен путь, который пакеты проходят при разделении на различные цепочки на межсетевом экране ipchains.
|
| Рисунок 2. Разделение пакетов ipchains. |
У межсетевого экрана iptables в таблице nat имеются две дополнительные цепочки — PREROUTING и POSTROUTING. Они служат для выполнения маскировки пакетов, или, иначе, преобразования сетевых адресов. После поступления на сетевой интерфейс все пакеты проходят эти цепочки перед дальнейшей отправкой.
В iptables цепочки INPUT и OUTPUT обрабатывают пакеты, предназначенные для межсетевого экрана, а цепочка FORWARD обрабатывает только замаскированные пакеты. На Рисунке 3 представлен путь, по которому следуют пакеты, проходя по различным цепочкам в межсетевом экране iptables.
|
| Рисунок 3. Разделение пакетов iptables. |
Таблица mangle в iptables использует цепочки PREROUTING и OUTPUT для того, чтобы можно было изменять в пакетах такие флаги IP, как TTL (срок действия) и TOS (тип обслуживания).
Более подробное описание способа передачи пакетов по различным цепочкам в ipchains и iptables можно найти по адресам: http://www.linuxdoc.org/ HOWTO/IPCHAINS-HOWTO-4.html и http://www.linuxdoc.org/LDP/nag2/x-087-2-firewall.future.html.
КОНФИГУРАЦИЯ ЯДРА МЕЖСЕТЕВОГО ЭКРАНА
Чтобы создать межсетевой экран ipchains в ядре Linux 2.2, необходимо указать ниже перечисленные опции в файле конфигурации ядра:
CONFIG_IP_FIREWALL=y CONFIG_IP_MASQUERADE=y CONFIG_IP_MASQUERADE_ICMP=y CONFIG_IP_ROUTE_TOS=y CONFIG_SYN_COOKIES=y
Межсетевой экран iptables в ядре Linux 2.2 создается с помощью следующих опций в файле конфигурации ядра:
CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_PSD=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_IPLIMIT=m CONFIG_IP_NF_MATCH_STRING=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_ROUTE_TOS=y CONFIG_SYN_COOKIES=y
На момент написания данной статьи некоторых из указанных функций ядра в основном ядре Linux 2.4 не было, но их можно добавить в качестве заплат. Для этого необходимо установить ядро Linux 2.4.13 и iptables 1.2.4, которые можно найти по адресу: http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.13.tar.gz и http://netfilter.filewatcher.org/iptables-1.2.4.tar.bz2.
Добавить к своему ядру экспериментальные заплаты iptables можно, выполнив указанные инструкции.
- Установите ядро Linux 2.4.13 в /usr/src/linux и запустите его.
- Перенесите iptables-1.2.4.tar.bz2 в свой собственный каталог.
- Примените заплаты к iptables-1.2.4#.
Ответьте yes («да») на вопрос об установке следующих заплат:
string psd (выявление сканирования портов) iplimit
Поскольку не все заплаты совместимы, выбирайте только те из них, которые намереваетесь использовать.
- iptables-1.2.4#make install.
- /usr/src/linux#make oldconfig.
Укажите в качестве ответа m для опций CONFIG_IP_NF_ MATCH, которые вы добавили к ядру.
- Перекомпилируйте ядро и перезагрузитесь.
Обратите внимание, что приведенные команды написаны именно для ядра Linux 2.4.13 и заплат iptables 1.2.4. Предполагается, что эти экспериментальные функции войдут в состав основного ядра уже в ближайшем будущем.
СЦЕНАРИИ МЕЖСЕТЕВОГО ЭКРАНА
Базовый поток сценариев межсетевого экрана предназначен для того, чтобы определить последовательность цепочек INPUT, FORWARD и OUTPUT. Сценарий межсетевого экрана iptables также конфигурирует цепочки PREROUTING и POSTROUTING. Каждый сценарий содержит комментарии, описывающие, какой трафик принимается, а какой — отклоняется. Одни пакеты не принимаются, а другие — игнорируются. REJECT отклоняет пакеты и отсылает ответы ICMP обратно отправителю с соответствующим уведомлением. DENY (ipchains) или DROP (iptables) просто игнорируют пакеты и не посылают никакого ответа. При подобном подходе при зондировании конкретного порта система как будто бы не существует. Описываемые сценарии межсетевого экрана предусматривают игнорирование пакетов в цепочках INPUT и FORWARD, т. е. удаленным системам никаких ответов не посылается. Сценарии будут отклонять пакеты в цепочке OUTPUT таким образом, что локальная система получит уведомления в случае некорректных исходящих пакетов.
Чтобы установить сценарий межсетевого экрана в своей системе Red Hat 7.1, его следует поместить в /etc/init.d/firewall и выполнить команду:
#chkconfig firewall on
Для конфигурации сценария межсетевого экрана в своей системе нужно отредактировать следующие две строки, чтобы определить имеющиеся внутренний и внешний интерфейсы:
INT_IFACE=?eth0? EXT_IFACES=?eth1 eth2?
Цепочка INPUT открывает проход через межсетевой экран для служб, которым это позволено, и игнорирует остальные. Далее следует отредактировать список служб для конкретной системы. Входящие соединения разрешаются посредством записей в сценарии межсетевого экрана ipchains:
#РАЗРЕШИТЬ соединения TCP для различных #служб, указанных в /etc/services for service in ftp ssh smtp domain http auth ldap https;do ipchains -A INPUT -i $EXT_IFACE -p tcp -d $IP $service -j ACCEPT done
Сценарий межсетевого экрана циклически просматривает различные службы, доступные на хосте. В данном случае — это ftp, SSH, sendmail, DNS (зонные пересылки), HTTP, ident, LDAP и HTTPS. Имена и номера портов для этих протоколов на базе TCP можно найти в файле /etc/services.
Цепочка INPUT также допускает любые ответы (возвраты), инициированные локально для соединений в соответствии со следующими правилами в сценарии межсетевого экрана ipchains.
#РАЗРЕШИТЬ пакеты TCP без опции SYN #на непривилегированных портах (возвраты) ipchains -A INPUT -i $EXT_IFACE -p tcp !-y -d $IP 1024:-j ACCEPT #РАЗРЕШИТЬ все пакеты UDP на непривилегированных портах ipchains -A INPUT -i $EXT_IFACE -p udp -d $IP 1024: -j ACCEPT
Это единственный способ разрешить обратный трафик TCP, поскольку ipchains не является межсетевым экраном с контекстной проверкой. iptables значительно улучшает защиту за счет поддержки работы межсетевого экрана с такой функциональностью. Он называется также «контроль соединения», т. е. пакет принимается только при соответствии активному соединению, инициатор которого находится во внутренней сети. Эта обработка оформляется в сценарии межсетевого экрана iptables соответствующим образом:
#РАЗРЕШИТЬ возврат трафика TCP/UDP #(межсетевой экран с контекстной проверкой) iptables -t filter -A INPUT -m state --state ESTABLISHED -i $EXT_IFACE -p tcp -d $IP --dport 1024:-j ACCEPT iptables -t filter -A INPUT -m state --state ESTABLISHED -i $EXT_IFACE -p udp -d $IP --dport 1024:-j ACCEPT
UDP — это протокол, не сохраняющий состояние, но контроль соединений iptables поддерживает таблицу состояний и допускает через порты UDP ответы для трафика, инициатор которого находится во внутренней сети.
Сценарий межсетевого экрана iptables принимает входящие соединения и размещает информацию о новых в базе данных контроля соединений в соответствии со следующими правилами:
#РАЗРЕШИТЬ входящие соединения TCP для различных #служб, перечисленных в /etc/services for service in ftp ssh smtp domain http auth ldap https;do iptables -t filter INPUT -m state --state NEW,ESTABLISHED -i $EXT_IFACE -p tcp -d $IP --dport $service -j ACCEPT done
Базу данных контроля соединений можно посмотреть, открыв файл /proc/net/ip_conntrack.
Приводимое ниже правило для iptables разрешает входящие активные соединения ftp на межсетевом экране с порта TCP 20 только для уже открытого сеанса ftp.
#РАЗРЕШИТЬ активные соединения ftp #для передачи данных на межсетевом экране iptables -t filter -A INPUT -m state --state RELATED -i $EXT_IFACE -p tcp -d $IP --dport 1024: --sport ftp-data -j ACCEPT
Следующее правило разрешает входящие запросы DNS к BIND:
#РАЗРЕШИТЬ входящие запросы DNS iptables -t filter -A INPUT -i $EXT_IFACE -p udp -d $IP --dport domain -j ACCEPT
Перечисленные ниже правила разрешают входящий трафик NTP из военно-морской обсерватории Соединенных Штатов:
#РАЗРЕШИТЬ входящие обновления NTP
с серверов времени
#tick.usno.navy.mil и tock.usno.navy.mil
for timehost in 192.5.41.40 192.5.41.41;do
iptables -t filter -A INPUT
-i $EXT_IFACE -p udp
-d $IP --dport ntp -s $timehost
--sport ntp
-j ACCEPT
doneЦепочка FORWARD просто маскирует соединения для систем во внутренней сети, используя преобразование сетевых адресов (Network Addresss Translation, NAT). Большинство протоколов работает с NAT, но некоторым необходима небольшая помощь со стороны специального модуля, который переписывает IP-адреса. Активным соединениям ftp требуется программа-помощник для преодоления межсетевого экрана; их можно замаскировать, загружая модули ip_masq_ftp (ipchains) или ip_nat_ftp (iptables) с командой modprobe (если они уже не скомпилированы в ядре). Удаленная машина на другой стороне активного соединения ftp пытается подключиться обратно к локальной машине через межсетевой экран для передачи данных. Модуль ip_masq_ftp перезаписывает пакеты соединения ftp так, что внутренняя машина кажется подключенной напрямую к Internet. В пассивном режиме ftp эта проблема решается за счет передачи всех данных через порт TCP 21. Если вы решите поддерживать ftp, помните, что он передает пароли по сети в виде обычного текста и не считается защищенным. Защищенная альтернатива ftp — это sftp; метод организации соединений он использует в качестве защищенного сокета. Сейчас sftp предлагается вместе с клиентскими инструментальными средствами OpenSSH.
Другие маскирующие модули для различных приложений можно найти в каталогах /lib/modules/?uname -r?/ipv4 (ipchains) или /lib/modules/?uname -r?/kernel/net/ipv4/netfilter/ (iptables).
Цепочка FORWARD использует следующие правила iptables при прохождении замаскированных пакетов через межсетевой экран:
#РАЗРЕШИТЬ новый исходящий трафик #(межсетевой экран с контекстной проверкой) iptables -t filter -A FORWARD -m state -state NEW,ESTABLISHED -i $INT_IFACE -s $INT_NET -j ACCEPT #РАЗРЕШИТЬ возвращаемый трафик #(межсетевой экран с контекстной проверкой) iptables -t filter -A FORWARD -m state -state NEW,ESTABLISHED,RELATED -i $EXT_IFACE -s !$INT_NET -j ACCEPT #Передача трафика Internet во внутреннюю сеть без изменений iptables -t nat -A POSTROUTING -o $INT_IFACE -j ACCEPT #Маскировка исходящих соединений из внутренней сети iptables -t nat -A POSTROUTING -o $EXT_IFACE -j MASQUERADE
Цепочка OUTPUT допускает только сетевой трафик (если он направляется через корректный интерфейс), а также выявляет приоритеты для определенного трафика, устанавливая флаги TOS. Так, с помощью флагов TOS можно указать, что интерактивный (SSH) трафик имеет приоритет перед трафиком ftp. К флагам TOS относятся минимизация задержки (Minimize-Delay), максимизация пропускной способности (Maximize-Throughput), максимизация надежности (Maximize-Reliability) и минимизация затрат (Minimize-Cost).
Многие провайдеры Internet игнорируют флаги TOS в пакетах, но их полезность очевидна, поскольку именно благодаря им опция ядра CONFIG_IP_ROUTE_TOS определяет приоритеты исходящего трафика. Это значит, что приложения с высокими требованиями к пропускной способности (например, крупный сервер ftp) могут выполняться с флагом «максимальная пропускная способность», а интерактивные приложения (такие, как SSH) — «с минимальной задержкой». Таким образом, ftp не будет негативно влиять на производительность вашего соединения SSH.
Флаги TOS устанавливаются в сценарии межсетевого экрана iptables в цепочках PREROUTING и OUTPUT таблицы mangle. Цепочка PREROUTING определяет приоритеты входящих, а OUTPUT — исходящих пакетов. Для минимизации задержки пакетов SSH используются следующие правила:
iptables -t mangle -A PREROUTING -j TOS --set-tos Minimize-Delay -p tcp --dport ssh iptables -t mangle -A OUTPUT -j TOS --set-tos Minimize-Delay -p tcp --sport ssh
Цепочка OUTPUT также ограничивает типы сообщений ICMP, на которые система будет отвечать. Сообщения ICMP допускаются для ping и traceroute, а сообщения timestamp (используемые в операционных системах с идентификацией) игнорируются. Ответы ICMP конфигурируются с помощью специальных строк в сценарии межсетевого экрана ipchains:
#РАЗРЕШИТЬ различные сообщения ICMP
for message in echo-reply destination
-unreachable
source-quench redirect echo-request
time-exceeded parameter-problem;do
ipchains -A OUTPUT -p icmp -s 0/0
$message -j ACCEPT
doneНесколько последних команд в сценариях межсетевого экрана обеспечивают продвижение IP (маскировку/NAT), разрешают выполнение TCP SYN cookies (они помогают снизить эффект атак со сканированием TCP SYN, относящихся к классу атак по типу «отказ в обслуживании»), игнорируют различные сообщения ICMP, направляют маршрутизацию по обратному пути (запутывающие действия) и регистрируют «заблудившиеся» пакеты с недопустимыми адресами.
ПОДДЕРЖКА МЕЖСЕТЕВОГО ЭКРАНА
Чтобы проверить эффективность правил межсетевого экрана, сценарий межсетевого экрана следует выполнить, применив следующую команду:
# ./firewall status
Проанализируйте данные в первых двух столбцах полученного результата. Нули свидетельствуют о том, что ни один пакет не соответствует данному правилу. Это не всегда плохо — нули в поле правил DENY или DROP свидетельствуют, что никто не пытался проникнуть на ваш хост с помощью указанного правила. Нули в поле правила ACCEPT означают, что соответствующий трафик не был принят, однако трафик может соответствовать к правилу, находящемуся раньше в цепочке.
Если необходимо отладить собственные правила межсетевого экрана, убедитесь, что все правила REJECT и DENY регистрируются в файле /var/log/messages, для чего в команду ipchains следует включить опцию -l. Сценарий межсетевого экрана iptables создает специальную цепочку DROPLOG, которая регистрирует отвергнутые пакеты. Регистрационные журналы следует регулярно проверять на предмет обнаружения нарушителей. Полезный инструментарий для мониторинга журналов регистрации межсетевого экрана называется fwlogwatch, его можно найти по адресу: http://cert.uni-stuttgart.de/projects/fwlogwatch/.
Эти сценарии межсетевого экрана разрешают обратный трафик только через непривилегированные порты, поэтому, чтобы разрешить обслуживание непривилегированных портов, конфигурацию SSH придется обновить, отредактировав файл ssh_config и добавив строку:
UsePrivilegedPort no
ВЫВОДЫ
Я использовал эту конфигурацию почти целый год и остался доволен ее производительностью. Однако исходящие соединения ставят несколько вопросов в тех случаях, когда канал перестает функционировать. Если один канал станет недоступен, то на этот случай избыточность для исходящих соединений обеспечивается с помощью второго канала на уровне приложений. Исходящие соединения, инициируемые локально, будут поддерживаться в единичных случаях до тех пор, пока не будет выполнена команда ifdown для интерфейса с провайдером Internet, на котором возник сбой. Если перерыв в работе окажется достаточно долгим, вы можете обновить DNS. Проблема возникает, когда выполняется ifup для интерфейса, поскольку во вторичную таблицу необходимо добавить записи о маршрутизации (например, ip route add 0/0 via 63.89.102.1 table 1). Сценарий ifup-routes был изменен для того, чтобы эти нетривиальные маршруты добавлялись автоматически. Если команда ifdown запускается на обоих интерфейсах, необходимо снова добавить маршрут по умолчанию в основную таблицу маршрутизации (например, ip route add default equalize nexthop via...). Сценарии для выполнения различных алгоритмов восстановления после сбоя читателю предлагается написать самостоятельно в качестве упражнения.
Синн Хердеюрген — старший консультант компании Collective Technologies. С ним можно связаться по адресу: seann@herdejurgen.com.
Ресурсы Internet
Значительная часть информации, использованной в данной статье, была найдена в Internet с помощью системы поиска google.com.
Информационная страница по fwlogwatch находится на http://cert.uni-stuttgart.de/projects/fwlogwatch/.
Офир Аркин описал «Использование ICMP при сканировании» на http://www.sys-ecurity.com/archive/papers/ICMP_Scanning_v2.0.pdf.
Информационная страница по ipchains помещена на http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO-4.html.
Информационная страница по ipcref располагается на http://snafu.freedom.org/linux2.2/docs/ip-cref/ip-cref.html.
Информационная страница по iprouting находится на ftp://ftp.inr.ac.ru/ip-routing/.
Оскар Андреассон опубликовал «Руководство 1.1.3 по iptables»: http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html.
Информационная страница Linux Guruz iptables помещена на http://www.linuxguruz.org/iptables/.
«Руководство по Linux для сетевых администраторов», глава «Сетевые фильтры и таблицы IP (ядра Linux 2.4)», можно найти на http://www.linuxdoc.org/LDP/nag2/x-087-2-firewall.future.html.
Информационная страница по балансировке нагрузки имеет адрес: ftp://sliepen.warande.net/pub/eql/load-balancing.txt.
Дэниэл Киракоф представил «Краткое описание организации прозрачного посредника с помощью Linux и Squid» по адресу: http://www.linuxdoc.org/HOWTO/mini
/TransparentProxy.html.
Новые функции сценария межсетевого экрана iptables
Следует отметить, что iptables не только обеспечивает полноценную работу межсетевого экрана с контекстной проверкой, но и способен к расширению. Кроме того, iptables поддерживает более совершенные функции межсетевого экрана, чем ipchains. Некоторые из них требуют поддержки ядра, как описано выше в разделе «Конфигурация ядра межсетевого экрана».
iptables можно использовать для установки ограничений на новые входящие пакеты TCP, чтобы предотвратить атаки по типу «отказ в обслуживании». Это достигается с помощью следующих правил:
#Создание цепочки syn-flood для обнаружения #атак по типу "отказ в обслуживании" iptables -t nat -N syn-flood #Ограничение в 12 соединений в секунду #максимально допустимое - 24) iptables -t nat -A syn-flood -m limit --limit 12/s --limit-burst 24 -j RETURN iptables -t nat -A syn-flood -j DROPLOG #Проверка на атаку по типу "отказ в обслуживании" iptables -t nat -A PREROUTING -i $EXT_IFACE -d $IP -p tcp --syn -j syn-flood
Эти правила ограничивают количество новых входящих соединений TCP (пакеты с установленным битом SYN) до 12 соединений в секунду после того, как окажется достигнут предел в 24 соединения в секунду.
С помощью iptables устанавливается посредник Squid. Он будет прозрачным образом кэшировать и регистрировать все исходящие запросы HTTP в Internet. Для этого не нужно вносить изменения в браузер пользователя. Он полезен и для блокировки незатребованного информационного наполнения. Это достигается с помощью правила iptables на базе цепочки PREROUTING:
#Установка прозрачного посредника Squid для внутренней сети # #Более подробную информацию по настройке Squid, см. #http://www.unxsoft.com/TransparentProxy.html # iptables -t nat -A PREROUTING -i $INT_IFACE -p tcp --dport 80 -j REDIRECT --to-port 3128
Теперь можно установить соответствие любым флагам TCP, т. е. блокировать дерево XMAS (все флаги установлены) и пакеты NULL по следующим правилам:
#ОТКЛОНИТЬ пакеты TCP - XMAS и NULL iptables -t nat -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROPLOG iptables -t nat -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROPLOG
Благодаря экспериментальной заплате netfilter psd межсетевой экран iptables может выявлять и блокировать сканирование входящих портов с помощью другого правила:
#ОТКЛОНИТЬ сканирование входящих портов iptables -t nat -A PREROUTING -i $EXT_IFACE -d $IP -m psd -j DROPLOG
Экспериментальная заплата netfilter iplimit позволит межсетевому экрану iptables ограничить число соединений с конкретного IP-адреса посредством следующего правила:
#ОТКЛОНИТЬ пакеты с хостов, имеющих #более 16 активных соединений iptables -t nat -A PREROUTING -i $EXT_IFACE -p tcp --syn -d $IP -m iplimit --iplimit -above 16 -j DROPLOG
Одна из наиболее мощных заплат netfilter предназначена для определения соответствия пакетов на основе их информационного наполнения. Экспериментальная заплата соответствия строк позволяет отфильтровать пакеты, если они относятся к определенной строке. Она дает возможность выявлять вирусы CodeRed или Nimda до их проникновения на сервер Web. Это можно сделать с помощью нескольких правил.
#ОТКЛОНИТЬ пакеты HTTP, #связанные с вирусами CodeRed и Nimda iptables -t filter -A INPUT -i $EXT_IFACE -p tcp -d $IP --dport http -m string --string "/default.ida?" -j DROP iptables -t filter -A INPUT -i $EXT_IFACE -p tcp -d $IP --dport http -m string --string ".exe?/c+dir" --j DROP iptables -t filter -A INPUT -i $EXT_IFACE -p tcp -d $IP --dport http -m string --string ".exe?/c+tftp" -j DROP
Перенаправление портов теперь является встроенной функцией. Чтобы добиться этого, таблица nat использует функцию, получившую название «назначения NAT» в цепочке PREROUTING. Для перенаправления с порта запросов HTTP в систему во внутренней сети нужно выполнить следующее:
#Использовать DNAT, чтобы перенаправить с порта пакеты http iptables -t nat -A PREROUTING !-i $INT_IFACE -p tcp --destination-port 80 -j DNAT --to 10.0.0.3:80
Вы можете также перенаправлять с порта пакеты UDP. Если трафик перенаправляется на конкретный порт, то для разрешения входящих соединений соответствующее правило в цепочке INPUT указывать не нужно.
Если вы перенаправляете запросы HTTP с порта на внутренний хост, вирус CodeRed можно отфильтровать в цепочке FORWARD с помощью следующего правила:
iptables -t filter -A FORWARD -p tcp --dport http -m string --string ?/default.ida?? -j DROP
Новые функции iptables появляются регулярно. Один из таких экспериментальных модулей — ip_nat_h323. Он позволит перенаправлять с порта входящие соединения NetMeeting через межсетевой экран. В момент написания данной статьи это решение находилось на стадии разработки.