Jusqu'où peut-on aller soi-même dans l'analyse avec la gestion de surface d'attaque open source ?

Lors des scans actifs, il faut faire très attention à la limitation de débit. Si vous lancez une analyse qui envoie des centaines de paquets par seconde, les systèmes de détection d'intrusion du centre de données vont isoler automatiquement votre serveur. Vous devez exécuter vos scans en thread unique et en appliquant un délai entre chaque requête.

Avec les outils open source, on voit uniquement si la porte est ouverte ou pas. Ces outils ne vous diront jamais comment les données situées derrière cette porte peuvent être dérobées, ni comment la combinaison de deux services distincts peut créer une faille. Il ne faut pas tomber dans un faux sentiment de sécurité.

L'année dernière, j'ai lancé un scanner open source similaire sur notre serveur à Berlin. Une heure après, l'hébergeur nous a envoyé un avertissement pour activité malveillante et notre trafic a été suspendu. Le temps d'expliquer la situation, nos systèmes sont restés coupés pendant une demi-journée.

Pour commencer, utilisez plutôt des outils de reconnaissance passive. Sans envoyer le moindre paquet à aucun serveur, uniquement via les enregistrements publics, vous pouvez dénicher des dizaines de sous-domaines oubliés et de vieilles pages de test. Commencez par fermer ceux-là.

un conseil, lancez pas de scan agressif sans prévenir le datacenter et faire whitelister vos ips sinon vous allez vous taper le service abuse.

Les serveurs que vous utilisez sont des dédiés qui vous appartiennent entièrement ou des instances cloud partagées ? Dans les environnements mutualisés, les règles sont beaucoup plus strictes à cause du risque d'impact sur les autres clients du même bloc d'IP.

Même sur votre propre infra, ne lancez pas de scan actif de vulnérabilités au niveau réseau sans en informer formellement votre datacenter.

Je partage mon expérience. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

N'hésitez pas à demander, celui qui ne demande pas paie toujours plus cher. Voilà, désolé si je me suis étendu.

J'aimerais poser une question. Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Je ne savais pas ça. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Je suis dans la même situation c'est pourquoi je pose la question... bon l'erreur commise du côté de surface d'attaque open source est généralement réversible mais coûteuse.

À votre place, j'irais par cette voie.

Il faut y aller étape par étape. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

Une modification des coordonnées bancaires n'est jamais confirmée par le canal d'origine. Voilà, désolé si je me suis étendu.

Je ne suis pas d'accord sur ce point. Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur. C'est confirmé par l'expérience.

Absolument. Si j'ajoute quelque chose : Si l'autorisation et le périmètre ne sont pas écrits ne lancez pas ce test.

Si j'ai bien compris vous dites que : L'erreur commise du côté de surface d'attaque open source est généralement réversible, mais coûteuse.

Exact.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort.

C'est confirmé par l'expérience.

Chez nous, ça s'est passé comme ça. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

Bien sûr, cela change si votre situation est différente.