Можливо десь буде трохи тривіальщини, проте з нашого досвіду, умовно зі 100 очевидних речей, добрих відсотків 20% завжди або забувається або десь не цілком догледіли. Звідси потім і маленькі і великі проблеми. Тому давайте їх уникати і робити свою інфраструктуру безпечною!
У цій статті ми розглянемо як кейси з власного досвіду так і деякі показові, відомі широкому загалу. Повірте, за 10 років на ринку ми встигли побачити достатньо – від зламаних серверів з паролем типу 123qwe, резервних копій сервера на тому ж сервері і до ssh ключів у вільному доступі у репозиторії GitHub.
Ми не претендуємо на “експертність” у сфері безпеки, а хочемо поділитись з вами тим, з чим стикалося наше ком’юніті, що дозволить зайвий (насправді не зайвий 🙂) раз себе перевірити.
1. Використовуйте складні паролі не тільки на prod 🙂 та захистіть саме з’єднання з серверами
Так звісно, на prod ви не забудете зробити все як треба, а як щодо серверів які використовуються суто під внутрішні потреби? Думаєте це банальщина? Так воно і є! І саме тому ну дуже часто на цьому моменті багато хто просто “забиває/забуває”. Наявність сильного паролю не є 100% гарантією що вас не зламають але якщо ще подумати про блокування доступу по IP, навіть зі зламаним паролем потрапити до вашої інфраструктури не вийде.
Кейс: Саме таке рішення ми запропонували нашому клієнту, коли він періодично скаржився на якісь нові файли на сервері, котрих не повинно було там бути. Ми не знаємо, як і де саме клієнт зберігав пароль доступу, проте після обмеження доступу по IP “загадкові” файли перестали з’являтися.
Рекомендації:
✔ Використовуйте складні паролі, які містять літери, цифри та спеціальні символи на ВСІЙ інфраструктурі. Навіть якщо той сервер використовується раз на рік і там “немає нічого важливого”
✔ Завжди змінюйте автоматично згенеровані хостингом паролі.
✔ Використовуйте VPN для адміністрування серверу та обмежуйте доступ для всіх IP крім ваших.
✔ Приховуйте реальну IP адресу Вашого сервера – це значно зменшує потенційний масштаб шкоди.
✔ Регулярно оновлюйте паролі та уникайте їх повторного використання.
2. Несвоєчасне оновлення програмного забезпечення
Застаріле програмне забезпечення, операційні системи чи CMS (наприклад, WordPress, Joomla) часто містять вразливості, які можуть бути використані зловмисниками.
Кейс: У 2017 році світ охопила атака вірусом-шифрувальником WannaCry, який використовував вразливість у застарілій версії Windows. Багато компаній, які не встановили оновлення для операційної системи, стали жертвами атаки. Вірус зашифрував дані на тисячах комп’ютерів, вимагаючи викуп за їх розшифрування.
Рекомендації:
✔ Встановлюйте оновлення та патчі для всіх компонентів інфраструктури.
✔ Налаштуйте автоматичне оновлення для критично важливих систем.
✔ CVE. Відстежуйте появу нових та усунення раніше виявлених вразливостей для програмного забезпечення, яке ви використовуєте.
✔ Регулярно перевіряйте програмне забезпечення на наявність вразливостей.
3. Наявність і дотримання політики кібербезпеки в компанії
Ситуації бувають різні. Подбайте про скрипт на випадок інциденту. Хто, коли і за що відповідає. Які дії в першу чергу будуть прийняті, дублери у цих людей теж повинні бути з відповідним рівнем допуску. Хтось може бути у відпустці, не на зв’язку і тд. Краще хай це все буде і не знадобиться ніж навпаки.
Кейс: Тут можна згадати ситуацію яка сталась з Київстаром. Є золотий трикутник кіберзахисту, в який входять технології, процеси і люди. Якщо людей не навчати, якщо людський фактор не враховувати, то будь -яка компанія може бути зламана.
Рекомендації:
✔ Наявність політики кібербезпеки і конкретних дій на випадок різних інцидентів.
✔ Звертайте увагу на кібергігієну своєї команди, підвищуйте кваліфікацію своїх технічних спеціалістів.
✔ Обмежте доступ до портів, які не використовуються.
✔ Налаштуйте правила брандмауера для дозволу лише необхідного трафіку.
4. Відсутність резервного копіювання
Навіть при найкращій безпеці завжди існує ризик втрати даних через атаки, збої обладнання чи помилки адміністратора. Відсутність резервних копій може призвести до катастрофічних наслідків.
Кейс: Саме так сталося з одним із наших клієнтів (клієнтом він став після цього випадку насправді) Отже, у 2021 в OVH згорів дата-центр в Страсбурзі. Найцікавіше, що клієнт таки подумав про бекапи, правда тримав він їх на тому ж сервері, в тому ж дата центрі.
Нажаль відновити дані змоги не було але ми розосередили всю інфраструктуру клієнта по різним гео, та різним серверам під виділені задачі. Налаштували RAID, синхронізацію з іншими серверами. Тепер навіть в випадку пожежі – все буде ок.
Рекомендації:
✔ Налаштуйте регулярне резервне копіювання даних.
✔ Зберігайте резервні копії на окремих серверах або в хмарних сховищах.
✔ Перевіряйте цілісність резервних копій та робіть тестові відновлення.
✔ Перевіряйте чи відпрацьовує автоматика резервного копіювання з потрібною вам частотою
5. Ігнорування шифрування даних
Передача конфіденційних даних (наприклад, паролів, платіжної інформації) без шифрування робить їх легкою здобиччю для зловмисників.
Кейс: У 2018 році компанія British Airways була оштрафована на 183 мільйони фунтів стерлінгів через витік даних 500 тисяч клієнтів. Зловмисники змогли перехопити конфіденційну інформацію (номери кредитних карток, імена, адреси) через те, що дані передавалися без належного шифрування на сайті компанії.
Рекомендації:
✔ Використовуйте протоколи HTTPS для захисту даних під час передачі.
✔ Шифруйте бекапи, важливі файли та бази даних на сервері.
✔ Використовуйте сертифікати SSL/TLS для веб-сайтів.
6. Неправильне налаштування прав доступу
Надання надмірних прав доступу користувачам або службам може призвести до несанкціонованого доступу до критично важливих ресурсів.
Кейс: Клієнт звернувся через раптове зростання навантаження на сервер. Було виявлено шкідливе ПЗ (майнер криптовалют та програма віддаленого керування), а також доданий ключ SSH невідомої особи. Після видалення ПО зловмисник відновлював доступ через шкідливий код у профілі Bash та вразливий модуль сайту. Після усунення цих вразливостей доступ зловмисника було повністю заблоковано.
Рекомендації:
✔ Дотримуйтесь принципу мінімальних привілеїв (надавайте лише необхідні права).
✔ Не концентруйте всі доступи чи ключі на аккаунтах окремих співробітників.
✔ Регулярно перевіряйте та оновлюйте права доступу.
✔ Використовуйте окремі облікові записи для різних служб.
7. Відсутність моніторингу та логування
Без належного моніторингу та логування ви можете не помітити підозрілу активність чи атаку на сервер.
Кейс: Саме з таким нетиповим запитом звернувся поточний клієнт. У нього були деякі підозри з приводу чесності окремих людей з його команди, тому він просив розробити рішення яке б допомогло виявити будь яку нетипову поведінку. На окремих RDP був налаштований моніторинг і при вході на робочий сервер одразу спрацьовував бот який повідомляв про це клієнта. Додатково була встановлена заборона встановлювати будь яке ПО.
Моніторинг допоміг виявити що один співробітник постійно заходив на сервер в неробочі години.
Рекомендації:
✔ Налаштуйте систему моніторингу для відстеження стану серверів.
✔ Зберігайте логи подій та регулярно аналізуйте їх на наявність аномалій.
✔ Використовуйте інструменти для автоматичного виявлення загроз (наприклад, SIEM-системи).
8. Цілодобова підтримка
Так, це складно віднести саме до помилок і це скоріш рекомендація. Проте вчасна реакція так само важлива як і всі попередні міри. Тому якщо щось вже і сталося, то дуже непогано якщо підтримка вашого дата-центру чи веб хостинг провайдеру може вчасно відреагувати. Нажаль такі гіганти як Hetzner, OVH чи той самий AWS будуть просто не в змозі відповісти вам за 5 хв. І якщо ваш адмін “не в мережі”, доступу до сервера у вас немає, то вітаємо в клубі “ Your request will be held by responsible employee in his working hours”
Кейс: Саме це ми надаємо нашим клієнтам. 24/7/365 – швидку та якісну підтримку. І не важливо чи день чи ніч, чи свято чи вихідний. Наші клієнти можуть просто на сайті звернутись в чат і отримати відповідь вже менш як за хвилину(!). Звичайно все залежить від кейсу і саме рішення може зайняти більше часу але якщо вас зламали і ви нічого не можете вдіяти самостійно, вже за 2 хвилини Ваш сервер буде вимкнуто і як мінімум важливу інформацію з нього ніхто не дістане.
Рекомендації:
✔ Налаштуйте систему моніторингу для відстеження стану серверів.
✔ Зберігайте логи подій та регулярно аналізуйте їх на наявність аномалій.
✔ Вибирайте хостинг виходячи з ваших потреб. Не всім необхідні гіганти ринку. Особливо якщо в вас невелика інфраструктура.
Висновок
Безпека — це не одноразове завдання, а постійний процес. Не економте на ній, адже вартість можливих наслідків може бути набагато вищою. Якщо ви сумніваєтеся у своїх силах, звертайтеся до професіоналів або використовуйте послуги надійних хостинг-провайдерів, які пропонують вбудовані засоби захисту та підтримку.
Дякуємо всім, хто дочитав до кінця: за промокодом DEV10 ми пропонуємо вам 10% знижки на перше замовлення та безкоштовну консультацію.
Також, можете перевірити швидкість відповіді нашої підтримки у чаті на сайті: unihost.com