Если у меня включена авторизация, почему опасно открывать MongoDB для всех удаленных IP-адресов?

Question

MongoDB по умолчанию прослушивает только трафик, поступающий с 127.0.0.1 (и с порта 27017). Я единственный, кто может отправлять трафик на этот IP-адрес, так что это предотвращает случайное вмешательство интернет-пользователей в мою базу данных и кражу данных. Здорово. Но затем я включаю авторизацию, создавая администратора:

mongo
use admin
db.createUser(
  {
    user: "ADMINUSERNAME",
    pwd: "ADMINPASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)
exit

и установка security.authorization на «включено» в /etc/mongod.conf.

Теперь, если я установлю net.bindIp в /etc/mongod.conf на 127.0.0.1,<serveripaddress> и открою порт 27017 с помощью ufw allow 27017, какой метод может использовать злоумышленник (кроме взлома пользователя / пароля), чтобы взломать мой базы данных?

Является ли рекомендация иметь белый список IP-адресов просто дополнительным уровнем безопасности, или я что-то здесь упускаю? Преимущества, которые я могу придумать:

1. Если в MongoDB обнаружен эксплойт, у вас все еще есть дополнительный уровень защиты.
2. Если в вашем коде есть ошибки или что-то испортилось (например, вы случайно добавили пользователя со слабым паролем), у вас есть этот дополнительный слой.
3. Защищен от атак методом перебора пользователей / паролем - но при условии, что мой пароль состоит из 50 случайных символов ASCII, это не будет проблемой, верно?
4. Плохие актеры не могут напрямую DDOS / залить сервер mongodb напрямую, но я думаю, что это легко решить другими способами (fail2ban или что-то в этом роде).

Так что точки № 1 и № 2 кажутся единственными реальными проблемами - и я определенно вижу опасности, но я что-то упускаю?

---

Примечание: я не думаю, что этот вопрос подходит для сайта security stackexchange, потому что это довольно простой вопрос для конкретной программы.

Редактировать: я изначально говорил "аутентификация", когда имел в виду "авторизация".

Answer 1

Я долго думал, стоит ли отвечать на вопрос здесь или пометить его как не по теме, но, поскольку «DevOps» в наши дни кажется повсеместным, он может предотвратить серьезный ущерб, когда станет более доступным.

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

Предположение в соответствии с передовой практикой: злоумышленник знает по минимум о вашей системе (сети, программном обеспечении, ОС и т. Д.) Столько же, сколько и вы.

Итак, давайте вспомним (некоторые из) общие риски.

Если вы не отслеживаете неудачные попытки входа в систему и не настраиваете автоматические действия после нескольких неудачных попыток от конкретного клиента (fail2ban - самый простой пример), можно взломать ваши учетные записи и пароли.

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

Используя эксплойты, например, ssh-сервер, злоумышленник может похитить ваш компьютер. Этот риск увеличивается для каждой выставленной услуги. Эта атака, безусловно, самая опасная, поскольку ваши данные будут скомпрометированы и . Злоумышленник может использовать вашу систему для выполнения очень плохих вещей ™. На ваше имя и в некоторых юрисдикциях даже на вашем юридическом счете.

Белые IP-адреса, безусловно, полезны, но решительный злоумышленник может обойти это путем подмены IP-адресов. И вы должны предположить, что злоумышленник знает действительные IP-адреса источника и назначения. Кроме того, когда один из «белых» IP-адресов (частично) захвачен, атака вполне может исходить оттуда.

Теперь есть три основных способа борьбы с этими рисками:

• Снижение рисков, таких как правильное управление исправлениями и правильная настройка брандмауэра.
• Защита от вторжений, например fail2ban
• Обнаружение вторжения

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

Предполагая, что вы не управляете сетью, вам придется прибегнуть к так называемому обнаружению вторжения на основе хоста или HIDS для краткости. HIDS, в свою очередь, относятся к двум категориям: HIDS на основе поведения и HIDS на основе состояния. OSSEC относится к последней категории и (относительно) прост в настройке и обслуживании, предлагая широкий спектр функций.

На другом уровне предоставление службы баз данных общедоступному Интернету почти всегда является верным признаком того, что с дизайном системы что-то не так. Если вы специально не хотите предоставлять услуги базы данных, у меня нет причин думать об этом.

Если вы хотите только предоставить данные: напишите для них REST- / SOAP- / what-API. Если ваши серверы баз данных доступны только через общедоступный Интернет по какой-то странной причине: используйте VPN или stunnel .

Подсказка: в зависимости от приложения, которое вы создаете, или юрисдикции, в которой вы живете, предоставление доступа к службе базы данных общедоступному Интернету может привести к нарушению правил, норм или даже закона

tl; dr: если вам нужно спросить, вы, вероятно, не должны этого делать.