☰

セキュリティレビュー：SSHログイン試行分類[閉じる]

tag-icon • tag-icon ssh security logs aws
セキュリティレビュー：SSHログイン試行分類[閉じる]

AWS EC2 Ubuntu LinuxインスタンスへのMy SSHログインは、次のように表示されます。

Nov 18 07:32:21 ip-10-20-30-40 sshd[9487]: Accepted publickey for ubuntu from 15.26.37.48 port 46273 ssh2: RSA SHA256:e37A/qiEdkHHNpeksdPO

私が走るとき珍しい脆弱性を探すコマンド

ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log
ubuntu@ip-12-34-56-78:~$ egrep "Failed|Failure" /var/log/auth.log
ubuntu@ip-12-34-56-78:~$ grep "Failed password" /var/log/auth.log | awk '{print $11}' | uniq -c | sort -nr
ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure"
ubuntu@ip-12-34-56-78:~$ journalctl _SYSTEMD_UNIT=sshd.service | grep "failure"

何も現れません。今まではそんなに良くなった。

ところで、ログファイルを探していたところ、2つの疑わしい問題が見つかりました。まず、「認証失敗」と表示されます。

ubuntu@ip-12-34-56-78:~$  grep "authentication failure" /var/log/auth.log

Nov 14 09:23:19 ip-12-34-56-78 sshd[9711]: Disconnecting authenticating user root 98.76.54.32 port 36745: Too many authentication failures [preauth]
Nov 14 09:23:22 ip-12-34-56-78 sshd[9713]: Disconnecting authenticating user root 98.76.54.32 port 36754: Too many authentication failures [preauth]
Nov 16 11:45:29 ip-12-34-56-78 sshd[20710]: Disconnecting invalid user admin 15.48.27.78 port 51289: Too many authentication failures [preauth]

第二に、sshで接続しても以下のような行が浮かびます。ssh -i myKeyPair.pem [email protected]

Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 17 17:17:01 ip-12-34-56-78 CRON[948]: pam_unix(cron:session): session closed for user root

Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Invalid user stuart from 34.55.89.144 port 32946
Nov 17 18:23:25 ip-12-34-56-78 sshd[1004]: Connection closed by invalid user stuart 34.55.89.144 port 32946 [preauth]

Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Invalid user ubnt from 21.34.55.89 port 56171
Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: error: Received disconnect from 21.34.55.89 port 56171:14: Unable to connect using the available authentication methods [preauth]
Nov 17 07:29:47 ip-12-34-56-78 sshd[32620]: Disconnected from invalid user ubnt 21.34.55.89 port 56171 [preauth]

Nov 17 12:39:00 ip-12-34-56-78 sshd[32695]: Did not receive identification string from 233.55.89.13 port 54959

Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Received disconnect from 144.233.55.89 port 42056:11: Normal Shutdown, Thank you for playing [preauth]
Nov 17 23:51:58 ip-12-34-56-78 sshd[1396]: Disconnected from invalid user sinusbot 144.233.55.89 port 42056 [preauth]
Nov 17 23:52:24 ip-12-34-56-78 sshd[1398]: Invalid user sinusbot from 144.233.55.89 port 57180

不明な質問がたくさんあります。

  1. 「遊んでくれてありがとう」はどんな冗談ですか？これは悪いゲームサーバーではありません。うん？
  2. 自動的に「機会をつかむ」ことを試みるように見える「スチュアート」のようなユーザーがたくさんいます。これはただのロボットですか？
  3. このような試みが発生または処理されるのを防ぐための設定はありますか？
  4. 以前は、ssh-keygenでファイルを作成した後、リモートサーバーにコピー/貼り付けを行いましたが、今はAWSを使用しています。邪魔することなく許可されます。私は正しいですか？ssh -i myKeyPair.pem [email protected]
  5. 最も重要なこと：公開鍵SSHを唯一の認証方法として選択した記憶がありますが、AWS設定でもあれこれ試してみました。私や他の誰もSSHに公開鍵以外に何も開いていないことを常に確認するためにどのテストを実行できますか？

ベストアンサー1

1～3までの短答型問題

あまり混乱しない分析のために、私はそれが必須last -iだと思いますlastb -i。

  • このpreauth記号はログイン試行の失敗を示します。

  • これ遊びに来てくれてありがとう。シンボルにはマネージャーのユーモアのセンスが少しあります。

  • 失敗した試みはすべて記録されます。

  • おっしゃるとおり、「ゲート」はインターネットに開かれています。したがって、ポートバンピングを構成しない限り、世界中のすべてのホストが「ゲートに到達」します。

一般に、公開鍵が設定sshの唯一の認証方法である場合、スクリプトボットは攻撃することはほとんど不可能です。ただし、月に数千回以上試すこともできます。

そのような試みが心配な場合は、インストールして設定できます。失敗2禁止。

長い答えとマトリックスへようこそ

ロボットと低くぶら下がっている果物

経験が少ないほとんどの管理者は、ログファイルの表示を開始するとパニックになることがあります。私が質問をしたときにあなたが投稿したのと同じ質問をたくさん始めたことを知っています。これは、インターネット上で無限に見えるハッキングの数に対する一般的な反応です。

私の技術的な友人や同僚は、私が見ているのがターゲット攻撃ではなく、自動化されたスクリプトを確認するためのほとんどの簡単な結果であると確信していました。そしてそれは...

評判の悪いさまざまな場所で購入して販売できるユーザー名とパスワードのリストがあります。スクリプトボットを実行している個人は、これらのリストの1つ以上を購入し、それを使用して特定のサブネット内のすべてのコンピュータにアクセスしようとし、IPv4アドレス空間全体をクロールすることもできます。

これが、次のような約100の名前がシリーズで表示される理由です。フレッド、サリー、ジョージ...など...あなたはあなたの名前や同様のものを見ることもできます。電子メールなど、実行できる他のサービスにも当てはまります。ファイルを見ると、/var/log/mail.log同じタイプのユーザー名とパスワードの組み合わせをハックする試みが表示されます。

これらの攻撃はボットです。サーバーに合理的なセキュリティ対策が設定されていると、sshハッカーの試行によって破損する可能性が低くなります。

SSHキー

SSHキーペアには公開コンポーネントとプライベートコンポーネントがあります。プライベートコンポーネントは絶対に配布しないでください。パブリックコンポーネントは~/.ssh/authorized_keysターゲットサーバーのファイルに配置する必要があります。

公開鍵認証中は、秘密鍵またはその鍵のパスワードは接続を介して送信されません。認証されると、ssh合意された対称セッションキーを使用してセッションが暗号化されます。あなたの秘密鍵を盗む攻撃者はまだあなたのパスワードを見つけなければなりません。そして、攻撃者は秘密鍵が保存されているコンピュータを損傷することなくそのパスワードをスニッフィングすることはできません。

SSHキーは暗号化オブジェクトであるため、アルゴリズムの終了日および/または特定のアルゴリズムの寿命全体にわたって発見された脆弱性が適用されます。したがって、サーバーソフトウェアを頻繁に更新し、新しく発見された問題があるかどうかをユーザーキーを確認することが重要です。

この記事を書いた時点で、標準アルゴリズムはまだRSA 2048のようです。 AWS キースクリプトは、以下に基づいて RSA 2048 キーを生成します.AWS ドキュメント。しかし、鍵ははるかに短く、アルゴリズムは国家機関や潜在的に破損したオブジェクトから独立して開発されたと推定されているので、すべての鍵をCurve 25519に変更しました。

サーバーの監査と記録のアーカイブ

最初にSSH公開鍵認証を有効にし、パスワード認証も無効にしたことを示したので、リモート攻撃者が公開鍵認証を無効にしたと疑う理由はありません。 AWS アカウント自体が破損していない限り、これは本当です。ただし、AWS アカウントへのアクセスに使用された予期しない IP アドレスに関する通知を受け取ることもあります。

長いロギングが必要な場合は、ログファイルの保存時間を延長またはlogrotateインストールできます。審査。

構成の完全性レベル

小規模/個人サーバー向けの正気なSSHセキュリティ対策

  • 公開鍵認証と公開鍵専用認証
  • rootユーザーへのSSHアクセスを無効にする
  • sudoroot権限が必要なユーザーにのみ有効になります。
  • 少なくとも2048ビットのRSAキーまたは曲線25519キーを使用してください。
  • 秘密鍵素材をサーバーに置かないでください
  • 必須でない場合は、X11転送を無効にしてください。

ほとんどの新規インストールで変更する必要がある唯一の設定は、公開鍵認証の有効化とX11の無効化です。

/etc/ssh/shhd_config

...
PermitRootLogin no
...
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
...

クレイジーSSHセキュリティ

上記に加えて、ポートノッキングを有効にし、ホストキーを単一のアルゴリズム（曲線25519など）に制限し、サーバーのホストキーフィンガープリントをドメインのDNSレコードに配置してから、DNSSECを使用してそのレコードを保護できます。

  • サーバーのホストキーを制限するには、使用するアルゴリズムのコメントを解除してサーバーを再起動しますsshd。この操作が完了して再接続しようとすると、ホストキーが一致しません。ローカルに保存されているホストキーの指紋を交換しようとするときは、接続の指示に従ってください。

/etc/ssh/sshd_config

...
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
...
  • sshfp選択したホストキーのDNSレコードを生成するには：

ssh-keygen -r domain.tld -f /etc/ssh/ssh_host_ed25519_key

結果レコードはドメインのDNSゾーンファイルに保存でき、ssh接続でそのフィンガープリントを確認します。これにより、初めて接続したときやサーバーのホストキーが変更されたときにSSHへの中間者攻撃を防ぐことができます。

そして文書に従って構成しなさい。

knockd is a port-knock server.  It listens to all traffic on an ethernet (or PPP) interface, looking for special "knock" sequences of port-
hits.  A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server.  This port need not be open -- since knockd
listens  at the link-layer level, it sees all traffic even if it's destined for a closed port.  When the server detects a specific sequence
of port-hits, it runs a command defined in its configuration file.  This can be used to open up holes in a firewall for quick access.

....

[options]
     logfile = /var/log/knockd.log

[openSSH]
     sequence    = 7000,8000,9000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -A INPUT -s %IP% --dport 22 -j ACCEPT

[closeSSH]
     sequence    = 9000,8000,7000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -D INPUT -s %IP% --dport 22 -j ACCEPT
  • DNSSECの構成ここでは詳細については説明しません。ただし、DNS なりすましは、DNSSEC が解決する実際の問題であることを覚えておくことが重要です。

おすすめ記事