1行でデータベースサーバーにDoS攻撃を仕掛ける方法

40 Mbpsは、DoS攻撃に適したトラフィックです。 これは、サーバーへのインバウンドトラフィックの急激な増加です。 サイトは勇敢に開催されました。 異常に高いトラフィックの急増の開始時間は、1つのメジャーリリースをレイアウトする時間と疑いなく正確に一致しました。

リリースには何百もの異なるphpファイルの順序の変更が含まれており、変更のリスト全体を閲覧することは非常に困難であったという事実により、状況は複雑でした。 tcpdumpは、トラフィックがPostgreSQLデータベースサーバーに成長することを発見するのに役立ちました。 円は狭くなりました。

最初の仮定は、SQLクエリの1つで制限が忘れられ、単一行ではなくデータセット全体が選択されることでした。 しかし、このリクエストが何であるかをどのように知っていますか？ PgFouineは救助に来ました。 2分でデータベースサーバーのログを分析し、ここにある-悪の源！

select oid,typname from pg_type

ここにあります-何千回も実行されている制限のない要求。 しかし、ソースにはこのリクエストがありませんでした！ 彼はどのファイルのどこにも会いませんでした。

問題の原因はphp関数pg_field_typeに隠されていましたが、これは選択結果の列タイプのシンボル名のみを返していました。

この問題の根源は少なくとも2005年ですが、これまでのところ公式ドキュメントには、PostgreSQLにアクセスするためのphp-pgsqlライブラリがDBMSへの追加クエリを作成し、1000を超えるデータ型の完全なリストを選択するというメモが追加されていません。

おそらくあまりアクセスされないサイトでは、これはパフォーマンスにまったく影響しませんが、ロードされたプロジェクトでは深刻な問題を引き起こす可能性があります。 pg_field_type関数の代わりに、そのアナログ名であるpg_field_type_oidを使用することで問題を回避しました。これは、シンボリック名ではなく、データ型の内部oidを返します。 はい、これによりコードの可読性がわずかに低下しましたが、チャネルを40 Mbitデータベースサーバーにオフロードしました。

おそらくTrue FastCGIを使用した場合、この問題は発生しなかったでしょうが、 phpはほんの数か月前に準備が整い 、問題は約6年間存在していました。

ソースコードでpg_field_typeキーワードを探します-おそらく、PostgreSQLサーバーの困難な生活を大幅に緩和できます。