Потенциально угнанная сессия SSH & лучшие практики SSH


14

Я немного волнуюсь в данный момент. Я SSHing на удаленный сервер, который я недавно ввел в эксплуатацию. Я делаю это как root. Я установил fail2ban и имел огромное количество забаненных IP-адресов в журнале.

В прошлый раз, когда я вошел в систему, я заметил, что мой терминал действительно зависает, а затем интернет-соединение оборвалось. Когда я купил его обратно примерно через 5 минут, я снова вошел на сервер и сделал «кто» и понял, что вошли два пользователя root. Я мог бы подумать, что, если бы мое соединение прервало процесс с последнего сеанса, это было бы остановился на сервере?

Соединение завершилось сообщением «Ошибка записи: сломанный канал», когда я впервые отключился. Я убил сессию Bash с другим рутом. Я не очень разбираюсь в безопасности ssh, однако можно ли захватывать сессии? Есть ли способ проверить это? Мне нужно продолжить вход через ssh, какие меры предосторожности следует предпринять? Если бы я каким-то образом проходил через прокси, чтобы добраться до моего сервера (как человек, находящийся в середине атаки), могли бы они перехватить мою сессию ssh?

Ответы:


40

Корневые логины - это, вероятно, висящие сеансы оболочки, которые когда-то были вами. Ваш сервер также, вероятно, получает dDOS'd со всеми попытками входа в систему.

Блокировка SSH. Не разрешайте вход в систему с правами root, и те запросы, которые пытаются грубо форсировать эту машину, сразу же завершатся неудачей (потребляя гораздо меньше ресурсов). Войдите в систему как обычный пользователь и увеличьте права доступа через него sudo, в любом случае вы должны выполнять эту практику. Также ограничьте вход в SSH списком IP-адресов клиентов, чтобы сомнительные машины не могли даже попытаться войти в систему.

Используйте ключи SSH вместо паролей для входа пользователя. С ними легче иметь дело, и они могут быть защищены паролем сами в случае, если вы случайно отдадите закрытый ключ в неправильное место (давая вам время заменить их и лишить законной силы старый). Как упомянуто в комментариях @EEAA, вы также должны отключить аутентификацию на основе пароля, если хотите ограничить использование только ключей вместо паролей и ключей.

Если монгольские кланы продолжают избивать вашу городскую стену, возможно, переместите SSH в другой высокий порт (менее 1024, как указывал @AustinBurke - чтобы использовать привилегированный порт) вместо 22. Это уменьшит трафик на этом порту, если это это проблема для вас (и большинство ботов не очень изящны, поэтому они будут пытаться только 22). Это не остановит попытки попробовать порт 22 или даже сканировать вашу машину, чтобы увидеть, какой порт прослушивает SSH, и в большинстве случаев это ненужное неудобство. Но это может помочь.

Другие могут дать больше советов, но это довольно общие меры безопасности для публичного SSH-сервера.


22
Использование ключей недостаточно. Нужно также отключить аутентификацию по паролю.
EEAA

4
@marcelm Разве « огромное количество забаненных IP-адресов в журнале » не намекает на то, что это может происходить?
TripeHound

4
@ tripehound Нет, это не так. Это ничего не говорит об относительных потребляемых ресурсах.
17

3
Это является намеком на этот эффект , хотя, @marcelm.
Легкость гонки с Моникой

4
Хотя это возможно в этой вселенной, ssh чертовски безопасен. Конечно, вы можете захватить этот трафик в полете и сохранить его в зашифрованном состоянии, но для установления зашифрованного канала используется обмен ключами Диффи-Хеллмана. Взломать это даже невозможно, если у вас есть как закрытый, так и открытый ключ ssh, который использовался для аутентификации, поскольку ключ потока никогда не передавался во время сеанса. К тому времени, когда кто-то взломает этот поток, мы все умрем.
шпульницы
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.