В дискуссии по поводу катастрофы Cloudflare, я видел, как люди говорят, что защита от атак отказа в обслуживании без Cloudflare в принципе невозможно. Хотя это гораздо сложнее, это не невозможно.

Прежде всего, есть главная проблема сайтов, дающих свои ключи HTTPS для Cloudflare. Одной из главных причин того, что Cloudflare нужно видеть в HTTPS так что они могут обнаруживать атаки на уровне приложений, таких как медленный или больших запросов HTTP, инъекции SQL и т.д. Эти виды атак могут быть фиксированной серверной стороне, и, кроме того Cloudflare не могу исправить эти атаки в целом. Опираясь на Cloudflare для защиты от всех таких атак действительно "безопасность через неизвестность"И не будет стоять против серьезного нападающего. Если обрабатывать атаки на уровне приложений по своему усмотрению, то с точки зрения безопасности, есть очень мало причин для Cloudflare, чтобы иметь возможность видеть в HTTPS. Они должны быть в состоянии работать исключительно на уровне TCP / IP.

(Глядя на HTTPS также требуется для кэширования на сервере DDoS-защиты, но и для динамических веб-приложений, кэширование не может быть использовано все, что многое в любом случае. Cloudflare также использует свою способность к человеку-в-середине HTTPS соединения в порядке для отображения капчу, но я думаю, что это невероятно раздражает и не нужно.)

Помимо: Cloudflare предлагает кусок программного обеспечения, которое они утверждают, что позволяет использовать их обслуживание, не давая им ключ HTTPS. Несмотря на то, что позволяет не давать им свой ключ, программа отправляет каждый HTTPS ключ сеанса Cloudflare, что позволяет им делать почти все, что они могли бы сделать, если бы имели ключ. Может быть, это немного лучше, чем ничего, но это в основном ложное чувство безопасности.

Где DDoS-провайдеры действительно полезны против атак на сетевом и транспортном уровнях. Если предположить, что атаки на уровне приложений уже рассмотрены две наиболее мощные стратегии DDoS являются:

- TCP SYN и UDP потоки, которые работают подавляющая способность сервера для отслеживания и технологических соединения на уровне программного обеспечения.
- Транспортные потоки, которые работают, перегружая сетевое оборудование либо ведущие в машине или перед машиной.

Большинство сайтов сегодня будет снесен даже небольшой SYN или UDP Flood. Тем не менее, для атак до умеренного размера, эти атаки могут быть смягчены достаточно эффективно, блокируя UDP где-то выше по течению сервера (непредусмотренные UDP соединение не используется большинство серверов) и имеющая установку SYNPROXY IPtables на сервере. Если все сайты делали это и обрабатываются их на уровень приложения векторов DoS атаки, то распространенные типы подписки Cloudflare будут полностью избыточными, так как Cloudflare не будет защищать от крупных атак без очень дорогой подписки в любом случае.

Для больших атак, вы должны справиться с этим:

- SYN / UDP наводнение: Есть несколько серверов SYNPROXY перед сервером приложений, или иметь несколько обратных прокси-серверов перед сервером приложений, или иметь несколько серверов приложений, которые могут использоваться параллельно. Основной смысл этого, чтобы отфильтровать плохие пакеты, прежде чем они могут засорять сервер приложений, не действительно кэшировать или любой другой.
- Транспортные потоки: Убедитесь, что полный путь между Интернетом и внешней сервер (ы) может обрабатывать полосу пропускания атаки. Часто, некоторые Ethernet коммутатор только за пределами вашего сервера будет узким местом. Опять же, наличие нескольких наиболее удаленных серверов является полезным, поскольку он распадается на трафик атакующего.

Эти большой атаки, где вы действительно хотите DDoS защиты от компании; в то время как вполне возможно установить вышеупомянутую защиту от крупных нападений со стороны себя, это дорого и сложно. И потому, что на самом деле-опасные атаки на сетевом или транспортном уровне, там действительно нет причин для компании защиты от DDoS, чтобы нужно видеть в основной трафик HTTPS (хотя большинство из них хотят сделать это в любом случае ...). Тем не менее, хотя есть много защит от DDoS компании, которые могут защитить вас от крупных DDoS-атак, они очень дорогие; если вы можете получить его менее чем за несколько сотен долларов в месяц, то компания защита от DDoS, возможно, лжет о том, что вы на самом деле получаете.

К югу от $ 200 / месяц Cloudflare подписка, которые используют большинство людей является дешевой волшебной пулей для отъезжающих только самого слабого атакующим, а также продает свою душу Cloudflare.

Если бы я собирался создать нечто вроде Cloudflare, я бы это сделать только две вещи:

1. Во всех сайтов, размещенных на службе, я бы следить за поведением клиента IP-адресов для классификации IP-адресов, как "вероятно, реальный человек", "вероятно, злоумышленник", или "новый / неизвестно", На основе этих классификаций, я бы применять ставки лимиты и блоки в IP-адрес, чтобы помочь сайтам отсеивать оскорбительный трафик. Такое широкое зрения поведения IP-адрес является то, что сервис-провайдер для многих сайтов может сделать лучше, чем в одном месте.
2. В то время как имея кучу интернет-облицовочный серверов и соединений сверхвысокой емкости, я бы блокировать UDP и обрабатывать TCP рукопожатия от имени реального сервера, передавая только через TCP соединений, которые завершают рукопожатия. Это увеличивает время ожидания несколько, но, вероятно, не так уж плохо, и он может активировать только тогда, когда атака DoS, кажется, на самом деле происходит. Он может также принять во внимание адреса классификацию IP предыдущей точки (но со знанием в виде, что IP-адрес может быть поддельным до завершения TCP рукопожатия).

This'd защиты от DDoS-атак без значительно вредит безопасности.

---

Это плохо, что DDoS-атаки являются чем-то, что должно быть обеспокоены. Это особенно плохо для анонимности, так как в настоящее время веб-сайты должен иметь возможность блокировать IP-адреса в целях защиты от DDoS-атак на уровне приложений; IP-адрес является единственным дефицитным ресурсом, что злоумышленники могут быть вынуждены прогорает. Если сайт позволяет устанавливать соединение через Tor, а затем во время DDoS через сеть Tor, все Tor будет нужно быть заблокирован, чтобы блокировать нападавшего. Если сайт позволяет устанавливать соединение через скрытый сервис Tor, а затем во время DDoS через скрытый сервис, сайт придется закрыть скрытый сервис. По дизайну, нет никакого способа отличить хорошие пользователь Tor от плохих пользователей Tor, так что если серьезные злоупотребления приходят через Tor, вы просто должны блокировать Tor полностью.

Это серьезный недостаток в Интернете, которая должна быть исправлена. Одним из решений было бы добавить какую-то плату для пакетов и / или соединений, таких, как доказательство-оф-работы или микроплатежей. В идеале, доказательство правильности работы будет добавлено в IP-пакеты и упал на магистральных маршрутизаторах, если недостаточно, хотя я не знаю, как вы бы координировать правильную трудность POW. Может быть, вы могли бы иметь минимальную POW трудности на проверку магистральных маршрутизаторов, а затем гораздо больше POW трудности в пункте назначения.

Что касается Tor и подобных darknets, я также думаю, что было бы полезно иметь расширение HTTP для дорогих и долгосрочных доказательств-оф-работы. Например, может быть, вы должны были бы работать на ПР в течение нескольких часов, прежде чем вы могли бы разместить на Tor на основе форуме, но тогда вы могли бы повторно использовать этот POW позднее в любое время на этом сайте. Таким образом, не было бы некоторые расходы, связанные с людьми, имеющими свои счета / POW запрещенный для оскорбительного поведения: они должны были бы пересчитывать POW. Это заменит настоящий момент общий механизм запрещающих IP-адресов, что невозможно на Tor скрытых сервисов.

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

Я думаю, что ~ 99% вещей, сделанных в Интернете может, с работой, быть преобразованы в распределенном хранилище данных модели. Streaming содержания, статические веб-сайты и электронная почта довольно легко. Динамические веб-приложения, такие как форумы и сайты Facebook типа можно сделать с помощью статических страниц с причудливыми приложениями JavaScript, которые работают в рамках распределенных данных магазина. (Эта бы быть довольно изменения в том, как люди пишут веб-приложений, хотя; не было бы, конечно, быть не способ быстро / легко перевести некоторые PHP-код непосредственно в модели данных магазина, например.) Единственное, что эта модель не очень хорошо единовременная один к несколько связи, таких как видео / голосовые вызовы; за эти несколько сценариев использования, все еще может быть использована модель точка-точка.