web-dev-qa-db-ja.com

失敗したログイン試行はログに記録されるべきか

失敗したログイン試行を記録する必要がありますか？私の疑問は、分散ブルートフォース攻撃がある場合、データベースの使用可能なディスク領域を使い果たす可能性があることです。これのベストプラクティスは何ですか？

機密データで公開されているWebサーバーを保護しています。

これまでの回答に基づいて、私に起こったもう1つの質問は、そのような試みをログに記録するにはWebサーバーのログで十分かどうかです。それらをデータベースに記録するのは冗長でしょうか？

brute-forcelogging
41
John L.

はい、失敗したログイン試行はログに記録されます。

  • あなたは人々がいつ-やっているに入るのか知りたいです
  • アカウントがロックアウトされる理由を理解したい

それも非常に重要です。古いWindowsのログプロセスでは、これを十分に強調したことはありません。ログ記録成功したログイン試行も同様です。一連の失敗したログイン試行がある場合は、最後のログインの後に成功したログインが続いているかどうかを本当に知る必要があります。

ログは比較的小さいです。ロギングが問題を引き起こすほどのログイン試行があった場合、「試行について知らない」ことは、「ディスクが足りなくなったときにそれらを見つける」よりも、おそらく最悪の問題です。

簡単な警告-@Polynomialが指摘しているように、passwordはログに記録されるべきではありません（25年前に一部のシステムがまだ記録していたことを思い出しているようです）。ただし、ユーザーがユーザー名フィールドにパスワードを入力すると、一部の正当なログイン試行が失敗するため、パスワードがログに記録されることにも注意する必要があります。私を疑う？ WindowsイベントID 4768のログをトロールします。

LogName=Security
SourceName=Microsoft Windows security auditing.
EventCode=4768
EventType=0
Type=Information
ComputerName=dc.test.int
TaskCategory=Kerberos Authentication Service
OpCode=Info
RecordNumber=1175382241
Keywords=Audit Failure
Message=A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:       gowenfawr-has-a-cool-password
    Supplied Realm Name:    TEST.INT
    User ID:            NULL SID

同様に、これらのログへのアクセスを必要な人に制限する必要があります。会社全体が読み取りアクセス権を持っているSIEMにそれらを単にダンプしないでください。

質問の編集に対処するための更新：

これまでの回答に基づいて、私に起こったもう1つの質問は、そのような試みをログに記録するにはWebサーバーのログで十分かどうかということです。それらをデータベースに記録するのは冗長でしょうか？

ベストプラクティスは、どのような場合でもログを別のログアグリゲーターに転送することです。たとえば、PCI DSS 10.5.4を検討してください。実際には、このようなアグリゲーターは通常SIEMであり、フラットログファイルではなくデータベース。

つまり、そうです、定義上は「冗長」ですが、これは冗長性の一種であり、セキュリティ上の機能であり、アーキテクチャ上の誤りではありません。

それらをデータベースにログインすることの利点には、検索、相関、および合計が含まれます。たとえば、次のSplunk検索：

source="/var/log/secure" | regex _raw="authentication failure;" | stats count by user,Host

ユーザーとホストごとに認証失敗をロールアップできます。

Failed logins as per Splunk search

「ユーザー」や「ホスト」などの個別のフィールドをクエリする機能は、SIEMがログを選択し、何が何を意味するかを理解していることに依存しています。ここでこれらのフィールドにアクセスできるのは、Splunkが自動的にログを自動的に解析する副作用です。

元の質問ではスペースの制約を扱っていたので、データベースまたはSIEMソリューションでは、フラットテキストファイルのログよりも多くのディスク容量を使用することを指摘しておく必要があります。ただし、このようなソリューションを使用する場合、セキュリティとスペース管理の理由から、ほとんどの場合は別のサーバーに配置します。 （現在、SIEM-in-the-cloudソリューションもあります。

50
gowenfawr

whyを説明する@gowenfawrの回答を補足するものとして、これらの試行をログに記録する必要があります。ログがディスクを使い果たすことのないようにする方法はいくつかあります。

少なくともUnix-Linuxの世界では、logrotateやrotatelogsなどのツールを使用して、ログファイルのサイズが特定のしきい値を超えたときにログファイルを変更できます。これらは一般に、Apacheサーバー（rotatelogsはApache Foundationから提供されます）またはsyslogシステムで使用されます。

たとえば、logrotateは、ログファイルの名前を変更するために使用され（多数のコピーのリングで、通常は10個程度）、最終的にそれを圧縮し、ログを生成するプログラムに警告を送信して、ログファイルを再度開くように警告します。専用信号または任意のコマンドを介して。

これにより、サーバーがDoS攻撃を受けている場合でも、ログファイルのサイズは制御されたままになります。もちろん、古いイベントは失われますが、ディスクパーティションが使い果たされたためにサーバーをクラッシュさせるよりも間違いなく優れています。

8
Serge Ballesta

それは、あなたが情報から導き出すことができるとあなたが考えるどのような価値に本当に依存します。サーバーが攻撃を受けていることをログのページに通知することには、限られた価値があります。インターネットに接続しているため、存続期間中はさまざまな程度の絶え間ない攻撃を受ける可能性があります。

サーバーの構成によっては、ログで使用可能なディスク領域を使い果たしているため、最終的に可用性の問題が発生する可能性があります。それは起こります。 Gowenfawr氏は、ログはスペースをあまり取らないと述べたのは当然でしたが、これがディスクスペースの枯渇に関する問題がポップアップするまでに何年もかかる可能性がある理由ですが、そうすると大きな問題になります。

ログに記録することに決めた場合、ログ管理戦略を設計し、以下のいくつかを検討する必要があります。

  • ログをどのように処理しますか？ 誰かがあなたのシステムにアクセスしようとしていることを確立した後に何が起こりますか？
  • ログには潜在的に機密性の高いデータが含まれますか？ （実際のユーザーは、自分の資格情報を指で叩くことがあります）。 答えが「はい」の場合、保管する前にログをサニタイズするか、保管時にログを一度暗号化することを検討してください
  • 冗長性とログイベント
  • どのくらいの頻度でログをローテーションする必要がありますか？ ログローテーション は、ログサイズを処理するかなり標準的な方法です。古いログを圧縮し、特に古いログアーカイブを削除する可能性があります
  • セキュリティ情報とイベント管理。 _サーバーには機密情報が含まれているとのことですが、何を検討するかによって異なります [〜＃〜] siem [〜＃〜] に基づいて、有用な洞察を提供できる製品ロギング、およびアラート、ダッシュボード、フォレンジックなどのその他のデータ.

個人的に言えば、ログはフォレンジック分析にのみ役立つ傾向があります-違反が成功した後に何が起こったかを解明するのに役立ちます。 Gowenfawrが述べたように;システムへのログイン試行の成功をログに記録することは、失敗した場合と同じくらい（おそらくそれ以上に）重要です。

最後に、ログインメカニズムは、ブルートフォースが分散して動作する可能性がほとんどなくなるように構築する必要があります。構築したものについては詳しく説明していませんが、強力なバックエンドアルゴリズム、特に計算コストの高いハッシュを使用し、ログイン試行にバックオフタイミングを導入することで、攻撃者がこの方法でアクセスする可能性を大幅に減らすことができます。

4
Rob C