Size: a a a

DevOps — русскоговорящее сообщество

2021 February 18

VC

Vladimir Chernyshev in DevOps — русскоговорящее сообщество
Slava
Так, и еще 1 момент плз тогда))

Если говорят, что будет использовать SSR (Server Side Rendering) - это означает, что на СЕРВЕРЕ должна быть node (+ angular)?
скорее да чем нет
источник

AK

Andrey Kartashov in DevOps — русскоговорящее сообщество
/report
источник

D

DevOps Help Bot in DevOps — русскоговорящее сообщество
Report command works on replied messages only.
источник

jp

jarmil prdel in DevOps — русскоговорящее сообщество
0.19?
источник

FL

First Name Last Name in DevOps — русскоговорящее сообщество
Проблема с библиотекой распознавания Tessearact
Кто может настроить?
источник

АТ

Андрей Трефилов... in DevOps — русскоговорящее сообщество
Народ, привет.
Посоветуйте статьи по организации иммутабельного хранилища аудит-логов Linux'а.
Задача - не допустить сокрытия событий доступа к системе в случае её компроментации
Заранее спасибо)
источник

a6

admin 666admin in DevOps — русскоговорящее сообщество
Андрей Трефилов
Народ, привет.
Посоветуйте статьи по организации иммутабельного хранилища аудит-логов Linux'а.
Задача - не допустить сокрытия событий доступа к системе в случае её компроментации
Заранее спасибо)
Статей как таковых панацейных нет, чтобы логировать вообще все то хватит базовых siem-наборов (wazuh+shoopy) с хранением логов на удаленном хранилище. Опять же, 'события доступа' и "компрометация" - это очень размытые термины, делайте себе ТЗ чтобы было понимание что такое события доступа и компрометация и потом уж на основании этого подбирайте себе инструменты. Можно заколхозить по сислогу auth.log, а можно вкрячить туда суперсиемыне вещи с с полным аудитом всех вызовов и анализом процессов.
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
rsyslog + auditd + отправка на удаленный сервер к которому будет ограниченый доступ.
источник

АТ

Андрей Трефилов... in DevOps — русскоговорящее сообщество
admin 666admin
Статей как таковых панацейных нет, чтобы логировать вообще все то хватит базовых siem-наборов (wazuh+shoopy) с хранением логов на удаленном хранилище. Опять же, 'события доступа' и "компрометация" - это очень размытые термины, делайте себе ТЗ чтобы было понимание что такое события доступа и компрометация и потом уж на основании этого подбирайте себе инструменты. Можно заколхозить по сислогу auth.log, а можно вкрячить туда суперсиемыне вещи с с полным аудитом всех вызовов и анализом процессов.
Спасибо за ответ)
"Событие доступа" по большей части - логин в систему или взаимодействие с ФС. "Компроментация" - повышение прав пользователя, при котором возникает возможность логи поправить.
Для сбора планирую использовать auditd с отправкой на удаленный сервер.
Проблема в предотвращении перезаписи логов на удаленном сервере, так как он также может быть скомпрометирован
источник

АТ

Андрей Трефилов... in DevOps — русскоговорящее сообщество
Короче, необходимо иметь возможность расследовать инцидент и предотвратить его сокрытие со стороны "взломщика"
источник

a6

admin 666admin in DevOps — русскоговорящее сообщество
Андрей Трефилов
Спасибо за ответ)
"Событие доступа" по большей части - логин в систему или взаимодействие с ФС. "Компроментация" - повышение прав пользователя, при котором возникает возможность логи поправить.
Для сбора планирую использовать auditd с отправкой на удаленный сервер.
Проблема в предотвращении перезаписи логов на удаленном сервере, так как он также может быть скомпрометирован
Бекапьте логи тогда в air gaps или сделайте так чтобы их нельзя было вайпнуть (chattr,file ACLS и тд)
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Андрей Трефилов
Спасибо за ответ)
"Событие доступа" по большей части - логин в систему или взаимодействие с ФС. "Компроментация" - повышение прав пользователя, при котором возникает возможность логи поправить.
Для сбора планирую использовать auditd с отправкой на удаленный сервер.
Проблема в предотвращении перезаписи логов на удаленном сервере, так как он также может быть скомпрометирован
Чтобы такого небыло его нужно ограничить максимально,  вход по ssh только по ключам, без рутового доступа, только юзверям в определенной группе, только с определенных IP
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
admin 666admin
Бекапьте логи тогда в air gaps или сделайте так чтобы их нельзя было вайпнуть (chattr,file ACLS и тд)
chattr только после копии иначе в origin хер что запишется ))
источник

a6

admin 666admin in DevOps — русскоговорящее сообщество
Андрей Трефилов
Короче, необходимо иметь возможность расследовать инцидент и предотвратить его сокрытие со стороны "взломщика"
В любом случае это SIEM у Вас получается на выходе, а потом это обрастёт IPSами и IDSками, потом контурами, перимитрами vlan per user и пойдёт жара
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Ну если уж совсем упороться то конечно всяких SNORT+ SUrricata, + selinux или apparmor добавить
источник

a6

admin 666admin in DevOps — русскоговорящее сообщество
zeleniumex
chattr только после копии иначе в origin хер что запишется ))
Я и с чатром вайпну, если мне надо будет хехе (от серьёзного хаксора аудитд не спасет)
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
admin 666admin
Я и с чатром вайпну, если мне надо будет хехе (от серьёзного хаксора аудитд не спасет)
Да понятно, что сможешь.
источник

a6

admin 666admin in DevOps — русскоговорящее сообщество
zeleniumex
Ну если уж совсем упороться то конечно всяких SNORT+ SUrricata, + selinux или apparmor добавить
это старьё я бы не стал, есть куда более простые и производительные вещи.
источник

АТ

Андрей Трефилов... in DevOps — русскоговорящее сообщество
admin 666admin
это старьё я бы не стал, есть куда более простые и производительные вещи.
можете накидать примеров, если не сложно?
источник

z

zeleniumex in DevOps — русскоговорящее сообщество
Андрей Трефилов
можете накидать примеров, если не сложно?
источник