You could do this with a URL Rewriter, like IIRF.
IIRF provides examples of how to block requests based on the IP address of the remote machine.
# Iirf.ini
#
# ini file for blocking by IP address
#
RewriteLogLevel 1
RewriteLog c:\inetpub\iirfLogs\Iirf
RewriteEngine ON
StatusUrl /iirfStatus
IterationLimit 5
RewriteCond %{REMOTE_ADDR} ^24\.132\.226\.94$ [OR]
RewriteRule ^/(.*)$ /$1 [F]
I think what you're doing is allowing based on IP address, so .. the reverse.
# Iirf.ini
#
# ini file for allowing requests by IP address range
#
RewriteLogLevel 1
RewriteLog c:\inetpub\iirfLogs\iirf
RewriteEngine ON
StatusUrl /iirfStatus
IterationLimit 5
# If the IP address is not in the specified range, return 404
# (NF = Not Found)
RewriteCond %{REMOTE_ADDR} ^(?!24\.132\.(\d+)\.(\d+))
RewriteRule ^/.*$ - [NF]
# If URL processing has gotten this far, do nothing (no rewrite),
# which means, implicitly, allow the request.
If you also want to allow access for authenticated users, you would have to modify that ini file to also consider an authentication cookie, or something.
Windows NT, Server 2000 and Windows 2000 are now regarded as end of life by Microsoft. This means that if any new security vulnerabilities are discovered for these operating systems, Microsoft will make no effort to create a security patch.
While I agree that yes, it is unlikely that a virus will be specifically developed to target anything less than Windows XP/Server 2003, since they all evolve from the same code, it's certainly possible that a "modern day" virus designed for Windows XP/Vista/7 can also successfully attack Windows NT/2000. Indeed there was a security vulnerability in September 2009 which affected a whole array of operating systems (including Windows 2000) and they all got a patch except Windows 2000.
Aside from vulnerabilities in the core Operating System, you are also lumbered with Internet Explorer 6 at best. Internet Explorer 6 is known to not implement various protection features that later versions of the browser do, and you're more likely to get attacked by a "surf and get owned" type virus. Then you've got browser plugins (Flash Player, Adobe Reader etc) - these might still release updates for Windows 2000 at the moment, but you're walking on thin ice. Sooner or later, they will do what the rest of the world is doing and stop supporting a 10 year old Operating System. Then you'll have vulnerable browser plugins, and believe me - they are the most documented and exploited, because it's such an easy and effective attack vector.
Third party applications will also become a security problem (if they're not already, they will) as vendors stop patching older versions of the software that work only on legacy Operating Systems.
As an example, Office XP was the last version to run on Windows NT and Office 2003 the last version to run on Windows 2000. These products will become end of life soon (if they're not already) - and Office frequently features in the monthly security updates.
Then you've got all your other software. This won't necessarily cause you security problems, but rather maintainability problems. The majority of software was stopped being tested against Windows 2000 long ago. This means that if one of your applications breaks, the vendor is quite likely to say to you "Well you're running Windows 2000.... what do you expect?".
As an aside, make sure all your Windows XP workstations are on Service Pack 3, as anything lower than that is not supported by Microsoft, and won't receive security updates.
Best Answer
You really need to follow some guidance. When hardening an operating system thousands of configuration items an be customised in many different ways. A good place to start is with the CIS (Center for Internet Security) guidance. The CIS publishes security benchmarks for most common operating systems and applications. You can download the benchmarks here: https://learn.cisecurity.org/benchmarks
In respect of your original question, I've quickly skimmed the Windows 7 CIS Benchmark doc and it doesn't seem to mention locking down the command prompt or PowerShell. That said, I also checked the CESG guidance (UK Government IT Security Guidelines) and they suggest using AppLocker to prevent user access to CMD.exe. https://www.gov.uk/government/publications/end-user-devices-security-guidance-windows-7/end-user-devices-security-guidance-windows-7
TLDR: Security is difficult, and the level of 'lock down' you place upon your users is going to be different from the level I apply against mine. If your users don't need access to cmd prompt, don't give it to them. Before you remove it though consider whether or not you need to retain CMD.exe for troubleshooting end user problems (running in the logged on users' context).