отправка логов на удаленный сервер

rsyslogd может дублировать логи на удаленный хост, man rsyslogd и man rsyslog.conf

наверно у systemd тоже есть такая функция

rsyslogd может дублировать логи

Я знаю. Но, это делается по крону. Когда все поздно.

Может их сразу в ластик слать? Жирно конечно, но зато работает и в случае подозрительной активности алерты шлёт.

/etc/rsyslog.d/remote.conf

*.* @10.10.10.10

значит у вас по крону настроена отправка, сделайте отправку по-другому.

host1:
Aug 27 14:46:01 HOST systemd[1]: Started Session 12492 of user root.
host2:
Aug 27 14:46:01 HOST systemd[1]: Started Session 12492 of user root.

да, оно

системD пока не рассматривается. Коллеги. Интерисует запись логов в реальном времени в неизвестную директорию (для жулика)

Ты действительно намерен хранить логи на том же узле, рассчитывая что злоумышленник их не найдёт?

так тут дело не в системд, а в том, что логи любого сервиса можно отправить на удаленный сервер в реальном времени.

что злоумышленник их не найдёт? Воощето на такое не расчитываю. Хотя спрятать все можно в своем сундуке. :) Можно на др. машине.

Главно , чтоб данные защищены от перезаписывания.

Grafana Loki + Promtail спасут отца русской демократии.

отправка логов на удаленный сервер (комментарий)

Но, это делается по крону.

не думаю, это прописывается в конфиге rsyslogd и он отправляет логи в момент, кога приложение пишет логи

посмотрите внимательно маны, которые я привел, я уже не найду, как это делается, но помню, что это делается в конфиге

вот, вам написали, он будет в реальном времени отправлять логи

отправка логов на удаленный сервер (комментарий)

Grafana Loki

Разве это предохранит от чистки логов?

момент, кога приложение пишет логи

Пардон. Недосмотрел. Вообщето хотел сохранить логи на основной машинке-гдето в укромном месте.:)

А если цхакер запустит рсин на обновление?

А как он почистит, оно же в себе логи хранит.

А как он почистит, оно же в себе логи хранит.

Подробнее пож.

«Сибо» Тебе Админ. «отправка логов на удаленный сервер»

Я так тему не подписывал. Тема называлась: LOG" Зачем переправил? Итут выслушиваю всяко

ну, если хранить на локальной машине, то хакер может посмотреть в /etc/rsyslogd.conf и понять, куда еще логи пишутся, а если отправлять на удаленную машину, то вероятность ее взломать меньше, так как там ничего не будет установлено, кроме rsyslogd и, наверно, sshd

Детский сад, прятать логи на том же сервере надеясь что хакер не сможет посмотреть настройки логировпния на этом же сервере.

Дали внятный ответ уже - настроить rsyslog чтобы при появлении новых логов автоматом слал их на другой rsyslog или в какой-нибудь эластик или спланк.

то вероятность ее взломать меньше, так как там ничего

Ясный перец, что другую машинку не взломать. Однако хочется и на своей машинке второй вал защиты иметь

прятать логи на том же сервере над

Ну не скажите. Для гостя машинка-лес.

ну, можно написать демон, который будет стартовать из /etc/init.d и раз в минуту делать архив /var/log и рассовывать его под разными именами в разные директории, тогда хакер наверно не догадается, но все же лучше их еще отправлять на удаленный rsyslogd

Какой ты упертый. То, что ТЫ хочешь - это полумеры. Как надо, тебе уже подсказали.

Какой ты упертый

По теме ответ увидеть адекватный.

Если до системы получил доступ посторонний то система скомпрометирована и подлежит замене.

А «другой вал» это изолированная среда для каждой отдельной задачи. Возьми например proxmox и используй lxc контейнеры. Накладные расходы при этом стремятся к нулю. В каждом держи только одну задачу: http, sql, smb, smtp/imap… А злоумышленник получив доступ к отдельной системе не получит автоматически доступ к чему либо ещё.

ну, можно написать демон,

А вот это дельный костыль. Нарисую в баш. Сибо.

вообще-то я пошутил ))) проще отправлять логи на другой сервер, кстати, если не нравится использовать для этого rsyslogd, то отправляй scp, тоже секьюрно будет, если запускать демона под видом чего-то неприметного в /etc/init.d

Если на удалённую машину будет копироваться по scp то туда будет доступ по ssh, со всеми вытекающими последствиями…

да, не подумал или сертификаты будут или пароль где-то записанный, не секьюрно

проще отправлять логи на другой сервер, кстати, если н

Еще Раз: загаловок Темы был изначально: LOG. Нынешний-сервер... не мое. Админа походу исправил.

то система скомпрометирована и подлежит замене.

Не всегда. Как выше писал-бывший...

Он тебе уже руткит поставил и по выходным будет развлекаться. Любишь лотереи?

Он тебе уже руткит поставил и по выходным будет развлекаться

Похикил? Полегчало?

Тебе не просто так сказали как правильно решать такую задачу. Но ты можешь отбрасывать опыт других и собирать все шишки сам.

других и собирать все шишки сам.

давай проще. 25 лет уже шишки собираю.

Думаю что суммарный опыт шишкочасов у людей больше 25 лет в самых разных условиях и стоит того чтобы на него оглядываться.

Тебе не просто так сказали как правильно решать такую задачу. Но ты можешь

Небыло ответа. Только удаленный сервер-не ответ это.

Уже несколько раз ответили, но нет, хочу по своему. Промышленное решение rsyslog, и единый агрегатор логов в сети. Кроме серверов в сети бывают ещё и железки типа свичей и проч, которые тоже могут ломать и которым логи хранить тупо негде. И в них отправка логов на syslog сервер - штатное решение из коробки. Так что не нужно своё писать и сущности плодить, нужно настроить rsyslog, дабы везде царило единообразие. А на агрегаторе логов пользительно поднять их анализатор с рассылкой алертов, icinga2 например, тут уже по вкусу. На самих машинах и железках локально логи можно вообще не хранить, хакеру там подчищать будет нечего. А вот агрегатор логов имеет смысл усиленно защищать, но это обычно не сложно, так как на нём не принято держать что либо лишнее через что его можно взломать.

Промышленное решение rsyslog,

Коллега Вас Всех заклинило на рсинсе? Тема проще...

Суть не в «проще», а в том что архитектуру сети нужно сразу планировать и строить правильно. Например разносить сеть передачи данных и сеть управления по разным vlan, и через сеть управления уже и sshем ходить, и логи слать в одно место. Тогда хакер, который придёт именно по сети передачи данных, при грамотной настройке не сможет попасть в сеть управления вообще. А всю его суету можно будет наблюдать в реальном времени из одной точки.

Погоди, мне кажется ты чего-то недопонимаешь. При чём здесь рсинк?

Погоди, мне кажется ты чего-то недопонимаешь. При чём здесь рсинк?

Я и сам не понимаю. Грю про локал.

Коллега Вас Всех заклинило на рсинсе? Тема проще…

не на rsync, а на syslog, syslog пишет логи, когда их пишет приложение, а не копирует по расписанию

Для гостя машинка-лес.

Да щас. Все конфиги и скрипты (включая «демона» на bash) лежет тут же в тектовых файлах и найти копию логов на этом же хосте труда не составит.

25 лет уже шишки собираю.

Это грустно, что Вы за 25 лет не поняли даже основ...

Коллега Вас Всех заклинило на рсинсе?

Откуда Вы рсинк взяли, он в теме вообще не упоминался. Вам rsyslog советуют.

У меня сложилось впечатление что ты думаешь что файлы логов будут рсинком копироваться на удалённую машину. Это не так, демон логов, например rsyslogd будет сам отправлять их при появлении.

Но давай подойдём с другой стороны. А что тебе мешает сделать сервер логов? У тебя нет свободного компьютера? Но для этого можно использовать сколько угодно слабую машину, загрузка там устойчиво будет стремиться к нулю.

Для этого понадобится установить syslog-ng и создать например файл /etc/syslog-ng/conf.d/90_remote.conf

### remote logs
#

source s_net { udp(ip(0.0.0.0) port(514)); };

destination d_net {
   file( "/var/log/remote/$SOURCEIP-$HOST/$HOST.$FACILITY.log"
          template("$DATE $FACILITY $MESSAGE\n")
          template_escape(off)
          create_dirs(yes)
          dir_group(adm)
          dir_perm(0750)
          perm(0640)
          group(adm) );
   };

log { source(s_net); destination(d_net); };

После этого логи с каждой машины отправленные на этот адрес будут ложиться в соотв. каталог. И тебе останется только сделать ротацию:

# rotate remote logs
#

/var/log/remote/*/*.log {
    weekly
    rotate 53
    # 1 year
    notifempty
    missingok
    compress
}

На фоне прочитанного топика, дарю идею. Отрезаем кусман от диска, оставив его без раздела. Логи фигачим по inotify. Тут можно добавить развлечений в виде проверок старого размера файла и нового, в смысле если он неожидаемо стал меньше то сохранять по некому смещению, что бы предыдущий не затер и алерт на все телеграфы, телефоны. Саму[и] софтины не в коем случае не скриптом, онлу бинарники в каталогах /bin, /sbin, /usr/bin &etc. Названия придумать что бы сразу не вызывали подозрение, похожее на уже существующие, например у вас там крутиться почтарь с sendmail, ещё один процесс с названием sendmail не вызовет подозрений и наличие бинарника тоже, пофиг что есть ещё один такой же в другом каталоге, сравнивать не будут. Если лень заморачиваться с пустым куском диска, местом хранения можно выбрать любой каталог, куда скореее всего не полезут смотреть, например есть муся с базами, в её каталог и фигачим, время изменения файлов не вызовут подозрение ну и пожать заодно, в целом тут вам виднее. Запуск прописать в инит скрипт чего-то и так запускающегося, на примере sendmail в его же скрипт и пишем.

При этом если уж совсем включать параноика, то syslog-ng можно настроить записывать лог параллельно в несколько файлов в разных местах, да и rsyslog, наверное, так же умеет

Это ты так auditd изобретешь

Да, ну и наблюдатель за этим процессом. Если процесс внезапно умер то крик на все доступные средства связи.