🔍 Быстрая диагностика задержек и потерь пакетов с tcpdump + tshark

Устали искать «почему тормозит сеть» вслепую? Давайте соберём данные и быстро выявим узкое место.

1️⃣ Сниффинг трафика

tcpdump -i eth0 port 80 -w /tmp/capture.pcap \
  -C 50 -W 4

• -C 50 & -W 4 — кольцевой буфер: четыре файла по 50 МБ, без остановки
• port 80 — фильтрация по порту (замените на нужный)

2️⃣ Подсчёт средних RTT и пакетов

tshark -r /tmp/capture.pcap \
  -q -z io,stat,0,AVG(tcp.analysis.ack_rtt)

Выдаст статистику задержек TCP-ACK во времени.

3️⃣ Анализ потерь и повторов

tshark -r /tmp/capture.pcap \
  -Y "tcp.analysis.retransmission or tcp.analysis.loss" \
  -T fields -e frame.number -e tcp.analysis.retransmission

Список фреймов с повторными передачами или потерями.

4️⃣ Состояние сокетов в реальном времени

ss -s          # общая статистика
ss -ti dst :80 # детально по портам

❓ Зачем и когда

Выявить задержки: RTT и пики задержек.
Найти потери: точно знать, на каком сегменте уходит трафик.
Без GUI: всё в консоли, подходит для серверов.

💡 Трюк
Для live-анализа пропускайте вывод tcpdump напрямую:

tcpdump -i eth0 -l port 443 | tshark -l -T fields -e frame.time_relative -e tcp.analysis.ack_rtt

Таким образом вы сразу видите задержки без файлов.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔒 iptables: блокируем скан nmap

Многие забывают: nmap умеет скрываться. Обычные правила iptables не всегда помогут. Но есть трюк.

📌 Цель: заблокировать NULL, FIN, XMAS сканы — любимые техники скрытного обнаружения.



👣 Пошагово:

# Блокируем NULL-скан (без флагов)
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

# Блокируем FIN-скан (только FIN-флаг)
iptables -A INPUT -p tcp --tcp-flags ALL FIN -j DROP

# Блокируем XMAS-скан (FIN, PSH, URG)
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP

💡 Эти сканы эксплуатируют особенности TCP — они не характерны для нормального трафика. Если ты не хостишь экзотику, можно смело дропать.



⚠️ Важно: Не перебарщивай — агрессивные правила могут мешать нестандартным приложениям (например, BitTorrent). Проверяй логи!


🔥 Добавь логирование в отдельную цепочку для отладки:

iptables -N SCAN_DROP
iptables -A SCAN_DROP -j LOG --log-prefix "PortScan Blocked: " --log-level 7
iptables -A SCAN_DROP -j DROP

# Пример с логом:
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j SCAN_DROP

🧠 Защита от портсканирования — это must-have на фронте. Идеально в связке с fail2ban.

Сохрани, пригодится 💥

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔥 Как быстро сбросить iptables, не потеряв доступ по SSH

Иногда после кривой настройки iptables можно отрезать себя от сервера. Но если SSH-сессия ещё активна — есть шанс всё вернуть.

🔧 Пошагово:
1. Сохраняем текущие правила в файл — на всякий случай:

iptables-save > /root/iptables.bak

2. Создаём “спасательный” скрипт для сброса:

cat <<EOF > /tmp/flush.sh
#!/bin/bash
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
EOF

chmod +x /tmp/flush.sh

3. Запускаем с отложенным выполнением (через 1 минуту):

at now + 1 minute -f /tmp/flush.sh

4. ⚠️ За это время проверь правила и поправь ошибки.
Если всё заработает — отмени задание, чтобы не сбросить то, что уже исправлено:

atq # узнать ID задания
atrm <ID>

🧠 Зачем?
Этот приём спасает при ошибках в firewall’е, когда нельзя подключиться заново, но активная сессия ещё жива.

💡Добавляй в iptables-скрипты проверку подключения (например, через ping/curl), прежде чем применять DROP-политики.

Сохрани, пригодится. А ты так страхуешься?

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔥 Сетевой интерфейс завис после ifdown? Как поднять без ребута

Иногда после ifdown eth0 интерфейс "залипает": ip link показывает DOWN, ifup eth0 — молчит или пишет, что интерфейс уже внизу. Особенно частая беда при ручных правках /etc/network/interfaces.

📌 Решение:

# Убедимся, что интерфейс точно down
ip link show eth0

# Принудительно поднимем
ip link set eth0 up

# Применим конфиг из /etc/network/interfaces
ifup --force eth0

💡 Или ещё жёстче — снять все адреса и применить заново:

ip addr flush dev eth0
ifdown --force eth0 && ifup eth0

📍Когда применять:
– после кривого ifdown;
– при ошибках конфигурации сетевого интерфейса без желания ребутать;
– если systemctl restart networking не помогает.

🛑 Важно: на проде делай это только с консоли или IPMI, иначе останешься без доступа.

Сохрани — пригодится, когда SSH срежет сук под тобой 😅

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

Сколько раз бывало: "Где лежит этот конфиг? А в каком файле та самая строка?" — и понеслась лихорадочная проверка /etc, find, grep...

🔍 Поиск файлов по имени:

find /etc -name "sshd_config"

А если не знаешь точное имя — используй маску:

find /var/log -iname "*auth*"

📂 Поиск только файлов или только директорий:

find /opt -type f       # только файлы
find /srv -type d       # только каталоги

🧵 Поиск по содержимому файла — мой любимый grep:

grep -Ri "PermitRootLogin" /etc/ssh

Здесь:

* -R — рекурсивно,
* -i — игнор регистра.

🎯 Хочешь только имена файлов, а не строки? Используй:

grep -Rl "Listen 80" /etc

🔥 Ищу файлы, изменённые за последние сутки:

find /etc -mtime -1

Это спасает, если надо понять, кто и когда трогал конфиги. Отличный приём при разборе инцидентов.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🛠 Мини-гайд: Как читать htop, если ты не просто кликаешь мышкой

htop — любимая команда всех линуксоидов. Но многие юзают её по принципу “вижу, что что-то горит — и ладно”. А ведь она даёт кучу полезной инфы, если читать внимательно.

Вот что стоит смотреть:


🔹 CPU bars (вверху)
– Разноцветные полоски = разные типы загрузки

* 🔴 красное — system (ядро)
* 💚 зелёное — user (твои процессы)
* 🔵 синее — nice (низкий приоритет)
* ⚫ серое — idle (простой)

Если всё в красном — значит, ядро чем-то занято. Чаще всего — IO или проблемы с драйверами.


🔹 Memory / Swap
– Если swap активно используется — беда. RAM не хватает.
– Если swap постоянно растёт — ищи прожорливый процесс.


🔹 Сортировка по колонкам
Нажми F6, чтобы выбрать, по чему сортировать:
– CPU
– MEM
– TIME+ (время работы)
– PRI (приоритет)

Часто забывают про TIME+ — а он показывает, кто реально долго жрёт ресурсы.


🔹 Управление процессами прямо из htop
– F9 — убить процесс
– F7/F8 — изменить приоритет (nice)
– F3 — поиск по названию
– F2 — кастомизация интерфейса (рекомендую)


htop — не просто анимация для терминала. Это инструмент диагностики.

Запусти у себя, поиграй с колонками и цветами, и начни действительно понимать, что происходит в системе.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🧠Ловим «призрачный» трафик: tcpdump

Сервер «висит» — подозрительная активность, но ss, netstat и iftop ничего не показывают? Используй tcpdump, чтобы увидеть весь трафик в обход сокетов.


📌 1. Базовый сниффинг по интерфейсу:

tcpdump -i eth0 -n

📌 2. Только входящие подключения (например, к порту 22):

tcpdump -i eth0 'tcp dst port 22'

📌 3. Вывести IP-адреса и порты в читаемом виде:

tcpdump -ni eth0

📌 4. Сохраняем трафик в файл для анализа:

tcpdump -i eth0 -w /tmp/capture.pcap

📌 5. Проверка на скан SYN-пакетов (часто — злоумышленники):

tcpdump 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

🔍 Когда использовать:
– Видишь нагрузку, а не можешь найти, кто её создаёт
– Подозрение на сканирование, ботнет или майнер
– Анализ нестандартного поведения сети

💡tcpdump может показать даже raw-трафик от контейнеров, tun-интерфейсов, снифферов, которые не видны через ss/netstat.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

💡 Как ускорить резолв DNS в Linux (и не словить таймаут)

Иногда curl, apt, ping и др. тормозят из-за медленного DNS. Особенно при неверной конфигурации /etc/resolv.conf. Вот как это проверить и поправить:


🔧 1. Проверяем текущий DNS:

systemd-resolve --status | grep 'DNS Servers' -A2

или:

resolvectl status

Убедись, что указан локальный (127.0.0.53) резолвер, если используется systemd-resolved, или явные DNS (например, 8.8.8.8) — если нет.


⚙️ 2. Проверяем /etc/resolv.conf:

cat /etc/resolv.conf

Если там:

nameserver 127.0.0.53

— ок для systemd-resolved.

Если там:

nameserver 127.0.0.1

— опасно! Убедись, что локальный DNS работает (dnsmasq, unbound и пр.). Иначе — будут фризы.


🚑 3. Подключи быстрые DNS напрямую (если нужно):

sudo nano /etc/systemd/resolved.conf

Добавь:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9

Применить:

sudo systemctl restart systemd-resolved

📌 Совет:

Проверь производительность DNS:

systemd-resolve google.com --statistics

Или используй dig, drill и resolvectl query.


#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🔗 goto: Навигация в консоли на новом уровне! 🚀

🔥 goto — это удобный инструмент для быстрого перемещения по директориям в командной строке. Если вы устали от постоянного набора длинных путей к папкам, этот инструмент станет вашим спасением!

🎯 Что делает goto?
- Позволяет сохранять короткие алиасы для директорий.
- Упрощает переход к важным папкам одной командой.
- Работает быстро, удобно и просто!

📌 Ключевые функции:
1. Добавление алиасов:

   goto add <alias> <path>
   

Пример:

   goto add projects ~/Documents/Projects
   

2. Навигация по алиасу:

   goto <alias>
   

Пример:

   goto projects
   

3. Список всех алиасов:

   goto list
   

4. Удаление алиасов:

   goto remove <alias>
   

💻 Установка
Просто клонируйте репозиторий и следуйте инструкциям:

git clone https://github.com/grafviktor/goto.git
cd goto
make install

🛠 Для кого?
- Разработчиков, которые работают с множеством проектов.
- Системных администраторов, часто переключающихся между директориями.
- Всех, кто хочет оптимизировать свою работу в терминале.


📥 Репозиторий: https://github.com/grafviktor/goto

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🚨 tcpdump + iptables: ищем странный трафик с минимальными усилиями

Бывает сервер грузится входящими соединениями, но откуда — непонятно. Ловим сразу по факту, не копаясь в логах.

🎯 Цель: отловить соединения к нестандартному порту, которых быть не должно.

🔧 Шаги:

1. Выясни, куда идет трафик:

   ss -tnlp
   

Смотри, какие порты слушаются. Допустим, нашли неожиданный порт 4444.

2. Добавь временное правило в iptables, чтобы логировать:

   iptables -I INPUT -p tcp --dport 4444 -j LOG --log-prefix "INCOMING 4444: " --log-level 4
   

3. Лови трафик через tcpdump, если логов нет или нужно больше деталей:

   tcpdump -i any port 4444 -n
   

Или в файл:

   tcpdump -i any port 4444 -n -w suspicious.pcap
   

4. Проверка логов:

   dmesg | grep 'INCOMING 4444'
   

Или в journald:

   journalctl -k | grep 'INCOMING 4444'
   

5. Удаление правила после анализа:

   iptables -D INPUT -p tcp --dport 4444 -j LOG --log-prefix "INCOMING 4444: " --log-level 4
   

⚠️ Зачем и когда применять:

– Быстрое выявление подозрительной активности
– Минимальное вмешательство в работу сервиса
– Отличный способ понять, «кто ломится» на редкие или ошибочно открытые порты

💡 tcpdump + iptables LOG — мощный дуэт для экспресс-анализа трафика без сложных тулов.

Сохрани, пригодится при разборе аномалий ⚙️

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🔒 Быстрый способ ограничить доступ к SSH по стране с помощью ipset + iptables

Если нужно быстро отрезать SSH от всего мира, кроме, скажем, России (или наоборот — закрыть доступ для определённой страны), вот практический способ.


1. Установи нужные пакеты:

apt install ipset xtables-addons-common -y

2. Скачай GeoIP базы:

/usr/lib/xtables-addons/xt_geoip_dl
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip /usr/share/xt_geoip/*

3. Создай ipset с нужной страной:

ipset create geo-ru hash:net

4. Загрузи IP-диапазоны страны (например, Russia):

wget -O - https://ipdeny.com/ipblocks/data/countries/ru.zone | while read ip; do ipset add geo-ru $ip; done

5. Применение iptables-правила:

iptables -A INPUT -p tcp --dport 22 -m set ! --match-set geo-ru src -j DROP

📌 Быстрый и действенный способ снизить количество bruteforce-попыток к SSH, особенно если сервер рассчитан на работу только из одной страны.

⚠️ Geo-блокировка не панацея — используйте вместе с fail2ban, ключами и сменой порта.

💡Можно применить тот же принцип для любого сервиса — не только SSH. Просто поменяй порт и ipset.

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🔥 Диагностика внезапных потерь связи через ip route get

Сеть вроде «живая», ping до шлюза идёт, но пакеты не доходят до нужного хоста? Быстрая проверка маршрута решит многое.

📌 Что делать:

ip route get 8.8.8.8

🔍 Что покажет:

- интерфейс, через который идёт маршрут
- IP-адрес источника (важно при policy routing)
- реальный шлюз
- отметку mtu, cache, unreachable и др.

🛠 Пример:

ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 1000

Если вместо via ... → unreachable, значит маршрут битый или его нет.

👀 Когда использовать:

- подозрение на policy routing
- неочевидные проблемы при SNAT/DNAT
- быстро понять, почему не ходит трафик

💡 Трюк:
Добавь -o к ip — получишь вывод в JSON, удобно парсить в скриптах:

ip -j route get 8.8.8.8 | jq .

Сохрани, пригодится в проде, когда всё внезапно «перестаёт работать».

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🔥 Неожиданный source IP у входящих соединений? Проверяем Reverse Path Filtering (rp_filter)

📌 Столкнулись с асимметричной маршрутизацией, при которой ss или tcpdump показывают странный source IP? Или iptables дропает "легитимные" соединения? — проблема может быть в rp_filter.


1. Нужно проверить текущие настройки:

   sysctl net.ipv4.conf.all.rp_filter
   sysctl net.ipv4.conf.default.rp_filter
   

1 — strict mode (по умолчанию);
0 — отключено;
2 — loose mode (рекомендуется при асимметрии или сложной маршрутизации).

2. Временно изменить поведение:

   sysctl -w net.ipv4.conf.all.rp_filter=2
   sysctl -w net.ipv4.conf.default.rp_filter=2
   

3. Постоянно через /etc/sysctl.conf:

   net.ipv4.conf.all.rp_filter=2
   net.ipv4.conf.default.rp_filter=2
   

❗️ Когда применять:
Если используется policy-based routing, мульти-хоминг или VPN с отдельными маршрутами — strict режим (1) может ломать соединения.

💡Используйте 2 для loose проверки, если трафик приходит по одному интерфейсу, а уходит через другой.

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

🎉Коллеги, всех причастных с праздником!!!

Желаю, чтобы начальство думало о тебе не только тогда, когда “ничего не работает”.

👉 @linux_odmin

🔥 Bash-скрипт: Поиск больших файлов в системе

Когда место на сервере внезапно заканчивается, найти "пожирателей" места бывает непросто. Вот простой скрипт, который покажет топ-20 самых больших файлов:

#!/bin/bash

# Где искать (по умолчанию — весь /)
SEARCH_DIR="/"

# Сколько файлов показывать
TOP=20

echo "=== Топ-$TOP самых больших файлов в $SEARCH_DIR ==="
find "$SEARCH_DIR" -type f -printf '%s %p\n' 2>/dev/null | sort -nr | head -n $TOP | awk '{printf "%10d MB  %s\n", $1/1024/1024, $2}'

Как использовать:

1. Сохраните в /usr/local/bin/bigfiles.sh.
2. Сделайте исполняемым:

   chmod +x /usr/local/bin/bigfiles.sh
   

3. Запускайте, например:

   /usr/local/bin/bigfiles.sh
   

#Linux@linux_odmin #Github@linux_odmin

👉 @linux_odmin

💡 Как я ускоряю поиск по логам в Linux

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

Представим, что нужно найти ошибки в большом лог-файле, например /var/log/nginx/access.log. Обычно все начинают с:

cat access.log | grep "500"

Но это медленно. Лучше так:

grep "500" access.log

Ещё лучше — использовать less и внутри него grep-подобный поиск:

less +F access.log

А затем нажать /500 — и перейти по найденным совпадениям. Работает быстро, особенно на больших логах.

А если хочется реального профита, то вот мой любимый трюк:

grep -E "500|502|503" access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

Что делает эта команда:
- Ищет ошибки 500/502/503
- Извлекает IP-адреса (предположим, это первое поле)
- Считает, сколько раз каждый IP дал ошибку
- Показывает топ атакующих/плохих клиентов

Эта команда — мини-аналитика в одну строку. Часто помогает сразу понять, где проблема.


#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🚀 Netplan: быстрая настройка второго IP на интерфейсе

Нужно добавить второй адрес без простоя? Netplan справится за пару секунд.

1. Редактируем конфиг:

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    ens33:
      addresses:
        - 192.168.1.10/24
        - 192.168.1.20/24   # ← второй IP
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

2. Применяем изменения без перезагрузки:

netplan apply

3. Проверяем:

ip a show ens33

Зачем так?
– Удобно для быстрого тестирования сервисов.
– Применяется атомарно (не рвёт соединения).
– Работает одинаково в Ubuntu/Debian с Netplan.

⚠️ Трюк: можно применить временно:

netplan try

- изменения откатятся, если не подтвердить за 120 сек.

Сохрани себе — выручит, когда надо быстро поднять доп. IP без рестарта сети.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

ss вместо netstat: быстрое выявление зависших соединений

netstat устарел, а вот ss работает быстрее и даёт больше деталей.
Полезно, когда сервер "подвис" на куче TCP-сессий.

Базовые приёмы:

1. Все активные TCP-соединения:

ss -tuna

(-t TCP, -u UDP, -n без DNS, -a все сокеты)

2. Сортировка по количеству соединений с IP:

ss -tan | awk '{print $6}' | sort | uniq -c | sort -nr | head

→ Быстро видим топ-источники трафика.

3. Состояния TCP (например, зависшие TIME-WAIT):

ss -tan state time-wait

4. Отбор по порту:

ss -tan sport = :443

Зачем?
– Диагностика DDoS / "залипших" коннектов.
– Поиск проблемных клиентов.
– Быстрая альтернатива netstat без лишних зависимостей.

👉 ss -p — сразу показывает PID процесса, владеющего сокетом.

Проверь свой сервер — удивишься количеству "мертвых" коннектов.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin

🚀 Быстрый способ ограничить скорость на интерфейсе с tc

Иногда нужно временно урезать пропускную способность - тест, симуляция плохого канала, защита от перегрузки. Делается это без лишних пакетов - встроенным Traffic Control.


Пример: ограничим eth0 до 10 Мбит/с

# Очистить старые правила
tc qdisc del dev eth0 root 2>/dev/null

# Добавить qdisc с ограничением
tc qdisc add dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms

🔹 rate - целевая скорость.
🔹 burst - размер «рывка» (буфер), лучше 2–3× MTU.
🔹 latency - допустимая задержка очереди.


📌 Проверка:

tc -s qdisc show dev eth0

📌 Сброс:

tc qdisc del dev eth0 root

💡 Когда полезно:

- тестирование поведения приложений при низкой скорости;
- эмуляция 3G/4G-сетей;
- временное сдерживание исходящего трафика при ddos/backup.

Сохрани, пригодится.

#Linux@linux_odmin #LinuxTips@linux_odmin #Команды@linux_odmin

👉 @linux_odmin