Comments 26
> поместить скрипт в cron на запуск каждые 10 минут;
Да за 10 минут потенциально можно рута получить и деактивировать вашу систему.
Да за 10 минут потенциально можно рута получить и деактивировать вашу систему.
Да, можно. Но так мы об этом быстро узнаем хотя бы.
Как вы узнаете, если скрипт не сработает?
Узнаем. Я не 100% информации выложил.
К тому же, какие средства Вы можете предложить как альтернативу?
К тому же, какие средства Вы можете предложить как альтернативу?
Мониторинг логов в реальном времени, конечно же. Есть же средства для отслеживания изменений в файлах.
Они тоже используются. Только не всегда можно позволить постоянно мониторить логи из-за нагрузки.
Из-за нагрузки на сервера доступа? Серьёзно?
logfmon практически не грузит систему
UFO just landed and posted this here
Спасибо за статью.
Тоже задумывался о таких вещах.
Предположим взлом случился 31 декабря, все пьяные и отреагировать на письмо оперативно никто не может.
А почему-бы не лишить злоумышленника информации о том, где этот ключ можно применять?
Вот что из этого у меня получилось:
1) Не храним историю
2) Не храним known_hosts
3) Авторизуемся без проверки known_hosts
Если дело касается своих собственных виртуалок, наверное, это оправданно.
И сделать соответствующий alias в .bashrc.
Тоже задумывался о таких вещах.
Предположим взлом случился 31 декабря, все пьяные и отреагировать на письмо оперативно никто не может.
А почему-бы не лишить злоумышленника информации о том, где этот ключ можно применять?
Вот что из этого у меня получилось:
1) Не храним историю
ln -sf /dev/null ~/.bash_history
2) Не храним known_hosts
cd ~/.ssh
ln -sf /dev/null known_hosts
3) Авторизуемся без проверки known_hosts
ssh -o 'StrictHostKeyChecking no' user@remotehost
Если дело касается своих собственных виртуалок, наверное, это оправданно.
И сделать соответствующий alias в .bashrc.
К счастью(клиентов, конечно:) ) у нас всегда есть дежурный сотрудник, который может оперативно отреагировать на ситуацию.
Спасибо за комментарий!
Обдумаем модификацию.
Спасибо за комментарий!
Обдумаем модификацию.
Вообще-то, known_hosts можно хранить в формате, не позволяющем извлечь явно имена хостов. А с вашей конфигурацией можно MITM провести без проблем.
Поступило предложение ограничить ssh доступ на серверы доступа через firewall, разрешив доступ только с ip наших сотрудников. Хорошо. Но тут проблема: админов у нас не мало, у многих динамические ip. Да и что если срочно потребуется “поработать” находясь в поездке и т.д.?
Чем не устроил вариант использования технологии port knocking (другое название «DACL — dynamic access list»)?
На хабре уже было несколько статей об этом (раз и два)
Подобный подход использую уже несколько лет на различных Linux-серверах и на маршрутизаторах Mikrotik (у Cisco тоже такой функционал есть, но я не сильно подружился с их железками пока).
И ещё. В статье не сказано, может у Вас так и реализовано. Хорошей идеей будет перевесить ssh-сервер со стандартного порта. Тогда будет меньше всяких брутов и вообще логи будут меньше
Итого: «вешаем» ssh-сервер на нестандартный порт (например, 22222). Порт доступен по правилам firewall по спискам. Если IP нет в списке, а доступ очень хочется — используем port knocking, после чего этот IP попадает в список разрешённых. Чтоб списки не загаживались постоянно после использования port knocking с разных адресов, по крону восстанавливаем эталонный список firewall. Например, раз в сутки, в 5 утра — когда меньше вероятность, что кто-то будет работать с сервером
Как показывает практика — взломать можно все что угодно.
И не важно на каком порту висит ssh и используется ли при этом port knocking.
Если сильно будет нужно, то взломают с помощью той же соц. инженерии.
Например, устроятся к ним на работу, подсунут симпотичную девушку одному из админов и т.д.
Я не говорю, что не надо использовать port knocking, но в данной статье, человек просто рассказал о своем способе оповещения.
А оповещения, тоже штука нужная.
И не важно на каком порту висит ssh и используется ли при этом port knocking.
Если сильно будет нужно, то взломают с помощью той же соц. инженерии.
Например, устроятся к ним на работу, подсунут симпотичную девушку одному из админов и т.д.
Я не говорю, что не надо использовать port knocking, но в данной статье, человек просто рассказал о своем способе оповещения.
А оповещения, тоже штука нужная.
Порты и так нестандартные.
Технологию попробуем, спасибо!
Технологию попробуем, спасибо!
1. Вместо крона правильнее использовать специально разработанные для похожих задач средства. Auditd умеет передавать информацию о событиях в сокет или syslog. А ssh и pam могут логировать удачные/неудачные логины в audit.
2. Вы пишите, что админы имеют доступ только по ключу, а в скрипте парсите строку «Accepted password for»
3. И сама идеология спорна: логиниться с любых ip можно, но если кто-то логинится не с того ip, то мы все начинаем подпрыгивать и что-то выяснять. Пока вы будете устраивать «допрос с пристрастием» злоумышленник может уже сделать все что нужно.
2. Вы пишите, что админы имеют доступ только по ключу, а в скрипте парсите строку «Accepted password for»
3. И сама идеология спорна: логиниться с любых ip можно, но если кто-то логинится не с того ip, то мы все начинаем подпрыгивать и что-то выяснять. Пока вы будете устраивать «допрос с пристрастием» злоумышленник может уже сделать все что нужно.
Первым шагом мы через систему управления конфигурациями распространили на все физические сервера ssh ключи, для входа на них с серверов доступа без пароля
А чем не устроили парольные ключи и ssh-agent?
В идеале, для доступа на клиентские серверы не должен использоваться ключ с центрального узла. Только персонифицированные ключи администраторов, защищенные паролями.
Те все должно происходить так:
- Админ экспортирует свой ключ для целевого сервера в ssh-agent и заходит на управляющий сервер («сервер доступа»)
- Используя свой персональный ключ (пробрасываемый агентом) заходит на целевой сервер
Это позволяет решить проблему со взломом центарльного сервера: на нем нет никаких ключей, тем более беспарольных, а значит доступ к нему можно по ssh открыть, не боясь что при его взломе получат доступ к внутрененй инфраструктуре. + такой подход позволяет разграничивать доступ для админов: они могут иметь один аккаунт на центральном сервере, но при этом иметь доступ только на те узлы, на которые должны попадать (не говоря уже о том что можно хоть на каждый сервер уникальный ключ иметь и не как не влиять при этом на остальных администраторов)
Как-то не умали об этом варианте.
Рассмотрим и потестим.
Спасибо за рекомендацию.
Рассмотрим и потестим.
Спасибо за рекомендацию.
Еще в вашем случае уместно такое решение для динамических IP:
Что бы получать актуальные IP можно воспользоваться сервисами типа DynDNS.
Это, конечно, скрывает потенциальную дыру в безопасности (через атаки на DNS), но это все же лучше чем пускать всех подряд.
- Создаете отдельную цепочку для динамических IP и 22 локального порта на сервере доступа
- По крону, раз в 5 минут, например, цепочку очищаете и добавляете актуальные IP
Что бы получать актуальные IP можно воспользоваться сервисами типа DynDNS.
Это, конечно, скрывает потенциальную дыру в безопасности (через атаки на DNS), но это все же лучше чем пускать всех подряд.
Стандартная схема — туннелирование ssh через управляющий сервер. Ключ — на машине персонала. Управляющий сервер доступ к агенту не получает. «Сервер-жертва» доступ к агенту не получает.
Выглядит это так:
Выглядит это так:
Host access
Hostname 8.8.8.8
Port 22
ForwardAgent yes
User user
Host servers* !access
User user
Port 22
ProxyCommand ssh -W %h:%p -C access
У нас это реализовано приблизительно также (доступ, не алерты).
Два сервера доступа, с которых можно попасть на сервера, один открыт со всего мира (авторизация по логину/паролю/токену), второй открыт только для своих сетей (авторизация по логину/паролю).
Логины/пароли c радиуса(для первого сервера OTP-железка, для второго AD).
Далее, через sudo реализованы права доступа на рабочие сервера с серверов доступа по ключу, данные берутся из AD (пользователи могут попасть только на разрешенные сервера).
Шелл на сервера доступа не стандартный ни-разу, в нем ничего не выполнить, кроме разрешенного.
Эту систему я реализовывал сам. Сейчас она в продакшене на 2000+ серверов. До того как её внедрить, пробовал кучу возможных готовых решений, все было не то. Главное требование — реализация разграниченного доступа, пользователи в AD и токены.
Вот как то так.
Я б с удовольствием описал бы все подробности и ньюансы (типа по-шагового руководства к действию), но к сожалению, не могу вот так просто, без одобрения сверху этого сделать.
Два сервера доступа, с которых можно попасть на сервера, один открыт со всего мира (авторизация по логину/паролю/токену), второй открыт только для своих сетей (авторизация по логину/паролю).
Логины/пароли c радиуса(для первого сервера OTP-железка, для второго AD).
Далее, через sudo реализованы права доступа на рабочие сервера с серверов доступа по ключу, данные берутся из AD (пользователи могут попасть только на разрешенные сервера).
Шелл на сервера доступа не стандартный ни-разу, в нем ничего не выполнить, кроме разрешенного.
Эту систему я реализовывал сам. Сейчас она в продакшене на 2000+ серверов. До того как её внедрить, пробовал кучу возможных готовых решений, все было не то. Главное требование — реализация разграниченного доступа, пользователи в AD и токены.
Вот как то так.
Я б с удовольствием описал бы все подробности и ньюансы (типа по-шагового руководства к действию), но к сожалению, не могу вот так просто, без одобрения сверху этого сделать.
Можно обойтись и без анализа логов, через использование ~/.ssh/rc или /etc/ssh/sshrc
Sign up to leave a comment.
Простой способ дополнительной защиты: SSH — ALERT