Mr. Kruchkov presents a common, real-world scenario that many of you might face. Protecting yourself from this type of access is simple. Let's look at each aspect of protection that you need if you want to avoid this type of intrusion.
Internet Information Server (IIS)—Load the service packs and hotfixes. If you can't load the fixes, always put your Web scripts in a separate directory from your HTML and other files and allow only Execute access to that directory. If you take these precautions, no one can browse those documents or their hidden field contents.
SQL Server—Never leave an account with a blank password; always change the password to something complex that contains a mix of numeric, alpha, and special characters. Consider not using TCP/IP on your SQL servers, and instead run NetBEUI between your SQL server and other systems (e.g., a Web server) that access that system. This way, intruders originating from TCP/IP-based systems will have a much harder time getting into your SQL servers. Because those systems speak only NetBEUI, an intruder has to commandeer a system on your network loaded with NetBEUI, to attack your SQL Server system. In addition, disable the SQL Server xp_cmdshell stored procedure, unless you absolutely must use it. And if possible, don't let stored procedures access the Windows NT Registry.
Domain Name System (DNS)—Never put a hostname in DNS unless it's absolutely necessary, such as when you need the system—such as a Web server or mail server—to be visible to the Internet via DNS queries. Consider using an LMHOSTS file or a WINS server for private internal machines that never require inbound Internet access. If you use LMHOSTS or WINS, discovering other machines on your network is more difficult. Always disallow Domain Listing on your DNS server; this action prevents someone from dumping your domain record database.
Protocols—Always block ports 137, 138, and 139 for inbound and outbound access unless you know these need to be open. In the cases where you must let people use these ports (e.g., a remote user accessing the network 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 an Internet route. This action makes an intruder's discovery process much tougher and stops many types of potential attacks.
User Accounts—Disable the Guest account. If you must let guests 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 it crashes can help you find out why NT crashed. But leaving those system dump logs and 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 application crashes, make sure you either delete the dump/debug file or move it to a secured directory (one that has administrator access only).
General Protection—If your network has a firewall, consider not allowing inbound ping traffic; this action prevents several types of mischief. Also, consider disabling inbound and outbound access to User Datagram Protocol (UDP) ports 137 and 138 and TCP port 139 to stop many common attacks on NT networks. A general rule for firewall implementation is to use your firewall'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 you need to make it available. Block inbound access to all your systems, especially systems running SQL Server, until you have a definite need to allow direct inbound access. Following this practice can be tedious, but it could save your business from complete disaster.
