Security Policy Manager Code
Status: Beta
Brought to you by:
jsulliva
Menu
▾
▴
Tree [cfe9bf] master / History
Read Me
README for ISCS version 0.5 - April 20, 2013 Copyright 2006 - 2013 John A. Sullivan III jsullivan@opensourcedevel.com http://iscs.sourceforge.net Thank you for your interest in ISCS. We are thrilled that you have downloaded our product. We do not wish to scare you away but please read the VERY IMPORTANT POINTS to reduce grief for all of us! ********************************************************************** * VERY IMPORTANT POINTS!!!!! * 1) This product may not be for you. If you have a single firewall, this is not the product for you unless it is uses very complex access control and constantly changes. You will be far better off using fwbuilder (http://www.fwbuilder.org) or other similar rule creators. The additional overhead of ISCS becomes worthwhile at somewhere between three and five gateways and, of course, will scale to many, many, many more. 2) This is not a configure && make && make install product. If you are looking for something simple which preserves the power of ISCS, please consider buying a commercial product from one of the companies that have commercialized ISCS technology. PLEASE READ THE INSTALLATION INSTRUCTIONS in the docs/html/en/ directory. 3) If you are an experienced security administrator, your unlearning curve will be steeper than your learning curve. ISCS is not like any other network security configurator. If you attempt to use it like you used fwbuilder, Checkpoint, Cisco, Juniper or any other network security tool, you will be frustrated, infuriated, and generally miserable. Once you adjust to the ISCS paradigm, you will be able to achieve the over 90% reduction in time to configure network security that experienced ISCS users achieve. PLEASE READ THE SHORT INTRODUCTION in the docs/html/en/ directory. * * ************************************************************************ VERY IMPORTANT POINTS for version 0.5 This long overdue release is a huge step forward with important new features (e.g., Endian support, IDS/IPS integration, configurable communication ports - please see the ChangeLog) and an embarrassingly long list of bug fixes. However, we have also pushed it out prematurely because of urgent client needs. There are thus some largely untested changes and partially functioning features along with a long list of know bugs (see below). It is beta code at best and lacks some functionality in areas outside of access control, e.g., VPN, routing and element management. It will generate and distribute access control, NAT rules and IP address bindings for proper ARP responses. It will not configure the VPN; this must be done manually. It will not configure iproute2 other than the address bindings for NAT addresses. We had hoped to complete all access control code before this release but, since a new release is long overdue, did not complete it. The big holes were edit and delete functions for PEPs. These have been almost completed but the consequential actions have not been automated. For example, Accessors are not automatically changed to account for new or deleted addresses and must be changed manually. Resources will not automatically be readdressed and, in fact, will be deleted if their network is deleted or edited and they have no addresses on the remaining networks. Therefore, if one wishes to edit a network, it is best to create a new network, readdress any servers or resources and then delete the old network. DHCP ISSUES Since the packets are directed to the broadcast address, there is no rule to accept them since the broadcast address is not associated with a Resource. Thus, to fully allow the PEP to function as a DHCP Server, one must add a custom rule to the iptables.postboot.custom.local file to allow DHCP packets addressed to the broadcast address. There is no simplified installer in this version so expect a lot of work to get started. You will need to know how to install and configure an IPSec stack and how to set up a database and import data into it. The installation process for the production release will be much, much simpler! There is a users mailing list and an announce mailing list available at http://sourceforge.net/projects/iscs/ but, as the developers know this is a beta release and are busily at work preparing the next release, you are not likely to get a response at this time. Thank you again for your interest in ISCS! KNOWN ISSUES: SERIOUS - multi interfaces on same network create antispoof problem If we create multiple interfaces on the same network and anti-spoof is enabled, we cut off traffic because of conflicting antispoofing rules in the mangle table PREROUTING chain, e.g., one that says if !eth1 and source 172.16.20.0/24 DROP and another that says !eth2 and source 172.16.20.0/24 DROP. We'll need to detect if multiple interfaces are operating on the same network and automatically disable anti-spoof. Cannot create Public PEP Resource override If we try to add a Resource Override to a PEP using a public IP Address on the PEP's public network, we generate an "Address not behind this PEP" error. We should be able to do this especially for UTM devices which may wish to publish different services on different addresses. It may not be possible in the very rare case where a user wishes to bind an address to the public interface which is not on the public network, e.g., the public network is 1.1.1.0/24 and the user wishes to create a Resource Override on that interface of 2.2.2.2. I'm not sure how we would identify the proper interface in that case since the address is a real address and not a NAT address and thus is not assigned an NAT Interface. undetected port map conflicts It is possible to add a Resource Override with a port map (NAT using a PEP public IP address) on a service used by the PEP. That should not be allowed since they will try to use the same public IP address for the same service. Likewise, it is possible to add a Service to a PEP which is already being used by a port mapping Resource Override. Possible failed ARP updates if PEP Pub IF bound to multiple addresses It is possible to generate random ARP update failures if a PEP has the same Public Interface bound to more than one network because SubRangeOptions::dynamicARPChanges() only matches the network on the interface in order to find the subnet mask to use for the address binding. If multiple networks are bound to the same interface with different subnet masks, it could use the wrong mask. Adding PEP Public IF as subnet of another does not redistribute Resource NAT If one creates a new PEP Public IF which is a subnet of another Public network, it may be a better match for existing Resource NATs than the original. How shall we handle that? Deleting PEP Public IF does not remove related Resource NATs If one deletes a PEP Public Interface, any resource NATs which use addresses on that public network remain. We should show a warning message that they will be removed with an option to cancel. If the user elects to continue, they must be removed. PEP Public IF change does not update Resource natif If one changes the interface for a PEP public interface, the natif interface for all Resources using it is not updated. This creates a database inconsistency and causes future ARP changes to fail. NAT Override does not properly update ProxyARP We have Resource overrides which NAT to 192.168.223.202 for aol /tcp and jabber-client /tcp (using jabber-server /tcp as a public service override). We edited an existing server address with all three of the above services on it to NAT to 192.168.223.202-204 but it generated a dynamic ARP update error. The proxyarp script reads: !/bin/sh ip address add 192.168.223.201/24 brd + dev eth1 ip address add 192.168.223.202/24 brd + dev eth1 ip address add 192.168.223.203/24 brd + dev eth1 ip address add 192.168.223.204/24 brd + dev eth1 I do not know why it has 201 and 202 already exists. Delete ProtNet does not put Servers in SuperRange The code for deleting a Protected Network says that orphaned servers which are part of a SuperNet of the deleted subnet will be moved to that SuperNet but that does not happen. We will not fix this bug at this time because the entire idea of deleting a network from a PEP has a different meaning in the next version of ISCS. ProtNet delete produces spurious conflicting db error If one deletes a Protected Network and there is an affected Resource with multiple affected addresses, we generate a spurious simultaneous database edit conflict error and cannot save changes. This is because the first IP address change changes the actualrange in the database but the subsequent changes use the original actualrange value. NetNAT change produces spurious conflicting db error If one changes a NetNAT address and there is an affected Resource with multiple affected addresses, we generate a spurious simultaneous database edit conflict error and cannot save changes. This is because the first IP address change changes the actualrange in the database but the subsequent changes use the original actualrange value. Logic error - Servers on PEPs rather than Nets We have a very serious logic error where we have associated Servers with PEPs rather than with networks. This requires a major rewriting of several parts of the code and major database changes. This has been described in the PEPFunctions document under both Delete Protected Network and The Internal Scenario. Here is an excerpt from Delete Protected Network: For example, let's assume there are three protected networks on a PEP, specifically, 10.1.1.0/26, 10.1.1.0/25 and 10.1.1.0/24. Let's also assume there are three servers at 10.1.1.10, 10.1.1.120, and 10.1.1.254. Let's now assume we choose to delete 10.1.1.0/26 and 10.1.1.0/24. With no culling, we would think we should orphan the 10.1.1.10 and 10.1.1.254 servers. In reality, we will not orphan 10.1.1.10 because it will still find a home within 10.1.1.0/25. Our challenge is to not seek orphans on deleted networks which have a non-deleted SuperNet. This must be distinguished from deleted networks which have a SuperNet which is also being deleted. We have a complication if the SuperNet resides on a different PEP; then we must move the Resources and Accessors to the new PEP. We should prompt the user to confirm they approve of moving them to the new PEP rather than deleting them. We must also address the issue where there are SubNets which are not being deleted. We should do nothing at all to those Resources and Accessors as they remain unchanged in their current SubNet and on the SubNet's PEP. Uh-oh. We have a serious and fundamental logic error. Servers should be associated with networks and not PEPs. We already realized this in our outline for changing ISCS to allow multiple PEPs to connect to the same network but there is a serious implication for this particular logic. In two ways. First, remapping orphaned Resources into SubRanges and SuperRanges may make mathematical sense but it does not necessarily make physical sense even on the same PEP, e.g., the rare configuration with multiple PEPs connected to the same network where one PEP is connected only to 10.1.1.0/26 (to use the above example) and another is connected to all three networks - well there it doesn't make mathematical sense either but the point is that the server may or may not be physically moving to the SuperRange even if it is mathematically possible. We must ask the user. SubRanges are also problematic because we currently allow the creation of Resources with sub-optimal routing, e.g., one can create a 10.1.1.5 Resource on the 10.1.1.0/24 network using the example above even though the best match routing is 10.1.1.0/26. We warn the user but do not prevent it in case there is a legitimate reason such as the above example where not all PEPs attach to all the networks. Since we allow this, it is impossible to know if the 10.1.1.10 server (using the above example) lives on the 10.1.1.0/26, /25, or /24 network as long as Servers are associated with PEPs. As an interim step, we will disallow the creation of suboptimal addresses but this is a serious disability. We will need to re-enable it as soon as we release the version of ISCS which corrects the Server association logic error. Improper conflict resolution unchecking NetNAT When we uncheck NetNAT on a protected network, it does not find all the conflicts and it does not find the correct conflicts among Resources. It is finding Resources which are subranges or superranges of Resources on the protected network and identifying them as conflicts rather than applying Best Match. We should only have a warning if there is a direct conflict or if BestMatch produces a situation where there are no available addresses left on one of the Resources. Changing pub IP Address on unmanaged PEP-no change on protne If we change the public IP address on an unmanaged PEP, the Public IP Address for the protected networks do not change. The QComboBox does not have the new address in it. Changing a PEP public IP doesn't change NAPT for ProtNets Changing the public IP Address of a PEP does not change the NAPT addresses of the protected networks doing NAPT via that interface. Antispoof settings not reflected in PEP dialog I changed a private interface to not do AntiSpoofI nor AntiSpoofA and to drop frags. I committed the changes. I then went to edit the PEP and both AntiSpoof boxes were checked for that interface. Unnecessary pre-existing IP Accessor checks When saving changes to a PEP's network settings, all the unchanged networks are checked for already existing IP Accessors instead of just the new and changed networks. This produces unnecessary popup warnings about the existence of those networks as IP Accessors. Subnet of Supernet on different IF trips address anti-spoof If one creates a network on a PEP which is a subnet on an existing network and it uses a different interface, its packets are improperly blocked by the address anti-spoof rules for the supernet. We found this when setting up and IPSec/L2TP VPN. The existing network was 192.168.15.0/24 on bond0. The L2TP users were assigned addresses out of 192.168.15.192/27 on interface ppp0. The was an existing anti-spoof rule of: DROP all -- !bond0 * 192.168.15.0/24 0.0.0.0/0 The new network appended a rule: DROP all -- !ppp+ * 192.168.15.192/27 0.0.0.0/0 Packets from 192.168.15.192/27 on ppp+ hit the bond0 rule first and were dropped. We could address this either of two ways: 1) We check for supernets and, if there are any, we delete the supernet address anti-spoof rule, create the subnet rule, and then recreate the supernet rule so that it is processed after the subnet. That seems a bit kludgy and could create a problem if there is a legitimate reason for a packet from the subnet to be on the supernet interface. I'm not sure if there is a justifiable such case. 2) We could create a separate chain for address anti-spoof rules, change the rules to RETURN rules rather than DROP and then have a drop all at the end. On first look, this seems to be the better approach. Changing PEP IF must change Resource NATIFs If we change an interface name on a PEP, e.g., from eth1 to bond0, we must also change all the Resource NATIF entries in the database, GUI, and rules. Improper handling of network duplicates for PEPs We do not properly handle the detection of duplicate networks on the same PEP when editing or creating a PEP. However, since we are planning to change the entire way duplicates are handled in order to allow for redundant internal connections, we will wait until that design is in place to fix this bug. IP subnet Accesors defined wrong if LowIP is not subnet base If we define an IP Accessors as a subnet but set the Low IP address as a value other than the subnet base, the subnet mask is overwritten and set to 32 bits making it a single IP Accessor. This is done without warning. The user should be advised, apprised of the possible proper settings, and returned to the current field for corrections. Recreating deleted PEP creates Resource artifacts We deleted a PEP with three direct routes, 192.168.0.15, 192.168.1.15, 192.168.2.15. When we recreated the PEP with the same networks, we saw two strange Network Server objects under the PEP in the Resources QListView for two of the IP addresses, i.e., not the correct network server object syntax which includes the mask length. Reloading the database removed these objects from the QListView. PEP unmanage toggle check catches network server The check to ensure there are no conflicts when due to disabling NetNAT when unmanaging a PEP should allow for subnets on different PEPs, e.g., 10.1.1.0/24 on PEP1 and 10.1.1.0/25 on PEP2. However, the Network Server Objects are being treated as servers (as expected) and thus showing a conflict where there should not be. Unmanaging a PEP does not return NAT fragments If a PEP becomes unmanaged, it no longer can do NAT administered by ISCS. Therefore, all Resources should have their DNATs removed and return their NAT fragments. No check for conflicting Resource on PEP subnet creation It is possible to create a protected network behind one PEP which is a subnet of a protected network behind a different PEP however there is not check for conflicts with existing Resources behind the different PEP. For example, PEP1 may have 10.1.1.0/24 and I create a new protected network behind PEP2 of 10.1.1.0/25 but there was no check to see if there was an existing Server behind PEP1 at 10.1.1.130. Cannot enter duplicate PEP IP even when using NetNAT If one is using NetNAT, it is possible that the PEP's IP address on a directly connected network will be the same as another PEP's IP address but the conflict is resolved via NetNAT. However, the validation on the PEP IP address field does not allow this. It should still flag a warning but should be overridable. We will then need to include a check in finalCheck() to ensure the conflict has been resolved via NetNAT. Delete network w/NetNAT improperly readdreses into Supernet If we delete a protected network with a SuperNet and one or both use unrelated NetNATs, e.g., 10.1.1.0/25 maps to 192.168.1.0/25 and 10.1.1.0/24 maps to 192.168.201.0/24, preserved (as opposed to deleted) Resources are not properly translated to the SuperNet's addresses. We appear to be using offsets incorrectly. For example, we had a 10.1.0.0/24 network not using NetNAT and a 10.1.0.16/29 network with NetNAT and a server at 10.1.0.18. We we deleted the 10.1.0.16/29 network, the server should have been migrated to the 10.1.0.0/24 network as 10.1.0.18 but was instead migrated as 10.1.0.2 - the same offset as it had from the original base network. That is normally how we should handle changing Resources involving NetNAT but not in this corner case. Deleting network with supernet automatically moves servers Right now, if a user deletes a protected network and there exists a non-deleted SuperNet, we automatically move any Resources to the SuperNet. That may not be the user's intent. They may wish to truly wipe out everything on the deleted network. Thus, we should prompt the user for their decision. To fix this problem, we will need to implement the move server routine. Then, if the user does not want to delete them, we can move those with SuperNets to the SuperNet and the rest to the Internet. May not move Accessors when deleting network with supernet If we delete a network from a PEP and there is a supernet of that network on a different PEP, we may not be moving the IP Accessors to be behind the supernet PEP. Deleting NAT'd Resource did not remove natactuals This was a somewhat complicated transaction so I do not know if we have captured all the details. We created a Resource Override for with a public service override. The private service was pcsync-https and the public was https. This conflicted with the existing https on the server so we save the override without the NAT. We then deleted the https service and added the NAT to the resource override. This did not correctly create the iptables rules (it left off the public service - opened as another bug). We deleted the new service and recreated it now able to create the NAT when creating the Resource (since there was no longer an https conflict). We received an error that we could not connect to the natactuals table. We ran the insert manually inside a transaction and were told there was a primary key conflict. Upon investigation, it appears the delete did not remove the entry from natactuals. Missing source NAT port when editing Resource Override We created a resource override with a public service override but it detected a NAT conflict. We created the Resource Override without NAT. I do not recall if we created the public service override even though we had no NAT. We then deleted the conflict and edited the Resource Override to add NAT. The resulting dynamic rule did not include the original port in the DNAT rule. Old Server DNAT address not removed after change We changed the public IP address of a PEP and then changed the DNAT address of a server behind the PEP to reflect that change. This was not port mapping; the server was using a unique IP address. Changes were applied to the PEP but failed with an inconsistent state message. This was not unexpected. However, after reinitializing the server, the new address was added but the old address was not removed from the running state of the SG565. However, the old address was removed from the ProxyARPUp and ProxyARPDown static configuration files.