web-dev-qa-db-ja.com

「ハニーポット（Linux）ユーザー」を安全に作成する方法

以下は、試みを検出するための実現可能なセキュリティ機能でしょうか？

以下の仕様でユーザーを作成します。

  • ユーザー名admin
  • パスワードはかなり安全ではありません（123456ではなく、独断的な言葉）
  • 特別な権限：none
  • .bashrcログインを通知するスクリプト、...

ご質問

  • これによりセキュリティリスクが発生しますか（特権の昇格など）？
  • それは攻撃者に関する情報を収集する賢明な方法でしょうか、それとも.bashrc 脚本？
  • それを実現可能/安全にするためにどのような措置をとるべきですか？

目的

  • 「手遅れ」になる前に、より深刻な脅威について知る
  • 攻撃者に関する情報を収集するには：攻撃者が使用しているテクニック/ツール、攻撃者（攻撃元）など。
authenticationlinuxbrute-forcehoneypot
4
Levite

コメントに記載する要件から、「ハニーユーザー」ではなく、インタラクションの高いハニーポットを探しています。

あなたが提案しているような高い相互作用のハニーポットは、決して実稼働システムで実行してはなりません。 OSレベルの脆弱性により、攻撃者はエスカレートする可能性があります。

常に、相互作用の高いハニーポットを自分の壁システムに配置します。

ただし、対話性の高いハニーポットは、攻撃者に関する特定の種類の情報を収集するためにのみ必要です。手法、ツールを分析し、攻撃者の行動をリアルタイムで観察することからのみ得られるその他のデータを収集する場合は、相互作用の高いハニーポットが必要です。そして、これはあなたのタイトルが示唆するように単に「ハニーユーザー」ではなく、本格的なハニーポットです。

真の「ハニーユーザー」は、高い相互作用であってはならず、そうである必要もありません。そのユーザーとしてログインしようとすると、アラームと追加のロギングがトリガーされます。システムでのユーザー資格情報の使用もキャプチャできます。これらのいずれも、資格情報が実際に機能することを必要としないため、セキュリティへの影響はありません。タイムスタンプ、ソースIP、および試行されたパスワードをキャプチャできます。

あなたが本当に探しているのは、Kippo/Cowrie（私は定期的に実行していて、多くのプレゼンテーションを行っています）です。また、開発者はハニーポットを運用システムで実行しないことを非常に明確にしています。私が展開したハニーポットについては、24時間ごとに（またはそれより早く）リセットされ、ログが中央サーバーに送信される仮想マシンのDMZに常に配置します。ハニーポットから開始されたトラフィックはすべてブロックされます。攻撃者は侵入できますが、マシン全体を危険にさらしたとしても、逃げることはできません。

同様の設定を検討する必要があります。

1
schroeder

未知のソースの実行を許可することは、ユーザーが最小限の権限しか持っていなくても、良い考えではありません。

攻撃者が実行できること：

  • 攻撃者はハードウェアでコードを実行することができ、たとえば暗号通貨のマイニングに100％CPUを使用する可能性があります。
  • 攻撃者は最終的に、dirty-cowなどの特権昇格を使用する機会を持つ可能性があります。
  • 攻撃者は、権限昇格用に設計が不適切なsuidファイルを見つける可能性があります。

GitHubにはsshセッションをエミュレートするオープンソースプロジェクトがあり、セッションを完全に制御できます。 https://github.com/micheloosterhof/cowrie/blob/master/README.md

1
user169249