1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

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

Если Вы держите свой форум, то рано или поздно приходится думать о защите Вашего форума — ведь злоумышленники не дремлют! В этом топике я (при помощи хабраюзера ReaM ) собрал список советов по увеличению безопасности Вашего форума. Заинтересовало? Добро пожаловать под хабракат 🙂

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

Читать еще:  Заплатка от microsoft против вируса wanna. Wana Decrypt0r или WannaCry: необходимые обновления Windows и способы обнаружения. Эпидемия шифратора WannaCry: что сделать для избежания заражения. Пошаговое руководство

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 включительно. Правда ссылка в выпадающее меню в панели навигации добавлялась в разные места, но это уже мелочи.

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

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

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

Собственно, на этом всё… Это первый мой топик на хабре, так что просьба сильно не пинать 🙂

UPD: Перенес в «Информационную безопасность».

Неприятная ситуация ,согласен

Я,вообще,просто не могу представить себе ,такой способ лишения тебя средств 1х,может всё таки кто-то имел доступ ,я очень много раз ,сталкивался с ситуацией,когда человек покидал компьютер ,и по каким-то причинам ,не выходил с своего акк.,существуют так же и схемы мошенических действий ,для завладения твоим паролем,и в этих случаях ,как раз и нужно ,пихнуть всё ,если +,то быстренько вывести ,перевести на другой счёт ,как то обналичить ,я думаю если хорошо подумать ,как то можно это провернуть,подумай . за такими делами зачастую стоят люди из твоего окружения,постарайся вспомнить и разложить для себя всё в мелких деталях,и тогда ,возможно тебе станет всё понятно . Ещё вопрос ,что бы происходило если бы ставки зашли НО . Если всё ,действительно,так как описываешь ты ,то наши бабки тогда в опасности. у меня было очень много споров ,отмен,перерасчётов,но все ,до копеечки бабки заказанные мною были перечислены мне на карту(пусть для этого и была потрачена неделя времени ,куча нервов,верификацию ,я проходил раз 5,неменьше, счёт реально уже без бонуса,с огромным таймингом на приём ставок влайве,кф и Макс порезаный вообще в хлам,это методы 1х не поспоришь,но это всё с выплатой всех положенных мне средств.Борись ,за правду ,до конца.Я думаю, ты разъяснишь сложившуюся ситуацию,я лично слежу за темой,пиши,интересно кто действительно стоит за этим

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

Если Вы держите свой форум, то рано или поздно приходится думать о защите Вашего форума — ведь злоумышленники не дремлют! В этом топике я (при помощи хабраюзера ReaM ) собрал список советов по увеличению безопасности Вашего форума. Заинтересовало? Добро пожаловать под хабракат 🙂

Читать еще:  ТОП-30 Лучших Защищенных Смартфонов IP68 +Отзывы

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, что не очень хорошо.
Читать еще:  Как исправить ошибку при открытии Autodesk 3ds Max

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

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 включительно. Правда ссылка в выпадающее меню в панели навигации добавлялась в разные места, но это уже мелочи.

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

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

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

Собственно, на этом всё… Это первый мой топик на хабре, так что просьба сильно не пинать 🙂

UPD: Перенес в «Информационную безопасность».

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector