HotKey
15.03.2007, 21:42
В данной статье представлен сценарий достаточно сложного вторжения в систему, описаны некоторые технологии, которые использовал взломщик, чтобы
замаскировать следы тайного вторжения, а также некоторые усовершенствованные технологии обнаружения.
Вторник, 26 сентября 2005 года, 14:00
В полдень Роберт, преподаватель крупного восточного университета и владелец рабочей станции Red Hat Linux, заметил в конце конфигурационного файла
inetd.conf странную запись.
Подозрите/ьная запись в файле /eto/inetd.conf
netstat stream tcp nowait root /usr/lib/netstat netstat
Роберт был достаточно хорошо знаком с Linux и подумал, что такой записи там быть не должно, поэтому он попросил сотрудницу Алису проверить это. У Алисы
тоже была система Red Hat, установленная с тех же дисков (RedHat 6.2), с теми же настройками (используемыми по умолчанию) и в то же время (7 сентября 2005
года), что и система Роберта. Она просто проверила, была ли эта строка в ее системе. Там такой строки не было.
Чтобы определить нагрузку процессора, Роберт обычно запускал небольшую программу контроля центрального процессора на основе X Window. Сейчас он
видел, что нагрузка его центрального процессора составляет 100%. Однако запуск программы top показал в то же время нагрузку только 90% и не выявил
никаких выполняемых процессов, т.е. ничего такого, что могло бы объяснить эту разницу. Роберт очень заинтересовался тем, что же, собственно, происходит, но
не стал особо беспокоиться по этому поводу. Он решил вернуться к данному вопросу на следующий день.
Среда, 27 сентября 2005 года, 10:00
На следующее утро Роберт скопировал программы ps, netstat, Is и top со своего компьютера на компьютер Алисы, используя известную копию netcat. Он
полагал, что с ними могло быть что-то не так, а раз начались такие странные вещи, эти файлы должны быть изменены в первую очередь. Он сверил
контрольные суммы MD5 этих программ и определил, что они идентичны программам в системе Алисы. Это исключало возможность внедрения "троянского
коня", поэтому Роберт решил довериться программам. Но что же все-таки произошло с нагрузкой центрального процессора и что означала дополнительная
строка в inetd?
Все еще одолеваемые сомнениями, Роберт с Алисой тщательно просмотрели системные журналы. В них не было никаких признаков попыток вторжения или
несанкционированного входа в систему, но кое-что здесь выглядело подозрительно: в каталоге /var/log/secure отсутствовали записи о регистрации входа в
систему за период с 7 до 14 сентября, а Роберт точно знал, что он использовал систему в течение этого времени. Это было доказательством того, что с системой
что-то сделано путем использования прав суперпользователя (root). Теперь Роберт не сомневался, что его система взломана, но не понимал, каким образом.
Среда, 27 сентября 2005 года, 16:20
Алиса связалась с университетской группой реагирования на инциденты и изложила все, что они с Робертом узнали. Группа реагирования посоветовала
Роберту и Алисе собрать все данные входящего и исходящего трафика системы, используя утилиту tcpdump для сохранения признаков деятельности и более
тщательного анализа системы извне. С их помощью Алиса начала tcpdump-протоколирование показаний со смежной системы, использующей тот же
концентратор, и договорилась о визите группы реагирования на следующий день.
Четверг, 29 сентября 2005 года, 13:00
Член группы реагирования Фрэнк прихватил с собой портативный компьютер с жестким диском большой емкости, анализатором сетевых пакетов и другими
средствами. Портативный компьютер был подключен к тому же концентратору, который обслуживал подозрительную систему и еще две другие.
Фрэнк начал расследование со сканирования подозрительной системы, используя портативный компьютер и программу nmap:
laptop! nmap -sS -pi- -0 victim.chemistry.set.edu
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nma
P/ )
Insufficient responses for TCP sequencing (2), OS detection will be
MUCH less reliable
Interesting ports on victim.chemistry.set.edu (192.168.4.20):
(The 65523 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
113/tcp open auth
515/tcp open printer
932/tcp open unknown
945/tcp open unknown
1036/tcp open unknown
1037/tcp open unknown
3457/tcp open vat-control
32411/tcp open unknown
Remote operating system guess: Linux 2.1.122 - 2.2.14
Nmap run completed — 1 IP address (1 host up) scanned in 40 seconds
Затем Фрэнк зарегистрировался в подозрительной системе и запустил программу lsof, чтобы составить перечень открытых дескрипторов сетевых файлов
транспортного уровня. Они сравнили два этих списка.
victim! lsof | egrep "TCP|UDP"
portmap 325 root 3u IPv4 256 UDP *:sunrpc
portmap 325 root 4u IPv4 257 TCP *:sunrpc (LISTEN)
identd 438 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 439 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 442 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 444 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 445 root 4u IPv4 364 TCP *:auth (LISTEN)
Ipd 502 root 6u IPv4 447 TCP * sprinter (LISTEN)
sendmail 551 root 4u IPv4 483 TCP *:smtp (LISTEN)
httpd 530 root 16u IPv4 543 TCP *:www (LISTEN)
sshd2 590 root 3u IPv4 521 TCP *:ssh (LISTEN)
rpc.statd 3734 root Ou IPv4 12546 UDP *:943
rpc.statd 3734 root lu IPv4 12549 TCP *:945 (LISTEN)
httpd 12795 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12796 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12797 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12798 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12799 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12800 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12801 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12802 root 16u IPv4 543 TCP *:www (LISTEN)
Фрэнк тут же отметил некоторые странные вещи в результатах программы nmap: здесь указывалось на присутствие двух ожидающих подключения служб на
TCP-портах 3457 и 32411, которые не были обнаружены в ходе просмотра системы изнутри. Но что это были за службы?
Фрэнк переписал журнал tcpdump из системы Алисы, где она установила перехват трафика, на свой портативный компьютер и с помощью команды ngrep
выяснил, какой TCP-трафик транслируется на порт 32411:
apocalypsel ngrep -I victim.tcpdump "*" port 32411
input: victim.tcpdump
filter: ip and ( port 32411 )
match: *
#
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
ping.
#
Т 192.168.4.20:1844 -» 10.6.6.6:32411 [АР]
pong.
# #
Т 192.168.4.20:1844 -» 10.6.6.6:32411 [АР]
ping.
#
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
pong.
# #
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
ping.
#
Т 192.168.4.20:1844 -» 10.6.6.6:32411 [АР]
pong.
...
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
chan fubar 0 haxOr joined the party line..
##
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
join fubar haxOr 0 *5 haxOr@evil.site.com.
##
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
chan fubar 0 haxOr left the party line..
##
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
part fubar haxOr 5 .
##
Убедившись, что происходит что-то неладное, Фрэнк сделал для анализа побитовые копии разделов диска работающей системы, считывая их с помощью
программы dd и передавая результаты на портативный компьютер с помощью netcat.
Пятница, 30 сентября 2005 года, 10:00
После копирования активных разделов на портативный компьютер, Фрэнк установил для них атрибут "только для чтения", используя средства ядра Linux.
Подключенные таким способом разделы можно было увидеть из анализирующей системы. Затем Фрэнк использовал The Coroner's Toolkit — набор средств
постоперационного анализа — для просмотра копий системы. Он знал, что система была установлена 7 сентября, следовательно, временной интервал, который
необходимо проанализировать, небольшой и несложный для определения. Значит, обнаружить файл модификации файловой системы будет достаточно легко.
Предварительный анализ резервного пространства копии выявил следующую запись удаленного системного журнала:
Sep 18 02:42:54 victim rpc.statd[349]: gethostbyname error for "X [buffer overrun shell code removed]
В результате дальнейшего поиска с помощью программы mactirne была получена такая информация:
Sep 20 00 15:46:05 31376 .a. -rwxr-xr-x root root
/mount/usr/sbin/in.telnetd
Sep 20 00 15:46:39 20452 ..c -rwxr-xr-x root root
/mount/bin/login
Sep 20 00 16:49:26 446592 m.. -rwxr-xr-x root root
/mount/dev/ttypq/.../ex
Sep 20 00 16:49:45 1491 mac -rw-r—r— root root
/mount/dev/ttypq/.../doop
Sep 20 00 16:49:46 84688 m.c -rw-r—r— root root
/mount/dev/ttypq/.../c4
wnf 446592 ..c -rwxr-xr-x root root
/mount/dev/ttypq/.../ex
4096 m.c drwxr-xr-x root root
/mount/lib/modules/2.2.16-3/net
7704 ..c -rw-r--r— root root
/mount/lib/modules/2.2.16-3/net/
ipv6.0 Sep 20 00 16:49:47 949 ..c -rwxr-xr-x root root /mount/etc/re.d/rc.local
209 ..c -rwx——— root root
/mount/usr/sbin/initd
Sep 20 00 16:50:11 4096 .a. drwxr-xr-x operator 11
/mount/dev/ttypq/...
Sep 20 00 16:52:12 7704 .a. -rw-r—r— root root
/mount/lib/modules/2.2.16-3/net/ipv6.o
209 .a. -rwx——— root root /mount/usr/sbin/initd
222068 .a. -rwxr-xr-x root root
/mount/usr/sbin/rpc.status
Весьма серьезные подозрения у Фрэнка вызвал модуль ipv6. о, поскольку он знал, что протокол Ipv6 в системе не использовался. А вот что показал просмотр
двоичного кода с помощью программы strings:
provert strings ipv6.o
. . . check logfilter
kernel_version=2.2.16-3 my atoi
-.32411 my~find_task
:3457 is invisible
:6667 is_secret
:6664 iget
:6663 iput
:6662 hide_process
:6661 hidejile
:irc _mark_inode_dirty
:6660 unhide_file
:6668 n_getdents
nobody o_getdents
telnet n_fork
operator о fork
Proxy n clone
proxy o_clone
undernet.org n_kill
Undernet.org о kill
netstat n_ioctl
syslogd dev_get
klogd boot_cpu_data
promiscuous mode _verify_write
. . . o_ioctl
adore.с n write
gcc2_compiled. o_write _module_kernel version n setuid
we_did_promisc cleanup_module
netfilter_table о setuid
check_netfilter init_module
strstr _thisjnodule
logfilter table sys_call_table
Фрэнк также заметил, что в файле re.local изменился узел inode, поэтому он сравнил содержимое этого файла с содержимым аналогичного файла из "чистой"
системы:
provert diff re.local /etc/re.d/rc.local
36d35
< /usr/sbin/initd
По-видимому, это была строка, добавленная в конец файла, который запускал программу initd. Файл initd являлся сценарием:
proverjt cat /usr/sbin/initd
#l/bin/sh
#
# automatic install script to load kernel modules for ipv6 support.
# do not edit the file directly.
/sbin/insmod -f /lib/modules/2.2.16-3/net/ipv6.o »/dev/null 2»/dev/
null
/usr/sbin/rpc.status
После этого Фрэнк, естественно, проверил двоичный код файла rpc. status:
apocalypset strings /usr/sbin/rpc.status
leeto bindshell.
Enter valid IPX address:
gdb
(nfsiod)
socket
bind
listen
accept
/bin/sh
/dev/null
Теперь Фрэнк обладал уже достаточным количеством информации, чтобы определить, что же произошло с системой Linux.
Вопросы
1. Когда и каким образом компьютер Роберта был взломан?
2. Что могло послужить причиной тому, что две дополнительные службы не были обнаружены с помощью локальной программы lsof, но были выявлены
посредством удаленного сканирования программой nmар?
3. Какой тип трафика был обнаружен на TCP-порту 32411?
4. Что собой представляет модуль ipv6. о?
5. Что собой представляет файл rpc. status?
замаскировать следы тайного вторжения, а также некоторые усовершенствованные технологии обнаружения.
Вторник, 26 сентября 2005 года, 14:00
В полдень Роберт, преподаватель крупного восточного университета и владелец рабочей станции Red Hat Linux, заметил в конце конфигурационного файла
inetd.conf странную запись.
Подозрите/ьная запись в файле /eto/inetd.conf
netstat stream tcp nowait root /usr/lib/netstat netstat
Роберт был достаточно хорошо знаком с Linux и подумал, что такой записи там быть не должно, поэтому он попросил сотрудницу Алису проверить это. У Алисы
тоже была система Red Hat, установленная с тех же дисков (RedHat 6.2), с теми же настройками (используемыми по умолчанию) и в то же время (7 сентября 2005
года), что и система Роберта. Она просто проверила, была ли эта строка в ее системе. Там такой строки не было.
Чтобы определить нагрузку процессора, Роберт обычно запускал небольшую программу контроля центрального процессора на основе X Window. Сейчас он
видел, что нагрузка его центрального процессора составляет 100%. Однако запуск программы top показал в то же время нагрузку только 90% и не выявил
никаких выполняемых процессов, т.е. ничего такого, что могло бы объяснить эту разницу. Роберт очень заинтересовался тем, что же, собственно, происходит, но
не стал особо беспокоиться по этому поводу. Он решил вернуться к данному вопросу на следующий день.
Среда, 27 сентября 2005 года, 10:00
На следующее утро Роберт скопировал программы ps, netstat, Is и top со своего компьютера на компьютер Алисы, используя известную копию netcat. Он
полагал, что с ними могло быть что-то не так, а раз начались такие странные вещи, эти файлы должны быть изменены в первую очередь. Он сверил
контрольные суммы MD5 этих программ и определил, что они идентичны программам в системе Алисы. Это исключало возможность внедрения "троянского
коня", поэтому Роберт решил довериться программам. Но что же все-таки произошло с нагрузкой центрального процессора и что означала дополнительная
строка в inetd?
Все еще одолеваемые сомнениями, Роберт с Алисой тщательно просмотрели системные журналы. В них не было никаких признаков попыток вторжения или
несанкционированного входа в систему, но кое-что здесь выглядело подозрительно: в каталоге /var/log/secure отсутствовали записи о регистрации входа в
систему за период с 7 до 14 сентября, а Роберт точно знал, что он использовал систему в течение этого времени. Это было доказательством того, что с системой
что-то сделано путем использования прав суперпользователя (root). Теперь Роберт не сомневался, что его система взломана, но не понимал, каким образом.
Среда, 27 сентября 2005 года, 16:20
Алиса связалась с университетской группой реагирования на инциденты и изложила все, что они с Робертом узнали. Группа реагирования посоветовала
Роберту и Алисе собрать все данные входящего и исходящего трафика системы, используя утилиту tcpdump для сохранения признаков деятельности и более
тщательного анализа системы извне. С их помощью Алиса начала tcpdump-протоколирование показаний со смежной системы, использующей тот же
концентратор, и договорилась о визите группы реагирования на следующий день.
Четверг, 29 сентября 2005 года, 13:00
Член группы реагирования Фрэнк прихватил с собой портативный компьютер с жестким диском большой емкости, анализатором сетевых пакетов и другими
средствами. Портативный компьютер был подключен к тому же концентратору, который обслуживал подозрительную систему и еще две другие.
Фрэнк начал расследование со сканирования подозрительной системы, используя портативный компьютер и программу nmap:
laptop! nmap -sS -pi- -0 victim.chemistry.set.edu
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nma
P/ )
Insufficient responses for TCP sequencing (2), OS detection will be
MUCH less reliable
Interesting ports on victim.chemistry.set.edu (192.168.4.20):
(The 65523 ports scanned but not shown below are in state: closed)
Port State Service
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
113/tcp open auth
515/tcp open printer
932/tcp open unknown
945/tcp open unknown
1036/tcp open unknown
1037/tcp open unknown
3457/tcp open vat-control
32411/tcp open unknown
Remote operating system guess: Linux 2.1.122 - 2.2.14
Nmap run completed — 1 IP address (1 host up) scanned in 40 seconds
Затем Фрэнк зарегистрировался в подозрительной системе и запустил программу lsof, чтобы составить перечень открытых дескрипторов сетевых файлов
транспортного уровня. Они сравнили два этих списка.
victim! lsof | egrep "TCP|UDP"
portmap 325 root 3u IPv4 256 UDP *:sunrpc
portmap 325 root 4u IPv4 257 TCP *:sunrpc (LISTEN)
identd 438 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 439 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 442 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 444 root 4u IPv4 364 TCP *:auth (LISTEN)
identd 445 root 4u IPv4 364 TCP *:auth (LISTEN)
Ipd 502 root 6u IPv4 447 TCP * sprinter (LISTEN)
sendmail 551 root 4u IPv4 483 TCP *:smtp (LISTEN)
httpd 530 root 16u IPv4 543 TCP *:www (LISTEN)
sshd2 590 root 3u IPv4 521 TCP *:ssh (LISTEN)
rpc.statd 3734 root Ou IPv4 12546 UDP *:943
rpc.statd 3734 root lu IPv4 12549 TCP *:945 (LISTEN)
httpd 12795 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12796 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12797 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12798 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12799 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12800 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12801 root 16u IPv4 543 TCP *:www (LISTEN)
httpd 12802 root 16u IPv4 543 TCP *:www (LISTEN)
Фрэнк тут же отметил некоторые странные вещи в результатах программы nmap: здесь указывалось на присутствие двух ожидающих подключения служб на
TCP-портах 3457 и 32411, которые не были обнаружены в ходе просмотра системы изнутри. Но что это были за службы?
Фрэнк переписал журнал tcpdump из системы Алисы, где она установила перехват трафика, на свой портативный компьютер и с помощью команды ngrep
выяснил, какой TCP-трафик транслируется на порт 32411:
apocalypsel ngrep -I victim.tcpdump "*" port 32411
input: victim.tcpdump
filter: ip and ( port 32411 )
match: *
#
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
ping.
#
Т 192.168.4.20:1844 -» 10.6.6.6:32411 [АР]
pong.
# #
Т 192.168.4.20:1844 -» 10.6.6.6:32411 [АР]
ping.
#
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
pong.
# #
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
ping.
#
Т 192.168.4.20:1844 -» 10.6.6.6:32411 [АР]
pong.
...
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
chan fubar 0 haxOr joined the party line..
##
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
join fubar haxOr 0 *5 haxOr@evil.site.com.
##
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
chan fubar 0 haxOr left the party line..
##
Т 10.6.6.6:32411 -» 192.168.4.20:1844 [АР]
part fubar haxOr 5 .
##
Убедившись, что происходит что-то неладное, Фрэнк сделал для анализа побитовые копии разделов диска работающей системы, считывая их с помощью
программы dd и передавая результаты на портативный компьютер с помощью netcat.
Пятница, 30 сентября 2005 года, 10:00
После копирования активных разделов на портативный компьютер, Фрэнк установил для них атрибут "только для чтения", используя средства ядра Linux.
Подключенные таким способом разделы можно было увидеть из анализирующей системы. Затем Фрэнк использовал The Coroner's Toolkit — набор средств
постоперационного анализа — для просмотра копий системы. Он знал, что система была установлена 7 сентября, следовательно, временной интервал, который
необходимо проанализировать, небольшой и несложный для определения. Значит, обнаружить файл модификации файловой системы будет достаточно легко.
Предварительный анализ резервного пространства копии выявил следующую запись удаленного системного журнала:
Sep 18 02:42:54 victim rpc.statd[349]: gethostbyname error for "X [buffer overrun shell code removed]
В результате дальнейшего поиска с помощью программы mactirne была получена такая информация:
Sep 20 00 15:46:05 31376 .a. -rwxr-xr-x root root
/mount/usr/sbin/in.telnetd
Sep 20 00 15:46:39 20452 ..c -rwxr-xr-x root root
/mount/bin/login
Sep 20 00 16:49:26 446592 m.. -rwxr-xr-x root root
/mount/dev/ttypq/.../ex
Sep 20 00 16:49:45 1491 mac -rw-r—r— root root
/mount/dev/ttypq/.../doop
Sep 20 00 16:49:46 84688 m.c -rw-r—r— root root
/mount/dev/ttypq/.../c4
wnf 446592 ..c -rwxr-xr-x root root
/mount/dev/ttypq/.../ex
4096 m.c drwxr-xr-x root root
/mount/lib/modules/2.2.16-3/net
7704 ..c -rw-r--r— root root
/mount/lib/modules/2.2.16-3/net/
ipv6.0 Sep 20 00 16:49:47 949 ..c -rwxr-xr-x root root /mount/etc/re.d/rc.local
209 ..c -rwx——— root root
/mount/usr/sbin/initd
Sep 20 00 16:50:11 4096 .a. drwxr-xr-x operator 11
/mount/dev/ttypq/...
Sep 20 00 16:52:12 7704 .a. -rw-r—r— root root
/mount/lib/modules/2.2.16-3/net/ipv6.o
209 .a. -rwx——— root root /mount/usr/sbin/initd
222068 .a. -rwxr-xr-x root root
/mount/usr/sbin/rpc.status
Весьма серьезные подозрения у Фрэнка вызвал модуль ipv6. о, поскольку он знал, что протокол Ipv6 в системе не использовался. А вот что показал просмотр
двоичного кода с помощью программы strings:
provert strings ipv6.o
. . . check logfilter
kernel_version=2.2.16-3 my atoi
-.32411 my~find_task
:3457 is invisible
:6667 is_secret
:6664 iget
:6663 iput
:6662 hide_process
:6661 hidejile
:irc _mark_inode_dirty
:6660 unhide_file
:6668 n_getdents
nobody o_getdents
telnet n_fork
operator о fork
Proxy n clone
proxy o_clone
undernet.org n_kill
Undernet.org о kill
netstat n_ioctl
syslogd dev_get
klogd boot_cpu_data
promiscuous mode _verify_write
. . . o_ioctl
adore.с n write
gcc2_compiled. o_write _module_kernel version n setuid
we_did_promisc cleanup_module
netfilter_table о setuid
check_netfilter init_module
strstr _thisjnodule
logfilter table sys_call_table
Фрэнк также заметил, что в файле re.local изменился узел inode, поэтому он сравнил содержимое этого файла с содержимым аналогичного файла из "чистой"
системы:
provert diff re.local /etc/re.d/rc.local
36d35
< /usr/sbin/initd
По-видимому, это была строка, добавленная в конец файла, который запускал программу initd. Файл initd являлся сценарием:
proverjt cat /usr/sbin/initd
#l/bin/sh
#
# automatic install script to load kernel modules for ipv6 support.
# do not edit the file directly.
/sbin/insmod -f /lib/modules/2.2.16-3/net/ipv6.o »/dev/null 2»/dev/
null
/usr/sbin/rpc.status
После этого Фрэнк, естественно, проверил двоичный код файла rpc. status:
apocalypset strings /usr/sbin/rpc.status
leeto bindshell.
Enter valid IPX address:
gdb
(nfsiod)
socket
bind
listen
accept
/bin/sh
/dev/null
Теперь Фрэнк обладал уже достаточным количеством информации, чтобы определить, что же произошло с системой Linux.
Вопросы
1. Когда и каким образом компьютер Роберта был взломан?
2. Что могло послужить причиной тому, что две дополнительные службы не были обнаружены с помощью локальной программы lsof, но были выявлены
посредством удаленного сканирования программой nmар?
3. Какой тип трафика был обнаружен на TCP-порту 32411?
4. Что собой представляет модуль ipv6. о?
5. Что собой представляет файл rpc. status?