Every day, new DDoS attacks threaten the defense systems of companies and weaken networks even more. These DDoS attacks are increasing with the crisis that the world is experiencing today.
Find in this document how a DDoS attack is carried out and which solutions should be chosen to stop them.
Every day, new cyberattacks threaten the defense systems of companies, and further weaken networks, cyberattacks occur exponentially.
Find in this 5 minutes to understand document what are the most common cyberattacks’ operating modes and the solutions to implement to counter them.
The digital world is in perpetual evolution and every days, new domain names are registered around the world.
Among these new registrations, some can potentially affect your notoriety, your activity, and your results. Fraudsters, through these abusive domain names registrations, seek to benefit from your notoriety as quickly as possible.
Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, the different practices of abusive domain names registrations that can affect your brand and the actions to take depending on the infringement caused to the brand.
Every day, new cyberattacks are threatening companies’ defense systems, and further weaken relations with web users, particularly on e-commerce websites. Identity theft and data theft have become common.
The risks of a malicious person intercepting the data transmitted by the web user on your website and more generally all the information transmitted between the browser and the server of your website ,are increasing significantly.
Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, the solution to implement against these risks.
On November 17, Mozilla released the version 83 of the Firefox browser, promising improved performance in terms of page loading and browsing responsiveness, as well as a significant reduction in the memory used.
But above all, Mozilla introduces a brand-new security feature to the small world of browsers, an “HTTPS-Only Mode” option to limit browsing to secure HTTPS* connections only.
Mozilla is pushing it further regarding the desire of major browsers to pass HTTPS as the default browsing protocol instead of the unencrypted and therefore fully visible HTTP.
When the option is activated, any web page that does not have an SSL/TLS certificate (allowing the HTTPS and the security padlock icon to be displayed in the browser address bar) will be preceded by the warning message below, which is restrictive for web users.
If the option is not yet activated by default, Mozilla’s management indicates that it expects HTTPS to become the standard for browsing the Web. Driven by the successive evolutions of browsers and their increasingly obvious displays of a lack of security, more and more websites are migrating to HTTPS by default. It is likely that browsers makers will decide to completely depreciate HTTP connections in the near future, making HTTPS the default protocol for Web browsing.
Most companies have already begun the migration of their website(s) to the HTTPS by default. It is important to maintain an exhaustive inventory of the company’s websites and pages and to control the associated SSL-TLS certificates, of which the main risks are renewal errors and poor implementation. It is essential to set up clear procedures and to associate to them a good communication towards the interlocutors in charge of the websites. Actors such as Nameshield are there to accompany you in this process. They have the expertise and tools necessary to simplify these tasks and reduce the risk of error.
Names’ holders must protect their brands and domain names against fraud and abuse just as they would protect any other valuable asset. The infringement of your domain name weakens the strength of your brand.
If, despite defensive registrations, which are a first line of defense, you find out that a third party has registered a disputed domain name, procedures exist to stop the infringement of your trademark and stop the damage.
Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, these different dispute resolution procedures related to domain names.
TLS/SSL certificates are used to authenticate servers (mostly Web) and encrypt traffic between websites and users. Thus, they ensure the integrity of the data exchanged and prevent data spying. The digitalization of the company and the world in general, as well as the browsers’ desire to impose HTTPS:// by default, have multiplied exponentially the need for certificates.
To meet these growing needs, the wildcard certificate (*.domainname.com) is increasingly being considered by companies. While it has some advantages, particularly in terms of costs reduction and flexibility, it is important to be aware of the disadvantages in order to choose the right certificate wisely. A brief overview of the wildcard certificate.
A standard TLS certificate secures an explicit host name (CN for Common Name or FQDN for Fully Qualified Domain Name) defined in its metadata. For example, Google holds a certificate for mail.google.com.
In other words, the host name must be an exact match. If you try to use this certificate on https://my.mail.google.com/ you will get a certificate error from your browser.
A TLS wildcard certificate is different. As its name implies, it uses a generic match rather than an exact match. This generic match is represented by “*” in the CN and covers all subdomains of the same level. Example with the *.google.com certificate.
In some situations, the wildcard certificate is very useful. A host that proposes websites for different clients, hosted on a shared server, and accessible through different subdomains… client1.mysite.com, client2.mysite.com, client3… It is less practical, technically more complicated and de facto more expensive to ask for a new certificate for each client that registers; the simplest option is a wildcard certificate for *.mysite.com, a unique certificate that will cover all clients. The case is identical for a company that wishes to access its websites through FQDN derived from the same domain and hosted on the same web server, *.mycompany.com. So far, everything is okay.
In the cases above, all sites are hosted on a single server. In large companies, or for major websites, hosting is often more complex and on different servers. Let’s take again our example of Google with images.google.com and mail.google.com, these two applications are linked to different services of the company, hosted on different servers and managed by different technical teams. This kind of organization is extremely frequent in the company. And this is where the security of wildcard certificates stops.
The problem with wildcard certificates, and to a lesser extent with certificates containing multiple entries (the famous SAN, Subject Alternative Names), comes from the fact that they are deployed on several servers. Indeed, to ensure the security of a TLS/SSL certificate, it is absolutely necessary to protect the private key associated with the certificate. Ideally, it should be stored in a vault or in a HSM. When a certificate is installed on several servers, the associated private keys circulate, increasing the exposure to the risk of compromise.
In case of a compromised certificate, or an error on the certificate (renewal problem), it is recommended to intervene quickly to limit the damage caused. Application for a new certificate (or renewal), installation of the new certificate and, if necessary, revocation of the compromised certificate.
In our example of creating websites on a single server, this is not a problem. We have only one server, it has been compromised, the stolen/expired/compromised certificate only works for this one server; we have limited the damage as much as possible.
In a “several servers” scenario, if the certificate of only one of the servers is affected, it becomes compromised on all of the servers, which will have consequences on all of them and require a much wider intervention to repair the damage, most often in an emergency, and assuming that all of the affected servers are identified. Indeed, it is not uncommon for the certificate to circulate within several teams and to be installed without being listed on a certain number of servers. The impact can be important.
Taking our example of Google. Let’s imagine that only the images.google.com server has been hacked and that mail.google.com has not been affected. The certificate for images.google.com being a wildcard certificate for *.google.com which is common to mail.google.com, the cyber-attacker having compromised the images service has by rebound usurped the identity of the mail.google.com server and can intercept the traffic of the mail service while this server has never been hacked!
In our last example, if we were to have two certificates instead of one, with each server having only access to its own certificate, we would have limited the risk. In an ideal world, each certificate should only be used for one server (or a homogeneous cluster of servers). Different services on different servers should have their own certificates, generally not wildcard certificates.
A wildcard can be used if you have a lot of host names, of subdomain type, pointing to the same service on the same server. Be careful however that this generic certificate does not also cover host names pointing to other servers, in which case each service should have its own certificates.
Lastly, if you have a few host names pointing to single servers and everything else on a single service, then it is better to disassociate the host names. For example, you may have a certificate for login.mysite.com and a (wildcard) certificate for *.clients.mysite.com. On this last example, if the number of clients is fixed or clearly defined, it is better to go for a certificate with a precise SAN list, to better control secure host names and not allow the httpS:// on uncontrolled host names.
The option of a wildcard certificate exists and it is a good thing for some very specific needs. But in practice, there should never be a need to install a wildcard certificate, nor should the same certificate be installed on different servers not built in cluster.
The .FORUM is an interesting new extension to exploit and secure.
For more information on the conditions of registration of your .FORUM, please contact your Nameshield consultant .
Launched by the Donuts registry, this .CONTACT extension is interesting, particularly for the contact pages of your websites.
This extension is also part of the TrueName program created by the Donuts registry: when registering a domain name in .CONTACT, Donuts will also protect the typographical alternatives of your brand by blocking them, thus preventing some phishing attempts through the registration by a third party of a typographically similar name (ex.: loulou.contact vs l0ulou.contact).
– Early Access Phase (EAP) Day 1: December 2/3
– Early Access Phase (EAP) Day 2: December 3/4
– Early Access Phase (EAP) Day 3: December 4/5
– Early Access Phase (EAP) Day 4: December 5/6
– Early Access Phase (EAP) Day 5-7: December 6/9
For any questions, your Nameshield consultant is at your disposal.
October is the month in Europe that celebrates cybersecurity. Every year, the aim of this operation is to make users aware of digital security issues, both on a personal and professional level.
Many players are mobilized on this occasion to alert on cyber risks and inform on existing protection measures.
It is in this context that the website cybervictime.net was launched!
This website is a digital manual of easy to implement solutions to protect your computer and your digital life.
You will find interesting tutorials about the security of:
