LINUX.ORG.RU
ФорумAdmin

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

 


0

1

Здравствуйте всем. Интересует вопрос дублирования логов. Известно что хакер (или бывший сотрудник) после посещения атакуемого сервиса очень тщательно подтирает свои следы в всех логах. Возможно ли некоторые логи писать в стороннии дублем директории? Гугля промолчала :)

Перемещено alpha из general

☆☆☆

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

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

IvanR ★★★ ()

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

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

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

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.

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

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

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

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

sin_a ★★★★★ ()
Ответ на: комментарий от Bootmen

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

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

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

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

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

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

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

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

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

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

IvanR ★★★ ()
Последнее исправление: IvanR (всего исправлений: 1)
Ответ на: комментарий от IvanR

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

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

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

Bootmen ☆☆☆ ()
Последнее исправление: Bootmen (всего исправлений: 1)
Ответ на: комментарий от Bootmen

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

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

Bootmen ☆☆☆ ()
Последнее исправление: Bootmen (всего исправлений: 1)
Ответ на: комментарий от Bootmen

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

IvanR ★★★ ()

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

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

skyman ★★ ()
Ответ на: комментарий от IvanR

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

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

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

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

IvanR ★★★ ()
Ответ на: комментарий от Bootmen

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

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

sin_a ★★★★★ ()
Ответ на: комментарий от Bootmen

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

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

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

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

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

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

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

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

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

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

sin_a ★★★★★ ()
Ответ на: комментарий от Bootmen

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

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

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

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

Bootmen ☆☆☆ ()

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

Jameson ★★★★ ()
Ответ на: комментарий от Bootmen

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

Jameson ★★★★ ()
Ответ на: комментарий от Bootmen

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

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

IvanR ★★★ ()
Ответ на: комментарий от Bootmen

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

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

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

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

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

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

MumiyTroll ★★ ()
Последнее исправление: MumiyTroll (всего исправлений: 1)
Ответ на: комментарий от Bootmen

У меня сложилось впечатление что ты думаешь что файлы логов будут рсинком копироваться на удалённую машину. Это не так, демон логов, например 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
}

sin_a ★★★★★ ()

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

anc ★★★★★ ()
Ответ на: комментарий от sin_a

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

annulen ★★★★★ ()
Ответ на: комментарий от anc

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

anc ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.