web-dev-qa-db-ja.com

セキュリティレビュー：sshログイン試行の分類

AWS EC2 UbuntuLinuxインスタンスへの自分の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

few コマンドを実行して脆弱性を探すとき

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 -i myKeyPair.pem [email protected]をsshで実行しても、次のような行が表示されます。

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]を使用しています。 pemファイルまたは秘密鍵のいずれかを取得する人は誰でも邪魔されずに侵入できるため、どちらも安全性は同じです。私はこれを正しく理解していますか？
  5. 最も重要なこと：唯一の認証方法として公開鍵sshを選択したことを思い出しますが、AWSの設定でこれとそれに手を出しました。私も他の誰かもsshで公開鍵以外のものを開いていないことを今も継続的に確認するために実行できるテストとは何ですか？
sshsecuritylogsaws
3
Calaf

1から3の短い答え

分析をすっきりさせるには、last -iとlastb -iが不可欠だと思います。

  • preauth表記は、ログイン試行が失敗したことを示します。

  • 遊んでくれてありがとう表記はちょっとした管理者のユーモアです。

  • 失敗したすべての試行がログに記録されます。

  • あなたが言うところの「ゲート」はインターネットに開かれています...したがって、ポートノッキングを設定しない限り、世界中のすべてのホストが「ゲートに到達」しています。

一般に、公開鍵がsshの唯一の認証方法である場合、スクリプトボットからの構成はかなり攻撃不可能です。ただし、月に数千回、おそらくそれ以上の試行が予想されます。

このような試みが心配な場合は、インストールして構成できます fail2ban 。

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

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

ログファイルの監視を開始する経験の浅い管理者にとっては、恐らくパニックの瞬間があります。私が私のものを持っていたとき、私はあなたが投稿したのと同じ質問の多くを尋ね始めました。これは、インターネットの小さな隅でのハッキングの試みが際限なく殺到していることに対する一般的な対応です。

私の技術者の友人や同僚は、私が見たのは標的型攻撃ではなく、ほとんどが自動化されたスクリプトであり、ぶら下がっている果物をチェックしていることを保証しました。そしてそれは....

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

そのため、次のような100ほどの名前のシリーズ全体が表示されます：Fred、Sally、George ...など...名前などが表示される場合もありますいいね。電子メールなど、実行している可能性のある他のサービスについても同じことが言えます。 /var/log/mail.logファイルを見ると、同じ種類のユーザー名とパスワードの組み合わせによるハッキングの試みが見られます。

これらの攻撃はすべてボットです。サーバーに適切なセキュリティ対策を設定している場合は、sshハッキングの試みによって危険にさらされる可能性はほとんどありません。

SSHキー

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

公開鍵認証中、秘密鍵もその鍵のパスフレーズも接続を介して送信されません。認証が行われると、sshセッションは合意された対称セッションキーを使用して暗号化されます。あなたの秘密鍵を盗んだ攻撃者は、あなたのパスフレーズを理解する必要があります。そして、その攻撃者は、秘密鍵が保存されているマシンを危険にさらすことなく、そのパスフレーズを盗聴することはできません。

SSHキーは暗号化オブジェクトであるため、特定のアルゴリズムの存続期間を通じて発見されたアルゴリズムの廃止日や脆弱性の影響を受けます。したがって、サーバーのソフトウェアが頻繁に更新され、ユーザーキーが新たに特定された問題に対してチェックされていることを確認することが重要です。

この記事の執筆時点では、標準アルゴリズムはまだRSA 2048のようです。AWSキースクリプトは、 AWSドキュメント に従ってRSA2048キーを生成します。ただし、すべてのキーをCurve 25519に変更しました。これらのキーははるかに短く、アルゴリズムは州の機関や侵害された可能性のあるエンティティから独立して開発されるとされているためです。

サーバーの監査と記録の保持

最初にssh公開鍵認証を有効にし、パスワード認証も無効にしたことを示したので、リモートの攻撃者によって公開鍵認証が無効にされたと疑う理由はありません。つまり、AWSアカウント自体が侵害されていない限り、そうです。ただし、AWSアカウントへのアクセスに使用される予期しないIPアドレスに関する通知がいくつか届く可能性があります。

より長いログレコードが必要な場合は、ログファイルがlogrotateによって保持される期間を延長するか、インストール auditd することができます。

構成の健全性のレベル

小規模/個人用サーバーの健全なsshセキュリティ対策

  • 公開鍵認証と公開鍵認証のみ
  • Rootユーザーのsshアクセスを無効にする
  • ルート権限を必要とするユーザーに対してのみSudoを有効にします
  • 2048ビット以上のRSAキー、またはCurve25519キーを使用します
  • サーバーに秘密鍵を配置しないでください
  • どうしても必要な場合を除いて、X11転送を無効にする

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

/etc/ssh/shhd_config

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

非常識なsshセキュリティ

上記に加えて、ポートノッキングを有効にし、ホストキーをCurve 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に対するman-In-The-Middle攻撃から保護されます。

そして、ドキュメントに従って構成します。

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が解決する実際の問題であることを覚えておくことが重要です。
4
RubberStamp