пятница, 7 мая 2010 г.

Жизнь после взлома Linux

Один из обслуживаемых серверов был в недавнем времени взломан. Поэтому я хочу опубликовать краткий обзор тех команд которые помогут вам вычислить, какие процессы и порты использует хакер. Итак начнем:

Программа 1. Команда top
Очень хорошая утилитка, которая покажет вам что у вас происходит в системе. Ее должен знать каждый уважающий себя(и даже не уважающий) админ.

debian:/etc# top
top - 17:46:27 up 1 day, 22:51, 1 user, load average: 0.02, 0.09, 0.07
Tasks: 59 total, 2 running, 57 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.3%us, 0.7%sy, 0.0%ni, 95.4%id, 0.3%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 507408k total, 498848k used, 8560k free, 62672k buffers
Swap: 1485972k total, 68k used, 1485904k free, 336816k cached


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2146 uucp 20 0 6188 4072 780 S 5.3 0.8 42:17.90 iaxmodem
2663 root 20 0 52488 21m 14m S 2.0 4.3 40:19.33 asterisk
471 root 20 0 2392 1104 884 R 0.7 0.2 0:00.02 top
1 root 20 0 2100 684 588 S 0.0 0.1 0:02.14 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:05.24 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:05.82 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
39 root 15 -5 0 0 0 S 0.0 0.0 0:00.84 kblockd/0
41 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
42 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kacpi_notify
110 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
146 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
147 root 20 0 0 0 0 S 0.0 0.0 0:02.44 pdflush
148 root 15 -5 0 0 0 S 0.0 0.0 0:00.56 kswapd0

Если ничего подозрительного вы не нашли, что идем к следующей программе.

Программа 2. nmap
Замечательная утилита, возможности которой просто безграничны.
debian:/etc# nmap -sT -v -v -v localhost

Starting Nmap 4.62 ( http://nmap.org ) at 2010-05-06 17:50 MSD
Initiating Connect Scan at 17:50
Scanning localhost (127.0.0.1) [1715 ports]
Discovered open port 53/tcp on 127.0.0.1
Discovered open port 25/tcp on 127.0.0.1
Discovered open port 2000/tcp on 127.0.0.1
Discovered open port 3306/tcp on 127.0.0.1
Discovered open port 953/tcp on 127.0.0.1
Discovered open port 139/tcp on 127.0.0.1
Discovered open port 445/tcp on 127.0.0.1
Completed Connect Scan at 17:50, 0.09s elapsed (1715 total ports)
Host localhost (127.0.0.1) appears to be up ... good.
Interesting ports on localhost (127.0.0.1):
Not shown: 1708 closed ports
PORT STATE SERVICE
25/tcp open smtp
53/tcp open domain
139/tcp open netbios-ssn
445/tcp open microsoft-ds
953/tcp open rndc
2000/tcp open callbook
3306/tcp open mysql


Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.142 seconds
Raw packets sent: 0 (0B) | Rcvd: 0 (0B)

Программа 3. tcpdump
Далее стоит запустить сниффер пакетов. Отсекая ненужные порты, запускаем:
debian:/etc# /usr/sbin/tcpdump -elXnvvv -i eth0 dst port not 22 and dst port not 80 and dst port not 53

Программа 3. netstat
Команда netstat показывает содержимое различных структур данных, связанных с сетью, в различных форматах в зависимости от указанных опций.
debian:/etc# netstat -lpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 2209/mysqld
tcp 0 0 0.0.0.0:25900 0.0.0.0:* LISTEN 2123/sshd
tcp 0 0 0.0.0.0:2000 0.0.0.0:* LISTEN 2663/asterisk
tcp 0 0 10.220.10.1:53 0.0.0.0:* LISTEN 2064/named
tcp 0 0 192.168.0.167:53 0.0.0.0:* LISTEN 2064/named
tcp 0 0 A.B.C.D:53 0.0.0.0:* LISTEN 2064/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2064/named
tcp 0 0 A.B.C.D:1720 0.0.0.0:* LISTEN 2663/asterisk
tcp 0 0 A.B.C.D:1721 0.0.0.0:* LISTEN 2663/asterisk
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2533/exim4
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 2064/named
tcp6 0 0 :::139 :::* LISTEN 2562/smbd
tcp6 0 0 :::25900 :::* LISTEN 2123/sshd
tcp6 0 0 :::53 :::* LISTEN 2064/named
tcp6 0 0 ::1:953 :::* LISTEN 2064/named
tcp6 0 0 :::445 :::* LISTEN 2562/smbd
udp 0 0 0.0.0.0:5000 0.0.0.0:* 2663/asterisk
udp 0 0 10.220.10.1:137 0.0.0.0:* 2560/nmbd
udp 0 0 192.168.0.167:137 0.0.0.0:* 2560/nmbd
udp 0 0 A.B.C.D:137 0.0.0.0:* 2560/nmbd
udp 0 0 0.0.0.0:137 0.0.0.0:* 2560/nmbd
udp 0 0 10.220.10.1:138 0.0.0.0:* 2560/nmbd
udp 0 0 192.168.0.167:138 0.0.0.0:* 2560/nmbd
udp 0 0 A.B.C.D:138 0.0.0.0:* 2560/nmbd
udp 0 0 0.0.0.0:138 0.0.0.0:* 2560/nmbd
udp 0 0 127.0.0.1:161 0.0.0.0:* 2572/snmpd
udp 0 0 0.0.0.0:2727 0.0.0.0:* 2663/asterisk
udp 0 0 0.0.0.0:4520 0.0.0.0:* 2663/asterisk
udp 0 0 10.220.10.1:53 0.0.0.0:* 2064/named
udp 0 0 192.168.0.167:53 0.0.0.0:* 2064/named
udp 0 0 A.B.C.D:53 0.0.0.0:* 2064/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 2064/named
udp 0 0 0.0.0.0:5060 0.0.0.0:* 2663/asterisk
udp 0 0 0.0.0.0:4569 0.0.0.0:* 2146/iaxmodem
udp6 0 0 :::53 :::* 2064/named
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 4620 2026/acpid /var/run/acpid.socket
unix 2 [ ACC ] STREAM LISTENING 5605 2663/asterisk /var/run/asterisk.ctl
unix 2 [ ACC ] STREAM LISTENING 4910 2209/mysqld /tmp/mysql.sock
unix 2 [ ACC ] STREAM LISTENING 4640 2036/dbus-daemon /var/run/dbus/system_bus_socket

Программа 4. find
Да, вы не ослышались. Команду find будем использовать для поиска файлов которые были изменены. Пример поиска изменившихся файлов за последние час:

debian:/etc# find /etc -mtime -10
/etc
/etc/firewall.conf
/etc/asterisk
/etc/asterisk/extensions.conf
/etc/asterisk/h323.conf
/etc/asterisk/users.conf
/etc/asterisk/ooh323.conf
/etc/asterisk/screenlog.0
/etc/mtab
/etc/firewall.allow.conf
/etc/adjtime
/etc/network/run
/etc/network/run/ifstate

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

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

3 комментария:

Angel 2S2 комментирует...

Т.ж. всегда стоит учитывать, что взломщик может заменить любую утилиту на специально пропатченную, которая просто не будет показывать то, что вам не надо знать, по мнению злоумышленника (аля, руткит). Поэтому такой софт лучше запускать с компакта или из шары, которая доступна в режиме только для чтения, предварительно монолитно скомпилированный на заведомо стерильной системе. Еще взломщик может внедрить руткит, работающий в режиме ядра (модуль ядра, например), который просто из выходных данных различных утилит и логов будет удалять все "не нужное". В таких случаях хорошо помогают специализированные дистрибутивы для расследования инцидентов (forensic) таких как DEFT и ему подобные (исследование, естественно, проводится в оффлайне, что, к сожалению, не всегда возможно/допустимо, но сделать хотя бы дамп диска и его исследовать в таких случаях стоит).

Никита комментирует...

Angel 2S2 , спасибо за советы, они прекрасно дополняют статью. =)

Igor комментирует...

Я для анализа взлома держу заархивированые образа LVM снапшотов.
Их очень удобно примонтировать и сделать diff каталогов на предмет внедрения руткита. Кроме того почта и прочие взломоопасные машины кроме астериска живут в виртуалках XEN, что позволяет, например, /bin/ и /usr/ хранить в разделах ридонли, а так же разворачивать восстановленный образ машины за секунды