Comments 95
Мне кажется, что просто взят какой-то, около-случайный шаблон ОС, которых валяется по всему Интернету масса, проверен просто на предмет успешного импорта и все. Проблема может быть вовсе не в сотруднике. А в настройке сервиса по принципу «лишь бы работало», без процедур QA.
По принципу «лишь бы работало», серьезно? Я же не у дяди Пети сервера арендую, а у крупной компании, которая за последний год стала достаточно популярна в России. Как можно подвергать тысячи клиентов такому риску?
Уязвимость устранена сегодня в 12:08.
Мы подтверждаем факт обнаружения в одном из наших шаблонов (ОС Debian 8.7) пользовательской учётной записи, с недостаточно крипто защищённым паролем. В следствии чего данный пароль был взломан злоумышленником и в дальнейшем использован при подключении к серверам, созданным из уязвимого шаблона. Эта версия шаблона была опубликована 30.07.2018. Все клиенты, которые использовали указанную версию шаблона, к настоящему времени оповещены о выявленной уязвимости, и приняты меры по её устранению.
Уязвимости был подвержен 1 из наших 18 шаблонов.
Количество пострадавших серверов: менее 50 шт.
Сразу после обнаружения источника проблемы этот шаблон был незамедлительно выведен из эксплуатации. Все остальные публичные шаблоны виртуальных машин проверены на наличие подобной уязвимости.
Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.
Предпринятые действия:
1. Уязвимость устранена в шаблоне Debian 8.7
2. Проводится дополнительная проверка все остальных шаблонов на предмет других уязвимостей по безопасности
3. Будет доработана процедура автоматической проверки «золотых» шаблонов на наличие данной ошибки и других уязвимостей по безопасности.
4. Будет проведены работы с сотрудниками поддержки для недопущения повторения подобных сценариев взаимодействия с Клиентами
Приносим свои глубочайшие извинения нашим настоящим и будущим клиентам за возникший инцидент. Мы приложим максимум усилий для исключения возможности возникновения подобных ситуаций в дальнейшем.
Мы планируем предоставить более подробный отчет об устранении данной проблемы и о предпринятых мерах в отдельной статье в нашем блоге.
Выражаем благодарность пользователю egorbI4 за извещение о серьёзной проблеме, конструктивную критику и взаимодействие!
Мы подтверждаем факт обнаружения в одном из наших шаблонов (ОС Debian 8.7) пользовательской учётной записи, с недостаточно крипто защищённым паролем. В следствии чего данный пароль был взломан злоумышленником и в дальнейшем использован при подключении к серверам, созданным из уязвимого шаблона. Эта версия шаблона была опубликована 30.07.2018. Все клиенты, которые использовали указанную версию шаблона, к настоящему времени оповещены о выявленной уязвимости, и приняты меры по её устранению.
Уязвимости был подвержен 1 из наших 18 шаблонов.
Количество пострадавших серверов: менее 50 шт.
Сразу после обнаружения источника проблемы этот шаблон был незамедлительно выведен из эксплуатации. Все остальные публичные шаблоны виртуальных машин проверены на наличие подобной уязвимости.
Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.
Предпринятые действия:
1. Уязвимость устранена в шаблоне Debian 8.7
2. Проводится дополнительная проверка все остальных шаблонов на предмет других уязвимостей по безопасности
3. Будет доработана процедура автоматической проверки «золотых» шаблонов на наличие данной ошибки и других уязвимостей по безопасности.
4. Будет проведены работы с сотрудниками поддержки для недопущения повторения подобных сценариев взаимодействия с Клиентами
Приносим свои глубочайшие извинения нашим настоящим и будущим клиентам за возникший инцидент. Мы приложим максимум усилий для исключения возможности возникновения подобных ситуаций в дальнейшем.
Мы планируем предоставить более подробный отчет об устранении данной проблемы и о предпринятых мерах в отдельной статье в нашем блоге.
Выражаем благодарность пользователю egorbI4 за извещение о серьёзной проблеме, конструктивную критику и взаимодействие!
а с какой целью вообще добавляли левого пользователя в шаблон?
В процессе установки Debian нельзя пропустить шаг создания непривилегированного пользователя.
Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.
Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.
можно, если выбирать экспертную установку
Судя по всему тестили новую сборку, и во время тестов сделали временного пользователя user:123 (условно). Но удалить из финалки его забыли, пустили в прод.
Ушлый хацкер увидел в дефолтной сборке уже существуюего пользователя, выкачал его хэш и забрутфорсил пароль, после чего открылся доступ к любому серверу на этой ОС. Раз в сутки сканировал подсеть на наличие новых серверов, и заражал их.
При расследовании очень быстро нашли "виновных" — спосили "Сашу и Петю", и они вспомнили что действительно при тестах всегда ставят пароль 123. Вот и сказке конец, расследование закончено.
ПС: это мое личное мнение как всё было, в стиле Шерлок.
Ушлый хацкер увидел в дефолтной сборке уже существуюего пользователя, выкачал его хэш и забрутфорсил пароль
Никто никакой хэш не выкачивал, 22-й порт всего интернета непрерывно сканируется червями-майнерами на предмет наличия пользователей типа admin/user/test с паролями типа 123456, 123qwe!@#, и прочей дичью. Автор об этом тоже писал, если вы заметили.
Нет, там всего 6 попыток авторизации. Причем вход под user — с первой попытки. Брутфорсить через ssh гораздо дольше и затратнее (ты не знаешь, есть ли такая учетка вообще, после скольки попыток ты попадешь в бан, итд), чем брутфорсить хэш пароля локально, никто ничего даже не увидит.
Плюс вы невнимательно прочитали тему — такой юзер уже был во всех сборках. А значит хацкер просто арендовал когда то такой же сервер и нашел эту учётку, и подобрал пароль к ней. Потом уже он начал ходить в гости к остальным…
Плюс вы невнимательно прочитали тему — такой юзер уже был во всех сборках. А значит хацкер просто арендовал когда то такой же сервер и нашел эту учётку, и подобрал пароль к ней. Потом уже он начал ходить в гости к остальным…
Вы не поняли. Никто ничего не брутфорсит. Перебирается просто несколько фиксированных паролей к нескольким учёткам. Это никак не зависит от того, есть ли юзер в сборках, арендовал ли хакер сервер, и подобрал ли к ней пароль. Я даже больше скажу, эти же пароли и логины подбираются к виндовым серверам с подключением через RDP. Вы можете легко это проверить, выставьте в интернет порт 22 или 3389, и через пару часов увидите в логе попытки подключения от тех же самых пользователей.
Специально для вас дёрнул лог:
Aug 23 20:12:25 43602 sshd[6711]: Invalid user user from 121.124.124.73
Aug 23 20:12:31 43602 sshd[6713]: Invalid user admin from 121.124.124.73
Aug 23 20:12:37 43602 sshd[6715]: Invalid user test from 121.124.124.73
Aug 23 20:12:54 43602 sshd[6721]: Invalid user osmc from 121.124.124.73
Aug 23 20:13:14 43602 sshd[6723]: Invalid user odroid from 121.124.124.73
Aug 23 20:13:19 43602 sshd[6725]: Invalid user admin from 121.124.124.73
Aug 23 20:13:32 43602 sshd[6729]: Invalid user james from 121.124.124.73
Aug 23 20:13:48 43602 sshd[6733]: Invalid user admin from 121.124.124.73
Aug 23 20:13:57 43602 sshd[6735]: Invalid user admin from 121.124.124.73
Aug 23 20:14:45 43602 sshd[6742]: Invalid user mobile from 121.124.124.73
Aug 23 20:14:54 43602 sshd[6744]: Invalid user nagios from 121.124.124.73
Aug 23 20:15:00 43602 sshd[6746]: Invalid user scanner from 121.124.124.73
Aug 23 20:15:05 43602 sshd[6748]: Invalid user backup from 121.124.124.73
Aug 23 20:15:12 43602 sshd[6750]: Invalid user zabbix from 121.124.124.73
Aug 23 20:15:24 43602 sshd[6752]: Invalid user pi from 121.124.124.73
Aug 23 20:15:31 43602 sshd[6754]: Invalid user ubnt from 121.124.124.73
Aug 23 20:15:42 43602 sshd[6758]: Invalid user admin from 121.124.124.73
Aug 23 20:15:53 43602 sshd[6760]: Invalid user debian from 121.124.124.73
Aug 23 20:16:05 43602 sshd[6762]: Invalid user 1234 from 121.124.124.73
Aug 23 20:16:11 43602 sshd[6764]: Invalid user ftpuser from 121.124.124.73
Aug 23 20:16:17 43602 sshd[6766]: Invalid user guest from 121.124.124.73
Aug 23 20:16:23 43602 sshd[6768]: Invalid user user from 121.124.124.73
Aug 23 20:16:35 43602 sshd[6772]: Invalid user ftpuser from 121.124.124.73
Aug 23 20:16:41 43602 sshd[6774]: Invalid user admin from 121.124.124.73
Aug 23 20:16:47 43602 sshd[6776]: Invalid user mysql from 121.124.124.73
и т.д., и т.п.
Aug 23 20:12:25 43602 sshd[6711]: Invalid user user from 121.124.124.73
Aug 23 20:12:31 43602 sshd[6713]: Invalid user admin from 121.124.124.73
Aug 23 20:12:37 43602 sshd[6715]: Invalid user test from 121.124.124.73
Aug 23 20:12:54 43602 sshd[6721]: Invalid user osmc from 121.124.124.73
Aug 23 20:13:14 43602 sshd[6723]: Invalid user odroid from 121.124.124.73
Aug 23 20:13:19 43602 sshd[6725]: Invalid user admin from 121.124.124.73
Aug 23 20:13:32 43602 sshd[6729]: Invalid user james from 121.124.124.73
Aug 23 20:13:48 43602 sshd[6733]: Invalid user admin from 121.124.124.73
Aug 23 20:13:57 43602 sshd[6735]: Invalid user admin from 121.124.124.73
Aug 23 20:14:45 43602 sshd[6742]: Invalid user mobile from 121.124.124.73
Aug 23 20:14:54 43602 sshd[6744]: Invalid user nagios from 121.124.124.73
Aug 23 20:15:00 43602 sshd[6746]: Invalid user scanner from 121.124.124.73
Aug 23 20:15:05 43602 sshd[6748]: Invalid user backup from 121.124.124.73
Aug 23 20:15:12 43602 sshd[6750]: Invalid user zabbix from 121.124.124.73
Aug 23 20:15:24 43602 sshd[6752]: Invalid user pi from 121.124.124.73
Aug 23 20:15:31 43602 sshd[6754]: Invalid user ubnt from 121.124.124.73
Aug 23 20:15:42 43602 sshd[6758]: Invalid user admin from 121.124.124.73
Aug 23 20:15:53 43602 sshd[6760]: Invalid user debian from 121.124.124.73
Aug 23 20:16:05 43602 sshd[6762]: Invalid user 1234 from 121.124.124.73
Aug 23 20:16:11 43602 sshd[6764]: Invalid user ftpuser from 121.124.124.73
Aug 23 20:16:17 43602 sshd[6766]: Invalid user guest from 121.124.124.73
Aug 23 20:16:23 43602 sshd[6768]: Invalid user user from 121.124.124.73
Aug 23 20:16:35 43602 sshd[6772]: Invalid user ftpuser from 121.124.124.73
Aug 23 20:16:41 43602 sshd[6774]: Invalid user admin from 121.124.124.73
Aug 23 20:16:47 43602 sshd[6776]: Invalid user mysql from 121.124.124.73
и т.д., и т.п.
А при чем тут ваш лог непонятно откуда, и как он связан с конкртно этим случаем в статье? Да, я знаю, что есть такие боты, которые стучатся, да, мы все их давным давно наблюдаем.
Но посмотрите логи выше в статье, там пользователь USER входит с 1й попытки:
Aug 20 03:47:31 debian8x64 sshd[1346]: Accepted password for user from 219.135.136.144 port 56492 ssh2
Это значит, что:
1) Либо админы чемпионы игры «Сто к одному», и придумали самый популярный в мире пароль для пользователя user, и этот пароль стоит 1м в списке ботов. Но мы с вами прекрасно понимаем, что там работают не домохозяйки, и настолько тупой пароль придумать не могли (вообще-то могли).
2) Либо вариант более простой — арендовать сервер, подобрать пароль к дефолтной учётке user на своём же арендованном сервере, а потом использовать этот же пароль для всех остальных серверов. Вариант гораздо более реальный, чем угадать пароль с 1го раза.
Но посмотрите логи выше в статье, там пользователь USER входит с 1й попытки:
Aug 20 03:47:31 debian8x64 sshd[1346]: Accepted password for user from 219.135.136.144 port 56492 ssh2
Это значит, что:
1) Либо админы чемпионы игры «Сто к одному», и придумали самый популярный в мире пароль для пользователя user, и этот пароль стоит 1м в списке ботов. Но мы с вами прекрасно понимаем, что там работают не домохозяйки, и настолько тупой пароль придумать не могли (вообще-то могли).
2) Либо вариант более простой — арендовать сервер, подобрать пароль к дефолтной учётке user на своём же арендованном сервере, а потом использовать этот же пароль для всех остальных серверов. Вариант гораздо более реальный, чем угадать пароль с 1го раза.
А при чем тут ваш лог непонятно откуда, и как он связан с конкртно этим случаем в статье?
Объясняю. Мой лог связан с конкретно этим случаем в статье следующим образом: он является результатом работы одного и того же вредоносного ПО. Если вы внимательно посмотрите на лог автора статьи, то вы увидите тот же самый пакет подключений, идущих друг за другом в течение нескольких секунд: сначала test, затем debian, osmc, ubnt, admin, и только восьмое подключение с именем пользователя user оказалось успешным, поэтому лог автора на этом обрывается, а мой лог продолжается дальше с другими пользователями. По сути, бот перебирает не пароли, а учётные записи с паролем 123456, и только для учётки admin он пробует ещё несколько паролей, в частности 123qwe!@# и 123qwe! (статистически это самые распространённые пароли, подходящие под политику сложности). После того, как червь нашёл подходящую учётку, он начинает не только майнить чего-то там, но и начинает с заражённой машины сканировать интернет в попытках размножиться, за что, собственно, автора и забанили:
зафиксирована аномальная сетевая активность: попытки подключения к большому количеству произвольных серверов по порту 22 (SSH)
А всякая лирика с вариантами, как и фантазии автора насчёт злобного хакера на площадке хостера к реальности не имеют никакого отношения.
user/user, в чём проблема?
А зачем вы вообще разрешаете SSH-аутентификацию по паролю? В нормальных облачных провайдерах она выключена по умолчанию.
только я не вижу в этом комментарии ничего про шаблон c Windows?
Прошу прощения за оффтоп, но можно было написать хотя бы как-то так:
В вашем ответе сплошной канцелярит, размытые формулировки, стена мусорного текста и неуважение. Не надо так.
P.S. Про извинения
Мы устранили уязвимость сегодня в 12:08.
В нашем шаблоне Debian 8.7 от 30.07.2018 действительно была учётная запись «user» со слабым паролем. Она появилась из-за ошибки наших сотрудников, которые занимались этим шаблоном. Неизвестный злоумышленник подобрал пароль и смог подключаться к уязвимым серверам.
Мы уже сообщили об уязвимости всем, кто пользовался этим шаблоном, и исправили её. Во всех остальных наших шаблонах этой уязвимости нет.
Чтобы избежать проблем в будущем, мы сейчас проводим дополнительное тестирование безопасности всех шаблонов, улучшаем автоматическую проверку и работаем с качеством работы сотрудников поддержки.
Скоро мы выложим подробный отчёт об этой уязвимости в нашем блоге.
Прошу прощения за нашу ошибку. (%Имя-Отчество Автора%), спасибо за вашу помощь в решении проблемы.
Технический директор, Иванов И.И.
В вашем ответе сплошной канцелярит, размытые формулировки, стена мусорного текста и неуважение. Не надо так.
P.S. Про извинения
А вот в рамках извинений, расскажите, а как вы эти образа собираете и тестируете? DIB или что-то другое?
Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.Сценарий новой серии готов, можно снимать.
Что можно сказать по ситуации описанной в данной статье?…
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
Фэйл, конечно, по-настоящему эпический. Но вопрос — а сами-то вы куда смотрели про создании и конфигурировании серверов? :) Как можно было не заметить левого юзера, да ещё с правами удалённого входа?
последние месяцы на Windows серверах 1cloud, мы начали замечать аномальную нагрузку, но не придавали этому особого значения
А с этим так и не разобрались?
Как можно было не заметить левого юзера
Простите конечно, но повторюсь, что мы не арендуем сервера не у дяди Пети, почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать? 1cloud обязан предоставлять клиентам чистые сборки! У нас создаются десятки серверов в день, если каждый проверять вручную, то придется для этого нанимать отдельного сотрудника…
А с этим так и не разобрались?
Пока никак, к сожалению. Открываю диспетчер задач, тогда сервер перестает тупить. То есть приходится работать с открытым диспетчером задач, тогда нагрузка на сервер снижается. Я так понимаю, что при открытии диспетчера задач перестает работать установленное вредоносное ПО.
docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
как вариант, может то по на него реагировать не будет.
как вариант, может то по на него реагировать не будет.
почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать?
И даже ваша собственная история не дала вам ответ на вопрос, "почему должны"? :) Если вкратце, потому, что прямая обязанность ИТ-службы — понимать, что происходит на обслуживаемых ей серверах. Я вас могу хоть как-то понять, если вы не айтишник, а просто менеджер, который щелкает на кнопочку "заказать сервер в облаке". Но в таком случае надо заключать договор на обслуживание серверов с кем-то, кто понимает, что делает.
Открываю диспетчер задач, тогда сервер перестает тупить.
Диспетчер задач для мониторинга не нужен, это так, средство быстро примерно оценить происходящее. А мониторить можно много чем, от штатного perfmon до самописных скриптов, если какая-то дрянь маскируется от всех штатных средств, было бы желание… Начать можно с process explorer от sysinternals, может сразу будут видны левые процессы.
«почему должны»? :) Если вкратце, потому, что прямая обязанность ИТ-службы — понимать, что происходит на обслуживаемых ей серверах.
Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей, а тем более без инжектов вредоносного ПО. Остальное аргументы не имеет отношения к делу!
А если более подробно, то:
Во-первых выше я уже писал «… хотя мы видели таких пользователей на всех серверах на протяжении всего периода использования серверов.» Возможно не на всех, но на многих серверах, включая Windows сервера, присутствовал такой пользователь. Мы думали, что это какая-то особенность шаблона ОС и не предавали этому значения, так как ранее никаких проблем не испытывали. Прошу заметить, что сборку ОС предоставляет нам 1cloud, соответственно они за нее и должны отвечать! По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер. Речь идет не о нашей некомпетентности, а о некомпетентности сотрудников 1cloud. Если это дело рук кого-то из сотрудников, то это серьезное преступление!
Во-вторых я не менеджер! Я знаю, что говорю. Мы нашли проблему на сервере ровно через 5 минут после начала осмотра сервера. Мы работаем с большим количеством серверов, как облачных, так и обычных, но с таким вопиющим нарушением сталкиваемся впервые! На 1cloud ничего жизненно важного никогда не держали, понимали, что у них все далеко не идеально. Никто не предавал особого значения этим пользователям. Все важное всегда держим на digitalocean, где не приходится искать дыры в сборках ОС.
Как бы вам объяснить… Вот идете вы по тротуару, а там лежат грабли. Вы на них наступаете и получаете по лбу. Тот, кто их туда положил — несомненно, нехороший человек. И, если бы вы прогуливались с девушкой и смотрели на звёзды :), винить можно было бы только его. Но, если вы на работе и в ваши непосредственные обязанности входит в том числе очистка тротуара от граблей, то для оценки вашего собственно профессионализма совершенно неважно, кто и почему их туда положил — важно, что вы их не заметили. Не какую-нибудь хитро замаскированную ловушку, а такие здоровенные садовые грабли с большой деревянной ручкой. :) Лоб, конечно, ваш, и вам решать, делать выводы или нет. Но контроль за учетками и удаленным доступом к серверам — это такие азы, что даже удивительно, что тут что-то приходится объяснять. Тем более, если у вас «создаются десятки серверов в день» — никакой «отдельный человек», чтобы всё проверять, тут не нужен — нужна автоматическая заливка проверенного вами конфига и мониторинг.
> где не приходится искать дыры в сборках ОС.
Или же вы можете просто ничего о них не знать. Если пропустили что-то столь очевидное, как левый пользователь с удаленным доступом, то можете и куда менее очевидные вещи пропустить.
> где не приходится искать дыры в сборках ОС.
Или же вы можете просто ничего о них не знать. Если пропустили что-то столь очевидное, как левый пользователь с удаленным доступом, то можете и куда менее очевидные вещи пропустить.
Считаю, что нет смысла продолжать далее данный диалог, так как от Вас пахнет кем-то причастным к данной ситуации с 1cloud) Не понимаю, при чем тут мы вообще? Мы что сделали плохого? Потроллить просто нужно или что? По тротуару мы идем бесплатно, а сервера арендуем за деньги.
Вы ничего плохого не сделали. У вас просто заведомо уязвимая позиция «мы заплатили деньги, значит, все хорошо, и ничего проверять не надо». При этом аргументация такой позиции у вас на уровне «вот в Digital Ocean» все хорошо, им мы доверяем.
Дело в том, что у того же DO тоже вполне себе обнаруживаются время от времени уязвимости, никто не без греха. И «пофиксить» их без вмешательства с вашей стороны тот же DO не всегда может. Потом вы пропустите письмо от DO с просьбой «нажать вот эти кнопки вот в такой последовательности» и будете писать ровно такой же пост, только уже про «плохой DigitalOcean».
Дело в том, что у того же DO тоже вполне себе обнаруживаются время от времени уязвимости, никто не без греха. И «пофиксить» их без вмешательства с вашей стороны тот же DO не всегда может. Потом вы пропустите письмо от DO с просьбой «нажать вот эти кнопки вот в такой последовательности» и будете писать ровно такой же пост, только уже про «плохой DigitalOcean».
И хорошо ещё, если грабли не детские...
del
Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей, а тем более без инжектов вредоносного ПО.
Тут весьма спорный момент. Кто, кому, в каком объеме и что должен явно прописано в договоре и SLA — если глянуть эти два документа у 1cloud, то там нет ни слова о образах ОС. То есть, с юридической точки зрения, в данном случае провайдер вам ничего не должен в плане предоставления образов ОС.
Возможно не на всех, но на многих серверах, включая Windows сервера, присутствовал такой пользователь. Мы думали, что это какая-то особенность шаблона ОС и не предавали этому значения, так как ранее никаких проблем не испытывали.
То есть вы заранее знали о том, что на ваших машинах присутствует какой то левый пользователь, который явно не нужен ни вам ни ОС, но при этом положили на это, как говорится, «вдоль и поперек»? О какой особенности шаблона вы думали? Не кажется ли вам это, мягко говоря, некомпетентностью с вашей стороны?
По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер.
Вы никак не объяснили, что именно сотрудник провайдера имеет пароль для пользователя user:
Мы считаем, и все указывает на то, что кто-то из сотрудников 1cloud (очень надеюсь, что не руководство), начал промышлять черными делами, устанавливая майнеры и вредоносное ПО на сервера своих клиентов, за которые между прочим мы платим деньги.
То есть, вам не пришла в голову мысль, что пароль (который, скорее всего прост как пятерня на руке) был заранее известен (учитывая, что машины из этого шаблона создавались с 30 июля 2018 года) злоумышленнику и считаете, что сотрудники провайдера нагибали целенаправленно ваши серверы?
А исходя из высказывания:
по логам видна попытка однократного подключения к пользователям user, admin, ubuntu, ubnt, test и osmc, а затем успешная авторизация через пользователя «user».
и логов, это обычная подборка по словарю. То есть, другими словами, вы не удосужились обезопасить свою инфраструктуру от подобных атак (несмотря на то, что попытки совершались с одного и того же адреса 219.135.136.144) даже банальным fail2ban.
И тут возникает вопрос по поводу второго абзаца вашего комментария:
Во-вторых я не менеджер! Я знаю, что говорю.
P.S. Я не имею никакого отношения к 1cloud, про данного провайдера я услышал благодаря этой статье, я не укоряю ни вас лично, ни провайдера — це исключительно размышления и вопросы.
Справедливости ради, вы в данный момент ведете себя не сильно лучше поддержки 1Cloud.
Вот это место:
выглядит достаточно сомнительно.
Почему именно сотрудник 1cloud? Логичнее предположить, что пользователь — тупо шаблонный, и во всех контейнерах у него один и тот же пароль. Для того, чтобы одноразово подобрать пароль и потом использовать его на всех инстансах, совершенно не обязательно быть сотрудником 1Cloud. В конце концов сотруднику проще тупо «заинжектить дичь» напрямую в шаблон ОС, чтобы не «палиться» с логами авторизации при последующих коннектах с целью «заинжектить дичь».
Это не отменяет того факта, что у 1Cloud дыра в шаблоне контейнера размером не то что с футбольные ворота, а скорее с футбольное поле, но хотелось бы, чтобы вы, как человек вопрошающий, придерживались корректных формулировок.
Ну а вот это:
вообще достаточно странная позиция.
«Мы не должны как-либо проверять качество получаемой нами услуги» — достаточно уязвимая позиция, например, вам не кажется? Это не ваша прямая обязанность, конечно, но оценка качества — нормальная позиция адекватного человека. При этом, если вы сами предоставляете услугу на базе сервисов 1Cloud третьей стороне, то проверка качества сервиса 1Cloud таки становится вашей прямой обязанностью, вы ведь принимаете на себя обязательство о качестве вашего сервиса уже перед вашим клиентом.
Вот это место:
По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер.
выглядит достаточно сомнительно.
Почему именно сотрудник 1cloud? Логичнее предположить, что пользователь — тупо шаблонный, и во всех контейнерах у него один и тот же пароль. Для того, чтобы одноразово подобрать пароль и потом использовать его на всех инстансах, совершенно не обязательно быть сотрудником 1Cloud. В конце концов сотруднику проще тупо «заинжектить дичь» напрямую в шаблон ОС, чтобы не «палиться» с логами авторизации при последующих коннектах с целью «заинжектить дичь».
Это не отменяет того факта, что у 1Cloud дыра в шаблоне контейнера размером не то что с футбольные ворота, а скорее с футбольное поле, но хотелось бы, чтобы вы, как человек вопрошающий, придерживались корректных формулировок.
Ну а вот это:
Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей
вообще достаточно странная позиция.
«Мы не должны как-либо проверять качество получаемой нами услуги» — достаточно уязвимая позиция, например, вам не кажется? Это не ваша прямая обязанность, конечно, но оценка качества — нормальная позиция адекватного человека. При этом, если вы сами предоставляете услугу на базе сервисов 1Cloud третьей стороне, то проверка качества сервиса 1Cloud таки становится вашей прямой обязанностью, вы ведь принимаете на себя обязательство о качестве вашего сервиса уже перед вашим клиентом.
Т. Е. Я заплатил деньги за услугу, которая должна быть качественной, ещё при этом нанять безопансика, чтобы он проверил на предмет дыр? Так себе услуга…
Если честно, сам факт того, что услуга платная, вообще ничего не говорит о ее качестве, например. С вашей логикой любая услуга — так себе, просто по определению услуги.
с твоей логикой при покупке пива надо бежать в лабораторию, а не ожидать, что в банку налито то за что ты заплатил, а не бодяга.
логика ущербна.
логика ущербна.
Какбэ, в текущей ситуации на VPSке пользователя был создан левый пользователь. Так что вернее выглядит следующая ассоциация:
Ты купил пива, а дома, когда наливал его в стакан, заметил, что в бутылке плавает лягушка, а пена на пиве фиолетового цвета.
— Нет, быть не может, что говно попалось! — подумал ты. — Я же ДЕНЬГИ ЗАПЛАТИЛ!
Зажмурился, заткнул нос, постарался максимально абстрагироваться и таки выпил.
Ты купил пива, а дома, когда наливал его в стакан, заметил, что в бутылке плавает лягушка, а пена на пиве фиолетового цвета.
— Нет, быть не может, что говно попалось! — подумал ты. — Я же ДЕНЬГИ ЗАПЛАТИЛ!
Зажмурился, заткнул нос, постарался максимально абстрагироваться и таки выпил.
Простите конечно, но повторюсь, что мы не арендуем сервера не у дяди Пети, почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать? 1cloud обязан предоставлять клиентам чистые сборки! У нас создаются десятки серверов в день, если каждый проверять вручную, то придется для этого нанимать отдельного сотрудника…Знаете фразу «пешеход всегда прав, особенно если мертв»?
Возможно, вас повеселит или заинтересует эта статья от Microsoft: Windows Update может создавать повышенную нагрузку, если в ОС существует пользователь с именем, содержащим подстроку "user".
219.135.136.144
В abuseipdb.com — по нему стали поступать репорты 2018.08.19.
Shodan его зафиксировал 2018.01.10
Предположительно, по соседним хостам — там есть живые люди, китайцы:
iknowwhatyoudownload.com/ru/peer/?ip=219.135.136.138
В abuseipdb.com — по нему стали поступать репорты 2018.08.19.
Brute-Force, FTP Brute-Force, Hacking, SSH
Shodan его зафиксировал 2018.01.10
Предположительно, по соседним хостам — там есть живые люди, китайцы:
iknowwhatyoudownload.com/ru/peer/?ip=219.135.136.138
Только что пришло новое сообщение от техподдержки. «Сервер заблокирован администратором. Причина блокировки: Зафиксирована попытка атаки». Очередной наш сервер, который был создан 22 августа 2018, уже был заражен через пользователя «user» и начались атаки на другие сервера… Похоже, что 1cloud ничего не собирается предпринимать.
Тикет от 1cloud
Здравствуйте.
Поступила жалоба атаку, осуществляемую с IP адреса: 176.122.20.205 из пула выданной вам публичной сети.
Просим принять меры. Ниже приводим оригинальный текст жалобы:
Hello Abuse-Team,
your Server/Customer with the IP: *176.122.20.205* (176.122.20.205) has attacked one of our servers/partners.
The attackers used the method/service: *ssh* on: *Fri, 24 Aug 2018 03:04:31 -0400*.
The time listed is from the server-time of the Blocklist-user who submitted the report.
The attack was reported to the Blocklist.de-System on: *Fri, 24 Aug 2018 09:04:38 +0200*
!!! Do not answer to this Mail! Use support@ or contact-form for Questions (no resolve-messages, no updates....)!!!
The IP has been automatically blocked for a period of time. For an IP to be blocked, it needs
to have made several failed logins (ssh, imap....), tried to log in for an «invalid user», or have
triggered several 5xx-Error-Codes (eg. Blacklist on email...), all during a short period of time.
The Server-Owner configures the number of failed attempts, and the time period they have
to occur in, in order to trigger a ban and report. Blocklist has no control over these settings.
Please check the machine behind the IP 176.122.20.205 (176.122.20.205) and fix the problem.
This is the 2 Attack (reported: 0) from this IP; see:
www.blocklist.de/en/view.html?ip=176.122.20.205
If you need the logs in another format (rather than an attachment), please let us know.
You can see the Logfiles online again: www.blocklist.de/en/logs.html?rid=833680682&ip=176.122.20.205
You can parse this abuse report mail with X-ARF-Tools from www.xarf.org/tools.html e.g. validatexarf-php.tar.gz.
You can find more information about X-Arf V0.2 at www.xarf.org/specification.html
This message will be sent again in one day if more attacks are reported to Blocklist.
In the attachment of this message you can find the original logs from the attacked system.
To pause this message for one week, you can use our «Stop Reports» feature on Blocklist.de to submit
the IP you want to stop recieving emails about, and the email you want to stop receiving them on.
If more attacks from your network are recognized after the seven day grace period, the reports will start
being sent again.
To pause these reports for one week:
www.blocklist.de/en/insert.html?ip=176.122.20.205&email=abuse@it-grad.ru
We found this abuse email address in the Whois-Data from the IP under the SearchString «abuse-c (own-db)»
Reply to this message to let us know if you want us to send future reports to a different email. (e.g. to abuse-quiet or a special address)
— blocklist.de Abuse-Team
This message was sent automatically. For questions please use our Contact-Form (autogenerated@/abuse-team@ is not monitored!):
www.blocklist.de/en/contact.html?RID=833680682
Logfiles: www.blocklist.de/en/logs.html?rid=833680682&ip=176.122.20.205
------------------------------Reported-From: abuse-team@blocklist.de
Category: abuse
Report-Type: login-attack
Service: ssh
Version: 0.2
User-Agent: Fail2BanFeedBackScript blocklist.de V0.2
Date: Fri, 24 Aug 2018 03:04:31 -0400
Source-Type: ip-address
Source: 176.122.20.205
Port: 22
Report-ID: 833680682@blocklist.de
Schema-URL: www.xarf.org/schema/abuse_login-attack_0.1.2.json
Attachment: text/plain
Aug 24 03:04:11 eola sshd[14810]: Did not receive identification string from 176.122.20.205 port 43425
Aug 24 03:04:22 eola sshd[14817]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=176.122.20.205 user=root
Aug 24 03:04:23 eola sshd[14817]: Failed password for root from 176.122.20.205 port 45131 ssh2
Aug 24 03:04:24 eola sshd[14817]: Connection closed by 176.122.20.205 port 45131 [preauth]
Aug 24 03:04:29 eola sshd[14826]: Invalid user test from 176.122.20.205 port 47217
Aug 24 03:04:30 eola sshd[14826]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=176.122.20.205
Aug 24 03:04:31 eola sshd[14826]: Failed password for invalid user test from 176.122.20.205 port 47217 ssh2
Поступила жалоба атаку, осуществляемую с IP адреса: 176.122.20.205 из пула выданной вам публичной сети.
Просим принять меры. Ниже приводим оригинальный текст жалобы:
Hello Abuse-Team,
your Server/Customer with the IP: *176.122.20.205* (176.122.20.205) has attacked one of our servers/partners.
The attackers used the method/service: *ssh* on: *Fri, 24 Aug 2018 03:04:31 -0400*.
The time listed is from the server-time of the Blocklist-user who submitted the report.
The attack was reported to the Blocklist.de-System on: *Fri, 24 Aug 2018 09:04:38 +0200*
!!! Do not answer to this Mail! Use support@ or contact-form for Questions (no resolve-messages, no updates....)!!!
The IP has been automatically blocked for a period of time. For an IP to be blocked, it needs
to have made several failed logins (ssh, imap....), tried to log in for an «invalid user», or have
triggered several 5xx-Error-Codes (eg. Blacklist on email...), all during a short period of time.
The Server-Owner configures the number of failed attempts, and the time period they have
to occur in, in order to trigger a ban and report. Blocklist has no control over these settings.
Please check the machine behind the IP 176.122.20.205 (176.122.20.205) and fix the problem.
This is the 2 Attack (reported: 0) from this IP; see:
www.blocklist.de/en/view.html?ip=176.122.20.205
If you need the logs in another format (rather than an attachment), please let us know.
You can see the Logfiles online again: www.blocklist.de/en/logs.html?rid=833680682&ip=176.122.20.205
You can parse this abuse report mail with X-ARF-Tools from www.xarf.org/tools.html e.g. validatexarf-php.tar.gz.
You can find more information about X-Arf V0.2 at www.xarf.org/specification.html
This message will be sent again in one day if more attacks are reported to Blocklist.
In the attachment of this message you can find the original logs from the attacked system.
To pause this message for one week, you can use our «Stop Reports» feature on Blocklist.de to submit
the IP you want to stop recieving emails about, and the email you want to stop receiving them on.
If more attacks from your network are recognized after the seven day grace period, the reports will start
being sent again.
To pause these reports for one week:
www.blocklist.de/en/insert.html?ip=176.122.20.205&email=abuse@it-grad.ru
We found this abuse email address in the Whois-Data from the IP under the SearchString «abuse-c (own-db)»
Reply to this message to let us know if you want us to send future reports to a different email. (e.g. to abuse-quiet or a special address)
— blocklist.de Abuse-Team
This message was sent automatically. For questions please use our Contact-Form (autogenerated@/abuse-team@ is not monitored!):
www.blocklist.de/en/contact.html?RID=833680682
Logfiles: www.blocklist.de/en/logs.html?rid=833680682&ip=176.122.20.205
------------------------------Reported-From: abuse-team@blocklist.de
Category: abuse
Report-Type: login-attack
Service: ssh
Version: 0.2
User-Agent: Fail2BanFeedBackScript blocklist.de V0.2
Date: Fri, 24 Aug 2018 03:04:31 -0400
Source-Type: ip-address
Source: 176.122.20.205
Port: 22
Report-ID: 833680682@blocklist.de
Schema-URL: www.xarf.org/schema/abuse_login-attack_0.1.2.json
Attachment: text/plain
Aug 24 03:04:11 eola sshd[14810]: Did not receive identification string from 176.122.20.205 port 43425
Aug 24 03:04:22 eola sshd[14817]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=176.122.20.205 user=root
Aug 24 03:04:23 eola sshd[14817]: Failed password for root from 176.122.20.205 port 45131 ssh2
Aug 24 03:04:24 eola sshd[14817]: Connection closed by 176.122.20.205 port 45131 [preauth]
Aug 24 03:04:29 eola sshd[14826]: Invalid user test from 176.122.20.205 port 47217
Aug 24 03:04:30 eola sshd[14826]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=176.122.20.205
Aug 24 03:04:31 eola sshd[14826]: Failed password for invalid user test from 176.122.20.205 port 47217 ssh2
Понапишите им во все фейсбуки, телеграмы, инстаграмы с просьбой срочно(!!!) объективно(!!!) рассмотреть ваш тикет.
Но вообще этот случай — полнейшая дичь конечно же…
Но вообще этот случай — полнейшая дичь конечно же…
На тикеты они отвечают, утверждают что уязвимые шаблоны более недоступны, но пока в это слабо верится…
Здравствуйте!
Шаблон исправлен, сейчас идет процедура его синхронизации по площадкам. Уязвимый шаблон исключили из списка доступных.
Добрый день!
Подтверждаем, что данный шаблон сервера имел уязвимого пользователя user (которого там вообще не должно было быть).
О факте его наличия будет произведено внутреннее расследование с ответственными за подготовку шаблона сотрудниками (шаблон точно не был взят из общего доступа, а подготовлен нами с нуля).
Спешим отметить, что версия уязвимого шаблона была выпущена 30.07.2018, поэтому серверы, созданные ранее из этого шаблона, такой уязвимости не имеют.
На текущий момент уязвимый шаблон выведен из эксплуатации, исправленный шаблон синхронизируется по площадкам и скоро будет запущен.
Также будет проверены все шаблоны, которые доступны в данный момент.
Также будет добавлен дополнительный пункт в check list проверки, который используется при подготовке новых версий шаблонов.
Также в течение дня мы свяжемся со всеми Клиентами у которых были созданы серверы из уязвимых шаблонов и поможем им устранить данную уязвимость.
Большое спасибо за информацию. Верим, что подобный fail мы более не повторим.
Подтверждаем, что данный шаблон сервера имел уязвимого пользователя user (которого там вообще не должно было быть).
О факте его наличия будет произведено внутреннее расследование с ответственными за подготовку шаблона сотрудниками (шаблон точно не был взят из общего доступа, а подготовлен нами с нуля).
Спешим отметить, что версия уязвимого шаблона была выпущена 30.07.2018, поэтому серверы, созданные ранее из этого шаблона, такой уязвимости не имеют.
На текущий момент уязвимый шаблон выведен из эксплуатации, исправленный шаблон синхронизируется по площадкам и скоро будет запущен.
Также будет проверены все шаблоны, которые доступны в данный момент.
Также будет добавлен дополнительный пункт в check list проверки, который используется при подготовке новых версий шаблонов.
Также в течение дня мы свяжемся со всеми Клиентами у которых были созданы серверы из уязвимых шаблонов и поможем им устранить данную уязвимость.
Большое спасибо за информацию. Верим, что подобный fail мы более не повторим.
Очень надеюсь получить развернутый и вразумительный ответ в комментариях к этой статье после проведения внутреннего расследования.
Вот я тоже неоднократно замечал что тех-поддержка Ваша в любой нештатной ситуации бесполезна — «не могём, не знаем, не виноватая я»… А стоит, например, тут в личку написать, и всё решается достаточно быстро и позитивно. Возможно и этой статьи бы не было, сработай ТП профессионально. Пофиксите ТП уже, наконец)
Если вы искренне раскаиваетесь, а не на словах, то докажите это делом, например, компенсируйте клиенту понесенные неудобства.
Мы признаем, что уязвимость имела место быть. Клиенту компенсирован простой серверов в соответствии с SLA.
компенсация-то хоть нормальная, а не за сутки?
А разве это важно? Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости! Мы вообще не особо претендовали на компенсацию. «Согласно SLA данное время простоя попадает в промежуток, соответствующий сумме 20% от месячного потребления недоступных ВМ.»
по моему опыту — важно.
когда клиенту после суточного простоя компенсируешь «строго по договору» — его с заметной вероятностью больше не увидишь.
когда клиенту после суточного простоя компенсируешь «строго по договору» — его с заметной вероятностью больше не увидишь.
Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости!
Такое — это наличие уязвимостей на сервере в принципе? Я вас разочарую, повторится, и не раз, и не только у 1Cloud.
А наказание виновников «по всей строгости» вам, простите, зачем?
Помогли ли альтернативные просмотрщики процессов на виндовсе?
Если еще и виндовые машины заражены — это полнейший провал.
Если еще и виндовые машины заражены — это полнейший провал.
Это уже 4-й день вы с ними воюете?
UFO just landed and posted this here
Дичь какая то. Это даже не фэйлище. А саботаж чистой воды.Как этот 1Cloud жить то дальше собирается?
В ubuntu для lxc (который через lxc-create из коробки качается) добавлен пользователь по умолчанию ubuntu:ubuntu.
Думаю, у вас примерно то же самое.
Думаю, у вас примерно то же самое.
Я понимаю, что на деревню дедушке писать эффективнее, чем обращаться к нашим правоохранителям (а вообще-то это можно расценивать как нарушение работы информационных систем, т.е. взлом ваших серверов… соответственно и дело уголовное можно смело заводить и выигрывать). Просто призываю всех пользователей этого сервиса (коим я, к счастью, не являюсь) попробовать создать дебиан сервер для теста и если там будет юзер user — отписать техподдержке «что за фигня» и «верните деньги за этот тестовый сервер, там троян»… Если запрос «что за фигня» техподдержка легко проигнорирует, то запрос на массовый (пусть и копеечный) возврат денег уже может кого-то напрячь.
Не понимаю, какие могут быть преимущества таких облаков по сравнению с AWS. Цена? Набросал сервер примерно эквивалентный ec2 t2.micro, цена выходит такая же или дороже… Только качество сервиса у AWS мирового уровня и гарантии начинаются с нескольких девяток у 99%.
UFO just landed and posted this here
Может быть проблема в кириллице в имени и фамилии.
Определенно! Проблема в локации. Россию и СНГ мало кто любит (благодаря кардерам...)! С европейских аккаунтов не возникает подобных проблем, проверено на личном опыте.
UFO just landed and posted this here
Проблема в отношении. Западным сервисам проще забанить российские карты (или по-скотски требовать документы) чем разбираться, кто кардер, а кто честный пользователь. Ну и проблема в устаревших незащищенных системах Visa/Mastercard, которые позволяют воровать данные карт и до сих пор не могут сделать нормальную систему защиты.
вы забываете про локализацию хранения данных. Плюс еще свежи воспоминания про массовые простои в западных облаках во время погони за тграммом в конце апреля. Поэтому все массово (действительно массово) идут в рублака — селектел, мрг, 1клауд. Я-блоко говорят запустится в конце осени (уже пару лет так говорят, правда). Плюс у бизнеса чаще всего в РФ (я не знаю как на западе — не берусь судить) для юриков == лиц с большим месячным чеком == цена за условную виртуалку или гигабайт гораздо дешевле
сюр какой то, не в защиту 1cloud
«у нас на виндовом сервере большая нагрузка, делать мы ничего не будем, пусть диспетчер задач будет открыт»
«у нас на виндовом сервере большая нагрузка, делать мы ничего не будем, пусть диспетчер задач будет открыт»
egorbI4
Такое случается у разных провайдеров. Например, у FirstVDS я замечал то же самое.
Когда моя статья об этом была опубликована на Хабре (до того, как она стала заблокирована) — попадались комментарии, в которых писалось, что это норм ситуация для техподдержки (чтоб оперативно решать проблемы у клиента). При этом клиента об этом не предупреждают заранее. Сам это не одобряю. Просто делюсь наблюдениями о том, зачем это могло понадобиться провайдеру.
С тех пор при аренде серверов у любых провайдеров в обязательном порядке проверяю наличие пользователей
Такое случается у разных провайдеров. Например, у FirstVDS я замечал то же самое.
Когда моя статья об этом была опубликована на Хабре (до того, как она стала заблокирована) — попадались комментарии, в которых писалось, что это норм ситуация для техподдержки (чтоб оперативно решать проблемы у клиента). При этом клиента об этом не предупреждают заранее. Сам это не одобряю. Просто делюсь наблюдениями о том, зачем это могло понадобиться провайдеру.
С тех пор при аренде серверов у любых провайдеров в обязательном порядке проверяю наличие пользователей
Извините за нескомность. А Вам сколько лет?
Автору статьи: Просто напиши мне в личку, готов решить все проблемы с *nix\Win серверами + поставим нормальный мониторинг на Nagios, чтоб больше никаких левых пользователей\нагрузок. Надо будет — свой образ сделаем, чтоб с гарантией. По цене договоримся ;-)
1cloud: мужики, вы чего? Ну возьмите уже этот образ, расковыряйте, что там за пароль, зайдите сами и поменяйте на что-то сложное. Костыль конечно, но хоть абузы сыпаться не будут. ИМХО скриптец при наличии пароля написать не проблема. Да и за такое время если у Вас реально специалисты есть можно было бы расследовать и статью написать с подробностями. Уже бы и г-ном тут перестали поливать. Косяки то у всех бывают да еще какие. А пока молчите — тут градус растет, а репутация падает.
1cloud: мужики, вы чего? Ну возьмите уже этот образ, расковыряйте, что там за пароль, зайдите сами и поменяйте на что-то сложное. Костыль конечно, но хоть абузы сыпаться не будут. ИМХО скриптец при наличии пароля написать не проблема. Да и за такое время если у Вас реально специалисты есть можно было бы расследовать и статью написать с подробностями. Уже бы и г-ном тут перестали поливать. Косяки то у всех бывают да еще какие. А пока молчите — тут градус растет, а репутация падает.
Что можно сказать по ситуации описанной в данной статье?…
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
1) постановка задачи.
2) контроль
3) результат.
Очень часто косяки встречаются на п2. Ввиду экономии или чего-либо ещё. Сам косячил. Аргументирую так: " а кто меня проконтролировал, как исполнителя?"
- должен сам себя контролировать! Если всех контролировать, то это колоссальные издержки. Считаю, что нет. Промежуточный контроль нужен. Группа системных администраторов и старший системный администратор. Он контролирует не для того что бы наказать, а для того что бы избежать последствий.
Всегда на всех арендуемых Linux сразу выставляю список конкретных юзеров для ssh, смотрю список шеллов в /etc/passwd, считал себя параноиком, а теперь точно не перестану это делать.
Виртуалки с виндой арендую только у тех, у кого есть возможность штатно управлять firewall ко всем серверам моего аккаунта. И сразу фильтрую rdp и прочие как минимум по ip. Если хостер не имеет опции настраиваемого firewall, прохожу мимо. Так выходит, что прохожу мимо всех почти, кроме Amazon и Azure. И, по ходу, так и дальше буду.
Ситуация атас, и поучительна с обеих сторон.
Sign up to leave a comment.
Критическая уязвимость серверов 1Cloud