wp.ITACOM.kz дайджест интересного

Отдельная тема: функционал IOS. Чтобы вас не запутать, давайте разделим: IOS для ISR G1 (самых обычных маршрутизаторов 85х, 87х, 18хх, 28хх, 38хх а также их предшественников 26хх, 36хх, 37хх) и IOS для ISR G2 (89х, 19хх, 29хх, 39хх). Для последних есть ТОЛЬКО IOS версии 15.0(1)М и новее. Для старых есть и 12 и 15 версия.

Примечание: версий 12.5, 13 и 14 никогда не было. По легенде, 13 – несчастливое число в США, а 14 – в Японии.
Примечание 2: маршрутизатор 86х хоть и относится формально к G2, о выпущен раньше остальной линейки. Имеет IOS 12.4 и не лицензируется (т.е. работает так же, как G1)

ISR G1:
В версиях до 15 фичи IOSов можно было разделить на несколько типов:
1. Security. Позволяет сделать VPN разного вида, МСЭ, IPS и защитить сам маршрутизатор.
2. Enterprise. Позволяет обрабатывать не только IPv4, например, IPX, CLNP. Раньше только в него включали IPv6. Сейчас этот протокол есть и в Base
3. Unified communications. Всевозможные телефонные фичи, типа CUCM, gateway, gatekeeper и пр.
4. IP Base. Минимальный набор. Даже ip sla нет! Я стараюсь IP Base не оставлять.

Самих IOSов было гораздо больше, т.к. они могли сочетать разные фичи. Подробно узнать, какие возможности есть в каком IOS можно в цискином удобном фича-навигаторе.
_______________
UPD от 3.04.11

Названия линеек IOSов в 12 версии

IP Base
IP Voice
Advanced Security
SP Services
Enterprise Base
Advanced IP Services
Enterprise Services
Advanced Enterprise Services
________________

С 15 версии возможности называются почти так же
1. Security
2. DATA
3. UC
4. Base

15 версия IOS содержит в себе ВСЕ возможности. Для ISR G1 это означает, что можно закачать свежий IOS 15 версии и не бояться. Т-линейка, как и прежде, содержит в себе больше возможностей, но считается менее стабильной.

Зачем же выделять группы фич, если они все доступны? А вот зачем: в ISR G2 внедрена система лицензирования фич, примерно как на ASA. Т.е. залить в ISR G2 другой IOS и получить другой функционал, как привыкли делать в ISR G1, не получится. Нужно покупать лицензии на нужный функционал. Так cisco борется с изобилием «не совсем легальных установок» продвинутого функционала. Ведь IP BASE стоит гораздо дешевле, чем нужный bundle, а значит можно «сэкономить». И хоть формально за это можно пожурить, но если вы не покупали поддержку от cisco (SmartNet), то о факте такой замены никто не узнает.

Дополнительную сложность вносит наше таможенное законодательство, которое ставит табу на ввоз шифровальных средств с длиной ключа более 56 бит (DES еще проходит и так ввозят ASA-K8, а 3DES/AES- нет). Cisco в ответ на эти запреты выпустила локализованную версию IOS, с обрезанным функционалом по шифрованию туннелей. Первой ласточкой была NOVPN для 3845, а для 15 версии IOS такая линейка называется NPE (No Payload Encryption). Такой шаг позволил получить на ISR G2 нотификацию и ввозить на территорию РФ такие циски беспрепятственно (ISR G1 легко ввозятся с IOS IP Base). Однако, лишил нас массы удобных возможностей: IPSec VPN, L2TPoIPSec, SSLVPN, GETVPN, DMVPN, sRTP и других шифровальных возможностей … То, за что многие так уважают цискины маршрутизаторы. Вы можете купить bundle UC, Sec-NPE, DATA, но ни одна из них вам не разблокирует шифрования. И до недавнего времени решения этой проблемы не было: официально купить полноценный IOS (PE) и лицензию на Security, где есть VPN не было…
Но если очень хочется…

Недавно появилась такая возможность: на 12 лет получить «технологические лицензии» на шифрование (SecurityK9, UCk9, DATAk9). Для этого можно сделать так:

1. Найти где-нибудь IOS не NPE, т.е. без NPE в названии, т.е., например, вот такой: c2900-universalk9-mz.SPA.151-3.T.bin.
2. ИОС не ниже версий: 15.0(1)M4, 15.1(1)T2, 15.1(2)T2, 15.1(3)T.
3. Ввести несколько волшебных команд, которые при некоторой настойчивости находятся так:

Ro(config)# license boot ?

и после ввода каждой из строк согласиться с EULA.

Примечание: я намеренно не привожу точных команд, т.к. не знаю, как отреагируют владельцы Хабра на такой «хак»

4. Сохраниться
5. Перезагрузить маршрутизатор, не пугаясь предупреждения, что до конца технологического периода осталось всего ничего: 12 лет :)

Дисклаймер: пользуемся на свой страх и риск. Регуляторы возможно могут придраться, так что готовьте security action plan отката. Возможны подводные камни, о которых я не знаю. Например, один из тестировщиков решения сообщил, что после заливки лицензий и перезагрузки пропала часть команд ip inspect.

http://habrahabr.ru/blogs/cisconetworks/116722/

Static PAT
Сюда же относиться и просто проброс порта, называемый обычно PAT, да и показываемый в по sh xlate тоже РАТ. Используеться в тех случаях когда необходимо обеспечить доступность снаружи только по некоторым портам. Допустим для почтового сервера.

PIX(config)# static (inside,outside) tcp 192.168.100.10 smtp 10.10.10.10 smtp netmask 255.255.255.255

Также может быть полезно в случае, если сервисов больше чем реальных адресов. Ничего не мешает пробросить порт и на веб-сервер.

PIX(config)# static (inside,outside) tcp 192.168.100.10 www 10.10.10.11 www netmask 255.255.255.255

Dynamic
Dynamic NAT
Определяется пул адресов для которых будет проводиться трансляция и пул в которые она будет проводиться.
Трансляция просиходит один к одному, т.е. каждый хост inside хост имеет монопольное право на один адрес из global_IP диапазона. Соответственно если global_IP <>

Определяем, что будем транслировать (real_IP):

PIX(config)# nat (real_ifc) nat_id real_ip [mask]
PIX(config)# nat (inside) 1 10.10.10.0 255.255.255.0

Во что будем транслировать (global_IP):

PIX(config)# global (global_ifc) nat_id global_ip[-global_ip] [netmask global_mask]
PIX(config)# global (outside) 1 192.168.100.20-192.168.100.121

Вот такая нехитрая конфигураци позволяет получить доступ в внешнюю сеть первым 100 хостам из сети 10.10.10.0/24 :)
Зачастую этот тип трансляции используется в том случае если протокол более высокого уровня не поддерживает работу через PAT.

Dynamic PAT
То что в Linux называется маскарадинг. Ситуация когда несколько внутренних хостов используют один, либо несколько, глобальных адресов для выхода в внешнюю сеть..

Определяем, что будем транслировать (real_IP):
PIX(config)# nat (real_ifc) nat_id real_ip [mask]

В данном случае мы будем выпускать “в мир” всё ту же многострадальную сеть – 10.10.10.0/24. Это наши настоящие (real_IP) адреса на интерфейсах внутренних хостов.

PIX(config)# nat (inside) 1 10.10.10.0 255.255.255.0

Транслироваться всё это будет в один адрес global_IP:
PIX(config)# global (outside) 1 192.168.100.130

Однако, зачастую интерфейсов на нашем firewall чем два, возможно остальным тоже необходимо получать доступ?
Добавляем правило трансляции для еще одного интерфейса, необходимо использовать такой же nat-id.

PIX(config)# nat (inside2) 1 10.10.11.0 255.255.255.0

Теперь хосты из двух подсетей 10.10.10.0/24 и 10.10.11.0/24 видны как один адрес 192.168.100.130.

Теперь вполне возможна ситуация, когда лимитов на соединение (около 64 тысяч) будет уже не хватать.
Есть возможность выделить еще несколько адресов для РАТ.
PIX(config)# global (outside) 1 192.168.100.12
PIX(config)# global (outside) 1 192.168.100.13

Есть возможность ипользовать адрес интерфейса, для РАТ трансляции.

PIX(config)# global (outside) 1 interface

Также для определения адресов подлежащих трансляции можно пользоваться acl.
В примере ниже разрешена трансляция адресов сети 10.10.10.0/24 в адрес outside интерфейса с помощью acl в том случае если адрес назначения сеть 10.10.100.0/24

PIX(config)# access-list someflow permit ip 10.10.10.0 255.255.255.0 10.10.100.0 255.255.255.0
PIX(config)# nat (inside) 1 access-list someflow
PIX(config)# global (outside) 1 interface

Это не так очевидно, посему особо отмечу: конфигурация NAT от PAT отличается только способом указания global_IP.В первом случае указывается диапазон, во втором отдельные адреса.
nat-id варьируеться от 1 до 2,147,483,647 т.е. можно использовать разные правила трансляции для различных интерфейсов, PIX/ASA различает их по nat-id.

Policy NAT
Используется в случае необходимости нелинейно транслировать адреса, например в зависимости от адреса назначения. Например адреса внутренней сети 10.10.10.0/24 могут быть транслированы в 192.168.100.12 при обращении к сети 10.11.10.0 и в 192.168.100.13 при обращении к 10.12.10.0

PIX(config)# access-list someflowA permit ip 10.10.10.0 255.255.255.0 10.11.10.0 255.255.255.0
PIX(config)# access-list someflowB permit ip 10.10.10.0 255.255.255.0 10.12.10.0 255.255.255.0
PIX(config)# nat (inside) 1 access-list someflowA
PIX(config)# nat (inside) 2 access-list someflowB
PIX(config)# global (outside) 1 192.168.100.12
PIX(config)# global (outside) 2 192.168.100.13

не-NAT
Псевдонат используется в тех случаях если включен nat-control, который требует, чтобы для пакета проходящего с более защищенного интерфейса на менее защищенный (inside -> outside) существовала трансляция. В противном случае обработка пакета прекращается.

Identity NAT
Команда выглядит следующим образом
PIX(config)# nat (real_ifc) 0 real_ip real_mask

Допустим, что в внутренней сети, например в dmz находиться сервер с реальным адресом на интерфейсе 100.100.100.100.
В данном случае команда будет выглядеть так:

PIX(config)# nat (dmz) 0 100.100.100.100 255.255.255.255

Необходимо обратить внимание на nat-id равный нулю и на отсутствие команды global.
Отмечу также, что в данном случае firewall разрешит только соединения в внешнюю сеть (outbound), inbound соединения будут сброшены.

NAT Exemption
Почти то же самое, что и Identity NAT но соединения разрешены в обе стороны. Настраивается почти так же, единственное отличие – используется acl.

PIX(config)# access-list nonat_from_dmz permit ip 100.100.100.100 255.255.255.255 any
PIX(config)# nat (dmz) 0 access-list nonat_from_dmz

Плюшки
Это не все параметры имеющиеся в арсенале команд nat и static. Полный синтаксис выглядит так:
… [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

norandomseq
Включено по-умолчанию. При каждом новом соединении firewall генерирует случайный initial sequence number (ISN).
Связано это с тем, что tcp/ip стек некоторых ОС использует предсказуемые ISN, что дает возможность злоумышленнику вклиниться в чужую сессию.
Атака носит название TCP hijacking.
PIX/ASA использует оригинальный ISN для поддержания сессис с сгенерировавшим его хостом и переписывает на сгенерированый собственноручно, для общения с хостом назначения.
Протоколы используемые проверку целостности пакетов не смогут работать в таких жестоких условиях. :) Для отключения используется данный параметр.

tcp max_conns и udp udp_max_conns
В принипе из названия всё понятно. Лимиты на количество соединений. Значения по умолчанию равны нулю – отсутствие лимитов.

emb_limit
Удивительно полезная и нужная опция. Позволяет защитить внутренние хосты от syn-flood.
До тех пор пока лимит не достигнут, все новые пакеты (первый syn) перенаправляються оригинальному хосту получателю.
Как только лимит в достигнут firewall перехватывает новые пакеты, с первым syn, и отвечает иницатору соединения с syn-ack.
В случае благополучного завершения тройного рукопожатия,получения ack от инициатора, firewall создает новое соединение с оригинальным хостом назначения.

http://techoover.blogspot.com/2007/12/nat-pixasa.html

Текущее решение.
Итак, как и во втором случае, создаем udp-монитор качества канала, имитирующий G729a кодек (так называемый SLA-монитор).
ip sla 33
udp-jitter 172.16.1.66 49333 source-ip 172.16.1.65 codec g729a codec-size 20
tos 70
threshold 10
Данный монитор будет отправлять 1000 пакетов с интервалом в минуту на порт 49333 у точки назначения, маркировка tos= 70=0×46=EF. На точке назначения должен быть включен
ip sla responder
Далее создаем стабовый трек (создается специально для того, чтобы управлять им с помощью апплетов, а не привязывать жестко к SLA-монитору):
track 20 stub-object
default-state up

Теперь наша задача вынуть результаты из SLA-монитора и по их значениям оставить track 20 в состоянии UP или же положить его. Это можно сделать например с помощью Cisco EEM (Embedded Event Manager), который позволяет отслеживать текущее состояние Вашей железки и выполнять определенные действия.
Для этого создадим два апплета. Один будет класть track в состояние Down, если хотя бы один из параметров (джиттер или число потерь) нас не устраивает. Второй будет поднимать его обратно, если ОБА параметра в норме.

Конфигурация
1. Создаем первый апплет:

event manager applet LB trap
Создаем два события на основе SNMP OID для RTT и jitter От нашего SLA-монитора:
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op ge entry-val “10″ entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op le entry-val “994″ entry-type value poll-interval 4
Здесь последняя цифра 33 в SNMP OID — номер SLA-инстанции. 10 — порог для джиттера (в мс), 994 — минимально допустимое число вернувшихся пакетов из тысячи посланных (1000 — packet_loss). poll-interval — интервал с которым кошка опрашивает состояние значений. Здесь 4с.
Указываем, что наш апплет должен сработать при ЛЮБОМ из событий, т.е. используется логическое ИЛИ.
trigger
correlate event loss or event jitter
Далее действие:
action 20 track set 20 state down
Т.е. наш трек укладывается в состояние Down.

Второй апплет аналогично:

event manager applet LB2 trap
event tag jitter snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.46.33 get-type exact entry-op lt entry-val “10″ entry-type value poll-interval 4
event tag loss snmp oid 1.3.6.1.4.1.9.9.42.1.5.2.1.1.33 get-type exact entry-op gt entry-val “994″ entry-type value poll-interval 4
trigger
correlate event loss and event jitter
action 20 track set 20 state up

Только апплет срабатывает по логическому И между событиями. И трек взводится в состояние Up.

Видно, что опрос происходит с интервалом 4с и текущее состояние трека не учитывается, т.е. трапы срабатывают постоянно, раз в 4с. Я пытался прикрутить еще мониторинг состояния самого трека, но работало очень глючно, срабатывало не всегда. Так что я пожертвовал парой процентов проца и оставил так.

Дополнительно есть еще апплеты, информирующие меня о проблемах на канале и их исчезновении:

event manager applet LB_info
event syslog pattern “20 stub Up->Down”
action 10 syslog msg “applet works!”
action 11 cli command “enable”
action 12 cli command “show ip sla stat 33″
action 13 mail server “192.168.6.20″ to “ilya@tut_domen.ru” from “alert@tut_domen.ru” subject “Frame loss or high jitter on NiS channel” body “$_cli_result”
и
в переменной $_cli_result содержится результат вывода последней команды, т.е. в нашем случае — show ip sla stat 33.

event manager applet LB2_info
event syslog pattern “20 stub Down->Up”
action 10 syslog msg “applet 2 works!”
action 11 cli command “enable”
action 12 cli command “show ip sla stat 33″
action 13 mail server “192.168.6.20″ to “ilya@tut_domen.ru” from “alert@tut_domen.ru” subject “NiS channel is correct” body “$_cli_result”

Другими словами, мы шлем себе письмо, в теле которо – результат последнего запуска SLA-монитора, собственно и вызвавшего переключение трека.

Так, теперь собственно как это учитывать. Я вижу два способа:

1. строчка в route-map (как и работает у меня, собственно, но там просто схема хитрая)
set ip next-hop verify-availability 172.16.1.66 1 track 20
2. трекинг статики, когда у нас есть маршрут вида
ip route 172.16.0.0 255.255.255.0 192.168.1.1 track 20
При потерях или джиттере на канале данный маршрут просто уберется из таблицы маршрутизации и трафик пойдет по альтернативному пути.

Может и коряво, но я промучившись неделю лучше ничего не придумал. Чем богаты, как говорится.

P.S. Я подразумеваю, что читатель немного знаком с основами консоли Cisco
P.P.S. Синтаксис ip sla команд разнится на 12.4Т и 12.4, но смысл такой же.
P.P.S. Если требуется пояснения, не выходящие за границу нескольких строк — пишите, добавлю.

С уважением, Подкопаев Илья
источник: http://habrahabr.ru/blogs/cisconetworks/108519/

C2970#vlan data
C2970(vlan)#vlan 10 name OurNet
VLAN 10 added:
Name: OurNet
C2970(vlan)#vlan 12 name ISP1
VLAN 12 added:
Name: ISP1
C2970(vlan)#vlan 14 name ISP2
VLAN 13 added:
Name: ISP2
C2970-Servers(vlan)#exit
APPLY completed.
Exiting….
C2970#

Порт номер 1 принадлежит Vlan’у 12 -ISP1, порт 2 принадлежит Vlan’у 14 (ISP2), третий порт транковый — для рутера, остальные порты принадлежат Vlan’у 10 — наша внутренняя сеть.

interface FastEthernet0/1
description -=I=- ISP1 -=I=-
switchport access vlan 12
switchport mode access
no cdp enable

interface FastEthernet0/2
description -=I=- ISP2 -=I=-
switchport access vlan 14
switchport mode access
no cdp enable

interface FastEthernet0/3
description -=I=- RTR -=I=-
switchport mode trunk
no mdix auto

interface FastEthernet0/4
switchport access vlan 10
switchport mode access
no cdp enable
…
interface FastEthernet0/24
switchport access vlan 10
switchport mode access
no cdp enable

С коммутацией разобрались переходим к нашему рутеру, у меня за пример взят Cisco 2811 с иосом c2800nm-adventerprisek9_ivs-mz.124-24.T1.bin (хотя будет работать и на другом рутере с другим ИОС’ом)

Настроим интерфейсы:

interface FastEthernet0/0
no ip address
duplex auto
speed auto
no cdp enable
!
interface FastEthernet0/0.12
description -=I=- Internet over ISP1 -=I=-
encapsulation dot1Q 12
ip address 164.122.12.9 255.255.255.248
ip access-group ACL_INET_OUT_ISP1 out
ip nat outside
ip virtual-reassembly
no cdp enable
!
interface FastEthernet0/0.14
description -=I=- Internet over ISP2 -=I=-
encapsulation dot1Q 14
ip address 122.164.8.17 255.255.255.248
ip access-group ACL_INET_OUT_ISP2 out
ip nat outside
ip virtual-reassembly
no cdp enable
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.10
description to -=I=- LAN -=I=-
encapsulation dot1Q 10
ip address 10.10.10.200 255.255.255.0
ip nat inside
ip virtual-reassembly
no cdp enable

Настроим пулы для NAT’а:
ip nat pool ISP1-PUBLIC-IP 164.122.12.9 164.122.12.9 netmask 255.255.255.248
ip nat pool ISP2-PUBLIC-IP 122.164.8.17 122.164.8.17 netmask 255.255.255.248

Акцесс-листы (ACL):
ACL’и для интерфейсов, чтобы никто не прорвался :)
ip access-list extended ACL_INET_OUT_ISP1
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
permit ip host 164.122.12.9 any
deny ip any any log-input

ip access-list extended ACL_INET_OUT_ISP2
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
permit ip host 122.164.8.17 any
deny ip any any log-input

ACL’и для тех кто в сети:
ip access-list extended ACL_NAT-INET_OUT_ISP1
remark /————————————–
remark Black Hole RFC 1918
remark ————————————–/
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
remark /————————————–
remark SMTP For Exchange
remark ————————————–/
permit tcp host 10.10.10.254 any eq smtp
deny tcp any any eq smtp log-input
remark /————————————–
remark WSUS
remark ————————————–/
permit ip host 10.10.10.251 any
remark /————————————–
remark Full Aceess for Odmins
remark ————————————–/
permit ip host 10.10.10.10 any
remark /————————————–
remark Access for Exchange
remark ————————————–/
permit ip host 10.10.10.254 any
remark /————————————–
remark Deny SMTP for TI (gate)
remark ————————————–/
deny tcp host 10.10.10.249 eq smtp any log-input
remark /————————————–
remark Access to Internet for TI (gate)
remark ————————————–/
permit ip host 10.10.10.249 any
remark /————————————–
remark Self
remark ————————————–/
permit ip host 164.122.12.9 any
remark /————————————–
remark Deny All
remark ————————————–/
deny ip any any log-input

ip access-list extended ACL_NAT-INET_OUT_ISP2
remark /————————————–
remark Black Hole RFC 1918
remark ————————————–/
deny ip any 10.0.0.0 0.255.255.255 log-input
deny ip any 172.16.0.0 0.15.255.255 log-input
deny ip any 192.168.0.0 0.0.255.255 log-input
remark /————————————–
remark SMTP For Exchange
remark ————————————–/
permit tcp host 10.10.10.254 any eq smtp
deny tcp any any eq smtp log-input
remark /————————————–
remark WSUS
remark ————————————–/
permit ip host 10.10.10.251 any
remark /————————————–
remark Full Aceess for Odmins
remark ————————————–/
permit ip host 10.10.10.10 any
remark /————————————–
remark Access for Exchange
remark ————————————–/
permit ip host 10.10.10.254 any
remark /————————————–
remark Deny SMTP for TI (gate)
remark ————————————–/
deny tcp host 10.10.10.249 eq smtp any log-input
remark /————————————–
remark Access to Internet for TI (gate)
remark ————————————–/
permit ip host 10.10.10.249 any
remark /————————————–
remark Self
remark ————————————–/
permit ip host 122.164.8.17 any
remark /————————————–
remark Deny All
remark ————————————–/
deny ip any any log-input

Route-map:
route-map NAT-TO-ISP1 permit 10
description -= Routing/NAT to ISP1, outgoing traffic =-
match ip address ACL_NAT-INET_OUT_ISP1
match interface FastEthernet0/0.12
!
route-map NAT-TO-ISP2 permit 10
description -= Routing/NAT to ISP2, outgoing traffic =-
match ip address ACL_NAT-INET_OUT_ISP2
match interface FastEthernet0/0.14

И вот теперь самое интересное — трекинг:

track 100 list boolean and
object 101
object 102
object 103
object 104
delay down 2 up 3
!
track 101 interface FastEthernet0/0.12 line-protocol
delay down 2 up 5
!
track 102 interface FastEthernet0/1 line-protocol
delay down 2 up 5
!
track 103 ip route 164.122.12.9 255.255.255.248 reachability
delay down 2 up 5
!
track 104 ip sla 104
delay down 2 up 5
!
track 200 list boolean and
object 201
object 202
object 203
object 204
delay down 2 up 3
!
track 201 interface FastEthernet0/0.14 line-protocol
delay down 2 up 5
!
track 202 interface FastEthernet0/1 line-protocol
delay down 2 up 5
!
track 203 ip route 122.164.8.17 255.255.255.248 reachability
delay down 2 up 5
!
track 204 ip sla 204
delay down 2 up 5

и маршруты:

ip route 0.0.0.0 0.0.0.0 164.122.12.9 10 tag 100 name -=[ISP1]=- track 100
ip route 0.0.0.0 0.0.0.0 122.164.8.17 20 tag 200 name -=[ISP2]=- track 200

а теперь собственно то, чем мы проверяем доступность наших шлюзов:

ip sla 104
icmp-echo 164.122.12.9 source-interface FastEthernet0/0.12
request-data-size 1
timeout 700
threshold 600
frequency 30
ip sla schedule 104 life forever start-time now
ip sla 204
icmp-echo 122.164.8.17 source-interface FastEthernet0/0.14
request-data-size 1
timeout 700
threshold 600
frequency 30
ip sla schedule 204 life forever start-time now

источник: http://habrahabr.ru/blogs/personal/70801/

Базовая конфигурация

configuration mode exclusive auto expire 600
hostname RT-SEC

no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime msec
service timestamps log datetime msec localtime show-timezone year
service password-encryption
service sequence-numbers
no service dhcp

logging buffered 64000 informational
logging persistent url flash:/LOG size 4096000 filesize 64000
no logging console
no logging monitor
logging origin-id hostname
logging source-interface Loopback0
logging count
logging x.x.x.x
logging y.y.y.y

aaa new-model
aaa local authentication attempts max-fail 10
aaa authentication login default local
aaa authentication enable default enable
aaa authorization console
aaa authorization exec default local
username user privilege 1 secret 5
username admin privilege 15 secret 5
enable secret 5

no ip source-route
ip options drop
ip cef
ip dhcp bootp ignore
no ip bootp server
no ip domain lookup

memory reserve critical 16000

secure boot-image
warm-reboot count 10
archive
log config
logging enable
logging size 1000
hidekeys
path flash:/ARCHIVE/config
write-memory

no ip http server
no ip http secure-server
no cdp run

Терминал
line con 0
exec-timeout 60 0
logging synchronous
transport preferred none
transport output none
line aux 0
exec-timeout 60 0
logging synchronous
transport preferred none
transport output none
line vty 0 n
no exec
transport input none
transport output none

Интерфейсы

interface Null0
no ip unreachables

interface Loopback0
no ip redirects
no ip unreachables
no ip proxy-arp

interface FastEthernet1/0
no ip redirects
no ip proxy-arp
no mop enabled
no cdp enabled

NTP (синхронизация времени)
ntp authentication-key 1 md5 7
ntp authenticate
ntp trusted-key 1
ntp source Loopback0
ntp update-calendar
ntp server x.x.x.x key 1
ntp server y.y.y.y key 1

Базовая конфигурация CPPr от DOS аттак

CCPr (http://www.cisco.com/web/about/security/intelligence/understanding-cppr.html )

Конфигурация рассмотренная ниже подходит для IOS версии 12.4.15T

class-map match-any CPPR_HOST_CRITICAL
match protocol bgp
class-map match-any CPPR_HOST_ICMP
match protocol icmp
class-map match-any CPPR_HOST_NORMAL
match protocol ntp
match protocol ssh
match protocol sntp
class-map match-any CPPR_HOST_IP
match protocol ip
class-map match-any CPPR_TRANSIT_CRITICAL
match protocol ospf
match protocol bgp
class-map match-any CPPR_TRANSIT_IP
match protocol ip
class-map match-any CPPR_CEF-EXCEPTION_CRITICAL
match protocol arp
class-map match-any CPPR_CEF-EXCEPTION_IP
match protocol ip

policy-map CPPR_HOST
class CPPR_HOST_CRITICAL
class CPPR_HOST_ICMP
police 128000
class CPPR_HOST_NORMAL
police 512000
class CPPR_HOST_IP
drop

policy-map CPPR_TRANSIT
class CPPR_TRANSIT_CRITICAL
class CPPR_TRANSIT_IP
police 512000
policy-map CPPR_CEF-EXCEPTION
class CPPR_CEF-EXCEPTION_CRITICAL
class CPPR_CEF-EXCEPTION_IP
police 512000

control-plane host
service-policy input CPPR_HOST
control-plane transit
service-policy input CPPR_TRANSIT
control-plane cef-exception
service-policy input CPPR_CEF-EXCEPTION

источник: http://faq-cisco.ru/statji/statji/shablony-bezopasnosti-dlja-marshrutizatorov-cisco.html