Приглашаем на вебинар, посвященный последним обновлениям IVA MCU — ведущей платформы видеоконференцсвязи на российском рынке*
Вы узнаете, как новая версия помогает повысить безопасность коммуникаций, упростить внедрение и сделать работу сотрудников комфортной и продуктивной. Наши эксперты продемонстрируют интерфейс, расскажут о новых функциях с ИИ, покажут реальные кейсы внедрения и ответят на все ваши вопросы.
Спикеры
Дмитрий Журавлев, директор по продукту IVA MCU
Дмитрий Чугунов, руководитель управления поддержки продаж
Что вас ждет
Обзор ключевых функций новой версии IVA MCU
Экскурс: как мы обеспечиваем безопасность платформы
Несложная задача с CTF-турнира. Будет интересна всем, кто интересуется информационной безопасностью.
Условие Представьте, что вы — дежурный инженер. Вместе с коллегами вы ежедневно фиксируете состояние информационной системы в специальном журнале. Этот документ помогает определять угрозы и вовремя на них реагировать.
Однажды ваши коллеги рассказали, что где-то на странице журнала находится флаг. Но вот где именно — не раскрыли. Попробуйте найти этот флаг без подсказок коллег.
Задача Найдите флаг — строку в формате slcctf{}. Чтобы выполнить задание, перейдите на страницу http://findme.slcctf.fun/.
Делитесь своим решением в комментариях. А правильный ответ можно посмотреть в Академии Selectel.
Утечка системного промпта Claude 3.5 Sonnet: что произошло
TL;DR: прозмоьла утечка системного промпта Claude 3.5 Sonnet.
Недавно в открытом доступе на GitHub появился файл с системным промптом модели Claude 3.5 Sonnet от Anthropic. В этой заметке мы подробно разберём, что именно было обнародовано, как устроен промпт и какие риски несёт его утечка.
Системный промпт — это скрытая инструкция, определяющая поведение и «мозг» LLM-модели, задающая стиль, ограничения, формат вывода и логику внутренних решений. Утечка данной инструкции может помочь лучше понять внутренности и логику работы данной нейросети.
Описания «артефактов» (artifacts) — самостоятельных блоков контента (отчёты, письма, презентации).
Правила запуска «структурированного мышления» в тегах <antthinking>.
Шаблоны и условия фильтрации: когда создавать артефакт и когда отвечать простым текстом.
Ограничения по объёму и форматированию, а также рекомендации по стилю.
Небольшой анализ этой утечки:
Артефакты Системный промпт описывает «артефакты» — XML-подобные блоки (отчёты, письма), которые модель генерирует для структурированного редактирования.
Структурированное мышление Перед формированием сложных ответов включаются теги <antthinking>, задающие пошаговый алгоритм анализа запроса и выбора формата вывода.
Фильтрация и объём Короткие ответы (1–2 предложения) выдаются без артефактов; при этом заданы жёсткие лимиты на размер и глубину артефактов во избежание «раздувания» текста.
Режимы и модерация Включены автоматические режимы генерации (быстрый ответ, развёрнутый отчёт) и встроенные фильтры для блокировки нежелательного контента и внутренней информации.
На всякий случай, файл с GitHub'a залил в облако и Web archive, чтобы точно не потерять :). Хотя сам, честно говоря, до сегодняшнего дня но разу не пользовался данной моделью, теперь есть повод поэкспериментировать.
PS. Это мой первый пост, друзья, так что, если найдёте какие-либо недочёты, пожалуйста, укажите на них!
Утечка системного промпта Claude 3.5 Sonnet: что произошло
TL;DR: произошла утечка системного промпта Claude 3.5 Sonnet.
Недавно в открытом доступе на GitHub появился файл с системным промптом модели Claude 3.5 Sonnet от Anthropic. В этой заметке мы подробно разберём, что именно было обнародовано, как устроен промпт и какие риски несёт его утечка.
Системный промпт — это скрытая инструкция, определяющая поведение и «мозг» LLM-модели, задающая стиль, ограничения, формат вывода и логику внутренних решений. Утечка данной инструкции может помочь лучше понять внутренности и логику работы данной нейросети.
Описания «артефактов» (artifacts) — самостоятельных блоков контента (отчёты, письма, презентации).
Правила запуска «структурированного мышления» в тегах <antthinking>.
Шаблоны и условия фильтрации: когда создавать артефакт и когда отвечать простым текстом.
Ограничения по объёму и форматированию, а также рекомендации по стилю.
Небольшой анализ этой утечки:
Артефакты Системный промпт описывает «артефакты» — XML-подобные блоки (отчёты, письма), которые модель генерирует для структурированного редактирования.
Структурированное мышление Перед формированием сложных ответов включаются теги <antthinking>, задающие пошаговый алгоритм анализа запроса и выбора формата вывода.
Фильтрация и объём Короткие ответы (1–2 предложения) выдаются без артефактов; при этом заданы жёсткие лимиты на размер и глубину артефактов во избежание «раздувания» текста.
Режимы и модерация Включены автоматические режимы генерации (быстрый ответ, развёрнутый отчёт) и встроенные фильтры для блокировки нежелательного контента и внутренней информации.
На всякий случай, файл с GitHub'a залил в облакo [ Upd: администрация Telebox, как выяснилось, имеет доступ ко всем файлам, даже беспарольным архивам, и уже дважды удалила файл] и Web archive [здесь файл жив и здоров], чтобы у каждого была возможность покопаться в недрах этого конфига. Честно говоря, до сегодняшнего дня ни разу не пользовался данной моделью от Anthropic, теперь есть повод поэкспериментировать :).
PS. Это мой первый пост, друзья, так что, если найдёте какие-либо недочёты, пожалуйста, укажите на них!
Продолжая тему взаимодействия с MITRE насчёт CVE. В прошлый раз я обращался к MITRE из-за нежелания вендора Docker создавать CVE. Теперь же я попытался внести уточнение к существующей записи CVE-2018-14847, описание которой не слишком точное:
MikroTik RouterOS through 6.42 allows unauthenticated remote attackers to read arbitrary files and remote authenticated attackers to write arbitrary files due to a directory traversal vulnerability in the WinBox interface.
По такому описанию можно подумать, что уязвимы абсолютно все версии ниже 6.42. На самом деле это не так. Более точное описание есть у вендора MikroTik:
Versions affected:
Affected all bugfix releases from 6.30.1 to 6.40.7, fixed in 6.40.8 on 2018-Apr-23
Affected all current releases from 6.29 to 6.42, fixed in 6.42.1 on 2018-Apr-23
Affected all RC releases from 6.29rc1 to 6.43rc3, fixed in 6.43rc4 on on 2018-Apr-23
Но, и оно не совсем правдивое. Как минимум версия 6.28 уязвима (проверял используя этот эксплоит). Я обратился в MITRE через эту форму (выбрал "Request an update to an existing CVE Entry"), объяснив всё это. В итоге MITRE лишь добавили ссылку на описание уязвимости от вендора (обновление от 28.04.2025). Это в очередной раз подтверждает, что при оценке угроз не стоит полностью полагаться ни на CVE, ни на информацию от вендора. О чём говорю не только я. Был у меня личный опыт, показывающий неточность в описании уязвимых версий со стороны вендора: Cisco UCS Manager. А если пытаться смотреть на CVE, указанные вендором по этой проблеме - так каши в голове становится лишь больше: в CVE речь о версиях bash (а какая версия bash в какой прошивке и оборудовании есть - в CVE не указывается).
ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)
20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.
Несколько информационных моментов.
1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО
Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.
2. Вебинары РБПО-направленности
Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:
Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.
3. Сертификация ФСТЭК
В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?
Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).
PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.
PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):
PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);
PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);
продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.
Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.
Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325 Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325
В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:
Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment.
Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.
Надеюсь, CVE заведут. Мне и моим коллегам по цеху по безопасности гораздо удобнее оценивать безопасность архитектуры, имея единый источник проблем безопасности (база CVE). А не рыскать по всему интернету, пытаясь собрать воедино информацию о проблемах безопасности конктерных продуктов, придумывая какие-то запросы, вовзращающие релевантную информацию. Даже если описание в самом CVE сухое - всегда проще искать подробности по уникальному идентификатору CVE, чем выдумывать разные запросы для каждого конктерного продукта.
К сожалению, нежелание признавать CVE со стороны различных разработчиков случается периодически. В моей практике была ситуация, когда разработчик не просто не хотел заводить CVE, а ещё и желал, чтоб я сам отозвал CVE. После моего отказа пытался CVE оспорить (но, неудачно).
Личный кабинет налогоплательщика, или как потерять доступ, если бы не длинный буфер обмена Windows 11
Обнаружил сценарий, при котором можно потерять доступ к личному кабинету (ЛК) налогоплательщика, если не сохранять в отдельном месте генерируемые пароли.
Входим в ЛК.
Нажимаем "Изменить пароль" в настройках профиля.
Генерируем пароль сторонним сервисом, назовем его "Пароль 1".
Вводим пароль, сохраняем.
Вдруг система говорит, что в пароле нет цифр!..
Хорошо, генерируем новый пароль, с цифрами.
Вводим новый пароль... О-па, а в поле "Старый пароль" уже неверный пароль.
Нервно ищем Пароль 1. Оказывается, что он применился, несмотря на ругань системы. Если не нашли, то всё... Мне помог длинный буфер обмена Windows 11.
Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢
Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу.
Ты можешь выбрать направления:
Продуктовая разработка: DevOps или Golang.
Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.
А у лучших стажеров будет возможность попасть в штат Cloud․ru.
Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.
Используйте шанс погрузиться в реальные проекты, обучиться актуальным технологиям и продолжить работу в крутой компании. А о результатах и впечатлениях участников предыдущих стажировок можно почитать в статье.
У пенсионера из США c помощью социальной инженерии украли 3520 биткойнов на $330 миллионов. Мошенники потом кучу раз дробили сумму и отмыли её через 300 кошельков и 20 бирж. Большую часть денег вообще перевели в XMR — монету, которую трудно отследить. Эксперты говорят, что вернуть эти криптоактивы пострадавшему невозможно.
Утечка данных оператора связи Телекоммуникационная компания MTN Group сообщила об утечке ПДн абонентов, подчеркнув, что это не повлияло на работу ее сети.
Кибератака на телеком-оператора Корейский оператор SK Telecom расследует хакерский взлом — злоумышленники использовали вредоносное ПО и завладели ПДн клиентов.
NGFW: останется только один Поделились, каким требованиям должны соответствовать полноценные NGFW: в том числе требуются высокая отказоустойчивость, регулярное обновление ПО и стабильная производительность, соответствующая сетевой инфраструктуре бизнес-заказчика.
Форум безопасного Интернета На «XIV Форуме безопасного Интернета» рассказали про архитектуру мошенничества и противодействие подобным манипуляциям в докладе «Как активировать психологическую защиту пользователей».
Как вам такой сценарий. Некоторая группа специалистов по информационной безопасности (в плохом смысле) создаёт публичный сайт-прокси который рекламируется как бесплатное решение всех проблем программиста.
Когда программист делает запрос на генерацию кода скажем бекенда для веб сервера его запрос проксируется в ChatGPT, а потом модифицируется скриптом, который добавляет небезопасный код.
Попутно сайт собирает информацию о самом программисте, например, IP адрес, а в случае регистрации - email работодателя.
Информация сохраняется для разработки, через полгода-год когда код гарантировано попадает на прод происходит кибератака.
Телеграм, дай возможность отозвать заявки в группы! Это же базовый функционал!
Знаете, что меня недавно выбесило в любимом мессенджере? Отсутствие элементарной, казалось бы, функции: списка поданных заявок в группы и каналы.
История банальна до смешного. Вечер, пишет какой-то аккаунт, кидает ссылку на группу "взаимной подписки". Мозг отключен, палец машинально жмет "Подать заявку". Через час доходит – зачем мне это? Лезу в диалог, а приглашение уже удалено. Название группы? Не помню. Ссылка? Потеряна.
И тут начинается паранойя. А что, если это была какая-то мутная группа? Что, если ее завтра переименуют во что-то совершенно неприемлемое? А я там буду висеть в "кандидатах на вступление", и отозвать заявку НЕ МОГУ, потому что я ее тупо не вижу!
Я перерыл все настройки – бесполезно. Telegram не показывает список твоих активных, еще не одобренных заявок. Ты просто сидишь и надеешься, что пронесет, или что админ той самой группы (которую ты даже не помнишь) отклонит твой запрос.
В моем случае все разрешилось относительно мирно. Через пару дней меня приняли в очередной канал про "успешный успех". Фух, пронесло.
Но сама ситуация – дичь! Почему я не могу контролировать, куда я "постучался"? Почему нельзя посмотреть список своих ожидающих заявок и отменить ненужные? Это же базовая гигиена цифровой безопасности и просто здравый смысл!
Как-то неловко случайно "подписаться" на неизвестно что без права на отмену.
Как автоматизировать распознавание текста с изображений?
В открытых источниках часто встречаются изображения с ценным текстом — скриншоты рабочих столов и приложений, фотографии таблиц, чеков, рукописных заметок и т.д. Сбор обычного текста автоматизировать легко, но с текстом на картинках начинаются сложности.
Раньше в моём арсенале был только pytesseract (Python-библиотека для распознавания текста). Она работала, но с серьёзными ограничениями: ➖Плохо справлялась с разными шрифтами ➖Теряла точность на низкокачественных изображениях ➖Путала языки, если текст был мультиязычным
Сейчас появились LLM-модели, которые справляются с этой задачей гораздо лучше, но если у вас нет мощного железа, запустить их локально не получится.
В профильных каналах регулярно пишут: «Вышла модель Х, которая показывает отличные результаты. OSINT-еры больше не нужны!», но никто не дает гайдов, как с этими моделями работать. Сегодня я это исправлю.
Обзор моделей для OCR Прошерстив не один десяток источников, я выделил две наиболее популярные на текущий момент модели: 1️⃣ GPT-4 mini — высокая точность, но платная. 2️⃣ Google Gemini 2.0 Flash — высокая точность + бесплатный лимит.
Выбор без раздумий пал на Gemini. На момент публикации бесплатные лимиты от Google следующие: ✔️ 15 запросов в минуту ✔️ 1 млн токенов в минуту (ввод + вывод) ✔️ 1 500 запросов в сутки
Как взаимодействовать с Gemini? 1️⃣ Получаем API-ключ в Google AI Studio 2️⃣ Через API отправляем изображение в base64 + промпт 3️⃣ Получаем распознанный текст в ответе
Но есть важный нюанс: сервис не работает с российскими IP
Что делать, если Gemini недоступна? Если у вас по какой-то причине нет возможности получить доступ к серверам Google AI Studio, то можно воспользоваться сервисами, которые предоставляют доступ к различным open-source моделям. Например, DeepInfra. Плюсы: ✔️ Нет блокировок по геолокации ✔️ Гибкая тарификация Минусы: ✖️ Нет бесплатного тарифа
Подписывать контейнеры с помощью GPG важно, потому что это гарантирует, что образ действительно создан вами или вашей командой и не был изменён после сборки. GPG — это проверенный инструмент, который уже давно используется для шифрования и подписи данных. Он не зависит от сторонних решений и является частью свободного ПО, поэтому ему можно доверять.
Когда вы подписываете контейнер, вы подтверждаете его целостность. Если кто-то заменит образ на поддельный с вредоносным кодом, подпись позволит это обнаружить. Без подписи вы рискуете запустить что-то небезопасное, даже не зная об этом.
Конечно, есть и другие инструменты, например cosign, которые тоже полезны, особенно в облачных средах. Но GPG остаётся надёжным базовым решением, которое работает везде и не требует дополнительной настройки. Проще говоря, это как печать на документе: если её нет, вы не можете быть уверены, что всё чисто.
container-tools % make
Usage: make <target>
help - Display this help message
all - Build all Debian images
check-dependencies - Verify required tools are installed
clean - Remove all build artifacts and downloads
list-vars - List all Makefile variables and their origins
shellcheck - Validate all bash scripts
package - Create tar.gz archive of the directory
release - Create Git tag and GitHub release
archive - Create git archive of HEAD
bundle - Create git bundle of repository
============================
** Debian Linux targets **
============================
|all|
|debian11|
|debian11-java|
|debian11-java-slim|
|debian11-corretto|
|debian11-graal|
|debian11-graal-slim|
|debian11-java-slim-maven|
|debian11-java-slim-gradle|
|debian11-graal-slim-maven|
|debian11-graal-slim-gradle|
|debian11-java-kafka|
|debian11-java-slim-kafka|
|debian11-nodejs-23.11.0|
|debian11-python-3.9.18|
Собираем базовый образ для NodeJS
make debian11-nodejs-23.11.0
После завершения сборки:
[Image was built successfully]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Artifact location: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
Artifact size: 93M
Для подписи используем gpg.py в составе container-tools:
./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB
2025-04-25 13:39:41,269 [INFO] Signing tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar -> Signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] Successfully signed tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:39:41,752 [INFO] Signature saved to: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] All tarballs have been processed successfully.
Подтверждаем:
./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB --verify
2025-04-25 13:40:19,734 [INFO] Verifying tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar against signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:40:20,192 [INFO] Verification successful: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:40:20,193 [INFO] All tarballs have bee
Время уходит — компаниям до 30 мая следует сообщить в РКН об утечках данных
Скоро в России вступят в силу новые законодательные требования по обороту ПДн. Вчера в ТАСС состоялась посвященная этой теме пресс-конференция. Модератором и участником стала Наталья Касперская, президент ГК InfoWatch.
Главные тезисы:
Наталья Касперская: утечки ПДн затрагивают не только бизнес, но и всех граждан. Они — причина успеха кибермошенников, которые используют достоверную информацию о людях для обмана.
Михаил Смирнов (эксперт и главный редактор BISA): масштабы проблемы утечек данных не осознаны и недооценены. Объем скомпрометированных ПДн растет — в 2024 году из российских компаний утекло 1,5 млрд записей ПДн.
Милош Вагнер (замруководител РКН): у компаний до 30 мая есть время, чтобы проинформировать уполномоченные органы о произошедших ранее инцидентах. И тогда к ним будут применяться текущие меры ответственности, а не более строгие.
Как устроен ваш цикл разработки приложений? Проверяются ли API на наличие уязвимостей до их публикации? И есть ли вообще для этого процесса какая-то методология?
Вместе с экспертом команды Вебмониторэкс, участвующим в совместной работе с ИСП РАН, подробно разберём, как выстроить эффективный процесс тестирования API, и чем отличаются различные его виды.
Когда? 23 апреля в 14:00
Спикер: Динко Димитров, руководитель продуктового направления, Вебмониторэкс
К чему это я все? DevOps инструментарий – это полный шлак. На попытку заставить на бэке работать эту чудо-поделку под названием GitLeaks, ушло больше времени чем на то, чтобы переписать ее с нуля, добавив еще и возможность кастомизировать паттерны для проверки.
Большинство инструментов для поиска секретов в Git-репозиториях страдают от одной серьёзной проблемы: их JSON-вывод часто кривой или трудночитаемый, что усложняет автоматизацию. Они неплохо находят утечки, но попытка использовать их вывод в CI-пайплайне или бэкенд-сервисе обычно превращается в борьбу с битыми данными или написание кастомных парсеров.
Поэтому я написал лёгкий инструмент на Julia, который делает две вещи правильно: выдаёт чистый, валидный JSON и позволяет задавать собственные правила поиска через YAML-конфиг. Никакой возни с кривым выводом или жёстко зашитыми правилами — только структурированные результаты, которые действительно работают в автоматизированных процессах.
Коллеги, если вы знаете, что такое TAP и SPAN, вам не безразличны вопросы зеркалирования и оптимизации сетевого трафика, а ещё хочется узнать, как в этом помогают брокеры сетевых пакетов, то 23 апреля мы ждем вас на техническом вебинаре, где мы подробно обсудим эти темы. А ещё помимо слайдов с картинками будет живая демонстрация работы ответвителей трафика DS TAP и пакетных брокеров DS Integrity в связке c системой анализа сетевого трафика PT NAD.
Когда тема ИБ вышла за пределы профессиональной аудитории и попала в федеральные СМИ, мы не можем пройти мимо. А когда речь идёт ещё и об одной из самых удобных баз уязвимостей, мы просто обязаны вставить свои 5 копеек.
Итак, представим, что с финансированием CVE всё будет плохо и российские пользователи перестанут получать информацию об актуальных уязвимостях. Руководитель технического центра «АйТи Бастион» Владимир Алтухов видит в этом ещё один шаг в направлении антиглобализации мира ИБ. Универсальный для всех специалистов на планете инструмент исчезает, поэтому возникает необходимость пользоваться чем-то своим.
Не стоит радоваться тому, что не надо будет закрывать какую-то Цэ-Вэ-Ешку – обязательно придётся закрыть очередную БДУшку!
Перед лицом глобальной проблемы у России есть пусть небольшое, но преимущество. В нашей стране уже существует отечественный Банк данных угроз информационной безопасности, он нужен и востребован, хоть пока и ограничен по географическому признаку. Гипотетическая ситуация прекращения поддержки базы CVE станет очередным вынужденным шагом к самостоятельному развитию и более скрупулёзному подходу к управлению безопасностью.
Да, с учётом геополитической нестабильности, исключать внезапное отключение от всего привычного нельзя. Поэтому в очередной раз настоятельно рекомендуем быть готовыми заранее к любому развитию событий. Базовый набор «подушки безопасности от неизвестных уязвимостей» прост:
✅ Минимизировать привилегии при доступе к целевым ресурсам. Лучше всего сделать это с помощью PAM-системы, выполнение основных функций которой укладывается в большинство векторов атак, построенных на превышении привилегий.
✅ Соблюдать принцип Zero Trust.
✅ Отдавать предпочтение зрелым продуктам ИБ с подтверждённым уровнем доверия и на сертифицированных ОС.
Как известно, основной глобальный инструмент для просмотра логов Certificate Transparency (CT-логов) через веб-интерфейс - это crt.sh. Однако сертификаты российских УЦ в глобальные логи пока не попадают (перечень принимаемых сертификатов и пресертификатов в CT-логе всегда ограничен некоторым набором корневых ключей). Для российских УЦ запущены российские CT-логи. Для просмотра российских CT-логов тоже есть сервисы с веб-интерфейсом:
ct.tlscc.ru - это выделенный экземпляр crt.sh, поддерживаемый ТЦИ и настроенный на российские логи; веб-сайт использует TLS-сертификат, выпущенный от корня ТЦИ, так что если корня в браузере нет, то будет выдаваться предупреждение; (пример запроса);
precert.ru - отдельный и весьма удобный сервис, имеющий целый ряд преимуществ: например, здесь другой интерфейс для поиска записей, подробная статистика по логам и УЦ; (пример запроса).
Сейчас в российские CT-логи добавляются сведения о сертификатах, выпускаемых НУЦ (все логи) и ТЦИ (логи "Яндекса" и VK). Основной объём логов составляют пресертификаты, которые добавляют сами УЦ, в процессе выпуска сертификата. Пресертификат отличается от сертификата наличием специального расширения (CT Poison), отсутствием SCT-меток и значением подписи. Обратите внимание, что сертификаты добавить в CT-лог может каждый. Например, можно добавить сертификат, найденный на каком-то веб-узле в Сети (если, конечно, сертификат выпущен подходящим УЦ). Но для добавления придётся уже воспользоваться HTTP-интерфейсом соответствующего лога напрямую, подготовив и отправив POST-запрос.
Зачем просматривать CT-логи? Во-первых, наличие сторон, изучающих записи в CT-логах, это основной декларируемый смысл Certificate Transparency. Во-вторых, просмотр логов позволяет пронаблюдать, что и для чего выпускается, и даже минимально контролировать выпуск сертификатов для тех доменов, которые вы администрируете; Certificate Transparency не гарантирует, что сведения о выпущенном сертификате будут в CT-логе, но такие сведения могут там быть, а сам по себе сертификат, благодаря наличию цифровой подписи, это какой-никакой, но документ, подтверждающий хотя бы свой собственный выпуск. В-третьих, в логах можно найти что-то неожиданное - для этого внимание нужно обращать на таймстемпы, на формат (пре)сертификатов, на состояние конкретных лог-сервисов.
Как я едва не стал жертвой мошенников с помощью Zoom-схемы
Хочу поделиться историей, которая произошла буквально час назад — всё выглядело настолько реалистично, что я по-настоящему поверил, что это обычное собеседование. Но в итоге это оказался тонко продуманный скам, и я чудом не попался.
Всё началось с приглашения на интервью
Мне написал человек в Telegram под ником @AlexImmerman. Он представился сотрудником компании xLabs, объяснил, что им нужен человек с моими навыками, и пригласил на Zoom-интервью. Меня немного смутило, почему он пишет через Telegram, а не через LinkedIn, но он удачно соврал, что меня ему порекомендовали ребята из одного криптопроекта, с которым я недавно работал — и я успокоился.
Мы даже несколько раз переносили встречу — это добавляло реалистичности. Он вёл себя профессионально, попросил ссылку на мой профиль в LinkedIn и актуальное резюме.
Всё выглядело привычно и по делу. И вот сегодня наконец состоялось интервью.
Оно длилось около 20 минут. Это была довольно приятная беседа: он расспрашивал про мой опыт, карьеру, интересы, вёл себя дружелюбно, даже похвалил мой английский :) В общем, всё шло классно — никакого давления, всё казалось очень естественным.
Он заранее предупредил, что интервью будет состоять из двух этапов. После первой части он объяснил, что в соответствии с внутренней политикой компании они используют платформу willo.video, где я якобы должен пройти пару бизнес-сценариев, ответить на вопросы и заполнить анкету. Всё звучало логично — это ведь реальный сервис для видеособеседований.
Но тут он добавил:
“Чтобы тебе было проще, просто расшарь экран — я покажу тебе, куда нажимать и как всё быстро пройти.”
В этот момент у меня внутри сработал звоночек. Я вспомнил, что недавно читал про мошенничество через Zoom, и говорю: “Извини, но я бы не хотел делиться экраном — слышал, что бывают скам-сценарии через Zoom, и хотел бы сначала убедиться, что всё безопасно.”
Он ответил, что понимает мои опасения, добавил, что “сам в крипте уже 10 лет”, и похвалил мою бдительность. Затем предложил перенести вторую часть на завтра и использовать другой сервис — например, Google Meet.
Я согласился, но добавил, что мне ничего не нужно показывать — я и сам спокойно разберусь с любым сервисом. Попросил просто прислать инструкцию и ссылку.
Мы согласовали время и он тут же отключился... А спустя несколько минут я заметил, что вся переписка в Telegram была удалена. Даже жалобу не успел отправить. Вот так вот.
Что это было
Это был очень хорошо продуманный скам. И он бы сработал, если бы буквально вчера я не прочитал, что мошенники могут получить удалённый доступ через Zoom. Никаких “переведите деньги” или “установите программу” — всё выглядело на 100% натурально.
Что бы он сделал, если бы я расшарил экран — я, к счастью, так и не узнал. Но подозреваю, что мог попросить установить какое-нибудь “удобное приложение” или, пока я отойду“за каким-нибудь документом”, сам бы успел что-то скачать. Вариантов масса.
Выводы
Будьте осторожны! Не бойтесь быть подозрительным, задавать вопросы, просить подтверждение личности — например, через LinkedIn или корпоративный сайт. А ещё лучше — проходите онлайн-интервью на отдельном устройстве, где нет кошельков, логинов и приватной информации.
Я чудом не попался. И теперь хочу предупредить других — делитесь этой историей, если вы работаете в крипте, Web3, фрилансите или просто ищете работу. Думаю эта история будет полезна не только криптанам.
Пусть об этих схемах знают как можно больше людей. Берегите себя. И будьте бдительны.
В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки - шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS - есть готовое решение.
Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз - для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.
Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.
Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify - TLS-сессия браузером установлена не будет.
Это, если что, была минутка технологического юмора. Но вот то, что развитие инфраструктуры TLS-сертификатов в вебе движется в сторону тикетов доступа (или, скорее, квитанций) - отрицать всё сложнее.
Сайт — это не просто витрина вашего бизнеса, а главный канал коммуникации с клиентами и источник прибыли. Но чем успешнее становится проект, тем чаще он попадает в поле зрения злоумышленников.
В честь запуска новой услуги мы дарим 200 бесплатных защит! Просто активируйте промокод PQANTIDDOS при подключении и получите защиту бесплатно!
Команда PQ.Hosting всегда остаётся на страже безопасности ваших проектов и делает всё возможное, чтобы это было не дополнительной опцией, а базовым стандартом. В связи с этим мы запустили новую услугу «Защита сайта», чтобы ваши онлайн-проекты были под надёжной защитой от DDoS-атак на уровне L7!
Что такое DDoS-атака?
Это массированная попытка перегрузить сайт, обрушив на него поток запросов, которые сервер не в состоянии обработать. Главная задача — сделать его недоступным, а значит сократить вашу прибыль и сделать всё, чтобы вы потеряли клиентов и даже репутацию.
Как работает защита и что в себя включает?
— Автоматический выпуск Let’s Encrypt сертификата и редирект всех запросов на HTTPS
— Чёрный/Белый список: если IP в списке, запрос блокируется, а IP, которым доверяете, проходят мимо фильтров.
— Распознавание ботов. Система отличает реальных пользователей от автоматических скриптов.
— Запросы оцениваются на наличие признаков атаки. Подозрительные попадают на проверку: JS-челлендж, CAPTCHA и т.д
С новым сервисом от PQ.Hosting такие сценарии — в прошлом. Интеллектуальные фильтры распознают и блокируют вредоносный трафик, пропуская только легитимные запросы. Всё это работает круглосуточно, автоматически и без вмешательства с вашей стороны.
Добавили сервис управления приватными сетями в облаке Рег.ру
К облачной платформе Рег.ру подключили новую функциональность работы с приватными сетями. Обновленный сервис поможет с высокоскоростной защищенной сетевой связностью между виртуальными машинами в облаке. Пользователи смогут изолировать важные элементы инфраструктуры от внешнего доступа, что сведет к минимуму риск взломов и кибератак.
Решение будет полезно, прежде всего, тем, кто работает с чувствительными данными, когда необходимо обеспечить стабильную и безопасную работу распределенных систем, приложений или сервисов.
Передача данных в приватных сетях осуществляется по высокоскоростным оптическим каналам доступа. По умолчанию для пользователей доступна скорость до 1Гбит/с, ограничение внешнего канала до 350 Мбит/с.
Сквозные сценарии и новый портрет клиента: ключевые ИТ-тренды глазами техподдержки
Одна из заметных тенденций 2024 года — продолжение активной миграции отечественных компаний на российское ПО. Переход закономерно приводит к росту сложности ИТ-инфраструктуры и, как следствие, повышенным требованиям к стабильности системы. В этих условиях роль технической поддержки выходит на первый план. Задача техподдержки — не просто решать возникающие проблемы, но и обеспечивать бесперебойную работу и помогать пользователям адаптироваться к новым для них продуктам.
Ниже — несколько ключевых инсайтов, которые отражают реальные изменения в поведении бизнеса, от руководителя дирекции технологических сервисов МойОфис Василия Уварова. А полную версию можно прочесть в свежей колонке Василия для TAdviser по этой ссылке.
Технологическое развитие важнее функционального
Все больше клиентов, особенно те, кто использует серверные продукты, обращают внимание не только на функциональное развитие решений, когда увеличивается количество фичей и новых «кнопочек», но и на технологическое — то есть на стабильность, надежность и безопасность работы ПО. Для них важна высокая скорость работы, устойчивость системы к сбоям, возможность обработки больших объемов данных, защита от потенциальных угроз, а также быстрое копирование и восстановление после инцидентов. Поэтому в текущем году приоритетными направлениями разработки стали повышение производительности и обеспечение отказоустойчивости наших решений. Так, благодаря оптимизации кода и архитектуры мы ускорили работу в веб-редакторах в разных сценариях от 2 до 10 раз. Например, открытие табличного документа выполняется в 4 раза быстрее, а скорость форматирования текста и изменения размера столбца увеличилась в 6 раз.
В свою очередь, для крупных заказчиков важно, чтобы продукт был защищен не только от сбоев и падений, но и от утечек данных. Для этого мы интегрируем наши решения с DLP-системами и другими средствами защиты информации.
Поддержка комплексных инфраструктурных сценариев
Сегодня, когда многие организации вынуждены одновременно использовать отечественные и зарубежные ИТ-решения, особенно остро встает вопрос поддержки комплексных инфраструктурных сценариев. Речь идет не просто об интеграции разрозненных систем, а о создании слаженного механизма, где решения разных производителей эффективно взаимодействуют друг с другом. Это требует глубокой проработки сквозных сценариев использования, охватывающих все уровни инфраструктуры — от горизонтальных связей между различными сервисами до вертикальной интеграции с прикладным уровнем. Особенно это актуально для организаций, которые исторически использовали такие прикладные решения, как Oracle и SAP, и сейчас находятся в процессе длительной и сложной миграции на отечественные аналоги.
Проактивная техническая поддержка, включающая мониторинг инфраструктуры и консалтинг по ее оптимизации, становится критически важной для обеспечения бесперебойной работы и плавного перехода на новые решения.
Продолжение колонки о смене портрета пользователя и запросах бизнеса читайте здесь.
Пишут, что CA/B-форум согласовал дальнейшее сокращение интервала валидности TLS-сертификатов: теперь планируют к 2029 году уменьшить этот интервал до 47 дней. Ожидаемо. Я бы предположил, что ещё короче сделают (да и, фактически, раньше; например, Let's Encrypt уже готовит шестидневные сертификаты).
Тенденция коснётся и сертификатов, выпускаемых "собственными УЦ": если браузер принципиально не верит сертификатам только на основании длительности их интервала валидности, то не играет роли, был ли добавлен корневой ключ УЦ вручную или приехал в составе дистрибутива. (Технически, да, урезать действие ограничения для "домашних" сертификатов можно, но вряд ли имеет смысл на это рассчитывать.) Кроме того, строго автоматический выпуск сертификатов - требует наличия подходящего API на стороне УЦ, тоже немаловажный технологический фактор.
Интересно, что TLS-сертификаты становятся больше похожи на квитанции доступа. Что-то вроде тикетов в каком-нибудь глобальном Kerberos, только повёрнуто в сторону к клиенту, который с браузером. При этом всякий веб-узел должен постоянно и автоматически отмечаться на центральном сервисе, получая новую квитанцию, которая разрешает браузерам доступ. Ну или квитанцию сервис не выдаёт, тогда доступ к веб-узлу для браузеров отключается автоматом. Да, нужно будет ещё в браузерах отключить возможность "отменить предупреждения безопасности" простым способом, но это уже детали.
В отчете The State of Human Risk 2025 (SOHR 2025) компании Mimecast говорится, что человеческий фактор превосходит технологические пробелы в качестве самой большой ИБ-проблемы для организаций по всему миру. Отчет подготовлен на основе интервью с 1100 лицами, принимающими решения в области ИТ-безопасности и развития ИТ.
Фактически, наряду с инсайдерскими угрозами и неправомерным использованием учетных данных, человеческие ошибки являются причиной большинства ИБ-инцидентов.
Около 95% всех утечек данных вызваны человеческим фактором, говорится в отчете SOHR 2025. Решение проблемы требует специального подхода к выявлению, оценке и снижению этих рисков.
Согласно результатам исследования InfoWatch, среди главных причин утечек информации из российских организаций 42% опрошенных выделили неумышленные действия сотрудников — тот же человеческий фактор.
В исследовании Voice of the CISO компании Proofpoint сказано, что 3/4 руководителей ИБ-служб считают человеческие ошибки основным риском ИБ.
Сегодня расскажу про "хитрушку" VK, которую активно обсуждали около 10 лет назад. Со временем о ней стали забывать, хотя она до сих пор не потеряла актуальности.
К сути Уже много лет во «ВКонтакте» существует встроенный инструмент для поиска файлов, доступный каждому пользователю. Поиск по документам может открыть доступ к уникальным данным, которые не найти в обычных поисковиках.
Как это работает? 1️⃣ Переходим в раздел «Файлы» → vk.com/docs 2️⃣ Вводим запрос (например, «ответы на ЕГЭ 2025», «внутренние инструкции», «отчет 2024») 3️⃣ PROFIT!
Из личного опыта: В студенчестве с помощью этого метода я находил ответы на экзамены, которые загружал кто-то из предшествующих потоков.
Где пригодится? Поиск учебных материалов, анализ цифрового следа, журналистские расследования, … — возможности огромны!
Если вам понравился пост и вы хотите узнавать больше о подобных инструментах, то можете подписаться на мой авторский Telegram-канал!
Утечка персональных данных из шпионского приложения
Журналистам стало известно, что случилась утечка данных шпионского приложения SpyX. Скомпрометированы данные около 2 млн пользователей и подписчиков двух аналогичных по функционалу приложений — Msafely и SpyPhone.
Эта вредоносная программа для слежки относится к условному классу «сталкерского ПО», которое позволяет следить за своей парой. Иногда SpyX используется как средство родительского контроля.
На Android-устройства инсталлируется в обход официального магазина приложений Google Play. Для этого необходимо иметь физический доступ к устройству объекта бытового шпионажа и знание пароля для входа в настройки.
На устройства Apple ПО ставится через подключение резервной копии устройства в облачном хранилище. Сталкерское ПО может постоянно обращаться к резервной копии напрямую с серверов Apple.
Деталей инцидента немного. Утечка произошла еще в июне 2024 г., но ранее о ней нигде не сообщали, и нет признаков того, что операторы приложения SpyX когда-либо уведомляли о нарушении пользователей или тех, на кого было направлено шпионское ПО.
Против компании подан иск после масштабной утечки данных
Против австралийской финкомпании FIIG Securities подан судебный иск от Австралийской комиссии по ценным бумагам и инвестициям (ASIC). Регулятор инициировал разбирательство после киберинцидента с раскрытием конфиденциальная информация 18 тыс. клиентов FIIG.
В иске сказано, что FIIG Securities обладала неадекватно-слабой ИБ-защитой, нарушая свои обязательства как лицензиата австралийских финансовых сервисов (AFS). В результате хакер проник в ИТ-инфраструктуру FIIG и оставался незамеченным около трех недель, с 19 мая по 8 июня 2023 г. Он скачал около 385 ГБ данных, которые впоследствии были опубликованы в дарквебе. Имена, адреса, даты рождения, водительские права, паспорта, банковские реквизиты и пр.
Согласно иску, FIIG не обеспечивала следующих мер кибербезопасности в разное время: надлежащая настройка и мониторинг межсетевых экранов для защиты от кибератак; последовательное и своевременное обновление и исправление ПО и ОС; не проводила обучение по кибербезопасности.
По данным ASIC, компания даже не подозревала о взломе.
Куда утекают ваши данные? | Новые технологии мошенников | Биометрия и борьба с дипфейками
Ваши персональные данные уже утекли в сеть — но возможно, не всё так страшно. Только как понять, когда ситуация из рядовой становится критической? И что в целом полезно знать о клиентских данных в 2025 году?
Разбирались вместе с Никитой Назаровым, CTO компании HFLabs, который 12 лет работает с данными клиентов по всей России. Обсудили, как методы социальной инженерии помогают мошенникам, меры государства по защите наших данных и способы обеспечить себе приватность в цифровую эпоху.
Также в выпуске:
Ваши персональные данные утекли в сеть: чем это грозит и что предпринять?
Биометрия — реальная мера защиты или проклятие?
Как компании на самом деле работают с клиентскими базами
Обезличивание данных — способ бороться с утечками
Посмотреть новый выпуск Sravni Tech Podcast можно здесь:
Исследователи кибербезопасности из CloudSEK заявили, что компания Oracle стала жертвой взлома и утечки данных. Они зафиксировали инцидент ИБ после того, как неизвестный злоумышленник опубликовал в дарквебе объявление о продаже 6 млн записей, похищенных из Oracle Cloud. Это подразделение Oracle, которое занимается облачными вычислениями и предоставляет сервисы хранения данных в облачных средах. Инцидент мог затронуть около 140 тыс. клиентов.
Представители Oracle опровергли сообщение о взломе, но CloudSEC представила отчет с неопровержимыми доказательствами инцидента. Инцидент связан с эксплуатацией уязвимости в программном продукте Oracle Access Manager, обеспечивающем аутентификацию в различных Web-приложениях. Эта уязвимость с критическим уровнем опасности.
Хакер предлагал всем желающим помочь ему за вознаграждение расшифровать пароли к системе единого вход (SSO), чтобы оказать давление на компании с целью получения от них выкупа за удаление данных.
Задача о поиске чувствительных данных в дампе трафика
Условие Представьте, что кто-то получил нелегитимный доступ к серверу по API. Вы провели внутреннее расследование и — о ужас! — нашли опубликованный в интернете файловый сервер. Его серый адрес — 192.168.1.47. Известно, что сервер использовался как файлообменник для IT-специалистов. Возможно, что-то ценное утекло именно оттуда.
Задача Скачайте дамп трафика по ссылке dump.pcap и проанализируйте его. Найдите, в каком файле находились чувствительные данные, используемые для доступа к серверу по API.
Делитесь своим ответом в комментариях. А посмотреть полное решение можно в Академии Selectel.
В марте хакеры устроили кибератаку на турецкого провайдера TürkNet. Украдены данные 1,5 млн пользователей.
TürkNet признал факт взлома, рассказав, что утекшие данные включают в себя полные имена, национальные ID, номера телефонов, адреса, данные о подписке и статические IP-адреса.
По данным СМИ, злоумышленники потребовали от TürkNet выкуп в 3 биткойна — около $250 тыс. — в обмен на возврат украденной информации.
Эта кибератака вызвала обеспокоенность официальных лиц Турции по поводу кибербезопасности в стране. Недавно министр транспорта и инфраструктуры Турции Абдулкадир Уралоглу (Abdulkadir Uraloğlu) заявил, что только в течение января 2025 года официальные органы кибербезопасности заблокировали более миллиарда попыток несанкционированного доступа к 1,5 млн IP-адресов в стране.
В середине марта парламент Турции ратифицировал закон о кибербезопасности, который вводит тюремное заключение сроком до 12 лет для организаторов кибератак на инфраструктуру государственных учреждений.
Привет, Хабр! Ровно через 10 минут, в 16:00 мск, проведем вебинар для тех, кто взаимодействует с персональными данными. Поговорим про законодательство, которое регулирует эту работу, и расскажем, как определить свой уровень защищенности. Присоединяйтесь!
РТУ МИРЭА совместно с АО НИЦ и Ассоциацией РУСИБ приглашает всех, интересующихся Инфобезом, с 7 апреля по 31 мая принять участие в гибридном хакатоне NeedForFWSpeed на самое быстрое ПО межсетевого экрана и побороться за призовой фонд 0,6 млн рублей.
Все конкурсанты будут использовать одинаковые аппаратные платформы и одинаковые датасеты. Так что старт у всех будет с одной линии.
В качестве аппаратной платформы всем предлагается RPi CM4 MilkV с процессором архитектуры RISC V – мы стойкие сторонники OpenSource.
Зато нет никаких ограничений на ПО. Можно взять абсолютно стандартную сборку *nix и пойти с ней. Можно хорошенько пооптимизировать iptables/nftables, сетевые драйверы и настройки IP-стека и получить прирост производительности. В придачу можно поотключать в ОС и всё лишнее, можно собрать свою кастомную сборку и много чего ещё.
Можно взять и операционку полегче, ОС РВ или Нейтрино, и попытаться получить выигрыш за их счёт. Можно вообще написать свой код, взяв за основу исходники IP-стека, так сказать, BareMetal в чистом виде.
По условиям соревнований не важно, сколько человек в команде, один или пять, какой у Вас возраст и образование, какой опыт работы и какой стек технологий – значение имеет только СКОРОСТЬ РАБОТЫ МЕЖСЕТЕВОГО ЭКРАНА. Никаких взвешенных коэффициентов, призов зрительских симпатий и симпатий жюри. От жюри нужно будет одно – подписать итоговый протокол.
Вся интрига заключается в том, что команды не будут знать о планах и результатах соперников до самого последнего дня. Никаких публичных питчей!
Вопросы можно задать и здесь, можно и там. Организаторы опубликуют несколько статей, посвящённых оптимизации ПО межсетевых экранов для помощи в выборе пути интересующимся. Если Вас заинтересовало это мероприятие, то добавьте этот пост в закладки, по выходу материалов мы добавим сюда или в комментарии ссылки.
PS ... и да, среди нас есть фанаты ленты Need For Speed, и скорость межсетевого экрана нам тоже очень нужна.
