Сетевик Джонни // Network Admin

🥷 Подключилось новое устройство. Назвалось «принтер_бухгалтерия». IP свободный, MAC похож на настоящий.

Вы же не пустите его в VLAN с серверами просто потому, что оно хорошо представилось? В жизни то же самое. Новый человек написал: «Ты мне нравишься». Красивый hostname, аватарка как с обложки, а что внутри, неизвестно.

Сетевики это знают: пинг прошёл ≠ можно доверять.

Zero trust работает не только на периметре: сверь номер телефона, пробей фото через обратный поиск, проверь электронную почту.

Доверяй, но проверяй. Сначала в карантинный VLAN, потом в доверенную сеть — okosearch.com

🎇Главная идея DevSecOps: безопасность перестаёт тормозить разработку.

Вместо проверок «после релиза» всё встроено в пайплайн: код проходит SAST, контейнеры сканируются, инфраструктура проверяется на комплайенс. В итоге релизы выходят быстрее и при этом безопаснее.

Этому и учит курс DevSecOps от Академии Codeby на практике:

⏺️9 модулей, 48 занятий, 90% практики
⏺️Стек: Docker, Kubernetes, Terraform, Vault, Ansible, Prometheus
⏺️Финальный экзамен в стиле OSCP — только реальные задачи
⏺️Авторы — практики: внедрение Zero Trust, построение SOC, разработка DevSec-инструментов под Burp Suite

Инженеры, которые умеют встраивать безопасность в CI/CD, сегодня в дефиците на стыке ИБ и DevOps — компании поняли, что «сначала сделать, потом чинить» обходится дороже.

👉 Старт курса 5 октября

➡️️️Программа и регистрация

Бесплатная консультация — @CodebyAcademyBot

22 октября встречаемся в Москве: Kuber Conf уже совсем скоро!

Что будет на конференции:
– доклады про эксплуатацию Kubernetes, observability, AI и облачную инфраструктуру;
– обсуждение Service Mesh, безопасности и экономики платформ;
– темы про bare metal, железо и инфраструктуру ЦОДов;
– активности партнеров и общение с участниками.

В программе — практические кейсы и темы, которые помогут посмотреть на инфраструктуру с разных сторон: от управления кластером с помощью AI-агента и доставки системного софта в managed K8s до мультитенантности в Kubernetes-платформе.

А еще обсудим спорные вопросы индустрии: действительно ли Kubernetes — король оркестраторов, подходит ли он для всех инфраструктурных задач и как изменится наша работа в мире, где ИИ всё активнее берет на себя привычные задачи?

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

📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 10:00–21:00

👉 Программа, билеты и подробности — на сайте Kuber Conf от АОТ

🥸 OWASP Agentic Skills Top 10: критические уязвимости при работе с агентами

Свежак от OWASP (~66 стр., август 2026) — про security agentic skills: SKILL.md, ClawHub/skills.sh и весь этот зоопарк, который агенты тащат к себе в контекст.

ТОП-10 рисков:
• Malicious Skills — зловред под видом легитимного скилла (см. кейс ClawHavoc, 1000+ вредоносных скиллов с общим C2);
• Supply Chain Compromise — реестры без нормальной проверки происхождения;
• Over-Privileged Skills — скиллу для прогноза погоды выдают доступ ко всем API-ключам разом;
• Insecure Metadata — YAML/JSON-фронтматтер как рабочий вектор атаки, а не просто описание;
• Untrusted External Instructions — агент тянет внешний URL и слепо исполняет как инструкцию;
• Weak Isolation — скилл живёт в том же контексте, что и хост-агент, песочниц нет;
• Update Drift — обновления без пиннинга и подписи, «патч» может завезти новый пейлоад;
• Poor Scanning — сканеры ловят curl в скрипте, но не ловят то же самое, сказанное прозой;
• No Governance — никто не считает, кто что установил и с какими правами;
• Cross-Platform Reuse — манифест с ограничениями теряется при переносе между площадками.

По каждому пункту — описание, пруфы из реальных инцидентов, сценарии атак и митигации. Годнота для всех, кто уже тащит агентов в прод.

Технологический радар и принятие изменений

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

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

А как у вас происходит выбор применяемых технологий? и кто уже что для себя решил чем заменить minio?

🥷 Джонни вещает: проброс авторизации

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

🆘 Для понимания ситуации, пример ниже будет ссылаться на вот эту схему (click)

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам.

— Компромиссным вариантом было бы иметь «другой» SSH-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

⚙️ SSH предлагает возможность форварда SSH-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так: ssh -A user@8.8.8.8 ssh user2@10.1.1.2

Удалённый SSH-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали SSH-клиенту доступ к своему агенту авторизации (но не ключу!).

#SSH #Authorization | 😊 @iscode

🥷 Джонни вещает: 8 популярных сетевых протоколов с наглядным объяснением

Сетевые протоколы работают на разных уровнях модели OSI, это важно знать.

🌜 Эта многоуровневая архитектура обеспечивает стандартизированное взаимодействие между различными программными и аппаратными компонентами в сети.

1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке.

2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям.

3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами.

4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети.

5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке.

6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами.

7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети.

- Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания 📠

#Protocol #cheatsheet | 😊 @iscode

Обычный день с СДВГ

#meme | 😊 @iscode

🥷 Джонни вещает: реверс сокс-прокси

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

🆘 Для понимания ситуации, пример ниже будет ссылаться на вот эту схему (click)

ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

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

📠 Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

#Socks #Proxy

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

— Основная задача показать пример организациям для подготовки своих аналогичных решений.

🥷 Смена парадигм: удивительные тренды анонимности и безопасности в 2026

2026 год по правде можно назвать переходящим в новую эру, эру опасных технологий, где понятия анонимности и безопасности выходят далеко за рамки паролей, шифрования и смены IP-адреса. Например, DeepFake превратился в настоящую фабрику цифровых личностей: теперь анонимность означает создание такого цифрового двойника, который без проблем пройдёт видео/голос проверку.

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

Но одними лишь дипфейками дело не ограничивается. Умение правильно прятать криптоактивы стало базой. С 20 февраля 2026 года криптовалюта официально признана имуществом № 38-ФЗ, и следователь теперь может изъять холодный кошелёк, а затем перевести средства на государственный счёт. В этих условиях необходимы продуманная легенда с убедительным отрицанием, тайники на устройствах, duress-пароль на случай принуждения, методы форензики и надёжные бэкапы. Хорошая новость в том, что всему этому реально научиться.

😎 Наконец, всё большее распространение получает концепция активной защиты — атака вместо обороны. Вместо того чтобы просто защищаться и прятаться, можно незаметно вычислить злоумышленника и нанести ответный удар. Среди популярных приёмов — ZIP-бомбы, когда крошечный файл в 42 мегабайта превращается в 4,5 терабайта и выводит из строя сканер на машине атакующего; выставление фальшивых открытых портов, чтобы nmap злоумышленника показывал ложную картину; а также цифровые «канарейки», которые предупредят о любом скрытом доступе к устройству — будь то хакер или кто-то из домашних.

— CyberYozh Academy помогает освоить все эти навыки “под ключ” вместе с ведущими экспертами рынка. Академия работает с 2014 года и считается одной из самых авторитетных в сфере кибербезопасности. Переходите по ссылке, чтобы узнать подробности, или пишите менеджеру для анонимной заявки на обучение.

⤷ Ссылка на источник

#Trends #CyberYozh | ✋ @iscode

😈 Лёгший эквайринг и цензор: РКН потребовал удалить «ложную» информацию

Роскомнадзор потребовал удалить ложную информацию о том, что эквайринг во всей стране прилёг из-за блокировок IP-адресов, действительно, что-ж все собак спустили на прекрасную службу по надзору связи, совпадение, не более.

— И вообще, не стоит доверять всяким TG-каналам, сплошные фейки, вся достоверная информация только в MAX 🙂

🥷 4 YouTube-канала для системного администратора

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

1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети.

2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы.

🕹 Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе.

3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN]

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

админ вернулся с работы, лайк посту поставьте братва и посты чаще начнут выходить 🌟

Telegram в России ЗАБЛОКИРОВАН на ~80% — пишут СМИ.

В отдельных федеральных округах цифра близится к
90%.

в этом даже есть плюс, отсортируют действительно заинтересованных лиц в свободном, НЕ цензурированом интернете.

👮‍♀️ Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2 (цветет и пахнет, пинг минимальный 200-300ms)

🥷 Как работает DNS в Linux. Часть 3: кто на самом деле управляет resolv.conf?

Мы уже знаем, как dhclient и resolvconf пишут настройки DNS. Но что происходит, когда в игру вступают тяжеловесы вроде NetworkManager, systemd-resolved, отдельно стоящий unbound или корпоративный BIND? А если сверху это всё приправлено облачной инициализацией cloud-init и абстракцией netplan? Файл /etc/resolv.conf может вести себя непредсказуемо.

🔍 systemd-resolved — это локальный кэширующий dns-сервер (systemd-networkd), процесс systemd-resolved слушает 127.0.0.53:53, и nameserver в resolv.conf указывает на 127.0.0.53 соответственно. Файл /etc/resolv.conf обычно является symlink на /run/systemd/resolve/stub-resolv.conf

В свою очередь /run/systemd/resolve/stub-resolv.conf — содержит 127.0.0.53, а прямой список upstream DNS можно найти в файле /run/systemd/resolve/resolv.conf.

Диагностика:

# Основная информация о состоянии
resolvectl status
# Статистика запросов
resolvectl statistics
# Информация по конкретному интерфейсу
resolvectl status eth0

🖥 dnsmasq — это простой DHCP/DNS сервер, который работает зачастую как локальный кэш на 127.0.0.1:53. Обычно dnsmasq не пишет в resolv.conf самостоятельно, а читает upstream из resolv.conf, использует директиву --server= при запуске, или сервера прописаны в конфигурационном файле /etc/dnsmasq.conf.

Диагностика:

# Перезагрузка конфигурации
sudo kill -USR1 $(pidof dnsmasq)
# Проверка параметров запуска
ps aux | grep dnsmasq

🕹 NetworkManager — это инструмент для автоматической настройки сети в большинстве современных десктопных и серверных дистрибутивах Linux. Был разработан компанией Red Hat в 2004 году для упрощения современных сетевых задач. Взаимодействие с ним настолько “упрощает” работу с сетью, что очень многие системные администраторы отключают его сразу.

— Обычно NetworkManager получает настройки от DHCP (через внутренний DHCP-плагин или внешний dhclient), принимая DNS-серверы из DHCP-ответа (опция option domain-name-servers), и передает их в системную службу управления DNS.

Поведение при обработке DHCP DNS можно контролировать через параметр ipv4.ignore-auto-dns:

ipv4.ignore-auto-dns=no (по умолчанию) - NM использует DNS-серверы, полученные от DHCP
ipv4.ignore-auto-dns=yes - игнорировать DNS от DHCP и использовать только статически заданные серверы

Сам NetworkManager не обрабатывает DNS-запросы и не слушает порт 53, а в зависимости от настроек запускает dnsmasq (который слушает 127.0.0.1:53) или взаимодействует с systemd-resolved (обычно слушает 127.0.0.53:53).

Что запускается - зависит от параметра dns в /etc/NetworkManager/NetworkManager.conf:

dns=systemd-resolved — используется только systemd-resolved.
dns=dnsmasq — запускается dnsmasq через NetworkManager.
dns=none — NetworkManager не берет на себя функции управления резолвингом DNS
dns=default — NetworkManager сам решает, что делать.

При взаимодействии с systemd-resolved NetworkManager выступает в роли менеджера конфигурации, передавая параметры DNS через D-Bus API systemd-resolved, но не участвуя в обработке DNS-запросов напрямую.

Тогда у нас будет наблюдаться следующая картина:
resolvectl status # отображает текущие DNS-серверы, которые systemd-resolved получил от NetworkManager
nmcli dev show | grep DNS # показывает DNS-серверы, которые NetworkManager передал в systemd-resolved

🔍 dhclient — стандартный DHCP-клиент в Linux-системах, входящий в пакет ISC DHCP. Его основная задача автоматически получать настройки сети (IP-адрес, сетевую маску, шлюз, DNS-сервера) у DHCP-сервера и применять их локально.

По умолчанию DHCP-клиент (программа /sbin/dhclient) не изменяет /etc/resolv.conf напрямую. Вместо этого вызывается вспомогательный скрипт /sbin/dhclient-script, который получает параметры (в том числе DNS-серверы) от DHCP-сервера.
— Внутри dhclient-script есть функция make_resolv_conf(), которая формирует содержимое файла /etc/resolv.conf и записывает новые настройки DNS.
Кроме того используются так называемые хуки (скрипты), которые лежат в каталогах /etc/dhcp/dhclient-exit-hooks.d/ или /etc/dhcp/dhclient-enter-hooks.d/. Они позволяют изменить логику формирования или перезаписи /etc/resolv.conf, переопределяя функции или добавляя свои параметры.

Диагностика:

# Проверить конфигурацию DHCP-клиента
cat /etc/dhcp/dhclient.conf
# Запустить dhclient в debug-режиме
dhclient -v -d <интерфейс> # выведет подробный лог, включая обработку DNS).
# Проверить lease-файл DHCP**
cat /var/lib/dhcp/dhclient.leases # там хранятся полученные параметры, включая DNS-серверы

🖥 resolvconf — это устаревший, но иногда встречающийся служебный инструмент для централизованного управления содержимым файла /etc/resolv.conf в UNIX-подобных системах. Он сохраняет и обновляет /etc/resolv.conf, собирая настройки DNS с различных источников: DHCP-клиентов, VPN-клиентов, сетевых интерфейсов, NetworkManager, позволяет нескольким программам и сервисам вносить свои DNS-серверы, динамически формируя итоговый конфиг для системы.

— Работает как демон или в виде набора скриптов-хуков, которые вызываются при изменении сетевой конфигурации, принимает входящие DNS-настройки через программу или скриптовые вызовы, обновляет кэш и генерирует конечный /etc/resolv.conf.

В resolvconf используются шаблоны для формирования итогового файла DNS:
- /etc/resolvconf/resolv.conf.d/head — вставляется в начало результата.
- /etc/resolvconf/resolv.conf.d/base — база доменов и серверов.
- /etc/resolvconf/resolv.conf.d/tail — добавляется в конец.

resolvconf может использоваться другими службами (например, NetworkManager, dhclient, openvpn) для централизованного обновления DNS-конфига.

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

Диагностика:

# Вывод актуальной информации
resolvconf -l
# Обновить /etc/resolv.conf
resolvconf -u

В следующем посте продолжим навигацию по этому лабиринту: разберёмся, как systemd-resolved, dnsmasq, NetworkManager, unbound, BIND, cloud-init и netplan управляют /etc/resolv.conf, в каких случаях они конфликтуют, а когда — работают сообща, и какие рычаги у нас остаются над DNS. Ставьте 👍

#DNS #Linux | 🙁 @iscode

🥷 Как работает DNS в Linux. Часть 3: кто на самом деле управляет resolv.conf?

Когда-то давным-давно в далекой Галактике DNS настраивался простым редактированием /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com

Сейчас же файл с содержанием nameserver 127.0.0.53 и предупреждением “DO NOT EDIT” может шокировать. Причина такого изменения в эволюции DNS-инфраструктуры:

Раньше: приложения → resolv.conf → DNS-сервер

Сейчас: приложения → локальный DNS-прокси → upstream серверы

В современных дистрибутивах /etc/resolv.conf – это чаще всего не ручная настройка, а автоматически генерируемый конфиг, создаваемый и поддерживаемый системными компонентами: systemd-resolved, NetworkManager, resolvconf или их аналогами вроде openresolv. Эта автоматизация приносит гибкость (разные DNS для разных сетей, DNSSEC, LLMNR/mDNS), но с другой стороны и некоторые потенциальные проблемы:

• Настройки могут слетать после перезагрузки сети или обновления пакетов.
• Конфликты при подключении VPN, которые пытаются переписать DNS.
• Сложности с использованием локальных доменов или специфичных DNS-серверов.
• Затрудненная отладка: куда на самом деле идут запросы?

Так кто же главный? systemd-resolved? NetworkManager? Как вернуть себе контроль?

В следующем посте разберёмся в этом лабиринте: какие инструменты претендуют на управление /etc/resolv.conf, как они взаимодействуют и какие рычаги управления у нас есть, чтобы заставить DNS работать так, как нам нужно. Ставьте 👍

#DNS #Linux | 🙁 @iscode

🥷 Как работает DNS в Linux. Часть 3: разбираемся с resolv.conf, systemd-resolved, NetworkManager и другими

Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике.

Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS:

• почему одинаковые запросы дают разные IP
• как реально контролируется разрешение имен: что вызывает кого и зачем
• как проводить диагностику: strace, resolvectl, tcpdump

🖥 Утилиты и их пути к DNS
В Linux-системах преобразование доменных имён в IP-адреса — фундаментальный процесс, но не все утилиты делают это одинаково. Под капотом скрываются конкурирующие механизмы: классический стек glibc/NSS (с его правилами из /etc/nsswitch.conf, локальным файлом /etc/hosts и кеширующими сервисами, такими как systemd-resolved), прямые DNS-запросы (игнорирующие системные настройки) и альтернативные библиотеки (например, c-ares). Эти различия часто становятся источником неочевидных расхождений в работе инструментов, особенно при диагностике сетевых проблем.

‼️ Типичный пример — разница в выводе getent hosts и dig для одного домена:

$ getent hosts google.com
142.250.179.206 google.com
$ dig +short google.com
142.250.179.238

Здесь getent опирается на кеш systemd-resolved (через NSS), а dig обходит системные механизмы, запрашивая DNS-сервер напрямую.

Практические советы:

• Если ping и curl выдают разные IP, причина обычно в кеше NSS или настройках /etc/hosts.

При работе с curl/wget учитывайте их зависимость от libc: расхождения могут указывать на проблемы в NSS (например, некорректный nsswitch.conf).

• Для проверки системного разрешения (включая /etc/hosts) используйте getent, host или ping.
• Для валидации работы DNS-сервера применяйте dig/nslookup — они не смотрят в локальные файлы.

Итог: понимание внутренних механизмов разрешения имён критично при отладке сетевых проблем. Всегда сверяйтесь с таблицей выше, чтобы выбрать правильный инструмент: проверка локальных настроек требует NSS-зависимых утилит, а диагностика DNS — "прямых" запросов в обход системы.

#DNS #Linux | 🙁 @iscode