Блог: PHP2Shell, сигурност на сървъри и спешна помощ
Оценка на ситуацията, ръководства за администратори и помощ при вземане на решения за ръководството. Подредени по теми, всяка статия е с източници.
Ситуация и оценка
17 статии
PHP2Shell: какво е доказано и какво не
Проверка на фактите за PHP2Shell: кои твърдения идват от първични източници, кои от медийни съобщения и кои твърдения не издържат проверка.
Прочетете още →002Защо PHP уязвимостта стана известна преди пача
Според съобщенията подробности за PHP2Shell са станали публични преди изтичането на ембаргото. Обясняваме хода на събитията и какво означава той за планирането на пачовете.
Прочетете още →003Институции изключват уебсайтове: какво да научат фирмите от това
Майнц, правителството на Хесен и BKA изключиха уебсайтове предпазно. Какво могат да научат фирмите от това за собственото си решение.
Прочетете още →004BSI ниво на предупреждение оранжево: какво означава оценката
BSI оценява PHP2Shell с 3 / оранжево. Какво казва скалата и какво не, и как фирмите да превърнат оценката в решения.
Прочетете още →005Какво съветват CERT-EU и CERT-Bund за PHP2Shell
Официалните органи са единодушни: пачвайте незабавно, иначе изолирайте. Сравняваме препоръките и показваме как изглежда изолирането на практика.
Прочетете още →006Правилата за защита на Cloudflare срещу PHP2Shell: какво постигат и какво не
Cloudflare рано пусна правила за защита срещу PHP2Shell. Защо това помага, защо въпреки това не заменя актуализацията на PHP и кои настройки да проверите.
Прочетете още →00722,6 милиона изложени инстанции: как да осмислим числата
Unit 42, CybelAngel и други посочват твърде различни числа за PHP2Shell. Обясняваме какво е броено и кое число наистина има значение за Вас.
Прочетете още →008PHP2Shell за пет минути: брифинг за управителите
PHP уязвимостта PHP2Shell на една страница за вземащите решения: ситуация, риск, пет въпроса към ИТ и решенията за днес.
Прочетете още →009PHP уязвимостта в сигурността, обяснена просто
PHP2Shell за нетехници: с картини от ежедневието, малък речник и три типични изходни положения - какво да направите като собственик на уебсайт.
Прочетете още →010PHP2Shell: 15 въпроса на клиенти на хостинг
Уебсайтът Ви е при хостинг доставчик и искате да знаете какво трябва да направите сами при PHP2Shell? Ето 15-те най-чести въпроса с кратки отговори.
Прочетете още →011Защо актуализацията на WordPress не помага срещу PHP2Shell
След заглавията много оператори актуализираха WordPress и се чувстват сигурни. Защо при PHP2Shell това е напразно и какво има значение вместо това.
Прочетете още →012PHP2Shell и Log4Shell: какво е общото между уязвимостите
Мнозина сравняват PHP2Shell с Log4Shell от 2021 г. Докъде стига сравнението, къде куца и кои поуки от онова време помагат днес.
Прочетете още →013Масови сканирания за непачнат PHP: как протичат автоматизираните атаки
След PHP2Shell нападателите претърсват автоматизирано интернет за уязвими сървъри. Как протича това, защо размерът няма значение и какво Ви защитава.
Прочетете още →014Времевият прозорец между пач и атака
При PHP2Shell имаше опити за атака още преди пача. Обясняваме фазите на времевия прозорец, как да измерите собствения си и как да го съкратите.
Прочетете още →015След PHP2Shell: защо още съобщения са вероятни
PHP2Shell не е приключила с пача от 21 октомври. Защо се очакват последващи съобщения и как да настроите екипа си за това.
Прочетете още →016PHP2Shell: картината на положението след първата седмица
Една седмица след първия наблюдаван опит за атака: състоянието на пачовете, предупрежденията на институциите, атаките и изключванията, подредени ясно по източници.
Прочетете още →017Опасни погрешни съвети за PHP2Shell, които в момента циркулират
Блокиране на бисквитки, скриване на съобщения за грешки, актуализиране само на CMS: девет съвета за PHP2Shell, които създават фалшива сигурност, и какво наистина има значение.
Прочетете още →Хостинг и дистрибуции
18 статии
Смяна на PHP версията в клиентската зона на хостинга
Как да смените PHP версията в клиентската зона на хостинг доставчика, коя версия да изберете и какво да проверите преди и след това.
Прочетете още →019Debian и Ubuntu: пачнат ли е моят PHP пакет?
Кои PHP пакети Debian и Ubuntu са коригирали срещу PHP2Shell, как да сравните точно инсталираното състояние и къде се проваля доказването.
Прочетете още →020RHEL, AlmaLinux и Rocky Linux: проверка на PHP пача
Какво публикува Red Hat за PHP2Shell, как да докажете състоянието на пакета на RHEL и клоновете му и защо презареждането не стига.
Прочетете още →021Хранилището sury.org: PHP пакети от външен източник
Много сървъри с Debian и Ubuntu вземат PHP от хранилището sury. Какво означава това за актуализациите, доказателствата и старите PHP версии след PHP2Shell.
Прочетете още →022Хранилището Remi: поддържане на PHP на RHEL системи актуален
Remi доставя актуални PHP версии за семейството RHEL, като модул или за паралелна инсталация. Така проверявате състоянието след PHP2Shell и избягвате забравени клонове.
Прочетете още →023Защо php -v показва същия номер след актуализацията
Актуализацията мина, но php -v съобщава старата версия. Най-често това е backport, а не грешка. Така разграничавате безобидното от истинските проблеми.
Прочетете още →024Доказване на CVE номера в changelog на пакета
Който трябва да докаже PHP пача пред ръководството, одиторите или застрахователите, се нуждае от повече от номер на версия. Така записът в changelog става доказателство.
Прочетете още →025Смяна на хостера след инцидент със сигурността: на какво да обърнете внимание?
След инцидент желанието за нов хостер е разбираемо. За да не отнесе сменянето нападателя със себе си, значение имат редът на стъпките и изборът.
Прочетете още →026Няколко версии на PHP на един сървър: пачнете всяка поотделно
На много сървъри работят три, четири или повече PHP инсталации една до друга. След PHP2Shell всяка трябва да бъде намерена, актуализирана и рестартирана.
Прочетете още →027Изключване на стари версии на PHP в хостинг панела
PHP2Shell е добър повод да се освободите от старите версии на PHP. Така действате на три фази, за да не отпадне незабелязано нито уебсайт, нито cron задача.
Прочетете още →028Plesk: разбиране на PHP handler-ите (FPM, FastCGI, Apache модул)
Кой PHP handler Plesk ползва за уебсайт, решава изолацията, конфигурацията и риска. Сравнение с поглед към PHP2Shell.
Прочетете още →029CloudLinux и alt-php: какво трябва да знаят хостинг клиентите
На сървъри с CloudLinux уебсайтовете често работят със собствени пакети alt-php. Всяка от тези версии изисква собствен пач и само операторът на сървъра може да го инсталира.
Прочетете още →030PHP на NAS, защитни стени и устройства: забравените системи
Не само уеб сървърите ползват PHP. Засегнати могат да бъдат и NAS системи, защитни стени и специализирани устройства с уеб интерфейс. Пачва ги обикновено само производителят, достъпността регулирате Вие.
Прочетете още →031PHP при облачни и PaaS доставчици: кой пачва средата за изпълнение?
При платформените услуги PHP пачът зависи от модела на работа. Решаваща е средата за изпълнение, която наистина обслужва, не локалната среда и не кодът на приложението.
Прочетете още →032Официални PHP Docker образи: тагове, digest и ново изграждане
Тагът на официалния PHP образ е указател, който с времето се премества към нови състояния. Който знае какво значат таг, вариант и digest, избира правилния образ и може да докаже състоянието на пача.
Прочетете още →033CI/CD: автоматично ново изграждане на PHP образи
Образът остарява и без промяна в кода. С build-ове по график, проверка на версията и разполагане по digest PHP пачовете стигат надеждно до продукция.
Прочетете още →034Дългосрочна поддръжка за стари версии на PHP: опции и граници
Който не може веднага да премине от PHP 8.1 или по-стара версия, намира дългосрочна поддръжка при дистрибуции, външни доставчици и комерсиални услуги. Какво постигат тези пътища, какво Ви трябва писмено и къде са границите.
Прочетете още →035Актуализиране на PHP под Windows
Под Windows няма автоматична актуализация на PHP. Който избере правилния вариант, провери изтеглянето и рестартира всички процеси, довежда пача за PHP2Shell чисто на всеки компютър.
Прочетете още →Откриване и форензика
18 статии
Предупредителен сигнал: уеб сървърът стартира shell
Ако процес на PHP-FPM или на уеб сървъра стартира shell, това е един от най-силните предупредителни сигнали за проникване. Така проверявате дървото на процесите, класифицирате изключенията и наблюдавате модела трайно.
Прочетете още →037Намиране на подозрителни процеси на Linux сървъри
Злонамерените процеси се маскират с безобидни имена, работят от временни директории или от изтрити файлове. С малко команди само за четене намирате странностите и ги класифицирате.
Прочетете още →038Разпознаване на скрити cron задачи като задна вратичка
Нападателите ползват планирани задачи, за да се върнат след почистване. Така проверявате изцяло crontab файловете, cron директориите, таймерите на systemd и задачите at и разпознавате подозрителните записи.
Прочетете още →039Намиране на наскоро променени файлове на уеб сървъра
След възможно проникване има значение какво се е променило на сървъра. Така търсите по времеви прозорци, ползвате правилно mtime и ctime и сверявате с пакети, Git и резервни копия.
Прочетете още →040PHP файлове в директорията за качване: правилно тълкуване на находките
PHP файл в директорията за качване е почти винаги тревожен знак, но не всеки е злонамерен код. Така оценявате находката, без да унищожите следи, и изяснявате дали някой го е извикал.
Прочетете още →041Разпознаване на замъглен PHP код
Нечетим PHP код с eval и base64_decode е класически знак за вмъкнат злонамерен код. Какви шаблони да търсите, как да ги намирате безопасно и кога замъгляването е легитимно.
Прочетете още →042Проверка на изходящите връзки на един сървър
Уеб сървърът отговаря преди всичко на заявки. Ако сам изгражда връзки към непознати цели, това може да означава управление от нападатели или изтичане на данни. Така проверявате и ограничавате изходящия трафик.
Прочетете още →043Намиране на чужди админ акаунти в CMS и на сървъра
Непознатият администратор често е най-простата задна вратичка. Така търсите ниво по ниво чужди акаунти, и такива, които интерфейсът скрива.
Прочетете още →044Намиране и премахване на непознати SSH ключове
Вмъкнат SSH ключ отваря вратата на нападателите, дори всички пароли да са сменени. Така намирате всеки файл authorized_keys и проверявате всеки запис.
Прочетете още →045Криптоминър на уеб сървъра: признаци и действия
Постоянно пълно натоварване на процесора, без да идват повече посетители: това може да е криптоминър. Така проверявате натоварването, намирате процеса и механизмите му за рестарт и действате подредено.
Прочетете още →046Сървърът изпраща спам: намиране на причините
Недоставени писма, черни списъци, оплаквания: когато собственият сървър изпраща спам, зад това обикновено стои скрипт или превзета пощенска кутия. Така намирате източника.
Прочетете още →047SEO спам и чужди страници в индекса на Google
Изведнъж под Вашия домейн се класират страници за лекарства или стоки с чужди марки. Така ще откриете откъде идва SEO спамът и ще го изведете от индекса.
Прочетете още →048Уебсайтът пренасочва към чужди страници
Посетителите попадат на томболи или съмнителни магазини, а Вие самият не виждате нищо? Така ще откриете слоя, в който се крие пренасочването, и ще го премахнете.
Прочетете още →049Запазете доказателствата, преди да преинсталирате сървъра
Новата инсталация премахва нападателя, но и всички следи. Който преди това отдели един час за запазване на доказателства, по-късно може да каже какво се е случило.
Прочетете още →050Изготвяне на времевата линия на един инцидент
Кога е дошъл нападателят, какво е направил, кога е забелязано? Добре водена времева линия отговаря на тези въпроси и е основа за уведомления, застраховка и отчет.
Прочетете още →051Сравняване на основните файлове на CMS с оригинала
Сравнението с чист оригинал показва всеки променен файл, независимо дали скенерът го познава. Така изграждате проверката за WordPress, Composer проекти и системни пакети.
Прочетете още →052Проверка на базата данни за внедрен код
Който проверява само файловете, пропуска половината. Така претърсвате съдържанието, настройките, тригерите и акаунтите в базата данни за внедрен код, само за четене и върху копие.
Прочетете още →053Скенери за зловреден софтуер на сайтове: какво откриват и какво не
Скенерът не съобщава нищо, значи всичко е наред? Не непременно. Какви видове скенери за сайтове има, какво вижда всеки от тях и какво по принцип не може да види.
Прочетете още →Заздравяване и конфигурация
20 статии
Изолиране на PHP-FPM пулове за всеки сайт
Отделен пул за всеки сайт е началото, не краят. Така проверявате съществуващите пулове и заздравявате сокетите, разширенията, статус страниците, ресурсите и логовете.
Прочетете още →055Правилна настройка на memory_limit
memory_limit ограничава паметта за всяка PHP заявка. След PHP2Shell php.net временно съветва обратното. Какво важи в нормална работа, по време на прехода и след актуализацията.
Прочетете още →056Разумно ограничаване на post_max_size и upload_max_filesize
Лимитите за качване действат на три места: в уеб сървъра, в PHP и в приложението. Така задавате стойностите съгласувано, включително с преходните стойности на php.net за PHP2Shell.
Прочетете още →057Изключване на session.upload_progress: правилно и трайно
Мярката срещу CVE-2026-115560 и една от преходните мерки за PHP2Shell се задава бързо. За да издържи, тя трябва да стои на правилното място, да е заключена и да се проверява отново след всяка актуализация.
Прочетете още →058expose_php и Server заглавия: скриване на данните за версиите
PHP, Nginx и Apache по подразбиране посочват номера на версията си във всеки отговор. Това не защитава от атаки, но дава на скенерите удобен списък с цели. Така го изключвате и въпреки това запазвате прегледа.
Прочетете още →059display_errors off: изключване на изхода на грешки в продукция
Видимите съобщения за грешки на PHP издават пътища, имена на бази данни и версии. Така ги изключвате в PHP, в рамката и в уеб сървъра, без да изпускате грешките от поглед.
Прочетете още →060php_admin_value: заключване на настройки срещу презаписване
Настройка за сигурност помага малко, ако приложението я променя отново с един ред код. С php_admin_value и php_admin_flag фиксирате стойности за PHP-FPM и Apache задължително.
Прочетете още →061Задаване на лимити на паметта със systemd и cgroups
php.net препоръчва като преходна мярка за PHP2Shell memory_limit=-1 и лимит на паметта извън PHP. Така задавате този лимит със systemd и cgroups, без един отделен worker да повлече цялата услуга.
Прочетете още →062Сигурна конфигурация на Nginx за PHP
Повечето слабости в Nginx настройките за PHP не са в Nginx, а в няколко реда на PHP location. Така конфигурирате предаването към PHP-FPM, че да се изпълняват само желаните скриптове.
Прочетете още →063Сигурна конфигурация на Apache за PHP
Apache е гъвкав и именно това го прави уязвим към погрешна конфигурация. Така свързвате PHP през PHP-FPM, затваряте .htaccess като задна врата и настройвате сигурно най-важните основни опции.
Прочетете още →064Забрана за изпълнение на PHP в папки за качване
Уеб шелът се нуждае от две неща: папка, в която може да се записва, и сървър, който го изпълнява. Така му отнемате второто, и то във всяка папка с право за писане, не само в uploads.
Прочетете още →065Филтриране на заявки за качване в периферията: възможности и рискове
Специалисти предлагат заявките за качване извън истинските пътища за качване да се блокират на прокси сървъра, докато PHP не бъде пачнат. Това може да помогне, но и да спре формуляри и поръчки. Така действате контролирано.
Прочетете още →066Внедряване на ModSecurity и OWASP Core Rule Set
Собствена Web Application Firewall с ModSecurity и OWASP Core Rule Set е безплатна и мощна, но не работи сама. Така избирате двигател, стартирате без прекъсвания и настройвате правилата.
Прочетете още →067Настройка на Fail2ban за уеб сървъри
Fail2ban блокира адреси, които многократно се набиват на очи в логовете. За уеб сървъри има готови филтри, а с няколко реда се добавят собствени. Така го настройвате, без да блокирате себе си или клиентите си.
Прочетете още →068Защитна стена за уеб сървъри: отваряйте само необходимите портове
Уеб сървърът обикновено се нуждае навън само от два порта. Въпреки това на много сървъри в интернет слушат бази данни, PHP-FPM или административни интерфейси. Така намирате отворените услуги и затваряте ненужните.
Прочетете още →069Автоматични актуализации за сигурност на Linux сървъри
Според съобщения дистрибуциите са доставяли backport корекции за PHP понякога още на 21 октомври 2026 г., деня на пачовете. Който ползва автоматични актуализации за сигурност, ги е имал бързо на сървъра. За да действат, са нужни рестартирания, външни източници и контрол.
Прочетете още →070Least Privilege: права на потребителя на уеб сървъра
Внедреният код се изпълнява с правата на потребителя на уеб сървъра. Какво може този акаунт, определя докъде стига атакуващият. Ето как да ограничите shell, sudo, cron, базата данни и файловата система до необходимото.
Прочетете още →071Скриване на админ частта чрез IP, VPN или допълнителна защита
Защо административната част на един уебсайт не трябва да е достъпна за целия свят и как да я скриете чрез IP филтър, VPN или предварителен вход, без да заключите сами себе си.
Прочетете още →072Правилна конфигурация на TLS и HTTPS
Кои версии на TLS и кои набори от шифри (cipher suites) трябва да предлага един уеб сървър днес, на какво се опират препоръките и как да проверите Nginx, Apache и изходящите връзки на PHP.
Прочетете още →073CIS Benchmarks и модули на BSI за уеб сървъри
Какви стандарти за заздравяване има за Linux уеб сървъри, с какво се различават CIS Benchmarks и модулите на IT-Grundschutz и как да превърнете това в проверима насока за Вашите PHP сървъри.
Прочетете още →Сигурна разработка
16 статии
Сигурно съхранение на пароли в PHP: правилно използване на password_hash
Как разработчиците съхраняват пароли в PHP с password_hash и password_verify, избират подходящия метод и заменят стари MD5 или SHA-1 хешове, без да принуждават всички потребители да сменят паролата си.
Прочетете още →075CSRF защита в PHP приложения
Как разработчиците предотвратяват Cross-Site Request Forgery в PHP приложения: токени за всяка заявка, която променя данни, проверка на произхода в заглавната част и SameSite бисквитки като допълнителен слой.
Прочетете още →076Валидиране и филтриране на вход в PHP с filter_var
Как разработчиците проверяват входа в PHP с filter_var, filter_input_array и списъци с разрешени стойности, кои филтри са остарели и защо валидирането не замества Prepared Statements и кодирането на изхода.
Прочетете още →077Предотвратяване на Command Injection в PHP
Как разработчиците избягват Command Injection в PHP: замяна на системни команди с PHP функции, proc_open без shell, проверка на аргументите и откриване на опасните места в съществуващия код.
Прочетете още →078Предотвратяване на Server-Side Request Forgery (SSRF) в PHP
Как разработчиците предотвратяват PHP приложение да запитва вътрешни системи по поръчка на външни лица: списъци с разрешени стойности, ограничаване на протоколите, проверка на разрешения адрес и граници в мрежата.
Прочетете още →079Предотвратяване на XML External Entities (XXE) в PHP
Как разработчиците обработват XML сигурно в PHP: стандартно поведение на libxml, рискови опции като LIBXML_NOENT, защита с Entity Loader и LIBXML_NO_XXE и типични скрити входове за XML.
Прочетете още →080Type Juggling в PHP: хлабавите сравнения като риск за сигурността
Защо хлабавите сравнения с == в PHP могат да доведат до уязвимости, какво се промени с PHP 8.0 и как да пишете устойчиви сравнения във входове, токени и права.
Прочетете още →081Сигурни случайни числа и токени в PHP с random_bytes
Как разработчиците създават в PHP токени за връзки за парола, API ключове и еднократни кодове: криптографски сигурни източници, достатъчна дължина, съхранение като хеш и ограничена валидност.
Прочетете още →082Правилна защита на данните за достъп и .env файловете
Как да защитите пароли за бази данни, API ключове и други тайни в PHP проекти: .env файлове извън уеб корена, блокиране в уеб сървъра, тесни права и подредена подмяна след инцидент.
Прочетете още →083Публична папка .git: недооценено изтичане на данни
Защо уеб корен, внедрен чрез Git, може да разкрие целия изходен код заедно с историята, как да го проверите, да го блокирате веднага и да изградите внедряването трайно без папка .git.
Прочетете още →084Резервни файлове в уеб корена: .zip, .sql и .bak
Защо дъмповете на бази данни, архивите и резервните копия в публичната директория са сред най-честите изтичания на данни, как да ги откриете, да ги блокирате и да изясните дали са били изтегляни.
Прочетете още →085Файлове phpinfo(): защо трябва да изчезнат
След PHP2Shell много администратори бързо създават info.php. Защо такива файлове са теч на данни, как да ги откриете и кои начини за проверка са по-добри.
Прочетете още →086Поддържане на зависимостите актуални: Composer, npm и добавки
Един проект се състои от три свята на пакети: Composer, npm и добавки за CMS. Как да поддържате и трите актуални с твърд ритъм, ясна отговорност и тестове.
Прочетете още →087Код ревю за сигурност в PHP проекти
Как екипите целенасочено преглеждат собствения PHP код за уязвимости: видове ревюта, критични функции, смислени инструменти и контролен списък.
Прочетете още →088Сигурно логване: записване на грешки без теч на данни
Журналите помагат при търсене на грешки и форензика, но бързо стават самите те теч на данни. Какво трябва да записват PHP приложенията, какво никога и как се защитават журналите.
Прочетете още →089Защита на REST API в PHP
Интерфейсите често са защитени по-зле от уебсайта пред тях. Най-важните правила за REST API в PHP, от правата върху обектите до ограничаването на честотата.
Прочетете още →Управление и право
14 статии
Договори с ИТ доставчици: ясно уреждане на задълженията за сигурност
PHP2Shell показа колко често е неясно кой трябва да пачва. Кои задължения за сигурност принадлежат в договорите с агенция, хостинг и ИТ доставчик.
Прочетете още →091Обработване на данни по поръчка, когато доставчици имат достъп до сървъри
Който допуска външни лица до сървъри с данни на клиенти, обикновено се нуждае от споразумение за обработване на данни (AVV). Какво изисква чл. 28 от ОРЗД и как да организирате достъпите при спешен случай в съответствие със защитата на данните.
Прочетете още →092Управление на уязвимостите в средния бизнес
Нито една средна фирма не може да обработи веднага всяко съобщение. Схемата с отчитане, оценка, решение и доказателства гарантира, че най-важното се прави първо.
Прочетете още →093Да знаем какво работи: инвентар на всички уебсайтове и сървъри
При PHP2Shell мнозина се спънаха не в пача, а във въпроса къде изобщо работи PHP. Ето как да изградите инвентар на всички уебсайтове и сървъри.
Прочетете още →094Управление на пачовете като процес, а не като гасене на пожари
Който пачва само когато гори, губи време в критичен момент. Как процес с твърди класове, прозорци и доказателства свързва рутината и извънредната ситуация.
Прочетете още →095Контакти за извънредни ситуации: кого и кога трябва да уведомим?
В критичен момент важи кого можете да достигнете и кога. Как да изградите списък с ИТ контакти за извънредни случаи, с поводи, заместници и данните, които всяко обаждане изисква.
Прочетете още →096Колко струва хакнат сървър: разходните пера
Хакнат уеб сървър струва повече от ремонта. Какви разходни пера възникват и как със собствени цифри да обосновете бюджет за превенция.
Прочетете още →097Уведомяване на клиентите след инцидент
Задължение или доброволно: как след инцидент да решите кого да уведомите, кои канали са сигурни и как да подготвите обслужването на клиенти.
Прочетете още →098Веригата в уеба: агенция, хостинг доставчик, доставчик на добавки
PHP2Shell показа колко звена има между един пач и Вашия уебсайт. Как да познавате веригата на уебсайта си, да я обезопасите и да поемете отпадането на отделни звена.
Прочетете още →099Осведоменост за сигурността при администратори и редактори: Security Awareness в уеб екипа
Който поддържа уебсайтове, решава ежедневно за сигурността, често без да го забелязва. Как да обучите администратори и редактори според ролята, без маратон от слайдове.
Прочетете още →100Упражнение за извънредни ситуации на маса: изиграване на инцидент с уеб сървър
Упражнение на маса отнема един следобед и показва дали Вашият план за извънредни ситуации издържа. Тук ще намерите готов сценарий за инцидент на PHP уеб сървър.
Прочетете още →101ISO 27001 и TISAX: какво засяга уеб сървърите
Който поддържа ISMS по ISO 27001 или има етикет TISAX, трябва да мисли и за уеб сървърите. Тук е описано кои изисквания ги засягат и кои доказателства имат значение след PHP2Shell.
Прочетете още →102VdS 10000: информационна сигурност за малки и средни предприятия
VdS 10000 е стегната рамка за информационна сигурност в средния бизнес. Какво изисква, какво дойде ново през 2025 г. и какво означава това за уебсайтовете и уеб сървърите.
Прочетете още →103Lessons Learned: да станем по-добри след инцидента
След инцидента е преди следващия. Структурирано обсъждане без търсене на виновни превръща една лоша седмица в измерим напредък.
Прочетете още →Помощ при вземане на решения
10 статии
Пач, изключване или изчакване? Помощ при решението за PHP уязвимостта
При критична PHP уязвимост отговорните трябва да решават бързо. Тази помощ подрежда трите варианта, посочва критерии и показва кога изчакването е допустимо.
Прочетете още →105WAF или ъпдейт: защо Ви трябват и двете
Web Application Firewall може да спира атаки, но не затваря уязвимост в интерпретатора на PHP. Кога WAF помага, докъде стига и как да комбинирате двете разумно.
Прочетете още →106Нова инсталация или почистване на сървъра? Решението след заразяване
След проникване има два пътя: да почистите сървъра или да го изградите наново. Кои критерии решават и защо редът е по-важен от избора.
Прочетете още →107Да отстраним сами или да ангажираме доставчик? Честна преценка
Не всяко положение със сигурността изисква външна помощ. С тези критерии и кратка самооценка решавате дали Вашият екип се справя с PHP2Shell сам или се нуждае от подкрепа.
Прочетете още →108Как да изберете доставчик на услуги по ИТ сигурност: 12 въпроса преди поръчката
Под натиск на времето е трудно да намерите добър доставчик на услуги по сигурност. Тези дванадесет въпроса помагат да сравните офертите обективно, без да се хванете на рекламни обещания.
Прочетете още →109Managed хостинг или собствен сървър? Сравнение по сигурност
PHP2Shell беше стрес тест за всеки модел на експлоатация. Сравнението показва кога Managed хостингът е по-сигурен, кога собственият сървър и кои смесени форми се доказват.
Прочетете още →110Ъпгрейд на PHP или backport? Решението за стари системи
За старите версии на PHP след PHP2Shell има няколко пътя: backport на дистрибуцията, трети източник, пач на изходния код, дългосрочна поддръжка или ъпгрейд. Какво струва всеки път и докога издържа.
Прочетете още →111Да сменим ли CMS след хака? Кога помага и кога не
След проникване доверието в CMS често изчезва. Но нова система рядко решава същинската причина. Кога смяната има смисъл и как да мине чисто.
Прочетете още →112Статични уебсайтове: по-малко PHP, по-малка повърхност за атака
Статичният уебсайт обслужва готови HTML файлове и не се нуждае от PHP на сървъра. Това намалява значително повърхността за атака, но носи свои граници и задължения.
Прочетете още →113Пентест, Bug Bounty или сканиране за уязвимости? Изборът на подходящ метод за проверка
Сканирането, тестът за проникване и Bug Bounty проверяват уебсайтовете по съвсем различен начин. Какво постига всеки метод, къде се проваля и какъв ред пасва на Вашата фирма.
Прочетете още →Всеки час има значение. Пишете ни сега.
Опишете накратко системата, версията на PHP и какво сте забелязали. Ние се свързваме с Вас, уточняваме ситуацията и работим отдалечено, докато инцидентът бъде приключен и документиран.