Советы по защите форума vBulletin
Если Вы держите свой форум, то рано или поздно приходится думать о защите Вашего форума — ведь злоумышленники не дремлют! В этом топике я (при помощи хабраюзера ReaM ) собрал список советов по увеличению безопасности Вашего форума. Заинтересовало? Добро пожаловать под хабракат :)
Итак… Начнем:
Описание: Без комментариев
Почему?: Jelsoft постоянно закрывает всплывшие уязвимости. Никому не хочется работать на прошлогоднем дырявом форуме, правда?
Описание: Переименовываем админку, но в конфигурации ни в коем случае не пишем путь к нашей переименованной админке. Также переименовываем модерку, но её уже можно прописать в конфигурации(хотя тоже нежелательно), так как она менее уязвима. Смотрите сами :)
Почему?: Если переименовать админку и не указать путь в конфигурации, то будет гораздо сложнее её найти и следовательно применить XSS или еще что похуже. Есть минусы: — редактирование профиля и добавление модераторов перестанут работать без ручной правки ссылок.
Описание:
a) если ip статичен, то
b) Также ставим дополнительный пароль:
Идём по ссылке: _http://vbsupport.org/htaccess.php, заполняем поля и дописываем по инструкции в наш файл htaccess.
Почему?: Дополнительное паролирование админки никогда не помешает.
Описание:
a) Удаляем файлы:
/validator.php(если имеется)
/checksum.md5(если имеется)
b) Удаляем папки:
/install/
Почему?: Небезопасные файлы от нулёных версий могут дать возможность просматривать список файлов, а также папка install очень вредная=)
Описание:
Идем в админку, далее:
a) Вложения -> Метод хранения вложений
Вложения должны храниться в базе данных
b) Аватары -> Тип хранения изображений пользователя
Аватары должны храниться в базе данных
Почему?: Линейка 3.5, если мне не изменяет память, давала прямые ссылки на картинки — что при неправильной конфигурации хостинга, давало шанс залить шелл.
Описание: Если выполнен пункт 5, то теперь смело ставим права на папки custom_* 644, так как они нам теперь не нужны(или можете их удалить). Дальше, если Вы устанавливали vBulletin по инструкции, у вас все папке в / (корне) должны иметь права 644. Проверьте это, если не так, то выставите права 644.
Почему?: Затрудняем хакеру заливку шелла.
Описание: Без комментариев. Зачем кому-то HTML?
Почему?: Возможность XSS атак при включенной функции.
Описание: Ставим .htaccess на папку includes следующего содержания:
Почему?:
Описание:
Почему?: Скрипты с указанными расширениями более невозможно использовать в пределах директории с таким htaccess.
Описание: /includes/config.php. Просто вписать id администраторов, после того когда внесли все необходимые изменения в профиль.
Почему?: Незачем лишний раз кому-то менять профили администраторов, даже им самим. Понадобится — удалят ID из файла, поменяют, вернут обратно. Безопасность — превыше всего! :)
Описание: Без комментариев
Почему?: А зачем вам на сервере лишние файлы? Незачем…
Описание: Без комментариев
Почему?: Они будут доступны для скачивания любому, кто узнает имя бэкапа. Конечно, можно htaccess прикрутить, но все равно, безопасности ради, выносите бекапы за пределы доступности веб-сервера.
Описание (цитата):
Скачать с vbsupport.org
Почему?: Незаменимая вещь в поиске шеллов на сайте, но ставить её необходимо заранее.
Доступ к админке получить довольно сложно — следовательно залить шелл через админку тоже. Можно залить шелл через уязвимости vB, но если лить в /includes (там есть для некоторых хаков файлы, которые требуют 777), то у нас на папке includes стоит deny from all — шелл попросту не будет доступен извне!
На остальные папки можно ставить права 644, если проделали все пункты — тогда достаточно сложно будет залить, особенно при правильной настройке chroot. И наконец, мы добавили защиту от самих админов, которые лазают где не попадя, тем самым сажая себя на XSS'ки и трояны.
Собственно, на этом всё… Это первый мой топик на хабре, так что просьба сильно не пинать :)
UPD: Перенес в «Информационную безопасность».
Итак… Начнем:
1) Апдейтимся в самый конец своей линейки(3.5.х,3.6.х,3.7.х)
Описание: Без комментариев
Почему?: Jelsoft постоянно закрывает всплывшие уязвимости. Никому не хочется работать на прошлогоднем дырявом форуме, правда?
2) Переименовываем админку и модерку
Описание: Переименовываем админку, но в конфигурации ни в коем случае не пишем путь к нашей переименованной админке. Также переименовываем модерку, но её уже можно прописать в конфигурации(хотя тоже нежелательно), так как она менее уязвима. Смотрите сами :)
Почему?: Если переименовать админку и не указать путь в конфигурации, то будет гораздо сложнее её найти и следовательно применить XSS или еще что похуже. Есть минусы: — редактирование профиля и добавление модераторов перестанут работать без ручной правки ссылок.
3) Ставим .htaccess на админку:
Описание:
a) если ip статичен, то
order allow, deny
deny from all
allow from %ваш_IP%
b) Также ставим дополнительный пароль:
Идём по ссылке: _http://vbsupport.org/htaccess.php, заполняем поля и дописываем по инструкции в наш файл htaccess.
Почему?: Дополнительное паролирование админки никогда не помешает.
4) Удаляем файлы и папки:
Описание:
a) Удаляем файлы:
/validator.php(если имеется)
/checksum.md5(если имеется)
b) Удаляем папки:
/install/
Почему?: Небезопасные файлы от нулёных версий могут дать возможность просматривать список файлов, а также папка install очень вредная=)
5) Перемещаем вложения и аватары
Описание:
Идем в админку, далее:
a) Вложения -> Метод хранения вложений
Вложения должны храниться в базе данных
b) Аватары -> Тип хранения изображений пользователя
Аватары должны храниться в базе данных
Почему?: Линейка 3.5, если мне не изменяет память, давала прямые ссылки на картинки — что при неправильной конфигурации хостинга, давало шанс залить шелл.
6)Выставляем права на папки
Описание: Если выполнен пункт 5, то теперь смело ставим права на папки custom_* 644, так как они нам теперь не нужны(или можете их удалить). Дальше, если Вы устанавливали vBulletin по инструкции, у вас все папке в / (корне) должны иметь права 644. Проверьте это, если не так, то выставите права 644.
Почему?: Затрудняем хакеру заливку шелла.
7) Нигде, никогда, никому не включаем опцию 'Разрешить html'.
Описание: Без комментариев. Зачем кому-то HTML?
Почему?: Возможность XSS атак при включенной функции.
8) Ставим .htaccess на папку includes
Описание: Ставим .htaccess на папку includes следующего содержания:
order allow, deny
deny from allПочему?:
- если туда каким-либо образом зальют шелл, то не смогут зайти на него.
- если вас будут ддосить, то возможен такой вариант, когда интерпретатор php отваливается и остается только апач — и апача разрешает уже читать файлы php — следовательно можно будет прочитать все файлы из папки /includes/ — тот же config.php, что не очень хорошо.
9) Пихните в директорию с файлами, на которых стоят атрибуты 0777 такой .htaccess:
© kerk _http://vbsupport.org/forum/member.php?u=30
Описание:
RemoveHandler .phtml
RemoveHandler .php
RemoveHandler .php3
RemoveHandler .php4
RemoveHandler .php5
RemoveHandler .cgi
RemoveHandler .exe
RemoveHandler .pl
RemoveHandler .asp
RemoveHandler .aspx
RemoveHandler .shtml
<Files ~ "\.php|\.phtml|\.cgi|\.exe|\.pl|\.asp|\.aspx|\.shtml">
Order allow,deny
Deny from all
Почему?: Скрипты с указанными расширениями более невозможно использовать в пределах директории с таким htaccess.
10) Отредактируйте config.php, впишите id администраторов в поле undeletable user(неудаляемые/неизменяемые пользователи).
Описание: /includes/config.php. Просто вписать id администраторов, после того когда внесли все необходимые изменения в профиль.
Почему?: Незачем лишний раз кому-то менять профили администраторов, даже им самим. Понадобится — удалят ID из файла, поменяют, вернут обратно. Безопасность — превыше всего! :)
11) После удаления модов/хаков не забывайте удалять файлы, которые Вы закачали вместе с ними.
Описание: Без комментариев
Почему?: А зачем вам на сервере лишние файлы? Незачем…
12) Никогда не сохраняйте бэкапы в пределах доступности веб-сервера.
Описание: Без комментариев
Почему?: Они будут доступны для скачивания любому, кто узнает имя бэкапа. Конечно, можно htaccess прикрутить, но все равно, безопасности ради, выносите бекапы за пределы доступности веб-сервера.
13) Установить плагин «Инспектор файлов».
Автор — Ghost (http://www.vbsupport.org/forum/member.php?u=38422)
Описание (цитата):
Лазая по своим старым скриптам, напоролся на этот продукт — Инспектор файлов. Это несколько модулей для vBulletin, при помощи которых можно сохранять в базе данных список существующих файлов и время от времени проверять, не изменились ли какие из них (для каждого файла сохраняется размер, владелец и права доступа) — встроенная cron-задача уведомит администратора по почте о найденных несоответствиях. Можно сохранять в БД несколько различных копий (ревизий) списков файлов для сравнения (автоматическая проверка с уведомлением на email сверяется только с последней ревизией). Внешний вид и доступные настройки можно посмотреть на скриншотах.
INSTALL: Для установки необходимо залить два PHP-файла из архива на сервер и импортировать продукт из файла «product-gfi.xml».
UPDATE: Обновление версий не предусмотрено, так что для установки новой рекомендуется сперва удалить предыдущую версию.
З.Ы. Продукт успешно работал на всех версиях от 3.6.8 до 3.8.1 включительно. Правда ссылка в выпадающее меню в панели навигации добавлялась в разные места, но это уже мелочи.
Скачать с vbsupport.org
Почему?: Незаменимая вещь в поиске шеллов на сайте, но ставить её необходимо заранее.
Итог:
Доступ к админке получить довольно сложно — следовательно залить шелл через админку тоже. Можно залить шелл через уязвимости vB, но если лить в /includes (там есть для некоторых хаков файлы, которые требуют 777), то у нас на папке includes стоит deny from all — шелл попросту не будет доступен извне!
На остальные папки можно ставить права 644, если проделали все пункты — тогда достаточно сложно будет залить, особенно при правильной настройке chroot. И наконец, мы добавили защиту от самих админов, которые лазают где не попадя, тем самым сажая себя на XSS'ки и трояны.
Собственно, на этом всё… Это первый мой топик на хабре, так что просьба сильно не пинать :)
UPD: Перенес в «Информационную безопасность».
комментарии (38)