форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"How to audit apache log messages?"
Сообщение от Vladislav Lazarenko on 21-Дек-04, 18:47  (MSK)
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.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "How to audit apache log messages?"
Сообщение от Vladislav Lazarenko on 21-Дек-04, 18:48  (MSK)
**where** I can get...
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	2. "How to audit apache log messages?"
	Сообщение от DeadMustdie (??) on 21-Дек-04, 19:35  (MSK)
	Хм. По идее, зависит от версии Апача, от состава применяемых модулей, а также от того, не прикручено ли чего ещё сбоку (типа mod_jk). Если бы я собирался такое сооружать, двинул бы в направлении создания настраиваемого движка, способного обрабатывать Апачёвые сообщения в соответствии с заданным набором правил. Состав поддерживаемых сообщений как раз набором правил и определяется. Если оный журналоанализатор предполагается как компонент системы обнаружения атак, то можно не шибко тревожиться - в приличных IDS такие средства попросту есть.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "How to audit apache log messages?"
	Сообщение от Vladislav Lazarenko on 21-Дек-04, 20:02  (MSK)
	>Хм. По идее, зависит от версии Апача, от состава применяемых модулей, >а также от того, не прикручено ли чего ещё сбоку (типа mod_jk). > Да, так оно и есть. >Если бы я собирался такое сооружать, двинул бы в направлении >создания настраиваемого движка, способного обрабатывать >Апачёвые сообщения в соответствии с заданным набором правил. Да, но такой движок мало возможен без четкого знания всех возможных эвентов продукта. >Состав поддерживаемых сообщений как раз набором правил и >определяется. Можно поподробнее? > >Если оный журналоанализатор предполагается как компонент системы >обнаружения атак, то можно не шибко тревожиться - в приличных >IDS такие средства попросту есть. Я не тревожусь за приличные IDS, я тревожусь за свое чадо, к тому же если брать приличные IDS, то они в редких случаях поддерживают Apache :-\
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "How to audit apache log messages?"
	Сообщение от DeadMustdie (??) on 22-Дек-04, 19:52  (MSK)
	>>Если бы я собирался такое сооружать, двинул бы в направлении >>создания настраиваемого движка, способного обрабатывать >>Апачёвые сообщения в соответствии с заданным набором правил. > >Да, но такой движок мало возможен без четкого знания всех возможных >эвентов продукта. > Тут мы вплотную упираемся в вопрос - а что именно нужно с оными событиями делать? Собственно движок может предоставлять механизмы расширения, позволяющие   1. Парсить сообщения в структуры   2. Задавать триггера, активизируемые по набору условий. Движок при этом должен уметь:   1. хранить структурированные (распарсённые) сообщения   2. выполнять по этим структурам запросы (так что хранить      лучше всего в БД, там средства выполнения произвольных      запросов уже есть)   3. отслеживать выполнение заданных условий (например:      появилось сообщение с такими-то значениями полей) и      выполнять код заданного триггера (хоть хранимая      процедура, хоть внешняя программа). В идеале триггера могли бы производить запросы к базе данных сообщений. Если сделать всё очень красиво, может даже за бабасы пойти :) Если же по-простому делать, то работающую (хотя и кривенькую) версию можно за месяц примерно накропать. >>Состав поддерживаемых сообщений как раз набором правил и >>определяется. > >Можно поподробнее? > Собственно, см. выше. Какие сообщения парсить умеем, те и поддерживаем. А набор триггеров и/или запросов по базе структурированных таким образом логов зависит от цели рекомого аудита. >> >>Если оный журналоанализатор предполагается как компонент системы >>обнаружения атак, то можно не шибко тревожиться - в приличных >>IDS такие средства попросту есть. > >Я не тревожусь за приличные IDS, я тревожусь за свое чадо, к >тому же если брать приличные IDS, то они в редких случаях >поддерживают Apache :-\ http://www.modsecurity.org/ http://www.logreport.org/
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "How to audit apache log messages?"
	Сообщение от Vladislav Lazarenko on 23-Дек-04, 11:54  (MSK)
	Спасибо, все очень правильно.. почти) Но это мы уже ушли в детали. Мне пока что необходим только полный список нужных эвентов, которые я, кстати, в небольшом колличестве уже накопал. В конце я их описываю в регулярных выражениях... получается что-то типа этого: ^dup2\((.*)\) failed ну или Cannot remove module (.*): not found in module list Правда процедура не очень приятная - reverse engineering ....
		Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "How to audit apache log messages?"
Сообщение от Vladislav Lazarenko on 21-Дек-04, 20:19  (MSK)
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 :-(
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "How to audit apache log messages?"
	Сообщение от Dead Mustdie on 22-Дек-04, 16:43  (MSK)
	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.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "How to audit apache log messages?"
	Сообщение от dimus (??) on 23-Дек-04, 11:41  (MSK)
	А почему бы не парсить лог и не засовывать результат в базу данных. Прикрутить подобную штуковину к реально работающей системе, и за месяц наберется неплохая статистика. А на ее основе можно ваять дальше. Не согласен с утверждением о бесполезности виндовых логов для аудита.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "How to audit apache log messages?"
	Сообщение от Vladislav Lazarenko on 23-Дек-04, 12:04  (MSK)
	>А почему бы не парсить лог и не засовывать результат в базу >данных. Прикрутить подобную штуковину к реально работающей системе, и за месяц >наберется неплохая статистика. А на ее основе можно ваять дальше. > >Не согласен с утверждением о бесполезности виндовых логов для аудита. Да, можно.. но это достаточно долго, к тому же нет никакой гарантии, что система будет находится в критических состояниях, будет часто меняться конфигурация и в логах появится достаточно вариаций системы. Так как код apache открыт, то, чтобы наверняка, я смотрю по коду, что и в каких случаях пишет сервер/модули.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "How to audit apache log messages?"
	Сообщение от Vladislav Lazarenko on 23-Дек-04, 11:49  (MSK)
	>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 :-)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "How to audit apache log messages?"
	Сообщение от dimus (??) on 30-Дек-04, 15:20  (MSK)
	Боюсь я не до конца сформулировал свою мысль - на основе отпарсенного лога можно собрать статистику ОБЫЧНЫХ событий. Остальные события будут необычными, и, соответственно, требовать повышенного внимания сисадмина. Согласитесь, что добавление системе некоторого количества мозгов хуже ее не сделает.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.