Серверная Админа | Компьютерные сети

🎇Главная идея DevSecOps: безопасность перестаёт тормозить разработку. Вместо проверок «после релиза» всё встроено в пайплайн: код проходит SAST, контейнеры сканируются, инфраструктура проверяется на комплайенс. В итоге релизы выходят быстрее и при этом безопаснее. Этому и учит курс DevSecOps от Академии Codeby на практике: ⏺️9 модулей, 48 занятий, 90% практики ⏺️Стек: Docker, Kubernetes, Terraform, Vault, Ansible, Prometheus ⏺️Финальный экзамен в стиле OSCP — только реальные задачи ⏺️Авторы — практики: внедрение Zero Trust, построение SOC, разработка DevSec-инструментов под Burp Suite Инженеры, которые умеют встраивать безопасность в CI/CD, сегодня в дефиците на стыке ИБ и DevOps — компании поняли, что «сначала сделать, потом чинить» обходится дороже. 👉 Успейте записаться на текущий поток до 15 октября ➡️️️Программа и регистрация Бесплатная консультация — @CodebyAcademyBot

👋 Привет, сетевой друг! Сегодня разберём recursive routing на MikroTik - настроим переключение между двумя провайдерами так, чтобы роутер проверял не только шлюз, но и доступность интернета за ним. 🟣Сценарий: основной WAN работает через 192.168.1.1, резервный - через 192.168.2.1. Если проверять только gateway: check-gateway=ping роутер увидит 192.168.1.1 и решит, что маршрут исправен. Даже если у самого провайдера дальше уже ничего не работает. Поэтому проверять будем внешний адрес, например 1.1.1.1. 🟣Сначала создаём маршрут до контрольного IP через основного провайдера: /ip route add dst-address=1.1.1.1/32 gateway=192.168.1.1 scope=10 Теперь 1.1.1.1 доступен только через первый WAN. Создаём default route, но в качестве gateway указываем уже контрольный адрес: /ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 \ distance=1 check-gateway=ping target-scope=11 RouterOS сначала рекурсивно ищет, как добраться до 1.1.1.1, и находит маршрут через 192.168.1.1. 🟣Для резервного WAN делаем то же самое с другим контрольным адресом: /ip route add dst-address=8.8.8.8/32 gateway=192.168.2.1 scope=10 add dst-address=0.0.0.0/0 gateway=8.8.8.8 \ distance=2 check-gateway=ping target-scope=11 distance=2 делает этот маршрут резервным. Пока 1.1.1.1 отвечает через первого провайдера, используется основной WAN. Если проверка перестаёт проходить, маршрут становится неактивным и RouterOS выбирает второй default route. 🟣Посмотреть, какой маршрут сейчас активен: /ip route print detail where dst-address=0.0.0.0/0 Получается такая схема: 1.1.1.1 → WAN1 → distance 1 8.8.8.8 → WAN2 → distance 2 ↓ default route 🟣Можно пойти ещё дальше и не завязывать состояние WAN на один контрольный IP. Для каждого провайдера создают несколько probe-маршрутов, например до 1.1.1.1 и 8.8.8.8, чтобы отказ одного публичного адреса сам по себе не переключал весь канал. Серверная Админа | Zeroday | #Mikrotik

🗂 Пакет Безопасности — папка, которую админ собирал более 10 лет ⚡️ Слитые курсы по IT и ИБ ⚡️ Сервисы и тулзы для приватности ⚡️ Инструкции и шпаргалки ⚡️ Редкие книги и утилиты ⚡️ Гайды написанные автором Большинство собирает такую базу годами. Здесь все отсортировали и разбили в одном канале ссылка действует 48 часов 📌 Подписывайся: @package_security

👋 Привет, сетевой друг! Сегодня про Network Doctor - TUI для диагностики сети, который пытается не просто показать пачку вывода от ping, dig и curl, а найти место, где именно ломается соединение. 🟣Запускаете: netdoc github.com И инструмент последовательно проверяет DNS, TCP, TLS и HTTP, связывая результаты между собой. Если DNS не работает, зависимые проверки не запускаются, а итог прямо говорит, что проблема в разрешении имени. То есть вместо: ping - не работает curl - не работает получаете примерно: DNS: FAIL TCP: SKIP TLS: SKIP HTTP: SKIP Diagnosis: target hostname does not resolve 🟣При этом проверки разбиты на независимые ветки. Отдельно проверяются локальный интерфейс и Wi-Fi, выход в интернет, QUIC/UDP 443, DNS, DoH/DoT, proxy и путь до конкретного сервиса. Можно проверить даже порт: netdoc github.com:22 Тогда вместо HTTP-проверок появится SSH banner check. 🟣Интересная часть - Path MTU. Network Doctor умеет искать проблемы с MTU без root-доступа и обычного ICMP-пинга. Это полезно для случаев, когда соединение вроде бы устанавливается, но определённые пакеты по пути начинают теряться. 🟣Если проблема плавающая, есть Watch Mode: netdoc --watch host Он повторяет проверки и сохраняет небольшую историю инцидента: что работало до сбоя, где появилась проблема и когда всё восстановилось. А для автоматизации есть JSON: netdoc --json host и стабильные exit codes, поэтому результат можно использовать уже в скриптах и мониторинге. 🟣Ещё можно сохранить диагностику: netdoc --save failure.ndoc host netdoc --support support.ndoc host А потом сравнить хороший и плохой запуск: netdoc --compare good.ndoc bad.ndoc Причём сравнение сохранённых отчётов не требует нового сетевого подключения. 🟣Сам Network Doctor написан на Go и работает на Linux, macOS и Windows. Внутри TUI используется Bubble Tea, а если одной встроенной проверки мало, прямо из интерфейса можно запустить привычные route, ss, ping, DNS, curl, traceroute, mtr или nmap. Получается не очередной «ping с красивым интерфейсом», а попытка разложить сетевую проблему по слоям и сразу связать результат с конкретной причиной. Серверная Админа | Zeroday | #Инструмент

Как хаотичные подсети убивают масштабируемость В статье показывают, как случайные /24, пересекающиеся диапазоны и адресация «как получилось» годами копят проблемы, а потом взрываются при росте или слиянии компаний. Разбирают, почему двойной NAT не спасает, и как нормальная иерархия адресов помогает не превращать расширение сети в многонедельный квест. Серверная Админа | Zeroday | #Статья

👋 Привет, сетевой друг! Ещё три функции MikroTik, которые легко пропустить, пока не столкнёшься с конкретной задачей. 🟣Connection Tracking Helpers - когда роутер понимает протокол RouterOS умеет подключать helpers для некоторых протоколов, где одного IP/порта недостаточно, чтобы нормально отслеживать соединения. Например, FTP может открывать дополнительные соединения для передачи данных. Helper анализирует управляющий канал и помогает connection tracking понять, какой трафик относится к этой сессии. Проверить helpers: /ip/firewall/service-port/print А ненужные можно отключить: /ip/firewall/service-port/set ftp disabled=yes 🟣Torch - посмотреть трафик прямо на интерфейсе: Когда нужно быстро понять, кто и куда ходит, не обязательно сразу запускать Wireshark. /tool/torch interface=ether1 Можно фильтровать по IP, порту, протоколу и направлению. Например, быстро найти, кто забивает uplink или куда конкретно уходит трафик. 🟣Packet Sniffer умеет отдавать трафик прямо в Wireshark: На MikroTik можно захватить пакеты и открыть их в Wireshark: /tool/sniffer set filter-interface=ether1 \ filter-ip-address=10.0.0.10/32 \ file-name=capture.pcap start После остановки получаете обычный PCAP: /tool/sniffer/stop Это удобно, когда проблема происходит на самом роутере: SYN приходит, ответ уходит, но дальше что-то теряется. Серверная Админа | Бункер Хакера | #Mikrotik

Для тех, кто работает с Kubernetes и облачной инфраструктурой, в октябре намечается отличный повод выбраться из рабочих чатов и встретиться офлайн 👀 Обсудим: – как пройти путь от бизнес-требования к ядру Linux – как дать агенту управление кластером вашей инфраструктуры  – как в MWS Cloud Platform доставляют системный софт в managed K8s – мультитенантность в Kubernetes-платформе — «Проект вместо namespace» – как работает LLM-диагностика инцидентов в Kubernetes и OpenStack Не обойдётся и без дискуссий: на круглых столах разберём, действительно ли Kubernetes победил и что делать, если из-за ИИ нас всех уволят. В течение дня вас ждут доклады, общение с коллегами и активности от партнеров. Будет возможность обсудить кейсы, обменяться опытом и познакомиться с коллегами из индустрии. После конференции вас ждет афтепати, где можно будет пообщаться с единомышленниками в более неформальной обстановке. 📍 Москва, 5-й Донской проезд, 17, Connect 📅 22 октября, 10:00–21:00 👉 Программу, билеты и подробности сможете найти на сайте Kuber Conf от АОТ!

👋 Привет, сетевой друг! Сегодня про UUCP - протокол и набор утилит, через которые Unix-машины десятилетиями обменивались файлами, почтой и командами задолго до привычного нам интернета. 🟣Название расшифровывается как Unix-to-Unix Copy. Изначально идея была максимально простой: одна машина звонит другой по модему, устанавливает соединение и передаёт задания. Никаких постоянных TCP-соединений. Машины могли вообще не быть одновременно онлайн. 🟣Например, сервер A хотел отправить файл серверу B. UUCP складывал задание в очередь: A ├── файл ├── адрес получателя └── команда на обработку Когда наступало время связи, машина дозванивалась до B, передавала накопившиеся задания и забирала то, что накопилось в обратную сторону. 🟣Из этого выросла довольно интересная схема маршрутизации. Если A не мог напрямую связаться с C, файл можно было отправить через B: A → B → C Узлы образовывали цепочки, а сообщения могли проходить через несколько промежуточных машин. 🟣UUCP использовали не только для файлов. Через него пересылали электронную почту, новости Usenet и удалённые команды. Особенно это подходило для дорогих dial-up соединений: связь поднималась только тогда, когда действительно появлялись данные для передачи. 🟣Сегодня идея выглядит архаично, но концепция никуда не делась. Очередь заданий, store-and-forward и передача при появлении связи всё ещё используются там, где постоянное соединение невозможно или слишком дорого. Просто вместо пары Unix-серверов с модемами теперь это могут быть устройства с нестабильным спутниковым каналом, IoT и системы в удалённых местах. Серверная Админа | #XMODEM

👋 Привет, сетевой друг! Давай разберём несколько TCP-флагов и состояний, которые особенно полезны, когда смотришь трафик в Wireshark и пытаешься понять, где именно всё сломалось. 🟣SYN без SYN-ACK Клиент отправляет Client → Server SYN Client → Server SYN Client → Server SYN а ответа нет. Это ещё не значит «сервер лежит». SYN мог потеряться, его мог отбросить файрвол, либо обратный маршрут сломан. Поэтому следующий шаг - смотреть, доходят ли пакеты до сервера и есть ли от него ответ. 🟣SYN-ACK приходит, но клиент отвечает RST: Здесь картина уже интереснее: Client → Server SYN Server → Client SYN-ACK Client → Server RST Сервер явно ответил, но клиент сразу сбросил соединение. Такое бывает, например, когда клиентский стек уже не ожидает этот ответ или состояние соединения исчезло из-за NAT/stateful firewall. 🟣RST вместо SYN-ACK Client → Server SYN Server → Client RST TCP-порт на той стороне явно отверг попытку соединения. Классический случай - приложение не слушает этот порт. Но RST может генерироваться и сетевым оборудованием или security-механизмом, поэтому источник пакета тоже стоит проверить. 🟣FIN и RST - совсем разные истории FIN означает: «я закончил отправлять данные». RST означает: «эту TCP-сессию прекращаем прямо сейчас». Например, нормальное закрытие выглядит примерно так: Client → Server FIN Server → Client ACK Server → Client FIN Client → Server ACK А RST посреди нормального обмена уже требует посмотреть, что происходило непосредственно перед ним. 🟣ACK с неожиданным номером: TCP подтверждает не отдельные пакеты, а последовательность байтов. Например: SEQ=1000 LEN=500 ACK=1500 Если сервер продолжает получать ACK=1000, хотя уже отправил данные дальше, можно увидеть retransmission, duplicate ACK и проблемы с доставкой. Именно по комбинации SEQ, ACK, SYN, FIN, RST и времени между пакетами часто можно восстановить всю историю TCP-сессии - кто начал соединение, где потерялся пакет и на каком этапе оно развалилось. Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг! Сегодня про webcensus - инструмент для довольно специфичной задачи: найти один и тот же URL-путь сразу на огромном количестве сайтов. 🟣Например, хочется понять, кто вообще публикует /.well-known/security.txt, robots.txt, ads.txt или sitemap.xml. Перебирать сайты по одному здесь явно не вариант. 🟣webcensus собирает это в конвейер из нескольких этапов: список доменов ↓ DNS ↓ HTTPS probe ↓ скачивание ↓ проверка файла Сначала massdns быстро резолвит миллионы доменов и оставляет только те, у которых есть A-запись. 🟣Дальше в дело вступает собственный Rust-пробер skim. Он подключается к :443, выполняет TLS handshake и отправляет обычный HTTP-запрос к нужному пути. Но самое интересное - тело ответа на этом этапе вообще не скачивается. Инструмент читает только HTTP status line: {"url":"https://example.com/.well-known/security.txt","status":"success","code":200,"cert_ok":true} Поэтому из миллионов адресов дальше проходят только те, где HTTPS вообще поднялся и нужный путь вернул 200. 🟣И только теперь начинается полноценная загрузка. curl --parallel скачивает найденные URL пачками, причём для каждого запроса есть ограничения по размеру, времени и числу повторных попыток. Например: --parallel-max 50 --max-filesize 5M --max-time 10 --connect-timeout 3 --retry 2 Это важно, потому что сервер вполне может ответить 200, а вместо маленького security.txt отдать несколько мегабайт HTML. 🟣После скачивания webcensus ещё раз проверяет содержимое уже локально. HTML-страницы, JSON-ошибки, бинарный мусор и слишком короткие ответы отбрасываются. Получается важная разница: HTTP 200 ≠ нужный файл действительно существует Например, сайт может отдавать одну и ту же SPA-страницу на любой URL с кодом 200. Для простого сканера это найденный файл, для webcensus - мусор. 🟣Весь процесс запускается внутри Docker, а каждый этап оставляет результат в data/. Можно остановиться после любого шага и продолжить с него, а локальный этап проверки вообще не требует повторно ходить в интернет. Серверная Админа | Zeroday | #Инструмент