Cканер кода SonarQube

Всем привет.

Большинство кодировщиков пишут, как им часто кажется, совершенный код. Некоторые уже используют в IDE инструменты статического анализа, такие как ESLint, которые выявляют возможности улучшения каких-то частей кода в процессе его написания. Практика хорошая, и не стоит от нее отказываться.

Сегодня будет представлен инструмент для повышения качества кода, выводящий этот процесс на новый уровень - SonarQube. Вы узнаете:

• что такое SonarQube;
• как установить этот инструмент на локальный компьютер;
• как сканировать файлы проекта;
• как провести анализ проекта в SonarQube.

В статье будет рассмотрена открытая версия для сообщества. SonarQube невероятно полезный инструмент, так что я с радостью поделюсь своими знаниями о нем.

Что такое SonarQube?

SonarQube - это платформа с открытым исходным кодом, разработанная SonarSource, для непрерывной оценки качества кода путем статического анализа.

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

Завершив сканирование кода, о чем будет рассказано далее, SonarQube формирует отчет, который можно посмотреть в GUI через браузер. Все обнаруженные проблемы представляют собой “интерактивные тикеты”, позволяющие писать к ним комментарии, делегировать их другим пользователям, открывать или закрывать и т. д.

К подробному описанию проблемы сразу же прилагается соответствующий код.

SonarQube также объясняет суть проблемы при нажатии на соответствующую ссылку “Why is this an issue?” .

И волки сыты, и овцы целы!

Всем привет.

Играясь с полигоном ELK в качестве активного выявление угроз я обнаружил любопытную заметку. В ней говорилось что деятельность инфобеза в качестве охотников за угрозами можно уместить в 6 пунктов, заимствованных из отчета, опубликованного компанией Lockheed Martin (Eric M. Hutchins, Michael J. Cloppert, Rohan M. Amin, Ph.D., Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains, https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/LM-White-Paper-Intel-Driven-Defense.pdf):

• Detect (oбнаруживать);
• Deny (отказывать);
• Disrupt (нарушать);
• Degrade (ухудшать);
• Deceive (обманывать);
• Destroy (уничтожать).

Так вот по пункту Deny сообщалось следущее:

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

Тут я вспомнил свою историю, которая оказалась весьма похожа. Итак, руководящий орган поставил перед нашей бухгалтерией емкую задачу по сбору данных в сжатые сроки. Все бы ничего, но данные требовали консолидации со всей области, а это без малого 28 филиалов банка. Разумеется к часу Х данные были готовы на 90%, посылать непроверенные данные не хотелось, а нарушать сроки их подачи тем более. Над местным главбухом навис дамоклов меч. Они обратились к ИТ за помощью, т.е. ко мне.

Я решил что будет для всех правильно перевести ситуацию в чисто техническую - реализовать идею которая лишила бы руководство наверху рычага наказания нашего бухгалтера, хотя бы временно. Итак, я предложил взять готовые данные дополнить их  пустышкой до 100% и все красиво поместить в архив. В самом архиве был намеренно поврежден header чтобы архив не смог корректно распаковаться у адресата. И в таком виде файл был отправлен наверх. Разумеется адресат минут через 20 сообщил что архив (при пересылке?) был поврежден, срочно повторите отправку и т.д. Ай, я, яй, как же так... конечно сейчас  повторим. Вы уже поняли что за это время бухгалтерия дополучила недостающие данные, и уже новый но правильный архив бы "повторно" и торжественно отправлен адресату. 

Каюсь, но как говорится, остались и волки сыты и овцы целы!

Удачи.

Расследование взлома компьютера с Windows, CTF #2.

Всем привет.

Вторая часть серии CyberDefenders.org представляет собой еще более увлекательную криминалистическую CTF. Как обычно, цель состоит в том, чтобы ответить на ряд типичных вопросов реагирования на инциденты, связанные с заражением вредоносным ПО.

Вам предоставляются следующие файлы, которые помогут в анализе:

- дамп необходимых лог-файлов в формате Json (для анализа будем использовать jq)

- ELK с графическим интерфейсом Kibana

Поэтoму на этот раз образ весит все 7 Гб. Скачали? Тогда начнем.

1) Процесс Threat Hunting обычно начинается с того, что аналитик выдвигает гипотезу о возможном векторе компрометации или методах, используемых злоумышленником. В этом сценарии ваша первоначальная гипотеза выглядит следующим образом: 

«Злоумышленник использовал механизм подписки WMI для обеспечения устойчивости в инфраструктуре». Проверьте эту гипотезу и найдите имя потребителя событий WMI, используемого злоумышленником для сохранения своей позиции.

Выполним запрос:

cat cyberpolygon-2020-data.json | jq 'select(._source.event_id=="5861")'

или отфильтруем в Кibana:

event_id:5861

Ответ:

PowerControl Consumer

Пишем правило для Snort.

Всем привет.

Загляняем сегодня к одной из самых популярных систем IDS в инфомире - Snort. Snort используется для сигнатур или правил, которые связывают между собой группу элементов (так называемые параметры правил), истинность которых является обязательным условием срабатывания правила. Основные параметры занимаются распознаванием элементов, которые либо относятся к содержимому (параметры правил содержимого в терминологии Snort), либо нет (параметры правил вне содержимого). Примерами параметров правил вне содержимого могут служить определенные флаги, значения TCP- или IP-заголовков и размер пакета. Например, параметр flow:established,to_client выбирает пакеты, которые входят в сеанс TCP, инициированный сервером, и предназначены для клиента. Еще один пример, dsize:200, выбирает пакеты, содержимое которых равно 200 байт.

Как я писал ранее, IDS Suricata, она же является развитием Snort, и которая является основой в пакете SELKS использует синтаксис правил Snort. Поэтому давайте в качестве примера создадим для Snort простое правило, которое позволяет обнаружить вредонос, который генерирует сетевой трафик, состоящий из HTTP-запроса типа GET. Когда браузеры или другие HTTP-приложения делают запрос, они указывают поле заголовка User-Agent, чтобы связаться с программой, которая используется для этого запроса. Обычно данное поле начинается со слова Mozilla (по историческим причинам) и может выглядеть как Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1). Здесь содержится информация о версии браузера и ОС.

Пусть наш вредонос формирует такой GET-запрос:

GET /index.htm HTTP 1.1

Accept: */*

User-Agent: Wefa7e

Cache-Control: no

Поле User-Agent, которое используется рассмотренным вредоносом, равно Wefa7e. Это характерное значение, и с его помощью можно распознавать вредоносный трафик. Разумеется более надежный вредонос сформирует это поле под любой браузер, но для нашего примера он будет таким простым. Следующая сигнатура нацелена на необычные строки User-Agent, которые использовались запущенным нами вредоносом:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TROJAN Malicious User-Agent"; content:"|0d 0a|User-Agent\: Wefa7e"; classtype:trojan-activity; sid:2000001; rev:1;)

В Snort правила состоят из двух частей: заголовка и параметров. Заголовок содержит действие (обычно alert), протокол, исходный и конечный IP-адреса, а также порты источника и адресата.

В правилах принято использовать переменные, которые позволяют адаптироваться под текущую среду: $HOME_NET и $EXTERNAL_NET определяют внутренний и внешний диапазоны IP-адресов, а $HTTP_PORTS указывает порты, которые следует интерпретировать как HTTP-трафик. В данном случае заголовок $HOME_NET any ->$EXTERNAL_NET $HTTP_PORTS соответствует исходящему трафику, проходящему через HTTP-порты, так как знак -> говорит о том, что правило относится лишь к одному направлению передачи данных.

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

В сочетании с sid служит уникальным идентификатором версии правила Внутри выражения content используется вертикальная черта (|), которая определяет начало и конец записи в шестнадцатеричном формате. Все, что находится между этими символами, интерпретируется в качестве шестнадцатеричных значений. Таким образом, |0d 0a| представляет разрыв между HTTP-заголовками.

Еще раз про SELKS.

Всем привет.

Анализ пакетов - это ключевой компонент для реализации систем обнаружения сетевых вторжений (IDS) и для мониторинга безопасности сети. Доступны разные средства с открытым исходным кодом для обнаружения сетевых вторжений, которые обрабатывают запись пакетов для поиска известных сигнатур потенциальных сетевых вторжений и вредоносных действий. Используя функцию записи пакетов службы наблюдения за сетями, вы можете анализировать сеть для поиска вредоносных вторжений и уязвимостей.

В числе средств с открытым исходным кодом на слуху система обнаружения сетевых вторжений Suricata, которая использует наборы правил формата Snort для отслеживания сетевого трафика и создает оповещения при обнаружении подозрительных событий. Механизм Suricata является многопоточным, что позволяет еще быстрее и эффективнее выполнять анализ сетевого трафика. 

Дополнительные сведения о системе Suricata и ее возможностях можно узнать на веб-сайте https://suricata-ids.org/.

Но неплохо бы иметь под рукой также схему хранения и анализа пакетов перехваченных Suricata. Следуя принципу open source на эту роль напрашивается ELK стек. Suricata предоставляет возможность записи пакетов, которая используется для обнаружения сетевых вторжений. Suricata обрабатывает запись пакетов и формирует оповещения, если обнаруживает пакеты, соответствующие наборы правил для известных угроз. Эти предупреждения сохраняются в файле журнала на локальном компьютере. А Elastic Stack позволяет индексировать журналы, созданные Suricata, и использовать их для создания панели мониторинга в Kibana, которая визуализирует информацию из журналов для быстрого анализа потенциальных уязвимостей сети.

В принципе в интернет есть большое количество сценариев настройки среды для обнаружения сетевых вторжений с помощью Suricata и Elastic Stack. Вам будет интересно попробовать все сделать вручную и очень удобно для полного управления процессом. Как вы понимаете, я так не делал. По разным причинам. Одна из них это наличие в интернет пакета SELKS. Это тот же ELK-стек плюс Suricata, плюс еще два полезных инструмента мониторинга от компании Stamus. 

Напомню, что SELKS состоит из 6-ти компонентов:

S - Suricata IDPS - http://suricata-ids.org/

E - Elasticsearch - https://www.elastic.co/products/elasticsearch

L - Logstash - https://www.elastic.co/products/logstash

K - Kibana - https://www.elastic.co/products/kibana

S - Scirius - https://github.com/StamusNetworks/scirius

EveBox - https://evebox.org/

Оптимизация ELK стека.

Всем привет.

Как любая сложная система ELK стек нуждается в оптимизации своей работы, т.е. настроек по умолчанию. Для нормальной работы ELK стека приведенные ниже рекомендации по оптимизации работы Elasticsearch будут одинаково справедливы как для кластерной схемы так и без нее. Что же следует сделать?

1) Установить размер heap size.

Так как Elasticsearch написан на Java, то для работы необходимо настроить размер «кучи» (heap size).  В каталоге установки Elasticsearch имеется файл jvm.options, в котором уже указаны размеры, по умолчанию - это 1 Гб. Однако, для настройки рекомендуется указать новые параметры в файле каталога jvm.options.d, который находится там же.

-Xms16g

-Xmx16g

Пример выше использует минимальный Xms и максимальный Xmx размер heap size, равный 16 Гб. Для настройки данных параметров следует использовать следующие рекомендации:

- установите значения Xmx и Xms не более 50% от имеющейся физической памяти узла. Оставшуюся память Elasticsearch будет использовать для других целей. Чем больше heap size, тем меньше памяти используется под системные кеш. JVM и память: чем больше тем лучше? Не всегда.

Xmx & Xms <= 31Gb

- устанавите значение не более того значения, которое использует JVM для сжатия указателей, он же compressed object pointers. Данное значение составляет около 32 Гб. Стоит также отметить, что рекомендуется ограничивать heap size еще одним параметром JVM, а именно zero-based compressed oops (обычно размер около 26 Гб). 

2) Отключить подкачку.

Подкачка негативно сказывается на производительности и стабильности работы Elasticsearch, ведь система может выгрузить страницы JVM на диск.

Есть несколько вариантов работы с подкачкой:

1. Полное отключение подкачки. Перезапуск Elasticseach при этом не требуется.

sudo swapoff -a

2. Ограничение подкачки через значение vm.swappiness=1 для sysctl.

3. Использование mlockall для блокировки адресного пространства в оперативной памяти.

Чтобы включить mlockall в конфигурации Elasticseach elasticsearch.yml указываем для параметра bootstrap.memory_lock значение true:

bootstrap.memory_lock: true

Перезапускаем Elasticsearch и проверяем настройки через запрос к любому узлу:

curl -X GET "http://192.168.1.10:9200/_nodes?filter_path=**.mlockall&pretty"

Если перезапуск Elasticsearch завершился ошибкой вида:

[1] bootstrap checks failed

[1]: memory locking requested for elasticsearch process but memory is not locked

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

1. Установите значение параметра MAX_LOCKED_MEMORY как unlimited в /etc/sysconfig/elasticsearch для rpm или /etc/default/elasticsearch для dep.

2. Если вы используете systemd для запуска Elasticsearch, то лимиты должны быть указаны через настройку параметра LimitMEMLOCK. Для этого выполните команду:

sudo systemctl edit elasticsearch

и укажите следующее значение:

[Service]

LimitMEMLOCK=infinity

Полигон ELK.

Всем привет.

Использование rsyslog для хранения log-сообщений сетевого оборудования, и loganalyzer для их отображения, обозначило необходимость поиска, соответствующей современным требованиям, альтернативы. В результате анализа различных решений был сделан выбор в пользу open-source компонентов стека ELK. Был ли этот выбор полностью осознанным - скорее нет, ибо популярность ELK стека бьет все рекорды. Поэтому не пощупать его своими руками было бы неразумно. Тем более у меня была давняя задача разобраться с IDS SELKS изнутри, где ELK, как вы заметили, является основой.

Итак, основными элементами ELK являются: Elasticsearch (search engine – для хранения и быстрого поиска структурированных данных), Logstash (collector – для приема в различном формате данных, их фильтрации и преобразования, и последующей отправки в различные базы данных) и Kibana (инструмент для визуализации), которые и составляют акроним ELK. Это в классическом варианте исходя из названия, но в последнее время сюда активно подмешивают Filebeat, который идет как в в паре с Logstash, так и вместо него.

Подробное описание работы этих компонентов не планировалось в рамках данной статьи. Интересующая информация по стеку очень хорошо представлена на официальном сайте, в т.ч. в виде подробной документации, а также в огромном количестве статей и публикаций. Именно по ним я поднимал весь стек пошагово. За основу была взята подробная инструкция здесь, ему помагал материал отсюда и отсюда. Каждый автор решал свою практичечкую задачу поэтому мне пришлось компилировать нужное по ходу. Обычно ELK разворачивают на одном сервере  (как с SELKS), но я решил что это будет слишком просто, поэтому  в моем полигоне Elasticsearch один хост, Kibana второй хост, и Logstash+FileBeat третий. До кластера руки не дошли, но я уверен, что это будет создать не так уж и трудно.

В ходе работ было проведено: 

• установка Elasticsearch
• установка Kibana
• установка Logstash
• установка Filebeat для отправки логов в Logstash
• установка и настройка Winlogbeat
• установка плагина Filebeat для отправки netflow Cisco
• настройка безопасности и авторизация в Kibana (несколько вариантов)
• проксирование подключений к Kibana через Nginx
• автоматическая очистка индексов в elasticsearch.

А теперь мои шаги:

1) Проверить для всех хостов стека с Ubuntu 

sudo timedatectl set-timezone Europe/Kiev

sudo apt-get install --reinstall systemd

2) Установить для всех хостов ELK стека

sudo apt-get install apt-transport-https

sudo wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a  /etc/apt/sources.list.d/elastic-7.x.list

# Также ставим JDK for Elasticsearch (Host0) & Logstash (Host1)

sudo apt install default-jdk -y

java -version

3) Настройка Elasticsearch (Host0, IP 192.168.1.11, port 9200,9300) 

- /etc/elasticsearch/elasticsearch.yml:

network.host: 0.0.0.0 (or 192.168.1.11)

http.port: 9200

transport.host: localhost

transport.tcp.port: 9300

SELKS как ELK для Suricata.

Всем привет.

Популярное на сегодня понятие SIEM (Security information and event management) - объединение двух терминов, обозначающих область применения ПО: SIM (Security information management) - управление информационной безопасностью, и SEM (Security event management) - управление событиями безопасности. Технология SIEM обеспечивает анализ в реальном времени событий (тревог) безопасности, исходящих от сетевых устройств и приложений. SIEM представлено приложениями, приборами или услугами, и используется также для журналирования данных и генерации отчетов в целях совместимости с прочими бизнес-данными.

Среди топовых SIEM можно назвать ArcSight, QRadar, Splunk, Qualys и MaxPatrol. Они все платные.

Любители бесплатных решений используют так называеемый ELK stack (Logstash+Elasticsearch+Kibana):

• Logstash - сбор логов
• Elasticsearch - хранение и быстрый поиск по логам
• Kibana - визуализация

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

Как полнять ELK хорошо описано здесь - Введение в ELK: собираем, фильтруем и анализируем большие данные