В 1970-х годах известный программист Эдгар Кодд разработал математически выверенную теорию организации данных в виде таблиц (реляций). С тех пор утекло немало воды — появилось большое количество различных коммерческих и open-source реляционных систем управления базами данных (РСУБД). Скоро стало понятно, что эффективное получение данных из базы — задача далеко не тривиальная. Если говорить прямо, она нелинейная и в общем случае NP-сложная.

Когда SQL-запрос становится немного сложнее: SELECT * FROM table, у нас появляется огромная вариативность его исполнения внутри системы — и не всегда понятно, какой из возможных вариантов эффективнее как по памяти, так и по скорости. Чтобы сократить огромное количество вариантов до приемлемого, обычно используются так называемые эвристики — эмпирические правила, которые придуманы человеком для сокращения пространства поиска на несколько порядков. Понятное дело, эти правила могут отсечь и сам оптимальный план выполнения запроса, но позволяют получить хоть что-то приемлемое за адекватное время.

В последние годы в связи с активным развитием ML начали развиваться и нейронные оптимизаторы запросов —особенность которых в том, что они самостоятельно, без участия человека, находят необходимые закономерности в выполнении сложных планов исходя из обучения на огромном количестве данных. Тенденция началась приблизительно в 2017 году и продолжается до сих пор. Давайте посмотрим, что уже появилось в этой области в хронологическом порядке и какие перспективы нас ждут.

Доброго дня. Это мой первый пост на хабре, поэтому не будьте особо строги к нему.

В мире разработки, системного администрирования и DevOps не смотря на то, что давно существуют и заняли свою нишу инструменты, связанные с централизованным сбором, визуализацией и анализом логов (graylog, ELK/EFK, loki, loggly и другие), всё ещё существует необходимость периодически взять шашку в руки и поработать со старыми/добрыми (а может быть и не очень добрыми) текстовыми логами. За 21 год своей деятельности я успел побыть системным администратором, DevOps инженером, разработчиком, CTO и системным аналитиком, но необходимость периодической работы с логами неизменно присутствовала в том или ином виде всегда. Это может быть разбор вывода нового сервиса или контейнера на машине разработчика, что-то, что ещё не успели завести (или сознательно по каким-либо причинам не завели) на централизованную систему сбора логов или, например, сервис, временно включенный в режиме debug для поиска причин проблемы. Ситуаций бывает много и ситуации бывают разные, а текстовые логи были, есть и ещё долго будут с нами.

Все, кто как-либо связан с DevOps знают про такие утилиты как more, less, tail, head, grep, sed, awk (а кто-то и ещё десяток более специфичных) и при необходимости их используют, но из тех, с кем я общался, никто не подтвердил мне, что знает про lnav. Я и сам не знал и искал нечто подобное более десяти лет. lnav — это не просто швейцарский армейский нож в мире работы с логами, а целый космический корабль, на котором можно улететь в соседнюю галактику. Мой мир разделился на "до" и "после" знакомства с этой утилитой. Там, где раньше требовались часы, а то и десятки часов на анализ логов, теперь хватает считанных минут.

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

В связи с последними событиями вокруг видеохостинга YouTube, ситуация вынуждает искать технические решения для восстановления доступа к сервису. В этой статье я хочу поделиться своим техническим опытом по восстановлению доступа к сервису с помощью дешевого одноплатника Orange Pi Zero2 от компании Xunlong Software.

Disclaimer: практически всё описанное в статье, не является чем-то принципиально новым или инновационным - оно давно известно и придумано, используется в разных странах мира, реализовано в коде и описано в научных и технических публикациях, поэтому никакого ящика Пандоры я не открываю.

Нередко на Хабре в темах, посвященных блокировкам ресурсов встречаются забавные заявления, вида "Я настроил TLS-VPN, теперь будут смотреть что хочу и цензоры мой VPN не заблокируют", "Я использую SSH туннель, значит все ок, не забанят же они SSH целиком", и подобное. Что ж, давайте проанализируем опыт других стран и подумаем, как же оно может быть на самом деле.

Технологии машинного обучения все стремительней входят в нашу жизнь и находят применение в различных сферах деятельности. В медицине развивается диагностика различных заболеваний и методов лечения. В автомобильной промышленности машинное обучение успешно применяется в сервисах для помощи водителю и готовится полноценно забрать управление автомобилем на себя. В финансовой сфере ML используются для прогнозирования рынка и определения рисков. А что происходит в сфере информационной безопасности?

В ИБ технологии машинного обучения успешно применяются в системах защиты информации, таких как IDS/IPS, WAF, Antivirus, Anti-phishing и т.д. Все эти СЗИ обрабатывают огромные объемы данных, и выявление атак сопряжено с большой вариативностью техник злоумышленника. Конечно же сигнатурный анализ не готов уйти в историю и является основой для выявления угроз, но есть ряд существенных ограничений. В основном, правила направлены на выявление известных техник и не всегда способны учесть все возможные вариации, т.е. направлены на выявление ряда частных случаев. Соответственно, выявление неизвестных атак достаточно проблематично.

Модели машинного обучения позволяют решить эти проблемы, так как способны обучаться на больших данных и выявлять аномальные паттерны, которые невозможно учесть при сигнатурном анализе. В современных СЗИ данные технологии применяются совместно и дополняют друг друга.

Аналогичные проблемы существуют и в SOC относительно методик выявления инцидентов ИБ. Основой являются правила корреляции SIEM которые в отдельных кейсах стремятся покрыть выявление всех возможных атак, но не могут этого сделать в виду различных ограничений. В отличие от СЗИ, машинное обучение в инструментах SOC развито достаточно слабо. Мы тестировали ряд систем, таких как Anomaly Detection и UEBA, но широкого применения в SOC они не нашли из-за большого количества ложных срабатываний. Других инструментов направленных на выявление инцидентов ИБ нам, к сожалению, найти не удалось.

Как говорится, хочешь сделать хорошо - сделай сам! Вооружившись этой идеей, мы решили выделить некоторые точечные кейсы, с проблематикой описанной выше, и автоматизировать выявление с применением машинного обучения. В данной статье мы поделимся нашим опытом на примере выявления вредоносного кода PowerShell, соберем нейронную сеть и рассмотрим варианты ее использования совместно с SIEM.

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

Сегодня мы хотели бы поговорить о Lateral Movement - тактике, активно используемой злоумышленниками для продвижения по сети. Часто во время атак или тестирований на проникновение атакующие перемещаются не вверх по привилегиям, а вбок по машинам, "перескакивая" от одной машины к другой. Это нужно для получения информации, находящейся на специфичной машине, а также для расширения доступов и влияния на сетевую инфраструктуру. Такая тактика называется Lateral Movement, что переводится как "Горизонтальное Перемещение". Часто этот термин употребляется в контексте целевых атак, однако перемещаться по сети может и вредоносное ПО.

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

Согласно годовому отчету от коллег из DFIR, одной из наиболее распространенных техник бокового перемещения является техника использования протоколов удаленного подключения RDP и SSH. Но здесь мы не будем углубляться в их исследование, так как при использовании этих протоколов поведение злоумышленника обычно не отличается от легитимной деятельности пользователей. Чего нельзя сказать о случаях использования инструментов, при которых атака будет иметь свои чёткие признаки.

Вредоносное ПО уже долгое время является одной из основных угроз в области информационной безопасности. Подходы к анализу и защите от такого рода атак бывают разные. В общем случае разделяют два подхода: статический и динамический анализ. 

Часто подходы в поведенческом анализе основаны на наборах правил. Экспертный анализ переносится в сигнатуры, на основе которых инструмент детекта вредоносного ПО и файлов делает выводы. Однако в таком случае может возникнуть проблема: могут учитываться лишь те атаки, которые строго соответствуют написанным правилам, а атаки, которые не выполняют эти условия, но все еще являются вредоносными, можно пропустить. Та же проблема возникает в случае изменений одного и того же вредоносного ПО.

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

Как идеально не строй цикл разработки и поиска уязвимостей, все равно будут существовать кейсы, которые приводят к security-инцидентам. Поэтому давайте соединим два ингредиента: control loop (reconciliation loop) и полную декларативную возможность Kubernetes и посмотрим, как автоматизировано реагировать на те или иные угрозы, риски, инциденты, которые происходят в Kubernetes-кластере.

Сразу предостерегаю, что после прочтения не надо бежать и воплощать то, о чем я расскажу. Всё это некоторый high level. У вас должны быть соответствующие выстроенные процессы и уровень информационной безопасности. Без базового контроля и базовых мер реализовывать SOAR очень опасно. Это может только навредить. Поэтому нужно адекватно оценивать уровень зрелости процессов и информационной безопасности в вашей компании.

Меня зовут Дмитрий Евдокимов. Я основатель и технический директор Luntry. Мы делаем security observability решение для Kubernetes и делимся опытом в данной области.

Статьи цикла:

1. Обзор материалов и литературы по NAS. По предложениям пользователей ссылки на материалы будут сведены в отдельную статью.
2. Выбор железа. Описан один из вариантов выбора железа и дан краткий обзор рынка домашних и офисных NAS систем.
3. Установка ОС, на которой будет строиться NAS. В отдельной статье описано дополнение, позволяющее отказаться ото всех файловых систем, кроме ZFS.
4. Проектирование поддерживающей инфраструктуры, которая будет лежать в основе всех сервисов NAS.
5. Реализация поддерживающей инфраструктуры.
6. Механизм аварийной удалённой разблокировки. Требуется для того, чтобы разблокировать систему, не имея к ней физического доступа.
7. Повышение защищённости NAS. Исправление ошибок, допущенных в предыдущих статьях и описание Hardening процесса.
8. Система контроля версий на базе Git. Установка Gitlab в контейнере.
9. Система резервного копирования. От регламента до установки ПО, где в качестве примера используется UrBackup.
10. Персональное облако. Обеспечивает хранение персональных файлов пользователя, обмен файлами между пользователями, а также интеграцию различных сервисов между собой.
11. Сквозная аутентификация контейнеров.
12. Управление файлами.
13. Библиотека.
14. Мультимедийная система 1: музыка.
15. Мультимедийная система 2: медиа сервер.
16. Фронтенд. Интерфейс, позволяющий быстро обращаться к сервисам.
17. Заметки про управление контейнерами.

Привет, Хабр! На проектах по пентестам нам часто удается получить доступ к корпоративному компьютеру «жертвы», а затем и добыть из него плохо защищенные пароли. К чему это приводит, все понимают. А как происходит такая компрометация — сегодня попробуем раскрыть.

Подробности под катом

Начало 2023 года — подходящее время писать на Хабре о том, как важно делать бэкапы. Как оказывается, оно всегда подходящее, потому что большинство не усвоило простые уроки информационной безопасности. На самом деле, эта статья — крик души разработчика корпоративных систем. Можно смело перефразировать слова Салтыкова-Щедрина: «Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: не делают бэкапы». И не только в России — это удивительно упорная, странная проблема международного масштаба, настоящий символ пофигизма, раздолбайства и пренебрежения к труду, прежде всего к собственному. Так почему? Может, так и надо? :-)

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

Казалось бы простая задача - развернуть Kubernetes кластер и в нем запустить централизованный мониторинг TICK стек и логирование ELK стек. Но для меня она осложнилась тем, что с этим технологиями я столкнулся впервые. Чтобы понять, как все работает, хотел пройти простые Quick Start инструкции. К своему удивлению, не нашел детальных актуальных описаний - либо отдельные статьи со своей спецификой, либо многостраничные книги по Kubernetes. Пока собирал пазл из многочисленных материалов, решил написать статью, в которой рассмотреть общую концепцию развертывания TICK и ELK стеков в Kubernetes. 

Для чего, вообще, решать задачу централизованного мониторинга и логирования в Kubernetes? 

Причины и симптоматика синдрома запястного канала

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

Как это часто бывает, по-настоящему понимаешь какую-то тему, только когда начинаешь рассказывать о ней другим («метод Фейнмана»). Несколько друзей, позавидовав моим «успехам», попросили помочь разобраться с английским. Тут и обнаружилось, что хотя я уже успешно использую английский в повседневной работе, обучать ему кого-то ещё — это совершенно отдельный навык.

Первоначальная идея. Сначала разъяснить все английские времена за один присест удавалось, надёргав различных идей из интернета: обрывки чьих-то схем, начинали склеиваться в свою схему и обрастать собственными легендами, а применение времён почти всегда было проще пояснить, используя хрестоматийную «систему английских времен с точки зрения употребления глагола “to vodka”». С каждой новой импровизированной лекцией, схема и нарратив продолжали меняться. «Ученики» попадались с различным базовым уровнем, что позволило понять, откуда нужно начинать плясать, чтобы урок был понятен всем, кто хоть раз слышал что-то про глаголы have и be. Когда счёт обученных уже пошёл на десятки, я решил оформить идею в более стройную лекцию. От первых попыток преподавания английских времён, до этого момента прошло пять лет. За это время было обучено ещё пару сотен человек. Обучено — по приколу. Денег за эти уроки я не брал.

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

Два года я работал в одной конторе на позиции джуна, но роста там особо не было. Надеялся, что скоро закончу магистратуру, и меня повысят до милда. Но этого не произошло. К слову, бакалавриат я закончил в СПбГУТ им. М.А. Бонч-Бруевича, факультет инфокоммуникационных сетей и систем, но знаний, которые можно непосредственно применять в современной продуктовой разработке, к сожалению, не получил. В программировании на Java я самоучка, и технический бэкграунд мне сильно в этом помог. Java изучал на практике, вникая в документацию и смотря ролики на ютубе.

Здравствуйте, товарищи! Прошло чуть больше полугода после выхода предыдущей статьи о Windows 10 Sophia Script — скрипте, который за прошедшие годы стал самым крупным (а их осталось всего два) опенсорс-проектом по персонализации и настройке Windows 10, а также автоматизации рутинных задач. В статье я расскажу, что изменилось с момента релиза версии, описываемой в статье от 29.09.2020, с какими трудностями мы столкнулись, и куда всё движется.