Yes, there are a large number of potential exploit-vectors of this kind. Only
thing is, if you close them all, you end-up with a deaf, dumb and blind box
that does very little that's useful, apart from maybe play Solitaire.
It would really be preferable if the buffer-overrun exploits which are at
the root of the problem could be dealt with. But, I guess that ain't gonna
happen anytime soon, as it would require a change to a programming-language
with better inbuilt bounds-checking.
I think it's also a fair bet that Linux, mostly coded with the same
language, has the same issues; it's just that no-one has gone looking for
over-run exploits with the same level of effort.
I don't recall 95/98 having many of these issues, plus on that platform the
only open ports were -in general- those which were actually required by
server processes. Perhaps XP took the wrong roadmap, would it have been
easier to fix the stability bugs of 9x than to fix the security bugs of NT?
"Marbles" wrote:
>
> From the methods shown. By closing the ports at the Operating System level.
> In theory you could leave those ports open on your firewall and there would
> be no response from these ports that were disabled by tweaking services and
> registry. because the mechanism that controls those ports have been turned
> off/shut down / locked down and or disabled.
>
> Tho to be on the safe side, keep those ports blocked at the firewall layer
> as well. So now you have a dual layer of security protecting those ports. :)
>