Category Archives: Traffic Analysis

Security Learning, Traffic Analysis

Research to Detection – Identify Fast Flux in your environment

Gallery 7 Comments

So what is Fast Flux?

Fast Flux is a camouflage technique used by Modern day Bots to evade detection and IP-based Blacklisting. This technique basically involves rapidly changing DNS Address Records (A Record) for a single FQDN, which means that every time you visit a www.site.com, you will be connecting to a different IP address.
Detecting Fast Flux in any environment is a very difficult task. Let me explain how!!!

  1. Fast Flux is of two types – Single Flux and Double Flux.
  2. If Single flux is employed, the only thing to worry about is IP address change for static domain names. A typically Fast Flux service network would have several thousand A records for the same domain name. The TTL value for every A record is very less, thereby prompting DNS resolvers to query in short succession.
  3. If Double Flux is employed nothing is static anymore. Both the NS Records as well as the A records change rapidly. The NS servers are a list of compromised machines having a back-end control to the attacker. Detecting Double Flux is twice as hard as Single Flux already is.
  4. If you think that “Oh, its easy to identify these domains from Analysis of rapidly changing DNS records” YOU ARE WRONG. In case of Web Traffic Load Balancing, several hosting servers employ this to ensure that they are able to serve the Client Request quickly. So, if you were to analyze the DNS records, you would be lost when you try to separate milk and water.
  5. There is no right or wrong way of identifying the Fast Flux networks and research is still ongoing to identify a solid solution.

But the havoc, several Bots cause today are real. How can be bring Research based approaches to Enterprise? How can we achieve Fast Flux detection? How can we increase the effectiveness of detection with already existing tools?
In this post, I wanted to discuss about Research to Detection based approach for Fast Flux in DNS in an Enterprise Network. I have used Snort, ArcSight, Custom Scripting etc to elucidate my thoughts and ideas. This may not be a perfect solution but it would do its primary job.

  1. Firstly, we need to start logging DNS queries happening in the Network. We are interested in only logging and analyzing all outward queries happening from our Enterprise DNS servers. This is less noisier than internally received requests to DNS Servers from client machines. Remember to have a Log Management/Detection program in place.
  2. In the queries being sent from the DNS servers, we need to detect all the queries that return A records with a TTL value of < 1800 seconds. This data collection should contain the Domain Name, A records and NS Records.
  3. If possible we can collect the ASN records for the IP A records returned by the DNS response
  4. The data collection of the above can be done by a three-step customization.
    1. First step would be to create a Snort Rule to identify DNS queries/responses with a low TTL value. Generally, the DNS Response would have the A Records, the corresponding NS records and the TTL value.
    2. Second step of the collection would be to parse the Snort Output data to the to correctly identify the domain, IP records and the NS records. This would mostly require a Custom Collector or we can “shim” an existing File Reader collector to parse the Snort Data into respective fields.
    3. Third Step would be to do a recursive IP to ASN mapping for all the IP records returned. This can be done by running a script or a tool post collection.
  5. We can then put the parsed data into two Active lists (ArcSight Terminology for a watch list). One Active List would be a Domain/A Record pairing and the other would be a Domain/NS Record pairing.
  6. Then a rule logic can be created to do the following:
    1. For Single Flux the logic would be One Domain – Large IP records in a day.
    2. For Double Flux the logic would be One Domain – Large IP records – Large NS records in a day.
    3. Correlation with ASN data collected would give a clear picture of whether the Fast Flux trigger is False Positive or not. I would personally want to investigate this data set against ASN data set manually to begin with so that I can make a determination on what needs to be tightened for the Rules.
    4. Now, we can add some tuning as well for DynDNS scenarios. This whitelist domain list would then reduce the subset of event triggers.
    5. Progressive Cross-Validation with Internet Blacklists, Spam Lists, Abuse Lists etc, will give identification more muscle.

Remember that there are several practical pitfalls in terms of “Performance Issues”. Snort preprocessors can quickly become resource intensive, hence best idea would be to put some Network Zoning in place (with Whitelisted DynDNS sites as well), thereby reducing the Snort processing cycles. Similarly ArcSight Active Lists and Rule Triggers can quickly go out of control, hence it is important to manage them closely. The Custom scripts/data collectors can also put some load on the servers. Once the detection is done, suitable response mechanisms can be put in place for Fast Flux Networks.

Since this approach is a work in progress, I would be adding a few more notes as and when I identify something new. If you have inputs to enhance this idea, I would love to hear from you as well.

 [pdf]Save as PDF[/pdf]

Security Learning, Traffic Analysis, What you need to know?

What is TOR? How can I Un-TOR?

Gallery Leave a comment

TOR or The Onion Router is one of the widely used Anonymity Networks in the “Wide World Web”. Before we understand what TOR Networks are, its important to understand the basic technology involved. This is key to defining a Detection/Prevention/Control strategy in Enterprise Networks. The basic technology behind TOR is Onion Routing.
Onion routing is a technique for anonymous communications over a Network. Data Packets are repeatedly encrypted and then sent through several onion routers. Like someone unpeeling an Onion, each onion router removes a layer of encryption to uncover routing instructions, and sends the message to the next router where this is repeated. Using this approach means each node in the chain is ideally aware of only 2 other nodes:

  1. The preceding node from which the onion was transmitted.
  2. The proceeding node to which the onion should next be transmitted.

Now how is it achieved? Just like in a Routed Network, there is a master node in Onion Network that maintains the list of TOR Nodes and their Public Keys (Remember TOR uses Asymmetric Crypto). Whenever a request is made, this master node crafts the data packet in layers. Outermost Layer of encryption will be opened by the First Onion Router and the Innermost encryption will be opened by the Last Onion Router. The peeling away of each layer of the onion makes it difficult or impossible to track the onion and hence the name Onion Routing.

Some things to understand about TOR in addition to the basic technology is how it works and how hard it makes life for Security Professionals to identify and control it.

  • Firstly, TOR Nodes have to be public. Their IPs cannot be hidden. Here is a sample list of TOR IP Addresses. This could potentially serve as a blacklisting source in Enterprise Firewalls/IPS/IDS/Proxy.
  • TOR Nodes can use Bridges to connect to TOR Public IPs. Bridges are nothing but Relay IP addresses that help a client connect to the TOR Network. Bridge/Relay IP Addresses make it difficult to identify TOR entry and Exit nodes. Any user can install “Vidalia” and set up a Bridge relay to help several TOR users (who have TOR Public nodes blocked by ISP or Enterprise). These bridge IP addresses are generated randomly per Request Received. There are several such Relays and they are hidden from Public IP Pool.
  • TOR traffic is encrypted and hence detection using IDS/IPS will be difficult
  • TOR Clients have the capability to use SOCKS to set up connections and hence differentiating SOCKS doing TOR and SOCKS not doing TOR is a great challenge.
  • Several Torrent softwares have the capability to do native TOR communication. Identifying such Software Machines will be a challenge in an Enterprise having a distributed setup, Remote Access Setup etc.

Now that we know what TOR is, Don’t we need to know how to control this in the Network?
Analysis and Control of TOR can be done as follows:

1. Blacklist all known IP addresses – This essentially is not fool-proof for the mentioned reasons above with Bridging.
2. Custom Script to pool Bridge IPs and keep adding the same to IP Blacklist. This can regularly query the Bridge Mail ID to get the random list of Bridge IP addresses.
3. If your enterprise is using HTTP Proxies only, then SOCKS Protocol should not be available in your network. Identifying a user doing SOCKS can help identify possible TOR clients.
4. P2P traffic should be blocked in the enterprise as P2P and TOR go hand in hand. The key things to look for is, Browser Plugins for P2P that mask behind HTTP and HTTPS Requests. This is quite an interesting development as far as Identifying P2P Users in your network is concerned.
5. If Traffic Analysis, Flow Analysis is available in your network, you can profile your Network segments for all the Application protocols in use in your network. Unless and until you are using TLS/IPSEC through out your network, chances are that very less amount of encrypted traffic is found. Filtering through the Chaff on known Encrypted traffic should narrow you down to a list of machines that do encrypted traffic and are not supposed to or not normal.

I welcome the readers to share your experience on working with TOR and let me know of any other method of identifying and analysis TOR in Enterprise networks.