EOL софтуер в публична среда: как една отложена миграция стигна до компрометиран сървър

Защо разказваме този случай

Повечето инциденти в ИТ инфраструктурата не се случват внезапно. Те се натрупват тихо — с всяко отложено решение, с всеки пропуснат ъпгрейд, с всяко „ще го направим следващото тримесечие".

Случаят по-долу проследява точно такова натрупване: от първия оглед преди няколко години до обаждането, че сървърът е спрял. Разказваме го анонимизирано, защото поуките важат за всяка организация, която в момента разчита на софтуер извън поддръжка.

Как започна

Преди няколко години към нас се обърна служител на средно голяма фирма — общ познат му беше дал контактите ни. Заявката беше на пръв поглед ясна:

• ъпгрейд на много остаряла инсталация на Zimbra;
• проблем с доставянето на изходяща поща;
• диагностика и оптимизация на файловия сървър.

Уговорката беше стандартната за нас: първо предварителен оглед и анализ на средата, чак след това разговор за обхват, срокове и бюджет. Не даваме оферта за нещо, което още не сме видели.

Какво заварихме

Огледът показа среда, в която всеки отделен компонент носеше самостоятелен риск:

• „Сървърът" беше десктоп машина в офиса, без UPS, на стандартна бизнес интернет услуга — негарантирана, със статичен публичен адрес.
• Публичният IP адрес фигурираше в няколко RBL (Realtime Blackhole List) списъка. Не само той — засегнат беше целият подмрежов диапазон на доставчика.
• Операционната система беше силно остаряла Linux дистрибуция, отдавна извън поддръжка (EOL).
• RAID1 масивът работеше в degraded режим — единият диск се беше предал някъде назад през годините.
• Регулярен backup нямаше.
• Zimbra сървърът беше много стара версия, също EOL.
• Файловият сървър се оказа просто SAMBA услуга, инсталирана на същата машина.

Тоест: една физическа машина без резервно захранване, с един работещ диск и без архив, обслужваше едновременно пощата и файловете на цялата организация — и беше пряко изложена в интернет.

Какво препоръчахме

Разговорът след анализа беше директен: това е недопустимо голям риск за организацията. Препоръките бяха три:

1. Сървър: незабавен backup на външен носител и възстановяване на RAID масива.
2. Пощенски сървър: миграция към външен хостинг, а още по-добре — към Microsoft 365 Exchange Online.
3. Файлов сървър: изваждане от пряка експозиция и поставяне зад защитна стена.

Какво прие клиентът

• Backup + възстановяване на RAID — Прието
• Миграция на пощата към 365 или външен хостинг — Отказано (български споделен хостинг отпадна по съображения за сигурност, а 365 се стори скъпо решение)
• Файлов сървър зад защитна стена — Прието

Две от трите препоръки бяха приети. Отказана беше именно тази, която адресираше корена на проблема.

Компромисът

Проблемът с RBL списъците беше сериозен. При негарантирана услуга в мрежата на доставчика има компрометирани машини, които генерират спам, и репутацията на целия диапазон страда — независимо колко коректен е конкретният подател.

При липса на бюджет за трайно решение стигнахме до работещ компромис: изнесохме Zimbra сървъра на VPS хостинг с чист IP адрес. Това реши проблема с изпращането и с приемането на пощата от отсрещната страна.

Оставаше ъпгрейдът на Zimbra, който клиентът беше поискал още в началото. Проблемът беше, че последната възможна безплатна версия също беше излязла от поддръжка — тоест дори „най-новото" достъпно за тях означаваше софтуер, който вече не получава корекции за сигурност. Обяснихме риска и всички съображения. Вариантите за трайно решение отново бяха отхвърлени.

Направихме миграцията към последната възможна версия, изведохме файловия сървър от пряка експозиция и заявихме изрично, че не можем да носим отговорност за система извън поддръжка. Администрацията ѝ остана на клиента.

Обаждането

Всичко работеше — до деня, в който ни се обадиха, че сървърът е спрял и дали можем да помогнем.

Няколко седмици по-рано бях попаднал на публикация за сериозен exploit за Zimbra. Тогава имах други ангажименти и не му обърнах особено внимание — сървърът не беше в наша поддръжка. В ретроспекция това е първата брънка от веригата.

Диагностиката

На първо четене всичко изглеждаше в ред: чисти access логове, достатъчно свободен ресурс. След по-задълбочен преглед забелязах, че услугите на самата Zimbra се рестартират циклично.

Първата стъпка беше рестарт на VPS-а. Системата тръгна, всичко изглеждаше нормално и за момент и ние, и клиентът си отдъхнахме. Двайсет минути по-късно спря отново.

Следващата стъпка беше връщане на вчерашния backup. Същите симптоми.

Точно тук стана ясно, че проблемът е от съвсем друг мащаб: машината беше компрометирана. Използван беше същият exploit, за когото бях чел седмици по-рано — CVE-2026-73570, през SNMP модула.

Това обяснява и защо вчерашният архив не помогна: компрометирането беше отпреди него.

За уязвимостта

CVE-2026-73570 е командна инжекция (OS command injection) в обработката на SNMP notifications на Zimbra Collaboration, с оценка CVSS 8.9. Специално подготвени SMTP заявки позволяват на неавтентикиран атакуващ да изпълни команди на операционната система с правата на потребителя zimbra. Засегнати са версиите преди 10.1.20, при които е инсталиран пакетът zimbra-snmp и са включени SNMP известията — конфигурация, която в уязвимите версии е активна по подразбиране.

Хронология:

• Публично обявяване на уязвимостта, с временна мярка за смекчаване — 26 юни 2026
• Излиза поправката — ZCS 10.1.20 — 20 юли 2026
• CERT Polska съобщава за активна експлоатация в реални условия — 17 август 2026
• CISA добавя уязвимостта в каталога KEV с тридневен срок за федералните агенции — 21 август 2026
• Shadowserver отчита стотици компрометирани инстанции и над 8200 непоправени сървъра — 20–25 август 2026

Ето и същината на целия този случай: поправка съществуваше. Тя излезе на 20 юли във версия 10.1.20. Само че клиентската инсталация беше EOL — за нея такава версия няма и няма да има. Точно това означава на практика „софтуер извън поддръжка": не просто по-стар, а изключен от механизма, по който светът се защитава.

Възстановяването

Тук се отплати една решена преди години подробност — разумната политика за backup с по-дълъг период на съхранение. Имаше по-стари копия и сред тях намерих некомпрометиран архив.

След като проучихме как да защитим машината, възстанових системата от здравия архив, премахнах уязвимия модул и спрях допълнителни некритични функции, свързани с него.

Оставаше обаче най-неприятното: между здравия архив и днешния ден зееше дупка от две седмици кореспонденция.

Решението беше да вдигна компрометирания сървър в контролирана, изолирана среда, да проуча как да извлека точно тези съобщения и да ги експортирам. След това ги приложихме към пощенските кутии на потребителите. Кореспонденцията беше възстановена.

От първото обаждане до окончателната развръзка минаха няколко дни, с по няколко часа съсредоточена работа дневно. През цялото това време организацията работеше с ненадеждна поща.

Какво беше изложено

Щетите вървяха по две линии едновременно.

Първата беше видима: пощенската услуга отпадна и организацията остана без основния си канал за комуникация — с клиенти, с доставчици, помежду си.

Втората беше по-тиха и по-сериозна. Уязвимостта дава изпълнение на команди с правата на потребителя zimbra — тоест същият потребител, който има достъп до пощенските кутии. За целия период между компрометирането и откриването атакуващият е разполагал с този достъп.

Няма индикации за изнасяне на данни. Но при инцидент от този тип липсата на индикации не е доказателство за липса на достъп. Затова и правилният подход е „приемаме, че е компрометирано": преглед за следи и създадени файлове, смяна на пароли и трезва оценка какво е било достъпно през този период. Че не последва изтичане на данни или изнудване е добър изход — не заслуга на конфигурацията.

Какво остава

Клиентът е доволен от резултата. Но нека сме честни за това какво всъщност се случи: за пореден път направихме кръпка и отложихме неизбежното.

Разликата е, че този път вариантът за миграция към 365 се обсъжда сериозно. Надеждната и защитена пощенска услуга не е лукс — тя е основна инфраструктура за всеки бизнес.

Изводите

1. EOL не значи „по-стар". Значи „изключен от механизма за защита".

За поддържаните версии поправката излезе за по-малко от месец. За EOL версия такава просто няма. Всяка публикувана уязвимост се превръща в постоянно отворена врата — и то документирана, с публично достъпно описание как се използва.

2. Прозорецът между обявяването и масовата атака се мери в седмици, не в тримесечия.

От публичното обявяване до потвърдена експлоатация в реални условия минаха около седем седмици, а компрометираните сървъри бяха стотици в рамките на дни. Автоматизираното сканиране е непрекъснато и не подбира по големина на фирмата.

3. Backup без retention е половин backup.

Вчерашният архив беше безполезен, защото вече съдържаше компрометирана система. Спасението дойде от по-старите копия. Ако пазите само последните няколко дни, при бавно развиващ се инцидент ще архивирате проблема, не решението.

4. Изключвайте функционалност, която не използвате.

Уязвимият модул не беше нужен за работата на организацията. Всяка активна услуга е част от атакуваната повърхност — независимо дали някой я ползва.

5. Отлагането не е спестяване, а разсрочване на разход с лихва.

Сметката за този инцидент: няколко дни календарно време, по няколко часа специализиран труд дневно, диагностика на компрометирана система, възстановяване от архив, обезопасяване, вдигане на втора машина в изолирана среда и ръчно извличане на две седмици кореспонденция. Плюс дните, в които бизнесът работеше с ненадеждна поща. Сравнете това с годишната цена на един абонамент — сметката се прави за минута.

6. Пробив в пощенския сървър е пробив в цялата кореспонденция.

Отпадането на услугата е неудобство, което се вижда веднага и се решава. Достъпът до съдържанието е щета, която може да не се прояви никога — или да се прояви след месеци, под формата на убедителен опит за измама, подготвен с реални данни от вътрешна кореспонденция.

7. Границите на отговорността трябва да са заявени предварително.

Когато клиент откаже препоръка, разговорът не приключва — той се документира. Това не пречи да вдигнете телефона, когато потрябва.

Ако това ви звучи познато

Ако разчитате на система, за която не сте сигурни дали още получава актуализации за сигурност, започнете с най-евтината възможна стъпка: преглед на средата. Той не задължава с нищо, но премахва най-скъпото в ИТ — изненадата.

Свържете се с нас за преглед на инфраструктурата →