На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Какое средство применяется?


Иногда вы можете достаточно точно определить, какое средство использовано для сканирования вашей сети. Большинство простых средств сканирования, таких как ftp-scan.c, исследует сеть в поисках
конкретной уязвимости. Если в вашей сети наблюдается интерес к ка­кому-то определенному порту, наиболее вероятно, что используется одно из таких специализированных средств. Существуют, однако, и более универсальные средства, проверяющие наличие сразу несколь-кихуязвимостей. Два наиболее известных - это sscan (автор -jsbach) и nmap (автор — Fyodor). Я выделил именно эти два средства, так как они представляют две «категории» сканеров. Я настойчиво рекомен­дую вам изучить собственные сети этими средствами результаты могут вас удивить.
sscan достаточно старый сканер (ему уже больше года), и он рассмотрен здесь лишь в качестве примера. Для сканирования вашей собственной сети на предмет наличия уязвимос-тей я рекомендую использовать Nessus, распространяемый с открыты­ми исходными текстами.
Sscan, часто применяемый Script Kiddie, является многоцелевым
сканером. Он проверяет сеть на наличие набора заранее определенных уязвимостей. Это настраиваемое средство: оно позволяет вам добавить
описание новых типов уязвимостей. Вы просто сообщаете ему адрес
сети, и sscan делает остальную работу самостоятельно.
Однако для его использования необходимо иметь права root в
системе, на которой он запускается. Выдаваемая им информация чрез­вычайно легко интерпретируется, что и сделало его Настолько попу­лярным. Он выдает сводную информацию о многих уязвимых серви­сах. Все, что вам надо — это запустить сканирование выбранной сети, проанализировать выходную информацию (найти с помощью grep слово «VULN») и запустить соответствующий «эксплоит дня». Ниже приведен результат работы sscan, запущенного на анализ системы под
названием mozart.
(172.17,6.30).
otto #./sscan -о 172.17.6.30
- *   report   for host mozart
<[   tcp port:   80    (http)    ]> <[   tcp port:   23    (telnet) ]>
52

<[ tcp port:  143 ]> <[ tcp port:  110   (pop-3) ]>
<[  tcp port:   111   (sunrpc)   ]> <[ tcp port:   79 (finger)
<[   tcp port:   53    (domain)    ]> <[   tcp port:   25   (smtp) ]>
<[ tcp port: 21 (ftp) ]>'
—<[   *OS*:  mozart:   os detected:   redhat  linux 5.1
mozart:  VULN:   linux box vulnerable to named overflow.
<[ *CGI*: 172.17,6.30: tried to redirect a /cgi-bin/phf request.
<[  *FINGER*: mozart: account exists.
•<[ *VULN*: mozart: sencmail will 'expn* accounts for us
<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
mozart: linux remote buffer overflow
---* scan of mozart com­pleted *
Nmap входит в группу средств, добывающих «чистые данные». Он не пытается найти уязвимости, а просто сообщает, какие порты открыты, оставляя принятие решения об их защищенности вам. Nmap быстро стал самым популярным сканером и на то есть объективные причины. Он соединяет в одном средстве черты лучших сканеров, включая определение типа операционной системы, различные спосо­бы построения пакетов, сканирование как UDP, так и TCP, рандомиза­цию и т. д.
Однако необходимо обладать достаточными знаниями в области
сетевых технологий, чтобы интерпретировать полученные данные. Ниже приведен пример работы запущенного для изучения той
же самой системы.
otto #nmap -sS -0 172.17.6.30
Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on mozart (172.17.6.30): Port State Protocol Service 21 open tcp ftp
23 open tcp telnet 25 open tcp smtp
53

37  open tcp time 53 open tcp domain 7 0  open tcp gopher
79 open tcp finger
80 open  tcp http
109 open tcp pop-2
110 open tcp
111 open tcp sunrpc 143  open tcp imap2
513 open tcp login
514 open tcp shell
635  open  tcp unknown
2049 open tcp nfs
TCP      Sequence      Prediction:       Class=truly random
Difficulty=9999999    (Good luck!)
Remote operating system guess:   Linux 2.0.35-36
Nmap run completed — 1 IP address   (1 host up) scanned
in 2 seconds
Просматривая ваши регистрационные журналы, вы можете оп­ределить, какое из этих средств было использовано для изучения ва­шей системы.
Чтобы сделать это, вам необходимо понять механизмы работы этих средств. Сканирование при помощи sscan отражается в регистра­ционных журналах, как приведено ниже (это режим по умолчанию, без внесения изменений в конфигурационные файлы):
/var/log/secure
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200
Apr  14   19:18:56 mozart connect from
192.168.11.200
Apr 14 19:18:56 mozart connect from
192.168.11.200
Apr 14  19:18:56 mozart connect from
192.168.11.200
Apr 14 19:18:56 mozart connect from
192.168.11.200
54

Apr   14   19:18:56  mozart :   connect from
192.168.11.200
Apr   14   19:19:03   mozart ■ connect from
192.168.11.200
Apr 14  19:19:03 mozart imapd[11643] :  connect from
192.168.11.200
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]:  connect from
192.168.11.200
/var/log/maillog
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=??? ho3t-C192.168.ll.200]
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory
while reading line user=??? host-[192.168.11.200]
Apr    14    21:02:05    mozart    sendmail[11675]: NOQUEUE: [192.168.11.200]:
expn root
/var/log/messages
Apr 14 21:03:09 mozart ttloop: peer
died:   Invalid or _
incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688] : FTP session closed
Sscan также определяет уязвимости cgi (common gateway inter­face).
Эти попытки не будут зафиксированы в журналах syslogd, вы найдете их в файле access_log. Включаем и этот пример для иллюстра­ции.
/var/log/httpd/access_log
192.168.11.200 •■ [14/Арг/1999:16:44:49 -0500] «GET /cgi-bin/phf HTTP/1.0» 302 192
192.168.11.200   • [14/Apr/1999:16:44:49   -0500] «GET
/cgi-bin/Count.cgi HTTP/1.0» 404 170
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/test-cgi HTTP/1.0» 404 169
192.168.11.200 • [14/Арг/1999:16:44:49 -0500] «GET /cgi-bin/php.cgi HTTP/1.0» 404 168
192.168.11.200 • [14/Apr/1999.:16:44:49 -0500] «GET /cgi-bin/handler HTTP/1.0» 404 168
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/webgais   HTTP/1.0»   404 168
192.168.11.200 •■' [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/websendmail HTTP/1.0» 404 172
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/webdist.cgi HTTP/1.0» 404 172
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/faxsurvey   HTTP/1.0»   404 170
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/htmlscript HTTP/1.0» 404 171
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/pfdisplay.cgi HTTP/1.0» 404 174
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-bin/perl.exe HTTP/1.0»  404 169
192.168.11.200 • [14/Apr/1999:16:44:49 -0500] «GET /cgi-biri/wwwboard.pl HTTP/1.0» 404 172
192.168.11.200 • [14/Apr/1999:16:44:50 -0500] «GET /cgi-bin/ews/ews/architext_guery.pl HTTP/1.0» 404 187
192.168.11.200 • [14/Apr/1999:16:44:50 -0500] «GET /cgi-bin/jj HTTP/1.0» 404 163
Обратите внимание, что для каждого порта создается полноцен­ное соединение SYN-ACK, АСК), которое затем закрывается. Это происходит потому, что sscan в данном режиме работает на уровне приложений. Sscan не просто определяет, открыт ли порт ftp, но и ка­кой именно демон ftp запущен. То же самое можно сказать и про imap, pop и т. д. Это легко увидеть при помощи sniffit — средства, широко применяемого для перехвата паролей.
mozart  $   cat 172.17.6.30.21-192.168.11.200.7238
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17] (1) Tue Fin 9 10:43:14 EDT 1998) ready.
Как видно из приведенного выше примера, для определения вер­сии также создавалось полноценное соединение. Когда вы ви­дите в ваших регистрационных журналах такие следы, это означает,
что применялось средство поиска уязвимостей. Такие программы всегда создают полноценные соединения для определения версий ис­полняемого программного обеспечения.
Nmap, как и большинство сканеров-портов, не интересуется, ка­кая версия программного обеспечения запущена, он определяет, от­крыт ли соответствующий порт. Для этого nmap снабжен мощным на­бором опций, позволяющих вам задать тип используемого соедине­ния, включая SYN, FIN, Xmas, Null и т. п. Детальное описание этих оп­ций можно получить по адресу
doc.html. Эти опции влияют на вид записей в ваших регистрационных журналах в зависимости от использованного атакующим набора пара­метров.

Соединение с флагом -sT является полноценным и поэтому за­писи в регистрационных журналах будут похожи на записи после при­менения с той лишь разницей, что nmap проверяет большее ко­личество портов.
/var/log/secure
Apr 14 21:25:08 mozart in . rshd [ 11717 ] : warning: can't get  client  address:   Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717] : connect from unknown Apr 14 21:25:09 mozart in. timed [11718] : warn­ing: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in . timed [ 11718 J : connect from unknown Apr 14 21:25:09 mozart imapd[11719] : warning: can't  get  client  address:   Connection reset by peer
Apr    14    21:25:09   mozart    imapd [ 11719 ] :    connect from
unknown
Apr 14 21:25:09 mozart ipop3d[11720]: warning: can't get  client  address:   Connection reset by peer
Apr   14   21:25:09   mozart    ipop3d[11720]:    connect from
unknown
Apr   14   21:25:09   mozart    in.rlogind[11722]: warning: can't get  client  address:   Connection reset by peer Apr 14 21:25:09 mozart in.rlogind[11722] :  connect from
unknown
Еще один момент, о котором следует помнить, это опция -D (decoy).
Павел Даниэль Шрейн
Эта опция позволяет установить для сканера поддельный обрат­ный адрес. Вы можете увидеть соединения с 15 различными адресами одновременно, но только один из них будет настоящим. Чрезвычайно трудно определить, который из 15 источников является истинным. Более того, при сканировании портов часто используется опция -sS.
Этот режим позволяет осуществить скрытное (стеле) сканирова­ние. В этом случае сканер посылает только а после получе­ния ответа от удаленной системы сразу же его разрывает посылкой па­кета с флагом RST.
/var/log/secure
Ух! Здесь ничего нет! Причина кроется в том, что подсистема ре­гистрации записывает данные только о полностью установленных со­единениях. Так как запускался с параметром sS, полноценное TCP-соединение не устанавливалось, и факт сканирования, таким об­разом, зафиксирован не был. Именно по этой причине данный тип ска­нирования является скрытным (стеле) — он не фиксируется в систем­ных журналах. Для систем на базе Linux со старыми версиями ядра (а именно: 2.0.x) неполные соединения фиксируются, но как несостояв­шиеся. Регистрационные журналы системы с таким ядром и нроска-пированные с параметром -sS выглядят следующим образом (ПРИ­МЕЧАНИЕ: приведены только первые пять записей):
/var/log/secure
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client
address:  Connection reset by peer
Apr 14 21:25:08 mozart connect from
unknown
Apr 14 21:25:09 mozart in. timed [ 11718 j : warning: can't
get client
address: Connection reset by peer
Apr 14 21:25:09 mozart connect from
unknown
Apr 14 21:25:09 mozart warning: can't
get client
address: Connection reset by peer
Apr 14  21:25:09 mozart :   connect from
unknown
Apr 14 21:25:09 mozart ipop3d[11720] : warning: can't get client
address:  Connection reset by peer
Apr 14 21:25:09 mozart ipop3d[11720] : connect from unknown .
Apr 14 21:25:09 mozart in. rlogind [11722 ] : warning: can't get client
address:   Connection reset by peer
Apr 14 21:25:09 mozart in.rlogind[11722]: connect from unknown
Обратите внимание на ошибки в установлении соединения. Так как последовательность SYN-ACK прерывается и установка соедине­ния не завершена, демон не может определить систему-источник. Из регистрационных журналов видно, что вас сканируют, но невозможно определить кто. Еще более тревожным является тот факт, что боль­шинство систем (включая Linux с новыми ядрами) не фиксирует эти ошибки в журналах. Как сказал Fyodor, «... основываясь на сообщени­ях 'connection reset by реег'». Это особенность Linux 2.0.ХХ. Практиче­ски все остальные системы (включая ядра 2.2 и поздние ядра 2.1) не показывают ничего. Ошибка (accept(), возвращающий управление до завершения трехшагового процесса установления соединения) ис­правлена.»
Nmap имеет и другие опции для осуществления скрытого скани­рования, такие как -sF, -sX, -sN, использующие различные флаги.
Вот так выглядят регистрационные журналы после такого ска­нирования:
/var/log/secure
И снова, обратите внимание, что журналы пусты! Страшно поду­мать, вы но даже не подозреваете об этом! Все три типа сканирования дают одинаковые результаты, но вы можете зафик­сировать только первый — с опцией -sT (полное соединение). Чтобы обнаружить факты скрытного сканирования, вам придется использо­вать специальные средства регистрации, такие как tcplogd или Некоторые коммерческие межсетевые экраны также могут обнаружи­вать и фиксировать попытки такого сканирования, в частности IPFilter, SunScreen или FireWall-1.
Получили ли они доступ?
После того, как вы определили факт сканирования, следующий вопрос, которым вы задаетесь: Смогли ли они проникнуть внутрь? Большинство современных эксплоитов основано на переполнении бу-
фера (известном также, как срыв стека). Говоря простым языком, пе­реполнение буфера возникает, когда программа (как правило, демон) получает на вход данные большего размера, чем ожидалось, перезапи­сывая критичные области памяти. В результате выполняется некото­рый код, дающий права привилегированного пользователя (root).
Дополнительную информацию о переполнении буфера можно найти в прекрасной главе (автор - Alephl) по адресу ftp://ftp.tech-notronic.com/rfc/phrack49-14.txt.
Обычно следы атак на переполнение буфера можно обнаружить в файле /var/log/messages (или /var/adm/messages для других разно­видностей Unix) для атак типа mountd. Вы также можете обнаружить
аналогичные следы в файле maillog, если атака осуществлена на imapd. В регистрационных журналах это выглядит так:
Apr 14 04:20:51 mozart mountd[6688] : Unauthorized access by NFS
client 192.168.11.200.
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together
Apr 14 04:20:51 mozart mountd[ 6688] : Blocked attempt of
to mount
Если вы видите нечто подобное в ваших регистрационных жур­налах, это означает, что кто-то пытался использовать уязвимость ва­шей системы. Очень сложно определить, была ли попытка эксплоита
успешной. Один из путей сделать это — сразу после попытки примене­ния эксплоита посмотреть, нет ли соединений удаленной системы с вашей. Если имеет место успешный вход из удаленной системы, то по­пытка применения эксплоита оказалась удачной.
Другой признак — появление новых пользователей типа «moofV, «rewt>, «сгакО» или «wOrm» в файле /etc/passwd. Эти пользователи (с UID=0) добавляются многими распространенными сценариями-экс-плоитами. Как только черная шляпа получила доступ к вашей систе­ме, первая вещь, которую она обычно делает, — это очистка регистра­ционных журналов и установка подсистемы ре­гистрации (см. «Они получают права root»).
С этого момента вы не сможете получать регистрационную ин­формацию от вашей системы, так как все уже скомпрометировано. Что делать дальше, является темой отдельной статьи. А тем временем я ре­комендую вам изучить документ http://www.cert.org/nav/recovering.html.
Чтобы облегчить себе процесс поиска аномалий в регистрацион­ных журналах, я написал специальный сценарий (см. ниже), который осуществляет проверку журналов. Дополнительную информацию по разбору и сортировке журналов можно получить из письма, опублико­ванного Маркусом Ранумом.
Korn shell script
Заключение
Регистрационные журналы вашей системы могут очень много
рассказать о вашем противнике. Однако первым шагом должно стать обеспечение их целостности. Одним из лучших решений этой пробле­мы является организация выделенного собирающего ре­гистрационную информацию со всех систем. После того, как журналы защищены, вы можете использовать их для поиска в них характерных последовательностей. На базе этой информации вы сможете опреде­лить, какие цели преследует черная шляпа и, возможно, какими средствами она пользуется.
Полученные сведения помогут вам наилучшим образом органи­зовать защиту вашей системы.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика