Зашифровать БД форума

Статус
В этой теме нельзя размещать новые ответы.
по сути все зависит от цены вопроса, т.е. сколько готовы заплатить или вложить в защиту и сколько готовы выложить за взлом или за попытку взлома. если цена достаточно высока, то либо одна сторона отступает, либо другая.
Вероятность что взломают сервер с БД - 0.1%. Т.к. ее адресс и данные никому не известны.
Вероятность что взломают именно сервер с движком - 99.9%.
А если взломают сервер с движком, то пофигу где расположена база, на этом серве или на другом. ПОФИГУ.
вот так просто, взять и взломать? чисто, без одного алерта в логах, без малейшего нарушения работы всех служб, не тревожа систему мониторинга? малейший алерт и сервер с БД отрубается, до выяснения. да и админы будут уже на сервере разбираться, что и к чему.
Можно будет вытащить любые данные, при любой шифровке. Даже если у тебя там стоят куча ограничений, трижды шифрованные данные, закодированные скрипты и т.д.
в мире возможно все, я с этим совсем не спорю. а вот вероятность пройти, грамотно спроектированную систему защиты без единого алерта, очень мала. да и очень трудоемко это, проще забить и пойти искать что-нибудь менее защищенное.
А ты попробуй выдержать 200 юзеров онлайн на любом движке, почувствуешь разницу между локальным коннектом, удаленный коннектом и ssh-тунелем.
угу, я в курсе этого вопроса. в веб приложениях это немного проще: принял запрос - вернул данные или пачку данных, завершил соединение.
чем в некоторых бизнес приложениях, когда соединение с клиентом нельзя разрывать по несколько часов. понятно, что использовались железные тунели на цисках, а не програмный ssh-тунель. да и каналы были тоже не общедоступные.
 
вот так просто, взять и взломать? чисто, без одного алерта в логах, без малейшего нарушения работы всех служб, не тревожа систему мониторинга? малейший алерт и сервер с БД отрубается, до выяснения. да и админы будут уже на сервере разбираться, что и к чему.

Спасибо поржал.
Как ты себе это представляешь? А если у тебя под базу используется 2 и более серваков?
intval и mysql_real_escape_string вот две функции на пхп которые полностью решат проблем взлома через скуль. А также все остальное.
Да ты запаришься бегать анализировать логи. Если ты будешь при малейшем шорохе отключать базу, она у тебя постоянно будет в отключке. Потому что полно школьников-идиотов, которые будут любыми способами взломать твой серв. Тебя будут сканить, брутить, подставлять ковычки, пробывать xss и прочую хрень вытворять, все твои ids/ips,мод_секур и прочие безопасники, будут просто рыдать глядя на это.


Вообщем, для тех кто хочет, все это сделать по нормальному и не страдает излишней паранойей советую следующее:
1) Фильтруйте данные !ВСЕГДА!, ибо у вас должно работать с любыми входящими данные, а отключать базу - это не выход.
2) Используйте Mysql Proxy
читаем тут

Позволит балансировать нагрузку, расширить логгирование, исправление невалида, анализатор sql инъекции, модифицировать запросы, фильтровать и т.д.
 
Спасибо поржал.
ну вот вишь, какая польза от общения - хорошее настроение :)
а по теме, попроси кого-то рядом поднять локалхост и взломай его и получи все данные, не на словах, а получи.
да и наша тема не ограничивается только технической стороной, возможны и еше варианты и в офлайне тоже. все в цене вопроса.
Как ты себе это представляешь? А если у тебя под базу используется 2 и более серваков?
Да ты запаришься бегать анализировать логи. Если ты будешь при малейшем шорохе отключать базу, она у тебя постоянно будет в отключке. Потому что полно школьников-идиотов, которые будут любыми способами взломать твой серв. Тебя будут сканить, брутить, подставлять ковычки, пробывать xss и прочую хрень вытворять, все твои ids/ips,мод_секур и прочие безопасники, будут просто рыдать глядя на это.
как раз это меня меньше всего беспокоит. иногда специально не трогаю идиотов, чтобы понаблюдать за сообразительностью. :)
а от кол-ва серверов разве что-то зависит?
трудно управлять двумя-тремя серверами, потом кол-во не имеет значение.
если гиганто-мания... то под расстрел, ддосы, бруты, сканы можно поставить дешевые фронт-енды, где толком нихрена и не будет, даже и апача там может не быть :) они будут тупо держать пиковую сетевую нагрузку, а брутить и сканить там особо нечего будет. ладно, это лирическое отступление.
intval и mysql_real_escape_string вот две функции на пхп которые полностью решат проблем взлома через скуль. А также все остальное.
да НЕТУ SQL-я, НЕТУ. забудь про него. а иньекции - это вообще... ну не знаю какое слово юмора подобрать.
Вообщем, для тех кто хочет, все это сделать по нормальному и не страдает излишней паранойей советую следующее:
1) Фильтруйте данные !ВСЕГДА!, ибо у вас должно работать с любыми входящими данные, а отключать базу - это не выход.
как раз я об ЭТОМ и говорю. фильтрация - ДА, инъекция - смешно... (при затратах на разработку защиты и безопасности, это действительно смешно).

2) Используйте Mysql Proxy
читаем тут *** скрытое содержание ***
Позволит балансировать нагрузку, расширить логгирование, исправление невалида, анализатор sql инъекции, модифицировать запросы, фильтровать и т.д.
да, да, да. но мы говорим как раз о разных вещах, хотя и о похожих...
Mysql Proxy - это и есть "интерфейс доступа к БД", с одним отличием, что SQL-я не существует.
не нужно подстраиваться под все конечные приложения, лучше посмотрите, что у вордпреса внутри или у многих цмс тоже.
при постановке вопроса безопасности переписывается весь модуль работы с данными. есть запрос данных - есть ответ.
SQL?? - **х... только вопрос - ответ и это не sql :)
ну неужели вы не писали приложения, где в качестве универсально источника данных может выступать далеко не sql?
да и если это sql источник, то почему он должен понимать команды sql-я переданные в параметрах хз знает где??
инъекция - это мимо, другой вариант...
 
да НЕТУ SQL-я, НЕТУ. забудь про него. а иньекции - это вообще... ну не знаю какое слово юмора подобрать.

Что-то я не догнал, поясни?

Mysql Proxy - это и есть "интерфейс доступа к БД", с одним отличием, что SQL-я не существует.

Ды не интерфейс это, это реально прокси.

ну неужели вы не писали приложения, где в качестве универсально источника данных может выступать далеко не sql?

например?
 
Что-то я не догнал, поясни?
модель черного ящика: есть входные параметры. если входные параметры валидны, то есть выходные данные.
что внутри - неизвестно. конечному приложению совсем не нужно знать как и каким образом хранятся данные (частично пересекается с ООП моделью)
т.е. нет связки приложение - SQL
ну неужели вы не писали приложения, где в качестве универсально источника данных может выступать далеко не sql?
например?
да те же самые текстовые файлы, для хранения данных, на некоторых смс(упаси их душу :)
из известного: ну тот же самый микрософтовский ODBC, где источником данных может быть фиг знает что, включая и csv или текстовые файлы.
DTS на MSSQL начиная с 2000-го и выше.
перловые DBI/DBD - Results 1 - 10 of 206 Found
Для просмотра ссылки Войди или Зарегистрируйся
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху