Ключевые слова:cisco, auth, security, limit, firewall, acl, snmp, (найти похожие документы)
From: BETEP <enkhabarov@gmail.com.>
Date: Mon, 9 Feb 2007 14:31:37 +0000 (UTC)
Subject: Настройка безопасности маршрутизаторов Cisco
Оригинал: http://dr-betep.blogspot.com/2009/02/1.htmlhttp://dr-betep.blogspot.com/2009/02/2.html
Настраиваем неприступный маршрутизатор. Часть 1.
Статья была опубликована в журнале IT-Спец за февраль 2008 г.
Хотелось бы сразу сказать, что данная статья не претендует на
какую-либо уникальность и новизну. Я лишь еще раз повторю то, что
говорили уже много раз, однако постараюсь привнести в это сказанное
некую изюминку. Проще говоря статья повествует о том, как защищает
свои маршрутизаторы автор. Статья рассчитана на человека, который
знаком с операционной системой IOS маршрутизаторов Cisco и имеет
базовые представления о принципах коммутации, маршрутизации и сетевых
протоколах. В основном я буду рассматривать IOS версии 12.4 с
функционалом advansed IP services, однако с большой долей вероятности
все нижесказанное может быть применено к более старым операционным
системам.
0. О том, как надо защищаться.
Основным принципом защиты маршрутизатора является запрет всего, кроме
того, что разрешено. Помимо этого хорошей идеей является запрет того
функционала, который будет использоваться редко, не имеет смысла в
использовании или назначение которого нам не совсем ясно. Конечно,
последний пункт должен быть исключением, так как мы всегда можем
ознакомиться с огромным набором документации.
И так, план действий защиты таков:
1.Настройка аутентификации и паролей
2.Ограничение доступа к маршрутизатору
3.Отключение лишних служб и включение дополнительных
4.Настройка SNMP
5.Настройка журналирования
1.Операционная система Cisco IOS во многом очень схожа с большинством
операцион6ных систем семейства UNIX. Как и в *nix-системах все
основные операции по настройке и работе с маршрутизатором происходят
посредством взаимодействия с командной оболочкой (CLI). Доступ к
командной оболочке можно получить через удаленный терминал (vty),
консольный порт (con), либо через модем на порту aux. Чаще всего весь
процесс взаимодействия с маршрутизатором происходит через удаленный
терминал. Консольный порт применяется лишь в экстренных случаях или в
случае острой паранойи. Если маршрутизатор установлен на чужой
территории, например вы арендуете место в шкафу, то можно отключить
консоль и аuх порты, чтобы предотвратить физический доступ к
маршрутизатору. Однако вам тогда будет сложнее самим зайти на него в
случае потери удаленного управления. Модем часто применяется как
резервный канал доступа к маршрутизатору, но в последнее время его
применяют все реже. Существуют два основных режима, в котором можно
работать с командной оболочкой: непривилегированный режим (EXEC level)
и привилегированный режим (privileged EXEC level). Привилегированный
режим позволяет изменять настройки маршрутизатора в режиме
конфигурации. По большому счету это очень напоминает
непривилегированного пользователя и root. Примерно как обычный
пользователь *nix системы использует команду su для авторизации
исполнения команд с правами root, в IOS используется команда enable.
Всего в IOS доступны 15 уровней приоритетов. Привилегированный режим
обычно имеет уровень приоритета 15, в то время как обычный
пользователь в непривилегированном режиме имеет уровень 1. Кроме того
администратор может задать определенный набор команд, доступный для
пользователя в соответствии с его режимом приоритета, например так:
!
enable secret level 4 5 $1$6Dr/$vVMNdSKUfSkF.o9IMasrt1
!
privilege exec level 4 traceroute
privilege exec level 4 ping
privilege exec level 4 clear
privilege exec level 4 show configuration
!
Пароли в конфигурации маршрутизатора могут быть нескольких типов:
- обычные открытые (plain-text) пароли
- type 7 пароли
- type 5 пароли
По-умолчанию в конфигурации маршрутизатора пароли хранятся в открытом
тексте и любой, кто имеет доступ к привилегированному режиму командной
оболочки или к самому файлу конфигурации может увидеть их просматривая
show running-config или show startup-config. Избежать этого можно с
помощью кодирования паролей командой
service password-encryption
После применения этой команды все plain-text пароли в конфигурации
заменяются на так называемые type 7 пароли, которые представляют из
себя набор цифр и заглавных букв от A до F. Хотя формально эти пароли
и зашифрованы, назвать шифрованием такой метод сложно так как основан
он на применении XOR-подобной функции с ключом
dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;f g87
Существует множество утилит для расшифровки type 7 паролей, множество
из которых доступно на packetstormsecurity.org и ему подобных сайтах.
С таким же успехом пароль может быть раскодирован на самом
маршрутизаторе с помощью нехитрой последовательности действий. Для
начала включим режим шифрования plain-text паролей и добавим некого
тестового пользователя с паролем <<passw0rd":
Router(config)#service password-encryption
Router(config)#username test password passw0rd
Теперь выполним команду show и выведем нашу строку:
Router(config)#do show run | include username
username test password 7 044B0A151C361C5C0D
Затем создадим цепочку ключей и введем type-7 пароль как ключевую
строку для него:
Router(config)#key chain decrypt
Router(config-keychain)#key 0
Router(config-keychain-key)#key-string 7 044B0A151C361C5C0D
А теперь с помощью show выведем расшифрованную строку:
Router(config-keychain-key)#do show key chain decrypt
Key-chain decrypt:
****key 1 -- text "passw0rd"
********accept lifetime (always valid) - (always valid) [valid now]
********send lifetime (always valid) - (always valid) [valid now]
Как видим, безопасность type 7 паролей оставляет желать лучшего.
Выхода может быть два -- один из них оригинальный и нестандартный,
другой -- соответственно полная его противоположность. В качестве
последнего можно использовать type 5 (или так называемые secret)
пароли, которые переставляют из себя md5-хеши. Как известно, при
достаточной длине пароля взломщик встретится с трудно решаемой
вычислительной задачей, чего, в принципе, должно быть достаточно для
защиты. Примером type 5 может служить пароль на режим enable:
enable secret 5 $1$3ORt$Pf.hrk2RehgDs3w7L5ER/0
Брать в рассмотрение первый способ рекомендую только в крайнем случае
(например, выраженное проявление паранойи). Заключается он в
модификации бинарного образа операционной системы маршрутизатора и
изменении вышеупомянутого ключа шифрования. Не вдаваясь в подробности,
скажу лишь что образ IOS представляет собой запакованный в слегка
модифицированный zip-архив бинарный ELF-файл, который очень похож на
ядро Linux и других подобных операционных систем. Строка шифрования
представлена в нем в открытом виде и для ее модификации можно
воспользоваться любым шестнадцатеричным редактором. Единственную
проблему может представлять специальное поле контрольной суммы образа,
которое необходимо будет переписать после изменения ключа и
перепаковки образа. Как для распаковки, так и для корректной упаковки
с подсчетом контрольной суммы можно использовать утилиту ciscopack от
создателей книги "Hacking Exposed Cisco Networks". Скачать ее можно
здесь: http://www.hackingciscoexposed.com/tools/ciscopack.tar.gz.
Пример использования:
usage: ./ciscopack.pl [--unpack=imagename ]
Options:
--upack Upack cisco IOS image
--pack Pack new imagename
--head Head (Self extractor) to pack
--body Body (IOS body) to pack
--readheader Read the file header
--help This message
Естественно, проводить эксперименты рекомендуется не на используемом в
активном сетевом взаимодействии маршрутизаторе, так как последствия
неправильной модификации могут быть катастрофическими. В своих
исследованиях я использовал эмулятор dynamips для запуска образов
операционной системы IOS платформы 3725
(c3725-adventerprisek9-mz.124-18.bin) и шестнадцатеричный редактор
biew для модификации образа IOS.
ciscopack.pl --unpack c3725-adventerprisek9-mz.124-18.bin --head c3725-adventerprisek9-mz.124-18.bin.head
ciscopack.pl, , V 0.1
Unpacking image: c3725-adventerprisek9-mz.124-18.bin
Written 7078 byte to c3725-adventerprisek9-mz.124-18.bin.head
Magic is found, reading the archive info
Compressed size:81980888 byte. Compressed size:39184467 byte
Compressed checksum: 0xb1dff6e0 Uncompressed checksum: 0x26adfdf2
Written Kb38267 to c3725-adventerprisek9-mz.124-18.bin.zip
uzip c3725-adventerprisek9-mz.124-18.bin.zip
Archive: c3725-adventerprisek9-mz.124-18.bin.zip
inflating: C3725-AD.BIN
All done!
Полученный распакованный образ я модифицировал в шестнадцатеричном
редакторе biew, заменив строку:
dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;f g87
на строку:
shados.oA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;f g87
После этого проведем тест. Загружаем модифицированный образ в
эмулятор:
dynamips -P 3725 C3725-AD.bin
После загрузки, отменяем вход в режим начальной конфигурации, включим
сервис шифрования паролей и создадим пользователя с паролем
"notracable":
Router(config)#service password-encryption
Router(config)#username shados password notcracable
Теперь выполним команду show и выведем нашу строку:
Router(config)#do show run | include username
username test password 7 04011C120c334d4d0218071B17
Полученную строку попытаемся расшифровать в хорошо известной
утилите Cain&Able (http://www.oxid.it). Как видим, исходный пароль
и расшифрованный отличают -- трюк сработал. Образ, загруженный в
эмулятор оттестирован и готов к использованию на реальном
маршрутизаторе после переупаковки:
./ciscopack.pl --pack c3725-adventerprisek9-mz.124-18.bin \
--head c3725-adventerprisek9-mz.124-18.bin.head --body С3725-AD.bin
Пожалуй, на этом с собственно паролями закончим и перейдем к
авторизации. Естественно, для настройки авторизации будем использовать
наиболее современные методы, такие как модульный фреймворк AAA
(Authentication, Authorization, Accounting). Для настройки этого
сервиса требуется выполнить всего несколько простых действий:
1.Включить использование AAA посредством команды глобальной
конфигурации
aaa new-model
2. Если принято решение использовать внешний сервер безопасности,
следует на стоить параметры работы его протокола (например, RADIUS,
TACACS+, Kerberos)
3.Определить списки методов аутентификации
4.Применить созданный список для конкретного интерфейса или линии
5.Если требуется -- настроить авторизацию и аккаунтинг.
В качестве примера настроим аутентификацию посредством TACACS+. Если
по TACACS+ аутентифицироваться не удастся -- переходим к локальной
аутентификации:
Router(config)#aaa new-model
Router(config)#aaa authentication login default group tacacs+ local-case
Router(config)#aaa authentication enable default group tacacs+ enable
Router(config)#aaa authorization commands 15 default group tacacs+ local
Router(config)#aaa accounting exec default stop-only group tacacs+
Router(config)#aaa accounting commands 15 default stop-only group tacacs+
Router(config)#aaa accounting network default stop-only group tacacs+
Так, например, если аутентифицироваться для удаленного входа в exec
режим через TACACS+ сервер не удастся, мы попытаемся
аутентифицироваться в локальной базе пользователей:
username secret
Логично, что для большей защищенности стоит использовать символы
разных регистров -- это значительно усложнит жизнь переборщикам
паролей.
Помимо всего прочего хорошей идеей будет изменить стандартное
приглашение ввода имени пользователя и пароля. Пусть, допустим, оно
будет сходно приглашению Linux:
Router(config)#aaa authentication password-prompt "password: "
Router(config)#aaa authentication username-prompt "login as: "
Такой трюк как минимум запутает взломщика, привыкшего видеть
стандартное приглашение маршрутизатора.
2. Перейдем ко второму пункту наших действий -- ограничение удаленного
доступа. Конечно, чаще всего на маршрутизатор оператору или сетевому
администратору придется получать доступ через удаленный терминал.
Отсюда следует простая мысль, что этот же путь попытается проследовать
взломщик (лицо, осуществляющее несанкционированное вторжение; пожалуй,
здесь я сделаю небольшое лирическое отступление и позволю себе
заметить, что намеренно не ассоциирую взломщика с хакером по известным
этическим причинам и соображениям). Общая схема такова -- доступ к
консоли ограничиваем таймаутом в 15 минут, доступ через порт AUX
отключаем полностью, доступ к виртуальному терминалу ограничиваем
стандартным списком доступа, в качестве транспорта используем протокол
ssh и также ограничиваем сессию таймаутом в 15 минут. Стандартный
список доступа разрешает доступ только с двух доверенных машин, все
остальные запросы фильтруются. Будем использовать протокол SSH версии
2 ввиду его большей безопасности, ограничим таймаутом и включим его
журналирование. Ниже привожу вырезку из конфигурации устройства:
!
ip ssh time-out 15
ip ssh logging events
ip ssh version 2
!
!
access-list 100 permit 172.16.1.100
access-list 100 permit 172.17.1.200
access-list 100 deny any
!
line con 0
exec-timeout 15 0
line aux 0
exec-timeout 0 0
no exec
transport input none
line vty 0 4
access-class 100 in
exec-timeout 15 0
transport input ssh
!
Позволю себе напомнить читателю, что для того, чтобы использовать
протокол SSH необходимо задать домен маршрутизатора и имя хоста, а
затем сгенерировать RSA ключи достаточной длинны (автор всегда
выбирает максимально доступную длину, в частности 2048):
Router(config)#ip domain name something.ru
Router(config)#crypto key generate rsa
Интересен один момент -- в фильтрации удаленного доступа тоже есть
место для трюка. В документации по операционной системе IOS 12.4 нет
упоминания о том, что помимо стандартных списков доступа можно
использовать еще и именованные. Грех этим не воспользоваться в своих
целях. Хорошим примером применения этого функционала можно считать
разрешение доступа по протоколу telnet из внутренней сети технических
специалистов, а доступ с внешних адресов разрешить по протоколу ssh.
Кроме этого, именованные списки доступа позволяют вести журналирование
запросов. Ниже приведу пример, из которого станет все понятно:
!
ip access-list extended TerminalAccess
permit tcp 172.16.1.0 0.0.0.255 any eq telnet log
permit tcp any any eq 22 log
deny tcp any any log
!
line vty 0 4
access-class TerminalAccess in
transport input telnet ssh
Завершающим аккордом второго этапа будет настройка задержки между
повторными вводами учетныйх данных:
Router(config)#login delay 5
Router(config)#login block-for 60 attempts 3 within 30
Первой командой мы устанавливаем задержку между повторными вводами
равной пяти секундам. Второй командой устанавливаем блокировку на 60
секунд в случае трех неудачных попыток ввода имени пользователя/пароля
в течение 30 секунд.
3. Третий этап наших действий по защите состоит в отключении всех
ненужных и небезопасных служб маршрутизатора. На мой взгляд этот этап
является наиболее простым и наименее творческим.
Командой глобальной конфигурации отключаем использование протокола CDP
(Cisco Discovery Protocol). Это защитит наш маршрутизатор от раскрытия
критичных данных о платформе, версии и т.п.
Router(config)#no cdp running
Проверим, отключены ли простые службы, аналогичные службам inetd типа
chargen:
Router(config)#no service tcp-small-servers
Router(config)#no service udp-small-servers
Включим службы keep-alive, чтобы защититься от возможного перехвата,
например, сессии telnet:
Router(config)#service tcp-keepalives-in
Router(config)#service tcp-keepalives-out
Отключим доспуп к маршрутизатору по протоколам http и https, так как
все основные задачи по конфигурированию маршрутизатора будем выполнять
через командную оболочку:
Router(config)#no ip http server
Router(config)#no ip http secure-server
Если не планируется использовать протокол динамического присвоения
IP-адресов, отключим его:
Router(config)#no service dhcp
Маршрутизацию от источника, резолвинг DNS-имен, finger и тому подобные
службы, необходимость которых сомнительна, либо если служба является
потенциально небезопасной также отключаем:
Router(config)#no ip source-route
Router(config)#no ip finger
Router(config)#no ip bootp server
Router(config)#no ip domain-lookup
Скорее всего для журналирования потребуется использовать
централизованную синхронизацию времени с NTP- сервером (Network Time
Protocol)*. Выставляем правильную временную зону, соответствующую
нашему расположению, назначаем ключ аутентификации для сервера и,
собственно, указываем сам сервер:
Router(config)#clock timezone GMT 3
Router(config)#ntp authenticate
Router(config)#ntp authentication-key 1 md5
Router(config)#ntp server 172.16.1.100
Завершающей частью этого пункта включим автоматическую проверку
целостности образа операционной системы IOS, который может быть как
поврежден во время передачи, так и модифицирован злонамеренно с целью
внедрения рукткита:
Router(config)#file verify auto
Пример работы службы контроля целостности:
Verifying file integrity of
flash:c2600-ipbasek9-mz.124-17.bin....................................
........ ..................................................
............................Done!
Embedded Hash MD5 : 5DB1422925E26D7AEAB3DB9AF919AF83
Computed Hash MD5 : 5DB1422925E26D7AEAB3DB9AF919AF83
CCO Hash MD5 : EB9561C52A02E1DECD8490ED2935B5E9
Signature Verified
Verified flash:c2600-ipbasek9-mz.124-17.bin
4. Атаки на SNMP, пожалуй, являются одними из опаснейших, поэтому
защите SNMP-агента маршрутизатора следует уделить пристальное
внимание. Основной вектор атак на SNMP в случае маршрутизатора Cisco
под управлением операционной системы IOS является получение
конфигурации через CISCO-CONFIG-COPY-MIB. Атака может быть успешно
проведена только в случае наличия строки community, доступной на
запись. Маршрутизаторы Cisco под управлением IOS 12.4 поддерживают 3
основных модели SNMP -- v1, v2c и v3. Соответственно каждая из моделей
обеспечивает свой уровень защищенности, однако выбор ее зависит, в
основном, от используемой системы мониторинга, а точнее от ее
совместимости с используемой моделью безопасности. Естественно, для
наибольшей безопасности рекомендуется использовать наиболее
совершенную модель SNMPv3, отличающуюся наличием аутентификации по MD5
и SHA-ключам, 56-ти битным шифрованием данных по алгоритму DES, а
также разграничением политик доступа пользователей по группам. Приведу
пример настройки:
Router(config)#snmp-server group netadmins v3 priv
Router(config)#snmp-server user operator netadmins v3 auth md5
AuthPassw0rd priv des56 EncryptionPassw0rd
Первой командой мы создаем группу "netadmins" и указываем, что
каждый пакет необходимо аутентифицировать и шифровать. Следует
заметить, что одна из самых распространенных систем мониторинга Cacti
умеет работать только с группами, опция которых установлена в auth.
Второй командой мы создаем пользователя "operator", входящего в
группу "netadmins", и указываем что аутентифицироваться он будет по
md5-паролю, а шифрование данных будет происходить по протоколу DES.
Для проверки работоспособности воспользуемся утилитой snmpwalk, где
172.16.1.1 -- ip-адрес маршрутизатора:
snmpwalk -v 3 -u operator -A AuthPassw0rd -x DES -X EncryptionPassw0rd -l AuthPriv 172.16.1.1
Для большей защищенности можно определить список доступа,
ограничивающий доступ к внешним серверам tftp, ftp, sftp и т.д.:
!
access-list 100 permit 172.16.1.100
access-list 100 permit 172.17.1.200
access-list 100 deny any
!
snmp-server file-transfer access-group 100
На этом, пожалуй, настройку протокола SNMP закончим и перейдем к
настройке журналирования.
Для начала определим, в каком формате будут записываться временные
отметки в журнале. По умолчанию маршрутизатор заносит в журнал записи
с временной отметкой uptime. Чтобы изменить это поведение на
стандартный формат date/time, необходимо выполнить следующую
настройку:
Router(config)#service timestamps debug datetime localtime
Router(config)#service timestamps log datetime localtime
Затем определим размер буфера для журнала и уровень важности событий
(severity), которые будут заноситься в журнал и отключим вывод
системных сообщений на консоль, чтобы не перегружать маршрутизатор:
Router(config)#logging buffered 8128 debugging
Router(config)#no logging console
Затем укажем в конфигурации, что нам требуется заносить в журнал
события в случае если аутентификации пользователя была успешной или
произошла ошибка ввода логина/пароля:
Router(config)#login on-failure log
Router(config)#login on-success log
Изменение уровня привелегий пользователя также будем журналирвать:
Router(config)#logging userinfo
Пример вывода сообщений журнала:
Router>enable
Password:
*Mar 1 10:41:18: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 15 by admin on console
Router#disable
*Mar 1 10:41:19: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 1 by admin on console
Неоспоримый интерес для выяснения причин возможных проблем в случае
ошибочной настройки представляет ведение истории команд режима
конфигурации:
!
archive
log config
logging enable
notify syslog
hidekeys
!
Пример вывода сообщений журнала:
*Mar 1 10:41:24: %PARSER-5-CFGLOG_LOGGEDCMD: User:admin logged command:!exec: enable
*Mar 1 10:44:32: %PARSER-5-CFGLOG_LOGGEDCMD: User:admin logged command:arp 172.16.1.110 abcd.1234.8765 arpa
И последним шагом настройки укажем syslog-сервер, на который будем
отправлять сообщения. В качестве транспортного протокола для
наибольшей надежности соединения и гарантии доставки сообщений будем
использовать TCP. Естественно, syslog-сервер должен поддерживать
работу по протоколу TCP. Примером может служить syslog-ng:
Router(config)#logging host 172.16.1.155 transport tcp port 514
Итак, подводя некоторые итоги мы выполнили часть работы по настройке
самого маршрутизатора, настроив безопасную работу его служб,
обеспечили журналирование важных системных событий, ограничили
удаленный доступ к маршрутизатору и задали надежные пароли доступа. В
следующей части статьи мы перейдем к настройке безопасного межсетевого
взаимодействия, защите от DDoS-атак, предотвращению паразитного
трафика, а также к защите от злонамеренного контента и вирусов, в
общем говоря ко всему, что связанно с фильтрацией и файрволлингом
трафика, проходящего через маршрутизатор.
Ссылки:
1. Cisco IOS Security Configuration Guide (http://www.cisco.com)
2. Configuring Secure Shell on Routers and Switches Running Cisco IOS (http://www.cisco.com)
3. Network Management System: Best Practices: White Paper (http://www.cisco.com)
4. Cisco IOS hints and tricks (http://ioshints.blogspot.com)
5. Cisco IOS from an Attacker's Point of View (http://www.hakin9.org)
6. Building Bastion Routers Using Cisco IOS (Phrack Magazine #55)
7. Укрощение дикой киски, или сливаем пароли чемоданами (журнал Xakep #109)
Настраиваем неприступный маршрутизатор. Часть 2
Статья была опубликована в журнале 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
Собственно, теперь требуется применить список доступа к интерфейсу:
(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
!
Пожалуй, если теперь свести все настройки из первой и второй части
статьи, мы получим достаточно безопасную конфигурацию нашего
маршрутизатора, обеспечивающего надлежащий уровень защиты
пользователей и самого себя от различных видов атак. Конечно, полная
безопасность это миф, и даже такая настройка не гарантирует лечение
паранойи, ведь нет предела совершенству. А совершенствоваться
необходимо постоянно и лучшим источником информации для этого,
конечно, является официальная документация, обращайтесь к ней чаще,
ведь множество не менее интересного, хотя и реже используемого
функционала так и осталась за бортом этой статьи. Всего наилучшего.
Ссылки и источники:
1. Cisco IOS Security Configuration Guide
2. Building Bastion Routers Using Cisco IOS
3. http://www.faqs.org/rfcs/rfc1918.html
4. http://www.faqs.org/rfcs/rfc2365.html
