Відмова Tomcat в обслуговуванні

3

Останні два дні наш веб-сервер Tomcat 5.5 Linux був розбитий протягом декількох хвилин, починаючи тисячі завантажень і зупиняючи їх. Деякі шляхи запиту в журналі доступу закінчуються частиною, подібною до "? Jfkdsjkfsdk". Чи відома вразливість систем Tomcat для таких атак?

Оновлення: На даний момент ми працюємо з чистою Tomcat, без Apache.

tomcat denial-of-service vulnerability

— Майк Л.
джерело

Чи можете ви захопити повні заголовки запиту? Це повинно допомогти визначити характер нападу.

— Шейн Мадден

Ми щойно оновили журнал, тому я не можу надати жодної інформації про заголовки запитів, а лише наступне: атака виконувалася лише з однієї IP-адреси та працювала, запитуючи завжди один і той же двійковий файл через регулярні інтервали, іноді кілька запитів за секунду , іноді пауза пару секунд. Tomcat зареєстрував кількість відправлених байтів від 18 до 32K та код статусу HTTP 206.

— Майк Л.

3

Підключення в тисячі разів - це відома "вразливість" будь-якого сервера з налаштуванням maxconnections (або який використовує багато ресурсів за з'єднання). Як DDOS, швидше за все, вони не "зупиняють" завантаження, вони просто переривають з'єднання без стільки, як пакет RST, так що з'єднання зависає, поки воно не вичерпається, або використовують щось на зразок trickleлише визнати кілька байт на час, щоб запобігти тимчасовому з’єднанню.

Все, що ви зробите, щоб пом'якшити це, залежатиме від усієї настройки. Якщо припустити, що ви зараз використовуєте apache + mod_jk + tomcat, то, крім помилки Барта2, я б розглядав mod_security, щоб виявити можливі шкідливі запити та відмовити їх. Інша ідея полягає в тому, якщо ви дійсно використовуєте tomcat для надсилання статичних даних, переміщуючи статичні дані, які подаються безпосередньо з apache (або легкого сервера, як lighttpd або nginix), використовуючи static.example.comдомен. Або, якщо вам потрібно, щоб ваш код вирішив, який файл надсилати, подумайте про використання mod_xsendfile в apache для подання статичних файлів, на які "вказував" ваш додаток, що дозволить tomcat закінчити запит і рухатися далі, поки apache обробляє файл (а не тримати файл і apache, і tomcat надсилати файл).

— ДерфК
джерело

3

На підставі 206 відповідей, на ваш сервер Tomcat нападає атака перекриття, що перекривається, як це описано проти Apache в CVE-2011-3192.

Коли це була гаряча тема минулого місяця, мені здалося, що сервлет за замовчуванням Tomcat виглядає вразливим - дивіться тут .

Найкращим способом зупинити це було б припинити надання цих статичних файлів сервлетом за замовчуванням або зняти Range:заголовок вхідних запитів.

— Шейн Медден
джерело

Ви сказали, про це питання повідомляється проти Apache, але ми використовуємо не Apache, а лише Tomcat. Чи означатиме ваша пропозиція заборонити завантаження за допомогою менеджера завантажень, який зазвичай завантажує декілька сегментів файлу одночасно?

— Майк Л.

2

Ви приєднуєтесь до Tomcat з Apache? Якщо ні, то ви можете бути досить легко вразливими до таких атак, як Slowloris . Дещо погана ідея публічно викривати Tomcat.

Навіть якщо ви звертаєтесь через Apache, вам потрібно бути обережним, щоб захистити від атак Slowloris-esque, використовуючи mod_antiloris, а ще краще використовувати nginxпроксі-сервер, сервер якого виявляється невразливим до атаки Slowloris.

Шейн Медден має кращу відповідь, спочатку прийміть його поради.

— Xorlev
джерело

Як ви думаєте, що простіше налаштувати - Apache чи nginx?

— Майк Л.

nginx, це неймовірно просто.

— Xorlev

Використовуючи nginx як чистий проксі для tomcat (тобто всі запити, навіть наші файли завантаження будуть перенаправлені до tomcat), чи може nginx все-таки захистити нас від нападів, схожих на slowloris, Apache CVE-2011-3192-подібних атак, ...?

— Майк Л.

Ми встановили nginxзараз , але отримати зараз дивне попередження ABE всередині Firefox / NoScript:

Request { GET http://localhost/.... <<< http://our-domain.com/...., http://our-domain.com/foo/bar - 6} filtered by ABE: <LOCAL> Deny

. Що це могло означати?

— Майк Л.

1

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

Ви також можете працювати над впровадженням обмежень ресурсів / квот, щоб обмежити запити на завантаження, проксі / кешування для зменшення навантаження та сповіщення, щоб повідомити вас, коли це відбувається. Поряд з придушенням наших вихідних запитів, тому що навіть якщо ви не були DDoS'ed, ви не хочете, щоб законні запити перевищували вашу доступну пропускну здатність.

Більшість уразливостей полягатиме в тому, щоб "володіти" своїм сервером; врізання / ddos'ing це в цьому відношенні контрпродуктивно. Насправді, єдиний привід вбити сервер - це те, якщо хтось має сокиру, яка молиться проти вашої компанії.

— Барт Сільверстрім
джерело