Lab 6 Implementing Web(HTTP) Services
Goal: To implement a Web(HTTP) server with a virtual host and CGI capability.
System Setup: Throughout this lab, the hostnames and domain names that you use will be based upon the IP address of your machine. Any time the lab refers to a name that contains X, you should replace X with your station number (the last segment of your IP address). For example, if your station's IP address is 192.168.0.3, you would replace references to stationX.domainX.com with station3.domain3.com.
Enable packet filtering. Before commencing, ensure that packet filtering is active and that SELinux is in Enforcing mode.
Sequence 1: Server installation and basic configuration
Deliverable: A working Web Services implementation: with virtual hosting, CGI capability, and a proxy server.
Instructions:
1. Inventory your system and install packages as necessary.
Enable the service at system boot.
The httpd package is required. Use chkconfig to enable this service.
a. # yum -y install httpd
b. # chkconfig httpd on
2. Consider and document which access controls are applicable to your service implementation to meet the specified requirements.
Complete the access control matrix to be used as an aid while configuring the service:
| Access Control | Implementation |
| Application | /etc/httpd/conf/httpd.conf and /etc/httpd/conf.d/* |
| PAM | N/A |
| xinetd | N/A |
| tcp_wrappers | N/A |
| SELinux | ensure correct file contexts; no change to booleans |
| Netfilter, IPv6 | disregard IPv6 access for now |
| Netfilter | tcp ports 80 and 443 |
Check which ports are commonly used for your service:
grep http /etc/services
Check whether httpd is linked, or controlled by another utility that is linked with libwrap.so.
ldd $(which httpd) | grep libwrap
strings $(which httpd) | grep hosts
Application Specific Security
Inspect configuration files used by your service to see the default access control options. A recommended file to begin your inspection is the initialization script called at system boot.
Compare these defaults to the stated requirements.
SELinux
Determine that httpd is an SELinux-targeted service by checking the policy file:
semanage fcontext -l | grep http
You can check for SELinux booleans by running:
getsebool -a | grep http
If you're unsure about the purpose of these settings, try following up with man pages:
man -k http | grep selinux
If the above command fails to indicate a man page, but instead displays an error message with the string "updatedb", then you must run makewhatis &. Please retry the man command as listed above.
3. Start httpd using the default configuration.
a. # service httpd start
4. Verify the DocumentRoot directive in /etc/httpd/conf/httpd.conf reads as below:
DocumentRoot /var/www/html
5. Open a web browser and set the URL to http://stationX.example.com.
If your browser is working, you will see the Red Hat Enterprise Linux Test Page. Note that this page is not the actual index.html file, but it used the /var/www/error/noindex.html file because index.html was missing.
6. Create a new directory hierarchy and some new content:
# mkdir -p /var/www/virtual/wwwX.example.com/html
# cd /var/www/virtual/wwwX.example.com/html
# cat > index.html <<EOF
<b>wwwX.example.com</b>
EOF
(This creates a one-line HTML page.)
7. Create a virtual host by adding the following lines to the bottom of the /etc/httpd/conf/httpd.conf file:
NameVirtualHost 192.168.0.X:80
<VirtualHost 192.168.0.X:80>
ServerName wwwX.example.com
ServerAdmin root@stationX.example.com
DocumentRoot /var/www/virtual/wwwX.example.com/html
ErrorLog logs/wwwX.example.com-error_log
CustomLog logs/wwwX.example.com-access_log combined
<Directory /var/www/virtual/wwwX.example.com/html>
Options Indexes Includes
</Directory>
</VirtualHost>
8. Ensure that your DNS system resolves your virtual host domain name.
# dig wwwX.example.com
;; QUESTION SECTION:
;wwwX.example.com
;; ANSWER SECTION:
wwwX.example.com 86400 IN CNAME stationX.example.com.
stationX.example.com 86400 IN A 192.168.0.X
9. Check the syntax of the configuration file and reload httpd.
a. # service httpd configtest
b. If you do not get any errors, run the following to reload httpd :
# service httpd reload
10. In your browser, change the URL to point to the new virtual host:
http://wwwX.example.com
Do you see the content of your customized page?
11. Enable the web port in your firewall for the 192.168.0.0/24 subnet.
a. # iptables -I INPUT 1 -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT
b. # service iptables save
Sequence 2: Using CGI
Deliverable: A web server with a CGI script
Instructions:
1. Add the following line to the <VirtualHost> block defined in the previous Sequence:
ScriptAlias /cgi-bin/ /var/www/virtual/wwwX.example.com/cgi-bin/
2. Create the directory above, then create a file inside it named test.sh, with the following contents:
#!/bin/bash
echo Content-Type: text/html
echo
echo "<pre>"
echo My username is:
whoami
echo
echo My id is:
id
echo
echo My shell settings are:
set
echo
echo My environmental variables are:
env
echo
echo Here are the files in /tmp/:
ls /tmp/*
echo "</pre>"
a. # cd /var/www/virtual/wwwX.example.com/
# mkdir -p cgi-bin
3. Try to execute this CGI script by pointing your web browser to http://wwwX.example.com/cgi-bin/test.sh
Why didn't the script execute? Check the log files in /var/log/httpd/ for information to help you answer why. (Did you remember to restart or reload server?).
4. Fix the problem and ensure that the script executes properly.
a. Make the script read-write-executable for user, and read-executable for group and other:
# chmod 755 test.sh
5. In the test.sh script, the ls /tmp/* command is executed. When you test this and the script otherwise runs correctly, you will note that the ls command fails. Can you figure out why?
If the ls command works, ensure that you are in Enforcing mode
6. Remove the ls /tmp/* command from the test.sh script and confirm that the test.sh script can run without errors after restarting the httpd daemon..
a. Run setenforce to ensure that you are in Enforcing mode.
# setenforce 1
b. In /var/log/audit/audit.log, you should see some SELinux errors as the web server tries to access the files in /tmp/.
c. SELinux prevents the web server from accessing the files in /tmp/. Note the SELinux error messages in the /var/log/audit/audit.log file.
Challenge Sequence 3: Securing access to your web site documents
Deliverable: A password-protected web server
Instructions:
1. Create a file named .htaccess in the wwwX.example.com document root with the following content:
AuthName "restricted stuff"
AuthType Basic
AuthUserFile /etc/httpd/conf/.htpasswd-wwwX
require valid-user
a. Edit /var/www/virtual/wwwX.example.com/html/.htaccess, and add the content above.
2. Create your domain's password file in /etc/httpd/conf/.htpasswd-wwwX. The file must be readable by the group apache. Reload the httpd service.
a. # cd /etc/httpd/conf/
b. # htpasswd -mc .htpasswd-wwwX user_name
c. # chgrp apache .htpasswd-wwwX
d. # chmod 640 .htpasswd-wwwX
e. # service httpd reload
3. Access the http://wwwX.example.com web page. Are you prompted for a user name and password?
It should not work yet.
4. Add the following line to the web server's configuration file httpd.conf, inside of the <Directory> block for the wwwX.example.com virtual host you created earlier:
AllowOverride AuthConfig
5. Try to access the http://wwwX.example.com web page again. Are you prompted for a user name and password now? If so, are you able to gain access to the page with the user name and password you created earlier?
6. Create a new directory for your web site named /virtual/. Copy (not move) the contents of your virtual web site to the new directory.
a. # mkdir -p /virtual
b. # cp -a /var/www/virtual/wwwX.example.com/html /virtual
7. Change the DocumentRoot of the virtual web site to /virtual/. Attempt to access the web page. Did it work? If not, investigate the errors and fix the problem.
a. Change the DocumentRoot of the virtual site in /etc/httpd/conf/httpd.conf to match the following:
DocumentRoot /virtual/html
b. Test and reload the web server
# service httpd configtest
# service httpd reload
c. /var/log/audit/audit.log should contain some SELinux errors regarding an incorrect target context. Set the context on the directory and file:
# chcon -R --reference=/var/www/html /virtual
8. If you found some SELinux errors, did you attempt to use restorecon to change the context? Did it work?
a. restorecon will not fix the problem because this web site is not in a standard directory. You must use chcon to fix this problem.
Sequence 4: Basic Squid(ICP) Implementation
Deliverable: A working Squid(ICP) proxy server.
Instructions:
1. Inventory your system and install packages as necessary.
The squid package is required. Use chkconfig to enable this service.
a. # yum -y install squid
b. # chkconfig squid on
2. Consider and document which access controls are applicable to your service implementation to meet the specified requirements.
Complete the access control matrix to be used as an aid while configuring the service:
| Access Control | Implementation |
| Application | /etc/squid/squid.conf |
| PAM | /etc/pam.d/squid |
| xinetd | N/A |
| tcp_wrappers | N/A |
| SELinux | ensure correct file contexts; no change to booleans |
| Netfilter, IPv6 | disregard IPv6 access for now |
| Netfilter | default tcp port is 3128 |
Check which ports are commonly used for your service:
grep squid /etc/services
Application Specific Security
Inspect configuration files used by your service to see the default access control options. A recommended file to begin your inspection is the initialization script called at system boot.
Compare these defaults to the stated requirements.
SELinux
Determine that squid is an SELinux-targeted service by checking the policy file:
semanage fcontext -l | grep squi
You can check for SELinux booleans by running:
getsebool -a | grep squi
If you're unsure about the purpose of these settings, try following up with man pages:
man -k proxy | grep selinux
If the above command fails to indicate a man page, but instead displays an error message with the string "updatedb", then you must run makewhatis &. Please retry the man command as listed above.
3. Start the squid service, then configure your web browser to use your proxy. Use localhost as the server, with the port set to 3128.
a. # service squid start
b. # chkconfig squid on
c. To set the proxy settings in Firefox, navigate to Edit->Preferences. In the General settings, click on the Connection Settings... button. Click the Manual proxy configuration radio button. Add localhost in the HTTP Proxy: box, and 3128 in the Port: box. Click OK to accept the changes.
4. Try accessing a web page somewhere. If the classroom does not have Internet access, try http://server1.example.com/pub/, which should return the RHN Satellite server page.
5. Now have a neighbor configure his or her web browser to use your proxy. This should not work.
6. Configure the firewall to allow the default proxy port to your neighbor's IP address. Have your neighbor attempt to connect again. This should still not work.
a. # iptables -I INPUT 1 -s 192.168.0.0/24 -p tcp --dport 3128 -j ACCEPT
b. # service iptables save
7. The page that squid returns, and the bottom of /var/log/squid/access.log indicate why.
8. Open /etc/squid/squid.conf in your preferred text browser. As you can see, it is mostly comments and documentation. You will also note that squid is extremely configurable and tunable. For this lab, we will configure a basic setup that will be adequate for many settings.
a. If you don't have a preferred text editor, use gedit:
# gedit /etc/squid/squid.conf
9. Search for the second occurrence of Recommended minimum configuration in the file. This will take you to the default access control lists, or acls. Add an acl for the 192.168.0.0/24 network below the acl CONNECT method CONNECT line.
a. You should add this line:
acl example src 192.168.0.0/24
You can now refer to this network as example elsewhere in the configuration file. src means that the IP specified is the source IP(s) for this acl.
10. Search further down in the file for INSERT YOUR OWN RULE(S) HERE. Add a line above the localhost access rule to allow example. Reload squid. Your neighbor should now be able to access your cache.
a. You should add this line:
http_access allow example
b. # service squid reload
11. Some URLs are best avoided completely. Return to the acl section, and add the some acl lines beneath the line you added earlier to include .yahoo.com and .hotmail.com in an acl named otherguys (use .example.com if you do not have Internet access in your classroom).
a. Add these lines near the location that you added the example acls:
acl otherguys dstdomain .yahoo.com
acl otherguys dstdomain .hotmail.com
b. There are a couple of things to mention here. First, note that the additive property of acls. Both of the domains are added to the acl. Second, note the dstdomain acl type, which specifies that this definition concerns destination domains. Third, note the use of dot notation in specifying the domain name. Make sure to include the leading dot.
12. Add a rule to deny access to these problematic domains.
Restart squid again, then check one or more of the web sites associated with those domains. Unfortunately, you find that access is not denied.
a. Return to where you added the allow rule for example, and below it add the following:
http_access deny otherguys
b. # service squid reload
13. Open the configuration file again, and move the deny rule you added so that it is before the allow rule for example. Order matters, so by having the allow rule for example before the deny rule for the otherguys destinations, access was allowed and the deny rule never took effect. After moving the rule, restart squid once more. This time it should deny access to any site within the prohibited domains.
a. # service squid reload