Почему я не люблю облачные сервисы?

[rockatansky]

А я очень не люблю облачные сервисы.

Вот стоит задача: запретить доступ до api.mail.ru со всех наших филиалов. Запретить при помощь файрвола, cisco asa 5505, скажем. Известно, что у api.mail.ru много адресов.
И тут же хочется, конечно, использовать fqdn acl.
А облом.
Если сделать nslookup api.mail.ru 8.8.8.8 (чтобы заведомо ничего не кэшировалось), то выяснится, что:

• api.mail.ru резолвится только в один адрес за раз
• но при следующем запросе это будет уже другой адрес
• и эти адреса не принадлежат одной AS-ке и общего между собою ничего не имеют.

Это называется — облако.
Строго говоря, если есть кэширующий DNS сервер (грубо говоря, DefaultDNS у асы не гугловый, а корпоративный), схема может сработать — пока тот же сервер является DNS-ом у пользователей.
Но вот незадача — время кэширования у асы и корпоративного DNS легко может не совпасть.

Даже если мы настроим проверку обновлений на циске раз в минуту, то за эту минуту, пока acl не обновился,

много чего может случиться

много чего может случиться. У нас, например, asa при этом ушатывается по cpu, но как и почему — это материал для другой сказки-про-циску.

А вот кстати поговорим про обновление acl. Каждый раз, как acl будет обновляться, циска будет фактически выполнять операцию clear xlate, дропая коннекшены (так как на базе fqdn она формирует вполне себе классическую ACL-ку). upd: вроде, всё же нет.

Последний минус этой схемы — на блокируемых адресах может быть размещено что-то полезное. А то так заблочишь api.mail.ru, а тебе mail.ru отдаваться перестанет (чисто теоретически).

Как мы (Николай Второй, император и самодержец) это порешали?
Добавили на корпоративный DNS указ резолвить api.mail.ru в серый внутренний адрес 10.x.x.x, а на ASA, соответственно, блочить запросы к этому ip-шнику.


Здесь для сравнения нужно добавить контрпример, пусть будет maps.google.com.
Сделайте nslookup maps.google.com и почувствуйте разницу: вот это благодатная почва для fqdn acl.

UPD: в попытке всё же воспользоваться fqdn пока сделала

dns domain-lookup inside
dns server-group DefaultDNS
expire-entry-timer minutes 60
poll-timer minutes 1
name-server 10.150.1.2
domain-name tensor.ru

Смотрю, сколько он насобирает за час. Ещё интересно, что произойдёт на стыке. Время жизни записи минута, итого у парня 60 попыток собрать всю эту байду. А потом всё обнулится Т.е., на практике меня интересуют очень длинные expire-entry-timer minutes.

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

@темы: цыски

Comments

[Garryncha]

rockatansky, интересно, т.к. задача из практики!
Получается, надо до L7 пакет просматривать, чтобы фильтровать строго определённый сайт.
Ну и вы тоже придумали выход, прикольно.
Я и не думал, что FQDN ACL делают просто резолв и потом строят обычный ACL.

[rockatansky]

Garryncha, до L7 как раз фильтровать можно, но не хочется по понятным причинам. А так, видимо, скоро придётся.
Потому что представим обратную ситуацию - трафик до облачного ресурса нужно разрешить, а не запретить, и мой аккуратный в целом метод уже не работает

[Garryncha]

rockatansky, а если написать на вашем DNS-сервере какие-нибудь статические записи (типа /etc/hosts), что сайт надо резолвить в такой-то набор из 20 ip-шников? Да, не всегда будет гарантия, что сайт доступен, но вероятность отказа маленькая. Ну или можно написать какой-нибудь скрипт, который много раз делает dig/nslookup и потом обновляет статические записи. И запускать этот скрипт периодически, автоматически, конечно.

[rockatansky]

Garryncha, а это уже костыль.
Я собираюсь всё-таки реализовать очень похожую схему, но динамическую, с помощью fqdn: задам ему политику обновления (нового запроса к DNS) - раз в скажем одну минуту, а кэш задам длинный - скажем, час, или 8 часов или 24 часа, если возможно.
Итого : за 8 часов циска опросит все возможные ip-шники для данного имени, добавит в acl и будет обрабатывать.

ip могут полностью смениться, а acl будет работать. Срыв маловероятен)

[Garryncha]

rockatansky, а ты пишешь, что ASA уходи в "полку" по CPU, если настроить обновления ACL раз в минуту. Как с этим жить? И ещё отдельный вопрос — почему так происходит.

[rockatansky]

Garryncha,
>>> ASA уходи в "полку" по CPU, если настроить обновления ACL раз в минуту - не говорила я этого! Она у нас уходит в полку по совершенно левым причинам, и чтобы избавиться от этого, мы блочим конкретные ресурсы. А почему уходит - это связано с багом при авторизации.

[rockatansky]

Garryncha, не репости пока) Это по горячим следам статейка, для себя же. Чтобы завтра же не забыть все тонкости.
В частности, в сентенции про clear xlate я уже сомневаюсь: надо тестировать.

[Garryncha]

rockatansky, про CPU понял. Удалить репост?

[rockatansky]

Garryncha, да там уже дискуссия)) лучше так. Я дотестю, попрошу специально тебя и ты его апдейтнешь - типа автор дурак, но стремительно исправляется?
Мне просто удобно сюда записывать рабочие моменты и апдейтить, как разберусь)

Коннекшены он вроде не рвёт. поэтому что это считается не за добавление нового rule, а за добавление объекта в rule

[Garryncha]

rockatansky, ага, апдейтну пост, как ты скажешь.

[rockatansky]

Garryncha, можешь апдейтить)

[Garryncha]

rockatansky, обновил пост у себя.