Періодичний збій о Cloudflare у вівторок ненадовго вивело з ладу багато популярних напрямків Інтернету. Деяким постраждалим клієнтам Cloudflare вдалося тимчасово відмовитися від платформи, щоб відвідувачі могли отримати доступ до їхніх веб-сайтів. Але експерти з безпеки кажуть, що це також могло спровокувати імпровізований тест на проникнення в мережу для організацій, які почали покладатися на Cloudflare для блокування багатьох типів образливого та зловмисного трафіку.
Приблизно о 6:30 EST/11:30 UTC 18 листопада на сторінці статусу Cloudflare було зазначено, що компанія переживає «внутрішнє погіршення якості обслуговування». Після кількох годин, коли служби Cloudflare відновлювали роботу та знову виходили з ладу, багато веб-сайтів, які стоять за Cloudflare, виявили, що не можуть перейти від використання послуг компанії, оскільки портал Cloudflare був недоступний та/або тому, що вони також отримували свої послуги системи доменних імен (DNS) від Cloudflare.
Однак деяким клієнтам вдалося відключити свої домени від Cloudflare під час збою. І багатьом із цих організацій, мабуть, потрібно уважніше переглянути журнали брандмауера веб-додатків (WAF) протягом цього часу, сказав Аарон Тернервикладач кафедри Дослідження IANS.
Тернер сказав, що WAF від Cloudflare добре відфільтровує шкідливий трафік, який відповідає будь-якому з десяти найпопулярніших типів атак на прикладному рівні, включаючи введення облікових даних, міжсайтовий сценарій, впровадження SQL, атаки ботів і зловживання API. Але він сказав, що цей збій може бути гарною можливістю для клієнтів Cloudflare краще зрозуміти, як захист їхніх власних програм і веб-сайтів може давати збій без допомоги Cloudflare.
«Ваші розробники могли бути ледачими в минулому для впровадження SQL, тому що Cloudflare зупинив це на межі», — сказав Тернер. «Можливо, у вас не був найкращий контроль якості безпеки [quality assurance] для певних речей, тому що Cloudflare був керуючим рівнем, щоб компенсувати це».
Тернер сказав, що одна компанія, з якою він працює, помітила величезне збільшення обсягу журналів, і вони все ще намагаються з’ясувати, що було «законним зловмисним», а не просто шумом.
«Схоже, було приблизно восьмигодинне вікно, коли кілька відомих сайтів вирішили обійти Cloudflare заради доступності», — сказав Тернер. «Багато компаній, по суті, покладалися на Cloudflare для десятки кращих OWASP [web application vulnerabilities] і цілий спектр блокування ботів. Скільки зла могло статися в тому вікні? Будь-яка організація, яка прийняла таке рішення, повинна уважно оглянути будь-яку незахищену інфраструктуру, щоб побачити, чи є хтось, що продовжує працювати після того, як вони повернулися до захисту Cloudflare».
Тернер сказав, що деякі групи кіберзлочинців, ймовірно, помітили, коли онлайн-продавець, якого вони зазвичай переслідують, перестав користуватися послугами Cloudflare під час збою.
«Припустімо, ви були зловмисником, який намагався пробитися до цілі, але ви відчували, що Cloudflare заважав у минулому», — сказав він. “Тоді через зміни DNS ви бачите, що мета видалила Cloudflare зі свого веб-стека через збій. Тепер ви збираєтеся запустити цілу низку нових атак, оскільки захисний шар більше не на місці”.
Ніколь Скоттстарший менеджер з маркетингу продуктів у компанії McLean, штат Вірджинія Репліка Cyberназвав вчорашній збій «безкоштовною настільною вправою, незалежно від того, хотіли ви її виконати чи ні».
«Те кількагодинне вікно було живим стрес-тестом того, як ваша організація обходить власну площину управління та тінь ІТ-розквіту під світлом тиску часу», — сказав Скотт у дописі на LinkedIn. “Так, подивіться на трафік, який вас охопив, коли захист був ослаблений. Але також уважно подивіться на поведінку всередині вашої організації”.
Скотт сказав, що організації, які шукають інформацію про безпеку через збій Cloudflare, повинні запитати себе:
1. Що було вимкнено або обійдено (WAF, захист від ботів, геоблокування) і як довго?
2. Які надзвичайні зміни DNS або маршрутизації були внесені та хто їх схвалив?
3. Чи переклали люди роботу на особисті пристрої, домашній Wi-Fi або несанкціонованих постачальників програмного забезпечення як послуги, щоб уникнути збою?
4. Хтось створював нові сервіси, тунелі чи облікові записи постачальників «лише зараз»?
5. Чи є план скасування цих змін, чи це тепер постійні обхідні шляхи?
6. Який навмисний резервний план для наступного інциденту замість децентралізованої імпровізації?
У посмертному висновку, опублікованому у вівторок увечері, Cloudflare стверджує, що збій не був спричинений, прямо чи опосередковано, кібератакою чи будь-якою зловмисною діяльністю.
«Натомість це було викликано зміною дозволів однієї з наших систем бази даних, що призвело до того, що база даних виводить кілька записів у «файл функцій», який використовується нашою системою керування ботами», — генеральний директор Cloudflare. Матвій Принц написав. “Цей файл функцій, у свою чергу, подвоївся в розмірі. Більший, ніж очікувалося, файл функцій було потім поширено на всі машини, які складають нашу мережу”.
За оцінками Cloudflare, приблизно 20 відсотків веб-сайтів користуються його послугами, і велика частина сучасного Інтернету значною мірою покладається на декілька інших хмарних провайдерів, зокрема AWS і Лазурнийнавіть короткий збій на одній із цих платформ може створити єдину точку збою для багатьох організацій.
Мартін Грінфілдгенеральний директор ІТ-консалтингу Який світсказав, що збій у вівторок був ще одним нагадуванням про те, що багато організацій, можливо, кладуть забагато своїх яєць в один кошик.
«Є кілька практичних і запізнілих виправлень», — порадив Грінфілд. “Розділіть свою власність. Поширюйте захист WAF і DDoS на кілька зон. Використовуйте DNS від різних постачальників. Сегментуйте додатки, щоб збій одного постачальника не відбувався каскадом. І постійно контролюйте елементи керування, щоб виявити залежність від одного постачальника”.