Сколько раз бывало: "Где лежит этот конфиг? А в каком файле та самая строка?" — и понеслась лихорадочная проверка /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

💡 Как я ускоряю поиск по логам в 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

🔐 Защищаем SSH с помощью Fail2Ban

Всем привет! 👋 Сегодня поговорим о базовой, но крайне важной утилите для защиты вашего сервера - Fail2Ban. Если у вас есть сервер с доступом по SSH, этот пост для вас.

Что такое Fail2Ban?

Fail2Ban — это утилита, которая анализирует логи служб (например, SSH, Apache, Nginx) на предмет подозрительной активности, такой как многократные неудачные попытки входа. При обнаружении нарушителя (бота или злоумышленника), Fail2Ban автоматически блокирует его IP-адрес на определённое время с помощью файрвола.

Как это защищает SSH?

Основная угроза для SSH - это брутфорс-атаки (атаки перебором), когда боты пытаются подобрать ваш пароль, пробуя тысячи комбинаций. Fail2Ban эффективно противостоит этому:

1. Мониторинг логов: Он постоянно следит за файлом /var/log/auth.log (или аналогом в вашей системе).
2. Обнаружение аномалий: Если с одного IP-адреса поступает, скажем, 5 неудачных попыток входа подряд, Fail2Ban это замечает.
3. Блокировка: Утилита мгновенно добавляет правило в файрвол (например, iptables или ufw), которое блокирует этот IP-адрес.
4. Снятие блокировки: Через заданное время (например, 10 минут или час) IP-адрес автоматически разблокируется.

Быстрая настройка для SSH (на примере Debian/Ubuntu)

Настроить базовую защиту очень просто:

1. Установка:

    sudo apt update
    sudo apt install fail2ban
    

2. Создание локального конфигурационного файла:
Никогда не редактируйте jail.conf! Создайте его копию jail.local, чтобы ваши настройки не перезаписались при обновлении.

    sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
    

3. Настройка jail.local:
Откройте файл sudo nano /etc/fail2ban/jail.local и найдите секцию [sshd]. Убедитесь, что она включена:

    [sshd]
    enabled = true
    

Вы можете изменить стандартные параметры, например:

- maxretry = 5 - количество неудачных попыток до бана.
- bantime = 10m - время блокировки (10 минут).
- findtime = 10m - временное окно, в течение которого считаются попытки.

4. Перезапуск службы:

    sudo systemctl restart fail2ban
    

5. Проверка статуса:
Чтобы увидеть, заблокировал ли Fail2Ban кого-нибудь, используйте команду:

    sudo fail2ban-client status sshd
    

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

👉 @linux_odmin

nftables без fail2ban: динамический бан брутфорса SSH (IPv4/IPv6)

Задача: быстро отстреливать источники, ломающие ssh, без демонов и лог-парсеров. Решение - динамический set с таймаутом + правило, которое само добавляет нарушителя.

Шаги

1. Создаём таблицу, набор и цепочку:

sudo nft -f - <<'EOF'
table inet fw {
  set ssh_bad {
    type inet_addr
    flags timeout
    timeout 1h      # дефолт для элементов
  }

  chain input {
    type filter hook input priority 0; policy accept;

    iif lo accept
    ct state established,related accept

    # уже занесённых — вон:
    ip saddr @ssh_bad drop

    # детект частых новых соединений на 22/tcp и бан + дроп:
    tcp dport 22 ct state new limit rate over 10/minute \
      add @ssh_bad { ip saddr timeout 2h } counter drop
  }
}
EOF

2. Ручное управление бан-листом (админ-бан/разбан):

sudo nft add element inet fw ssh_bad { 203.0.113.5 timeout 24h comment "manual" }
sudo nft delete element inet fw ssh_bad { 203.0.113.5 }

3. Наблюдение за изменениями сета (для отладки):

sudo nft monitor set

4. Персистентность (Debian/Ubuntu/RHEL/Alma):

# Проверь синтаксис и атомарно загрузись
sudo nft -c -f /etc/nftables.conf && sudo nft -f /etc/nftables.conf
sudo systemctl enable --now nftables

совет: вынеси блок в /etc/nftables.d/ssh-ban.nft и подключи include в /etc/nftables.conf.

Зачем и когда

- Базовая защита от брутфорса без сторонних сервисов.
- Подходит для edge/VM/контейнер-хостов, где не нужен полный fail2ban.
- Работает в family inet → одна логика и для IPv4, и для IPv6.

Трюки / best practices

- limit rate over срабатывает только при превышении порога - нормальные пользователи не пострадают.
- Не делай flush table inet fw в бою: обнулятся текущие баны (timeouts). Обновляй правила точечно (nft -a list ruleset, затем delete rule handle … / add rule …) или проверяй конфиг -c перед загрузкой.
- Для нестандартных портов поменяй tcp dport 22 на свой.

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

👉 @linux_odmin