- Регистрация
- 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) Защищаем форум от брута аккаунтов.
Для этого устанавливаем хак Advanced Login System, который после ввода данных аккаунта, перенаправляет на страницу ввода капчи.
Что значительно усложняет подбор паролей.
Итог:
Доступ к админке получить довольно сложно — следовательно залить шелл через админку тоже. Можно залить шелл через уязвимости vB, но если лить в /includes (там есть для некоторых хаков файлы, которые требуют 777), то у нас на папке includes стоит deny from all — шелл попросту не будет доступен извне!
На остальные папки можно ставить права 644, если проделали все пункты — тогда достаточно сложно будет залить, особенно при правильной настройке chroot. И наконец, мы добавили защиту от самих админов, которые лазают где не попадя, тем самым сажая себя на XSS'ки и трояны.
Автор:
Чтобы видеть скрытое содержание Зарегистрируйтесь на форуме!
Последнее редактирование модератором: