Які дії ви зробите для захисту сервера Debian? [зачинено]

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

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

Ви змінюєте свій порт SSH? Чи використовуєте Ви програмне забезпечення типу Fail2Ban для запобігання жорстоких атак?

Обов’язкові:

• установка системи в експертному режимі, лише ті пакунки, які мені потрібні
• рукописний брандмауер з політикою за замовчуванням на iptables'input: drop, що дозволяє отримати доступ до SSH, HTTP або будь-якого іншого сервера.
• Fail2Ban для SSH [а іноді і FTP / HTTP / інше - залежно від контексту]
• відключити кореневі входи, примусити використовувати звичайного користувача та sudo
• користувацьке ядро ​​[просто стара звичка]
• планове оновлення системи

Залежно від рівня параноїя додатково:

• політика падіння виходу за винятком декількох дозволених напрямків / портів
• integritперевірити, чи не змінено деякі частини файлової системи [з контрольною сумою, що зберігається поза машиною], наприклад Tripwire
• планове сканування принаймні за допомогою nmap системи ззовні
• автоматична перевірка журналу на предмет невідомих шаблонів [але це здебільшого для виявлення несправностей обладнання або деяких незначних збоїв]
• запланований запуск chkrootkit
• незмінний атрибут для того, /etc/passwdщоб додати нових користувачів трохи складніше
• / tmp, змонтований з noexec
• сувенірний порт або інший нестандартний спосіб відкриття портів SSH [наприклад, відвідування «секретної» веб-сторінки на веб-сервері дозволяє вхідне з'єднання SSH протягом обмеженого періоду часу з IP-адреси, яка переглядала сторінку. Якщо ви підключитесь, -m state --satete ESTABLISHEDпіклується про те, щоб дозволити потік пакетів, поки ви використовуєте один сеанс SSH]

Те, що я не роблю сама, але має сенс:

• безпека для ядра
• віддалений syslog, тому журнали не можуть бути перезаписані при порушенні системи
• попередження про будь-які входи в SSH
• налаштуйте rkhunter і налаштуйте його для запуску час від часу

Просто примітка про брандмауер Вашої машини ...

• Використовуйте білий список, а не чорний список - тобто заблокуйте все, і дозвольте лише те, що вам потрібно, заперечуйте все інше.
• Не використовуйте GUI / ncurses або будь-яке інше програмне забезпечення, яке намагається скласти для вас завдання брандмауера. Якщо ви це зробите, ви будете дозволяти програмному забезпеченню робити припущення для вас - вам не потрібно ризикувати і не варто. Налаштуйте його самостійно, якщо ви не впевнені, відключіть його - ви дізнаєтесь досить швидко, якщо це потрібно. Якщо це вже запущена система, і ви не можете порушити трафік (випадково заблокувавши його), запустіть tcpdump (дамп у файл) і взяти зразки - вивчіть їх пізніше, а потім з’ясуйте, що є дійсним, а що ні.
• Я особисто не бачу сенсу запускати службу на нестандартному порту, інструменти в наші дні не такі німі, щоб припустити, що, оскільки щось працює на порту 22, наприклад, це повинно бути ssh, а не інакше - для Наприклад amap, і nmaps ' -Aваріант. Сказавши це, ви можете (і, мабуть, маєте бажання) змінити свої служби, щоб сховатися від сторонніх очей, наприклад, наступне дозволить зловмисникові дізнатись точну версію OpenSSHзапущеного вами, а потім вони можуть шукати подвиги для точна версія. Якщо ви приховуєте подібні речі, ви б ускладнювали їх.

    [root @ ud-olis-1 uhtbin] # telnet localhost 22
    Пробуємо 127.0.0.1 ...
    Підключено до localhost.localdomain (127.0.0.1).
    Символ втечі - '^]'.
    SSH-2.0-OpenSSH_3.9p1

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

Підсумок полягає в тому, що вам ніколи не вдасться зробити що-небудь на 100% захищеним - це просто неможливо - тому мета полягає в тому, щоб зробити це максимально захищеним - якщо для того, щоб зламати вашу систему, потрібно занадто багато зусиль, це досить добре і більшість ламерних діти-сценарії перейдуть до наступної системи.

• iptables це шлях для будь-якої системи Linux - але налаштуйте її самостійно.

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

Сподіваюся, що це допомагає :)

• відключити кореневий вхід
• вимкнути вхід паролем (дозволити вхід лише відкритим ключем)
• змінити порт SSH

• використовувати запрети (або подібні)

• написати власний скрипт iptbles (щоб ви точно контролювали, що дозволити, і можете скинути все інше)

• змусити використовувати захищені SSL / TLS комунікації та переконайтеся, що вони мають дійсні, недійсні та підписані сертифікати

• увімкніть сувору перевірку сертифікатів для всіх зовнішніх служб (наприклад, при автентифікації користувачів на сервері LDAP на іншій машині)

Починай тут:

http://www.debian.org/doc/manuals/securing-debian-howto/

Як загальний вихідний пункт, я дотримуюсь орієнтиру / довідників Центру безпеки в Інтернеті , які представляють собою вичерпні збірки найкращих практик безпеки. Не схоже, що їх орієнтир Debian був оновлений за деякий час, але загальний огляд кроків:

• Застосувати останні патчі / пакети ОС
• Увімкнути облік системи / ядра / процесу.
• Увімкніть MAC (наприклад, SELinux або AppArmor).
• Увімкнути брандмауер на основі хоста (iptables).
• Перевірте APT source.list (ключі правильні, джерелам довіряють).
• Мінімізуйте мережеві послуги, вимкніть все необхідне та брандмауер, що є.
• Використовуйте TCPWrappers для подальшого обмеження доступу до системи.
• Використовуйте лише зашифровані мережеві протоколи, відключайте незашифровані послуги (telnet, ftp тощо).
• Настройте віддалений доступ лише до SSH.
• Вимкніть паролі для входу користувачів та потребуйте аутентифікації на основі ключа.
• Вимкнути спільний доступ до файлової системи (NFS, SMB).
• Увімкніть віддалений / централізований системний журнал (і регулярно переглядайте журнали!).
• Встановіть пароль рівня BIOS / прошивки.
• Встановіть пароль завантажувача.
• Налаштуйте резервні копії системи, складіть план відновлення після аварій і TEST, що резервні копії є дійсними, і що персонал знає процедури відновлення після аварій!

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

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

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

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

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

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

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

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

Я переходжу до шифрування на повному диску для всіх моїх серверів.

Я встановлюю лише сервіси, якими користуюся. У мене немає брандмауера; Я конфігурую послуги, які мені потрібно вимагати аутентифікацію, або обмежувати їх (за власною конфігурацією програми або TCP-обгортками) певними IP-адресами. Єдине, що мені потрібно було заблокувати за допомогою iptables memcached, це те, що він не мав файлу конфігурації і не використовував TCP-обгортки.

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

Перегляньте цю приємну практику на веб-сайті www.debian.org/doc/manuals/securing-debian-howto/

Я особисто змінюю порт ssh і використовую fail2ban + denyhosts. І я блокую все, що не потрібно. Чим більше ви блокуєте, тим менше потрібно хвилюватися.