Допустим есть некий ключ, который храниться в файле, этот ключ использует приложение на python, если серв хакнут, как уберечь или хотя бы затруднить процесс получения ключа для взломщика?
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Как уберечь данные при компрометации сервера?
- Автор темы Raskolnikov
- Дата начала
1. Поместить ключ в скрипт и обфускация, например pyarmor
2. Спрятать скрипт поглубже, типа сюда /usr/local/lib/python3.10/dist-packages/pip-23.0.1.dist-info/
Это затруднит, но не предотвратит
2. Спрятать скрипт поглубже, типа сюда /usr/local/lib/python3.10/dist-packages/pip-23.0.1.dist-info/
Это затруднит, но не предотвратит
Если тебя ломает АРТ то все поставленные цели будут достигнуты, и пиздец
А если не АРТ а просто пробили эксплоитом паблик или сбрутили то кто его искать станет вообще?
А если не АРТ а просто пробили эксплоитом паблик или сбрутили то кто его искать станет вообще?
А если он имеет в виду не APT? Допустим ФБР? Тогда ключ никак не спрячешь, сделают снимок жесткого диска и всё, данные из оперативки точно так же дампятся. Не нужно придумывать лишние сущности. К тому же есть команда last, на любом gnu/linux сервере, которая раскроет ip адреса любого пользователя подключившегося по ssh
, так что думайте головой в первую очередь дорогие мои, потому что ваша надежда на безопасность мгновенно тает, когда некоторые подразделения получают должное финансирование.Ну да, под словом АРТ я именно это и имел ввиду, таргетированная атака
А если он имеет в виду не APT? Допустим ФБР? Тогда ключ никак не спрячешь, сделают снимок жесткого диска и всё, данные из оперативки точно так же дампятся. Не нужно придумывать лишние сущности. К тому же есть команда last, на любом gnu/linux сервере, которая раскроет ip адреса любого пользователя подключившегося по ssh
- Автор темы
- Добавить закладку
- #6
Я знаю что апт достигнет целей, фбр сдампит память, мой вопрос совершенно в другом)
Можно подключаться к серверу только с одного ip, и написать скрипт который будет мониторить с какого ip идут подключения к серверу по тому же ssh. Если подключение к ssh произошло не из твоего ip, тогда запускать скрипт с wipe'ом.... как пример. Что-то похожее читал кажется в "Linux глазами хакера"....но не точно.
Также можно на видное место положить файл с вкусным названием, и тоже мониторить его открытие, ты то знаешь что это приманка, а другие нет.....
Также можно на видное место положить файл с вкусным названием, и тоже мониторить его открытие, ты то знаешь что это приманка, а другие нет.....
- Автор темы
- Добавить закладку
- #8
Идея с приманкой и запутыванием звучит интересно, спасибо
Такие решение дорого стоят и они непубличны. А то кто знает, может это ФБР собирает информацию, кто как противодействует, чтобы уже в свою очередь придумывать противодействие таким методам. Классический метод сбора инфы, да еще халявный. Не давайте им халявы.
В смысле для скрипта доступа использовать свой ip ?!
Вам не кажется, что это плохая идея?
Мой адрес использовать это за пределами всяких правил секретности! Можно использовать адрес впн или прокси, но это вещь не стабильная. Думаю это не то.
По запутыванию специалистов. Это рисковая скорее не обдуманное занятие. Запутать так спецов это заблуждение. Ищейки проведут точнейший анализ и долгие поиски крупиц истины.
Не знаю как вам, но мне кажется хороший способ применён у Таилс системы. Зашифровать некий раздел на диске. С таким функционалом придётся долго повозится, но оно того будет стоить.
Если система будет взломана злоумышленником, то ему предстанет зашифрованный раздел и не больше того. При этом в разделе можно хранить все личные данные, причём без опаски их кражи.
К сожалению должно быть только так. Ведь открытый способ подразумевает открытое хранение информации с какой нибудь секретной калиткой, что НЕ ИЗ ВНЕ, а уже там в системе. Этот путь чреват! Он запутан и возможно быстр и эффективен в работе но чреват. Тем что мы не знаем умственные способности взломщиков. Если они сильно мотивированы и допустим знают, что не применено шифрование с внешним ключиком, то они будут копать долго.
Думайте сами, нужно ли вам рисковать так. Не проще ли один раз хорошо поработать, хотя это будет очень сложно, зато потом иметь плюшку за пазухой и плевать на взломщиков?
Как по мне, то идея как у Таилс очень понравилась. Вы спокойны за свои данные, если применён хороший ключ шифрования.
Так же если предположить какой-то встроенный ключ, то как известно есть обратный реверсинг и этот ключ может быть вытащен. На мой взгляд при помощи простоты не получишь простоту. А простоту даст только предпринятая сложность.
Вам не кажется, что это плохая идея?
Мой адрес использовать это за пределами всяких правил секретности! Можно использовать адрес впн или прокси, но это вещь не стабильная. Думаю это не то.
По запутыванию специалистов. Это рисковая скорее не обдуманное занятие. Запутать так спецов это заблуждение. Ищейки проведут точнейший анализ и долгие поиски крупиц истины.
Не знаю как вам, но мне кажется хороший способ применён у Таилс системы. Зашифровать некий раздел на диске. С таким функционалом придётся долго повозится, но оно того будет стоить.
Если система будет взломана злоумышленником, то ему предстанет зашифрованный раздел и не больше того. При этом в разделе можно хранить все личные данные, причём без опаски их кражи.
К сожалению должно быть только так. Ведь открытый способ подразумевает открытое хранение информации с какой нибудь секретной калиткой, что НЕ ИЗ ВНЕ, а уже там в системе. Этот путь чреват! Он запутан и возможно быстр и эффективен в работе но чреват. Тем что мы не знаем умственные способности взломщиков. Если они сильно мотивированы и допустим знают, что не применено шифрование с внешним ключиком, то они будут копать долго.
Думайте сами, нужно ли вам рисковать так. Не проще ли один раз хорошо поработать, хотя это будет очень сложно, зато потом иметь плюшку за пазухой и плевать на взломщиков?
Как по мне, то идея как у Таилс очень понравилась. Вы спокойны за свои данные, если применён хороший ключ шифрования.
Так же если предположить какой-то встроенный ключ, то как известно есть обратный реверсинг и этот ключ может быть вытащен. На мой взгляд при помощи простоты не получишь простоту. А простоту даст только предпринятая сложность.
Последнее редактирование:
TC, скорее всего, использует скрипт в автоматизированном процессе, возможно он является частью веб приложения. Иначе, нет смысла хранить ключ на самом серваке, его можно было бы вводить каждый раз вручную при исполнении.
Если это автоматизированный процесс, то и диск/раздел в этом случае придется монтировать автоматически, это раз. Второе, на той же Tails раздел шифруется LUKS либо VeraCrypt. Когда зашифрованный диск примонтирован, он становится виден всем. В случае взлома рута, либо юзера с правами доступа к скрипту, например, www-data, apache etc. можно спокойно считать данные, включая скрипт и ключ.
Шифрование диска приносит профит только онпремис. На удаленном, тем более vps, смысла нет. Хостер может заполучить ключ от шифрованного диска, в момент монтирования, подменив системные файлы например.
Последнее редактирование:
Я бы спрятал ключик подальше и раскидал везде по серверу canarytokens. Так, что бы когда искали по базовым путям - тригнули canary-token и ты мог оперативно среагировать.
Никак не спрячешь, могут сделать снимок, сдампить память и тд. Нету 100% способа защитить данные
Последнее редактирование:
- Автор темы
- Добавить закладку
- #15
Да, всё верно, скрипт - часть веб приложения.
никак. если у хакера права приложения, или, ещё хуже, рута, то он легко разберёт это приложение и достанет ключ.
можно усложнить слив ключа, не храня его на диске, а только в памяти, то есть вводя ключ вручную при каждом запуске приложения.
и как уже предлагали, обязательно нужно настроить всякие IDS и/или раскидать "токены" на inotify, чтобы при обнаружении взлома приложение выключалось, то есть ключ выгружался из оперативной памяти.
можно усложнить слив ключа, не храня его на диске, а только в памяти, то есть вводя ключ вручную при каждом запуске приложения.
и как уже предлагали, обязательно нужно настроить всякие IDS и/или раскидать "токены" на inotify, чтобы при обнаружении взлома приложение выключалось, то есть ключ выгружался из оперативной памяти.
Вот простые и краткие меры для защиты данных при компрометации сервера: 1. Шифруйте данные. 2. Регулярно создавайте резервные копии данных. 3. Усилите безопасность сервера. 4. Ограничьте доступ к серверу. 5. Мониторьте и реагируйте на инциденты. 6. Обновляйте политики безопасности. 7. Подготовьте план реагирования на инциденты.