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

Расскажу еще о 3 способах прокачать защиту Mikrotik.

🟣Автоматическая ловля портсканеров через PSD (port scan detection): В MikroTik есть встроенный детектор сканирования - без L7 и без скриптов. Он анализирует частоту попыток подключений к разным портам и сам помечает сканеры.

/ip firewall filter
add chain=input protocol=tcp psd=21,3s,3,1 \
    action=add-src-to-address-list \
    address-list=port_scanners address-list-timeout=1d \
    comment="Detect TCP port scanners"

add chain=input src-address-list=port_scanners action=drop \
    comment="Drop detected scanners"

Если IP за короткое время лезет на много портов - улетает в бан на сутки. Отсекает nmap, masscan, zmap и 90% автоматических разведок.

🟣Сброс кривых TCP-пакетов (флаги, которые в нормальной сети не существуют): Большая часть атак и сканов шлёт комбинации флагов, которые обычный стек TCP не использует. Их можно рубить ещё в raw.

/ip firewall raw
add chain=prerouting protocol=tcp tcp-flags=fin,syn action=drop comment="Invalid FIN+SYN"
add chain=prerouting protocol=tcp tcp-flags=fin,rst action=drop comment="Invalid FIN+RST"
add chain=prerouting protocol=tcp tcp-flags=fin,ack action=drop comment="Stealth scan pattern"
add chain=prerouting protocol=tcp tcp-flags=!syn,!ack,!rst,!fin action=drop comment="Null scan"

Что это даёт:
• режет stealth-сканы
• режет странные probing-пакеты
• снижает шум в conntrack

Легальный трафик так никогда не ходит.

🟣Отсечение bogon и поддельных source IP на WAN: Очень много мусора приходит с адресов, которые в интернете вообще не должны существовать: private сети, loopback, multicast и т.п.

/ip firewall address-list
add list=bogons address=0.0.0.0/8
add list=bogons address=10.0.0.0/8
add list=bogons address=127.0.0.0/8
add list=bogons address=169.254.0.0/16
add list=bogons address=172.16.0.0/12
add list=bogons address=192.168.0.0/16
add list=bogons address=224.0.0.0/4

/ip firewall raw
add chain=prerouting in-interface=WAN src-address-list=bogons \
    action=drop comment="Drop spoofed/bogon sources"

Эффекты:
• режется spoofing
• уменьшается нагрузка
• половина мусорных атак даже не доходит до firewall logic

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

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

Сегодня разберём одну из самых частых путаниц в performance-туннинге: Latency ≠ Response Time - и почему из-за этого часто оптимизируют не то место.

🟣Latency - это только путь по сети. Это чистое время передачи пакетов между клиентом и сервером: расстояние, маршрутизация, количество хопов, качество канала, CDN и перегруженные пиринги. Проще говоря - сколько данные физически «летят». Если RTT около 500 мс, то примерно 250 мс уходит в одну сторону, и это ещё не скорость приложения, а лишь транспорт.

🟣Response Time - это то, что реально видит пользователь. Полное время от отправки запроса до получения ответа. Формула всегда одна:

• Response Time = Latency + Processing Time.
• А Processing Time - вся работа сервера: разбор запроса, авторизация, обращения к базе и кэшу, бизнес-логика, генерация и сериализация ответа.

🟣Как это выглядит на деле: Запрос летит к серверу 500 мс, сервер обрабатывает его 1 500 мс, ответ возвращается за 300 мс. Итог - 2,3 секунды. Из них 800 мс это сеть, а полторы секунды чистая обработка. То есть большая часть задержки вообще не связана с инфраструктурой.

🟣Как быстро понять, где настоящий тормоз: Если растёт Latency - проблема почти всегда в сети: маршруты, удалённый дата-центр, отсутствие CDN, перегруженные каналы. Если растёт Processing Time - узкое место внутри сервиса: медленные SQL-запросы, блокировки, тяжёлая логика, паузы сборщика мусора, синхронные вызовы.

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

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

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

🟣TCP Intercept для защиты от SYN-флудов: Вместо того чтобы просто дропать пакеты, роутер ведёт TCP handshake и пропускает только легитимные соединения, снижая нагрузку на сервер.

ip tcp intercept list SYN-FLOOD
ip tcp intercept mode intercept
ip tcp intercept max-incomplete 100
ip tcp intercept one-minute

🟣IP SLA Object Tracking для динамического failover: Можно автоматически переключать маршруты или интерфейсы при падении сервиса, а не только линка.

ip sla 1
 icmp-echo 8.8.8.8 source-interface Gi0/0
 frequency 5
ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability
ip route 0.0.0.0 0.0.0.0 10.0.0.1 track 1
ip route 0.0.0.0 0.0.0.0 10.0.0.2 10

🟣Service Policy для QoS на Control Plane: Не только пользовательский трафик, но и OSPF, BGP, SNMP могут перегрузить CPU. Ограничиваем их через QoS.

class-map match-any CTRL-TRAFFIC
 match protocol ospf
 match protocol bgp
 match protocol snmp

policy-map CTRL-POLICY
 class CTRL-TRAFFIC
  police 64000 conform-action transmit exceed-action drop

control-plane
 service-policy input CTRL-POLICY

🟣Embedded Packet Capture (EPC) с фильтром VLAN: Захватываем трафик прямо на коммутаторе или роутере без SPAN-портов и смотрим только нужное.

monitor capture EPC interface Gi1/0/1 both match vlan 10
monitor capture EPC start
monitor capture EPC stop
show monitor capture EPC buffer brief
copy monitor capture EPC tftp://10.0.0.100/capture.pcap

🟣Smart Call Home Alerts: Устройство само отправляет оповещения о проблемах (состояние интерфейсов, ошибки, SLA) на заранее настроенный email или syslog, чтобы админ узнавал раньше, чем падает сеть.

call-home
 profile "ALERTS"
  destination email admin@example.com
  subscribe-to all
  periodic-schedule daily 08:00
  send-alerts

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

📝 История Wi-Fi: как радио из лабораторий стало главным способом выхода в интернет

Сегодня вспомним, как беспроводные сети прошли путь от экспериментальных скоростей до основы домашних и корпоративных сетей.

🟣Когда всё было почти игрушкой: В конце 90-х первый стандарт 802.11 давал всего 2 Мбит/с. Связь легко рвалась, шифрование было слабым, а точки доступа больше напоминали дорогие радиомодемы. Но идея «интернет без проводов» уже выглядела магией.

🟣Взлёт популярности с 802.11b и g: Появились 11 и 54 Мбит/с - скорости, сопоставимые с тогдашним Ethernet. Кафе, офисы и дома начали массово уходить от кабелей. Wi-Fi перестал быть экзотикой и стал стандартом для ноутбуков.

🟣Эра умных антенн и MIMO: Стандарты n и ac научили сеть передавать данные сразу по нескольким потокам. Скорости выросли в разы, стабильность стала выше, а беспроводная сеть впервые начала конкурировать с проводной по качеству.

🟣Гигабиты по воздуху: Wi-Fi 6 и 6E принесли OFDMA, работу с сотнями клиентов и реальные гигабитные скорости в перегруженных сетях. Теперь Wi-Fi это не компромисс, а полноценная инфраструктура.

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

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

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

Сегодня разберём QUIC + HTTP/3 против TCP + TLS + HTTP/2 - что реально происходит в сети и почему веб переползает на новый транспорт.

🟣Классический стек TCP + TLS + HTTP/2: Браузер открывает сайт в несколько этапов: TCP-рукопожатие, потом TLS-рукопожатие, и только после этого летят HTTP-запросы. Даже в хорошей сети это 2–3 RTT до первого байта.
Главный же минус TCP это строгий порядок доставки. В случае потери одного пакета весь поток ждёт повторной передачи. HTTP/2 мультиплексирует запросы, но внутри одного TCP они всё равно блокируют друг друга.

Проверить соединение:

curl -I –http2 https://example.com

Посмотреть задержки:

curl -w “DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect}\n” -o /dev/null -s https://example.com

🟣Что меняет QUIC: QUIC работает поверх UDP, сразу шифрован. Нет отдельного TCP и TLS, так как всё слито в один слой. Каждый запрос, как отдельный поток.

1️⃣Потерялся пакет видео - не тормозит загрузку HTML. 2️⃣Потерялся кусок картинки - JS выполняется дальше. Соединение привязано к криптосессии, а не к IP.
3️⃣А если переключился с Wi-Fi на LTE, то соединение продолжает жить.

Проверка HTTP/3:

curl -I –http3 https://cloudflare.com
Сравнение:
curl –http3 -v https://cloudflare.com
curl –http2 -v https://cloudflare.com

🟣Почему QUIC рвёт TCP в реальности: В лаборатории TCP нормальный. В реале: мобильные сети теряют пакеты, Wi-Fi скачет по latency, маршруты меняются. TCP начинает простаивать на retransmission. Эмулируем реальный интернет:

tc qdisc add dev eth0 root netem delay 100ms loss 2%

HTTP/2 залипает, HTTP/3 продолжает качать почти без деградации.

🟣Почему CDN массово перешли: Google, Cloudflare, Meta, Akamai уже отдают большую часть трафика по QUIC:

• меньше handshake-задержек
• нет head-of-line blocking
• лучше на мобилках
• проще масштабируется

Серверная Админа | #QUIC #TCP

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

Сегодня поговорим об инструменте Netfox

🟣Netfox - лёгкая библиотека для сетевого дебага в iOS и macOS, которая показывает все HTTP/HTTPS-запросы прямо в приложении. Netfox перехватывает все запросы приложения - ваши, SDK вроде Alamofire или AFNetworking, WebView и даже UIWebView. Можно мгновенно смотреть headers, body, статус ответа, размер и тайминги, прямо в интерфейсе приложения.

🟣Когда это удобно: Если API тупит, SDK ведёт себя странно или баг проявляется только на девайсе, Netfox показывает всё «живьём». Для QA-сборок и тестеров это настоящий спасатель: вы видите, что реально летит и возвращается, и не нужно ловить пакеты через Wireshark или Charles.

🟣Как подключить: Для Swift достаточно одной строки в didFinishLaunchingWithOptions, и только в Debug:

import netfox

#if DEBUG
NFX.sharedInstance().start()
#endif

Логи открываются привычным shake, но можно кастомизировать жест:

NFX.sharedInstance().setGesture(.custom)
NFX.sharedInstance().show()
NFX.sharedInstance().hide()

🟣Управление и фильтры: Можно останавливать Netfox, очищать логи и исключать конкретные URL, чтобы не засорять вывод:

NFX.sharedInstance().stop()
NFX.sharedInstance().ignoreURL("https://api.example.com")

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