Які можливі проблеми із безпекою демона SSH?


14

Я хотів би мати можливість SSH на моєму офісному ПК Ubuntu 10.04 зовні. Таким чином, я думаю запустити демон на SSH на ПК. Які проблеми із безпекою, можливі збої, конкретні параметри конфігурації тощо. Мені слід знати?

У випадку, якщо це має значення: це, по суті, лише для мого власного використання, я не думаю, що будуть користуватися іншими людьми; це комп'ютер Ubuntu 10.04 у переважно Windows 7 / Vista / XP.


1
Ви можете також розглянути можливість встановлення OpenVPN і створити тунель VPN на ПК для вашого ssh-з'єднання. Таким чином, вам не потрібно відкривати свій ssh-порт у світі.
Linker3000

@ Linker3000 Дякую! Я задумаюся --- хоча я мав досить неприємний досвід із VPN деякий час тому.
ev-br

@Zhenya Якщо ви не вкажете "@" та ім'я користувачів, вони отримають сповіщення про відповідь на них. ;) Тож ви отримаєте коментар, коли я використовую @Zhenya, але не тоді, коли я використовую @ Zhenya
BloodPhilia

@Zhenya А тепер ти робиш це знову XD
BloodPhilia

@Linker, чи можете ви трохи розібратися, чому OpenVPN є більш безпечним, ніж SSH?
Ар'ян

Відповіді:


20

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

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

  1. Використовуйте надійний пароль, що складається з щонайменше (скажімо) 10 великих і малих літер, цифр та інших символів.

  2. Користувачі в'язниці в домашній каталог. Користувачі, які потрапляють до в'язниці, не зможуть отримати доступ / редагувати файли, що знаходяться за межами домашнього каталогу. Таким чином, ваш користувач не зможе отримати доступ / редагувати ключові системні файли. Багато навчальних посібників можна знайти в Інтернеті про те, як ув’язнити користувача. Більшість з них використовує JailKit . Приклад такого підручника можна знайти тут . Крім того, ви також можете використовувати власну ChrootDirectoryдирективу OpenSSH-сервера . Приклад навчального посібника з цього питання можна знайти тут .

  3. Встановити Fail2Ban . Fail2Ban - програма, яка перевіряє журнали аутентифікації на предмет неправильних записів. Коли буде досягнуто певного обмеження, він додає блок брандмауера для цього певного IP протягом заданої кількості часу. Також в Інтернеті знайдено кілька навчальних посібників про те, як налаштувати Fail2Ban за допомогою SSH, наприклад, цей . На домашній сторінці Fail2Ban також є кілька приємних і повних HOWTO.

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

    #PermitRootLogin no
    
  5. Використовуйте нестандартний порт (напр., Не 22). Це робиться через переадресацію портів у вашому маршрутизаторі (наприклад, 16121 -> 22 замість 22 -> 22), або шляхом змушення демона SSH прослуховувати на іншому порту. Це зробить вашу службу SSH менш легкою для виявлення зловмисним користувачам. Це робиться шляхом редагування файлу /etc/ssh/sshd_config. Подивіться на наступний рядок і зміни 22 в будь-який порт , який ви хочете. Не забудьте потім переслати правильний порт у своєму маршрутизаторі.

    Port 22
    
  6. Не використовуйте паролі для входу. Крім паролів, SSH також дозволяє входити в систему за допомогою приватних ключів. Це означає, що ключ зберігається на вашому комп’ютері, на якому ви отримуєте доступ до SSH машини SSH. При спробі з'єднання клієнт SSH використовує ключ для входу на сервер замість автентифікації пароля. Ключі аутентифікації набагато сильніше криптографічно, ніж паролі, і тому їх не так просто зламати. Також в Інтернеті знайдено кілька навчальних посібників про те, як налаштувати аутентифікацію на основі ключів за допомогою SSH, наприклад, цей . (Якщо ви SSH з вікон за допомогою PuTTY, перевірте це посилання на тему HowT PuTTY.) Після встановлення аутентифікації на основі ключа ви можете відключити автентифікацію пароля, відредагувавши файл /etc/ssh/sshd_config. Знайдіть наступний рядок і переконайтеся, що перед ним немає #.

    #PasswordAuthentication no
    
  7. За бажанням, як @ Linker3000 згадував у своєму коментарі, ви можете налаштувати VPN-тунель на ПК, до якого ви хочете отримати доступ через SSH, а потім заборонити доступ до локальної мережі на сервері SSH. Таким чином, жоден зовнішній пристрій без VPN-з'єднання не зможе отримати доступ до вашого SSH-сервера. Це можна зробити, заборонивши ВСІ хости, а потім дозволити входити лише IP локальної мережі. Це робиться шляхом редагування /etc/hosts.denyта додавання наступного:

    sshd: ALL
    

    і /etc/hosts.allowдодати наступне:

    sshd: 192.168.1.*
    

    де IP відповідає цій локальній мережі. *є шаблоном, тому всі IP-адреси, що починаються з, 192.168.1.будуть прийняті. Якщо це не працює, ваш дистрибутив може використовуватись sshзамість sshd. У такому випадку вам слід спробувати ssh: 192.168.1.*і ssh: ALLзамість цього.

  8. Ви можете дозволити лише певні хости, робити те саме з пунктом 6 /etc/hosts.allowта /etc/hosts.denyяк описано в 6, але /etc/hosts.allowдодайте наступний рядок і кожен хост, щоб дозволити розділені пробілами:

    sshd: {IP OF HOST TO ALLOW 1} {IP OF HOST TO ALLOW 2} {IP OF HOST TO ALLOW 3} {ETC.}
    
  9. Дозволити доступ до вашого SSH-сервера лише конкретним користувачам. Це робиться шляхом редагування файлу /etc/ssh/sshd_config. Подивіться на наступний рядок і переконайтеся , що немає # перед ним. Якщо його не існує, створіть його. Наприклад, якщо ви хочете дозволити лише Джон, Том і Маррі, додайте / редагуйте цей рядок:

    AllowUsers john tom mary
    

    Ви також можете заборонити конкретним користувачам, наприклад, якщо ви хочете заборонити доступ до John, Tom і Mary, додайте / редагуйте цей рядок:

    DenyUsers john tom mary
    
  10. Дозволити протокол SSH2 для вхідних з'єднань. Існує дві версії протоколу SSH. SSH1 є предметом проблем безпеки, тому використання SSH 2 рекомендується. Це можна примусити відредагувати файл /etc/ssh/sshd_config. Подивіться на наступний рядок і переконайтеся , що немає # перед ним. Якщо його не існує, створіть його.

    Protocol 2,1
    

    видаліть, 1, так що лінія буде

    Protocol 2
    
  11. Не дозволяйте користувачам входити в систему, у яких не встановлено пароль. Це можна примусити відредагувати файл /etc/ssh/sshd_config. Подивіться на наступний рядок і переконайтеся , що немає # перед ним. Якщо його не існує, створіть його.

    PermitEmptyPasswords no
    
  12. І хоча просто і, мабуть, не потрібно говорити, але в багатьох випадках виявляється вирішальним, оновлюйте своє програмне забезпечення. Регулярно оновлюйте встановлені пакети / програмне забезпечення.


= відредагувавши конфігураційний файл SSH, не забудьте перезапустити демон, щоб застосувати зміни. Перезапустіть демон, виконавши:

sudo /etc/init.d/ssh restart

або

sudo /etc/init.d/sshd restart

залежно від того, який дистрибутив Linux ви використовуєте.


2
sudo service ssh restartна Ubuntu.
ulidtko

@ulidtko Це питання було об'єднано з більш загальним питанням, тому я зробив свою відповідь більш загальною та придатною для різних розповсюджень. Це буде працювати майже на всіх дистрибутивах, але ви праві.
BloodPhilia

@BloodPhilia Дякую чимало за таку детальну та доступну відповідь! Ще кілька запитань щодо ваших питань: 1. Яка перевага ув'язнення користувачів у тому, щоб лише обмежити дозволи? Скажімо, увійшовши як "користувач", я маю доступ лише для читання до речей поза моїм / домашнім доступом, але жодного запису не пишуть чи не виконують [відповідно до стандартних умов Ubuntu]. Це краще / гірше, ніж в'язниця? 2. Де зазвичай розташовані журнали аутентифікації? Мені б хотілося раз у раз оглянути їх вручну / через grep.
ev-br

@BloodPhilia 4. Якщо я змушу sshd прослуховувати нестандартний порт на сервері, наприклад 1234, то який спосіб підключення до цього сервера з командного рядка Linux на клієнті? Я маю на увазі, чи потрібна стандартна команда ssh якийсь комутатор?
ev-br

1
@ulidtko: З Upstart, sudo restart ssh.
Привіт71

7

Кілька порад:

  1. Використовуйте аутентифікацію на основі ключа, яка є НАЙКРАЩО безпечнішою за паролі
  2. Тільки SSH 2
  3. Вимкнути кореневі входи
  4. Для параноїка змініть порт зі стандартного порту 22
  5. Для зручності використовуйте інструмент для зіставлення вашого IP-адреси на ім'я DNS, як-от Dyndns або його ilk. Ви можете їхати довго з тим самим IP, але коли ви подорожуєте та потребуєте, ви побачите, що вам видали новий.
  6. Звичайно, дозвольте лише через порт, необхідний для SSH (порт 22, або нестандартний, якщо ви вибрали) через брандмауер.

1
Re 5: Якщо у вас є електронна пошта на машині поза вашим домом, ви можете налаштувати cron, щоб періодично надсилати повідомлення з вашої домашньої машини на цю адресу. Ваш домашній IP буде в заголовках. Не так зручно, як DNS, але зручно використовувати.
garyjohn

Ви також можете зв’язатися зі своїм провайдером і попросити ціну статичної IP-адреси. Це далеко не найпростіше рішення з усіх, але зазвичай дорожче, ніж динамічний DNS
Steen Schütt

2

Основний ризик - це забути, що ви запускаєте ssh-сервер і вводите слабкий пароль в обліковий запис. Там є зловмисники, які систематично пробують загальні імена облікових записів (як-от webmasterі bob) та слабкі паролі. Ви можете усунути цей ризик, забороняючи пароль логін (покласти PasswordAuthentication noв sshd_config, і або також ставити UsePAM Noабо відключити аутентифікацію пароля в налаштуваннях PAM для SSH). Проміжним заходом є обмеження входу ssh до білого списку користувачів з AllowUsersабо AllowGroupsв sshd_config.

Зауважте, що дозвіл на вхід пароля сам по собі не є проблемою безпеки. Слабкі паролі та відкладені паролі - це проблеми, і дозволити автентифікацію паролів на ssh-сервері є чинником. Для захисту від прослуховування пароля ніколи не вводьте свій пароль на машині, якій ви не повністю довіряєте (але тоді, якщо ви довіряєте машині, ви можете також встановити на ній приватний ключ, і тоді вам не потрібно автентифікацію пароля).

Мінімальна вимога для використання ssh-клієнта на машині полягає в тому, що ви довіряєте, що не буде активного викрадення ssh-зв’язку (атака "людина-в-середині" можлива, якщо вона працює на клієнтській машині - ви думаєте ви вводите команди у незайманий ssh-клієнт, але клієнт насправді передає ваші дані автентифікації сумлінно, але також вставляє троянську коня в комунікацію після цього). Це слабша вимога, ніж довіряти, там не буде снупер паролів (зазвичай це виконується через кейлоггер, але є й інші менш автоматизовані методи, наприклад, плечове серфінг). Якщо у вас є мінімальна довіра, але ви все ще боїтеся снуперів, ви можете використовувати одноразові паролі (OpenSSH підтримує їх через підтримку PAM).

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


2

Три речі мені натрапили:

  1. Якщо ви відкриєте порт 22 за замовчуванням, то досить скоро він буде виявлений, і ваш комп'ютер буде забитий грубими атаками. Я пропоную вам налаштувати sshd для прослуховування якогось іншого порту або зробити зіставлення портів на брандмауері. Хоча це не чарівна куля, вона, безумовно, збереже вам хоча б ті самі цикли процесора.

    Порт 12345

  2. Явно відключити автентифікацію пароля та використовувати лише ключі. Будь-який ключ буде кращим, ніж найскладніший пароль, який ви можете запам'ятати.

    Аутентифікація пароля немає

  3. Навіть незважаючи на те, що Ubuntu за замовчуванням відключений користувач root, явно відключити кореневий вхід

    PermitRootLogin немає

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.