Обеспечение сервера SSH против bruteforcing

Нет никакой замены для безопасных паролей И ключевой аутентификации. Однако Fail2Ban является большим инструментом для запрета дюйм/с пользователей, которые пытаются пройти проверку подлинности слишком много раз. Это также доступно как предварительно созданный пакет для большинства дистрибутивов. Предупредите, можно было случайно запретить себя, поэтому удостоверьтесь, что у Вас есть добавленный в белый список IP восстановления также или легкий консольный доступ...

Fail2Ban имеет несколько хороших примеров практического руководства, настраивают все, что Вы спросили..., что это не делает однако, имеет универсальный репозиторий плохих адресов. Я не думаю, что существует такой репозиторий везде из-за простоты получения другого IP (dhcp, возобновляют/сеть роботов нападения/и т.д....). Я также отключил бы вход на пути ssh, использование общего 'администратора' вводят имена пользователей (root/admin/administrator/sysop/etc..), поскольку это обычно барабанившее.

Я остановил атаки перебором с:

• fail2ban
• sshd.config:
  • PasswordAuthentication нет
  • PermitRootLogin нет
• Ограничение уровней Подключения SSH с iptables (http://www.debian-administration.org/articles/187)

Существует много хороших предложений, предлагаемых здесь. Я почтительно предлагаю, чтобы три вещи сделали это относительно безопасным:

1. Выполните sshd на случайном высоком порте. Боты обычно только следуют за портом 22 и вариации на порт 22 как 2 222.
2. Отключите основанную на пароле аутентификацию в конфигурации sshd:

UsePAM нет

3. Только пройдите проверку подлинности с этим сайтом через предобщие пары ключей SSH. Человек на ssh-keygen для начала работы с основанной на PKI аутентификацией.

Надеюсь, это поможет.

Я всегда был большим поклонником CSF/LFD, который может заблокировать IP-адреса людей, пробующих к сканированию портов "в лоб" и некоторым другим опциям. Это - в основном огромная perl-обертка для таблиц IP, но конфигурационный файл не трудно считать, и документация не плоха.

Вы могли также изучить sshguard. Я не использовал его, но я услышал хорошие вещи.

Источники:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

"Sshguard контролирует серверы от их действия входа. Когда журналы передают это, кто-то делает Плохую Вещь, sshguard реагирует путем блокирования he/she/it некоторое время. Sshguard имеет раздражительную личность: когда непослушный малыш настаивает, нарушая Ваш хост, он реагирует более жестко и более жестко".

Мне подключили сервер SSH к Интернету на порте по умолчанию и никогда не испытывал проблемы..

• tcp_wrappers (т.е. hosts.allow hosts.deny) для SSH.. Я не думаю, что существует SSH там, который не имеет поддержки скомпилированной в нем
• iptables это в сочетании с tcp_wrappers устранило приблизительно 99% моих попыток сканирований случайного порта / попыток "в лоб".. единственная проблема - Вы, должен знать, где Вы будете соединяться от того, чтобы позволить им IP/диапазоны IP... Я просто сделал поиск на популярных поставщиках вокруг моей области, чтобы видеть их диапазоны IP и позволить им.. большинство сканирований, кажется, прибывает из далеко земель :)
• PermitRootLogin, без паролей (т.е. только пары ключей RSA/DSA, которые шифруются с паролем), работы замечательно для автоматизированных задач.. когда я вхожу в систему для взаимодействия, я, очевидно, использую свою учетную запись (обычную), который настроен с sudo доступом
• sudoers
• постоянные обновления.. Я часто обновляю это поле со всеми обновлениями безопасности / критическими обновлениями
• изменения пароля/пароля
• выполненный chkrootkit время от времени, чтобы видеть, есть ли у меня какие-либо проблемы.. (существуют несколько там, которые выполняют эту функцию),

надежда это помогает!

Существует лучший способ сделать, это, с помощью fail2ban означает, что необходимо добавить приложение, и он работает на прикладном уровне.

При использовании iptables, это более эффективно, поскольку это работает на сетевом уровне, и Вы не должны устанавливать дополнительное приложение.

Используйте iptables недавний модуль http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Опция (чтобы использоваться в дополнение к другим мерам безопасности), имеют sshd, слушают на порте кроме 22. Я не попробовал его сам, но услышал, что это сокращает количество чистых атак перебором ботами.

Я должен подчеркнуть, что это не реальная безопасность, просто сокращает количество автоматизированных атак перебором. Слишком много работы для проверки каждого порта я предполагаю.

Что-то, что не упоминается здесь и действительно должно, ограничивает доступ через брандмауэр. Это не удовлетворяет каждой ситуации, но если Вы соединяетесь с хостом от последовательного местоположения со статическим IP, Вы могли просто блокировать SSH полностью кроме к тому IP. Это гарантирует, что злоумышленники не могут войти. Как я упомянул, хотя, это не всегда удовлетворяет каждой ситуации, особенно если Ваш IP является динамичным и часто изменяется.

DenyHosts, http://denyhosts.sourceforge.net/, является хорошим проектом, с которым у меня была удача. При установке denyhosts для синхронизации, он загрузит нового дюйм/с для добавления к списку запрета, которые имели к другим системам "в лоб" с помощью denyhosts. Это также истекает дюйм/с, которые не попробовали к грубой силе некоторое время.

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

Что было эффективным для меня:

1. Как другие сказали, никакой корневой вход в систему, набор PasswordAuthentication к не (только входят в w/keys) в sshd_config

2. Только один или два пользователя позволили регистрироваться на пути ssh, и у них есть квазинеясные имена, которые не находятся в общих списках имени пользователя инструмента "в лоб" (т.е. не "администратор" или "апач" или "сеть" или "johnny")

3. Строгие правила брандмауэра (в основном, все заблокировано, но мой порт услуг и ssh). Я даже ограничиваю ping, для отражения большего количества сырых сканирований (очень к огорчению моего партнера).

4. На моем веб-хосте я действительно ограничиваю доступ к определенному небольшому количеству IP-адреса - но это похоже, это не опция для Вас. Конечно, не может сделать этого самостоятельно на всех наших хостах. Можно также хотеть изучить "стук порта".

5. И мой фаворит: активный модуль ответа OSSEC для блокирования многих условий грубой силы и предупреждений на других ошибках, также. Это обнаруживает x недопустимые логины за y количество времени и затем блоки (через iptables команду отбрасывания брандмауэра) в течение определенного промежутка времени. Я блокируюсь в течение приблизительно 12 часов теперь для забавы.:)

Одна вещь, которую я делаю здесь, чтобы удостовериться, что я не блокирую слишком много неправильной вещи, состоит в том, что в/etc/ossec.conf, я установил активный ответ на высокий уровень (который не существует в конфигурации по умолчанию), и затем пройдите sshd_rules.xml и установите правила, которые я хочу заблокировать к тому уровню и изменить пороги для блока по сравнению с предупреждением по мере необходимости.

При выполнении Apache можно заблокировать материал, который нарушает апачские правила, также. Я не блокируюсь на них только из-за проблемы NAT, я хочу думать о блокировании всего университета или чего-то.:) Кроме того, можно записать пользовательские правила для блокирования на определенных условиях в файлах журнала, которые могут быть действительно полезными.