tutorial-fwbuilder.pdf

Firewall BuilderTutorial

Vadim [email protected]

Firewall Builder: Tutorialby Vadim Kurland

This tutorial provides an overview of the Firewall Builder application. The tutorial uses snap-shots to graphically orient you to a particular step and to introduce you to the concepts used inthe application.

Examples used in this document can be found in the file tutorial_objects.xml1 In order to viewexamples in this file, you need to download it to your computer and then open it in FirewallBuilder. Since this file is in XML format and many web browsers will try to show it, you needto make sure you download it and not just open it in your browser. Use "Shift+Mouse button"or right mouse button or whatever else method your browser provides as a way to save a filepointed at by that link on the page.

Table of Contents1. Introduction .......................................................................................................................7

Concepts ........................................................................................................................7Policies and rules..........................................................................................................7Global Policy versus Interface Policy ........................................................................9Network Address Translation ....................................................................................9Building policy ...........................................................................................................10

Building policy by hand ..................................................................................10Building a policy using Druid ........................................................................11

2. Policy Rules......................................................................................................................13Letting certain protocols through, while blocking everything else ....................13Interchangeable and non-interchangeable objects ................................................13Using groups...............................................................................................................14Blocking IP fragments and other potentially dangerous types of packets ........14Anti-spoofing rules ....................................................................................................16Protecting local host...................................................................................................16Proper blocking of Ident protocol............................................................................17Using negation in policy rules..................................................................................18

3. Network Address Translation Rules...........................................................................21Providing Internet connection for workstations behind the firewall .................21Server behind the firewall using address of the firewall for access....................21Server behind the firewall using virtual address for access.................................22Server behind the firewall with port mapping ......................................................23Redirecting the traffic ................................................................................................24

5

Chapter 1. Introduction

ConceptsFirewall Builder consists of an object-oriented graphic user interface (GUI) and setof policy compilers for a number of firewall platforms. In Firewall Builder, a firewallpolicy is a set of rules, where each rule consists of abstract objects that represent realnetwork objects and services (hosts, routers, firewalls, networks, protocols, and soon). Firewall Builder helps you maintain a database of objects, in addition to enablingyou to edit a policy using simple drag-and-drop operations. The following list showsall supported object types:

Network objects and groups:

Firewall

Host

Network

Group of hosts and networks

Services:

IP (Internet Protocol)

ICMP (Internet Control Message Protocol)

UDP (User Datagram Protocol)

TCP (Transmition Control Protocol)

Custom Service

Group of services

Time interval

A Firewall object describes the firewall itself. The object has a number of basic param-eters that describe its IP address, software platform, and so on. It also provides a wayto describe which network interfaces the firewall has, and the parameters specific tothe chosen software platform.

Policies and rulesA Firewall object has three sets of rules associated with it:

Global Policy rules

Network Address Translation (NAT) rules

Rules, associated with its network interfaces

7


Figure 1-1. Three different rule sets:

Both Global Policy rules and Interface Policy rules include the following commonelements:

Source

Destination

Service

Action

Logging

Comment

Source and Destination correspond to the source and destination addresses in thepacket. Firewall Builder provides different types of objects that can be used in theserule elements; these are: Firewall, Host, Network, and Group. In the end, Firewall, Hostand Network objects specify the address that is going to be used for the target platformcode. A Group object is simply a container that can include any number of Firewall,Host or Network objects.

Service is a generalized way to describe port numbers in case of UDP and TCP pro-tocols, message type and code for ICMP messages, and protocol number and op-tions for other IP protocols. There are different types of objects available for TCP,UDP, ICMP, and generalized IP protocols; each type of service object provides itsown means of setting port numbers and other parameters.

Action can be one of the following:

Accept

Deny

Reject

If a rules action is Accept, then a packet with source and destination addresses andservice matching the rule is let through. If a rules action is Deny, such a packet issilently dropped. If a rules action is Reject, then the packet is dropped and an appro-priate ICMP message is sent back to the sender. For target platforms that support it,there might be an option to send a TCP RST packet back in response for TCP services.

8


In addition, Interface Policy rules have a Direction option that can be one of the fol-lowing:

Inbound

Outbound

Both

Figure 1-2 and Figure 1-3 represent examples of a Global Policy rule and an InterfacePolicy rule

Figure 1-2. Global Policy rule

Figure 1-3. Interface Policy rule

Global Policy versus Interface PolicyGlobal Policy rules apply to packets crossing the firewall, regardless of the inter-face through which they enter or exit. In case of iptables, this is equivalent to theFORWARD chain, although there might be no such direct correspondence in otherfirewall platforms. Even when such correspondence does exist, a high level FirewallBuilder policy rule might need to be converted into multiple rules going into differentgroups or chains in the target platform code because of a number of reasons.

To explain one need for a conversion, consider a situation when Firewall Builder hasto generate code for an iptables firewall and the rule has Any as source. Obviously, ifthe source is Any, then it should cover any object, including the firewall itself. There-fore, a policy compiler that generates code for iptables places a rule into both FOR-WARD and OUTPUT chains. However, both final iptables rules wont have an inter-face specified in them since the original fwbuilder rule was part of the Global Policythat is not associated with any interface. Place most rules in Global Policy and only afew rules into Interface Rules. This simplifies the analysis of the rule set and makes acompilers job easier, so it can use a built-in optimizer to compact the resultant code.

Interface Policy rules are associated with a certain network interface of the firewall.Unlike Global Policy rules, direction can be specified for Interface Policy rules. Thisprovides a mechanism for dealing with situations where knowing both interface anddirection is necessary; for example, setting up anti-spoofing rules. At the same time,there are target platforms that require that all rules are always associated with in-terfaces. In this case, using Global Policy rules might not be practical because writ-ing policy compiler capable of guessing correct interface might be too complex. Oneexample of such platform is the Cisco routers, where access lists (ACL) are alwaysassociated with interfaces.

9


Network Address TranslationNetwork Address Translation (NAT) rules consist of the following elements:

Original Source

Original Destination

Original Service

Translated Source

Translated Destination

Translated Service

Comment

As names of these elements suggest, the first three refer to the source and destina-tion address and service of the packet before translation, while the last three referto those parameters after translation. The Policy compiler is supposed to be smartenough to generate correct NAT code for the target platform and determine parame-ters like chain and type of translation (for example SNAT, DNAT, MASQUERADING,or REDIRECT in case of iptables).

When the policy compiler generates code for the target platform, it first scans NATrules, then Interface Policies, then Global Policy. This determines the order in whichlines of the target code are generated.

Building policyAt this point, you should be ready to start building a firewall policy. This can be doneeither manually or with the help of another Druid.

Building policy by handOnce a firewall object is created, it has an empty Global Policy, NAT, and InterfacePolicies. To create rules, use main menu item Rules. For an example, see Figure 1-4

Figure 1-4. Adding Policy Rules using menu selection Rules

10


Start with adding a rule on top of the policy; then proceed by adding more rules andfilling them with objects. You can simply drag and drop objects from the tree on theleft into appropriate rule fields. Figure 1-5 illustrates this process.

Figure 1-5. Adding objects to the rule using drag and drop

Once a policy is filled, call the pop-up menu by clicking the right mouse button onany rule number. Both main menu Rules and the pop-up menu provide ways to insertrules in the middle of the policy, remove rules, add a rule at the top or bottom of thepolicy, and move rules up and down. You can also move rules up and down simplyby dragging them by the number field in the direction you want them to go.

Building a policy using DruidTo call the Druid, select firewall object in the tree of objects and call menu Rules"Helpme build firewall policy" (see Figure 1-4). The Druid will ask a series of questionsand generate the firewall policy rules. Rules created this way are not different fromthose created by hand; that is, you can always modify them later and change themto fit your needs. Remember that the Druid might add rules to both Global Policyand Interface Policy, depending on your choices as specified in your answers to theDruids questions.

To build a policy manually, or to modify an existing policy, simply drag objects fromthe tree to the policy elements. Use menu Rule to add and remove rules. Move rulesup and down either by using the menu, or by dragging the rule by its number field.

We recommend that you start with the Druid to get few initial rules to see whatthey look like. Then you can modify your policy by hand, by adding more rules orchanging those created by the Druid.

11


12

Chapter 2. Policy Rules

Letting certain protocols through, while blocking everything elseThis is one of the simplest, most basic tasks you may want your firewall to do - blockall the traffic but let certain protocols through. Lets assume we have a network con-sisting just of the firewall "firewall1" and few hosts behind it. We want to let protocolsSMTP and FTP through to the server "hostA" from the Internet, and block everythingelse. All we need to do is put the following rules in the Global Policy:

Figure 2-1. Example of the rule permitting only certain protocols to the server andblock everything else.

Rule #0 allows SMTP and FTP through to the server, while rule #1 blocks and logseverything else. It is worth mentioning that this policy also blocks all the access tofirewall itself, including access to it from internal hosts.

We do not need any additional rules to take care of "reply" packets coming backfrom the server to clients because our underlying firewall software supports statefulinspection and "understands" that such packets should be let through.

Interchangeable and non-interchangeable objectsIn the previous example we put object "hostA" into the Destination field of the policyrule #0 because our goal was to permit protocols SMTP and FTP to that host andnot to any other one. This actually reflects general principle Firewall Builder is basedon: put the object you want to control access for in the Source or Destination fieldof the policy rule. Two different objects with the same address may or may not beinterchangeable, depending on their type and other parameters. One of the frequentmistakes is to create Host object with IP address of the firewall, then use it in thepolicy and expect Firewall Builder to build policy controlling access to the firewall.Unfortunately it does not work that way. If you wish to control access to or from thefirewall machine, then put Firewall object into the policy rule.

Another example of two objects which may on the first glance represent the samething, but in fact are not interchangeable, is IP service object with protocol numberset to 1 and ICMP service object with type and code set to "any". Both objects mightrepresent the same type of service, namely "Any ICMP message". IP protocol 1 is infact ICMP, so one would expect the behaviour of the firewall to be the same regardlessof what type of service object is used. However, target firewall software typically usesspecial syntax for indication of different protocols, so using proper syntax for ICMPprotocol turns certain features on, like for example session state tracking. Using justIP with protocol number 1 will most likely not turn these features on and thereforewill lead to unexpected results.

On the other hand, two objects of the same type with different names but the samevalues of all other parameters are perfectly interchangeable. Although using different

13


objects to describe the same object may be confusing, the final firewall policy will becorrect.

Using groupsSometimes we need to define a lot of very similar rules for multiple hosts or net-works. For example, there may be a need to permit the same service to 10 differenthosts on the network, while still blocking it to all others. The simplest way to accom-plish this is to add 10 rules with the same source and service fields and just differentdestinations. Obviously this can make firewall policy quite cluttered. To avoid thisand make policy readable we can use groups. Group is just a container which in-cludes multiple objects of the same or similar type. Firewall Builder supports groupsof objects and groups of services. One can put "Host", "Network" and "Firewall" ob-jects in the group of objects; service objects can not be put in a such group. Similarlygroup of services can contain "IP Service", "TCP Service", "UDP Service" and "ICMPService" objects and can not contain hosts or networks. Groups can contain othergroups of the same type as well.

To add objects to a group simply drag them from the tree on the left into group viewon the right, or use Copy/Paste functions available via menus.

Once appropriate group has been created, it can be used for policy and NAT rulesjust like any other object.

Blocking IP fragments and other potentially dangerous types ofpackets

Fragmented IP packets, although useful in certain situations, are often used as a toolto probe and penetrate simple packet filters. Particular kind of fragmented packets,namely those with incorrect length specification, are especially bad because they cancause some Operating Systems to crash (for example Windows NT was known tocrash before fix was developed and published by Microsoft). These packets thereforeare considered potentially harmful and should be blocked on the perimeter of yournetwork. Many firewall platforms provide ways to deal with such packets.

In Firewall Builder, we provide a way to set flags or options in the IP service object.Two options deal with fragments: one is called "all fragments" and another "shortfragments". Figure 2-2 shows how does object "ip_fragments" look like with bothoptions turned on. Policy compilers recognize this object and generate correct codefor underlying firewall software platform.

Figure 2-2. IP Service object which represents fragmented packets.

14


Object "ip_fragments" is included in the section "Services/IP" of the standard objectsdatabase coming with Firewall Builder.

Another potentially harmful type of packets is so called "Christmas tree" packet. Thisone is just a TCP packet with all TCP flags turned on at once (SYN, ACK, FIN, RST,PSH). This combination is never used in real communications, so if any packet likethat comes to your network, it should be considered illegal and blocked. Object "tcp-xmas" is included in the section "Services/TCP" of the standard objects database com-ing with Firewall Builder.

Some platforms provide a mechanism to turn on and off stateful inspection on indi-vidual rules. Turning it off on those rules which do not require it may improve perfor-mance of the firewall. Obviously we do not need stateful inspection while analysingfragmented packets as we do not really want any session to be established, so we cansafely use this option on this rule. One example of firewall platform which supportsstateful inspection but provides a way to turn it on and off is iptables. In FirewallBuilder, this can be done in the rule options dialog (which is platform-sensitive andshows different options for different platforms). Figure 2-3 shows rule options dialogfor iptables firewall:

Figure 2-3. Rule options dialog for iptables firewall

Here is an example of the policy rule which is intended to block all fragmented andTCP "Christmas tree" packets. Note an icon in the "Options" column, it indicates thatthis rule has non-default options set.

Figure 2-4. Rule blocking all fragmented packets and TCP "cristmas tree" packets

This rule is part of the Global Policy and therefore applies to all packets crossing thefirewall regardless of their origin. This means that it will block such packets originat-ing in your network, headed out to the Internet. If by some reason you might want

15


to be able to send this kind of packets out, then put this rule in the Interface Policyon your external interface, with Direction "Inbound".

An interactive Druid available via menu item "Rules/Help me build firewall policy"can create a rule to protect against fragmented packets.

Anti-spoofing rulesFirst of all, spoofed packet is one which is coming from the Internet into your net-work, but its source address belongs to one of the address blocks or subnets usedon your network. Under normal circumstances such packet can only originate onyour network, therefore it can not be entering it from the Internet. Basic idea of anti-spoofing protection is to have a firewall rule assigned to the external interface of thefirewall, which examines source address of all packets crossing that interface com-ing from outside. If that address belongs to internal network or firewall itself, packetshould be dropped. Since rule must take into account both interface packet is comingthrough and the direction in which it is coming, it must be put into Interface Policy.This is one of the rare cases when the rule can not be put into Global Policy.

To create anti-spoofing rule in Firewall Builder we need objects for all subnets insidethe firewall perimeter and obviously an object for firewall itself. Objects for internalsubnets can be put in the single group, to make rule compact. Then we create a rule inthe Interface Policy of firewalls external interface and put all these objects, or a groupwhich contains them, and the firewall object in the "source" rule element. "Destina-tion" and "service" must be set to "any" and Direction must be set to "inbound". Figure2-5 shows the anti-spoofing rule.

Figure 2-5. Anti-spoofing rule

Just like in the previous example, it may be advantageous to turn stateful inspectionoff on anti-spoofing rules. Since we want to prevent these packets from entering ournetwork, there is going to be no session opened and we do not want to keep state atall. You can use "Options" element to do it.

An interactive Druid available via menu item "Rules/Help me build firewall policy"can create anti-spoofing rules.

Protecting local hostThis is the kind of policy you would want if you are using firewall software runningon the host itself. Your host may or may not have its IP address assigned via PPPoEor DHCP.

Here is what you do if address is static:

16


create firewall object, enter its IP address

create interface for it in "Interfaces" tab, mark it as "external"

add loopback interface named "lo", address 127.0.0.1/255.0.0.0

call Druid, chose "Firewall protects local host" and then pick rules you want.

See what Druid have created for you. You can edit these and add more rules now.

If address is dynamic:

create firewall object, mark its address as "dynamic"

create interface for it in "Interfaces" tab, mark address as "external" and "dynamic"

add loopback interface named "lo", address 127.0.0.1/255.0.0.0

call Druid, chose "Firewall protects local host" and then pick rules you want.

File tutorial_objects.xml includes firewall object called "firewall_on_the_host" whichillustrates local host protection rules created with the aid of the Druid.

Proper blocking of Ident protocolSuppose we want to block connections to certain ports on the server behind the fire-wall, but want to do it in a "polite" manner, that is send TCP RST packet back so ourserver would look like nothing is listening on that port at all. One of the practical ap-plications of this setup would be blocking Ident connections to the mail relay or mailserver. Sendmail and many other MTAs (Mail Transport Agents) attempt to connectto Ident port (TCP port 113) on the mail relay every time they accept email from thatrelay. Many believe Ident protocol is practically useless and does not really serve asprotection against SPAM or any other useful function. I am not going into discussionregarding usefulness of Ident protocol here as my intent is simply to show how onecan construct a policy rule which will block Ident without causing delay in emaildelivery.

The simplest way to block any protocol is to use "Deny" action in the policy rule.Since "Deny" causes firewall to silently drop the packet, sender never knows whathappened to it and keeps waiting for responce. This means that denying on the fire-wall will lead to a delay in the delivery of each email message. This happens becauseremote mail relay tries to connect to Ident port on our server and, since the firewalldrops the packet and connection can not be established, it will just wait until its time-out expires. To avoid this delay we will set rule Action to "Reject". Normally "Reject"makes firewall to send ICMP "unreachable" message back to sender, thus indicatingthat access to requested port is denied by the firewall. This may be insufficient yetbecause host trying to connect to our Ident port wont understand this type of ICMPmessage and will keep trying. In fact, most OS do not recognize ICMP "administra-tively prohibited" message and do keep trying. To make host on the other side dropits attempts right away we need to send TCP RST packet back instead of ICMP mes-sage. This can be done by adding appropriate rule option (see Figure 2-7) It is alsosafe to turn stateful inspection off on this rule since we do not want connection to beestabslished and therefore do not need to keep track of it.

17


Figure 2-6. Using action "Reject" with rule option

Figure 2-7. Adding rule option to make send TCP RST packet

Using negation in policy rulesSuppose we want to set up a rule to permit access from the host on DMZ net "mail_relay_1"to hosts on the Internet, but do not want to open access from it to machines on ourinternal network represented by the object "internal_net". Since we want it to connectto hosts on the Internet and can not predict their addresses, we have to use "any" as adestination in the policy rule. Unfortunately "any" includes our internal net as well,which is going to open undesired hole in the firewall.

There are two solutions to this problem. First, we can use two rules: first will denyaccess from "mail_relay_1" to "internal_net" and the second will permit access from"mail_relay_1" to "any". Since rules are consulted in the order they are specified in thepolicy, access to internal net will be blocked by the first rule since the packet wouldhit it first. These two rules are represented on Figure 2-8

Figure 2-8. Using two rules to block access from DMZ to internal net and permitaccess to the Internet

Another solution uses negation. We can specify destination in the rule as "not in-ternal_net", thus permitting access to anything but "internal_net". Negation can be

18


enabled and disabled in the pop-up menu which you call by clicking right mousebutton on the corresponding rule field.

Figure 2-9. Using rule with negation to block access from DMZ to internal net andpermit access to the Internet

Negation can be used in NAT rules in a similar way.

19


20

Chapter 3. Network Address Translation Rules

Providing Internet connection for workstations behind the firewallSuppose your internal network is configured using so-called private IP addresses asdefined in RFC 1918. These addresses are:

10.0.0.0 / 255.0.0.0

172.16.0.0 / 255.240.0.0

192.168.0.0 / 255.255.0.0

If your network uses addresses from one of these blocks, and you want to provideInternet access for machines on this net, then you may need Network Address Trans-lation (NAT) configured on the firewall. This particular type of NAT configurationis often called Masquerading. When configured this way, firewall rewrites source IPaddress of each packet sent by internal machines to the Internet replacing private IPaddress with the address of its external interface.

In Firewall Builder this type of the NAT rule is composed as shown on Figure 3-1

Figure 3-1. Masquerading rule (this rule is part of NAT ruleset)

Here, object representing internal network is placed in "Original Source" and fire-walls object is placed in "Translated Source", thus indicating that we want sourceaddress of the packets to be translated. As before, we do not need to worry aboutreply packets because underlying firewall software keeps track of translations donefor all the connections opened through the firewall and rewrites addresses in all replypackets automatically.

The rule on Figure 3-1 provides address translation for all the packets, but to permitconnections to the Internet a special Global Policy rule is needed. This rule simplypermits all connections from internal network to "any" and should be placed some-where close to the end of the policy, for example right on top of "catch all and log"rule.

Figure 3-2. Rule #3 permits connections from internal network to the Internet (thisrule is part of Global Policy)

21


Server behind the firewall using address of the firewall for accessSuppose we have a network using private IP addresses behind the firewall, and aweb server on it. We need to provide access to this server from the Internet in a suchway that connections will be established to the address of the firewall. In this case weneed destination address of packets to be rewritten so packets would reach the serveron internal network. Just like in the previous case we need one NAT rule to providetranslation and one Global Policy rule to permit connecitons. Figure 3-3 shows NATrule we need:

Figure 3-3. NAT rule for the server behind the firewall

Since we wanted to use address of the firewalls external interface to access the server,firewalls object is placed in "Original Destination" part of the rule. Servers objectwas placed in "Translated Destination" part of the rule so that original destinationaddress of the packet will be replaced with servers address.

We also need a Global Policy rule to permit connections to the server. This rule isshown on Figure 3-4

Figure 3-4. rule #1 permits access to the server (This rule is part of Global Policy)

Configuration on Figure 3-3 and Figure 3-4 can be combined with configuration onFigure 3-1 and Figure 3-2 Such combination illustrate a situation when machines onthe local network can go out to the Internet, and at the same time server locatedon internal network can provide service for the Internet users - all using single IPaddress of the firewalls external interface! This configuration can be useful for thosewith cable or DSL connection and single IP address.

Server behind the firewall using virtual address for accessThose who have more than one IP address allocated by their ISP may want to con-figure the firewall in a such way that extra addresses be mapped to different serversinside their network. This can be done using slightly different NAT rule.

First of all, we create additional "Host" object with IP address which we are goingto use for the translation. This object can have any name, but for simplicity I call it"hostA-nat" since it will be used to configure NAT rule for hostA in our example.The rule which provides translation from address "hostA-nat" to "hostA" is shownon Figure 3-6

22


Figure 3-5. Additional object used for "Original Destination" in the NAT rule

Figure 3-6. NAT rule for the server behind the firewall with different address usedfor access

Finally we need a Global Policy rule to permit connections to the server. This rulelooks exactly like that in the previous case - see Figure 3-4

Using different address for translation requires additional set up to be done on thefirewall to ensure packets would reach firewall while headed for that address. Thereare two approaches to this problem:

One way to do it is to basically take care of ARP requests sent by the router in frontof the firewall. This can be done either by setting up static ARP entries on the routeror on the firewall, so the additional address we use for translation will get mappedto the same MAC address of the firewalls external interface. Here are the commandswe would need to run on Linux firewall to map address 222.222.222.33 to the MACaddress of the interface eth1 and add appropriate routing entry pointing to the inter-nal interface eth0:

route add 222.222.222.33 dev eth0arp -Ds 222.222.222.33 eth1 pub

Another way is to use tool /sbin/ip to assign an "alias" ip address to the same inter-face of the firewall:

ip addr add 222.222.222.33 dev eth0 scope link

Tool /sbin/ip is a part of the package iproute.

Firewall Builder provides simple way of doing this. Just check option "Create virtualaddresses for NAT rules" in the "Firewall" tab in Firewall dialog and policy compilerwill include all the neccesary code in the firewall script.

Server behind the firewall with port mappingThis case is similar to two previous ones, except it illustrates how NAT rule can helpchange a port number besides of the address. This can be useful if server behind thefirewall runs on some alternative port, yet we want to make it so that users wouldaccess it using another port when connect to it. For example, one could use it to

23


provide access to the web server running on non-standard port #8080 by setting uptranslation of TCP ports to the standard one #80. This configuration can be combinedwith either one of the two above, that is translation can be done using either firewallsexternal interface address or some different address.

This kind of translation works for both TCP and UDP services.

First of all, additional Service object needs to be created. This object would have itsport number set to that used by the real server. Figure 3-7 illustrates this objectssetup:

Figure 3-7. TCP Service object for port tranlsation rule

Now we can create the rule, it would look just like previous translation rules ex-cept we put appropriate service objects in "Original Service" and "Translated Service"columns. see Figure 3-8

Figure 3-8. NAT rule with port translation

Of course we need Global Policy rule as well to permit connections to our server.Since Policy rules are consulted after NAT, Policy rule should use TCP Service object"tcp-8080" instead of "http". See Figure 3-9

Figure 3-9. Global Policy rule which permits access to the server

Redirecting the trafficthis is a special case of NAT where packets destination address gets changed to thatof the firewall itself. This may be useful if you, for example, run transparent webproxy on the firewall box. The rule goes to NAT ruleset and should have firewall ob-

24


ject in "Translated desination". Redirection rule may be combined with port mapping,so redirected packet will hit firewall on a different port.

In a real policy this rule would have specific port number in "Original Service" to limitits scope to the protocol supported by the proxy server and will also be placed on topof other NAT rules dealing with the same source addresses so it would match first.Figure 3-10 shows redirection rule which bounces all HTTP connections opened byusers on "internal_net" to the Squid proxy server running on the firewall box on port3128. Obviously squid has to be configured properly to work as transparent proxy.

Figure 3-10. Redirect rule

Note that for this setup to work a Global Policy rule is needed to permit HTTP re-quests made by Squid. These requests will originate from the firewall itself.

25


26

Table of ContentsChapter 1. IntroductionConceptsPolicies and rulesGlobal Policy versus Interface PolicyNetwork Address TranslationBuilding policyBuilding policy by handBuilding a policy using Druid

Chapter 2. Policy Rules Letting certain protocols through, while blocking everything elseInterchangeable and non-interchangeable objectsUsing groupsBlocking IP fragments and other potentially dangerous types of packetsAnti-spoofing rulesProtecting local hostProper blocking of Ident protocolUsing negation in policy rules

Chapter 3. Network Address Translation RulesProviding Internet connection for workstations behind the firewallServer behind the firewall using address of the firewall for accessServer behind the firewall using virtual address for accessServer behind the firewall with port mappingRedirecting the traffic

tutorial-fwbuilder.pdf

Documents

Transcript of tutorial-fwbuilder.pdf