Як загартувати SSH-сервер?


128

Які заходи можна / потрібно вжити, щоб переконатися, що безпека навколо мого SSH-сервера абсолютно непроникна?

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


44
Абсолютна непроникність вимагає вимкнення коробки.
Thorbjørn Ravn Andersen

Що робити, якщо у вас Wake-on-LAN?
ребус

Проблема полягала б у частині LAN ... Пакети Wake-on-LAN не маршрутизуються, тому вам доведеться мати доступ до машини всередині локальної мережі, щоб відправити пакет WOL ...
LassePoulsen,

Для автентифікації ключів ви можете обмежити Шифри тими, що вам дійсно потрібні.

Відповіді:


108

Використовуйте пари відкритих / приватних ключів для автентифікації замість паролів.

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

    ssh-keygen

  2. Дозволити доступ із відкритим ключем до SSH з дозволених комп'ютерів:

    Скопіюйте вміст ~/.ssh/id_rsa.pubкожного комп’ютера в окремі рядки ~/.ssh/authorized_keysна сервері або запустіть ssh-copy-id [server IP address]на кожному комп'ютері, до якого ви надаєте доступ (вам потрібно буде ввести пароль сервера під запитом).

  3. Вимкнути пароль доступу до SSH:

    Відкрийте /etc/ssh/sshd_config, знайдіть рядок, який говорить #PasswordAuthentication yes, і змініть його на PasswordAuthentication no. Перезапустіть демон сервера SSH, щоб застосувати change ( sudo service ssh restart).

Тепер єдиний можливий спосіб SSH на сервер - це використання ключа, який відповідає рядку в ~/.ssh/authorized_keys. Використовуючи цей метод, я не дбаю про грубі напади, тому що навіть якщо вони вгадають мій пароль, він буде відхилений. За допомогою сучасної технології жорстоке примушування пари державних / приватних ключів неможливо .


5
-1: Як правило, доступ надається окремим, а не комп'ютерам. Створення ключа для кожного потенційного клієнтського комп'ютера, підключеного до сервера, нерозумно. Ваше останнє твердження невірне за вашим пропозицією і тому, що ви не запропонували встановлювати парольну фразу для приватних ключів, що мають доступ / компрометують будь-яку з клієнтських систем, автоматично надають доступ до SSH-сервера. Рекомендується автентифікація ключів SSH, але приватні ключі повинні бути належним чином захищені, і їх слід використовувати індивідуально, а не в розповсюдженому способі, як описано.
Жоао Пінто

7
"Взагалі доступ надається окремим, а не комп'ютерам. Створення ключа для кожного потенційного клієнтського комп'ютера, що підключається до сервера, нерозумно" Є багато варіантів, і я думаю, що опис того, як безпечно передати приватний ключ кожному клієнту, здається, не входить у сферу цього питання . Я не представляю всіх варіантів, просто простий, який я думаю, що люди можуть зрозуміти. "... слід використовувати індивідуально, а не розподіленим способом, як описано". Це, здається, суперечить вашому попередньому твердженню, і я нічого не описував як розподілене.
Аса Айерс

5
"неможливо", можливо, це трохи переборщити.
Thorbjørn Ravn Andersen

9
Ось чому я кажу "неможливо". Ніхто не має комп'ютерів так швидко, цей маленький, стільки чи багато часу. "Уявіть собі комп'ютер розміром із піщаного зерна, який може перевірити ключі на деякі зашифровані дані. Також уявіть, що він може перевірити ключ протягом часу, необхідного світлу для його перетину. Потім розгляньте кластер цих комп'ютерів, стільки, що якби ви покривали ними землю, вони покривали б всю планету на висоту 1 метр. Кластер комп'ютерів тріщить 128-бітний ключ в середньому за 1000 років ".
Аса Айерс

@ ThorbjørnRavnAndersen "Неможливо" насправді це не завищує, якщо ви користуєтесь сильною клавішею. Зараз я не можу знайти цитату, але при існуючій довжині ключів напади грубої сили є нездійсненними, "поки комп'ютери не будуть складені чимось, крім матерії, і займуть щось інше, ніж простір".
Maximillian Laumeister

72

Я б запропонував:

  • Використання fail2ban для запобігання грубій спробі входу.

  • Вимкнення входу в систему як root через SSH. Це означає, що зловмиснику довелося з'ясувати і ім’я користувача, і пароль, що ускладнює атаку.

    Додайте PermitRootLogin noдо свого /etc/ssh/sshd_config.

  • Обмеження користувачів, які можуть SSH на сервер. Або за групою, або просто конкретними користувачами.

    Додайте AllowGroups group1 group2або AllowUsers user1 user2обмежте, хто може SSH на сервер.


2
У AllowUsers і AllowGroups не приймає кому , в якості роздільника. Переконайтеся, що ви не намагаєтеся це віддалено. Я продовжую вимикатися з мого НАС, роблячи це неправильно.
невгамовний шум

4
Завжди перевіряйте,sshd чи правильно налаштовано ваш конфігурацію, перш ніж перезапустити sshd, щоб уникнути блокування з машини. Докладніше див. У цьому блозі - просто запустіть sshd -Tпісля зміни конфігурації перед перезапуском основного sshd. Крім того, відкрийте сеанс SSH на машині, коли ви вносите зміни конфігурації, і не закривайте це, поки ви не підтвердили конфігурацію, як було зазначено, і, можливо, не зробили тестовий вхід SSH.
RichVel

24

Інші відповіді забезпечують безпеку, але ви можете зробити одне, що зробить ваші журнали тихішими та зробить меншою ймовірність того, що вас заблокують із вашого облікового запису:

Перемістіть сервер з порту 22 на інший. Або у вашому шлюзі, або на сервері.

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


1
Для тих, хто вірить у безпеку через незрозумілість ( en.wikipedia.org/wiki/Security_through_obscurity ) має багато сенсу використовувати інший порт. Я не хочу ..
LassePoulsen

32
Йдеться не про безпеку через непрозорість (хоча незрозумілість може мати граничний позитивний ефект). Йдеться про зменшення фонового шуму нескінченних спроб грубої сили. Ви не можете корисно перевірити журнали відмов у доступі, якщо вони повно автоматизованих атак; fail2ban не зменшує обсяг достатньо, враховуючи кількість нападників та поширеність розповсюджених (ботнетів) та приглушених атак. З ssh на незвичному порту, ви знаєте, що атаки, які ви бачите в журналах, надходять від справжнього зловмисника, зацікавленого у вашому полі. Я настійно рекомендую.
bobince

Оскільки ви можете запитувати Інтернет-сервіси, такі як shodan, для веб-серверів ssh, або використання nmap та захоплення банерів робить зміну порту за замовчуванням майже безглуздою. Я б радив проти цього.
SLow Loris

Shodan не захоплює всі 65-портові порти, тому зміна на високий порт, ймовірно, видалить його зі свого сканування. Крім того, якщо ви перейдете до випадкового високого порту, зловмиснику, ймовірно, доведеться зробити 65K сканування TCP (дуже шумно), щоб знайти вашу службу, щоб почати атакувати на неї. І те й інше - це виграші з точки зору безпеки, тому перехід на високий порт - це загалом хороший план. Ще один варіант полягає в тому, що переходячи до високого порту, ви можете мати краще уявлення, що хтось, хто нападає на вас, орієнтується на ваші системи конкретно на відміну від просто загального фонового шуму в Інтернеті
Рорі МакКуне,

23

Увімкніть двофакторну автентифікацію за допомогою HOTP або TOTP . Це доступно з 13.10.

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

Підсумок:

  1. sudo apt-get install libpam-google-authenticator

  2. Кожен користувач запускає google-authenticatorкоманду, яка генерує ~/.google-authenticatorта допомагає їм налаштувати свої двофакторні пристрої (наприклад, додаток Google Authenticator Android).

  3. Редагувати /etc/ssh/sshd_configта встановити:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Запустіть, sudo service ssh reloadщоб забрати свої зміни до /etc/ssh/sshd_config.

  5. Відредагуйте /etc/pam.d/sshdта замініть рядок:

    @include common-auth
    

    з:

    auth required pam_google_authenticator.so
    

Детальніше про різні параметри конфігурації - це моя публікація в блозі минулого року: Краще двофакторна аутентифікація ssh на Ubuntu .


21

Зробіть IP-адресу клієнта sshd-блоку, яка не змогла надати правильну інформацію для входу, " DenyHØsts " може виконати цю роботу досить ефективно. У мене це встановлено на всіх моїх скриньках Linux, які якимось чином доступні ззовні.

Це дозволить переконатися, що силові атаки на SSHD не будуть ефективними, але пам’ятайте (!) Таким чином, ви зможете заблокувати себе, якщо забудете пароль. Це може бути проблемою на віддаленому сервері, до якого ви не маєте доступу.


2
Чи є якийсь варіант, наприклад, 10 невдалих спроб входу до заборони ip-адреси?
sayantankhan

20

Ось одна проста річ: встановити ufw ("нехитрий брандмауер") і використовувати його для обмеження обмеження кількості вхідних з'єднань.

У командному рядку введіть:

$ sudo ufw limit OpenSSH 

Якщо ufw не встановлено, зробіть це та повторіть спробу:

$ sudo aptitude install ufw 

Багато зловмисників намагаються використовувати ваш SSH-сервер для жорстокої дії паролів. Це дозволить лише 6 підключень кожні 30 секунд з однієї і тієї ж IP-адреси.


+1 Використання ліміту може бути хорошим. Однак слід зазначити, що у мене виникли проблеми при використанні вбудованого сервера sftp, оскільки він також обмежує з'єднання для цього.
Марк Девідсон

2
@Mark - хороший момент, але чи це не схоже на погано написаний клієнт SFTP? Чому б вони продовжували знову підключатися до порту SSH, коли вони могли просто відкрити більше каналів SSH?
mpontillo

12

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

  1. Встановіть Tor та встановіть сам SSH-сервер.
  2. Переконайтеся, що sshd слухає лише о localhost.
  3. Відкрити /etc/tor/torrc. Встановити HiddenServiceDir /var/lib/tor/sshі HiddenServicePort 22 127.0.0.1:22.
  4. Подивіться var/lib/tor/ssh/hostname. Є така назва, як d6frsudqtx123vxf.onion. Це адреса прихованої служби.
  5. Відкрийте $HOME/.ssh/configта додайте рядки:

    Host myhost
    HostName d6frsudqtx123vxf.onion
    ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
    

Крім того, мені потрібен Tor на місцевому господареві. Якщо він встановлений, я можу вступити, ssh myhostі SSH відкриває з'єднання через Tor. Сервер SSH з іншого боку відкриває свій порт тільки на localhost. Тож ніхто не може підключити це через "звичайний Інтернет".


10
Безпека за допомогою розширеної невідомості, але дуже цікава.
Йоганнес

8

На цю тему є стаття Debian Administration. Він охоплює основні конфігурації сервера SSH, а також правила брандмауера. Це може зацікавити також загартований сервер SSH.

Дивіться статтю: Захист доступу до SSH .


3
Трохи запізнюйтесь, але, відповідаючи на запитання, скопіюйте важливі частини зі посилання так, що якщо посилання відхиляється, інформація все ще є тут.
umop aplsdn

1
Гарна ідея. Хоча я переживаю період із значно меншим часом для участі. Моя відповідь - це "вікі спільноти", тому сміливо додайте інформацію про посилання, якщо у вас є час.
Гюйгенс

6

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

  1. Фільтрація трафіку на рівні кордону через IDS / IPS з відомими сервісними сканерами та підписами у списку блоків. Я домагаюся цього за допомогою Snort через мій брандмауер (це мій підхід, пристрій pfSense). Іноді я не можу цього зробити, як, наприклад, з моїми VPS.

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

  3. У поєднанні з моїм pfSense, або прикордонним брандмауером NAT, що працює з внутрішньою мережею та відокремлюється від Інтернету та систем, VPN-доступ лише до серверів . Маю VPN в мої мережі, щоб дістатися до серверів, оскільки немає таких портів, що стоять перед Інтернетом. Це, безумовно, не працює для всіх моїх VPS, але в поєднанні з №2, я можу мати один VPS "шлюзом" VPNing на цьому сервері, а потім дозволити його IP-адреси в інші поля. Таким чином, я точно знаю, що може чи не можна SSH в моєму одному вікні - це VPN. (Або в моїй домашній мережі позаду pfSense - моє VPN-з'єднання, і я єдиний, хто має доступ до VPN).

  4. Там, де №3 неможливо виконати, fail2ban, налаштований на блокування після 4 невдалих спроб і блокування IP-адрес протягом години або більше - це гідний захист від людей, які постійно атакують з допомогою грубої сили - просто блокуйте їх на брандмауері автоматично за допомогою fail2ban і meh. Налаштування fail2ban - це біль, хоча ...

  5. Обфузація порту шляхом зміни порту SSH. Однак це НЕ є хорошою ідеєю обійтися і без будь-яких додаткових заходів безпеки - мантра "Безпека через неприйняття безпеки" вже була спростована і оскаржена у багатьох багатьох випадках. Я це робив спільно з IDS / IPS та мережевою фільтрацією, але це все ще ДУЖЕ погано робити самостійно.

  6. ОБОВ'ЯЗКОВА Двофакторна автентифікація через двофакторні рішення Duo Security . Кожен з моїх серверів SSH на ньому налаштований Duo, так що для того, щоб навіть увійти, трапляються запити 2FA, і я повинен підтвердити кожен доступ. (Це надзвичайно корисна функція - адже навіть якщо хтось має мою парольну фразу або вривається, він не може пройти плагіни Duo PAM). Це один із найбільших захистів моїх SSH-серверів від несанкціонованого доступу - кожен вхід користувача ОБОВ'ЯЗКОВО повинен відповідати налаштованому користувачеві в Duo, і оскільки у мене обмежений набір, нові системи не можуть бути зареєстровані в системі.

Мої два центи на забезпечення SSH. Або, принаймні, мої думки про підхід.


1

Можливо, ви захочете оформити додаток FreeOTP від ​​RedHat, а не використовувати Google Authenticator. Іноді під час оновлення програми вони заблокують вас! ;-)

Якщо ви хочете використовувати інші апаратні жетони, такі як Yubikey або eToken PASS або NG, або якщо у вас є багато користувачів або багато серверів, ви можете скористатися двофакторним аутентифікацією з відкритим кодом.

Нещодавно я написав як про це .


0

Нещодавно я написав невеличкий підручник із цим. В основному, вам потрібно використовувати PKI, і в моєму підручнику також показано, як використовувати двофакторну автентифікацію для ще більшої безпеки. Навіть якщо ви не використовуєте жодне з цих речей, є також деякі підказки щодо безпеки сервера шляхом видалення слабких пакетів шифрів та інших основ. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/


0

Для великої кількості користувачів / сертифікатів врахуйте інтеграцію LDAP. Великі організації використовують LDAP як сховище для облікових даних користувачів та сертифікатів, що зберігаються на значках або fobs, незалежно від того, використовуються вони для автентифікації або підпису електронних листів. Приклади включають openLDAP, openDJ, Active Directory, Universal Oracle Directory, IBM Directory Server, snareWorks ...

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

Ось посилання на інтеграцію до centOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html


0

Ви також можете блокувати на основі країни походження за допомогою бази даних geoIP.

Якщо ви живете в США, то в Росії немає підстав підключатися до вашого SSH, тому вони будуть автоматично заблоковані.

Сценарій ви можете знайти тут: https://www.axllent.org/docs/view/ssh-geoip/

Ви також можете додати до нього команди iptables (я зробив для крапель), щоб автоматично скинути весь трафік на / з цих IP-адрес.


1
Іноді бази даних GeoIP можуть помилятися - мене запитали, чи я вчора був у Москві ... так, ні! :)
Шон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.