Мой сайт использует Discourse. Изначально он не был защищён Cloudflare и подвергся DDoS-атаке.
Позже я изменил IP-адрес и настроил Cloudflare. Однако сайт снова подвергся DDoS-атаке, вероятно, из-за утечки IP-адреса исходного сервера.
При использовании CDN Cloudflare, как предотвратить утечку IP-адреса исходного сервера? Есть ли у кого-нибудь хорошие методы? Спасибо.
Я не знаю, но IP-адреса всех онлайн-серверов будут раскрыты одновременно с их созданием.
Вы можете предотвратить множество утечек, выполнив следующие действия:
HTTPS_PROXY и HTTP_PROXY, чтобы Discourse использовал их (укажите их в секции env вашего файла app.yml);NO_PROXY='127.0.0.1, localhost, <internal-network>'.Также см. Install discourse with internet access only via proxy, Configuration outbound proxy и Discourse Link previews through a proxy server? - #14 by supermathie
Кроме того, если вы используете Cloudflare, вы можете настроить брандмауэр на хосте с Discourse, разрешив входящий трафик только с IP-адресов Cloudflare (а также с хоста, с которого вы сами получаете доступ к нему).
Это и есть решение. Безопасность через неясность не является надёжной. Тогда не будет иметь значения, если ваш IP-адрес станет общеизвестным.
Это или, альтернативно, более простой подход — использовать то, что называется туннелем Cloudflare. Это должно быть одноразовая настройка, после чего вы сможете в основном закрыть свой брандмауэр для входящих подключений.
По-моему, я делал так уже довольно давно (без настройки прокси, о которой вы упомянули). Не уверен, что это применимо ко всем брандмауэрам (или, возможно, дело в моей конфигурации),
но в моём случае с ufw стоит отметить, что Docker по умолчанию обходит ufw, поэтому необходимо убедиться, что правила применяются также к внутренним IP-адресам контейнеров Docker.
Прошло уже довольно много времени, но я могу разобраться подробнее, если вам это ещё нужно, на этой неделе.
И да, туннели Cloudflare — это потрясающе! @itsbhanusharma
Вам следует использовать брандмауэр, предоставляемый вашим провайдером VPS. Использование хост-ориентированного брандмауэра будет гораздо менее эффективным в борьбе с DDoS-атаками, так как трафик всё равно достигает вашего сетевого стека.
Думаю, у большинства крупных провайдеров защита от DDoS включена по умолчанию? Разве этого недостаточно? Ручное добавление IP-адресов CloudFlare через интерфейс кажется излишним хлопотом (например, мой пользовательский bash-скрипт за 2 секунды автоматически подтягивает IP-адреса CF).
Надо сказать, обычно я вижу обратное: ufw/локальный фаервол вместо фаервола провайдера 
Редактирование: я понимаю логику, с точки зрения защиты от DDoS это, вероятно, эффективнее, и вы правы. Тем не менее, если основной IP-адрес изначально правильно скрыт, DDoS-атаки не должны быть проблемой, верно?
У большинства провайдеров сейчас есть для этого API?
Верно! Но это довольно большое «если»…
На самом деле это неверно. Просто потому, что IP-адрес никогда не скрывается. DDoS-атака не является проблемой, если обратный прокси-сервер или аналогичное решение имеет инструменты для её блокировки. И даже в случае реальной атаки простого решения начального уровня будет недостаточно. Если же боты или подконтрольные пользователи сканируют закрытые порты или порты с ограничением по IP, это не такая уж большая проблема. Я бы назвал это очередной «четвергом» в мире WordPress, но Discourse во многих отношениях — это совсем другая история.
С другой стороны, я не эксперт в этой области.
Но мне любопытно… какой объём трафика необходим для успешной DDoS-атаки? Конечно, это зависит от ресурсов конфигурации, но, пожалуйста, приведите какие-нибудь цифры.
Всё зависит от вашего определения слова скрыт. Да, все IP-адреса являются публичными. Но тогда какой из 4 миллиардов IP-адресов является правильным? Я считаю, что в рамках этого обсуждения IP-адрес можно считать скрытым, если нет способа определить IP-адрес(а) сервера, на котором размещён конкретный форум Discourse (то есть функция f(h) не определена, где функция f возвращает истинный IP-адрес для хоста).
При условии:
Однако я согласен с вами, что термин «скрыт» вводит в заблуждение и является некорректным. Вероятно, лучше использовать слово «неизвестен».
Это зависит от типа DDoS-атаки. Для атаки на уровне приложений это может быть верно, но также сложно реализовать, так как потребуется某种形式的 rate limiting с инспекцией запросов. Однако для атаки на сетевом уровне (просто затопление трафика через усиление или SYN-атаку) это может не сработать. Кроме того, по сути вы говорите: «это не проблема, если вы можете её смягчить», что довольно очевидно, но при этом сложно и/или дорого.
Это также зависит от типа атаки. Атака на уровне приложений должна быть адаптирована под Discourse, но, например, может запускать тяжёлые запросы, такие как поиск, чтобы перегрузить серверы приложений, тогда как атака на сетевом уровне может быть более универсальной, требовать большего объёма трафика и просто забивать nginx или сеть VPS.