🖥 Вредоносное ПО в Linux

Штатные утилиты для обнаружения и обезвреживания вредоносов.

💬Процессы и автозапуск

ps / pgrep / top / htop — ищем «левые» процессы, аномальный расход CPU/RAM.

ps aux --sort=-%cpu | head        # топ-«прожорливые» по CPU
ps aux --sort=-%mem | head        # топ по памяти
pgrep -a -f "curl|wget|perl|php"  # процессы, часто встречающиеся в малвари

systemctl / service — неизвестные юниты/демоны в автозапуске.

systemctl list-unit-files --type=service | grep enabled
systemctl status suspicious.service

💬Сеть и соединения

ss / netstat — кто слушает порты и куда установлены сессии.

ss -lptn                               # слушающие порты + PID/процессы
ss -tp 'state established'             # активные TCP-сессии

lsof — какие процессы держат файлы/сокеты, в т.ч. «удалённые» бинарники.

sudo lsof -i
sudo lsof +L1 | head                   # запущенные, но удалённые файлы

💬Файлы, изменения и права

grep — быстрый поиск характерных паттернов.

grep -R --line-number -E 'base64_decode|eval\(|system\(|shell_exec\(' /var/www 2>/dev/null

lsattr / chattr — проверка «immutable»-атрибута.

sudo lsattr -R /var/www
# при необходимости снять:
# sudo chattr -i /path/to/file

💬Логи и следы взлома

last / lastb / w — логины и неудачные попытки.

last | head
sudo lastb | head
w

💬Учётные записи и ключи

/etc/passwd — двойные UID 0, «левые» системные пользователи. authorized_keys — подмена ключей.

awk -F: '($3==0){print}' /etc/passwd
sudo grep -R -n '' /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null

💬Шаги реагирования

Остановить подозрительный сервис/процесс:

sudo systemctl stop suspicious.service
sudo kill -9 <PID>

Запретить автозапуск и убрать юнит:

sudo systemctl disable --now suspicious.service
sudo rm -f /etc/systemd/system/suspicious.service
sudo systemctl daemon-reload

Удалить «крюк» в cron/профилях, вернуть права/атрибуты, очистить временные каталоги.

#линуксятина

Сейчас Вероника рассказывает про кейсы обработки ПДН на реальных примерах.

Присоединяйтесь 🥳

👉 ПРЯМАЯ ТРАНСЛЯЦИЯ

🤗 Спасибо всем за участие в мероприятии!

Вероника еще успела дать мини интервью 🥰

В завершение темы персональных данных мы собрали подборку статей с подсказками и разъяснениями:

✅ Что смотрит Роскомнадзор при проверках
✅ Биометрия, политика обработки, оценка эффективности.
✅ Персональные данные медицинских организаций
✅ Персональные данные на сайте компании: главные правила

Video by: Медиа.Hub

❤️ Пропустили выступление Вероники?

На следующей неделе будет сразу два шанса!

💎15 октября. Форум ITSEC*

Тема: «152-ФЗ без простоев: один контур защиты для ритейла, медицины и финансов»

💎16 октября. ГАРДА. Сохранить ВСЁ*

Тема: «Гибридные угрозы: кибершпионаж, дезинформация, саботаж»

*Регистрация и условия участия ищите на официальных сайтах мероприятий.

🤭 Вот так бы откатить понедельник до субботы ...

— лишь бы таймлайн не зациклить 😳

P.S. С началом трудовой недели

🔥 Пожар в дата-центре Южной Кореи: данные гос-облака безвозвратно утрачены

В конце сентября в ДЦ NIRS в Тэджоне сгорели 96 критичных систем, а облачное хранилище G-Drive — уничтожено: внешних резервных копий не было, копии в том же контуре погибли вместе с системой.

За последние 5 лет было несколько показательных катастроф с потерей данных и простоями:

🔥 Страсбург, OVHcloud в марте 2021. Пожар на кампусе SBG уничтожил часть инфраструктуры; у клиентов — утраты данных, совокупные требования по искам — > €10 млн. Среди пострадавших публично отчиталась и российская компания — её бэкапы лежали рядом с продом и сгорели вместе с ним.

🔥 Париж, Google Cloud europe-west9 в апреле 2023. Протечка воды в здании подрядчика попала в зал источников бесперебойного питания (ИБП), вызвала возгорание и многочасовое отключение одного из зданий региона; у клиентов с данными и снапшотами в одной зоне часть дисков оказалась невосстановимой.

💀 Дания, CloudNordic/AzeroCloud в августе 2023. Атака ransomware (вымогатель-шифровальщик) задела инфраструктуру и бэкапы в том же контуре — провайдер сообщил, что у большинства клиентов утрачены все данные.

⚡️ Бэкап сам по себе — не стратегия: он может сгореть вместе с продом, не влезть в окно RTO или стоить как крыло от самолёта.

Лучше соблюсти баланс между надёжностью (что поднимется и когда) и выгодностью (сколько это стоит), с регулярными тест-ресторами для подтверждения готовности и минимизацией затрат за счёт архитектуры хранения (offsite/immutable, разнесённые контуры, lifecycle-политики).

🥂 Такая схема переживёт пожар, потоп и шифровальщика — и не разорит бюджет.

🖥 Надёжный способ бэкапа PostgreSQL

pg_dump — утилита для создания логических бэкапов PostgreSQL.

В отличие от физического бэкапа, она выгружает объекты (схемы/данные) в переносимый вид. Дамп, как правило, корректно восстанавливается в такую же или более новую версию Postgres.

✅ Основные сценарии

Бэкап одной базы (plain SQL)

pg_dump mydb > backup.sql

Бэкап с компрессией «на лету» (для plain)

pg_dump mydb | gzip > backup.sql.gz

То же, но со встроенной компрессией (для custom/tar/directory)

pg_dump -Fc -Z 9 mydb > backup.dump

Только схема без данных:

pg_dump -s mydb > schema_only.sql 
# или выборочно по схемам: 
pg_dump -s -n public -N audit mydb > schema_public.sql

Бэкап конкретной таблицы:

pg_dump -t public.users mydb > users_backup.sql 
# исключение таблиц: 
pg_dump -T public.logs mydb > no_logs.sql

Параллельный бэкап (работает только с -Fd)

pg_dump -Fd /backups/mydb_$(date +%F) -j 4 mydb

Бэкап всего кластера (все БД + роли/табл.пространства)

pg_dumpall > all_databases.sql 
# только «глобалы» (роли, табличные пространства): 
pg_dumpall -g > globals.sql

Удаляем бэкапы старше 7 дней (недавний пост про find)

find /backups -type f -name "*.sql.gz" -mtime +7 -delete

👀 Дополнительно

-Fc — custom-формат: компактно, выборочное и параллельное восстановление через pg_restore.

-Fd — directory-формат: поддерживает параллельный дамп (-j) и гибкое восстановление.

--no-owner --no-privileges — удобно для переноса между серверами/окружениями.

--exclude-table-data=... — дамп схем без данных отдельных «тяжёлых» таблиц.

⚙️ pg_dump делает снапшот на момент старта дампа, поэтому данные консистентны даже при параллельных транзакциях. Это достигается через механизм MVCC PostgreSQL.
Необходимо учесть, что логические дампы не подходят для PITR — для этого нужны физические бэкапы + WAL.

🔘 Связка pg_dump(-Fc/-Fd) [| gzip] + find -delete — простой и надёжный пайплайн. Но периодически проверяйте восстановление на тестовом стенде и следите за версиями сервера/клиента.

#заметкиИнженера