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

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

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

2) Я бы стал.

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

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

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

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

• Сухосин для укрепления самого PHP.

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

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

• Отключите ненужные функции PHP, такие как система и пройти через.

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

• Своевременно обновляйте свой сервер.

• Следите за журналами.

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

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

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

Это нападение, это очень подробно объясняется Вот.

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

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

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

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

• сухосин (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 (не могу вспомнить, что, я думаю, это тоже было перенаправление при определенных условиях).