Всем привет! Изначально создал подобную тему в оффтопе, но там понабежала школота и начала пороть неадекват. Создаю в разделе "Уязвимости" для адекватного обсуждения.

Предположим, перед вами стоит задача ликвидировать чужой сайт или форум. Какой метод реализации этой задачи вы бы разработали и осуществили? Просто удалить контент и базу данных - должного эффекта не возымеет, через некоторое время ресурс будет элементарно восстановлен из бэкапов.

После некоторых размышлений мне в голову пришел следующий алгоритм действий:

1. Зашифровываем (например по алгоритму AES) часть БД жертвы (если мы говорим о форуме, то шифруем только записи таблицы постов и только поле "тело сообщения")

2. Модифицируем исходный код ресурса для шифрования/дешифрования всех запросов к записям поля "тело сообщения" (при извлечении информации происходит процесс дешифрования, при внесении/обновлении записей - шифрование).

3. Ключ к шифру располагаем на удаленном сервере.

4. Ждем год О_о (столь длительный промежуток времени необходим для того, чтоб все имеющиеся бэкапы уже были зашифрованы и у жертвы не осталось незашифрованных бэкапов БД)

5. Через год попросту удаляем файл-ключ.

Результат: У жертвы остались либо только зашифрованные бэкапы и без ключа шифрования они представляют из себя информационный мусор, либо у жертвы всё же завалялся чистый (незашиврованный) бэкап годичной давности, но он уже неактуален.

P.S.: При использовании подобного метода мы безусловно столкнемся с серьезной нагрузкой на CPU сервера жертвы, но это уже детали. Я привел лишь концепт.

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

нормальные админы бекапы хранят на другом сервере, или на флешке в своем кармане

а вышенаписанное просто мазохизм, для чего все это нужно? и в чем смысл вреда? кайф получаете или что?

Идея хорошая но не сработает( Алгоритм дешифровки останется в бэкапах.

Крупный проект?

1)r00t=>PROFIT!

2)Зачем шифровать все посты измени алгоритм поролей юзеров палева меньше.Обычно бэкапы хранятся 14 дней.

3)Накидай на сайт доров,малвари,ДП,etc=PROFIT!

Можно так: скопировать базу на иной сервер и подключить его. А оригинал испортить. После года просто отключить сервер.

Не останется. Для дешифровки необходим ключ. На сайте жертвы хранится только путь к ключу, сам ключ находится на стороннем сервере. Когда наступает время "Ч" - удаляем ключ. В бэкапах осталась лишь ссылка на него, но самого тела ключа нет.

Тогда да, все верно.

В логах ключ останется( Так что мой способ лучше

Можно посмотреть на этот проект? Мы сами оценим его нормальность. Возможно даже узнаем каким образом бэкапятся данные

Жди, они уже идут

надеяться на то что одмин не заметит каши в бд во время того что на сервер возрастет ни с того ни с сего нагрузка и при том что мы говорим не о заброшенном блоге довольно глупо

и можно поподробнее про второй пункт, мне просто интересно сколько ты будешь модифицировать какую нить джумлу например

порой от админа безуспешно пытаешься спрятать шел, спрятать строчку в файле с shell_exec eval, а ты тут сурс переписать решил

Найти уязвимость ресурса и включить его в бот сеть, через некоторое время IP попадет во все черные списки и не один АВ не пустит пользователя на него.

Вероятность того, что админ заметит кашу только в одном поле одной таблицы - стремится к нулю. Если у вас есть собственный форум, то ответьте на вопрос: Делали вы хоть раз прямой вывод поля "тело сообщения", как часто вы вообще заглядываете в таблицу с постами?

При поиске решения возросшей нагрузки, можно попробовать посмотреть в сторону аппаратного ускорения AES. Т.е. если процессор сервера поддерживает аппаратное ускорение AES, то можно уже думать в сторону программной реализации.

Если без учета реализации ускорения шифрования/дешифрования через аппаратную составляющую, то на такую модификацию уйдет минут 15-20 и одна чашка кофе. Можно использовать AES_ENCRYPT()

В принципе решение хорошее, но до первой попытки админа сменить пароль БД.

Все одобряю, вперед и с песней. Можешь через недельку отписаться здесь, как там у тебя успехи с модификацией.

А на собственный вариант решения задачи, как я посмотрю, у вас фантазии не хватает? Ваш вариант какой?

С фантазией и креативом у меня все окей. Мой вариант будет действительно фатален для ресурса. Я лучше посмотрю как вы свой реализуете

Блесните! Предложите вариант "действительно фатального" исхода для ресурса. Сомневаюсь, что у вас такой вариант есть.

О наркоша ты опять здесь, скажи а кто тебя из лосей надоумил такую схему уничтожения сайта придумать?

Предложите свой.

тебе в прошлой написал про вирусы на сайте, или просто на ссылку на домен, уже спаленную антивирусными компаниями, тоже помогает с поисковой выдачи свалить

Дорвей на сайт, к примеру детское порно, очень популярно сейчас качать такое видео!

Тупо запретить в роботсе заходить поисковикам на сайт !! (Способ работает на ура, проверено!)

Ну и в конце концов, ни 1 поисковик не любит когда сайты спец. по каталогам сайтов загоняют, раскручивают нечестным путём. Достаточно по спаленным, грязным, каталогам разместить ссылки, чем больше тем лучше. И лучше всего одновременно.

Кстати, лучше всего по нелепым по тематике ключевикам!

выкидывать людей с поисковиков на другие ресурсы, прокладки типа "пиздуй на ... сайт больше не работает =)"

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

Значит я не правильно понял суть этой темы, но уничтожения ресурса полностью возможна только при уничтожении всей администраций проекта

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


если же это какой нибудь видео хостинг, при чём очень большой, реально ли его забекапить на несколько серверов, если он итак занимает десятки серверов с файлами? реально, но пздц как дорого, неоправданно дорого.

Мой пример

Взять блог на ворд прессе, сайт почти пустой, но ему 4 года (тут в шеле смотрю его) трафа тут примерно 3К в сутки, инфы, ну так статей 300 где то есть, но бля его бекап весит 6 гб (1 бекап) стоит он на VPS тут у него 15 гб памяти, итого в общем у него забито бекапом и сайтов почти 13 гб, думаешь админ качает его каждую неделю?

В конце концов, все подобные темы приходят к тому, что надо накидать на сайт вирусов или прогнать по каталогам.

Вирусы админ заметит еще быстрее чем тот изврат, что предлагает ТС, не заметит сам, так если на сайте есть интерактив, то юзеры стуканут.

По каталогам прогнать в принципе более годная идея, но я почему-то все равно не думаю, что она сработает, хотя смотря как гонять и по каким каталогам.

В любом случае это лишь пакость, потеря позиций в худшем для сайта случае, но никак не полное уничтожение.

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

Выносить в фоне старые страницы потихоньку это тоже вариант, если, например, жертва=форум, но заметить могут все равно, но вот если реально тихо подсирать, то восстановить потом никаких шансов не будет.

пздц какой херни он туда на пихал на 6 гб, видяхи что ли или данные статистики посещений?

Это невозможно в принципе. Точка. Контент восстанавливается из бекапов, из кеша, откуда-то еще, в конце концов, создается заново, одномоментно уничтожить какой-либо контент в сети просто невозможно, даже если он никому вообще не нужен и устарел, это и то очень сложно.

хз, файлов тут вообще не видно, видимо изображения в высоком качестве, видимо в БД статистику собирает все эти годы)

Пиздец изврат в базе изображения хранить, мало того что она вообще для этого не предназначена, так еще ее раздувает от этого и еще когда в базе изображения то ее бекап просто так не возьмешь и не отредактируешь в блокноте из-за размера да и еще у меня всегда после сохранения в таких случаях слетали изображения, конкретно это были аватарки на форуме VBulletin, хранение которых в базе я по глупости не отключил. Больше я так не делал.

Disasm, то что ты придумал это полная херня обреченная на провал с дичайшими ресурсозатратами.

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

Смотри зальются к тебе как-нибудь через "локальную картинку"

Это возможно. При благоприятном стечении всех обстоятельств - вполне возможно.

По этому я и говорю, что основной упор при решении этой задачи необходимо делать именно на бэкапы. Когда ресурс будет грохнут, админ сразу же будет пытаться поднять его из бэкапов. Необходимо обеспечить невозможность восстановление ресурса из бэкапов. Пока мы имеем только два варианта решения. То, что они извращенные никто не спорит, но и задача, извините меня, не из легких. Варианты решения и их основные узкие моменты (для простоты предположим, что речь идет о форуме, либо чисто информационном сайте):

Вариант первый:

Модифицируем исходный код ресурса и, в течение длительного промежутка времени, пишем в БД не сам контент, а его криптографическую производную. При чтении производим обратную операцию - извлекаем из БД криптографическую производную, дешифруем, отдаем клиенту. Визуально, для ресурса ничего не изменится - пользователи как общались, так и продолжают общаться, новости как висели на сайте - так и висят.

Очень маловероятно, что админ спалит, что всего в одном поле (даже не во всей БД, а всего в одном поле одной таблицы) хранятся не посты пользователей или новости, а "хрень какая-то" - спалить это практически нереально. Спалить это можно только совершенно случайно, при прямой выборке из таблицы постов или новостей.

Наступает время "Ч" - грохаем ресурс, отрубаем доступ к файлу-ключу. Админ кинулся восстанавливать ресурс, но в его бекапах вместо сообщений/новостей - криптографическая производная. Без исходного ключа шифрования - это просто мусор.

Цель достигнута - восстановление из бэкапов невозможно.

Жесткий минус - это нагрузка на CPU сервера. Насколько она возрастет - неизвестно. Это можно установить только экспериментальным путем. Если вопрос с нагрузкой будет решен или если нагрузка возрастет незначительно - то это 100% метод уничтожения контента сайта без возможности восстановления.

Вариант второй:

Производим замену БД ресурса на БД удаленного сервера. Через год закрываем доступ к БД. Этот вариант рассчитан на полную убогость админа, но все же вариант. Может прокатить при условии, что за год админ ни разу не сунется за чем-нибудь в БД.

Вариант третий и стопроцентный:

DDoS.

Минусы:

Колоссальные финансовые затраты. При том, затраты прямо пропорциональны времени и ответной реакции ресурса. Если ресурс подрубится к системе распределенной фильтрации трафика, то придется класть уже не только сам сайт, но и всю сеть, которая фильтрует трафик на пути к нему.

Ты же знаешь свое дело. В чем проблема поднять свой ботнет? Дело на пару дней

Эээ. А вариант бомбардировки серверов хостера чем не устраивает?

Предлагали, но почему-то данный вариант ТС не устроил

RulleR, ну мне до вас далеко, у вас-то и "действительно фатальные" варианты исхода для ресурса есть и ботнет, который на раз кладет любую сеть, даже сети, если мы говорим о распределенной фильтрации. Вам проще...

Да ваще не вопрос, показывай свою сеть. Мы тут лайвжурнал ложим, чо нам пару цисок положить

А как, подробности можно?

Ты находишься в разделе Уязвимости. Все пикантные подробности уже давно тут

Просмотрел всю тему с уязвимостями Vbulletin в разделе, но не нашел.

Не оффтопьте пожалуйста в теме!

И так... Продолжая размышлять над ликвидацией ресурса методом шифрования части БД, пришел к совершенно очевидному выводу о том, что модификация исходного кода ресурса - вообще ни разу не катит. Первый же установленный админом сторонний модуль/плагин/хак выдаст из БД зашифрованный мусор.

Тогда я припомнил, что многие СУБД (в т.ч. MySQL 5) готовы предложить нам такую замечательную плюшку, как триггер! Т.е. Шифровать и дешифровывать инфу мы будем централизованно на уровне БД, не модифицируя запросов на уровне исходного кода.

Потихонечку, практическая реализация становится все более и более реальной...

Ну естественно делается. Но мы будем хранить ключ шифрования не в базе, а на стороннем сервере. Без исходного ключа шифрования, дешифровать базу будет невозможно.

Загвоздочка с триггерами... MySQL позволяет нам обрабатывать только события INSERT, UPDATE, DELETE, но не позволяет работать с SELECT - дурдом короче! Т.е. зашифровать инфу при записи в БД мы можем, а вот расшифровать при извлечении - нет. Надо что-то придумать для дешифрования на уровне БД при SELECT. Будем думать...

Что-то никто больше никаких вариантов не предлагает... Господа, у кого хорошо с мозговой деятельностью - присоединяемся!

Напоминаю, что в этой теме обсуждаются способы необратимой ликвидации ресурса - а это действительно очень сложная задача, требующая неординарного подхода и сообразительности.

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

Бредово, но оригинально.

Если серьезно.

Тс это задача нерешаема, понимаешь? Есть такой класс задач в жизни, который решить нельзя.

ТС мне вот интересно, этот сайт вообще существует? Или ты просто теоретически хочешь решить этот вопрос?

Я это все к чему пишу-то. Если цель реальна, ее надо досконально изучить. Собрать максимум данных о ней. И только потом, на основе всей полученной информации, искать решение данной задачи.