Why Your i Should Never, Ever Be Left Unattended On the Internet
April 9, 2013 Alex Woodie
By all accounts, Rich Loeber is a good and decent man. He doesn’t leave dogs in parked cars on hot days. He pays taxes. There are no reports of stealing candy from babies. He may be a Yankees fan, but we’ll let that slide. However, when Loeber announced last week that he has an IBM i server that he leaves unprotected on the Internet–and then admitted that it’s been there for 18 years–it naturally leads to certain questions.
In 1995, Loeber decided to do an experiment. He would leave an AS/400 out on the open Internet without the benefit of a firewall, just to see what would happen. Now, everybody of a certain age knows the Internet is full of creepers, crawlers, and is the conduit for horrible individuals to do horrible things. Just what did Loeber think would happen when he left a poor, defenseless AS/400 out on the network? Is he some sort of technological sadist?
Not at all, it turns out. Loeber, who is owner of the IBM i security software distributor Kisco Information Systems, didn’t put the AS/400 (since upgraded to an IBM i server) out on the Internet without any protection. While the server was in the demilitarized zone (DMZ), it also had a running copy of Safenet/400 (now SafeNet/i), an exit point monitoring solution designed to protect IBM i servers from unauthorized network access via FTP, ODBC, Telnet, and other common Internet protocols.
“I thought it was a good place to evaluate the product and it has been helpful at times having a server out in public,” Loeber tells IT Jungle, “especially when I’m traveling or working with other developers.”
Last week, Loeber shared some information pulled from this on-going experiment. Perhaps the most astounding piece of news is that this particular server has never been successfully hacked. Although it’s been subjected to tens of millions of hacker probes and illegal access attempts, it has not once given up the goods (not that there are any actual goods stored on this particular machine, of course, but you get the idea).
That is the good news. The key takeaway is this: If you’re crazy enough to leave an IBM i server out on the DMZ (and we hope that you’re not), then at least equip it with an exit point monitoring solution. It doesn’t have to be SafeNet/i. Just about any of the products from reputable security software vendors will do.
Loeber provided a more detailed look at the honeypot’s server logs in this first quarter hacking report recently published on his website. “To help IBM i shops understand the reality of network threats, we are now reporting some results of what we see on this test box. We hope that it will help IBM i users to better prepare for the very real threats that exist,” Kisco says in its report.
During the first three months of 2013, Kisco’s software recorded 211,346 network transactions in the exit points monitored by SafeNet/i. Out of this total, 1,603, or 0.75 percent, were identified as illegal access attempts and were denied, Loeber says. “That represents about 18 times each day when someone tried to gain access to our system, but was not authorized for that network activity,” the report states.
FTP and Telnet accounted for the vast majority of the unauthorized access attempts, with about 64 percent of them occurring through FTP and about 37 percent occurring through Telnet. Loeber says the FTP attempts were “brute force” attacks, while the Telnet attacks were more targeted.
All but 10 of the FTP access attempts came from user profiles that don’t exist on the server, and were based on common names and functions, such as “Alan” and “Admin.” “These all appear to be FTP script connection attempts, probably cycling through a series of popular password combinations,” Loeber writes. “It argues strongly for user profiles on the IBM i that are not based on people’s first names or job functions.”
The Telnet attempts followed a different pattern. Usually, somebody would try to log on one time, and quit after being rejected. Occasionally, there were two attempts in a row, Loeber says.
Kisco did reverse IP address lookups to find out where these hacking attempts originated. The company says two of the IP addresses used came from an ISP in Brisbane, Australia, and another two from ISPs in Scranton, Pennsylvania, and Galloway, New Jersey. None of the IP addresses are associated with developers that Kisco normally works with. “The obvious conclusion was that these access attempts were malevolent, which is all the more troubling since the IP address of our server is not generally known to the public,” Loeber says.
At least “security through obscurity” still provides a little protection. “When I go through the logs for the access denials, none of them appear to be from people with IBM i expertise,” Loeber says. “I think most of them are expecting a Unix box or a Windows server based on what we see. The strongest attempts are aggressive FTP script attacks that try to gain access by brute force. The OS returns very little information from the Telnet denials, so it is very hard to characterize them at all.”
Loeber’s on-going experiment provides definitive proof that no server is safe when left on the open Internet. That really shouldn’t be a surprise to anybody who’s paying attention. Once a server is placed on the Internet, it’s instantly deluged with unauthorized access attempts by hackers who are poking and prodding for a crack in the security mechanisms.
While the nature of the Internet shouldn’t surprise you, the level of success that hackers are having may. According to a recent report by Webroot, 79 percent of US and UK companies suffered some sort of Web-borne attack in 2012. Phishing is the most prevalent Web-borne attack, and affected 55 percent of companies last year, the company says. More than half of survey respondents without Web security in place reported their websites being compromised.
The folks at Webroot say it’s to be expected. “It’s no surprise that the latest study shows that attacks are increasing in frequency, complexity, and scale. Organizations need to implement layered defenses from the endpoint to the network to understand not only what is happening but where the attacks are manifesting from and when,” David Duncan, Webroot’s chief marketing officer, says in a press release. Webroot says its software as a service (SaaS) Web security software can provide another layer of security.
Organizations that host production Web apps on IBM i servers definitely need to take more precautions than those that run traditional transaction systems on Power Systems servers that reside behind a protective firewall, outside of the DMZ. For those with modern Web apps on IBM i servers, an exit point tool such as SafeNet/i will provide a good foundation to protect the OS, but additional network-level layers–such as IPS, IDS devices, reverse proxies, and SIEM appliances–as well as application-level protection will be required.