2014.2.5
Garage labsサーバー部12U

Linuxサーバーのセキュリティ対策 part4
~僕がいつもやっていること
稲葉 一紀@札幌

2014/2/5

Kazunori INABA

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

Kazunori INABA

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

・どんな対策をしても、やられるときはやられる!
  それでも、できるだけ少ない手間で基本的な設定を行い、
  不正アクセスされる確率を減らす。
2014/2/5

Kazunori INABA

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

2014/2/5

Kazunori INABA

4
セキュリティ対策 - 項目
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
セキュリティ対策 - 項目
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
データベース MySQL(1)
・TCP/3306ポートを外部に公開しない。
・インストール時にmysql_secure_installationコマンドでセキュリ
 ティ設定を行う。
  - 匿名ユーザーを削除。
  - rootユーザーのリモートログインを禁止。(または限定)

・アプリケーション専用ユーザーを作成し、権限とアクセスする
 データベーススキーマを限定する。
  rootユーザーを使用しない!
・やむを得ずインターネット越しにアクセスする場合はSSLを使用。

2014/2/5

Kazunori INABA

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

2014/2/5

Kazunori INABA

8
メール Postfix(1)
・メールサーバーの設定、運用は大変!
  - マルチバーチャルドメイン、メーリングリスト、ウイルスチェック、
   スパムメールフィルタ、暗号化通信、Webメール、PostfixAdmin等
   のGUI管理ツールなどなど。
  - SMTPポートへのログインチャレンジも多い。
  ※Webサーバー上でメールサーバーも運用する場合は、運用保守
   費を5割増ぐらいにしてもよいのでは。。。

・さくらのメールボックス(1,000円/年)、Bizメール(1ID 315円/月)
 などの外部サービスの利用がおすすめ。
・メルマガ等の大量メール配信も、携帯キャリアへの送信等の 
 ノウハウを持っている外部サービス利用がおすすめ。
2014/2/5

Kazunori INABA

9
メール 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
アンチウイルス ClamAV
・オープンソースのアンチウイルスソフト。
  設定手順は以下が詳しい。
  http://centossrv.com/clamav.shtml

・定期的にフルスキャンを実施する設定を行うとよい。
  - スキャン前に、ClamAV自身とウイルス定義をアップデートする。
  - ウイルス検知時に即時削除するかメッセージを出力するのみ
   かは設定可能。
    誤検知することもある。古いPHPパッケージなど。

・リアルタイムスキャンは、サーバーに負荷がかかり、また、
 ディレクトリの作成し直しが必要。(未経験)
・Postfixとの連携でメールのウイルスチェックも可。(未経験)
2014/2/5

Kazunori INABA

11
改ざん検知 Tripwire
・指定したファイルやディレクトリの変化をチェックしてレポートで
 知らせるツール。設定手順は以下など。
  http://centossrv.com/tripwire.shtml

・監視対象や検知ポリシーの設定が可能。

  - Webコンテンツは静的コンテンツのみ監視対象とする。
  - コンテンツだけではなく、各種ConfigやOS基本コマンドの
   改ざん(rootkit的な)検知にも有効。

・短所
  - ポリシーファイルに監視対象を設定するのがやや難しい。
  - 予定されたConfigの変更でも、状態をアップデートしないと
   いちいちアラートメールが届く。(当然だけど)
    →運用はわりと大変。
2014/2/5

Kazunori INABA

12
リアルタイムログ監視 Swatch
・指定したログファイルを監視し、指定した文字列が出現したとき
 にアラートメールを送信する。
   ログイン認証エラー 'authentication failure' など。

・設定手順は以下など。
  http://www.aconus.com/~oyaji/security/swatch.htm

・検知対象の文字列が大量に出現した際の、アラートメールの
 送信を抑制する設定が可能。
・Apacheのエラーログやアプリケーションのログ監視にも便利。
・監視対象のログファイルの分だけtailプロセスが常駐するので、
 メモリ使用量が少し増えることに注意。
2014/2/5

Kazunori INABA

13
リアルタイムログ監視 logmon
・IBMが提供するログ監視ツール
  http://www-06.ibm.com/jp/linux/tech/doc/00057580.html

・機能はSwatchとほぼ同等だが、logmonのほうがインストール 
 が簡単で設定がシンプル。

2014/2/5

Kazunori INABA

14
ソフトウェア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
ソフトウェアIDS, IPS - Snort(2)
Snortの運用
・不正アクセス発生時の通知はSwatchを使用するとよい。

・誤検知があるので、ルールのチューニングが必要。
  - 事前に十分な動作確認を。
  - 無料配布ルールファイルは、かなりのルールがコメントアウト
   されていることに注意。

・攻撃を想定したテストは難しい。
  - ツールが少ない。
  - 利用しているISP、サーバーサービスによっては外部からの
   攻撃テストは申請が必要 or 禁止の場合もあるので注意。
    →例えば、AWSは申請が必要。
      http://aws.amazon.com/jp/security/penetration-testing/
2014/2/5

Kazunori INABA

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

2014/2/5

Kazunori INABA

17

Linuxサーバーのセキュリティ対策 part4