network Archives | Clever Cloud https://www.clever.cloud/blog/tag/network/ From Code to Product Mon, 16 Jun 2025 12:53:54 +0000 en-GB hourly 1 https://cdn.clever-cloud.com/uploads/2023/03/cropped-cropped-favicon-32x32.png network Archives | Clever Cloud https://www.clever.cloud/blog/tag/network/ 32 32 The End of the Fortress Metaphor https://www.clever.cloud/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/ https://www.clever.cloud/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/#comments Tue, 16 Jun 2015 14:04:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2015/06/16/the-end-of-the-fortress-metaphor/ fortress 1

This is the most seducing approach in IT security. This is also the worst. For more than 20 years now, people have believed that their network was a fortress, protected from the outside world by firewalls, NAT and DMZ. This idea is obsolete, we must change now. 20 years ago, it was still possible to see internal networks totally open, with every machine directly addressable from Internet. There were enough IPv4 addresses for everybody, the networks were small, life was good. But the security was atrocious: TCP stacks were remotely exploitable, worms were reproducing on corporate networks, internal file servers were publicly available, so people found the easiest way to secure everything on the cheap: isolate the network from the outside world. There's nothing wrong with that approach: it made sense at the time. As usual when someone finds a small, temporary hack instead of fixing everything, people kept improving it, approaching the local optimum. This led to firewalls on every machine, every network. People discovered that NAT could hide IP addresses, instead of simply allowing IP reuse, and thought it was a security feature. All of the nonsense about DMZ and airgapped networks appeared. Companies were actually selling hardware which would get packets from one network, disconnect (physically) from it, connect to another network, then send the packets. Airgap, yup. It worked for a time, since a lot of exploits in the 90s focused on remote exploits in operating systems and servers. If you cannot exploit the public face of the network, everything is alright.
The attacker is only one wrong click on a lovingly crafted PDF file away from your network.
Sysadmin taunting hackers
Unfortunately, we cannot think that way anymore. Web applications give too much entry points to your servers. Pivoting from a DMZ server to the internal network is easy, since internal users will also access those web applications. The attacker is only one wrong click on a lovingly crafted PDF file away from your network. Why would you concentrate on firewall rules when phishing is so effective? Once the attacker is in your network, it is over. Listen to traffic, elevate your privilege, pivot to another machine, impersonate users, traverse the whole network...
[caption id="" align="aligncenter" width="340"]Traditional IT infrastructure Traditional IT infrastructure[/caption]
The fortress metaphor, where everything behind your firewall is safe and trusted, is dead. Your walls are useful, but not that much when the attacker can get insiders to help him, willingly or unknowingly. The goal is not to keep the attacker out of your system. It is to detect the threat, isolate it, find the attacker's path and heal the system. The attacker may have been in your network for months. How would you be sure he is not there anymore? There is a much better metaphor than the fortress, now. Think of your system as a city. The city can have walls, but to function properly, it should let people enter and get out. You cannot know precisely if everything in your city is legit. Chances are, someone uses his personal USB key. Someone else connected a WiFi router in his office. People are talking on Facebook, watching porn, using forbidden applications, like modern browsers. You will not be able to catch them, unless repression is your main tool, and this will not help them work. You want to reduce criminality in your city, but you will not eradicate it. You cannot prevent fires, but you can prevent them from spreading too far and too fast. If you imagine the attacker as already present on your network, you go from plugging holes in one wall, to verifying dependencies and access control between systems. The trusted network approach is flawed, you have to think in terms of authorization from one user/app/machine to the other. The attacker will explore your network from one node to the next connected one, from one access level to the upper one, and try to combine them. Defenders think in lists, attackers think in graphs. You must assume that the internal network is as dangerous as the Internet.
Assuming that servers will be safer if they are on your own network leads to a false sense of security.
This is also why the nonsense around private cloud has to die. Assuming that servers will be safer on your own network leads to a false sense of security. A system built from scratch to handle the worst of internet has a better chance to survive. What matters is access control granularity around data, users and applications. The network is not a security boundary anymore. ]]> fortress 1

This is the most seducing approach in IT security. This is also the worst. For more than 20 years now, people have believed that their network was a fortress, protected from the outside world by firewalls, NAT and DMZ. This idea is obsolete, we must change now. 20 years ago, it was still possible to see internal networks totally open, with every machine directly addressable from Internet. There were enough IPv4 addresses for everybody, the networks were small, life was good. But the security was atrocious: TCP stacks were remotely exploitable, worms were reproducing on corporate networks, internal file servers were publicly available, so people found the easiest way to secure everything on the cheap: isolate the network from the outside world. There's nothing wrong with that approach: it made sense at the time. As usual when someone finds a small, temporary hack instead of fixing everything, people kept improving it, approaching the local optimum. This led to firewalls on every machine, every network. People discovered that NAT could hide IP addresses, instead of simply allowing IP reuse, and thought it was a security feature. All of the nonsense about DMZ and airgapped networks appeared. Companies were actually selling hardware which would get packets from one network, disconnect (physically) from it, connect to another network, then send the packets. Airgap, yup. It worked for a time, since a lot of exploits in the 90s focused on remote exploits in operating systems and servers. If you cannot exploit the public face of the network, everything is alright.
The attacker is only one wrong click on a lovingly crafted PDF file away from your network.
Sysadmin taunting hackers
Unfortunately, we cannot think that way anymore. Web applications give too much entry points to your servers. Pivoting from a DMZ server to the internal network is easy, since internal users will also access those web applications. The attacker is only one wrong click on a lovingly crafted PDF file away from your network. Why would you concentrate on firewall rules when phishing is so effective? Once the attacker is in your network, it is over. Listen to traffic, elevate your privilege, pivot to another machine, impersonate users, traverse the whole network...
[caption id="" align="aligncenter" width="340"]Traditional IT infrastructure Traditional IT infrastructure[/caption]
The fortress metaphor, where everything behind your firewall is safe and trusted, is dead. Your walls are useful, but not that much when the attacker can get insiders to help him, willingly or unknowingly. The goal is not to keep the attacker out of your system. It is to detect the threat, isolate it, find the attacker's path and heal the system. The attacker may have been in your network for months. How would you be sure he is not there anymore? There is a much better metaphor than the fortress, now. Think of your system as a city. The city can have walls, but to function properly, it should let people enter and get out. You cannot know precisely if everything in your city is legit. Chances are, someone uses his personal USB key. Someone else connected a WiFi router in his office. People are talking on Facebook, watching porn, using forbidden applications, like modern browsers. You will not be able to catch them, unless repression is your main tool, and this will not help them work. You want to reduce criminality in your city, but you will not eradicate it. You cannot prevent fires, but you can prevent them from spreading too far and too fast. If you imagine the attacker as already present on your network, you go from plugging holes in one wall, to verifying dependencies and access control between systems. The trusted network approach is flawed, you have to think in terms of authorization from one user/app/machine to the other. The attacker will explore your network from one node to the next connected one, from one access level to the upper one, and try to combine them. Defenders think in lists, attackers think in graphs. You must assume that the internal network is as dangerous as the Internet.
Assuming that servers will be safer if they are on your own network leads to a false sense of security.
This is also why the nonsense around private cloud has to die. Assuming that servers will be safer on your own network leads to a false sense of security. A system built from scratch to handle the worst of internet has a better chance to survive. What matters is access control granularity around data, users and applications. The network is not a security boundary anymore. ]]> https://www.clever.cloud/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/feed/ 1 Handling a Massive TV Effect on Your Website https://www.clever.cloud/blog/features/2014/01/13/handling-a-massive-live-tv-effect/ Mon, 13 Jan 2014 00:00:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2014/01/13/handling-a-massive-live-tv-effect/ French version below

On Saturday 11 January, Denis Payre, the president of 'Nous Citoyens' (a new French political movement) was a guest on French presenter Laurent Ruquier's show, 'On n'est pas couché.'

This new french political movement has been officially launched on the 10th of october 2013, and allow its members to be part of it, thanks to its collaborative website, developed by the parisian web agency Sooyoos.

Coded with PHP, a few configuration steps on Clever Cloud made by Sooyoos were needed to get the app ready for the TV broadcast.

Usually, the app runs on a 2GB and 2CPU scaler type (scalers are the equivalent of instances on Clever Cloud). But the TV audience brought 2 massive peaks of visits.

Around midnight, the webapp scaled from a L scaler size to a XXXL scaler size (8 CPU, 16GB of RAM), in a few seconds.

The trafic peak recorded at 0h15.

In most cases, media exposure of this kind (over 30 mins for Nous Citoyens here) leads to a huge load on the servers of the sites concerned, causing slowing down, and in the worst cases, periods of unavailability. For those who are lucky enough to be able to foresee such a load, the solution is to prepare a migration of the site to a more suitable infrastructure.

Unfortunately, this is not always the case. Because some companies fell victim to the "Capital effect" ('Capital' is a popular magazine program on the French TV channel, M6). According to social networks, some of them often acknowledged several minutes of unavailability during the program.

However, the Nous Citoyens website, hosted on Clever Cloud, remained perfectly stable throughout Denis Payre's interview on France 2, and that despite the increase in traffic due to the millions of television viewers.

Clever Cloud, therefore, managed the increased load without problem, thanks to an automatic attribution of resources to the infrastructure of NousCitoyens.fr.

Version française

Samedi 11 janvier, Denis Payre le président de Nous Citoyens, un nouveau mouvement politique, a été reçu dans l'émission de Laurent Ruquier "On n’est pas couché".

Lancé officiellement le jeudi 10 octobre et déjà fort de plusieurs milliers d'adhérents, Nous Citoyens propose à tous de devenir acteur du mouvement, notamment grâce à sa plateforme web collaborative conçue par l'agence parisienne Sooyoos.

Développée en PHP, celle-ci repose sur Clever Cloud pour son hébergement. Avec quelques réglages simples, l'agence Sooyoos a pu être en mesure de préaprer le site de Nous Citoyens à l'émission de France 2, où était invité Denis Payre.

En temps normal, la plateforme repose sur une scaler (équivalent d'instances chez Clever Cloud) de taille "Large", soit 2Go de RAM et 2 vCPU dédiés. Mais face à la forte médiatisation, 2 grands pics d'audience ont été enregistrés.

À partir de minuit, l'application a migrée d'une instance de taille 'L' jusqu'à 'XXXL' (8 CPU, 16Go de RAM), en passant par les tailles intermédiaires, puis est redescendue petit à petit vers sa taille d'instance habituelle.

Le pic de trafic rencontré à 0h15 pour NousCitoyens.fr

Dans la plupart des cas, une telle exposition médiatique (ici plus de 45 minutes pour Nous Citoyens) entraîne une charge momumentale sur les serveurs des sites web concernés causant des ralentissments, et dans le pire des cas, une indisponibilité.

En revanche, hébergé sur Clever Cloud, le site de Nous Citoyens est resté parfaitement stable tout au long de l'interview de Denis Payre sur France 2, et ce malgré la montée conséquente du trafic due aux millions de téléspectateurs.

Malheuresement, il n'en va pas de même pour tout le monde, certaines entreprises étant victimes de “l'Effet Capital” par exemple sur M6, résultant en ralentissments ou indisponibilité de quelques minutes au cours de l'émission. Pour ceux qui ont la chance de prévoir une telle charge, la solution est de prépaprer une migration du site sur une infrastructure adaptée.

]]> Is dotscale another boring cloud conference? https://www.clever.cloud/blog/company/2013/06/04/dotscale-conference/ Tue, 04 Jun 2013 00:00:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2013/06/04/dotscale-conference/
dotscale

Lire la version française

The dotConferences are always crazy. The first one of 2013 is the dotScale one. This cloud conference dedicated to developers takes place the 7th and 8th June 2013. The attracting mix is still the same : the best tech speakers in an amazing environment, the Paris “théâtre des variétés”. There are some new speakers and we are very proud to see our CEO Quentin Adam being part of them.

"No marketing speeches, no buzzword cover-ups"

Why is the dotScale so special and interesting ? For us, it is the concept itself: a conference which gives a voice to hardcore developers, more specially to those who work hard to offer innovative cloud solutions.


dotscale

Where the magic takes place.

The tech conference to supersize your apps

This event’s goal is to offer an affordable and unique conference to the developpers. It's also the occasion to understand the technical choices of the platforms they use for their own apps. Thereafter optimise them in order to make them more scalable by taking full advantage of the underlying platform.

Some of the best speakers you could expect

As we mentionned at the beginning of the article, Quentin will be a part of the event as a speaker. He will introduce Clever Cloud to the devs. The complete list of speakers is on the website. Finally, just know that some workshops will occur the day after the conferences (8th June).

We also wanted to thank Sylvain Zimmer for having contacted us 🙂

Version française

Les dotConferences sont toujours incroyables. Cette année, la première est la dotScale, la conférence cloud dédiée aux développeurs qui aura lieu les 7 et 8 juin 2013. La recette ne diffère pas énormément: le meilleur de la technique dans un décor incroyable, à savoir le théâtre des variété de Paris. Pour cette édition dédiée au cloud, nous sommes très fier d'y voir Quentin Adam (CEO de Clever Cloud).

Pas de discours marketing, pas de couverture de buzz

Ce qui rend la dotScale si spéciale (et si intéressante à nos yeux) c'est son concept lui même: proposer une conférence qui donne la parole aux hard développeurs, en clair à ceux qui mettent les mains dans le cambouis pour proposer des solutions cloud innovantes.

La conférence technique pour maximiser vos apps

L'objectif de cet évènement est de présenter une conférence pour les développeurs, abordable et unique. C'est aussi l'occasion de comprendre les choix techniques des plateformes qu'ils utilisent pour leur propres applications et donc de les optimiser, de les rendre plus scalables.

Les meilleurs speakers seront présents

Comme nous l'avons évoqué au début de ce billet, Quentin participe à l'évènement en tant que speaker. Il y présentera Clever Cloud aux développeurs. Pour connaître la liste des speakers présents, rendez-vous sur le site de l'évènement.

Sachez également que pour cette édition aussi des ateliers auront lieux le lendemain des conférences (le 8 juin).

Nous souhaitions enfin remercier Sylvain Zimmer de nous avoir sollicité 🙂

]]> Introducing Databases as a Service on Clever Cloud https://www.clever.cloud/blog/features/2013/05/02/external-db/ Thu, 02 May 2013 00:00:00 +0000 https://www2.cleverapps.io/wp/blog/technology/2013/05/02/external-db/ French version below

server

Another kind of ‘external’ DBs

Until now, databases hosted on Clever Cloud were only available from within the hosted apps. Since it was impossible to use external DB management software, it was a bit cumbersome to import or export data.

This era is over: right now, the services are available from outside!

Indeed, it means you will be able to use your favorite DB management tool. If you want to use our platform simply for host a database or if you have to access to your db for initial setup or migration, you can.
It also means you can use Clever Cloud as a pure Database as a Service (DBaaS) provider.

The current form (only available from within Clever Cloud apps) is
"dbname.engine.internal" (eg "customers.my.internal").

The new domain names will follow this pattern:
"dbname.engine.clvrcld.net" (eg "customers.mysql.clvrcld.net").

As for the ports, they stay the same (3306 for MySQL, 5432 for PostgreSQL).

Old domain names remain active for now (no sunset date is planned yet), but we strongly encourage you to make the switch.

We will indicate a date for the end of the internal databases services later.

The support remains at your service to help you tomigrate from .internal to clvrcld.net in your code.

Don't hesitate ton contact the support for more precisions 😉

Version française

Lancement des Databases as a Service sur Clever Cloud

Jusqu'ici les bases de données hébergées dans Clever Cloud n'étaient utilisables que depuis l'application hébergée. Il était alors impossible d'utiliser un outil de gestion de base de données externe, ce qui était fastidieux notamment pour les imports/exports.

Cette ère est révolue: désormais, les services sont accessible depuis l'extérieur !

Concrètement, cela signifie qu'il sera possible d'utiliser l'outil de management de votre choix. Si vous souhaitez utiliser notre plateforme uniquement pour héberger une base de données ou si vous devez accéder à votre base depuis l’extérieur pour l'amorçage ou la migration de vos données, c'est désormais possible.
Clever Cloud devient donc aussi fournisseur Database as a Service (DBaaS) !

La forme actuelle (seulement accessible depuis les applications Clever Cloud) est:
"dbname.engine.internal" (ex "clients.my.internal").

Les nouveaux noms de domaine adopteront désormais cette forme:
"dbname.engine.clvrcld.net" (ex "clients.mysql.clvrcld.net").

En ce qui concerne les ports, ils restent les même (3306 for MySQL, 5432 for PostgreSQL).

Nous préciserons une date de fin des services des bases de données internes ultérieurement.

Le support reste à votre service pour vous aider à migrer de .internal vers le clvrcld.net dans votre code.

N'hésitez pas à contacter le support pour plus de précisions 😉

]]>