Михаил Фленов СанктПетербург бхвпетербург 2010 удк 681 06 ббк 32. 973. 26018. 2 Ф69
 Скачать 3.69 Mb.
|
|
lsof С помощью этой команды можно определить, какие файлы и какими поль- зователями открыты в данный момент. Результат ее выполнения приведен в листинге 12.2. Листинг 12.2. Результат выполнения команды lsof COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root cwd DIR 3,2 4096 2 / init 1 root rtd DIR 3,2 4096 2 / init 1 root txt REG 3,2 26920 635256 /sbin/init init 1 root mem REG 3,2 89547 553856 /lib/ld-2.2.5.so init 1 root 10u FIFO 3,2 195499 /dev/initctl keventd 2 root cwd DIR 3,2 4096 2 / keventd 2 root rtd DIR 3,2 4096 2 / kapmd 3 root 10u FIFO 3,2 195499 /dev/initctl Это далеко не полный результат. Даже если в данный момент вы один рабо- таете с системой, количество открытых файлов может исчисляться парой де- сятков , и число их заметно растет, если в системе несколько пользователей, ведь один файл может открываться несколько раз каждым из них. Это каса- ется в основном системных конфигурационных файлов. 12.5.2. Системные текстовые журналы Следующие журналы — это текстовые файлы. Их можно без проблем про- сматривать такими командами, как cat , или любыми текстовыми редакторами. В файле /var/log/messages находится основная информация о заходах пользо- вателей , о неверных авторизациях, остановках и запусках сервисов и многое другое . В один документ все подобные события поместиться не могут, иначе он будет нечитаемым, поэтому в папке /var/log/ могут находиться файлы с именами messages.X, где Х — это число. Этот журнал — один из самых главных для любого администратора. Если взломщик пытается подобрать пароль, то вы сможете заметить быстрый рост этого файла и появление большого количество записей о неверной авториза- ции . На рис. 12.1 показан пример содержимого файла. Следующий журнал расположен в файле /var/log/secure. Что в нем такого особенного ? Это самый основной журнал, который нужно проверять макси- Глава 12 378 мально часто, и каждой записи нужно уделять особое внимание. В этом фай- ле отображается, под каким именем и с какого адреса пользователь вошел в систему. Например, на сервис FTP может подключаться главный бухгалтер. Если вы увидели, что он пользуется сервисом, но при этом журнал показыва- ет чужой IP-адрес, то это должно стать поводом для беспокойства. Рис . 12.1. Снимок экрана с выведенным на него файлом /var/log/messages В этом же файле отображается информация о внесении изменений в список пользователей или групп. Злоумышленники очень редко используют запись root для своих злобных целей и заводят какую-нибудь более незаметную, с ну- левым идентификатором. Если это сделано не руками, а с помощью команды Linux, то вы в журнале /var/log/secure увидите подозрительные изменения. Хакеры , конечно же, знают о таких уловках, поэтому корректируют список вручную , ведь это не так уж и сложно — добавить по одной записи в файлы /etc/passwd и /etc/shadow. Но даже в этом случае вы почувствуете неладное, когда увидите запись о том, что в систему вошел пользователь, которого вы не создавали. Чтобы реагировать на подозрительные записи, вы должны быть вниматель- ны . Самые опытные и крайне опасные хакеры используют очень интересные методы . Например, в вашей системе есть пользователь robert. Хакер видит эту запись и добавляет пользователя с именем rodert. Разница всего лишь в третьей букве, и если быть невнимательным, то ее и не заметишь, что по- зволит взломщику безнаказанно гулять по вашему компьютеру. Мониторинг системы 379 Журнал почтового сервера SendMail находится в файле /var/log/maillog. В нем можно увидеть строки примерно следующего вида (здесь три строки представляют собой одну строку журнала): Jan 16 13:01:01 FlenovM sendmail[1571]: j0GA11S01571: from=root, size=151, class=0, nrcpts=1, msgid=<200501161001.j0GA11S01571@flenovm.ru>, relay=root@localhost Из этого файла вы можете узнать, кто, когда и кому отправлял сообщения. Вспоминается случай, когда один администратор после того, как взломали его сервер, вручную осматривал все директории на предмет чужих файлов. Не проще ли проанализировать журнал, где все записано? Если злоумыш- ленник не подчистил журналы до выхода из системы, то можно узнать доста- точно много. На журналы надеяться можно, но, все же, это не очень надежно. Умные хаке- ры всегда заметают свои следы и уничтожают ненужные записи из журналов. Поэтому и ручной осмотр может пригодиться, но первым делом стоит прове- рить журнал. 12.5.3. Журнал FTP- сервера Войдя в систему, взломщики нередко закачивают на сервер собственные программы для повышения своих прав или для открытия потайных дверей. Для закачки можно использовать протокол FTP. Кто именно подключался к серверу, можно узнать из файла /var/log/secure. А вот что закачивали — подскажет /var/log/xferlog. О журнале FTP-сервера мы уже немного говорили в разд. 10.3.5. Теперь познакомимся с ним поближе. Журнал FTP-сервера текстовый, как и у почтового сервера, но мы его рас- сматриваем отдельно. Из моей практики, если вы используете сервис FTP, то именно он чаще всего приводит к проблемам. Нет, программа достаточно хороша , но злоумышленник чаще всего стремится получить доступ к учетной записи с правами на FTP, чтобы иметь возможность размещать свой боевой софт на сервере. С помощью анализа журнала вы быстро узнаете, кто и что закачивал Посмотрим пример строки из файла /var/log/xferlog (здесь опять длинная строка разбита на две): Sun Jan 16 13:21:28 2005 1 192.168.77.10 46668 /home/flenov/sendmail.cf b _ o r flenov ftp 0 * c Из нее видно, что 16 января в 13:21 пользователь с адреса 192.168.77.10 ска- чал файл /home/flenov/sendmail.cf. Глава 12 380 Протокол FTP является наиболее опасным, потому что через него злоумыш- ленник может скачать секретные данные (например, файл с паролями) или положить на сервер свою программу (в частности, rootkit или трояна). Необ- ходимо научиться понимать каждую запись, чтобы знать, что происходит с файлами в системе. Давайте рассмотрим каждый параметр в журнале: полная дата, которая состоит из дня недели, месяца, числа, времени и года; продолжительность сеанса или время, потраченное на скачивание/зака- чивание файла; имя или IP-адрес удаленного хоста; размер файла в байтах; полный путь к файлу, который был скачан или закачан; тип передачи — буква a (символьная) или b (бинарная); символ , определяющий специальные действия над файлом: • C — сжат; • U — разархивирован; • T — обработан программой tar; • _ — не было никаких действий; символ , определяющий направление передачи: o (скачивание с сервера) или i (закачивание на сервер); символ , определяющий тип пользователя: a (анонимный), g (гость) или r (действительный); локальное имя пользователя. Для анонимных пользователей здесь можно увидеть номер ID; имя сервиса, обычно это слово ftp ; способ аутентификации. Здесь можно увидеть 0, если определение под- линности отсутствовало, или 1 в случае идентификации по RFC 931; идентификатор пользователя. Если он не определен, то можно увидеть звездочку ; символ , определяющий состояние передачи: c (прошла успешно) или i (была прервана). Если вы никогда не работали с журналом FTP, то советую сейчас остано- виться на минуту и внимательно изучить строку примера, показанную выше, и записи из вашего журнала. Вы всегда должны подходить к проблеме уже подготовленным , а не изучать ее после появления, иначе вы проиграете. Мониторинг системы 381 12.5.4. Журнал прокси - сервера squid Основным журналом прокси-сервера squid является /var/log/squid/access.log. Это текстовый файл, в котором каждая строка состоит из следующих полей: время начала соединения или события; продолжительность сессии; IP-адрес клиента; результат обработки запроса. Здесь может быть одно из следующих зна- чений : • TCP_HIT — в кэше найдена нужная копия; • TCP_NEGATIVE_HIT — объект кэширован негативно, получена ошибка при его запросе; • TCP_MISS — объект не найден в кэше; • TCP_DENIED — отказ в обслуживании запроса; • TCP_EXPIRED — объект найден, но устарел; • TCP_CLIENT_REFRESH — запрошено принудительное обновление; • TCP_REFRESH_HIT — при попытке обновления сервер сообщил, что объ- ект не изменился; • TCP_REFRESH_MISS — после попытки обновления сервер вернул новую версию объекта; • TCP_REF_FAIL_HIT — объект из кэша устарел, а новую версию получить не удалось; • TCP_SWAPFAIL — объект должен находиться в кэше, но он не найден; количество байт, полученных клиентом; метод запроса — GET , POST , HEAD или ICP_QUIERY ; URL-адрес запрашиваемого объекта; поле ident (знак минус ( - ), если оно недоступно); результат запроса к другим кэшам: • PARENT_HIT — объект найден; • PARENT_UDP_HIT_OBGECT — объект найден и возвращен в UDP-запросе; • DIRECT — объект запрошен с оригинального сервера; тип содержимого MIME. Когда в главе 9 мы говорили о прокси-сервере squid, то упоминали и о других журналах : cache.log и useragent.log. Глава 12 382 12.5.5. Журнал WEB- сервера Сервер Apache хранит свои журналы в файлах access.log и error.log, которые расположены в директории /var/log/httpd. Эти журналы позволяют узнать об активности и доступе пользователей. С другой стороны, журналы текстовые и легко читаемые. Любой хакер может просмотреть их. А так как в журнале сохраняются пароли, с которыми пользо- ватели получили доступ к серверу, то хакер легко их может вычислить. Отказаться совсем от ведения журнала нельзя. Но необходимо сделать все возможное , чтобы он не был доступен злоумышленнику. Как минимум, я всегда изменяю расположение журнала по умолчанию. По моим наблюде- ниям , редко кто смотрит файл httpd.conf, большинство сразу лезут в каталоги по умолчанию. Если журналов нет, то хакер думает, что они отключены. Итак , в директории /var/log/httpd создайте пустые файлы access_log, access_log.1, access_log.2, access_log.3, access_log.4, error_log, error_log.1, error_log.2, error_log.3 и error_log.4. Для большей правдоподобности в них можно поместить копию реальных данных, только убедитесь, что там нет важной информации. Правда по дате изменения и по строкам внутри файла злоумышленник легко увидит, что данные старые, но не догадается, что эта информация только для отвода глаз. Главное, чтобы даты изменения файла и формирования записей в нем совпадали. Для упрощения создания подобных файлов можно на время включить жур- налы в директории по умолчанию, чтобы в них появилась информация, а по- том отключить. После этого измените директивы ErrorLog и CustomLog в файле конфигура- ции httpd.conf сервера Apache, указав другую директорию для хранения жур- налов . Такой простой метод позволяет затуманить мозги большинству взломщиков 12.5.6. Кто пишет ? Записью в журналы, находящиеся в директории /var/log, занимаются демоны syslogd и klogd, но в программе setup при настройке автоматически загру- жаемых сервисов вы увидите только первый. Настройки автозапуска syslogd влияют и на загрузку klogd. Если вы используете изолированную систему или просто не нуждаетесь в протоколировании событий, происходящих в систе- ме , то можете отключить эти сервисы, чтобы они не расходовали процессор- ное время. Для сервера я не рекомендую этого делать. Если сейчас вы еще не прочувствовали необходимость использования журналов, то после первой проблемы или взлома системы вы осознаете все их преимущества. Мониторинг системы 383 Программа syslogd сохраняет в файлах журналов всю информацию о сооб- щениях системы. Программа klogd предназначена для сохранения сообщений ядра . Настройки журналов находятся в файле /etc/syslog.conf. Пример содер- жимого файла можно увидеть в листинге 12.3. Листинг 12.3. Файл конфигурации программы syslogd # Log all kernel messages to the console. # Logging much else clutters up the screen. # Выводить все сообщения ядра на экран. # Вывод других сообщений создаст на экране беспорядок. #kern.* /dev/console # Log anything (except mail) of level info or higher. # Don't log private authentication messages! # Протоколировать в указанный файл все сообщения уровня info и выше. # Исключения составляют письма, сообщения аутентификации и демона cron. *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. # Файл authpriv содержит ограниченный доступ. authpriv.* /var/log/secure # Log all the mail messages in one place. # Сохранять все события почтовой системы в указанное место. mail.* /var/log/maillog # Log cron stuff. # Протоколировать сообщения cron. cron.* /var/log/cron # Everybody gets emergency messages. # Все получают критические сообщения. *.emerg * # Save news errors of level crit and higher in a special file. # Сохранять сообщения новостей уровня crit (критический) и выше # в специальный файл. Глава 12 384 uucp,news.crit /var/log/spooler # Save boot messages also to boot.log. # Сохранять сообщения, происходящие во время загрузки в указанный файл. local7.* /var/log/boot.log Назначение директив легко можно проследить по комментариям. Все они имеют вид: название.уровень В качестве названия выступает имя параметра, который надо протоколиро- вать . Это могут быть следующие категории сообщений: kern — от ядра; auth — о нарушении безопасности и авторизации; authpriv — об использовании привилегированного доступа; — от почтовых программ; cron — от планировщиков задач cron и at ; deamon — генерируемые сервисами; user — от пользовательских программ; uucp — UUCP-сообщения (UNIX To UNIX Copy, копирование с UNIX на UNIX). В настоящее время практически не используется; news — из новостей; lpr — с принтеров. Уровень может быть одним из следующих: * — протоколировать все сообщения системы; debug — отладочная информация; info — информационные сообщения; notice — уведомления; warn — предупреждения; err — ошибки; crit — критические сообщения; alert — требуется немедленное вмешательство; emerg — авария, дальнейшая работа невозможна. В журнал попадают сообщения указанного уровня и выше. Например, уста- новка значения err определяет, что в журнал будут попадать сообщения уровней err , crit , alert и emerg Мониторинг системы 385 Чем больше ошибок вы сохраняете, тем выше нагрузка на жесткий диск, да и расход ресурсов увеличивается. Для большей эффективности функциони- рования системы раздел /var, на котором хранятся журналы, лучше всего пе- ренести на отдельный винчестер. Таким образом, запись в журналы и работа ОС сможет происходить параллельно. Но вы должны быть уверенными, что раздел /var содержит достаточно дискового пространства. Я уже говорил, что в своих системах убираю журналы из расположения по умолчанию , что усложняет хакеру жизнь. Но этого недостаточно. Опытный взломщик просмотрит конфигурационный файл /etc/syslog.conf и найдет но- вое расположение журналов. Но мы можем поступить еще умнее, и для этого достаточно штатных средств ОС Linux. В моей системе сервис cron раз в час запускает процесс, который делает резервную копию директории /var. Таким образом, если хакер подчис- тит журнал, я легко смогу определить его по резервной копии. Если у вас есть возможность установить в сети еще один Linux-сервер, то можно все сообщения журнала отправлять на специально выделенный ком- пьютер , что будет еще более выгодным. Чтобы хакер смог подправить жур- нал , ему придется взламывать еще один сервер. А если он используется толь- ко для протоколирования и никаких лишних портов на нем не открыто, то взлом может оказаться затруднительным. Для журналирования по сети в файле /etc/services должна иметься строка syslog 514/udp Кроме того, в файле /etc/syslog.conf должна присутствовать директива сообщения @адрес Первый параметр указывает, какие сообщения нужно отправлять на сервер. Если вы хотите пересылать всю информацию, то в качестве этого параметра указывается *.* , если только критические, — то *.crit Второй параметр — это адрес сервера, на который будут отправляться сооб- щения журналов. Например, если вы хотите, чтобы все сообщения отправля- лись на сервер log.myserver.com, то добавьте строку: *.* @log.myserver.com Но тут есть одна проблема — для определения IP-адреса необходим DNS. При загрузке системы сервис syslogd стартует раньше DNS, поэтому опреде- ление адреса окажется невозможным. Чтобы решить эту задачу, соответствие IP-адреса и имени сервера можно прописать в файле /etc/hosts. И последнее. На сервере служба syslogd должна быть запущена с ключом –r , который позволяет получать сообщения по сети и сохранять их в журнале. Для этого нужно изменить сценарий запуска сервиса. Все сценарии хранятся Глава 12 386 в директории /etc/rc.d/init.d/, и для syslogd это файл syslog, основное содер- жимое которого можно увидеть в листинге 12.4. Листинг__12.4._Содержимое_файла__/etc/rc.d/init.d/syslog'>Листинг 12.4. Содержимое файла /etc/rc.d/init.d/syslog #!/bin/bash . /etc/init.d/functions [ -f /sbin/syslogd ] || exit 0 [ -f /sbin/klogd ] || exit 0 # Source config # Загрузка конфигурационного файла if [ -f /etc/sysconfig/syslog ] ; then . /etc/sysconfig/syslog else SYSLOGD_OPTIONS="-m 0" KLOGD_OPTIONS="-2" fi RETVAL=0 umask 077 start() { echo -n $"Starting system logger: " daemon syslogd $SYSLOGD_OPTIONS RETVAL=$? echo echo -n $"Starting kernel logger: " daemon klogd $KLOGD_OPTIONS echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/syslog return $RETVAL } stop() { # Команды остановки сервиса } rhstatus() { Мониторинг системы 387 # Команды вывода состояния } restart() { stop start } Самое интересное спрятано в следующих строчках: if [ -f /etc/sysconfig/syslog ] ; then . /etc/sysconfig/syslog else SYSLOGD_OPTIONS="-m 0" KLOGD_OPTIONS="-2" fi Здесь происходит проверка. Если файл /etc/sysconfig/syslog существует, то исполь- зуются параметры загрузки из этого файла, иначе они явно задаются в строке SYSLOGD_OPTIONS="-m 0" Здесь в кавычках указываются параметры. Чтобы добавить ключ –r , измени- те строку следующим образом: SYSLOGD_OPTIONS="-m 0 -r" Если файл /etc/sysconfig/syslog существует, то в нем будет такая же строка. В этом случае вам достаточно внести изменения в этом файле, и не надо бу- дет трогать сценарий запуска /etc/rc.d/init.d/syslog. Использование выделенного сервера для сохранения сообщений из журналов позволяет сохранить записи, но при этом делает их доступными для всеобще- го просмотра. Дело в том, что сообщения передаются по сети в незашифро- ванном виде. Это не проблема, если вы отделены от Интернета сетевым эк- раном , и злоумышленник не смог проникнуть внутрь сети. Но если ему удалось взломать хотя бы один компьютер в защищенной сети, то хакер может установить программу прослушивания и увидеть все сообщения в журналах. Вопрос решается достаточно просто, если зашифровать трафик, направив его через туннель SSL. Самый простой вариант — выполнить следующие действия: 1. На сервере, отправляющем сообщения, в конфигурационном файле про- писываем пересылку сообщений на локальный компьютер: *.* @localhost Глава 12 388 2. Все сообщения будут передаваться на локальный компьютер на 514 порт UDP. Чтобы все работало верно, сервер не должен работать в режиме приема сообщений, то есть запущен без ключа –r . Иначе порт 514 будет занят , а нам это не нужно. 3. На порту 514 локального компьютера запускаем stunnel-клиент: stunnel –c –d 127.0.0.1: 514 –r loagserver:1050 Все сообщения, полученные на этот порт, будут шифроваться и переда- ваться на порт 1050 компьютера loagserver . В вашем случае вместо име- ни loagserver нужно указать адрес вашего сервера. 4. На компьютере loagserver создаем stunnel-сервер: stunnel –d 1050 –r 127.0.0.1:514 После этих действий на локальном компьютере клиент stunnel будет полу- чать незашифрованные сообщения на порту 514, шифровать их и отправлять на порт 1050 компьютера loagserver . А на компьютере loagserver сервер stunnel будет получать зашифрованные сообщения и в расшифрованном виде направлять их на порт 514. На сервере loagserver сервис syslogd должен быть запущен с ключом –r для приема сообщений на 514 порту. Теперь все сообщения будут передаваться по сети в зашифрованном виде. 12.5.7. logrotate Чтобы файлы журналов слишком сильно не раздувались, в Linux включена утилита logrotate. Рассмотрим принцип ее работы на примере журнала /var/log/messages: 1. Когда размер файла /var/log/messages превышает максимально допусти- мое значение или проходит определенный промежуток времени, содер- жимое текущего журнала переносится в файл /var/log/messages.1, а файл /var/log/messages очищается и заполняется заново; 2. В следующий раз, при достижении максимального размера, содержимое файла /var/log/messages.1 переносится в /var/log/messages.2, а журнал /var/log/messages переносится в /var/log/messages.1. Таким образом, история изменений сохраняется в отдельных файлах, и ее можно всегда просмотреть. При этом сам журнал никогда не превысит опре- деленного размера, и с ним будет удобно работать. За сохранение истории и перенос данных между файлами отвечает програм- ма logrotate. Рассмотрим ее конфигурационный файл (/etc/logrotate.conf), ко- торый показан в листинге 12.5. Мониторинг системы 389 Листинг 12.5. Файл /etc/logrotate.conf конфигурации программы logrotate # see "man logrotate" for details # Выполните команду man logrotate для получения дополнительной информации # rotate log files weekly # Смена файлов происходит еженедельно weekly # keep 4 weeks worth of backlogs # Будут использоваться 4 файла для сохранения истории rotate 4 # create new (empty) log files after rotating old ones # После сохранения журнала создается пустой новый файл create # uncomment this if you want your log files compressed # Уберите комментарий со следующей строки, # чтобы файлы журналов сжимались #compress # RPM packages drop log rotation information into this directory # Пакеты RPM переносят информацию о переворотах журнала в эту директорию include /etc/logrotate.d # no packages own wtmp -- we'll rotate them here # для журнала /var/log/wtmp задаются собственные правила /var/log/wtmp { monthly create 0664 root utmp rotate 1 } # system-specific logs may be also be configured here. # специфичные системные журналы могут быть сконфигурированы здесь. Посмотрим на параметры, которые нам доступны: weekly — указывает на то, что файлы журналов должны меняться ежене- дельно . Если сервер используется редко, можно изменить это значение на monthly , чтобы обновление происходило ежемесячно; Глава 12 390 rotate — задает количество файлов, которые будут использоваться для хранения истории. В данном случае стоит число 4, то есть имена журналов будут иметь вид: /etc/log/имя.X, где X изменяется от 1 до 4; create — требует создания нового пустого документа после смены файла журнала ; compress — позволяет сжимать файлы журналов. На серверах, обрабаты- вающих запросы огромного количества пользователей, журналы могут за- нимать очень много места, и чтобы сэкономить дисковое пространство, их можно сжимать. Так как журналы содержат текст, сжатая версия может иметь объем на 70% (и даже более) меньше. В начале файла идут описания значений по умолчанию. Затем можно указать специфичные значения для определенных журналов. В данном конфигураци- онном файле выделен журнала /var/log/wtmp: /var/log/wtmp { monthly create 0664 root utmp rotate 1 } В данном файле нет ограничения на размер журнала, но его можно задать с помощью параметра size . Например, в следующем примере задается мак- симальный размер журнала в 100 Кбайт: /var/log/wtmp { monthly size = 100k create 0664 root utmp rotate 1 } Теперь файл журнала будет меняться в двух случаях (по событию, которое наступит раньше): ежемесячно , так как указан параметр monthly ; когда файл достигнет размера 100 Кбайт. За счет смены журналов мы получаем как удобства, так и недостатки. На- пример , после проведения атаки хакер может уничтожить свои следы, даже если не имеет непосредственного доступа к файлам журнала. Достаточно только засыпать журнал мусорными сообщениями и превысить максималь- ный размер, чтобы система четыре раза произвела ротацию. Пытаться защищать журнал, увеличивая его размер, бесполезно, потому что хакер не будет добавлять записи в log-файл вручную, а воспользуется про- Мониторинг системы 391 стой программой на Perl или написанной прямо для командного интерпрета- тора (Shell). Такая программа чрезвычайно проста. Достаточно только в цикле выполнять команду: logger –p kern.alert "Текст сообщения" С помощью директивы logger можно записывать в журнал сообщения. Если организовать бесконечный цикл выполнения этой команды, то система сама уничтожит журнал. Чтобы данные не исчезали бесследно, можно добавить команду, которая бу- дет отправлять журнал на почтовый адрес администратора: /var/log/wtmp { monthly size = 100k create 0664 root utmp postrotate # Команда отправки журнала имя.1 endscript rotate 1 } В данном случае после первой смены журнала будет выполняться сценарий отправки этого файла на почтовый ящик администратора. Если вы настраиваете сервис таким образом, убедитесь, что ваш почтовый ящик способен принять необходимое количество данных. Например, если вы установили максимальный размер файла в 10 Мбайт, а ваш почтовый ящик способен принять только 5 Мбайт, то вы никогда не получите этот файл, по- скольку он будет удален почтовым сервером. 12.5.8. Пользовательские журналы Все команды, которые выполняются пользователем, сохраняются в файле .bash_history (если используется интерпретатор команд /bin/bash), который находится в пользовательской домашней директории. Когда вы определили, под какой учетной записью в системе находился взломщик, его действия можно проследить по этому журналу. Вы сможете узнать, какие команды или программы выполнялись, а эта информация подскажет, как злоумышленник проник в систему и что изменил. Если хакер добавил пользователя или модифицировал какой-либо важный сис- темный файл, то вы это увидите и сможете вернуть все в исходное состояние, и тем самым быстро закрыть двери в системе, которые открыл хакер. Конечно же, профессиональные взломщики, которые зарабатывают деньги, проникая в чужие системы, знают об этом, поэтому делают все возможное, Глава 12 392 чтобы скрыть свои действия, и регулярно чистят этот журнал. Посторонние изменения файла .bash_history могут указать на конкретную учетную запись, через которую произошел взлом. Пользовательские журналы нужно регулярно проверять и чистить. Некоторые пользователи (да и вы сами) могут ошибиться при написании какой-либо команды и указать свой пароль. Взломщик, проанализировав файл .bash_history, увидит пароли и сможет уничтожить ваш сервер. Если вы в командной строке набирали директиву и указывали пароль адми- нистратора root, то не поленитесь удалить соответствующую запись из поль- зовательского журнала. Такая ошибка может вам обеспечить бессонную ночь , а может и не одну. Пароли администраторов могут указываться в командной строке и при ис- пользовании программы mysql. Если вы, например, выполнили команду /usr/bin/mysql –uroot –ppassword то она полностью сохранится в журнале. Получив доступ к вашему журналу команд bash, злоумышленник приобретает возможность использовать базу данных MySQL с правами root. В лучшем случае это будет только база дан- ных , а в худшем (если пароль root на систему и на MySQL совпадают), — весь сервер будет под контролем взломщика. В Н И МА Н И Е ! Никогда не выполняйте в командной строке директивы , требующие указания пароля , а если сделали это , то удалите соответствующую запись из журнала bash. В случае с MySQL нужно было задать команду /usr/bin/mysql – uroot В ответ на это сервер запросит пароль , который не сохранится в журна - ле , а запишется только введенная команда Если вы работаете с сервером баз данных MySQL, то в вашей домашней ди- ректории помимо файла .bash_history будет еще и .mysql_history. В этом фай- ле хранятся все команды, которые выполнялись в программе конфигуриро- вания mysql. Его также надо очищать, если при выполнении команды был указан какой-либо пароль. База данных — это еще не вся ОС, но и она может послужить отправной точкой для дальнейшего взлома, к тому же сами базы данных могут содержать секретную информацию, например, пароли доступа к закрытым частям WEB-сайта. 12.5.9. Обратите внимание Давайте посмотрим, на чем нужно сосредоточить внимание при анализе жур- налов безопасности. Это не только записи о неправомерном доступе к систе- ме . Наблюдая за журналами, необходимо выявлять атаки еще на начальном Мониторинг системы 393 этапе и не допускать взлома. Когда вы увидели, что пользователь получил доступ к закрытой информации, то момент взлома вы уже пропустили. Если стали быстро увеличиваться журналы, значит, возросла активность и, возможно , началась атака отказа от обслуживания. Нужно срочно реагиро- вать , иначе рост нагрузки на сервер или каналы связи может стать неуправ- ляемым , и к определенному моменту сервер перестанет обрабатывать запро- сы пользователей. К тому же, если журналы заполнят весь диск, то вся система может выйти из строя. Убедитесь, что у вас достаточно места для хранения файлов журналов. Компьютер не должен перегружаться без вашего ведома. Если это произош- ло , то проверьте журналы и выясните, по какой причине и когда это случи- лось . Момент последней загрузки Linux легко узнать с помощью команды uptime Следите за повторяющимися записями, особенно об авторизации. Если на каком -либо сервисе происходит много попыток входа с неверной идентифи- кацией пользователя, это может говорить о том, что взломщик пытается по- добрать пароль. Если вы заметили что-то подозрительное (с учетом вышеперечисленного), то следует выяснить, откуда идет потенциальная угроза, а именно, IP-адрес и расположение сети атакующего. Для предотвращения дальнейших действий со стороны взломщика можно изменить политику сетевого экрана, добавив запись , запрещающую любые подключения со стороны атакующего хоста. При анализе журнала нужно быть очень бдительным и обращать внимание на каждую мелочь. Например, чтобы подобрать пароль, злоумышленник может использовать различные методы маскировки, в частности, он может само- стоятельно записывать в журнал подложные записи. Если хакер будет подбирать пароль простым перебором, то вы легко уви- дите большое количество неудачных попыток войти под определенным пользователем , так как при этом в журнале /var/log/messages появляется запись вроде этой: Feb 12 17:31:37 FlenovM login(pam_unix)[1238]: authentication failure; logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=root Параметр login(pam_unix) указывает на то, что хакер только пытается вой- ти в систему. Если он уже проник в систему, но неудачно использовал команду su , то в поле logname будет имя, под которым хакер находится в системе, и текст login(pam_unix) будет заменен на su(pam_unix) По такой строке вы легко сможете определить, что это злоумышленник, и быстро найти его. Но хакер может накидать в журнал своих записей, которые Глава 12 394 будут указывать на других пользователей, тогда среди всех этих записей найти реальную будет очень сложно. Например, с помощью следующей коман- ды хакер может добавить в журнал строку, которая будет идентична ошибке аутентификации : logger –p kern.alert –t 'su(pam_unix)' "authentication failure ; \ logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root " Как обычно, обратная косая черта служит здесь для разбиения длинной команды на две строки. В ответ на это в журнале будет создана примерно следующая запись: Feb 12 17:31:37 FlenovM login(pam_unix)[1238]: authentication failure; logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root Теперь представим, что хакер накидал строк, в которых поле logname всегда разное . Выделить из них реальные практически невозможно. Хорошо , если при использовании программы logger хакер не будет исполь- зовать ключ –t , а укажет команду следующим образом: logger –p kern.alert "authentication failure ; logname=robert uid=0 \ euid=0 tty=tty1 ruser= rhost= user=root " В этом случае в журнале будет строка: Feb 12 17:31:37 FlenovM logger: authentication failure; logname=robert uid=0 euid=0 tty=tty1 ruser= rhost= user=root Как видите, перед сообщением об ошибке стоит ключевое слово logger , ко- торое как раз и выдает подделку. Даже если программа logger не будет доступна хакеру, он может создать записи своей программой. 12.6. Работа с журналами Мы рассмотрели различные журналы, которые доступны в системе, взгляну- ли на их содержимое и узнали, что и где хранится. Знать все это просто необ- ходимо , но анализировать текстовый файл размером в несколько мегабайт очень сложно и неудобно. В действующей системе, обрабатывающей множество пользовательских за- просов , журналы растут очень быстро. Например, на моем WEB-сервере ежедневный журнал часто превышает 4 Мбайт, а ведь мой сайт — далеко не самый посещаемый. Это очень много текстовой информации, в которой бы- стро найти нужную строку практически невозможно. Для упрощения анализа программисты и администраторы написали и про- должают разрабатывать программы-анализаторы файлов журналов. Про- Мониторинг системы 395 сматривать журналы необходимо каждый день, а лучше даже каждый час. Для обеспечения безопасности нельзя прозевать важные сообщения, иначе проигрыш будет обеспечен. Но как при ежечасном контроле файла отделить записи , которые уже проверялись? Программа должна уметь запоминать время последней ревизии и при следующем запуске отбрасывать ранее про- смотренные записи. Наиболее эффективными программами анализа журналов являются сервисы, которые проверяют записи параллельно с попаданием их в log-файлы. Это достаточно просто реализовать, особенно на удаленном компьютере, которо- му посылается информация от работающего сервера по сети. По мере полу- чения записей они проверяются и помещаются в файлы для дальнейшего хранения и более тщательного анализа. По одной записи очень сложно вы- явить атаку, и иногда необходимо видеть динамику событий. Например, одна неправильная попытка авторизации еще ни о чем не говорит, а вот 10 и бо- лее — это уже должно вызывать подозрение. Самое обидное, что все известные программы неэффективны для анализа в динамике. Большинство из них имеют ограничения при создании правил, по которым отдельная запись относится к разряду опасных. Из-за этого при- ходится в круг подозреваемых относить все, что имеет ошибки входа в сис- тему , а потом лично анализировать все записи и время их срабатывания. Каждый день хотя бы один пользователь может ввести ошибочный пароль, особенно если пароль, как и должен быть, сложный. Реагировать на подоб- ные записи бессмысленно. Есть еще один недостаток просмотра журнала построчно. Допустим, анализа- тор выдал сообщение о попытке обращения к запрещенной области диска. Для большинства сервисов в этой записи отсутствует информация о пользователе. Например , вы заметили строку о неправомерном доступе к директории по FTP. В ней будет IP-адрес клиента, но вы можете захотеть узнать, под какой учетной записью зарегистрировался пользователь. Чтобы это увидеть, необ- ходимо открыть сам журнал и проследить историю подключений с этого IP- адреса . А ведь это можно решить, если анализировать журнал в динамике. 12.6.1. tail Когда я нахожусь непосредственно за сервером, то в отдельном окне терми- нала запускаю следующую команду: tail –f /var/log/messages После этого на экране появляется содержимое журнала, которое изменяется в реальном времени. При записи в журнал новой строки она тут же появляет- ся у меня на мониторе. Глава 12 396 Это очень удобно, особенно при небольшом количестве записей. Вы можете спокойно работать в одном терминале и иногда переключаться на другой, чтобы взглянуть на ход работы. Если сообщения появляются слишком часто (с сервером работает большое количество пользователей), то проследить за ними просто невозможно. В этом случае необходимо их фильтровать с по- мощью специализированных программ, которые отображают только подо- зрительную информацию, а остальные записи просто пропускают. 12.6.2. swatch Это очень мощная утилита, написанная на простом и знакомом многим адми- нистраторам языке Perl. Это позволяет легко изменять и добавлять возможно- сти самостоятельно. Скачать программу можно по адресу sourceforge.net/ projects/swatch. Она позволяет анализировать записи по расписанию (если за- нести выполнение программы в cron ) или сразу после их попадания в журнал. Так как это Perl-программа, то процесс ее установки отличается от многих других программ. В данном случае выполните следующие действия: tar xzvf swatch-3.1.tgz cd swatch-3.1 perl Makefile.PL make test make install make realclean Как всегда, у медали есть оборотная сторона. То, что программа написана на Perl, является и недостатком, так как требует наличия интерпретатора. Я уже говорил , что нельзя устанавливать на сервер то, что может открыть дверь злоумышленнику и при этом не является действительно необходимым. Без нужды я рекомендую не подключать интерпретаторы типа Perl, потому что хакеры очень часто используют их для написания собственных rootkit- программ 12.6.3. Logsurfer Одна из немногих программ, которая может просматривать журнал в дина- мике , — Logsurfer (sourceforge.net/projects/logsurfer). Как я уже говорил, большинство средств разбирает журнал построчно, что не очень эффективно, потому что в результате мы получаем слишком много мусора. Из -за мощных возможностей этой программы ее сложнее настраивать. Это тоже недостаток, потому что из-за ошибок в конфигурации можно не уловить очень важные события. Мониторинг системы 397 12.6.4. Logcheck/LogSentry Это самая простая в использовании программа. Она написана теми же про- граммистами , что и PortSentry, которую мы рассматривали в разд. 12.4.2. В состав LogSentry уже входят различные шаблоны, с помощью которых можно выделять потенциально опасные записи. Разобраться с программой очень просто, но меня смущает только ее будущее. В последнее время создается впечатление, что обновлений больше не будет, а рано или поздно возможностей текущей версии просто не хватит, и придет- ся искать новое средство. Но будем надеяться на лучшее. 12.7. Безопасность журналов Заканчивая тему журналирования, необходимо поговорить и о безопасности. Журналы создавались как средство наблюдения за системой и выявления атак , но могут быть использованы в корыстных целях. Рассмотрим классический пример взлома. Система регистрирует в журналах безопасности неверные попытки входа. При этом в файл попадает имя поль- зователя , который допустил ошибку. Пароль при этом не сохраняется, чтобы хакер , прочитав журнал, не смог его увидеть. Допустим, что легальный поль- зователь случайно вместо имени пользователя набрал свой пароль. Такое бы- вает , особенно по утрам, если пользователь пришел на работу, не выспав- шись , или просто с плохим настроением. Таким образом, пароль будет сохранен в журнале в открытом виде. Очень важно сделать так, чтобы журнал не был доступен для злоумышлен- ника . Выполните сейчас следующую директиву для просмотра прав доступа на файлы журналов: ls –al /var/log Результат работы команды: drwxr-xr-x 9 root root 4096 Jan 12 13:18 . drwxr-xr-x 21 root root 4096 Jan 24 23:00 .. drwx------ 2 root root 4096 Jan 12 11:14 bclsecurity -rw-r----- 1 root root 83307 Jan 12 13:18 boot.log -rw-r----- 1 root root 89697 Jan 6 09:01 boot.log.1 -rw-r----- 1 root root 48922 Jan 30 11:45 boot.log.2 -rw-r----- 1 root root 64540 Jan 23 19:55 boot.log.3 -rw-r----- 1 root root 36769 Jan 16 12:36 boot.log.4 Глава 12 398 -rw-r----- 1 root root 8453 Jan 12 13:18 cron -rw-r----- 1 root root 8507 Jan 6 09:06 cron.1 -rw-r----- 1 root root 7189 Jan 30 11:50 cron.2 -rw-r----- 1 root root 6935 Jan 23 20:01 cron.3 -rw-r----- 1 root root 4176 Jan 16 12:41 cron.4 Владельцем всех файлов должен быть администратор root. Убедитесь также, что только он имеет полные права, а всем остальным не позволено работать с файлами. По умолчанию для большинства файлов правом чтения обладает владелец и пользователи его группы, в качестве которой чаще всего можно увидеть root. Если в вашей системе в эту группу входит только администратор, то можно оставить все, как есть. Но если в нее входит несколько пользователей, что я абсолютно не приветствую, то необходимо сформировать специальную группу с минимальными правами и назначить ее для всех журналов. Следующие команды создают новую группу loggroup и устанавливают ее для всех log-файлов: groupadd logsgroup cd /var/log chgrp –R logsgroup . В директории /var/log правом чтения и записи в журналы должен обладать исключительно администратор. Пользователям группы следует разрешить только чтение, а остальным — запретить абсолютно все. Для того чтобы всем файлам установить эти права, выполните следующие команды: cd /var/log find . –type f | xargs chmod 640 Вторая строка состоит из двух директив. Команда find . –type f ищет в текущем каталоге все объекты, у которых тип равен f , то есть все файлы. Вторая ( xargs chmod 640 ) — изменяет у всех найденных объектов права дос- тупа на 640. Можно даже понизить это значение до 600, чтобы и читать, и писать мог только администратор. Помимо этого, на директорию /var/log у пользователей не должно быть прав на запись, потому что это позволит злоумышленнику удалять файлы. Если хакер не сможет изменить журнал, то попытается его уничтожить. Да, вы поймете , что в системе кто-то был, но не определите, как произошло вторже- ние , и не сможете найти взломщика. Помните , что, прочитав журнал, хакер может получить шанс повысить свои права , если там случайно окажется конфиденциальная информация. Но если Мониторинг системы 399 журналы станут доступными на запись, то взломщик сможет замести следы, удалив все записи относительно своей активности. Но и этого недостаточно для обеспечения максимальной защиты. Если по- смотреть на суть журналов, то станет очевидным, что в них ОС только до- бавляет новые записи. Таким образом, можно поставить дополнительную защиту от удаления и изменения с помощью ключей. В файловых системах Ext2 и Ext3 есть команда chattr , с помощью которой можно устанавливать дополнительные атрибуты на файлы. Один из них (ключ +a ) позволяет задать условие , при котором файл можно только пополнять. Например, следующая команда устанавливает для файла /var/log/boot.log такой атрибут: chattr +a /var/log/boot.log Попробуйте теперь изменить или удалить файл. У вас ничего не выйдет. Единственный недостаток этого ключа — у вас тоже не будет возможности чистить файл. А ведь журнал постоянно растет, и нет смысла хранить записи о событиях, которые произошли месяц, а то и год назад. Перед стиранием устаревшей информации из журнала необходимо снять атрибут: chattr -a /var/log/boot.log Только не забудьте потом вернуть его обратно, чтобы файл снова стал дос- тупным только для добавления записей. Помимо самих журналов необходимо защищать и программы, установлен- ные для их анализа. Бесполезно стоять на страже файлов, если их можно про- смотреть через утилиты. Для этого у всех программ, позволяющих читать журналы , не должно быть установленного SUID- или SGID-бита. |