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

Вышел свежий квартальный отчет CURATOR DDoS-атаках и других киберугрозах. Несколько цифр, которые кажутся самыми показательными: ☮️13,5 млн → 2,09 млн — крупнейший ботнет квартала сократился почти в шесть раз. ☮️12 — столько DDoS-атак мощностью свыше 1 Тбит/с зафиксировано всего за три месяца. ☮️16,92% — индекс ботовости в EdTech при среднем по рынку 1,56%. ☮️−34% — настолько снизилось число BGP-перехватов год к году. ☮️180 000 — вредоносных запросов в секунду достигла бот-атака на одну из медиакомпаний. ↕️Главный вывод отчета: угрозы становятся не просто мощнее, а сложнее — меняются их масштаб, цели и механики. 🔁Полную версию отчета с разбором ключевых тенденций ищите в Telegram-канале CURATOR.

Технологический радар и принятие изменений Когда вы уже достаточно выросли из штанишек и компания насчитывает большое количество продуктов и команд, наступает момент когда пора останавливать внедрение новых технологий на "просто потому что". Каждая крупная технология должна пройти через оценку ее применения в компании, рассматриваться с разных сторон и разными людьми, которые работают в не связанных друг с другом командах и имеют абсолютно разный опыт работы с технологией. Так мы можем обоснованно принять какую-то технологию в технологический радар и получить максимальную унификацию. В иллюстрации пример выбора замены 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)

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

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

🥷 Как работает 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

🥷 Как работает DNS в Linux. Часть 2: мониторинг в среде Kubernetes Эффективная работа DNS критична для производительности кластера Kubernetes. CoreDNS, как стандартный резолвер, генерирует метрики, которые помогают выявлять: — эффективность кэширования (снижает ли нагрузку на upstream); — ошибки разрешения имен (например, всплески NXDOMAIN); — аномальные задержки (проблемы с сетью или перегрузку). Собирая эти данные через Prometheus, вы можете настроить алертинг и предотвратить сбои до их влияния на приложения. Примеры метрик: - Эффективность кэша: sum(rate(coredns_cache_hits_total{type="success"}[5m])) / sum(rate(coredns_cache_requests_total[5m])) - Отслеживание ошибок: rate(coredns_dns_responses_total{rcode="NXDOMAIN"}[5m]) - Задержки запросов: histogram_quantile(0.99, rate(coredns_dns_request_duration_seconds_bucket[5m])) Примеры алертов - Рост ошибок NXDOMAIN: rate(coredns_dns_responses_total{rcode="NXDOMAIN"}[5m]) > 10 - Деградация скорости ответа: histogram_quantile(0.99, rate(coredns_dns_request_duration_seconds_bucket[5m])) > 1 - Снижение эффективности: rate(coredns_cache_misses_total[15m]) / rate(coredns_cache_requests_total[15m]) > 0.5 Проактивные практики: — Автоматизируйте алерты на аномальный рост NXDOMAIN-ответов. — Контролируйте сроки жизни DNS-записей (TTL), чтобы избежать использования устаревших данных. — Визуализируйте hit/miss ratio для контроля эффективности кэширования.

🥷 Как работает DNS в Linux. Часть 2: как правильно управлять кэшем Немного практических советов по работе с кэшами. В разработке: 1. Использовать короткие TTL для тестовых доменов (60-120 секунд). Для негативных ответов (NXDOMAIN) устанавливайте ещё меньший TTL (5-30 сек) в конфигурации резолверов (например, cache_neg_ttl в dnsmasq), чтобы быстро тестировать исправления. 2. Знать, как сбросить кэш на каждом используемом уровне. 3. Тестировать изменения DNS в изолированной среде. В production: 1. Планировать изменения DNS: снижать TTL заранее. 2. Мониторить кэширование: логировать stale answers и NXDOMAIN. 3. Использовать централизованные резолверы с контролируемым кэшированием. 4. Настроить правильные TTL: - Для часто меняющихся сервисов: 60-300 секунд. - Для статичных данных: 3600+ секунд. Эффективное управление DNS в продакшене требует непрерывного контроля кэша. Ключевые метрики: hit rate (эффективность кэша), stale answers (устаревшие ответы), NXDOMAIN rate (ошибки резолвинга) и latency (задержка). #DNS #Linux #Cache | 🙁 @iscode

😢 Насколько утечки 🔼 бустят эффективность фишинга Речь пойдёт о целевых атаках, не буду говорить о массовых фишинговых письмах, на подобии наследства с Африки, ибо не эффективно, лидов нет. А вот когда у тебя на руках персональные данные сотрудников и правильно воспользовавшись можно превратить обычный спам в целевую атаку: ❗️ Допустим, в сеть утекли заказы из некоторого сервиса еды. Из них злоумышленник может узнать: · корпоративный адрес сотрудника, который заказывает еду в офис, его имя и фамилию; · когда происходит заказ — например, до обеда в пятницу; · что заказывают — пиццу, бургеры, вок и т. д.; · телефон того, кто встречает курьера; · сколько было заказов, какая регулярность После чего желательно в пятницу утром высылается письмо на адрес жерты: Добрый день, Афанасий Валерьянович! Спасибо, что являетесь клиентом нашей пиццерии. Мы благодарны вам и дарим купон на скидку 20%. Работает только сегодня, автоматически применится при заказе по ссылке: <фишинговая ссылка> С уважением, пиццерия Мама Вонс. Эффективность фишинга с применением персональных данных повышается в разы, в 51% случаев сотрудники открывают, и 40% из этого числа взаимодействует с сервисом, так что, будьте аккуратней и информируйте сотрудников. #Phishing #Dataleaks | 🙁 @iscode

🥷 4 YouTube-канала для системного администратора По просьбе одного из подписчиков, а точнее Alexander S выложить YT авторов по нашему направлению, что-ж, тема отличная, не знаю почему раньше этим не занялся, так как в любой связанной с айтишкой профессии, в системном администрировании специалисту требуется постоянное обучение, без которого нельзя развить необходимые навыки и наработать опыт. 1. Andrey Sozykin — на канале доступны видеолекции, подготовленные автором на основе этих курсов. Информация подается в краткой форме без затрудняющих восприятие деталей. Автор подробно разбирает следующие темы: компьютерные сети, защищенные сетевые протоколы, SQL, Python и нейросети. 2. Вера Дроздова — роликов немного, но они оформлены в виде лекций и хорошо продуманы. 🕹 Объясняются следующие темы: введение в компьютерные сети, сети ЭВМ и телекоммуникации, беспроводные технологии и компьютерные сети, сетевые технологии – все как в универе. 3. tutoriaLinux — автор профессиональный системный администратор, веб-разработчик, безопасник и архитектор датацентров с более чем десятилетним опытом. Обсуждаются следующие темы: получение первой работы, команды Linux, SRE, GIT, сети, VPN, оболочки и масса прочего. Также здесь можно найти интересные интервью.[EN] 4. ExtremeCode — и замыкающий автор в нашем списке это ExtremeCode, первые три автора это скучная техническая часть, а этот автор поможет скрасить вечера или послеобеденные будни в офисе) админ вернулся с попойки, лайк посту поставьте братва и посты чаще начнут выходить 🌟