A real-world network might consist of a gateway router connecting
our network to some ISP (the public
network),
public web and email servers (and perhaps other servers too)
that would support various services including POP and SMTP
email, DNS, HTTP, SSL, etc.
The public servers would be in a DMZ
network.
(Such servers are also referred to as bastion hosts.)
A private intranet might provide web, database, and other
servers, as well as workstations on a private inner network (the
trusted
network).
The DMZ, trusted, and public networks would all be
separated with a firewall product of some sort.
Since we don't really have that many hosts per student, nor do we have sufficient time for a sophisticated setup, we will simplify the real-world scenario as follows:
You have just been hired and it falls to you to implement the company's security policy, as described below. While you are browsing through catalogs and drooling over the expensive firewall products you see, your boss, a non-technical manager (who is always boasting of her self-taught technical skills) proudly give the following security policy for you to implement.
Your server connects to the Internet through
its eth0 NIC, which has the IP address of
218.100.50.25/24.
Your server also connects to the trusted inner network through
eth1, using the IP address of
10.0.0.1/8.
Network 10.0.0.0 will be called TRUSTED-NET
and 218.100.50.0 will be called PUBLIC-NET.
Your server supports the public HTTP (web) and
POP and SMTP (email) services.
In effect your multi-homed host becomes the bastion host or
DMZ
.
Your server must also support the private SMTP
and DNS services for hosts on TRUSTED-NET.
There will be no intranet
web server used in this example,
nor any proxy servers.
Users on TRUSTED-NET would like to block ads from
popping up.
While using a proxy such as JunkBuster
does this very well, you will
do it here by egress filtering:
blocking your hosts from requesting ads from various sites.
(The JavaScript in a web page causes your host to request popup
and other ads.)
In addition your server must perform routing (IP
forwarding), masquerade the inner network, and
log all telnet and ftp attempts.
The following policies must be correctly enforced by an iptables
packet filtering firewall on your server.
(In this table PUBLIC-NET denotes any IP
address except for TRUSTED-NET, not just the
IPS's network):
| FROM | TO | PERMITTED SERVICES |
MASQUERADE | LOG ACCESS ATTEMPTS |
|---|---|---|---|---|
| localhost | localhost | Any | No | No |
| PUBLIC-NET | TRUSTED-NET | None | No | No |
| PUBLIC-NET | 218.100.50.25 | HTTP POP3 |
No | No |
| 218.100.50.25 | PUBLIC-NET | HTTP POP3 |
No | No |
| TRUSTED-NET | PUBLIC-NET | Any | Yes | No |
| TRUSTED-NET | 10.0.0.1 | HTTP DNS POP3 SMTP |
No | No |
| 10.0.0.1 | TRUSTED-NET | HTTP DNS POP3 SMTP |
No | No |
| Any | Any | FTP telnet | No | Yes |
| TRUSTED-NET | 199.95.207.0/24 | None | — | no |
All other access not listed in the table above should be denied. Note that the table doesn't show the port numbers involved, but you should be able to work them out.
After some study of this policy you wisely refrain from laughing
at your boss, or
pointing out the dangers of using a single host for a router,
firewall, and bastion host providing POP, DNS,
and HTTP services.
This is not a good idea in real-life!
Normally one or more hosts within TRUSTED-NET
are used as bastion hosts, or a third NIC is added to the router
(or two routers are used) to connect to DMZ-NET.
You don't point this out because buying new hardware would change the budget and thus embarrass your boss to her boss. But some policies are contradictory and some are illogical. Policies can be changed without embarrassing your boss so if you approach her right you can fix this.
What changes to this policy will you suggest to your boss? (Be prepared to discuss your changes in class.) Keep in mind the necessity of keeping your boss happy with you.
After finalizing the policy, implement this firewall using
iptables rules.
Save a copy of the working firewall. Then you can work on your hosts to experiment and to test out the firewall rules. When done, save your rules in a file to submit.
You should test your firewall by having a classmate attempt to access your server. (You may wish to change the default web page with one clearly identifying your server.) Test the permitted access, the blocked access, and the logged access. Examine your log files to verify correct firewall operation.
You cannot test some parts of your firewall, such as the email or the gateway (masquerading) parts, but test all you can.
The file /etc/services lists the port numbers used for all
supported services, and the file /etc/protocols lists the
protocol numbers used for all supported protocols such as
TCP.
In the iptables command line you can use either the number
or the name.
A sample iptables firewall for a web server can be found in the resources.
Include a high-level description of the firewall scenario, including
what type of traffic (and in which directions) you will permit,
and a listing of all iptables rules.
This can be in the form of a shell script with iptables
commands and comments, or as a table similar to the one above.
A printout of all modified or new files on your server as a result of your firewall setup.
You can send as email to (preferred). If email is a problem for some reason, you may turn in a hard-copy. In this case the pages should be readable, dated, and stapled together. Your name should appear on the first page.
Please see your syllabus for more information about submitting projects.
Since this is a very difficult project with very limited time (and insufficient instruction!), it is not expected that anyone will actually complete a correct, fully functional firewall. Your grade will depend only on implementing the localhost and web (HTTP) policies listed in the table. Only attempt the other policies if you want to, and if time permits.
(Try to avoid finding a firewall configuration on the Internet and adopting it, you will learn more by writing your own from scratch!)