Close Topic Options

[valja]

Вопрос к спецам Cisco.

Задача: Имеется ASA5510, интерфейсы (в скобках security level) - внешний (0), внутренний (70), dmz (30), wireless (50), интерфейсы с бОльшим security level должны по дефолту иметь доступ к интерфейсам с меньшим security level. Для выхода во внешнюю сеть используется dynamic NAT (dmz исключение, там все индивидуально). Транспорт между внутренними сетями должен быть без NAT (то есть, там стоит NAT exemption).

Пока все хорошо - в Security Policy у каждого интерфейса на входе по умолчанию стоит два правила: 1. разрешен доступ в сети с меньшим security level, 2. второе правило запрещает весь (остальной) траффик.

Проблема: Добавление любого разрешения какого либо входящего траффика (например из dmz на группу адресов во внутреннем итерфейсе) убирет дефолтное правило 1. То есть, dmz сразу лишается доступа куда либо, кроме разрешенного новым правилом, то есть, больше нет выхода на внешний интерфейс. Все доступы нужно теперь устанавливать вручную. Для восстановления доступа из dmz во внешнюю сеть нужно разрешить выход на адрес any (0.0.0.0) на внешнем интерфейсе. Если в ASDM выбрать источником пул адресов DMZ а адресата как any, то any открывает полный доступ из dmz куда угодно, то есть, кроме внешних адресов и во все внутренние сети (у NAT exemtion и доступ прямой). Ограничить доступ к any только внешним интерфейсом в ADSM я не могу - в ADSM можно выбрать только адреса (либо IP адрес интерфейса, что не решает проблемы). А вот выбрать адрес any, ограничивась для адресата лишь внешним интерфейсом, у меня не получается.

Вопросы:

Можно ли восстановить дефолтное правило, разрешающее траффик на интерфейсы с меньшим security level, то есть ставить новые разрешения на входе интерфейса в дополнение к данному дефолтному. (Скорее всего нельзя).

Как описывать адресата/источник на только по IP адресам/группам но и указвать одновременно и интерфейс (то есть, например, any, но только на внешнем интерфейсе)? В ADSM я такого не вижу. Стало быть, командной строкой? Или как то можно и в ADSM?

Или у меня уже крыша едет и я не вижу тривиального решения?

Возможно, изложил проблему несколько сумбурно, но, надеюсь, спецам понятно.

[astra]

Я не спец и много чего не понял из того, что ты описал, но мне кажется из командной строки можно будет настроить extended ACLs..

[valja]

QUOTE (astra @ 10-06-2008, 22:53)

Я не спец и много чего не понял из того, что ты описал,

Попробую объяснить иначе. Для каждого разрешенного интерфейса для входящих пакетов есть два правила по умолчанию (implicit rules). Первое правило разрешает траффик ко всем интерфейсам с меньшей защитой (security level), второе правило запрещает весь остальной траффик. В общем случае это именно то, что надо (например, любой внутренний интерфейс может обращаться наружу, так как этот интерфейс имеет самый низкий security level = 0). В конфигурационном файле эти правила не прописываются.

Если нужно дополнительно разрешить какой либо траффик, входящий по какому либо интерфейсу (например, из dmz на внутренний), то первое implicit правило аннулируется и все правила нужно теперь писать вручную.

Беда тут в том, что интерфейс источника я могу задать, но для адресата я могу выбирать лишь адреса, то есть я не могу ограничить действие правила конкретным выходным интерфейсом. Например, если я определяю для входящих на интерфейс dmz пакетов разрешенного адресата как any (необходимо для доступа к прозвольным сайтам в интернете), то это открывает также доступ к любому внутреннему интерфейсу, независимо от его security level. А мне нужно ограничить действие этого правила лишь пактетами, идущими на внешний интерфейс. Увы, задать здесь для адресата как адрес так и интерфейс я не умею

QUOTE

но мне кажется из командной строки можно будет настроить extended ACLs..

Похоже, что таки придется учить албанский (после ipchains и iptables диалект Cisco сильно на албанский смахивает ). Пока нашел только команду access-group, но моя беда в том, что в новом правиле мне нужно задать два интерфейса - интерфейс, к которому правило прилагется, но ограничить применеие правила только вторым интерфейсом, куда пакет адресуется.

В iptables проблема решается одной строкой (вроде не противоречит правилам):

IFACE_EXT="eth0"
IFACE_DMZ="eth1"
IFACE_INT="eth2"

iptables -A FORWARD -i $IFACE_DMZ -o $IFACE_EXT -d 0.0.0.0 -j ACCEPT

и такая строка не даст доступа из IFACE_DMZ на IFACE_INT.

Аналог того, что создается в ASDM, это

iptables -A FORWARD -i $IFACE_DMZ -d 0.0.0.0 -j ACCEPT

но это разрешает пактеты и не итерфейс IFACE_INT

Надеюсь, теперь проблема более понятна

[heineken man]

QUOTE

то это открывает также доступ к любому внутреннему интерфейсу, независимо от его security level.

Ну, собственно это то, о чем уже лет 15 говорили большевики и одна из причин, по которым файервольщики стараются по возможности держаться подальше от пиксов и его реинкарнаций.

Обычно используют два workarounds, один кривее другого.

Первый - селективный NAT Control, т.е регулировать доступ через NAT rules вдобавок к аксесс-листам. Вот там есть привязка к обоим интерфейсам - IN-OUT. Собственно, так Сиско все и задумывала. Вообще-то, это тебе только кажется что появляется доступ ко всему с появлением рула any-any-allow, в пиксах это не так - появляется только доступ к туда, куда сделан NAT (любой, хотя бы нулевой, возможность отменить NAT Control появилась только в 7 версии.)

Есть какой-то тип NAT, привязанный к аксесс-листу, но там не на всякую нервную систему расчитано (не на мою точно).

Второй -способ после того, как имплисит рул исчезает, создать связку access-lists на интерфейсе DMZ
(DMZ NET) -> (internal LAN) -> allowed services -> allow
(DMZ NET) -> (internal LAN) -> any -> deny
(DMZ NET) -> (any) -> any -> allow
Обычно так и делают.

Genka у нас знаком с сабжем "интимно" по его словам, если сумеет оторваться от отцовских забот минут на десять то можно будет получить expert opinion.

ЗЫ - только сейчас почувствовал, как хорошо что я уже с пиксями не работаю.

[valja]

QUOTE (heineken man @ 11-06-2008, 11:15)

QUOTE то это открывает также доступ к любому внутреннему интерфейсу, независимо от его security level. Ну, собственно это то, о чем уже лет 15 говорили большевики и одна из причин, по которым файервольщики стараются по возможности держаться подальше от пиксов и его реинкарнаций.

А в чем там, собственно, проблема? Почему бы не добавить к адресату кроме IP адреса, еще и (optional) интерфейс? Механизм у них вроде есть (implicit rule работает именно по интерфейсам а не по адресам.

Кстати, security level интерфейса самому как то использвать можно? Или он работает только с implicit rule?

QUOTE

Первый - селективный NAT Control, т.е регулировать доступ через NAT rules вдобавок к аксесс-листам. Вот там есть привязка к обоим интерфейсам - IN-OUT. Собственно, так Сиско все и задумывала. Вообще-то, это тебе только кажется что появляется доступ ко всему с появлением рула any-any-allow, в пиксах это не так - появляется только доступ к туда, куда сделан NAT (любой, хотя бы нулевой, возможность отменить NAT Control появилась только в 7 версии.)

NAT между внутренними интерфейсами я снимаю (NAT exemption), так что остается играться с ACL.

QUOTE

Есть какой-то тип NAT, привязанный к аксесс-листу, но там не на всякую нервную систему расчитано (не на мою точно).

Может, когда албанский подучу, попробую разобраться

QUOTE

Второй -способ после того, как имплисит рул исчезает, создать связку access-lists на интерфейсе DMZ (DMZ NET) -> (internal LAN) -> allowed services -> allow (DMZ NET) -> (internal LAN) -> any -> deny (DMZ NET) -> (any) -> any -> allow Обычно так и делают.

Спасибо, похоже, что товарисч (т.е. я) шел верным путем. Осталось разобраться, как в ASDM двигать правила вверх-вниз (а то я раньше этот путь пробовал, но создал запрещающее правило после разрешения на any, и естественно, это не работало ).

QUOTE

Genka у нас знаком с сабжем "интимно" по его словам, если сумеет оторваться от отцовских забот минут на десять то можно будет получить expert opinion.

О, буду только рад

[heineken man]

QUOTE

NAT между внутренними интерфейсами я снимаю (NAT exemption), так что остается играться с ACL.

Ты его не снимаешь, а создаешь. NAT exemption - один из видов NAT. Так создай не один "грандиозный", а несколько целевых.

QUOTE

А в чем там, собственно, проблема? Почему бы не добавить к адресату кроме IP адреса, еще и (optional) интерфейс?

Таков формат общесисковских аксесс-листов.

Рулы двигать нельзя, но cut -> paste работает. И в последних версиях ASDM появилась возможность делать disable на акксесс-лист (хвала богам - через десять лет стенаний мучающихся админив).

QUOTE

Кстати, security level интерфейса самому как то использвать можно? Или он работает только с implicit rule?

Как говорит Т'илк из SG-1 - Indeed.
Тяжелое наследие прошлого, наряду с обязательным нат-ированием и привязкой рулов к интерфейсам.

[valja]

QUOTE (heineken man @ 11-06-2008, 12:42)

QUOTE NAT между внутренними интерфейсами я снимаю (NAT exemption), так что остается играться с ACL. NAT exemption - один из видов NAT.

Спасибо, это объясняет, почему при трассировке пакетов в ASDM так много NAT проверок.

QUOTE

Так создай не один "грандиозный", а несколько целевых.

А это как? Собственно, NAT мне нужен только для общения с внешним миром и для этого на каждом интерфейсе (кроме dmz) создается динамический NAT на внешний интерфейс с адресатом any, из за чего приходится дополнительно делать NAT exemption для внтренних сетевых адресов. То есть, тут та же заморочка с any. На dmz статические NAT для каждого сервера индивидуално.

Кстати, если бы можно было создавать адресные пулы с исключениями (вроде any except 192.168.0.0/255.255.0.0) то это сразу решило бы большинство проблем, как с созданием целевых NAT так и с созданием ACL. Да и вся конфигурация выглядела бы проще и прозрачнее

QUOTE

Рулы двигать нельзя, но cut -> paste работает. И в последних версиях ASDM появилась возможность делать disable на акксесс-лист (хвала богам - через десять лет стенаний мучающихся админив).

Да, возможности передвигать установленные правила в ASDM я не нашел. К счастью при создании ACL правила, в ASDM можно указывать место, куда его ставить (то есть, до или после какого либо имеющегося правила). А по умолчанию правила добавляются в хронологической очередности создания.

[heineken man]

QUOTE

А это как? Собственно, NAT мне нужен только для общения с внешним миром и для этого на каждом интерфейсе (кроме dmz) создается динамический NAT на внешний интерфейс с адресатом any, из за чего приходится дополнительно делать NAT exemption для внтренних сетевых адресов. То есть, тут та же заморочка с any. На dmz статические NAT для каждого сервера индивидуално.

Идея в том, что для любого интерфейса, где существует угроза "any" после исчезновения имплисит рула сделать набор натов (или exemptions) только на те интерфейсы, куда действительно надо ходить. Для выхода в инет через Outside этого делать не надо, уже сделано.
У меня нет возможности сейчас заглянуть в железку или мануал, сорри.

QUOTE

NAT мне нужен только для общения с внешним миром

Прописать бы это огромными красными буквами и повесить в спальнях всех девелоперов PIX/ASA.

[valja]

QUOTE (heineken man @ 11-06-2008, 14:15)

У меня нет возможности сейчас заглянуть в железку или мануал, сорри.

Спасибо, идея понятна, разберемся

QUOTE

QUOTE NAT мне нужен только для общения с внешним миром Прописать бы это огромными красными буквами и повесить в спальнях всех девелоперов PIX/ASA.

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