You don't have to hire a hacker or cracker to test your application's security, nor do you have to buy a lot of expensive hacker tools. However, you do need to have a set process for identifying potential problems. By following the five-step process I detail below, you can easily identify commonly exploited vulnerabilities; and, once you've identified them, you can eliminate or mitigate them.
Step 1: The port scanThe first thing you need to do is perform a port scan on your clients and servers looking for unnecessarily open communication ports. Ports used by services like FTP, NetBIOS, echo, and gotd, are typical culprits for causing security problems. The rule of thumb for TCP and UDP ports is: Turn off any services or listeners that you don't need for your application to function. A port scan is a test to observe which TCP and UDP ports on a target system are listening -- that is, waiting for a connection. Because most computers have a lot of these listeners turned on by default, hackers and crackers often spend a lot of time port scanning their target to locate the listeners prior to establishing a plan of attack. Once these open ports have been identified, it's not difficult to exploit them. Port scanning tools, commonly referred to as port scanners, are readily available on the Internet. Many of them are Linux-based; for example, Nmap, Strobe, and Netcat are a few good ones. My favorite Linux-based port scanner is Nmap. There are a few good Microsoft Windows-based port scanners out there, too, my favorite being Ipswitch's WS_Ping ProPack. WS_Ping ProPack is a low-cost, multipurpose, network-troubleshooting tool that packs a lot of functionality in an easy-to-use package. Once you've procured a port scanner, run a test against the entire gamut of TCP and UDP ports to see which ports are open. Compare the list of open ports against the list of ports the system needs to function, and close all unnecessary ports. Turning off open ports in Microsoft-based operating systems often requires reconfiguring the OS's services or modifying registry settings. UNIX and Linux systems are a little easier: Depending on the flavor, you can usually just comment out a line in a configuration file. Step 2: Check over the user accounts
Next, you need to take a look at the operating system, any databases, and the application itself, looking specifically for guest user accounts, accounts with default or weak passwords, and unnecessary user IDs. You need to do this because most default configurations leave a lot of open holes, creating more than a few default accounts that can be used to compromise your system. This is especially true if you're using a database system such as Oracle, or a Web server such as Microsoft Internet Information Services (IIS). I have logged into many routers, databases, and applications with user IDs and passwords for accounts that either should not have existed or should have been disabled. For example, several years ago, while testing a primitive Web application, I tried logging in to the system using the user ID Guest and a null password. Much to my surprise, the application gladly accepted Guest as a valid user and allowed me to log on. I then tried several other combinations successfully -- entering user IDs and password pairs like none/none and admin/admin. As a result of this experience, I always make a point to look up default accounts and passwords in the setup manual for each piece of software included in the architecture. I build a list of these default accounts and passwords, making sure to test any that I find. I do the same for the application itself, building a list of the test user accounts created by the developers, and try those too. Testing for these things helps identify ways that the system could be compromised, and disabling or deleting unnecessary accounts is a means of eliminating the vulnerabilities you find. A similar rule to that for communication ports applies here: Disable any user ID that is not needed for the system to function. If a user ID can't be disabled, at a minimum, change the default password to one that is well constructed. What's a well-constructed password, you ask? It should be at least six to eight characters long, with at least one special character. Passwords should be just long enough to make them hard to crack, but short enough that they're easy to remember -- a hard balance to strike, I know. I like to use acronyms or a mnemonic device. Never use any word or term that's guessable or obvious; this is another common password mistake. Likewise, be sure not to use single words from a dictionary. My favorite example of a bad password is ROLLTIDE, which I found on a machine in a cubicle littered with University of Alabama paraphernalia. (The nickname for that university's sports teams is the Crimson Tide).
