Outpost versus Wormhole Tunnels

[tjuren]

I have read this article about "Software Firewalls versus Wormhole Tunnels" at: http://www.securityfocus.com/infocus/1831

Outpostfirewall forum seems to have very little about network interfaces working in promiscuious mode. Nothing about vpn's created by mallisious software thus giving it an unwanted function (the desired one for me , and one for the "creator or bandwidth consumer/seller" )

I have initially two questions:
-Does Outpost always asume that the network interfaces works in non-promiscious mode?
-What options does outpost offer to assist understanding what mode my network card is working in?

and:
-Are there any more step by step laborations available on internet but for the one I found at Microsofts page at: http://support.microsoft.com/?kbid=892853

[aspnet]

tjuren - Thank you

This has nothing to do with promiscuous mode. Promiscuous mode simply enables NYC to catch packets not addressed to its MAC. The problem described in the article occurs because certain programs using libpcap library can directly communicate with NYC bypassing the firewall.

I just conducted a little experiment and confirmed the problem. Outpost leaks like a sieve!!!!!!!

My setup: Computers A and B on the LAN

Computer A:
WinXP
Outpost in "Stop All" mode
Nemesis (a program to create and inject custom packets) with WinPCap installed

Computer B:
Win2K
Outpost in "Stop All" mode
ARP Cache: Empty

I ran Nemesis on Computer A:
nemesis arp -S [Routers's IP] -D [Computer B's IP]

ARP Cache of Computer B now shows:
Router's IP -> Computer A's MAC

I just successfully carried out ARP poisoning attack of Computer B from Computer A even though BOTH COMPUTERS HAD OUTPOST FIREWALL IN STOP-ALL MODE!

I think bug report is due - though this sounds like it could just be a design flaw.

[tjuren]

You are welcome - aspnet
Thank you for the laboration! If I could I would serve you tea and cookies...

The worst is that it seems to concern every kind of standalone software firewall. The author of the article I mensioned discusses that intrusion detection systems should be the standard way to monitor the network-"plugg in the wall".

Just my thoughts:
I who have only one machine and a gateway sees that the future should be to have both hardware and software working hand in hand, to talk to each other! It shouldn't be that difficult to implement. Perhaps a new standard in this area is the only way to walk to avoid wormholes.

My constantly confused and twisted mind forced me to check the following earlier today:
I thought that perhaps there is a way to set the networking services on my win xp (sp1) to only tolerate open packages. I have skimmed the ipsec help files and tutorials to see if it is possible to make it work "backwards": To force all tcp/ip traffic to be in an open mode. However to perform a laboration would require my gateway to be a "windows device" which it is not (hehe and shouldn't be). -Well just hallucinating...

[aspnet]

should be to have both hardware and software working hand in hand

Well, one solution is router (which I have) in addition to Outpost

What I would really like is to hear some opinions from people involved with Outpost development or bug-track

Paranoid, Minoka - lets hear your input into this one

[BAM]

Forgive me if im completely off track here, but shouldnt the raw sockets monitoring of Outpost catch these sort of packets from the sorts of programs that use the libpcap library? DId you previously allow access to rawsockets for "nemesis"?

Just an out of the blue query!

Regards,

BAM.

[Paranoid2000]

Originally Posted by BAM

DId you previously allow access to rawsockets for "nemesis"?

This is the key question - any program allowed rawsockets access will be allowed to bypass Outpost completely (and the Outpost Rawsockets window does warn about this). Outpost should also prompt on Rawsocket access by default so if you did not allow rawsocket access for libpcap and recieved no prompt, then this would be worth reporting to Agnitum (Agnitum Online Support Form).

As for Aspnet's ARP "poisoning" test, it should be noted that Outpost does not by itself filter ARP traffic - if you consider ARP poisoning an issue (this should only apply if you are sharing a local network with untrusted systems - though some cable ISPs arrange their network in this fashion!) then you should use the SuperStealth plugin - this does filter ARP requests and can prevent ARP poisoning.

Finally, any such technique which requires a driver install can be blocked using other security software - in this case the full version of Process Guard can block driver/rootkit installations and Win2K/XP users should seriously consider using it (it does not work for 9x/ME). Even the free version will improve security by protecting your security software from being terminated by malware. Malicious driver installation is more of a Windows security issue and really needs to be dealt with separately. The Wilders' forum thread CHX-I has some discussion of malicious drivers on page 2 (along with lots of other firewall-related items...) so may be worth a read.

[aspnet]

Paranoid2000
BAM

There are NO applications on my system at all allowed Rawsocket access. I also have a checkmark "Ask whenever an application attempts to use rawsockets".

I never get any notifications when ranning Nemesis. All the traffick it generates is listed in the logs under "System". E.g. if particular ICMP traffic is allowed under "system" rules, I can send those ICMP packets using Nemesis and they're "Allowed" to pass. ARP traffick passes even in Stop-All mode, as I described above.

Rawsocket controls never pop up (and Outpost never even recognizes that traffic is generated by Nemesis, and not "System"). Outpost is not aware of Nemesis at all.

With respect to SuperStealth - I'll try ranning the same test with SuperStealth and will report results. But I doubt it's an issue because in Stop-All mode all traffick should be stopped, SuperStealth or not.

With respect the "Driver Install" - Paranoid, the "malicious driver" (Nemesis/WinPCap) was installed only on the "Attacking" computer A. The "victim" Computer B (whose ARP cache was poisoned) did NOT have Nemesis or WinPCap.

[Paranoid2000]

Originally Posted by aspnet

I never get any notifications when ranning Nemesis. All the traffick it generates is listed in the logs under "System". E.g. if particular ICMP traffic is allowed under "system" rules, I can send those ICMP packets using Nemesis and they're "Allowed" to pass. ARP traffick passes even in Stop-All mode, as I described above.

That suggests that Outpost is seeing the traffic generated by Nemesis but is allowing/blocking it based on your ruleset which is normal. ICMP traffic is normally attributed to "System" by Outpost so this is not unusual either.

Outpost does not offer direct control over ARP (that's where SuperStealth comes in) but ARP requests/responses cannot be sent over the Internet (they are Ethernet frames rather than Internet Protocol packets) so ARP exploits are limited to LANs only (and possibly within cable ISPs as noted previously).

ARP is a protocol that sits underneath IP (its purpose is to provide a translation between IP addresses and Ethernet MAC addresses) so it is not specifically covered by most firewalls (which start filtering at the IP level). SoftPerfect and Sygate offer ARP filtering and Look'n'Stop has a plugin for viewing ARP traffic but those are the only examples I've come across so far.

[aspnet]

Paranoid2000
You were right. I conducted the same test with SuperStealth and it successfully prevents ARP poisoning. Outpost cannot block ARP traffick without SuperStealth, so ARP traffick is not the best way to test how Outpost handles applications that communicate with NYC directly (by using rawsocket access).

That suggests that Outpost is seeing the traffic generated by Nemesis but is allowing/blocking it based on your ruleset which is normal. ICMP traffic is normally attributed to "System" by Outpost so this is not unusual either.

Paranoid, you are missing the point. When I generate ICMP or TCP or other traffic with Nemesis, Outpost always attributes it to the "System" (and yes, it uses "System" rules to filter "system" traffic, I understand that).

What Outpost should be doing is:
#1. Identifying that an application called Nemesis (NOT the "System") is requesting rawsocket access.
#2. Popping up a window asking me if I want to allow this application rawsocket access
#3. From that point on, allowing or disallowing Nemesis' rawsocket traffic based on my decision in #2, rather than "System" rules.

What is the whole point of having Rawsocket controls if Outpost cannot even correctly identify which applications are using rawsockets? I also ran Ettercap, another program which operates through rawsocket access, and it's the same situation as with Nemesis.

Paranoid, this is not normal. This is a bug.