B системе IOS компании Cisco имеется множество достаточно редко используемых функций, но тем не менее они весьма полезны для укрепления защищенности сети. В случае возвратных списков управления доступом (Reflexive Access Control Lists, RACL) можно более тщательно исследовать сетевой трафик и даже изменять путь передачи данных, представляющих особую важность, с помощью маршрутизации на базе правил (Policy Based Routing, PBR). Механизмы перехвата TCP (TCP Intercept) и проверки обратного маршрута пакетов IP (Unicast Reverse Path Forwarding, URPF) позволяют на границе сети ликвидировать представляющий угрозу безопасности трафик, проверив каждую попытку установления входящего соединения и ее источник. В следующих разделах описываются некоторые из этих полезных, но пока еще мало известных функций обеспечения безопасности маршрутизаторов Cisco.
ВОЗВРАТНЫЕ СПИСКИ УПРАВЛЕНИЯ ДОСТУПОМ
Как правило, списки контроля доступа (Access Control Lists, ACL) конфигурируются статически на отбрасывание либо пропуск тех или иных сетевых пакетов. В таком случае управление безопасностью сети затрудняется, так как обратный трафик для соединений, инициированных изнутри сети, должен быть разрешен явным образом. При использовании возвратных списков контроля доступа маршрутизатор автоматически делает записи в динамическом ACL, после чего тот может применяться для авторизации обратного трафика. Поскольку подобные динамические записи в ACL автоматически создаются для конкретного соединения и определяют при этом протокол, адреса отправления и назначения, а также порты соединения, их применение повышает безопасность сети, разрешая лишь трафик, который непосредственно связан с соединением, инициированным изнутри сети. Без данной функциональности было бы нелегко обеспечивать защиту, поскольку обратный трафик пришлось бы разрешить для всех возможных исходящих соединений.
Возвратные списки контроля доступа повышают функциональность расширенных именованных списков контроля доступа за счет включения двух дополнительных ключевых слов: reflect и evaluate. Слово reflect употребляется для обновления динамического ACL с помощью зеркального образа пакета, соответствующего конкретной записи в ACL. Обратный трафик впоследствии сопоставляется с этим динамическим ACL с помощью ключевого слова evaluate. Следующий далее пример содержит исходящий и входящий именованные расширенные списки ACL IP, необходимые для осуществления обмена данными клиента DNS с сервером DNS без использования возвратных ACL:
ip access-list extended OUTBOUND permit udp any any eq domain ip access-list extended INBOUND permit udp any eq domain any
Хотя такой сценарий может показаться вполне удовлетворительным, он, однако, позволяет любому компьютеру, находящемуся вне сети и посылающему трафик UDP на порт 53, осуществлять обмен данными посредством UDP с любым компьютером в сети. Применив в нашем примере команды reflect и evaluate, мы получим конфигурацию с более высоким уровнем защищенности:
ip access-list extended OUTBOUND permit udp any any eq domain reflect REFLEXIVE ip access-list extended INBOUND evaluate REFLEXIVE
В приведенном примере изменяемый динамически возвратный ACL допускает обратный трафик DNS. К примеру, если клиент с IP-адресом 192.168.1.1 обменивается данными с сервером DNS с адресом 172.16.1.1, то возвратный ACL модифицируется, при этом во входящий ACL добавляется строка udp host 172.16.1.1 eq domain host 192.168.1.1 eq 1024.
Запись из возвратного ACL удаляется в двух случаях: во-первых, это окончание сеанса TCP посредством выставления битов FIN или RST и, во-вторых, отсутствие трафика в сеансе TCP или UDP. Величину времени ожидания можно установить либо с помощью команды конфигурирования на глобальном уровне ip reflexive-list timeout, либо посредством опции timeout для конкретного возвратного ACL во время создания. Приводимый ниже фрагмент предыдущего примера дополнен для иллюстрации использования опции timeout:
ip access-list extended OUTBOUND permit udp any any eq domain reflect REFLEXIVE timeout 120
После того как возвратный ACL сконфигурирован, его динамическое содержимое можно просмотреть с помощью привилегированной команды EXEC — show access-list. Она выведет на экран список пакетов, соответствующих каждой записи, а также время в секундах, по истечении которого запись, находящаяся в неактивном состоянии, будет удалена.
МАРШРУТИЗАЦИЯ НА ОСНОВЕ ПРАВИЛ
Одно из многих применений маршрутизации на основе правил (Policy Based Routing, PBR) — перенаправление потока конфиденциальных данных по альтернативному пути с более высоким уровнем безопасности. Предлагаемые возможности включают как передачу трафика telnet по туннелю, поддерживающему протокол безопасности IPSec, так и пересылку критических данных приложения через выделенные интерфейсы. Для обеспечения защиты данных или изменения следующего транзитного узла для пакета IP, конфигурирование PBR привязано к маршрутизатору. Выполнение некоторого действия на основе правил предполагает конфигурирование вручную каждого маршрутизатора на пути следования данных от пункта отправления до пункта назначения.
Конфигурирование PBR предусматривает настройку нескольких компонентов. Во-первых, необходимо задать списки доступа, чтобы определить, к какому именно трафику будут применяться правила маршрутизации. Стандартные и расширенные списки доступа IP можно создать с помощью команды глобального конфигурирования access-list. Стандартные списки проверяют лишь поле с исходным IP-адресом, и их не следует использовать вместо более гибких расширенных или именованных расширенных списков доступа IP. Последние предоставляют улучшенные средства редактирования, а также возможность добавлять комментарии непосредственно в текст. Команда глобального конфигурирования ip access-list extended создает именованные расширенные списки доступа IP.
Затем создаются карты маршрутов (route map) для сопоставления состояния пакета с изменениями параметров. В действительности происходит следующее: карта маршрута «берет» пакет, удовлетворяющий некоторому списку доступа, и применяет к нему оператор изменения (один или более). Например, для пакетов, которыми обмениваются два узла, транзитный участок передачи можно изменить так, что они будут пересылаться по более медленному, но зато более защищенному пути вне зависимости от параметров протокола маршрутизации или текущей конфигурации статических маршрутов. Поскольку к интерфейсу можно применить только одну карту маршрута, она может иметь несколько экземпляров, причем каждый из них поддерживает различные параметры для разных видов трафика. Экземпляры применяются к трафику в последовательности, определяемой порядковыми номерами, начиная с меньших и заканчивая бо/льшими. Экземпляр карты маршрута создается с помощью команды глобального конфигурирования route-map, имеющей следующий синтаксис:
route-map NAME ACTION SEQNUM
В случае PBR поле ACTION необходимо всегда устанавливать в значение permit, оно предписывает применять параметры карты маршрута ко всем пакетам, удовлетворяющим требованиям данной карты. Список доступа привязывается к экземпляру карты с помощью команды конфигурирования карты маршрута match address, что показано ниже:
route-map NAME ACTION SEQNUM match address ACL
Маршрутизация на основе правил позволяет легко изменить маршрут передачи пакетов. Команда ip next-hop, наиболее востребованная при обеспечении защиты данных, изменяет путь следования трафика. Ниже представлен набор команд для создания экземпляра карты маршрута для изменения следующего транзитного узла передачи пакета:
route-map NAME ACTION SEQNUM match address ACL set ip next-hop NEXTHOP
После того как список доступа и карты маршрутов созданы, они применяются к интерфейсу с помощью команды конфигурирования интерфейса ip policy route-map. При этом система будет анализировать весь входящий трафик, поступающий на интерфейс, и пропускать без изменения трафик, передающийся помимо него. Приводимая далее конфигурация определяет пересылку всего трафика telnet на узел 192.168.4.100 по более медленному двухточечному (point-to-point) последовательному каналу передачи данных вместо более быстрой линии frame realy:
interface Ethernet1 ip address 192.168.1.1 255.255.255.0 ip policy route-map ROUTE-MAP interface Serial2 description T1 to Frame Relay ip address 192.168.2.1 255.255.255.252 encapsulation frame-relay interface Serial3 description 56k to Site B,remote router 192.168.3.2 ip address 192.168.3.1 255.255.255.252 ! ip access-list extended ROUTE-MAP-ACL permit tcp any host 192.168.4.100 eq 23 ! route-map ROUTE-MAP permit 10 match address ROUTE-MAP-ACL set ip next-hop 192.168.3.2
Хотя для нашего примера необходимости в этом нет, мы можем видоизменить ACL и включить в него различные параметры для разных типов трафиков, используя несколько экземпляров одной и той же карты маршрута. В дополнение к изменению следующего транзитного участка передачи пакета IP в целях повышения защищенности данных, как описано в предыдущем примере, трафик Web направляется на устройство кэширования Web:
ip access-list extended ROUTE-MAP-ACL permit tcp any host 192.168.4.100 eq 23 ! ip access-list extended WEB-CACHE-ACL deny tcp 192.168.1.100 any eq 80 permit tcp any host any eq 80 ! route-map ROUTE-MAP permit 10 match address ROUTE-MAP-ACL set ip next-hop 192.168.3.2 ! route-map ROUTE-MAP permit 20 match address WEB-CACHE-ACL set ip next-hop 192.168.1.100
Несмотря на возможность использования множества записей в списках доступа и множества экземпляров карт маршрутов, к интерфейсу может быть применена только одна карта.
Для увеличения эффективности маршрутизации пакетов на основе правил необходимо применить команду конфигурирования интерфейса ip route-cache policy, обеспечивающую быструю коммутацию на тех интерфейсах, где задействован механизм PBR. Ускорение коммутации достигается благодаря использованию кэша маршрутов, что существенно повышает производительность маршрутизатора, так как пакеты обрабатываются без прерывания работы основного процессора. Проверить факт включения режима быстрого переключения для пакетов, маршрутизируемых посредством PBR, можно с помощью команды EXEC show ip interface. Если строка со списком флагов кэша маршрутов IP содержит ключевое слово Policy, значит, быстрая коммутация пакетов, маршрутизируемых на основе правил, включена для данного интерфейса.
ПЕРЕХВАТ TCP
Задействуя механизм перехвата TCP, маршрутизатор может уменьшить воздействие атак по типу SYN flood на серверы организации. Указанный механизм отслеживает соединения TCP, соответствующие списку доступа, и гораздо более активно, нежели большинство серверных операционных систем, закрывает по истечении времени тайм-аута наполовину открытые соединения.
Перехват TCP можно настроить для работы в одном из двух режимов. Работая в режиме по умолчанию, маршрутизатор устанавливает соединения с внешними клиентами от имени сервера. После того как сеанс связи с клиентом успешно открыт, маршрутизатор организует соединение с сервером, а затем связывает эти два сеанса между собой. Подобный способ соединения прозрачен как для клиента, так и для сервера, однако требует больших ресурсов маршрутизатора. Такой режим работы известен как «режим перехвата» (intercept mode).
Второй режим, так называемый «режим наблюдения» (watch mode), позволяет маршрутизатору осуществлять пассивное слежение за соединениями TCP с сервером. В обычной ситуации (когда соединение успешно установлено) он не предпринимает никаких действий. Однако, если соединение не перешло в состояние ESTABLISHED по истечении времени тайм-аута, маршрутизатор посылает серверу сброс TCP, чтобы закрыть такое соединение. Интервал времени, после которого срабатывает таймер, по умолчанию равен 30 с. Его можно изменить с помощью команды глобального конфигурирования ip tcp intercept watch-timeout. Режим перехвата TCP включается командой глобального конфигурирования ip tcp intercept mode.
Если в какой-либо момент сервер имеет 1100 незавершенных соединений или за последнюю минуту наблюдалось 1100 попыток установления соединений, механизм перехвата TCP, работающий в режиме по умолчанию, переходит в агрессивное состояние: каждая попытка установления нового соединения приводит к удалению одного наполовину открытого соединения. По умолчанию удаляется самое раннее незавершенное соединение. В качестве альтернативы маршрутизатор можно настроить на удаление соединений, выбираемых случайным образом, — это можно сделать с помощью команды глобального конфигурирования ip tcp intercept drop-mode. Если перехват TCP работает в режиме наблюдения, то при переходе в агрессивное состояние время тайм-аута для наполовину открытых соединений сокращается вдвое (по умолчанию до 15 с).
Условие перехода механизма перехвата TCP в агрессивное состояние, а также его продолжительность настраивается с помощью следующих четырех команд глобального конфигурирования:
ip tcp intercept max-incomplete high VALUE
Если количество незавершенных соединений достигает значения VALUE, то механизм перехвата переходит в агрессивное состояние. Значение VALUE по умолчанию равно 1100.
ip tcp intercept max-incomplete low VALUE
Эта команда глобального конфигурирования сообщает маршрутизатору, в какой момент ему следует из агрессивного состояния вернуться в обычный режим работы. Значение VALUE по умолчанию равно 900.
ip tcp intercept one-minute high VALUE
Если количество попыток установления соединений за последнюю минуту достигло значения VALUE, то механизм перехвата переходит в агрессивное состояние. Значение VALUE по умолчанию равно 1100.
ip tcp intercept one-minute low VALUE
Маршрутизатор продолжает работать в агрессивном режиме до тех пор, пока количество активных соединений не упадет до значения, меньшего VALUE, которое по умолчанию равно 900.
Когда превышены оба нижних порога, маршрутизатор также переходит в агрессивное состояние и начинает удаление наполовину открытых соединений. В этом состоянии он находится до тех пор, пока оба значения не станут меньше соответствующих нижних порогов.
Приводимый пример настройки использует установки по умолчанию и требует минимального конфигурирования:
! ip tcp intercept list 100 ! access-list 100 permit any 192.168.1.0 0.0.0.255 !
Следующий пример несколько длиннее, в нем явным образом задаются режим перехвата и режим удаления незавершенных соединений, а также пороги перехода в агрессивное состояние:
! ip tcp intercept list 100 ip tcp intercept mode watch ip tcp intercept drop-mode random ip tcp intercept one-minute high 2000 ip tcp intercept one-minute low 1600 ! access-list 100 permit any 192.168.1.0 0.0.0.255 eq www access-list 100 permit any 192.168.1.0 0.0.0.255 eq smtp !
Оценить параметры работы сконфигурированной системы перехвата TCP можно лишь с помощью двух команд show. Первая, show tcp intercept connections, отображает список активных завершенных и незавершенных соединений. Для каждого из них выдается его состояние, а также счетчики времени с момента создания и до момента удаления по истечении тайм-аута. Вторая команда, show tcp intercept statistics, выводит на экран общее количество завершенных и незавершенных соединений, а также количество соединений, установленных за минуту. Эта важная информация поможет на начальном этапе конфигурирования системы перехвата TCP.
ПРОВЕРКА ОБРАТНОГО МАРШРУТА IP-ПАКЕТОВ
Механизм проверки обратного маршрута IP-пакетов (Unicast Reverse Path Forwarding, Unicast RPF) позволяет устранить ложные пакеты IP на границе сети. Он проверяет каждый пакет, поступающий на вход интерфейса маршрутизатора, выясняя с помощью локальной таблицы маршрутизации, получен ли данный пакет через соответствующий интерфейс. В некоторых случаях такую защиту проще реализовать с помощью списков доступа, однако в отличие от них Unicast RPF не требует, чтобы пакеты, поступающие на вход интерфейса граничного маршрутизатора извне, были бы инициированы внутренними клиентами. К тому же работа со списками доступа требует редактирования вручную. Это утомительная процедура, и она чревата ошибками в быстроменяющихся условиях, а также при использовании между партнерами по бизнесу или большими удаленными сайтами протоколов динамической маршрутизации.
Использование Unicast RPF оправдано, когда, например, организации требуется поддерживать контакты с находящимися вне ее территории бизнес-партнерами или, возможно, удаленными неавторизованными пользователями. Применение этого механизма к интерфейсам маршрутизаторов, связывающих такие объекты, гарантирует, что они не станут источниками ложных сетевых пакетов и определенных видов атак по типу «отказ в обслуживании» (Denial of Service, DoS). Провайдеры Internet могут повысить защищенность своей сети и Internet вообще, реализовав Unicast RPF для сетевых соединений со своими потребителями.
Поскольку в случае многоканальных (multihomed) соединений Internet трафик имеет определенную асимметрию, то невозможно гарантировать, что он полностью будет проходить по одному и тому же пути при передаче в сеть и обратно. По этой причине Unicast RPF не подходит для пограничных маршрутизаторов или маршрутизаторов в тех организациях, где имеются многоканальные соединения с Internet. Использование Unicast RPF в подобных условиях может повлечь блокирование полезного трафика.
Механизм Unicast RPF появился, начиная с версии Cisco 12.0, и работает только на тех платформах, которые поддерживает Cisco Express Forwarding. Конфигурирование Unicast RPF не представляет сложности и активизируется одной командой ip verify unicast reverse-path в режиме конфигурирования интерфейса. Если для интерфейса определены также и списки контроля доступа, то они проверяются прежде, чем пакет будет передан на обработку механизму Unicast RPF.
ОГРАНИЧЕНИЕ ДОСТУПА К МАРШРУТИЗАТОРАМ ПО ПРОТОКОЛУ TELNET
Обычно лишь относительно небольшому числу рабочих станций может потребоваться установление соединения с маршрутизаторами сети по протоколу telnet. Команда конфигурирования линии access-class позволяет точно определить, какие рабочие станции будут иметь доступ к маршрутизаторам, а какие нет. Если для находящихся внутри организации маршрутизаторов такое конфигурирование не обязательно, то для подключенных к Internet маршрутизаторов оно необходимо. Команда access-class принимает в качестве аргумента список ACL для разрешения/запрещения входящих соединений telnet:
access-list 90 permit 1.1.1.0 0.0.0.255 ! line vty 0 4 access-class 90 in
В приведенном примере доступ по протоколу telnet к данному маршрутизатору будут иметь лишь устройства с исходными IP-адресами в диапазоне от 1.1.1.0 до 1.1.1.255.
ЗАЩИТА ОТ ШИРОКОВЕЩАТЕЛЬНЫХ АТАК
Встречающаяся в распространенных атаках по типу DoS направленная широковещательная передача позволяет удаленному компьютеру посылать широковещательные пакеты сразу всем компьютерам некоторой подсети. До версии 12.0 после того, как широковещательные сообщения достигали подсети назначения, маршрутизаторы Cisco по умолчанию преобразовывали их в широковещательные пакеты MAC и отправляли далее. Эту функциональность обеспечивает поддерживаемая всеми версиями системы IOS команда конфигурирования интерфейса ip directed-broadcast.
Команда глобального конфигурирования ip forward-protocol предоставляет более широкие возможности, определяя, какие именно широковещательные пакеты разрешается пересылать далее. Она поддерживает достаточно большой список протоколов, включая tftp, bootp и netbios-ns.
Команда ip directed-broadcast принимает в качестве необязательного аргумента список контроля доступа, используемый для фильтрации широковещательных пакетов. Это дает дополнительный уровень контроля, когда необходимо определить класс разрешенных для дальнейшей передачи пакетов. В нижеследующем примере разрешены только те широковещательные пакеты, которые были инициированы внутри сети и используют закрытое адресное пространство 192.168.0.0:
interface Ethernet0 ip directed-broadcast 100 ! access-list 100 permit ip 192.168.0.0 0.0.255.255 any
ЗАКЛЮЧЕНИЕ
Безопасность сети — ускользающая цель, которая многими считается вообще недостижимой. Рассмотренные нами средства, хотя и не исчерпывают всех существующих возможностей, при правильном применении могут значительно повысить сетевую защиту.
Тим Сэммет работает старшим сетевым инженером в компании Logicon FDC. Он занимается проектированием сетей и реализацией сетевых служб для федерального правительства. С ним можно связаться по адресу: tim.sammut@feddata.com.