Вы испытываете атаку отказа в обслуживании. Если вы видите трафик, поступающий из нескольких сетей (разные IP-адреса в разных подсетях), вы получаете распределенный отказ в обслуживании (DDoS); если все идет из одного места, у вас обычный старый DoS. Может быть полезно проверить, если вы в состоянии; используйте netstat для проверки. Это может быть трудно сделать, хотя.
Отказ в обслуживании обычно подразделяется на несколько категорий: на основе трафика и нагрузки. Последний пункт (с аварийным сервисом) - это DoS, основанный на эксплойтах, и он совершенно другой.
Если вы пытаетесь определить тип атаки, вы можете захватить некоторый трафик (используя wireshark, tcpdump или libpcap). Вы должны, если это возможно, но также знать, что вы, вероятно, захватите довольно много трафика.
Как правило, они поступают из ботнетов (сетей скомпрометированных хостов, находящихся под центральным контролем какого-либо злоумышленника, чьи ставки они будут выполнять). Это хороший способ для злоумышленника (очень дешево) получить пропускную способность множества различных хостов в разных сетях, чтобы атаковать вас, при этом следя за своими следами. Низкая орбита Ион пушка является одним из примеров ботнета (несмотря на то , добровольно вместо вредоносного происхождения); Зевс более типичный.
Трафик на основе
Если вы используете DoS на основе трафика, вы обнаружите, что на ваш сервер поступает так много трафика, что его подключение к Интернету полностью насыщено. Существует высокая скорость потери пакетов при пинге вашего сервера из другого места, и (в зависимости от используемых методов маршрутизации) иногда вы также наблюдаете очень высокую задержку (пинг высокий). Этот тип атаки обычно является DDoS.
Несмотря на то, что это действительно «громкая» атака, и очевидно, что происходит, администратору сервера трудно его смягчить (и, по сути, невозможно пользователю общего хостинга его смягчить). Вам понадобится помощь от вашего интернет-провайдера; Сообщите им, что вы находитесь под DDoS, и они могут помочь.
Тем не менее, большинство интернет-провайдеров и транзитных провайдеров будут заранее понимать, что происходит, и публиковать маршрут «черной дыры» для вашего сервера. Это означает, что они публикуют маршрут к вашему серверу с 0.0.0.0наименьшими затратами, благодаря : они делают трафик на ваш сервер больше не маршрутизируемым в Интернете. Эти маршруты, как правило, / 32, и в конце концов они удалены. Это тебе совсем не поможет; Цель состоит в том, чтобы защитить сеть провайдера от наводнения. В течение этого времени ваш сервер будет эффективно терять доступ в Интернет.
Единственный способ, которым ваш провайдер (или вы, если у вас есть собственный AS) сможет помочь, - это если они используют интеллектуальные формирователи трафика, которые могут обнаруживать и ограничивать вероятный DDoS-трафик. Не у всех есть эта технология. Однако, если трафик поступает из одной или двух сетей или одного хоста, они также могут блокировать трафик перед вами.
Короче говоря, вы мало что можете сделать с этой проблемой. Лучшее долгосрочное решение - разместить ваши сервисы в разных местах в Интернете, которые должны быть DDoSed индивидуально и одновременно, что делает 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 и количество разрешенных дочерних процессов, если применимо.
Само собой разумеется, что чем лучше настроен и лучше подготовлен ваш сервер, тем сложнее будет этот тип атаки. Избегайте скупости с ОЗУ и процессором в частности. Убедитесь, что ваши подключения к таким вещам, как базы данных и дисковое хранилище, быстрые и надежные.
Exploit основе
Если ваш сервис загадочным образом аварийно завершает работу после запуска, особенно если вы можете установить шаблон запросов, которые предшествуют сбою, а запрос нетипичен или не соответствует ожидаемым шаблонам использования, возможно, вы испытываете DoS на основе эксплойта. Это может быть всего лишь один хост (практически с любым типом интернет-соединения) или несколько хостов.
Это похоже на DoS на основе нагрузки во многих отношениях и имеет в основном те же причины и смягчения. Разница лишь в том, что в этом случае ошибка не приводит к расточительству вашего сервера, а к смерти. Злоумышленник обычно использует уязвимость удаленного сбоя, такую как искаженный ввод, который вызывает нулевую разыменование или что-то в вашем сервисе.
Обработайте это аналогично несанкционированной атаке удаленного доступа. Брандмауэр против исходящих хостов и типа трафика, если они могут быть закреплены. Используйте валидацию обратных прокси, если применимо. Соберите улики (попробуйте собрать часть трафика), отправьте заявку об ошибке продавцу и рассмотрите возможность подачи жалобы о нарушении (или юридической жалобы) против источника.
Эти атаки довольно дешевы, если их можно найти, и они могут быть очень мощными, но также относительно простыми для отслеживания и остановки. Однако методы, которые полезны против DDoS на основе трафика, как правило, бесполезны против DoS на основе эксплойтов.