I hate it when that happens myself (luckily it hasn't happened to me here in several months). Okay, just requesting clarification as to which subset you were referring. Just quickly re-checked my numbers for the last month. Well over 70% of the probes I see can be immediately ascribed either to my ISP, Worms, or P2P. Half of the remainder all skiddies, in all probability. It's only after digging through all this that the truly interesting stuff turns up. But I think your last statement is the interesting one! (I was trying to hold this back, but I suppose I might as well mention it now.) Yes, it's the record that I find interesting. And relying on ICS produces no record (a hardware router could be enabled to do so, of course). It's that ability to peer under the hood and see what's happening that I find so interesting, but many of the PSFs are sorely deficient in this capability and we have to rely on third-party log analyzers to do this. Indeed, for those who haven't already picked up on it, that's one of the reasons I stopped with NIS 3/4 -- in those contexts I have a good log analyzer; in NIS 6, the capability is pitiful. Of course, an IDS would also provide this capability (and even better, I might add), but they're not well understood (apparently) in the community at large. Yes, and no. Sure, they'll ride in if you give them the chance on IM programs, P2P programs (including, now, the RIAA, I note), chat utilities, but they will also ride in on your newsreaders, e-mail clients and even your browser -- if you give them a chance. For the most part, a traditional firewall (hardware or software) isn't going to stop this. And when I say 'traditional firewall', I'm talking about what CrazyM brought up in another thread, not one of the 'latter day' firewalls with all sorts of additional bells and whistles. If you Internet-enable Windows Explorer (especially the good ole web folders), your word processing or spreadsheet or DBMS app, they'll be perfectly happy to ride in on those, too! It's not necessary to give these applications 'server rights' for them to do this, either. (And I fear that far too many PSF users think that's the magic bullet to avoid.) All you have to do is give any of these apps more or less unrestricted client rights and you can very easily end up as dead meat. You go 'somewhere', you request something. If it's the 'wrong place', you're just as vulnerable as if you're running the app in server mode. You asked for it? You got it! Uh-ohhh. What's the solution? Well, that's why many of the PSFs are now moving beyond traditional firewall protective measures (but only if those additional methods are invoked, of course). And, for the most part, many of these 'other' protective measures have been available for sometime from non-firewall utilities (including in some instances existing OS utilities). For example, you just gave me a gold mine in your following comment. Okay, I hit this one hard -- must have been two years ago -- with all of Steve Gibson's ballyhoo about Leaktest. Can you identify a single exploit (before or since the Leaktest freak-out) that relied on tampering with the main executable for which a firewall rule had been set? I can't; I've asked (repeatedly); if one is out there in the wild that actually tries to do this, I've never heard of it. (Of course, there's probably not gonna be one now, either. ) But, Is a software firewall the only solution to this problem; and, indeed, is a software firewall a solution to this kind of problem? No, (on both counts). Again, I've never seen or heard of a 'masquerading executable' identified in the firewall ruleset and I've asked. What I have heard about is corrupted main OS utilities (technically, having no Internet access capabilities whatsoever), and I have heard about corrupted DLLs, OCXs, VBXs and SYS files used by such utilities. In the former case, I've got a guy who sat there and watched his DUN monitor go crazy with outbound traffic (this on a stand-alone PC), while his software firewall showed no untoward activity whatsoever. In the latter case, MSIE (iexplore.exe) is nothing but a stub program; all the real work is done via DLLs , OCXs, etc. You bust one of these, you're good to go -- over the connections PERMITTed for MSIE itself! Yeah, yeah, yeah, I know ... the newer releases of the major PSFs will also check for (and authenticate) the DLLs. Ummm, just which called routines are they checking; are they checking OCXs and VXDs and SYS files? Are they also checking core OS components? Are people actually using this functionality or are they being told to turn it 'off' because it's such a 'hassle' and raises so much havoc with throughput? All I can say is check the posts on these subjects. If it ain't on, it ain't working. Now, (even if it's being used) the above functionality is not part of the core functionality of a PSF (and certainly not of a hardware firewall which doesn't even have access to such information). Is there nothing we can do about such problems? Of course not; that's where memory-resident registry monitors, AV/AT/Spyware/keylogger utilities come into play. There's also file authentication software which is far more sweeping in its power. (No, this is not a plug for NIS File Check; there are any number of freeware/shareware/payware alternatives to NIS File Check -- and I'm still trying to work my way through all of them.) All of these do a better, more comprehensive job that the latest generation of PSFs -- and they do it with far less of a performance hit.) I suspect (but at the moment cannot confirm) that this was part of what wizard was referring to. All of which brings us back to his statement about the incremental advantage of using a software firewall. Finally, there's one particular threat against which the current crop of PSFs is largely useless -- these are the memory-resident (RAM only) exploits. For those who may have missed it, these have been 'out there' since at least CRv1 and CRv2. In this instance, there ain't no "file on disk" for an AV/AT/spyware/keylogger program to pick up. And it doesn't screw with the registry, so even a registry monitor isn't going to pick it up. The only solution (of which I am aware) to this vulnerability is to run a locked-down version of Win NT/2000/XP (and with non-supervisory privileges) while on the Internet. And quite frankly, I'm not going to maintain that even this is sufficient. Disagree. the kinds of threats I'm talking about here ride piggy-back on the existing authorized application, using the ports and IP addresses for which the authorized Internet-enabled application has been authenticated. That's precisely what CRv1 and CRv2 did; indeed, it's precisely what most of the e-mail borne viruses and worms do. A standard firewall (hardware or software) has no capability whatsoever to 'block' these communications. You have to go to the exotics and you have to have the functionality enabled (assuming it exists in the first place). Agreed, no argument whatsoever. I never took your comments any other way. For those who may be wondering (and haven't figured it out yet), someone (who shall rename nameless) asked for someone to take the counterpoint in this discussion. I waited, no one else really picked up on it, so I decided to do it. (Yes, I do use a PSF, but we'll get to why much later in this thread.) I think we all know that at least 90% of the people frequenting this forum use some sort of firewall. Most of the remaining 10% would probably take a look at the question that scotcov initially posed and simply say "Why bother? I'll be here for the next ten weeks!" You've seen the "Of course, you need a (software?) firewall!" responses already. But, if I turn to you and ask "Why do you need a software firewall?", I'd really like to think you could provide a better answer than "Well, I asked in Wilders/GRC/DSLR Security and 90% of the respondents said I did!" In all honesty, that's not much of a response (and it don' sell real well if that's all you can say to your spouse, co-worker, or friend). So, yes, I'm playing counterfoil here. I don't really care if you agree or disagree with my position; I want you to think, decide, and then be able to defend your decision. There are alternatives to a PSF (I think luv2besecure or LowWaterMark may have referred to them) and I think that wizard may well be basing a certain amount of his initial statement on the fact that many of them are readily available as freeware/shareware. Indeed, quite some time ago, I wrote a rather sardonic response (was it to Name Game, our very own PrimRose?) in the DSLR SEcurity Forum as to how one could live perfectly safely without a PSF. This solution is hardly for Joe User, however. I also initiated the "Stealthed vs Closed" debate in the DSLR Security Forum. While I have my own opinions on the value of 'Stealth', my primary intent was to make people think about just how much Stealth was really worth. To me, your questions represent an "Inquiring minds want to know (understand)" position. I have used you as a foil (and I think you know that), but I'm not trying to convince you that I'm right and you're wrong. I'm simply trying to lay out an alternative so that you can make an 'informed' decision and then defend it, whatever it may be. Peace.