Step 3: Secure NT Services
Several NT-based services are vulnerable when exposed to an untrusted
network like the Internet. Therefore, consider disconnecting (unbinding)
these services from any publicly exposed network adapters, including serial
communications (COM) ports (dialup adapters) if you use Remote Access Service
(RAS) for Internet or inbound dial-up access. For example, unless you must
support telecommuters who need access to this service, don't make the server
available to remote users. If remote Internet users need to access this
sensitive service, you can use a Virtual Private Network (VPN). Establishing a
VPN with Point-to-Point Tunneling Protocol (PPTP) provides a more secure means
of supporting telecommuter connections.
If you aren't supporting telecommuters, you still need the server to work
correctly on your private network. Disable the server bindings to any network
adapter cards connected to the Internet or other untrusted networks. Do not
leave the following standard services bound to an exposed network card, except
under special circumstances: Alerter, Clipbook Server, Dynamic Host
Configuration Protocol (DHCP), Windows Internet Naming Service (WINS), Directory
Replicator, Messenger, Network Dynamic Data Exchange (DDE), Network DDE DSDM,
Schedule, Simple Network Management Protocol (SNMP), and simple TCP/IP services.
In short, bind only the required services (e.g., Web or email) to a public
network adapter.
In my secured system, I used only one network adapter card and loaded only
default services, which simplified the unbinding process. I disabled the WINS
client binding from the adapter, and rebooted the system. To unbind services
from a network adapter, open the Network applet in Control Panel, click the
Bindings tab, select your exposed network adapters, and click Disable. You can
then close the dialog box and reboot the server.
I didn't install the FTP service portion of IIS and encourage you not to
install it. FTP clients send passwords in clear text, and packet sniffers can
easily grab them. Also, minor oversights in setting your directory and file
permissions can lead to a system security breach. The only services running on
my system were the event logs, NT LAN Manager (NTLM) Security Support Provider,
Remote Procedure Call (RPC) Service, and Web Service.
Step 4: Obscure the Administrator Account
Crippling the built-in Administrator account (i.e., removing its permissions
and rights) is a great idea. This powerful built-in account is dangerous to
leave available because intruders can use it as a target for gaining access to
your network.
Some network professionals argue that renaming or disabling the
Administrator account is easier than crippling it. However, there are two
reasons why the easier way isn't necessarily the safest way to handle this
vulnerable account. First, before Microsoft released SP3, the RedButton utility
easily revealed your newly renamed Administrator account. SP3 fixed that
problem, but you're better off safe than sorry. Second, intruders can recognize
a disabled account and start guessing account names and passwords until they
find what works.
If you cripple the Administrator account, intruders might spend days,
weeks, or even months trying to guess the account name and associated password.
Even if the hackers eventually discover the name and password, they will also
find that the account has no rights or permissions, and they've wasted their
time. In the meantime, you can closely monitor your audit logs to detect
break-in attempts and the would-be intruder, and take steps to make your network
more secure.
On my installation, I used the built-in TCP/IP filtering security to
disable all ports except port 80 so a tool like RedButton couldn't contact the
NT system. I also used a shortcut to obscure the Administrator account. This
shortcut can work for you if you're certain you won't expose non-Internet
service ports (e.g., port 137, port 138, and port 139 for NetBIOS) in the
future.
First, I gave the Administrator account an obscure, hard-to-guess name.
Then I created a new Administrator account and removed all default permissions
and rights, effectively creating a dummy target for would-be intruders. I
removed the right to log on from the network, so users couldn't access the
system across the network. That way, an intruder who learned the new account
name and associated password would still need to log on to the system using the
local keyboard console. Administrators working remotely might require the right
to log on from the network to perform certain operations. It's always best to
require any remote user to use PPTP to access the corporate network from across
the Internet. If you don't use an encryption method such as PPTP, a hacker can
sniff your network traffic more easily and possibly use the information in the
network traffic to penetrate the system.
NT also creates a Guest user account (as seen in User Manager). However,
leave this account disabled until a guest uses your network, and then create a
specific account for that person. (You will need to delete the account after the
guest has finished using it).
Prev. page
1
[2]
3
4
next page 
