1. З чого починається безпеку?
2. Безпека сервера - нічого зайвого.

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

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

У той же час роутер з виділеним IP-адресою є "воротами" до локальної мережі і тільки від адміністратора буде залежати будуть ці ворота надійною перешкодою або виявляться дачної хвірткою закритою на гвоздик.

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

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

Незважаючи на те, що стаття присвячена Ubuntu Server, спочатку ми розглянемо загальні питання безпеки, які в рівній мірі відносяться до будь-якій платформі і є азами, без засвоєння яких немає сенсу обговорювати питання більш детально.

З чого починається безпеку?

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

Тому перше, що ви повинні зробити - це провести аудит безпеки. Не лякайтеся цього слова, все не так складно: накресліть схематичний план мережі, на якому відзначте безпечну зону, зону потенційної небезпеки і зону підвищеної небезпеки, а також складіть список користувачів які мають (повинні мати доступ) до цих зон.

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

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

До небезпечній зоні слід віднести пристрої безпосередньо доступні ззовні, в ідеальному випадку це повинен бути один роутер.

По можливості потенційно небезпечну зону слід винести в окрему підмережу - демілітаризовану зону (DMZ), яка відокремлена від основної мережі додатковим брандмауером.

Пристрої локальної мережі повинні мати доступ лише зі службами в DMZ, які їм необхідні, наприклад SMTP, POP3, HTTP, інші сполуки повинні блокуватися. Це дозволить надійно ізолювати зловмисника або шкідливі програми, які скористалися вразливістю в окремому сервісі, демілітаризованою зоною, закривши їм доступ до основної мережі.

Фізично DMZ можна організувати поставивши окремий сервер / апаратний брандмауер або додавши додаткову мережну карту в роутер, проте в останньому випадку доведеться приділити пильну увагу безпеці роутера. Але в будь-якому випадку забезпечити безпеку одного сервера набагато простіше, ніж групи серверів.

Наступним кроком має стати аналіз списку користувачів, всім їм потрібен доступ в DMZ і до роутера (за винятком загальнодоступних служб), окрему увагу слід приділити користувачам підключаються ззовні.

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

Крім того пароль не повинен включати логін користувача або його частина, не містити дат і імен, які можна пов'язати з користувачем і, бажано, не бути словниковим словом.

Непогано завести практику міняти паролі раз в 30-40 днів. Зрозуміло, що подібна політика здатна викликати неприйняття з боку користувачів, але ви повинні завжди пам'ятати, що паролі типу 123 або qwerty рівносильні ключу залишеному під килимком.

Безпека сервера - нічого зайвого.

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

Чим менше служб, тим простіше забезпечити безпеку, тим менше шанс компрометації сервера через критичну уразливість в одній з них.

Налаштуйте служби, які обслуговують локальну мережу (наприклад squid), таким чином, щоб вони брали запити виключно з локального інтерфейсу. Чим менше служб є ззовні, тим краще.

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

Хорошим помічником у справі забезпечення безпеки буде сканер вразливостей, яким слід просканувати зовнішній інтерфейс сервера. Ми використовували демо-версію одного з найвідоміших продуктів - XSpider 7.7.

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

Окремо варто поговорити про безпеку SSH, дана служба зазвичай використовується адміністраторами для віддаленого управління сервером і представляє підвищений інтерес для зловмисників. Налаштування SSH зберігаються в файлі / etc / ssh / sshd_config, всі описувані нижче зміни вносяться в нього. В першу чергу слід заборонити авторизацію під користувачем root, для цього додайте опцію:

PermitRootLogin no

Тепер зловмиснику доведеться підбирати не тільки пароль, але ще і логін, при цьому йому все одно буде невідомий пароль суперкористувача (сподіваємося він не збігається з вашим паролем). Всі адміністративні завдання при підключенні ззовні варто виконувати з-під sudo, входячи в систему звичайним користувачем.

Варто явно вказати список дозволених користувачів, при цьому можна використовувати записи типу user @ host, яка дозволяє вказаною користувачеві підключатися тільки з зазначеного хоста. Наприклад щоб дозволити користувачеві ivanov підключатися з дому (IP 1.2.3.4) слід додати наступний запис:

AllowUser [email protected]

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

Protocol 2

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

sudo apt-get install fail2ban

Дана утиліта готова до роботи відразу після установки, однак ми б радили відразу змінити деякі параметри, для цього внесіть зміни в файл /etc/fail2ban/jail.conf. За замовчуванням контролюється тільки доступ до SSH і час бана становить 10 хвилин (600 секунд), на наш погляд варто його збільшити, змінивши наступну опцію:

bantime = 6000

Після чого перегорніть файл і включіть секції для працюючих у вашій системі служб, встановивши після імені відповідної секції параметр enabled в стан true, наприклад для служби proftpd це буде виглядати так:

[Proftpd]
enabled = true

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

sudo /etc/init.d/fail2ban restart

Лог роботи утиліти ви можете подивитися в /var/log/fail2ban.log.

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