|
|
Страница 1 из 1
|
[ Сообщений: 22 ] |
|
CiscoExpo 2009: задачка про ASA
Автор |
Сообщение |
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24 Сообщения: 4434
|
На самом деле задачка практически только про NAT. На СЕ2009 её никто не решил сам. _____________________________________________________________________________ Пусть в сети есть ОФИС и ЦОД. Между ними куплена выделенная линия. Все ресурсы сосредоточены в ЦОД и в нормальном состоянии сети все пакеты из ОФИСа в Интернет должны ходить через интерфейс DMZ, ведущий прямо в ЦОД (канал должен полностью шифроваться). Адреса источника должны оставаться неизменными. В случае падения выделенной линии пакеты из ОФИСа в ЦОД и далее в Интернет должны попадать в зашифрованный IPSec канал через Интернет до ЦОДа. Для этого у ОФИСа есть свой выход в Интернет. Исключение составляет лишь хост 192.168.1.100, которому в случае падения выделенной линии необходимо предоставлять прямой выход в Интернет, используя адрес интерфейса outside ASA ОФИСа, но сохранив для него возможность работать с сетью ЦОДа (10.1.0.0/16) через шифрованный канал. Дополнительно, для защиты от DoS атак на IPSec необходимо запретить ASA ОФИСа обрабатывать пакеты IPSec от всех, кроме адреса интерфейса outside ASA ЦОД. Ваша задача состоит в том, чтобы предоставить конфиг ASA ОФИСа. Достаточно предоставить : 1. Описание «интересного трафика» для каналов IPSec 2. Описание правил трансляции NAT 3. Способ защиты от DoS атак на IPSec ______________________________________________________________________________ Я уверен, что вы её решите, поэтому усложню: Решите её в двух вариантах: А) no nat-control B) nat-control И желательно объяснить, почему именно так
Вложения:
SNAF.jpeg [ 16.2 КБ | Просмотров: 51748 ]
|
15 окт 2009, 09:13 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
ОФИС - sla tracker на цодовскую next-hop асу в DMZ. Крипто мапа - ОФИС - any
В случае падения trackera -> статик через аутсайд, Криптомапа на аутсайд ( match addreess ) для хоста 192.168.1.100 -> сеть ЦОД: пермит для того же хоста -> any ( 2ой статйтмент в acl ) -> deny сеть офица -> any permit
ну и нат 0 inside-dmz match acl... для нат 0 inside-outside : хост 192.168.1.100 -> ЦОД: пермит same host -> any : deny ( ибо тогда в интерфейс нат не сработает без этого, так как нат 0 самым первым проверяется ) office lan -> цод - permit
нат 1 - host 1.100 -> interface
я б так решил
|
15 окт 2009, 09:57 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
ddos protection: хмм нет асы с 8.04, а в предыдуших бага, но скорее всего permit esp, udp 500&4500 только от адреса ЦОДа outside в access-group control plane на интерфейсе оутсайд АСЫ в офисе
|
15 окт 2009, 09:59 |
|
|
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24 Сообщения: 4434
|
nat 0 нельзя сделать на ПАРУ интерфейсов. Он только один и пишется nat (inside) 0 ... Так что не получится. Мало того, IPSec с deny - не оч. хорошая идея. Подумай ещё Напиши прямо командами ЗЫ Впрочем, я не сомневаюсь, что ты её решишь. Можешь пока не писать - дай другим подумать
|
15 окт 2009, 10:06 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
с наскоку не получилось :) все таки придеться собрать походу стендик :) почему с deny плохая идея ?
|
15 окт 2009, 10:14 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
про нат 0 даже стыдно как то, что в попехах забыл :(
|
15 окт 2009, 10:16 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
не уж то статик Оо
|
15 окт 2009, 10:46 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
Кстати, а можно задачку про роутер и свитч и вланы кинуть, у меня на ней клин случился :)) я хз как ее легко сделать, а условие забыл ( что можно настраивать из оборудования и где что идет )
|
15 окт 2009, 10:54 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
понял, как без deny в crypto map . Забыл порядок обработки пакетов :)))
|
15 окт 2009, 11:13 |
|
|
siv
Зарегистрирован: 02 июн 2009, 14:42 Сообщения: 231
|
Предлагаю мой вариант решения задачи. Он кажется корявым, поскольку завязан на маршрутизацию, но должен работать как с nat-control, так и без него.
1. Crypto ACL
access-list VPN_DMZ extended permit ip 192.168.1.0 255.255.255.0 10.1.0.0 255.255.0.0 access-list VPN_outside extended permit ip 192.168.1.0 255.255.255.0 10.1.0.0 255.255.0.0
2. NAT + Routing
access-list HOST_COD extended permit ip host 192.168.1.100 10.1.0.0 255.255.0.0
nat-control global (outside) 10 interface nat (inside) 10 192.168.1.100 255.255.255.255 nat (inside) 0 192.168.1.0 255.255.255.0 static (inside,outside) 192.168.1.100 access-list HOST_COD static (inside,DMZ) 192.168.1.100 access-list HOST_COD
route DMZ 0.0.0.0 0.0.0.0 <DMZ next hop> 1 route outside 0.0.0.0 0.0.0.0 <outside next hop> 200 route DMZ 10.1.0.0 255.255.0.0 <DMZ next hop> 1 route outside 10.1.0.0 255.255.0.0 <outside next hop> 200
3. AntiDOS
access-list antiDOS extended permit udp host outside_COD host outside_OFFICE eq isakmp access-list antiDOS extended permit esp host outside_COD host outside_OFFICE access-list antiDOS extended deny udp any host outside_OFFICE eq isakmp access-list antiDOS extended deny esp any host outside_OFFICE
|
17 окт 2009, 14:20 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
Серег, а комменты мне можно писать ?:)
|
17 окт 2009, 14:27 |
|
|
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24 Сообщения: 4434
|
2 Hando: без сомнения ) 2 siv: не сработает. nat (inside) 0 не транслирует 192.168.1.0/24, а значит и 192.168.1.100. В этом и есть загвоздка. Её решить можно 3 или даже 4 способами.
|
17 окт 2009, 19:10 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
Тогда по порядку, попробую без явных указаний как делать , чтоб сохранить интерес: "1. Crypto ACL access-list VPN_DMZ extended permit ip 192.168.1.0 255.255.255.0 10.1.0.0 255.255.0.0 access-list VPN_outside extended permit ip 192.168.1.0 255.255.255.0 10.1.0.0 255.255.0.0" Трафик в интернет не шифруется По поводу ната 1st lil hint: http://www.cisco.com/en/US/docs/securit ... #wp1079279nat 0 транслирует только в одну сторону, соотв из ЦОДа попасть в офис не смогут ( я думаю условие задачи подразумевает, что ipsec с любой стороны можно строить ) "route DMZ 0.0.0.0 0.0.0.0 <DMZ next hop> 1 route outside 0.0.0.0 0.0.0.0 <outside next hop> 200 route DMZ 10.1.0.0 255.255.0.0 <DMZ next hop> 1 route outside 10.1.0.0 255.255.0.0 <outside next hop> 200" маршруты с метрикой 1 упадут только в случае, если интерфейс потеряет carier, допустим между АСАшками стоит свитч ( или например оборудование провайдера, реализующие pseudowire чтоб соединить 2 площадки ) - соотв если у одной сдохнет интерфейс, маршруты на второй так и останутся активными ( тк интерфейс не опуститься в down )
|
17 окт 2009, 19:34 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
2 Fedia: так почему же deny в crypto acl !TRUE ?
|
17 окт 2009, 19:36 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
я б кстати в условие задания добавил бы настройку АСЫ в DC - как ее настроить, чтоб пакеты и офиса транслировались и нормально уходили в интернет, когда упадет выделенный канал, и ipsec c DC будет строится через интернет
|
17 окт 2009, 19:39 |
|
|
siv
Зарегистрирован: 02 июн 2009, 14:42 Сообщения: 231
|
To Hando: Маршруты можно сконфигурировать с трэкингом, так что если между асами будет стоять свич, что маршруты всё равно упадут - это сделать не проблема. По поводу моего решения - я решал задачу из расчёта, что сессии устанавливаются из офиса в ЦОД, а не наоборот. IPsec не всегда предполагает, что сессии устанавливаются в двустороннем порядке - в задаче про это ничего не сказано.
To Fedia: " 2 siv: не сработает. nat (inside) 0 не транслирует 192.168.1.0/24, а значит и 192.168.1.100. В этом и есть загвоздка. "
Но у меня же сконфигурирован nat (inside) 10 192.168.1.100 255.255.255.255 и global (outside) 10 interface, и следовательно 192.168.1.100 по нат 0 не уйдёт (а уйдёт по 10 строке) - в правилах сказано, что когда дело доходит до nat - поиск идёт по наиболее длинному соответствию. Это я проверял на живом железе.
|
17 окт 2009, 21:32 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
нет правила проверки ната: exempt nat ( nat 0 with acl ) static nat ( also nat 0 with ip addr; 1st match ) dynamic policy nat dynamic nat ( вот тут только longest match )
соотв nat 10 у вас никогда не заработает ( а если nat 0 не поставить в конец списка статик натов, то и статик для хоста несработает )
|
17 окт 2009, 21:39 |
|
|
siv
Зарегистрирован: 02 июн 2009, 14:42 Сообщения: 231
|
Привожу тогда описание с циски: *** Order of NAT Commands Used to Match Real Addresses The adaptive security appliance matches real addresses to NAT commands in the following order: 1. NAT exemption (nat 0 access-list)—In order, until the first match. Identity NAT is not included in this category; it is included in the regular static NAT or regular NAT category. We do not recommend overlapping addresses in NAT exemption statements because unexpected results can occur. 2. Static NAT and Static PAT (regular and policy) (static)—In order, until the first match. Static identity NAT is included in this category. 3. Policy dynamic NAT (nat access-list)—In order, until the first match. Overlapping addresses are allowed. 4. Regular dynamic NAT (nat)—Best match. Regular identity NAT is included in this category. The order of the NAT commands does not matter; the NAT statement that best matches the real address is used. For example, you can create a general statement to translate all addresses (0.0.0.0) on an interface. If you want to translate a subset of your network (10.1.1.1) to a different address, then you can create a statement to translate only 10.1.1.1. When 10.1.1.1 makes a connection, the specific statement for 10.1.1.1 is used because it matches the real address best. We do not recommend using overlapping statements; they use more memory and can slow the performance of the adaptive security appliance. http://www.cisco.com/en/US/docs/securit ... rview.html*** У меня написан полиси нат статик (т.е. пункт 2 правил) -> работает он только тогда, когда хост 192.168.1.100 идёт в сеть ЦОДа. В остальных случаях статик не работает. Идём дальше: есть строчки nat 0 и nat 10 без ACL -> это пункт 4 правил, как раз в нём и написано, что identity nat (т.е. nat 0) включен в этот пункт, но когда хост 192.168.1.100 будет лезть в интернет, то будет работать правило nat 10 как наиболее подходящее, а nat 0 будет работать для всех остальных хостов из сети 192.168.1.0. Хотя, конечно, получаются перекрывающиеся строки, что циска не рекомендует, но это не означает, что оно работать не будет. З.Ы. Я бы так не упирался, если бы не проверил всё на железе. Понимаю, что вариант решения не единственный - у меня в голове ещё как минимум 1 есть, просто команды нужно написать. Этот вариант я отстаиваю уже просто из интереса.
|
17 окт 2009, 23:50 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
My bad: сам линк на это кидал, сам его то до конца и не дочитал :)
|
18 окт 2009, 00:00 |
|
|
Hando
Зарегистрирован: 21 июл 2009, 13:59 Сообщения: 565 Откуда: Moscow
|
c exempt проще логика : deny host ; permit сеть в nat 0; а хост статиками добиваем на DMZ & Outside ( во втором случае identity static чтоб ток в 10 сеть), а в конце dynamic
|
18 окт 2009, 00:03 |
|
|
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24 Сообщения: 4434
|
2 siv: я приношу свои извинения. ВОт что значит "давно работать с оборудованием" - где то упустил что то и накрепко запомнил. Я всю жизнь приравнивал по приоритету nat 0 access-l и просто nat 0 Завтра обязательно соберу стенд и оттестирую, ибо не люблю оставлять пробелы Впрочем, скорее всего я когда то сталкивался с жестокими глюками в случае использование топологий, которые циска мягко "не рекомендует". Оттуда и ноги растут. Я предпочитаю более надёжный способ: nat 0 c ACL, он всегда на интерфейсе один, все, что туда попадать не должно - deny.
|
18 окт 2009, 21:38 |
|
|
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24 Сообщения: 4434
|
Резюмируем:
Вариант no nat-control
В этом варианте не надо описывать то, что не транслируется, поэтому трафик в сторону DMZ можно не учитывать вовсе. Осталось разобраться с хостом 192.168.1.100
Это можно сделать например так: access-list NONAT100 permit h 192.168.1.100 10.1.0.0 255.255.0.0 nat (inside) 0 access-l NONAT100 nat (inside) 1 192.168.1.100 global (outside) 1 int
Вариант nat-control
Тут сложнее, потому что надо явно описать тот трафик, который не надо транслировать. Такой вариант (сам просится) использовать нельзя access-l WRONG perm ip 192.168.1.0 255.255.255.0 any nat (inside) 0 access-l WRONG
т.к. nat 0 отработает в сторону и dmz и outside интерфейсов и до трансляции 192.168.1.100 дело не дойдёт
Поэтому есть несколько вариантов.
В лоб. Работает всегда: описываем тот трафик, который никогда не транслируем access-list NONAT perm ip h 192.168.1.100 10.1.0.0 255.255.0.0 access-list NONAT deny ip h 192.168.1.100 255.255.255.0 any access-list NONAT perm ip 192.168.1.0 255.255.255.0 any
nat (inside) 0 access-l NONAT для nat 0 допускаются строчки deny в ACL
deny для nat 0 говорит, чтобы циска дальше искала правила трансляций. Нам необходимо странслировать 192.168.1.100 в outside nat (inside) 1 192.168.1.100 global (outside) 1 int и в dmz static (inside,dmz) 192.168.1.100 192.168.1.100
еще вариант - применить военную хитрость: между интерфейсами с одинаковым security level осуществляется маршрутизация, даже если включен nat-control!
int e0/1 sec 100 nameif inside
int e0/2 sec 100 nameif dmz
same-security-traffic permit inter-interface Теперь трафик в dmz пойдет и без правила nat 0 и осталось описать только правила для outside
access-list NONAT perm ip h 192.168.1.100 10.1.0.0 255.255.0.0 access-list NONAT deny ip h 192.168.1.100 255.255.255.0 any access-list NONAT perm ip 192.168.1.0 255.255.255.0 any nat (inside) 0 access-l NONAT
Т.к. шифрование происходит после НАТа, для IPSec достаточно написать один ACL
access-l IPSEC perm ip 192.168.1.0 255.255.255.0 any
Без сомнения есть ещё варианты: с использованием некрасивого ACL, исключающего 192.168.1.100 без строчек deny (так имело смысл делать для ОС 6), можно использовать policy static хоста 192.168.1.100 в себя при проходе в сеть 10.1.0.0/16
|
21 окт 2009, 22:26 |
|
|
|
Страница 1 из 1
|
[ Сообщений: 22 ] |
|
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1 |
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
|
|
|