Как остановить атаку hack/DOS на веб-API

Ответ 1

Предотвращение приступов грубой силы:

Существует множество инструментов и стратегий, которые помогут вам в этом, и которые полностью зависят от реализации вашего сервера и требований.

Без использования брандмауэра, IDS или других инструментов сетевого управления вы не сможете остановить DDOS, а также отказаться от обслуживания вашего приложения. Однако вы можете изменить свое приложение, чтобы сделать атаку грубой силы значительно сложнее.

Стандартный способ сделать это - реализовать блокировку или прогрессивную задержку. Блокировка запрещает IP-адресу делать запрос на вход в течение X минут, если они не могут войти в N раз. Прогрессивная задержка добавляет большую и большую задержку для обработки каждого неудачного запроса на вход.

Если вы используете систему аутентификации Tomcat (т.е. у вас есть элемент <login-constraint> в вашей конфигурации webapp), вы должны использовать Tomcat LockoutRealm, который позволяет легко помещать IP-адреса в блокировку, как только они совершают множество неудачных запросов.

Если вы не используете систему аутентификации Tomcat, вам нужно будет опубликовать дополнительную информацию о том, что вы используете, чтобы получить более конкретную информацию.

Наконец, вы можете просто увеличить длину своих ключей API. 64 бита кажутся непреодолимым огромным количеством ключей для поиска, но его недостаточный вес по современным стандартам. Ряд факторов может помочь сделать его гораздо менее безопасным, чем вы ожидаете:

• Ботнет (или другая крупная сеть) может производить десятки тысяч попыток в секунду, если у вас нет защиты.
• В зависимости от того, как вы генерируете свои ключи и собираете энтропию, ваше фактическое пространство ключей может быть намного меньше.
• По мере увеличения количества действительных ключей количество ключей, которые вам нужны чтобы попытаться найти действительную (по крайней мере теоретически) капли резко.

Увеличение длины ключа API до 128 (или 256 или 512) не будет дорогостоящим, и вы значительно увеличите пространство поиска (и, следовательно, сложность) любой атаки с использованием грубой силы.

Смягчение атак DDOS:

Однако для смягчения DDOS-атак вам нужно немного поработать. Атаки DDOS жесткие для защиты от них и особенно сильно, если вы не контролируете сеть, на которой работает ваш сервер.

Как говорится, есть несколько действий на стороне сервера, которые вы можете сделать:

• Установка и настройка брандмауэра веб-приложений, например mod_security, для отклонения входящих соединений, которые нарушают правила, которые вы определяете.
• Настройка системы IDS, например Snort, чтобы обнаружить, когда происходит DDOS-атака, и сделать первые шаги для ее устранения
• См. @Martin Muller post для другого отличного варианта, fail2ban
• Создайте свой собственный Tomcat Valve, как описано здесь, чтобы отклонять входящие запросы их User-Agents (или любым другим критерием) как последняя линия обороны.

В конце концов, однако, вы можете сделать так, чтобы остановить DDOS-атаку бесплатно. Сервер имеет только столько памяти, столько циклов процессора и так много пропускной способности сети; с достаточным количеством входящих соединений, даже самый эффективный брандмауэр не заставит вас отказаться. Вы сможете лучше атаковать DDOS-атаки, если вы инвестируете в интернет-соединение с более высокой пропускной способностью и больше серверов, или если вы развертываете свое приложение на Amazon Web Services, или если вы купили один из многих продуктов для снижения спроса на потребительские товары и предприятия DDOS (@SDude имеет несколько отличных рекомендаций в своем сообщении). Ни один из этих вариантов не является дешевым, быстрым или легким, но они доступны.

Нижняя линия:

Если вы полагаетесь на свой код приложения для смягчения DDOS, вы уже потеряли

Ответ 2

Если он достаточно большой, вы просто не можете остановить его в одиночку. Вы можете сделать все, что хотите, на уровне приложения, но вы все равно пойдете вниз. В дополнение к безопасности на уровне приложений для предотвращения (как и в ответе FSQ) вы должны использовать проверенные решения, оставляя тяжелый подъем профессионалам (если вы серьезно относитесь к своему бизнесу). Мой совет:

• Регистрация CloudFlare или Incapsula. Это день ото дня для них.
• Рассмотрите возможность использования AWS API-шлюза в качестве второго этапа для ваших запросов API. Вы будете наслаждаться фильтрацией, дросселированием, безопасностью, автомасштабированием и HA для вашего API в масштабе Amazon. Затем вы можете перенаправить действительные запросы на свои компьютеры (в или за пределами Amazon).

Интернет → CloudFlare/Incapsula → AWS API Gateway → Сервер API

0,02

PS: Я думаю, что этот вопрос относится к Sec

Ответ 3

Лучший способ - не допустить доступа к вашим услугам полностью для тех IP-адресов, которые потерпели неудачу, скажем, 3 раза. Это займет большую часть загрузки с вашего сервера, поскольку атакующий блокируется, прежде чем Tomcat даже начнет поток для этого пользователя.

Один из лучших инструментов для достижения этого - fail2ban (http://www.fail2ban.org). Он предоставляется как пакет во всех основных дистрибутивах Linux.

Что вам нужно сделать, это в основном регистрировать неудавшиеся попытки в файле и создавать настраиваемый фильтр для fail2ban. Darryn van Tonder имеет хороший пример того, как написать свой собственный фильтр в своем блоге: https://darrynvt.wordpress.com/tag/custom-fail2ban-filters/

Ответ 4

Если атака D-DOS серьезная, проверки уровня приложения вообще не работают. Вся пропускная способность будет потребляться клиентами D-DOS, и ваши проверки уровня приложения не будут инициированы. Практически ваш веб-сервис не запускается вообще.

Если вам нужно защищать ваше приложение от серьезных атак D-DOS, у вас нет другого выбора, кроме как полагаться на сторонние инструменты, платя деньги. Один из поставщиков чистых труб (который отправляет только хорошие трафик), которые я могу извлечь из своего прошлого опыта: Neustar

Если атака D-DOS на вашем сайте мягкая, вы можете реализовать проверки уровня приложения. Например, ниже конфигурация ограничивает максимальное количество подключений от одного IP, как указано в Ограничить вызовы с одного IP

<Directory /home/*/public_html> -- You can change this location
    MaxConnPerIP 1  
    OnlyIPLimit audio/mpeg video
</Directory>

Подробнее об атаке D-DOS см. ссылка на Wiki. Он содержит список превентивных и гибких инструментов, которые включают в себя: Брандмауэры, коммутаторы, маршрутизаторы, предотвращение IP-адресов, защита на основе D-DOS

и, наконец,

Очистить трубы (весь трафик передается через "центр очистки" или "очищающий центр" с помощью различных методов, таких как прокси, туннели или даже прямые схемы, которые отделяют "плохой" трафик (DDoS а также другие распространенные интернет-атаки) и отправляет только хороший трафик за пределы сервера)

Вы можете найти 12 дистрибьюторов чистых труб.

Ответ 5

Вот пара идей. Кроме того, существует ряд стратегий, но это должно помочь вам начать. Также поймите, что amazon получает ddos'd на частой основе, и их системы имеют тенденцию иметь несколько эвристик, которые затвердевают (и, следовательно, вы) от этих атак, особенно если вы используете балансировку нагрузки Elastic, которую вы должны использовать в любом случае.

• Используйте CDN - у них часто есть способы обнаружения и защиты от ddos. Akamai, мастерство или амазонки владеют облачным фронтом.
• Используйте iptables для включения в черный список оскорбительных ips. Чем больше инструментов у вас есть, тем быстрее вы можете блокировать/разблокировать

• Используйте механизмы дросселирования для предотвращения большого количества запросов

• Автоматически отклонять запросы, которые являются очень большими (скажем, больше 1-2 МБ, если у вас нет услуги по загрузке фотографий или тому подобное), прежде чем они попадут в ваше приложение

• Предотвратите каскадные сбои, установив ограничение на общее количество подключений к другим компонентам вашей системы; например, не позволяйте серверу базы данных перегружаться, открыв к нему тысячу подключений.

Ответ 6

Для целевой и высокораспределенной атаки DOS единственное практическое решение (помимо обеспечения возможности его впитывания) заключается в том, чтобы профилировать атаку, идентифицировать "подсказки" и маршрутизировать этот трафик на низкоуровневый обработчик.

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

В ваших комментариях вы сказали нам хотя бы один другой рассказ - пользовательский агент имеет значение null.

Без добавления каких-либо дополнительных компонентов вы можете начать с tarpitting соединения - если появится запрос, соответствующий профилю, выполните проверку и подтвердите ключ, но тогда ваш код будет спящим на секунду или два. Это уменьшит количество запросов от этих клиентов за небольшую плату.

Другим решением будет использование ошибок журнала, соответствующих запросу, и использование fail2ban, чтобы перенастроить ваш брандмауэр в реальном времени, чтобы удалить все пакеты из адрес источника на некоторое время.

Нет, маловероятно, что вы сможете определить приложение, не захватив поврежденное устройство.