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

Original author: Abangkis Pribadi
  • Translation
Подозреваете, что 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-серверов на предмет взлома и об улучшении их защиты. Надеемся, наши советы помогут вам повысить уровень информационной безопасности ваших систем.
RUVDS.com
894.21
RUVDS – хостинг VDS/VPS серверов
Share post

Comments 43

    +4
    А почему для просмотра логов vi, а не less?
      0
      Чтобы сразу удалить за собой следы.
      • UFO just landed and posted this here
          +2

          Интересно, как долго у меня будет открываться вечером apache.log размеров в пару гигабайт на один виртуалхост?.. и через сколько я в соседней консоли этот vim прибью.


          Пополнил свою коллекцию вредных советов.
          Интересно, с сервисом у компании так же, как с этим постом?

            0
            Интересно, зачем держать лог в пару гигабайт, когда давно придумали logrotate? Попробуйте, говорят, помогает
            • UFO just landed and posted this here
                0
                Всё равно гигабайтные логи это не дело.
                Всегда можно например писать не общий лог домена, а каждому location сделать свой файл.
                • UFO just landed and posted this here
                    0

                    Хорошо, у меня на каждом сервере шаредхостинга — несколько сот клиентов, у каждого от одного до десятка сайтов на жумлах, битриксах и прочих вордпрессах. на некоторые сайты госорганизаций, учебных заведений и просто достаточно большие порталы собирается под гигабайт логов в сутки.


                    Как вы себе представляете работу инженера поддержки, которому приходит тикет на "у меня тут вот на сайте что-то не работает", и как Вы себе представляете моё предложение клиентам разбить логи на location, например, в плеске, cpanel или даже просто, средствами обычного вордпресса? и работу саппорта в таком режиме "найти бог знает что в бог знает каком логе для воот этого домена"

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

          wipe, re-image.


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

            0
            И неплохо бы еще биос проверить :)
              0

              Таки да, я хотел написать, но решил не усложнять :-)

              0
              ksplice облегчает дело, но он не обязателен. Если у злоумышленника есть возможность загружать свои модули в ядро — всё, тушите свет. Если есть доступ к /dev/mem, /dev/kmem — тоже тушите свет.
                0

                согласен.

              0
              А можно тоже самое, только для windows?
                +7
                А что — уже каникулы?
                  0
                  Сегодня вроде как начались.
                    +1
                    Ну тогда нормальный пост, как школьникам с хоумпэйджами на vps защититься от других школьников
                  +1
                  Смените порт SSH
                    +1
                    И какой цели это волшебство послужит, особенно в свете того, что уже установлен fail2ban, и тупые боты не мешают. А не тупых и не ботов смена порта не запутает ни сколько…
                      +2
                      Смена порта помогает от засорения логов записями о блокировке тупых ботов. Чистые логи читать приятнее.
                      • UFO just landed and posted this here
                          0
                          Сегодня бот- а завтра? А если вирус на компьютере ни в чём ни повинного пользователя? А 1000 пользователей за натом?
                          В общем не панацея, так с водой и ребёнка выплеснуть можно.
                          • UFO just landed and posted this here
                              0
                              Я лично пока баню только ssh.

                              Тогда нормально. Я уж думал, вообще все пакеты от них дропаете.
                      +3
                      Вроде такой солидный человек, в костюме, что то там про безопасность пишет/переводит и такой совет… да я покурить не успею пока сканер найдёт нестандартный ssh порт. как правильно ниже говорят — fail2ban, ключи и/или сложные пароли — вот отличный вариант, а не порт менять.
                      • UFO just landed and posted this here
                          0
                          И это правильно, курить вредно
                          • UFO just landed and posted this here
                            • UFO just landed and posted this here
                          +1
                          Как показал мой личный опыт, смена порта sshd на нестандартный на порядки уменьшило в логах auth.log кол-во записей. Это помогает отсеивать не целенаправленные атаки.
                        –1
                        Теперь ясно что ни за что не стоит брать вдс в этой компании.
                          0
                          Почему? Цены у них нормальные, но вот защита от ддос атак — мало верю.
                          0
                          Нормальный мануал для начинающих, поможет в свое время
                            +2

                            Добавлю советов и я:


                            • сменить порт ssh. Как ни возмущались бы выше, но большая часть взломов — это автоматические сканеры уязвимостей. другой порт -> меньше попыток взлома -> меньше шанс словить свежий эксплойт.
                            • отключить аутентификацию по паролю и использовать только аутентификацию по ключам. Хранить приватный ключ в зашифрованном виде. Это сделает бессмысленным брутфорс и кражу приватных ключей с машины администратора.
                            • (для параноиков) добавить в sshd двухфакторную аутентификацию по TOTP
                            • (для рисковых параноиков) настроить на сервере файрволл, чтобы он разрешал подключения по SSH только с ваших IP адресов.
                              0
                              Вопрос по проверке cron'а, что делать, если злоумышленник менял не пользовательскую конфигурацию, а системную? А если и пользовательскую, но создал еще одного root'а? А если изменил login shell для любого системного пользователя (плюс добавил пароль, разумеется), добавил его в sudoers и таким образом имеет backdoor с root'ом? Также, он мог банально повесить SUID-бит на /bin/bash, либо положить wrapper для оболочки с этим битом, чтобы иметь root'а при логине под любым пользователем.

                              Собственно, исходя из этого на мой взгляд нужно как минимум:
                              • Ежедневно проверять список файлов с SUID-битом (интересно, но во FreeBSD есть periodic-задание для этого)
                              • Проверять не crontab -l, а /var/spool/cron, /etc/crontab и /etc/cron.*
                              • Регулярно проверять изменения в /etc/passwd, возможно даже настроить мониторинг на изменение этого файла (по дефолту в zabbix'е есть даже триггер на это)
                              • Проверять /etc/sudoers
                              • Диски, на которые происходит заливка файлов с внешнего мира, монтировать с флагами nosuid и noexec
                                0
                                Нужно исходить из того, что если злоумышленник получил рута хоть на 5 секунд — вы больше не контролируете систему. Потому что уже руткит уже загружен прямо в ядро и вы никогда даже не узнаете о его существовании.
                                stat() будет показывать правильные права для нужных файлов, никаких лишних записей в /etc/passwd вы не увидите, в /proc/ тоже не будет видно лишних процессов и т.д. И при этом машина будет вовсю DDOSить кого-нибудь и рассылать спам в промежутках между атаками.

                                Разве что физически снимете винчестер, подключите его к другой системе и очень детально проанализируете данные (не файлы!) на нём. Тогда да, вы сможете понять что машина была заражена.
                                А это мы ещё не затрагивали UEFI. Вирус в биосе — это больше не фантастика.
                                  0
                                  Это само собой разумеющееся, я всего-навсего немного развил мысли автора, не сильно углубляясь. Понятное дело, что при должном уровне паранойи необходимо заново поднимать сервер в такой ситуации.
                                0
                                Еще рекомендую делать «rpm -V» — сверяет контрольные суммы файлов на диске с эталонными. Можно смотреть какие конфиги или бинарники изменлись.
                                • UFO just landed and posted this here
                                    0
                                    Мне мое знание помогало пару раз найти атаки. А Вам ваше знание помогло?
                                • UFO just landed and posted this here
                                    0
                                    я тоже не понял вас. предлагаю закончить диспут

                                  Only users with full accounts can post comments. Log in, please.