Наскільки ризиковано відкрити персональний сервер з ssh, відкритим до Інтернету?


25

Продовженням заголовку буде "маючи обмежені знання про Інтернет-безпеку".

Нещодавно я створив невеликий сервер з комп’ютером низького рівня, на якому працює debian з метою використання його як особистого сховища git. Я ввімкнув ssh і був дуже здивований оперативністю, при якій він зазнав грубих атак тощо. Потім я прочитав, що це досить часто, і дізнався про основні заходи безпеки для запобігання цих атак (з цим вирішується багато питань і дублікатів на сервері за замовчуванням, див., Наприклад, цей чи цей ).

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

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

Яка ймовірність того, що я потрапляю у справжню проблему, якщо дотримуватимуся основних вказівок, таких як надійний пароль, відключений кореневий доступ до ssh, нестандартний порт для ssh та, можливо, відключення входу пароля та використання одного з правил fail2ban, denyhosts або iptables?

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


Я думаю, що ти вдарив цвях по голові, коли ти згадав, що у тебе немає часу або нахилу стати експертом у галузі безпеки $ TECHNOLOGY; це головна причина використання розміщеного рішення. Єдиний інший поширений аргумент для оцінки внутрішнього та проти хостингу - це вартість. Оскільки github та подібні є безкоштовними, ви, по суті, відмовляєтесь від особистого часу лише для того, щоб отримати знання про те, як запустити git repo. Ми не можемо сказати тобі, що ти повинен робити зі своїм особистим часом, але в професійній ситуації це не має сенсу. (запобіжний емптор: складні ситуації мають більше змінних).
Chris S

1
Якщо ви вирішили запустити власний сервер, також додайте до свого списку todo регулярну перевірку наявності оновлень та вразливості безпеки для кожної запущеної послуги. Просто встановити його недостатньо.
тиждень

Два слова: відкриті ключі, як сказав @Stephane. Вимкнути keyboard-interactiveавтентифікацію та використовувати лише pubkeyавтентифікацію.
kostix

Відповіді:


14

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

У мене люди час від часу потрапляли на домашній сервер SSH (відкрито до Time Warner Cable). Ніколи не мав фактичного впливу.

Деякі додаткові речі, які ви можете зробити, щоб зробити SSH більш безпечним, - це запобігати повторним спробам з однієї і тієї ж IP-адреси домашньої машини чимось на кшталт

MaxStartups 2:30:10

в / etc / ssh / sshd_config, що обмежить кількість підключень, які можна створити підряд, перш ніж успішно входити в систему.


Мій постачальник послуг Інтернету надає брандмауер, параметри якого я бачив під час відкриття порту для ssh. Це те, на що ви посилаєтесь?
Альфред М.

2
Можливо, деякі провайдери надають вам німий пристрій, деякі маршрутизатор із вбудованим брандмауером. Я просто кажу, що НІКОЛИ не годиться розміщувати ОС загального призначення безпосередньо в Інтернеті, незалежно від того, які обережні заходи ви вживаєте. Ви хочете, щоб якийсь апаратний пристрій (або щось на зразок DD-WRT) між вами та бридким.
TheFiddlerWins

1
Налаштуйте автентифікацію відкритого ключа, як згадується в іншій відповіді, і TURN OFF ChallengeResponseAuthentication та PasswordAuthentication в / etc / ssh / sshd_config.
Ренді Оррісон

Я знаю, що це дурне питання, але чи потрібно купувати домен для доступу до свого сервера (через ssh чи браузер) з Інтернету?
TheRookierLearner

@TheRookierLearner - ні, ви можете використовувати IP-адресу, яку надає ваш провайдер. Однак, залежно від конфігурації вашої домашньої мережі, можна ділитися через усі ваші пристрої чимось під назвою PNAT (більшість людей просто називають це NAT). Якщо ви схожі на більшість людей, вам потрібно буде з'ясувати "NATED" IP-адресу конкретного пристрою, до якого ви хочете отримати доступ з Інтернету (просто якщо ifconfig / ipconfig в системі, це буде 10.xxx, 172.16. xx або 192.168.xx адреса див. RFC 1918 більше, ніж ти переймаєшся цими номерами), а потім скажи маршрутизатору "порт вперед" або "DMZ" порт 22.
TheFiddlerWins

10

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

Якщо ви змусите все SSH-з'єднання використовувати його, то це зробить вашу систему настільки ж стійкою, наскільки ви можете сподіватися, не вкладаючи ЛОТ в інфраструктуру безпеки. Чесно кажучи, це настільки просто і ефективно (якщо у вас немає 200 акаунтів - тоді він стає безладним), що не використовувати його має бути публічним правопорушенням.


3
Щоб змусити SSH-з'єднання використовувати автентифікацію відкритого ключа після його встановлення, переконайтесь, що ВИМКНЕНО ChallengeResponseAuthentication та PasswordAuthentication в / etc / ssh / sshd_config. Я забув це колись, на превеликий жаль (лише один раз, і ніколи більше).
Ренді Оррісон

8

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

TheFiddlerWins вже вирішує основні наслідки безпеки відкриття SSH на загальнодоступному IP- адресі , але найкращим інструментом IMO у відповідь на спроби грубої сили є Fail2Ban - програмне забезпечення, яке контролює ваші файли журналу аутентифікації, виявляє спроби вторгнення та додає правила брандмауера. Місцевий iptablesбрандмауер машини. Ви можете налаштувати як кількість спроб до заборони, так і тривалість заборони (за замовчуванням - 10 днів).


Як було сказано в моєму коментарі до попереднього допису, це те, що мій NAS використовує вдома, і через пару місяців кількість спроб значно знизилася.
mveroone

2

Ще один спосіб вирішити це - налаштувати VPN. Замість того, щоб підключатися безпосередньо до портів SSH на домашньому сервері, ви спочатку підключаєтесь до VPN, а потім запускаєте весь свій трафік через зашифроване безпечне з'єднання.

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

Ось приклад:

http://www.howtogeek.com/135996/

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

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

Отже, налаштування виглядатиме так:

Конфігурація DMZ


Вибачте за маленьке зображення ... Я не можу зрозуміти, як відредагувати свою публікацію.
TomXP411

2

Відповіді дуже хороші, я б рекомендував лише дві речі:

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