As shown in Figure 1 the 16 host Network has a single routing PC running Linux with ISDN Software. This PC handles the ISDN compatible leased line as well as the ethernet of the local hosts. It is the only bastion available for the configuration of proxy services and packet filtering
The PC running SF is a Intel Pentium 75 with 16MB of RAM, 850MB of E-IDE Harddrive a TELES ISDN adapter and a NE2000 ethernet card. The operating system of the routing PC is Linux 1.2.11 with UISDN. The PC also runs the TIS fwtk SMAPd combined with smail as well as the TIS fwtk telnet and rlogin proxies with the authentication server using Bellcore's S-Keys, CERN httpd 3.0 as a proxy server a poorly frequented WWW-Server. and the secure shell demon for encrypted remote access to the machine.
This part of the test was to verify the functionality and robustness of SF in an environment not heavily used and therefore not posing any heavy load or even race conditions on the SF software. It was to show possible limitations of the rule language and the cooperation between SF and other modules taking influence on the IP layer.
As an expansion to the original testsuite the routing PC was updated to an ELF library structure from a.out as well as the configuration of a Mbone mrouted.
Figure 2 shows the original configuration of the class C net enterprisenetwork with a 2 host transfer network for firewall designation. The internet connection is a 64kb digital leased line with an optional 64kb of additional capacity via an ISDN dial-up. The internet connection and the dial on demand features are maintained by a CISCO 2500 series router with constantly updated enterprise software modules. For efficiency reasons this router also acts as a preliminary packet filter screening the traffic for connections to internal hosts and discarding such packets. The firewall bastion host has a fairly complex mechanism of filtering. It implements a packet filter, that only allows connections to the specified ports of hosts available to the outside (such as FTP ad WWW) along with the standard packet filtering this host provides encapsulation detection and virtual refeeding of traffic to a second high performance router interface for rechecking encapsulate packets. IP level proxy services with IP masquerading are also available on the firewall bastion but are rarely used. The package on the firewall bastion also contains a sophisticated counter measure and logging and auditing facility for misuse detection and backtracking.
The SF packetfilter is installed on a separate PC and introduced into the network with another 2 address transfer network before the firewall bastion. The SF packetfilter is configured with the same filtering rules as the standard packet filter of the firewall bastion. The firewall bastion is then reconfigured to log any packet the filter would catch to check the proper filtering on the SF machine.
The PC running SF is an Intel 486-66 with 32MB of RAM and an 850MB SCSI drive. The PC has 2 3COM ethernet adapters and is running Linux 1.2.11 with the SF patches and no other modules. The Linux system installed is very basic. SF and the kernel are compiled on another host and transferred to the SF host from there. The SF host is running nothing but the SF module. None of the network services are available on the host i.e. the inetd is not running neither are any other demons.
This is the first main test for the SF package. SF is employed in a quite heavily used environment with a fairly large network behind the SF filter. This test is to reveal functionality as well as possible extensions to the SF features. Another important aspect of the test is to get a measure of the impact SF has on network performance especially during peek times.
As a small expansion for performance testing the SF filter was put parallel to the original standard packet filter (taking all other functionality off the original packetfilter) and hooked up to a separate 64kb internet connection. The two 64kb lines were fed with exactly the same traffic to get precise performance figures. This test was monitored with a FLU-670BL network monitor with protocol analysis software installed. Due to the fairly high cost of this test it could only be performed for 48 hours, but with traffic being normal with specially created peeks the results reveal usable performance figures.
The first SF installation is in the same network as described in Test 3. The main difference is that the original packet filter is taken off the firewall bastion and replaced by the SF filter. Figure 3 also shows the second installation of the SF filter. Is installed before a CISCO 4000 router that interconnects 2 class C networks. The network behind the router is a more secure network and only very space access from that network to the outside world as well as from the outside to this network is permitted. (Mainly access to one WWW Server). The SF is to replace the filtering rules on the CISCO router as performance proofs to be adequate. This is done due to the advantages SF offers in terms of logging and real-time reconfiguration. Filtering rules will eventually be deleted from the router as SF has shown that its filtering is sufficient.
The primary firewall bastion is a Intel Pentium 90 with 64MB of RAM, a 2 GB SCSI drive and 2 3COM ethernet cards as well as one high speed serial card configured with SLIP (This serial card is connected to the primary internet router and is used to refeed packets that were encapsulated to the router as packets from the outside, this does not touch the SF configuration because SF simply allows any traffic on this special network) The system on the host is Linux 1.2.11 with quite a lot of changes, since the original firewall software is built into the kernel directly for performance reasons (This made it hard to install SF in the first place, because great parts of the Linux TCP code were changed, but with a little restructuring it was possible without too many changes)
The second SF installation on a Intel 486-66 with 32MB of RAM, 850 MB SCSI drive and 2 3COM ethernet cards. This host is running a standard Linux 1.2.11 kernel with the SF patches applied. The system is configured very sparcely only running SF. SF is compiled on another system and transferred to this host on completion.
This test puts SF in a normal firewall context. The primary intent is to check for robustness and performance under normal usage. The proper functionality of the SF package has been verified by Test 2, so this test can be implemented without risks to security. The second SF installation is to check SF for its flexibility and to test SF as a tool for logging and auditing in a normally used network environment.
This test does not offer much space for expansion of the SF configuration. The main changes during the test are changes to the rule sets used for SF configuration.
One major expansion to Test 2 and Test 3 occurred during negotiations with our internet provider. The provider will collect all transfer networks within 6 months, this means that there is no network available between the internet router and the firewall bastion. The result of this new network configuration is that subnetting will probably be used in a "messy" way supported by CISCO routers as multiple subnet definitions. This means that several different netmasks with overlapping subnets can be used for one network. This implies some harsh changes to the SF configurations, the problems are described in the section on desired extensions to SF.
SF has proven to be a very stabilely written piece of software. In the normal testing environment no memory leeks, stall pointers or anything the like could be found within a 51day running period when the router had to be rebooted for some totally different reason. In general one must say that SF seems to be very much exceptional. It was compiled then installed as a module and after that kept being reconfigured with the sfc control program without any problems. It has shown that in a low usage environment there are no problems whatsoever with the SF software concerning robustness.
Performance was not an issue in this test, in this low usage environment however there was a visible performance loss at connect time (which is to be expected the way SF works).
The biggest problem of SF software seems to get it working with ELF. Since there were no memory leaks with standard a.out libraries I do figure that this is a problem with the ELF library code. SF produced interesting memory effects which are not at all reproducible. Especially when trying to execute X Programs on the server running SF (exporting the display to some other host) SF eats up memory. Stepping through the SF code with GDB and trying to monitor the kernel module with debug setting did not show any problem within SF. The bug was not really locatable within the ELF standard libs either. From the results in the first setup however it can be said that this bug is most likely not within SF but within the ELF implementation and so it should disappear in future releases.
Generally speaking SF made a good stand. It even recognized and blocked off some denial of service attacks with its rule implementation. All network traffic was gated through the SF machine. The machine was rebooted twice a day during the first part of the test for security reasons, but as SF proved to be reliable even with more network traffic the machine was rebooted only once a day and later even only once a week. Longer machine runtimes are not really desirable for firewall systems. Our general firewall reboots once a week and does internal confidence checking, log rotation and all the like.
We also downgraded our CISCO Router to an old software release to check for the old CISCO small packet fragment bug, in the original Version of SF these packets were not filtered by SF but were stopped at our firewall bastion. After applying the authors' patch to SF even a flooding of small packets was filtered out at much better performance than our firewall bastion did.
The only thing that was not really filtered perfectly by SF were IGMP streams. There are two users within the organization who sometimes take part in IGMP broadcasts. I had to enable their hosts completely in the SF package and did the "real" filtering on the router only putting IGMP packets through to these hosts. IGMP was obviously not an issue while developing SF, maybe that is a project for the future ? (see also desirable extensions SF).
Other than the IGMP logs our Firewall which was then behind SF did not log ANY hostile packets coming through SF.
Interesting extensions to SF are listed in the section desirable extensions to SF.
This test showed very interesting facts about the SF implementation. As noted before the connect time on normal traffic was slowed down a little. With medium network traffic the overall performance was slowed just a little bit. Incoming and outgoing connections were mostly delayed in the same way. Incoming FTP connections however had a pretty big performance loss (round 2 seconds lag between control and data), that was not observed on outgoing FTP connections. With high network load and many attacks (some of them simulated to test SF against multiple attackers) SF even improved the performance significantly. This may be due to the fact that SF after blocking the initial connection does not even look at anything that comes behind. A very good approach and very efficient for loaded lines or systems that tend to attract the hackers' interest.
The following chart shows the packet-thoughput of the SF host during one day.
The following 3D Images show the packet-thoughput and delay for packets going though the Firewall with and without SF. Showing the time of day, the number of packets and the delay in ns.
The 3D curves in the back showes the delay, the curve on the bottom showes the packet throughput and the 3D curve shows the combined data. The curves are splined to make the oscillation of the packet-throughput disappear.
The parallel test was probably the most interesting test to monitor performance influence of SF compared to a very much OS and kernel based firewall (which I consider high performance). As expected this test showed little lags at connect and refresh times, but no real performance loss in the whole. It actually showed that with peeks and attack-peeks SF has much better performance due to the intelligent algorithm. This algorithm has disadvantages (e.g. it would probably be hard to detect encapsulation or to integrate a sophisticated encapsulation filter right within the algorithm) however for conventional firewalls it is a great approach and as shown here even improves performance. The parallel test showed how little the overall impact on performance was compared to the kernel-based firewall and router-based packet filter. As shown in the graphs the delay introduced into the network flow by the SF package with normal traffic was minimal and internal users never even realized that there was a new security component that could delay traffic.
Moving SF onto the normal firewall bastion was absolutely no problem. SF worked with the greatly modified kernel on the machine (even though some patching had to be done manually, but that was as mentioned previously expected due to the very different IP code). As noted before the machine was rebooted once a week and there were no stability problems during this time. The reboot is done on the firewalls to rotate logs and do cleanup-work while the networks are definitely disconnected. The packet filtering of the kernel-based firewall was disabled and maybe a little performance with normal network traffic was given away for the benefits of SF's rule implementation. The conjunction of the two software packets reveled one race-condition, since SF looked at the outgoing interface (serial link back to the router) as well and blocked off traffic in the first place due to an IP conflict (generated on intent to assure the proper refeeding of the encapsulated packets). SF was however simply by reconfiguring (!!) not by changing the code kept from looking at this IP stream and recognizing the serial link as network interface. The kernel-based firewall, especially the encapsulation filter and refeeding module had to be changed slightly (4 lines of code were manipulated). After these modifications the two packages worked together very well. As was shown in Testsuite 2 SF's functionality was not changed or influenced by the new environment.
The second installation of SF was mainly put up because of the dynamic features of SF. It was shown that strong authentication could be used to open a internal host for connection to the outside world. This was done on the SF host with the auth-server from fwtk from TIS. On authentication from a specific host the SF filter was reconfigured to allow this host to connect to the outside world for a specified period of time. Personally I think that is especially in commercial environments a very desirable feature and maybe the authentication algorithm could be integrated into an SF environment (stated in the section desirable extensions to SF). Besides the dynamic reconfiguration SF was used as sufficient logging tool for the access to another internal WWW. logging all these accesses drew down the performance of the gateway quite a bit. Changing the rules to not logging all accesses but trying to filter out several connections from the same host into one log entry. Oddly enough the rules implementation was not drawing down performance by a lot. Extensions to the logging capacities are also mentioned in the section desirable extensions to SF.
On the outer firewall performance loss (if any) was minor and can be compared to the performance effects found in Testsuite 2. I think however it is worth mentioning that the delays found in Testsuite 2 from each firewall component did not really add up since they were installed on the same host. The imposed delay is not very much more than the one introduced by one of the components on its own.
Performance loss on the second SF installation was a little higher due to the dynamic reconfiguration and probably the rebuffering on reconfiguration. I actually thought SF would reset already established connections on being reconfigured, but in most cases it did not, so the reconfiguration worked well. The original logging setup imposed actually unbearable delays (peek times up to 5 seconds) on accesses (WWW accesses especially). Changing the logging mechanism to a sparcer logging for the same host accessing in parallel connections (which is especially relevant for WWW and Netscape Navigator users) put down these delays to an acceptable level.
As stated in the test descriptions there were not really any expansions to this test. But as mentioned in the further tests and modification section there were problems with using multiply subnetted networks as supported by most routers (and never officially approved by and IETF or other group) This "feature" enables administrators to configure networks with different and maybe overlapping netmasks and subnets. This is interesting when using a transfer network for firewall-router, router-internet or router-provider connections. By taking local addresses and opening up the network topology to the router and/or firewall only this saves the transfer networks, which seems to be desired by almost all providers.
SF is not (yet) designed for such configurations. On using addresses from the same subnet for internal hosts and the external firewall interface the SF software detects address spoofing on ANY packet. This can only be prevented by declaring all internal hosts explicitly in the internalnets statement. Of course putting that many entries into the internalnets list pulls off performance a great deal. This solution is not really practical. This is definitely something that should be changed in future releases, even though (by looking at the SF code and talking to the authors) the changes required are not really minor. Multiply subnetted networks and the like will gain more importance as address space becomes more tight. It is not a good solution, but while waiting for some sort of address space extension a very practical and widely used one. Maybe SF should be adapted to that. (see also the section on desirable extensions to SF).
There are some extensions to SF appearing helpful during the test. Other things mentioned here may sound/be a little futuristic but might give ideas for extensions to SF itself and maybe for new projects creating a streamline and maybe consistent product family of products just as well designed as SF.
Maybe it is advisable to talk to the Linux ELF team to find the critical point where SF looses memory in an ELF configuration. I guess one could also wait for the next or next two ELF library releases and see whether the problem still occurs. As I stated before it does not seem to be an SF problem but rather some sort of the Kernel interface in the ELF libraries or some other (rarely used) function within the ELF libraries.
As ELF is becoming the standard for libraries (which makes a lot of sense) the SF team should take care of the ELF problems.
As stated within the test results of Testsuite 3 the internalnets statement in the SF configuration is not quite flexible enough. First of all the functionality of having the outside interface belong to the same network as the internalnets should be implemented and maybe the internalnets statement should be changed to something like
internalnets {network [mask netmask] [except {network [mask netmask]},};
Talking to the SF authors and browsing through the code revealed that changing the internalnets statement with the described functionality is not implies major changes to the core of SF. I think that these changes are worthwhile and should be implemented in some way. But I do not think that this has an utter priority, it should however be mentioned that the SF team is working of something like that when SF is distributed (commercially or publicly). (quite incorrectly {a} is supposed to identify ONE or more occurrences or a)
I think for normal TCP connections it should be no problem to add "real" IP masquerading to the SF package. What I have in mind is a host inside the firewall does not have access to the internet at all, SF however pretends that this host can do "anything" (allowed) on the net directly by catching connections from this host to the internet and remasquerading them to connections from the firewall to the internet, on incoming packets they would have to be masqueraded in terms of coming directly from the internet (after security checking) and being forwarded through the firewall to the host thinking to hold the connections.
This would in some way hide internal network structures, would give much more control of who can do what on the internet especially when these access and masquerading regulations are also available in the dynamic rules definitions. Furthermore one could implement per-host accounting very easily and make the accounting information available in the rules section as well. (Which is, in my opinion, an interesting factor for dynamic configuration within a commercial environment.
It would be interesting to enable IGMP inside the SF configuration. Maybe a collaboration between mrouted and SF is possible for tunnels (maybe also masqueraded tunnels) of mbone broadcasts. SF might also extend the functionality of mourted greatly by allowing certain groups of users from the inside to join only special multicast-groups or special multicast nets and then take card of configuring mrouted either to get the packets into the internalnet directly or to setup a tunnel for special requests from the inside.
Multicasting will become more and more important and not all that many firewalls support if flexibly enough to really work with it. This might be a chance for SF to fill in another gap in the requirements on the firewall market.
It the long run it would be very desirable to have SF come with rule definition for very common attacks like simple denial of service and as a more complicated one a SATAN attack. These rules could make proper log entries and offer "callback rules" for the local firewall administrator to fill in their personal reactions to certain attacks
SF generating SYSVR4 auditing data and guaranteeing a transfer of this data in a secure manner to an internal auditing host running some audit-evaluation-software (like Haystack Stalker) would improve logging and reporting facilities greatly. So far only the TIS fwtk can offer such an interface. I think on implementing an auditing interface the SF team could get support from Haystack Labs (since they are most interested in building interfaces to their software). Auditing of this standard offers much more information on actual break-in attempts and maybe also break-ins. It would therefor be a very valuable extension to a normal firewall.
A neat extension to the SF package in some way would be to offer a service on the firewall for guaranteed data transfer. This could be file transfer or just message transfer (whereas file transfer is more flexible and therefore more desirable) This system should enable internal users to transfer files to defined points in the net (maybe defined by SF?) in a queued manner, including a retry system. A tool like that has been developed at the university of Stuttgart, Germany (called SAFT, by Ulli Horlacher). SAFT however does not integrate with the firewall or any firewall construction. A SF solution would have to take the following features into account:
· queued system
· retry system
· forwarding system (the firewall does all the transfers, file received by the firewall would however have to get to the user in some way, since most users tend not to have accounts on bastions hosts)
· encryption system (probably an RSA public key encryption would be best suited, and it would also be easy to use by simply using pgp as the means of encrypting and decrypting data, this would also free users of any hassle concerning the management of more and more secret and public keys)
· offer a library, so client programs running on internal nets can be written to request secure and guaranteed data transfer from the program right away)
Writing a package like that is not an easy job; but integrating it with SF would be a unique solution to quite some security and secure-transfer problems. Especially the fact that there would be only one configuration file, which could for both packages include the rule processing and that both packages could integrate their configuration to work together the best they can would make this solution extremely valuable.
There are many things one could think of to collaborate directly with SF on application levels, especially when libraries are made available for client programming on most used platforms. Not all the application level extensions can be discussed in short paper like this an not all may be really interesting to the SF team. It would be interesting to follow up on the thought of extending SF to the application level, and I would like to offer my help in choosing some of the ideas for implementation.
A tool for SF administartion would also be desirable. During the tests I have written some perl hacks as CGI interfaces to create new config files and extend the rules section. I will provide these tools for any sort of SF release, but I will have to make them a little more flexible and not so "hooked" to our internal network structures.
However I think an approach like that does not go far enough. There should be some graphical administration tool (written in JAVA?!?) to enable especially dynamic administration and monitoring of the firewall. Monitoring features would enable a network manager to detect bottle-necks before they actually occur and to monitor certain users activities. As thinking about monitoring not only user monitoring is an interesting factor but also hacker monitoring, so implementing the traceback functionality and so on into the firewall administration tool might be very helpful.