Как стать автором
Обновить

Комментарии 45

а мне показалось, что кат есть, но слишком уж глубоко
Он есть. Сразу после Рис. 24. Посмотрел только что запись полуфинала с эпичной игрой бразильцев. Так что такому фортелю даже не удивился.
Быстрее прячьте все под кат :)
Под кат статью, только 2-3 абзаца анонса, а не половину статьи! зачем такая простыня на главной?
Прошу прощенья, поправку ката сделал.
Когда будете публиковать EOL для всей линейки ASA? У меня давно было ощущение, что эту платформу планомерно убивают. По VPN функционалу она далеко отстала от ASR1k/ISR, оставался функционал NGFW, но тут появляется явно более совершенный FirePower. Существование ASA полностью теряет смысл.
EOL? Не слышали)
Это самый широко распространённый в мире межсетевой экран, основа нашего бизнеса по безопасности и передо мной детальный план развития на два года.
А с августа *пшшш, по секрету* мы сможем запускать Sourcefire на любой ASA с приставкой Х и SSD-диском
Ура! ASA из убогой хреновины с не очень понятным назначением превратится во что-то приличное!

Скажите, а в том плане говорится что-то о приведении конфигурации NAT в поддающийся хоть какому-то сопровождению вид? Или это будет сделано в рамках интеграции SF? Подразумевает ли «запускать Sourcefire» замену родной ОС, или это параллельный функционал?
Наверное процесс конфигурации NAT на ASA это как «фломастеры на вкус и цвет все разные», я настраивал NAT еще на 6-ке PIX и за последние лет 7 какие только сложные конфигурации натирования мне не приходилось делать. Если честно, на мой взгляд, на ASA самая гибкая система натирования и эта функция очень продвинутая. С точки зрения настроек, да, пожалуй надо привыкнуть, но как и любая профессиональная система ASA требует сноровки и внимательного чтения мана.
Если честно, на мой взгляд, на ASA самая гибкая система натирования и эта функция очень продвинутая.

Тут не поспоришь — гибче некуда. Неудобнее в работе — тоже. Вероятно, каждый, кто сталкивается с функционалом NAT на асе, периодически чертыхается на строчки в логах со словом «asymmetric». То, что наворотили в 8.3+, еще более монструозно. А уж всякие прикольные вещи вроде удаления записи policy NAT, если в его ACL нечаянно добавили строчку с «permit tcp»…

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

Ситуация печальна тем, что обычно получаешь заявку, настраиваешь, говоришь «настроено», а у людей ничего не работает. Ситуация обычно не критичная, но неприятная. Но куда хуже, когда кусок NAT просто сдувает из конфигурации из-за маленькой ошибки, а потом заводят и тут же закрывают enhancement request, мол «так и надо».

Да, я тоже помню тот ужас, который представляли собой пиксы 6-7 версий. Еще даже без поддержки кнопки Tab. У меня где-то по сети несколько 501-х машинок даже разбросаны. Годами работают в одиночестве, ssh сервис зарастает паутиной…
Со сдуванием настроек ната у меня лично не было случаев, но я и не писал permit tcp, вспоминается демотиватор «процесс перевода кейса из разряда as designed, not a bug в состояние Pending». Это уже привычка вырабатывается писать permit IP, также как и логика работы route-map с acl.
Причиной может быть копипаст куска обычного ACL, когда забыли поправить TCP на IP. Лично я так не делал, но был свидетелем подобной аварии. И где-то в блогосфере было много статей с матами на эту тему. Если вводишь некорректную строчку в ACL, правильным поведением системы было бы отбросить эту строчку. А ASA применяет ее, внезапно обнаруживает некорректность всего ACL и удаляет то, к чему он привязан. Раньше было поведение «удалить весь ACL», это на каком-то этапе заменили на более мягкое «удалить конфигурацию NAT, опирающуюся на ACL». Волшебно. Логика людей из BU какая-то инопланетная.
Людей из BU порой непросто понять ;)
Линейка ASA очень бурно развивается, посмотрите на тот функционал что был добавлен начиная с версии 9.0 и 9.2.1, кластеризация, микшированные контексты, BGP, интеграция в архитектуру TrustSec и оочень много всего другого, я боюсь что именно VPN в виде GETVPN/DMVPN этот как раз и есть то отличие, которое на маршрутизаторах впереди. Но возьмем мобильный VPN посредством ANYCONNECT, полноценная его работа со всеми функциями и теперь уже COA (Change of Authorization) есть только на ASA. По многим функциям у ASA и конкурентов то нет, так что платформа цветет и развивается семимильными шагами.
Ну положим из реально сильных мест можно упомянуть только Trustsec. Anyconnect плох по сравнению с аналогичными решениями многих конкурентов (хоть того же F5), разве что есть дружба с ISE (у конкурентов свои механизмы). Кластеризация — забавная штука, но ИМХО потребность в ней следует из плохого дизайна, и у нее свои штрафы и ограничения. Контексты наконец-то начали обретать функционал, но мне не очень понятна их надобность.
Я к сожалению не могу сравнить с F5, не было у меня опыта с ними, зато работал с CheckPoint в частности на десктопных и мобильных платформах, «юзер экспириенс» остался весьма отрицательный. Кстати и по поводу ISE, на данный момент это практически безконкурентная система идентификации пользовательского и непользовательского доступа в сеть. Более органично вписывающейся системы идентификации с прозрачной авторизацией на транзитных узлах (МСЭ, маршрутизаторы, коммутаторы ЦОД, VPN гейтвей) я просто не знаю (поправьте если не прав). И именно благодаря TrustSec и меткам SGT.
Контексты они крайне полезны в ЦОД, заказчики нарезают на контексты функционально разные сегменты ЦОД, разных своих внутренних заказчиков, отделяют PCI DSS сертифицируемые сегменты и так далее, фактически вы же получаете логически полностью отдельный фаервол, даже с защитой вычислительных ресурсов по классам обслуживания.
Да, Trustsec и SGT — вкусно. Но не когда оборудование не умеет SGT, а иных причин менять его нет.
Ну так специально чтобы оборудование не менять можно использовать протокол SXP, который может передавать маппинги IP <-> SGT на вышестоящие устройства, которые понимают Inline тегирование к примеру. Этот протокол как раз избавляет нас от необходимости менять все оборудование.
Конечно надо понимать, что совсем старое оборудование уже и SXP не умеет.
Там свои сложности по части масштабирования. Ну и да, пограничное оборудование может и этого не уметь. Но при этом иметь прочий функционал ISE с точки зрения 802.1x.
Кстати и в этом случае есть возможность использовать SGT. Например делать динамическую авторизацию с назначением VLAN, на вышестоящем уровне распределения использовать более умное оборудование (например Cat6k-SUP2T) и применять теги на нем уже с привязкой к влану.
Тогда теряется профит отвязки примененных политик от адреса устройства. С таким же успехом можно на файрволе сразу делать фильтрацию по адресам.
Ну почему же, если у нас более менее общие политики по группам пользователей, тогда например делаем 7 вланов:
1) Группа 1
2) Группа 2
3) Группа 3
4) Группа 4
5) Карантин
6) Voice Vlan
7) Printers

Назначаем по аутентификации динамически VLAN на старом оборудовании. Эти вланы приходят на Cat6k и тегируются инлайн. Дальше на фаерволе уже все рубится по меткам, ну а метки мы соответственно можем назначать какие-хотим на разные состояния, просто надо VLAN добавить и к нему метку. Есть там конечно ограничения и не удобства, но что поделать когда денег менять железо нет, а хочется «красиво».
Ну так какой смысл накручивать фичи, если на файрволе можно сразу рубить по IP адресам? Больше фич — больше глюков.

Красота SGT в возможности тегировать на уровне отдельных пользователей, одновременно обходясь минимальным state на сети и на енфорсерах.
Красота SGT еще в том, что можно не просто по пользователям делать разделение. По пользователям можно было разделять политики еще лет 5 назад когда появился IDFW.
Прелесть в том, что эта метка характеризует состояние (контекст) текущего подключенного пользователя (устройства), например:
— с корпоративного ноута зашел или с домашнего
— Есть антивирус или нет
— активирован DeviceLock или нет
— Зашел через проводную/беспроводную/VPN сеть
— В каком офисе/этаже/стране зашел
— Сколько неудачных попыток аутентификации было
— Зашел с мобильного устройства (копроативного/нет), есть ли он в MDM
— и много много другого.

И метка может характеризовать любую комбинацию текущих условий.

Еще пример, 100 филиалов, в филиале по 1 программисту и надо дать им доступ к 10 сервисам ЦОД, в типичной конфигурации фильтров по IP это было бы ACL на 1000 строк, в случае SGT всего одна строка.
Это в том числе я и подразумевал. Весь профит SGT сдувает, как только начинаем вешать теги по VLANам.
Конечно функционал становится не таким гибким с вешанием на VLAN, но это позволит:
a) Подготовить этапно сеть к миграции системы авторизации на SGT;
б) Сделать систему NAC для внутренних пользователей с проверкой состояния;
в) Сегментировать доступ пользователей по группам AD (к примеру), отследить их состояние (posture) и централизованно отфильтровать на ASA в ЦОД к примеру.

Если оборудование оконечное не Cisco и не поддерживает COA, то о веб аутентификации и гостевом удобном доступе тоже можно забыть…
На текущий момент Sourcefire FirePOWER позиционируется как NGIPS и NGFW — фильтр «тонкой очистки». Позволяет предотвращать вторжения, фильтровать ложные срабатывания, получать информацию об уязвимостях в сети, настраивать политики доступа по приложениям, их компонентам, группам пользователей в АД, категориям сайтов и многое, даже МНОГОЕ другое.

Само собой, это здорово нагружает ресурсы устройства и есть смысл дополнительно задействовать фильтр грубой очистки – Cisco ASA. Да и стоимость Гбит пропускной способности наверняка покажется более привлекательной.

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

Повторюсь — Sourcefire on ASA, совсем скоро :)
В роли фильтра грубой очистки целесообразнее было бы использовать ASR1k, который, в отличие от ASA, хрен просадишь по RP/ESP. Хотя вот у него заморочек по NAT столько, что волосы дыбом встают.
ASA по производительности просадить… ну это не так просто. Конечно каждому месту установки и цели должна соответствовать и модель ASA, поставьте 5585, раз мы сравниваем с ASR… Опять же функция кластеризации до 16 устройств дает прирост и в соединениях в секунду и в максимальном количестве соединений.
Есть отличная лекция BRKSEC-3021 «Maximizing Firewall Performance», где подробно рассказывается про множество способов просадить асы, а также про их внутреннюю архитектуру :) Кластеризация ведь не линейно масштабируется, и эффективность масштабирования от кучи факторов зависит. Да и поддерживается пока исключительно на 5585.

А ASR бывают и маленькие. 1001-X довольно интересен. Весьма недорогой по сравнению с 5585-м.
Про внутреннюю архитектуру я в курсе и ограничения тоже конечно же есть (как и везде), но в production за все время моей работы в интеграторе на довольно длинном списке клиентов мне не довелось увидеть чтобы асашку просадили. Во время атаки DDOS один раз помню было что асашка вылетала и тутже подключалась Failover нода, вся соль была в том, что я только через часа полтора заметил, что у меня файловер скачет время от времени, ни пользователи никто не заметил, вот такой файловер Active/Standby. Один раз помню PIX очень старый был в одном кампусе университетском на 30000 пользователей! Кампус был ну очень завирусован и там только ICMP трафик 5 мегабит генерировалось, вот там пикс на 80% работал… Но этот пикс даже на треть этих пользователей не был рассчитан.
Тут, наверное, имеет смысл пообщаться с кем-то из TAC security team. У них много-много историй найдется.
Это да, это уникальная конечно команда. Мне и десятой части тех багов, что они рассматривали не пападется/попадалось. На то TAC у нас так и ценится, экспертиза!
Я лично за забивание гвоздей молотком. Но пассатижами тоже иногда можно :)
Молотком можно назвать хардварную платформу, производительность которой не особо зависит от числа и характера фич data plane. А еще бывают микроскопы, умеющие до фига и больше, но более нежные и тонкие :)
… и файл будет централизованно заблокирован как на уровне сети, так и на уровне всех зараженных Endpoint систем

Как происходит блокировка на уровне Endpoint систем? Какой-то клиентский софт? Какие системы поддерживаются?
Весьма закономерный вопрос, я к сожалению все моменты в статье изложить не смог, для этого книга нужна=)
Итак, если с блокировкой файлов на уровне сети все более-менее понятно и они будут заблокированы по совпадению проходящего через аплаенс файла с подозрительным хэшем, то в случае с блокировкой на хосте нужен агент.
Агент представляет собой ~15-ти мегабайтный инсталлятор FireAMP Connector, который не несет в себе никакой базы антивирусной, он также как и сетевой аплаенс собирает хеши файлов, их параметры окружения и отсылает на анализ. Соответственно при поступлении сигнала на блокировку — он помещает файл в карантин.
Причем администратор может и сам задавать в централизованных политиках какие файлы блокировать по хэшу (не только malware), также можно блокировать различные приложения (например Вы видите, что заражение произошло из-за использования Adobe Acrobat версии с уязвимостью и блокируете централизованно только эту версию).

Поддерживаются системы на данный момент Windows, MAC OSX, Android.

Для Windows поддерживаются:
Microsoft Windows XP with Service Pack 3 or later
Microsoft Windows Vista with Service Pack 2 or later
Microsoft Windows 7
Microsoft Windows 8 and 8.1 (requires FireAMP Connector 3.1.4 or later)
Microsoft Windows Server 2003
Microsoft Windows Server 2008
Microsoft Windows Server 2012 (requires FireAMP Connector 3.1.9 or later)

Для MAC: 64-bit Macs running OS X 10.7 to 10.9

Для Android: Android 2.1 or higher running on ARM and Intel Atom
Полноценный антивирус на хосте потребуется? Они там не подерутся?
FireAMP рассматривается как специализированное средство борьбы с файло-ориентированными угрозами, вирусами и malware, его эффективность более 99% на данном поле, когда у обычных антивирусов по последним исследованиям не более 40%. Тем не менее мы не позиционируем FifeAMP как Антивирусное средство, поскольку он работает только с файл-ориентированными угрозами. Рекомендация на текущий момент это иметь установленный корпоративный антивирус + FireAMP.
Работать они будут нормально вместе, FireAMP систему не нагружает, поскольку локально никакого анализа не проводит сигнатурного.
В настройках FireAMP центральной консоли надо лишь указать исключемую директорию с антивирусом, установленным на системах. Со стороны Антивируса делается такое же исключение в сторону FireAMP.

По моему опыту, я на 4 компьютера поставил в рамках домашней лаборатории только FireAMP, эффективность его работы на мой взгляд выше чем все ранее установленные коммерческие антивирусы. (Это лишь мой опыт в лаборатории, ни коим разом под официальные данные не подвожу)
Ок, спасибо
Расскажите пожалуйста про лицензирование. Какие лицензии нужны? Какие покупаются отдельно, если таковые есть?
Если говорить про устройства FirePOWER, то схема лицензирования выглядит как на картинках ниже. Если говорить про Sourcefire on ASA, то чуть проще.
Варианты Awaraness only и AMP достаточно экзотичны, так что обратить внимание стоит на столбцы NGFW и NGIPS.



Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.