Почему?: Jelsoft постоянно закрывает всплывшие уязвимости. Никому не хочется работать на прошлогоднем дырявом форуме, правда?
2) Переименовываем админку и модерку
Описание: Переименовываем админку, но в конфигурации ни в коем случае не пишем путь к нашей переименованной админке. Также переименовываем модерку, но её уже можно прописать в конфигурации(хотя тоже нежелательно), так как она менее уязвима. Смотрите сами
Почему?: Если переименовать админку и не указать путь в конфигурации, то будет гораздо сложнее её найти и следовательно применить XSS или еще что похуже. Есть минусы: — редактирование профиля и добавление модераторов перестанут работать без ручной правки ссылок.
3) Ставим .htaccess на админку:
Описание:
a) если ip статичен, то
order allow, deny
deny from all
allow from %ваш_IP%
b) Также ставим дополнительный пароль:
Идём по ссылке: _http://vbsupport.org/htaccess.php, заполняем поля и дописываем по инструкции в наш файл 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/
a) Удаляем файлы:
/validator.php(если имеется)
/checksum.md5(если имеется)
b) Удаляем папки:
/install/
5) Перемещаем вложения и аватары
Описание:
Идем в админку, далее:
a) Вложения -> Метод хранения вложений
Вложения должны храниться в базе данных
b) Аватары -> Тип хранения изображений пользователя
Аватары должны храниться в базе данных
Идем в админку, далее:
a) Вложения -> Метод хранения вложений
Вложения должны храниться в базе данных
b) Аватары -> Тип хранения изображений пользователя
Аватары должны храниться в базе данных
6)Выставляем права на папки
Описание: Если выполнен пункт 5, то теперь смело ставим права на папки custom_* 644, так как они нам теперь не нужны(или можете их удалить). Дальше, если Вы устанавливали vBulletin по инструкции, у вас все папке в / (корне) должны иметь права 644. Проверьте это, если не так, то выставите права 644.
7) Нигде, никогда, никому не включаем опцию 'Разрешить html'.
Описание: Без комментариев. Зачем кому-то HTML?
Ставим .htaccess на папку includes
Описание: Ставим .htaccess на папку includes следующего содержания:
order allow, deny
deny from all
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
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
10) Отредактируйте config.php, впишите id администраторов в поле undeletable user(неудаляемые/неизменяемые пользователи).
Описание: /includes/config.php. Просто вписать id администраторов, после того когда внесли все необходимые изменения в профиль.
Почему?: Незачем лишний раз кому-то менять профили администраторов, даже им самим. Понадобится — удалят ID из файла, поменяют, вернут обратно. Безопасность — превыше всего!
Почему?: Незачем лишний раз кому-то менять профили администраторов, даже им самим. Понадобится — удалят ID из файла, поменяют, вернут обратно. Безопасность — превыше всего!
Почему?: А зачем вам на сервере лишние файлы? Незачем…
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'ки и трояны.