Protection against DoS / DDoS attacks using autonomous system number (ASN) filtering

Introduction

In the light of the New Year holidays with their essential attribute - increased DoS / DDoS attack activity, I would like to raise one rather rarely used (but quite effective) way of repelling attacks - blocking based on the ownership of IP address blocks to a specific provider / Data Center.


On the Internet and on Habré there were a lot of publications on the subject of protection, but basically they boil down to the following approaches based on IP grouping on various grounds:

• Block individual IP attacking bots
• Block whole subnets to which the bots belong
• Blocking entire countries / cities to which the attacking bots belong
• Blocking all IP addresses except those explicitly allowed
• Block IP addresses based on a specific algorithm (including the use of specialized hardware)

But at the same time, another way of grouping (and, therefore, blocking) IP addresses is completely unfairly missed - their membership in autonomous systems (ASN). What is ASN? This is a group of IP addresses that are served by one provider or Data Center. Conventionally, this is a higher level of hierarchy, immediately following the concept of a network / subnet, but having an organizational origin. Let us take Yandex as an example, their autonomous system number is 13238 and it owns the following blocks of IP addresses: as you can see, bgp.he.net/AS13238#_prefixes , there is no regularity other than belonging to the same ASN. Another thing to note is that ASNs are of two types - 16 bit (up to 65635) and 32 bit (up to 2 ^ 32-1).

But how does this technical excursion help protect against intruders? The fact is that there is a rather wide list of providers (both ISP and Data Centers), which, to put it mildly, do not care about the security of their networks (do not block outgoing DDoS attacks, do not respond to complaints, etc.) and, as a result , quite often are sources of DDoS attacks. Blocking such autonomous systems (temporary, of course) can greatly help in defending against attacks. With detailed statistics of autonomous systems, which are most often the sources of attacks, you can find on the website: stopddos.ru/current (statistics almost in real time)

Determining the number of autonomous system to which the IP address belongs

How to determine the autonomous system to which the IP address / network belongs? It is quite simple. If the IP address is in Europe (and therefore - in the RIPE jurisdiction), then you can use the command: whois ip_address / network. Let's try on Yandex:

whois 93.158.146.0 

Pay attention to the field ORIGIN, it just shows the autonomous system number.
')


If the IP addresses belong to another RIR (AFRINIC, LACNIC, etc.), then they do not have the concept of a route object and here the most universal advice I can give is to use a special service that allows you to convert an IP address to an ASN number: www. team-cymru.org/Services/ip-to-asn.html

What else is remarkable service from CymRu, is the ability to automate and call from the console of this operation, which will be very appropriate if you use (when protecting against real attacks without it) automated traffic analyzers, log files to search for patterns and anomalies in context defined ASN.

Well, for example, at this stage, we found the ASN (usually, of course, from several pieces to several dozen), from which the attack is coming, the next step is to check who owns it and for what purpose it serves so as not to accidentally cut off its own customers, this can be done through a service from Hurricane Electric, bgp.he.net/ASXXXX , where instead of XXXX you need to put the detected autonomous system number.

Blocking traffic from / to a specific ASN

But how do we block the traffic that comes to us from a certain ASN? Any trunk provider has this function, the data center or carrier (and it is implemented via BGP), but it’s almost impossible for the end user to get this function. Therefore, we will use Debian Wheezy and the iptables packet filter to cut off traffic from spurious ASNs.



Of course, a standard solution that allows you to do something in style:

 iptables -I INPUT -p tcp --dport 80 -m asn --asn-number 11222 -j DROP 

It does not exist yet, so we have to improvise!

Two different approaches immediately come to mind - ipset and geoip (yes, you have a question - what relation does it have to the question, but more on that later). ipset allows you to block traffic belonging to a set of IP addresses or a set of IP networks, which basically suits us. But this is not particularly flexible and I'm not sure that the Linux kernel will be enough if we create, say, 120 hashes for the autonomous systems we need and the management of such a set of hashes will be very, very problematic.

Quite by chance, in the process of studying the xtables GeoIP module, it occurred to me that it uses approximately the same algorithm for determining whether a network belongs to a specific country, which we need to determine membership in a particular autonomous system. In addition, there is a number of compelling comments from the author xtables GeoIP, judging by which approach is used by them is more optimal: xtables-addons.sourceforge.net/geoip.php

So, let's first assemble and install the xtables geoip module and then we will unify it to solve the initial task - blocking by ASN.

Installing the xtables GeoIP Module

There were many such instructions, they are rather brief, so let me give here the full instructions.
Install the required packages:

 apt-get install xtables-addons-common xtables-addons-source 

In Debian Wheezy, a lot of work has been done with the Xtables and now there is no need for additional gestures to get working modules from the Xtables package. Also, due to the use of the DKMS framework, it is not necessary to re-compile the modules manually when updating / replacing the kernel - the system will automatically solve all this.

Now a few words about how GeoIP works. It uses a rather clever (in my opinion) approach, when lists of IP networks belonging to a particular country are given in binary format, stored in the server’s file system and loaded into memory when the iptables command affecting the country is called. This allows you to provide high speed and save memory, as the full set of IP addresses of all networks in the world takes almost 500 megabytes in uncompressed form.

For xtables, GeoIP uses network-to-country mapping bases taken from the MaxMind company site, but it is required to manually load and convert to the format that the xtables kernel module accepts.
Go:

 cd /tmp /usr/lib/xtables-addons/xt_geoip_dl 

After this operation, two files with the CSV extension will be found in the current folder, in which respectively there are lists of IP networks for the IPv6 and IPv4 protocols with an indication to which countries they belong.
Now we need to convert these files to binary format:

 mkdir -p /usr/share/xt_geoip /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip *.csv 

In the process of conversion, we will see many interesting informational messages, for example, the number of IP v4 / v6 ranges for each country:

 759 IPv6 ranges for RU Russian Federation 5401 IPv4 ranges for RU Russian Federation 

Everything, we are ready to work, we will try to cut off the traffic that comes, for example, from Zimbabwe:

 iptables -I INPUT -p tcp --dport 80 -m geoip --src-cc ZW -j DROP 

The moment we give this command, the file /usr/share/xt_geoip/LE/ZW.iv4 will be taken from the file system and loaded into the kernel, which contains the list of IP countries.

Pay attention, friends! In no case do not use similar in the production of NO-WHERE-YES. This is the best practice, as it is impossible to do on the Internet. This can be done only temporarily, for example, in the case of active resistance to DDoS / DoS attacks, or just to calculate how much traffic comes from each country. Always keep in mind that the relevance of GeoIP bases leaves much to be desired, and your key clients from New York may turn out to be in Zimbabwe banned by you (of course, deprived of access to your resource).

Creation of base on networks belonging to ASN in the MaxMind format.

To make your life as simple as possible, let's try to create a network-ASN mapping database in the same format that MaxMind stores network-country mapping data. With this approach, we will be able to use the xt_geoip_build script without any changes.

How to create a similar database? First, we will need the current imprint of the Internet routing table, since the information on the network ownership of a particular ASN changes every minute and therefore it is not possible to always have a current base. Where to take this print? It is always up-to-date in the format MRT TABLE DUMP V2 on the website Routevievs.org: archive.routeviews.org/bgpdata .

But there is a small problem with this format - it is very difficult to analyze and therefore we need a converter that is developed by RIPE and is called BgpDump: bitbucket.org/ripencc/bgpdump/wiki/Home
Unfortunately, there is no such converter in the Debian repository and we will have to compile it from the source code, this is rather trivial, I provide the instructions below:

 apt-get install -y libbz2-dev cd /usr/src wget http://www.ris.ripe.net/source/bgpdump/libbgpdump-1.4.99.13.tgz tar -xf libbgpdump-1.4.99.13.tgz cd libbgpdump-1.4.99.13 ./configure --prefix=/opt/libbgpdump mkdir /opt/libbgpdump make mv bgpdump /opt/libbgpdump 

But the format of the data that BgpDump generates does not match the MaxMind format and we need another converter (fortunately a lot simpler) that we implemented in Perl, you can take it to the address: raw.github.com/FastVPSEestiOu/xt_asn/ master / bgp_table_to_text.pl , then put it at /opt/bgp_table_to_text.pl and set the exec flag (chmod + x).

Now we have a complete set of software for generating the ASN network in the MaxMind format. To implement the entire task, you need to run a series of bash commands:

 rm -f /opt/bgp/asn.csv mkdir /opt/bgp # http://phpsuxx.blogspot.com/2011/12/full-bgp.html yesterday_date=$(date --date='1 days ago' '+%Y.%m') yesterday_date_with_day=$(date --date='1 days ago' '+%Y%m%d') # get routing data for yesterday at 5 o'clock wget http://archive.routeviews.org/bgpdata/${yesterday_date}/RIBS/rib.${yesterday_date_with_day}.0600.bz2 -O /opt/bgp/rib.bz2 #  ,       "" (25   i7 2600) /opt/libbgpdump/bgpdump /opt/bgp/rib.bz2 | /opt/bgp_table_to_text.pl > /opt/bgp/asn.csv 

After that we convert in the same way as the data of Max Mind GeoIP:

 /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip /opt/bgp/asn.csv 

As a result of the work of the command, almost 100 thousand files (2 for each ASN) will be created in the / usr / share / xt_geoip / LE / folder / and they will be used to load into the kernel filtering module.

Modifying xtables geoip to use it to determine if an IP belongs to a specific ASN

If we try to replace the ZW country name in the iptables command with an ASN number, for example, 11222, we will get an error:

 geoip: invalid country code '11222' 

What to do? Look inside xt_geoip. Here are a few words about how GeoIP works - it consists of a plugin for iptables (userspace), which loads the rules into the kernel and the kernel module (kernel space, respectively). After a quick search through the code, we find that the Country Code in ISO3166 format is stored in an unsigned 16 bit number format that can hold numbers up to 65535.

As we mentioned earlier, the ASN format is currently adopted 32-bit, so in order to filter traffic from / to 32-bit ASN (for example, 190111), a little improvisation will be required - you will need to find a free ASN number in the first 65 thousand (for example, free ASN 170) and transfer the list of networks in binary format to it (mv /usr/share/xt_geoip/LE/190111.iv4 /usr/share/xt_geoip/LE/170.iv4), but not forgetting that the ASN number is used "replaced".

Such a hack will work fine even if you need to operate with all the ASN of the world! Their total number today is ~ 46000 and is easily placed, taking into account permutations in a 16-bit unsigned number. If at the time of reading the article, the ASN will become more than 65 thousand, then you will have to put a patch on the nuclear component of the GeoIP module, but it will be quite simple - will you need to replace the short int with a full int or even long (what if 64 bit ASNs appear?).



To achieve the possibility of using ASN numbers instead of two-letter country codes, we will patch the code a bit. Namely, we will comment out the block in which there is a check that the specified iptables “country” argument is exactly the two-letter ISO country code:

 //if (strlen(cc) != 2) /* Country must be 2 chars long according // to the ISO3166 standard */ // xtables_error(PARAMETER_PROBLEM, // "geoip: invalid country code '%s'", cc); // Verification will fail if chars aren't uppercased. // Make sure they are.. //for (i = 0; i < 2; i++) // if (isalnum(cc[i]) != 0) // cc[i] = toupper(cc[i]); // else // xtables_error(PARAMETER_PROBLEM, // "geoip: invalid country code '%s'", cc); 

And after that, we replace the packing code of two 8-bit characters into a 16-bit number with a code that simply reads a 16-bit number from the string and saves it:

 //cc_int16 = (cc[0] << 8) | cc[1]; // Convert 16 bit unsinged integer (up to 65535) sscanf(cc, "%d", &cc_int16); 

You also need to change the code that displays the country code using the internal numeric representation of the country (16 bit number), now we simply display the number without conversions:

 -printf("%s%c%c", i ? "," : "", COUNTRY(info->cc[i])); +printf("%sxas%d", i ? "," : "", info->cc[i]); 

In this case, I allowed myself to replace asn with xas, since in some cases (32-bit ASN) this is not a real ASN number (but a wildcard number) and I would like to emphasize this.

The final patch overlay file can be found here in our GitHub repository: raw.github.com/FastVPSEestiOu/xt_asn/3e3eebe8b2136d148fe71adc1218a656c363ada2/libxt_geoip_patched.c

Now it's small, we need to compile the xtables-addons-common package (just in it is placed the module-extension for iptables, working in user space) by putting this patch on it:

 cd /usr/src apt-get install -y dpkg-dev devscripts build-essential fakeroot apt-get source xtables-addons-common apt-get build-dep -y xtables-addons-common cd xtables-addons-1.42 #     wget https://raw.github.com/FastVPSEestiOu/xt_asn/3e3eebe8b2136d148fe71adc1218a656c363ada2/libxt_geoip_patched.c -Oextensions/libxt_geoip.c dpkg-source --commit  "Patch for xtables geoip - ASN resolver" debuild -us -uc 

Now install the patched package:

 dpkg -i /usr/src/xtables-addons-common_1.42-2_amd64.deb 

And after that you can use 16-bit ASN numbers in the ipables rules:

 iptables -I INPUT -p tcp --dport 80 -m geoip --dst-cc 11222 -j DROP 

Now you are ready to repel another type of attack! In addition, similar methods can be used to analyze the legitimate traffic that goes to your server :)

Friends! Good luck to you in the coming year and fewer DDoS attacks, your FastVPS!