1. 2014.2.5
Garage labsサーバー部12U
Linuxサーバーのセキュリティ対策 part4
～僕がいつもやっていること
稲葉 一紀@札幌
2014/2/5
Kazunori INABA
1

2. 自己紹介
稲葉 一紀
サーバーインフラ専門のフリーランスエンジニア＠札幌
稲葉サーバーデザイン http://inaba-serverdesign.jp/
おもにアプリ開発企業・エンジニア向けに
セキュリティ・可用性・性能・拡張性を考慮した
ちょっと気の利いた
サーバーインフラ構成設計・設定・支援や既存システムの性能改善調査・支援
を行います。
札幌ライブ情報 公開中 （URLが変わりました）
http://seesaawiki.jp/w/sapporo_rock_live/
2014/2/5
Kazunori INABA
2

3. セキュリティ対策 - 基本方針
・僕がサーバーの設定を行うときにいつもやっていることを発表
します part4（最後）
・できるだけ、信頼できるPaaS, SaaS的な外部サービスや
共用レンタルサーバーを利用して、自分で設定、運用する
サービスを減らす。
- 特にDNSとメールは自前でやらない！
- SSHとHTTP(S)のみ外部公開するのが理想。
- Webアプリケーションサーバー1台の運用保守を専門業者に
任せるといくらかかる？→それぐらいコストがかかること。
・どんな対策をしても、やられるときはやられる！
それでも、できるだけ少ない手間で基本的な設定を行い、
不正アクセスされる確率を減らす。
2014/2/5
Kazunori INABA
3

4. セキュリティ対策 - 基本方針
基本方針についてわかりやすい資料
・インフィニットループ社内勉強会資料
1時間でざっくり教えるサーバ運営超入門
http://www.slideshare.net/infinite_loop/1-10128499
2014/2/5
Kazunori INABA
4

5. セキュリティ対策 - 項目
Part1
・SSH
・Firewall
・iptables
・TCP Wrapper
・不要なサービスの停止
・DNS bind
http://www.slideshare.net/kazunoriinaba/20130510-linuxsecurity1-21092608
Part2 - Apache編
・（再）DNS bind
・Apache
http://www.slideshare.net/kazunoriinaba/20130619-linuxsecurity2
2014/2/5
Kazunori INABA
5

6. セキュリティ対策 - 項目
Part3 - ファイル転送編
・Apache補足
・ファイル転送 FTP, SCP/SFTP, WebDAV
http://www.slideshare.net/kazunoriinaba/20130717-linuxsecurity3
Part4（今回、最後）
・データベース MySQL
・メール Postfix
・アンチウイルス ClamAV
・改ざん検知 Tripwire
・リアルタイムログ監視 Swatch, logmon
・IDS, IPS Snort
以降、コマンドやConfigは、CentOSにおける例です。
2014/2/5
Kazunori INABA
6

7. データベース MySQL(1)
・TCP/3306ポートを外部に公開しない。
・インストール時にmysql_secure_installationコマンドでセキュリ
ティ設定を行う。
- 匿名ユーザーを削除。
- rootユーザーのリモートログインを禁止。（または限定）
・アプリケーション専用ユーザーを作成し、権限とアクセスする
データベーススキーマを限定する。
rootユーザーを使用しない！
・やむを得ずインターネット越しにアクセスする場合はSSLを使用。
2014/2/5
Kazunori INABA
7

8. データベース MySQL(2)
・phpMyAdmin
- HTTPSを必須として、DBデータ参照時の通信を暗号化する。
- DBユーザーのログイン認証だけではなく、アクセス元IPアドレス
の制限、クライアント証明書、BASIC/Digest認証などと組み
合わせてセキュリティを強化。
2014/2/5
Kazunori INABA
8

9. メール Postfix(1)
・メールサーバーの設定、運用は大変！
- マルチバーチャルドメイン、メーリングリスト、ウイルスチェック、
スパムメールフィルタ、暗号化通信、Webメール、PostfixAdmin等
のGUI管理ツールなどなど。
- SMTPポートへのログインチャレンジも多い。
※Webサーバー上でメールサーバーも運用する場合は、運用保守
費を5割増ぐらいにしてもよいのでは。。。
・さくらのメールボックス（1,000円/年）、Bizメール（1ID 315円/月）
などの外部サービスの利用がおすすめ。
・メルマガ等の大量メール配信も、携帯キャリアへの送信等の
ノウハウを持っている外部サービス利用がおすすめ。
2014/2/5
Kazunori INABA
9

10. メール Postfix(2)
・できれば、アプリケーションや監視ツール等による送信のみ
とする。
- 上位ファイアウォール、iptablesでSMTP(TCP/25)を塞ぐ。
- SMTPポートをListenするアドレスを限定する。
inet_interfaces = localhost
どうしても受信、SMTP, POP/IMAP環境が必要なとき、、、
・不正中継（リレー）されないようにする。
mynetworks = 127.0.0.1, <リレーを許可するサーバー>
・POP over SSL/SMTP over SSL/IMAP over SSLによる
暗号化、SMTP Authは必須。
2014/2/5
Kazunori INABA
10

11. アンチウイルス ClamAV
・オープンソースのアンチウイルスソフト。
設定手順は以下が詳しい。
http://centossrv.com/clamav.shtml
・定期的にフルスキャンを実施する設定を行うとよい。
- スキャン前に、ClamAV自身とウイルス定義をアップデートする。
- ウイルス検知時に即時削除するかメッセージを出力するのみ
かは設定可能。
誤検知することもある。古いPHPパッケージなど。
・リアルタイムスキャンは、サーバーに負荷がかかり、また、
ディレクトリの作成し直しが必要。（未経験）
・Postfixとの連携でメールのウイルスチェックも可。（未経験）
2014/2/5
Kazunori INABA
11

12. 改ざん検知 Tripwire
・指定したファイルやディレクトリの変化をチェックしてレポートで
知らせるツール。設定手順は以下など。
http://centossrv.com/tripwire.shtml
・監視対象や検知ポリシーの設定が可能。
- Webコンテンツは静的コンテンツのみ監視対象とする。
- コンテンツだけではなく、各種ConfigやOS基本コマンドの
改ざん(rootkit的な)検知にも有効。
・短所
- ポリシーファイルに監視対象を設定するのがやや難しい。
- 予定されたConfigの変更でも、状態をアップデートしないと
いちいちアラートメールが届く。（当然だけど）
→運用はわりと大変。
2014/2/5
Kazunori INABA
12

13. リアルタイムログ監視 Swatch
・指定したログファイルを監視し、指定した文字列が出現したとき
にアラートメールを送信する。
ログイン認証エラー 'authentication failure' など。
・設定手順は以下など。
http://www.aconus.com/~oyaji/security/swatch.htm
・検知対象の文字列が大量に出現した際の、アラートメールの
送信を抑制する設定が可能。
・Apacheのエラーログやアプリケーションのログ監視にも便利。
・監視対象のログファイルの分だけtailプロセスが常駐するので、
メモリ使用量が少し増えることに注意。
2014/2/5
Kazunori INABA
13

14. リアルタイムログ監視 logmon
・IBMが提供するログ監視ツール
http://www-06.ibm.com/jp/linux/tech/doc/00057580.html
・機能はSwatchとほぼ同等だが、logmonのほうがインストール
が簡単で設定がシンプル。
2014/2/5
Kazunori INABA
14

15. ソフトウェアIDS, IPS - Snort(1)
・IDS（Intrusion Detection System, 不正侵入検知）として使用
- ルールに基づいてパケットを検査し、不正なアクセスがあればログ
に書き出す（のみ。アクセスはできてしまう）。
・IPS（Intrusion Prevention System, 不正侵入防止）として使用
- インターネットと防御対象サーバーの間に挟み込む構成
（Inlineモード）。
- iptablesと組み合わせる。
- ルールに基づいてパケットを検査し、不正なアクセスがあれば
パケットを破棄し、ログに書き出す。
→不正アクセスを自動でブロック。
構築手順をまとめました。
http://inaba-serverdesign.jp/blog/20140131/snort_inline_ips.html
2014/2/5
Kazunori INABA
15

16. ソフトウェアIDS, IPS - Snort(2)
Snortの運用
・不正アクセス発生時の通知はSwatchを使用するとよい。
・誤検知があるので、ルールのチューニングが必要。
- 事前に十分な動作確認を。
- 無料配布ルールファイルは、かなりのルールがコメントアウト
されていることに注意。
・攻撃を想定したテストは難しい。
- ツールが少ない。
- 利用しているISP、サーバーサービスによっては外部からの
攻撃テストは申請が必要 or 禁止の場合もあるので注意。
→例えば、AWSは申請が必要。
http://aws.amazon.com/jp/security/penetration-testing/
2014/2/5
Kazunori INABA
16

17. まとめ
・信頼できるPaaS, SaaS的な外部サービスや共用レンタル
サーバーを利用して、自分で設定、運用するサービスを
減らそう。
・基本的な対策を行って、不正アクセスされる確率を減らそう。
・サーバーやミドルウェアの設定だけでは、アプリケーション
レイヤまでは守れないことに注意しよう。
2014/2/5
Kazunori INABA
17