Насколько рискованно иметь персональный сервер с ssh, открытый в Интернет?


25

Продолжение названия будет «при ограниченных знаниях безопасности в Интернете».

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

Но теперь мне интересно, стоит ли все это усилий. Я решил настроить свой собственный сервер в основном для развлечения: я мог просто положиться на сторонние решения, такие как предлагаемые gitbucket.org, bettercodes.org и т. Д. В то время как часть забавы связана с изучением безопасности в Интернете, я не достаточно времени, чтобы посвятить его тому, чтобы стать экспертом и быть почти уверенным, что я принял правильные профилактические меры.

Чтобы решить, буду ли я продолжать играть с этим игрушечным проектом, я хотел бы знать, чем я действительно рискую при этом. Например, в какой степени другие компьютеры, подключенные к моей сети, также представляют угрозу? Некоторые из этих компьютеров используются людьми, обладающими даже меньшими знаниями, чем мой, использующий Windows.

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

Другими словами, есть ли какие-то большие плохие волки, которых я должен бояться, или это все в основном из-за того, что они прогоняют сценаристов?


Я думаю, что вы ударили ногтем по голове, когда упомянули, что у вас нет времени или желания стать экспертом в области безопасности $ TECHNOLOGY; это основная причина использования размещенного решения. Единственный другой распространенный аргумент в оценке хостинга по сравнению с хостингом - это стоимость. Поскольку github и тому подобное бесплатны, вы, по сути, тратите свое личное время только на то, чтобы получить знания о том, как запустить git-репо. Мы не можем сказать вам, что вы должны делать со своим личным временем, но в профессиональной ситуации это не имеет смысла. (предостережение emptor: сложные ситуации имеют больше переменных).
Крис С

1
Если вы решите запустить свой собственный сервер, также добавьте в свой список задач регулярную проверку обновлений и уязвимостей безопасности для каждой службы, которую вы запускаете. Просто настроить его недостаточно.
неделя

Два слова: открытые ключи, как сказал @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
Настройте аутентификацию с открытым ключом, как указано в другом ответе, и ВЫКЛЮЧИТЕ ChallengeResponseAuthentication и PasswordAuthentication в / etc / ssh / sshd_config.
Рэнди Оррисон

Я знаю, что это глупый вопрос, но мне нужно купить домен для доступа к моему серверу (через ssh или браузер) из Интернета?
TheRookierLearner

@TheRookierLearner - нет, вы можете использовать IP-адрес, предоставленный вашим провайдером. Тем не менее, в зависимости от конфигурации вашей домашней сети, через все ваши устройства он может быть разделен чем-то, называемым PNAT (большинство людей просто называют его NAT). Если вы похожи на большинство людей, вам необходимо выяснить «NAT» IP-адрес конкретного устройства, к которому вы хотите получить доступ из Интернета (просто ifconfig / ipconfig в системе, это будет 10.xxx, 172.16. адрес xx или 192.168.xx, см. RFC 1918, в котором
указывается

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/

Имейте в виду, что для правильной настройки безопасности может потребоваться общедоступный (или частично общедоступный) компьютер, который изолирован от вашей внутренней сети. Веб-сервер или любой компьютер, на котором размещены общедоступные службы, должен находиться за пределами защищенной сети вашего дома или офиса. Вы бы использовали 2 маршрутизатора для создания безопасной зоны или DMZ между вами и Интернетом.

Таким образом, если ваш сервер взломан, его нельзя использовать как вектор для атаки на другие ваши компьютеры.

Таким образом, установка будет выглядеть так:

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


Извините за маленькое изображение ... Я не могу понять, как редактировать свой пост.
TomXP411

2

Ответы очень хорошие, я бы порекомендовал только две вещи:

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