Before giving guidance on how to construct the rules for creating a firewall, one would want to make sure that the firewall itself is fully understood. A few things to discuss is that the firewall, “by default denies everything, even if there are no rules” and one must “create rules that ALLOW communication through the Firewall, versus denying traffic (Checkpoint, N.d.)”. There will many more rules created in blocking intrusion versus allowing traffic flow in to the organization. A few areas to be discussed: “Rule number, Source (IP address), Destination (IP address), Service (TCP/IP), Action and Track” (McCubbrey, S. 2014).
A few things to point out about the rules are all the headers with the firewall rule builder. “Rule number or sequence number” is very important to understand. This rule is just like it sounds as flow will come in and out in sequential order. A few rules of to take note with sequential order is the flow of how the process will work. An example of how this works would be using this email flow; “Gmail additional categories include Sends Mail, Transmits Personal or Enterprise Information, and Instant Chat. If rule 3 allows Gmail and rule 4 blocks applications with the Instant Chat additional category, Gmail will be allowed based on rule 3 (Managing, N.d.)”. It literally will go in order, and the order is very important when creating rules within the firewall.
Source is the “where the traffic originates from” (Managing, N.d.). To explain this term to be more clear the source is usually set to “any” but with setting up a rule for filtering traffic, the source must be set up appropriately. A few things to keep in mind for “anti-spoofing” would be to set the source to “firewall and net 192.168.1.0” (Firewallbuilding, N.d.). “It denies all packets coming through the outside interface with source address claiming to be that of the firewall itself or internal network it protects. This rule utilizes interface and direction matching in addition to the source address (FirewallBuilder, N.d.)”. The same rule will also be applied with destination.
Destination is basically “choosing the destination for the traffic. The default is the Internet, which includes all traffic with the destination of DMZ or external (Managing, N.d.)”. When working with IP addresses, a quick tip is that you can also “exclude” specific IP address, if they are known offenders. An example of this is “the rule matches any destination address except addresses within the private address space” (FirewallBuilder, N.d.). The rule would be specified by adding a specific IP Address in that field.
“Services by default, HTTPS traffic on port 443 and HTTP and HTTPS proxy on port 8080 is inspected. You can include more services and ports in the inspection by adding them to the services list (Managing, N.d.)”. An example of specific traffic coming in that would list a “SSH” service would be allowed by specifically creating a rule just for that field. “A connection from the internal network 192.168.1.0 to the firewall itself using ssh (Services) is allowed. The "Catch all" rule (to be created) will deny all packets that have not been matched by any rule above it. The access policy constructed to allow only specific services and deny everything else, is a good practice (FirewallBuilder, N.d.)”.
Action is how you want to handle that specific rule created. You will create specific rules and if the case actually happens, the action field will “accept or drop” then you can actually “track” the traffic, based on what is created (Managing, N.d.). An example from above was created on whether to accept or drop the action item. Based on created a specific rule and then the “catch all” rule (denying all packets) if not matched, the action field will deny (action). (FirewallBuilder, N.d.).
Tracking is rule specific as well. This field can define “if the traffic is logged or if it triggers other notifications” (Managing, N.d.). For traffic, “this option is useful to get general information on your network. It consolidates logs by session. It shows the initial URL browsed and the number of suppressed logs it includes (Managing, N.d.)”. A rule of thumb, “a good security solution has many layers or components, commonly referred to as 'Defense in Depth'. Regardless of which types of security solutions are being implemented, logging is critical to ensure their implementation is running smoothly as well to keep tabs on what is happening in an environment (Willard, N.d.)”.