Роман П.
1599 сообщений
#14 лет назад
Имеем рабочий интернет-магазин, есть вероятность рейдерского захвата компании; без движка и базы никому ничего нафик не сдалось.

Есть варианты защитить движок и базу так, чтобы даже имея бекапы, нельзя было восстановить ничего без конкретного человека?

Единственное, что придумал - кодировать важную инфу в базе, основные файлы, восстанавливать их на лету при работе самого сайта, ну и внедрить червяка в сайт, который, например, при отправке смски сносит все к чертям.
Роман Беляев
16382 сообщения
#14 лет назад
Ioncube + шифрование данных в базе RSA?

Или как простой вариант - обфускация скриптов и названий полей в базе.
Роман П.
1599 сообщений
#14 лет назад
Цитата ("frig"):
Ioncube + шифрование данных в базе RSA?


Т.е. даже админы сервера, где этот сайт находится - не смогут все расшифровать и нормально запускать сайт без ведома владельцев?
Роман Беляев
16382 сообщения
#14 лет назад
Crist, работать будет нормально, но как - понятно не будет. Исходный код закрыт, что в базе понять нельзя. Без доступа к исходным кодам и ключам, которые в зашифрованном коде ничего сделать будет нельзя.
Максим Ф.
3195 сообщений
#14 лет назад
Что продаём? Родину?

Обфускации файлов + внедрения червя достаточно. Как защитить базу не знаю.
Хостинг нормальный (м.б. зарубежный) купить.

----
upd: магазин без раскрученного домена - вначале ничто. регистрируйтесь у аккредитованного регистратора и оформляйте ту же по названию ооо.
Роман П.
1599 сообщений
#14 лет назад
Цитата ("AlekartRu"):
Обфускации файлов + внедрения червя достаточно


вот, кстати, немного не понял. Имея на руках бекап с этими файлами и базой, ведь все-равно они смогут запустить магазин без проблем? Вы имеете ввиду, что этого червяка перед обфускацией хорошенько запрятать и потом просто постоянно сносить магазин, который они будут запускать без первоначального владельца? Это все же не очень хороший выход, т.к. при большом-большом желании они этого червяка выкопают по логам и т.д.
Роман Беляев
16382 сообщения
#14 лет назад
Crist, можно сделать такую беду - если скрипту не удается получить доступ к определенному удаленному файлу, то он прекращает работу. Либо опять же реализовать шифрование на стороне. Сторонний скрипт будет хранить ключ для расшифровки базы, а в самом магазине будет скрипт который его будет по защищенному каналу запрашивать. Сперли скрипты - тушим выдающий ключи удаленный скрипт и все ровненько лежит :-).
Справедливости ради также ровненько оно будет лежать если по каким-то другим причинам сторонний хост перестанет выдавать ключи.
Можно еще суровее - какую-то важную функцию получать с удаленного хоста. Тоже шифрованную. Получать, расшифровывать, eval-ить и продолжать выполнение.
Роман П.
1599 сообщений
#14 лет назад
frig, во, насчет функции кстати просто отличная мысль! Реально классная идея. Спасибо! Пожалуй, лучший выход, тем более, мощности и деньги позволяют что почти что что угодно сделать. Осталась база вот ее наверное и буду шифровать удаленным ключем тоже..

Насчет шифрования на стороне - вот то, о чем писал в первом посте насчет кодирования - конечно, предполагал ключ хранить на стороннем сервере (как уже сказал - к хостингу, где магазин висит, есть доступ у админов и они неблагонадежны, так что если хранить ключ на нем же, то кодировать бессмысленно).
Роман Беляев
16382 сообщения
#14 лет назад
Ключи можно безопасно передавать с внешнего сервера.
Роман Р.
132 сообщения
#14 лет назад
Zend\Ioncube и прочую обфускацию для людей, которые поимели ваш сайт, снять - как пальцем об асфальт. все это давным давно легко снимается.
надо что то поновее
Роман Беляев
16382 сообщения
#14 лет назад
itspoma, вопрос в том сколько ресурсов и каких для этого потребуется. Чтобы разобрать обфусцированный код недостаточно просто автомата. А чтобы его потом модифицировать - надо весь его перешерстить и быстрее моск сломается, чем разберутся с хотя бы просто именованием.
Кирилл Е.
2817 сообщений
#14 лет назад
Нужно закодить всё так, чтобы тот кто полезет смотреть код - нафиг повесился/выбросился с окна/короче совершил суицид .. и БД так-же спроектировать..
У рейдеров тупо штата не хватит, или их посадят за массовые убийства ))
Роман Беляев
16382 сообщения
#14 лет назад
kirilev, свернуть все в один файл и обсфуцировать хватит на много много людей
Роман П.
1599 сообщений
#14 лет назад
А я меж делом еще придумал в движок червяка воткнуть который сносит все, но поставить на таймер и обновлять его вручную, а если не обновишь - мина срабатывает! Можно даже несколько таких воткнуть. Фик они ее откопают по логам, как если бы извне запускали снос движка, тут замучаются искать эксплойт)
Роман П.
1599 сообщений
#14 лет назад
А кстати, чем обфускацию делаете, добрые люди? Я никогда не делал этого, а гугл дал кучу продуктов, но все они платные, а мне бы бесплатный
Роман Беляев
16382 сообщения
#14 лет назад
Цитата ("Crist"):
а мне бы бесплатный


Не надо жмотиться.
Я пробовал каким-то бесплатным, не помню уже - работал более менее нормально. Надо искать нормальный, чтобы пожестче.
Роман Беляев
16382 сообщения
#14 лет назад
А можно и вообще - надуться и написать самому
Владимир Ф.
1322 сообщения
#14 лет назад
А тупо бекапы шифровать не прокатит?
Или набигание на хостинг тоже не исключено?
Роман Р.
132 сообщения
#14 лет назад
Цитата ("frig"):
itspoma, вопрос в том сколько ресурсов и каких для этого потребуется. Чтобы разобрать обфусцированный код недостаточно просто автомата. А чтобы его потом модифицировать - надо весь его перешерстить и быстрее моск сломается, чем разберутся с хотя бы просто именованием.

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

Как вариант - сделать так, чтобы злоумышленник думал что у него есть все файлы и бд, а на самом деле у него были фейковые данные.

И еще: посмотри как устроены сайты банков, крупных организаций, где хостятся, как защищаются.
Роман Р.
132 сообщения
#14 лет назад
Цитата ("vovan_f"):
А тупо бекапы шифровать не прокатит?
Или набигание на хостинг тоже не исключено?

А зачем бекапы шифровать? Воровать будут актуальные данные на текущее время.