Configuring Apache Webserver to Withstand DoS and Brute Force Attacks on NetWare 6.x
Novell Cool Solutions: Tip
Digg This -
Posted: 20 Apr 2006
Configuring Apache Webserver (all versions) to withstand DoS and Brute force attacks on NetWare 6.x and above platforms.
Follow the script below. I recommend that you reload apache after each and every procedure. This way you will know where it breaks and on what. Most likely you'll be able to make the necessary adjustments in order to complete the procedure.
I have tested this procedure on several Network Operating Systems. First and foremost, depending on what version of Apache you are running on NetWare, Unix, or Windows, not all of these steps will apply. Sometimes certain headings don't exist in the HTTPD.conf file. This is okay. Do as much of the procedure as you can.
In my testing of the above mentioned, Nessus brute force attempts were made as well as SPI Dynamics "WebInspect. Both were fantastic tools that gave it their all agains my configurations. The systems held up with no problem!
Keep in mind that anything can be compromised, and parrying DoS attacks still remains a huge challenge. This procedure should help with all of that.
Harden core NOS. Apply current patches (applicable to your NOS platform and Apache version).
Change the default "DocumentRoot" of htdocs to somewhere else on the volume or a different volume entirely. Doing so will make an attackers fingerprinting techniques more difficult.
Change "DocumentRoot" in HTTPD.conf file to reflect the new location in which Apache will serve up its web pages. Example: DocumentRoot apache2/htdocs to ServerName/Apps/webpages etc...
Change the default ErrorLog location to another volume or Syslog server. This will be done in the HTTPD.conf file under the <VirtualHost> heading. It can be found at the very bottom of the .conf file. Specify the DocumentRoot, ServerName, ErrorLog, and CustomLog. CustomLog is the actual Access log that apache uses. You can name this to anything you want. It's good to remember that in the naming of the log files, don't forget the .log extention. Keep in mind that port 80 is still our default unless your organization specifies otherwise. In which case, make sure that the correct port is specified throughout the .conf file.
<VirtualHost *:80># ServerAdmin firstname.lastname@example.org DocumentRoot /Volxxx/webpages ServerName MyApacheServer.gov ErrorLog /Volxxx/logs/MyError.log CustomLog /Volxxx/logs/MyAccess.log common</VirtualHost>
Change location of the PidFile within the HTTPD.conf. Point the PidFile to the new log files location. The PidFile is the file in which the server records is process identification number when it starts.
Header String limiting. Add the Header String limitation in the HTTPD.conf File by adding the fields below. A good place to add the code is below the "LogLevel warn heading. This code will limit the size of the various HTTP header "Strings" being copied.
This will reduce the chance of a successful buffer overflow:
CoreDumpDirectory /user/local/apache/logs (or where your logs are generated)
Note: If the web page fails to generate after applying this change, it is most likely due to the "LimitRequestFieldSize" string. Increment this by 50 until the page loads without errors.
The below is optional except in Windows environments. It all depends on what and how you are using your webserver.
Create Apache "Administrators" ,"Web Development" and "WebServ" groups (these names are only examples. Choose something more elusive). The administrators account willbe used to own and maintain the web servers configuration documents located in the Apache2/Conf and Bin directories. Administrators will also be maintaining the access and error logs located in the logs directory (which will not be stored in their default location). The Web development group will own and maintain all of the web document root files withinthe htdocs directory such as index.html and the custom error documents created later in these procedures. The WebServ group will be the group that Apache itself is a part of, with the login credential of WebUsr. The permissions to the Apache2 folder should be Read Only. The log files that will be written will be written to a different volume, directory, and/or remote host.
Create Web server service user. Create a user account which Apache will use to authenticate to the system in order to run. Make this user part of the WebServ group which should have been created in the previous step.In Windows "Services", set the Apache2 service to log into the system with a specific account. Choose the Web Service user that you created in the previous step. Create other Apache server users if necessary. Assign to the appropriate groups.
Remark out any UN-NEEDED modules loading out of the HTTPD.conf file. This is similar to the OS security issue of running unnecessary network services such as Telnet and FTP and their default TCP ports. The needed modules will vary on what role the Apache server plays in an organization. You will want to spend some time researching what is absolutely necessary for server operation. The list of modules and what they are used for can be found in: http://YourServerName (or IP)/manual or http://httpd.apache.org/docs/mod/
Alter "ServerAdmin" e-mail address in HTTPD.confChange
Change Get Request timeouts from 300 to 60 in HTTPD.conf
Enable KeepAlive in HTTPD.confEnable
KeepAlive timeout in HTTPD.conf
Maximum KeepAlive Requests 256 in HTTPD.conf
Throttle server instances from 5 to 10 in HTTPD.conf
Change ServerSignature to Off in HTTPD.conf
Remove Apache Banner Information by removing all of the default index.html.xx located in Apache2/htdocs directory. Create a new htdocs directory on a different volume of the server. Create new custom error documents which are stored in the Apache2/htdocs in the new htdocs directory. Title them accordingly. (error 404 in HTML. Document 402 is a simple redirect pointed in the HTTPD.conf file to the 404 document, and 500 is stated in the HTTPD.conf as simply "Cannot find Server").Example: ErrorDocument 500 "Cannot find server.", ErrorDocument 404 /custom404.html. ErrorDocument 402 http://www.yahoo.com The custom error docs. should NOT make any references to what OS platform or Apache version that is running. A good practice is to have the error documents reference an error that another type of web server would generate. A page displaying an error pertaining to a different Webserver application would be a good example of deception. The custom error documents can also be simply blank with maybe a custom error message. This practice will aid in confusing fingerprinting techniques/tools that the attacker will use against HTTP headers.
Set HostNameLookups to ON in HTTPD.conf Depending on how much traffic your site receives, you may want to leave this setting off. This feature is used as a means of tracking suspicious connections. Enabled, Apache will take a little longer to serve up requests. Whileit is good to tell Apache to do a DNS query to verify the hostname of a requestor's IP address for ACL purposes, this information can also be pulled using the "Logresolve" utility in the Apache/bin directory. Logresolve is a program that analyzes log files and resolves IP's to domain names. Using this utility can boost Apache's performance and free up resources.
ServerTokens changed from Full to Prod in HTTPD.conf
Remove all unnecessary default HTML files in Apache's /htdocs directory. The sites actual index.html file and all custom HTML files are all that are needed
Remove all cgi scripts in the cgi-bin directory that are not used. This will prevent the possible exploitation and reconnaissance of CGI programs on the web server
I've used this document to harden Apache 1.3.x and 2.x. If you have the means to use Apache 2.0.55, or 2.5, I highly recommend it! If you're stuck on 1.3.x, it will hold up just fine against many attacks.
During the testing on Apache 1.3.x on NetWare 6.0, I was able to stay portaled in without any hiccups, as well as browsing the homepage that my server serves up.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com