Файрвол, який ви забули налаштувати: 7 дірок у серверній безпеці, через які вже лізуть

Уявіть: ви ставите броньовані двері у квартиру, а вікно на першому поверсі залишаєте навстіж. Смішно? Саме так виглядає більшість серверів у 2025 році. За даними Positive Technologies, 73% зламаних серверів мали хоча б один правильно налаштований захисний елемент - і одночасно три-чотири відверто забуті. Власники інвестують у SSL-сертифікати, але ігнорують SSH-ключі. Купують дорогий хостинг, але не закривають порти. Оновлюють CMS, але залишають дефолтні паролі на базах даних. Сьогодні ми поговоримо про конкретні дірки, які прямо зараз роблять ваш сервер ласим шматком для ботів і живих зловмисників.

Порти як двері підʼїзду: чому більшість відчинені для всіх

Коли ви орендуєте VPS або виділений сервер, за замовчуванням на ньому відкрито десятки портів. FTP на 21, SSH на 22, MySQL на 3306, і ще купа службових, про які ви навіть не підозрюєте. Це як будинок з двадцятьма дверима, де ви замкнули лише парадний вхід.

Перше правило серверної безпеки - закрийте все, що не використовуєте. Не "потім". Не "коли буде час". Зараз. Утиліта nmap покаже вам повну картину за 30 секунд:

1. Запустіть nmap -sS -p 1-65535 your_server_ip з іншої машини
2. Складіть список відкритих портів
3. Залиште тільки ті, що реально потрібні (зазвичай це 80, 443 і SSH на кастомному порті)
4. Закрийте решту через iptables або firewalld
5. Перевірте ще раз через тиждень - деякі сервіси люблять відкривати порти після оновлень

Один мій знайомий адміністратор знайшов на клієнтському сервері відкритий порт 11211 - Memcached без автентифікації. Бот-мережа вже використовувала його для DDoS-ампліфікації. Клієнт навіть не знав, що Memcached там стоїть - його поставив попередній розробник "для тестів" два роки тому.

SSH на 22-му порті: запрошення, яке приймають тисячі ботів щохвилини

Подивіться логи свого сервера прямо зараз. Файл /var/log/auth.log або /var/log/secure - залежно від дистрибутива. Бачите сотні рядків з "Failed password for root"? Це не параноя. Це реальність.

Щодня на кожен сервер з відкритим SSH на стандартному 22-му порті припадає від 5 000 до 50 000 спроб брутфорсу. Боти працюють цілодобово, без перерв і вихідних. Вони не втомлюються.

"Переміщення SSH на нестандартний порт зменшує кількість автоматизованих атак на 98%. Це не захист сам по собі, але це усуває величезний обсяг шуму і дозволяє побачити справжні загрози." - Daniel Miessler, дослідник кібербезпеки, автор проєкту Unsupervised Learning

Мінімальний набір дій для SSH:

• Змініть порт з 22 на будь-який вище 1024 (наприклад, 49152)
• Вимкніть вхід під root: PermitRootLogin no у sshd_config
• Використовуйте тільки ключі замість паролів: PasswordAuthentication no
• Додайте fail2ban з порогом у 3 невдалі спроби
• Обмежте доступ за IP через AllowUsers або firewall

Пʼять кроків. Десять хвилин. І ваш сервер перестає бути мішенню для 98% ботів. Нечесно мало зусиль для такого ефекту, правда?

Оновлення, яких "ніколи нема часу робити"

Знаєте, що спільного між серверним софтом і молоком? Обидва мають термін придатності. Тільки прокисле молоко ви викинете, а застарілий OpenSSL з відомою вразливістю - ні, він тихо працює місяцями.

Equifax у 2017 році втратили дані 147 мільйонів людей через вразливість в Apache Struts, для якої патч вийшов за два місяці до зламу. Два місяці. Хтось просто не натиснув "оновити".

Ось як виглядає реальна статистика за категоріями вразливостей у 2024 році:

Бачите цю прірву між "середнім часом до патча" і "реальним часом встановлення"? 67 днів замість трьох. Це не лінь - це організаційний хаос. Налаштуйте unattended-upgrades для критичних безпекових патчів хоча б на Debian/Ubuntu. Це автоматика, яка реально рятує.

Бекапи без перевірки - це не бекапи, а самозаспокоєння

"У нас все бекапиться" - чую я цю фразу регулярно. А потім починаються питання. Куди бекапиться? На той самий сервер? Коли востаннє перевіряли відновлення? Ніколи? Чудово.

Бекап, який лежить на тому ж фізичному сервері, що й основні дані - це як тримати копію ключів під килимком біля тих самих дверей. Зловмисник, який отримав root-доступ, видалить і сайт, і бекап одним рухом. Ransomware-атаки у 2024 році саме так і працювали - шифрували все, включно з локальними копіями.

Правило 3-2-1 ніхто не скасовував: три копії даних, на двох різних носіях, одна - за межами сервера (offsite). Мінімум. І хоча б раз на місяць робіть тестове відновлення. Без цього кроку ваш бекап - це файл Шредінгера: він одночасно працює і не працює, поки ви не спробуєте його розгорнути.

Права доступу: коли "chmod 777" стає прокляттям

Є команда, яку знає кожен початківець і яку ненавидить кожен безпековий аудитор. chmod 777. "Щось не працює - дай повні права всім". Працює? Працює. Безпечно? Катастрофічно ні.

Коли веб-сервер працює від імені www-data, а файли мають права 777, будь-який скрипт може записати що завгодно куди завгодно. Зловмисник завантажує PHP-шелл через вразливість у формі зворотного звʼязку - і ось він вже має повний доступ до файлової системи.

Правильний підхід:

• Директорії - 755, файли - 644 для контенту
• Конфігураційні файли (wp-config.php, .env) - 600 або навіть 400
• Власник файлів - не той самий користувач, від якого працює веб-сервер
• Окремі користувачі для кожного сайту на сервері (suEXEC або PHP-FPM pools)

Перевірте прямо зараз: find /var/www -perm -0777 -type f. Якщо результат не порожній - у вас проблема. І вона старша за цю статтю.

HTTPS є, а headers немає: безпека наполовину

SSL-сертифікат у 2025 році - це як ремінь безпеки в автомобілі: без нього взагалі не можна, але він один вас не врятує. Багато хто ставить Let's Encrypt, бачить зелений замочок у браузері - і вважає, що справу зроблено. Ні.

HTTP security headers - це другий шар захисту, про який забувають навіть досвідчені адміни. Перевірте свій сайт на securityheaders.com. Побачили оцінку F? Ласкаво просимо до клубу більшості.

Що потрібно додати у конфігурацію Nginx або Apache:

1. Content-Security-Policy - захист від XSS-атак та інʼєкцій стороннього коду
2. X-Frame-Options: DENY - блокує вбудовування вашого сайту у фрейми (clickjacking)
3. X-Content-Type-Options: nosniff - забороняє браузеру "вгадувати" тип контенту
4. Strict-Transport-Security (HSTS) - примусовий HTTPS без варіантів
5. Permissions-Policy - контроль доступу до камери, мікрофону, геолокації

Пʼять рядків у конфігу. Копіпаст з документації. А різниця між оцінкою F та A+ - це різниця між "заходьте, у нас відчинено" і серйозним захистом від цілого класу атак.

Моніторинг цілісності файлів: знати про злам раніше за хакера

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

Інструменти моніторингу цілісності файлів - такі як AIDE, Tripwire або навіть простий скрипт з sha256sum - створюють "знімок" вашої файлової системи. Будь-яка зміна - і ви отримуєте алерт. Хтось модифікував index.php о третій ночі? Ви дізнаєтесь о третій ночі і одній хвилині.

Серверна безпека - це не стан, а процес. Немає точки, де ви скажете "все, мій сервер захищений". Є набір практик, які ви або виконуєте регулярно, або ні. Кожен пропущений крок - це ще одне відчинене вікно у вашій квартирі з броньованими дверима.

Скільки з цих семи пунктів ви закрили на своєму сервері? Будьте чесні - від цього залежить не оцінка за тест, а збереженість ваших даних і даних ваших користувачів. Якщо відповідь "менше трьох" - відкладіть каву і відкрийте термінал. Серйозно. Прямо зараз.