Вопросы Теги

Почему значение по умолчанию изменения ssh порт?

Удалите цветовые коды (специальные символы) с GNU sed
sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g"

Или

Разделите escape-последовательности ANSI в Python

Установите colorama пакет Python (pip install colorama). Помещенный в stripcolorcodes:

#!/usr/bin/env python
import colorama, fileinput, sys;
colorama.init(strip=True);

for line in fileinput.input():
    sys.stdout.write(line)

Выполненный chmod +x stripcolorcodes.

19
17.07.2013, 12:39
3 ответа

Наиболее вероятная причина состоит в том, чтобы мешать людям, случайным образом пробующим к грубой силе любой вход в систему SSH, который они могут найти. Моя стоящая с Интернетом машина использует порт SSH по умолчанию, и мои журналы раньше были заполнены материалом как это (извлеченный из фактического файла журнала):

sshd[16359]: Invalid user test from 92.241.180.96
sshd[16428]: Invalid user oracle from 92.241.180.96
sshd[16496]: Invalid user backup from 92.241.180.96
sshd[16556]: Invalid user ftpuser from 92.241.180.96
sshd[16612]: Invalid user nagios from 92.241.180.96
sshd[16649]: Invalid user student from 92.241.180.96
sshd[16689]: Invalid user tomcat from 92.241.180.96
sshd[16713]: Invalid user test1 from 92.241.180.96
sshd[16742]: Invalid user test from 92.241.180.96
sshd[16746]: Invalid user cyrus from 92.241.180.96
sshd[16774]: Invalid user temp from 92.241.180.96
sshd[16790]: Invalid user postgres from 92.241.180.96
sshd[16806]: Invalid user samba from 92.241.180.96

В эти дни я использую DenyHosts для блокирования дюйм/с, которым не удается пройти проверку подлинности слишком много раз, но это, вероятно, столь же легко только к портам коммутатора; фактически все атаки перебором этого вида не собираются потрудиться сканировать, чтобы видеть, слушает ли Ваш sshd на другом порте, они просто предположат, что Вы не работаете один и перемещение

27
27.01.2020, 19:44

Нет, это - безопасность с помощью тактики мрака.

Если Ваша установка sshd не достаточно пригодна стоять перед немыми деточками сценария, только пробующими порт 22, у Вас есть проблема так или иначе.

Более рациональная реакция была бы:

  • удостоверьтесь, что Ваши пользователи используют хорошие пароли, которые трудны к предположению/грубой силе
  • отключите аутентификацию по паролю (по крайней мере, для важных учетных записей) и просто используйте аутентификацию с открытым ключом
  • не упустите ssh-проблемы-безопасности и обновления

Некоторые люди могут также раздражаться шумом sshd записи в системный журнал, например:

Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth

Могло бы быть затем заманчиво затенить sshd порт или использовать автоматическое решение для блокирования (как DenyHosts, Fail2ban или BlockHosts) для увеличения отношения сигнал-шум снова.

Но лучшие альтернативы действительно существуют. Например, можно настроить демона системного журнала, таким образом, что sshd регистрируются, шум только записан в - говорят - /var/log/sshd-attempts.log и сигнал (т.е. остающиеся сообщения журнала sshd) записан в /var/log/messages и т.д. как прежде.

Развертывание автоматических инструментов блокирования нужно рассмотреть тщательно, потому что, добавляя больше сложности к безопасности соответствующие системы означают также увеличение риска эксплуатации. И действительно, за эти годы, существует несколько отчетов об уязвимости DoS для каждого DenyHosts, Fail2ban и BlockHosts.

15
27.01.2020, 19:44
  • 1
    , который я действительно не согласовываю с тот, "это - безопасность с помощью мрака", я думаю, что, тот ответ является общей ошибкой в этом случае. обоснование @Michael обычно шоу лучшая причина иметь его в другом месте. Это должно главным образом только избавиться от всех забитых нападений в виде сценария. Не обязательно означает, что Вы боитесь их или считаете это эффективным против решительного взломщика. Я знаю, что никогда не волновался, что они на самом деле войдут. но весь хлам журнала был раздражающим. –  xenoterracide 11.10.2010, 00:20
  • 2
    @xenoterracide: Если Вы только обеспокоены удобочитаемостью своих файлов журнала затем существуют другие лучшие альтернативы для исключения шума вместо того, чтобы изменить порт как тактику мрака, которая была вопросом. Относительно блокирования IP, которое не было частью вопроса: Обратите внимание на то, что добавление большей сложности к безопасности соответствующие системы означает также увеличение риска эксплуатации. Рассмотрите, напримерseclists.org/fulldisclosure/2007/Jun/121, ossec.net/main/attacking-log-analysis-tools. Да, DenyHosts был затронут этим. –  maxschlepzig 11.10.2010, 00:49
  • 3
    Существуют больше, чем просто удобочитаемость в памяти. Правильно зарегистрированное изменение порта не является безопасностью с помощью мрака. –  xenoterracide 11.10.2010, 16:44

Изменение порта SSH является главным образом театром безопасности. Это дает Вам нечеткое чувство того, что сделало что-то. Вы скрыли порт SSH под половой тряпкой.

При выполнении сервера SSH в Интернете Вы будете видеть много неудавшихся попыток входа в систему в Ваших журналах от ботов, которые ищут глупо слабые пароли, слабые ключи и известное использование в сервере более старые версии. Неудачные попытки состоят просто в том что: неудачные попытки. До оценки, насколько уязвимый Вы, они абсолютно не важны. То, о чем необходимо волноваться, является успешными попытками проникновения, и Вы не будете видеть попытки в Ваших журналах.

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

Изменение порта по умолчанию имеет главный недостаток: это делает Вас менее вероятно, чтобы смочь войти в систему из-за брандмауэра. Брандмауэры, более вероятно, пропустят сервисы на свой порт по умолчанию, чем на некоторых случайный другой порт. Если Вы не выполняете сервер HTTPS, считаете то, чтобы заставлять SSH послушать на порте 443 также (или перенаправление входящие запросы TCP от порта 443 для портирования 22), поскольку некоторые брандмауэры позволяют трафик, который они не могут декодировать на порте 443, потому что это похоже на HTTPS.

4
27.01.2020, 19:44

Теги

Похожие вопросы