Below is a list of questions with answers that should give you better insight into how the Eagle helps to protect your network.
The security policy for your network is defined in the authorization rule database. This database resides on a separate machine that can be physically secured, preventing unauthorized changes. The rules are read by the Eagle on the gateway machine through a read-only, private connection, unreachable from anywhere in the network. Only those who have physical access to the authorization machine can modify the authorization rule database. No one can remotely modify your rule database-not even you, unless you have left some security hole open, such as an inappropriate /.rhosts file.
Each packet must be specifically authorized by the Eagle as defined by your security policy before it is forwarded to your internal network or from your internal network to the outside. In the unlikely event Eagle terminates, all traffic through the gateway ceases. This results in loss of service rather than compromising security.
Eagle counters the possible threat of modification of its code by detecting any code changes and immediately terminating. Again, this would cause loss of service through your gateway, preventing security breaches.
Yes. Your system's network adapter card (Token Ring or FDDI) must support the IP protocols to run the Eagle software.
Forcing all transmissions to pass through the Eagle might appear to pose a performance problem. In practice, however, the performance is bounded by the network connection between your inside and outside network. To provide the highest possible security all network traffic is approved or denied by the Eagle but only adds a few milliseconds to each operation through the gateway. Network traffic on your inside network is unaffected. Only traffic to outside services is considered by the Eagle.
An out of the box 25MHz sparc processor can pass ethernet based TCP/IP packets at approximately 250KB/sec. With a high speed line interface T1 speeds can be closely approached. Faster machines can, of course, pass data more quickly.
Since all operating systems have known and unknown security weaknesses, a person logged into the machine might discover and exploit these weaknesses. Eagle allows root login only. Any non-rooted program is terminated automatically by the Vulture program.
The biggest problem with TCP/IP is that you must assume that the information in an incoming packet header is valid. This may not be the case; a host may assume the IP address of another machine. Eagle cannot directly detect this spoofing, except on your local network with Etherguard. Other features of the Eagle however, such as the Dynamic Activity Monitor tend to minimize most outside attacks. Opportunities for spoofing are further reduced by restricting sites by service (i.e. ftp only) or to a particular time of day (i.e. restrict sites to day-time access only since many attacks occur at night).
Eagle gives additional protection by preventing outside machines from spoofing an address from an internal machine on your network. Even routers, which are sometimes used to protect networks, cannot provide for this type of attack. For more information on network security matters, see the publications listed in the preface.
No. No one can access the Eagle remotely, not even Raptor Systems. Eagle was designed to allow access from the console of the gateway machine only.
Many of our customers are in a similar situation. Eagle hides the internal structure of your network, including its IP addresses. All outgoing IP packets are rewritten at our gateway to replace the internal network information with that of the Gateway, with the result that to the outside world, it appears that all communications with your network come to/from the Eagle gateway alone. The only NIC-issued IP address that you need is for the G box.
This, too, is a common need. The Eagle works in this situation as well, using the same packet-rewrite mechanism.
In both of these cases, customers can take advantage of DNS even though the IP addresses of their internal hosts are never made available to the Internet at large. We recommend a two-level DNS arrangement for our customers, using what are known as internal root nameservers (also called false root nameservers) to preserve internal network confidentiality or deal with the problem of duplicate IP addresses. This setup allows internal hosts to be able to resolve Internet hostnames/addresses within the Eagle-secured nework, but prevents resolution of internal hostnames by outside hosts, effectively dealing with both of these issues. DNS information about your internal network is not broadcast to the outside world and, since all packets are rewritten at the gateway, the outside system knows only that it is communicating with the Eagle gateway instead of internal systems. Re-writing outgoing e-mail headers (as described below) completes the picture of keeping information about your internal network confidential.
The first of these goals can be achieved in an Eagle-secured network, although there is nothing special about the Eagle software itself which enables it. A combination of setup of e-mail aliases, DNS mail-exchanger (MX) records, and reconfiguration of sendmail on your UNIX hosts inside the network and on the Eagle gateway system itself will enable addressing of e-mail to names like yourname@yourcompany.com and ensure that outgoing e-mail contains such a return address, regardless of where it arises inside your network.
Raptor Systems can make available software which will, in combination with the Eagle software, automatically redirect all incoming e-mail addressed to any system in your network to the e-mail hub you specify. SMTP (e-mail) network packets coming in from the Internet will not be allowed to reach any system inside your network other than the specified mail hub, regardless of the actual address on the message. You can then turn off the sendmail transport agent on your gateway (and on all your internal hosts) altogether.
These can be generated from the log files by whatever techniques the customer chooses. The logs are flat files which can be easily parsed with tools ranging from simple UNIX shell utilities (such as sed, awk, cut, paste, etc.) to sophisticated database systems with full query language and reporting capabilities. The log files can be automatically emailed from the gateway on a daily basis to the analysis system, including being piped directly to data-analysis scripts for immediate processing.
Yes, via a proxy Web server outside the firewall and the Generic Service Passer. You should be aware that use of a WWW proxy service can negate service limits you place in the Eagle authorization file, since WWW clients have ftp, telnet, and other services built in which would not be controllable with the Eagle software and which may require you to reconsider your security policy. It makes little sense to attempt to control outgoing ftp, for example, with the Eagle authorization rules, then let users access ftp services via their WWW browser and the proxy mechanism. Furthermore, since the proxy WWW server operates outside the Eagle firewall, the server itself should not be considered secure.