Tag Archives : Internet Protocol March 2009

ATLAS 2.0: Observing A Rapidly Changing Internet

By: Danny McPherson -

It’s already been over 2 years ago since we first introduced our Active Threat Level Analysis System – ATLAS, a multiphase project that’s been evolving pretty much constantly ever since.  The first phase of ATLAS focused on capturing data via a globally scoped network of sensors running a number of data capture and analysis tools that would interact with attackers to discover what activities they are attempting, capture full payloads and classify them, and characterize scan and backscatter traffic.   This information was then correlated with a number of other ATLAS system data sources, and wrapped in the ATLAS portal, a public resource that delivers a sub-set of the intelligence derived from the ATLAS sensor network on host/port scanning activity, zero-day exploits and worm propagation, security events, vulnerability disclosures and dynamic botnet and phishing infrastructures.  It includes:

  • Global Threat Map: Real-time visibility into globally propagating threats
  • Threat Briefs: Summarizing the most significant security events that have taken place over the past 24 hours
  • Top Threat Sources: Multi-dimensional visualization of originating attack activity
  • Threat Index: Summarizing Internet malicious activity by offering detailed threat ratings
  • Top Internet Attacks: 24-hour snapshot of the most prevalent exploits being used to launch attacks globally
  • Vulnerability Risk Index: Determines the most dangerous vulnerabilities being exploited on the Internet today

Today we announced ATLAS 2.0, the next generation of ATLAS.  Many of you that follow the ASERT blog, employ our Active Threat Feed (ATF), or work with Arbor and our ASERT team on operational security issues, have seen bits and pieces of ATLAS 2.0 for quite a while now.  In a nutshell, what we’ve done with ATLAS 2.0 is expand well beyond the initial ATLAS capabilities, incorporating new intelligence information, to include:

  • collaboration with over 100 ISPs across 17 countries
  • expanded Fingerprint Sharing Alliance participation
  • real-time ‘coarse’ Internet traffic levels, protocols, and applications
  • topologically diverse global view of Internet routing system security, stability and intelligence
  • topologically diverse DNS system inputs and analysis (e.g., to identify fast flux and other DNS-related threats)
  • attack traffic data flows and trajectory information
ATLAS Fast Flux Bots

ATLAS DNS Fast Flux Bots

It’s all about visibility and baselining up and down the IP protocol stack, operating at each of the various layers, the more information we collect and model, from more globally distributed and diverse locations, in particular with the ever-increasing array of topologically scoped threats, the more likely we are to detect deviations from what’s normal or acceptable.  Once those deviations are detected, they can be analyzed to determine whether they’re legitimate or malicious.  Whether they’re Internet control plane routing system stability [1], global Internet traffic levels [2, 3, 4], exploit activity for a given vulnerability [5], DNS flux activity [6], or botnet command and control log and execution activities [7], establishing broad visibility and understanding what constitutes normal activity enables network operators and engineers to respond most effectively in their operating environment.

We hope that the additional intelligence gained through ATLAS 2.0 will permit Arbor to continue to provide a valuable public resource, and enable Arbor customers and non-customers alike to better prepare for the rapidly evolving global Internet threat landscape.

Reblog this post [with Zemanta]

Distributed SSH Brute Force Attacks

By: Jose -

Recently a couple of news reports have come in that suggest that someone has changed how they do SSH brute force attacks:

The change is this: instead of the hosts from the SSH botnet pounding away as fast as possible from the same IP over and over and over again, where you see it failing and failing and failing, these guys have moved to what they should have been doing, coordination. They’re only trying one or two logins from a single IP before moving on; another IP from the botnet tries a new login. The IP may re-appear but only after a while. This defeats some of the simple rate-based triggers for local protection. What’s more is they’re only trying very specific SSH servers. They seem to not be trying everything in the book.

The answer to this is to use a blacklist, working on the theory that someone else has seen this IP scanning and trying logins and failing. Here’s a list of blacklists you can use (import them with caution, use at your own risk, etc).

These lists MAY help you prevent the attempts from the botnet (and many others). I’ve worked with the person (let’s call him C) who both gathered this list and did more analysis of this distributed, patient scanning to look at an overlap between Arbor’s SSH scanner and bruter blacklist and his own blacklist and we came up with about 12% overlap. Not great, and I wonder how much overlap there will be in the future (ie if we go forward one day would the Arbor SSH blacklist have prevented a bruter from trying logins). I would suggest contributing to those blacklists to help everyone, there’s a lot of SSH-bots out there at this point!

Also, here’s a 2d snapshot of ATLAS’ SSH blacklist: http://atlas-public.ec2.arbor.net/public/ssh_attackers

What we’re lacking so far is a capture of the tools on the box, the bot code. I analyzed a case earlier this week where an SSH server was broken into via SSH scanning and it was just a typical IROFFER network. This looks far more substantial than that.

If you have tracks matching this AND you want to help analyze this, please be in contact.

Many thanks to C for his great analysis of the events so far. He, too, is looking for “what comes next”.

Reblog this post [with Zemanta]