1

今朝、私は自分のWebサイトに移動し、ストアドプロシージャの後に次のメッセージでクラッシュするのを見ました。

Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

イベントビューアで、「sa」を使用しようとしている誰かによるブルートフォースログイン攻撃があったことに気づいたので、リモートアクセスを無効にしました。

それからのアパート、私は何が起こったのかについての手がかりがありません。現在、SQL Server 2008要求は機能せず、ストアドプロシージャを実行しようとすると常にタイムアウトを返すため、ASP.Netページを処理できません。

原因は何でしょうか。また、何を確認して修正する必要がありますか？

[編集3]

接続文字列のIPを127.0.0.1に変更することで解決しました。外部IPからSQLポートへのアクセスをブロックしてからブロックを解除した後も、あいまいなファイアウォール設定が外部IPをブロックしていました。

[編集2]

SQLで直接クエリを実行したところ、表示されるメッセージは次のとおりです。

A transport-level error has occurred when sending the request to the server.

[編集]

同様のスレッドに3つの可能性がリストされています。

1-どこかにデッドロックがあります。

いいえ、理由：

  • すべてのストアドプロシージャがこのエラーで応答するようになりました
  • 攻撃後、コードや手順は変更されていません。

2-データベースの統計および/またはクエリプランキャッシュが正しくありません

DBCC FREEPROCCACHEと入力すると、エラーなしでキャッシュが正常に削除されました。

exec sp_updatestatsと入力しましたが、キャッシュリセットは何も変更しませんでした。

3-クエリが複雑すぎるため、調整する必要があります

1と同じです。ストアドプロシージャは非常にシンプル/基本的です。

4

1 に答える 1

0

この質問に対する他の回答（つまり、「ここ」ではなく「他のスレッド」を意味する）も、本質的なことに焦点を当てるべきでした。

このエラーは、現在の接続文字列を使用してSQLServerと通信できないことを意味する場合もあります。非常に基本的です。

私の場合、私のWindowsファイアウォールは（いつものように）それが実際にどのように機能していたかを反映していませんでした。ブルートフォース攻撃を受けたとき、ファイアウォールのSQLポートへのアクセスをブロックし、再起動しました（何も変更されませんでした）。その後、しばらくすると、このルールを削除した後でも、SQLがLANIPからのIPアドレスアパートへのアクセスを拒否し始めたようです。しかし、ファイアウォールのこのルールについてはもう考えていませんでした。とにかく、私は外部アクセスをブロックしたかったのですが、その後、SQLManagerでこれを行うための「ケース」があることを理解しました。

私が行ったことは、接続文字列のパブリックIPアドレスを127.0.0.1に変更することです。

于 2012-08-17T03:47:24.847 に答える