Let us revisit your five bullet points
- 1. Executable modification detection is not the job of a packet filter firewall, but more in the area of a HIPS. This is material for a different discussion.
- 2. You can click "Allow", but this requires a UAC transition (at least on Win7 - I'd be surprised if it doesn't on Vista). UAC transitions can't be scripted[/sup]1[/sup].
- 3. The packets have "entered your computer" but haven't hit applications yet. This is the purpose of a packet filter: to avoid service exploitation2. Somebody more clever than me can comment on the implementation, but I'll highlight that "If the traffic does not match an exception, the NAT driver determines that the traffic is unsolicited; the packets are dropped and do not continue through the TCP/IP stack".
- 4. I assume you're talking "outbound leaking" here. Ultimately, there's nothing you can do to stop outbound leaking, whether on the individual host or an external boundary firewall, short of blocking all outgoing traffic3. This is topic for a whole separate discussion, though; my stance is that when you need outbound filtering you're pretty much game over, but it can help mitigate some attacks. And if you only need to defend against usermode code, you can do a lot.
- 5. If you're reckless and run in admin mode without UAC: yes - otherwise: no.
1: I know of no way to script UAC transitions when running with UAC on max settings, which is what you should be doing. I'm not excluding the possibility that there's bugs that will eventually be found, but so far we don't know of any.
2: yes, it's possible that the packet filter itself has bugs, just like everything else - including your "hardware" firewall firmware.
3: no, really. An external firewall knows nothing about applications, and can only judge on packet data. Make an outgoing HTTPS connection and you can't do much traffic inspection except looking at destination.
You've come up with one thing so far, which is more than three years old, limited to XP, and requires the ICS service to be on (which it isn't by default, as far as a lazy google says).http://en.wiktionary.org/wiki/potential
That's the best you can do? Nice move ignoring the iptables link, which sounds like it could potentially
be a lot worse than the cry-wolf XP bug. Yep, it was serious, if you had enabled ICS
- not something most home users do... and the resources I've seen say that server editions weren't affected.
Some are "better" however.
"Secure by Default" is a very nice goal, and MS has
been sleeping in class. The XP-SP2 firewall and DEP
were steps in the right direction, UAC was a major
step (too bad default user wasn't made non-admin alread in Win2k). And then there's ASLR
and a whole bunch of enhancements to the heap manager, not to mention various security enhancments in the Visual C++ compiler. None of this by itself is perfect, but it shows that MS certainly aren't ignoring the problem any longer - and you get a lot of stuff with NT now that you don't get with linux unless manually choosing a kernel with SELinux patches.
Of course you can configure *ix to be insecure, of course you can even have a secure Windows XP server or something. The software running on the server is the bottleneck - and now we're on topic again. The one who installs and maintains the software is responsible for it to work properly. If he fails, not even a firewall of any kind can help him. If he succeeds, he doesn't need paranoia. There might be something in between. Does it really matter?
Well, duh, isn't this what I've been saying all along? Except for the "doesn't need paranoia" part... a packet filter isn't paranoia, it's an additional level of security
. Hopefully it'll never be needed on neither hosts nor servers, but if you have a breach it can
save your ass - and I bet you aren't able to measure a performance difference whether it's enabled or disabled.
So what, really? Windows isn't unix, things work differently.Now this is not a reason for having to use a rather mediocre shell, is it?
If you don't need
something complex, why waste time developing it? *u*x and Windows are different philosophies. Apparently enough users wanted a more powerful shell, and MS responded with PowerShell. Haven't used it myself so I can't comment on it's quality.
By this, you're saying that packet filters which require administrative privileges to configure are useless... to me. Maybe there are some rare circumstances that might be easier to handle with something like a "packet filter". Using such does not necessarily make your system more secure, though.
Ah, now you're talking a lot more sense. But let us revisit your original statement, which is what got this started:
Disable Windows Firewall - And there it is!How many reasons why the Windows "Firewall" is neither a firewall nor of any use would be enough to convince you that disabling it is a good idea? I think I could find dozens of them.
...see a slight difference between those two statements?
ICS is disabled by default, and the only unscheduled reboots in the last 10 years on the (approx 20) Windows servers I manage were due to either hardware failures or power outages that outlasted the UPS.
Do you have a clean & untweaked XP-SP2 you can confirm this on, or official docs?
- I'm almost tempted to do a test install in vmware (damn insomnia!), but it'd make a helluva lot sense not to have it enabled by default.