Critics of this method of defense say it's easy for a hacker to find where the default port has been moved, and this is true. All it takes is a port scanner, like Nmap, or an application fingerprinter, like Nikto, to identify the app running on the nondefault port. In reality, most attacks are automated using malware, which as stated, only go for default ports, and most hackers don't bother to look for nondefault ports. They find too much low-hanging fruit on default ports to be bothered with the extra effort.
Years ago, as an experiment, I moved my RDP port from 3889 to 50471 and offered a reward to the first person to find the new port. Two people discovered the port right away, which was no surprise; because I told them what I did, it's easy to discover the right spot. What blew me away is that tens of thousands of hacker wannabes, scanning my system for the new port using Nmap, didn't realize that Nmap, if left to its own defaults, doesn't look on nondefault ports. It proved that by doing a simple port move you significantly reduce your risk.
This one doesn't work as well as it used to, given that most attacks happen at the application file level today, but it still has value. Like the previous security-by-obscurity recommendations, installing applications to custom directories reduces risk -- automated malware almost never looks anywhere but the default directories. If malware is able to exploit your system or application, it will try to manipulate the system or application by looking for default directories. Install your OS or application to a nonstandard directory and you screw up its coding.
On many of my honeypots, I install the OS to nondefault folders -- say, in C:/Win7 instead of C:/Windows. I usually create the "fake" folders that mimic the real ones, had I installed the software and taken the defaults. When my computers get attacked, it's easy to find complete and isolated copies of the malware hanging out in the C:/Windows/System32 folder.
Changing default folders doesn't have as much bang for the buck as the other techniques mentioned here, but it fools a ton of malware, and that means reduced risk.
Innovative security technique No. 6: Tarpits
My first experience with a tarpit product was LaBrea Tarpit. It was developed during the outbreak of the Code Red IIS worm of 2001. Worms readily replicate to any system that matches their exploit capabilities. LaBrea worked by answering connection attempts for addresses not already assigned to legitimate machines. It would then answer and tell the worm to connect, then spend the rest of the time trying to slow down the worm, using various TCP protocol tricks: long timeouts, multiple retransmissions, and so on.
Today, many networks (and honeypots) have tarpit functionality, which answers for any nonvalid connection attempt. When I penetration-test these networks, my attacks and network sweep scanning attacks slow to a crawl -- they're unusable, which is exactly the purpose. The only downside: Tarpits can cause problems with legitimate services if the tarpits answer prematurely because the legitimate server responded slowly. Remember to fine-tune the tarpit to avoid these false positives and enjoy the benefits.