Linux in Government: How Security Exploits Threaten Government Infrastructures

Showing government offices and agencies how Linux and open-source software provide better security.

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".

Perpetrators Without Borders

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.

Example #1

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 66.126.78.114 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 66.126.78.114: 5 Time(s)
angel/password from 66.126.78.114: 5 Time(s)
barbara/password from 66.126.78.114: 5 Time(s)
ben/password from 66.126.78.114: 5 Time(s)
betty/password from 66.126.78.114: 5 Time(s)
billy/password from 66.126.78.114: 5 Time(s)
black/password from 66.126.78.114: 5 Time(s)
blue/password from 66.126.78.114: 5 Time(s)
brandon/password from 66.126.78.114: 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 66.126.78.112-119.

Figure 1. Using whois to Find IP Owner

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.

Figure 2. Excerpt of E-mail

After receiving the e-mail from our service provider, we reported the incident to abuse@pacbell.net. 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.

Figure 3. Excerpt of Reply

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Follow up from our ISP

tadelste's picture

It is disappointing they do not police their home subscribers, but at the same time, it is hardly a surprise. You will find a list of blocks attached that belong to them in the event you wish to filter traffic from them in a different fashion.

If this occurs again, open a ticket with a summary along the lines of, "Abuse from PacBell IP <x>", attach text logs to the ticket, and we will report the issue to them immediately and see what response we garner. If it is not favorable, I have some other options for contacting someone with PacBell that will be more responsive.

I am closing this ticket, but again, please open another if the abuse continues.

Latest response from PacBell

tadelste's picture

If you have followed this article, you might enjoy this latest piece.

PacBell wrote me:

From: kana1@pbi.net
Reply-To: kana1@pbi.net

"This is to acknowledge receipt of your complaint. All complaints
received are investigated. However, individual responses to these
complaints are not always possible due to the volume received.

"Please be assured we will investigate this issue and take appropriate
action.

"Please do not hesitate to write again if you have any questions or if
you wish to report instances of abuse by SBC Internet customers.

"Thank you,

"The SBC Internet Abuse Security Department"

I responded to them and received this immediately:

"User's mailbox is full:
Unable to deliver mail."

oh... PacBell cares now

Ben LeMasurier's picture

It's funny that PacBell all of a sudden seems to care a little more about this problem...
- Ben

uidzer0.org

SBC response

Doug Morris's picture

I am constantly reporting abuse through e-mail to SBC. I like to add a 'CC' to abuse@FTC.gov. But recently, SBC's email server tends to refuse relays to the FTC.gov email server. Suprising, huh?

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix