Як ми відмовились від сисадмінів: тепер сервери налаштовує Claude, а не дорога підтримка

Disclosure. У статті є партнерське посилання на Contabo. Якщо ви замовите сервер за ним, ми отримаємо невелику комісію – на ціну для вас це не впливає. Пишемо про Contabo не заради партнерки, а тому, що самі тримаємо там свій парк серверів. Історія нижче – справжня.

Коротко, для тих, хто поспішає

Кілька років ми переплачували за «спокій». Брали шаред-хостинги й VPS саме там, де була гарна технічна підтримка, – і це виливалося в чималі щомісячні бюджети. Але навіть за ці гроші проблеми з адмініструванням нікуди не дівалися: щось падало, щось треба було донастроювати, а по-справжньому складні речі підтримка не робила – «це поза нашою зоною відповідальності».

Переломним став злам одного з наших серверів. Тоді нам не зміг допомогти ніхто: адміни тягнули час, щось поробили, але толку не було. З відчаю я вирішив розібратися сам – підключив Claude (Claude Code) прямо в терміналі. І з того моменту все перевернулося: відколи я почав конфігурувати й налаштовувати сервери з Claude, проблеми з адмініструванням просто зникли. Найдивніше – я лише описував простими словами, що хочу отримати, а Claude технічно все налаштовував, попереджав про деталі й давав рекомендації. Лишилися самі плюси. Окремі системні адміністратори мені більше не потрібні.

Ця стаття – про те, як ми до цього дійшли.

Як було: платив за підтримку – і все одно мав проблеми

Логіка була проста й, здавалося, розумна: якщо ти не сисадмін, бери хостинг там, де за тебе все зроблять. Тож ми свідомо обирали дорожчі тарифи – шаред-хостинги з живою підтримкою, managed-VPS, де обіцяли «допоможемо з будь-чим». За це платиш помітну надбавку щомісяця, помножену на кількість проєктів. У сумі – суттєвий рядок витрат.

Проблема в тому, що це не рятувало. Підтримка чудово перезапускала сервіс чи відповідала на дрібне питання, але як тільки треба було щось нестандартне – міграція, конфіг nginx під конкретний кейс, розбір, чому сайт віддає 500, налаштування фаєрвола – починалося «це вже адміністрування вашого застосунку, ми цим не займаємось». Тобто ти платиш за підтримку, а реальне адміністрування все одно висить на тобі. І ти або платиш ще й окремому адміну, або живеш із напівробочими рішеннями.

Так тривало, поки удача не закінчилася.

День, коли нас зламали

Пізніше, відновивши хронологію з логів, ми побачили картину:

• 14 липня, 17:27 – хтось із чужого IP зайшов root по SSH. Одна невдала спроба – і успішний вхід. Пароль просто вгадали брутфорсом.
• 17:34–18:08 – за півгодини на сервер поставили повний набір: криптомайнер, rootkit для приховування процесів, викрадач паролів і механізми самовідновлення.

Найгірше з’ясувалося під час розбору: окремий SSH-бекдор-ключ додали ще 12 липня – за два дні до «гучної» атаки. І не тільки в root, а майже в усі акаунти з реальним shell-доступом. Зловмисник мав кілька незалежних входів.

Що конкретно жило на сервері (усе це ми потім вичистили):

• Криптомайнер, замаскований під системну бібліотеку libudev.so.6, з запуском через cron.hourly.
• Rootkit hide – щоб майнер не було видно в списку процесів.
• PAM-хук – викрадач паролів: логував кожну спробу входу (логін, пароль, IP) у прихований файл.
• Скрипт-«воскреситель» у cron.daily: після видалення майнера за годину перевстановлював його з прихованих копій і отруював .bashrc.
• Шість прихованих бекап-копій малвара по /boot, /srv, /mnt, /opt, /usr/lib під випадковими іменами.
• Каталоги .ssh із бекдор-ключами були захищені immutable-флагами (chattr +i), щоб їх не можна було просто видалити.

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

Адміни, які не допомогли

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

Адміни, до яких ми звернулися, тягнули час. Хтось узявся, щось поробив – частину малвара навіть прибрали (пізніше в логах було видно, що якісь файли видаляли, сервер кілька разів перезавантажували). Але толку не було: майнер повертався, чужі ключі лишалися, незрозуміла персистентність нікуди не поділася. Пояснити, що взагалі відбувається і чи чистий тепер сервер, ніхто не міг.

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

Як ми розгрібали це з Claude

Ключове рішення виявилося простим: не робити наосліп. Замість «загуглив команду – вставив – сподіваюся» ми з Claude пішли методично, з поясненням кожного кроку.

Найважливіше: я казав простими словами – Claude робив

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

Технічну частину брав на себе Claude:

• перекладав моє побажання в конкретні команди й пояснював, що кожна робить, перш ніж я її виконаю;
• попереджав про деталі й ризики, яких я б нізащо не врахував сам: «спершу дозволь SSH-порт, інакше замкнеш себе за межами сервера», «цей файл нульового розміру відновлюється – краще копнути глибше, ніж просто видалити», «ipset не переживе ребут – треба окремий сервіс, щоб правило не загубилось»;
• давав рекомендації, яких я навіть не питав: забанити рецидивістів через recidive, увімкнути автооновлення, зробити снапшот-страховку перед ризикованим кроком.

Розподіл був чіткий: на мені – рішення й здоровий глузд («так, роби», «ні, спершу бекап»), на Claude – техніка й уважність до дрібниць. Мені не треба було ставати інженером – треба було зрозуміло сформулювати задачу й перевіряти висновки.

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

1. Спочатку зрозуміти масштаб

Прогнали chkrootkit і rkhunter. Вони одразу підсвітили попередження про можливий rootkit рівня ядра й приховані каталоги .ssh. Claude пояснив, що означає кожне попередження і які з них – реальна загроза, а які хибне спрацювання. Це важливо: половина виводу таких утиліт – шум, і без розуміння ти або панікуєш даремно, або пропускаєш справжнє.

2. Зняти захист малвара й вичистити IOC

Далі по колу: знайти компонент, зрозуміти, як він тримається за систему, зняти chattr-флаги, видалити. Майнер, лоадер, rootkit hide, PAM-викрадач, скрипт-воскреситель, усі шість прихованих бекапів. Заражені .bash_profile/.profile/.bashrc – почистили, оригінали зберегли як докази. Окрема історія – бекдор-ключі: їх треба було витягти з усіх акаунтів, не зачепивши легітимні ключі команди. Коли кожен крок на очах, перед кожним видаленням видно, чий це ключ.

3. Момент, коли ми вирішили перевстановити сервер

Був один файл – нульового розміру, з SUID-бітом і chattr +i, – який продовжував відновлюватися навіть після того, як ми вичистили усе: malware, cron, systemd, PAM-хук, усі бекдор-ключі. Ми перевірили cron, systemd-таймери, incron, at, kernel-модулі, живий семплінг процесів щосекунди. Джерело так і не знайшли.

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

Головний урок: іноді правильна відповідь – не «долікувати», а «знести й поставити заново на чистий чеклист».

Чеклист хардненгу, який тепер у нас стандарт

Після переустановки ми накотили набір базового захисту. Тепер цей список застосовується до кожного нового VPS:

1. SSH – тільки по ключу. PermitRootLogin prohibit-password, PasswordAuthentication no. Парольний брутфорс root – той самий вектор, яким нас зламали, – після цього не працює.
2. UFW. Спершу дозволити 22/80/443 (щоб не замкнути себе), потім default deny incoming і enable.
3. fail2ban з jail’ами sshd і recidive (бан рецидивістів на тиждень).
4. Блок-лист blocklist.de через ipset – ~18 000 відомих зловмисних IP дропаються на вході, щоденне автооновлення через systemd-таймер.
5. Хмарний фаєрвол Contabo – окремий шар на рівні провайдера, ще до того, як трафік дійде до сервера. Default-deny, відкриваємо лише потрібне кожній ролі.
6. Автооновлення (unattended-upgrades) – критичні патчі ставляться самі.

Дрібні граблі, на які ми наступили (щоб ви не наступали):

• У before.rules для ufw правило -A має йти після оголошення ланцюга :chain - [0:0], інакше iptables-restore тихо падає, а ufw reload про це не сварить.
• ipset живе в пам’яті й не переживає ребут – потрібен окремий restore-сервіс, що піднімає набір до старту ufw.
• На Ubuntu 24.04 fail2ban пише в journal, і для recidive треба окремо вказати лог-файл.

Нічого космічного. Але зібране в один повторюваний чеклист – сервер перестає бути лотереєю.

Що змінилося: сисадміни більше не потрібні

Найбільша зміна навіть не технічна, а в голові: серверна частина перестала бути страшною. Ми більше не «власники сайтів, які бояться зайти в термінал». Ми перевіряємо, оновлюємо й закриваємо порти самі – з Claude як другим пілотом, який пояснює кожен крок і ловить помилки до того, як ти їх виконаєш.

Практичні наслідки:

• Той самий чеклист хардненгу ми розгорнули на весь парк – кожен новий сервер піднімається вже захищеним із першої хвилини.
• Через API Contabo тримаємо інвентар серверів, керуємо хмарними фаєрволами й робимо снапшоти скриптами, а не кліками.
• І головне з грошей: ми перестали платити за дорогий managed-хостинг і окрему підтримку, якої все одно бракувало. Задачі, що раніше вимагали або дорогого спеца, або managed-тарифу, тепер робляться за вечір – з розумінням, що саме й навіщо ти робиш.

Чи означає це, що Claude «замінив» системного адміна? Для нашого масштабу – по суті так: окремі сисадміни нам більше не потрібні. Поріг входу впав настільки, що адміністрування перестало бути окремою статтею витрат. За Claude усе одно варто перевіряти – і ми перевіряємо, особливо перед видаленням чогось на проді. Але це партнерство, а не безпорадність і не рахунок за годинну ставку.

Чому саме Contabo

Коли адмін і платна підтримка більше не потрібні, змінюється й вибір хостингу. Раніше ми переплачували за managed саме заради «допоможуть». Тепер допомагає Claude – і логічно брати дешевий, але потужний unmanaged-VPS, а не дорогий тариф із підтримкою, яку не використовуєш. Contabo сюди лягає ідеально:

• Ціна/потужність. За гроші, за які в «великих» хмарах береш крихітний інстанс, тут отримуєш VPS із нормальним CPU, кількома гігабайтами RAM і пристойним диском.
• Європейські дата-центри – важливо для латентності та GDPR.
• Хмарний фаєрвол на рівні провайдера – той самий додатковий шар захисту, безкоштовно в панелі.
• Повноцінний REST API – інвентар, снапшоти, фаєрволи, reinstall, приватні мережі, об’єктне сховище. Усе скриптується.
• Reinstall/rescue у пару кліків – те, що врятувало нас під час чистої переустановки.

Мінуси теж є: підтримка не миттєва, а панель без надмірностей. Але коли підтримка тобі не потрібна щодня, це якраз перестає бути мінусом – ти не платиш за те, чим не користуєшся.

👉 Подивитися тарифи Contabo VPS: contabo.com/vps

Висновок

Роками ми платили за «спокій» – managed-хостинг і підтримку – і все одно мали проблеми з адмініструванням. Розв’язала їх не дорожча підписка, а зв’язка дешевого гнучкого VPS + AI-помічник у терміналі. Не тому, що ми стали сисадмінами, а тому, що перестали робити наосліп – і перестали за це переплачувати.

Якщо ви теж тримаєте сайти на дорогому managed-тарифі «щоб було спокійно» – спробуйте інший шлях: недорогий VPS і базовий чеклист (SSH по ключу, fail2ban, фаєрвол). Уже одне це прибирає той вектор атаки, яким зайшли до нас, – і показує, скільки ви насправді переплачували.

---

FAQ

Чи справді можна обійтися без системного адміністратора? Для парку типових сайтів (nginx/PHP/MySQL, WordPress, Joomla тощо) – так. Рутинні задачі (налаштування, оновлення, фаєрвол, розбір помилок, бекапи) робляться в терміналі з AI-помічником, який пояснює кожен крок. Для рідкісних складних кейсів завжди можна разово залучити спеца – але це вже не щомісячний рядок витрат.

Скільки економиш, відмовившись від managed-хостингу? Залежить від парку, але різниця між managed-тарифом із підтримкою і unmanaged-VPS тієї ж потужності – часто кратна. Помножте надбавку на кількість проєктів і місяців – і побачите бюджет, який ішов за «спокій».

Чи безпечно давати AI доступ до продакшн-сервера? Ви не «даєте доступ» – ви працюєте в терміналі самі, а AI пропонує команди й пояснює їх. Кожну дію ви бачите й підтверджуєте. Правило просте: перед будь-яким видаленням чи зміною на проді – перечитати, що саме виконається.

Що робити прямо зараз, якщо підозрюю, що сервер зламали? Не перезавантажуйте наосліп (втратите частину слідів у пам’яті). Зробіть снапшот для доказів, проженіть chkrootkit/rkhunter, перевірте authorized_keys в усіх акаунтів і свіжі записи в cron/systemd. Якщо бачите незрозумілу персистентність – плануйте чисту переустановку з подальшим хардненгом.

Який мінімальний захист має бути на кожному VPS? SSH тільки по ключу, парольний вхід вимкнено, fail2ban, фаєрвол default-deny і автооновлення. П’ять пунктів, пів години роботи – і 99% автоматизованих атак вас уже не дістануть.

---

*Матеріал ґрунтується на реальному інциденті в нашій інфраструктурі (липень 2026). Технічні деталі, IP-адреси та доступи навмисно узагальнені з міркувань безпеки.*

Фото для статті: Gabriel Heinzer, Kevin Horvat і Domaintechnik на Unsplash, Paras Katwal на Pexels. Використані за безкоштовними ліцензіями Unsplash і Pexels.