отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Traceroute over ASA5505

Доброго дня!

Имеется Cisco ASA5505

version 9.0(2)

Появилось несколько вопорсов:

1. Traceroute работает при определённых настройках в правилах, в частности, вот такая строчка позволяет трейсиьт внешнии хосты из внутренней сети:

access-list global_access extended permit icmp any4 any4

Однако если поменять на вот такую:

access-list global_access extended permit icmp object-group InеNets any4

то уже нет (в данном случае InеNets - группа внутренних сетей ip4 и не более). В консоли тогда вместо ответов от промежуточных хостов появляются звёздочки аля:

3     *        *        *     Request timed out.

4     *        *        *     Request timed out.

и в логе запись вида:

Deny icmp src outside:x.x.x.x dst inside:10.0.0.x (type 11, code 0) by access-group "global_access" [0x0, 0x0]

Собственно не могу поняьт почему так происходит? АСА во втором случае воспринимает ответ как пакет от внешнего хоста и отбрасывает его?

В конфиге присутствует необходимый инспекшен:

policy-map global_policy

class inspection_default

  ....

  inspect icmp

  ....

2.  В рабочем варианте трейса у меня почему то сама cisco asa отсутствует в списке как один из промежутчных узлов - так и должно быть!?

3. Через ASDM или туже консоль можно напрямую сделать ping\traceroute прямо с cisco - вопрос: надо ли спец.правилами открываьт доступ такому трафику наружу с самого девайса или нет?

1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения

Re: Traceroute over ASA5505

Попробуйте заодно включить inspect icmp error. Сейчас в трассировке виден только последний хоп, но не те, что между ним и асой?

По TTL - маленький security through obscurity в дополнение к основным средствам защиты еще никому не мешал Если файрвол никак не выдает своего присутствия помимо тихого уничтожения неразрешенных пакетов - его сложнее атаковать, да и вообще понять, что же такое происходит и почему теряются пакеты.

По пакетам с самого файрвола - проще всего посмотреть, как подобные запросы отмечаются в логах, и под них подстраиваться. Как оно должно быть с глобальными ACLями - не знаю, навскидку тоже не нашел. Возможно, нужно будет сделать permit на трафик с адреса асы. Об обратном трафике в теории должен позаботиться инспект.

14 ОТВЕТ.

Traceroute over ASA5505

1. Трассировку пускаете с *NIX или с Windows?

В каком направлении и к какому интерфейсу применен ACL global_access? Inside out?

Соберите лог, когда стоит "permit any4 any4" и попытки успешны.

2. Она по умолчанию не снижает TTL, потому от нее пакет не отскакивает. Если хотите исправить - в inspection-default (или еще где) пропишите "set connection decrement-ttl"

3. Вероятно, на ACLe, висящем на outside в направлении in, надо будет дописать permit.

New Member

Re: Traceroute over ASA5505

Dmitriy Zhiznevskiy wrote:

1. Трассировку пускаете с *NIX или с Windows?

протокол ICMP как транспортный для traceroute (с UDP ещё не возился)

В каком направлении и к какому интерфейсу применен ACL global_access? Inside out?

У меня аксес листы (правли фильтрации) только глобальные (global) без привязки к интерфейсу аля:

access-list global_access extended permit any4 object-group IneNets eq https

access-group global_access global


2. Она по умолчанию не снижает TTL, потому от нее пакет не отскакивает. Если хотите исправить - в inspection-default (или еще где) пропишите "set connection decrement-ttl"

Понятно, т.е. это по умолчанию так. (А для чего? Безопастность?)

3. Вероятно, на ACLe, висящем на outside в направлении in, надо будет дописать permit.

Только на вход? А на выход? Сам девайс как представлен в системе фильтрации пакетов? Только интерфейсами - т.е. если надо что бы с дефолтного интерфейса внешнего выходили пинги теже надо открывать доступ с внешнего ip циски наружу? Я просто из документации не совсем понял как циска представлена сама в цепочки фильтрации пакетов (если она сама генерит трафик) - только интерфейсами получается с соот-м source\destination адресами этих интерфейсов?)

За ответы в любом случае спасибо!

Re: Traceroute over ASA5505

Попробуйте заодно включить inspect icmp error. Сейчас в трассировке виден только последний хоп, но не те, что между ним и асой?

По TTL - маленький security through obscurity в дополнение к основным средствам защиты еще никому не мешал Если файрвол никак не выдает своего присутствия помимо тихого уничтожения неразрешенных пакетов - его сложнее атаковать, да и вообще понять, что же такое происходит и почему теряются пакеты.

По пакетам с самого файрвола - проще всего посмотреть, как подобные запросы отмечаются в логах, и под них подстраиваться. Как оно должно быть с глобальными ACLями - не знаю, навскидку тоже не нашел. Возможно, нужно будет сделать permit на трафик с адреса асы. Об обратном трафике в теории должен позаботиться инспект.

New Member

Re: Traceroute over ASA5505

Dmitriy Zhiznevskiy wrote:

Попробуйте заодно включить inspect icmp error. Сейчас в трассировке виден только последний хоп, но не те, что между ним и асой?

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

class inspection_default

  ....

  inspect icmp

  inspect icmp error

  ....

Собственно это и вызвало вопрос т.к. по идее обратный "коннект" разрешён и ответные icmp сообщения должы парситься и разрешаться ...

Да, если включить как было изначально - только последний хоп. Если включить:

access-list global_access extended permit icmp any4 any4

То всё видно (за исключением самой циски)

По TTL - маленький security through obscurity в дополнение к основным средствам защиты еще никому не мешал Если файрвол никак не выдает своего присутствия помимо тихого уничтожения неразрешенных пакетов - его сложнее атаковать, да и вообще понять, что же такое происходит и почему теряются пакеты.

понял, спасибо

По пакетам с самого файрвола - проще всего посмотреть, как подобные запросы отмечаются в логах, и под них подстраиваться. Как оно должно быть с глобальными ACLями - не знаю, навскидку тоже не нашел. Возможно, нужно будет сделать permit на трафик с адреса асы. Об обратном трафике в теории должен позаботиться инспект.

Вот у меня тоже мысль что надо внешнии ip интерфейсов брать и ими оперировать, есдинственный нюанс возникакет вроде: вот взять мой конфиг - у меня внешний дефолтный интерфейс циски и внешний натащий ip для циски один и тот же. В логах по идее трафик будет исходящим висеть с этого внешнего ip в обоих случаях - что идёт коннект с циски самой что с внутренней сети... Как там разобрать что инициировало коннект - acl по идее разбираться не будет - удовлетворяет критериям пакет - и в топку...

Re: Traceroute over ASA5505

Ну тогда правильнее всего по всем вопросам смотреть логи - открытие ICMP соединения, создание NAT трансляции, и от них плясать.

New Member

Re: Traceroute over ASA5505

Вобщем поигрался с правилами, вот такая пара правил работает:

access-list global_access extended permit icmp object-group IneNets any4

access-list global_access extended permit icmp any4 object-group IneNets time-exceeded

Т.е. почему то надо задавать напрямую разрешающее правило для обратного прохождения пакета "icmp time-exceeded" хотя по идее первой строчки должно хватать и циска сама должна "парсить" обратные пакеты при включенных опциях:

inspect icmp

inspect icmp error

Или не должна?

Re: Traceroute over ASA5505

А можете показать логи, относящиеся к созданию и завершению соединений, а также к дропу пакетов, про которые мы говорим?

В теории, ASA создает исходящее соединение, и должно пропустить ответный по нему ICMP time exceeded. Странно.

New Member

Re: Traceroute over ASA5505

Dmitriy Zhiznevskiy wrote:

А можете показать логи, относящиеся к созданию и завершению соединений, а также к дропу пакетов, про которые мы говорим?

4|Feb 25 2014|11:21:13|106023|1.1.1.9||192.168.10.242||Deny icmp src outside:1.1.1.9 dst inside:192.168.10.242 (type 11, code 0) by access-group "global_access" [0x0, 0x0]

6|Feb 25 2014|11:21:13|302020|192.168.10.242|1|94.100.180.70|0|Built outbound ICMP connection for faddr 94.100.180.70/0 gaddr x.x.x.x.210/1 laddr 192.168.10.242/1

Re: Traceroute over ASA5505

Покажите show service-policy.

New Member

Traceroute over ASA5505

Ничего странного здесь нет, на мой взгляд.

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

1. Добавить в ACL на внешнем интерфейсе icmp пакеты 11 типа. На внутреннем интерфейсе в ACL ICMP добавлять не надо, так как трафик идет с интерфейса с более высоким уровнем безопасности на более низкий.

2. Включить строку set connection decrement-ttl в дефолтную политику.

3. Подкрутить таймер icmp - icmp unreachable rate-limit 10 burst-size 5.

Так как вы используете глобальный ACL, вам приходится добавлять разрешение на icmp так же и для внутреннего интерфейса.

Адреса интерфейсов самой Cisco ASA не контролируются ACL.

Traceroute over ASA5505

"Так как вы используете глобальный ACL, вам приходится добавлять разрешение на icmp так же и для внутреннего интерфейса."

Вообще-то inspect icmp error и предназначен для того, чтобы не нужно было этого делать В state table достаточно информации для нормального пропускания time exceeded.

New Member

Traceroute over ASA5505

Вы путаете фичи stateful packet inspection и deep packet inspection.

Traceroute over ASA5505

Инспекты на асе реализуют базовый функционал DPI, позволяя на основании L7 информации динамически открывать дополнительные доступы. Наиболее яркий пример семейства протоколов, которые без этого жить не могут - VOIP. Без инспектирования надо открывать половину диапазона UDP портов, чтобы RTP ходил, и даже тогда могут быть проблемы.

Не будь сконфигурировано inspect icmp и inspect icmp error - вы были бы совершенно правы, у ASA не было бы причин пропускать обратный ICMP time exceeded.

Cisco Employee

Re: Traceroute over ASA5505

Коллеги, это не так тривиально, как вы думаете. Ведь у сообщения ICMP Time Exceeded source IP совершенно не равен destination IP из той TCP/UDP/ICMP-сессии, для которой этот ICMP Time Exceeded был послан. Ибо он был послан промежуточным устройством. Да, внутри error-сообщений ICMP содержится IP-заголовок (и часть заголовка транспортного уровня) исходного пакета и можно было бы сопоставлять возвращающееся error-сообщение ICMP по нему. Но учтите, что error-сообщения ICMP бываю разными (PMTUD, например), транспортные протоколы тоже бывают разными, а на ASA может быть настроен даже не только NAT, но и PAT и исходный трафик мог быть натирован.

И, главное, что автоматическое прокидывание error-сообщений ICMP при настроенном inspect было бы потенциальной дырой в безопасности и снижало бы гранулярность политики безопасности, поскольку администратор может хотеть пропускать только часть сообщений ICMP в зависимости от source IP, а не все сообщения подряд.

Вобщем, ICMP Time Exceeded поэтому не прокидывается автоматически и д.б. явно разрешено ACL. ENH Request:

CSCsu84905    inspect icmp error should dynamically allow TTL ICMP expired messages

Аналогично для др. errors:

CSCta28249    ICMP Unreachables (Type 3) denied with inspect icmp error

И любопытно, что ASA лезет-таки в payload error-сообщений ICMP пытаясь найти в таблице соединений исходное TCP/UDP-соединение, для которого ICMP пришел. И это, как я написал выше, не всегда просто. А представьте, что у нас маршрутизация асимметрична и на этой ASA исходного соединения вообще нет? Поэтому есть еще один ENH Request, чтобы эту deep-проверку можно было отключать:

CSCtf91445    ENH: ASA - manually disable icmp type 3 and 11 state checks

725
Просмотры
5
Полезный материал
14
Ответы