Информационная безопасность *

Если верить Вики — ipv6 появился раньше, чем я научился соединять два компьютера в сеть, но за всё эти годы, несмотря на всё, нигде, никогда на практике я с ним не сталкивался.
Ну да, есть иногда на интерфейсах какие‑то странные длинные адреса, на какая от них польза и зачем они вообще — совершенно непонятно.

И вот в обсуждениях очередной статьи — очередное «никто почему‑то не хочет использовать ipv6» — так может быть, пора попробовать?

Сразу дисклеймер: тут на Хабре уже есть хорошая техническая статья именно по ipv6, лучше я точно не напишу, но зато напишу, так сказать, с бытовой точки зрения: что мне это может дать и зачем.

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

Конечно, тяжело написать универсальный гайд, который полностью закроет все вопросы по ИБ для каждого случая. Все кейсы — разные и требуют отдельного рассмотрения и анализа, а также регулярного обновления средств защиты и мониторинга для поддержания системы в актуальном состоянии.

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

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

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

Взгляд безопасника на ежегодный отчет Github Octoverse 2025. Отчет 2025 выглядит как вестник новой реальности, где ИИ в разработке будет отведена ключевая роль. Постарался дать пару советов для безопасников которых ждет такое значимое изменение подходов.

Cейчас, когда связь с внешними сервисами работает с перебоями, а самым стабильным международным способом созвониться теперь является, внезапно, Steam, VoIP которого точно не блокируется, возникает резонный вопрос: а как коммуницировать хотя бы в рамках собственной компании? Особенно с учетом того, что Discord давно и надежно заблокирован, Slack с рынка ушел, а популярные публичные мессенджеры замедляются или рискуют отправиться в бан? Решение очевидно: поднимать собственные текстовые и VoIP-сервера, о чем мы и поговорим в статье на примере связки Matrix и Jitsi.

Эта история началась в далёком 2021 году, когда я на стихающей волне хайпа криптовалют решил купить немного биткоинов и эзериумов. Просто на всякий случай, чтобы были, вдруг их стоимость вырастет в 100 раз. Честно говоря, они так и пролежали большую часть времени в кошельке. Я сделал пару покупок просто, чтобы потратить их хоть на что‑то, например, оплатил хостинг у одного провайдера.

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

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

По мере роста требований регуляторов нагрузка увеличивается. Стандарт ГОСТ 57580, положения Банка России, международные стандарты, внутренние регламенты — всё это формирует массив нормативов, который необходимо не только исполнять, но и постоянно подтверждать доказательной базой. Для крупных банков это тысячи документов, десятки тысяч артефактов, сотни участников согласований. Каждое обновление нормативов заставляет команды заново пересматривать формы контроля, переписывать документы, изменять регламенты и собирать подтверждения. В результате процесс, который должен обеспечивать устойчивость, превращается в бесконечный цикл подготовки к проверкам.

Юрий Подгорбунский, Security Vision

Что же такое NIST CSF 2.0?

NIST Cybersecurity Framework 2.0 — это концепция кибербезопасности (CSF) разработана Национальным институтом стандартов и технологий США (NIST) для того, чтобы предоставить организациям комплексный, а также гибкий подход к управлению и снижению рисков кибербезопасности, используя таксономию общих показателей кибербезопасности, которая может применяться любой организацией независимо от ее размера, отрасли или уровня развития. Концепция призвана помочь организациям управлять рисками ИБ, тем самым повышая уровень кибербезопасности.

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

Kubernetes в IT-инфраструктуре — это не просто про удобство деплоя. Это критическая часть сервиса. Одна неправильная настройка kube-apiserver или etcd — и вместо кластера вы получите бублик с дыркой, через который утекут и данные, и бизнес-процессы.

В этой статье разберем, какие стандарты защищают контейнерные среды, почему CIS-бенчмарк часто становится первой точкой опоры, какие практики дополняют его и как Managed Kubernetes превращается в автоматизированный рабочий процесс. Детали внутри.

Приветствую, Хабр!

Совсем недавно – в августе текущего года – Институт стандартов и технологий США NIST выпустил стандарт NIST SP 800-232 [1], описывающий четыре низкоресурсных криптографических алгоритма на базе семейства алгоритмов Ascon:

· алгоритм аутентифицированного шифрования с присоединенными данными Ascon-AEAD128;
· три алгоритма хеширования: Ascon-Hash256 (классическая хеш-функция), Ascon-XOF128 (хеш-функция с переменным размером выходного значения) и Ascon-CXOF128 (хеш-функция с кастомизацией и переменным размером выходного значения). 

Предыдущий опыт показывает, что криптографические стандарты США после их принятия обычно широко используются во всем мире, поэтому данный документ может представлять значительный интерес и достоин детального разбора (краткий обзор стандарта NIST SP 800-232 уже был опубликован на Хабре ранее здесь), который я и предлагаю вам в двух частях в этой (и следующей) статье.

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

Никаких домыслов — только измерения, цифры и технические факты.

На прошлой неделе в Таиланде прошла ежегодная конференция Security Analyst Summit, организуемая «Лабораторией Касперского». Один из главных докладов конференции был посвящен операции «Форумный тролль» — кибершпионской кампании, нацеленной на организации в России. Обнаружение данной угрозы помогло экспертам «Лаборатории Касперского» еще в марте этого года выявить уязвимость нулевого дня в браузере Google Chrome, о которой было сообщено еще весной. Дальнейшее исследование атаки помогло связать ее с деятельностью компании Memento Labs, ранее известной как Hacking Team.

Атака начиналась с рассылки правдоподобных сообщений с приглашением на мероприятие. Открытие ссылки в этом письме в итоге приводило жертв на подлинный веб-сайт, но в процессе они также направлялись на вредоносную страницу, откуда загружался вредоносный скрипт. Этот код задействовал уязвимость в браузере Chrome, которая позволяла полностью обойти «песочницу» — технологию ограничения доступа к системным ресурсам. Как выяснилось, причиной возникновения уязвимости стала особенность работы Windows.

Здраствуйте, коллеги. Сегодня делаем базовые конфиги на Palo Alto: NAT для выхода в интернет, лог-форвардинг, security-профили, интерфейсы, роутинг и сервисные роуты. Всё коротко, понятно, с примерами.

Здравствуйте, коллеги. Сегодня с вами будем настраивать GRE, как всегда, практическая реализация.

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

Так что если не читал — советую глянуть ту статью, там всё есть.

Сегодня у нас другой случай. Будем настраивать его между Palo Alto и Cisco. Вот наша топология.

Как прошел ваш Хэллоуин? Вот мы в СайберОК качественно повеселились и попугались, потому что наши эксперты-охотники на привидений до самого рассвета рыскали по внешнему периметру Рунета и вытаскивали на свет главных монстров октября – как новых, так и хорошо забытых старых.

Всем привет! Закрываем октябрь подборкой самых горячих ИБ-новостей. В прошлом месяце инфобез-гигант F5 раскрыл масштабную компрометацию своих систем госхакерами. А у AWS произошёл коллапс облачной инфраструктуры, на сутки положивший тысячи сервисов.

У разработчика спайвари Trenchant случился шпионский скандал, британская военка отметилась очередным постыдным взломом. А OpenAI отметилась первым кейсом по взаимодействию с органами, в котором по запросу о содержимом чатов сдали киберпреступника. Об этом и других интересных событиях в мире инфобеза за октябрь читайте под катом!

История Solar appScreener началась в одной из российских IT-компаний, в которой тогда работала команда основателей «Солара». Они занимались консалтинговым бизнесом и наблюдали кардинальные изменения на рынке, которые стали почвой для будущей разработки продукта в сегменте application security.

К 2014-2015 гг. проблема безопасной разработки приложений стала острой и заметной не только для отраслевого сообщества, но и регулярно привлекала внимание общественности. Более чем в 75% успешных кибератак уже тогда эксплуатировались «дыры» в ПО, которое в то время было самых слабым звеном с т.з. технической защиты. Например, 15% от всего количества опубликованных уязвимостей приходилось на уязвимости для платформы Android. Громким событием первой половины 2010-х также был хакерский взлом AppStore, в ходе которого в ряд приложений был внедрен вредоносный код XCodeGhost.

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

Так возникла идея российского AppSec-продукта: для отечественных компаний, на родном языке, с понятными рекомендациями, четким анализом и наукоемкими технологиями под капотом.

Всех приветствую! Ещё год назад я играл в CTF и работал как SOC-аналитик L1, а сегодня в компании «Газинформсервис» занимаюсь тестированием веб-ресурсов. В свободное время багханчу, и больше слов о моих успехах скажет статистика в профиле амбассадора Standoff. На Standoff Talks я выступил с докладом об эффективном поиске уязвимостей и хочу поделиться этим опытом здесь.