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

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

    image


    Итак… Начнем:

    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

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


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

    Скачать с vbsupport.org

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

    Итог:



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

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

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

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

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 39

      +2
      С моего разрешения оформлено и запощено! спасибо автору:)
        +11
        да… хабр уже не тот
          –3
          Просто не нашел подобной темы тут, поэтому решил запостить. :)
            +1
            PS: советы вполне грамотные (мнения сисалмина и любителя булки с многолетним стжем)
              –3
              Жаль, кармы не хватает перенести в Информационную безопасность. :)
                0
                должно хватать…
                  0
                  уже — да.
            +1
            за 230 американских рублей купить «Продукт» и ещё допиливать его напильником?
            не… не круто… Хотя соглашусь, булка один из лучших движков, но я сторонник free
              –1
              50% форум в России купили сей продукт?
              vbsupport.org
              • UFO just landed and posted this here
              –3
              Спасибо, советы полезные, но что-то всё равно не то, наверно Булке пора выпускать новую исправленную версию, так как руками исправлять это не есть хорошо.
                –1
                vBulletin 4 уже есть. Честно говоря, не пользовал — поэтому не знаю что там да как… надо будет на vbsupport взять :)
                +3
                a) Вложения -> Метод хранения вложений
                Вложения должны храниться в базе данных

                b) Аватары -> Тип хранения изображений пользователя
                Аватары должны храниться в базе данных


                [сарказм]Ну нормальная рекомендация для школьного портала например.[/сарказм] Вместо того, чтобы отдавать аттачи, аватары быстро через nginx например, мы их фигачим через цепочку СУБД и фронтенда с бэкендом…
                  +1
                  «Советы по защите форума vBulletin»
                  Если мне удастся залить shell, то я его пробью через папку avatars, ок
                    +1
                    Это защита от прокаженных, достаточно в .htaccess запретить тогда уж выполнение любого php!
                      –3
                      в директории аватар и вложений
                      –3
                      А разве в этом поделии (vBulletin) разрешена загрузка шеллов на сервер? Что за десткий сад? Как это можно залить скрипт вместо аватара?

                      И вообще, советы на уровне какого-то форума про хакерство для школьников (особенно про переименовние админки — на одном сайте админку переименовали в что-то вроде f3563f3e3fre53, но прописали путь к ней в robots.txt. Я посмеялся :) ). Какой смысл переименовывать админку, если вход в нее доступен только через пароль?

                      И что за чушь с «при ДДОСЕ отвалится php» — куда он отвалится, он же обычно сделан как модуль апача?

                        –1
                        Вот-вот, даже в так ненавидимом пользователями VB IP.Board такое не получится сделать, расширение поменяется. Да и что мешает проверять HTML при разрешённом оном на наличие вредоносного кода…
                    +4
                    Пункт 5. сомнительный т.к. будет пухнуть база еще и от атачей, да и какой смысл пихать статику (атачи, аватарки) в базу? К тому же это хреново скажется в виде нагрузки на сервак с базой данных. Вообщем пункт 5. очень спорный.

                    В кач-ве зашиты в папке атачей (с папкой аватарок так же) тоже кладут htaccess-файл и в нем блочат все расширения файлов кроме разрешенных.
                      0
                      Не только нагрузка на бд, но и необходимость подключать php для отдачи статики станут проблемой.
                        –1
                        Угу и не будет возможности использовать nginx что бы отдавать через него статику.
                          0
                          :) ну можно заюзать proxy_cache\fastcgi_cache, но это из серии, «нельзя через писю, будем через попу», применительно к аватарам конечно.
                            0
                            Не заморачивайтесь — в vbulletin возможности отдавать файлы без обращений к базе все равно нет. Форум проверяет права доступа к разделу при каждом скачивании.
                              0
                              смотрим через браузер
                              мойдомен.ру/forum/images/avatars/i26103867_65034_7.gif

                              смотрим через ФС
                              ls -la /var/www/html/forum/images/avatars/i26103867_65034_7.gif
                              -rw-r--r-- 1 www-data www-data 7687 Sep 1 2007 /var/www/html/forum/images/avatars/i26103867_65034_7.gif

                              аттачи проверяет наверное, не смотрел
                        0
                        Не только нагрузка на базу, а и невозможность делать частые инкрементальные бэкапы, да и полный бэкап будет весить гигабайты с картинками.
                          –1
                          Согласен, но в таком случае у администратора форума есть выбор — либо удобство бекапа, либо теоретическая возможность поиметь у себя шелл. Можно обезопасить себя htaccess, можно по-разному извернуться… выбор всегда за администратором, а я в этом топике хотел показать возможные варианты увеличения безопасности форума.
                            0
                            Безопасность безопасностью, а если картинки в базе хранить — не будет ли проблем с большими файлами у mysql?
                              –1
                              Имхо лучше иметь один часовой геморрой(если это можно назвать так жёстко) с восстановлением в случае убиения форума шеллом, чем час геморроя каждую неделю(месяц) с бекапом.
                          +2
                          Большинство советов подходят практически к любому сайту. Особенно бэйсик авторизация для доступа в админку и выключение ненужных расширений. Хотя хороший фильтр при загрузке файла проверяет не расширение а содержание). А если сайт маленький можно запутать начинающих взломщиков (коих большинство) сменой расширений исполняемых файлов.
                            0
                            Есть еще один способ защиты это не доверять данным из вне и не надеятся на то что разработчики учли все возможные дыры в безопасности т.е. вешать при вызове первым скриптом проверку и фильтрацию входных данных на предмет всяких попыток пропихать XSS и SQL-иньекции + при попытках что пропихнуть себе отсылать оповещение и т.д…
                              +1
                              Собственно, почти это и делает плагин из пункта #13 :)
                                0
                                Скорее так «почти» :)
                              0
                              Метод 5 — хранение в БД??? — Да вы что!!!
                              Вы представляете себе форум на 1,5млн сообщений, с 30.000 юзеров. Из них у 15.000 будет аватар и фотка личная. И все это в базе… А если к этому добавить аттачи на 20Гб… Я бы посмотрел на ваш сервер mysql, который быстро бы умирал даже на хорошем сервере
                                +3
                                Пользователи: 217,889
                                Темы: 94,819
                                Сообщения: 967,708
                                у меня на форуме, и?
                                посмотри на мой сервер — если не умеешь настраивать не берись:)
                                  0
                                  Конфигурация сервера?..
                                    –1
                                    Окей, давай по новой… 20Гб аттачей… И все как пишет автор, засунем в БД… Вопросы?
                                    Крутой бэкап будет, кстати :-D

                                    И, кстати, какой конфиг сервера?
                                • UFO just landed and posted this here
                                    0
                                    Вроде все перечисленное мог бы сделать автомат, то есть чтобы в ручную не делать, или?
                                      0
                                      А чтобы найти заразу, можно воспользоваться вот этим бесплатным скриптом: revisium.com/ai/

                                      Only users with full accounts can post comments. Log in, please.