1. Home
  2. Networking Firewalls
  3. Is Firwall necessay?
  4. Page 2

Is Firwall necessay?

Just to be clear, I *agree* with you that a software firewall that runs on the same host as the application is a bad solution. But if the application runs on a virtual machine you have isolated the application's code and the kernel associated with it from the OS that runs the firewall.

Can you imagine a driver that runs as a rootkit trojan in a virtual machine, that then exploits a processor misfeature/bug to get into the memory space of the host OS? Probably yes. Will they prevent that eventually by some capability in the processors? Probably. In any case, it's a lot more secure to isolate the application in a virtual machine than to run it in the same application space as the firewall. You open up lots of possible tricks to work around the firewall.

I don't know what the real risks are, but my own subjective guess would be that if you have a properly configured firewall, and then introduce a rootkit trojan onto the host that runs the application you are firewalling, you have these percent chances of having the firewall stop its activity:

Approach 1: Software based firewall like ZoneAlarm: 90% chance that the Trojan bypasses the firewall completely.

Approach 2: Isolate the application into a virtual machine and the virtual machine gets the infection: 10% chance that the Trojan bypasses the firewall completely.

Approach 3: Isolate the application onto a separate physical computer that is attached by a dedicated ethernet segment to a separate firewall: problem of the tow mechanisms not knowing the states of each other, so

Excellent and true, which is why you never use the NAT adapter.... You create virtual *private* networks, and connect those to a routing firewall that runs on the host computer.

If you have a VMWare installation, try to go create a virtual private ethernet by using the separate "Manage Virtual Networks" application. Nothing like adding six dedicated class C networks to a network and getting it all "wired up" in about 20 minutes.

If the return ACK from the original TCP SYN doesn't reach the host firewall within the timeout, then the packet is dropped. Why would it be otherwise?

If it was otherwise, then yes that would be a bad thing and it would be a bug in the firewall or possibly bad firewall rule design.

The virtual machine does not "see" the physical interface. The virtual machines don't share it. The host has exclusive view and use of the external interface, just like in any real firewall.

Reply to
Will
Loading thread data ...

Oh puhleeze, peddle the old time religion somewhere else.

With respect, you dont know what the term means. From an operational risk perspective it is far preferable for an organisation to manage something it knows how to do properly than to attempt to manage something it knows little or nothing about. The potential risk of loss is a lot smaller.

You haven't answered the question.

Show me the free out of the box pf/ipfw/netfilter solution which can filter soap, xml & rpc. Pointing to an unsupportable netfilter hack someone has posted on sourceforge doesnt cut the mustard in an enterprise environment.

BWAHAHAHA! Oh Jesus wept... Shorewall .... Look do yourself a favour, I'll give you some hints Cisco Security Manager, Checkpoint Provider-1, Netscreen Security Manager just to name 3. Your lack of knowledge on the topic is just too embarrasing for words.

You dont comprehend the change management constraints which enterprises operate under.

The notion that risk management in any large organsiation would even contemplate permitting the roll of out netfilter 'helper' modules across a global network to selectively filter SOAP & RPC is hilarious.

Never mind rolling out hacks which run application layer filtering in kernel space.

Oh gawd. Open your eyes puhleeze. Crisco, Checkpoint and Netscreen can and do fixup 323 and other voip protocols.

Of course you did, you insisted

"BSD+ipfw/pf or Linux+netfilter would be the best choice, for obvious reasons."

without having any idea of what the client requirements were.

Again you make authoritiative claims without having a clue of the real world capabilities of the products in the market place. In the real world, there are 3 main players, Crisco, Juniper and & Checkpoint. They all provide L7 filtering in various forms.

The notion that

"*most* L7 protocol filtering is done using proxy firewalls"

is arrant nonsense.

ridiculously irrelevant. Show me a 1 meg LFS floppy disk with support for say OSPF, BGP, sparse PIM which can dynamically route several hundred market data feeds delivered though trunks running into a Cat 6509.

By that reasoning the same fallacious 'point' would apply to Splat Pro or Solaris.

Windows Server is *not* hard to secure. Whether you choose to believe that is not my problem.

You dont, it's painfully obvious that your exposure to anything other than soho solutions to security infrastructure delivery is extremely limited.

greg

Reply to
Greg Hennessy

ShoreWall. Redhat Enterprise Firewall Server. All the flavors are belong to you.

Put an IBM sticker on it. The management will be satisfied.

Ugly, ugly² and ugly³.

Then save those for yourself. Might be a wise consideration.

I wonder where you want to draw the line to the even dirtier solutions you're talking about.

I was talking about working protocol parsers, not just some half-working cheap hacks.

Nonsense. Where?

The most important requirement of a firewall is to provide security on a network boundary. And with security comes avoiding complexity.

Sorry for specifying "sane approach of".

Then 2 MB, mainly for the sparse PIM. (WTF? Does this belong to a firewall?). Kernel is 0.5 MB, OSPF and BGB support are 200 KB and the thrunk's interface driver is 100 KB. I'd say this fits well.

Agreed for Solaris, this is really a monster as well. Even though not a monstruos as Windows.

Well, see above. It seems like you really like underestimating complexity.

... says someone who doesn't even know the extensive variety of management solutions for Unix systems which are mostly based upon pf, ipfw or netfilter in the core.

Reply to
Sebastian Gottschalk

And a lot more unusable. Ever tried copy & paste? What about opening files? Programs are doing IPC for good reason. And once you begin to share data between the VMs, you're likely to copy the compromised data and infect another VM (or even the host).

What about Approach #4: Do not get the malware executed in first place?

The don't run the malware.

No. It's simply program code, readily available from the internet and already integrated in the most favorite trojan horses.

That's where #3b or #3c applies.

You already forwarded the SYN/ACK to the wrong interface. That's already bad.

Oh, not to mention UDP, which is somehow connection-less.

No. The host uses the physical interface for his own purposes, as well as providing network connectivity to the VMs.

Reply to
Sebastian Gottschalk

Oh for crying out loud, not this nonsense again.

RHES is *not* free.

Netfilter on RHES does *not* filter soap/xml or rpc. Blocking ports at layer 3 is does not constitute meaningful filtering, especially when soap is delivered over 80/tcp.

If you actually had any experience of the subject matter, it would be painfully obvious that I am referring to filtering RMI , schema checking & tracking UUID endpoint maps.

The fact that you appear to be unable to conceive of a use for multicast routing on an edge security device is further proof that your level of real world exposure to network security design & implementation is limited to say the least.

greg

Reply to
Greg Hennessy

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.