обеспечение SSH и отключение прямого корня

Это похоже на отказ, к сожалению, находится в демоне, который не сбрасывает, это - stdout после записи данных логов.

svlogd действительно только выравнивает буферизацию, таким образом, это производит полные строки к файлу журнала, как только они прибывают в stdin.

0
28.11.2012, 00:30
4 ответа

OpenSSH следует, "прокомментировал значения по умолчанию" политика. Это означает, что конфигурационный файл (в масштабе всей системы) содержит наиболее доступные варианты, которые - если не прокомментированный - имел бы то же значение как значения по умолчанию приложения, которые соединены проводами в фактические исполняемые двоичные файлы. С тех пор некоторое время назад, значение по умолчанию Protocol устанавливание значения было изменено от 2, 1 кому: 2 только. Следовательно инструкции на основе более старых выпусков не применяются буквально сегодня. Другая вещь рассмотреть, как конкретное распределение изменяет файл в их пакете.

Что касается настроек:

  • если Вы не используете древние приложения, сохранить Protocol набор только к 2 - как часто, если Вы не знаете то, что это означает, сохраните значения по умолчанию;

  • изменение порта не имеет большого смысла, если Вы только не имеете некоторые порты в наличии из-за ограничений, установленных на Вас сетью, Вы идете. Это определенно не мера по усилению безопасности.

  • предотвращение прямого корневого доступа является хорошей идеей. Можно также хотеть отключить логины пароля и использовать только аутентификацию с закрытым ключом, так как это намного более трудно (читайте невозможный) повреждаться грубой силой. Это может также эффективно создать две аутентификации уровня для корневого доступа (сначала закрытый ключ для входа в систему и затем пароль к su или sudo). С другой стороны, Вы не смогли бы войти в систему без ключа (который может создать серьезную проблему в некоторых ситуациях).

  • привязка к определенному адресу не имеет большого смысла, если Вы действительно не хотите служить ему только один сетевой интерфейс. Снова - если Вы не уверены, не изменяйте его. На машине, которая имеет динамический IP-адрес, он мог даже вызвать временную недоступность сервиса.

2
28.01.2020, 02:28
  • 1
    Это - очень полезная информация, спасибо. –  freja 28.11.2012, 01:20

Я не уверен, понял ли я действительно Ваш вопрос, тем не менее, вот ключевые мысли, которые я понял:

  • Порядок записей конфигурации в файле конфигурации не важен. Вот почему Вы регистрируете, мог бы иметь другое расположение затем то в инструкциях, которые Вы имеете. Необходимо просто удостовериться, что Вы только используете каждый параметр однажды в файле.
  • Как @Mark указанный, это - вопрос Вашей среды, можно ли пойти с протоколом 2 только. Если Вы хотите включить версию 1 и 2, строка должна читать Protocol 1,2
  • Изменение порта является вопросом вкуса (или конвенция, в некоторых случаях) и не увеличивает безопасность: взломщик может легко сделать сканирование портов для выяснения, которые портируют SSHD, работает. (Ну, можно предотвратить portscanning до некоторой степени, но это - просто вопрос времени и ресурсы для квалифицированного взломщика для обнаружения.)
  • Разрешение root логины являются проблемой безопасности: Вы только разрешаете имя пользователя, которое все знают (таким образом, взломщик может сфокусировать на принуждении скота пароль для того допустимого имени пользователя), но также и в одну учетную запись, которая является самой разрешающей. Если нет серьезные основания, я предложил бы PermitRootLogin no и затем также su или sudo, В зависимости от Вашей политики.
  • sudo требует, чтобы пользователь ввел ее собственный пароль снова, в то время как su просит rootпароль. Различие - это su на самом деле открывает a root оболочка для пользователя, где он root. sudo позволяет пользователю выполнять определенные команды как root. Безопасное sudo конфигурация является вопросом опыта (например, если Вы позволяете пользователям работать bash как root, Вы в основном позволяете root доступ к каждому sudoer), таким образом, sudo не увеличивает безопасность путем простого включения его.
  • Привязка SSHD к определенному IP-адресу через ListenAddress только полезно на хостах, которые подключены к нескольким сетям. В таких системах существует усиление безопасности при ограничении доступа SSH к тем сетям, от которых Вы требуете доступа SSH.
1
28.01.2020, 02:28
  • 1
    Право, я должен буду действительно читать больше о sudo. Мое обоснование сказало мне, что должно было быть больше к нему, чем просто свопинг поддерживает sudo, и я думаю, что самый безопасный путь с ключом и паролем. Однако я не буду работать с другими людьми и так в меньшем количестве риска социальной инженерии плюс никогда пароли хранилища на моем компьютере. Спасибо очень. –  freja 28.11.2012, 01:24

Только имейте частичные ответы и предложения.

Из комментариев и моего собственного sshd файла конфигурации на ubuntu 10.04 I предложил бы, чтобы Вы пошли с Протоколом 2. Если у Вас нет legacy/slighly ssh клиентов старшего возраста.

ListenAddress связывает ssh демона с определенным интерфейсом (соответствие IP). Отъезд его как 0.0.0.0 свяжет со всеми интерфейсами (не только внешний, но также и localhost/loopback), тогда как определение IP-адреса свяжет его с тем единственным интерфейсом.

PermitRootLogin не будет подразумевать, что Вы не можете использовать корень для входа в систему по ssh. В то время как Вы зарегистрированы, можно все еще переключиться на пользователя root, хотя я думал бы, что лучшая практика должна использовать sudo.

Изменение Порта, очевидно, изменится, порт ssh слушает на. Я не уверен, откуда Вы получили диапазон доступных портов. Некоторые порты резервируются, см. http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers для обширного списка. номера портов могут подойти 65535, и действительно порты выше 1024 являются справедливой игрой, пока Вы знаете, что ничего не ударяете.

Надежда, которая помогает!

Mark

0
28.01.2020, 02:28
  • 1
    Mark Спасибо, таким образом, Вы удалили бы все выше Протокола 2, имеющего отношение к протоколу 1? Далее вниз файл там является ссылками на протокол 1 также. Также я собирался удалить строку '#AddressFAmily какое-либо' рассмотрение, что ListenAddress будет моим IP - который имеет смысл? –  freja 27.11.2012, 08:46
  • 2
    я склонен оставлять вещи в файлах конфигурации и комментировать их, а не удалять их. Просто персональное предпочтение. Как уже существует '#', символ перед ним это не имеет никакого значения как прокомментированного. –  Mark Underwood 27.11.2012, 11:15

Порядок строк в sshd_config не важно, за исключением одной вещи: каждая строка, которая начинается со слова Match запускает новый раздел, и расположение этих разделов важно.

Строки, которые начинаются # комментируются: они проигнорированы. Можно видеть их в конфигурационном файле по умолчанию как примеры вещей, которые Вы могли записать, хотели ли Вы. Вы не должны комментировать строку для изменения настроек, можно записать дополнительные строки, как Вы желаете.

Например, #Port 22 есть ли, потому что порт по умолчанию равняется 22. Если Вы удаляете # символ, Вы явно установите порт на 22, который ничего на самом деле не изменяет. Если Вы удаляете # и измените число, это заставит сервер SSH слушать на другом порте. Можно также оставить закомментированную строку в покое (если она присутствует вообще), и записать Port 1234 на отдельной строке.

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

Наличие Protocol 2 хорошая идея, если Вы не знаете, что хотите смочь использовать чрезвычайно старые клиенты.

ListenAddress только полезно для определенных конфигураций, где Вы хотите, чтобы сервер SSH послушал только на одной сетевой плате. Вам не нужен он.

PermitRootLogin no обычно хорошая идея, но это не абсолютная легкая задача, которой некоторые люди разбирают его, чтобы быть. Это только предоставляет прямое преимущество безопасности, если Ваш пароль root слаб или пропущен (не хорошая идея) или если Вы позволяете корню входить в систему со слабым или пропустили ключ (так же). Если корень не может войти в систему непосредственно, это означает, что пользователи должны сначала войти в систему со своей собственной учетной записью. Это хорошо для отслеживаемости, для знания то, что произошло после факта, когда законные пользователи вошли в систему. В большинстве установок злонамеренные пользователи могут изменить журналы после факта, таким образом, дополнительный шаг, который они сделали, не будет видим.

Другая общая стабилизирующая установка должна потребовать, чтобы пользователи использовали пары ключей вместо паролей для аутентификации, т.е. отключили аутентификацию по паролю:

PasswordAuthentication no

Необходимо только уехать, аутентификация по паролю позволила если:

  • все Ваши пользователи могут быть доверены для выбора сильных паролей; и
  • всем Вашим пользователям нельзя доверять, чтобы никогда войти в систему от доверяемых машин (где они уверены, что нет никакого клавиатурного перехватчика и т.п.).
0
28.01.2020, 02:28
  • 1
    Хорошо, кажется, что я ничем не побеспокою кроме того, что имеет отношение к паролям root и паролям пользователя в этом файле. Когда Вы говорите, что пользователям можно доверять, Вы имеете в виду пользователей сайта не права администратора? Очевидно, пользователям сайта нельзя доверять, но если бы Вы означаете других возможных пользователей управлять затем, что я оставил бы это в покое. Интересный Вы все опровергаете то, что много учебных руководств требуют для безопасности, но Ваши объяснения имеют смысл.Спасибо. –  freja 28.11.2012, 04:05
  • 2
    @freja пользователи здесь является теми с учетной записью Unix (не посетители веб-сайта или что-либо как этот). –  Gilles 'SO- stop being evil' 28.11.2012, 12:17

Теги

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