Посвящается моему любимому человечку, с которым мы, надеюсь, что временно в разлуке.
Анют, это для тебя. Да это не стихи и не красивые слова, и для тебя эта статья ровным счетом ничего не значащая но делалось это в думах о тебе. (Злобные техники IBR тоже люди ... прим. Dekker IBR Staff)

Данная публикация целиком и полностью принадлежит автору GIV, администратору ресурса http://www.ibresource.ru. Опубликовано c разрешения http://www.ibresource.ru/. При цитировании указание источника обязательно. (прим. Dekker IBR Staff)

Данная статья не претендует на полное и единственно верное освещение проблемы безопасности форумов. Все здесь перечисленное это мой личный опыт.

Наверное, сразу стоит сказать, что 100% защиты форума от взлома не существует, и прочитав до конца статью вы поймете почему.

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

За сервер отвечает хостер, вывод прост нужен надежный хостинг. Что такое «надежный»? Я думаю, это должна быть фирма (заметьте, фирма, а не один человек, и даже не группа людей), которая уже не первый год работает на рынке. Но это точно не должны быть хостеры одиночки (знакомый Вася, с собственным сервером) и хостеры новички (группа людей, купивших сервер и предоставляющих «дешовый» хостинг).

Отдельно хотелось бы сказать про покупку выделенных серверов и колокейшен. При таком раскладе, вся ответственность за ПО сервера лежит на вас, т.е. нужно быть либо профи в *NIX, либо иметь такого профи в команде, ну или платить персоналу, на площадке которого размещен сервер и надеяться на их профессионализм (снова возвращаемся к понятию «надежный» хостинг).

У большинства администраторов проект состоит не только из форума, а еще и множества скриптов (CMS, галереи, магазины, и т.п.), выполняющих те или иные функции. Они так же представляют собой угрозу безопасности, и за ними тоже надо следить, во время обновлять, правильно настраивать.

Сейчас на примере постараюсь объяснить, почему так происходит. Итак, мы на своем хосте разместили форум и какую-нибудь простенькую систему управления сайтом (CMS). Обе системы работают с MySQL базой, причем база, как это часто бывает, и у форума, и у CMS одна и та же. Все здорово, все работает, но На некотором сайте опубликовали SQL уязвимость (возможность выполнения вредоносной инструкции в MySQL базе), которая работает на нашей CMS. И в один прекрасный день к нам пришел злоумышленник и выловил все хэши паролей и базу мыл с форума (для спамеров). Как он это сделал, ведь на форуме то дырок не было? Ответ прост общая база у форума и CMS.

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

Продолжая тему скриптов, упомяну еще о категории скриптов административного значения. К ним относятся, например, скрипты для работы с mySQL (phpMyAdmin, MySQLMan, и т.п.) эти скрипты как правило не имеют системы авторизации, а значит могут быть запущены любым пользователем, знающим об их существовании. Поэтому если у вас на сервере есть, такие скрипты, защищайте, хотя бы .htaccess, директории в которых они находятся. Желательно что бы эта защита была не при помощи базовой аутентификации (AuthType Basic), а по IP (deny from all, allow from ips). Теперь непосредственно о форумах.

Миф второй: «последняя версия значит лучшая».
Для начала точно определим, что такое версия и что такое билд, эта моя собственная классификация, так что пользоваться можно, но утверждать, что это истина из истин нет =]

Возьмем, к примеру, нумерацию версии в Invision Power Board:

• 1.0 первая персия (первое поколение)
• 1.1 вторая версия, нулевой билд
• 1.1.1 вторая версия, первый билд
• 1.1.2 вторая версия, второй билд
• 1.2 третья версия, нулевой билд
• 1.3 четвертая версия, нулевой билд
• 1.3.1 четвертая версия, первый билд
• 2.0 пятая версия (второе поколение)

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

Вернемся к вопросу какая версия безопаснее. Очевидно, что последний билд версии, предшествующей текущей версии (трудно уловить на словах, потому привожу пример версия 1.3.1 будет безопаснее, нежели версия 2.0.0).

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

Однако не все так просто, и особняком у нас стоит первая версия новой линейки. Конечно, ставить нулевой билд первой версии это, мягко говоря, неправильно, но когда счетчик билда переваливает за цифру 2-а, то такую версию уже можно ставить.

Снова привожу пример. Пусть есть версии 2.0.0, 2.0.1. В такой ситуации ставить 2-ю версию форума нецелесообразно, так как она еще нестабильна. Если у нас набор версии таков: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, то можно смело ставить 2.0.4 версию, она действительно самая безопасная во 2-ой линейке.

Миф третий: «обновляя в кратчайший срок скрипты, я нахожусь в безопасности».
К сожалению, ни один разработчик не может с полной уверенностью сказать, что его система безопасна на все 100% (сразу оговорюсь, что речь идет про системы с открытым кодом). В любом скрипте остаются ошибки, и не редко результатом исправления старых ошибок является появление новых.

Значит, администратору ресурса всегда надо быть в состоянии «готовности к войне», т.е. ежедневное создание бэкапов баз, аудит администраторских паролей (смена паролей хотя бы раз в полгода на администраторских аккаунтах, доступа к хостингу и т.д.), бэкапы жизненно важных конфигурационных файлов. Да это утомительно, но оно того стоит, что бы при любом форс-мажоре ресурс не лежал неделями, а был приведен в работоспособное состояние в считанные часы.

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

Миф четвертый: «людям можно доверять».
Часто администраторы не имеют навыков программирования, и им приходится просить написать модификацию у третьих лиц. Есть не чистые на руку люди, которые в модификации напишут вам, кроме основной функциональности еще и бэкдор, который вы своими же руками и поставите.

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

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

Что делать, как быть? Здесь выхода только два:

• первый писать самому с упором на безопасность, либо заказывать у умеющих людей (еще раз перечитываем четвертый миф)
• второй ставить то, что есть и молить господа Бога, что бы там не было уязвимостей. Сразу перечислю типы модификаций, для форумов, которые могут быть потенциально уязвимы:
  1. все, что добавляют новые BB коды
  2. все, что работают с механизмами авторизации и сессионными механизмами
  3. все модульные модификации, т.е. когда помимо изменений в стандартных файлах форума, добавляются собственные файлы модификаций.

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

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

1. После установки скриптов всегда удаляйте с хоста скрипты установки и обновления. Это касается не только самих скриптов, но так же и скриптов-установщиков модификаций.
2. Используйте сложные для брута пароли ( к примеру: OlVOm+c7#81, Ob%#-tH8Y-y).
3. Если регистрируетесь на других ресурсах, никогда не используйте свои администраторские пароли.
4. Подпишитесь на ежедневные рассылки security сайтов, либо используйте их RSS-фиды.
5. Если вашему ресурсу требуется несколько администраторов, то администраторскую команду подбирайте очень и очень тщательно. Это должны быть хорошо знакомые люди с опытом администрирования проектов. При таком подходе вы будем уверены, что ваш новоиспеченный администратор не поставит пароль qwert, не снесет пол проекта нажатием кнопки «удалить».
6. Если проект большой, и вы не справляетесь с его ростом, найдите технического администратора, который бы занимался только поддержкой работоспособности проекта. Требования к такому человеку должны быть жестче, чем ко всем другим администраторам. Он как минимум должен уметь читать код скриптов и разбираться в том, что они делают, иметь огромную мотивацию к развитию проекта, фактор лени должен стремиться к 20% =]
7. Пароли к хостинг-панели и FTP серверу должны быть известены только вам и вашему технику, если такой имеется.
8. Не используйте скрипты web-файл менеджеров, без особой необходимости (хотя я плохо представляю ситуацию, когда это столь необходимо. Всегда есть доступ до хоста по FTP)
9. Если вы по каким то причинам не можете контролировать свой ресурс более недели и не кому оставить его для присмотра, убирайте с сервера скрипты, осуществляющие доступ к администраторской части.
10. И возвращаясь к тому с чего начал помните 100% защиты форума от взлома не существует.