Tests of Conseal

The Conseal firewall[3] is full of interesting features :

• • Filter ALL packets. For example, you can deny outbound web pages on Ethernet device 1 or all inbound email connections from network X over dialup only.

  • Control access to networking resources? complete access control according to IP address, service, device and direction. For example, you can allow inbound FTP connections from Ethernet device 1 for only three chosen IP addresses.

  • Activate rulesets only for specific applications

  • Filters all packet types at the device (link layer) level, including IP (TCP, UDP, etc), NetBEUI, IPX, ARP, etc.

  • You don't have to install required special-purpose plug-ins or add-ons to enable applications or services to pass through this firewall.

  • Constant monitoring - works quietly in the background while you use your system, constantly monitoring all traffic in or out of your PC.

  • Optional password protection or rulesets

  • Rulesets can be exported or transferred between systems with virtually no changes, making universal "corporate" rulesets feasible.

  • Complete logging services - Log files record all network activity to help you track down important events.

No sold any more... :-(

1. Test Ping : Blocked . The result of this test is good.

2. Test Netbus : Conseal doesn't detect the Netbus server when started. But it remains impossible to connect to Netbus server from outside and an event is logged. The result of this test is good.

3. An nmap scan without Conseal (on Win 2000 OS SP1 with a "standard" installation, it means NetBios active and so on) :
   $ nmap -sT -O -P0 -v IP_ADDR
   
   Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
   Initiating TCP connect() scan against (IP_ADDR)
   Adding TCP port 135 (state open).
   Adding TCP port 1025 (state open).
   Adding TCP port 445 (state open).
   Adding TCP port 139 (state open).
   The TCP connect scan took 0 seconds to scan 1523 ports.
   
   For OSScan assuming that port 135 is open and port 1 is closed and neither are firewalled
   Insufficient responses for TCP sequencing (0), OS detection will be MUCH less reliable
   For OSScan assuming that port 135 is open and port 1 is closed and neither are firewalled
   Insufficient responses for TCP sequencing (0), OS detection will be MUCH less reliable
   For OSScan assuming that port 135 is open and port 1 is closed and neither are firewalled
   Insufficient responses for TCP sequencing (0), OS detection will be MUCH less reliable
   
   Interesting ports on (IP_ADDR):
   (The 1519 ports scanned but not shown below are in state: closed)

   Port	State	Service
   135/tcp	open	loc-srv
   139/tcp	open	netbios-ssn
   445/tcp	open	microsoft-ds
   1025/tcp	open	listen

   
   Too many fingerprints match this host for me to give an accurate OS guess
   TCP/IP fingerprint:
   T1(Resp=N)
   T2(Resp=N)
   T3(Resp=N)
   T4(Resp=N)
   T5(Resp=N)
   T6(Resp=N)
   T7(Resp=N)
   PU(Resp=N)
   
   Nmap run completed -- 1 IP address (1 host up) scanned in 29 seconds
   

   An nmap TCP scan with Conseal (on Win 2000 SP2 OS with a "standard" installation, it means NetBios active and so on) with the ruleset provided here or more verbose ruleset here :
   
   Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
   Initiating TCP connect() scan against (IP_ADDR)
   Skipping host (IP_ADDR) due to host timeout
   
   Nmap run completed -- 1 IP address (1 host up) scanned in 75 seconds
   

   
   
   An nmap scan with Conseal gives :
   

   • no result with the ruleset provided here,

   • no result but the events are logged with the ruleset verbose,

   • hundreds of logged events and dialog windows with the default ruleset.
     
     

   Therefore, tight effective security is possible with Conseal, if configured correctly. This is a good result.

4. An nmap UDP scan with Conseal (on Win 2000 SP1 OS with a "standard" installation, it means NetBios active and so on) :
   

   $ nmap -sU -O IP_ADDR
   NAV

   This means that the security seems efficient for UDP, and events appears in the log. This is good result.

5. Test Leaktest : Conseal doesn't detect the software start, and leaktest is able to connect, the result of this test is bad.

6. Test Yalta : Conseal doesn't detect the software start, and yalta is able to connect, the result of this test is bad.

7. Test Tooleaky : Conseal doesn't detect the software start, and tooleaky is able to connect, the result of this test is bad.

8. Test FireHole : Conseal doesn't detect the software start, and firehole is able to connect, the result of this test is bad.

9. Test OutBound : Conseal doesn't detect the software start, and outbound is able to connect, the result of this test is bad.

10. Conseal use NAV peek CPU load. It uses NAV MB of memory during normal operations and up to NAV MB peeks.

11. The substitution test : (you can make it yourself : for example you substitute Iexplorer.exe with leaktest.exe - yes this one :) - by renaming the latest and running it). Conseal doesn't detect anything, it's possible to connect without anything logged. This is a bad result.
    

12. For the second test (the trojan replace the executable file at the software start) : Conseal doesn't detect anything, it's possible to connect without anything logged. This is a bad result.

13. Network speed test :

• Rules can be applied to specific dialup connections.

• Rules can be password-protected.

• "Learning mode" should make it easier for the user to get the initial rules he/she needs installed. This mode can be interactive or automatic.

• Logging window is useful. The maximum log size can be set and its directory (but not name) changed.

• Rules can be saved, loaded and exported to text format.

• Expensive for NT/Win2K users.

• The GUI is not the easiest to use.

  • Netmasks and port ranges could be better presented.

  • Using rule priority numbers is not trivial to grasp. Why are rules not listed in numerical order?

  • The number of rules can be large and confusing.

  • Creating rules to deal with broadcasts is not easy.

  • Despite enabling "unchecked learning mode" (where appropriate rules should automatically be generated), UDP/137 packets were blocked.

  • Despite adding a rule allowing all UDP ports on an active dialup connection, outgoing UDP/137 was still being blocked — the rules can collide and create confusing effects that are annoying to correct.

  • The dialog which prompts the user to add new rules needs improvement. A communication can be allowed/blocked for this session or forever. But there is no option to set port/IP ranges, associate an application, associate this network interface only, allow all UDP or TCP communications to/from this host, etc. The details dialog is useful but terse. UDP traffic on high ports can be a real pain (many alerts on different ports creating many different rules).

  • Associating an application with a rule could be easier; no application details are shown, just a lookup list of cryptic names corresponding to running tasks. Since only the application name (not path or a cryptographic hash of the application executable) is checked, it would not detect Trojans pretending to be a trusted application.

• There are no corporate features such as centralized alerting, policy updates, rollout or lockdown.

• Rules cannot be applied to specific LAN adapters on the Conseal Win2K/NT Workstation version. Rules can be specified per adapter in the Windows 9x/ME and 2K/NT Server editions.

• Constant (annoying) beeping of the computer speaker when alerts are detected. To fix this, remove "warning" from rules, activate "logging" instead.

• There is no concept of "trusted addresses" (from which the workstation should accept all traffic).

• The log cannot be browsed. The Log window shows recent events, but once cleared, previous events cannot be viewed.

• Intrusion detection is poor:

  • Log events don't have any kind of severity rating.

  • Scans are not detected, only connections to individual ports.

  • No options for tracing the attacker source are provided.

  • Is is very difficult for non-expert users to understand what the log entries actually mean.

• Overhaul the rules interface and the dialog which prompts users for leaning mode rules.

• Allow the user to change the order of columns listed in the rules window.

• Create a list of sample rules that the user can add/remove. Rules that are easy for users to understand, like: "Allow computer to be visible in Network Neighborhood," "Allow other hosts to detect your presence (ping)," "Allow Filesharing," "Allow accessing of remote Fileshares," etc.
  Note: sample rulesets are available from http://www.consealfirewall.com/buildblk3.htm

• It would be useful to change rule order by drag and drop.

• A separate single dialog for editing existing rules would be better than using the "new rule wizard."

A powerful, flexible firewall that expert users may well appreciate. Could be much easier to use, though.

Corporate users may be interested in features such as password-protecting of rules and exporting/importing of rulesets. However, remote policy changes, centralized logging/alerting, centralized rollout and enabling of selected GUI features are not supported.

Evaluation :

• Installation process () : /20

• Configuration, GUI () : /20

• Import/Export configuration () : /20

• Filtering rules () : /20

• Antitrojan protection () : /20

• Filtering security () : /20

• Software load and memory usage () : /20

• Network speed () : /20

• Product Internationalization () : /20

• HELP, FAQ () : /20

Total : / 20

Note : the result may be modified with the release , and when adding new criteria or re-evaluating their weight or their content.

1. Nmap - Network mapper, a really efficient tool to check networks
   http://www.insecure.org/nmap

2. Netbus Pro - Remote control program often used as an attack tool to control remote PCs.
   http://www.netbus.org/
   download

3. Conseal
   Conseal
   download
   

4. Leaktest - Small testing software written by Steve Gibson to check firewalls. It makes a simple TCP (ftp) connexion that simulate sennding of personnal content, which can also be used to take remote controle in reverse mode (arg :-[ ).
   http://grc.com/
   download

Key criteria in choosing a personnal firewall are :

• Effectiveness of security protection : penetration, Trojans, controlling leaks, denial of service.

• Effectiveness of intrusion detection: few false positives, alerting of dangerous attacks.

• User interface: ease of use, instructiveness, simplicity, quality of online help. Does the interface suit the way you use your PC ?

• Price.

How did we test firewall/intrusion detection efficiency ?

1. Ping and accessing shares to and from the test host.

2. A powerful, well known "remote control" Trojan (Netbus Pro v2.1 [2]) was installed on the system on a nonstandard port (to make detection more difficult), the Netbus server started and attempts made to connect from a remote system.

3. An nmap [1] TCP scan was run, to check that incoming ports were really blocked. With another local PC launching nmaps againts the test PC and the following options (nmap -sT -P0 -O IP_ADDR).

4. An nmap [1] UDP scan was run, to check that incoming ports were really blocked. With another local PC launching nmaps againts the test PC and the following options (nmap -sU -O IP_ADDR).

5. A test using Leaktest [4] was done.

6. New : The tests with other tools inspired by Leaktest, are now done.
   Yalta Tooleaky FireHole Outbound
   

7. We checked the system ressource usage of the firewall during the tests (just in case).

8. The first substitution test : We try to launch a modified (by us) release of IEXPLORE.EXE (C:\Program Files\Internet Explorer\IEXPLORE.EXE ) to check if the firewall detects the problem.

9. The second substitution test : we start iexplorer.exe, rename iexplorer.exe to iexplorer.old and rename leaktest.exe to iexplorer.exe :) then you try to start it. Be careful the Windows system will replace the executable file quickly after the first rename. assez rapidement). This means that we start a modified release of IEXPLORER.EXE while this one is already running and check if the firewall detects it (note that this test is not possible on Windows 9x systems).

10. New : After many remarks, a network impact test is done. At this time it still simple : A la suite de nombreuses remarques, un test d'impact sur les performances réseau est réalisé. Pour le moment la méthodologie est simple : whe make a ratio on the same server with and without firewall of the network transer speed (on a 100 Mb/s local netork). Without a firewall we reach 90 Mb/s , near the nominal speed on such network.
    Each time 3 measures were done, we keep the best one to compute the ratio.
    A good firewall shouldn't lower this speed (a maximum of 5% is correct).

NB : These tests do not pretend to be exhaustives. By the way the aim is to be sure that the tested software offers at least expected security (or not) for a personnal use (do not compare this to professional use).

Jump to the tests results.