Брандмауэры и специальное программное обеспечение



Pdf просмотр
страница37/42
Дата15.02.2017
Размер6.16 Mb.
Просмотров3100
Скачиваний0
ТипАнализ
1   ...   34   35   36   37   38   39   40   41   42
Листинг 22.4. Фрагмент вывода команды netstat -а, в котором показан канал syslog
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path unix 0 [ ACC ] STREAM LISTENING 12556 /dev/log unix 1 [ ] STREAM CONNECTED 12560 /dev/log
Правом записи в этот сокет и правом чтения из него обладает любой пользователь, поэтому скрывать его не имеет смысла. Основная цель злоумышленников — удаление записей из журнала. По этой причине правом записи в журналы должен обладать только пользователь root (или пользователь, от лица которого работает syslog).
ПРИМЕЧАНИЕ
Для повышения уровня безопасности демон syslogd можно запустить от имени непривилегированного пользователя,

однако в этом случае его нельзя будет использовать в качестве центрального механизма протоколирования для всей
сети. Дело в том, что UDP-порт с номером 514, используемый для приема сообщений syslog через сеть, может
быть связан только на уровне привилегий root.
Совместно с демоном syslogd можно использовать и многие другие параметры командной строки, однако здесь я расскажу вам еще только об одном ключе. Ключ -m используется для добавления в файлы журналов пометок о времени. В числе прочих механизмом syslog используется канал mark, который на самом деле не является обычным каналом. Этот канал используется только для того, чтобы добавлять в журналы пометки о времени. Эти пометки многим могут показаться раздражающими, однако на самом деле, проанализировав их или обнаружив их отсутствие, вы сможете сделать вывод о том, что с файлами журналов кто-то производил несанкционированные операции. По умолчанию пометки о времени добавляются в файлы журналов через каждые 20 минут, однако длительность этого промежутка можно изменить при помощи ключа -m, к которому в качестве аргумента необходимо добавить желаемую длительность временного интервала. Если установить временной интервал равным нулю, пометки о времени не будут добавляться в файлы журналов.
Что искать в файлах журналов?
После того как система протоколирования настроена, возможно, у вас возникнет вопрос, а что именно следует искать внутри файлов журналов? Другой, более грамотный вопрос: какую именно информацию следует получать от системы протоколирования для обеспечения приемлемого уровня защиты и как следует настроить систему протоколирования, чтобы получить от нее эту информацию? В большинстве случаев с точки зрения безопасности вас будут интересовать действия локальных пользователей, а также удаленные подключения к вашей системе.
Конечно же, система протоколирования является емким источником информации о функционировании самых разнообразных работающих в системе служб. Зачастую при помощи журналов syslog можно выполнить отладку конфигурации, а также получить сведения о неправильно работающих процессах. Зачастую сообщения, протоколируемые syslog, весьма детально описывают возникшую в системе проблему. Однако все это в первую очередь относится не к безопасности, а к системному администрированию, поэтому я не буду затрагивать всех этих вопросов в данной книге.
С точки зрения безопасности вам прежде всего необходимо знать, используют ли локальные пользователи команду su или приглашение на подключение к сиcтеме для того, чтобы получить доступ на уровне привилегий root. По содержимому журналов вы можете определить, когда некто подключается к системе в качестве обычного пользователя, а затем при помощи команды su переходит на уровень привилегий root. Чаще всего для получения доступа к системе на уровне привилегий root используются социальные контакты и умение общаться с людьми, то есть так называемая «социальная инженерия».
Именно этот метод использовался печально известным взломщиком Кевином Митником (Kevin Mitnick) для получения несанкционированного доступа к системам. Чтобы улучшить защиту, ограничьте подключение на уровне root к локальным терминалам, полностью запретите подключение через telnet. В
OpenLinux такой порядок вещей установлен в конфигурации по умолчанию.
Что касается внешних подключений, вы должны реагировать на попытки сканирования вашей системы в поисках открытых портов. Чтобы попытаться взломать вашу систему, злоумышленник должен вначале узнать, какими службами он может воспользоваться для этой цели. Таким образом, он будет пытаться подключиться к вашей системе через различные порты. Эти попытки вы сможете обнаружить, просмотрев содержимое журналов. Вы увидите, что некто последовательно подключается к разнообразным портам вашей системы. Чуть позже, возможно, поступает запрос о статусе сервера, при этом клиент не пытается использовать данный сервер. Это может указывать на то, что взломщик пытается определить разновидность и версию серверной программы, чтобы точнее подобрать инструменты, которые потребуются ему для взлома. Получив эти сведения и выполнив быстрый поиск уязвимых мест, злоумышленник может приступить к взлому. Сама попытка может выглядеть в журналах syslog как соединение с клиентом, через которое получены некорректные данные. Возможно, это попытка организовать переполнение буфера. Некорректные данные — это бессмысленный набор символов, среди которых можно обнаружить как бы случайно оказавшийся там полный путь к некоторому исполняемому файлу.
ССЫЛКА
Сканирование сетей обсуждается в главе 25 «Использование средств наблюдения за сетью».
В лучшем случае может произойти одно из двух:
а) возникает сбой серверной программы, выводится содержимое некоторого
участка оперативной памяти и программа завершает работу;
б) программа принимает неправильные данные, отказывается от их обработ ки, заносит их в журнал и продолжает нормальное функционирование.
В любом из этих случаев можете считать, что вам повезло, — замысел злоумышленника провалился.
Однако может произойти и другое: в момент своего аварийного завершения программа запускает командную оболочку на уровне привилегий root, к которой получает удаленный доступ злоумышленник.
Слишком легко? Именно по причине такой легкости значительная часть Интернета в последнее время превратилась в настоящий детский сад, заполненный малолетними хулиганами.
ССЫЛКА
В главе 23 о просмотре и анализе файлов журналов рассказывается подробнее.
Заключение
В этой главе я рассказал вам о том, как настраивается механизм протоколирования данных о работе системы. Вы познакомились с форматом записей файла /etc/syslog.conf. Вы также узнали о том, какими бывают каналы и уровни приоритета и откуда они берутся. Вы узнали о том, как составлять спецификации протоколируемых сообщений, и о том, как указывать разнообразные цели для записи этих сообщений.
Затем я рассказал вам о параметрах командной строки демона syslogd. Вы также узнали о том, как настроить центральный сервер протоколирования и предотвратить атаку Denial of Service, направленную на этот сервер.

Просмотр и анализ журналов
syslog
23
В данной главе рассматриваются следующие вопросы:
- типы файлов журналов и их местоположение;
- разрешения на доступ к файлам журналов;
- как работает механизм протоколирования;
- использование dmesg;
- просмотр журналов в формате, отличающемся от ASCII.
В предыдущей главе я рассказал вам о том, как управлять механизмом syslog и как настроить его таким образом, чтобы он вносил в файлы журналов именно ту информацию, которая вам нужна. В данной главе я подробнее расскажу вам об этих файлах журналов.
Большая часть файлов журналов являются простыми текстовыми файлами ASCII. Для просмотра таких файлов вы можете воспользоваться любым текстовым редактором. Также вы можете просто вывести их содержимое на экран или в окно /terminal при помощи утилиты cat. Однако как только вы приступите к анализу содержимого любого из этих файлов, вы обнаружите множество однообразных сообщений, большую часть которых вам захочется игнорировать. Они вносятся в журнал на всякий случай, однако если попытаться просмотреть их все в поисках чего-либо ненормального, у вас могут возникнуть сложности.
Требуется некий способ анализа базовой информации о вашей системе для того, чтобы оперативно определять, что является нормальным, а что вызывает подозрения. При работе с файлами журналов вы имеете дело с сотнями или с тысячами (а возможно, и более того) записей ежедневно. Очевидно, что для упрощения этой работы удобнее использовать некий сценарий, позволяющий отбирать нужные вам записи и скрывать от ваших глаз ненужные записи (после того как вы поймете, что они вас не интересуют).

ВНИМАНИЕ
Если вы обнаруживаете что-либо странное, например запись, содержащую следующий текст:
H^N^L^K^^N^H^V^L^^?^?^?/bin/sh^^?^?^?^?^?^?^?^?^?^?^?имейте в виду, что в отношении вашей системы была
предпринята попытка взлома (возможно, успешная, а возможно — нет). Немедленно примите меры, так как
комбинация символов /bin/sh в середине бессмысленного набора символов — это не простая случайность.
Файлы, расположенные в каталоге /var/log
Как отмечалось в предыдущей главе, каталог /var/log является местоположением по умолчанию для системных файлов журналов. В большинстве случаев, если некоторый файл отсутствует, механизм syslog автоматически создает его. Однако существует пара файлов, которые не создаются демоном syslog автоматически -их следует создать вручную (об этом будет рассказано позже).
Если syslog автоматически создал некоторый отсутствующий ранее файл журнала, это еще не означает, что данный файл был создан правильно. Вы должны внимательно изучить содержимое каталога
/var/log. Необходимо проанализировать, какая информация записывается в каждый из файлов и кто должен обладать правом просмотра этой информации.
Если в отношении файлов журналов назначены неправильные наборы разрешений, достаточно выполнить простую операцию chmod. Некоторые из файлов могут использоваться опытными пользователями или пользователями, осуществляющими компиляцию и запуск своих собственных программ, которые могут выводить отладочную информацию или какие-либо результаты работы в syslog.
Для таких пользователей, возможно, будет необходимо разрешить просматривать некоторые из файлов журналов. Для каждой отдельной сети и для каждого отдельного узла решение о просмотре тех или иных файлов журналов следует принимать по отдельности. Если вы используете центральный протоколирующий сервер, будет лучше, если вы ограничите к нему доступ и запретите подключение к нему обычных пользователей.
Некоторые из файлов журналов не должны быть доступны для широкой публики. Любой из файлов, в который попадают сообщения из канала authpriv.*, может содержать в себе пароли. В листинге 23.1
показан пример записи файла secure, в которой содержится пароль.
Листинг 23.1. Фрагмент файла /var/log/secure
Oct 3 16:22:54 volcan login[1549]: FAILED LOGIN 1 FROM (null) FOR nypassword. User not known to the underlying authentication module
Показанная в листинге запись сообщает, что некто с именем mypassword пытался подключиться к системе, но получил отказ, так как пользователя с таким именем в системе не существует. Что же произошло? На самом деле пользователь по ошибке ввел вместо имени свой пароль, естественно, система не узнала его. Подобное часто случается с людьми, которые привыкли работать с Windows. Операционная система Windows запоминает имя последнего подключавшегося к ней пользователя и по умолчанию предлагает имя этого пользователя в приглашении на подключение к системе. Таким образом, пользователь привыкает к тому, что в большинстве случаев для того, чтобы войти в систему, ему надо ввести только пароль. Все это — остаточный менталитет идеологии «одна система, один пользователь», на базе которой была построена большая часть систем Windows. Пользователи привыкают сообщать системе только пароль, подразумевая, что система уже знает, кто они есть. В нашем случае пользователь вводит свой пароль вместо имени и получает отказ — первая попытка подключения проваливается. Однако запись, которая следует сразу же за записью, указанной в листинге 23.1 сообщает нам, что пользователь root успешно подключился к системе. Таким образом, в первой из рассматриваемых записей содержится пароль, а в следующей — имя пользователя, обладающего данным паролем. Не надо быть гением, чтобы сообразить, какой пользовательской учетной записи соответствует этот пароль. Любой человек, обладающий возможностью просмотра данного файла журнала, получит в свое распоряжение открытые ворота, пропускающие его в систему.
СОВЕТ
Если вы используете программные средства, осуществляющие автоматическую смену файлов журналов, убедитесь
в том, что используемый вами программный механизм создает файл-замену с корректным набором разрешений на
доступ.
Содержимое каталога /var/log, который должен быть зарезервирован исключительно для системы протоколирования, должно выглядеть приблизительно так, как показано в листинге 23.2.
Листинг 23.2. Содержимое каталога /var/log drwxr-xr-x 2 root root 1024 Oct 27 00:00 atsar drwxr-x--- 2 root root 1024 Oct 25 12:42 httpd
-rw-r--r-- 1 root root 1702 Aug 5 09:06 kdm
-rw-r--r-- 1 root root 146876 Oct 27 06:50 lastlog
-rw ------- 1 root root 180264 Oct 27 09:34 mail
-rw ------- 1 root root 323304 Oct 25 11:58 mail.0.gz drwxr-xr-x 2 majordom majordom 1024 Jul 27 19:55 majordomo
-rw ------- 1 root root 1425209 Oct 27 09:39 messages
-rw ------- 1 root root 1667546 Oct 25 12:05 messages.0.gz drwxr-xr-x 3 news news 1024 Aug 5 08:52 news.d drwxr-xr-x 2 root root 1024 Jul 28 00:00 samba.d
-rw ------- 1 root root 331161 Oct 27 09:38 secure
-rw ------- 1 root root 0 Aug 5 09:04 spooler drwxr-x--- 2 root root 1024 Jul 14 20:08 squid drwxr-xr-x 2 uucp uucp 1024 Jul 27 20:53 uucp
-rw-rw-r-- 1 root utmp 1276032 Oct 27 09:37 wtmp
-rw-r--r-- 1 root root 4193 Oct 25 11:16 xdm-errors
-rw ------- 1 root root 52626 Oct 27 08:57 xferlog
Обратите внимание, что часть файлов открыты для всеобщего обозрения. Любой пользователь обладает возможность прочитать их содержимое. На данной системе эти файлы используются некоторыми пользователями и не содержат никаких данных, критичных для безопасности системы. Отдельные файлы, в особенности те, которые расположены в подкаталогах, создаются программами, не являющимися syslog. В некоторых случаях они принадлежат другим пользователям. Как правило, если программа должна создать файл журнала, этот файл должен принадлежать пользователю, от имени которого работает данная программа. Если бы файлы и подкаталоги принадлежали пользователю root, некоторые программы, такие как uucp, majordomo и т. п., не смогли бы осуществить запись в файл или подкаталог, если только этот файл или подкаталог не является доступным для записи для всего окружающего мира. А это не самая лучшая идея.

Как работает система протоколирования
Работая с syslogd, вы должны понимать, что происходит, когда syslogd начинает работу. Демон syslogd начинает работу на самых ранних стадиях загрузки системы. Это происходит потому, что механизм syslog должен как можно раньше приступить к протоколированию происходящих в системе событий.
Прежде всего syslog читает содержимое файла /etc/syslog.conf (информация, содержащаяся в этом файле, описывается в предыдущей главе). После этого syslog создает сокет (по умолчанию /dev/log), через который будет осуществляться запись, после чего сокет соединяется со всеми файлами журналов, упоминаемыми в файле /etc/syslog.conf (или в другом конфигурационном файле, указанном в командной строке).
Когда syslogd готов приступить к записи сообщений, он читает содержимое кольцевого буфера ядра.
Благодаря этому в журнал попадают все те сообщения, которые отображаются на экране в процессе загрузки системы и рассказывают о том, что было обнаружено системой. Демон syslogd не может начать работу до того, как загрузка ядра будет полностью завершена, поэтому до начала работы syslogd ядро сохраняет сообщения в буфере. Сообщения заносятся в буфер до тех пор, пока буфер не заполнится, после этого для того, чтобы занести в буфер новое сообщение, ядро стирает наиболее старое хранящееся в буфере сообщение.
Чтобы снизить вероятность взлома или какого-либо нарушения работы системы, вы можете запустить syslogd от лица непривилегированного пользователя. Однако прежде чем сделать это, вы должны учесть, что если syslogd работает на более низком, чем root, уровне привилегий, этот демон не сможет связать стандартный порт syslog с номером 514. Однако это вовсе не значит, что в этом случае вы не сможете использовать syslogd в качестве центрального протоколирующего сервера. Чтобы обеспечить прием протоколируемых сообщений через сеть, вы должны связать с syslogd порт с номером выше 1024, а затем перенаправить все UDP-паке-ты, поступающие через порт 514, в тот новый порт с непривилегированным номером. Для этого необходимо изменить определение службы syslog в файле /etc/ services и использовать редиректор (например, ipchains или что-либо подобное) для перенаправления UDP- порта 514 в новый непривилегированный порт syslog. Если вы приказали демону syslogd открыть новый нестандартный порт (с использованием ключа -r) и он не может этого сделать, syslogd завершит работу, выдав сообщение об ошибке.
Изменив уровень привилегий, на котором работает syslogd, вы также должны убедиться в том, что все файлы каталога /var/log, запись в которые разрешена только пользователю root, доступны для записи пользователю, от имени которого работает демон syslogd. По умолчанию запись в подкаталоги и файлы
/var/log разрешена только пользователю root. Вы должны изменить права на владение файлами журналов, в противном случае syslogd не сможет осуществить запись в эти файлы. После того как syslogd начал работу, файлы журналов постоянно находятся в активном состоянии. Иными словами, они постоянно открыты. В этом можно убедиться, воспользовавшись командой lsof, которая отображает список открытых файлов. В листинге 23.3 показаны выдержки из вывода команды lsof. Здесь вы видите записи, имеющие отношение к протоколированию, то есть содержащие в себе буквосочетание Log.
Листинг 23.3. Фрагмент вывода команды Isof, показывающий только записи, имеющие отношение к syslog и klog
COMMAND
PID
USER
FD TYPE DEVICE SIZE NODE NAME syslogd 1040 root cwd
DIR
3,1 1024 2 / syslogd 1040 root rtd
DIR
3,1 1024 2 / syslogd 1040 root txt
REG
3,1 27772 184444 /usr/sbin/syslogd syslogd 1040 root Ou unixOxc7fecccO 118 22643 /dev/log syslogd 1040 root 1u unixOxc21d7000 118 22645 /home/dns/dev/log syslogd 1040 root 2u unixOxc5166360 118 65006 /dev/log syslogd 1040 root 4w
CHR
4,0 123 388 /dev/tty0 syslogd 1040 root 5w
REG 3,11 524040 75780 /var/log/messages syslogd 1040 root 6u unixOxc2577960 52739 52 /dev/log syslogd 1040 root 7u unixOxc68bbOOO
118 19313 /dev/log syslogd 1040 root 8u inet 612 UDP
* :syslog syslogd 1040 root 9u unixOxc21d7960 61 5 /dev/log syslogd 1040 root 10u unixOxc214d680 65 1 /dev/log syslogd 1040 root 11u unixOxc214dccO 66 3 /dev/log syslogd 1040 root 12u unixOxc2c7a680 56748 55 /home/dns/dev/log syslogd 1040 root 13u unixOxc2577640 19 81 /dev/log syslogd 1040 root 14w
REG
3,1 333293 75968 /var/log/secure syslogd 1040 root 15w
REG
3,1 191389 75781 /var/log/mail syslogd 1040 root 16w
REG
3,1 0
75970 /var/log/news.all syslogd 1040 root 17w
REG
3,1 0
75971 /var/log/spooler klogd 1043 root cwd
DIR 3,1 1024 2 / klogd 1043 root rtd
DIR 3,1 1024 2 / klogd 1043 root txt
REG 3,1 19932 184443 /usr/sbin/klogd klogd 1043 root
0r
REG 0,2 0
5 /proc/kmsg
klogd 1043 root
1u unixOxc21d76 40 614 socket
Проанализировав самую правую колонку, можно обратить внимание, что несколько процессов подключены через сокет /dev/log. Используется также сокет /home/dns/dev/log, который мы с вами создали в главе 14, об этом сокете я не буду рассказывать подробно. Запись *:syslog показывает, что syslogd связывает порт syslog для приема сообщений от других серверов. Этот порт можно легко заметить в разделе UDP вывода команды netstat -an.
В листинге 23.3 можно легко заметить записи, относящиеся к каждому из файлов журналов. В частности, показаны файлы messages, mail, news.all, secure и spooler.
Демон syslogd находится в постоянном контакте с этими файлами, поэтому их нельзя просто так переместить, переименовать или стереть. Если активный файл журнала перемещается или переименуется, перемещенный или переименованный файл продолжает принимать сообщения. Иными словами, если вы переименовываете файл messages в файл messages.0, а затем выполняете команду touch messages, файл messages.O будет продолжать увеличиваться в размерах. Иначе говоря, в момент запуска syslogd между этим демоном и файлом messages создается канал передачи данных, в момент переименования файла канал между демоном и этим файлом сохраняется. Файл можно редактировать, однако канал передачи данных все равно соединен с этим файлом до тех пор, пока syslogd не будет перезапущен.
Чтение файлов журналов
Просмотр содержимого большинства файлов журналов (по крайней мере тех, которые записываются демоном syslogd) не представляет труда. Типичная запись в файле журнала syslog выглядит следующим образом:
Oct 3 10:56:18 volcan sshd[5915]: log: Generating 768 bit RSA key.
Формат всегда один и тот же. В первой колонке указывается дата и время внесения в журнал записи.
Время является локальным временем сервера. Во второй колонке указывается имя сервера, который сделал эту запись. Часто в этой колонке указываются полные доменные имена внешних по отношению к протоколирующему серверу сетевых узлов, однако формат указываемых здесь имен можно изменить при помощи ключа командной строки (см. предыдущую главу). В рассматриваемом случае во второй колонке указано имя локальной системы — volcan. Следующая колонка содержит имя и идентификатор PID демона, создавшего эту запись. Идентификатор процесса PID (Process ID) указывается не всегда. В нашем случае создателем записи является демон sshd с идентификатором PID, равным 5915. Далее идет собственно сама запись, то есть текст сообщения, переданного демоном. В нашем случае запись показывает, что демон защищенной командной оболочки sshd (Secure Shell Daemon) с идентификатором PID 5915 сгенерировал ключ шифрования длиной 768 бит для обеспечения соединения через сеть.
Таким образом, пользователь root может свободно читать любой журнал, созданный демоном syslogd. Для этого не требуется никаких специальных программ. Однако некоторые программы, предназначенные для чтения сообщений, все же существуют. Первая такая программа называется dmesg.
На самом деле программа dmesg не читает содержимое файла журнала. Вместо этого данная утилита читает кольцевой буфер ядра. Кольцевой буфер — это обычный буфер, который спроектирован таким образом, что сразу же после его заполнения новые данные начинают записываться в его начало и далее, затирая при этом информацию, которая располагалась в начале буфера до этого. Таким образом, добавление новых данных в буфер происходит по кольцу, переходя из конца в начало буфера.
Утилита dmesg возвращает последние 8192 байт из кольцевого буфера ядра (в документации указывается число 8196, однако на самом деле это не так). Это соответствует размеру кольцевого буфера в старых ядрах версий 2.0.x. Начиная с версии 2.2.13 размер кольцевого буфера увеличился и стал равным
16384 байтам. Чтобы увидеть все содержимое буфера целиком, можно воспользоваться ключом -s за которым указывается количество отображаемых байт кольцевого буфера. Например, вы можете воспользоваться командой:
dmesg -s16284
По этой команде на экран будет выведено полное содержимое кольцевого буфера. Если вы полагаете, что вам требуется более емкий буфер, вы можете модифицировать значение параметра LOG_BUF_LEN в файле /usr/src/linux/kernel/printk.c. Увеличивая размер буфера, вы должны сделать его кратным значению
8192.
СОВЕТ
Утилита dmesg читает содержимое кольцевого буфера ядра, а не содержимое файла /var/log/ messages, поэтому
даже если система загружается с использованием строки init=/bin/sh, вы все равно сможете ознакомиться с
диагностическими сообщениями, хранящимися в кольцевом буфере.

Совместно с утилитой dmesg можно использовать еще один из двух ключей (нельзя использовать эти два ключа одновременно). Любой из них можно использовать совместно с ключом -s. Во-первых, вы можете использовать ключ -с, который очищает кольцевой буфер. Во-вторых, вы можете использовать ключ -n<#>, при помощи которого вы можете сообщить утилите dmesg наименьший допустимый приоритет сообщений, выводимых на консоль. Например, если вы хотите отобразить только сообщения уровня приоритета emergency, вы можете указать -n 1. По мере увеличения этого числа разрешенный уровень приоритета понижается, и соответственно, все большее количество сообщений будет выводиться на экран. Пример вывода утилиты dmesg показан в листинге 23.4.


Поделитесь с Вашими друзьями:
1   ...   34   35   36   37   38   39   40   41   42


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал