Previous
Index Next
ISCS version 0.1.1
ISCS is designed to automatically accommodate most firewall needs even for complex, power user environments. However, there may be occasions where customized, manual rules are necessary. ISCS provides a method to add such rules although it is not exposed through the SPM GUI as of this version.
We will first describe the firewall rule loading sequence. Firewall rules are loaded in a series of six or seven files. This allows ISCS to conserve space and processing power by segregating between rules which are shared by all PEPs and those which pertain to only a specific PEP and also allows order dependent rules to be created in their proper sequence while still maintaining the order independence of security policies.
The current version of ISCS only supports Linux PEPs and iptables as a firewall. The file load order and explanations are:
iptables.chains - ISCS makes heavy use of custom chains. This file first loads all the chains required for the rest of the rules.
iptables.boot - This is the failsafe rule set. It closes down all but essential access. Essential access is SSH (or whatever protocol is used for out-of-band management), NTP and DNS. It also handles screening or malicious packets.
iptables.boot.local - This file implements basic security specific to the PEP, e.g., fragment and anti-spoofing rules which are specific to the PEP interfaces and addresses.
iptables.postboot - This is typically the largest rule set and implements the access control rules.
iptables.postboot.local - This implements PEP specific rules, e.g., VPN_ALLOW (to specify the IP addresses for which this PEP is responsible for making a security decision), ACCESS_GROUPS and ACCESS_GROUPS_DENY (funneling IP addresses for which the PEP is responsible into the appropriate chains), NAT and NAPT (dependent upon the PEP's IP addresses).
iptables.postboot.custom.local - Optional file. This file will be executed if it exists. This is where one places manual rules created outside the SPM.
iptables.postboot.last - This file contains the rules which finally allow access, e.g., it allows ESP, IKE, and jumps from the INPUT and FORWARD chains into VPN_ALLOW, ACCESS_GROUPS_DENY and ACCESS_GROUPS.
The location and format of the these rules files depends upon the model.
Generic Linux PEPs store these in /etc/PEP/ as text files in iptables-restore syntax.
CyberGuard SG575, SG580 and all bash shell based devices store these in /etc/config/ as text files in iptables-restore syntax.
CyberGuard SG570 devices store these in /etc/config/ as text files in iptables syntax. Resultant rule loading performance is dramatically slower than in the devices which use iptables-restore syntax.
Custom rules should be placed in a file named iptables.postboot.custom.local in the format and location appropriate for the device. The rules will be executed after iptables.postboot.local and before iptables.postboot.last.
PLEASE BE AWARE OF WHAT THE OTHER RULE SET FILES ARE DOING BEFORE ADDING CUSTOM RULES.
The nat table POSTROUTING and PREROUTING chains contain rules at the very beginning to ensure that NAT rules with specific services are evaluated before NAT rules for only IP addresses. Thus, one will generally insert at position two or greater when inserting rules into these chains.
The INPUT and FORWARD chains contain several jumps at the beginning to screen malicious packets. The INPUT, OUTPUT and FORWARD chains also contain rules toward the beginning to funnel packets into the appropriate access control chains. Be very careful about inserting rules at the beginning of these chains.
Access Group chains and Resource Group chains frequently contain inheritance jump rules at the end of the chain. Be very careful when appending rules to these chains.
As of version 0.0.6.3, ISCS supports manually added proxy rules for iptables on the PEP, e.g., squid, frox. If the clients are configured for proxy use, one can simply treat the proxy port like any other PEP based Resource to which one wants to grant access, i.e., use the SPM the grant access which will produce filter table rules. Transparent proxy is a little more complicated. These rules are usually entered in the nat table and make use of the REDIRECT target.
All PEP nat table packets on both the PREROUTING and POSTROUTING chains are immediately jumped into either the ServiceDNAT or ServiceSNAT user defined chains. These chains immediately jump packets into the ProxyDNAT or ProxySNAT chains. For this reasons, care must be taken to never insert a new rule in the first position in the PREROUTING, POSTROUTING, ServiceDNAT or ServiceSNAT chains. To enable transparent proxy, place the transparent proxy rules into the ProxyDNAT (or ProxySNAT) chains. The proxy must have rights to access the required services on behalf of its clients, e.g., when using a PEP based http proxy such as Squid in transparent mode, the PEP must have access to both resolve DNS and send outbound traffic on http.
Until ISCS integrates directly with proxies, you will lose fine grained control over access when using transparent proxies. Any traffic you send to the proxy will gain the rights granted to the proxy. For example, if you previously restricted outbound http traffic to only Researchers on the internal network but now direct all internal network traffic into the transparent proxy, all internal network users will have the same access to http as the proxy. For this reason, you may wish to not use transparent proxies for internal servers. To do this, use RETURN rules before the REDIRECT rule. For example, consider the case where one is using Squid, the internal PEP interface is eth0 and the 10.1.1.0/24 and 192.168.2.0/24 networks are on the corporate network but not this specific internal network. The iptables.postboot.custom.local file would look something like:
*nat
-A ProxyDNAT -i eth0 -d 10.1.1.0/24 -j RETURN
-A ProxyDNAT -i eth0 -d 192.168.2.0/24 -j RETURN
-A ProxyDNAT -i eth0 -p 6 --dport 80 -j REDIRECT --to-port 3128
COMMIT