Customizing Firewall Rules - Global Permit/Block Rules

Discussion in 'other firewalls' started by CrazyM, Oct 25, 2002.

Thread Status:
Not open for further replies.
  1. CrazyM

    CrazyM Firewall Expert

    Joined:
    Feb 9, 2002
    Posts:
    2,428
    Location:
    BC, Canada
    Again the following are presented as suggestions and food for thought only for those who may now want to get under the hood and tweak their rule sets.


    Global Permit/Block Rules

    These types of rules would be used to either permit or block all traffic to specific IP addresses. They can also be used to permit or block specific communication/protocol types. The term Global implies that these rules would be applied before any others in the rule set and thus would be at the top of the rule set.

    Rule examples here were made with NIS v.4 which permits multiple remote addresses in a rule. Those using firewalls without this ability may have to make individual rules for each remote address where applicable.

    ------------------------------------------------------

    Rule: Permit LAN Traffic
    Rule in use: YES
    Logging: NO
    Protocol: TCP or UDP
    Action: Permit
    Direction: Either
    Application: Any Application
    Local Service: Any Service
    Local Address: Any Address
    Remote Service: Any Service
    Remote Address:
    ............IP: 192.168.1.xxx
    ............IP: 192.168.1.xxx
    ............IP: 192.158.1.xxx

    ***Note: An example of a common global permit rule for LAN traffic. This example shows individual IP's, but could also be for a range of IP's or the subnet, your choice. If you use individual IP's you will also need to allow the broadcast address (ie. 192.168.1.255). While some rule based firewall allow for "Trusted" sites/zones, some prefer to have specific rules for this traffic which would allow the user to monitor/log this traffic if and when desired. Usually no logging is available for addresses accommodated via "Trusted" sites. This rule would allow for all traffic on your LAN (including file sharing) except for ICMP. If you need systems on the LAN to be pingable, you would have to allow for this in your ICMP rules.

    ------------------------------------------------------

    Rule: Block XXX Traffic
    Rule in use: YES
    Logging: YES
    Protocol: TCP or UDP
    Action: Block
    Direction: Either
    Application: Any Application
    Local Service: Any Service
    Local Address: Any Address
    Remote Service: Any Service
    Remote Address:
    ............IP: xxx.xxx.xxx.xxx
    ............IP: xxx.xxx.xxx.xxx
    ............IP: xxx.xxx.xxx.xxx

    ***Note: An example global block rule for traffic to specic sites/remote addresses you may not want your system/users communicating with, usually because of content.. You could also use IP ranges or entire subnets here also. Some firewalls may offer "Restricted" sites/zones, but as noted above these "Restricted" zones may not allow monitoring/logging of this blocked traffic. Depending on how many specific IP's you may want to block, or how you may want to organize/monitor things, you could have multiple global block rules here.

    ------------------------------------------------------

    Rule: Block Inbound CR/Nimda - no log
    Rule in use: YES
    Logging: NO
    Protocol: TCP or UDP
    Action: Block
    Direction: Inbound
    Application: Any Application
    Local Service:
    ...............Port: 80
    Local Address: Any Address
    Remote Service: Any Service
    Remote Address: Any Address

    ***Note: Don't want to see all those Code Red/Nimda scans in your logs. An example of how a global block rule could be used to block a particular unsolicited Inbound communication, but not clutter up your logs with the entries. Unless you have an interest in logging/tracking some of these worms/virus, such as the recent flood of Inbound UDP port 137, you can use the versatility of rule based firewalls to block but not log this traffic.

    ------------------------------------------------------

    Rule: Block Outbound SSDP
    Rule in use: YES
    Logging: NO
    Protocol: UDP
    Action: Block
    Direction: Outbound
    Application: Any Application
    Local Service: Any Service
    Local Address: Any Address
    Remote Service:
    ..................Port: 1900
    Remote Address: Any Address

    ***Note: An example of a rule to block a specific Outbound communication/protocol. In this case SSDP or part of UPNP used by things like MSMessenger. This rule could just as easily block this protocol in both directions if desired and a rule blocking the inbound was not in place elsewhere in the ruleset. (more on block rules later)

    ------------------------------------------------------

    Rule: Block Inbound IGMP
    Rule in use: YES
    Logging: Yes
    Protocol: Other - type 2
    Action: Block
    Direction: Inbound
    Application: Any Application
    Local Service: Any Service
    Local Address: Any Address
    Remote Service: Any service
    Remote Address: Any Address

    ***Note: An example of a rule to block a specific Inbound protocol. In this case IGMP. Some firewalls will allow for rules for protocols other than the usual ICMP, TCP and UDP. If your firewall has this ability and you wish to globally block a particular protocol, this would be the area in the rule set for such a rule(s). NIS/NPF allows for the blocking of IGMP only elsewhere in the interface.

    ------------------------------------------------------

    Another type of rule that could be used at the top of the rule set would be a Monitor/Logging rule if your firewall has the ability for Ignore/Log Only rules. The Ignore action, as it implies, does not impact allowing or blocking, but simply allows a user to monitor and log the specified traffic prior to any other rules. This is handy for fine tuning a rule set and trouble shooting.

    Same final note applies if you decide to venture into your rule set: Pay close attention to your logs to make sure everything is working as expected. They will provide the information required to make any corrections.

    Stay tuned for the next installment...

    CrazyM
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.