- Регистрация
- 14 Авг 2012
- Сообщения
- 159
- Лучшие ответы
- 0
- Репутация
- 77
Несколько советов, которые помогут защитить ваш форум на движке vbulletin от нападок хакеров.
1) Апдейтимся в самый конец своей линейки(3.5.х,3.6.х,3.7.х,3.8.х или ставим новую версию 4.х.х)
Описание: Без комментариев
Почему ?: Jelsoft постоянно закрывает всплывшие уязвимости. Никому не хочется работать на прошлогоднем дырявом форуме, правда?
2) Переименовываем админку и модерку
Описание: Переименовываем админку, но в конфигурации ни в коем случае не пишем путь к нашей переименованной админке. Также переименовываем модерку, но её уже можно прописать в конфигурации (хотя тоже нежелательно), так как она менее уязвима.
Почему ?: Если переименовать админку и не указать путь в конфигурации, то будет гораздо сложнее её найти и следовательно применить XSS или еще что похуже. Есть минусы: — редактирование профиля и добавление модераторов перестанут работать без ручной правки ссылок.
3) Ставим .htaccess на админку:
Описание:
a) если ip статичен, то
b) Также ставим дополнительный пароль:
Идём по ссылке: _http://vbsupport.org/htaccess.php, заполняем поля и дописываем по инструкции в наш файл .htaccess.
Почему?: Дополнительное паролирование админки никогда не помешает.
3.1)
Переименованную папку админа и модерки, не нужно вносить в файл robots.txt - иначе нет смысла её переименования...
Нужно создать в папке админки и модерки файл .htaccess (в случае если ваш сервер Apache) с таким содержимым:
На файл поставить потом права CHMOD 444
Зачем? Чтобы поисковые боты не индексировали папки админки и модерки
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 следующего содержания:
Почему?:
если туда каким-либо образом зальют шелл, то не смогут зайти на него.
если вас будут ддосить, то возможен такой вариант, когда интерпретатор php отваливается и остается только апач — и апача разрешает уже читать файлы php — следовательно можно будет прочитать все файлы из папки /includes/ — тот же config.php, что не очень хорошо.
9) Вставьте в директорию с файлами, на которых стоят атрибуты 0777 такой .htaccess:
Почему?: Скрипты с указанными расширениями более невозможно использовать в пределах директории с таким htaccess.
10) Отредактируйте config.php, впишите id администраторов в поле undeletable user(неудаляемые/неизменяемые пользователи).
Описание: /includes/config.php. Просто вписать id администраторов, после того когда внесли все необходимые изменения в профиль.
Почему ?: Незачем лишний раз кому-то менять профили администраторов, даже им самим. Понадобится — удалят ID из файла, поменяют, вернут обратно. Безопасность — превыше всего!
11) После удаления модов/хаков не забывайте удалять файлы, которые Вы закачали вместе с ними.
Описание: Без комментариев
Почему ?: А зачем вам на сервере лишние файлы? Незачем…
12) Никогда не сохраняйте бэкапы в пределах доступности веб-сервера.
Описание: Без комментариев
Почему ?: Они будут доступны для скачивания любому, кто узнает имя бэкапа. Конечно, можно htaccess прикрутить, но все равно, безопасности ради, выносите бекапы за пределы доступности веб-сервера.
13) Установить плагин «Инспектор файлов».
Для этого устанавливаем хак Advanced Login System, который после ввода данных аккаунта, перенаправляет на страницу ввода капчи.
Что значительно усложняет подбор паролей.
Итог:
Доступ к админке получить довольно сложно — следовательно залить шелл через админку тоже. Можно залить шелл через уязвимости vB, но если лить в /includes (там есть для некоторых хаков файлы, которые требуют 777), то у нас на папке includes стоит deny from all — шелл попросту не будет доступен извне!
На остальные папки можно ставить права 644, если проделали все пункты — тогда достаточно сложно будет залить, особенно при правильной настройке chroot. И наконец, мы добавили защиту от самих админов, которые лазают где не попадя, тем самым сажая себя на XSS'ки и трояны.
1) Апдейтимся в самый конец своей линейки(3.5.х,3.6.х,3.7.х,3.8.х или ставим новую версию 4.х.х)
Описание: Без комментариев
Почему ?: Jelsoft постоянно закрывает всплывшие уязвимости. Никому не хочется работать на прошлогоднем дырявом форуме, правда?
2) Переименовываем админку и модерку
Описание: Переименовываем админку, но в конфигурации ни в коем случае не пишем путь к нашей переименованной админке. Также переименовываем модерку, но её уже можно прописать в конфигурации (хотя тоже нежелательно), так как она менее уязвима.
Почему ?: Если переименовать админку и не указать путь в конфигурации, то будет гораздо сложнее её найти и следовательно применить XSS или еще что похуже. Есть минусы: — редактирование профиля и добавление модераторов перестанут работать без ручной правки ссылок.
3) Ставим .htaccess на админку:
Описание:
a) если ip статичен, то
PHP:
order allow, deny
deny from all
allow from %ваш_IP%
Идём по ссылке: _http://vbsupport.org/htaccess.php, заполняем поля и дописываем по инструкции в наш файл .htaccess.
Почему?: Дополнительное паролирование админки никогда не помешает.
3.1)
Переименованную папку админа и модерки, не нужно вносить в файл robots.txt - иначе нет смысла её переименования...
Нужно создать в папке админки и модерки файл .htaccess (в случае если ваш сервер Apache) с таким содержимым:
PHP:
SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Yahoo" search_bot
SetEnvIfNoCase User-Agent "^igdeSpyder" search_bot
SetEnvIfNoCase User-Agent "^Robot" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
SetEnvIfNoCase User-Agent "^msnbot" search_bot
SetEnvIfNoCase User-Agent "^Aport" search_bot
SetEnvIfNoCase User-Agent "^Mail" search_bot
SetEnvIfNoCase User-Agent "^bot" search_bot
SetEnvIfNoCase User-Agent "^spider" search_bot
SetEnvIfNoCase User-Agent "^php" search_bot
SetEnvIfNoCase User-Agent "^Parser" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot
Зачем? Чтобы поисковые боты не индексировали папки админки и модерки
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 следующего содержания:
PHP:
order allow, deny
deny from all
если туда каким-либо образом зальют шелл, то не смогут зайти на него.
если вас будут ддосить, то возможен такой вариант, когда интерпретатор php отваливается и остается только апач — и апача разрешает уже читать файлы php — следовательно можно будет прочитать все файлы из папки /includes/ — тот же config.php, что не очень хорошо.
9) Вставьте в директорию с файлами, на которых стоят атрибуты 0777 такой .htaccess:
PHP:
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
</Files>
10) Отредактируйте config.php, впишите id администраторов в поле undeletable user(неудаляемые/неизменяемые пользователи).
Описание: /includes/config.php. Просто вписать id администраторов, после того когда внесли все необходимые изменения в профиль.
Почему ?: Незачем лишний раз кому-то менять профили администраторов, даже им самим. Понадобится — удалят ID из файла, поменяют, вернут обратно. Безопасность — превыше всего!
11) После удаления модов/хаков не забывайте удалять файлы, которые Вы закачали вместе с ними.
Описание: Без комментариев
Почему ?: А зачем вам на сервере лишние файлы? Незачем…
12) Никогда не сохраняйте бэкапы в пределах доступности веб-сервера.
Описание: Без комментариев
Почему ?: Они будут доступны для скачивания любому, кто узнает имя бэкапа. Конечно, можно htaccess прикрутить, но все равно, безопасности ради, выносите бекапы за пределы доступности веб-сервера.
13) Установить плагин «Инспектор файлов».
14) Защищаем форум от брута аккаунтов.Лазая по своим старым скриптам, напоролся на этот продукт — Инспектор файлов. Это несколько модулей для vBulletin, при помощи которых можно сохранять в базе данных список существующих файлов и время от времени проверять, не изменились ли какие из них (для каждого файла сохраняется размер, владелец и права доступа) — встроенная cron-задача уведомит администратора по почте о найденных несоответствиях. Можно сохранять в БД несколько различных копий (ревизий) списков файлов для сравнения (автоматическая проверка с уведомлением на email сверяется только с последней ревизией). Внешний вид и доступные настройки можно посмотреть на скриншотах.
INSTALL: Для установки необходимо залить два PHP-файла из архива на сервер и импортировать продукт из файла «product-gfi.xml».
UPDATE: Обновление версий не предусмотрено, так что для установки новой рекомендуется сперва удалить предыдущую версию.
З.Ы. Продукт успешно работал на всех версиях от 3.6.8 до 3.8.1 включительно. Правда ссылка в выпадающее меню в панели навигации добавлялась в разные места, но это уже мелочи.
Для этого устанавливаем хак Advanced Login System, который после ввода данных аккаунта, перенаправляет на страницу ввода капчи.
Что значительно усложняет подбор паролей.
Итог:
Доступ к админке получить довольно сложно — следовательно залить шелл через админку тоже. Можно залить шелл через уязвимости vB, но если лить в /includes (там есть для некоторых хаков файлы, которые требуют 777), то у нас на папке includes стоит deny from all — шелл попросту не будет доступен извне!
На остальные папки можно ставить права 644, если проделали все пункты — тогда достаточно сложно будет залить, особенно при правильной настройке chroot. И наконец, мы добавили защиту от самих админов, которые лазают где не попадя, тем самым сажая себя на XSS'ки и трояны.
Автор:
Чтобы видеть скрытое содержание Зарегистрируйтесь на форуме!
Последнее редактирование модератором: