Website Construction
Tarpit & iptables: anti-DDOS fatal arms!
Submitted by maxtor, 23-06-2015, 11:45 AM, Thread ID: 5002
Thread Closed
23-06-2015, 11:45 AM
#1 An enemy apart!
The problem is, well, simple:
In computer security, nowadays we know deal with the vast majority of threats. If we focus on the server side and on Linux, Grsex / Pax, a blow of hardening, static and optimized kernel, chroot and my faith one is not bad ...
Demons like Apache and MySQL, as well as interpreters like PHP or Perl, are protected against their intimate enemies, the overflows. The separate rights, protected trees, the filtered connections, what can be done? For example separate back office to another vhost to add an htaccess to protect, audit the site against conventional vulnerabilities, XSS, SQL injection etc ...
Well ... What you have left it, one or two mechanisms to protect but ... The DDOS is fatal.
Know your enemy!
The DDOS - Distributed Denial Of Service - this is the great fear of any e-retailer, of any site earning money online and most importantly, your outsourcer ...
A distributed denial of service is to send thousands, tens of thousands, hundreds of thousands of requests simultaneously. If we limit the discussion to the Web sites, simply, in general, to take 10 on 50 000 concurrent connections for a server to kneel and / or internet servers.
These innumerable connections arrive, usually from compromised machines, from all over the world. These machines are compromised by worms, for example Confliker or other more discreet, slumbering in PCs for months, listening for orders. These machines, known as zombies, are part of networks called botnets.
Then it's unfortunately a devilish simplicity. A kiddy script (or even a real hacker) pay a few dollars handles and simply praise the power of a botnet. How many machines, how long, what commands to be launched. Simple, extremely effective, unstoppable ...
The machines take orders and within minutes, hundreds thousands of connections rain on the target site.
How to avoid D.D.O.S?
A DDOS is based, not gasoline, compromised machines, mostly individual PC beasts.
Obviously we can not have a direct effect on these machines. Remotely disinfect is not possible, no more than would be allowed the rest.
Then lock these machines one by one in a firewall is useless impossible. Impossible because of the volume, block unnecessary as these connections will not stop the hacker to send others to send more and anyway, if the servers are not creaky, it'll be the Internet connection servers.
Damned, we are done?
No. Rather than studying the problem in terms of what we can not do, rather see what our attackers can not do:
It is not possible for the hacker to actually patch the kernel compromised Windows machines. If a worm behaved that way, it would be much less effective (captured by anti virus) and much less mobile (depending on versions of Windows). Therefore, to rotate generally above in the software layer. Result, they are forced to do what the application layer below ...
And that's where this is the fault of these attacks, these worms. If we manage to force the machines to stop sending packets using TCP subtlety, the driver of the network card will be obliged to act and this set him straight to the core level, so overrides the layer software
Here is a beginning solution seems you ...
Tarpit: tar and feathers!
Rule number one of the Blog: the more, the less it is read ... I'll make it short and I will not explain how to set up a Linux kernel and compile it, just for the iptables binary. You will find the kernel here: ftp.kernel.org and a lot of googling survival guide.
Otherwise I have written a long ago, but it should help you, ca be found here. there are things quite outdated, inaccurate things in the examples of firewall but I have not had time to fix it. That said, you can go from there. you will need to also recompile the iptables binary via the patch-o-matic, everything is explained here.
But why iptables and Tarpit are our friends?
The tarpit rule, and there are other ways to do this obviously helps to inform our friendly zombie PCs they are asked to wait to be recontacted them before sending the next packet network. Windows machines, as most recent OS from the rest, respects the "window resizing".
When you adjust the window (window) communication to zero size, the remote machine remains in a waiting state until we furnish a normal size at the TCP window.
But what happens if you never return the window to normal size? Well the machine waits ... And this is where the solution lies. The connection will block until the OS to clean house in its inert connections!
It may take time ... a lot of time in fact, even our remote machine is acharnerait redoing a connection with each new attempt, it will block a little more his own "stack tcp", its own management system network ... It'll take some time but it is well slow down the attack, especially since most machines do not ressayeront since the connection is not dead, she's just "pause".
How and to whom apply the Tarpit?
Simply taping the connection 1 2 hitter in dropant the package to us not to burden unnecessarily. History to keep it simple, we'll create a rule that can do it all at once.
Ok, but if we make a tarpit of all incoming traffic with iptables -I INPUT TARPIT_DROP -P or the same as FORWARD, we will lose all incoming traffic, including real customers of the site ... It may be a bit unpleasant for people who have nothing to do.
To sort the wheat from the chaff, we will have to outsmart the "bots", zombies, who attack us. It is possible to do some sorts with IDS Snort as such or otherwise analyze the logs and queries, or even the pace of connections.
When you think about it, it is quite simple to recognize a club because he always does the same thing in general (eg a get /blabla.php) and / or uses a precise frequency (eg every 5 seconds).
If using an IDS, it is he who will drive firewalling rules (flex rules) directly when it detects abnormal behavior. If you want to use a parser logs, it is very simple to give him the "pattern" of the attack (eg a get /blabla.php every 5 seconds) and to ban all machines using this pattern .
If it's a specific page referenced (blabla.php for example) it is also possible to detect the contents of the package (except https) word blah and to prohibit actually tarpiter the appellant machinery . Certainly the people actually calling for good reasons the blabber page will be disappointed, but the others will be blocked too. If ca takes place on the homepage, this method is not applicable, but otherwise:
We have other possibilities, with the mod geoip for example, or in tarpitant incoming connections that are similar networks (eg 49.230.xxx.xxx)
It is possible to limit a function of the number of packets and the type of packets received per second. Iptables is actually an ideas factory limitless. The attacks can take many forms but the answer can also be quite polymorphic in his way with iptables!
Use a subtle mix of parameters limit and burst-limit may help stem the network packet streams too "supported".
Mix -string subtly to identify content and -limit for rhythm, -state for the connection status and other tests, this can also allow interesting results in terms of detection:
There by cons, much has limited tarpites people who are actually doing that a new connection more often than every 6 seconds or if they call the chain blah at the same frequency. Another variant?
The parameter "Syn cookie" in the kernel also makes sure that a wise guy is not a sudden flood of SYN us only because if it does not comply with his connection, it will not be maintained, it is an indispensable element of protection. And if our assailant is very "old" and your very antiquated system, it uses a ping flood, iptables -A INPUT -p icmp -m limit --limit 1 / s --limit-burst 1 j ACCEPT, should be limited ambitions.
If you place an IDS, you have to analyze yourself the attack, his method and form to determine the most appropriate method to respond.
The analysis is a vital point and Tarpit a fatal response.
More fun with Tarpit?
Well let's be clear, we can go further in the fun.
For example a person who scans the machine will use a scanner that will be used sequences known TCP (SYN scan, Xmas Scan etc ..) or even a sequence of ports, linear (1,2,3 etc ...), specific growing (21,22,23,25,80 for example) or random (443,22,53,80,21 example).
In all these cases, one can use as a demon knocked eg a port knocking daemon to identify a scan sequence. Once you've identified the knocker port is supposed to open the connection for the person who does the right sequence. Let us reverse since it is a pirate, and forbid him access to the crossing tarpitons a helping ...
The funny thing is that we will maintain the IP Tarpit and thus cause a blocked connection port and scanned there ... pretty quickly ... his machine will severely block the network side
So in the end, Tarpit is fun right? There are many other options you can find in the kernel or in the patch-o-matic, all can lead to very useful mixtures.
The problem is, well, simple:
In computer security, nowadays we know deal with the vast majority of threats. If we focus on the server side and on Linux, Grsex / Pax, a blow of hardening, static and optimized kernel, chroot and my faith one is not bad ...
Demons like Apache and MySQL, as well as interpreters like PHP or Perl, are protected against their intimate enemies, the overflows. The separate rights, protected trees, the filtered connections, what can be done? For example separate back office to another vhost to add an htaccess to protect, audit the site against conventional vulnerabilities, XSS, SQL injection etc ...
Well ... What you have left it, one or two mechanisms to protect but ... The DDOS is fatal.
Know your enemy!
The DDOS - Distributed Denial Of Service - this is the great fear of any e-retailer, of any site earning money online and most importantly, your outsourcer ...
A distributed denial of service is to send thousands, tens of thousands, hundreds of thousands of requests simultaneously. If we limit the discussion to the Web sites, simply, in general, to take 10 on 50 000 concurrent connections for a server to kneel and / or internet servers.
These innumerable connections arrive, usually from compromised machines, from all over the world. These machines are compromised by worms, for example Confliker or other more discreet, slumbering in PCs for months, listening for orders. These machines, known as zombies, are part of networks called botnets.
Then it's unfortunately a devilish simplicity. A kiddy script (or even a real hacker) pay a few dollars handles and simply praise the power of a botnet. How many machines, how long, what commands to be launched. Simple, extremely effective, unstoppable ...
The machines take orders and within minutes, hundreds thousands of connections rain on the target site.
How to avoid D.D.O.S?
A DDOS is based, not gasoline, compromised machines, mostly individual PC beasts.
Obviously we can not have a direct effect on these machines. Remotely disinfect is not possible, no more than would be allowed the rest.
Then lock these machines one by one in a firewall is useless impossible. Impossible because of the volume, block unnecessary as these connections will not stop the hacker to send others to send more and anyway, if the servers are not creaky, it'll be the Internet connection servers.
Damned, we are done?
No. Rather than studying the problem in terms of what we can not do, rather see what our attackers can not do:
It is not possible for the hacker to actually patch the kernel compromised Windows machines. If a worm behaved that way, it would be much less effective (captured by anti virus) and much less mobile (depending on versions of Windows). Therefore, to rotate generally above in the software layer. Result, they are forced to do what the application layer below ...
And that's where this is the fault of these attacks, these worms. If we manage to force the machines to stop sending packets using TCP subtlety, the driver of the network card will be obliged to act and this set him straight to the core level, so overrides the layer software
Here is a beginning solution seems you ...
Tarpit: tar and feathers!
Rule number one of the Blog: the more, the less it is read ... I'll make it short and I will not explain how to set up a Linux kernel and compile it, just for the iptables binary. You will find the kernel here: ftp.kernel.org and a lot of googling survival guide.
Otherwise I have written a long ago, but it should help you, ca be found here. there are things quite outdated, inaccurate things in the examples of firewall but I have not had time to fix it. That said, you can go from there. you will need to also recompile the iptables binary via the patch-o-matic, everything is explained here.
But why iptables and Tarpit are our friends?
The tarpit rule, and there are other ways to do this obviously helps to inform our friendly zombie PCs they are asked to wait to be recontacted them before sending the next packet network. Windows machines, as most recent OS from the rest, respects the "window resizing".
When you adjust the window (window) communication to zero size, the remote machine remains in a waiting state until we furnish a normal size at the TCP window.
But what happens if you never return the window to normal size? Well the machine waits ... And this is where the solution lies. The connection will block until the OS to clean house in its inert connections!
It may take time ... a lot of time in fact, even our remote machine is acharnerait redoing a connection with each new attempt, it will block a little more his own "stack tcp", its own management system network ... It'll take some time but it is well slow down the attack, especially since most machines do not ressayeront since the connection is not dead, she's just "pause".
How and to whom apply the Tarpit?
Simply taping the connection 1 2 hitter in dropant the package to us not to burden unnecessarily. History to keep it simple, we'll create a rule that can do it all at once.
Code:
iptables -N TARPIT_DROP
iptables -j TARPIT_DROP tarpit
j DROP iptables TARPIT_DROPTo sort the wheat from the chaff, we will have to outsmart the "bots", zombies, who attack us. It is possible to do some sorts with IDS Snort as such or otherwise analyze the logs and queries, or even the pace of connections.
When you think about it, it is quite simple to recognize a club because he always does the same thing in general (eg a get /blabla.php) and / or uses a precise frequency (eg every 5 seconds).
If using an IDS, it is he who will drive firewalling rules (flex rules) directly when it detects abnormal behavior. If you want to use a parser logs, it is very simple to give him the "pattern" of the attack (eg a get /blabla.php every 5 seconds) and to ban all machines using this pattern .
If it's a specific page referenced (blabla.php for example) it is also possible to detect the contents of the package (except https) word blah and to prohibit actually tarpiter the appellant machinery . Certainly the people actually calling for good reasons the blabber page will be disappointed, but the others will be blocked too. If ca takes place on the homepage, this method is not applicable, but otherwise:
Code:
iptables -I INPUT -p tcp -m -s 0.0.0.0/0 -dport 80 -string string "blah" j tarpitWe have other possibilities, with the mod geoip for example, or in tarpitant incoming connections that are similar networks (eg 49.230.xxx.xxx)
It is possible to limit a function of the number of packets and the type of packets received per second. Iptables is actually an ideas factory limitless. The attacks can take many forms but the answer can also be quite polymorphic in his way with iptables!
Code:
-m limit -limit 2/80 second -dport -syn j ACCEPTUse a subtle mix of parameters limit and burst-limit may help stem the network packet streams too "supported".
Mix -string subtly to identify content and -limit for rhythm, -state for the connection status and other tests, this can also allow interesting results in terms of detection:
Code:
iptables -I INPUT -p tcp -m -dport 80 -string string "blah" -m limit -limit 1 / 6s -limit-burst 1 -m recent -name DDOSbot -set
iptables -I INPUT -p tcp -dport 80 FORWARD -m recent -name badguy -set j TARPIT_DROP
iptables -I INPUT -m state -state NEW -m limit -limit 1 / 6s -limit-burst 1-j TARPIT_DROPThere by cons, much has limited tarpites people who are actually doing that a new connection more often than every 6 seconds or if they call the chain blah at the same frequency. Another variant?
Code:
iptables -I INPUT -m state -state NEW -m recent -update -seconds -hitcount 20 4 j DROP
INPUT -p tcp iptables -m limit --syn --limit 1 / s --limit-burst 3 -j RETURNIf you place an IDS, you have to analyze yourself the attack, his method and form to determine the most appropriate method to respond.
The analysis is a vital point and Tarpit a fatal response.
More fun with Tarpit?
Well let's be clear, we can go further in the fun.
For example a person who scans the machine will use a scanner that will be used sequences known TCP (SYN scan, Xmas Scan etc ..) or even a sequence of ports, linear (1,2,3 etc ...), specific growing (21,22,23,25,80 for example) or random (443,22,53,80,21 example).
In all these cases, one can use as a demon knocked eg a port knocking daemon to identify a scan sequence. Once you've identified the knocker port is supposed to open the connection for the person who does the right sequence. Let us reverse since it is a pirate, and forbid him access to the crossing tarpitons a helping ...
The funny thing is that we will maintain the IP Tarpit and thus cause a blocked connection port and scanned there ... pretty quickly ... his machine will severely block the network side
So in the end, Tarpit is fun right? There are many other options you can find in the kernel or in the patch-o-matic, all can lead to very useful mixtures.
RE: Tarpit & iptables: anti-DDOS fatal arms!
23-06-2015, 11:48 AM
#2 RE: Tarpit & iptables: anti-DDOS fatal arms!
RE: Tarpit & iptables: anti-DDOS fatal arms!
23-06-2015, 11:55 AM
#4 RE: Tarpit & iptables: anti-DDOS fatal arms!
RE: Tarpit & iptables: anti-DDOS fatal arms!
23-06-2015, 12:26 PM
#6 RE: Tarpit & iptables: anti-DDOS fatal arms!
23-06-2015, 01:28 PM
#7 Thanks for this awesome thread bro. Gives me alot of new informations.
RE: Tarpit & iptables: anti-DDOS fatal arms!
23-06-2015, 02:56 PM
#8 23-06-2015, 01:28 PMScream Wrote: Thanks for this awesome thread bro. Gives me alot of new informations.
Do you understand what this thread is all about partner?
Unless you have a dedicated server Tarpit and IPTables can't be used by you. Are you using a dedi as your hosting server for your site/network?
Sorry, but I don't like these kinds of random posts on great informational threads. If the thread doesn't have anything to do with you then don't post in it. I'm sure the information in this article isn't of use to you.
RE: Tarpit & iptables: anti-DDOS fatal arms!
24-06-2015, 03:42 AM
#9 You can on a VPS.23-06-2015, 02:56 PMGodsHand Wrote:23-06-2015, 01:28 PMScream Wrote: Thanks for this awesome thread bro. Gives me alot of new informations.
Do you understand what this thread is all about partner?
Unless you have a dedicated server Tarpit and IPTables can't be used by you. Are you using a dedi as your hosting server for your site/network?
Sorry, but I don't like these kinds of random posts on great informational threads. If the thread doesn't have anything to do with you then don't post in it. I'm sure the information in this article isn't of use to you.
RE: Tarpit & iptables: anti-DDOS fatal arms!
24-06-2015, 03:45 AM
#10 24-06-2015, 03:42 AMKill Wrote:You can on a VPS.23-06-2015, 02:56 PMGodsHand Wrote:23-06-2015, 01:28 PMScream Wrote: Thanks for this awesome thread bro. Gives me alot of new informations.
Do you understand what this thread is all about partner?
Unless you have a dedicated server Tarpit and IPTables can't be used by you. Are you using a dedi as your hosting server for your site/network?
Sorry, but I don't like these kinds of random posts on great informational threads. If the thread doesn't have anything to do with you then don't post in it. I'm sure the information in this article isn't of use to you.
Yup you can on a VPS too sorry for that meant to include.
Users browsing this thread: 4 Guest(s)