Linuxサーバのセキュリティ対策 part2 - Apache編
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 11,788 views

 

Statistics

Views

Total Views
11,788
Views on SlideShare
11,408
Embed Views
380

Actions

Likes
13
Downloads
69
Comments
0

4 Embeds 380

http://inaba-serverdesign.jp 358
http://172.18.10.229 20
https://twitter.com 1
http://www.google.co.jp 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 1. 2013/6/19 Kazunori INABA 12013.6.19Garage labsサーバー部9ULinuxサーバのセキュリティ対策 part2~僕がいつもやっていること稲葉 一紀@札幌
  • 2. 2013/6/19 Kazunori INABA 2自己紹介稲葉 一紀 サーバーインフラ専門のフリーランスエンジニア@札幌    おもにアプリ開発企業・エンジニア向けに    セキュリティ・可用性・性能・拡張性を考慮した    ちょっと気の利いた    サーバーインフラ構成設計・設定・支援や既存システムの性能改善調査・支援     を行います。     札幌ライブ情報 公開中  http://wiki.livedoor.jp/sapporo_rock_live/
  • 3. 2013/6/19 Kazunori INABA 3セキュリティ対策 - 基本方針・僕がサーバの設定を行うときにいつもやっていることを発表 します part2・運用に手間をかけられなのであれば、できるだけPaaS, SaaS 的な外部サービスや共用レンタルサーバを利用して、自分で 設定、運用するサービスを減らす。  - 特にDNSとメールは自前でやらない!  - SSHとHTTP(S)のみ外部公開するのが理想。  - Webアプリケーションサーバ1台の運用保守を専門業者に   任せるといくらかかる?・どんな対策をしても、やられるときはやられる!  それでも、できるだけ少ない手間で基本的な設定を行い、  不正アクセスされる確率を減らす。
  • 4. 2013/6/19 Kazunori INABA 4セキュリティ対策 - 項目Part1 - 前回http://www.slideshare.net/kazunoriinaba/20130510-linuxsecurity1-21092608・SSH・Firewall・iptables・TCP Wrapper・不要なサービスの停止・DNS bindPart2 - 今回・(再)DNS bind・Apache
  • 5. 2013/6/19 Kazunori INABA 5セキュリティ対策 - 項目Part3以降 - 次回・ファイル転送 FTP, SCP/SFTP, WebDAV・メール Postfix・アンチウイルス ClamAV・改ざん検知 Tripwire・SEO対策・その他やってないこと SELinux, IPS, WAF・技術以外の対策以降、コマンドやConfigは、CentOSにおける例です。
  • 6. 2013/6/19 Kazunori INABA 6(再)DNS bind(1)・DNSサーバの設定、運用は大変!  - 頻繁に発見されるbindの脆弱性、DNSサーバを利用した攻撃   の多さ、キャッシュにより設定ミスの時限爆弾化、仕様や設定の   複雑さ etc.  - DNSサーバのダウンや設定ミスはWebサーバダウンと同じこと。・外部サービスの利用がおすすめ。  - キャッシュサーバは、サーバサービスベンダーが用意する   DNSサーバを利用。  - 権威(コンテンツ)サーバは、ドメイン管理業者が用意する   DNSサーバやAWS Route 53を利用。  
  • 7. 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アドレスに詐称した問い合わせを  オープンリゾルバーに送信   →オープンリゾルバーからの応答が攻撃対象に返る。  ※実生活でいうと、「なりすまし出前注文」のようなもの。
  • 8. 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からのみキャッシュの内容を返します...};  
  • 9. 2013/6/19 Kazunori INABA 9Apache(1)・サーバの情報を隠す  - HTTP Serverレスポンスヘッダの情報はApacheのみとし、   Apacheのバージョンやサーバ情報を含めない。    ServerTokens ProductOnly  - エラーメッセージ出力時にフッタに情報を表示しない。    ServerSignature Off  ※攻撃手法が多様化する現在となっては効果が薄いかもしれな   いが、わざわざサーバの情報をさらす必要はないので設定する。・フォワードプロキシを無効に(デフォルトは無効)  ProxyRequests Off
  • 10. 2013/6/19 Kazunori INABA 10Apache(2)・Cross Site Tracing対策  - Cross Site Tracing(XST)とは?    TRACE メソッドのリクエストを発行させてHTTP要求ヘッダの    内容をAuthorizationフィールドから読み取ることで、BASIC認証    のID、パスワードを取得する攻撃手法。    (参考)    http://bakera.jp/glossary/Cross%20Site%20Tracing  - TRACEメソッドを無効にする。    TraceEnable Off
  • 11. 2013/6/19 Kazunori INABA 11Apache(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
  • 12. 2013/6/19 Kazunori INABA 12Apache(4)・SSLサーバ証明書, HTTPS  - 不特定多数のユーザによるログインページ、個人情報入力ページ   では、認証局の証明書を使用したHTTPS通信とする。  - ユーザに安心して情報を入力してもらうことが大切なので   「見た目はHTTPページだけどボタンを押したら内部的に    HTTPSで処理する。」はあまり意味がない。  - サイト管理者・関係者しかセキュア通信を必要としないならば、   自己(オレオレ)証明書でもよい。  - 基本的には、1サーバ(というか1Apache)で1ホスト名の証明書   しか使用できない。    ・IPアドレスが複数あれば、その分のホスト名の証明書を使用できる。
  • 13. 2013/6/19 Kazunori INABA 13Apache(5)・BASIC認証の設定で注意すること  htpasswdコマンドでユーザエントリーを作成するときは、  -mオプションをつけないと、先頭の8文字しか認証に使用されない。  (9文字目以降が間違っていても認証が通る。)  # htpasswd -m <passwdfile> <username>  ※Linuxでは、htpasswdコマンドのデフォルトで、暗号化にcrypt()   関数が使用される。crypt()関数の暗号化では先頭の8文字しか   使用されない。  ※-mオプションをつけると、md5で暗号化する。
  • 14. 2013/6/19 Kazunori INABA 14Apache(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
  • 15. 2013/6/19 Kazunori INABA 15Apache(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
  • 16. 2013/6/19 Kazunori INABA 16Apache(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モジュールを使用する。
  • 17. 2013/6/19 Kazunori INABA 17Apache(9)・DoS攻撃対策 mod_dosdetector 設定例    「同一IPアドレスから5秒間に50回アクセスがあったら、30秒間     エラーとみなす。」パラメータ 設定値の例 意味DoSDetection on DoS攻撃判定を有効にする。DoSPeriod 5 DoS攻撃アクセスの判定秒数。DoSThreshold 50 同一IPアドレスからDoSPeriodの間に何回アクセスがきたらエラーと判定するかの閾値。閾値を超えると、環境変数SuspectDoS,SuspectHardDoSに1がセットされる。DoSHardThreshold 100DoSBanPeriod 30 エラーと判定されてから解除されるまでの秒数。DoSTableSize 300 アクセス元IPアドレスの保存数。DoSIgnoreContentType image|javascript|css攻撃判定時にカウントしないContent MimeType。これにより、1PVを1アクセスとカウントするようにする
  • 18. 2013/6/19 Kazunori INABA 18Apache(10)・DoS攻撃対策 mod_dosdetector 設定例(つづき)  - パラメータを設定しただけでは、ログを書き出すのみで攻撃を   ブロックしない。– Apacheエラーログ /var/log/httpd/error_log[Sat May 25 02:07:39 2013] [notice] dosdetector: xxx.xxxx.xxx.xxx is suspectedas Hard DoS attack! (counter: 101)--  - 適用させたいVirtualHostやDirectory, Locationで環境変数   SuspectDoS, SuspectHardDoSに対する動作を指定する。    下記は、ハードエラー時に、503ステータスを返す例。RewriteCond %{ENV:SuspectHardDoS} =1RewriteRule .* - [R=503,L]
  • 19. 2013/6/19 Kazunori INABA 19Apache(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アドレスを限定する。
  • 20. 2013/6/19 Kazunori INABA 20Apache(12)・メジャーなアプリケーションのセキュリティ対策(続き)  - phpMyAdmin     ・パス名を少し工夫する /pMyAdmin など。     ・DBに個人情報が含まれるならば、HTTPS必須とする。  - WordPress(すみません、運用実績はありません。)    ・Limit Login Attemptsプラグインで不正ログインをロックアウトする。    ・Stealth Login Page プラグインで、ログインページのURLを隠す。  - Movable Type(すみません、運用実績はありません。)    ・認証ロックアウト機能を適切に設定する。    ・管理ページmt.cgiのファイル名をrenameする。    ・検索ページmt-search.cgiのファイル名をrenameする。
  • 21. 2013/6/19 Kazunori INABA 21Apache(13)・IPアドレス直打ちアクセスを弾く  - 意図した設定でない限り、http://111.222.xxx.xxx/~ のような   IPアドレス直打ちアクセスは、ほぼ不正アクセスである。  - NameVirtualHostを使用した場合、IPアドレス直打ちアクセスは、   configで最初に指定したVirtualHostが使われる。   (Apacheの仕様)    →これを利用して、ダミーのVirtualHost設定を用意する。
  • 22. 2013/6/19 Kazunori INABA 22Apache(14)・IPアドレス直打ちアクセスを弾く(続き)<VirtualHost *:80> // ダミー用の定義DocumentRoot /var/www/dummy // 中身は空っぽにするServerName dummy.comCustomLog logs/dummy.com-access_log // ログもちゃんととるErrorLog logs/dummy.com-error_log</VirtualHost><VirtualHost *:80> // 本サイト用の定義DocumentRoot /var/www/htmlServerName www.example.com  ~</VirtualHost>
  • 23. 2013/6/19 Kazunori INABA 23Apache(15)・IPアドレス直打ちアクセスを弾く(余談)  VirutalHostの定義は別ファイルにして、httpd.confからInclude  すると、設定管理がすっきりします。Include conf/vhost_dummy.com.confInclude conf/vhost_www.example.com.conf
  • 24. 2013/6/19 Kazunori INABA 24(次回)ファイル転送 FTP, SFTP, WebDAV・お客様による静的コンテンツファイルのメンテナンス用に、 FTPサーバの設置が必要となることも多い。  - Web公開するコンテンツファイルの転送だから暗号化は不要、   とよく言われるが...OSのユーザパスワードが平文で流れる!   (メール送受信のPOP/SMTPも同じことだけど...)  - FTPが許されるなら、端末ログインはSSHじゃなくてtelnetでい   いし、ログインフォームもHTTPSじゃなくてHTTPでよいの   では...  - と思うけど、できるだけセキュリティ対策を施して稼働させる。  - FTP over SSLで暗号化する方法や、SFTP, WebDAVで代替する   方法もある。    
  • 25. 2013/6/19 Kazunori INABA 25  ご質問、ご相談は直接、またはこちらまで。   e-mail: i-ask@inaba-serverdesign.jp