Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:
В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.
Итак, первым делом меняем рутовый пароль:
Далее сканируем хост на предмет подозрительных открытых портов. Сделать это можно, например, с другой юниксовой машины с помощью утилиты nmap:
В этом списке подозрительно выглядели 111 и 620 порты, поэтому далее смотрим, кто их слушает:
Тут оказалось всё в порядке, так как это были компоненты nfs. Далее проверяем UDP соединения:
Тут тоже всё оказалось в порядке. Попасть на сервер, скорее всего могли не через консоль, так как при логине на сервер Centos писал, что последний логин был с моего IP. Поэтому следующим пунктом нужно проверить фолдер /root/.ssh, туда могли положить ключ для ssh-клиента каким-либо образом.
Здесь оказался только файл с ключами, который я переименовал сразу после передачи хоста провайдером. Далее нужно проверить файл /etc/passwd. В нём не должно быть пользователей с uid=0, кроме root:
И тут тоже было всё окей. Финальным аккордом являлась проверка хоста на установленные руткиты. Для этого можно использовать бесплатную утилиту rkhunter. Скачиваем архив с последней версией, распаковываем его и запускаем инсталлер. Далее делаем его обновление и запускаем проверку:
Rkhunter в начале проверят важные системные файлы, затем ищет руткиты. После происходит проверка на различные vulnerabilities. В конце программа проверяет версии популярных продуктов, таких как Apache, OpenSSH и т.п. на предмет последних версий.
Результаты своей работы rkhunter выдает в консоль, а также формирует консолидированный лог /var/log/rkhunter.log. Можно запускать данный антируткит каждый день по крону и получать отчет о сканировании по электронной почте.
К счастью, rkhunter не обнаружил на моём сервере никаких зловредов, это позволило успокоиться и подумать, что же за странные инсталлы произошли на сервере. И тут я вспомнил, что сразу после получения сервера, я установил и сконфигурировал на этом сервере VPN сервер. Видимо, произошла какая-то ошибка в Logwatch и он добавил в отчёт данные двухлетней давности.
Разумеется, если злоумышленники всё сделают грамотно, то Logwatch никаких следов не обнаружит и хозяин сервера долго ни о чём не будет подозревать. Однако, шаги, описанные в данном HowTo, если проводить их регулярно, помогут уберечь ваши сервера от компроментации.
На Centos есть стандартный анализатор логов Logwatch, который запускается ежедневно по крону, анализирует содержимое /var/log, делает сводный отчет и присылает его по электропочте. В один прекрасный день я обнаружил в этом отчете запись:
--------------------- yum Begin ------------------------
Packages Installed:
lzo2 - 2.02-3.el5.rf.i386
dnstracer - 1.8-1.2.el5.rf.i386
openvpn - 2.0.9-1.el5.rf.i386
---------------------- yum End -------------------------
В тот момент меня она очень смутила, так как в предыдущий день на сервер я не логинился и тем более ничего не устанавливал. Первое, что пришло в голову — сервер был скомпроментирован. Себя я считал уверенным пользователем Linux, однако я растерялся. Благо в тот момент в icq был мой бывший коллега, лучший системный администратор, которого я знаю, и просто очень хороший человек.
Он помог быстро проверить систему. В результате у меня сформировалось краткое HowTo о том, как быстро проверить свой сервер на предмет взлома. Уверен, что многим Храброчитателям оно будет полезно. Предполагается, что пользователь знаком с консолью Linux/Unix.
Итак, первым делом меняем рутовый пароль:
[root@myhost etc]# passwd Changing password for user root. New UNIX password: ...
Далее сканируем хост на предмет подозрительных открытых портов. Сделать это можно, например, с другой юниксовой машины с помощью утилиты nmap:
[root@myhost ~]# nmap -P0 123.123.123.123 Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2011-01-23 11:47 MSK Interesting ports on myhost.myprovider.net (123.123.123.123): Not shown: 1679 filtered ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 53/tcp open domain 80/tcp open http 106/tcp open pop3pw 110/tcp open pop3 111/tcp open rpcbind 135/tcp filtered msrpc 136/tcp filtered profile 137/tcp filtered netbios-ns 138/tcp filtered netbios-dgm 139/tcp filtered netbios-ssn 143/tcp open imap 443/tcp open https 445/tcp filtered microsoft-ds 465/tcp open smtps 620/tcp open unknown 993/tcp open imaps 995/tcp open pop3s 3306/tcp open mysql 8443/tcp open https-alt
В этом списке подозрительно выглядели 111 и 620 порты, поэтому далее смотрим, кто их слушает:
[root@myhost ~]# netstat -anp | grep LISTEN | grep 620 tcp 0 0 0.0.0.0:620 0.0.0.0:* LISTEN 1710/rpc.statd
[root@myhost ~]# netstat -anp | grep LISTEN | grep 111 tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1685/portmap
Тут оказалось всё в порядке, так как это были компоненты nfs. Далее проверяем UDP соединения:
[root@myhost ~]# netstat –anp | grep udp udp 0 0 0.0.0.0:32773 0.0.0.0:* 2345/named udp 0 0 127.0.0.1:32780 127.0.0.1:32780 ESTABLISHED 2539/postmaster udp 0 0 0.0.0.0:32783 0.0.0.0:* 2790/avahi-daemon: udp 0 0 123.123.123.123:53 0.0.0.0:* 2345/named udp 0 0 123.123.123.123:53 0.0.0.0:* 2345/named udp 0 0 127.0.0.1:53 0.0.0.0:* 2345/named udp 0 0 0.0.0.0:614 0.0.0.0:* 1710/rpc.statd udp 0 0 0.0.0.0:5353 0.0.0.0:* 2790/avahi-daemon: udp 0 0 0.0.0.0:617 0.0.0.0:* 1710/rpc.statd udp 0 0 0.0.0.0:111 0.0.0.0:* 1685/portmap udp 0 0 0.0.0.0:631 0.0.0.0:* 2069/cupsd udp 0 0 :::32774 :::* 2345/named udp 0 0 :::32784 :::* 2790/avahi-daemon: udp 0 0 :::5353 :::* 2790/avahi-daemon:
Тут тоже всё оказалось в порядке. Попасть на сервер, скорее всего могли не через консоль, так как при логине на сервер Centos писал, что последний логин был с моего IP. Поэтому следующим пунктом нужно проверить фолдер /root/.ssh, туда могли положить ключ для ssh-клиента каким-либо образом.
[root@myhost ~]# dir /root/.ssh authorized_keys_
Здесь оказался только файл с ключами, который я переименовал сразу после передачи хоста провайдером. Далее нужно проверить файл /etc/passwd. В нём не должно быть пользователей с uid=0, кроме root:
[root@myhost ~]# cat /etc/passwd | more root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync …
И тут тоже было всё окей. Финальным аккордом являлась проверка хоста на установленные руткиты. Для этого можно использовать бесплатную утилиту rkhunter. Скачиваем архив с последней версией, распаковываем его и запускаем инсталлер. Далее делаем его обновление и запускаем проверку:
[root@myhost ~]# ./installer.sh --install --layout /usr/local [root@myhost ~]# /usr/local/bin/rkhunter –-update [root@myhost ~]# /usr/local/bin/rkhunter –-check
Rkhunter в начале проверят важные системные файлы, затем ищет руткиты. После происходит проверка на различные vulnerabilities. В конце программа проверяет версии популярных продуктов, таких как Apache, OpenSSH и т.п. на предмет последних версий.
Результаты своей работы rkhunter выдает в консоль, а также формирует консолидированный лог /var/log/rkhunter.log. Можно запускать данный антируткит каждый день по крону и получать отчет о сканировании по электронной почте.
К счастью, rkhunter не обнаружил на моём сервере никаких зловредов, это позволило успокоиться и подумать, что же за странные инсталлы произошли на сервере. И тут я вспомнил, что сразу после получения сервера, я установил и сконфигурировал на этом сервере VPN сервер. Видимо, произошла какая-то ошибка в Logwatch и он добавил в отчёт данные двухлетней давности.
Разумеется, если злоумышленники всё сделают грамотно, то Logwatch никаких следов не обнаружит и хозяин сервера долго ни о чём не будет подозревать. Однако, шаги, описанные в данном HowTo, если проводить их регулярно, помогут уберечь ваши сервера от компроментации.
