Is a software firewall such as Zone Alarm essential for added
protection if I am already using the XP firewall, AVG antivirus (free)
and have a wired router (D-link-524)? Will it offer me any additional
protection? If so, is there a better free firewall than Zone alarm?
Thanks.
Post removed (X-No-Archive: yes)
Dickie Peters
> Is a software firewall such as Zone Alarm essential for added
> protection if I am already using the XP firewall, AVG antivirus (free)
> and have a wired router (D-link-524)? Will it offer me any additional
> protection?
I cannot see anything in the common "Personal Firewall" products, which
is not useless if not counterproductive.
Yours,
VB.
--
"Pornography is an abstract phenomenon. It cannot exist without a medium
to propagate it, and it has very little (if anything at all) to do with sex."
Tina Lorenz
"Dickie Peters"
news:3c78r2hh7f4cksa4qpjnuugldbf36lm3v4@4ax.com...
> Is a software firewall such as Zone Alarm essential for added
> protection if I am already using the XP firewall, AVG antivirus (free)
> and have a wired router (D-link-524)? Will it offer me any additional
> protection? If so, is there a better free firewall than Zone alarm?
>
> Thanks.
Your router, AVG free and Mozilla Firefox are all you need.
Zone Alarm and all other 'personal firewalls' are not fireewalls at all,
they are all garbage!
Visualize these two scenarios:
-1
You install ZA or some other similar crap, then you start your browser. Your
'firewall' pops up a message asking you if you wish to allow the browser to
access the internet and tells you a whole story about how dangerous that can
be. You want to be safe and tell ZA to keep blocking it, but decide to keep
your browser anyway because it has a cute icon.
Then, you start your email client and you get another message asking you if
you wish to allow it to access the net. You want to stay safe and tell ZA to
keep blocking it, then you go to the nearest bookstore and buy all the books
on telepathy, since you can't use electronic mail any more.
You pop an audio cd in your drive and Windows Media Player tries to retrieve
info on that cd to display it for you. But, ZA stops it. Then, you try to
play an online game and ZA tells you it's not safe and you allow it to block
the game.
At the end of the day, after you allowed ZA to control you life, you ask
yourself:
Why the fuck am I paying for internet access?
-2
You install ZA or some other similar crap, but this time you allow
everything to access the internet, because you need to browse and
communicate, etc...
At the end of the day, you ask yourself:
Why the fuck did I install Zone Alarm?
Post removed (X-No-Archive: yes)
"Sebastian Gottschalk"
news:51lrggF1kkmecU1@mid.dfncis.de...
> Jack wrote:
>
> [why ZoneAlarm is crap]
>
> -3 It's broken, totally broken, just like any other PFW. Most recent case:
> Computer A had ZoneAlarm running. A could ping B, but B could not ping A.
> ZoneAlarm got deactivated, still didn't work. ZoneAlarm got uninstalled,
> everything worked fine.
That wasn't so bad, I have recently tested close to 100 different pfw's,
looking for one that blocks outside intruders, not me. Some of them screwed
up my settings and left them screwed up even after uninstall. Luckily, I
wouldn't test any crappy software without a fresh Ghost image.
The only software firewall that does what it should do, detect an attack and
give you the option to block the offending IP, was Black Ice. It's a shame
it crashed my email server every five minutes.
I got a better router in the meantime and I'm happy.
Post removed (X-No-Archive: yes)
"Sebastian Gottschalk"
news:51or4eF1lc5h4U1@mid.dfncis.de...
> Whaout about some serious HPBF implementation for Windows like Wipfw,
InJoy
> Firewall or the Windows Firewall? Or what about not using any packet
filter
> at all?
As cheap firewalls go, I'm fond of the Kerio Enterprise firewall, which
seems to give you a Checkpoint style rule interface and about 40% of the
capability of Checkpoint, but at about 1/8th the price. Around $350 /
computer, wish it were less.
Agreed that the ZoneAlarms of the world are so anxious to be cute, and so
targeted at not stopping the truly stupid user, that they are nearly
completely worthless to anyone who understands networking.
--
Will
Will wrote:
> "Sebastian Gottschalk"
> news:51or4eF1lc5h4U1@mid.dfncis.de...
>> Whaout about some serious HPBF implementation for Windows like Wipfw,
> InJoy
>> Firewall or the Windows Firewall? Or what about not using any packet
> filter
>> at all?
>
> As cheap firewalls go, I'm fond of the Kerio Enterprise firewall, which
> seems to give you a Checkpoint style rule interface and about 40% of the
> capability of Checkpoint, but at about 1/8th the price. Around $350 /
> computer, wish it were less.
>
> Agreed that the ZoneAlarms of the world are so anxious to be cute, and so
> targeted at not stopping the truly stupid user, that they are nearly
> completely worthless to anyone who understands networking.
If you had been following the ramblings of Sebastian, you'd know that,
in his eyes, there are *NO* effective software firewalls.
LQTM
--
Notan
Post removed (X-No-Archive: yes)
"Sebastian Gottschalk"
news:520r9pF1lj97qU1@mid.dfncis.de...
> > which seems to give you a Checkpoint style rule interface
>
> and a horrible ruleset expressiveness.
Which routing firewalls do you like that have a GUI configuration interface
and cost under $900?
> > and about 40% of the capability of Checkpoint, but at about 1/8th the
> > price. Around $350 / computer, wish it were less.
>
> And Wipfw is for free. Now, what's your point? If you're not going to
> build a routing firewall but merely want a host-based packet filter, I'd
> say that Kerio Enterprise is total overkill.
I would always want a firewall to have some level of stateful inspection.
Packet filters that don't even attempt to see who started the connection are
pretty easy to defeat.
For my own use, I prefer routing firewalls since I tend to use virtual
machines a lot and those get put on separate subnets behind my computer.
I'm certainly not bragging that Kerio Enterprise is the best routing
firewall. It's just good value for the buck, for protecting workstations
or low end applications behind a main firewall. I certainly do see a lot
of room for improvement, and I'm certainly open to suggestions about what is
better, without spending Checkpoint or ISA prices.
--
Will
Post removed (X-No-Archive: yes)
In article
usc@noemail.nospam says...
> "Sebastian Gottschalk"
> news:520r9pF1lj97qU1@mid.dfncis.de...
> > > which seems to give you a Checkpoint style rule interface
> >
> > and a horrible ruleset expressiveness.
>
> Which routing firewalls do you like that have a GUI configuration interface
> and cost under $900?
I see that SG didn't answer your question when he replied, he is really
good at ignoring questions and Side-Stepping them.
In the under $400 market, I would pick a DFL-700 device.
In the under $900 market, I would pick a WatchGuard X55e (about $920)
and then a X20e for a small shop (20 users, about $600).
--
spam999free@rrohio.com
remove 999 in order to email me
On Sat, 27 Jan 2007 22:15:49 -0800, "Will"
wrote:
>"Sebastian Gottschalk"
>news:520r9pF1lj97qU1@mid.dfncis.de...
>> > which seems to give you a Checkpoint style rule interface
>>
>> and a horrible ruleset expressiveness.
>
>Which routing firewalls do you like that have a GUI configuration interface
>and cost under $900?
www.pfsense.com
greg
--
"He's raising an unholy army of singing dinosaurs!"
On Sun, 28 Jan 2007 12:47:22 +0100, Sebastian Gottschalk
wrote:
>> Which routing firewalls do you like that have a GUI configuration interface
>> and cost under $900?
>
>I would not build any firewall upon Windows.
That's your problem.
Security is a process, not a product,
Those of us who work in the real world have deployed and supported FW1 on
NT for the better part of a decade. (Not my 1st choice as a checkpoint
platform, but that's a client decision, some sites do not tolerate Unix in
any shape or form).
Those of us who work in the real world have evaluated ISA 2k4/2k6 and found
a lot in there to like.
It usually takes MS about 3 attempts to get something approaching right &
in the case of ISA 2k4/2k6 it's a very capable enterprise grade firewall
solution.
If MS did the right thing and made EMC an offer for rainwall/rainconnect
they couldn't refuse , it would IMHO be a viable option for a multitier
solution in any enterprise sized MS shop.
greg
--
"He's raising an unholy army of singing dinosaurs!"
"Sebastian Gottschalk"
news:523gq8F1ml9pmU1@mid.dfncis.de...
> > Packet filters that don't even attempt to see who started the connection
are
> > pretty easy to defeat.
>
> Nonsense. What difference should it made, except adding more potentially
> vulnerable code?
Let's say you want to create a firewall rule that allows the host behind the
firewall to make DNS queries going to the Internet.
A firewall that tracks who initiated the request and looks for the response
to come within a certain time period would allow a rule that specifies the
source host or network behind your firewall and the destination as the
outside network, using DNS UDP 53. The firewall would reject UDP 53
queries coming from the outside in unless the firewall's state table could
match those packets to an appropriate outstanding request.
To contrast, a stupid packet filter defines simple rules for for DNS queries
that allow destination port 53/UDP out and source port 53/UDP in. If
there is no internal state table that keeps track of queries that originate
from your internal network, any intruder can bypass your firewall simply by
using a source port of 53 and sending the data as a UDP packet. There are
lots of routers and simple packet filtering firewalls that implement designs
not much more sophisticated than that.
> > For my own use, I prefer routing firewalls since I tend to use virtual
> > machines a lot and those get put on separate subnets behind my computer.
>
> This sound even more nonsensical, since this both wouldn't provide any
> protection and can't even work.
Do you always have the habit of making assertions without submitting any
form of evidence or reasoning? At very least try. You may not be able to
control the fact that you are disagreeable to every idea, but you could at
least try to make yourself effective in the process. Otherwise your posts
all come across as just grumpy emotional displays, no factual information
provided.
It works just fine. You define virtual adapters that are private networks
between the firewall host and the virtual computer. Routing is turned off
on the box, and all traffic must pass through the routing firewall. The
routing firewall sees the virtual adapter as it would any physical adapter,
and you can construct host and network based rules, NAT rules, whatever,
that use those virtual adapters. I've tested such firewalls with packet
constructors like HPing3 and while they are not great they are a whole level
beyond what host based packet filters like ZoneAlarm can do.
It also works more securely than a host based packet filter. There are
lots of published mechanisms for circumventing software based firewalls that
run on the same OS as the application you are trying to constrain. You can
circumvent a firewall that runs on the same host OS as your application by
playing games with how the OS APIs are called, installing rootkits, etc, on
the OS. If the software you are trying to constrain or publish out runs on
a different OS on a virtual computer, and your firewall sees that traffic on
the wire as it would a separate physical computer with a separate ethernet
network, there is a lot less the application can do to bypass the firewall
rules. If it is a virus it can malform packets, but most commercial
applications don't do that. So there are just fewer tricks that can be
used to circumvent the firewall.
--
Will
Post removed (X-No-Archive: yes)
Post removed (X-No-Archive: yes)
On Mon, 29 Jan 2007 12:25:38 +0100, Sebastian Gottschalk
wrote:
>> Security is a process, not a product,
>>
>> Those of us who work in the real world have deployed and supported FW1 on
>> NT for the better part of a decade. (Not my 1st choice as a checkpoint
>> platform, but that's a client decision, some sites do not tolerate Unix in
>> any shape or form).
>
>And if you had real experience, you could build any type of firewall on any
>OS. And then, if no such stupid "no Unix" constraints are given,
Only someone who has no clue regarding operational risk could make such a
ridiculous statement.
>BSD+ipfw/pf or Linux+netfilter would be the best choice, for obvious
>reasons.
Don't teach your grandmother how to suck eggs.
Show me a 'free' solution which can dynamically filter soap/xml/rpc *and*
doesn't require command line hackery to manage.
Show me the netfilter/pf solution that can dynamically fixup and sanitise a
huge range of application protocols other than basic FTP.
Again you have demonstrated a lack of real world experience, client
requirements extend far beyond mere L3 packet filtering.
>And, depending on your company's policy, you should really consider not
>working for clients which demand firewalls on Windows, since it's not worth
>the risk.
Considering that you have singularly failed to quantify that 'risk' in
anything resembling terms other than emoting hearsay, I'll treat your
advice with the due consideration it deserves.
>> Those of us who work in the real world have evaluated ISA 2k4/2k6 and found
>> a lot in there to like.
>>
>> It usually takes MS about 3 attempts to get something approaching right &
>> in the case of ISA 2k4/2k6 it's a very capable enterprise grade firewall
>> solution.
>
>ISA is pretty much based on the integration to proprietary Windows
>protocols that can't be easily handled by other firewall products or would
>require separate hosts (even if virtual).
Oh puhleeze. Enough with the bullshit already, you clearly do *not* know
about the commercial products under discussion.
greg
--
"He's raising an unholy army of singing dinosaurs!"
Post removed (X-No-Archive: yes)
"Sebastian Gottschalk"
news:5265n5F1kljvhU1@mid.dfncis.de...
> > To contrast, a stupid packet filter defines simple rules for for DNS
queries
> > that allow destination port 53/UDP out and source port 53/UDP in.
>
> I just underlined where you got it wrong. Stateful filtering has nothing
to
> do with identifying processes.
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: <1%
chance of bypassing the firewall.
Now assume costs for the above are:
Approach 1: $90
Approach 2: $400
Approach 3: $1500
And the above doesn't calculate the additional costs for hardware and
administration of hardware with approach 3, which make it MUCH more
expensive.
So if you have unlimited money, go with Approach 3. But Approach 2 is at
least decent protection, particularly given the cost savings.. Approach 1
is a complete joke.
> > If there is no internal state table that keeps track of queries that
originate
> > from your internal network, any intruder can bypass your firewall simply
by
> > using a source port of 53 and sending the data as a UDP packet.
>
> And if there is, he can tunnel through DNS. Your point being?
My point being that I want protection from kiddy hackers. It takes a very
sophisticated intruder to try to tunnel back into your network during the 5
to10 second windows of opportunity that are opened during the return packet
state from an outgoing UDP request.
You can never remove all risks. But with limited resources you at least
want to be able to get rid of the 95% of the jokers out there who download a
few packet shapers and try to do easy probes.
> 1. Virtual machines share the same physical interface.
No, the virtual machines can be configured (not a default!) to each have
dedicated virtual adapters. It's pure software, nothing physical and
nothing shared. I have a firewall for example with six virtual machines,
and each of those has a separate class c network on a separate virtual
adapter.
Yes, the external interface is shared, but that's not different than any
physical firewall. At some point all packets get to a firewall that acts
on them and those packets go out a single shared external interface.
> 2. If you're using bridging, you're hosed.
Which is why you never use bridging....
> 3a. If you're providing NAT throught the VM monitor, the firewall can't
> work since it doesn't know about the NAT states, or can't provide any
> security because you have to emulate that behaviour in an obviously
> insecure manner.
> 3b. If you're providing NAT through the firewall, then the VMs won't get
> any connection.
> 3c. If you're providing NAT through both mechanisms, you still have the
> problem of the tow mechanisms not knowing the states of each other, so
> you'll either get it insecure or non-working.
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.
> Virtual Machine A opens a TCP connection with src.ip=192.168.1.1
> src.port=3000 to dst.ip=12.34.56.78 dst.port=80. The NAT mechanism of the
> VM translates if to src.ip=192.168.100.1 src.port=1040. Then it gets
passed
> through the routing firewall, which translates it to src.ip=78.56.34.21
> src.port=1040.
>
> The connection times out, VM A drops the connection and the VM NAT
> mechanism deassociates the NAT state.
>
> Not the physical host opens a connection with src.port=1040 and creates a
> connection to 12.34.56.78:80 as well.
>
> Now an answer to 78.56.34.21:1040 is received.
>
> Question: What should the routing firewall do?
> a) forward to the virtual interface of VM A
> b) forward to the program running on the physical host
> c) drop the packet
>
> Hint: Neither is right. From a security perspective, one would choose C,
> but then you'd have fucked up the network. If you don't choose C, you're
> trivially getting insecure.
>
> I guess you be able to construct a similar scenario for the case of port
> forwarding being utilized.
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.
> They share on physical interface, and the host is supposed to be secured
as
> well. That's why this often heard idea fails so blatantly.
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.
--
Will
On Mon, 29 Jan 2007 18:44:51 +0100, Sebastian Gottschalk
wrote:
>Greg Hennessy wrote:
>
>>>And if you had real experience, you could build any type of firewall on any
>>>OS. And then, if no such stupid "no Unix" constraints are given,
>>
>> Only someone who has no clue regarding operational risk could make such a
>> ridiculous statement.
>
>What are you referring to? Calling the constraint stupid? Well, it
>certainly is.
Oh puhleeze, peddle the old time religion somewhere else.
>And has nothing to do with operational risk, for obvious
>reasons.
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.
>
>>>BSD+ipfw/pf or Linux+netfilter would be the best choice, for obvious
>>>reasons.
>>
>> Don't teach your grandmother how to suck eggs.
>>
>> Show me a 'free' solution which can dynamically filter soap/xml/rpc *and*
>> doesn't require command line hackery to manage.
>
>This "command line hackery" as you call it is exactly why you can utilize a
>wide variety of management tools, including graphical ones.
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.
> Just show me
>one "non-free" solution that could compare to the management of large
>networks with ShoreWall.
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.
>> Show me the netfilter/pf solution that can dynamically fixup and sanitise a
>> huge range of application protocols other than basic FTP.
>
>Well, netfilter. I just looked at the list... weeh, more than 900 helper
>modules for netfilter.
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.
> Including one for such nasty stuff like H.323 which
>you can find no-where else.
Oh gawd. Open your eyes puhleeze. Crisco, Checkpoint and Netscreen can and
do fixup 323 and other voip protocols.
>> Again you have demonstrated a lack of real world experience, client
>> requirements extend far beyond mere L3 packet filtering.
>
>I never claimed anything in this way.
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.
>But well, as you may understand, most
>L7 protocol filtering is done using proxy firewalls.
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.
>
>>>And, depending on your company's policy, you should really consider not
>>>working for clients which demand firewalls on Windows, since it's not worth
>>>the risk.
>>
>> Considering that you have singularly failed to quantify that 'risk' in
>> anything resembling terms other than emoting hearsay, I'll treat your
>> advice with the due consideration it deserves.
>
>sizeof(Windows_installation_stripped_down) = 300 MB+
>sizeof(Linux_from_a_scratch+netfilter) = 1 MB
>
>I rest my case.
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.
> You really don't understand how much overkill and
>complexity a Windows installation provides, and how hard it is to properly
>secure it just on its own.
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.
>>>> Those of us who work in the real world have evaluated ISA 2k4/2k6 and found
>>>> a lot in there to like.
>>>>
>>>> It usually takes MS about 3 attempts to get something approaching right &
>>>> in the case of ISA 2k4/2k6 it's a very capable enterprise grade firewall
>>>> solution.
>>>
>>>ISA is pretty much based on the integration to proprietary Windows
>>>protocols that can't be easily handled by other firewall products or would
>>>require separate hosts (even if virtual).
>>
>> Oh puhleeze. Enough with the bullshit already, you clearly do *not* know
>> about the commercial products under discussion.
>
>I do.
You dont, it's painfully obvious that your exposure to anything other than
soho solutions to security infrastructure delivery is extremely limited.
greg
--
"He's raising an unholy army of singing dinosaurs!"
Post removed (X-No-Archive: yes)
Post removed (X-No-Archive: yes)
On Mon, 29 Jan 2007 21:51:36 +0100, Sebastian Gottschalk
wrote:
>> You haven't answered the question.
>>
>> Show me the free out of the box pf/ipfw/netfilter solution which can filter
>> soap, xml & rpc.
>
>ShoreWall. Redhat Enterprise Firewall Server. All the flavors are belong to
>you.
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
--
"He's raising an unholy army of singing dinosaurs!"