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

Навеяло на создание темы разговор с 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 г пользователем Одмин

Настройки безопасности > Убрать ссылку на АЦ с форума?

Приведу реальный случай

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

 

95% взломов сейчас это взломы через ботсети. А ломают боты по типичным стратегиям. Чаще всего их 2: уязвимости цмс, брутфорс админки.

Переименование админки поможет как раз против бот сетей, против брута админки, бот не станет искать админку в другом месте. Бот просто пойдет ломать другой сайт.

 

Т.е. этот способ как раз очень эффективен и как раз против массовых взломов.

Ваш реальный случай единичен, поскольку относится к ручному взлому.

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

Переименование админки имеет свои плюсы, но нужно подходить с умом, и не считать ее панацеей даже при массовом взломе.

@fregs, если я Вас правильно понял, 27 из 30 пунктов, с Вашей точки зрения, имеют важность - 0,1%? :D То есть ограничение доступа к FTP и АЦ только с Вашего статичного IP - не имеет для Вас особого значения? А вот по мне, так ограничив доступ к АЦ с моего статичного IP, можно вообще не менять название админки. Злоумышленник не получит доступ к АЦ ни при каких обстоятельствах со своего IP и проблемы с брутфорсом и создание злоумышленником в базе своего админа для проникновения в АЦ - уже не представляют опасности именно для админки. И в то же время злоумышленник не сможет убрать запрет по IP по одной простой причине - у него не будет доступа к FTP, ибо доступ к нему разрешен тоже только со статичного IP.

@fregs,А вот по мне, так ограничив доступ к АЦ с моего статичного IP, можно вообще не менять название админки.

Мало где это возможно. У меня айпи динамический, хоть и меняется редко.

У кого то доступ нужен на несколько человек.

И это частая ситуация.

 

Поэтому смена админки более эффективна, потому что возможна практически в 100% случаев.

Поэтому смена админки более эффективна

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

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

 

В общем, хотелось бы узнать как заливаются шеллы на FTP? Злоумышленник, как правило, использует сплоит для вашей версии форума. Следовательно, процесс автоматический и в большинстве случаев, школота не прилагает умственных усилий для взлома форума. Тогда получается в сплоите уже априори встроена функция по заливке шеллов в самые незащищенные папки - это /cache/, /hooks/, /public/ и /uploads/. А что если нам сменить названия этих папок? Как тогда будет вести себя программа-взломщик? К примеру, /public/ можно сменить через initdata.php (на новых версиях - init.php). На счёт других папок я не уверен, но если есть в этом смысл, и если это остановит бота-взломщика, то имеет ли смыл копать в этом направлении?

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

Если есть возможность заливать шелл там наверняка доступны системные переменные в которые хранятся пути ко всем папкам.

А если открыть доступ к FTP через .ftpaccess только с моего статичного IP, как по-другому можно залить шелл? Доступ к АЦ хостинга тоже закрыт посредством IP. Получается только через взлом сайтов на этом же сервере? Но опять же если каждый аккаунт завязан на отдельном пользователе, как можно править чужие сайты, взломав сайт на этом же сервере?

Шеллы не только через фтп загружаются, скорее наоборот, если есть доступ к фтп он не особо и нужен, хотя закладки все равно оставляют как бэкдор в случае замены пароля. Через уязвимости в ПО сервера; через уязвимости на форуме - некоторые требует доступа в АЦ, некоторые нет; через утечку админских данных и тд и тп. Вы ищите таблэтку от всех болезней - нет ее, в этой теме уже не раз говорилось. Ограничения по фтп не дает гарантий что не взломают другим способом где оно не требуется, но оно поможет в случае если украли доступ к фтп (был известный вирус который любил тырить пароли из total commander и других фтп клиентов).

через уязвимости на форуме - некоторые требует доступа в АЦ, некоторые нет; через утечку админских данных

А толку что тырить админские данные, если в АЦ не зайти с другого IP? Вот к чему я веду всё это... Если все пути доступа (FTP, АЦ, ПУ хостинга) перекрыть своим IP, то злоумышленнику в сторону уязвимости этих путей можно вообще не копать. А если еще придумать такой способ, чтобы администраторы могли логиниться на форуме только со разрешенного статичного IP, то проблему с кражей админских паролей можно вообще отложить в долгий ящик.

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

ну не считая тех неприятностей которые он может доставить на форуме

 

администраторы могли логиниться на форуме только со разрешенного статичного IP

Я сейчас как раз размышляю на тему, как организовать логику работы этого ограничения. Скорее всего, это должно выглядеть примерно так: ограничение распространяется только на пользователей группы с ID: 4; пользователь пытается залогиниться на форуме, программа проверяет ID его группы и IP. Если ID группы не равен "4", IP не проверяется (не имеет смысла дальнейшей проверки) и пользователь проходит обычную авторизацию на правах обычного пользователя. Если ID группы = 4, проверяется IP адрес пользователя-администратора и если IP адрес = разрешенному IP адресу (при условии, что правильно введены логин и пароль), администратор успешно авторизуется на форуме. В противном случае, система выдает стандартное сообщение "Логин и пароль не верны".

 

Если реализовать данное решение, то любые кражи администраторских паролей будут чьей-то смешной бессильной попыткой кражи. А смешной потому, что вроде как злоумышленнику известны логин и пароль администратора, а применить их в действии он не может. К тому же решение это нестандартное (не имеет отношения к стандартному движку IPB), поэтому злоумышленник 100 раз сломает себе голову, прежде чем что-либо придумает, а вероятнее всего просто психанёт и уйдёт ломать другой ресурс (более податливый его инструментам).

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

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

 

1. Пользователь нажимает "Вход" -> появляется форма входа (либо страница входа).

 

2. Пользователь в форму входа вводит свои логин и пароль -> нажимает "Вход".

 

3. Проверяется ID группы пользователя:

3.1. Если ID != 4 (и при условии, что логин и пароль верны), пользователь успешно авторизуется;

3.2. Если ID == 4, -> переходим к п. 4.

 

4. Проверяется IP пользователя:

4.1. Если IP != разрешенному IP, выводится ошибка "Логин и пароль не верны" (даже при условии, что логин и пароль верны);

4.2. Если IP == разрешенному IP (и при условии, что логин и пароль верны), пользователь-администратор успешно авторизуется.

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

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

Самое лучшее средство от кражи паролей от FTP из ftp-клиентов, а также от кражи при переборе паролей от FTP - это временное создание подобных аккаунтов для единовременных операций на диске! Т.е. на хостинге создается ftp-акк, проводится операция и акк закрывается. Каждый раз необходимо использовать разные случайно сгенерированные пароли, тогда по FTP взлом исключен! Как только операция проведена (например, залиты патчи), - ftp-акк удаляется и мы перекрываем потенциальную уязвимость форума посредством взлома форума через FTP.

 

P.S. К слову говоря, я априори не понимаю, для чего необходим постоянно открытый ftp-акк на хостинге, если этим акком пользуемся не каждый день... К тому же открыть такой акк для форума и сгенерировать к нему на хостинге пароль - 5 секунд... никаких проблем... А до тех пор (до востребования) иметь открытый акк, ведущий к папке форума - не совсем правильно и с точки зрения обсуждения данной темы - не кошерно. Спасибо.