ネットワーク運⽤と そのセキュリティ対策 ·...
TRANSCRIPT
ネットワーク運⽤とそのセキュリティ対策
和歌⼭⼤学学術情報センター
川橋 裕
Special Thanks To…• 本会場にお越しの皆さま• 経済産業省近畿経済産業局• ⼀般財団法⼈関⻄情報センター• ⽇頃トラブルシュートにつきあってる同僚• 研究室の学⽣たち• 家族
2
Profile• 和歌⼭⼤学学術情報センター
• 専任教官，講師• システム⼯学部・システム⼯学研究科兼務• 川橋研究室(学部・⼤学院の学⽣)
• ⼤学全体のネットワーク・コンピュータを管理• 20年近く，レンタルシステムとネットワーク• 仕様書，調達に係る⼊札案件，技術審査など
• 最近は情報危機管理コンテストなど• 経済産業省と⽂部科学省
3
宣伝ですが…「情報危機管理コンテスト」で検索・経済産業⼤⾂賞と⽂部科学⼤⾂賞を団体に授与・JPCERT/CC賞を個⼈に授与
- インシデントレスポンス，顧客対応，広報，報告を織り交ぜた実践的で総合的な競技
- 全国の⼤学・⼤学院・専⾨学校から毎年20チームほど
5
6
もうひとつ宣伝ですが…「enPiT-Pro」で検索・(社会⼈のための)
成⻑分野を⽀える情報技術⼈材の育成拠点の形成・国内7⼤学
IT(ICT)を再度学びたい社会⼈の⽅々に
本学で考えている不埒なこと・「教える」層を厚くする・現場で仕事を「押しつけられている」⽅々に光を・前述のコンテストで学⽣たちをきりきり舞いさせる・そこで学⽣との接点をもってリクルートにつなげる
Agenda• ⼀般的な情報危機管理のお話
• 最近の事例も踏まえて• Google検索結果に「クラックされた可能性」
• コンテンツの分散管理とプログラムの把握• アノニマスによる攻撃および防御の紹介
• 和歌⼭ですし…• コンテストと⼈材育成
7
情報セキュリティと情報危機管理情報通信研究機構(NICT)「CYDER事前学習」より
8
語句の意味• 情報セキュリティ
• 企業の情報システムを取り巻くさまざまな脅威から，情報資産を機密性・完全性・可⽤性（三⼤要件）の確保を⾏いつつ，正常に維持すること． 情報資産を正当な権利を持った⼈だけが使⽤できる状態にしておくこと．• JNSA：NPO⽇本ネットワークシステム協会
• 情報危機管理• 情報資産を危機(脅威)から護りつつ事業を継続していくこと．細かい
定義はない．
9
情報資産とは• 情報と情報システムおよびそれらを維持および保護するために
必要なもの• ⽂書(紙)，電⼦⽂書，情報システム内のデータ，• OS，アプリケーションソフトなど• コンピュータ，ネットワーク機器，記録媒体• 建物，空調，電源など
10
脅威とは• 標的型攻撃(特定組織の情報を狙うサイバー攻撃)
• Webサイトの改ざん，マルウェア(※)感染• 不正アクセス，内部犯⾏
• ※不正または有害な動作をおこなう意図で作成された悪意あるソフトウェアや悪質なコードの総称
• ⾮標的型攻撃と故障・ヒューマンエラー• 愉快犯などによる不特定多数への攻撃など
• 前項との切り分けが重要• 攻撃でないことの証明が⼤変⾯倒，横のつながり
• ⾃然災害，盗難などの犯罪
11
脆弱性(ついでに)• 脅威を引き起こす・拡⼤させる要因となるもの
• OSやアプリケーションのバグ(不良な部分)• パラメータ設定の不備など• 不⼗分なセキュリティ教育，技術対策，組織体制
• 「脅威」＋「脆弱性」＝被害発⽣• 「脅威」はなくならない• 「脆弱性」をなくす• 「脅威」と「脆弱性」の間に障壁を⼊れる• 障壁＝ハード，ソフト，⼈材，⾯倒な⼿続き
12
セキュリティ「CIA」• 機密性(Confidential)
• 許可されたものだけが情報にアクセスできる• 許可が無いと読めない，など
• 完全性(Integrity)• 情報や情報の処理⽅法が正確で完全であること• 許可が無いと編集できない，など
• 可⽤性(Availability)• 許可されたユーザが必要な時に情報および関連する情報資産にアクセ
スできること• サーバ壊れちゃ仕事にならん，許可が無いと使えない，など
13
振り返ってみましょう• これまで⾝近なところでセキュリティ事件や事故の事例を⾒聞
きしたことはありませんか？• セキュリティ事件や事故を未然に防ぎ，また万⼀の時に被害を
最⼩限にとどめるためには，⽇ごろからどんな対策・対応が必要でしょうか？
• もし今，職場で事件や事故が発現したら，あなたはどのように対応し，周りの同僚にはどのようにアドバイスしますか？
• 対応ルールや⼿順は策定されていますか？またその対応は全員に周知徹底されているでしょうか？
14
運⽤の落とし⽳
15
ITセキュリティを維持するには• システム設計と運⽤設計
• 前者は「〜させる」「〜させない」設計• 後者は「〜したか」「〜しなかったか」設計
• ⼈の⾏動の全てを型にはめることはできない• 「守りの堅い城ほど〜」
• 過度なシステム設計は業務をできなくする• 例：県教育委員会の教育ネット• 「働き⽅改⾰」
• PDCAサイクルのPlanのみがシステム設計
16
出典：IPA(情報処理推進機構)「情報セキュリティマネジメントとPDCAサイクル
」17
運⽤って何？• 偉い⼈はシステムを⼊れたことだけ知ってる• 偉い⼈はそれがどんなトラブルを⽣むのか興味が無い
• 「買ったんだからサービスしてくれる」• すでにサービスに⾦がかかる時代
• ⾃分で抱えるか，⾃分で持たないか• 前者は運⽤そのものを⽀えるスタッフが必要
• 運⽤や再設計に融通が利く，リスクを取る• 後者は運⽤そのものも投げてスタッフを持たない
• 業務スタイルをシステム&運⽤に合わせて⼤幅変更• 上記リスクは減るが新たなリスクが…
• ファイアウォールのルールが棚卸しされずに増え続けるなど18
すべてはバランス• リスクを取るか，軽減するか，移転するか
• 最後は保険や委託など• 通信教育事業者は200億円を拠出
• カネをかけるか，⼿間をかけるか• セキュリティとは「⾯倒なもの」• リスクヘッジ以上のとらえ⽅を模索する必要性
• 運⽤に光を！• 導⼊は実績，運⽤は現場で，は良くある
19
⾃分とこの検索結果なんて⾒ない⾝近な事例-1
20
ある⽇突然外部から• 「おたくクラックされてるって」
• 外部に異動した教官から連絡• Google「このサイトは第三者によってハッキングされている可能性が」
• メッセージの理由は「スパム広告の存在」• リンク先にはどこも変化がない• クリック⼩僧では⾒つけられない
• サイトの信頼を無くすための攻撃オプション• 「修学旅⾏」「アップローダ」というオチ• 有名なアップローダだが4桁のパスコードをブレイクするツールあり
21
ファイル構成DocumentRoot
⼤学コンテンツ
ユーザコンテンツ
public_html
ファイルアップローダ
スパム広告
・付属学校教員がおいたアップローダに脆弱性・www権限が取られてトップドメインに⾮リンクでスパム置かれる・Googleにごっそりキャッシュされる
22
リンクあり
リンクあり リンクなし
対応(インシデント・レスポンス)• 膨⼤なログの解析
• アップローダと同不正利⽤の発⾒• スパムの設置
• スパム広告を保全• プログラム設置のガイドライン
• ⼀⾔⾔いなさいよ• トップドメインと差別化
• 広報委員会と運⽤の壁• 意図しない内部犯⾏(当⽅に処分権限無し)
23
標的型メールを実際に受信する⾝近な事例-2
24
標的型メールの恐ろしいところ• 「⾃分は⼤丈夫」と思い込むこと
• 私でもヒヤヒヤ• 添付は知ってる⼈からのみ開く
• 知ってる⼈からなのかメールのヘッダで調べる• Webリンクは開いて良いのどうか調べる
• マルウェアは仕込まれていないはチェック• 代理アクセスして画⾯をチェック• ようやくリンクを開く
• 「開いた⼈がどれだけ居るか調べろ」という声• インターネットは送信記録がないという本質
25
前提環境
⼤学のメールサーバ(メールをやりとりする)
⼤学のWebメールサービス(⼤学ユーザが学内外で利⽤)Active!Mailというオンプレミス(⾃前で持ってるサービス)
メール
学内ユーザ(学内外で利⽤)
※⾃前のオンプレミスなので外部から⽂句⾔われることは無い 26
標的型メール(スパム)受信
27
件名: Upgrade Required送信者: "Active Mail" <[email protected]>送信⽇時: 2017年06⽉30⽇(⾦) 09:28:28宛先: "Active Mail" <[email protected]>
！Active Mail Upgrade Required！ メールボックスクォータがいっぱいですこれにより、メールボックスに障害が発⽣する可能性があります。または、メールを受信できなくなる可能性があります。メールボックスを引き続き使⽤するには、すぐにメールボックスのクォータをアップグレードする必要があります。 このサービスは無料です。
今すぐアップグレード<http://seo-force.com/wp-admin/user/activemailUpgradeNow/>
アップグレードが完了すると、メールボックスは効果的に機能します。ご協⼒ありがとうございます！アクティブメールサーバー著作権2017-アクティブゲートウェイ
28
29
何が問題？• 本学のユーザアカウントを奪う気満々
• ⼤学のロゴマークまで使ってつり上げる• 奪って何をする気なのか？
• 本学ユーザになりすまして全世界にスパム配信• 当該ユーザの情報を抜き取る• 当該ユーザの権限でbotを仕込み攻撃• …などなどが可能
30
ボットネット（botnet）はあなたのPCを「犯罪の道具」にする
遠隔操作⽤サーバ
攻撃者
Bot（ウィルス）
指令を設定
Botがサーバに接続
Botへの指令を送信
企業等のWEBサーバ
⼤量アクセスによる停⽌
⽇本のPCの２〜２．５%が感染合計数⼗万台？
侵⼊経路はメール・Web・ネット直接など
迷惑メールの⼤量ばらまき
カードの情報アカウントなど大量漏洩！
31
対策• アカウントを盗られるとどうしようもない
• 「⼤したデータは⼊ってない」は通⽤しない• 学外からアクセスさせる以上，制限できない
• メール内のリンクを調査するシステムがない• 管理者が代わりに踏むか⾃前で警戒するか
• 誰がそのリンクを踏んだが追跡する仕掛け• パフォーマンスとの兼ね合い• よくプライバシー問題と並べられる• 電話の通話記録を同じだと突っぱねている
32
33
テキスト形式でメールを⾒ると
34
aguseなどでサイト調査すると
35
アノニマスによるSLOW HTTP 攻撃
36
Slowlorisとは• 遅延攻撃• 便宜上，まとめてSlowlorisと呼ぶ(かわいい)
• 1バイトずつ送って通信を⻑時間維持する• POSTによるapacheの圧迫がもっとも強烈で多い• HTTP内のKeepaliveを⻑くしてセッション維持
• ファーストフードのカウンター• 実はサーバは窓⼝が256個しかない• 256のリクエストなら⼀⼈からでもできちゃう• ⼀般的なDoS攻撃は1秒間に100万アクセスなど
37
POST / HTTP1.1HOST: ----User-Agent: ----Connection: keep-aliveKeep-Alive: 900Content-Length: 10000
Keepalive で900秒とっておいてPOSTするからと⾔ってPOSTしない
38
攻撃を受けると何か起こるか• Webページが閲覧できない
• 全ツリー全滅• CMSなど転送先は直接指定で⾒える
• 攻撃を受けてる最中はログに何も出ない• Timeoutしてからログに出⼒される• 時刻情報がずれて記録される• UserAgentがバラバラ（POST）
39
b115469.yse.yahoo.net - - [02/Jan/2016:08:06:58 +0900] "GET /~kikuchi/wiki/jp/index.php?pluginxx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Googlebot/2.1xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Googlebot/2.1xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/4.0xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "YahooSeeker/xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Googlebot/2.1xx.143.192.194 - - [02/Jan/2016:08:06:14 +0900] "POST / HTTP/1.1" 400 226 "-" "YahooSeeker/xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/5.0xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "YahooSeeker/xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/5.0xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/5.0 xx.143.192.194 - - [02/Jan/2016:08:06:15 +0900] "POST / HTTP/1.1" 400 226 "-" "Googlebot/2.1 xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/5.0xx.143.192.194 - - [02/Jan/2016:08:06:16 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/5.0xx.143.192.194 - - [02/Jan/2016:08:06:16 +0900] "POST / HTTP/1.1" 400 226 "-" "Googlebot/xx.143.192.194 - - [02/Jan/2016:08:06:15 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/5.0xx.143.192.194 - - [02/Jan/2016:08:06:13 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/4.0xx.143.192.194 - - [02/Jan/2016:08:06:12 +0900] "POST / HTTP/1.1" 400 226 "-" "Mozilla/4.0………….Static.aaa-bbb-180-41.clients.your-server.de - - [02/Jan/2016:08:07:00 +0900] "GET /~atomita/
時刻がずれるのはWebサーバ側の処理が遅れている攻撃は⼀⻫に来ている．
40
本学における被害• ⼤学トップページ
• 2016/10/29 - 約30分(正午あたり) • 2017/5/14 - 約6時間(⽇曜午前中)
• その他• 2017/6/1 - 本学蔵書検索サイト
41
攻撃側のアクション• チェックホスト(check-host.netなど)で確認• 攻撃開始
• レンタルサーバ，Proxy，Tor，Tunnelbearなどから• 攻撃中に再度チェックホストで確認• スクリーンショット• #OpKillingBayや#Tangodownで報告
• 何秒落としたのかなどは⾔わない
42
対応が⼤変なところ• 攻撃が⾒えにくい• フィルタを撃っても回避してくる
• レンタルサーバ・Proxy・Tunnelを代える• 正引きさせないトンネルサイトが増えている• CloudFlareなどはネットワークが巨⼤で分散
• Slowlorisは脆弱性ではあってもバグではない• アプリケーション側に対策がなかった• 意識的に対策しないと全て攻撃対象となる
43
基本対策1. Keepaliveをサーバ側から能動的に切る2. 1クライアントからの同時セッション数を絞る
• 切るまでの時間が問題• スクリーンショットを撮られると結局勝利報告• Keepaliveを利⽤不可にするとセッション激増
• 絞る数が問題• ⾃サイトのコンテンツを把握• 絞った数の中でDDoSされると回避できない
44
勝ち鬨をあげる
45
↑OPAC蔵書検索サイト＠和歌⼭⼤学↓#OpkillingBay での情報収集サイト
46
[yutaka@nm-dhcp27 #opac_log]$ cat ssl_access_log | grep 84.16.225.36 | headxx.16.225.36 - - [01/Jun/2017:07:22:46 +0900] "GET /opac/opac_search/?lang=1 HTTP/1.1”xx.16.225.36 - - [01/Jun/2017:07:22:47 +0900] "GET /media/css/opac_common_custom.cssxx.16.225.36 - - [01/Jun/2017:07:22:46 +0900] "GET /media/css/opac_common.css?20150302xx.16.225.36 - - [01/Jun/2017:07:22:47 +0900] "GET /media/css/jquery.ajaxSuggest.css?xx.16.225.36 - - [01/Jun/2017:07:22:47 +0900] "GET /media/css/jquery.ajaxSuggest_custom.css-xx.16.225.36 - - [01/Jun/2017:07:22:47 +0900] "GET /media/css/opac_search_custom.css? ‒xx.16.225.36 - - [01/Jun/2017:07:22:47 +0900] "GET /media/js/opac_common.js?20150302 xx.16.225.36 - - [01/Jun/2017:07:22:47 +0900] "GET /media/js/wordBreak.js?20150302
[yutaka@nm-dhcp27 #opac_log]$ cat ssl_access_log | grep 84.16.225.36 | tailxx.16.225.36 - - [01/Jun/2017:08:37:27 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200xx.16.225.36 - - [01/Jun/2017:08:28:02 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200xx.16.225.36 - - [01/Jun/2017:08:32:16 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200xx.16.225.36 - - [01/Jun/2017:08:40:49 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200xx.16.225.36 - - [01/Jun/2017:08:53:56 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200xx.16.225.36 - - [01/Jun/2017:08:37:49 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200xx.16.225.36 - - [01/Jun/2017:08:06:36 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200 xx.16.225.36 - - [01/Jun/2017:08:05:30 +0900] "GET /opac/opac_search/?lang= HTTP/1.1" 200
[yutaka@nm-dhcp27 #opac_log]$ cat ssl_access_log | grep xx.16.225.36 | wc -l13849
ドイツから来ている．アドレス割り当てはNLかも知れない． 47
本省「今後の対策を教えろ」• ソフトターゲット(テロ⽤語)にシフトしてきた
• 放っておくのも⼀つの⼿だけど…• ⼀応DDoS対策のACLリスト下に⼊れる
• 同時セッション数とセッション維持時間で制限• 海外からのアクセスを拒否する仕掛けも
order deny,allowdeny from all allow from .jpallow from .bbtec.net # Yahoo BBallow from .il24.net # Interlink
JP 1.0.16.0/255.255.240.0 JP 1.0.64.0/255.255.192.0 JP 1.1.64.0/255.255.192.0 JP 1.5.0.0/255.255.0.0 JP 1.21.0.0/255.255.0.0 JP 1.33.0.0/255.255.0.0 JP 1.66.0.0/255.254.0.0
.htaccess での書き⽅ APNICでのJP割り当てリスト(2724レコード) 48
苦悩• 「もし〜されたら」という恐怖
• アノニマスは横のつながりがない• おそらく複数犯によるDDoSの可能性は低い• 2016/10/29本学が受けたmobHammerV4は最⼤3カ所• 2017/5/14本学が受けた攻撃は最⼤30カ所から• 2017/6/1本学蔵書検索サイトは1カ所から
• どの具体的対策も留意点はある• サイトのコンテンツ量を知る外部専⾨家は居ない• ファイアウォールチューニングを⾃分でやる
49
情報危機管理コンテスト
50
51
コンテストのシナリオ例• P2Pファイル共有ソフトで⽩浜著作権協会を名乗る組織から著
作権違反の対応を迫られる• ショッピングサイトの顧客データがSQLインジェクションで流
出，掲⽰板に掲載され「祭り」が発⽣し対応を迫られる• 組織外へのトラフィックが異常に⾼くなり，同グラフを⾒た経
営陣から説明を求められる• アノニマスと同じ攻撃⼿法でWebサーバが接続不能になる
52
他に例がないコンテスト• CTF（Catch the Flag）とは違う• トラブルをスケールする
• 決まった規模で，確実にトラブルを発⽣させる• どのように復旧できるかを「ほのかに」誘導する• 担当スタッフの対応を均質化する
• めんどくさい（だから他に例がない）• ⾯倒なことをすればできるように⼯夫する
• ⼆⾯から⾒ることで引き出しを増やす• 復旧する側と復旧させる側からトラブルを⾒る• 指導する側の層を厚くする
53
最近注⽬されている？
54
コンテスト関連イベント• 5⽉ｰコンテスト
• 3⽉から仕込み• 8⽉ｰBasic SecCap(第2期enPiT)ｰ本学学部⽣(30名)• 9⽉ｰSecCap(第1期enPiT)ｰNAIST，SFCなど学外院⽣(30名)• 8-9⽉ｰ県警サイバー犯罪対策班研修受け⼊れ• 11-12⽉ｰProSec(第3期enPiT)ｰ社会⼈向け(本年12名)
• 12/8-9 - ⾼専機構向け演習(全国⾼専5校，30名)
55
ProSecのコンテンツ• コンテストのシナリオ
• Stage-1〜3に分けて10程度のシナリオを遠隔ハンズオン演習• 3⽇間の合同ハンズオン
• 偵察活動(ネットワーク構成を設計図なしでどこまで探れるか)• 暗号化無線通信の解読(共通鍵暗号の無意味さ)• 暗号化通信(https)の解読(RSA鍵交換⽅式のみ)• Cisco社製ファイアウォールの脆弱性を使った攻撃⽤ツール作成• これまでの経験に基づくシナリオ作り(コンテストおよび演習で採⽤)
http://www.seccap.pro/
コンテストにおける⼈材育成• 実は欲しがられるのは川橋研側
• トラブルが起こる(攻撃が成⽴する)仕組みを知る• どうすれば直る(戻る)が知っている• どこまでやるのが仕事かよくわかっている• ⼤抵のことにあまり驚かない
• コンテストに臨む各校の姿勢に変化が• ベストメンバーでチームを作らない
• 先輩と後輩が混じった編成になっている• 教える側の層が厚くなっている？• 教えることで知識とスキルに深みが出る• 流れを作り上げて維持するのが我々の仕事
57
これまで⾒てきたもの結論
58
お定まりの⽂句ですが…• 運⽤設計はかなり⼤事だ
• PDCAサイクルを守っている組織は少ない• 運⽤に過⼤な負担がかかっている上に⼈材不⾜
• 孫⼦の兵法• 「昔の善く戦う者は，先ず勝つべからざるをなして…」• まず⾃分の⾜下を固めて負けない体制を築く
• サイバーではよく「敵」が⾒えない• モチベーションの維持は困難• 運⽤の現場をよく⾒るべし・よく知るべし• 情を移しすぎない程度に
59
難しい教育・易しい教育• 学⽣に信頼される仕事
• 教育の現場におけるもっとも基本的な事項• 学⽣を信頼する仕事
• とても難しい・責任を伴う• 先輩から後輩への流れをつかむのに5年• 教えることよりも，⾒せる，盗ませる
• 「やってみせ ⾔って聞かせて させてみて ほめてやらねば ⼈は動かじ」• 浅はかなヒトからは「楽してる」と⾔われる
60