Критическая уязвимость серверов 1Cloud

Хотим поделиться своим опытом работы с серверами 1cloud. Мы не хотим никого обвинять, просто хотим выставить проблему на всеобщее обозрение, чтобы у сотрудников 1cloud появилась мотивация для проведения детального анализа данной проблемы.

Началось все с того, что последние месяцы на Windows серверах 1cloud, мы начали замечать аномальную нагрузку, но не придавали этому особого значения, так как Windows сервера в основном использовались для выполнения различных мелких задач типа использование браузера и любых других программ, да и особо не было желания выяснять что там и как.

Но на днях произошла весьма неприятная и оскорбительная ситуация со стороны сотрудников 1cloud, которая подтолкнула нас на публикацию данной статьи. Мы используем сервера 1cloud уже около 1.5-2х лет, правила использования серверов не нарушали. Я был неприятно удивлен, когда зашел в аккаунт и увидел, что все 40 наших серверов заблокированы с пометкой «Сервер заблокирован администратором. Причина блокировки: брутфорс.». Собрался писать в сапорт и увидел новое сообщение от службы техподдержки, в котором было сказано:
Здравствуйте.

С Вашего сервера IP 111.111.11.111 зафиксирована аномальная сетевая активность: попытки подключения к большому количеству произвольных серверов по порту 22 (SSH)
Возможно, сервер был взломан. Вам необходимо оперативно устранить проблему.

В случае отсутствия реакции по данному обращению сервер будет отключен от сети.

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

Это конечно неприятная ситуация, но бывает, подумал я, и мы начали разбираться в проблеме, из-за которой сервера были блокированы. Сервера автоматически не включились, как нам обещали, и мне пришлось вручную запускать все сервера, но это мелочь по сравнению с основной проблемой. Залогинились на сервер, и сразу заметили странность, что по ssh мы подключались в последний раз 20го августа, а различные вредоносные файлы были залиты на сервер 21го и 22го числа. Как оказалось, во время создания каждого сервера на 1cloud, добавляется какой-то сомнительный пользователь «user», в папке которого в дальнейшем начала появляться куча вредоносных файлов, включая майнер xrig.

image

Начали звонить в сапорт, объяснили ситуацию, спросили, что за пользователь «user» добавляется при создании сервера и что в его папках делают вредоносные файлы. Сотрудник техподдержки пытался отрицать, что пользователь «user» добавляется автоматически при создании сервера, и утверждал, что они к этому не имеют никакого отношения. Мы создали новый сервер для теста, на котором так же уже сразу присутствовал пользователь «user», но пока без вредоносных файлов, так как инджектят вредоносное ПО на сервер не сразу, а через сутки или более. Сотрудник техподдержки не смог дать внятного ответа, откуда на вновь созданном сервере по умолчанию появился пользователь «user».

Полезли смотреть логи, оказалось, что кто-то, зная пароль, подконнектился к пользователю «user», и залил на сервер вредоносные файлы для майнинга и брутфорса. Сразу хотел бы уточнить, что клиентам 1cloud не выдают пароль от пользователя «user», более того сотрудник техподдержки мне упорно доказывал, что даже такого пользователя на их серверах нет и никогда не было, хотя мы видели таких пользователей на всех серверах на протяжении всего периода использования серверов.

Мы считаем, и все указывает на то, что кто-то из сотрудников 1cloud (очень надеюсь, что не руководство), начал промышлять черными делами, устанавливая майнеры и вредоносное ПО на сервера своих клиентов, за которые между прочим мы платим деньги. В первые дни после создания сервера кто-то подключается к нему через пользователя «user», зная при этом его пароль, и получает контроль над Вашим сервером. Возможно это брут, скажете вы, но нет, к сожалению, по логам видно, что это не брут, а именно обычная авторизация без подбора паролей. Перед тем как войти на сервер под пользователем «user», по логам видна попытка однократного подключения к пользователям user, admin, ubuntu, ubnt, test и osmc, а затем успешная авторизация через пользователя «user».

Aug 20 03:46:59 debian8x64 sshd[1328]: Invalid user test from 219.135.136.144
Aug 20 03:46:59 debian8x64 sshd[1328]: input_userauth_request: invalid user test [preauth]
Aug 20 03:46:59 debian8x64 sshd[1328]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:46:59 debian8x64 sshd[1328]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:02 debian8x64 sshd[1328]: Failed password for invalid user test from 219.135.136.144 port 1072 ssh2
Aug 20 03:47:02 debian8x64 sshd[1328]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:03 debian8x64 sshd[1330]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:03 debian8x64 sshd[1330]: Invalid user debian from 219.135.136.144
Aug 20 03:47:03 debian8x64 sshd[1330]: input_userauth_request: invalid user debian [preauth]
Aug 20 03:47:03 debian8x64 sshd[1330]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:03 debian8x64 sshd[1330]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:05 debian8x64 sshd[1330]: Failed password for invalid user debian from 219.135.136.144 port 8178 ssh2
Aug 20 03:47:05 debian8x64 sshd[1330]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:06 debian8x64 sshd[1332]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:07 debian8x64 sshd[1332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144 user=root
Aug 20 03:47:09 debian8x64 sshd[1332]: Failed password for root from 219.135.136.144 port 14224 ssh2
Aug 20 03:47:09 debian8x64 sshd[1332]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:10 debian8x64 sshd[1334]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:10 debian8x64 sshd[1334]: Invalid user debian from 219.135.136.144
Aug 20 03:47:10 debian8x64 sshd[1334]: input_userauth_request: invalid user debian [preauth]
Aug 20 03:47:11 debian8x64 sshd[1334]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:11 debian8x64 sshd[1334]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:13 debian8x64 sshd[1334]: Failed password for invalid user debian from 219.135.136.144 port 21466 ssh2
Aug 20 03:47:13 debian8x64 sshd[1334]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:15 debian8x64 sshd[1336]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:15 debian8x64 sshd[1336]: Invalid user osmc from 219.135.136.144
Aug 20 03:47:15 debian8x64 sshd[1336]: input_userauth_request: invalid user osmc [preauth]
Aug 20 03:47:15 debian8x64 sshd[1336]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:15 debian8x64 sshd[1336]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:16 debian8x64 sshd[1336]: Failed password for invalid user osmc from 219.135.136.144 port 28516 ssh2
Aug 20 03:47:17 debian8x64 sshd[1336]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:18 debian8x64 sshd[1338]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:18 debian8x64 sshd[1338]: Invalid user ubnt from 219.135.136.144
Aug 20 03:47:18 debian8x64 sshd[1338]: input_userauth_request: invalid user ubnt [preauth]
Aug 20 03:47:18 debian8x64 sshd[1338]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:18 debian8x64 sshd[1338]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:20 debian8x64 sshd[1338]: Failed password for invalid user ubnt from 219.135.136.144 port 34656 ssh2
Aug 20 03:47:20 debian8x64 sshd[1338]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:22 debian8x64 sshd[1340]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:22 debian8x64 sshd[1340]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144 user=root
Aug 20 03:47:24 debian8x64 sshd[1340]: Failed password for root from 219.135.136.144 port 40882 ssh2
Aug 20 03:47:24 debian8x64 sshd[1340]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:25 debian8x64 sshd[1342]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:25 debian8x64 sshd[1342]: Invalid user admin from 219.135.136.144
Aug 20 03:47:25 debian8x64 sshd[1342]: input_userauth_request: invalid user admin [preauth]
Aug 20 03:47:26 debian8x64 sshd[1342]: Failed none for invalid user admin from 219.135.136.144 port 47736 ssh2
Aug 20 03:47:26 debian8x64 sshd[1342]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:27 debian8x64 sshd[1344]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:27 debian8x64 sshd[1344]: Invalid user test from 219.135.136.144
Aug 20 03:47:27 debian8x64 sshd[1344]: input_userauth_request: invalid user test [preauth]
Aug 20 03:47:27 debian8x64 sshd[1344]: pam_unix(sshd:auth): check pass; user unknown
Aug 20 03:47:27 debian8x64 sshd[1344]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=219.135.136.144
Aug 20 03:47:29 debian8x64 sshd[1344]: Failed password for invalid user test from 219.135.136.144 port 50546 ssh2
Aug 20 03:47:29 debian8x64 sshd[1344]: Connection closed by 219.135.136.144 [preauth]
Aug 20 03:47:30 debian8x64 sshd[1346]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:31 debian8x64 sshd[1346]: Accepted password for user from 219.135.136.144 port 56492 ssh2
Aug 20 03:47:31 debian8x64 sshd[1346]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:33 debian8x64 sshd[1350]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:33 debian8x64 sshd[1350]: Accepted password for user from 219.135.136.144 port 60134 ssh2
Aug 20 03:47:33 debian8x64 sshd[1350]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:35 debian8x64 sshd[1354]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:35 debian8x64 sshd[1354]: Accepted password for user from 219.135.136.144 port 4485 ssh2
Aug 20 03:47:35 debian8x64 sshd[1354]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:38 debian8x64 sshd[1358]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:38 debian8x64 sshd[1358]: Accepted password for user from 219.135.136.144 port 9509 ssh2
Aug 20 03:47:38 debian8x64 sshd[1358]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:42 debian8x64 sshd[1362]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:42 debian8x64 sshd[1362]: Accepted password for user from 219.135.136.144 port 15833 ssh2
Aug 20 03:47:42 debian8x64 sshd[1362]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:43 debian8x64 sshd[1346]: pam_unix(sshd:session): session closed for user user
Aug 20 03:47:44 debian8x64 sshd[1366]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:44 debian8x64 sshd[1366]: Accepted password for user from 219.135.136.144 port 19619 ssh2
Aug 20 03:47:44 debian8x64 sshd[1366]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:46 debian8x64 sshd[1370]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:46 debian8x64 sshd[1370]: Accepted password for user from 219.135.136.144 port 23935 ssh2
Aug 20 03:47:46 debian8x64 sshd[1370]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:48 debian8x64 sshd[1374]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:49 debian8x64 sshd[1374]: Accepted password for user from 219.135.136.144 port 28277 ssh2
Aug 20 03:47:49 debian8x64 sshd[1374]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:51 debian8x64 sshd[1378]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:51 debian8x64 sshd[1378]: Accepted password for user from 219.135.136.144 port 31735 ssh2
Aug 20 03:47:51 debian8x64 sshd[1378]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:53 debian8x64 sshd[1383]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:53 debian8x64 sshd[1383]: Accepted password for user from 219.135.136.144 port 36097 ssh2
Aug 20 03:47:53 debian8x64 sshd[1383]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:47:55 debian8x64 sshd[1388]: reverse mapping checking getaddrinfo for 144.136.135.219.broad.gz.gd.dynamic.163data.com.cn [219.135.136.144] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 20 03:47:56 debian8x64 sshd[1388]: Accepted password for user from 219.135.136.144 port 39885 ssh2
Aug 20 03:47:56 debian8x64 sshd[1388]: pam_unix(sshd:session): session opened for user user by (uid=0)
Aug 20 03:48:16 debian8x64 sshd[1350]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:19 debian8x64 sshd[1354]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:22 debian8x64 sshd[1358]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:25 debian8x64 sshd[1362]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:27 debian8x64 sshd[1366]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:29 debian8x64 sshd[1370]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:31 debian8x64 sshd[1374]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:34 debian8x64 sshd[1378]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:36 debian8x64 sshd[1383]: pam_unix(sshd:session): session closed for user user
Aug 20 03:48:38 debian8x64 sshd[1388]: pam_unix(sshd:session): session closed for user user


Вывод из этого один – сервера 1cloud на сегодняшний день небезопасно использовать для хостинга каких-либо важных проектов, так как ваши данные могут быть утеряны в связи с тем, что в 1cloud завелся какой-то крот, оставивший дыру в шаблонах ОС. На данный момент нам удалось выяснить, что данная уязвимость точно присутствует в шаблоне Debian 8, остальное пусть сотрудники 1cloud проверяют сами, мы и так сделали достаточно, сообщив им об этой уязвимости.

После длительных телефонных бесед с 1cloud мы не смогли получить вразумительного объяснения по поводу происходящего. Перед нами нехотя извинились, и сказали, что они якобы когда-то там займутся заменой шаблонов ОС, и исключат из них все лишнее. Навязывается вопрос, ребята, что лишнее вам нужно убрать из шаблонов ОС? Вам полностью плевать на своих клиентов? Как можно было продавать сервера с подобной брешью тысячам своим клиентов, хранящих на этих серверах терабайты важных данных? Вывод один –1cloud ценит лишь профит, данные клиентов для них не представляют никакой ценности! Ребята из 1cloud, если считаете, что я не прав – докажите мне обратное!

Мы открыты к общению, уважаемые сотрудники 1cloud, если у вас есть какие-то вопросы – пишите тикет. Мы готовы обсуждать данную ситуацию, но только с кем-то компетентным, а не с сотрудником сапорта, который упорно пытался нам доказать, что никаких пользователей с именем «user» вы не добавляете при создании сервера. Мы также готовы предоставить все необходимые данные, которые помогут покончить с продажей уязвимых серверов 1cloud раз и навсегда!

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 94

    +4
    Мне кажется, что просто взят какой-то, около-случайный шаблон ОС, которых валяется по всему Интернету масса, проверен просто на предмет успешного импорта и все. Проблема может быть вовсе не в сотруднике. А в настройке сервиса по принципу «лишь бы работало», без процедур QA.
      +14
      По принципу «лишь бы работало», серьезно? Я же не у дяди Пети сервера арендую, а у крупной компании, которая за последний год стала достаточно популярна в России. Как можно подвергать тысячи клиентов такому риску?
        +1
        Надеюсь исправятся.
        Интересно, а шаблон дают выкачать. Может быть что-то стоит в rc.local…
        +7
        Уязвимость устранена сегодня в 12:08.

        Мы подтверждаем факт обнаружения в одном из наших шаблонов (ОС Debian 8.7) пользовательской учётной записи, с недостаточно крипто защищённым паролем. В следствии чего данный пароль был взломан злоумышленником и в дальнейшем использован при подключении к серверам, созданным из уязвимого шаблона. Эта версия шаблона была опубликована 30.07.2018. Все клиенты, которые использовали указанную версию шаблона, к настоящему времени оповещены о выявленной уязвимости, и приняты меры по её устранению.
        Уязвимости был подвержен 1 из наших 18 шаблонов.
        Количество пострадавших серверов: менее 50 шт.
        Сразу после обнаружения источника проблемы этот шаблон был незамедлительно выведен из эксплуатации. Все остальные публичные шаблоны виртуальных машин проверены на наличие подобной уязвимости.
        Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.
        Предпринятые действия:
        1. Уязвимость устранена в шаблоне Debian 8.7
        2. Проводится дополнительная проверка все остальных шаблонов на предмет других уязвимостей по безопасности
        3. Будет доработана процедура автоматической проверки «золотых» шаблонов на наличие данной ошибки и других уязвимостей по безопасности.
        4. Будет проведены работы с сотрудниками поддержки для недопущения повторения подобных сценариев взаимодействия с Клиентами
        Приносим свои глубочайшие извинения нашим настоящим и будущим клиентам за возникший инцидент. Мы приложим максимум усилий для исключения возможности возникновения подобных ситуаций в дальнейшем.
        Мы планируем предоставить более подробный отчет об устранении данной проблемы и о предпринятых мерах в отдельной статье в нашем блоге.
        Выражаем благодарность пользователю egorbI4 за извещение о серьёзной проблеме, конструктивную критику и взаимодействие!
          +2
          а с какой целью вообще добавляли левого пользователя в шаблон?
            0
            В процессе установки Debian нельзя пропустить шаг создания непривилегированного пользователя.
            Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
            Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.
              +8
              можно, если выбирать экспертную установку
                +18

                Судя по всему тестили новую сборку, и во время тестов сделали временного пользователя user:123 (условно). Но удалить из финалки его забыли, пустили в прод.
                Ушлый хацкер увидел в дефолтной сборке уже существуюего пользователя, выкачал его хэш и забрутфорсил пароль, после чего открылся доступ к любому серверу на этой ОС. Раз в сутки сканировал подсеть на наличие новых серверов, и заражал их.


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


                ПС: это мое личное мнение как всё было, в стиле Шерлок.

                  –2
                  Ушлый хацкер увидел в дефолтной сборке уже существуюего пользователя, выкачал его хэш и забрутфорсил пароль

                  Никто никакой хэш не выкачивал, 22-й порт всего интернета непрерывно сканируется червями-майнерами на предмет наличия пользователей типа admin/user/test с паролями типа 123456, 123qwe!@#, и прочей дичью. Автор об этом тоже писал, если вы заметили.
                    0
                    Нет, там всего 6 попыток авторизации. Причем вход под user — с первой попытки. Брутфорсить через ssh гораздо дольше и затратнее (ты не знаешь, есть ли такая учетка вообще, после скольки попыток ты попадешь в бан, итд), чем брутфорсить хэш пароля локально, никто ничего даже не увидит.
                    Плюс вы невнимательно прочитали тему — такой юзер уже был во всех сборках. А значит хацкер просто арендовал когда то такой же сервер и нашел эту учётку, и подобрал пароль к ней. Потом уже он начал ходить в гости к остальным…
                      –3
                      Вы не поняли. Никто ничего не брутфорсит. Перебирается просто несколько фиксированных паролей к нескольким учёткам. Это никак не зависит от того, есть ли юзер в сборках, арендовал ли хакер сервер, и подобрал ли к ней пароль. Я даже больше скажу, эти же пароли и логины подбираются к виндовым серверам с подключением через RDP. Вы можете легко это проверить, выставьте в интернет порт 22 или 3389, и через пару часов увидите в логе попытки подключения от тех же самых пользователей.
                        0
                        Специально для вас дёрнул лог:
                        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

                        и т.д., и т.п.
                          0
                          А при чем тут ваш лог непонятно откуда, и как он связан с конкртно этим случаем в статье? Да, я знаю, что есть такие боты, которые стучатся, да, мы все их давным давно наблюдаем.
                          Но посмотрите логи выше в статье, там пользователь 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го раза.
                            +2
                            А при чем тут ваш лог непонятно откуда, и как он связан с конкртно этим случаем в статье?

                            Объясняю. Мой лог связан с конкретно этим случаем в статье следующим образом: он является результатом работы одного и того же вредоносного ПО. Если вы внимательно посмотрите на лог автора статьи, то вы увидите тот же самый пакет подключений, идущих друг за другом в течение нескольких секунд: сначала test, затем debian, osmc, ubnt, admin, и только восьмое подключение с именем пользователя user оказалось успешным, поэтому лог автора на этом обрывается, а мой лог продолжается дальше с другими пользователями. По сути, бот перебирает не пароли, а учётные записи с паролем 123456, и только для учётки admin он пробует ещё несколько паролей, в частности 123qwe!@# и 123qwe! (статистически это самые распространённые пароли, подходящие под политику сложности). После того, как червь нашёл подходящую учётку, он начинает не только майнить чего-то там, но и начинает с заражённой машины сканировать интернет в попытках размножиться, за что, собственно, автора и забанили:
                            зафиксирована аномальная сетевая активность: попытки подключения к большому количеству произвольных серверов по порту 22 (SSH)

                            А всякая лирика с вариантами, как и фантазии автора насчёт злобного хакера на площадке хостера к реальности не имеют никакого отношения.
                              0
                              Спасибо, интересное предложение. Действительно похоже на правду.
                              1cloud надо в сто к одному)))
                              0
                              user/user, в чём проблема?
                    –1
                    А зачем вы вообще разрешаете SSH-аутентификацию по паролю? В нормальных облачных провайдерах она выключена по умолчанию.
                  +3
                  только я не вижу в этом комментарии ничего про шаблон c Windows?
                    +3
                    Прошу прощения за оффтоп, но можно было написать хотя бы как-то так:

                    Мы устранили уязвимость сегодня в 12:08.

                    В нашем шаблоне Debian 8.7 от 30.07.2018 действительно была учётная запись «user» со слабым паролем. Она появилась из-за ошибки наших сотрудников, которые занимались этим шаблоном. Неизвестный злоумышленник подобрал пароль и смог подключаться к уязвимым серверам.

                    Мы уже сообщили об уязвимости всем, кто пользовался этим шаблоном, и исправили её. Во всех остальных наших шаблонах этой уязвимости нет.

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

                    Скоро мы выложим подробный отчёт об этой уязвимости в нашем блоге.

                    Прошу прощения за нашу ошибку. (%Имя-Отчество Автора%), спасибо за вашу помощь в решении проблемы.

                    Технический директор, Иванов И.И.


                    В вашем ответе сплошной канцелярит, размытые формулировки, стена мусорного текста и неуважение. Не надо так.

                    P.S. Про извинения
                      +1
                      А вот в рамках извинений, расскажите, а как вы эти образа собираете и тестируете? DIB или что-то другое?
                        0
                        Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.
                        Сценарий новой серии готов, можно снимать.
                        +2
                        Что можно сказать по ситуации описанной в данной статье?…
                        Мы облажались. И облажались по-крупному.
                        Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
                        Естественно, была выплачена компенсация по SLA с округлением в большую сторону.

                        Результаты внутреннего расследования инцидента
                        В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
                        Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
                        Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
                        Откуда взялся пользователь user?
                        При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.

                        Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
                        Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
                        В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.

                        Почему последовала неадекватная реакция первого уровня поддержки?
                        По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
                        1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
                        2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
                        Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
                        Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.

                        Что мы сделали, чтобы подобная ситуация не повторилась

                        • Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
                        • Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
                        • Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
                        • Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
                        • Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.

                        Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.

                          0
                          Очень достойный ответ! А могли бы Вы также написать статью, о том как готовите шаблоны, как подходите к выбору состава шаблона, как производите тестирование? Желательно с деталями и подробностями. Я думаю эта информация была бы многим интересна.
                            0
                            Хорошая идея.
                            Посмотрим, что удастся собрать по этой теме.
                        +2

                        Фэйл, конечно, по-настоящему эпический. Но вопрос — а сами-то вы куда смотрели про создании и конфигурировании серверов? :) Как можно было не заметить левого юзера, да ещё с правами удалённого входа?


                        последние месяцы на Windows серверах 1cloud, мы начали замечать аномальную нагрузку, но не придавали этому особого значения

                        А с этим так и не разобрались?

                          +7
                          Как можно было не заметить левого юзера

                          Простите конечно, но повторюсь, что мы не арендуем сервера не у дяди Пети, почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать? 1cloud обязан предоставлять клиентам чистые сборки! У нас создаются десятки серверов в день, если каждый проверять вручную, то придется для этого нанимать отдельного сотрудника…

                          А с этим так и не разобрались?

                          Пока никак, к сожалению. Открываю диспетчер задач, тогда сервер перестает тупить. То есть приходится работать с открытым диспетчером задач, тогда нагрузка на сервер снижается. Я так понимаю, что при открытии диспетчера задач перестает работать установленное вредоносное ПО.
                            +1
                            docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
                            как вариант, может то по на него реагировать не будет.
                              –5
                              почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать?

                              И даже ваша собственная история не дала вам ответ на вопрос, "почему должны"? :) Если вкратце, потому, что прямая обязанность ИТ-службы — понимать, что происходит на обслуживаемых ей серверах. Я вас могу хоть как-то понять, если вы не айтишник, а просто менеджер, который щелкает на кнопочку "заказать сервер в облаке". Но в таком случае надо заключать договор на обслуживание серверов с кем-то, кто понимает, что делает.


                              Открываю диспетчер задач, тогда сервер перестает тупить.

                              Диспетчер задач для мониторинга не нужен, это так, средство быстро примерно оценить происходящее. А мониторить можно много чем, от штатного perfmon до самописных скриптов, если какая-то дрянь маскируется от всех штатных средств, было бы желание… Начать можно с process explorer от sysinternals, может сразу будут видны левые процессы.

                                +6
                                «почему должны»? :) Если вкратце, потому, что прямая обязанность ИТ-службы — понимать, что происходит на обслуживаемых ей серверах.

                                Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей, а тем более без инжектов вредоносного ПО. Остальное аргументы не имеет отношения к делу!

                                А если более подробно, то:

                                Во-первых выше я уже писал «… хотя мы видели таких пользователей на всех серверах на протяжении всего периода использования серверов.» Возможно не на всех, но на многих серверах, включая Windows сервера, присутствовал такой пользователь. Мы думали, что это какая-то особенность шаблона ОС и не предавали этому значения, так как ранее никаких проблем не испытывали. Прошу заметить, что сборку ОС предоставляет нам 1cloud, соответственно они за нее и должны отвечать! По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер. Речь идет не о нашей некомпетентности, а о некомпетентности сотрудников 1cloud. Если это дело рук кого-то из сотрудников, то это серьезное преступление!

                                Во-вторых я не менеджер! Я знаю, что говорю. Мы нашли проблему на сервере ровно через 5 минут после начала осмотра сервера. Мы работаем с большим количеством серверов, как облачных, так и обычных, но с таким вопиющим нарушением сталкиваемся впервые! На 1cloud ничего жизненно важного никогда не держали, понимали, что у них все далеко не идеально. Никто не предавал особого значения этим пользователям. Все важное всегда держим на digitalocean, где не приходится искать дыры в сборках ОС.
                                  0
                                  Как бы вам объяснить… Вот идете вы по тротуару, а там лежат грабли. Вы на них наступаете и получаете по лбу. Тот, кто их туда положил — несомненно, нехороший человек. И, если бы вы прогуливались с девушкой и смотрели на звёзды :), винить можно было бы только его. Но, если вы на работе и в ваши непосредственные обязанности входит в том числе очистка тротуара от граблей, то для оценки вашего собственно профессионализма совершенно неважно, кто и почему их туда положил — важно, что вы их не заметили. Не какую-нибудь хитро замаскированную ловушку, а такие здоровенные садовые грабли с большой деревянной ручкой. :) Лоб, конечно, ваш, и вам решать, делать выводы или нет. Но контроль за учетками и удаленным доступом к серверам — это такие азы, что даже удивительно, что тут что-то приходится объяснять. Тем более, если у вас «создаются десятки серверов в день» — никакой «отдельный человек», чтобы всё проверять, тут не нужен — нужна автоматическая заливка проверенного вами конфига и мониторинг.

                                  > где не приходится искать дыры в сборках ОС.

                                  Или же вы можете просто ничего о них не знать. Если пропустили что-то столь очевидное, как левый пользователь с удаленным доступом, то можете и куда менее очевидные вещи пропустить.
                                    +3
                                    Считаю, что нет смысла продолжать далее данный диалог, так как от Вас пахнет кем-то причастным к данной ситуации с 1cloud) Не понимаю, при чем тут мы вообще? Мы что сделали плохого? Потроллить просто нужно или что? По тротуару мы идем бесплатно, а сервера арендуем за деньги.
                                      +1
                                      Вы ничего плохого не сделали. У вас просто заведомо уязвимая позиция «мы заплатили деньги, значит, все хорошо, и ничего проверять не надо». При этом аргументация такой позиции у вас на уровне «вот в Digital Ocean» все хорошо, им мы доверяем.

                                      Дело в том, что у того же DO тоже вполне себе обнаруживаются время от времени уязвимости, никто не без греха. И «пофиксить» их без вмешательства с вашей стороны тот же DO не всегда может. Потом вы пропустите письмо от DO с просьбой «нажать вот эти кнопки вот в такой последовательности» и будете писать ровно такой же пост, только уже про «плохой DigitalOcean».
                                      0

                                      И хорошо ещё, если грабли не детские...

                                      0
                                      del
                                        –2
                                        Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 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, про данного провайдера я услышал благодаря этой статье, я не укоряю ни вас лично, ни провайдера — це исключительно размышления и вопросы.
                                          0
                                          Справедливости ради, вы в данный момент ведете себя не сильно лучше поддержки 1Cloud.
                                          Вот это место:
                                          По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер.

                                          выглядит достаточно сомнительно.

                                          Почему именно сотрудник 1cloud? Логичнее предположить, что пользователь — тупо шаблонный, и во всех контейнерах у него один и тот же пароль. Для того, чтобы одноразово подобрать пароль и потом использовать его на всех инстансах, совершенно не обязательно быть сотрудником 1Cloud. В конце концов сотруднику проще тупо «заинжектить дичь» напрямую в шаблон ОС, чтобы не «палиться» с логами авторизации при последующих коннектах с целью «заинжектить дичь».

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

                                          Ну а вот это:
                                          Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей

                                          вообще достаточно странная позиция.

                                          «Мы не должны как-либо проверять качество получаемой нами услуги» — достаточно уязвимая позиция, например, вам не кажется? Это не ваша прямая обязанность, конечно, но оценка качества — нормальная позиция адекватного человека. При этом, если вы сами предоставляете услугу на базе сервисов 1Cloud третьей стороне, то проверка качества сервиса 1Cloud таки становится вашей прямой обязанностью, вы ведь принимаете на себя обязательство о качестве вашего сервиса уже перед вашим клиентом.
                                          +6

                                          Т. Е. Я заплатил деньги за услугу, которая должна быть качественной, ещё при этом нанять безопансика, чтобы он проверил на предмет дыр? Так себе услуга…

                                            0
                                            Если честно, сам факт того, что услуга платная, вообще ничего не говорит о ее качестве, например. С вашей логикой любая услуга — так себе, просто по определению услуги.
                                              +2
                                              с твоей логикой при покупке пива надо бежать в лабораторию, а не ожидать, что в банку налито то за что ты заплатил, а не бодяга.
                                              логика ущербна.
                                                0
                                                Какбэ, в текущей ситуации на VPSке пользователя был создан левый пользователь. Так что вернее выглядит следующая ассоциация:
                                                Ты купил пива, а дома, когда наливал его в стакан, заметил, что в бутылке плавает лягушка, а пена на пиве фиолетового цвета.
                                                — Нет, быть не может, что говно попалось! — подумал ты. — Я же ДЕНЬГИ ЗАПЛАТИЛ!
                                                Зажмурился, заткнул нос, постарался максимально абстрагироваться и таки выпил.
                                          +2
                                          Простите конечно, но повторюсь, что мы не арендуем сервера не у дяди Пети, почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать? 1cloud обязан предоставлять клиентам чистые сборки! У нас создаются десятки серверов в день, если каждый проверять вручную, то придется для этого нанимать отдельного сотрудника…
                                          Знаете фразу «пешеход всегда прав, особенно если мертв»?
                                          0
                                          219.135.136.144
                                          В 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
                                            +3
                                            Только что пришло новое сообщение от техподдержки. «Сервер заблокирован администратором. Причина блокировки: Зафиксирована попытка атаки». Очередной наш сервер, который был создан 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
                                              0
                                              а вы не могли бы показать логи с сервера, с каких IP идут коннекты к вам?
                                                0
                                                Выше в логе можете увидеть строки Accepted password for user from…
                                                Вот строка, например Aug 20 03:47:53 debian8x64 sshd[1383]: Accepted password for user from 219.135.136.144 port 36097 ssh2
                                              +5
                                              Понапишите им во все фейсбуки, телеграмы, инстаграмы с просьбой срочно(!!!) объективно(!!!) рассмотреть ваш тикет.

                                              Но вообще этот случай — полнейшая дичь конечно же…

                                                0
                                                На тикеты они отвечают, утверждают что уязвимые шаблоны более недоступны, но пока в это слабо верится…

                                                Здравствуйте!
                                                Шаблон исправлен, сейчас идет процедура его синхронизации по площадкам. Уязвимый шаблон исключили из списка доступных.
                                                  +4
                                                  Добрый день!
                                                  Подтверждаем, что данный шаблон сервера имел уязвимого пользователя user (которого там вообще не должно было быть).
                                                  О факте его наличия будет произведено внутреннее расследование с ответственными за подготовку шаблона сотрудниками (шаблон точно не был взят из общего доступа, а подготовлен нами с нуля).

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

                                                  Также будет проверены все шаблоны, которые доступны в данный момент.
                                                  Также будет добавлен дополнительный пункт в check list проверки, который используется при подготовке новых версий шаблонов.

                                                  Также в течение дня мы свяжемся со всеми Клиентами у которых были созданы серверы из уязвимых шаблонов и поможем им устранить данную уязвимость.

                                                  Большое спасибо за информацию. Верим, что подобный fail мы более не повторим.
                                                    +3
                                                    Очень надеюсь получить развернутый и вразумительный ответ в комментариях к этой статье после проведения внутреннего расследования.
                                                      +2
                                                      Да, конечно. Информация будет предоставлена.
                                                        +1
                                                        Так где расследование, подробности?
                                                        +1
                                                        А лучше отдельной статьей
                                                        +6
                                                        Вот я тоже неоднократно замечал что тех-поддержка Ваша в любой нештатной ситуации бесполезна — «не могём, не знаем, не виноватая я»… А стоит, например, тут в личку написать, и всё решается достаточно быстро и позитивно. Возможно и этой статьи бы не было, сработай ТП профессионально. Пофиксите ТП уже, наконец)
                                                          0

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

                                                            0
                                                            Мы признаем, что уязвимость имела место быть. Клиенту компенсирован простой серверов в соответствии с SLA.
                                                              0
                                                              компенсация-то хоть нормальная, а не за сутки?
                                                                0
                                                                А разве это важно? Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости! Мы вообще не особо претендовали на компенсацию. «Согласно SLA данное время простоя попадает в промежуток, соответствующий сумме 20% от месячного потребления недоступных ВМ.»
                                                                  0
                                                                  по моему опыту — важно.
                                                                  когда клиенту после суточного простоя компенсируешь «строго по договору» — его с заметной вероятностью больше не увидишь.
                                                                    0
                                                                    Вопрос в том, нужен ли им клиент, который опубликовал все это на хабре)
                                                                      +2
                                                                      Конечно нужен! Ведь эта статья сохранила им не одного клиента! Все могло бы быть гораздо хуже, если бы поддержка продолжала спускать все на тормозах, мол «сам дурак».
                                                                    +1
                                                                    Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости!

                                                                    Такое — это наличие уязвимостей на сервере в принципе? Я вас разочарую, повторится, и не раз, и не только у 1Cloud.
                                                                    А наказание виновников «по всей строгости» вам, простите, зачем?
                                                        0
                                                        Помогли ли альтернативные просмотрщики процессов на виндовсе?
                                                        Если еще и виндовые машины заражены — это полнейший провал.

                                                          0
                                                          Честно говоря, нет ни времени, ни желания что-либо еще проверять. Мне кажется, мы сделали для 1cloud достаточно, подробно расписав критическую уязвимость. Пусть уже сами хоть что-то сделают!
                                                            +1
                                                            Тут с вами согласен. Просто распирает любопытство…
                                                            Как будет время, взгляните… расскажите :)
                                                              0
                                                              Вот это вообще не в вашу пользу как специалиста говорит, например.
                                                              0
                                                              Windows шаблоны данной уязвимости не подвержены. Но они также будут проверены на предмет других проблем
                                                              0
                                                              Это уже 4-й день вы с ними воюете?
                                                                +3
                                                                Вторые сутки
                                                                  +3
                                                                  Держитесь :)
                                                                +4
                                                                такое везде у компаний происходит.
                                                                в европе у крупнейшей сети дата-центров, ОВХ, с начала лета не отключаются заказы. ну т.е. их не продляешь, они удаляются, но по факту не удаляются и прожигают электричество. вся канада, весь сингапур и вся австралия. мы короче все лето туда пишет, доказательства скриншоты прикладываем, даже видос для тупых сняли. но не один сотрудник не доложил вышестоящим, а просто клал болты. мы даже продлили услугу для прикола такую кривую, она конечно же зависла. но сотрудник взял ее просто и вручную закрыл продление, мало того что услуга конечно же не вернулась нам в аккаунт, а значит он просто отобрал деньги. но он снова не доложил никому. короче люди уже там тачки с супер процессорами покупают, майнинг запускают, и не продляют. а сервера продолжают работать. уже в наличии даже нету никаких услуг в сингапуре и австралии :) абсолютно все сотрудники работают там не за компанию, а против компании. и так поверь мне — абсолютно везде. в РФ еще хуже, там вообще работают люди которым наплевать на деньги компании, им главное зар плату получать. так везде. полная халтура в отрасли. и даже в IT. взять тот же яндекс например, историю с кинопоиском. или то как сейчас они уничтожают pdd.yandex.ru, переводя людей в школьный аналог который глючит на каждом шаге. нормальных сотрудников нигде нет. это беда всего современного интернета. на хабре например тоже самое, тостер.ру загубили как раз модераторы и сотрудники не разу видимо не общавшиеся на форумах в интернете.
                                                                  +5
                                                                  Как-то просил у хостера временную виртуалку для тестов IPsec. Протестировал, пишу, что больше она мне не нужна, можете удалять, а они не реагируют. Написал второй раз — снова нет реакции. Так и пользуюсь уже года 4.
                                                                    0
                                                                    Пора сдавать в аренду ;-)
                                                                      0
                                                                      Такая же ситуация :) Арендовал сервачек, год попользовался, стал не нужен, перестал платить, в биллинге статус offline… но сервак уже 2 год бесплатно работает.
                                                                    +7
                                                                    Дичь какая то. Это даже не фэйлище. А саботаж чистой воды.Как этот 1Cloud жить то дальше собирается?
                                                                      +5
                                                                      Да как все живут, с покерфейсом.
                                                                        0
                                                                        Ну как-как… Всем по… (клиентам нет, но кто слушает клиента?)
                                                                        0
                                                                        В ubuntu для lxc (который через lxc-create из коробки качается) добавлен пользователь по умолчанию ubuntu:ubuntu.
                                                                        Думаю, у вас примерно то же самое.
                                                                          0
                                                                          Все «cloud» образа, которые представлены на сайтах тех или иных дистрибов, имеют пользователя с названием ОС — centos ,debian ,ubuntu etc
                                                                            0
                                                                            Не возьмусь говорить за cloud-образы, но в debian в lxc такой ухни нет =)
                                                                          0
                                                                          Я понимаю, что на деревню дедушке писать эффективнее, чем обращаться к нашим правоохранителям (а вообще-то это можно расценивать как нарушение работы информационных систем, т.е. взлом ваших серверов… соответственно и дело уголовное можно смело заводить и выигрывать). Просто призываю всех пользователей этого сервиса (коим я, к счастью, не являюсь) попробовать создать дебиан сервер для теста и если там будет юзер user — отписать техподдержке «что за фигня» и «верните деньги за этот тестовый сервер, там троян»… Если запрос «что за фигня» техподдержка легко проигнорирует, то запрос на массовый (пусть и копеечный) возврат денег уже может кого-то напрячь.
                                                                            0
                                                                            Не понимаю, какие могут быть преимущества таких облаков по сравнению с AWS. Цена? Набросал сервер примерно эквивалентный ec2 t2.micro, цена выходит такая же или дороже… Только качество сервиса у AWS мирового уровня и гарантии начинаются с нескольких девяток у 99%.
                                                                            • UFO just landed and posted this here
                                                                                +1
                                                                                Может быть проблема в кириллице в имени и фамилии.
                                                                                  0
                                                                                  Определенно! Проблема в локации. Россию и СНГ мало кто любит (благодаря кардерам...)! С европейских аккаунтов не возникает подобных проблем, проверено на личном опыте.
                                                                                  • UFO just landed and posted this here
                                                                                      0
                                                                                      Проблема в отношении. Западным сервисам проще забанить российские карты (или по-скотски требовать документы) чем разбираться, кто кардер, а кто честный пользователь. Ну и проблема в устаревших незащищенных системах Visa/Mastercard, которые позволяют воровать данные карт и до сих пор не могут сделать нормальную систему защиты.
                                                                                    0
                                                                                    вы забываете про локализацию хранения данных. Плюс еще свежи воспоминания про массовые простои в западных облаках во время погони за тграммом в конце апреля. Поэтому все массово (действительно массово) идут в рублака — селектел, мрг, 1клауд. Я-блоко говорят запустится в конце осени (уже пару лет так говорят, правда). Плюс у бизнеса чаще всего в РФ (я не знаю как на западе — не берусь судить) для юриков == лиц с большим месячным чеком == цена за условную виртуалку или гигабайт гораздо дешевле
                                                                                    +3
                                                                                    сюр какой то, не в защиту 1cloud
                                                                                    «у нас на виндовом сервере большая нагрузка, делать мы ничего не будем, пусть диспетчер задач будет открыт»
                                                                                      0
                                                                                      egorbI4
                                                                                      Такое случается у разных провайдеров. Например, у FirstVDS я замечал то же самое.

                                                                                      Когда моя статья об этом была опубликована на Хабре (до того, как она стала заблокирована) — попадались комментарии, в которых писалось, что это норм ситуация для техподдержки (чтоб оперативно решать проблемы у клиента). При этом клиента об этом не предупреждают заранее. Сам это не одобряю. Просто делюсь наблюдениями о том, зачем это могло понадобиться провайдеру.
                                                                                      С тех пор при аренде серверов у любых провайдеров в обязательном порядке проверяю наличие пользователей
                                                                                        0
                                                                                        Извините за нескомность. А Вам сколько лет?
                                                                                          0
                                                                                          Автору статьи: Просто напиши мне в личку, готов решить все проблемы с *nix\Win серверами + поставим нормальный мониторинг на Nagios, чтоб больше никаких левых пользователей\нагрузок. Надо будет — свой образ сделаем, чтоб с гарантией. По цене договоримся ;-)
                                                                                          1cloud: мужики, вы чего? Ну возьмите уже этот образ, расковыряйте, что там за пароль, зайдите сами и поменяйте на что-то сложное. Костыль конечно, но хоть абузы сыпаться не будут. ИМХО скриптец при наличии пароля написать не проблема. Да и за такое время если у Вас реально специалисты есть можно было бы расследовать и статью написать с подробностями. Уже бы и г-ном тут перестали поливать. Косяки то у всех бывают да еще какие. А пока молчите — тут градус растет, а репутация падает.
                                                                                            0
                                                                                            Что можно сказать по ситуации описанной в данной статье?…
                                                                                            Мы облажались. И облажались по-крупному.
                                                                                            Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
                                                                                            Естественно, была выплачена компенсация по SLA с округлением в большую сторону.

                                                                                            Результаты внутреннего расследования инцидента
                                                                                            В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
                                                                                            Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
                                                                                            Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
                                                                                            Откуда взялся пользователь user?
                                                                                            При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.

                                                                                            Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
                                                                                            Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
                                                                                            В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.

                                                                                            Почему последовала неадекватная реакция первого уровня поддержки?
                                                                                            По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
                                                                                            1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
                                                                                            2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
                                                                                            Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
                                                                                            Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.

                                                                                            Что мы сделали, чтобы подобная ситуация не повторилась

                                                                                            • Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
                                                                                            • Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
                                                                                            • Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
                                                                                            • Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
                                                                                            • Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.

                                                                                            Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.

                                                                                              0

                                                                                              1) постановка задачи.
                                                                                              2) контроль
                                                                                              3) результат.


                                                                                              Очень часто косяки встречаются на п2. Ввиду экономии или чего-либо ещё. Сам косячил. Аргументирую так: " а кто меня проконтролировал, как исполнителя?"


                                                                                              • должен сам себя контролировать! Если всех контролировать, то это колоссальные издержки. Считаю, что нет. Промежуточный контроль нужен. Группа системных администраторов и старший системный администратор. Он контролирует не для того что бы наказать, а для того что бы избежать последствий.

                                                                                              Only users with full accounts can post comments. Log in, please.