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

Собрал три способа прокачать защиту MikroTik - особенно если роутеров уже несколько и хочется меньше ручной работы…

🟣Автоматически обновлять блок-листы через RouterOS API + Python: Когда роутеров десятки, заходить на каждый и вручную добавлять подозрительные IP - сомнительное удовольствие. Через API можно централизованно обновлять address-list и быстро распространять блокировки на весь парк:

import routeros_api

connection = routeros_api.RouterOsApiPool(
    '192.168.1.1',
    username='admin',
    password='pass',
    plaintext_login=True
)

api = connection.get_api()

rules = api.get_resource('/ip/firewall/filter')
print(rules.get())

Например, добавить IP в blocklist:

api.get_resource('/ip/firewall/address-list').add(
    list='blocklist',
    address='10.0.0.5',
    comment='auto-blocked'
)

Так можно быстро блокировать адреса, полученные из SIEM, threat intelligence или внутренней системы мониторинга, сразу на всех MikroTik.

🟣Проверять доступность сервисов через Netwatch: Ping не всегда показывает реальное состояние сервиса. Хост может отвечать на ICMP, пока nginx возвращает 502, приложение не работает, а пользователи уже не могут подключиться. Для дополнительного контроля Netwatch можно связать с HTTP health-check и проверять конкретный endpoint:

/tool netwatch
add host=10.0.0.10 interval=30s timeout=5s \
    type=HTTP http-codes=200 \
    down-script="/log error \"Web server DOWN\"" \
    up-script="/log info \"Web server UP\""

Если сервис перестал отвечать, down-script может добавить его адрес в отдельный список, отправить событие в мониторинг или запустить переключение на резервный сервер.

🟣Ловить сканирование внутри сети: Скомпрометированный хост может начать быстро перебирать адреса и открывать множество TCP-соединений. Для этого можно отслеживать новые SYN и складывать активные источники в отдельный список:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn \
    connection-state=new \
    src-address-list=!whitelist \
    action=add-src-to-address-list \
    address-list=syn-tracking \
    address-list-timeout=30s

/ip firewall filter
add chain=forward protocol=tcp tcp-flags=syn \
    connection-state=new \
    src-address-list=syn-tracking \
    connection-limit=30,32 \
    action=add-src-to-address-list \
    address-list=internal-scanner \
    address-list-timeout=1h \
    log=yes \
    log-prefix="SCAN DETECTED:"

add chain=forward src-address-list=internal-scanner \
    action=drop \
    log=yes \
    log-prefix="SCANNER BLOCKED: "

В итоге источник, который набирает слишком много одновременных TCP-соединений, попадает в internal-scanner, а следующее правило уже режет ему трафик.

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

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

Сегодня про Ethernet, который мы привыкли воспринимать как обычный кабельный LAN. Но за ним давно стоит целый набор технологий, которые позволяют гонять трафик на десятки и сотни гигабит.

🟣Сначала был 10BASE-T: В классическом Ethernet по витой паре использовались 10 Мбит/с и обычная схема с хабами. Несколько устройств делили один collision domain и решали, кто сейчас может передавать, через CSMA/CD. С современными коммутаторами эта история практически исчезла.

🟣Потом Ethernet научился работать одновременно: Появился full-duplex: устройство может передавать и принимать данные одновременно, а коллизии на коммутируемом соединении больше не нужны. Поэтому сегодня 1000BASE-T означает не просто «гигабит по кабелю». Это уже point-to-point соединение между портом коммутатора и конечным устройством.

🟣А дальше началась гонка скоростей:

10 → 100 → 1000 → 10G → 25G → 40G → 100G → 200G → 400G → 800G.

Причём скорость росла не только за счёт увеличения частоты сигнала. Используются более сложные схемы кодирования, PAM4, несколько физических линий и всё более продвинутые DSP. Например, 400GbE может передавать данные четырьмя электрическими или оптическими лэйнами по 100 Гбит/с.

🟣Почему 25G вообще появился, если был 10G?: Для дата-центров оказалось удобнее масштабировать серверные подключения по 25G: один 25G lane хорошо сочетается с 100G и 400G аплинками.
Например:

Server
  │ 25G
  ▼
Leaf
  │ 100G
  ▼
Spine
  │ 400G
  ▼
Core

Так Ethernet постепенно превратился из стандарта для офисной сети в основу современных дата-центров.

🟣И самое интересное: Ethernet не выиграл потому, что у него всегда была самая высокая скорость. Его сила в огромной экосистеме: совместимые коммутаторы, NIC, оптика, медь, стандарты, LACP, VLAN, QoS и куча оборудования от разных производителей. Поэтому когда вы подключаете сервер на 25G или 100G, под капотом всё ещё работает тот же Ethernet, которому уже больше 40 лет.

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

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

Почему SAML снова и снова ломается на одном и том же месте?

SAML больше 20 лет отвечает за корпоративный SSO, но исследователи до сих пор находят способы обходить его защиту. В статье разбирают, как XML-комментарии, особенности парсеров и канонизация позволяют подменять подписанные данные так, что проверка проходит, а приложение получает уже другое содержимое.

🟣Разбирают пять проблем протокола: сложность XML, канонизацию, вложенные подписи, перегруженную спецификацию и устаревшую архитектуру. Отдельно проходят по XSW, parser differential и round-trip-атакам, а затем сравнивают подход SAML с OIDC и показывают, почему современные системы постепенно уходят от XML в сторону JSON/JWT.

Серверная Админа | 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 | #Инструмент

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

Давай разберём несколько 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 | #Инструмент

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

Сегодня про 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

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

Ещё три функции 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