Stop Thief!

Protect Your System from Intruders

Mr. Kruchkov presents a common, real-world scenario that many of you mightface. Protecting yourself from this type of access is simple. Let's look at eachaspect of protection that you need if you want to avoid this type of intrusion.

Internet Information Server (IIS)—Load the service packs andhotfixes. If you can't load the fixes, always put your Web scripts in aseparate directory from your HTML and other files and allow only Execute accessto that directory. If you take these precautions, no one can browse thosedocuments or their hidden field contents.

SQL Server—Never leave an account with a blankpassword; always change the password to something complex that containsa mix of numeric, alpha, and special characters. Consider not using TCP/IP onyour SQL servers, and instead run NetBEUI between your SQL server and othersystems (e.g., a Web server) that access that system. This way, intrudersoriginating from TCP/IP-based systems will have a much harder time getting intoyour SQL servers. Because those systems speak only NetBEUI, an intruder has tocommandeer a system on your network loaded with NetBEUI, to attack your SQLServer system. In addition, disable the SQL Server xp_cmdshell stored procedure,unless you absolutely must use it. And if possible, don't let stored proceduresaccess the Windows NT Registry.

Domain Name System (DNS)—Never put a hostname in DNS unlessit's absolutely necessary, such as when you need the system—such as a Webserver or mail server—to be visible to the Internet via DNS queries.Consider using an LMHOSTS file or a WINS server for private internal machinesthat never require inbound Internet access. If you use LMHOSTS or WINS,discovering other machines on your network is more difficult. Always disallowDomain Listing on your DNS server; this action prevents someone from dumpingyour domain record database.

Protocols—Always block ports 137, 138, and 139 forinbound and outbound access unless you know these need to be open. In the caseswhere you must let people use these ports (e.g., a remote user accessing thenetwork via the Internet), define filtering rulesets (in your firewall, router,or NT TCP/IP stack) that let only specific systems use these ports to connect.Also, consider unbinding NetBIOS from your network cards connected to anInternet route. This action makes an intruder's discovery process much tougherand stops many types of potential attacks.

User Accounts—Disable the Guest account. If you must letguests access your system, consider establishing an ID name other than Guest,and set the lowest possible level of rights and permissions for that account.

Dump Logs—Configuring NT to write a memory dump file when itcrashes can help you find out why NT crashed. But leaving those system dump logsand drwtsn32.log debug files unprotected on your system can lead to disaster.Often, dump/debug files contain information (e.g., domain name, ID, passwords)an intruder needs to break in to your network. Any time NT or an applicationcrashes, make sure you either delete the dump/debug file or move it to a secureddirectory (one that has administrator access only).

General Protection—If your network has a firewall, considernot allowing inbound ping traffic; this action prevents several types ofmischief. Also, consider disabling inbound and outbound access to User DatagramProtocol (UDP) ports 137 and 138 and TCP port 139 to stop many common attacks onNT networks. A general rule for firewall implementation is to use yourfirewall's rules to block everything, and then open access as needed.

For example, if you don't run an FTP server, block inbound FTP until youneed to make it available. Block inbound access to all your systems, especiallysystems running SQL Server, until you have a definite need to allow directinbound access. Following this practice can be tedious, but it could save yourbusiness from complete disaster.