Eagle Firewall, Raptor Systems

Description

The is an application layer firewall. It features network address translation, multiple interfaces, and transparent access.

The firewall is administrated with an X-windows based GUI. On supported platforms, the GUI can be run remotely. It uses the Nortel Entrust system to communicate with the firewall. Multiple firewalls can be administrated from a centralized location.

The firewall is installed on top of an existing operating system.

Policy

Raptor Eagle would appear to have evolved slowly, always maintaining backward compatibility with the previous interfaces. There are often multiple places to configure things, repetitive configuration (the distinction between defining services and Generic Service Passers for instance), and misplaced configuration.

Rules can be defined minimally by source and destination addresses. To this is added dialogues to select which services to allow, what times are allowed, which users and groups are allowed or denied, and what kind of authentication is required. The later fields are optional, if they are not defined, then no authentication is required, any user can access, and at any time.

At the same time, the user dialogue allows a user to be configured with a fixed password, or an s/key password. To configure a strong token, one uses the rule interface. That is, some authentication schemes are configured per user, while others are configured per rule.

The policy can be summarized as:

[source XOR netmask] x [destination XOR netmask] x [service groups] x time definition x (user XOR group)

User Authentication

Eagle supports fixed password, S/Key, ACE/SecurId, CRYPTOCard, AssureNetPathways/SNK, generic radius, and generic tacacs.

Logging/Auditing

Logging is done by each proxy, giving connection time, source, destination and number of bytes transfered.

A real time monitor can be used to set off alarms. The criteria for an alarm is a string to match and a severity level.

VPN

Eagle 4.0 supports both SWiPE (referred to as a Raptor proprietary format) and manually keyed IPsec.

Integration

CRYPTOCard is supported directly by Eagle. CRYPTOCard initialization software is required.

Eagle uses the CRYPTOCard Corporation file formats. To configure the CRYPTOCard, the ccsecret and CRYPTOCards files just need to be initialized.

Remote administration is authenticated using a fixed password. Privacy for the remote administration connection is provided by Entrust.

A second option is to use Radius or Tacacs to talk to an appropriate server.

Card Modes

All permissible CRYPTOCard modes are supported via the definitions in the CRYPTOCards file. Reduced input mode is not used, a new random challenge is generated everytime.

The following configuration was used:

Eagle Raptor CRYPTOCard Configuration Options
OPTION FIELD 1 DIGIT
VALUE
MEANING
First Digit (MSD)
-PIN entry feedback options
1 PIN Entry Feedback, user may change PIN
Second Digit
-Decimal/Hex Display
1 Decimal display e.g. 01234ABC
Third Digit (LSD)
Telephone Display
1 Use telephone format
OPTION FIELD 2 DIGIT
VALUE
MEANING
First Digit (MSD)
-Authentication Mode and User ID Options
2 Event Synchronous mode, no User ID required
Second Digit
-Number of PIN entry attempts
0 Unlimited attempts at PIN entry allowed
Third Digit (LSD) -Minimum Pin Length 4 4 minimum of 4 characters for the PIN
OPTION FIELD 3 DIGIT
VALUE
MEANING
Digit 1 (MSD)
-Time Out Period
1 Turn off token after 60 seconds of inactivity
Digit 2
-Prompt Language
0 North American English
Digit 3 (LSD)
-Number of Keys
1 One key



Vendor Documentation

Unavailable at this time.

Experience

Setting up the CRYPTOCard was very simple. The ccsecret and cryptocards files belong in /usr/adm/sg.

Create a user name, add that user to the list of allowed users for that rule, and select CryptoCard authentication.

Standard CRYPTOCard Corporation software was needed. If using the precompiled initfile and intlzr programs, then the output files will be created in the right place. do not put spaces in the ccsecret file.

Setting up radius was equally easy.

A note on rules: when making incoming rules, one must first set up a redirector service in the Gateway dialogue. The internal host to be connected to should be listed. It is not possible to plug ports to multiple destinations, or for the user to select the intended final destination. If multiple internal hosts must be reached, the solution is to use different (non-standard) ports, or virtual IP addresses.

Once the redirector is setup, the destination address of the connection request is translated to the internal address. This is done before the rules are examined. The rule must therefore permit connections from the external node to the internal node.

Installation Recipe

Built-in

  1. copy the cryptocards and ccinit files from the machine where the tokens were configured. It is possible to compile and install initfile and intlzr for the firewall. (See above)
  2. create a rule listing the soruce and final destination that one wishes to authenticate.
  3. select CRYPTOCard from authentication type combo box.

Radius

  1. install and test the radius server on a host.
  2. make sure that the address of the firewall is listed in the radius server's client file. The address should be that of the interface closest to the radius server.
  3. create a rule listing the source and final destination that one wishes to authenticate.
  4. Edit the authentication type. (bottom of the dialogue)
  5. In the dialogue, create a new authentication type. One suggestion is to give it the name of the radius authentication host. Do not pick the CRYPTOCard definition.
  6. Pick ``radius'' from the protocol list.
  7. Enter the IP address of the server, possibly giving the address of a backup server.
  8. the Radius client shared secret is required.
  9. save the entry by clicking Update and then Close
  10. pick the named entry in the authentication type. Future rules that are to use same authentication server need only do this last step.

If the Radius server is installed on the firewall it will be reachable from any host on all sides of the network. The firewall provides no protection for it. It is therefore not suggested that a radius server be installed on the firewall.

User Recipe

Telnet example

    % telnet gate.pcgbase.com
    Trying 205.233.33.5...
    Connected to gate.pcgbase.com.
    Escape character is '^]'.

    Eagle Secure Gateway.
    Enter Gateway Username: mcr
    CRYPTOCard challenge 33452595, response: 722-7787

    UNIX(r) System V Release 4.0 (pcgbase)
    login:

  1. Invoke the telnet command, connect to the external interface of the firewall. This will commonly be given the name of the company, e.g. CRYPTOCard.com.
    telnet outside.sandelman.ottawa.on.ca
  2. Telnet will connect to the remote system, giving some notices as it does so. The prompt login: will appear.
    Trying 205.233.33.5...
    Connected to gate.pcgbase.com.
    Escape character is '^]'.

    Eagle Secure Gateway.

    Enter Gateway Username:

    Enter the username. The letters will echo.
  3. The system will provide a challenge and prompt for the response.
    CRYPTOCard challenge 33452595, response:
    The response will echo.
  4. If the challenge is successful, the user will be connected to the remote machine. The selection of remote machine is usually configured by the administrator.
    CRYPTOCard challenge 33452595, response: 722-7787

    UNIX(r) System V Release 4.0 (pcgbase)

    login:

Radius Telnet Example

% telnet gate.pcgbase.com
Trying 205.233.33.5...
Connected to gate.pcgbase.com.
Escape character is '^]'.

Eagle Secure Gateway.
Enter Gateway Username: mcr
Challenge: 50020931 Enter Response:

UNIX(r) System V Release 4.0 (pcgbase)

login:

FTP Example

% ftp gate.pcgbase.com
Connected to gate.pcgbase.com.
220 Secure Gateway FTP server ready.
Name (gate.pcgbase.com:mcr): mcr
331 Password required for destination user mcr.
Password:
332 CRYPTOCard challenge 77237029, response (use the 'account' command to respond)
Account:
530- Connected to pcgbase.pcgbase.com.
530- 220 pcgbase FTP server (Version wu-2.4(12) Thu Jun 27 19:07:06 EDT 1996) ready.
530 Login incorrect.
ftp: Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.

At the Password: prompt, one should enter the password for the final host. Eagle will provide the username and password to the remote host after authentication.

The CRYPTOCard challenge is displayed using the auxiliary Account facility. This command is sometimes not implemented in some PC clients.

Note, whether or not the passwords are echoed depends entirely on the FTP client. Default Unix FTP does not echo the password.

Logs from Examples

telnet[1745]: connection for y.x.com to pcgbase.pcgbase.com [rule id 3] [auth required]
telnet[1745]: connection for y.x.com to pcgbase.pcgbase.com [rule id 3]
121 Statistics: duration=78 user=mcr auth=CRYPTOCard sent=124 rcvd=245 srcif=le0
src=205.233.54.134/1827 dst=205.233.33.1/23 proto=telnet
telnet[1745]: closing connection

telnet[1936]: connection for y.x.com to pcgbase.pcgbase.com [rule id 3] [auth required]
telnet[1936]: connection for y.x.com to pcgbase.pcgbase.com [rule id 3]
121 Statistics: duration=47 user=mcr auth=radius:205.233.54.134 sent=124 rcvd=232 srcif=le0
src=205.233.54.134/1837 dst=205.233.33.1/23 proto=telnet telnet[1936]: closing connection

ftp[1752]: connection for y.x.com to pcgbase.pcgbase.com [rule id 3] [auth required]
ftp[1752]: connection for y.x.com to pcgbase.pcgbase.com [rule id 3]
121 Statistics: interval=281 user=mcr auth=CRYPTOCard sent=47 rcvd=338 srcif=le0
src=205.233.54.134/1828 dst=205.233.33.1/21 proto=ftp
121 Statistics: duration=281 user=mcr auth=CRYPTOCard sent=47 rcvd=352 srcif=le0
src=205.233.54.134/1828 dst=205.233.33.1/21 proto=ftp ftp
[1752]: closing connection

Time fields removed to fit the page.

Note that the internal machine shows a connection to the firewall, not the external node.

[Home] [Search] [What's New] [Products] [Sales]
[Company] [Partners] [Download] [Employment] [Support]

Revised : Tuesday, March 25, 1997
©1997, CRYPTOCard Corp., All Rights Reserved