RioRey RX1810: how to put a firewall through hell

Introduction

Dit artikel is een vertaling van RioRey RX1810: een firewall onder vuur.

The RioRey RX1810 is an appliance specially developed to counter DDoS attacks. Tweakers.net has purchased this appliance to better protect itself against these kinds of attacks and, since it is an interesting appliance, we have written a review about it.

Attack!

The goal of a Denial of Service attack (DoS, for short) is to render services such as a website or chat server inaccessible. When many attackers are involved in a DoS, this is called a Distributed DoS, or a DDoS.

In its manual, RioRey defines a DDoS as being 'an attack which uses a flood of traffic to overwhelm a server on the Internet.' This straightforward concept can be put into practice in countless straightforward and, in particular, less straightforward ways. An attack may resemble any type of legitimate Internet traffic, and, since the Internet offers thousands of legitimate applications, a DDoS defence must be able to counter thousands of different attacks.

Moreover, it is stated in the manual that most DDoS attacks are carried out nowadays by at least four thousand computers and that botnets involved in the really large attacks involve hundreds of thousands of computers. In addition, RioRey tells us that, at the end of 2008, it only cost 4 dollar cents per bot per day to set up an attack.

Why we should protect ourselves

Protection against DDoS attacks costs, of course, money, time and effort and most websites are not exactly under attack on a daily basis. Therefore, not everybody will find it useful to take preventive measures. Thus, it is necessary to carefully consider the costs and benefits of protection.

Most of the costs are related to buying the appliance and its additional maintenance. The benefits are somewhat harder to establish. Our primary goal is to reduce the number of hours our system administrators have to invest in trying to counter an attack. What is more, a successful defence has the immediate benefit of safeguarding the income from banners and various other parts of the websites. Other websites also have to take the increased traffic into account, as well as the additional load to servers caused by a DDoS.

The benefits in the long term are more difficult to assess. Even if a website is down for only a few hours, this may already result in a loss of visitors. Usually, there are several other websites that provide comparable information and once a visitor has found an alternative website he or she is less likely to return. In addition, downtime may cause damage to the image of a website or the company behind it. After all, people expect a website to be fully operational.

Whether protection is useful or not mainly depends on the frequency and severity of the DDoS attacks that are made on a website. If a website has never been under attack, protection is simply a waste of money. In any case, the cheapest solution is to not protect oneself and hope that this will never be necessary either.

DDoS attacks on Tweakers.net

Tweakers.net fell victim to several attacks in August and September 2009. A number of these attacks were indeed effective. The attacks varied in intensity between 60 and 75 kilopackets per second (kpps), peaking at 250kpps, and between tens to hundreds of megabits per second. It is important to note that the effectiveness of this type of attack relies mainly on the number of packets used. The size of the packets usually is not even that important, and the same applies to the number of megabits.

Since this was not the first time we were subject to DDoS attacks, and since we sadly do not expect this to be the last time either, we started looking for a way to protect ourselves. Of course, we are well aware that it remains difficult to counter an attack that takes up all available bandwidth, but attacks of that nature comprise only a subset of all possible attacks.

The DDoS

While there is a whole range of possible attacks, a few are specially relevant to websites. First, an attacker may simply generate such a large amount of traffic that regular traffic no longer reaches its destination. Such a brute force attack usually consists of UDP or ICMP traffic, but may also consist of bare TCP or even bare IP packets.

A more 'intelligent' way of doing this is to send specially constructed TCP packets that disrupt the network layer. This way, new connections may continuously be half or fully opened so that the lists with open connections get flooded and legitimate users may no longer connect. These attacks are known as SYN and SYN/ACK floods, respectively.

Finally, it is possible to make use of errors or heavy webpages in web applications or bugs in web servers or network layers, for instance by sending a stream of special requests that cause a web server to crash time and again.

The defence

There is not much one can do about a brute force attack, except to discard the surplus traffic as quickly and effortlessly as possible. This way, as little processor power as possible is wasted on the attack, and there will be some capacity left to deal with regular traffic.

SYN and SYN/ACK attacks do not rely on brute force, but rather exploit the fact that a server can only accept so many connections. Especially Apache can be vulnerable to this type of attack. Unfortunately, there are no really good protective measures for these types of attacks at the application level, although some web servers are capable of accepting many more connections simultaneously. Therefore, this type of attack is our primary motive to install an additional protective layer.

The best way of preventing the third type of attack is to keep the software up-to-date. If a piece of software contains a DoS bug, a firewall will probably not be able to do anything about it. In most cases the best defence is to update the software or to change the configuration.

Here at Tweakers.net we always try to make sure that the website operates smoothly and reacts quickly and we have a excessive capacity for dealing with peak loads. This makes that the last variant of DDoS attacks are somewhat less interesting for attackers, partly because these attacks may already be averted by the protection against other types of attack.

Practical experience shows that attackers often try several types of attack and then combine the successful ones. It will be evident that this kind of behaviour makes it even more difficult to set up a successful DDoS defence.

Practical solutions

One of the problems when choosing an appropriate DDoS defence is that its effectiveness will only become apparent in practice. What is even worse is that this solution may lead to false positives - it is of course in nobody's interest to block regular traffic.

To this end, there are countless software-based firewalls available that allow you to set up a basic defence. If you wish to protect yourself from a SYN flood attack, you may find yourself considering iptables rules that limit the number of connections per second. However, these rules may have adverse effects. For instance, if a rule only accepts one connection per second while an attacker is trying to open 99 per second, a legitimate user will only have a one percent chance of reaching the server. This means that it will already be nearly impossible to establish a connection with a server that is under attack by only 99 packets per second.

Other firewall rules are only effective when an attack is poorly set up. For example, it became evident from one of the attacks on Tweakers.net that all traffic originated from the same unusual source port - consequently, blocking it was a mere triviality. Of course, we had to discover this first and, as a firewall is quite busy during a DDoS, that proved to be rather time consuming.

There are also more complex software-based solutions available. While researching the matter we stumbled on a Linux tool named Floodmon. At first, the tool seemed promising, but after a few tests it turned out that this program was hardly more effective than a handful of iptables rules.

In addition, a software-based solution requires a lot of server capacity. An attack of only 350kpps already caused the CPU core responsible for handling network traffic to be fully in use, so it was hardly able to handle legitimate traffic.

To put it briefly, the disadvantage of the software-based solutions on a custom built Linux firewall is that a lot still needs to be managed manually. Moreover, the rules are likely to be either too strict for regular traffic, or too broad to even prevent against attacks. On top of that, a software-based defence does not effectively prevent against distributed attacks consisting of small amounts of traffic originating from many different addresses.

Ironing it out

Hardware-based solutions come in roughly three different shapes. There are, for instance, switches and routers with basic DDoS protection that you are only able to turn 'on' or 'off'. The question is then what gets blocked and what not, whether they are, on the one hand, aimed at preventing damage or, on the other, at keeping the target available, and how you find out that a system is under attack.

In addition, there are generic firewalls available that may be provided with expansion modules to counter DDoS attacks. Some well-known names in this field are Cisco, Juniper and Checkpoint, but these are not the only ones. We do not have extensive experience with these solutions, but, for as far as we know, they are difficult to manage. Moreover, you often have to pay an additional amount for protection against DDoS attacks, while at the same time it was unclear to what extent these systems are able to cope with large numbers of attackers that each generate relatively small amounts of traffic.

Finally, there are appliances available that are customized to counter DDoS attacks. Our new RioRey RX1810 is just that kind of appliance. The companies that dominate this market are largely unknown, at least, to us. As may be expected, this group of appliances also has its disadvantages: your rack has to put up with yet more hardware and worse still, it is one that is only able to carry out one specific task. On top of that, chances are that your supplier may not sell or support such appliances.

The sky is the limit

Another possibility is to buy protection outside of your own rack. In such a 'cloud' defence, all traffic is routed via the network of a service provider; only 'clean' traffic will find its way to your web servers. This may be done on demand during a DDoS attack by modifying routing information. Obviously, your ISP has to support this service to make this work. We did not explore it in any depth, but this approach has the advantage that there is a lot more bandwidth available for dealing with a DDoS attack.

RioRey

As we mentioned before, the market for DDoS protection was largely unknown to us. We would have to base our decision on specifications and sales and marketing material, but fortunately enough our suppliers already have the necessary knowledge and experience. One of our suppliers had just taken its chance with RioRey, a company presenting itself as being 'the DDoS specialist'.

At the time of writing, RioRey offers three series of DDoS appliances. The RE series consists of two reasonably affordable 1U models and is meant to be used with smaller websites. Right above that, there is the RX series offering three 2U models. The highest level consists of the RG: a 7U housing for a maximum of eight blades with a 10Gbit connection each.

The major differences between the RE and RX series are the amounts of computing power and memory. Compared to the RE series, the RX offers more redundancy and sufficient computing power to support IPv6.

All models mentioned above are based on the same RIOS software. This is a adapted version of Linux containing, of course, a software layer for DDoS protection. Among others, there are separate algorithms for TCP, HTTP, UDP and ICMP traffic. The software continuously monitors whether and to what extent traffic has changed during the past few minutes; if any significant change in traffic patterns is detected action is undertaken. The reaction time for a DDoS attack is therefore usually around two minutes.

In addition to redundancy, the RX series offers a 'hardware bypass circuit' that makes sure that, when the service is down, the connection meant to protect the appliance keeps on functioning. This functionality is optionally available for the RE models.

Unfortunately, RioRey has hidden most of its website behind a login, making it somewhat difficult to obtain information about the appliances. Therefore we here provide a brief overview of the most important features of the various models.

	RE series	RX series	RG series
Target	Entry-level	Enterprise	Large enterprise
Models	RE500, RE1500	RX1800, RX2300, RX4400	RG10000
Filtering capacity (kpps)	150/300	300/425/1440	8000
No of protected targets	128	1024	1024
Connections/second	4M conc. sessions	4M conc. sessions	16M conc. sessions
Connections	1000Base-T, -SX of -LX	1000Base-T, -SX of -LX	8x 10GBase-LX
System height	1U	2U	7U
Weight	6kg	12,5kg, 15kg	38kg
Powersupply	Enkelvoudig	Redundant	Redundant
Max. power cons.(230V)	1,25A	1,25A/2A	15A

The prices of the models mainly depend on the chosen network connection. In the case of the RE models one has to think of the price you pay for a somewhat higher end dual processor server; the RX series costs roughly the same amount of money as a more expensive dual processor and a cheaper quad processor computer. For exact prices, we recommend contacting a distributor. For the Netherlands this is Quanza Engineering.

RioRey RX1810

The RX series consists of the models 18, 23 and 44. According to the specifications, these models only differ from one another in the amount of traffic they can handle at the moment a DDoS attack is in progress. This translates to 300kpps, 425kpps and 1.4Mpps in case of the 18, 23 and 44 models respectively. Since we usually have only limited amounts of incoming traffic, we deemed the 300kpps version sufficient. With the smallest packets of 64 bytes this big box is able to handle a good 150Mbps of traffic and with a maximum packet size of 1500 bytes it could even handle a theoretical 3.6Gbps.

The attacks we carried out were frequently above the de 350kpps, so the estimated capacity is probably on the safe side. In such cases the RioRey appliance did suffer quite a burden, though.

By the way, the RX appliances can be furnished with either a set of basic RJ45 plugs, multimode SX/LC optical fibre or single-mode LX/LC optical fibre, which results in 10, 11 or 12 as the model number postfix.

Looks

The RX1810 is a 2U rack mount without sliders. The green front with the fairly large RioRey logo is quite an eye-catcher, but the rest of the appliance looks rather basic and dull. Although we are suckers for appealing industrial design, we of course much rather have the manufacturer invest his money in decent DDoS protection

The construction is robust and professional. The only slightly weaker part is the green board that protects the connections at the front. It is kept in place by two (too) small magnets and fails to close properly even when only one of the cables comes down through the opening at ever so slight an angle.

Traffic is led through the appliance by means of two network cables. The appliance is further furnished with a serial and a network port for the management interface. To provide you with status reviews at its location the appliance has been furnished with three LEDs that indicate its status and which show whether there is a DDoS attack in progress.

The interior

Since we would really like to keep the guarantee on our brand-new RX1810 valid, we refrained from opening up the appliance. However, we were able to get a closer look at the interior of a demonstration model. Thus, we found out that the interior comes across as being both professional and reliable. Cable management is not quite as streamlined as it is in the Sun and Dell servers which we have bought recently, but everything is connected firmly and in a practical manner.

The CPU cooling is a gigantic cooling block that is placed right in front of the system fans thanks to its heat pipes. The CPU is a regular AMD Opteron dual core with an aggregate 16GB RAM. Flash memory has been installed for permanent storage.

The network card and monitoring hardware that are supplied with the RioRey are something special, but from the outside it is difficult to see what their exact function is. The network card at least comes equipped with the previously mentioned hardware bypass, which turns the appliance into a somewhat overpriced RJ45 coupler; the traffic along the cables will be put through unchecked. This mode is switched on, for example, when the appliance carries out an update or when the power is disconnected from the appliance. This way, the servers behind the RioRey are always available.

Web interface

In addition, the RX1810 comes equipped with a basic web interface. In particular, it allows you to set up the basic configuration for the management interface. Things that can be configured are the IP address and the various external servers such as NTP, SMTP, DNS, SYSLOG, RADIUS and SNMP.

It is almost refreshing to see how stripped down the interface is: it contains some basic HTML forms and tables set against a pale orange background and that is about it. The idea is that you only spend a few minutes here to configure the appliance. Afterwards, the appliance can be completely managed from the rView console.

The rView management console

The RioRey is monitored and controlled through the rView console. This is a Java application that is able to communicate with one or more RioRey appliances through an SSH tunnel.

Updating the RIOS software is very straightforward: just load the new system definition into the appliance, indicate that an update has to be carried out and one reboot later you are done. The whole process only takes a few minutes of your time. Should anything go wrong, you can revert to a previous version in exactly the same way. During the upgrade, the network card is put in the hardware bypass mode, thus ensuring that the protected servers remain available.

The software is updated on more than a regular basis. RioRey does not employ a fixed schedule for updates - however, when we started our review we were using version 5.0.2, and by the time we were finishing it we could welcome version 5.0.5. It did not have any marked effect on the test results which version we used, so we did not repeat any of them.

However, it should be noted that the 5.0.5 update comes with protection against Slowloris. We tested it, of course - it turned out that the RX1810 is able to handle even those slow DoS attacks that hardly generate any traffic.

Operation

When the software is started an overview of the 'sensor network' is shown. Here you can check the status of all the RioRey appliances. You have to look around a bit to find certain settings and information, but it is not a configuration labyrinth, so with only a few clicks you will have found your way. There are two levels: system level and interface level.

At system level you can check the general status of the machine, such as the status of the various components, and CPU and memory load. In addition, at this level you can manage accounts, configure alerts and check various log files. Moreover, it is possible to renew the licence and carry out updates at this level.

At interface level, the application provides an overview of the network load of the LAN or WAN interface in question. In the basic versions of the RioRey appliances only incoming traffic is filtered and the application gives a fairly detailed overview of incoming traffic broken down into protocols (IP, TCP, UDP, ICMP) and per protocol into the percentage of bad packets and bytes and the number of invalid, filtered and whitelisted packets and bytes.

You can also configure the behaviour of the filters for every interface. Although we noted earlier that the RX1810 is not a firewall, it does contain a number of settings that relieve some of the workload of a firewall. For instance, there is a setting that allows you to block ICMP, UDP, non-IP and invalid packets and it is also possible to block traffic for local networks. In addition, the application offers three interface settings: 'filter' activates DDoS protection and 'monitor' analyses traffic but does not filter it. When set to 'bypass' the RioRey once again functions as an upgraded coupling device.

You can put a list of IP addresses on a whitelist or on a blacklist. Despite the fact that the application stores a mask with it, every IP address needs to be entered separately. This makes configuration somewhat toilsome when many IP addresses need to be entered into one (or both) of the lists.

The 'Service Definitions' deserve special mention as well. These allow you to indicate which traffic belongs to which IP addresses in the proprietary network. It is, for instance, possible to configure a web server in such a way that it only allows incoming TCP traffic to pass through ports 80 and 443. Other traffic is blocked, which, according to RioRey, has the effect of unburdening to a degree the (more complex) firewall at a spot further down the network.

Reporting

In addition to all these settings, rView offers an overview of the status of the various filters. Graphs show the amount of incoming traffic and the amount that is allowed to pass through. Per filter there are six 'confidence' levels that indicate to what extent traffic patterns resemble a DDoS attack. From level 3 upwards the appliance starts to filter incoming traffic.

The level is raised whenever successive analyses detect the same amount of (or more) suspicious traffic. In addition, the share of traffic involved in an attack is colour coded: traffic that is less than 5 percent suspicious gets a green colour, between 5 and 10 percent it gets a yellow colour, a percentage between 10 and 50 is coloured orange and if more than 50 percent of traffic is suspicious, the graph turns red.

If a filter reaches one of the two highest levels, the appliance in question in the 'network sensors' overview will turn orange or red, respectively. Moreover, an LED is switched on and warning e-mails and SNMP traps are sent.

To determine the load on the connection and how much of it is attack traffic, rView can produce various graphs. Subject to a slight delay, these graphs represent the latest traffic overview - both the aggregate amount of traffic and the amount after filtering are shown.

In addition, it is possible to request an overview of targets (or 'victims', as RioRey calls them, even though the appliance should of course stop the attacks before there are any victims) and attackers. The last overview in particular is somewhat redundant during a large DDoS attack because of the large number of entries. However, during regular use it is a useful overview to establish whether legitimate traffic gets blocked by accident. Moreover, it can be gathered from this overview that from some attackers only a few packets are stopped, while their IP address does not get blocked. It is also possible to enter IP addresses from this list into whitelists and blacklists.

Test setup

In practice, it turns out to be rather difficult to carry out a good DDoS in a limited testing environment. During one of our first simulations we actually managed to completely flood the MAC address tables of our office switches and consequently we crippled the entire office network. Generating varied legitimate traffic is not a small feat either. Unfortunately, our budget did not allow us to use expensive testing hardware from companies such as Spirent or Ixia, so we had to make do with packet generator software running on a regular PC.

Our testing environment was set up to resemble the situation in our server rack. To this end, we used two HP Procurve 2520G-8 switches for incoming traffic. Both were coupled to an internal network switch, with one of the two made more important by configuring the priorities in the spanning tree. This switch was protected by the RioRey RX1810.

Behind the internal switch an old SuperMicro server with two Opteron 275 dual cores and 2GB RAM was set up. Thanks to its rather limited capacity, this server is ideal for observing the effects of a DDoS. We also used two discarded Dell 1950s, each containing two Intel Xeon 5150s, 4GB RAM and Broadcom NetExtreme II 5708 network chips to generate the incoming traffic - one for legitimate traffic and one for carrying out the DDoS attack.

Both systems were furnished with a recent Debian installation and a 2.6.32 kernel. The server runs lighttpd, version 1.4.26, with which a few statistic files can be served out.

Legitimate traffic

The 'good' traffic was produced by curl-loader, with which one thousand unique IP addresses were generated. These addresses sent around 1250 requests per second, resulting in 8000 packets per second, or 6Mbps of incoming traffic. Subsequently, we let this program download various files, ranging in size from 100 bytes to 100KB; the smaller files were requested more often to simulate requests for images, javascript and CSS files, etc. The server responded to these requests with approx. 16,000pps, using up a bandwidth of about 190Mbit.

The requests from curl-loader were responded to with a delay of about 1ms on average; unfortunately, the application is not able to make a more precise measurement. However, since the delay increases markedly during a DDoS attack, the differences are noticeable enough.

There are, of course, some differences with the real setup of Tweakers.net. In reality, there are many more types of requests and also the response times differ more widely than during this test. For instance, we found during a TCP attack that our setup could inadvertently dupe the RioRey: after all, there were 'only' one thousand addresses simultaneously making a request each second. This did not seem to be a problem in other attacks, so we cheated by whitelisting the 'good' IP addresses.

Boom box

The DDoS PC was equipped with two software packages to generate random network traffic. To begin with, we used the random packet generator hping3 to generate sizeable amounts of basic, random attack traffic. Hping is a 'fire and forget' tool that is not able to set up real TCP connections. However, the tool is able to generate about 300,000 packets per second and, although not really suggested by the name, in addition to ICMP traffic it is able to generate UDP and TCP traffic. Using two hping3 processes on our DDoS PC we sent around 350,000 packets per second to our web server.

We used BoNeSi to establish full TCP connections, so that it would also be possible to do something with the incoming return traffic. BoNeSi is short for 'BotNet Simulator'. This tool opens real connections from random addresses and, after a connection has been established, is able to carry out HTTP requests.

Attack!

In our tests we aim to keep the number of requests per second from the 'good' client as stable as possible when an attack is carried out. This way, we can compare the statistics of curl-loader in 'peace time' to those generated during DDoS simulations.

To put the performance of the RX1810 in context we have also carried out attacks on the same server using only an iptables firewall. In addition, we tried to tweak the network settings, for instance with FloodMon. This tool did not live up to the expectations, therefore we omitted the corresponding results.

We have carried out the following attacks leading to the corresponding availability of the server:

Attack	No protection	Linux firewall	RioRey RX1810
TCP/SYN flood, port 80	0,6%	4,6%	90,6%
UDP flood, port 80	9,5%	10,9%	100%
ICMP flood	8,8%	10,1%	100%
ICMP flood, 1500 bytes	4,7%	33,4%	100%
TCP data flood, port 80, 1500 bytes	15,2%	17,0%	76,9%
TCP connections, port 80	4,9%	5,3%	100%
DNS reply flood	0%	90%	0%1

1. With this form of protection all UDP traffic on port 53 was blocked, though whitelisting DNS servers does offer a solution.

In the table above you can find the availability percentages that were measured after the RioRey was able to react. Our test server may therefore have been unavailable during the first 90 seconds.

TCP/SYN flood on port 80

The aim of a SYN flood is to request as many connections as possible. Whenever a lack of resources occurs, regular connection requests are no longer accepted.

In the case of the unprotected server (SYN cookies were used, though) the SYN flood caused the website to be practically unavailable - only the odd request seemed to filter through. Using the iptables gave a somewhat better result, although the server remained largely or even completely unavailable. The RioRey was a great asset in this type of attack - availability only dropped to a little above 90 percent.

What we see in this type of attack, as in some others, is that the legitimate client is not able to fully recover itself following the DDoS attack. Insofar as we have been able to verify, this is mainly caused by not properly closing the connections that have been set up. As soon as the added IP aliases of the client were removed and the curl-loader application was restarted, the number of requests did again reach about 1250 requests per second.

UDP flood on port 80

In a UDP flood, very many random packets are produced. This test is therefore mainly concerned with the server's processing capacity.

Although the unprotected server seemed to be better able to withstand this type of attack than a SYN flood, its availability still fell far short of satisfactory. Remarkably enough, using an iptables rule to drop all UDP traffic on port 80 did very little to alter this situation. There is probably not much of a difference between 'ignore UDP traffic on port 80' and 'immediately throw away all UDP traffic on port 80'.

However, the RioRey was very well capable of dealing with this type of attack - it was so effective in blocking bad traffic that, even during the first few minutes, the client did not even notice the UDP flood.

ICMP flood

The aim of an ICMP flood is the same as that of a UDP flood. Therefore, what matters is the processing capacity of the various network devices. As a result, the effect on the server was nearly the same as with UDP. Also in this case the RX1810 - after having discovered the attack - blocked all attack traffic. By the way, it is possible to block all ICMP traffic and we do not doubt we would have got the same result as in the UDP flood.

ICMP flood with 1500B packets

This type of ICMP flood works with substantially larger packets, which allows it to reach the maximum capacity of the network connection. According to the RX1810, interface load during this test increased to 95 percent, the highest value we have measured in any of the tests.

In this type of attack, the availability of the unprotected server was even worse than when it experienced a stream of small ICMP packets. The server that was protected with iptables, and which threw away all ICMP traffic, did show some better results this time. After about ten minutes, availability stabilised in one third of all requests. It seems that for the RioRey the size of the ICMP packets is a sign that something is wrong: this attack was blocked right from the very first packet.

TCP flood with 1500B packets on port 80

In this type of attack, traffic is generated that bears a resemblance to web traffic, but without setting up a connection first. In theory, since this traffic is not related to known connections, protection could easily consist of an iptables firewall with connection tracking. In this case, it should be difficult for the RioRey to distinguish between attack packets and legitimate packets.

Compared to the other attacks, the unprotected server did a relatively good job - an even better one than during the ICMP flood with large packets. Despite the connection tracking feature, the iptables firewall was not much of a help. As expected, the RioRey did have quite a hard time handling the attack. Since there was a continuous stream of requests from a relatively small number of legitimate clients, requests that did not have anything to do with the attack were blocked as well.

However, we believe that, in practice, this attack will have less severe consequences: the requests of our real visitors do not exhibit the regularity of the requests of our legitimate client. However, in this test, even after whitelisting the good clients, the number of legitimate requests per second was lowered by approximately 20 percent.

TCP connection flood on port 80

The aim of this attack, again, is to open as many connections as possible, so that legitimate requests can no longer pass through. As opposed to other types of attack, the connections are fully opened and are even harder to distinguish from those of legitimate clients.

The unprotected server seemed to be quite at a loss here. The number of requests per second that could pass through fluctuated heavily, but remained below 20 percent most of the time, while at certain moments nothing could pass. The iptables protection did not offer much of a solution - traffic patterns became more constant, but availability hardly improved.

This type of attack relies on IP addresses that really exist. The number of different IP addresses is therefore more limited than in a fully random generated attack. This became very evident when we viewed the results: the attackers were detected without much of a delay and were blocked for a longer period of time.

DNS reply flood

In this type of attack, source port 53 was used to send random UDP traffic. These packets are hard to distinguish from traffic generated by DNS servers, which, in theory, makes it impossible to use DNS servers.

Sure enough, in the case of the unprotected server it turned out to be impossible to carry out any more DNS lookups. With regard to the server protected with iptables and connection tracking, traffic was as yet hindered, but nearly all DNS replies reached their goal.

The RioRey does not make use of connection tracking and is therefore not able to make a clear distinction between attack and legitimate replies. However, one can create a good work-around by configuring the IP addresses of several known DNS servers to legitimate sources of traffic.

Conclusion

The RioRey appliance does its job. Most of the attacks we carried out were stopped completely, and in the other cases a much larger share of the legitimate traffic could pass through than without protection. The RX 1810 would have successfully warded off the attacks made on Tweakers.net in August and September 2009.

Another advantage is that RioRey offers 24-hour support on their products, so you are not left to your own devices when you are under attack. In the unlikely event a DDoS is not warded off, the experts of RioRey can think up an ad hoc solution together with you. In practice, this will most likely come down to RioRey doing most of the work, while we sit and wait until the problem is fixed

Our home-made firewall was not much of a match for most of the attacks. On top of that, iptables is tucked away pretty deeply in the kernel and zero routing for IPs and IP ranges would be more efficient - this, however, requires detailed scripting and a lot of manual work. There probably are better ways to configure the network, but we do not expect to gain much by that.

At the moment of writing, the RioRey has spent a few days in our rack and it looks like it does not inadvertently block legitimate traffic. This does not mean that in the long run or during a DDoS attack not a single legitimate request would be thrown away - but at least it is a hopeful sign that, for now, there are no false positives to report.

There is, of course, also some room for improvement. The finishing of the appliance is satisfactory, but not top-notch; especially the front board deserves some reconsideration. It would definitely be an idea to put a lock on it: after all, it needs to protect the uplink to your network.

Another point to be reconsidered is the practicability of the rView application - the traffic graphs are somewhat hard to manage, for instance. In addition, it is bothersome that the status is displayed with a delay, although this is probably inherent to the way the application works. It is worse that IP ranges can nowhere be defined; each and every address, whether approved or rejected, needs to be entered separately.

However, we are left with a general feeling of contentment. Obviously, we hope there ultimately was no real reason to install our RioRey - but if the worst comes to the worst, we will in any case be well prepared.

We would like to thank Quanza Engineering, both for the test appliance and all the answers to our torrent of questions about the RioRey.

Reacties (1)

[Jaccoh]

Erg goed artikel. Vind ik tenminste erg interessant vanuit mijn vak gezien. Maar ik mis 1 ding. Wat kost dat?