Orenosp User's Guide for version 0.8.5 or later Table of Contents - HTTP/HTTPS Reverse Proxy Basics - Absolute URLs in Contents - Load-Balancing HTTP/HTTPS Servers - Virtual hosts and SSL server certificate - HTTP Compression - Nimda Filters - Referer Checking - Request Policing - Access and Performance Logging - User Authentication - External Authentication Servers - Client Certificate Mapping and Authorization - IP-based Access Control - Bandwidth Control - Local File Serving for Menu Pages - Processing Order - IPv4 <-> IPv6 - Proxy-Backend Communication - Adding Arbitrary Request/Response Headers - Simple Content Rewrite - Regular Expression Based Content Rewrite - Response Headers Rewrite - Cookie Attribute Translation - Advanced Reverse Proxy Configurations - Outlook Web Access (OWA) - Interoperability Tips with IIS - Miscellaneous Parameters - SSL Client Authentication - SSL Profiles For Secure Port Forwarding (SSL Tunneling), see SSL Tunneling Guide (tunnel/ssltunnel_en.txt). はじめに各パラメータ／オプションなどの正確な文法については/padmin/doc/ sproxy_full.txtを参照してください。 HTTP/HTTPS Reverse Proxy Basics =============================== 個別のパラメータの説明はsproxy_full.txtを参照してください。ここではいくつか例をあげます。例-1 外部向けポート内部ポート web page (Orenosp) (内部httpサーバー) ---------------------------------------------------------------------------- 80 http --> 10001 http 公開 web page 443 https --> 10002 http 安全な公開 web page 8888 https --> 10009 http 管理用 web page --- sproxy.conf --- #まずリスンするエンドポイント(以降リスンポートと呼ぶ)を定義し名前を付けます # proxy_listen_name = lis-http 0.0.0.0@80 http proxy_listen_name = lis-ssl 0.0.0.0@443 https proxy_listen_name = lis-admin 0.0.0.0@8888 https #そのリスンポートで受けたリクエストをフォワードするバックエンドサーバを #指定します #

proxy_pass_by = lis lis-http http://localhost:10001 proxy_pass_by = lis lis-ssl http://localhost:10002 proxy_pass_by = lis lis-admin http://localhost:10009 --- 内部web serverの設定 --- - ポート10001で公開 web pageを提供する - ポート10002で安全な公開 web pageを提供する - ポート10009で管理用 web pageを提供する - すべてのポートで、Orenospからだけリクエストを受け付けるように IP制限する。例-2 内部httpサーバではポート番号ではなく仮想ホスト名で差別化する例外部向けポート内部仮想ホスト名 web page (Orenosp) (内部httpサーバー) ---------------------------------------------------------------------------- 80 http --> unsecure-pub http 公開 web page 443 https --> secure-pub http 安全な公開 web page 8888 https --> secure-admin http 管理用 web page --- sproxy.conf --- # proxy_listen_name = lis-http 0.0.0.0@80 http proxy_listen_name = lis-ssl 0.0.0.0@443 https proxy_listen_name = lis-admin 0.0.0.0@8888 https # ３つのリスンポートで受け付けたリクエストはどれも http://localhost/に # 転送します。ただし転送する際にHost:ヘッダに-hhで指定した # 仮想ホスト名を付与します。 #

proxy_pass_by = lis lis-http http://localhost -hh=unsecure-pub proxy_pass_by = lis lis-ssl http://localhost -hh=secure-pub proxy_pass_by = lis lis-admin http://localhost -hh=secure-admin --- 内部web serverの設定 --- - リスンポートは80のみ。 - 仮想ホスト名 unsecure-pub で公開 web pageを提供する - 仮想ホスト名 secure-pub で安全な公開 web pageを提供する - 仮想ホスト名 secure-admin で管理用 web pageを提供する - すべての仮想ホストで、Orenospからだけリクエストを受け付けるように IP制限する。例-3 複数の仮想ホスト名を用いてサーバを公開する。内部サーバでも仮想ホスト名で差別化する。外部向けポート・ホスト名内部仮想ホスト名 web page (Orenosp) (内部httpサーバー) ---------------------------------------------------------------------------- 443 https : spub1.example.com --> secure-pub-1 http 安全な公開 web page 1 443 https : spub2.example.com --> secure-pub-2 http 安全な公開 web page 2 443 https : sadmin.example.com --> secure-admin http 管理用 web page --- sproxy.conf --- # 定義するリスンポートは一つだけ # proxy_listen_name = lis-ssl 0.0.0.0@443 https # 受け付けたリクエストの転送先を決定する際に、オリジナルリクエスト内の # Host:ヘッダーの値を参照しその値で転送先を決めます。 # ただし転送する際にHost:ヘッダに-hhで指定した仮想ホスト名を付与します。 #

proxy_pass_by = vhost spub1.example.com http://localhost -hh=unsecure-pub proxy_pass_by = vhost spub2.example.com http://localhost -hh=secure-pub proxy_pass_by = vhost sadmin.example.com http://localhost -hh=secure-admin --- 内部web serverの設定 --- - リスンポートは80のみ。 - 仮想ホスト名 secure-pub-1 で安全な公開 web page 1を提供する - 仮想ホスト名 secure-pub-2 で安全な公開 web page 2を提供する - 仮想ホスト名 secure-admin で管理用 web pageを提供する - すべての仮想ホストで、Orenospからだけリクエストを受け付けるように IP制限する。 --- HTTPSでこの方法を使うときの留意点 --- "Virtual hosts and SSL server certificate"セクションを参照。例-4 単一のホスト名を用いて複数のサーバ上に散らばるアプリケーションを公開する。 App1とApp2が以下の2つのサーバ上のそれぞれ/app1/、/app2/というパスに存在している。 https://appserver1/app1/ Application-1 http://appserver2/app2/ Application-2 これらをhttps://mine.example.com/という単一の外部向けプロキシ経由で公開したい。 https://mine.example.com/app1/ --> https://appserver1/app1/ https://mine.example.com/app2/ --> http://appserver2/app2/ --- sproxy.conf --- # 定義するリスンポートは一つだけ # proxy_listen_name = lis-ssl 0.0.0.0@443 https # lis-sslで受け付けたリクエストのうちパスが/app1/で始まるもの全てを # https://appserver1/app1/に転送する。 # lis-sslで受け付けたリクエストのうちパスが/app2/で始まるもの全てを # http://appserver2/app2/に転送する。 # 他の全てのリクエストはエラーとして拒否。 #

proxy_pass_by = url lis-ssl://*/app1/ https://appserver1/app1/ proxy_pass_by = url lis-ssl://*/app2/ http://appserver2/app2/ --- 内部web serverの設定 --- この例のように外部向けパスと内部パスを一致させると他に設定を変える必要がない。しかし外部向けパスと内部パスを一致させられない場合、app server側で相対パスを使うかOrenospのコンテンツ・リライトでHTML内のパスを書き換える必要が出てくる。例-5 Basic認証が必要なバックエンドサーバへ固定の認証情報を送る通常、Basic認証のかかったバックエンドのページにアクセスすると Orenospはバックエンド－クライアント間でBasic認証の情報を単に通過させます。しかしBasic認証のかかったバックエンドに固定的な認証情報を付加してアクセスするように設定することもできます。 proxy_pass_by = lis lis-ssl http://username:password@localhost:10001 Absolute URLs in Contents ========================= Generally if a web application is put behind a reverse proxy, its contents shouldn't have absolute URLs in them. But if you already have such an application, then there are two options: 1) Contents that use $SERVER_NAME and friends to achieve site-name independence -> specify -hh="_self_" 2) Contents that have literal absolute URLs -> specify -rw_url=on (automatic URL rewriting in content) If you have an application that spans multiple web servers and has links to one another, the automatic URL rewriting (-rw_url) won't solve the problem. In this case, you need to manually configure content rewrite rules. (See Content Rewrite) Load-Balancing HTTP/HTTPS Servers ================================= With load-balancing, you can distribute HTTP request processing among multiple equivalently configured backend servers. In the basic reverse proxy mode, destinations of requests are specified as a regular HTTP or HTTPS URLs. To use multiple servers for load-balancing you will instead need to define a load-balancing group (LB group) and specify the defined LB group as the destination in proxy_pass_by rules. proxy_lbgroup_define = lbhost1 http nodes="server1,server2:8890,server3:8888"

... proxy_pass_by = vhost www.example.com lbgrp://lbhost1 -hh="..." nodes= option specifies a list of servers that will share the request processing load. A node should be specified with its hostname and an optional port number. (Note: do not specify http and https default port numbers, 80 and 443). -hh option in proxy_pass_by, if specified, applies to all the nodes in a group equally. Session Binding --------------- By default, once an HTTP session is assigned to a particular LB node, all requests from that session will go to the same LB node. This is accomplished by using an HTTP cookie ("orenosp-lbg-"). Session binding modes supported: cookie insert mode : the only one supported now other modes that may be supported in future: backend cookie mode : uses backend-supplied cookie client IP range mode : uses client IP address Load-Balancing Algorithm ------------------------ Currently Orenosp does a simple round-robin. High Availability ----------------- Orenosp proactively health-check all nodes in LB groups. In every 5 seconds, it "pings" all nodes using ICMP echo requests. If a node fails to respond to this ping request, it is considered Non-Existent (NOEX). For all other nodes that responded to pings, Orenosp sends a HTTP request: GET http-or-https://node-hostname[:port]/ If the node returns a bad status or fails to respond, it is considered Service-Down (DOWN). Otherwise, the node is considered Service-UP (UP). HTTP status codes that are considered bad are 500 (internal server error), 502 (bad gateway), 503 (service unavailable) and 504 (gateway time out). If the node's state is not UP, it is considered as dead and is temporarily evicted from its LB group. When the node's state becomes UP, it is allowed to join back to the LB group. To rephase, Orenosp does two periodic checks: (1) Ping check : all nodes (2) HTTP check : all non-NOEX nodes (DOWN and UP nodes) Apart from the peridic checks, Orenosp also retries to send the client HTTP request to another node if the first request fails. If you want to take a node into maintenance, you can just shutdown its HTTP service, shutdown the OS, or just remove the node from the network. After the maintenance, you can start the HTTP service or plug-in the network again. --- Tunables --- You can configure the HTTP check to be applied only for DOWN nodes. This way, you can avoid periodic HTTP check on UP nodes. You still get a similar level of high availability. proxy_lb_hcheck_downonly = 1 Monitoring ---------- You can configure Orenosp monitoring module and check status of LB groups. See "Monitoring Module" later in this guide. Virtual hosts and SSL server certificate ======================================== 単一のSSL listen port (IPアドレス＋ポート)上で複数の仮想ホストを公開する場合の注意点。 SSL用サーバ証明書に含まれるホスト名が仮想ホスト名と一致しなければブラウザはホスト名が一致しないという警告を発します。それを避けるには以下のどちらかで証明書を作成する必要があります。 1) 複数の仮想ホスト名をサーバ証明書に登録する(subjectAltName)。仮想ホスト1 : myweb1.example.com 仮想ホスト2 : myweb2.example.com 仮想ホスト3 : myadmin.example.com 証明書のsubjectAltName : DNS:myweb1.example.com, DNS:myweb2.example.com, DNS:admin.example.com gencertを使用する場合、"gencert -gen -1"で起動し"Do you want to put multitple DNS names?(y/n)"という質問にYと答えて myweb1.example.com, myweb2.example.com, admin.example.com と入力すればそのような証明書が作成できます。 2) ワイルドカードホスト名を証明書のCNに入力(ワイルドカード証明書) 仮想ホスト1 : www.mycompany.com 仮想ホスト2 : www2.mycompany.com 仮想ホスト3 : admin.mycompany.com 証明書のCN : *.mycompany.com HTTP Compression ================ sproxy.confの以下の行を見つけてコメントをはずします。 #proxy_filter_define = comp-txtonly mod_filt_zlib mtype="text/" #proxy_filter_assign = * comp-txtonly 上記のように設定すると、以下の全ての条件を満たしたレスポンスボディ (コンテンツ)がHTTP圧縮された形でクライアント側に送られます: - HTTPステータスが200 (HTTP_OK) - テキストファイルである(MIMEタイプ名が"text/"で始まる) - クライアント(要求側)がHTTP圧縮レスポンスを受け取れるその他のオプションに関してはOrenosvのユーザーズガイドおよびコンフィグファイルを参照してください。 http://hp.vector.co.jp/authors/VA027031/orenosv/guide_jp.txt http://hp.vector.co.jp/authors/VA027031/orenosv/http_dflt.txt Nimda Filters ============= 標準ポートの80でHTTPをリスンしているとNimda系のアクセスが飛んできます。内部HTTPサーバにこれをフォワードせずOrenospでこれらのリクエストを処理することができます。以下の設定をsproxy.confに入れます。 #--- Nimda filter BEGIN --- # --- set to 1 to enable nimda filters proxy_nimda_enable = 1 # --- nimda rules, specify path pattern --- # up to 128 rules can be specified proxy_nimda_path = /scripts/root.exe* proxy_nimda_path = /MSADC/root.exe* proxy_nimda_path = /msadc/*/winnt/system32/cmd.exe* proxy_nimda_path = /c/winnt/system32/cmd.exe* proxy_nimda_path = /d/winnt/system32/cmd.exe* proxy_nimda_path = /_vti_bin/*/winnt/system32/cmd.exe* proxy_nimda_path = /_mem_bin/*/winnt/system32/cmd.exe* proxy_nimda_path = /scripts/*/winnt/system32/cmd.exe* proxy_nimda_path = /default.ida* proxy_nimda_path = /scripts/Admin.dll #--- END --- 上記のように設定すると、 proxy_nimda_pathにマッチするリクエストはすべて Bad Requestエラーを返すようになります。そして/trash.logにマッチしたURLを書き出します。その他にもこまごまとした動作指定できるパラメータがあります。 sproxy_full.confを参照してください。 Referer Checking (直リン禁止) ============================= Refererフィールドをnimdaフィルターでチェックすることで他のサイトからの自サイト内の画像ファイル等への参照を制限することが可能です。主な利用目的として「直リン禁止」があります。「直リン」(直接リンク)とは、あるウェブページ上に存在する資源(HTMLページや画像)へ著作権を侵害しうる形でリンクすることであるとここでは定義します。インターネット上で問題視されている具体的な例として、画像ファイルへの埋め込みリンクがあります。タグによりブラウザはそのリンク先の画像をダウンロードしあたかもリンクを張っているウェブページの一部であるようにユーザに表示します。これは公正でない引用・無断複製となりえますし、さらにそのサーバの画像提供者側の貴重なネットワーク帯域を消費させてしまいます。 HTML的にはタグによるリンクは通常のリンクでなく埋め込みリンク (embedding link)として分類されています。しかしタグを使った通常リンクもタグを使えば埋め込みリンクと同様の効果が得られます。したがって「直リン」か否かの判断は参照に使われるHTMLのタグの種類ではなく、参照を行うウェブページの作りによって行われるべきものです。注意: ここで定義している直接リンクは一部で主張されている「無断リンク」とは一切関係ありません。 nimdaフィルターの規則で、Referer要件をつけることで直リンを禁止します。 proxy_nimda_path = -ref=

にマッチするリクエストは、Refererフィールドを持ちかつその値が以下とマッチすればアクセスが許可されます。そうでなければリクエストは拒否されます: {http|https}://

つまり自サーバ上にあるにマッチする資源からのリンクでなければ、nimdaリクエストとして扱い拒否します。 ===重要=== このアクセス制限はあくまでもブラウザを使用している一般ユーザに直リンダウンロードを禁止しているだけであり、IPアドレスやパスワードによる厳密なアクセス制限ではありません。特殊なダウンロードソフトを使うと簡単に回避されます。したがって、無制限公開を意図しないデータはかならず必ずこの直リン制限とは別にパスワードなどのアクセス制限を行ってください。 ========== 例-1 /myhome配下の画像ファイルは/myhome/配下のpict*ページからしか参照させない proxy_nimda_path = /myhome/*.jpg -ref=/myhome/pict*.html proxy_nimda_path = /myhome/*.gif -ref=/myhome/pict*.html 例-2 トップページにだけ外部からのリンクを許すという制限方法を実現するにはトップページ以外のファイルを全てをサブディレクトリに格納する必要があります。ウェブページ構造 /index.html 直リン可能 /html/... 直リン禁止 /image/... 直リン禁止 proxy_nimda_path = /html/* -ref=/* proxy_nimda_path = /image/* -ref=/* Request Policing ================ Nimda filterに加えてさらにある種のHTTPリクエストを検査・拒否する設定があります。下記を有効にするにはすべてproxy_nimda_enable=1を設定する必要があります。 proxy_plc_max_post_datasz = POSTやWebDAV等でクライアント側から送られてくるデータのサイズを制限します。 0だと制限しません。リクエストのContent-Sizeをチェックします。 proxy_plc_req_chunked_disable = { 0 | 1 } 1に設定するとPOSTやWebDAV等でクライアント側からchunked encoding形式で送られてくるデータを拒否します。リクエストのTransfer-Encodingにchunkedが含まれているかチェックします。 proxy_plc_max_url_len = 特定サイズ以上のURLをもつリクエストを拒否します。URLは'?'以降のクエリパラメータも含みます。 proxy_plc_max_path_len = 特定サイズ以上のPATHを持つリクエストを拒否します。PATHはURLのうちクエリパラメータを含まない部分です。 proxy_plc_url_8bit_disable = { 0 | 1 } URLに8ビット文字を含むリクエストを拒否します。日本語URLでも正しく URLエンコードされている場合は8ビット文字にはなりません。 proxy_plc_basic_auth_disable = { 0 | 1 | 2 } パスワードを平文で送るHTTP Basic Authenticationを制限します。 0: 制限なし 1: 通信路がSSLでない場合、Basic Authenticationを許しません(リクエスト・レスポンス共に)。 2: 常にBasic Authenticationを許しません(リクエスト・レスポンス共に)。 Access and Performance Logging ============================== - Access Logging See proxy_log_access_XXX parameters in sproxy_full.txt - Performance Logging You can add request's response time access logs by specifying 0004 flag to proxy_log_access_flags. The reponse time is defined as the time in seconds from when the request is received from the client and when the proxy has finished sending the last byte of the content. You can also have another dedicated performance logging for tracking backen response times. proxy_perf_logio = single perf.log Format for performance log files time: time when the front request is received from client hmethod: HTTP verb in backend request url: request URL to backend (enclosed by "") hstatus: HTTP status from backend inbytes: bytes sent to backend (sizeof request body) outbytes: bytes received from backend (size of response body) tm_connect: (2-1) time(msec) to connect tm_sendreq: (3-2) time(msec) to send request including req body tm_waitres: (4-3) time(msec) to wait for response headers tm_recvbody (5-4) time(msec) to receive all response body As of version 0.4.2, inbytes are not yet correctly reflected in the log. - Remote Logging You can direct Orenosp to send log records to a Logging Service running on another PC. This function is applicable to the following logs: proxy_log_access_io, proxy_perf_logio, proxy_nimda_logio, proxy_htrace_logio Syntax of proxy_log_access_io: proxy_log_access_io = remote hostname:port { ssl | tcp } label hostname:port : log service's hostname and TCP port { ssl | tcp } Specify "ssl" to connect over SSL. SSL profile "cldflt" is used for the SSL operations. Specify "tcp" (or its synonym "raw") to connect over TCP. Note that logging communication including username and password will not be encrypted. label : any string that the log service requires -u=username:password : username and password to connect to the log service example proxy_log_access_io = remote host1:13000 ssl /host1/proxy \ -u=logadmin/passwd [Developing a compatible network log service] Please see remote_log_spec.txt. User Authentication =================== 内部サーバへのアクセスを認証・認可する２つの選択があります。ひとつは全てのリクエストを通過させてバックエンドサーバ側で認証・認可を行わせます。もうひとつはリバースプロキシにリクエストを認証・認可させることです。クライアント(フロント)コネクション上のユーザを認証・認可する方法は３つあります。それぞれを組み合わせることも可能です。 Passing Through Authentication to Backend ----------------------------------------- By default Orenosp will relay HTTP basic, HTTP digest and any types of cookie-based authentication/authorization requests from/to backend servers. Windows Integrated Authentication: By default Orenosp will not pass through Microsoft-proprietary HTTP authentication methods. These include MS NTLM authentication and MS Negotiate authentication. When orenosp finds response headers requesting one of these auth methods, it will silently drops that response header. See proxy_auth_disable_XXX parameters in sproxy_full.txt. Set the following parameter to enable these auth methods. proxy_auth_disable_ntlm = 0 proxy_auth_disable_negotiate = 0 Authenticating and Authorizing at Reverse Proxy ----------------------------------------------- 1) HTTPベーシック認証 (HTTP Basic authentication) This is the most simple and easy method. If your backend server also enforces HTTP Basic Authentication, it won't work because each of the reverse proxy (front-end) and the backnd will request a basic authentication. There are three options: - Use a form based authentication at the proxy. - Specify a fixed username and password in backend specifier in proxy_pass_by parameter. (uname:passwd@backend:8888). - Have the proxy to pass username and password received to the backend. The latter only works if your proxy and backend server uses the same authentication database. (You need to set "proxy_auth_pass_to_backend = 1") 2) フォームベース認証 (Form Based authentication) This is probably the most prefered method by users and server admins. フォーム・ベース認証ではカスタマイズ可能なHTMLページを使いユーザ認証が行えます。また'orenosp-authck-XXX'という名のcookieを使用しているのでバックエンドでの HTTP基本認証やフォーム・ベース認証と共存できます。さらに受け付けたユーザ名・パスワードをHTTP基本認証情報としてバックエンドに渡すことも可能です。 (You need to set "proxy_authck_pass_to_backend = 1") 3) SSLクライアント認証 (SSL client authentication) See section "Client Certificate Mapping and Authorization". HTTP Basic Authentication ------------------------- #proxy_auth_url =

[options] proxy_auth_url = lis-ssl://*/* -u="user1:pass1" -rlm="Local Server" proxy_auth_url = lis-ssl2://*/* -u="user2:pass2" -rlm="Note Server" # [optional] pass user credential to backend's basic auth proxy_auth_pass_to_backend = 1 Form Based Authentication ------------------------- - /_formauth というディレクトリを作成 - /padmin/_formauth 内の全てのファイルを/_formauth にコピーする。コマンドプロンプトから以下のコマンドで一発でコピーできます: > cd > xcopy padmin\_formauth _formauth\ sprox.confを編集する - Form Based Authenticationを有効にする proxy_authck_enable = 1 - [optional] # pass user credential to backend's basic auth proxy_authck_pass_to_backend = 1 - authentication type (protection realm)を定義する proxy_authck_define = noone -u="" -rlm="nobody allowed" proxy_authck_define = fmauth1 -u="user1:passwd1,user2:passwd2" \ -rlm="Restricted Area" -u でユーザ名とパスワードのリストを指定します。空のパスワードを指定することで、外部認証サーバを使うことができます。例: -u="user1:,user2:" (パスワードが無い場合でも':'は指定しなければなりません）。 External Authentication Serversを参照。 -rlm ではprotection realmの名前を指定します。省略した場合、authentication typeの名前(例では"fmauth1")が使われます。 -tmo= : idle login timeout in minutes (must be >= 2) default is 30 (minutes). -ckdomain="domain-name" : specifies "domain" name in the ticket cookie. if you have two vhosts, www.example.com and www2.example.com, you could set -ckdomain=".example.com" (notice the leading dot) so that a user could be authenticated just once for all vhosts in *.example.com. - 仮想パスもしくはURL空間を定義したprotection realmにマップします proxy_authck_assign = * fmauth1 もし保護したいURL空間をvhost1だけに限定したい場合は: proxy_authck_assign = *://vhost1.example.com/* fmauth1 注意: デフォルトではどのURL空間もアクセス制限されていません。全てのURL空間のアクセスを制限したい場合は以下のパラメータを他の proxy_authck_assignパラメータよりも＿＿上＿＿に配置してください: # for all others, deny any access proxy_authck_assign = * noone - OPTIONAL: add authorizatin list The protection domain defined by proxy_authck_define is really user authentication domain. For each URL space, you can specify a list of users who should be allowed access. # anyone who are successfully authenticated can access. proxy_authck_assign = *://vhost1.example.com/* fmauth1 # for /private/* space, only user "admin1" and users in "admin" group # will be allowed access. proxy_authck_assign = *://vhost1.example.com/private/* fmauth1 \ -allow="admin1,@admins" User grouping information is stored in /grpdb.txt. 保護したページをアクセスする保護されたページをアクセスした場合、"/_formauth/login.html"ページにリダイレクトされます。リダイレクト時にプロキシはアクセスを試みたページのprotection realmを指定するクッキーを送ってきます。(上記例では"Restricted Area"がrealmとなります)。プロキシはこのrealm名を使ってユーザ認証を行うauthck typeを見つけます。注意: リダイレクトされずに直接"/_formauth/login.html"をアクセスした場合、プロキシにはrealm名が分かりません。そのような場合は、デフォルトとして設定ファイルで最後に定義されたauthck typeを使います。 0.4.1以前ではこのような場合認証は単に失敗していました。この動作変更はユーザがログインページをブックマークする場合により望ましいものです。フォームベース認証ページのカスタマイズフォームベース認証を有効にすることで、"/_formauth/"から始まる仮想パスは： - プロキシによってインターセプトされます - ＿＿一切の認証なしで＿＿アクセス可能になります - $ORENOSP_HOME/_formauthディレクトリのファイルが送られますしたがってこのディレクトリに存在するファイルを認証ページに埋め込むことが可能です。以下はフォームベース認証モジュールによってアクセスされる特殊なファイル群です： /_formauth/validate : ビルトイン・パスワード確認プログラム (not customizable) /_formauth/login.html : ログインページ(HTML) /_formauth/loginerror.html : ログインエラーページ(HTML) /_formauth/loginsuccess.html : ログイン成功ページ(HTML) このディレクトリに他のHTMLファイル、アイコン、javascriptなど如何なるファイルを置くことができます。 External Authentication Servers =============================== フォーム・ベース認証とHTTP基本認証では、ユーザパスワードを確認するための外部認証サーバをサポートしています。user-password-listに空のパスワードを指定することで、これら認証モジュールは指定された認証サーバに問い合わせを送るようになります。空のパスワードは "username:" と指定します。 (':'はつけてください)。また、"_valid_"という特殊ユーザ名を指定することにより、外部認証サーバで認証された全てのユーザを許すこともできます。現在のところサポートしている外部認証サーバのタイプは３つあります: - HTTP/HTTPS 基本認証サーバユーザ名・パスワードと共にHEADリクエストをに送ります。ステータスとして200が帰ってくればユーザは認証されます。実際の動作詳細: まず最初に認証情報なしでHEADリクエストを送り、指定されたサーバが実際にユーザ認証を要求しているのか確認します。そうであれば、つぎに認証情報共に新たなHEADリクエストを送り、ステータス200が返されるかを確認します。その場合だけユーザは認証され他のケース全てでは認証は失敗します。 - ファイルベース認証 Authenticates username and password against "passwd.txt" file which usually resides in . Also, when using this methods, you can authenticate users against the OS's native authentication mechanism (os_acl option). See Users Guide for detail. - PAM認証 (Linux version only) Authenticate username and password using a PAM rule specified by "orenosp". You need to create /etc/pam.d/orenosp, possibly by copying another entry like "login" or "system-auth". HTTP認証サーバを指定するには: - Prepare a web server that requires HTTP basic authentication. Say, "https://authserver1". (You can use either http or https web server) - HTTP Basic認証を要求するWebサーバを用意します。例えば "https://authserver1"です。(http、httpsどちらのWebサーバでも使えます) - for Form Based Authentication proxy_authck_authsrv_url = https://authserver1/ - for HTTP Basic Authentication proxy_auth_authsrv_url = https://authserver1/ ファイルベース認証サーバを指定するには: - for Form Based Authentication proxy_authck_authsrv_file = passwd.txt - for HTTP Basic Authentication proxy_auth_authsrv_file = passwd.txt PAM認証を指定するには: - for Form Based Authentication proxy_authck_authsrv_pam = svcname=orenosp - for HTTP Basic Authentication proxy_auth_authsrv_pam = svcname=orenosp Note when both parameters are present in sproxy.conf, proxy_auth_authsrv_url takes precedence. 注意: HTTP基本認証(proxy_auth_xxx)では保護されたページへのアクセスのたびにユーザパスワードが確認されます。認証サーバへの問合せ回数を減らすためにプロキシは問合せ結果をメモリ内にキャッシュします(positiveおよびnegative両方)。これらキャッシュは3分でタイムアウトします。 Client Certificate Mapping and Authorization ============================================ You can use SSL client certificates for authenticating user certificates, and enforce access contol based on them. First you enable SSL Client Authentication, then you use Client Certificate Mapping for two purposes. 1) Authorize access based on certain certificate attributes. 2) Establish mappings between certificates and usernames which will be used in subsequent authentication/authorization mechanisms (like basic auth and form-based auth). In 1) usage, you can protect a certain URL space by restricting access to those clients who have certficates with certain attributes. Let's say you want to restrict access to clients having certificates with "O=Tange Kentou Club". Then map all clients with Tange Kentou Club to a single username "tange-club", and restrict access to that user. In 2) usage, you don't really protect URL spaces, but just specify certificate to username mapping rules for URL spaces. You also specify other authentication/authorization rules (like basic auth and/or form-based auth), which would require the client to use the mapped username. For example, if a client having a certificate with "CN=Joe Yabuki" is mapped to "jyabuki", the client will be required to use "jyabuki" as username for subsequent basic auth and/or form-based auth. Parameters used (see sproxy_full.txt for complete list of options): proxy_authcert_define = ... proxy_authcert_assign =

Steps - Enable SSL Client Authentication by following "SSL Client Authentication" section. You need to set proxy_ssl_clauth to either "require" or "optional". proxy_ssl_clauth = require or proxy_ssl_clauth = optional If you choose "require" your users will need to present a valid certificate upon connecting your proxy. If they don't, an HTTPS connection will not be established. If you choose "optional" your users will not be required to present a valid certificate but offered a chance to present one upon connecting your proxy. So "option" allows both users with a certificate and without a certificate to connect. Interoperability Note: In very old browsers, using "optional" will ... - Define certificate mapping and authorization rules A) Restrict access to users with "O=Shiraki Corporation, OU=Boxing Gym" --- certmap.txt --- shiraki-boxing Subject O=Shiraki Corporation, OU=Boxing Gym --- end --- --- sproxy.conf --- # allow certificate-mapped users user1 and user2 proxy_authcert_define = shiraki -u="shiraki-boxing" -cmap=certmap.txt proxy_authcert_assign = * shiraki B) Map certificate to a username and require that username in subsequent The key option here is "-set_username=1". --- certmap.txt --- jyabuki Subject CN=Joe Yabuki, O=Tange Kentou Club tange Subject CN=Tange, O=Tange Kentou Club --- end --- # establish mapped username to be required in subquent other auths. # That is, Joe needs to log in as "jyabuki" for subsequent form-based auth, # and Tange needs to log in as "tange" for subsequent form-based auth. proxy_authcert_define = tange -u="_valid_" -set_username=1 -cmap=certmap.txt proxy_authcert_assign = * tange # use mapped username in form-based auth proxy_authck_define = ... -u="jyabuki,tange" Certificate Mapping Rules ------------------------- The default filename used for storing certificate mapping rules is /certmap.txt. You can specify a different file with -cmap= option. Modification to the specified file is monitored by Orenosp and the file is re-read as necessary. You don't have to restart Orenosp to reflect changes. Syntax

: username to mapp to

Subject ,,... Hash_SHA1 If you need other matching method, please request to the auther. DN-Pattern : the following attribute names are recognized: CN : Common Name O : Organization Name OU : Organization Unit Name L : Locality Name C : Country Name E : EmailAddress - the following can be used in subject DN matching only (not for issuer DN) NOT YET IMPLEMENTED altDNSName : subject alternative name - DNS name (hostname) altEmail : subject alternative name - Email address If an attribute value contains a ',', it must be prefixed by '\'. O=Shiraki Corporation\, Inc., OU=Boxing Gym certificate-fingerprint-in-SHA1-in-hex : can accept two forms ':'-separated: 57:E7:BB:5D:20:D3:61:49:B9:F1:5E:18:14:6D:43:84:85:75:88:BB ' '-separated: 57 e7 bb 5d 20 d3 61 49 b9 f1 5e 18 14 6d 43 84 85 75 88 bb IP-based Access Control ======================= IP-based Access Control can be enforced in two ways: - per connection basis (specified in proxy_listen_name) - per request basis (specified by proxy_authip_url) Per-connection access control is more effective because it checks client's IP before establishing an SSL / HTTP connection, thereby thwarting SSL handshake DoS attacks. Per-request access control gives you more flexibility by giving finer control over URL space that a user is allowed to access. Both methods can use either the same access control list or separate ones. That is, you can specify a text-based IP pattern file to both modules. The IP pattern file can be edited while the service is running. Orenosp will detects file modification and reloads patterns from the file. There's no limit on the number of IP patterns in a file. --- a sample IP pattern file --- # you can comment out a line with '#' 123.123.0.0/16 123.234.0.0/16 234.123.123.128 --- end --- Refer to sproxy_full.txt for more details - "ip_allow/ip_deny/ip_order" options in proxy_listen_name - "IP-based Access Authorization" (proxy_authip_url) Bandwidth Control (Throttling) ============================== See sproxy_full.txt for actual parameters. IMPORTANT : current limitations - Only the SEND direction (reverse proxy sending out contents) is currently supported. - BW control works over data that have not been processed by output filters. This means that the amount of data that's subjected to the bandwidth control will differ from the actual amount of data that goes over the wire. For example, if the HTTP compression filter reduces a 1MB content by 90%, the bandwidth control will see it as 1MB of data even though only the 100KB of data is actually sent over the wire. A work around would be to let the backend server to compress the contents and let them through the reverse proxy. Of course, it won't be possible to rewrite contents with this way. Local File Serving for Menu Pages ================================= プロキシ経由で複数のサーバ・サービスを公開している場合、「メニューページ」のようなものが欲しくなります。通常はバックエンドサーバの一つでそのようなメニューページをホストすればよいのですが、それが不可能な場合もあります。 (例えば全てのバックエンドはデバイスのような場合)。そのような状況のために、Orenospは簡単なローカルファイルサーブ機能を持っています。 proxy_lfile_enable = 1 を設定すると、/_intmenu/配下の全てのファイルがURL /_intmenu/XXX でアクセス可能になります。これらファイルへのリクエストは通常の認証・認可の対象になることに注意してください。つまりベーシック認証やフォームベース認証でチェックされます。さらにトップページからメニューページにユーザを導くためにトップURL("/")を "/_intmenu/menu.html"にリダイレクトするように設定しておくとよいでしょう。 # "/" を /_intmenu/menu.html にリダイレクトする ("-s" オプションに注意) proxy_redirect_by = url lis-ssl://host.com/ https://host.com/_intmenu/menu.html -s Processing Order ================ - [On connect only] Per-Connection IP-based Access Control - Request policing (proxy_plc_xxx) - Check for nimda requests - Per-Request IP-based Access Control - Certificate Mapping and Authorization - Redirect if matched with proxy_redirect_by - Simple basic authentication - Form based authentication - Switch to tunneling if SSLVPN - Redirect if matched with proxy_redirect_by (when "-2" is used) - Serve local files if "/_intmenu/xxx" - Serve monitoring request - Reverse-proxy request to backend if matched with proxy_pass_by IPv4 <-> IPv6 ============= IPv6を使うにはIPv6対応別バイナリのOrenospが必要です。(orenospXXXi6.exe) Limitations in the Current Release ---------------------------------- These will be addressed in future release as demand for IPv6 grows. - SSL Portforwarding over IPv6 is not supported Especially, tnapplet (Java) is not IPv6-enabled. Other components may work but not tested yet. - Load-Balancing to IPv6 backend servers is not supported This is because the load-balancing feature requires ping (ICMPv6) functionality but it is not quite implemented yet. IPv4-LAN内のHTTPサーバをIPv6のネットワークに公開する ---------------------------------------------------- # proxy_listen_name = lis-ipv6 ::@80 http #

proxy_pass_by = lis lis-ipv6 127.0.0.1 IPv6-LAN内のHTTPサーバをIPv4のネットワークに公開する ---------------------------------------------------- # proxy_listen_name = lis-ipv4 0.0.0.0@80 http #

proxy_pass_by = lis lis-ipv4 [::1] -hh=127.0.0.1 []という表記は、URLのホスト部にIPv6アドレスを指定する際に使用されるものです。 URL表記 Orenosp http://[fe80::203:2fff:fe02:c640]/ -> [fe80::203:2fff:fe02:c640] http://[fe80::203:2fff:fe02:c640]:81/ -> [fe80::203:2fff:fe02:c640]:81 名前解決 - DNSの設定について ---------------------------- IPv6サーバをIPv4ネットワークに公開する場合 DNSエントリ IPアドレス(A) host1.mycompany.com host2.mycompany.com と設定し、Orenospで仮想ホスト名でリクエストを振り分けます。 IPv4サーバをIPv6ネットワークに公開する場合 DNSエントリ IPアドレス(AAAA) host1.mycompany.com host2.mycompany.com と設定し、Orenospで仮想ホスト名でリクエストを振り分けます。 IPv6,v4どちらからでもリクエストを受け付けたい場合 host1.mycompany.com A host1.mycompany.com AAAA host2.mycompany.com A host2.mycompany.com AAAA また逆引き用にIPv6アドレスのPTRレコードも記述しなければならないが、ここでは省略する。その他 ------ - Note about "localhost" When you install IPv6 stack on Windows XP or Windows 2003, it seems like that the first IP address that the OS returns for "localhost" is IPv6 loop back address (::1), not IPv4 loop back address (127.0.0.1), even though "127.0.0.1 localhost" is in etc/hosts file. You can try "ping localhost" to see which address it's pinging. This will cause many problems including Orenosv. Use 127.0.0.1 instead of "localhost" whenever you have a strange problem. - link-localアドレスをlistenポートとして指定する場合は、 scope-idとしてinterface numberを追加してください # in case of IPv6 link-local address, append interface number # following '%'. proxy_listen_name = lis-ipv6 fe80::203:2fff:fe02:c640%3@8888 http # ^^ interface numberはつきのどちらかのコマンドで取得できます。 >ipv6 if (XP SP0) >netsh ??? (XP SP1 or higher, Win2003) - link-localアドレスをconnectアドレス(URL)として指定する場合は、 interface numberを指定してはいけません。 [fe80::203:2fff:fe02:c640%3]:81 ^^ DON'T DO THIS Proxy-Backend Communication =========================== Passing Client IP Addresses to Backend Servers ---------------------------------------------- Many HTTP reverse proxies including Orenosp will add the following headers to client request: X-Forwarded-For: X-Forwarded-Host: X-Forwarded-Proto: <"http"-or-"https"-of-client-request> If you are using Apache as a backend server, you can use a module called "mod_rpaf" to make the Apache server to 1) accept X-Forwarded-For:'s IP address as real client's IP address, 2) accept X-Forwarded-Host:'s value as real virtual hostname. X-Forwarded-Proto header is introduced in Orenosp 0.7.4c and Orenosp-specific. Adding Arbitrary Request/Response Headers ========================================= リバースプロキシ時に任意のHTTPヘッダをリクエストやレスポンスに付加することができます。proxy_pass_by パラメータの"-rq_hdr"と"-rs_hdr"を使用します。 -rq_hdr : リクエストヘッダを追加クライアント ---> Orenosp ---> バックエンドココ -rs_hdr : レスポンスヘッダを追加クライアント <--- Orenosp <--- バックエンドココ Simple Content Rewrite ====================== If you use any reverse-proxy, you can no longer use "absolute URLs" that point to pages on the same reverse-proxied server. For example, let's say "https://www.mine.com/" is reverse-proxied to "http://internal1/" and if you write an HTML link as

then, users on the Internet try to go to the internal server directly, which fails. You need to rewrite the URL as "https://www.mine.com/doc/abc.html". Orenosp and Orenosv have a mechanism to do this kind of content (response-body) rewriting. mod_filt_rwt (optimized rewrite filter) implements this content rewriting functionality. It has two sub-modules, one is simle text search-and-replace filter, the other is a regular expression-based filter. How to configure content rewrite -------------------------------- - create a config file named /rewrite_simple.conf - add rewrite rules to the config file: ---rewrite_simple.conf--- = this is a comment http://internal1/=https://www.mine.com/ http://internal2/=https://www2.mine.com/ = eof ---end of rewrite_simple.conf--- Note on format of rewrite_simple.conf: - '=' is used as the separater: = - leading '=' (i.e., empty ) designates that line as a comment. - two consective '=' ("==") specifies a literal '='. This applies only to . - add the following line to sproxy.conf: # Content Rewrite - must come after HTTP compression filter in config file proxy_filter_define = rewrite-simple mod_filt_rwt rwtype=simple mtype="text/html" proxy_filter_assign = * rewrite-simple - restart Orenosp and check event.log Different rewrite rules for multiple paths ------------------------------------------ - use "-cf=" submodule-specific parameter to specify an alternate rewrite rule file. Note that "--" designates the begining of submodule-specific parameters. example: proxy_filter_define = rewrite-simple-1 mod_filt_rwt rwtype=simple \ mtype="text/html" -- -cf=rewrite-1.conf proxy_filter_define = rewrite-simple-2 mod_filt_rwt rwtype=simple \ mtype="text/html" -- -cf=rewrite-2.conf proxy_filter_assign = /vpath-1/* ext-rewrite-1 proxy_filter_assign = /vpath-2/* ext-rewrite-2 Trouble shooting ---------------- - Rewrites not working when called from browsers, but they work if I directly call the server with "telnet" command. -> Most likely your backend server is applying HTTP compression to the content. Orenosp doesn't decompress already compressed documents in order to apply filters. Make sure you do not apply HTTP compression to those contents. Since 0.4.3c, you can set "proxy_origin_gzip_disable = 1" to disable backend's HTTP compression. You should let Orenosp handle HTTP compression instead. Note: Orenosp can handle chunked-encoded response from a backend and "de-chunk" it. - If an HTML line are longer than 30KB bytes, the rewrite filter splits it in multiple chunks that are smaller than 30KB and work on each of them. If the string you want to rewrite happens to be in the middle of that split, the rewrite won't work. -> Make sure your HTML lines are less than 30K bytes. - Enabling trace : Setting rewrite trace level to 2 or 3 may help. (event.log will be very messy!) proxy_filter_define = rewrite-regex mod_filt_ext int=rewrite_regex \ mtype="text/html" -- -cf=rewrite-2.conf -trc=2 Regular Expression Based Content Rewrite ======================================== The configuration is basically very similar to that of Simple Content Rewrite. Refer to the above section for more info. - create a config file named /rewrite_regex.conf - add rewrite rules to the config file: --- rewrite_regex.conf --- = Header (]*>)=$1

Header Something

= Footer ()=

Footer Something