Создание и использование комплекта инструментов живого ответа для Unix

ARP

Таблица ARP (Address Resolution Protocol - Протокол определения адресов) устанавливает соответствие между физическим машинным MAC-адресом Ethernet-карты и соответствующим IP-адресом в подсети. Поскольку большинство сетей не обеспечивают безопасность локальной подсети, связывая определенный MAC-адрес с IP-адресом, используя коммутаторы, то любой может изменить свою ARP -таблицу или IP-адрес и вызвать смуту. Это происходит, например, когда один из служащих маскируется под другого служащего во внутренней сети. Используя команду ARP, вы можете видеть, какой MAC-адрес соответствовал определенному IP-адресу в течение последних нескольких минут, и это поможет вам выследить жулика.

Программа ARP обычно расположена в каталоге /sbin или /usr/sbin, в зависимости от версии Unix, которую вы используете.

Реализация

Команда используется для просмотра ARP -таблицы машины-жертвы. Очень похожа на команду, которая используется при живом ответе в Windows:

victim# ./arp -an

С системы-жертвы возвращается следующая таблица ARP:

? (192.168.1.1) at 00:BD:81:43:07:03 [ether] on eth0

Результаты показывают, что машина с IP-адресом 192.168.1.1 имеет MAC-адрес 00:BD:81:43:07:03. Эта дополнительная часть информации помогает нам при отслеживании адреса 192.168.1.1 из нашей сети, когда мы не регулируем IP-адреса сами. Мы можем проверять каждую машину, пока не найдем MAC-адрес 00:BD:81:43:07:03.

ls

Использование команды ls в Unix подобно использованию команды dir при выполнении живого ответа в Windows. Мы можем использовать ее, чтобы собрать те файлы системы, к которым недавно обращались или которые недавно изменялись. Неплохо выполнить эту команду, чтобы ни одна временная метка в системе не была потеряна на случай, если в процессе живого ответа будет сделана ошибка. Команда ls обычно находится в каталоге /bin.

Реализация

Чтобы собрать файлы, к которым кто-либо обращался в последнее время, выполните следующую команду:

victim# ls-alR --time=atime/

Соответствующие файлы, возвращенные в результате этой команды, показаны в следующем фрагменте. Сначала, мы видим файлы из каталога /etc.

-rw-r--r--  1 root  root    7470    Mar 21  06:32   mime.types  
-rw-r--r--  1 root  root    1048    Mar 7   2000    minicom.users   
-rw-r--r--  1 root  kjohnson    196 Mar 22  00:17   motd    
-rw-r--r--  1 root  root    90  Mar 22  00:23   mtab    
-rw-r--r--  1 root  root    1925    Feb 9   2000    mtools.conf

Затем мы видим файлы в подкаталоге home каталога /kjohnson:

/home/kjohnson:
total 240
drwx------  2 root  kjohnson    4096    Mar 22  00:30   .   
drwxr-xr-x  7 root  root    4096    Mar 22  00:30   ..  
-rw-------  1 root  kjohnson    216 Mar 22  00:18   .bash_history   
-rw-r--r--  1 root  kjohnson    24  Mar 22  00:18   .bash_logout    
-rw-r--r--  1 root  kjohnson    230 Mar 21  23:40   .bash_profile   
-rw-r--r--  1 root  kjohnson    124 Mar 21  23:40   .bashrc 
-rw-r--r--  1 root  kjohnson    3394    Mar 21  23:39   .screenrc   
-rwxr-xr-x  1 root  kjohnson    210096  Mar 22  00:13   1

Чтобы собрать файлы, которые в последнее время модифицировались, выполняем следующую команду:

victim# ls-alR - time=mtime/

Если команда не сработала, это может означать, что модифицированные файлы уже были отображены по умолчанию (так обстоит дело в системе Linux).

Если файлы, модифицированные в ближайшее время, были показаны по умолчанию, то вместо предыдущей команды можно использовать следующую:

victim# ls-alR/

В результате этой команды были отображены следующие файлы. Сначала видим подозрительные файлы в каталоге /etc.

-rw-r--r--  1 root  root    7470    Mar 21  06:32   mime.types  
-rw-r--r--  1 root  root    1048    Mar 7   2000    minicom.users   
-rw-r--r--  1 root  kjohnson    196 Mar 22  00:17   motd    
-rw-r--r--  1 root  root    90  Mar 22  00:23   mtab    
-rw-r--r--  1 root  root    1925    Feb 9   2000    mtools.conf

Затем смотрим файлы из подкаталога home каталога /kjohnson.

/home/kjohnson:
total 240
drwx------  2 root  kjohnson    4096    Mar 22  00:18   .   
drwxr-xr-x  7 root  root    4096    Mar 21  23:39   ..  
-rw-------  1 root  kjohnson    216 Mar 22  00:18   .bash_history   
-rw-r--r--  1 root  kjohnson    24  Mar 21  23:39   .bash_logout    
-rw-r--r--  1 root  kjohnson    230 Mar 21  23:39   .bash_profile   
-rw-r--r--  1 root  kjohnson    124 Mar 21  23:39   .bashrc 
-rw-r--r--  1 root  kjohnson    3394    Mar 21  23:39   .screenrc   
-rwxr-xr-x  1 root  kjohnson    210096  Mar 21  23:43   1

Чтобы собрать данные о том, когда изменялась какая-либо информация в пределах inode (структура данных, содержащая разрешения файла; место на диске, где может быть найдена остальная часть файла, а также метки даты и времени), выполняется следующая команда:

victim# ls -alR --time=ctime /

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

В подкаталоге home каталога /kjohnson мы видим подозрительный файл с именем 1. Сейчас он может не иметь для нас большого значения, но он будет играть важную роль позже в разделе "Пример из жизни".

w

Для системы Unix существует команда w, подобная команде loggedon, которую мы использовали с системой Windows. Эта команда отображает всех пользователей, в настоящее время вошедших в систему, и их исходящие IP-адреса. Эта команда полезна при расследовании неправомочного использования учетных записей в системе Unix.

Команда w расположена в каталоге /usr/bin.

Реализация

Чтобы использовать команду w, наберите следующее:

victim# w

Вывод команды w на нашей машине-жертве выглядит следующим образом:

12:24am     up  1:38, 1 user, load average: 0.02, 0.02, 0.00
USER        TTY     FROM    LOGIN@  IDLE    JCPU    PCPU    WHAT    
Root        tty1    -       10:44pm 0.00s   0.71s   0.03s   w

Поскольку мы вошли в систему в качестве привилегированного (root) пользователя с консоли (обозначено символом " - " в столбце FROM ), мы не видим никакой подозрительной деятельности.

last и lastb

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

Команды last и lastb обычно расположены в каталоге /usr/bin.

Реализация

В сценарии своего расследования вам нужно сделать дамп всех попыток входа в систему. Это должно выполняться следующей командой (при использовании команды lastb, замените last на lastb):

victim# last

Команда выведет следующие результаты с нашей машины-жертвы:

mpepe   pts/0   192.168.1.1 Thu Mar 21  23:37   -   00:24   (00:46)
root    tty1        Thu Mar 21  22:44       still logged in 
reboot  system boot 2.2.14-5.0  Fri Mar 22  03:42           (-3:-6)
root    tty1        Fri Mar 22  03:39   -   down    (00:00)
reboot  system boot 2.2.14-5.0  Fri Mar 22  03:09           (00:30)
reboot  system boot 2.2.14-5.0  Thu Mar 21  09:04   (18:36) 

wtmp begins Thu Mar 21 09:04:17 2002

Как видим, регистрация входа в систему пользователя kjohnson отсутствует. Мы можем сделать еще несколько заключений: или файлы регистрации были испорчены взломщиком, или он взломал учетную запись mpepe и переключил пользователя, используя команду su, на учетную запись kjohnson.

Lsof

Поскольку для большинства разновидностей систем Unix отсутствует версия netstat, которая поддерживает флаг -p, то для отображения сетевых сокетов, открытых в файловой системе для исполняемых файлов, мы используем инструмент, который называется lsof. В этом отношении, lsof подобен инструменту fport, который был описан в предыдущей лекции. Кроме того, lsof покажет нам все открытые файлы в системе. Инструмент lsof распространяется бесплатно и перенесен почти на все разновидности системы Unix. Хотя lsof имеет множество опций, полезных для обычного системного администратора, в этой лекции обсуждаются только те опции, которые полезны для сценария "живого ответа". Если вам интересно использование других опций, с помощью команды man посмотрите страницы, посвященные утилите lsof. На них этот инструмент широко обсуждается.

lsof доступен на следующих FTP-сайтах:

Реализация

Используйте следующую команду, чтобы получить список всех открытых сокетов и файлов в системе:

victim# ./lsof -n

Опция -n используется в команде lsof, чтобы не выполнять обратный поиск имен DNS для всех IP-адресов, перечисленных в результатах. В целях нашего расследования, мы стараемся не полагаться на полностью квалифицированные имена доменов, потому что они могут меняться; лучше использовать действующие IP-адреса. Ниже показан вывод этой команды.

COMMAND PID USER    FD    TYPE    DEVICE     SIZE    NODE   NAME
inetd   721 root    cwd   DIR        3,2     4096       2   /
inetd   721 root    rtd   DIR        3,2     4096       2   /
inetd   721 root    txt   REG        3,2    21552   35319   /usr/sbin/inetd
inetd   721 root    mem   REG        3,2   340663  146606   /lib/ld-2.1.3.so
inetd   721 root    mem   REG        3,2  4101324  146613   /lib/libc-2.1.3.so
inetd   721 root    mem   REG        3,2   246652  146644   /lib/libnss_files-2.1.3.so
inetd   721 root    0u    CHR        1,3            65387   /dev/null
inetd   721 root    1u    CHR        1,3            65387   /dev/null
inetd   721 root    2u    CHR        1,             65387   /dev/null
inetd   721 root    3u    IPv4       745              TCP   *:39168 (LISTEN)
inetd   721 root    4u    IPv4       746              TCP
192.168.1.104:39168-192.168.1.1:2028 (CLOSE_WAIT)
inetd   721 root    5u    unix 0xc2a99980             853   socket
inetd   721 root    6u    IPv4       748              TCP   *:ftp (LISTEN)
inetd   721 root    7u    IPv4       749              TCP   *:telnet (LISTEN)
inetd   721 root    8u    IPv4       750              TCP   *:shell (LISTEN)
inetd   721 root    9u    IPv4       751              TCP   *:login (LISTEN)
inetd   721 root    10u   IPv4       752              UDP   *:talk
inetd   721 root    11u   IPv4       753              UDP   *:ntalk
inetd   721 root    12u   IPv4       754              TCP   *:finger (LISTEN)
inetd   721 root    13u   IPv4       755              TCP   *:linuxconf (LISTEN)
inetd   721 root    14u   IPv4       756              TCP   *:4375 (LISTEN)
1       881 root    cwd   DIR        3,2     4096   83456   /home/kjohnson
1       881 root    rtd   DIR        3,2     4096       2   /
1       881 root    txt   REG        3,2   210096   83461   /home/kjohnson/1
1       881 root    mem   REG        3,2   340663  146606   /lib/ld-2.1.3.so
1       881 root    mem   REG        3,2  4101324  146613   /lib/libc-2.1.3.so
1       881 root    mem   REG        3,2   246652  146644   /lib/ /libnss_files-2.1.3.so
1       881 root    0u    CHR      136,0                2   /dev/pts/0
1       881 root    1u    CHR      136,0                2   /dev/pts/0
1       881 root    2u    CHR      136,0                2   /dev/pts/0
1       881 root    3u    sock       0,0              954   can't identify protocol
1       881 root    4w    REG        3,2    36864   35934   /tmp/.net

Здесь мы видим, что inetd открыл TCP-порт 4375. Следовательно, мы должны исследовать файл /etc/inetd.conf. Далее мы видим, что исполняемый файл 1 открывает файл с именем /tmp/.net, и этот файл также надо исследовать. Исполняемый файл 1 открывает также "сырой" (необработанный) сокет, как видно из следующей строки:

1   881 root   3u    sock       0,0    954   can't identify protocol

Если мы убеждаемся, что этот исполняемый файл открывает "сырой" сокет и обычный файл, то можно предполагать, что исполняемый файл 1 может быть анализатором сетевого трафика (sniffer) (анализаторы сетевого трафика обсуждались в лекции "Анализаторы сетевых потоков").

ps

Чтобы получить список процессов, в настоящее время выполняющихся в системе, используется команда ps. Эта команда подобна программе Pslist, которую мы обсуждали в лекции "Компоновка и использование набора инструментов для расследования хакерских атак, то есть для "живого ответа" в системе Windows". Мы используем команду ps, чтобы увидеть процессы, запущенные взломщиком, такие как анализаторы сетевых потоков (sniffers), черные ходы для скрытого удаленного администрирования, зомби, вызывающие распределенный отказ в обслуживании, а также взломщики паролей (password cracker), выполняющиеся на машине-жертве.

Команда ps обычно расположена в каталоге /bin.

Реализация

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

victim# ./ps-aux

Ниже показан список процессов нашей машины-жертвы. Обратите внимание, что мы можем видеть время начала каждого процесса, то есть, можем узнать, какие процессы были выполнены вскоре после того, как система была взломана.

USER    PID  %CPU   %MEM    VSZ   RSS TTY     STAT  START   TIME   COMMAND
root      1   0.1    0.7   1120   476   ?     S     Mar21   0:06   init [3]
root      2   0.0    0.0      0     0   ?     SW    Mar21   0:00   [kflushd]
root      3   0.0    0.0      0     0   ?     SW    Mar21   0:01   [kupdate]
root      4   0.0    0.0      0     0   ?     SW    Mar21   0:00   [kpiod]
root      5   0.0    0.0      0     0   ?     SW    Mar21   0:00   [kswapd]
root      6   0.0    0.0      0     0   ?     SW    Mar21   0:00   [mdrecoveryd]
bin     319   0.0    0.7   1212   496   ?     S     Mar21   0:00   portmap
root    334   0.0    0.0      0     0   ?     SW    Mar21   0:00   [lockd]
root    335   0.0    0.0      0     0   ?     SW    Mar21   0:00   [rpciod]
root    358   0.0    0.7   1104   480   ?     S     Mar21   0:00   /usr/sbin/apmd -p
root    409   0.0    0.8   1172   552   ?     S     Mar21   0:00   syslogd -m 0
root    418   0.0    1.2   1440   768   ?     S     Mar21   0:00   klogd
nobody  432   0.0    0.9   1292   628   ?     S     Mar21   0:00   identd -e -o
nobody  435   0.0    0.9   1292   628   ?     S     Mar21   0:00   identd -e -o
nobody  436   0.0    0.9   1292   628   ?     S     Mar21   0:00   identd -e -o
nobody  438   0.0    0.9   1292   628   ?     S     Mar21   0:00   identd -e -o
nobody  439   0.0    0.9   1292   628   ?     S     Mar21   0:00   identd -e -o
daemon  450   0.0    0.7   1144   496   ?     S     Mar21   0:00   /usr/sbin/atd
root    464   0.0    0.9   1328   620   ?     S     Mar21   0:00   crond
root    496   0.0    0.8   1204   532   ?     S     Mar21   0:00   lpd
root    510   0.0    0.8   1156   532   ?     S     Mar21   0:00   rpc.rstatd
root    526   0.0    0.6   1140   408   ?     S     Mar21   0:00   rpc.rusersd
nobody  540   0.0    0.9   1316   612   ?     S     Mar21   0:00   rpc.rwalld  root
root    554   0.0    0.8   1132   552   ?     S     Mar21   0:00   rwhod
root    598   0.0    1.7   2128  1124   ?     S     Mar21   0:00   sendmail: accepti
root    613   0.0    0.7   1144   456   ?     S     Mar21   0:00   gpm -t ps/2
xfs     647   0.0    1.2   1728   808   ?     S     Mar21   0:00   xfs -droppriv -da
root    685   0.0    1.6   2224  1040   tty1  S     Mar21   0:00   login - root
root    686   0.0    0.6   1092   408   tty2  S     Mar21   0:00   /sbin/mingetty tt
root    687   0.0    0.6   1092   408   tty3  S     Mar21   0:00   /sbin/mingetty tt
root    688   0.0    0.6   1092   408   tty4  S     Mar21   0:00   /sbin/mingetty tt
root    689   0.0    0.6   1092   408   tty5  S     Mar21   0:00   /sbin/mingetty tt
root    690   0.0    0.6   1092   408   tty6  S     Mar21   0:00   /sbin/mingetty tt
root    693   0.0    1.5   1716   976   tty1  S     Mar21   0:00   -bash
root    721   0.0    0.8   1156   520   ?     S     Mar21   0:00   /usr/sbin/inetd
root    881   0.0    1.2   1964   776   ?     S     00:14   0:00   ./1 -s 65535 -n -
root    975   0.0    1.1   2332   700   tty1  R     00:34   0:00   ps aux

Если мы рассмотрим процесс, соответствующий выполнению команды 1, мы увидим, что он выполняется как процесс с идентификатором (ID) 721. Процесс был запущен пользователем с правами привилегированного доступа (root) в 00:14 того же дня. Следовательно, если мы знаем, что пользователь с именем kjohnson, запустивший исполняемый файл 1, был неправомочным пользователем в системе, и этот процесс выполняется с правами привилегированного доступа (root), то, вероятно, у взломщика есть право привилегированного доступа.

Примеры, приведенные в этой книге, показывают такой формат вывода, который в большинстве ситуаций полезен человеку, проводящему расследование. Однако команда ps может делать вывод данных в разнообразных форматах. Формат, заданный в первой команде ps (ps -aux), отсекает часть синтаксиса командной строки перечисляемых процессов. Чтобы решить проблему с отсечением части данных, мы можем переформатировать вывод команды ps следующим образом:

victim# ./ps-axo <var1>, <var2>, :

Маркер <var> может представлять любой из параметров, перечисленных далее. Столбец "код" содержит код, который вы вводите как <var1>, <var2> и так далее; столбец "заголовок" содержит название заголовка, который появляется в выводе команды ps. С помощью этих кодов можно инвентаризировать почти любой аспект таблицы процессов, который может потребоваться.

Многие из этих полей могут быть вам не интересны. Тем не менее, некоторые из них могут оказаться полезными. Например, если вы хотели посмотреть только идентификаторы процессов ID (PID), пользователей, которые создали процессы, время их запуска и полную командную строку, понадобится следующая команда:

victim# ./ps-axo pid,uid,start,command

Эта командная строка вывела бы больше синтаксиса командных строк, перечисленных процессов, чем выводит версия ps -aux.

kill

Если начальство просит нас немедленно исправить ситуацию, мы можем уничтожить подозрительный процесс, запущенный взломщиком (ID 721). Это можно сделать с помощью команды kill. Команда kill установлена по умолчанию в операционных системах Unix и может быть найдена в каталоге /bin.

Реализация

Следующая команда уничтожит процесс с идентификатором <PID>:

victim# ./kill-9 <PID>

Md5sum

После того как вся информация была передана на компьютер, используемый для расследования (судебный), неплохо получить контрольную сумму MD5-вывода. Поскольку на судебном компьютере может быть установлена система Unix (вместо системы Windows, которая демонстрируется в лекции "Компоновка и использование набора инструментов для расследования хакерских атак, то есть для "живого ответа" в системе Windows"), то в этом разделе мы предлагаем правильную нотацию команд для Unix.

Версия Md5sum распространяется с основной операционной системой Linux, и подобная ей версия, md5, распространяется с системой FreeBSD. Инструментальные средства вычисления контрольной суммы MD5 будут обсуждаться снова в лекции "Некоммерческие наборы инструментов, предназначенные для судебного дублирования".

Реализация

Следующая команда вычислит контрольную сумму MD5-файлов вывода и сохранит их в файле с именем md5sums.txt.

forensic# md5sum-b * > md5sums.txt

В любой момент утилита Md5sum может проверять контрольные суммы MD5 любых файлов, если вы снабдите ее списком этих файлов. Следующая команда проверит контрольные суммы MD5 для списка файлов и сообщит о любом изменении в их содержании.

forensic# md5sum-c md5sums.txt

Carbonite

Инструмент и выполнять на большинстве систем с ядром Linux v2.2 (хотя он был разработан на RedHat и наилучшие результаты показал на подобной системе).

Поскольку процессы могут выполняться без связанных с ними двоичных файлов в файловой системе, традиционное силовое выключение машины уничтожило бы улики. Следовательно, процессы, скрытые с помощью команды kill -31 инструмента Knark, могли бы быть найдены, если бы было возможно проникнуть в ядро и исследовать таблицу процессов. Поэтому один из возможных способов бороться с комплектами LKM root состоит в использовании LKM-решений, в связи с чем и был создан инструмент Carbonite.

Реализация

Инструмент Carbonite должен компилироваться на системе, имеющей то же ядро, что и машина-жертва. Версию ядра можно, обычно, посмотреть с помощью следующей команды:

victim# uname-a

После того как надежная машина с такой же самой версией ядра, как у вашей машины-жертвы, найдена, разархивируйте содержимое пакета Carbonite и измените каталог в ней. Введите следующую команду, чтобы создать пакет:

forensic# make

Пакет компилируется, и создается файл carbonite.o. Скопируйте этот каталог на машину-жертву надежным способом (через диск или компакт диск). Затем Carbonite нужно установить в ядро, используя команду

victim# ./carbonite.sh

Когда Carbonite внесен в ядро, он временно замораживает систему, пока не выполнит свою миссию. Он создает каталог /tmp/CARBONITE, который будет содержать копию каждого процесса, выполняющегося на машине. Имена копий процессов будут CARBONITE.< Команда> < PID >, где < команда > - имя процесса и < PID > - ID процесса.

Создается дополнительный файл, CARBONITE.html, который может быть загружен в Web-браузер. Этот файл подобен файлу, созданному с помощью команды ps (рассматривался ранее), но поскольку он получен в результате прямого входа в ядро, то он более надежен и показывает все процессы, даже если они скрыты с помощью инструмента Knark.

Execve_Sniffer

Этот инструмент еще не выпущен публично; его дебют состоится в этой книге. Написанный Кейтом Джонсом (Keith J. Jones) инструмент execve_sniffer в большей степени является программой "доказательства-концепции", чем инструментом, "пригодным для часа пик", но его можно изменить так, чтобы удовлетворить определенные потребности. Инструмент execve_sniffer загружается как модуль ядра. Он "обертывает" системный вызов execve. После того как системный вызов запакован, все запросы к этой функции будут полностью зарегистрированы в виде сообщений ядра.

Чтобы понять, почему это действие важно, вы должны понять системный вызов execve. Каждый раз, когда в системе выполняется команда, командная строка передается в системный вызов execve для выполнения. Когда мы обертываем этот системный вызов, то можем сделать с информацией, которая передается в этот вызов, что захотим (подобно тому, что делает инструмент Knark, описанный в лекции "Черный ход и средства удаленного доступа"). Поскольку мы ребята хорошие, то хотим лишь сообщать о том, какая команда была выполнена, а затем передавать саму команду оригинальному системному вызову execve.

Вся эта работа может показаться неважной, если вы можете поместить в сеть анализатор сетевых потоков (sniffer) и видеть ту же самую информацию, но этот инструмент был разработан в ответ на все увеличивающееся использование Secure Shell (SSH) для шифрования связи. Поэтому запись каждой команды, выполненной в системе, может быть единственной возможностью справиться с шифрованием. Кроме того, мы рекомендуем после установления execve_sniffer скрыть его с помощью инструмента modhide.o, имеющегося в Knark, чтобы преступник его не обнаружил и не попытался выгрузить.

Следующий текст дает пример вывода инструмента execve_sniffer из системы RedHat v6.2 Linux.

Execve Sniffer Inserted
execve - user: 0 pid: 769 filename: /sbin/lsmod args: lsmod
execve - user: 0 pid: 770 filename: /usr/bin/w args: w
execve - user: 0 pid: 771 filename: /usr/sbin/tcpdump
args: tcpdump -s 65535 -n -w /tmp/.net
execve - user: 0 pid: 772 filename: /bin/dmesg args: dmesg

Как уже упоминалось, этот инструмент борется против команд взломщика, выполняющихся по зашифрованному каналу. Даже если взломщик выполняет команды, и нам не видно, что он набирает (через контроль сети), теперь мы можем видеть полное содержание того, что он выполняет.