Антивзлом форума IPBoard

[wick 2]

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

[siv1987 2628]

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

[fregs 0]

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

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

 

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

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

 

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

[siv1987 2628]

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

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

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

[Одмин 42]

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

[fregs 0]

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

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

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

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

 

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

[Одмин 42]

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

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

[Одмин 42]

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

 

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

[siv1987 2628]

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

[Одмин 42]

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

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

[siv1987 2628]

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

[Одмин 42]

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

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

[siv1987 2628]

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

[Одмин 42]

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

 

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

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

 

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

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

[Одмин 42]

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

 

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

 

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

 

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

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

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

 

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

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

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

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