ネットワーク運⽤とそのセキュリティ対策
和歌⼭⼤学
学術情報センター
川橋 裕

Special Thanks To…
• 本会場にお越しの皆さま• 経済産業省近畿経済産業局• ⼀般財団法⼈関⻄情報センター• ⽇頃トラブルシュートにつきあってる同僚• 研究室の学⽣たち• 家族2

Profile• 和歌⼭⼤学学術情報センター• 専任教官，講師• システム⼯学部・システム⼯学研究科兼務• 川橋研究室(学部・⼤学院の学⽣)• ⼤学全体のネットワーク・コンピュータを管理• 20年近く，レンタルシステムとネットワーク• 仕様書，調達に係る⼊札案件，技術審査など• 最近は情報危機管理コンテストなど• 経済産業省と⽂部科学省

3宣伝ですが…

「情報危機管理コンテスト」で検索
・経済産業⼤⾂賞と⽂部科学⼤⾂賞を団体に授与
・JPCERT/CC賞を個⼈に授与- インシデントレスポンス，顧客対応，広報，報告を織り交ぜた実践的で総合的な競技- 全国の⼤学・⼤学院・専⾨学校から毎年20チームほど4

もうひとつ宣伝ですが…

「enPiT-Pro」で検索
・(社会⼈のための)成⻑分野を⽀える情報技術⼈材の育成拠点の形成
・国内7⼤学IT(ICT)を再度学びたい社会⼈の⽅々に本学で考えている不埒なこと
・「教える」層を厚くする，「質の問題」より「量の問題」
・現場で仕事を「押しつけられている」⽅々に光を・前述のコンテストで学⽣たちをきりきり舞いさせる
・そこで学⽣との接点をもってリクルートにつなげる5

Agenda• ⼀般的な情報危機管理のお話• 最近の事例も踏まえて• Google検索結果に「クラックされた可能性」• コンテンツの分散管理とプログラムの把握• アノニマスによる攻撃および防御の紹介• 和歌⼭ですし…

• コンテストと⼈材育成6

情報セキュリティと情報危機管理
情報通信研究機構(NICT)「CYDER事前学習」より

7

語句の意味• 情報セキュリティ• 企業の情報システムを取り巻くさまざまな脅威から，情報資産を機密性・完全性・可⽤性（三⼤要件）の確保を⾏いつつ，正常に維持すること． 情報資産を正当な権利を持った⼈だけが使⽤できる状態にしておくこと．
• JNSA：NPO⽇本ネットワークシステム協会• 情報危機管理• 情報資産を危機(脅威)から護りつつ事業を継続していくこと．細かい定義はない．

8

情報資産とは• 情報と情報システムおよびそれらを維持および保護するために必要なもの• ⽂書(紙)，電⼦⽂書，情報システム内のデータ，• OS，アプリケーションソフトなど• コンピュータ，ネットワーク機器，記録媒体• 建物，空調，電源など

9

脅威とは
• 標的型攻撃(特定組織の情報を狙うサイバー攻撃)• Webサイトの改ざん，マルウェア(※)感染• 不正アクセス，内部犯⾏• ※不正または有害な動作をおこなう意図で作成された悪意あるソフトウェアや悪質なコードの総称• ⾮標的型攻撃と故障・ヒューマンエラー• 愉快犯などによる不特定多数への攻撃など• 前項との切り分けが重要• 攻撃でないことの証明が⼤変⾯倒，横のつながり• ⾃然災害，盗難などの犯罪
10

脆弱性(ついでに)• 脅威を引き起こす・拡⼤させる要因となるもの• OSやアプリケーションのバグ(不良な部分)• パラメータ設定の不備など• 不⼗分なセキュリティ教育，技術対策，組織体制• 「脅威」＋「脆弱性」＝被害発⽣• 「脅威」はなくならない• 「脆弱性」をなくす(努⼒をする)• 「脅威」と「脆弱性」の間に障壁を⼊れる• 障壁＝ハード，ソフト，⼈材，⾯倒な⼿続き11

セキュリティ「CIA」• 機密性(Confidential)• 許可されたものだけが情報にアクセスできる• 許可が無いと読めない，など• 完全性(Integrity)• 情報や情報の処理⽅法が正確で完全であること• 許可が無いと編集できない，など• 可⽤性(Availability)• 許可されたユーザが必要な時に情報および関連する情報資産にアクセスできること• サーバ壊れちゃ仕事にならん，許可が無いと使えない，など
12UNIXに⾒る「CIA」
yutaka@triglav[~] % ls -ltotal 12drwx------ 2 yutaka wheel 512 Apr 30 2011 Arch/drwx------ 5 yutaka wheel 512 Apr 30 2011 Maildir/-rw-r--r-- 1 yutaka wheel 2366 Jan 25 2018 cron.0.bz2-rw-r--r-- 1 yutaka wheel 0 Jan 6 2020 result.log
drwxr-xr-x 3 yutaka wheel 512 Mar 17 2014 src/
drwxr-xr-x 7 yutaka wheel 512 Nov 12 2019 work/

パーミッション：誰にどのような権限が与えられてるかr : 読む権限
w : 書く（編集・消す）権限
x : 実⾏する権限

drwxrwxrwx <dirs> <owner> <group> <size> <time> <name>
UNIXを使う⼈はすでにCIAを理解している

振り返ってみましょう• これまで⾝近なところでセキュリティ事件や事故の事例を⾒聞きしたことはありませんか？
• セキュリティ事件や事故を未然に防ぎ，また万⼀の時に被害を最⼩限にとどめるためには，⽇ごろからどんな対策・対応が必要でしょうか？
• もし今，職場で事件や事故が発現したら，あなたはどのように対応し，周りの同僚にはどのようにアドバイスしますか？
• 対応ルールや⼿順は策定されていますか？またその対応は全員に周知徹底されているでしょうか？
14

運⽤の落とし⽳15

ITセキュリティを維持するには• システム設計と運⽤設計• 前者は「〜させる」「〜させない」設計• 後者は「〜したか」「〜しなかったか」設計• ⼈の⾏動の全てを型にはめることはできない• 「守りの堅い城ほど〜」• 過度なシステム設計は業務をできなくする• 例：県教育委員会の教育ネット• 「働き⽅改⾰」• PDCAサイクルのPlanのみがシステム設計

16出典：IPA(情報処理推進機構)「情報セキュリティマネジメントとPDCAサイクル

17

運⽤って何？
• 偉い⼈はシステムを⼊れたことだけ知ってる• 偉い⼈はそれがどんなトラブルを⽣むのか興味が無い• 「買ったんだからサービスしてくれる」• すでにサービスに⾦がかかる時代• ⾃分で抱えるか，⾃分で持たないか• 前者は運⽤そのものを⽀えるスタッフが必要• 運⽤や再設計に融通が利く，リスクを取る• 後者は運⽤そのものも投げてスタッフを持たない• 業務スタイルをシステム&運⽤に合わせて⼤幅変更• 上記リスクは減るが新たなリスクが…

• ファイアウォールのルールが棚卸しされずに増え続けるなど
18すべてはバランス• リスクを取るか，軽減するか，移転するか• 最後は保険や委託など• 通信教育事業者は200億円を拠出• カネをかけるか，⼿間をかけるか• セキュリティとは「⾯倒なもの」• リスクヘッジ以上のとらえ⽅を模索する必要性• 運⽤に光を！
• 導⼊は実績，運⽤は現場で，は良くある19

⾃分とこの検索結果なんて⾒ない
⾝近な事例-120

ある⽇突然外部から• 「おたくクラックされてるって」• 外部に異動した教官から連絡• Google「このサイトは第三者によってハッキングされている可能性が」• メッセージの理由は「スパム広告の存在」• リンク先にはどこも変化がない• クリック⼩僧では⾒つけられない• サイトの信頼を無くすための攻撃オプション• 「修学旅⾏」「アップローダ」というオチ• 有名なアップローダだが4桁のパスコードをブレイクするツールあり

21

ファイル構成
DocumentRoot
リンクあり

リンクなし

⼤学コンテン
ツ

スパム広告
リンクあり

ユーザコンテンツpublic_html

ファイル
アップローダ・付属学校教員がおいたアップローダに脆弱性
・www権限が取られてトップドメインに⾮リンクでスパム置かれる
・Googleにごっそりキャッシュされる
22

対応(インシデント・レスポンス)• 膨⼤なログの解析• アップローダと同不正利⽤の発⾒• スパムの設置• スパム広告を保全• プログラム設置のガイドライン• ⼀⾔⾔いなさいよ• トップドメインと差別化• 広報委員会と運⽤の壁• 意図しない内部犯⾏(当⽅に処分権限無し)
23

標的型メールを実際に受信する
⾝近な事例-2

24

標的型メールの恐ろしいところ• 「⾃分は⼤丈夫」と思い込むこと• 私でもヒヤヒヤ• 添付は知ってる⼈からのみ開く• 知ってる⼈からなのかメールのヘッダで調べる• Webリンクは開いて良いのどうか調べる• マルウェアは仕込まれていないはチェック• 代理アクセスして画⾯をチェック• ようやくリンクを開く• 「開いた⼈がどれだけ居るか調べろ」という声• インターネットは送信記録がないという本質
25

前提環境
メール

⼤学のメールサーバ(メールをやりとりする)⼤学のWebメールサービス(⼤学ユーザが学内外で利⽤)
Active!Mailというオンプレミス(⾃前で持ってるサービス)

学内ユーザ(学内外で利⽤)※⾃前のオンプレミスなので外部から⽂句⾔われることは無い

26

標的型メール(スパム)受信

件名: Upgrade Required
送信者: "Active Mail" <ehec2017@m.kufm.kagoshima-u.ac.jp>
送信⽇時: 2017年06⽉30⽇(⾦) 09:28:28
宛先: "Active Mail" <ehec2017@m.kufm.kagoshima-u.ac.jp>！Active Mail Upgrade Required！ メールボックスクォータがいっぱいです
これにより、メールボックスに障害が発⽣する可能性があります。または、メールを受信できなくなる可能性があります。
メールボックスを引き続き使⽤するには、すぐにメールボックスのクォータをアップグレードする必要があります。 このサービスは無料です。
今すぐアップグレード<http://seo-force.com/wp-admin/user/activemailUpgradeNow/>
アップグレードが完了すると、メールボックスは効果的に機能します。
ご協⼒ありがとうございます！
アクティブメールサーバー
著作権2017-アクティブゲートウェイ

27

28

29

何が問題？
• 本学のユーザアカウントを奪う気満々• ⼤学のロゴマークまで使ってつり上げる• 奪って何をする気なのか？
• 本学ユーザになりすまして全世界にスパム配信• 当該ユーザの情報を抜き取る• 当該ユーザの権限でbotを仕込み攻撃• …などなどが可能

30

対策• アカウントを盗られるとどうしようもない• 「⼤したデータは⼊ってない」は通⽤しない• 学外からアクセスさせる以上，制限できない• メール内のリンクを調査するシステムがない• 管理者が代わりに踏むか⾃前で警戒するか• 誰がそのリンクを踏んだが追跡する仕掛け• パフォーマンスとの兼ね合い• よくプライバシー問題と並べられる• 電話の通話記録を同じだと突っぱねている

32パスワードクラックの仕組み
ドコモ⼝座？

パスワードを破るとはどういうことか？
（パスワード）yutaka1 →ハッシュ⽣成は⼀⽅向性関数（逆変換は無理）（ハッシュ）
ハッシュ形式で保存される
5f4dcc3b5aa765d61… （管理者もパスワードは不明）
⼀⽅向性関数はほぼ既知（SALTなど変数で変化をつける）

yutaka → 5f2efcb3c…
yutaka → kawahashi → 5f3dca4b…
yutaka1 → 5f4dcc3b…

固定したID
適当なパスワード
ハッシュを⽐較
⼀致すれば「破れた」
ハッシュ⼊⼿が必須

ログに⾒る「パスワード破り」の試⾏
Dec 6 18:45:41 triglav sshd[587]: Failed password for root from a.b.c.d port 22754 ssh2
Dec 6 18:45:41 triglav sshd[588]: Failed password for root from a.b.c.d port 22755 ssh2
Dec 6 18:45:42 triglav sshd[589]: Failed password for root from a.b.c.d port 22756 ssh2
最近はハッシュの⼊⼿を⾶ばして直接ログインを試みる→辞書攻撃，Brute force攻撃同⼀IDに対してパスワードを変えて試みる→ 連続して失敗するとログインできなくなるなどの対抗措置→ わざとロックさせるなどの迷惑⾏為も存在するが…

運⽤の落とし⽳
yutaka0
kawahashi → yutaka1

パスワードを固定してIDを変える
パスワードを知らない管理者の落とし⽳→同⼀⼈物の試⾏と思わない→試⾏されていることに気づきにくい

yutakaDec 6 18:45:41 triglav sshd[587]: Failed password for yutaka0 from a.b.c.d port 22754 ssh2
Dec 6 18:45:41 triglav sshd[588]: Failed password for kawahashi a.b.c.d port 22755 ssh2
Dec 6 18:45:42 triglav sshd[589]: Failed password for izumi from a.b.c.d port 22756 ssh2

やたらログイン失敗する⼈多いなあ…
（そもそもそんなにログを⾒ていない）（システム上おかしいと定義づけしづらい）対策• パラメータを増やす（時刻や場所など）• 監視・モニタリングの精度を上げる• もっとも有効だがもっとも難しい（価格的・システム的に）• 今回はSMS認証を突破しているフシもある• ⾃分の銀⾏⼝座の通帳記帳・出⼊りをこまめに⾒る• カネをかけるか，⼿間をかけるかアノニマスによるSLOW HTTP 攻撃

40

Slowlorisとは• 遅延攻撃• 便宜上，まとめてSlowlorisと呼ぶ(かわいい)• 1バイトずつ送って通信を⻑時間維持する• POSTによるapacheの圧迫がもっとも強烈で多い• HTTP内のKeepaliveを⻑くしてセッション維持• ファーストフードのカウンター• 実はサーバは窓⼝が256個しかない• 256のリクエストなら⼀⼈からでもできちゃう• ⼀般的なDoS攻撃は1秒間に100万アクセスなど

41

攻撃を受けると何か起こるか• Webページが閲覧できない• 全ツリー全滅• CMSなど転送先は直接指定で⾒える• 攻撃を受けてる最中はログに何も出ない• Timeoutしてからログに出⼒される• 時刻情報がずれて記録される• UserAgentがバラバラ（POST）

42

攻撃側のアクション• チェックホスト(check-host.netなど)で確認• 攻撃開始• レンタルサーバ，Proxy，Tor，Tunnelbearなどから• 攻撃中に再度チェックホストで確認• スクリーンショット• #OpKillingBayや#Tangodownで報告• 何秒落としたのかなどは⾔わない

45

対応が⼤変なところ• 攻撃が⾒えにくい• フィルタを撃っても回避してくる• レンタルサーバ・Proxy・Tunnelを代える• 正引きさせないトンネルサイトが増えている• CloudFlareなどはネットワークが巨⼤で分散• Slowlorisは脆弱性ではあってもバグではない• アプリケーション側に対策がなかった• 意識的に対策しないと全て攻撃対象となる

46

基本対策
1. Keepaliveをサーバ側から能動的に切る
2. 1クライアントからの同時セッション数を絞る• 切るまでの時間が問題• スクリーンショットを撮られると結局勝利報告• Keepaliveを利⽤不可にするとセッション激増• 絞る数が問題• ⾃サイトのコンテンツを把握• 絞った数の中でDDoSされると回避できない47

勝ち鬨をあげる48

情報危機管理コンテスト

50

51

コンテストのシナリオ例• P2Pファイル共有ソフトで⽩浜著作権協会を名乗る組織から著作権違反の対応を迫られる• ショッピングサイトの顧客データがSQLインジェクションで流出，掲⽰板に掲載され「祭り」が発⽣し対応を迫られる• 組織外へのトラフィックが異常に⾼くなり，同グラフを⾒た経営陣から説明を求められる• アノニマスと同じ攻撃⼿法でWebサーバが接続不能になる

52

他に例がないコンテスト• CTF（Catch the Flag）とは違う• トラブルをスケールする• 決まった規模で，確実にトラブルを発⽣させる• どのように復旧できるかを「ほのかに」誘導する• 担当スタッフの対応を均質化する• めんどくさい（だから他に例がない）• ⾯倒なことをすればできるように⼯夫する• ⼆⾯から⾒ることで引き出しを増やす• 復旧する側と復旧させる側からトラブルを⾒る• 指導する側の層を厚くする53

レイヤモデルと向き合う(enPiT和⼤)• 問題がどこで発⽣しているのか切り分ける必然性• 幅広い知識と切り分けるスキル• そのスキルをどこでどのように使うのか？
• 逆転の教育⽅法• 無法地帯の現場を構築し提供，フィードバックしながら学ぶ

知識技術現場同じ症状，違う原因(enPiT和⼤)• ホームページが⾒えない• ホームページが改ざんされた• Slow HTTP DoS攻撃• BF攻撃によるアカウント奪取(個⼈ページ)• SYN Flood攻撃• htaccessにフォワード設定• 外部コンテンツスタック(Apache• index.htmlにフォワード設定Struts2)• Javascriptにフォワード設定• リフレクション(増幅攻撃)• パーミッション全解放によるいたずら(個⼈)• ntp• httpd.confのオーナーwwwにともなう権限奪• memcached
取(トップページ)• ホームページが重い• WordPress脆弱性(restAPI，トップ)• File system is full
• 偽DHCPおよび偽DNSによる⼀部クライアン• 異様な個⼈acl
トのphish(トップ)• ウィルス・ワーム系• JavaWebStartにともなうクライアント内• Excelマクロhosts改ざん(トップ)• バックドア，仮想通貨マイニング

違う原因によって何が⾒えるか？
• 技術(ツール)の使い⽅・結果の⾒⽅が増える• その基底にある共通した知識がわかる• 障害の仕組みがわかる• 知識と技術をどんなときにどう使うのかわかる
学ぶ側がモチベーションを維持しやすい反⾯，準備が超しんどいコンテスト関連イベント• 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名)
60

ProSecのコンテンツ• コンテストのシナリオ• Stage-1〜3に分けて10程度のシナリオを遠隔ハンズオン演習• 3⽇間の合同ハンズオン• 偵察活動(ネットワーク構成を設計図なしでどこまで探れるか)• 暗号化無線通信の解読(共通鍵暗号の無意味さ)• 暗号化通信(https)の解読(RSA鍵交換⽅式のみ)• Cisco社製ファイアウォールの脆弱性を使った攻撃⽤ツール作成• これまでの経験に基づくシナリオ作り(コンテストおよび演習で採⽤)

http://www.seccap.pro/

enPiTとコンテストにおける⼈材育成• 実は欲しがられるのは川橋研側• トラブルが起こる(攻撃が成⽴する)仕組みを知る• どうすれば直る(戻る)が知っている• どこまでやるのが仕事かよくわかっている• ⼤抵のことにあまり驚かない• 教える側の層を厚くする• enPiTでは川橋研究室の学⽣• コンテストでは各チームの先輩による指導体制• ベストメンバーでチームを作らない

62

これまで⾒てきたもの
結論63お定まりの⽂句ですが…
• 運⽤設計はかなり⼤事だ• PDCAサイクルを守っている組織は少ない• 運⽤に過⼤な負担がかかっている上に⼈材不⾜• 孫⼦の兵法• 「昔の善く戦う者は，先ず勝つべからざるをなして…」• まず⾃分の⾜下を固めて負けない体制を築く• サイバーではよく「敵」が⾒えない• モチベーションの維持は困難• 運⽤の現場をよく⾒るべし・よく知るべし• 情を移しすぎない程度に64

難しい教育・易しい教育• 学⽣に信頼される仕事• 教育の現場におけるもっとも基本的な事項• 学⽣を信頼する仕事• とても難しい・責任を伴う• 先輩から後輩への流れをつかむのに5年• 教えることよりも，⾒せる，盗ませる• 「やってみせ ⾔って聞かせて させてみて ほめてやらねば ⼈は動かじ」• 浅はかなヒトからは「楽してる」と⾔われる

65