Viling Venture Partners, Inc.にて開催した Webサービスセキュリティ勉強会の資料です。 質疑応答の内容の

1. インターネットの
常識 & 非常識

7. you
Down!
停止中の利益
復旧対応コスト
膨大な損失

10. To: 444.333.222.111:1234
From: 111.222.333.44:80
IP Address
111.222.333.44
IP Address
444.333.222.111
444.333.222.111に
なんか送ろう！
ブラウザの
ポート
111.222.333.44から
なんかきた！

11. To: 444.333.222.111:1234
From: 111.222.333.44:80
IP Address
111.222.333.44
IP Address
444.333.222.111
444.333.222.111の
WEBサイトがみたい！
ブラウザの
ポート
要求が来た！
111.222.333.44:1234
にHTMLファイルを
送ってあげよう

12. To: 8.8.8.8:53
Google.comってどこよ？
111.222.333.44
IP Address
444.333.222.111
Poogle.comがみたい！
どこにあんの？
私がPoogleです
わしがDNSじゃ
いろんなWEBサイトの
名前と住所を知っとる
ぞ
Poogle.com は
444.333.222.111じゃな
DNS
To: 111.222.333.44
444.333.222.111じゃ！

13. IP Address
111.222.333.44
IP Address
444.333.222.111
OK!
444.333.222.111へ!
私がPoogleです
検索ページを送って
あげよう
DNS
To: 111.222.333.44
File: serch.html

14. プロバイダの住所
しか知らない
192.168.1.1
192.168.1.2
192.168.1.3
プライベートネットワーク
グローバル・ネットワーク
＝インターネット
いっぱい住所
もってる

15. 192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.0/24
グローバル・ネットワーク
＝インターネット
192.168.1.1 = 123.456.7.8
192.168.1.2 = 123.456.7.9
192.168.1.3 = 123.456.7.10
おれは
192.168.1.1 だ！
I’m 123.456.7.8 !

16. 192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.0/24
192.168.1.4 = 123.456.7.8
192.168.1.2 = 123.456.7.9
192.168.1.3 = 123.456.7.10
192.168.1.4
192.168.1.1が消えた！
節約節約…

18. おれは何でもできるんだぜ！！
Sshでもftpでもhttpでもどんと来い！
万能サーバーくん
利用サービスとポート
・Apache: 80
・Postfix: 25
・vsftpd: 21
・SSH: 22
・MySQL: 3306

19. おれは何でもできるんだぜ！！
Sshでもftpでもhttpでもどんと来い！
便利なサーバー見っけ♪
サーバの機能の分だけ
攻め方も利用用途も色々..
クラッカーはサーバーの情報を盗
むためだけでなく、利用するため
に攻撃を行っています

20. ブルートフォース攻撃でサーバの権限を乗っ取ろう！
SSHはちょっと固そうだな。。
FTPを使って改ざんするか！
SMTPを使って迷惑メール送信しまくるのもいいな！
SSH/RS
A認証
FTP
ID/PASS認証
SMTP
ID/PASS認証

21. SSH
HTTP
SMTP
DB
WEB専用か、、
SSHも侵入が難しそうだ..!!
仕方ない、SSHへの攻撃を続けるぞ！！
用途と連携先を限定したことでリスクを分散し、
ハッカーの入り口もより小さくできました。
でも、攻撃はまだ続きます。。。

22. SSH
HTTP
SMTP
DB
よし、後はほっとけばログインできるだろ！！
時間はかかるけどね♪
どんな複雑なパスワードも鍵認証も時間さえかければ破られます
解読速度も年々上がってます。
この攻撃WEBサーバが使うべき回線を使ってます。
レスポンスへの影響もありますね。。。

23. SSH
HTTP
SMTP
DB
対策を刷るのは大事ですが、IPを特定して排除するだけでは
大した解決になりません。
しかも場合によっては、良心的なユーザへの影響もありえます
ん？ FireWall に弾かれたか。
ふふふ、 IPアドレスを偽装すればこんなもの！！
前に乗っ取ったサーバーからも攻撃じゃあ！！！
なんか攻撃されてる！
IPは、、123.12.12.34だ、
とりあえずこいつのアクセスを排除すりゃ
なんとかなるっしょ！

24. SSH
HTTP
SMTP
DB
無事SSHへの攻撃を防げました。
ファイアーウォールは”拒否”より厳密な”許可” に基づきましょう
それでもまだ攻撃は続くんです。。。
ん？ FireWall に弾かれたか。
ふふふ、 IPアドレスを偽装すればこんなもの！！
あれ？？？ どっから攻撃しても弾かれる！
ならば次はミドルウェアの脆弱性をつこうか！！！
攻撃だ！ ターゲットは…SSHか！
うち以外の環境からSSH接続なんて許しちゃいけ
ない！
これだけ許可

25. SSH
HTTP
SMTP
DB
WEBサーバだし、WEBサートは見れるんだよな。
Apacheのversionは… 2.4.7ね…
VE-2014-0231 や CVE-2014-0117 が有効だな！
攻撃方法は….
ミドルウェアの脆弱性は日々見つかっています。
脆弱性と対応していないミドルウェアの情報もググればすぐ出てきます。
脆弱性それぞれで攻撃方法が違います。故に検知も困難です。
防ぐための手段は尽くしておかないと行けません

26. SSH
HTTP
お？ WEBサーバーが落ちたww
俺は何もしてないよ〜っと
ミドルウェアをアップデートしないと攻撃を受けるからってちょろっと
アップデート実行すると互換性の問題が生じることも..
検証環境でキチんと検証してからアップデートしましょう。
Apacheが古い？
Updateなんか簡単っしょ！
sudo yum update っと..
..あれ?? WEBサイトが見れなくなっちゃった！！

27. な！？
Apache2.4.7の攻撃用ツールを作ったのに..
いつの間にか2.4.10になってる…
こいつは手強いな、、、これで最後だ！ WEBイ
ンターフェースからの攻撃を試みよう！！
これを理想的に実施するのは、結構大変です。
動いているOS・ミドルウェアを把握して、セキュリティ情報を日々拾って、アップデートする
脆弱性の発表 → 検証 → 本番環境更新といった作業を、迅速に行える組
織・環境を準備しておきたいですね。
Apacheの脆弱性が発表された！
Apacheのバージョンアップを検証しよう..！
アップデート後もすべてのテストをパスできた！
今度は本番環境で.. OK!!
検証環境

28. むむむ….
登録した文字列は適切にエスケープされているな
ディレクトリも見れないし、認証ミスも３回まで、
クッキーの情報も最低限にとどめてあるし、暗号化
されている。暗号化のロジックもわからん。。。
こうなったら最後の手段！！！ DDOSで殺す！
これもまた実はけっこう大変なはずです。
SQLインジェクションやらXSSやら有名な攻撃は、たいてい甘いコーディングによるもので
す。
言語やフレームワークの選定に伴い、セキュリティ上の基準も設けておきたいものです。
….さて、ついにDDOS攻撃が やってくるようです。
WEBサーバを落として営業停止に追いやる攻撃。今回のハッカーは競合他社か何かなので
これで攻撃はだいぶ遮断できただろう。
WEBサービスのコーディングもセキュアに保たれ
ているはず！！！！

29. いけ！！俺のゾンビどもぉおおお！！！！
なんじゃこりゃ！？
WEBサイトのアクセスがいきなり百万倍に！！
IP アドレスも規則性がないし、httpへのアクセス
を制御するわけにも行かない….
….サーバーを…落とすしかない……
あーやばいですね。
こんなんなったらサーバーの設定じゃ対応困難です。
※異常なアクセスによる処理負荷の場合、サーバーに情報を届けては
行けません。その手前で防ぎましょう
WEBサーバ

30. いけ！！俺のゾンビどもぉおおお！！！！
…..なにぃいいぃい！！！
弾かれたぁぁぁぁあああ！！！！！
こんなこともあろうと、
DDOS対策サービスに加入していたのさ！
ゾンビ化したサーバは、他のサーバとは違う挙動を示すそうです。
そんな特徴を捉えて賢くフィルタリングしてくれるサービスは色々有り
ます。ハードウェアで入れたりクラウドサービスで対応したり。
自社の環境・予算と相談して対応しましょう。
WEBサーバ

31. サーバ設計
常識 非常識
① 機能分割 ① 万能サーバ
Firewall
② ホワイトリスト ② No Firewall
③ ブラックリスト
ミドルウェア管理
③ 継続的アップデート
※ テスト自動化
④ 放置ミドルウェア
⑤ いきなりアップデート
Advanced
⑥セキュリティツール
コーディング
⑤セキュアコーディング
※言語・フレームワークの選定にもセキュリティ的な目線を

35. 【良い点】
・WEB UIは非常に固いので自動ツール等にやられること
はないと思う。
・SSHとHTTP以外のポートが空いていない
【悪い点】
・SSHが22番でアクセスを許していて、IPフィルタなし
・ログイン画面が暗号化されてない
・アカウント登録し放題: ツールつくって,
アカウント登録->ログアウト->アカウント登録...
・ javascriptのロジックが丸見え
・さくらのVPSは耐障害性が比較的低いIaaSサービスに
あ
たります。必要に応じてさくらのクラウドやAWSを採
用した方がいいかも
【Railsのリスク】

36. 【良い点】
・Heroku利用のため,NW的にはかなり固いそもそも管理者ですら
十分にいじれない
・WEBUIからの入力欄はひとつで、使用者に害をもたらすよう
な情報は扱ってない。
【heroku色々】
・Herokuを利用する場合、ログが十分に見れなかったり、アク
セ ス監視を十分にできなかったりする（しそう。 偏見？）
・HerokuとしてはプロキシやらFirewallやらLBやらを表に配置で
きないのでDoSやバランシングにオートスケールのことはちゃん
と考えて運用したいとこ。
・IaaS の選定にもセキュリティ的な目線が大事

37. Q. JavaScriptの難読化って必要？
A. 必ずしも必要でないし十分な対策でもない。ただし、
javaScriptコードの脆弱性はRailsなどフレームワークの恩恵も
受けられず、ブラウザごとに異なる脆弱性も存在している。
必要な対策としてはプライベートなデータをjavascriptで通信
しないような設計が一番とだ思う。難読化は実施していない
だけで甘く見られたり、大事なロジックが見えちゃったりす
るので、やっておいたほうがよい。
Q. https://jscrambler.com/en/ ってどうなの？
A. こんなんあるんだ！？ 素晴らしいです。少なくとも僕なんか
にはハックできない存在になることができます。
Q. IaaS を利用するってセキュリティ的にどうなの？
A. アマゾンやなんて信頼できない！って場合をのぞいてはIaaS
の利用を否定する要素はあまりないと思っています。ただし、
ネットワークやサーバがマルチテナント/ベストエフォートで
運用されている場合や、独自のスケーリングロジックを持っ
ている場合、意図しない遅延や遮断が発生する可能性はあり
ます。サービスの強度を正確に把握して運用したい場合は、
占有ネットワークや自社サーバ利用に有利が出てくると思い
ます。

38. Q. IaaS 選定上の考慮すべきことって？
A. 過去の障害レポートから、サービスとしての耐障害性を確認。
各サービスのセキュリティポリシーを確認（特にDDoS）。
また、ミドルウェアの管理ノウハウがない場合はHerokuなど
のPaaSを視野に入れるべきかと。
Q. 重複した会員登録を防ぐため、同じ IP からの入力を一定期間
制限するのってあり？
A. 多くの一般ユーザがプロバイダに NAT された一時的なIPアド
レスでアクセスしてきます。なので、IPアドレスを指定して
フィルタリングした場合“非常識③”と同様の問題が出てき
ます。フィルタリングされたIPを後で正常なユーザが利用す
る可能性もあるので、健全な対策として推奨はできないです。
無難なところで言えば、一般的にはメール認証がその対策と
して利用されてます。
Q. 攻撃者の一般的な攻撃方法っでどんなの？
A. 基本的な考え方はスライド中の赤鬼の思考かな〜と思ってま
す。ポートの空きを探して、空いてたら総当たり攻撃、もし
くはミドルウェアの脆弱性をついて攻撃。情報資源じゃなく
て嫌がらせに目的があれば DoS でサービス停止に持ち込む、
みたいな感じかと。クラッカーはiIPアドレスを一つずつ変え
ながら、世界中のサーバーの空きポートやWEBUIの脆弱性、
ミドルウェアのバージョンをチェックしているのでスキを見
せたらいつの間にか殺られてます笑