Это Канонический вопрос о предотвращении DoS- и DDoS-атак.
Я обнаружил значительный всплеск трафика на веб-сайте, который я размещаю сегодня; Я получаю тысячи подключений в секунду и вижу, что использую все 100 Мбит / с доступной пропускной способности. Никто не может получить доступ к моему сайту, потому что время ожидания всех запросов истекло, и я даже не могу войти на сервер, потому что время ожидания SSH тоже истекло! Это случалось пару раз раньше, и каждый раз длилось пару часов и проходило само по себе.
Иногда у моего веб-сайта есть другая отдельная, но связанная с этим проблема: средняя загрузка моего сервера (которая обычно составляет около 0,25) достигает 20 или более, и никто не может получить доступ к моему сайту точно так же, как и в другом случае. Он также проходит через несколько часов.
Перезапуск моего сервера не помогает; что я могу сделать, чтобы мой сайт снова стал доступным, и что происходит?
Соответственно, однажды я обнаружил, что в течение дня или двух каждый раз, когда я запускал свой сервис, он получал соединение с определенного IP-адреса, а затем падал. Как только я запустил его снова, это случилось снова и снова вылетело. Чем это похоже и что я могу с этим поделать?
Вы испытываете атаку отказа в обслуживании. Если вы видите трафик, поступающий из нескольких сетей (разные IP-адреса в разных подсетях), у вас есть распределенный отказ в обслуживании (DDoS); если все это исходит из одного и того же места, у вас старый добрый DoS. Может быть полезно проверить, можете ли вы; используйте netstat для проверки. Однако это может быть сложно.
Отказ в обслуживании обычно делится на несколько категорий: на основе трафика и нагрузки. Последний пункт (со сбойным сервисом) - это DoS на основе эксплойтов, и он совсем другой.
Если вы пытаетесь определить, какой тип атаки происходит, вы можете захотеть захватить некоторый трафик (с помощью wirehark, tcpdump или libpcap). Вы должны, если возможно, но также знать, что вы, вероятно, захватите довольно много трафика.
Чаще всего они будут исходить от ботнетов (сетей скомпрометированных хостов, находящихся под центральным контролем какого-либо злоумышленника, чьи приказы они будут выполнять). Это хороший способ (очень дешево) для злоумышленника получить пропускную способность восходящего потока множества разных хостов в разных сетях, чтобы атаковать вас, прикрывая свои следы. В Низкоорбитальная ионная пушка является одним из примеров ботнета (несмотря на то, что он является добровольным, а не вредоносным); Зевс более типичный.
Если вы находитесь под DoS на основе трафика, вы обнаружите, что просто так много трафика приходит на ваш сервер, что его подключение к Интернету полностью загружено. При пинге вашего сервера из другого места наблюдается высокая скорость потери пакетов, и (в зависимости от используемых методов маршрутизации) иногда вы также наблюдаете очень высокую задержку (высокий пинг). Этот вид атаки обычно является DDoS-атакой.
Хотя это действительно «громкая» атака, и то, что происходит, очевидно, администратору сервера сложно смягчить ее (и практически невозможно смягчить ее для пользователя виртуального хостинга). Вам понадобится помощь вашего интернет-провайдера; дайте им знать, что вы подверглись DDoS-атаке, и они могут помочь.
Однако большинство интернет-провайдеров и транзитных провайдеров заранее осознают, что происходит, и опубликуют маршрут черной дыры для вашего сервера. Это означает, что они публикуют маршрут к вашему серверу с минимальными затратами через 0.0.0.0: они делают трафик на ваш сервер больше не маршрутизируемым в Интернете. Обычно это маршруты / 32, и в конечном итоге они удаляются. Это вам совсем не помогает; цель - защитить сеть провайдера от наводнения. На время ваш сервер фактически потеряет доступ в Интернет.
Единственный способ, которым ваш интернет-провайдер (или вы, если у вас есть собственная AS) сможет помочь, - это использовать интеллектуальные формирователи трафика, которые могут обнаруживать и ограничивать скорость вероятного DDoS-трафика. Не у всех есть эта технология. Однако, если трафик идет из одной или двух сетей или одного хоста, они также могут заблокировать трафик впереди вас.
Коротко, ты очень мало можешь сделать об этой проблеме. Лучшее долгосрочное решение - разместить ваши сервисы во многих разных местах в Интернете, которые должны подвергаться DDoS-атакам индивидуально и одновременно, что значительно удорожает DDoS-атаки. Стратегии для этого зависят от службы, которую необходимо защитить; DNS можно защитить с помощью нескольких авторитетных серверов имен, SMTP с резервными записями MX и почтовыми обменниками, а также HTTP с циклическим DNS или множественной адресацией (но в любом случае некоторое ухудшение может быть заметным в течение этого времени).
Балансировщики нагрузки редко бывают эффективным решением этой проблемы, потому что сам балансировщик нагрузки подвержен той же проблеме и просто создает узкое место. IPTables или другие правила брандмауэра не помогут потому что проблема в том, что ваша труба пропитана водой. Как только соединения обнаруживаются вашим брандмауэром, уже слишком поздно; пропускная способность вашего сайта израсходована. Неважно, что вы делаете со связями; атака смягчается или завершается, когда объем входящего трафика возвращается к норме.
Если вы можете это сделать, подумайте об использовании сеть распространения контента (CDN), например Akamai, Limelight и CDN77, или используйте службу очистки от DDoS-атак, например CloudFlare или Prolexic. Эти службы принимают активные меры для смягчения этих типов атак, а также имеют настолько большую доступную полосу пропускания во многих разных местах, что их лавинная рассылка обычно невозможна.
Если вы решите использовать CloudFlare (или любой другой CDN / прокси), не забудьте скрыть IP своего сервера. Если злоумышленник узнает IP-адрес, он может снова выполнить DDoS-атаку на ваш сервер напрямую, минуя CloudFlare. Чтобы скрыть IP, ваш сервер никогда не должен напрямую связываться с другими серверами / пользователями, если они не в безопасности. Например, ваш сервер не должен отправлять электронные письма пользователям напрямую. Это неприменимо, если вы размещаете весь свой контент в CDN и не имеете собственного сервера.
Кроме того, некоторые VPS и хостинг-провайдеры лучше противодействуют этим атакам, чем другие. Как правило, чем они больше, тем лучше они справляются с этим; провайдер, у которого очень много пианистов и большая пропускная способность, естественно, будет более устойчивым, а тот, у кого есть активная и полностью укомплектованная команда сетевых операций, сможет быстрее реагировать.
Когда вы сталкиваетесь с DDoS-атакой на основе нагрузки, вы замечаете, что средняя нагрузка ненормально высокая (или использование ЦП, ОЗУ или диска, в зависимости от вашей платформы и особенностей). Хотя сервер, похоже, не делает ничего полезного, он очень занят. Часто в журналах будет большое количество записей, указывающих на необычные условия. Чаще всего это происходит из самых разных источников и является DDoS-атакой, но это не всегда так. Даже не обязательно много разных хостов.
Эта атака основана на том, чтобы заставить ваш сервис делать много дорогостоящих вещей. Это может быть что-то вроде открытия гигантского количества TCP-соединений и принуждения вас поддерживать их состояние, или загрузка чрезмерно больших или многочисленных файлов в вашу службу, или, возможно, выполнение действительно дорогостоящего поиска или действительно выполнение чего-либо, что дорого в обработке. Трафик находится в пределах того, что вы запланировали и можете взять на себя, но типы запросов слишком дороги, чтобы обрабатывать так много.
Во-первых, то, что этот тип атаки возможен, часто указывает на проблема или ошибка конфигурации к вашим услугам. Например, у вас может быть включено слишком подробное ведение журнала, и вы можете хранить журналы на том, что очень медленно для записи. Если кто-то осознает это и сделает много чего, что заставит вас записывать большое количество журналов на диск, ваш сервер будет медленно сканировать. Ваше программное обеспечение может также делать что-то крайне неэффективное для определенных случаев ввода; причин столько же, сколько и программ, но двумя примерами могут быть ситуация, когда ваша служба не закрывает сеанс, который в противном случае завершен, и ситуация, которая заставляет ее порождать дочерний процесс и выходить из него. Если у вас останутся десятки тысяч открытых соединений с отслеживаемым состоянием или десятки тысяч дочерних процессов, у вас возникнут проблемы.
Первое, что вы сможете сделать, это использовать брандмауэр, чтобы сбросить трафик. Это не всегда возможно, но если есть характеристика, которую вы можете найти во входящем трафике (tcpdump может быть хорошим для этого, если трафик небольшой), вы можете сбросить его на брандмауэре, и это больше не будет вызывать проблем. Другой вариант - исправить ошибку в вашем сервисе (свяжитесь с поставщиком и будьте готовы к длительной поддержке).
Тем не мение, если это проблема конфигурации, начните с этого. Отключите ведение журнала в производственных системах до разумного уровня (в зависимости от программы это обычно значение по умолчанию и обычно включает отключение уровней "отладки" и "подробного" ведения журнала; если все, что делает пользователь, входит в систему точно и мелкая деталь, ваш лог слишком многословен). Дополнительно, проверить дочерний процесс и лимиты запросоввозможно дроссель входящие запросы, соединения на IP и количество разрешенных дочерних процессов, если применимо.
Само собой разумеется, что чем лучше сконфигурирован и лучше подготовлен ваш сервер, тем сложнее будет этот тип атаки. Не скупитесь на RAM и CPU в частности. Обеспечьте быстрое и надежное подключение к таким вещам, как серверные базы данных и дисковое хранилище.
Если ваш сервис загадочно вылетает очень быстро после запуска, особенно если вы можете установить шаблон запросов, предшествующих сбою, и запрос является нетипичным или не соответствует ожидаемым шаблонам использования, вы можете столкнуться с DoS на основе эксплойтов. Это может быть всего лишь с одного хоста (с практически любым типом подключения к Интернету) или с множества хостов.
Это похож на DoS на основе нагрузки во многих отношениях и имеет в основном те же причины и способы устранения. Разница лишь в том, что в этом случае ошибка не приводит к тому, что ваш сервер становится бесполезным, а просто умирает. Злоумышленник обычно использует уязвимость удаленного сбоя, например искаженный ввод, который вызывает разыменование нуля или что-то в вашей службе.
Обработайте это аналогично атаке с несанкционированным удаленным доступом. Брандмауэр против исходных хостов и типа трафика, если они могут быть зафиксированы. Используйте проверяющие обратные прокси если это применимо. Соберите судебные доказательства (попробуйте захватить часть трафика), отправьте сообщение об ошибке поставщику и рассмотрите возможность подачи жалобы о злоупотреблении (или юридической жалобы) на источник.
Эти атаки довольно дешевы в установке, если можно найти эксплойт, и они могут быть очень мощными, но также относительно легко отследить и остановить. Однако методы, которые полезны против DDoS на основе трафика, обычно бесполезны против DoS на основе эксплойтов.
Если вы являетесь предприятием, у вас есть много вариантов. Если вы такой же маленький парень, как я, и арендуете VPS или выделенный сервер для обслуживания небольшого веб-сайта, стоимость может быстро стать непомерно высокой.
По моему опыту, я считаю, что большинство выделенных провайдеров и провайдеров VPS не будут устанавливать специальные правила брандмауэра только для вашего сервера. Но в настоящее время у вас есть несколько вариантов.
Если вы используете веб-сервер, подумайте о том, чтобы разместить его за CDN, например CloudFlare или Amazon CloudFront.
CDN дороги. Чтобы держать расходы под контролем, обслуживайте большие файлы (большие изображения, аудио, видео) прямо с вашего сервера, а не через CDN. Однако при этом злоумышленники могут открыть IP-адрес вашего сервера.
Частные облака обычно являются дорогостоящими корпоративными решениями, но установка Amazon VPC практически ничего не стоит. Однако в целом пропускная способность Amazon стоит дорого. Если вы можете себе это позволить, вы можете настроить группу безопасности Amazon VPC и сетевой ACL, чтобы блокировать трафик до того, как он поступит на ваш экземпляр. Вам следует заблокировать все порты, кроме порта TCP-сервера.
Обратите внимание, что злоумышленник может атаковать порт вашего TCP-сервера. Если это веб-сервер, подумайте об использовании чего-то вроде nginx, который использует неблокирующий ввод-вывод и может обрабатывать большое количество подключений. Кроме того, вы мало что можете сделать, кроме как запустить последнюю версию серверного программного обеспечения.
Это решение, которое я разработал, применимо к не веб-серверам, которые не могут спрятаться за CDN, таким как WebSocket, серверы мультимедийного контента / потоковой передачи. CloudFlare поддерживает WebSocket, но в настоящее время только для предприятий.
Цель состоит в том, чтобы изменить порт прослушивания TCP достаточно быстро, чтобы бот-сеть не успевала за ним, скажем, каждые 10 секунд. Это достигается с помощью простой прокси-программы, которая выполняет роуминг портов. Последовательность портов псевдослучайна, но должна основываться на времени сервера. Алгоритм расчета серверного времени и порта должен быть скрыт в вашем клиентском javascript / flash-коде. Программа также должна модифицировать брандмауэр, поскольку он меняет порт прослушивания, и брандмауэр должен поддерживать отслеживание состояния. Если кому-то интересно, я загружу свой скрипт node.js, который работает с Amazon, на GitHub.
Измените свой домен, чтобы ненадолго погрузиться в черную дыру вроде 0.0.0.0.
Поговорите со своим сервером и посмотрите, могут ли они выдать вам другой IP-адрес в качестве временного способа доступа к серверу или узнать, есть ли у сервера доступ к удаленной консоли (например, вы сидите перед ним). Отсюда вы можете увидеть, является ли это одиночным IP-адресом, и заблокировать его от сайта или от распределенной атаки.
Когда вы подвергаетесь DDoS-атаке, ваш интернет-провайдер может помочь вам больше всего, но если у них нет защиты от DDoS-атак, очень вероятно, что вы не будете обслуживать, пока атака не прекратится. Обычно они видят атакованный IP-адрес и обнуляют сеть на своем восходящем маршрутизаторе. Если у вас не так много трафика, существует множество онлайн-сервисов для защиты от DDoS-атак, где ваш трафик перенаправляется, фильтруется и отправляется обратно на ваш сервер.
У нас была такая же похожая ситуация и раньше. Вот что мы сделали.
Сначала отключите сетевой кабель от вашего сервера. Теперь убедитесь, что службы вашего сервера вернулись в нормальное состояние, посмотрев на монитор производительности и диспетчер задач. Если нет, просканируйте ваш сервер с помощью программы Malwarebytes, чтобы убедиться, что ваш сервер очищен. Этот шаг обычно возвращает ваш отключенный сервер в нормальное состояние.
Далее, у вас установлен брандмауэр? Если да, продлили ли вы подписку? Убедитесь, что вы включили функцию вторжения IPS в брандмауэре. Просто продлив подписку на брандмауэр, мы решили нашу DDOS-атаку.
Мы узнали, что нам следует продлить подписку безопасности (например, прошивку или антивирус) и не относиться к этому легкомысленно. DDOS-атаки происходят каждый день и могут случиться и с малым бизнесом. Надеюсь это поможет.