🔑 Шпаргалка: Session-cookie, JWT, SSO и OAuth 2.0

Наглядная схема от ByteByteGo: как работает вход через сессию и токены, где браузер хранит cookie, как устроен JWT, как SSO объединяет вход для нескольких сервисов и как OAuth 2.0 выдаёт доступ по токенам.

📍 WWW-Authenticate (логин/пароль)
Браузер отправляет логин и пароль на сервер, сервер проверяет и пускает в приложение. Базовая точка старта, но дальше нужно решить, как “держать” авторизацию между запросами.

📍 Session-cookie
Сервер создаёт сессию и хранит её у себя, а браузеру отдаёт cookie с Session ID. На каждом запросе браузер приносит cookie, сервер по Session ID находит сессию и понимает, кто пришёл.

📍 Token
Клиент хранит токен (часто тоже в cookie/хранилище приложения) и передаёт его в запросах. Сервер проверяет токен сам или через отдельный Token Validation Service и принимает решение о доступе.

📍 JWT
Стандартизированный формат токенов с цифровой подписью. Содержит все необходимые данные и подпись для проверки подлинности. Самодостаточен — не требует хранения состояния на сервере.

📍 SSO
Единый вход через центральный сервис аутентификации (CAS/SSO): пользователь проходит авторизацию один раз, а затем получает доступ к нескольким приложениям через доверие к этому центру.

📍 OAuth 2.0
Описывает, как выдавать ограниченный доступ к данным между сервисами без передачи паролей и выбирать подходящий flow под сценарий:

— Authorization Code — браузер + сервер (самый распространённый для веба)
— Client Credentials — сервер-сервер (без пользователя)
— Implicit Grant — исторический вариант для браузера
— Password Grant — устаревший сценарий

#полезное

🎧 Как выбрать площадку для ПДн?

ИСПДн — это любая система, в которой обрабатываются персональные данные: клиентов и сотрудников.

Контур состоит из приложения, базы данных, интеграции, доступов, резервных копий, логов и журналов событий и т.д.

➡️ При выборе площадки важно понимать не только место размещения, но и зоны ответственности.

📍 Вариант 1.
On-Premise (всё на стороне организации)

Инфраструктура и система находятся в периметре организации.

— оборудование, сеть, системы хранения;
— резервное копирование и восстановление;
— администрирование, обновления, мониторинг;
— меры защиты (управление доступами, сегментация, журналирование, реагирование);
— комплект документов и подтверждение выполнения требований.

* подход даёт максимальный уровень контроля, но требует собственной экспертизы и постоянных затрат на поддержку и развитие.

📍 Вариант 2.
Площадка провайдера (ЦОД / выделенные ресурсы / colocation)

Размещение происходит на внешней площадке, но ИСПДн как система остаётся в зоне управления организации.

💬 Провайдер, как правило, отвечает за площадку:

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

💬 Организация отвечает за систему и данные:

— конфигурацию ИСПДн, администрирование, обновления;
— доступы, политики безопасности, сегментацию;
— резервные копии, журналы, контроль изменений;
— реагирование на инциденты и комплект документов.

* провайдер отвечает за площадку и её доступность, а за безопасность, настройки и эксплуатацию ИСПДн — отвечает организация.

📍 Вариант 3.
Облако провайдера (IaaS / PaaS)

Провайдер предоставляет инфраструктуру и, в зависимости от модели, часть платформенных сервисов. При этом ответственность за выполнение требований к защите ПДн и корректность настроек ИСПДн не «переезжает» в облако автоматически.

💬 Провайдер отвечает за свой слой:

— вычисления/хранилища/сети как сервис;
— доступность и работоспособность платформы на своей стороне;
— физическую среду размещения инфраструктуры.

💬 Организация отвечает за всё, что связано с данными и управлением ИСПДн от уровня ВМ:

— персональные данные и правила их обработки;
— пользователей и права доступа;
— сетевую конфигурацию и контуры доступа (в рамках облака);
— настройку логирования и резервного копирования (даже если это сервис провайдера — политика и контроль остаются на стороне организации);
— процессы реагирования и комплект документов между сторонами.

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

🟢 Хотите разобраться подробнее?

⏰ Приходите на открытый вебинар 3 декабря в 11:00 МСК.

Вероника Нечаева расскажет про облако и аттестованный ЦОД для ИСПДн, границы ответственности, аттестацию в облаке, документы между сторонами, типовые ошибки и кейсы.

➡️ Регистрация

🟡 Wazuh: мониторинг безопасности (SIEM/XDR)

Это open-source платформа для мониторинга безопасности инфраструктуры: собирает телеметрию и логи с серверов/ВМ/контейнеров, связывает события в цепочки, поднимает алерты и дает единое окно для расследований в дашборде.

Инструмент помогает навести порядок в событиях ИБ: от контроля изменений на хостах до обнаружения уязвимостей и базовых сценариев реагирования.

⚙️ Основной функционал:

— сбор логов и событий с хостов и сервисов, нормализация
— правила/корреляции, уровни критичности, оповещения и сортировка и приоритизации найденных уязвимостей
— контроль изменений: файлы, конфиги, ключевые директории (FIM)
— инвентаризация активов и ПО + сопоставление с уязвимостями
— проверки конфигураций и аудит под политики/требования
— реагирование по условиям (active response): блокировки/скрипты/автодействия
— веб-дашборды, поиск по событиям, отчёты и видимость по средам/сегментам

👉 Git
#полезное

⏳ 24 часа до вебинара

🕒 Уже завтра, 3 декабря, в 11:00 (МСК) Вероника Нечаева расскажет о безопасном размещении ИСПДн в соответствии с 152-ФЗ.


🎁 Бонус учасникам
— чек-лист выбора защищённого облака и проверки провайдера по ФЗ-152;
— персональная подборка материалов и методических рекомендаций;
— чек-лист из 36 пунктов подготовки к проверке РКН;
— возможность персональной консультации и разбора вашей архитектуры после вебинара.

🔗 Регистрация

🔐 RBAC в Kubernetes: best practices безопасности

Role-Based Access Control — стандартный механизм управления доступом в Kubernetes, обеспечивающий принцип наименьших привилегий и контроль над операциями в кластере.

✅ Зачем это нужно?

— Реализовать принцип наименьших привилегий
— Разделить обязанности между командами
— Соответствовать требованиям безопасности
— Предотвратить несанкционированный доступ к ресурсам

✅ Ключевые принципы

🔘Минимальные привилегии:

# минимальные необходимые права
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

🔘Разделение по namespace:

# Доступ только в конкретном namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "delete"]

✅ Критически важные практики

🔘Ограничение сервисных аккаунтов:

# Автоматическое монтирование токена только когда нужно
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
automountServiceAccountToken: false

🔘 Регулярный аудит RBAC:

# Проверка прав текущего пользователя
kubectl auth can-i list secrets --all-namespaces

# Аудит всех ClusterRole и Role
kubectl get clusterroles,roles --all-namespaces -o yaml

🔘 Избегание wildcard-прав:

# ОПАСНО:
verbs: ["*"]
resources: ["*"]

# БЕЗОПАСНО:
verbs: ["get", "list"]
resources: ["pods", "services"]

👀 RBAC — фундамент безопасности Kubernetes. Правильная настройка предотвращает 90% инцидентов, связанных с несанкционированным доступом.

#заметкиИнженера

🤩 Через 30 минут откладываем все дела, наливаем вкусный чай и готовимся получать много полезной и важной информации от Вероники Нечаевой.

🎙 В 11:00 по Мск вебинар про инфраструктуру и безопасное размещение ИСПДн

➡️ Регистрация

🔼 Подборка по ПДН:

🔵 Административная ответственность и штрафы

🔵 Вся Нормативно-правовая база СЗ ПДн

🔵 Перечень документов по защите ПДн

🔵 Как создать политику по обработке ПДн?

🔵 Где конкретно в нормативно правовой базе написано про СЗ ПДн?

🔵 Реализация мер защиты каждого из УЗ ПДн

🔵 Что делать если часть СЗИ уже есть, но сертификата у них нет?

🔵 Как вообще защищать ПДН?

🔵 Роадмэп защиты ПДН с нуля

🔵 Как определять уровень защищённости ПДН

🔵 Как подтвердить выполнение требований

🔵 Аттестация информационной системы по требованиям ФСТЭК

🔵 Обработка и защита персональных данных: кто ответственный?

🔵 Тильда и персональные данные

🔵 Как выполнить требования к уровню защищённости ИСПДн

🔵 Проверки по защите персональных данных: Роскомнадзор, ФСБ, ФСТЭК

🔵 Отличие соглашения о поручении на обработку персональных данных от передачи ПДн

🔵 Трансграничная передача ПДн: как выполнить требования

🔵 Как подобрать нужный тип и класс сертифицированных СЗИ

🔵 Отличия 17 и 21 приказов ФСТЭК

🔵 Как выбрать класс СКЗИ

🔵 Как сообщить в Роскомнадзор об утечке персданных?

🔵 Как определить класс защищённости ГИС?

🔵 Как составить модель угроз для ИСПДн
🔵 Как составить модель угроз: подробно о методике ФСТЭК

🔵 Защита обработки персональных данных в облаке по 152-ФЗ

🔵 Как провести аудит защиты персональных данных: пошаговая инструкция

🐶 Kerberos

Система аутентификации для ненадёжных сетей, разработанная в MIT в 1980-х годах.

Названа в честь трёхглавого пса Цербера из греческой мифологии — по аналогии с тремя компонентами системы.

Основная идея: никогда не передавать пароли по сети. Вместо этого используются зашифрованные "билеты".

💬 Ключевые компоненты:

— Client — пользователь/сервис, запрашивающий доступ
— AS (Authentication Server) — сервер аутентификации
— TGS (Ticket Granting Server) — сервер выдачи билетов
— SS (Service Server) — целевой сервис

💬 Процесс аутентификации:

1. Аутентификация
— Клиент → AS: "Я пользователь Иван"
— AS проверяет учётные данные и выдаёт TGT (Ticket Granting Ticket)

2. Получение сервисного билета
— Клиент → TGS: "У меня TGT, хочу доступ к сервису X"
— TGS проверяет TGT и выдаёт сервисный билет

3. Доступ к сервису
— Клиент → SS: "Вот мой сервисный билет"
— Сервис проверяет билет и предоставляет доступ

💬 Технические детали:

— Использует симметричное ширфрование (AES, DES)
— Время жизни билетов ограничено (обычно 8-24 часа)
— Требует точной синхронизации времени (NTP)
— Поддерживает mutual authentication (взаимную аутентификацию)

💬 Где используется:

— Active Directory — основа аутентификации Windows
— Hadoop — безопасность кластеров
— SSH — аутентификация через GSSAPI
— NFSv4 — сетевое хранилище
— FreeIPA — централизованное управление доступом

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

#линуксятина

📚 Сети с нулевым доверием: построение безопасных систем в ненадежных сетях

Практическое руководство по Zero Trust: как спроектировать и внедрить модель «нулевого доверия» в организации — от принципов и архитектуры до миграции с периметровых схем и рабочих сценариев внедрения.

🔎 Рассматривается:

— базовые принципы Zero Trust: непрерывная верификация, минимальные привилегии, микросегментация;
— механизмы контроля доступа, оценка доверия и современные подходы к аутентификации;
— интеграция защиты устройств, пользователей и сетевого трафика на практике;
— миграция на Zero Trust в реальных инфраструктурах и кейсы внедрения в организациях разного масштаба;
— фреймворки, архитектуры и методологии Zero Trust (в т.ч. NIST, CISA, DoD и др.), и влияние новых технологий (ИИ, квантовые вычисления) на эволюцию подхода.

Полезно специалистам по ИБ, архитекторам и инженерам, которые отвечают за модель доступа, сетевую сегментацию и практическое внедрение Zero Trust.

Авторы:
Дуг Барт, Эван Гилман, Кристина Морильо, Рази Райс.

Издательство:
БХВ, рус. изд., 2025 (2-е издание)

#книги

⚠️ Эмоции как точка взлома

Даже при хорошо защищённой инфраструктуре ИБ-инцидент начинается с человека — сотрудника или пользователя, который сам делает первый шаг.

🫨 Точкой входа мошенников являются эмоции: страх, тревога, паника, спешка, доверие к авторитету, стыд, вина, жадность/выгода, желание помочь.

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

Форматы атак:

➡️ Фишинг (phishing) — вам присылают “официальное” письмо/страницу, очень похожую на настоящую (банк, доставка, госуслуги), чтобы вы сами ввели логин, пароль или данные карты.

➡️ Звонки (vishing) — звонят и разыгрывают спектакль: “служба безопасности”, “следователь”, “оператор”, чтобы вы сообщили код, перевели деньги или установили приложение.

➡️ Мессенджеры (smishing / messenger phishing) — то же самое, но в Telegram/WhatsApp: пишут поддержка, коллега, знакомый и дают ссылку/файл или просят срочно сделать.

➡️ Письмо «от руководителя/партнёра» (BEC) — в рабочей почте имитируют начальника/контрагента и пытаются добиться оплаты счета, отправки документов или доступа.

➡️ Угон переписки (conversation hijacking) — мошенник встраивается в настоящую переписку и в нужный момент подменяет детали: новый счёт, правильная ссылка, перешлите сюда.

➡️ Удалённый доступ «для помощи» (remote access scam) — просят установить программу, чтобы помочь, а потом управляют вашим устройством и делают операции от вашего имени.

➡️ Поддельный голос/видео (deepfake / voice cloning) — делают голос/видео похожим на вашего знакомого и просят срочно перевести/дать доступ/подтвердить.

💊 Гигиена безопасности

⏺ Пауза и холодный рассудок — это ваша главная защита.

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

⏺ Коды и подтверждения

SMS-коды, пуши и одноразовые пароли — это ключи от ваших счетов и аккаунтов: нормальные службы их не спрашивают, а тот, кто спрашивает, чаще всего и есть мошенник.

⏺ Перепроверка

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

⏺ Ссылки и файлы

Неожиданный счёт/акт/фото/документ — стоп-сигнал: сначала проверяем отправителя и контекст, а потом открываем.

⏺ Удалённый доступ

Программы для удалённого доступа — это фактически пульт от вашего устройства: подключение допустимо только по понятной причине и только с проверенным специалистом.

⏺ 2FA

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

⏺ Пароли

Один пароль на всё утечка в одном месте открывает доступ в остальные; лучше менеджер паролей и уникальные комбинации.

⏺ Меньше личных деталей

Чем больше вы публикуете про работу, семью и привычки, тем проще мошеннику сделать правдоподобную легенду и втереться в доверие.

⏺ Ошиблись — говорите сразу.

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

#MentalDebug

⚖️ Изменения в законодательстве для ИТ

✉️ Новые правила аккредитации: с 1 января 2026 меняются требования к компаниям для получения и сохранения аккредитации.

✉️ 3% на подготовку кадров: крупные аккредитованные ИТ-компании должны направлять не менее 3% экономии от ИТ-льгот на подготовку специалистов .

✉️ Ограничения VPN: РКН усилил ограничения на отдельные VPN-протоколы.

✉️ Оборотные штрафы за срыв импортозамещения на значимых объектах КИИ: Минцифры обсуждает меры ответственности, предварительный срок перехода — до 1 января 2028.

✉️ Перечень доверенного российского ПО: правила ведения уже утверждены, а сам механизм начнёт действовать с 1 марта 2026 года.

✉️ Новые требования ФСТЭК к защите ГИС: приказ №117 вступает в силу с 1 марта 2026 — Нужно обновить модель угроз, привести меры защиты и документы в соответствие с новыми требованиями.

✉️ Проект ФСБ по непрерывному взаимодействию для субъектов КИИ: предложен порядок постоянного обмена информацией и реагирования на инциденты; документ пока в проекте.

#ИТиЗАКОН

😎 4 механизма аутентификации

Шпаргалка от bytebytego

Аутентификация — это способ подтвердить право на вход: кто вы для системы и можно ли вас пропустить.

🗝 SSH keys (SSH-ключи)
— доступ подтверждается владением приватным ключом (пароль не передаётся).

Используют для входа на серверы, доступа к Git-репозиториям и в автоматизации (CI/CD).

🗝 OAuth tokens (OAuth-токены)
— система выдаёт токен, который даёт ограниченный доступ на время и с заданными правами.

Чаще всего это вход через внешнего провайдера и доступ приложений к API.

🗝 SSL/TLS certificates (сертификаты)
— взаимная аутентификация сторон через криптографически подписанные удостоверения, выпущенные доверенным центром (CA). Одновременно устанавливает защищённый канал для передачи данных.

Это основа HTTPS и частый выбор для взаимной аутентификации сервисов.

🗝 Credentials (учётные данные)
— аутентификация через предварительно известный секрет: логин/пароль, API-ключ, токен доступа.

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

#полезное

🛡💻 Официальный чеклист безопасности от Kubernetes

Общие принципы

↪️ Принцип наименьших привилегий
— Всегда задавать минимально необходимые права для сервисных аккаунтов, пользователей и подов
— Использовать RBAC с явным указанием ресурсов и операций

↪️ Регулярные обновления
— Обновлять Kubernetes до последней стабильной версии
— Обновлять базовые образы и зависимости контейнеров

↪️ Аудит и мониторинг
— Включить аудит Kubernetes API (audit logging)
— Настроить мониторинг подозрительной активности

➡️ Основные направления для внедрения:

🟢 Security Context — настройка подов так, чтобы у них было минимум прав: без root, без лишних возможностей, с ограничением доступа к файловой системе.

🟢 Сетевая безопасность — правила сетевого доступа между сервисами: кто с кем может общаться, на какие порты и в каких направлениях.

🟢 Инструменты для проверки — чем регулярно проверять кластер, образы и манифесты: находить уязвимости и опасные настройки до попадания в прод.

🖱 Быстрый чеклист перед продакшеном

👀 RBAC настроен с минимальными привилегиями
👀 Pod Security Standards включены
👀 Network Policies ограничивают трафик
👀 Все образы сканированы на уязвимости
👀 Security Context настроен для всех подов
👀 Аудит Kubernetes API включён
👀 etcd зашифрован
👀 Регулярные обновления кластера
👀 Мониторинг безопасности настроен
👀 План реагирования на инциденты готов

✅ Проверка по чеклисту перед релизом помогает убрать основные риски.

✅ Следующий шаг — автоматизировать проверки и сделать их частью CI/CD и эксплуатации.

#гайды

📚 Облачные микросервисы

Практическое руководство по Kubernetes для построения масштабируемых и отказоустойчивых микросервисов в облаке — от деплоя до наблюдаемости.

🔎 Рассматривается:

— как применять Kubernetes для проектирования и эксплуатации микросервисов;
— стратегии высокой доступности и отказоустойчивости сервисов;
— CI/CD и практики доставки: GitOps и управляемые изменения;
— наблюдаемость: метрики, логи, трассировки и диагностика проблем;
— практические примеры с инструментами: Docker, Rancher, Terraform, Operators, Helm, Prometheus, Istio, Grafana, OpenTelemetry, Jaeger, Loki и др.

Полезно DevOps-инженерам, архитекторам ПО, а также системным администраторам и разработчикам, которые работают с микросервисами и Kubernetes-инфраструктурой.

Автор:
Аймен Эль Амри
Издательство:
ДМК Пресс, рус. 2024

#книги

🤖 External Secrets Operator (ESO) — Kubernetes-оператор, который подтягивает секреты из внешних хранилищ (Vault, AWS, GCP) и создаёт из них обычные Kubernetes Secrets.

➡️ Зачем это нужно?

— Хранить секреты в специализированных системах (Vault, AWS Secrets Manager)
— Автоматически обновлять секреты в Kubernetes при изменении во внешнем хранилище
— Избегать хранения чувствительных данных в Git и ConfigMaps
— Реализовать принцип zero-trust для секретов

➡️ Ключевые принципы

— SecretStore: CRD для конфигурации провайдера (Vault, AWS и т.д.). Указывает аутентификацию и параметры подключения.
— ExternalSecret: CRD, который ссылается на SecretStore и описывает, какие внешние секреты синхронизировать в K8s Secret.
— Синхронизация: Оператор периодически проверяет внешний источник и обновляет Secret в кластере.

➡️ Практический пример:
интеграция с HashiCorp Vault

📍 Создание SecretStore для Vault:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: vault-secret-store
  namespace: dev
spec:
  provider:
    vault:
      server: "https://vault.example.ru"
      path: "secret/project"
      version: "v2"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "external-secrets-operator"
          serviceAccountRef:
            name: external-secrets-operator

📍 Создание ExternalSecret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
  namespace: dev
spec:
  refreshInterval: "5m"
  secretStoreRef:
    name: vault-secret-store
    kind: SecretStore
  target:
    name: application-secrets
  dataFrom:
  - extract:
      key: dev/app/config

➡️ Что происходит после применения:

📍ESO подключается к Vault используя настроенный SecretStore
📍Читает секреты по указанному пути (dev/app/config)
📍Создаёт или обновляет Kubernetes Secret application-secrets в namespace dev
📍Автоматически обновляет secret каждые 5 минут

Поддерживаемые провайдеры:

— HashiCorp Vault
— AWS Secrets Manager
— GCP Secret Manager
— Azure Key Vault
— Kubernetes (другой кластер)
— GitLab CI/CD Variables
— 1Password, LastPass и другие

External Secrets Operator превращает управление секретами из рутинной операционной задачи в декларативный и безопасный процесс.

#заметкиИнженера

📦 HashiCorp Vault — платформа для централизованного управления секретами: хранение, выдача, шифрование и контроль доступа.

💬 Основные задачи Vault

— Централизованное хранение: пароли, API-ключи, TLS-сертификаты

— Данные для входа: временные учётные данные для БД и облачных сервисов

— Шифрование как сервис: шифрование/расшифровка через API без изменения логики хранения

— Аудит: журналирование операций и доступа к секретам

— Ротация: автоматическая смена секретов и сроков действия

💬 Secrets Engines (движки секретов)

— KV — произвольные секреты (key-value)

— Database — динамические учётные данные (MySQL, PostgreSQL, MongoDB)

— PKI — выпуск и управление TLS-сертификатами

— Transit — сервис шифрования (данные не хранятся, операции выполняются через Vault)

👀 Vault снижает риски утечек и ручных ошибок за счёт централизованных политик доступа, аудита и автоматизации работы с секретами.

#полезное

🖥 Lynis — инструмент для проверки безопасности и соответствия стандартам в Linux-системах.

Разработанный Michael Boelen, он выполняет сотни тестов для выявления уязвимостей и проблем конфигурации.

💬 Что проверяет:
— Настройки ядра и системные параметры
— Права доступа и аутентификация
— Конфигурации сетевых служб
— Наличие обновлений безопасности
— Соответствие стандартам CIS, NIST, HIPAA
— Логирование и мониторинг

💬 Основное использование:

🔴 Базовый аудит:

# Запуск с правами root
sudo lynis audit system

# Проверка раздела SSH
sudo lynis audit system --tests-from-group ssh

🔴 Расширенная проверка:

# Детальный отчёт с сохранением результатов
sudo lynis audit system --quick --nocolors --report-file /tmp/lynis-report.txt

# Проверка на соответствие стандарту CIS
sudo lynis audit system --profile cis

# Просмотр доступных тестов
sudo lynis show tests

💬 Анализ результатов:

После запуска Lynis предоставляет:
— Оценку безопасности (hardening index) от 0 до 100
— Предупреждения (warnings) — критичные проблемы
— Советы (suggestions) — рекомендации по улучшению
— Обнаруженное ПО — установленные пакеты и версии

Lynis превращает сложный аудит безопасности в простую регулярную процедуру. Это must-have инструмент для любого администратора, который хочет спать спокойно, зная что его системы защищены.

👉 Git
#линуксятина

🖥 GitHub-подборка: утилиты для анализа сетевого трафика

➡️ tcpdump
— классический консольный сниффер для захвата и анализа сетевых пакетов. Работает на любом Linux без GUI.

➡️ Wireshark
— мощный графический анализатор трафика с поддержкой тысяч протоколов и возможностью глубокой инспекции пакетов.

➡️ Termshark
— терминальный интерфейс для Wireshark с TUI, позволяет анализировать трафик прямо в консоли.

➡️ Sniffglue
— безопасный сниффер на Rust с минимальными привилегиями и изоляцией через seccomp.

➡️ Moloch
— масштабируемая система для захвата, индексации и анализа сетевого трафика в больших сетях.

Все инструменты open-source и активно развиваются, покрывая разные сценарии анализа — от быстрой отладки на сервере до мониторинга корпоративных сетей.

#полезное

🐠 asciiquarium в терминале

Это консольная «игрушка»-скринсейвер: рисует подводный мир в ASCII-графике прямо в терминале.

🪸 Рыбки, водоросли и прочие морские обитатели — всё на символах, без GUI.

📍 Работает просто:
ввёл asciiquarium — и терминал на время превращается в аквариум.

📍 Управление:

q — выход
p — пауза
r — перерисовать сцену
-c — classic mode (только «классические» виды)

Можно включать на фоне во время созвонов или просто проветрить голову между задачами.

# Запуск
asciiquarium

# Debian / Ubuntu (если пакет есть в репозиториях)
sudo apt update
sudo apt install asciiquarium

# Fedora
sudo dnf install asciiquarium

# Arch / Manjaro
sudo pacman -S asciiquarium

# macOS (Homebrew)
brew install asciiquarium

# Если в Ubuntu пакет не находится — вариант через snap
sudo snap install asciiquarium

# Вручную (Perl-зависимости, если нужно)
sudo apt-get install libcurses-perl
sudo cpan Term::Animation

P.S. хороших выходных 😍

#rootoffun

🎙️ За неделю

✉️ ОЗУ резко подорожала — на рынке нехватка DRAM/NAND, а производители и дистрибьюторы в первую очередь закрывают спрос со стороны дата-центров и крупных ИИ-проектов. Апгрейды и сборки ПК станут заметно дороже, а по некоторым модулям возможны задержки и нестабильная доступность.

✉️ МФТИ протестировали китайские ускорители Moore Threads S4000 и MetaX C500: они стабильно работают с популярными LLM и фреймворками, а в отдельных задачах идут на уровне NVIDIA A100 или быстрее; отдельно отметили кластерные сценарии и рост софта под них.

✉️ Появилось больше уязвимостей, которые злоумышленники могут использовать сразу: примерно в 450 таких случаев против 114 годом ранее. Часть из них критические, чаще всего — в промышленном ПО и системах АСУ ТП. Отдельно отмечают рост доли уязвимостей в российском ПО до 30% — это означает больше затрат на проверки безопасности и исправления.

✉️ Сотрудники часто не понимают, зачем нужны правила ИБ: только 24% считают требования по ИБ оправданными, а 71% сомневаются, что они действительно нужны. Основная причина — правила выглядят как набор запретов без объяснений и мешают работе, поэтому их нередко соблюдают формально или обходят.