LINUX.ORG.RU
Форум — Development  

Централизованный сбор логов auditd + RPC

 , , ,


0

1

Привет, ЛОР. Посоветуйте, как можно было бы спроектировать приложение для сети из 10 - 100 АРМ с ОС Linux, которое собирало бы логи auditd с машин и кидало их на один сервер?

Проблема в том, что логов этих очень много. Правило будет что-то вроде: 

auditctl -a exit,always -F arch=b64 -S open -S execve -S fchmodat -S fchownat -S exit -S exit_group
В стандартной конфигурации auditd набегает около 100 Мб логов в час или около 1Гб за рабочий день.

Поэтому нужно сделать:

1. Клиентскую часть, которая будет парсить логи и вытаскивать из них нужную информацию (приблизительно около 25% от исходного объёма лога);

2. Серверную часть, которая способна держать такую нагрузку с указанного количества машин;

3. SSL-шифрование;

4. Элементарный RPC, подразумевающий определённую реакцию сервера на приход тех или иных событий из локальных логов, в том числе - возможность ответа сервера клиенту по такому же каналу.

Требование заказчика - только С или С++. Вопрос - какие существует подходы для разработки таких программ? Может быть, есть что-то готовое? Если нет, то какие применяются обычно либы/фреймфорки? Какой выбрать протокол сообщений? (protobuf пробовал, не подходит)

Спасибо



Последнее исправление: Klymedy (всего исправлений: 1)

Ответ на: комментарий от anonymous

почиму?

Я пробовал скрестить его с boost::asio с ssl, ничего не вышло из-за сложностей передачи больших количеств сообщений. Сначала надо писать в канал размер сообщений, потом само сообщение - на одном конце. А на другом конце надо парсить буфер boost::asio - сначала вытаскивать размер, потом сообщение. Сам разработчик protobuf признал, что protobuf в версии для плюсов слишком заумно написан в этом месте. У Java версии protobuf есть удобные для такого случаи parse_delimited и write_delimited.

vitalyisaev2
() автор топика
Ответ на: комментарий от vitalyisaev2

ох лол...у меня сервер писаный как раз с протобуфером (правда там protobuf-c). он собирает данные с тысяч точек, много данных (ОЧЕНЬ много), и передача сообщения протобуфера (а протобуфер это просто сериализатор/парсер) со своим наворотом - это не проблема протобуфера, это проблема протокола.

А на другом конце надо парсить буфер boost::asio - сначала вытаскивать размер, потом сообщение.

Для этого пишется простой коллектор, который накапливает байтики и разбивает на порции по заголовочным размерам (при схеме <размер><данные>). Кстати:

Сначала надо писать в канал размер сообщений

есть зло. Писать надо в блок, в который же писать и данные и слать весь блок (пропуская сначала через трансформацию, например SSL).

И да:

Сам разработчик protobuf признал, что protobuf в версии для плюсов слишком заумно написан в этом месте.

Разработчик там вопроса не понял нифига. А вот ты сильно заумно таки пытаешься все сделать, это да.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо... Тогда, возможно, вернусь к нему.

у меня сервер писаный как раз с протобуфером (правда там protobuf-c). он собирает данные с тысяч точек, много данных (ОЧЕНЬ много), и передача сообщения протобуфера (а протобуфер это просто сериализатор/парсер) со своим наворотом - это не проблема протобуфера, это проблема протокола.

Если не секрет, как написан сервер? Многопоточный или асинхронный, или вообще через fork? Используется ли select или epoll, или что-то другое?

vitalyisaev2
() автор топика
Ответ на: комментарий от vitalyisaev2

не секрет, конечно. написан от руки :) вся работа асинхронная, пользуется epoll (кстати проектировал я его и начинал писать как раз на boost::asio::io_service, но требовался голый Си (именно поэтому protobuf-c) + сборка каким-то древним gcc (норвежцы странные люди, хм)). Каждый клиент получает свой контекст, который «живет» пока клиент не отвалится, у каждого своя среда, свои «правила», свой приоритет и набор разрешений, свой пакер, свой трансформер (криптование)...

anonymous
()
Ответ на: комментарий от anonymous

интересно! а шифрование с помощью OpenSSL? Через все эти не очень понятные BIO структуры? (возможно, я просто не нашёл документации хорошей)

vitalyisaev2
() автор топика
Ответ на: комментарий от vitalyisaev2

не. С шифрованием у меня все проще было. пользовать OpenSSL задачи вообще не стояло. И даже наоборот, очень не хотелось им его видеть, равно как и множество других сторонних библиотек.

там сейчас rc4 генератор. До этого у них вообще был простой ксор c sha1 от какого-то забитого на всех клиентах «пароля». Данные не сильно секретные, поэтому никому не нужны в чистом виде. Как и данные-события, которые идут от сервера к клиенту. Какую-то коммерческую тайну только методы обработки этих данных составляют.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development