Tests du Firewall Winproxy

• Antivirus intégré

• Filtrage des sites Web

• Taille du fichier à télécharger : 15 Mo.

• Support annoncé de : Win 98/Me, XP, 2000, NT4

68 Euros

1. Test Ping : Le ping reste possible même avec le firewall au niveau High (utilisé pour l'ensemble des tests). C'est un mauvais résultat.

2. Test Netbus : Winproxy ne détecte pas le lancement de Netbus en mode serveur et les ports 80 et 23 de NetBus sont bloqués et ce dernier refuse de les utiliser... Cependant si netbus utilise d'autre ports ( 20036 , 20023 , 20080) tout reste possible, Les connexions de l'extérieur vers Netbus ne sont pas détectées. Le résultat est mauvais.

3. Un scan nmap sans Winproxy (sur un OS Win 2000 avec une configuration "standard", c'est à dire NetBios actif etc.) :
   
   $ 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
   

   Un scan TCP avec nmap et Winproxy (sur un OS Win 2000 avec une configuration "standard", c'est à dire NetBios actif etc.) scan donne une alerte , NPF détecte le scan ignore immédiatement et automatique l'adresse IP source du scan , ce qui est un bon résultat en termes de détaction et de protection :
   
   
   Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
   Host (IP_ADDR) appears to be up ... good.
   Initiating Connect() Scan against (IP_ADDR)
   Adding open port 1080/tcp
   Adding open port 135/tcp
   Adding open port 139/tcp
   Adding open port 23/tcp
   Adding open port 110/tcp
   Adding open port 5190/tcp
   Adding open port 21/tcp
   Adding open port 80/tcp
   Adding open port 4144/tcp
   Adding open port 445/tcp
   Adding open port 1025/tcp
   The Connect() Scan took 0 seconds to scan 1554 ports.
   For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled
   Interesting ports on (IP_ADDR):
   (The 1543 ports scanned but not shown below are in state: closed)
   Port State Service
   21/tcp open ftp
   23/tcp open telnet
   80/tcp open http
   110/tcp open pop-3
   135/tcp open loc-srv
   139/tcp open netbios-ssn
   445/tcp open microsoft-ds
   1025/tcp open listen
   1080/tcp open socks
   4144/tcp open wincim
   5190/tcp open aol
   
   Remote OS guesses: Windows Me or Windows 2000 RC1 through final release, Windows Millenium Edition v4.90.3000
   TCP Sequence Prediction: Class=random positive increments
   Difficulty=22072 (Worthy challenge)
   IPID Sequence Generation: Incremental
   
   Nmap run completed -- 1 IP address (1 host up) scanned in 12 seconds
   
   
   Ce qui montre qu'avec WinProxy, non seulement les ports de Windows semblent apparents, mais en plus les ports du proxy sont ouverts à l'extérieur ! C'est un mauvais résultat.
   

4. Un scan nmap UDP avec Winproxy (sur un OS Win 2000 avec une configuration "standard", c'est à dire NetBios actif etc.) :
   
   Starting nmap V. 2.54BETA31 ( www.insecure.org/nmap/ )
   Host (IP_ADDR) appears to be up ... good.
   Initiating UDP Scan against (IP_ADDR)
   The UDP Scan took 6 seconds to scan 1459 ports.
   Adding open port 138/udp
   Adding open port 53/udp
   Adding open port 445/udp
   Adding open port 500/udp
   Adding open port 137/udp
   Adding open port 67/udp
   Adding open port 135/udp
   Interesting ports on (192.168.66.130):
   (The 1452 ports scanned but not shown below are in state: closed)
   Port State Service
   53/udp open domain
   67/udp open dhcp
   135/udp open loc-srv
   137/udp open netbios-ns
   138/udp open netbios-dgm
   445/udp open microsoft-ds
   500/udp open isakmp
   
   Nmap run completed -- 1 IP address (1 host up) scanned in 6 seconds
   
   
   De même , ceci confirme qu'avec Winproxy les ports habituellement ouverts sont apparents mais aussi ceux du proxy. C'est un mauvais résultat.
   

5. Test Leaktest : Winproxy ne détecte pas la tentative de connexion de Leaktest, qui arrive à se connecter. Le résultat est donc mauvais .

6. Test Yalta :

7. Test Tooleaky :

8. Test FireHole :

9. Test OutBound :

10. Winproxy utilise jusqu'à 0 à 1% de CPU . Il utilise 8 Mo Mo de mémoire en fonctionnement normal et jusqu'à 9 Mo Mo en pointe.

11. Le test de substitution : (vous pouvez le réaliser vous même par exemple : vous remplacez Iexplorer.exe avec leaktest.exe - celui-là même - en renommant ce dernier et en l'exécutant). WinProxy ne détecte pas le changement. C'est un mauvais résultat.
    
    

12. Pour le second test (le troyen remplace son exécutable au lancement) : WinProxy ne détecte pas le changement. C'est un mauvais résultat.
    

1. WinProxy semble offrir de nombreuses fonctionnalités en tant que proxy (non testées ici).

2. Support annoncé de Windows 95/98/ME, Windows NT, Windows 2000, Windows XP

1. WinProxy n'intègre absolument aucune fonction de filtrage digne de porter le nom de firewall.

2. 20% de perte en taux de transfert...

• Soit supprimer "firewall" de éléments commerciaux de ce produits, soit implémenter une vrai protection !

• Réduire la taille du logiciel : 15 Mo à télécharger et 18 Mo une fois installé, c'est presque la taille record de Norton !!!

• Améliorer la protection par indentification les logiciels reconnus afin de les protéger contre un troyen.

• Internationaliser le logiciel serait utile :)

Difficle de conclure. De façon synthétique , n'utilisez pas ce produit comme un firewall, ce n'en est pas un !

Evaluation :

• Installation (2) : 5/20

• Configuration, Interface graphique (3) : 5/20

• Sécurité filtrage (5) : 0/20

• Sécurité complémentaire (3) : 0/20

• Utilisation mémoire et CPU du logiciel (2) : 10/20

• Import/Export de la configuration (2) : 0/20

• Performance réseau (3) : 6/20

• Aide, FAQ (2) : 8/20

• Internationalisation du produit (1) : 0/20

Total : 3,4 / 20

Note : Ce résultat peu être modifié selon la version logicielle, lors de l'ajout de nouveaux critère, la modification de leur importance ou de leur contenu et mode d'évaluation.

1. Nmap - Network mapper, un outil très efficace pour scanner et tester l'activité réseau -
   http://www.insecure.org/nmap

2. Netbus Pro - Programme de contrôle à distance souvent utilisé comme outil d'attaque pour contrôler un PC distant.
   http://www.netbus.org/
   download

3. Winproxy
   http://www.winproxy.com/
   download

4. Leaktest - Petit logiciel de test réalisé par Steve Gibson afin d'éprouver les firewalls les plus répandus (et les autres). Il fait une simple connection ftp standard censée simuler l'envoi d'informations personnelles à votre insu, voire un mécanisme simple de prise de contrôle à distance en mode opposé (oups).
   http://grc.com/
   download

Les critères de choix pour un firewall personnel sont :

• Efficacité des protections : pénétration, troyens, surveillance des points faibles, dénis de service.

• Efficacité de la détection d'intrusion : minimum d'identification positives erronées, alertes sur les attaques dangereuses.

• Interface utilisateur : facilité d'utilisation, simplicité, qualité de l'aide en ligne, complémentarité de l'interface avec votre façon d'utiliser votre PC.

• Prix.

Comment les tests ont-ils été réalisés ?

1. Simple ping et tentative d'utilisation des partages réseau de et à partir de l'ordinateur de test.

2. Installation d'un outil utilisé comme troyen, bien connu et performant (Netbus Pro v2.1 [2]) sur un port non standard de l'ordinateur de test et tentatives d'accès à partir d'un système distant.

3. Un scan TCP nmap [1] a été réalisé et comparé au scan nmap fait sans firewall (nmap -sT -P0 -O IP_ADDR).

4. Un scan UDP nmap [1] a été réalisé et comparé au scan nmap fait sans firewall (nmap -sU -P0 IP_ADDR).

5. Un test utilisant Leaktest [4] a été réalisé.

6. Nouveau : Les tests avec les autres utilitaires inspirés de Leaktest, sont dorénavant effectués.
   Yalta Tooleaky FireHole Outbound
   

7. On vérifie les ressources système utilisées par le firewall pendant les tests (au cas où).

8. Le premier test de subsitution : On essaie de lancer une version modifiée de IEXPLORE.EXE (C:\Program Files\Internet Explorer\IEXPLORE.EXE ) pour vérifier si le firewall détecte le problème.

9. Le second test de substitution : (vous pouvez le réaliser vous même par exemple : vous lancez iexplorer.exe, vous renommez iexplorer.exe en iexplorer.old et renommez leaktest.exe en iexplorer.exe puis vous le lancez, attention le système va l'écraser assez rapidement). On lance une version modifiée de IEXPLORER.EXE pendant qu'il est déjà en cours d'exécution et on teste pour savoir si le firewall détecte le problème.

10. Nouveau : 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 : une mesure comparative sur la même plateforme sans firewall, de transfert d'un fichier de taille respectable (50 Mo) sur un réseau local à 100 M/s. Sans firewall, on atteint un taux aux environs de 90 Mb/s très proche de la capacité nominale sur ce type de réseau.
    Un bon firewall ne doit pas dégrader ces performances, ou tout au moins elles doivent rester négligeables.

NB : Ces tests n'ont pas vocation à être exhaustifs bien au contraire. Cependant l'objectif reste de vérifier que le logiciel testé offre un minimum (ou non) de sécurité pour un usage personnel (à ne pas confondre avec l'usage professionnel).

Voir les résultats des tests.