В номере редактор английской версии


Извлекаем полезную информацию из лог-сообщений



Pdf просмотр
страница5/7
Дата19.11.2016
Размер4.58 Mb.
Просмотров1881
Скачиваний0
1   2   3   4   5   6   7
Извлекаем полезную информацию из лог-сообщений
www.bsdmag.org
35
filter f_level {“$LEVEL_NUM” > “5”};
А в этом фильтре производится сравнение по имени хоста, например, по начальной строчке myhost, так, чтобы попадались myhost-1, myhost-2 и т.д.
filter f_wildcard {host(“myhost*” type(glob));};
Однако полностью возможности мета-данных и свойств могут быть раскрыты при задействовании парсеров. Чтобы они сегментировали тело сообщения в нужные свойства и характеристики. В качестве примера, приведем следующий сценарий. Вам нужно выделить имя пользователя и название хоста из сообщений входа и выхода пользователей из системы, названия тех команд, что выполнялись через sudo и т.п. Выделив такие сведения, вы можете разместить их в базе данных, чтобы потом, с помощью нужных запросов, проводить наглядный аудит — кто, где и когда. Поэтому в случае, если один из серверов будет недоступен, вы сможете запустить отчет и увидеть, кто пользовался данным сервером.
Пример:
Начиная с версии syslog-ng 3.3 (в редакции Open
Source) можно хранить сообщения и их свойства в базе MongoDB. Из которой уже сгенерировать нужный вам отчет с помощью JasperReports.
Парсим лог-сообщения
Структурированные сообщения, использующие запятую в качестве разделителя, могут легко быть сегментированы в отдельные поля с помощью встроенной функции csv-parser(). Такие поля могут быть преобразованы в свойства, и затем использованы в шаблонах или фильтрах, если назначите им соответствующие имена. Таким образом могут быть обработаны лог-сообщения от веб-сервера Apache и перенаправлены в разные файлы, в зависимости от имени пользователя, запросившего тот или иной веб-ресурс. Заметьте, вы можете задействовать парсеры над любым полем собщения, а не только над текстовым. Вы также можете отдельно выделить имена хостов в структурированную базу, как мы уже показали с myhost-1 и myhost-2.
Пример: парсим сообщения от Apache
Следующий парсер обрабатывает лог-файл от веб- сервера Apache и разделяет на несколько полей.
Обычно такие логи веб-сервера представляют строку параметров, разделенных пробелами.
192.168.1.1 - - [31/Dec/2007:00:17:10 +0100] “GET /cgi-bin/example.
cgi HTTP/1.1” 200 2708
“-” “curl/7.15.5 (i4 86-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5”
2 example.balabit
Парсер, что обрабатывает их, в syslog-ng будет выглядеть так: см. Листинг 1.
Другим мощным средством будет обработка с помощью базы трафаретов. Т.к. такая техника немного сложнее, то рассмотрим её подробно в следующей секции.
Текущая версия, которая в настоящее время находится в разработке (syslog-ng 3.4), обзавелась инструментом обработки полей сообщений и в формате JSON.
База трафаретов syslog-ng
Приложение syslog-ng может сравнивать содержимое входящих сообщений с предопределенным трафаретом. Таким образом, syslog-ng способен
Листинг 1. Парсим сообщения от Apache с помощью csv-parser
parser p_apache { csv-parser(columns(“APACHE.CLIENT_IP”, “APACHE.IDENT_NAME”, “APACHE.USER_NAME”,
“APACHE.TIMESTAMP”, “APACHE.REQUEST_URL”, “APACHE.REQUEST_STATUS”,
“APACHE.CONTENT_LENGTH”, “APACHE.REFERER”, “APACHE.USER_AGENT”,
“APACHE.PROCESS_TIME”, “APACHE.SERVER_NAME”) flags(escape-double-char,strip-whitespace) delimiters(“ “) quote-pairs(‘””[]’)
);
};

12/2011 36
HOW-TO
идентифицировать конкретное сообщение, классифицировать и назначить ему необходимые мета-поля (например, тип события «безопасность»,
«аппаратная ошибка»), а также «вытащить» нужные данные из распознанного сообщения.
База трафаретов в syslog-ng использует в работе базисные деревья (Radix trees), т.к. этот метод достаточно быстрый и хорошо масштабируется.
Скорость обработки практически не зависит от общего количества трафаретов в базе, а зависит только от длины сообщения и количества «похожих» трафаретов.
По сравнению с традиционными решениями по обработке сообщений, которые основаны на регулярных выражениях, трафареты в syslog-ng просты в написании, понимании и последующей эксплуатации.
Сравним:
Сообщение приходящее от OpenSSH-сервера:
Accepted password for joe from 10.50.0.247 port 42156 ssh2
Регулярное выражение, что обрабатывает это сообщение и его варианты:
Accepted \ (gssapi(-with-mic|-keyex)?|rsa|dsa|password|publickey|
keyboard-interactive/pam) \ for [^[:space:]]+ from [^[:space:]]+ port
[0-9]+( (ssh|ssh2))?
Его эквивалент в базе трафаретов syslog-ng:
Accepted @QSTRING:auth_method: @ for @QSTRING:username: @ from \ @IPv4:client_addr: @ port @NUMBER:port:@ @QSTRING:pro- tocol_version: @
Как видите, трафарет в syslog-ng использует типизацию данных для определения значения, что ожидается в логе, например, строка в кавычках
(QSTRING), число, IP-адрес. Совпадающие значения могут быть получены из лога и использованы в качестве свойств. В приведенном выше примере, такие свойства включают метод авторизации, имя пользователя, IP-адрес клиента. Эти же свойства могут быть использованы и фильтрах, и в шаблонах.
Если вы храните сообщения и их свойства в базе данных, то становится очень просто составить запрос, какие пользователи заходили на ваш сервер и с каких адресов.
База трафаретов в syslog-ng — это XML файл, в котором хранятся сами трафареты и различная мета- информация о них. Трафареты являются просто примерами сообщений, по которым происходит идентификация входящих логов. Мета-данные могут включать описание, произвольные поля, класс сообщения (который просто является специальным типом тега), и любая другая информация со свойствами, которая добавляется к сообщениям, попавшим под трафарет.
Пример:
База трафаретов, содержащая
Листинг 2. База трафаретов для единичного сообщения
ssh


Accepted @QSTRING:SSH.AUTH_METHOD: @ for@QSTRING:SSH_USERNAME: @from\ @QSTRING:SSH_CLIENT_ADDRESS: @port @NUMBER:SSH_PORT_NUMBER:@ ssh2




Извлекаем полезную информацию из лог-сообщений
www.bsdmag.org
37
единственный трафарет (Листинг 2)
Следующая база содержит правило для SSH соединений вида:
Accepted password for sampleuser from 10.50.0.247 port 42156 ssh2
Такая мета-информация может быть использована, к примеру, для разметки важных сообщений, а затем их фильтрации по тегу. Вы также можете сгенерировать специальные служебные сообщения, которые будут высылаться системой при поступлении нужного входящего сообщения.
Срабатываем по приходящему событию, а
также внешние действия
С помощью трафаретной базы syslog-ng можно автоматически генерировать новые сообщения о том, что обнаружено подходящее входящее лог- сообщение. Сгенерированные сообщения могут быть сконфигурированы внутри правил базы трафаретов и, в идеале, на каждое входящее сообщение можно назначить свой собственный класс служебного сообщения. Такое, конечно же, бывает очень редким событием, но в некоторых случаях это обязательное условие.
Пример: генерируем новое сообщение (Листинг 3)
Данный пример, будучи вставлен в базу трафаретов, генерирует сообщение, когда любое входящее сообщение подпадает под соответствующее правило.
Рассылка уведомлений непосредственно из syslog-ng на данный момент не реализована, однако достаточно просто организовать передачу сгенерированного сообщения внешнему скрипту, который уже сам перешлет нужному адресату по электронной почте или протоколу SNMP. В следующей версии (3.4) такая функция доставки через электронную почту посредством самого движка syslog-ng будет реализована.
Сообщения могут быть отправлены и в случае обнаружения коррелирующих сообщений. Более подробно в следующей секции.
Корреляция системных сообщений
Обнаружение коррелирующих сообщений — один из основополагающих принципов в анализе сообщений, т.к. сообщения обладают свойством беспорядочности, и очень часто важная информация о событиях поступает в разных логах. Например, почтовая служба Postfix любит заносить адреса отправителя и адресата в разные сообщения. А сервер OpenSSH, в случае неудачной попытки захода на машину, высылает в первом письме сам факт неудачной входа и с разъяснением этой ошибки в следующем. Но в большинстве случаев важны вместе как события, так и разъяснения к ним. Имея возможность собирать информацию о событиях как о событиях, а не в виде сообщений, позволят намного облегчить жизнь системному администратору.
Корреляция сообщений в syslog-ng основана на успешной идентификации лог-сообщений трафаретной базой syslog-ng. Вы можете расширить правила, описывающие трафареты, новыми, которые будут учитывать корреляцию совпадающих сообщений.
Такая процедура корреляции означает сборку сообщений в группы, названные контекстом. Который состоит из серии сообщений, связанных между собой по какому-либо признаку. Например, контекстом могут быть сообщения от одной SSH-сессии. Сообщения могут добавляться к контексту по мере их обработки.
Контекст можно задать используя простые статические строки, либо с помощью макросов и динамических значений. Например, вы можете сгруппировать сообщения присланные одним и тем же хостом
($HOST), приложением ($HOST$APPALICATION), или процессом ($HOST$PROGRAM$PID).
Сообщения, принадлежащие одному и тому же контексту, коррелируют и могут потом быть обработаны рядом способов. Можно включить
Листинг 3. Определяем действие в базе
трафаретов




Лог-сообщение от $HOST попало под правило $.classifier.rule_id





12/2011 38
HOW-TO
информацию, содержащуюся в предыдущем сообщении контекста, в сообщения, следующие за ним. К примеру, если почтовая служба отсылает серию разных лог-сообщений для каждого получателя письма (как делает Posftix), то можно «прилепить» все адреса реципиентов к одному первоначальному.
Другим вариантом является генерация абсолютно нового сообщения, в котором будет храниться вся важная информация, что пришла в одном контексте. Примером для такой ситуации может быть информация о времени захода и выхода с сервера
(либо время тайм-аута) авторизованных сессий для протоколов SSH/telnet.
Чтобы убедиться, что в рамках контекста обрабатываются только связанные события, можно назначить особое значение — время на обработку контекста, т.е. как долго контекстная обработка должна длиться. Если достигнут тайм-аут, то контекст закрывается. Он также может быть закрыт явно, если поступило последнее сообщение в рамках контекста.
Если обрабатывается информация о соединениях, то сообщение с уведомлением о закрытии соединения и вызовет закрытие контекста.
Когда механизм корреляции сообщений используется вместе со срабатывающим механизмом, то вы можете обращаться к полям и значениям предыдущих сообщений контекста. Следующие трафареты генерируют коррелированное сообщение, где включена информация от обоих лог-сообщений в контексте - конструкция может быть использована для поиска совпадающих сообщений от OpenSSH, а далее следует действие.
Для обработки уже собранных сообщений, sys- log-ng также умеет работать и с лог-файлами. В этом случае, для расчета времени между сессиями, будет использоваться время, записанное внутри сообщений, а не системное время.
Где найти syslog-ng
Открытая редакция (Open Source Edition) syslog-ng доступна в портах и коллекции пакетов FreeBSD. Порт раньше присутствовал в секции sysutils/syslog-ng3, но в связи с удалением версии 1.X, он был переименован в syslog-ng. Для минимизации внешних зависимостей, в пакете присутствует только ограниченное количество функций. Для задействования всех тех возможностей, что перечислены в сегодняшней статье, установите версию syslog-ng 3.3 из обновленной ветки портов.
Исходный текст также может быть найден на странице проекта — http://www.balabit.com/network-security/sys- log-ng/. Если возникли какие-либо проблемы, или же у вас есть ценные комментарии, присоединяйтесь к списку рассылки: https://lists.balabit.hu/mailman/listinfo/
syslog-ng/.
Об авторе
Robert
Fekete является инженером по документированию в компании BalaBit (Венгрия), которая занимается разработкой syslog-ng и других продуктов сетевой безопасности. Он также является приверженцем открытых продуктов и любит писать о свободном ПО по мере возможности.
Листинг 4. Консолидируем информацию в одном сообщении
Accepted @QSTRING:SSH.AUTH_METHOD: @ for@QSTRING:SSH_USERNAME: @from @QSTRING:SSH_CLIENT_AD-
DRESS: @port@NUMBER:SSH_PORT_NUMBER:@ ssh2
pam_unix(sshd:session): session closed for user @ESTRING:SSH_USERNAME: @
SSH-сессия для пользователя $SSH_USERNAME с ${SSH_CLIENT_ADDRESS}@1 закрыта. Она длилась с ${DATE}@1 по $DATE.

<>
www.bsdmag.org
39

12/2011 40
БЕЗОПАСНОСТЬ
Анатомия
Считается, что семейство BSD более устойчиво к атакам, нежели остальные системы, однако ни один сервер или IT-продукт не застрахован от взлома. В этой статье мы рассмотрим лучшие методики от вторжения, и что делать, когда случилось самое неприятное.
компрометации FreeBSD (часть 1-я)
Вы узнаете…
• Как запланировать стратегию безопасности
О чем вы должны знать…
• О навыках администрирования BSD систем
У меня долгоиграющая любовь с интернетом.
Будучи немного IT-динозавром, который сохранился со времен 1200-бодовых модемов, выделенных линий и операционной системы CP/M, я могу припомнить, что с безопасностью в начале
1980-х была намного проще. В те времена, если ваша компания была достаточно финансово успешна, то у нее была своя корпоративная сеть. Она была очень затратным делом, строго эксплуатировалась, поэтому никаких возможностей для неправильного поведения не было. Может быть только оставался маневр для так называемых хакеров в «белых шляпах», которые не стремились скомпрометировать систему ради финансовой выгоды, коммерческих секретов или ради глупых шуток. В то время, цель была другой — максимально исследовать новый (в то время) мир, поэтому-то и никаких зловредных наружений не было. А если и появлялись, то их можно было быстро вычислить, т.к. обычно производились отдельными умельцами. Теперь же перемотайте в 2011 год и мы обнаружим: многочисленные бот-неты, сетевые сканеры, вирусы с всякой вредоносной ерундой, социальный инжиниринг и т.д. Более того, технология шагнула к нам в офисы, дома и машины. Атаки теперь проводятся на глобальной уровне — страна против страны — и каждый с интернет-подключением теперь может достаточно быстро загрузить инструкцию, как взломать ту или иную систему. Пока правительства вяло реагируют на такие угрозы и неэффективно работают на юридическом поле, вы, как системный администратор, находитесь на первой линии огня.
К сожалению, громких процессов очень мало, и случаются только, если жертва нападения или сам хакер широко известен.
Оставим интернет в стороне, и глянем на компьютерную безопасность, которая меня всегда очень сильно удивляла. Особенно в организациях.
Там умудряются по какой-то причине обходиться без громких инцидентов. Возьмите, к примеру, большие кабинеты офисов (особенно это принято в IT), где пароли клеят на мониторы и клавиатуры, и они обычно самые простые. Также их любят хранить в незакодированной форме внутри текстовых файлов — это самые распространенные примеры, но глупость коллег иногда просто вызывающая.
Рассылка почтой незашифрованной клиентской базы
— это еще один пример. И я также часто наблюдаю, как технические операторы службы поддержки (и даже плохо спроектированные системы) рассылают вместо с почтой и некоторые служебные поля. Кроме риска атаки вида «человек-в-середине-цепочки», что случится после того, как какой-нибудь Ваня или Вася сохранит такое письмо на рабочий стол?
Любый, кто имеет доступ на его машину, может узнать как скомпрометировать и чужую систему. Поэтому проблема заключается не только в применении лучшей защитной технологии, но также и в обучении

Анатомия компрометации FreeBSD (часть 1-я)
www.bsdmag.org
41
пользователей правильной работе.
Насколько вы защищены?
Я всегда говорил, что единственный способ
100% защитить сервер от вторжения, это залить его бетоном и отправить на дно океана. Может выгдялеть слишком экстремально, но высказывалось как-то предположение, что даже OpenBSD было скомпрометировано (см. статью в Register, табл. 3).
Существует слишком много векторов атак, различных багов и других замечательных путей заставить сегодняшние сложные приложения выполнять те задачи, для которых они вообще не проектировались.
Я частно использую telnet для проверки веб-серверов или, например, для отсылки тестовых электронных писем, но те современные диагностические утилиты, что не были доступны 30 лет назад, дают фантастическую фору для «черных» хакеров.
Возьмем, к примеру, эксплойты вида 0day. «Черный» хакер Петя обнаруживает недокументированную дырку в программе X. Он сообщает об этом друзьям , но просит их не рассказывать больше никому и не публиковать сей факт. Если системные администраторы, где работает программа, не обнаружат никакой странной активности вокруг их систем, и нет процесса, который такую активность может засечь, то Петя с друзьями могут остаться незамеченными. Только когда атака становится более явной и принимает угрожающий вид, тогда исследователь, связанный с безопасностью, начинает задумываться. Или же кто-то написал об аналогичной атаке и оригинальный разработчик программы X может тогда эту уязвимость устранить.
Все зависит от масштаба проблемы и риска — если атаки проводятся часто, то кто-нибудь заметит аномальность и, в случае серьезных повреждений, вопросы будут заданы сразу же. Но что происходит, когда Петя не говорит об уязвимости и использует ее время от времени? Шансы обнаружения малы, обзор проблемы узок, а сам разработчик и соответствующие эксперты даже не в курсе проблемы. Пока Петя не выпустил информацию в широкий доступ, уязвимость так и будет использоваться втихомолку. До момента, пока не достигнута точка кипения, проблема диагностирована, проанализирована и уязвимость устранена, а упомянутый Петя достаточно умен, чтобы не атаковать специально расставленную ловушку с этой уязвимостью.
Таблица 1. 10 заповедей системного администратора
10 заповедей администратора безопасности
Паранойя важна. Доказательства, основанные на паранойе, даже лучше. Журналируйте всё, включая контрольные суммы.
Ваш противник может быть ближе, нежели вы думаете.
Храните конфиденциальную информацию в секретном месте.
Шифруйте, защищайте паролями и разрешайте другим доступ только в случае, если им это действительно нужно.
Используйте сложные пароли и регулярно их меняйте. Не встраивайте пароли в скрипты.
Производите часто обновление системы.
Запускайте нужные службы, только если они очень-очень нужны. Потом же, не забывайте их защищать.
Регулярное архивирование не должно быть по желанию — оно обязательно.
Пробуйте взломать свои собственные системы. Вы будете удивлены обнаруженным. Не будьте удовлетворены результатом.
Не думайте, что и другие такие же сознательные, как и вы.
Расскажите им о вашей позиции.
Если вас атаковали — не паникуйте. Будьте методичны и сохраните улики. Если не уверены в собственных силах, или же инцидент достаточно серьезен, то пригласите профессионалов, прежде чем наломаете дров и не оставите ни следа. Не пытайтесь претворить аналогичное действие над вашим врагом — вы поставите под вопрос официальное расследование и, возможно, подставите себя.
Вы не одни. Большинство людей за «добрых» парней, нежели за «плохих».
На самом деле это реальная проблема со «многими неизвестными». Хорошие системы управления могут снизить риск, но никогда не уберут его полностью. Как и банковская система, наша IT-инфраструктура очень сильно основана на доверии. Конечно, мы можем придумать белые списки для наших серверов, так, что только наши уважаемые заказчики могли бы заходить на них. Но даже такое решение не будет практичным, т.к. достаточно просто будет заменить IP- и MAC- адреса. Частные сети находят свое применение, но в интернет-эпоху каждый хочет быть оставаться подключенным к сети. И аббревиатура WWW не расшифровывается как «всемирная паутина» (World
Wide Web), в реальности она означает «дикий, дикий запад» (Wild Wild West).
Знайте своего врага
«В искусстве войны» Сунь Цзы сказано — «Знайте своего врага». И системный администратор должен воспитать в себе такое военное отношение, как будто

12/2011 42
БЕЗОПАСНОСТЬ
бы у него есть нечто ценное, и которое не нужно терять.
Во-первых, самая очевидная часть уязвимости — это ваши пользователи. Строгая политика по применению ресурсов, которая официально поддержана и закреплена на самом верхнем уровне — хорошая отправная точка. Большая проблема при это может быть в сохранении баланса. Слишком запретительная и к IT будут относиться как к инструменту подавления.
Слишком мягкая? Тогда к ней будут относиться как бумажке, на которую можно наплевать.
Хорошим пунктом в ней может быть позиция по конфиденциальности и безопасности данных, т.к. многие страны сейчас иемют в своем законодательстве необходимые пункты по защите данных и электронной коммерции. Существует ряд коммерческих продуктов против потери данных, но те, кто хорошо понимает UNIX, ценят силу собственных скриптов. Будучи частью общей политики безопасности, любая конфиденциальная информация должна быть помечена как таковая. И будет довольно просто организовать сервер электронной почты, который такие прикрепления заводил бы в очередь, с последующей их проверкой. Если всё нормально, то сообщение пропускается. Идя далее по такому сценарию, электронная почта может быть сканирована на наличие ключевых слов и значений, и направлена в специальную очередь при совпадении. Единственной проблемой здесь может быть, что найдутся те, кто захочет обойти систему. Решения для этого может быть таким — использовать безопасный шлюз, куда файлы сгружаются и проверяются, а затем забираются заказчиком.
Интересным и распространным явлением является передача паролей и логинов устно по телефону или через факс. Но это уже проблема другого отдела.
Большинство же «домашних» уязвимостей созданы по ошибке (если честно, когда последний раз вы по ошибке отослали не тому адресату какой-либо важное письмо?) и хорошей практикой будет попытаться минимизировать потери.
Конфиденциальные документы на расшаренных ресурсах обычная практика, но используя специальные процедуры
(например, только веб-мастер может загружать на сервер документы) можно риски снизить. Также важен хороший файрволл, и несколько прокси- серверов, которые умеют работать с HTTP- и FTP- трафиком. Сканирование электронной почты на наличие вредоносных программ (включая ссылки и прикрепления) работает определенно хорошо, будучи централизировано.
Следующий момент — преднамеренное причинение ущерба персоналом. Я знаю, что документы и приложения могут быть специально удалены или украдены, или не туда направлены. Либо же наносится ущерб самой аппаратуре. Коллега моей жены стал саботировать систему, когда ему отказали в повышении. Поэтому это хороший фундамент, где руководство и IT-сотрудники могут найти общий язык
— когда существует риск в работе организации. Дело
Коли находится в папке на увольнение? Убедитесь, что его профиль и права на систему заблокированы, прежде чем он пойдет на встречу с отделом кадров.
И наконец, существует просто беспечность.
Большие открытые офисные пространства и широкие
TFT-экраны просто радость для подсматривающих. А
Таблица 2. 10 заповедей хакера
Хакер в черной шляпе — 10 заповедей
Скрывайте ваши следы. Никогда не показывайте свой собственный IP-адрес. Очищайте все места, где может храниться история ваших посещений.
Старайтесь заполучить привилегии суперпользователя.
Если они у вас есть, то весь мир у ваших ног и вы можете еще лучше спрятаться.
Не высвечивайте. Максимальное использование ресурсов сервера просто раскрывает вас. Вы не хотите, чтобы ваша жертва обратила внимание на вас, поэтому не берите много.
Ни один из серверов защищен на 100%, но некоторые защищены слабее. Опробуйте силы сначала на простых мишенях — чем больше распространена уязвимость, тем меньше шансов быть раскрытым.
Никому не доверяйте. Хвастаться вашим умением — это замечательно. Пока кто-нибудь не захочет вами заинтересоваться.
Если вы взламываете, то можете огорчить людей. Некоторые из них в достаточной власти, чтобы наказать вас — учитывайте риски.
Знайте, как программировать. Если вы не понимаете C, ассемблер и что такое указатели, то вы просто любитель.
Улучшайте социальные навыки. Один из действенных способов взлома — социальный инжиниринг. А это требует владение навыком управления другими людьми.
Будьте в курсе технологий. Новые уязвимости появляются каждый день, т.к. технологичская сфера увеличивается.
Существует мало экспертов в безопасности и много некудышных программистов.
Физический доступ к машинам почти всегда дает вам преимущество (например, позволяет расставить кейлоггеры), однако риски здесь выше.
1   2   3   4   5   6   7


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

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


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