📝 ICMP Type/Code: что скрывается за “ping не проходит”

👋 Привет, сетевой друг!

ICMP все знают как «пинг», но на самом деле это целый набор сообщений с разными Type и Code, каждое из которых говорит конкретную вещь.

🟣Type 0 и 8 - Echo Reply и Echo Request. Это то, что обычно называют ping. Клиент шлёт Type 8, живой хост отвечает Type 0. Если ответа нет, это ещё не значит что хост мёртв — многие фаерволы просто дропают ICMP целиком из соображений безопасности.

🟣Type 3 - Destination Unreachable, самый информативный тип с кучей Code внутри. Code 0 значит сеть недостижима, Code 1 - хост недостижим, Code 3 - порт недостижим (обычно приходит на UDP, когда порт закрыт). Code 4 отдельно интересен - Fragmentation Needed, приходит когда пакет слишком большой, а бит DF (Don’t Fragment) установлен.

🟣Именно Type 3 Code 4 лежит в основе Path MTU Discovery - механизма, который автоматически находит максимальный размер пакета на всём пути. Если где-то по дороге роутер не может протолкнуть пакет целиком, он не режет его, а шлёт обратно ICMP с этим кодом, отправитель уменьшает размер и пробует снова.

🟣Type 11 - Time Exceeded, ровно на этом построен traceroute. Каждый транзитный роутер уменьшает TTL на 1, и когда TTL доходит до нуля, роутер дропает пакет и шлёт обратно Type 11. Traceroute просто шлёт пакеты с TTL=1, 2, 3 и так далее, собирая ответы от каждого хопа по пути.

🟣Type 5 - Redirect, роутер говорит хосту «есть путь короче, используй другой шлюз». В современных сетях это часто отключают из соображений безопасности, потому что атакующий в том же сегменте может слать поддельные Redirect и перенаправлять трафик через себя.

🟣Смотрим ICMP в трафике:

tcpdump -i eth0 icmp -nn



В выводе сразу видны type и code - например, ICMP time exceeded in-transit это Type 11, а ICMP net 10.0.0.5 unreachable - need to frag, mtu 1400 это классический Type 3 Code 4 с указанием реального MTU которое надо использовать.

Серверная Админа | Zeroday | #ICMP

👋 Привет, сетевой друг!

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

🟣Зачем он: после ZMap, Nmap или Masscan обычно возникает следующий вопрос: что именно висит на открытом порту? ZGrab2 подключается по нужному протоколу, получает ответ сервиса и сохраняет всё в JSON для дальнейшего анализа.

🟣Как работает: каждый протокол реализован отдельным модулем - HTTP, TLS, SSH, SMTP, Redis, MySQL, MQTT, SMB, FTP, NTP и ещё несколько десятков. Вместо простого “порт открыт” вы получаете HTTP-заголовки, TLS-сертификаты, баннеры сервисов, версии ПО, параметры рукопожатия и другие детали, которые обычный порт-сканер не показывает.

🟣Установка:

git clone https://github.com/zmap/zgrab2.git
cd zgrab2
make



🟣Полезные команды:

# HTTP
echo "example.com" | ./zgrab2 http

# TLS и сертификат
echo "example.com" | ./zgrab2 tls

# SSH-баннер
echo "192.168.1.10" | ./zgrab2 ssh

# Проверить SMTP
echo "mail.example.com" | ./zgrab2 smtp

# Получить информацию по NTP
echo "pool.ntp.org" | ./zgrab2 ntp

# Посмотреть доступные параметры модуля
./zgrab2 http -h



🟣Можно запускать сразу несколько модулей:

./zgrab2 multiple -c config.ini



Так за один проход получится проверить, например, HTTP, HTTPS и SSH на одном списке хостов.

🟣Почему его любят исследователи: ZGrab2 не пытается искать уязвимости или подбирать пароли. Он берет и супер подробно “говорит” с сервисом и сохраняет весь диалог. Например, TLS-модуль записывает сертификат, поддерживаемые версии протокола и параметры рукопожатия, HTTP - заголовки и код ответа, SSH - баннер сервера. Именно поэтому его часто используют при массовой инвентаризации инфраструктуры, анализе интернет-сервисов и поиске устаревших или неправильно настроенных систем.

Серверная Админа | Zeroday | #Инструмент

📝 Ричард Столлман: человек который придумал свободу для кода раньше чем это стало трендом

Расскажу о человеке без которого не было бы ни Linux в привычном виде, ни огромной части современной инфраструктуры серверов.

🟣В начале 80-х Столлман работал в MIT Lab for Artificial Intelligence и застал момент когда культура свободного обмена кодом между программистами начала исчезать - компании стали закрывать исходники, требовать NDA, продавать софт как закрытый продукт. Для Столлмана это выглядело не как естественное развитие индустрии, а как потеря чего-то принципиально важного.

🟣В 1983 году он объявил о запуске проекта GNU (GNU’s Not Unix) - цель была написать полностью свободную операционную систему с нуля, совместимую с Unix но без единой строчки проприетарного кода. К концу 80-х GNU дал миру компилятор GCC, редактор Emacs, десятки утилит командной строки - всё то что сейчас есть в любом Linux-дистрибутиве по умолчанию.

🟣Столлман придумал не просто лицензию, а целую философию через GPL (GNU General Public License) в 1989 году. Ключевая идея - copyleft: если ты берёшь код под GPL и модифицируешь его, твоя версия тоже обязана остаться свободной. Это было принципиально другое решение чем просто “выложить код в открытый доступ” — GPL защищала свободу кода юридически, не давая закрыть производную работу.

🟣В 1991 году уже Линус Торвальдс написал ядро Linux и лицензировал его под GPL - сумма GNU-утилит и Linux-ядра дала полноценную операционную систему которую большинство называет просто “Linux”, хотя формально это GNU/Linux, на чём Столлман настаивает до сих пор.

🟣Столлман остаётся фигурой спорной: его радикальная позиция по поводу проприетарного софта, отказ от смартфонов и облачных сервисов, специфичное поведение на конференциях вызывают споры до сих пор. Но без GPL и философии copyleft большая часть современной серверной инфраструктуры - от Linux до огромного количества опенсорсных инструментов на этом канале - выглядела бы совершенно иначе.

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Сегодня настроим защиту MikroTik от DHCP Starvation.

🟣DHCP Starvation - это атака, при которой засыпает DHCP-сервер тысячами запросов с разными MAC-адресами и забирает весь пул IP.
Когда адреса заканчиваются, новые устройства просто перестают получать IP.

🟣Включаем DHCP Snooping:

/interface bridge
set bridge1 dhcp-snooping=yes



Теперь мост начинает отслеживать DHCP-трафик и понимает, с каких портов разрешено отвечать DHCP-серверу.

🟣Помечаем доверенный порт:
Если DHCP-сервер подключен, например, к ether1:

/interface bridge port
set [find interface=ether1] trusted=yes



Все остальные порты останутся недоверенными. Если кто-то попытается поднять свой DHCP-сервер внутри сети, его ответы просто не пройдут.

🟣Ограничиваем количество MAC-адресов на клиентском порту:

/interface bridge port
set [find interface=ether5] \
    learning=yes \
    unknown-unicast-flood=no



А если используется RouterOS v7 с поддержкой ограничения обученных MAC, можно задать лимит через настройки bridge port, чтобы на одном порту не появлялись сотни новых адресов.

🟣Проверяем работу:

/interface bridge port print
/interface bridge host print
/ip dhcp-server lease print



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

🟣DHCP Starvation занимает считанные секунды, а последствия ощущают все юзеры сети. DHCP Snooping почти не нагружает устройство, зато сразу закрывает сразу две проблемы: блокирует rogue DHCP-серверы и сильно усложняет подобные атаки внутри локальной сети.

Серверная Админа | Бункер Хакера | #Mikrotik

👋 Привет, сетевой друг!
Сегодня разберу RPKI (Resource Public Key Infrastructure) - механизм, который защищает BGP от одной из самых старых проблем интернета: когда кто-то случайно или специально объявляет чужие IP-префиксы.

🟣Зачем он: BGP исторически доверяет соседям. Если AS64500 объявит:
203.0.113.0/24 интернет может начать отправлять туда трафик, даже если этот префикс принадлежит другой организации.
RPKI добавляет проверку: имеет ли конкретная автономная система право объявлять этот маршрут.

🟣Как работает: владелец сети создаёт ROA (Route Origin Authorization):

Prefix: 203.0.113.0/24
Origin AS: 64500
Max Length: /24



Эти данные подписываются криптографически и публикуются в RPKI-хранилищах.
Маршрутизатор получает список ROA и проверяет BGP-анонс:

Prefix: 203.0.113.0/24
Origin AS: 64501



Результат:

VALID   - AS имеет право объявлять сеть
INVALID - AS не соответствует ROA
UNKNOWN - ROA для сети нет



🟣Проверка маршрутов на MikroTik: Добавляем валидатор RPKI:

/routing rpki
add group=rpki-cache address=192.0.2.10 port=8282



Проверяем состояние:

/routing rpki print



🟣Добавляем фильтр BGP: Например, запрещаем INVALID-маршруты:

/routing filter rule
add chain=bgp-in rule="if (rpki invalid) { reject }"



Теперь маршруты с неправильным origin AS не попадут в таблицу маршрутизации.

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

Проверяем статус маршрута:

/ip route print detail



И смотрим BGP-анонсы:

/routing bgp advertisements print



🟣Почему это нужно: BGP работает между десятками тысяч автономных систем, и одна ошибка в конфигурации может отправить большой кусок интернета не туда. RPKI не заменяет BGP-фильтры, но добавляет ещё один уровень проверки - уже на уровне криптографического подтверждения права владения маршрутом.

Серверная Админа | Zeroday | #RPKI

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Сегодня про инструмент bgscan. Это быстрый многопротокольный сканер, который умеет строить целые цепочки проверок: например, ICMP → TCP → HTTP.

🟣Зачем он: обычно сначала пингуют сеть, потом отдельно сканируют порты, затем вручную проверяют веб-сервисы. bgscan позволяет собрать всё это в один pipeline, чтобы на следующий этап попадали только хосты, прошедшие предыдущий.

🟣Как работает: каждый протокол - отдельный модуль. Сначала можно найти живые узлы по ICMP, затем проверить открытые TCP-порты и только после этого отправить HTTP/HTTPS-запросы. Есть три режима работы: Streaming (результаты сразу передаются дальше), Sequential (этап за этапом) и Batch (пакетами).

🟣Установка:

curl -fsSL https://raw.githubusercontent.com/MohsenBg/bgscan/refs/heads/main/scripts/install.sh | bash



или собрать из исходников:

git clone https://github.com/MohsenBg/bgscan.git
cd bgscan
go run ./cmd/bgscan/



🟣Что умеет:

ICMP      — поиск живых хостов
TCP       — проверка портов
HTTP/1-3  — тест веб-сервисов
TLS       — анализ TLS
DNS       — проверка резолверов
Xray      — валидация прокси



🟣Чем крут: после каждого этапа результаты автоматически сохраняются в CSV и могут стать входными данными для следующего запуска. Например, сначала просканировали миллион адресов по ICMP, затем взяли только ответившие и проверили TCP, а потом - только узлы с открытым 443-м портом на поддержку HTTP/3 или TLS.

🟣Приятная мелочь: вместо десятков параметров в командной строке здесь полноценный терминальный интерфейс на BubbleTea - запуск сканирования, просмотр прогресса, управление результатами и настройками выполняются прямо из TUI, без браузера и веб-панелей.

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Сегодня разберём ещё 5 полезных фишек для Cisco IOS, которые реально экономят время и нервы.

🟣TCP Fast Open (TFO) - отправляем данные уже во время SYN, не дожидаясь завершения трёхстороннего рукопожатия:

sysctl -w net.ipv4.tcp_fastopen=3
sysctl net.ipv4.tcp_fastopen



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

🟣TCP MTU Probing - автоматически подбираем рабочий MTU, если ICMP режется где-то по пути:

sysctl -w net.ipv4.tcp_mtu_probing=1
sysctl -w net.ipv4.tcp_base_mss=1024



Помогает при PMTU Black Hole, когда пакеты теряются из-за слишком большого MTU, а ICMP Fragmentation Needed не проходит.

🟣BBR вместо CUBIC - меняем алгоритм контроля перегрузки:

sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr



BBR оценивает пропускную способность и RTT, а не реагирует только на потери. На каналах с высокой задержкой часто даёт более стабильную скорость.

🟣TCP SYN Cookies - защита от переполнения очереди SYN:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl net.ipv4.tcp_syncookies



При SYN Flood ядро перестаёт хранить состояние для полуоткрытых соединений и кодирует его прямо в SYN-ACK, сохраняя работоспособность сервиса.

🟣Просмотр TCP-сокетов через ss - получаем гораздо больше информации, чем через netstat:

ss -ti
ss -o state established



Можно увидеть congestion control, RTT, congestion window, retransmits, таймеры и другие параметры конкретного соединения - очень полезно при разборе проблем с производительностью.

Серверная Админа | Zeroday | #Cisco

👋 Привет, сетевой друг!

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

🟣Что это: бывает, что одно волокно в оптической паре повредилось. Один коммутатор продолжает видеть соседа, интерфейс горит зелёным, а вот ответы обратно уже не приходят. Для Ethernet всё выглядит нормально - порт up/up, хотя связь фактически сломана.

🟣Как это работает: устройства регулярно обмениваются UDLD-пакетами, в которых сообщают, кто они и через какой порт подключены. Если коммутатор перестал получать такие пакеты от соседа, но физический линк всё ещё поднят, он понимает: это не обычный обрыв, а однонаправленная связь.

🟣Почему это опасно: в такой ситуации могут начать странно работать STP, EtherChannel и даже обычная коммутация. Где-то появится blackhole, где-то зависнет агрегированный канал, а поиск причины легко может затянуться на часы - ведь интерфейс продолжает выглядеть полностью рабочим.

🟣Базовая настройка (Cisco):

udld enable

interface TenGigabitEthernet1/0/1
 udld port

Если нужен более жёсткий контроль:
udld aggressive
В этом режиме устройство несколько раз пытается восстановить обмен, а если ничего не меняется - автоматически переводит порт в err-disabled, чтобы неисправный линк не успел натворить проблем.

🟣Что посмотреть при диагностике:

show udld
show udld interface
show interfaces status err-disabled

Если порт отключился именно по UDLD, первым делом стоит проверить SFP-модули, патч-корды и оптические волокна. Очень часто проблема оказывается не в настройках сети, а в физике.

Серверная Админа | Zeroday | #Network

👋 Привет, сетевой друг!

Продолжаем разбираться с API. В прошлый раз говорили, что это способ общения программ. Сегодня расскажу, как происходит этот "разговор" на практике.

🟣Из чего состоит запрос: почти любой API использует четыре вещи: адрес (URL), метод, заголовки и, при необходимости, тело запроса.

Например:

curl -X GET https://router/api/interfaces \
-H "Authorization: Bearer TOKEN"

Здесь GET - метод, /api/interfaces - нужный ресурс, а токен в заголовке подтверждает, что у нас есть право получить информацию.

🟣Что приходит в ответ: чаще всего - JSON. Его легко читать человеку и ещё проще обрабатывать программами.

{
  "name": "Gi0/1",
  "admin_state": "up",
  "oper_state": "up",
  "speed": "1G"
}

После этого Python, Ansible или даже Bash могут сразу использовать эти данные без парсинга CLI.

🟣Коды ответа тоже важны:

200 — всё успешно
201 — объект создан
400 — ошибка в запросе
401 — нет авторизации
403 — доступ запрещён
404 — объект не найден
500 — проблема на стороне сервера

По одному статус-коду часто уже можно понять, где искать проблему.

🟣Полезные команды:

# Красиво вывести JSON
curl https://device/api/interfaces | jq

# Посмотреть только HTTP-заголовки
curl -I https://device/api

# Посмотреть полный обмен
curl -v https://device/api

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

Серверная Админа | Zeroday | #API

👨‍💻Серверная Админа | #мем

👋 Привет, сетевой друг!

Сегодня разберём vps-audit, небольшой Bash-скрипт, который делает из обычного VPS - объект для быстрого security-аудита.

🟣Что это: часто после установки сервера проверяют только “работает ли SSH и сайт”. Но в реальности на VPS могут остаться открытые порты, включённый root login, слабые настройки SSH, лишние сервисы или переполненный диск. vps-audit собирает всё это в один отчёт без установки тяжёлых инструментов.

🟣Как работает: внутри это обычный Bash-скрипт, который последовательно проверяет системные параметры через стандартные Linux-команды.

Например:

• SSH-конфигурацию (sshd_config)
• состояние firewall (UFW)
• Fail2ban
• последние неудачные входы
• обновления системы
• запущенные сервисы через systemd
• открытые порты
• SUID-файлы
• нагрузку CPU, RAM и диска

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

⏺PASS - всё нормально
⏺WARN — стоит проверить
⏺FAIL — потенциальная проблема

🟣Установка:

wget https://raw.githubusercontent.com/vernu/vps-audit/main/vps-audit.sh

chmod +x vps-audit.sh

Запуск:

sudo ./vps-audit.sh

🟣Примеры проверок:
Проверка SSH:

[PASS] SSH Root Login - disabled
[WARN] SSH Port - using default port 22

Проверка открытых портов:

ss -tulpn

Скрипт анализирует, какие сервисы слушают сеть, и показывает потенциально лишние точки входа.

🟣Что ещё полезно смотреть вручную после отчёта:

Активные сервисы:

systemctl list-units --type=service --state=running

SUID-файлы:

find / -perm -4000 -type f 2>/dev/null

Последние попытки входа:

lastb

Серверная Админа | Zeroday | #Инструмент

👋 Привет, сетевой друг!

Firewall и IDS/IPS - оба анализируют трафик и оба про безопасность, но принимают решения на основе разной логики. Разберём в чём разница.

🟣Firewall - фильтрует трафик по правилам которые описывают структуру соединения: IP-адреса, порты, протоколы, состояние сессии (stateful). Он не смотрит что внутри пакета с точки зрения содержимого - задача файрвола ответить на вопрос “разрешено ли этому источнику обращаться к этому назначению по этому порту”. Если правило разрешает трафик на 443 порт - файрвол пропустит любой TCP-пакет туда, даже если внутри реальная атака, потому что для него это выглядит как легитимное HTTPS-соединение.

🟣IDS/IPS (Intrusion Detection/Prevention System) - анализирует содержимое трафика на предмет сигнатур атак, аномального поведения и известных паттернов эксплуатации. IDS работает в пассивном режиме - видит копию трафика через SPAN-порт, обнаруживает угрозу и просто сигнализирует. IPS работает inline - стоит прямо в разрыве канала и может заблокировать пакет в реальном времени до того как он дойдёт до цели.

🟣Ключевое различие: Firewall решает “кому вообще можно сюда стучаться” на уровне структуры соединения, IDS/IPS решает “что происходит внутри разрешённого соединения” на уровне содержимого и поведения. Файрвол пропустит SQL-инъекцию на 443 порт потому что порт открыт легитимно - IPS увидит саму инъекцию в теле HTTP-запроса и заблокирует именно её, не трогая остальной трафик на этом порту.

🟣На деле они работают слоями: файрвол на периметре режет всё что явно не должно проходить по портам и адресам, IPS дальше разбирает то что файрвол пропустил и ищет уже конкретные признаки атаки внутри разрешённого трафика. Убрать любой слой - и защита становится однобокой: без файрвола IPS захлебнётся анализируя весь трафик подряд включая заведомо неразрешённый, без IPS файрвол пропустит любую атаку которая маскируется под легитимный протокол на открытом порту.

Серверная Админа | Zeroday | #firewall #ids