Мануалы / manual по настройке:
NX Series System Administration Guide-
https://mega.co.nz/#!ZMM0XTqI!UZfviyQpcAuF2U4gznzZjYgH4ULtW76CrA79mBgqfFA
NX Series System Operators Guide-
https://mega.co.nz/#!pJVnyRxJ!qXUhCG5PFUC5CT_FWXNXFCYYEhr1Rd1vqwTTQDeIdjE
EX Series System Operators Guide-
https://mega.co.nz/#!RVEQXCgZ!maq0_9l9gIH0FzTWmC76uPScqJrGtq7uHoDOXFl2wjk
FX Series System Operators Guide-
https://mega.co.nz/#!NZlE3AIb!d0JJyIB6faocqGkbrQZr_Esa0Wo205uP94Ll6sMarOM
CM Series System Operators Guide-
https://mega.co.nz/#!sJcTUaZC!LNIjcofWx-qeBmwhy7XCx3WI4sHr-M3t7IQ6XOo_KCA
AX Series System Operators Guide-
https://mega.co.nz/#!sQ8kwAoS!_bEOCo_cO-AG9i_i1KukemzHdMVq0bOM9S6Sl7DHQIA
MAS Series System Operators Guide-
https://mega.co.nz/#!xJNQ1DAI!mdlq9_dsTIdngRv19zk-IOeJS7FZWBZcFnih3x75ehQ
Полная топология:
(Мы подключены по консоли, скорость 115200 bps)
NX > enable
NX # configure terminal
NX (config) #configuration jump-start
и второй вариант:
(Мы подключены по консоли, скорость 115200 bps)
NX > enable
NX # configure terminal
NX (config) #
NX (config) # no interface ether1 dhcp
NX (config) # interface ether1 ip address 1.1.1.1 255.240.0.0
NX (config) # ip default-gateway 1.1.1.2 ether1
hostname(config)# ntp server time.nist.gov
hostname(config)#show ntp configured
Описание портов:
После чего, можно переходить к "интеграции" в сеть (для Fireeye NX):
Пример подключения inline:
CLI:
NX (config) # policymgr interface A op-mode block fail-safe
NX (config) # policymgr interface A policy-type mixed
NX (config) # policymgr interface A re-configure
NX (config) # write memory
Проверки:
# slogin ----- ssh connect to other device from Fireeye.
# show workorders ----- show stat
# deployment check network start
# show deployment check network status
# sh network status
Система управления FireEye CMS 7400
Эту врезку в стройный алгоритм тестирования NX'a я сделал для того, чтобы объяснить некоторые щекотливые моменты совместимости управляющей части (CMS) с сенсорами и анализаторами (у нас это ЕХ и NX), а так же логику их взаимодействия.
Как показано на схемке выше, CMS принимает от ЕХ и NX "сигналы беды" параллельно с самим CMS. Если CMS нашёл беду первым (допустим, это письмо с атачментом в виде вируса), то он раздаёт работу с письмом - ЕХ'у, а с самим вредоносом разбирается NX. Результат работы сенсоров потом возвращается на CMS и дополнительно анализируется.
Такая иерархия взаимодействия логична, но накладывает не совсем понятные ограничения на версии ПО, работающего на всех трёх железках. У нас несостыковка версий NX (тут была версия 7.1) с CMS (тут была версия 6.4) вызвала ошибку добавления в CMS'е NX'а, как устройства мониторинга. Короче, нам пришлось запросить у поставщика оборудования новые ключи (нам их весьма оперативно дали), удалить старые ключи и ввести новые, что дало возможность обновить ПО. Что CMS предлагает обновиться - нам говорит скрин ниже:
Выводы:
1. Без ключей железяки не обновляются (это касается лазанья в облако за новыми актуальными данными о новых видах атак и системного ПО, которое может напряму влиять на работу самих железок и на их совместимость с упрявляющей ими
CMS. То есть, например, возможна такая ситуация, когда обновление версии сенсора приведёт к выпадению её из списка (у нас так и случилось). Это заставляет обратить внимание на своевременнную (читай, заблаговременнную) закупку ключей лицензий, а так же на то, что информацию о совместимости версий надо вытаскивать из саппортаклещами заранее (до собственно обновления).
2. В гугле описания решения проблемы, а так же обсуждения подобных проблем нам найти не удалось. То есть, покупая такую железку, надо становиться членом комьюнити и, как минимум, завести соответствующий аккаунт на сайте изготовителя, не забрасывая в далёкий ящик контакт сапорта.
Итак, CMS "увидела" NX:
Критическое состояние - потому что ключи подходят к концу срока годности.
3. Подключаем к одному из 4 слушающих (не менеджмент) портов NXа патчкорд, который воткнут в SPAN-порт коммутатора Cisco и в котором бежит копия траффика локальной сети воображаемого клиента. При настройках порта таким образом оборудование FireEye не может посылать свой траффик в него, а только получает траффик.
и...
заработало:
- поднялся порт NX и побежала статистика принятых-отправленных пакетов:
...и первым делом я делаю тест оборудования путём встроенного механизма. Я запросил выслать мне все 5 видов образцов "тестового зла":
Выпадающее окошко обьяснило, что зло - тестовое и придёт через некоторое время в виде соответствующих файлов/контента. Через несколько часов пришли и были отображены несколько тестов, вот один их них:
Как видно, с IANA'овских блоков IP нам прислали тест, иммитирующий callback малваря, ворующего данные юзеров, на хост в "мире".
Но тестирование мы ужесточили и подключили локальную сеть, через 5 минут мы получили интересный результат:
Как видно, названия малварей кликабельны и о них можно почитать, получив доступ в облако (напомню, оно в США). Доступ в это облако запросим у поставщика, допишем впечатления...
При клике на маленький красный треугольничек слева открываются детали зафиксированной malitious activity:
итак, видно кто заражен, куда отстукивает, как идёт отстук, MAC и IP адреса источника и назначения этого взаимодействия, заголовок GET HTTP протокола и все поля, версию браузера...тоесть вполне достаточно, чтобы достаточно информативно огорчить админа этой сети, сообщив ему о найденном зараженном компьютере в его сети.
Так же на предыдущем рисунке в графе "Callbacks" виден один отстук. Раскрытие меню даёт возможность ознакомиться с деталями такого отстука (это попытка зараженного компьютера (бота/зомби) связаться с управляющим им сервером), а так же посмотреть/сохранить pcap-файл (сохранённый трафик) этого отстука:
Ну и видим, что такой файл с трафиком открывается обычным Wireshark-ом. Это незаменимо для последующего анализа малваря и более детального разбора инцидента.
Для того, чтобы понять как работает оборудование в динамике, мы оставили его поработать на ночь. Dashboard за это время должен нарисовать нам первые графики.
4. Прошло некоторое время с момента запуска и тестирования оборудования. NX выявил несколько вредоносов в сетях:
Итого, выявлено 2 АРТ-атаки, скомпрометированы несколько хостов сети и это отображено в виде понятных графиков и диаграмм. При это так же доступна информация о том, какой вирус когда себя обнаруживал для оборудования:
Кроме того, есть возможность визуализации и классификации всего проходящего трафика по типам/протоколам (меню справа на всех графиках кликабельны и позволяют показать/скрыть любой вид):
Для более детального изучения найденных угроз возможно создание отчётов по атакам, активности малварей и т.д. Для примера создадим несколько отчётов:
Чтобы ознакомиться с ними - достаточно стандартных офисных пакетов или даже обычного текстового редактора:
Отчёт по Malware activity и Суммарный отчёт в Вашему вниманию. комментарии излишни. там всё подробно и красиво (на наш взгляд расписано). А вот так выглядит расширенный текстовый отчёт по атакам:
Так же имеется весьма гибкая возможность планирования (автоматизации) генерирования отчётов:
Можно задать периодичность создания отчётов, тип отчёта и способ его доставки (почта или складировать в виде файла). Для примера мы задали три вида отчётов:
Итого, за сутки NX выявил 6 разных видов зловредов в подопытной площадке. Но, согласно настройке, не позволяющей ему активно вмешиваться в трафик клиентов и блокировать их, атаки не блокировались. Скрин CMS показывает найденное в трёх видах как это выглядит со стороны:
- таблица:
- графики (мне особо понравилось):
- нечто квадратное, позволяющее оценить масштабы и относительность каждого вида угроз (у FireEye это - Treemaps):
последний тип визуализации позволяет делать разнвые срезы - по маске подсети, именам зловредов и за разные промежутки времени...вот пример таблицы "какие в сетях с маской \24 за последние 24 часа разные по именам были найдены вирусы":
Что же по зараженным хостам? смотрим общую статистику по хостам:
клик на название трояна даёт рекомендации из облачного сервиса от производителя:
...тоесть сей вид зла специалисты заморские ещё не закончили анализировать и угрозы не очевидны (но они есть!). И потому предлагается патчить браузеры, софт, фаерволлы и IDS'ы. Так же надо не читать атачменты в почте от неизвестных отправителей, не позволять ставить незнакомый софт из неизвестных источников и т.д. и если (вдруг) возникнут вопросы - можно обратиться по соответствующим контактным данным. Особенно забавна фраза про "особо отважных юзеров, которые могут попытаться самостоятельно очистить зараженную систему от зловреда" :)
5. Разграничение полномочий
NX имеет возможности по разграничению полномочий для пользователей. Есть 5 стандартных ролей и я добавил одного нового юзера в роли аналитика...
при попытке добавления нового пользователя мне выдало ошибку, которая гласила, что пробел недопустим в имени. Это запустило механизм пентеста в моей голове)) я выяснил, что недопустима так же кириллица, а экранируются все символы, кроме слешей. На введённый мной в поле имени юзера слеш система ответила мне системной ошибкой, которую по моему мнению разработчику лучше было бы убрать (она свидетельствует о раскрытии внутренних путей и плохой "защите от дурака" или фаззинга). Это не критично, скажем, для рядового свича, но кто знает, вдруг - хакер получит удалённый рабочий стол на ПК админа и попытается закинуть свой зловред прямо через GUI NX'а...моё мнение такое - если графический интерфейс есть - он должен скрыть от его пользователя всю системную часть сервера. Ведь именно через выявление недокументированных и плохо фильтруемых параметров команд в IOS ломают, например, Cisco...вот скриншот ошибки:
Присутствие поля VLAN намекнуло о мультивлановой сетевухе сервера, но не проверялось. Если да - то очень хорошо, т.к. это позволяет локализовать домен коллизий, ограничив доступ для каждой учётки ещё и тегом виртуальной локальной сети. Кроме того, можно ограничить доступ по учтной записи так же и по сети с произвольной маской, а так же менять пароли.
6. Уведомления
NX для уведомлений использует некое подобие матрицы, которая весьма гибко позволяет настраивать триггеры при наступлении разных событий:
При выборе какого-то чекбокса справа выпадает менюшка для настройки именно этого вида уведомлений (в зависимости от протокола эти менюшки отличаются). Соответственно, в нижней части можно добавлять те серверы, которые будут получать такие уведомления.
Так же имеется возможность получения от системы уведомлений по почте:
Уведомления могут быть отфильтрованы по группам (чекбоксы на скрине) для каждого почтового ящика.
Вывод: отчёты и настройка уведомлений достаточно гибкая и понятная. Спамить FireEye не будет, а дежурная смена сможет легко и быстро локализовать проблему.
Для дополнительной защиты и обеспечения безопасной работы с оборудованием по HTTPS есть возможность подключить сертификаты и ключевые данные:
NX поддерживает возможность работы с интсрументарием классификации и идентификации малварей, который называется YARA. Это полезный и мощный инструмент для того, кто хочет провести форенсику. Подробнее о YARA - тут и тут. Его используют такие гиганты, как virustotal, volatility и т.д. В NX есть возможность задать имя файла с шаблоном для разных типов файлов (всего около 30 стандартных расширений):
7. 7400 EX - устройство для защиты почтового информационного обмена.
Подключен 7400 EX был аналогично в режиме "только слушаю" к SPAN-порту коммутатора, который принимал трафик почтового тестового почтового домена.
После начальной настройки по аналогии с NX и захода по http выводится стандартное (для всех образцов FireEye это окно почти одинаковое) приглашение к авторизации с выводом настраиваемогоустрашения уведомления о том, что мы пытаемся досутпиться на не рядовую железку в сети...нет чтобы имитировать принтер)):
Интересен момент отсутствия средств защиты от подбора аутентификационных данных формы авторизации в сочетании с протоколом HTTP по умолчанию. Ни капчи, ни чего-либо подобного тут нет, то есть разработчики как бы не ожидают инсайдерских угроз, MITM и т.д. После начального входа под админскими правами я открываю https-сессию:
Дефолтный дашборд EX'а выглядит так:
он так же гибок и информативен, обображает колличества отсканированных почтовых ссобщений, найденных в общем слушаемом потоке зараженных вирусами потчтовых сообщений, вложений. Сортирует почту по источникам, которых касались алерты и визуализирует эти данные (2 нижних графика пока пусты, ведь мы же только начали тест).
Ключи у нас отсутствовали и через несколько часов ожидания в фильтруемом почтовом трафике первого "опасного" письма мы поняли важны момент:
ЕХ не работает по сути без ключей, пропуская всё подряд!
Это его отличие в худшую сторону от NX'a, который ловит всё, только не обновляет базы при просроченных ключах. Вывод прост - если не собираетесь продлевать ключи - позаботьтесь до окончания ключей об альтернативе EX'у для звщиты от атак по почте.
Далее пробежимся по вкладкам ЕХа:
- алерты могут оборажаться по времени появления, фильтроваться за какой-то промежуток или по встречаемым частям текста (например, можно найти определённый вредонос). По каждому из полей возможна сортировка.
- карантин так же может быть отфильтрован по времени, искомому тексту и параметрам писем, в которых он найден. По каждому из полей возможна сортировка.
- окно настроек подобно NX'у, но содержит меню которые уникальны в связи с спецификой ЕХа - работа с почтой:
ЕХ имеет матрицу событий немного более узкую, чем его собрат NX, а именно - он информирует только при выявления малваря:
Окно настроек агента доставки почты выглядит таким образом:
Это окно надо в том случае, если ЕХ настраивается как мейл-релей (тоесть будет принимать почту и передавать её дальше после проверки). У нас не этот случай, так что мы тут оставили всё как есть.
Наконец, наверно, самое важное окно ЕХа - окно настроек фильтрации почты:
Тут подтвердилось опасение, что без лицензии атачи не проверяются вообще. Остальное выглядит хорошо и работает. Почту можно дропать 4 разными типами, фантастика.
Окно настроек ассоциаций программ для открытия атачментов к почте разными приложениями - весьма длинное и даёт возможность открыть что угодно чем угодно. Я бы открыл вордовский документ свежезалитым шеллом))...интересно, завопит ли защитный механизм ЕХа при такой попытке (и есть ли такой в природе на виртуальных машинках)?
Кстати, окно виртуальных машин такое же статичное как и в NX, содержит 5 разных образов виндовс-машин. Нет, действие малварей на MAC и Unix-системы не изучается:
Окно сертификатов имеет такой вид:
Окно отчётов выглядит так:
Мы получили новые ключи и ввели их:
Как видно из скриншота, каждый ключ активирует определённую "фичу", которых у нас 6. По всей видимости, ЕХ использует для антивирусной проверки движок антивируса Sophos. Оборудование "ожило" после того, как ключи были введены. Это обображено в политиках фильтрации почты:
..а так же в окне About, через которое после ввода ключей надо первым делом обновить все компоненты ЕХа:
Мы попробовали обновить то, что можно:
NX Series System Administration Guide-
https://mega.co.nz/#!ZMM0XTqI!UZfviyQpcAuF2U4gznzZjYgH4ULtW76CrA79mBgqfFA
NX Series System Operators Guide-
https://mega.co.nz/#!pJVnyRxJ!qXUhCG5PFUC5CT_FWXNXFCYYEhr1Rd1vqwTTQDeIdjE
EX Series System Operators Guide-
https://mega.co.nz/#!RVEQXCgZ!maq0_9l9gIH0FzTWmC76uPScqJrGtq7uHoDOXFl2wjk
FX Series System Operators Guide-
https://mega.co.nz/#!NZlE3AIb!d0JJyIB6faocqGkbrQZr_Esa0Wo205uP94Ll6sMarOM
CM Series System Operators Guide-
https://mega.co.nz/#!sJcTUaZC!LNIjcofWx-qeBmwhy7XCx3WI4sHr-M3t7IQ6XOo_KCA
AX Series System Operators Guide-
https://mega.co.nz/#!sQ8kwAoS!_bEOCo_cO-AG9i_i1KukemzHdMVq0bOM9S6Sl7DHQIA
MAS Series System Operators Guide-
https://mega.co.nz/#!xJNQ1DAI!mdlq9_dsTIdngRv19zk-IOeJS7FZWBZcFnih3x75ehQ
Полная топология:
Для первоначальной настройки (настройка mgmt) два варианта:
(Мы подключены по консоли, скорость 115200 bps)
NX > enable
NX # configure terminal
NX (config) #configuration jump-start
и второй вариант:
(Мы подключены по консоли, скорость 115200 bps)
NX > enable
NX # configure terminal
NX (config) #
NX (config) # no interface ether1 dhcp
NX (config) # interface ether1 ip address 1.1.1.1 255.240.0.0
NX (config) # ip default-gateway 1.1.1.2 ether1
Для настройки ntp:
hostname(config)# ntp enablehostname(config)# ntp server time.nist.gov
hostname(config)#show ntp configured
Для сохранения конфигурации:
NX #write memoryНастройка DNS:
hostname(config)# ip name-server 8.8.8.8Описание портов:
После чего, можно переходить к "интеграции" в сеть (для Fireeye NX):
Пример подключения inline:
NX (config) # policymgr interface A op-mode block fail-safe
NX (config) # policymgr interface A policy-type mixed
NX (config) # policymgr interface A re-configure
NX (config) # write memory
Проверки:
# slogin ----- ssh connect to other device from Fireeye.
# show workorders ----- show stat
# deployment check network start
# show deployment check network status
# sh network status
Система управления FireEye CMS 7400
Эту врезку в стройный алгоритм тестирования NX'a я сделал для того, чтобы объяснить некоторые щекотливые моменты совместимости управляющей части (CMS) с сенсорами и анализаторами (у нас это ЕХ и NX), а так же логику их взаимодействия.
Как показано на схемке выше, CMS принимает от ЕХ и NX "сигналы беды" параллельно с самим CMS. Если CMS нашёл беду первым (допустим, это письмо с атачментом в виде вируса), то он раздаёт работу с письмом - ЕХ'у, а с самим вредоносом разбирается NX. Результат работы сенсоров потом возвращается на CMS и дополнительно анализируется.
Такая иерархия взаимодействия логична, но накладывает не совсем понятные ограничения на версии ПО, работающего на всех трёх железках. У нас несостыковка версий NX (тут была версия 7.1) с CMS (тут была версия 6.4) вызвала ошибку добавления в CMS'е NX'а, как устройства мониторинга. Короче, нам пришлось запросить у поставщика оборудования новые ключи (нам их весьма оперативно дали), удалить старые ключи и ввести новые, что дало возможность обновить ПО. Что CMS предлагает обновиться - нам говорит скрин ниже:
Выводы:
1. Без ключей железяки не обновляются (это касается лазанья в облако за новыми актуальными данными о новых видах атак и системного ПО, которое может напряму влиять на работу самих железок и на их совместимость с упрявляющей ими
CMS. То есть, например, возможна такая ситуация, когда обновление версии сенсора приведёт к выпадению её из списка (у нас так и случилось). Это заставляет обратить внимание на своевременнную (читай, заблаговременнную) закупку ключей лицензий, а так же на то, что информацию о совместимости версий надо вытаскивать из саппорта
2. В гугле описания решения проблемы, а так же обсуждения подобных проблем нам найти не удалось. То есть, покупая такую железку, надо становиться членом комьюнити и, как минимум, завести соответствующий аккаунт на сайте изготовителя, не забрасывая в далёкий ящик контакт сапорта.
Итак, CMS "увидела" NX:
Критическое состояние - потому что ключи подходят к концу срока годности.
3. Подключаем к одному из 4 слушающих (не менеджмент) портов NXа патчкорд, который воткнут в SPAN-порт коммутатора Cisco и в котором бежит копия траффика локальной сети воображаемого клиента. При настройках порта таким образом оборудование FireEye не может посылать свой траффик в него, а только получает траффик.
и...
заработало:
- поднялся порт NX и побежала статистика принятых-отправленных пакетов:
...и первым делом я делаю тест оборудования путём встроенного механизма. Я запросил выслать мне все 5 видов образцов "тестового зла":
Выпадающее окошко обьяснило, что зло - тестовое и придёт через некоторое время в виде соответствующих файлов/контента. Через несколько часов пришли и были отображены несколько тестов, вот один их них:
Как видно, с IANA'овских блоков IP нам прислали тест, иммитирующий callback малваря, ворующего данные юзеров, на хост в "мире".
Но тестирование мы ужесточили и подключили локальную сеть, через 5 минут мы получили интересный результат:
Как видно, названия малварей кликабельны и о них можно почитать, получив доступ в облако (напомню, оно в США). Доступ в это облако запросим у поставщика, допишем впечатления...
При клике на маленький красный треугольничек слева открываются детали зафиксированной malitious activity:
итак, видно кто заражен, куда отстукивает, как идёт отстук, MAC и IP адреса источника и назначения этого взаимодействия, заголовок GET HTTP протокола и все поля, версию браузера...тоесть вполне достаточно, чтобы достаточно информативно огорчить админа этой сети, сообщив ему о найденном зараженном компьютере в его сети.
Так же на предыдущем рисунке в графе "Callbacks" виден один отстук. Раскрытие меню даёт возможность ознакомиться с деталями такого отстука (это попытка зараженного компьютера (бота/зомби) связаться с управляющим им сервером), а так же посмотреть/сохранить pcap-файл (сохранённый трафик) этого отстука:
Ну и видим, что такой файл с трафиком открывается обычным Wireshark-ом. Это незаменимо для последующего анализа малваря и более детального разбора инцидента.
Для того, чтобы понять как работает оборудование в динамике, мы оставили его поработать на ночь. Dashboard за это время должен нарисовать нам первые графики.
4. Прошло некоторое время с момента запуска и тестирования оборудования. NX выявил несколько вредоносов в сетях:
Итого, выявлено 2 АРТ-атаки, скомпрометированы несколько хостов сети и это отображено в виде понятных графиков и диаграмм. При это так же доступна информация о том, какой вирус когда себя обнаруживал для оборудования:
Кроме того, есть возможность визуализации и классификации всего проходящего трафика по типам/протоколам (меню справа на всех графиках кликабельны и позволяют показать/скрыть любой вид):
Для более детального изучения найденных угроз возможно создание отчётов по атакам, активности малварей и т.д. Для примера создадим несколько отчётов:
Чтобы ознакомиться с ними - достаточно стандартных офисных пакетов или даже обычного текстового редактора:
Отчёт по Malware activity и Суммарный отчёт в Вашему вниманию. комментарии излишни. там всё подробно и красиво (на наш взгляд расписано). А вот так выглядит расширенный текстовый отчёт по атакам:
Так же имеется весьма гибкая возможность планирования (автоматизации) генерирования отчётов:
Можно задать периодичность создания отчётов, тип отчёта и способ его доставки (почта или складировать в виде файла). Для примера мы задали три вида отчётов:
Итого, за сутки NX выявил 6 разных видов зловредов в подопытной площадке. Но, согласно настройке, не позволяющей ему активно вмешиваться в трафик клиентов и блокировать их, атаки не блокировались. Скрин CMS показывает найденное в трёх видах как это выглядит со стороны:
- таблица:
- графики (мне особо понравилось):
- нечто квадратное, позволяющее оценить масштабы и относительность каждого вида угроз (у FireEye это - Treemaps):
последний тип визуализации позволяет делать разнвые срезы - по маске подсети, именам зловредов и за разные промежутки времени...вот пример таблицы "какие в сетях с маской \24 за последние 24 часа разные по именам были найдены вирусы":
Что же по зараженным хостам? смотрим общую статистику по хостам:
клик на название трояна даёт рекомендации из облачного сервиса от производителя:
...тоесть сей вид зла специалисты заморские ещё не закончили анализировать и угрозы не очевидны (но они есть!). И потому предлагается патчить браузеры, софт, фаерволлы и IDS'ы. Так же надо не читать атачменты в почте от неизвестных отправителей, не позволять ставить незнакомый софт из неизвестных источников и т.д. и если (вдруг) возникнут вопросы - можно обратиться по соответствующим контактным данным. Особенно забавна фраза про "особо отважных юзеров, которые могут попытаться самостоятельно очистить зараженную систему от зловреда" :)
5. Разграничение полномочий
NX имеет возможности по разграничению полномочий для пользователей. Есть 5 стандартных ролей и я добавил одного нового юзера в роли аналитика...
при попытке добавления нового пользователя мне выдало ошибку, которая гласила, что пробел недопустим в имени. Это запустило механизм пентеста в моей голове)) я выяснил, что недопустима так же кириллица, а экранируются все символы, кроме слешей. На введённый мной в поле имени юзера слеш система ответила мне системной ошибкой, которую по моему мнению разработчику лучше было бы убрать (она свидетельствует о раскрытии внутренних путей и плохой "защите от дурака" или фаззинга). Это не критично, скажем, для рядового свича, но кто знает, вдруг - хакер получит удалённый рабочий стол на ПК админа и попытается закинуть свой зловред прямо через GUI NX'а...моё мнение такое - если графический интерфейс есть - он должен скрыть от его пользователя всю системную часть сервера. Ведь именно через выявление недокументированных и плохо фильтруемых параметров команд в IOS ломают, например, Cisco...вот скриншот ошибки:
Присутствие поля VLAN намекнуло о мультивлановой сетевухе сервера, но не проверялось. Если да - то очень хорошо, т.к. это позволяет локализовать домен коллизий, ограничив доступ для каждой учётки ещё и тегом виртуальной локальной сети. Кроме того, можно ограничить доступ по учтной записи так же и по сети с произвольной маской, а так же менять пароли.
6. Уведомления
NX для уведомлений использует некое подобие матрицы, которая весьма гибко позволяет настраивать триггеры при наступлении разных событий:
При выборе какого-то чекбокса справа выпадает менюшка для настройки именно этого вида уведомлений (в зависимости от протокола эти менюшки отличаются). Соответственно, в нижней части можно добавлять те серверы, которые будут получать такие уведомления.
Так же имеется возможность получения от системы уведомлений по почте:
Уведомления могут быть отфильтрованы по группам (чекбоксы на скрине) для каждого почтового ящика.
Вывод: отчёты и настройка уведомлений достаточно гибкая и понятная. Спамить FireEye не будет, а дежурная смена сможет легко и быстро локализовать проблему.
Для дополнительной защиты и обеспечения безопасной работы с оборудованием по HTTPS есть возможность подключить сертификаты и ключевые данные:
NX поддерживает возможность работы с интсрументарием классификации и идентификации малварей, который называется YARA. Это полезный и мощный инструмент для того, кто хочет провести форенсику. Подробнее о YARA - тут и тут. Его используют такие гиганты, как virustotal, volatility и т.д. В NX есть возможность задать имя файла с шаблоном для разных типов файлов (всего около 30 стандартных расширений):
7. 7400 EX - устройство для защиты почтового информационного обмена.
Подключен 7400 EX был аналогично в режиме "только слушаю" к SPAN-порту коммутатора, который принимал трафик почтового тестового почтового домена.
После начальной настройки по аналогии с NX и захода по http выводится стандартное (для всех образцов FireEye это окно почти одинаковое) приглашение к авторизации с выводом настраиваемого
Интересен момент отсутствия средств защиты от подбора аутентификационных данных формы авторизации в сочетании с протоколом HTTP по умолчанию. Ни капчи, ни чего-либо подобного тут нет, то есть разработчики как бы не ожидают инсайдерских угроз, MITM и т.д. После начального входа под админскими правами я открываю https-сессию:
Дефолтный дашборд EX'а выглядит так:
он так же гибок и информативен, обображает колличества отсканированных почтовых ссобщений, найденных в общем слушаемом потоке зараженных вирусами потчтовых сообщений, вложений. Сортирует почту по источникам, которых касались алерты и визуализирует эти данные (2 нижних графика пока пусты, ведь мы же только начали тест).
Ключи у нас отсутствовали и через несколько часов ожидания в фильтруемом почтовом трафике первого "опасного" письма мы поняли важны момент:
ЕХ не работает по сути без ключей, пропуская всё подряд!
Это его отличие в худшую сторону от NX'a, который ловит всё, только не обновляет базы при просроченных ключах. Вывод прост - если не собираетесь продлевать ключи - позаботьтесь до окончания ключей об альтернативе EX'у для звщиты от атак по почте.
Далее пробежимся по вкладкам ЕХа:
- алерты могут оборажаться по времени появления, фильтроваться за какой-то промежуток или по встречаемым частям текста (например, можно найти определённый вредонос). По каждому из полей возможна сортировка.
- карантин так же может быть отфильтрован по времени, искомому тексту и параметрам писем, в которых он найден. По каждому из полей возможна сортировка.
- окно настроек подобно NX'у, но содержит меню которые уникальны в связи с спецификой ЕХа - работа с почтой:
ЕХ имеет матрицу событий немного более узкую, чем его собрат NX, а именно - он информирует только при выявления малваря:
Окно настроек агента доставки почты выглядит таким образом:
Это окно надо в том случае, если ЕХ настраивается как мейл-релей (тоесть будет принимать почту и передавать её дальше после проверки). У нас не этот случай, так что мы тут оставили всё как есть.
Наконец, наверно, самое важное окно ЕХа - окно настроек фильтрации почты:
Тут подтвердилось опасение, что без лицензии атачи не проверяются вообще. Остальное выглядит хорошо и работает. Почту можно дропать 4 разными типами, фантастика.
Окно настроек ассоциаций программ для открытия атачментов к почте разными приложениями - весьма длинное и даёт возможность открыть что угодно чем угодно. Я бы открыл вордовский документ свежезалитым шеллом))...интересно, завопит ли защитный механизм ЕХа при такой попытке (и есть ли такой в природе на виртуальных машинках)?
Кстати, окно виртуальных машин такое же статичное как и в NX, содержит 5 разных образов виндовс-машин. Нет, действие малварей на MAC и Unix-системы не изучается:
Окно сертификатов имеет такой вид:
Окно отчётов выглядит так:
Мы получили новые ключи и ввели их:
Как видно из скриншота, каждый ключ активирует определённую "фичу", которых у нас 6. По всей видимости, ЕХ использует для антивирусной проверки движок антивируса Sophos. Оборудование "ожило" после того, как ключи были введены. Это обображено в политиках фильтрации почты:
..а так же в окне About, через которое после ввода ключей надо первым делом обновить все компоненты ЕХа:
Мы попробовали обновить то, что можно:
