|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
The firewall we've set up so far is quite strict, it won't allow any traffic in at all. Often, there are times when we need to make exceptions to the firewall policy we set up early. To accomplish this, we use the /etc/shorewall/rules file.
Firewall:~# nano -w /etc/shorewall/rules
Say we have an internal web server that we want the world to be able to access. Well right off the bat we have two problems: First, the firewall policy denies any traffic initiated by the internet. Second, our internal web server has an internal address that's not associated with our global (outside) IP address. We can overcome both these problems by making a DNAT (dynamic NAT) rule in shorewall. For this example, lets assume our web server's internal address is 192.168.1.100.
DNAT net loc:192.168.1.100 tcp 80
Let's break this down: We're telling the firewall to use DNAT, which will dynamically redirect a request to our external address to one of our internal machines. net says this applies to traffic coming from our "net" zone. loc:192.168.1.100 tells the firewall to send this traffic to a specific machine in our local zone, 192.168.1.100. Then we have to specify the protocol (tcp,udp,etc), and the destination port number (80 for http, etc). You can set any protocol and port number supported by the kernel. Now, when the firewall receives traffic to its external interface with a destination port of 80, it will automatically translate the traffic and send it to our internal web server. Pretty cool.
Next, let's say we have a server running on the firewall machine itself, for example SSH. Rather than deny or redirect connections, we want the firewall to pass the traffic to one of it's own servers. For this we use the ACCEPT option:
ACCEPT net fw tcp 22
This example will tell the firewall to accept any connections coming from the internet (net) zone to itself on port 22 (SSH). In other words, you can connect to an SSH server on your firewall with this rule.
Warning: Be careful when authorizing any inbound traffic! Rules such as this can be useful, but they can also be very dangerous. Any time you leave open services on the internet, you're making yourself vulnerable to attack. If a malicious person can connect to your ssh server at all, then there's a chance they can also get full access to your machine. Only use such options if you're well aware of the potential consequences!
Another popular option would be to allow people to ping your firewall, which is disabled by our default policy. To do this, allow the firewall to accept ICMP protocol traffic from the net zone:
ACCEPT net fw icmp
There are many potential applications for rules, even in basic usage. If you're a P2P user, look up what ports your favorite P2P app uses for incoming traffic, and create a DNAT rule to your local machine. This will allow you to get full connectivity to the P2P network without the hassles of the software knowing you're behind a firewall.
By default, whenever the firewall drops unauthorized traffic it is logged. To view the logs, run less /var/log/syslog. If you have traffic that is constantly bombarding your firewall and filling up your logs, you can use the rules to silently drop the traffic without logging it. Just create a DROP entry:
DROP net fw udp 1026:1029
This will cause the firewall to drop any incoming traffic to the firewall on udp ports 1026-1029 without logging it. You can set any protocol and port numbers you wish.
Once you've finished setting up all your rules, don't forget to save the file, run shorewall check, and restart shorewall to apply the new configuration.
Finally, as always, read all of the options in the rules file. It's a very powerful tool, and you should study how to configure it properly.
|
|
|
|
|
|
Proceed to Step 7 - DNS |
|
|
|
|
|
|
|
|
|
|
| Copyright © 2006 Matt LaPlante. All rights reserved. |
|
Page created in 0.0019 seconds.
|
|