私のUbuntuボックスが壊れていて、ハッカーが私のコンピューターで(ポート25を介して)メールをスパムしようとしたと思います。
/var/log/auth.log
の一部は次のように抽出されます(実際のユーザーをmyuser
に変更し、一部の外部IPアドレスを1.2.3.x
に変更しました):
Feb 20 06:07:12 ubuntu systemd-logind[954]: New session 77 of user myuser.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.4 port 25: failed.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.5 port 25: failed.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.5 port 25: failed.
Feb 20 06:08:22 ubuntu sshd[21251]: error: connect_to 1.2.3.6 port 25: failed.
...(thousands of similar lines follows)...
エラーメッセージはsshd
によって生成されたので、ハッカーはmyuser
としてSSHにログインすることでアクセスを得たと思います。 /etc/passwd
の各レコードは次のとおりです。
myuser:x:1003:1004:myuser:/home/myuser:/bin/false
ハッカーはmyuser
のシェルが/bin/false
であるためログインできなかったはずです。つまり、ログインできたとしてもすぐに追い出されるべきです。ログインできませんmyuser
PuTTYでも同様です。私自身のログインのログインレコードは次のようなものです。
Feb 22 10:26:58 ubuntu sshd[3653]: pam_unix(sshd:session): session opened for user myuser by (uid=0)
Feb 22 10:26:58 ubuntu systemd-logind[734]: New session 2 of user myuser.
Feb 22 10:26:58 ubuntu sshd[3653]: pam_unix(sshd:session): session closed for user myuser
したがって、明らかに私の設定に何か問題があるか、/bin/false
が/etc/passwd
ファイルで機能していません。現在の設定の何が問題になっていますか?また、抜け穴をどのように修正すればよいですか?
この / bin/false、/ sbin/nologinおよびSSHについてのcommandline.ninjaの記事 はあなたの質問に答えているようです。
ハッカーは、次のようなssh
コマンドを使用して、port forwardingを使用して、そのユーザーのシェルとして/bin/false
を使用する保護をバイパスできます。
[user@panel~] ssh -N [email protected] -L 2525:127.0.0.1:25
シナリオで可能な場合、最も単純で最も抜本的なのは、
sshd
構成ファイル(多くのシステムで/etc/ssh/sshd_config
)でTCPポート転送を無効にすることです。AllowAgentForwarding no AllowTcpForwarding no X11Forwarding no
/etc/shadow
を編集し、ユーザーのパスワードを*
に設定しますシャドウパスワード*
の暗号化されたパスワードとして/etc/shadow
を持つことは、アカウントがロックされていることを意味し、ユーザーはパスワード認証でログインできませんしかし、他の方法(SSHキーなど)は引き続き許可される場合があります。
詳細は / bin/false、/ sbin/nologinおよびSSHについてのcommandline.ninja にあります。