This appendix provides answers to frequently asked questions about Oracle HTTP Server (OHS). It includes the following topics:
Section B.9, "Should I Re-register Partner Applications with SSO Server If I Disable or Enable SSL?"
Section B.10, "Why is REDIRECT_ERROR_NOTES not set for "File Not Found" errors?"
Section B.11, "How can I hide information about the Web Server Vendor and Version"
Section B.12, "Can I Start OHS by Using apachectl or Other Command-Line Tool?"
Documentation from the Apache Software Foundation is referenced when applicable.
Note:
Readers using this guide in PDF or hard copy formats will be unable to access third-party documentation, which Oracle provides in HTML format only. To access the third-party documentation referenced in this guide, use the HTML version of this guide and click the hyperlinks.Oracle HTTP Server has a default content handler for dealing with errors. You can use the ErrorDocument directive to override the defaults.
For HTTP, Oracle HTTP Server supports both name-based and IP-based virtual hosts. Name-based virtual hosts are virtual hosts that share a common listening address (IP plus port combination), but route requests based on a match between the Host header sent by the client and the ServerName directive set within the VirtualHost. IP-based virtual hosts are virtual hosts that have distinct listening addresses. IP-based virtual hosts route requests based on the address they were received on.
For HTTPS, only IP-based virtual hosts are possible with Oracle HTTP Server. This is because for name-based virtual hosts, the request must be read and inspected to determine which virtual host is used to process the request. If HTTPS is used, an SSL handshake must be performed before the request can be read. To perform the SSL handshake, a server certificate must be provided. To have a meaningful server certificate, the host name in the certificate must match the host name the client requested, which implies a unique server certificate per virtual host. However, because the server cannot know which virtual host to route the request to until it has read the request, and it can't properly read the request unless it knows which server certificate to provide, there is no way to make name-based virtual hosting work with HTTPS.
Yes, you can use multiviews, a general name given to the Apache HTTP Server's ability to provide language and character-specific document variants in response to a request.
See Also:
Multiviews option in the Apache HTTP Server documentation on Content Negotiation, at:http://httpd.apache.org/docs/current/content-negotiation.html
No, you cannot apply the Apache HTTP Server security patches to Oracle HTTP Server for the following reasons:
Oracle tests and appropriately modifies security patches before releasing them to Oracle HTTP Server users.
In many cases, the Apache HTTP Server alerts, such as OpenSSL alerts, may not be applicable because Oracle has removed those components from the stack.
The latest security related fixes to Oracle HTTP Server are performed through the Oracle Critical Patch Update (CPU). For more details, refer to Oracle's Critical Patch Updates and Security Alerts Web page.
Note:
After applying a CPU, the Apache HTTP Server-based version may stay the same, but the vulnerability will be fixed. There are third-party security detection tools that can check the version, but do not check the vulnerability itself.No, you cannot upgrade only the Apache HTTP Server version inside Oracle HTTP Server. Oracle provides a newer version of Apache HTTP Server that Oracle HTTP Server is based on, which is part of either a patch update or the next major or minor release of Oracle Fusion Middleware.
In general, Oracle recommends using mod_deflate, which is included with Oracle HTTP Server. For more information pertaining to mod_deflate, see http://httpd.apache.org/docs/current/mod/mod_deflate.html
The general idea is that all servers in a distributed website should use a single URL namespace. Every server serves some part of that namespace, and is able to redirect or proxy requests for URLs that it does not serve to a server that is closer to that URL. For example, your namespaces could be the following:
/app1/login.html /app1/catalog.html /app1/dologin.jsp /app2/orderForm.html /apps/placeOrder.jsp
You could initially map these name spaces to two Web servers by putting app1 on server1 and app2 on server2. The configuration for server1 might look like the following:
Redirect permanent /app2 http://server2/app2 Alias /app1 /myApps/application1 <Directory /myApps/application1> ... </Directory>
The configuration for Server2 is complementary.
If you decide to partition the namespace by content type (HTML on server1, and JSP on server2), then you can change server configuration and move files around, but you do not have to make changes to the application itself. The resulting configuration of server1 might look like the following:
RedirectMatch permanent (.*) \.jsp$ http://server2/$1.jsp AliasMatch ^/app(.*) \.html$ /myPages/application$1.html <DirectoryMatch "^/myPages/application\d"> ... </DirectoryMatch>
The amount of actual redirection can be minimized by configuring a hardware load balancer like F5 system BIG-IP to send requests to server1 or server2 based on the URL.
There are many attacks by hackers, and new attacks are invented everyday. The following are some general guidelines for securing your site. You can never be completely secure, but you can avoid being an easy target.
Use a commercial firewall, such as Checkpoint FW-1 or Cisco PIX between your ISP and your Web server. Remember not all hackers are outside your organization.
Use switched Ethernet to limit the amount of traffic a compromised server can detect. Use additional firewalls between Web server machines and highly sensitive internal servers running the database and enterprise applications.
Remove unnecessary network services such as RPC, Finger, and telnet from your server.
Carefully validate all input from Web forms. Be especially wary of long input strings and input that contains non-printable characters, HTML tags, or javascript tags.
Encrypt or randomize the contents of cookies that contain sensitive information to prevent a hacker from hijacking a valid session. For example, it should be difficult to guess a valid sessionID.
Check often for security patches for all your system and application software, and install them as soon as possible. Be sure these patches come from reliable sources. Only download patches from trusted sites and verify the cryptographic checksum.
Use an intrusion detection package to monitor for defaced Web pages, viruses, and presence of rootkits that indicate hackers have broken into your site. If possible, mount system executables and Web content on read-only file systems.
Have a forensic analysis package on hand to capture evidence of a break in as soon as detected. This aids in prosecution of the hackers.
Perform Pen testing or other relevant security testing on your application. Configure the appropriate custom mod_security rules to protect your application. For more information on mod_security, see Appendix F, "Configuring mod_security."
If you want to use the open source Open Web Application Security Project (OWASP)-based core rule set, then you must ensure that the rule set corresponds to the version of mod_security included with Oracle HTTP Server. Note that the core rule set provides only a general set of rules and is not very application-specific. Thus, the core rule set might not adequately protect your application. For more information on the OWASP core rule set, see the following URL:
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
Remove unneeded content from the httpd.conf file. For more information, see Section 4.6.7, "Removing Access to Unneeded Content."
Yes, if you enable or disable SSL, you have to re-register partner applications with the SSO server. When you make any changes that affect the URL (for example, changing the host name or port, or enabling or disabling SSL), you have to re-register partner applications with the SSO server because the old URL registered with the SSO server is no longer valid. You have to re-register the partner applications with the new URL.
The REDIRECT_ERROR_NOTES CGI environment variable is not set for "File Not Found" errors in Oracle HTTP Server because compatibility with Apache HTTP Server does not make that information available to CGI and other applications for this condition.
Specify ServerSignature Off to remove this information from web server generated responses. Specify ServerTokens Custom some-server-string to disguise the web server software when Oracle HTTP Server generates the web Server response header. (When a backend server generates the response, the server response header may come from the backend server depending on the proxy mechanism.)
Note:
ServerTokens Custom some-server-string is a replacement for the ServerHeader Off setting in Oracle HTTP Server 10g.Oracle HTTP Server 12.1.2 process management is handled by Node Manager. The startComponent command can be used to start Oracle HTTP Server without using WLST or Fusion Middleware Control directly. For more information, see Section 4.3.2.3, "Starting Oracle HTTP Server Instances from the Command Line".