25
2013/6/19 Kazunori INABA 1 2013.6.19 Garage labsサーバー部9U Linuxサーバのセキュリティ対策 part2 ~僕がいつもやっていること 稲葉 一紀@札幌

Linuxサーバのセキュリティ対策 part2 - Apache編

Embed Size (px)

Citation preview

Page 1: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 1

2013.6.19Garage labsサーバー部9U

Linuxサーバのセキュリティ対策 part2~僕がいつもやっていること

稲葉 一紀@札幌

Page 2: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 2

自己紹介

稲葉 一紀 サーバーインフラ専門のフリーランスエンジニア@札幌

    おもにアプリ開発企業・エンジニア向けに

    セキュリティ・可用性・性能・拡張性を考慮した

    ちょっと気の利いた

    サーバーインフラ構成設計・設定・支援や既存システムの性能改善調査・支援

     を行います。

     札幌ライブ情報 公開中  http://wiki.livedoor.jp/sapporo_rock_live/

Page 3: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 3

セキュリティ対策 - 基本方針

・僕がサーバの設定を行うときにいつもやっていることを発表 します part2

・運用に手間をかけられなのであれば、できるだけPaaS, SaaS 的な外部サービスや共用レンタルサーバを利用して、自分で 設定、運用するサービスを減らす。  - 特にDNSとメールは自前でやらない!  - SSHとHTTP(S)のみ外部公開するのが理想。  - Webアプリケーションサーバ1台の運用保守を専門業者に   任せるといくらかかる?

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

Page 4: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 4

セキュリティ対策 - 項目

Part1 - 前回http://www.slideshare.net/kazunoriinaba/20130510-linuxsecurity1-21092608

・SSH・Firewall・iptables・TCP Wrapper・不要なサービスの停止・DNS bind

Part2 - 今回・(再)DNS bind・Apache

Page 5: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 5

セキュリティ対策 - 項目

Part3以降 - 次回・ファイル転送 FTP, SCP/SFTP, WebDAV・メール Postfix・アンチウイルス ClamAV・改ざん検知 Tripwire・SEO対策・その他やってないこと SELinux, IPS, WAF・技術以外の対策

以降、コマンドやConfigは、CentOSにおける例です。

Page 6: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 6

(再)DNS bind(1)

・DNSサーバの設定、運用は大変!  - 頻繁に発見されるbindの脆弱性、DNSサーバを利用した攻撃   の多さ、キャッシュにより設定ミスの時限爆弾化、仕様や設定の   複雑さ etc.  - DNSサーバのダウンや設定ミスはWebサーバダウンと同じこと。

・外部サービスの利用がおすすめ。  - キャッシュサーバは、サーバサービスベンダーが用意する   DNSサーバを利用。  - 権威(コンテンツ)サーバは、ドメイン管理業者が用意する   DNSサーバやAWS Route 53を利用。  

Page 7: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 7

(再)DNS bind(2)

どうしてもDNSサーバの運用が必要なとき、、、

・キャッシュサーバとしてのアクセス元IPアドレスを限定して、 オープンリゾルバーにならないようにする。 - オープンリゾルバーを利用したDNSリフレクター攻撃(参考)http://internet.watch.impress.co.jp/docs/interview/20130426_597628.html

  送信元IPアドレスを攻撃対象のIPアドレスに詐称した問い合わせを  オープンリゾルバーに送信   →オープンリゾルバーからの応答が攻撃対象に返る。

  ※実生活でいうと、「なりすまし出前注文」のようなもの。

Page 8: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 8

(再)DNS bind(3)

・オープンリゾルバーにならないための設定例。

(参考)http://jprs.jp/tech/notice/2013-04-18-fixing-bind-openresolver.html– named.conf...acl "TRUSTSRC" { // TRUSTSRCというacl作成の設定を追加します 192.168.0.0/24; localhost; };

options { ... //query-source port 53; // 外部への問い合わせ元のポート番号をランダム化します recursion yes; // リゾルバーとして動作します allow-query { TRUSTSRC; }; // TRUSTSRCからのみクエリを許可します allow-recursion { TRUSTSRC; }; // TRUSTSRCからのみリゾルバーとして動作します allow-query-cache { TRUSTSRC; }; // TRUSTSRCからのみキャッシュの内容を返します ... };   

Page 9: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 9

Apache(1)

・サーバの情報を隠す  - HTTP Serverレスポンスヘッダの情報は'Apache'のみとし、   Apacheのバージョンやサーバ情報を含めない。    ServerTokens ProductOnly

  - エラーメッセージ出力時にフッタに情報を表示しない。    ServerSignature Off

  ※攻撃手法が多様化する現在となっては効果が薄いかもしれな   いが、わざわざサーバの情報をさらす必要はないので設定する。

・フォワードプロキシを無効に(デフォルトは無効)  ProxyRequests Off

Page 10: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 10

Apache(2)

・Cross Site Tracing対策  - Cross Site Tracing(XST)とは?    TRACE メソッドのリクエストを発行させてHTTP要求ヘッダの    内容をAuthorizationフィールドから読み取ることで、BASIC認証    のID、パスワードを取得する攻撃手法。    (参考)    http://bakera.jp/glossary/Cross%20Site%20Tracing

  - TRACEメソッドを無効にする。    TraceEnable Off

Page 11: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 11

Apache(3)

・不要なモジュールは読み込まない  - 使用しないモジュールのLoadModule行をコメントアウト。    mod_authn_anon, mod_authn_dbm, mod_authz_dbm,    mod_ldap, mod_authnz_ldap, mod_dav, mod_dav_fs,    mod_proxy_ftp, mod_proxy_ajp, mod_cache,    mod_suexec, mod_disk_cache など。

  - メモリリソースの節約にもなる。  - PHPやSSLを使用しない場合、php.conf, ssl.confをIncludeしな   いだけで、Apacheプロセスのメモリ使用量はかなり少なくなる。     Include conf.d/* はコメントアウトして、使用するconfファイルのみ     明示的にIncludeする。

     #Include conf.d/*     Include conf.d/php.conf

Page 12: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 12

Apache(4)

・SSLサーバ証明書, HTTPS  - 不特定多数のユーザによるログインページ、個人情報入力ページ   では、認証局の証明書を使用したHTTPS通信とする。

  - ユーザに安心して情報を入力してもらうことが大切なので   「見た目はHTTPページだけどボタンを押したら内部的に    HTTPSで処理する。」はあまり意味がない。

  - サイト管理者・関係者しかセキュア通信を必要としないならば、   自己(オレオレ)証明書でもよい。

  - 基本的には、1サーバ(というか1Apache)で1ホスト名の証明書   しか使用できない。    ・IPアドレスが複数あれば、その分のホスト名の証明書を使用できる。

Page 13: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 13

Apache(5)

・BASIC認証の設定で注意すること  htpasswdコマンドでユーザエントリーを作成するときは、  -mオプションをつけないと、先頭の8文字しか認証に使用されない。  (9文字目以降が間違っていても認証が通る。)

  # htpasswd -m <passwdfile> <username>

  ※Linuxでは、htpasswdコマンドのデフォルトで、暗号化にcrypt()   関数が使用される。crypt()関数の暗号化では先頭の8文字しか   使用されない。  ※-mオプションをつけると、md5で暗号化する。

Page 14: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 14

Apache(6)

・管理者ページ、公開前ページのアクセス制限  - できれば、アクセス元IPアドレスを限定する。     Order deny, allow     Deny from all     Allow from <IPアドレス>

  ※アクセス元IPアドレス(REMOTE_ADDRヘッダ)がProxyや   ロードバランサーとなってしまう場合...    ①X-Forwarded-Forヘッダで制御する。    ②mod_extract_forwardedモジュールを使用して、     REMOTE_ADDRヘッダを書き換えると、通常どおりのIPアドレス     制御ができる。

   (参考)    http://blog.suz-lab.com/2010/05/apacheremoteaddrelbcentos.html

Page 15: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 15

Apache(7)

・管理者ページ、公開前ページのアクセス制限(つづき)  - モバイル使用などアクセス元IPアドレスが不定であれば、アクセス   元IPアドレスとBASIC認証のいずれかでアクセス可能とする。     Order deny, allow     Deny from all     Allow from <IPアドレス>

     AuthType Basic     AuthUserFile /var/www/.htpasswd     AuthName ’MembersOnly’     require valid-user

     Satisfy Any

  - phpMyAdminやユーザの個人データを直接参照できるページは   HTTPS必須とする。     SSLRequireSSL

Page 16: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 16

Apache(8)

・DoS攻撃対策 mod_dosdetector  - 同一IPアドレスからの集中アクセスをブロックする、   はてな田中さんが作成したモジュール。    (参考)http://tkyk.name/blog/2009/05/07/Apache-mod_dosdetector-Server-mod_dosdetector/

  - F5キー押しっぱなしによる悪意のない連続アクセスや、   取得間隔の短いなんちゃってクローラー    によるサーバ負荷上昇やダウンを防げる。

  - アクセス元IPアドレス(REMOTE_ADDRヘッダ)がProxyや   ロードバランサーとなってしまう場合    →全ユーザのアクセスがカウント対象となってしまう。    →mod_extract_forwardedモジュールを使用する。

Page 17: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 17

Apache(9)

・DoS攻撃対策 mod_dosdetector 設定例    「同一IPアドレスから5秒間に50回アクセスがあったら、30秒間     エラーとみなす。」

パラメータ 設定値の例 意味

DoSDetection on DoS攻撃判定を有効にする。

DoSPeriod 5 DoS攻撃アクセスの判定秒数。

DoSThreshold 50 同一IPアドレスからDoSPeriodの間に何回アクセスがきたらエラーと判定するかの閾値。閾値を超えると、環境変数SuspectDoS, SuspectHardDoSに1がセットされる。

DoSHardThreshold 100

DoSBanPeriod 30 エラーと判定されてから解除されるまでの秒数。

DoSTableSize 300 アクセス元IPアドレスの保存数。

DoSIgnoreContentType image|javascript|css

攻撃判定時にカウントしないContent Mime Type。これにより、1PVを1アクセスとカウントするようにする

Page 18: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 18

Apache(10)

・DoS攻撃対策 mod_dosdetector 設定例(つづき)  - パラメータを設定しただけでは、ログを書き出すのみで攻撃を   ブロックしない。

– Apacheエラーログ /var/log/httpd/error_log[Sat May 25 02:07:39 2013] [notice] dosdetector: 'xxx.xxxx.xxx.xxx' is suspected as Hard DoS attack! (counter: 101)--

  - 適用させたいVirtualHostやDirectory, Locationで環境変数   SuspectDoS, SuspectHardDoSに対する動作を指定する。    下記は、ハードエラー時に、503ステータスを返す例。

RewriteCond %{ENV:SuspectHardDoS} =1 RewriteRule .* - [R=503,L]

Page 19: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 19

Apache(11)

・メジャーなアプリケーションのセキュリティ対策  - (アプリケーションを設置していてもしていなくても)   /phpMyAdmin, /wp-login.php, /mt.cgi 等の管理ページへの   ログインチャレンジはかなり多い。アクセスログを確認してみると   よい。

--216.55.183.111 - - [10/Jun/2013:21:05:19 +0900] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 226 "-" "Mozilla/4.0 (compatible; MSIE 6.0; MSIE 5.5; Windows NT 5.1) Opera 7.01 [en]"--

  - ユーザID adminは使用しない。(必須)

  - 可能であれば、管理ページへのアクセス元IPアドレスを限定する。

Page 20: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 20

Apache(12)

・メジャーなアプリケーションのセキュリティ対策(続き)  - phpMyAdmin     ・パス名を少し工夫する /pMyAdmin など。     ・DBに個人情報が含まれるならば、HTTPS必須とする。

  - WordPress(すみません、運用実績はありません。)    ・Limit Login Attemptsプラグインで不正ログインをロックアウトする。    ・Stealth Login Page プラグインで、ログインページのURLを隠す。

  - Movable Type(すみません、運用実績はありません。)    ・認証ロックアウト機能を適切に設定する。    ・管理ページmt.cgiのファイル名をrenameする。    ・検索ページmt-search.cgiのファイル名をrenameする。

Page 21: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 21

Apache(13)

・IPアドレス直打ちアクセスを弾く  - 意図した設定でない限り、http://111.222.xxx.xxx/~ のような   IPアドレス直打ちアクセスは、ほぼ不正アクセスである。

  - NameVirtualHostを使用した場合、IPアドレス直打ちアクセスは、   configで最初に指定したVirtualHostが使われる。   (Apacheの仕様)    →これを利用して、ダミーのVirtualHost設定を用意する。

Page 22: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 22

Apache(14)

・IPアドレス直打ちアクセスを弾く(続き)

<VirtualHost *:80> // ダミー用の定義 DocumentRoot /var/www/dummy // 中身は空っぽにする ServerName dummy.com CustomLog logs/dummy.com-access_log // ログもちゃんととる ErrorLog logs/dummy.com-error_log</VirtualHost>

<VirtualHost *:80> // 本サイト用の定義 DocumentRoot /var/www/html ServerName www.example.com  ~</VirtualHost>

Page 23: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 23

Apache(15)

・IPアドレス直打ちアクセスを弾く(余談)  VirutalHostの定義は別ファイルにして、httpd.confからInclude  すると、設定管理がすっきりします。

Include conf/vhost_dummy.com.confInclude conf/vhost_www.example.com.conf

Page 24: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 24

(次回)ファイル転送 FTP, SFTP, WebDAV

・お客様による静的コンテンツファイルのメンテナンス用に、 FTPサーバの設置が必要となることも多い。  - Web公開するコンテンツファイルの転送だから暗号化は不要、   とよく言われるが...OSのユーザパスワードが平文で流れる!   (メール送受信のPOP/SMTPも同じことだけど...)

  - FTPが許されるなら、端末ログインはSSHじゃなくてtelnetでい   いし、ログインフォームもHTTPSじゃなくてHTTPでよいの   では...

  - と思うけど、できるだけセキュリティ対策を施して稼働させる。

  - FTP over SSLで暗号化する方法や、SFTP, WebDAVで代替する   方法もある。

    

Page 25: Linuxサーバのセキュリティ対策 part2 - Apache編

2013/6/19 Kazunori INABA 25

  ご質問、ご相談は直接、またはこちらまで。   e-mail: [email protected]