Customer experience is one of the most crucial factors to look out for when trying out a web hosting service. After Vitor’s website went down due to a mishap by his previous provider and no clear explanation was provided, he decided to search for a better alternative. Learn how this incident led Vitor to Hostinger and why he chose to stay with us.

The Background

Vitor Braga is a software developer from Brazil. With nearly 17 years of experience, he knows how important it is for small to medium-sized enterprises to have the right tools to operate their businesses.

However, creating software that suits all your needs is no easy task. You must either have the money to hire a software developer, which can be expensive, or the skills to build the application yourself, which can take a long time to master.

Vitor launched a startup that tackles this exact problem. VTB Solutions specializes in no-code, AI-powered services that help businesses create software without having any technical expertise. Vitor and his team call themselves the ‘solution developers.’

To market his business and accomplish its mission, Vitor needed a website.

The Challenge

To launch his website, Vitor decided to purchase a hosting plan from a popular provider in Brazil, which he used for quite some time.

Unfortunately, the company’s slow customer support and lack of communication became a major source of frustration for Vitor.

“We had a very, very big problem with the DNS configuration. One day, the provider just reset our DNS settings without informing us. This made the site inaccessible to our clients and us. We asked their support, ‘What happened?’ And their only reply was, ‘We had a problem with your website.’ We got a lot of answers like that when we were with them, ”Vitor said.

When the same issue happened again one week later, Vitor decided it was the last straw. He left his then-provider and began searching for a better alternative. He wanted one with responsive customer support, an excellent reputation, and a reasonable price.

The Solution: Migrating to Hostinger

When Vitor was reading reviews about web hosting services, Hostinger was listed as one of the top picks for the best value for money.

On ReclameAqui, a popular Brazil-based complaint website, our services are scored 8.7 out of 10with a 93% success rate in solving customers’ problems. We also have an Excellent rate of 4.3 out of 5 stars on Trustpilot. Such reviews convinced Vitor to try our web hosting.

After looking at the plans, Vitor went with Hostinger’s Premium Shared Hosting. It offers unlimited bandwidth and 100 GB of SSD storage, which is plenty of space for running a small to a medium-sized business website.

At first, he planned to test five hosting providers and compare them side by side. However, Vitor was so impressed with Hostinger that he no longer needed to check out the other hosts.

When asked what made him stay with us, he said our Customer Success team was a major contributing factor.

At Hostinger, clients can get 24/7 customer support via live chat and email on any day of the year. Our Customer Success agents also live across different time zones and speak over ten languages.

What’s more, we have an extensive knowledge base that offers answers to frequently asked questions about using our services. If you’re looking for how-to guides to build your online presence or configure your website, our vast library of tutorials can help you out.

Vitor also shared another feature that surprised him – the easy SSL configuration.

After transferring his domain name, he was able to purchase and install a lifetime SSL certificate automatically on the control panel – no technical know-how was necessary. Vitor can also feel safe knowing his certificate will never expire, as it will encrypt all client-server communications for an unlimited period.

Today, Vitor’s websites are up and running smoothly at Hostinger. In fact, the latest GTMetrix test gave his business site No Code Backend a B score on the overall speed, with a 94% in performance.

What’s Next?

VTB Solutions and Hostinger have one common mission – giving small to medium-sized enterprises the tools and support to run their businesses. With us, Vitor no longer has to worry about not receiving help when he needs it the most.

“Hostinger’s support is really good and really fast – it’s very different from our previous provider. There, a lot of things happened that I couldn’t even imagine in the first place, that made me have to ask, ‘Why did that happen?’ That’s a big part of why we’re with Hostinger now, and why we probably won’t change, ”said Vitor.

Up next, Vitor will continue to work with his clients and scale his business even further. His ultimate goal is to “democratize software development” using AI so that anyone can build their own solution easily and affordably.

No matter what Vitor needs in his web hosting, our Customer Success team will always be ready to help him.

For over two decades, there’s been a system to help companies recover domain names that infringe their trademarks. Called the Uniform Domain Name Dispute Resolution Policy (UDRP), this system is designed to be easier, faster, and cheaper than using the court system to go after cybersquatters.

It works as designed – bridge of the time. Sometimes, companies that covet valuable domain names make spurious claims through the UDRP. When they go too far, the panelists (think judges) overseeing the case will say that the company tried to “reverse domain name hijack” the domain.

What’s UDRP?

Think of UDRP as a stripped-down version of a lawsuit. A company with a trademark (called the Complainant) files a case against someone who owns a domain (called the Respondent) that it says infringes on its trademark.

The Complainant files the case and the Respondent gets a chance to defend itself. A panel of one to three people (usually active or retired attorneys) reviews the case and decides if the domain should be transferred to the Complainant or remain with the Respondent. The entire process can be completed in weeks, rather than the months or years required for a lawsuit.

Proving cybersquatting

To win the case, the Complainant has to show three things:

1. The domain matches or is confusingly similar to a mark in which it has rights. It needs to show that it has a registered or common law trademark matching (or similar to) the domain.
2. The Respondent lacks rights or legitimate interests in the domain name. The Complainant makes a case, and the domain owner can put up a defense, such as that they registered the domain for a legitimate business or personal reason.
3. The Respondent registered and used the domain in bad faith. The Complainant needs to show that the domain owner registered the domain to target the Complainant.

Of the decided cases, over 90% are found in favor of the Complainant. This makes sense because most of the cases are clear-cut. Morgan Stanley recently won a case against morganstanley-futures.com, Impossible Foods won a case against a look-a-like domain imposslblefoods.com (swapping an L for an I), and Home Depot won a case to recover homedepotcustomercenter.com. These are all obvious cases of cybersquatting and the types of disputes the system was created to resolve.

Overstepping

What about the other 10% or so of cases that the Complainant doesn’t win? In some cases, they are a close call, and the panelists defer to the domain owner. Other cases are more appropriate for courts where claims can be vetted. And in some cases, Complainants tried to use the UDRP to get a domain name they have no rights to without paying for it.

These are reverse domain name hijacking (RDNH) cases. Here are a few recent examples:

• wex.com – Wex Inc., a publicly-traded technology company, tried to get wex.com. The panel determined that Wex left critical information out of its case and submitted misleading evidence. Disputes involving three-letter domains frequently end in RNDH decisions because the domains are valuable and can be used by many different companies.

• ecostream.com – Water management company Ecostream LLC tried to get this domain through UDRP. The domain owner registered the domain before the Complainant had any trademark rights in the name, which means it could not show that the domain was registered in bad faith. Ecostream first tried to buy the domain before filing the case. This scenario – when a company files a UDRP after failing to buy a domain – is usually labeled a “Plan B” RDNH.

• bartko.com – This case was especially egregious because a law firm was the Complainant. Bartko Zankel Bunzel & Miller filed the case on its own behalf, apparently in an effort to shorten its domain name to bartko.com. The domain name owner’s last name was Bartko, which means the case was doomed to fail on the issue of whether the domain owner had rights or legitimate interests in the domain. (If the domain matches your surname, that means you have a legitimate interest in the domain.)

No penalties

While an RDNH filing might be embarrassing for the company that filed its complaint (or at least its lawyers), there is no financial penalty for filing an RNDH case.

Some domain owners have called for there to be a penalty in order to deter companies from filing bad cases. This idea hasn’t gone anywhere yet.

It’s worth noting that courts can assess financial penalties for reverse domain name hijacking, but that’s in relation to lawsuits filed under the Anticybersquatting Consumer Protection Act (ACPA), not UDRP.

Protect yourself

Domain owners can do a couple of things to protect themselves from both UDRP cases and reverse domain name hijackers.

First, don’t register domain names to target trademark holders. This is cybersquatting and you might lose your domain in a UDRP. Worse, you could be sued and have to pay damages.

Second, talk to a domain name attorney if one of your domains is hit with a UDRP and you think it’s baseless. They can help you respond to the dispute and perhaps win a reverse domain name hijacking finding.

How to Recognize a Distributed Denial-of-Service (DDoS) Attack

To avoid an attack, you need to know what’s coming your way. When you spot an attempt to disrupt the regular traffic of a targeted server, service, or network by overburdening it with unwanted traffic, you’re dealing with a distributed denial-of-service (DDoS) attack.

A DDoS attack attempts to deny access to a targeted server by generating a large amount of malicious internet traffic which overwhelms the target’s available resources.

Today, we’ll discuss how we combat such attacks and detail our DDoS countermeasure setup and overall infrastructure.

What Does an Attack Look Like?

Here’s a real-life example of a DDoS attack. Picture 400 Mbps of UDP traffic heading to a VPS with an available bandwidth of 100 Mbps.

Simple Jekyll website load time results:
Before the attack: 0.08 seconds
During an attack: 23.35 seconds (1st attempt), 30.86 seconds (2nd attempt)

DDoS attacks are often hard to mitigate because they usually involve whole or multiple botnets targeting you. A botnet consists of many infected systems, so fighting it on your own will, most of the time, prove useless.

How We Deal With DDoS Attacks

We have two DDoS mitigation solutions for dealing with incoming attacks in our infrastructure – remotely triggered black hole (RTBH) and traffic filtering.

RTBH filtering offers a way to eliminate unwanted traffic quickly before it enters our infrastructure. While this method effectively protects our infrastructure as a service provider, it prevents all traffic from hitting us – not something our clients prefer. Eventually, their websites and VPSs become completely unreachable. As a result, the attackers achieve their goals.

Traffic filtering is the next-level DDoS protection for our services. It only stops the malicious traffic instead of dropping all of it. Malicious traffic is identified by examining the packets flowing through our infrastructure. The following traffic elements are inspected for specific patterns:

• packet payload
• source port
• source IP
• destination port
• country
• and more

This filtering process is done on our infrastructure before the traffic reaches our services, so our clients have nothing to worry about.

Traffic Filtering

Setup

We have implemented out-of-line filtering for our setup. Since we rarely experience powerful DDoS attacks, in-line filtering would be inefficient in actual practicality and cost – we have the RTBH method to combat them, instead.

Our setup involves filter instances connected to spine switches through which diverted traffic flows. We use sFlows, which are sent from spine instances to the filter instance, to investigate and divert traffic if needed. Clean traffic is forwarded to leaf switches, while malicious traffic is dropped at the filter instance. It’s important to note that the traffic diversion and filtering processes are fully automated.

If any destination host experiences a traffic spike above our set thresholds, we advertise that IP address to the spines using ExaBGP. When the traffic arrives at a filter instance, we examine the incoming packets to identify the attack pattern. Once complete, new rules are added to the firewall, preventing malicious traffic from reaching its destination.

Hardware

The main elements that the filter server depends on are the CPU and NIC. After some testing and research, we decided to go with the following:

CPU: Intel (R) Xeon (R) Silver 4215R @ 3.2 GHz
NIC: Intel XL710 (40G)

During a DDoS attack with ~ 1.5 Mpps and 8 Gbps of traffic, the CPU usage looks like this:

Automation

It would be tough to manage multiple filter instances across all data centers manually. As a result, the whole solution is fully automated, from attack detection to threshold settings. Currently, we use Chef and Ansible for our infrastructure as code (IaC). Changing thresholds or other settings for all instances at once is as easy as changing a few lines of the code.

Configuration

Here’s a sneak peek at our configuration:

Our instance must be able to route packets between interfaces, so forwarding is enabled for both IPv4 and IPv6. Since we don’t have any routes via interfaces used for traffic diversion, we must disable reverse path filtering or set it to “loose mode” – as we have done – so the packets coming via those interfaces don’t get dropped.

We have increased the maximum number of packets in one NAPI poll cycle (net.core.netdev_budget) to 1000. As we prefer throughput over latency in this case, we’ve set our ring buffers to the maximum.

We’ve been running this solution for six months and can see that these small changes are enough to handle any attacks of the anticipated scales. We didn’t go deeper into tuning the system as the default values ​​are reasonable and don’t cause any problems.

Next, we have actions. An action is triggered when an attack is detected or finished. We use it to divert traffic (route announcement via ExaBGP), inform our monitoring team about the attack (a Slack message from the instance), and more.

Thresholds are also managed as code, providing numerous options for detecting an attack. For example, if we detect 100K UDP packets per second aimed at a single target, we start the filtering process. It can also be TCP traffic, HTTP / HTTPS requests, and so on.

The prefixes that should be under protection are also added automatically from Chef data bags.

Results

What does the handling of a DDoS attack look like on Grafana? Let’s look at a recent attack with 8 Gbps and 1 Mpps of traffic below.

Here’s the traffic incoming to the filter instance:

And here’s the traffic outgoing to the end device:

Incoming packets per second:

Outgoing packets per second:

As you can see, there is a short burst of traffic going from the filtering instance to the end device. It is the gap caused by the attack pattern identification process. It’s a short amount of time, usually between 1 and 10 seconds, but it’s something to be aware of. As seen on the graph, once the attack pattern is identified, you’re safe!

What about the speed of attack detection? This part depends on sFlows, and, as we know, it’s not as fast as port mirroring. That said, it’s easy to set up, flexible, and costs less. Once an attack starts, the time to divert the traffic to the filter instance takes between 20 and 50 seconds.

This is how the whole process looks from the target instance:

Traffic

Packets per second

There’s a short spike and we’re back to business as usual. Depending on the service you’re running, you may not even notice it.

At Hostinger, we like to know what is happening in our infrastructure, so let’s investigate this case a little bit further:

Attack source. We noticed an increase in IPv4 traffic from a few countries, with India and Taiwan contributing the most. There is a high possibility that those IPs were spoofed, so this information may be inaccurate. We have the list of source addresses and ASNs but won’t publish it here for the same reason (spoofing).

Attack protocol. This attack was mainly based on UDP as we didn’t see any unusual increases on the TCP graph.

Attack type. It generated a large amount of traffic to random UDP ports. A few of them are seen on the graph below:

Summary

RTBH, as DDoS protection, is effective but eventually causes downtime. After implementing the traffic filtering solution in our infrastructure, we only drop malicious traffic instead of all of it. We’ve noticed that RTBH usage has decreased by 90-95%resulting in a better uptime for our services and clients.