Накратко: Пентест или сканиране за уязвимости не е въпрос на „или-или“, а на ред. Сканирането за уязвимости намира автоматизирано познати уязвимости и грешни конфигурации, бързо и евтино, но с фалшиви аларми и слепи петна. Тестът за проникване проверява целенасочено какво нападател действително би могъл да постигне. Програмата Bug Bounty отваря проверката за външни изследователи и си струва едва когато сканирането и пентестовете са рутина. За повечето малки и средни фирми редът е: редовно сканиране, отстраняване на находките, целенасочен тест, създаване на звено за съобщаване на уязвимости.
Защо въпросът след PHP2Shell се поставя наново
Който след PHP2Shell проверява уебсайта си с онлайн скенер, може да получи объркващи резултати. Един скенер съобщава евентуално за критична уязвимост, въпреки че хостинг доставчикът е потвърдил пача. Друг не съобщава нищо, въпреки че сървърът още ползва стара версия на PHP, защото информацията за версията е скрита.
Причината е в начина на работа. Много скенери извеждат уязвимостта от показваната версия. Дистрибуциите обаче инсталират backport-ове, без да променят номера на версията; според съобщенията например Ubuntu 24.04 след ъпдейта продължава да показва 8.3.6. Защо е така, обяснява Защо php -v след ъпдейта показва същия номер. Надеждното доказателство дава changelog-ът на пакета, вижте Как да проверите правилно версията на PHP и състоянието на пача.
Това не е аргумент срещу скенерите, а за това да познавате границите им и да ги комбинирате с други методи.
Пентест или сканиране за уязвимости: трите метода в сравнение
| Критерий | Сканиране за уязвимости | Тест за проникване | Bug Bounty |
|---|---|---|---|
| Кой проверява? | Автоматизиран инструмент | Възложени специалисти | Външни изследователи, често чрез платформа |
| Какво се намира? | Познати уязвимости, остарели версии, грешни конфигурации | Използваеми слабости, логически грешки, вериги | Каквото изследователите намерят и съобщят, често необичайно |
| Дълбочина | Широко, но повърхностно | Дълбоко в договорения обхват | Различна, зависи от участниците |
| Фалшиви аларми | Чести | Редки, находките се доказват | Много съобщения, които трябва да се оценяват |
| Планируемост | Висока, повтаряемо по желание | Висока, фиксиран период и обхват | Ниска, съобщенията идват непрекъснато |
| Предпоставки във фирмата | Някой, който оценява резултатите | Съгласуван обхват, тестова среда или прозорец за поддръжка | Зрял процес за оценка, отстраняване и възнаграждение |
| Типично приложение | Непрекъснато, например месечно или след промени | Преди пускане, след по-големи промени, редовно | Допълнително при зрели, изложени приложения |
Нито един от методите не замества другите. Сканирането показва много за кратко време, пентестът показва какво наистина има значение, а Bug Bounty намира онова, за което никой не е помислил.
При скенерите си заслужава и втори поглед върху вида на сканирането. Сканиране отвън вижда само това, което вижда всеки посетител, и често трябва да налучква версиите от отговорите на сървъра. Автентифицирано сканиране, при което инструментът със собствени данни за достъп чете инсталираните пакети на сървъра, дава значително по-надеждни резултати, особено за действителното състояние на пакета на PHP. То предполага обаче да настроите за целта ограничен достъп и да го защитите добре. За зависимостите на собствени PHP приложения има от своя страна собствени инструменти за проверка, например composer audit за пакети от Composer.
Разумният ред за малките и средните фирми
- Инвентар и сканиране: Първо да знаете кои уебсайтове и сървъри има, после да сканирате редовно. Находките не се приемат непроверени, а се оценяват.
- Отстраняване на основите: Премахнете остарелия софтуер, липсващите ъпдейти и очевидните грешни конфигурации. Да се насрочи пентест върху непачнати системи е прахосване на бюджет.
- Целенасочен тест за проникване: За най-важните приложения, например магазин, клиентски портал или интерфейси, с ясно договорен обхват и повторен тест.
- Проверка на кода при собствени разработки: Който стопанисва собствени PHP приложения, допълва теста с преглед на изходния код. Как протича това, описва Преглед на кода за сигурност в PHP проекти.
- Звено за съобщаване на уязвимости: Политика как външни лица могат да съобщават уязвимости и файл security.txt по RFC 9116 на
/.well-known/security.txtс контакт и срок на валидност. - Bug Bounty, когато основите стоят: Едва когато съобщенията се оценяват надеждно, а уязвимостите се отстраняват своевременно.
За да стане от това траен процес, си заслужава погледът към Управление на уязвимостите в средния бизнес.
Какво не постига нито един от методите
Никой метод за проверка не доказва, че една система е сигурна. Той показва само това, което е намерено в даден момент с определени методи. Чист доклад от пентест от пролетта не казва нищо за уязвимост като PHP2Shell, която става известна през октомври.
Също така нито сканирането, нито пентестът отговарят на въпроса дали един сървър вече е компрометиран. За това е нужно търсене на следи в самата система: процеси, файлове, cron задачи, акаунти, връзки. Това е отделна задача със собствени методи.
Проверявайте само системи, за които имате право, и изяснявайте предварително при хоствани системи правилата на доставчика. Тестът за проникване изисква писмено възлагане с обхват, период и лица за контакт.
Кога не Ви трябва външен тест
За прост фирмен уебсайт без формуляри с чувствителни данни, при хостинг доставчик, който инсталира ъпдейтите надеждно, често е достатъчно редовно сканиране с критична оценка на резултатите. Тестът за проникване тук би бил обикновено несъразмерен. По-важни са актуалният софтуер, силните достъпи и резервните копия.
Външен тест си струва при магазини, портали, собствени разработки, интерфейси към вътрешни системи и навсякъде, където клиенти или норми изискват независимо доказателство.
Как помага PHP SOS конкретно?
- Настройваме редовни сканирания и оценяваме резултатите, включително фалшивите аларми от backport-ове.
- Помагаме да се отстранят основите, преди парите да потекат към пентест.
- Заедно със специализирани партньори провеждаме одити на сигурността и тестове за проникване със съгласуван обхват и повторен тест.
- Подкрепяме при изграждането на звено за съобщаване на уязвимости и на security.txt.
Извод
Сканирането, пентестът и Bug Bounty са стъпала, а не конкуренти. Който започне с редовни сканирания, отстрани основите и след това тества целенасочено, получава най-много сигурност за бюджета си. Bug Bounty е допълнение за организации, чието задължително вече стои.
Често задавани въпроси
Каква е разликата между пентест и сканиране за уязвимости?
Сканирането за уязвимости проверява автоматизирано дали познати уязвимости или грешни конфигурации са разпознаваеми. Тестът за проникване отива по-далеч: специалисти в договорена рамка се опитват действително да използват слабостите и да ги свързват и оценяват последствията.
Установява ли скенерът дали сървърът ми е пачнат срещу PHP2Shell?
Само ограничено. Много скенери четат показваната версия на PHP. Ако дистрибуцията инсталира backport, номерът често остава същият и скенерът съобщава за уязвимост, която отдавна е затворена. Обратно, може да се показва нов номер, докато стари процеси още работят.
Подходяща ли е програма Bug Bounty за малки фирми?
Обикновено още не. Bug Bounty предполага съобщенията да се оценяват бързо, а уязвимостите да се отстраняват своевременно. Добро начало е проста политика за съобщаване на уязвимости с файл security.txt.
Мога ли сам да проверя уебсайта си със скенер?
Собствените си системи по правило да, ако имате право. Ако уебсайтът е при хостинг доставчик, изяснете предварително дали сканиранията са разрешени или подлежат на обявяване. Чужди системи проверявате само с писмено разрешение на оператора.
Колко често трябва да се прави пентест?
Няма твърдо правило. Обичайно е тест преди пускането на ново приложение, след по-големи промени и на редовни интервали, определяни от Вашия риск и евентуално от изисквания на клиенти или норми.