[Перевод] Нет – взломам серверов! Советы по проверке и защите

Подозреваете, что Linux-сервер взломан? Уверены, что всё в порядке, но на всякий случай хотите повысить уровень безопасности? Если так — вот несколько простых советов, которые помогут проверить систему на предмет взлома и лучше её защитить.
image


Проверка


Для того, чтобы узнать, не взломали ли ваш сервер, скажем, работающий под управлением Ubuntu, стоит кое-что проверить.

▍Данные последнего входа в систему


Выясните данные последнего входа в систему. Делается это с помощью команды lastlog.
$>lastlog

▍История команд


Взгляните на историю команд, узнайте, когда именно их вводили:
$>history

Если список команд выводится без даты — настройте соответствующие параметры утилиты history.

▍Журнал auth.log


Следующий способ проверки — просмотр файла /var/log/auth.log. Например, с помощью такой команды:
$>sudo vi /var/log/auth.log

Здесь можно найти список всех, кто пытался подключиться к серверу по SSH.

▍IP-адреса


Для того, чтобы выяснить IP-адреса, с которых подключались к серверу, воспользуйтесь такой командой:
$>zgrep sshd /var/log/auth.log* | grep rhost | sed -re 's/.*rhost=([^ ]+).*/\1/' | sort –u

▍Журналы Apache


Проверьте журналы Apache:
$>sudo vi /var/log/apache2/access.log
$>sudo vi /var/log/apache2/error.log

▍Поиск подозрительных процессов


Если вы уверены в том, что сервер взломан, разыщите процесс злоумышленника. Например, список всех процессов можно получить такой командой:
$>ps aux | less

▍Список заданий cron


Анализируя сервер на предмет взлома, полезно будет проверить список заданий cron, в который злоумышленник вполне мог добавить что-то своё.
$>crontab -l | grep -v ‘^#’

Независимо от того, выявила ли проверка попытки взлома, безопасности много не бывает. Поэтому вот — несколько советов по защите сервера.

Защита


Рекомендации по защите сервера, в основном, касаются отслеживания и блокирования подозрительной активности, а также регулярного обновления программного обеспечения.

▍Запрет входа root-пользователей по SSH


Для повышения уровня безопасности сервера стоит запретить вход root-пользователей по SSH.
$>sudo vi /etc/ssh/sshd_config
PermitRootLogin no

▍Автоматические обновления


Включите автоматические обновления безопасности с использованием пакета unattended-upgrades. Сначала его надо установить:
$>sudo apt-get install unattended-upgrades

Следующий шаг — настройка:
$>sudo dpkg-reconfigure -plow unattended-upgrades

Пакет можно вызвать и самостоятельно:
$>sudo unattended-upgrade

▍Настройка блокировок


Установите пакет fail2ban. Для того, чтобы блокировать с его помощью подозрительных SSH-пользователей, воспользуйтесь этим руководством, поле чего настройте систему отчётов.
Для того, чтобы узнать, сколько раз fail2ban заблокировал некий IP-адрес, воспользуйтесь такой командой:
$>sudo awk '($(NF-1) = /Ban/){print $NF}' /var/log/fail2ban.log | sort | uniq -c | sort –n

Для того, чтобы просмотреть весь файл журнала fail2ban, введите следующее:
$>sudo zgrep -h "Ban "/var/log/fail2ban.log* | awk '{print $NF}' | sort | uniq –c

Для поиска проблемных подсетей подойдёт такая команда:
$>sudo zgrep -h "Ban " /var/log/fail2ban.log* | awk '{print $NF}' | awk -F\. '{print $1"."$2"."}' | sort | uniq -c | sort -n | tail

Если анализ файлов журнала показывает, что атаки из некоторой подсети происходят регулярно, её можно заблокировать на постоянной основе. Перед этим, однако, стоит проверить, к какой стране принадлежит подсеть.

Например, вот как заблокировать подключения к sshd-порту из подсети 221.229.*.*:

$>sudo iptables -I INPUT -p tcp -s 221.229.0.0/255.255.0.0 --dport ssh -j REJECT --reject-with tcp-reset

Для того, чтобы узнать о том, что именно было заблокировано правилами iptables, можно воспользоваться такой командой:
$>sudo iptables -vnL INPUT --line-numbers

Для того, чтобы правила iptables сохранялись после перезагрузки сервера, установите в Ubuntu пакет iptables-persistent.
$>sudo apt-get install iptables-persistent
$>cat /etc/iptables/rules.v4

Если вы отредактировали правила iptables, используйте такую команду:
$>sudo bash -c "iptables-save  > /etc/iptables/rules.v4"

Файл с правилами не рекомендуется править вручную, так как его формат важен для того, чтобы всё работало как надо.

Итоги


Мы рассказали о методах проверки Linux-серверов на предмет взлома и об улучшении их защиты. Надеемся, наши советы помогут вам повысить уровень информационной безопасности ваших систем.

Комментарии (4)

  • 1 ноября 2016 в 16:27

    +1

    А почему для просмотра логов vi, а не less?
    • 1 ноября 2016 в 16:37

      0

      Чтобы сразу удалить за собой следы.
    • 1 ноября 2016 в 16:39

      0

      Да уж. Вообще, вот такие пассажи
      >>sudo vi /var/log/apache2/access.log
      ставят компетентность автора оригинального текста под сомнение.
  • 1 ноября 2016 в 17:05

    0

    Подозреваете, что Linux-сервер взломан?

    wipe, re-image.


    Нет никаких других вариантов. Злоумышленник уже мог пропатчить ядро и спрятать зловредные процессы. При чем, мог это сделать даже и без перезагрузки, если ksplice включен.

© Habrahabr.ru