Перші години після критичного CVE: робочий чекліст

Опубліковано вразливість найвищої критичності в базовому компоненті. З цієї миті годинник іде для всіх, включно зі зловмисниками. Різниця між спокійним днем і поганим тижнем рідко полягає в самому патчі. Вона в тому, що ви робите в години до і після нього. Ось послідовність, якої дотримуємося ми, записана так, щоб ви могли пристосувати її до власного парку.

Година нуль: прочитайте бюлетень двічі

Прочитайте бюлетень один раз, щоб зрозуміти ваду, і один раз, щоб зрозуміти умови. Більшість серйозних бюлетенів мають уточнення: лише коли завантажено певний модуль, лише в певному режимі сервера, лише коли функція досяжна з мережі. Ці уточнення вирішують, які з ваших хостів термінові, які лише зачеплені і яке пом’якшення підходить.

Запишіть три речі, перш ніж щось торкати: назви зачеплених пакетів, виправлений upstream-реліз і умови експлуатації вразливості. Усе, що йде далі, звіряється з цим записом.

Знайдіть кожен хост, на якому це працює

Питайте базу даних пакетів на кожному хості замість покладатися на те, що, як ви вважаєте, встановлено:

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

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

Пом’якшуйте до того, як виправлення існує

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

• Ведіть список кожного пом’якшення, яке ви поставили, щоб зняти ті, що коштують продуктивності, щойно прийде справжнє виправлення. Пом’якшення, які не коштують нічого, можуть залишитися.

Зберіть виправлення самі, якщо мусите

Іноді upstream-проєкт випустив виправлений вихідний код, а дистрибутив ще не запакував його. Чекати є варіантом, але не єдиним. Коли ми вирішуємо не чекати, ми збираємо пакет самі: за власною специфікацією мейнтейнера дистрибутива, у чистому одноразовому контейнері, з вихідного коду, контрольна сума якого звірена зі сторінкою офіційного завантаження проєкту, з тегом релізу, обраним так, щоб власна збірка виробника автоматично замінила нашу, коли вона прийде. Пакети йдуть у наше власне дзеркало з їхніми контрольними сумами в обліку. Повний метод, з командами, викладено у статті Ваше власне дзеркало RPM і збірка виправлення до того, як його випустить дистрибутив.

Рішення збирати є судженням, а не рефлексом. Збирайте, коли ваду експлуатують або вона тривіально експлуатована, зачеплені хости досяжні і жодне пом’якшення не закриває шлях достатньо добре. Інакше надійне пом’якшення плюс коротке очікування пакета виробника зазвичай є спокійнішим вибором.

Ведіть облік і повідомляйте людей

Ведіть хронологію в процесі

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

Повідомте людей до того, як вони запитають

Люди, що залежать від зачеплених систем, почують про гучну вразливість з новин, часто за лічені години. Повідомте їх першими. Коротке повідомлення про те, чи зачеплені їхні системи, що вже зроблено і коли прийде виправлення, варте більше за ідеальний звіт тижнем пізніше. Якщо якийсь крок потребує простою, узгодьте з ними час, перш ніж його брати.

Розгортайте по одному хосту за раз, з доказом

Кожен хост отримує перевірку до і перевірку після, і їх порівнюють, а не оглядають оком:

php -m | sort > pre-modules.txt      # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

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

Потім запитайте, чи було використано вікно

Патчинг зачиняє двері. Він не каже вам, чи хтось пройшов крізь них, поки вони були відчинені. Коли розгортання завершено, перешукайте веб-логи та логи автентифікації за період між оприлюдненням і патчем на кожному відкритому хості. Шукайте форми запитів, потрібні експлойту, несподівані процеси або файли, створені в тому вікні, і входи, які не вкладаються у звичну картину. Запишіть, що знайшли, включно з «нічого», бо люди, які залежать від цих систем, запитають.

Коротка версія

• Читайте умови, а не лише критичність.
• Інвентаризуйте з бази даних пакетів, а не з пам’яті.
• Пом’якшуйте протягом годин.
• Збирайте виправлення самі лише тоді, коли це виправдано, і робіть це чистим способом.
• Ведіть хронологію і рано повідомляйте зачеплених людей.
• Розгортайте по одному хосту за раз з порівнюваними перевірками до і після та автоматичною зупинкою.
• Переглядайте вікно експозиції в логах і звітуйте про нього.

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

Related (rows[1])

Пов’язане: Реагування на критичні вразливості в той самий день · Hardening baseline на кожному хості · Актуальність платформ і дисципліна оновлень