SSHへのブルートフォース攻撃が煩いので・・・

4 min read

sshdebianvpsfail2ban

こんにちは、無能です。
Giteaをホストしている/var/log/auth.logをtail -fで眺めていると何やら怪しい試行が。
例としてこんな感じ

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

VPNのサーバー側からのSSHのログイン試行がある。なんでこんなことが起きているかというとNginxでこのGiteaサーバーに対してStreamプロキシしているからだ。

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

こうするとPort 2222番で受け付けたIPはGiteaSrvIPに流されていくのだか正直なんでログには別ポートの42552が表示されているのか理解は未だ出来ていないがこの一応内部IPとして使っているIPからのログイン試行がすごい流れてくるのが気持ち悪い。
仕組み的には結局、GiteaにはSSHプロトコルでPushしたいけどStreamでプロキシする場合ポートにIP:portでプロキシする必要があり2222番でのSSH試行が全てGiteaSrvIPに流れているから起きているんだと思う。

自分で言っていてもごちゃごちゃになっているので・・・

悪モン : git.domain.tldの2222番にsshするで！
WireGuardSrv : おうおう、君2222番でログイン試行しようとしとんか
WireGuardSrv : じゃあ2222番へのリクエストは全てGiteaSrvに流すからな！
GiteaSrv : いやなんか俺からはWireGuardSrvくんのIPしか見えないし、いっぱいSSHのログイン試行来てるけど・・・。

ていう感じの流れでしか、WireGuardSrvIPからのSSH試行のイメージつかないんですが・・・。
ただ謎なのが2222番で受け付けて2222番に流すようにしかしていないのに、どうやってport 42552になっているのかはわからない。VPN上にしか存在しないIPアドレスでグローバルIPからこのポートでSSHしにこよう、というのならばまだ理解は出来るが・・・。
もちろん、SSHログイン自体はrootログインは禁止にしているし、公開鍵認証のみにしているのでもし突破されるならそれはそれでどうやられたか気になる程度ではあります。

対策として

汚いauth.logが残るとログファイルとして見づらいし、何よりもめちゃくちゃにlogファイルが肥大化しそうなので前段でブロックしたい。
というのも、fail2banでSSHの複数回ログイン試行はブロックしているんだけれどもこれだとWireguard経由でGiteaSrvIPに対してのSSHも他のログに混じってブロックされてしまう。
ということでauth.logに書き込まれる前段階で阻止したい。

FreeBSD(WireGuardサーバー)側

pfのデフォルトでブロックするポリシー設定としてdropをするようにする。
PF: 実行時オプション
というわけで、デフォルトポリシーとしてDropさせる。

set block-policy drop

これでFreeBSD側のブロックポリシーに引っかかった場合そのままパケットは捨てられる。

Debian(WireGuardクライアント兼Giteaサーバー)側

そもそも、GiteaのHTTPサーバーとSSHの22番、2222番で明らかにWireGuardSrvIPから来た他のポート番号から何かしらアクセスしにくる事自体がおかしい。
特に2222番以上のポート、3000番等はデフォルトのローカルHTTPポートとして機能していているからコレも本来は開けるべきではないのだがGiteaを80番でListenもしたくないので一旦テスト期間中として3000番で開けている。
でごちゃごちゃ言ってしまったので以下のようにufwでポート制限した。

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

お遊びVPSサーバーとして使いたい気持ちではあるので、2223:65535の範囲で一旦拒否して、別に明示的に3000/tcpは開けている。

無事に意味のわからないSSH試行ログは来なくなり

このおかげで、FreeBSD側でのブロックポリシーが効いたかufwで明示的にdenyしたからかは同時に行ってしまったのでどっちの効果かは知らないが無事に鬼のように飛んできていたauth.logに残るログイン試行はなくなった。
おそらく、もともとFreeBSD側ではある程度ファイアーウォールは設定していたのでブロックされたものに関してはREJECTではなくdropされることによってFreeBSD時点で全部パケットは捨てられているんだと思う。そう願いたい。

改めて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はportは明示的にsshとだけしているからsshで使うポートだけになっているんだけれどもこれは全てのポートに対するSSH試行を監視。
リトライに関しても厳しめの2回まで。
変えた理由はどれくらい引っかかるか気になり、もしこれでたくさん引っかかればWireGuardSrvにも同じようなレベルで設定するつもりです。
それでは。
結果が楽しみです。

PGP --- Contact --- Machines