Представьте, что вы создали пустую, приватную корзину (их ещё называют «бакетами» — от «bucket») AWS S3 в выбранном вами регионе. Каким будет счёт за услуги AWS на следующее утро?

Несколько недель назад я начал работу над прототипом системы индексирования документов для моего клиента. Я создал одну корзину S3 в регионе eu-west-1 и загрузил туда несколько файлов для тестирования. Через два дня я проверил мою страницу выставления счетов AWS, заглянув туда, преимущественно, для того, чтобы проверить, что то, чем я занимаюсь, нормально укладывается в лимиты бесплатного тарифного плана. Но, судя по тому, что я там увидел, ни о какой нормальности речи не шло. Мой счёт превышал $1300, а в консоли выставления счетов были видны сто миллионов PUT-запросов к корзине S3, выполненных всего за один день!

Откуда приходят эти запросы?

AWS, по умолчанию, не логирует запросы, выполняемые к корзинам S3. Но их логирование можно включить, используя AWS CloudTrail или S3 Server Access Logging. После включения логов CloudTrail я сразу же обнаружил тысячи запросов на запись, исходящих как от множества аккаунтов AWS, так и из-за пределов этой платформы.

Но почему посторонние заваливают мою корзину S3 неавторизованными запросами?

Может, это было что-то вроде DDoS-атаки на мой аккаунт? Или — это была атака на AWS? Как оказалось — один из популярных опенсорсных инструментов по умолчанию настроен на сохранение бэкапов в S3. И разработчики этого инструмента использовали в виде текстовой заглушки для имени корзины… то же имя, которым я назвал свою корзину. Это значит, что любой установленный экземпляр инструмента, в котором применяется его стандартная конфигурация, пытается сохранить бэкап в мою корзину S3!

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

В результате получается, что полчища неправильно настроенных систем пытаются сохранить свои данные в моей приватной корзине S3. Но почему кто-то должен платить за эту ошибку? А вот почему.

S3 берёт деньги за неавторизованные входящие запросы

Это подтверждает общение с поддержкой AWS. Вот что они написали:

Да, S3 берёт плату и за неавторизованные запросы (4xx) [1]. Это — ожидаемое поведение системы.

Предположим, я сейчас открою терминал и введу команду такого вида:

aws s3 cp ./file.txt s3://your-bucket-name/random_key

Мне достанется сообщение об ошибке AccessDenied, а владелец корзины будет тем самым человеком, который заплатит за этот запрос. И мне, чтобы это сделать, даже не нужна учётная запись AWS.

Меня беспокоил ещё один вопрос: почему запросы, оплата которых составляет большую часть счёта, поступили из региона us-east-1? У меня нет ни единой корзины в этом регионе! Ответ на этот вопрос заключается в том, что S3-запросы без указанного региона, по умолчанию, считаются относящимися к региону us-east-1, и, при необходимости, перенаправляются. А владелец корзины доплачивает и за эти перенаправленные запросы.

Вопрос безопасности

Теперь мы разобрались с тем, почему мою корзину S3 заваливали миллионами запросов, и с тем, почему, в итоге, это привело к огромному счёту. В этот момент у меня появилась ещё одна идея, которую мне захотелось исследовать. Если все эти неправильно настроенные системы попытаются отправить бэкапы своих данных в мою корзину S3 — почему бы мне просто не позволить им это сделать? Я открыл свою корзину для публичного доступа на запись и, менее чем за 30 секунд, собрал более 10 Гб данных. Конечно, я не могу рассказать о том, чьи это были данные. Но меня прямо-таки поразило то, как невинный недосмотр в настройках может привести к опасной утечке данных!

Какие уроки я из всего этого вынес?

Урок 1: кто угодно, знающий имя любой из ваших корзин S3, может задрать ваши счета в AWS до какого угодно уровня.

Единственный способ этому помешать — удалить корзину. Если к корзине обращаются напрямую через API S3 — её нельзя защитить с помощью служб наподобие CloudFront или WAF. Стоимость стандартных PUT-запросов S3 составляет $0,005 за 1,000 запросов, но всего один компьютер легко способен выполнить тысячи подобных запросов в секунду.

Урок 2: добавление случайного суффикса к именам корзин может улучшить безопасность.

Этот подход позволяет снизить риск обращений к корзинам, исходящих от неправильно настроенных систем, а так же — риск целенаправленных атак. Давая имена корзинам S3, стоит, как минимум, избегать использования коротких, распространённых слов.

Урок 3: если требуется выполнять много запросов к S3 — стоит проверить, задан ли явным образом нужный регион AWS.

Это позволит избежать дополнительных расходов на перенаправление запросов API S3.

Итоги

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

2. Я уведомил о произошедшем команду безопасности AWS. Я предложил ей ограничить возможность использования несчастного имени корзины S3 для того, чтобы, во-первых — оградить их пользователей от неожиданных трат, и во-вторых — чтобы защитить компании, на которые подействовала эта проблема, от утечек данных. Но команда безопасности не расположена решать проблемы настроек сторонних продуктов.

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

4. Сотрудники платформы AWS были так добры, что аннулировали мой счёт. Правда, они особо отметили, что сделано это было в порядке исключения.

Спасибо, что нашли время и прочли мой материал. Надеюсь, он поможет вам держаться подальше от неожиданных расходов в AWS.