まっちゃ４４５に行ってきた．

勉強会

夏休みなのでログ書くのが遅くなりました(；・∀・)．

First impressions

いやー，雰囲気違うなぁ．と言うか，Rubyist がおとなしすぎるのか歳を食ってるのか．
Perl/PHP とかどうなんだろうね．あと Windows 率が高い．これは開発者とは人種が異なると言うことだろうかね．

  • 内容は原則公開禁止．内容が内容だけに仕方ないよね．
  • 内輪ネタが多かった．かなり．
  • 主催者＆スタッフの人が会場全体を廻って話しかけていたのは非常に良かった．あれないと取り残される感が生じるかもしれない．

当日の流れ

  • 説明
  • 自己紹介
  • セッション1
  • ディスカッション
  • セッション2
  • ディスカッション
  • 全体ディスカッション

VPN再考

専用線とVPN
  • ネットで仕事は？
    • 安全に，確実に，接続元がわかる，必要がある．
    • インターネット経由だと，誰が見てる変わらないところもある．
    • 専用を使う
      • でも使えない場合は？
  • 専用線って？
    • 特定の地点間を結ぶ通信回線のようなもの
  • 利点・欠点・特徴
    • 特徴
      • 専用なので占有可能
    • 利点
      • 経路が保証される
    • 欠点
      • 高い
        • 64kbps で 77000円/月 とか 28000円/月
  • VPNって？
    • Virtual = 〜みたいなもの
    • VPN = 専用線みたいなもの
    • 機密性・安全性・完全性を確保するもの
    • 暗号化・認証を用いて「正当な相手」に安全に送る技術
    • 形態や構成はいろいろ
  • 何をもって VPN というのか
  • VPN を使うシーン
    • 拠点間通信
    • インターネットを経由して安全な接続(トンネル)を張る．
    • 端末を安全に LAN に接続する
VPN プロトコルと VPN 接続
  • VPN の例
    • ある Layer の上に別の Layer を乗せて通信する．
    • 「LAN 間接続」と「端末への LAN 接続」
  • VPN 封に使えるものの例
    • SSH / Zebedee など
  • IPsec/ EtherIP の構成
    • VPN 装置の部分で IPsec や EtherIP をサポート
  • PPTP の場合
    • VPN 装置が端末を LAN 上に接続したかのように見せる
VPN の使い方
  • 無線LAN を安全に LAN に接続する
    • LAN のセキュリティを向上させるために
    • 無線LAN の通信路が暗号化される．多重に暗号化してるので，安全度向上．
    • Captive Portal
      • HotSpot の Web 認証みたいなあれ．
      • 無線LAN をお手軽に守るなら
  • OpenSSH + Socks + FreeCap でお手軽 VPN 接続可能．
    • FreeCpa はアプリケーションを Socks 対応化させる
    • OpenSSH で Socks サーバとして動作させる．
  • EtherIP を使うと異なるセグメントにある Xen VM 同じセグメントにあるかのように見せることも可能
むすび
  • VPN もいろいろある
  • LAN 内でも使える
  • VPN も使いどころを考えた方がいいかもしれない．
    • 無理に VPN じゃなくても代替方法はある．

なぜ，攻撃されるのか．そして守るためには？

  • 安全な Web?
    • Web の安全について知る
    • どうすれば守れるだろうか
    • 攻撃はどこの Web サイトにもある
      • サーバ自体とか
なぜ攻撃されるのか？
  • どういうサイトがねらわれる？
    • 官公庁，有名企業
  • 動機は？
    • 技術力の誇示，政治的なもの
  • 具体的な被害
    • 個人除法の流出
    • フィッシングの温床となる
      • 何が狙われるのか．
        • 情報ではなく，「サイトの信用力」が狙われている．
    • 踏み台にされる
      • スパム配信，DDoS の拠点
  • どうやって攻撃しているか
    • 昔はスーパーハカー
    • 今は自動攻撃ツール
  • 攻撃成功後の行動
    • 見つからないように潜伏して，こっそりサーバを利用・情報抽出する．
  • サーバは存在しているだけで狙われる．
  • 攻撃手法の変遷
    • ターゲットはサーバから Web アプリへ
      • サーバは厳しいセキュリティ要件とテストがある
    • Web アプリは低コストで・・・・
      • 2007年は Web アプリへの攻撃が急増
  • 脆弱性のほとんどはバグ
  • カカクコム事件
    • 不正アクセスによりメールアドレスが流出
    • SQL インジェクションによりトロイの木馬が
    • 被害は？
      • ユーザだけではなく，会社経営にも影響を与える
    • Web アプリをしっかり作ってれば・・・・
  • サウンドハウス事件
    • 2年前から SQL インジェクション攻撃されていた．
    • 9万人の個人情報が漏れた
    • Web アプリをしっかり作ってれば・・・・
守るために何をすべきか
  • 要件と設計
    • 早い段階の方がコストが少ない
  • 安全な Web サイト設計のために
    • コストがフェーズによる変わる
      • 設計 : 1
      • 自訴巣 : 6.5
      • テスト : 15
      • 運用 : 65
  • 安全でない Web サイトができる例
    • 要求仕様や設計だけが重要なわけではない
    • 開発工数が確保できていない
      • 設計 : 1/3
      • 実装 : 1/6
      • 機能テスト : 1/4
      • 統合テスト : 1/4
    • 機能実装を優先し，異常系・例外処理がおろそかに
    • 安全でないコードの再利用
    • プログラマのスキル不足
    • テストの不足
    • 環境・運用後の問題
  • 資産に応じて「どの程度，安全にすべきか」を知っておく必要がある
    • 守るべき資産とは
      • 利用者の情報
      • サービスレベル
      • 売り上げ
  • セキュリティはトレードオフ
    • コスト
      • 実際の費用・工数
      • 機会損失
    • 利便性
    • リスク
  • 何を調整するか
    • コスト
      • コスト増はあまり容認されない場合もある
    • 利便性
      • 利便性を犠牲にできるか？
    • リスク
      • リスクは調整できる
  • リスクの緩和を戦略として取り入れる
    • リスク前提で運用
      • 対応策を考えて運用
    • リスクを回避する
      • サービスを止めるとか
    • リスクの限定
      • 影響を一定レベルに抑制するとか
    • リスク計画
    • リスクの委譲
  • Web アプリへの攻撃
    • 割愛
  • 安全な Web アプリケーションのためにセキュリティ要件
    • 開発者まかせでは解決しない
    • 要件に「考慮すること」とか書いてもダメ
  • 参考資料
まとめ
  • なぜ攻撃されるのか
    • サイバー空き巣．自動ツールによる無差別攻撃
  • どうやって守るか
    • リスク管理．リスクを見極め，許容する・回避するなど．
    • 適切なセキュリティ要件

感想など

  • ディスカッション時間をしっかり取っているのはいい気がする．これはRails勉強会でもやるべきかもしれず．
  • セキュリティ要件やコストは可視化しづらいのはどこも一緒みたいですね．