Фейл был знатный, тут даже спорить не станем.
Тем не менее, ситуацию мы эту отработали, уязвимость закрыли, в процессах учли…
Человеческий фактор присутсвует везде, к сожалению.
Но, опять же, учитывая объемы задач связанных с безопасностью и админитсрированием, которые решает iaas-провайдер, накопленный опыт у него, в том числе по отработанным ошибкам, гораздо выше чем у сотрудников обычного ит-отдела.
На то он и центр обработки ДАННЫХ.
Данные сейчас реально становятся чуть ли не главным активом большинства компаний.
И отношение к ним должно быть соответсвующим.
По крайней мере мы придерживаемся такой позиции.
Это дейсвительно весомый аргумент.
Обеспечить схожий уровень безопасности и стабильности, как это делает ЦОД, большинству компаний не под силу, просто из-за масштаба.
Пост задумывался именно как фотоэкскурсия.
+ на объекте снимать можно только согласованные места. Там размещено оборудвоание очень многих больших компаний. Не все их них хотят, чтобы их оборудование попало в кадр.
О каком-либо импортозамещении в рамках серверного оборудования и всего с ним связанного сейчас не может быть и речи.
Его просто нет по факту. А то что есть — непригодно для коммерческих сервисов.
Клиенты очень разные.
От рядовых пользователей, которым нужно сайт разместить на VDSке, до больших компаний, которые строят на нашей базе распределенную инфраструктруру для своих сервисов, ИТ-отделов и т.д.
Интеграторы, вебстудии, 1C-франчайзи и вольные админы, фрилансеры всех мастей, маркетологи и т.д.
Сервис позволяет решать задачи в очень широком диапазоне, потому разных клиенстких кейсов тоже очень много.
Что можно сказать по ситуации описанной в данной статье?…
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
Что можно сказать по ситуации описанной в данной статье?…
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
В процессе установки Debian нельзя пропустить шаг создания непривилегированного пользователя.
Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.
itprice.com/netapp-price-list/7.6%20tb%20ssd.html
www.youtube.com/watch?v=A_VdNBDKRDg.
www.youtube.com/watch?v=zElQCERp5vE
Тем не менее, ситуацию мы эту отработали, уязвимость закрыли, в процессах учли…
Человеческий фактор присутсвует везде, к сожалению.
Но, опять же, учитывая объемы задач связанных с безопасностью и админитсрированием, которые решает iaas-провайдер, накопленный опыт у него, в том числе по отработанным ошибкам, гораздо выше чем у сотрудников обычного ит-отдела.
Данные сейчас реально становятся чуть ли не главным активом большинства компаний.
И отношение к ним должно быть соответсвующим.
По крайней мере мы придерживаемся такой позиции.
Обеспечить схожий уровень безопасности и стабильности, как это делает ЦОД, большинству компаний не под силу, просто из-за масштаба.
+ на объекте снимать можно только согласованные места. Там размещено оборудвоание очень многих больших компаний. Не все их них хотят, чтобы их оборудование попало в кадр.
Его просто нет по факту. А то что есть — непригодно для коммерческих сервисов.
Голова там не пролезет =)
А даже если форточник с очень маленькой головой протиснится, то что он будет делать дальше?)
От рядовых пользователей, которым нужно сайт разместить на VDSке, до больших компаний, которые строят на нашей базе распределенную инфраструктруру для своих сервисов, ИТ-отделов и т.д.
Интеграторы, вебстудии, 1C-франчайзи и вольные админы, фрилансеры всех мастей, маркетологи и т.д.
Сервис позволяет решать задачи в очень широком диапазоне, потому разных клиенстких кейсов тоже очень много.
Не совсем понятно, с какой проблемой вы столкнулись?
Напишите, пожалуйста, в личку — разберемся.
Посмотрим, что удастся собрать по этой теме.
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
Мы облажались. И облажались по-крупному.
Мы просим прощения у наших действующих и будущих клиентов за этот инцидент. Уязвимость мы закрыли в тот же день, когда нам о ней сообщили, — 24 августа.
Естественно, была выплачена компенсация по SLA с округлением в большую сторону.
Результаты внутреннего расследования инцидента
В одном из наших шаблонов (а именно ОС Debian 8.7) была обнаружена пользовательская учетная запись user с недостаточно криптозащищённым паролем. Этот пароль был подобран злоумышленником и использован для подключения к серверу и загрузки вредоносного ПО. После заражения, зловред начал сканировать «соседей» по сети и по сетям, привязанным к нашей AS.
Как только источник проблемы был обнаружен, мы вывели шаблон из эксплуатации и уведомили клиентов с серверами из этого шаблона о проблеме, дали рекомендации как закрыть уязвимость и предложили свою помощь в решении проблемы.
Параллельно мы проверили другие шаблоны на наличие «лишних» пользователей. Уязвимым оказался только один шаблон из восемнадцати доступных.
Откуда взялся пользователь user?
При установке Debian в обычном режиме нельзя пропустить шаг создания непривилегированного пользователя (если не выбирать «экспертную установку», которую мы не используем), так как по умолчанию вход посредством SSH суперпользователя с паролем запрещён. Сразу после установки root может выполнить вход по паролю только через локальную консоль.
Мы готовили новую версию шаблона с ОС Debian 8 (её задачи: установка периодических обновлений в шаблон и решение проблем с кастомизацией средствами VMware Tools). Сотрудник, ответственный за публикацию шаблона в продакшн, был предупреждён о наличии учетки user. Потому изначально этого пользователя удалили при тестировании. Но, во время тестов мы обнаружили, что процедура расширения дискового пространства выполняется некорректно.
Всему виной были различия файловых систем между версиями шаблонов. Выбирая из двух вариантов — переделать скрипты расширения или переделать шаблон — мы решили подготовить новый шаблон с нуля.
В этот раз пользователь user не был удален по недосмотру сотрудника принимавшего и тестировавшего шаблон. В итоге шаблон был выкачен в продакшен с описанной уязвимостью.
Почему последовала неадекватная реакция первого уровня поддержки?
По результатам общения с задействованными в этой истории сотрудниками ServiceDesk можно выделить две основные причины:
1. Сотрудники поддержки реально не могли поверить, что наши админы могли так облажаться. И их можно понять… Когда я узнал о ситуации, у меня это тоже в голове не укладывалось.
2. Мы каждый день имеем дело с зловредными пользователями, пытающимися использовать нашу инфраструктуру для всевозможных пакостей. Порой они довольно изобретательны в своей аргументации.
Суммируя, сотрудники ServiceDesk были уверены, что тут речь идет об очередном пакостнике, что ни в коей мер не является полноценным оправданием….
Более того, была нарушена должностная инструкция: после получения обузы на брутфорс, наша поддержка написала клиенту, что нужно устранить проблему. Не получив ответа в течении суток, они зачем-то заблокировали все серверы клиента, хотя должны были заблокировать один сервер, с которого шла атака, до устранения причин.
Что мы сделали, чтобы подобная ситуация не повторилась
• Запретили на уровне компании использовать словарные логины и пароли (там, где необходим доступ по паролю) даже в dev и test средах. Во всех остальных случаях будут всегда использоваться SSH-ключи.
• Приняли кадровые решения: сотрудник, ответственный за публикацию шаблонов в продакшн, больше не работает в нашей компании.
• Поговорили с сотрудниками техподдержки и провели разъяснительные беседы о том, как работать с клиентами в подобных случаях. Сотрудник поддержки нарушивший должностную инструкцию был депремирован.
• Добавили новое правило проверки (на наличие «лишних» пользователей) в скрипты валидации шаблонов.
• Добавили дополнительные этап сканирования на предмет различных уязвимостей специальными скриптами на этапах подготовки и тестирования шаблона. Эти же проверки проведены для всех действующих шаблонов.
Еще раз просим прощения за возникший инцидент. Больше подобное не повторится.
Это сделано для возможности удалённого входа в ОС, поскольку, по умолчанию, вход посредством SSH суперпользователя с использованием пароля запрещён.
Непосредственно сразу после установки root может осуществлять вход по паролю только через локальную консоль.