Началось все с того, что последние месяцы на Windows серверах 1cloud, мы начали замечать аномальную нагрузку, но не придавали этому особого значения, так как Windows сервера в основном использовались для выполнения различных мелких задач типа использование браузера и любых других программ, да и особо не было желания выяснять что там и как.
Но на днях произошла весьма неприятная и оскорбительная ситуация со стороны сотрудников 1cloud, которая подтолкнула нас на публикацию данной статьи. Мы используем сервера 1cloud уже около 1.5-2х лет, правила использования серверов не нарушали. Я был неприятно удивлен, когда зашел в аккаунт и увидел, что все 40 наших серверов заблокированы с пометкой «Сервер заблокирован администратором. Причина блокировки: брутфорс.». Собрался писать в сапорт и увидел новое сообщение от службы техподдержки, в котором было сказано:
Здравствуйте.
С Вашего сервера IP 111.111.11.111 зафиксирована аномальная сетевая активность: попытки подключения к большому количеству произвольных серверов по порту 22 (SSH)
Возможно, сервер был взломан. Вам необходимо оперативно устранить проблему.
В случае отсутствия реакции по данному обращению сервер будет отключен от сети.
Из-за ошибки сотрудника или из-за каких-либо проблем с системой управления серверами, были выключены все 40 серверов вместо одного проблемного, и они были недоступны в течение суток. От саппорта поступило сообщение следующего содержания:
Серверы разблокировали, они включатся автоматически. По внутренним инструкциям должен был быть отключен один проблемный сервер, данный инцидент будет расследован.
Просьба во избежание подобных ситуаций реагировать на обращение оперативней.
Также просьба сообщить по факту устранения проблемы с сервером.
Это конечно неприятная ситуация, но бывает, подумал я, и мы начали разбираться в проблеме, из-за которой сервера были блокированы. Сервера автоматически не включились, как нам обещали, и мне пришлось вручную запускать все сервера, но это мелочь по сравнению с основной проблемой. Залогинились на сервер, и сразу заметили странность, что по ssh мы подключались в последний раз 20го августа, а различные вредоносные файлы были залиты на сервер 21го и 22го числа. Как оказалось, во время создания каждого сервера на 1cloud, добавляется какой-то сомнительный пользователь «user», в папке которого в дальнейшем начала появляться куча вредоносных файлов, включая майнер xrig.
Начали звонить в сапорт, объяснили ситуацию, спросили, что за пользователь «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 раз и навсегда!
Комментарии (82)
ildarz
24.08.2018 11:38-1Фэйл, конечно, по-настоящему эпический. Но вопрос — а сами-то вы куда смотрели про создании и конфигурировании серверов? :) Как можно было не заметить левого юзера, да ещё с правами удалённого входа?
последние месяцы на Windows серверах 1cloud, мы начали замечать аномальную нагрузку, но не придавали этому особого значения
А с этим так и не разобрались?
egorbI4 Автор
24.08.2018 11:46+1Как можно было не заметить левого юзера
Простите конечно, но повторюсь, что мы не арендуем сервера не у дяди Пети, почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать? 1cloud обязан предоставлять клиентам чистые сборки! У нас создаются десятки серверов в день, если каждый проверять вручную, то придется для этого нанимать отдельного сотрудника…
А с этим так и не разобрались?
Пока никак, к сожалению. Открываю диспетчер задач, тогда сервер перестает тупить. То есть приходится работать с открытым диспетчером задач, тогда нагрузка на сервер снижается. Я так понимаю, что при открытии диспетчера задач перестает работать установленное вредоносное ПО.maksqwe
24.08.2018 11:52docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
как вариант, может то по на него реагировать не будет.
ildarz
24.08.2018 12:18почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать?
И даже ваша собственная история не дала вам ответ на вопрос, "почему должны"? :) Если вкратце, потому, что прямая обязанность ИТ-службы — понимать, что происходит на обслуживаемых ей серверах. Я вас могу хоть как-то понять, если вы не айтишник, а просто менеджер, который щелкает на кнопочку "заказать сервер в облаке". Но в таком случае надо заключать договор на обслуживание серверов с кем-то, кто понимает, что делает.
Открываю диспетчер задач, тогда сервер перестает тупить.
Диспетчер задач для мониторинга не нужен, это так, средство быстро примерно оценить происходящее. А мониторить можно много чем, от штатного perfmon до самописных скриптов, если какая-то дрянь маскируется от всех штатных средств, было бы желание… Начать можно с process explorer от sysinternals, может сразу будут видны левые процессы.
egorbI4 Автор
24.08.2018 16:59+6«почему должны»? :) Если вкратце, потому, что прямая обязанность ИТ-службы — понимать, что происходит на обслуживаемых ей серверах.
Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей, а тем более без инжектов вредоносного ПО. Остальное аргументы не имеет отношения к делу!
А если более подробно, то:
Во-первых выше я уже писал «… хотя мы видели таких пользователей на всех серверах на протяжении всего периода использования серверов.» Возможно не на всех, но на многих серверах, включая Windows сервера, присутствовал такой пользователь. Мы думали, что это какая-то особенность шаблона ОС и не предавали этому значения, так как ранее никаких проблем не испытывали. Прошу заметить, что сборку ОС предоставляет нам 1cloud, соответственно они за нее и должны отвечать! По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер. Речь идет не о нашей некомпетентности, а о некомпетентности сотрудников 1cloud. Если это дело рук кого-то из сотрудников, то это серьезное преступление!
Во-вторых я не менеджер! Я знаю, что говорю. Мы нашли проблему на сервере ровно через 5 минут после начала осмотра сервера. Мы работаем с большим количеством серверов, как облачных, так и обычных, но с таким вопиющим нарушением сталкиваемся впервые! На 1cloud ничего жизненно важного никогда не держали, понимали, что у них все далеко не идеально. Никто не предавал особого значения этим пользователям. Все важное всегда держим на digitalocean, где не приходится искать дыры в сборках ОС.ildarz
24.08.2018 17:58Как бы вам объяснить… Вот идете вы по тротуару, а там лежат грабли. Вы на них наступаете и получаете по лбу. Тот, кто их туда положил — несомненно, нехороший человек. И, если бы вы прогуливались с девушкой и смотрели на звёзды :), винить можно было бы только его. Но, если вы на работе и в ваши непосредственные обязанности входит в том числе очистка тротуара от граблей, то для оценки вашего собственно профессионализма совершенно неважно, кто и почему их туда положил — важно, что вы их не заметили. Не какую-нибудь хитро замаскированную ловушку, а такие здоровенные садовые грабли с большой деревянной ручкой. :) Лоб, конечно, ваш, и вам решать, делать выводы или нет. Но контроль за учетками и удаленным доступом к серверам — это такие азы, что даже удивительно, что тут что-то приходится объяснять. Тем более, если у вас «создаются десятки серверов в день» — никакой «отдельный человек», чтобы всё проверять, тут не нужен — нужна автоматическая заливка проверенного вами конфига и мониторинг.
> где не приходится искать дыры в сборках ОС.
Или же вы можете просто ничего о них не знать. Если пропустили что-то столь очевидное, как левый пользователь с удаленным доступом, то можете и куда менее очевидные вещи пропустить.egorbI4 Автор
24.08.2018 18:49+3Считаю, что нет смысла продолжать далее данный диалог, так как от Вас пахнет кем-то причастным к данной ситуации с 1cloud) Не понимаю, при чем тут мы вообще? Мы что сделали плохого? Потроллить просто нужно или что? По тротуару мы идем бесплатно, а сервера арендуем за деньги.
qrKot
25.08.2018 12:07+1Вы ничего плохого не сделали. У вас просто заведомо уязвимая позиция «мы заплатили деньги, значит, все хорошо, и ничего проверять не надо». При этом аргументация такой позиции у вас на уровне «вот в Digital Ocean» все хорошо, им мы доверяем.
Дело в том, что у того же DO тоже вполне себе обнаруживаются время от времени уязвимости, никто не без греха. И «пофиксить» их без вмешательства с вашей стороны тот же DO не всегда может. Потом вы пропустите письмо от DO с просьбой «нажать вот эти кнопки вот в такой последовательности» и будете писать ровно такой же пост, только уже про «плохой DigitalOcean».
NETmare
25.08.2018 02:27-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, про данного провайдера я услышал благодаря этой статье, я не укоряю ни вас лично, ни провайдера — це исключительно размышления и вопросы.
qrKot
25.08.2018 12:02Справедливости ради, вы в данный момент ведете себя не сильно лучше поддержки 1Cloud.
Вот это место:
По моему я четко объяснил, что какой-то сотрудник 1cloud имеет пароль от пользователя user и инжектит всякую дичь на сервер.
выглядит достаточно сомнительно.
Почему именно сотрудник 1cloud? Логичнее предположить, что пользователь — тупо шаблонный, и во всех контейнерах у него один и тот же пароль. Для того, чтобы одноразово подобрать пароль и потом использовать его на всех инстансах, совершенно не обязательно быть сотрудником 1Cloud. В конце концов сотруднику проще тупо «заинжектить дичь» напрямую в шаблон ОС, чтобы не «палиться» с логами авторизации при последующих коннектах с целью «заинжектить дичь».
Это не отменяет того факта, что у 1Cloud дыра в шаблоне контейнера размером не то что с футбольные ворота, а скорее с футбольное поле, но хотелось бы, чтобы вы, как человек вопрошающий, придерживались корректных формулировок.
Ну а вот это:
Вообще-то, если вкратце, то мы никому ничего не должны, и прямая обязанность 1cloud — предоставлять клиентам сервера без уязвимостей
вообще достаточно странная позиция.
«Мы не должны как-либо проверять качество получаемой нами услуги» — достаточно уязвимая позиция, например, вам не кажется? Это не ваша прямая обязанность, конечно, но оценка качества — нормальная позиция адекватного человека. При этом, если вы сами предоставляете услугу на базе сервисов 1Cloud третьей стороне, то проверка качества сервиса 1Cloud таки становится вашей прямой обязанностью, вы ведь принимаете на себя обязательство о качестве вашего сервиса уже перед вашим клиентом.
easty
24.08.2018 21:20+6Т. Е. Я заплатил деньги за услугу, которая должна быть качественной, ещё при этом нанять безопансика, чтобы он проверил на предмет дыр? Так себе услуга…
qrKot
25.08.2018 12:10Если честно, сам факт того, что услуга платная, вообще ничего не говорит о ее качестве, например. С вашей логикой любая услуга — так себе, просто по определению услуги.
Yo1
25.08.2018 12:32+1с твоей логикой при покупке пива надо бежать в лабораторию, а не ожидать, что в банку налито то за что ты заплатил, а не бодяга.
логика ущербна.qrKot
27.08.2018 07:38Какбэ, в текущей ситуации на VPSке пользователя был создан левый пользователь. Так что вернее выглядит следующая ассоциация:
Ты купил пива, а дома, когда наливал его в стакан, заметил, что в бутылке плавает лягушка, а пена на пиве фиолетового цвета.
— Нет, быть не может, что говно попалось! — подумал ты. — Я же ДЕНЬГИ ЗАПЛАТИЛ!
Зажмурился, заткнул нос, постарался максимально абстрагироваться и таки выпил.
edogs
25.08.2018 02:04+2Простите конечно, но повторюсь, что мы не арендуем сервера не у дяди Пети, почему мы должны просматривать кадждый сервер на наличие всякой дряни? Почему мы должны об этом думать? 1cloud обязан предоставлять клиентам чистые сборки! У нас создаются десятки серверов в день, если каждый проверять вручную, то придется для этого нанимать отдельного сотрудника…
Знаете фразу «пешеход всегда прав, особенно если мертв»?
ForNeVeR
26.08.2018 07:53Возможно, вас повеселит или заинтересует эта статья от Microsoft: Windows Update может создавать повышенную нагрузку, если в ОС существует пользователь с именем, содержащим подстроку "user".
AndrewFoma
24.08.2018 11:57219.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
egorbI4 Автор
24.08.2018 11:57+1Только что пришло новое сообщение от техподдержки. «Сервер заблокирован администратором. Причина блокировки: Зафиксирована попытка атаки». Очередной наш сервер, который был создан 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 ssh2AndrewFoma
24.08.2018 12:08а вы не могли бы показать логи с сервера, с каких IP идут коннекты к вам?
egorbI4 Автор
24.08.2018 12:10Выше в логе можете увидеть строки 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
pupsegadm
24.08.2018 12:05+1Понапишите им во все фейсбуки, телеграмы, инстаграмы с просьбой срочно(!!!) объективно(!!!) рассмотреть ваш тикет.
Но вообще этот случай — полнейшая дичь конечно же…
egorbI4 Автор
24.08.2018 12:08На тикеты они отвечают, утверждают что уязвимые шаблоны более недоступны, но пока в это слабо верится…
Здравствуйте!
Шаблон исправлен, сейчас идет процедура его синхронизации по площадкам. Уязвимый шаблон исключили из списка доступных.
VisMaster
24.08.2018 12:33Добрый день!
Подтверждаем, что данный шаблон сервера имел уязвимого пользователя user (которого там вообще не должно было быть).
О факте его наличия будет произведено внутреннее расследование с ответственными за подготовку шаблона сотрудниками (шаблон точно не был взят из общего доступа, а подготовлен нами с нуля).
Спешим отметить, что версия уязвимого шаблона была выпущена 30.07.2018, поэтому серверы, созданные ранее из этого шаблона, такой уязвимости не имеют.
На текущий момент уязвимый шаблон выведен из эксплуатации, исправленный шаблон синхронизируется по площадкам и скоро будет запущен.
Также будет проверены все шаблоны, которые доступны в данный момент.
Также будет добавлен дополнительный пункт в check list проверки, который используется при подготовке новых версий шаблонов.
Также в течение дня мы свяжемся со всеми Клиентами у которых были созданы серверы из уязвимых шаблонов и поможем им устранить данную уязвимость.
Большое спасибо за информацию. Верим, что подобный fail мы более не повторим.egorbI4 Автор
24.08.2018 12:56+2Очень надеюсь получить развернутый и вразумительный ответ в комментариях к этой статье после проведения внутреннего расследования.
fedorro
24.08.2018 13:42+1Вот я тоже неоднократно замечал что тех-поддержка Ваша в любой нештатной ситуации бесполезна — «не могём, не знаем, не виноватая я»… А стоит, например, тут в личку написать, и всё решается достаточно быстро и позитивно. Возможно и этой статьи бы не было, сработай ТП профессионально. Пофиксите ТП уже, наконец)
Sabubu
24.08.2018 16:03Если вы искренне раскаиваетесь, а не на словах, то докажите это делом, например, компенсируйте клиенту понесенные неудобства.
1cloud
24.08.2018 16:48Мы признаем, что уязвимость имела место быть. Клиенту компенсирован простой серверов в соответствии с SLA.
rdc
24.08.2018 17:30компенсация-то хоть нормальная, а не за сутки?
egorbI4 Автор
24.08.2018 17:43А разве это важно? Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости! Мы вообще не особо претендовали на компенсацию. «Согласно SLA данное время простоя попадает в промежуток, соответствующий сумме 20% от месячного потребления недоступных ВМ.»
rdc
24.08.2018 17:47по моему опыту — важно.
когда клиенту после суточного простоя компенсируешь «строго по договору» — его с заметной вероятностью больше не увидишь.egorbI4 Автор
24.08.2018 17:53Вопрос в том, нужен ли им клиент, который опубликовал все это на хабре)
Superl3n1n
24.08.2018 19:37+2Конечно нужен! Ведь эта статья сохранила им не одного клиента! Все могло бы быть гораздо хуже, если бы поддержка продолжала спускать все на тормозах, мол «сам дурак».
qrKot
25.08.2018 12:13Важно чтобы такое больше никогда не повторилось, а виновники были наказаны по всей строгости!
Такое — это наличие уязвимостей на сервере в принципе? Я вас разочарую, повторится, и не раз, и не только у 1Cloud.
А наказание виновников «по всей строгости» вам, простите, зачем?
pupsegadm
24.08.2018 12:09Помогли ли альтернативные просмотрщики процессов на виндовсе?
Если еще и виндовые машины заражены — это полнейший провал.
egorbI4 Автор
24.08.2018 12:13Честно говоря, нет ни времени, ни желания что-либо еще проверять. Мне кажется, мы сделали для 1cloud достаточно, подробно расписав критическую уязвимость. Пусть уже сами хоть что-то сделают!
pupsegadm
24.08.2018 12:15Тут с вами согласен. Просто распирает любопытство…
Как будет время, взгляните… расскажите :)
1cloud
24.08.2018 16:45Windows шаблоны данной уязвимости не подвержены. Но они также будут проверены на предмет других проблем
hostsuki
24.08.2018 13:05-1такое везде у компаний происходит.
в европе у крупнейшей сети дата-центров, ОВХ, с начала лета не отключаются заказы. ну т.е. их не продляешь, они удаляются, но по факту не удаляются и прожигают электричество. вся канада, весь сингапур и вся австралия. мы короче все лето туда пишет, доказательства скриншоты прикладываем, даже видос для тупых сняли. но не один сотрудник не доложил вышестоящим, а просто клал болты. мы даже продлили услугу для прикола такую кривую, она конечно же зависла. но сотрудник взял ее просто и вручную закрыл продление, мало того что услуга конечно же не вернулась нам в аккаунт, а значит он просто отобрал деньги. но он снова не доложил никому. короче люди уже там тачки с супер процессорами покупают, майнинг запускают, и не продляют. а сервера продолжают работать. уже в наличии даже нету никаких услуг в сингапуре и австралии :) абсолютно все сотрудники работают там не за компанию, а против компании. и так поверь мне — абсолютно везде. в РФ еще хуже, там вообще работают люди которым наплевать на деньги компании, им главное зар плату получать. так везде. полная халтура в отрасли. и даже в IT. взять тот же яндекс например, историю с кинопоиском. или то как сейчас они уничтожают pdd.yandex.ru, переводя людей в школьный аналог который глючит на каждом шаге. нормальных сотрудников нигде нет. это беда всего современного интернета. на хабре например тоже самое, тостер.ру загубили как раз модераторы и сотрудники не разу видимо не общавшиеся на форумах в интернете.ValdikSS
24.08.2018 14:23Как-то просил у хостера временную виртуалку для тестов IPsec. Протестировал, пишу, что больше она мне не нужна, можете удалять, а они не реагируют. Написал второй раз — снова нет реакции. Так и пользуюсь уже года 4.
Daar
25.08.2018 11:45Такая же ситуация :) Арендовал сервачек, год попользовался, стал не нужен, перестал платить, в биллинге статус offline… но сервак уже 2 год бесплатно работает.
inkvizitor68sl
24.08.2018 15:13В ubuntu для lxc (который через lxc-create из коробки качается) добавлен пользователь по умолчанию ubuntu:ubuntu.
Думаю, у вас примерно то же самое.ddPechkin
24.08.2018 18:43Все «cloud» образа, которые представлены на сайтах тех или иных дистрибов, имеют пользователя с названием ОС — centos ,debian ,ubuntu etc
inkvizitor68sl
24.08.2018 18:50Не возьмусь говорить за cloud-образы, но в debian в lxc такой ухни нет =)
Berkof
24.08.2018 16:06Я понимаю, что на деревню дедушке писать эффективнее, чем обращаться к нашим правоохранителям (а вообще-то это можно расценивать как нарушение работы информационных систем, т.е. взлом ваших серверов… соответственно и дело уголовное можно смело заводить и выигрывать). Просто призываю всех пользователей этого сервиса (коим я, к счастью, не являюсь) попробовать создать дебиан сервер для теста и если там будет юзер user — отписать техподдержке «что за фигня» и «верните деньги за этот тестовый сервер, там троян»… Если запрос «что за фигня» техподдержка легко проигнорирует, то запрос на массовый (пусть и копеечный) возврат денег уже может кого-то напрячь.
springimport
24.08.2018 16:59Не понимаю, какие могут быть преимущества таких облаков по сравнению с AWS. Цена? Набросал сервер примерно эквивалентный ec2 t2.micro, цена выходит такая же или дороже… Только качество сервиса у AWS мирового уровня и гарантии начинаются с нескольких девяток у 99%.
Konachan700
24.08.2018 17:37Ну вот пытался я сделать себе виртуалку на AWS… Регистрация, подтверждение карты — через пару минут бан за «использование заблокированной или истекшей карты». Хотя карта до 21 года и отлично работает. Ввожу другую — полчаса, и опять та же самая блокировка. Техподдержка молчит. Вобщем 3 карты разных банков пробовал (все реальные, не виртуалки), 3 раза бан через короткое время.
Такая же фигня у LeaseWeb — сначала регистрация «в один клик» и оплата без ворнинга о том, что использовать сервис можно только юрлицам. Потом сразу же бан и «дайте документы на ваше юрлицо». Ну хорошо, что хоть деньги вернули…
С — сервис.springimport
24.08.2018 17:43+1Может быть проблема в кириллице в имени и фамилии.
egorbI4 Автор
24.08.2018 17:51Определенно! Проблема в локации. Россию и СНГ мало кто любит (благодаря кардерам...)! С европейских аккаунтов не возникает подобных проблем, проверено на личном опыте.
Konachan700
24.08.2018 18:35Нет. Если сервис не на русском — я никогда не догадаюсь вбивать данные в нем на русском. Данные карт тоже стандартные, более того, одна карта «анонимная», то есть с MEGAFON CLIENT в имени. Скорее всего это именно сработка антифрода, ибо если сидеть без VPN, постоянно капча в гугле и прочие такие вещи — наверняка IP провайдера проспамленые, вот и агрится.
Sabubu
25.08.2018 12:23Проблема в отношении. Западным сервисам проще забанить российские карты (или по-скотски требовать документы) чем разбираться, кто кардер, а кто честный пользователь. Ну и проблема в устаревших незащищенных системах Visa/Mastercard, которые позволяют воровать данные карт и до сих пор не могут сделать нормальную систему защиты.
ddPechkin
24.08.2018 18:48вы забываете про локализацию хранения данных. Плюс еще свежи воспоминания про массовые простои в западных облаках во время погони за тграммом в конце апреля. Поэтому все массово (действительно массово) идут в рублака — селектел, мрг, 1клауд. Я-блоко говорят запустится в конце осени (уже пару лет так говорят, правда). Плюс у бизнеса чаще всего в РФ (я не знаю как на западе — не берусь судить) для юриков == лиц с большим месячным чеком == цена за условную виртуалку или гигабайт гораздо дешевле
aaalllsss
24.08.2018 19:08+3сюр какой то, не в защиту 1cloud
«у нас на виндовом сервере большая нагрузка, делать мы ничего не будем, пусть диспетчер задач будет открыт»
shanker
24.08.2018 20:26egorbI4
Такое случается у разных провайдеров. Например, у FirstVDS я замечал то же самое.
Когда моя статья об этом была опубликована на Хабре (до того, как она стала заблокирована) — попадались комментарии, в которых писалось, что это норм ситуация для техподдержки (чтоб оперативно решать проблемы у клиента). При этом клиента об этом не предупреждают заранее. Сам это не одобряю. Просто делюсь наблюдениями о том, зачем это могло понадобиться провайдеру.
С тех пор при аренде серверов у любых провайдеров в обязательном порядке проверяю наличие пользователей
pupsegadm
Мне кажется, что просто взят какой-то, около-случайный шаблон ОС, которых валяется по всему Интернету масса, проверен просто на предмет успешного импорта и все. Проблема может быть вовсе не в сотруднике. А в настройке сервиса по принципу «лишь бы работало», без процедур QA.
egorbI4 Автор
По принципу «лишь бы работало», серьезно? Я же не у дяди Пети сервера арендую, а у крупной компании, которая за последний год стала достаточно популярна в России. Как можно подвергать тысячи клиентов такому риску?
pupsegadm
Надеюсь исправятся.
Интересно, а шаблон дают выкачать. Может быть что-то стоит в rc.local…
1cloud
Уязвимость устранена сегодня в 12:08.
Мы подтверждаем факт обнаружения в одном из наших шаблонов (ОС Debian 8.7) пользовательской учётной записи, с недостаточно крипто защищённым паролем. В следствии чего данный пароль был взломан злоумышленником и в дальнейшем использован при подключении к серверам, созданным из уязвимого шаблона. Эта версия шаблона была опубликована 30.07.2018. Все клиенты, которые использовали указанную версию шаблона, к настоящему времени оповещены о выявленной уязвимости, и приняты меры по её устранению.
Уязвимости был подвержен 1 из наших 18 шаблонов.
Количество пострадавших серверов: менее 50 шт.
Сразу после обнаружения источника проблемы этот шаблон был незамедлительно выведен из эксплуатации. Все остальные публичные шаблоны виртуальных машин проверены на наличие подобной уязвимости.
Предварительное оперативное расследование показало, что проблема возникла из-за непреднамеренной ошибки, возникшей в результате несогласованных действий двух наших сотрудников, которые занимались подготовкой и тестированием указанного шаблона.
Предпринятые действия:
1. Уязвимость устранена в шаблоне Debian 8.7
2. Проводится дополнительная проверка все остальных шаблонов на предмет других уязвимостей по безопасности
3. Будет доработана процедура автоматической проверки «золотых» шаблонов на наличие данной ошибки и других уязвимостей по безопасности.
4. Будет проведены работы с сотрудниками поддержки для недопущения повторения подобных сценариев взаимодействия с Клиентами
Приносим свои глубочайшие извинения нашим настоящим и будущим клиентам за возникший инцидент. Мы приложим максимум усилий для исключения возможности возникновения подобных ситуаций в дальнейшем.
Мы планируем предоставить более подробный отчет об устранении данной проблемы и о предпринятых мерах в отдельной статье в нашем блоге.
Выражаем благодарность пользователю egorbI4 за извещение о серьёзной проблеме, конструктивную критику и взаимодействие!
Yo1
а с какой целью вообще добавляли левого пользователя в шаблон?
1cloud
В процессе установки Debian нельзя пропустить шаг создания непривилегированного пользователя.
Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.
davydt
можно, если выбирать экспертную установку
TimsTims
Судя по всему тестили новую сборку, и во время тестов сделали временного пользователя user:123 (условно). Но удалить из финалки его забыли, пустили в прод.
Ушлый хацкер увидел в дефолтной сборке уже существуюего пользователя, выкачал его хэш и забрутфорсил пароль, после чего открылся доступ к любому серверу на этой ОС. Раз в сутки сканировал подсеть на наличие новых серверов, и заражал их.
При расследовании очень быстро нашли "виновных" — спосили "Сашу и Петю", и они вспомнили что действительно при тестах всегда ставят пароль 123. Вот и сказке конец, расследование закончено.
ПС: это мое личное мнение как всё было, в стиле Шерлок.
SergeyMax
Никто никакой хэш не выкачивал, 22-й порт всего интернета непрерывно сканируется червями-майнерами на предмет наличия пользователей типа admin/user/test с паролями типа 123456, 123qwe!@#, и прочей дичью. Автор об этом тоже писал, если вы заметили.
TimsTims
Нет, там всего 6 попыток авторизации. Причем вход под user — с первой попытки. Брутфорсить через ssh гораздо дольше и затратнее (ты не знаешь, есть ли такая учетка вообще, после скольки попыток ты попадешь в бан, итд), чем брутфорсить хэш пароля локально, никто ничего даже не увидит.
Плюс вы невнимательно прочитали тему — такой юзер уже был во всех сборках. А значит хацкер просто арендовал когда то такой же сервер и нашел эту учётку, и подобрал пароль к ней. Потом уже он начал ходить в гости к остальным…
SergeyMax
Вы не поняли. Никто ничего не брутфорсит. Перебирается просто несколько фиксированных паролей к нескольким учёткам. Это никак не зависит от того, есть ли юзер в сборках, арендовал ли хакер сервер, и подобрал ли к ней пароль. Я даже больше скажу, эти же пароли и логины подбираются к виндовым серверам с подключением через RDP. Вы можете легко это проверить, выставьте в интернет порт 22 или 3389, и через пару часов увидите в логе попытки подключения от тех же самых пользователей.
SergeyMax
Специально для вас дёрнул лог:
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
и т.д., и т.п.
celebrate
А зачем вы вообще разрешаете SSH-аутентификацию по паролю? В нормальных облачных провайдерах она выключена по умолчанию.
bormotov
только я не вижу в этом комментарии ничего про шаблон c Windows?
atamanenko
Прошу прощения за оффтоп, но можно было написать хотя бы как-то так:
В вашем ответе сплошной канцелярит, размытые формулировки, стена мусорного текста и неуважение. Не надо так.
P.S. Про извинения
amarao
А вот в рамках извинений, расскажите, а как вы эти образа собираете и тестируете? DIB или что-то другое?
LoadRunner