Значит я не правильно понял суть этой темы, но уничтожения ресурса полностью возможна только при уничтожении всей администраций проекта Опять же, вернёмся к предыдущей созданной теме, сколько весит бекап сайта? если же это какой нибудь видео хостинг, при чём очень большой, реально ли его забекапить на несколько серверов, если он итак занимает десятки серверов с файлами? реально, но пздц как дорого, неоправданно дорого. Мой пример Взять блог на ворд прессе, сайт почти пустой, но ему 4 года (тут в шеле смотрю его) трафа тут примерно 3К в сутки, инфы, ну так статей 300 где то есть, но бля его бекап весит 6 гб (1 бекап) стоит он на VPS тут у него 15 гб памяти, итого в общем у него забито бекапом и сайтов почти 13 гб, думаешь админ качает его каждую неделю?
В конце концов, все подобные темы приходят к тому, что надо накидать на сайт вирусов или прогнать по каталогам. Вирусы админ заметит еще быстрее чем тот изврат, что предлагает ТС, не заметит сам, так если на сайте есть интерактив, то юзеры стуканут. По каталогам прогнать в принципе более годная идея, но я почему-то все равно не думаю, что она сработает, хотя смотря как гонять и по каким каталогам. В любом случае это лишь пакость, потеря позиций в худшем для сайта случае, но никак не полное уничтожение. Вообще, задача уничтожения сайта не так проста. Все зависит от того, сколько ты готов на это потратить, мне кажется, самое реальное- это все время дидосить, если готов тратить действительно серьезные деньги, ну и заказывать взлом и раз за разом все сносить, вытаскивать базу юзеров и срать им от имени админа на мыло, я думаю, что через н-ное кол-во месяцев админу это просто надоест и он забьет на свой проект. Выносить в фоне старые страницы потихоньку это тоже вариант, если, например, жертва=форум, но заметить могут все равно, но вот если реально тихо подсирать, то восстановить потом никаких шансов не будет. пздц какой херни он туда на пихал на 6 гб, видяхи что ли или данные статистики посещений? Это невозможно в принципе. Точка. Контент восстанавливается из бекапов, из кеша, откуда-то еще, в конце концов, создается заново, одномоментно уничтожить какой-либо контент в сети просто невозможно, даже если он никому вообще не нужен и устарел, это и то очень сложно.
хз, файлов тут вообще не видно, видимо изображения в высоком качестве, видимо в БД статистику собирает все эти годы)
Пиздец изврат в базе изображения хранить, мало того что она вообще для этого не предназначена, так еще ее раздувает от этого и еще когда в базе изображения то ее бекап просто так не возьмешь и не отредактируешь в блокноте из-за размера да и еще у меня всегда после сохранения в таких случаях слетали изображения, конкретно это были аватарки на форуме VBulletin, хранение которых в базе я по глупости не отключил. Больше я так не делал.
Disasm, то что ты придумал это полная херня обреченная на провал с дичайшими ресурсозатратами. единственный верный способ испортить жизнь сайту это ддос, остальные способы это на удачу, при этом план твой осуществить это как выиграть милиард в лотерею, а если точнее, то заработать милиард работая менеджером среднего звена.
Это возможно. При благоприятном стечении всех обстоятельств - вполне возможно. По этому я и говорю, что основной упор при решении этой задачи необходимо делать именно на бэкапы. Когда ресурс будет грохнут, админ сразу же будет пытаться поднять его из бэкапов. Необходимо обеспечить невозможность восстановление ресурса из бэкапов. Пока мы имеем только два варианта решения. То, что они извращенные никто не спорит, но и задача, извините меня, не из легких. Варианты решения и их основные узкие моменты (для простоты предположим, что речь идет о форуме, либо чисто информационном сайте): Вариант первый: Модифицируем исходный код ресурса и, в течение длительного промежутка времени, пишем в БД не сам контент, а его криптографическую производную. При чтении производим обратную операцию - извлекаем из БД криптографическую производную, дешифруем, отдаем клиенту. Визуально, для ресурса ничего не изменится - пользователи как общались, так и продолжают общаться, новости как висели на сайте - так и висят. Очень маловероятно, что админ спалит, что всего в одном поле (даже не во всей БД, а всего в одном поле одной таблицы) хранятся не посты пользователей или новости, а "хрень какая-то" - спалить это практически нереально. Спалить это можно только совершенно случайно, при прямой выборке из таблицы постов или новостей. Наступает время "Ч" - грохаем ресурс, отрубаем доступ к файлу-ключу. Админ кинулся восстанавливать ресурс, но в его бекапах вместо сообщений/новостей - криптографическая производная. Без исходного ключа шифрования - это просто мусор. Цель достигнута - восстановление из бэкапов невозможно. Жесткий минус - это нагрузка на CPU сервера. Насколько она возрастет - неизвестно. Это можно установить только экспериментальным путем. Если вопрос с нагрузкой будет решен или если нагрузка возрастет незначительно - то это 100% метод уничтожения контента сайта без возможности восстановления. Вариант второй: Производим замену БД ресурса на БД удаленного сервера. Через год закрываем доступ к БД. Этот вариант рассчитан на полную убогость админа, но все же вариант. Может прокатить при условии, что за год админ ни разу не сунется за чем-нибудь в БД. Вариант третий и стопроцентный: DDoS. Минусы: Колоссальные финансовые затраты. При том, затраты прямо пропорциональны времени и ответной реакции ресурса. Если ресурс подрубится к системе распределенной фильтрации трафика, то придется класть уже не только сам сайт, но и всю сеть, которая фильтрует трафик на пути к нему.
RulleR, ну мне до вас далеко, у вас-то и "действительно фатальные" варианты исхода для ресурса есть и ботнет, который на раз кладет любую сеть, даже сети, если мы говорим о распределенной фильтрации. Вам проще...
Не оффтопьте пожалуйста в теме! И так... Продолжая размышлять над ликвидацией ресурса методом шифрования части БД, пришел к совершенно очевидному выводу о том, что модификация исходного кода ресурса - вообще ни разу не катит. Первый же установленный админом сторонний модуль/плагин/хак выдаст из БД зашифрованный мусор. Тогда я припомнил, что многие СУБД (в т.ч. MySQL 5) готовы предложить нам такую замечательную плюшку, как триггер! Т.е. Шифровать и дешифровывать инфу мы будем централизованно на уровне БД, не модифицируя запросов на уровне исходного кода. Потихонечку, практическая реализация становится все более и более реальной...
Ну естественно делается. Но мы будем хранить ключ шифрования не в базе, а на стороннем сервере. Без исходного ключа шифрования, дешифровать базу будет невозможно.
Загвоздочка с триггерами... MySQL позволяет нам обрабатывать только события INSERT, UPDATE, DELETE, но не позволяет работать с SELECT - дурдом короче! Т.е. зашифровать инфу при записи в БД мы можем, а вот расшифровать при извлечении - нет. Надо что-то придумать для дешифрования на уровне БД при SELECT. Будем думать... Что-то никто больше никаких вариантов не предлагает... Господа, у кого хорошо с мозговой деятельностью - присоединяемся! Напоминаю, что в этой теме обсуждаются способы необратимой ликвидации ресурса - а это действительно очень сложная задача, требующая неординарного подхода и сообразительности.
Создать свою сборку мускуля и пхпмайадмина и всех других скриптов бэкапа, какие есть на серваке, чтобы они выдавали внешни верный бекап корректного размера, но вместо данных, например, строкового типа писать строки из пробелов, а вместо цифр нули и т.д. Бредово, но оригинально. Если серьезно. Тс это задача нерешаема, понимаешь? Есть такой класс задач в жизни, который решить нельзя.
ТС мне вот интересно, этот сайт вообще существует? Или ты просто теоретически хочешь решить этот вопрос? Я это все к чему пишу-то. Если цель реальна, ее надо досконально изучить. Собрать максимум данных о ней. И только потом, на основе всей полученной информации, искать решение данной задачи.
