Накратко: Автоматизираните атаки срещу уеб сървъри протичат на вълни: програми претърсват интернет за достъпни сървъри, класифицират ги по външни признаци и пробват масово известни уязвимости като PHP2Shell. Размерът на фирмата няма значение. Защита дават пачнат PHP, малка повърхност за атака и наблюдение, което бързо забелязва успешните попадения.
Поводът: „Кой би се интересувал от нашия уебсайт?“
Този въпрос чуваме често след PHP2Shell, най-вече от по-малки фирми. Честният отговор: вероятно никой лично. Но при уязвимости от този вид и не е нужно. Атаките се изпълняват от програми, които не търсят имена, а възможности.
BSI (Федералната служба за информационна сигурност на Германия) очакваше при PHP2Shell бърза експлоатация в голям мащаб. Cloudflare съобщи за опити за атака и за това, че нападателите са променяли модела си, за да заобиколят правилата за защита. И двете неща съответстват на онова, което редовно се случва при критични уязвимости в много разпространен софтуер.
Как протичат автоматизираните атаки срещу уеб сървъри
Автоматизираните кампании обикновено следват сходен модел. Следният преглед описва фазите общо, без подробности за атаката:
| Фаза | Какво се случва | Какво помага срещу това |
|---|---|---|
| Търсене | програми проверяват големи адресни диапазони или публични регистри като протоколите на сертификатите за достъпни уеб сървъри | малко публично достъпни системи, инвентар на всички адреси |
| Класифициране | отговорите се анализират: уеб сървър, PHP версия, CMS, типични пътища | скриване на указанията за версия, премахване на ненужни файлове |
| Пробване | известни уязвимости се тестват масово, често без предварително класифициране | актуален PHP, рестарт, WAF като допълнителен слой |
| Закрепване | при успех се оставя задна вратичка, например уеб шел или cron задача | ограничени права за писане, без изпълнение на PHP в папките за качване |
| Експлоатация | сървърът се използва, например за спам, криптомайнинг, пренасочвания или кражба на данни | наблюдение на процеси, файлове и изходящи връзки |
Важен е третият ред. Много кампании изобщо не си правят труда първо да класифицират точно сървърите. Те просто пробват всичко, което е достъпно. Затова само незабележимостта не защитава.
Защо атаките идват на вълни
Автоматизираните кампании рядко текат веднъж и после никога повече. Типичен е моделът на вълни. Първата вълна следва малко след като уязвимостта стане известна, често още с недоразвити инструменти. Следващи вълни идват, когато нападателите подобрят инструментите си или ги приспособят към правилата за защита. Cloudflare наблюдава точно това при PHP2Shell: променени модели на атака, за да се заобиколят правилата.
За Вас това означава: сървър, който е преминал невредим първата вълна, не е трайно сигурен, докато е непачнат. А новоинсталиран сървър е цел от момента, в който стане достъпен. Който например издаде нов TLS сертификат, прави името видимо в публичните протоколи на сертификатите, които скенерите също анализират. Затова новата система трябва да излезе в мрежата едва когато вече е актуализирана.
Защо малките фирми са засегнати със същата сила
За автоматизираните атаки не е важна стойността на отделната цел, а количеството. Сървърът на малка фирма предлага изчислителна мощност, домейн с добра репутация, изпращане на поща и понякога данни на клиенти. За нападателите това е достатъчно.
Към това се добавя: по-малките фирми често нямат собствена ИТ, която да инсталира актуализациите веднага. Сървърите им остават уязвими по-дълго и затова по-често попадат в списъците с резултати на скенерите. Който пачва пръв, отпада от тези списъци.
Друга точка е веригата на доставки. Много малки уебсайтове са на сървъри на агенции или на малки хостинг доставчици, където работят дузини клиентски проекти един до друг. За нападателите такъв сървър е особено изгоден, защото едно-единствено попадение засяга много уебсайтове едновременно. Вашият риск тогава зависи не само от Вашата собствена грижа, но и от тази на Вашия доставчик на услуги.
Сканиранията във Вашите логове са нормални и не са доказателство за проникване. Успешната атака се проявява с други следи: нови файлове, чужди процеси, непознати акаунти, необичайни изходящи връзки.
Какво можете да проверите сами
Поглед в логовете показва колко силно се сканира Вашият сървър. Следните команди само четат и нищо не променят:
# Десетте адреса с най-много заявки в текущия лог за достъп
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Заявки, на които е отговорено с „не е намерено“, по честота
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Издава ли сървърът PHP версията си в заглавието?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Много заявки към несъществуващи пътища са типичен фон от сканиране. По-внимателни трябва да станете, ако на такива заявки внезапно последват успешни отговори, ако в папките за качване се извикват файлове, които не познавате, или ако потребителят на уеб сървъра стартира процеси, които иначе никога не стартира. Потвърдени признаци за разпознаване специално за PHP2Shell засега няма, затова оценката се основава на такива отклонения в поведението. Как да анализирате логовете по-задълбочено, описва ръководството Анализ на логовете на уеб сървъра. Ако третата заявка покаже PHP версия, струва си настройката expose_php = Off; основите са в Скриване на указанията за версия.
Слоевете на защитата в правилния ред
- Актуализирайте PHP и рестартирайте: Без тази стъпка всички други мерки остават кърпеж.
- Намалете повърхността за атака: неизползвани уебсайтове, тестови системи и стари микросайтове изключете или сложете зад вход.
- Правила по периферията: Web Application Firewall с поддържан набор от правила, например OWASP Core Rule Set с ModSecurity, улавя част от опитите.
- Забавете повторните опити: Инструменти като Fail2ban блокират адреси, които предизвикват необичайно много грешки. Срещу разпределени сканирания това помага само ограничено.
- Наблюдавайте: Следете процесите на потребителя на уеб сървъра, новите PHP файлове и изходящите връзки, за да не остане успешно попадение седмици незабелязано.
Как помага PHP SOS конкретно?
- Описване на повърхността за атака: Установяваме кои от Вашите системи са достъпни отвън и какво издават за себе си.
- Пач и заздравяване: Актуализираме PHP, рестартираме и намаляваме указанията за версия, правата за писане и ненужните услуги.
- Правила и блокиране: Изграждаме WAF правила и механизми за блокиране, съобразени с Вашето приложение.
- Текущо наблюдение: Съобщаваме за необичайни процеси, файлове и връзки, преди едно попадение да стане инцидент.
Как изглежда това в постоянен режим, описва Мониторинг на сигурността на уеб сървъри.
Заключение
Автоматизираните атаки не питат на кого принадлежи един сървър. Те питат само дали е уязвим. Най-добрият отговор на това е непретенциозен: пачвайте бързо, предлагайте малко, гледайте внимателно. Който го прави, продължава да бъде сканиран, но вече не бива намиран.
Често задавани въпроси
Малките фирми цел ли са на автоматизирани атаки?
Да. Автоматизираните сканирания проверяват достъпни сървъри, без да гледат кой е операторът. Дали зад него стои концерн или занаятчийска фирма, за софтуера няма значение. Решаващо е дали сървърът изглежда уязвим.
По какво разпознавам сканирания в моите логове?
Типични са много заявки към пътища, които на Вашия уебсайт изобщо не съществуват, често от сменящи се адреси и със странни идентификатори. Такива записи са нормални и още не са доказателство за успешна атака, но показват, че сървърът Ви се проверява.
Помага ли скриването на PHP версията?
Прави малко по-трудно за скенерите да определят целенасочено Вашия сървър и е смислена основна настройка. Не защитава обаче от атаки, които просто пробват всеки сървър. Актуализацията остава задължителна.
Мога ли напълно да предотвратя сканиранията?
Не. Всеки публично достъпен сървър се сканира редовно. Целта не е да се предотвратят сканиранията, а да се осигури, че те не намират нищо: актуален софтуер, малка повърхност за атака и наблюдение, което съобщава за необичайни находки.