Dear colleagues. I got the idea to develop the tool to audit Apache log files. Maybe somebody knows when I can get a list of all possible events (log records) or have some ideas how can I get it - you are welcome. Please help.
**where** I can get...
Хм. По идее, зависит от версии Апача, от состава применяемых модулей,
а также от того, не прикручено ли чего ещё сбоку (типа mod_jk).
Если бы я собирался такое сооружать, двинул бы в направлении
создания настраиваемого движка, способного обрабатывать
Апачёвые сообщения в соответствии с заданным набором правил.
Состав поддерживаемых сообщений как раз набором правил и
определяется.Если оный журналоанализатор предполагается как компонент системы
обнаружения атак, то можно не шибко тревожиться - в приличных
IDS такие средства попросту есть.
>Хм. По идее, зависит от версии Апача, от состава применяемых модулей,
>а также от того, не прикручено ли чего ещё сбоку (типа mod_jk).
>Да, так оно и есть.
>Если бы я собирался такое сооружать, двинул бы в направлении
>создания настраиваемого движка, способного обрабатывать
>Апачёвые сообщения в соответствии с заданным набором правил.Да, но такой движок мало возможен без четкого знания всех возможных эвентов продукта.
>Состав поддерживаемых сообщений как раз набором правил и
>определяется.Можно поподробнее?
>
>Если оный журналоанализатор предполагается как компонент системы
>обнаружения атак, то можно не шибко тревожиться - в приличных
>IDS такие средства попросту есть.Я не тревожусь за приличные IDS, я тревожусь за свое чадо, к тому же если брать приличные IDS, то они в редких случаях поддерживают Apache :-\
>>Если бы я собирался такое сооружать, двинул бы в направлении
>>создания настраиваемого движка, способного обрабатывать
>>Апачёвые сообщения в соответствии с заданным набором правил.
>
>Да, но такой движок мало возможен без четкого знания всех возможных
>эвентов продукта.
>Тут мы вплотную упираемся в вопрос - а что именно нужно с оными
событиями делать? Собственно движок может предоставлять
механизмы расширения, позволяющие
1. Парсить сообщения в структуры
2. Задавать триггера, активизируемые по набору условий.
Движок при этом должен уметь:
1. хранить структурированные (распарсённые) сообщения
2. выполнять по этим структурам запросы (так что хранить
лучше всего в БД, там средства выполнения произвольных
запросов уже есть)
3. отслеживать выполнение заданных условий (например:
появилось сообщение с такими-то значениями полей) и
выполнять код заданного триггера (хоть хранимая
процедура, хоть внешняя программа).
В идеале триггера могли бы производить запросы к базе
данных сообщений.Если сделать всё очень красиво, может даже за бабасы пойти :)
Если же по-простому делать, то работающую (хотя и кривенькую)
версию можно за месяц примерно накропать.>>Состав поддерживаемых сообщений как раз набором правил и
>>определяется.
>
>Можно поподробнее?
>Собственно, см. выше.
Какие сообщения парсить умеем, те и поддерживаем.
А набор триггеров и/или запросов по базе структурированных
таким образом логов зависит от цели рекомого аудита.>>
>>Если оный журналоанализатор предполагается как компонент системы
>>обнаружения атак, то можно не шибко тревожиться - в приличных
>>IDS такие средства попросту есть.
>
>Я не тревожусь за приличные IDS, я тревожусь за свое чадо, к
>тому же если брать приличные IDS, то они в редких случаях
>поддерживают Apache :-\http://www.modsecurity.org/
http://www.logreport.org/
Спасибо, все очень правильно.. почти) Но это мы уже ушли в детали. Мне пока что необходим только полный список нужных эвентов, которые я, кстати, в небольшом колличестве уже накопал. В конце я их описываю в регулярных выражениях... получается что-то типа этого:^dup2\((.*)\) failed
ну или
Cannot remove module (.*): not found in module list
Правда процедура не очень приятная - reverse engineering ....
I like Microsoft Windows(r) event log mechanism. It is standardized and we can get a list of all possible event from specific product's shared object for event logging (DLL). But apache hasn't this feature and something like this. All eventlog messages are chaotic :-(
This 'Microsoft Windows(r) event log mechanism' does not help
you to programmatically interpret messages. It helps to
automatically translate them, and provides a GUI to display
localized messages. Useful for userland, but not really neccessary
in the server end :). After all, Windoze event log will not
help you to perform automatic audit functions. It's not too
much better then plain text logs in that case.
А почему бы не парсить лог и не засовывать результат в базу данных. Прикрутить подобную штуковину к реально работающей системе, и за месяц наберется неплохая статистика. А на ее основе можно ваять дальше.Не согласен с утверждением о бесполезности виндовых логов для аудита.
>А почему бы не парсить лог и не засовывать результат в базу
>данных. Прикрутить подобную штуковину к реально работающей системе, и за месяц
>наберется неплохая статистика. А на ее основе можно ваять дальше.
>
>Не согласен с утверждением о бесполезности виндовых логов для аудита.Да, можно.. но это достаточно долго, к тому же нет никакой гарантии, что система будет находится в критических состояниях, будет часто меняться конфигурация и в логах появится достаточно вариаций системы. Так как код apache открыт, то, чтобы наверняка, я смотрю по коду, что и в каких случаях пишет сервер/модули.
>This 'Microsoft Windows(r) event log mechanism' does not help
>you to programmatically interpret messages. It helps to
>automatically translate them, and provides a GUI to display
>localized messages. Useful for userland, but not really neccessary
>in the server end :). After all, Windoze event log will not
>
>help you to perform automatic audit functions. It's not too
>much better then plain text logs in that case.Yeah! You are right... I mean every application which uses Windoze event log has specific DLL which can be used to extract all possible events. It can be very useful for me :-)
Боюсь я не до конца сформулировал свою мысль - на основе отпарсенного лога можно собрать статистику ОБЫЧНЫХ событий. Остальные события будут необычными, и, соответственно, требовать повышенного внимания сисадмина. Согласитесь, что добавление системе некоторого количества мозгов хуже ее не сделает.