Vous ne vous assurez pas que toutes les mises à jour de sécurité sont appliquées? N'oubliez pas qu'en tant que défenseur, vous devez gagner 100% du temps . Un hacker n'a besoin de gagner qu'une seule fois.

Les étapes que vous avez énumérées sont également beaucoup plus faciles à dire qu'à faire (sauf le mot de passe ... et pourtant les gens choisissent toujours des mots de passe horribles!).

2) En outre, qu'est-ce qu'une «source crédible» pour un serveur Web public? Tout Internet? Tout Internet, sans Chine / Russie (/ certains / autres / pays)? Les systèmes automatisés peuvent détecter de nombreux types d'attaques, mais tout comme les antivirus, ils ne peuvent aller plus loin.

3) La surveillance des fichiers locaux est une bonne chose, mais, encore une fois, ce n'est pas une panacée. Que faire si l'attaquant parvient à injecter du code dans le serveur Web, puis utilise un bogue du noyau pour obtenir du code dans le noyau ... sans jamais écrire de fichier sur le disque? À ce stade, ils pourraient écrire des fichiers sur le disque et utiliser un kit racine pour empêcher la plupart des analyses en ligne (théoriquement toutes ) de détecter des modifications du système.

Et même s'ils ne parviennent qu'à exploiter le serveur Web, ils peuvent faire tout ce que le serveur Web peut faire (ce qui pourrait être tout ce qui intéressait l'attaquant de toute façon).

4) Vous devriez toujours valider l'entrée de l'utilisateur. La plupart des développeurs le savent (et beaucoup essaient de le faire). Malheureusement, c'est beaucoup plus facile à dire qu'à faire, c'est pourquoi nous continuons à voir des problèmes après des problèmes où l'entrée de l'utilisateur n'est pas correctement validée. Vous ne pourrez jamais garantir qu’un logiciel réel valide correctement toutes les entrées utilisateur. Lisez quelques questions PHP + MySQL sur StackOverflow pour voir combien de personnes pensent que mysqli_real_escape_string () empêche toutes les attaques par injection SQL ( "where ID =". $ Val est vulnérable, même lorsque $ val est la sortie de mysqli_real_escape_string !).

Même si vous pouviez (vous ne pouvez pas) vous assurer que tous les vecteurs d'attaque connus étaient protégés, vous ne pouvez rien faire de plus que de vous balancer sauvagement dans l'obscurité contre et inconnu-inconnu (eh bien, vous instruire continuellement aide). / p>

À titre d'exemple où vos défenses n'auraient rien fait, je participais à un cours de sécurité où nous faisons des "jeux de guerre". J'ai pu rooter le serveur d'une équipe adverse en étant capable d'obtenir l'un de leurs mots de passe utilisateur sur une autre machine (l'un d'eux a foiré et l'a tapé dans bash comme une commande par erreur, et ils n'ont jamais pensé pour le supprimer de .bash_history ).

À partir de là, j'ai usurpé l'adresse IP de la machine à partir de laquelle ils se sont généralement connectés et me suis connecté en SSH, en saisissant leur nom d'utilisateur + mot de passe. J'avais un accès limité au système. J'ai ensuite exécuté sudo vim , entré à nouveau le même mot de passe et ai fait créer un shell bash à vim. Tada! Accès root, à partir d'une source crédible, sans modifier aucun fichier local de manière inhabituelle, sans exploiter un mot de passe faible (c'était mauvais, mais même le meilleur mot de passe au monde n'aurait pas aidé), ni en s'appuyant sur une entrée utilisateur non validée.

À ce stade, étant malicieux pour moi, j'ai modifié manuellement tous les fichiers journaux liés à ma connexion légitime, et effacé leur IDS (je parie qu'ils ne seront pas assez attentifs pour remarquer que j'ai remplacé tous les ses binaires avec des copies de / bin / true !). Un `` vrai '' hacker serait probablement bien mieux équipé pour s'assurer que son activité ne soit pas détectée par des administrateurs plus vigilants, mais j'avais déjà atteint mon objectif, et une petite partie de moi voulait qu'ils découvrent que quelqu'un l'a compris.

Si je peux déformer la loi de Schneier:

N'importe qui, de l'amateur le plus ignorant au meilleur administrateur système, peut créer un système de sécurité qu'il ne peut pas craquer lui-même.

En bref, défendre correctement n'est pas une tâche facile parce que ...

Prendre un coup rapide à vos entrées ->

Rendre le mot de passe du compte administrateur long ...

Le simple fait de surfer à l'épaule vainc toutes les tentatives de mots de passe forts. Injections SQL, ou mécanismes de hachage non sécurisés ou, pire, stockage de mots de passe en texte brut), vous restez vulnérable.

Surveillez chaque trafic réseau entrant

Vous serez surveiller énormément de trafic. Quelle est la garantie que vous ne manquerez pas de choses importantes? Et qu'en est-il des jours zéro?
Qu'en est-il du trafic chiffré? Que ferez-vous surveiller à ce sujet?

... et n'autorisez que les sources crédibles.

Et si vos sources crédibles obtiennent compromis / piraté? Alors ils ne sont plus crédibles mais vous, l'administrateur système, ne le savez pas!

... surveillez les changements de fichiers locaux ... Validez chaque entrée utilisateur. ..

Encore une fois, combien pouvez-vous surveiller et combien de journaux pouvez-vous analyser ...

De plus, en supposant qu'au moins quelques services fonctionnent sur le machine, les vulnérabilités du service peuvent devenir la cause de la compromission de votre machine.

J'espère pouvoir vous donner une idée de la faisabilité du piratage est possible :)

Ack: Image tirée de www.quotesparade.com

Si vous pouviez vous défendre «correctement», les pirates ne pourraient jamais entrer. Le problème est de savoir ce que signifie correctement dans ce genre de situation.

Vous pouvez éteindre le serveur et le sceller dans du béton à un demi-mile sous la terre et il est assez sécurisé, non? Mais c'est inutilisable. Et si la valeur de ce qu'il contient est suffisamment élevée, un attaquant peut essayer de la déterrer. Vous pouvez donc déjà voir sur cet exemple extrême que la sécurité est un équilibre. Il doit être approprié - et toujours autoriser l'utilisation du serveur.

Cela étant, les problèmes que vous rencontrerez incluent:

• comment vous assurez-vous que tous les exécutables sont sécurisés? Encore une fois, vous ne pouvez pas. Vous pouvez décider de l'effort que vous souhaitez consacrer à leur vérification et exécuter divers tests, mais les bases de code sont suffisamment grandes pour que la plupart des applications puissent contenir des erreurs accidentelles.
• L'option de sécurité proposée rend-elle le serveur inutilisable pour son public cible? Le débrancher du réseau augmentera la sécurité, mais ne plaira pas à vos utilisateurs.
• connaissez-vous réellement toutes les entrées possibles que vos utilisateurs peuvent souhaiter utiliser? Si c'est le cas, brillant - liste-les en blanc. Mais n'oubliez pas de mettre à jour chaque fois que votre application est mise à jour ou présente de nouvelles fonctionnalités. Et vérifiez chaque fois que vous obtenez un nouvel utilisateur. Et vérifiez que la liste blanche fonctionne pour arrêter toutes les entrées non approuvées. Et ainsi de suite ...
• les attaques peuvent ne pas avoir besoin de modifier les fichiers sur le disque. Les fichiers de surveillance ne détecteront pas les attaques qui ciblent directement le code en mémoire, par exemple.
• l'ajout de contrôles de sécurité techniques ne prend pas en compte les attaques sociales ou physiques. Si un attaquant veut vraiment accéder à un serveur bien protégé, il peut juger utile de vous déranger, d'enregistrer vos frappes au clavier pour obtenir des mots de passe, etc. Ou il peut être plus facile de bogue un utilisateur - peut-être qu'il est moins conscient de la sécurité.
• etc etc

En termes simples, vous pouvez sécuriser à un niveau, en fonction de votre budget. Décidez combien vous êtes prêt à dépenser en fonction de ce que vous voulez protéger. Acceptez qu'il y ait un risque résiduel.

Et puis planifiez quelque chose qui ne va pas - à un moment donné, votre sécurité sera brisée et vous devez savoir comment réagir. Pour un simple serveur de fichiers, ce processus peut simplement être effacé et réinstallé à partir d'une sauvegarde, mais pour quelque chose de plus complexe, vous devrez peut-être informer les utilisateurs, les parties prenantes, les régulateurs, etc., stocker des preuves, faire des copies médico-légales, reconstruire, reconfigurer ou, sous une forme quelconque, corriger l'incident ... et puis en tirer les expériences d'apprentissage pour réévaluer votre plan de sécurité.

... et ensuite ... Refaire tout à nouveau. Réévaluez régulièrement votre sécurité et votre appétit de sécurité, car c'est un monde en évolution rapide!

Disons que vous avez un serveur Web, qui prend une commande:

GET /helloworld.txt

Et qui renvoie, très simplement, "Hello, World!"

C'est la chose la plus simple au monde à coder, non? En supposant que vous preniez l'entrée, vérifiez la chaîne "GET /helloworld.txt", et faites la bonne chose, puis ignorez toute autre chose, quelles sont les possibilités de piratage? Aucun?

OK. Quelle est la taille de votre tampon de commandes? 20 octets? Juste assez longtemps pour accepter cette commande? Et si quelqu'un donne une commande de deux octets de plus? Et s'ils donnent une commande de 2000 octets de plus? Comment recevez-vous réellement la commande? Qu'est-ce qui parle à la carte réseau? Qu'est-ce que le décodage des paquets? Et si les caractères étaient envoyés en deux paquets, sans terminaison NUL entre les octets?

En bref, même ce "plus simple" des programmes réseau, qui n'a même pas besoin d'un accès par mot de passe, pourrait avoir BEAUCOUP de sécurité défauts.

Simplement, c'est une question de complexité. Chaque fois qu'une variable est introduite, le nombre de vecteurs d'attaque POSSIBLES augmente de façon exponentielle. Tous ne seront pas des vecteurs d'attaque, mais ils POURRAIENT l'être, et vous devez donc les couvrir tous, si vous voulez être en sécurité.

C'est pratiquement impossible, sans une unité entièrement vérifiée et entièrement testée, système conçu par contrat, et peut-être même mathématiquement prouvé. Autant que je sache, un tel système n'existe pas. OpenBSD pourrait se rapprocher, mais je doute que ce soit tout le chemin.

La réponse très courte est: avec la sécurité, supposons toujours le pire. Il est BEAUCOUP plus intelligent de savoir que vous êtes vulnérable et d'agir de manière humble et appropriée, en risquant le moins possible, que de supposer que vous êtes en sécurité simplement parce que vous ne pouvez pas penser à un vecteur d'attaque possible.

Si vous faites tout et que vous le faites correctement, vous pouvez empêcher de nombreuses attaques différentes. Malheureusement, le piratage ne se limite pas à attaquer directement la connexion / l'accès.

Une grande partie comprend le contournement de votre protection, donc un attaquant n'a pas besoin de connaître le mot de passe. L'ingénierie sociale est une autre grande partie. Les mots de passe ne protègent rien s'ils sont connus des attaquants. De plus, il y a plus d'attaques et de cibles dommageables que le simple accès au panneau d'administration. Si quelqu'un ne veut pas que vous gériez une boutique en ligne, parce qu'il a le sien et veut garder ses clients (et vous hors des affaires), comment voulez-vous empêcher une attaque DDoS, ou simplement quelqu'un qui débranche votre serveur chambre? (La femme de ménage, qui voulait juste dépoussiérer la carte mère?;))

De plus, la surveillance n'aide pas vraiment à prévenir les attaques.

Il y a différents types de systèmes de protection, d'intervention anti-effraction, de résistance à l'altération et d'inviolabilité. Les systèmes anti-falsification veulent ralentir les attaques (par exemple, les mots de passe longs). La réponse anti-sabotage vous indique si une attaque est en cours (par exemple, une alarme qui se déclenche est que votre IDS détecte certaines chaînes d'injection SQL), et le système de détection de sabotage vous montre comment les attaques se sont produites (par exemple, les fichiers journaux)

Les pirates tentent de casser ou d'éviter ces protections, et c'est votre travail d'avoir une longueur d'avance. Bien sûr, cela est très difficile, car vous pouvez à peine connaître les failles de sécurité de votre logiciel serveur, qui peuvent permettre à un attaquant d'accéder aux informations root sans mot de passe. Habituellement, les attaquants trouvent ce type de faiblesses en premier, et c'est votre travail de prendre soin de votre système et de ralentir leurs attaques jusqu'à ce que le problème soit résolu.

Rendre le mot de passe du compte administrateur suffisamment long et assez compliqué (c'est-à-dire en théorie, le mot de passe ne peut pas être craqué dans un délai raisonnable).

Cracké par la force brute? Non. Craqué par l'ingénierie sociale? Oui. Si de nombreuses personnes connaissent le mot de passe, il n'est pas trop difficile de l'obtenir via l'ingénierie sociale. (chaque fois que plusieurs personnes connaissent le mot de passe, il est possible d'utiliser efficacement l'usurpation d'identité pour obtenir le mot de passe). Si seulement vous avez accès, l'accès physique peut toujours être obtenu via l'ingénierie sociale. Cependant, il est plus difficile de gérer cela et vous devez vous demander si cela en vaut vraiment la peine.

Surveillez chaque trafic réseau entrant vers les fichiers administratifs.

Cela ne vous protège pas des attaques DDoS. Et si vous souhaitez vous protéger contre les attaques DDoS, il y aura trop de faux positifs d'utilisateurs bloqués injustement.

Même si votre mot de passe est long, un botnet peut s'introduire. Si vous avez une sorte de restriction sur le nombre de fois où vous pouvez échouer une tentative de mot de passe, ils peuvent alors vous verrouiller vous .

De plus, les CAPTCHA ne sont plus aussi sécurisés, il existe de nombreuses entités qui paient de l'argent les gens doivent rester assis toute la journée et résoudre les captchas.

Pour étendre la couche de protection à partir du n ° 2 ci-dessus, surveillez les modifications des fichiers locaux (en particulier ceux qui ont des commandes qui nécessitent des privilèges sudo.

Vous ne pouvez pas surveiller complètement toutes les modifications apportées aux fichiers. Il y a tout simplement trop d'informations. La plupart des programmes manipulent beaucoup de fichiers lorsqu'ils s'exécutent. Comment différencieriez-vous une mise à jour de programme d'un fichier malveillant?

Validez chaque entrée utilisateur, de sorte que toutes les entrées utilisateur soient sûres.

Assurez-vous de faire ce côté serveur.

Enfin , les exploits zero day seront toujours un problème. Si quelqu'un trouve une faille de sécurité dans le cadre que vous utilisez, vous êtes coulé. Pour éviter cela, utilisez des frameworks largement utilisés et espérez le meilleur.

Se protéger contre le piratage, c'est comme essayer de protéger un bunker sous-marin rempli de sodium. Selon vous, il y a de nombreux endroits qui doivent être réparés. Vous pouvez tous les réparer. Mais cela ne signifie pas que vous êtes en sécurité - il suffit d'une petite fuite dans un endroit que vous n'avez pas inspecté pour que tout s'écroule.

"défendre correctement" signifie: "mon code n'a pas de bogues; aucun des outils que j'utilise non plus". Mais le logiciel a des bogues; le matériel a des bogues; personne ne sait comment garantir l'inexistence de bogues dans un logiciel ou un matériel non trivial (ceux qui prétendent le contraire sont délirants ou menteurs, ou les deux). Voir cette question précédente pour une discussion.

La manière pratique dont les attaques se produisent est lorsqu'un attaquant découvre ou apprend un bogue qui peut être exploité à son avantage, et avant le propriétaire du système en prend connaissance et le corrige.

De votre liste:

• Un mot de passe d'administrateur gros, gros, aléatoire et impossible à deviner convient - tant que la machine sur lequel l'administrateur tape son mot de passe n'est pas infecté par certains logiciels malveillants de keylogger.

• La surveillance aide principalement à l'analyse post mortem; cela n'empêche pas l'attaque, mais il vous aide à déterminer ce qui s'est passé, quel bogue a été exploité, afin qu'il puisse être corrigé ... pour la prochaine fois.

• Là n'est pas une "entrée utilisateur sûre garantie". Il y a "une entrée utilisateur dont la conformité à un ensemble spécifique de règles a été vérifiée, ce qui devrait signifier que ladite entrée utilisateur peut être utilisée dans une construction donnée sans rencontrer de situations gênantes". Par exemple, un morceau de texte peut être "sûr pour l'inclusion dans un fichier HTML" (il ne contient pas certains caractères spéciaux HTML qui déclenchent un traitement avancé, tels que '<' et '&'), mais pas du tout sûr pour inclusion dans une requête SQL (les caractères HTML-safe pourraient encoder une requête SQL totalement non sûre).

Juste pour ajouter quelques points:

Rendez le mot de passe du compte administrateur suffisamment long et compliqué (c'est-à-dire en théorie, le mot de passe ne peut pas être craqué dans un délai raisonnable).

Les mots de passe longs et compliqués, même s'ils sont bons, augmentent la probabilité qu'ils soient écrits. Idem avec les mots de passe qui doivent être changés souvent. Surtout si plus d'une personne a besoin du mot de passe, ou si c'est un mot de passe qui n'est pas souvent utilisé.

Surveillez tout le trafic réseau entrant vers les fichiers administratifs.

Les attaques d'escalade de privilèges rendront cela inutile, car les changements sembleront alors provenir du trafic local et non du réseau. Et trop de surveillance ouvrira de nouveaux problèmes. Buffer overflow Les exploits sont courants. Heck, certains routeurs grand public continuent de s'étouffer lorsque les tentatives de trafic bloquées obstruent leurs tables de connexion.

Pour étendre la couche de protection à partir du n ° 2 ci-dessus, surveillez les modifications des fichiers locaux (en particulier ceux qui ont des commandes qui nécessitent sudo).

Mieux, mais les attaques par élévation de privilèges pourraient permettre à quelqu'un de télécharger un binaire et d'y ajouter des bits persistants suid / sgid. Il ne sera pas sur votre liste de fichiers à vérifier.

Validez toutes les entrées de l'utilisateur, de sorte que toutes les entrées de l'utilisateur soient garanties en toute sécurité.

Quels efforts allez-vous consacrer à cela? La désinfection des entrées utilisateur n'est jamais efficace à 100%.

En gros, certaines choses que vous faites causeront plus de problèmes que de ne pas les faire, il y a toujours des moyens de contourner cela, essayez simplement de faire de votre mieux et j'espère que vous ne faites pas une erreur stupide. Soyez comme un désinfectant. Vous ne pouvez tuer que 99% du problème.

"Il est possible de ne commettre aucune erreur tout en perdant. Ce n'est pas une faiblesse, c'est la vie." - Picard

Vous n'avez pas défini ce que cela signifie pour votre serveur d'être piraté.

La première étape est de définir quelle est la portée de l'accès légitime au système. Qui sont les utilisateurs et que fournit le système aux utilisateurs qui doit être protégé?

Si le système est dédié à une fonction très spécifique et limitée (comme servir une application distribuée particulière), et les attaquants peuvent accéder uniquement à ce système via le réseau, alors à peu près juste cette application doit être sécurisée, ainsi que les parties du système exposées au réseau: l'adaptateur LAN, son pilote et la pile réseau.

Le vrai défi en sécurité dans un système d'exploitation comme Linux est de savoir comment rendre le système d'exploitation non piratable dans une situation multi-utilisateurs lorsque les gens utilisent presque pleinement le système, ils peuvent se connecter aux comptes du système d'exploitation et exécuter des applications directement.

A le système peut avoir des incidents de sécurité sans que le compte du superutilisateur ne soit compromis. Supposons que vous ayez un système Linux parfaitement incassable. Pourtant, l'utilisateur joe installe une application non sécurisée / home / joe / bin . Cette application ouvre un document malveillant, qui exploite une faille dans l'application, au moyen de laquelle un code malveillant obtient l'exécution de code arbitraire dans le contexte de sécurité de joe . Le code malveillant endommage les données de joe et vole également le temps CPU de la machine. (Essayez comme il pourrait, cependant, il ne peut pas obtenir les privilèges d'exécution de super-utilisateur, car la machine est "non piratable").

Est-ce piraté? Ou pas piraté? Que diriez-vous du point de vue de l'utilisateur joe . joe se soucie-t-il que root n’ait jamais été compromis lors de l’incident?

Si les gens (ou du moins vos administrateurs) n'ont jamais commis d'erreurs et que les programmes informatiques étaient tous 100% sans bogue tout le temps, alors en théorie vous avez raison. Malheureusement, ni l'un ni l'autre n'est jamais vrai et il est assez facile pour un attaquant d'attaquer à ces points.

Même parfaitement configuré, le logiciel est incapable d'agir comme il est configuré tout le temps à cause de bugs. Dans les bonnes conditions, il peut être possible de faire faire au logiciel quelque chose qu'il ne devrait pas faire.

De même, l'ingénierie sociale est probablement la forme la plus courante de piratage. Il n'est pas nécessaire de prendre des mesures techniques complexes lorsque vous pouvez simplement inciter votre adversaire à vous donner ce que vous voulez. Surfer sur le mot de passe, obtenir un enregistreur de frappe sur un ordinateur que l'administrateur utilise ou tromper un administrateur pour exécuter votre logiciel malveillant sont tous des moyens possibles de se faufiler sous le radar.

Vous pouvez compenser de nombreuses ceci en verrouillant un serveur dans une pièce sans connexion Internet et en permettant uniquement aux administrateurs d'utiliser le système dans la pièce avec un gardien à la porte, et en fait, c'est le nombre de réseaux gouvernementaux de haute sécurité qui fonctionnent, mais cela met un énorme barrière à la convivialité.

En fin de compte, la sécurité consiste à équilibrer la convivialité et les risques. Les étapes que vous décrivez nécessitent une trop grande réduction de la convivialité pour être mises en œuvre en toute sécurité et ne peuvent donc pas fonctionner seules dans une situation réelle. La sécurité est un domaine complexe et en constante évolution qui nécessite de rester à jour sur les menaces, de vérifier vos défenses contre les nouvelles menaces et d'être sûr de surveiller les compromis qui peuvent passer comme des problèmes de 0 jour.

J'essaye de construire des systèmes pare-balles depuis près de dix ans maintenant. J'ai dû apprendre les techniques de conception à haute assurance (par exemple EAL7), les canaux cachés, les attaques de subversion, etc. Honnêtement, la plupart des concepteurs ou administrateurs de systèmes n'ont ni les connaissances ni les ressources pour sécuriser totalement une machine contre les attaques connues. C'est presque impossible compte tenu des contraintes commerciales. La plupart des décisions de sécurité reflètent des compromis entre le coût, les fonctionnalités, la convivialité, la compatibilité héritée, les profils d'attaquants probables, etc.

Si vous voulez savoir, voici une de mes ventilations simplifiées sur les différents niveaux et problèmes de sécurité. (Et ce n'est pas la taille d'un livre 8). Il était adressé à un gars qui pensait que les codeurs de premier ordre pouvaient créer des programmes sécurisés, mais vous pouvez sous-administrer le codeur et toujours les mêmes résultats. Amusez-vous et apprenez les leçons moins vous répétez l'histoire comme le fait une grande partie de la communauté INFOSEC. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

Ce suivi up comment contient de nombreux liens qui retracent l'histoire, les facteurs gouvernementaux, les exigences de développement, etc. Je liste également une tonne de systèmes et de processus exemplaires. Chacun peut avoir des défauts cachés mais inspirer plus de confiance qu'un produit moyen.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

Un système est aussi fort que le lien le plus faible

C'est une phrase souvent répétée et vous devez vous rappeler que peu importe la force d'un mot de passe, c'est un seul point d'échec et un bruteforcer sera capable de percer à un moment donné.

De plus, que se passerait-il si votre administrateur système décidait d'accepter une récompense plutôt intéressante pour supprimer accidentellement une charge de fichiers?

Les Allemands pensaient que l'énigme était incassable et il a été avancé que leur dépendance et leur confiance dans cette méthode unique de cryptage leur coûtaient la guerre - la dépendance à un seul système ou ressource (humaine ou autre) est le pire. crime possible contre la sécurité.

Il y a quelques aspects humains qui ne sont généralement pas présentés lorsque quelque chose comme ça est demandé.

1. Certaines personnes n'ont littéralement rien de mieux à faire et essaieront de pirater votre système par simple ennui .
2. Certaines personnes le font pour le plaisir (comme quelques chapeaux blancs). Les chapeaux blancs ne sont généralement pas mauvais parce que beaucoup d'entre eux vous contacteront et vous diront "mec, je suis entré dans votre système" et ne font rien de malveillant.
3. Certaines personnes essaieront d'obtenir les mots de passe de vos utilisateurs afin de les essayer sur d'autres sites Web, comme les cartes de crédit. Ils posent pour gagner un énorme profit en faisant cela
4. Certaines personnes attaqueront un serveur pour se venger. "Jane Berman a dit que je suis une tête de merde? SON SERVEUR VA TOMBER!"

Les gens, en particulier entre 2 et 4, ont tendance à être incroyablement passionnés par l'idée d'entrer dans votre système. Parfois, le n ° 1 se transforme en 2-4. Les entreprises doivent payer quelqu'un pour sécuriser un serveur, et il faut beaucoup d'argent, de recherche et d'heures de travail pour empêcher une armée de ce genre de personnes de l'attaquer

Peut-être parce que la plupart des systèmes et logiciels ne sont pas sensibles à la sécurité en premier lieu. La sécurité est fastidieuse à enseigner, à comprendre et aussi à être mise à jour (actualités, nouveaux vecteurs d'attaque, etc.).

C'est pourquoi elle n'est pas entièrement et largement enseignée. Par exemple, il n'y a pas de norme de sécurité comme il y a des normes ISO. Aussi parce que c'est un marché potentiel pour la sécurité domestique (antivirus).

Lorsque les ordinateurs seront plus courants, peut-être qu'un jour cela deviendra quelque chose dont on s'occupera. Un avenir où il y a quelque chose comme 100 ordinateurs ou plus par être humain.

Si vous y réfléchissez vraiment, nous ne dépendons pas vraiment des ordinateurs suffisamment pour nous soucier de la sécurité Internet (du moins je pense, ou au moins les parties où il est essentiel d'être bien entretenu).