FreeHost.com.UA
Сентября 22, 2017, 12:11:43 am *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.

Войти
Новости: Распродажа серверов http://freehost.com.ua/forum/index.php?topic=2093.0
 
   Начало   Помощь Поиск Войти Регистрация  
Страниц: [1] 2 3 4
  Печать  
Автор Тема: Масовые взломы акаунтов - почему они происходят?  (Прочитано 15767 раз)
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« : Октября 31, 2011, 07:29:12 pm »

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

Причина первая - и самая популярная - клиент не следит за changelog-ами и обновлениями используемой CMS.
Уязвимости в joomla, DLE, phpMyAdmin и т.д находят постоянно, поэтому если вы заботитесь о том, чтобы ваши сайты на готовых CMS работали и не были взломаны - хотя бы 2 раза в месяц проверяйте новости на официальном сайте CMS.

Причина вторая - неверные права доступа на файлы и каталоги.
Очень многие клиенты устанавливают права доступа рекурсивно 777. Рекомендуется ознакомиться с тем, что значат данные права:
http://www.tux.in.ua/articles/305 - информация о системе прав в юникс.
Вкратце: права 777 дают полный доступ на чтение, запись и выполнение _всем_. Ни о какой безопасности в таком случае речь идти не может. Если вы хотите значительно уменьшить вероятность взлома акаунта - установите на каталоги 755, а на файлы 644. Это защитит вас даже от тех уязвимостей движка, которые еще не найдены и не описаны на сайте разработчика, т.е от потенциальных дыр. Правильно выставленые права доступа - это залог спокойного сна и программиста, и владельца сайта.

Причина третья - доступ по FTP с инфицированых вирусом машин.
Существует категория вирусов, которые собирают вводимые на машине пароли FTP, затем используют их для модификации файлов на FTP-сервере и добавления туда вирусного кода. Тут не поможет ни обновленная CMS, ни правильные права доступа - владелец хостинг-акаунта всегда имеет права записи по FTP. Поможет тут обновленный хороший антивирус на всех машинах, откуда производится FTP-доступ. Для надежности вы можете в админпанели ограничить доступ по FTP только с довереных адресов. Сделайте это.
Фактически соблюдение этих 3 пунктов сводит к минимуму риск того, что ваши сайты будут взломаны.
Enjoy Улыбающийся
« Последнее редактирование: Октября 31, 2011, 11:15:56 pm от Komintern » Записан

Lucy in the Sky with Diamonds
akok
Newbie
*

Karma: 0
Сообщений: 15


Просмотр профиля WWW
« Ответ #1 : Ноября 01, 2011, 02:16:00 pm »

Еще бы статью, о том, что делать если таки взломали Улыбающийся и о бекапах обязательно.

Записан
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #2 : Ноября 01, 2011, 02:25:44 pm »

Еще бы статью, о том, что делать если таки взломали Улыбающийся и о бекапах обязательно.

Если таки взломали, то во-первых можно написать на support@freehost.com.ua, и мы восстановим сайт из резервной копии.
После восстановления _обязательно_ проделать вышеуказаные пункты - обновить CMS, установить 755 рекурсивно на все каталоги и 644 рекурсивно на все файлы и ограничить доступ на FTP только с довереных ip.
Записан

Lucy in the Sky with Diamonds
seavolf
Newbie
*

Karma: 0
Сообщений: 1


Просмотр профиля
« Ответ #3 : Ноября 01, 2011, 06:07:38 pm »

А как рекурсивно выставить права на все файлы? С каталогами понятно, а вот с файлами не могу разобраться как это сделать.
Записан
мережевий хробачок™
Sr. Member
****

Karma: 3
Сообщений: 309



Просмотр профиля
« Ответ #4 : Ноября 01, 2011, 10:25:16 pm »

Еще бы статью, о том, что делать если таки взломали Улыбающийся и о бекапах обязательно.
установить 755 рекурсивно на все каталоги и 644 рекурсивно на все файлы.

Не всегда и не везде можно ставить 755. Много где для корректной работы ЦМС требуется на некоторые (!) каталоги устанавливать именно 777, например папки uploads.
Ну а в целом, да, все верно. И вообще - статья полезная и нужная, Андрею - СПАСИБО.
Записан
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #5 : Ноября 02, 2011, 12:15:40 am »

А как рекурсивно выставить права на все файлы? С каталогами понятно, а вот с файлами не могу разобраться как это сделать.

Напишите в техподдержку просьбу исправить права доступа, они сделают.
Записан

Lucy in the Sky with Diamonds
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #6 : Ноября 02, 2011, 12:17:50 am »

Еще бы статью, о том, что делать если таки взломали Улыбающийся и о бекапах обязательно.
установить 755 рекурсивно на все каталоги и 644 рекурсивно на все файлы.

Не всегда и не везде можно ставить 755. Много где для корректной работы ЦМС требуется на некоторые (!) каталоги устанавливать именно 777, например папки uploads.
Ну а в целом, да, все верно. И вообще - статья полезная и нужная, Андрею - СПАСИБО.

На новых серверах (s11-s26), где http-процессы работают от владельца хостинг-акаунта, нужно именно 755 и 644.
На остальных рекомендуется на тот же uploads выставить владельцем пользователя, а группу www и права 775, на файлы 664, типа так:
Код:
drwxrwxr-x   2 komi  www      12288 Nov  1 22:55 cache
Но уж никак не 777 на все. Вообще к расстановке прав доступа нужно очень внимательно относиться.

Еще хочется сказать пару слов насчет кеширования в CMS. Во многих статьях по оптимизации рекомендуют включать кеширование. Это не всегда оправдано и не всегда ведет к приросту производительности.
Суть такова - кешируются запросы и некоторый контент в определенную директорию, которая со временем вырастает до необьятных размеров, а количество файлов в ней измеряется десятками тысяч - говорю из опыта т.к видел примеры. Так вот, запрос к MySQL в таком случае выполнится гораздо быстрее, чем вытянутся из подобного "кеша" данные не первой свежести. Либо очищайте кеш регулярно по крону, либо просто не включайте его.
« Последнее редактирование: Июля 17, 2012, 01:23:25 pm от Komintern » Записан

Lucy in the Sky with Diamonds
allprices
Full Member
***

Karma: -3
Сообщений: 100

614799
Просмотр профиля WWW
« Ответ #7 : Ноября 02, 2011, 02:43:53 am »

Самая большая проблема по 1 пункту - это использование нелиц. софта, дырки не закрыты.
Пример: Прогоните всех клиентов (таблица jb_board в базе) .. подбор пароля займет макс 1 день и доступ открыт.

2 причина. в мануалах всегда все описано: что и как ставить права.. (основная причина)

3 причина нефиг сохранять пароли в браузераз, тоталах, фтп клиентах. (основная причина)
Записан

http://allprices.com.ua - Предприятия, товары, объявления Украины.
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #8 : Ноября 02, 2011, 08:46:09 am »

Если бы кто-то еще читал эти мануалы Улыбающийся
Записан

Lucy in the Sky with Diamonds
AMBA
Hero Member
*****

Karma: 2
Сообщений: 955



Просмотр профиля E-mail
« Ответ #9 : Ноября 02, 2011, 02:03:12 pm »

Ну вот у меня на днях, залочили один сайт за то что он досит кого-то там. Полез смотреть, да, подложили в пару файлов сайта (при том что сайт по вебу не работает, есть только редирект на форум) шел, и в пару папок скрипты для удалённой атаки. Прошу сапорт, мол дайте логи по доступу на фтп за последние несколько дней. Ответ, файлы заливались не по фтп. И так и не выложили.

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

Цитировать
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 2097123 bytes) in /usr/local/www/docroot/uhtq/getftplog.php on line 15

Причём я в эти дни по фтп с сайтом точно не работал. Также и Access логи просил за последние пару дней по вебу, тоже проигнорили. И на вопрос небыло ли аналогичных случаев у соседей на s11, и не пролезли ли где-то на уровне сервера, тоже не ответили. Значит у меня нет причин сбрасывать и такой вариант со счетов. И как с такой поддержкой искать и закрывать дырку по горячим следам?
Не надо косить только на мануалы, взлом аккаунта это помоему достаточно серьёзный повод чтобы сапорт способствовал пользователю в поиске и устранении причин.
Записан
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #10 : Ноября 02, 2011, 03:20:10 pm »

AMBA, какая CMS использовалась на сайте?
Какие права стояли на каталоги, куда были залиты скрипты?
Взломано было достаточно много акаунтов, что привело к возникновению слухов, что "к серверам freehost был получен root-доступ злоумышленниками". Слухи эти ничем не подтверждены и полностью неправдивы, последствия такого явления были бы гораздо больше, чем взлом ~20-30 сайтов из более чем 1000 размеенных на сервере.
90% вероятности, что на каталоги, куда были залиты скрипты, стояли права 777, и скрипты скорее всего были залиты через веб-шелл.
Как и когда был залит шелл - не знает никто, если техподдержка сказала что в FTP-логах (они хранятся у нас за неделю) информации нет - значит вероятнее всего шелл залили давно и не только вам.
Записан

Lucy in the Sky with Diamonds
AMBA
Hero Member
*****

Karma: 2
Сообщений: 955



Просмотр профиля E-mail
« Ответ #11 : Ноября 02, 2011, 04:20:25 pm »

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

Про слухи о том что взломано 20-30 сайтов я не слышал, я лишь предполагал разные варианты. Но согласитесь, 20-30 сайтов на одном сервере одновременно, очень не похоже на совпадение. Ломать 20 сайтов на одном сервере целенаправленно, ну это по крайней мере странно. Самое вероятное через что могли пролезть ко мне это форум phpBB. На других взломанных аккаунтах стоял этот скрипт?

Да, на файлы и папки которые были изменены и в которые лились посторонние скрипты были права 777, но я думаю что узнать про них и самое главное писать в них, не залив предварительно как-то шелл и не просканировав хост, нереально.
Насколько я успел по диагонали почитать инфо о том шеле который закинули мне, то это один из самых популярных и функциональных, кроме того у него существуют модификации для работы с суидниками. Я не линуксоид, поэтому сразу прошу прощения есмли прогоню в чём-то, но насколько я понял у них есть возможность править первый байт чи бит файла, отвечающий за доступ, таким образом организовывая исполнение файла не от имени пользователя который этот файл создавал, а от имени апача или даже рута. Возможно взломав какой-то один сайт на сервере, они нашли возможность сканировать папки соседних хостов, и найдя у них каталоги/файлы с правами 777 смогли туда что-то дозаписывать. Советую всё же внимательнее изучить возможность перепрыгивания злоумышленников с какого-то из хостов на соседние, надо это исключить, ибо избавиться на 100% от файлов и папок с 777 просто невозможно.

P.S. От меня кстати ддосили какой-то turnitupnowдотnet.
« Последнее редактирование: Ноября 02, 2011, 04:44:51 pm от AMBA » Записан
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #12 : Ноября 02, 2011, 04:43:29 pm »

Цитировать
Самое вероятное через что могли пролезть ко мне это форум phpBB. На других взломанных аккаунтах стоял этот скрипт?

Да, почти все недавно взломаные акаунты использовали либо Joomla либо phpBB.

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

Тут использовался тупой метод проб и ошибок. Бот нашел большой список сайтов с определенными CMS и применил к ним автоматизированый эксплойт. Все, которые оказались уязвимыми - получили шелл. Потом опять же автоматом другой бот позаливал через этот шелл скрипты для спама и ддос-а.

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

Понятия не имею что за первый байт или бит вы имеете ввиду, но SUID тут точно не при чем, тем более SUID-бит не устанавливается на скрипты, он устанавливается только на бинарники и только root-ом.
Если вы имеете ввиду chown, то при правах 777 он не имеет никакого смысла, т.к писать в каталог может любой пользователь, независимо владелец он каталога или нет.
Записан

Lucy in the Sky with Diamonds
AMBA
Hero Member
*****

Karma: 2
Сообщений: 955



Просмотр профиля E-mail
« Ответ #13 : Ноября 02, 2011, 05:07:05 pm »

Ну да наверное речь шла как раз о том, чтобы через этот вебшел ломать сервер более серьёзно.

Цитировать
Установленный suid-бит позволяет выполнять файл от имени владельца файла, а не текущего юзера. Т.е. если дать суиднику права root'a, то можно будет выполнять команды от имени root'a с любого юзера.

Описанная вами схема понятна, а по логам нельзя установить что за дыру использовали, ведь наверняка бот работал с одного ip который вычислить не сложно, и соответственно отследить всё что он делал.

Хуже всего что у меня стоит самая свежая версия форума, и никаких заплаток новых не видно на данный момент.
Записан
Komintern
FreeHost
*****

Karma: 9
Сообщений: 417


Админ


Просмотр профиля WWW
« Ответ #14 : Ноября 02, 2011, 05:15:35 pm »

Описанная вами схема понятна, а по логам нельзя установить что за дыру использовали, ведь наверняка бот работал с одного ip который вычислить не сложно, и соответственно отследить всё что он делал.

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

Установить пытаемся, но в приоритете задача не допустить подобного впреть, в связи с чем и была создана эта тема.
Свежая версия форума - это отлично, но опять же - была ли она самой свежей в тот момент (который был неизвестно когда), когда заливали шелл. Он мог лежать месяцами без использования, а потом по набору нужного количества инфицированых акаунтов каждый паразитный скрипт получил команду начать свою активность.
Никто же из владельцев акаунтов не проверяет - не появился ли случаем левый файл в каталоге uploads.
Вот именно из-за подобных инцидентов рекомендуется выставлять правильные права и ограничивать доступ на FTP с довереных айпи.
Записан

Lucy in the Sky with Diamonds
Страниц: [1] 2 3 4
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2006-2011, Simple Machines Valid XHTML 1.0! Valid CSS!