Article ID: 8119, created on Oct 10, 2012, last review on Mar 31, 2016

  • Applies to:
  • Odin Business Automation Standard 4.5
  • Plesk for Linux/Unix

Симптомы

В журнале Parallels Panel sw-cp-server (/var/log/sw-cp-server/error_log) периодически появляется много записей "ssl handshake failure":

2009-06-03 22:37:08: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-03 22:46:56: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-03 22:58:49: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-03 23:19:52: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-03 23:31:44: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-03 23:41:18: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-03 23:52:36: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure
2009-06-04 00:02:38: (connections.c.299) SSL: 1 error:140780E5:SSL routines:SSL23_READ:ssl handshake failure


Кроме того, в журнале системной безопасности можно обнаружить следующие записи:

Jan 13 02:54:48 plesk9 sshd[9890]: Failed password for root from ::ffff:125.208.21.3 port 8880 ssh2
Jan 13 07:32:43 plesk9 sshd[11756]: Failed password for root from ::ffff:125.208.21.3 port 8880 ssh2

Причина

Возможная причина появления таких записей -- это атака методом подбора на sw-cp-server через порт 8880. Атака методом подбора может в конечном итоге заблокировать нормальную работу службы.

Решение

Эту проблему можно устранить одним из приведенных ниже способов.

1. Заблокировать сервер с помощью правил брандмауэра.

Пример 1 (Linux):

Вам нужно настроить правила брандмауэра (iptables) с помощью следующих команд:

#iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource

#iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix "SSH_brute_force "

#iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --rttl --name SSH --rsource -j DROP


Пример 2 (FreeBSD):

a. Создайте сценарий ssh-fwscan.sh:

#!/bin/sh

if ipfw show | awk '{print $1}' | grep -q 20000 ; then
            ipfw delete 20000
fi
# This catches repeated attempts for both legal and illegal users
# No check for duplicate entries is performed, since the rule
# has been deleted.

awk '/sshd/ && (/Invalid user/ || /authentication error/) {try[$(NF)]++}

END {for (h in try) if (try[h] > 5) print h}' /var/log/auth.log |
while read ip
do
ipfw -q add 20000 deny tcp from $ip to any in
done


б. Добавьте этот сценарий в cronjob:

*/10 * * * * root /operator/sshd-fwscan.sh


Пример 3 (FreeBSD):

Добавьте правило в фильтр pf:

pass in on $ext_if inet proto tcp from {192.168.1.0/24, 202.54.1.5/29} to $ssh_server_ip port ssh flags S/SA synproxy state


Внимание! IP-адреса 192.168.1.0/24 и 202.54.1.5/29 нужно заменить на ваши реальные адреса.

2. Заблокируйте сервер с помощью tcp-оболочек.

Пример:

Добавьте следующее правило в файл /etc/hosts.allow:

sshd: <admin IP address>/<netmask> : allow
sshd: ALL : deny

Дополнительная информация

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

- измените порт процесса sshd с 22 на какой-нибудь другой;
- используйте идентификацию только на основе ключей;
- закройте SSH-доступ для пользователя "root";
- настройте процесс sshd на прослушивание только с помощью эксклюзивных IP-адресов.

Разумеется, для этой цели существует и множество сторонних решений:

DenyHosts - сканирует файлы журналов и настраивает правила tcp-оболочки;
Cryptknock - открывает SSH-порт в случае необходимости;
BlockSshd - анализирует журналы и настраивает правила брандмауэра;
SshGuard - наблюдает за журналами и настраивает брандмауэры.

a914db3fdc7a53ddcfd1b2db8f5a1b9c 29d1e90fd304f01e6420fbe60f66f838 56797cefb1efc9130f7c48a7d1db0f0c 400e18f6ede9f8be5575a475d2d6b0a6 caea8340e2d186a540518d08602aa065 624ca542e40215e6f1d39170d8e7ec75 70a5401e8b9354cd1d64d0346f2c4a3e

Email subscription for changes to this article
Save as PDF