Статья была опубликована в журнале IT-Спец за апрель 2008 г.
В прошлой части статьи мы начали настраивать безопасность маршрутизатора с ограничения доступа непосредственно к самому устройству, отключили лишние службы, настроили безопасность SNMP и включили журналирования. Остановились мы на аспекте безопасного межсетевого взаимодействия, которое, подчас, является не менее важным чем безопасность самого маршрутизатора.
1.Защита от подмены ip-адресов или антиспуфинг
Подмена ip-адресов - это настоящий бич интернета, основанного на потоколе ip версии 4. Проблема состоит в том, что чаще всего большинство маршрутизаторов настроены на перенаправление пакетов исходя только из данных в поле адреса назначения заголовка ip. Конечно, проблема заключается не в самом механизме маршрутизации, а в том, что в большинстве сетей абсолютно любой корректно сформированный пакет будет совершенно свободно перенаправлен, если маршрутизатор будет иметь маршрут к адресу назначения, даже если в поле адреса источника заголовка ip будет указан нелегитимный адрес. Подобный нелегитимный (фейк) адрес в условиях нормально функционирования сети обычно не может быть указан в качестве источника пакета и чаще всего причиной его появления может стать лишь то, что кто-то, а точнее что-то не желает показать, откуда в действительности пришел пакет. Проще говоря, причиной появления в сети подобных пакетов чаще всего является вредоносное программное обеспечение, будь то черви, вирусы, спам- или DDoS-боты. Конечно, скрыть их деятельность очень сложно и любой мало-мальски опытный сетевой администратор при желании достаточно быстро обнаружит их сетевую активность. Возьмем, к примеру, процесс рассылки спама. Пусть в данном примере схема сети в точности соответствует рисунку. Чаще всего такой нехорошей затеей, т.е. спамом, будут заниматься управляемые боты, особый класс вредоносного программного обеспечения типа троянов-бекдоров, централизованно управляемых с мастер-сервера. Спам-бот, получив команду от хозяина через мастер-сервер в большом количестве рассылает корреспонденцию, открывая множество tcp-соединений на 25-е порты (SMTP) различных серверов. При этом в кеше маршрутизатора сетевой администратор наблюдает записи подобные этим:
#show ip cash flow
E0/0 86.35.180.4 E0/1 72.80.182.193 06 0C17 0019 7
E0/0 92.83.36.64 E0/1 78.37.213.158 06 E774 0019 2
E0/0 85.140.144.55 E0/1 78.37.213.158 06 CB6A 0019 7
E0/0 88.231.190.7 E0/1 69.13.131.2 06 C211 0019 2
E0/0 83.143.38.195 E0/1 67.18.144.162 06 0C37 0019 2
E0/0 62.66.167.235 E0/1 44.98.128.241 06 714F 0019 6
здесь 0019 - 25-й порт в шестнадцатеричном представлении. Администратор видит, что с интерфейса E0/1, который является в нашем примере внутренним, в большом количестве поступают пакеты, направленные к адресам в интернете, а порт назначения принадлежит протоколу SMTP. Однако, адрес источника никак не мог оказаться таким, ведь внутрення подсеть 121.132.143.0/24! Что же случилось? Мы столкнулись с простейшим примером подмены адреса источника или, проще говоря, спуфинга. Что же делать? Вариантов защиты несколько. Первый из них - ограничить исходящие пакеты на основе ip-адреса источника, исходя из принадлежности адресов к нашей сети:
#conf t
(config)#ip access-list standart 20
(config-std-nacl)#permit 121.132.143.0 0.0.0.255
(config-std-nacl)#deny any
(config-std-nacl)#exit
(config)#interface E0/1
(config-if)#ip access-group 20 in
Таким образом мы ограничим исходящий трафик из нашей сети с адресов, которые фактически нам не принадлежат. Такая концепция как минимум облегчит жизнь таким же как мы сетевым администраторам в деле борьбы с подменой ip-адресов. Теперь перейдем к внешнему интерфейсу. Согласно нашему примеру это интерфейс E0/0. Ограничим входящий трафик с адресов, которые фактически не могут быть источниками для пакетов, приходящих из интернета. Естественно, из внешней сети к нам не могут прийти пакеты, источник которых - наша внутренняя сеть, ограничим их:
#conf t
(config)#ip access-list standart 30
(config-std-nacl)#deny ip 121.132.143.0 0.0.0.255
Затем ограничим адреса, которые согласно RFC 1918 являются «серыми», т.е. немаршрутизируемыми в интернете:
(config-std-nacl)#deny ip 10.0.0.0 0.255.255.255
(config-std-nacl)#deny ip 172.16.0.0 0.15.255.255
(config-std-nacl)#deny ip 192.168.0.0 0.0.255.255
Кроме того, можно заблокировать адреса, являющиеся адресами автоконфигурации. Такие адреса, например, присваиваются компьютерам под управлением операционной системы Windows, настройки сетевого подключения которого обеспечивают присвоение адресов по протоколу DHCP, если в данный момент присвоить адрес не удается (допустим, не доступен dhcp-сервер):
(config-std-nacl)#deny ip 169.254.0.0 0.0.255.255
Ограничим адреса multicast (класс D) и адреса, предназначенные для последующего использования (класс E):
(config-std-nacl)#deny ip 224.0.0.0 15.255.255.255
(config-std-nacl)#deny ip 240.0.0.0 7.255.255.255
Адреса, принадлежащие интерфейсу обратной петли (loopback) и адреса, первые октеты которых нули или все единицы также заблокируем, ибо путь их следования сомнителен:
(config-std-nacl)#deny ip 127.0.0.0 0.255.255.255
(config-std-nacl)#deny ip 0.0.0.0 0.255.255.255
(config-std-nacl)#deny ip host 255.255.255.255
Подсеть, предназначенную для тестирования заблокируем аналогично предыдущим:
(config-std-nacl)#deny ip 192.0.2.0 0.0.0.255
Ну и напоследок ограничим адреса, зарезервированные за организацией IANA и/или так называемые bogons-адреса:
(config-std-nacl)#deny ip 1.0.0.0 0.255.255.255
deny ip 2.0.0.0 0.255.255.255
deny ip 5.0.0.0 0.255.255.255
deny ip 14.0.0.0 0.255.255.255
deny ip 23.0.0.0 0.255.255.255
deny ip 27.0.0.0 0.255.255.255
deny ip 31.0.0.0 0.255.255.255
deny ip 36.0.0.0 0.255.255.255
deny ip 37.0.0.0 0.255.255.255
deny ip 39.0.0.0 0.255.255.255
deny ip 42.0.0.0 0.255.255.255
deny ip 46.0.0.0 0.255.255.255
deny ip 49.0.0.0 0.255.255.255
deny ip 50.0.0.0 0.255.255.255
deny ip 100.0.0.0 0.255.255.255
deny ip 101.0.0.0 0.255.255.255
deny ip 102.0.0.0 0.255.255.255
deny ip 103.0.0.0 0.255.255.255
deny ip 104.0.0.0 0.255.255.255
deny ip 105.0.0.0 0.255.255.255
deny ip 106.0.0.0 0.255.255.255
deny ip 107.0.0.0 0.255.255.255
deny ip 108.0.0.0 0.255.255.255
deny ip 109.0.0.0 0.255.255.255
deny ip 110.0.0.0 0.255.255.255
deny ip 111.0.0.0 0.255.255.255
deny ip 112.0.0.0 0.255.255.255
deny ip 113.0.0.0 0.255.255.255
deny ip 175.0.0.0 0.255.255.255
deny ip 176.0.0.0 0.255.255.255
deny ip 177.0.0.0 0.255.255.255
deny ip 178.0.0.0 0.255.255.255
deny ip 179.0.0.0 0.255.255.255
deny ip 180.0.0.0 0.255.255.255
deny ip 181.0.0.0 0.255.255.255
deny ip 182.0.0.0 0.255.255.255
deny ip 183.0.0.0 0.255.255.255
deny ip 184.0.0.0 0.255.255.255
deny ip 185.0.0.0 0.255.255.255
deny ip 197.0.0.0 0.255.255.255
deny ip 223.0.0.0 0.255.255.255
Не забываем:
permit ip any
Собственно, теперь требуется применить список доступа к интерфейсу:
(config-std-nacl)#exit
(config)#interface E0/0
(config-if)#
ip access-group 20 in
Естественно, с таким же успехом мы могли бы отправлять подобные пакеты в «черную дыру», настроив соответствующим образом маршруты, например, для подсети 192.168.0.0/24 так:
(config)#interface Null0
(config-if)#exit
(config)#ip route 192.168.0.0 255.255.255.0 Null0
Как упоминалось выше, путей решения проблемы спуфинга может быть несколько, и вторая из них - использования протокола Cisco Express Forwarding, особого протокола уровня 3, предназначенного для ускоренной коммутации пакетов и используемого в больших ядрах сети. Наша цель его применения будет заключаться в контролировании обратного пути следования пакета, пришедшего на интерфейс с помощью команды конфигурации интерфейса «ip verify unicast
reverse-path». Однако, здесь может быть несколько сложностей, основная из которых - ограничение, заключающееся в необходимости наличия симметричного прямого и обратного пути пакета. В обратном случае маршрутизация может быть нарушена. Проще говоря, я Вас предупредил - будьте осторожны в своих экспериментах. Последнее, что хотелось бы порекомендовать - запретить принимать фрагментированные icmp-пакеты, хотя атаки, основанные на их использовании и потеряли свою актуальность, лишним это не будет:
deny icmp any any fragments
2.Защита от DDoS
Перейдем ко второй части настройке безопасного межсетевого взаимодействия, а именно к защите от распределенных атак отказа в обслуживании, направленных на истощение ресурсов сети. Как известно, в последнее время атаки типа TCP SYN-flood постепенно сходят на нет благодаря стараниям корпорации Microsoft по защите своих операционных систем семейства Windows от бесконтрольного использования сырых сокетов, позволяющих конструировать сетевые пакеты «вручную». Ввиду вышеназванных обстоятельств все большую популярность приобретают атаки типа ICMP/UDP флуд или атаки, направленные на отказ в обслуживании Web-сервисов путем перегрузки POST/GET-запросами. Как и в любом деле, вариантов выхода из ситуации может быть несколько, но всегда есть наиболее простой. Пойдем по пути наименьшего сопротивления и будем пресекать выше названые атаки с помощью QoS. Суть защиты будет состоять в ограничении пропускной способности, доступной для различных сетевых протоколов. Конечно, параметры очередей будут сильно зависеть от общей пропускной способности вашей сети и статистического распределения трафика по типам. Пусть внешний интерфейс имеет канал 10 Mb/s. Для примера поступим следующим образом: ограничим ICMP-трафик до 500 Kb/s, а UDP-трафик - до 2 Mb/s.
!
interface Ethernet0/0
rate-limit input access-group 150 2010000 250000 250000 conform-action transmit exceed-action drop
rate-limit input access-group 160 500000 62500 62500 conform-action transmit exceed-action drop
...
Если бы в нашей сети использовалась многоадресная рассылка, то можно было бы ограничить и ее, допустим, потоком в 2,5 Mb/s:
rate-limit input access-group 170 2500000 187500 187500 conform-action transmit exceed-action drop
Собственно, списки доступа, согласно которым мы будем классифицировать трафик:
!
access-list 150 remark CAR-UDP ACL
access-list 150 permit udp any any
access-list 160 remark CAR-ICMP ACL
access-list 160 permit icmp any any
access-list 170 remark CAR-Multicast ACL
access-list 170 permit ip any 224.0.0.0 15.255.255.255
!
Опять же в плане защиты от DDoS есть еще варианты, один из которых - перехватчики TCP, которые являются достаточно эффективным средством, но относятся только к атаке TCP SYN-flood, направленной на истощение ресурсов системы. Суть работы перехватчиков TCP заключается в том, что маршрутизатор будет выступать неким посредником между сервером, предоставляющим какую-либо службу TCP и клиентом, пытающимся установить соединение. Идея чрезвычайно проста - маршрутизатор, получивший SYN (synchronization) -пакет в ответ на него пытается отправить ответ SYN/ACK к источнику т.е клиенту. Если операция выполняется успешно, маршрутизатор устанавливает соединение с сервером, а затем объединяет воедино оба соединения. Далее сервер и клиент продолжают процесс взаимодействия без участия маршрутизатора. В результате, если SYN-пакет приходит от недостижимого источника, сервер никогда не узнает о том, что была попытка открытия подключения. Перехватчики TCP могут работать в двух режимах: пассивном режиме наблюдения и, собственно, активном - перехвата. По умолчанию перехватчики работают во втором. Процесс настройки банален и прост, сводится он к указанию списка серверов, соединения с которыми требуется перехватывать и введению команды глобальной конфигурации, задействующей перехватчики для заданного списка доступа:
ip tcp intercept list 101
!
access-list 101 permit tcp any 121.132.143.0 0.0.0.255
3.Комплексная защита внутренней сети
Перейдем к последнему пункту безопасного сетевого взаимодействия - комплексной защите внутренней сети. Основным функционалом, используемым нами будет контекстный контроль доступа (Context-Based Access Control
), входящий в состав Cisco IOS Firewall. Вкратце, использование CBAC позволяет обойти ограничения, заложенные в фильтрацию на основе списков доступа, исходя из того, что в отличие от списков доступа, CBAC оперирует не только информацией сетевого уровня, но и, отчасти, уровня приложения. Основной критерий, на котором базируется CBAC является понятие сессии. Исходя из нее, обратный трафик, который в ситуации использования обычного списка доступа должен был бы быть заблокирован, будет пропущен с помощью создания временных разрешающих записей в списке доступа. Проще говоря, все то, что было инициировано и относится к текущей сессии изнутри, вернется обратно, в то время как аналогичные типы трафика извне не будет пропущены. Однако, внимательный читатель мог заметить, что фактически подобное поведение аналогично состояниям соединений related/established:
permit tcp host 192.168.0.5 eq www any established
но прав он будет лишь отчасти, т.к. CBAC имеет намного больший спектр функционала, и способен различить сессии даже мультимедийных протоколов типа H.323, RealAudio, не говоря уже о таких обыденных протоколах как SMTP или FTP. Впрочем, не будем углубляться в подробности, тем более что в любой момент читатель может обратиться к официальному документу Cisco IOS Security Configuration Guide за более подробной информацией, вместо этого перейдем к примеру на основе нашей сети. Для начала определим правило инспектирования myrule трафика с помощью CBAC:
!
ip inspect name myrule ftp
ip inspect name myrule http
ip inspect name myrule realaudio
ip inspect name myrule h323
ip inspect name myrule smtp
ip inspect name myrule tftp
ip inspect name myrule udp
ip inspect name myrule tcp
!
Затем применим правило myrule ко входящему трафику на внутренний интерфейс E0/1:
!
interface Ethernet0/1
description intranet
ip address 121.132.143.1 255.255.255.0
no ip directed-broadcast
no ip proxy-arp
ip inspect myrule in
ip access-group 101 in
no cdp enable
!
Список доступа с номером 111 на внешнем интерфейсе будет фильтровать прямые обращения извне во внутреннюю сеть. Именно в него CBAC будет вносить временные разрешающие записи:
!
interface Ethernet0/0
description extranet to ISP
ip address 213.241.12.5 255.255.255.252
no ip directed-broadcast
no ip proxy-arp
ip inspect myrule out
ip access-group 111 in
no cdp enable
Список доступа за номером 101 будет определять инспектируемый трафик. Вторым его назначением будет антиспуфинг и блокирование «неиспользуемых»/«неизвестных» протоколов:
!
access-list 101 permit tcp 121.132.143.0 0.0.0.255 any
access-list 101 permit udp 121.132.143.0 0.0.0.255 any
access-list 101 permit icmp 121.132.143.0 0.0.0.255 any
access-list 101 deny ip any any
!
А следующий список доступа, применяемый к внешнему интерфейсу будет блокировать все входящие запросы во внутреннюю сеть. Стоит отметить, что в случае использования некоторых протоколов динамической маршрутизации, в частности EIGRP, требуется разрешить их отдельно, так как их применение подразумевает наличие многоадресной рассылки, будьте аккуратны:
!
access-list 111 deny ip 121.132.143.0 0.0.0.255 any
access-list 111 permit igrp any any
Естественно, для того, чтобы иметь рабочие инструменты отладки, требуется разрешить использование некоторых типов пакетов ICMP:
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 administratively-prohibited
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 echo
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 echo-reply
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 packet-too-big
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 time-exceeded
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 traceroute
Ну и наконец финальным аккордом запрещаем все остальное:
access-list 111 deny ip any any
!
Пожалуй, если теперь свести все настройки из первой и второй части статьи, мы получим достаточно безопасную конфигурацию нашего маршрутизатора, обеспечивающего надлежащий уровень защиты пользователей и самого себя от различных видов атак. Конечно, полная безопасность это миф, и даже такая настройка не гарантирует лечение паранойи, ведь нет предела совершенству. А совершенствоваться необходимо постоянно и лучшим источником информации для этого, конечно, является официальная документация, обращайтесь к ней чаще, ведь множество не менее интересного, хотя и реже используемого функционала так и осталась за бортом этой статьи. Всего наилучшего.
Ссылки и источники:
Cisco IOS Security Configuration Guide
Building Bastion Routers Using Cisco IOS
http://www.faqs.org/rfcs/rfc1918.html
http://www.faqs.org/rfcs/rfc2365.html
В прошлой части статьи мы начали настраивать безопасность маршрутизатора с ограничения доступа непосредственно к самому устройству, отключили лишние службы, настроили безопасность SNMP и включили журналирования. Остановились мы на аспекте безопасного межсетевого взаимодействия, которое, подчас, является не менее важным чем безопасность самого маршрутизатора.
1.Защита от подмены ip-адресов или антиспуфинг
Подмена ip-адресов - это настоящий бич интернета, основанного на потоколе ip версии 4. Проблема состоит в том, что чаще всего большинство маршрутизаторов настроены на перенаправление пакетов исходя только из данных в поле адреса назначения заголовка ip. Конечно, проблема заключается не в самом механизме маршрутизации, а в том, что в большинстве сетей абсолютно любой корректно сформированный пакет будет совершенно свободно перенаправлен, если маршрутизатор будет иметь маршрут к адресу назначения, даже если в поле адреса источника заголовка ip будет указан нелегитимный адрес. Подобный нелегитимный (фейк) адрес в условиях нормально функционирования сети обычно не может быть указан в качестве источника пакета и чаще всего причиной его появления может стать лишь то, что кто-то, а точнее что-то не желает показать, откуда в действительности пришел пакет. Проще говоря, причиной появления в сети подобных пакетов чаще всего является вредоносное программное обеспечение, будь то черви, вирусы, спам- или DDoS-боты. Конечно, скрыть их деятельность очень сложно и любой мало-мальски опытный сетевой администратор при желании достаточно быстро обнаружит их сетевую активность. Возьмем, к примеру, процесс рассылки спама. Пусть в данном примере схема сети в точности соответствует рисунку. Чаще всего такой нехорошей затеей, т.е. спамом, будут заниматься управляемые боты, особый класс вредоносного программного обеспечения типа троянов-бекдоров, централизованно управляемых с мастер-сервера. Спам-бот, получив команду от хозяина через мастер-сервер в большом количестве рассылает корреспонденцию, открывая множество tcp-соединений на 25-е порты (SMTP) различных серверов. При этом в кеше маршрутизатора сетевой администратор наблюдает записи подобные этим:
#show ip cash flow
E0/0 86.35.180.4 E0/1 72.80.182.193 06 0C17 0019 7
E0/0 92.83.36.64 E0/1 78.37.213.158 06 E774 0019 2
E0/0 85.140.144.55 E0/1 78.37.213.158 06 CB6A 0019 7
E0/0 88.231.190.7 E0/1 69.13.131.2 06 C211 0019 2
E0/0 83.143.38.195 E0/1 67.18.144.162 06 0C37 0019 2
E0/0 62.66.167.235 E0/1 44.98.128.241 06 714F 0019 6
здесь 0019 - 25-й порт в шестнадцатеричном представлении. Администратор видит, что с интерфейса E0/1, который является в нашем примере внутренним, в большом количестве поступают пакеты, направленные к адресам в интернете, а порт назначения принадлежит протоколу SMTP. Однако, адрес источника никак не мог оказаться таким, ведь внутрення подсеть 121.132.143.0/24! Что же случилось? Мы столкнулись с простейшим примером подмены адреса источника или, проще говоря, спуфинга. Что же делать? Вариантов защиты несколько. Первый из них - ограничить исходящие пакеты на основе ip-адреса источника, исходя из принадлежности адресов к нашей сети:
#conf t
(config)#ip access-list standart 20
(config-std-nacl)#permit 121.132.143.0 0.0.0.255
(config-std-nacl)#deny any
(config-std-nacl)#exit
(config)#interface E0/1
(config-if)#ip access-group 20 in
Таким образом мы ограничим исходящий трафик из нашей сети с адресов, которые фактически нам не принадлежат. Такая концепция как минимум облегчит жизнь таким же как мы сетевым администраторам в деле борьбы с подменой ip-адресов. Теперь перейдем к внешнему интерфейсу. Согласно нашему примеру это интерфейс E0/0. Ограничим входящий трафик с адресов, которые фактически не могут быть источниками для пакетов, приходящих из интернета. Естественно, из внешней сети к нам не могут прийти пакеты, источник которых - наша внутренняя сеть, ограничим их:
#conf t
(config)#ip access-list standart 30
(config-std-nacl)#deny ip 121.132.143.0 0.0.0.255
Затем ограничим адреса, которые согласно RFC 1918 являются «серыми», т.е. немаршрутизируемыми в интернете:
(config-std-nacl)#deny ip 10.0.0.0 0.255.255.255
(config-std-nacl)#deny ip 172.16.0.0 0.15.255.255
(config-std-nacl)#deny ip 192.168.0.0 0.0.255.255
Кроме того, можно заблокировать адреса, являющиеся адресами автоконфигурации. Такие адреса, например, присваиваются компьютерам под управлением операционной системы Windows, настройки сетевого подключения которого обеспечивают присвоение адресов по протоколу DHCP, если в данный момент присвоить адрес не удается (допустим, не доступен dhcp-сервер):
(config-std-nacl)#deny ip 169.254.0.0 0.0.255.255
Ограничим адреса multicast (класс D) и адреса, предназначенные для последующего использования (класс E):
(config-std-nacl)#deny ip 224.0.0.0 15.255.255.255
(config-std-nacl)#deny ip 240.0.0.0 7.255.255.255
Адреса, принадлежащие интерфейсу обратной петли (loopback) и адреса, первые октеты которых нули или все единицы также заблокируем, ибо путь их следования сомнителен:
(config-std-nacl)#deny ip 127.0.0.0 0.255.255.255
(config-std-nacl)#deny ip 0.0.0.0 0.255.255.255
(config-std-nacl)#deny ip host 255.255.255.255
Подсеть, предназначенную для тестирования заблокируем аналогично предыдущим:
(config-std-nacl)#deny ip 192.0.2.0 0.0.0.255
Ну и напоследок ограничим адреса, зарезервированные за организацией IANA и/или так называемые bogons-адреса:
(config-std-nacl)#deny ip 1.0.0.0 0.255.255.255
deny ip 2.0.0.0 0.255.255.255
deny ip 5.0.0.0 0.255.255.255
deny ip 14.0.0.0 0.255.255.255
deny ip 23.0.0.0 0.255.255.255
deny ip 27.0.0.0 0.255.255.255
deny ip 31.0.0.0 0.255.255.255
deny ip 36.0.0.0 0.255.255.255
deny ip 37.0.0.0 0.255.255.255
deny ip 39.0.0.0 0.255.255.255
deny ip 42.0.0.0 0.255.255.255
deny ip 46.0.0.0 0.255.255.255
deny ip 49.0.0.0 0.255.255.255
deny ip 50.0.0.0 0.255.255.255
deny ip 100.0.0.0 0.255.255.255
deny ip 101.0.0.0 0.255.255.255
deny ip 102.0.0.0 0.255.255.255
deny ip 103.0.0.0 0.255.255.255
deny ip 104.0.0.0 0.255.255.255
deny ip 105.0.0.0 0.255.255.255
deny ip 106.0.0.0 0.255.255.255
deny ip 107.0.0.0 0.255.255.255
deny ip 108.0.0.0 0.255.255.255
deny ip 109.0.0.0 0.255.255.255
deny ip 110.0.0.0 0.255.255.255
deny ip 111.0.0.0 0.255.255.255
deny ip 112.0.0.0 0.255.255.255
deny ip 113.0.0.0 0.255.255.255
deny ip 175.0.0.0 0.255.255.255
deny ip 176.0.0.0 0.255.255.255
deny ip 177.0.0.0 0.255.255.255
deny ip 178.0.0.0 0.255.255.255
deny ip 179.0.0.0 0.255.255.255
deny ip 180.0.0.0 0.255.255.255
deny ip 181.0.0.0 0.255.255.255
deny ip 182.0.0.0 0.255.255.255
deny ip 183.0.0.0 0.255.255.255
deny ip 184.0.0.0 0.255.255.255
deny ip 185.0.0.0 0.255.255.255
deny ip 197.0.0.0 0.255.255.255
deny ip 223.0.0.0 0.255.255.255
Не забываем:
permit ip any
Собственно, теперь требуется применить список доступа к интерфейсу:
(config-std-nacl)#exit
(config)#interface E0/0
(config-if)#
ip access-group 20 in
Естественно, с таким же успехом мы могли бы отправлять подобные пакеты в «черную дыру», настроив соответствующим образом маршруты, например, для подсети 192.168.0.0/24 так:
(config)#interface Null0
(config-if)#exit
(config)#ip route 192.168.0.0 255.255.255.0 Null0
Как упоминалось выше, путей решения проблемы спуфинга может быть несколько, и вторая из них - использования протокола Cisco Express Forwarding, особого протокола уровня 3, предназначенного для ускоренной коммутации пакетов и используемого в больших ядрах сети. Наша цель его применения будет заключаться в контролировании обратного пути следования пакета, пришедшего на интерфейс с помощью команды конфигурации интерфейса «ip verify unicast
reverse-path». Однако, здесь может быть несколько сложностей, основная из которых - ограничение, заключающееся в необходимости наличия симметричного прямого и обратного пути пакета. В обратном случае маршрутизация может быть нарушена. Проще говоря, я Вас предупредил - будьте осторожны в своих экспериментах. Последнее, что хотелось бы порекомендовать - запретить принимать фрагментированные icmp-пакеты, хотя атаки, основанные на их использовании и потеряли свою актуальность, лишним это не будет:
deny icmp any any fragments
2.Защита от DDoS
Перейдем ко второй части настройке безопасного межсетевого взаимодействия, а именно к защите от распределенных атак отказа в обслуживании, направленных на истощение ресурсов сети. Как известно, в последнее время атаки типа TCP SYN-flood постепенно сходят на нет благодаря стараниям корпорации Microsoft по защите своих операционных систем семейства Windows от бесконтрольного использования сырых сокетов, позволяющих конструировать сетевые пакеты «вручную». Ввиду вышеназванных обстоятельств все большую популярность приобретают атаки типа ICMP/UDP флуд или атаки, направленные на отказ в обслуживании Web-сервисов путем перегрузки POST/GET-запросами. Как и в любом деле, вариантов выхода из ситуации может быть несколько, но всегда есть наиболее простой. Пойдем по пути наименьшего сопротивления и будем пресекать выше названые атаки с помощью QoS. Суть защиты будет состоять в ограничении пропускной способности, доступной для различных сетевых протоколов. Конечно, параметры очередей будут сильно зависеть от общей пропускной способности вашей сети и статистического распределения трафика по типам. Пусть внешний интерфейс имеет канал 10 Mb/s. Для примера поступим следующим образом: ограничим ICMP-трафик до 500 Kb/s, а UDP-трафик - до 2 Mb/s.
!
interface Ethernet0/0
rate-limit input access-group 150 2010000 250000 250000 conform-action transmit exceed-action drop
rate-limit input access-group 160 500000 62500 62500 conform-action transmit exceed-action drop
...
Если бы в нашей сети использовалась многоадресная рассылка, то можно было бы ограничить и ее, допустим, потоком в 2,5 Mb/s:
rate-limit input access-group 170 2500000 187500 187500 conform-action transmit exceed-action drop
Собственно, списки доступа, согласно которым мы будем классифицировать трафик:
!
access-list 150 remark CAR-UDP ACL
access-list 150 permit udp any any
access-list 160 remark CAR-ICMP ACL
access-list 160 permit icmp any any
access-list 170 remark CAR-Multicast ACL
access-list 170 permit ip any 224.0.0.0 15.255.255.255
!
Опять же в плане защиты от DDoS есть еще варианты, один из которых - перехватчики TCP, которые являются достаточно эффективным средством, но относятся только к атаке TCP SYN-flood, направленной на истощение ресурсов системы. Суть работы перехватчиков TCP заключается в том, что маршрутизатор будет выступать неким посредником между сервером, предоставляющим какую-либо службу TCP и клиентом, пытающимся установить соединение. Идея чрезвычайно проста - маршрутизатор, получивший SYN (synchronization) -пакет в ответ на него пытается отправить ответ SYN/ACK к источнику т.е клиенту. Если операция выполняется успешно, маршрутизатор устанавливает соединение с сервером, а затем объединяет воедино оба соединения. Далее сервер и клиент продолжают процесс взаимодействия без участия маршрутизатора. В результате, если SYN-пакет приходит от недостижимого источника, сервер никогда не узнает о том, что была попытка открытия подключения. Перехватчики TCP могут работать в двух режимах: пассивном режиме наблюдения и, собственно, активном - перехвата. По умолчанию перехватчики работают во втором. Процесс настройки банален и прост, сводится он к указанию списка серверов, соединения с которыми требуется перехватывать и введению команды глобальной конфигурации, задействующей перехватчики для заданного списка доступа:
ip tcp intercept list 101
!
access-list 101 permit tcp any 121.132.143.0 0.0.0.255
3.Комплексная защита внутренней сети
Перейдем к последнему пункту безопасного сетевого взаимодействия - комплексной защите внутренней сети. Основным функционалом, используемым нами будет контекстный контроль доступа (Context-Based Access Control
), входящий в состав Cisco IOS Firewall. Вкратце, использование CBAC позволяет обойти ограничения, заложенные в фильтрацию на основе списков доступа, исходя из того, что в отличие от списков доступа, CBAC оперирует не только информацией сетевого уровня, но и, отчасти, уровня приложения. Основной критерий, на котором базируется CBAC является понятие сессии. Исходя из нее, обратный трафик, который в ситуации использования обычного списка доступа должен был бы быть заблокирован, будет пропущен с помощью создания временных разрешающих записей в списке доступа. Проще говоря, все то, что было инициировано и относится к текущей сессии изнутри, вернется обратно, в то время как аналогичные типы трафика извне не будет пропущены. Однако, внимательный читатель мог заметить, что фактически подобное поведение аналогично состояниям соединений related/established:
permit tcp host 192.168.0.5 eq www any established
но прав он будет лишь отчасти, т.к. CBAC имеет намного больший спектр функционала, и способен различить сессии даже мультимедийных протоколов типа H.323, RealAudio, не говоря уже о таких обыденных протоколах как SMTP или FTP. Впрочем, не будем углубляться в подробности, тем более что в любой момент читатель может обратиться к официальному документу Cisco IOS Security Configuration Guide за более подробной информацией, вместо этого перейдем к примеру на основе нашей сети. Для начала определим правило инспектирования myrule трафика с помощью CBAC:
!
ip inspect name myrule ftp
ip inspect name myrule http
ip inspect name myrule realaudio
ip inspect name myrule h323
ip inspect name myrule smtp
ip inspect name myrule tftp
ip inspect name myrule udp
ip inspect name myrule tcp
!
Затем применим правило myrule ко входящему трафику на внутренний интерфейс E0/1:
!
interface Ethernet0/1
description intranet
ip address 121.132.143.1 255.255.255.0
no ip directed-broadcast
no ip proxy-arp
ip inspect myrule in
ip access-group 101 in
no cdp enable
!
Список доступа с номером 111 на внешнем интерфейсе будет фильтровать прямые обращения извне во внутреннюю сеть. Именно в него CBAC будет вносить временные разрешающие записи:
!
interface Ethernet0/0
description extranet to ISP
ip address 213.241.12.5 255.255.255.252
no ip directed-broadcast
no ip proxy-arp
ip inspect myrule out
ip access-group 111 in
no cdp enable
Список доступа за номером 101 будет определять инспектируемый трафик. Вторым его назначением будет антиспуфинг и блокирование «неиспользуемых»/«неизвестных» протоколов:
!
access-list 101 permit tcp 121.132.143.0 0.0.0.255 any
access-list 101 permit udp 121.132.143.0 0.0.0.255 any
access-list 101 permit icmp 121.132.143.0 0.0.0.255 any
access-list 101 deny ip any any
!
А следующий список доступа, применяемый к внешнему интерфейсу будет блокировать все входящие запросы во внутреннюю сеть. Стоит отметить, что в случае использования некоторых протоколов динамической маршрутизации, в частности EIGRP, требуется разрешить их отдельно, так как их применение подразумевает наличие многоадресной рассылки, будьте аккуратны:
!
access-list 111 deny ip 121.132.143.0 0.0.0.255 any
access-list 111 permit igrp any any
Естественно, для того, чтобы иметь рабочие инструменты отладки, требуется разрешить использование некоторых типов пакетов ICMP:
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 administratively-prohibited
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 echo
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 echo-reply
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 packet-too-big
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 time-exceeded
access-list 111 permit icmp any 121.132.143.0 0.0.0.255 traceroute
Ну и наконец финальным аккордом запрещаем все остальное:
access-list 111 deny ip any any
!
Пожалуй, если теперь свести все настройки из первой и второй части статьи, мы получим достаточно безопасную конфигурацию нашего маршрутизатора, обеспечивающего надлежащий уровень защиты пользователей и самого себя от различных видов атак. Конечно, полная безопасность это миф, и даже такая настройка не гарантирует лечение паранойи, ведь нет предела совершенству. А совершенствоваться необходимо постоянно и лучшим источником информации для этого, конечно, является официальная документация, обращайтесь к ней чаще, ведь множество не менее интересного, хотя и реже используемого функционала так и осталась за бортом этой статьи. Всего наилучшего.
Ссылки и источники:
Cisco IOS Security Configuration Guide
Building Bastion Routers Using Cisco IOS
http://www.faqs.org/rfcs/rfc1918.html
http://www.faqs.org/rfcs/rfc2365.html
Комментариев нет:
Отправить комментарий