Translate

2013年2月13日水曜日

個人で作ったGoogle App EngineサイトがDDoS攻撃を受ける

2017年10月24日追記:
この記事書いたのが2013年2月13日なので4年以上経過して
ワタシ的には今更なのですが..

ようやくGoogleが対策乗り出してくれました。

Google Cloud Platform Japan Blog
AppleEngineファイアウォールをサポート
https://cloudplatform-jp.googleblog.com/2017/10/App-Engine-firewall-now-generally-available.html

DDoS 対策はコレ使えば、良いと思いますよ。




具体的な日時やサイトURLの記述は避けるが
私が構築運用しているApp Engineで作ったサイトが
DDoS攻撃を受けた。

2010年の夏に構築したサイトで
画面数5のすごく小さなアプリだったのだけど..

Google APIの使用は、
Bigtableへアクセスと
アンケート結果をメール送信する
この2つだけ、
無課金で運用していた。

ある日、
ユーザからアクセス出来ないという

真っ白な画面に
Error: Server Error
The server encountered an error and could not complete your request.

If the problem persists, please report your problem and mention this error message and the query that caused it.
というメッセージのみの状態が続く障害が発生。

大した処理もしていないので、
運用し始めた頃から
ソース自体は変更していなかった。
#リンク先の変更などの静的変更は数度のみ

しかもたまにトップページが出たり、
内部でExceptionが出た時表示する画面へ
すすんだりして動作が安定していない。

なので環境面をまず疑った。
MasterSlaveからHigh Replicationへ移行しろという
コンソールメッセージがでていて
面倒臭がってこれまでやっていなかった。

なので
ははあ、Google M/S型アプリへのリソース配分変えたな
と誤解して
HRD環境へアプリを移行させた。

移行したのでアプリIDがかわり(URLはかわらない)
制約も一旦クリアされるので
その日は快適に動作していたのだけど..

今度は制約クリア時刻(午後5時)から深夜までは動作するが
その後エラーページしかでなくなった。
1日のうち1/3も動作しない時間が..

で、ログを見たらたくさんアクセスしていて
DBアクセスのCPU時間を超過している事がわかった。

もしやとおもいコンソールの
Blacklistを見ると..
でるわでるわ1000アクセスしたIPアドレスが
ちょろちょろと。
#このページ1時間でフルクリアする









しかも別の時間見た時全然別のIPアドレスでアクセスしている。
課金してたら恐ろしいことになってたかも..






自慢じゃないが1ヶ月でやっと1000アクセスするくらいのアプリだ。
キャンペーンもしていない。

ログをジーっとみつづけていたら
法則がわかってきた。
・IPアドレスはランダム、クラスA~Dまでふんだんに使用している
・1つのアドレスからのリクエストは1000件まで
・ブラウザもAndroidからWindows、MacのSafaliやMozilla、Firefoxさまざま
・GET/POSTパラメータを駆使
・GETパラメータのパラメータ値がいつも一緒
・3分で1つのIPアドレスからのアクセス1000件を達成している
・6パラでアクセスしている風を装っている

IPアドレスを1つづつnslookupしていたが、
ランダムだということがわかってきて諦めた。


最後のパラメータ値が一緒だというところから
ツールなりサーバなりで自動でリクエスト投げてきている
可能性が高い。


..人生初、DDoS攻撃。
また、大人の階段を登ってしまった..

Blacklistがきっちり1000件アクセスでならんでいるのは
GAE環境が同一IPを1000件でロックアウトさせるのか、
ツールのループが1000件で次のアドレスを使い出すロジックになっているのか..

DoS攻撃の場合、アクセスを禁止するIPアドレスを設定できる
dos.xmlというファイルがあるが、
(同一サーバ経由の擬似かもしれないが)DDoS攻撃だと使えない。

アプリで制約にかかりそうなロジックを退避させる。
Cookieで排除してやろうかとも思ったが
ツールならCookieを仕込まないで直接Socketしてるかもしれない。
もうべたな方法で治すしか無い..

やったことは
ダイレクトにURLエントリポイントにGET/POSTしても
Google APIを消費しない
ようにロジックを変更した。
あと、とあるPOSTパラメータをチェックして
これがないとエラーページ(静的)へ飛ばすようにした。

今のアプリ、男らしくServletを使っているけど、
Google App Engineの構造上、
Google Web Toolkitとの親和性がいいはず。
粗方の処理はロジックをJavaでかきJavaScript変換して
ほとんどをクライアント側でやってしまい、
DB保存やDB照会を非同期で処理させてAjaxで画面表示する..


..そろそろ書きなおそうかな..
げっGWTもう2.5.0だって..
こりは時間がかかるかも..

0 件のコメント:

既存アプリケーションをK8s上でコンテナ化して動かす場合の設計注意事項メモ

既存アプリをK8sなどのコンテナにして動かすには、どこを注意すればいいか..ちょっと調べたときの注意事項をメモにした。   1. The Twelve Factors (日本語訳からの転記) コードベース   バージョン管理されている1つのコードベースと複数のデプロイ 依存関係 ...