Sécurité RexOS Shield
Les attaques s'arrêtent à la porte, bien avant d'atteindre le serveur.
Chaque requête vers ce site traverse 12 couches de protection, du bord du réseau jusqu'au code qui y répond. Les vrais joueurs et les moteurs de recherche passent sans rien remarquer.
- Surveillé 24 h/24
- OWASP Top 10 couvert
- HTTPS uniquement, avec HSTS
- Connexion en deux étapes
- Attaquants signalés avec preuves
Ce que Shield a bloqué cette semaine
Comptés sur ce site par Shield lui-même. Les moteurs de recherche vérifiés et les vrais visiteurs ne sont pas inclus.
- 7,011dim.
- 8,291lun.
- 7,842mar.
- 8,359mer.
- 10,260jeu.
- 12,986ven.
- 1,198Aujourd’hui
Aujourd'hui, par type
- Scrapers SEO
- 985
- Attaques stoppées par le pare-feu
- 181
- Bots malveillants et faux navigateurs
- 25
- Requêtes falsifiées à l'entrée
- 5
- Attaquants récidivistes bannis
- 1
- Vérifications humaines échouées
- 1
2,993 visites vérifiées de moteurs de recherche et de robots IA autorisées aujourd'hui
Signalés ce mois-ci, par catégorie
- Port Scan110
- Web App Attack110
- Exploited Host54
- Bad Web Bot37
Comment une requête est contrôlée
Chaque visite parcourt ce chemin en quelques millisecondes. Une requête qui échoue à une étape ne va pas plus loin.
- Bordure
Les requêtes falsifiées ou cassées sont rejetées.
- Réputation
Les réseaux malveillants connus sont refusés.
- Contrôle du navigateur
Le navigateur doit correspondre à son appareil et à son réseau.
- Pare-feu
En-têtes, formulaires et corps d'API sont décompressés et inspectés.
- Limites
Les floods et les tentatives de mots de passe sont freinés.
- Application
La page est construite uniquement avec des requêtes sûres.
- Contrôle des fuites
La réponse est vérifiée avant de partir.
Les sept étapes réussies : la page est servie. Les moteurs de recherche et robots d'IA sont vérifiés à l'étape 3 et jamais ralentis.
Ce qu'il arrête
Les attaques les plus fréquentes, et ce qui arrive à chacune.
| Menace | À quoi ça ressemble | Ce que fait Shield |
|---|---|---|
| Injection SQL | Commandes de base de données cachées dans un formulaire, un lien ou un appel API. | Décodé, détecté et bloqué avant toute requête. |
| Cross-site scripting (XSS) | Code de script glissé dans un avis, un profil ou un lien. | Bloqué à l'entrée, et chaque page échappe ce qu'elle affiche. |
| Exécution de code à distance | Commandes shell ou code envoyés pour que le serveur les exécute. | Détecté dans chaque saisie et bloqué au pare-feu. |
| Recherche de fichiers secrets | Requêtes visant les fichiers .env, les sauvegardes, wp-config et les outils d'administration. | Bloqué immédiatement. Les scanners récidivistes sont bannis et signalés. |
| Attaques par force brute | Des milliers de connexions depuis des adresses changeantes. | Ralenti, puis bloqué. La connexion en deux étapes arrête les mots de passe volés. |
| Scrapers et faux bots | Un bot qui se fait passer pour Googlebot ou un navigateur normal. | Vérifié selon son réseau et son appareil. Les faux sont arrêtés. |
| Abus de Tor et de proxys | Attaques cachées derrière Tor, des VPN et des serveurs loués. | D'abord une vérification humaine. La plupart des outils automatisés abandonnent là. |
| Floods applicatifs | Une rafale de requêtes lourdes destinée à ralentir le site. | Limites de requêtes par adresse, puis un verrouillage automatique. |
| Spam et fraude | Faux avis, spam de tickets et abus de commandes ou de récompenses. | Contrôlé à l'envoi. Les commandes frauduleuses sont signalées. |
Les attaques cachées sont d'abord décodées
Les attaquants déguisent leur code pour tromper les filtres simples. Shield décode chaque couche avant de décider. Ces trois exemples sont de vrais tests de notre dernier audit.
%2527%20UNION%2F**%2FSELECT%20password%20FROM%20usersse lit comme' union select password from usersBloqué : Injection SQL&lt;svg onload=alert(1)&gt;se lit comme<svg onload=alert(1)>Bloqué : Cross-site scripting (XSS)／ｅｔｃ／ｐａｓｓｗｄse lit comme/etc/passwdBloqué : Accès aux fichiers système
Chaque couche, une mission
Chaque couche couvre une voie d'entrée différente. Ensemble, elles protègent le site, le launcher et chaque compte.
Filtrage en périphérie
Les requêtes malveillantes et falsifiées sont rejetées en périphérie, avant l'exécution de l'application.
Renseignement sur les menaces
Le trafic provenant de réseaux malveillants connus est bloqué grâce à des listes de menaces mises à jour en continu.
Gestion des bots
Une vérification multi-signaux sur ordinateur et mobile contrôle que chaque navigateur correspond à son appareil et à son réseau. Les robots des moteurs de recherche et de l'IA sont vérifiés, les imposteurs arrêtés.
Contrôle des proxys et de l'anonymat
Les visiteurs passant par Tor, des VPN ou des réseaux d'hébergement, ou les navigateurs qui trahissent un proxy loué, doivent réussir une vérification humaine avant de voir le site.
Pare-feu applicatif web
Chaque requête, en-têtes et corps d'API compris, est inspectée contre les injections, le cross-site scripting et les autres attaques de l'OWASP Top 10. Les charges encodées et obfusquées sont d'abord décodées, si bien que les techniques de contournement échouent.
Détection des scans et anomalies
Les recherches d'outils d'administration, de fichiers secrets, de sauvegardes et d'exploits connus sont bloquées immédiatement. Des leurres démasquent les robots qui ignorent les règles.
Protection des comptes
Les tentatives de force brute et de bourrage d'identifiants sont ralenties et bloquées. La connexion en deux étapes protège les comptes sur le site et dans le launcher, et est obligatoire pour l'équipe.
Prévention des fuites de données
Les réponses sortantes sont inspectées pour que les secrets et les détails internes ne quittent jamais le serveur.
Durcissement du serveur
Les fichiers sensibles sont inaccessibles depuis le web, et le contenu envoyé ne peut jamais s'exécuter sur le serveur.
Protection contre le spam et la fraude
Les avis, tickets et fiches sont filtrés contre le spam et les envois automatisés. Les commandes et les récompenses sont contrôlées pour qu'elles ne puissent pas être détournées.
Protection contre les floods et surveillance
Les floods au niveau applicatif déclenchent un verrouillage automatique. Chaque événement de sécurité est consigné en détail et transmis à l'équipe en temps réel.
Signalement des abus
Les attaquants, spammeurs et commandes frauduleuses confirmés sont signalés à des bases de données d'abus mondiales, chacun avec sa catégorie et ses preuves.
Les bons bots entrent, les faux restent dehors
Les moteurs de recherche et assistants IA ne passent qu'après confirmation qu'ils viennent de leur vrai propriétaire. Tout le monde peut copier le nom d'un bot, personne ne peut copier son réseau.
- Googlebot
- Googlebot smartphone
- Google-InspectionTool
- Googlebot-Image
- Bingbot
- Applebot
- DuckDuckBot
- GPTBot
- OAI-SearchBot
- ChatGPT-User
- ClaudeBot
- Claude-User
- PerplexityBot
- MistralAI-User
Un « Googlebot » venant d'un serveur loué est bloqué.
Testé contre de vraies attaques
Voici les résultats de notre dernier audit complet.
Vérifié le
- 1,260
- charges d'attaque envoyées vers 7 points d'entrée différents. Toutes ont été bloquées.
- 0
- blocage à tort sur 631 avis, commentaires et messages normaux.
- 14
- moteurs de recherche et robots d'IA testés. Tous sont passés, les faux non.
À quoi ressemble un signalement d'abus
Quand un attaquant est confirmé, les preuves sont envoyées à AbuseIPDB et Spamhaus pour que d'autres sites puissent aussi le bloquer. Cet exemple utilise une adresse de documentation.
IP 203.0.113.47 · Web App Attack, SQL Injection, Hacking Blocked 14 requests in 3 minutes by RexOS Shield (web application firewall) GET /search?q=1%27%20UNION%20SELECT%20password%20FROM%20users-- GET /.env · GET /wp-config.php.bak · GET /admin/phpinfo.php User agent: python-requests/2.31 · Network: hosting provider
Comment les comptes et les données sont protégés
La protection ne s'arrête pas au pare-feu. Ces règles sont intégrées au site lui-même.
Mots de passe
Stockés uniquement sous forme de hachages forts à sens unique. Personne ne peut les lire, nous compris.
Connexion en deux étapes
Sur le site et dans le launcher, et obligatoire pour l'équipe.
Sessions
Les cookies sont HttpOnly, sécurisés et same-site : ni les scripts ni les autres sites ne peuvent les utiliser.
Formulaires
Chaque formulaire porte un jeton à usage unique : d'autres sites ne peuvent pas l'envoyer à votre place.
Base de données
Chaque requête est préparée : une saisie ne peut jamais devenir une commande.
Règles du navigateur
HSTS, Content Security Policy, règles de frame et de referrer sur chaque page.
Envois de fichiers
Les images et fichiers ne peuvent jamais s'exécuter comme du code sur le serveur.
Launcher
Open source et compilé publiquement par GitHub Actions.
Comment nous le mettons en place pour vous
Dites-nous ce que vous utilisez
Votre site, serveur, boutique ou panel, et les attaques que vous avez subies.
Nous étudions votre trafic
Nous apprenons ce qui est normal pour vous, pour que les vrais joueurs ne soient jamais bloqués.
Shield est activé
La protection est activée étape par étape, avec des journaux dès la première minute.
Nous continuons à surveiller
Alertes, rapports mensuels et aide dès qu'une attaque commence.
Vous voulez la même protection pour votre serveur ou votre site ?
Nous installons RexOS Shield pour les réseaux Minecraft, les boutiques et les sites communautaires. Dites-nous ce que vous gérez et nous vous répondrons avec un plan.
- Pare-feu et protection anti-bots adaptés à votre trafic
- Les moteurs de recherche et les vrais joueurs ne sont jamais bloqués
- Attaquants signalés avec preuves
- Journaux détaillés et alertes en temps réel
- De l'aide pendant une attaque
Questions
La protection ralentit-elle le site ?
Non. La plupart des contrôles ont lieu avant la construction de la page, donc une visite normale n'est pas plus lente.
Peut-elle bloquer Google ou de vrais joueurs ?
Les moteurs de recherche et robots d'IA vérifiés passent toujours, et les visiteurs normaux passent sans rien remarquer.
Que deviennent les attaquants ?
Ils sont bloqués et enregistrés, puis, une fois confirmés, signalés à AbuseIPDB et Spamhaus avec preuves.
Puis-je avoir cette protection pour mon propre serveur ou site ?
Oui. Nous installons RexOS Shield pour les réseaux Minecraft, les boutiques et les sites communautaires. Contactez-nous et dites-nous ce que vous gérez.
Est-ce que cela arrête les attaques DDoS ?
Il arrête les floods visant le site lui-même, comme les rafales de requêtes et les floods de connexion. Les très gros floods réseau doivent être absorbés par le réseau de l'hébergeur, et nous vous aidons à le configurer.
Quelle différence avec un plugin de pare-feu classique ?
Shield s'exécute avant le site, décode les attaques déguisées, vérifie les bots auprès de leurs vrais propriétaires et partage les attaquants confirmés avec des bases de données d'abus.
Comment signaler un problème de sécurité ?
Ouvrez un ticket de support et commencez l'objet par Security. Nous répondons vite et créditons les signalements responsables.
Vous avez trouvé une faille de sécurité ?
Nous accueillons les signalements des chercheurs et des joueurs, et nous créditons ceux qui agissent de façon responsable.
À faire
- Ouvrez un ticket de support et commencez l'objet par Security
- Indiquez les étapes pour la reproduire
- Laissez-nous le temps de la corriger avant de la rendre publique
À ne pas faire
- Consulter ou modifier les données d'autres personnes
- Lancer des floods ou des tests de charge
- Utiliser des scanners automatiques à grande vitesse
Si vous le faites, l'activité est enregistrée et remontée jusqu'au réseau d'où elle provient. Nous pouvons la signaler avec les preuves à ce fournisseur et aux bases de données d'abus ; le fournisseur peut identifier le titulaire de l'abonnement derrière l'adresse. Les cas graves peuvent être signalés directement aux autorités compétentes, et vous êtes responsable des conséquences juridiques.
En France, ces attaques sont des délits. L'accès frauduleux à un système informatique (article 323-1 du Code pénal) est puni de 3 ans d'emprisonnement et de 100 000 € d'amende, et de 5 ans et 150 000 € s'il endommage des données. Entraver un système ou modifier ses données (articles 323-2 et 323-3) est puni de 5 ans d'emprisonnement et de 150 000 € d'amende.
