best software firewall?

I don't know. I am admin on the machine as most programmers are admin.

Secondly, most home users with the XP O/S or any NT based O/S run with admin rights on the machine in spite of being told not to do this. This doesn't hold true for users that don't need admin rights on the machine in a corporate environment. The machine is setup with them not having admin rights by the support staff.

With that being said, for those that run on the Internet with admin rights with the XP FW, if malware can get there and can be executed, it can easily make the registry change to disable the XP FW. And on the reboot of the machine the end-user would not even know that it was down.

I just don't like this situation with a PFW solution. Granted, all the solutions can be taken out, but this one on the XP O/S with XP's FW is too simple to do.

Duane :)

So far many security flaws in Windows have been random errors, e.g. program errors or misconfiguration, because people make mistakes even with good intentions and such things cannot generally be avoided. They can be fixed by replacing the code or reconfiguration.

Outpost has some systematic error, which was introduced by an intentional design decision, which is absolutely avoidable and should especially not occur for a security-relevant software. It cannot be replaced without rewriting a major part of the relevant code, and most likely breaks something.

OK, and where's your argument? I'd call it a collary.

There's no reason to make it any more complicated, this would just increase complexity. It's always easy to take it out, even when, or better said, especially when made complicated.

What I think is really happening is somehow the .NET Framework has something to do with this, because this .NET solution with several projects was compiled and executed within the .NET IDE.

The .NET machine configuration is looking at this application as a trusted application, for the exe. The remote server portion of this application was complied to a DLL and I don't think an exception rule was made for it in the XP FW for it, even though this entire .NET Remoting application was running on my development machine. The remote server could not be contacted for whatever reasons.

The argument there is it interfered with my development and debugging process with this .NET solution on my own development machine, which until this point, no developer even knows how to develop a .NET Remoting application and no one realizes that this is a problem.

Well, I did what the tech support people indicated to do, which was disabled the XP FW and whatever else was in the way of me running and debugging the application in the .NET IDE.

If they had told me and gave info on what I needed to do, I would have used that too.

Anyway, the XP FW is out of the way and I am happy.

Duane :)

Where do you people get off thinking that something is some kind of an debate. Really, is this how people think over there in Europe? If this is the case, then no wonder people try to take each out out every century or two over there.

It shouldn't be in the registry. Maybe, one day the FW will be under the control .NET where it doesn't need the registry to do anything.

But I doubt that's going to happen.

Duane :)

Have fun if someone hacks through your computer if it is not well protected.

I don't understand your point. If there are enough rights (and admin rights are enough for all AFAICS), then you may configure your computer.

Admin rights are _intended_ to be enough to configure the computer.

To configure things, it should be as easy as possible. Why making things complicated?

If you have admin rights, you can configure the packet filter, too, because you can configure everything. "This behaviour is by design".

Yours, VB.

Running out of arguments and offending all people in Europe to detract from?

VB.

Again, what argument or debate are you talking about? I am not out here to debate and make an augment about anything. You and the rest may think this is what NG(s) and the Internet are about. I don't beckon to it or look for it. I got better things to do.

And, yes every opinionated lunatic that I have encounter out on this Internet trolls alike have been out of Europe and I am not going to back away from that.

They are a dime a dozen. But does this mean that I include all people in Europe in that category, no -- only some. But can I see why people over there will go to war over the centuries in Europe at the drop of a hat, you bet I do.

Duane :)

The point is with me wanting to write malware if I choose to do that to knock out that XP FW, if I could get the program there and it was executed. This doesn't seem to be that hard with most home users with the happy fingers that click on everything under the Sun, while running with Admin rights.

In certain areas yes. But not with something that can be a risk, the very things you talk about with IE and OE.

In the wrong hands, those solutions are a risk and are a vector that can be used to attack a machine because of their power, ease of use and ability to be programmed easily to do it, along with these solutions being used in the wrong user's hands.

So why not apply your views to the O/S? Nothing that critical should be that easy to do and that easy to attack, not if it's supposed to be an integrated solution with the O/S as the XP FW is supposed to be.

That doesn't mean that it can't be done by someone configuring the machine that knows what he or she is doing. But as I would suspect that you know, a vast, vast, vast majority of MS users don't have a clue about configuring anything, other than they need to run on the Internet with admin rights.

Hopefully, some of this will change over the years as the .NET Framework is supposed to step in and assist in the protection of the O/S with code that is managed by .NET that will not allow destructive code behavior, doesn't need the use of the registry and .NET has its security implementations that can be applied to a machine as well.

But of course, that remains to be seen.

This is not an argument or debate and don't make it into one. ;-)

Duane :)

Thank you for that opinion. me

Then I don't understand, why you're thinking you're needing to offend. I know, Sebastian sometimes is very hard to read, and, yes, he's offending, too.

But why offending a large group of people, when you're angry about a single person? Think about it, please.

Yours, VB.

Perhaps we have a different view then, because if I would write malware, I would write a root kit only, and if this is started with administrator's rights, then I would not need to switch off anything, because nothing could be in my way anyways.

Yes. And this is the point to change. They should not run their machine as administrator. While Microsoft delivers the OS with doing so as default, nothing ever will change.

Hey, this is an interesting topic to discuss. Why not throwing arguments into this discussion? ;-)

Yours, VB.

Of course it should. What would be more suitable than a well-cached globally accessable and configurable database?

Eh, what about making .NET secure first?

Which is true for every other security software. Your point being?

Well, shouldn't they make .NET secure first?

Who cares? Malicious code can circumvent those easily.

That would be news. The .NET runtime isn't documented to do such a thing.

Documenting the used ports is the job of the programmer, reading the documentation and allowing those ports is the job of the administrator.

However, a program might assist by using both the IPHelper API to open the port at XP ICFW and UPnP to do so remotely with UPnP-capable devices. And a good administrator should disable such functionality.

At the point was that ShieldsUp doesn't help you with protection. If you want to audit a packet filter, use some serious port scans like .

Anyway, one usually doesn't need any packet filter for protection.

Beside that, ZoneAlarm doesn't offer any protection either.

Then you just don't understand the difference.

This tells me that you don't know the first thing about .NET.

Duane :)