IIS Request filtering проти ddos-атаки

Лежимо
Замовник, чиї сайти я підтримував раніше, звернувся з тим, що сайт лежить і віддає 500 помилку. У нього стандартний сайт ASP.NET WebForms, не скажу, що дуже навантажений, але бували проблеми з продуктивністю бази даних (MS SQL Server на окремому сервері). Нещодавно сервер БД поміняли і перенесли дані.

Цей сайт не основний бізнес замовника, тому практично не обслуговувався. У нього не налаштоване ніякого моніторингу  і збору метрик і взагалі за ним особливо не стежать.

Дані телеметрії
Які аномалії кинулися в очі:

  1. Процес w3wp використовував понад 50% CPU (зазвичай сильно менше).
  2. Кількість потоків у цьому процес стабільно приростало (сайт не встигав обслужити клієнтів).
  3. Диск на сервері БД використовувався на 100% (Active Time).
  4. Довжина черги звернень до диску з базами проекту була великою (звичайно в районі нуля-одиниць).
  5. Оперативна пам'ять на сервер БД використана повністю.
  6. Профайлер показав, що є один гарячий метод, який ходить в БД.
Тюнінг СУБД
Перша моя гіпотеза була пов'язана з неполадками на стороні сервера БД з-за його перенесення: забули щось налаштувати, не відпрацьовує джоб по збору статистики і перебудування індексу і т. п.

Пам'ять — відразу стало ясно, що при перенесенні СУБД забули обмежити використання оперативної пам'яті  на новому сервері — обмежуємо. По минулому досвіду цієї конфігурації цілком вистачало 24Гб (із загальних 32).

Проверям джобы — все норм. Запускаємо Tuning Advisor та добудовуємо відсутні індекси (серед них був і індекс для гарячого запиту з профайлера). Вихлоп близький до нуля: сайт лежить.

IIS
Заходжу в логи і відразу все стає зрозуміло — DDoS:


Перший раз така ситуація, неясно кому знадобилося. Запитів стало на порядок більше, що в логах?

В логах бачимо близько 200 запитів в секунду (звичайні користувачі генерує до десяти в хвилину по метриці). Всі запити з різних IP, об'єднує їх тільки схожий user-agent:
















GET 101.200.177.82 WordPress/4.2.2; www.renwenqifei.com;+verifying+pingback+from+37.1.211.155 503
GET 54.69.1.242 WordPress/4.2.10; 54.69.1.242;+verifying+pingback+from+37.1.211.155 503
GET 123.57.33.117 WordPress/4.0; www.phenomenon.net.cn;+verifying+pingback+from+37.1.211.155 503
GET 54.69.236.133 WordPress/4.3.1;+http://www.the-call-button.com;+verifying+pingback+from+37.1.211.155 503
GET 52.19.227.86 WordPress/4.3.6; 52.19.227.86;+verifying+pingback+from+37.1.211.155 503
GET 52.27.233.237 WordPress/4.1.13; 52.27.233.237; verifying+pingback+from+37.1.211.155 503
GET 202.244.241.54 WordPress/3.5.1; www.fm.geidai.ac.jp 503
GET 52.34.12.105 WordPress/4.3.6; 52.34.12.105; verifying+pingback+from+37.1.211.155 503
GET 128.199.195.155 WordPress/4.3.6; www.glamasia.com;+verifying+pingback+from+37.1.211.155 503
GET 61.194.65.94 WordPress/4.2.10; wpwewill.help;+verifying+pingback+from+37.1.211.155 503
GET 23.226.237.2 WordPress/4.3.1; hypergridder.com;+verifying+pingback+from+37.1.211.155 503
GET 104.239.228.203 WordPress/4.2.5; pjtpartners.com;+verifying+pingback+from+37.1.211.155 503
GET 104.239.168.88 WordPress/4.2.10; creatorinitiative.com;+verifying+pingback+from+37.1.211.155 503
GET 166.78.66.195 WordPress/3.6; remote.wisys.com/website 503
GET 212.34.236.214 WordPress/3.5.1; nuevavista.am 503
Це відомий тип атаки: WordPress сайт з включеним Pingback (включений за умовчанням), може використовуватися в DDOS-атаки на інші сайти. Більш детальна стаття на Хабре.

Налаштовуємо фільтр запитів
Є кілька рівнів де можна фільтрувати запити. Перший — це файрвол. Грепаем ip — додаємо їх в файрволл, за розкладом збираємо знову з'явилися. Плюси — відмінна швидкість, немає сміттєвих запитів в логах. Мінуси — треба писати скрипти і стежити.

Другий рівень — сам IIS (з явних мінусів — сміттєві запити потрапляють в логи). Третій рівень — написати модуль і використовувати його. Це найбільш гнучкий підхід, але трудомісткий і має невисоку продуктивність.

Я зупинився на другому рівні з міркувань отримати рішення зробивши мінімум дій.
У IIS багато можливостей фільтрації запитів. В даному випадку підходитьRequest Filtering. детальніше про установці і настройці.

Вибираємо сайт → Request Filtering → Rules → Add filtering rules

І вказуємо, що ми хочемо відфільтрувати всі запити де Header: User-Agent є слово WordPress.


Чи можна вказати відповідні параметри у файлі web.config:

<system.webServer>
<security>
<requestFiltering>
<filteringRules>
<filteringRule name="ddos" scanUrl="false" scanQueryString="false">
<scanHeaders>
<clear />
<add requestHeader="User-Agent" />
</scanHeaders>
<denyStrings>
<clear />
<add string="WordPress" />
</denyStrings>
</filteringRule>
</filteringRules>
</requestFiltering>
</security>
</system.webServer>

Відразу після застосування цього фільтра сайт запрацював. Всі показники повернулися до норми. Якби я відразу перевірив логи — на все пішло б менше півгодини.

Що ще вміє IIS?
IIS — дуже крутий і продуктивний сервер для веб-додатків. Крім передачі запиту на керовану середу він багато що вміє робити і по продуктивності сильно переграє managed-рішення.

У розділі Request Filtering ви можете налаштувати ще багато різних фільтрів: за методами, сегментами урла, query-параметрами, розширення і т. д. Можна заборонити asp.net проект специфічні для PHP query-параметри (спроба отримати доступ до htaccess файл з паролями). Можна заборонити такі запити, наприклад, містять sql-ін'єкції. Це робиться не як захист від цих атак, а в цілях економії ресурсу сервера IIS самостійно відкине ці запити і зробить це швидко з мінімальними витратами пам'яті та процесорного часу.

Ще один механізм називається IP Address and Domain Restrictions. Цей механізм дозволяє складати білі і чорні списки IP-адрес для обмеження доступу до сайту. Ви можете заблокувати злісного парсера чи навпаки відкрити доступ на тестовий сайт або адмінку тільки з певних IP. Більш детально читати в офіційній документації.

І третій механізм, який може вам допомогти протидіяти ддос-атак і небажаним парсерам — Dynamic IP Address Restrictions. 

Не завжди ми можемо стежити за постійно мінливими ip-адресами зловмисника. Але за допомогою цього інструменту ми можемо обмежити частоту запитів. Таким чином, IIS на аномально велику кількість запитів з однієї IP-адреси буде швидко віддавати 403 або 404. Будьте акуратніше з пошуковими ботами. Офіційна документація.

Висновки
Не відключайте логи, налаштовуйте моніторинг, який попередить вас про аномалії в показниках. Це можна зробити швидко і недорого, і заощадить вам час при розслідуванні інцидентів. Налаштування моніторингу, а також адміністративні та організаційні заходи протидії залишимо за рамками цієї статті.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.