Firewall Net tests, install & configure
FireWall.net - Guide to install and configure a PC FireWall
 
 

Tests of Winroute 4.2.1

 
? Tests description ? Overview ? Price ? Results ? Pros ? Cons ? Improvements ? Summary ? References ?

A - Overview

The Winroute 4.2.1 firewall[3] is full of interesting features :

    • Protocols and Packet Filtering, ingoing and outgoing, fully configurable per network interface (you can define common rules or specific rules).

    • Rules priority order,

    • Features usefull for local networks :

      • NAT (masqueraing),

      • Proxy : a NAT alternative,

      • DHCP server : allows it to became DHCP server for your own local network,

      • DNS server (forwarder and local DNS server),

      • Centralize filtering management abilities,

    • Time sets (usefull for permanent connexions),

    • Many admin levels with user/passwords, can be combined with NT domains.


B - Price

Release Pro : 5 users : 150 US $ - 30 days trial,

Release Lite : 3 users : 80 US $ - 30 days trial,

¤ (Euros) equiv to US $.


C - Security Effeciency
  1. Test Ping : Blocked . The result of this test is good.

  2. Test Netbus : Winroute 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 Winroute 4.2.1 (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 [email protected] ( 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 Winroute 4.2.1 (on Win 2000 SP2 OS with a "standard" installation, it means NetBios active and so on) the tests were done with the ruleset provided on the configuration page and Winroute Pro 4.x release :


    Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
    Host (IP_ADDR) appears to be up ... good.
    Initiating Connect() Scan against (IP_ADDR)

    The Connect() Scan took 591 seconds to scan 1542 ports.

    Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port

    Interesting ports on (IP_ADDR): (The 1541 ports scanned but not shown below are in state: filtered)
    Port State Service
    113/tcp closed auth

    Too many fingerprints match this host for me to give an accurate OS guess TCP/IP fingerprint:
    SInfo(V=2.54BETA22%P=i686-pc-linux-gnu%D=5/27%Time=3B114459%O=-1%C=113)
    T5(Resp=N)
    T6(Resp=N)
    T7(Resp=N)
    PU(Resp=N)

    Nmap run completed -- 1 IP address (1 host up) scanned in 616 seconds


    This means that Winroute ports remains invisible and access attempt are logged ! This is a good result.

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

    $ nmap -sU -O IP_ADDR

    Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
    Host (IP_ADDR) appears to be up ... good.
    Initiating UDP Scan against (IP_ADDR)
    The UDP Scan took 4 seconds to scan 1453 ports.
    Interesting ports on (IP_ADDR):
    (The 1453 ports scanned but not shown below are in state: closed)

    Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds

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

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

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

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

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

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

  10. Winroute 4.2.1 use 79 % peek CPU load. It uses 5.7 MB MB of memory during normal operations and up to 7 MB 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). Winroute 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) : Winroute doesn't detect anything, it's possible to connect without anything logged. This is a bad result.

  13. Network speed test :

D - Pros 
  • Possibility to specify specific rules for each interface,

  • Possibility to use NAT module ,

  • Possibility to use DNS forwarding feature (complementary to NAT feature) and a DHCP server function,

  • Provide a proxy module which can be usefull (only if you don't want to use NAT function),

  • logs are sperated per feature : security, proxy, and so on in different windows and files,

  • Exist in some foreign languages.

E - Cons
  • It's hard to know wich rule got precedence, moreover when you combine specific interface rules and common rules at the same time !

  • Long and fastiduous to add new rules , its nearly impossible to save them or restore them !

  • Filtering logs are really poor. No advanced logs (storage, size and so on).

  • It's price !

F - Suggested improvements
  • Improve the GUI and packet filter management :

    • rules GUI should be more explicit,

    • adding a rule can be easier,

    • allow to define a host = localhost,

    • allow to create rules to allow you handle broadcast (as 192.168.1.255 and 255.255.255.255),

    • add a learning mode,

    • allow to add a description associated to each rule and be able to give a rule name,

    • add a condition for rules linked to a program (cf. Conseal for example),

  • Allow the customer to manage its rules : be able to export or import them (usefull for a network),

  • Improve the logs quality.

G - Summary 

A complete tool, efficient and adapted to advanced users looking for solutions for their local networks (NAT/masqueraing, proxy, and so on), but it could be really improved for its GUI parts mainly.

Evaluation :

  • Installation process () : 14/20

  • Configuration, GUI () : 10/20

  • Import/Export configuration () : 5/20

  • Filtering rules () : /20

  • Antitrojan protection () : /20

  • Filtering security () : 14/20

  • Software load and memory usage () : 0/20

  • Network speed () : 0/20

  • Product Internationalization () : 15/20

  • HELP, FAQ () : 15/20

Total : 9.48 / 20

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

H - References
  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. Winroute 4.2.1
    Winroute
    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

 
I - Description des tests

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.