SlideShare a Scribd company logo
1 of 160
Copyright 2004,2007 © Kensuke Nezu, All rights Reserved. 1
文部科学省文部科学省
中央大学研究開発機構中央大学研究開発機構
UNIXセキュリティ実践講UNIXセキュリティ実践講
座座
~Secure Serve~Secure Serve
r Day~r Day~
Microsoft MVP – Windows SecurityMicrosoft MVP – Windows Security
NPONPO 日本ネットワークセキュリティ協日本ネットワークセキュリティ協
会会
NTTデータ先端技術株式会社NTTデータ先端技術株式会社
根津 研介根津 研介
Copyright 2004,2007 © Kensuke Nezu, All2
本資料の取扱について本資料の取扱について
 本資料は、文部科学省科学技術振興調整費 中央大学研究開発機構
「情報セキュリ ティ・情報保証 人材育成拠点」人材養成計画に基づ
き、中央大学 研究開発機構  「情報セキュリティ教育システムの
開発」ユニットが実施する「 Unix セキュリティ実践講座」の教材
として使用するために提供するものです。
 本資料を上記「本資料を上記「 UnixUnix セキュリティ実践講座」の使用目的以外に利用セキュリティ実践講座」の使用目的以外に利用
(転載、転用、商業活動への使用など)することを禁止します。ただ(転載、転用、商業活動への使用など)することを禁止します。ただ
し、例外として、学校内、サークル内、企業内などでサーバ導入の際し、例外として、学校内、サークル内、企業内などでサーバ導入の際
の参考資料として内部的に複写したり、活用することは許可します。の参考資料として内部的に複写したり、活用することは許可します。
この場合でも、教育そのものを事業目的とする場合は例外条件としてこの場合でも、教育そのものを事業目的とする場合は例外条件として
認められないので注意してください。認められないので注意してください。
 本資料の扱いに関して不明点等ある場合には、 中央大学 研究開発本資料の扱いに関して不明点等ある場合には、 中央大学 研究開発
機構 「情報セキュリティ教育システムの開発」ユニットまでお問い機構 「情報セキュリティ教育システムの開発」ユニットまでお問い
合わせください。合わせください。
Copyright 2004,2007 © Kensuke Nezu, All3
セキュリティ概論セキュリティ概論
Copyright 2004,2007 © Kensuke Nezu, All4
セキュリティの必要性セキュリティの必要性
 インターネットの長所インターネットの長所
 世界中から自由にアクセスできる世界中から自由にアクセスできる
 世界中に自由に公開できる世界中に自由に公開できる
 手軽な値段で誰でも利用できる手軽な値段で誰でも利用できる
 インターネットの短所インターネットの短所
 法的な保護が及びにくい法的な保護が及びにくい
  ~自分の身は自分で守るという姿勢が必要~  ~自分の身は自分で守るという姿勢が必要~
 全体を制御する「しくみ」とか「規制」がない全体を制御する「しくみ」とか「規制」がない
 他者への犯罪の幇助をしてしまうことも!他者への犯罪の幇助をしてしまうことも!SPAM メールの送信元になっ
たり、攻撃元を詐称するため
の踏み台にされたり・・・
SPAM メールの送信元になっ
たり、攻撃元を詐称するため
の踏み台にされたり・・・
Copyright 2004,2007 © Kensuke Nezu, All5
セキュリティ=国家の安全保障にもセキュリティ=国家の安全保障にも
気を配らなければなりません気を配らなければなりません
Copyright 2004,2007 © Kensuke Nezu, All6
サーバを法律が守ってくれる?サーバを法律が守ってくれる?
 場合によっては、守ってくれる程度場合によっては、守ってくれる程度
 日本と捜査協力や犯人引渡協定のない国、日本と捜査協力や犯人引渡協定のない国、国交の無い国国交の無い国
では日本国の法律は無力です。では日本国の法律は無力です。
-- 不正アクセスを国交の無い国から受けたので捜査して欲しい不正アクセスを国交の無い国から受けたので捜査して欲しい etc..etc..
 行為者が国内にいる日本人であれば、他の国のサーバをい行為者が国内にいる日本人であれば、他の国のサーバをい
くつ経由しても日本の法律で裁くことができます。くつ経由しても日本の法律で裁くことができます。
 刑法第一条~第五条参照(刑法第一条~第五条参照(
http://www.ron.gr.jp/law/law/keihou.htmhttp://www.ron.gr.jp/law/law/keihou.htm ))
 刑事でなければなりません。民事の損害賠償などは刑事でなければなりません。民事の損害賠償などは
、まず、成り立ちません。(損害額の算定が微少な、まず、成り立ちません。(損害額の算定が微少な
ため)ため)
 国際私法国際私法 (( ベルヌ条約、サイバー犯罪防止条約等)ベルヌ条約、サイバー犯罪防止条約等)
と各国に於ける法整備、法解釈の違いも問題になりと各国に於ける法整備、法解釈の違いも問題になり
Copyright 2004,2007 © Kensuke Nezu, All7
TPOTPO に合わせたセキュリティに合わせたセキュリティ
コンビニのセキュリティ
1. 店舗スペースは「公開」で不特定多
数のアクセスを許す
2. 店舗内トイレは「店員に一声かけ
て」利用する
3. レジ裏の事務所は非公開
4. 事務所にはビデオ録画システムを設
置し,防犯の目的や犯罪発生時の保
全措置に利用
公開サーバの最低限のセキュリテ
ィ
1. 公開する範囲を正しく判断し正しく
公開する
2. 公開する範囲を「正しい相手」に公
開する
3. 公開すべきでない(するつもりがな
い)部分を公開しない / させない
4. 必要な部分では「監視するしくみ」
を作りこむ
セキュリティ構築の5セキュリティ構築の5 W1HW1H をを
はっきりさせよう!はっきりさせよう!
Copyright 2004,2007 © Kensuke Nezu, All8
セキュアサーバ構築のコストセキュアサーバ構築のコスト (1)(1)
自分だけで構築・運用可能か判断す自分だけで構築・運用可能か判断す
るる
 「10:90の法則」が基準:「10:90の法則」が基準: 10%10% の工数での工数で
90%90% の効果の効果
 UNIXUNIX 開発の設計思想~もっともバランスがよい~開発の設計思想~もっともバランスがよい~
 セキュリティにセキュリティに 100%100% はない~どこかで見切りが必はない~どこかで見切りが必
要~要~
→→ 90% 91%→90% 91%→ にするにはにするには 20%20% の労力が必要の労力が必要
→→ 98% 99%→98% 99%→ にはには 100%100% の労力が必要の労力が必要
 サーバーやサービス毎に必要な効果を考えよう!サーバーやサービス毎に必要な効果を考えよう!
→ 90% までなら技術さえあれば自分で構築可能
Copyright 2004,2007 © Kensuke Nezu, All9
セキュアサーバ構築のコストセキュアサーバ構築のコスト (2)(2)
サーバーの価値を計算するサーバーの価値を計算する
 不正利用者の立場からみたサーバー不正利用者の立場からみたサーバー
の価値の価値
 システムに含まれるデータの価値システムに含まれるデータの価値
 機密情報があるか?など     機密情報があるか?など     
      → 転売の価値や改竄      → 転売の価値や改竄
、脅迫等、脅迫等
 踏み台にするサーバーとしての価踏み台にするサーバーとしての価
値値
 上位プロバイダとの回線速度など上位プロバイダとの回線速度など
 その他の価値その他の価値
 怨恨、意趣晴らし、愉快犯など怨恨、意趣晴らし、愉快犯など
機密情報機密情報 なしなし
顧客のデータ顧客のデータ なしなし
回線速度回線速度 <1Mbit<1Mbit 程度?程度?
怨恨関係怨恨関係 ???(???( 多分なし多分なし ))
総合総合 1515 点程度?点程度?
計算例
これらを総合的に判断して、
必要となるセキュリティレベ
ルを考える
Copyright 2004,2007 © Kensuke Nezu, All10
0
20
40
60
80
100
構築 セ キ ュリティ対策 日常監視
金銭的費用
工数
緊急性
サーバのライフサイクルと「コサーバのライフサイクルと「コ
スト」スト」
構築のコスト(金銭的コ
スト)だけに注意が向い
て、運用のコストが考え
られていないことが多い
構築のコスト(金銭的コ
スト)だけに注意が向い
て、運用のコストが考え
られていないことが多い
運用に必要な「目
に見えないコス
ト」の方が実はト
ータルすると重要
!
運用に必要な「目
に見えないコス
ト」の方が実はト
ータルすると重要
!
緊急性の高い作業は
、夜中や休日に集中
緊急性の高い作業は
、夜中や休日に集中
いかにいかに管理の手間管理の手間を下げるかがカギ!を下げるかがカギ!
Copyright 2004,2007 © Kensuke Nezu, All11
サーバー=サービスを提供するシサーバー=サービスを提供するシ
ステムステム
サービスの品質をはかる基準サービスの品質をはかる基準
 RAS(RAS( 大型コンピュータ大型コンピュータ // エンタープライズサーエンタープライズサー
バの世界の用語バの世界の用語 ))
 ReliabilityReliability :信頼性 - 「いつで:信頼性 - 「いつで
も安定したサービス」も安定したサービス」
 AvailabilityAvailability :可用性 - 「24時間、:可用性 - 「24時間、 365365 日稼日稼
働」働」
 ServiceService abilityability :保守性 -「誰でもどこ:保守性 -「誰でもどこ
でも簡単に」でも簡単に」
 MTBFMTBF とと MTTRMTTR
 MTBF:できるだけサービスを落とさないMTBF:できるだけサービスを落とさない
Copyright 2004,2007 © Kensuke Nezu, All12
サーバー=サービスを提供するシサーバー=サービスを提供するシ
ステムステム
セキュリティの品質をはかる基準セキュリティの品質をはかる基準
 国際規格国際規格 ISO/IEC17799ISO/IEC17799 による定義(による定義( CIA)CIA) を購入前のを購入前の
マヨネーズで例えると・・・マヨネーズで例えると・・・
 ConfidencialityConfidenciality :機密性 -チューブに穴は空いていませ:機密性 -チューブに穴は空いていませ
んか?んか?
 IntegrityIntegrity :完全性 -口のシールが貼り直されてい:完全性 -口のシールが貼り直されてい
ませんか?ませんか?
 AvailabilityAvailability :可用性 -売り切れていませんか?:可用性 -売り切れていませんか?
Copyright 2004,2007 © Kensuke Nezu, All13
サーバという「サービスの品サーバという「サービスの品
質」質」
サーバが目標とする品質とセキュリサーバが目標とする品質とセキュリ
ティティ
品質の目標品質の目標
1. いつでも安定していて、
2. いつでも利用することができて、
3. 「正しい中身」が「正しい人」に
伝わり、
4. 保守作業が簡単なシステム。
セキュリティはこの目標を達成し、セキュリティはこの目標を達成し、
維持し続けるための手段の1つにすぎない維持し続けるための手段の1つにすぎない
Copyright 2004,2007 © Kensuke Nezu, All14
サーバという「サービスの品サーバという「サービスの品
質」質」
サービスの維持管理とセキュリティサービスの維持管理とセキュリティ
「セキュリティ」の意味「セキュリティ」の意味
1. 安全、安全保障、安全確保、保障
。
2. 戸締まり、防衛手段、警備、防護
、保全、保安。
3. 無事、治安、安心。
日常の保守作業はすべて「セキュリティ」日常の保守作業はすべて「セキュリティ」
という大きなフレームワークの一部!という大きなフレームワークの一部!
保障:生命、財産、権
利などを保護して守る
こと
保障:生命、財産、権
利などを保護して守る
こと
Copyright 2004,2007 © Kensuke Nezu, All15
サーバという「サービスの品サーバという「サービスの品
質」質」
メインテナンスも立派なセキュリテメインテナンスも立派なセキュリテ
ィィ
•システムの定期的なバックアップ
•システムログのチェック
•不正利用、サービス不能、サービス停止の
防止
•システム侵入の防止、検出
•セキュリティインベントリ(ソフトウェア
のセキュリティホール発覚など)の監視
•速やかなサービス不能状態の検出、回復
•自動監視、自動警報発報、自動アップデー
ト
RAS の向上 MTBF をより
長く
MTTR を最小
に
Copyright 2004,2007 © Kensuke Nezu, All16
通常監視と情報収集通常監視と情報収集
通常監視
1. サービス可否のチェック
2. マシンのチェック
3. ネットワーク品質のチェック
4. システム負荷のチェック
5. 利用状況のチェック
6. 異常状態の検出
7. システム統計情報の監視
情報収集
1. (Push 型 )CERT/CC, JPCERT/CC, 各
種メールニュースなどの利用
2. (Push 型 ) セキュリティ関連メーリ
ングリストによる情報収集
3. (Pull 型 ) セキュリティ関連ホームペ
ージの利用
4. (Push 型 ) 利用ディストリビューシ
ョンのユーザメーリングリストの利
用
自動化に向いている自動化に向いている 自動化に向いていない自動化に向いていない
Copyright 2004,2007 © Kensuke Nezu, All17
予防保守と緊急対応予防保守と緊急対応
緊急対応
1. 緊急事態の発生時の対応体制、対応
マニュアル/メモの作成と実行
2. 異常状態検出時の対応体制、対応マ
ニュアル/メモの作成と実行
3. 問いあわせ発生時( Web サイト脆
弱性、 SPAM メール送信、踏み台に
よる第三者への攻撃元などの通告)
の対応体制、対応マニュアル/メモ
の作成と実行(捜査機関などの協力
要請への対応も別途、要検討)
4. 記録保全体制、手順書の作成
5. サービス/システム一時停止の判断
基準の作成
インシデントレスインシデントレス
ポンスポンス
予防保守
1. ハードウェアの二重化 (RAID 、フェ
イルオーバー、スタンバイシステム
など )
2. データの多重化(バックアップも含
む)
3. システムログの監視(通常状態の把
握と異常状態の検知)
4. パフォーマンス統計の監視(通常状
態の把握と異常状態の検知)
5. ソフトウェアのバージョンアップ
6. 異常状態の自動検出システムの作り
こみ(システム停止、サービス停止
を含む)
自動化に向いている自動化に向いている
Copyright 2004,2007 © Kensuke Nezu, All18
情報収集のコツ情報収集のコツ (1)(1)
プッシュ型コンテンツを有効にプッシュ型コンテンツを有効に
利用利用
 JPCERT/CCJPCERT/CC メーリングリストメーリングリスト ((http://www.jpcert.or.jp/announce.htmlhttp://www.jpcert.or.jp/announce.html))
 US CERTUS CERT メーリングリストメーリングリスト ((http://www.us-cert.gov/cas/index.htmlhttp://www.us-cert.gov/cas/index.html))
 スラッシュドットジャパンスラッシュドットジャパン [[ 毎日のヘッドライン毎日のヘッドライン ] (] (http://http://slashdot.jpslashdot.jp//))
 CNET Japan : NewsLetter(CNET Japan : NewsLetter( http://japan.cnet.com/news/sec/http://japan.cnet.com/news/sec/ ))
 MicrosoftMicrosoft プロダクトセキュリティ警告サービス日本語版プロダクトセキュリティ警告サービス日本語版 ((
http://www.microsoft.com/japan/technet/security/bulletin/notify.asphttp://www.microsoft.com/japan/technet/security/bulletin/notify.asp)) 無作為攻撃では Windows
をターゲットにしたものも
・・・
無作為攻撃では Windows
をターゲットにしたものも
・・・
Copyright 2004,2007 © Kensuke Nezu, All19
情報収集のコツ情報収集のコツ (2)(2)
   メーリングリストの活   メーリングリストの活
用用
 セキュリティホールセキュリティホール memo ML(memo ML(http://memo.st.ryukoku.ac.jp/http://memo.st.ryukoku.ac.jp/))
 2424 時間常時接続時間常時接続 ML (ML (http://cn24h.hawkeye.ac/connect24h.htmlhttp://cn24h.hawkeye.ac/connect24h.html))
 Intrusions List ML (Intrusions List ML (http://http://www.dshield.org/mailman/listinfo/intrusionswww.dshield.org/mailman/listinfo/intrusions))
 各種各種 OSOS のユーザーのユーザー MLML
 LinuxLinux ディストリビューションのユーザディストリビューションのユーザ MLML  など などパッチを当てるタイミン
グ、 update の安定動作
の確認
パッチを当てるタイミン
グ、 update の安定動作
の確認
メーリングリストの主旨
は、あくまでも「情報交
換」。
「収集」のみではなく、
「提供」できるようにす
る努力も工数のうちです
。
メーリングリストの主旨
は、あくまでも「情報交
換」。
「収集」のみではなく、
「提供」できるようにす
る努力も工数のうちです
。
Copyright 2004,2007 © Kensuke Nezu, All20
情報収集のコツ情報収集のコツ (3)(3)
ホームページの活用ホームページの活用
 前2ページで紹介したところにはそれぞれに大抵前2ページで紹介したところにはそれぞれに大抵
ホームページがありますホームページがあります
 WWWCWWWC 等のホームページ更新チェッカで自動化等のホームページ更新チェッカで自動化
 記事のリンク先のホームページ情報も確認しまし記事のリンク先のホームページ情報も確認しまし
ょうょう
  
プル型コンテンツなのでプッシュ型と比較するとプル型コンテンツなのでプッシュ型と比較すると
ひと手間多くかかりますひと手間多くかかります注意!
Copyright 2004,2007 © Kensuke Nezu, All21
セキュリティポリシーの必要性セキュリティポリシーの必要性
(1)(1)
個人サーバ運用の立場からみて・・・個人サーバ運用の立場からみて・・・
 作業手順、作業量の明確化作業手順、作業量の明確化
 やるべきこととやった方がいいこと、やっちゃいやるべきこととやった方がいいこと、やっちゃい
けないことが明確になる→ちゃんとメモを取ろうけないことが明確になる→ちゃんとメモを取ろう
!!
 作業全体の見通しがよくなる作業全体の見通しがよくなる
 忘れた頃にやってくるバージョンアップ忘れた頃にやってくるバージョンアップ // 再再
構築構築
 裁判裁判 // 訴訟、刑事事件などの際の証拠保全訴訟、刑事事件などの際の証拠保全
Copyright 2004,2007 © Kensuke Nezu, All22
セキュリティポリシーの必要性セキュリティポリシーの必要性
(2)(2)
…企業サーバ運用の立場からみて…企業サーバ運用の立場からみて
 作業手順、作業量の明確化作業手順、作業量の明確化
 複数人で均質の作業複数人で均質の作業
 全社的なセキュリティ意識の統一全社的なセキュリティ意識の統一
 対外的なポリシー運用の提示対外的なポリシー運用の提示
 担当者が変わった頃にくるバージョンアップ担当者が変わった頃にくるバージョンアップ
// 再構築再構築
 裁判 / 訴訟、刑事事件などの際の証拠保全
これは、企業だけでなく
、ゼミのサーバや部のサ
ーバ、学校のイントラサ
ーバでもおなじ。
これは、企業だけでなく
、ゼミのサーバや部のサ
ーバ、学校のイントラサ
ーバでもおなじ。
訴訟のリスク
はより大きい
!
訴訟のリスク
はより大きい
!
Copyright 2004,2007 © Kensuke Nezu, All23
セキュリティポリシーの必要性セキュリティポリシーの必要性
(3)(3)
素早いレスポンスを心がけよう!素早いレスポンスを心がけよう!
 サーバサーバ // サービス停止の判断を独力でできない場合はサービス停止の判断を独力でできない場合は
、「緊急連絡網」を作って指示を仰ごう。、「緊急連絡網」を作って指示を仰ごう。
 脆弱性指摘などがあった場合には、調査期間と回答期脆弱性指摘などがあった場合には、調査期間と回答期
限をつけてまずは返信しておこう。限をつけてまずは返信しておこう。
 指摘自体が「愉快犯」の可能性もゼロではありません。指摘自体が「愉快犯」の可能性もゼロではありません。
まずは、指摘事項の確認・再現を怠ってはなりませんまずは、指摘事項の確認・再現を怠ってはなりません
。。
 システムが侵入されていると、オペレータ作業でシステムが侵入されていると、オペレータ作業で rootroot
権限が乗っ取られる場合もあるので注意!権限が乗っ取られる場合もあるので注意!
 やりとりや作業は、きちんと記録を付けましょう。やりとりや作業は、きちんと記録を付けましょう。
Copyright 2004,2007 © Kensuke Nezu, All24
システムログの保存(保全措システムログの保存(保全措
置)置)
保存期間を最低1年以上に!保存期間を最低1年以上に!
 ディストリビューションの標準ディストリビューションの標準
設定は4週間。最低でも53週設定は4週間。最低でも53週
間(371日)に。間(371日)に。
 /etc/logrotate.conf/etc/logrotate.conf のの rotate 4 roatate 53→rotate 4 roatate 53→ にに
する。する。
 定期的にログを定期的にログを CD-RCD-R に焼いてに焼いて
バックアップを取りましょうバックアップを取りましょう
 /var/var は専用パーティションを用は専用パーティションを用
意して大きめにとる。意して大きめにとる。
 // と一緒で溢れるとfsが壊れること一緒で溢れるとfsが壊れるこ
とも・・・とも・・・
/etc/logrotate.conf の例:
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4 → 53
Copyright 2004,2007 © Kensuke Nezu, All25
サーバー運用の注意点サーバー運用の注意点 (1)(1)
「やられたら再インストールすればいい」「やられたら再インストールすればいい」は間は間
違い!違い!
 本当にやられちゃったら気付きません。 ←本当にやられちゃったら気付きません。 ← rootkitrootkit の存在の存在
 簡単な自動ツールくらいしか目で見てわからないです簡単な自動ツールくらいしか目で見てわからないです
 いつかは面倒になって目でも見なくなりますいつかは面倒になって目でも見なくなります
 「天災は忘れた頃にやってくる」「天災は忘れた頃にやってくる」
 ペーターとおおかみペーターとおおかみ
 気付いたときには手遅れです気付いたときには手遅れです教訓:侵入を事前予報できるシステムが必要教訓:侵入を事前予報できるシステムが必要
脆弱なフリー
のサーバ事件
Copyright 2004,2007 © Kensuke Nezu, All26
サーバー運用の注意点サーバー運用の注意点 (2)(2)
サーバー1台ですべてやろう・・・は間サーバー1台ですべてやろう・・・は間
違い!違い!
 NATNAT ルータ機能、フィルタリング機能、サーバ機ルータ機能、フィルタリング機能、サーバ機
能・・・全部をごちゃごちゃに1台で運用するのはスゴ能・・・全部をごちゃごちゃに1台で運用するのはスゴ
く難しいく難しい
 技術的チャレンジ・・・、でも一歩間違えるとネット全体に迷惑技術的チャレンジ・・・、でも一歩間違えるとネット全体に迷惑
が・・・が・・・
 趣味のサーバーも「グローバル趣味のサーバーも「グローバル IPIP アドレス」を持っている立場アドレス」を持っている立場
としては、としては、 NASANASA    /FBI/FBI    /NSA/NSA や、や、 YahooYahoo 、楽天、ホワイトハ、楽天、ホワイトハ
ウスサーバと同等の責任がありますウスサーバと同等の責任があります
 多重防御多重防御 // 多層防御が防御の基本多層防御が防御の基本
 なぜ、大阪城には外堀と内堀があったの?なぜ、大阪城には外堀と内堀があったの?
教訓:幾重にも防護壁を作っておきましょう教訓:幾重にも防護壁を作っておきましょう
ブロードバ
ンドルータ
の併用
Copyright 2004,2007 © Kensuke Nezu, All27
サーバー運用の注意点サーバー運用の注意点 (3)(3)
固定固定 IPIP アドレスを取得するアドレスを取得する
 IPIP アドレスはサーバーの「住所」ですアドレスはサーバーの「住所」です
 いつ転居するか分からない「住所」では困ることがありますいつ転居するか分からない「住所」では困ることがあります
 ドメインは「友達の鈴木君ち」みたいなもので固定であることがドメインは「友達の鈴木君ち」みたいなもので固定であることが
信頼性につながりません信頼性につながりません
 可変アドレス、ダイナミック可変アドレス、ダイナミック DNSDNS では利用できないものでは利用できないもの
も・・・も・・・
 おうちメールサーバーは運用できませんおうちメールサーバーは運用できません
 アクセスが多くなると他の人への攻撃になることも・・・アクセスが多くなると他の人への攻撃になることも・・・
教訓:やっぱり安心の固定教訓:やっぱり安心の固定 IPIP アドレス!アドレス!
Copyright 2004,2007 © Kensuke Nezu, All28
サーバー運用の注意点サーバー運用の注意点 (4)(4)
複数の固定複数の固定 IPIP アドレスを取得しよう!アドレスを取得しよう!
 インターネットのインシデントは、主に「自分のサーバインターネットのインシデントは、主に「自分のサーバ
だけをねらい打ちにしたもの」と、「機械的に総ナメにだけをねらい打ちにしたもの」と、「機械的に総ナメに
していくもの」に分けられますしていくもの」に分けられます
 「機械的」なものにはツールやウィルスなどがありますが、これ「機械的」なものにはツールやウィルスなどがありますが、これ
らはそれほどらはそれほど「危険性は高くありません」「危険性は高くありません」
 これを判断するためには、2つ以上の連続した(もしくこれを判断するためには、2つ以上の連続した(もしく
は近い)アドレスで監視をする必要がありますは近い)アドレスで監視をする必要があります
 これは、複数サーバでなくともこれは、複数サーバでなくとも IPIP アドレスのエイリアス機能でアドレスのエイリアス機能で
もも OKOK
  
教訓:比較/対照は分析の基礎です教訓:比較/対照は分析の基礎です
Copyright 2004,2007 © Kensuke Nezu, All29
サーバ管理者に求められる資質サーバ管理者に求められる資質 (1)(1)
 サーバ上の情報に個人的サーバ上の情報に個人的
興味を持ってはいけない興味を持ってはいけない
 ユーザのパスワードはユーザのパスワードは
「すぐに忘れる」「すぐに忘れる」
 管理の都合上「知ってし管理の都合上「知ってし
まった」事も知らぬ存ぜまった」事も知らぬ存ぜ
ぬを貫くぬを貫く
 サーバ上の不法行為の証サーバ上の不法行為の証
拠には常に目を光らせる拠には常に目を光らせる
 管理者権限、管理者ア管理者権限、管理者ア
カウント情報は、管理カウント情報は、管理
者をやめたら「忘れな者をやめたら「忘れな
ければならない」ければならない」
From hira@<平山>
To naka@<なかむらくん>
Subject きのうのデート
なかむらくん、昨日は楽しい
デートをどうもありがとう・
・・。
遊園地とってもたのしかった
です。また誘ってください。
ふむふ
む・・・
Copyright 2004,2007 © Kensuke Nezu, All30
サーバ管理者に求められる資質サーバ管理者に求められる資質 (2)(2)
 サーバ管理者は実用的サーバ管理者は実用的
な法律家である必要がな法律家である必要が
あります。あります。
 著作権法著作権法
 不正アクセス禁止法不正アクセス禁止法
 個人情報保護法個人情報保護法
 プロバイダ法プロバイダ法
 表現の自由と名誉毀損表現の自由と名誉毀損
 脅迫等の刑法脅迫等の刑法
 etc…etc…
 世の状況(裁判の判決世の状況(裁判の判決
など)にも敏感でなけなど)にも敏感でなけ
ればなりません。ればなりません。
・映画のコピー
・不許可のアイドル写真
・ TV のキャプチャ画像
・不法なソフトウェアコピー
・ホームページのコピペふむふ
む・・・
Copyright 2004,2007 © Kensuke Nezu, All31
サーバ管理者に求められる資質サーバ管理者に求められる資質 (3)(3)
~優良推薦参考図書~~優良推薦参考図書~
 「ハイテク犯罪捜査入門~捜査実務「ハイテク犯罪捜査入門~捜査実務
編」編」
 警察、検察側の現在の常識と今後数年間の警察、検察側の現在の常識と今後数年間の
動向を占うことができる書籍動向を占うことができる書籍
 著者は、現役の札幌高等検事局検事さん著者は、現役の札幌高等検事局検事さん
 技術書ではないが、「捜査」の現場で、実技術書ではないが、「捜査」の現場で、実
際に何がどのような判断で行われているか際に何がどのような判断で行われているか
を知っておくことは必ず役立ちます。特にを知っておくことは必ず役立ちます。特に
、初動捜査における「証拠」として何を用、初動捜査における「証拠」として何を用
意しておけばよいかなどの判断にも使えま意しておけばよいかなどの判断にも使えま
す。す。
※※ 技術的には、現場の警察官を対象として技術的には、現場の警察官を対象として
いるため、初心者向けの若干のウソも見らいるため、初心者向けの若干のウソも見ら
れます。れます。
Copyright 2004,2007 © Kensuke Nezu, All32
サーバー構築方法サーバー構築方法
Copyright 2004,2007 © Kensuke Nezu, All33
セキュアサーバー構築方法論セキュアサーバー構築方法論
10:9010:90 の法則を適用すると・・・の法則を適用すると・・・
 パケットフィルタリングによるセキュリティの確保パケットフィルタリングによるセキュリティの確保
 サーバー、ルーターそれぞれで設定が必要サーバー、ルーターそれぞれで設定が必要
 守れるもの、守れないものを意識することが必要守れるもの、守れないものを意識することが必要
 サービスの限定など、他の機能との組み合わせが必要サービスの限定など、他の機能との組み合わせが必要
 サービスの限定、公開範囲の限定サービスの限定、公開範囲の限定
 各サービス、ソフトウェア毎の設定が必要  各サービス、ソフトウェア毎の設定が必要  
 自動監視ツールなどによる監視コストの低減自動監視ツールなどによる監視コストの低減
 ツールとして自作しなければいけない場合もあるツールとして自作しなければいけない場合もある
 プロバイダのサービスや商用ソフトウェア利用が推奨される場合プロバイダのサービスや商用ソフトウェア利用が推奨される場合
も・・・  も・・・              
商用ファイヤ
ーウォール
商用ファイヤ
ーウォール
Snort などの
侵入検知ツー
ル
Snort などの
侵入検知ツー
ル
本格的なスキ
ルや監視コス
トが必要
Copyright 2004,2007 © Kensuke Nezu, All34
パケットフィルタリングについパケットフィルタリングについ
てて (1)(1)
パケットフィルタリングが有効な場面パケットフィルタリングが有効な場面
 公開する内容、条件、相手などがルールとして固定的に決定できる場公開する内容、条件、相手などがルールとして固定的に決定できる場
合合
 時間帯限定公開や、同時接続数上限などの設定は基本的にできな時間帯限定公開や、同時接続数上限などの設定は基本的にできな
いい
 FTPFTP でのファイル転送などサービスポートが動的なものには向かでのファイル転送などサービスポートが動的なものには向か
ないない
 サービスの単位で、または公開先として固定的な場所からのアクセスサービスの単位で、または公開先として固定的な場所からのアクセス
が特定できる場合が特定できる場合
 今日は今日は NIFTYNIFTY から、明日はから、明日は so-netso-net から・・・という動的な条件にから・・・という動的な条件に
は向かないは向かない
 HTTPHTTP でで javascriptjavascript の実行権限などサービス内での制限はできないの実行権限などサービス内での制限はできない
時間帯限定はブロードバ
ンドルータによっては可
能なものもあります
時間帯限定はブロードバ
ンドルータによっては可
能なものもあります
Copyright 2004,2007 © Kensuke Nezu, All35
主なウェルノウン・ポ主なウェルノウン・ポ
ートート
 「「 ** 」のついているサービスは基本」のついているサービスは基本
的に公開すべきでないポート的に公開すべきでないポート
 社内社内 LANLAN 等、イントラネットでの等、イントラネットでの
運用を前提とするセキュアでないサ運用を前提とするセキュアでないサ
ービスービス
 インターネットがいにしえの良き時インターネットがいにしえの良き時
代であったころに参加者がすべて善代であったころに参加者がすべて善
良であることを前提としたサービス良であることを前提としたサービス
ホ ゚ー ト TCP/ UDP サービス名
20 TCP ft p- dat a FTPサービスのデータ転送用
21 TCP ft p- c o nt ro l FTPサービス制御用
22 TCP s s h Se c ure Sh e llセキュア・シェル( )接続
23 TCP t e lne t Te ln e t 接続
25 TCP s mtp s e ndmail/ qmail/ po s t fixなどのメール・サーバ接続
53 TCP/ UDP do main DNSドメイン・ネーム・サービス( )
67 UDP bo o t ps BOOTPサーバ*
68 UDP bo o t pc BOOTPクライアント*
69 UDP t ftp TFTPサーバ*
70 TCP go ph e r Go ph e rサーバ*
79 TCP finge r Finge rサービス*
80 TCP h t tp We bサーバ
98 TCP linuxc o nf linuxc o nfネットワーク・サービス*
109 TCP po p- 2 POP- 2メール受信用
110 TCP po p- 3 POP- 3メール受信用
111 TCP/ UDP s unrpc RPC 4.0 po rt mappe r*
113 TCP ide nt ide ntクライアント・ユーザ確認( )*
119 TCP nnt p インターネット・ニュース・サービス
123 TCP/ UDP nt p ネットワーク時刻同期サービス
135 TCP mic ro s o ft- rpc Mic ro s o ft RPC Exc h ange Se rve rの サービス( など)
137 UDP ne t bio s - ns MS- Ne t wo rkネーム・サービス*
138 UDP ne t bio s - dgm MS- Ne t wo rkブラウジング・サービスなど*
139 TCP ne t bio s - s s n MS- Ne t wo rk /ファイルプリンタ共有サービス*
143 TCP imap IMAP4メール・サービス
144 TCP Ne WS Ne WSウィンドウ・システム・サービス*
161 UDP s nmp ネットワーク管理用*
162 UDP s nmp- t rap ネットワーク管理用(異常検知など)*
443 TCP h t tps We b暗号化した サービス
445 TCP mic ro s o ft- DS Windo ws 2000 CIFS以降の 接続用*
512 TCP e xe c BSD UNIX re xe c d系 の デーモン用*
512 UDP biff UNIX biff(メール到着通知)サービス*
513 TCP lo gin BSD UNIX rlo gind系 の デーモン用*
513 UDP wh o BSD UNIX rwh o d系 の デーモン用*
514 TCP s h e ll BSD UNIX rwh o d系 の デーモン用*
514 UDP s ys lo g BSD UNIX s ys lo gd系 の デーモン用*
515 TCP print e r BSD UNIX lpd系 の デーモン用*
517 UDP t alk BSD UNIX talkd系 の デーモン用*
518 UDP nt alk SunOS talkdの デーモン用*
520 UDP ro ute BSD UNIX ro ut e d系 の デーモン用*
525 UDP t ime d BSD UNIX time d系 の デーモン用*
554 TCP/ UDP rts p リアルタイム・ストリーミング用
635 UDP mo unt NFSマウント・サービス*
901 TCP s wat Samba We bの ベース管理ツール用*
Copyright 2004,2007 © Kensuke Nezu, All36
パケットフィルタリングについパケットフィルタリングについ
てて (3)(3)
10241024 以降の定義済ポートの例以降の定義済ポートの例
 Microsoft SQL ServerMicrosoft SQL Server のの RPCRPC (( Remote Procedure Call)Remote Procedure Call) で使うで使う 1433/TCP1433/TCP
 非透過型プロキシーサービス非透過型プロキシーサービス (delegate(delegate など)でなど)で 8080/TCP,1080/TCP8080/TCP,1080/TCP
 X WindowX Window のフォントサーバのフォントサーバ (xfs)(xfs) でで 7100/TCP7100/TCP
 X WindowX Window のの XX サーバーでサーバーで 6000/TCP6000/TCP
 仮名漢字変換仮名漢字変換 WnnWnn サーバーでサーバーで 22273/TCP22273/TCP
 仮名漢字変換仮名漢字変換 CannaCanna サーバーでサーバーで 5680/TCP5680/TCP
 NFSNFS でで 2049/UDP2049/UDP
インターネットに公開すべきでないポートがほとんどインターネットに公開すべきでないポートがほとんど
Copyright 2004,2007 © Kensuke Nezu, All37
パケットフィルタリングについパケットフィルタリングについ
てて (4)(4)
10241024 以降で以降で IANAIANA 未定義だがよくウィルスに使われるポートの例未定義だがよくウィルスに使われるポートの例
 SasserSasser ウィルスが使うウィルスが使う Microsoft RPCMicrosoft RPC のの 1025/TCP1025/TCP
 DamewareDameware ウィルスが使うバックドアポートウィルスが使うバックドアポート 6129/TCP6129/TCP
 MyDoomMyDoom ウィルスが使うバックドアポートウィルスが使うバックドアポート 3127/TCP3127/TCP
 SQL SnakeSQL Snake ウィルスが使うウィルスが使う Microsoft SQL ServerMicrosoft SQL Server のの 1433/TCP1433/TCP
 バックドアバックドア (( トロイの木馬)プログラムトロイの木馬)プログラム WinHoleWinHole でで 1080/TCP1080/TCP
 バックドアプログラムバックドアプログラム RingZeroRingZero でで 8080/TCP8080/TCP とと 3128/TCP3128/TCP
 Windows XPWindows XP のリモートデスクトップが使うのリモートデスクトップが使う 3389/TCP3389/TCP
絶対にインターネットに公開すべきでないポート絶対にインターネットに公開すべきでないポート
Copyright 2004,2007 © Kensuke Nezu, All38
パケットフィルタリングについパケットフィルタリングについ
てて (5)(5)
危険なソースルーティング危険なソースルーティング
コンピュータ C攻撃者 B
コンピュータ A
送信元:送信元: AA 宛先:宛先: CC
経由:経由:
送信元:送信元: CC 宛先:宛先: AA
経由:経由: BB
送信元:送信元: CC 宛先:宛先: AA
経由:経由:
送信元:送信元: AA 宛先:宛先: CC
経由:経由: BB
通常のパケット
ソースルーティン
グされると・・・
Copyright 2004,2007 © Kensuke Nezu, All39
パケットフィルタリングについパケットフィルタリングについ
てて (6)(6)
TCPTCP の特殊な状態の特殊な状態 (1)(1) ~接続~接続~~ 3-Way Handshake3-Way Handshake
SEQ :シーケンス番
号
ACK :返信番号
CTL :制御フラグ
③<411> <312> <ACK>+ データ
① <311> <SYN>
② <411> <312> <SYN,ACK>
要求者 A 相手 B
SEQ ACK CTL
3-3- ウェイ・ハンドシウェイ・ハンドシ
ェイクェイク パケットフィルタリ
ングで防御しきれな
い
•① を大量に送りつけ
て B をサービス不能
に・・・ → SYN Flood
攻撃
•① の応答②があるか
どうかでポートスキ
ャン
Syslog にもでてきませ
ん
Syslog にもでてきませ
ん
防御にはサーバ上のユー
ティリティなどが必要
防御にはサーバ上のユー
ティリティなどが必要
Web やft
pを一切サ
ービスして
ないなら防
御可能
Web やft
pを一切サ
ービスして
ないなら防
御可能
Copyright 2004,2007 © Kensuke Nezu, All40
パケットフィルタリングについパケットフィルタリングについ
てて (7)(7)
TCPTCP の特殊な状態の特殊な状態 (2)(2) ~切断~切断~~
SEQ :シーケンス番
号
ACK :返信番号
CTL :制御フラグ
パケットフィルタリ
ングで防御しきれな
い
•① の応答②があるか
どうかでポートスキ
ャン
実際は双方向通信なので
、反対向きも行われる
実際は双方向通信なので
、反対向きも行われる
① <FIN>
② <FIN,ACK>
リクエスト側
SEQ ACK CTL
リクエストを受ける側
多くの機器や OS ではサー
ビスが有効なら未接続の状
態でも <FIN> に反応する
多くの機器や OS ではサー
ビスが有効なら未接続の状
態でも <FIN> に反応する
Copyright 2004,2007 © Kensuke Nezu, All41
パケットフィルタリングについパケットフィルタリングについ
てて (8)(8)
UDP(User Datagram Protocol)UDP(User Datagram Protocol) についてについて
 パケットが相手に到達したことが確認できないパケットが相手に到達したことが確認できない
 「接続を覚えて」おかなくてもよい「接続を覚えて」おかなくてもよい
 TCPTCP と異なり相手の返信をまたなくてもよいと異なり相手の返信をまたなくてもよい
インターネットサービスでは少数派、主にインターネットサービスでは少数派、主に DNS/snmpDNS/snmp 等で利用される等で利用される
名前←→ IP アドレス変換の
問い合わせなど
名前←→ IP アドレス変換の
問い合わせなど
プライマリ DNS とセカンダリ
DNS とのデータ複写で TCP も利
用している
プライマリ DNS とセカンダリ
DNS とのデータ複写で TCP も利
用している
Copyright 2004,2007 © Kensuke Nezu, All42
パケットフィルタリングについパケットフィルタリングについ
てて (9)(9)
ICMP(Internet Control Message Protocol)ICMP(Internet Control Message Protocol) についてについて
 データ通信には使われないデータ通信には使われない
 ネットワーク障害によるエラー通知ネットワーク障害によるエラー通知
 診断機能用のメッセージのやりとり診断機能用のメッセージのやりとり
 いくつかのメッセージタイプがあるいくつかのメッセージタイプがある
 ブロードキャストアドレス宛てのブロードキャストアドレス宛ての ICMPICMP には全機器が反応には全機器が反応
Host
Unreachable
Host
Unreachable
Network
Unreachable
Network
Unreachable
自サイトのブロードキャストアドレス宛の自サイトのブロードキャストアドレス宛の ICMPICMP は遮断しなければならないは遮断しなければならない
Ping や
traceroute など
Ping や
traceroute など
Smurf という
DDoS の防止
Smurf という
DDoS の防止
Copyright 2004,2007 © Kensuke Nezu, All43
パケットフィルタリングについパケットフィルタリングについ
てて (10)(10)
タイプ 名前 意味
0 Ec ho Re ply ICMP ping/ trac e routeエコー応答( の返信用)
3 De s tination Unre ac hable あて先アドレスに到達不可能
4 Sourc e Que nc he 受信バッファあふれによる送信元への通信停止要求
5 Re dire c t 最適な経路でないことを送信元に通知
8 Ec ho ICMP ping/ trac e routeエコー要求( の送信用)
9 Route r Adve rtis e me nt ルータ通知
10 Route r Se le c tion ルータ選択
11 Time Exc e e d TTL Time To Live( )時間の超過
12 Parame te r Proble m パケットのパラメータ異常
13 Time s tamp タイム・スタンプ保持要求
14 Time s tamp Re ply タイム・スタンプ保持応答
17 Addre s s Mas k Re que s t アドレス・マスク要求
18 Addre s s Mas k Re ply アドレス・マスク応答
ICMP メッセージのタイプ
Windows 版の tracert
コマンドが利用
Windows 版の tracert
コマンドが利用
UNIX/Linux 版の traceroute は
UDP/33434 を使用
UNIX/Linux 版の traceroute は
UDP/33434 を使用
Copyright 2004,2007 © Kensuke Nezu, All44
パケットフィルタリングについパケットフィルタリングについ
てて (11)(11)
ICMPICMP Smurf攻撃のしくみSmurf攻撃のしくみ
(1)(1)
1.1. 攻撃者は攻撃者は IPIP アドレスをなアドレスをな
りすまして各サイトのブりすまして各サイトのブ
ロードキャストアドレスにロードキャストアドレスに ICMPICMP
エコーを送信エコーを送信
ターゲット
攻撃者
Copyright 2004,2007 © Kensuke Nezu, All45
パケットフィルタリングについパケットフィルタリングについ
てて (12)(12)
ICMPICMP Smurf攻撃のしくみSmurf攻撃のしくみ
(2)(2)
1.1. 攻撃者は攻撃者は IPIP アドレスをなアドレスをな
りすまして各サイトのブりすまして各サイトのブ
ロードキャストアドレスにロードキャストアドレスに ICMPICMP
エコーを送信エコーを送信
2.2. 各サイトの全機器がター各サイトの全機器がター
ゲットに一斉にゲットに一斉に ICMPICMP エエ
コーリプライを送信コーリプライを送信
3.3. ネットワークがパンクネットワークがパンク
ターゲット
攻撃者
Copyright 2004,2007 © Kensuke Nezu, All46
パケットフィルタリングについパケットフィルタリングについ
てて (13)(13)
実は実は SmurfSmurf 攻撃には攻撃には DNSDNS クエリクエリ SmurfSmurf 攻撃もあります攻撃もあります
1.1. 犠牲者ホストの犠牲者ホストの IPIP アドレスをなりすました端末かアドレスをなりすました端末か
らの問いあわせ(クエリ)をネット上のらの問いあわせ(クエリ)をネット上の DNSDNS サーバサーバ
群に一斉送信群に一斉送信
2.2. DNSDNS サーバがインターネット側からのクエリに反応サーバがインターネット側からのクエリに反応
して、検索結果を返すして、検索結果を返す
3.3. 犠牲者ホストにクエリの結果が溢れて犠牲者ホストにクエリの結果が溢れて DDoSDDoS になるになる
  
これは本来、これは本来、 LANLAN 内からの端末クエリしか反応しない様に内からの端末クエリしか反応しない様に
DNSDNS が適切に設定されていれば防げるものですが適切に設定されていれば防げるものです
Copyright 2004,2007 © Kensuke Nezu, All47
パケットフィルタリングについパケットフィルタリングについ
てて (14)(14)
短命なポート(エフェメラル・ポート)短命なポート(エフェメラル・ポート)
Web サーバ
PC ポート番号:1
234
ポート番号:8
0
ポート番号:1
234
ポート番号:8
0
•接続を依頼する側が一時的に使用す
るポート
•1024 番以降の適当なポートを使用
Copyright 2004,2007 © Kensuke Nezu, All48
パケットフィルタリングについパケットフィルタリングについ
てて (15)(15) ~パケットフィルタリン~パケットフィルタリン
グの要点~グの要点~
パケットフィルタリングで利用できるパラメータパケットフィルタリングで利用できるパラメータ
 送信元送信元 IPIP アドレスアドレス
 あて先あて先 IPIP アドレスアドレス
 送信元ポート番号送信元ポート番号
 あて先ポート番号あて先ポート番号
 プロトコル種別プロトコル種別
 TCPTCP のフラグ(のフラグ( SYN,FIN,ACKSYN,FIN,ACK など)など)
 ICMPICMP のタイプのタイプ
これらの情報を必要に応じて組み合わせて設定するこれらの情報を必要に応じて組み合わせて設定する
範囲指定が可能
機器によっては未対機器によっては未対
応応
Copyright 2004,2007 © Kensuke Nezu, All49
パケットフィルタリングについてパケットフィルタリングについて
(16)(16)
ブロードバンドルーターの設定の要点ブロードバンドルーターの設定の要点
 NAT+IPNAT+IP マスカレードでは外部からの攻撃はまず不可能マスカレードでは外部からの攻撃はまず不可能
 外部からの攻撃を防止する目的のパケットフィルタリング不要外部からの攻撃を防止する目的のパケットフィルタリング不要
 → → SYNFloodSYNFlood 攻撃防止機能を持つものもある攻撃防止機能を持つものもある
 LANLAN からの外向きのパケットフィルタリングが必要からの外向きのパケットフィルタリングが必要
 ウィルス感染ウィルス感染 PCPC からのパケット発信(からのパケット発信( SMTPSMTP 大量送信など)防大量送信など)防
止止
 Microsoft NetworkMicrosoft Network (ネットワークフォルダ(ネットワークフォルダ )) 等のパケットの漏洩を防等のパケットの漏洩を防
止止
 公開サーバは簡易公開サーバは簡易 DMZDMZ もしくはポート単位で公開するもしくはポート単位で公開する
 ルータルータ 22 台用いて、本格的な台用いて、本格的な DMZDMZ を組むことを強くを組むことを強く
推奨します推奨します
Copyright 2004,2007 © Kensuke Nezu, All50
パケットフィルタリングについてパケットフィルタリングについて
(17)(17)
公開サーバーの設定の要点公開サーバーの設定の要点
 いくつかの公開サービスいくつかの公開サービス
 プライマリプライマリ DNSDNS
 通常の通常の 53/UDP53/UDP へのアクセスと、セカンダリをお願いしているセへのアクセスと、セカンダリをお願いしているセ
カンダリカンダリ DNSDNS のの IPIP アドレスからのアドレスからの 53/TCP53/TCP への接続許可が必要への接続許可が必要
 セカンダリメール・サーバー(受けてあげるなら・・セカンダリメール・サーバー(受けてあげるなら・・
・)・)
 他の人のプライマリ・メール・サーバーに何らかの障害があると他の人のプライマリ・メール・サーバーに何らかの障害があると
きにメールを代行受信きにメールを代行受信
 25/TCP25/TCP への接続を許可した上で、プライマリ・メール・サーバへの接続を許可した上で、プライマリ・メール・サーバ
ーのーの 25/TCP25/TCP への接続を許可し受信済メールを転送可能にへの接続を許可し受信済メールを転送可能に
Copyright 2004,2007 © Kensuke Nezu, All51
パケットフィルタリングについてパケットフィルタリングについて
(18)(18)
公開サーバーの設定例公開サーバーの設定例
番号 パケットの向き IP送信元 アドレス IPあて先 アドレス プロトコル 送信元ポート番号 あて先ポート番号 ICMPのタイプ /通過 破棄 説明
1 IN すべて 61.211.1.178 TCP すべて 25,80,443 - 通過 We b SMTP, の接続を許可
2 IN 192.168.0.0/ 24 61.211.1.178 TCP すべて 22 - 通過 LAN s s hからのみ を許可
3 IN IPセカンダリの アドレス 61.211.1.178 TCP すべて 53 - 通過 DNSセカンダリ からのゾーン転送を許可
4 IN すべて 61.211.1.178 UDP すべて 53 - 通過 DNSへの問い合わせを許可
5 IN すべて 61.211.1.178 ICMP - - 0 3 8 11, , , 通過 ネットワーク試験用
6 IN すべて すべて すべて すべて すべて すべて 破棄 上記以外の入力パケットを遮断
7 OUT 61.211.1.178 IPプライマリの アドレス TCP すべて 25 - 通過 プライマリ・メール・サーバへの転送を許可
8 OUT 61.211.1.178 すべて TCP 25 80 443, , すべて - 通過 より安全にするなら設定する
9 OUT 61.211.1.178 61.211.1.180 TCP 22 すべて - 通過 同上
10 OUT 61.211.1.178 61.210.22.254 TCP すべて 53 - 通過 同上
11 OUT 61.211.1.178 すべて UDP 53 すべて - 通過 同上
12 OUT 61.211.1.178 すべて ICMP - - 0 3 8 11, , , 通過 同上
13 OUT すべて すべて すべて すべて すべて すべて 破棄 -
MTA の設定不良によ
るオープンリレーの防
止
MTA の設定不良によ
るオープンリレーの防
止
管理者の ssh アクセスをインターネットから可
能にするならルール2を変更。この場
合、 /etc/hosts.allow などでアクセス元を限定
すること。
管理者の ssh アクセスをインターネットから可
能にするならルール2を変更。この場
合、 /etc/hosts.allow などでアクセス元を限定
すること。
パッケージのアップデートはftpを
使う場合がほとんどなので、この場合
、ルール 13 を止めないといけない
パッケージのアップデートはftpを
使う場合がほとんどなので、この場合
、ルール 13 を止めないといけない
Copyright 2004,2007 © Kensuke Nezu, All52
パケットフィルタリングの具体例パケットフィルタリングの具体例 (1)(1)
LinuxLinux のの iptablesiptables 利用上の注意点利用上の注意点
1. インターネットに接続した状態で /etc/rc.d/init.d/iptables restart
するのはあまり好ましくありません。
1. 上記スクリプトの設計上、いったん全部削除して、ポリシーだ
け残るので、 ACCEPT ポリシーだけ残った状態で全てのポート
が一瞬オープン状態になります
2. システムの再起動ならば、 iptables のポリシが設定されてから
ネットワークが立ち上がるので安全です。
2. ネットワークを切断してコンソールで作業するか、シス
テムを再立ち上げしましょう。
CentOSもデフォルトではポリシがCentOSもデフォルトではポリシが ACCEPTACCEPT ですです
Copyright 2004,2007 © Kensuke Nezu, All53
パケットフィルタリングの具体例パケットフィルタリングの具体例 (2)(2)
CentOSでファイアウォールオンの標準例CentOSでファイアウォールオンの標準例
(/etc/sysconfig/iptables)(/etc/sysconfig/iptables)
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
Copyright 2004,2007 © Kensuke Nezu, All54
パケットフィルタリングの具体例パケットフィルタリングの具体例 (3)(3)
CentOSでファイアウォールオン標準設定CentOSでファイアウォールオン標準設定
を改善してみましょう!を改善してみましょう!
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type ping -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type pong -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
Copyright 2004,2007 © Kensuke Nezu, All55
実習実習 11 :: CentOSCentOS のファイアウォールのファイアウォール
  機能をカスタマイズしてみよう  機能をカスタマイズしてみよう
(( 55 分)分)
 CentOSCentOS は、は、 RedHat Enterprise LinuxRedHat Enterprise Linux と同様にと同様に
iptablesiptables を利用したパケットフィルタ機能によを利用したパケットフィルタ機能によ
り簡易ファイアウォールを実現しています。り簡易ファイアウォールを実現しています。
 前前 33 ページの内容を見て、実際に簡易ファイページの内容を見て、実際に簡易ファイ
アウォールを設定してみましょう。そして、アウォールを設定してみましょう。そして、
その効果を確認してみましょう。その効果を確認してみましょう。 icmpicmp の設定の設定
も変更してみましょう。も変更してみましょう。
 GUIGUI の設定コマンドはの設定コマンドは rootroot で、次のコマンドで、次のコマンド
を実行します。を実行します。
# system-config-securitylevel# system-config-securitylevel
また、設定ファイルは、また、設定ファイルは、 /etc/sysconfig/iptables/etc/sysconfig/iptables
です。です。
Copyright 2004,2007 © Kensuke Nezu, All56
サーバー構築手順~インストールサーバー構築手順~インストール
編~編~
インストール時にはブロードバンドルータ内で作業せインストール時にはブロードバンドルータ内で作業せ
よ!よ!
 TCP/IPTCP/IP の制限でファイヤーウォール機能の制限でファイヤーウォール機能 (( パケットフィルパケットフィル
タタ )) だけでは防止できないものもあるだけでは防止できないものもある
 ディストリビューションディストリビューション CDCD だけではなく最だけではなく最
初にアップデートするのにインターネット接初にアップデートするのにインターネット接
続が必要続が必要
 ディストビューションディストビューション CDCD はセキュリティ的はセキュリティ的
に問題のある「古い状態」であることが多いに問題のある「古い状態」であることが多い
Copyright 2004,2007 © Kensuke Nezu, All57
 CentOSCentOS は、インターネットに接続した上でオは、インターネットに接続した上でオ
ンラインで追加インストールをしたり、ソフンラインで追加インストールをしたり、ソフ
トウェアの更新版をインストールしたりできトウェアの更新版をインストールしたりでき
ます。ます。
 本講座で使用する追加のソフトウェアの大半本講座で使用する追加のソフトウェアの大半
をを Cent OSCent OS のアップデータ(のアップデータ( yum)yum) でインスでインス
トールできるようにするソフトウェア書庫トールできるようにするソフトウェア書庫
(リポリトジ)もいくつか公開されています(リポリトジ)もいくつか公開されています
。。
 時間がないので実習は行いませんが、内容は時間がないので実習は行いませんが、内容は
実習補助資料にあるので、後で自分で環境構実習補助資料にあるので、後で自分で環境構
築してみてください。築してみてください。
CenCen tt OSOS を使った追加ソフトを使った追加ソフト
ウェアウェア
インストールについてインストールについて
Copyright 2004,2007 © Kensuke Nezu, All58
サーバー構築手順~最初の1手サーバー構築手順~最初の1手 (1)(1) ~~
sshssh サーバー以外をまずは非公開にサーバー以外をまずは非公開に
 ssh 環境を最初に構築しよう
 端末側( Windows) は PuTTY や TeraTERM pro
+ TTSSH 、 Poderosa で環境を構築しよう
 セキュリティ的な検討、日本語化度を考慮
するとPoderosaがオススメ。ただ
し、 ssh2 の鍵の互換性に若干の問題がある
。
Copyright 2004,2007 © Kensuke Nezu, All59
サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (2)(2) ~~
PuTTYPuTTY
 ダウンロードサイトダウンロードサイト (( 英語英語 ))
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.htmlhttp://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
 ダウンロードサイト(非公式日本語パッチ版ダウンロードサイト(非公式日本語パッチ版 ))
http://www11.tok2.com/home/hdk/download.htmlhttp://www11.tok2.com/home/hdk/download.html
 非公式日本語パッチ作成者サイト非公式日本語パッチ作成者サイト
http://hp.vector.co.jp/authors/VA024651/#PuTTYkj_tophttp://hp.vector.co.jp/authors/VA024651/#PuTTYkj_top
 特徴特徴
 SSH1(RSA), SSH2SSH1(RSA), SSH2 (( DSA)DSA) に対応に対応
 cp, ftpcp, ftp に対応するに対応する PSCP, PSFTPPSCP, PSFTP コマンドがあるコマンドがある
 Windows 95/98/Me/NT/2000/XP for x86Windows 95/98/Me/NT/2000/XP for x86 以外に以外に NT on AlphaNT on Alpha も対応も対応
Copyright 2004,2007 © Kensuke Nezu, All60
サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (3)(3) ~~
TeraTERM pro + TTSSHTeraTERM pro + TTSSH 日本語版日本語版
 TeraTERM TeraTERM→TeraTERM TeraTERM→ 日本語版 → 日本語版 →  TTSSH →TTSSH →    TTSSHTTSSH 日本語版と順番にバ日本語版と順番にバ
イナリファイルの差分を上書きする必要がある(日本語メニューが不要であイナリファイルの差分を上書きする必要がある(日本語メニューが不要であ
れば、日本語版は不要)れば、日本語版は不要)
 インストール手順、ダウンロード先、および使い方については以下のサイトインストール手順、ダウンロード先、および使い方については以下のサイト
が詳しいが詳しい
http://www.netlab.is.tsukuba.ac.jp/~one/ssh/http://www.netlab.is.tsukuba.ac.jp/~one/ssh/
 特徴特徴
 SSH1(RSA)SSH1(RSA) にのみ対応にのみ対応
 安定した日本語環境安定した日本語環境
 開発、メインテナンスはすでに終了開発、メインテナンスはすでに終了
 右のように右のように UTF-8UTF-8 対応、対応、 ssh2ssh2 対応も有志の方により対応も有志の方により
   進んでいます。   進んでいます。
 UTF-8UTF-8 はは Fedora CoreFedora Core 以降が標準コードに採用以降が標準コードに採用
・最近、 ssh2 対応などの拡張
をしようというプロジェクトが
できました。対応するサイトは
、
http://www.ayera.com/teraterm
で TeraTERM 3.1.3 が公開されて
います。日本語版はまだない模
様。
・ ttssh で UTF-8 をサポートす
るプロジェクトもあります
・最近、 ssh2 対応などの拡張
をしようというプロジェクトが
できました。対応するサイトは
、
http://www.ayera.com/teraterm
で TeraTERM 3.1.3 が公開されて
います。日本語版はまだない模
様。
・ ttssh で UTF-8 をサポートす
るプロジェクトもあります
(ssh2 対応含む ) 。
Copyright 2004,2007 © Kensuke Nezu, All61
サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (3)(3) ~~
Poderosa(Poderosa( ポデローサ)ポデローサ)
 日本語の扱いや日本語の扱いや WindowsWindows プログラムとしての安定性に特徴があります。プログラムとしての安定性に特徴があります。
 純粋な、純粋な、 .NET Framework.NET Framework を使用したアプリケーションです。を使用したアプリケーションです。
 タブ式タブ式 GUIGUI 、、 SSH2SSH2 をサポートしているオープンソースのをサポートしているオープンソースの WindowsWindows 用ターミ用ターミ
ナルエミュレータ。ナルエミュレータ。
 インストール手順、ダウンロード先、および使い方については以下のサイトインストール手順、ダウンロード先、および使い方については以下のサイト
が詳しいが詳しい
http://ja.poderosa.org/http://ja.poderosa.org/
 特徴特徴
 SSH1,SSH2SSH1,SSH2 に対応に対応
 .NET Framework.NET Framework 対応言語でマクロを記述可能対応言語でマクロを記述可能
 ローカルのローカルの CygwinCygwin やや SFU(Services for UNIX)SFU(Services for UNIX) に対応に対応
 タブ式ウィンドウ画面タブ式ウィンドウ画面
 SSH2SSH2 ポートフォワードツール、ポートフォワードツール、 SSHSSH 鍵作成ウィザード、鍵作成ウィザード、 SOCKSSOCKS 対対
応、応、 IPv6IPv6 対応など多くのサポート機能、ツールがある対応など多くのサポート機能、ツールがある
Copyright 2004,2007 © Kensuke Nezu, All62
サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (4)(4) ~~
CentOSCentOS のサーバー側のサーバー側 sshdsshd の設定上の注意の設定上の注意
 /etc/ssh/sshd_config/etc/ssh/sshd_config のパラメータのパラメータ
PermitRootLogin noPermitRootLogin no root→ root→ での直接ログイン不可での直接ログイン不可
MaxAuthTries 1MaxAuthTries 1 1→ 1→ セッションの最大試行回数1セッションの最大試行回数1
回回
PasswordAuthentication no →PasswordAuthentication no → 生パスワードでの認証不可生パスワードでの認証不可
GSSAPIAuthentication no GSSAPI→GSSAPIAuthentication no GSSAPI→ 認証不可認証不可
 etc/hosts.allowetc/hosts.allow のパラメータのパラメータ
sshd:[sshd:[ 自サイトのネットワークアドレス自サイトのネットワークアドレス ]/[]/[ ネットマスネットマス
クク ]]
sshd: .jp*sshd: .jp*
ほとんどのイリーガルアクセスを防止
可能
Copyright 2004,2007 © Kensuke Nezu, All63
SSHSSH の裏まで知りたいあなたに・・の裏まで知りたいあなたに・・
・・
~優良推薦図書~~優良推薦図書~
「実用「実用 SSHSSH 第第 22 版版 -- セキュアシェル徹底活用ガセキュアシェル徹底活用ガ
イド」イド」
http://www.oreilly.co.jp/books/4873112877/http://www.oreilly.co.jp/books/4873112877/
 細かな使い方や設定方法が書かれています細かな使い方や設定方法が書かれています
。。
 新しい使い方のヒントが載っています。新しい使い方のヒントが載っています。
 コンパイル時のオプションコンパイル時のオプション
 サーバ全体のオプションサーバ全体のオプション
 各ユーザが利用可能なオプション各ユーザが利用可能なオプション
 ftpftp をを SSHSSH に通すに通す
 鍵の種類で利用できる機能を制限鍵の種類で利用できる機能を制限
Copyright 2004,2007 © Kensuke Nezu, All64
実習2:ssh環境を構築しよう!実習2:ssh環境を構築しよう!
(( 11 5分)5分)
 ここまでのsshの説明に従った設定を行います。ここまでのsshの説明に従った設定を行います。
/etc/ssh/sshd_config/etc/ssh/sshd_config ファイルはデフォルト(記述しなファイルはデフォルト(記述しな
かった場合の動作)がかった場合の動作)が ## コメントとして書かれてコメントとして書かれて
います。これと異なる部分だけ記述してやればOいます。これと異なる部分だけ記述してやればO
Kです。Kです。
 補助教材を参考に実習してください。補助教材を参考に実習してください。
※※ なお、今回はCentOS自身のローカル接なお、今回はCentOS自身のローカル接
続をおこないます。時間が余った人続をおこないます。時間が余った人
は、は、 PoderosaPoderosa でのリモートログインもチャレでのリモートログインもチャレ
ンジしてみてください。ンジしてみてください。
Copyright 2004,2007 © Kensuke Nezu, All65
サーバー構築手順~サーバー構築手順~ sudosudo の利用の利用 (1)(1) ~~
sudoでsudoで rootroot になれるユーザを限定するになれるユーザを限定する
 歴史的理由により /etc/sudoers ファイルで wheel グループに属している
ユーザに root になれる権限を設定します
 root になってもよいユーザを vigr コマンドで wheel グループに登録しま
す
 登録されたユーザは、ユーザ毎のパスワードで root になれます
 sudo で指定したコマンドや権限のないユーザの sudo の試みは syslog に記
録されます
ローカルマシンの一般ユーザのローカルマシンの一般ユーザの rootroot 権限奪取の防止権限奪取の防止
コマンド毎やユーザをグル
ープ毎にして、細かく制御
も可能
コマンド毎やユーザをグル
ープ毎にして、細かく制御
も可能
Copyright 2004,2007 © Kensuke Nezu, All66
サーバー構築手順~サーバー構築手順~ sudosudo の利用の利用 (2)(2) ~~
root::0:rootroot::0:root
bin::1:root,daemon,majordomo,majbin::1:root,daemon,majordomo,maj
ordomoordomo
daemon::2:root,daemondaemon::2:root,daemon
sys::3:root,admsys::3:root,adm
adm::4:root,adm,daemonadm::4:root,adm,daemon
tty::5:tty::5:
disk::6:rootdisk::6:root
lp::7:daemon,lplp::7:daemon,lp
mem::8:mem::8:
kmem::9:kmem::9:
wheel::10:root,suzuki,tanaka,itowheel::10:root,suzuki,tanaka,ito
mail::12:mail,binmail::12:mail,bin
……
/etc/group
vigr で編集しないとシャ
ドウパスワードファイル
が更新されない
vigr で編集しないとシャ
ドウパスワードファイル
が更新されない
##
# This file MUST be edited with the 'visudo' command as# This file MUST be edited with the 'visudo' command as
root.root.
##
# See the sudoers man page for the details on how to write# See the sudoers man page for the details on how to write
a sudoers file.a sudoers file.
##
# Host alias specification# Host alias specification
# User alias specification# User alias specification
# Cmnd alias specification# Cmnd alias specification
# User privilege specification# User privilege specification
root ALL=(ALL) ALLroot ALL=(ALL) ALL
%wheel ALL (ALL) ALL%wheel ALL (ALL) ALL
/etc/sudoers
‘‘=’=’ がないがない
!!
visudo コマンドを使うと
こういった文法エラーを
チェックしてくれます
visudo コマンドを使うと
こういった文法エラーを
チェックしてくれます
Copyright 2004,2007 © Kensuke Nezu, All67
サーバー構築手順~サーバー構築手順~ sudosudo の応用例~の応用例~
## ホストエイリアスの指定ホストエイリアスの指定
Host_Alias DMZ = *.famm.ne.jp, aaa.bbb.ccc.ddd/255.255.255.240Host_Alias DMZ = *.famm.ne.jp, aaa.bbb.ccc.ddd/255.255.255.240
## ユーザ名エイリアスの指定ユーザ名エイリアスの指定
User_Alias OPERATOR = suzuki, hayashi, itohUser_Alias OPERATOR = suzuki, hayashi, itoh
## コマンドエイリアスの指定コマンドエイリアスの指定
Cmnd_Alias OPERATION = /etc/rc.d/init.d/* restart, /usr/sbin/useraddCmnd_Alias OPERATION = /etc/rc.d/init.d/* restart, /usr/sbin/useradd
## 特権ユーザの指定特権ユーザの指定
root ALL = (ALL) ALLroot ALL = (ALL) ALL
%wheel ALL = (ALL) ALL%wheel ALL = (ALL) ALL
# OPERATOR# OPERATOR に属する管理者はメインテナンス用にに属する管理者はメインテナンス用に OPERATIONOPERATION で定義したコマンドで定義したコマンド
だけ実行可能だけ実行可能
OPERATOR DMZ = (root) OPERATIONOPERATOR DMZ = (root) OPERATION
/etc/sudoers
ワイルドカード指定でワイルドカード指定で
きますきます
引数を指定するこ引数を指定するこ
ともできますともできます
実行コマンド例:
1. sudo –u root /etc/rc.d/init.d/httpd restart
2. sudo –u root /usr/sbin/useradd –m milky
実行コマンド例:
1. sudo –u root /etc/rc.d/init.d/httpd restart
2. sudo –u root /usr/sbin/useradd –m milky
セキュリティ的には・・・:
1. 応用例は、よりセキュア。
2. root だけでは、ちょっといまひとつ・・・
。
セキュリティ的には・・・:
1. 応用例は、よりセキュア。
2. root だけでは、ちょっといまひとつ・・・
。
Copyright 2004,2007 © Kensuke Nezu, All68
実習3:sudoを体感する(1実習3:sudoを体感する(1
0分)0分)
 前ページの設定を行い、実行例がきちんと前ページの設定を行い、実行例がきちんと
できることを確認してください。できることを確認してください。
 このとき、このとき、 syslogsyslog に出て来るメッセージも確認に出て来るメッセージも確認
します。します。
 実行権限のないユーザが実行しようとして実行権限のないユーザが実行しようとして
跳ねられることを確認してください。跳ねられることを確認してください。
 このとき、このとき、 syslogsyslog に出て来るメッセージも確認に出て来るメッセージも確認
します。します。
 次に、特定のユーザだけシステムのリブー次に、特定のユーザだけシステムのリブー
トを可能にする設定を考えてみてくださいトを可能にする設定を考えてみてください
。。
Copyright 2004,2007 © Kensuke Nezu, All69
サーバー構築手順~サーバー構築手順~ inetdinetd の設定の設定 (1)(1) ~~
inetdinetd 本体の設定 本体の設定  /etc/inetd.conf/etc/inetd.conf
 不必要なネットワークサービスは起動しない
 デーモンモードで常時起動するものも書かない
 TurboLinux では turboservice, RedHat Linux では ntsysv でも
設定可能
 最低必要なものは以下のようなものです
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a -d
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
Copyright 2004,2007 © Kensuke Nezu, All70
サーバー構築手順~サーバー構築手順~ inetdinetd の設定の設定 (2)(2) ~~
tcp_wrappertcp_wrapper の設定例  の設定例   /etc/hosts.allow/etc/hosts.allow
in.ftpd :211.9.xx.xxx
in.ftpd :61.9.xx.xxx/255.255.255.0
ipop2d,ipop3d,imapd,in.ftpd :.ykhm00.ap.so-net.ne.jp
ipop2d,ipop3d,imapd,in.ftpd :.iwate.ppp.infoweb.ne.jp
sshd : .samba.gr.jp
sshd : .jp
ALL : ALL : spawn (/usr/sbin/safe_finger –l @%h | /bin/mail –s %s-%h
alert ) & : deny
1度アクセスし
てもらいエラー
ログから判断す
る
1度アクセスし
てもらいエラー
ログから判断す
る
先方のログイン
ユーザを調べて
メール
先方のログイン
ユーザを調べて
メール
Copyright 2004,2007 © Kensuke Nezu, All71
サーバー構築手順~サーバー構築手順~ xinetdxinetd の設定の設定 (1)(1)
~~
chkconfigchkconfig による設定による設定
 起動するサービスとアクセス制限内容は inetd.conf +
tcp_wrapper とおなじ
 turboservice/ntsysv でも設定可能
 設定するコマンド
/sbin/chkconfig --level 345 ftp on
/sbin/chkconfig --level 345 pop3 on
/sbin/chkconfig --level 345 pop2 on
/sbin/chkconfig --level 345 imap on
 chkconfig --list で必要なサービスのみ上っていることを確認
Copyright 2004,2007 © Kensuke Nezu, All72
サーバー構築手順~サーバー構築手順~ xinetdxinetd の設定の設定 (2)(2)
~~
サービス毎のアクセス制限 サービス毎のアクセス制限  /etc/xinetd.d/ftp/etc/xinetd.d/ftp のの
例例
 only_from = パラメータで指定する
service ftp {
disable = no
only_from = 211.9.xx.xxx
only_from = 61.9.xx.xxx/255.255.255.yyy
only_from = 210.9.xx.0
only_from = .iwate.ppp.infoweb.ne.jp
…..
log_on_failure += USERID
}
Copyright 2004,2007 © Kensuke Nezu, All73
サーバー構築手順~起動サービスの設定サーバー構築手順~起動サービスの設定 (1)(1)
~~
ntsysv/turboservicentsysv/turboservice による設定による設定
 redhat-config-services/system-config-services は RedHat
系、 turboservice は TurboLinux
Copyright 2004,2007 © Kensuke Nezu, All74
サーバー構築手順~起動サービスの設定サーバー構築手順~起動サービスの設定 (2)(2)
~~
自動起動させるサービスの例自動起動させるサービスの例
 apmd/acpidapmd/acpid
 atd/crond/anacronatd/crond/anacron
 random/httpd(Webrandom/httpd(Web サービスをするならサービスをするなら ))
 inet/network/inetd/xinetd
 ipchains(2.2 系 )/iptables(2.4 系 )
 iplog/syslog
 keytable
 irqbalance
 rawdevices
 kudzu/readahead/readahead_early/rhnsd/yum
(RedHat Linux 等 )
 named(DNS を動かすなら)
 portmapportmap
 sendmailsendmail(MTA(MTA にに sendmailsendmail を使うならを使うなら ))
 snmpd(mrtgsnmpd(mrtg 等を使うなら等を使うなら ))
 sshd
 smartd
 xntpd(ntpd を使うなら )
Copyright 2004,2007 © Kensuke Nezu, All75
サーバー構築手順~サーバー構築手順~ DNS(1)DNS(1) ~~
ネームサーバーの設定ネームサーバーの設定
 セカンダリネームサーバ以外には情報の転送を不許可にするセカンダリネームサーバ以外には情報の転送を不許可にする
 /etc/named.conf/etc/named.conf で、で、
allow-transfer { IPallow-transfer { IP アドレスアドレス 1 ; //1 ; // 転送を許可するセカンダリネームサーバ転送を許可するセカンダリネームサーバ 11
IPIP アドレスアドレス 2 ; // // 22 ; // // 2
…… };};
 バージョンチェックできないようにするバージョンチェックできないようにする (( バグバージョンを探す攻バグバージョンを探す攻
撃防止撃防止 ))
 /etc/named.conf/etc/named.conf で、で、
zone bind” chaos { allow-query { localhost; }; // localhost“zone bind” chaos { allow-query { localhost; }; // localhost“ からしか許さないからしか許さない
type master;type master;
file bind”;“file bind”;“
};};
Bind 9.x では不必要
!
Bind 9.x では不必要
!
Copyright 2004,2007 © Kensuke Nezu, All76
サーバー構築手順~サーバー構築手順~ DNS(2)DNS(2) ~~
ネームサーバーの設定ネームサーバーの設定 (( つづき)つづき)
 /var/named/bind (/var/named/bind ( 標準)で、標準)で、
$origin bind.$origin bind.
@ 1d chaos soa localhost. root.localhost. (@ 1d chaos soa localhost. root.localhost. (
1 ; serial1 ; serial
3H ; refresh3H ; refresh
1H ; retry1H ; retry
1W ; expiry1W ; expiry
1D ) ; minimum1D ) ; minimum
chaos ns localhost.chaos ns localhost.
chaos A 127.0.0.1chaos A 127.0.0.1
[ チェック方法 ]
$nslookup –class=chaos –query=txt localhost
version.bind( 実際は1行 )
Server: localhost
Address: 127.0.0.1
VERSION.BIND text = 8.2.3-REL”“
Copyright 2004,2007 © Kensuke Nezu, All77
実習4:実習4: CentOSCentOS でのでの version.bindversion.bind の有効の有効
性を調べてください性を調べてください (( 5分5分 ))
 前ページのような前ページのような chaoschaos クラスを利用した脆クラスを利用した脆
弱性の発見方法がCentOSで有効かど弱性の発見方法がCentOSで有効かど
うかを調べてください。うかを調べてください。
Copyright 2004,2007 © Kensuke Nezu, All78
サーバー構築手順~メールサーサーバー構築手順~メールサー
バ~バ~
オープンリレー(オープンリレー( OpenRelay)OpenRelay) しないようしないよう
に注意に注意
 Sendmail 8Sendmail 8 系以降、系以降、 qmailqmail 、、 postfixpostfix ではリレーしないではリレーしない
のが基本のが基本
-しかし、設定を誤るとオープンリレーになってしまう-しかし、設定を誤るとオープンリレーになってしまう
。。
 2004/072004/07 で2台のサーバーで観測すると、オープで2台のサーバーで観測すると、オープ
ンリレーチェックのメールサーバーアクセスがンリレーチェックのメールサーバーアクセスが
5757 回回 /109/109 回回
 telnettelnet でも手軽にチェックできるので、設定を変でも手軽にチェックできるので、設定を変
更するたびにチェックしよう更するたびにチェックしよう

Copyright 2004,2007 © Kensuke Nezu, All79
サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (1)(1)
~~
FTPFTP サービスとサービスと WebDAVWebDAV
 よりセキュアなのはよりセキュアなのは WebDAVWebDAV
 FTPFTP ではシステムにアカウントが必要、ではシステムにアカウントが必要、 WebDAVWebDAV は不要は不要
 システム中のアクセスできるファイルエリアを制御しやすいのはシステム中のアクセスできるファイルエリアを制御しやすいのは
WebDAVWebDAV 。。 FTP(wuFTPD, proftpdFTP(wuFTPD, proftpd 等)ではユーザ毎の等)ではユーザ毎の chrootchroot 環境が必要で、これを環境が必要で、これを
構築、維持、運用構築、維持、運用 (( ユーザの追加など)するのは結構たいへんユーザの追加など)するのは結構たいへん
 FTPFTP では認証に生パスワードが流れる。では認証に生パスワードが流れる。 WebDAVWebDAV はは BASICBASIC 認証でなく、認証でなく、 digestdigest
認証ならばパスワードは暗号化される認証ならばパスワードは暗号化される
 WebDAVWebDAV は接続がは接続が [[ クライアントクライアント ] [→] [→ サーバー:サーバー: 80/TCP]80/TCP] に固定。に固定。 FTPFTP はモーはモー
ドによってドによって [[ クライアントクライアント ] [←→] [←→ サーバサーバ ]] どちらの接続もありえるし、使用どちらの接続もありえるし、使用
ポートも流動的ポートも流動的
FTP はパケットフィ
ルタリングしにくい
FTP はパケットフィ
ルタリングしにくい
WindowsWindows のの WEBWEB フォフォ
ルダ機能を実現するルダ機能を実現する
ApacheApache のモジュールのモジュール
Copyright 2004,2007 © Kensuke Nezu, All80
サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (2)(2)
~~
サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (2)(2)
~~
FTPFTP サービスサービス (( 通常モード)通常モード)
[ 制御コネクション ]Ftp クライアント (1024
)
Ftp サーバ (21)
PORT 192,168,1,1,4,0
OK
[ データコネクション ]Ftp クライアント (1024
)
Ftp サーバ (20)
GET のデータ転送
4,0 は、 0x04,
0x00
で、 0x0400 、つ
まり 1024 を示す
。
4,0 は、 0x04,
0x00
で、 0x0400 、つ
まり 1024 を示す
。
接続の向き 20/TCP1024/TCP
接続の向き
とポート番
号が問題
Copyright 2004,2007 © Kensuke Nezu, All81
サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (3)(3)
~~
FTPFTP サービスサービス (PASV(PASV モード)モード)
[ 制御コネクション ]Ftp クライアント (3000
)
Ftp サーバ (21)
PASV
OK(211,9,36,180,4,255)
[ データコネクション ]Ftp クライアント (3001
)
Ftp サーバ (1279)
GET のデータ転送
4,0 は、 0x04,
0xff で、 0x04ff 、
つまり 1279 を示
す。
4,0 は、 0x04,
0xff で、 0x04ff 、
つまり 1279 を示
す。
接続の向き 1279/TCP3001/TCP
接続の向き
とポート番
号が問題
Copyright 2004,2007 © Kensuke Nezu, All82
サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (4)(4)
~~
WebDAVWebDAV の欠点もあるの欠点もある
 あまり多くの日本語情報がないあまり多くの日本語情報がない
 ApacheApache ではでは 2.02.0 系でないと標準モジュールでない系でないと標準モジュールでない
 日本語を上手に使おうとすると非標準モジュール日本語を上手に使おうとすると非標準モジュール (mod_encoding)(mod_encoding) が必が必
要要
 非標準モジュールがソースでしか配布されていない非標準モジュールがソースでしか配布されていない (RPM/de(RPM/de bがなbがな
い)い)
 クライアントによって挙動が違うことがあるクライアントによって挙動が違うことがある (Windows XP(Windows XP など)など)
acheのacheの V.upV.up でバイナリが非互換になるとちょっと悲しいことにでバイナリが非互換になるとちょっと悲しいことに
Apache のセキュリテ
ィホール対策版の
1.3.26 など・・・
Apache のセキュリテ
ィホール対策版の
1.3.26 など・・・
Copyright 2004,2007 © Kensuke Nezu, All83
実習5:実習5: WebDAVWebDAV 環境を構築する(環境を構築する( 2020
分)分)
 DAVDAV の設定を行ってください。ユーザ認証の設定を行ってください。ユーザ認証
はは BASICBASIC 認証で設定してください。認証で設定してください。
 WindowsWindows のウェブブラウザから、のウェブブラウザから、 WebDAVWebDAV にに
アクセスしてファイルが置けることを確認アクセスしてファイルが置けることを確認
してください。してください。
 詳細は、補助資料を参考にしてください。詳細は、補助資料を参考にしてください。
Copyright 2004,2007 © Kensuke Nezu, All84
サーバー構築手順~サーバー構築手順~ WWWWWW サービサービ
ス~ス~
Apache設定のポイントApache設定のポイント (1)(1)
 ApacheApache のバージョンを表示しないのバージョンを表示しない (httpd.conf)(httpd.conf)
ServerSignatureServerSignature OffOff
→→Apache 1.3Apache 1.3 以降。サーバが生成する以降。サーバが生成する (( エラーなどのエラーなどの )) ドキュメントドキュメント
にバージョン等の付加情報をつけないにバージョン等の付加情報をつけない
ServerTokensServerTokens              ProductOnlyProductOnly
→→Apache 1.3.12Apache 1.3.12 以降。サーバレスポンスヘッダにバージョンや以降。サーバレスポンスヘッダにバージョンや
プリコンパイルモジュールの情報を含めないプリコンパイルモジュールの情報を含めない
Apache のセキュリテ
ィホール対策版の
1.3.26 以前のセキュリ
ティホールをつくワー
ムが近いうちにきっと
でてきます。
Apache のセキュリテ
ィホール対策版の
1.3.26 以前のセキュリ
ティホールをつくワー
ムが近いうちにきっと
でてきます。
Nimdaタイプの IP
アドレス総なめタイプ
かもしれませんが、バ
ージョンをチェックす
るタイプであればこの
防御は有効です。
Nimdaタイプの IP
アドレス総なめタイプ
かもしれませんが、バ
ージョンをチェックす
るタイプであればこの
防御は有効です。
設定していないと・・・:
HTTP/1.1 200 OK
Date: Thu, 27 Jun 2002 07:54:50 GMT
Server: Apache/1.3.23 (TurboLinux) mod_throttle/3.1.2 PHP/4.1.2
Connection: close
設定してあると・・・:
HTTP/1.1 200 OK
Date: Thu, 27 Jun 2002 07:54:50 GMT
Server: Apache
Connection: close
FreeBSDFreeBSD 版の版の
ワームはでてワームはでて
きてしまいまきてしまいま
したした
Slapper ワームがこの
機能を利用しています
Slapper ワームがこの
機能を利用しています
Copyright 2004,2007 © Kensuke Nezu, All85
実習6:実習6: apacheapache のセキュリティを設定のセキュリティを設定
してみる(してみる( 1010 分)分)
 /etc/httpd/conf/httpd.conf/etc/httpd/conf/httpd.conf で、で、
ServerSignature On/Off/EmailServerSignature On/Off/Email
ServerTokensServerTokens
ProductOnly/Major/Minor/Minimal/OS/FullProductOnly/Major/Minor/Minimal/OS/Full
と切り替えたときのレスポンスヘッダの違いを確と切り替えたときのレスポンスヘッダの違いを確
認してく認してく
ださい。ださい。→変更したら、必ず再起動→変更したら、必ず再起動 (service httpd(service httpd
restart )restart )  します。 します。
 CentOSのデフォルトは、CentOSのデフォルトは、 ServerServer
Tokens OS / ServerSignature OnTokens OS / ServerSignature On です。です。
 確認方法は、端末窓から、確認方法は、端末窓から、
$ telnet localhost 80$ telnet localhost 80
適当な文字+リターン適当な文字+リターン
Copyright 2004,2007 © Kensuke Nezu, All86
サーバー構築手順~サーバー構築手順~ WWWWWW サービサービ
ス~ス~
Apache設定のポイントApache設定のポイント (2)(2)
 BASICBASIC 認証を使わずにダイジェスト認証を使う認証を使わずにダイジェスト認証を使う
 BASICBASIC 認証ではパスワードは認証ではパスワードは mimemime エンコードされているだけの状態でネッエンコードされているだけの状態でネッ
トワークを流れているトワークを流れている
 盗聴盗聴 (Sniffer)(Sniffer) して簡単に生のパスワードが得られますして簡単に生のパスワードが得られます
 ダイジェスト認証は、ダイジェスト認証は、 MD5MD5 でハッシュ化されているのでほぼ安全でハッシュ化されているのでほぼ安全
 Apache 1.xApache 1.x の標準モジュールでないの標準モジュールでない (experimental(experimental のの )mod_auth_digest)mod_auth_digest モジュールでサモジュールでサ
ポートされているので手でコンパイルしてインストールしなければいけないポートされているので手でコンパイルしてインストールしなければいけない
→→ Apache 2.xApache 2.x では標準モジュールになっていますでは標準モジュールになっています
電子メールの添付ファイ電子メールの添付ファイ
ルの形式ルの形式
BASICBASIC 認証(認証( ApacheApache の標準パスワード形式)はセキュリティがないのと同の標準パスワード形式)はセキュリティがないのと同
Copyright 2004,2007 © Kensuke Nezu, All87
サーバー構築手順~サーバー構築手順~ WWWWWW サービサービ
ス~ス~
Apache設定のポイントApache設定のポイント (3)(3)
 mod_auth_digestmod_auth_digest モジュールのインストール方法モジュールのインストール方法
1.1. ソースコードを取得、展開するソースコードを取得、展開する
2.2. cd apache_1.3.26/src/modules/experimentalcd apache_1.3.26/src/modules/experimental
3.3. /usr/bin/apxs –D DEV_RANDOM –c mod_auth_digest.c/usr/bin/apxs –D DEV_RANDOM –c mod_auth_digest.c でコンパイルでコンパイル
4.4. rootroot で、で、 /usr/bin/apxs –i mod_auth_digest.so/usr/bin/apxs –i mod_auth_digest.so でインストールでインストール
5.5. httpd.confhttpd.conf で、以下を追加するで、以下を追加する
     LoadModule digest_auth_module /usr/libexec/apache/mod_auth_digest.soLoadModule digest_auth_module /usr/libexec/apache/mod_auth_digest.so
     AddModule mod_auth_digest.cAddModule mod_auth_digest.c
6.6. パスワードの作成はパスワードの作成は htdigesthtdigest コマンドを使うコマンドを使う
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)
セキュアなサーバを構築しよう(CentOS 5.xまで対応)

More Related Content

Viewers also liked

Fluentd+elasticsearch+kibana(fluentd編)
Fluentd+elasticsearch+kibana(fluentd編)Fluentd+elasticsearch+kibana(fluentd編)
Fluentd+elasticsearch+kibana(fluentd編)Daisuke Kikuchi
 
それFluentdで! #fluentd
それFluentdで!  #fluentdそれFluentdで!  #fluentd
それFluentdで! #fluentdAtsuko Shibuya
 
「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』cotonas_en
 
fluentd を利用した大規模ウェブサービスのロギング
fluentd を利用した大規模ウェブサービスのロギングfluentd を利用した大規模ウェブサービスのロギング
fluentd を利用した大規模ウェブサービスのロギングYuichi Tateno
 
Qpstudy201404 インフラ設計の勘所
Qpstudy201404 インフラ設計の勘所Qpstudy201404 インフラ設計の勘所
Qpstudy201404 インフラ設計の勘所Seiichiro Ishida
 

Viewers also liked (6)

Fluentd+elasticsearch+kibana(fluentd編)
Fluentd+elasticsearch+kibana(fluentd編)Fluentd+elasticsearch+kibana(fluentd編)
Fluentd+elasticsearch+kibana(fluentd編)
 
ネットワーク構築訓練 入門
ネットワーク構築訓練 入門ネットワーク構築訓練 入門
ネットワーク構築訓練 入門
 
それFluentdで! #fluentd
それFluentdで!  #fluentdそれFluentdで!  #fluentd
それFluentdで! #fluentd
 
「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』「コトナス」:出会わなくても良いアプリ『Match★Contact』
「コトナス」:出会わなくても良いアプリ『Match★Contact』
 
fluentd を利用した大規模ウェブサービスのロギング
fluentd を利用した大規模ウェブサービスのロギングfluentd を利用した大規模ウェブサービスのロギング
fluentd を利用した大規模ウェブサービスのロギング
 
Qpstudy201404 インフラ設計の勘所
Qpstudy201404 インフラ設計の勘所Qpstudy201404 インフラ設計の勘所
Qpstudy201404 インフラ設計の勘所
 

Similar to セキュアなサーバを構築しよう(CentOS 5.xまで対応)

Dev sumi 14-e-1-クラウドセキュリティ
Dev sumi 14-e-1-クラウドセキュリティDev sumi 14-e-1-クラウドセキュリティ
Dev sumi 14-e-1-クラウドセキュリティShoji Kawano
 
NAIST ソフトウェア工学研究室紹介 2017
NAIST ソフトウェア工学研究室紹介 2017NAIST ソフトウェア工学研究室紹介 2017
NAIST ソフトウェア工学研究室紹介 2017Takashi Ishio
 
【Securify】Partner program.pdf
【Securify】Partner program.pdf【Securify】Partner program.pdf
【Securify】Partner program.pdfmihokawagoe
 
【Explanatory material】Securify_v1.2.pptx
【Explanatory material】Securify_v1.2.pptx【Explanatory material】Securify_v1.2.pptx
【Explanatory material】Securify_v1.2.pptxmihokawagoe
 
できることから始めるセキュリティ対策
できることから始めるセキュリティ対策できることから始めるセキュリティ対策
できることから始めるセキュリティ対策NHN テコラス株式会社
 
標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝
標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝
標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝Fumitaka Takeuchi
 
金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」
金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」
金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」Tomohisa Ishikawa, CISSP, CSSLP, CISA, CISM, CFE
 
天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501
天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501
天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501Sen Ueno
 
Yamakawa@shirahama v4.0 20120517
Yamakawa@shirahama v4.0 20120517Yamakawa@shirahama v4.0 20120517
Yamakawa@shirahama v4.0 20120517Tomohiko Yamakawa
 
良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント
良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント
良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイントNaoki Ohsugi
 
なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~
なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~
なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~Tomohiro Nakashima
 
セキュキャンのススメ
セキュキャンのススメセキュキャンのススメ
セキュキャンのススメshutingrz
 
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 apkiban
 
06.超初心者向けセキュリティ入門(.netの解析と対策)
06.超初心者向けセキュリティ入門(.netの解析と対策)06.超初心者向けセキュリティ入門(.netの解析と対策)
06.超初心者向けセキュリティ入門(.netの解析と対策)Study Group by SciencePark Corp.
 
【ITソリューション塾・特別講義】Security Fundamentals/2017.5
【ITソリューション塾・特別講義】Security Fundamentals/2017.5【ITソリューション塾・特別講義】Security Fundamentals/2017.5
【ITソリューション塾・特別講義】Security Fundamentals/2017.5Masanori Saito
 

Similar to セキュアなサーバを構築しよう(CentOS 5.xまで対応) (20)

Dev sumi 14-e-1-クラウドセキュリティ
Dev sumi 14-e-1-クラウドセキュリティDev sumi 14-e-1-クラウドセキュリティ
Dev sumi 14-e-1-クラウドセキュリティ
 
NAIST ソフトウェア工学研究室紹介 2017
NAIST ソフトウェア工学研究室紹介 2017NAIST ソフトウェア工学研究室紹介 2017
NAIST ソフトウェア工学研究室紹介 2017
 
【Securify】Partner program.pdf
【Securify】Partner program.pdf【Securify】Partner program.pdf
【Securify】Partner program.pdf
 
【Explanatory material】Securify_v1.2.pptx
【Explanatory material】Securify_v1.2.pptx【Explanatory material】Securify_v1.2.pptx
【Explanatory material】Securify_v1.2.pptx
 
できることから始めるセキュリティ対策
できることから始めるセキュリティ対策できることから始めるセキュリティ対策
できることから始めるセキュリティ対策
 
標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝
標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝
標的型攻撃にいかに立ち向かうか~巧妙化する脅威に組織がとるべき対策とは~竹内 文孝
 
金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」
金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」
金融ISAC アニュアルカンファレンス 2020:Intelligence Driven Securityの「ことはじめ」
 
なぜ今、セキュリティ人材の育成が叫ばれているのか
なぜ今、セキュリティ人材の育成が叫ばれているのかなぜ今、セキュリティ人材の育成が叫ばれているのか
なぜ今、セキュリティ人材の育成が叫ばれているのか
 
情報セキュリティとの正しい付き合い方
情報セキュリティとの正しい付き合い方情報セキュリティとの正しい付き合い方
情報セキュリティとの正しい付き合い方
 
CND(認定ネットワークディフェンダー / Certified Network Defender)公式トレーニングのご紹介
CND(認定ネットワークディフェンダー / Certified Network Defender)公式トレーニングのご紹介CND(認定ネットワークディフェンダー / Certified Network Defender)公式トレーニングのご紹介
CND(認定ネットワークディフェンダー / Certified Network Defender)公式トレーニングのご紹介
 
【セミナー講演資料】CND(認定ネットワークディフェンダー)公式トレーニング紹介
【セミナー講演資料】CND(認定ネットワークディフェンダー)公式トレーニング紹介【セミナー講演資料】CND(認定ネットワークディフェンダー)公式トレーニング紹介
【セミナー講演資料】CND(認定ネットワークディフェンダー)公式トレーニング紹介
 
Certified network defender
Certified network defenderCertified network defender
Certified network defender
 
天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501
天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501
天職の就き方 〜 ぼくらが旅に出る理由 Part 2 #ssmjp 1501
 
Yamakawa@shirahama v4.0 20120517
Yamakawa@shirahama v4.0 20120517Yamakawa@shirahama v4.0 20120517
Yamakawa@shirahama v4.0 20120517
 
良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント
良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント
良い原稿を作る3つの要素、読み易い文章を作る5つのコツ、SQiPシンポジウムアブストラクト作成のポイント
 
なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~
なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~
なぜ私たちはシステムを侵害から守れないのか?~広く知って欲しい不都合なこと~
 
セキュキャンのススメ
セキュキャンのススメセキュキャンのススメ
セキュキャンのススメ
 
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」
 
06.超初心者向けセキュリティ入門(.netの解析と対策)
06.超初心者向けセキュリティ入門(.netの解析と対策)06.超初心者向けセキュリティ入門(.netの解析と対策)
06.超初心者向けセキュリティ入門(.netの解析と対策)
 
【ITソリューション塾・特別講義】Security Fundamentals/2017.5
【ITソリューション塾・特別講義】Security Fundamentals/2017.5【ITソリューション塾・特別講義】Security Fundamentals/2017.5
【ITソリューション塾・特別講義】Security Fundamentals/2017.5
 

セキュアなサーバを構築しよう(CentOS 5.xまで対応)

  • 1. Copyright 2004,2007 © Kensuke Nezu, All rights Reserved. 1 文部科学省文部科学省 中央大学研究開発機構中央大学研究開発機構 UNIXセキュリティ実践講UNIXセキュリティ実践講 座座 ~Secure Serve~Secure Serve r Day~r Day~ Microsoft MVP – Windows SecurityMicrosoft MVP – Windows Security NPONPO 日本ネットワークセキュリティ協日本ネットワークセキュリティ協 会会 NTTデータ先端技術株式会社NTTデータ先端技術株式会社 根津 研介根津 研介
  • 2. Copyright 2004,2007 © Kensuke Nezu, All2 本資料の取扱について本資料の取扱について  本資料は、文部科学省科学技術振興調整費 中央大学研究開発機構 「情報セキュリ ティ・情報保証 人材育成拠点」人材養成計画に基づ き、中央大学 研究開発機構  「情報セキュリティ教育システムの 開発」ユニットが実施する「 Unix セキュリティ実践講座」の教材 として使用するために提供するものです。  本資料を上記「本資料を上記「 UnixUnix セキュリティ実践講座」の使用目的以外に利用セキュリティ実践講座」の使用目的以外に利用 (転載、転用、商業活動への使用など)することを禁止します。ただ(転載、転用、商業活動への使用など)することを禁止します。ただ し、例外として、学校内、サークル内、企業内などでサーバ導入の際し、例外として、学校内、サークル内、企業内などでサーバ導入の際 の参考資料として内部的に複写したり、活用することは許可します。の参考資料として内部的に複写したり、活用することは許可します。 この場合でも、教育そのものを事業目的とする場合は例外条件としてこの場合でも、教育そのものを事業目的とする場合は例外条件として 認められないので注意してください。認められないので注意してください。  本資料の扱いに関して不明点等ある場合には、 中央大学 研究開発本資料の扱いに関して不明点等ある場合には、 中央大学 研究開発 機構 「情報セキュリティ教育システムの開発」ユニットまでお問い機構 「情報セキュリティ教育システムの開発」ユニットまでお問い 合わせください。合わせください。
  • 3. Copyright 2004,2007 © Kensuke Nezu, All3 セキュリティ概論セキュリティ概論
  • 4. Copyright 2004,2007 © Kensuke Nezu, All4 セキュリティの必要性セキュリティの必要性  インターネットの長所インターネットの長所  世界中から自由にアクセスできる世界中から自由にアクセスできる  世界中に自由に公開できる世界中に自由に公開できる  手軽な値段で誰でも利用できる手軽な値段で誰でも利用できる  インターネットの短所インターネットの短所  法的な保護が及びにくい法的な保護が及びにくい   ~自分の身は自分で守るという姿勢が必要~  ~自分の身は自分で守るという姿勢が必要~  全体を制御する「しくみ」とか「規制」がない全体を制御する「しくみ」とか「規制」がない  他者への犯罪の幇助をしてしまうことも!他者への犯罪の幇助をしてしまうことも!SPAM メールの送信元になっ たり、攻撃元を詐称するため の踏み台にされたり・・・ SPAM メールの送信元になっ たり、攻撃元を詐称するため の踏み台にされたり・・・
  • 5. Copyright 2004,2007 © Kensuke Nezu, All5 セキュリティ=国家の安全保障にもセキュリティ=国家の安全保障にも 気を配らなければなりません気を配らなければなりません
  • 6. Copyright 2004,2007 © Kensuke Nezu, All6 サーバを法律が守ってくれる?サーバを法律が守ってくれる?  場合によっては、守ってくれる程度場合によっては、守ってくれる程度  日本と捜査協力や犯人引渡協定のない国、日本と捜査協力や犯人引渡協定のない国、国交の無い国国交の無い国 では日本国の法律は無力です。では日本国の法律は無力です。 -- 不正アクセスを国交の無い国から受けたので捜査して欲しい不正アクセスを国交の無い国から受けたので捜査して欲しい etc..etc..  行為者が国内にいる日本人であれば、他の国のサーバをい行為者が国内にいる日本人であれば、他の国のサーバをい くつ経由しても日本の法律で裁くことができます。くつ経由しても日本の法律で裁くことができます。  刑法第一条~第五条参照(刑法第一条~第五条参照( http://www.ron.gr.jp/law/law/keihou.htmhttp://www.ron.gr.jp/law/law/keihou.htm ))  刑事でなければなりません。民事の損害賠償などは刑事でなければなりません。民事の損害賠償などは 、まず、成り立ちません。(損害額の算定が微少な、まず、成り立ちません。(損害額の算定が微少な ため)ため)  国際私法国際私法 (( ベルヌ条約、サイバー犯罪防止条約等)ベルヌ条約、サイバー犯罪防止条約等) と各国に於ける法整備、法解釈の違いも問題になりと各国に於ける法整備、法解釈の違いも問題になり
  • 7. Copyright 2004,2007 © Kensuke Nezu, All7 TPOTPO に合わせたセキュリティに合わせたセキュリティ コンビニのセキュリティ 1. 店舗スペースは「公開」で不特定多 数のアクセスを許す 2. 店舗内トイレは「店員に一声かけ て」利用する 3. レジ裏の事務所は非公開 4. 事務所にはビデオ録画システムを設 置し,防犯の目的や犯罪発生時の保 全措置に利用 公開サーバの最低限のセキュリテ ィ 1. 公開する範囲を正しく判断し正しく 公開する 2. 公開する範囲を「正しい相手」に公 開する 3. 公開すべきでない(するつもりがな い)部分を公開しない / させない 4. 必要な部分では「監視するしくみ」 を作りこむ セキュリティ構築の5セキュリティ構築の5 W1HW1H をを はっきりさせよう!はっきりさせよう!
  • 8. Copyright 2004,2007 © Kensuke Nezu, All8 セキュアサーバ構築のコストセキュアサーバ構築のコスト (1)(1) 自分だけで構築・運用可能か判断す自分だけで構築・運用可能か判断す るる  「10:90の法則」が基準:「10:90の法則」が基準: 10%10% の工数での工数で 90%90% の効果の効果  UNIXUNIX 開発の設計思想~もっともバランスがよい~開発の設計思想~もっともバランスがよい~  セキュリティにセキュリティに 100%100% はない~どこかで見切りが必はない~どこかで見切りが必 要~要~ →→ 90% 91%→90% 91%→ にするにはにするには 20%20% の労力が必要の労力が必要 →→ 98% 99%→98% 99%→ にはには 100%100% の労力が必要の労力が必要  サーバーやサービス毎に必要な効果を考えよう!サーバーやサービス毎に必要な効果を考えよう! → 90% までなら技術さえあれば自分で構築可能
  • 9. Copyright 2004,2007 © Kensuke Nezu, All9 セキュアサーバ構築のコストセキュアサーバ構築のコスト (2)(2) サーバーの価値を計算するサーバーの価値を計算する  不正利用者の立場からみたサーバー不正利用者の立場からみたサーバー の価値の価値  システムに含まれるデータの価値システムに含まれるデータの価値  機密情報があるか?など     機密情報があるか?など            → 転売の価値や改竄      → 転売の価値や改竄 、脅迫等、脅迫等  踏み台にするサーバーとしての価踏み台にするサーバーとしての価 値値  上位プロバイダとの回線速度など上位プロバイダとの回線速度など  その他の価値その他の価値  怨恨、意趣晴らし、愉快犯など怨恨、意趣晴らし、愉快犯など 機密情報機密情報 なしなし 顧客のデータ顧客のデータ なしなし 回線速度回線速度 <1Mbit<1Mbit 程度?程度? 怨恨関係怨恨関係 ???(???( 多分なし多分なし )) 総合総合 1515 点程度?点程度? 計算例 これらを総合的に判断して、 必要となるセキュリティレベ ルを考える
  • 10. Copyright 2004,2007 © Kensuke Nezu, All10 0 20 40 60 80 100 構築 セ キ ュリティ対策 日常監視 金銭的費用 工数 緊急性 サーバのライフサイクルと「コサーバのライフサイクルと「コ スト」スト」 構築のコスト(金銭的コ スト)だけに注意が向い て、運用のコストが考え られていないことが多い 構築のコスト(金銭的コ スト)だけに注意が向い て、運用のコストが考え られていないことが多い 運用に必要な「目 に見えないコス ト」の方が実はト ータルすると重要 ! 運用に必要な「目 に見えないコス ト」の方が実はト ータルすると重要 ! 緊急性の高い作業は 、夜中や休日に集中 緊急性の高い作業は 、夜中や休日に集中 いかにいかに管理の手間管理の手間を下げるかがカギ!を下げるかがカギ!
  • 11. Copyright 2004,2007 © Kensuke Nezu, All11 サーバー=サービスを提供するシサーバー=サービスを提供するシ ステムステム サービスの品質をはかる基準サービスの品質をはかる基準  RAS(RAS( 大型コンピュータ大型コンピュータ // エンタープライズサーエンタープライズサー バの世界の用語バの世界の用語 ))  ReliabilityReliability :信頼性 - 「いつで:信頼性 - 「いつで も安定したサービス」も安定したサービス」  AvailabilityAvailability :可用性 - 「24時間、:可用性 - 「24時間、 365365 日稼日稼 働」働」  ServiceService abilityability :保守性 -「誰でもどこ:保守性 -「誰でもどこ でも簡単に」でも簡単に」  MTBFMTBF とと MTTRMTTR  MTBF:できるだけサービスを落とさないMTBF:できるだけサービスを落とさない
  • 12. Copyright 2004,2007 © Kensuke Nezu, All12 サーバー=サービスを提供するシサーバー=サービスを提供するシ ステムステム セキュリティの品質をはかる基準セキュリティの品質をはかる基準  国際規格国際規格 ISO/IEC17799ISO/IEC17799 による定義(による定義( CIA)CIA) を購入前のを購入前の マヨネーズで例えると・・・マヨネーズで例えると・・・  ConfidencialityConfidenciality :機密性 -チューブに穴は空いていませ:機密性 -チューブに穴は空いていませ んか?んか?  IntegrityIntegrity :完全性 -口のシールが貼り直されてい:完全性 -口のシールが貼り直されてい ませんか?ませんか?  AvailabilityAvailability :可用性 -売り切れていませんか?:可用性 -売り切れていませんか?
  • 13. Copyright 2004,2007 © Kensuke Nezu, All13 サーバという「サービスの品サーバという「サービスの品 質」質」 サーバが目標とする品質とセキュリサーバが目標とする品質とセキュリ ティティ 品質の目標品質の目標 1. いつでも安定していて、 2. いつでも利用することができて、 3. 「正しい中身」が「正しい人」に 伝わり、 4. 保守作業が簡単なシステム。 セキュリティはこの目標を達成し、セキュリティはこの目標を達成し、 維持し続けるための手段の1つにすぎない維持し続けるための手段の1つにすぎない
  • 14. Copyright 2004,2007 © Kensuke Nezu, All14 サーバという「サービスの品サーバという「サービスの品 質」質」 サービスの維持管理とセキュリティサービスの維持管理とセキュリティ 「セキュリティ」の意味「セキュリティ」の意味 1. 安全、安全保障、安全確保、保障 。 2. 戸締まり、防衛手段、警備、防護 、保全、保安。 3. 無事、治安、安心。 日常の保守作業はすべて「セキュリティ」日常の保守作業はすべて「セキュリティ」 という大きなフレームワークの一部!という大きなフレームワークの一部! 保障:生命、財産、権 利などを保護して守る こと 保障:生命、財産、権 利などを保護して守る こと
  • 15. Copyright 2004,2007 © Kensuke Nezu, All15 サーバという「サービスの品サーバという「サービスの品 質」質」 メインテナンスも立派なセキュリテメインテナンスも立派なセキュリテ ィィ •システムの定期的なバックアップ •システムログのチェック •不正利用、サービス不能、サービス停止の 防止 •システム侵入の防止、検出 •セキュリティインベントリ(ソフトウェア のセキュリティホール発覚など)の監視 •速やかなサービス不能状態の検出、回復 •自動監視、自動警報発報、自動アップデー ト RAS の向上 MTBF をより 長く MTTR を最小 に
  • 16. Copyright 2004,2007 © Kensuke Nezu, All16 通常監視と情報収集通常監視と情報収集 通常監視 1. サービス可否のチェック 2. マシンのチェック 3. ネットワーク品質のチェック 4. システム負荷のチェック 5. 利用状況のチェック 6. 異常状態の検出 7. システム統計情報の監視 情報収集 1. (Push 型 )CERT/CC, JPCERT/CC, 各 種メールニュースなどの利用 2. (Push 型 ) セキュリティ関連メーリ ングリストによる情報収集 3. (Pull 型 ) セキュリティ関連ホームペ ージの利用 4. (Push 型 ) 利用ディストリビューシ ョンのユーザメーリングリストの利 用 自動化に向いている自動化に向いている 自動化に向いていない自動化に向いていない
  • 17. Copyright 2004,2007 © Kensuke Nezu, All17 予防保守と緊急対応予防保守と緊急対応 緊急対応 1. 緊急事態の発生時の対応体制、対応 マニュアル/メモの作成と実行 2. 異常状態検出時の対応体制、対応マ ニュアル/メモの作成と実行 3. 問いあわせ発生時( Web サイト脆 弱性、 SPAM メール送信、踏み台に よる第三者への攻撃元などの通告) の対応体制、対応マニュアル/メモ の作成と実行(捜査機関などの協力 要請への対応も別途、要検討) 4. 記録保全体制、手順書の作成 5. サービス/システム一時停止の判断 基準の作成 インシデントレスインシデントレス ポンスポンス 予防保守 1. ハードウェアの二重化 (RAID 、フェ イルオーバー、スタンバイシステム など ) 2. データの多重化(バックアップも含 む) 3. システムログの監視(通常状態の把 握と異常状態の検知) 4. パフォーマンス統計の監視(通常状 態の把握と異常状態の検知) 5. ソフトウェアのバージョンアップ 6. 異常状態の自動検出システムの作り こみ(システム停止、サービス停止 を含む) 自動化に向いている自動化に向いている
  • 18. Copyright 2004,2007 © Kensuke Nezu, All18 情報収集のコツ情報収集のコツ (1)(1) プッシュ型コンテンツを有効にプッシュ型コンテンツを有効に 利用利用  JPCERT/CCJPCERT/CC メーリングリストメーリングリスト ((http://www.jpcert.or.jp/announce.htmlhttp://www.jpcert.or.jp/announce.html))  US CERTUS CERT メーリングリストメーリングリスト ((http://www.us-cert.gov/cas/index.htmlhttp://www.us-cert.gov/cas/index.html))  スラッシュドットジャパンスラッシュドットジャパン [[ 毎日のヘッドライン毎日のヘッドライン ] (] (http://http://slashdot.jpslashdot.jp//))  CNET Japan : NewsLetter(CNET Japan : NewsLetter( http://japan.cnet.com/news/sec/http://japan.cnet.com/news/sec/ ))  MicrosoftMicrosoft プロダクトセキュリティ警告サービス日本語版プロダクトセキュリティ警告サービス日本語版 (( http://www.microsoft.com/japan/technet/security/bulletin/notify.asphttp://www.microsoft.com/japan/technet/security/bulletin/notify.asp)) 無作為攻撃では Windows をターゲットにしたものも ・・・ 無作為攻撃では Windows をターゲットにしたものも ・・・
  • 19. Copyright 2004,2007 © Kensuke Nezu, All19 情報収集のコツ情報収集のコツ (2)(2)    メーリングリストの活   メーリングリストの活 用用  セキュリティホールセキュリティホール memo ML(memo ML(http://memo.st.ryukoku.ac.jp/http://memo.st.ryukoku.ac.jp/))  2424 時間常時接続時間常時接続 ML (ML (http://cn24h.hawkeye.ac/connect24h.htmlhttp://cn24h.hawkeye.ac/connect24h.html))  Intrusions List ML (Intrusions List ML (http://http://www.dshield.org/mailman/listinfo/intrusionswww.dshield.org/mailman/listinfo/intrusions))  各種各種 OSOS のユーザーのユーザー MLML  LinuxLinux ディストリビューションのユーザディストリビューションのユーザ MLML  など などパッチを当てるタイミン グ、 update の安定動作 の確認 パッチを当てるタイミン グ、 update の安定動作 の確認 メーリングリストの主旨 は、あくまでも「情報交 換」。 「収集」のみではなく、 「提供」できるようにす る努力も工数のうちです 。 メーリングリストの主旨 は、あくまでも「情報交 換」。 「収集」のみではなく、 「提供」できるようにす る努力も工数のうちです 。
  • 20. Copyright 2004,2007 © Kensuke Nezu, All20 情報収集のコツ情報収集のコツ (3)(3) ホームページの活用ホームページの活用  前2ページで紹介したところにはそれぞれに大抵前2ページで紹介したところにはそれぞれに大抵 ホームページがありますホームページがあります  WWWCWWWC 等のホームページ更新チェッカで自動化等のホームページ更新チェッカで自動化  記事のリンク先のホームページ情報も確認しまし記事のリンク先のホームページ情報も確認しまし ょうょう    プル型コンテンツなのでプッシュ型と比較するとプル型コンテンツなのでプッシュ型と比較すると ひと手間多くかかりますひと手間多くかかります注意!
  • 21. Copyright 2004,2007 © Kensuke Nezu, All21 セキュリティポリシーの必要性セキュリティポリシーの必要性 (1)(1) 個人サーバ運用の立場からみて・・・個人サーバ運用の立場からみて・・・  作業手順、作業量の明確化作業手順、作業量の明確化  やるべきこととやった方がいいこと、やっちゃいやるべきこととやった方がいいこと、やっちゃい けないことが明確になる→ちゃんとメモを取ろうけないことが明確になる→ちゃんとメモを取ろう !!  作業全体の見通しがよくなる作業全体の見通しがよくなる  忘れた頃にやってくるバージョンアップ忘れた頃にやってくるバージョンアップ // 再再 構築構築  裁判裁判 // 訴訟、刑事事件などの際の証拠保全訴訟、刑事事件などの際の証拠保全
  • 22. Copyright 2004,2007 © Kensuke Nezu, All22 セキュリティポリシーの必要性セキュリティポリシーの必要性 (2)(2) …企業サーバ運用の立場からみて…企業サーバ運用の立場からみて  作業手順、作業量の明確化作業手順、作業量の明確化  複数人で均質の作業複数人で均質の作業  全社的なセキュリティ意識の統一全社的なセキュリティ意識の統一  対外的なポリシー運用の提示対外的なポリシー運用の提示  担当者が変わった頃にくるバージョンアップ担当者が変わった頃にくるバージョンアップ // 再構築再構築  裁判 / 訴訟、刑事事件などの際の証拠保全 これは、企業だけでなく 、ゼミのサーバや部のサ ーバ、学校のイントラサ ーバでもおなじ。 これは、企業だけでなく 、ゼミのサーバや部のサ ーバ、学校のイントラサ ーバでもおなじ。 訴訟のリスク はより大きい ! 訴訟のリスク はより大きい !
  • 23. Copyright 2004,2007 © Kensuke Nezu, All23 セキュリティポリシーの必要性セキュリティポリシーの必要性 (3)(3) 素早いレスポンスを心がけよう!素早いレスポンスを心がけよう!  サーバサーバ // サービス停止の判断を独力でできない場合はサービス停止の判断を独力でできない場合は 、「緊急連絡網」を作って指示を仰ごう。、「緊急連絡網」を作って指示を仰ごう。  脆弱性指摘などがあった場合には、調査期間と回答期脆弱性指摘などがあった場合には、調査期間と回答期 限をつけてまずは返信しておこう。限をつけてまずは返信しておこう。  指摘自体が「愉快犯」の可能性もゼロではありません。指摘自体が「愉快犯」の可能性もゼロではありません。 まずは、指摘事項の確認・再現を怠ってはなりませんまずは、指摘事項の確認・再現を怠ってはなりません 。。  システムが侵入されていると、オペレータ作業でシステムが侵入されていると、オペレータ作業で rootroot 権限が乗っ取られる場合もあるので注意!権限が乗っ取られる場合もあるので注意!  やりとりや作業は、きちんと記録を付けましょう。やりとりや作業は、きちんと記録を付けましょう。
  • 24. Copyright 2004,2007 © Kensuke Nezu, All24 システムログの保存(保全措システムログの保存(保全措 置)置) 保存期間を最低1年以上に!保存期間を最低1年以上に!  ディストリビューションの標準ディストリビューションの標準 設定は4週間。最低でも53週設定は4週間。最低でも53週 間(371日)に。間(371日)に。  /etc/logrotate.conf/etc/logrotate.conf のの rotate 4 roatate 53→rotate 4 roatate 53→ にに する。する。  定期的にログを定期的にログを CD-RCD-R に焼いてに焼いて バックアップを取りましょうバックアップを取りましょう  /var/var は専用パーティションを用は専用パーティションを用 意して大きめにとる。意して大きめにとる。  // と一緒で溢れるとfsが壊れること一緒で溢れるとfsが壊れるこ とも・・・とも・・・ /etc/logrotate.conf の例: # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 → 53
  • 25. Copyright 2004,2007 © Kensuke Nezu, All25 サーバー運用の注意点サーバー運用の注意点 (1)(1) 「やられたら再インストールすればいい」「やられたら再インストールすればいい」は間は間 違い!違い!  本当にやられちゃったら気付きません。 ←本当にやられちゃったら気付きません。 ← rootkitrootkit の存在の存在  簡単な自動ツールくらいしか目で見てわからないです簡単な自動ツールくらいしか目で見てわからないです  いつかは面倒になって目でも見なくなりますいつかは面倒になって目でも見なくなります  「天災は忘れた頃にやってくる」「天災は忘れた頃にやってくる」  ペーターとおおかみペーターとおおかみ  気付いたときには手遅れです気付いたときには手遅れです教訓:侵入を事前予報できるシステムが必要教訓:侵入を事前予報できるシステムが必要 脆弱なフリー のサーバ事件
  • 26. Copyright 2004,2007 © Kensuke Nezu, All26 サーバー運用の注意点サーバー運用の注意点 (2)(2) サーバー1台ですべてやろう・・・は間サーバー1台ですべてやろう・・・は間 違い!違い!  NATNAT ルータ機能、フィルタリング機能、サーバ機ルータ機能、フィルタリング機能、サーバ機 能・・・全部をごちゃごちゃに1台で運用するのはスゴ能・・・全部をごちゃごちゃに1台で運用するのはスゴ く難しいく難しい  技術的チャレンジ・・・、でも一歩間違えるとネット全体に迷惑技術的チャレンジ・・・、でも一歩間違えるとネット全体に迷惑 が・・・が・・・  趣味のサーバーも「グローバル趣味のサーバーも「グローバル IPIP アドレス」を持っている立場アドレス」を持っている立場 としては、としては、 NASANASA    /FBI/FBI    /NSA/NSA や、や、 YahooYahoo 、楽天、ホワイトハ、楽天、ホワイトハ ウスサーバと同等の責任がありますウスサーバと同等の責任があります  多重防御多重防御 // 多層防御が防御の基本多層防御が防御の基本  なぜ、大阪城には外堀と内堀があったの?なぜ、大阪城には外堀と内堀があったの? 教訓:幾重にも防護壁を作っておきましょう教訓:幾重にも防護壁を作っておきましょう ブロードバ ンドルータ の併用
  • 27. Copyright 2004,2007 © Kensuke Nezu, All27 サーバー運用の注意点サーバー運用の注意点 (3)(3) 固定固定 IPIP アドレスを取得するアドレスを取得する  IPIP アドレスはサーバーの「住所」ですアドレスはサーバーの「住所」です  いつ転居するか分からない「住所」では困ることがありますいつ転居するか分からない「住所」では困ることがあります  ドメインは「友達の鈴木君ち」みたいなもので固定であることがドメインは「友達の鈴木君ち」みたいなもので固定であることが 信頼性につながりません信頼性につながりません  可変アドレス、ダイナミック可変アドレス、ダイナミック DNSDNS では利用できないものでは利用できないもの も・・・も・・・  おうちメールサーバーは運用できませんおうちメールサーバーは運用できません  アクセスが多くなると他の人への攻撃になることも・・・アクセスが多くなると他の人への攻撃になることも・・・ 教訓:やっぱり安心の固定教訓:やっぱり安心の固定 IPIP アドレス!アドレス!
  • 28. Copyright 2004,2007 © Kensuke Nezu, All28 サーバー運用の注意点サーバー運用の注意点 (4)(4) 複数の固定複数の固定 IPIP アドレスを取得しよう!アドレスを取得しよう!  インターネットのインシデントは、主に「自分のサーバインターネットのインシデントは、主に「自分のサーバ だけをねらい打ちにしたもの」と、「機械的に総ナメにだけをねらい打ちにしたもの」と、「機械的に総ナメに していくもの」に分けられますしていくもの」に分けられます  「機械的」なものにはツールやウィルスなどがありますが、これ「機械的」なものにはツールやウィルスなどがありますが、これ らはそれほどらはそれほど「危険性は高くありません」「危険性は高くありません」  これを判断するためには、2つ以上の連続した(もしくこれを判断するためには、2つ以上の連続した(もしく は近い)アドレスで監視をする必要がありますは近い)アドレスで監視をする必要があります  これは、複数サーバでなくともこれは、複数サーバでなくとも IPIP アドレスのエイリアス機能でアドレスのエイリアス機能で もも OKOK    教訓:比較/対照は分析の基礎です教訓:比較/対照は分析の基礎です
  • 29. Copyright 2004,2007 © Kensuke Nezu, All29 サーバ管理者に求められる資質サーバ管理者に求められる資質 (1)(1)  サーバ上の情報に個人的サーバ上の情報に個人的 興味を持ってはいけない興味を持ってはいけない  ユーザのパスワードはユーザのパスワードは 「すぐに忘れる」「すぐに忘れる」  管理の都合上「知ってし管理の都合上「知ってし まった」事も知らぬ存ぜまった」事も知らぬ存ぜ ぬを貫くぬを貫く  サーバ上の不法行為の証サーバ上の不法行為の証 拠には常に目を光らせる拠には常に目を光らせる  管理者権限、管理者ア管理者権限、管理者ア カウント情報は、管理カウント情報は、管理 者をやめたら「忘れな者をやめたら「忘れな ければならない」ければならない」 From hira@<平山> To naka@<なかむらくん> Subject きのうのデート なかむらくん、昨日は楽しい デートをどうもありがとう・ ・・。 遊園地とってもたのしかった です。また誘ってください。 ふむふ む・・・
  • 30. Copyright 2004,2007 © Kensuke Nezu, All30 サーバ管理者に求められる資質サーバ管理者に求められる資質 (2)(2)  サーバ管理者は実用的サーバ管理者は実用的 な法律家である必要がな法律家である必要が あります。あります。  著作権法著作権法  不正アクセス禁止法不正アクセス禁止法  個人情報保護法個人情報保護法  プロバイダ法プロバイダ法  表現の自由と名誉毀損表現の自由と名誉毀損  脅迫等の刑法脅迫等の刑法  etc…etc…  世の状況(裁判の判決世の状況(裁判の判決 など)にも敏感でなけなど)にも敏感でなけ ればなりません。ればなりません。 ・映画のコピー ・不許可のアイドル写真 ・ TV のキャプチャ画像 ・不法なソフトウェアコピー ・ホームページのコピペふむふ む・・・
  • 31. Copyright 2004,2007 © Kensuke Nezu, All31 サーバ管理者に求められる資質サーバ管理者に求められる資質 (3)(3) ~優良推薦参考図書~~優良推薦参考図書~  「ハイテク犯罪捜査入門~捜査実務「ハイテク犯罪捜査入門~捜査実務 編」編」  警察、検察側の現在の常識と今後数年間の警察、検察側の現在の常識と今後数年間の 動向を占うことができる書籍動向を占うことができる書籍  著者は、現役の札幌高等検事局検事さん著者は、現役の札幌高等検事局検事さん  技術書ではないが、「捜査」の現場で、実技術書ではないが、「捜査」の現場で、実 際に何がどのような判断で行われているか際に何がどのような判断で行われているか を知っておくことは必ず役立ちます。特にを知っておくことは必ず役立ちます。特に 、初動捜査における「証拠」として何を用、初動捜査における「証拠」として何を用 意しておけばよいかなどの判断にも使えま意しておけばよいかなどの判断にも使えま す。す。 ※※ 技術的には、現場の警察官を対象として技術的には、現場の警察官を対象として いるため、初心者向けの若干のウソも見らいるため、初心者向けの若干のウソも見ら れます。れます。
  • 32. Copyright 2004,2007 © Kensuke Nezu, All32 サーバー構築方法サーバー構築方法
  • 33. Copyright 2004,2007 © Kensuke Nezu, All33 セキュアサーバー構築方法論セキュアサーバー構築方法論 10:9010:90 の法則を適用すると・・・の法則を適用すると・・・  パケットフィルタリングによるセキュリティの確保パケットフィルタリングによるセキュリティの確保  サーバー、ルーターそれぞれで設定が必要サーバー、ルーターそれぞれで設定が必要  守れるもの、守れないものを意識することが必要守れるもの、守れないものを意識することが必要  サービスの限定など、他の機能との組み合わせが必要サービスの限定など、他の機能との組み合わせが必要  サービスの限定、公開範囲の限定サービスの限定、公開範囲の限定  各サービス、ソフトウェア毎の設定が必要  各サービス、ソフトウェア毎の設定が必要    自動監視ツールなどによる監視コストの低減自動監視ツールなどによる監視コストの低減  ツールとして自作しなければいけない場合もあるツールとして自作しなければいけない場合もある  プロバイダのサービスや商用ソフトウェア利用が推奨される場合プロバイダのサービスや商用ソフトウェア利用が推奨される場合 も・・・  も・・・               商用ファイヤ ーウォール 商用ファイヤ ーウォール Snort などの 侵入検知ツー ル Snort などの 侵入検知ツー ル 本格的なスキ ルや監視コス トが必要
  • 34. Copyright 2004,2007 © Kensuke Nezu, All34 パケットフィルタリングについパケットフィルタリングについ てて (1)(1) パケットフィルタリングが有効な場面パケットフィルタリングが有効な場面  公開する内容、条件、相手などがルールとして固定的に決定できる場公開する内容、条件、相手などがルールとして固定的に決定できる場 合合  時間帯限定公開や、同時接続数上限などの設定は基本的にできな時間帯限定公開や、同時接続数上限などの設定は基本的にできな いい  FTPFTP でのファイル転送などサービスポートが動的なものには向かでのファイル転送などサービスポートが動的なものには向か ないない  サービスの単位で、または公開先として固定的な場所からのアクセスサービスの単位で、または公開先として固定的な場所からのアクセス が特定できる場合が特定できる場合  今日は今日は NIFTYNIFTY から、明日はから、明日は so-netso-net から・・・という動的な条件にから・・・という動的な条件に は向かないは向かない  HTTPHTTP でで javascriptjavascript の実行権限などサービス内での制限はできないの実行権限などサービス内での制限はできない 時間帯限定はブロードバ ンドルータによっては可 能なものもあります 時間帯限定はブロードバ ンドルータによっては可 能なものもあります
  • 35. Copyright 2004,2007 © Kensuke Nezu, All35 主なウェルノウン・ポ主なウェルノウン・ポ ートート  「「 ** 」のついているサービスは基本」のついているサービスは基本 的に公開すべきでないポート的に公開すべきでないポート  社内社内 LANLAN 等、イントラネットでの等、イントラネットでの 運用を前提とするセキュアでないサ運用を前提とするセキュアでないサ ービスービス  インターネットがいにしえの良き時インターネットがいにしえの良き時 代であったころに参加者がすべて善代であったころに参加者がすべて善 良であることを前提としたサービス良であることを前提としたサービス ホ ゚ー ト TCP/ UDP サービス名 20 TCP ft p- dat a FTPサービスのデータ転送用 21 TCP ft p- c o nt ro l FTPサービス制御用 22 TCP s s h Se c ure Sh e llセキュア・シェル( )接続 23 TCP t e lne t Te ln e t 接続 25 TCP s mtp s e ndmail/ qmail/ po s t fixなどのメール・サーバ接続 53 TCP/ UDP do main DNSドメイン・ネーム・サービス( ) 67 UDP bo o t ps BOOTPサーバ* 68 UDP bo o t pc BOOTPクライアント* 69 UDP t ftp TFTPサーバ* 70 TCP go ph e r Go ph e rサーバ* 79 TCP finge r Finge rサービス* 80 TCP h t tp We bサーバ 98 TCP linuxc o nf linuxc o nfネットワーク・サービス* 109 TCP po p- 2 POP- 2メール受信用 110 TCP po p- 3 POP- 3メール受信用 111 TCP/ UDP s unrpc RPC 4.0 po rt mappe r* 113 TCP ide nt ide ntクライアント・ユーザ確認( )* 119 TCP nnt p インターネット・ニュース・サービス 123 TCP/ UDP nt p ネットワーク時刻同期サービス 135 TCP mic ro s o ft- rpc Mic ro s o ft RPC Exc h ange Se rve rの サービス( など) 137 UDP ne t bio s - ns MS- Ne t wo rkネーム・サービス* 138 UDP ne t bio s - dgm MS- Ne t wo rkブラウジング・サービスなど* 139 TCP ne t bio s - s s n MS- Ne t wo rk /ファイルプリンタ共有サービス* 143 TCP imap IMAP4メール・サービス 144 TCP Ne WS Ne WSウィンドウ・システム・サービス* 161 UDP s nmp ネットワーク管理用* 162 UDP s nmp- t rap ネットワーク管理用(異常検知など)* 443 TCP h t tps We b暗号化した サービス 445 TCP mic ro s o ft- DS Windo ws 2000 CIFS以降の 接続用* 512 TCP e xe c BSD UNIX re xe c d系 の デーモン用* 512 UDP biff UNIX biff(メール到着通知)サービス* 513 TCP lo gin BSD UNIX rlo gind系 の デーモン用* 513 UDP wh o BSD UNIX rwh o d系 の デーモン用* 514 TCP s h e ll BSD UNIX rwh o d系 の デーモン用* 514 UDP s ys lo g BSD UNIX s ys lo gd系 の デーモン用* 515 TCP print e r BSD UNIX lpd系 の デーモン用* 517 UDP t alk BSD UNIX talkd系 の デーモン用* 518 UDP nt alk SunOS talkdの デーモン用* 520 UDP ro ute BSD UNIX ro ut e d系 の デーモン用* 525 UDP t ime d BSD UNIX time d系 の デーモン用* 554 TCP/ UDP rts p リアルタイム・ストリーミング用 635 UDP mo unt NFSマウント・サービス* 901 TCP s wat Samba We bの ベース管理ツール用*
  • 36. Copyright 2004,2007 © Kensuke Nezu, All36 パケットフィルタリングについパケットフィルタリングについ てて (3)(3) 10241024 以降の定義済ポートの例以降の定義済ポートの例  Microsoft SQL ServerMicrosoft SQL Server のの RPCRPC (( Remote Procedure Call)Remote Procedure Call) で使うで使う 1433/TCP1433/TCP  非透過型プロキシーサービス非透過型プロキシーサービス (delegate(delegate など)でなど)で 8080/TCP,1080/TCP8080/TCP,1080/TCP  X WindowX Window のフォントサーバのフォントサーバ (xfs)(xfs) でで 7100/TCP7100/TCP  X WindowX Window のの XX サーバーでサーバーで 6000/TCP6000/TCP  仮名漢字変換仮名漢字変換 WnnWnn サーバーでサーバーで 22273/TCP22273/TCP  仮名漢字変換仮名漢字変換 CannaCanna サーバーでサーバーで 5680/TCP5680/TCP  NFSNFS でで 2049/UDP2049/UDP インターネットに公開すべきでないポートがほとんどインターネットに公開すべきでないポートがほとんど
  • 37. Copyright 2004,2007 © Kensuke Nezu, All37 パケットフィルタリングについパケットフィルタリングについ てて (4)(4) 10241024 以降で以降で IANAIANA 未定義だがよくウィルスに使われるポートの例未定義だがよくウィルスに使われるポートの例  SasserSasser ウィルスが使うウィルスが使う Microsoft RPCMicrosoft RPC のの 1025/TCP1025/TCP  DamewareDameware ウィルスが使うバックドアポートウィルスが使うバックドアポート 6129/TCP6129/TCP  MyDoomMyDoom ウィルスが使うバックドアポートウィルスが使うバックドアポート 3127/TCP3127/TCP  SQL SnakeSQL Snake ウィルスが使うウィルスが使う Microsoft SQL ServerMicrosoft SQL Server のの 1433/TCP1433/TCP  バックドアバックドア (( トロイの木馬)プログラムトロイの木馬)プログラム WinHoleWinHole でで 1080/TCP1080/TCP  バックドアプログラムバックドアプログラム RingZeroRingZero でで 8080/TCP8080/TCP とと 3128/TCP3128/TCP  Windows XPWindows XP のリモートデスクトップが使うのリモートデスクトップが使う 3389/TCP3389/TCP 絶対にインターネットに公開すべきでないポート絶対にインターネットに公開すべきでないポート
  • 38. Copyright 2004,2007 © Kensuke Nezu, All38 パケットフィルタリングについパケットフィルタリングについ てて (5)(5) 危険なソースルーティング危険なソースルーティング コンピュータ C攻撃者 B コンピュータ A 送信元:送信元: AA 宛先:宛先: CC 経由:経由: 送信元:送信元: CC 宛先:宛先: AA 経由:経由: BB 送信元:送信元: CC 宛先:宛先: AA 経由:経由: 送信元:送信元: AA 宛先:宛先: CC 経由:経由: BB 通常のパケット ソースルーティン グされると・・・
  • 39. Copyright 2004,2007 © Kensuke Nezu, All39 パケットフィルタリングについパケットフィルタリングについ てて (6)(6) TCPTCP の特殊な状態の特殊な状態 (1)(1) ~接続~接続~~ 3-Way Handshake3-Way Handshake SEQ :シーケンス番 号 ACK :返信番号 CTL :制御フラグ ③<411> <312> <ACK>+ データ ① <311> <SYN> ② <411> <312> <SYN,ACK> 要求者 A 相手 B SEQ ACK CTL 3-3- ウェイ・ハンドシウェイ・ハンドシ ェイクェイク パケットフィルタリ ングで防御しきれな い •① を大量に送りつけ て B をサービス不能 に・・・ → SYN Flood 攻撃 •① の応答②があるか どうかでポートスキ ャン Syslog にもでてきませ ん Syslog にもでてきませ ん 防御にはサーバ上のユー ティリティなどが必要 防御にはサーバ上のユー ティリティなどが必要 Web やft pを一切サ ービスして ないなら防 御可能 Web やft pを一切サ ービスして ないなら防 御可能
  • 40. Copyright 2004,2007 © Kensuke Nezu, All40 パケットフィルタリングについパケットフィルタリングについ てて (7)(7) TCPTCP の特殊な状態の特殊な状態 (2)(2) ~切断~切断~~ SEQ :シーケンス番 号 ACK :返信番号 CTL :制御フラグ パケットフィルタリ ングで防御しきれな い •① の応答②があるか どうかでポートスキ ャン 実際は双方向通信なので 、反対向きも行われる 実際は双方向通信なので 、反対向きも行われる ① <FIN> ② <FIN,ACK> リクエスト側 SEQ ACK CTL リクエストを受ける側 多くの機器や OS ではサー ビスが有効なら未接続の状 態でも <FIN> に反応する 多くの機器や OS ではサー ビスが有効なら未接続の状 態でも <FIN> に反応する
  • 41. Copyright 2004,2007 © Kensuke Nezu, All41 パケットフィルタリングについパケットフィルタリングについ てて (8)(8) UDP(User Datagram Protocol)UDP(User Datagram Protocol) についてについて  パケットが相手に到達したことが確認できないパケットが相手に到達したことが確認できない  「接続を覚えて」おかなくてもよい「接続を覚えて」おかなくてもよい  TCPTCP と異なり相手の返信をまたなくてもよいと異なり相手の返信をまたなくてもよい インターネットサービスでは少数派、主にインターネットサービスでは少数派、主に DNS/snmpDNS/snmp 等で利用される等で利用される 名前←→ IP アドレス変換の 問い合わせなど 名前←→ IP アドレス変換の 問い合わせなど プライマリ DNS とセカンダリ DNS とのデータ複写で TCP も利 用している プライマリ DNS とセカンダリ DNS とのデータ複写で TCP も利 用している
  • 42. Copyright 2004,2007 © Kensuke Nezu, All42 パケットフィルタリングについパケットフィルタリングについ てて (9)(9) ICMP(Internet Control Message Protocol)ICMP(Internet Control Message Protocol) についてについて  データ通信には使われないデータ通信には使われない  ネットワーク障害によるエラー通知ネットワーク障害によるエラー通知  診断機能用のメッセージのやりとり診断機能用のメッセージのやりとり  いくつかのメッセージタイプがあるいくつかのメッセージタイプがある  ブロードキャストアドレス宛てのブロードキャストアドレス宛ての ICMPICMP には全機器が反応には全機器が反応 Host Unreachable Host Unreachable Network Unreachable Network Unreachable 自サイトのブロードキャストアドレス宛の自サイトのブロードキャストアドレス宛の ICMPICMP は遮断しなければならないは遮断しなければならない Ping や traceroute など Ping や traceroute など Smurf という DDoS の防止 Smurf という DDoS の防止
  • 43. Copyright 2004,2007 © Kensuke Nezu, All43 パケットフィルタリングについパケットフィルタリングについ てて (10)(10) タイプ 名前 意味 0 Ec ho Re ply ICMP ping/ trac e routeエコー応答( の返信用) 3 De s tination Unre ac hable あて先アドレスに到達不可能 4 Sourc e Que nc he 受信バッファあふれによる送信元への通信停止要求 5 Re dire c t 最適な経路でないことを送信元に通知 8 Ec ho ICMP ping/ trac e routeエコー要求( の送信用) 9 Route r Adve rtis e me nt ルータ通知 10 Route r Se le c tion ルータ選択 11 Time Exc e e d TTL Time To Live( )時間の超過 12 Parame te r Proble m パケットのパラメータ異常 13 Time s tamp タイム・スタンプ保持要求 14 Time s tamp Re ply タイム・スタンプ保持応答 17 Addre s s Mas k Re que s t アドレス・マスク要求 18 Addre s s Mas k Re ply アドレス・マスク応答 ICMP メッセージのタイプ Windows 版の tracert コマンドが利用 Windows 版の tracert コマンドが利用 UNIX/Linux 版の traceroute は UDP/33434 を使用 UNIX/Linux 版の traceroute は UDP/33434 を使用
  • 44. Copyright 2004,2007 © Kensuke Nezu, All44 パケットフィルタリングについパケットフィルタリングについ てて (11)(11) ICMPICMP Smurf攻撃のしくみSmurf攻撃のしくみ (1)(1) 1.1. 攻撃者は攻撃者は IPIP アドレスをなアドレスをな りすまして各サイトのブりすまして各サイトのブ ロードキャストアドレスにロードキャストアドレスに ICMPICMP エコーを送信エコーを送信 ターゲット 攻撃者
  • 45. Copyright 2004,2007 © Kensuke Nezu, All45 パケットフィルタリングについパケットフィルタリングについ てて (12)(12) ICMPICMP Smurf攻撃のしくみSmurf攻撃のしくみ (2)(2) 1.1. 攻撃者は攻撃者は IPIP アドレスをなアドレスをな りすまして各サイトのブりすまして各サイトのブ ロードキャストアドレスにロードキャストアドレスに ICMPICMP エコーを送信エコーを送信 2.2. 各サイトの全機器がター各サイトの全機器がター ゲットに一斉にゲットに一斉に ICMPICMP エエ コーリプライを送信コーリプライを送信 3.3. ネットワークがパンクネットワークがパンク ターゲット 攻撃者
  • 46. Copyright 2004,2007 © Kensuke Nezu, All46 パケットフィルタリングについパケットフィルタリングについ てて (13)(13) 実は実は SmurfSmurf 攻撃には攻撃には DNSDNS クエリクエリ SmurfSmurf 攻撃もあります攻撃もあります 1.1. 犠牲者ホストの犠牲者ホストの IPIP アドレスをなりすました端末かアドレスをなりすました端末か らの問いあわせ(クエリ)をネット上のらの問いあわせ(クエリ)をネット上の DNSDNS サーバサーバ 群に一斉送信群に一斉送信 2.2. DNSDNS サーバがインターネット側からのクエリに反応サーバがインターネット側からのクエリに反応 して、検索結果を返すして、検索結果を返す 3.3. 犠牲者ホストにクエリの結果が溢れて犠牲者ホストにクエリの結果が溢れて DDoSDDoS になるになる    これは本来、これは本来、 LANLAN 内からの端末クエリしか反応しない様に内からの端末クエリしか反応しない様に DNSDNS が適切に設定されていれば防げるものですが適切に設定されていれば防げるものです
  • 47. Copyright 2004,2007 © Kensuke Nezu, All47 パケットフィルタリングについパケットフィルタリングについ てて (14)(14) 短命なポート(エフェメラル・ポート)短命なポート(エフェメラル・ポート) Web サーバ PC ポート番号:1 234 ポート番号:8 0 ポート番号:1 234 ポート番号:8 0 •接続を依頼する側が一時的に使用す るポート •1024 番以降の適当なポートを使用
  • 48. Copyright 2004,2007 © Kensuke Nezu, All48 パケットフィルタリングについパケットフィルタリングについ てて (15)(15) ~パケットフィルタリン~パケットフィルタリン グの要点~グの要点~ パケットフィルタリングで利用できるパラメータパケットフィルタリングで利用できるパラメータ  送信元送信元 IPIP アドレスアドレス  あて先あて先 IPIP アドレスアドレス  送信元ポート番号送信元ポート番号  あて先ポート番号あて先ポート番号  プロトコル種別プロトコル種別  TCPTCP のフラグ(のフラグ( SYN,FIN,ACKSYN,FIN,ACK など)など)  ICMPICMP のタイプのタイプ これらの情報を必要に応じて組み合わせて設定するこれらの情報を必要に応じて組み合わせて設定する 範囲指定が可能 機器によっては未対機器によっては未対 応応
  • 49. Copyright 2004,2007 © Kensuke Nezu, All49 パケットフィルタリングについてパケットフィルタリングについて (16)(16) ブロードバンドルーターの設定の要点ブロードバンドルーターの設定の要点  NAT+IPNAT+IP マスカレードでは外部からの攻撃はまず不可能マスカレードでは外部からの攻撃はまず不可能  外部からの攻撃を防止する目的のパケットフィルタリング不要外部からの攻撃を防止する目的のパケットフィルタリング不要  → → SYNFloodSYNFlood 攻撃防止機能を持つものもある攻撃防止機能を持つものもある  LANLAN からの外向きのパケットフィルタリングが必要からの外向きのパケットフィルタリングが必要  ウィルス感染ウィルス感染 PCPC からのパケット発信(からのパケット発信( SMTPSMTP 大量送信など)防大量送信など)防 止止  Microsoft NetworkMicrosoft Network (ネットワークフォルダ(ネットワークフォルダ )) 等のパケットの漏洩を防等のパケットの漏洩を防 止止  公開サーバは簡易公開サーバは簡易 DMZDMZ もしくはポート単位で公開するもしくはポート単位で公開する  ルータルータ 22 台用いて、本格的な台用いて、本格的な DMZDMZ を組むことを強くを組むことを強く 推奨します推奨します
  • 50. Copyright 2004,2007 © Kensuke Nezu, All50 パケットフィルタリングについてパケットフィルタリングについて (17)(17) 公開サーバーの設定の要点公開サーバーの設定の要点  いくつかの公開サービスいくつかの公開サービス  プライマリプライマリ DNSDNS  通常の通常の 53/UDP53/UDP へのアクセスと、セカンダリをお願いしているセへのアクセスと、セカンダリをお願いしているセ カンダリカンダリ DNSDNS のの IPIP アドレスからのアドレスからの 53/TCP53/TCP への接続許可が必要への接続許可が必要  セカンダリメール・サーバー(受けてあげるなら・・セカンダリメール・サーバー(受けてあげるなら・・ ・)・)  他の人のプライマリ・メール・サーバーに何らかの障害があると他の人のプライマリ・メール・サーバーに何らかの障害があると きにメールを代行受信きにメールを代行受信  25/TCP25/TCP への接続を許可した上で、プライマリ・メール・サーバへの接続を許可した上で、プライマリ・メール・サーバ ーのーの 25/TCP25/TCP への接続を許可し受信済メールを転送可能にへの接続を許可し受信済メールを転送可能に
  • 51. Copyright 2004,2007 © Kensuke Nezu, All51 パケットフィルタリングについてパケットフィルタリングについて (18)(18) 公開サーバーの設定例公開サーバーの設定例 番号 パケットの向き IP送信元 アドレス IPあて先 アドレス プロトコル 送信元ポート番号 あて先ポート番号 ICMPのタイプ /通過 破棄 説明 1 IN すべて 61.211.1.178 TCP すべて 25,80,443 - 通過 We b SMTP, の接続を許可 2 IN 192.168.0.0/ 24 61.211.1.178 TCP すべて 22 - 通過 LAN s s hからのみ を許可 3 IN IPセカンダリの アドレス 61.211.1.178 TCP すべて 53 - 通過 DNSセカンダリ からのゾーン転送を許可 4 IN すべて 61.211.1.178 UDP すべて 53 - 通過 DNSへの問い合わせを許可 5 IN すべて 61.211.1.178 ICMP - - 0 3 8 11, , , 通過 ネットワーク試験用 6 IN すべて すべて すべて すべて すべて すべて 破棄 上記以外の入力パケットを遮断 7 OUT 61.211.1.178 IPプライマリの アドレス TCP すべて 25 - 通過 プライマリ・メール・サーバへの転送を許可 8 OUT 61.211.1.178 すべて TCP 25 80 443, , すべて - 通過 より安全にするなら設定する 9 OUT 61.211.1.178 61.211.1.180 TCP 22 すべて - 通過 同上 10 OUT 61.211.1.178 61.210.22.254 TCP すべて 53 - 通過 同上 11 OUT 61.211.1.178 すべて UDP 53 すべて - 通過 同上 12 OUT 61.211.1.178 すべて ICMP - - 0 3 8 11, , , 通過 同上 13 OUT すべて すべて すべて すべて すべて すべて 破棄 - MTA の設定不良によ るオープンリレーの防 止 MTA の設定不良によ るオープンリレーの防 止 管理者の ssh アクセスをインターネットから可 能にするならルール2を変更。この場 合、 /etc/hosts.allow などでアクセス元を限定 すること。 管理者の ssh アクセスをインターネットから可 能にするならルール2を変更。この場 合、 /etc/hosts.allow などでアクセス元を限定 すること。 パッケージのアップデートはftpを 使う場合がほとんどなので、この場合 、ルール 13 を止めないといけない パッケージのアップデートはftpを 使う場合がほとんどなので、この場合 、ルール 13 を止めないといけない
  • 52. Copyright 2004,2007 © Kensuke Nezu, All52 パケットフィルタリングの具体例パケットフィルタリングの具体例 (1)(1) LinuxLinux のの iptablesiptables 利用上の注意点利用上の注意点 1. インターネットに接続した状態で /etc/rc.d/init.d/iptables restart するのはあまり好ましくありません。 1. 上記スクリプトの設計上、いったん全部削除して、ポリシーだ け残るので、 ACCEPT ポリシーだけ残った状態で全てのポート が一瞬オープン状態になります 2. システムの再起動ならば、 iptables のポリシが設定されてから ネットワークが立ち上がるので安全です。 2. ネットワークを切断してコンソールで作業するか、シス テムを再立ち上げしましょう。 CentOSもデフォルトではポリシがCentOSもデフォルトではポリシが ACCEPTACCEPT ですです
  • 53. Copyright 2004,2007 © Kensuke Nezu, All53 パケットフィルタリングの具体例パケットフィルタリングの具体例 (2)(2) CentOSでファイアウォールオンの標準例CentOSでファイアウォールオンの標準例 (/etc/sysconfig/iptables)(/etc/sysconfig/iptables) :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
  • 54. Copyright 2004,2007 © Kensuke Nezu, All54 パケットフィルタリングの具体例パケットフィルタリングの具体例 (3)(3) CentOSでファイアウォールオン標準設定CentOSでファイアウォールオン標準設定 を改善してみましょう!を改善してみましょう! :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type ping -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type pong -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
  • 55. Copyright 2004,2007 © Kensuke Nezu, All55 実習実習 11 :: CentOSCentOS のファイアウォールのファイアウォール   機能をカスタマイズしてみよう  機能をカスタマイズしてみよう (( 55 分)分)  CentOSCentOS は、は、 RedHat Enterprise LinuxRedHat Enterprise Linux と同様にと同様に iptablesiptables を利用したパケットフィルタ機能によを利用したパケットフィルタ機能によ り簡易ファイアウォールを実現しています。り簡易ファイアウォールを実現しています。  前前 33 ページの内容を見て、実際に簡易ファイページの内容を見て、実際に簡易ファイ アウォールを設定してみましょう。そして、アウォールを設定してみましょう。そして、 その効果を確認してみましょう。その効果を確認してみましょう。 icmpicmp の設定の設定 も変更してみましょう。も変更してみましょう。  GUIGUI の設定コマンドはの設定コマンドは rootroot で、次のコマンドで、次のコマンド を実行します。を実行します。 # system-config-securitylevel# system-config-securitylevel また、設定ファイルは、また、設定ファイルは、 /etc/sysconfig/iptables/etc/sysconfig/iptables です。です。
  • 56. Copyright 2004,2007 © Kensuke Nezu, All56 サーバー構築手順~インストールサーバー構築手順~インストール 編~編~ インストール時にはブロードバンドルータ内で作業せインストール時にはブロードバンドルータ内で作業せ よ!よ!  TCP/IPTCP/IP の制限でファイヤーウォール機能の制限でファイヤーウォール機能 (( パケットフィルパケットフィル タタ )) だけでは防止できないものもあるだけでは防止できないものもある  ディストリビューションディストリビューション CDCD だけではなく最だけではなく最 初にアップデートするのにインターネット接初にアップデートするのにインターネット接 続が必要続が必要  ディストビューションディストビューション CDCD はセキュリティ的はセキュリティ的 に問題のある「古い状態」であることが多いに問題のある「古い状態」であることが多い
  • 57. Copyright 2004,2007 © Kensuke Nezu, All57  CentOSCentOS は、インターネットに接続した上でオは、インターネットに接続した上でオ ンラインで追加インストールをしたり、ソフンラインで追加インストールをしたり、ソフ トウェアの更新版をインストールしたりできトウェアの更新版をインストールしたりでき ます。ます。  本講座で使用する追加のソフトウェアの大半本講座で使用する追加のソフトウェアの大半 をを Cent OSCent OS のアップデータ(のアップデータ( yum)yum) でインスでインス トールできるようにするソフトウェア書庫トールできるようにするソフトウェア書庫 (リポリトジ)もいくつか公開されています(リポリトジ)もいくつか公開されています 。。  時間がないので実習は行いませんが、内容は時間がないので実習は行いませんが、内容は 実習補助資料にあるので、後で自分で環境構実習補助資料にあるので、後で自分で環境構 築してみてください。築してみてください。 CenCen tt OSOS を使った追加ソフトを使った追加ソフト ウェアウェア インストールについてインストールについて
  • 58. Copyright 2004,2007 © Kensuke Nezu, All58 サーバー構築手順~最初の1手サーバー構築手順~最初の1手 (1)(1) ~~ sshssh サーバー以外をまずは非公開にサーバー以外をまずは非公開に  ssh 環境を最初に構築しよう  端末側( Windows) は PuTTY や TeraTERM pro + TTSSH 、 Poderosa で環境を構築しよう  セキュリティ的な検討、日本語化度を考慮 するとPoderosaがオススメ。ただ し、 ssh2 の鍵の互換性に若干の問題がある 。
  • 59. Copyright 2004,2007 © Kensuke Nezu, All59 サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (2)(2) ~~ PuTTYPuTTY  ダウンロードサイトダウンロードサイト (( 英語英語 )) http://www.chiark.greenend.org.uk/~sgtatham/putty/download.htmlhttp://www.chiark.greenend.org.uk/~sgtatham/putty/download.html  ダウンロードサイト(非公式日本語パッチ版ダウンロードサイト(非公式日本語パッチ版 )) http://www11.tok2.com/home/hdk/download.htmlhttp://www11.tok2.com/home/hdk/download.html  非公式日本語パッチ作成者サイト非公式日本語パッチ作成者サイト http://hp.vector.co.jp/authors/VA024651/#PuTTYkj_tophttp://hp.vector.co.jp/authors/VA024651/#PuTTYkj_top  特徴特徴  SSH1(RSA), SSH2SSH1(RSA), SSH2 (( DSA)DSA) に対応に対応  cp, ftpcp, ftp に対応するに対応する PSCP, PSFTPPSCP, PSFTP コマンドがあるコマンドがある  Windows 95/98/Me/NT/2000/XP for x86Windows 95/98/Me/NT/2000/XP for x86 以外に以外に NT on AlphaNT on Alpha も対応も対応
  • 60. Copyright 2004,2007 © Kensuke Nezu, All60 サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (3)(3) ~~ TeraTERM pro + TTSSHTeraTERM pro + TTSSH 日本語版日本語版  TeraTERM TeraTERM→TeraTERM TeraTERM→ 日本語版 → 日本語版 →  TTSSH →TTSSH →    TTSSHTTSSH 日本語版と順番にバ日本語版と順番にバ イナリファイルの差分を上書きする必要がある(日本語メニューが不要であイナリファイルの差分を上書きする必要がある(日本語メニューが不要であ れば、日本語版は不要)れば、日本語版は不要)  インストール手順、ダウンロード先、および使い方については以下のサイトインストール手順、ダウンロード先、および使い方については以下のサイト が詳しいが詳しい http://www.netlab.is.tsukuba.ac.jp/~one/ssh/http://www.netlab.is.tsukuba.ac.jp/~one/ssh/  特徴特徴  SSH1(RSA)SSH1(RSA) にのみ対応にのみ対応  安定した日本語環境安定した日本語環境  開発、メインテナンスはすでに終了開発、メインテナンスはすでに終了  右のように右のように UTF-8UTF-8 対応、対応、 ssh2ssh2 対応も有志の方により対応も有志の方により    進んでいます。   進んでいます。  UTF-8UTF-8 はは Fedora CoreFedora Core 以降が標準コードに採用以降が標準コードに採用 ・最近、 ssh2 対応などの拡張 をしようというプロジェクトが できました。対応するサイトは 、 http://www.ayera.com/teraterm で TeraTERM 3.1.3 が公開されて います。日本語版はまだない模 様。 ・ ttssh で UTF-8 をサポートす るプロジェクトもあります ・最近、 ssh2 対応などの拡張 をしようというプロジェクトが できました。対応するサイトは 、 http://www.ayera.com/teraterm で TeraTERM 3.1.3 が公開されて います。日本語版はまだない模 様。 ・ ttssh で UTF-8 をサポートす るプロジェクトもあります (ssh2 対応含む ) 。
  • 61. Copyright 2004,2007 © Kensuke Nezu, All61 サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (3)(3) ~~ Poderosa(Poderosa( ポデローサ)ポデローサ)  日本語の扱いや日本語の扱いや WindowsWindows プログラムとしての安定性に特徴があります。プログラムとしての安定性に特徴があります。  純粋な、純粋な、 .NET Framework.NET Framework を使用したアプリケーションです。を使用したアプリケーションです。  タブ式タブ式 GUIGUI 、、 SSH2SSH2 をサポートしているオープンソースのをサポートしているオープンソースの WindowsWindows 用ターミ用ターミ ナルエミュレータ。ナルエミュレータ。  インストール手順、ダウンロード先、および使い方については以下のサイトインストール手順、ダウンロード先、および使い方については以下のサイト が詳しいが詳しい http://ja.poderosa.org/http://ja.poderosa.org/  特徴特徴  SSH1,SSH2SSH1,SSH2 に対応に対応  .NET Framework.NET Framework 対応言語でマクロを記述可能対応言語でマクロを記述可能  ローカルのローカルの CygwinCygwin やや SFU(Services for UNIX)SFU(Services for UNIX) に対応に対応  タブ式ウィンドウ画面タブ式ウィンドウ画面  SSH2SSH2 ポートフォワードツール、ポートフォワードツール、 SSHSSH 鍵作成ウィザード、鍵作成ウィザード、 SOCKSSOCKS 対対 応、応、 IPv6IPv6 対応など多くのサポート機能、ツールがある対応など多くのサポート機能、ツールがある
  • 62. Copyright 2004,2007 © Kensuke Nezu, All62 サーバー構築手順~最初のサーバー構築手順~最初の 11 手手 (4)(4) ~~ CentOSCentOS のサーバー側のサーバー側 sshdsshd の設定上の注意の設定上の注意  /etc/ssh/sshd_config/etc/ssh/sshd_config のパラメータのパラメータ PermitRootLogin noPermitRootLogin no root→ root→ での直接ログイン不可での直接ログイン不可 MaxAuthTries 1MaxAuthTries 1 1→ 1→ セッションの最大試行回数1セッションの最大試行回数1 回回 PasswordAuthentication no →PasswordAuthentication no → 生パスワードでの認証不可生パスワードでの認証不可 GSSAPIAuthentication no GSSAPI→GSSAPIAuthentication no GSSAPI→ 認証不可認証不可  etc/hosts.allowetc/hosts.allow のパラメータのパラメータ sshd:[sshd:[ 自サイトのネットワークアドレス自サイトのネットワークアドレス ]/[]/[ ネットマスネットマス クク ]] sshd: .jp*sshd: .jp* ほとんどのイリーガルアクセスを防止 可能
  • 63. Copyright 2004,2007 © Kensuke Nezu, All63 SSHSSH の裏まで知りたいあなたに・・の裏まで知りたいあなたに・・ ・・ ~優良推薦図書~~優良推薦図書~ 「実用「実用 SSHSSH 第第 22 版版 -- セキュアシェル徹底活用ガセキュアシェル徹底活用ガ イド」イド」 http://www.oreilly.co.jp/books/4873112877/http://www.oreilly.co.jp/books/4873112877/  細かな使い方や設定方法が書かれています細かな使い方や設定方法が書かれています 。。  新しい使い方のヒントが載っています。新しい使い方のヒントが載っています。  コンパイル時のオプションコンパイル時のオプション  サーバ全体のオプションサーバ全体のオプション  各ユーザが利用可能なオプション各ユーザが利用可能なオプション  ftpftp をを SSHSSH に通すに通す  鍵の種類で利用できる機能を制限鍵の種類で利用できる機能を制限
  • 64. Copyright 2004,2007 © Kensuke Nezu, All64 実習2:ssh環境を構築しよう!実習2:ssh環境を構築しよう! (( 11 5分)5分)  ここまでのsshの説明に従った設定を行います。ここまでのsshの説明に従った設定を行います。 /etc/ssh/sshd_config/etc/ssh/sshd_config ファイルはデフォルト(記述しなファイルはデフォルト(記述しな かった場合の動作)がかった場合の動作)が ## コメントとして書かれてコメントとして書かれて います。これと異なる部分だけ記述してやればOいます。これと異なる部分だけ記述してやればO Kです。Kです。  補助教材を参考に実習してください。補助教材を参考に実習してください。 ※※ なお、今回はCentOS自身のローカル接なお、今回はCentOS自身のローカル接 続をおこないます。時間が余った人続をおこないます。時間が余った人 は、は、 PoderosaPoderosa でのリモートログインもチャレでのリモートログインもチャレ ンジしてみてください。ンジしてみてください。
  • 65. Copyright 2004,2007 © Kensuke Nezu, All65 サーバー構築手順~サーバー構築手順~ sudosudo の利用の利用 (1)(1) ~~ sudoでsudoで rootroot になれるユーザを限定するになれるユーザを限定する  歴史的理由により /etc/sudoers ファイルで wheel グループに属している ユーザに root になれる権限を設定します  root になってもよいユーザを vigr コマンドで wheel グループに登録しま す  登録されたユーザは、ユーザ毎のパスワードで root になれます  sudo で指定したコマンドや権限のないユーザの sudo の試みは syslog に記 録されます ローカルマシンの一般ユーザのローカルマシンの一般ユーザの rootroot 権限奪取の防止権限奪取の防止 コマンド毎やユーザをグル ープ毎にして、細かく制御 も可能 コマンド毎やユーザをグル ープ毎にして、細かく制御 も可能
  • 66. Copyright 2004,2007 © Kensuke Nezu, All66 サーバー構築手順~サーバー構築手順~ sudosudo の利用の利用 (2)(2) ~~ root::0:rootroot::0:root bin::1:root,daemon,majordomo,majbin::1:root,daemon,majordomo,maj ordomoordomo daemon::2:root,daemondaemon::2:root,daemon sys::3:root,admsys::3:root,adm adm::4:root,adm,daemonadm::4:root,adm,daemon tty::5:tty::5: disk::6:rootdisk::6:root lp::7:daemon,lplp::7:daemon,lp mem::8:mem::8: kmem::9:kmem::9: wheel::10:root,suzuki,tanaka,itowheel::10:root,suzuki,tanaka,ito mail::12:mail,binmail::12:mail,bin …… /etc/group vigr で編集しないとシャ ドウパスワードファイル が更新されない vigr で編集しないとシャ ドウパスワードファイル が更新されない ## # This file MUST be edited with the 'visudo' command as# This file MUST be edited with the 'visudo' command as root.root. ## # See the sudoers man page for the details on how to write# See the sudoers man page for the details on how to write a sudoers file.a sudoers file. ## # Host alias specification# Host alias specification # User alias specification# User alias specification # Cmnd alias specification# Cmnd alias specification # User privilege specification# User privilege specification root ALL=(ALL) ALLroot ALL=(ALL) ALL %wheel ALL (ALL) ALL%wheel ALL (ALL) ALL /etc/sudoers ‘‘=’=’ がないがない !! visudo コマンドを使うと こういった文法エラーを チェックしてくれます visudo コマンドを使うと こういった文法エラーを チェックしてくれます
  • 67. Copyright 2004,2007 © Kensuke Nezu, All67 サーバー構築手順~サーバー構築手順~ sudosudo の応用例~の応用例~ ## ホストエイリアスの指定ホストエイリアスの指定 Host_Alias DMZ = *.famm.ne.jp, aaa.bbb.ccc.ddd/255.255.255.240Host_Alias DMZ = *.famm.ne.jp, aaa.bbb.ccc.ddd/255.255.255.240 ## ユーザ名エイリアスの指定ユーザ名エイリアスの指定 User_Alias OPERATOR = suzuki, hayashi, itohUser_Alias OPERATOR = suzuki, hayashi, itoh ## コマンドエイリアスの指定コマンドエイリアスの指定 Cmnd_Alias OPERATION = /etc/rc.d/init.d/* restart, /usr/sbin/useraddCmnd_Alias OPERATION = /etc/rc.d/init.d/* restart, /usr/sbin/useradd ## 特権ユーザの指定特権ユーザの指定 root ALL = (ALL) ALLroot ALL = (ALL) ALL %wheel ALL = (ALL) ALL%wheel ALL = (ALL) ALL # OPERATOR# OPERATOR に属する管理者はメインテナンス用にに属する管理者はメインテナンス用に OPERATIONOPERATION で定義したコマンドで定義したコマンド だけ実行可能だけ実行可能 OPERATOR DMZ = (root) OPERATIONOPERATOR DMZ = (root) OPERATION /etc/sudoers ワイルドカード指定でワイルドカード指定で きますきます 引数を指定するこ引数を指定するこ ともできますともできます 実行コマンド例: 1. sudo –u root /etc/rc.d/init.d/httpd restart 2. sudo –u root /usr/sbin/useradd –m milky 実行コマンド例: 1. sudo –u root /etc/rc.d/init.d/httpd restart 2. sudo –u root /usr/sbin/useradd –m milky セキュリティ的には・・・: 1. 応用例は、よりセキュア。 2. root だけでは、ちょっといまひとつ・・・ 。 セキュリティ的には・・・: 1. 応用例は、よりセキュア。 2. root だけでは、ちょっといまひとつ・・・ 。
  • 68. Copyright 2004,2007 © Kensuke Nezu, All68 実習3:sudoを体感する(1実習3:sudoを体感する(1 0分)0分)  前ページの設定を行い、実行例がきちんと前ページの設定を行い、実行例がきちんと できることを確認してください。できることを確認してください。  このとき、このとき、 syslogsyslog に出て来るメッセージも確認に出て来るメッセージも確認 します。します。  実行権限のないユーザが実行しようとして実行権限のないユーザが実行しようとして 跳ねられることを確認してください。跳ねられることを確認してください。  このとき、このとき、 syslogsyslog に出て来るメッセージも確認に出て来るメッセージも確認 します。します。  次に、特定のユーザだけシステムのリブー次に、特定のユーザだけシステムのリブー トを可能にする設定を考えてみてくださいトを可能にする設定を考えてみてください 。。
  • 69. Copyright 2004,2007 © Kensuke Nezu, All69 サーバー構築手順~サーバー構築手順~ inetdinetd の設定の設定 (1)(1) ~~ inetdinetd 本体の設定 本体の設定  /etc/inetd.conf/etc/inetd.conf  不必要なネットワークサービスは起動しない  デーモンモードで常時起動するものも書かない  TurboLinux では turboservice, RedHat Linux では ntsysv でも 設定可能  最低必要なものは以下のようなものです ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a -d pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d imap stream tcp nowait root /usr/sbin/tcpd imapd
  • 70. Copyright 2004,2007 © Kensuke Nezu, All70 サーバー構築手順~サーバー構築手順~ inetdinetd の設定の設定 (2)(2) ~~ tcp_wrappertcp_wrapper の設定例  の設定例   /etc/hosts.allow/etc/hosts.allow in.ftpd :211.9.xx.xxx in.ftpd :61.9.xx.xxx/255.255.255.0 ipop2d,ipop3d,imapd,in.ftpd :.ykhm00.ap.so-net.ne.jp ipop2d,ipop3d,imapd,in.ftpd :.iwate.ppp.infoweb.ne.jp sshd : .samba.gr.jp sshd : .jp ALL : ALL : spawn (/usr/sbin/safe_finger –l @%h | /bin/mail –s %s-%h alert ) & : deny 1度アクセスし てもらいエラー ログから判断す る 1度アクセスし てもらいエラー ログから判断す る 先方のログイン ユーザを調べて メール 先方のログイン ユーザを調べて メール
  • 71. Copyright 2004,2007 © Kensuke Nezu, All71 サーバー構築手順~サーバー構築手順~ xinetdxinetd の設定の設定 (1)(1) ~~ chkconfigchkconfig による設定による設定  起動するサービスとアクセス制限内容は inetd.conf + tcp_wrapper とおなじ  turboservice/ntsysv でも設定可能  設定するコマンド /sbin/chkconfig --level 345 ftp on /sbin/chkconfig --level 345 pop3 on /sbin/chkconfig --level 345 pop2 on /sbin/chkconfig --level 345 imap on  chkconfig --list で必要なサービスのみ上っていることを確認
  • 72. Copyright 2004,2007 © Kensuke Nezu, All72 サーバー構築手順~サーバー構築手順~ xinetdxinetd の設定の設定 (2)(2) ~~ サービス毎のアクセス制限 サービス毎のアクセス制限  /etc/xinetd.d/ftp/etc/xinetd.d/ftp のの 例例  only_from = パラメータで指定する service ftp { disable = no only_from = 211.9.xx.xxx only_from = 61.9.xx.xxx/255.255.255.yyy only_from = 210.9.xx.0 only_from = .iwate.ppp.infoweb.ne.jp ….. log_on_failure += USERID }
  • 73. Copyright 2004,2007 © Kensuke Nezu, All73 サーバー構築手順~起動サービスの設定サーバー構築手順~起動サービスの設定 (1)(1) ~~ ntsysv/turboservicentsysv/turboservice による設定による設定  redhat-config-services/system-config-services は RedHat 系、 turboservice は TurboLinux
  • 74. Copyright 2004,2007 © Kensuke Nezu, All74 サーバー構築手順~起動サービスの設定サーバー構築手順~起動サービスの設定 (2)(2) ~~ 自動起動させるサービスの例自動起動させるサービスの例  apmd/acpidapmd/acpid  atd/crond/anacronatd/crond/anacron  random/httpd(Webrandom/httpd(Web サービスをするならサービスをするなら ))  inet/network/inetd/xinetd  ipchains(2.2 系 )/iptables(2.4 系 )  iplog/syslog  keytable  irqbalance  rawdevices  kudzu/readahead/readahead_early/rhnsd/yum (RedHat Linux 等 )  named(DNS を動かすなら)  portmapportmap  sendmailsendmail(MTA(MTA にに sendmailsendmail を使うならを使うなら ))  snmpd(mrtgsnmpd(mrtg 等を使うなら等を使うなら ))  sshd  smartd  xntpd(ntpd を使うなら )
  • 75. Copyright 2004,2007 © Kensuke Nezu, All75 サーバー構築手順~サーバー構築手順~ DNS(1)DNS(1) ~~ ネームサーバーの設定ネームサーバーの設定  セカンダリネームサーバ以外には情報の転送を不許可にするセカンダリネームサーバ以外には情報の転送を不許可にする  /etc/named.conf/etc/named.conf で、で、 allow-transfer { IPallow-transfer { IP アドレスアドレス 1 ; //1 ; // 転送を許可するセカンダリネームサーバ転送を許可するセカンダリネームサーバ 11 IPIP アドレスアドレス 2 ; // // 22 ; // // 2 …… };};  バージョンチェックできないようにするバージョンチェックできないようにする (( バグバージョンを探す攻バグバージョンを探す攻 撃防止撃防止 ))  /etc/named.conf/etc/named.conf で、で、 zone bind” chaos { allow-query { localhost; }; // localhost“zone bind” chaos { allow-query { localhost; }; // localhost“ からしか許さないからしか許さない type master;type master; file bind”;“file bind”;“ };}; Bind 9.x では不必要 ! Bind 9.x では不必要 !
  • 76. Copyright 2004,2007 © Kensuke Nezu, All76 サーバー構築手順~サーバー構築手順~ DNS(2)DNS(2) ~~ ネームサーバーの設定ネームサーバーの設定 (( つづき)つづき)  /var/named/bind (/var/named/bind ( 標準)で、標準)で、 $origin bind.$origin bind. @ 1d chaos soa localhost. root.localhost. (@ 1d chaos soa localhost. root.localhost. ( 1 ; serial1 ; serial 3H ; refresh3H ; refresh 1H ; retry1H ; retry 1W ; expiry1W ; expiry 1D ) ; minimum1D ) ; minimum chaos ns localhost.chaos ns localhost. chaos A 127.0.0.1chaos A 127.0.0.1 [ チェック方法 ] $nslookup –class=chaos –query=txt localhost version.bind( 実際は1行 ) Server: localhost Address: 127.0.0.1 VERSION.BIND text = 8.2.3-REL”“
  • 77. Copyright 2004,2007 © Kensuke Nezu, All77 実習4:実習4: CentOSCentOS でのでの version.bindversion.bind の有効の有効 性を調べてください性を調べてください (( 5分5分 ))  前ページのような前ページのような chaoschaos クラスを利用した脆クラスを利用した脆 弱性の発見方法がCentOSで有効かど弱性の発見方法がCentOSで有効かど うかを調べてください。うかを調べてください。
  • 78. Copyright 2004,2007 © Kensuke Nezu, All78 サーバー構築手順~メールサーサーバー構築手順~メールサー バ~バ~ オープンリレー(オープンリレー( OpenRelay)OpenRelay) しないようしないよう に注意に注意  Sendmail 8Sendmail 8 系以降、系以降、 qmailqmail 、、 postfixpostfix ではリレーしないではリレーしない のが基本のが基本 -しかし、設定を誤るとオープンリレーになってしまう-しかし、設定を誤るとオープンリレーになってしまう 。。  2004/072004/07 で2台のサーバーで観測すると、オープで2台のサーバーで観測すると、オープ ンリレーチェックのメールサーバーアクセスがンリレーチェックのメールサーバーアクセスが 5757 回回 /109/109 回回  telnettelnet でも手軽にチェックできるので、設定を変でも手軽にチェックできるので、設定を変 更するたびにチェックしよう更するたびにチェックしよう 
  • 79. Copyright 2004,2007 © Kensuke Nezu, All79 サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (1)(1) ~~ FTPFTP サービスとサービスと WebDAVWebDAV  よりセキュアなのはよりセキュアなのは WebDAVWebDAV  FTPFTP ではシステムにアカウントが必要、ではシステムにアカウントが必要、 WebDAVWebDAV は不要は不要  システム中のアクセスできるファイルエリアを制御しやすいのはシステム中のアクセスできるファイルエリアを制御しやすいのは WebDAVWebDAV 。。 FTP(wuFTPD, proftpdFTP(wuFTPD, proftpd 等)ではユーザ毎の等)ではユーザ毎の chrootchroot 環境が必要で、これを環境が必要で、これを 構築、維持、運用構築、維持、運用 (( ユーザの追加など)するのは結構たいへんユーザの追加など)するのは結構たいへん  FTPFTP では認証に生パスワードが流れる。では認証に生パスワードが流れる。 WebDAVWebDAV はは BASICBASIC 認証でなく、認証でなく、 digestdigest 認証ならばパスワードは暗号化される認証ならばパスワードは暗号化される  WebDAVWebDAV は接続がは接続が [[ クライアントクライアント ] [→] [→ サーバー:サーバー: 80/TCP]80/TCP] に固定。に固定。 FTPFTP はモーはモー ドによってドによって [[ クライアントクライアント ] [←→] [←→ サーバサーバ ]] どちらの接続もありえるし、使用どちらの接続もありえるし、使用 ポートも流動的ポートも流動的 FTP はパケットフィ ルタリングしにくい FTP はパケットフィ ルタリングしにくい WindowsWindows のの WEBWEB フォフォ ルダ機能を実現するルダ機能を実現する ApacheApache のモジュールのモジュール
  • 80. Copyright 2004,2007 © Kensuke Nezu, All80 サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (2)(2) ~~ サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (2)(2) ~~ FTPFTP サービスサービス (( 通常モード)通常モード) [ 制御コネクション ]Ftp クライアント (1024 ) Ftp サーバ (21) PORT 192,168,1,1,4,0 OK [ データコネクション ]Ftp クライアント (1024 ) Ftp サーバ (20) GET のデータ転送 4,0 は、 0x04, 0x00 で、 0x0400 、つ まり 1024 を示す 。 4,0 は、 0x04, 0x00 で、 0x0400 、つ まり 1024 を示す 。 接続の向き 20/TCP1024/TCP 接続の向き とポート番 号が問題
  • 81. Copyright 2004,2007 © Kensuke Nezu, All81 サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (3)(3) ~~ FTPFTP サービスサービス (PASV(PASV モード)モード) [ 制御コネクション ]Ftp クライアント (3000 ) Ftp サーバ (21) PASV OK(211,9,36,180,4,255) [ データコネクション ]Ftp クライアント (3001 ) Ftp サーバ (1279) GET のデータ転送 4,0 は、 0x04, 0xff で、 0x04ff 、 つまり 1279 を示 す。 4,0 は、 0x04, 0xff で、 0x04ff 、 つまり 1279 を示 す。 接続の向き 1279/TCP3001/TCP 接続の向き とポート番 号が問題
  • 82. Copyright 2004,2007 © Kensuke Nezu, All82 サーバー構築手順~ファイル転送サーバー構築手順~ファイル転送 (4)(4) ~~ WebDAVWebDAV の欠点もあるの欠点もある  あまり多くの日本語情報がないあまり多くの日本語情報がない  ApacheApache ではでは 2.02.0 系でないと標準モジュールでない系でないと標準モジュールでない  日本語を上手に使おうとすると非標準モジュール日本語を上手に使おうとすると非標準モジュール (mod_encoding)(mod_encoding) が必が必 要要  非標準モジュールがソースでしか配布されていない非標準モジュールがソースでしか配布されていない (RPM/de(RPM/de bがなbがな い)い)  クライアントによって挙動が違うことがあるクライアントによって挙動が違うことがある (Windows XP(Windows XP など)など) acheのacheの V.upV.up でバイナリが非互換になるとちょっと悲しいことにでバイナリが非互換になるとちょっと悲しいことに Apache のセキュリテ ィホール対策版の 1.3.26 など・・・ Apache のセキュリテ ィホール対策版の 1.3.26 など・・・
  • 83. Copyright 2004,2007 © Kensuke Nezu, All83 実習5:実習5: WebDAVWebDAV 環境を構築する(環境を構築する( 2020 分)分)  DAVDAV の設定を行ってください。ユーザ認証の設定を行ってください。ユーザ認証 はは BASICBASIC 認証で設定してください。認証で設定してください。  WindowsWindows のウェブブラウザから、のウェブブラウザから、 WebDAVWebDAV にに アクセスしてファイルが置けることを確認アクセスしてファイルが置けることを確認 してください。してください。  詳細は、補助資料を参考にしてください。詳細は、補助資料を参考にしてください。
  • 84. Copyright 2004,2007 © Kensuke Nezu, All84 サーバー構築手順~サーバー構築手順~ WWWWWW サービサービ ス~ス~ Apache設定のポイントApache設定のポイント (1)(1)  ApacheApache のバージョンを表示しないのバージョンを表示しない (httpd.conf)(httpd.conf) ServerSignatureServerSignature OffOff →→Apache 1.3Apache 1.3 以降。サーバが生成する以降。サーバが生成する (( エラーなどのエラーなどの )) ドキュメントドキュメント にバージョン等の付加情報をつけないにバージョン等の付加情報をつけない ServerTokensServerTokens              ProductOnlyProductOnly →→Apache 1.3.12Apache 1.3.12 以降。サーバレスポンスヘッダにバージョンや以降。サーバレスポンスヘッダにバージョンや プリコンパイルモジュールの情報を含めないプリコンパイルモジュールの情報を含めない Apache のセキュリテ ィホール対策版の 1.3.26 以前のセキュリ ティホールをつくワー ムが近いうちにきっと でてきます。 Apache のセキュリテ ィホール対策版の 1.3.26 以前のセキュリ ティホールをつくワー ムが近いうちにきっと でてきます。 Nimdaタイプの IP アドレス総なめタイプ かもしれませんが、バ ージョンをチェックす るタイプであればこの 防御は有効です。 Nimdaタイプの IP アドレス総なめタイプ かもしれませんが、バ ージョンをチェックす るタイプであればこの 防御は有効です。 設定していないと・・・: HTTP/1.1 200 OK Date: Thu, 27 Jun 2002 07:54:50 GMT Server: Apache/1.3.23 (TurboLinux) mod_throttle/3.1.2 PHP/4.1.2 Connection: close 設定してあると・・・: HTTP/1.1 200 OK Date: Thu, 27 Jun 2002 07:54:50 GMT Server: Apache Connection: close FreeBSDFreeBSD 版の版の ワームはでてワームはでて きてしまいまきてしまいま したした Slapper ワームがこの 機能を利用しています Slapper ワームがこの 機能を利用しています
  • 85. Copyright 2004,2007 © Kensuke Nezu, All85 実習6:実習6: apacheapache のセキュリティを設定のセキュリティを設定 してみる(してみる( 1010 分)分)  /etc/httpd/conf/httpd.conf/etc/httpd/conf/httpd.conf で、で、 ServerSignature On/Off/EmailServerSignature On/Off/Email ServerTokensServerTokens ProductOnly/Major/Minor/Minimal/OS/FullProductOnly/Major/Minor/Minimal/OS/Full と切り替えたときのレスポンスヘッダの違いを確と切り替えたときのレスポンスヘッダの違いを確 認してく認してく ださい。ださい。→変更したら、必ず再起動→変更したら、必ず再起動 (service httpd(service httpd restart )restart )  します。 します。  CentOSのデフォルトは、CentOSのデフォルトは、 ServerServer Tokens OS / ServerSignature OnTokens OS / ServerSignature On です。です。  確認方法は、端末窓から、確認方法は、端末窓から、 $ telnet localhost 80$ telnet localhost 80 適当な文字+リターン適当な文字+リターン
  • 86. Copyright 2004,2007 © Kensuke Nezu, All86 サーバー構築手順~サーバー構築手順~ WWWWWW サービサービ ス~ス~ Apache設定のポイントApache設定のポイント (2)(2)  BASICBASIC 認証を使わずにダイジェスト認証を使う認証を使わずにダイジェスト認証を使う  BASICBASIC 認証ではパスワードは認証ではパスワードは mimemime エンコードされているだけの状態でネッエンコードされているだけの状態でネッ トワークを流れているトワークを流れている  盗聴盗聴 (Sniffer)(Sniffer) して簡単に生のパスワードが得られますして簡単に生のパスワードが得られます  ダイジェスト認証は、ダイジェスト認証は、 MD5MD5 でハッシュ化されているのでほぼ安全でハッシュ化されているのでほぼ安全  Apache 1.xApache 1.x の標準モジュールでないの標準モジュールでない (experimental(experimental のの )mod_auth_digest)mod_auth_digest モジュールでサモジュールでサ ポートされているので手でコンパイルしてインストールしなければいけないポートされているので手でコンパイルしてインストールしなければいけない →→ Apache 2.xApache 2.x では標準モジュールになっていますでは標準モジュールになっています 電子メールの添付ファイ電子メールの添付ファイ ルの形式ルの形式 BASICBASIC 認証(認証( ApacheApache の標準パスワード形式)はセキュリティがないのと同の標準パスワード形式)はセキュリティがないのと同
  • 87. Copyright 2004,2007 © Kensuke Nezu, All87 サーバー構築手順~サーバー構築手順~ WWWWWW サービサービ ス~ス~ Apache設定のポイントApache設定のポイント (3)(3)  mod_auth_digestmod_auth_digest モジュールのインストール方法モジュールのインストール方法 1.1. ソースコードを取得、展開するソースコードを取得、展開する 2.2. cd apache_1.3.26/src/modules/experimentalcd apache_1.3.26/src/modules/experimental 3.3. /usr/bin/apxs –D DEV_RANDOM –c mod_auth_digest.c/usr/bin/apxs –D DEV_RANDOM –c mod_auth_digest.c でコンパイルでコンパイル 4.4. rootroot で、で、 /usr/bin/apxs –i mod_auth_digest.so/usr/bin/apxs –i mod_auth_digest.so でインストールでインストール 5.5. httpd.confhttpd.conf で、以下を追加するで、以下を追加する      LoadModule digest_auth_module /usr/libexec/apache/mod_auth_digest.soLoadModule digest_auth_module /usr/libexec/apache/mod_auth_digest.so      AddModule mod_auth_digest.cAddModule mod_auth_digest.c 6.6. パスワードの作成はパスワードの作成は htdigesthtdigest コマンドを使うコマンドを使う

Editor's Notes

  1. みなさんの周りには、サーバと呼ばれるコンピュータがないでしょうか? または、サーバと呼ばれるコンピュータを使っていないでしょうか? 実は、次に挙げるようなことは、すべてサーバコンピュータがなくては、実現できません。 ・ホームページを作る授業でホームページを作って公開した ・フリーで利用できるホームページのページを利用した ・ホームページをブラウザで見た ・フリーで取れるメールアドレスを取得した ・メールソフトウェアでプロバイダからメールを取り出した これらのすべてが、サーバコンピュータを使って何かをしたり、情報を取り出したりしています。 つまり、「インターネットの利用には、サーバはなくてはならないもの」なのです。 この講座では、このようなサーバコンピュータを自宅で立ち上げたり(お家サーバ)、クラブ活動でクラブで公開するホームページを入れたコンピュータを立ち上げたり、企業でホームページやメールを格納するサーバを立ち上げたり、そんな時に、ぜひ、覚えておいて欲しいことについてお話します。
  2. 本資料は、文部科学省、中央大学研究開発機構が主催する「UNIX/Linuxセキュリティ実践講座」の教材として根津 研介(nez@samba.gr.jp)が作成した資料です。 本資料は、著作権で保護されています。上記の例外を除いて、根津 研介による事前の許可なく、本資料のいかなる部分も無断転載、複製、複写を禁じます。 本資料に記載されている製品には、米国特許権、米国外での特許権または登録申請中の特許により保護されているものが含まれています。 商標 Linux は、Linus Torvalds の米国およびその他の国における登録商標あるいは商標です。 Red Hat は、米国及び全世界におけるRed Hat ,Inc.の登録商標、またRPMは、米国および全世界における Red Hat ,Inc の商標です。 UNIX は、The Open Group の登録商標です。 本書で参照されているその他すべての製品やサービスの名称は、それぞれの所有者の商標です。 文部科学省、中央大学研究開発機構、および、根津 研介のいずれも、本資料について、その記載内容に誤りがないこと、および特定の目的のために適合していることを一切保証するものではありません。従って、受講者が本資料を参考にしてアプリケーション・ソフトウェアを作成またはシステムを構築した場合であっても、作成されたアプリケーションまたは構築されたシステムに関して、文部科学省、中央大学研究開発機構、および、根津 研介は、いかなる責任も負うものではありません。 また、実習で使用されたいかなるサンプル・ファイルおよび環境は、航空機、航空交通官制、航空機の航行もしくは通信のオンライン制御システムでの使用、および核施設の設計、建設、稼動もしくは管理システムでの使用を目的として考案、製造されたものではありません。 実習で使用されたいかなるサンプル・ファイルおよび環境の提供者は、かかる目的への適合性についていかなる保証を行うものではありません。受講者は、かかる目的のために、実習で使用されたいかなるサンプル・ファイルおよび実習環境を自ら使用しないことおよび第三者に使用させないことを保証するものとします。 ※本資料には、デザインエクスチェンジ社のクリップアートを使用しています。
  3. まず、「インターネット」とはなんでしょうか? 次のページに進む前に5分間、考えてみてください。 これが、はっきりしないと、「サーバにはどういう危険が待って」いて、 なぜ「セキュリティ」が必要なのかがわからないからです。 ここでは、まず、インターネットの特質を明らかにした上で、サーバを 防衛するために必要な指針や、防御にどれだけの労力をかけるべきか のガイドライン、そして、サーバというコンピュータシステムが安全に サービスを提供するということはどういうことなのかについて順番に お話ししてゆきます。
  4. インターネットの長所と短所を挙げてみて下さい。 すぐに列挙することができるでしょうか? たとえば、ADSL等で自宅でインターネットに接続していたら、ある日思いついたら、ホームページを立ち上げることができます。そして、多くの人から有用だと評価されれば、世界中からアクセスして貰えるホームページだって作ることができます。これには、お金もほとんどかかりませんし、沢山の人がアクセスしてくれるようになれば、大手のポータルサイトにだって負けないくらい有名になれます。これに対して、本を出版して同じくらいの人たちの目に触れてもらうためにしなければならないことを考えてみてください。 このような手軽さが、インターネットの最大の利点です。 しかし、常に物事には2面性があり、この利点にはつぎのような暗黒面もあります。 あなたが作ったホームページやサーバで人に被害を与えてしまったり、あなたの書き込みが他の人の人権を著しく侵害してしまった場合には、それを事前にチェックして止めてくれる人はいません。公開してしまった責任や、他の人に損害を与えてしまった責任はあなた自身が取るしかないのです。 また、世界中からアクセスできるということは、サーバを立てた場合、地球の裏側から自分のサーバが攻撃されることもあり得ます。実際に、インターネットの画像掲示板がテロリストの連絡に使用されたり、不正侵入されたコンピュータを踏み台にして、NASAやFBI、CIAのサイトが攻撃されたりといったこともありえます。こういった事から、あなたを守ってくれるものは何もありません。
  5. すべての責任をあなた自身が負わなければならないことはすでに述べました。ここでは、例として、情報の公開が国家の安全保障に関わる場合について触れます。たかがホームページと侮ってはいけない実例です。 たとえばあなたがホームページで公開する情報が「特定技術」に該当してしまった場合を考えてみましょう。 ここでいう「特定技術」とは「国際的な平和及び安全の維持を妨げることとなると認められるものとして政令で定める特定の種類の貨物の設計、製造又は使用に係る技術」のことです。別途、政令で指定されている特定の地域においてこの「特定技術」を提供することを目的とする取引は、事前に経済産業大臣の許可を受けなければなりません。 このような情報には例えば高度暗号化技術やある種の科学技術系計算プログラムに関するもの、原子爆弾製造技術および転用可能な部品、情報、ソフトウェアなど、多くのものが該当してしまうのです。 このようなものに関する情報は、基本的に「特定技術」に該当すると考えた方が無難で、しかも、事前に経済産業大臣の許可無く、下記のページで挙げられている「輸出令別表第4の2に掲げる26カ国」の地域にアクセスを限定せずに、Web上で公開してしまったとしたら、「世界中に輸出」したものとみなされ、「外国為替法及び外国貿易管理法」違反として、重い処罰が科されます。 ※詳細は、財団法人安全保障貿易センターの以下のページを見て下さい。  我が国の安全保障輸出管理制度:  http://www.cistec.or.jp/open/info/lec/index.html ※例えば、最近の無線LAN製品の暗号化技術AESのアクセスポイントの設定画面部分もモザイクをかけなければ該当する可能性があります。
  6. 法律面の弱点についても、考えてみましょう。 現在のインターネットは、ある意味で、Global IPアドレスを持っている部分は「公海」です。この意味では、インターネットとの接続ポイントであるゲートウェイルータは、国際空港の役割を果たしています。行為者が国外で、国外からの不正アクセスというのは、現在の国内法ではほぼ処罰できないと考えていいでしょう(サイバー犯罪防止条約加盟国同士であれば処罰は可能)。  →行為者が国内で被害サーバも国内で、かつ、日本人であれば、犯罪行為が国内で実行されたものとみなし、積極的に処罰するのがトレンドになっています(判例もあります)。しかし、実際問題として、みなさんが運営するようなサーバの場合、刑事事件にできる案件(不正アクセス禁止法違反など)でなければ、損害賠償請求などの民事訴訟は起こしにくいと考えられます(損害金額を算定すると被害額があまりにも少ないため)。 訴訟が成立し、損害額が算定でき、勝訴する・・・ここまで行くには、インターネットでは非常に高い技術と労力が必要になるからです。まず、民事の訴訟が成立するためには「相手を特定」できなければなりません。ここが第一の関門です。次に、相手が属する国と日本国で罪刑がともに成立し、要件が成立することも確認しなければなりません。たとえば著作権法では、不法に作成された二次著作物(意匠を模倣したパロディ画等)の扱いについて、一次著作者に帰属するか(日本)、二次著作者に帰属するか(米国)で違いがあったりします。ここが第二の関門です。結局のところ、自分の身は自分で守るしかないのです。 また、サーバ運用管理者の責任は、「技術を知っている」ハズの人間は「より重く」なります。それは、一般の人以上に詳しいはずなので、より責任が重いと判断されるからです。情報セキュリティアドミニストレータ取得資格者やテクニカルエンジニア(情報セキュリティ)取得者、電気通信事業者が運営するサーバは、より高度の防衛に関する「注意義務」が要求されるものと考えられます。
  7. セキュリティは、いくらお金をかけて、いくら手間をかけても100%絶対ということがありません。 Who(誰)がWhere(どこ)にWhen(いつ)、Why(なぜ)、What(何)を求めて、How(どのように)セキュリティ破りを行おうとするのか?サーバのWhere(どこ)にWho(誰)が、What(何)の価値を見いだすのか?そして、その価値にはどれだけの守る価値があるのか? こういったことを、一つ一つ見ながら、その部分にかけてよいセキュリティ資源(個人サーバの場合は主に手間)を冷静に判断しなければならないのです。 身近な例で考えてみましょう。 たとえば、コンビニエンスストアのセキュリティを考えてみます。 そして、それを公開サーバのセキュリティに当てはめて考えてみて下さい。
  8. &amp;lt;number&amp;gt; セキュアサーバーを構築するには、守るべき資源を防御する「しくみ」を作り込むためにある程度の技術が必要になります。 また、継続的にセキュリティレベルを維持していくためには、それなりの手間が継続的にかかってしまいます。 このことに関して、取ることのできる戦略は以下のようになります。 ・必要最小限の手間で、最大効果が得られるポイントはどこか? ・そのレベルで実現できるセキュリティの「しくみ」はどの程度の防御レベルか? ・サーバ自体の価値や、サービスの価値は、その「得られる防御レベル」で  十分に釣り合うものか? これらのバランスが悪いと、「手間ばかりかかって実は守るものが大してない」等ということや、逆に「重要なデータが入っている非常に価値の高いサーバなのに何も防御されていない」等ということが起きてしまいます。 つまり、一番重要なのは、この「適正なセキュリティのバランス感覚」なのです。 たとえば、自分だけで構築するにはあまりにも重要なデータ(個人情報など)がサーバに保存されるのであれば、別の十分にセキュアなコンピュータへそのデータを(インターネットを通さないで)転送することを検討したり、そもそもそのようなデータを取る必要があるのかどうかを疑ってみましょう。このような対策を取ることでサーバの価値を下げることができるかもしれないからです。データ取得が本当に必要な場合には、個人情報保護法に則した管理コストも計上しなければなりません。
  9. &amp;lt;number&amp;gt; 大抵の場合、セキュリティに関する価値は、自分にとっての価値ではなく、「相手にとっての価値」が大変重要になります。 これは、例えば「個人情報」などを考えるとよくわかることです。企業が個人情報を漏洩してしまうのは、往々にして、根底に「こんな情報は価値はない」という「思いこみ」があることが多いようです。しかし、実は、立場を変えて見てみると、貴重な情報として捉える立場の人もいるはずなのです。 これは例えば、セキュリティイベントに参加した人のメールアドレス一覧があったとして、主宰者側から見れば単なる連絡用リストでしか無かったものが、見る立場が変わることで「宝の山」になる場合があることを考えればよくわかります。たとえばこのリストは、セキュリティ装置を販売する業者から見たときには重要な優先営業先リストになりますし、また、公安関係者から見たときには「電子犯罪予備軍リスト」と見えるかも知れないのです。 サーバ自身の価値も同じです。 個人サーバの場合、往々にして「何の価値もない」と考えることが多いのですが、不正利用しようとする立場から見て、自分のサーバにどれだけの価値を見いだせるか?ということを考えることは、大変に重要です。 たとえば、あなたが界隈では結構有名なヒット数もそれなりにあるウェブページを掲載しているサーバを運用していたり、何らかの形で目立つことを行っていたりした場合、それだけであなたのサーバが狙われる価値が上がってしまうこともあり得ます。ウェブページ上に自動的にダウンロードされるスパイウェアなどを忍ばせておくためだけでも十分な価値があるからです。
  10. サーバを運用するというのは、本来、大変に手間のかかる「はず」のものです。 通常、自分でサーバを立ち上げようと思うと、ハードウェアの購入資金やインストールの手間、ネットワーク回線の手配と接続機器といったようなものに目を奪われがちです。 しかし、それは「構築」という1つのフェーズについての費用にすぎません。 ドメインを取って、運用を開始してから、サーバが役目を終えて引退するまでの間、延々と「セキュリティ対策」と「日常監視」の日々が続きます。 しかも、本来の目的は、大抵、   ・ホームページを公開したい   ・メールサーバを上げたい(メールを蓄積できるようにしたい)   ・独自のドメインを取って、特殊なゲーム環境(箱庭諸島など)を持ちたい 等であって、「サーバのお守り係」になることではないでしょう。 しかし、実際には、サーバのライフサイクルで計算すると、「サーバのお守り」にかかる時間がいちばん長く、時には辛いことがわかるでしょう。 そして、いつか、段々と手を抜くようになり、「どうせ誰もこんなサーバなんて・・・」と思い始めたころに、黒い影が忍び込んでくるのです。 そうならないようにするためにも、人間の労力を介さずに監視できるしくみを「いかに沢山作り込んでおくか」が重要になります。
  11. サーバとはどういうものでしょうか? それは、「サービスを提供するシステム」のことです。 この観点から、サーバには、   ・いつでも安定したサービスを、   ・できるだけ長い時間止まらずに、また、とまっても最短時間で戻り、   ・しかも、誰でも簡単にメンテ作業できるようになっていること が要求されます。 これらのどれかが考慮されていなかったり、欠けていたりすると、 そのサーバシステムの信頼性は失われてしまいます。 インターネット接続がその日の気分でつながったり、つながらなかったりすることを想像してみてください。また、いつ復旧するか分からない停電についても、まっくらな中で考えを巡らせてみてください。 RASの重要性について、きっと、合点がいくに違いありません。 
  12. セキュリティも一つのサービスと見ることができます。 このサービスの善し悪しを論じるには、次の3点で評価します。  ・機密性: 情報にアクセス権限のある人だけがアクセスできて、権限の         ない人にはアクセスできないこと。ここで云う情報には、例えば         共用しているサーバで他の利用者が何をしているか等も含みます。  ・完全性: 情報が常に完全な状態であることを保証できること。これは、         つまり書き換える権限のない人の書換えがちゃんとできない         ことや、削除できないファイルは削除できないように強制でき         ること等が含まれます。  ・可用性: 情報へのアクセスが、上記の条件を満たしている限り、利用者         が欲するときにはいつでもアクセスできるようにすること。 これも、それぞれの「情報」に対して、5W1Hを明確なルールにしておき、このルールに従った「情報へのアクセス」だけが行われるようにしようというものです。 これは、缶詰めなどの食品で「中身がちゃんと食べられるもの」であることを確実にするための方法論に似ています。情報セキュリティマネジメントサービスでは、「中身」が「情報」ということになります。
  13. このように見てくると、サーバに求められるものは、おおよそ次のようなことであることがわかります。 ・いつでも安定してサービスを提供していること。 ・ユーザが使いたい時にいつでも使える状態にしておくこと。 ・「中身」である情報が正しいこと。 ・「自分の行動」という情報が漏れないこと。 ・誰でも簡単に保守できること。 そして、このような目標を阻害する外的な要因として、セキュリティ上の問題点(不正アクセスやサーバの脆弱性など)を捉えることができると言えます。 つまり、大ざっぱに言ってしまえば、セキュリティ上の問題というのは、サーバを管理する側から見ると、ハードディスクの故障とそれほど違いはないことになります。 ※ただし、その結果としての副作用に大きな違いがでます。これは、セキュリティ上の問題点の場合、起きてしまう事象に付随して引き起こされる、「情報の漏洩」や「他のシステム/財産への侵害」といったものが、ハードディスクの故障にはないからです。
  14. 「セキュリティ」という意味を、英和辞典でひいて、どういう意味があるか調べて見て下さい。 日本では、「コンピュータセキュリティ」という場合、「防御手段、警備、防護、保全、保安」という意味をもって「セキュリティ」という用語を使う場合が多いのですが、本来の「セキュリティ」には、以下のような使い方があるのです。 ・日米安全保障条約(Treaty of mutual cooperation and security between Japan and the United States of America) また、「セキュリティ」は、「無事」や「安心」という意味にも使われます。 さて、このように見てくると、「ハードディスクの故障」に対する備えがなければ、安心して枕を高くして寝ているわけにもいかないのですから、「安心=セキュリティ」のためには、ハードディスクのバックアップを取っておくというのも重要なセキュリティ対策の一環と言えるのではないでしょうか? セキュリティとは、何も難しい特別な事を要求している訳ではないのです。ごく普通に、枕を高くして、夜中にたたき起こされることなく、安心してサーバを運用できるようにしようとすることだと言えます。
  15. このようにして見てくると、サーバのメインテナンスという作業も立派なセキュリティ対策だということがわかってきます。 システムの定期的なバックアップは、ハードディスクの故障への対策にもなれば、悪意あるプログラムや人による不正侵入による情報破壊への対策にもなります。 そして、ハードディスクの故障の徴候はシステムのログにハードディスクの読み出しエラーやシークエラーとして記録されますし、不正侵入の徴候はサーバへの異常なポートスキャンなどがシステムのログに記録されます。 普段からシステムの状態を知っていれば、システムの異常を検知しやすいというのも、ハード故障と不正侵入で同じことが言えます。 また、普段からの予防保守(=ハードディスクのバックアップなど)をしておけば、ハードの障害や、セキュリティ上の障害が発生した時にもすばやく復旧することができるという点も同じです。 ※ただし、すでに述べたように、セキュリティ上の問題では、さらに「他者への侵害」、「情報盗難」という問題が追加して検討しなければならないという点が大きく異なることだけは注意しなければなりません。
  16. 今までの論点をまとめてみると、サーバ運用には、  ・まめな人でないとだめ  ・沢山時間があって、いつもサーバを気遣って監視できないとだめ  ・さまざまな最新の情報をいつでも知っていないとだめ と言っているように聞こえたかも知れません。 しかし、せっかくコンピュータを使うのです。 コンピュータに任せられるところは極力コンピュータに任せてしまいましょう。 つまり、日常の運用管理のうち、コンピュータが得意な「自動化」に向いている部分を切り出して、コンピュータ自身にやらせるようにすることで、人間が関与しなければならないことを減らせばよいのです。 こうすることで、いつかは面倒くさくなってやらなくなってしまうという事も防止することができます。 日常のサーバ運営管理について、考えなければならない側面は、以下のものがあります。それぞれについて検討し、自動化に向いているかどうかを考えてみましょう。 ・通常監視 ・情報収集 ・予防保守 ・緊急対策
  17. ・通常監視  日常的に監視する目的はなんでしょうか?   1.サーバが動いていることを確認する   2.サービスが動いていることを確認する   3.インシデントが発生していないかを確認する  ちょっと考えれば、このようなことが出てくるでしょう。  しかし、実は、   4.通常の状態がどういうものかを把握する  ということも通常監視に含まれる非常に重要な役割です。  たとえば、現在のインターネットではウィルスに冒されたコンピュータからのポートスキャンはもはや日常的です。これらのポートスキャンの総数や傾向をきちんと把握していれば、そのようなポートスキャンに紛れて、怪しい目的でポートスキャンを行おうとしている行動を検出しやすくなります。  また、たとえば「CATV接続インターネット等で、ルータを購入したらルータのセキュリティログに“UDP/137….”等のログが異常に出るのですが、攻撃されているのでしょうか?」というのも日常的に監視していれば、何らかの理由があって、バックグラウンドノイズのように流れているということが分かるはずです。  このように、通常の状態を知っておくことで初めて異常状態を検出 (Anomaly Detection)することが可能になるのです。
  18. &amp;lt;number&amp;gt; 情報収集について考えてみましょう。 情報収集では、各種のニュースソースや、マイクロソフトのセキュリティサイトなど、様々な情報源から、自分が運営しているサーバへの影響度などを計算し、緊急性を判断し、そして、必要ならパッチを当てるなどの対策を考えたり、パッチを当てるタイミング(たとえば、一番アクセスの少ない午前4時に当てよう・・・等)を決定するまでの一連の作業と高度な判断が求められます。 ※これが、作業を自動化できない所以です。何でもかんでもパッチを当て   れば良いというものではないからです。場合によっては、パッチをあてる   ことで動かなくなってしまうこともあります。 このような状況での情報収集ですが、やはりブラウザを使ったコンテンツへのアクセスはクリックとはいえ、自分が能動的に動くという点で、やはりワンクッションあるようです。これをプル型コンテンツと呼びます。 これに対して、メールニュースの場合、手元に勝手に配信してくれるという意味で、手元まで情報が配信されてくるということで、自分が受動的になれるという意味で、このような情報をプッシュ型コンテンツと呼んでいます。 どちらもそう変わりは無いように思われるかもしれませんが、長く継続的に行うことが苦痛でないのはプッシュ型のコンテンツのようです。
  19. &amp;lt;number&amp;gt; メーリングリストも「生きた」プッシュ型コンテンツです。 ニュースにはならないようなポートスキャンの傾向などがLIVEで流れ、より現実性を帯びて手元に情報が届きます。 また、プッシュ型のメールニュースなどで情報の山の中に埋もれてしまっている「見逃してしまった情報」について、指摘してくれる場合もあります。 ただし、メーリングリスト自体は、受動的なコンテンツではなく、参加することが強く要請されるものです。 学生の場合、セキュリティパッチなどを積極的に当てる「人身御供」になった結果などの報告が、重要な貢献になる場合も多いと思いますので、積極的に貢献していきましょう。 業務で使用されているシステムの場合、当ててしまったことによる影響、特に、事業を継続していく上での損害が、秤にかけることができないシステムが多いので、なかなかこういうものを積極的に、素早くあてたり、実験環境を構築して当てたりするコストが捻出できないケースがあります。 そういう人たちに対して、学生であるあなた方が貢献できる部分は大きいのです。
  20. &amp;lt;number&amp;gt; 情報収集では、受動的な受信だけではどうにもならないこともあります。 プッシュ型に比べると、インターネットにアクセスするという手間がかかる分、プル型の作業は大変な作業になりますが、実際上は、メールニュースでは概要しか書かれておらず、具体的に内容を検討した方がよいと思われる場合などに、ホームページの情報を検索しなければならないことがあります。特に、概要など不明なエリアの知識を吸収しようとして検索サイトで検索を行うようなケースもあるでしょう。 この場合、関連しそうなキーワードの組み合わせをいくつも試しながら、本当に欲しい情報を検索で絞り込んでいくというのもサーバ管理者には要求される「技術」です。 いずれにしても、この情報収集では、「いかに時間をかけずに、効率よく、探したい情報を収集するか?」という技術に長けているかがものをいいます。 また、何かの徴候を見つけたときに他のトレンドと比較すると異常検知がしやすくなる場合もあります。このようなトレンド(定点観測)を行い情報を公開しているところとしては、以下が有名です。 ・SANS Internet Storm Center ( http://isc.incidents.org/ ) ・WCLSCAN ( http://www.wclscan.org ) (日本語サイト) これらのサイトは、各種のポートスキャン等の傾向を見るのに大変に役立ちます。 特にWCLSCANは、日本国内にセンサを設置して解析していたり、携帯電話からアクセスできる状況通知サイトがある等の利点があります。 iモード顔アイコン版: http://www.wclscan.org/iwr/i.html Ezweb顔アイコン版: http://www.wclscan.org/iwr/f.html
  21. &amp;lt;number&amp;gt; 個人サーバや学校のクラブ活動などのコミュニティサーバで、セキュリティポリシーを決定する必要性について考えてみましょう。 「昨日の自分は赤の他人」とも言います。ある時点で決めたルールを記録しておくことは、赤の他人になってしまった未来の自分へのメッセージとして必要だということは真実です。 また、サーバが破壊してしまったような事態になったときに、元の形にもどすためにも、「前回行ったこと」ができる限り文書化されている必要があります。 これによって、毎回、サーバを構築しなければならないたびに、同じ品質の同じセキュリティポリシーに従ったサーバが、自分で、もしくは、他人に頼んでも出来上がることを確実にすることができます。 このようなルーチンワークは、大抵、忘れた頃にやってきます。ハードディスクのトラブルや全損などがこの忘れた頃にやってくる事象としてはもっとも有力なものです(セキュリティホールをつかれてサーバがやられるよりも、ハードディスクの故障でシステム障害になる可能性の方が高いでしょう)。 そして、忘れた頃にやってくるメジャーバージョンアップも、このようなドキュメントがあれば、ある程度、「怖いものなし」で行うことができるようになるのです。 おまけに、万に一つ、あなたの管理するサーバが侵略されてしまったときに、「サーバがどのように管理されていたか」を唯一つ証明することができる証拠になる可能性もあります。
  22. 次に企業サーバでセキュリティポリシーを決定する必要性も考えてみましょう。 個人サーバと同様の部分もありますが、それに加えて、企業サーバの場合、担当者が複数いたり、緊急時に担当者に替わって別の人間が作業できるようにしておかなければならないといった事情があります。このために、個人サーバで行うより、より第三者にわかりやすい作業手順書が必要になります。 サーバーポリシーを作成しておくことで、全社的なセキュリティポリシーとの整合性を確保することも可能になります。社内からのサーバー利用や、複数人で作業する場合のセキュリティについての意識の統一を図ることもできるでしょう。このことにより、マニュアル化されていない不測の事態が起きた場合でもポリシーに鑑みて適切な対応をすることが期待できます。 社外的な事情もあります。サーバーで個人情報などの提供を受ける場合などに、どのようなセキュリティポリシーでサーバーを運用しているかを明確にすることは大変に重要なことであり、現代の企業サーバーではもはや当然の要請になります。 最後に、個人サーバーと同じ項目ですが、より重要な意味を持ってくるものに「証拠保全」の能力の問題があります。企業サーバーの場合、サーバーにより損害を受けた側は、企業が補償するものとして、巨額の民事訴訟を起こされる可能性があります。この場合に、サーバー運用側として「善意の管理者」としての義務を怠っていなかったことを証明しなければなりません。このために、個人サーバー以上に厳密にサーバー管理をしておく必要があるのです。たとえば、作業を複数人で行い証拠となる記録(写真など)を作業者以外の人がとっておくなどです。作業のメモも複数人でとっておき、相互に確認して署名するなども有効でしょう。
  23. &amp;lt;number&amp;gt; 運用している間、サーバはウィルスの被害や、脆弱性を抜かれて踏み台になる等の「インシデント」にさらされます。サーバの正規の利用者が他のサーバを攻撃していてクレームや捜査が来るという事だってあり得るでしょう。 また、「貴サイトから攻撃されています」、「貴サイトには脆弱性があります」という指摘やクレームもいつこないとも限りません。 このような場合、まず、慌ててサーバを緊急停止したりしてはいけません。指摘の事実を確認することが最重要です。そして、外部からの指摘の場合は、調査期間と回答期限をつけて返信しておくことも重要です(ファーストレスポンス)。その上で、事実が確認できてもできなくてもいずれの場合でも最終的な回答もその回答期限内に行っておきましょう。 また、夜中や夏休み、日曜の深夜などインシデントの発生は時を選びません。自分でサーバ/サービスの停止が判断できないような場合は、最終的に責任を取って判断できる人、もしくは指示系統に合わせた「緊急連絡網」を事前に作成しておき、その指示を仰ぎましょう。 他にも注意すべき点があります。例えば、脆弱性を通知してきた人物が、実は、  ・サーバの脆弱性を突いて侵入したが一般ユーザ権限しか取れなかった  ・通知することでオペレータ権限(root)での作業の際に権限昇格する踏み   台のコマンドを用意してオペレータに踏ませようとした という可能性を否定できないのです。 そして、最後に大切なことはこれらの全ての作業ややりとりはきちんと記録を付け、できれば複数人で合議しながら記録し、対応することです。このことをきちんと行っておくことで、何かあった場合の証拠能力はグンと上がります。
  24. &amp;lt;number&amp;gt; 証拠ということで、証拠保全という点で、ログの保存について話をしましょう。 本来は、決められた手順で、作業を二人の立会人の元に、定期的に行い、作業記録に署名し、メディアの保管方法や期間、廃棄方法にいたるまでを規則を作って、これを堅実に実施することが要求されています。 (他にも、メディアに油性ペンで署名し、捺印し(捺印はセロハンテープで押さえる)、これを日付を証明する新聞などと一緒に作業者が保持している写真を撮影するなども有効です) しかし、これを個人サーバやコミュニティサーバで励行することは、事実上、不可能かもしれません。 最低でもしておきましょう!というガイドラインは、  1.ログの取得期間を53週(1年)にしておく  2.定期的(例えば1ヶ月に1回)に、ログディレクトリのバックアップをCD-   Rメディアに記録し、盤面にバックアップ日付と署名を行う  3.このCD-Rメディアを3年くらい保存しておく ということを励行することです。「定期的」の期間は、3ヶ月に1度でも構いません。重要なのは、以下のようなコンセプトです。  『ルールを明文化し、その通りに正しく遵守して、確実に実行する』  『記録を定期的に“重複”して取ることで原本の改竄の痕跡を見つけやすくする』  『重要なログは、他の方法(後述)でも複製して改竄の痕跡を見つけやすくする』
  25. &amp;lt;number&amp;gt; 最近では、ADSL等の高速回線とパソコンと、無償または安価で入手できるUNIX系のOSの普及と低価格から、猫も杓子もお家サーバという環境ができあがってきています。 市販の本でも「誰でもできる自宅サーバ」、「簡単ホームサーバ」などという類の本で、サーバ環境を構築するのは誰にとっても簡単という時代になってきています。 ところが、このように簡単にインストールして運用を始められてしまうサーバですが、これを常に安全に保ち続けるというのは今まで述べてきたようにインストールのように「誰でも簡単」というわけにはいきません。 このため、簡単な方法に逃げて、「やられたら再インストールすればいいや」というサーバ運用者を時々みかけるのですが、これは大きな間違いです。通常、rootkit等のツールを使われるとサーバが乗っ取られた事は容易には判別できないからです。 また、産業スパイ等、高度のテクニックを持った犯罪者に狙われてしまった場合も、まず、サーバが乗っ取られた事は判別不能です。 このため、やられにくいサーバ、やられそうになったことを検出できるサーバ、やられても被害を最小限度に止められるサーバを構築・運用していなければなりません。 このような努力を怠ると、2002年8月23日の事件(古い脆弱なOSを使っていた愛知県のケーブルTV局配下のインターネット利用ユーザのサーバを踏み台にしてNASAが数百回の不正アクセスの試みを受けていた)のような立場になり、場合によっては管理責任として損害賠償を請求される可能性もでてきます。
  26. &amp;lt;number&amp;gt; 自宅サーバなどを立てる時に、往々にしてよく見かけるのが、NATルータ機能やダイアルアップルータ機能、パケットフィルタリング機能、サーバ機能をただ唯一のサーバで全て賄ってしまおうというケースです。 しかし、全ての機能を複合して1台で設定し、運用するのは、実は非常に難しいことです。というのは、たった1台で運用しているということは、 ・防御もたった1台(1重の守り) ・緊急事態で停止したら全て停止 だからです。また、シンプルな設定で運用した方がサーバの見通しもよくなり、メインテナンス性も上がります。 このようなことを考慮しなければならないのは、あなたが運用しているサーバは(当然)グローバルIPアドレスを持っているはずですが、グローバルIPアドレスを割り当てられて運用しているサーバという観点でいえば、NASA、FBI、首相官邸などのWebページを運用しているサーバと責任は同じだからです。 この意味では、最低でも二重の防御構造、すなわち、ブロードバンドルータを併用して、パケットフィルタなどの機能も二重に設定しましょう。つまり、サーバ上のパケットフィルタはブロードバンドルータのパケットフィルタ機能を破られたり、バグがあって機能しなかった場合のために設定しておく…という考え方です。
  27. &amp;lt;number&amp;gt; 近年の自宅サーバでは、「ダイナミックDNS」機能を利用したサーバ運用が流行っています。 しかし、WEBサービスやメールサービス等、全てのサービスは、IPアドレスを元にしてデータの配信をしているシステムです。 そして、「ダイナミックDNS」にも、「新しいIPアドレス」に更新するための時間が必要になります(大抵は5分程度)。 結果として、DNSデータベースが切り替わる5分間の間、古いIPアドレスを取得したコンピュータに全てのWEBアクセスやメールが行ってしまうことになるのです。 WEBアクセスであれば、利用者にそのように告知してあれば、そう大きな問題にはならないはずですが、しかし、古いIPアドレスを取得した他の利用者がWEBサービスを提供していなかった場合、その利用者から見れば、このアクセスは「不正アクセスの試み」以外の何者でもありません。 また、メールサーバを運用しているのであれば、これも古いIPアドレスを取得した他の利用者のサーバに行ってしまいます。そして、宛先不明のメールを全て管理者アドレスで受信する設定でそのメールサーバが運用されていた場合、迷い込んだメールはそのまま吸い込まれてしまうことになります(自宅サーバの場合、このような設定で運用されているサーバは多い)。これでは、メールのセキュリティは無いも同然です。 従って、継続的にサーバを運用するのであれば、やはり固定IPアドレスが割り当てられる接続サービスを利用するべきなのです。
  28. &amp;lt;number&amp;gt; 個人サーバを運用する上では多少実現が難しいのですが、できるだけ固定IPアドレスも複数取得しておきましょう。監視が楽になるからです。 サーバを運用監視する上で、大抵、常に問題となるのが「あるポートスキャンが攻撃の予兆なのかどうか?」や「自分の管理するサーバ“だけ”をねらい打ちで来たのか?」を判断するのが難しいことです。 この判断ポイントは非常に重要です。 自分の管理するサーバがウィルスやツールなどによって自動チェックされているだけであれば、相手は無人か、もしくは自分がターゲットとしてロックオンされていないことが期待できます。ところが、何らかの理由により自分のサーバがターゲットとしてロックオンされているのだとすれば、自ずから対応が変わってきます。その場合の対応は、もう、オペレーション コードレッド、つまり緊急事態です。 この判断は、次のような手段を使うことで比較的容易におこなうことができます。  ・自分のサイトのIPアドレス近辺での「傾向と対策」を分析する  ・自分のサイトの傾向とインターネット全体の傾向を比較する 判断ポイントとしては、近辺アドレスを総ナメにしていくようなアクセスでないか?や、インターネット全体の傾向と同じパターンか?などです。この場合は、自サイトはターゲットとしてロックオンされている可能性は低いでしょう。 ただし、全体傾向よりひどい場合であっても、JPドメインをねらい打ちにしている場合や、IPアドレス(先頭1オクテット)を多く所有している国で流行しているだけ・・・という場合もあります。
  29. システム/ネットワークの管理者には、大切な資質があります。 三歩歩いたら忘れる  システム/ネットワークの管理者は、利用者の個人情報や、利用情報(「いつ使った?」「どれくらい使った?」「何をした」等)、利用者情報(ユーザのID/パスワード)を知り得る立場です。また、管理をしている間にこれらの情報に嫌でも晒されます。しかし、これらの情報は、システム管理をしている瞬間を除いて、すぐに忘れなければなりません(少なくとも忘れているべきです)。 管理者は自らを厳しく律さなければならない  監視する人をどのように監視するか?は永遠の課題です。一般的に、システム/ネットワークの管理者自身を管理・監視するのは自分以外にはいません。無人島のロビンソン・クルーソーが、誰も見ていなくても弱い立場の動物たちを決していじめなかったように「誰が見ていなくとも守るべき規範は守る」という強い遵法意識、職業倫理がなければなりません。 管理者として知り得たモノは個人で得たモノではない  管理者をしている間に、管理の都合上入手してしまった情報は、個人が得た情報ではありません。あくまでも、「管理者」という「委託された神聖な権限」に付随するものです。したがって、たとえば管理者のIDとパスワードは、管理者を辞めた時点であなたが知る由もない他人の情報になります。つまり、たとえば管理者を止めたあとも管理者パスワードが変更されていなかったとしても、そこにアクセスしたら不正アクセス禁止法違反になるということです。 ※これにはいくつもの判例があるので確定事項です。
  30. システム/ネットワークの管理者には、必要な知識があります。 実用的な法律知識  インターネットの世界への法律の適用はまだまだ難しい場面が多くあります。インターネットのあまりにも早い変化に法律が追いついていないのです。このような中でも、既存の法律の枠組みを適用した判例や、新しい法律の制定など、法律の枠組みもリアルタイムで変化しています。 なかには、「既存の枠組みでこういう解釈をするのか?!」と疑問に感じるものすらあります。まだまだ、試行錯誤を繰り返しているという状態なのです。 このように混沌とした中で、管理者には、比較的インターネットを利用する場合に問題になりそうな法律と、今までに出ている判例を、ある程度、把握しておくことが要請されます。  実際に、企業の顧問弁護士でもインターネットロイヤーと呼べるレベルの実用知識を持ち合わせている弁護士はそう多くなく、日々のインシデントを法的にハンドリングする際に、顧問弁護士と相談する場合にも、判例等のポイントを指定して実務面の相談をした方が話がスムーズに進む場合もあります。また、国家をまたがった違法行為の場合は、実例や判例などをどれだけ押さえているかがカギになる場合もあります。時々、そのような関係の勉強会が行われる場合もありますので、そのようなときには積極的に知識を研鑽しましょう。 最新の動向に敏感に  そして、このような情報は、日々、更新されていきます。P2P問題や、不正アクセス禁止法、サイバー犯罪防止条約、著作権法違反およびその幇助、等など、常に最新の情報と動向に敏感でなければなりません。
  31. 著者は、警察大学校や東京高検、情報セキュリティ大学院大学にて外部講師をなさっていらっしゃったり、法総研研究員時代にハイテク犯罪研究を専任されていたこともある有名なハッカー検事さんです。この方は、ある意味で現在の警察、検察、法廷の“ハイテク犯罪の常識”の基礎を作った人と言えます。 なお、本書は、全国警察署・警察官向けの月刊誌「捜査研究」の連載を単行本化したものです。(IT系の会社が取る日経コンピュータみたいな位置づけの雑誌) 一般書店で入手しにくい場合は、東京法令のページから注文した方がよいかもしれません。 (郵便振替で後払い) → http://www.tokyo-horei.co.jp/haiteku/ 書籍情報:  書名:「ハイテク犯罪捜査入門-捜査実務編-」        ISBN4-8090-1119-4 A5版488ページ  著者:大橋 充直  定価:@2,940-  出版社: 東京法令株式会社 同シリーズの書籍として、「ハイテク犯罪捜査入門-基礎編-」 がありますが、私見ではこちらの書籍は、本書「ハイテク犯罪 捜査入門-捜査実務編-」を読みこなせる人であれば無理に 読む必要はないかもしれません。 しかし、いわゆる現場警察官のレベルを知っておくにはよいでしょう。
  32. ここでは、実際にサーバ上で、各種のサービスについてどのような点について注意して構築すればよいか? また、どういう設定をどういう観点で行えばいいかについてお話してゆきます。 ここからの内容は、演習の際に実際に設定していただきます。 よく内容を理解し、手順を頭に入れて、効率よく設定を進めていくようにしてください。 なお、演習中、不明点などがあった場合は、他の参加者に聞いたり、講師に聞いたりしながら、(テストなどではありませんので)考え方や方針といったものを会得するようにしてください。また、分かった参加者は積極的に回りの分からない参加者に教えてあげましょう。 教えることは最大の学習であり、単純に手順だけ覚えるよりも、得られるものも多く、応用が利くようになるからです。
  33. &amp;lt;number&amp;gt; 「セキュリティ概論」で述べたように、サーバ構築では、「10%の労力で90%の効果」という自分でできる範囲かどうかを見極めるポイントがあります。 この範囲でいうと、最低限のラインとしては、  ・パケットフィルタリングによるセキュリティの確保  ・サービスの限定、公開範囲の設定  ・自動監視ツールなどによる監視コストの低減 といったあたりになります。 これ以上の作り込みを行っていくと、理解のしやすさもメインテナンス性も落ちます。また、例えばSnort等の場合は、常に新しいインシデントに対応した「シグネチャ」のパターンを更新したり、吐き出される情報を選定していかないと有用な情報は得られにくいものです。 このような関係の中で、「得られる効果」と「必要とされる効果」を比較して、「必要とされる効果」が勝る場合は、その原因となった要因を減らす(個人情報を取得しない等)方法でバランスをとるようにしましょう。
  34. &amp;lt;number&amp;gt; パケットフィルタリングについて考えましょう。 パケットフィルタリングとは、  ・公開する内容(What)  ・公開する条件(How)  ・公開する相手(Who) などが固定的なルールで決定できる場合に有効な方法です。 たとえば、オートロック付きマンションの管理人さんに「なかむらクリーニング」の人が、「ご用聞き」で来たのならば、80号室と53号室と110号室の部屋に訪問すると言っているのであれば開けてあげてください・・・と頼むようなものです。 間違っても、「消防署の方からきました」という人を訪問先も聞かずに、要件も聞かずに通されてしまっては困るのです。 特にプロバイダのサーバなどを運用する訳ではないので、接続できるプロバイダを限定したりして、できるだけ細かく相手を特定してサービスを提供する等の利用方法は検討してもよいでしょう。 また、コンピュータウィルスなどのアクセスと判別できる特定ポートへのアクセスを元にそのコンピュータの接続を拒否するパケットフィルタを自動的に設定するようにするのも手です。不正アクセスを試みる側から見ると、自動遮断機のようにパケットが突然切断されることになるので、これだけでも「手強そうだ」という印象を与えることができます。
  35. &amp;lt;number&amp;gt; TCP/IPでは、TCPサービスとUDPサービスにポート番号という概念があります。このポート番号とは、マンションでいうところの各部屋番号にあたります。サーバ自身はオートロック付きのマンションのようなものです。 UDPサービスでは、来訪者の身元は保証されていません。あくまでも自己申告で行われます。 TCPサービスでは、来訪者の身元はある程度、保証されています。相手が自己申告した「住所」に「32ビットサイコロ」の結果を送付し、持ってきた結果の一致を見て相手の素性を確認するようになっているからです(ただし、「32ビットサイコロ」の値を当てずっぽうで当てられてしまったり、相手に届ける途中の経路で覗かれてしまう可能性はあります)。 また、それぞれのサービスには固有のポート番号が割りあてられており、どのサービスが呼び出されたのかを判別できるようになっています。 このような代表的なポート番号はIANA(Internet Assigned Number Authority)がウェルノウン・ポート(Well-Known Port:よく知られているポート)として1024未満のポートを割り当てています。このウェルノウン・ポートは、512未満のインターネットサービスと512~1023のUNIXサービスに大別されています。 そのうち、512~1023のUNIXサービスは、UDP接続サービスのものも多く、また、ほとんどのものがLANの内部や、「お友達同士」というような間柄で使うようなサービスで、現在の殺伐としたインターネットでは決して公開に相応しいようなサービスではありません。
  36. &amp;lt;number&amp;gt; ポート番号にはIANAで定義されてこそいないものの、事実上の標準として特定のソフトウェアが使用してしまっている1024番以降のポートもあります。 また、その特定のソフトウェアの用途から、汎用的にその目的のために使うポートとしても事実上の標準になってしまっている場合もあります。 ただ、ほとんどのポートは、やはり512~1023番までのポートと同様に、インターネット越しに使用されることを前提にしてはいないものばかりです。 たとえば、近年、様々な場面で話題になる、ウィルスなどの「裏口(バックドア)」や、また、Sasserウィルスが使用したWindowsの脆弱性なども、全てこのような「インターネット越しに使用されることを本来、前提としていない」サービスがインターネットに直接晒されていたことが被害の原因になっています。 また、中には、このような事実上の標準のポート番号をわざわざ使用して「裏口」を開けるウィルスもいます。これは、そのような「事実上の標準」のポートであればファイアウォールやパケットフィルタ等で通過できる設定になっていることが期待できるからです。 したがって、このようなポート番号を使用するサービスを、もし、パケットフィルタなどで「通過」させる設定を要求するサービスを利用する場合には、「本当に必要か?」をリスクと勘案しながら決定しなければなりません。
  37. &amp;lt;number&amp;gt; このページでは、代表的なウィルスの「裏口」や、ウィルスが使用する脆弱性のあるポートについて一覧表示しています。 特に、    をつけたポート番号は、使用するウィルスや脆弱性の影響の大きさから大変に「有名」になってしまったものです。 これらのポートについて、外部からのポートスキャンがあったり、内部で応答するようになっていたりする場合には、速やかに「出入り口=ゲートウェイルータ」でこれらのポートを遮断しなければなりません。
  38. &amp;lt;number&amp;gt; パケットフィルタについて考慮する時に、「ソースルーティング」についても知っておいた方がよいでしょう。ソースルーティングとは、元々、パケットが通る経路を指定するための機能で、TCP/IPの「オプション」的な位置づけの機能です。 この機能は、  ・パケットのオリエンテーリングのようなもの  ・IPネットワークが充実する以前、特定の経路でないとインターネット に接  続できないサイトのために利用された  ・経路上の障害が事前に分かっている場合の迂回手段のひとつ といった特徴がありますが、「IPアドレスの詐称と組み合わさるとサーバへの攻撃手段」となり、パケットフィルタやファイヤウォールを通り抜けてしまう可能性があるため、注意が必要です。 先のオートロック付きマンションの例で言えば、ソースルーティングはまさしく来訪者が「消防署の方から来ました」というような機能だといえます。 一般的には、皆さんが使用するような「末端(エッジ)」のネットワークでは、この機能は必要がありませんので、水際のパケットフィルタでソースルーティング指定されているパケットを識別できる機能がある場合には、このようなパケットは破棄するべきです。
  39. &amp;lt;number&amp;gt; TCP/IPのTCPセッションにはパケットフィルタで防ぎきれない特殊な状態があります。 これは、軽く先にふれましたが、「スリーウェイ・ハンドシェイク」という独特のTCPセッションのスタート方法が関係しています。 スリーウェイ・ハンドシェイクでは、接続しようとする側(A)が、サーバ(B)にセッション開始を通知するときに、乱数の&amp;lt;シーケンス番号1&amp;gt;と&amp;lt;SYN&amp;gt;フラグを立てたパケットを送ります(ターゲットのポート番号指定も入っています)。 サーバは、この返事のパケットにさらに独自の<シーケンス番号2>をつけてAに返し、Aからこのシーケンス番号のセットが返ってくるのを待って、セッションを開始します。  ※相手のIPアドレス宛に投げたパケットが届いていなければ③のパケット   は来ないはず・・・という方法で確認をしています。逆にいうと、通信経路   上で、傍受・偽装(MITM)されたりすると、全く異なる相手との通信が成立   してしまうことに注意!! この機能を悪用して、①のパケットを大量に送りつけて(①が来たことを覚えておくバッファを使い切らせることで)SYN-Floodと呼ばれるサービス不能(DoS)攻撃に用いられたり、①を送って②が返ってくることを確認してそのポートでのサービスが提供されているかを確認したりするのに使われることがあります(ハーフオープン・ステルススキャンと呼びます)。
  40. &amp;lt;number&amp;gt; セッション開始と同じように、セッション終了にも問題のある部分があります。 それは、TCPセッションの終了/切断時です。 TCPセッションの終了時には、①のように<FIN&amp;gt;フラグを立てたパケットを送信し、相手から&amp;lt;FIN,ACK&amp;gt;フラグの立ったパケットを受信するというのを、双方向で行います。 ところが、この②のパケットが、もし通信障害などでリクエスト側に届かなかったらどうなるでしょう?このようなとき、①を送った側は、タイムアウトを待って①を再送信します。しかし、②を送った側はとうの昔に正常終了したものとみなしているため、今度は、そのままでは①の返信②が返送されないことになってしまいます。 このようなことを考慮して、多くの機器やOSの実装で、セッションが開始されていない時の動きとして、無条件に①がきたら②を返すというようになっているものがあるのです。 このことから、悪意のある第三者が、①のパケットを送りつけて②のパケットが返ってくるかを見て、そのポートでのサービスを提供しているのかを探る方法もあります。これを一般的に「FINスキャン」と呼んでいます。 これらのスキャンは通常のセッションとは異なり、システムの通常のユーティリティではsyslogに記録されません。そして、隠蔽を特徴とする「ステルス系」のスキャンは、間違いなく通常とは異なる攻撃の前兆と言えます。 これは、パケットフィルタでは防ぎきれませんし、OSでも検出してsyslogに記録するには特別なユーティリティが必要になります。
  41. &amp;lt;number&amp;gt; TCPの特殊な事情についてお話しましたので、UDPの事情についてもお話しましょう。 UDPは、TCPのように相手にパケットが必ず着くことを確認できません。基本的に「投げたら投げっぱなし」で、相手に届いたことをプロトコルとしては確認できません。 また、TCPのスリーウェイ・ハンドシェイクのような「儀式」もなく、ただひたすら「垂れ流し」状態で、「セッション」という概念もありません。 このため、接続を覚えて置かなくてもよいことや、相手の返信(ACK等)を待たなくても良い=タイムアウト時間だけ返信を待たなくてもよいことから、高速な通信やマルチメディア通信などで利用されます。 接続を覚えて置かなくてもよいことから、DNSやSNMP、RADIUS等で利用されています。  ※マルチメディア系では、高速性を追求するためにUDPを使用しますが、   このような信頼性のないプロトコルなので、信頼性をアプリケーションが   実現しています。 しかし、これらの特徴からわかるように、送信元のIPアドレスを確認する手段がないので、あくまでも送信元のIPアドレスは「自己申告」で本当にそのIPアドレスから送信されたことは保証できません。悪意ある第三者が専用のツールなどを使ってIPアドレスを偽装してUDPパケットを送りつけてくることも十分考えられます。 (専用のツールといっても、簡単なものならnmapでも可能です)
  42. &amp;lt;number&amp;gt; pingやtracerouteなどのユーティリティが使用するICMPについても触れておきましょう。 ICMPは、「制御メッセージやりとりするためのプロトコル」です。この「制御メッセージ」には、ネットワークを診断するためのメッセージやネットワークの障害を通知するためのメッセージなど、いくつかの種別があります。 また、ブロードキャストアドレス宛のICMPパケットには、全機器が反応するという約束事があります。この機能を利用して、Smurfと呼ばれるDDoS(分散サービス不能攻撃)の有名な攻撃方法がすでに行われており、ゲートウェイのルータ等でブロードキャストアドレス宛のICMPはすべて遮断しておかなければなりません。 また、いくつかの種類のメッセージはエッジ(末端)のルータでは現実的に不要なものや、攻撃に使用される可能性のあるものがあるため、このような種類のメッセージも識別できるのであれば、積極的にパケットフィルタで遮断した方がよいでしょう。 次のページに遮断した方がよい種類のICMPメッセージの一覧があります。
  43. &amp;lt;number&amp;gt; この表は主なICMPメッセージの種別について、一覧表示にしたものです。 タイプ0とタイプ8は、ping/tracerouteが使用するメッセージですので、遮断してはいけません。 タイプ11はWindows版のtracerouteが使用するメッセージですので、Windows版のtracerouteを診断ツールとして使うのでなければ遮断することは可能ですが、このメッセージを悪用した攻撃というのは基本的にありませんので、敢えて遮断する必要はないと思われます。 最後にタイプ3ですが、これは、IETF(Internet Engeneering Task Force)によるRFC(Request For Comment:インターネット標準を規定した文書)により遮断が禁止されているメッセージです。 これ以外の   が付いている種別のメッセージは、悪用されるとDoS攻撃が可能になるものが多いので、積極的に遮断しておいた方がよいでしょう。  ※実際に、インターネットを観測していると、タイプ4のSource Quenche(ソー   ス・クエンチ)などはたまに送られてきます。これは、「送信停止して欲しい」   というリクエストですので、DoS攻撃の可能性があり得ます。
  44. &amp;lt;number&amp;gt; 実際に、ICMP Smurf攻撃が過去、どのように行われたかについて簡単に説明してみましょう。  ※絶対に実行してはいけませんし、また、このような攻撃に参加するような   はめになるインターネット側からのブロードキャストアドレス宛のICMPには   反応してはいけません。 この攻撃は、世界中の各サイトのブロードキャストアドレス宛にpingが使用するICMP Echoのパケットを送信します。この結果として、実際に例えばクラスCのネットワークの場合、最大253台のコンピュータがICMP Echo Replyパケットを返すわけですが、この時、ICMP Echoの送信元を詐称して被害者サイトのIPアドレスを偽装するのです。  ※ICMPもUDPと同様、相手のIPアドレスが偽装されていないことを確認す   る手段がありません。 このため、クラスCでは1個の偽装パケットが254倍になって犠牲者IPアドレスに向かって殺到することになります。クラスBでは、1個の偽装パケットから65534倍の攻撃パケットが・・・という形で、犠牲者のIPアドレスに返信パケットが殺到することになるのです。
  45. &amp;lt;number&amp;gt; この結果、もし、例えば、攻撃者が1.5MのADSL回線のアップリンク512Kのフルスピードでこの手の攻撃をしたとすると、クラスCで行った場合、最大で、  0.5M × 253 ≒ 126.5 M の帯域幅を犠牲者サイトが持っていなかった場合、ネットワークがパンクしてしまい、サービス不能状態に陥ることになってしまうわけです。 実際にこのような攻撃と思われる届け出が1999年に2件、2000年にも3件、2001年以降はSmurfを含むDoSが6件、2002年には16件、2003年には8件が報告されています(IPA調べ)。 重ねて言いますが、このような攻撃が成立してしまうのは、このような不正なパケットを中継するサーバ/サイトがいるためです。 少なくとも皆さんが運用するサイトでは、このような攻撃に加担することのないように、ブロードキャストアドレス宛のICMPパケットは必ず破棄しましょう。
  46. &amp;lt;number&amp;gt; Smurf攻撃は何もICMPばかりではありません。 TCP以外の通信では、送信元IPアドレスはすでに触れたように「あくまでも自己主張」にすぎないからです。すると、DNSやSNMP、UDPを使ったストリーム通信なども送信元IPアドレスを詐称して攻撃対象のIPアドレスにすることができてしまうのです。 しかし、実際にはストリーム通信は「一定量送ったら、着信の返答がある」モードを持った通信です。こういう通信は、相手側に対応するプログラムが動作していなければ返答がないので、すぐに止まってしまいます。 ところが、DNSやSNMPはこういった回答を待たないもードレスな通信です。このため、1パケット送信すると255パケット返ってきても決して不思議でも何でもありません。特に、LAN内やDMZ内からの名前解決の問いあわせを処理するためのDNSサーバが往々にして、インターネット側にもそのままぽっかりと口が開いてしまっているものを見かけます。このようなDNSサーバはクエリSmurf攻撃に利用される可能性が高いと言えます。 ※余談になりますが、DNSにはこの他にも、ビッグパケット(問いあわせに対して  数キロバイトのデータが返ってくる)やマルチパケット(1つの問いあわせに数百  倍のパケットが返ってくる)という形でのDNSサーバ側からの攻撃もありえます。
  47. &amp;lt;number&amp;gt; パケットフィルタについて、説明すべき項目で残っているのが「短命なポート」と呼ばれるエフェメラル・ポートです。 たとえば、WEBブラウザでWEBサーバにアクセスする場合、WEBブラウザは、一時的に使用するために1024番以降の空いているポートの割当てを受けます。  ※接続する先は、WEBサーバなのでポート番号80番(TCP/80)です。ポー    トは、接続元と接続先でそれぞれ異なる番号が使用できるのです。 高速な先読みを行うWEBブラウザやWEBブラウザのチューニングの「最大接続数」などは、このような通信をいくつ同時に行うかを指定するものです。 このエフェメラル・ポートが問題になるのは、ftpでの接続です。Ftpでは、制御系のポートは固定ですが、実際のファイル送受信は、送信元も送信先も共にこのエフェメラル・ポートを使用するからです。 このため、ftpでのファイル転送はパケットフィルタを非常に難しくしてしまいます。
  48. &amp;lt;number&amp;gt; このように、パケットフィルタリングを考える場合には、TCP/IPの特性なども含めて、様々な要素を考慮し、また、それらの機能の有効性を考えながら設定したり、また、機器の機能のある・なしを選定していかなければなりません。 また、このようなパケットフィルタリングの設定は、数を増やしていけばいくほど、機器の性能が加速度的に落ちていきます。特に、ゲートウェイルータ等のハードウェア機器の場合にはこの症状は顕著に表れます。 性能だけならまだしも、処理能力が落ちるとサービス不能攻撃に対する耐性も落ちてしまいます。 また、ゲートウェイだからこそ設定できるフィルタルールもあります。それは、インターネット側からDMZ側アドレスをソースアドレスとして詐称するパケットが来たらそれを遮断したり、その逆にDMZ/イントラネット側からそれぞれのアドレス以外のアドレスをソースアドレスに詐称したパケットがインターネットに出ていくのを防止するようなルールです。後者は自サイトからSmurf攻撃をさせないためにも有効です。 インターネット側からのブロードキャストアドレス宛のICMPもゲートウェイルータで設定するのが一番適切でしょう。 この他にも、多重・多層防御の考え方で、それぞれの機器にバグなどがあってうまく設定が機能しない場合や、設定ミスの場合などを考慮して、ゲートウェイルータだけでなく、サーバでもパケットフィルタを設定することも考慮するべきです。 このようなことを総合的に判断して、パケットフィルタを設定しなければならないのです。
  49. &amp;lt;number&amp;gt; 実際に、自宅サーバなどの場合、ブロードバンドルータの直下にDMZとして一台のサーバが動作するというケースが多いでしょう。 この場合でも、注意しなければならない事があります。 それは、簡易DMZ(「なんちゃってDMZ機能」と私は呼んでいます)機能についてです。これは「ブロードバンドルータの外側(インターネット側)のIPアドレスでのアクセスがあったら、指定された内側(イントラネット側)のIPアドレスにフォワードする」機能で、サーバを公開する方法としてはもっとも簡単な方法です。しかしこの方法では「サーバが侵入されてしまうと内部ネットワークの全コンピュータが危機にさらされる」という意味で、非常に危うい薄氷の上を歩いているような状況を作り出すというリスクを負わねばならず、実は常に危険と隣り合わせの運用を強いられるのです。 この意味で、リスクは少しでも少ない方がよく、できるだけ公開するサービスを限定して、ポート単位で公開するといった方法を用いた方が、より安全です。 もっと安全なのは、イントラネットを背後に置くルータと、公開サーバが接続されているLANがあって(これが本当のDMZ)、これがルータを介してインターネットに接続している・・・というネットワークにすることです。 昨今、ブロードバンドルータの値段が非常に安価になっているので、ここはちょっとリッチに2台用意して、このような本格的なDMZを設けることを強く推奨します。
  50. &amp;lt;number&amp;gt; 公開サーバでは、どんなパケットフィルタを設定すればよいでしょうか? 実際のところは、公開するサービスの種類によりますが、DNSとメールサーバ機能については、セカンダリ機能を作れるのであれば、ぜひ、設定しておきたいところです。 DNSとメールサーバは、インターネットサービスのうちセカンダリを設ける事で、信頼性を担保したほうがよいサービスだからです。 たとえば、DNSでセカンダリを用意できると、何かの作業などでプライマリDNSがダウンしても問題になることがほとんど無くなり、気軽にサーバのメインテナンスができるようになります。 さらに、メールサーバにセカンダリがあると、プライマリメールサーバがダウンしてもセカンダリが「とりあえず受けてくれて」、後でプライマリに転送してくれるので、プライマリメールサーバも気軽にメインテナンスすることができるようになります。(ただし、qmail では、優先順位の低いセカンダリには転送するように実装されていません)  ※最も、大抵は送信側のメールサーバが72時間くらいは再送を試みて    くれるような実装になっています。 このように、セカンダリを用意することは、気軽にメインテナンスできる=メインテナンス性を上げることができるのです。 セカンダリを受けてくれる知人が周辺にいないときには、セカンダリDNS互助会(http://cn24h.hawkeye.ac/dns.html)でセカンダリを受けてくれる有志を探しましょう。
  51. &amp;lt;number&amp;gt; この設定例は、Linuxサーバで公開サーバを設定する場合のパケットフィルタの設定例です。この例では、以下のような例題ネットワークにおける公開サーバAを想定しています。 サーバAのIPアドレスは61.211.1.178、ルータCのIPアドレスは61.211.1.180です。
  52. &amp;lt;number&amp;gt; パケットフィルタの設定は、実際の運用時には上記のように注意して行う必要があります。しかも、「遠隔操作でメインテナンス」をしているような場合、標準ポリシを変更するときは、設定方法を間違えると、sshでの接続が遮断されてしまう場合があるからです。 Linuxのパケットフィルタには、「ポリシ」というものがあります。 これは、「何も指定されなかった場合のデフォルトの動作」を指定するものです。「受け入れる(ACCEPT)」、「拒否して返答する(REJECT)」、「拒否して返答しない(DENY)」の三つのポリシがあります。 通常、安全を考慮するとDENYをポリシとして、ACCEPTする個別のルールを指定すると良いように思われますが、実際は、そう簡単にはいきません。 これは、このフィルタの設定方法(システムの設定スクリプト)によります。 どういうことかというと、  1.既存のルールを削除  2.デフォルトのポリシを設定  3.個別のルールを設定 という設定順序になっているため、2.が設定された時点でポリシがDENYの場合、「ネットワーク経由の接続が切れてしまう」ため、個別のACCEPTルールが有効にならないままになってしまい、コンソール以外からはルールの再読み込みができなくなってしまうからです。 作業をコンソールからしか行わないのであれば問題はありませんが、そうでない場合は、ACCEPTをポリシとしてルールを作成しなければなりません。 しかし、その場合、上記のプレゼンのような「注意」がでてきてしまうのです。
  53. &amp;lt;number&amp;gt; このルールでは、固定的なルールを設定しています。 CentOS では、標準のパケットファイアウォール設定では、簡易的なファイアウォール設定が行われます。簡易ファイアウォールの設定については実際のファイルを見てください。 また、この際の指定方法等については、書籍などを参考にしてください。
  54. &amp;lt;number&amp;gt; このルールでは、前ページの標準的なルールをより厳密に設定しています。 CentOSでは、標準ですべてのicmpを受け入れます。これでは問題がありますので、パスさせるものを、より厳密に定義しています。また、ネットワークがipv6に対応していない場合には(この例では対応していないものとします)、「-p 50」(IPv6-Crypt)と「-p 51」(IPv6-Auth)の行は不要なので削除しましょう。 また、出て行く側のパケットは厳密には制限していません。ただし、簡易ファイアウォール機能で接続状態は見ているので、外部からの不正なパケットが通過することはありません。
  55. &amp;lt;number&amp;gt; ここはメモ欄です。
  56. &amp;lt;number&amp;gt; サーバを構築する場合、必ず最初にインストール作業が発生します。 この際、例えインターネットに公開するサーバであったとしても、いきなりインターネットに直結してはいけません。 まずは、ブロードバンドルータ等の内側で、イントラネットのネットワーク設定で最新の状態へのアップデートしたり、不必要なサービスを停止するなど、十分に「インターネットの攻撃者と渡り合える準備をしてからインターネット側に接続する」必要があります。 実際に、このような方法を取らずに、「アップデートするのにインターネットにつなぐ必要がある」からと、いきなりインターネットに直接接続し、インストール/アップデートしている間に侵入された・・・という笑えない実例もあります。 これは、Linuxサーバに限らず、Windowsサーバでも、また、サーバではなく、クライアントコンピュータでも同様です。  ※余談ですが、クライアントコンピュータという意味では、AirH”等の常時   接続カードやモデムなどでインターネットに接続している場合も、「インター   ネットに直結」していることを意識する必要があります。この状態ではあな   たのコンピュータは攻撃者に直に晒されていることになるのです。
  57. &amp;lt;number&amp;gt; ここはメモ欄です。
  58. &amp;lt;number&amp;gt; 最低限の更新を行った後は、実際のサーバの運用にあわせて各種の設定を行っていくため、できればサーバを実際のネットワーク位置に置いて作業をしたいところです。 しかし、その前に行っておく事があります。 それは、まず、メインテナンス用にsshのセキュアな接続環境を構築し、その他のサービスをパケットフィルタや、その他の設定で「すべて落としておく」ことです。 この状態では、指定されたIPアドレス等からのsshの接続のみが可能で、その他の接続(たとえばメールとかWWWとかのサーバ機能や漢字変換サーバ、Xウィンドウ等々)は全くできないという状態です。 このためには、クライアント側もsshのクライアントをインストールして、接続の為の環境をつくっておかなければなりません。
  59. &amp;lt;number&amp;gt; PuTTYはWindowsで使えるSSH2対応のSSHクライアントソフトウェア群です。 ただ、日本語パッチの熟成具合や、また、ウィンドウハンドリングなどの操作性では、TeraTERMに一日の長があります。 一番のメリットのあるSSH2対応ですが、SSH1がセキュリティ的に脆弱と長いこと言われてきていますが、実際にこれが破られて大きな被害が発生したという話はあまり聞こえてきません。  ※でも、弱いのは事実です。 SSH1しか使わない場合でも、接続元を制限するなどの方法と組み合わせる事でリスクを低減することも可能です。  ※もちろん、SSH2と組み合わさると最強です。 クライアントについて言えば、このようなWindows用の専用クライアントではなく、Cygwinに含まれるsshコマンドを利用する手もあります。
  60. &amp;lt;number&amp;gt; TeraTERMは、Windows向けのSSH/telnet/シリアルポート用端末ソフトウェアとして、定番になっているソフトウェアです。 原著作権者はすでに開発を停止してしまっており、メインテナンスもされていません。しかし、ソースコードも公開されているため、必要に応じて、様々な改造や改良が行われて公開されています。 たとえば、上記のUTF-8対応TeraTERMですが、元々、作者の平田 豊氏は、漢字標準コードがユニコードであるMac OS Xへの対応としてTeraTERMのUTF-8対応を進められていましたが、Fedora Core 1以降で日本語の漢字エンコードにUTF-8が標準で採用されたため、脚光を浴びています。ちなみに、標準状態のTeraTERM proではUTF-8には対応していません。 現状では、平田 豊氏がUTF-8対応以外にssh2のPKI実装を進めようとしている最中であるため、ssh2でのPKI接続はまだ不安定です。 (http://hp.vector.co.jp/authors/VA013320/)
  61. &amp;lt;number&amp;gt; Poderosaは、Windows専用の.NET Framework 1.1以上で動作するタブ式GUIの高機能端末ソフトウェアです。Poderosaは元々、シェアウェアであったVaraTermというソフトウェアがオープンソースソフトウェアとしてApacheライセンス2.0の元で公開されるようになったものです。 (ただし、Poderosa はVaraTermとのシステム的な互換性はないので注意!) 元々は、Poderosaのプロジェクト・開発リーダーである岡嶋 大介氏がTeraTermへの不満から手がけるようになったソフトウェアであるため、使い勝手はたいへんによいものになっています。この辺の開発の動機やPoderosaの現在に至るまでの経緯は、 http://ja.poderosa.org/present/history.html で紹介されています。ソフトウェアのコンセプトを理解する上でも一読しておくとよいでしょう。 なお、PoderosaはソースコードもSourceForgeで公開されており、VisualStudio .NETでコンパイルすることができます。
  62. &amp;lt;number&amp;gt; サーバ側のSSHデーモンでも、よりセキュアな設定をしておきます。 一般的な変更の要点は、以下の通りです。 ディストリビューションの判断で設定が変更されている場合もあります。 ・ssh経由で直接rootでログインさせない。 ・ホームディレクトリの~/.rhosts等のファイルを参照するとパスワード無しでの  接続が可能になってしまうので、これらのファイルを無視する。 ・ホスト単位でのRSA認証は行わない。ユーザ単位でのみ行う。 ・GSSAPI認証やKerberos認証は行わない。 ・セッションの最大試行回数を制限する。 ・パスワードなしは認めない。 ・生パスワードで認証せず、必ずRSA認証、DSA認証で行う。 これらのうち、最後の項目は、最初にSSH1/SSH2の公開鍵をサーバに転送する時には(サーバ側に認証の公開鍵がない状態なので)設定せず、生パスワードでのログインを可能にしておきます(ただし、安全なブロードバンドルータの中で行います)。公開鍵をサーバに転送し、~/.ssh/authorized_keys ファイルを作成したら、RSA/DSA認証でログインできるかどうかを確認の上、生パスワードでのログインを禁止します。 また、/etc/hosts.allowにssh対応のエントリを作成します。自サイトの設定と、*.jp(JPドメイン)からの設定をしておけば通常は問題ありません。  ※国内JPドメインからのSSH接続の試みはほとんど見られないため。
  63. &amp;lt;number&amp;gt;  「実用SSH第2版-セキュアシェル徹底活用ガイド」は、OpenSSHと商用製品のTectiaをSSHサーバとして構成し、使用するためのノウハウが詰まった書籍です。 今後、SSH本の定番本になるであろう書籍ということができます。  SSHクライアントも日本国内での使用者の傾向にあわせて、TeraTERM, PuTTY, Poderosaに関する記述を追加したり、それぞれのクライアントでの日本語環境での使用に関する点も書き加えられています。また、原書刊行の後、世界的に流行した「SSHに対する辞書ベースでの攻撃」についてもJPCERT/CCから寄稿されたドキュメントがAppendixに追加されています。  つまり、現時点では世界でもっとも新しいSSHの事情に対応した書籍になっています。少々、重たい(笑)のと高い(m(_ _)m)のが難点ですが、安心してオススメできる1冊です。 また、監訳者である龍谷大学小島先生によるサポートページも充実しています。 「実用SSH 第2版 ― セキュアシェル徹底活用ガイド」サポートページ :  http://www.st.ryukoku.ac.jp/~kjm/security/sshbook/ TIPS:  「第2版」とありますが、「第1版」はどこにあるのでしょうか?実は、原書には5年前に「第1版」がありました。まだ、SSH-1しか無かった頃です。ところが、種々の理由により、日本語版を出す企画は露と消えてしまいました。 そこで、日本語版は、「第2版」からになっています。
  64. &amp;lt;number&amp;gt; ここはメモ欄です。
  65. &amp;lt;number&amp;gt; sudo は、サーバを複数の管理者で運用管理する場合に威力を発揮するユーティリティです。 sudo には大きく分けて2つの使い方があります。 一つは、rootに、いつ、誰がなったのかを記録するために使用する方法です。 この場合、rootになることのできる管理者ユーザをwheelグループに登録することで、その管理者は、 $ sudo su – Password: # でrootになることができます。この記録は、成功した場合も、失敗した場合もsyslogに記録が出力されます。
  66. &amp;lt;number&amp;gt; sudoの設定をする場合には、設定ファイルの編集にはvisudo コマンドを使用します。visudoで編集すると、文法チェックや複数ユーザの同時編集をチェックしてくれるからです。 例えば、上記の/etc/sudoersの内容でvisudoを終了しようとすると、次のようなエラーメッセージを表示します。 エラーチェックの例) etc/sudoers.tmp: 16 lines, 358 characters &amp;gt;&amp;gt;&amp;gt; sudoers file: syntax error, line 16 &amp;lt;&amp;lt;&amp;lt; What now? ? Options are: (e)dit sudoers file again e(x)it without saving changes to sudoers file (Q)uit and save changes to sudoers file (DANGER!) これは、この「=」が欠けていることを文法チェックで教えてくれています。   %wheel ALL = (ALL) ALL
  67. &amp;lt;number&amp;gt; sudoのもう一つの使い方は、特定のユーザに特定のコマンドだけの実行を許可する使い方です。この方法を用いると、  ・システムのシャットダウンだけ許されたユーザ  ・ユーザの追加、削除だけを許されたユーザ  ・fmlの設定だけを許されたユーザ  ・cvsでの操作だけを許されたユーザ 等というように、ユーザによって設定されたコマンドだけを実行することを許可することができるようになります。 しかも、これらのコマンドをそのユーザが実行したことを記録に取る(syslogに記録する)ことができます。
  68. &amp;lt;number&amp;gt; ここはメモ欄です。
  69. &amp;lt;number&amp;gt; inetd/xinetdは、「インターネットスーパーデーモン」と呼ばれる特殊なプログラムです。 これらのプログラムは、telnetやftp等の各種のサービスを行うサーバプログラムを「必要に応じて」呼び出してくれるプログラムです。  ※会社等でいうところの「受付」の役割を行うのが仕事ということで、「来訪   者」の訪問先に応じて、内線電話帳を見て、適正な宛先を案内してくれ   ます。 通常、ディストリビューションをインストールしただけの状態では、およそインストール済みのほぼ全てのサーバサービスがinetd/xinetd経由で起動できる設定になっています。 このため、最初に不必要なネットワークサービス/サーバサービスは全て「落とす」という作業が必要になるのです。
  70. &amp;lt;number&amp;gt; inetdは、Linuxカーネル 2.2までに対応していた頃のディストリビューションで用いられていたスーパーデーモンです。inetdではプログラムが設計が古く、プログラム自体に接続元によって起動できるサービスを制限する機能がありません。 このため、linux 2.2カーネル系のディストリビューションでは、tcp_wrapper という「接続元によって接続できるサービスを制限できる」ユーティリティと、ほぼセットで利用します。 この「接続元」の指定方法には4種類の方法があります。  1.「IPアドレス」指定による方法  2.「IPアドレス/ネットマスク」指定による方法  3.「.(ドット)から始まるドメインの一部」の指定による方法  4.「すべて」を表すALL指定 このうち、3.の「ドメインの一部」について説明すると、たとえば、.samba.gr.jpと指定されたとすると、perth.samba.gr.jpやsydney.samba.gr.jp等のコンピュータからの接続が許可されます。 実際に、接続してくる人が、「どういうプロバイダを使用しているか?」は知っていても、「どのようなドメイン名で接続してるのか?」を知っている場合はほとんどありません。このような場合、許可設定をする前に一度アクセスしてみてもらい、その日時を教えてもらうことでアクセス拒否したログから接続元のドメイン情報を取得するという方法が有効です。 また、指定するドメインの一部も、できるだけ長い文字列部分を指定するようにすると、同じプロバイダを使用していても、より「限定」されたエリアからのアクセスのみを許可することでサーバをよりセキュアにすることができます。
  71. &amp;lt;number&amp;gt; xinetdはinetdの拡張版として開発されtcp_wrapperの機能を内包しています。 その他にも、  ・サービス提供時間が指定できる  ・syslogに接続成功(または失敗)の記録を取ることができる  ・同時起動数を制限できる  ・システム負荷による接続制限をかけることができる  ・他のサーバへリダイレクトできる 等々、豊富な機能を持っています。 また、inetdでは問題となるSYN-Flood攻撃に対しても対策が講じられているなど、より拡張された機能を誇っています。 主にLinuxカーネル2.4以降のディストリビューションで採用されています。 これらのサービスの起動の可否は、 inetd/xinetdのいずれを使う場合でも、専用のユーティリティで設定することもできますし、chkconfig コマンドでコマンドラインで指定することも可能です。
  72. &amp;lt;number&amp;gt; xinetd では、個別のサービス毎に接続制限を設定しなければなりません。 たとえば、上記の例では、ftpサービスで接続元を指定しています。 接続制限は、only_from=パラメータで行いますが、その指定方法はtcp_wrapperと同じです。 また、サービス自体をONに指定する方法については、enable=ではなく、disable=で指定していることに注意してください。 つまり、サービスをONにするのであれば、disable = no 、サービスをOFFにするのであれば disable = yes になります。注意しましょう。 なお、xinetdでは、port = という指定で、使用するポート番号を明示的に指定することができます。このため、/etc/servicesにサービス名に対応するポート番号を記述しなくともport=901等と指定することで特別なサービスを特別なポートで待ち受けることができるようになっています。
  73. &amp;lt;number&amp;gt; 上記の画面は、CUI/GUIでの設定ユーティリティです。 左がRedHat系のredhat/system-config-servicesユーティリティです。 右がTurboLinuxのturboserviceユーティリティです。 これらのユーティリティや、chkconfigコマンドは実際には、inetd/xinetdによるサービスのON/OFFだけではなく、各種のサービスや自動実行プログラム (apache, DNS, ネットワーク,漢字変換サーバ、パケットフィルタなど)のON/OFFも行うことができます。 また、このように設定したサービスが正しく動作し、期待通りのポートが公開されて、期待以外のポートがちゃんと閉じていることを確認するためには、nmapコマンドやnetstatコマンドを使用します。 特に、“netstat –lp “を使用すると、サーバ上で待ち受けているポートと、そのポートで待ち受けているプログラムの一覧を得ることができるので便利です。  ※netstatで、待ち受けていることが確認できているにもかかわらず、nmapで    外側からポートスキャンしてみてサービスが確認できない場合は、パケット    フィルタでフィルタアウトされている可能性があるのでチェックしましょう。
  74. &amp;lt;number&amp;gt; この一覧は、システムが立ち上がる時に自動起動してもよいサービスの例です。 注意すべき点は以下の通りです。  ・ipchainsとiptablesはどちらか一方しか使用できません。  ・apmd/acpidは、場合によっては起動しない方がよいでしょう。サーバで電源   制御によってディスプレイがオフになっているときにカーネルパニック等が   起きるとエラーになった直前の状態が分からないからです。  ・この設定では、X-ウィンドウなどは起動しません。また、漢字変換サーバ   (FreeWnn, Canna等)も起動しません。この意味では、ランレベル3で動く   ことを想定しています。  ・random は一見、不必要に思われがちですが、https等でapache が暗号化   通信をしたりする場合に、システムの乱数を必要とするため、システム   の乱数系列を初期化するために実行しなければなりません。  ・atdやcrond/anacronは各種のメンテナンスユーティリティなどを自動実行し   たりするのに使用します。  ・停止するサービスがどういう機能を持っていて、停止しても問題がないことを   確認してからサービスを停止するようにしてください。
  75. &amp;lt;number&amp;gt; ここでは、一般的なISC BINDについて記述しています。 ネームサーバでは、3つの事項について、チェックが必要です。 一点目は、ネームサーバは一般的に53/TCPと53/UDPを使用することになっていますが、使用方法に違いがあるということです。53/UDPは通常の名前の問い合わせに使われます。これに対して、53/TCPはプライマリーセカンダリ間でのゾーン転送に使用されるのです。 よく見かける攻撃の種類に、プライマリネームサーバに対して「全く関係ない第三者からのゾーン転送」リクエストパケットが送られてくるものがあります。 これは、そのDNSが管理しているサーバの一覧を得ようとする、攻撃の前兆と言えます。  ※機械的な収集の場合も多いので、ねらい打ちでない場合もあります。 このような事態に対処するため、セカンダリDNS以外からのゾーン転送しか許可しない設定にすることが重要です。 二点目は、ネームサーバに対する「バージョンの問い合わせ」を行わせないようにする必要があるということです。ISC BINDでは不具合がでると、このバージョン問い合わせにより、不具合のあるバージョンかどうかを確認して脆弱性を突くという闇のユーティリティが必ず出回るので、これに対処するためです。 最後に、インターネット全体にDNSキャッシュ(参照専門のDNS)として公開しないことです。これは、すでにクエリのSmurf攻撃で述べたリスクを低減するためです。参照専門のDNSは、ドメインのオーソリティとなるDNSとは別に用意し、インターネット側からはパケットフィルタなどで参照できないようにしましょう。
  76. &amp;lt;number&amp;gt; このバージョンの問い合わせに対しては、ISC BIND 9.Xからはデフォルトで反応しないようになっています。 それ以前のバージョンの場合は、バージョン問い合わせに使用されるchaosクラスへの問い合わせを、localhostからのもの以外は全て拒否するという設定で対処します。 設定が正しく動いているかどうかは、ローカルコンピュータで以下のコマンドが成功するけれども、  $ nslookup –class=chaos –query=txt localhost version.bind  ~中略~  VERSION.BIND text = “8.2.3-REL” 他のサーバからの問い合わせは失敗するということを確認します。
  77. &amp;lt;number&amp;gt; ここはメモ欄です。
  78. &amp;lt;number&amp;gt; メールサーバでの重要な注意点は、「SPAM送信の温床にされないこと」です。 SPAM送信業者は、いわゆるオープンリレーのメールサーバを常に探しています。そして、そのような誤って甘い設定になっているメールサーバを見つけると、SPAM送信に使用します。 それというのも、このようなサーバでは、一通のメールを送るだけで宛先に1000万件とか10万件という宛先を指定さえしておけば、あとはメールサーバが勝手にSPAMを配信してくれるということで、「効率よくSPAMメールが送信できてしまう」からです。 特に、デフォルトでは最近のメールサーバではリレーしない設定になっているにも関わらず、イントラネットからのメールだけはどこ宛てでも、どういうFromアドレスになっていてもリレーするようにするということを実現しようとしてオープンリレー(どこからのメールでもどこ宛てでもリレーするという設定)に誤って設定してしまっているのを見かけます。 できるならば、受信専用SMTPサーバと送信専用SMTPサーバと個別に用意するのが一番事故が少なく、設定が簡素化され、間違いの少ない方法になります。 この場合、送信専用SMTPサーバはイントラネットの内部に置き、インターネット側からは直接アクセスできないようにすることが重要です。
  79. &amp;lt;number&amp;gt; このページでは、ファイル転送プロトコルについて代表的なFTPとWebDAVを比較しています。 以前は、ファイル転送といえばFTPということで、各種のホームページ作成ユーティリティはサーバへのコンテンツアップデートにFTPしか使用できませんでしたので利用者のFTPの要求を排除するのは難しいものがありました。しかし、現在ではメジャーなホームページ作成ユーティリティはWebDAVをサポートしているものが沢山あります。 また、サーバからのファイルのダウンロードであればFTPを使用せずともHTTPでもダウンロードさせることは可能です。 これらの状況の変化もあり、生の(プレインテキストの)IDとパスワードが流れてしまい、また、パケットフィルタが非常にやりにくいFTPサービスをサーバサービスとして起動するよりは、WebDAVを使用する方がよい状況になってきています。 WebDAVの設定方法については、以下の本を参考にしてください。 WebDAVシステム構築ガイド ――Apache/IIS/Subversion/Jakarta Slide  宮本久仁男、山田 泰資 、渡辺 剛著  技術評論社 ISBN: 4774119113
  80. &amp;lt;number&amp;gt; このページでは、FTPサービスがなぜパケットフィルタでフィルタリングしにくいのかを説明しています。通常、FTPでファイルを一つ転送するのに次のような手順と、接続方向で接続が行われます。  1.FTPクライアントは、エフェメラルポートからFTP制御ポートに接続します  2.FTPクライアントはデータ転送用のポート番号をサーバに通知します  3.FTPサーバはFTPデータ(20)ポートから2.で指定されたポートに接続し    にいきます  4.ファイル転送が開始されます このように、通常のファイル転送であれば、少なくともサーバ側のポートは特定することができます。しかし、データ転送する際の接続方向(サーバ→クライアント)と、接続先のポート番号が通常1024より大きく、また、その時によって番号が異なることが問題になる場合があります。
  81. &amp;lt;number&amp;gt; このページも、FTPサービスがなぜパケットフィルタでフィルタリングしにくいのかを説明しています。FTPには、PASVモードという転送モードがあります。この時には、ファイル転送は次のような手順と、接続方向で接続が行われます。  1.FTPクライアントは、エフェメラルポートからFTP制御ポートに接続します  2.FTPクライアントはPASVコマンドを発行  3.サーバは接続するポート番号をクライアントに通知します。通常、このポー    ト番号はエフェメラルポートです  4.FTPクライアントはエフェメラルポートから、指定されたFTPサーバのエフェメラルポートに接続しに行きます  5.ファイル転送が開始されます このように、PASVモードのファイル転送では、サーバ側、クライアント側どちらも1024より大きなエフェメラルポートを使用します。しかも、使用されるポート番号も接続のたびに変わります。そして、データ転送する際の接続方向(クライアント→サーバ)と、接続元/先のポート番号が通常の1024より大きく、また、その時によって番号が異なることが問題になります。
  82. &amp;lt;number&amp;gt; WebDAV自体にも、いくつかの欠点はあります。 しかし、商業サーバではないので、問題の起きない組み合わせでのみサポートすればよいという「思い切り」も可能ですので、思い切ってWebDAVのみをサポートしてしまえばよいでしょう。サーバのWebページコンテンツの更新用と割り切ってしまえば標準状態での日本語の扱いがうまくない点も全く問題になりません。  ※Webページのファイル名に日本語は使いません。 ただし、セキュアにしようとして、ダイジェスト認証モジュールなど標準ではインストールされないモジュールを追加で入れた場合、RPM/deb等の自動アップグレードで「バイナリ互換性がないアップグレード」が行われた場合、apacheサーバそのものがサービスとして起動できない状況になることが多いため、この点は注意が必要です。  ※WebDAV自体もapache 2.xより前は標準ではインストールされませんでし   た。
  83. &amp;lt;number&amp;gt; ここはメモ欄です。
  84. &amp;lt;number&amp;gt; Webサーバのapacheについても構築上の注意点があります。 自分でapacheサーバを起動したら、Netcraftのサイト(http://www.netcraft.com) に行って、自分のサーバからどんな情報が引き出せてしまうのか見てみましょう(下図は一部を切り出したものです)。 このように、OSの種別や、apacheのバージョン、組み込まれているモジュールのバージョン等、多くの情報をapacheサーバはクライアントに与えるため、脆弱性などがでた場合に、これらの文字をチェックして「問題のあるバージョンであれば脆弱性をつく」というようなワームがでてきます。 そこで、これらの情報をクライアントに表示しない設定にすることは重要です。
  85. &amp;lt;number&amp;gt; ここはメモ欄です。
  86. &amp;lt;number&amp;gt; ここでは、Webサービスでのユーザ認証について議論します。 基本的に、Webサービスでのユーザ認証には2つの方法があります。  1.BASIC認証(標準)  2.ダイジェスト認証 これらのうち、BASIC認証というのは実はパスワードはMIMEエンコードされているだけです。通信を傍受・盗聴された場合、MIMEエンコードは暗号化ではない(可逆性があるので)ので簡単にパスワードを入手されてしまいます。  ※最近ではネットワークキャプチャソフトウェアのWireSharkを使うと自動的にデコードして表示してしまいます。 これに対して、ダイジェスト認証はMD5でハッシュのみがネットワーク上を流れるため、ほぼ安全です(ハッシュには可逆性がないため)。 このダイジェスト認証は、CentOSのapache 2.0以降であれば標準的に組込済みのモジュールですので、安全に使用することができます。 このような幸せな状況の場合はよいのですが、そうでない場合は「Experimental(実験的の意。通常、このようなモジュールは標準で組み込まれません。)」のモジュールですので、手動で組み込まなければなりません。
  87. &amp;lt;number&amp;gt; ここでは、apache 1.3.26でmod_auth_digestモジュールを手動でインストールする方法を説明しています。 実際には、使用しているディストリビューションにインストールされているapacheのバイナリに対応するソースコードを入手して作業を行います。 Apache 2.x系の場合、手順5.は記述方式が以下のようになります。 LoadModule auth_digest-module modules/mod_auth_digest.so ※CentOSでは、Apache 2.x系を採用していますので、すでに標準でバイナリ モジュールが組み込まれていますので、これらの作業は必要ありません。
  88. &amp;lt;number&amp;gt; ここはメモ欄です。
  89. &amp;lt;number&amp;gt; NTP(ネットワーク時刻プロトコル)についても検討しましょう。 NTPはインターネット上で正確な時計と時刻同期を行うプロトコルです。 Linuxサーバでは、時刻同期を行うのに、   1.NTPdサーバを使用する方法   2.ntpdateを自動実行する方法 があります。 「正確な時計と同期する」ことは、「正確な時刻を記録する」ことにつながり、ログの正確性を担保するためにも必要であることはわかるでしょう。その他にも、正確な時刻というのは様々な面で有利なことがあります。 1.のデーモンで動作させる場合、いくつかの注意点があります。  ・NTPでは、各サイトが基本時計を根(ルート)として、木構造に構造されて   おり、深さのレベルをストラタムという名前で表現します。根元はストラタム   1です。ストラタムは1~15までの値を取ります。  ・NTPデーモンでは、最低でも、自分より上位のストラタムのNTPサーバ2つ、   もしくは、上位ストラタムのサーバと同レベルストラタムのサーバ1つずつ   指定します(ネットワークの遅延を計算するために必要)。  ・NTPサービスを公開サービスにするのでない限り、他のサイトからの問い   合わせに応答しないように設定しましょう。
  90. &amp;lt;number&amp;gt; デーモンで起動する場合、公開NTPサーバ(日本国内では(独)情報通信研究機構(=NICT)がStratum1、他はほとんどがStratum2です)を任意に2つ選んで起動するのが普通ですが、使用しているプロバイダでNTPサーバを公開している等、ネットワークの遅延がある程度一定していることが期待できる場合は、デーモンを起動せずにntpdateコマンドを自動起動する方法で時刻の同期を取ることもできます。 管理するサーバが多数ある場合や、管理するサイトで全コンピュータの正確な時刻同義が必要な場合はNTPデーモンが動くサイトのNTPマスターサーバが必要になりますが、それ以外の場合は、上記のように一定時間毎にntpdateコマンドを実行する方法も、簡単です。 公開NTPサーバについては、国内では次のような公開サービスが利用できます。  ※NICT 公開NTPサービス: http://www2.nict.go.jp/w/w114/stsi/PubNtp/  ※MFEED時刻情報サービス for Public: http://www.jst.mfeed.ad.jp/  ※NTP service : ntp.ring.gr.jp: http://ring.maffin.ad.jp/ring/ntp.html.ja また、Linuxサーバは「立ち上がったあとはハードウェア時計を見にいかずにソフトウェア的に時刻を管理する」=ソフトウェアクロック方式を採用しています。このため、システムを再立ち上げしたりするとBIOSが管理するハードウェアクロックが大きくズレていたりする経験をしたこともある人が多いと思います。 このような不具合を防止するために、一日に一回ソフトウェアクロックとハードウェアクロックを同期しておきましょう。
  91. &amp;lt;number&amp;gt; Webminは、システム管理者がWebブラウザ経由でサーバーのメインテナンスを行えるようにするユーティリティです。Perlによるモジュール構成になっていて、日本語画面にも対応しています。 また、サーバー上で動作しているサービスを監視し、停止していた場合にサービスを復旧するためのコマンドを指定しておくなどが可能です。 ほかにも、アクセスページがSSLページになっていたり、Webminページへのアクセスの試みなどを記録したり、アクセス元を制限するなどの、セキュリティに配慮した設定もできるようになっています。 WebminはJamie Cameron氏が開発し、公開しています。 ソフトウェアの入手とコンパイル Webminを導入する場合、まずはディストリビューションに既に含まれていないかどうかを確認しましょう。次に示すディストリビューションには標準で含まれているはずです。   HOLON Linux   Miracle Linux   TurboLinux   Mandrake Linux   VineLinux パッケージとして含まれていない場合、または、最新のバージョンを使用したいなどの場合は、ソースコードを入手してコンパイルすることになります。ダウンロードは、http://sourceforge.net/projects/webadmin から行います。
  92. &amp;lt;number&amp;gt; (続き)ソースコードも、同じURL からダウンロードすることができます。RPMベースのディストリビューションの場合は、上記ページから、webmin-x.xxx-1.noarch.rpmかwebmin-x.xxx-1.src.rpmをダウンロードして、rpm/rpmbuildコマンドを利用してコンパイル/インストールを行うのが手軽です。うまくいかない場合は、webmin-x.xxx.tar.gzを使ってコンパイル/インストールを行うこととなります。作業方法は、Webmin本家(http://www.webmin.com/)のドキュメント に従って作業します。 なお、セキュアな接続を行うためにopenSSLを使うためのperlモジュール Net:SSLeayをインストールしておく必要があります。 セキュリティを設定する インストールが完了したら、そのままではlocalhost上のみしかWebminにアクセスできない場合、/etc/webmin/miniserv.conf中の以下の行を修正しましょう。逆に、allow行がない場合、修正行のような行を付け加えましょう。 修正前: allow=127.0.0.1 修正後: allow=127.0.0.1 123.456.789.0/255.255.255.0 *.example.co.jp ここには、スペースで区切ったアクセス可能なホストの名前やIPアドレスを羅列します。*.jipdec.jp や、192.168.1.* などの表記ができます。設定したら、webminを再起動しましょう。RPMパッケージでインストールしていれば、/etc/rc.d/init.d/webmin restart で再起動することができます。 ブラウザでhttps://サーバー名:10000 にアクセスすると、左上のような表示がありますが、これはhttpsのアクセスにGnuPGの署名を利用しているためなので、驚かずに「はい」を選択します。すると、ログイン画面になるので、初回はID=rootでログインします。
  93. &amp;lt;number&amp;gt; 「Webmin設定」タグを選択すると、「IPアドレスのアクセス制御」、「ポートとアドレス」、「認証」の3つのセキュリティ設定を設定できるので、これらの画面を使って、Webminのセキュリティ設定を行いましょう。 特に、「認証」のページでは、パスワードのタイムアウト設定をきちんとやっておきましょう。これを設定しておけば、機械的にパスワードアタックをかけられる頻度を調整することができるようになります。  ※逆に、あまり厳密な設定をすると、1回パスワードエラーをするだけで指   定された時間アクセスできなくなったりしますが・・・。 日本語メニューに切り替える Webminは標準で多言語対応をしています。一般にただインストールした場合は、標準で英語メニューになっていますが、指定がない場合のシステム全体のメニュー言語の設定や、追加するユーザ毎にもメニュー言語を設定することができます。これは、インターナショナルな環境ではたいへんに便利です。 ここで、システムのデフォルトのメニュー言語を日本語に変更する場合を説明すると、最初にログインした状態で、「Webmin」タブの「Change Language and Theme」を選択します。そこで、「Webmin UI language」を「Global Language (English)」から、「Personal Choice..」に切り替えて、プルダウンメニューから、「Japanese(JA_JP.EUC)」を選択し、「Make Changes」ボタンを押すだけです。 (このあと、「Return to Index」を押すことで、メニューが日本語に切り替わります) Webminはこのように非常に多機能なツールです。色々な管理画面が安全にWebブラウザで設定できるようになっていますので、ぜひ色々と使ってみて下さい。
  94. &amp;lt;number&amp;gt; ここはメモ欄です。
  95. &amp;lt;number&amp;gt; PortSentryは、TCPやUDPでのポートスキャン、その他の怪しいポートスキャンをフルオートで検出し、そのパケットの遮断やターゲットIPアドレスに対する指定コマンドの実行、パケットフィルタの追加などでターゲットIPアドレスのトラフィックの遮断などを自動的に行ってくれるユーティリティです。 一般的にサーバに対する攻撃は(自動ツールも含めて)、事前に何らかのポートスキャンがあることが多く、その意味ではこのユーティリティは効果がとても大きいものです。 ソフトウェアの入手とコンパイル このソフトウェアは、(それ以前は違ったのですが)GPLライセンスで公開され、SourceForgeのSentryToolsプロジェクトのサイト(http://sourceforge.net/projects/sentrytools/)からダウンロードすることができます。また、英語ですが、以下のサイトが詳しく情報が掲載されています。PortSentryは、1.2が最新で、Craig H. Rowland氏が開発、公開しています。  http://linux.cudeso.be/linuxdoc/portsentry.php SourceForgeのサイトから、最新版のportsentry-1.2.tar.gzをダウンロードしたら、 # tar zxvf portsentry-1.2.tar.gz # cd portsentry_beta # make linux # make install で、/usr/local/psionic/portsentry ディレクトリ以下に実行プログラムや設定ファイルなどがインストールされます(CentOS4以降のgcc 3.4.3以降では、portsentry.cの1584-1585行目でコンパイルエラーが起きますが、行を連結して下さい)。
  96. &amp;lt;number&amp;gt; PortSentryを設定する PortSentryの設定は、/usr/local/psionic/portsentry/ 下の以下のファイルで行います。   portsentry.conf: マスターの構成定義ファイル   portsentry.ignore: チェックを無視するサイトを設定 また、過去のブロックの記録は以下のファイルに取られます。   portsentry.history: (これはログファイルです)   portsentry.blocked: (これはログファイルです) portsentry.confでは、上記以外にも以下のチューニングオプションがあります。  ・TCP_PORTS/UDP_PORTS :    TCP/UDPそれぞれの監視するポートを指定します。  ・RESOLVE_HOST :    判定やログにIPアドレス→FQDN名への変換を行ってから行うかを指定    します(On = 1, Off=Else)。Onにすると、DoS攻撃に弱くなる可能性もあ    るので、この指定には注意が必要です。  ・BLOCK_TCP/BLOCK_UDP :    TCP/UDPへのそれぞれのアクセスに対して、「記録だけ取る」、「disable   にする」、「何もしない」を指定します。ハーフオープンステルススキャン    (TCP)や、UDPアクセスでは、IPアドレスが詐称できてしまうので裏をか    かれると、DoS状態になるので、その場合には「記録だけ取る」設定にし    なければならないかもしれません。
  97. &amp;lt;number&amp;gt; PortSentryを正しく設定していると、このようにパケットファイアウォールが設定されたり、tcp_wrapperの設定が行われたりします。 ただし、これらのフィルタ設定は「自動的に削除されたりしない」ので、放置しておくと大量の(おそらく二度と使われない可能性のある)フィルタルールが蓄積されていきます。 これは、あまり大量になるとTCP/IPの性能劣化につながる可能性もでてきます。 実際には、cron等で一定時間毎(2日に一度とか、一週間の指定曜日など)に /etc/rc.d/init.d/iptables restart を実行するように指定して、溜まってしまったフィルタルールをリフレッシュしてあげましょう。  ※ただし、パケットフィルタの設定とポリシによっては、restartは危険なので    注意しましょう・・・というお話はすでにしました。
  98. &amp;lt;number&amp;gt; ここはメモ欄です。
  99. &amp;lt;number&amp;gt; SELinux(Security-Enhanced Linux)は、米国家安全保障局(NSA)が中心となって開発されている「セキュリティ拡張されたLinux」です。GPLで公開されています。Linuxカーネル2.6では、カーネル構造にLSM(Linux Security Modules)インタフェースが導入されたことから、SELinuxの機能がカーネル本体に統合されました。 これを受けて、CentOSは標準でSELinuxに対応した状態で配布されています(しかも、標準設定のままインストールすると、自動的に有効になります)。 SELinuxは基本的に、「事前に許可された資源」、「事前に許可された権限」、「事前に許可された権限の昇格」を「強制」するLinuxです。これらの機能を実現するのが、SELinuxの次の機能です。  ・MAC(強制アクセス制御)  ・TE(プロセスのアクセス強制)  ・ドメイン遷移  ・RBAC(役割ベースのユーザアクセス制御) ただ、利便性を優先した設定として、ルールが事前に設定されていないものは従来のLinuxと同様の動き方をするように(policy=targeted)設定されているので、「事前にどれだけ必要十分な設定をしておくか」が大変重要です。 さらに、CentOSでも利用者の便を図って「ひ弱な」設定になっている部分もある(sshdやX-Windowの設定など)ので注意が必要です。
  100. &amp;lt;number&amp;gt; CentOSでインストール時にSELinuxを指定してインストールしなかった場合、SELinuxを使用するには、次のようにします。  1./etc/sysconfig/selinux ファイルの中身を以下のように書き換える。    selinux=enforcing  2.コマンドラインで、次のコマンドを実行する(時間がかかります)。    # fixfiles relabel  3.システムをリブートする。 逆に、SELinuxを無効にするには、/etc/sysconfig/selinuxファイルの中身を次のように変更してリブートします。再度、有効にする場合には上記の手順をやり直します。 selinux=disabled 自分で新規にプログラムを導入したり、不具合を修正する場合には、上記の~情報源~や、「SELinuxシステム管理― セキュアOSの基礎と運用」、 「日経Linux別冊 セキュアOSによるシステム構築と運用 SELinux徹底ガイド」を参考にするとよいでしょう。 SELinuxシステム管理― セキュアOSの基礎と運用: Bill McCarty 著田口 裕也、根津 研介 監訳288ページ 定価2,940円 ISBN4-87311-225-7
  101. &amp;lt;number&amp;gt; TOMOYO Linuxは、プロセスツリーと名前ベースでの実行状態を覚えておき、これを強制アクセス制御(MAC)情報として使用するプロファイリング型の国産セキュアOSです。SELinuxのような複雑なポリシー管理を必要としません。 TOMOYO Linuxに関する情報源: http://tomoyo.sourceforge.jp/  ※メーリングリストもあります。 ソース&amp;バイナリのダウンロード: http://sourceforge.jp/projects/tomoyo/  ※CentOS用のバイナリパッケージ(rpm)も公開されています。パッケージを    インストールさえすればとりあえず使い始められます。 技術評論社の「Network Security Expert Vol.5」の特集記事、および「Software Design 2007/01号からの連載」もオススメです。 自分でカーネルをいじってみたい人はそのサンプルにもなるでしょう。
  102. ここでは、実際にサーバ上で、各種のログ監視ツールや状態を監視するツールについてどのような点について注意して構築し、運用管理すればよいか? また、どういう観点で監視を行えばいいかについてお話してゆきます。 ここからの内容も、皆さんに実際に演習として設定していただきます。 よく内容を理解し、手順を頭に入れて、効率よく設定を進めていくようにしてください。 なお、演習中、不明点などがあった場合は、参加者同士で教えあったり、講師に聞きながら、(テストなどではありませんので)考え方や方針といったものを会得するようにしてください。 単純に手順だけ覚えるよりも、得られるものも多く、応用が利くようになるのは構築と同じです。
  103. &amp;lt;number&amp;gt; この表は、これから紹介するユーティリティの一覧です。これらのユーティリティはおおよそ次の三つの種類に分類することができます。  ・ログを取得するツール  ・ログ中の指定のログを通知するツール  ・マシンやサービスを監視・運用するツール ※ディストリビューションに入っていない場合、http://www.rpmfind.netでの   検索や、各ディストリビューションのftpサイトのuntested / updated /   contributedなどのディレクトリ、sourceforge等も探してみましょう。 ※debianでは、apt-getでほとんどのものがインストールできます。 ※CentOSでは、いくつかのyum/apt-getサイトの追加でほとんどのものがイン ストールできます。たとえば、/etc/yum.repos.d/ に以下のファイルを追加しま す。この場合、それぞれのGPGキーをRPMに登録しなければなりません。 dag.repo: [dag] name=Dag RPM Repository for Red Hat Enterprise Linux baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag gpgcheck=1 enabled=1 dries.repo: [dries] name=Extra Fedora rpms dries - $releasever - $basearch baseurl=http://ftp.belnet.be/packages/dries.ulyssis.org/redhat/el4/en/i386/dries/RPMS
  104. &amp;lt;number&amp;gt; ここで表記しているものは、RedHat系ディストリビューションにおける通常の監視対象となるログファイルです。  ※Debian系では、また構成が異なります。 このログファイルは、cronの機能でlogrotateスクリプトを起動し、logrotateによりバックアップがどんどん作られていきます。
  105. &amp;lt;number&amp;gt; atd/crond/anacronは、システムの自動実行管理を行うユーティリティです。 atdデーモンへの指示は、atコマンドで行います。例えば、公開ホームページの入れ替えを、ユーザの一番アクセスの少ない時間帯で行おうとした場合(大抵は明け方などになります)に、その作業のためにのみ管理者が起きていて手動で作業をするというのは現実的ではありません。このような時に、新旧のホームページのディレクトリを用意しておいて、atコマンドで自動切り替え=ディレクトリ名の入れ換えを行うようなコマンドを与えておくだけで、管理者は枕を高くして眠っていることができます。 crondデーモンは、atdデーモンと異なり、一度だけではなく、決まった曜日、時間、月間隔で定期的に実行するコマンドを指定する場合に使用します。anacronは、毎日1回、週に1回、月に1回で指定されたディレクトリにあるコマンドスクリプトを実行します。ただし、anacronの機能はcronで代替することができます。 これらのプログラム/デーモンは、システム管理者の強い味方です。
  106. &amp;lt;number&amp;gt; ここはメモ欄です。
  107. &amp;lt;number&amp;gt; Iplogger/ippl/iplogは、ともにTCP/UDP/ICMPのそれぞれのトラフィックをログに記録してくれるソフトウェアです。ディストリビューションに標準で入っていることも多いのですが、新規に導入する場合は、iplogの方が機能が高いため、こちらを導入することをお勧めします。 ここではiplogに話を限定します。 iplogは、Ryan McCabe 氏により公開されており、次のような豊富な機能を持っています。  ・TCP/UDP/ICMPそれぞれのトラフィックのログを取る  ・TCPのコネクト/ハーフオープン/FIN/XMAS/NULLスキャンを検出しログを  取る  ・UDPスキャンのログを取る  ・ping flood, SYN flood, SMURF, フラグメント攻撃を検出しログを取る  ・bogus TCPフラグを検出しログを取る  ・tracerouteを検出しログを取る  ・スキャンしてきたホストの名前でログを取る ちなみに、bogus TCPフラグとは、nmap等が利用しているOSを判定するためのフラグが設定されたTCPパケットのことを指します。このようにiplogでは、多くのポートスキャンを検出する能力を持っているのです。
  108. &amp;lt;number&amp;gt; ソフトウェアの入手とコンパイル iplogを導入する場合、まずはディストリビューションに含まれていないか確認した方がよいでしょう。含まれていれば、ソースコードの入手やコンパイルといった作業の必要がないからです。もし、ディストリビューションに含まれていない場合は、ソースコードからのコンパイルが必要になります。ソースコードはhttp://ojnk.sourceforge.net/から入手します。また、コンパイルにはlibpcapが必要になるので、大抵のディストリビューションには含まれているので、もしインストールしていなければ先に済ませておかなければなりません。最新版は、iplog 2.2.3です。コンパイルは、ソースコードを展開したディレクトリで ./configure make make install を実行するだけです。標準で、iplog本体は/usr/local/sbin/iplog にインストールされるので、/etc/rc.d/rc.local に以下のように記述を追加しておけばサーバー起動時に自動的にサービスも起動されるようになります。 /usr/local/sbin/iplog &amp; ディストリビューションに含まれていたり、RPMでインストールした場合は、Red Hat 系の場合、起動用のスクリプトが/etc/rc.d/init.d/iplogにあるので、 chkconfig --add iplog とすることで、起動時に自動的にサービスが起動されるようになります。また、コンフィグファイルのサンプルが/usr/share/doc/iplog-2.2.3/example-iplog.conf にあるので、これをテンプレートとして/etc/iplog.confにコピーして必要なところを編集してから起動します。
  109. &amp;lt;number&amp;gt; ログ出力のカスタマイズ iplogを起動してしばらくすると、前ページのようなログが/var/log/messagesにかなりの量吐き出されてくるようになります。このようにiplogではアクセスしてきた先のIPアドレスを名前解決してホスト名でログに記録しようとします。また、nmap等のユーティリティで連続したポートスキャンを受けた場合、特にこれを記録したりする機能もあります(前ページの(1))。このソフトウェアの最大の欠点は、標準ではトラフィックのログをのべつまくなしに根こそぎ取ってしまうことです。つまり、通常「ログを取っても意味のない正常なログ」も出てきてしまうのです。これではログのパーティションが幾つあっても足りません。例えば、サーバーでWebサーバーや、DNSサーバー、メールサーバーを上げている場合には、これらのアクセス制御していないトラフィックはログに取りたくない場合が多いはずです。このような場合には、/etc/iplog.conf(iplog 2.1.xでは/etc/iplog.rules)ファイルを作成して、上記のような設定をすることでログを取らないトラフィックを指定するといったカスタマイズを行います。このカスタマイズはサイトで動いているサーバーやトラフィックの量に依存するので、実際にシステムを運用しながら、ログファイルを見て、監視項目から外すトラフィックを追加して記述していくことになります。 また、先に触れたホスト名を名前で記録する機能などは、サーバーが全IPアドレスをホスト名に変換しようとしてDNSの問い合わせを行ってしまうために、DoS攻撃に弱くなるという弱点になり得ます。そこで、この変換を行わないというデフォルト値は変更しないようにします。このほかにも、iplogでは、/etc/iplog.confで様々なカスタマイズを行うことが可能です。カスタマイズできる項目や指定の詳細は、man iplog.conf でオンラインマニュアルを参照してください。
  110. &amp;lt;number&amp;gt; 誤認に対する注意 iplogでは、特定のIPアドレスから連続したアクセスがあったときにポートスキャンと判定してしまいます。例えば、上記のログ(1)の例では、これはポートスキャンではなく実際はWebサーバーへのアクセスです。これは、ログ(2)の実際ののポートスキャンと比べてみればすぐに分かります。このほかにも、ftpサーバーを上げている場合、ファイル転送時のポートが通常は規定のポートではなく、ポートスキャンのように見える場合が多いので、この場合もログファイルの前後を確認してftpへのログインなどがないかどうかを調べなければならなりません。 また、先にも触れましたが、icmpとudpはIPアドレスの詐称が簡単にできてしまいます。したがって、icmpとudpのログは基本的に「何らかのポートスキャンが行われた」ことを示しているだけで、ホスト名/IPアドレスは信用できないものと考えた方が無難です。このログを元に、プロバイダやIPアドレスの所有者に嫌疑をかけると無実の罪になってしまう可能性がかなりの確率であると考えるべきなのです。もし、先方に問い合わせる場合には、これを十分に理解した上で、調査協力のお願いの形を取るべきです。
  111. &amp;lt;number&amp;gt; ここはメモ欄です。
  112. &amp;lt;number&amp;gt; logwatch/logcheckは、システムのログを一定時間ごとに検査して、その結果をメールで報告するツールです。logwatchは検査結果のサマリをメールで、logcheckは登録されているキーワードに該当するエントリから続くエントリをメールで、いずれもroot宛に送付します(logwatchは/etc/log.d/logwatch.conf で送付先をカスタマイズできます)。 大抵はいずれか一方がディストリビューションに含まれているはずです。CentOSでは、logwatchが採用されています。 実際のところ、logcheckは情報の精度があまり高くなく、メールの量が多くなる傾向が強く、あまり勧められるものではありません。少なくとも新規にlogcheckを入れるメリットはあまりありません。それよりは、後述するswatchによる監視の方が役に立つからです。そこで、ここではlogwatchについてのみ紹介します。 logwatchは、Kirk Bauer氏により公開されているツールです。これは、一日に一回動作させることを前提にしており、デフォルトで昨日分のログの解析を行います。解析は、グループごとに行われ、指定されたメールアドレスにサマリを送ります。 このように、各種のサービスがどの端末からリクエストされたのかや、利用頻度、ディスクの空き領域、エラーなどがサマリとしてメールされてきます。この情報から普段のサーバーのアクティビティを知っておくことで、異常なアクティビティを見分けることができ、侵入の形跡を発見できる場合があります。
  113. &amp;lt;number&amp;gt; ソースコードの入手とコンパイル logwatchを導入する場合も、まずは使用するディストリビューションに含まれていないかどうかを確認しましょう。もっとも、logwatch自身がPerlで記述されているため、ソースパッケージから入手してインストールするのもそれほど難しいものではありません。ソースパッケージは、http://www.logwatch.org/tabs/download/ からダウンロードします。最新版はlogwatch 7.3です。もし、5.2.2より古いパッケージを使っている場合は、含まれているsudo関連のスクリプトにバグが残っていることもあり、若干の修正が必要なので5.2.2以上を入れましょう。また、ソースパッケージもソースRPM形式も用意されているので、RPM系のディストリビューションを利用しているのであれば、logwatch-7.3-1.src.rpm をダウンロードしてきて、 rpmbuild --rebuild logwatch-7.3-1.src.rpm でバイナリRPMを作成すれば、インストールも簡単な作業になります。なお、バイナリRPMは、logwatch-7.1-1.noarch.rpm になるので注意してください。 カスタマイズ カスタマイズは、構成定義ファイル /etc/log.d/logwatch.confを変更します。変更のポイントとしては、  ・MailToは標準ではrootだが、管理者が普段使用しているメールアドレス   に変更する  ・mktemp --helpを実行してみて、-dオプションがサポートされていないなら   ば、UseMkTempをnoに設定します。 ・Detailはレポートの詳細さを制御します。0-9の値をとりますが、デフォルトで   は0です。数字が大きいとより詳細なレポートがでます。慣れるまでは大きめ   がいいでしょう。
  114. &amp;lt;number&amp;gt; ここはメモ欄です。
  115. &amp;lt;number&amp;gt; TripWireは、ファイルの改ざんをチェックできるツールです。基本的には、各ファイルの「署名」を作成して、これを署名付きデータベースに保存しておき、定期的に実際のファイルから計算された署名と比べることで改ざんをチェックできるようになっています。商用版とフリーソフトウェア版があり、多くのディストリビューションで一時期、標準でフリーソフトウェア版が含まれていました。 TripWireは、TripWire Inc.が公開しています。 ソフトウェアの入手とコンパイル TripWireも、まずはディストリビューションに含まれていないか確認します。あれば、コンパイル/インストールの手間がないからです。含まれていない場合はソースコードからコンパイル/インストールすることになります。ソースコードは、http://sourceforge.net/projects/tripwire からダウンロードします。最新版は、TripWire 2.4.0.1 です。 コンパイルには、g++ を使うので、gccのg++機能がシステムにインストールされていなければなりません。標準ではダウンロードしたソースアーカイブを展開したディレクトリで、 cd src gmake release cd .. ln -sf install/install.sh . ln -sf install/install.cfg . ./install.sh を実行します。
  116. &amp;lt;number&amp;gt; あとは指示に従ってインストール作業を行う。サイトパスフレーズとローカルパスフレーズを設定すればあとは自動的に行われます。ディストリビューションに含まれている場合は、最後の./install.shが/etc/tripwire/twinstall.shになります。作業手順は上記のようになります。 また、twcfg.txtとtwpol.txtの設定上の注意点としては、  ・twcfg.txt中の$HOSTNAMEは書き換えできない  ・twpol.txtサンプルは古いRedHat Linuxを基準にしているので、ディストリ   ビューションに合わせて修正が必要! という点が挙げられます。ここまでできたら、あとはディストリビューションからインストールした場合は、cronで自動的に一日一回自動的に起動されるようになります。また、手動でインストールした場合は、crontab -e で、 0 4 * * * /usr/sbin/tripwire --check を登録します。 実行結果は、root宛のメールで送られてきます。しばらく運用してみてsyslogファイルなどのエラーが目立つ場合には、上記の4~7の作業を繰り返すことになります。
  117. &amp;lt;number&amp;gt; (ここは空白です)
  118. &amp;lt;number&amp;gt; (ここは空白です)
  119. &amp;lt;number&amp;gt; この出力では、  ・Critical configuration filesの分類で、変更されたファイルが3つあること  ・System boot changesの分類でファイルの追加が4つ、削除が一つ  ・Root config filesの分類で変更されたファイルが3つあること が分かります。 このように、tripwireでは構成定義ファイルで分類されたそれぞれについて、追加や削除、変更の記録を取ることができます。
  120. &amp;lt;number&amp;gt; AIDEは、Advanced Intrusion Detection Environmentの頭文字を取ったソフトウェアで、tripwireとほぼ同じようなことをおこなってくれるソフトウェアです。 AIDEは、Rami Lehti氏、Pablo Virolainen氏、Richard van den Berg氏によって作成され、公開されているソフトウェアです。GPLライセンスで配布されています。 現在の最新版は、0.11です。 詳細は、AIDEの以下のページを参照してください。  http://www.cs.tut.fi/~rammer/aide.html AIDEの一番の特徴は、tripwireで言うところのポリシーを、ディレクトリの単位で自由な組み合わせで指定できることで、これがあるために、tripwireで必要だった、一覧リストの作成という苦渋の作業をほぼ無くしてしまったことです。 AIDEのカスタマイズは、オンラインマニュアルのaide.conf(5)、aide(8)を見てください。 操作の基本は、  ・初期化: aide --init  ・チェック: aide --check  ・コンペア: aide --compare などと、ほとんどtripwireと同じです。
  121. &amp;lt;number&amp;gt; ここはメモ欄です。
  122. &amp;lt;number&amp;gt; webalizerとanalogはどちらもWebサーバーに対するアクセスの統計情報ページを作成するツールです。違いは、analogの方には簡易的なGUIのカスタマイズインタフェースがあることと、より詳細な解析が行えることが挙げられます。 これらのツールは、Webサーバーを上げているときのみ有効です。また、システムを管理するという観点でいうと、Webトラフィックの普段のアクセス状況と特異な状況を判断するのに使用することができます。この意味で、詳細な解析というよりはWebサーバーが記録するログを短時間で眺めて傾向を把握しやすいwebalizerの利用の方が使い勝手が良い場合が多いでしょう。 webalizerは、Bradford L. Barrett氏によって公開されており、  ・Webサーバーのcommonレコード形式と、combinedレコード形式に対応  ・ftpサーバー(wu-ftpd)の転送ログ形式に対応  ・squidプロキシーサーバーのログ形式に対応  ・html/テキスト出力形式に両対応  ・複数ファイルに分割されたログに対応(Incrementalモード)  ・リバースDNS機能を内蔵  ・解決済みDNSをキャッシュする機能を内蔵  ・データベースに入力可能なダンプファイルを作成可能  ・日本語ページを作成可能 のような機能を持っています。webalizerが主とする対象はもちろんWebサーバーですが、それ以外にもftpサーバーの転送ログや、squidプロキシーのログの解析にも対応しています。
  123. &amp;lt;number&amp;gt; Webalizerでは、Webサーバーのログ形式をcombinedにした場合、参照元サイトやブラウザ種別の統計解析も出力することができます。Incrementalモードで動作させた場合、前回、解析済みの情報をファイルから読み出す事で差分のログだけを処理する機能もあります。これは負荷の低減に役立ちます。また、analogで問題になるWebサーバーのログがIPアドレスで行われていた場合でも内蔵のリバースDNS機能でホスト名に変換し、かつ、それをキャッシュする機能まで内蔵しています。そして、ダンプ機能を利用すれば、データベースやMicrosoft Excelなどに直接入力可能な、タブで区切られたCSVファイルを出力することもできます。特に最後の機能はExcelでアクセスレポートを提出するような場合にはたいへん重宝するでしょう。 ソースコードの入手とコンパイル webalizerを導入する場合についても、まずは使用するディストリビューションに含まれていないかどうかを確認しましょう。大抵のディストリビューションには含まれているはずです。ただし、多くの場合、英語版のバイナリが含まれることが多いので注意が必要です。webalizerは、コンパイル時に使用する言語を決めうちにしてコンパイルしなければならないため、英語版のwebalizerでは、日本語によるレポートを出力することはできないからです。どうしても日本語で表示しなければならない理由がない限りは、素直にディストリビューションに含まれているバイナリを利用することをお勧めします。ソースコードからのコンパイルが多少面倒だからです。ソースコードからコンパイルする場合、http://www.mrunix.net/webalizer/ からソースコードを入手します。最新版は、webalizer 2.01-10です。コンパイルにはgdライブラリが必要なので、ディストリビューションに含まれているかどうか確認した上で、含まれているのであれば事前にインストールしておきます。gdライブラリをコンパイルしなければならない場合は、さらに事前にpngライブラリ、dbライブラリ、zlibライブラリ、jpeg-6bライブラリがインストール済みでなければならないので注意が必要です。
  124. &amp;lt;number&amp;gt; webalizerのコンパイルに必要なライブラリの関係を示すと以下のようになります。     必要なライブラリをそろえたら、実際にwebalizerをコンパイル/インストールします。ダウン     ロードしたソースアーカイブを展開したディレクトリで、      # ./configure --enable-dns --with-language=japanese      # make      # make install     を実行します。表に記載したライブラリをディストリビューション標準でなく手動でインストー     ルした場合には、configureに「--with-gd=ディレクトリ名 --with-gdlib=ディレクトリ名」などの     追加オプションが必要な場合もあります。詳細は、configureに—helpをみてください。      インストールに成功すると、実行バイナリは/usr/local/bin/webalizer(RPM でインストールした     場合は/usr/bin/webalizer)に、サンプルの設定ファイルが/etc/webalizer.conf.sample にインス     トールされます。実際の動作指定はコマンドラインオプションでも指定できますが、/etc/       webalizer.conf.sampleを/etc/webalizer.confにコピーしてこれを編集することでも指定できます。     構成定義ファイルの例は上記のようになります。 ライブラリ名 ヘッダー名 必要なパッケージ名 入手先 libdb.so db.h glibc-devel, glibc libpng.so png.h libpng-devel, libpng http://www.libpng.org/pub/png/libpng.html libjpeg.so jpeglib.h libjpeg-devel, libjpeg  http://www.ijg.org/ libz.so zlib.h zlib-devel, zlib      http://www.gzip.org/zlib/ libgd.so gd.h gd-devel, gd http://www.boutell.com/gd/
  125. &amp;lt;number&amp;gt; 実際にwebalizerを定期的に実行するように起動設定するには、rootでcrontab -e でcronの設定を行います。設定する項目としては、 300-23/2* * */root/do-webalizer などとしておいて、/root/do-webalizerは、上記のような設定をしておくと良いでしょう。 出力のカスタマイズ webalizerでも程度の差こそあれ、ユーザ情報やディレクトリ構成など一般に公開するには相応しくない情報も出力に含まれる場合があります。たとえば、認証付きページのディレクトリ構成やファイル構成が分かってしまったり、認証できたユーザ情報があったり、また、参照ページを操作することでgoogleなどの検索サイトのランキングを操作しようという意図に使われてしまうなどのケースもあり得ます。したがって、出力するWebページには厳重なアクセス制限をかけるべきです。具体的には、apacheなどでは、たとえばwebalizerの出力先を/var/www/html/webalizer/ とすると、httpd.conf で次のような認証を行う設定にするか、もしくはアクセス元を制限するようにしておくとよいでしょう。 &amp;lt;Directory /webalizer&amp;gt; AuthUserFile /home/httpd/.private AuthName AccessStatistics AuthType Basic &amp;lt;Limit GET HEAD POST OPTIONS&amp;gt; Require valid-user &amp;lt;/Limit&amp;gt; &amp;lt;/Directory&amp;gt;
  126. &amp;lt;number&amp;gt; どうしても公開したい場合には、webalizerの出力するグラフのみを公開するのが良いでしょう。これなら、一般に公開してもさほど問題にはならないはずだからです。たとえば、次のようなcronをcrontabで設定しておきます。 0 0 1 * * ln -sf /var/www/html/webalizer/daily_usage`date +%Y%m`.png /var/www/html/daily_usage.png これで、/var/www/html/daily_usage.pngを参照するページを作成しておけば、画像ファイルとして常に最新の月間アクセスグラフが表示できることになります。 なお、運用時に注目すべき項目としては、特に急激にヒット数が上がったり、レスポンスコードの400や404の回数が急激に上がったりしていないかに特に注意を払うようにしましょう。特に後者の場合、直接リンクされていないページを探索して回ったり、Webサーバーのバグを探して回っていたりする攻撃者がいる可能性があります。
  127. &amp;lt;number&amp;gt; ここはメモ欄です。
  128. &amp;lt;number&amp;gt; Analogは webalizerより詳細な統計がとれる反面、絶対に外部に公開してはならないような隠しディレクトリやユーザディレクトリの存在などが明らかになりやすい、実行時にすべてのログを検査するためCPU資源を浪費しやすいという欠点もあります。これらは、analogの実行をGUIで行わずにcronなどでバッチジョブとして実行することで改善することができます。しかし、Webサーバーの設定で、ログを取るときにIPアドレスをDNSでホスト名に変換する指定をしない場合に、国別やプロバイダ別の分類ができないという点は使いづらいところです。Webサーバーに高い負荷が想定される場合、すべてのリクエストをホスト名でログに記録していては、サーバーの処理が追いつかなくなるからです。このような処理を想定して、名前解決できないIPアドレスから大量のリクエストを発行することで簡単にWebサーバーがサービス停止状態になってしまうのでは脆弱性を導入したのと変わらないことになってしまいます。
  129. &amp;lt;number&amp;gt; (ここは空白です)
  130. &amp;lt;number&amp;gt; (ここは空白です)
  131. &amp;lt;number&amp;gt; (ここは空白です)
  132. &amp;lt;number&amp;gt; (ここは空白です)
  133. &amp;lt;number&amp;gt; (ここは空白です)
  134. &amp;lt;number&amp;gt; (ここは空白です)
  135. &amp;lt;number&amp;gt; (ここは空白です)
  136. &amp;lt;number&amp;gt; mrtgは、元々ネットワーク機器などのトラフィックを時系列でグラフ化するユーティリティです。サーバーで運用する場合、net-snmp(ucd-snmp)と組み合わせることでネットワークのトラフィック、CPUのロードアベレージ、メモリ空き容量などを時系列でグラフ化することができます。また、mrtg用のpingユーティリティを利用することで、特定サーバーとのping遅延をグラフ化することもできます。このユーティリティを用いて、通常運転時のサーバー状態を把握しておくことで、急激なトラフィックの発生やCPU負荷の発生など侵入の試みやDoS攻撃、侵入された場合の侵入者の活動によるサーバー資源の動きを把握することなどが可能になります。 mrtgは、Tobias Oetiker氏、Dave Rand氏により公開されています。 ソフトウェアの入手とコンパイル mrtgを導入する場合、ソースコードはhttp://people.ee.ethz.ch/~oetiker/ webtools/mrtg/から入手することができます。最新版は、mrtg 2.14.5です。展開したディレクトリ中のdoc/unix-guide.txtにインストール手順が書かれていますが、mrtgもコンパイルにwebalizerと同様、gdライブラリとこれに関係した一連のライブラリが事前にインストールされていなければなりません。また、Perlがシステムにインストールされていることも必要です。 必要なライブラリがインストールされていれば、コンパイルとインストールは、 ./configure --prefix=/usr/local/mrtg-2 make make install で簡単にできます。gdライブラリのインストール方法によっては、「--with-gd=/usr/local/include --with-gd-lib=/usr/local/lib」などのオプションをconfigureの実行時に付加しなければならないのもまったくwebalizerと同じです。
  137. &amp;lt;number&amp;gt; 今回、紹介するやり方では、/etc/mrtg というディレクトリを作成してここを作業ディレクトリにするので、ここへimages/下のファイルもコピーしておきましょう。ほかにも、実行時にはucd-snmp(net-snmp)とmrtg-ping-probeが必要になるので、こちらもそれぞれシステムにインストールしておきます。ucd-snmp (net-snmp)は大抵のディストリビューションでパッケージが用意されているので、これをインストールします。mrtg-ping-probeは、Peter W. Osel氏が公開しているmrtg用のpingのラッパーでPerl5.003以降で動作するPerlプログラムです。http://pwo.de/projects/mrtg/ 、またはftp://ftp.pwo.de/pub/pwo/mrtg/mrtg-ping-probe/からダウンロードすることができ、最新版は、mrtg-ping-probe Release_2_2_0です。ダウンロードしたソースアーカイブを展開すると、mrtg-ping-probe本体があるので、これもmrtgを実行する作業ディレクトリにコピーしておきます。 ucd-snmp(net-snmp)の構成定義 ここまで準備ができたら、ucd-snmp(net-snmp)の構成定義ファイル /etc/snmp/snmpd.confを設定します。設定例は上のようになります。このうち、コミュニティ名というのは、snmpdのパスワードのような役割を果たすので、慎重に設定しましょう。標準では、publicになっていますが、これは既定で既知の値なのでかならず設定を変更しておきます。また、syslocationとsyscontactは好みに応じて設定します。実際には、ucd-snmp(net-snmp)にはデーモンのプロセス数や、ディスクの空き容量、外部プログラムの実行による結果など、多くの機能があります。これらをmrtgで管理することも可能なので、チャレンジ精神が旺盛なみなさんはサンプルのsnmpd.confとオンラインマニュアル(man snmpd.conf)を参考に色々と設定を試してみましょう。
  138. &amp;lt;number&amp;gt; なお、snmpはプロトコルにUDP/161を使っており、IPアドレスの詐称が簡単にできてしまいますので、セキュリティ上、インターネットゲートウェイルータで宛先ポートがUDP/161のパケットの通過を拒否する設定をするか、または、Linuxのパケットフィルタでイーサネットインタフェースにくる宛先ポートがUDP/161のパケットをDenyするようにしておかなければならない点に特に注意が必要です。 mrtgの構成定義 ここまで準備ができたならば、ようやくmrtgの構成定義ができるようになります。mrtgには、cfgmakerやindexmakerという構成定義ファイルやWebページのテンプレートを作るユーティリティも添付されているので、これらのユーティリティを用いてテンプレートをベースにカスタマイズするか、または、今回、例示する構成定義例を利用してmrtgの構成定義ファイルを作成しましょう。なお、上記の設定例では、 mrtgの作業ディレクトリ: /etc/mrtg mrtgのWebディレクトリ:/var/www/html/mrtg mrtgの構成定義ファイル: /etc/mrtg/mrtg.cfg としています。
  139. &amp;lt;number&amp;gt; 最初に、mrtg.cfgのテンプレートを作成するために、 /usr/bin/cfgmaker --community=コミュニティ名 --output=/etc/mrtg/ mrtg.cfg localhost を実行します。 これで、インターフェースについての設定部分は自動的に作成されます。 また、mrtg-ping-probeを利用する部分は、mrtg-ping-probeのパッケージに含まれるmrtg-ping-cfgユーティリティを利用して、 mrtg-ping-cfg ターゲットのIPアドレス ターゲットの表記 &amp;gt;&amp;gt;  /root/mrtg/ mrtg.cfg でmrtg.cfgファイルに必要なターゲットの数だけ追加します。 実際に作成したmrtg.cfgをカスタマイズした例が前ページと本ページです。図中コミュニティ名となっているところは、実際に設定したコミュニティ名を指定します。また、IPアドレスやインタフェース、ping先など下線がついているところは書き換えて使用します。特に、ping先についてはサーバーが使用している上位プロバイダのゲートウェイなどと、IX(インターネットエクスチェンジ)を超えた著名なサイトなどを選ぶと良いでしょう。サーバーが遅いなどのクレームの際に、上位回線の障害なのか、それともIXが混雑しているために起きているのかの初期診断が可能になるからです。 なお、このファイルは最終的にnkfなどでJISコードに書き換えておく必要があるので注意してください。
  140. &amp;lt;number&amp;gt; (このページは空白です)
  141. &amp;lt;number&amp;gt; (このページは空白です)
  142. &amp;lt;number&amp;gt; (このページは空白です)
  143. &amp;lt;number&amp;gt; (このページは空白です)
  144. &amp;lt;number&amp;gt; mrtgトップページの作成 最後にmrtgのトップページの作成ですが、これは、http://www1.famm.ne.jp/ mrtg/index.htmlを取得して、これを参考にカスタマイズしてしまいましょう。インターネットエクスプローラであれば、[表示]-&amp;gt;[ソース]でソースが表示できるので、これをカスタマイズして使用すればいいことになります(簡単!)。 日本語ページにはなりませんが、mrtg付属のユーティリティindexmakerを使用して、 /usr/bin/indexmaker --columns 1 --enumerate /etc/mrtg/mrtg.cfg &amp;gt; /var/www/html/mrtg/index.html とすることで、トップページを簡単に作成してしまってもいいでしょう。 mrtgの定期的な実行 mrtgは、一定時間ごとに起動することで時系列のログが取れるようになっています。そこで、一般的にはcronを利用して5分おきにmrtgを実行するようにします。この場合、crontab -e で以下の行を追加すればよい。 0-59/5 * * * * /usr/bin/mrtg /etc/mrtg/mrtg.cfg snmpdの自動実行 最後にsnmpdを自動起動するように作り込みを行います。ディストリビューションでは自動起動のスクリプトが大抵提供されているので、RedHat系であれば、 chkconfig –level 235 snmpd on で自動起動するようになります。
  145. &amp;lt;number&amp;gt; ここはメモ欄です。
  146. &amp;lt;number&amp;gt; (このページは空白です)
  147. &amp;lt;number&amp;gt; swatchは、ログのように追加書き込みされていくファイルの最後を常に監視するツールです。ある意味で、‘tail -f’ の拡張版のような機能ということができます。監視する対象のログファイルの種別は問わない汎用のツールです。 swatchでは、構成定義ファイルに「興味ある文字列」を指定することでこの汎用性を確保しています。また、logrotateなどでログファイルのローテーションが行われる場合も、ファイルを最初から監視しなおす--restart-timeオプションで対応しています。このように、swatchはログを24時間365日監視してくれる電子の目ということができます。 swatchは、Todd Atkins氏により公開されていて最新版は、swatch 3.2.1です。 ソフトウェアの導入とコンパイル swatchを導入する場合、ソースコードパッケージをダウンロードしてコンパイル/インストールする必要があります。ソースコードは、http://sourceforge.net/projects /swatch/ からダウンロードします。コンパイル/インストール作業は非常に簡単な作業で、展開したディレクトリで、 perl Makefile.PL make make test make install を実行するだけです。これで、実行可能バイナリが/usr/bin/swatchとしてインストールされます。
  148. &amp;lt;number&amp;gt; 監視対象にするログファイル 最初に触れたように、swatch では様々なログファイルの監視が可能ですが、RedHat系のディストリビューションでは一般的なシステムログである、/var/log/messages 、/var/log/secure、/var/log/maillog あたりの監視から始めると良いでしょう。他にも、apacheのエラーファイルや、ftpサーバーの転送ログなどの監視にも応用することが可能です。 上記の例では、これらの標準的なシステムログファイルを監視するためのswatchをそれぞれ自動起動する設定になります。 設定ファイルのカスタマイズ swatchでは、一つの設定ファイルで一つのログファイルに対応した設定ファイルを作成するというのが一般的な使い方です。 次のページで、/var/log/messagesを監視するシンプルな例を掲載しています。設定していることは単純で、最初に、DMZやイントラネットからのアクセスを除外しています。ただし、これはゲートウェイルータで送信元のIPアドレスをDMZやイントラネットに詐称しているパケットをフィルタリングしていなければ危険な設定なので注意してください。 あとは、基本的なパターンとしては、ログから除外するパターンをignoreで指定して、残りをwatchforで引っかけてメールを送信するというものです。/refuse/ のところでthrottle指定しているのは、DoS攻撃の時に大量のメールが発生するのを抑止するためです。
  149. &amp;lt;number&amp;gt; swatchでは、構成定義ファイルでwatchforで指定できる「興味ある文字列」にもPerlの正規表現が使用できます。また、アクションにも次のように多くのオプションがあります。 アクション 意味 echo [mode]  マッチした文字列をコンソールに表示する。modeには、normal, bold, nderscore, blinkなど多くの指定が可能 bell [N]  マッチした文字列を表示して、ベルを鳴らす。Nには鳴らす回数を指定でき、デフォルトでは1 exec command commandで指定したプログラムを実行する。コマンドには、変数を含むことができ、$1 $2 $3 はそれぞれマッチした文字列の1番目、2番目、3番目のフィールドに置換される。$0と$*は文字列全体に置換される。 mail [addresses=addr,subject=title]           addrで指定したメールアドレスにtitleの表題でマッチした文字列を本文にしてメールを送信する。アドレスや表題を指定しなかった場合は、swatchを実行したユーザに表題が空のメールが送られる。 pipe command,[keep_open] commandで指定したプログラムにパイプでマッチした文字列を渡す。keep_openを指定した場合は、別のpipe指定がされるかswatchが終了するまでパイプはオープンされたままになる write [user:user:...]             userで指定されたユーザにwrite(1)コマンドでマッチした文字列を送る。 throttle 時:分:秒,[use=message|regex]              指定された時間内で次のメッセージの出力を抑止する。DoS攻撃でメールが溢れたりするのを防止できる。指定時間内のメッセージは回数付きで指定時間後にまとめて出力される。 continue 通常、watchforでマッチした文字列は対応するアクションを実行するとそれ以上検索しないが、continueをつけると、さらに次のwatchforでの検索を続行するようになる  quit swatchを終了する
  150. &amp;lt;number&amp;gt; ここでは、実際に運用している環境で送られてきたメールをいくつか表示しています。 利用する上での注意点 前ページの設定はあくまでも一つ例にすぎません。実際のサーバでは、アクセスのパターンをログファイルと見合わせながら実際のサーバーにあった設定に変更して使うようにしてください。 また、紹介した例では使用していませんが、execアクションをもっと積極的に利用した設定も考えられます。たとえば/var/log/maillogで、以下のルールにマッチするのは、明らかに怪しいアクセスです。オープンリレーサーバーを探していると考えられます。  watchfor /ruleset=check_rcpt/    mail alert,subject=sendmail Relay rejected    exec /root/bin/reject.sh $9 このチェックにひっかかるログの例は次のようなものです。 May 3 02:10:07 server sendmail[28147]: CAA28147: ruleset=check_rcpt, arg1=&amp;lt;amaill@famm.ne.jp&amp;gt;, relay=[192.168.0.100], reject=553 &amp;lt;amaill@famm.ne.jp&amp;gt;... Relay operation rejected ここで、/root/bin/reject.shを次のように記述して、Linuxカーネル2.4以降のパケットフィルタ機能でアクセスを拒否するという積極的な防御も可能です。 #!/bin/sh TARGET_IP=`echo $1 | cut -d \[ -f 2 | cut -d \] -f 1` iptables -a INPUT -s ${TARGET_IP}/32 -j LOG iptables -a INPUT -s ${TARGET_IP}/32 -j DROP
  151. &amp;lt;number&amp;gt; ここはメモ欄です。
  152. &amp;lt;number&amp;gt; ここまで紹介してきたツールを活用すると、普段よく利用しているメールアドレスに警報メールが大量に到着するようになります。この情報(警報メール)をどうやって活用するかが運用管理の鍵になります。 しかし、通常の場合、このメールを見て、処理すること自体が苦痛になる場合も多いはずです。しかし、メールソフトの仕分けの機能を利用して、専用のフォルダに仕分けておくようにすると、時間が取れた時に見ることもできるし、定量的な判断も可能になります。 ここでいう定量的な判断とは、あまり褒められた方法ではありませんが、「未読の数」の推移でざっくりとサーバーの状況を想定してしまうのです。たとえば、通常の定常状態で、一日に200程度の未読メールの増加であるものが、ある日、突然に500を超えたとします。これは、サーバーに何か起きているという「警報」と言えるのではないでしょうか? また、swatchの設定が不足していたり必要な情報が不足している時にはやはりログファイルを実際に見に行くことになりますが、この場合も警報メールのパターンなどからIPアドレスやホスト名などを頼りに、findとgrepを使ってログを絞り込むことで大量のログから必要な部分だけを抽出するといった作業を行う必要があります。これは、何も難しいことをしているわけではなく「ダイエットの仕方の例」に示すようなワンラインスクリプト(grep -v [不必要なリスト]を必要なだけ追加して行きながらより精度の高い抽出をおこなっている)を実行しているだけです。これだけでも大量のログの海に溺れずに済みます。
  153. &amp;lt;number&amp;gt; カスタムシェルスクリプトによる簡易チェック サイトに複数のサーバーがある場合は相互に、知り合いの管理者がいるサイトと相互になどの形で、マシンのネットワークが上がっているのかをチェックするスクリプトを紹介します。 これらのスクリプトを利用することで、簡易的なサービスチェックを行うことができ、サーバを24時間監視しなくても、機械が自動監視し、落ちていたら携帯電話にメールが来るようにして実際に運用しています。 この他にもいくつか簡単にできるRAS向上を図っていて、それなりに成果が上がっているものをご紹介します。
  154. &amp;lt;number&amp;gt; 最初は、自サイトの内部のゾーンにpingを打ち、反応がない場合に指定されたアドレスに警報メールを出すスクリプトです。ALERTMAILには送信するメールアドレスを、BASEには監視する自サイトのゾーンのネットワーク部分を、HOSTには監視対象のコンピュータのIPアドレスを列挙します。 これを、crontab -e で、たとえば、 0-59/10 * * * * /root/bin/checkmachine などと登録することで、10分に1回サーバーが上がっているかどうかを確認できるようになります。 実際にはメールアドレスには、システム管理者他数名の携帯メールアドレスを登録しておき、対応できる担当者が相互に連絡をとりながら、サーバの再起動なりを試みる方式をとっています。 ただし、ICMPは到達を確認できないプロトコルですので、瞬間的にサーバやネットワークの処理が重くなってしまったときにエラーになることもあるので、実際には2回以上続けてエラー警告が上がってきたときに対応するようにしています。
  155. &amp;lt;number&amp;gt; このスクリプトは、checkmachineをベースに改造を施したものです。 複数のIPアドレスや、複数のドメインを管理している場合、どのIPアドレスとFQDNが対応するのかや、どのアドレスが使用中なのかを手軽にチェックしたくなるときがあります。 この目的で、このチェックを手軽に行うためにこのスクリプトを利用しています。
  156. &amp;lt;number&amp;gt; 次に紹介するのは、FQDN(www.jipdec.jpなど)でサーバーが上がっているかどうかを調べるように改造したものです。名前に特に意味はありません。 管理のお手伝いをしている遠隔地のサーバーを監視するために作成したものです。これも、checkmachineと同様にALERTMAIL、BASE、HOSTSなどを書き換えて使用します。こちらのバージョンでは、checkmachineと異なりDNSの名前解決ができない場合でもエラーになるので注意が必要です。また、遠隔地のサーバーに対してpingを打つ分、1回程度エラーが出ることがよくあります。複数回警報メールが出たときに初めて警報だと考えた方がよいようです。送信先のメールアドレスに携帯電話のメールアドレスを登録しておけば、お手軽な自動監視のできあがりということになります。 このスクリプトなどは、サーバ管理者同士が互いのサーバを相互に監視する等の方法で自サイトの上位回線の障害によって警告メールすら送れなくなってしまった場合に備えるのも手です。 このようにちょっとしたスクリプトでも、実際に役に立つ自動監視の機能を作り込めることが分かっていただけたでしょうか。
  157. &amp;lt;number&amp;gt; このシェルプログラムは、携帯から閲覧されるWebサイトを想定しています。 このプログラムでは、URLの部分を毎日ランダムな物に変更し、変更した結果を指定されたユーザのメールアドレスに送信します。 この結果、パスワードでアクセス制限をしなくても、ある程度実用的なセキュリティを確保できるようになるわけです。 注意点としては、Webサーバでディレクトリ一覧が見えるような設定にしてしまうと意味がない点が挙げられます。 特に最近の携帯電話では、入力のキャッシュがあるため、パスワードを入力させることは、利用者が不便というだけでなく危険ですらあります。このような時には、このようなシェルスクリプトを利用するとよいでしょう。
  158. &amp;lt;number&amp;gt; このスクリプトは、cronの@reboot指定(リブートした時に一致する)の機能との組み合わせ技です。 システムが何らかの不具合などによりリブートしてしまった場合、または、リブートした結果システムにリモートログインできなくなってしまったような場合に、  ・ブート時のログ  ・リブートから遡ること200行のsyslogデータ を指定したメールアドレス(上記の例では[email_address])に送信するものです。 これにより、リブート時の不具合の原因を突き止められる可能性が増えます。
  159. &amp;lt;number&amp;gt; この機能は、システムが固まるもののうち、明らかにカーネルがパニック処理を行った場合にのみ有効な機能です。 この指定を行うと、パニックを起こした原因を解決することなく、システムを再起動してしまいますので、運が悪ければシステムに壊滅的なダメージを与える場合もあり得ます。 しかし、そこまでシビアな運用管理を要求されない場合は、そのままリブートしてくれるので、無人運転(夜中や連休など)の際のサーバダウンなどに対処できる唯一の安価な対処方法でもあります。 (安価でない対処方法は、専用装置を使って電話回線経由でキーボードや、ディスプレイをリモート操作する方法です)
  160. &amp;lt;number&amp;gt; (このページは空白です)