Classes of Attack



WASC Project Proposal/Overview:

Distributed Open Proxy Honeypots

Team

Project Lead: Ryan Barnett (WASC/Breach)

Project Team:

Jeremiah Grossman WASC

Prince Kohli Citrix

Ivan Ristic WASC/Breach/ModSecurity

Robert Auger WASC

Anton Chuvakin LogLogic

Goals & Objectives

Goals

• Gather statistics on web attacks

o Number/Types of attacks

o Attacker Origin

o Target Classifications – ISP/Bank/eCommerce

• Categorize attack data – using WASC TC

o Real-time

o Manual/Post Processing

• Identify new web-based attacks/methods

o New vulnerabilities/attacks

o Known vulnerability – first appearance of exploitation in the wild

• Develop new honeypot filters to detect/prevent attacks

Overview

Historically, it has been rather difficult for the security community at-large to gather detailed information of web-based attacks. This seems a bit odd since we are constantly deluged with news reports of web attacks such as: defacements, customer’s credit card data being stolen from eCommerce sites or new worms that will automatically exploit some web server flaw. As a matter of fact, in Symantec’s recent Internet Security Threat Report for July 2004 – December, 2004 () they outlined the fact that web-based attacks account for a significant number of top attacks:

• Volume of Attacks - 5 of the top 10 attacks occurred over HTTP

If we know that web attacks are taking place, then why don’t we have more concrete evidence of how the attacks happen? This lack of intelligence may be attributed to a variety of factors from the victim web site’s perspective including:

1. Lack of knowledge that an attack even occurred

Many web attacks go unnoticed for a variety of reasons. Organizations may have either not installed some sort of Intrusion Detection software to monitor HTTP traffic or they have not configured it correctly. Add to this the numerous methods which attackers use to evade IDS systems (Tunneling attacks through an SSL Tunnel, URL Encoding, TAB Separation, etc…) and it becomes evident that web attacks often slip under the radar of web administrators.

2. Lack of verbose/adequate logging of HTTP transactions

Web attacks can often be very complex, perhaps utilizing a specially crafted HTTP request header that will exploit some new web server flaw. Unfortunately, the most typically used web server logging format is the Common Log Format (CLF) which only includes a small subset of transactional data. After a successful web break-in, the standard logs usually do not provide the level of detail needed to accurately diagnose the full web communication.

3. Lack of interest in public disclosure of the attack

In today’s cutthroat world of business, disclosing information about a successful attack may provide competition with a competitive advantage or cost an organization customer support.

From a counter-intelligence perspective, honeypot/honeynet technologies have not bared much fruit in the way of web attack data. The exceptions to this rule are indiscriminant worms such as Code Red, Nimda and Linux.Slapper that pseudo-randomly scanned IP ranges looking for anything that was listening on port 80. Web-based honeypots have not been as successful as OS level or other honeypot applications (such as SMTP) due to the lack of their perceived value. Deploying an attractive honeypot web site is a complicated, time-consuming task. Other than a Script Kiddie probing for an easy defacement, you just won’t get much traffic.

So the question is - How can we increase our traffic, and thus, our chances of obtaining valuable web attack reconnaissance?

Our solution is to use one of the web attacker’s most trusted tools against him - the Open Proxy server. Instead of being the target of the attacks, we opt to be used as a conduit of the attack data in order to gather our intelligence. By deploying a specially configured open proxy server (or proxypot), we aim to take a birds-eye look at the types of malicious traffic that traverse these applications.

The honeypot systems will conduct real-time analysis on the HTTP traffic to categorize the requests into threat classifications outlined by the Web Application Security Consortium (WASC) - and report all logging data to a centralized location.

Outline

Phase 1: GenI Initial deployment (March, 2004)

• Consisted of one open proxy honeypot system

• Was online for 5 days

• Report can be read at the Honeynet Project website -

Phase 2: GenII WASC Deployment – (Starting Nov. 2006)

• Small test deployments

• Test all configurations

• Test all logging/reporting

• Approximately 1-2 months

Phase 3: GenII WASC Deployment – (Jan. 2007)

• Will consist of multiple open proxy honeypot systems

• Will be online for extended period of time (initial timeframe of 1 year)

• Will have the following improvements over the GenI deployment:

1. It will be deployed for an extended period of time, which will allow for valuable metrics for trending, etc...

2. It had a limited scope of view. Was deployed off of a home cable modem (on the Comcast network in Northern VA). Phase 2 will deploy our GenII honeypot proxies on multiple networks to record differences in attack traffic, etc...

3. Centralized Logging

In order to facilitate centralized logging of web attack data, we will be using the open source ModSecurity Console (). The VMware honeypot sensors will be running ModSecurity 2.0 and will use the Concurrent audit log format and a custom log monitoring program called “logc” to transport the audit log data in real time from the sensors to the central log host. Using the ModSecurity Console will provide a centralized log analysis console for generating reports.

4. Additional Proxy Ports

Will configure the open proxy to listen on additional proxy ports (such as Squid Proxy 3128/tcp). This will widen the scope of proxy attacks. Additionally, we will configure the proxy to log to separate files for each port. This would allow for metrics to compare port usage (8080 vs. 8000 vs. 3128). In the initial deployment, the logs did not differentiate whether the client connected to ports 80, 8000 or 8080.

5. Real-Time Categorization

By using the ModSecurity Core Rules (), we are able to effectively categorize the attacks in real-time. This data will assist with monitoring trends, events and for generating reports.

6. Web Threat Report

We will provide some high level stats, trends, new attacks on a monthly basis and release it to the public. This could be similar to:

• SANS Internet Storm Center's Monthly Threat Update () or

• Symantec Internet Threat Report ()

7. Top Attacker Block List

Will provide a continually updated block list of the top web attackers. I worked with the folks at to see if they could provide this functionality. The idea here is that we can use this list to add Web Server ACLs to block these particular hosts. Dshield said that they were already providing a block list (). While this is true, I gave them the analogy that this is like running a bank and having the option of putting up the FBI’s Most Wanted posters vs. the FBI’s Most Wanted Bank Robbers posters. The value difference is that their current block list is for bad guys who are scanning systems, however it does not focus on port 80 attacks.

Honeypot Configurations

-----------------------------

I. Hardware Used:

-----------------------

1. Citrix provided Linux servers for ModSecurity Console host

II. Software Used:

-----------------------

1. Debian Linux VMware image

2. Apache Web Server

3. ModSecurity (Apache IDS module)

4. ModSecurity Core Rules

5. Mod_Evasive (Apache Denial of Service Prevention Module)

III. Apache Configurations

-----------------------------------

Refer to Apache Open Proxy Honeypot document for GenI configurations -

1. Lock down per CIS Apache Benchmark

2. Implement additional security modules

3. Configure httpd.conf to allow for Proxy capability

Deployment Scenarios

-----------------------------

I. High Speed Home Networks:

-----------------------

• Project Members may deploy our honeypot proxy systems on their home networks if they have high speed connections – cable modems, etc…

• Caveats – some ISP’s may block certain traffic (Ports 80, 6667, etc…) Also need to verify acceptable use policies. During GenI deployment on Comcast network, there were no problems. GenII deployment will include Cox network and they block inbound HTTP requests -

II. Global Positioning:

-----------------------

We need to deploy systems in countries other than US. This may include home users in other countries.

III. Universities/Research Facilities:

-----------------------

We may be able to deploy these systems with help from Universities and other research facilities.

Final Deliverables

Outline what the completed project will deliver:

← Daily Threat Reports

o Similar to SIG^2 G-TEC -

o Automated Reporting

o Diairy type entries when interesting attacks are identified

← Monthly Threat Reports

← Incident Reports as needed

← Block List of Port 80 attackers

← Regular updates

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download