Как я могу ограничить доступ SSH, когда исходный IP является динамичным
Если домен имеет групповую политику, это могло бы потенциально изменить членов пользователей в локальном администраторе и группе продвинутых пользователей..... или даже добавить в новых пользователях. Но существующие пользователи на локальной машине останутся незатронутыми.
Я рекомендовал бы терять ограничение IP и потребовал бы, чтобы и ключ базирующаяся и основанная на пароле аутентификация вошел в систему. Я думаю, что это получило бы Вас лучшая безопасность в конце, и затем Вы не должны будете волноваться о динамическом дюйм/с.
Вы могли бы хотеть полагать, что порт, пробивающий http://en.wikipedia.org/wiki/Port_knocking и http://www.zeroflux.org/projects/knock, позволяет открытие определенного динамического дюйм/с на ограниченный срок и отмену их позже.
Я не использовал этот метод лично, но на сайте существуют некоторые красивые примеры.
Сколько штата с динамическим дюйм/с? Если небольшое число, Вы могли бы просто заплатить за них, чтобы иметь статического дюйм/с, и Вы сохраняете в целости свою политику безопасности и простую конфигурацию. Я уверен, что Вы уже рассмотрели это.
Если Вы готовы ослабить некоторые политики, Вы могли в теории узнавать свой штат подсети ISP и ограничивать доступ к тем, которые могут значительно уменьшить воздействие, хотя я думаю, что это было бы необычным подходом.
Если Вы серьезно относитесь к обеспечению SSH, необходимо смотреть на ключевые логины только с некоторыми требованиями, чтобы ключи были защищены паролем, и возможно даже истечение их на запланированной основе.
Не предоставляйте свой корневой доступ пользователей SSH. Используйте sudo для предоставления доступа к корневым командам типа. Используйте logwatch или подобный для слежения за тем, что продолжается.
Кроме того, это - веб-сервер - Ваша конфигурация по умолчанию SSH, вероятно, намного более безопасна, чем другие аспекты системы, которую Вы сознательно выставляете Интернету, даже если компромисс был бы более серьезным. Не забывайте об обеспечении остальной части сервера и кода, Вы работаете на нем.
Превосходное руководство по обеспечению сервера Linux может быть найдено здесь. Специфические особенности являются CentOS/RedHat, но он пробегается через большое количество опций, характерных для всех дистрибутивов.
В дополнение к другим предложениям Вы могли бы также рассмотреть выполнение sshd на нестандартном номере порта. Это не будет замедлять целенаправленное нападение очень долго, но оно обойдет некоторые автоматизированные атаки перебором, которые сканируют Интернет для хостов, работающих sshd на порте 22.
Брандмауэр ConfigServer может быть установлен до автоматически белого списка динамический дюйм/с. Необходимо будет установить динамическое доменное имя для каждого клиента для этого для работы - некоторые динамические сайты IP предоставят Вам клиентский исполняемый файл, который держит IP в курсе. Я использую no-ip.com с этой целью.
Поддержка некоторого брандмауэра с помощью записей DNS, таким образом, сервисы как http://www.no-ip.com/services/managed_dns/free_dynamic_dns.html могут использоваться для ограничения доступа.
Если Вы просто хотите использовать iptables, у Вас могло бы, вероятно, быть что-то заданное сценарием для проверки имен DNS (я не думаю поддержки iptables с помощью записей DNS для предоставления доступа.)
Но у Kyle есть хороший ответ в требовании основанного на ключе автора, которого я не знаю, как потребовать и ключей и паролей, таким образом, мой метод должен был бы потребовать, чтобы ключи получили доступ к серверу.