🚪 iSCSI (Internet Small Computer System Interface)— протокол блочного доступа, инкапсулирующий команды SCSI в TCP/IP.

Позволяет подключать удалённые блочные устройства по IP-сети так, будто это локальный диск.

➡️ Архитектурная модель iSCSI:
— Target — сервер, предоставляющий блочные устройства (LUN).
— Initiator — клиент, подключающийся к таргету и получающий доступ к этим устройствам.

➡️ Установка и настройка iSCSI Target

# Установка (Debian/Ubuntu):
sudo apt install tgt

Конфигурация — файл /etc/tgt/conf.d/debian.conf. Пример создания LUN:

debian.conf
<target iqn.2026-02.example:storage.lun1>
    backing-store /dev/sdb           # или путь к файлу-образу
    initiator-address 192.168.1.0/24 # разрешённые инициаторы
</target>

После изменения конфигурации перезапустите службу:

sudo systemctl restart tgt

➡️ Установка и основные команды для iSCSI Initiator

# Установка (Debian/Ubuntu)
sudo apt install open-iscsi

#Обнаружение таргетов
sudo iscsiadm -m discovery -t sendtargets -p <IP_таргета>

#Подключение к таргету
sudo iscsiadm -m node -T <IQN> -p <IP> --login

#Просмотр активных сессий
sudo iscsiadm -m session

#Отключение
sudo iscsiadm -m node -T <IQN> -p <IP> --logout

ISCSI превращает IP-сеть в гибкое хранилище уровня SAN — бесплатная альтернатива Fibre Channel для виртуализации, кластеров и бэкапов. open-iscsi (инициатор) и tgt (таргет)/

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

🥳 С Всемирным днём управления информацией!

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

🔎 Полезная подборка по управлению информацией:

• Как настроить резервное копирование и работать без перебоев

• Как избежать потерь: стратегии Disaster Recovery для бизнеса

• 99,99% времени без перебоев: как обеспечить надёжную работу ИТ-систем

• Бэкап: как сделать резервное копирование надёжным

• Информационная безопасность за 10 минут: с чего начать

• Сравнение средств защиты от несанкционированного доступа

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

🖥 Что такое ЦОД по 152-ФЗ в понимании РКН?

Ошибки в трактовке статуса ЦОДа напрямую влияют на уведомление об обработке ПДн, уровень защищённости ИСПДн и распределение ответственности между оператором и провайдером.

Выложили эпизод из вебинара про инфраструктуру для ПДн.

В видео:
— нормативное определение ЦОДа;
— разница между обычным и аттестованным ЦОДом;
— ограничения по уровням защищённости;
— где находится ЦОД при использовании 1С, Bitrix и облаков;
— как корректно определить границу ответственности.

🤓 Смотрите на наших площадках:
▶️ Rutube
▶️ YouTube
▶️ VK Видео

#полезное

🧘 Nafas
— CLI-утилита с готовыми программами дыхательных упражнений.

Запускается прямо из терминала.

😤 Внутри:
— несколько режимов (Relax, Anti-Stress, Power и др.)
— заданный ритм: вдох / задержка / выдох
— короткие сессии на 2–5 минут

Можно использовать в середине дня, чтобы восстановить концентрацию, после напряжённой задачи или перед важным созвоном.

✈️ Установка и запуск

pip install nafas
nafas

P.S. хороших праздничных выходных 🎉

#rootoffun

⚖️ Законы для ИТ и связи

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

👀 Подписан закон, по которому операторов связи обязали приостанавливать услуги по требованию ФСБ (вступает в силу в марте 2026). Важно заранее продумать резервирование и альтернативные каналы связи.

👀 Специальные энергетические зоны для размещения ЦОД под задачи ИИ обсуждают в России — с приоритетным доступом к мощности и упрощённым подключением к сетям.

#ИТиЗАКОН

🕵️‍♀️ Shadow IT — ресурсы вне контроля ИТ-службы: несанкционированные, неучтённые или забытые системы, сервисы и инфраструктура.

🎭 Как они появляются

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

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

🎭 Какие риски несут

❌ Расходы: появляются неучтённые платежи, дублируются сервисы, сложно понять, за что платит компания
❌ Безопасность: данные могут храниться вне контролируемого контура, доступы не отслеживаются
❌ Устойчивость: такие системы не входят в резервирование и планы восстановления
❌ Дополнительно: сложности с аудитом, поддержкой и зависимость от отдельных сотрудников

🙂 Как найти теневые ресурсы

✅Проверить расходы: счета, подписки, облачные биллинги, корпоративные карты — по ним видно сервисы, которые не проходят через ИТ

✅ Посмотреть трафик: DNS-запросы, прокси, CASB или SWG — показывают, какими внешними сервисами реально пользуются

✅ Проверить облака: аудит аккаунтов, проектов и ресурсов — часто находятся забытые VM, хранилища и тестовые среды

✅ Проверить доступы: какие учётные записи существуют, у кого есть права, какие сервисы привязаны к личным почтам — так выявляются «сиротские» ресурсы

✅ Поговорить с командами: часть инструментов не видна технически — о них можно узнать только от пользователей

#полезное #гайды

💻 Дебаг подов без боли: эффемерные контейнеры в Kubernetes

В версии Kubernetes 1.25 стала стабильной функция эффемерных контейнеров (ephemeral containers).

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

🤔 Как это работает?

Эффемерный контейнер добавляется через специальный ресурс EphemeralContainers или командой kubectl debug. Kubelet создаёт новый контейнер в том же поде, не перезапуская уже работающие контейнеры. Он разделяет с подом:

— Сеть (network namespace)
— Пространство имён PID (чтобы видеть процессы)
— Межпроцессное взаимодействие
— Тома

После завершения отладки контейнер остаётся в статусе Completed (или удаляется при использовании --rm), но не перезапускается.

🤔 Пример использования

kubectl debug my-app -it --image=nicolaka/netshoot -- bash

Эта команда запускает временный контейнер с образом nicolaka/netshoot (набор сетевых утилит) внутри работающего пода my-app. Благодаря общим namespace'ам контейнер получает доступ к процессам, файловой системе и сетевым интерфейсам оригинального пода — даже если его собственный образ собран на scratch. После завершения отладки контейнер останавливается, не влияя на работу приложения.

🤔 Когда это особенно полезно?

— Приложения на distroless/scratch — нет shell.
— Диагностика сети из контекста пода (curl, ping, tcpdump).
— Проверка состояния томов (например, emptyDir или ConfigMap).
— Анализ потребления ресурсов процессами (через / proc).

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

⚙️ netshoot — набор сетевых утилит для диагностики в контейнерах

Образ nicolaka/netshoot — это «швейцарский нож» для сетевой отладки в Kubernetes и Docker.

Внутри — десятки предустановленных инструментов, которые покрывают почти любую задачу: от простого ping до трассировки gRPC-запросов.

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

— Базовые утилиты: ping, traceroute, mtr, dig, nslookup, host, whois.
— Продвинутая диагностика: tcpdump, tshark, netstat, ss, lsof.
— Тестирование производительности: iperf, iperf3, httping.
— Работа с HTTP/HTTPS: curl, wget, httpie, grpcurl, wrk, vegeta.
— Сетевые сканеры: nmap, masscan, hping3.
— Крипто/сертификаты: openssl, cfssl, ssh-client.
— Дополнительно: jq, drill, socat, netcat, socat, vim, git.

✅ Ключевые особенности:

— Всё в одном: не нужно подбирать отдельные образы под каждую задачу.
— Актуальность: образ регулярно обновляется, включаются новые версии утилит.
— Минимальный вес: базируется на Alpine, что позволяет быстро запускать контейнер даже на медленных соединениях.
— Идеален для Kubernetes: легко использовать с kubectl debug для создания эффемерных контейнеров прямо в поде.
— Гибкость: можно запускать как отдельный под для диагностики сети между сервисами.

👉 Git
#полезное

😵‍💫 Зомби-процессы в Linux: что это и как с ними бороться

Зомби (состояние Z в ps) — это завершившиеся процессы, которые всё ещё присутствуют в таблице процессов. Они ждут, пока родитель прочитает их код возврата через системный вызов wait(). После этого запись о процессе исчезает.

👻 Чем опасны?

Сами по себе зомби не потребляют ресурсы (CPU, память), но занимают слот в таблице процессов. Если родительский процесс никогда не вызывает wait(), зомби накапливаются. Когда таблица процессов заполняется, система перестаёт создавать новые процессы — это может привести к отказу сервисов. Кроме того, большое число зомби — явный признак бага в родительском приложении.

👻 Как найти?

Самый простой способ — использовать ps -eal или aux и grep состояние Z:

ps aux | grep ' Z '

Более детальный вывод с информацией о родителе:

ps -eal | awk '{ if ($2 == "Z") print $4, $14 }'

Здесь $2 — код состояния, $4 — PID, $14 — имя процесса.

✅ Как избавиться?

Если зомби уже есть, можно попробовать:

— Отправить сигнал SIGCHLD родителю (не всегда помогает, так как родитель может игнорировать сигналы).
— Завершить родительский процесс (если это возможно).
— Перезапустить сервис, который порождает зомби.

⚠️ Главное — не убивать зомби напрямую (kill -9 на PID зомби не работает, потому что процесс уже мёртв). Устранять нужно причину — родительский процесс.

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

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

📖 Практическая безопасность Linux

Руководство по защите Linux-систем: от базовой архитектуры безопасности до настройки механизмов контроля доступа, аудита и реагирования на инциденты.

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

— архитектура безопасности Linux и модель прав доступа (DAC, MAC);
— механизмы контроля: SELinux и AppArmor;
— безопасная загрузка, аудит и журналирование событий;
— изоляция процессов и контейнеризация;
— защита памяти и настройка компилятора;
— методы шифрования и защиты данных;
— сетевая безопасность и контроль трафика;
— обнаружение атак и использование IDS/IPS;
— анализ инцидентов, сбор и разбор логов;
— основы цифровой криминалистики и постинцидентное восстановление.

Автор:
Александр Чайка
Издательство:
БХВ-Петербург, 2026 г.

#полезное #книги

📝 Медицинские данные в облаке: как закрыть 152-ФЗ без своего ЦОДа

Сервис F.Doc перевёл обработку персональных данных пациентов в защищённое облако SafeCloud — без развертывания и аттестации собственного ИБ-контура.

✅ Проект закрыл сразу несколько задач: соответствие 152-ФЗ, защита медицинской тайны и стабильная работа сервиса без простоев при миграции.

👉 Как выстроили защищённый контур, почему отказались от on-prem и что это дало бизнесу — рассказали в новом материале.

#статья #изПрактики

🌐 Как работает DNS

Шпаргалка показывает путь от доменного имени до ответа сервера — какие узлы участвуют и как именно находится нужный IP.

1️⃣ Пользователь → браузер
— старт запроса.

Пользователь вводит домен (например, cortel.cloud ), браузер начинает поиск IP-адреса.

2️⃣ Кэш браузера / ОС
— первая проверка.

Если IP уже сохранён локально — он сразу используется. Если нет — запрос уходит дальше.

3️⃣ DNS-резолвер
— точка входа в DNS.

Браузер отправляет запрос резолверу (обычно провайдера или публичному DNS). Резолвер также проверяет свой кэш.

4️⃣ Root DNS Server
— начало цепочки поиска.

Если в кэше пусто, резолвер обращается к корневому серверу и получает указание на TLD-зону (.com).

5️⃣ TLD Name Server
— уровень доменной зоны.

TLD-сервер сообщает, какой авторитетный сервер отвечает за нужный домен.

6️⃣ Authoritative DNS Server
— финальный источник.

Возвращает конкретную запись A/AAAA — IP-адрес домена (например, 95.181.181.7).

7️⃣ Возврат и кэширование
— ускорение следующих запросов.

IP сохраняется в кэше резолвера и браузера, после чего передаётся клиенту.

8️⃣ HTTP-запрос
— получение контента.

Браузер обращается по IP к веб-серверу, отправляет GET-запрос и получает ответ (HTML страницы).

#полезное

🎉 С Днем Хостинг провайдера!

Отпраздновали 1 марта, а поздравляем сейчас 🥳

Желаем стабильного аптайма, отсутствия критических инцидентов и предсказуемой нагрузки, надёжной инфраструктуры, роста без потери качества сервиса и благодарных клиентов!

Подборка статей: как строить надёжную инфраструктуру

✅ SLA на практике: что стоит за 99,9%

✅ SLI / SLO / SLA за 10 минут

✅ 5 ошибок при переходе в облако

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

✅ 152-ФЗ: как выполнить требования регуляторов

✅ Disaster Recovery за 15 минут

✅ Стратегии Disaster Recovery для бизнеса

#полезное

🕵️‍♀️ Shadow Data — рабочие данные, которые существуют вне официального учёта и контроля.

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

Это могут быть выгрузки из CRM, копии клиентских баз, отчёты, дампы, архивы, таблицы с персональными данными и т.д.

Файл сохранили локально, переслали в личную почту, оставили в старом облаке или тестовой среде — и он перестал быть видимым для ИТ и ИБ.

❌ Риски от теневых данных.

❌ Неконтролируемый контур обработки данных
Данные существуют вне утверждённых систем и процессов защиты. Компания не управляет этим сегментом, но он влияет на общий уровень риска.

❌ Неучтённые доступы
Файлы могут храниться на личных устройствах, в сторонних сервисах или старых папках с устаревшими правами. Формально доступ ограничен, фактически — нет.

❌ Утечки
Именно такие копии чаще становятся источником инцидентов: потерянные ноутбуки, взлом личной почты, открытые ссылки в облачных хранилищах.

❌ Ответственность за ПДн и чувствительные данные
Даже если компания не знала о существовании конкретной копии базы клиентов, ответственность за защиту персональных данных остаётся.
Неучтённые данные не освобождают от требований законодательства.

❌ Инциденты и расследования
После утечки возникает вопрос: где ещё есть копии?
Если инвентаризации нет, расследование затягивается, а подтвердить полноту устранения последствий становится сложно.

🔍 Как обнаруживать и предотвращать

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

✅Data discovery (поиск и выявление данных в инфраструктуре) и сканирование хранилищ
Поиск чувствительных данных в файловых шарах, облаках, на рабочих станциях и в почтовых ящиках.

✅Контроль выгрузок и пересылок
DLP, мониторинг почты и облачных сервисов, ограничения на скачивание баз и массовые экспорты.

✅Минимальные привилегии и регулярный пересмотр доступов
Если доступ выдан на всякий случай и не пересматривается годами, риск только накапливается.

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

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

#полезное #гайды

🔥Подборка материалов по работе с данными

— Практики управления доступами и предотвращения утечек
— Как наладить информационную безопасность компании
— Чем опасны утечки данных
— Как сообщить в Роскомнадзор об утечке персданных
— Аудит информационной безопасности

📹 А еще много полезного видео про работу с ПДн в наших каналах
Rutube
YouTube
VK Видео

💻 Как работает DNS в Kubernetes?

В Kubernetes поды динамически создаются и удаляются, их IP-адреса меняются. Использование конкретных адресов невозможно, поэтому в кластере функционирует внутренняя DNS-система, позволяющая обращаться к сервисам по именам.

CoreDNS — стандартный DNS-сервер Kubernetes. Он работает внутри кластера, как набор подов. Основная задача — обработка DNS-запросов от всех подов кластера.

При создании Service (например, app в namespace dev) Kubernetes API передаёт его имя и IP в CoreDNS. а он автоматически создаёт A-запись (или SRV, если необходимо).

➡️ Формирование DNS-имени ресурса в кластере.

Система строится вокруг домена кластера (по умолчанию — cluster.local).

Для сервиса (Service). Полное имя (FQDN) имеет вид: <service-name>.<namespace>.svc.cluster.local

🔵Пример: Для сервиса redis-cash в namespace stage полное имя — redis-cash.stage.svc.cluster.local. Под из любого другого namespace может обратиться к нему по этому имени.

🔵Короткая форма: Внутри одного namespace можно использовать только имя сервиса — redis-cash. DNS-запрос автоматически дополнится до полного имени благодаря настройкам поиска в /etc/resolv.conf пода.

➡️ Проблема масштабирования CoreDNS

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

➡️ Принцип работы:

1. На каждой ноде под node-local-dns работает в режиме hostNetwork.
2. Правила iptables настраиваются так, чтобы трафик к сервису kube-dns не покидал ноду, а перехватывался локальным агентом.
3. Агент слушает локальный адрес (например, 169.254.20.10) и кеширует ответы.

Понимание того, как устроены CoreDNS и NodeLocalDNS, даёт ключ к быстрой диагностике проблем сетевой связности в кластере. Часто за внешними симптомами падения сервиса скрывается не ошибка в коде, а некорректная работа DNS-инфраструктуры — и умение разобраться в ней превращает непонятный инцидент в рутинную задачу с быстрым решением.

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

ExternalDNS — это Kubernetes-контроллер, который автоматически управляет DNS-записями у внешних провайдеров на основе ресурсов кластера. Он отслеживает появление, изменение и удаление Ingress, Service (типа LoadBalancer) и других объектов и соответствующим образом обновляет DNS-зону, избавляя от ручного вмешательства.

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

— Автоматическое создание/обновление DNS записей у указанного DNS-провайдера.
— Удаление устаревших записей: при удалении ресурса запись автоматически убирается из DNS-зоны.
— Гибкая настройка источников: может работать с Ingress, Service (type=LoadBalancer), а также с Gateway API и другими CRD.
— Фильтрация и области видимости: позволяет ограничить синхронизацию конкретными namespace, аннотациями или доменами.

Ключевые особенности:

▪️ Декларативность и согласованность —
состояние DNS всегда соответствует реальному состоянию сервисов в кластере. Никаких рассинхронизаций.

▪️ Поддержка ownership —
еxternalDNS помечает созданные им записи специальными тегами (или TXT-записями), чтобы не трогать записи, созданные вручную.

▪️ Гибкая настройка TTL —
можно задавать время жизни записей как глобально, так и через аннотации к конкретным ресурсам.

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

👉 Git
#полезное

🖥 dig (domain information groper) — мощная утилита для выполнения DNS-запросов и получения детальной информации о доменах. Входит в состав пакета dnsutils (Debian) или bind-utils (RHEL). Незаменима при поиске проблем с резолвингом, проверке зон и отладке DNS-серверов.

⚙️ Как работает?

dig отправляет DNS-запрос указанному серверу (или системному резолверу по умолчанию) и выводит полученный ответ в структурированном виде. В отличие от nslookup или host, dig показывает полную информацию: заголовки запроса, секции ответа, время отклика и статистику.

➡️ Основные примеры использования

Простой запрос A-записи

dig cortel.cloud 

; <<>> DiG 9.20.20 <<>> cortel.cloud
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48488
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cortel.cloud.      IN  A

;; ANSWER SECTION:
cortel.cloud.    4746  IN  A  95.181.181.7

;; Query time: 174 msec
;; SERVER: 77.88.8.8#53(77.88.8.8) (UDP)
;; WHEN: Tue Mar 05 11:15:58 +03 2026
;; MSG SIZE  rcvd: 57

Запрос к определённому DNS-серверу

dig @8.8.8.8 cortel.cloud    # использовать DNS Google

Краткий вывод (только ответ)

dig cortel.cloud +short

95.181.181.7

Полезные опции

— +noall +answer — показать только секцию ответа.
— +stats — добавить статистику (время, размер).
— +tcp — использовать TCP вместо UDP.
— +dnssec — запросить DNSSEC-данные.

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

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

🔮 fortune

Предсказания прямо в терминале

Классическая консольная утилита, которая достает из терминальной вселенной послания специально для тебя 🃏

🧑‍💻 Установка:

# Ubuntu/Debian
sudo apt install fortune-mod

# Fedora
sudo dnf install fortune-mod

# Arch/Manjaro
sudo pacman -S fortune-mod

# macOS
brew install fortune

Пример:

user@ubuntu::~ $ fortune
What do you have when you have six lawyers buried up to their necks in sand?
Not enough sand.

user@ubuntu:~ $ fortune
There is no education that is not political.  An apolitical
education is also political because it is purposely isolating.

user@ubuntu::~ $ fortune
Hacker's Law:
  The belief that enhanced understanding will necessarily stir
  a nation to action is one of mankind's oldest illusions.

user@ubuntu:~ $ fortune
QOTD:
  All I want is more than my fair share.

P.S. И еще оракул предсказал, что в эти выходные будет много цветов и красоты 🌸

#rootoffun

💐 С 8 Марта, прекрасная половина ИТ-вселенной!

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

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

С праздником!