Комментарии 39
С моего разрешения оформлено и запощено! спасибо автору:)
+2
да… хабр уже не тот
+11
за 230 американских рублей купить «Продукт» и ещё допиливать его напильником?
не… не круто… Хотя соглашусь, булка один из лучших движков, но я сторонник free
не… не круто… Хотя соглашусь, булка один из лучших движков, но я сторонник free
+1
Спасибо, советы полезные, но что-то всё равно не то, наверно Булке пора выпускать новую исправленную версию, так как руками исправлять это не есть хорошо.
-3
a) Вложения -> Метод хранения вложений
Вложения должны храниться в базе данных
b) Аватары -> Тип хранения изображений пользователя
Аватары должны храниться в базе данных
[сарказм]Ну нормальная рекомендация для школьного портала например.[/сарказм] Вместо того, чтобы отдавать аттачи, аватары быстро через nginx например, мы их фигачим через цепочку СУБД и фронтенда с бэкендом…
+3
«Советы по защите форума vBulletin»
Если мне удастся залить shell, то я его пробью через папку avatars, ок
Если мне удастся залить shell, то я его пробью через папку avatars, ок
+1
Это защита от прокаженных, достаточно в .htaccess запретить тогда уж выполнение любого php!
+1
А разве в этом поделии (vBulletin) разрешена загрузка шеллов на сервер? Что за десткий сад? Как это можно залить скрипт вместо аватара?
И вообще, советы на уровне какого-то форума про хакерство для школьников (особенно про переименовние админки — на одном сайте админку переименовали в что-то вроде f3563f3e3fre53, но прописали путь к ней в robots.txt. Я посмеялся :) ). Какой смысл переименовывать админку, если вход в нее доступен только через пароль?
И что за чушь с «при ДДОСЕ отвалится php» — куда он отвалится, он же обычно сделан как модуль апача?
И вообще, советы на уровне какого-то форума про хакерство для школьников (особенно про переименовние админки — на одном сайте админку переименовали в что-то вроде f3563f3e3fre53, но прописали путь к ней в robots.txt. Я посмеялся :) ). Какой смысл переименовывать админку, если вход в нее доступен только через пароль?
И что за чушь с «при ДДОСЕ отвалится php» — куда он отвалится, он же обычно сделан как модуль апача?
-3
Пункт 5. сомнительный т.к. будет пухнуть база еще и от атачей, да и какой смысл пихать статику (атачи, аватарки) в базу? К тому же это хреново скажется в виде нагрузки на сервак с базой данных. Вообщем пункт 5. очень спорный.
В кач-ве зашиты в папке атачей (с папкой аватарок так же) тоже кладут htaccess-файл и в нем блочат все расширения файлов кроме разрешенных.
В кач-ве зашиты в папке атачей (с папкой аватарок так же) тоже кладут htaccess-файл и в нем блочат все расширения файлов кроме разрешенных.
+4
Не только нагрузка на бд, но и необходимость подключать php для отдачи статики станут проблемой.
0
Угу и не будет возможности использовать nginx что бы отдавать через него статику.
-1
:) ну можно заюзать proxy_cache\fastcgi_cache, но это из серии, «нельзя через писю, будем через попу», применительно к аватарам конечно.
0
Не заморачивайтесь — в vbulletin возможности отдавать файлы без обращений к базе все равно нет. Форум проверяет права доступа к разделу при каждом скачивании.
0
смотрим через браузер
мойдомен.ру/forum/images/avatars/i26103867_65034_7.gif
смотрим через ФС
ls -la /var/www/html/forum/images/avatars/i26103867_65034_7.gif
-rw-r--r-- 1 www-data www-data 7687 Sep 1 2007 /var/www/html/forum/images/avatars/i26103867_65034_7.gif
аттачи проверяет наверное, не смотрел
мойдомен.ру/forum/images/avatars/i26103867_65034_7.gif
смотрим через ФС
ls -la /var/www/html/forum/images/avatars/i26103867_65034_7.gif
-rw-r--r-- 1 www-data www-data 7687 Sep 1 2007 /var/www/html/forum/images/avatars/i26103867_65034_7.gif
аттачи проверяет наверное, не смотрел
0
Не только нагрузка на базу, а и невозможность делать частые инкрементальные бэкапы, да и полный бэкап будет весить гигабайты с картинками.
0
Согласен, но в таком случае у администратора форума есть выбор — либо удобство бекапа, либо теоретическая возможность поиметь у себя шелл. Можно обезопасить себя htaccess, можно по-разному извернуться… выбор всегда за администратором, а я в этом топике хотел показать возможные варианты увеличения безопасности форума.
-1
Большинство советов подходят практически к любому сайту. Особенно бэйсик авторизация для доступа в админку и выключение ненужных расширений. Хотя хороший фильтр при загрузке файла проверяет не расширение а содержание). А если сайт маленький можно запутать начинающих взломщиков (коих большинство) сменой расширений исполняемых файлов.
+2
Есть еще один способ защиты это не доверять данным из вне и не надеятся на то что разработчики учли все возможные дыры в безопасности т.е. вешать при вызове первым скриптом проверку и фильтрацию входных данных на предмет всяких попыток пропихать XSS и SQL-иньекции + при попытках что пропихнуть себе отсылать оповещение и т.д…
0
Метод 5 — хранение в БД??? — Да вы что!!!
Вы представляете себе форум на 1,5млн сообщений, с 30.000 юзеров. Из них у 15.000 будет аватар и фотка личная. И все это в базе… А если к этому добавить аттачи на 20Гб… Я бы посмотрел на ваш сервер mysql, который быстро бы умирал даже на хорошем сервере
Вы представляете себе форум на 1,5млн сообщений, с 30.000 юзеров. Из них у 15.000 будет аватар и фотка личная. И все это в базе… А если к этому добавить аттачи на 20Гб… Я бы посмотрел на ваш сервер mysql, который быстро бы умирал даже на хорошем сервере
0
НЛО прилетело и опубликовало эту надпись здесь
Вроде все перечисленное мог бы сделать автомат, то есть чтобы в ручную не делать, или?
0
А чтобы найти заразу, можно воспользоваться вот этим бесплатным скриптом: revisium.com/ai/
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Советы по защите форума vBulletin