🔥 Как быстро сбросить 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

🔥 iptables: быстрое логирование и дроп подозрительных пакетов

Иногда нужно понять, что именно ломится в сервер, но без спама в dmesg.

Минимальный рабочий набор:

# 1. Создаём цепочку для логирования
sudo iptables -N LOG_DROP

# 2. Логируем с ограничением частоты (1 сообщение/сек)
sudo iptables -A LOG_DROP -m limit --limit 1/second -j LOG \
  --log-prefix "[FW DROP] " --log-level 4

# 3. Дропаем пакет
sudo iptables -A LOG_DROP -j DROP

# 4. Применяем к подозрительному трафику (пример: TCP 23)
sudo iptables -A INPUT -p tcp --dport 23 -j LOG_DROP

Где смотреть логи:

- journalctl -k -f
- или /var/log/kern.log (Debian/Ubuntu)

💡 Best practice:

- Используйте -m limit, чтобы не утопить систему в логах
- Для массового анализа можно отправлять в rsyslog с отдельным тегом

Сохрани — пригодится, если нужно быстро вычислить мусорный трафик и отрезать его 🚫

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

👉 @linux_odmin

🚀 Быстрый контроль за соединениями через ss

Когда нужно понять, кто держит соединение, какой порт занят или где «течёт» трафик — ss быстрее и информативнее, чем устаревший netstat.

Пример: найти все процессы, слушающие порты TCP

ss -ltnp

-l — только прослушивающие сокеты
-t — TCP
-n — не пытаться резолвить имена
-p — показать PID/имя процесса

Активные установленные соединения:

ss -tn state established

Отфильтровать по порту:

ss -tn sport = :443

💡 ss может фильтровать по состояниям, адресам и портам прямо в команде — это экономит время при отладке сетевых проблем и поиске подозрительных подключений.

Когда применять:

- диагностика зависших сервисов
- поиск «висящих» соединений
- аудит входящих/исходящих подключений

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

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

👉 @linux_odmin

🔥 net.ipv4.conf.all.rp_filter - твой тихий телохранитель от IP spoofing

Многие админы забывают, что rp_filter в Linux может спасти от подмены IP пакетов, но при кривой настройке ломает сложные маршруты.

Проверка:

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

Значения:

- 0 - фильтр выключен
- 1 - строгий режим (пакет отбрасывается, если обратный маршрут не совпадает с интерфейсом входа)
- 2 - «loose mode» (разрешает асимметричную маршрутизацию, но всё ещё фильтрует spoof)

Безопасная настройка для большинства серверов:

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

Для сложных схем с несколькими WAN:

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

Применить навсегда:

cat >> /etc/sysctl.conf <<EOF
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1
EOF
sysctl -p

💡 Когда включать strict (1) - одиночный WAN, простая маршрутизация.
💡 Когда loose (2) - мульти-WAN, policy routing, сложные VPN-топологии.

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

👉 @linux_odmin