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 |
