Ce que nous faisons · Réseau: Firewalls périmétriques infogérés
Les services exposés au public à Athènes sont placés derrière des paires de firewalls redondants et à état, avec une politique default-deny par hôte, un blocage par threat intelligence et par pays, et la possibilité d'ouvrir un service à un seul pays. Chaque règle porte le nom de l'hôte qu'elle protège, chaque changement passe par une API avec une sauvegarde préalable, et chaque firewall remonte vers notre journalisation centrale.
De quoi il s'agit
Un périmètre infogéré : les firewalls devant vos adresses publiques, exploités par nous comme une partie du réseau et non comme une boîte que vous configurez seul. Vous nous dites ce que chaque service doit exposer et à qui. Nous le construisons comme une politique nommée et documentée, nous la tenons à jour et nous la prouvons de l'extérieur.
Comment nous le construisons
- La haute disponibilité par conception. Les firewalls OPNsense tournent en paires actif et secours. Des adresses virtuelles CARP couvrent le côté amont comme votre passerelle, et pfsync réplique l'état des connexions entre les nœuds, de sorte qu'une panne de nœud est une bascule à état en moins d'une seconde.
- Une politique qui se documente elle-même. Chaque hôte intégré reçoit son propre alias nommé et ses propres règles.
- Une pile de blocage ordonnée. Le trafic rencontre d'abord une liste de threat intelligence combinée, construite à partir de plusieurs flux de réputation, puis une liste unifiée de blocage par pays, puis un blocage des plages d'hébergement abusives, et seulement ensuite les autorisations par hôte. Si votre audience est dans un seul pays, vous pouvez avoir à la place une liste d'autorisation de l'espace d'adressage de ce pays.
- Réglés pour de vraies attaques. Le traitement des paquets est réparti sur les cœurs du processeur, avec un nombre de threads adapté à chaque appliance. Les services publics à fort trafic UDP sont traités sans état pour ne pas épuiser la table de connexions, et la défense contre les SYN floods utilise des cookies adaptatifs et des délais dimensionnés d'après l'arithmétique de la table d'états.
- Modifiés par l'API, jamais à la main. Chaque changement passe par l'API REST d'OPNsense et le résultat est vérifié depuis un point d'observation externe.
- Des chemins de sauvegarde à sens unique. La production n'a aucun chemin réseau vers l'infrastructure de sauvegarde. Les systèmes de sauvegarde tirent ; la production ne pousse jamais. Cela est imposé par des règles de refus sur les appliances firewall elles-mêmes, pas sur les hôtes.
- Une journalisation qui ne peut pas se taire. Un watchdog réaffirme sur minuteur la configuration de journalisation de chaque firewall, de sorte qu'un firewall ne peut jamais cesser de remonter vers Graylog sans que personne ne le remarque.
Nous exploitons à la fois Cisco Firepower et OPNsense, et lorsque nous déplaçons un segment d'une plateforme de firewall à une autre, nous suivons une méthode écrite et par phases : le nouveau firewall rejoint le routage sans rien annoncer, puis prend la main un VLAN à la fois, par une bascule scriptée avec un rollback automatique conditionné par des pings.
Ce dont il vous protège
- Du trafic de force brute et de balayage venant de sources connues comme malveillantes, et de pays où vous n'avez aucune audience.
- D'une panne de firewall qui couperait toutes les sessions.
- De l'épuisement de la table de connexions par des floods UDP ou SYN.
- De règles non documentées que personne n'ose retirer.
- D'un journal de sécurité qui ne va discrètement nulle part jusqu'au jour où vous en avez besoin.
En pratique
Un CRM ouvert à un seul pays. Le CRM et l'environnement de test d'un client du commerce de détail ont été intégrés avec un accès web et administration autorisé uniquement depuis le pays qu'il sert, tout le reste refusé, et vérifiés sur les deux nœuds du firewall. Lorsque l'entreprise a eu besoin de deux pays supplémentaires, nous les avons ajoutés le lendemain.
Pourquoi EuroVPS
- Des paires redondantes avec bascule à état, pas un firewall unique.
- Une politique default-deny par hôte, nommée, que vous pouvez lire.
- Threat intelligence, blocage par pays et listes d'autorisation à un seul pays comme options standard.
- Des changements uniquement par l'API, et une journalisation centrale qui est elle-même surveillée.
- Des réseaux de sauvegarde que la production ne peut pas atteindre, imposé au niveau du firewall.
Questions fréquentes
Puis-je restreindre mon service aux visiteurs d'un seul pays ? Oui. Nous remplaçons la pile de blocage par défaut par une liste d'autorisation de l'espace d'adressage de ce pays, et nous pouvons ajouter des pays plus tard.
Que se passe-t-il si un nœud du firewall tombe en panne ? Le nœud de secours reprend les adresses virtuelles et l'état des connexions existantes, en général en moins d'une seconde.
Puis-je voir les règles ou demander des changements ? Oui. Les règles sont nommées par hôte, nous pouvons donc vous montrer exactement ce qui est ouvert pour chaque service et le modifier sur demande.
Bloquez-vous les attaques automatiquement ? Oui. Les listes de threat intelligence, de pays et de plages abusives sont appliquées avant vos propres règles et tenues à jour.
Si vous voulez vos services publics derrière un périmètre construit et surveillé ainsi, parlez à un ingénieur.
Votre prochain partenaire d'infrastructure
Examinons votre environnement.
Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.
+357 222 32280
Commençons par votre environnement.
Un peu de contexte nous aide à démarrer la bonne conversation.