UDP - DDoS Protection

It is common knowledge that nowadays many developing companies, game publishers or even independent developers tends to choose UDP Protocol as their standard for their internet driven applications.

Although, compared with the TCP Protocol, the UDP Protocol does have its advantages and disadvantages, and we can (to enlighten the readers), enumerate a few of them here:

Key Advantages:

1. - Low latency between data exchange in both endpoints (server / client).
2. - High flexibility in protocol development.
3. - Connection less protocol, direct data exchange between both endpoints (server / client).
4. - Perfect for voice/video streaming based applications, or latency sensitive games (generally FPS in most cases).

Key Disadvantages:

1. - Since it is a connection less protocol, there is no session validation between connections, it means at any time one may start data transmission without passing through a handshake algorithm like TCP.
2. - No packet ordering guaranteed, this must be implemented and handled by the developer itself, while in TCP this is a mature feature, ensuring all packets are received in the same order as they have originated from the source.
3. - Vulnerabilities of all types when it comes to DDoS Attacks, either by the written applications acting as amplification vector for DDoS Attacks or being a target from these vectors (Such as DNS Amplification, NTP Amplification, Chargen Amplification, SNMP Amplification and much more, as there are dozens of vulnerable computers on the internet, ready to be used as amplification vectors). Also, still on this subject, these applications are often target of customized attacks, coded targeting the application in order to either cause resource exhaustion at the server-side or even a complete downtime. It is important to say, that while TCP adds a response time overhead in it's packet transmissions, it is much safer than UDP in these matters, due to the protocol design itself, removing this responsibility from the developers back.

An example of a customized/scripted UDP DDoS Attack towards a TeamSpeak voice server:

The solution:

Nowadays, we (HyperFilter), are working in our own DDoS Appliances, focused in helping the developers which depends/require of the usage of UDP Protocol based applications. We're capable in conjunction with them, to add behavior detection techniques in the middle of the communication and "identify" and "separate" the real user traffic, from forged/spoofed custom attacks, keeping their applications stable.

If you are running in troubles with UDP based DDoS Attacks, we are open to discuss with you, implementation plans, to improve and solve these issues in your corporation, keeping your business project rock solid, while you focus in the real objective, which is your business by itself. :)

Our engineering support team will always be looking forward to help you in any sort issues you may incur related to these types of attacks.

Tags: DDoS Mitigation → DDoS Protection → featured → Online Games → UDP Attack Scripts → UDP DDoS Attacks → UDP Games

UDP - DDoS Protection

By HyperFilter → Monday, September 5, 2016

POODLE Security Vulnerability Breaks SSLv3 Secure Browsing

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).

It is important to note that this is NOT a flaw in SSL certificates, their private keys, or their design but in the old SSLv3 protocol.  SSL Certificates are not affected and customers with certificates on servers supporting SSL 3.0 do not need to replace them.

It’s believed to not be as serious as the Heartbleed bug in OpenSSL, since the attacker needs to have a privileged position in the network to exploit the latest.  The usage of Hotspots, public Wi-Fi, makes this attack a real problem. This type of attack falls into the “Man-in-the-middle” category. 

Background

While SSL 3.0 was introduced in 1996, it is currently supported by nearly 95% of Web browsers according toNetcraft’s latest report.  Many Transport Layer Socket (TLS) clients downgrade their cryptography protocol to SSL 3.0 when working with legacy servers. According to Google, an attacker that controls the network between the computer and server could interfere with the handshake process used to verify which cryptography protocol the server can accept using a “protocol downgrade dance”. This will force computers to use the older SSL 3.0 protocol to protect data that is being sent. Attackers can then exploit the bug by carrying out a man-in-the-middle (MITM) attack to decrypt secure HTTP cookies, which could let them steal information or take control of the victim’s online accounts.  Although, at the time to writing, webmasters have been disabling moving to TLSv1 and above and a rapid pace, there still remains a lot of work to be done.  If Heartbleed taught us anything, it’s that the largest companies act fast while many small companies drag their heels in patching critical vulnerabilities. 

What Businesses Need to Do

In order to mitigate the bug there are a few courses of action:

1. Check to see if your webservers are vulnerable using our free SSL Toolbox.
2. Use tools that support TLS_FALLBACK_SCSV, a mechanism that prevents attackers from forcing Web browsers to use SSL 3.0.
3. Disable SSL 3.0 altogether, or disable SSL 3.0 CBC-mode ciphers
4. A cloud-based Web Application Firewall can help protect against this kind of vulnerability.  For more information please visit our website.
5. Be leery of any spam messages from scammers trying to capitalize on uncertainty and a lack of technical knowledge.

A few tips on how to fix this on Apache:

> SSLProtocol All -SSLv2 -SSLv3                   <- Removes SSLv2 and SSLv3

> apachectl configtest                                   <- Test your configuration

> sudo service apache restart                      <- Restart server

Google added that it will remove SSL 3.0 support from all of its products in the next few months. Mozilla also said it would disable SSL 3.0 in FireFox 34, which will be released at the end of November. 

What End-Users Need to Do

For end-users accessing websites Symantec recommends:

1. Check to see if SSL 3.0 is disabled on your browser (for example, in Internet Explorer it is under Internet Options, Advanced Settings).
2. Avoid MITM attacks by making sure “HTTPS” is always on the websites you visit.
3. Monitor any notices from the vendors you use regarding recommendations to update software or passwords.
4. Avoid potential phishing emails from attackers asking you to update your password – to avoid going to an impersonated website, stick with the official site domain.

Source: symantec

Tags: Vulnerabilities

POODLE Security Vulnerability Breaks SSLv3 Secure Browsing

By HyperFilter → Thursday, October 16, 2014

Internet routing 512K limitation

In the past two years we have been individually updating our clients about the (possible and most likely) upcoming issues with the internet.

Most people and companies were afraid off the issues year 2K might bring due to the possible bugs in software. Others got scared because of the major Cisco and Juniper router bugs that occurred in the past years, which brought down a large portion of the internet. And then there are some people that are always scared I guess...

Anyways, now the time has come that the internet will actually start to cripple and become unstable for a couple of weeks. This is what we have been warning many clients and other ISP about in the past years. Many have acted upon this, but we can say for sure that most have not acted yet.

In the past years everyone heard (or should have) about the depletion of the IPv4 address space. Registries such as RIPE, who distribute those address blocks, thought it was a smart move to start and limit the size of each subnet that they distribute to their members who request additional address space. This has resulted in many subnet sizes of a /22 (1024 IP addresses) up to a /24 (256 IP addresses) to be distributed. Providers need to use these subnets across their infrastructure and as many providers have their infrastructure widely spread, this required them to divide those subnets into smaller portions, blocks. This is normal behavior, however as the subnets they received were already very small, there was not much to divide. Providers had to start dividing them into the smallest blocks possible that is allowed to be routed on the internet, which are /24's (256 addresses).

Up till a few years ago, there were about 400K routes active on the internet (see reference 1). Since last Tuesday we have reached over 512K routes. This poses a serious problem all over the internet as many routers have hardware limit of 512K routes that can be installed in their forwarding table of their line-cards. Every brand and type of router will act differently when this limit is hit. We have seen Cisco routers crash/reload (continuously). And other routers just not installing new routes, causing unavailability of parts of the internet. Last Tuesday we have been given a preview of these issues. Major providers like Level 3, AT&T, Cogent, Sprint and Verizon were having serious issues. And surely there were many more that should be added to this list.

The crashes and other issues will be seen in the coming weeks all over the internet. We expect that from time to time there will be, as we call it, BGP flaps all over the internet. This will cause routes to changes back and forth for a few minutes or even hours, which on its turn could cause a domino effect or at least a non-optimal set of routes on the internet.

It could be that many people will not notice this. But if you can not reach your local bank website, your company email or you just cannot reach your girlfriend by phone... Think about what we have said. And do not blame your local ISP -just yet-, as it can be very much any of the other 70.000 Internet Service Providers out there. Anyone provider that has been given an AS (Autonomous System) number and is between you and your destination (and/or back) can be causing these issues. Just wait a minute and retry.

We can now officially call the 12th of August 2014, the "512k day" (reference 5).

References:
1. CIDR Active BGP entries (FIB): http://www.cidr-report.org/cgi-bin/plota?file=/var/data/bgp/as2.0/bgp-active.txt&descr=Active BGP entries (FIB)&ylabel=Active BGP entries (FIB)&with=step
2. http://online.wsj.com/articles/y2k-meets-512k-as-internet-limit-approaches-1407937617
3. http://www.renesys.com/2014/08/internet-512k-global-routes/
4. http://arstechnica.com/security/2014/08/internet-routers-hitting-512k-limit-some-become-unreliable/
5. http://en.wikipedia.org/wiki/512K
6. https://noc.nforce.com/notifications/informational

Tags: News

Internet routing 512K limitation

By HyperFilter → Saturday, August 16, 2014

WordPress sites used for DDoS attacks with XML-RPC PingBack Vulnerability

There were news stories this week outlining how attackers are abusing the XML-PRC "pingback" feature of WordPress blog sites to launch DDoS attacks on other sites.  This blog post will provide some analysis on this attack and additional information for websites to protect themselves.

Not A New Vulnerabilty

The vulnerability in WordPress's XML-RPC API is not new.  Here is data from the WordPress bug tracker from 7 years ago.

While the vulnerability itself is not new, it has only been within the past couple years that attack code/tools have been made available.  This has certainly helped increase attacks by ScriptKiddies and resulted in more actual DDoS attacks.

WordPress XML-RPC Pingback DDoS Attack Walkthrough

The XML-RPC pingback functionality has a legitimate purpose with regards to linking blog content from different authors.  The issue is that this functionality can be abuse by attackers to use the XML-RPC pingback feature of a blog site to attack a 3rd party site.

WordPress XML-RPC Pingback DDoS attack

Here is an example attack command using curl -

The YELLOW highlighted data is a WordPress "Patsy Proxy" site while teh ORANGE highlighted data is the target/victim website.  It is important to note for testing purposes that you must include the "Content-Type: text/xml" request header data otherwise the XML-RPC service will not treat the request as valid and will issue the following response:

With the previous request sent by the attacker, the Patsy Proxy WordPress site then initiates this HTTP request to the target/victim site -

Notice that the format of the HTTP request is only two lines:

• URI
• Host request header

This intelligence can be used by Web Application Firewalls (WAFs) that are protecting the victim sites to identify attack requests.  Normal web browsers send many more request headers.  While the pingback DDoS attack doesn't utilize any type of amplification as other more recent network protocol attacks (e.g. NTP), requests can cause more damage on the victim site if the URI is initiating a computationally expensive back-end query or process.

Protections Disable XML-RPC

It is possible to disable the XML-RPC process altogether if you do not want to use it.  There are even plugins that will disable it.

Also there is a plugin for to make your wordpress faster and more secure: https://wordpress.org/plugins/wordfence/

Disable Pingback Requests

You may also disable the pingback feature by adding the following to your functions.php file:

source: spiderlabs

Tags: DDoS Attacks → News → Vulnerabilities → WordPress

WordPress sites used for DDoS attacks with XML-RPC PingBack Vulnerability

By HyperFilter → Sunday, August 10, 2014

DDoS Attacks against Israel

Hacking attempts against Israeli networks and servers increased more than five-fold during the war in Gaza, according to a report released this week by network security specialists Arbor Networks.

Just about all the attacks were Denial of Service (DDOS) attacks, in which the hackers attempt to overwhelm and shut down a server by directing an unsustainable volume of requests at it.

The volume of attacks began to rise in the first week of July, going from an average of 30 attacks per day in June to 150 attacks per day in July. The onslaught peaked on July 21, when 429 attacks were recorded.

Attacks dropped precipitously on July 28, the day that an ultimately unsuccessful cease-fire was due to go into effect, and started rising again on August 3.

Not only the number of attacks was unprecedented during July. They were also unusual in size (the traffic directed at a specific server) and duration.

In June, no attack exceeded 12 Gbps. In July, seven attacks exceeded 12 Gbps, with the largest peaking at 22.56 Gbps on July 12.. The largest attack of all – at 29 Gbps – came on August 3, after cease-fire talks collapsed.

The average duration of an attack in June was 20 minutes with a peak duration of 24 hours. In July, the average duration was one hour and 39 minutes. An attack launched on July 19 was still in progress when the report was written, after approximately two weeks.

The report concludes that the number, size and duration of the DDoS attacks targeting Israel were proportional to the intensity of the conflict. The attackers, it says, appear to have made an effort to adhere to the “real world” calls for a cease-fire, resuming their attacks when the cease-fire ended or collapsed.

In all, Israel was targeted by 5,346 DDOS attacks during the duration of the fighting.

Tags: DDoS Attacks → News

DDoS Attacks against Israel

By HyperFilter → Wednesday, August 6, 2014

New dedicated servers with DDoS Protection

Its a pleasure to announce our new protected dedicated servers.

Location: Amsterdam, Netherlands

• Xeon E3-1240v3 16GB

• 16 GB RAM Advanced ECC

• 2 x 500GB SATA II 7200 RPM

• Hardware Raid 1

• 20TB bandwidth Premium Bandwidth [Clean Traffic]

• Network Port 1000 Mbps

• DDoS Protection

• $449.99/Month

• Order Now •

• Xeon E3-1240v3 32GB

• 32 GB RAM Advanced ECC

• 2 x 500GB SATA II 7200 RPM

• Hardware Raid 1

• 20TB bandwidth Premium Bandwidth [Clean Traffic]

• Network Port 1000 Mbps

• DDoS Protection

• $489.99/Month

• Order Now •

• Xeon E3-1240v3 32GB SSD

• 32 GB RAM Advanced ECC

• 2 x 240GB SSD

• Hardware Raid 1

• 20TB bandwidth Premium Bandwidth [Clean Traffic]

• Network Port 1000 Mbps

• DDoS Protection

• $599.99/Month

• Order Now •

Key Points:

• Low False Positive Rate (<=1%)

• Always on Protection State

• The HyperFilter DDoS Protected Dedicated Servers, are branded hardware built by HP.

• They are placed in a redundant DoS/DDoS Protected network with multiple 10GE carriers providing the best connectivity.

• A DoS/DDoS Attack is mitigated nearly instantly, avoiding downtimes and side effects related with it.

• Quality is an important factor, our engineering team is always available for you.

• All kinds of DDoS attacks are mitigated into our systems and only the good traffic is allowed to pass.

• We aren’t resellers like the competition, we develop our mitigation technology daily, improving it day-by-day to become the most up to date and quality DDoS Protection available.

• You will be protected against any kind of DDoS Attack, being TCP, UDP, ICMP, ARP, Socket Flooding and so on.

Please feel free to contact our Sales Live Chat for more informations.

Tags: DDoS Mitigation → DDoS Protection → News

New dedicated servers with DDoS Protection

By HyperFilter →