Phenquestions
Заходи захисту сервера SSH варіюються від базових до вдосконалених, і, як ми вже говорили раніше, ви можете вибрати їх відповідно до рівня безпеки, який вам потрібен. Ви можете пропустити будь-який із передбачених заходів, якщо ви маєте достатнє знання про наслідки та якщо у вас є можливість вирішити їх. Крім того, ми ніколи не можемо сказати, що один крок забезпечить 100% безпеку, або певний крок кращий за інший.
Все залежить від того, який тип безпеки нам насправді потрібен. Тому сьогодні ми маємо намір дати вам дуже глибоке розуміння основних та вдосконалених кроків щодо захисту сервера SSH в Ubuntu 20.04. Окрім цих методів, ми також поділимося з вами додатковими порадами щодо захисту вашого SSH-сервера як бонус. Тож давайте почнемо з сьогоднішньої цікавої дискусії.
Метод захисту SSH-сервера в Ubuntu 20.04:
Усі конфігурації SSH зберігаються у файлі / etc / ssh / sshd_config. Цей файл вважається дуже важливим для нормальної роботи вашого SSH-сервера. Тому перед внесенням будь-яких змін у цей файл настійно рекомендується створити резервну копію цього файлу, виконавши в своєму терміналі таку команду:
sudo cp / etc / ssh / sshd_config / etc / ssh / sshd_config.бак
Якщо ця команда буде виконана успішно, вам не буде представлено жодних результатів, як показано на малюнку нижче:
Після створення резервної копії цього файлу цей крок є необов’язковим і виконується, якщо ви хочете перевірити всі параметри, які наразі ввімкнено в цьому конфігураційному файлі. Ви можете перевірити це, виконавши наступну команду у своєму терміналі:
Наразі ввімкнені параметри файлу конфігурації SSH показані на зображенні нижче. Ви можете прокрутити цей список, щоб переглянути всі опції.
Тепер ви можете розпочати захист свого SSH-сервера, переходячи від основних кроків до розширених кроків в Ubuntu 20.04.
Основні кроки для захисту сервера SSH в Ubuntu 20.04:
Основні кроки для захисту сервера SSH в Ubuntu 20.04 такі:
Крок No1: Відкриття файлу конфігурації SSH:
Ви можете відкрити файл конфігурації SSH, виконавши в терміналі команду, зазначену нижче:
sudo nano / etc / ssh / sshd_config
Файл конфігурації SSH показаний на наступному зображенні:
Крок 2. Вимкнення автентифікації на основі пароля:
Замість використання паролів для автентифікації ключі SSH вважаються більш безпечними. Отже, якщо ви створили ключі SSH для автентифікації, вам слід вимкнути автентифікацію на основі пароля. Для цього вам потрібно знайти змінну “PasswordAuthentication”, розкомментувати її та встановити для її значення “ні”, як це виділено на зображенні нижче:
Крок No3: Відхилення / заборона порожніх паролів:
Іноді користувачам надзвичайно зручно створювати порожні паролі заради того, щоб уберегти себе від запам'ятовування складних паролів. Ця практика може виявитись шкідливою для безпеки вашого SSH-сервера. Тому вам потрібно відхилити всі спроби автентифікації за допомогою порожніх паролів. Для цього вам потрібно знайти змінну “PermitEmptyPasswords” і просто її прокоментувати, оскільки її значення за замовчуванням вже встановлено в “ні”, як це виділено на наступному зображенні:
Крок No4: Заборона корінного входу:
Вам слід суворо заборонити входити в систему root для захисту будь-якого зловмисника від отримання доступу до вашого сервера на рівні root. Це можна зробити, знайшовши змінну “PermitRootLogin”, розкомментируйте її та встановіть для її значення значення “ні”, як це виділено на зображенні нижче:
Крок 5: Використання протоколу SSH 2:
Сервер SSH може працювати за двома різними протоколами, тобто.e., Протокол 1 і Протокол 2. Протокол 2 реалізує більш розширені функції безпеки, саме тому він віддає перевагу протоколу 1. Однак протокол 1 є протоколом SSH за замовчуванням, і він явно не згадується у файлі конфігурації SSH. Отже, якщо ви хочете працювати з Протоколом 2 замість Протоколу 1, то вам потрібно явно додати рядок “Протокол 2” у ваш файл конфігурації SSH, як це виділено на наступному зображенні:
Крок 6: Встановлення часу очікування сеансу:
Іноді користувачі залишають свої комп’ютери без нагляду дуже довго. Тим часом будь-який зловмисник може підійти і отримати доступ до вашої системи, порушуючи її безпеку. Тут входить в дію концепція тайм-ауту сеансу. Ця функція використовується для виходу користувача з системи, якщо він залишається неактивним протягом тривалого часу, так що жоден інший користувач не може отримати доступ до його системи.
Цей тайм-аут можна встановити, знайшовши змінну “ClientAliveInterval”, розкомментувати її та призначити будь-яке значення (у секундах) на ваш вибір. У нашому випадку ми призначили йому значення "300 секунд" або "5 хвилин". Це означає, що якщо користувач залишається подалі від сервера SSH на «300 секунд», то він автоматично вийде з системи, як це виділено на зображенні, показано нижче:
Крок 7: Надання певним користувачам доступу до сервера SSH:
Сервер SSH - це не сервер, доступ якого вимагає кожен інший користувач. Тому доступ до нього повинен бути обмежений лише тими користувачами, які насправді потребують цього. Щоб дозволити певним користувачам доступ до сервера SSH, вам потрібно додати змінну з назвою «AllowUsers» до файлу конфігурації SSH, а потім написати імена всіх тих користувачів, яким ви хочете дозволити доступ до сервера SSH, розділені пробілом. У нашому випадку ми хотіли дозволити лише одному користувачеві доступ до сервера SSH. Ось чому ми додали його ім’я лише так, як виділено на наступному зображенні:
Крок 8: Обмеження кількості спроб автентифікації:
Щоразу, коли користувач намагається отримати доступ до сервера, і він не може автентифікуватися вперше, він намагається зробити це знову. Користувач продовжує робити ці спроби до тих пір, поки він не зможе автентифікуватися, отже, отримаючи доступ до сервера SSH. Це вважається надзвичайно небезпечною практикою, оскільки хакер може запустити атаку грубої сили (атака, яка неодноразово намагається вгадати пароль, доки не буде знайдено правильний збіг). Як результат, він зможе отримати доступ до вашого SSH-сервера.
Ось чому настійно рекомендується обмежити кількість спроб автентифікації, щоб запобігти атакам вгадування пароля. Значенням за замовчуванням для спроб автентифікації сервера SSH встановлено значення “6”. Однак ви можете змінити його залежно від рівня безпеки, який вам потрібен. Для цього вам потрібно знайти змінні “MaxAuthTries”, розкомментирувати їх і встановити його значення на будь-яке бажане число. Ми хотіли обмежити спроби автентифікації “3”, як це виділено на зображенні, показано нижче:
Крок 9: Запуск сервера SSH у тестовому режимі:
На даний момент ми зробили всі основні кроки, щоб захистити наш SSH-сервер на Ubuntu 20.04. Однак нам все одно потрібно переконатися, що параметри, які ми щойно налаштували, працюють належним чином. Для цього ми спочатку збережемо та закриємо наш конфігураційний файл. Після цього ми спробуємо запустити наш сервер SSH у тестовому режимі. Якщо він успішно працює в тестовому режимі, це означатиме, що у вашому конфігураційному файлі немає помилок. Ви можете запустити ваш SSH-сервер у тестовому режимі, виконавши в своєму терміналі таку команду:
sudo sshd -t
Після успішного виконання цієї команди на терміналі вона не відображатиме вихідних даних, як показано на малюнку нижче. Однак, якщо у вашому файлі конфігурації будуть помилки, тоді запуск цієї команди відобразить ці помилки на терміналі. Потім вам слід буде виправити ці помилки. Тільки тоді ви зможете продовжувати далі.
Крок 10: Перезавантаження сервера SSH новими конфігураціями:
Тепер, коли сервер SSH успішно працював у тестовому режимі, нам потрібно перезавантажити його, щоб він міг прочитати новий файл конфігурації, i.e., зміни, які ми внесли у файл конфігурації SSH на кроках, показаних вище. Для перезавантаження сервера SSH новими конфігураціями потрібно виконати таку команду у своєму терміналі:
sudo service sshd перезавантажити - -
Якщо ваш SSH-сервер буде перезапущено успішно, термінал не відображатиме вихідних даних, як показано на зображенні нижче:
Розширені кроки для захисту сервера SSH в Ubuntu 20.04:
Після виконання всіх основних кроків щодо захисту сервера SSH в Ubuntu 20.04, нарешті можна перейти до просунутих кроків. Це лише крок вперед для захисту вашого SSH-сервера. Однак якщо ви маєте намір досягти лише помірного рівня безпеки, то описаних вище кроків буде достатньо. Але якщо ви хочете піти трохи далі, ви можете виконати описані нижче дії:
Крок No1: Відкриття ~ /.Файл ssh / санкціоновані_клавіші:
Основні етапи захисту сервера SSH реалізовані у файлі конфігурації SSH. Це означає, що ці правила будуть корисними для всіх користувачів, які намагатимуться отримати доступ до сервера SSH. Це також передбачає, що основні етапи представляють загальний метод захисту сервера SSH. Однак, якщо ми спробуємо розглянути принцип «Захист у глибину», то ми зрозуміємо, що нам потрібно захистити кожен окремий ключ SSH окремо. Це можна зробити, визначивши явні параметри безпеки для кожного окремого ключа. Ключі SSH зберігаються в ~ /.ssh / санкціоновані_ключі, тому ми спочатку отримаємо доступ до цього файлу, щоб змінити параметри безпеки. Ми виконаємо наступну команду в терміналі для доступу до ~ /.ssh / файл авторизованих ключів:
sudo nano ~ /.ssh / дозволені_клавішіЗапуск цієї команди відкриє вказаний файл за допомогою редактора nano. Однак ви можете використовувати будь-який інший текстовий редактор на ваш вибір, щоб відкрити цей файл. Цей файл буде містити всі SSH-ключі, які ви створили до цього часу.
Крок 2. Визначення конкретних конфігурацій для окремих ключів:
Для досягнення просунутого рівня безпеки доступні наступні п’ять варіантів:
- no-agent-forwarding
- переадресація без порту
- ні-шкода
- no-user-rc
- no-X11-переадресація
Ці параметри можна записати перед будь-яким ключем SSH на ваш вибір, щоб зробити їх доступними для цього конкретного ключа. Навіть більше одного варіанту також можна налаштувати для одного ключа SSH. Наприклад, ви хочете відключити переадресацію портів для будь-якого конкретного ключа, або, іншими словами, ви хочете реалізувати переадресацію портів для певного ключа, тоді синтаксис буде таким:
no-port-forwarding DesiredSSHKeyТут замість DesiredSSHKey ви будете мати фактичний ключ SSH у вашому ~ /.ssh / файл санкціонованих ключів. Після застосування цих параметрів для бажаних ключів SSH вам потрібно буде зберегти ~ /.ssh / санкціоновані_ключі та закрийте його. Добре, що стосується цього вдосконаленого методу, це те, що він не вимагатиме перезавантаження сервера SSH після внесення цих змін. Швидше ці зміни будуть зчитуватися вашим сервером SSH автоматично.
Таким чином, ви зможете глибоко захистити кожен ключ SSH, застосувавши розширені механізми безпеки.
Деякі додаткові поради щодо захисту сервера SSH в Ubuntu 20.04:
Окрім усіх основних та вдосконалених кроків, які ми зробили вище, є також кілька додаткових порад, які можуть виявитись дуже хорошими для захисту сервера SSH в Ubuntu 20.04. Ці додаткові поради були розглянуті нижче:
Зберігайте свої дані в зашифрованому вигляді:
Дані, що знаходяться на вашому сервері SSH, а також ті, що залишаються в передачі, повинні бути зашифровані, і це також, з потужним алгоритмом шифрування. Це не тільки захистить цілісність і конфіденційність ваших даних, але також запобіжить порушенню безпеки всього вашого сервера SSH.
Оновлюйте програмне забезпечення:
Програмне забезпечення, яке працює на вашому сервері SSH, повинно бути оновленим. Це робиться для того, щоб жодні помилки безпеки у вашому програмному забезпеченні не залишались без нагляду. Швидше їх слід вчасно виправити. Це позбавить вас від будь-якої потенційної шкоди в довгостроковій перспективі, а також запобіжить падінню або недоступності сервера через проблеми безпеки.
Переконайтеся, що SELinux увімкнено:
SELinux - це механізм, який закладає основу безпеки в системах на базі Linux. Це працює шляхом впровадження обов'язкового контролю доступу (MAC). Він реалізує цю модель контролю доступу, визначаючи правила доступу у своїй політиці безпеки. Цей механізм увімкнено за замовчуванням. Однак користувачам дозволяється будь-коли змінювати це налаштування. Це означає, що вони можуть відключити SELinux, коли захочуть. Однак настійно рекомендуємо завжди залишати включеним SELinux, щоб він міг запобігти вашому SSH-серверу від усієї потенційної шкоди.
Використовуйте сувору політику щодо паролів:
Якщо ви захистили свій SSH-сервер паролями, то вам слід створити надійні правила щодо паролів. В ідеалі паролі повинні складати більше 8 символів. Їх слід міняти через визначений час, скажімо, через кожні 2 місяці. Вони не повинні містити жодних словникових слів; швидше, вони повинні бути комбінацією алфавітів, цифр та спеціальних символів. Подібним чином ви можете визначити деякі інші надзвичайно жорсткі заходи для своїх політик щодо паролів, щоб переконатися, що вони достатньо надійні.
Моніторинг та ведення журналів аудиту вашого SSH-сервера:
Якщо з вашим сервером SSH щось піде не так, вашим першим помічником можуть бути журнали аудиту. Тому ви повинні продовжувати вести ці журнали, щоб можна було прослідкувати першопричину проблеми. Більше того, якщо ви постійно стежите за працездатністю та роботою вашого SSH-сервера, це також запобіжить виникненню будь-яких основних проблем.
Ведіть регулярні резервні копії своїх даних:
І останнє, але не менш важливе: ви завжди повинні зберігати резервну копію всього SSH-сервера. Це не лише збереже ваші дані від пошкодження або втрати; швидше, ви також можете використовувати цей сервер резервного копіювання, коли ваш основний сервер не працює. Це також обмежить час простою сервера та забезпечить його доступність.
Висновок:
Подбавши про всі заходи, прописані в цій статті, ви можете легко захистити або затвердити свій SSH-сервер в Ubuntu 20.04. Однак, якщо ви походите з інформаційної безпеки, ви повинні добре усвідомлювати цей факт, що немає нічого подібного до 100% безпеки. Все, що ми можемо отримати, це обіцянка найкращих зусиль, і ці найкращі зусилля будуть забезпечені лише до тих пір, поки вони також не будуть порушені. Ось чому навіть після вжиття всіх цих заходів ви не можете сказати, що ваш SSH-сервер на 100% захищений; швидше, він все ще може мати такі вразливості, про які ви навіть не могли подумати. Подолати такі вразливості можна лише в тому випадку, якщо ми пильно стежимо за нашим сервером SSH і постійно оновлюємо його, коли це потрібно.
