Over the past few weeks, we have researched Internet security--the more recent threats, as well as countermeasures against the attacks made. The problems we looked at ranged from Botnets to DDoS to DNS attacks to Spam attacks. The solutions included anomaly detection using a variety of approaches, reputation systems, blacklisting and cheating detection.
One of the thoughts I've had is that network security is not so much a problem of bad system design as much as it is a perpetual game between the "bad guy" and security research. Either party is rewarded by staying one step ahead of the other. The "bad guy" always has plenty of incentive to come up with a new security threat, and that gives security a good reason to come up with a countermeasure against the threat. In a sense, the good and bad guys are creating a competitive market for each other.
Also, I was previously unfamiliar with how Botnets worked. It was pretty impressive (albeit quite insidious) that a system can be designed to take command of tens of thousands of computers and use them to perform an arbitrary task. Robust distributed systems are hard to design. (Well, who knows if Botnets are designed robustly?)
We discussed several reputation systems. Collusion seems to be a persistent problem in reputation system design. It is a hard problem because colluding peers can game the system by taking advantage of good peers and rating other colluding peers well, thus damaging the accuracy of the rating system. I have read papers on reputation systems, but none of them has applied the study of evolutionary dynamics and evolutionary stable strategies to them. I read an excellent book this semester that sheds light on design of a robust social structure. It discusses the conditions that allow or prohibit invasion into a society of agents. Translating collusion into the language of the book, if a reputation system can be designed where peers have an evolutionarily stable strategy, the peers will be able to resist invasion by a colluding group of attackers.
Wednesday, December 15, 2010
Kalman: Another Anomaly Detection System
My previous post dealt with ASTUTE, a traffic anomaly detection system that uses the queue volume equilibrium property to detect anomalies of a distributed nature. This post deals with a different anomaly detection system known as KALMAN. The developers of this approach presented their system in the 2005 IMC. It makes use of the Kalman filter to extract normal traffic traces from a network, leaving the rest (known as the residual) for anomaly analysis.
The Kalman filter is a technique that allows for predicting future values based on past measurements that may be mingled with noise, or random variations in measurement. This filter is useful for other things, such as predicting the position of a target, given previous measurements that may be slightly inaccurate.
In the anomaly detection system KALMAN, the Kalman filter compares predictions of traffic state with the actual traffic state (with the more recent measurement data). Then, ROC curves are used to decide the accuracy of the prediction. In short, there is a traffic matrix (showing traffic at each intermediate node) and a path matrix from which origin-destination flows can be constructed. The system identifies the individual flows that are anomalous so that they can be analyzed for what type of anomaly it has.
The Kalman filter is a technique that allows for predicting future values based on past measurements that may be mingled with noise, or random variations in measurement. This filter is useful for other things, such as predicting the position of a target, given previous measurements that may be slightly inaccurate.
In the anomaly detection system KALMAN, the Kalman filter compares predictions of traffic state with the actual traffic state (with the more recent measurement data). Then, ROC curves are used to decide the accuracy of the prediction. In short, there is a traffic matrix (showing traffic at each intermediate node) and a path matrix from which origin-destination flows can be constructed. The system identifies the individual flows that are anomalous so that they can be analyzed for what type of anomaly it has.
A "Wise" Way to Detect Traffic Anomalies
Since the early days of the Internet, its security has been something of growing importance. As it is managed on many different levels (user, ISP, content provider, telephony, etc.), there have been different approaches to minimize threats. For example, users and content providers are primarily concerned with keeping their computers free of malware, to avoid compromise of personal information or resources.
ISPs take a different stance. They are concerned with keeping their clients as a whole free of malware, and free from becoming part of (or the target of) attacks, such as DDoS and spam. That is what traffic anomaly detection is concerned with. Anomaly detection is a challenging task, as there are a variety of anomalies that can occur within an ISP. Consequently there are a variety of systems that have been developed to pinpoint anomalies.
ASTUTE is a fairly recent system. Its detection is based on the assumption that, when router queues are not saturated, the total volume aggregated from different flows does not change much over time. Anomalies are thus detected based on deviations from this equilibrium. ASTUTE does well at finding when groups of flows simultaneously cause an increase of traffic, even when this increase is small. This would make it possible to classify traffic from Botnets. However, it does not do well at classifying large volume increases by one or a few flows. There are other detection methods, such as Wavelet or Kalman, that can do this. In practice, ASTUTE would work well in concert with one of these other detection methods, as each has its own benefits.
ISPs take a different stance. They are concerned with keeping their clients as a whole free of malware, and free from becoming part of (or the target of) attacks, such as DDoS and spam. That is what traffic anomaly detection is concerned with. Anomaly detection is a challenging task, as there are a variety of anomalies that can occur within an ISP. Consequently there are a variety of systems that have been developed to pinpoint anomalies.
ASTUTE is a fairly recent system. Its detection is based on the assumption that, when router queues are not saturated, the total volume aggregated from different flows does not change much over time. Anomalies are thus detected based on deviations from this equilibrium. ASTUTE does well at finding when groups of flows simultaneously cause an increase of traffic, even when this increase is small. This would make it possible to classify traffic from Botnets. However, it does not do well at classifying large volume increases by one or a few flows. There are other detection methods, such as Wavelet or Kalman, that can do this. In practice, ASTUTE would work well in concert with one of these other detection methods, as each has its own benefits.
Looking at Wireless Simulations in OMNeT++
We were curious to know how well OMNeT++ (v4) simulates a wireless setting. There are several out there, such as ns-2, and Opnet. We have done experiments with ns-2 in a wireless setting, but thought it performed significantly below our expectation. Perhaps it is because we hold wireless simulation to a high standard.
The benchmark we use is a 2007 IMC performance study done by Dracos Nicolescu, titled "Interference map for 802.11 networks". A major point in his study is that there are three different ranges in an 802.11 network. Communication range defines the range in which two hosts can communicate with adequate SNR in absence of other wireless communications. Carrier sensing range is the distance at which two hosts can sense whether the other is transmitting, but they don't have the ability to send or receive data from the other. Beyond carrier sensing range is the interfering range, at which one host will transmit while the other is transmitting, yet its signal will be corrupted by the signal of the other.
So, we set out to experiment to see whether simulated 802.11 hosts in fact model those three ranges, and if so, find out at which distances the ranges correspond to. We used two different OMNeT++ packages: the most common networking one (INET), and Mixnet. Mixnet combines the upper stack of INET with a more sophisticated network interface card, which is derived from MiXiM.
Our methodology and results are included in our report. The conclusions are two-fold: First, OMNeT++ wireless simulation provides many of the aspects of the 802.11 host, but isn't entirely faithful to the results of Nicolescu's study. Second, these simulation packages are relatively young; we found adequate need for debugging, development and documentation in both.
The benchmark we use is a 2007 IMC performance study done by Dracos Nicolescu, titled "Interference map for 802.11 networks". A major point in his study is that there are three different ranges in an 802.11 network. Communication range defines the range in which two hosts can communicate with adequate SNR in absence of other wireless communications. Carrier sensing range is the distance at which two hosts can sense whether the other is transmitting, but they don't have the ability to send or receive data from the other. Beyond carrier sensing range is the interfering range, at which one host will transmit while the other is transmitting, yet its signal will be corrupted by the signal of the other.
So, we set out to experiment to see whether simulated 802.11 hosts in fact model those three ranges, and if so, find out at which distances the ranges correspond to. We used two different OMNeT++ packages: the most common networking one (INET), and Mixnet. Mixnet combines the upper stack of INET with a more sophisticated network interface card, which is derived from MiXiM.
Our methodology and results are included in our report. The conclusions are two-fold: First, OMNeT++ wireless simulation provides many of the aspects of the 802.11 host, but isn't entirely faithful to the results of Nicolescu's study. Second, these simulation packages are relatively young; we found adequate need for debugging, development and documentation in both.
Subscribe to:
Posts (Atom)