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