Безопасность

[hobot-bobot]

Несколько дней изучал возможности phpddEX, почитал форум, побаловался в виртуалке с установкой форума, установил портал и в ближайшее время собираюсь устанавливать на хостинг.
Вопрос в чем? Помогите советами дабы обезопасить форум. Первоначальные настройки, может кто поделится.
Есть ли риск,если буду писать сообщения на своем портале от имени администратора,и чем это чревато. На форуме phpbbguru в нескольких темах обсуждался этот вопрос, но конкретных доводов нет, и весь треп сводится к разделению участников на 2 категории ЗА и ПРОТИВ. По моим наблюдениям на большинстве форумов админы ведут активную переписку и тот не исключение.

[RuRupert]

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

[VEG]

phpBB / phpBBex хороши сразу после установки, и самое лучшее, что вы можете сделать, это:

• Избегать использования на этой же площадке сторонних движков, в которых регулярно находят уязвимости (просто перед использованием проверьте наличие эксплоитов через поиск, запрос вида «instantcms эксплоит»)
• Осторожно занимайтесь модификацией форума — в устанавливаемых модах тоже могут быть уязвимости
• Используемые вами скрипты — регулярно обновляйте (вполне возможно, что при обновлении будут решены какие-то обнаруженные проблемы с безопасностью)
• Хороший хостинг со свежим ПО (во избежание несанкционированного доступа к вашей площадке через других пользователей этого же хостинга)
• Разные и безопасные пароли на email, хостинг, FTP, SSH и на веб-сайтах
• Избегать возможного заражения вирусами всеми возможными способами, вплоть до полного отказа от пиратского ПО (вместе с которым вам могут подсунуть руткит, например)
• Не авторизуйтесь на вашем форуме, когда вы находитесь в публичных wi-fi сетях (ваш пароль могут перехватить, если ваш сайт работает не по зашифрованному протоколу HTTPS)

Самые частые способы взлома — угон паролей и известные уязвимости в популярных CMS. Остальное, что вам могут посоветовать на phpbbguru — скорее порождение паранойи, нежели реально полезные советы. Там некоторые слишком любят спасаться от неведомых типов угрозы и вводить ограничения ради ограничений.

Как-то дискутировал с их админом по поводу невозможности открытия нескольких окон с подтверждениями в обычном phpBB. Он свято верил, что подобное ограничение — это очень безопасно для форума, но почему именно такое ограничение повышает безопасность — объяснить так и не смог. Хотя на самом деле в phpBB эта проблема вызвана непродуманным механизмом борьбы с CSRF атаками, который сохраняет в базе только один последний вечный токен. В phpBBex этот механизм усовершенствован: в нём поддерживается открытие более одного окна с подтверждением и введено ограничение на время жизни выдаваемых токенов.

[Александр_130308]

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

Ведь безопасность проекта это целый комплекс разного рода защиты вашего сервера, серверного ПО, а также программного кода вашего проекта. Да, есть тот необходимый минимум который избавит вас от некоторого гемороя (грамотно написанный код ядра и модулей вашей cms), но суть проблемы это не решает. Можете даже не заморачивать себе и другим голову этой проблемой. Если вы просто ставите форум для небольшого проекта и вам не интересно администрирование серверов, программирование, в частности php, sql ...

[Sumanai]

Но боюсь уязвимость любого проекта с установленным phpbb* из коробки очевидна

Уязвимость любой программы очевидна. Даже специально написанной. Даже ping может глючить

[VEG]

Но боюсь уязвимость любого проекта с установленным phpbb* из коробки очевидна.

Почему вы считаете, что phpBB по умолчанию уязвим? Понятно, что программ без ошибок не бывает. Но! С 2008 года серьёзных уязвимостей в phpBB 3 не было найдено. Во времена phpBB 2 — да, бывало, что находили опасные уязвимости. Качество кода было другим. В phpBB 3 подход к разработке был более серьёзным. Вместе с отказом от совместимости с PHP 5.2 и менее можно написать ещё более безопасный код.

[factotum]

мне бы тоже хотелось знать, как реализована защита от наиболее распространенных атак, например, брутфорсов, дос-атак, ... ? Можно ли получить доступ к аккаунту, перехватив кукизы?

[VEG]

брутфорсов

При попытке подбора пароля после n-ной попытки выдаётся капча, что значительно усложняет перебор.

дос-атак

Тут движок ничего не поделает, с DDoS атаками борются на другом уровне. PHP для этих целей слишком медленный. Максимум, что здесь есть — это ограничение количества поисков в минуту (слишком уж трудозатратная операция).

Можно ли получить доступ к аккаунту, перехватив кукизы?

Только если вы сможете перехватить сырой HTTP запрос (в случае, если вы провайдер или прокси). Например, js-скриптом прочитать cookie сессии из document.cookie не получится.

[factotum]

Скажу так. Когда мы говорим о безопасности, мы подразумеваем:

• Наличие уязвимостей в движке, в том числе потенциальных (подразумевается противодействия распространенным методам несанкционированного доступа и в том духе)
• Средства защиты от атак
• Наличие уязвимостей и средств защиты на уровне серверной части.

По первому пункту - когда мне был нужен доступ к аккаунту, он был.

По второму пункту - защиты нет.

Третий пункт уже в другой компетенции

Так будет более справедливо.

Зы. iOS7 - пока написал все выше, возненавидел форумы. Попробуйте сами, наконец

[VEG]

По первому пункту - когда мне был нужен доступ к аккаунту, он был.

Что именно вы хотели сказать этим?

По второму пункту - защиты нет.

Ну как это нет? Если бы не было никаких «защит», движок был бы переполнен CSRF и XSS уязвимостями, нашёлся бы десяток SQL-инъекций или даже PHP-инклюдов. Правильно написанный скрипт автоматически предоставляет защиту от всех этих атак, если это можно так назвать (можно ли называть правильно написанный скрипт защитой?). Но никаких «дополнительных защит», чтобы «душа была спокойна», здесь делать не нужно. Не вводите людей в заблуждение.

[factotum]

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

мне всегда импонировала ваша отстраненность. мол меня не коснулось - значит не бывает.

Хотя логичней поставить вопрос по другому. Как-то так:
phpBB имеет высокую степень устойчивости к различным атакам, но можно подстраховаться, реализовав дополнительные механизмы противодействия атакам через моды/серверную часть.

[VEG]

Просто как пример дурацкой «дополнительной защиты». Во времена PHP 3, когда на PHP адекватные программисты не писали, и большинство веб-страничек было переполнено SQL-инъекциями, разработчики PHP придумали «спасительные» волшебные кавычки. Ну поленились они заниматься «просвещением» тогдашних PHP-программистов.

Суть в том, что все входящие данные автоматически фильтровались, и перед каждой кавычкой ставился экранирующий обратный слэш, из-за чего при подстановке этих данных в SQL запрос без экранирования всё работало так, как «хотел» быдлокодер. Кто-то даже решил, что это нормально, и целые системы разрабатывались с упором на этот костыль. Вы не представляете, сколько геморроя пришлось стерпеть из-за этой дурацкой «защиты»!

При этом разработчики, использующие magic_quotes, классически не понимали, что оно вообще делает и зачем нужно экранирование данных в SQL-запросах (оно же просто работает, да?). В результате при выводе данных в HTML они не занимались экранированием служебных для HTML символов, и получали уже HTML-инъекции. При этом при выводе каких-то данных из ввода пользователя на страничку они конечно же забывали удалить созданные автоматически экранирующие последовательности для SQL-запросов, в результате на странице рядом со всеми кавычками пользователь видел странный обратный слэш.

Я даже сталкивался с формой сохранения HTML-кода (!) в одной из админок, где при каждой отправке формы все экранирующие слэши умножались надвое. Вот это был ад! Сохраняешь невинный код <img src="test.jpg">, на выходе получаешь <img src=\"test.jpg\">. После повторного сохранения: <img src=\\\"test.jpg\\\">. Сохраним ещё раз, и получим: <img src=\\\\\\\"test.jpg\\\\\\\">. А теперь представьте, что тегов в сохраняемом тексте было штук 30, и менеджер пересохранил текст раз 10, не понимая, почему блок отображается неверно на сайте. Сколько месяцев было потрачено на переписывание этой системы и приведение её в относительно адекватный вид. Вот тебе и изнанка «мега-защиты».

Хорошо, что эта «фишка» выключается, а в PHP 5.4 её удалили совсем. Но сколько дров из-за неё уже было наломано...

Добавлено спустя 18 минут 5 секунд:
Кстати да, phpBB 3 не опирается на magic_quotes (даже если «фишка» включена, при старте phpBB 3 тратит время на то, чтобы откатить эффект этой опции). Но при этом он опирается на свой, в данном случае менее фатальный механизм, который делает HTML-escape всех входящих данных. Этим должен был бы заниматься шаблонизатор, но встроенный в phpBB шаблонизатор достаточно убог, чтобы уметь такое. Когда-нибудь хотелось бы побороть этот недуг. Кое-какие работы в этом направлении ведутся, пока что на уровне экспериментов.

Но вы можете считать просто, что в phpBB встроена железная защита от HTML-инъекций :)

[Александр_]

Вот чего не хватает так это хорошей статьи по безопасности, на пример настройка сервера от установки ос, до установки cms.

Ниже я приведу ряд мер которые можно применить в том или ином случае.

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

Код: Выделить всё

require_once( CONFIG_DIR. '/config.php' );

Всю графику, js, css в отдельную папку. К этой же папке и поддиректорий, делаем запрет на исполнение php файлов, к примеру /storage css /js /images /upload.
Возможность разместить важные папки и файлы в секретной директории которая будет защищена на уровне вэб сервера, там может быть к примеру дампер, мониторинг, управление кешом, конфиговский файл и т.д.

Сделать проверку админов и модеров по ip или header Authenticate php скриптом независимо.
Это только пример:

Код: Выделить всё

<?php if (usergroupaccess('admin','moder')) : ?>
инклюд проверочного скрипта
<?php // elseif (usergroupaccess('member')) : ?>
<?php else : ?>
<?php endif; ?>

Нестандартные права на все важные файлы и папки!!!

Если свой сервер
OS Linux* FreeBSD
Детальная настройка (необходимая)
ssh (sftp), iptables, ipfw.
Обзор: mc, arno-iptables и тд.

Пропаганда nginx+php-fpm apc+eaccelerator, mariaDB

Настройка быстродействия на уровне сервера (гостевое кеширование)

Настройка безопасности на уровне сервера
ssl, проверка запросов, запрет на исполнение php файлов в локейшн нужной папки, запрет доступа к папкам, NAXSI и многое другое.

Настройка логирования: ротация логов, понимание логов

Детальная настройка php
В частности:
register_globals
# allow_url_fopen
allow_url_include
file_uploads
disable_functions

display_errors
error_reporting

СУБД
Настройка (базовая)
настройка прав пользователя БД, ограничение доступа к БД.

Это малая часть того что можно сделать к улучшению быстродействия и безопасности проекта.

[VEG]

Зы. iOS7 - пока написал все выше, возненавидел форумы. Попробуйте сами, наконец

Я вообще не представляю, как вы не возненавидели iPhone/iPad за экранную клавиатуру. Это же так ме-е-е-е-едле-е-е-е-енно-о-о-о-о :)

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

Если немного помечтать, то хотелось бы в phpBBex увидеть совершенно новое ядро, активный шаблонизатор типа Smarty 3 / Twig с виджетами, поверх которого уже легко можно было бы с большим удобством сделать любой новый стиль. Кое-какие эксперименты по этому поводу сейчас проводятся. Дело в том, что есть список достаточно глобальных «хотелок», которые на текущем ядре без замены реализовать практически нереально. Если из экспериментов получится что-то достойное, то может быть когда-нибудь phpBBex переедет на полностью собственное ядро с преферансом и поэтессами

Добавлено спустя 3 минуты 50 секунд:
Александр_, в phpBBex стоит запрет на выполнение PHP кода из каталогов, где не должно быть таких скриптов, при помощи следующей инструкции в .htaccess:

Код: Выделить всё

php_flag engine off

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

[Александр_]

Главный недостаток открытого проекта, это то, что он открытый.
Mercurial в данном вопросе не панацея.
Качественно написанный код тоже самое.

[VEG]

Александр_, это как недостаток, так и преимущество. В закрытом проекте могут быть глупейшие уязвимости, которые быстро обнаружит любой заинтересованный просто «методом тыка». В открытом проекте код может изучать значительно больше людей, и велика вероятность, что при нахождении уязвимости, об этом будет оповещён разработчик.

То есть если у вас закрытый движок, и вас не взламывают, это не значит, что у вас качественный код. Скорее всего вы просто никому не нужны :) Я работал с многими самописными (закрытыми) системами, и там порой встречались совсем уж глупые уязвимости. Просто писать систему изначально были наняты неопытные программисты, которые наломали дров, а проверить качество кода было некому. Но сайты годами работали и ничего, потому что «Неуловимый Джо». С открытым проектом велика вероятность, что при плохом коде кто-то из опытных программистов сообщит о том, что в коде есть проблемы с безопасностью.

[Александр_]

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

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

[VEG]

Александр_, то что вы пишете было актуально больше 5 лет назад. Сейчас качество серьёзных открытых проектов, как правило, лучше, чем у закрытых проектов. В phpBB 3 с момента выпуска не было найдено ни одной серьёзной уязвимости. С 2008 года была найдена лишь одна небольшая проблема с BBCode [flash], который по умолчанию разрешён только администратору, то есть проблема не затронула подавляющее большинство форумов на phpBB 3.

Добавлено спустя 2 минуты 43 секунды:

Но именно открытые проекты ломают чаще всего, так как:
Разработчик не всегда узнает о уязвимости первым

Это же касается и закрытых проектов :) Или вы думаете, что при закрытом коде найти уязвимость нереально? Иногда под закрытым кодом скрывается настолько глупый код, что найти в нём уязвимость даже проще, чем в открытом проекте с доступными исходными кодами.

Добавлено спустя 4 минуты 11 секунд:

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

Также совершенно необоснованное утверждение. Как над закрытым проектом может работать неопытный разработчик, так и над открытым проектом может работать неопытный разработчик. При этом при закрытой разработке проверить качество кода часто бывает просто некому.

[Александр_]

Я писал о глобальной теме forums open source. В самом начале я дал положительную характеристику как phpbb так и *ex.
Но тоже самое можно сказать и о закрытых проектах. Открытому проекту я дал лишь один минус и он неоспорим.

То что сейчас качество стало на порядок выше, это очевидно, ведь 5 лет назад не о коком полноценном ооп в php и речи не было.

[Sumanai]

Зы. iOS7 - пока написал все выше, возненавидел форумы.

А что там сломали? Я с андроида писал, вроде ничего.