Примерно два года назад я арендовал у одного немецкого хостера не очень мощный сервер на базе Centos 5.2. На нём живут несколько вебпроектов, приносящих некоторую прибыль, и поэтому, я стараюсь присматривать за ним по мере возможности.
На 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, если проводить их регулярно, помогут уберечь ваши сервера от компроментации.