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

Навеяло на создание темы разговор с siv1987 о том, что всегда нужно обновляться до актуальной версии. НО! Стоит понимать, что одним обновлением мы не делаем свой форум абсолютно безопасным, всегда можно найти способ взломать форум. Начитавшись тонн разных материалов, пришел к выводу, что хакер среднего уровня (не школота) не работает импульсивно и не дергается, аки сложный подросток. Он работает по отлаженной схеме. Он не бежит искать админку с надеждой, что его туда пустят. Нет. В первую очередь надо определить CMS и желательно версию. Например, отличить 2.х от 3.х можно и внешне, имея опытный глаз, но если вебмастер использует индивидуальный дизайн, то можно определить версию обращением к одной из системных папок движка. Например, на 2.х есть папки, которых нет на 3.х и если даже к ним закрыт доступ, это уже (косвенно) говорит о той или иной версии: либо forbidden (и косвенно - есть такая папка), либо 404 (нет такой папки). То есть определить версия движка IPB можно не зная ее, даже если вебмастер визуально ее убрал. Зная версию, можно посредством разных сплоитов сломать любой двиг. Но для того, что уберечь свой форум от этих программ, нужно не только обновиться до актуальной версии, пропатчить дыры, но и соблюдать элементарную "гигиену", проще говоря - быть осторожным.

 

Я приведу несколько примеров того, как можно защитить свой форум, а здешние Гуру меня поправят если что не так (или дополнят).

Итак, мы имеем последнюю стабильную версию форума (полностью пропатченную) и вот что мы будем делать дальше:

 

1. Естественно перво-наперво закрываем от записи главный конфиг форума (CHMOD 444).

2. Далее, переименовываем папку /admin например на /manage44 или /control_q8 (как угодно , только не /admin) и желательно, творчески подойти к вопросу наименования.

3. Пароль к БД должен быть примерно таким: fO9e0o$>7!()^Diq__%4V или длиннее на порядок: вам все-равно его не вводить каждый раз, поэтому о его длине лучше позаботиться основательно, раз и навсегда надолго.

4. Переименовываем префикс к таблицам БД.

5. Права папок и файлов в корне форума не должны быть выше 700 (кроме конфига - 444). 700 хватает для полноценной работы всего форума. Проверено!

6. В корневом .htaccess (в корне форума) необходимо все ErrorDocument (403, 404...) обратить к /403.

7. В конфиге сервера необходимо запретить вывод каких-либо системных ошибок. Отчет о версии Apache и PHP не должен появляться в окне браузера НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ! Лучше сделать свои страницы ошибок.

8. Закрыть ото всех phpinfo вашего сервера (сделать доступным только для администратора).

9. Доступ к АЦ нужно ограничить только с Вашего статичного IP.

10. Служебный доступ к ftp необходимо так же ограничить только Вашим IP.

11. Пароли к админке и ftp должны быть надежными и меняться раз в месяц (квартал).

12. Все администраторы форума должны иметь несуществующие электронные почты, на которые зарегистрирован их аккаунт (для случаев взлома админских акков по почте). Зайдите в АЦ в профиль админа и сделайте ему почту, типа odmin4@google.ru.com.bot.net (такой почты, естественно не существует и confirm о смене пароля будет сливаться, что называется, в унитаз).

13. Имя и логин администраторов должны отличаться. К примеру, на форуме Ваше имя высвечивается в постах как "Админ", а в поле ввода логина Вы должны вводить сложную комбинацию цифр и букв, известную ТОЛЬКО Вам! Естественно, злоумышленник никогда не сможет ее узнать.

14. Пароли администраторов должны быть достаточно большими, но при соблюдении п. 13 (имея логин, отличный от никнейма), можно пароль иметь и поменьше.

15. В php.ini необходимо запретить следующие функции, которые после этого не будут работать на Вашем форуме. В директиве:

 

disable_functions = "exec,system,phpinfo,passthru,shell_exec,escapeshellarg,escapeshellcmd,parse_ini_file,ini_alter,dl,popen,show_source,pcntl_exec,proc_close,proc_open,proc_get_status,proc_nice,proc_terminate,symlink"

Кто-то еще запрещает eval, но не на всех версиях это можно сделать. Версия 3.2.3 полноценно работает без eval и ничего не отваливается.

16. В том же php.ini необходимо отключить display_errors = Off.

17. В том же php.ini необходимо отключить register_globals = Off.

18. На АЦ устанавливаем .htaccess-авторизацию (дополнительная защита АЦ).

19. Отключаем листинг всех директорий форума. Для этого в корневом .htaccess пишем:

Options All -Indexes

20. Принимаем дополнительные комплексные меры по защите форума. Для этого в .htaccess добавляем:

# Включаем отслеживание сим-ссылок:
Options +FollowSymLinks
# Блокируем все ссылки, содержащие <script>
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Блокируем все скрипты, которые пытаются изменить переменные PHP Globals:
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Блокируем все скрипты, которые пытаются изменить переменную _REQUEST:
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Перенаправляем все подобные на страницу с ошибкой 403 — запрещено:
RewriteRule ^(.*)$ index.php [F,L]

21. Закрываем от гостей все приложения форума, где можно что-либо ввести (какой-либо текст) в поле ввода. Все приложения должны быть доступны только пользователям.

22. Необходимо полностью запретить использование html на форуме (для всех масок), в том числе и для администраторов, за ненадобностью.

23. Создать новую группу пользователей, например "Новички" (пусть у нее будет ID: 15). Этот ID необходимо прописать в конфиге в строке:

$INFO['member_group'] = '15';

После этого все новые пользователи будут попадать в эту группу. Теперь для этой группы нужно отрубить все потенциально опасные инструменты: личку, вложения, img, полностью профиль, оставление ссылок, html (само собой) и все-все, кроме голимого текста и некоторых BB-кодов. И поставить порог перехода от "Новичков" к "Пользователям", например, 20 сообщений. Ни один кулхацкер не будет писать 20 сообщений, чтобы потом нанести какой-либо урон, который еще надо умудриться нанести.

24. Гостям форума отключить строку поиска.

25. Во всех папках форума, где нет php-файлов, необходимо установить .htaccess с соответствующим содержимым. Функция доступна в АЦ.

26. Скрыть версию форума не только визуально из подвала форума, но и из исходного кода. Функция доступна в АЦ.

27. Выдавать своим администраторам только ограниченные права на определенные разделы АЦ, а не на весь АЦ.

28. Не использовать приложения и хуки, в которых Вы не уверены.

29. Время сессии пользователей нужно, по возможности, уменьшить. Защита от перехвата.

30. Всегда наблюдайте за странной активностью на форуме. Знайте свою целевую аудиторию! Если Ваш форум - городской, то ограничьте его хотя бы пределами государства или отключите от форума страны, в которых очень много зараженных компьютеров Ботнета. Для этого в корневом .htaccess добавляем:

<IfModule mod_setenvif.c>
# Блокировка доступа странам Ю-В Азии и Африки
Deny from 3 4 6 7 8 9 11 12 13 14 15 16 17 18 19 20 21 22 24 25 26 28 29 30 32 33 34 35 38 40 41 43 44 45 47 48 51 52 53 54 55 56 57 58 59 60 61 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 140.92 140.96 140.109 140.138 163.13 163.32 180 192.192 196 202 203 210 211 214 215 218 219 220 221 222
</IfModule>

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

 

Фуф! Может чего-то и забыл, но в том-то и задумка - если у кого-то есть иные способы защиты форума от несанкционированного доступа к его ресурсам, пишите, мы обязательно это обсудим!

 

P.S. Все мысли только мои (кроме некоторых готовых решений), поэтому статья эксклюзивна для IPBSkins!

Изменено 28 февраля 201510 г пользователем Одмин

Кто-то еще запрещает eval, но не на всех версиях это можно сделать. Версия 3.2.3 полноценно работает без eval и ничего не отваливается.

К сожалению, полноценно тройка без eval работать не может. Не будут работать хуки типа Skin Overloaders (Перезагрузчик стиля), не будут работать не закешированые шаблоны, нормально не будет работать редактирование скинов в АЦ - при сохранении применяется eval для валидации шаблона, шаблон возможно и сохранится в бд, но где-то можно допустить ошибку в синтаксисе и шаблон окажется битым.

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

 

5. Права папок и файлов в корне форума не должны быть выше 700 (кроме конфига - 444). 700 хватает для полноценной работы всего форума. Проверено!

Эти цифры относительное значение. Все зависит от того, как настроен и работает web-сервер, под каким пользователем работает апач и соответственно выполняется php, кто является владельцем файлов и тд и тп. Правильнее будет говорить права на запись, чтение и выполнение, а какие это цифры зависит от конкретных настроек сервера. Права на запись должны быть только у определенных папках которые требует ipb - cache, uploads, public (конкретный список есть в документации к дистрибутиву).

Права конфига на мой взгляд преувеличены, так как с таким же успехом можно отредактировать любой файл из корня форума index.php, initdata.php. Просто нужно запрещать запись во всех статических php файлов. Зачастую права на запись у файлов убирают, а про права на папку забывают, а потом удивляются каким образом изменили файл если у него нет прав не запись. А очень просто, права на запись есть у родительской папки, поэтому cmod файла можно изменить либо с помощью функции touch, либо тупо удалив файл и пересоздав его заново (зависит от конфигурации веб сервера). Поэтому в корневую папку форума права на запись быть не должны, а файлы в которые записывает форум, обычно это xml карта сайта sitemap.xml, создаются вручную с необходимыми правами.

 

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

>1. Естественно перво-наперво закрываем от записи главный конфиг форума (CHMOD 444).

>5. Права папок и файлов в корне форума не должны быть выше 700 (кроме конфига - 444).

Устарело. Если хакер имеет файловый доступ, то ничто ему не мешает прочмодить нужные права средсnвами php

3. Пароль к БД должен быть примерно таким:

Устарело. В 99% БД закрыта снаружи и видна только локалхосту. Соотвественно брутфорсить можно только с локалхоста.

Но если у хакера есть доступ вовнутрь, то ему проще подсмотреть пароль к бд в конфиге.

 

12. Все администраторы форума должны иметь несуществующие электронные почты, на которые зарегистрирован их аккаунт (для случаев взлома админских акков по почте). Зайдите в АЦ в профиль админа и сделайте ему почту, типа odmin4@google.ru.com.bot.net (такой почты, естественно не существует и confirm о смене пароля будет сливаться, что называется, в унитаз).

Сомнительно.

13. Имя и логин администраторов должны отличаться. К примеру, на форуме Ваше имя высвечивается в постах как "Админ", а в поле ввода логина Вы должны вводить сложную комбинацию цифр и букв, известную ТОЛЬКО Вам! Естественно, злоумышленник никогда не сможет ее узнать.

Переименовать нужно и правильно. Но логин обычно легко узнать. Тем не менее от ботов это защищает, согласен.

 

 

В целом у вас реально полезнах 4-5 пунктов. Остальные либо трудозатратны и неудобны, либо невыполнимы, либо устарели лет на 10 как с правами на файлы.

Устарело. Если хакер имеет файловый доступ, то ничто ему не мешает прочмодить нужные права средсnвами php

Не совсем так. Чтобы изменять средствами php нужно чтобы были права на записи у родительской папки. И многое зависит от конфигурации веб-сервера - кто владелец файлов и как выполняется php.

 

Устарело. В 99% БД закрыта снаружи и видна только локалхосту. Соотвественно брутфорсить можно только с локалхоста.

За то на многих хостингах и панельках по умолчанию есть открытый /phpmyadmin/.

Права конфига на мой взгляд преувеличены, так как с таким же успехом можно отредактировать любой файл из корня форума index.php, initdata.php. Просто нужно запрещать запись во всех статических php файлов.

Но ведь это стандартный прием системы. Что здесь может быть сомнительного? Как Вы отредактируете (например) корневой index.php , если Вы не имеете к нему доступа?

Права 700 хватает для того, чтобы их защитить от записи. Может я ошибаюсь - поправьте.

 

К сожалению, полноценно тройка без eval работать не может. Не будут работать хуки типа Skin Overloaders (Перезагрузчик стиля), не будут работать не закешированые шаблоны, нормально не будет работать редактирование скинов в АЦ - при сохранении применяется eval для валидации шаблона, шаблон возможно и сохранится в бд, но где-то можно допустить ошибку в синтаксисе и шаблон окажется битым.

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

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

 

 

>1. Естественно перво-наперво закрываем от записи главный конфиг форума (CHMOD 444).

>5. Права папок и файлов в корне форума не должны быть выше 700 (кроме конфига - 444).

Устарело. Если хакер имеет файловый доступ, то ничто ему не мешает прочмодить нужные права средсnвами php

10. Служебный доступ к ftp необходимо так же ограничить только Вашим IP.

 

 

12. Все администраторы форума должны иметь несуществующие электронные почты, на которые зарегистрирован их аккаунт (для случаев взлома админских акков по почте). Зайдите в АЦ в профиль админа и сделайте ему почту, типа odmin4@google.ru.com.bot.net (такой почты, естественно не существует и confirm о смене пароля будет сливаться, что называется, в унитаз).

Сомнительно.

Не аргументированно!

 

 

В целом у вас реально полезнах 4-5 пунктов. Остальные либо трудозатратны и неудобны, либо невыполнимы, либо устарели лет на 10 как с правами на файлы.

Наверное, Вы либо столь самонадеяны, либо неаккуратны. В комплексе, всё способствует защите и ничем не стоит пренебрегать. Ибо по отдельности, каждый из пунктов ничтожен, но в купе - имеет неплохую протекцию (подчеркиваю - именно в купе!).

 

P.S. Уважаемые оппоненты, в целях развития темы есть нахождение иных способов закрытия уязвимостей, поэтому помимо конструктивной критики хотелось бы получить взамен еще что-либо полезное (познавательное/неустаревшее) для защиты наших ресурсов. Те, кто утверждают, что данные методы защиты устарели/бесполезны, могут привести свои решения...

Дискуссию можно долго продолжать, но за первый пост спасибо. Много новичков пренебрегают советам и всегда думают, что все будет Ок, а потом подымают панику, что их взломали, и не только новички. +

Как Вы отредактируете (например) корневой index.php , если Вы не имеете к нему доступа?

Права 700 хватает для того, чтобы их защитить от записи. Может я ошибаюсь - поправьте.

Я (шелл на сервере) - php. Поэтому все зависит от ого как запускается php, как настроен веб-сервер и какие права стоят на папках/файлах. Прямо может быть я и не смогу отредактировать файл, но при наличие прав я могу изменить chmod или удалить файл и пересоздать его заново.

Вы говорите о своем конкретном окружении. Говорить о правах 700, это тоже самое что говорить - хватает 1000 долларов чтобы быть счастливым. Кому-то хватит, а кому-то нет. Конкретные права доступа зависит от настроек системы.

@siv1987, если тема будет востребована, Вы как администратор можете ее закрепить в разделе. Я буду ее пополнять (чтобы она не ушла в забытие)... ;)

 

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

 

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

 

Я (шелл на сервере) - php. Поэтому все зависит от ого как запускается php, как настроен веб-сервер и какие права стоят на папках/файлов. Прямо может быть я и не смогу отредактировать файл, но при наличие прав я могу изменить chmod или удалить файл и пересоздать его заново.

Вы говорите о своем конкретном окружении. Говорить о правах 700, это тоже самое что говорить - хватает 1000 долларов чтобы быть счастливым. Кому-то хватит, а кому-то нет. Конкретные права доступа зависит от настроек системы.

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

Еще про eval. Он применяется и для настроек типа "мултивыбор", где выполняется пользовательский php. Так что эти настройки также работать не будут. В 3.4x это примерно ~55 настроек. Имхо, пусть пользователи ничего и не замечают, но нормально администрировать форум без него не возможно.

@siv1987, Вы верно подметили:

 

эти настройки также работать не будут. В 3.4x это примерно ~55 настроек.

Но в 3.2.3 это не критично.

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

Для эффективной защиты это нужно знать и понимать. Многое кроется именно в мелочах.

Не совсем так. Чтобы изменять средствами php нужно чтобы были права на записи у родительской папки. И многое зависит от конфигурации веб-сервера - кто владелец файлов и как выполняется php.

 

 

За то на многих хостингах и панельках по умолчанию есть открытый /phpmyadmin/.

1. Мне по работе приходится регулярно иметь дело с чужими сайтами\вебсерверами. В 99% случаев сервер настроен так что у скрипта есть возможность чмодить папку\файл. И причина тому есть, это требуется для нормальной работы кеша\шаблонизации во многих популярных CMS

2. Да, но на него нужно еще получить ссылку. Чаще всего его нет в дефолтной папке. Т.е. брутфорс маловероятен.

И не забывайте что брутфорс в случае mysql ведется по паре.

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

Не аргументированно!

 

 

Наверное, Вы либо столь самонадеяны, либо неаккуратны. В комплексе, всё способствует защите и ничем не стоит пренебрегать. Ибо по отдельности, каждый из пунктов ничтожен, но в купе - имеет неплохую протекцию (подчеркиваю - именно в купе!).

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

 

У вас неверно главное утверждение. "всё способствует защите и ничем не стоит пренебрегать ...по отдельности, каждый из пунктов ничтожен"

Самый эффективный из способов защиты указаный у вас, это переименование админки

Второй, смена логина админа.

Третий сложный пароль.

К ним я бы добавил всего 1 пункт, нулевой, который вы не указали

 

В итоге.

0. следить за обновлением CMS и плагинов к ней. Это самый важный пункт безопасности. Более важный чем все что вы перечислили. 80% взломов делаются через уязвимости ядра и плагинов. И лишь 15% через алминку и против них уже направлены вышеуказанные 2 пункта с переименованием админки\логина.

1. переименование админки

2. смена логина админа

3. сложный пароль.

 

Всего 4 эти пункта безопасности защитят вас от 95% взломов. А все остальное в лучшем случае от 0.1%. Оставшиеся 4.9% взломов это 0-day, социальная инженерия и т.п. Эффективной защиты от них нет.

В 99% случаев сервер настроен так что у скрипта есть возможность чмодить папку\файл.

Значит права на папки не правильно настроены. Или все находится под одним пользователем. На шаред хостингах обычно так и бывает.

 

 

 

Да, но на него нужно еще получить ссылку. Чаще всего его нет в дефолтной папке. Т.е. брутфорс маловероятен.

Чаще всего он именно там и находится. Даже по памяти могу назвать пару крупных хостингах.

Самый эффективный из способов защиты указаный у вас, это переименование админки

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

 

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

- брутфорсе

- утечке админской сессии/пароля.

При этом надо еще не забыть убрать ссылку из публичной части.

как удалить ссылку на ац из пользовательской части форума?