|
|
Introduction |
Enter your firewall rules here. You need to enter the following
for each rule:
- Rule Number: This defines where the rule is entered into
the list. For example, to enter a new rule between 100 and 200,
number it "150". The rules will be re-numbered on each iteration
of the firewall, so you can continue entering rules between each
new pair of rules. If you leave this blank then the rule will go
at the end of the rule set.
- Source: Select a source network object (where the packet
is coming from).
- Destination: Select a destination network object (where the
packet is going to).
- Protocol: Select a network protocol, or ALL for all protocols.
- Service: Select a network port, or ALL for all ports. Note that
most ports will also define a protocol, eg: telnet/tcp is for the tcp
protocol.
- Action: This will be ACCEPT or DENY.
- Log: YES to log the packet, NO to not bother logging it.
- Direction: IN for input packets, FWD for forwarded packets,
OUT for output packets (mostly used for VPN servers), or IN/FWD for
packets that can be either input or forwarded.
|
Firewall Basics |
A firewall ruleset is a set of rules that allow or deny packets
based on the following information:
- Where the packet is coming from.
- Where the packet is going to.
- What service (protocol and port) the packet is attempting to access.
The PHP Firewall Generator starts with some pre-defined rules, some
additional default rules, and a set of default policies. To this
starting ruleset, you add your own rules to accept packets that you
do want to allow into your network, and deny packets that you do not
want to allow in to your network.
From the ruleset that you enter, the PHP firewall generator creates a
shell script that, when run, enters the rules in a more low-level
format into the Linux kernel.
|
Input, Forward or Output? |
The choice between creating rules as IN, FWD, IN/FWD, or
OUT rules is as follows:
- If a packet is only to travel as far as the firewall, then the
rule should be an IN rule.
- If a packet can travel either to the firewall or past it, then
it should be an IN/FWD rule.
- A rule should almost never be a FWD rule as it will then be
blocked by the firewall, as it travels IN. FWD rules can sometimes
be set up as subsets of previous IN rules.
- A rule should only be an OUT rule if it relates to packets
actually generated on the firewall. Most firewalls can send out
arbitrary packets with no loss of security (we are usually only
concerned with IN and FWD packets) so most rulesets should have no
OUT rules. VPN servers might need OUT rules, but be careful
with these as they require careful planning.
Note that all of your rules should almost always be IN or IN/FWD rules.
You should really know what you are doing before creating a
FWD or OUT rule.
|
Masquerading |
Some people call it Network Address Translation (NAT), some call
it address hiding, but here it's called Masquerading.
Suppose you have a single connection to the internet, with a single
valid internet IP address (assigned by your ISP). You can give an
entire network access to the internet through the single IP, provided
you have masquerading.
Masquerading works for any network object that you have set the
"Masquerade" option to be "YES". All addresses on this network will
be hidden behind your single IP address.
|
Pre-defined Rules |
The PHP Firewall Generator comes with a standard set of pre-defined
rules. You can edit or delete these if you prefer, but they are
usually fairly safe rules to leave untouched.
The pre-defined rules include:
- Blocking of packets coming in to certain types of services that
are often used by trojan packages, such as NetBus and BackOrifice.
- Allowing all DNS packets, both TCP and UDP types.
- Allowing all DHCP packets, from DHCP clients and servers. These
are not logged (as they will tend to clutter up the logs otherwise).
- Allowing certain types of ICMP packets, because they are required
for other (TCP and UDP) protocols. Some of these packets are logged
(eg: ICMP echo requests) because they are unusual, whereas others
(such as port-unreachable) are not logged because they are part of the
normal TCP/IP data stream.
- Blocking other types of ICMP packets, including source-redirect
packets.
|
Default Rules |
In addition to the pre-defined rules, there are some default rules that
get created along the way:
- A FWD rule is created that masquerades, and allows, all packets
from all masqueraded networks, to the internet.
- A set of FWD rules is created that allows, and does not masquerade,
packets from all masqueraded networks to all other masqueraded networks.
Note that the above rules are not all that is required to get packets
flowing from masqueraded networks to the internet. Because there is no
IN rule to match the FWD rules, you must enter these yourself.
If you do not enter these rules, or prefer not to do so (for security
reasons) then all packets that you have not allowed IN rules for will
be blocked.
|
Rules you will need |
As mentioned above, if you have masqueraded networks, then you need to
enter explicit ACCEPT IN rules for each of those networks, or packets
from those networks will be denied.
|
Example Rules |
Here are some quick example rules that you might like to use. The
rules are specified in the following format:
- Source Destination Protocol Service Action Log Direction
- Allowing all packets from the masqueraded network ETH0_NET to the internet:
- ETH0_NET ALL ALL ALL ACCEPT NO IN
- Allowing only HTTP packets to a web server called WEBSERVER:
- ALL WEBSERVER tcp www ACCEPT NO IN
- Allowing SSH (secure shell) to the ETH1 address of the firewall, and
logging it:
- ALL ETH1 tcp ssh ACCEPT YES IN
- Allowing routing of traffic between the FARM network and the PADDOCK
network, with no logging:
- FARM PADDOCK ALL ALL ACCEPT YES IN/FWD
- PADDOCK FARM ALL ALL ACCEPT YES IN/FWD
|
Return Packets |
The PHP Firewall Generator will automatically create extra low-level
firewall rules for each of the ACCEPT rules that you define. The extra
rules cater for return packets.
For example, if you create a rule that allows a web server to receive
packets in to port www, then another rule is automatically created to allow
the web server to send out packets from port www, so that the web server
can receive requests, and respond to them as well.
|
Ordering of your Rules |
The order in which you create rules is important.
Rules are processed by the system in order, from top to bottom. If
a packet matches the Source, Destination, Protocol, and Port fields
of a rule, then the packet will be processed by that rule (ACCEPT or
DENY, and logged or not logged), and no further rules will be consulted.
For example, consider the following rules:
- ALL ALL ALL ALL DENY YES IN/FWD
- ALL WEBSERVER tcp www ACCEPT YES IN
Note that packets that would perhaps have been allowed to reach the
web server by the second rule will in fact be denied by the first rule
and will never get there.
For this reason, it is usually best to create all of your ACCEPT rules
first, and only after the ACCEPT rules have been created should you
create DENY rules.
It is often simpler not to create any DENY rules at all, and allow the
default policy take care of denying any packets that you have not
specifically put in an ACCEPT rule for.
|
Default Policies |
Input and Forward
The default policy is to deny all packets that you have not specifically
set up an ACCEPT rule for. All packets that are denied by the default
policy will be logged.
Output
The default output policy will vary depending on whether you have output
rules. If you have any output rules (i.e. you want to restrict VPN users
or other users actually attached to the firewall) then the default output
policy is to DENY all packets that you have not specifically entered
ACCEPT rules for. Otherwise, the default policy is to ACCEPT all outgoing
packets.
Note that you don't normally need to worry about output packets, unless
your firewall is also a target for VPN connections, and you need to restrict
what outgoing services VPN users can connect to.
In most other cases you should not enter any OUT rules, and let the default
policy do its job.
|
Tricks and Traps |
There are no functions to renumber, copy, or move a rule in this system.
Some ways around this include:
- To copy a rule: Click on the "Edit" icon, and change the rule number.
For example, to make a copy of rule 3100, edit it, and change the rule
number field in the edit window to 3150. When this is saved it will appear
as a new rule.
- To move or renumber a rule: Copy the rule to the new location, then
delete the old rule.
- To delete a bunch of rules: Click the delete button multiple times.
How lazy can you get?
|