The Best Booter For Layer4 OR Layer7 Network

Booter usage splits to two main groups:
Layer 4 methods which are made to stress test IP addresses (usually called ip stresser tool).
Layer 7 methods which are made to stress websites (URL only).

Your first goal would be to understand which what you are looking to stress test, an IP address (servers) or a website. The next step would be to choose the right method for your stress test. Each booter may offer different methods but I will try to explain and categorize them for you.

Layer 7 methods:
GET/HEAD/POST – Stress testing method done with proxies, launches a few thousands requests per second using one of the following HTTP request: GET, HEAD or POST. This method is the oldest one but since it’s done with a unique ip address and a unique user agent, it’s hard to mitigate it.
XMLRPC – The XMLRPC method is a reflected method. XMLRPC is a WordPress service which can be use to generate XML requests to websites. It’s fairly easy to mitigate since it uses the same useragent every time.
Joomla – The Joomla method is actually a Google Maps plugin made for the Joomla CMS which can be used to generate GET requests as well. It’s pretty similar to XMLRPC and it can be mitigated easily as well since it uses the same user agent in every request.

Layer 4 methods:
Layer 4 methods usually have 3 different categories:
*Amplified UDP methods – These are usually services (for example: DNS, NTP, CHARGEN, SSDP etc) that can be used to amplify (reflect) a packet with a bigger size packet, or even more packets. Using this methods also requires spoofing the source IP address of the server. So let’s say the target IP address is 127.0.0.1, so the stress testing server sends a packet with a certain payload over a certain port with the source ip address of the target (127.0.0.1) to the amplifier server. The amplifier server receives the packet and sends a bigger size packet (or a number of packets) to the target ip address (127.0.0.1) therefore resulting in an amplified stress test. With a 1Gbps uplink, an amplified stress test can reach over 80Gbps of bandwidth using the NTP service. This method is the most common one to use with a Layer 4 stress test on a booter.
*Raw UDP – Sends a large number of UDP 1024 length packets. It’s the oldest method and easily mitigated when done from only a few servers because the IP address remains the same in each packet.
*Spoofed TCP – This method also requires spoofing the source ip address but in this case the packets are not amplified but simply sent via a random IP address which does not belong to the server. This method has various names (ssyn, tcp, essyn etc).

When using an ip stresser, there is no best method, the best way would be testing each method and see which one suits you the best.

the Best ip website booter stresser ddos

This profound question seems to still be quite a bit of a mystery. We all have a rough idea of what it’s like but most people don’t really know what it’s all about. So this post is here to answer what is an ip stresser  / website DDoSer / HTTP Flooder or by its second name, a booter .

A booter is a tool designed to stress test your servers against heavy load of traffic. What does it mean? Let’s say you have a website which sells shirts. You have a constant flow of about 100 visitors every day, but sometimes this number can spike drastically (Black Friday for example). In most cases what happens is that your website or server is not well designed for a high number of visitors (let’s say 50 visitors at the same time) and it will most likely load very slow or just crash. Here comes the IP stresser to the picture. Using this tool you can design your website or server to better handle the sudden spike of traffic and therefore serve a large number of visitors at the same time.

Another example would be stimulating a DDoS attack. If your website is a target to such malicious attack, you would want to adjust it to handle this type of attacks without block real visitors from viewing your website. Most booters are equipped with tools and information on how to protect your business from such attacks.

A DDoS Attack Explained: TCP SYN ACK Flood

Continuing on with explanations of attack vectors, we will be discussing a TCP SYN ACK flood. A TCP packet with the SYN ACK flag enabled is used as part of the three step process involved with establishing a TCP connection.

1. SYN packet. During this stage, a client (such as a desktop computer, laptop, or smartphone) initiates an outgoing connection to a server (such as a web or gaming server).
2. SYN-ACK packet. The server responds with an acknowledgement of the initial request, signaling it is ready to finish initiating the connection.
3. ACK packet. The client sends a final acknowledgment, signifying that both the client and server are ready to send and receive data.
This process is known as a “three-way handshake”.

A TCP SYN ACK flood involves sending a large amount of TCP packets with both the SYN and the ACK bit enabled on it. This kind of flood is very similar to the more common SYN flood.

First, let’s take a look at what an SYN ACK flood looks like. This is a spoofed SYN ACK flood against server IP address 10.100.101.102 on port 80.

12:43:52.835860 IP 240.26.181.120.1696 > 10.100.101.102.80: Flags [S.], seq 2130742457, ack 1965920245, win 512, length 0
0x0000: 4500 0028 31ac 0000 3f06 466e f01a b578 E..(1…?.Fn…x
0x0010: 4814 160f 06a0 0050 7f00 8cb9 752d 8ff5 H……P….u-..
0x0020: 5012 0200 924f 0000 0000 0000 0000 P….O……..
12:43:53.835899 IP 250.226.228.185.1697 > 10.100.101.102.80: Flags [S.], seq 1590728177, ack 1831211018, win 512, length 0
0x0000: 4500 0028 d4d7 0000 3f06 6939 fae2 e4b9 E..(….?.i9….
0x0010: 4814 160f 06a1 0050 5ed0 95f1 6d26 100a H……P^…m&..
0x0020: 5012 0200 f72f 0000 0000 0000 0000 P…./……..
12:43:54.835938 IP 83.152.76.154.1698 > 10.100.101.102.80: Flags [S.], seq 1450754368, ack 932352526, win 512, length 0
0x0000: 4500 0028 ba9b 0000 3f06 c2df 5398 4c9a E..(….?…S.L.
0x0010: 4814 160f 06a2 0050 5678 c140 3792 920e H……[email protected]
0x0020: 5012 0200 c731 0000 0000 0000 0000 P….1……..
12:43:55.835978 IP 243.6.15.240.1699 > 10.100.101.102.80: Flags [S.], seq 1615424763, ack 1978575496, win 512, length 0
0x0000: 4500 0028 e6ba 0000 3f06 33fc f306 0ff0 E..(….?.3…..
0x0010: 4814 160f 06a3 0050 6049 6cfb 75ee aa88 H……P`Il.u…
0x0020: 5012 0200 580a 0000 0000 0000 0000 P…X………

The [S.] flag indicates that it is a SYN ACK packet.

A TCP session is required for a server to accept any TCP packet (other than a SYN packet which is meant to initiate the connection). If a session does not exist for the source/destination pair, the packet will not be accept by the server. In the case of a SYN ACK packet, the server will reply with a RST (reset) packet, telling the client that there is no established connection.

A SYN ACK flood consists of sending a lot of spoofed IP to a destination server. If the packets are allowed to get to the destination, the server has to send a RST packet back out for each packet that it sees does not have a valid TCP connection. Every packet that a server processes costs resources, even if it’s just to deny the connection. For this reason, a SYN ACK flood can be very effective. A SYN ACK packet is an allowed “initial” receive packet if the server sent out a SYN request first.

This type of flood, as with any other TCP flood, is effective because it forces the server to drop the packets. This causes resource exhaustion as it has to process each packet. A SYN ACK flood can potentially be more effective than a SYN flood in the case where the DDoS mitigation provider handles SYN floods better than SYN ACK floods, which is often the case. A SYN flood is a more effective solution to taking down a server though in the sense that once the packets hit the server, a SYN packet half-opens a TCP connection. Even with DDoS mitigation, there is a potential for some packets to get through to the server. It takes a smaller amount of SYN packets to impact a server and as such is the more effective choice.

A DDoS Attack Explained: TCP ACK

We’re continuing along with our explanations of types of DDoS attacks today, with emphasis on the TCP ACK flood. Much like we discussed on Tuesday, this form of attack is a part of making a TCP connection. When a client establishes a TCP connection to a server, the connection goes through a three step process.

1. SYN packet. During this stage, a client (such as a desktop computer, laptop, or smartphone) initiates an outgoing connection to a server (such as a web or gaming server).
2. SYN-ACK packet. The server responds with an acknowledgement of the initial request, signaling it is ready to finish initiating the connection.
3. ACK packet. The client sends a final acknowledgment, signifying that both the client and server are ready to send and receive data.
This process is known as a “three-way handshake”.

An ACK flood, as the name describes, involves sending a whole bunch of TCP packets with the ACK bit enabled on it. This kind of DDoS attack has its advantages and disadvantages when compared to the more common SYN flood.

First, let’s take a look at what an ACK flood looks like. This is a spoofed ACK flood against server IP address 10.100.101.102 on port 80.

20:02:48.983378 IP (tos 0x0, ttl 63, id 32488, offset 0, flags [none], proto TCP (6), length 40) 222.83.14.144.1040 > 10.100.101.102.80: Flags [.], cksum 0xb469 (correct), seq 751014783, ack 2048786021, win 512, length 0 0x0000: 4500 0028 7ee8 0000 3f06 40a3 4814 160e E..([email protected] 0x0010: 4814 160f 0410 0050 2cc3 937f 7a1d fe65 H......P,...z..e 0x0020: 5010 0200 b469 0000 0000 0000 0000 P....i........ 20:02:49.983439 IP (tos 0x0, ttl 63, id 43793, offset 0, flags [none], proto TCP (6), length 40) 114.80.136.184.1041 > 10.100.101.102.80: Flags [.], cksum 0x1c45 (correct), seq 135907827, ack 760402314, win 512, length 0 0x0000: 4500 0028 ab11 0000 3f06 147a 4814 160e E..(....?..zH... 0x0010: 4814 160f 0411 0050 0819 c9f3 2d52 d18a H......P....-R.. 0x0020: 5010 0200 1c45 0000 0000 0000 0000 P....E........ 20:02:50.983479 IP (tos 0x0, ttl 63, id 44213, offset 0, flags [none], proto TCP (6), length 40) 223.4.31.169.1042 > 10.100.101.102.80: Flags [.], cksum 0x3320 (correct), seq 227681609, ack 1655186570, win 512, length 0 0x0000: 4500 0028 acb5 0000 3f06 12d6 4814 160e E..(....?...H... 0x0010: 4814 160f 0412 0050 0d92 2549 62a8 248a H......P..%Ib.$. 0x0020: 5010 0200 3320 0000 0000 0000 0000 P...3......... 20:02:51.983525 IP (tos 0x0, ttl 63, id 52759, offset 0, flags [none], proto TCP (6), length 40) 202.116.160.1043 > 10.100.101.102.80: Flags [.], cksum 0x5f9f (correct), seq 379954490, ack 794534482, win 512, length 0 0x0000: 4500 0028 ce17 0000 3f06 f173 4814 160e E..(....?..sH... 0x0010: 4814 160f 0413 0050 16a5 a53a 2f5b a252 H......P...:/[.R 0x0020: 5010 0200 5f9f 0000 0000 0000 0000 P..._......... 20:02:52.983569 IP (tos 0x0, ttl 63, id 23290, offset 0, flags [none], proto TCP (6), length 40) 200.27.175.70.1044 > 10.100.101.102.80: Flags [.], cksum 0x8634 (correct), seq 242507686, ack 1779207888, win 512, length 0 0x0000: 4500 0028 5afa 0000 3f06 6491 4814 160e E..(Z...?.d.H... 0x0010: 4814 160f 0414 0050 0e74 5fa6 6a0c 8ed0 H......P.t_.j... 0x0020: 5010 0200 8634 0000 0000 0000 0000 P....4........ 20:02:53.983607 IP (tos 0x0, ttl 63, id 42657, offset 0, flags [none], proto TCP (6), length 40) 219.137.229.214.1045 > 10.100.101.102.80: Flags [.], cksum 0x03ae (correct), seq 984467710, ack 563135552, win 512, length 0 0x0000: 4500 0028 a6a1 0000 3f06 18ea 4814 160e E..(....?...H... 0x0010: 4814 160f 0415 0050 3aad c8fe 2190 c440 H......P:[email protected] 0x0020: 5010 0200 03ae 0000 0000 0000 0000 P.............

The [.] flag indicates that it is an ACK packet.

Where The ACK Flood Flows

When a server encounters any TCP packet, it will only accept the packet if there is an already established TCP connection between the source and destination.
There are two common scenarios where an ACK flood takes place:

1. The less common scenario: The attacker sends an initial SYN packet using a bunch of different spoofed IP addresses, calculates the sequence number, and then sends a bunch of properly constructed ACK packets from those same spoofed IP addresses. This keeps all of the connections in an open state, causing the server to run out of resources with seemingly legitimate connections that don’t close. This kind of attack is very difficult to pull off.
2. The more common scenario: The attacker just sends a whole bunch of TCP packets with the ACK bit enabled and the source IP spoofed. This kind of attack is very easy to execute.

Scenario 1’s advantage vs a SYN flood is that it actually opens a connection to the server, and can keep the connection open indefinitely. This is extremely effective when it comes to taking up server resources. A SYN flood on the other hand just opens up a half connection, which times out. It is also much simpler for a DDoS protection device or service to mitigate a SYN flood. The disadvantage is that it’s extremely difficult to execute this kind of attack.

In Scenario 2, the application receiving the packets will simply drop them because there are no active TCP connections between the source and the destination IP addresses. It doesn’t actually open any connections. The reason it’s effective is that the flood forces the server to drop the packets. This causes resource exhaustion as it has to process each packet. The server has to do the same kind of thing with a SYN flood, except it also opens a connection with the server, which is much more effective. The only advantage an ACK flood has is that DDoS protection devices and services are more tuned to handle SYN floods as they are significantly more common. An ACK flood is a clever way to potentially trick DDoS protection services into actually allowing the packets through the filter, which can end up overwhelming the server.

A DDoS Attack Explained: DNS Amplification Attack

amplification

Up to this point, we’ve largely focused on the types of DDoS attack associated with TCP connections, but today we’d like to switch our focus over to another area: DNS amplification attacks.

A DNS amplification DDoS attack builds on the connection-less orientation of the UDP protocol. Attackers use publically accessible open DNS servers to flood a target system with DNS response traffic. The primary technique consists of an attacker sending a DNS name lookup request to an open DNS server with the source address spoofed to be the target’s address. When the DNS server sends the DNS record response, it is sent instead to the target. Attackers will typically submit a request for as much zone information as possible to maximize the amplification effect. The amplification factor of this type of attack is up to 54x. What this means is that for every byte of traffic that is sent from the attacker, up to 54 bytes of traffic will be sent to the destination.

In most attacks of this type observed by US-CERT, the spoofed queries sent by the attacker are of the type, “ANY,” which returns all known information about a DNS zone in a single request. Because the size of the response is considerably larger than the request, the attacker is able to increase the amount of traffic directed at the victim. By leveraging a botnet to produce a large number of spoofed DNS queries, an attacker can create an immense amount of traffic with little effort. Additionally, because the responses are legitimate data coming from valid servers, it is extremely difficult to prevent these types of attacks.

Below, we see an example of a DNS query targeting 10.100.101.102 port 80 from an open DNS resolver running on IP address 192.168.5.10:

[email protected]:~# dig ANY exampletest.xab @192.168.5.10 +edns=0

; <<>> DiG 9.8.1-P1 <<>> ANY exampletest.xab @192.168.5.10 +edns=0
;; global options: +cmd
;; Got answer:
;; ->>HEADER< ;; flags: qr rd ra; QUERY: 1, ANSWER: 39, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;exampletest.xab. IN ANY

;; ANSWER SECTION:
exampletest.xab. 3599 IN TXT “553992721-5400647”
exampletest.xab. 3599 IN SOA ns1.exampletest.xab. 2015062301 28800 7200 604800 3600
exampletest.xab. 299 IN MX 10 abcmail1.exampletest.xab.
exampletest.xab. 299 IN MX 10 defmail5.exampletest.xab.
exampletest.xab. 299 IN MX 10 defmail3.exampletest.xab.
exampletest.xab. 299 IN MX 10 ghimail1.exampletest.xab.
exampletest.xab. 299 IN MX 10 abcmail2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 21599 IN NS ns3.exampletest.xab.
exampletest.xab. 299 IN A 192.168.22.167
exampletest.xab. 299 IN A 192.168.22.166
exampletest.xab. 3599 IN TXT “178953544-4422001”
exampletest.xab. 3599 IN TXT “228406766-4422034”
exampletest.xab. 3599 IN TXT “299762315-4422055”
exampletest.xab. 3599 IN TXT “826318936-4422046”
exampletest.xab. 3599 IN TXT “598362127-4422061”
exampletest.xab. 3599 IN TXT “227933795-4422004”
exampletest.xab. 3599 IN TXT “691244312-4422022”
exampletest.xab. 3599 IN TXT “287893658-4422013”
exampletest.xab. 3599 IN TXT “186244776-4422028”
exampletest.xab. 3599 IN TXT “353675828-4422052”
exampletest.xab. 3599 IN TXT “782919862-4417942”
exampletest.xab. 3599 IN TXT “126353328-4422040”
exampletest.xab. 3599 IN TXT “294923881-4422049”
exampletest.xab. 3599 IN TXT “667921463-4422007”
exampletest.xab. 21599 IN NS ns2.exampletest.xab.
exampletest.xab. 21599 IN NS ns1.exampletest.xab.
exampletest.xab. 3599 IN TXT “764482656-4422025”
exampletest.xab. 3599 IN TXT “757973593-4422016”
exampletest.xab. 3599 IN TXT “MS=ms66433104”
exampletest.xab. 3599 IN TXT “714321871-4421998”
exampletest.xab. 3599 IN TXT “882369757-4422010”
exampletest.xab. 3599 IN TXT “ms=ms97244866”
exampletest.xab. 3599 IN TXT “321959687-4422031”
exampletest.xab. 3599 IN TXT “754510718-4422064”
exampletest.xab. 3599 IN TXT “319997471-4422043”
exampletest.xab. 3599 IN TXT “522183251-4422019”
exampletest.xab. 3599 IN TXT “688562515-4422037”
exampletest.xab. 3599 IN TXT “133466244-4422058”

;; Query time: 254 msec
;; SERVER: 192.168.5.10#53(192.168.5.10)
;; WHEN: Thu Jul 9 14:10:14 2015
;; MSG SIZE rcvd: 1175

In the example above, a 64 byte packet sent from a malicious source caused the open DNS resolver running on 192.168.5.10 to reply with a packet with a size of 1175 bytes. In this case, it’s only amplification factor of 18, but they can get much larger depending on what domain is being queried! DNS amplification attacks were a very big deal in 2012.

The reason they were so popular was because they were easy to generate due to a very large number of misconfigured open DNS resolvers. This brought upon the Open Resolver Project. This site was created, as the name implies, to help identify open DNS resolvers. Of course the downside of this was that it made it easier for people to generate large DDoS attacks, but what it did was cause people to start fixing their own DNS resolvers and contact people who had misconfigured DNS resolvers. This project spearheaded significantly reducing the capability to execute DNS amplification attacks.

A funny thing that DDoS mitigation providers and probably a lot of ISPs had happen during this time was that people who were running open DNS resolvers would get in contact with us and tell us that we are DoSing their resolver. The reason they thought that we were DoSing them was that our IP (the one that the actual attacker spoofed) was continuously querying their server, so it looked like we were DoSing them. What they didn’t realize was that the packets were spoofed, and in fact they were the ones DoSing us! This was useful because we were able to tell them how to stop their resolver from participating in DDoS attacks, which helped everyone, except for the attackers.

This sort of DNS traffic is suspect primarily for the large amount of data being “requested”- no normal application or server should ever generate a request designed to elicit this kind of response. Although DNS requests mostly happen over the UDP protocol, there is a way to force DNS over TCP. If the DNS server allows for TCP mode, then denying UDP DNS requests is a very good idea.

[email protected]~# dig test.site ;; Truncated, retrying in TCP mode.

This eliminates the connection-less properties of UDP traffic, allowing DNS traffic to flow without simply blocking or rate-limiting packets, but only over a verified and properly-initiated connection.

DDoS Attacks Against Data Centers

data centerDDoS attacks come in all shapes and sizes. They are used to harm businesses, extort money, annoy system administrators, test vulnerabilities, and many other, mostly malicious reasons. A DDoS attack is typically meant to target a specific service, such as a website. By taking the website offline, the attacker accomplishes whatever goal he set for.

A data center is a facility that hosts many online services. They are indirectly the target of the majority of DDoS attacks, as they host most of the services on the web. These data centers all have various methods of dealing with DDoS attacks.

In order to understand the kind of impact DDoS attacks have on a data center, first we need to define at a high level what the network infrastructure of a typical data center looks like. Of course, network architecture is much more complicated, but at a high level, traffic entering the data center comes in through either the data center’s transit or peering network to the core layer, then aggregation layer, and finally the access layer prior to getting to the server hosting the online service.

Transit and peering links are connected to the large core router that sits at the edge of the network. This hardware is meant to be able to handle a large amount of data coming in. The aggregation layer is meant to handle a smaller amount of traffic. This is handled by having a larger number of aggregation layer hardware than core. The aggregation layer is typically where things like load balancing and firewalls are located. Prior to hitting the server, the traffic is sent to the access layer. The access layer is typically a top of rack switch, where a whole cabinet worth of services receive their internet connectivity from. There usually isn’t much going on at the access level. Access layer routers usually have a single or redundant uplink from the aggregation layer and either 1G or 10G. What this means is that a cabinet full of servers all share this 1G or 10G port upstream of them.

As far as vulnerability to DDoS is concerned, the end server is typically the most vulnerable due to two major factors: 1. that’s where the application is located, and as such its resources can quickly be depleted by a DDoS attacks, and 2. it only has a limited amount of network capacity (in this example, we’ll say it has a 1G port). A 1 gbps DDoS attack can take down almost any server solely due to the fact that it takes up all of the available network capacity of the server.

Moving up the chain, the access layer is the next most vulnerable part of a datacenter’s network when it comes to DDoS. This is due to the fact that it also has a more limited amount of network connectivity powering it. In this example, we’ll say the access layer switches have a 10g port coming from the aggregation layer. What this means is that a 10g DDoS attack target against a single server can take out every single server that shares an access layer switch with it. This is a huge problem for data centers. They can’t have one person getting hit by an attack impact potentially hundreds of other customers.

Aggregation and core routers are less vulnerable to DDoS attacks since they are limited almost exclusively by their network capacity.

How does a data center prevent a single customer getting DDoSed from impacting hundreds of other customers?

In order for a DDoS attack to not impact other customers at the access layer, the DDoS traffic must be stopped prior to it ever reaching the access layer. There are a couple of ways data centers handle this. One of the most typical strategies is for the data center to issue a blackhole on the destination IP address under attack to its transit providers. What this means is that when their transit providers receive traffic to that IP address, they don’t forward the traffic to the data center. This ensures that it never hits the access layer as it doesn’t even reach the core layer. Of course the issue with this is that it impacts all traffic, not just DDoS, so the web service is completely offline. This is a safe strategy for a data center though since it completely protects them against collateral damage at any layer. Another strategy is to have some sort of DDoS protection either using a cloud service where the traffic goes through another network before getting to the data center, or by using onsite hardware to scrub traffic at the core or aggregation layer prior to being forwarded to the access layer.

I mentioned two important things that get into the next part of this article. One was cloud protection and the other was blackholing IP addresses.

What happens if a data center receives an attack so large that it exceeds its total network capacity?

This is potentially the most devestating thing that can happen to a data center short of a critical event like power or cooling going out completely. Those things are less likely to occur due to the fact that data centers spend a lot of money ensuring that critical services have massive redundancy and backup. Many data centers have around 40 gigabits per second worth of network capacity. Very few of those ever get remotely close to using that much bandwidth. The reason for having so much capacity is to handle larger DDoS attacks that can wreck the entire network. Just like at the access level where a 10 gbps DDoS attack could impact potentially hundreds of customers (everyone at that specific access level), a 40 gbps DDoS attack, which would saturate the data center’s total network capacity, would take literally everyone being hosted in that data center offline. This is a very effective way to DDoS someone. By hitting them for so much that their data center can’t handle the traffic at all, they are forced to take that IP offline by blackholing it at the transit provider level. Since it never gets forwarded to the data center, it solves their problem at the cost of the one person being attacked being completely offline. This is an acceptable solution for data centers as the needs of the many outweigh the needs of the few. It costs too much for a company to invest in a massive network backbone just to handle these volumetric DDoS attacks. The other solution is for the datacenter to have a cloud DDoS protection provider that is specifically built to be able to take massive DDoS attacks. The data center can always have their traffic running through the DDoS protection provider, or have a manual or automatic method to send the DDoS traffic over to the DDoS protection provider when an attack occurs.

A DDoS Attack Explained: HTTP Flood

HTTP floods are one of the most devastating types of DDoS attacks currently available to an attacker. It is an attack at the application layer (Layer 7 of the OSI model), meant to exhaust a system’s application resources. It is very easy to execute, doesn’t require a massive botnet or any sort of tricks to generate volumetric amounts of data, and extremely difficult to block.

A server that is hosting a website is probably running Apache or Nginx. Depending on how strong the server is and how many servers are concurrently running hosting the website, it could support anywhere from just a few users at any given time to thousands of users. Whenever a user connects to a website, they establish a TCP connection using a three-way handshake:

– Client sends a SYN packet to the server
– Server sends a SYN ACK packet to the client
– Client sends an ACK packet to the server

Once this happens, a TCP connection is opened between the client and the server, allowing for free communication between the two. Data flows between the client and the server, the server sending the client the web data using TCP packets, and the client’s web browser translates these packets into a webpage.
HTTP floods involve opening up a valid TCP connection with a server, and then proceeding to send some sort of request to the server, such as download every object on page, or triggering some sort of call that would force a database query. There are many different ways an HTTP flood can overwhelm a server.

An example HTTP flood, in this case, a GET flood looks like this:

T 198.19.0.2:42728 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:40962 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:51486 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:55300 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:56396 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .

The GET flood above is legitimately downloading the index page of a website. By legitimately, I mean it establishes a full session and actually receives all the data from the webpage.
An HTTP flood accomplishes multiple goals. The simplest thing it does is it establishes a lot of TCP sessions. This on its own causes a huge amount of strain on web servers. The more complex part of it is that each session is requesting the server to send it data over and over again, so the server is constantly processing requests from the clients and trying to respond to them. This very easily exhausts the server’s resources.

This kind of flood is easy to execute. There are scripts online such as httpflooder.pl that allow a client to send a GET flood to a server. A single machine sending a GET flood to a server will not be enough to take the server down though. It requires a decent sized botnet. The reason a botnet is necessary is that in order for an HTTP flood to work, the client has to be able to respond to the server’s requests. This is much different than a SYN flood where packets just get sent but don’t send any sort of follow up packets. With enough zombies in a botnet, a server can easily be overwhelmed.

This kind of attack is very difficult to stop due to the fact that these systems are all sending what look like legitimate connections. Detecting the bad traffic requires deep packet inspection and a lot of logic around what seems to be legitimate and what does not. This introduces the problem of false-positive blocking, which is a major problem that DDoS protection providers have. The idea is the bad traffic has to be filtered out and the good traffic has to be let through, but when application layer floods occur, most DDoS protection providers fall short detecting what is good and what is bad.

Staminus SecurePort technology is at the forefront of application layer DDoS protection as well as very all other types of attacks. You can learn more about the Staminus filtering and mitigation process by visiting our technology page.

Free Cloud Services and How They Are Used for DDoS

cloud-services

Free cloud services have become popular in recent years. These services provide developers a platform to test software, and collaborate with others easily. While this sounds amazing, in reality these platforms can be a goldmine for attackers if not properly secured. Many of these services require only an email for verification. Setting up fake emails and automating this sign up process is all too simple for attackers.

A couple years ago at Black Hat in Las Vegas, security researchers Oscar Salazar and Rob Ragan demonstrated just how easy this process was. They managed to accumulate 1,000 free cloud accounts during one weekend. With this free botnet they performed LiteCoin mining, allowing them to average $1,750 per week in pure profit.

This was a proof of concept exercise and as such restraint was shown. A malicious user on the other hand, would feel no need to limit themselves. Imagine tens of thousands of free cloud services being utilized for DDoS attacks. Being able to bypass email authentication is simple for any skilled coder, free cloud providers need to be aware of this, and take the necessary steps to improve authentication. These types of services are ideal for attackers to perform distributed network scanning, distributed password cracking, DDoS attacks, click-fraud, crypto currency mining and data storage.

Moving forward we need to keep security in mind as we offer free services and connect more devices to the internet. The threat landscape is constantly evolving, as a community we need to evolve as well. Take any and every step possible to remain secure and up to date.

DDoS, Baidu, and China’s Great Cannon

Recently the New York Times announced that CloudFlare has partnered with Internet search giant Baidu in China, Google’s eerily similar competitor, to deliver Yunjiasu, a CloudFlare-like service in China. The service is aimed at speeding up Internet connectivity and providing some level security services for its customers, including limited DDoS mitigation. It will likely operate similar to CloudFlare itself, with the exception of falling within the jurisdiction of the Chinese government and therefore Chinese censorship and draconian Internet laws. The New York Times considers this as possibly a “new model for American tech firms that are considering doing business in the delicate areas of China’s tech industry.”

China and Its Internet

There are many countries that provide some level of censorship and control over their population, especially with regards to the Internet. China, however, stands fairly unique in the world in this regard. It has managed to shield the entire country – all 1.35Bn people from what it deems as inappropriate or subversive to the current political regime. This is by no means a trivial matter. The sheer volume of data that passes in and out of China is immense. They’ve managed to control this flow with a comprehensive firewall known as the Great Firewall. This is a defensive system.

Continue reading

What is a DDoS ATTACK

DDoS is an abbreviation for distributed denial of service. Ddos is done by transmitting packets of information in a rapid manner to the extent that the machine under target can no longer bear it or respond to legal requests anymore. This is a common form of attack which is used by hackers with the intent of causing a loss of income or to cause intimidation.
A simple way to explain this is to imagine a scenario where 10 fat men are pushing their way through a small entrance at the same time. This will only prevent other persons from finding their way through to either enter or leave. It is pretty much the same with internet connections; the DDoS makes it impossible for any signal to pass through and the motive at the end of the day is to hinder your connection to the World Wide Web.
For some, DDoS is considered legal while to some others it is not. The Computer Fraud and Abuse act is the only law against DDoS that can be considered in court. It can easily be argued in court and only a few persons have been indicted in such cases.
There were only a few ways to carry out a DDoS attack in the past, either you own a botnet or you gain illegal entry to a server and upload shells which basically are webpages used to send packets of information without the knowledge of the webservers. Nowadays, shells have been substituted by purchased servers from data centers that ignore the activities of these servers. That is also what you will be using whenever you make use of an IP booter or an IP stresser.
There is absolutely no difference between an ip stresser, a DDoSer, a botnet and a booter. Whenever a person calls an ip stresser a booter, they are just concealing their shady deals.