Ограничение доступа к SSH с динамическим IP-адресом

Я отключил PasswordAuthentication для SSH, и я использую открытый-закрытый ключ для входа в систему. Однако ряд руководств (в частности, этот), которые я видел, предлагают только разрешение SSH-доступа с моего конкретного IP-адреса.

/etc/ssh/sshd_config:
    AllowUsers deploy@(your-ip) deploy@(another-ip-if-any)

ufw allow from {your-ip} to any port 22
Есть ли какая-либо точка в ограничении IP-адресом внутри sshd_config И добавление правила брандмауэра? Предполагая, что у меня динамический IP-адрес, такие правила выглядят бесполезными, так как я должен использовать терминал консоли хостинг-провайдеров, войдите в root, чтобы разрешить доступ к моему домашнему IP-адресу. В этом случае: какой маршрут?

1: запретить все логины с помощью SSH, если я сначала не использую терминал хостинг-провайдеров, войдите в root, чтобы разрешить доступ из моего домашнего IP-адреса в SSH?

2: сохранить SSH-порт открывать и доверять публично-секретному ключу для входа в систему.

3: Любые другие предложения?

1
задан 8 February 2017 в 18:03

1 ответ

Если вы используете веб-сервер на одном и том же хосте, то, возможно, также установлен PHP, тогда вы можете установить инструмент, который я написал, использовал и активно поддерживал:

https: // github.com/cubiclesoft/web-knocker-firewall-service/

Клиенты, которым нужен SSH-доступ, запускают клиентскую часть как системную службу на своей ОС по выбору. Клиент сохраняет SSH-порт сервера и любые другие защищенные порты (например, POP3 / IMAP) с помощью редких, зашифрованных пакетов. Это довольно приятное решение с огнем и забытьем. У меня лично возникли проблемы с программным обеспечением, но вы можете протестировать его на капельке DigitalOcean или аналогичной службе, прежде чем развертывать ее в своей производственной среде. Порты сохраняются открытыми в течение 30 минут (по умолчанию), если пакеты обновления не отправляются (клиент пытается возобновить каждые 10 минут по умолчанию), что позволяет изменять IP-адреса с минимальным временем простоя. Когда открываются порты для IP-адреса, уведомления по электронной почте могут быть отправлены производителю, который настроен для получения таких уведомлений.

Цель состоит в том, чтобы резко ограничить поверхность атаки закрытием чувствительного порта (ов) всем у которого нет ключей шифрования для клиентов на динамических IP-адресах, где настройка сложной VPN не является вариантом. Даже если атакующий набирает тот же разблокированный IP-адрес (например, ноутбук на WiFi-кафе), им все равно нужно пройти через SSH, но по крайней мере Россия, Китай и Северная Корея не могут даже увидеть порт .

Кстати, я не использую ufw. Он загрязняет iptables путём ненужных цепей, делает правила iptables более сложными, чем они должны быть, и больше правил приравнивается к медленной обработке пакетов через iptables. Я написал сообщение не так давно, написав элегантные правила iptables:

https://github.com/cubiclesoft/web-knocker-firewall-service/

На самом деле гораздо проще использовать iptables напрямую и менее неудобно, чем ufw, когда вы можете копировать макароны с хорошими, чистыми наборами правил. Кроме того, вы никогда не знаете, когда вы застрянете в коробке CentOS.

0
ответ дан 23 May 2018 в 01:40

Другие вопросы по тегам:

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