2016年06月 Hardening Project 2016 / Hardening 100 Value x Value 参加した。
2016年06月某日。とあるチームで参加。
内容は下記。
特徴
与えられた競技環境である、ECサイトと関連するシステムを守り切り、売り上げの最大化を目指す。
採点について、今回の大会では下記のようなパラメータにて各チームが評価された。
・見込み販売力 (Sales Potential)
・技術点 (Technical Merit)
・顧客点 (Customer Impression)
・対応点 (Incident Response)
・経済点 (Market Creation)
・協調点 (Information Sharing)
各チームのスコア(結果)は、下記より参照できる。
ルール上ではまり易い点
前日に配布された資料の十分な読み込みが必要。
競技後の評価や不慮の事故や調査等で運営者から利用されるアカウントのについては、下記のようなルールがある。
・該当アカウントでのログオン可能にしておくこと
・該当アカウントでのsshを許可しておくこと (※)
・該当アカウントの sudo の設定値を変更しないこと。
・パスワードを変えないこと(sshのキーでログインしているっぽいので関係ないかも。)
※ sshを許可しておくこと = 最終的に競技環境のどこかしらから運営者がsshでログオンするため、その経路をFirewall等で止めてしまうとNG。
外部向けのFirewallの設定では、競技環境のDMZのサーバがすべて1:1のStaticNATで外部に公開されている。一般的に考えると、公開サイトは、NAT公開されてて良いとは思うが、dbやlogを管理するサーバ、proxyなどは、NAT公開が必須ではないし、外部への不要な通信(例えば、C&Cサイトへアクセスしてしまうなど)を排除すべく外部へのNAT公開や、IPマスカレードでの外向けアクセスを停止する方が本来は正しいとは思う。
仮想基盤特有の留意点
競技者達は、StarBED内に構築された、仮想のネットワーク環境、仮想マシンで競技します。それらは、各チーム毎にそれぞれに比較的フェアな条件で構築されており、それなりのスペックの仮想マシンが動作している。しかしながら、ディスク構成としては、チーム内の仮想化マシン間でシェアしているため、特定の仮想マシンのIO負荷が上がってしまうと、同じディスク(同じRAID Group)に属している別の仮想マシンのIOに影響が出てしまう。
例えば、webサーバでディスクにランダムアクセスが集中しているような場合に、同じRAID Groupにある、dbサーバのIOパフォーマンスが出ないといったことが発生する。
同一RAID GROUP内の仮想マシン達でIO負荷が集中するような処理をcronで回す場合には、処理時間をずらすなどの考慮が必要となるのかもしれない。
運用監視
サイトの監視を行い、改ざんされたり、サイトが停止していたりすることを把握する必要がある。サービス監視、プロセス監視などが必要となる。
8時間という限られた時間である点と、発生するインシデントが頻繁に襲ってくるような競技の特性があるため、サポート端末(Windows)のブラウザより、F5でのサイト監視が最も有効な説有。tail -f とかで 各サービスのログを監視しておけば、それでもわかるのかも。
もしかしたら、ChromeのAuto Refresh プラグインを動かして監視とかがいいのかも。
尚、競技用に作成したが、それほど役に立たなかった監視ツールを一応置いておく。
dnsが死んだ場合には、postfixの設定次第で、メールの送信ができないケースもあると思われるため注意が必要。/etc/postfix/main.cf の設定で、MTAに向ける設定がIP指定か、ホスト指定か、それともMXで動くのかなどにより監視サーバのメールの設定周りにも注意が必要。
改ざん検知
aideを使った。CentOS6.x でrpmで入れられてサクッと動かせるので便利。
一般的な運用とは異なり、頻繁にチェックが必要となると思われる。チームでは30分単位で動作。
8時間という競技上、改ざんを本当に確認すべきか、さっさとバックアップからコンテンツを戻す方が早いのかが結構悩ましいところではある。
各サーバからメールで通知する場合、DNSが死ぬと役に立たないケースがあるので、postfixの設定なども気を付けた方が良い。
