Как быстро проверить Linux сервер на предмет взлома

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