Советы по защите форума vBulletin

Shane

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 атак при включенной функции.

Ставим .htaccess на папку includes

Описание: Ставим .htaccess на папку includes следующего содержания:

order allow, deny
deny from all

Свернуть

Почему?:
если туда каким-либо образом зальют шелл, то не смогут зайти на него.
если вас будут ддосить, то возможен такой вариант, когда интерпретатор php отваливается и остается только апач — и апача разрешает уже читать файлы php — следовательно можно будет прочитать все файлы из папки /includes/ — тот же config.php, что не очень хорошо.

9) Пихните в директорию с файлами, на которых стоят атрибуты 0777 такой .htaccess:

Описание:

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) Установить плагин «Инспектор файлов».

Описание (цитата):
Лазая по своим старым скриптам, напоролся на этот продукт — Инспектор файлов. Это несколько модулей для vBulletin, при помощи которых можно сохранять в базе данных список существующих файлов и время от времени проверять, не изменились ли какие из них (для каждого файла сохраняется размер, владелец и права доступа) — встроенная cron-задача уведомит администратора по почте о найденных несоответствиях. Можно сохранять в БД несколько различных копий (ревизий) списков файлов для сравнения (автоматическая проверка с уведомлением на email сверяется только с последней ревизией). Внешний вид и доступные настройки можно посмотреть на скриншотах.

INSTALL: Для установки необходимо залить два PHP-файла из архива на сервер и импортировать продукт из файла «product-gfi.xml».

UPDATE: Обновление версий не предусмотрено, так что для установки новой рекомендуется сперва удалить предыдущую версию.

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

Свернуть

Почему?: Незаменимая вещь в поиске шеллов на сайте, но ставить её необходимо заранее.

Итог:

Доступ к админке получить довольно сложно — следовательно залить шелл через админку тоже. Можно залить шелл через уязвимости vB, но если лить в /includes (там есть для некоторых хаков файлы, которые требуют 777), то у нас на папке includes стоит deny from all — шелл попросту не будет доступен извне!

На остальные папки можно ставить права 644, если проделали все пункты — тогда достаточно сложно будет залить, особенно при правильной настройке chroot. И наконец, мы добавили защиту от самих админов, которые лазают где не попадя, тем самым сажая себя на XSS'ки и трояны.