Знай своего врага: II
 

Эта статья – вторая  из серии «Знай своего врага».
В первой были обсуждены методология, лежащая в основе одной из наиболее общих и универсальных угроз – Script Kiddie и средства, Script Kiddie применяемые.
Третья статья обсуждает, что случится, если они получат права рута. В особенности, как они будут маскировать свои действия  и что они будут делать дальше.
Данная статья фокусируется на том, как обнаружить эти попытки. Как и на войне, Вам необходимо следить за противником и знать, что он делает. Здесь мы обсудим то, что Вы можете определить с помощью системных логов (предпринималась ли попытка взлома по отношению к Вашей системе, для чего она предпринималась, какие средства применялись и была ли попытка успешной), а что - нет. Приведенные ниже примеры имеют отношение к Linux'у, но они применимы к любому виду UNIX'a. Имейте в виду, что не существует определенного способа отслеживания врага,  который бы гарантировал  Вам знание каждого его шага, но в качестве стартовой площадки эта статья  Вам подойдет.

Охраняйте Ваши логи.

Эта сатья не о том, как определить вторжение в Вашу систему, есть немало информации на эту тему. Если она Вас интересует, я рекомендую Вам следующие приложения:   Network Flight Recorder или swatch. Эта статья фокусируется на сборе информации. В особенности, как составить полное представление о том, что враг может сделать, просмотрев Ваши системные логи.  Но прежде чем обсуждать это, мы должны сначала обсудить, как оберегать Ваши логи. Они ничего не стоят, если вы не можете поручиться за их целостность. Ведь первое, что делает большинство взломщиков - подменяет лог-файлы на взломанной системе. Существует множество средств, позволяющих замести за собой следы, оставленные в логах (например, cloak) либо подменить демон, ведущий логи, на троян (например, troianed syslogd binaries). Итак, первый шаг в отслеживании Ваших логов заключается в их охране.
Это означает, что Вам необходим удаленный лог-сервер. Вне зависимости от того, как защищена Ваша система, Вы не можете поручиться за логи на взломанной системе. Взломщик может просто набрать  rm -rf /*  в Вашей системе, удалив все таким образом  с Вашего hard-диска. Это затруднит восстановление логов. Чтобы защитить себя от этого, Вы должны вести логи и на своей машине, и на удаленной. Я рекомендую под лог-сервер выделить отдельную машину, т.е. она должна только собирать логи с других систем. Этот сервер должен быть хорошо защищен, на нем должны быть выключены все сервисы, он должен позволять доступ только с консоли. (см. Armoring Linux ). Убедитесь, что 514 порт закрыт или прикрыт файрволом. Это защитит Ваш лог-сервер от получения неверной либо неавторизованной информации из Интернет о заходах на Ваш сервер.
Для тех из Вас, кто желает помучить подлеца, я рекомендую перекомпилировать демон syslogd так, чтобы он читал другой конфигурационный файл, например, /var/tmp/.conf. Таким образом, взломщик не сможет понять, где же находится настоящий конфигурационный файл. Это легко сделать, изменив /etc/syslog.conf в source code
на другой файл, который Вы выберете. Затем, установим наш новый конфигурационный файл так, чтобы вести логи и локально, и на удаленном  лог-сервере (см. пример). Убедитесь в том, что Вы поддерживаете стандартную копию конфигурационного файла  /etc/syslog.conf , который отмечает все заходы на сервер. Даже если этот конфигурационный файл сейчас бесполезен, такое дублирование логов не даст понять взломщику, где находится удаленный лог-сервер.
Когда же Вы захотите проверить целостность логов на локальной машине, Вам будет достаточно сверить их с логами на удаленной машине.
Другой способ заключается в  защищенном методе ведения логов. Необходимо заменить Ваш syslogd binary другим, проверяющем целостность системы и с более широким диапазоном опций.Например, syslog-ng, http://www.balabit.hu/products/syslog-ng.html.

Соответствие шаблону.

Просматривая записи в логах, Вы обычно можете определить, сканируются ли Ваши порты. Большинство Script Kiddies сканируют сеть для определения какой-либо одной уязвимости. Если Ваши логи показывают большое количество соединений,  открытых одной и той же удаленной системой на каком-либо одном порту, то это больше всего похоже на сканирование с целью взлома. На большинстве Линуксовых систем TCP Wrapper инсталлируется по умолчанию. Поэтому записи о таких содинениях мы можем найти в файле /var/log/secure.
Для других видов UNIX, мы можем вести логи по всем соединениям, запустив inetd  с флагом "-t". Этот демон более продвинутый, чем линуксовый, он ловит те сканы, которые пропускает линуксовый.
Типичный скан с целью влома может выглядеть так  (поиск wu-ftpd уязвимости):
/var/log/secure
Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200

Хост 192.168.11.200 сканирует нашу сеть, последовательно перебирая IP-адреса. Повторяющиеся соединения с 21 ftp-портом говорят о том, что цель сканирующего хоста - wu-ftpd-взлом.  Бывает, что сканирование периодически возобновляется после перерыва. Предположим, что некто написал код для взлома imap, тогда Вы скорее всего по Вашим логам почувствуете наплыв сканирований . В следующем месяце хитом может стать ftp-сканирование. Текущие взломы можно увидеть здесь -  http://www.cert.org/advisories Иногда сканирование имеет целью взлом сразу по нескольким уязвимостям, в таком случае Вы увидите в логах многочисленные соединения удаленной системы сразу к нескольким портам.
Имейте в виду, что если Вы не ведете логи по определенному сервису, то Вы не будете знать, сканируют ли Вас на предмет его уязвимости. Например, по большинству rpc-соединений по умолчанию логи не ведутся. Значит, нужно просто добавить многие сервисы в файл /etc/inetd.conf для сопровождения их TCP Wrapper'ом.   Например, Вы можете добавить запись относительно NetBus. Вы можете настроить TCP Wrapper для более защищенного запрета соединений и ведения логов. (См.  Intrusion Detection)

Что есть средство взлома ?

Иногда Вы можете определить средства, используемые против Вашей сети. Некоторые из основных средств сканируют с целью конкретного взлома, например ftp-scan.c.Если хотя бы один открытый порт или уязвимость обнаружены в Вашей сети, они скорее всего воспользуются одноцелевым, односторонним средством. Тем не менее, существуют средства, перебирающие несколько уязвимостей, два наиболее популярных из них - sscan и nmap. Они представляют собой две различные категории сканирующих средств. Я очень рекомендую попробовать их в своей сети, Вас ждет немало сюрпризов. :)

• sscan представляет из себя многоцелевое сканирующее средство, которым пользуются Script Kiddie и, возможно, оно одно из лучших. Sscan быстро проверяет сеть на наличие различных уязвимостей (включая cgi-bin). Он легко настраиваемый, Вы только указываете сеть и маску сети и можете отдыхать. Но! Чтобы его запустить, нужно быть рутом. Выходные данные очень легко интерпретируются (что делает его еще  более популярным): Он выдает сжатый отчет о многих уязвимых сервисах. Все, что Вам нужно сделать - запустить sscan, найти слово VULN в выходных данных и затем запустить "exploit du jour". Ниже приведен пример применения sscan'а против хоста mozart (127.17.6.30).

          --------------------------<[ * report for host mozart *
          <[ tcp port: 80 (http) ]>       <[ tcp port: 23 (telnet) ]>
          <[ tcp port: 143 (imap) ]>      <[ 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: root: account exists.
          --<[ *VULN*: mozart: sendmail will 'expn' accounts for us
          --<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
          --<[ *VULN*: mozart: linux mountd remote buffer overflow
          ---------------------------<[ * scan of mozart completed *

• Nmap - это средство, дающее Вам "сырые" данные. Оно не скажет Вам, какие уязвимости присутствуют на удаленной системе, но оно покажет Вам, какие порты открыты и Вы сможете определить слабые места в защите. Nmap сразу стал наиболее предпочитаемым сканером портов и неспроста. Он вобрал в себя лучшие черты многих сканеров портов: определение ОС, соединение нескольких опций,  UDP и TCP сканирование, рандомизацию и т.д. Тем не менее, от Вас потребуется мастерство, чтобы использоать это средство и интерпретировать данные. Ниже приведен пример nmap, запущенного против того же хоста:

          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
          37      open        tcp        time
          53      open        tcp        domain
          70      open        tcp        gopher
          79      open        tcp        finger
          80      open        tcp        http
          109     open        tcp        pop-2
          110     open        tcp        pop-3
          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 imapd[11635]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200
Apr 14 19:19:03 mozart ipop3d[11642]: 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=??? host=[192.168.11.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 telnetd[11682]: ttloop:  peer died: Invalid or incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed

Sscan также может быть использован для сканирования на предмет наличия cgi-bin уязвимостей. Логи по таким попыткам ведутся не syslogd, Вы найдете их в access_log:

/var/log/httpd/access_log
192.168.11.200 - - [14/Apr/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/Apr/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-bin/wwwboard.pl HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.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,SYN-ACK,ACK), а затем разорвано. Это происходит потому, что sscan действует на прикладном уровне. Sscan интересует не только, открыт ли ftp-порт, но и какой ftp-демон на нем запущен. Тоже относительно imap,pop и т.д.  Информацию такого же рода можно узнать с помощью sniffit - средства, обычно используемого для ворования паролей.
В приведенном ниже примере, установлено полное соединение для определения версии wu-ftpd, запущенного на удаленной системе. Если Вы видете в своих логах записи подобного рода, то Вас вероятнее всего сканируют с целью взлома каким-либо средством, способным определять путем установления с Вами полного соединения, что запущено на Вашем хосте.

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 Jun 9 10:43:14 EDT 1998) ready.

Nmap, как большинство сканеров портов, не интересует, что запущено на Вашей машине, но интересует, запущен ли определенный сервис. Для этого, nmap обладает рядом полезных опций, позволяющих определить вид соединения, включая SYN,  FIN,  Xmas, Null, etc. Детальное описание этих опций смотри на http://www.insecure.org/nmap/nmap_doc.html. В зависимости от их выбора сканирующим хостом, Ваши логи будут выглядеть по разному. Содинение, установленное с флагом -sT является полным соединением, поэтому в этом случае логи будут выглядеть также, как будто Вас сканировали sscan'ом. Но nmap по умолчанию сканирует больше портов.

/var/log/secure
Apr 14 21:20:50 mozart in.rlogind[11706]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.fingerd[11708]: connect from 192.168.11.200
Apr 14 21:20:51 mozart ipop2d[11709]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.rshd[11710]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: error: cannot execute /usr/sbin/gn: No such file or directory
Apr 14 21:20:52 mozart in.timed[11712]: connect from 192.168.11.200
Apr 14 21:20:52 mozart imapd[11713]: connect from 192.168.11.200
Apr 14 21:20:52 mozart ipop3d[11714]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.telnetd[11715]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.ftpd[11716]: connect from 192.168.11.200

Обратите внимание на опцию -D (decoy-западня, ловушка). Эта опция позволяет подменить адрес сканирующего хоста. Вы можете увидеть 15 различных IP-адресов в одно и тоже время, но настоящим может оказаться только один из них. Будет очень-очень трудно определить, какой же из них - неподдельный. Еще чаще выбирается опция -sS . Это опция скрытого сканирования, когда посылается только SYN пакет. Если удаленный хост ответит, соединение тут же обрывается RST. Логи в таком случае выглядят таким образом (обратите внимание, что здесь приведены только первые пять записей):

/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]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: 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

Обращайте внимание на все записи об ошибках. Так как SYN-ACK последовательность обрывается до установки полного соединения, демон не в состоянии определить систему-источник. Логи покажут, что Вас сканируют, но Вы не узнаете, кем. Эта ситуация усугубляется еще и тем, что большинство систем ( включая новые ядра Linux- 2.2 и последние 2.1), не ведут логи о таких ошибках. В ядрах 2.0.XX был баг - возврат accept() до установления "3-way handshake".
Nmap включает и другие скрытые опции: -sF -sX -sN. Записи о таком сканировании обычными демонами логов не ведутся, необходимо установить tcplogd, scanlogd or ippl.  Нкоторые коммерческие Firewalls также определяют и ведут логи по таким сканам (Я убедился в этом относительно Checkpoint Firewall 1). Обычный syslogd ведет полные логи только о сканировании с опцией -sT (полное соединение).

Получили ли они доступ ?

Этот вопрос должен возникнуть сразе после того, как Вы определили, что Вас сканируют и что их интересует.
Большинство сегодняшних взломов основано на buffer overflow (переполнении буфера, smashing the stack). Buffer overflow наступает тогда, когда программа( а чаще всего демон) получает больше данных, чем должна была получить, таким образом происходит переполнение критических областей памяти (thus overwriting critcical areas in memory). Затем выполняется определенный код, обычно дающий права рута. См. отличную статью ftp://ftp.technotronic.com/rfc/phrack49-14.txt.
Вы можете определить такую атаку  (например, mountd) по /var/log/messages ( либо /var/adm/messages для других разновидностей UNIX). Ниже приведен пример лога во время buffer_overflow-атаки на 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 192.168.11.200 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3?3?°^[?~@3?3?~K?°^F?~@??u?1?°^B?~@~E?ub?b^V¬<?t^F??t^K??°0??~HF???^°^B~
I^F??~IF^D°^F~IF^H°f1???~I??~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1?~IF^P°^P~IF^H°
f???~@°^A~IF^D°f?^D?~@?^D?L?R1?~IF^D~IF^H°f???~@~H?°?1??~@°????~@°????~@?.bin@~
I^F?.sh!@~IF^D1?~HF^G~Iv^H~IF^L°^K~I?~MN^H~MV^L?~@1?°^A1??~@?E??????Privet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E

Трудно определить, была ли попытка взлома успешной. Один из способов - после попытки взлома сначала проверить, установлено ли с Вами соединение этим удаленным хостом. Если они успешно залогнились с удаленного хоста, значит, доступ получили. Другой способ - поискать в /etc/passwd новые accounts: "moof", "rewt", "crak0", "w0rm".  Эти эккоунты с uid=0 добавляются некоторыми скриптами взлома. Как только взломщик получил доступ,обычно он сначала подчищает логи и заменяет Ваш syslogd на троян (см. "Знай своего врага: III"). В таком случае Ваши логи Вам ничего не расскажут. Но это тема для другой статьи. Я же настоятельно рекомендую посмотреть http://www.cert.org/nav/recovering.html.
Для поиска аномалий в моих логах, я написал shell-срипт (Bourne shell script, Korn shell script), сканирующий мои логи.Больная детальная информация о мониторинге лог-файлов у Marcus Ranum.

Заключение

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