Команда IT специалистов выполнит подготовку инфраструктуры для вашего бизнеса.
Внедрение самых передовых решений и технологий.
Поддержка и сопровождение ваших сервисов.
Выполнение работ под "ключ", от покупки сервера, до настройки автоматизации процессов.
8(977)608-78-62 adm@nixm.ru

защищённость SSH сессии

Ответить
Olej

защищённость SSH сессии

Сообщение Olej »

Есть несколько мелочей, возникающих при разборках с обеспечением защищённости SSH сессии от внешних придурков (читай "доморощенных хакеров"). Вопросы относительно параметров конфигурирования sshd сервера.
Вопросы выпишу ниже отдельными сообщениями, чтобы не сваливать всё в кучу.
Может кто сталкивался и может подсказать что-то внятное...
Olej

Re: защищённость SSH сессии

Сообщение Olej »

При неверной авторизации, вводе неправильного пароля (попытках подбора) сессия SSH прерывается после N=3 неверных попыток.

1. Откуда взялась эта цифра 3?

2. Как изменить число ошибочных попыток перед обрывом сессии? (например, на 1 :D )
Этот вопрос встречается в обсуждениях на разных рсурсах... но на него есть "бла-бла-бла", но корректных ответов нет.
Указывается параметр MaxAuthTries в конфиге /etc/ssh/sshd_config
... sshd_config (5) (перевод мой ;) ):
Максимальное число попыток аутентификации, разрешенных на подключение. Как только количество отказов достигает половины этого значения, дополнительные отказы регистрируются. Значение по умолчанию - 6.
Но это не работает:
- число неудачных попыток на сессию всё равно 3 (при изменении MaxAuthTries и перезапуске sshd);
- неудачные попытки логируются с самого начала, с 1-й... правда я смотрел это в новой системе логирования journal

Код: Выделить всё

[olej@dell home]$ journalctl --since="2017-01-24 15:30" | grep sshd
...
3. Утверждается, что это параметр новый, появился с версии 5.Х с чем-то, лет 2-3 назад...
Но в современных дистрибутивах уже что-то типа:

Код: Выделить всё

[olej@dell home]$ ssh -V
OpenSSH_7.2p2, OpenSSL 1.0.2j-fips  26 Sep 2016
(да и те, кто попадался на старую версию, пишут что получают на такой параметр явную ошибку)
Последний раз редактировалось Olej 25 янв 2017, 12:57, всего редактировалось 2 раза.
Olej

Re: защищённость SSH сессии

Сообщение Olej »

Ещё один параметр /etc/ssh/sshd_config - MaxStartups :
Определяет максимальное число одновременных неавторизованных подключений к демону sshd. Дополнительные подключения будут отвергнуты до тех пор, пока не будет произведена аутентификация или не истечет LoginGraceTime для соединения. Значение по умолчанию 10.
Как альтернатива может быть задействован ранний произвольный сброс путем указания трех разделенных через двоеточие значений ``старт:норма:полная'' (т.е., "10:30:60"). sshd отвергнет соединение с вероятностью ``норма/100'' (30%) если имеется ``старт'' (10) неавторизованных соединений. Вероятность возрастает линейно и все попытки соединения будут отвергнуты при достижении числа неавторизованных соединений значения ``полная'' (60).
Иногда утверждается, что этот параметр стоит переопределить, предлагается так:

Код: Выделить всё

MaxStartups 2:70:10
5. В чём сермяжная правда "вероятности" (70) в определении такого параметра?
Как это должно работать?
Последний раз редактировалось Olej 25 янв 2017, 17:24, всего редактировалось 1 раз.
HorekRediskovich
Разговорчивый гость
Разговорчивый гость
Сообщения: 20
Зарегистрирован: 26 янв 2016, 15:28
Откуда: Украина

Re: защищённость SSH сессии

Сообщение HorekRediskovich »

То есть и после перезагрузки демона число попыток неверной авторизации не ограничивается? :?
Olej

Re: защищённость SSH сессии

Сообщение Olej »

HorekRediskovich писал(а):То есть и после перезагрузки демона число попыток неверной авторизации не ограничивается? :?
Не о том речь.
Оно не изменяется, и остаётся 3.
(вы попробуйте)
Откуда вообще взялась эта цифра 3?
Olej

Re: защищённость SSH сессии

Сообщение Olej »

И это ещё не все вопросы ... непонятки:

5. SSH - весьма старая подсистема, работающая практически во всех UNIX-like системах.
А Linux достаточно быстро эволюционирует и меняется ...
Вот MaxAuthTries - новый параметр ... в man ни Solaris, ни FreeBSD его нет (по крайней мере в публикуемых man, а вживую мне посмотреть сейчас негде).
Вот и вопрос: все замечания в документации относительно логирования событий SSH - они к какой системе логирования относятся, т.к. в большинстве систем Linux на сегодня работают 2 лога: *logd + journal :

Код: Выделить всё

[olej@dell 13]$ ps -A | grep logd
  987 ?        00:00:00 rsyslogd

[olej@dell 13]$ ps -A | grep journ
  528 ?        00:00:03 systemd-journal
 1144 ?        00:00:00 abrt-dump-journ
 1145 ?        00:00:00 abrt-dump-journ
А для SSH логирование - одна из важнейших возможностей, и логи эти должны тщательно анализироваться.
Olej

Re: защищённость SSH сессии

Сообщение Olej »

Olej писал(а): 1. Откуда взялась эта цифра 3?

2. Как изменить число ошибочных попыток перед обрывом сессии? (например, на 1 :D )
С этим ... отчасти подсказали, чем подтолкнули на эксперименты ... разобрались.
3 попытки ограничивает не сервер, а SSH-клиент:

Код: Выделить всё

[olej@dell IDE]$ man 5 ssh_config
...
NumberOfPasswordPrompts
Specifies the number of password prompts before giving up.  The argument to this keyword must be an integer.  The default is 3.
Вот один из моих тестовых придурков ломится при значении 6:

Код: Выделить всё

[stupid@dell ~]$ ssh stupid@localhost
stupid@localhost's password: 
Permission denied, please try again.
stupid@localhost's password: 
Permission denied, please try again.
stupid@localhost's password: 
Permission denied, please try again.
stupid@localhost's password: 
Permission denied, please try again.
stupid@localhost's password: 
Permission denied, please try again.
stupid@localhost's password: 
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
А MaxAuthTries ограничивает число попыток со стороны сервера:

Код: Выделить всё

[root@dell ssh]# cat /etc/ssh/sshd_config | grep MaxAuthTries
MaxAuthTries 4
[root@dell ssh]# service sshd restart
Redirecting to /bin/systemctl restart  sshd.service
Вот 2-й мой тестовый придурок пытается вломиться:

Код: Выделить всё

[freak@dell ~]$ ssh freak@localhost
freak@localhost's password: 
Permission denied, please try again.
freak@localhost's password: 
Permission denied, please try again.
freak@localhost's password: 
Permission denied, please try again.
freak@localhost's password: 
Received disconnect from 127.0.0.1 port 22:2: Too many authentication failures
Connection to localhost closed by remote host.
Connection to localhost closed.
Обратите внимание - сообщение отлупа получаем разные!

Надеюсь, это кому-то ещё может пригодиться ... так много букав писал :)
HorekRediskovich
Разговорчивый гость
Разговорчивый гость
Сообщения: 20
Зарегистрирован: 26 янв 2016, 15:28
Откуда: Украина

Re: защищённость SSH сессии

Сообщение HorekRediskovich »

Эм полезная информация, ток вот я не понял для того что бы 3 попытки или 6 это надо и в конфиге сервера и клиента задавать одинаковые значения? а если они разные допустим на клиенте 3 а на сервере 6 то чьё значение будет в приоритете?

З.ы. под рукой сейчас нет просто linux, так бы сам проверил и помог в экспериментах, вот и задаю такие глупые вопросы :sorry:
Olej

Re: защищённость SSH сессии

Сообщение Olej »

HorekRediskovich писал(а):Эм полезная информация, ток вот я не понял для того что бы 3 попытки или 6 это надо и в конфиге сервера и клиента задавать одинаковые значения? а если они разные допустим на клиенте 3 а на сервере 6 то чьё значение будет в приоритете?
Клиент независимо прекращает попытки в зависимости от своих настроек. Разные клиенты могут иметь совершенно разные настройки. Говорят, что putty из Windows делает 5 попыток авторизации... но тут я ничего не могу сказать. Ограничение со стороны клиента - это вопрос, скорее, удобства.

Сервер независимо ни от чего разрывает соединение при превышения указанного ему числа попыток. Это надёжное ограничение. Ограничивать попытки враждебного вторжения нужно именно с этой стороны.

Но есть ещё более радикальное решение: при превышении установленного числа попыток подключения к серверу, доступ для клиента (либо его IP, либо его имени) запрещается ... либо на достаточно продолжительный тайм-аут (10 мин., 3 часа, 1 день), либо вообще навсегда.
Ответить

Вернуться в «Сети. Настройка и администрирование»