oss os セキュリティ
Post on 18-Jan-2016
80 Views
Preview:
DESCRIPTION
TRANSCRIPT
OSS OS セキュリティOSS OS セキュリティ
株式会社リナックスアカデミー
http://www.linuxacademy.ne.jp
本講座の項目 サーバセキュリティ概論 ネットワークセキュリティ セキュアシェル セキュア OS 概論 SELinux の仕組みと機能 (1) SELinux の仕組みと機能 (2)
(1/2)
本講座の項目 SELinux 構築演習 Web 環境におけるセキュリティ Web 環境におけるセキュリティの実務 ログ管理システムの仕組み (1) ログ管理システムの仕組み (2) ログ管理システムの構築実務
(2/2)
1 章 サーバセキュリティ概論
サーバセキュリティ Linux におけるネットワーク chkconfig によるサービスの設定 Kudzu
脅威の種類
侵入による脅威‒ 情報漏洩‒ 改ざん‒ バックドア‒ 踏み台
サービス妨害– DoS
待ち伏せによる脅威– トロイの木馬型– 盗聴– ソーシャルエンジニアリング
実際に起きた事例 (1)
楽器販売サイトからの情報流出‒ 楽器をインターネット上で通信販売している会
社のサーバから、過去に利用した利用者の情報が流出
‒ 流出規模は数万件‒ SQL インジェクションといわれる、 DB の操作
を不正に行う処理‒ 販売サイトのシステムにミスが存在‒ 流出したデータにはクレジットカードの情報も
存在
実際に起きた事例 (2)
DoS
企業ネットワークを機能させなくする‒ ある企業のネットワーク部門に連絡、膨大な顧
問料を要求‒ 断ると、その企業のサーバに対して、多くのア
クセスが発生。企業のサービス・ネットワークがダウン
‒ 攻撃元は、顧問料を要求している人間
代表的な対策 (1)
トロイの木馬‒ アンチウイルスのソフトウエアによる駆除
ソーシャルエンジニアリング‒ ワンタイムパスワード‒ セキュリティに対する教育‒ ハードウエアトークン
代表的な対策 (2)
DoS‒ ネットワークの監視
Broute Force Attack‒ ネットワークの監視‒ IDS
TCP/IP とネットワーク
Linux では、 TCP/IP をベースとしたネットワークが動作
lo のループバックのインターフェース ethX の主に NIC が対象となるインターフェ
ース
IP ネットワーキング 実習 (1)
IP アドレスを確認
ifconfig -a でインターフェース一覧表示
ifconfig eth0 で、特定インターフェースの設定内容の表示
IP ネットワーキング 実習 (2)
netstat -r でルーティングテーブル表示 隣の生徒に IP アドレスを交換 教員が IP アドレスを板書 ルータの IP アドレスを板書1.localhost に ping を打つ2.隣に ping を打つ3.教員マシンに ping を打つ4.ルータに ping を打つ
ポートオープンとその確認 (1)
TCP/IP の動作原理は、サーバの対象となるサービスのポートに対して、クライアントがアクセス
例 : HTTP は TCP/80 なので、 Web サーバの TCP/80 番へのアクセス
サーバは、常に対象となるサービスのポートをオープン状態で待機
lsof 等のコマンドで、待機状態を確認
ポートオープンとその確認 実習
netstat –a netstat –r netstat –p lsof
これらを順に入力し動作確認
サーバプログラムとは
サーバ上で、常時稼動しているプログラム
クライアントからのリクエストに応じて、サーバプログラムが応答し、レスポンスが応答
主要なサービスは、 1-1023=Well known port でポートオープン
サービスの起動と終了
service コマンドを利用して、起動／終了
service XXXX start
service XXXX stop
で起動／終了が可能
ランレベル
Linux が動作するときの、動作モードのことが「ランレベル」
ランレベルごとに、違った動作環境を設定済 ランレベルごとに動作するサービスを変更 ランレベルは 0-6, S の 8 段階 telinit X でランレベルを変更
kudzu とは
システム起動時に実行されるハードウエア認識ツール
新しいデバイスが加わった、既存のデバイスが取り出された、等の管理
起動時に新しいデバイスがあった場合、追加するかしないか等の判定
kudzu の設定
kuzduの設定ファイル-
/etc/sysconfig/hwconf
- ハードウエアの情報が記述されている
起動時のkudzuのメッセージを確認-
dmesgコマンド
1 章のまとめ
ネットワークにおける脅威 Linux のネットワーク機能 Linux におけるサーバ動作の原理 サーバ機能の提供 ランレベルとサーバの動作 kudzu の説明の機能
2 章 ネットワークセキュリティ
iptables- iptales の仕組み- テーブルとチェイン- ターゲット- ルールの設定- 実習
上級の設定
iptables とは
パケットフィルタのツール カーネルレベルに実装されている netfilter netfilter に対して制御のルールを指定する
のが iptables( コマンド ) アクセス制限によるファイアウォール パケット転送による NAT ルータ等が実現 パケットは、「チェイン」というところを通
過
iptables の仕組み 1
カーネルのモジュールとコマンドから成立
カーネルが受け取ったパケットを、カーネル内部で処理コマンドは、そのルールを与えるためのコマンド
ハードウエア
カーネル
ユー
ザラ
ンド プ
ログ
ラム
プログ
ラム
プログ
ラム
iptables モジュール(netfilter)
iptables の仕組み 2
ルールはチェインに対して設定
例 : iptables -A INPUT -i eth0 –s 192.168.10.0/24
-p tcp --dport 80 -j DROP
インターフェース eth0 から入ってくる (=INPUT チェインを通過する ) 、発信元アドレスが 192.168.10.0/24 で宛先ポートが TCP/80 であるパケットをDROP せよ、というルール
iptables の仕組み 3
否定に関する
例 : iptables –A INPUT ! –s 192.168.20.0/24 –j DROP
! は否定（〜ではない）を意味する。 従来の書式では、
iptables –A INPUT –s ! 192.168.20.0/24 –j DROP
というように、 ! の位置が違っていた。 まだ出回っている iptables の説明は、こ
の古い形式で書かれている場合が多い。
テーブルとは？
4つのテーブル「 filter 」「 nat 」「 mangle 」「 raw 」
それぞれのテーブルに機能が存在 例 : mangle ・・・パケットの改変 filter ・・・パケットのフィルタリング
それぞれのテーブルの中で利用できるチェイン
チェインとは？
チェインは、ルールの集まりでできている 元々組み込まれているチェインがある チェインは独自に設定し、チェインに対して
チェインを加えることができる チェインの中に記述されたルールは、ファー
ストマッチであるため、優先度の高いルールはチェインの中で前の方に書いておく必要がある
ターゲット
チェインに設定されたルールで、対象のパケットをターゲットに送る仕組み
ターゲット自身に機能があり、パケットを送ることで処理を
全部で 20以上あるが、有名なターゲットとして、 ACCEPT, DROP, REJECT, MASQUERADE 等が存在
例 : iptables -A INPUT -i eth0 -s 192.168.10.0/24 -p tcp --dport 80 -j DROP
対象のパケットを DROP ターゲットに送る（= 落とす）。
ルールの設定
チェイン XXX に対してルールを設定する
iptables -A XXX ルールの追加
iptables -D XXX ルールの削除
iptables -i ethX ルールを ethX からパケットが入力されるときに適用
iptables -s X.X.X.X 発信元 IP アドレスがX.X.X.X であるパケットが対象。 CIDR形式でも指定可能。
iptables -d XXX 送信先 IP アドレスが X.X.X.Xであるパケットが対象。 CIDR形式でも指定可能
実習 1 方針
SSH のアクセス制限を行います。
2 人でペアになってください。
相手の IP アドレスを聞いてください。
自分の IP アドレスを相手に伝えてください。
実習 2-1 アクセス制限
ssh 相手の IP アドレス-
アクセスできます。
実習 2-2 アクセス制限 コマンド一覧
iptables –nvL
iptables -A INPUT -i eth0 -s 相手の IP アドレス -j DROP
iptables –nvL
相手の IP アドレスを発信元 IP とするパケットで、 eth0 からパケットがくるものを、すべて DROP する。という意味。
実習 3-1 アクセス制限後
もう一度実行してください。 ssh 相手の IP アドレス・・・接続できないはずです。
実習 3-2 アクセス制限後 コマンド一覧
iptables –nvL iptables –F iptables –nvL
すべてのアクセス制限を解除します。
実習 4 カウンター確認する
実験 2〜3を再度行います。iptables –nvL
を入力しますが、実験 2-2 の終わりの出力と、実験 3-2 の終わりの出力を比較してください。
設定した条件にマッチした回数と、適用したパケットのバイト数が変わるはずです。
上級の設定
サーバの構成
あるサーバを想定し、そのサーバのファイアウォールをiptablesで実現
対象とするサーバの構成:-
Webサーバ-
リモートからSSHアクセスによる操作が可能
- Apache-httpd, sshdが動作
- IPアドレスは192.168.10.100
サーバの特徴 1
設定上の理念は 2 つA 「対象ホストが、ネットワーク的にどういう動きをする
か完全把握する必要がある」B 「獅子身中の虫」
A 「対象ホストが、ネットワーク的にどういう動きをするか完全把握する必要がある」
Apache-httpd が動作している⇒ TCP/80 がポートオープンsshd が動作している⇒ TCP/22 がポートオープン
他にオープンしているようであれば、それは停止→ lsof 等を使って、動いているプロセスと、ポートオープンの状況を調査
サーバの特徴 2
B 「獅子身中の虫」
iptables で設定できるファイアウォール／アクセス制限多くの場合 :
「外部から自ホストへのアクセス制限をかける」
それ以外に :
「自ホストから外部へのアクセス制限もかける」
万が一乗っ取り等が発生した場合、他ホストへのアタックの防止
iptables の設定 1
どちらの方針がよいか ?
1. 「全パケット通過で、特定のパケットだけ制限する。」 2. 「全パケットを制限し、特定のパケットだけ通す」
1. vs 2. ・・・もちろん 2. そのための A 「対象ホストが、ネットワーク的に・・・完全把握する」
実際の設定方法まず全チェインに対するルール削除と、余分なチェインの削除INPUT, OUTPUT のチェインのポリシーは「すべて通過させない」ループバックは全部通す。
iptables の設定 2
自ホスト TCP/80 へのアクセスと、その応答の通信を許可。 (HTTP)
自ホスト TCP/22 へのアクセスと、その応答の通信を許可。 (SSH)
自ホストから UDP/53 TCP/53 へのアクセスと、その応答の通信を許可。 (DNS)
iptables スクリプト表示
参考文献「習うより慣れろ iptables テンプレート集
」@IT 連載記事http://www.atmarkit.co.jp/flinux/index/
indexfiles/iptablesindex.html
2 章のまとめ
iptables の動作原理の説明
iptables のアクセス制限の実証
iptables で Web サーバの設定
3章 セキュアシェル
telnet サーバの構築
OpenSSH
sshd_config の設定
ブルートフォースアタック
telnet とは
TCP 23 番ポートで通信相手先の telnet サーバと通信 UNIX でリモートのマシンにログイン暗号化は（標準では）行われない セキュリティ的に怖いので、最近は利用頻度
が低い
telnet サーバとは
telnet のクライアントに対して応答
telnet の通信は、ログインだけではない
ルータや様々な機器が telnet の接続に応答
telnet コマンドとは UNIX系 OS の場合標準で利用可能
リモートマシンにも接続
telnet ホスト名 ポート番号で、ホスト名に対してポート番号で接続
手動 HTTP 、手動 SMTP の実現
telnet サーバの設定 ( 実習 )
yum install telnet-server
/etc/xinetd.d/telnet の設定 disable=yes ⇒ no に変更
service xinetd restart
telnet-server は xinetd で管理
OpenSSH
SSH とは 1
Secure SHell のこと。従来、 Remote SHell(rsh) というのがあり、リモートマシンのシェルを利用することが可能通信内容はすべて平文
SSH は、リモートへの接続をすべて暗号化し、 RSH と同等のことが実現
UNIX系 OS を中心に、リモートマシンへのログインは、現在 SSH が一般的
SSH とは 2
同等なことは、前述 RSHや telnet でも実現
通信内容がすべて平文でありアカウント認証時も平文
⇒セキュリティ的に NG
SSH を使うようになった。
SSH とは 3
外部からのホストのアクセスを、すべてSSH に限定
SSH のサーバプログラム（ sshd）のセキュリティ情報をだけを注意し、他のサービスを利用しない
他のポートを閉じることも可能なので、セキュリティ的にも利点
SSH関連のコマンド 1
sftp‒ 通常の FTP サービスは、最近利用頻度が低下‒ プロトコルの仕様と、サーバのセキュリティ等
の理由‒ ファイルの転送は重要‒ 通信経路はできれば暗号化されていることが期
待
⇒sftp の利用
SSH関連のコマンド 2
sftp（続き）‒ FTP の通信中に暗号化を行う SFTP(≠FTP over
SSL)
‒ SSH をインストールすると、クライアントコマンド sftp
サーバプログラム sftp-server
がインストール‒ ポートも SSH と同じ TCP/22 番を利用するので
、ファイアウォールの設定も簡単‒ 「 SFTP は SSH のサブセットである」
SSH関連のコマンド 3
scp‒ リモートホスト間で、ファイルのコピーを行う
rcp というコマンドが過去に存在‒ rsh同様、セキュリティの面で難があったので
、利用頻度が減少‒ 通信内容が暗号化され、ファイルコピーの実行
コマンド例 : scp file-a host1:/tmp
file-a を host1 というホストの /tmp ディレクトリにコピー
SSH関連のコマンド 4
ssh の -L オプション（ SSH トンネリング）‒ あるマシンに ssh をトンネリングモードで待機
。この ssh は 2 つのポートをオープン。
‒ 1 つは待機用（ host1 の port1）。もう 1 つは別マシン（ host2）のポート（ port2）に接続。
‒ すると、 host1 の port1 に接続すると、それがそのまま host2 の port2 に接続。
SSH関連のコマンド 5
ssh の -L オプション（ SSH トンネリング） 2（続き）
‒ 環境により直接 host2 の port2 に接続できないとき、 host1 を経由させることによって接続が可能
‒ これが SSH のトンネリングモード
host1 host2
port1 port2ssh –L によるトンネリング
sshd_config の設定
様々なパラメータの紹介 1
Port
- ポート番号を設定する。 Protocol
- 利用するプロトコル。 2,1 と記述することで、 SSH2 を優先し、次に SSH1
PermitRootLogin
- SSH での接続の際に root でログインすることを許可
様々なパラメータの紹介 2
MaxAuthTries
- ログイン名とパスワードが一致しなかったときに、何回までリトライを許すか？という設定。あ多いと、ブルートフォースアタックに対してぜい弱
PubkeyAuthentication
- 事前に公開鍵を渡しておき、それを利用して認証する＝パスワードを聞かれることが無くなる
RhostsRSAAuthentication
- rhosts を認証のときに利用するかしないか、の設定
様々なパラメータの紹介 3
HostbasedAuthentication
- /etc/ssh/ssh_known_hosts に公開鍵を設定。登録されたホストからのログインを許可- ホストが認証の対象
PasswordAuthentication
- SSH の接続の際に、ログイン名・パスワードでのログインを許可- 交換したキーの情報に依存せず
ChallengeResponseAuthentication
- チャレンジレスポンスの認証方式を許可するかの設定
公開鍵暗号方式
鍵 A, B のルール
- 「 A で閉めた（＝暗号化した）データは、 Bでしかあけられ（復号化でき）ない。」
- 「 Bで閉めた（＝暗号化した）データは、 Aでしかあけられ（復号化でき）ない。」
A,B のどちらかを公開鍵といい、残りを秘密鍵公開鍵は一般に公開、秘密鍵は外部に非公開
SSH の公開鍵と秘密鍵
authorized_key に公開鍵保存する- 2名一組で、お互いの IP アドレスを交換- root でログインにチャレンジ- 公開鍵／秘密鍵のペアを作成- 相手に公開鍵を渡す- ログイン名・パスワードの入力無しでログイ
ンができる事を確認
ブルートフォースアタック
ブルートフォースアタック 1
ログイン名とパスワードの組み合わせを、たて続けに送信
アカウント奪取を“力技”で実行
どのサーバ・サービスでも対象例：Web のサービスにおける、アカウントの
ログインとパスワード
ブルートフォースアタック 2
パスワードの生成方法よくある「パスワードの決め方」ルール‒ 辞書に載っている単語は利用しない‒ 簡単な文字列の羅列（ abcdef）は利用しない‒ アルファベット（大文字小文字）・記号・数値
等を混ぜて作成‒ ログイン名／パスワードを同じにするのは利用
しない
⇒ブルートフォースアタックの時に、耐久性を上げる為の忠告
パスワードの設定方法（続き）- root のように、アカウントが存在しているこ
とがわかっていると、パスワードを順に変えてアタック
- アカウントを総当りにするより、対象になるデータ件数は減るため、見つかるまでの“のべ時間”が減り、危険
ブルートフォースアタック 3
ログ（抜粋）logname= uid=0 euid=0 tty=ssh ruser= rhost=YYYY user=root
Oct 22 23:02:17 XXXXXX sshd[6078]: Failed password for root from YYYY port 36657 ssh2
logname= uid=0 euid=0 tty=ssh ruser= rhost=YYYY user=root
Oct 22 23:02:20 XXXXXX sshd[6082]: Failed password for root from YYYY port 37060 ssh2
logname= uid=0 euid=0 tty=ssh ruser= rhost=YYYY user=root
Oct 22 23:02:27 XXXXXX sshd[6090]: Failed password for root from YYYY port 37791 ssh2
- root というユーザに対して、同じ IP から連続にしてログインしようとしていて、失敗
- 様々なパスワードを送信されている事が確認
ブルートフォースアタック 4
ログはこのようになります（抜粋）logname= uid=0 euid=0 tty=ssh ruser= rhost=YYYY
Oct 20 22:09:49 XXXXXX sshd[5314]: Failed password for invalid user abe from ZZZZ port 57556 ssh2
logname= uid=0 euid=0 tty=ssh ruser= rhost=YYYY
Oct 20 22:09:50 XXXXXX sshd[5318]: Failed password for invalid user adabas from ZZZZ port 57779 ssh2
logname= uid=0 euid=0 tty=ssh ruser= rhost=YYYY
Oct 20 22:10:00 XXXXXX sshd[5322]: Failed password for invalid user adam from ZZZZ port 57962 ssh2
同じホストから、 a で始まるアカウント(abe, adabas, adam…) でログインを試行
SSH に対するブルートフォースアタックの対策 1
SSH のサーバにブルートフォースアタックを検出する方法は無い
一般的には、 2 通り‒ Linux のファイアウォールを設定す
る、 iptables を利用するタイプ‒ SSH に対するアクセスログをスキャンし、同一ホストからの大量のログインミスを発見、そのホストからのアクセスを禁止。ログを解析するタイプ。
SSH に対するブルートフォースアタックの対策 2
iptables を利用するタイプ 2（続き）
- iptables には、 recent というモジュールがある。
「最近＊＊秒以内に～の条件が＊＊回発生した」⇒単位時間あたりの条件適用回数をカウントできるモジュール
SSH に対するブルートフォースアタックの対策 3
iptables を利用するタイプ 3 （続き）
recent モジュールを用いて
「最近＊＊分以内に、 ssh宛てのパケットでNEW フラグがたったパケットを＊＊回以上確認した場合、発信元の IP からのパケットを＊＊秒遮断する」
という設定をする。
SSH に対するブルートフォースアタックの対策 4
iptables を利用するタイプ 4 （続き）
利点：指定回数以上を間違えた場合、即その段階で遮
断することができる。
難点：正式なユーザでも、「たまたま」指定回数以上
を間違えると、アクセスが禁止される。
SSH に対するブルートフォースアタックの対策 5
ログを利用するタイプ 1
- 定期的にログ解析ツールを動かす。- 対象のログは、認証結果を出力するログ。- 「何時何分にアカウント＊＊がログインをし
た」- 「何時何分にアカウント＊＊のアクセスがあ
ったが認証に失敗した」
SSH に対するブルートフォースアタックの対策 6
ログを利用するタイプ 2（続き）
- ブルートフォースアタックは、大量のログイン失敗の情報が発生
⇒ログの内容から、ブルートフォースアタックの検出
SSH に対するブルートフォースアタックの対策 7
ログを利用するタイプ 3 （続き）
利点 :
ログの解析なので、 iptables の複雑な方法の理解が不要
難点 :
ログのフォーマットにより、検出できる場合とできない場合が存在。利用するプログラムにもよる。
3章のまとめ
telnet の動作原理
ssh の動作原理
ssh で公開鍵／秘密鍵を交換したログイン
ssh でのブルートフォースアタックと、その防ぎ方
4章 セキュア OS 概論
セキュア OS の種類 セキュリティアップデート パッケージの管理と利点 chroot/jail 環境
セキュア OS
セキュリティを強化した OS明確な定義は無い
‒ MAC(Mandatory Access Control, 強制アクセス制御 ) を兼ね備えている
‒ root ではなく、最小特権をもつ複数ユーザによる管理
root は危険‒ すべての権限が root で操作可能‒ root が乗っ取られるとアウト
セキュリティホール情報の集め方
IPA 情報セキュリティ情報http://www.ipa.go.jp/security/
JP/CERT 注意喚起http://www.jpcert.or.jp/
のようなところから情報を収集
パッケージの管理と利点 1
パッケージとは？ アプリケーションを実行するの必要なファイ
ルを提供 一括インストールできる機構 パッケージ管理機構により、依存性を解決配布元が動作保証（することがある）
パッケージの管理と利点 2
ディストリビューション大きく分けて、 2系統に分かれる- RedHat系列・・・ RedHat Enterprise Linux,
Fedora, CentOS
- Debian系列・・・ Debian, Ubuntu, KNOPPIX
ディストリビューションとパッケージ- RedHat系列・・・ .rpm形式のパッケージ- Debian系列・・・ .deb形式のパッケージ
パッケージの管理と利点 3
パッケージとパッケージツリーの管理 パッケージツリーとは、パッケージの依存関係の情報
パッケージのインストールは、 CD/DVD からの他にネットワークからファイルを取り寄せインストール
ツリー管理コマンドと、インストールするコマンドは異なる
rpm/yum ・・・ RedHat系 dpkg/apt-get・・・ Debian系
実習 : パッケージ管理
CD/DVD を利用するときは、メディアをマウント ネットワークを利用するときは、導通確認 プロキシが必要であるときは、以下の設定
export http_proxy=http:// プロキシ情報
CentOS では、 yum を利用しパッケージファイルの取り寄せyum install パッケージ名yum remove パッケージ名yum check-update ・・・パッケージツリー情報更新
chroot/jail 環境とは 1
プログラムのアクセスを、特定ディレクトリ以下に抑える技術
/usr/var/tmp/home
/chroot /dir-a
Jail 環境とは 2
原理は、 UNIX のプロセスの機能 プロセスが到達できる、最上位のディレクト
リを指定 通常は /（ルート）だが、任意のディレクト
リにする事が可能 動作範囲が抑えられた状態が、いかにも牢獄
のよう・・・ Jail（牢獄）環境と呼ぶ
Jail 環境の利点 1
シェルの実習環境 不特定多数の一般ユーザに、ログイン環境を提供
通常だと /etc 等、その OS 上の設定までみられる可能性
/var, /home 等に動作環境を作成 Jail 環境には、 OS の設定等を見せないよう
に構築
Jail 環境の利点 2
サーバ運用環境 サーバの動作環境を Jail 環境で構築 1 つの Jail 環境が攻撃されても、他の Jail 環
境には影響が無いメモリ・ CPU ・ HDD は共有可能 一番簡単な「仮想化」
実習 : Jail 環境の構築
/tmp/jailed に Jail 環境を構築する /tmp/jailed に必要なファイルをコピー chroot コマンドでルートディレクトリを指
定 対象のディレクトリ以上より上にアクセスで
きない事を確認
4章のまとめ
セキュア OS セキュリティホール情報の集め方 パッケージの利用と利点 chroot/jail 環境について chroot/jail 環境の構築
5章 SELinux の仕組みと機能 (1)
root の危険性 SELinux とは SELinux の機能の構成強制アクセス制御 TE ドメイン RBAC セキュリティコンテキスト
SELinux とは
SELinux は、カーネルに独自拡張を加えたOS
セキュア OS に分類 アメリカの国家安全保障局 (NSA) が中心に開発
GPL で配布 カーネル 2.6.0 にマージ
root権限の存在
root ・・・ UNIX系 OS での UID 0 番の特殊なユーザ
すべてのアクセス権において、無視・・・「なんでもあり」
セキュアな OS において、 root の存在が好ましくない
理由は「 root権限が奪取されたら、すべてのことができてしまう」ことによる
任意アクセス制御（ DAC）
アクセス権は、ファイル・ディレクトリに存在 それらのアクセス権を設定するのは、“ユーザ” - 「各ユーザが“（各自が）任意に”アクセス権
を設定・管理できる」 この仕組みを DAC(Discretionalry Access
Control) という・・・セキュリティ管理者がアクセス権
を設定したい・・・しかし「 root の存在」が問題
SELinux の動作
SELinux の働き
カーネル カーネル
ファイル等のリソース ファイル等のリソース
プロセス
アクセス権の確認
アクセス権の確認
Linux Security Module
プロセス
従来のアクセス SELinux 環境でのアクセス
機能構成図
最小特権 RBAC
TE
ドメイン遷移
強制アクセス制御 (MAC)
監査ログ (AVC)
セキュア OS の必要項目
強制アクセス制御
「セキュリティ ポリシ ファイル」に、アクセスについての記述
設定は、ユーザや ファイル・ディレクトリのオーナではなく、 Role単位
ポリシファイルを管理するのが、セキュリティ管理者
セキュリティ管理者の考えの元に、運用
TE(Type Enforcement)1
様々なプロセスとリソースに対して、ラベルを割り当て
プロセスの事を“サブジェクト” リソースの事を“オブジェクト” プロセスに割り当てたラベルは“ドメイン” リソースに割り当てたラベルを“タイプ” 「様々なリソース」には次のもの
‒ ファイルやディレクトリ‒ 通信ポート等のデバイス
TE(Type Enforcement)2
オブジェクトには、その種類ごとにオブジェクトクラスが存在
オブジェクトクラスには、アクセス権限が存在
・・・アクセスベクタ TE ・・・ドメイン（プロセス）がオブジェ
クトに対して、どんな権限があるかの定義
ドメイン遷移
プロセスに対してラベルを付けたものが“ドメイン”
アクセス対象のファイル・ディレクトリにつけたラベルが“タイプ” （前述）
プロセスが別プロセスを起動したとき、原則は同じドメインを割り当て
必要に応じて、別プロセスに別ドメインを割り当てる必要あり・・・ドメイン遷移
RBAC
すべてのユーザに対して、“役割”を割り当て
役割は Role（ロール）
ロールに対して、アクセス制限
これが RBAC(Role Based Access Control)
セキュリティコンテキスト
プロセスやオブジェクトが属している、セキュリティの属性
ユーザ・ロール・タイプが定義 プロセスの場合、ユーザ・ロール・ドメイン
が属性として存在 リソース（オブジェクト）の場合、ユーザ・
ロール・タイプが属性として存在
5章のまとめ
SELinux の機能について説明
SELinux は Linux Security Module というroot でも機能するアクセス制限機能の元で動作
SELinux を理解する上で必要な用語である、 TE, RBAC, セキュリティコンテキスト等を説明
6章 SELinux の仕組みと機能 (2)
SELinux の動作モードの説明
SELinux で守れない種類の脅威
TOMOYO Linux の紹介
SELinux の動作モード
enforcing, permissive, disabled の 3つのモードが存在
RedHat/CentOS Linux では、インストール時に設定が可能
標準でインストールを行う場合、 enforcingの状態に設定
SELinux の動作モードの設定
SELinux の動作モードの設定箇所は以下の 2点
インストール時に設定 インストール後コマンドにて設定する
‒ setenforce [ Enforcing | Permissive | 1 | 0 ]
1, 0 はそれぞれ Enforcing, Permissive
動作モードの確認と変更
確認を行う方法‒ getenforce コマンドで応答を確認‒ cat /etc/selinux/config で config ファイルの中を
確認
動作モードの変更‒ setenforce [ Enforcing | Permissive | 1 | 0 ] で変更
‒ ただし、 Enforcing と Permissive の間でのみ切り替え
‒ /etc/selinux/config ファイルを書き換え、直接指定し
‒ 再起動
SELinux の弱点 1
root アカウント root のアカウントが奪取される可能性 root が実行するプロセスの動きは制限する
ことが可能 root が属するドメインの権限の範囲内で、
設定を変更することが可能 定期的に root のパスワードを入れ替えたり
、ネットワークからのアクセス制限を実行
SELinux の弱点 2
ネットワークでの攻撃外部ネットワークからの不正攻撃（それで乗っ取られたプロセスの挙動を制限する
ことはできるが、乗っ取り自体を防ぐことはできない）
SPAM の受信 CSRF, XSS 等 Web アプリケーション上での
セキュリティホール
TOMOYO Linux とは
NTT データが開発し、 GPL で配布しているセキュア OS
標準でインストールされていないので、カーネルの追加モジュールとして実装
「使いこなせるセキュア OS 」という発想‒ 従来のセキュア OS は、設定が困難
http://tomoyo.sourceforge.jp
TOMOYO Linux の特徴
「学習」を行う・・・最大のポイント
セキュア OS で一番難しい設定が、ポリシーの設定
収集したアクセス履歴の中から、必要なポリシーを自動的に生成
動作モード (SELinux の Enforcing, Permissive 等 ) に、学習を行うモードが存在
6章のまとめ
SELinux の動作モードの説明Enforcing, Permissive
SELinux で守れない種類の脅威
TOMOYO Linux の紹介 「学習を行う」事が最大の特徴
7章 SELinux 構築演習
SELinux のインストール– インストール– SELinux の状態の確認– SELinux の有効化／無効化
SELinux関連のコマンド‑ セキュリティコンテキスト関連のコマンド‑ アクセス制御関連のコマンド‑ ロール関連のコマンド
avc ログ
SELinux のインストール
標準ではインストール済みなので、操作は必要無い
SELinux の状態の確認
sestatus ・・・動作状態とポリシー情報を表示
seinfo ・・・現在のポリシーの詳細な情報
SELinux の有効化／無効化
getenforce で動作確認‒ disableだった場合は、 /etc/selinux/config で
SELINUX=permissive にして再起動‒ 再度 getenforce で状態を確認
setenforce 1 で SELinux を有効化
SELinux関連のコマンド
セキュリティコンテキスト関連のコマンドps --context ・・・プロセスのコンテキスト
を表示id –context ・・・ログインシェルの動作ドメ
インを表示ls --context ・・・ファイルのコンテキストを
表示
アクセス制御関連のコマンド
sesearch
- ポリシーに定義されている内容を調査
chcon
- ファイルコンテキストを変更
fixfiles
- ファイルコンテキストを再設定
ロール関連のコマンド
newrole
- ロールの変更 - パッケージ policycoreutils-newrole が必
要
avc ログとは
ポリシールールに関する違反が発生すると、 avc ログに出力
SELinux のモードは、 enforcing, permissive のときに出力
ポリシールール違反が発生した理由、またはポリシールールの動作確認等で利用
CentOS では /var/log/audit/audit.log
avc ログのフォーマット
ログには次の内容が含まれるs
context=アクセスしたプロセスのドメインコンテキスト
tcontext=アクセス対象のセキュリティコンテキスト
tclass=アクセス対象のオブジェクトクラス
その他、プロセスidや、実行したプロセスを記録
avc ログの解析
avc ログを元に、ポリシーを作成
audit2allow というコマンド - audit.log を元にポリシーを作成
7章のまとめ
SELinux の設定で利用するコマンドの利用
セキュリティコンテキスト等の表示
avc ログの解析
avc ログからのポリシーの作成
8章 Web 環境におけるセキュリティ
Apache-HTTPD のセキュリティ– Apache-HTTPD のインストール– Apache-HTTPD の実行権限– httpd.conf の設定– ネットワークのアクセス権限
CGI のプログラムと出力 フォームデータの取り扱い 入力値評価
Apache-HTTPD のセキュリティ
Apache-HTTPD のインストール
パッケージによるインストール‒ 非常に有名・多く利用されているので、各ディ
ストリビューションはパッケージで用意
ソースコードからビルド‒ 機能追加のモジュール形式として static と DSO形式が存在
‒ ディストリビューションによる配布では、 DSO形式が多数
Apache-HTTPD の実行権限
親プロセスと子プロセスで動作親プロセスは、リクエストを子プロセスに振り分け、子プロセスが応答
親プロセスは root 、子プロセスが一般ユーザで動作
子プロセスは、必ず一般ユーザ権限で実行 コンテンツは、 apacheやwww-dataユーザ権限では保存“しない”
‒ 通常は /var/www/httpdや /var/www に保存
httpd.conf の設定
ServerRoot‒ /etc/httpd が標準‒ httpd の設定ファイルツリーのトップを示す
User, Group‒ apache, apache が標準‒ httpd の子プロセスが動作するユーザ権限
DocumentRoot‒ /var/www/httpd が標準‒ コンテンツをおくトップディレクトリを指定
ネットワークのアクセス権限
アクセス制御<Directory /var/www/http/xxx>
order deny, allow
denyfrom all
allow from .example.com
</Directory>
deny, allow の順でパターンマッチ.example.com からのアクセス以外、すべて
応答拒否
CGI のプログラムと出力
静的コンテンツ＝常に同じ内容を応答 動的コンテンツ＝入力に応じて応答が変化 CGI ・・・外部プログラムを起動し、動的コ
ンテンツを作成
クライアント /ブラウザ
Web サーバ /Apache
外部プログラム
この部分が CGI
フォームデータの取り扱い 1
フォームにより値を入力 インタラクティブなページを作成 フォームによるデータ入力を扱える HTTP のメソッドは 2 つ (GET/POST)
パラメータの渡しかたが、 GET/POST で異なる‒ GET ・・・ URL の終わりに値の羅列‒ POST ・・・ HTTP の通信上に値を羅列
フォームデータの取り扱い 2
GET の動作を見てみよう‒ Google で何か検索‒ 検索結果を URL で表示‒ 検索結果も HP である、という考え
POST の動作を見てみよう‒ POST のサイトに Wireshark でパケットキャプ
チャ
入力値評価 1
入力する値が、想定したものかどうか検証する。
例：生“年”月日を西暦 4桁ではなく、昭和・平成＊＊年で入力
- 住所の欄に名前を入力
入力値が、こちらの想定したものかどうかを検証
例 : 郵便番号 3桁 -4桁の数値
- 携帯電話番号 : 080 or 090 で始まる、 3桁 -4桁 -4桁の番号
入力値評価 2
RADIOボタンのとき、値は複数の中から 1つ選択
入力値評価は「必要である」前述 GET/POST 、どちらでも値を偽装する
ことは可能 もし、「複数の中から 1 つ」を前提にシステ
ムを設計すると、トラブル発生文字列パターンのマッチングには、正規表現
を使うといい
8章のまとめ
Apache-httpd のセキュリティについて Apache-httpd の動作環境について Apache-httpd の設定 フォームデータの取り扱い フォームデータの入力値検証の重要性
9章 Web 環境におけるセキュリティの実務
Web アプリケーション周りで発生するセキュリティホール‒ SQL インジェクション‒ XSS
‒ CSRF
前述セキュリティホールの発生原因と、その対策（方法）
セキュリティ対策
SQL インジェクション
SQL インジェクションは、「期待した入力値ではなく、 SQL の制御コードを入力され、期待していない SQL が動作」
Web アプリケーション等で、受け付けた値に SQL の制御コードが存在
既存の SQL コードと連携し、期待していない動作の SQL文が実現・実行
SQL とフォームの値
Web アプリケーションにおける、フォームのパラメータの処理
フォームによりパラメータが入力 書式が無いデータは、自由に入力 書式があるデータも、パラメータ操作により
入力が自由（ Radioボタンの GET）
SQL インジェクションの発生メカニズム
t_person に name列という文字列が含まれる列があったとする。
okada という文字を含む行を検索する SQL
select * from t_person where name like 'okada';
$input_data という文字列変数があり、それに含まれた文字列を含む行を検索するときは？
"select * from t_person where name like '" . $input_data . "';"
SQL インジェクションの防止方法
入力値評価を厳密化‒ 書式のあるデータは、その書式に従ったフォー
マットかを繰り返し検証‒ 入力値の中に制御コード（今回の場合‘）が入っ
ていないか検証‒ ’ がある場合は、’ -> \’という「’は文字である
」というエスケープ処理
DB 操作フレームワークを利用する。‒ Java-JDBC(PreparedStatement)
‒ PHP-PDO(bindParam)
‒ Perl-DBI(bind_param)
XSS とは
ブラウザ上で動作するスクリプト言語（主にJavaScript）を利用
JavaScript ・・・ブラウザに効果を与えることができるスクリプト言語
HP 表示を行う際に、利用者に気づかせずスクリプトを動作
動作内容により、 Web サイトにアタックをかけたり、 Cookie 情報を盗用
これを XSS(Cross Site Scripting)
XSS の発生メカニズム
JavaScript の文法・・・ <script type="text/javascript">……</script>
スクリプトがブラウザに読み込み
気づかないうちに、スクリプトが動作
JavaScript の内容によっては、危険な攻撃が可能
XSS の発生メカニズム ( 例 )
他のサイトに攻撃を仕掛けるスクリプトだったと仮定
1.悪意のあるユーザ
一般の
閲覧者
2.
3.
4. 攻撃対象のサイト
XSS の防止方法
<script> というタグが認識されてしまうことが、すべての原因
入力データに <script> 等、タグ情報を入力させない
出力時に、タグの情報をすべて実体参照文字に変更‒ < ・・・ < 、 > ・・・ > 等の変換
効果を含んだ文字入力（<b> 等）をしても、出力時にエスケープされてしまい、機能を限定
CSRF とは
リンクの先に特別なアクションを設定 そのリンクをクリックした瞬間、そのアクシ
ョンが動作気づかないうちに、そのアクションが実行
‒ ヤフオクの評価を下げる（未遂）‒ 「ぼくはまちちゃん」事件
ブラウザに含まれる、環境 (Cookie ・ログイン済みの状態）を利用しながら攻撃が可能
CSRF の発生メカニズム
攻撃対象のアクションが GETメソッドのときは、 URL自体がアクション
攻撃対象のアクションが POSTメソッドのときは、 POSTメソッドが動作するJavaScript が含まれた HP を作成し、そこにアクセス
認証を必要とするサイトで、ログインしたままのときは、 Cookie が備わっているので、認証がそのまま通過
CSRF の発生メカニズム ( 例 )1
通常はウイザード画面のように処理が進む(A. B. C.)⇒ ⇒
A B C
CSRF の発生メカニズム ( 例 )2
通常はウイザード画面のように処理が進む
A B
D
C
CSRF の発生メカニズム ( 例 )3
通常はウイザード画面のように処理が進む
A B
D
C
E
CSRF の防止方法
過去にログインした Cookie が利用できる・・・ログイン状態でできる“重要な”アクションの前、再度認証を要求
リンクによるアタックではないことを保証＝前のページからの遷移である事を保証‒ hidden タグを使って、前ページからの遷移であ
る確認を行う‒ リファラーを確認し、前のページの URL を確認‒ CAPTCHA（後述）を利用し、ユーザが目で見
ていることを確認
クロールツールについて
プログラムで自動的に巡回する（クロールツール） データを POST することでフォームの利用も可能自動巡回による攻撃
‒ Blog に対してメッセージを自動で書き込むことも可能（ブログスパム）
‒ 認証機構にブルートフォースアタック
対策‒ 遷移に JavaScript が用いられていると、遷移を行えな
い場合が多い‒ 遷移に JavaScript を利用
クロールツールの対策
CAPTCHA クライアントが画面を見ているという保証
＝クロールツールのブロック画像自動認識をさせないように、曲がった文字列を表示
なぞなぞ・クイズを解かせる CAPTCHA も存在
視覚に障害を持つ人のケア‒ 色覚障害で、画像の文字がよく見えない、等
実習
XSS を発生させるホームページ 「名前を表示する」という簡単なプログラムを
作成
名前を入力し、通常の動作がする事を確認
JavaScript を含んだ文字列を入力し動作確認
もし、これが攻撃用の JavaScript であったら？
9章のまとめ
Web のセキュリティ対策について学習 SQL インジェクション、 XSS 、 CSRF につ
いて学習 それぞれの発生原因と対策方法に着いて解説 実際に XSS を発生
10章 ログ管理システムの仕組み (1)
第 10章 ～第 12 章でログについて説明第 12 章が実習です。 10,11 章は説明のみログの管理機構についての説明 syslog syslog-ng swatch
等の動作原理の解説
syslog とは 1
ログ-
システムの動作の記録（ログ＝航海日誌）
- システムの挙動をログから判断／解析する
例: メールのログには、メールを送受信したことが記録される
ロギングシステム-
ログをとり、それらを管理するシステム
syslogはロギングシステムである
syslog とは 2
syslog はクライアントサーバ形式のロギングシステム
クライアントサーバ形式なので、「ログサーバ (syslog サーバ ) 」の構築が可能
一般に 日時 ホスト名 (IP アドレス ) 情報 の順で出力ホスト名を記述するのは、ログサーバを作成
した場合、ログを送ったホストを判定するために必要
syslog の動作原理
セレクタとアクション- セレクタには「ファシリティ」と「プライオリティ」が存在
ファシリティ・・・ログの分類 プライオリティ・・・ログの優先度
アクション・・・保存するログの位置、も他のホストに送る場合の設定、パイプで区切ったファイルへ渡す、などの指示
syslog の設定
/etc/syslog.conf で設定 ログサーバへ送る場合は、前述 action で説明した方法を利用
例：cron.* /var/log/cron
cron ファシリティは /var/log/cron ファイルにログを出力
cron.* @server-b
cron ファシリティは server-b にログを送付
syslog-ng
syslog-NewGeneration が名前の由来 syslog に機能追加
‒ フィルタリング‒ 柔軟性の高い設定‒ 信頼性の高い処理‒ データベースへの出力‒ ログサーバへの通信を暗号化
swatch とは
syslog 等のログの内容を監視することが可能
常に複数の OS で出力されている複数のログを監視することは困難
swatch ・・・ログの監視ツール ログに吐き出されたメッセージを解析条件にマッチしたものがあれば、イベントを
フック
swatch の動作原理
対象ログファイルの監視 設定ファイルは ~/.swatchrc
Perl で書かれているため、いくつかモジュールが必要
Date::Calc, Date::Parse, File::Tail, Time:HiRes
swatch の設定 1
パターンの記述.swatchrc に watchfor / パターン /
アクション :
watchfor / パターン /,/ パターン /
アクション :
の繰り返しを記述
swatch の設定 2
アクションの例 - mail=... ...（メールアドレス）に送信 - bell ベルを鳴らす - continue 処理を継続 - echo ターミナルに文字列出力 - pipe コマンド 出力をパイプ経由でコマ
ンドを実行
10章のまとめ
syslog の動作原理 syslog の設定ファイルの記述方法 syslog-ng の動作原理 swatch の動作原理 swatch の設定ファイルの記述方法
11 章 ログ管理システムの仕組み (2)
ログの管理機構についての説明 logrotate logwatch
の動作原理の解説
logrotate とは
logが増えてくると管理が困難1
回／1日、1回／1週、1回／1月等の単位でログを循環
xxx.log ⇒ xxx.log.1
---次の循環------------------------
xxx.log.1 ⇒ xxx.log.2
xxx.log ⇒ xxx.log.1
この循環作業を行うのが logrotate
logrotate の動作原理
logrotate の設定ファイル /etc/logrotate.conf
/etc/logrotate.d
logrotate.d は設定ファイルを置くディレクトリ
パッケージの追加／削除が行いやすいように、独立したファイルが設定ファイルとして存在
プログラムが設定ファイルを読み込むときに、ディレクトリ内のすべてのファイルを参照
logrotate の設定
設定できる項目-
対象ログファイル
- 更新タイミング(daily, weekly, monthly)
- ファイルのサイズ(minsize)
- ファイルの所有権(create)
- 保存する過去の世代(rotate)
その他-
更新時に実行するスクリプト(postrotate)
logwatch とは
ログは、様々な種類で様々なファイルへ出力
ログ全部の監視は困難
logwatch は、それらのログを「まとめる」
まとめたログは、ファイルに出力したりメールで送ったりすることが可能
logwatch の動作原理
/etc/logwatch/conf/logwatch.conf が設定ファイル
オリジナルは /usr/share/logwatch/default.conf/logwatch.conf
/etc/logwatch/conf/* のファイルを、オリジナルの設定に重ねて設定
ログファイルを直接管理する機能ではないので、 cron 等で指定、定時実行を指示
logwatch の設定
LogDir = /var/log ログの保存ディレクトリ
MailTo = usera 結果をメールするユーザ Detail = Low 報告の精度 Archive = Yes Range = yesterday 昨日のログファイル
をチェック
等の設定が可能
11 章のまとめ
logrotate の原理を学習 logwatch の原理を学習
12 章 ログ管理システムの構築実務
syslog の動作確認 syslog サーバの構築 syslog-ng の動作確認 swatch の動作確認 logwatch の動作確認 logrotate の動作確認
実習
本章では実習がメイン OS の設定は、ノートの通り
ログの動作
Apache-httpdサーバの動作確認-
service httpd start （サーバの動作開始）
- tail –f /var/log/httpd/access_log（ログの更新確認）
- ブラウザを起動し、http://localhostにアクセス
アクセスがあり、ログが更新されていることを確認
syslog の学習
この節の流れ Apache-httpd のログの出力を、 syslog に変更- Apache-httpd のログを syslog に向ける
- syslog で Apache-httpd を受信するに設定
ローカルホストでの syslog を、リモート環境で動作- 2 人 1 組で作業をするので、相手となる人のマシ
ンの IP アドレスを聞いておいてください
syslog の設定 1
Apache-httpd の設定‒ エラーのログは syslog に流すことができる。‒ アクセスログは、 syslog に流す為には細工が必
要
（ logger コマンド）
syslog の設定‒ syslog.conf で設定‒ ファシリティは local5（ access_log) と
local6(error_log) を利用
syslog の設定 1
Apache-httpd の設定‒ エラーのログは syslog に流すことができる。‒ アクセスログは、 syslog に流す為には細工が必
要
（ logger コマンド）
syslog の設定‒ syslog.conf で設定‒ ファシリティは local5（ access_log) と
local6(error_log) を利用
syslog の設定 2
2名 1 組になり、 syslog サーバを構築 マスターのマシンとサーバのマシンに役割分担
マスターのマシン側は、 Apache-httpd のログを syslog経由でサーバのマシンへ送信
サーバのマシン側は、ネットワーク経由でログ情報を受けとり、ファイルへ出力
syslog-ng の動作確認
インストール-
syslog-ngはCentOSのyumリポジトリには存在しない
動作確認-
作業内容は、Apache-httpdとsyslogと同一
- error_logは操作せず、access_logのみ操作
- syslog-ng.confの設定が、syslogと違う
swatch の動作確認 1
インストール-
リポジトリには存在していない
- Perlのスクリプトで、Perlのモジュールが必要
- PECLを利用しインストール
- gccがインストールされていることを確認
swatch の動作確認 2
設定ファイル/root/.swatchrc に設定を記述設定内容は、 ssh でのログインに失敗すると
ベルが鳴る
動作確認ssh localhost
で、ランダムなログイン名／パスワードを入力ログインに“わざと失敗”
logwatch の動作確認
インストール-
yum install logwatch
- CentOSはインストール済みのことが主流
動作確認 - --serviceオプションで、特定サービスのlogwatchの結果を得ることが可能
- 設定ファイルの方は、メールが必要なので、ここでは設定しない
logrotate の動作確認
既存のログを、 logrotate を使って更新 対象のログは、 Apache-httpd のログ Apache-httpd のログは、（標準の設定では） 1週間たたないと更新が発生しない
logrotate は最終更新日時の記録を持っているので、それを操作し、更新
12 章のまとめ
syslog サーバの構築 syslog-ng の設定・動作確認 swatch の設定・動作確認 logwatch の設定・動作確認 logrotate の設定・動作確認
top related