What's your reaction on this... bout outbound?

Jazzie1 · Jan 7, 2006

Am using Astaro 6.0 myself! And find it to be an excellent firewall! Using proxies for HTTP/HTTPS/DNS/POP3 & SMTP with integrated AV/spyware engines.. No outbound app filtering here. From a network 'point of view' this would be over-kill, especially if half your machines are a unix platform...I agree with Blue on that this some how 'touchy' subject here in the forum. And I guess I am one of those guys who have been posting here for some time and who do AV/AT scans... That is part of it, the other part is your surfing habbits, what activities you engage in, ect... Not to put down App filtering, but too many people are brain washed into thinking it is a protect all, secure all solution. Which it isn't.. I know it could be argued that it is better than 'No' outbound protection, but that is the hype that is posted all over this forum. IE: 'I would feel naked without it!' There are other ways to monitor your applications/services than with an app filtering firewall...

Regards
Jazzie

devlish · Jan 7, 2006

Infinity while I'm not saying you are wrong in wanting outbound protection, and i would guess most people here have it (plus a heck of a lot more stuff)it's surprising that you aren't aware of the arguments raised by myself, Blue and others about this issue.

It's a fully valid and legimate position held as i said by many informed people, and not something I argued just to play devil's advocate.

Infinity said:

at devilsadvocate or devilish:

are you telling me there is no point in having any outbound control what so ever?
Click to expand...

Hmm, Blue and SSk have already answered and I don't think I can improve on their answers. Still let me try.

Your question is pretty loaded. since there is definitely a point if you look hard enough.For example you just want control. So you just want to be as armored as possible and are willing to pay any price, even if the gain is small.

Security wise, as Blue says it's not as important relatively speaking because it's too "downstream" (very good word) with regards to threat mitigiation.

I'm not saying security wise it's useless, as there are definitely some cases where it might help , partcularly if supplemented by extremely tight system , OS control (you know the stuff i'm talking about right?).

But that isn't really an option for 'normal users' (too difficult to use, too painful to use etc) , and in any case, in such setups most of the work is done not by the outbound firewall anyway.

On other hand, most posters on this forum are willing to go the extra mile to be extra safe With process/directory/registry control layers. Once that is in place, outbound control starts to make some sense.

Without such layers in place any malware that starts running can do a dance all over your system, do you really care then if it 'phones home' as part of it's routine if you don't catch all the rest?

Let me quote from the well known security focus article "Software Firewalls: Made of Straw?", which shows how much you must control at least before it's worth using outbound control.

Problems with per-process filtering

There are concerns with this implementation, however. For example, it would be desirable to check whether the process has any modules (DLLs) attached, and if so whether these modules are supposed to be there or not. This makes sense since the code in attached modules will execute from within the context of the process they are attached to, 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. The solution for this requires enumerating the loaded modules, finding their image files (path and filename of the attached DLLs), then checking against a table of modules allowed to attach to that process. Firewalls often check for this and ask whether to allow the module; but obviously this is only a placebo in a sense. The firewall can't possibly know all possible present and future DLLs, good and bad, that might exist, and therefore it is up to the user to guess whether a given DLL is good or not. Yet another concern is whether the process has had its code altered in memory (a process can alter another process' memory region, changing it's code on the fly to alter its behaviour). Or if the process was launched by a malicious program (which would also allow the malicious program to alter the process' behaviour). And the list goes on.

Only a few of these problems are adequately addressed in today's firewalls. The truth is there are simply too many ways for malicious code to disguise itself in order to fool a software firewall's process filtering, ranging from the simple to the very complex. An illegitimate process could patch another legitimate process in memory. It could take advantage of a legitimate program's behaviour, for example by launching a browser with a command line telling it to load a given malicious page. Even in the advent of the process filter scanning for parent-child relationships, multiple levels of indirection could be used (the illegal process could launch cmd.exe with a command line telling it to launch another cmd.exe, which will then launch the browser with the intended page). Or the rogue application could adopt aggressive tactics against the firewall, disabling it altogether, faking mouse clicks to click through the alerts... Remember, anything the user can do, a program can do for him (within this context, obviously).

And all of the above is just focusing on fooling the per-process filter. A whole other world of opportunities opens up when the attacker realizes he doesn't even need to go through the process filter at all. Remember, below the process filter, information about processes is lost. Information just becomes data coming in or out of the machine, and that is as it appears to the other filter, the packet filter. All the attacker has to do is use a driver to inject the packets below the level where the process filtering is being done, and then he only has to worry about the packet filter. As long as he uses an already allowed port (say port 80, 25, or whatever), the packet filter will happily allow it. Not even to mention the possibility of just going under the packet filter...
Click to expand...

Okay say you have a firewall that handles all these issues, maybe ZA pro and Outpost Pro (hello Paranoid2k!) come closest , and you build this "system/OC firewall structure" which comes at a high cost of user complexity. Is the cure worse than the disease?

And in the end, what exactly is saving your butt? The OS system control or is it your outbound control?

Log in or Sign up

What's your reaction on this... bout outbound?

Jazzie1 Registered Member

devlish Guest

Log in or Sign up

What's your reaction on this... bout outbound?

Jazzie1 Registered Member

devlish Guest

Useful Searches