Web application を host する secure な network 構成 の続き
前回では secure な基盤を構築することを説明しましたが、その環境でももちろん攻撃方法は存在します。全部説明するのは厳しいので、ここでは Web, AP, DB に実装された custom application にはまったく脆弱性が存在しない前提で話を進めます。前回も登場した下記 network (図1) を題材にしましょうか。
図1 Web, AP, DB Management の network をそれぞれ分離した sample
通常重要な data は DB に格納されるため、今回の攻撃の最終目標は DB から情報を引き出すこととします。
さて、client から DB の情報を引き出すためにはどうしたらよいでしょうか？
Client が直接通信できるのは、client - Web segment に存在する router, firewall, Web server のみです。したがって、攻撃をする場合必然的に router, firewall, Web server へまず攻撃を行うことになります。
さて、この router, firewall, Web server に設定上の不備があった場合どうなるでしょうか？
Web server の設定がまずかった場合なんかは特に悲惨です。乗っ取った Web server を踏み台にして AP server へ攻撃を仕掛けます。また、構成によっては Management segment を通じて Web server から直接攻撃を仕掛けるでしょう。また、server は network 機器に比べてより多くの機能を持っているため、network 機器を乗っ取るよりも簡単に攻撃を仕掛けることが可能というのももちろんありますね。
Network 機器の場合でも、それを乗っ取ることにより攻撃は可能ですね。Network 機器に搭載されている telnet や SSH 等を利用可能な状況であれば攻撃は server 同様非常に容易です。
# こんな状態あったら、アホ過ぎて目も当てられん。。。
なので、Web segment に存在する機器は細心の注意を払って、絶対に脆弱とならないように設定を行わなければなりません。
では、設定がまったく問題なく構成されていれば安全でしょうか？
もちろん違いますね。自分のところで作成した application に脆弱性が無くても、OS, middleware 等の脆弱性は頻繁に発見されています。したがって、脆弱性情報を日頃から check し、適宜対策を行うことが必須です。
また、OS 自体の security 機能を有効活用することもまた重要です。一般的な server OS では、user 毎に異なる権限を与えることが出来ます。Client から直接攻撃の受ける可能性のある service をより低い権限で実行させることにより、その service 自体に脆弱性が存在しても影響を受けにくくすることが出来ます。
# これに関してはまた別の機会に解説します。