Где вы оставляете следы, когда подключаетесь по SSH к серверу на базе Linux? Собрал краткую подборку основных ваших артефактов в Debian. Будет актуальна во всех дистрибутивах на её основе. Для других могут отличаться только частности в виде имён и путей к логам, но общий смысл будет тот же.
На всякий случай сразу предупреждаю, что если логи отправляются во внешнее хранилище, то вы там наследили сразу в момент подключения. Поэтому важно иметь своё внешнее по отношению ко всем серверам хранилище системных логов.
1️⃣ Подключение по SSH фиксируется в
Лога может не быть, либо логи могут параллельно храниться в journald. Смотреть так:
2️⃣ Информация о подключении будет записана в бинарный лог
3️⃣ Информация о последнем логине пользователя хранится в бинарном файле
4️⃣ Пока вы не отключились, информация о вашей активной сессии вместе с остальными сессиями хранится в бинарном файле
5️⃣ Если во время подключения были неудачные попытки с неправильным логином и паролем, то эта информация будет сохранена в бинарном файле
6️⃣ Если что-то делали в консоли, то информация об этом сохранится в текстовом файле
В рамках сессии история будет сохраняться и отображаться по команде
Для скрытия информации о подключении можно банально обнулить указанные выше логи и бинарные файлы. О вас не останется информации, но станет понятно, что кто-то подключался. Я, кстати, с подобным сталкивался. Когда только устроился в одну компанию. Через несколько дней после начала работы, когда стал проверять все серваки и разбираться в инфраструктуре, заметил на одном из серверов очищенную историю и прочие следы. Остаётся только гадать, что там делал бывший админ.
Просто взять и удалить информацию о себе из бинарных файлов не очень просто. Как один из вариантов - взять готовый скрипт, который на основе IP адреса вычистит информацию в том числе из бинарных логов. У меня на Debian 12 он не завёлся. Всё время ругался на UTMP block size. Мучал уже родной ChatGPT с chatgpt.com на эту тему, не смог помочь. Много всего предложил, но ничего не помогло. В конце предложил по-другому очистить файл: удалить и заново создать. Забил.
Для того, чтобы от подобных очисток защититься, достаточно на любом Linux сервере запустить syslog сервер или systemd-journal-remote. И вы всегда будете знать, кто и когда к вам подключается. Для логов службы sshd не нужно ни много ресурсов, ни места на диске. Нет нужды разворачивать какое-то специальное хранилище для логов, если у вас в нём нет нужды. Я отдельно для syslog сервера поднимал виртуалку 1CPU/512M/10G.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #security
На всякий случай сразу предупреждаю, что если логи отправляются во внешнее хранилище, то вы там наследили сразу в момент подключения. Поэтому важно иметь своё внешнее по отношению ко всем серверам хранилище системных логов.
1️⃣ Подключение по SSH фиксируется в
/var/log/auth.log. С ним всё просто - это текстовый лог. Сразу посмотреть удачные подключения можно так:# grep 'Accepted' /var/log/auth.logЛога может не быть, либо логи могут параллельно храниться в journald. Смотреть так:
# journalctl -u ssh -r2️⃣ Информация о подключении будет записана в бинарный лог
/var/log/wtmp. Смотреть в консоли командой last. Увидите информацию о дате логина, пользователе, его IP адресе. Там же дополнительно хранится информация о загрузках и выключениях сервера, в том числе кем они были инициированы. Могу сразу для расширенной информации посоветовать ключи: last -Faiwx.3️⃣ Информация о последнем логине пользователя хранится в бинарном файле
/var/log/lastlog. Смотреть одноимённой консольной командой lastlog. Увидите список всех системных пользователей и дату их последнего подключения вместе с IP адресом.4️⃣ Пока вы не отключились, информация о вашей активной сессии вместе с остальными сессиями хранится в бинарном файле
/var/run/utmp. Смотреть информацию оттуда можно командой who.5️⃣ Если во время подключения были неудачные попытки с неправильным логином и паролем, то эта информация будет сохранена в бинарном файле
/var/log/btmp. Смотреть командой lastb.6️⃣ Если что-то делали в консоли, то информация об этом сохранится в текстовом файле
~/.bash_history. Если не хотите, чтобы это происходило, после логина измените место хранения истории через переопределение переменной. Выполните в консоли:# export HISTFILE=/dev/nullВ рамках сессии история будет сохраняться и отображаться по команде
history, но в файл записана не будет.Для скрытия информации о подключении можно банально обнулить указанные выше логи и бинарные файлы. О вас не останется информации, но станет понятно, что кто-то подключался. Я, кстати, с подобным сталкивался. Когда только устроился в одну компанию. Через несколько дней после начала работы, когда стал проверять все серваки и разбираться в инфраструктуре, заметил на одном из серверов очищенную историю и прочие следы. Остаётся только гадать, что там делал бывший админ.
Просто взять и удалить информацию о себе из бинарных файлов не очень просто. Как один из вариантов - взять готовый скрипт, который на основе IP адреса вычистит информацию в том числе из бинарных логов. У меня на Debian 12 он не завёлся. Всё время ругался на UTMP block size. Мучал уже родной ChatGPT с chatgpt.com на эту тему, не смог помочь. Много всего предложил, но ничего не помогло. В конце предложил по-другому очистить файл: удалить и заново создать. Забил.
Для того, чтобы от подобных очисток защититься, достаточно на любом Linux сервере запустить syslog сервер или systemd-journal-remote. И вы всегда будете знать, кто и когда к вам подключается. Для логов службы sshd не нужно ни много ресурсов, ни места на диске. Нет нужды разворачивать какое-то специальное хранилище для логов, если у вас в нём нет нужды. Я отдельно для syslog сервера поднимал виртуалку 1CPU/512M/10G.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#terminal #security
526👍293👎2
Вчера одной знакомой мошенники взломали учётную запись от Госуслуг. Причём сделали это таким запутанным способом, что я даже не уверен, что ломали именно их. Расскажу обо всём по порядку. Возможно кто-то с подобным сталкивался. Другим наука будет, чтобы предупредили знакомых и родственников.
1️⃣ 9 утра, человек едет в метро. Раздаётся звонок на телефон. Слышно плохо. Мошенники называют ФИО и адрес проживания. Говорят, что пришла посылка на почту рядом с домом. Чтобы забрать, надо привязать в почте свой номер телефона, на который придёт код подтверждения для забора посылки.
2️⃣ Приходит смс от Госуслуг. Тут первая странность. В смс текст: Для подтверждения смены номера введите код подтверждения: 1234. Не сообщайте никому! Странности тут две. Во-первых, коды подтверждения у Госуслуг 6-ти значные, а тут только 4 знака. Во-вторых, сейчас от Госуслуг приходит другой текст. В конце добавляют, что этот код спрашивают только мошенники. И при этом смс пришла от отправителя gosuslugi и легла в тот же чат, где все остальные смс от реального сервиса.
3️⃣ Человек называет код и тут же понимает, что это какая-то ерунда и обман. Она кладёт трубку, заходит через приложение Госуслуг на смартфоне и меняет пароль. Приходит смс для аутентификации и там 6 знаков и привычный текст.
4️⃣ Человек заходит в свою почту и там видит несколько подозрительных писем:
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.
5️⃣ Человек звонит по этому номеру. Там сразу снимают трубку, как-будто ждали звонка. Мужчина без всякого акцента рассказал, что кто-то заходил в учётку, если это не вы, то надо срочно менять пароль и привязку телефона. А потом отложил трубку и судя по всему забыл отключить микрофон. Начал разговаривать матерясь с какой-то девушкой рядом, а та ему говорила, что надо что-то ещё, чтобы она сделала или ничего не получится.
6️⃣ Знакомая поняла, что это опять мошенники, положила трубку. Зашла с компьютера в Госуслуги, снова сменила пароль, убедилась, что привязан её мобильный номер. Для аутентификации все смски с кодами приходили к ней на смартфон.
Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.
Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.
И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.
Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.
#security
▪️Первое от реальных Госуслуг, где указано, что её номер введён в другой учётной записи.
▪️Второе фейковое от хостинга Aeza, отправленное с домена aeza_email, где указано, что для подтверждения почты нужно пройти по ссылке и активировать учётку. Тут я уже удивился, так как сначала вообще не понял, при чём тут Aeza. В письме странные ссылки через сокращатели. Не ходил по ним. Письмо точно фейк, потому что у меня есть письма от реальной Аезы. Они по-другому отправляют.
▪️Третье письмо подделано под шаблон Госуслуг. Там сказано, что кто-то совершил вход под вашей учётной записью. Указан IP адрес и расположение: Украина - г. Киев. И ниже указан номер тех. поддержки, куда предлагают позвонить, если это были не вы. Забегая вперёд скажу, что номер мошенников. Письмо отправлено с домена в зоне .org, похожего на госуслуги.
Всё просмотрела в личном кабинете, вроде никаких изменений. В списке действий ровно одно подозрительное действие как раз после первого звонка, совершённое не с её IP адреса. При этом IP адрес московский. Выполнено действие - отключение входа с подтверждением. Что это значит, не очень понятно, так как подтверждение по телефону реально не отключили.
Вот такая странная история произошла. Ниже список писем в тот день и скрины фейкового письма с госуслуг и от Aeza. Вот последняя меня больше всего интересует. При чём тут вообще этот хостинг? Знакомая с ним никак не связана и вообще не знает, что это такое.
И второй момент. От чего в итоге был передан мошенникам код из 4-х знаков? У меня есть подозрение, что Госуслуги тут только прикрытие каких-то других дел. Я не знаю, можно ли подделать отправителя смс, чтобы его сообщение попало в папку или чат с реальными смс от Госуслуг. А может на смену номера там только 4 символа и остался старый шаблон. Но смена по какой-то причине не состоялась.
Кто-нибудь сталкивался с подобным? Что это может быть? Какая-то многоходовая махинация. Тут и посылка, и фейковые письма, и поддержка.
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍136👎4
Продолжаю пересматривать старые заметки. Нашёл показательную новость от 2020 года, которую скорее всего все уже позабыли.
⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3
Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.
И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.
К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.
Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.
На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.
#совет #security
⇨ Удалённая уязвимость в серверных платах Intel с BMC Emulex Pilot 3
Это когда в BMC-контроллере, который используют для управления серверной платформой, нашли эпические уязвимости, которые позволяли без аутентификации получить доступ к консоли удалённого управления KVM. Причём по словам выявившего уязвимость исследователя работать с BMC через эксплоит гораздо удобнее, чем при помощи штатного Java-клиента. Ну случайно так вышло, понимать надо ☝️.
И такие уязвимости регулярно всплывают. Помню, как в ядро Linux какие-то "шутники" протолкнули уязвимости, их приняли, а потом заметили. Оказалось, их туда в исследовательских целях добавляли, тоже понимать надо.
К чему я это написать решил. Не помню, акцентировал ли когда-нибудь конкретно на этом внимание. Я стараюсь сам и рекомендую остальным закрывать доступ извне ко всему, что не требует публичного доступа, файрволом. Закрываю даже SSH, хотя не всегда так делал. Последние года стабильно закрываю службу SSH списками IP адресов. Возможно и ICMP стоит закрывать, чтобы не отсвечивать лишний раз, но я оставляю для удобства мониторинга.
Есть расхожее мнение на тему того, что если регулярно и своевременно ставить обновления, то можно особо не бояться уязвимостей. К сожалению, это не так. Уязвимости закрывают, когда они появляются в публичной плоскости. А сколько они эксплуатируются в теневом режиме - неизвестно. Я лично сталкивался с историей, когда сервер живёт своей жизнью - останавливает и запускает сервисы, а ты не можешь понять кто и как это делает. Из исследовательских целей оставлял сервер и долго с ним ковырялся, но не мог понять, что там происходит. Пришлось переустанавливать. Подозреваю, что через какую-то непубличную уязвимость ломали, да и всё.
На днях ещё одну новость видел: У криптовалютной биржи Bybit похитили 1,46 млрд долларов. Во времена хайпа крипты я плотно работал с компанией, которая писала криптовалютные биржи и приложения. Я реально опасался за безопасность, хотя старался делать всё, что от меня зависело, для безопасности, но всякое бывает. Потом больше всего вопросов к администратору будет, если случится инцидент. Больше не занимаюсь этим и не хочу. Технически работа была интересная, но с точки зрения безопасности постоянно чувствовал некоторую тревогу. Там сервисы публичные были, всё не закрыть.
#совет #security
👍87👎2
У меня в канале в разное время выходили разборы рекомендаций по безопасности от проекта CIS — Center for Internet Security. Кто не видел их, рекомендую. Я почерпнул оттуда некоторые настройки для своих установок. Сами документы объёмные. Постарался взять из них самую суть, которая пригодится в среднестатистическом применении:
▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16
Софт с тех пор уже обновился, вышли новые рекомендации на основе старых, но я не прорабатывал обновления. Базовые настройки чаще всего остаются те же самые с минимальными изменениями.
Отдельно отмечу проект Docker Bench for Security, который автоматически проверяет образы Docker на соответствие рекомендациям CIS.
Сегодня хочу развить эту тему и познакомить вас с проектом CIS Debian 10/11/12 Hardening от известного международного хостера OVH, который когда-то сильно горел. Этот проект состоит из bash скриптов для проверки вашей системы на базе Debian на соответствие рекомендациям по безопасности.
Проект сделан для автоматизации и гибкой, выборочной проверки. Тесты настраиваются, есть возможность исключать какие-то проверки. Можно проводить только аудит, а можно сразу применять изменения для приведения системы в заданные соответствия.
Покажу кратко, как пользоваться этими скриптами. Клонируем репозиторий:
Создаём файл
Теперь можно запускать как по отдельности проверки, так и все разом. Проверки находятся в директории
Я проверку провалил. У меня
Для того, чтобы запустить все тесты разом, можно использовать отдельный скрипт в папке
Будут выполнены все проверки, результат вывалится в консоль. Это неудобно, так как он может быть огромным. Лучше сразу направить вывод в текстовый файл:
Потом файл можно спокойно посмотреть, осмыслить. Смотреть удобно в less с подсветкой:
В конце увидите итоговый результат:
Его можно получить в json:
Для каждой проверки есть свой конфиг в
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#cis #security
▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16
Софт с тех пор уже обновился, вышли новые рекомендации на основе старых, но я не прорабатывал обновления. Базовые настройки чаще всего остаются те же самые с минимальными изменениями.
Отдельно отмечу проект Docker Bench for Security, который автоматически проверяет образы Docker на соответствие рекомендациям CIS.
Сегодня хочу развить эту тему и познакомить вас с проектом CIS Debian 10/11/12 Hardening от известного международного хостера OVH, который когда-то сильно горел. Этот проект состоит из bash скриптов для проверки вашей системы на базе Debian на соответствие рекомендациям по безопасности.
Проект сделан для автоматизации и гибкой, выборочной проверки. Тесты настраиваются, есть возможность исключать какие-то проверки. Можно проводить только аудит, а можно сразу применять изменения для приведения системы в заданные соответствия.
Покажу кратко, как пользоваться этими скриптами. Клонируем репозиторий:
# git clone https://github.com/ovh/debian-cis.git && cd debian-cisСоздаём файл
/etc/default/cis-hardening и добавляем туда информацию о директории, из которой мы будем запускать скрипты:# cp debian/default /etc/default/cis-hardening# sed -i "s#CIS_LIB_DIR=.*#CIS_LIB_DIR='$(pwd)'/lib#" /etc/default/cis-hardening# sed -i "s#CIS_CHECKS_DIR=.*#CIS_CHECKS_DIR='$(pwd)'/bin/hardening#" /etc/default/cis-hardening# sed -i "s#CIS_CONF_DIR=.*#CIS_CONF_DIR='$(pwd)'/etc#" /etc/default/cis-hardening# sed -i "s#CIS_TMP_DIR=.*#CIS_TMP_DIR='$(pwd)'/tmp#" /etc/default/cis-hardeningТеперь можно запускать как по отдельности проверки, так и все разом. Проверки находятся в директории
bin/hardening. На каждый тест – отдельный bash скрипт с осмысленным названием. Например, 1.1.11_var_log_partition.sh. Запускаем:# ./1.1.11_var_log_partition.sh1.1.11_var_log_partition [INFO] Working on 1.1.11_var_log_partition1.1.11_var_log_partition [INFO] [DESCRIPTION] /var/log on separate partition.1.1.11_var_log_partition [INFO] Checking Configuration1.1.11_var_log_partition [INFO] Performing audit1.1.11_var_log_partition [INFO] Verifying that /var/log is a partition1.1.11_var_log_partition [ KO ] /var/log is not a partition1.1.11_var_log_partition [ KO ] Check FailedЯ проверку провалил. У меня
/var/log находится на корневом разделе. С точки зрения безопасности и стабильности работы системы это не очень хорошо. Во-первых, логи могут заполнить весь корневой раздел. Во-вторых, отдельный раздел под логи можно смонтировать для большей безопасности с некоторыми дополнительными настройками, типа noexec, nosuid, noatime и т.д. Я всё это понимаю, но мне чаще всего удобнее с одним общим разделом для всего.Для того, чтобы запустить все тесты разом, можно использовать отдельный скрипт в папке
bin:# ./hardening.sh --auditБудут выполнены все проверки, результат вывалится в консоль. Это неудобно, так как он может быть огромным. Лучше сразу направить вывод в текстовый файл:
# ./hardening.sh --audit > ~/cis.txtПотом файл можно спокойно посмотреть, осмыслить. Смотреть удобно в less с подсветкой:
# less -R ~/cis.txtВ конце увидите итоговый результат:
Total Passed Checks : [ 102/243 ]Total Failed Checks : [ 141/243 ]Enabled Checks Percentage : 100.00 %Conformity Percentage : 41.97 %Его можно получить в json:
# ./hardening.sh --audit --summary-jsonДля каждой проверки есть свой конфиг в
etc/conf.d, где её можно настроить или отключить. По проверкам можно делать либо аудит, либо вносить изменения в систему.❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#cis #security
2👍132👎2
На прошлой неделе делал подборку инструментов для логирования действий пользователя в консоли. В комментариях справедливо заметили, что всё это умеет делать практически штатный инструмент - auditd. Его всегда рекомендуют включать и настраивать в контексте вопросов безопасности. Например, в руководствах CIS (#cis) о нём всегда упоминают.
Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.
Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.
Устанавливаем auditd:
Создаём правило, добавив в файл
По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.
Применяем правила:
Теперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:
Вывалится большая портянка. Каждая команда в своём блоке, где будет указано:
◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.
Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.
Может помочь команда, которая выведет список всех выполненных исполняемых файлов:
Также неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.
По умолчанию auditd хранит логи в
Либо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле
Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#auditd #ssh #security
Auditd я знаю, иногда настраиваю. Я о нём писал, как об инструменте для контроля за изменениями файлов. С его помощью это сделать относительно просто. Но честно скажу, не очень его люблю. Настройка неинтуитивна, логи перенасыщены информацией, чтобы просто посмотреть лог и что-то там найти, надо вспоминать команды или грепать текстовый лог.
Тем не менее, auditd это линуксовая база, так что знать его полезно. Настроим в нём логирование пользовательских команд. Auditd будет записывать не только запущенную команду, но и реально выполненную, а так же сопутствующую информацию: рабочая директория, файлы, связанные с выполнением, системный вызов, pid, uid, gid, tty и другие вещи.
Устанавливаем auditd:
# apt install auditdСоздаём правило, добавив в файл
/etc/audit/rules.d/audit.rules несколько новых строк:-a always,exit -F arch=b64 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b32 -F euid=0 -F auid=0 -S execve -S execveat -k root_auth_command_execution
-a always,exit -F arch=b64 -F auid!=-1 -S execve -S execveat -k generic_command_execution
-a always,exit -F arch=b32 -F auid!=-1 -S execve -S execveat -k generic_command_execution
По совету читателя добавил два правила: для пользователя root и для всех остальных. Правила идентичные, пользователя root идентифицировали через euid=0 и auid=0. Нулевые значения соответствуют root.
Применяем правила:
# auditctl -R /etc/audit/rules.d/audit.rulesТеперь все команды пользователей записываются в соответствием с правилами. Смотрим команды root:
# ausearch -k root_auth_command_executionВывалится большая портянка. Каждая команда в своём блоке, где будет указано:
◽️Дата и время выполнения
◽️PROCTITLE - выполненная команда
◽️PATH - файлы, связанные с выполнением (какие-нибудь библиотеки, сам исполняемый файл и т.д.)
◽️CWD - рабочая директория
◽️EXECVE - аргументы команды, если есть.
◽️SYSCALL - выполненный системный вызов со всеми свойствами в виде пользователя, pid, самой команды, исполняемого файла и т.д.
Как можно увидеть, информация исчерпывающая. Вроде и хорошо, что так подробно. С точки зрения безопасности полезная информация. Но быстро глянуть, кто тут что запускал, не получится. Например, если пользователь просто запустил mc, то в лог улетит не только эта команда, но и сопутствующие. Mc открывает свой bash и это тоже будет отражено в логе, также он запускает бинарники cons.saver, dircolors. Избыток подробной информации может сбивать с толку и усложнять аудит. С точки зрения безопасности это полезная информация, а с точки зрения посмотреть, кто тут что делал, не очень.
Может помочь команда, которая выведет список всех выполненных исполняемых файлов:
# aureport -x -iТакже неудобно смотреть команды, запущенные через pipe. В auditd они будут отображены по отдельности.
По умолчанию auditd хранит логи в
/var/log/audit/audit.log. Читать их или грепать напрямую неудобно. Там всё сплошным потоком, без дат. Можно через ausearch или aureport выгружать их в файлы:# aureport -x -i > /var/log/audit_exec_summary.logЛибо настроить пересылку логов в syslog. Для локального syslog сервера есть плагин с настройками в файле
/etc/audit/plugins.d/syslog.conf. С локального можно на внешний пересылать.Auditd – мощный инструмент для мониторинга событий операционной системы. Он взаимодействует напрямую с ядром, наблюдает за системными вызовами. Всё, что с ними связано, может записывать. Можно создавать отдельные правила для конкретных приложений и наблюдать за ними.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#auditd #ssh #security
4👍126👎2
В комментариях к статье с настройкой OpenVPN читатель задал странный вопрос. Он обратил внимание, что в логах подключения клиента к серверу фигурирует пароль от закрытого ключа CA:
Я сначала призадумался, прикинул, что такого не может быть. Сколько использую OpenVPN, никогда такого не видел. Следующим комментарием автор сам же и ответил на свой вопрос. Он по ошибке загнал пароль от CA в CN сертификата сервера, когда его создавал. А там должно быть имя сервера, CN = Common Name. Пароль надо вводить уже в самом конце, когда подписываешь сертификат.
Интересная ситуация, поэтому решил сделать по мотивам заметку. Такие ошибки на самом деле не редкость. Расскажу, на мой взгляд, одну из самых популярных ситуаций, когда невольно раскрывается важный пароль. Я и сам на такое натыкался, и от других видел не раз.
Когда торопишься и логинишься по SSH к серверу, особенно если не к своему и первый раз это делаешь, учётные данные ещё не сохранены, то можно в окно приветствия вместо логина сразу же вставить из буфера пароль. Тут же становится понятно, что ты ошибся, и со второй попытки ты всё делаешь правильно.
Но при этом твой введённый пароль вместо логина улетает в открытом виде в лог
Ещё часто пароли светятся вот в таких конструкциях:
Если вводите что-то подобное в консоль, то не указывайте пароль явно. Оставьте только ключ
Палили так свои пароли? Я и по ssh, и в консоли палил. Благо это было не особо критично, так как чаще всего работаю со своими серверами я один, и чтобы всё это прочитать потом, надо быть рутом. А root это я и есть. Но о таких вещах стоит всегда помнить и следить за собой.
#security
Mon Jun 16 16:25:21 2025 VERIFY OK: depth=0, CN=пароль_на_ca.keyЯ сначала призадумался, прикинул, что такого не может быть. Сколько использую OpenVPN, никогда такого не видел. Следующим комментарием автор сам же и ответил на свой вопрос. Он по ошибке загнал пароль от CA в CN сертификата сервера, когда его создавал. А там должно быть имя сервера, CN = Common Name. Пароль надо вводить уже в самом конце, когда подписываешь сертификат.
Интересная ситуация, поэтому решил сделать по мотивам заметку. Такие ошибки на самом деле не редкость. Расскажу, на мой взгляд, одну из самых популярных ситуаций, когда невольно раскрывается важный пароль. Я и сам на такое натыкался, и от других видел не раз.
Когда торопишься и логинишься по SSH к серверу, особенно если не к своему и первый раз это делаешь, учётные данные ещё не сохранены, то можно в окно приветствия вместо логина сразу же вставить из буфера пароль. Тут же становится понятно, что ты ошибся, и со второй попытки ты всё делаешь правильно.
Но при этом твой введённый пароль вместо логина улетает в открытом виде в лог
auth.log или какой-то другой и остаётся там. А если настроено какое-то хранилище логов, то он улетает дальше туда. Если так ошиблись, то сразу же зайдите в логи и подчистите за собой. А если это невозможно, то меняйте пароль, если есть вероятность, что логи может посмотреть кто-то, кому этот пароль знать не положено. Ещё часто пароли светятся вот в таких конструкциях:
# mysqldump --opt -v --no-create-db db01 -u'root' -p'pass01' > ~/db01.sql'Если вводите что-то подобное в консоль, то не указывайте пароль явно. Оставьте только ключ
-p, тогда пароль у вас спросят интерактивно и он не попадёт в history. Ну а если попал, то удалите его после себя. Либо при запуске команды поставьте перед ней пробел. Но это не обязательно спасёт от сохранения команды. Данная возможность может быть отключена.Палили так свои пароли? Я и по ssh, и в консоли палил. Благо это было не особо критично, так как чаще всего работаю со своими серверами я один, и чтобы всё это прочитать потом, надо быть рутом. А root это я и есть. Но о таких вещах стоит всегда помнить и следить за собой.
#security
👍172👎3
На днях читал новость про взлом крупного почтового сервиса через уязвимость в Roundcube Webmail. Это один из самых, если не самый популярный open source проект для веб интерфейса почтового клиента. Я повсеместно и очень давно его использую и уже привык, что там периодически находят уязвимости. Подписан на их рассылку и сразу иду ставить обновление, если оно появилось. Не откладываю.
С публичным веб интерфейсом постоянно сидишь как на пороховой бочке. Я рекомендую, если есть возможность, скрывать веб интерфейс почты за VPN. Не оставлять его напрямую в интернет. Не всегда это возможно.
Если вам всё же нужно оставить его в публичном доступе, то не ставьте веб интерфейс напрямую на почтовом сервере, хотя часто хочется это сделать. Если сервер не очень большой, то веб интерфейс особо не нагружает систему и удобно иметь всё, что связано с почтой, на одном сервере.
Ставьте веб интерфейс на отдельный веб сервер. Не оставляйте к нему прямого доступа. Если у вас более-менее насыщенная инфраструктура с веб сервисами, то наверняка используется какой-то обратный прокси. Делайте доступ к веб интерфейсу через него. В таком случае при взломе любого веб клиента, не обязательно Roundcube, уязвимости находят везде, просто этот самый популярный, доступ получат только к данным этого клиента.
А там не так уже много конфиденциальной информации. Самое ценное – список всех актуальных почтовых адресов ваших доменов. Неприятно, но некритично. Можно пережить. Если с этого сервера дальше никуда нет доступа и там больше ничего нет, то вы особо не пострадаете. Доступ к почте, как правило, при таком взломе не получить, если на самом почтовом сервере нет уязвимостей, с помощью которых можно без аутентификации получить доступ к почте. Сами пароли от ящиков в веб клиентах обычно не хранятся.
#mailserver #security
С публичным веб интерфейсом постоянно сидишь как на пороховой бочке. Я рекомендую, если есть возможность, скрывать веб интерфейс почты за VPN. Не оставлять его напрямую в интернет. Не всегда это возможно.
Если вам всё же нужно оставить его в публичном доступе, то не ставьте веб интерфейс напрямую на почтовом сервере, хотя часто хочется это сделать. Если сервер не очень большой, то веб интерфейс особо не нагружает систему и удобно иметь всё, что связано с почтой, на одном сервере.
Ставьте веб интерфейс на отдельный веб сервер. Не оставляйте к нему прямого доступа. Если у вас более-менее насыщенная инфраструктура с веб сервисами, то наверняка используется какой-то обратный прокси. Делайте доступ к веб интерфейсу через него. В таком случае при взломе любого веб клиента, не обязательно Roundcube, уязвимости находят везде, просто этот самый популярный, доступ получат только к данным этого клиента.
А там не так уже много конфиденциальной информации. Самое ценное – список всех актуальных почтовых адресов ваших доменов. Неприятно, но некритично. Можно пережить. Если с этого сервера дальше никуда нет доступа и там больше ничего нет, то вы особо не пострадаете. Доступ к почте, как правило, при таком взломе не получить, если на самом почтовом сервере нет уязвимостей, с помощью которых можно без аутентификации получить доступ к почте. Сами пароли от ящиков в веб клиентах обычно не хранятся.
#mailserver #security
XAKEP
Cock[.]li взломали. Похищены данные миллиона пользователей
Почтовый хостинг-провайдер Cock[.]li сообщил, что пострадал от утечки данных. Хакеры воспользовались уязвимостями в Roundcube Webmail и похитили более миллиона пользовательских записей.
👍80👎3
Я уже когда-то давно упоминал про любопытный сайт, где простыми словами описываются различные уязвимости веб приложений:
⇨ Hacksplaining ⇨ Lesson Library
На текущий момент сайт доступен только через VPN. Не знаю, кто и за что блокирует, но не суть. Там есть раздел, где наглядно описаны и на примерах показаны уязвимости и как их эксплуатируют. К некоторым реализованы интерактивные действия, где вы сами поучаствуете во взломе. Сделано необычно и интересно, всё описано простыми словами.
Даётся минимум теории по выполненным шагам. Но в целом всё понятно. Как говорится, вместо тысячи слов. Проще один раз сделать самому и всё понять. Посмотрите на описание SQL Injection, и сразу поймёте о чём я говорю. Также рекомендую как минимум посмотреть наиболее популярные уязвимости:
▪️Cross-Site Scripting
▪️Command Execution
▪️Directory Traversal
▪️File Upload Vulnerabilities
Из последних нововведений - описание нескольких примеров уязвимостей искусственного интеллекта, доступного публично. Из него, оказывается, можно вытянуть информацию, которая не должна быть доступна широкому кругу лиц. Я об этих вещах раньше не слышал и даже не задумывался. Например, из модели можно вытянуть реальные данные, на которых она обучалась, или заставить её выполнить код из загруженного документа. Это при условии, что её заранее не защитили от этих вещей.
Ресурс будет в первую очередь интересен разработчикам, так как там наглядно показано, как не надо писать код или настраивать ИИ. Админам и девопсам будет просто полезно посмотреть, как обычно ломают веб ресурсы, ИИ, и за какие промахи можно бить по рукам разработчиков. Да и просто интересно ознакомиться для общего образования. Платить не надо, всё бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#security #обучение
⇨ Hacksplaining ⇨ Lesson Library
На текущий момент сайт доступен только через VPN. Не знаю, кто и за что блокирует, но не суть. Там есть раздел, где наглядно описаны и на примерах показаны уязвимости и как их эксплуатируют. К некоторым реализованы интерактивные действия, где вы сами поучаствуете во взломе. Сделано необычно и интересно, всё описано простыми словами.
Даётся минимум теории по выполненным шагам. Но в целом всё понятно. Как говорится, вместо тысячи слов. Проще один раз сделать самому и всё понять. Посмотрите на описание SQL Injection, и сразу поймёте о чём я говорю. Также рекомендую как минимум посмотреть наиболее популярные уязвимости:
▪️Cross-Site Scripting
▪️Command Execution
▪️Directory Traversal
▪️File Upload Vulnerabilities
Из последних нововведений - описание нескольких примеров уязвимостей искусственного интеллекта, доступного публично. Из него, оказывается, можно вытянуть информацию, которая не должна быть доступна широкому кругу лиц. Я об этих вещах раньше не слышал и даже не задумывался. Например, из модели можно вытянуть реальные данные, на которых она обучалась, или заставить её выполнить код из загруженного документа. Это при условии, что её заранее не защитили от этих вещей.
Ресурс будет в первую очередь интересен разработчикам, так как там наглядно показано, как не надо писать код или настраивать ИИ. Админам и девопсам будет просто полезно посмотреть, как обычно ломают веб ресурсы, ИИ, и за какие промахи можно бить по рукам разработчиков. Да и просто интересно ознакомиться для общего образования. Платить не надо, всё бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#security #обучение
👍141👎2
Недавно из комментариев узнал про систему RuSIEM. Она относится к классу продуктов SIEM (Security Information and Event Management). Я в целом далёк от темы безопасности и связанным с этим софтом, так как это отдельное направление в IT. Эта система привлекла меня тем, что у неё есть полностью бесплатная версия RvSIEM, которая занимается только сбором и обработкой логов, анализируя их на наличие содержимого, связанного с защитой и безопасностью.
Решение полностью российское, соответственно документация, весь интерфейс, все встроенные фильтры и отчёты полностью на русском, что упрощает эксплуатацию. Я немного разобрался с RvSIEM: развернул, посмотрел, что умеет и как работает. На первый взгляд неплохая система. Кратко расскажу, что конкретно она делает.
RvSIEM умеет принимать логи из различных систем: веб сервера, операционные системы (в том числе Windows), СУБД, почтовые сервера, шлюзы, сетевые устройства и т.д. Она их автоматически парсит, если используются стандартные шаблоны логов этих приложений и собирает по ним аналитику. Например, вычленяет из них IP адреса источников, информацию об учётных данных, если речь идёт о логине, статусы и критичности событий из логов приложений и т.д.
Всё это стекается в общее хранилище на базе Elasticsearch и ClickHouse, там анализируется и строятся отчёты. Например, можно вывести сквозной список всех IP адресов, с которых были подключения, которые не относятся к IP адресам РФ. Можно сделать отдельный отчёт по логинам RDP или в админку самой RvSIEM. Причём отчёты можно выгружать в различных форматах: PDF, DOCX, XSLX, CSV.
Есть стандартные преднастроенные фильтры и отчёты. Можно писать свои. То же самое и к парсерам относится. Используются grok фильтры для парсинга, как в Logstash. С ними нетрудно разобраться и распарсить свой формат логов. Я в своё время это освоил, когда надо было. Управление всё через веб интерфейс, в консоль ходить не обязательно.
Рассказываю, как я всё это установил. Пошёл на сайт и в разделе скачать оставил заявку. На следующий день мне прислали на почту мою учётную запись в ЛК с документацией всей системы RuSIEM. Там есть все ссылки и инструкции на загрузку. Используется общий установщик, а конкретно установку RvSIEM выбираешь при его запуске.
С установкой проблем не возникло, там всё просто. Инструкция на русском, сделал по ней. Хотя по сути там нужно просто скачать скрипт и запустить его. Дальше установщик всё делает сам. Он работает на базе ролей Ansible. Никаких лицензий потом получать не надо.
Дам одну существенную рекомендацию по настройкам Elasticsearch. Он по умолчанию съедает всю оперативную память и его прибивает OOM Killer. У меня было 4GB памяти, сделал 8GB, не помогло, сделал 12GB - тоже не помогло. Elasticsearch регулярно падал, хотя в тестовой системе нагрузки никакой не было. Мне это надоело и я в файл
Они ограничивают потребление в 4GB, что для небольшой нагрузки достаточно. После этого система стала стабильно работать.
RvSIEM умеет собирать логи разными способами. В основном это syslog, NetFlow и свой агент, в том числе для Windows. То есть настройка простая. Например, в Angie можно напрямую отправить логи в RvSIEM в формате syslog:
Основное ограничение бесплатной версии - 500 EPS (events per second). Не знаю, что тут конкретно имеется ввиду. Наверное, суммарное количество строк логов в секунду.
Для бесплатной системы функциональность более чем. Не знаю, есть ли у кого-то что-то лучше. Да и в целом мне понравилась система. Довольно быстро разобрался, развернул, посмотрел, как работает. Особых проблем не возникло. Попробуйте, если вам нужен такого рода продукт.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #security #отечественное
Решение полностью российское, соответственно документация, весь интерфейс, все встроенные фильтры и отчёты полностью на русском, что упрощает эксплуатацию. Я немного разобрался с RvSIEM: развернул, посмотрел, что умеет и как работает. На первый взгляд неплохая система. Кратко расскажу, что конкретно она делает.
RvSIEM умеет принимать логи из различных систем: веб сервера, операционные системы (в том числе Windows), СУБД, почтовые сервера, шлюзы, сетевые устройства и т.д. Она их автоматически парсит, если используются стандартные шаблоны логов этих приложений и собирает по ним аналитику. Например, вычленяет из них IP адреса источников, информацию об учётных данных, если речь идёт о логине, статусы и критичности событий из логов приложений и т.д.
Всё это стекается в общее хранилище на базе Elasticsearch и ClickHouse, там анализируется и строятся отчёты. Например, можно вывести сквозной список всех IP адресов, с которых были подключения, которые не относятся к IP адресам РФ. Можно сделать отдельный отчёт по логинам RDP или в админку самой RvSIEM. Причём отчёты можно выгружать в различных форматах: PDF, DOCX, XSLX, CSV.
Есть стандартные преднастроенные фильтры и отчёты. Можно писать свои. То же самое и к парсерам относится. Используются grok фильтры для парсинга, как в Logstash. С ними нетрудно разобраться и распарсить свой формат логов. Я в своё время это освоил, когда надо было. Управление всё через веб интерфейс, в консоль ходить не обязательно.
Рассказываю, как я всё это установил. Пошёл на сайт и в разделе скачать оставил заявку. На следующий день мне прислали на почту мою учётную запись в ЛК с документацией всей системы RuSIEM. Там есть все ссылки и инструкции на загрузку. Используется общий установщик, а конкретно установку RvSIEM выбираешь при его запуске.
С установкой проблем не возникло, там всё просто. Инструкция на русском, сделал по ней. Хотя по сути там нужно просто скачать скрипт и запустить его. Дальше установщик всё делает сам. Он работает на базе ролей Ansible. Никаких лицензий потом получать не надо.
Дам одну существенную рекомендацию по настройкам Elasticsearch. Он по умолчанию съедает всю оперативную память и его прибивает OOM Killer. У меня было 4GB памяти, сделал 8GB, не помогло, сделал 12GB - тоже не помогло. Elasticsearch регулярно падал, хотя в тестовой системе нагрузки никакой не было. Мне это надоело и я в файл
/etc/elasticsearch/jvm.options.d/rusiem.jvm.options добавил настройки:-Xms4g-Xmx4gОни ограничивают потребление в 4GB, что для небольшой нагрузки достаточно. После этого система стала стабильно работать.
RvSIEM умеет собирать логи разными способами. В основном это syslog, NetFlow и свой агент, в том числе для Windows. То есть настройка простая. Например, в Angie можно напрямую отправить логи в RvSIEM в формате syslog:
access_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=infoerror_log syslog:server=10.20.1.9:5014,facility=local7,tag=angie,severity=infoОсновное ограничение бесплатной версии - 500 EPS (events per second). Не знаю, что тут конкретно имеется ввиду. Наверное, суммарное количество строк логов в секунду.
Для бесплатной системы функциональность более чем. Не знаю, есть ли у кого-то что-то лучше. Да и в целом мне понравилась система. Довольно быстро разобрался, развернул, посмотрел, как работает. Особых проблем не возникло. Попробуйте, если вам нужен такого рода продукт.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#logs #security #отечественное
2👍135👎10
Ранее я упоминал про утилиту Lynis, а также то, как я её использую в связке с Zabbix для предупреждения о каких-то проблемах на хостах. С момента написания статьи я немного поменял подход к сбору данных. Расскажу кратко, как это у меня сейчас работает. Я с тех пор постоянно использую эту связку. Мне нравится, как она работает.
Кратко поясню суть того, что делаю и для чего. Утилита Lynis есть в стандартных репах. Она делает некоторый набор проверок системы и пишет отчёт в лог. Конкретно меня от неё интересуют две вещи:
◽️Вывод предупреждений. Например, о том, что систему надо перезагрузить после обновления ядра, либо о том, что есть уязвимые пакеты.
◽️Список пакетов с уязвимостями, для которых доступны обновления.
С помощью Zabbix я анализирую лог Lynis и прямо на почту отправляю текст замечаний и уязвимых пакетов, если они есть. Реализую это следующим образом:
1️⃣ Делаю простой скрипт, который запускает Lynis и анализирует код завершения работы. У этой программы он ненулевой, если есть какие-то замечания. Завожу эти замечания в переменную и отправляю данные с помощью zabbix_sender на Zabbix Server. Если код выхода 0, то отправляю строку All is OK.
Сам скрипт очень простой:
Ставлю скрипт в cron или timers на выполнение раз в 2-3 часа. Чаще большого смысла нет.
2️⃣ В Zabbix Server делаю простой шаблон с одним элементом данных типа Zabbix траппер. Его настройки есть на скриншоте снизу. К айтему делаю два триггера. Один на поиск строки All is OK. Если в последнем полученном значении её нет, то срабатывает триггер. И второй - проверка, что данные приходят. Если в течении дня ничего не приходило, то он срабатывает. Настройки триггера тоже ниже.
3️⃣ В итоге если Lynis что-то находит, отправляет информацию в Zabbix Server. Срабатывает триггер, в описании которого будет текст из айтема со всеми замечаниями и списками уязвимых пакетов, которые надо обновить. Пример письма с информацией тоже есть ниже на картинке.
Всё это настраивается относительно просто. Не нужны никакие отдельные системы и сторонние пакеты. Всё ставится из базовых репозиториев, а система мониторинга скорее всего уже есть. Мне для базовых проверок такой информации достаточно.
Сам шаблон не прикрепляю, так как там всего один айтем и два триггера, содержимое которых и так есть на скринах. Воспроизвести нетрудно. Работать будет на любых версиях Zabbix сервера. Если не устанавливали на хосты zabbix_sender, то поставьте его. Он идёт в отдельном пакете:
Такая вот простая и функциональная система с предупреждениями об обновлениях и некоторых других вещах. Lynis делает много проверок, можно почитать о нём отдельно. В рамках этой заметки не стал на этом делать акцент.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #security
Кратко поясню суть того, что делаю и для чего. Утилита Lynis есть в стандартных репах. Она делает некоторый набор проверок системы и пишет отчёт в лог. Конкретно меня от неё интересуют две вещи:
◽️Вывод предупреждений. Например, о том, что систему надо перезагрузить после обновления ядра, либо о том, что есть уязвимые пакеты.
◽️Список пакетов с уязвимостями, для которых доступны обновления.
С помощью Zabbix я анализирую лог Lynis и прямо на почту отправляю текст замечаний и уязвимых пакетов, если они есть. Реализую это следующим образом:
Сам скрипт очень простой:
#!/bin/bash/usr/sbin/lynis audit system -qexitcode=$?result="0"if [ $exitcode != 0 ]; then result=$(/usr/bin/grep "Warning:\|Found vulnerable package" /var/log/lynis.log)else result="All is OK"fizabbix_sender -c /etc/zabbix/zabbix_agentd.conf -k "lynis.check" -o "$result"Ставлю скрипт в cron или timers на выполнение раз в 2-3 часа. Чаще большого смысла нет.
Всё это настраивается относительно просто. Не нужны никакие отдельные системы и сторонние пакеты. Всё ставится из базовых репозиториев, а система мониторинга скорее всего уже есть. Мне для базовых проверок такой информации достаточно.
Сам шаблон не прикрепляю, так как там всего один айтем и два триггера, содержимое которых и так есть на скринах. Воспроизвести нетрудно. Работать будет на любых версиях Zabbix сервера. Если не устанавливали на хосты zabbix_sender, то поставьте его. Он идёт в отдельном пакете:
# apt install zabbix-senderТакая вот простая и функциональная система с предупреждениями об обновлениях и некоторых других вещах. Lynis делает много проверок, можно почитать о нём отдельно. В рамках этой заметки не стал на этом делать акцент.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#zabbix #security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍126👎3
У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
Это пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
Можно просто в Docker запустить:
Если запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
# trufflehog git https://github.com/trufflesecurity/test_keysЭто пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
# curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/binМожно просто в Docker запустить:
# docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keysЕсли запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
# trufflehog filesystem --config=$PWD/generic.yml /var/logTrufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
1👍82👎3
Думаю, многие из вас знают или слышали о бесплатном продукте Suricata – это система обнаружения вторжений (IDS) и система предотвращения вторжений (IPS) с открытым исходным кодом. Её обычно используют в программных шлюзах и анализаторах трафика. Например, в IPFire, OPNsense, PfSense, Arkime и т.д.
На базе Suricata построен известный продукт SELKS, который является отличным дополнением к бесплатному же Wazuh - это SIEM система (Security Information and Event Management). Получается хорошая связка:
◽️SELKS мониторит сетевой трафик в режиме реального времени, выявляет угрозы на уровне сети и пытается их предотвратить.
◽️Wazuh ставит агенты на конечные системы, собирает данные об ОС, софте, уязвимостях, о событиях из логов, об изменениях с уровня файловой системы и т.д.
Вместе эта бесплатная парочка закрывают базовые потребности малого и среднего бизнеса. Хотя не уверен, что малому это в принципе нужно, но тем не менее. Это хорошая рабочая связка.
В январе этого года SELKS прекратил своё развитие в том виде, как он был. Его переименовали в Clear NDR – Community и немного пересобрали. Заменили Elastic Stack (Elasticsearch, Logstash, Kibana) на OpenSearch и Fluentd. Также изменили веб интерфейс с Kibana на тот, что есть в Enterprise-версии. Но при этом версия осталась бесплатной с той же функциональностью. Разработчики обещают более активное развитие, так как теперь у
Community и Enterprise версии общая кодовая база и одинаковый веб интерфейс.
Для Clear NDR - Community пока нет собранного ISO файла, как это было у SELKS. Его можно было развернуть с помощью установщика, как отдельную, новую систему. Clear NDR ставится поверх уже установленной с помощью утилиты stamusctl и работает на базе Docker.
Установка Clear NDR - Community:
У меня напрямую не скачался бинарник на сервере. Не знаю почему, не стал разбираться. Скачал через браузер даже без VPN и закинул на сервер вручную.
Выбираем сетевой интерфейс, на котором будем слушать трафик. Запускаем сервис:
Можно идти в веб интерфейс по HTTPS и настраивать систему. Учётка по умолчанию - selks-user / selks-user.
К сожалению, на Clear NDR нельзя напрямую подать NetFlow трафик для простого и удобного анализа, поэтому если сервер с ней не является шлюзом, то нужно будет каким-то образом реализовывать подачу нужного трафика на сетевой интерфейс сервера с Clear NDR. В зависимости от топологии сети, задача может решаться по-разному.
Для ручных проверок готовых дампов трафика в формате pcap, можно сделать вот так:
Система при запуске заберёт себе и проанализирует весь трафик из файла.
Проверить работу можно с помощью набора проверок отсюда: https://github.com/3CORESec/testmynids.org
Отдельно отмечу, что в составе Clear NDR есть полнофункциональный Arkime.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#security #gateway
На базе Suricata построен известный продукт SELKS, который является отличным дополнением к бесплатному же Wazuh - это SIEM система (Security Information and Event Management). Получается хорошая связка:
◽️SELKS мониторит сетевой трафик в режиме реального времени, выявляет угрозы на уровне сети и пытается их предотвратить.
◽️Wazuh ставит агенты на конечные системы, собирает данные об ОС, софте, уязвимостях, о событиях из логов, об изменениях с уровня файловой системы и т.д.
Вместе эта бесплатная парочка закрывают базовые потребности малого и среднего бизнеса. Хотя не уверен, что малому это в принципе нужно, но тем не менее. Это хорошая рабочая связка.
В январе этого года SELKS прекратил своё развитие в том виде, как он был. Его переименовали в Clear NDR – Community и немного пересобрали. Заменили Elastic Stack (Elasticsearch, Logstash, Kibana) на OpenSearch и Fluentd. Также изменили веб интерфейс с Kibana на тот, что есть в Enterprise-версии. Но при этом версия осталась бесплатной с той же функциональностью. Разработчики обещают более активное развитие, так как теперь у
Community и Enterprise версии общая кодовая база и одинаковый веб интерфейс.
Для Clear NDR - Community пока нет собранного ISO файла, как это было у SELKS. Его можно было развернуть с помощью установщика, как отдельную, новую систему. Clear NDR ставится поверх уже установленной с помощью утилиты stamusctl и работает на базе Docker.
Установка Clear NDR - Community:
# wget https://dl.clearndr.io/stamusctl-linux-amd64# chmod +x ./stamusctl-linux-amd64# mv ./stamusctl-linux-amd64 /usr/local/bin/stamusctlУ меня напрямую не скачался бинарник на сервере. Не знаю почему, не стал разбираться. Скачал через браузер даже без VPN и закинул на сервер вручную.
# mkdir /opt/ClearNDR && cd /opt/ClearNDR# stamusctl compose initВыбираем сетевой интерфейс, на котором будем слушать трафик. Запускаем сервис:
# stamusctl compose up -dМожно идти в веб интерфейс по HTTPS и настраивать систему. Учётка по умолчанию - selks-user / selks-user.
К сожалению, на Clear NDR нельзя напрямую подать NetFlow трафик для простого и удобного анализа, поэтому если сервер с ней не является шлюзом, то нужно будет каким-то образом реализовывать подачу нужного трафика на сетевой интерфейс сервера с Clear NDR. В зависимости от топологии сети, задача может решаться по-разному.
Для ручных проверок готовых дампов трафика в формате pcap, можно сделать вот так:
# stamusctl compose readpcap fulltraf.pcapСистема при запуске заберёт себе и проанализирует весь трафик из файла.
Проверить работу можно с помощью набора проверок отсюда: https://github.com/3CORESec/testmynids.org
Отдельно отмечу, что в составе Clear NDR есть полнофункциональный Arkime.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#security #gateway
👍112👎3
Недавно в одной из статей увидел рассказ про сканер уязвимостей Nuclei. Впервые о нём услышал. По описанию и возможностям он меня заинтересовал. Запомнил его. Позже была заметка про Suricata, SELKS, Wazuh и т.д. В контексте этой темы, думаю, будет уместно рассказать про Nuclei. Этот инструмент дополнит упомянутую связку.
Основные особенности Nuclei:
1️⃣ Высокая скорость работы.
2️⃣ Возможность относительно просто писать для него шаблоны в формате yaml.
Из-за этого этих шаблонов понаписали на все случаи жизни и уязвимости. Сам шаблон представляет из себя описание запроса, сопоставление ответа какому-то правилу и соответственно вывод на основе этого сопоставления. Например, софт какой-то версии является уязвимым. Делаем запрос к нему и спрашиваем версию. Если она соответствует той, что уязвима, значит у нас имеется уязвимый сервис.
Я не буду подробно описывать все возможности Nuclei. Если он вас заинтересовал, то вы без проблем всё найдёте. Там и анализ сайтов, API, интеграция в CI/CD и многое другое.
Просто покажу несколько практических примеров, как его можно быстро начать использовать. Программа представляет из себя одиночный бинарник. Установить можно так:
При первом запуске nuclei сама скачает все доступные шаблоны из своей базы. Решил сразу же по всем шаблонам проверить свой Микротик, который со стороны локалки полностью открыт:
Довольно быстро nuclei собрал всю информацию по устройству. Отчёт на картинке ниже. Ничего критичного не нашёл. Выдал много информации в формате info. Например, наличие routeros-api, открытого порта SSH и аутентификация по нему с помощью пароля.
Среди проблем нашёл одну уровня low - в SSH протоколе используется алгоритм, который признан недостаточно защищённым. Шаблон, который это определил, называется
Если вам не нужна некритичная информация, то все информационные результаты можно исключить, оставив только уровни low, medium, high, critical. Показываю на примере всего сегмента сети (вторая картинка):
Если будете сканировать сайты, веб сервера или любые другие сервисы, где есть ограничение на одновременное количество запросов, то используйте ключ
Придумал себе применение nuclei, которое скорее всего реализую. Потом напишу подробнее. У меня есть набор внешних IP адресов, которые я хочу регулярно проверять. Думаю, что раз в неделю достаточно. Сделаю это с помощью nuclei и nmap, так как хочется ещё полный отчёт по открытым портам. Выглядеть это будет примерно так:
Дальше эти отчёты либо объединяю, либо по отдельности отправляю на почту и Telegram с помощью notify. Там это удобно реализовано через отдельный ключ и загрузку текста сразу из файла:
Вывод nuclei можно сделать в формате json, отправить в Zabbix и там на события high и critical сделать триггер. Тоже подумаю над реализацией, если на практике отчёты nuclei окажутся полезными. Например, отчёты Lynis мне очень нравятся. Постоянно их в Zabbix завожу.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#security
Основные особенности Nuclei:
Из-за этого этих шаблонов понаписали на все случаи жизни и уязвимости. Сам шаблон представляет из себя описание запроса, сопоставление ответа какому-то правилу и соответственно вывод на основе этого сопоставления. Например, софт какой-то версии является уязвимым. Делаем запрос к нему и спрашиваем версию. Если она соответствует той, что уязвима, значит у нас имеется уязвимый сервис.
Я не буду подробно описывать все возможности Nuclei. Если он вас заинтересовал, то вы без проблем всё найдёте. Там и анализ сайтов, API, интеграция в CI/CD и многое другое.
Просто покажу несколько практических примеров, как его можно быстро начать использовать. Программа представляет из себя одиночный бинарник. Установить можно так:
# wget https://github.com/projectdiscovery/nuclei/releases/download/v3.4.10/nuclei_3.4.10_linux_amd64.zip# unzip nuclei_3.4.10_linux_amd64.zip# mv ./nuclei /usr/local/bin/nucleiПри первом запуске nuclei сама скачает все доступные шаблоны из своей базы. Решил сразу же по всем шаблонам проверить свой Микротик, который со стороны локалки полностью открыт:
# nuclei -u 192.168.137.1Довольно быстро nuclei собрал всю информацию по устройству. Отчёт на картинке ниже. Ничего критичного не нашёл. Выдал много информации в формате info. Например, наличие routeros-api, открытого порта SSH и аутентификация по нему с помощью пароля.
Среди проблем нашёл одну уровня low - в SSH протоколе используется алгоритм, который признан недостаточно защищённым. Шаблон, который это определил, называется
ssh-diffie-hellman-logjam. Я ничего нигде не искал, а просто зашёл в папочку с шаблонами и там прочитал описание. По умолчанию они скачиваются в ~/nuclei-templates. Конкретно этот шаблон в директории ~/nuclei-templates/javascript/enumeration/ssh.Если вам не нужна некритичная информация, то все информационные результаты можно исключить, оставив только уровни low, medium, high, critical. Показываю на примере всего сегмента сети (вторая картинка):
# nuclei -u 192.168.137.0/24 -s low,medium,high,criticalЕсли будете сканировать сайты, веб сервера или любые другие сервисы, где есть ограничение на одновременное количество запросов, то используйте ключ
-rl или -rate-limit. Я на своих серверах сразу же бан по IP получал из-за превышения этого лимита. Там десятки потоков одновременно открываются для максимально быстрой проверки.Придумал себе применение nuclei, которое скорее всего реализую. Потом напишу подробнее. У меня есть набор внешних IP адресов, которые я хочу регулярно проверять. Думаю, что раз в неделю достаточно. Сделаю это с помощью nuclei и nmap, так как хочется ещё полный отчёт по открытым портам. Выглядеть это будет примерно так:
# nuclei -l ip-list.txt -s low,medium,high,critical -o nuclei_report.txt# nmap -iL ip-list.txt -p- -T4 -oN nmap_report.txtДальше эти отчёты либо объединяю, либо по отдельности отправляю на почту и Telegram с помощью notify. Там это удобно реализовано через отдельный ключ и загрузку текста сразу из файла:
# notify -data nuclei_report.txt -provider-mail -provider-telegram# notify -data nmap_report.txt -provider-mailВывод nuclei можно сделать в формате json, отправить в Zabbix и там на события high и critical сделать триггер. Тоже подумаю над реализацией, если на практике отчёты nuclei окажутся полезными. Например, отчёты Lynis мне очень нравятся. Постоянно их в Zabbix завожу.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍118👎3
На днях на хабре прочитал полезную статью, поэтому решил акцентировать ваше внимание на ней. Я в принципе не знал, что так можно сделать. Не приходилось сталкиваться.
⇨ Защита от эксплойтов rdp, smb c помощью IPSec и сертификатов
Думаю у многих всё ещё трудятся устаревшие операционные системы Windows. По моим наблюдениям, чаще всего это Windows Server 2012 R2. Не помню уже чем они в то время так привлекали внимание, но мне кажется, их наустанавливали значительно больше, чем последующих 2016-х и 2019-х. Таковые имеются и у меня.
По понятным причинам, установить обновления на Windows Server 2012 R2 либо сложно, либо невозможно, потому что в свободный доступ они больше не публикуются. Есть обходные пути, но не сказать, что они простые.
Автор предлагает следующий простой и эффективный способ защиты удалённых подключений.
1️⃣ Разворачиваем роль центра сертификации.
2️⃣ Выпускаем сертификаты для пользователей.
3️⃣ На целевых серверах, куда пользователи будут подключаться по SMB или RDP, на штатном файрволе настраиваем правила входящих соединений, где включаем параметр Разрешить только безопасное подключение. Дополнительно можно ограничить список компьютеров, с которых разрешено подключаться. Если это не терминальный сервер, а обычный, куда по RDP подключаются только админы, можно ограничить список компьютеров.
4️⃣ Отдельно создаём правило для безопасных соединений, где включаем проверку подлинности компьютера, если настраивали ограничения по ним, и проверку подлинности пользователя, которая выполняется с помощью ранее выпущенного сертификата с нашего CA.
Теперь если у пользователя нет сертификата, в подключении будет отказано. Это не даёт стопроцентной защиты, но заметно сужает вектор атак, так как без сертификата по RDP или SMB уже не подключиться. А именно в этих сервисах обычно находят фатальные уязвимости.
Настраивается всё это относительно просто. В статье пошаговая инструкция. Странно, что у статьи так мало просмотров и совсем нет комментариев. Мне кажется, довольно актуальная информация. Меня постоянно беспокоят эти устаревшие системы. Конечно, их надо обновлять, но как это обычно бывает, не всегда это просто сделать по различным причинам. А где-то и невозможно. Я лично обслуживал системы для станков, которые нельзя было обновить. Продавалась связка станок-компьютер с драйверами под конкретную версию.
#windows #security
⇨ Защита от эксплойтов rdp, smb c помощью IPSec и сертификатов
Думаю у многих всё ещё трудятся устаревшие операционные системы Windows. По моим наблюдениям, чаще всего это Windows Server 2012 R2. Не помню уже чем они в то время так привлекали внимание, но мне кажется, их наустанавливали значительно больше, чем последующих 2016-х и 2019-х. Таковые имеются и у меня.
По понятным причинам, установить обновления на Windows Server 2012 R2 либо сложно, либо невозможно, потому что в свободный доступ они больше не публикуются. Есть обходные пути, но не сказать, что они простые.
Автор предлагает следующий простой и эффективный способ защиты удалённых подключений.
Теперь если у пользователя нет сертификата, в подключении будет отказано. Это не даёт стопроцентной защиты, но заметно сужает вектор атак, так как без сертификата по RDP или SMB уже не подключиться. А именно в этих сервисах обычно находят фатальные уязвимости.
Настраивается всё это относительно просто. В статье пошаговая инструкция. Странно, что у статьи так мало просмотров и совсем нет комментариев. Мне кажется, довольно актуальная информация. Меня постоянно беспокоят эти устаревшие системы. Конечно, их надо обновлять, но как это обычно бывает, не всегда это просто сделать по различным причинам. А где-то и невозможно. Я лично обслуживал системы для станков, которые нельзя было обновить. Продавалась связка станок-компьютер с драйверами под конкретную версию.
#windows #security
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Защита от эксплойтов rdp, smb c помощью IPSec и сертификатов
На многих предприятиях остаются всё ещё работать старые версии операционных систем windows, которые не обновляются, или просто не установлены обновления по непонятным причинам. Типичный ответ у...
👍123👎2
Ниже будет простая информация на тему шифрования данных. Вспомнил про это, когда меня один знакомый спросил, как ему зашифровать систему на арендованной VPS, чтобы хоть как-то защитить личные данные, которые там будут храниться.
Зашифровать всю систему на арендованной виртуалке, раскатанной по шаблону хостера - задача хлопотная и чаще всего не имеет большого смысла. Зачем шифровать всю систему? Обычно достаточно зашифровать только данные. А для этого можно создать виртуальный диск, зашифровать только его и примонтировать к системе. Всю приватную информацию хранить только там. Ему это просто в голову не пришло, так как до этого он сам создавал виртуалки и шифровал их целиком.
Причём подход этот работает примерно одинаково и в Linux, и в Windows. Эта функциональность уже есть в ядре. Покажу, как это примерно может выглядеть. Для начала Linux. Ставим набор утилит:
Создаём виртуальный диск:
Шифруем его:
Вам нужно будет подтвердить команду, написав YES заглавными буквами. Затем ввести парольную фразу. Открываем зашифрованный образ и присваиваем любое имя, например, crypt:
Появится диск
Всё, с шифрованным диском можно работать, как с обычным. После перезагрузки нужно будет вручную его открыть через luksOpen и смонтировать. Можно это автоматизировать через файл с секретом, но тогда и особого смысла в шифровании не будет.
В Windows всё примерно то же самое, только в качестве шифрования используется BitLocker. Выполнить создание диска проще всего через оснастку Управление компьютером. Открываем её и переходим в Управление дисками ⇨ Дополнительные действия ⇨ Создать виртуальный жёсткий диск.
Указываете все необходимые параметры и создаёте файл с виртуальным диском. Потом тут же в оснастке выполняете его инициализацию, создаёте простой том и назначаете имя диска.
После этого переходите в Этот (давно уже не Мой) Компьютер, выбираете подключенный виртуальный диск, жмёте правой кнопкой мыши и выбираете Включить BitLocker. Дальше указываете пароль, файл для парольной фразы и дожидаетесь окончания шифрования.
Такие вот простые способы хранить данные в зашифрованном виде. Не требуется делать каких-то потенциально опасных для системы действий. Устанавливать дополнительный софт. Шифруется только то, что действительно нужно шифровать. Выбираете эти данные сами.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#security
Зашифровать всю систему на арендованной виртуалке, раскатанной по шаблону хостера - задача хлопотная и чаще всего не имеет большого смысла. Зачем шифровать всю систему? Обычно достаточно зашифровать только данные. А для этого можно создать виртуальный диск, зашифровать только его и примонтировать к системе. Всю приватную информацию хранить только там. Ему это просто в голову не пришло, так как до этого он сам создавал виртуалки и шифровал их целиком.
Причём подход этот работает примерно одинаково и в Linux, и в Windows. Эта функциональность уже есть в ядре. Покажу, как это примерно может выглядеть. Для начала Linux. Ставим набор утилит:
# apt install cryptsetupСоздаём виртуальный диск:
# dd if=/dev/zero of=~/crypt.img bs=1M count=1024 status=progressШифруем его:
# cryptsetup -y -v luksFormat ~/crypt.imgВам нужно будет подтвердить команду, написав YES заглавными буквами. Затем ввести парольную фразу. Открываем зашифрованный образ и присваиваем любое имя, например, crypt:
# cryptsetup luksOpen ~/crypt.img cryptПоявится диск
/dev/mapper/crypt, с которым можно работать как обычно. Создаём файловую систему и монтируем:# mkfs.ext4 /dev/mapper/crypt# mkdir -p /mnt/crypt# mount /dev/mapper/crypt /mnt/cryptВсё, с шифрованным диском можно работать, как с обычным. После перезагрузки нужно будет вручную его открыть через luksOpen и смонтировать. Можно это автоматизировать через файл с секретом, но тогда и особого смысла в шифровании не будет.
В Windows всё примерно то же самое, только в качестве шифрования используется BitLocker. Выполнить создание диска проще всего через оснастку Управление компьютером. Открываем её и переходим в Управление дисками ⇨ Дополнительные действия ⇨ Создать виртуальный жёсткий диск.
Указываете все необходимые параметры и создаёте файл с виртуальным диском. Потом тут же в оснастке выполняете его инициализацию, создаёте простой том и назначаете имя диска.
После этого переходите в Этот (давно уже не Мой) Компьютер, выбираете подключенный виртуальный диск, жмёте правой кнопкой мыши и выбираете Включить BitLocker. Дальше указываете пароль, файл для парольной фразы и дожидаетесь окончания шифрования.
Такие вот простые способы хранить данные в зашифрованном виде. Не требуется делать каких-то потенциально опасных для системы действий. Устанавливать дополнительный софт. Шифруется только то, что действительно нужно шифровать. Выбираете эти данные сами.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍158👎2
Продолжая утреннюю тему, разберу ещё один спорный момент насчёт использования sudo на серверах. В своих статьях и заметках я sudo никогда не пишу, да и не использую. И нередко получаю на этот счёт замечания, что автор советует плохое, использует небезопасные практики и сидит на сервере под root. Якобы это не безопасно.
А я на самом деле сижу на сервере под root и не вижу в этом ничего зазорного. Сервер - не рабочая машина. Я туда не захожу просто так. Обычно я захожу на сервер для выполнения административных действий, для которых требуются права root. Без этих прав мне там и делать особо нечего.
Человек, который безапелляционно заявляет, что работать без sudo небезопасно, скорее всего до конца не понимает, что это за инструмент и для чего он нужен. Просто где-то прочитал об этом и бездумно повторяет.
Допустим, я единственный пользователь сервера, настроил его и администрирую единолично. Других людей там нет. Я не использую sudo. И какие это должно вызывать проблемы безопасности?
Другое дело, когда появляются разные пользователи. И здесь уже нужно sudo для аудита выполняемых действий и разграничения прав. Тем более, если работает большой отдел с единой системой хранения учётных записей и разграничения прав доступа. Хотя и это уже не панацея. Есть и другие модели многопользовательского доступа к серверам без использования sudo для логирования и разграничения прав.
Далее у нас появляются какие-то скрипты или другие инструменты, которые заходят удалённо на наш сервер для выполнения каких-то конкретных действий. Тут опять нужно sudo для того, чтобы их ограничить только теми действиями, которые им разрешены. Сюда же относятся и локальные службы с ограниченными правами, которые через sudo выполняют какие-то конкретно разрешённые действия с повышением прав. Например, это очень актуально для Zabbix Agent, который может что-то автоматически выполнять на сервере.
С помощью sudo удобно настраивать шаблоны систем для каких-то узких задач. Например, есть веб сервер, на который нужен почти полный доступ разработчиков, чтобы они могли смотреть логи Nginx, Php-fpm, перезапускать сервисы, менять их конфигурации и т.д. Но при этом за самой системой, её обновлением, закрытием уязвимостей следит другая служба, которая сама всё обновляет, перезагружает и следит за стабильной работой системы в целом. Через sudo разработчикам даётся доступ к нужным им службам, а всё остальное им недоступно, чтобы ненароком чего не сломали, не нарушили общие правила безопасности. В данном случае можно сказать, что дать полный доступ разработчикам к серверу без sudo небезопасно.
☝️К чему я всё это пишу? Специалист он на то и специалист, что разбирается в теме и в каждом конкретном случае думает, как ему сделать удобнее и безопаснее, а не просто повторяет заученные или случайно увиденные примеры. Подходы к настройке и управлению инфраструктурой на 3 сервера и на 100 будут разные. В одном случае от sudo никакого толка не будет, а в другом без него никуда, хотя и это не точно. По умолчанию никакой безопасности sudo не добавляет. Её и в системе то нет в базовой установке. Надо отдельно устанавливать там, где это действительно нужно.
Например, можно запретить подключение по SSH для root, настроить аутентификацию по ключам, и каждый раз при входе на сервер делать что-то типа sudo su и вводить пароль или перед каждой командой писать sudo. А можно разрешить подключение сразу под root, настроить аутентификацию по ключу и закрыть ключ паролем. Его тоже придётся один раз ввести, но попадаешь на сервер сразу под root. Какая схема безопаснее? А какая удобнее?
Кстати, для тех, кто ещё не знает, напомню, что sudo появилась и в Windows. Я уже пользуюсь, удобно.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#security
А я на самом деле сижу на сервере под root и не вижу в этом ничего зазорного. Сервер - не рабочая машина. Я туда не захожу просто так. Обычно я захожу на сервер для выполнения административных действий, для которых требуются права root. Без этих прав мне там и делать особо нечего.
Человек, который безапелляционно заявляет, что работать без sudo небезопасно, скорее всего до конца не понимает, что это за инструмент и для чего он нужен. Просто где-то прочитал об этом и бездумно повторяет.
Допустим, я единственный пользователь сервера, настроил его и администрирую единолично. Других людей там нет. Я не использую sudo. И какие это должно вызывать проблемы безопасности?
Другое дело, когда появляются разные пользователи. И здесь уже нужно sudo для аудита выполняемых действий и разграничения прав. Тем более, если работает большой отдел с единой системой хранения учётных записей и разграничения прав доступа. Хотя и это уже не панацея. Есть и другие модели многопользовательского доступа к серверам без использования sudo для логирования и разграничения прав.
Далее у нас появляются какие-то скрипты или другие инструменты, которые заходят удалённо на наш сервер для выполнения каких-то конкретных действий. Тут опять нужно sudo для того, чтобы их ограничить только теми действиями, которые им разрешены. Сюда же относятся и локальные службы с ограниченными правами, которые через sudo выполняют какие-то конкретно разрешённые действия с повышением прав. Например, это очень актуально для Zabbix Agent, который может что-то автоматически выполнять на сервере.
С помощью sudo удобно настраивать шаблоны систем для каких-то узких задач. Например, есть веб сервер, на который нужен почти полный доступ разработчиков, чтобы они могли смотреть логи Nginx, Php-fpm, перезапускать сервисы, менять их конфигурации и т.д. Но при этом за самой системой, её обновлением, закрытием уязвимостей следит другая служба, которая сама всё обновляет, перезагружает и следит за стабильной работой системы в целом. Через sudo разработчикам даётся доступ к нужным им службам, а всё остальное им недоступно, чтобы ненароком чего не сломали, не нарушили общие правила безопасности. В данном случае можно сказать, что дать полный доступ разработчикам к серверу без sudo небезопасно.
☝️К чему я всё это пишу? Специалист он на то и специалист, что разбирается в теме и в каждом конкретном случае думает, как ему сделать удобнее и безопаснее, а не просто повторяет заученные или случайно увиденные примеры. Подходы к настройке и управлению инфраструктурой на 3 сервера и на 100 будут разные. В одном случае от sudo никакого толка не будет, а в другом без него никуда, хотя и это не точно. По умолчанию никакой безопасности sudo не добавляет. Её и в системе то нет в базовой установке. Надо отдельно устанавливать там, где это действительно нужно.
Например, можно запретить подключение по SSH для root, настроить аутентификацию по ключам, и каждый раз при входе на сервер делать что-то типа sudo su и вводить пароль или перед каждой командой писать sudo. А можно разрешить подключение сразу под root, настроить аутентификацию по ключу и закрыть ключ паролем. Его тоже придётся один раз ввести, но попадаешь на сервер сразу под root. Какая схема безопаснее? А какая удобнее?
Кстати, для тех, кто ещё не знает, напомню, что sudo появилась и в Windows. Я уже пользуюсь, удобно.
———
ServerAdmin:
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
ServerAdmin.ru
На днях увидел новость, что в Windows появилась утилита sudo 😳, как в Linux, для повышения пользовательских привилегий до административных. Было очень удивительно это увидеть и организационно, и по идентичному названию, которое в Windows выглядит инородно.…
👍172👎6
Подписчик поделился интересной реализацией OTP (One Time Password) для подключений по RDP. При подключении пользователь сначала вводит свой основной пароль от учётной записи, а потом одноразовый через приложение на смартфоне. Это неплохо страхует сервер, доступный из интернета. Способ отлично подойдёт в том случае, когда по какой-то причине доступ по RDP нельзя убрать из прямого доступа через интернет.
Ничего особенного в этом нет, подобных систем много. Но обычно это отдельный сервис, который надо разворачивать, настраивать, и это не всегда просто и быстро сделать. А описанный ниже способ очень простой. Всё устанавливается локально на ОС Windows как серверных, так и десктопных редакций. Разницы в настройке нет.
Для реализации 2FA через OTP на Windows нам понадобится open source продукт под названием multiOTP, а точнее его отдельный компонент multiOTPCredentialProvider. Покажу сразу полную настройку. Я у себя всё проверил. Долго провозился, потому что разбирался, как всё это работает, собирал нужные команды, читал help. Повторить можно будет намного быстрее. ИИ не помог, тупо выдумал все команды. Вообще все.
Со страницы загрузки скачиваете свежую версию multiOTP Credential Provider. Это обычный
- локальные и удалённые входы
- локальные или удалённые разблокировки сеансов
- локальный или удалённый запуск приложений в режиме "Запустить от администратора (Run as Administrator)"
Я выбрал только один случай - remote logon, то есть удалённое подключение, в данном случае по RDP.
После установки запускаем cmd от администратора и переходим в каталог с программой:
Выбираем любого системного пользователя и задаём ему вход через TOTP:
◽️totp_user - имя пользователя
◽️34443E4948A3C06A1CFB - любой 160 битный ключ (Hexadecimal, Шестнадцатеричный ключ, 20 символов), можно создать в онлайн генераторе.
◽️6 - количество символов в одноразовом пароле
И сразу же создадим пользователю qr код для добавления в аутентификатор:
❗️Теперь важный момент. После установки multiOTP Credential Provider для всех удалённых подключений будет требоваться TOTP, даже если вы их не добавили в базу multiotp. Я попался на этом. Пришлось подключаться локально и добавлять TOTP для остальных учёток.
Только после того, как вы выполнили создание пользователя через multiotp, вы сможете отключить для отдельных пользователей использование TOTP:
Для пользователя zerox отключили одноразовые пароли. Он заходит как обычно.
Собственно, на этом настройка и окончена. Приведу список команд, которыми пользовался во время настройки.
Список пользователей в базе multiotp:
Информация о пользователе:
Настроить длину пароля по умолчанию:
Выпустить список одноразовых паролей. Могут пригодиться, если пользователь потерял смартфон или не может воспользоваться аутентификатором:
Я проверил одноразовые пароли. По ним нормально заходит.
Пользователю нужно установить на смартфон или компьютер какой-то аутентификатор. Их очень много. Я проверял Google Authenticator и FreeOTP. Последний можно через RuStore установить.
В самой программе достаточно отсканировать qr код пользователя и генератор одноразовых паролей для multiotp будет добавлен. Если нет возможности отсканировать qr код, то можно hexadecimal ключ сконвертировать в base32 и добавить вручную.
multiOTP - масштабный сервис. Может быть развёрнут в связке с AD, или по аналогии настроен в Linux для SSH.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#windows #security
Ничего особенного в этом нет, подобных систем много. Но обычно это отдельный сервис, который надо разворачивать, настраивать, и это не всегда просто и быстро сделать. А описанный ниже способ очень простой. Всё устанавливается локально на ОС Windows как серверных, так и десктопных редакций. Разницы в настройке нет.
Для реализации 2FA через OTP на Windows нам понадобится open source продукт под названием multiOTP, а точнее его отдельный компонент multiOTPCredentialProvider. Покажу сразу полную настройку. Я у себя всё проверил. Долго провозился, потому что разбирался, как всё это работает, собирал нужные команды, читал help. Повторить можно будет намного быстрее. ИИ не помог, тупо выдумал все команды. Вообще все.
Со страницы загрузки скачиваете свежую версию multiOTP Credential Provider. Это обычный
.msi пакет. Устанавливаете в системе. Во время установки ставите галочку, что не используете никакой сервис, а только локальную версию. Не запомнил, как точно настройка называлась. А на втором экране отмечаете галочками, для каких процессов будет запрашиваться одноразовый пароль. Это могут быть:- локальные и удалённые входы
- локальные или удалённые разблокировки сеансов
- локальный или удалённый запуск приложений в режиме "Запустить от администратора (Run as Administrator)"
Я выбрал только один случай - remote logon, то есть удалённое подключение, в данном случае по RDP.
После установки запускаем cmd от администратора и переходим в каталог с программой:
> cd C:\Program Files\multiOTPВыбираем любого системного пользователя и задаём ему вход через TOTP:
> multiotp.exe -debug -display-log -create totp_user TOTP 34443E4948A3C06A1CFB 6◽️totp_user - имя пользователя
◽️34443E4948A3C06A1CFB - любой 160 битный ключ (Hexadecimal, Шестнадцатеричный ключ, 20 символов), можно создать в онлайн генераторе.
◽️6 - количество символов в одноразовом пароле
И сразу же создадим пользователю qr код для добавления в аутентификатор:
> multiotp.exe -qrcode totp_user c:\multiotp\totp_user.png❗️Теперь важный момент. После установки multiOTP Credential Provider для всех удалённых подключений будет требоваться TOTP, даже если вы их не добавили в базу multiotp. Я попался на этом. Пришлось подключаться локально и добавлять TOTP для остальных учёток.
Только после того, как вы выполнили создание пользователя через multiotp, вы сможете отключить для отдельных пользователей использование TOTP:
> multiotp -iswithout2fa zeroxДля пользователя zerox отключили одноразовые пароли. Он заходит как обычно.
Собственно, на этом настройка и окончена. Приведу список команд, которыми пользовался во время настройки.
Список пользователей в базе multiotp:
> multiotp -userslistИнформация о пользователе:
> multiotp -user-info totp_userНастроить длину пароля по умолчанию:
> multiotp -config default-2fa-digits 6Выпустить список одноразовых паролей. Могут пригодиться, если пользователь потерял смартфон или не может воспользоваться аутентификатором:
> multiotp.exe -scratchlist totp_userЯ проверил одноразовые пароли. По ним нормально заходит.
Пользователю нужно установить на смартфон или компьютер какой-то аутентификатор. Их очень много. Я проверял Google Authenticator и FreeOTP. Последний можно через RuStore установить.
В самой программе достаточно отсканировать qr код пользователя и генератор одноразовых паролей для multiotp будет добавлен. Если нет возможности отсканировать qr код, то можно hexadecimal ключ сконвертировать в base32 и добавить вручную.
multiOTP - масштабный сервис. Может быть развёрнут в связке с AD, или по аналогии настроен в Linux для SSH.
———
ServerAdmin:
#windows #security
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
3👍230👎2
Последнее время заметил, что стали донимать ситуации, когда слетают аутентификации в софте после каких-то изменений в системе. Причём иногда эти изменения ожидаемы, а иногда нет.
Вчера поменял пароль от своей учётной записи в Windows, сегодня утром 10 минут логинился в браузере во всех системах - яндекс, гугл, вк, трелло, озон, интеграции в vscode с git и т.д. Всё слетело. Ещё и по паролю не везде зайти можно. То смс шлют, то кукарекод предлагают отсканировать, то открыть навигатор и посмотреть код там. У меня даже в приложении MAX аутентификация слетела, в Joplin - мастер пароль. А вот Telegram таким не страдает.
Если не будет телефона под рукой, то это может стать проблемой. Я один раз так встрял, когда был в отпуске в Архангельской области, где не ловит мой оператор связи. Сразу все способы аутентификации по смс перестали работать. Я после этого вернулся домой и везде, где мог, отключил их.
Подобные вещи иногда происходят после обновлений системы, но не всех. Не знаю, что там должно прилететь, чтобы аутентификации протухли. Одно время меня вообще донимал какой-то баг. Я после каждой перезагрузки заново логинился. Несколько дней моё утро начиналось с того, что я всюду обратно заходил в систему. Бегло поискал информацию, от чего это может зависеть, но конкретики нет. Факторов очень много.
Вы замечали какие-то изменения в системе, которые гарантированно приводят к сбросу сохранённых сессий? Я вот теперь узнал, что смена пароля учётной записи гарантированно приводит к этому. Поспрашивал немного ИИ, но он как обычно много воды налил, предположений и т.д. По факту у меня это иногда происходит без видимых причин.
Кому интересна эта тема, сразу подскажу, что всё это завязано на DPAPI (Windows Data Protection API). Ключевые сущности там - пароль и SID пользователя. Их изменение гарантированно приведёт к тому, что все завязанные на этот механизм данные будут утеряны. Но помимо них там ещё много криптографической обвязки и ключей. Система сложная и многоступенчатая. Я немного почитал, но не стал углубляться, потому что всё равно забудется со временем. Мне больше интересны практические действия с системой, которые приводят к сбору сохранённых зашифрованных сессий.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#windows #security
Вчера поменял пароль от своей учётной записи в Windows, сегодня утром 10 минут логинился в браузере во всех системах - яндекс, гугл, вк, трелло, озон, интеграции в vscode с git и т.д. Всё слетело. Ещё и по паролю не везде зайти можно. То смс шлют, то кукарекод предлагают отсканировать, то открыть навигатор и посмотреть код там. У меня даже в приложении MAX аутентификация слетела, в Joplin - мастер пароль. А вот Telegram таким не страдает.
Если не будет телефона под рукой, то это может стать проблемой. Я один раз так встрял, когда был в отпуске в Архангельской области, где не ловит мой оператор связи. Сразу все способы аутентификации по смс перестали работать. Я после этого вернулся домой и везде, где мог, отключил их.
Подобные вещи иногда происходят после обновлений системы, но не всех. Не знаю, что там должно прилететь, чтобы аутентификации протухли. Одно время меня вообще донимал какой-то баг. Я после каждой перезагрузки заново логинился. Несколько дней моё утро начиналось с того, что я всюду обратно заходил в систему. Бегло поискал информацию, от чего это может зависеть, но конкретики нет. Факторов очень много.
Вы замечали какие-то изменения в системе, которые гарантированно приводят к сбросу сохранённых сессий? Я вот теперь узнал, что смена пароля учётной записи гарантированно приводит к этому. Поспрашивал немного ИИ, но он как обычно много воды налил, предположений и т.д. По факту у меня это иногда происходит без видимых причин.
Кому интересна эта тема, сразу подскажу, что всё это завязано на DPAPI (Windows Data Protection API). Ключевые сущности там - пароль и SID пользователя. Их изменение гарантированно приведёт к тому, что все завязанные на этот механизм данные будут утеряны. Но помимо них там ещё много криптографической обвязки и ключей. Система сложная и многоступенчатая. Я немного почитал, но не стал углубляться, потому что всё равно забудется со временем. Мне больше интересны практические действия с системой, которые приводят к сбору сохранённых зашифрованных сессий.
———
ServerAdmin:
#windows #security
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍58👎2
Я регулярно пользуюсь сервисом Virustotal. Все незнакомые файлы обязательно проверяю там. Обычно через веб интерфейс. Случайно узнал, что у этого сервиса есть бесплатный консольный клиент - VirusTotal CLI.
Для того, чтобы им пользоваться, нужно получить API ключ, а для этого пройти регистрацию. Особых проблем с этим нет, сервис поддерживает аутентификацию через тот же github. Зашёл через свою учётку там и сразу забрал API ключ из отдельного раздела API Key. Ограничение бесплатной версии - 500 проверок в день. Для единоличного использования хватит за глаза.
Дальше забираем бинарник под свою систему: Windows, Lunux, MacOS или FreeBSD. Я взял линуксовую версию, несмотря на то, что моя основная рабочая система - Windows. Использовать его буду в WSL. Разработчики советуют запускать vt-cli под виндой не в стандартном терминале, а хотя бы в cygwin из-за того, что в стандартном окружении Windows утилита будет подтупливать при выводе портянок текста. Если вам это некритично, то можно сразу в винду поставить:
Я в итоге поставил так:
Дальше хотел добавить встроенное автозаполнение для bash, но у меня ничего не получилось:
Кто догадается, почему эта команда не сработала с sudo? Я когда набирал, не подумал об этом, но как получил ошибку, сразу понял в чём дело. Тут есть один важный нюанс, из-за которого такая конструкция не работает. Пришлось сделать, как обычно 😁:
После этого регистрируем свой API Key:
Теперь можно в консоли делать различные проверки:
Файл загрузился и ему назначен ID. Нужно некоторое время, чтобы завершилась проверка. Обычно минута-две. Смотрим результат проверки по этому ID:
Вываливается портянка проверок. Большого смысла читать всё нет. Нас интересует только результат:
Таким же образом можно сайты и их IP адреса проверять:
Можно ограничить вывод, чтобы не читать всё:
Я погонял разные проверки. Сначала вроде воодушевился, что можно использовать CLI. Но на деле анализировать вывод глазами не очень удобно. В браузере привычнее. Возможно вам где-то это пригодится больше, чем мне. У кого какие привычки.
Это решение скорее для каких-то небольших своих проектов типа телеграм бота или скриптов автоматизации с проверками доменов или IP адресов, если их не очень много. Например, с помощью этой утилиты можно автоматически проверять свои IP адреса на предмет попадания в списки нежелательных адресов.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX 😩
#security
Для того, чтобы им пользоваться, нужно получить API ключ, а для этого пройти регистрацию. Особых проблем с этим нет, сервис поддерживает аутентификацию через тот же github. Зашёл через свою учётку там и сразу забрал API ключ из отдельного раздела API Key. Ограничение бесплатной версии - 500 проверок в день. Для единоличного использования хватит за глаза.
Дальше забираем бинарник под свою систему: Windows, Lunux, MacOS или FreeBSD. Я взял линуксовую версию, несмотря на то, что моя основная рабочая система - Windows. Использовать его буду в WSL. Разработчики советуют запускать vt-cli под виндой не в стандартном терминале, а хотя бы в cygwin из-за того, что в стандартном окружении Windows утилита будет подтупливать при выводе портянок текста. Если вам это некритично, то можно сразу в винду поставить:
# winget install VirusTotal.vt-cliЯ в итоге поставил так:
$ wget https://github.com/VirusTotal/vt-cli/releases/download/1.3.0/Linux64.zip$ unzip Linux64.zip$ sudo mv vt /usr/local/binДальше хотел добавить встроенное автозаполнение для bash, но у меня ничего не получилось:
$ sudo vt completion bash > /etc/bash_completion.d/vtbash: /etc/bash_completion.d/vt: Permission deniedКто догадается, почему эта команда не сработала с sudo? Я когда набирал, не подумал об этом, но как получил ошибку, сразу понял в чём дело. Тут есть один важный нюанс, из-за которого такая конструкция не работает. Пришлось сделать, как обычно 😁:
$ sudo su# vt completion bash > /etc/bash_completion.d/vt# exitПосле этого регистрируем свой API Key:
$ vt initТеперь можно в консоли делать различные проверки:
$ vt scan file awscliv2.zipawscliv2.zip M2UwMDJjNjU2MTZjRlZmY6MTc3NjM2NDgzNQ==Файл загрузился и ему назначен ID. Нужно некоторое время, чтобы завершилась проверка. Обычно минута-две. Смотрим результат проверки по этому ID:
$ vt analysis M2UwMDJjNjU2MTZjRlZmY6MTc3NjM2NDgzNQ==Вываливается портянка проверок. Большого смысла читать всё нет. Нас интересует только результат:
$ vt analysis -i=stats M2UwMDJjNjU2MTZjRlZmY6MTc3NjM2NDgzNQ==- stats: confirmed-timeout: 0 failure: 1 harmless: 0 malicious: 0 suspicious: 0 timeout: 11 type-unsupported: 8 undetected: 56Таким же образом можно сайты и их IP адреса проверять:
$ vt url https://serveradmin.ru$ vt url last_serving_ip_address https://serveradmin.ruМожно ограничить вывод, чтобы не читать всё:
$ vt -i=**.result url https://serveradmin.ru$ vt -i=**.result url last_serving_ip_address https://serveradmin.ruЯ погонял разные проверки. Сначала вроде воодушевился, что можно использовать CLI. Но на деле анализировать вывод глазами не очень удобно. В браузере привычнее. Возможно вам где-то это пригодится больше, чем мне. У кого какие привычки.
Это решение скорее для каких-то небольших своих проектов типа телеграм бота или скриптов автоматизации с проверками доменов или IP адресов, если их не очень много. Например, с помощью этой утилиты можно автоматически проверять свои IP адреса на предмет попадания в списки нежелательных адресов.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#security
Please open Telegram to view this post
VIEW IN TELEGRAM
👍109👎1
В продолжение утренней темы, так как по длине туда всё не влезло. Хочу кратенько ещё одну тему затронуть, которая сейчас только набирает популярность - безопасная работа с ИИ. Пока не погружаешься в эту тему, до конца не понимаешь, какие конкретно есть опасности.
Например, в LM Studio появились плагины. Я когда про них читал, погрузился в эту тему. Они пишутся на JavaScript, в перспективе будет Python, и закодить там можно всё, что угодно. Помимо того, что в коде самих плагинов может что-то быть, но это проверяется относительно просто, они могут ходить по сайтам и собирать информацию. В этих сайтах могут быть запрятаны инструкции что-то сделать, что вам не понравится. Например, проверить какие-то локальные файлы, к которым есть доступ, найти там какие-нибудь токены от платных сервисов и отправить их куда-то во вне веб запросом. Или что-то более простое - гонять модельку по редиректам, устраивая кому-то ддос, или просто отправить её сканировать localhost или твою локальную сеть.
Ещё один вполне реальный пример. Вам присылают документ, который вы автоматом отправляете в ИИ на анализ. В документе есть инструкция - добавить ссылку на вредоносный сайт или заменить существующую. Может быть и посложнее - проверить локальный RAG на предмет каких-то паролей, токенов или другой приватной информации, и перейти по адресу aiserver.com/?info=password. Обычным GET запросом агент выдаст найденный пароль. А серия таких запросов может вообще какую угодно текстовую информацию выдать.
Чем плотнее ИИ-агенты будут интегрироваться в наши процессы, а мне видится это неизбежным уже в самом ближайшем будущем, тем больше у них будет доступов и возможностей. И тут впору появиться какому-то специализированному ИИ-антивирусу, который будет защищать от таких проблем. А пока их нет, вся защита на пользователях.
Публичные сервисы от всего этого защищены, а вот локальная защита - ваша ответственность. Самое очевидно - использовать самодельные песочницы. В простом случае - отдельные виртуалки и гонять информацию между ними без участия ИИ-агентов. И уж точно не запускать агентов с доступом ко всей информации или всему компьютеру. Сколько уже историй видел в инете, когда агенты грохали пользовательские файлы или всю систему.
#ai #security
Например, в LM Studio появились плагины. Я когда про них читал, погрузился в эту тему. Они пишутся на JavaScript, в перспективе будет Python, и закодить там можно всё, что угодно. Помимо того, что в коде самих плагинов может что-то быть, но это проверяется относительно просто, они могут ходить по сайтам и собирать информацию. В этих сайтах могут быть запрятаны инструкции что-то сделать, что вам не понравится. Например, проверить какие-то локальные файлы, к которым есть доступ, найти там какие-нибудь токены от платных сервисов и отправить их куда-то во вне веб запросом. Или что-то более простое - гонять модельку по редиректам, устраивая кому-то ддос, или просто отправить её сканировать localhost или твою локальную сеть.
Ещё один вполне реальный пример. Вам присылают документ, который вы автоматом отправляете в ИИ на анализ. В документе есть инструкция - добавить ссылку на вредоносный сайт или заменить существующую. Может быть и посложнее - проверить локальный RAG на предмет каких-то паролей, токенов или другой приватной информации, и перейти по адресу aiserver.com/?info=password. Обычным GET запросом агент выдаст найденный пароль. А серия таких запросов может вообще какую угодно текстовую информацию выдать.
Чем плотнее ИИ-агенты будут интегрироваться в наши процессы, а мне видится это неизбежным уже в самом ближайшем будущем, тем больше у них будет доступов и возможностей. И тут впору появиться какому-то специализированному ИИ-антивирусу, который будет защищать от таких проблем. А пока их нет, вся защита на пользователях.
Публичные сервисы от всего этого защищены, а вот локальная защита - ваша ответственность. Самое очевидно - использовать самодельные песочницы. В простом случае - отдельные виртуалки и гонять информацию между ними без участия ИИ-агентов. И уж точно не запускать агентов с доступом ко всей информации или всему компьютеру. Сколько уже историй видел в инете, когда агенты грохали пользовательские файлы или всю систему.
#ai #security
1👍75👎2