Linux in Government: How Security Exploits Threaten Government Infrastructures
The Linux in Government series has taken a new format for 2005. This year's articles will provide fundamental information to government technologists about Linux and open-source software. Although we will continue to inform you about agencies and projects specifically using open-source solutions, we also are going to provide information about open-source resources available to governments.
In the day-to-day life of government information technology, procurement issues, vendor relations, support desk calls, system failures and lobbying command most decision makers' attention. The overall picture of keeping critical infrastructures safe rarely commands enough focus. Because of this, many officials have forgotten that a war exists, and technology infrastructures provide easy targets. Yet, if government officials recognized the magnitude of the problem, they could not avoid attending to it.
In this article, we address some aspects of the hostile environment threatening our critical infrastructures and how government CIOs can protect their organizations. This article offers only a glimpse of the problem and urges public administrators to "do something about it".
Every second of every day, tens of thousands of people with sophisticated tools scan our networks looking for vulnerabilities, hoping they can gain entry and steal money, destroy our command and control systems and disrupt commerce and law enforcement. The volume of activity and methods used seems inconceivable. Yet, you do not see much information about the extent of the problem in conventional media, in discussions on the floor of Congress or on the agendas of legislators. Why? Because the large telecommunications companies don't want to spend the time or money necessary to stop the activity.
Below, we show you the kinds of attacks that take place every day by using examples from real life. We're going to start by looking at an incident that occurred on a server sitting behind a firewall. You can see how the perpetrator attempted to break into the system and disappeared into the safe confines of his or her service provider. While reading this first example, keep in mind that security measures taken prevented this attempted exploit from actually occurring.
We run a hardened Linux server located at an ISP that has passed DoD vendor security audits. Each day our server produces a report of attempted exploits that identifies the IP address of all logins, whether successful or failed. On Friday, December 24, 2004, a user with the IP address of 184.108.40.206 ran a program called crack that attempted to guess a user ID and password. The program made 260 attempts to penetrate the system. You can see an excerpt from our log report below:
Failed logins from these: andrew/password from 220.127.116.11: 5 Time(s) angel/password from 18.104.22.168: 5 Time(s) barbara/password from 22.214.171.124: 5 Time(s) ben/password from 126.96.36.199: 5 Time(s) betty/password from 188.8.131.52: 5 Time(s) billy/password from 184.108.40.206: 5 Time(s) black/password from 220.127.116.11: 5 Time(s) blue/password from 18.104.22.168: 5 Time(s) brandon/password from 22.214.171.124: 5 Time(s)
Notice how the cracker's program progressed in systematic order, using different names and combinations of passwords in an attempt to gain entry to the system.
Unfortunately, we receive log reports with attempts such as this on a daily basis. Usually, the perpetrators use multiple IP addresses to defeat our limits on failed logins. Once they reach the limit, the program kicks over to another IP address and systematically continues the attempt to find a combination of user name and password that allows them to gain access to our network.
In this particular case, I decided to track down the person attempting to break into our system. Using a program called whois, I found the origin of the IP address owner. Figure 1 indicates that the perpetrator used PacBell as an Internet provider and that the IP address owner has a range of address from 126.96.36.199-119.
In this case, I found a name associated with the owner of this range of IP addresses. I eliminated the person's name from the screenshot. This did not provide evidence as to whether or not the owner actually performed the attack. In most cases, Internet service providers assign a different IP address each time a person goes on-line, and names cannot be found.
I contacted PacBell to file a report on the attempted system exploit. After waiting on a service line for over an hour, I received a prerecorded message telling me to contact my Internet service provider, who would have to report the attempted system compromise.
So, I filed a report with our ISP, who took our logs and verified that an attempt was made to break into our system. From there, the issue went to the ISP's compliance office, which contacted PacBell. In Figure 2, you can see an excerpt from the e-mail I received.
After receiving the e-mail from our service provider, we reported the incident to firstname.lastname@example.org. After several days, PacBell informed us it would not institute an investigation. Figure 3 provides a copy of the e-mail we received after following PacBell's instructions and indicating that the company "please respond".
Although we know some facts about the situation, we also know that SBC and PacBell have not indicated that they include attempted break-ins as a violation of their acceptable use service agreements. Nor have they indicated that if so, we expect them to enforce the agreements.
Practical Task Scheduling Deployment
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide