SSH Issues: Does Installing SSH Enable More Exploits Than it Solves?
SSH as Salvation?
Some years ago I started doing research on SSH, the wonder tool of the security set. I read one article about a clever SSH setup. The administrator’s DMZ hosts could contact the intranet patching server, something normally verboten. The DMZ servers would route through the administrator’s PC and then access the internal patching server. After considering the author’s SSH design, however, I soon recognized definite security impacts to this approach.
Although several major security compromises are made possible through poor SSH design, does that mean that SSH is a likely target? Consider this: SSH is one of the most attacked services. As the SANS Institute states in its current top 20 vulnerabilities roundup, "Of particular interest this year are attacks against SSH." SSH is rated U1, the top UNIX vulnerability. Why is SSH such a target? In this article, you’ll learn why people are implementing SSH on Windows, mainframe, and UNIX devices. We’ll explore port forwarding, a cool SSH capability. Then we’ll take apart the clever administrator’s SSH design, including attacks against key authentication itself.
In a later article, I want to discuss what you can do if you’re a firewall or a UNIX administrator. You probably recently implemented SSH as a drop-in security precaution against Telnet and FTP exploits—if so, depending on your firewall and SSH design, you likely just enabled many more exploits.