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

На прошлой неделе мой сайт испытывал отказ в обслуживании / хакерскую атаку. Атака поражает наш веб-API со случайно генерируемыми недействительными ключами API в цикле.

Я не уверен, что они пытаются угадать ключ (математически невозможно, как 64-битные ключи) или пытаться атаковать сервер DOS. Атака распространяется, поэтому я не могу запретить весь IP-адрес, как это происходит от сотен клиентов.

Я предполагаю, что это приложение для Android с помощью IP-адресов, поэтому у кого-то есть вредоносная программа в приложении для Android, и все установки устанавливаются для атаки на мой сервер.

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

Любые предложения о том, как остановить атаку? Есть ли способ идентифицировать приложение Android, делающее запрос из HTTP-заголовка?

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

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

Без использования брандмауэра, 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 за другой отличный вариант, fail2ban
  • Создание вашего собственного Tomcat Valve , как описано здесь , для отклонения входящих запросов их User-Agents (или любым другим критерием) в качестве последней линии защиты.

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

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

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

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

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

Интернет -> CloudFlare / Incapsula -> AWS API Gateway -> Ваш сервер API

0,02

PS: Я думаю, этот вопрос принадлежит Sec

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

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

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

Если атака 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 дистрибьюторов чистых труб.

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

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

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

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

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

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

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

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

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

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