Контролировать подключения

заюзай https://github.com/a2o/snoopy

в sshrc или /etc/profile засунь запуск нужного тебе скрипта, который будет выполнятся при логине юзера.

по логауту - парсь лог snoopy по юзеру и отправляй письмом себе.

я б так сделал.

elvis@building ~ $ sudo -i
building ~ # su - elvis
elvis вошёл в здание
elvis@building ~ $ exit
выход
elvis вышел из здания
building ~ # ls -l /home/elvis/.bash{rc,_logout} /etc/bashrc.log{in,out}
-rw-r--r--. 1 root root 40 май 19 21:20 /etc/bashrc.login
-rw-r--r--. 1 root root 42 май 19 21:20 /etc/bashrc.logout
-rw-r--r--. 1 root root 85 май 19 21:19 /home/elvis/.bash_logout
-rw-r--r--. 1 root root 290 май 19 21:18 /home/elvis/.bashrc

Ну и в .bashrc:
if [ -f /etc/bashrc.login ]; then
. /etc/bashrc.login
fi
В ~/.bash_logout
if [ -f /etc/bashrc.logout ]; then
. /etc/bashrc.logout
fi

А в /etc/bashrc.log{in,out}
echo ${USER} вошёл в здание
и
echo ${USER} вышел из здания
соответственно
А заскриптовать в /etc/bashrc.log{in,out} можно что угодно. Главное юзерам рутовых прав не давать, иначе быстро открутят.

еще лучше отлавливать login и logout через pam, вызывая свой скрипт через pam_exec.so по нужному тебе событию.

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

Если «поимели» то без разницы «что ты одела» (с)

так настрой удаленный сборщик для syslog, это вроде не проблема.

Совершенно верно, но в наших загнивающих Европах если поимели сервер и ты ответственен за IT то какой-нибудь COO, CTO, CEO и т.д. вызовет на ковер и задаст два вопроса:

- Что случилось?

- Что предприняли чтобы предотвратить?

А т.к. работаю с серьезными дядьками, то скорей всего еще и аудит сторонний закажут по итогам разбора полетов. И если в итоге получится что ты даже не знаешь как именно и что случилось и аудит это покажет, то будет «давай до свидания» скорее всего.

Отсюда и интересуюсь.

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

Не поможет для вариантов ssh user@host command

Бигбро, смотри, не переусердствуй со шпионажем, а то админы взбунтуются и устроят тебе дворцовый переворот.

А ежели кроме тебя никто не админит, то и затея так себе.

К сожалению, да.

Я вот изучаю эту тему и реально не понимаю: неужели никто еще не реализовал подобный функционал? Ну то есть либо я перемудрил и это «ненужно», либо люди используют какие то костыли.

Я еще могу понять когда админят сеть из 1-5 серверов, там в принципе может быть один-два админа и ключи все у них, но ведь есть же и большие инсталляции на 100-200 машин которые еще и динамически расширяются-сжимаются.

Я уж не говорю про ситуации, на моей памяти, когда SSH ключи ходят по рукам и случайно загружаются в гит.

Вот парень реализавал что-то подобное ---> https://www.jms1.net/ssh-record.shtml

Там используется довольно простой перл скрипт, который при желании можно допилить.

Еще можно посмотреть в сторону руткитов ;)

Так вам вроде в первом посте анон ответил? Вы пробовали?

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

imho: если нужно логирование то надежнее всего патчить ssh

auditd - правильно. Только его нужно куда-то заслать, там поставить какой-нибудь graylog(лучше - купить коммерческий аналог, чтобы у заказчика не складывалось впечатление бесплатности происходящего), и нанять выделенного человека смотреть туда, т.к. изначально, это никому не интересно.

и нанять выделенного человека смотреть туда

cast u0atgKIRznY5

Но по крайней мере кто заходит можно сделать с помощью скрипта.
Добавить в .bashrc команды оповещения. И тогда кто зайдёт, выполниться bashrc.

А чтобы контролировать кто что писал, надо написать модуль ядра, который будет перехватывать write функцию. Это keylogger. Об этом немного написано в книге боевое программирование в линукс. Так же есть исходники, но для ядра 2.6. Думаю в нынешних ядрах тоже заработает. У каждой функции есть свой адрес. Адреса можно было поменять и выполнить сначала свои действия, а потом действия оригинальной функции. Ну понял, тебе нужен кейлоггер.

И все равно при учете:

Я уж не говорю про ситуации, на моей памяти, когда SSH ключи ходят по рукам и случайно загружаются в гит.

не факт что докопается до истиной причины... конечно все зависит от цели которой хочет достигнуть какер и его квалификации.
ЗЫ А при нужной «квалификации» отмазок, даже если и спалят будет как про Штирлица «апельсины приносил»

Ну это все понятно. Неприступных не бывает. Но хотелось бы выполнять хоты бы какой то стандартный минимум.

Вот например, для Web приложений есть OWASP, и если следовать их рекомендациям с подтверждением независимыми аудиторами, то вроде как и взятки гладки в случае чего.

Однако ничего подобного нет для IT инфраструктуры.

Нет спасибо, мне не нужен кейлоггер.

Ну это все понятно. Неприступных не бывает. Но хотелось бы выполнять хоты бы какой то стандартный минимум.

«На каждую хитрую попу...» надеюсь вы поняли.

Однако ничего подобного нет для IT инфраструктуры.

Чую что бы хотите «кнопку сделай мне зашибись»

Вот выше Контролировать подключения (комментарий) вам анон все правильно написал:

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

Продолжая:

Вот например, для Web приложений есть OWASP, и если следовать их рекомендациям с подтверждением независимыми аудиторами, то вроде как и взятки гладки в случае чего.

Страусиная политика? Ну тогда ставьте сертифицированные дистры, используйте на них только сертифицированные приложения, накатывайте своевременно обновления, не забудьте про подписку, и тогда тоже следуя вашей логике будет «вроде как и взятки гладки в случае чего»

Нет почему же, это не страусиная политика.

Вот допустим, я рулю IT инфраструктурой, у меня есть один главный админ и у него два админа помладше. Что же получается? Вся моя политика безопасности зависит от квалификации и желания главного админа?

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

1.1. SSH на порту 22 будет подвержен атаке китайский ботов.

Решение 1.1.1. Перевести SSH на другой порт.

Решение 1.1.1. Настроить fail2ban.

1.2. Юзеры не должны использовать пароли для доступа по SSH.

Решение 1.2.1. Использовать ключ.

И т.д. и т.п.

Таким образом получится базовая защита, а дальше уже пусть будут умения админа, но базова система будет защищена.

Какой-то​ сумбур...
Сначала тебе надо продумать и расписать вектора атаки: кто, как, когда, зачем.
Дальше расписываешь варианты противодействия для каждого вектора.
По выполнению - отчёт мне на стол, второй экземпляр в этот топик

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

Вот допустим, я рулю IT инфраструктурой

Начнем с вопроса: Что такое «IT инфраструктура»? Сферическая и в вакууме? Для начала опишите для себя всю инфраструктуру подконтрольную вам, тогда станет понятнее где/что/и-каким-образом защищать от возможных атак. А то так на кофейной гуще можно гадать долго.

Ну так дело в том что я именно такой отчет и ищу. Я не специалист по безопасности, увы.

Уж простите за грубость. Но может вы не соответствующую квалификации должность занимаете?

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

По сути мне не надо ничего описывать дальше 48 х серверов «Ubuntu 16.04 LTS», к примеру. Как раз таки по должности, если уж брать совсем формально, мне не надо опускаться ниже этого уровня, ибо для этого есть админы.

Так вот, уже сам по себе «Ubuntu 16.04 LTS» несет в себе определенные сервисы, которые нужно либо отключить, либо обезопасить. Где есть конкретное руководство, какие сервисы отключать и/или их же обезопасить.

Сферическая и в вакууме?

Другой пример: вот я сделал систему java + Oracle и развернул ее на пресловутом Ubuntu 16.04 LTS. Да, я совершенно точно знаю как защитить java и Oracle, однако это не помешает мне оставить отключеным firewall и пользователя root с паролем admin.

Поэтому я и говорю что хочу абстрагироваться от конкретики, просто тупо набор формальных рекомендаций и best practices по эксплуатации более менее стандартных сборок Linux.

Вот пожалуйста вам пример для веб приложений: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents

Защитят ли эти тесты от всех возможных векторов атак? Конечно нет. Но они дадут очень хороший фундамент после которого уже и можно вот это вот

Для начала опишите для себя

Что толку то описывать конкретику когда общая картина вся в дырках?

Поэтому я и говорю что хочу абстрагироваться от конкретики, просто тупо набор формальных рекомендаций и best practices по эксплуатации более менее стандартных сборок Linux.

Угу «абстрагироваться от конкретики» «по эксплуатации более менее стандартных» автомобилей(найдите разницу между заз и бмв)/самолетов(сессна которая планирует и например боинг777 который тупо рухнет)/вертолетов(ми2 и ка50)

Возможные «стандартные» рекомендации:

ЗАЗ - БМВ:

- Закрыть двери перед началом движения.

- Пристегнуть ремни безопасности.

- Проверить давление воздуха в колесах.

Самолеты:

- Убедиться в наличии топлива достаточном для совершения маршрута.

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

Епаныйврот, вы меня троллить тут чтоли вздумали?

Епаныйврот, вы меня троллить тут чтоли вздумали?

Ни в коем случае, уж простите если был понят не правильно.
Исключительно пытался донести до вас что «нет понятия стандартный» проблемы же возникают не в «стандартном» а в вполне конкретных демонах/программах/etc которые еще и имеют разнае версии...
Ваша тема заявленная в топике переросла в другую плоскость

Ни в коем случае, уж простите если был понят не правильно.

Да не надо мне теперь на вы. Что за бред? Да, есть понятие стандартный, есть!!! Стандартный это не ставить пароль admin на пользователя рут, стандартный это не разрешать руту вообще логиниться через ssh, стандартный это настраивать iptables не только на вход, но еще и на выход, стандартный это ставить apparmor туда куда его надо ставить.

Вы, уважаемый, вообще понимаете о чем я? Вы уже и так и эдак, и к должности моей прикапались и я уже привел пример конкретного документы от OWASP, нет, все не так!!!

Да, совершенно верно, и я тоже об этом уже сказал и привел пример, что проблемы возникают в конкретной реализации, но это не отменяет того факта что есть некие политики которые применимы к системе в целом. И я тоже привел пример.

Нет, вы мне сравниваете самолеты с вертолетами, но даже там я объяснил что конкретно имею в виду.

Совершенно верно, но в наших загнивающих Европах если поимели сервер и ты ответственен за IT то какой-нибудь COO, CTO, CEO и т.д. вызовет на ковер и задаст два вопроса:

Но если реализовать функционал по слежке и протоколированию, то ещё до тех двух вопросов можно быстро получить обвинение, если предпринятые меры не описаны для всех пользователей/админов, которые под них подпадают, и от них не получены подписи, что согласны. Хотя можно и так переусердствовать, что всё равно это будет недействительно.

Для этого есть легальщики. Хотя тут речь идет скорее об обезличенных подключениях нежели о каких то конкретных данных.

Что за бред? Да, есть понятие стандартный, есть!!! Стандартный это не ставить пароль admin на пользователя рут, стандартный это не разрешать руту вообще логиниться через ssh, стандартный это настраивать iptables не только на вход, но еще и на выход, стандартный это ставить apparmor туда куда его надо ставить.

Вот видите, вы сами написали коренное слово «настраивать» а это как раз и есть основной пласт работы. А настраиваем мы что? Правильно вполне конкретный софт которого чуть больше чем дофига + еще и разное поведение в зависимости от версии.
Хорошо, давайте возьмем частный пример, WP (который перманентно уязвим) но мы честно следуя рекомендациям постоянно его обновляем - запустили н-цать таких штук в lxc, но вот не задача lxc мы приготовили плохо, и после очередного взлома wp нам бомбануло и хост систему. Т.е. в целом мы следовали частным рекомендациям, но результат плачевный.
ЗЫ Повторюсь, это все уже за рамками задачи которую вы описали в топике, а готовых решений вам накидали, только вы все еще не довольны и не хотите даже пробовать их.

когда SSH ключи ходят по рукам и случайно загружаются в гит

man sshd
/authorized_keys file format
/from=

иногда будет лучше, чем ничего.

апельсины приносил

ausearch | суд

вообще редко работает.

Спасибо большое ЛОР за приятную дискуссию и за то что подсказал инструмент который решает большинство проблем поднятых здесь в автоматическом режиме: https://cisofy.com/download/lynis/