Software Firewalls: Made of Straw?

This is a great article, ronjor, and should be required reading by all, for it will lead one to think about the direction that firewall development is taking, and lead one to ask, what should a firewall do?

I'll mention two areas covered in the article:

-----------------
...so if an illegitimate process attaches EVIL.DLL to good process X, good process X will in effect be running the code from EVIL.DLL along its own...

...Yet another concern is whether the process has had its code altered in memory...
----------------

The user has two choices:

1) find a firewall that adds this type of protection, or

2) find other means of dealing with those problems.

Solution 1) is attractive to those who like the idea of a bigger, more robust firewall product

Solution 2) is favored by those who like some of the new products that handle these problems easily, stopping their attempt (dll injection, process altering) even before they get to the firewall.

It will be interesting to see in Part 2 if real-documented examples of some of these exploits exist - not just leak tests.


-rich
________________
~~Be ALERT!!! ~~

 

Isn't this old news?

We all know this already.

Another firewall article

http://www.ranum.com/security/computer_security/editorials/deepinspect/index.html

 

From the article:

Another recent article on SecurityFocus that touches on this:

Software Firewalls versus Wormhole Tunnels

Regards,

CrazyM

 

And this is why I don't think complex "leak proof" firewalls are worth the effort.

 

Nice article Ron .... really enjoyed it .... and I'm sure Pollmaster would not have considered it to be old news .... back when he was a " newbie " !!

HR

 

Very useful article.

However, I don't think it's a nail in the coffin for application filters.

One needs to understand their limits and uses.

For simply implemented "phone home" attempts they mostly work as advertised. This is a good thing.

Also, if one's system is compromised (by a superbly engineered virus/worm/backdoor) there is VERY LITTLE firewall can do, packet filter or app filter (or a combination of the two).

So, IMHO the point is not to think that it is the role of the FW (packet filter or other) to protect the system from viral code. It job is to control network access (inbound/outbound, system/app level).

It is the job of the Antivirus, antitrojan and antispyware utilities to control whether malware is able to run decompress/decrypt/execute/modify on the system.

And these software are of course imperfect.

However, if some code still gets through and the system is compromised, FW can help a bit.

It will catch the crudest/simplest outbound/inbound attempts.

Sure it's no panacea, but nothing is. So, it's imperfect like an AV or like an AT.

However, combining a good AV, good AT, good packet/app filter with a good set of sensible security practises is just about the best we can get.

Also, it's a good point to remember that a good packet filter combined with a good application filter is a better option that either of the two alone. Sure, the difference may not be big in some specific circumstances, but in overall use both have their benefits. So, why not have BOTH, instead of either-or?

Also, in my opinion the two should be wed inseparably.

Only by applying APP specific rules for oubound access (default deny otherwise) can you even theoretically have a tighter granulity than with a packet filter that ALWAYS lets data through for one specific rule (default deny for everything else).

The problem, as I have seen it (on the product in the market) is to intertwine the two so that they work together seamlessly and hard to fool.

That's my two cents worth.

YMMV, as always.

 

For a month or so, have been running CHX with Winsonar and Avast, so far no problems, I also use Net Meter which would tell me if there is any net activity going on behind my back as well as TCP View. I have no outbound app filtering in my system or my other system which is on LAN, as a matter of fact, all the LAN PC has is Winsonar, it uses my PC as Gateway so it is protected by CHX.

 

Ok, let me phrase my question this way:

Suppose you have the following scenario:

APP Allowed IP Allowed port
Firefox 127.0.0.1 8080
Opera * 80
IE * 80, 8080, 8090 (several other ports)
+ lots of other apps / IPs / Ports

Now, you have to open all the above ranges (in a packet filter), if you want one program to access them.

Once a range (IP/Port) is active AND an application is allowed to start, what stops from App X using ALL the open ranges, and not the ones intended?

A good app filter / packet filter does both imho.

It control the IP and port/protocol ranges (and a few other tidbits like session flows, packet fragments, etc.)

AND

It controls what programs can access which ranges (by themselves or via starting other apps or dlls).

AND

it may also control application starting (if one likes one tool to do it all).

Is this impossible to achieve?

Now, one could of course start to argue that why does one need to open such and such ports and different ranges for different programs.

But that is called "moving goal posts" in this discussion.

Sometimes one needs to be able to sacrifice some access security for more wide (outbound) access.

When one does this, it is desirable that the sacrifice comes with as accurate access granulity control as possible.

Just opening a range for any software to access does not cut it for me (for MY needs).

Anyone?

 

I'm still a newbie Hard rocker.

 

but are you a clueless newbie

 

There's a clueless newbie in all of us, Bubba :-?

 

Software Firewalls: Made of Straw? Part 2 of 2
Israel G. Lugo, Don Parker 2005-06-20

Part 2 of 2

 

This made me think of that warning on Wilders (I mean the other one). Link here. Well first off, what is it talking about (non-standard protocol)? And what the heck is a "stack" for that matter? LOL. I know it sounds kinda funny but I am serious.

 

I´ve not yet read the whole article, but I do know that a good firewall can pass most of the process injection leaktests, and isn´t the LSP/Winsock area being monitored by MS AntiSpy? Process Guard also comes to mind.

 

Hi Ron,

Interesting article. Can't wait for part 2. Just saw CrazyM's post of part 2.

I assume that any Setiri-like trojan will still be able to bypass with impunity any software firewall it chooses.

One question I have is where is the line drawn with regard to protecting processes and dlls from injection with process protection software vs firewall software? For example, Jetico Personal Firewall vs using Process Guard with Port Explorer from Diamond CS? Should not a firewall be working in conjunction with process protection software in an integrated fashion to shunt attacks?

Is the right question to ask:
Across which software can we layer coordinated functional protection?
vs
In which software do we provide functional protection?

I suppose the key thing is to be able to detect the potential for an attack before it happens and contain it in a honeypot-like facility before the attack can happen.

A multi-layered approach seems the most prudent.

-- Tom

 

Hi,

Firewalls should not be a religion: stealth communications are still always possible.

Others informations from the EEYE newsletters:

http://www.eeye.com/html/resources/newsletters/vice/VI20050504.html#qa1


Regards

 

The comparision "Wall and Straw" is good, but I find the comparision "Fire and Straw" even better.

 

If a program like Ethereal can see all communications, there will be a program (existing or new firewalls based on Ethereal) to protect your PC. Lets hope ....