Антивірус, який ламає ПК: іронія, що повторюється

Повторювана іронія: чому «безпека» стає простою відмовою в роботі

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

Коли він ламається — це голосно. Ви не бачите поступового погіршення; ви отримуєте цикли завантаження, сині екрани, «доступ заборонено» до системних бінарів, збірки, що тривають у 10× довше, і бази даних, які раптом поводяться так, ніби працюють з USB-накопичувача. Це тому, що інструменти захисту кінцевих точок проєктуються бути авторитетними. Вони можуть блокувати те, що ви намагаєтеся зробити, і робити це до того, як ваше програмне забезпечення отримає слово.

Повторюваний патерн не в тому, що «безпека погана». Патерн у тому, що ми поводимося з інструментами безпеки як з оновленням браузера: швидко пушимо скрізь, негайно, з мінімальною дисципліною — бо інструмент сам має зменшити ризик. Це помилково. Потрібно поводитися з інструментом як із оновленням ядра, бо фактично це воно і є.

Парафраз ідеї від John Allspaw: «Надійність походить від здатності вчитися й адаптуватися в реальних умовах.» Це стосується й агентів безпеки: розгортайте їх так, ніби вони можуть зазнати невдачі, тому що рано чи пізно це станеться.

Короткий жарт, бо він потрібен: антивірус — єдиний продукт, який може сказати «Я знайшов вірус» і мати на увазі «Сьогодні я і є вірус.»

Цікаві факти й історичний контекст (коротко, по суті)

• 1980-ті: Ранні «антивіруси» були переважно підбором сигнатур відомих інфекторів boot-sector і файлів; вони не були глибоко інтегровані в ядра, бо й ОСи такими не були.
• 1990-ті: Макровіруси (особливо через офісні документи) змістили виявлення в бік інспекції контенту та евристичного сканування, що збільшило навантаження на ЦП у робочих процесах з документами.
• Кінець 1990-х–2000-ті: Черви, що розповсюджувалися електронною поштою, змусили постачальників додати реальне сканування поштових сховищ і вкладень, часто викликаючи больове I/O-підсилення на PST/OST та подібних форматах.
• 2000-ті: Мініфільтри файлової системи Windows стали стандартним механізмом для сканування при доступі — потужні, але наближені до ядра й легкі для дестабілізації при помилках або неправильній конфігурації.
• 2010-ті: EDR розширився за межі просто виявлення шкідливого ПЗ до поведінкового моніторингу, захисту облікових даних і виявлення латерального переміщення — більше сенсорів, більше перехватів, більше точок відмови.
• Сучасні кінцеві точки: Багато агентів використовують хмарні підвантаження виявлень і часті оновлення правил. Це робить «оновлення сигнатур» ближчими до «оновлень політик» з реальним поведінковим впливом.
• Реальність продуктивності: Сканування при доступі може перетворити одну логічну операцію з файлом на кілька фізичних читань і записів, особливо при скануванні архівів і розпаковуванні контенту.
• Операційна реальність: Оновлення агента безпеки часто — це привілейований інсталятор, що оновлює драйвери/сервіси, іноді вимагає перезавантаження, іноді робить його автоматично.

Режими відмов: як антивірус ламає ПК на практиці

1) Цикли завантаження та сині екрани: взаємодія з ядром — гострий ніж

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

Типові тригери: оновлення, що додає новий драйвер; кумулятивний оновлення Windows, що змінює поведінку ядра; або перемикання флагу функції, яке розширює область моніторингу до коду, що ніколи не тестувався у вашому наборі обладнання/драйверів.

2) «Все повільно»: підсилення I/O і конфлікт за ресурси

Сканування при доступі часто означає: відкриття файлу → антивірус перехоплює → читає вміст → можливо розпаковує → сканує → дозволяє оригінальне читання. Помножте це на системи збірки (тисячі дрібних файлів), менеджери пакетів (безліч архівів) та робочі процеси розробника (node_modules, target/, bin/obj) — і ви отримали гріючий елемент, який маскується під ноутбук.

Сховище лише ускладнює ситуацію. Навантаження антивірусу — це «дрібні випадкові читання» плюс метадані. На обертових дисках це катастрофа; на SSD — швидша катастрофа. На мережевих дисках — катастрофа з затримкою.

3) Додатки ламаються: хибні спрацьовування та агресивне усунення

Сучасні інструменти не лише виявляють — вони усувають. Карантин, видалення, блокування виконання, блокування завантаження DLL, заборона відкриття дескрипторів. Якщо інструмент позначає легітимний бінарник (новий артефакт збірки, підписаний внутрішній інструмент, пакований інсталятор), «виправлення» перетворюється на продакшн-аутедж, тому що агент вирішив, що ваше ПЗ виглядає підозріло.

4) Мережеві дивності: TLS-інспекція й змішування пакетів

Деякі стеки кінцевих точок вставляються в мережу для веб-захисту, захисту від фішингу або TLS-інспекції. Якщо зроблено погано, ви отримуєте порушені ланцюжки сертифікатів, періодичні скиди підключень і різке падіння продуктивності для додатків з великим трафіком (CI ранери, кеші артефактів, завантаження контейнерів).

5) Шторм оновлень: політика, що миттєво розгортається

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

6) VDI і спільні машини: один хость — багато жертв

У VDI один хост запускає багато робочих столів. Якщо агент у кожній VM вирішує «почати повне сканування зараз», спільне сховище й CPU отримують відсіч. Якщо інструмент встановлено в золотому образі з поганими винятками, кожна клонована машина успадковує проблему миттєво.

7) Середовища розробників і SRE: сканери проти графів збірки

Інструменти збірки створюють тисячі тимчасових файлів. Менеджери пакетів пишуть кеші. Контейнери продукують шари. Антивірус бачить це як оргію підозрілої активності. Ви бачите: «чому мій тестовий набір став з 8 хвилин на 45?»

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

План швидкої діагностики (що перевіряти першим/другим/третім)

Це цикл «перестаньте гадати». Ви намагаєтеся відповісти на одне питання: Чи є агент безпеки вузьким місцем, і якщо так — який підсистему він душить?

Перший: підтвердьте охоплення та час початку (зона ураження)

• Це одна машина, відділ чи всі користувачі?
• Почалося одразу після оновлення агента, оновлення політики чи оновлення ОС?
• Чи корелює це з перезавантаженнями, входами в систему або мережевими змінами?

Рішення: Якщо зона ураження широка і початок синхронізований, розглядайте це як інцидент розгортання/політики, а не «ПК просто старі». Заморозьте зміни й почніть ізутримання.

Другий: визначте обмежений ресурс (CPU, диск, пам’ять, мережа)

• Високий CPU у процесах безпеки? Скоріше за все, сканування, поведінковий аналіз або безконтрольна телеметрія.
• Висока активність диска / черга? Ймовірно сканування при доступі або інтенсивна робота з карантином.
• Мережеві аномалії? Може бути модуль веб-захисту, проксирування, TLS-інспекція або петлі отримання правил з хмари.
• Збої при завантаженні/BSOD? Проблема на рівні драйвера, часто пов’язана з оновленням.

Рішення: Виберіть найшвидший інструмент вимірювання на ураженій ОС і доведіть вузьке місце до того, як змінювати налаштування.

Третій: доведіть причинно-наслідковий зв’язок (відключити vs виняток vs відкат)

• Чи можете ви відтворити уповільнення, торкнувшись відомого «гарячого шляху» (наприклад, збірка репозиторію, розпакування архіву)?
• Чи зникне проблема в Безпечному режимі (де багато сторонніх драйверів/сервісів відключені)?
• Чи зменшує навантаження цілеспрямований виняток без повного відключення захисту?

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

Практичні завдання: команди, вихідні дані та рішення (12+)

Це практичні завдання, які ви можете виконати на Linux-робочій станції/сервері або на Windows-ендонті, використовуючи оболонку (WSL, Git Bash або віддалені інструменти). Команди реалістичні; сенс — робочий процес: запустити → інтерпретувати → вирішити.

Завдання 1: Знайдіть найбільших споживачів CPU (чи саме сканер спалює цикли?)

cr0x@server:~$ ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 8
  PID  PPID CMD                         %CPU %MEM
 2143     1 /opt/edr/agentd              186.3  2.1
 2210  2143 /opt/edr/scanner --realtime   94.2  1.4
 1055     1 /usr/lib/systemd/systemd      1.2  0.1
 1899     1 /usr/sbin/sshd               0.3  0.2

Що це означає: Агент і сканер домінують у використанні CPU. Якщо це співпадає зі скаргами користувачів — це не «лише сприйняття».

Рішення: Перейдіть до перевірок диска і файлової активності; якщо CPU завантажений при мізерному I/O — підозрюйте петлю поведінкового двигуна або потік телеметрії.

Завдання 2: Виявлення тиску на диск (чи прив’язка до I/O?)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.50    0.00    9.20   38.10    0.00   40.20

Device            r/s     w/s   rkB/s   wkB/s  await  aqu-sz  %util
nvme0n1         320.0   210.0  8200.0  6400.0  18.40    6.20  98.70

Що це означає: iowait високий; використання пристрою ~99%. Система чекає дані зі сховища.

Рішення: Визначте процес, що створює I/O (ймовірно сканер). Розгляньте винятки для гарячих директорій і обмеження повних сканувань.

Завдання 3: Визначте порушника I/O (який PID б’є по диску?)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 45.12 M/s | Total DISK WRITE: 12.34 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO>    COMMAND
 2210 be/4   root     42.10 M/s   0.00 B/s    0.00 %  92.00 %  /opt/edr/scanner --realtime
 2143 be/4   root      2.20 M/s   9.80 M/s    0.00 %  18.00 %  /opt/edr/agentd

Що це означає: Сканер насичує операції читання. Таке часто трапляється, коли він перескановує кеші або артефакти збірки.

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

Завдання 4: Побачити, які файли торкається сканер (гарячі шляхи)

cr0x@server:~$ sudo lsof -p 2210 | head -n 12
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
scanner  2210 root  cwd    DIR  259,1     4096  1310730 /home/dev/build
scanner  2210 root   12r   REG  259,1  5242880  1311102 /home/dev/build/node_modules/.cache/tmp.bin
scanner  2210 root   13r   REG  259,1   912384  1311120 /home/dev/build/target/classes/app.jar

Що це означає: Він «осідає» в виходах збірки й кешах залежностей.

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

Завдання 5: Виявлення шторму змін файлів (чи перескановує файлову систему через високу турбулентність?)

cr0x@server:~$ inotifywatch -t 10 -r /home/dev/build
Establishing watches...
Finished establishing watches, now collecting statistics.
total  184532
create  61210
delete  60210
modify  48200
close_write  14912

Що це означає: Масивна турбулентність; сканери в реальному часі можуть стати самостійним DoS у такому випадку.

Рішення: Для дерев збірки обирайте режими «сканувати при закритті» або «сканувати при виконанні», або виключіть директорію і скануйте артефакти в CI.

Завдання 6: Перевірка тиску пам’яті (чи відбувається підміняння через роздутий агент?)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       1.1Gi       312Mi       2.0Gi       1.6Gi
Swap:          8.0Gi       5.2Gi       2.8Gi

Що це означає: Система глибоко в swap. Навіть «малий» стрибок CPU стає катастрофічним, коли все підміняється.

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

Завдання 7: Знайти процеси з найбільшим обсягом пам’яті (перевірка RSS)

cr0x@server:~$ ps -eo pid,cmd,rss --sort=-rss | head -n 6
  PID CMD                           RSS
 2143 /opt/edr/agentd            1824300
 2210 /opt/edr/scanner --realtime 943200
 3321 /usr/lib/firefox/firefox    612400

Що це означає: Агент — один із топових споживачів пам’яті. Деякі інструменти агресивно кешують сигнатури/моделі; іноді це витік.

Рішення: Якщо зростання пам’яті невпинне, плануйте відкат або ескалацію до вендора з доказами (тренд RSS).

Завдання 8: Перевірка здоров’я сервісу і нещодавніх перезапусків (зациклення аварій — підказка)

cr0x@server:~$ systemctl status edr-agent --no-pager
● edr-agent.service - Endpoint Detection and Response Agent
     Loaded: loaded (/etc/systemd/system/edr-agent.service; enabled)
     Active: active (running) since Wed 2026-01-22 09:11:02 UTC; 3min ago
   Main PID: 2143 (agentd)
     Tasks: 48 (limit: 38241)
     Memory: 1.8G
     CGroup: /system.slice/edr-agent.service
             ├─2143 /opt/edr/agentd
             └─2210 /opt/edr/scanner --realtime

Що це означає: Сервіс зараз запущений, але статус сам по собі не покаже флапінг.

Рішення: Перегляньте журнал на предмет нещодавніх крашів/перезапусків і корелюйте з повідомленнями користувачів.

Завдання 9: Прочитати логи навколо вікна інциденту (з’ясувати зміну політики/двигуна)

cr0x@server:~$ sudo journalctl -u edr-agent --since "2026-01-22 08:30" --no-pager | tail -n 12
Jan 22 08:58:10 server agentd[2143]: policy update received: profile=Workstations-Strict
Jan 22 08:58:11 server agentd[2143]: enabling feature: archive_deep_scan=true
Jan 22 08:58:12 server scanner[2210]: started full content scan: reason=policy_change
Jan 22 08:58:13 server scanner[2210]: warning: scan queue length=8421
Jan 22 08:58:20 server agentd[2143]: telemetry backlog increasing: 1200 events/sec

Що це означає: Це не таємниця. Оновлення політики ввімкнуло глибоке сканування архівів і спричинило повні сканування.

Рішення: Відкатайте політику або звузьте її; додайте запобіжники, щоб зміни політик не запускали повні сканування по всьому флоту.

Завдання 10: Перевірити мережеву активність (чи ми обрушуємо хмарні кінцеві точки?)

cr0x@server:~$ ss -tpn | head -n 12
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
ESTAB  0      0      10.0.3.14:51944    52.85.12.33:443  users:(("agentd",pid=2143,fd=28))
ESTAB  0      0      10.0.3.14:51946    52.85.12.33:443  users:(("agentd",pid=2143,fd=29))
ESTAB  0      0      10.0.3.14:51948    52.85.12.33:443  users:(("agentd",pid=2143,fd=30))

Що це означає: Кілька постійних TLS-сесій. Нормально — якщо тільки кількість не вибухає і трафік не насичує канали.

Рішення: Якщо кінцеві точки повільні лише при «онлайн»-режимі, тимчасово ізолюйте машину в лабораторній VLAN, щоб перевірити, чи хмарні запити не блокують виконання.

Завдання 11: Підтвердити тротлінг CPU / проблеми з охолодженням (іноді агент лише тригер)

cr0x@server:~$ cat /proc/cpuinfo | grep -E "model name|cpu MHz" | head -n 6
model name	: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
cpu MHz		: 799.932
model name	: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
cpu MHz		: 800.021

Що це означає: CPU працює близько 800 MHz — ймовірно, термальне/енергетичне тротлінгування. Навантаження агента може штовхнути систему охолодження понад межі.

Рішення: Виправте профіль живлення/термальний профіль (BIOS, політика ОС) і все одно налаштуйте сканування. Не варто звинувачувати «антивірус» за ноутбук, що не справляється з охолодженням.

Завдання 12: Виміряти затримку файлової операції (до/після винятків)

cr0x@server:~$ time find /home/dev/build -type f -maxdepth 4 -print0 | xargs -0 sha256sum >/dev/null
real	0m42.118s
user	0m8.901s
sys	0m31.772s

Що це означає: Високий sys-час вказує на накладні витрати ядра/файлового вводу-виводу — класично для сканування при доступі.

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

Завдання 13: Переглянути завантажені фільтри файлової системи (Windows-аспект, але концептуально важливо)

cr0x@server:~$ fltmc
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
WdFilter                                 10       328010         0
edrFilter                                 8       321200         0
luafv                                    1       135000         0

Що це означає: Кілька фільтрів накладаються. Altitude вказує порядок; взаємодії мають значення. Два продукти, що сканують одночасно, можуть подвоїти роботу або викликати дедлоки в крайових випадках.

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

Завдання 14: Швидко перевірити стан Windows Defender (поширено в змішаних EDR-наборах)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select AMServiceEnabled,AntispywareEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled"
AMServiceEnabled AntispywareEnabled RealTimeProtectionEnabled IoavProtectionEnabled
---------------- ----------------- ------------------------- ---------------------
            True              True                      True                  True

Що це означає: Defender у режимі реального часу. Якщо у вас також є сторонній EDR із скануванням при доступі, ви можете мати подвійне сканування.

Рішення: Визначте, який продукт є авторитетним для реального часу; інший поставте в пасивний режим за можливості і підтвердьте це політикою.

Завдання 15: Перевірити нещодавні bugcheck-и Windows (докази BSOD)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 3 | Format-Table TimeCreated,Message -Auto"
TimeCreated           Message
-----------           -------
1/22/2026 8:14:02 AM  The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e ...
1/22/2026 8:01:44 AM  The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e ...

Що це означає: Повторні bugcheck-и. Якщо час збігається з оновленням агента/зміною політики, у вас є сильна підказка.

Рішення: Збережіть дампи аварій, зупиніть розгортання і координуйте відкат/гаряче виправлення з вендором. Не «перевстановлюйте і забувайте», поки не локалізували ризик по флоту.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через хибне припущення

У компанії було два інструменти кінцевої точки: сторонній EDR і Windows Defender. Команда безпеки вважала, що Defender автоматично перейде в пасивний режим при встановленні стороннього агента. Вони бачили таку поведінку в деяких середовищах, і це стало «як працює Windows» у їхніх головах.

Потім прийшло оновлення Windows, і Defender знову увімкнувся в режимі реального часу на підмножині машин. Ніхто цього не помітив одразу, бо нічого «очевидно не зламалося». Замість цього трапилася повільна смерть: входи в систему почали займати більше часу, Outlook періодично зависав, а збірки на ноутбуках розробників почали таймаути при розпаковуванні залежностей.

SRE були підключені, бо «репозиторій артефактів став повільним». Насправді — ні. Кінцеві точки двічі сканували кожен скачаний архів, і один зі сканерів мав увімкнене глибоке сканування архівів. Команда зі сховищ побачила сплеск SMB-операцій метаданих і звинуватила файловий сервер; мережна команда побачила більше TLS до хмарних кінцевих точок безпеки і звинуватила «переповнення інтернету». Класична перекладач-звинувач.

Виправлення було нудним: явно виставити Defender у пасивний режим через політику на машинах, де сторонній EDR забезпечує реальний час, і постійно це перевіряти. Урок був гострим: ніколи не покладайтесь на «автоматичну сумісність» між продуктами безпеки. Якщо ви не можете описати станну машину, ви її не контролюєте.

Міні-історія 2: Оптимізація, що обернулася проти

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

Розробники запускали непідписані внутрішні інструменти, постійно збирали бінарники і виконували з директорій виходу збірки. Нова політика змусила кожний новий артефакт збірки вважатися підозрілим і відправлятися на перевірку репутації. Деякі перевірки займали секунди. Інші — хвилини, коли хмарний кінцевий пункт відповідав повільно або коли агент вирішував завантажити більше контексту.

Раптом «make test» перестав бути командою; це стало ретритом для медитації. Люди почали копіювати виходи збірки в дивні директорії, щоб «уникнути сканування», що зробило ще гірше: створило більше невідомих бінарників у різних місцях, збільшивши поверхню сканування. Оптимізація породила тіньові IT-обхідні практики всередині компанії.

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

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Одна організація справді ставилася до свого EDR як до критичної інфраструктури. У них були кільця: тест IT, невелика пілотна група в кожному бізнес-підрозділі, потім поетапне розгортання до інших. Також був процес «kill switch»: заздалегідь погоджений спосіб призупинити розгортання і повернути політики без тижня нарад.

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

Оскільки розгортання було поетапним, постраждало лише тестове кільце. Ніяких «чому у компанії пожежа» дзвінків від керівництва. Команда безпеки попрацювала з вендором, отримала оновлену конфігурацію й налаштувала винятки для відомих гарячих кешів.

Практика була нудною: канарне кільце, бенчмарк і план відкату. Це запобігло масовому відключенню. Ось у чому сенс нудних операцій — вони дають сон, а не заголовки.

Поширені помилки: симптом → корінна причина → виправлення

Симптом: ПК «повільний», диск на 100%, вентилятори ревуть

Корінна причина: Сканування в реальному часі високотурбулентних директорій (виходи збірки, кеші залежностей, профілі VDI), часто в поєднанні з глибоким скануванням архівів.

Виправлення: Додайте цілеспрямовані винятки для ефемерних директорій; змініть режим сканування на «сканувати при виконанні/закритті»; плануйте повні сканування в неробочий час з рандомізованими стартами. Перевірте вимірювання I/O до/після.

Симптом: випадкові збої додатків («access denied», помилки завантаження DLL)

Корінна причина: Поведінкове блокування або хибні спрацьовування, карантин новостворених/оновлених бінарників; іноді Controlled Folder Access або правила захисту від програм-вимагачів застосовано неправильно.

Виправлення: Створіть правила дозволу для підписаних внутрішніх бінарників; впровадьте підписування коду; налаштуйте правила для машин розробників; збирайте логи агента і хеші для ескалації до вендора.

Симптом: Цикл завантаження або BSOD відразу після оновлення агента

Корінна причина: Багатий драйвер ядра/мініфільтра, несумісність з нещодавнім патчем ОС або невдала інсталяція драйвера, що залишила систему в неконсистентному стані.

Виправлення: Негайно зупиніть розгортання. Скористайтеся Безпечним режимом/відновленням, щоб відключити драйвер/сервіс, відкотіть до останньої робочої версії агента, збережіть дампи аварій і координуйте виправлення з вендором.

Симптом: Мережа здається ненадійною; сертифікати виглядають «неправильними»

Корінна причина: Модуль веб-захисту діє як локальний проксі або TLS-інспекція, що вставляє кореневий CA; конфлікти з VPN, корпоративним проксі або додатками зі строгим pinning сертифікатів.

Виправлення: Вимкніть TLS-інспекцію для уражених додатків/доменів; переконайтеся, що розгортання кореневого CA виконане коректно; перевірте сумісність proxy/VPN в пілотному кільці.

Симптом: CI ранери або агенти збірки раптом сповільнились

Корінна причина: EDR встановлено з дефолтними робочими станціями; сканує робочі простори і кеші залежностей; агресивно сканує шари контейнерів.

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

Симптом: Стрибки CPU одночасно на багатьох машинах

Корінна причина: Push політики, що тригерять повні сканування або перехешування; оновлення сигнатур/правил, що викликає пересканування; скидання телеметричного беклогу.

Виправлення: Використовуйте кільця та обмеження швидкості; вимкніть «перевіряти одразу після зміни політики»; рандомізуйте початки сканувань; обмежуйте CPU; моніторте відповідність оновлень по флоту відносно продуктивності.

Симптом: Постраждав один користувач; інші в порядку

Корінна причина: Локальна корупція, часткове оновлення, конфлікт стороннього ПЗ або специфічне робоче навантаження (великий поштовий архів, масивний репозиторій, зашифрований контейнер).

Виправлення: Порівняйте версії агента/політик; повторно застосуйте політику; перевстановіть агент чисто; зберіть метрики до/після; не «флот-чиніть» one-off без доказів.

Чеклісти / покроковий план

Чекліст утримання (коли кінцеві точки активно ламаються)

1. Заморозьте розгортання: зупиніть нові інсталяції агентів і призупиніть поширення політик у центральній консолі.
2. Визначте кільця: з’ясуйте, який когорт отримав зміну (пілот проти широкого розгортання). Якщо кілець немає — створіть їх зараз: згрупуйте «вже оновлені» vs «ще не оновлені».
3. Зберіть докази: зберіть логи, версії й мітки часу з 3–5 уражених машин і 1 контролю.
4. Вирішіть обсяг відкату: відкотіть політику першочергово, якщо можливо; відкотіть версію агента, якщо підозрюєте проблеми на рівні драйвера.
5. Чітко комунікуйте: повідомлення для користувачів: що зламалося, обхідні шляхи, орієнтовний час і що не робити (наприклад, не встановлювати випадкові «чистильники»).
6. Захист безпеки: якщо ви мусите тимчасово зменшити захист, компенсуйте це (обмежте мережевий доступ, блокуйте ризикові завантаження, посильте контроль електронної пошти) до стабілізації.

Чекліст стабільності за замовчуванням (як припинити повторення)

1. Розгортання кільцями: тест → пілот → staged. Нехай агент слідує тій самій процедурі зміни, що й оновлення ОС.
2. SLO продуктивності для кінцевих точок: визначте вимірювані бюджети (наклад CPU, затримка диска, зростання часу збірки) і відхиляйте зміни, що їх порушують.
3. Політики з урахуванням робочого навантаження: розділіть політики для розробників, VDI, серверів і CI раннерів. Одна політика для всіх — шлях до універсального болю.
4. Винятки з дисципліною: виключайте ефемерні директорії і кеші; не виключайте цілі диски; переглядайте винятки щоквартально.
5. Контроль подвійного сканування: забезпечте, щоб лише один продукт робив сканування в реальному часі; інші — у пасивному/телеметричному режимі.
6. Охорона оновлень: уникайте «повного сканування одразу після зміни політики» по флоту; рандомізуйте розклади сканувань.
7. Збереження дампів і логів: зберігайте те, що потрібно для доведення багу драйвера; інакше кожен інцидент перетвориться на забобон.
8. Пакет ескалації до вендора: стандартний набір: логи агента, збірка ОС, дампи аварій, кроки відтворення і хронологія подій.

Налаштування кінцевих точок з урахуванням сховища (бо диски тихо страждають)

1. Не скануйте те, що можна відновити: виходи збірки, кеші залежностей і тимчасові директорії зазвичай безпечні для виключення.
2. Скануйте на межах: скануйте завантаження, вкладення електронної пошти та артефакти при публікації — місця, де контент входить або стає довготривалим.
3. Уникайте глибокого сканування архівів за замовчуванням: вмикайте його вибірково там, де ризик реальний (шлюзи пошти, папки завантажень), а не скрізь.
4. VDI: координуйте сканування: розбивайте час старту та обмежуйте ресурси; інакше ваше спільне сховище постраждає.

Питання й відповіді

1) Чи «антивірус» — це те саме, що EDR?

Ні. Традиційний антивірус орієнтується на виявлення шкідливого ПЗ (сигнатури/евристика). EDR додає поведінковий моніторинг, телеметрію й дії реагування. Багато продуктів зараз роблять і те, й інше, тому вони можуть і врятувати, і нашкодити.

2) Чому антивірус так сильно уповільнює збірки?

Збірки створюють і торкаються величезної кількості дрібних файлів. Сканування в реальному часі може перевіряти кожне відкриття/запис/закриття, помножуючи I/O. Додайте сканування архівів — і ви скануєте стиснені залежності багаторазово.

3) Чи небезпечні винятки?

Деякі — так. Виключення «C:\» — це капітуляція. Виключення ефемерних, відновлюваних директорій (наприклад, вихід збірки і кеші) зазвичай безпечні, якщо йдеться про сканування на вході (завантаження) і при публікації артефактів.

4) Чи варто запускати два антивіруси для «глибокого захисту»?

Не як два сканери в реальному часі. Це «захист на рівні диска». Якщо потрібні два інструменти, один має бути в пасивному/моніторинговому режимі, і це потрібно регулярно перевіряти.

5) Як довести, що агент безпеки — причина, не відключаючи його?

Виміряйте відтворюване робоче навантаження (хеш дерева директорій, збірка репозиторію, розпакування набору залежностей), потім застосуйте вузький виняток і запустіть ще раз. Якщо дельта велика, ви встановили причинність з мінімальним ризиком.

6) Який найшвидший індикатор проблеми політики по флоту?

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

7) Чому після оновлень безпеки трапляються BSODи?

Тому що інструменти кінцевих точок часто постачаються з драйверами або фільтрами. Баг або несумісність на цьому шарі може викликати краш ОС. Шлях виправлення так само операційний (зупинити розгортання, відкотити, зібрати дампи), як і технічний.

8) Що мають отримувати машини розробників, чого не потребують бухгалтерські машини?

Різні політики. Розробникам потрібні винятки для кешів збірки і продуманий підхід до «невідомих виконуваних файлів» (ідеально — підписування коду). Бухгалтерські машини можуть терпіти жорсткіший контроль виконання і агресивніше сканування.

9) Чи вирішать болі антивірусу лише поліпшення сховища?

Швидші SSD зменшать симптом, але не причину. Сканування при доступі може все одно насичувати швидкі диски і спалювати CPU. Налаштуйте модель сканування; не плекайте ілюзію, що «купити швидший диск» — це повне рішення.

10) Який найкращий операційний контроль?

Поетапні розгортання з кнопкою відкату. Більшість антивірусних катастроф трапляються, коли «усі отримали оновлення одночасно». Не робіть так.

Висновок: наступні кроки для зменшення інцидентів

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

Зробіть наступне:

1. Встановіть кільця для змін агента й політик безпеки (тест/пілот/поетапно).
2. Визначте три бенчмарки кінцевих точок (час входу, час збірки/розпакування і тест хешування файлів) і запускайте їх після кожної зміни.
3. Розділіть політики для розробників, VDI, серверів і CI раннерів.
4. Аудит подвійного сканування і забезпечте пасивний режим, де потрібно.
5. Створіть стандартний пакет інциденту (логи, версії, мітки часу, дампи аварій), щоб наступний збій став швидкою діагностикою, а не легендою.

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