Введение

Рады снова приветствовать дорогих читателей! Продолжаем рубрику статей "ШХ" в которой мы рассматриваем методы и инструменты OSINT. В этой статье хотим рассмотреть очередной перечень инструментов которые могут значительно упростить жизнь сетевым разведчикам.

Дисклеймер: Все данные, предоставленные статье, взяты из открытых источников, не призывают к действию и являются только лишь для ознакомления, и изучения механизмов используемых технологий.

В текущих реалиях все IT-продукты разрабатываются с использованием какого-либо ПО, способного управлять репозиториями программного кода для Git. В нашем случае, хотелось бы рассказать про один из самых популярных продуктов — Gitlab. «Gitlab — наше всё» должно быть слоганом каждой компании, которая его использует, иначе могут произойти события, которые приведут к печальным последствиям. На Habr можно найти множество различной информации, связанной с кейсами, туториалами или просто интересными историями. Но сколько бы ни было написано, найти место где было бы собрано всё и сразу — не получилось. Придется исправлять. 

Общие сведения о TLS

Wireshark – это широко распространённый инструмент для захвата и анализа сетевого трафика, который активно используется как для образовательных целей, так и для устранения неполадок на компьютере или в сети. Wireshark работает практически со всеми протоколами модели OSI, обладает понятным для обычного пользователя интерфейсом и удобной системой фильтрации данных. Помимо всего этого, программа является кроссплатформенной и поддерживает следующие операционные системы: Windows, Linux, Mac OS X, Solaris, FreeBSD, NetBSD, OpenBSD.

Привет, Хабр! 

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

Не секрет, что разработка даже небольшого проекта тесно связана с инфраструктурой, поскольку любая программа требует наличия определённого окружения. Часто таких окружений требуется несколько — одно под прод, а остальные — под разные нужды, например, тестирование. Иногда эти среды даже могут быть динамическими — когда вместе с новым бранчем создаётся окружение, в котором запускается разрабатываемая версия приложения и всё необходимое для неё, а после того как бранч вливается в main, эта среда и все её данные удаляется. 

И вот как раз о данных (а точнее о базах данных) в таких средах и хотелось бы поговорить. А именно — где и как их взять, как сделать их максимально приближенными к боевым и как защититься от их утечки. Для решения этих задач мы в Nixys используем собственный инструмент — nxs-data-anonymizer. Хотим поделиться им с вами.

В каких юнитах можно померить DDOS атаку? Биты в секунду, запросы, пакеты, время даунтайма, количество машинок в ботнете — все эти ответы верные. Потому что DDoS-атаки бывают разных категорий и для каждой есть свои ключевые метрики. Их рост и является движущей силой для эволюции DDoS атак. Посмотрим, как это происходит.

Поможет нам в этом Георгий Тарасов, владелец продукта Bot Protection в Qrator Labs. Ранее он занимался разработкой, проектным менеджментом и pre-sales. Вместе с ним мы полетим в 1994 год и обратно, в настоящее время. Посмотрим, как развивались распределённые атаки на отказ в обслуживании за эти годы, к чему они пришли сейчас, и на что есть смысл обратить внимание.

Фото ETA+, Unsplash.com

Первые шаги в сторону observability — собираем метрики с Prometheus

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

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

Что такое observability

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

Три кита observability

Observability основана на трех главных компонентах. Это данные телеметрии, которые можно агрегировать и анализировать, чтобы понять состояние системы:

1. Метрики.
2. Трассировки.
3. Логи.

В этой серии статей мы рассмотрим все три компонента с примерами. Начнем с метрик и опенсорс-проекта Prometheus.

Введение

FAQ MITRE ATT&CK оказался крайне нераспространенным документом, при всей его познавательной ценности как в перспективе, так и для текущей деятельности сообщества. Поэтому мы решили его перевести. Результат под катом.

• Простота. Стажёр или студент, приходя к нам, может уже через неделю написать и отправить в продакшен новый микросервис.
• Надёжность. Многие ошибки, в том числе и связанные с многопоточностью, можно поймать на этапе компиляции. Кроме того, фреймворк даёт подсказки по исправлению проблем.
• Полнота. В userver есть всё необходимое для тестирования, работы с разными базами данных, кеширования, логирования, трейсинга, распределённых блокировок, работы с JSON, BSON, YAML, изменения параметров сервиса на лету и так далее.

За 3 дня до нового года появилась задача, передать клиенту наше ПО через менеджера, на флешке. ПО – это микросервисная платформа в несколько десятков docker-образов с множеством настроек и “километровым” helm-чартом. Что мы имели:

• Менеджер в Москве (я не оттуда)
• Windows
• Прямого взаимодействия нет (а если бы и было, то не особо помогло)
• docker-а нет

Пфф, подумал я! Возьму Golang, напишу программку, скомпилирую под Windows.
… и 5 часов спустя осознал поспешность своих выводов. В тот момент в первый раз вспомнился смех Нельсона. ХА-ХА! Который преследовал меня все то время, что я потратил на изучение вопроса.