Search: Home Bugtraq Vulnerabilities Mailing Lists Jobs Tools Beta Programs
      Digg this story   Add to del.icio.us   (page 1 of 4 ) next 
Blocking Traffic by Country on Production Networks
Timothy M. Mullen 2008-07-16

When I originally posted to Bugtraq regarding the use of country-by-country sets to control traffic to or from any particular country, I knew that it was not a new idea. However, applying the concept for use with Microsoft's ISA Server was at least a new application for it, and apparently has had some utility for people based on the thousands of downloads that have been made of the free sets from the Hammer of God Web site.

As promised in that post, here is some more detailed information on the use of country-by-country data sets in firewall configurations, where it may be appropriate, and methods by which one may use the sets to create traffic reports. While the methods listed and tools available are created specifically for ISA, the concept can be applied to any product that supports the necessary data elements.

Before we begin, I will post a disclaimer: This is a technical discussion. Nothing in the following dissertation is motivated by any political, religious, racial, or other ideal or prejudice. Processes discussed and opinions reached are based on technical and statistical research -- No other bias is intended nor should be inferred.

Background


A few months back, David Litchfield from NGSSoftware was working on a research project on SQL security and asked if I could assist him by setting up a constant network capture looking for SQL Slammer attacks.

One will recall that the SQL Slammer worm exploited a vulnerability in the SQL Browser service of Microsoft SQL Server 2000 and MSDE a single packet payload delivery over UDP 1434 to randomly -- or psudo-randomly -- generated IP targets. Slammer was launched back in January of 2003, so I was curious as to what I would find. I had long-since moved all published services from my home office, and had a single high-speed cable connection for access. Given Slammer's "random" target IP generation, I thought it would be a good environment to test in, and to be honest, I was a bit dubious on what the results would be as I tend to hope that gaps of over 5 years in a vulnerability will result in eventual patching.

Unfortunately, that was obviously not the case.

In a little under 4 days, I received over 30 unique Slammer attacks which were verified by packet inspection and confirmed not to be simple probes to UDP 1434. I was surprised, but not by the number of attacks. Upon further investigation, I found that every single attack -- all 30 of them -- were sourced from China, which really piqued my interest. I've seen many, many different reports of different attacks from different worms as well as reports of generalized Internet traffic by protocol and port, but this was the first time I had seen firsthand where a worm attack was sourced from a single country.

The result got me thinking: What was special about China in regards to Slammer? Was it true what others have said about China being a festering cesspool of malicious network activity? Were the boxes just all unpatched? Was China just being used as a launching pad for attacks sourced elsewhere? More importantly, what other malicious traffic was sourced there? And what other countries exhibited similar behavior with other protocols?

Before I could answer any of these questions, I had to first figure out how to reliably -- or reliably enough -- determine what country the source IPs were from. This required building a database of IP ranges that I could use to report from. There are a number of sources around the Internet once can use for such purposes: some are for pay, some are free. Depending on how much work you want to do, how much you are willing to pay, and how often you need updates, you'll have to make your own choice. Of course, I've already got the sets for ISA made and available for download for free, or you can compile your own database from sources on the Internet.

The list I ended up with contained over 230 countries comprised of over 100,000 individual records of IP ranges. Obviously, I had a lot more work to do in order to make traffic reporting easy enough to work with on a continuing basis. Enter Microsoft ISA Server. ISA Server is an enterprise firewall and caching product that supports extensive reporting, scripting, and customization options. You can use any product you wish, of course, as long as it provides you the tools you need. I'll be using ISA in all following examples.

The goal required several steps: I had to load all the records into SQL Server, which was easy enough. Then, I had to set up several test ISA Servers configured to log all traffic to SQL, and combine those servers' logs into one huge database I could use for report. Then, ultimately, I would need to create country-by-country "sets" in ISA comprised of each countries multiple lists of IP ranges so that I could create firewall rules to act upon the traffic by country.

Compiling the Data


As far as SQL was concerned, the table format I ended up with was simple enough. Let's call it the IPAddresses table:
BegIP (nvarchar 16), EndIP (nvarchar 16), BegIPLong (bigint), EndIPLong (bigint), Cntry (nvarchar 50), and the FullCntry (nvarchar 75)
BegIP and EndIP are both character fields containing the dotted-IP format of the IP address, but the really important fields are the BegIPLong and EndIPLong which are long integer representations of the IP Address. The SQL data doesn't do us much good if we can't easily match up what country goes with what firewall log record based on the IP. When you have a range of IPs formatted in dotted notation, you can't easily perform logical record retrieval using operands like between, so having a mechanism by which one can easily retrieve records is essential. Besides, when ISA Server logs IP addresses to SQL, it first converts it to a Long Int, so we might as well take advantage of that here. He's the list of IPs for Papua New Guinea (used because it is a short list of IP ranges).
BegIP EndIP BegIPLong EndIPLong Cntry FullCntry
117.53.40.0 117.53.47.255 1966417920 1966419967 PG Papua New Guinea
192.160.29.0 192.160.29.255 3231718656 3231718911 PG Papua New Guinea
195.112.176.88 195.112.176.91 3278942296 3278942299 PG Papua New Guinea
202.0.80.0 202.0.80.255 3389018112 3389018367 PG Papua New Guinea
202.1.32.0 202.1.63.255 3389071360 3389079551 PG Papua New Guinea
202.1.240.0 202.1.255.255 3389124608 3389128703 PG Papua New Guinea
202.58.128.0 202.58.131.255 3392831488 3392832511 PG Papua New Guinea
202.61.0.0 202.61.0.255 3392995328 3392995583 PG Papua New Guinea
202.95.192.0 202.95.207.255 3395272704 3395276799 PG Papua New Guinea
202.165.192.0 202.165.207.255 3399860224 3399864319 PG Papua New Guinea
202.171.240.0 202.171.247.255 3400265728 3400267775 PG Papua New Guinea
203.83.16.0 203.83.23.255 3411218432 3411220479 PG Papua New Guinea
216.139.171.48 216.139.171.55 3633031984 3633031991 PG Papua New Guinea
Article continued on Page 2 



SecurityFocus accepts Infocus article submissions from members of the security community. Articles are published based on outstanding merit and level of technical detail. Full submission guidelines can be found at http://www.securityfocus.com/static/submissions.html.
    Digg this story   Add to del.icio.us   (page 1 of 4 ) next 
Comments Mode:







 

Privacy Statement
Copyright 2009, SecurityFocus