Как защитить сервер ubuntu от атак brutforce ssh?
Это не изменит шрифт при загрузке, но для консоли на Ctrl + Alt + F [1-6]
Установите пользовательские шрифты Ubuntu для вашей консоли:
sudo apt-get install fonts-ubuntu-font-family-console
И создайте скрипт /usr/local/bin/fontset с помощью этой команды:
#!/bin/sh
setfont /usr/share/consolefonts/Uni3-TerminusBold32x16.psf.gz
(выберите желаемый фон из папки /usr/share/consolefonts/)
Вы можете вызвать fontset каждый раз на консоли после использования Ctrl + Alt + Alt
или добавьте эту строку в свой /root/.profile
[ ! -t 0 ] && sleep 1 & /usr/local/bin/fontset
(не добавляйте это в ваш файл .profile или вы получаете сообщение об ошибке при графической загрузке)
source: Изменение размера шрифта на экране сообщений о загрузке и консоли
70 ответов
Вы можете использовать разные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это замечательное руководство для разных подходов (включая аутентификацию RSA): http: // www.la-samhna.de/library/brutessh.html
Я использую http://www.la-samhna.de/library/brutessh.html on мой сервер, потому что я не хочу, чтобы это осложнялось для моих непрофессиональных пользователей: используя iptables, чтобы ограничить количество соединений в минуту, что делает нападки грубой силы медленными и бесполезными.
Вот решение I ' m:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как сказано здесь: Это позволит подключить три порта 22 от любого заданного IP-адреса в течение 60 секунд и потребовать 60 секунд после последующих попыток подключения, прежде чем он возобновит разрешение соединений еще раз. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
Затем добавить доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
И после этого выполните правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
-
1Что касается отключения аутентификации пароля, как мне войти на сервер, если я потеряю его публичный ключ? (У меня нет физического доступа к серверу, это VPS) – Dziamid 27 March 2011 в 23:55
-
2Открытый ключ может быть опубликован везде, где вы хотите. Так что не беспокойтесь об этом. Вы можете поместить его где-нибудь, что вы уверены, что не забудете его даже в общественных местах. – Pedram 28 March 2011 в 00:46
-
3Подробнее читайте здесь: ru.wikipedia.org/wiki/Public-key_cryptography – Pedram 28 March 2011 в 00:46
-
4Есть ли способ настроить сервер для раскрытия его открытого ключа, когда его спрашивают? – Dziamid 28 March 2011 в 02:29
-
5Используя ssh, я так не думаю. Если у вас установлен веб-сервер, такой как apache, вы можете поделиться этим ключом с помощью сети. – Pedram 28 March 2011 в 02:43
Вы можете использовать разные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это замечательное руководство для разных подходов (включая аутентификацию RSA): http: // www.la-samhna.de/library/brutessh.html
Я использую http://www.la-samhna.de/library/brutessh.html on мой сервер, потому что я не хочу, чтобы это осложнялось для моих непрофессиональных пользователей: используя iptables, чтобы ограничить количество соединений в минуту, что делает нападки грубой силы медленными и бесполезными.
Вот решение I ' m:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как сказано здесь: Это позволит подключить три порта 22 от любого заданного IP-адреса в течение 60 секунд и потребовать 60 секунд после последующих попыток подключения, прежде чем он возобновит разрешение соединений еще раз. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
Затем добавить доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
И после этого выполните правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Вы можете использовать разные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это замечательное руководство для разных подходов (включая аутентификацию RSA): http: // www.la-samhna.de/library/brutessh.html
Я использую http://www.la-samhna.de/library/brutessh.html on мой сервер, потому что я не хочу, чтобы это осложнялось для моих непрофессиональных пользователей: используя iptables, чтобы ограничить количество соединений в минуту, что делает нападки грубой силы медленными и бесполезными.
Вот решение I ' m:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как сказано здесь: Это позволит подключить три порта 22 от любого заданного IP-адреса в течение 60 секунд и потребовать 60 секунд после последующих попыток подключения, прежде чем он возобновит разрешение соединений еще раз. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
Затем добавить доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
И после этого выполните правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Вы можете использовать разные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это замечательное руководство для разных подходов (включая аутентификацию RSA): http: // www.la-samhna.de/library/brutessh.html
Я использую http://www.la-samhna.de/library/brutessh.html on мой сервер, потому что я не хочу, чтобы это осложнялось для моих непрофессиональных пользователей: используя iptables, чтобы ограничить количество соединений в минуту, что делает нападки грубой силы медленными и бесполезными.
Вот решение I ' m:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как сказано здесь: Это позволит подключить три порта 22 от любого заданного IP-адреса в течение 60 секунд и потребовать 60 секунд после последующих попыток подключения, прежде чем он возобновит разрешение соединений еще раз. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
Затем добавить доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
И после этого выполните правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Вы можете использовать разные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это замечательное руководство для разных подходов (включая аутентификацию RSA): http: // www.la-samhna.de/library/brutessh.html
Я использую http://www.la-samhna.de/library/brutessh.html on мой сервер, потому что я не хочу, чтобы это осложнялось для моих непрофессиональных пользователей: используя iptables, чтобы ограничить количество соединений в минуту, что делает нападки грубой силы медленными и бесполезными.
Вот решение I ' m:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как сказано здесь: Это позволит подключить три порта 22 от любого заданного IP-адреса в течение 60 секунд и потребовать 60 секунд после последующих попыток подключения, прежде чем он возобновит разрешение соединений еще раз. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
Затем добавить доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
И после этого выполните правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Вы можете использовать разные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это замечательное руководство для разных подходов (включая аутентификацию RSA): http: // www.la-samhna.de/library/brutessh.html
Я использую http://www.la-samhna.de/library/brutessh.html on мой сервер, потому что я не хочу, чтобы это осложнялось для моих непрофессиональных пользователей: используя iptables, чтобы ограничить количество соединений в минуту, что делает нападки грубой силы медленными и бесполезными.
Вот решение I ' m:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как сказано здесь: Это позволит подключить три порта 22 от любого заданного IP-адреса в течение 60 секунд и потребовать 60 секунд после последующих попыток подключения, прежде чем он возобновит разрешение соединений еще раз. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
Затем добавить доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
И после этого выполните правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Вы можете использовать различные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это отличное руководство для разных подходов (включая аутентификацию RSA): http : //www.la-samhna.de/library/brutessh.html
Я использую 3rd solution на своем сервере, потому что я не хочу чтобы сделать его сложным для моих непрофессиональных пользователей: используя iptables , чтобы ограничить количество подключений в минуту, что делает атаки с использованием bruteforce медленными и бесполезными.
Вот решение, которое я использую:
iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -set -name SSH -j ACCEPT iptables -A INPUT -p tcp - dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force" iptables -A INPUT -p tcp --dport 22 -m последнее - update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP Как сказано здесь : Это позволит подключить три порта 22 s от любого заданного IP-адреса в течение 60 секунд и требуется 60 секунд после последующих попыток подключения, прежде чем он снова возобновит подключение. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST Затем добавьте доверенные хосты:
iptables -A SSH_WHITELIST -s $ TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT ] И после этого сделайте правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp -dport 22 -m state -state NEW -j SSH_WHITELIST iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 - -rttl - имя SSH -j ULOG --ulog-prefix SSH_brute_force iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 -rttl --name SSH -j DROP Вы можете использовать различные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это отличное руководство для разных подходов (включая аутентификацию RSA): http : //www.la-samhna.de/library/brutessh.html
Я использую 3rd solution на своем сервере, потому что я не хочу чтобы сделать его сложным для моих непрофессиональных пользователей: используя iptables , чтобы ограничить количество подключений в минуту, что делает атаки с использованием bruteforce медленными и бесполезными.
Вот решение, которое я использую:
iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -set -name SSH -j ACCEPT iptables -A INPUT -p tcp - dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force" iptables -A INPUT -p tcp --dport 22 -m последнее - update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP Как сказано здесь : Это позволит подключить три порта 22 s от любого заданного IP-адреса в течение 60 секунд и требуется 60 секунд после последующих попыток подключения, прежде чем он снова возобновит подключение. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST Затем добавьте доверенные хосты:
iptables -A SSH_WHITELIST -s $ TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT ] И после этого сделайте правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp -dport 22 -m state -state NEW -j SSH_WHITELIST iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 - -rttl - имя SSH -j ULOG --ulog-prefix SSH_brute_force iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 -rttl --name SSH -j DROP Вы можете использовать различные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это отличное руководство для разных подходов (включая аутентификацию RSA): http : //www.la-samhna.de/library/brutessh.html
Я использую 3rd solution на своем сервере, потому что я не хочу чтобы сделать его сложным для моих непрофессиональных пользователей: используя iptables , чтобы ограничить количество подключений в минуту, что делает атаки с использованием bruteforce медленными и бесполезными.
Вот решение, которое я использую:
iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -set -name SSH -j ACCEPT iptables -A INPUT -p tcp - dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force" iptables -A INPUT -p tcp --dport 22 -m последнее - update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP Как сказано здесь : Это позволит подключить три порта 22 s от любого заданного IP-адреса в течение 60 секунд и требуется 60 секунд после последующих попыток подключения, прежде чем он снова возобновит подключение. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST Затем добавьте доверенные хосты:
iptables -A SSH_WHITELIST -s $ TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT ] И после этого сделайте правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp -dport 22 -m state -state NEW -j SSH_WHITELIST iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 - -rttl - имя SSH -j ULOG --ulog-prefix SSH_brute_force iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 -rttl --name SSH -j DROP Вы можете использовать различные решения. Лучше всего использовать аутентификацию RSA, которая использует общедоступные / закрытые ключи для аутентификации пользователей.
Проверьте это отличное руководство для разных подходов (включая аутентификацию RSA): http : //www.la-samhna.de/library/brutessh.html
Я использую 3rd solution на своем сервере, потому что я не хочу чтобы сделать его сложным для моих непрофессиональных пользователей: используя iptables , чтобы ограничить количество подключений в минуту, что делает атаки с использованием bruteforce медленными и бесполезными.
Вот решение, которое я использую:
iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -set -name SSH -j ACCEPT iptables -A INPUT -p tcp - dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force" iptables -A INPUT -p tcp --dport 22 -m последнее - update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP Как сказано здесь : Это позволит подключить три порта 22 s от любого заданного IP-адреса в течение 60 секунд и требуется 60 секунд после последующих попыток подключения, прежде чем он снова возобновит подключение. Параметр -rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться смягчить атаки на поддельные адреса источника.
Как сказано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST Затем добавьте доверенные хосты:
iptables -A SSH_WHITELIST -s $ TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT ] И после этого сделайте правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH iptables -A INPUT -p tcp -dport 22 -m state -state NEW -j SSH_WHITELIST iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 - -rttl - имя SSH -j ULOG --ulog-prefix SSH_brute_force iptables -A INPUT -p tcp -dport 22 -m state -state NEW -m recent -update -seconds 60 --hitcount 4 -rttl --name SSH -j DROP -
1Что касается отключения аутентификации пароля, как мне войти на сервер, если я потеряю его публичный ключ? (У меня нет физического доступа к серверу, это VPS) – Dziamid 27 March 2011 в 23:55
-
2Открытый ключ может быть опубликован везде, где вы хотите. Так что не беспокойтесь об этом. Вы можете поместить его где-нибудь, что вы уверены, что не забудете его даже в общественных местах. – Pedram 28 March 2011 в 00:46
-
3Подробнее читайте здесь: ru.wikipedia.org/wiki/Public-key_cryptography – Pedram 28 March 2011 в 00:46
-
4Есть ли способ настроить сервер для раскрытия его открытого ключа, когда его спрашивают? – Dziamid 28 March 2011 в 02:29
-
5Используя ssh, я так не думаю. Если у вас установлен веб-сервер, такой как apache, вы можете поделиться этим ключом с помощью сети. – Pedram 28 March 2011 в 02:43
Я получаю ssh-атаки грубой силы на своих серверах со скоростью от 1 до 2 в день. Я установил denyhosts (пакет ubuntu: denyhosts). Это очень простой, но эффективный инструмент для этой цели: по существу он периодически проверяет ваши журналы, чтобы обнаруживать атаки с использованием грубой силы, и помещает IP-адреса, откуда эти атаки попадают в ваш файл /etc/hosts.deny. Вы не услышите от них снова, и ваша нагрузка должна быть значительно уменьшена. Он очень настраивается через свой файл конфигурации /etc/denyhosts.conf, чтобы настроить такие проблемы, как количество ошибочных попыток, связанных с атакой и т. Д.
Благодаря прозрачной работе вы можете легко увидеть, что происходит (уведомление по электронной почте: «ага, другая подлая атака сорвана!») и отменить ошибки из-за того, что ваши пользователи неоднократно вводили в заблуждение свои пароли.
Конечно, все, что ранее говорилось о переключении на другие методы проверки подлинности, но иногда ваши требования не согласуются с требованиями ваши пользователи.
Кроме того, ограничение скорости нового соединения в iptables может быть лучшим выбором, а затем запретить доступ через hosts.deny. Итак, взгляните на fail2ban. Но если вы знаете, что ваша главная задача ssh - ваша главная проблема (вручную просмотрите /var/log/auth.log, чтобы определить это), пойдите с этим очень легким и малоэффективным инструментом.
-
1В последнее время мой /var/log/auth.log значительно вырос. Есть ли такая запись, как Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=root, указывает на атаку? – Dziamid 28 March 2011 в 04:11
-
2Ну, это означает, что кто-то на IP 218.15.136.38 попытался войти в систему как root. Возможно, вы были, но, скорее всего, не потому, что с помощью tools.whois.net/whoisbyip , я вижу, что этот IP-адрес зарегистрирован в Китае, что вполне может быть из Минска ;-) Итак, да, это выглядит как догадка вашего пароля. Мораль: отключите вход root через ssh (PermitRootLogin no in / etc / ssh / sshd_config), потому что нет веских оснований оставлять это. А затем рассмотрите denyhosts или fail2ban. Кроме того, убедитесь, что у вас есть брандмауэр, позволяющий использовать только необходимый доступ через порт 22 и все, что вам нужно (но не более) – DrSAR 28 March 2011 в 09:40
-
1-1 для первого совета, усложняет ситуацию, поскольку на самом деле нет реального повышения безопасности – steabert 28 March 2011 в 14:18
-
2Если вы используете ключи ssh и отключите аутентификацию пароля через ssh, мне действительно нужно 1,2,3? – Dziamid 28 March 2011 в 16:48
-
3@steabert помогает против сценаристов-девичников, которые просто пытаются использовать свой путь через порт 22. Это мой опыт: кто-то держит bruteforcing сервер, обращенный к Интернету, когда я его настраивал, заставляя систему отправлять мне предупреждения после предупреждений. Я переместил порт, и предупреждения утихли. – pepoluan 28 March 2011 в 18:05
-
4@Dziamid ssh ключи не позволяют кому-то проникнуть в вашу систему. но это не мешает им подключиться к порту 22. – pepoluan 28 March 2011 в 18:06
-
5@Dziamid Нет, не правильно. Другие методы проверки подлинности (RSAAuthentication, PubkeyAuthentication, #KerberosAuthentication и т. Д.) Все еще поддерживают контакт через порт 22. – DrSAR 28 March 2011 в 23:45
Прежде всего, вы должны не использовать пароли и использовать вместо них ключи. Нет необходимости использовать пароль. Если это сработает для вас, вы можете настроить OpenSSH-сервер, чтобы он не реагировал на вход в систему.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Использование fail2ban также может быть вариантом.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
-
1
-
2Только через консоль или прямой доступ. Я уверен, что вы не потеряете свой ключ, если сможете управлять сервером. – ddeimeke 28 March 2011 в 08:34
Насколько широко распространен сервер в сети? Возможно, вы можете поговорить с сетевым администратором и проверить, можно ли контролировать и ограничивать доступ к сети на сервер. Даже если логины входа в систему безопасны, кажется, что сервер может пострадать от простой атаки DoS / DDoS.
Альтернативой fail2ban является CSF: ConfigServer Security & amp; Брандмауэр.
Он поставляется с LFD: Daemon Failure Login, который может обнаруживать несколько неудачных попыток входа в систему для различных служб и блокирует нарушающий IP-адрес (временно или постоянно).
It имеет некоторые другие варианты, которые могут помочь в борьбе с наводнениями и, возможно, обнаружить вторжения.
Недостатки:
Вы должны использовать CSF в качестве своего брандмауэра, чтобы LFD выполнял свою работу. Поэтому, если у вас есть существующий брандмауэр, вам нужно будет заменить его CSF и перенести конфигурацию. Он не упакован для Ubuntu. Вам придется доверять автоматическим обновлениям с configserver.com или отключать автоматические обновления. Я слышал, что он довольно популярен, поэтому умные злоумышленники, вероятно, знают, как отключить обнаружение вторжений до их обнаружения!Вы намерены разрешить услугу SSH для всего мира? Или просто членам команды в определенных местах? Мой ответ немного зависит от серьезности вашей задачи.
В любом случае вам нужно сделать все, чтобы убедиться, что сервер SSH не разрешает вход в систему для пользователя root.
В файле / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход в корневой каталог, кроме ключа SSH.В моих системах у меня есть этот параметр
PermitRootLogin without-password
, но я замечаю в новом Ubuntu, что у них есть
PermitRootLogin prohibit-password
Если вы читаете «человек sshd_config «Я думаю, это означает, что этот новый« запрет-пароль »означает одно и то же и, безусловно, более очевидно по смыслу. Это НЕ по умолчанию для некоторых Linux-систем, но, вероятно, должно быть.
Теперь о вашей проблеме. Имеет ли ваш системный сервер только некоторые пользователи в определенных местах? Сделайте это!
В файле / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход в root, кроме как с помощью SSH-ключа.Затем отредактируйте /etc/hosts.allow и введите IP-номера или диапазон, которые хотят разрешить использование SSH. Нотация там немного запутанна, потому что, если вы хотите разрешить все системы с номерами IP, такими как 111.222.65.101 - 111.222.65.255, вы помещаете такую запись в hosts.allow
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
. Это мощное решение.
Это решение существовало до создания IP-таблиц, это (я думаю), намного легче администрировать, но это не так хорошо, как IP-адрес таблиц, потому что процедуры IP-таблиц будут определять врагов раньше, чем программы, управляемые hosts.allow и hosts.deny. Но это верный огонь, простой способ закрыть множество проблем, а не только из SSH.
Обратите внимание на проблему, которую вы создаете для себя. Если вы хотите открыть FTP-сервер, веб-сервер или что-то еще, вам нужно будет сделать записи в хостах.
Вы можете достичь той же основной цели, перейдя в iptables и брандмауэр. В каком-то смысле это предпочтительное решение, потому что вы блокируете врагов на внешней границе. Ubuntu имеет «ufw» (несложный брандмауэр), а «man ufw» - множество примеров. Я бы предпочел иметь хороший графический интерфейс, чтобы пройти через это, мне не нужно делать это все время. Может быть, другие могут сказать нам, есть ли сейчас.
Другие сообщения здесь предлагали использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет, ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи идут среди компьютеров. Требование аутентификации ключа SSH вызовет большую проблему, потому что люди переходят с одного компьютера на другой.Еще один источник разочарования произойдет, когда некоторые пользователи накапливают разные ключи ssh для разных серверов. Поскольку у меня есть ключи SSH для примерно 12 различных проектов, теперь ssh терпит неудачу, потому что у меня слишком много открытых ключей (требуется либо «ssh -o PubkeyAuthentication = false», либо создание записи в файле .ssh / config. Это PITA)
Другие сообщения здесь предлагали использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет, ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи идут среди компьютеров. Требование аутентификации ключа SSH вызовет большую проблему, потому что люди переходят с одного компьютера на другой.В наших системах Centos Linux я заметил, что они отказались от пакета denyhosts и предлагают только fail2ban. Мне понравилось denyhosts, потому что он создал список проблемных диапазонов пользователей / ip, а затем в hosts.deny, этот список был отмечен. Вместо этого мы установили fail2ban, и все в порядке. Я понимаю, что вы предпочтете блокировать этих плохих пользователей на внешнем краю сервера, поэтому блокировщики на основе ip-таблиц, например fail2ban, на самом деле лучше. Denyhosts работает на вторичном уровне, после того как враги получили прошлые iptables, они затем отклоняются демоном sshd.
В обеих этих программах немного утомительно вывести пользователей из тюрьмы, если они забыли свой пароль и несколько раз попробовали войти в систему. Немного сложно вернуть людей, когда они сделать ошибки входа. Вы бы предположили, что будет графический интерфейс точки и щелчка, где вы могли бы просто указать и позволить людям вернуться, но это не так. Я должен делать это каждые несколько месяцев и забывать, как между временами, поэтому я написал инструкции для себя на моей веб-странице http://pj.freefaculty.org/blog/?p=301
Насколько широко распространен сервер в сети? Возможно, вы можете поговорить с сетевым администратором и проверить, можно ли контролировать и ограничивать доступ к сети на сервер. Даже если логины входа в систему безопасны, кажется, что сервер может пострадать от простой атаки DoS / DDoS.
Прежде всего, вы должны не использовать пароли и использовать вместо них ключи. Нет необходимости использовать пароль. Если это сработает для вас, вы можете настроить OpenSSH-сервер, чтобы он не реагировал на вход в систему.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Использование fail2ban также может быть вариантом.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
-
1
-
2Только через консоль или прямой доступ. Я уверен, что вы не потеряете свой ключ, если сможете управлять сервером. – ddeimeke 28 March 2011 в 08:34
Я получаю ssh-атаки грубой силы на своих серверах со скоростью от 1 до 2 в день. Я установил denyhosts (пакет ubuntu: denyhosts). Это очень простой, но эффективный инструмент для этой цели: по существу он периодически проверяет ваши журналы, чтобы обнаруживать атаки с использованием грубой силы, и помещает IP-адреса, откуда эти атаки попадают в ваш файл /etc/hosts.deny. Вы не услышите от них снова, и ваша нагрузка должна быть значительно уменьшена. Он очень настраивается через свой файл конфигурации /etc/denyhosts.conf, чтобы настроить такие проблемы, как количество ошибочных попыток, связанных с атакой и т. Д.
Благодаря прозрачной работе вы можете легко увидеть, что происходит (уведомление по электронной почте: «ага, другая подлая атака сорвана!») и отменить ошибки из-за того, что ваши пользователи неоднократно вводили в заблуждение свои пароли.
Конечно, все, что ранее говорилось о переключении на другие методы проверки подлинности, но иногда ваши требования не согласуются с требованиями ваши пользователи.
Кроме того, ограничение скорости нового соединения в iptables может быть лучшим выбором, а затем запретить доступ через hosts.deny. Итак, взгляните на fail2ban. Но если вы знаете, что ваша главная задача ssh - ваша главная проблема (вручную просмотрите /var/log/auth.log, чтобы определить это), пойдите с этим очень легким и малоэффективным инструментом.
-
1В последнее время мой /var/log/auth.log значительно вырос. Есть ли такая запись, как Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=root, указывает на атаку? – Dziamid 28 March 2011 в 04:11
-
2Ну, это означает, что кто-то на IP 218.15.136.38 попытался войти в систему как root. Возможно, вы были, но, скорее всего, не потому, что с помощью tools.whois.net/whoisbyip , я вижу, что этот IP-адрес зарегистрирован в Китае, что вполне может быть из Минска ;-) Итак, да, это выглядит как догадка вашего пароля. Мораль: отключите вход root через ssh (PermitRootLogin no in / etc / ssh / sshd_config), потому что нет веских оснований оставлять это. А затем рассмотрите denyhosts или fail2ban. Кроме того, убедитесь, что у вас есть брандмауэр, позволяющий использовать только необходимый доступ через порт 22 и все, что вам нужно (но не более) – DrSAR 28 March 2011 в 09:40
Альтернативой fail2ban является CSF: ConfigServer Security & amp; Брандмауэр.
Он поставляется с LFD: Daemon Failure Login, который может обнаруживать несколько неудачных попыток входа в систему для различных служб и блокирует нарушающий IP-адрес (временно или постоянно).
It имеет некоторые другие варианты, которые могут помочь в борьбе с наводнениями и, возможно, обнаружить вторжения.
Недостатки:
Вы должны использовать CSF в качестве своего брандмауэра, чтобы LFD выполнял свою работу. Поэтому, если у вас есть существующий брандмауэр, вам нужно будет заменить его CSF и перенести конфигурацию. Он не упакован для Ubuntu. Вам придется доверять автоматическим обновлениям с configserver.com или отключать автоматические обновления. Я слышал, что он довольно популярен, поэтому умные злоумышленники, вероятно, знают, как отключить обнаружение вторжений до их обнаружения!Вы намерены разрешить услугу SSH для всего мира? Или просто членам команды в определенных местах? Мой ответ немного зависит от серьезности вашей задачи.
В любом случае вам нужно сделать все, чтобы убедиться, что сервер SSH не разрешает вход в систему для пользователя root.
В файле / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход в корневой каталог, кроме ключа SSH.В моих системах у меня есть этот параметр
PermitRootLogin without-password
, но я замечаю в новом Ubuntu, что у них есть
PermitRootLogin prohibit-password
Если вы читаете «человек sshd_config «Я думаю, это означает, что этот новый« запрет-пароль »означает одно и то же и, безусловно, более очевидно по смыслу. Это НЕ по умолчанию для некоторых Linux-систем, но, вероятно, должно быть.
Теперь о вашей проблеме. Имеет ли ваш системный сервер только некоторые пользователи в определенных местах? Сделайте это!
В файле / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход в root, кроме как с помощью SSH-ключа.Затем отредактируйте /etc/hosts.allow и введите IP-номера или диапазон, которые хотят разрешить использование SSH. Нотация там немного запутанна, потому что, если вы хотите разрешить все системы с номерами IP, такими как 111.222.65.101 - 111.222.65.255, вы помещаете такую запись в hosts.allow
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
. Это мощное решение.
Это решение существовало до создания IP-таблиц, это (я думаю), намного легче администрировать, но это не так хорошо, как IP-адрес таблиц, потому что процедуры IP-таблиц будут определять врагов раньше, чем программы, управляемые hosts.allow и hosts.deny. Но это верный огонь, простой способ закрыть множество проблем, а не только из SSH.
Обратите внимание на проблему, которую вы создаете для себя. Если вы хотите открыть FTP-сервер, веб-сервер или что-то еще, вам нужно будет сделать записи в хостах.
Вы можете достичь той же основной цели, перейдя в iptables и брандмауэр. В каком-то смысле это предпочтительное решение, потому что вы блокируете врагов на внешней границе. Ubuntu имеет «ufw» (несложный брандмауэр), а «man ufw» - множество примеров. Я бы предпочел иметь хороший графический интерфейс, чтобы пройти через это, мне не нужно делать это все время. Может быть, другие могут сказать нам, есть ли сейчас.
Другие сообщения здесь предлагали использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет, ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи идут среди компьютеров. Требование аутентификации ключа SSH вызовет большую проблему, потому что люди переходят с одного компьютера на другой.Еще один источник разочарования произойдет, когда некоторые пользователи накапливают разные ключи ssh для разных серверов. Поскольку у меня есть ключи SSH для примерно 12 различных проектов, теперь ssh терпит неудачу, потому что у меня слишком много открытых ключей (требуется либо «ssh -o PubkeyAuthentication = false», либо создание записи в файле .ssh / config. Это PITA)
Другие сообщения здесь предлагали использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет, ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи идут среди компьютеров. Требование аутентификации ключа SSH вызовет большую проблему, потому что люди переходят с одного компьютера на другой.В наших системах Centos Linux я заметил, что они отказались от пакета denyhosts и предлагают только fail2ban. Мне понравилось denyhosts, потому что он создал список проблемных диапазонов пользователей / ip, а затем в hosts.deny, этот список был отмечен. Вместо этого мы установили fail2ban, и все в порядке. Я понимаю, что вы предпочтете блокировать этих плохих пользователей на внешнем краю сервера, поэтому блокировщики на основе ip-таблиц, например fail2ban, на самом деле лучше. Denyhosts работает на вторичном уровне, после того как враги получили прошлые iptables, они затем отклоняются демоном sshd.
В обеих этих программах немного утомительно вывести пользователей из тюрьмы, если они забыли свой пароль и несколько раз попробовали войти в систему. Немного сложно вернуть людей, когда они сделать ошибки входа. Вы бы предположили, что будет графический интерфейс точки и щелчка, где вы могли бы просто указать и позволить людям вернуться, но это не так. Я должен делать это каждые несколько месяцев и забывать, как между временами, поэтому я написал инструкции для себя на моей веб-странице http://pj.freefaculty.org/blog/?p=301
-
1-1 для первого совета, усложняет ситуацию, поскольку на самом деле нет реального повышения безопасности – steabert 28 March 2011 в 14:18
-
2Если вы используете ключи ssh и отключите аутентификацию пароля через ssh, мне действительно нужно 1,2,3? – Dziamid 28 March 2011 в 16:48
-
3@steabert помогает против сценаристов-девичников, которые просто пытаются использовать свой путь через порт 22. Это мой опыт: кто-то держит bruteforcing сервер, обращенный к Интернету, когда я его настраивал, заставляя систему отправлять мне предупреждения после предупреждений. Я переместил порт, и предупреждения утихли. – pepoluan 28 March 2011 в 18:05
-
4@Dziamid ssh ключи не позволяют кому-то проникнуть в вашу систему. но это не мешает им подключиться к порту 22. – pepoluan 28 March 2011 в 18:06
-
5@Dziamid Нет, не правильно. Другие методы проверки подлинности (RSAAuthentication, PubkeyAuthentication, #KerberosAuthentication и т. Д.) Все еще поддерживают контакт через порт 22. – DrSAR 28 March 2011 в 23:45
Насколько широко распространен сервер в сети? Возможно, вы можете поговорить с сетевым администратором и проверить, можно ли контролировать и ограничивать доступ к сети на сервер. Даже если логины входа в систему безопасны, кажется, что сервер может пострадать от простой атаки DoS / DDoS.
Прежде всего, вы должны не использовать пароли и использовать вместо них ключи. Нет необходимости использовать пароль. Если это сработает для вас, вы можете настроить OpenSSH-сервер, чтобы он не реагировал на вход в систему.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Использование fail2ban также может быть вариантом.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
-
1
-
2Только через консоль или прямой доступ. Я уверен, что вы не потеряете свой ключ, если сможете управлять сервером. – ddeimeke 28 March 2011 в 08:34
Я получаю ssh-атаки грубой силы на своих серверах со скоростью от 1 до 2 в день. Я установил denyhosts (пакет ubuntu: denyhosts). Это очень простой, но эффективный инструмент для этой цели: по существу он периодически проверяет ваши журналы, чтобы обнаруживать атаки с использованием грубой силы, и помещает IP-адреса, откуда эти атаки попадают в ваш файл /etc/hosts.deny. Вы не услышите от них снова, и ваша нагрузка должна быть значительно уменьшена. Он очень настраивается через свой файл конфигурации /etc/denyhosts.conf, чтобы настроить такие проблемы, как количество ошибочных попыток, связанных с атакой и т. Д.
Благодаря прозрачной работе вы можете легко увидеть, что происходит (уведомление по электронной почте: «ага, другая подлая атака сорвана!») и отменить ошибки из-за того, что ваши пользователи неоднократно вводили в заблуждение свои пароли.
Конечно, все, что ранее говорилось о переключении на другие методы проверки подлинности, но иногда ваши требования не согласуются с требованиями ваши пользователи.
Кроме того, ограничение скорости нового соединения в iptables может быть лучшим выбором, а затем запретить доступ через hosts.deny. Итак, взгляните на fail2ban. Но если вы знаете, что ваша главная задача ssh - ваша главная проблема (вручную просмотрите /var/log/auth.log, чтобы определить это), пойдите с этим очень легким и малоэффективным инструментом.
-
1В последнее время мой /var/log/auth.log значительно вырос. Есть ли такая запись, как Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=root, указывает на атаку? – Dziamid 28 March 2011 в 04:11
-
2Ну, это означает, что кто-то на IP 218.15.136.38 попытался войти в систему как root. Возможно, вы были, но, скорее всего, не потому, что с помощью tools.whois.net/whoisbyip , я вижу, что этот IP-адрес зарегистрирован в Китае, что вполне может быть из Минска ;-) Итак, да, это выглядит как догадка вашего пароля. Мораль: отключите вход root через ssh (PermitRootLogin no in / etc / ssh / sshd_config), потому что нет веских оснований оставлять это. А затем рассмотрите denyhosts или fail2ban. Кроме того, убедитесь, что у вас есть брандмауэр, позволяющий использовать только необходимый доступ через порт 22 и все, что вам нужно (но не более) – DrSAR 28 March 2011 в 09:40
Альтернативой fail2ban является CSF: ConfigServer Security & amp; Брандмауэр.
Он поставляется с LFD: Daemon Failure Login, который может обнаруживать несколько неудачных попыток входа в систему для различных служб и блокирует нарушающий IP-адрес (временно или постоянно).
It имеет некоторые другие варианты, которые могут помочь в борьбе с наводнениями и, возможно, обнаружить вторжения.
Недостатки:
Вы должны использовать CSF в качестве своего брандмауэра, чтобы LFD выполнял свою работу. Поэтому, если у вас есть существующий брандмауэр, вам нужно будет заменить его CSF и перенести конфигурацию. Он не упакован для Ubuntu. Вам придется доверять автоматическим обновлениям с configserver.com или отключать автоматические обновления. Я слышал, что он довольно популярен, поэтому умные злоумышленники, вероятно, знают, как отключить обнаружение вторжений до их обнаружения!Вы намерены разрешить услугу SSH для всего мира? Или просто членам команды в определенных местах? Мой ответ немного зависит от серьезности вашей задачи.
В любом случае вам нужно сделать все, чтобы убедиться, что сервер SSH не разрешает вход в систему для пользователя root.
В файле / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход в корневой каталог, кроме ключа SSH.В моих системах у меня есть этот параметр
PermitRootLogin without-password
, но я замечаю в новом Ubuntu, что у них есть
PermitRootLogin prohibit-password
Если вы читаете «человек sshd_config «Я думаю, это означает, что этот новый« запрет-пароль »означает одно и то же и, безусловно, более очевидно по смыслу. Это НЕ по умолчанию для некоторых Linux-систем, но, вероятно, должно быть.
Теперь о вашей проблеме. Имеет ли ваш системный сервер только некоторые пользователи в определенных местах? Сделайте это!
В файле / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход в root, кроме как с помощью SSH-ключа.Затем отредактируйте /etc/hosts.allow и введите IP-номера или диапазон, которые хотят разрешить использование SSH. Нотация там немного запутанна, потому что, если вы хотите разрешить все системы с номерами IP, такими как 111.222.65.101 - 111.222.65.255, вы помещаете такую запись в hosts.allow
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
. Это мощное решение.
Это решение существовало до создания IP-таблиц, это (я думаю), намного легче администрировать, но это не так хорошо, как IP-адрес таблиц, потому что процедуры IP-таблиц будут определять врагов раньше, чем программы, управляемые hosts.allow и hosts.deny. Но это верный огонь, простой способ закрыть множество проблем, а не только из SSH.
Обратите внимание на проблему, которую вы создаете для себя. Если вы хотите открыть FTP-сервер, веб-сервер или что-то еще, вам нужно будет сделать записи в хостах.
Вы можете достичь той же основной цели, перейдя в iptables и брандмауэр. В каком-то смысле это предпочтительное решение, потому что вы блокируете врагов на внешней границе. Ubuntu имеет «ufw» (несложный брандмауэр), а «man ufw» - множество примеров. Я бы предпочел иметь хороший графический интерфейс, чтобы пройти через это, мне не нужно делать это все время. Может быть, другие могут сказать нам, есть ли сейчас.
Другие сообщения здесь предлагали использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет, ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи идут среди компьютеров. Требование аутентификации ключа SSH вызовет большую проблему, потому что люди переходят с одного компьютера на другой.Еще один источник разочарования произойдет, когда некоторые пользователи накапливают разные ключи ssh для разных серверов. Поскольку у меня есть ключи SSH для примерно 12 различных проектов, теперь ssh терпит неудачу, потому что у меня слишком много открытых ключей (требуется либо «ssh -o PubkeyAuthentication = false», либо создание записи в файле .ssh / config. Это PITA)
Другие сообщения здесь предлагали использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет, ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи идут среди компьютеров. Требование аутентификации ключа SSH вызовет большую проблему, потому что люди переходят с одного компьютера на другой.В наших системах Centos Linux я заметил, что они отказались от пакета denyhosts и предлагают только fail2ban. Мне понравилось denyhosts, потому что он создал список проблемных диапазонов пользователей / ip, а затем в hosts.deny, этот список был отмечен. Вместо этого мы установили fail2ban, и все в порядке. Я понимаю, что вы предпочтете блокировать этих плохих пользователей на внешнем краю сервера, поэтому блокировщики на основе ip-таблиц, например fail2ban, на самом деле лучше. Denyhosts работает на вторичном уровне, после того как враги получили прошлые iptables, они затем отклоняются демоном sshd.
В обеих этих программах немного утомительно вывести пользователей из тюрьмы, если они забыли свой пароль и несколько раз попробовали войти в систему. Немного сложно вернуть людей, когда они сделать ошибки входа. Вы бы предположили, что будет графический интерфейс точки и щелчка, где вы могли бы просто указать и позволить людям вернуться, но это не так. Я должен делать это каждые несколько месяцев и забывать, как между временами, поэтому я написал инструкции для себя на моей веб-странице http://pj.freefaculty.org/blog/?p=301
-
1-1 для первого совета, усложняет ситуацию, поскольку на самом деле нет реального повышения безопасности – steabert 28 March 2011 в 14:18
-
2Если вы используете ключи ssh и отключите аутентификацию пароля через ssh, мне действительно нужно 1,2,3? – Dziamid 28 March 2011 в 16:48
-
3@steabert помогает против сценаристов-девичников, которые просто пытаются использовать свой путь через порт 22. Это мой опыт: кто-то держит bruteforcing сервер, обращенный к Интернету, когда я его настраивал, заставляя систему отправлять мне предупреждения после предупреждений. Я переместил порт, и предупреждения утихли. – pepoluan 28 March 2011 в 18:05
-
4@Dziamid ssh ключи не позволяют кому-то проникнуть в вашу систему. но это не мешает им подключиться к порту 22. – pepoluan 28 March 2011 в 18:06
-
5@Dziamid Нет, не правильно. Другие методы проверки подлинности (RSAAuthentication, PubkeyAuthentication, #KerberosAuthentication и т. Д.) Все еще поддерживают контакт через порт 22. – DrSAR 28 March 2011 в 23:45
Насколько широко распространен сервер в сети? Возможно, вы можете поговорить с сетевым администратором и проверить, можно ли контролировать и ограничивать доступ к сети на сервер. Даже если логины входа в систему безопасны, кажется, что сервер может пострадать от простой атаки DoS / DDoS.
Прежде всего, вы должны не использовать пароли и использовать вместо них ключи. Нет необходимости использовать пароль. Если это сработает для вас, вы можете настроить OpenSSH-сервер, чтобы он не реагировал на вход в систему.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Использование fail2ban также может быть вариантом.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
-
1
-
2Только через консоль или прямой доступ. Я уверен, что вы не потеряете свой ключ, если сможете управлять сервером. – ddeimeke 28 March 2011 в 08:34