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/i ptablesindex.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 port1 ssh –Lによるトンネリング host2 port2 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の働き従来のアクセス SELinux環境でのアクセスプロセスプロセスアクセス権の確認アクセス権の確認 Linux Security Module カーネルカーネルファイル等のリソースファイル等のリソース機能構成図 TE 最小特権セキュアOSの必要項目 RBAC ドメイン遷移強制アクセス制御(MAC) 監査ログ(AVC) 強制アクセス制御  「セキュリティポリシファイル」に、アクセスについての記述  設定は、ユーザやファイル・ディレクトリのオーナではなく、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ログのフォーマット  ログには次の内容が含まれる scontext=アクセスしたプロセスのドメインコンテキスト 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 deny from 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の設定・動作確認