Наблюдения за vBulletin или попытки кэширования динамического контента. Наблюдения за vBulletin или попытки кэширования динамического контента Непотребный vbulletin

Выбираем движок форума. IPB, vBulletin, Phpbb

Форум (forum engine) для серьезного сайта является необходимой вещью. Известен принцип – любой сайт должен быть интерактивным. Способов добиться интерактивность существует множество, начиная от комментариев к статьям и заканчивая собственной тематической социальной сетью. Форум, пожалуй, является самым универсальным инструментом для реальной обратной связи с посетителями.

Форум позволяет:

Создать постоянную аудиторию пользователей сайта, которые будут постоянно возвращаться и проявлять активность. Активность посетителей это живые деньги.

Экономия на контенте. Если сделать форум, то контент будет создаваться пользователями, и владельцу нет необходимость закупать большие количества текстов для продвижения.

Расширение семантического ядра сайта. Создание форума позволяет без особых усилий со стороны владельца расширить количество запросов, по которым продвигается сайт.

Установить движок форума – процесс простой, а вот настройка и дальнейшее администрирование могут вызвать множество затруднений у новичка. Впрочем, по каждому популярному движку существует огромное количество документации, так что при желании можно разобраться во всем. Или нанять профессионального администратора.

По большому счету, подавляющее большинство движков вполне приспособлены для нормальной работы форума, имеют примерно один и тот же набор базовых функций, в том числе и гибкую систему настроек прав доступа для пользователей. Отличаются они удобством администрирования, набором шаблонов и плагинов, надежность и технической поддержкой от производителя. Начну обзор с тройки лидеров в Рунете: Phpbb – пожалуй, самый популярный движок для создания форума в рунете. Для новичка главным преимуществом Phpbb является бесплатность как самого движка форума, так и всевозможных дополнений. Также существует множество различных фанатских сообществ Phpbb, как в русскоязычном, так и в зарубежном интернете.

Среди других преимуществ можно выделить быстроту работы, простоту и относительную гибкость настроек, большое количество шаблонов и дополнений. Если сделать форум на phpbb, то его можно использовать как часть сайта (есть возможность интеграции со многими cms), но также можно сделать более или менее полноценный сайт-портал на его основе.

Но есть и недостаток Phpbb – большая уязвимость и к спамерским атакам, и к взломам с внедрением своего кода. Чтобы этого избежать, нужно устанавливать специальные дополнения для защиты от спама, а также регулярно обновлять движок, устанавливая новые версии. Увы, и это далеко не всегда обеспечивает стопроцентную защиту, так что следить за этим придется вручную самому или назначив модераторов. Скачать можно на официальном сайте https://www.phpbb.com/

IPB (Invision Power Board) – платный движок форума, что сразу отпугивает большинство новичков. Впрочем, если проект задумывается серьезным, то сумма порядка 200 долларов за IPB вряд ли остановит решительного вебмастера. Но десять раз подумайте, готовы ли вы, пусть даже и ради очень широкого круга возможностей, постоянно переделывать движок IPB под себя, рискуя усложнить себе поддержку и обновления.

Система обладает огромным количеством возможностей по интеграции с разными сервисами – различные cms, блоги, чаты, фотогалереи и т. п. Пожалуй, портал на этом движке может считаться вполне полноценным сайтом, конечно, при определенной настройке.

И тут не обошлось без значительной ложки дегтя – движок IPB обновляется довольно редко, в роли тестеров выступают сами пользователи, которые сами находят уязвимости и ошибки. В любом случае, код в итоге получается «кривым» и неоптимальным. Качественные русские фанатские сообщества отсутствуют, все проблемы придется решать самостоятельно. Русские локализации также далеки от совершенства, языковые файлы часто приходится редактировать для нормального отображения.

В связи со сложностью и некорректностью кода, форумы на IPB отображаются корректно только в FireFox, в остальных браузерах могут быть небольшие проблемы.

Также может возникнуть проблема при обновлении со второй на третью версии – изменилась структура скинов и классов, и если форум был видоизменен, провести апгрейд будет проблематично.

Система шаблонов IPB крайне запутана, изменить внешний вид не так просто, потребуется «перелопатить» множество файлов. Стандартный дизайн неплох и вполне привычен – но он стандартный, что, само по себе, для многих может являться существенным недостатком. Скачать Invision Power Board можно на официальном сайте http://www.invisionpower.com/apps/board/
vBulletin (vb). В русскоязычном сегменте интернета vBulletin традиционно называют «вобла» или «булка». Это пожалуй, лучший движок форума, больше добавить нечего. Цена порядка 250 долларов (лицензия покупается на год и включает бесплатные обновления за это время) вполне оправдана и уж точно окупит себя экономией времени и нервов. Тут все работает как часы. Вполне понятно, за что берутся деньги – движок vBulletin постоянно совершенствуется, причем видно, что над ним работают профессиональные программисты, а не просто фанаты.

Все функции перечислять нет смысла – в нем (или же в дополнениях) реализовано практически все, что может понадобиться администратору для создания форума. Там есть и мультицитирование, и поддержка подкастинга, и сообщества пользователей, и социальные группы, и гибкая система репутации и многое другое.

Конечно, для vBulletin есть большое количество дополнений и пользовательских сообществ, так что никаких проблем с обслуживанием не будет, особенно с учетом того, что существует официальная служба поддержки. Минусом vBulletin, пусть и не очень большим, является платность дополнений, например, для пользовательских блогов.

По большому счету, недостатков у форума нет. Его можно рекомендовать для крупных серьезных проектов именно из-за его надежности и устойчивости ко всевозможным атакам. Как следствие, он создает существенную нагрузку на сервер, особенно с установленными дополнениями, но для серьезных проектов обычно используют серьезные сервера и серьезных администраторов. Скачать можно на официальном сайте http://www.vbulletin.com/

SMF (Simple Machines Forum). Простой движок, с которым справится любой новичок. Простота компенсируется недостатком функционала, однако далеко не всем нужен полный набор «фишек». В движке удобно организована установка плагинов (модов), их можно скачать и установить прямо из админки буквально в несколько кликов.

Административная панель несколько непривычна, однако для новичка это не является недостатком, ведь у него нет опыта и привычек к другим движкам. Непривычность не означает неудобство. Еще одним плюсом является наличие большого числа конвертеров для перехода с других движков.

Форум очень надежен в плане взлома, а спам... ну, спам – это вечная проблема, с которой нужно и можно бороться. Несмотря на то, что SMF бесплатен, разработчики и опытные пользователи оказывают помощь всем нуждающимся на официальном форуме проекта.

На основе этого движка можно также создавать полноценные сайты при помощи специальных дополнений для порталов (Adk Portal, EzPortal и т. п.) Впрочем, большой вопрос, стоит ли делать портал на основе форума. Логичнее сделать форум как дополнение к основному сайту на полноценном движке.

Intellect Board (IntBoard). Движок форума для фанатов, написанный фанатом и им же успешно заброшенный. Впрочем, заброшенность не является поводом для того, чтобы категорически его не рекомендовать.

Сразу о недостатках. Проблемы зачастую возникают на ровном месте, поддержка отсутствует как класс, официальный форум практически мертв, там изредка отвечают владельцы форумов на этом движке. Дополнений и шаблонов практически не существует – все придется делать самостоятельно.

Но и преимущества есть. Код движка достаточно простой, чтобы даже новичок мог разобраться и самостоятельно исправить некоторых проблемы, а также подстроить какие-то функции для себя. Движок очень легкий, создает небольшую нагрузку на сервер. Админка крайне нестандартная, но зато в ней есть, пожалуй, самая лучшая возможность настроить права для пользователей; система групп и прав доступа к каждому конкретному разделу позволит создать мощную и эффективную систему модерации.

PunBB. Простой легкий движок с достаточно мощным сообществом, которое поможет в решении возникающих проблем. Нетребователен к ресурсам сервера. Административная панель интуитивно понятна.

Верстка сделана при помощи css, поэтому новичкам, привыкшим к табличной верстке, будет непривычно редактировать шаблоны. Впрочем, это и плюсом является – пора осваивать современные технологии.

Серьезным недостатком является высокая доступность для спама – нужно следить за этим вручную, помимо установленных плагинов.

ExBB – бесплатный движок, особенностью которого является то, что он работает с текстовыми базами данных, не используя MySQL. Быть может, лет 10 назад это было преимуществом – такие сайты создавали меньшую нагрузку, да и хостинги с поддержкой баз данных стоили намного дороже. Сейчас любой хостинг поддерживает MySQL, и текстовые базы являются недостатком; они намного медленнее и менее надежны.

Впрочем, сделать форум на этой cms можно для небольшого сайта, где не ожидается большого наплыва посетителей и сообщений. Он прост в установке, обслуживании, на официальном сайте имеется большое количество пользователей и форум поддержки.

Vanilla – этот малоизвестный движок позиционируется как дополнение к Wordpress, одной из самых популярных cms. Среди стандартных возможностей вордпресса нет возможности создания форума. Конечно, можно приспособить любой форумный движок, но это не так просто. Ванилла же устанавливается как обычный плагин.

Необычно реализована система личных сообщений – они публикуются как обычные темы, но видны только тем, кому они адресованы. В любой теме, помимо публичного, можно оставить и личное сообщение. Непривычно, но довольно удобно. В общем, создается впечатление, что разработчики решили сделать форум, непохожий на все остальные. Плюс это или минус – решать вам.

В общем, движков существует масса – можно пробовать, можно сразу остановиться на чем-то популярном, можно даже что-то свое написать или заказать. Нельзя однозначно сказать, какой из вариантов окажется оптимальным для каждого конкретного случая.

Администрация подобных сервисов ни за что обычно не отвечает, поэтому если ваш форум в какой-то прекрасный момент пропадет – они в лучшем случае принесут извинения.

В следующей статье я расскажу, какие бывают

Любой движок, требует определенных действий для оптимизации его для лучшей и быстрой работы. В нашем же случае мы поговорим об оптимизации Vbulletin 4.

Так как движок нашего форума постоянно обновляется, я не буду писать об оптимизации более ранних версий Vbulletin , а начну именно с версии 4.1.12. Хотя возможно, постепенно буду дополнять эту статью и оптимизацией для предыдущих версий, так как не все переходят на более новые.

Здесь я приведу несколько примеров, чтобы сделать Ваш форум Vbulletin быстрее и лучше (начиная с самых простых вещей, переходя к более сложным). Пожалуйста, имейте в виду, что те вещи которые работают у меня, не обязательно будут работать и у вас. Поэтому все изменения вы делаете на свой страх и риск.

Отключение списка пользователей.

Существует простой способ, просто отключить функцию в AdminCP. (Settings -> Options -> User Listing Options)

Это не глобально конечно, и вы можете это пропустить и не делать, просто задайте себе вопрос нужно ли вам это? Так как имея список пользователи могут сортировать его, посмотреть у кого больше сообщений, репутация и так далее. Ваши пользователи пользуются этим? Наверное, нет…, когда вы сами в последний раз пользовались этим списком?

Как по мне, так мне кажется, что данные списки только на пользу спамерам, так как это самый простой способ собрать все именна участников форума Vbulletin 4 для рассылки спама в личных сообщениях.

Кроме этого, запрос который необходим для генерации списка пользователей ужасен для серверов баз данных и может привести к большой загрузке сервера.

Увеличение скорости при обработке списка личных сообщений.

Если вы некогда не импортировали личные сообщения от внешних источников с помощью Impex или других средств, вы можете смело положиться на сортировку по ID для личных сообщений. Сортировка по ID будет делать так, чтобы вашему серверу базы данных не приходилось сбрасывать личные сообщения во временную таблицу для выполнения сортировки (делая запрос намного быстрее).

Чтобы сделать это, нужно прописать небольшой модуль с расположением в private_messagelist_filter и прописать в нем следующее:

If ($sortfield == "pmtext.dateline") $sortfield = "pm.pmid";

И все, вы только что сделали private.php на ~ 20% быстрее.

Настраиваем более эффективный поиск последних сообщений от пользователя.

Идем на фтп, ищем файл includes /class_userprofile.php, и заменяем в нем данные следующим образом, ищем:

$getlastposts = $this->registry->db->query_read_slave(" SELECT thread.title, thread.threadid, thread.forumid, thread.postuserid, post.postid, post.dateline FROM " . TABLE_PREFIX . "post AS post INNER JOIN " . TABLE_PREFIX . "thread AS thread USING (threadid) WHERE thread.visible = 1 AND post.userid = " . $this->userinfo["userid"] . " AND post.visible = 1 ORDER BY post.dateline DESC LIMIT 20 ");

и заменяем на это (а конкретнее ORDER BY):

$getlastposts = $this->registry->db->query_read_slave(" SELECT thread.title, thread.threadid, thread.forumid, thread.postuserid, post.postid, post.dateline FROM " . TABLE_PREFIX . "post AS post INNER JOIN " . TABLE_PREFIX . "thread AS thread USING (threadid) WHERE thread.visible = 1 AND post.userid = " . $this->userinfo["userid"] . " AND post.visible = 1 ORDER BY post.postid DESC LIMIT 20 ");

Это делает запрос немного правильнее, чем он существует в данном виде. Таким образом не придется делать сортировку во временную таблицу. Для пользователей у которых более 1000 сообщений, исходный запрос занял бы около 10 секунд, в нашем же случае намного меньше. Это в первую очередь относится к профилю пользователя Vbulletin 4, для отображения последних сообщений.

Проверка индекса тем.

Если ваши форумы имеют порядок сортировки по умолчанию, и которые установлены без изменений, таких какие мы делали выше, убедитесь, что все ваши индексы находятся в своих таблицах. были случаи когда индексы по неведомым мне причинам пересекались и некоторые форумы не открывались.

Я предлагаю сделать так, чтобы сортировка по умолчанию была в виде даты (столбец который использует эти данные называется «dateline»), и чтобы это реализовать, выполним запрос:

ALTER TABLE thread ADD INDEX forumid2_dp (forumid, visible, sticky, dateline)

Это запрос применим ко мне конкретно, в вашем случае forumid2_dp должен иметь ваше имя. Используйте на свой страх и риск.

Будьте осторожны при установке дополнений.

Просто потому, что кто-то делает модули и хаки, не означает, что они сделаны именно для вас, работали на больших форумах Vbulletin 4 и не имеют ошибок. Прекрасным примером служат сообщения о массовых взломах, через тот или иной хак.

Конечно, можно предположить, что разработчики не могут всего учесть, и перелопатить все хаки, чтобы они не конфликтовали, но… Убедитесь, что модуль Vbulletin не вызывает больших нагрузок базы данных, убедитесь, что в хак имеет потенциал к защите от SQL инъекций или XSS. К сожалению, приложений и модификаций тысячи, и просто не реально все проверить. Лучше будет если все хаки вы будете писать себе сами, или заказывать у кого-либо. Конкретно под вас и ваши задачи.

Не используйте таблицы в InnoDB.

Тут конечно мне могут плюнуть в лицо, так как эта тема уже обсуждалась миллион раз, но по своему опыту могу сказать, что я работаю 100% на MyISAM таблицах для любого действия. Бывает обрабатываю 1000 запросов в секунду.

Если вы уже начинаете психовать где при запросах у вас все повисает, особенно в новом поиске Vbulletin, смените таблицы InnoDB в MyISAM. MyISAM отвечает быстрее на отдельные запросы, так как не нужно управлять блокировкой отдельных записей. InnoDB работает быстрее в целом, но только потому, что позволяет выполнять запросы одновременно. если ваши запросы и так исполняются быстро под MyISAM, нет необходимости переходить на InnoDB. ИМХО.

Рейтинг статьи

0%

Рейтинг

User Rating: 0.35 (1 votes)

Есть в моем ведении несколько VPSов, на которых крутится… вообщем не моя зона ответственности, и потому крутится там то что крутится, в меру тормозит, в меру работает. И оказалось, что крутится на одном из них некий форум, и начал форум притормаживать. И захотелось разобраться…

Исхдные

• Форум под vBulletin 3.8.x
• Вынесен на поддомен forum.domain.com
• Nginx 1.1.13, php 5.3.x (fpm)
• Кроме форума на этом сервере ничего не крутится. (это важно ).
• Mysql на отдельном сервере, коммуникация через TCP/IP.

Предыстория

Жил себе форум, не тужил, показывал по xm top нагрузку в районе 30-40 процентов. А затем наступил час «Х» и нагрузка подскочила до ровной полки в 90 процентов с пиками выше, что, вообщем-то, не есть гуд. Подозрение на DDOS не подтвердилось. По логам наблюдалась обычная рабочая нагрузка. Ну а перед тем как тупо наращивать ресурсы возникла идея разобраться в происходящем и попытаться закэшировать все что можно.

Расследование. Часть первая - чего хочет женщина посетитель

Так как с идеологией и особенностями данной софтины я знаком не был, то начал изучение проблемы с анализа логов и траффика между посетителями и сервером. Первым делом я с удивлением обнаружил, что аттачи к сообщениям в форуме отдаются исключительно скриптом attachment.php , при этом сами файлы могут храниться в базе, могут на локальном диске, но отдача - только через скрипт. И никак иначе. То есть получаем по 8-10 лишних дерганий php-интерпретатора на ветвь сообщений с 8-10 фотографиями. И это для каждого посетителя. Так как на этом форуме для просмотра аттачей не требуется регистрация, то аттачи можно закэшировать, допустим, на пару дней. Примерно вот так:
location = /attachment.php { expires max; limit_req zone=lim_req_1s_zone burst=5; fastcgi_pass forum__php_cluster; include /etc/nginx/fastcgi_params; include /etc/nginx/fastcgi_params_php-fpm; fastcgi_cache forum_att__cache; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; fastcgi_hide_header Set-Cookie; fastcgi_hide_header Pragma; fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$host:$request_uri:"; fastcgi_cache_use_stale updating error timeout invalid_header http_500; fastcgi_cache_lock on; fastcgi_cache_lock_timeout 2m; fastcgi_cache_valid 2d; } и где-ньть в http-секци объявим forum_att__cache: fastcgi_cache_path /var/cache/nginx/att levels=1:2 keys_zone=forum_att__cache:4m max_size=2g inactive=2d;

Вторым «откровением» для меня было то, что на форуме есть архивы, и они не просто существуют, а практически половина запросов приходится именно на них. Внешний вид страниц также позволяет закэшировать их содержимое:
location /archive/ { expires 10d; limit_req zone=lim_req_1s_zone burst=2; location ~ \.css$ { expires max; } fastcgi_pass forum__php_cluster; fastcgi_index index.php; include /etc/nginx/fastcgi_params; include /etc/nginx/fastcgi_params_php-fpm; fastcgi_param SCRIPT_FILENAME $document_root/archive/index.php; fastcgi_param SCRIPT_NAME $fastcgi_script_name; fastcgi_cache forum_arc__cache; fastcgi_hide_header Set-Cookie; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$host:$request_uri:"; fastcgi_cache_use_stale updating error timeout invalid_header http_500; fastcgi_cache_valid 2d; } и в http-секцию: fastcgi_cache_path /var/cache/nginx/arc levels=1:2 keys_zone=forum_arc__cache:4m max_size=2g inactive=2d; Заодно подстрахуемся от DDOS-атак: limit_req_zone "$psUID" zone=lim_req_1s_zone:2m rate=1r/s;
О формировании ключа "$psUID" я поведаю далее.

Расследование. Часть вторая - авторизация в vBulletin

С точки зрения посетителя форума зашедший может быть либо зарегистрированным пользователем, либо гостем. Но совсем другая ситуация складывается, если мы пронаблюдаем ситуацию «пришел, походил, залогинился, походил, отлогинился, походил» с точки зрения появления и исчезновения кук в браузере. Итак, очищаем куки для домена и его поддоменов, открываем HTTPfox и наблюдаем что происходит:
HTTP/1.1 200 OK Set-Cookie: PHPSESSID=cdme9rrptft67tbo97p4t1cua5; expires=Wed, 22-Feb-2012 15:04:12 GMT; path=/; domain=.domain.com Set-Cookie: bblastvisit=1329059052; expires=Mon, 11-Feb-2013 15:04:12 GMT; path=/; domain=.domain.com Set-Cookie: bblastactivity=0; expires=Mon, 11-Feb-2013 15:04:12 GMT; path=/; domain=.domain.com Set-Cookie: uid=XCuiGU831OyC8VLqAx/QAg==; expires=Thu, 31-Dec-37 23:55:55 GMT; domain=.domain.com; path=/
С uid и PHPSESSID все понятно - это происки nginx"a и php-интерпретатора с установленной опцией session.auto_start , а вот остальные - следилки за активностью на форуме. А вот главной сессионной куки vBulletin пока не наблюдается. Забегая вперед скажу, что vBulletin не использует стандартную php-вую сессию (точнее ПОЧТИ не использует), а ведет свою, идентификатор которой хранит в куке bbsessionhash . Итак, пользователь зашел, а сессии нет - то есть он аноним без сессии. При этом ссылки на форум далее могут иметь два вида (имеются ввиду все ссылки на странице, а не одна так, а другая эдак):
forum.domain.com/forumdisplay.php?s=12b66e447be52ebc84ab16d3f39626fb&f=69
forum.domain.com/forumdisplay.php?f=69
И если пройти по ссылке первого типа, то следующим ответом от форума придет кука сессии, а если по ссылке второго - нет. Если со вторым ответом кука от сессии не пришла то по форуму можно так и бродить безсессионным и неприкаянным пока не нарвешься на ссылку первого типа (закономерность их появления у меня выявить не получилось), или захочешь залогиниться. При успешном логине кука сессии придет по-любому. Если до логина гость был анонимом-с-сессией, то сессию ему заменят. Выглядит это так:
HTTP/1.1 200 OK Set-Cookie: bbsessionhash=85745bc6110db5221e159087bf037f24; path=/; domain=.domain.com; HttpOnly
После логина сессия «стабильна» и чехарды с ссылками не происходит. Процедура логаута оригинальностью не отличается - удаляются все существующие форумные куки (даже те, которые не были проставлены) и пишется кука новой («анонимной») сессии:
HTTP/1.1 200 OK Set-Cookie: bbsessionhash=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bblastvisit=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bblastactivity=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbthread_lastview=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbreferrerid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbuserid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbpassword=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbthreadedmode=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbstyleid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bblanguageid=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.domain.com Set-Cookie: bbsessionhash=3d0bdc5dbe8dabae361deebe8f6048d2; path=/; domain=.domain.com; HttpOnly
То есть на выходе мы получаем анонима (гостя), но стопроцентно имеющего сессию.
В итоге с точки зрения форумного софта И HTTP-заголовков мы имеем три типа пользователей: гость без сессии , гость с сессией , залогиненный посетитель . Причем на уровне nginx"a отличать вторых от третьих крайне проблематично.

Теперь, поняв какие куки и как курсируют между посетителем и сервером, можно подойти к вопросу кэширования динамического контента. Как известно, функционал кэширования ответов fastcgi-бэкенда в nginx встроен в модуль ngx_http_fastcgi_module . Для этого надо прописать глобально в http-секции зону кэширования, а в нужном location"e - ключ. И если для условно-статического контента (изображения, архивы) ключем для кэширования мог считаться URI с незначительными дополнениями, то для кэширования динамики нужно учитывать еще и юзера. Казалось-бы правило типа
fastcgi_cache_key "$request_method:$http_if_modified_since:$http_if_none_match:$host:$request_uri:$cookie_bbsessionhash:";
могло бы удовлетворить и гостей и залогиненных пользователей, однако на практике посетители начали получать содержимое чужого кэша. Кэширование «истиной» динамики пришлось отключить. Надеюсь приговор не окончателен.

Однако данная информация не бесполезна. На ее основе мы можем генерить ключ для ограничения частоты запросов основываясь не только на IP адресе посетителя, но и на его статусе.
set $psUID "anon"; set $psUCL "anon"; if ($cookie_bbsessionhash) { set $psUID "$cookie_bbsessionhash"; set $psUCL "user"; } if ($psUCL = "anon") { set $psUID "anon:$remote_addr"; }
Данный фрагмент конфига размещаем в секции server конфига nginx до описания всех location. В итоге мы получаем оригинальный ключ на пользователя имеющего сессию и ключ основанный на IP адресе для посетителей сессии не имеющих (например для поисковый краулеров).

Результаты

В результате предпринятых усилий общая нагрузка на виртуалку снизилась с полки на 90 процентов до пилы на 40 с всплесками до 80 процентов.

Исключительно в ознакомительных целях. Администрация не несет ответственности за его содержимое. Скачать бесплатно .

vBulletin Connect v5.3.3 - мощный, масштабируемый и полностью настраиваемый пакет форумов для вашего сайта.

Версия: 5.3.3 (Nulled by vBSupport.org)

Минимальные требования php 5.6
Совместимость с php 7.1
При новой установке необходимо переименовать файл htaccess.txt в.htaccess
При обновлении удалить папку fonts (до запуска обновления).

Новые возможности:
Новый UI с обширной социальной интеграцией;
Оптимизирован под мобильные устройства;
Упрощена установка, управление и настройка;
Новая архитектура базы данных для улучшения поиска и лучшей производительности;
Удобное динамическое изменение контента;
Расширенная для обмена видео и изображениями;
Полная интеграция с VigLink;
Больше чем 100 других новых функций и улучшений;

Встроенные приложения:
Дискуссионный форум
Группы
Опросы
Блог

Оптимизация поисковой системы:
SEO дружественные URL
Пользовательский тег ключевых слов/описания META

Гибкость:
Расширяемые профили пользователей
Перезапись URL
Интерфейсная локализация
Метаданные

Соответствие стандартов:
Объединение в синдикаты содержания (RSS)
Объединение в синдикаты содержания: RSS, Atom, XML
PHP v5.4 совместимый

Без разрывный интегрированная система:
Единственный задействованный вход в систему
Единственная система разрешения
Единственная администраторская панель управления
Создайте непрерывный Стиль/тему через Статьи, Блоги, Форум

Панели управления для каждой роли:
Администраторские средства управления
Панель управления модератора
Пользовательская панель управления
Объединенная система разрешения
Движок шаблонов питания для усовершенствованной настройки

Управление пользователя:
Многопользовательская система с неограниченными ролями и полномочиями
Задействованные группы
Безопасность
Гранулированные полномочия
Проблемное уведомление
Совместимый SSL
Captcha
Подтверждение адреса электронной почты
Администраторский редактор новостей панели управления
Система "забастовки" входа в систему
Электронная почта и изменения Пароля требуют текущего пароля
Совместимый с Children"s Online Privacy Protection Act (COPPA) 1998

1. Зайдите в панель управления администратора:
Languages & Phrases - Download / Upload Languages.
2. В поле "EITHER upload the XML file from your computer" введите путь к
файлу vbulletin-language_ru.xml на Вашем компьютере.
3. В параметре "Overwrite Language" выберите пункт "Create New Language"
4. В поле "Title for Uploaded Language" введите название языка.
При отсутствии введённых данных язык будет называться "Russian (RU)"
5. Установите "Yes" в параметре "Ignore Language Version"
6. Установите "Yes" в параметре "Read Charset from XML File"
7. Нажмите на кнопку "Import" и ждите завершения процесса загрузки.
7А При желании, Вы можете сделать новый язык языком "По умолчанию",
нажав возле него кнопку "Default" / "Значение по умолчанию".

Если Вы держите свой форум, то рано или поздно приходится думать о защите Вашего форума - ведь злоумышленники не дремлют! В этом топике я (при помощи хабраюзера 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) Также ставим дополнительный пароль:

Почему?: Дополнительное паролирование админки никогда не помешает.

4) Удаляем файлы и папки:

Описание:
a) Удаляем файлы:
/validator.php(если имеется)
/checksum.md5(если имеется)
b) Удаляем папки:
/install/

Почему?: Небезопасные файлы от нулёных версий могут дать возможность просматривать список файлов, а также папка install очень вредная=)

5) Перемещаем вложения и аватары

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

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: Перенес в «Информационную безопасность».