vADC Blog

Dynamic Defense Against Network Attacks (DYANA) (10/03/2008)

by mikeg_2 on ‎06-28-2012 09:48 AM (1,752 Views)

Dynamic Defense Against Network Attacks (DYANA) (10/03/2008)

* *

111_23208.png

Stingray Traffic Manager 5.0 allows you to call a customized version of Java's Servlet API from within TrafficScript™.

In this article we'll show how you can dynamically change Stingray Traffic Manager's configuration by accessing the SOAP interface of the admin server from a Java Extension that is run when a TrafficScript rule detects a network attack.

For more background material on Stingray's Java Extensions, please consult the documents linked to at the end of this article. The example we use is to look for requests containing attack attempts in TrafficScript and adding the IP address from which the attack originated to the list of banned IPs in Service Protection classes. The number of attacks out there is huge (and growing) -- it's impossible to look at them all here. We'll pick just a single one for the purposes of this article, the dreaded abuse of the HTTP CONNECT method.

HTTP's CONNECT Method

You may not be familiar with this method, because the bulk of the HTTP requests on the internet consists of the more conventional GET, HEAD and POST methods. The CONNECT method was added later on and provides a mechanism for proxy-ing https connections. Basically, the proxy establishes a TCP connection to a remote site on the user's behalf and then simply forwards on packets between the client and the final destination. For details, please see

<a href="http://tools.ietf.org/html/draft-luotonen-ssl-tunneling-01.txt" target="_blank">*the original specification*</a>

. There are, of course, legitimate uses of the CONNECT method. In fact, it can even be used together with Stingray's forward proxy functionality to

<a href="/t5/Articles/Stingray-Traffic-Manager-Forward-Proxy-and-Tunneling-SSL-06-21/td-p/23080" target="_self">*tunnel SSL traffic with Stingray*</a>

.

Abuses of CONNECT

While originally intended for SSL traffic, due to its very generic nature, the CONNECT method can be used to handle any type of TCP connection. In fact, since SSL traffic is incomprehensible for all intermediate nodes, the proxy has to be completely agnostic of the details of the packets it forwards. Therefore, also connections that are not using HTTPS can be proxied with the CONNECT method.

Most web-sites, of course, do not intend to provide SSL proxy functionality. Nevertheless, malicious users regularly try to trick unassuming servers into functioning as proxies. Why would they do that?

One reason is to get around access restrictions. Mail servers, for example, usually have blacklists of IP addresses which have been used for sending SPAM in the past. Connections from these IPs will be closed straight away. This makes life harder for spammers.

Today, most SPAM is not sent from the spammer's computer directly, but rather from hijacked machines. Spammers are, unfortunately, a rather clever breed and will go to great lengths to send their rubbish to as many recipients as possible. When they hijack a machine on the internet (often private Windows boxes without adequate protection), they will initially be able to use that machine for their evil intentions.

Once word has spread that this machine is not to be trusted for SMTP traffic, the spammer has to go and find another machine. This not only involves extra work, chances are that most easy victims have already been captured by other spammers. Also, since home users are typically assigned dynamic IP addresses, it's rather likely that any IP address a machine is given by its ISP has at some time in the past been abused for spamming (you will have cursed this if you have ever tried to send an email directly from your private Linux PC). The machines that are usually not on this type of blacklist are servers with static IP addresses.

Therefore, spammers are increasingly trying to make their SMTP connections appear to come from such trusted machines. The CONNECT method is every spammer's favorite HTTP extension. Here's how it works:

  • Hijack an average Windows PC and install your spam software.
  • Find an HTTP server which implements the CONNECT method naively in the sense of happily forwarding all connections from any machine to every machine.
  • Point your spamware at that server and feed any amount of email to as many SMTP servers as you can.

There is some more background information about this attack on

<a href="http://wiki.apache.org/httpd/ProxyAbuse" target="_blank">*apache's wiki page*</a>

.

Stingray’s answer - Part 1: TrafficScript™

Stingray’s TrafficScript programming language allows you to inspect the requests before they reach your backend servers. One of TrafficScript's functions is http.getMethod() which tells you the method used by a particular request. The following TrafficScript request rule will reject all CONNECT requests:

  1. sub isAttack()
  2. {
  3. $meth = http.getMethod();
  4. return string.icmp($meth, "CONNECT") == 0;
  5. }
  6. if( isAttack() ) {
  7. connection.close("HTTP/1.0 403 Forbidden\n");
  8. }

We've used a subroutine, which is a new functionality introduced with version 5.0. Due to the simplicity of our attack detection code, it is not really necessary to create a dedicated subroutine in this case. But as mentioned previously, the proxy abuse we protect against is just one example of many attacks in the wild. Therefore, every administrator will extend the subroutine isAttack to cover as many scenarios as possible.

Stingray’s answer - Part 2: Service Protection classes

So we've established our first line of defence. The attacker's CONNECT attempts will not succeed. It is very likely, however, that after the first attempt from any given IP address others will follow because, as explained above, most attacks these days originate from compromised computers.

Stingray can help you against this threat of course. The Service Protection functionality lets you define a list of IP addresses from which not to accept connections. Add the offending computer to this list and Stingray will block all subsequent CONNECT requests and other forms of attack before it even invokes a single TrafficScript rule.

The following screen-shot from the Catalog-Protection-page shows the necessary configuration:

746i199B23401113CD9B.png

Setting this up, however, involves manual intervention of the Stingray administrator and is therefore cumbersome, slow and error prone. Wouldn't it be nice if Stingray could itself detect the attack and then automatically block the evil computer? Surely TrafficScript can check for the malign CONNECT method, but how do you forward the information about an attack to Stingray’s configuration?

Stingray’s answer - Part 3: Java Extensions

Enter Java Extensions, another new feature of Stingray 5.0. With Java Extensions you can run arbitrary Java commands from inside Stingray. One of the things you can do is make SOAP requests from a Java Extension. This can be used to access Stingray’s SOAP Control API. The details of how to use SOAP from Java are explained

<a href="/t5/Articles/Accessing-Stingray-s-Control-API-from-Java-09-25-2008/td-p/23198" target="_self">*in another community article*</a>

. There you also find links to download the needed jar files.

Stingray’s SOAP API lets you control almost every aspect of your traffic manager's behavior, including which IP addresses are in the blacklist of each individual Service Protection class. Apart from the password of the admin user, our extension needs a few things to work:

    1. The object over which SOAP calls for Protection classes will be made:


      1. private static CatalogProtectionPort cpport = null;
    2. The object over which SOAP calls for Virtual Server classes will be made
      1. private static VirtualServerPort vsport = null;

The SOAP connections have to be initialized in the servlet's init() method, see

<a href="http://blogs.riverbed.com/files/blockattack.java.txt" target=_blank><font color="#888888">*the full source code in the attachments for details*</font></a>

. Now let's have a look at the service() method:


  1. public void service( ServletRequest req, ServletResponse res )
  2. throws ServletException, IOException
  3. {
  4. try {
  5. ZXTMServletRequest zreq = (ZXTMServletRequest)req;
  6. String srcip = (String)zreq.getAttribute("srcip");
  7. String vsname = (String)zreq.getAttribute("virtualserver");
  8. if( null == srcip || null == vsname ) {
  9. return; // ZXTM closed this connection anyway
  10. }

         String[] vsnames = ;

<a href="http://blogs.riverbed.com/files/blockattack.java-1.txt" target=_blank><font color="#888888">full source code of the Java Extension</font></a>

in the attachments. Due to the dynamic assignment of IP addresses to customers by ISPs, the address we have just banned from accessing our site may tomorrow belong to another computer with a legitimate interest in our pages. An optional improvement to this extension is therefore to add a background thread that removes banned IPs after a configurable period of time using the removeBannedAddresses() method from the SOAP Control API.