Назад | Перейти на главную страницу

MySQL-инъекционные атаки? Ошибки, вызывающие случайный URL

Мы только начали запускать наш собственный веб-сервер несколько месяцев назад на Rackspace (они великолепны). Я использую NewRelic (тоже довольно круто) для мониторинга использования сервера, и я получаю предупреждения об ошибках, которые кажутся мне атаками с использованием инъекций? Интересно, может ли кто-нибудь получить представление или совет о том, как помешать этим усилиям и избавиться от ошибок и надоедливых уведомлений.

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

Вот пример "ошибки MySQL":

http://www.ourdomain.com/item.php?fetchitem=46«+ И + 999999,9) + UNION + AlL + SELECT + 0x393133353134353632312e39,0x393133353134353632322e39,0x393133353134353632332e39,0x393133353134353632342e39,0x393133353134353632352e39,0x393133353134353632362e39,0x393133353134353632372e39,0x393133353134353632382e39,0x393133353134353632392e39,0x39313335313435363231302e39,0x39313335313435363231312e39,0x39313335313435363231322e39,0x39313335313435363231332e39,0x39313335313435363231342e39,0x39313335313435363231352e39,0x39313335313435363231362e39,0x39313335313435363231372e39,0x39313335313435363231382e39,0x39313335313435363231392e39 , 0x39313335313435363232302e39,0x39313335313435363232312e39,0x39313335313435363232322e39,0x39313335313435363232332e39,0x39313335313435363232342e39,0x39313335313435363232352e39,0x39313335313435363232362e39,0x39313335313435363232372e39,0x39313335313435363232382e39,0x39313335313435363232392e39 + и + '1' = '1

Этот URL должен быть просто www (точка) ourdomain (точка) com / item.php? Fetchitem = 46

Другой:

http://www.ourdomain.com/item.php?fetchitem=39'+ и (% 2f **% 2fsElEcT + 1 +% 2f **% 2ffRoM (% 2f **% 2fsElEcT + count (*),% ​​2f **% 2fcOnCaT ((% 2f **% 2fsElEcT (% 2f * *% 2fsElEcT (% 2f **% 2fsElEcT +% 2f **% 2fcOnCaT (char (33,126,33), count (t.% 2f **% 2ftAbLe_nAmE), char (33,126,33)) +% 2f **% 2ffRoM + information_schema.% 2f **% 2fsChEmAtA + as + d + join + information_schema.% 2f **% 2ftAbLeS + as + t + on + t.% 2f **% 2ftAbLe_sChEmA + = + d.% 2f **% 2fsChEmA_NaMe + join + information_schema.% 2f **% 2fcOlUmNs + as + c + on + c.% 2f **% 2ftAbLe_sChEmA + = + d.% 2f **% 2fsChEmA_NaMe + и + c.% 2f **% 2ftAbLe_nAmE + = + t. % 2f **% 2ftAbLe_nAmE +% 2f **% 2fwHeRe + not + c.% 2f **% 2ftAbLe_sChEmA + в (0x696e666f726d6174696f6e5f736368656d61,0x6d7973716c) + и + d. ) + и + c.% 2f **% 2fcOlUmN_NaMe + like + 0x25656d61696c6164647265737325)) +% 2f **% 2ffRoM + information_schema.% 2f **% 2ftAbLeS +% 2f **% 2flImIt (+ 0,1), floor ( 0) * 2)) x +% 2f **% 2ffRoM + information_schema.% 2f **% 2ftAbLeS +% 2f **% 2fgRoUp% 2f **% 2fbY + x) a) + и + '1' = '1

Было предложено установить ограничение на порт 80 в iptables, но я боюсь заблокировать потенциальных реальных пользователей.

Все мысли и советы приветствуются! Спасибо!

Да, это классическая атака с использованием SQL-инъекций. Единственная реальная долгосрочная защита - это защита приложения, хотя вы можете запретить IP-адреса по мере необходимости, и существуют различные инструменты, которые попытаются автоматизировать это.

В конечном итоге, если это не станет DOS-атакой, они должны быть относительно безвредными, если ваш сайт защищен от инъекций. Однако эта сторона вещей больше похожа на StackOverflow.

классический sqli - сканирование; жить с этим или блокировать (но не вручную :)

если вы хотите защитить себя от попыток sql-инъекций и вам нужно легкое решение, используйте nginx + naxsi , если вы можете установить и запустить обратный прокси-сервер перед своим apache (mod_security может немного замедлить работу вашего сайта)

причины использовать naxsi

  • является много более легкий, чем mod_security
  • основной набор правил стабилен в sqli-protection
  • написание и поддержка правил - это не такая PITA, как с mod_security
  • может быть расширен, чтобы заблокировать множество сканеров, скидок и нежелательного доступа (расширенный набор правил)
  • режим обучения -> запустите его на защищенном экземпляре и сгенерируйте правила белого списка для вашей живой настройки
  • вы можете иметь полную мощность nginx и использовать функции proxy_cache и static на одном хосте

когда НЕ использовать naxsi:

  • если необходима фильтрация исходящего трафика (здесь я бы предпочел snort)
  • если нужны многоступенчатые входящие фильтры (здесь я бы предпочел snort)

Да это оно.

Я рекомендую обнаруживать и блокировать эти атаки с помощью ModSecurity.

Примеры правил для обнаружения SQL-инъекций из ModSecurity CRS (основной набор правил):

https://raw.github.com/SpiderLabs/owasp-modsecurity-crs/master/base_rules/modsecurity_crs_41_sql_injection_attacks.conf

Вы можете четко видеть правила, содержащие ключевые слова "выбрать", "объединить", "все" и т. Д.