Contact Us
SECURITY BLOG SECURITY DASHBOARD PARTNERS PRODUCTS JOBS SERVICES COMPANY HOME
Network Security Consulting SecurityFocus Article

Blocking Traffic By Country On Production Networks
http://www.securityfocus.com/infocus/1900
2008-07-16

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 onSQL 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 (nvarchar16), 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).
BegIPEndIPBegIPLongEndIPLongCntryFullCntry
117.53.40.0117.53.47.25519664179201966419967PGPapua New Guinea
192.160.29.0192.160.29.25532317186563231718911PGPapua New Guinea
195.112.176.88195.112.176.9132789422963278942299PGPapua New Guinea
202.0.80.0202.0.80.25533890181123389018367PGPapua New Guinea
202.1.32.0202.1.63.25533890713603389079551PGPapua New Guinea
202.1.240.0202.1.255.25533891246083389128703PGPapua New Guinea
202.58.128.0202.58.131.25533928314883392832511PGPapua New Guinea
202.61.0.0202.61.0.25533929953283392995583PGPapua New Guinea
202.95.192.0202.95.207.25533952727043395276799PGPapua New Guinea
202.165.192.0202.165.207.25533998602243399864319PGPapua New Guinea
202.171.240.0202.171.247.25534002657283400267775PGPapua New Guinea
203.83.16.0203.83.23.25534112184323411220479PGPapua New Guinea
216.139.171.48216.139.171.5536330319843633031991PGPapua 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.


Contact Us

Security Penetration Testing

Security Questions

Security Dashboard

Emagined Security Blog featuring Dr. Eugene Schultz
Site Updated May 22, 2013
©2000-2013 Emagined Security
All Rights Reserved

Secure Web Programming
by Vizual Services