Брутфорс-атаки на SSH надоели, поэтому...

7 min

sshdebianvpsfail2ban
language: ja bn en es hi pt ru zh-cn zh-tw

Здравствуйте, я некомпетентен.
Наблюдая за /var/log/auth.log на сервере, где размещен Gitea, с помощью tail -f, я заметил подозрительные попытки.
Например, вот так:

2024-12-07T16:57:39.486624+00:00 hostname sshd[392231]: Received disconnect from WireGuardSrvIP port 42552:11: Bye Bye [preauth]

Происходят попытки входа по SSH со стороны VPN-сервера. Причина этого в том, что я использую Nginx для проксирования Stream к этому Gitea-серверу.

stream {
    server {
        listen 2222; 
        proxy_pass GiteaSrvIP:2222; 
        proxy_timeout 1m;
        proxy_connect_timeout 1s;
    }
}

Таким образом, IP-адреса, принятые на порту 2222, перенаправляются на GiteaSrvIP, но, честно говоря, я до сих пор не понимаю, почему в логах отображается другой порт 42552. Меня беспокоит, что так много попыток входа поступает с этого IP-адреса, который я использую как внутренний IP.
По сути, я хочу отправлять данные в Gitea по протоколу SSH, но при проксировании через Stream необходимо проксировать на IP:порт, и я думаю, что это происходит потому, что все попытки SSH на порт 2222 перенаправляются на GiteaSrvIP.

Даже для меня это звучит запутанно, поэтому...

Злодей: Я буду SSH на git.domain.tld на порт 2222!
WireGuardSrv: Ого, ты пытаешься войти на порт 2222?
WireGuardSrv: Тогда я перенаправлю все запросы на порт 2222 на GiteaSrv!
GiteaSrv: Эй, я вижу только IP WireGuardSrv, и ко мне поступает много попыток входа по SSH...

Я могу представить попытки SSH с WireGuardSrvIP только в таком сценарии...
Но загадка в том, что я не понимаю, как это становится port 42552, если я настроил его только на прием на порту 2222 и перенаправление на порт 2222. Если бы кто-то пытался SSH на этот порт с глобального IP-адреса, используя IP-адрес, который существует только в VPN, я бы еще мог понять...
Конечно, сам вход по SSH запрещен для root, и я использую только аутентификацию по открытому ключу, так что если его взломают, мне будет интересно, как это было сделано.

В качестве меры противодействия

Если останется грязный auth.log, его будет трудно читать как файл журнала, и, что самое главное, файл журнала, вероятно, сильно разрастется, поэтому я хочу заблокировать это на ранней стадии.
Дело в том, что я блокирую многократные попытки входа по SSH с помощью fail2ban, но в этом случае SSH-попытки к GiteaSrvIP через Wireguard также будут блокироваться вместе с другими записями в журнале.
Поэтому я хочу предотвратить это до того, как оно будет записано в auth.log.

На стороне FreeBSD (сервер WireGuard)

Я настрою политику блокировки по умолчанию для pf на drop.
PF: Опции времени выполнения
Итак, я установлю Drop в качестве политики по умолчанию.

set block-policy drop

Таким образом, если пакет попадает под политику блокировки на стороне FreeBSD, он будет просто отброшен.

На стороне Debian (клиент WireGuard и сервер Gitea)

Во-первых, это странно, что с WireGuardSrvIP поступают какие-то запросы на другие порты, кроме портов 22 и 2222 для HTTP-сервера Gitea и SSH.
В частности, порты выше 2222, такие как 3000, функционируют как порты HTTP по умолчанию, и их не следует открывать, но я не хочу, чтобы Gitea слушал на порту 80, поэтому я временно открыл порт 3000 на период тестирования.
Поскольку я уже наговорил много лишнего, я ограничил порты с помощью ufw следующим образом:

ufw deny proto tcp from WireGuardSrvIP to any port 2223:65535
ufw reload

Поскольку я хочу использовать его как тестовый VPS-сервер, я временно отклонил диапазон 2223:65535, но явно открыл 3000/tcp.

Успешно прекратились непонятные записи о попытках SSH

Благодаря этому, я не знаю, сработало ли это из-за политики блокировки на стороне FreeBSD или из-за явного deny с помощью ufw, так как я сделал это одновременно, но записи о попытках входа в auth.log, которые поступали в огромных количествах, успешно прекратились.
Вероятно, поскольку на стороне FreeBSD уже был настроен какой-то брандмауэр, я думаю, что все заблокированные пакеты отбрасываются на уровне FreeBSD, а не REJECT. Я надеюсь на это.

Повторная настройка fail2ban

Итак, я отредактировал /etc/fail2ban/jail.conf
и установил исключенные IP-адреса в настройках мониторинга по умолчанию.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 WireGuardSrvIP

После этого я изменил настройки для sshd.

[sshd]
enabled = true
port    = all
logpath = /var/log/auth.log
bantime = 10w  
findtime = 1d  
maxretry = 2

Я сделал настройки более строгими, чем для WireGuardSrv.
Причины изменений следующие:

port    =  all
maxretry = 2

Для WireGuardSrv порт явно указан как ssh, поэтому он отслеживает только порты, используемые для SSH, но это будет отслеживать попытки SSH на все порты.
Что касается повторных попыток, то их количество ограничено до 2.
Причина изменения в том, что мне интересно, сколько будет заблокировано, и если будет много блокировок, я планирую настроить WireGuardSrv на том же уровне.
На этом все.
С нетерпением жду результатов.

Related Posts