Кто либо знаком с подобным устройством? Точнее, с FirePOWER Service, используемом на Cisco ASA 5ххх-X. Штука весма новая, но надеюсь, что хоть кто то с ней сталкивался.

Дело в том, что мы перебираемся с ASA 5510 + CSC-SSM10 на вышеупомянутое устройство. Перевод самого файервола проблем не создает (хотя диалекты весьма разные: ASA 8.2 <-> ASA 9.2). Вопрос в том, какие могут быть подводные камни с FirePOWER Service. Первый нашелcя сразу - тут необходим дополнительно FireSIGHT Management Center, что есть вообще говоря недешевая железяка. К счастью существует и софтовый центр, инсталлируемый на VMware. Но из за этого для запуска FirePOWER Service нужно сразу подключать железку к внутренней сети. Вопрос теперь в том, можно ли запустить настроить (хотя бы грубо) этот FirePOWER Service НЕ подключая внешний интерфейс (соединять внутреннюю и внешнюю сети одновременно через два разный файервола как то не кузяво :)).

Отсюда и главный вопрос - можно ли FirePOWER Service настроить (хотя бы грубо) за час-два? Тогда можно просто поменять файерволы (ASA часть уже настроена) и притормозить почту, пока не запущен анти-спам. А все остальное настраивать уже не спеша, на рабочей системе.

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

QUOTE (FiL @ 16-02-2015, 23:20)

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

вот и ответил бы... ;)

Я-бы ответил если-бы хотя-бы понимал об чем там спрошено. Для меня это все набор букв. Не особо упорядоченный.

QUOTE (FiL @ 17-02-2015, 00:20)

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

Так вопрос в значительно мере "для поговорить". А если еще и ответят (как обычно и бывет), то это уже бонус :)

QUOTE (FiL)

Я-бы ответил если-бы хотя-бы понимал об чем там спрошено. Для меня это все набор букв. Не особо упорядоченный.

Попробуем упорядочить. ASA 5510 + CSC-SSM10 это файервол/раутер (ASA 5510) со сменным модулем анализа контента (CSC-SSM10) - спам, антивирус итд. Замена на аналогичный (помощнее) проста. Новая машинка соеднияется только внешним нтерфейсом на свободный внешний адрес (нужно для лицензирования, апдейтов итд) и все настранвается и проверяется автономно, никакой интерференции со старым файерволом (кроме пары NAT-ов на другие внешние адреса внешнего интерфейса с внутренних серверов, но их можно вписать в самом конце, отцепив нешний интерфейс). Далее внешний адерес меняется на рабочий и перебросить кабели это пара минут.

С переходом на ASA 5545-X + FirePOWER Service ситуация посложнее. Файервол такой же и там проблем нет (просто диалект чуть поновее. А вот анализ контента (FirePOWER Service) тут софтовый. и для конфигурации (да и вообще работы) требуется еще внешний FireSIGHT Management Center, что есть очень недешевая железяка. Мы обошлись софтовым Management Center, но его можно запустить только на VMware. И вот тут и зарыта собака. У нового файервола нужно подключать не только внешний итерфейс (для лицензиий и апдейтов) но и внутренний (для подключения к VMware). То есть файервол я погу настроить автономно (что уже и сделано), а для лицензирования и настройки FirePOWER Service (да и FireSIGHT Management) должен быть подключен и внутренний интерфейс. То есть для избежания интерференции со старым файерволом часть настроек нового файервола придется отменить (NAT на другие внешние адреса итд), а в конце менять на рабочий не только внешний но и внутренний IP и тут неясно, как на это будет реагировать связка FirePOWER Service - Management Center, плюс нужно будет восстанавливать отмененные настройки.

То есть, какая то пауза неизбежна. Поэтому и возник вопрос, а не проще ли автономно полностью настроить новый файервол, и заменить старый на новый, не настраивая при этом FirePOWER Service <-> Management, а настроить его на запущенной новой системе с реальными соединениями и адресами. Если с регистацией, лицензированием и (грубой) настройкой FirePOWER Service с нуля можно уложиться в час-два, то этот путь кажется вполне разумным и его можно реализвать на уикэнде. Однако имея некоторый опыт с подводными камнями Cisco, гложут серьезные сомнения. Тем более, что система соверенно незнакомая.

А сосем совсем коротко, то вопрос простой - кто либо сталкивался с FirePOWER Service + FireSIGHT Management? :)

QUOTE (valja @ 17-02-2015, 07:40)

А сосем совсем коротко, то вопрос простой - кто либо сталкивался с FirePOWER Service + FireSIGHT Management? :)

видать ты у них первый клиент будешь... :D:

QUOTE (Гордый @ 17-02-2015, 10:31)

видать ты у них первый клиент будешь... :D:

Ну, тогда буду тут докладать, как идут дела, может, кому в будущем поможет. :) Поскольку читать манулы по 2000- страниц тяжеловато, мы пойдем своим путем. :pig:

В общем, убрал я с нового файервола записи, конфликтующие с рабочими адресами и поставил его в параллель со старым. Следующий шаг - инсталлирую FireSIGHT Management на VMware. Поскольку манагемент вообще то поддерживает несколько внешних устройств (типа ASA), которые именуются тут сенсорами, то по идее по крайней мере запуск, начальная конфигурация и регистрация лицензии манагера должны пройти без проблем. Ежели тут все пройдет гдадко, будем состыковывть FirePOWER Service и FireSIGHT.

Итак, первый подводный камень :fear2:

Management Center зхаинсталлировался и запустился без проблем. Следующий шаг - начальные устанвки (IP, DNS итд.) Засада ждала на лицензировании. Выдается "License Key" софтины и посылается на сайт sourcefire за лицензией. Там сообщение: "Мы уже ни при чем, идите на сайт Cisco".

Лады, идем туда, вводим PAK (Product Autorisation Key) - я софтину вроде бы купил, по запросу вводим "License Key" софтины и получаем сгенерированную дицензию (как для скачивания так и по почте). И тут засада - "License is Invalid".

В общем, озадачил суппорт сиски и жду :drag:

Без лицензии дальше ходу нет. :(

Помнится, когда я покупал ASA, то выбрал вариант ASA5505-50-BUN-K9.
И в коробке был буклет с напечатанными кодами для лицензий (50 юзеров). :)

С нашим старым файерволом (ASA5510) тоже было сравнительно просто. А теперь куча лицензий, и с половиной из нмих проблемы. До сих пор все рашались, но уходит куча времени и нервов. :(

Ответ на вопрос из первого поста "Отсюда и главный вопрос - можно ли FirePOWER Service настроить (хотя бы грубо) за час-два? " получен экспериментальным путем - НЕ можно :) FireSight Management Center был запущен 8 часов назад, а поке не устанавлена даже лицензия на сам Management Center, и это не едиственная лицензия на весь комплект. :(

По совету сиски полазил по /etc/ в поисках старых лицензий (правда, я не понял, откуда им там взяться? Даже первую не установить) но около шести нашего времени "наступило утро и Шехерезада прекратила дозволенные речи" - то есть после шести вечера новых советов не поступало. Надеюсь, что завтра утром все же удастся решить проблему.

С другой стороны, FireSight Management Center все же установлен и обходными путями удалось пробраться на GUI конфигурации. Правда, конфигурировть там пока нечего, так как не установлено ни одной лицензии, но возможноостей там очень много и лицензии у меня есть почти на фсе :) Завтра на свежую голову буду смотреть.

Утром оказадлсь, что все просто - лицензию нельзя вводить в процессе начальной установки, ибо "не работает". Просто это пункт нужно пропусттиь. А далее мы попадаем на главную конфигурационную страницу. Наверху 10 табов, у каждого от трех до десяти субтабов, большинтсво субтабов дают dropdown с 5-10 выборами. То есть, есть где развернуться конфигуратору :) Но по крайней мере лицензию удалсь тут скормить.

Правда, конфигурировать там пока нечего, сперва нужно подключить файервол (именуемый здесь сенсором). И тут пришлось долго и нудно конфигурировать на ASA интерфейс для коммуникации с Managemet Center.

И тут поджидала очередная засада - с сетью и конфигурациями все вроде ОК, к обоим дивайсам можно подключаться без проблем, но на попытку их познакомить ASA ответила, что канал общения не законфигурирван, а Managemet Center заявил, что ASA не хочет с ним общаться. В общем, очередная задачка для суппорта сиски. Но все это уже завтра :)

Я не очень понял в чем проблема с поднятием внутренного интерфейса на новом роутере. Втыкаешь в него одну еднственную машину с этим самым менеджером и конфигуришь. Потом, когда сам фаер перенесешь в продакшн, тогда и виртуалку с менеджером перенесешь на рабочую вмварь. И ваще нигде ничего не меняется.

QUOTE (FiL @ 19-02-2015, 17:02)

Я не очень понял в чем проблема с поднятием внутренного интерфейса на новом роутере. Втыкаешь в него одну еднственную машину с этим самым менеджером и конфигуришь. Потом, когда сам фаер перенесешь в продакшн, тогда и виртуалку с менеджером перенесешь на рабочую вмварь. И ваще нигде ничего не меняется.

Собственно, большой проблемы тут нету. Просто мне не шибко нравится соединять две сети параллельно двумя разными устройствами.

Тут для работы нужно вообще говоря три физических интерфейса - внешний, внутренний и интерфейс менеджмента (который поделен между менеджментом ASA и менеджментом FirePOWER Service, причем менеджмент FirePOWER Service работает только через физический интерфейс менеджмента).

Проблема скорее во внешнем интерфейсе - это должен быть реальный внешний адрес (один из свободных внешних адресов нашей сети) - через него скачиваются апдейты, регистрируются лицензии, а главное, качается "Security Intelligence Feed" - т.е. постоянно меняющиеся данные о "плохишах" (spam, botnet etc). Реальные запросы снаружи нужны для конфигурирования и тестирования FirePOWER Service. И проблема тут в том, чо в рабочей системе на внешнем интерфейсе несколько IP адресов - NAT/PAT во внутренние сети для серверов (почта, DNS, adl итд), то есть конфигурировать все эти NAT/PAT на новом ASA сразу не получится - реальные внешние адреса будут конфликтовать с рабочей системой, а свободных у меня во внешней сети почти не осталось. Но это в действительности не проблема - законфигурировать эти недостающие NAT/PAT вопрос пары минут.

Поскольку внутренняя сеть "native" для VMware, то проще сразу все цеплять туда, тем более что оттуда есть автоматом выход в интернет (через ASA), а этот выход нужен как Mangenet Center (VMware) так и менеджмент итерфейсу FirePOWER Service - именно они потребляют апдейты и "Security Intelligence Feed". А запускать и лицензировть Mangenet Center на отдельной машине и потом перетаскивать на рабочую VMware вряд ли получится - лицензия как то связана с железом и после переноса скорее всего накроется.

А теперь о самом девайсе. Сегодня наконец законфигурировал. :punk: Самая простая конфигурация, но вполне рабочая. Правда, поимел кучу головной боли и дымящихся нервов, но имея дело с Cisco без этого не обойтись :laugh:

Теперь четыре дня отдохну (у нас 24 февраля гос. праздник) и с середины будущей недели буду играться с новой игрушкой. Как когда то сказали, правда, про Юникс/Линукс: "Зато там можно очень много конфигурировать. И ты, бл***, БУДЕШЬ конфигурировать!"

не очень понял как виртуалка может привязываться к железу. Она ведь по определению железо не видит.

"внешняя" сеть тоже в общем-то не обязана быть особо внешней. Вполне может быть и внутренней, но имеющей доступ во вне. Хотя, конечно, киска могла и выпендриться и не разрешить такую конфигурацию. С них станется.

QUOTE (FiL @ 20-02-2015, 20:03)

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

Каждая инсталлируемая Management Center имеет свой License Key (саязанный с MAC ID и чем то еще) и все рабочие лицензии генерируются с привязкой к этому ключу. Можеть быть ключ сохранится и такой перенос сработает, но рисковать лицензией не хочется. Иначе Камасутра с запросом новых лицензий и уверениями, что я не использую дупликат центра (они за каждый центр отдельно денежки хотят).

"Внешняя" сеть должна быть также напрямую доступна снаружи, иначе тяжело проверять работу например "Security Intelligence", которая использует базы данных о "плохишах". То есть все равно нужен static NAT наружу и свободный внешний адрес.

Сейчас у меня внешний и внутренний адреса подменены, но они оба в реальных рабочих сетях и я могу тестирвать практически любой трафик в реале. А для замены файервола достаточно убить старый, сменить адреса двух итерфейсов на освободившиеся рабочие, перебросить 3 кабеля остальных внутренних интерфейсов на новы й файервол и создать 3-4 ststic NAT и ФСЕ! Делов ровно на пять минут. Ошибиться тяжело и не надо ничего перезапускать, все идет практически на ходу.

QUOTE (valja @ 20-02-2015, 20:54)

А для замены файервола достаточно убить старый, сменить адреса двух итерфейсов на освободившиеся рабочие, перебросить 3 кабеля остальных внутренних интерфейсов на новы й файервол и создать 3-4 ststic NAT и ФСЕ! Делов ровно на пять минут. Ошибиться тяжело и не надо ничего перезапускать, все идет практически на ходу.

А вот тут то я и "ошибился", делов не на 5 минут оказалось. И причина опять этот NAT :fu: При переходе ASA 8.2->8.3 не только убрали принудительный NAT (что хорошо), но к сожаленю NAT крупно переделали (что для меня очень плохо :( )

Дело в том, что из за внутернних интерфейсов нужен статический NAT на внешний адрес внешнего интерфейса (типа доступ извне к серверу). Если делать NAT на внешний интерфейс, но на другой адрес, то все пучком и работает:

CODE

object network dmz_NAT_to_outside subnet 192.168.10.0 255.255.255.0 object network dmz_mailer host 192.168.10.8 object network dmz_mailer-outside host xxx.xxx.xxx.xxx object network dmz_NAT_to_outside nat (dmz,outside) dynamic interface object network dmz_mailer nat (dmz,outside) static dmz_mailer-outside service tcp 3389 3389

Но если пустить NAT на адрес внешнего интерфейса, т.е. заменить последнюю строчку на

CODE

nat (dmz,outside) static interface service tcp 3389 3389

то ругани нет, но пакеты где то зависают. В логе такие строчки (таймаут 30 сек):

CODE

6 Feb 24 2015 12:11:34 213.184.43.215 29888 192.168.10.8 3389 Teardown TCP connection 2472 for outside:213.184.43.215/29888 to dmz:192.168.10.8/3389 duration 0:00:30 bytes 0 SYN Timeout 6 Feb 24 2015 12:11:04 213.184.43.215 29888 192.168.10.8 3389 Built inbound TCP connection 2472 for outside:213.184.43.215/29888 (213.184.43.215/29888) to dmz:192.168.10.8/3389 (213.184.43.218/3389)

На старом файерволе (с ASA) несколько статических натов на внешний интерфейс, на разные адреса, в том числе и на адрес самого интерфейса . конфигурируются все одинаково и работают без проблем.

Вопрос: как на ASA 9.2 сделать статический NAT конкретных портов из внутренних сетей на адрес внешнего интерфеса?

Ситуция оказалось чуть интереснее. Статический NAT конкретных портов из внутренних сетей на адрес внешнего интерфеса все же работает. Но работает как то странно. В случае, если к порту на адресе интерфейса обращаться с адреса, НЕ нахожящегося в однй сети с адресом внешнего интерфейса, то все вроде бв работает. Но ксли обращаться из той же сетки, где и сам интерфейс, то соединение тихо зависает (вышеупомянутый таймаут).

Т.е, если адрес внешнего интерфейса 123..123.123.1/24 и изнутри делать статический NAT порта на 123.123.123.1, то для адресов 123.123.123.0/24 это NAT будет недоступен, но будет доступен для всех других адресов. Если же делать статический NAT порта на другой адрес в той же сети (например 123.123.123.2 или 123.123.123.10) то все работает с любого адреса,

Это не есть хорошо, так как на нашем старом файерволе на адресе внешнего интерфейса сидит мейлер это будет очень плохо, если он будет недоступен для устройств из своей же сети.

Как сие лечить???

на самом деле это очень распространенная проблема.
Я с ней многократно встречался на различных софтовых фаерволах. Причем в зависимости от софтовости фаервола проблема или решается просто или решается сложно или не решается совсем. А вот на железных рутерах я с этой проблемой не встречался. Правда с железными решениями я только с домашними встречался.

Ой, перечитал и понял, что неправильно тебя понял.

Обычно проблема возникает с NAT-ом при обращении к внешнему адресу из внутренней сети, а у тебя проблема при обращении из внешней сети, локальной к самому интерфейсу. Тут я даже не представляю с чего вдруг такой косяк. С точки зрения что НАТ-а, что фаервола - внешний он и есть внешний. И проблем быть не должно. Я-бы сказал, что косяк где-то в фаерволе в принципе. Но... дьявол в детялях. И, как я понял, аналогичная конфигурация на старой версии работает. Так что вообще не ясно что и где.

QUOTE (FiL @ 25-02-2015, 05:14)

а у тебя проблема при обращении из внешней сети, локальной к самому интерфейсу.

Именно так,

На старом файерволе, где ASA 8.2, такой NAT настраивается очень просто и нет никакой разницы, какой внешний адрес ставится для внутреннего сервера, лишь бы он был в пределах сетки внешнего интерфейса. И у меня большинство таких натов идут именно на адрес интерфейса.

Начиная с ASA 8.3 (у меня 9.2) не только убрали принудительный NAT (что хорошо), но к сожаленю NAT крупно переделали и чего-то там нахимичили. Похоже, что сетка внешнего интерфейса в чем то особенная и в Cisco об этом знают.

Например, в ASDM есть "Configuration > Firewall > Public Servers pane", где легко создать доступ к внутреннему серверу - укажи внутренний интерфейс, адреса (внутренний и внешний) и порт и все будет сделано. Внешний адрес может быть любой (внутри сетки), кроме IP внешнего интерфейса. Если попытаться это сделать, получим ошибку - "адрес перекрывается с адресом внешнего интерфейса". Если же идти в раздел конфигурации NAT, то можно выстаить и внешний интерфейс (но будем иметь вышеозвученные проблемы).

Кстати, попутно выплыла и другая проблема - оказываеьтся, что при обращениях из такого сервера к внешинм серверам в сети внешнего интерфейса тоже есть глюки: например FTP зависает, но работат с адресами вне сетки интерфеса, но SCP работает. Похоже, что с начиная с ASA 8.3, статический NAT на адрес внешнего интерфейса толком не работает (или же требует каких то дополнительных телодвижений, которых я не знаю). Повторюсь, что со старым ASA 8.2 все работает на ура.

ftp в passive mode должен-бы работать. в active - понятно почему не работает,
но почему они так жестко обрубили сеть внешнего интерфейса - это вопрос интересный.

Мне вот что интересно, ты говоришь, что для NAT-а можно указать любой адрес в качестве внешнего (понятно, что из своей сети) кроме адреса на интерфейсе. А где тогда должен быть этот адрес? Нигде? То есть фаервол слушает пакеты в promiscuous mode? странно оно...

QUOTE (FiL @ 25-02-2015, 08:06)

ftp в passive mode должен-бы работать. в active - понятно почему не работает, но почему они так жестко обрубили сеть внешнего интерфейса - это вопрос интересный.

"Login prompt" должен быть виден так и так, да и логин должен срабатывать. Просто в "active" я не получу даже листинга. А сейчас после задержки 20-25 получаю сообщение (фтп клиент из досовского промпта)

> ftp: connect :Unknown error number

Причем фтп сервер видит запрос на логин, который через 20-25 секунд умирает. В то же время например ftp.funet.fi работает на ура. И кстати, это фтп обращение никоим образом не связано со статическим NAT - тут работает уже dynamic NAT для всей внутренней сетки. И я не могу обращаться к собственному же фтп серверу во внешней сети! :fu: В то же время www, SCP

QUOTE (FiL @ 25-02-2015, 08:06)

Мне вот что интересно, ты говоришь, что для NAT-а можно указать любой адрес в качестве внешнего (понятно, что из своей сети) кроме адреса на интерфейсе. А где тогда должен быть этот адрес? Нигде? То есть фаервол слушает пакеты в promiscuous mode? странно оно...

Не совсем понял вопрос. А по ASA я понимаю так, что по умолчанию ASA слушает только по адресу интерфейса. Если при конфигурации NAT указывается другой адрес, то ASA начинает слушать и по этому адресу. Этот адрес прописывется в правиле/правилах NAT и открывается "на лету" вместе с активацией правила, отдельно его нигде прописывать не надо. Самое забавное, что я могу прописать там вообще любой адрес, например 123.123.123.123 (сообщения об ошибке не будет) и скорее всего он будет слушать по этому адресу. Правда, неясно, как он на такие запросы отвечать будет.

Похоже, что у ASA это весьма обычная практика. У ASA5545-X на Management0/0 интерфейсе по умолчанию активны три адреса - 192.168.1.1, 192.168.1.2 и 192.168.45.45

Поигрался я с этими натами. Карина выглядит следующим образом:

Если NAT (PAT), все равно, динамический или статический, делается на свободный адрес в сетке внешнего интрефейса, то все работает как в аптеке.

Если на адрес внешнего интерфейса сделать динамический NAT (доступ внутренней сети наружу) , то все работает при обращении к адресам вне сетки внешнего интерфейса. При обращении к сайтам в сетке внешнего интерфейса работает выборочно - с частью сайтов большинство протоколов не работают, причем эти сайты друг с другом (и другими сайтами) работают без проблем.
На сайте, куда делается соединение, видно, что несколько раз приходит SYN пакет, на что отвечают SYN ACK, который до цели, похоже, не доходит.

Если на адрес внешнего интерфейса сделать статический NAT (доступ снаружи к внутреннему серверу), то все работает, если обращаться из за пределов сети внешнего интерфейса. Если же обращаться из сетки внешнего интерфейса, то в основном не работает (см. предыдущие посты). Возможно, что что-то и работает, но все я не проверял.

Короче: если NAT (PAT), все равно, динамический или статический, делается на адрес внешнего интрефейса, то все работает для сайтов вне сетки внешнего интерфейса, но с сайтами внути этой сетки нерпедсказуемые заморочки.

К сожалению я так и не понял, это фича такая или NAT (PAT), все равно, динамический или статический, на адрес внешнего интрефейса делать нельзя. Или можно, но нужны дополнительные пляски с бубном.

ага, понимаю.
видимо (я тут вместо штатного телепата выступаю) эта хрень при описании правила NAT таки поднимает на внешнем интерфейсе очередной виртуальный интерфейс с этим самым адресом. Но при наличии там еще одного виртуального интерфейса с таким-же адресом система не ругается, а просто впадает в ступор. Ибо там получается два виртуальных интерфейса с одним адресом. И пакеты приходят... а куда хотят - туда и приходят. Но с большей вероятностью на статический, а не на тот, который от НАТ-а. Просто потому, что тот раньше поднят.
Забавная бага. Но, подозреваю, вручную не лечится.

Вопрос, а если система сама вполне себе умная и поднимает интерфейс с нужным адресом в момент описания правила НАТ, то зачем тебе этот адрес поднимать на интерфейсе статически?

Я думаю, не совсем так. Если я делаю новый NAT, то я могу указать либо новый адрес, либо сам внешний интерфейс. Если попытаться ввести адрес внешнего интерфейса, выдается ошиба - "address overlapping with address of interface". То есть, новые правила пришиваются либо к существующему объекту (виртуальному интерфейсу) либо нужно предварительно создать новый объект с новым адресом.

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

У меня сейчас все вообще раздельно:
адрес интерфейса вообще не используется.
серверы (разные порты) . статический NAT на АДРЕС-1
внутренняя сеть - динамический NAT на АДРЕС-2

И с виду все работает (полностью еще не проверил). Но стоит использовать для (любого) NAT адрес интерфейса, начинаются заморочки того или другого рода с хостами в сети внешнего интерфейса :( А на старом ASA на внешнем интерфейсе куча натов (как статических на разные порты, так и динамических от разных внутренних сетей, и все пашет).

Наконец нашли свободное время (не мое :) а в смысле загруженности сети) и поставилн новую игрушку. Все работает на ура. Были серьезне опасения по поводу спама, но к счастью спама приходит примрно столько же, т.е весьма мало, но немного увеличивается нагрузка на почтовый сервер.

А если подробнее, то это немного удивляет. CSC-SSM использует Trend Micro InterScan for CSC SSM. Анти-спам основан на собственном RBL листе, который дополнен динамичным, т.е. очень бстро меняющимся листом. В дополнение к этому собственный движок распознавания спама с постоянно обновляемыми правилами. Имеются black и white листы как по ИП-адресам так и по e-mail адресам и доменам. Эта система блокирует у нас 2000-2500 спамов в сутки, до меня доходило меньше одного спама в сутки.

ASA FirePOWER Service (Security Intelligence) использует Security Intelligence Feed (Sourcefire Intelligence Feed), где данные (ИП-адреса) обновляются каждые два часа, и лист спамеров только часть фида (там есть еще ботнеты, фишинг, атакеры, malware итд), в дополнение имеются black и white листы по ИП-адресам. Првила с почтовыми адресами и доменами пришлось переводить на почтовый сревер, что слегка увеличило его нагрузку. Слегка смущало малое число спамерских ИП-адресов в фиде (2000-4000) - очень мало по сравнению с RBL листами. Поэтому ожидалось увеличение проходящего спама и предполагалось использование дополнительных RBL листов. Однако роста спама не произошло, хотя по логам за сутки блокируется только 250 сайтов (вместо 2000 у Trend Micro). Trend Micro записывал на "свой счет" и блокировки по почтовым адресам и доменам, которые теперь блокирует сервер, но все равно это не объясняет столь большой разницы в числе блокировок (250 vs 2000). Возможно, что разница в системе регистраци - например, Trend Micro показывает в логе все обращения спамера а Security Intelligence только первое обращение и последуюшие (в течении какого то времени) в лог не записываются.

Как бы то ни было, анти-спам Security Intelligence оказался вполне эффективным, хотя и не является специальной анти-спам системой.