Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Sécurité Sécurité....................................................................................................................................................... 1 Pourquoi la sécurité? ............................................................................................................................. 8 Les types de sécurité ............................................................................................................................. 9 La sécurité physique .......................................................................................................................... 9 Une machine Unix ......................................................................................................................... 9 Le disque dur ............................................................................................................................... 10 Le bouton reset ............................................................................................................................ 10 La sécurité réseau ................................................................................................................................ 10 Définir une politique ......................................................................................................................... 10 Security Services ......................................................................................................................... 11 Attaques ............................................................................................................................................... 13 Techniques Adopted By 'System Crackers' When Attempting To Break Into Corporate Networks. ......................................................................................................................................................... 13 1.0 Introduction ........................................................................................................................... 13 Undernet/ Computer Underground .................................................................................................. 23 Introduction .................................................................................................................................. 23 What is the Computer Underground? .......................................................................................... 25 Topography of the Computer Underground ................................................................................ 28 Social Organization and Deviant Associations ............................................................................ 30 Mutual Association ...................................................................................................................... 31 The Structure of the Computer Underground .............................................................................. 32 Summary ..................................................................................................................................... 39 Type d’attaques ............................................................................................................................... 45 Trojan........................................................................................................................................... 45 Backdoor...................................................................................................................................... 45 Worms ......................................................................................................................................... 45 Password cracking ...................................................................................................................... 46 Social engineering ....................................................................................................................... 46 SPAM........................................................................................................................................... 47 What's Spam and What's the Problem? ...................................................................................... 47 Le dépassement de capacité d'un TAMPON .............................................................................. 59 Le délestage d'un fichier «core» .................................................................................................. 59 Les transmissions de messages ................................................................................................. 60 Denial of Services ........................................................................................................................ 60 Finger........................................................................................................................................... 61 SynFlood...................................................................................................................................... 62 Sniffer .......................................................................................................................................... 64 FTP .............................................................................................................................................. 64 NFS.............................................................................................................................................. 65 IP-Spoofing .................................................................................................................................. 65 DNS-Spoofing .............................................................................................................................. 65 Web ............................................................................................................................................. 66 Ddos ............................................................................................................................................ 66 Scanner ....................................................................................................................................... 75 ActiveX Java......................................................................................................................................... 76 Antivirus ................................................................................................................................................ 77 Les différents types de virus ........................................................................................................ 79 Audit ..................................................................................................................................................... 86 Authentification ..................................................................................................................................... 87 Les passwords ................................................................................................................................. 89 L'équivalence ................................................................................................................................... 89 Kerberos .......................................................................................................................................... 90 Crypto Card ...................................................................................................................................... 90 Autres authentifications.................................................................................................................... 91 Autorités de certification ....................................................................................................................... 92 Les certificats numériques ............................................................................................................... 92 Backup ................................................................................................................................................. 94 Biométrie .............................................................................................................................................. 95 Cisco .................................................................................................................................................... 96 Contrôle d’intégrité ............................................................................................................................... 99 TripwireCryptographie .......................................................................................................................... 99 Cryptographie ..................................................................................................................................... 100 Cryptographie à clé unique ............................................................................................................ 100 RSA ................................................................................................................................................ 100 Garantir l'origine d'un message ................................................................................................. 101 RSA en pratique............................................................................................................................. 101 PGP ........................................................................................................................................... 101 SSH Secure Shell ...................................................................................................................... 102 SSH security tunnels ................................................................................................................. 102 SSL Secure Socket Layer ......................................................................................................... 102 SET Secure Electronic Transaction .......................................................................................... 104 Chiffrement .................................................................................................................................... 104 Hachage ......................................................................................................................................... 104 Sortir de l'ombre ............................................................................................................................. 105 Chevaux de bataille symétriques ................................................................................................... 106 La clé est la clé .............................................................................................................................. 107 Attention aux intermédiaires .......................................................................................................... 108 Déchiffrer le futur ........................................................................................................................... 109 Bibliographie .................................................................................................................................. 109 Hyperliens : .................................................................................................................................... 110 Détection d’intrusion ........................................................................................................................... 111 1. Qu’est-ce qu’une intrusion ? ...................................................................................................... 111 2. Les différents types d’intrusions ................................................................................................ 112 3. Autre classement des intrusions ................................................................................................ 112 Utilisation frauduleuse (misuse) ................................................................................................ 112 Utilisation anormale (anomaly) .................................................................................................. 113 4. Les différents types de problèmes de sécurité .......................................................................... 113 Problèmes liés aux programmes ............................................................................................... 113 5. Les mots de passe ..................................................................................................................... 116 Crackage de mot de passe........................................................................................................ 117 6. Les sniffers................................................................................................................................. 118 7. Les modems dans un réseau .................................................................................................... 119 Systèmes de détection d’intrusion ................................................................................................. 119 Les différents types de systèmes de détection d’intrusion ............................................................ 120 Système basé sur un host (host based intrusion detection system) ......................................... 121 Système basé sur le trafic réseau (network based intrusion detection system ou NIDS) ........ 121 Système hybride ........................................................................................................................ 121 Système de leurre (deception system) ...................................................................................... 121 Différenciation des systèmes de détection d’intrusion en fonction du facteur temps .................... 122 A intervalles réguliers ................................................................................................................ 122 En temps réel ............................................................................................................................ 122 Différenciation des systèmes de détection d’intrusion en fonction du type d’intrusion ................. 123 Détection d’utilisation frauduleuse (misuse detection) .............................................................. 123 Détection d’utilisation anormale (anomaly detection) ................................................................ 123 Principe de fonctionnement d’un NIDS .......................................................................................... 124 Attaques pouvant affecter un NIDS ............................................................................................... 124 Insertion ..................................................................................................................................... 124 Evasion ...................................................................................................................................... 125 Les attaques par évasion et par insertion en pratique .............................................................. 126 Placement d’un NIDS..................................................................................................................... 128 Réponse d’un NIDS à une attaque ................................................................................................ 128 Réponse active .......................................................................................................................... 128 Réponse passive ....................................................................................................................... 130 Efforts de normalisation ................................................................................................................. 130 Normalisation de nomenclature des vulnérabilités ........................................................................ 131 CVE ........................................................................................................................................... 131 Format des messages envoyés par les outils de détection d’intrusion ......................................... 134 Protocole de communication des systèmes de détection d’intrusion ............................................ 137 Vulnérabilités et failles ................................................................................................................... 138 1. Les Buffer Overflow ............................................................................................................... 138 2. Les scanners de vulnérabilités .............................................................................................. 140 3. Les attaques par déni de service (Denial Of Service ou DOS) ............................................. 142 5. Les attaques distribuées par déni de service (Distributed Denial Of Service ou DDOS) ..... 150 6. Les virus du type « I love you » ............................................................................................. 153 7. Les root kits ........................................................................................................................... 155 An Introduction to Intrusion Detection ............................................................................................ 159 Introduction ................................................................................................................................ 159 The need for Intrusion Detection Systems ................................................................................ 159 Classification of Intrusion Detection Systems ........................................................................... 160 Anomaly Detection Systems...................................................................................................... 161 Misuse Detection Systems ........................................................................................................ 162 6 Other Models and Directions in Research .............................................................................. 165 Conclusion ................................................................................................................................. 166 FAQ: Network Intrusion Detection Systems .................................................................................. 167 0. Information about this FAQ ........................................................................................................ 167 0.1 Copyright ............................................................................................................................. 167 0.6 Where to get it ..................................................................................................................... 167 0.7 Thanks to ............................................................................................................................. 167 1. Introduction ................................................................................................................................ 167 1.1 What is a "network intrusion detection system (NIDS)"? .................................................... 167 1.2 Who is misusing the system? .............................................................................................. 168 1.3 How do intruders get into systems? .................................................................................... 168 1.4 Why can intruders get into systems? .................................................................................. 169 1.5 How do intruders get passwords? ....................................................................................... 171 1.6 What is a typical intrusion scenario? ................................................................................... 171 1.7 What are some common "intrusion signatures"? ................................................................ 172 1.8 What are some common exploits? ...................................................................................... 173 1.9 What are some common reconnaisance scans? ................................................................ 175 1.10 What are some common DoS (Denial of Service) attacks? .............................................. 175 1.11 How much danger from intrusions is there? ...................................................................... 176 1.12 Where can I find current statistics about intrusions? ......................................................... 176 2. Architecture ................................................................................................................................ 177 2.1 How are intrusions detected? .............................................................................................. 177 2.2 How does a NIDS match signatures with incoming traffic?................................................. 177 2.4 What happens after a NIDS detects an attack? .................................................................. 177 2.5 What other countermeasures besides IDS are there? ........................................................ 178 2.6 Where do I put IDS systems on my network? ..................................................................... 178 2.7 How does IDS fit with the rest of my security framework? .................................................. 179 2.8 How can I detect if someone is running a NIDS? ................................................................ 179 3. Policy ......................................................................................................................................... 179 3.1 How do I increase intrusion detection/prevention under WinNT? ....................................... 179 3.2 How do I increase intrusion detection/prevention under Win95/Win98? ............................. 181 3.3 How do I increase intrusion detection/prevention under UNIX?.......................................... 181 3.4 How do I increase intrusion detection/prevention under Macintosh? .................................. 182 3.5 How do I increase intrusion detection/prevention for the enterprise? ................................. 182 3.6 How should I implement intrusion detection my enterprise? ............................................... 182 3.7 What should I do when I've been hacked? .......................................................................... 182 3.8 How should I respond when somebody tells me they've been hacked from my site? ........ 183 3.9 How do I collect enough evidence about the hacker? ......................................................... 184 4. Products ..................................................................................................................................... 185 4.1 What freeware/shareware intrusion detection systems are available? ............................... 185 4.2 What commercial intrusion detection systems are available?............................................. 185 4.3 What is a "network grep" system? ....................................................................................... 187 4.4 What tools do intruders use to break into my systems? ...................................................... 189 4.5 What other free/shareware intrusion detection products should I be aware of? ................. 190 4.6 Are there NIDS available for my host? ................................................................................ 190 6. Resources .................................................................................................................................. 191 6.1 Where can I find updates about new security holes? .......................................................... 191 6.2 What are some other security and intrusion detection resources? ..................................... 191 6.3 What are some sites that are interesting? ........................................................................... 192 7. IDS and Firewalls ....................................................................................................................... 192 7.2 Why do I need IDS if I already have a firewall? .................................................................. 192 7.2.1 How is it that hackers can get through firewalls? ............................................................. 193 7.3 If I have a intrusion detection, do I need firewall? ............................................................... 193 7.4 Where does the intrusion detection system gets its information? The firewall? ................. 194 8. Implementation Guide ................................................................................................................ 194 8.1 What questions should I ask my IDS vendor? .................................................................... 194 8.2 How do I maintain the system on an on-going basis?......................................................... 195 8.4 How do I stop innapropriate web surfing? ........................................................................... 196 8.5 How can I build my own IDS (writing code)? ....................................................................... 196 8.7 What is the legality of NIDS (since it is a form of wiretap)? ................................................ 196 8.8 How do I save logfiles in a tamper-proof way? ................................................................... 196 9 What are the limitations of NIDS? ............................................................................................... 197 9.1 Switched network (inherent limitation) ................................................................................. 198 9.2 Resource limitations ............................................................................................................ 199 9.3 Attacks against the NIDS .................................................................................................... 199 9.4 Simple evasion .................................................................................................................... 200 9.5 Complex evasion ................................................................................................................. 201 9.9 Tools .................................................................................................................................... 202 10. Misc. ......................................................................................................................................... 203 10.1 What are some standardization/interoperability efforts? ................................................... 203 Travaux Pratiques .......................................................................................................................... 204 CIDF ............................................................................................................................................... 207 Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection ...................... 207 1 Introduction ............................................................................................................................. 207 2 Problems with Network ID Systems ....................................................................................... 212 3 Attacks .................................................................................................................................... 213 4 Network¡Layer Problems ........................................................................................................ 217 5 TCP Transport¡Layer Problems ............................................................................................. 223 6 Denial of Service Attacks........................................................................................................ 233 7 Methodology ........................................................................................................................... 237 8 Results .................................................................................................................................... 243 8.2 Overviews of Specific ID Systems ....................................................................................... 244 9 Discussion .............................................................................................................................. 247 Intrusion Detection Resources ....................................................................................................... 252 Introduction ................................................................................................................................ 252 Intrusion Detection Systems ...................................................................................................... 252 Commercial Products..................................................................................................................... 252 Other Lists of Intrusion Detection Systems.................................................................................... 252 Intrusion Detection Bibliographies...................................................................................................... 253 Mailing Lists ........................................................................................................................................ 253 Other Resources ................................................................................................................................ 253 How to Handle and Identify Network Probes ................................................................................. 254 Abstract...................................................................................................................................... 254 Introduction ................................................................................................................................ 254 Topology Mapping ..................................................................................................................... 260 Remote Operating System Identification ................................................................................... 262 Port Scanning Techniques ........................................................................................................ 263 Finding Targets of Opportunity .................................................................................................. 264 Access Control List Mapping ..................................................................................................... 264 Direct RPC Scanning ................................................................................................................. 265 Watching Your Logs....................................................................................................................... 276 Filtres Internet .................................................................................................................................... 280 Firewall ............................................................................................................................................... 281 Les types de machines .................................................................................................................. 282 Packet Filter ............................................................................................................................... 282 Screening Router ....................................................................................................................... 283 Dual-Homed Host ...................................................................................................................... 283 Les architectures ............................................................................................................................ 284 Bastion Host .............................................................................................................................. 284 Dual-Bastion .............................................................................................................................. 284 Les Firewalls .................................................................................................................................. 286 Firewall de niveau réseau.......................................................................................................... 286 Firewall de niveau application ................................................................................................... 287 Les Firewalls et les systèmes de détection d’intrusion réseau ...................................................... 288 2.1 Inconvénients des firewalls ................................................................................................. 289 2.2 Serveurs proxy .................................................................................................................... 289 3 Configurer tout ça ................................................................................................................... 289 4 Le serveur proxy ..................................................................................................................... 290 5 Configurations avancées ........................................................................................................ 293 Honeypot ............................................................................................................................................ 295 11. Honeypots and Deception Systems......................................................................................... 295 11.1 What is a honeypot? .......................................................................................................... 295 11.2 What are the advantages of a honeypot? ......................................................................... 295 11.3 What are the disadvantages of a honeypot? ..................................................................... 295 11.4 How can I setup my own honepot? ................................................................................... 296 11.5 What are the types of honeypots? ..................................................................................... 296 11.6 What are the pros/cons of setting up a system that can be hacked? ............................... 296 11.7 Are there examples of people using honeypots? .............................................................. 297 11.8 What honeypot products are available? ............................................................................ 297 11.9 What are deception countermeasures? ............................................................................ 297 11.10 What are the legal implication of honeypots? ................................................................. 298 IP-Masquerading ................................................................................................................................ 299 IPsec : présentation technique ........................................................................................................... 300 Introduction .................................................................................................................................... 300 1. Vue d'ensemble ......................................................................................................................... 300 1.1. Architecture d'IPsec ............................................................................................................ 300 1.2. Principe de fonctionnement ................................................................................................ 302 1.3. Types d'utilisations possibles ............................................................................................. 303 2. Les mécanismes de sécurité : AH et ESP ................................................................................. 304 2.1. Rappels sur les services de sécurité et les mécanismes associés .................................... 305 2.2. Authentication Header (AH) ............................................................................................... 306 2.3. Encapsulating Security Payload (ESP) .............................................................................. 308 3. La gestion des clefs ................................................................................................................... 310 3.1. Concepts généraux relatifs à la gestion des clefs .............................................................. 310 3.2. Les protocoles d'authentification mutuelle avec échange de clef développés pour IP ...... 313 3.3. La gestion des clefs pour IPsec : ISAKMP et IKE .............................................................. 317 Onduleurs ........................................................................................................................................... 328 RAID ................................................................................................................................................... 329 SSL ..................................................................................................................................................... 330 Introduction .................................................................................................................................... 330 Processus ...................................................................................................................................... 330 Fonctionnement ............................................................................................................................. 331 Démonstration par l’exemple ......................................................................................................... 331 Certificats ....................................................................................................................................... 332 Certificat pour client ....................................................................................................................... 332 SSL et les logiciels de communications......................................................................................... 333 Sources & divers liens pouvant vous intéresser : .......................................................................... 333 Unix .................................................................................................................................................... 334 Tcpdump ........................................................................................................................................ 334 Ntop................................................................................................................................................ 334 Security Guide ............................................................................................................................... 334 VPN .................................................................................................................................................... 335 NT 4 .................................................................................................................................................... 336 System Security ......................................................................................................................... 336 System Startup And Shutdown ................................................................................................. 337 The Disk And File Systems ....................................................................................................... 339 The User Environment ............................................................................................................... 341 Networking ................................................................................................................................. 343 Event And System Monitoring Tools ......................................................................................... 345 Troubleshooting ......................................................................................................................... 347 Hints And Tips ........................................................................................................................... 349 Projects: Practical Guide To Hints And Tips ............................................................................. 350 Windows NT User Rights .......................................................................................................... 351 Practical Guide to System Security ........................................................................................... 353 Security FAQ ............................................................................................................................. 357 CheckList ................................................................................................................................... 359 Windows 2000 ............................................................................................................................... 362 Role of Active Directory ............................................................................................................. 362 Kerberos Authentication Protocol .............................................................................................. 368 Public Key Infrastructure ........................................................................................................... 375 Smart Cards .............................................................................................................................. 377 Encrypting File System .............................................................................................................. 378 Security Configuration Templates ............................................................................................. 379 SSL ............................................................................................................................................ 379 Secure Networking with IPSec .................................................................................................. 381 Extensible Architecture .............................................................................................................. 383 Interoperability ........................................................................................................................... 384 Auditing ...................................................................................................................................... 384 Summary ................................................................................................................................... 385 Encryption ...................................................................................................................................... 385 Introduction ................................................................................................................................ 385 EFS Encryption Technology ...................................................................................................... 386 Using the Encrypting File System ............................................................................................. 389 EFS Architecture ....................................................................................................................... 397 Export Issues with EFS ............................................................................................................. 406 Summary ................................................................................................................................... 406 Authentication in Windows 2000 .................................................................................................... 407 Benefits of Kerberos Authentication .............................................................................................. 407 Standards for Kerberos Authentication .......................................................................................... 408 Extensions to the Kerberos Protocol ............................................................................................. 409 Overview of the Kerberos Protocol ................................................................................................ 409 Basic Concepts .......................................................................................................................... 409 Subprotocols .............................................................................................................................. 415 Tickets ....................................................................................................................................... 417 Delegation of Authentication...................................................................................................... 420 Kerberos Components in Windows 2000 ...................................................................................... 420 Key Distribution Center .............................................................................................................. 420 Account Database ..................................................................................................................... 421 Kerberos Policy ......................................................................................................................... 422 Delegation of Authentication...................................................................................................... 422 Preauthentication ....................................................................................................................... 423 Kerberos Security Support Provider .......................................................................................... 423 Credentials Cache ..................................................................................................................... 424 DNS Name Resolution .............................................................................................................. 425 IP Transport ............................................................................................................................... 425 Authorization Data ......................................................................................................................... 426 Access Control in Windows 2000 .............................................................................................. 426 How the KDC Prepares Authorization Data .............................................................................. 427 How Services Use Authorization Data ...................................................................................... 427 Why Authorization Data Is Signed ............................................................................................. 428 Interactive Logon ........................................................................................................................... 428 The Logon Process ................................................................................................................... 429 Password Logon ........................................................................................................................ 429 Smart Card Logon ..................................................................................................................... 431 Preauthentication Data .............................................................................................................. 432 Remote Logon ............................................................................................................................... 432 Security Support Provider Interface .......................................................................................... 432 Security Support Provider Negotiation ...................................................................................... 433 Example: Opening a File on a Remote Server .......................................................................... 433 Example: Cross-Domain Authentication .................................................................................... 434 Interoperability ............................................................................................................................... 436 Scenarios ................................................................................................................................... 436 Step-by-Step Guide to Internet Protocol Security (IPSec)............................................................. 438 Introduction .................................................................................................................................... 438 Prerequisites .................................................................................................................................. 439 Preparing for Testing ..................................................................................................................... 440 Using a Built-in IPSec Policy ......................................................................................................... 442 Building A Custom IPSec Policy .................................................................................................... 444 Testing Your Custom IPSec Policy ................................................................................................ 448 Using Certificate Authentication ..................................................................................................... 448 Understanding IKE Negotiation (Advanced Users) ....................................................................... 453 Troubleshooting ............................................................................................................................. 454 Troubleshooting Policy Configuration ................................................................................................ 454 For More Information ..................................................................................................................... 457 IPSec Tools and Information .............................................................................................................. 457 Related Links ................................................................................................................................. 457 Annexe A Security checklist ............................................................................................................... 459 Appendice B: Bibliographie ........................................................................................................ 472 Annexe C Glossaire ........................................................................................................................... 475 Pourquoi la sécurité? Aujourd'hui, les entreprises investissent beaucoup d'argent dans la recherche et dans le développement de nouveaux produits. Des budgets incroyables sont utilisés a des fins publicitaires pour rassembler les clients potentiels dans des listes. Ce listes sont d'ailleurs jalousement gardées... Lorsqu'on se donne tant de peine, lorsqu'on dépense tant d'argent, on n'a pas envie que nos concurrents ou nos employés s'en aillent avec notre liste de clients, effacent nos travaux de recherche ou abîment notre matériel. On n'a pas non plus envie que des curieux nous espionnent, lisent notre courrier ou se mêlent de notre vie privée. Qu'ils parlent à tout vent de vos problèmes de santé... Généralement, on ne veut rien de tout cela. On veut juste pouvoir travailler librement, l'esprit tranquille. On veut pouvoir compter sur une certaine fiabilité du système. On veut aussi, dans une autre mesure, pouvoir oublier qu'un système de sécurité est présent: il faut qu'il soit le plus fiable et le plus transparent possible. La transparence est la facilité avec laquelle il se fait oublier par l'utilisateur final. Nous allons voir que nous ne pouvons augmenter l'une de ces deux qualités qu'au détriment de l'autre. C'est généralement trouver un juste milieu entre efficacité et transparence qui pose un problème de choix. Il n'y a pas de solution miracle. Pour des problèmes dont vous n'êtes pas sûrs, il vaut mieux faire appel à une société qui fait de la consultance en sécurité et qui pourra vous aider et vous conseiller. Ce cours n'a bien entendu pas la prétention de vous transformer en un expert en sécurité, il faudrait pour cela une formation plus longue, un syllabus nettement plus conséquent et surtout, des travaux pratiques. Nous nous contenterons simplement de vous initier aux concepts fondamentaux de la sécurité, tout en prenant assez de recul pour que cela puisse s'appliquer à la plupart des topographies de réseau. Les types de sécurité La sécurité physique Pour attaquer un ordinateur, vous pouvez vous y prendre de manière purement physique. En règle générale, les systèmes de sécurité se basent sur le fait que les machines cruciales (par exemple les serveurs de clés), sont physiquement protégés. Il est en effet possible de causer pas mal de problèmes à une machine à laquelle on a physiquement accès. Une machine Unix S'il s'agit d'une machine Unix, il suffit de la faire démarrer dans le mode dit single user. Vous avez alors un accès complet à la machine, sans que l'on vous demande le moindre password. ( NB Cela dépend de l’implémentation Unix envisagée. Les OS actuels offrent la possibilité de demander un password au démarrage, ce qui est évidement, nettement préférable!. ) Ainsi, vous pouvez consulter tous les fichiers que vous voulez, les transférer sur un support, changer les passwords de tous les utilisateurs ou détruire les disques. On peut se protéger de cette attaque en enfermant la machine dans une pièce surveillée, ce qui peut parfois être assez contraignant ou en imposant un password même quand la machine est dans le mode single-user. Presque tous les OS proposent cette option, mais peu l'activent d'origine. Pratiquement, le mode single-user est utilisé pour des tâches de maintenance, comme la vérification des systèmes de fichiers ou les backups. On s'en sert aussi pour récupérer des disques endommagés, ou pour retrouver des passwords égarés. Le disque dur Que votre OS ne vous donne pas accès aux fichiers d'un disque est une chose. Mais ce que votre OS ne peut pas vous empêcher de faire, c'est de démonter la machine pour en extraire le disque, et ensuite l'utiliser sur une autre machine, sur laquelle vous avez accès. Il suffit de savoir se servir d'un tournevis et le tour est joué! C'est pourquoi les serveurs de réseau sont souvent dans des boîtiers verrouillés avec une ou plusieurs clés. Pour s'en protéger, il faut crypter vos systèmes de fichiers. Ainsi, si un tiers entre en sa possession, il ne saura rien en faire puisque, normalement, il ne pourra pas entrer en possession de la clé. La majorité des OS peuvent gérer les systèmes de fichiers cryptes. Si ce n'était pas le cas, il existe aussi des cartes hardware, qui se placent entre le disque et le contrôleur. Dans ce type de système, les clés peuvent soit se trouver sur une disquette, soit être simplement une phrase ou encore être stockée sur une carte à puce. Le bouton reset Bien que le bouton reset, qui se trouve sur la plus grande partie des machines, ne puisse pas vous donner un accès aux fichiers, il peut en tous cas sérieusement endommager les systèmes de fichiers s'il est pressé à un mauvais moment (par exemple, lors de la mise à jour d'une base de données). La sécurité réseau Si la sécurité physique des machines peut être facilement assurée sans nuire à la transparence, il n'en va pas de même avec la sécurité des réseaux d'ordinateurs, qui est l'objet de ce cours. Les attaques en réseau sont perverses et complexes pour plusieurs raisons: Elles font appel à des fonctions pas ou peu documentées, et dont la plupart des administrateurs ignorent l'existence. Tous les jours, on découvre de nouveaux trous de sécurité. Elles peuvent s’exécuter de manière invisible (ou en tous cas, peu visible). Une attaque peut se réaliser sur la machine que vous êtes en train d'utiliser, sans que vous ne vous aperceviez de quoi que ce soit. On peut même espionner votre écran à distance pour voir ce que vous faites. La localisation de l'attaque et donc l'identité du pirate sont très difficiles à déterminer. Une attaque bien menée se réalise donc presque sans risques. Elle se fait à des moments inattendus, comme la nuit, quand personne n'est là pour arrêter ou tenter de localiser le pirate. Le reste du cours sera consacré à cet aspect des choses. Ce domaine très complexe est en constante évolution, et au fur et à mesure que les techniques de défense se développent, les pirates trouvent de nouvelles failles. Vous n'aurez probablement jamais un réseau sécurisé à vie: il faudra vous tenir au courant et faire de fréquentes mises à jour! C'est un travail considérable qu'il ne faut pas négliger. Définir une politique Supposons que vous ayez à construire un réseau d'ordinateurs, et que ce réseau doive avoir un certain niveau de sécurité. Nous allons voir les grandes techniques utilisées en défense, leurs avantages et leurs inconvénients. Un bon réseau utilise plusieurs techniques, intelligemment combinées. Avant toutes choses, il ne faut pas vous lancer tête baissée dans les documentations techniques ou sur les pages Internet relatives à la sécurité. Il faut prendre le temps de développer une politique de défense claire, efficace et bien pensée. Vous devez commencez par choisir votre politique générale, et il en existe deux: Tout ce qui n'est pas explicitement permis est interdit Tout ce qui n'est pas explicitement interdit est permis Une fois ce choix fait, il y a quelques points dont vous devez absolument tenir compte: Quels sont vos besoins en sortie? Il faut savoir si vous avez besoin du WWW, de faire du FTP, de l'IRC. Quelles sont les applications que vous utilisez? Quel(s) port(s) utilisent-elles? Quel(s) protocole(s)? Quels sont vos besoins en entrée? Le mieux serait que l'on ne puisse pas accéder directement aux machines du réseau sécurisé. Vos besoins en entrée seraient alors nuls. Si ce n'est pas le cas, il faut savoir qui peut accéder à quelles machines, avec quel protocole, sur quel port, à quel moment,... Tout doit être précisé clairement. Le risque que vous êtes prêt à prendre? C'est inévitable, il y aura toujours une petite part de risque, de faille, dans votre système. Plus votre système sera efficace, plus il sera lourd et contraignant. Il faut trouver le juste milieu. N'utilisez pas un système d'authentification par cartes à puces pour lire votre courrier personnel! Un password devrait suffire. Il faut aussi savoir que les processus d'authentification énervent les utilisateurs. Un utilisateur énervé étant toujours désagréable, évitez les protections démesurées. Pensez à l'avenir! Prévoyez aussi l'évolution de votre réseau. S'il y a dix postes cette année, et 15 prévus pour l'année prochaine, votre politique ne changera pas. Par contre, si l'année prochaine, ce sont 150 postes qui sont attendus, il faudra penser dès maintenant à une solution souple et extensible! Une fois ce document terminé, vous aurez toujours à tout moment une liste exacte de vos besoins et vous n'oublierez rien quand vous ferez vos choix. Structurez-le et faites des plan, des dessins topographiques et logiques. Security Services Five major security services are identified in International Standard 7498-2. This standard was developed to specify the security aspects of the Open System Interconnect (OSI) model of computer networks. The security services (and a short explanation of each) include: Authentication - Verification of the claimed identity of a computer or computer network user; Access Control - Verification and enforcement of the authorized uses of a computer network by a user subsequent to authentication; Data Integrity - Verification that the contents of a data item (e.g., message, file, program) have not been accidentally or intentionally changed in an unauthorized manner; Data Confidentiality - Protection of the information ontent of data from unauthorized disclosure; Non-repudiation - Protection against denial of sending (or receiving) a data item by the sender (or receiver). These major security services should be augmented by a number of auxiliary services (audit, availability assurance) and support services (key management, security maintenance, network management). An integrated security system must offer all these services with a number of security mechanisms implemented in a number of security products Attaques Techniques Adopted By 'System Crackers' When Attempting To Break Into Corporate Networks. By the consultants of the Network Security Solutions Ltd. Front-line Information Security Team (FIST), December 1998. 1.0 Introduction This white paper was written to help give systems administrators and network operations staff an insight into the tactics and methodologies adopted by typical system crackers when targeting large networks. This document is not a guide about how to secure your networks, although it should help you identify security risks in your networked environment and maybe help point out any accidents that are waiting to happen. We hope you enjoy reading this paper, and hopefully learn a little about how crackers operate in the meantime! The Network Security Solutions Ltd. FIST staff ([email protected]) 1.1 Just who is vulnerable anyway? Networked computer environments are used everyday by corporations and various organisations. Networks of computers allow users to share vast amounts of data very efficiently. Usually corporate networks are not designed and implemented with security in mind, merely functionality and efficiency, although this is good from a business standpoint in the short-term, security problems usually arise later, which can cost millions to solve in larger environments. Most corporate and sensitive private networks work on a client-server principle, where employees use workstations to connect to servers in order to share information. In this paper we will concentrate on server security, as most crackers will always target servers first, the server is much like a 'hub' where all the information is stored. If a cracker can gain unauthorised access to such a server, the rest of his work is easy. Vulnerable parties to large-scale network probes usually include : Financial institutions and banks Internet service providers Pharmaceutical companies Government and defense agencies Contractors to various goverment agencies Multinational corporations Although many of these attacks take place internally (by users who have authorised access to parts of the corporate or sensitive networks already), we will be concentrating on the techniques used when breaking into such networks entirely from the outside. Financial institutions and banks are probed and attacked in attempts to commit fraud. Many banks have been targeted in this way, risking vast monetary funds. Banks make it policy not to admit to being victims of such external attacks because they will certainly lose customers and trust if attacks are publically known. Internet service providers are a common target by crackers, as ISP servers are easily accessible from the internet, and ISP's have access to large fibre optic connections which can be used by crackers to move large amounts of data across the internet. The larger ISP's also have customer databases, which usually contain confidential user information such as credit card numbers, names and addresses. Pharmaceutical companies are victims of mainly industrial espionage attempts, where a team of crackers will be paid large amounts in exchange for stolen pharmaceutical data, such drug companies often spend millions on research and development, and a lot can be lost as a result of such an attack. Over the last 6 years, Government and defence agencies in the United States have been victim to literally millions of attacks originating from the internet. Due to the low information security budgets and the weak security policies of such agencies, information security has become an uphill battle, as government and military servers are constantly being probed and attacked by crackers. Defence contractors, although security conscious, are targets to crackers seeking classified or sensitive military data. Such data can then be 'sold on' by crackers to foreign groups. Although only a handful of these cases have been publically known, such activities can occur at an alarming rate. Multinational corporations are prime examples of victims of industrial espionage attempts. Multinational corporations have offices based all around the world, and large corporate networks are installed in order for employees to be able to share information efficiently. NSS staff have performed penetration tests for multinational corporations, and our findings in most cases have shown that many can be compromised. Like pharmaceutical companies, multinational corporations operating in electronics, software or computer-related industries, spend millions on research and development of new technologies. It is very tempting for a competitor of such a corporation, to employ a team of 'system crackers' to steal data from a target corporation. Such data can then be used to quickly and easily improve the competitors knowledge of key technologies, and result in financial losses of the target corporation. Another form of attack adopted by competitors of corporations, is to 'take down' a corporate network for a certain amount of time, this results in loss of earnings for the target corporation. In most cases it is extremely difficult to locate the source of such an attack. Depending on the internal network segmentation in place, this kind of attack can be hugely effective and result in massive financial losses. Such 'foul play' is commonplace in today's networked society, and should be taken very seriously. 1.2 Profile of a typical 'system cracker' Studies have shown that typical a 'system cracker' is usually male, aged between 16 and 25. Such crackers usually become interested in breaking into machines and networks in order to improve their cracking skills, or to use network resources for their own purposes. Most crackers are quite persistent in their attacks, this is due to the amount of spare time an average cracker has. A high percentage of crackers are opportunists, and run scanners to check massive numbers of hosts for remote system vulnerabilities. Upon identifying hosts or networks that are vulnerable to remote attacks, the cracker will usually gain root access to the host, then install a backdoor and patch the host from common remote vulnerabilities, this prevents other crackers from being able to use the same popular techniques to gain access to the host. Opportunists operate on primarily two domains, the first being the internet, the second being telephone networks. To scan internet hosts for common remote vulnerabilities, the cracker will usually launch a scanning operation from a host that he has access to with a fast connection to the internet, usually on a fibreoptic connection. To scan for machines operating on telephone networks, being terminal servers, bulletin board systems, or voice mail systems. The cracker will use a wardialling program, this will automatically scan large amounts of telephone numbers for 'carriers', thus identifying such systems. A very small percentage of crackers actually define targets and attempt to attack them, such crackers are far more skilled, and adopt 'cutting-edge' techniques to compromise networks. It is known for these types of crackers to attack corporate networks that are firewalled from the internet by exploiting nonpublished vulnerabilities and 'features' in firewalls. The networks and hosts targeted by these crackers usually have sensitive data contained within them, such as research and development notes, or other data that will prove useful to the cracker. Such crackers are also known to have access to exploits and tools used by security consultants and large security companies, and then use them to scan defined targets for all known remote vulnerabilities. Crackers that are attacking specific hosts are also usually very patient, and have been known to spend many months gathering data before attempting to gain access to a host or network. 2.1 Networking methodologies adopted by many companies A typical corporation will have an internet presence for the following purposes : The hosting of corporate webservers E-mail and other global communications via. the internet To give employees internet access Of the corporations NSS has performed network penetration tests from the internet for, a networked environment is adopted where the corporate network and the internet are seperated by firewalls and application proxies. In such environments, the corporate webservers and mailservers are usually kept on the 'outside' of the corporate network, and then information is passed via. trusted channels onto the corporate network. In the case of trust present between external mailservers and hosts on the corporate network, a wellthought filtering policy has to be put into effect, as usually the external mailservers should only be able to connect to port 25 of a single 'secure' mailserver on the corporate network, as this will massively minimise the probability of unauthorised access, even if the external mailserver is compromised. One of the corporate networks NSS has performed penetration test on also had a handful of 'dualhomed' hosts, these hosts had network interfaces active on both the internet and the corporate network. From a security standpoint, such hosts that operate on multiple networks can pose a massive threat to network security, as upon compromising a host, it then acts as a simple 'bridge' between networks. 2.2 Understanding vulnerabilities in such networked systems On the internet, a corporation may have 5 external webservers, 2 external mailservers, and a firewall or filtering system implemented. Webservers are usually not attacked by crackers wanting to gain access to the corporate network, unless the firewall is misconfigured in some way that will allow the cracker access to the corporate network upon compromising the webserver. Although it is always good practise to secure your webservers and run TCP wrappers to allow only trusted parties to connect to the telnet and ftp ports. Mailservers are commonly targeted by crackers wanting to gain access to the corporate network, as a mailserver must have access to mailservers on the corporate network in order to distribute and exchange mail between the internet and the corporate network. Again, depending on the filtering in place, this tactic may or may not be effective on the cracker's part. Filtering routers are also commonly targeted by crackers with agressive-SNMP scanners and community string brute-force programs, if such an attack is effective, the router can easily be turned into a bridge, thus allowing unauthorised access to the corporate network. In this kind of situation the cracker will evaluate exactly which external hosts he has access to, and then attempt to identify any kinds of trust between the corporate network and the external hosts. Therefore if you install TCP wrappers on all your external hosts, which define that only trusted parties can connect to the critical ports of your hosts, which are usually : ftp (21), ssh (22), telnet (23), smtp (25), named (53), pop3 (110), imap (143), rsh (514), rlogin (513), lpd (515). SMTP, named and portmapper should be filtered accordingly depending on the host's role is on the network. Such filtering has been proven to massively reduce the risk of an attack on the corporate network. In the cases of networks with no clear 'corporate to internet' network security policy, multiple-homed hosts and misconfigured routers will exist. A lack of internal network segmentation will also usually exist, this makes it a lot easier for an cracker based on the internet to gain unauthorised access to the corporate network. Corporate network mapping can easily occur if external DNS servers are misconfigured, as NSS has performed penetration tests where we have been able to map the corporate network via. such a misconfigured DNS server, because of this, it is very important that DNS doesn't exist between hosts on the corporate network and external hosts, it is far safer to simply use IP addresses to connect to external machines from the corporate network and vice-versa. Insecure hosts with network interfaces active on multiple networks can be abused to gain access to the corporate network very easily. The insecure host doesn't even have to be compromised. It is very easy to abuse a finger daemon on such a host that allows forwarding.. as users, hosts and other network information can be collected to identify easily exploitable hosts on the corporate network, the operating system of a host can even be determined in many cases by issuing a finger request for root@host, bin@host and daemon@host. Some crackers are now starting to adopt techniques regarding the 'wardialling' of corporate locations, such as buildings and network operation centres. If a cracker was to find and then compromise a corporate terminal server, he would usually have a degree of access to the corporate network, thus totally bypassing any firewalls or filters that seperate the corporate network from the internet. It is therefore very important to identify and ensure the security of your terminal servers, logging of connections to such servers is also strongly advised. When trying to understand vulnerabilities in networked systems, a key point to remember, is trust between hosts on your network. Either through the use of TCP wrappers, hosts.equiv files, .rhosts or .shosts files, many larger networks are commonly attacked by exploiting the trust between hosts. For example, if an attacker uses a CGI exploit to view your hosts.allow file, he may find that you all connections to your ftp and telnet ports from *.trusted.com. Of course, the attacker can then gain access to any host at trusted.com, and gain access to your hosts easily. For these reasons, it is always a good idea to ensure that trusted hosts are equally secure from remote attack. One other attack that should be mentioned, is the installation of trojans and backdoors on corporate hosts (such as Windows 95/98 machines), if the employees have internet access through using an application proxy and a firewall, then they will sometimes visit 'warez' sites to download pirated software. Such 'warez' sites usually have screesaver software, and other utilities on offer, which in some cases contain trojan horse programs, such as the Cult of the Dead Cow's 'Back Orifice' trojan. Upon the installation of the screensaver, the trojan infests itself within the machine's registry and is run every time the machine boots. In the case of the BO trojan, plugins can be applied to the trojan to make the machine perform certain operations automatically, such as connect to IRC servers and join channels, and the like. This can prove very dangerous, as a trojaned machine on your corporate network could easily be controlled by someone on the internet. The BO trojan is infinitely more effective if the cracker already has access to the corporate network, either because he is an employee or has unauthorised access to corporate hosts. The BO trojan could be installed on every single Windows 95/98 machine in a matter of weeks if the cracker uses the correct strategy, after which he will have total remote control over the machines in question, including being able to manipulate files, reboot machines and even format drives, entirely remotely. 3.1 Techniques used to 'cloak' the attackers location Typical crackers will usually use the following techniques to hide their true IP address : - Bouncing through previously compromised hosts via. telnet or rsh. - Bouncing through windows hosts via. Wingates. - Bouncing through hosts using misconfigured proxies. If such a cracker has a pattern of always scanning your hosts from previously compromised machines, wingates or proxies, then it is advisable to contact the administrator of the machine by telephone, and notify him of the problems in hand. Never e-mail an administrator in such a case, because the cracker can simply intercept the e-mail beforehand. The more talented crackers who are skilled in breaking into hosts via. telephone exchanges, may use the following techniques : - Bouncing through '800-number' private telephone exchanges before connecting to an ISP using a 'cracked', 'phished' or 'carded' account. - Connecting to a host by telephone, that is in turn connected to the internet. Crackers adopting the techniques of bouncing through telephone networks before connecting to the internet are extremely hard to track down, because they could be literally anywhere in the world. If a cracker was to use an '800-number' dialup, he could dial into machines globally without having to worry about the cost. 3.2 Network probing and information gathering Before setting out to attack a corporate network from the internet, a typical cracker will perform some preliminary probes of your networks external hosts present on the internet. A cracker will attempt to gain external and internal hostnames by using the following techniques : - Using nslookup to perform 'ls <domain or network>' requests. - View the HTML on your webservers to identify any other hosts. - View the documents on your FTP servers. - Connect to your mailservers and perform 'expn <user>' requests. - Finger users on your external hosts. Crackers usually attempt to gather information about the layout of your network itself first as opposed to identifying specific vulnerabilities. By looking at results from the queries listed above, it is usually easy for a cracker to build a list of hosts and start to understand the relationships that exist between them. When performing these preliminary probes, a typical cracker will make very small mistakes and sometimes use his own IP to connect to ports of your machines to check operating system versions and other small details. If your hosts are compromised, it is a good idea to check your FTP and HTTPD logs for the presence of any strange requests. 3.3 Identifying trusted network components Crackers look for trusted network components to attack, a trusted network component is usually an administrators machine, or a server that is regarded as secure. A cracker will start out by checking the NFS exports of any of your machines running nfsd or mountd, the case being that critical directories on some of your hosts (such as /usr/bin, /etc and /home for example) may be mountable by such a trusted host. The finger daemon is often abused to identify trusted hosts and users, being users who often log into the machine from specific hosts. The cracker will then check your machines for other forms of trust, if he can exploit a machine using a CGI vulnerability, he may gain access to a hosts /etc/hosts.allow file, for example. After analysing the data from the above checks, the cracker will start to identify trust between hosts. The next step for the cracker is to identify any trusted hosts that are vulnerable to a remote compromise. 3.4 Identifying vulnerable network components If a cracker can build lists of your external and internal hosts, he will use Linux programs such as ADMhack, mscan, nmap and many smaller scanners to scan for specific remote vulnerabilities. Usuaully such scans of your external hosts will be launched from machines on fast fibre-optic connections, ADMhack requires to be run as root on a Linux machine, so a cracker will probably use a Linux machine that he has gained unauthorised access to and properly installed a 'rootkit' on. Such a 'rootkit' is used to backdoor critical system binaries to allow unauthorised and undetectable access to the host. The systems administrators of the hosts that are used to scan external corporate hosts usually have no idea that scans are being launched from their machines, as binaries such as 'ps' and 'netstat' are trojaned to hide scanning processes. Other programs such as mscan and nmap don't require to be run as root, and so can be launched from Linux (or other platforms in the case of nmap) hosts to effectively identify remote vulnerabilities, although these scans are slower, and cannot usually be hidden very well (as the attacker doesn't need root access to the host as with ADMhack). Both ADMhack and mscan perform the following types of checks on remote hosts : - A TCP portscan of a host. - A dump of the RPC services running via. portmapper. - A listing of exports present via. nfsd. - A listing of shares present via. samba or netbios. - Multiple finger requests to identify default accounts. - CGI vulnerability scanning. - Identification of vulnerable versions of server daemons, including Sendmail, IMAP, POP3, RPC status and RPC mountd. Programs such as SATAN are rarely used by crackers nowadays, as they are slow.. and scan for outdated vulnerabilities. After running ADMhack or mscan on the external hosts, the cracker will have a good idea of vulnerable or secure hosts. If routers are present that are SNMP capable, the more advanced crackers will adopt agressive-SNMP scanning techniques to try and 'brute force' the public and private community strings of such devices. 3.5 Taking advantage of vulnerable network components So the cracker has identified any trusted external hosts, and also identified any vulnerabilities in external hosts. If any vulnerable network components were identified, then he will attempt to compromise your hosts. A patient cracker won't compromise your hosts during normal hours, he will usually launch an attack between 9pm in the evening and 6am the next morning, this will reduce the likelyhood of anyone knowing about the attack, and give the cracker ample time to install backdoors and sniffers on your hosts without having to worry about the presence of Systems Administrators. Most crackers have a great deal of spare time over weekends, and attacks are usually launched then. The cracker will compromise an external trusted host that can be used as a point from which to launch an attack on the corporate network. Depending on the filtering between the corporate network and the external corporate hosts, this technique may or may not work. If the cracker compromises an external mailserver, which in turn has total access to a segment of the internal corporate network, then he can start work on embedding himself deeply into your network. To compromise most networked components, crackers will use programs to remotely exploit vulnerable versions of server daemons running on external hosts, such examples include vulnerable versions of Sendmail, IMAP, POP3 and RPC services such as statd, mountd and pcnfsd. Most remote exploits used by crackers are launched from previously compromised hosts, as in some cases they need to be compiled on the same platform as the host they are to be used to exploit. Upon executing such a program remotely to exploit a vulnerable server daemon running on your external host, the cracker will usually gain root access to your host, which in turn can be abused to gain access to other hosts and the corporate network. 3.6 Upon gain access to vulnerable network components After exploiting a server daemon, the cracker will start a 'clean-up' operation of doctoring your hosts logs and 'backdooring' service binaries so he can access the host undetected later. First he will start to implement backdoors, so he can later access the host. Most backdoors that crackers use are precompiled, and techniques are adopted to change the date and the permissions of the binary that has been backdoored, in some cases, even the filesize of the new binary is the same as the original binary. Attackers conscious of FTP transfer logs may use the 'rcp' program to copy backdoored programs to hosts. It is unlikely that such a cracker breaking into a corporate network will start to patch your hosts from vulnerabilities, he will usually only install backdoors and trojan critical system binaries such as 'ps' and 'netstat' to hide any connections he may make to and from the host. The following critical binaries are usually backdoored on Solaris 2.x machines : /usr/bin/login /usr/sbin/ping /usr/sbin/in.telnetd /usr/sbin/in.rshd /usr/sbin/in.rlogind Some crackers have also been known to place an .rhosts file in the /usr/bin directory to allow remote bin access to the host via. rsh and csh in interactive mode. The next thing that most crackers do is to check the host for any presence of logging systems that may have logged his connections to the host, he will then proceed to edit such connections out of any logs found on the host. It is advisable to log to a lineprinter if the machine is very likely to be a prime target of an attack, as this makes it extremely difficult for the cracker to edit himself from the logs. Upon ensuring that his presence has not been logged in any way, the cracker will proceed to invade the corporate network. Most crackers won't bother exploiting vulnerabilities in other external hosts if they have access to the internal network. 4.1 Downloading sensitive information If the cracker's goal is to download sensitive information from FTP servers or webservers on the internal corporate network, he can do so from the external host that is acting as a 'bridge' between the internet and corporate network. However, if the cracker's goal is to download sensitive information held within internally networked hosts, he will proceed to attempt to gain access to them by abusing the trust with the external host he already has access to. 4.2 Cracking other trusted hosts and networks Most crackers will simply repeat the steps taken in sections 3.2, 3.3, 3.4 and 3.5 to probe and gain access to hosts on the internal corporate network, depending on what the cracker is attempting to achieve, trojans and backdoors may or may not be installed on your internal hosts. If the cracker wishes to achieve total network access to the hosts on the internal network, he will install trojans and backdoors and remove logs as in section 3.6. Crackers will also install sniffers on your hosts, these are explained in section 4.3. If the cracker merely wishes to download data from key servers, he will take different approaches to gaining access to your hosts, such as identifying and attacking key hosts that are trusted by the target key servers. 4.3 Installing sniffers An extremely effective way for crackers to quickly obtain large amounts of usernames and passwords for internally networked hosts is to use 'ethernet sniffer' programs. Because such 'sniffer' programs need to operate on the same ethernet as the hosts the cracker wants to gain access to, it would be ineffective to run a sniffer on the external host he is using as a bridge. To 'sniff' data flowing across the internal network, the cracker must perform a remote root compromise of an internal host that is on the same ethernet as a number of other internal hosts. The techniques mentioned in sections 3.2, 3.3, 3.4, 3.5 and 3.6 are adopted here, as the cracker must compromise and backdoor the host successfully to ensure that the sniffer program can be installed and used effectively. Upon compromising, installing a backdoor and installing trojaned 'ps' and 'netstat' programs, the cracker must then install the 'ethernet sniffer' program on the host. Such sniffer programs are usually installed in the /usr/bin or /dev directories under Solaris 2.x, and then modified to seem as if they were installed with all the other system binaries. Most 'ethernet sniffers' run in the background and output to a log on the local machine, it is important to remember that the cracker will usually backdoor the 'ps' binary, so the process may not be noticeable. Such 'ethernet sniffers' work by turning a network interface into 'promiscuous mode', the interface then listens and logs to the sniffer logfile, any useful usernames, passwords or other data that can be used by the cracker to gain access to other networked hosts. Because 'ethernet sniffers' are installed on ethernets, literally any data travelling across that network can be sniffed, it doesn't have to be travelling to or from the host on which the sniffer is installed. The cracker will usually return a week later and download the logfile created by the 'sniffer' program. In the case of a corporate network breach such as this, it is likely that the sniffer will be set up very well, and hardly detectable unless a good security policy is implemented. A very good utility used by many security-conscious Administrators is Tripwire, which is available from COAST (see section 5.2). Tripwire makes an MD5 'fingerprint' of your filesystem, and will detect any modifications to your files made by malicious users or crackers. To detect promiscuous network interfaces (a common sign of a sniffer installation), the 'cpm' tool available from CERT is very useful, see http://www.cert.org/ftp/tools/cpm/ for more information. 4.4 Taking down networks If a cracker can compromise key servers running server applications such as databases, network operations systems or any other 'mission critical' functions, it is easy for him to take down your network for a period of time. A crude, but not unusual technique adopted by crackers attempting to disable network functions, would be to delete all the files from the key servers by issuing an 'rm -rf / &' command on the server. Depending on the backup system implemented, the system could be for anything from hours, to months. If a cracker was to gain access to your internal network, he could abuse vulnerabilities present in many routers such as in the Cisco, Bay and Ascend brands. In some cases the cracker could restart, or shut down routers entirely until an administrator was to reboot them. This can cause big problems regarding network functionality, as if the cracker was to assemble a list of vulnerable routers that performed key networking roles (if they were used on the corporate backbone for example), then he could easily disable the corporations networking ability for some time. For these reasons, it is very important that 'mission critical' routers and servers are always patched and secure. 5.1 Suggested reading There are many good papers available to help you maintain security of your external and internal hosts and routers, we recommend you visit the following websites and take a look at the following books if you wish to learn more about securing large networks and hosts : http://www.antionline.com/archives/documents/advanced/ http://www.rootshell.com/beta/documentation.html http://seclab.cs.ucdavis.edu/papers.html http://rhino9.ml.org/textware/ 'Practical Unix & Internet Security' A good introduction into Unix and Internet security if you really haven't read much into the subject before. Simson Garfinkel and Gene Spafford O'Reilly & Associates, Inc. ISBN 1-56592-148-8 US $39.95 CAN $56.95 (UK around 30 pounds) 5.2 Suggested tools and programs There are many good free security programs available for common platforms such as Solaris, IRIX, Linux, AIX, HP-UX and Windows NT, we recommend you take a look at the following websites for information on such free security tools : ftp://coast.cs.purdue.edu/pub/tools/unix/ http://www.alw.nih.gov/Security/prog-full.html http://rhino9.ml.org/software Network Security Solutions Ltd., is also currently developing a plethora of security tools for Unix and Windows based platforms, these will be available over the next few months, feel free to visit our site at http://www.ns2.co.uk , also look out for free 'lite' versions of our software! Copyright (c) Network Security Solutions Ltd. 1998 All rights reserved, all trademarks acknowledged http://www.ns2.co.uk Undernet/ Computer Underground NORTHERN ILLINOIS UNIVERSITY THE SOCIAL ORGANIZATION OF THE COMPUTER UNDERGROUND GORDON R. MEYER ABSTRACT This paper examines the social organization of the "computer underground" (CU). The CU is composed of actors in three roles, "computer hackers," "phone phreaks," and "software pirates." These roles have frequently been ignored or confused in media and other accounts of CU activity. By utilizing a data set culled from CU channels of communication this paper provides an ethnographic account of computer underground organization. It is concluded that despite the widespread social network of the computer underground, it is organized primarily on the level of colleagues, with only small groups approaching peer relationships. Introduction The proliferation of home computers has been accompanied by a corresponding social problem involving the activities of so-called "computer hackers." "Hackers" are computer aficionados who "break in" to corporate and government computer systems using their home computer and a telephone modem. The prevalence of the problem has been dramatized by the media and enforcement agents, and evidenced by the rise of specialized private security firms to confront the "hackers." But despite this flurry of attention, little research has examined the social world of the "computer hacker." Our current knowledge in this regard derives from hackers who have been caught, from enforcement agents, and from computer security specialists. The everyday world and activities of the "computer hacker" remain largely unknown. This study examines the way actors in the "computer underground" (CU) organize to perform their acts. The computer underground, as it is called by those who participate in it, is composed of actors adhering to one of three roles: "hackers," "phreakers," or "pirates." To further understanding this growing "social problem," this project will isolate and clarify these roles, and examine how each contributes to the culture as a whole. By doing so the sociological question of how the "underground" is organized will be answered, rather than the technical question of how CU participants perform their acts. Best and Luckenbill (1982) describe three basic approaches to the study of "deviant" groups. The first approach is from a social psychological level, where analysis focuses on the needs, motives, and individual characteristics of the actors involved. Secondly, deviant groups can be studied at a socio-structural level. Here the emphasis is on the distribution and consequences of deviance within the society as a whole. The third approach, the one adopted by this work, forms a middle ground between the former two by addressing the social organization of deviant groups. Focusing upon neither the individual nor societal structures entirely, social organization refers to the network of social relations between individuals involved in a common activity (pp. 13-14). Assessing the degree and manner in which the underground is organized provides the opportunity to also examine the culture, roles, and channels of communication used by the computer underground. The focus here is on the day to day experience of persons whose activities have been criminalized over the past several years. Hackers, and the "danger" that they present in our computer dependent society, have often received attention from the legal community and the media. Since 1980, every state and the federal government has criminalized "theft by browsing" of computerized information (Hollinger and Lanza-Kaduce, 1988, pp.101-102). In the media, hackers have been portrayed as maladjusted losers, forming "high-tech street gangs" (Chicago Tribune, 1989) that are dangerous to society. My research will show that the computer underground consists of a more sophisticated level of social organization than has been generally recognized. The very fact that CU participants are to some extent "networked" has implications for social control policies that may have been implemented based on an incomplete understanding of the activity. This project not only offers sociological insight into the organization of deviant associations, but may be helpful to policy makers as well. I begin with a discussion of the definitional problems that inhibit the sociological analysis of the computer underground. The emergence of the computer underground is a recent phenomenon, and the lack of empirical research on the topic has created an area where few "standard" definitions and categories exist. This work will show that terms such as "hacker," "phreaker," and "pirate" have different meanings for those who have written about the computer underground and those who participate in it. This work bridges these inconsistencies by providing definitions that focus on the intentions and goals of the participants, rather than the legality or morality of their actions. Following the definition of CU activities is a discussion of the structure of the underground. Utilizing a typology for understanding the social organization of deviant associations, developed by Best and Luckenbill (1982), the organization of the computer underground is examined in depth. The analysis begins by examining the structure of mutual association. This provides insight into how CU activity is organized, the ways in which information is obtained and disseminated, and explores the subcultural facets of the computer underground. More importantly, it clearly illustrates that the computer underground is primarily a social network of individuals that perform their acts separately, yet support each other by sharing information and other resources. After describing mutual association within the underground community, evidence of mutual participation is presented. Although the CU is a social network, the ties developed at the social level encourage the formation of small "work groups." At this level, some members of the CU work in cooperation to perform their acts. The organization and purposes of these groups are examined, as well as their relationship to the CU as a whole. However, because only limited numbers of individuals join these short-lived associations, it is concluded that the CU is organized as colleagues. Those who do join "work groups" display the characteristics of peers, but most CU activity takes place at a fairly low level of sophistication. Methodology Adopting an ethnographic approach, data have been gathered by participating in, monitoring, and cataloging channels of communication used by active members of the computer underground. These channels, which will be examined in detail later, include electronic bulletin board systems (BBS), voice mail boxes, bridges, loops, e-mail, and telephone conversations. These sources provide a window through which to observe interactions, language, and cultural meanings without intruding upon the situation or violating the privacy of the participants. Because these communication centers are the "back stage" area of the computer underground, they provided insight into organizational (and other) issues that CU participants face, and the methods they use to resolve them. As with any ethnographic research, steps have been taken to protect the identity of informants. The culture of the computer underground aids the researcher in this task since phreakers, hackers, and pirates regularly adopt pseudonyms to mask their identity. However to further ensure confidentiality, all of the pseudonyms cited in this research have been changed by the author. Additionally, any information that is potentially incriminating has been removed or altered. The data set used for this study consists primarily of messages, or "logs," which are the primary form of communication between users. These logs were "captured" (recorded using the computer to save the messages) from several hundred computer bulletin boards1 located across the United States. The bulk of the data were gathered over a seventeen month period (12/87 to 4/89) and will reflect the characteristics of the computer underground during that time span. However, some data, provided to the researcher by cooperative subjects, dates as far back as 1984. The logged data were supplemented by referring to several CU "publications." The members of the computer underground produce and distribute several technical and tutorial newsletters and "journals." Since these "publications" are not widely available outside of CU circles I have given a brief description of each below. Legion of Doom/Hackers Technical Journal. This publication is written and distributed by a group known as "The Legion of Doom/Legion of Hackers" (LoD/H). It is available in electronic format (a computer text file) and contains highly technical information on computer operating systems. As of this writing, three issues have been published. PHRACK Inc.: Phrack Inc is a newsletter that contains various articles, written by different authors, and "published" under one banner. Phrack Inc's first issue was released in 1985, making it the oldest of the electronically distributed underground publications. CU participants are invited to submit articles to the editors, who release a new issue when a sufficient number (about nine) of acceptable pieces have been gathered. Phrack also features a lengthy "World News" with stories about hackers who have been apprehended and interviews with various members of the underground. As of this writing twenty-seven issues of Phrack, have been published. Phreakers/Hackers Underground Network (P/Hun): Like Phrack, P/Hun collects articles from various authors and releases them as one issue. Three issues have been published to date. Activist Times, Incorporated (ATI): Unlike the other electronically distributed publications, ATI does not limit itself to strictly computer/telephone news. Articles normally include commentary on world and government events, and other "general interest" topics. ATI issues are generally small and consist of articles written by a core group of four to seven people. Unlike the publications discussed thus far, ATI is available in printed "hard copy" form by sending postage reimbursement to the editor. ATI is currently on their 38th issue. 2600 Magazine: Published in a traditional (printed) magazine format, 2600 (named for the frequency tone used to make free long distance phone calls) is arguably an "underground" publication as it is available on some newsstands and at some libraries. Begun in 1987 as a monthly magazine, it is now published quarterly. Subscription rates are $25.00 a year with a complete back-issue selection available. The magazine specializes in publishing technical information on telephone switching systems, satellite descrambling codes, and news about the computer underground. TAP/YIPL: First established in 1972 as YIPL (Youth International Party Line), this publication soon changed its name to TAP (Technical Assistance Party). Co-founded by Abbie Hoffman, it is generally recognized as the grandfather of computer underground publications. Publication of the 2-4 page newsletter has been very sporadic over the years, and currently two different versions of TAP, each published in different areas of the country, are in circulation. Utilizing a data set that consists of current message logs, old messages logs, and various CU publications yields a reasonably rich collection from which to draw the analysis. Examination of the older logs and publications shows that while the actors have changed over the years, cultural norms and characteristics have remained consistent over time. What is the Computer Underground? Defining the "computer underground" can be difficult. The sociologist soon finds that there are several competing definitions of computer underground activity. Those who have written on the subject, the media, criminologists, computer programmers, social control agents, and CU participants themselves, have adopted definitions consistent with their own social positions and perspectives. Not surprisingly, these definitions rarely correspond. Therefore, before discussing the organization of the computer underground, it is necessary to discuss and compare the various definitions. This will illustrate the range of beliefs about CU activity, and provide a springboard for the discussion of types of roles and activities found in the underground. We begin with a discussion of the media image of computer hackers. The media's concept of "hackers" is important because the criminalization of the activity has largely occurred as the result of media dramatization of the "problem" (Hollinger and Lanza-Kaduce, 1988). In fact, it was a collection of newspaper and film clips that was presented to the United States Congress during legislative debates as evidence of the computer hacking problem (Hollinger and Lanza-Kaduce, 1988, p.107). Unfortunately, the media assessment of the computer underground displays a naive understanding of CU activity. The media generally makes little distinction between different types of CU activity. Most any computer-related crime activity can be attributed to "hackers." Everything from embezzlement to computer viruses have, at one time or another, been attributed to them. Additionally, hackers are often described as being sociopathic or malicious, creating a media image of the computer underground that may exaggerate their propensity for doing damage. The labeling of hackers as being "evil" is well illustrated by two recent media examples. The first is from Eddie Schwartz, a WGN-Radio talk show host. Here Schwartz is addressing "Anna," a selfidentified hacker that has phoned into the show: You know what Anna, you know what disturbs me? You don't sound like a stupid person but you represent a . . . a . . . a . . . lack of morality that disturbs me greatly. You really do. I think you represent a certain way of thinking that is morally bankrupt. And I'm not trying to offend you, but I . . . I'm offended by you! (WGN Radio, 1988) Just two months later, NBC-TV's "Hour Magazine" featured a segment on "computer crime." In this example, Jay Bloombecker, director of the National Center for Computer Crime Data, discusses the "hacker problem" with the host of the show, Gary Collins. Collins: . . . are they %hackers% malicious in intent, or are they simply out to prove, ah, a certain machismo amongst their peers? Bloombecker: I think so. I've talked about "modem macho" as one explanation for what's being done. And a lot of the cases seem to involve %proving% %sic% that he . . . can do something really spiffy with computers. But, some of the cases are so evil, like causing so many computers to break, they can't look at that as just trying to prove that you're better than other people. GC: So that's just some of it, some kind of "bet" against the computer industry, or against the company. JB: No, I think it's more than just rottenness. And like someone who uses graffiti doesn't care too much whose building it is, they just want to be destructive. GC: You're talking about a sociopath in control of a computer! JB: Ah, lots of computers, because there's thousands, or tens of thousands %of hackers% (NBC-TV, 1988). The media image of computer hackers, and thus all members of the computer underground, is burdened with value-laden assumptions about their psychological makeup, and focuses almost entirely upon the morality of their actions. Additionally, since media stories are taken from the accounts of police blotters, security personnel, and hackers who have been caught, each of whom have different perspectives and definitions of their own, the media definition, if not inherently biased, is at best inconsistent. Criminologists, by way of contrast, have done little to define the computer underground from a sociological perspective. Those criminological definitions that do exist are less judgmental than the media image, but no more precise. Labels of "electronic trespassers" (Parker, 1983), and "electronic vandals" (Bequai, 1987) have both been applied to hackers. Both terms, while acknowledging that "hacking" is deviant, shy away from labeling it as "criminal" or sociopathic behavior. Yet despite this seemingly non-judgmental approach to the computer underground, both Parker and Bequai have testified before Congress, on behalf of the computer security industry, on the "danger" of computer hackers. Unfortunately, their "expert" testimony was largely based on information culled from newspaper stories, the objectiveness of which has been seriously questioned (Hollinger and LanzaKaduce 1988 p.105). Computer security specialists, on the other hand, are often quick to identify CU participants as part of the criminal element. Correspondingly, some reject the notion that there are different roles and motivations among computer underground participants and thereby refuse to define just what it is that a "hacker" or "phreaker" does. John Maxfield, a "hacker expert," suggests that differentiating between "hackers" and "phone phreaks" is a moot point, preferring instead that they all just be called "criminals" (WGN-Radio. Sept 28, 1988). The reluctance or inability to differentiate between roles and activities in the computer underground, as exhibited in the media and computer security firms, creates an ambiguous definition of "hacker" that possesses two extremes: the modern-day bank robber at one end, the trespassing teenager at the other. Thus, most any criminal or mischievous act that involves computers can be attributed to "hackers," regardless of the nature of the crime. Further compounding the inconsistent use of "hacker" is the evolution of meaning that the word has undergone. "Hacker" was first applied to computer related activities when it was used by programmers in the late 1950's. At that time it referred to the pioneering researchers, such as those at M.I.T., who were constantly adjusting and experimenting with the new technology (Levy, 1984. p.7). A "hacker" in this context refers to an unorthodox, yet talented, professional programmer. This use of the term still exits today, though it is largely limited to professional computing circles. Another definition of "hacker" refers to one who obtains unauthorized, if not illegal, access to computer systems and networks. This definition was popularized by the movie War Games and, generally speaking, is the one used by the media. It is also the definition favored by the computer underground. Both the members of the computer underground and computer programmers claim ownership of "hacker," and each defend the "proper" use of term. The computer professionals maintain that using "hackers" (or "hacking") to refer to any illegal or illicit activity is a corruption of the "true" meaning of the word. Bob Bickford, a professional programmer who has organized several programmer conferences, explains: At the most recent conference %called "Hackers 4.0"% we had 200 of the most brilliant computer professionals in the world together for one weekend; this crowd included several PhD's, several presidents of companies (including large companies, such as Pixar), and various artists, writers, engineers, and programmers. These people all consider themselves Hackers: all derive great joy from their work, from finding ways around problems and limits, from creating rather than destroying. It would be a great disservice to these people, and the thousands of professionals like them, to let some pathetic teenaged criminals destroy the one word which captures their style of interaction with the universe: Hackers (Bickford, 1988). Participants in the computer underground also object to the "misuse" of the term. Their objection centers around the indiscriminate use of the word to refer to computer related crime in general and not, specifically, the activities of the computer underground: Whenever the slightest little thing happens involving computer security, or the breach thereof, the media goes fucking bat shit and points all their fingers at us 'nasty hackers.' They're so damned ignorant it's sick (EN, message log, 1988). . . . whenever the media happens upon anything that involves malicious computer use it's the "HACKERS." The word is a catch phrase it makes mom drop the dishes and watch the TV. They use the word because not only they don't really know the meaning but they have lack of a word to describe the perpetrator. That's why hacker has such a bad name, its always associated with evil things and such (PA, message log, 1988). I never seen a phreaker called a phreaker when caught and he's printed in the newspaper. You always see them "Hacker caught in telephone fraud." "Hacker defrauds old man with phone calling card." What someone should do is tell the fucken (sic) media to get it straight (TP2, message log, 1988). Obviously the CU and computer professional definitions of "hacker" refer to different social groups. As Best and Luckenbill (1982, p. 39) observe: "Every social group modifies the basic language to fit its own circumstance, creating new words or using ordinary words in special ways." Which definition, if either, will come into widespread use remains to be seen. However, since computer breakins are likely to receive more media attention than clever feats of programming, the CU definition is likely to dominate simply by being used more often.4 But as long as the two definitions do exist there will be confusion unless writers and researchers adequately specify the group under discussion. For this reason, I suggest that sociologists, and criminologists in particular, adopt the "underground" definition for consistency and accuracy when speaking of the actions of CU participants. While it is recognized that computer hacking is a relatively new phenomenon, the indiscriminant use of the term to refer to many different forms of unorthodox computer use has been counterproductive to understanding the extent of the activity. To avoid this a "computer hacker" should be defined as an individual, associated with the computer underground, who specializes in obtaining unauthorized access to computer systems. A "phone phreak" in an individual, associated with the computer underground, who specializes in obtaining unauthorized information about the phone system. A "software pirate" is an individual, associated with the computer underground, who distributes or collects copyrighted computer software. These definitions have been derived from the data, instead of relying upon those who defend the "integrity" of the original meanings, or those who are unfamiliar with the culture. Topography of the Computer Underground Having defined the three main roles in the computer underground, it is necessary to examine each activity separately in order to provide a general typology of the computer underground. In doing so, the ways in which each contributes to the culture as a whole will be illustrated, and the divisions between them that affect the overall organization will be developed. Analysis of these roles and divisions is crucial to understanding identity, access, and mobility within the culture. Hacking In the vernacular of the computer underground, "hacking" refers to gaining access and exploring computer systems and networks. "Hacking" encompasses both the act and the methods used to obtain valid user accounts on computer systems. "Hacking" also refers to the activity that occurs once access to another computer has been obtained. Since the system is being used without authorization, the hacker does not, generally speaking, have access to the usual operating manuals and other resources that are available to legitimate users. Therefore, the hacker must experiment with commands and explore various files in order to understand and effectively use the system. The goal here is to explore and experiment with the system that has been entered. By examining files and, perhaps, by a little clever programming, the hacker may be able to obtain protected information or more powerful access privileges. Phreaking Another role in the computer underground is that of the "phone phreak." Phone phreaking, usually called just "phreaking," was widely publicized when the exploits of John "Cap'n Crunch" Draper, the "father of phreaking," were publicized in a 1971 Esquire magazine article. The term "phreaking" encompasses several different means of circumventing the billing mechanisms of telephone companies. By using these methods, long-distance phone calls can be placed without cost. In many cases the methods also prevent, or at least inhibit, the possibility of calls being traced to their source thereby helping the phreaker to avoid being caught. Early phreaking methods involved electromechanical devices that generated key tones, or altered line voltages in certain ways as to trick the mechanical switches of the phone company into connecting calls without charging. However the advent of computerized telephone-switching systems largely made these devices obsolete. In order to continue their practice the phreaks have had to learn hacking skills: Phreaking and hacking have just recently merged, because now, the telephone companies are using computers to operate their network. So, in order to learn more about these computers in relation to the network, phreaks have learned hacking skills, and can now program, and get around inside the machines (AF, message log, 1988). For most members of the computer underground, phreaking is simply a tool that allows them to call long distance without amassing enormous phone bills. Those who have a deeper and more technically oriented interest in the "telco" (telephone company) are known as phreakers. They, like the hackers discussed earlier, desire to master and explore a system that few outsiders really understand: The phone system is the most interesting, fascinating thing that I know of. There is so much to know. Even phreaks have their own areas of knowledge. There is so much to know that one phreak could know something fairly important and the next phreak not. The next phreak might know ten things that the first phreak doesn't though. It all depends upon where and how they get their info. I myself %sic% would like to work for the telco, doing something interesting, like programming a switch. Something that isn't slave labor bullshit. Something that you enjoy, but have to take risks in order to participate unless you are lucky enough to work for the telco. To have access to telco things, manuals, etc would be great (DP, message log, 1988). Phreaking involves having the dedication to commit yourself to learning as much about the phone system/network as possible. Since most of this information is not made public, phreaks have to resort to legally questionable means to obtain the knowledge they want (TP2, message log, 1988). Most members of the underground do not approach the telephone system with such passion. Many hackers are interested in the phone system solely to the extent that they can exploit its weaknesses and pursue other goals. In this case, phreaking becomes a means and not a pursuit unto itself. Another individual, one who identifies himself as a hacker, explains: I know very little about phones . . . I just hack. See, I can't exactly call these numbers direct. A lot of people are in the same boat. In my case, phreaking is a tool, an often used one, but nonetheless a tool (TU, message log, 1988). In the world of the computer underground, the ability to "phreak a call" is taken for granted. The invention of the telephone credit card has opened the door to wide-scale phreaking. With these cards, no special knowledge or equipment is required to phreak a call, only valid credit card numbers, known as "codez," are needed to call any location in the world. This easy access to free long-distance service is instrumental for maintaining contact with CU participants scattered across the nation. Pirating The third major role in the computer underground is that of the software pirate. Software piracy refers to the unauthorized copying and distribution of copyrighted software. This activity centers around computer bulletin board systems that specialize in "warez." There pirates can contribute and share copies of commercial software. Having access to these systems (usually obtained by contributing a copyrighted program via a telephone modem) allows the pirate to copy, or "download," between two to six programs that others have contributed. Software piracy is a growing concern among software publishing companies. Some contend that the illegal copying of software programs costs the industry billions of dollars in lost revenues. Pirates challenge this, and claim that in many ways pirating is a hobby, much like collecting stamps or baseball cards, and their participation actually induces them to spend more on software than they would otherwise, even to the point of buying software they don't truly need: There's a certain sense of, ahh, satisfaction in having the latest program, or being the first to upload a program on the "want list." I just like to play around with them, see what they can do. If I like something, I'll buy it, or try out several programs like it, then buy one. In fact, if I wasn't pirating, I wouldn't buy any warez, because some of these I buy I do for uploading or just for the fun of it. So I figure the software companies are making money off me, and this is pretty much the same for all the really elite boards, the ones that have the best and most programs. . . . I just bought a $117. program, an accounting program, and I have absolutely no use for it. It's for small businesses. I thought maybe it would autowrite checks, but it's really a bit too high powered for me. I thought it would be fun to trade to some other boards, but I learned a lot from just looking at it (JX, field notes, 989). Pirates and phreak/hackers do not necessarily support the activities of each other, and there is distrust and misunderstanding between the two groups. At least part of this distrust lies in the phreak/hacker perception that piracy is an unskilled activity. While p/hackers probably don't disapprove of piracy as an activity, they nevertheless tend to avoid pirate bulletin board systems --partly because there is little pertinent phreak/hack information contained on them, and partly because of the belief that pirates indiscriminately abuse the telephone network in pursuit of the latest computer game. One hacker illustrates this belief by theorizing that pirates are responsible for a large part of telephone credit card fraud. The media claims that it is solely hackers who are responsible for losses pertaining to large telecommunication companies and long distance services. This is not the case. We are %hackers% but a small portion of these losses. The rest are caused by pirates and thieves who sell these codes to people on the street (AF, message log, 1988). Other hackers complained that uploading large programs frequently takes several hours to complete, and it is pirate calls, not the ones placed by "telecommunications enthusiasts" (a popular euphemism for phreakers and hackers) that cost the telephone industry large sums of money. However, the data do not support the assertation that all pirates phreak their calls. Phreaking is considered "very tacky" among elite pirates, and system operators (Sysops) of pirate bulletin boards discourage phreaked calls because it draws attention to the system when the call is discovered by the telephone company. Regardless of whether it is the lack of phreak/hack skills, the reputation for abusing the network, or some other reason, there is indeed a certain amount of division between the world of phreakers and hackers and that of pirates. The two communities co-exist and share resources and methods, but function separately. Social Organization and Deviant Associations Having outlined and defined the activities of the computer underground, the question of social organization can be addressed. Joel Best and David Luckenbill (1982) have developed a typology for identifying the social organization of deviant associations. Essentially they state that deviant organizations, regardless of their actual type of deviance, will vary in the complexity of their division of labor, coordination among organization roles, and the purposiveness with which they attempt to achieve their goals. Those organizations which display high levels in each of these categories are more sophisticated than those with lower levels. Deviants relations with one another can be arrayed along the dimension of organizational sophistication. Beginning with the least sophisticated form, %we% discuss five forms of the social organization of deviants: loners, colleagues, peers, mobs, and formal organizations. These organization forms are defined in terms of four variables: whether the deviants associate with one another; whether they participate in deviance together; whether their deviance requires an elaborate division of labor; and whether their organization's activities extend over time and space (Best and Luckenbill, 1982, p.24). These four variables, also known as mutual association, mutual participation, elaborate division of labor, and extended organization, are indicators of the social organization of deviant groups. The following, taken from Best and Luckenbill, illustrates: FORM OF MUTUAL MUTUAL DIVISION EXTENDED ORGANASSOCIA- PARTICIPA- OF ORGANIZATION TION TION LABOR IZATION ----------------------------------------------------Loners no no no no Colleagues yes no no no Peers yes yes no no Mobs yes yes yes no Formal Organizations yes yes yes yes _____________________________________________________ (1982, p.25) Loners do not associate with other deviants, participate in shared deviance, have a division of labor, or maintain their deviance over extended time and space. Colleagues differ from loners because they associate with fellow deviants. Peers not only associate with one another, but also participate in deviance together. In mobs, this shared participation requires an elaborate division of labor. Finally, formal organizations involve mutual association, mutual participation, an elaborate division of labor, and deviant activities extended over time and space (Best and Luckenbill, 1982, pp.24-25). The five forms of organizations are presented as ideal types, and "organizational sophistication" should be regarded as forming a continuum with groups located at various points along the range (Best and Luckenbill, 1982, p.25). With these two caveats in mind, we begin to examine the computer underground in terms of each of the four organizational variables. The first level, mutual association, is addressed in the following section. Mutual Association Mutual association is an indicator of organizational sophistication in deviant associations. Its presence in the computer underground indicates that on a social organization level phreak/hackers act as "colleagues." Best and Luckenbill discuss the advantages of mutual association for unconventional groups: The more sophisticated the form of organization, the more likely the deviants can help one another with their problems. Deviants help one another in many ways: by teaching each other deviant skills and a deviant ideology; by working together to carry out complicated tasks; by giving each other sociable contacts and moral support; by supplying one another with deviant equipment; by protecting each other from the authorities; and so forth. Just as %others% rely on one another in the course of everyday life, deviants find it easier to cope with practical problems when they have the help of deviant associates (1982,pp.27-28). Hackers, phreakers, and pirates face practical problems. For example, in order to pursue their activities they require equipment and knowledge. The problem of acquiring the latter must be solved and, additionally, they must devise ways to prevent discovery , apprehension and sanctioning by social control agents. One method of solving these problems is to turn to other CU members for help and support. Various means of communication have been established that allow individuals to interact regardless of their location. As might be expected, the communication channels used by the CU reflect their interest and ability in high-technology, but the technical aspects of these methods should not overshadow the mutual association that they support. This section examines the structure of mutual association within the computer underground. The Structure of the Computer Underground Both computer underground communities, the p/hackers and the pirates, depend on communications technology to provide meeting places for social and "occupational" exchanges. However, phreakers, hackers, and pirates are widely dispersed across the country and, in many cases, the globe. In order for the communication to be organized and available to participants in many time zones and "working" under different schedules, centralized points of information distribution are required. Several existing technologies --computer bulletin boards, voice mail boxes, "chat" lines, and telephone bridges/loops -have been adopted by the CU for use as communication points. Each of these technologies will be addressed in turn, giving cultural insight into CU activities, and illustrating mutual association among CU participants. Bulletin Board Systems Communication in the computer underground takes place largely at night, and primarily through Bulletin Board Systems (BBS). By calling these systems and "logging on" with an account and password individuals can leave messages to each other, download files and programs, and, depending on the number of phone lines into the system, type messages to other users that may be logged on at the same time. Computer Bulletin Board Systems, or "boards," are quite common in this computerized age. Nearly every medium-sized city or town has at least one. But not all BBS are part of the computer underground culture. In fact, many systems prohibit users from discussing CU related activity. However, since all bulletin boards systems essentially function alike it is only the content, users, and CU culture that distinguish an "underground" from a "legitimate" bulletin board. Computer Underground BBS are generally owned and operated by a single person (known as the "system operator" or "sysop"). Typically setup in a spare bedroom, the costs of running the system are paid by the sysop, though some boards solicit donations from users. The sysop maintains the board and allocates accounts to people who call the system. It is difficult to assess the number of underground bulletin boards in operation at any one time. BBS in general are transitory in nature, and CU boards are no exception to this. Since they are operated by private individuals, they are often set up and closed down at the whim of the operator. A week that sees two new boards come online may also see another close down. A "lifetime" of anywhere from 1 month to 1-1/2 years is common for pirate and phreak/hack boards. One BBS, claimed to be the "busiest phreak/hack board in the country" at the time, operated for less than one year and was suddenly closed when the operator was laid off work. Further compounding the difficulty of estimating the number of CU boards is their "underground" status. CU systems do not typically publicize their existence. However, once access to one has been achieved, it is easy to learn of other systems by asking users for the phone numbers. Additionally, most BBS maintain lists of other boards that users can download or read. So it is possible, despite the difficulties, to get a feel for the number of CU boards in operation. Pirate boards are the most common of "underground" BBS. While there is no national "directory" of pirate boards, there are several listings of numbers for specific computer brands. One list of Apple pirate boards has 700 entries. Another, for IBM boards, lists just over 500. While there is no way of determining if these lists are comprehensive, they provide a minimum estimate. Pirate boards for systems other than IBM or Apple seem to exhibit similar numbers. David Small, a software developer that has taken an aggressive stance in closing down pirate boards, estimates that there are two thousand in existence at any one time (1988). Based on the boards discovered in the course of this research, and working from an assumption that each of the four major brands of microcomputers have equal numbers of pirate boards, two thousand is a reasonable estimate. The phreak/hack BBS community is not divided by differing brands of micro-computers. The applicability of phreak/hack information to a wide range of systems does not require the specialization that pirate boards exhibit. This makes it easier to estimate the number of systems in this category. John Maxfield, a computer security consultant, has asserted that there are "thousands" of phreak/hack boards in existence (WGN-Radio, November 1988). The data, however, do not confirm this. A list of phreak/hack boards compiled by asking active p/hackers and downloading BBS lists from known phreak/hack boards, indicates that there are probably no more than one hundred. Experienced phreak/hackers say that the quality of these boards varies greatly, and of those that are in operation today only a few (less than ten) attract the active and knowledgeable user. Right after "War Games" came out there must have been hundreds of hacker bulletin boards spring up. But 99% of those were lame. Just a bunch of dumb kids that saw the movie and spent all there %sic% time asking "anyone got any k00l numberz?" instead of actually hacking on anything. But for a while there was %sic% maybe ten systems worth calling . . . where you could actually learn something and talk to people who knew what was going Nowadays %sic% there are maybe three that I consider good . . . and about four or five others that are okay. The problem is that anybody can set up a board with a k-rad name and call it a hacker board and the media/feds will consider it one if it gets busted. But it never really was worth a shit from the beginning.(TP2, field notes, 1989) Towards a BBS Culture. Defining and identifying CU boards can be problematic. The lack of an ideal type undoubtedly contributes to the varying estimates of the number of CU bulletin board systems. While developing such a typology is not the intent of this work, it is appropriate to examine the activities and characteristics exhibited by BBS supporting the pirate and phreak/hack communities. While much of the culture of pirate and phreak/hack worlds overlap, there are some differences in terms of how the BBS medium is used to serve their interests. We begin with a short discussion of the differences between the two communities, then discuss cultural characteristics common to all CU BBS systems. All BBS feature a "files area" where programs and text files are available for downloading by users. Initially these programs/files are supplied by the system operator, but as the board grows they are contributed (called "uploading") by callers. The content and size of the files area differs according to whether the board supports the pirate or phreak/hack community. The files area on a pirate board consists primarily of programs and program documentation. Normally these programs are for only one brand of micro-computer (usually the same as the system is being run on). Text files on general or non-computer topics are uncommon. A "files area" menu from a pirate BBS illustrates the emphasis on software: %1% Documentation %2% Telecommunications %3% Misc Applications %4% Word Processing %5% Graphics %6% Utilities %7% Games 1 %8% Games 2 %9% XXX Rated %10% Elite_1 %11% Elite_2 %12% Super_Elite (IN BBS, message log, 1988) The "files area" on a phreak/hack BBS is noticeably smaller than it is on pirate systems. It consists primarily of instructional files (known as "g- files" for "general files") and copies of phreak/hack newsletters and journals. Pirated commercial software is very rare; any programs that are available are usually non-copyrighted specialized programs used to automate the more mundane aspects of phreaking or hacking. It is not uncommon to find them in forms usable by different brands of computers. A "files area" list from a phreak/hack BBS is listed here (edited for size): Misc Stuff ------------BRR2 .TXT: Bell Research Report Volume II BRR1 .TXT: Bell Research Report Volume I CONFIDE .ARC: Confide v1.0 DES EnCryption/DeCryption CNA .TXT: A bunch of CNA numbers CLIPS .ARC: newsclippings/articles on hackers and busts ESS1 .TXT: FILE DESCRIBING THE ESS1 CHIP TELEPHON.TXT: NY Times Article on hackers/phreaks HP-3000 .TXT: This tells a little info about hp VIRUS .TXT: Digest of PC anti-viral programs. Hack/Phreak Programs ----------------------THIEF .ARC: Code Thief for IBM! PC-LOK11.ARC: IBM Hard Disk Lock Utility- fairly good. PHONELIS.COM: Do a PHONE DIR command on VAX from DCL. XMO .FOR: VAX Xmodem Package in FORTRAN PASSWORD.ARC: IBM Password on bootup. Not too bad. Archived Gfiles ---------------------PHRACK15.ARC: Phrack #15 PHRACK10.ARC: Phrack #10 PHRACK20.ARC: Phrack #20 ATI1_6.ARC : ATI issues one thru six PHRACK5.ARC : Phrack #5 PHRACK25.ARC: Phrack #25 PHUN1.ARC : P/Hun first issue TCSJ.ARC : Telecom Security Journal ATI31.ARC : Activist Times Inc number 31 LODTECH3.ARC: LoD Tech Journal three (TPP BBS, message log, 1988) The difference in files area size is consistent with the activities of pirates and phreak/hackers. The main commodity of exchange between pirates is, as discussed earlier, copyrighted software thus accounting for the heavy use of that area of the board that permits exchange of programs. The phreak/hackers, on the other hand, primarily exchange information about outside systems and techniques. Their interests are better served by the "message bases" of BBS. The "message bases" (areas where callers leave messages to other users) are heavily used on phreak/hack systems. The messages are not specific to one brand of micro-computer due to the fact that not all users own the same equipment. Rather than focus on the equipment owned by the phreak/hacker, the messages deal with their "targets." Everything from phreak/hacking techniques to CU gossip is discussed. On some boards all the messages, regardless of topic, are strung together in one area. But on others there are separate areas dealing with specific networks and mainframe computers: Message Boards available: 1 : General 2 : Telecommunications 3 : Electronics 4 : Packet Switched Nets 5 : VAX/DEC 6 : Unix 7 : Primos 8 : HP-x000 9 : Engineering 10 : Programming & Theory 11 : Phrack Inc. 12 : Sociological Inquiries 13 : Security Personnel & Discussion 14 : Upper Deck 15 : Instructors (TPP BBS, message log, 1988) The pirate community, on the other hand, makes little use of the "message bases." Most users prefer to spend their time (which may be limited by the system operator on a per day or per call basis) uploading and/or downloading files rather than leaving messages for others. Those messages that do exist are usually specific to the pirating enterprise such as help with programs on the board, requests for specific programs ("want lists"), and notices about other pirate bulletin boards that users may want to call. Occasional discussion of phreaking may occur, but the emphasis is on techniques used to make free calls, not technical network discussions as often occurs on phreak/hack systems. A list of message areas from a large pirate BBS illustrates the emphasis on the pirating enterprise. A message area for general discussions has been created, but those areas devoted to pirating display more use: Area Area Area Area %1% %2% %3% %4% General Discussion Pirating Only!! Warez Wants **private messages** 15 75 31 10 messages messages messages messages (TL BBS, message log, 1988) In addition to the differences between files and message use on pirate and phreak/hack boards, they differ in degree of community cohesiveness. Every BBS has a group of "users" --the people who have accounts on the system. The group of users that call a specific BBS can be considered to be a "community" of loosely associated individuals by virtue of their "membership" in the BBS. Additionally, the system itself, serving either pirates or phreak/hackers, exists within a loose network of other bulletin boards that serve these same interests. It is within this larger community where pirate and phreak/hack boards seem to differ. Due to the brand-specific nature of pirate boards there is not a strong network between pirate BBS that operate on other systems. This is understandable as a pirate that owned an Apple computer would have little use for the programs found on an IBM board. However, this creates separate communities of active pirates, each loosely associated with other users of their computer type, but with little or no contact with pirate communities on other systems. There is, however, a degree of cohesiveness among pirate boards that support the same microcomputers. While the users may be different on systems, the data shows that some pirate boards are "networked" with each other via special software that allows messages and files to be automatically shared between different boards. Thus a message posted on a west coast pirate board will be automatically copied on an east coast BBS later that night. In a like manner, software programs can be sent between "networked" boards. The extent of this network is unknown. The pirate BBS community also exhibits cohesiveness in the form of "co-sysops." As discussed earlier, sysops are the system operators and usually owners of BBS. On some pirate boards, "cosysop" distinction is given to an operator of another board, often located in another state. This forms a loose network of "sister boards" where the sysop of one has co-sysop privileges on the other. However, this cooperative effort appears to be limited mainly to the system operators as comparing user lists from sister boards shows little overlap between the regular callers. How co-sysop positions are utilized is unknown, and it is suspected that they are largely honorary. But nonetheless it is indicative of mutual association between a small number of boards. The phreak/hack board community does not exhibit the same brand-specific division as the pirate community. Unlike the divided community of pirates, phreak/hackers appear to maintain contacts throughout the country. Obtaining and comparing user lists from several phreak/hack BBS reveals largely the same group of people using several different boards across the country.While phreak/hack boards have yet to adopt the "networking" software used by pirate boards, an active group of phreak/hackers is known to use the sophisticated university mainframe computer network, called Bitnet, to exchange phreak/hack newsletters and gossip. Despite the operational differences between pirate and phreak/hack boards, their cultures are remarkably similar. Any discussion of the computer underground must include both communities. Additionally, a formulation of the culture of CU BBS must address the means in which access to the board, and thus deviant associates, is obtained. For a caller to successfully enter the CU BBS community, he must display an awareness of CU culture and technical skill in the CU enterprise. If the caller fails to exhibit cultural knowledge, then access to the board is unlikely to be granted. The ways in which this cultural knowledge is obtained and displayed illustrates the social nature of the CU and further displays some of the subcultural norms of behavior. On most "licit" (non-underground) boards, obtaining permission to use the system is accomplished by logging on and providing a name and home phone number to the system operator (sysop). Sysop's normally do not check the validity of the information, and once a caller has provided it he or she is granted full access to the system. There is normally one level of access for all users, with only the sysop having more "powerful" access. Obtaining access to underground bulletin boards is more complicated and requires more steps to complete. In an attempt to prevent law enforcement agents ("feds") from obtaining accounts on systems where pirates or p/hackers are vulnerable, if not to actual arrest, then at least to exposing their latest activities and methods, sysop's of illicit boards attempt to limit access to the system. One method of doing this is to restrict publicizing the existence of the board. Computer underground BBS are not normally included in BBS listings found in computer books and magazines, and there is a norm, particularly strong on p/hack systems, that the boards are not to be mentioned on non-CU systems. There are, however, some "entry-level" CU BBS that are fairly well known. These systems are known as "anarchist" boards. "Anarchist" boards, while exhibiting many of the same characteristics as pirate and phreak/hack boards, are really a cross between the two and serve primarily as social outlets for both pirates and phreak/hackers. The message areas on "anarchist" boards are quite active, "chatty" messages are not discouraged. Indeed there are normally several different message areas devoted to a wide range of topics including everything from "skipping school" to "punk rock." The files area contains both warez (but normally only the newest games, and specific to the computer system that the board runs on) and phreak/hack text files. Neither collection is as extensive as it would be on pirate- only or p/hack-only systems. The data suggest that one function of "anarchist" boards is to introduce newcomers to the culture of the computer underground. By acting as "feeder boards," they can provide preliminary socialization and instruction for CU behavior and techniques. Additionally, "anarchist" boards frequently provide areas where phone numbers to pirate and p/hack systems can be traded, thus providing systems where more in-depth information, and other contacts, can be found. A phreak/hacker describes how an "anarchist" board was instrumental in introducing him to the computer underground: I've been phreaking and hacking for about four years now. I discovered phreaking on my own at this place I used to work. We had this small LD %long distance% provider that used codez so I started hacking them out and calling places myself . . . but I didn't know no other phreaks at that time. Then I started using the codez to call boards from home on my computer. Somebody gave me the number to Jack Black's Whore House %an "anarchy board"% and I started learning about hacking and shit from the people and philes they had there. Then one day this guy, King Hammer, sent me some e-mail %a private message% and told me to call his system. That's where I really learned my way around the nets and shit. You could ask questions and people would help you out and stuff. If I hadn't found out some of the tricks that I did I probably would have got busted by now. (TP2, field notes, 1989) Once an individual has obtained the telephone number to a CU BBS, through whatever channels, callers follow essentially the same procedure as they do on licit systems . . . that of calling and logging on. However, since "underground" boards are not truly underground (that is, totally secret) first-time callers are not given access to the board itself. When a user is unable to provide an already valid username/password, the system will automatically begin its registration procedure. First, the caller is asked to enter a "username" (the name used by the system to distinguish between callers) and "phone number." These first system requests, normally seen only as "Enter Your Name and Phone Number," serve as partial screens to keep out non-underground callers that may have happened across the board. The way that a user responds to these questions indicates if they have cultural knowledge of the CU. The norm is to enter a pseudonym and a fake phone number.15 If a caller enters his or her real name (or at least a name that does not appear to be a pseudonym) the system operator will be put on guard that the caller may not be aware of the type of board that he has called, for the pseudonym is the most visible of CU cultural traits. All members of the underground adopt "handles" to protect their identity. The pseudonyms become second identities and are used to log onto bulletin boards, and as "signatures" on messages and instructional text files. They are not unlike those adopted by citizens-band radio users, and reflect both the humor and technical orientation of computer underground participants. A review of handles used by phreakers, hackers, and pirates finds that they fall into three broad categories: figures from literature, films, and entertainment (often science fiction); names that play upon computers and related technologies; and nouns/descriptive names. (See Appendix A for fictional examples of each.) After providing a user name and entering a password to be used for future calls, the caller is asked several more questions designed to screen users and determine initial access privileges. Unlike licit boards, underground BBS may have several different levels of access with only the most trusted users being able to read messages and get files in "elite" or "high access" areas that are unknown and unavailable to other callers. In many cases, pirate boards are able to operate "above ground" and appear to be open-public access systems unless callers have the proper privileges to access the areas where the "good stuff" is located. The answers given to access questionnaires determine whether a caller will receive access to some, all, or none of the higher levels. These questionnaires frequently ask for "personal references" and a list of other boards the caller has "high access" on. The question is vague, and random callers are unlikely to answer it correctly. However, if the caller lists pseudonyms of other CU members that are known and trustworthy to the sysop, as well as some other boards that are known to have "good users" and "good security" access will usually be granted. If all the answers are relevant and indicative of CU knowledge, then initial access is normally granted. Other methods of controlling access include presenting a "quiz" to determine if the technical knowledge of the user is up to par with the expertise expected on the boards.18 Some systems, instead of a quiz, ask the user to write a short statement (100 words or less) about why they want access, where they got the phone number to the system, and what they can provide to other users. Some pirate boards come right out and ask the user to supply a list of the good "warez" that they can upload and what they are looking to download. If the caller fails to list recent copyrighted programs then it is evident that they are unaware of the nature of the BBS: I had this one dude call up and he told me in his message that he was looking for some "good games." So instead of giving him access I just left him some e-mail %a private message%. I asked what kind of games he was looking for. Next time he called he wrote back and said "a public domain Asteroids game." I couldn't believe it. Not only is Asteroids so damn old it's lame, but this guy is looking for pd %public domain% shit. No way was he going to get access. He didn't even know what this board is. I left him a message telling him that I didn't have one. He never called back after that (CH, sysop of a pirate BBS, field notes, 1988). Ironically, the pseudo-elaborate security methods of underground boards, while they may be effective in keeping off random non-CU callers, are not effective in screening out "feds." Data and media accounts show that boards are regularly infiltrated by telephone security personnel and software companies. Also, the adoption of handles to protect identities is defeated by the consistent use of the same handle over time. But in order to obtain and maintain status and prestige in the CU one must keep the same pseudonym in order to (literally) "make a name for oneself." The fact that CU communication is not face-to-face requires a consistent means of identifying oneself to others. The handle fulfills this purpose but at the same time becomes as attached to a single individual as a real name would. The access rituals of the computer underground, which are contingent on being a "known" pirate or phreak/hacker, make changing handles unproductive. The life blood and center of the computer underground is the bulletin board network. Acting as both the main trade center of performance related tools and innovations and as a means of socialization, the underground could not exist without the BBS network. They serve to "recruit" and educate newcomers and provide a way to traffic in information and software. The pirating enterprise in particular is very dependent upon the BBS as they are the very means by which "warez" are traded. For the phreak/hacker community, BBS provide a means of trading the resources of system numbers and passwords, as well as instructional texts on techniques. The access process serves as evidence of mutual association amongst phreakers, hackers, and pirates as cultural knowledge is needed as well as personal references (evidence of acceptance and access to others). The CU bulletin board systems are unique in that they provide a way to exchange information with a large number of others. The other methods of CU communication are based on conversations rather than written texts and thus are much less permanent. These methods, discussed next, are telephone bridges/loops, voice mail boxes, and computer "chat" systems. Bridges, Loops, and Voice Mail Boxes Of the additional means of communication used by the CU, telephone "bridges" and "loops" are most common. Unlike BBS, which require data links provided by a computer and modem, bridges and loops are "old fashioned" voice connections. Since they can not accommodate the transfer of programs or files they are used primarily by phreakers and hackers, and most often as a social/recreational outlet. A "bridge" is a technical name for what is commonly known as a "chat line" or "conference system." They are familiar to the public as the pay-per-minute group conversation systems advertised on late night television. Many bridge systems are owned by large corporations who maintain them for business use during the day. While the numbers to these systems is not public knowledge, many of them have been discovered by phreaks who then utilize the systems during the night. In addition to these pre-existing conference systems, phreakers have become skilled at arranging for a temporary, private bridge to be created via AT&T's conference calling facilities. This allows for conversations to be held among a self-selected group of phreak/hackers: Bridges can be %sic% extremely useful means of distributing information as long as the %phone% number is not known, and you don't have a bunch of children online testing out their DTMF.The last great discussion I participated with over a bridge occurred about 2 months ago on an AT&T Quorum where all we did was engineer 3/way %calls% and restrict ourselves to purely technical information. We could have convinced the Quorum operators that we were AT&T technicians had the need occurred. Don't let the kids ruin all the fun and convenience of bridges. Lameness is one thing, practicality is another (DC, message log, 1988). In addition to setting up "private" bridges, p/hackers can utilize "loop lines" in a further attempt to limit the number of eavesdroppers on their conversations. Unlike bridges, which connect a virtually unlimited number of callers at once, "loops" are limited to just two people at a time. "Loop lines" are actually telephone company test lines installed for internal use.21 A loop consists of two separate telephone numbers that connect only to each other. Each end has a separate phone number, and when each person calls one end, they are connected to each other automatically. This allows for individuals to hold private conversations without divulging their location or identity by exchanging telephone numbers. Finally, voice mail boxes ("VMB") are another means of communicating with individual actors. There are several commercial voice mail box systems located throughout the country. They function similar to a telephone answering machine in that callers can call in, listen to a recorded message, and then leave a message for the box owner. Many of these systems are accessible via toll-free telephone numbers. The security of some VMB systems is notoriously poor. Many phreaks have expertise in "creating" boxes for themselves that are unknown (until discovered) by the owner of the system. However, these boxes are usually short lived since discovery by the system operator, and closure of the box, is only a matter of time. But as long as the box is functioning, it can serve as a means of communicating with others. VMB numbers are frequently posted on bulletin boards with invitations to "call if you have any good stuff." They are often used by pirates to exchange messages about new releases of software, and by phreak/hackers to trade account and access numbers. Additionally, some of the underground newsletters and journals obtain boxes so users can call in news of arrests and other gossip. Like bulletin boards, VMBs are systems that allow information to be disseminated to a large number of associates, and unlike the live telephone conversations of bridges and loops, they are available at any time of the day. Additionally, VMB's don't require use of a computer and modem, only a touch tone phone is needed to call the box. Their usefulness is limited somewhat because they play only one "outgoing" message at a time, and their transitory nature limits their reliability. Summary Phreakers, hackers and pirates do not act as loners. They have adopted existing methods of communication, consistent with their skills in high technology, to form a social network that allows for the exchange of information, the socialization of new members, socializing with others, and in the case of pirates, performing the "deviant" act itself via these means. These communication points create and foster groups of loosely associated individuals, with specific interests, coming together to exchange information and/or software. It is impossible to be a part of the social network of the computer underground and be a loner. Based upon the Best and Luckenbill measure, actors in the computer underground, by displaying mutual association, organize as colleagues. The social network of the computer underground provides the opportunity for colleagues to form cooperative working relationships with others, thus moving the CU towards a more sophisticated form of social organization. These "hacker groups" are addressed in the next section. Mutual Participation In the previous chapter the ways in which the structure of the computer underground fosters mutual association were discussed. Their social outlets and means for informational exchange bring the CU community together as deviant colleagues. Their relationships fit quite well into the Best and Luckenbill (1982) typology of collegial associations: The relationship between deviant colleagues involves limited contact. Like loners, colleagues perform their deviant acts alone. But unlike loners colleagues associate with one another when they are not engaged in deviance . . . In effect, there is a division between two settings; onstage where individual performs alone; and backstage, where colleagues meet (cf Goffman). In their backstage meetings, colleagues discuss matters of common interest, including techniques for performing effectively, common problems and how to deal with them, and ways of coping with the outside world (1982 p.37). However, despite the advantages of collegial association, ties between CU participants are weak. Loyalty between individuals seems rare, as the CU is replete with tales of phreak/hackers who, when apprehended, expose identities or "trade secrets" in order to avoid prosecution. These weak collegial ties may be fostered by the anonymity of CU communication methods, and the fact that all CU actors are, to some extent, in competition with each other. There are only so many systems with weak security and once such a system is found, sharing it with others will virtually ensure that the hole will be sealed when the increased activity is noticed. Thus while p/hackers will share general knowledge with each other, specific information is not disseminated publicly. As Best and Luckenbill have observed, in order to remain in a collegial relationship individuals must be able to successfully carry out operations alone (1982 p.45). In order to sustain a career in p/hacking one must pursue and collect information independent of what is shared on the communication channels. Despite the association with other phreakers and hackers, the actual performance of the phreak/hacking act is a solitary activity. That is not to say, however, that p/hackers never share specific information with others. As discussed earlier, p/hack bulletin board systems frequently have differentiated levels of access where only highly regarded individuals are able to leave and read messages. These areas are frequently used to keep information from "unskilled" users at the lower levels. There are strong social norms that some information should not be shared too widely, as it may be either "abused" or fall into the hands of enforcement agents. For example, when one p/hacker announced that he was going to release a tutorial on how to infiltrate a new telephone company computer, he received the following messages in reply: Not smart, DT. %That computer% is a system which can be quite powerful if used to its potential. I don't think that information on programming the switches should be released to anyone. Do you realize how destructive %that computer% could really be if used by someone who is irresponsible and intends on destroying things? Don't even think about releasing that file. If you do release that file, it will disappear and will no longer remain in circulation. Believe me. Not many have the right to know about %that computer%, or any other delicate telco computers for that matter. Why do you think the fucking New York Times published that big article on hackers screwing around with telco machines? Not only will you get into a lot of trouble by releasing that file on %computer%, you will be making telcos more aware of what is actually happening, and soon no one will be able to learn about their systems. Just think twice (EP, message log, 1988). Why would you want normal people to have such knowledge? Any why would you post about it? If you have knowledge that's fine but DON'T spread that knowledge among others that may abuse it. It's not impressive! I don't know why anyone would want to disperse that knowledge. Please don't release any "in depth" files on such systems of great power. Keep that to yourself it will just mess it up for others (UU, message log, 1988). The desire to share information with selected colleagues often leads to the formation of cooperative "working groups." These partnerships are easily formed, as the structure of mutual association in the CU creates a means where "talent" can be judged on the basis of past interactions, longevity in the field, and mutual interests. When allegiances are formed, the CU actors begin "mutual participating" in their acts, thus becoming "peers" in terms of social organization. Mutual participation, as defined in the Best and Luckenbill typology, is exhibited by actors sharing in the same deviant act, in the physical presence of one another (1982 p.45). However, the measurement was "grounded" in studies of traditional deviant associations (eg: street gangs, prostitutes, etc.) where "real-time" interaction is common. The technology used by the CU negates this requirement as actors can be located in different parts of the country. Additionally, "hacking" on a system, by a group of peers, does not require simultaneous participation by all members. However Best and Luckenbill's typology is an ideal type, and the activities of peers in the computer underground do not fall outside of the spirit or intention of their concept of mutual participation. Their description of deviant peer associations is presented here: Deviant peers are distinguished from colleagues by their shared participation in deviance. While colleagues carry out their deviant operations alone, peers commit deviant acts in one another's presence. Peers cooperate in carrying out deviant operations, but they have a minimal division of labor, with each individual making roughly comparable contribution. Peer relationships also tend to be egalitarian and informal; some peers may be acknowledged leaders or admired for their skill, but there is no set division of authority. Like colleagues, peers share subcultural knowledge, but peer groups typically provide their members with more support. In addition to cooperating in deviant operations, peers may recruit and socialize newcomers and supply one another with deviant equipment and social support. Thus, the bonds between peers are stronger than those linking colleagues (1982, p.45). Peer associations in the CU are largely limited to small groups23 working on a specified goal. Both pirates and p/hackers organize themselves in this regard, though their characteristics differ. We begin with a discussion of mutual participation among pirates. Pirate Groups Pirate groups are composed of less than ten members. Their primary purpose is to obtain the latest software, remove any copy-protection from it, and then distribute it to the pirate community. Often the "warez" that they distribute will be adorned with the group name, so subsequent users will be aware of the source of the software. Many pirate groups have "home" BBS systems that act as key distribution points, and as places where outsiders can communicate with members of the association. This researcher was unable to obtain data about the internal organization of pirate groups, but it appears that they are leaderless, with individual members working alone but giving credit to the group as a whole. Phreak/hack groups The existence of phreak/hacker groups is well documented in the data, and has been heavily reported in the media. Two hacker groups in particular, The 414's (named for the Wisconsin area code in which they lived), and The Inner Circle, received a large amount of press after being apprehended for various computer break-ins. However, the "threat" that such groups represent has probably been overstated as the data indicate that "hacker gangs" vary greatly in organization and dedication to the CU enterprise. Many hacker groups are short-lived associations of convenience, much like the "no girls allowed!" clubs formed by young boys. They often consist of four to nine beginning phreak/hackers who will assist each other in obtaining telephone credit-card numbers. By pooling their resources, a large number of illicit "codez" can be obtained and shared with others. Distribution of the account numbers is not limited to the group, they are often shared with the community at large, "courtesy of Codez Kidz Ltd." Groups of this type are looked at with disdain by "elite" phreak/hackers and are often criticized as being more interested in self-promotion then they are with actually phreaking or hacking. Some hacker groups are very proficient and dedicated to their craft, however. These groups are characterized by smaller memberships, less visibility to non-members, and commitment to the CU enterprise. They are loosely organized, yet some have managed to exist six or more years despite members dropping out or being arrested. These "elite" groups are selective about membership, and cite trust and talent as the two leading requirements for joining: The group exists mainly for information trading. If you trust everyone else in the group, it is very profitable to pool information on systems . . . also it is nice to know someone that you can call if you need help on operating system X and to have people feel free to call you if they need help on operating system Y (AN, message log, 1988). Trust is a very important part of a group. I think that's blatantly obvious. You have to be able to trust the other members of the group with the information you are providing in order to be productive, and have a secure situation (UU, message log, 1988). . . . all groups serve the same purpose: to make their members feel better about themselves (like, wow, I'm in a group) and to trade things, whether it's wares, codes, or whatever. But the thing is that being in a group is like saying "I trust you, so like, what can we do together?" (NN, message log, 1988) Indeed, hacker groups are formed primarily for the purpose of information exchange. To this end, groups attempt to recruit members with a wide variety of "specializations" in order to have a better support network to turn to: %Our group% has always been very selective about members (took me six years to get in). The only reason the group exists is to bring together a diverse group of talents. There is very little overlap in %the group% these days. Everyone has one thing that they are the best in the country at, and are conversant with just about any other form of hacking. As an example, I got into a Primos computer this morning around 9 am. Once I got in, I know enough about Primos to get around, but that's it. So I call %PS% in New York, give him the info, and when I get home tonight, he has gotten in and decrypted the entire username/password file and uploaded it to me. But two weeks ago he got into a VAX. He got the account to me, I called it up and set up three backdoors into the system that we can get in if the account is detected or deleted. Simple matter of communism. From each according to his ability . . . etc. Also it helps that everyone in the group is experienced enough that they don't fuck up accounts you spend all day getting (TM, field notes, 1989). Consistent with the Best and Luckenbill ideal type, hacker groups do not exhibit a set division of authority or labor. Most groups are leaderless, and every member is free to pursue their own interests, involving other members of the group only when desired: We just got our group together. We've got a guy that does VMB's and a Sprinter %obtains "codez" from U.S. Sprint% and a couple of hackers. Everybody's free to pursue whatever system they want but if they want or need some help they can call on any of the other members if they want to. Like if one guy is scanning and finds a VAX he might call and give me the dialup. Then I might have to call our Sprinter to get some codez so I can start hacking on it. Once I get through I'll give the account to the other members. But if I found it myself I wouldn't have to give it out but I probably would anyway 'cuz keeping it would be bullshit (DC, field notes, 1988). There isn't a leader really. The guy who starts the group sort of acts like a contact point but everyone else has everyones' phone number and you can call whoever you want to anytime. Usually when you're putting a group together you just get everyone you want and you all decide on a name. (DC, field notes, 1988). Summary By virtue of the extensive social network found in the CU, some participants form work groups. The sophistication of these groups varies, but in all cases it is evident that the groups exist to support what are primarily individually performed activities. The groups exhibit many of the ideal-type characteristics of peer associations, and it is clear that in some cases the computer underground is socially organized as peers. Conclusion Phreakers, hackers, and pirates do not act as loners. Loners do not associate with others, and are on their own in coping with the practical problems presented by their activities (Best and Luckenbill 1982, p.28). From the data presented here, it is evident that the computer underground has established an extensive social network for the exchange of resources and mutual support. The characteristics of the CU varies according to the goals of the participants, but the presence of mutual association is consistent. Contact between individuals is limited, with the acts of phreaking or hacking being committed alone. Computer underground participants do associate with one another in order to discuss matters of common interest, such as performance techniques, news, and problem solving. To facilitate this informational exchange, they have established a technologically sophisticated network that utilizes computer bulletin boards, voice mail boxes, telephone bridges, and telephone loops. The collegial organization of the computer underground is further evidenced by the establishment of a CU culture. The subcultural adaptation of language, expectations of normative conduct, and status stratification based on mastery of cultural knowledge and skill, all indicate that the computer underground is, at the very least, a social organization of colleagues (see Best and Luckenbill, 1982, p.37). The very structure that permits mutual association among CU participants also encourages some to form working relationships, thus acting as peers by mutually participating in CU activities. Peers organized in this manner share in their deviance, organizing informally with little division of labor or set division of authority (Best and Luckenbill, 1982, p.45). These peer associations provide support to members, and can provide socialization and recruitment functions for newcomers. The establishment of work groups, through mutual participation, indicates that though the computer underground is largely organized as a network of colleagues, it is also, to some degree, a social organization of peers. Best and Luckenbill (1982) describe two additional forms of deviant associations that are more organizationally sophisticated than peers: "mobs" and "formal organizations." The computer underground, however, does not display the requisite characteristics of these organizational types. The primary characteristic of "mobs" is an elaborate division of labor (Best and Luckenbill, 1982, p.25). While some CU groups do exhibit a rudimentary division of labor based on individual members' specialization, it is not by any means "elaborate." Any division of labor that does exist is voluntary and arises on the basis of specialized knowledge, not a specialized organizational role. In much the same manner the lack of a designated leader or leadership hierarchy prevents CU groups from being categorized as "formal organizations" in the Best and Luckenbill typology. Deviant organizations at this level are quite sophisticated and there is no empirical evidence that the computer underground is organized in this manner. This study of the computer underground has been a test of the Best and Luckenbill typology of the social organization of deviants. As a test of their organizational indicators, the CU has shown that the categories are well constructed, with the possible exception of limiting "mutual participation" to acts carried out in the presence of others. However, if we modify this to include non-simultaneous, but cooperative, acts as found in phreak/hacker groups, the category is otherwise robust. The flexibility of the typology, which explicitly recognizes that not all deviant associations will display all of the characteristics (Best and Luckenbill, 1982, p.25), is a strength that allowed it to be easily used in terms of the computer underground. By addressing the CU from a social organizational viewpoint we have seen that despite the high technology trappings of their craft, pirates, phreakers, and hackers display organizational characteristics found in other groups that have been criminalized. This may suggest that the development of sophisticated tools to commit "crime" does not necessarily affect the ways in which individuals organize their activities. The implications of peer and collegial organization for the members of the computer underground are vast. The level of sophistication has a direct relationship to the types of resources on which individuals can draw (Best and Luckenbill, 1982, p.54). Because CU members are mutually associated, they are able to turn to colleagues for advice and support with various problems. However, at the collegial level they are left to enact the solutions independently. Whether or not they are successful in doing so will determine if they choose to remain active in the computer underground. The data show that involvement in the CU is short in duration, unless success in early phreak/hack attempts is obtained. As long as the CU remains organized as a collection of colleagues, this trend will continue. Additionally, as the computer and telephone industries become more sophisticated in preventing the unauthorized use of their facilities, new phreak/hackers are unlikely to succeed in their initial attempts at the act, thus dropping away from the activity and never becoming acculturated to the point where peer relationships can be developed. At the peer level, a dimension of sophistication that some members of the CU do display, the knowledge and resources to solve problems and obtain resources is greater. However, even at this level the ties between peers remain weak at best. Although their cooperative ties allow for more sophisticated operations, and somewhat reduce the CU's vulnerability to social control agents (Best and Luckenbill, 1982, p.53), it still does not completely eliminate the need for individual success in order to sustain a CU career. As long as the CU remains at the current level of organizational sophistication, with weak ties and somewhat limited means of support and resource attainment, it will continue to be a transitory and limited "criminal" enterprise. This realization should be considered by policy makers who desire to further criminalize computer underground activities. Given the current organization of the CU, the future social costs of their actions are not likely to expand beyond the current level. There is no evidence to support assertions that the CU is expanding, and the insight provided here shows that it is not likely to do so on a large scale. For sociologists, the computer underground is a field rich for insight into several areas of concern. Future research into the career path of CU members, and the relationships between individuals, could prove helpful to those interested in applying theories of differential association and career deviance. Additionally, the computer underground provides a unique opportunity to study the process of criminalization, and its effect on those who are engaged in the behavior. REFERENCES Best, Joel and David F. Luckenbill. 1982. Organizing Deviance. Englewood Cliff, New Jersey: PrenticeHall. Bequai, August. 1987. Technocrimes. Lexington, Mass.:Lexington Books. Bickford, Robert. 1988. Personal communication to Gordon Meyer. Chicago Tribune. 1989. "Computer hacker, 18, gets prison for fraud." Feb. 15:2,1. Field Notes. Interviews with phreakers, hackers, and pirates. Conducted from 7/88 to 4/89 (confidential material in authors files). Hollinger, Richard C. and Lonn Lanza-Kaduce. 1988. "The Process of Criminalization: The Case of Computer Crime Laws." Criminology 26:101-126. Levy, Steven. 1984. Hackers: Heroes of the Computer Revolution. New York: Dell Publishing. Message Logs from a variety of computer underground bulletin board systems, (confidential material), 1988-1989. NBC-TV. 1988. Hour Magazine. November 23, 1988. Parker, Donn B. 1983. Fighting Computer Crime. New York: Charles Scribner's Sons. Rosenbaum, Ron. 1971. "Secrets of the Little Blue Box." Esquire October, pp. 116-125. Small, David. 1988. Personal communication to Gordon Meyer. WGN-Radio. 1988. Ed Schwartz Show. September 27, 1988. Packet Storm Security archives Cyberarmy.com Hackers.com Netbus.org Rootshell.com Anonymiser.com Insecure.org Zataz.com Neworder.box.sk cDc (cult of dead cow) Infowar.com Hack-net.com Divine Intervention Hackernews.com Astalavista.box.sk L0pht Industries Antionline.com Digicrime.com Chaos Computer Club (CCC) Nightbird Type d’attaques Trojan Programme semblant avoir une autre fonction que celle qu'il réalise effectivement. L’utilitaire Scan de McAffee a d’ailleurs souvent été l’objet de Trojan Horses (Chevaux de Troie). Backdoor Portion de code agissant sans authentification. Imaginons qu’une erreur de programmation induise, dans certaines situations, l’exécution d’un code permettant l’accès à des ressources sans login ni mot de passe. Worms Programmes se propageant d'une machine à l'autre sur un réseau. Password cracking Il est très souvent facile d'obtenir le mot de passe d'un utilisateur peu avisé. Soit il s'agit d'un mot de passe facile à deviner ( 123, le prénom de la copine ou du fiston), soit il est écrit en toutes lettres sur un post-it collé à l'écran, soit la secrétaire le sème à tout vent. Même les plus prudents ne sont pas à l'abri d'un regard attentif au-dessus de l'épaule. Evitez spécialement les mots de passe faits de mouvements réguliers sur le clavier du type azerty. Une autre erreur classique est d'utiliser comme mot de passe le nom d'utilisateur comme guest - guest. Il faut également se méfier des faux programmes de login ou des programmes qui utilisent la force brute pour détecter un mot de passe à partir d'un dictionnaire. Les plus redoutables crackers auront même recours au "eavesdropping" pour capturer votre mot de passe en "sniffant" les paquets réseau. Social engineering Un pirate informatique a quelquefois bien plus de talents psychologiques que de compétences informatiques. Toutes les attaques informatiques n'ont pas l'efficacité d'un simple coup de fil donné d'un ton assuré pour réclamer un mot de passe oublié ou égaré. SPAM What's Spam and What's the Problem? In this chapter: Slapped in the Face What's Wrong with Spam A Taxonamy of Spam ... or, Why You Can't Just Click "Delete." Slapped in the Face If you use email, it's likely that you've recently received a piece of spam--an unsolicited, unwanted message sent to you without your permission. Spam is the Internet's version of junk mail, telemarketing calls during dinner, crank phone calls, and leaflets pasted around town, all rolled up into a single annoying electronic bundle. Spam is not democratic. If you are new to the Internet, you've probably seen only a few of these annoying messages. If you've been using the Internet for more than a few years, or if you participate in online discussion groups, you might receive a dozen or more of these messages each day. And if you administer a network for a business or university, you might be bombarded with hundreds. Here's a typical message that we received while working on this book: Received: (from mail@localhost) by apache.vineyard.net (8.8.5/8.8.5) id LAA01663 for <[email protected]>; Sat, 16 May 1998 11:57:57 -0400 (EDT) From: [email protected] Message-Id: <[email protected]> Received: from 209-142-2-72.stk.inreach.net(209.142.2.72) by apache.vineyard.net via smap/slg (V1.3) id sma001626; Sat May 16 11:57:27 1998 Date: Sat, 16 May 1998 05:18:34 To: <[email protected]> Subject: Search Engines, 400 for 5.75 (1) *** LIMITED TIME SPECIAL OFFER *** For Only $5.75 (1) We Will Submit Your Web Site To Over 400 Of The Net's Hottest Search Engines, Directories & Indexes. If you're site isn't listed in the Search Engines, how can people find you to buy your products or services? * Your Competition Is Getting Noticed Are You? Get Noticed By Your Prospects. Visit Our Web Site To Learn More: http://www.tiffiny.com/sitesubmissions Thank You (1) The price for this service is $69 prepaid which covers the cost of submitting your site every three months for an entire year. We have shown the price of $5.75 to show you how inexpensive this program really is when the overall cost is annualized. Minimum 12 month term and full prepayment required. ====================================== Name removal requests. Send to: TO: [email protected] SUB: remove ====================================== This email from tiffiny.com has all the elements of a typical spam message: The message came from a business with which we had no prior relationship. It was sent from an email address ([email protected]) that either is fictitious or was created solely for the purpose of sending spam messages and has long since been discarded. The message advertises a service that is illegitimate, shady, or misleading at best. (The service being advertised is not $5.75, as the subject line says, but $5.75 per month, with a "minimum 12 month term and full prepayment required." Furthermore, there simply aren't 400 "hot" search engines, directories, and indexes on the Internet.) The message does not clearly identify the person or group that has sent it. Removal requests sent to the address listed at the bottom, [email protected], were ignored. The company that's doing the advertising is not well known and typically isn't trying to establish a reputation or a loyal consumer following. If you've ever gotten a piece of spam mail, you've probably experienced a wide range of emotions. At first you were probably confused. What is this message? you might have asked yourself. Where did it come from? Where did these people get my name? Once your confusion passed and you received your second or third spam, you may have become angry. Perhaps you wrote letters of complaint to the spammer and were further angered when your complaints bounced back to you because the spammer had disguised his email address. Finally, you may have passed through anger to helplessness once you began receiving spam on a daily basis. Reading your email, once a source of fun or information, was reduced to a time-consuming process of weeding out junk mail with no end in sight. Don't give up hope. There are powerful tools for fighting back against spam. In this book, we'll show you how. What's Wrong with Spam Most spam messages on the Internet today are advertisements from individuals and the occasional small business looking for a way to make a fast buck. Spam messages are usually sent out using sophisticated techniques designed to mask the messages' true senders and points of origin. And as for your email address, spammers use a variety of techniques to find it, such as "harvesting" it from web pages and downloading it from directories of email addresses operated by Internet service providers (ISPs). But spamming today could well be undergoing a revolution. Over the past year, AT&T, Amazon.com, and OnSale.com all have experimented with bulk email. Although the companies clearly identify themselves in the mail messages, these bulk mailings can cause many of the same problems as spam messages from less scrupulous individuals and companies. If these companies continue their experiments, and if they are joined by others, we'll surely see a dramatic increase in the amount of spam on the Net. The people who send these messages say that the email is a form of electronic direct marketing--the cyberspace equivalent of radio advertisements and newspaper inserts. But there are important differences between electronic spam and conventional marketing techniques-differences that could ultimately destroy the usefulness of the Internet if spam is not stopped. Spammers often say that spam isn't a problem. "Just hit Delete if you don't want to see it." And many spam messages carry the tagline "If you don't want to receive further mailings, reply and we'll remove you." But spam is a huge problem. In fact, junk email and junk postings to Usenet newsgroups are one of the most serious threats facing the Internet today. Spam messages waste the Internet's two most precious resources: the bandwidth of longdistance communications links and the time of network administrators who keep the Internet working from day to day. Spam also wastes the time of countless computer users around the planet. Furthermore, in order to deliver their messages, the people who send spam mail are increasingly resorting to fraud and computer abuse. How Much Spam Is There? Just how much spam is out there? Although it's hard to come up with exact numbers, the initial reports from the field show that there's a lot and that the problem is getting worse: According to America Online, which testified about spam in front of the Federal Trade Commission in 1997, roughly a third of the email messages AOL receives on any given day from the Internet are unsolicited spam. According to the first academic study of spam, by Lorrie Faith Cranor at AT&T LabsResearch and Brian A. LaMacchia at Microsoft, between 5% and 15% of the email received by AT&T Research and Bell Labs Research between April 1997 and October 1997 was spam. Lorrie Faith Cranor and Brian A. LaMacchia, "Spam!," Communications of the ACM, Vol. 41, No. 8 (Aug. 1998), pp. 74-83, http://www.acm.org/pubs/citations/journals/cacm/1998-418/p74-cranor/>. According to Spam Hippo (http://www.spamhippo.com), an automated Usenet antispam system written by Kachun Lee for PathLink Technology Corporation, roughly 575,000 articles were posted to Usenet in June 1998, of which roughly 200,000, or 35%, were spam. (That's down from a high of 60%, or 300,000 spam messages out of 500,000 postings, before Spam Hippo began operation.) These numbers don't tell the whole story. Although they show that there is a lot of spam on the Internet today, they don't explain why it is a threat. Indeed, if the only problem with spam were the sheer volume, one could make equally urgent arguments about the number of advertisements in your daily newspaper, commercials on TV and radio, and even billboards in subways and on buses. Nobody is saying that advertising is about to bring newspaper journalism to an end. Indeed, most newspapers, broadcasters, and even public transit authorities rely on advertising to pay their bills. What's so different about spam? The answer to this question lies not in technology, but in economics. The fundamental difference between spam and other forms of advertising has to do with cost and price. The Low Cost of Spam With most forms of advertising, the cost of sending each message is significant--especially when compared to the cost of the item being sold and the size of the market. An advertisement in a newspaper can cost anywhere from $24 for a typical classified ad to $25,000 for a full-page advertisement in a major newspaper. Sending a catalog to 100,000 people can cost anywhere from $50,000 to $150,000, depending on the size of the catalog, the quality of the printing, and the type of postage used. Compare these costs to the cost of sending an email message or posting an article on Usenet. A typical computer connected to the Internet over a 28.8 kbps dial-up modem can send more than 100 email messages a minute, which translates to 864,000 mail messages a day, or 26 million in a typical month. With ISPs offering "unlimited" dial-up access to the Internet for $20 per month or less, and a dedicated phone line costing another $15, a spammer can send roughly 10,000 email messages for a penny. Even if you add the cost of buying a computer (perhaps $1,000), electronic advertising is an incredibly cheap way to reach an audience. This low cost encourages spammers to send huge numbers of messages. Businesses that advertise using traditional media normally make some kind of effort to target their messages. Common sense dictates that there's no reason to send an advertisement to somebody who can't buy the product being advertised--there's no reason to spend the money to advertise dog food to cat owners. But spammers have no motivation to target their messages, because the cost of sending out electronic messages is so low. Merge/purge The low cost of email encourages spammers to forsake another practice that's common among conventional direct marketers, a technique known as merge/purge. When a merge/purge is performed, a mailing list company merges several lists and then purges the duplicates. Because of the cost of sending messages, marketers normally try to avoid sending the same message again and again to the same consumer. Spammers, operating in a medium that's essentially without cost and frequently unconcerned about their reputation, don't care. Because there is no merge/purge, it's common to log in to your email and see many copies of the same spam message awaiting your perusal--especially if you have several email addresses that all forward to the same location: Id# From To Subject 1 [email protected] [email protected] Dental/Optical Plan 2 [email protected] [email protected] Dental/Optical Plan 3 [email protected] [email protected] Dental/Optical Plan 4 [email protected] [email protected] Dental/Optical Plan 5 [email protected] [email protected] Dental/Optical Plan 6 [email protected] [email protected] Dental/Optical Plan The clever spammer Spammers realize that it's pointless to send email that's not going to get read, so they're increasingly resorting to new, deceitful techniques to get you to read their mail before you delete it. Some tricks are designed to make it seem as if the message came from a new business partner: From: Bob Brown <[email protected]> Subject: RE:To selected new clients Or the spammer might try to make it look as if he or she is an old friend: From: Jane <[email protected]> Subject: What's up? Or the spammer might even try to make it look as if the message came from you: From: Jason Sears <[email protected]> To: Jason Sears <[email protected]> As spammers get more clever, it's becoming harder to delete these messages without reading them first. Unfortunately for us, the more people there are who send spam, the more likely it is that some of them will be quite clever. The High Price of Spam Spam may be cheap to send, but bulk email and newsgroup postings come at a high price to recipients of the messages and to the Internet through which they travel. It's because of this price that "simply clicking Delete" isn't a good solution to the spam problem. The price users pay Under normal circumstances, computers can't tell the difference between spam messages and normal, important messages--the kind that we want. Each message, spam or otherwise, is treated with care and speedily carried to its appropriate destination (or destinations). It may take a spammer just five or ten minutes to program his computer to send a million messages over the course of a weekend. Now it's true that each of these messages can be deleted with just a click of the mouse, which takes only three or four seconds: a few seconds to determine that the message is in fact spam plus a second to click Delete. But those seconds add up quickly: one million people clicking Delete corresponds to roughly a month of wasted human activity. Or put another way, if you get six spam messages a day, you're wasting two hours each year deleting spam. The price users pay for spam increases if you include the cost to the business or organization that operates the computer that holds your mailbox. These computers, called mail servers, require full-time connections to the Internet that can cost anywhere from $250 to $2,000 per month or more. The cost of the connection is determined, in part, by the amount of data it can carry. If a company's Internet connection is filled with spam, that company will be forced to spend more money on a faster Internet connection in order to handle the rest of its email traffic. Likewise, the company will be forced to buy faster computers and more disk drives. These costs must eventually be passed on to end users. This scenario is not theoretical. In July 1997, spam mail overwhelmed AT&T WorldNet's outgoing mail system, delaying legitimate email by many hours. The price administrators pay System administrators pay for spam with their time. The Internet's email system was designed to make it difficult to lose email messages: when a computer can't deliver a message to the intended recipient, it does its best to return that message to the sender. If it can't send the message to the sender, it sends it to the computer's postmaster--because something must be seriously wrong if the email addresses of both the sender and the recipient of a message are invalid. The well-meaning nature of Internet mail software becomes a positive liability when spammers come into the picture. In a typical bulk mailing, anywhere from a few hundred to tens of thousands of email addresses might be invalid. Under normal circumstances these email messages would bounce back to the sender. But the spammer doesn't want their bounces! To avoid being overwhelmed by the deluge, spammers often send messages with invalid return addresses. The result: the email messages end up in the mailboxes of Internet postmasters, who are usually living, breathing system administrators. System administrators at large sites are now receiving hundreds to thousands of bounced spam messages each day. Unfortunately, each of these messages needs to be carefully examined, because mixed in with these messages are the occasional bounced mail messages from misconfigured computers that actually need to be fixed. As a result, spam is creating a huge administrative load. As the spam problem grows worse, system administrators are increasingly taking themselves off their computer's "postmaster" mailing lists. The result is predictable: they're deluged with less email, but problems they would normally discover by receiving postmaster email are being missed, as well. The whole Internet suffers as a result. The price bystanders pay In their attempts to distribute their ads and avoid complaints, spammers often engage in fraud or other kinds of system abuse. For example, in 1996, America Online started blocking email from many domains associated with spammers. To bypass AOL's filters, some spammers started sending email with false "return addresses." Some of these return addresses were purely fictitious. Others were for existing businesses that had no connection with the spamming activities, but were nevertheless tarnished by them. Another technique spammers have used to send email is to relay their messages through other computers on the Internet--often without the knowledge or the consent of those computers' owners. This practice constitutes a theft of service. It also can result in problems for the unsuspecting relay, as people mistakenly think that the relay is the spammer. Attacked by a Spammer The attack started at 2:30 a.m. on January 15, 1997. But I didn't know that something was amiss until 4:20 p.m. or so, when I tried to check my mail. Strangely, there were 25 mail bounces from MAILER-DAEMON. Somebody had tried to send a whole bunch of mail; the mail that bounced had ended up in my inbox. Now, having weird mail show up in my inbox isn't an unusual occurrence for me. That's because I'm on [email protected], the mailing list for my small ISP located on the island of Martha's Vineyard, Massachusetts. Over the past 18 months I'd seen quite a bit of bounced mail from folks who hadn't set up computers properly. In each case I would have sombody call up the customer so they could fix their system. There was something different about these bounces. For starters, there were a lot of them. And they had all bounced from a computer called empty.cabi.net--a computer, I later learned, that had an invalid IP address. But the big giveaway was the content of the mail messages, hidden beneath more than 80 lines of bounced mail headers. "Customers For You!" the message read. "CV Communications BULK EMAIL ADVERTISING SERVICE." It didn't take me long to piece together what was happening. Somebody calling himself CV Communications had connected to the mail server on vineyard.net, and was using my computer to send his unsolicited bulk email. The nerve! This guy was using my Internet connection to further his commercial ends, and sticking me with his bounces. I had been spammed by a spammer advertising spamming services. It got worse. Further on down in my mailbox I noticed the complaints. Across the Internet, people being hit by this fellow's spam were blaming me and vineyard.net. Most thought CV Communications was one of our customers. I logged on to my computer and typed the mailq command to see how much mail this spammer had piled up on my machine. I was horrified: there were more than 2,000 messages waiting to go out. Nearly all of them were being shipped to AOL and CompuServe. The good news, I thought wryly, was at least this guy hadn't broken into my system. He was slowing down mail for all my customers, giving me a bad name, and making lots of work for me, but at least he hadn't broken in. Nevertheless, he had still caused plenty of damage. It took us more than two weeks to clean up from the incident. --Simson Garfinkel The price society pays There are nonmonetary costs to spam as well. Unwanted postings destroy the community spirit on which Usenet is based. When newsgroups are inundated with spam, fewer people read the groups, and they are less effective as a resource for discussion, problem solving, and information dissemination. And when Usenet traffic becomes too high, ISPs are forced to cut back on the number of newsgroups they carry, damaging Usenet's usefulness in the process. Some unwanted postings, like chain letter pyramid schemes, are illegal in themselves. Spam makes it easy for scam artists and hucksters to prey on some of the most vulnerable members of society. The Dirty Dozen Spam Scams In July 1998, the U.S. Federal Trade Commission (http://www.ftc.gov>) issued a list of the 12 most common scams promulgated by spammers: Pyramid schemes that promise a big return for a small investment. Scams that suggest that money can be made by becoming a spammer, and offer to sell address lists or bulk mailing software. The lists are often of poor quality, and spamming usually violates the victim's contract with his ISP. Chain letters. Work-at-home schemes that offer money for stuffing envelopes or building handicrafts. Often the victims never receive payment for their work. Health and diet scams--snake oil by email. Currency exchange scams that aren't legitimate. Scams promising free merchandise in return for a membership fee; victims discover (after paying the fee) that they don't qualify for the freebies until they sign up other members. Bogus investment opportunities. Offers of cable descrambler kits, which are illegal if they work--and most don't. Bogus home-equity loans or unsecured credit cards that never materialize. Credit repair scams in which the victim is promised a completely clean credit record upon payment. Establishing a new credit identity is illegal in the United States, and bad credit can't be magically removed. Vacation prize promotions that offer luxury vacations at discount prices. Victims find that the vacation accommodations aren't deluxe--unless they're willing to pay to upgrade. Nearly all these scams predate email, but spamming makes it easier than ever for con artists to recruit victims. Much spam is simply offensive to the recipients. On July 21, 1997, for example, a spammer appropriated CNN Interactive's CNN Plus mailing list and sent pornographic email to thousands of CNN customers. The incident was offensive to many of the subscribers and a terrible embarrassment to CNN. Is it acceptable for a company representative--or a scam artist--to interrupt a productive discussion you're having with your colleagues, solicit business using a false name and address, and then leave you with the bill? The price the Internet pays The biggest problem with spam is that if it continues to grow unchecked, its electronic deluge threatens to crowd out all other legitimate messages, making the electronic commons of the 21st century an unusable cesspool of useless marketing messages. This is a problem whether the spam messages are sent from shady operators or legitimate businesses. It is simply so cheap to send spam that every business can send it to all of us. And if this happens, there will be a deluge. Remember what happened to CB radio in the 1970s? Although CB was designed as a lowpower two-way communications medium, as radios became more popular, a few spoilsports started broadcasting music, political messages, and advertisements with 10 and 20 times more power than the law allowed. It didn't take long for the CB radio waves to become a vast wasteland. Today CB is useful only to very small, specialized groups of people. The same thing could happen to the Internet unless spam is stopped--and stopped soon. A Taxonamy of Spam Today people use the word "spam" to mean almost any kind of unwanted email message or news article they receive. In this book, however, we use the term to describe email or news articles that are sent in bulk without regard to the recipient's wishes. A spammer is someone who posts or sends spam, and spamming is the act of posting or sending spam. The word "spam" should not be capitalized unless it is at the beginning of a sentence, because to capitalize it would be to use it as a trademark. Spam? Obviously, in the context of the Internet, spam doesn't refer to the tasty canned meat produced by Hormel Foods. How did it come to mean bulk messages? The genesis of this meaning can be found in a Monty Python's Flying Circus sketch in which a customer in a restaurant asks what's on the menu. The waitress tells him, "Well, there's egg and bacon; egg, sausage, and bacon; egg and spam; egg, bacon, and spam; egg, bacon, sausage, spam; spam, bacon, sausage, and spam; spam, egg, spam, spam, bacon, and spam; spam, sausage, spam, spam, spam, bacon, spam, tomato, and spam; spam, spam, spam, egg, and spam" (and so on). Then a chorus of Vikings begins chanting "Spam, spam, spam, spam; lovely spam, wonderful spam." The first Internet use of the word originated in Internet chat rooms and on multiplayer Internet adventure games called MUDs (multiuser dungeons). According to Jennifer Smith, author of the Frequently Asked Questions (FAQ) list for the rec.games.mud newsgroup hierarchy, a few delinquents would "say" the same message again and again in a chat room, filling the screen in the process, and other people would call these messages "spam." It was just like the song in the Monty Python skit--senseless repetition. From flooding someone's screen with repeated words to flooding someone's mailbox or a newsgroup with repeated messages seemed to be a natural extension of the concept. Flavors of Spam It's important to distinguish between the different kinds of unwanted messages on the Internet today. The following sections explain some terms you may see. Email spam Unsolicited commercial email (UCE) is just what it sounds like: an email message that you receive without asking for it advertising a product or service. This is also called junk email. Unsolicited bulk email (UBE) refers to email messages that are sent in bulk to thousands (or millions) of recipients. UBE may be commercial in nature, in which case it is also UCE. But it may be sent for other purposes as well, such as political lobbying or harassment. Make money fast (MMF) messages, often in the form of chain letters or multi-level marketing schemes, are messages that suggest you can get rich by sending money to the top name on a list, removing that name, adding your name to the bottom of the list, and forwarding the message to other people. Some also advocate reposting the message to hundreds of newsgroups. MMF messages are considered lotteries in the United States and are illegal. They're also extremely common. Reputation attacks are messages that appear to be sent from one person or organization, but are actually sent from another. The purpose of the messages isn't to advertise a particular service or product, but to make the recipients of the message angry at the apparent sender. A typical reputation attack would be a spammer sending 10 million messages appearing to advertise this book. The most nasty reputation attacks include the actual email addresses, phone numbers, and street addresses of the victim or victims. Reputation attacks constitute wire fraud, since they use forged addresses, and are illegal. Usenet spam Excessive multi-posting (EMP) refers to an identical news article posted individually to many newsgroups. Each copy of the article has a different Message-ID and typically appears in different newsgroups (forcing each message to be sent individually to every computer connected to the Usenet). This is the strict definition of spam; if you ever hear someone arguing that an unwanted message isn't "spam," they probably mean that it isn't an EMP. Excessive cross-posting (ECP) refers to news articles cross-posted to many newsgroups. A news article is cross-posted when multiple newsgroups are listed in its "Newsgroups:" header line. For example, an article containing this "Newsgroups:" header: Newsgroups: rec.games.mud.admin,rec.games.mud.tiny,rec.games.mud.misc has been cross-posted to three newsgroups, a number that isn't usually considered excessive. Cross-posting is better than posting individual copies to each newsgroup, because only a single copy is passed between news sites, and most newsreaders will show a crossposted article only once. Nevertheless, cross-posting an article to hundreds of newsgroups is clearly an abuse of the Usenet system. ECP is sometimes called velveeta. A spew occurs when a misconfigured news program posts the same article to the same newsgroup repeatedly. Off-topic postings are news articles with inappropriate content for the newsgroup in which they appear. For example, an article about model trains is off-topic in rec.pets.dogs. The appropriate topics for a newsgroup are decided when the newsgroup is created, in its charter. Many newsgroups regularly post either the charter or a list of Frequently Asked Questions about the newsgroup to help people learn what's on-topic and what's off-topic. Binaries are news articles containing encoded binary files: image files, programs, video, or music samples, for example. Binaries are inappropriate for any newsgroup that's not explicitly chartered to allow binaries, even if they're on-topic. The alt.binaries hierarchy is devoted entirely to binaries. Commercial postings are news articles advertising a product or service for sale. These postings are welcomed in some newsgroups, tolerated in others, and discouraged or forbidden in still others, even if they're on-topic. In the next two sections, we'll look at MMF pyramid scams and reputation attacks. (Can't) Make Money Fast A substantial proportion of spam messages promise huge financial rewards if you simply send a few dollars to the name at the top of a list. Here is a typical message that you might have seen: INSTRUCTIONS: Follow these instructions EXACTLY and in 20 - 60 days you will have received well over $50,000.00 cash in the mail. This program has remained successful because of the HONESTY Integrity of the participants. Welcome to the world of Mail Order! This little business is somewhat different than most mail order houses. Your product is not solid and tangible, but rather a service. You are in the business of developing Mailing Lists. Many large corporations are happy to pay big bucks for quality lists. (The money made from the mailing lists is secondary to the income which is made from people like yourself requesting that they be included in that list.) HERE IS THE LIST OF NAMES TO SEND TO: 1. N. Ames, PO Box 123, San Fransisco, CA 2. S. D. Nym, 456 Red Road, Mesquite, TX 3. Y. Shure, 7890 Alphabet Ave. #1, New York, NY 4. L. Bank, 222 Sky Terrace, Los Angeles, CA 5. L. Twain, 10 Montgomery Dr., Chicago, IL Mail $1.00 to each of the 5 names listed above. SEND CASH ONLY (Total investment: $5.00) Enclose a note with each letter stating: Please add my name to your mailing list. Include your name and mailing address. (This is a legitimate service that you are requesting and you are paying $1.00 for this service.) Remove the name that appears as number 1 on the list. Move the other 4 names up one position (Number 2 becomes number 1,number 3 becomes number 2, and so on). Place your name, address, and zip code in the number 5 position. With your name in the number 5 position start posting this letter everywhere. Post on your web page, email it, mail it, take it to work, be creative give everyone you can think of a copy so they too can join in on the cash! Remember, the more places people see the letter the more people can respond and the more cash flows in for you! Tell them to follow these directions also! Despite the claim that this is a legitimate enterprise, these chain letters are pyramid schemes that are illegal in the United States and many other countries because they constitute gambling-you're sending money in hopes of an uncertain return. That's because it's mathematically impossible for everybody who receives the chain letter to be a winner--for everyone who makes a dollar with this scheme, somebody else must lose a dollar. If somebody does get rich, it's usually the person who started the chain. He gets rich at the expense of all the others who pin their hopes on the pyramid. Indeed, a clever initiator will put his name on the letter several different times in different forms, so he will get all the money. You can find out more about chain letters on the U.S. Postal Inspection Service's web site, at http://www.usps.gov/websites/depart/inspect/chainlet.htm>. In a Ponzi scheme, a variant of the pyramid, "investors" are recruited; interest on the investment is to be paid by future investors. In 1996, the U.S. Federal Trade Commission filed suit against the Fortuna Alliance, a group advertising a Ponzi scheme over the Internet that had taken over $6 million from its victims. The following year, a U.S. District Court ruled that Fortuna must refund its membership fees and barred it from ever again engaging in any sort of pyramid or multilevel marketing business. Do not be fooled if the chain letter is used to sell inexpensive reports on credit, mail-order sales, mailing lists, or other topics. The primary purpose is to take your money, not to sell information. "Selling" a product does not ensure legality. Be especially suspicious if there's a claim that the U.S. Postal Service or U.S. Postal Inspection Service has declared the letter legal. This is said only to mislead you. Neither the Postal Service nor Postal Inspectors give prior approval to any chain letter. Remember that money doesn't come from thin air. For every $5 someone gets, someone else loses $5. By virtue of the pyramid structure, there are always many more losers than winners. The Indefensible Reputation Attack On April 20, 1998, a spammer placed a phone call to a dial-up modem located in Florida, connected to a computer in Nantucket, and proceeded to send tens of thousands of email messages to unsuspecting users at America Online. "Hello once again," began the message. "I know you have heard of me. I am Jeanne Dixon, a well-known psychic, medium, healer, spiritualist, clairvoyant, and astrologer. My horoscopes and psychic predictions are found in all of the major newspapers and publications worldwide. I can predict your future." At the bottom of the message were two phone numbers for The Psychic Connection--one phone number to call if you wished to pay by credit card, another if you wished to have your call to the telephone psychic billed at $3.99 per minute. But what made the advertisement truly noteworthy, aside from the fact that Jeanne Dixon died on January 25, 1997, was the fact that each email message was sent with a forged return address, [email protected]. Why pick vineyard.net? As near as we can figure, the spammer had used our email addresses because we had recently installed anti-spam software and made it freely available on the Internet to others who wished to defend their systems. The vineyard.net anti-spam software prevented email messages from being relayed through our mail server and blocked our customers from receiving email that came from nonexistent domains. But there was no way that we could defend ourselves against this unauthorized use of our domain name. Over the next few days, thousands of people who received the astrology solicitation took a few moments out of their busy schedules to send vineyard.net complaints in return. Because of the nature of email, there is no way for people to defend themselves against this kind of attack. The astrology solicitation never passed through vineyard.net. It simply used our name, forcing us to deal with the consequences. These so-called reputation attacks are becoming increasingly common on the Internet, as spammers realize that the same techniques they have developed for sending spam mail can be used with impunity to hurt or harass others. One of the most public reputation attacks took place on October 20, 1996: Hi! I sent you this letter because your email address was on a list that fit this category. I am a fan of child pornography and for the past 4 years, I have been able to gather quite a collection of it. I have pictures, VHS tapes, posters, audio recordings, and games based on child pornography. I am now selling my products (or trading for other child pornography). I have a complete color catalog of all my products now available. The message concluded with a price list for a color catalog and videotapes, and an address in Jackson Heights, New York. It was spammed to millions. Within hours, the FBI's switchboard in New York City was flooded with more than 50 complaints. Soon complaints were coming in from all over the world. Numerous investigators were dispatched to the address in Jackson Heights. On October 23, the FBI issued a statement: "Police departments and FBI offices around the country have received numerous reports relating to the email message. The message is a hoax and the matter is being investigated." No arrests in the case were ever made. Reputation attacks continue to this day. Expect to see many of them in conjunction with the 1998 U.S. Congressional elections. Le dépassement de capacité d'un TAMPON Le dépassement de capacité d'un TAMPON est une faiblesse de certains programmes, par exemple ceux écrits en langage de programmation C et qui fonctionnent sur un système d'exploitation comme Unix. Le pirate exécute un programme en C sur l'ordinateur victime (a). Le programme stocke tout d'abord des données dans un espace de stockage temporaire, nommé tampon (b), puis souhaiterait déplacer des données de l'emplacement 1 vers le 2 et vers le 3 (c). Cependant, le pirate oblige le programme à accepter des données en excès : certaines informations s'infiltrent directement dans l'emplacement 4 (d). Le pirate en profite pour installer son propre code (e) et bénéficie ainsi des possibilités étendues de l'ordinateur de sa victime. Le délestage d'un fichier «core» Le délestage d'un fichier «core» est une opération que les pirates utilisent pour obtenir des informations secrètes. Après une erreur, l'ordinateur libère le contenu d'une partie de sa mémoire vive dans un fichier. Un pirate peut provoquer un tel incident et accéder ainsi à des informations importantes, tels des mots de passe. Les transmissions de messages Les transmissions de messages obéissent à un protocole rigide. L'expéditeur envoie un signal de synchronisation (SYN) des communications à venir (à gauche). Le destinataire retourne alors un double signal (ACK/SYN) d'accord et de synchronisation pour accepter la demande. Enfin, l'expéditeur envoie à son tour un signal d'accord (ACK). Le message lui-même est alors transmis. Un signal de FIN (FIN) le suit de peu. Le destinataire répond par un autre signal d'accord qui clôt définitivement la correspondance. Un pirate corrompt cet échange (à droite) en envoyant immédiatement un signal FIN auquel le destinataire est obligé de répondre par un signal pour recommencer (RST). La réponse – ou l'absence de réponse – fournit des informations sur le destinataire. Cependant, l'absence des triples salutations empêche la transmission d'être enregistrée dans les comptes rendus du destinataire. Le pirate sonde ainsi un ordinateur avec une certaine discrétion. Transmission normale Denial of Services Transmission piratée par un scanner furtif Finger Idéal pour avoir des informations sur les utilisateurs, et surtout des noms de login. Permet de voir si quelqu'un travaille sur la machine et est susceptible de détecter une attaque. Imaginons que je veuille savoir qui est connecté sur la machine hash.drug.be: root@extacy:~# finger @hash.drug.be [hash.rtfm.be] Login Name Tty Idle manu manu p1 89d root root p0 1 Login Time Office Office Phone Oct 10 20:52 (192.168.2.2) Oct 10 20:51 (192.168.2.2) On voit que l'utilisateur manu et l'utilisateur root sont tous deux connectés. On sait donc que le compte manu existe et on peu commencer à orienter ses recherche par là... Cherchons quelques informations supplémentaires sur l'utilisateur manu de cette manière: root@extacy:~# finger [email protected] [hash.rtfm.be] Login: manu Name: manu Directory: /home/manu Shell: /bin/bash On since Thu Oct 10 20:52 (EET) on ttyp1 from 192.168.2.2 0 days 5 hours idle No mail. No Plan. Avant d'attaquer une machine, le pirate préfère savoir si quelqu'un travaille dessus. Si c'est ce cas, il préférera ne pas attaquer, de peur d'être repéré et de perdre ainsi tout le bénéfice de son "travail". Sans compter que Finger a été la source de nombreux bugs, pouvant rendre exécutable une partie des paramètres qu'on lui passait. Finger étant exécuté par root, les commandes pouvaient avoir de graves conséquences. Bridez votre Finger! Il vaut donc calmer les ardeurs de votre Finger, en le remplacent pas une version un peu différente. Ceci est beaucoup mieux: root@extacy:~# finger @extacy [extacy.drug.be] ----------------------------------------------------------------------------** Welcome to this host's finger system, [email protected] ** This site is running cfingerd 1.2.1. ----------------------------------------------------------------------------Finger "[email protected]" to get a listing of finger query services this system provides. Username Real name Idletime TTY Remote console location ----------------------------------------------------------------------------If that scrolled by your screen too fast, please put a "| more" at the end of your finger command. Le pirate croit en toute bonne foi que personne n'est sur la machine, et commence son attaque. Pas de chance pour lui, en réalité, voici la liste des personnes présentes sur la même machine, au même moment: root@extacy:~# who root tty1 Oct 10 22:20 root ttyp0 Oct 10 22:21 (:0.0) root ttyp1 Oct 10 22:57 (:0.0) root ttyp2 Oct 10 22:57 (:0.0) Et son attaque sera de suite repérée! SynFlood Une escroquerie Internet permet au pirate de falsifier son identité. Il teste d'abord sa victime en lui envoyant de multiples signaux de synchronisation (SYN) pour obtenir, en réponse, un double signal d'accord et de synchronisation (ACK/SYN), et une valeur de temporisation caractéristique d'un système d'exploitation. •In the TCP/IP protocol, a three way handshake takes place as a service is connected to. First in a SYN packet from the client, with which the service responses with a SYN-ACK. Finally the client responds to the SYN-ACK and the conversation is considered started. •A SYN Flood attack is when the client does not response to the SYN-ACK, tying up the service until the service times out, and continues to send SYN packets. The source address of the client is forged to a non-existant host, and as long as the SYN packets are sent faster than the timeout rate of the TCP stack waiting for the time out, the resources of the service will be tied up. Cette valeur augmente ici de 128 000 à chaque échange. Le pirate envoie ensuite de nombreux signaux de synchronisation dont un est identique à celui d'un ordinateur connu de la victime, qui transmet alors un double signal d'accord et de synchronisation à cet ordinateur autorisé. Le pirate ne reçoit pas cette réponse, mais poursuit la correspondance. Il délivre un signal d'accord avec la valeur de temporisation correcte : la communication entre son ordinateur et sa victime est établie. Le piratage commence. Ping de la mort •The Ping of Death is a large ICMP packet sent by a workstation to a target. The target receives the ping in fragments and starts reassembling the packet. However, due to the size of the packet once it is reassembled it is too big for the buffer and overflows it. This causes unpredictable results, such as reboots or hangs. •Windows 95 and Windows NT are capable of sending such a packet. By simply typing in "ping -165527 -s 1 <target>" you can send such a ping. There are also source code examples available for Unix platforms that allow large ping packets to be constructed. These sources are freely available on the Internet. Sniffer Les machines qui se trouvent sur un réseau ne s'intéressent en général qu'aux paquets qui leurs sont destinés, les autres étant écartés. Si on fait passer l'interface réseau en promiscius mode, c'est à dire qu'au lieu d'envoyer au kernel uniquement les paquets qui lui sont destinés, on lui envoie tous les paquets qui transitent sur le réseau, on peut espionner tous les échanges de données, en ce compris des passwords, du courrier et bien d'autres choses. Pour éviter cela, on vend des cartes réseau qui refusent de passer en promiscius mode ( par exemple chez 3Com) . Mais on peut quand même capturer tous les paquets qui sont destinés à la machine locale. Si on fait cela sur un serveur où travaillent 50 personnes, vous pourrez capturer tout ce que font ces 50 personnes sur réseau (mail, password,...). Si vous faites une connexion Telnet (ou FTP) sur une machine à partir de ou vers le réseau que je suis en train de sniffer, toutes les commandes que vous tapez sont envoyées sur le réseau. Je pourrai alors capturer tout cela avec un sniffer et je serais en possession de votre login et de votre password. De même, j'entrerai en possession de tous les fichiers transférés, que ce soit du courrier électronique ou tout autre fichier. C'est l'attaque la plus méchante et la plus efficace car elle est absolument indécelable. Par contre, il est nécessaire d'avoir un accès physique au réseau. Pour la contrer, il ne reste qu'à encrypter absolument toutes les sessions critiques. C'est très lourd, et souvent assez complexe, mais c'est le prix à payer pour une bonne sécurité. What a sniffer is and how it works Unlike telephone circuits, computer networks are shared communication channels. It is simply too expensive to dedicate local loops to the switch (hub) for each pair of communicating computers. Sharing means that computers can receive information that was intended for other machines. To capture the information going over the network is called sniffing. Most popular way of connecting computers is through ethernet. Ethernet protocol works by sending packet information to all the hosts on the same circuit. The packet header contains the proper address of the destination machine. Only the machine with the matching address is suppose to accept the packet. A machine that is accepting all packets, no matter what the packet header says, is said to be in promiscuous mode. Because, in a normal networking environment, account and password information is passed along ethernet in clear-text, it is not hard for an intruder once they obtain root to put a machine into promiscuous mode and by sniffing, compromise all the machines on the net. FTP De nombreux serveurs FTP ont des bugs ou sont mal configurés ce qui rend disponible le fichier de passwords à tout le monde via le compte anonymous. Certains serveurs FTP peuvent aussi exécuter des commandes qui peuvent parfois être détournées au profit des pirates. Refusez l'accès anonymous sur votre serveur FTP ou, si ce n'est pas possible, placez le serveur FTP sur une machine avec un acompte root accessible uniquement depuis la console. Voici un exemple de bug, très dangereux: hash:~$ ftp extacy Connected to extacy.24heures.rtfm.be. 220 extacy FTP server (Version wu-2.4(1) Sat Feb 18 13:40:36 CST 1995) ready. Name (extacy:manu): manu 331 Password required for manu. Password: 230 User manu logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> site exec passwd root 200-passwd root 200-Changing password for root Cela a pour effet de supprimer, purement et simplement, le password root. Ca marche extrêmement bien sur certaines machines! NFS Filesystem exportés, filesystems oubliés! NFS vous permet de partager un disque entre plusieurs machines, un peu comme sous Windows. Sous Unix, NFS utilise le protocole TCP/IP et on peut donc monter des disques Unix depuis n'importe quelle machine à travers Internet, ce qui rend le système plus pratique mais plus dangereux en cas d'oublis... Avec showmount, on peut facilement trouver une cible facile. Exemple d'un utilisateur qui a oublié que son disque était exporté par NFS: root@foo:~# showmount -e extacy.drug.be Export list for extacy: /dosc/slakware (everyone) /cdrom (everyone) / (everyone) IP-Spoofing Comme vu plus haut, les utilisateurs de certaines machines ne sont pas obligées de s'identifier auprès d'autres machines. Dès lors, il est possible d'envoyer des commandes à une machine en lui faisant croire qu'on est une des machines privilégiées. Aucun password ne nous sera demandé. Cette méthode demande un peu plus de doigté technique, et nous ne la détaillerons pas plus. Sachez que cela existe, et soyez sur vos gardes. Il n'existe malheureusement pas de solution au niveau protocole pour lutter contre ce type d'attaque. On peut cependant utiliser l'astuce suivante: Imaginons une équivalence entre les machines A et B. Un pirate, sur une machine C, se faisant passer pour la machine B, envoie des commandes vers la machine A. Avant que la machine A n’accepte les paquets, elle va demander à la machine B si c'est bien elle qui vient d'envoyer le paquet que C a émis. Puisque ce paquet a en réalité, été envoyé par C , B répondra par la négative et A écartera le paquet du pirate. DNS-Spoofing Renvoyer des résultats inattendus comme nom de machine peut vous donner des accès très intéressants. La résolution des noms se réalise au moyen de la fonction gethostbyname(). Le résultat de cette fonction est souvent utilisé tel quel dans des commandes. Pensons à un programme comme ceci: host = gethostbyname("193.75.199.3"); exec("telnet %s",host); Si la fonction gethostbyname() retourne foobar; reboot, la machine va exécuter telnet foobar; reboot. La première commande échoue mais ensuite la seconde s’exécute et la machine redémarre! Web CGI CGI scripts are a major source of security holes. Although the CGI (Common Gateway Interface) protocol is not inherently insecure, CGI scripts must be written with just as much care as the server itself. Unfortunately some scripts fall short of this standard and trusting Web administrators install them at their sites without realizing the problems. The problem with CGI scripts is that each one presents yet another opportunity for exploitable bugs. CGI scripts should be written with the same care and attention given to Internet servers themselves, because, in fact, they are miniature servers. Unfortunately, for many Web authors, CGI scripts are their first encounter with network programming. CGI scripts can present security holes in two ways: 1. They may intentionally or unintentionally leak information about the host system that will help hackers break in. 2. Scripts that process remote user input, such as the contents of a form or a "searchable index" command, may be vulnerable to attacks in which the remote user tricks them into executing commands. CGI scripts are potential security holes even though you run your server as "nobody". A subverted CGI script running as "nobody" still has enough privileges to mail out the system password file, examine the network information maps, or launch a log-in session on a high numbered port (it just needs to execute a few commands in Perl to accomplish this). Even if your server runs in a chroot directory, a buggy CGI script can leak sufficient system information to compromise the host. Ddos Understanding the Basics of DDoS Attacks Behind a Client is a person that orchestrate an attack. A Handler is a compromised host with a special program running on it. Each handler is capable of controlling multiple agents. An Agent is a compromised host that is running a special program. Each agent is responsible for generating a stream of packets that is directed toward the intended victim. Attackers have been known to use the following 4 programs to launch DDoS attacks: Trinoo, TFN, TFN2K and Stacheldraht. In order to facilitate DDoS, the attackers need to have several hundred to several thousand compromised hosts. The hosts are usually Linux and SUN computers; however, the tools can be ported to other platforms as well. The process of compromising a host and installing the tool is automated. The process can be divided into the following steps, in which the attackers: 1. Initiate a scan phase in which a large number of hosts (on the order of 100,000 or more) are probed for a known vulnerability. 2. Compromise the vulnerable hosts to gain access. 3. Install the tool on each host. 4. Use the compromised hosts for further scanning and compromises. Because an automated process is used, attackers can compromise and install the tool on a single host in under 5 seconds. In other words, several thousand hosts can be compromised in under an hour. Characteristics of Common Programs Used to Facilitate Attacks The following are common programs that hackers use to facilitate distributed denial of services attacks: Trinoo Communication between clients, handlers and agents use the following ports: 1524 tcp 27665 tcp 27444 udp 31335 udp Important Note: The ports listed above are the default ports for this tool. Use these ports for orientation and example only, because the port numbers can easily be changed. TFN Communication between clients, handlers and agents use ICMP ECHO and ICMP ECHO REPLY packets. Stacheldraht Communication between clients, handlers and agents use the following ports: 16660 tcp 65000 tcp ICMP ECHO ICMP ECHO REPLY Important Note: The ports listed above are the default ports for this tool. Use these ports for orientation and example only, because the port numbers can easily be changed. TFN2K Communication between clients, handlers and agents does not use any specific port (it may be supplied on run time or it will be chosen randomly by a program) but is a combination of UDP, ICMP and TCP packets. For a detailed analysis of DDoS programs, read the following articles (Note: The following links point to external web sites not maintained by Cisco Systems): The DoS Project's "trinoo" distributed denial of service attack tool The "Tribe Flood Network" distributed denial of service attack tool The "stacheldraht" distributed denial of service attack tool Additional information regarding DDoS tools and their variants can be found at the Packet Storm web site's Index of Distributed Attack Tools. Prevention The following are suggested methods to prevent distributed denial of service attacks: 1. Use the ip verify unicast reverse-path interface command. This feature checks each packet that is routed into router. If the source IP address does not have a route in the CEF tables that points back to the same interface on which the packet arrived, the router drops the packet. The effect of Unicast RPF is that it stops SMURF attacks (and other attacks that depend on source IP address spoofing) at the ISP’s POP (lease and dial-up). This protects your network and customers, as well as the rest of the Internet. To use unicast RPF, enable ‘CEF switching’ or ‘CEF distributed switching’ in the router. There is no need to configure the input interface for CEF switching. As long as CEF is running on the router, individual interfaces can be configured with other switching modes. RPF is an input side function that enabled on an interface or subinterface and operates on packets received by the router. It is very important for CEF to be turned on in the router. RPF will not work without CEF. Unicast RPF was first supported in 11.1(17)CC CEF 13 images on the RSP7000, 7200 and 7500 platforms. It is not supported in any 11.2 or 11.3 images. Unicast RPF is included in 12.0 on platforms that support CEF, including the AS5800. Hence, unicast RFP can be configured on the PSTN/ISDN dial-up interfaces on the AS5800. 2. Filter all RFC1918 address space using access control lists. Refer to the following example: interface xy ip access-group 101 in access-list 101 deny ip 10.0.0.0 0.255.255.255 any access-list 101 deny ip 192.168.0.0 0.0.255.255 any access-list 101 deny ip 172.16.0.0 0.15.255.255 any access-list 101 permit ip any any 3. Apply ingress and egress filtering (see RFC 2267) using ACL. 4. Use CAR to rate limit ICMP packets. Refer to the following example: interface xy rate-limit output access-group 2020 3000000 512000 786000 conform-action transmit exceed-action drop access-list 2020 permit icmp any any echo-reply For more information, refer to IOS Essential Features. 5. Configure rate limiting for SYN packets. Refer to the following example: interface {int} rate-limit output access-group 153 45000000 100000 100000 conform-action transmit exceed-action drop rate-limit output access-group 152 1000000 100000 100000 conform-action transmit exceed-action drop access-list 152 permit tcp any host eq www access-list 153 permit tcp any host eq www established In the above example, replace: 45000000 with the maximum link bandwidth 1000000 with a value that is between 50% and 30% of the SYN flood rate burst normal and burst max rates with accurate values Note that if you set the burst rate greater than 30%, many legitimate SYNs may be dropped. To get an idea of where to set the burst rate, use the show interfaces rate-limit command to display the conformed and exceeded rates for the interface. Your objective is to rate-limit the SYNs as little as necessary to get things working again. WARNING: It is recommended that you first measure amount of SYN packets during normal state (before attacks occur) and use those values to limit. Review the numbers carefully before deploying this measure. If an SYN attack is aimed against a particular host, consider installing an IP filtering package on that host. One such package is IP Filter. This can be found on http://coombs.anu.edu.au/ipfilter/ Refer to IP Filter Examples for implementation details. Forensics: Capturing Evidence If possible, capture packet sample for analysis. It is recommended that you use a SUN workstation or a Linux box on a fast Pentium machine to capture the packet sample. For capturing, use the tcp dump program (Linux or SUN) or snoop (SUN only). The command syntax is: tcpdump -i interface -s 1500 -w capture_file snoop -d interface -o capture_file -s 1500 The MTU size in this example is 1500; change this parameter if the MTU is greater than 1500. Preserve these logs as evidence for law enforcement. Analyses and talks Invited Talk, "DDoS: Is There Really a Threat?," USENIX Security Symposium, August 16, 2000 The DoS Project's "trinoo" distributed denial of service attack tool, by David Dittrich RAZOR analysis of WinTrinoo The "Tribe Flood Network" distributed denial of service attack tool, by David Dittrich The "stacheldraht" distributed denial of service attack tool, by David Dittrich TFN2K - An Analysis, by Jason Barlow and Woody Thrower, Axent Security Team An analysis of the ``Shaft'' distributed denial of service tool, by Sven Dietrich, Neil Long, and David Dittrich [BUGTRAQ followup post by Richard Wash] The "mstream" distributed denial of service attack tool, by David Dittrich, George Weaver, Sven Dietrich, and Neil Long Notes of talk given at CERT Distributed-Systems Intruder Tools Workshop, November 2, 1999 Steve Bellovin's NANOG presentation on DDOS Attacks, February 7, 2000 Presentation at DDoS BoF, NANOG Meeting, February 7, 2000 Tools RID, by David Brumley NATIONAL INFRASTRUCTURE PROTECTION CENTER; TRINOO/Tribal Flood Net/tfn2k detection tool BindView's Zombie Zapper Index of Distributed Tools at Packet Storm dds -- a trinoo/TFN/stacheldraht agent scanner (C source code) by Dave Dittrich, Marcus Ranum, George Weaver, David Brumley, and others. [In BETA testing.] (Use RID instead.) gag -- a stacheldraht agent scanner (C source code) by Dave Dittrich, Marcus Ranum, and others. (Use RID instead.) Advisories and mitigation information Incident Handling Step by Step: Unix Trojan Programs, SANS Institute CERT® Incident Note IN-2000-05 "mstream" Distributed Denial of Service Tool, May 2, 2000 CERT® Advisory CA-2000-01 Denial-of-Service Developments Sun Bulletin #00193, Distributed Denial-of-Service Tools, January 5, 2000 Results of the [CERT sponsored] Distributed-Systems Intruder Tools Workshop [PDF version] Consensus Roadmap for Defeating Distributed Denial of Service Attacks, A Project of the Partnership for Critical Infrastructure Security Help Defeat Denial of Service Attacks: Step-by-Step, SANS Institute DDoS Attack Mitigation, BUGTRAQ posts by Elias Levy, 11 Feb 2000 A DDOS defeating technique based on routing, BUGTRAQ posts by Fernando Schapachnik, February 20, 2000 Smurf attacks by Craig A. Huegen Path MTU Discovery and Filtering ICMP, by Marc Slemko RFC 2267 -- Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, by Paul Fergussen and Daniel Senie RFC 2644 -- Changing the Default for Directed Broadcasts in Routers, by Daniel Senie "Essential IOS" - Features Every ISP Should Consider, Cisco Systems Inc. Distributed Denial of Service (DDoS) News Flash, Cisco Systems Inc. Characterizing and Tracing Packet Floods Using Cisco Routers, Cisco Systems Inc. Policing and Shaping Overview, Cisco whitepaper on rate limiting Denial of Service (DoS) Attack Resources, by Paul Ferguson Related Papers, Essays, Legislative Proposals, and Research MULTOPS: a data structure for denial-of-service attack detection (gzip PostScript), by Thomer M. Gil Guidelines for Evidence Collection and Archiving <draft-ietf-grip-prot-evidence01.txt>, Dominique Brezinski and Tom Killalea (Internet Draft) Draft Convention on Cyber-Crime, Council of Europe (See also Cybercrime Solution Has Bugs, by Declan McCullagh, Wired News, May. 3, 2000) Source code to mstream, a DDoS tool, VULN-DEV post by Anonymous, April 29, 2000 THE WAR ON HACKERS, by Gary Lawrence Murphy Distributed Denial Of Service Attacks (DDOS), by David Anderson, MIT Theories on new DoS Attacks v.1, by J. Oquendo On Magic, IRC Wars, and DDoS, by Robert Graham Client-side Distributed Denial-of-Service: Valid campaign tactic or terrorist act?, by the electrohippies collective Spaf's Summary of White House meeting, February 19, 2000 Report of Windows version of trinoo DDOS tool by Gary Flynn, James Madison University DDoS Whitepaper by Bennett Todd (readable overview intended for non-techies) Crypto-Gram, by Bruce Schneier, February 15, 2000 Current Events on The Net: Fact, Fiction, or Hype?, by Richard Forno DDoS FAQ, by Kurt Seifried "Tribe Flood Network 3000": A theoretical review of what exactly Distributed DOS tools are, how they can be used, what more dangerous features can be implemented in the future, and starting points on establishing Network Intrusion Detection Rules for DDOS, by Mixter Have Script, Will Destory (Lessons in DoS), by Brian Martin, Attrition.org Practical Network Support for IP Traceback, by Stefan Savage, David Wetherall, Anna Karlin and Tom Anderson, Department of Computer Science and Engineering, University of Washington ICMP Traceback Messages (IETF draft proposal), by Steven Bellovin Advanced and Authenticated Marking Schemes for IP Traceback, by Dawn X. Song and Adrian Perrig Host Identity Payload, Internet Draft, Robert Moskowitz, ICSA.net Host Identity Payload -- Architecture, Internet Draft, Robert Moskowitz, ICSA.net Host Identity Payload -- Implementation, Internet Draft, Robert Moskowitz, ICSA.net Protecting Against the Unknown -- A guide to improving network security to protect the Internet against future forms of security hazards, by Mixter Purgatory 101: Learning to cope with the SYNs of the Internet, by NightAxis and Rain Forrest Puppy Distributed Attacks and the Way To Deal With Them, by Tim Yardley Strategies for Defeating Distributed Attacks, by Simple Nomad Selected news reports/interviews/panel discussions (in reverse chronological order) o o o o o o o o o o o o Internet giants confer on denial-of-service attacks, by Paul Festa, CNET News.com, September 26, 2000 Web sites unite to fight denial-of-service war, by Ellen Messmer, Network World, September 25, 2000 New Technology Tracks, Kills DoS Attacks At ISP Level, by Cynthia Flash, TechWeb News, September 14, 2000 New denial-of-service attack tool uses chat programs, by Ellen Messmer, CNN, September 6, 2000 Surfing the Tsunami: A large Southeastern university IS team fights off a massive distributed denial of-service attack and lives to tell about it., by DDoS Survivor, Network World, August 28, 2000 University researcher traces response to DDOS attacks, by Ann Harrison, Computerworld, August 18, 2000 [Corrections to Computerworld article] New Public-Private Venture Meant to Combat Cybercrime, by Paul Nowell, The Associated Press, August 11, 2000 250 Linux servers infected by denial-of-service program, the Korea Herald, August 1, 2000 Lack of funding threatens cybersecurity project, by Elinor Abreu, The Industry Standard, July 31, 2000 Wanna know how BT.com was hacked?, by Kieren McCarthy, The Register, July 25, 2000 BT hacked: revenge for crap service, by Kieren McCarthy, The Register, July 21, 2000 Hackers Plant Attack File in Home Computers, by Chet Dembeck, E-Commerce Times, June 9, 2000 o o o o o o o o o o o o o o o o o o o o o o o o o Hackers Said Poised for Attack, by D. Ian Hopper, AP, June 9, 2000 Experts lecture feds on cybersecurity, by Diane Frank, Federal Computer Week, May 24, 2000 Beware of the security zealot, by Lewis Z. Koch, Inter@ctive Week, May 23, 2000 New Denial-of-Service Software Found "in the Wild", by Steven Bonisteel, Newsbytes, May 3, 2000 Hackers release new DoS tool -- Stakes high in cat-and-mouse game with security experts, by Bob Sullivan, MSNBC, May 2, 2000 [Corrections to MSNBC article] Cybercrime Solution Has Bugs, by Declan McCullagh, Wired News, May. 3, 2000 Expert warns of powerful new hacker tool, by Stephen Shankland, CNET News.com, May 1, 2000 Probe of Hacker Net a Second Suspect: His Father, by Steven Pearlstein and David A. Vise, Washington Post, April 21, 2000 DoS Attacks: What Really Happened, by Bob Sullivan, MSNBC, April 19, 2000 `Mafiaboy' Arrested -- Canadian Teen Charged In Web Attacks, by Jonathan Dube and Brian Ross, ABCnews.com, April 19, 2000 Hackers can claim copyright on tools, by David Hellaby, AustralianIT, April 18, 2000 U.S. Treasury Chief Warns of Cyber Threats, by Jim Wolf, Reuters, April 18, 2000 How to Fight Cyber Thugs -- Before it's Too Late, editorial by Jesse Berst, ZDNet AnchorDesk, April 3, 2000 Hacker attack costs rise -- FBI, CSI: Verifiable losses due to poor security top $265M in 1999, CNNfn, March 22, 2000 DDOS attacks' ultimate lesson: Secure that infrastructure, by Deborah Radcliff, Securityportal.com, March 20, 2000 DoS Attacks on the Anatel (Brazilian National Telecommunications) (Spanish translate with Babelfish), by Condor, March 15, 2000 Ihug hit by hackers, by Adam Gifford, The New Zealand Herald, March 15, 2000 Get more secure - or else!, by Lisa M. Bowman, ZDNet|UK|, March 15, 2000 Asleep at the switch? -- How the government failed to stop the world's worst Internet attack, by M.J. Zuckerman, USA TODAY, March 9, 2000 [Note: When I was interviewed by Mike, I hadn't researched the timing of events very thoroughly, so he was working with my rough recollections. I've since tried to put together my own timeline on DDoS events] Web attacks: Cure worse than woes? Trend Micro's anti-viral OfficeScan - which also checks for DoS vulnerabilities - is a prime vehicle for foul play, by Steven J. VaughanNichols, Sm@rt Reseller, ZDNN, March 8, 2000 DoS attacks: A problem of the information age Q&A with security guru Dave Dittrich, by J.S. Kelly, SunWorld Online, March 2000 [Note: I was unable to provide feedback to J.S. Kelly in time, so some of the transcribed answers are not quite what I said. I'll try to clarify more as I find time. See also the Slashdot and other RealAudio interviews for answers to similar questions.] Hatch Won't Hatch Clinton Net Security Idea, by Robert MacMillan, Newsbytes, March 3, 2000 Getting Hacked Could Lead to Getting Sued, by Ritchenya A. Shepherd, American Lawyer Media News Service, March 2, 2000 Hacker plan: take down the Net -- Associates tell feds Coolio started last month's Web attacks; teen's New England home searched, computers confiscated, by Bob Sullivan, MSNBC, March 1, 2000 CIOs Need to Be Held Accountable for Security, by L. Taylor, TechnologyEvaluation.com, February 28th, 2000 o o o o o o o o o o o o o o o o o o o o o o o o o o FBI: Internet Attack Motive Unknown, by Ted Bridis, AP, February 29, 2000 Senate Judiciary Committee hearing on Internet Denial of Service Attacks and the Federal Response, February 29, 2000 Testimony of Eric Holder, Deputy Attorney General, Department of Justice Testimony of Dan Rosensweig, President and CEO, ZDNet Testimony of "Mudge", @Stake Locking Out the Hackers -- How to safeguard the Web, News: Analysis & Commentary, Business Week, February 28, 2000 FBI site hit in latest hacker attacks -- Microsoft, brokerage among victims, but damage is short-lived, MSNBC staff and wire reports, February 25, 2000 Web attacks? The ISPs strike back!, by Robert Lemos, ZDNet News, February 23, 2000 New hacker software could spread by email, by John Borland, CNET News.com, February 23, 2000 Cyber Crime -- First Yahoo! Then eBay. The Net's vulnerability threatens e-commerce-and you, Cover Story, BusinessWeek magazine, February 21, 2000 Web attacks: Are ISPs doing enough? Not according to many broadband customers and security experts, by Robert Lemos, ZDNet News, February 21, 2000 Internet News Radio interview with David Dittrich (University of Washington) and Brian Martin (aka "jericho" of Attrition.org), February 23, 2000 Warding off DDoS Attacks: Tools and services help keep servers from being turned into zombies, by Jim Kerstetter, PC Week Online, February 21, 2000 Hacker's Web Weapons Test-Fired on Chat Sites, by Ariana Eunjung Cha, Washington Post, February 19, 2000 Dot-Com firms are hacking each other -- expert, by Thomas C. Greene, The Register, February 18, 2000 NPR's Diane Rehm show (Real Audio), panel discussion on Internet Security with Jeffrey Hunker (National Security Council), James Adams (iDefense.com), David Dittrich (University of Washington) and Elias Levy (SecurityFocus.com) Slashdot interview Universities likely to remain Net security risks, by John Borland, CNETNews.com, February 15, 2000 German programmer "Mixter" addresses cyberattacks, by Stephen Shankland, CNET News.com, February 14, 2000 Hacker discloses new Internet attack software , by Stephen Shankland, CNET News.com, February 14, 2000 Hacker hunters follow lead to Germany -- Web site attackers exploited Stanford computers, CNN.com, February 13, 2000 Hacker probe widens as Canada attacked, by John Greenwood, National Post (with files from Bloomberg News and Dow Jones), February 12, 2000 Doing Away with DoS, by Michelle Finley, Wired, February 10, 2000 DoS: Defense Is the Best Offense, by Chris Oakes, Wired, February 10, 2000 ZDNet Special Report: It's War! Web Under Attack [An over-hyped headline, but aggregates several stories] Hack leads point to California university, by John Borland and Jeff Pelline, CNET News.com, February 11, 2000 Hacker tools may come from single source, by Stephen Shankland, Michael Kanellos, and Mike Yamamoto Staff, CNET News.com, February 9, 2000 Hackers disrupt Web sites, Seattle Post-Intelligencer, February 9, 2000 Was Yahoo Smurfed or Trinooed?, by Declan McCullagh, Wired News, February 8, 2000 o o o o o o o o o o o Yahoo on Trail of Site Hackers, Rueters News Service, February 8, 2000 Yahoo brought to standstill, BBC News, February 8, 2000 Internet attack slows Web to a crawl -- Assault on Oz.net affects entire area, by Dan Richman, Seattle Post-Intelligencer, January 18, 2000 DoS attack programs find warm, safe place on Solaris, by Nora Mikes, SunWorld Magazine, January 2000 Experts Warn of Multipronged E-Mail Assaults: New Software Allows Vandals to Overwhelm Computers , by David Noack, APBNews.com, December 27, 1999 CERT warns of networked denial of service attacks, by Ann Harrison, Computerworld, December 23, 1999 [Corrections to Computerworld article] Malicious programs lie in wait, FBI warns, by Bruce V. Bigelow, San Diego Union Tribune, December 15, 1999 [Corrections to San Diego Union Tribune article] Computer security teams brace for attacks by Stephen Shankland, Staff Writer, CNET News.com, December 20, 1999 [Corrections to CNET News.com article] Net hackers develop destructive new tools, by M.J. Zuckerman, USA TODAY, December 7, 1999 [Corrections to USA Today article] Cyberterrorism hype, by Johan J. Ingles-le Nobel, Janes Intelligence Review, October 21, 1999 Cyber Attacks -- Both Old and New, by Robert Lemos, ZDNet News, October 20, 1999 Humor (from HNN) Benson "The Hacking" cartoon, Arizona Republic, February 13, 2000 Mike Lukovich cartoon, Atlanta Journal-Constitution, February 10, 2000 Hacker Attacks! by all of the top editorial cartoonists (updated regularly) Scanner SATAN (Security Analysis Tool for Auditing Networks) Originally conceived some years ago, SATAN is actually the prototype of a much larger and more comprehensive vision of a security tool. In its current incarnation, SATAN remotely probes and reports various bugs and weaknesses in network services and windowing systems, as well as detailing as much generally useful information as possible about the target(s). It then processes the data with a crude filter and what might be termed an expert system to generate the final security analysis. While not particularly fast, it is extremely modular and easy to modify. SATAN consists of several sub-programs, each of which is an executable file (perl, shell, compiled C binary, whatever) that tests a host for a given potential weakness. Adding further test programs is as simple as putting an executable into the main directory with the extension ".sat"; the driver program will automatically execute it. The driver generates a set of targets (using DNS and a fast version of ping together to get "live" targets), and then executes each of the programs over each of the targets. A data filtering/interpreting program then analyzes the output, and lastly a reporting program digests everything into a more readable format. The entire package, including source code and documentation, will be made freely available to the public, via anonymous ftp and by posting it to one of the numerous source code groups on the Usenet. ISS http://www.iss.com Retina http://www.eeye.com Rootkit ActiveX Java Antivirus Programmes modifiant d'autres programmes ou détruisant des portions sensibles. Beaucoup d'utilisateurs naïfs ont cru à la véracité du virus GoodTimes, un virus qui est sensé se propager par courrier électronique et détruire les données d'un disque dur. Le seul vecteur de propagation de ce virus est la crédulité humaine qui se charge de propager non le virus, mais la rumeur elle-même. Il n'empêche que des portions de code sont transmissibles via email et sont même exécutables via MIME (Multipurpose Internet Mail Extensions). Un interpréteur Postscript peut ainsi être automatiquement activé et exécuter une portion de code véreux. Comme énoncé dans la définition, un virus n’est qu’un programme. Le plus souvent écrit dans un langage proche de la machine, l’assembleur. Ce langage permet de créer du code exécutable très rapide et facilite l’appel à des routines systèmes. Lors de la sortie de Windows 95, la plupart des gens ont crus que ce système d’exploitation allait stoppé la propagation des virus (du fait que ceux-ci était prévu pour un environnement 16 Bits). Il n’en est rien et on n’a même assisté à l’apparition de virus 32 Bits fonctionnant sous Windows 95. D’autres virus ont également vu le jours, tel les macros virus qui utilisent l’interface VBA (Visual Basic pour Application) pour se propager. Il est en effet assez facile de programmer une macro dans un fichier Word pour que celle-ci ce recopie dans un autre fichier Word lorsque ce dernier est enregistré. Les macros virus sont de loin les plus virulent actuellement. Il faut avant tout définir la notion de virus. Commençons par celle d’un créateur de virus (Dark Angel) : « Art de programmation destinée à détruire les systèmes des crétins ». Il est clair que dans ce cas il s’agit principalement de vandalisme. Définition selon Larousse : (mot latin, poison) Informatique : Instruction ou suite d'instructions parasites, introduites dans un programme et susceptibles d'entraîner diverses perturbations dans le fonctionnement de l'ordinateur. Il faut prendre garde aux erreurs de langage. Il existe d’autres programmes destructeurs, à ne pas confondre avec un virus. Voici trois grandes catégories : 1. Les vers (Worms), qui eux sont prévus pour infiltrer un système et détruire, modifier des données ou exécuter une commande. Il ne s’agit plus de vandalisme, il s’agit de crime (ou vol), puisque la cible est bien déterminée. 2. Les chevaux de Troie (Trojan Horses), qui eux sont des programmes semblant totalement inoffensifs mais cachant derrière leur apparence une routine bien déterminée destinée à détruire ou voler des informations. Il existe même des chevaux plus vicieux qui servent à prendre le contrôle d’une machine à distance. Ceci permet une connexion non autorisée. 3. Les bombes logicielles (Logic Bombs), quant à elles sont de véritables bombes à retardement. Ce sont de petits programmes restant inactifs tant qu’une condition n’est pas remplie, une fois la condition remplie (une date par exemple), une suite de commandes est exécutée (dont le but, le plus souvent, hélas, est de faire le plus de dégâts possible). Le premier pas vers les virus : Core War. Au début des années 60, trois informaticiens américains de la société Bell ont consacré une grande partie de leur temps à créer un jeu ésotérique. Ce jeu consistait à lacher deux programmes de combat dans la mémoire vive* de l’ordinateur. Le but du jeu était très simple : le gagnant était celui qui détruisait le premier son adversaire ou celui dont le nombre de copies restantes, après un temps déterminé, était le plus grand. Les techniques de combat étaient très simples (à la base du moins). L’algorithme ayant eu le plus de succès visait à bombarder la mémoire de « 1 » (valeur binaire) ce qui modifiait le programme et le détruisait. Ce jeu, étant réservé aux initiés ne représentait, jusque là, pas de grand danger. Cependant dans les années suivantes ce jeu s’est lentement vulgarisé. Des articles sont parus et un manuel fut écrit. Quelques années plus tard, pour perfectionner les programmes d’attaque, deux italiens ont ajouté une procédure ajoutant des copies du programme sur la mémoire de masse (disque dur ou disquette). Il s’agit presque d’un virus. Mais, accablés par le potentiel destructeur de leur découverte, ils décidèrent de la laisser tomber ce projet. Le premier virus fut réalisé par un étudiant en informatique à l’Université de Californie (Fred Cohen), qui avait pour objectif de créer un programme parasite, une sorte de vie artificielle (ou, du moins, comparable à celle de virus biologiques) capable de se reproduire et de pervertir les programmes. Ce programme fut réalisé dans le but de créer une sorte de vie artificielle autonome, sans la moindre volonté négative. Cependant, cette idée fut vite reprise par des vandales de l’informatique dans le but de nuire. Il y a quelque temps, avant l’adoption de lois strictes sur les virus, certains éditeurs de software, ont vu dans les virus une solution efficace contre la copie. Le meilleur exemple de virus crée à cette intention était le virus pakistanais, distribué largement avec les copies pirates de logiciel vendues au Pakistan (ce pays n’avait pas de loi de concernant les droits d’auteur). Rassurons-nous, c’est aujourd’hui interdit. Dans ces années, on peut aussi citer le fameux virus Michel-Ange qui détruisit des données sur des centaines de milliers d’ordinateurs, le 6 mars 1992. 1949 : John Von Neumann présente les fondements théoriques des logiciels autocopiés. 1960 : Un groupe de jeunes ingénieurs des laboratoires Bell met au point un jeu informatique du nom de Core war : on installe dans la mémoire vive d'un ordinateur deux programmes chargés de se retrouver. Le gagnant doit détruire l'autre en s’autocopiant dans ses fichiers. 1984 : Le magazine Scientific American pressente un guide pour fabriquer ses propres virus. 1986 : Les frères Alvi, deux Pakistanais, fournissent à des touristes des copies de logiciels pirates infectés du virus Brain. Ce serait le premier virus clairement identifié et connu. Il a causé de sérieux dégâts sur les campus américains. 1988 : Peace/Mac affiche son message de paix universelle sur les écrans de possesseurs de Macintosh II. 1988 Robent Morris est arrêté pour fraude informatique. Cet étudiant vient de causer 15 millions de dollars de dommage sur Internet à cause de son virus. 1989 : Datacrime : trois virus font trembler les Pays-Bas et la France. La police néerlandaise propose alors un ensemble de programmes informatiques à bas prix pour lutter contre ces virus. C'est à cette époque que la France prend réellement conscience de l'existence des virus. 1991 : Diffusé par une disquette vendue dans la revue Soft et Micro, le virus Frodo/4096 arrive en France. Le Clusif (Club de la sécurité des systèmes d’information français) propose sur son serveur une procédure de détection et de décontamination pour lutter contre Frodo. Le serveur enregistre 8 000 connexions. 1992 : Le virus Michelangelo plonge la planète dans l’effroi. Ses effets restent pourtant limités : 200 000 machines, au lieu des 5 à 15 millions annoncés. 1998 : D'après les chiffres publiés par Dr Salomon's, éditeur d'antivirus, on recensait 17 745 virus différents en 1998, contre 18 en 1989. Comme je l’ai dit précédemment, le fonctionnement des différents virus sera étudié dans les paragraphes suivants. Cette étude me semble nécessaire pour avoir une connaissance globale du sujet et pour pouvoir aborder les informations qui suivent en connaissance de cause. La programmation d’un virus est très austère, c’est pourquoi, je vais essayer de ne pas employer trop de termes techniques. Il me semble cependant difficile de résumer, dans ce travail, toutes les notions nécessaires n’ayant pas un lien direct à ce domaine, c’est pourquoi, sans la connaissance des bases de l’informatique, il sera quand même difficile de saisir toutes les notions. Une fois le fonctionnement abordé, il nous sera plus facile d’estimer les conséquences et de comprendre comment se protéger. Il existe un grand nombre de formes de virus informatiques qui font varier les propriétés de ceux-ci. Il faut savoir qu’un programme ne peut être appelé virus que s’il a la propriété de se reproduire et de passer d’un système à un autre. Un virus est donc une suite d’instructions comprenant : une séquence destinée à la reproduction, une séquence de commandes, la plus part du temps destinée à la destruction et éventuellement une séquence de camouflage (voir schéma ci-dessus). Les différents types de virus et leurs propriétés sont décrits ci-après. En plus de ces caractéristiques, il existe des virus de bas niveau et des virus de haut niveau. Un virus de bas niveau est un virus fonctionnent directement sous le système d’exploitation (c-à-d sur la machine). Un virus de haut niveau est un virus tournant sous une autre plate-forme. Ce peut être une machine virtuelle (qui est une simulation de machine tournant elle même sur la machine) ou un programme exploitant le principe des macros. Evolution des virus : Les virus « classiques » commencent à disparaître pour céder leur place aux virus plus polyvalents (virus de haut niveau). Ceci est dû à la diminution d’échange de programmes (contenant les virus classiques) et l’augmentation d’échange de documents pouvant contenir des macros ou des applications intégrés au document (sources : traitements de textes, tableurs, documents sur Internet Les différents types de virus A. Les virus « classiques » Cette catégorie regroupe les virus infectant soit le Secteur d’amorçage du disque (disque dur ou disquettes), soit les fichiers, soit les deux. Il existe encore les Virus polymorphiques qui eux s’encryptent de façon à paraître à chaque fois différents, et les virus résidents en mémoire vive (c-à-d RAM), plus résistants. Voici une description des caractéristiques citées ci-dessus : a. Virus infectant le Boot sector (secteur d’amorçage) : Il s’agit d’un virus infectant la partie faisant démarrer l’ordinateur. Ces types de virus sont de nos jours peu contagieux. Pour qu’un ordinateur soit infecté, il doit être démarré avec un secteur d’amorçage infecté, ce qui était courant sur les premiers ordinateurs mais qui est rare aujourd’hui. Pourtant ce genre de virus est fort dangereux. En effet, il se trouve dans le premier secteur du disque et est donc chargé à chaque allumage de l’ordinateur. Le secteur d’amorçage du disque est le premier secteur lu au démarrage de l’ordinateur. Ce genre de virus a donc un contrôle complet de la machine, puisqu’il est chargé en premier. Ce peut être un des virus les plus difficiles à déceler et/ou à éradiquer, vu l’« incrustation » du virus dans le système. Ce genre de virus est actif à partir du moment où on allume l’ordinateur, jusqu’au moment où on l’éteint. Mais pourquoi le secteur d’amorçage d’un ordinateur n’est pas protégé contre l’écriture ? Le secteur d’amorçage est typique au système d’exploitation, donc variable. Il est du coup nécessaire de pouvoir le modifier si l’utilisateur désire changer de système d’exploitation. Ceci dit ce genre de virus est en voie de disparition : il est de plus en plus rare d’amorcer sa machine avec une disquette ou un disque dur de quelqu’un d’autre. b. Virus infectant les fichiers (parasites) : Voir schéma. 1. Non résident : c’est probablement le virus le plus répandu des virus classiques. Lors de l’infection, il cherche un fichier cible, et remplace, par sa section virale, le premier segment du programme. La section originale est alors ajoutée en fin de programme. Au moment de l’exécution du fichier, c’est le code viral qui est d’abord lancé. Ce code viral cherche d’autres programmes à infecter, il les infecte. Ensuite il restitue la première section du programme infecté et exécute celui-ci. La boucle est bouclée. Le virus a pu se propager de façon tout à fait invisible. Il s’agit donc d’un virus fort contagieux. La détection de ce genre de virus est pourtant assez aisée, le fichier infecté étant plus grand que le fichier sain, puisqu’il contient le virus en plus du programme. 2. Virus résidents : Il s’agit de virus qui restent présent dans la mémoire de l’ordinateur (RAM, à ne pas confondre avec le disque dur qui peut aussi être appelé mémoire). Fonctionnement : Une fois un fichier infecté exécuté (NB : ce fichier infecté vient soit d’une source infectée, une source douteuse, soit d’un autre fichier infecté précédemment), le virus se loge dans la mémoire vive, ou il reste actif. Dès qu’un programme est exécuté et qu’il n’est pas infecté, le virus l’infecte. La différence avec celui vu en point 1 est qu’il n’y a pas besoin de procédure pour trouver une cible, puisque c’est l’utilisateur qui la désigne en exécutant le programme cible. Ce genre de virus est actif à partir du moment où un programme infecté est exécuté jusqu’à l’arrêt complet de la machine. Certains d’entre eux peuvent résister au simple redémarrage (c-à-d : CTRL – ALT – DEL). 3. Virus multiformes : Virus regroupant les caractéristiques des virus parasites et des virus du secteur d’amorçage. 4. Les autres caractéristiques des virus : a. Virus furtifs (intercepteurs d’interruptions) : ce sont des virus modifiant complètement le fonctionnement du système d’exploitation. Ces virus le modifient tellement qu’il semble sain aux antivirus. Ceci les rend très difficiles à détecter, puisque les antivirus sont trompés, croyant le système d’exploitation sain. b. Virus polymorphes (mutants) : ce virus est différent à chaque infection. Il doit ceci à son encryption (Il existe un algorithme reprenant une valeur au hasard, permettant d’avoir un fichier crypté à chaque fois différant ne dérangeant cependant pas le décryptage). Le programme entier et le virus sont encryptés, excepté le premier segment destiné à la décryption. Ce genre de virus est donc beaucoup plus difficile à détecter que les précédents et presque impossible à détruire sans supprimer le fichier infecté, vu qu’il est crypté. c. Virus réseau : Ces virus se reproduisent dans les réseaux en prenant le contrôle des interruptions. d. Virus flibustiers (Bounty hunters) : virus visant la modification des antivirus les rendant non - opérationnels. Ce genre de virus est très rare mais très efficace. Il faut savoir que un virus peut regrouper une, plusieurs, voire toutes les caractéristiques vues cidessus. Plus le virus a de caractéristiques, plus il sera dangereux, compliqué, vorace en ressources de l’ordinateur (du à sa complexité). Ce qui signifie gênant sans même être actif, et surtout difficile a détecter par un antivirus (trompé, rendu inactif, ...) mais aussi plus facilement repérable, et ce, dû à la baisse des performances de la machine. Schéma de l’infection du virus classique : (Les numéros correspondent à l’ordre d’exécution du fichier) B. Les virus d'Internet Avec l’apparition d’Internet, de nouvelles opportunités se sont ouvertes pour les créateurs de virus telles Java et ActiveX. Ces deux langages de programmation sont destinés à la création de pages Internet interactives, multimédia et ergonomiques. a. Java Java est un langage de programmation proche des autres langages, les applications Java ont les mêmes caractéristiques que tout autre programme. L’avantage, au niveau sécurité, est que pour exécuter tout programme Java, il faut une intervention de l’utilisateur (exécution du fichier sur une machine virtuelle) et donc empêche toute exécution spontanée. Ce qui donne un contrôle relatif à l’utilisateur. Par contre les applets* java sont, quant à eux, différents. En effet, il s’agit d’applications développées et inclues spécifiquement pour les « Browsers », faites pour s’exécuter lors de la visite d’un site. Ici, par contre, nous sommes face à un danger plus grand au niveau virus. Heureusement, on a mis en place quelques mesures de sécurité : il n’est pas possible d’exécuter un programme ou une librairie DLL (qui peuvent aussi être infectées) sur la machine cible (empêchant donc tout dommage par l’exécution d’un programme tel un virus, un cheval de Troie, ou ver, …) - L’applet (= programme Java) ne peut pas lire ou écrire des fichiers sur la machine l’exécutant. Ceci est la meilleure protection contre les programmes vandales. Cependant l’applet peut lire et écrire sur la machine virtuelle (principe : une machine virtuelle est exécutée sur l’ordinateur, sur laquelle est exécutée l’applet, permettant aux applets d’être universels : ils fonctionnent sur Pc & Mac). Des informations confidentielles sont parfois stocké dans la machine virtuelle. On peut en outre imaginer une future génération de virus n’infectant que les machines virtuelles. Mais celle-ci serait donc limitée aux machines virtuelles – Les applets ne peuvent pas établir d’autres connections que celles avec l’hôte original du programme (site Internet ou se trouve l’applet*), empêchant donc toute connexion à distance non souhaitée. Ceci n’empêche toutefois pas une violation de la vie privée ! (N.B. : les données lisibles par les applets sont quand même limitées) Attention : Le téléchargement d’un applet pour l’exécuter en dehors du « browser » est aussi dangereux qu’exécuter un autre fichier. Il semble cependant qu’il y ait moyen de forcer ce système en « plantant » la procédure de test (celle qui vérifie si les conditions ci-dessus sont respectées). En « plantant » une partie de la machine virtuelle, il est possible de rendre inopérante la fonction de vérification. Ce qui ouvrirait une porte aux virus. b. ActiveX ActiveX est la réponse directe de Microsoft à la parution de Java. Il s’agit aussi de petits scriptes exécutables sur la machine client ( = machine de la personne qui visite le site web, par exemple). Si, tout comme pour Java, il y a une machine virtuelle, celle-ci se contente de traduire les commandes, ce qui signifie que, contrairement à Java, il n’existe aucune restriction pour les programmes ActiveX quant à l’accès aux fichiers. Ceci représente une énorme faille dans les systèmes, rendant une infection très facile. Microsoft espérait que son ActiveX ne serait pas utilisé à des fins destructrices. c. Les Cookies Le cookie est une suite de caractères fournie par le serveur lors de la première connexion. Par la suite, lors d'une reconnexion, le browser restitue le cookie pour pouvoir permettre l'identification de l'utilisateur. Il s'agit d'un processus d'identification, il ne contient donc aucun code de programme (ceci ne permet pas l'intrusion d'un virus). Le cookie peut cependant montrer des limites vis-à-vis de la vie privée (tracking des surfers pour analyser leurs goûts) mais n'est pas lié aux virus. C. Les virus macro Avant de commencer toute analyse, il faut définir la notion MACRO. « Une macro est une série de commandes destinée a effectuer automatiquement quelques tâches d’une application spécifique ». (Définition : Intro to macro viruses, site de l’antivirus Dr Solomon). Certains programmes autorisent à leurs macros un accès aux fichiers, c’est à partir de ces programmes qu’il est possible de créer des macros se recopiant par elles même. On peut dès lors les appeler virus (C.F.R. def. Virus). Le premier virus macro (DMV : infecte WORD) fut écrit par J. McNamara dans un but de démonstration. Le but était de prouver qu’il est possible de créer de tels virus. Les premiers virus macros destructeurs apparurent en été 1995. Ils infectaient presque tous Word. Atom, dont le script se trouve en annexe est un des premiers virus macro. Le nombre de virus macro devrait avoisiner les 1 800 (on en découvre plus de 5 chaque jour). Le fonctionnement d’un virus macro est relativement simple : Soit, il recherche des fichiers cible et les infecte (comparable aux virus classiques), soit, le virus infecte un fichier appelé NORMAL.DOT Ce fichier pourrait être comparé au secteur d’amorçage du programme. (voir anexe : il se copie dans le normal.dot). Celui-ci peut aussi contenir des macros. Or il existe des noms de macros qui sont exécutés automatiquement lors d’une action donnée (AutoExit, quand on quitte le programme ; AutoClose, lorsque l’on ferme un document, AutoOpen, quand on ouvre un fichier, …). C’est donc ainsi que le virus se répand. De manière générale les virus ont quelques caractéristiques supplémentaires qui les caractérisent : - Infection ou non du fichier NORMAL.DOT (ou équivalent). - Modification des menus. Save As (sauvant le virus en plus du document), par exemple. - Emploi de raccourcis clavier, c’est à dire qu’ils entrent en action dès qu’on tape une certaine combinaison de touches (Pex. : « t » ou « s »). - Sauvegarde de la macro dans ou hors du fichier infecté. - Certains dissimulent le menu macro empêchant le contrôle des macros. Et d’autres modifient ce menu de telle façon qu’il semble vide. - Virus et/ou données encryptées par mot de passe - Infection de fichiers exécutables (com, exe,…). « L’avantage » de ces virus est l’évolution des macro. En effet, un virus prévu pour Word 2.0 ne fonctionnera probablement plus sous Word 6.0. La plupart des virus macro se limitent à infecter les fichiers document mais il en existe aussi certains infectant les fichiers exécutables de DOS (et donc Windows aussi ! exemple : Anarchy.6093). Ces virus sont à la fois classiques et des virus macro. D. Windows 95 et les virus Dans ce paragraphe nous allons voir les « réactions de Microsoft Windows au différents types de virus. A. Windows 95 et les virus infectant le Boot sector. Il faut savoir avant tout qu’on a ajouté dans Windows 95 (par rapport aux versions précédentes) un test du boot sector (Emplacement du disque où sont enregistrés les fichiers de démarrage : IO.SYS ; MSDOS.SYS et COMMAND.COM). D’après Microsoft ce test devrait détecter toute intrusion de virus de type Boot sector. Ce n’est malheureusement pas toujours le cas. Des tests ont été effectués par la société ayant créé Dr Solomon antivirus montrant que si avec certains virus, le message était bien affiché : « WARNING : Your computer may have a virus. The Master Boot Record on your computer has been modified. Would you like to see more information about this problem ? », avec d’autres, il s’est avéré que la protection de Windows était bien peu efficace. En effet, dans certain cas, l’ordinateur redémarrait normalement, dans d’autres, il redémarrait avec un ou plusieurs de ses disques en mode compatibilité DOS (ce qui signifie que Windows ne sait pas gérer ce disque) et même parfois l’ordinateur refusait de démarrer (défaut de programmation du virus ou qualité spéciale ?). Microsoft a récemment intégré un nouveau système de gestion de disque (FAT32 mais je ne rentrerai pas dans les détails) qui permet d’« optimiser » le (ou les) disque dur. Ceci modifie radicalement le Boot Sector compliquant encore la tâche des virus. En effet il y a très peu de virus prévus pour fonctionner avec ce type de FAT. Le nombre d’erreurs (tel le « plantage » du système au démarrage ou encore la perte de données) se multiplie donc en présence d’un virus. B. Windows 95 et les virus infectant les fichiers Il faut pour commencer remarquer que le système de fichiers de Windows 95 est très proche de celui de ses prédécesseurs (Ms-Dos). Il n’y a en fait presque aucune différence à ce propos. La plupart des virus de fichiers continuent à fonctionner même si quelques vieux modèles de virus ne fonctionnent plus du tout. C. Windows 95 et les virus macros Il n’y a aucun changement de ce point de vue étant donné que ces virus dépendent directement du programme sous lequel il tourne. Ceux-ci jouent un rôle de machine virtuelle. Pex. : Word ou Excel. N.B. : De nouveaux virus ont étés développés spécialement pour ce système d’exploitation et sont d’autant plus redoutables! Et, si certains virus se sont éteints du à leur non-compatibilité avec Windows, il y en a toujours plus pour prendre leur place. a. Prévention : 1. Les boucliers (comparables aux anticorps) sont des programmes résidents dans la mémoire vive de l’ordinateur. Ceux-ci vérifient chaque fichier avant toute utilisation (lecture, écriture). Cette vérification consiste en une comparaison du fichier avec une banque de données reprenant les signatures des virus connus. Les signatures des virus sont des suites de caractères, propre à chaque virus informatique, comparables aux codes génétiques des virus biologiques. C’est leur caractère, c’est ce qui les définit. Si la recherche est fructueuse, si un virus est trouvé, alors le bouclier stoppe l’action en cours (lecture ou écriture) et demande que l’utilisateur intervienne. NB : Ce genre de système de prévention ralentit la machine. De plus, il faut une mise à jour fréquente de la base de donnée de signatures. 2. Les vaccins. Crées pour la première fois par un groupe de jeunes Allemands pour neutraliser le virus qui faisait alors des ravages. Ce sont des vrais « virus », tout autant contagieux. Cependant, leur code destructeur à été enlevé. Ainsi le virus se propage mais ne détruit plus. Le virus actif considère alors le fichier (contaminé par le vaccin) déjà contaminé et ne le l’infecte plus, grâce à une procédure de test qui vérifie si le fichier est déjà infecté. Ce genre de test chez le virus est toujours présent. Sans ce test un virus pourrait contaminer un fichier plusieurs fois, ce qui réduirait fortement les performances de la machine et mangerait beaucoup d’espace disque (En effet : les programmes grossiraient à chaque infection, ce qui les rendrait plus compliqués et donc plus lents). Ce phénomène est opposé au phénomène des vaccins biologiques, qui, quant à eux stimulent les anticorps, de sorte qu’ils soient capables de neutraliser le virus actif. NB : Ce genre de vaccins n’est pas retenu dans la lutte contre les virus car il faudrait infecter chaque fichier avec chaque vaccin pour chaque virus ce qui ralentirait et encombrerait énormément la machine (de plus en plus de commandes exécutées pour un même programme). De plus, l’emploi de vaccins simultanément peut être explosif (rappel : les vaccins sont des virus et ne sont donc en aucun cas prévus pour cohabiter). b. Détection 1. Les programmes surveillants (comparables aux symptômes de maladie) sont des programmes généraux qui vérifient si les points sensibles d’un système (command.com, io.sys, msdos.sys, win.ini, …) n’ont pas été modifiés. NB : ce genre de système donne de nombreuses fausses alertes, vu que certains programmes modifient les fichiers systèmes. 2. Les programmes d’analyse (antivirus) sont des programmes comparables aux globules blancs qui vérifient successivement tous les fichiers contaminables. Pour cela, il effectue, comme le bouclier, une comparaison de chaque fichier avec une banque de signatures. NB : Il est nécessaire de consacrer du temps à la détection et il faut des mises à jour de la banque de données fréquentes. La différence avec le bouclier est que celui-ci est prévu pour détecter un maximum de virus alors que les boucliers sont optimisés pour fonctionner très vite en faisant une détection superficielle et ne pas « manger » trop ressources. c. Eradication 1. La suppression pure et simple (comparable aux macrophages) : ce peut être la suppression du fichier contamminé, le formatage de haut niveau du disque (formatage de la partition), la réécriture des partitions du disque, ou encore un formatage de bas niveau du disque (aucun virus ne résiste à ceci). 2. La réparation du fichier contaminé. Etant donné que les virus ne se propagent que s’ils n’attirent pas l’attention de l’utilisateur, ils laissent le programme hôte intact (le programme se retrouve en entier dans le fichier) mais modifié (sur le disque), ce qui rend la réparation possible. Cette réparation se fait à l’aide d’un antivirus. La réparation se fait en supprimant les parties du virus et en reconstituant le programme d’origine en remettant ses parties dans le bon ordre. NB : On doit analyser chaque nouveau virus pour créer un moyen d’éradication. En conclusion, mis à part leur milieu d’action différent, les virus Biologiques et les virus Informatiques sont comparables, tant sur le plan de leur propagation que sur leur action. Conséquences A. Informatiques Les conséquences d’un virus ne sont pas toujours aussi graves qu’elles en ont l’air. En effet un virus est un programme qui se multiplie (définition). Cependant si un ordinateur est atteint d’un virus qui ne fait que se reproduire, il n’y aura aucune autre conséquence qu’une perte de place sur le disque dur, et une faible perte de vitesse. Ces virus sont des virus vivant généralement en harmonie avec les systèmes pour lesquels ils sont prévus. Malheureusement tous les virus ne sont pas comme cela. Tout comme pour les virus biologiques, il existe des virus de toutes sortes. Cela signifie aussi qu’en plus des virus inactifs il y a des virus bénins qui affichent des petits messages gentils (ou non) de temps en temps, n’empêchant aucunement de travailler. Par contre d’autres sont plus ennuyeux, il s’agit de virus qui paralysent ou ralentissent très fort les machines, de façon à les rendre la machine « cible » improductive. Les virus cités ci dessus sont des virus anodins pour les données ou la machine. Car dans la plupart des cas, il est possible de continuer son travail, plus tard, après les effets de celui-ci. Malheureusement, il existe des virus destructeurs. Ces derniers détruisent de façon, souvent irrécupérable des données et/ou programmes. D’autres conséquences de ceux-ci peuvent être la destruction, au premier sens du terme, de matériel informatique, Pex. : le flashage du BIOS des cartes mères (modification du code de la puce reprenant les informations concernant le matériel présent dans la machine et nécessaire au démarrage du PC), ce qui oblige la victime à ramener sa carte mère ou son PC au magasin. Ou la modification d'un secteur du disque dur avec des paramètres volontairement erronés obligeant un reformatage bas niveau, ce qui n'est pas toujours possible (merci à PierreGregory). Il est encore possible, sur certaines machines, du moins, de détruire l'écran ou disque dur (ce dernier point n’est pas reconnu comme vrai par tous les textes que j’ai lu. Il semble cependant qu’il soit possible de démolir un écran en réduisant la résolution à un pixel et en envoyant toute « l’énergie » sur ce pixel, ou encore de détruire un disque dur en frappant rapidement la tête du disque dur contre le buttoir, ce qui la désalignerrait). Il est aussi possible de détruire une puce informatique (telle un processeur) en la portant à une température supérieure à 80°C durant quelques minutes. Ceci est possible en poussant les recources du processeur hors de ses limites, ce qui est faisable avec certaines cartes mères permettant un contrôle logiciel des ressources matérielles (la technologie jumperless). B. Economiques – au sein d’une entreprise Ce phénomène est un problème sérieux dans notre société. Le budget passant dans la protection contre les dépasse l’imagination. En 1998, 40 millions d’euros ont été dépensés (en France) pour l’achat d’antivirus. Mais si le budget investi dans la protection contre les virus est si élevé c’est que la perte en cas de destruction de données serait encore plus élevée. Or il est difficilement possible d’envisager tous les effets que pourrait engendrer une perte de données dans une société, vu la diversité des types d’entreprises. C’est pourquoi, un créateur de virus peut être condamné à payer une amende de 46 000 euros et à 3 ans de prison ferme Audit Authentification La première étape dans tout mécanisme de sécurité, c'est l'authentification. Pour savoir si un utilisateur a accès ou non à certaines ressources, il faut être sûr de son identité. Il existe plusieurs techniques, plus ou moins valables, que nous allons passer en revue. Les passwords Le password est secret et est attaché à un utilisateur. Seul l'utilisateur connaît le password. C'est une vieille méthode, utilisée bien avant les premiers ordinateurs, et qui a ses failles: La sécurité n'est assurée que si le fichier de password reste secret. Même si les passwords sont cryptés dans le fichier, il vaut mieux qu'il ne soit pas accessible. Il est toujours possible de forcer quelqu'un à dévoiler son password, par la force, par chantage, par sa secrétaire,... Il est possible d'intercepter un password, au moment où l'utilisateur le tape sur son clavier, ou au moment où il transite sur le réseau. Les passwords sont souvent mal choisis: prénom, nom de son chien, plaque de voiture, date de naissance,... On peut donc les deviner assez facilement. Certains dictionnaires regroupant des passwords courants existent d'ailleurs. S'ils sont retenus par coeur, il doivent revêtir un caractère logique: un mélange de morceaux de mots, souvent groupés en syllabes prononçables. S'ils sont écrits, il y a toujours un risque de découvrir l'endroit où il sont stockés. Un password ne venant jamais seul, on a de forte chances de tomber sur d'autres informations confidentielles. Ils changent rarement. Si vous possédez le password de quelqu'un, vous pourrez bénéficier de son accès tant qu'il ne changera pas de password, c'est à dire pendant longtemps... Certains de ces défauts peuvent être évités, en utilisant les techniques simples suivantes: Sous Unix, rendez la liste de password illisible par les utilisateurs normaux en utilisant les Shadow Passwords. Forcez les utilisateurs à changer fréquemment de password. Vous pouvez facilement écrire un script qui fait cela automatiquement tous les jours. Refusez les mots de passe triviaux ou trop courts. Un bon mot de passe doit contenir 8 signes au minimum, être composé de lettres majuscules et minuscules et de chiffres. Vous pouvez remplacer des lettres par des chiffres qui y ressemblent. (Exemple: SpiderMAN devient 5p1derMAN) Sous Unix, utilisez Crack: il teste à l'aide d'une série de dictionnaires si les passwords ne sont pas trop simples à deviner, ou si ce ne sont pas des password courants (gibson, toyota,...). Il essaye aussi toutes les combinaisons avec les noms de logins, les initiales,... Si vous utilisez Crack sur une liste de quelques dizaines de passwords de personnes normalement constituées, vous serez certain d'en découvrir quelques-uns. Enormément de gens mettent comme passwords des "mots" de deux lettres, ou leur nom de login suivi d'un chiffre,... L'équivalence Il ne s'agit pas à proprement parler d'une authentification, mais plutôt d'une dispense d'authentification... Afin d'éviter de toujours devoir entrer son password lorsqu'on passe d'une machine à l'autre, on a mis au point une authentification par équivalence. Le principe est de dire: si un utilisateur demande un accès à partir d'une machine A d'un réseau vers une autre machine B du réseau, alors, je peux demander à B une dispense d’authentification pour A, c'est à dire que je n'ai pas besoin de lui demander son password. En effet, s'il est déjà connecté sur une machine du réseau, cela signifie qu'il s'est déjà authentifié correctement sur cette machine et donc, qu'il est superflu qu'il le fasse une seconde fois. Ce système est utilisé en pratique sur des réseaux de machines Unix. Pour éviter de rentrer son password chaque fois qu'on ouvre une application sur une autre machine, on rend des machines équivalentes. On fait confiance à la machine A et on dit que si l'utilisateur a légitimement pu se connecter sur A, alors, il peut aussi légitimement se connecter sur B. Ce système est extrêmement dangereux et il convient de bien surveiller quelles machines ont le droit de faire cela! Si c'est possible, n'utilisez pas cette méthode et refusez toute authentification par équivalence. Kerberos Kerberos est aussi un système d'authentification développé au MIT. L'authentification se fait auprès d'un serveur Kerberos qui vous délivre un ticket. C'est ce ticket qui va ensuite vous identifier comme utilisateur auprès des clients qui utilisent Kerberos. Un ticket a une durée de vie fixe et un nouveau ticket doit être délivrée par le serveur Kerberos dès que sa durée de vie est écoulée. Attention: Le principe utilisé dans Kerberos étant la cryptographie à clé publique, le serveur Kerberos doit être physiquement inaccessible. En pratique, Kerberos est rarement utilisé parce que c'est un système assez lourd. En plus, il a été développé au MIT, pour le MIT et pas pour les autres. Il ne s'agit donc pas d'une solution très adaptée, mais il faut savoir que cela existe. Crypto Card Plutôt que d'utiliser un password, qui a tous les désavantages que l'on vient de voir, on peut utiliser une carte électronique pour s'authentifier. C'est par exemple la technique utilisée si vous faites du Home Banking chez vous. On vous livre une petite carte (un DigiPASS) qui ressemble à une calculatrice: c'est en fait un automate cryptographique à algorithme RSA. La clé privée se trouve dans une puce située dans votre DigiPASS. La clé publique se trouve, elle, dans sur le serveur sur lequel vous devez vous identifier. Pour vérifier que vous êtes en possession de la bonne clé, le serveur vous donne un défi à signer avec la clé privée de votre DigiPASS. Un défi n'est rien d'autre qu'un nombre, le plus souvent de 12 chiffres. Vous entrez ce nombre dans votre DigiPASS et vous lui demandez de le signer avec sa clé privée. Vous n'avez plus qu'à renvoyer la signature (le plus souvent de 6 chiffres) au serveur. Celui-ci est en possession de votre clé publique et peut donc vérifier si la signature appliquée est celle que l'on attendait. Que se passe-t-il si on vous vole votre DigiPASS? Là non plus, pas de problèmes, on a pensé à tout! La mémoire du DigiPASS est aussi protégée par un mot de passe. Si un mot de passe erroné est entré trois fois de suite, la puce est brûlée par une surtension électrique à ses bornes, ce qui la rend tout à fait inutilisable. Pour craquer le système, il faut donc disposer du DigiPASS et de son password, ce qui fait beaucoup de malchance! A l'heure actuelle, cette méthode est l'une des plus sures et des plus faciles à utiliser. Autres authentifications Il existe encore d'autres méthodes qui sont rarement utilisées pour des authentifications classiques sur des ordinateurs, en raison du manque de commodité. De plus, la plupart d'entre elles ne sont pas encore parfaitement au point. Citons en vrac les authentifications: par la voix par les empreintes digitales par une photo de la rétine par empreinte volumique de la main (méthode utilisée aux Jeux Olympiques d'Atlanta) par analyse de l'écriture par analyse morphologique (analyse des traits du visage) Autorités de certification Les certificats numériques Les certificats numériques sont importants en cryptographie à clé publique, parce qu'ils garantissent qu'un intermédiaire n'espionne pas les échanges. Pour envoyer ou recevoir des messages en utilisant les clés publiques, un utilisateur doit posséder deux clés cryptographiques, l'une secrète, l'autre publique. Ces clés sont de longues suites de 0 et de 1 (entre 500 et 1 000 chiffres binaires). L'utilisateur garde sa clé secrète dans un endroit sûr, chiffrée sur un disque dur par exemple, mais il distribue sa clé publique à ceux avec qui il veut communiquer. Supposons qu'Alice veuille envoyer à Bernard un message authentifié, c'est-à-dire un message dont Bernard saura de façon certaine qu'il vient d'elle. En utilisant sa clé secrète, Alice crée une signature numérique qu'elle joindra au message. Puis, en utilisant la clé publique d'Alice, Bernard vérifiera cette signature. Cependant, comment Bernard saura-t-il que la clé publique appartient effectivement à Alice? Un imposteur pourrait créer sa propre paire de clés et envoyer sa clé publique à Bernard en prétendant qu'elle appartient à Alice. On évite cette fraude en utilisant une autorité de certification, qui fournira un certificat numérique sur la clé publique reconnu par tous. Plusieurs entreprises, telles VeriSign ou GTE CyberTrust, délivrent des certificats numériques. Ainsi, le certificat numérique est l'analogue informatique de la carte d'identité. Warwick Ford, VeriSign 1. À l'aide des logiciels de cryptographie, Alice crée une clé secrète (a) ainsi qu'une clé publique (b). Elle envoie la clé publique à une autorité de certification, à qui elle demande un certificat numérique. Pour authentifier Alice, cet organisme vérifie les informations fournies par Alice. Si 2. tout est en ordre, l'organisme de certification envoie un certificat numérique (c) qui authentifie la clé publique d'Alice. Sur ce certificat se trouve la signature numérique du tiers de confiance qui peut être vérifiée par toute personne connaissant la clé publique de cet organisme. La clé publique (d) de l'autorité de certification est fournie à ceux qui en ont besoin, dont Bernard. Elle peut être incluse dans les programmes de navigation sur le réseau Internet et dans d'autres logiciels utilisés pour les communications informatiques sécurisées. 3. Alice signe numériquement le message qu'elle envoie à Bernard. Tout d'abord, elle crée un condensé du message en lui appliquant une fonction de hachage. Le condensé ainsi créé est ensuite chiffré à l'aide de la clé secrète d'Alice ce qui donne la signature numérique du message (e). Cette signature est envoyée à Bernard en même temps que le message (f). Alice envoie aussi son certificat numérique, qui contient sa clé publique. 4. Bernard utilise la clé publique correspondant à l'autorité de certification pour vérifier la signature numérique officielle apposée sur le certificat. Il est alors certain que le certificat est authentique et que la clé publique qui l'accompagne appartient à Alice. Il utilise alors cette clé pour déchiffrer la signature numérique d'Alice et obtient donc le condensé du message. Enfin, Bob applique la fonction de hachage au message envoyé par Alice et obtient ainsi un condensé du message. Si ce condensé est identique à celui qui est obtenu par le déchiffrage de la signature numérique d'Alice, Bernard est certain que le message provient bien d'Alice et qu'il n'a pas été altéré par une tierce personne. Backup Biométrie Cisco Contrôle d’intégrité Tripwire Cryptographie Lorsque on sait que le canal de communication n'est pas secret, ou lorsqu'il nous est impossible de le rendre secret (téléphone, Internet,...), il faut crypter nos données de manière à ce qu'elles ne soient lisibles que par un groupe défini et précis de personnes, en possession de la clé de décodage. C'est le seul moyen de transférer des données de manière sûre dans un canal de communication qui peut être facilement espionné. La cryptographie est utilisée depuis Napoléon dans des tas d'applications, et notamment dans les affaires gouvernementales et dans l'armée. Il ne faut pas croire que les gens qui utilisent la cryptographie sont tous des vandales, des délinquants ou des pirates. Il y a des tas de raisons pour crypter un message, comme il peut y avoir des tas de raisons pour lesquelles vous envoyez une lettre sous enveloppe et non sur une carte postale. En Belgique, l'encryption n'est pas encore interdite. Ce n'est malheureusement pas le cas chez nos amis Français qui doivent demander une autorisation spéciale pour utiliser des systèmes cryptographiques et doivent, en plus, déposer un exemplaire des clés auprès d'une instance compétente. Profitons du fait que l'on puisse encore s'en servir pour voir quelques algorithmes... Cryptographie à clé unique Comme son nom le laisse supposer, cet algorithme se base une clé unique pour les deux parties. C'est donc la même clé qui est utilisée pour le codage et le décodage. Appelons K la clé unique. Imaginons que deux parties (A et B) veulent s'échanger un message secret. A va chiffrer un message (que nous noterons alpha avec la clé unique K. Il applique K à alpha, ce qui nous donne le message K(alpha). Pour que B puisse décoder le message, il va appliquer K au message reçu. Ce qui nous donne K(K(alpha)), c'est à dire le message alpha original. Cette méthode présente d'énormes désavantages: Si une personne entre en possession de la clé, elle peut non seulement lire tous les messages échangés par les parties, dans les deux sens, mais aussi se faire passer pour une des parties en chiffrant le message avec la clé. L'échange des clés doit se faire par un canal tout à fait sûr, pour éviter que quiconque n'en prenne connaissance. Pour faire les choses correctement, il faudrait une rencontre physique entre les deux parties pour procéder à l'échange des clés, ce qui n'est pas toujours possible. On est obligé d'avoir une clé unique pour chaque paire de correspondants. C'est assez lourd à gérer. Pour obtenir une certaine résistance à la cryptoanalyse, les clés doivent êtres assez longues. Si quelqu'un se trouve en présence d'un texte crypté avec la clé et du texte en clair qui y correspond, on peut assez facilement en déduire la clé de codage. Comme on le voit, cette méthode, utilisée pendant le guerre dans des grosses machines ressemblant à une machine à écrire, souffre de nombreuses lacunes. A l'heure actuelle, cette méthode n'est presque plus utilisée pour des applications un peu sérieuses. Méfiez-vous néanmoins des programmes soit disant sérieux utilisant un algorithme secret. En effet, si se dernier doit rester secret, c’est qu’il est, dans la plupart des cas, faible au niveau cryptographique et par conséquent facilement cassable. RSA Au lieu d'avoir une clé unique et secrète, chaque partie génère une paire de clés. Une des clés est dite publique et l'autre privée. Comme leur nom le laisse supposer, une des clés peut être librement distribuée à tous les correspondants, tandis que l'autre doit rester secrète. Toute l'astuce consiste en cette propriété remarquable: Notons Pu la clé publique, Pr la clé privée et un message quelconque. Pu (Pr())=Pr(Pu()= Autrement dit, la clé publique annule le cryptage de la clé privée et la clé privée annule celui de la clé publique. Les clés publiques et privées sont comme matière et antimatière. Garantir l'origine d'un message Avec ce système de clés, on peut aussi être sur de l'identité de la personne qui nous envoie un message. Soient les personnes et . envoie un message à et alpha veut prouver que c'est bien lui qui envoie le message. Voici ce qui va se passer lors du codage: P (P ()) u r crypte le message avec sa clé privée et avec la clé publique de . Lors du décodage, n'aura qu'à appliquer un décodage avec sa clé privée, et un second avec la clé publique de . Le message final sera alors: Pr(Pu(Pu (Pr())))= ..ce qui est bien le message original! RSA en pratique PGP PGP (Pretty Good Privacy) est un programme d'encryption de fichiers, que ce soient des textes ou des programmes. Il peut encrypter les fichiers en ASCII pour ensuite ler insérer dans des messages. Vous pouvez ainsi échanger de manière tout-à-fait sûre tous les messages que vous voulez. La robustesse d'une clé à 1024 bits est telle que vous pouvez être certain qu'elle résistera à un supercalculateur actuel. ( Par exemple un CRAY Y/MP) pendant au moins quelques milliers d'années. PGP permet en plus de signer un message pour en garantir l'authenticité. Imaginons que je vous envoie, sur Internet, un message pour vous dire que le cours est reporté. Cela pourrait très bien être quelqu'un d'autre qui l'écrit, en se faisant passer pour moi rien que pour vous causer des ennuis. Vous devez donc toujours douter d'un message qui n'est pas signé par une méthode sûre. Voici un exemple de message signé avec ma clé, en utilisant le programme PGP: -----BEGIN PGP SIGNED MESSAGE----Vive les cours de la technothèque! C'est [email protected] qui le dit... -----BEGIN PGP SIGNATURE----Version: 2.6.3i Charset: noconv iQCVAwUBMjNO92mx20WXHjsFAQGgcAP8C1sGZaqMnh7gAvKT4dBsCGDkBfFtiuV0 k3Xcre4j3mJpYqsGdTg/4FbZuaEQx4RracFZvqTrYXsM2Wm/sgCYbk604rB4j7V6 WrTZEGrmj5G0yxc2B8aaKq1/lNAo85Lx0mo1NKxJvqV6V1xT5jlkR7xfvdvcvaJD CrL3DNG4UGw= =Kxu6 -----END PGP SIGNATURE----- Vous pouvez vérifier, si vous êtes en possession de ma clé publique, que je suis bien l’auteur du message, et qu'il n'a pas été modifié. En effet, ce message étant signé avec ma clé privée, vous pouvez vérifier ma signature avec ma clé publique. De plus, comme je suis le seul à disposer de ma clé privée, je suis le seul à pouvoir faire une signature qui correspond à ma clé publique. SSH Secure Shell Lorsque vous vous connectez à distance sur une machine avec un remote shell de type Telnet, rsh, rlogin,... vous transférez chaque fois votre password en clair sur le réseau. De plus, on peut facilement faire un dump de votre session pour voir ce que vous avez fait. C'est utile pour avoir des passwords, ou des fichiers de passwords,... Il en va de même pour vos sessions Xwindows qui peuvent être tracées. SSH est un programme client/serveur qui vous permet d'obtenir un remote shell de manière sécurisée. Dès l'établissement de la connexion, les deux machines s'échangent une clé RSA de 768 bits, fréquemment modifiée. Cette clé n'est jamais écrite sur le disque mais est stockée en mémoire, pour la conserver secrète. Votre password et toute votre session seront protégés par une clé RSA. La protection est efficace puisqu'il faudrait environ 200.000.000 MIPS pour craquer la clé RSA de 768 bits en un an! SSH encrypte et forwarde aussi les session XWindows et crée de faux fichiers .Xauthority pour tromper les traceurs de sessions XWindows. SSH security tunnels SSH vous offre la possibilité de créer des tunnels sécurisés entre des machines. Vous pouvez rediriger un port d'une machine A vers un port d'une machine B de manière entièrement transparente. Si vous vous connectez fréquemment à un serveur FTP, ou si vous lisez votre mail avec Eudora, Netscape ou autre, vous pouvez sécuriser la connexion de manière entièrement transparente. Imaginons que je suis sur une machine extacy.drug.be et que je veux faire une connexion FTP vers la machine linux.netline.be à l'aide d'un compte manu. Sur extacy.drug.be, je vais installer un tunnel avec linux.netline.be. Je vais par exemple rediriger le port 6666 de ma machine vers le port 21 (FTP) de linux.netline.be: ssh -l manu -L 6666:linux.netline.be:21 linux.netline.be Je suis maintenant connecté sur linux.netline.be en tant qu'utilisateur manu et en plus, le port 6666 de ma machine est relié sur le port 21 de linux.netline.be. Pour faire une connexion FTP, il ne me reste plus qu'à faire: ftp localhost:6666 ..et la connexion sera automatiquement transférée et cryptée vers le port 21 de linux.netline.be. SSL Secure Socket Layer Parfois, sur le Web, on vous demande d'entrer votre numéro de carte de crédit ainsi que sa date d'expiration. Toutes ces informations sont envoyées dans un joli paquet, très pratique pour acheter sur votre compte. Pour ne pas que le premier sniffer venu vous vole vos précieux numéros, Netscape a implémenté SSL (Secure Socket Layer), qui encrypte vos demandes sur le Web, dans les deux sens. Mieux encore... Quand vous êtes connectés sur un site, par exemple celui de chez VISA, comment savoir qu'il s'agit bien du site VISA et non d'un autre site, qui se fait passer pour le site VISA et qui attends que vous entriez votre code secret? Pour cela, on utilise la certification. Le site VISA doit demander un certificat SSL auprès d'une instance officielle comme VeriSIGN (http://www.verisign.com) qui sera chargé de délivrer et authentifier de manière unique le certificat. SET Secure Electronic Transaction SET a été développé par Visa et Mastercard en collaboration avec d’autres partenaires (Netscape, …) pour effectuer des transactions commerciales au travers du web. Le consommateur ainsi que le commerçant doivent demander un identificateur spécial à leur banque et utiliser un logiciel adhoc (Un Digital Wallet ou portefeuille électronique pour l’utilisateur et un serveur SET pour le vendeur). Ces certificats seront délivrés à partir d’un site Web relié à la banque de l’acheteur et du vendeur. C’est la banque qui assure ainsi la reconnaissance des deux parties et non plus un organisme privé comme s’est le cas avec SSL. Vous trouverez plus d’information sur le site http://www.mastercard.com/set/. Chiffrement LE CHIFFREMENT D'UN MESSAGE que Bernard envoie à Alice par le réseau Internet s'effectue en plusieurs étapes. Tout d'abord, Bernard calcule un condensé de son texte, puis il chiffre ce condensé en utilisant sa clé secrète. L'information résultante (en bleu ci-dessous) est la signature numérique du message de Bernard, une sorte d'empreinte digitale qui certifie que le message vient bien de Bernard. Cette signature et le message sont ensuite comprimés (en violet), puis chiffrés à l'aide d'une clé nommée clé de session. Bernard chiffre ensuite cette clé en utilisant la clé publique d'Alice et il ajoute le résultat (en orange) au message. Le fichier résultant est ensuite converti en caractères alphanumériques (en rouge), puis expédié sur le réseau. À la réception, les étapes sont inversées. Alice utilise sa clé secrète pour déchiffrer la clé de session qui servira à son tour à déchiffrer le reste du message. Hachage UNE FONCTION DE HACHAGE crée un condensé de message, semblable à une empreinte digitale utilisée pour détecter les contrefaçons. Le texte d'un message est d'abord converti en chiffres binaires (la lettre A peut être représentée par 00000, la lettre B par 00001, le C par 00010, etc.) ; puis la suite de caractères qui en résulte est découpée en blocs de taille fixe. Chacun des blocs sert alors de clé dans un système de codage. La sortie finale est le condensé du message original. Quelle que soit la longueur du message initial, le condensé a toujours la même taille. C'est une opération à sens unique, car il est quasi impossible de retrouver le message original à partir de son condensé. De surcroît, avec cet algorithme, deux messages donnent presque toujours des condensés différents et il est impossible de trouver un autre message ayant le même condensé : ce condensé est une «empreinte digitale» du message. L'acheminement des lettres par la poste prend parfois des jours, mais les enveloppes cachent le contenu des messages. À l'inverse, le courrier électronique arrive en un clin d'œil, mais il peut être lu par des indiscrets. Des systèmes de chiffrement peuvent toutefois assurer la confidentialité de telles transmissions : on mélange l'information de manière tellement complexe qu'elle devient inintelligible, excepté pour le destinataire légitime, qui connaît les règles du mélange. Depuis les années 1980, les ordinateurs personnels sont si puissants qu'ils peuvent utiliser des systèmes cryptographiques naguère réservés aux militaires. Ces systèmes, très efficaces, résistent à toute tentative de «cassage». Sortir de l'ombre Avant le milieu des années 1970, l'Agence de sécurité américaine (NSA pour National Security Agency) avait le quasi-monopole de la cryptographie américaine ; les méthodes étaient confidentielles, connues seulement de quelques «hommes du chiffre». En 1976, un article intitulé De nouvelles voies pour la cryptographie, a ouvert la cryptographie au monde de la recherche : en décrivant la «cryptographie à clé publique», Whitfield Diffie et Martin Hellman, de l'Université de Stanford, ont suscité l'émergence d'une communauté universitaire et industrielle dynamique. Le développement du réseau Internet et le souci de confidentialité de ses utilisateurs ont intensifié les études de cryptographie civile. Aujourd'hui, les meilleurs algorithmes de chiffrement et les meilleurs systèmes cryptographiques sont mis au point hors de la communauté militaire. Les militaires américains achètent même des programmes de chiffrement pour leurs propres besoins. Pourquoi l'introduction de la cryptographie à clé publique était-elle si importante? Dans les systèmes classiques, une même clé est utilisée pour le chiffrement et pour le déchiffrement. Avec ces «systèmes symétriques», la clé de chiffrement doit être transmise sur une ligne sécurisée, mais si l'on dispose d'une ligne sécurisée inviolable, pourquoi chiffrer les messages? Grâce à la cryptographie à clé publique, la communication chiffrée est possible sans canal sécurisé pour l'échange des clés. Ce procédé, dit asymétrique, repose sur un couple de clés complémentaires. Chaque clé chiffre le message qui est déchiffré par l'autre clé ; le processus n'est pas réversible, car la clé utilisée pour chiffrer le message ne peut être utilisée pour le déchiffrer. Ainsi, l'une des clés complémentaires (la clé publique) peut être divulguée, tandis que l'autre (la clé secrète) n'est connue que de son propriétaire. Lorsque Bernard désire envoyer un message à Alice, il utilise la clé publique de cette dernière pour chiffrer le message. Alice utilisera ensuite sa clé secrète pour le déchiffrer. La cryptographie à clé publique est fondée sur l'utilisation de problèmes mathématiques faciles à résoudre dans un sens, mais très difficiles dans le sens inverse. Les deux algorithmes à clé publique les plus célèbres sont l'algorithme de Diffie et Hellman (ainsi que ses diverses variantes) et l'algorithme RSA, inventé par Ronald Rivest, Adi Shamir et Leonard Adleman, de l'Institut de technologie du Massachusetts. L'algorithme de Diffie et Hellman utilise les logarithmes discrets, c'est-à-dire que l'on calcule des valeurs du type gx modulo p. Un tel calcul est simple : on élève un nombre g à une puissance x, puis on divise le résultat par un grand nombre premier p et l'on conserve finalement le reste de cette division. L'opération inverse est un problème redoutable : même si l'on connaît les valeurs numériques de g, de p et de gx modulo p, il est impossible, en pratique, de retrouver x (voir Les mathématiques de la cryptographie à clef révélée, par Martin Hellman, octobre 1979). L'algorithme RSA, d'autre part, est fondé sur la factorisation des nombres : s'il est facile de multiplier deux grands nombres premiers, il est très difficile de décomposer le très grand nombre obtenu en ses deux facteurs premiers quand on ne les connaît pas. Avec les algorithmes à clé publique, le destinataire peut connaître l'identité de l'expéditeur. Lorsque Bernard envoie un message à Alice, il le chiffre avec sa clé secrète, puis il chiffre le résultat en utilisant la clé publique d'Alice. À la réception, Alice effectue les étapes inverses : elle déchiffre le message avec sa clé secrète, puis elle déchiffre le résultat avec la clé publique de Bernard. Si elle parvient à lire le message, elle est certaine que c'est bien Bernard qui l'a écrit. Ces opérations de chiffrement et de déchiffrement nécessitent des myriades d'opérations mathématiques, mais des logiciels exécutables par des ordinateurs personnels automatisent le processus ; l'utilisateur n'a qu'à cliquer sur les boutons «chiffrer» ou «déchiffrer» (ainsi mon programme pgp, l'acronyme de Pretty Good Privacy, soit «confidentialité raisonnable», est distribué gratuitement sur le réseau Internet ; son utilisation en France est maintenant autorisée). Malgré ces progrès, la cryptographie à clé publique a deux graves limitations. D'une part, la technique est relativement lente, de sorte qu'en pratique on ne peut chiffrer les messages trop longs. D'autre part, des structures caractéristiques du message en clair subsistent dans le message chiffré. Détectables dans le texte chiffré, ces fragments sont utilisables par des spécialistes, qui peuvent reconstituer la totalité des messages. Chevaux de bataille symétriques Pour ces raisons, le chiffrement est souvent assuré par des techniques symétriques, plus rapides et plus sûres, et la cryptographie à clé publique ne sert que lors de l'étape d'échange des clés symétriques. Par exemple, Bernard chiffre son message avec une clé symétrique rapide et sûre. Comme il doit envoyer à Alice la clé qu'il a utilisée, il la chiffre avec la clé publique d'Alice et attache le résultat à son message chiffré. Alice pourra déchiffrer la clé symétrique en utilisant sa clé secrète. Muni de la clé symétrique, elle déchiffrera alors le reste du message de Bernard. Pour authentifier ses messages, Bernard ne les signe pas non plus à l'aide des techniques à clé publique ; il extrait du message un condensé numérique, ou «empreinte digitale», à l'aide d'une transformation mathématique, nommée fonction de hachage. Cette transformation associe à un message de longueur quelconque un message de longueur fixe, telle que 160 bits (un bit est un chiffre binaire, égal à 0 ou à 1). Les programmes cryptographiques sont conçus de manière que deux messages différents n'aient pas le même condensé. Autrement dit, l'empreinte digitale est unique, deux messages différents ayant à peu près certainement deux condensés différents. Après avoir calculé le condensé de son message, Bernard le chiffre avec sa clé secrète. Il envoie cette «signature» en même temps que le reste de son message chiffré. Lorsqu'elle reçoit ce condensé chiffré, Alice le déchiffre grâce à la clé publique de Bernard. Elle compare alors le résultat obtenu avec le résultat qu'elle calcule elle-même après déchiffrement du message. Si les deux résultats sont identiques, elle conclut que le message n'a pas été modifié et que Bernard en est bien l'expéditeur. Pour chiffrer un message destiné à circuler sur le réseau Internet, on le découpe souvent en blocs de taille fixe (généralement 64 ou 128 bits), puis on chiffre individuellement les blocs successifs. Ce système de chiffrement par blocs crypte plusieurs fois chaque bloc (le nombre d'itérations dépend des algorithmes utilisés). Chaque itération fait intervenir des permutations circulaires (la permutation d'un groupe de trois blocs «xtv» devient «tvx») et des substitutions («tvx» engendre «cb2»). Une partie de la clé participe à la transformation des données au cours de chaque itération. Quand on fournit des morceaux de texte identiques à un système de chiffrement, on obtient des blocs identiques. Aussi, afin d'éviter le maintien de structures qui faciliteraient la découverte du message, les algorithmes par blocs utilisent un chaînage : les blocs qui viennent d'être chiffrés servent à déchiffrer les blocs suivants. Le chiffrement d'un bloc de texte dépend alors de tous les blocs qui le précèdent. La longueur des clés de chiffrement par blocs est généralement égale à 56, 128 ou 256 bits. Les méthodes les plus connues sont DES (Data Encryption Standard, soit «standard de chiffrement de données»), triple-DES, CAST, IDEA et Skipjack. Les algorithmes par blocs sont au centre de la plupart des recherches actuelles en cryptographie. La clé est la clé En cryptographie, l'étape la plus sensible est la création des clés. Pour qu'un système soit le plus sûr possible, les clés doivent être des nombres réellement aléatoires, imprévisibles par un éventuel pirate. Les séquences pseudo-aléatoires déterministes que les ordinateurs engendrent pour les jeux ou les simulations sont inutilisables, car ils sont insuffisamment aléatoires. La seule manière d'engendrer de vrais nombres aléatoires est d'utiliser un «bruit» physique, telle la désintégration radioactive. À l'aide d'un ordinateur, on fabrique difficilement des nombres aléatoires aussi bons que ceux issus de la physique. On obtient toutefois des résultats raisonnables quand on utilise l'intervalle de temps, en microsecondes, qui sépare la frappe de deux touches d'un clavier : cette valeur est impossible à prédire. Les données obtenues ainsi ne sont pas assez aléatoires pour fabriquer directement des clés, mais peuvent être transformées pour accroître le désordre. La seule méthode cryptographique dont on ait prouvé la parfaite sécurité est le chiffrement de Vernam, où la longueur de la clé est égale à la longueur du message. Dans cette méthode, on utilise une séquence aléatoire pour chiffrer le message bit par bit, c'est-à-dire que le 34e bit de la clé code le 34e bit du message. La clé doit être parfaitement aléatoire, elle ne peut pas être une séquence pseudoaléatoire issue d'un algorithme déterministe, sinon le code pourrait facilement être cassé. Le chiffrement de Vernam est rarement utilisé, en raison de difficultés pratiques : la clé, qui est aussi longue que le message, doit être envoyée au destinataire par un canal de transmission sûr. De surcroît, on ne peut utiliser chaque clé qu'une seule fois, sinon un pirate pourrait la décrypter. Si la taille des clés détermine l'efficacité des systèmes cryptographiques, la conception des systèmes est également très importante. Considérons un simple code de substitution où tous les A seraient transformés en W, tous les B en K, tous les C en Q, et ainsi de suite. Le nombre de façons différentes d'arranger l'alphabet est égale à 26! (ce nombre, qui se lit «factorielle 26», est égal à 26 x 25 x 24 … 3 x 2 x 1), soit environ 4 x 1026 (un nombre de 26 chiffres)! On ne peut tester toutes les combinaisons une à une, mais, lorsque j'étais enfant, je m'amusais à casser ce type de code avec un papier et un crayon : je regardais simplement la lettre la plus fréquente et je supposais qu'il s'agissait d'un E ; puis je cherchais la deuxième lettre la plus fréquente et je supposais que c'était un S, etc. Ainsi, malgré un espace des clés très grand, ce type de code est très simple. En fait, la sécurité d'un système cryptographique n'est pas proportionnelle à la taille de la clé. Pour les systèmes par blocs, par exemple, la relation est plutôt exponentielle : un bit de plus à la clé oblige un pirate éventuel à doubler le nombre d'essais. L'effort nécessaire est élevé au carré quand la taille de la clé est doublée. Pour casser un système qui utilise une clé de longueur 128 bits, il faut en moyenne 2 127 (soit 1,7 x 1038) opérations. Pour les algorithmes à clé publique, la difficulté augmente plus lentement. L'espace des clés augmente moins vite qu'une loi exponentielle, mais plus vite qu'une loi de puissance ; le doublement de la longueur de la clé n'élève pas au carré l'effort à fournir pour casser le code, mais le travail reste considérable. Par exemple, dans le système RSA, les algorithmes modernes de factorisation peuvent faire beaucoup mieux que d'essayer toutes les combinaisons de nombres premiers possibles pour factoriser un nombre de grande taille. Le code de Diffie et Hellman est, lui aussi, «sous-exponentiel». Par exemple, une clé de 3 000 bits pour RSA ou Diffie-Hellman est aussi difficile à décrypter qu'une clé de 128 bits d'un système de chiffrement par blocs. Le chiffrement par blocs n'est toutefois pas invulnérable. En 1998, la Société Electronic Frontier Foundation a construit, pour moins de 1,5 million de francs, un ordinateur massivement parallèle qui a cassé un message chiffré par DES en explorant toutes les clés à 56 bits en moins d'une semaine. La force brute n'est pas la seule façon de percer un code. Des méthodes mathématiques élaborées et des outils statistiques raccourcissent le travail. Certaines méthodes recherchent, par exemple, un motif particulier dans le message chiffré. Ces méthodes statistiques sont classées en trois catégories selon ce qui est connu du texte clair et du texte chiffré. Quand le pirate connaît seulement le texte chiffré, il n'a rien pour le guider dans sa recherche de la clé, si bien que même un système simple de chiffrement résiste aux assauts. En revanche, quand le pirate connaît au moins une partie du message, ses chances de succès augmentent. Par exemple, s'il sait qu'il commence par «Cher Monsieur Dupond», il peut d'abord chercher une clé qui décrypte la partie «Cher Monsieur Dupond» du texte clair, puis poursuivre le décryptage à l'aide des informations trouvées. Même quand le pirate ne connaît que le langage utilisé dans le texte clair, russe, français ou COBOL, il peut exploiter cette information. Si le message est en français, par exemple, alors le mot le plus fréquemment utilisé est sans doute «le» ou «la». Pour déjouer de telles attaques, certains systèmes cryptographiques compriment le message en clair, préalablement au chiffrement, ce qui en enlève les motifs prédictibles. Souvent le pirate en connaît bien plus. S'il a volé une carte à puce qui contient un système cryptographique, il peut envoyer à la carte des milliards de messages judicieusement choisis et étudier les messages chiffrés correspondants ; de telles attaques percent facilement les systèmes de chiffrement peu efficaces. Dans le cas des systèmes à clé publique, l'attaquant peut écrire un message, le coder avec la clé publique (connue) et analyser le texte chiffré qui en résulte. Des méthodes d'analyse des systèmes de chiffrement performantes apparaissent depuis peu : ce sont les méthodes différentielles et linéaires. On les a utilisées pour analyser un grand nombre de systèmes de chiffrement par blocs et pour montrer qu'il est possible de décrypter les messages chiffrés à l'aide de l'algorithme DES des centaines ou des milliers de fois plus rapidement que par une recherche exhaustive. Dans la cryptanalyse différentielle, introduite par A. Shamir et Eli Biham, de l'Institut Weissman, en Israël, on code des paires de messages clairs, où les différences sont convenablement choisies, afin de trouver des différences dans les paires chiffrées. La découverte de ces différences renseigne alors sur la clé. Dans la cryptanalyse linéaire, mise au point par Mitsuru Matsui, de la Société Mitsubishi, on recherche les corrélations, même faibles, qui existent entre les textes clairs, les textes chiffrés et les clés. La méthode accumule les statistiques obtenues sur un grand nombre de couples texte clair–texte chiffré, à la recherche de tendances qui donneraient des indices sur la clé. Attention aux intermédiaires Bien qu'efficaces, les méthodes de cryptanalyse (l'étude de la façon de percer les messages secrets) nécessitent de nombreux calculs. Souvent, au lieu de tenter de casser le système de chiffrement, les pirates préfèrent attaquer son implémentation, car elle laisse parfois «fuir» de l'information. Les systèmes cryptographiques à clé publique sont très vulnérables à une attaque par un tiers qui s'interposerait dans la communication. Bernard, qui envoie un message à Alice, peut ignorer que Caroline s'interpose. Si Caroline parvient à faire croire à Bernard que sa propre clé publique est celle d'Alice, elle pourra déchiffrer les messages émis par Bernard. Bernard ne peut éviter cette intrusion qu'en s'assurant que la clé utilisée est bien celle d'Alice. La complexité des bons systèmes de cryptographie à clé publique vise presque uniquement à donner cette garantie. Certains systèmes cryptographiques font appel à un tiers de confiance, qui certifie les clés. Toutefois, les clés doivent-elles être certifiées de manière descendante, par des autorités gouvernementales, ou de manière décentralisée, au choix des utilisateurs de systèmes cryptographiques? Ce point fait encore l'objet d'âpres débats. Les algorithmes de cryptographie se sont améliorés en même temps que la cryptanalyse. Le système DES, arrivé en fin de vie, surtout en raison de sa petite clé de 56 bits et de ses blocs de 64 bits, sera remplacé par un nouveau système cryptographique, l'AES (Advanced Encryption Standard, soit «standard de chiffrement avancé»). Ce système, qui a mis la communauté de la cryptographie en effervescence, devrait utiliser des clés de 128, 192 ou 256 bits pour chiffrer des données en blocs de 128 bits. Les systèmes AES devront satisfaire plusieurs contraintes. Ils devront utiliser plusieurs longueurs de clés et de blocs ; ils devront être rapides, créant les clés, chiffrant et déchiffrant les messages à l'aide de processeurs 32 bits, tels ceux qui équipent les ordinateurs personnels, ou de microprocesseurs 8 bits, tels ceux des cartes à puce ; enfin, ils devront fonctionner correctement lors des échanges sur le réseau Internet comme lors des télécommunications par satellite. Plusieurs propositions d'AES sont intéressantes. Elles bénéficient des études du codage par blocs et des recherches de défense contre les méthodes de cryptanalyses différentielles et linéaires. Plusieurs des 15 systèmes proposés seraient efficaces. Le système MARS, qui dérive du système DES de la Société IBM, utilise deux structures très différentes pour chaque itération de chiffrement. Cette approche mixte permet, selon la Société IBM, une sécurité que n'autorisent pas les systèmes de chiffrement classiques. Le procédé CAST-256 est une extension des premières architectures CAST à une clé de 256 bits et à des blocs de 128 bits. Le système Twofish est mathématiquement plus rigoureux que Blowfish, son prédécesseur. La conception de Serpent est fondée sur une structure parallèle inhabituelle, qui le rend aussi rapide que DES et qui permet d'engendrer très rapidement des clés autorisant ainsi son utilisation en tant que fonction de hachage. Au département de mathématiques et d'informatique de l'École normale supérieure, l'équipe de Serge Vaudenay a mis au point le système DFC (Decorrelated Fast Cipher, soit «codage décorrélé rapide»), très rapide, et dont on peut prouver la sûreté face à certains types d'attaques. Déchiffrer le futur Quelle que soit la proposition sélectionnée, AES avantagera les utilisateurs. Aujourd'hui, les meilleurs systèmes de cryptographie sont supérieurs aux meilleures méthodes de cryptanalyse connues. Bien sûr, la cryptanalyse viendra à bout des nouveaux systèmes, mais de nombreux informaticiens estiment que l'écart entre les méthodes de chiffrement et les méthodes de «cassage» se creusera progressivement. Je partage cette opinion : la cryptographie civile a grandi dans les universités et dans les entreprises privées, et elle a rattrapé la cryptographie militaire. D'ailleurs, les militaires américains ont rendu public leur système de chiffrement Skipjack, qu'ils avaient mis au point en secret. Selon une étude d'Eli Biham, cet algorithme serait moins sûr que les meilleurs algorithmes universitaires. Comme le réseau Internet, la cryptographie est sortie du giron militaire. Souhaitons-lui une croissance aussi remarquable! Bibliographie Bruce Schneier, Cryptographie appliquée, Vuibert, 1996. Doug Stinton, Cryptographie : théorie et pratique, Vuibert, 1996. Jean Guisnel, Guerre dans le cyberespace, La découverte, 1997. G. Dubertret, Initiation à la cryptographie, Vuibert, 1998. Jacques Stern, La science du secret, Odile Jacob, 1998. Hyperliens : Un site concernant le logiciel de cryptographie PGP : The International PGP Home Page Des données relatives aux méthodes DES et AES sur le site de la Computer Security Resource Clearinghouse Le Groupe de Recherche En Complexité et Cryptographie de École Normale Supérieure qui propose le DFC comme futur standard AES. Le dossier d'actualité sur la cryptographie du quotidien Le Monde. Le site de l'IACR, l'Association internationale de la recherche sur la cryptographie. Le site de l'organisation Global Internet Liberty Campaign propose une étude internationale sur le problème de la liberté individuelle lié à la cryptographie. Le site du S.C.S.S.I., centre focal de l'Etat pour la sécurité des systèmes d'information Le site Electronic Privacy Information Center Le site de l'Electronic Frontier Foundation Le site de la National Security Agency, l'Agence de sécurité américaine. Une page personnelle : Chiffrement & cryptographie par Serge Delestan et Lionel Lejeune. Détection d’intrusion 1. Qu’est-ce qu’une intrusion ? Une intrusion est quelqu’un, appelé généralement hacker ou cracker, qui tente d’entrer par effraction sur un site en vue d’en faire un mauvais usage. Par « faire un mauvais usage », on entend aussi bien visualiser, voler ou corrompre des données qu’utiliser un serveur de mail pour faire du spam (c’est-àdire utiliser un serveur de mail pour envoyer des milliers d’e-mails non sollicités, souvent à des buts publicitaires). Un hacker est généralement un passionné d’informatique qui accorde un grand intérêt aux rouages internes des systèmes d’exploitation et des différents programmes qui tournent dessus. Le plus souvent, il s’agit d’un programmeur. Il possède donc des connaissances approfondies en programmation et dans les mécanismes des systèmes d’exploitation ainsi que des protocoles de communication utilisés sur les réseaux. Grâce à ses connaissances, un hacker pénètre dans des systèmes dans un but d’apprentissage et non dans un but de destruction. La fierté de réaliser un tel exploit est le salaire du hacker. Un cracker est une personne qui entre par effraction dans des systèmes informatiques dans un but malveillant. Une fois entré dans un système, il détruira des données sensibles ou empêchera le fonctionnement normal d’une machine. Les définitions de hacker ou cracker sont théoriques. Dans la pratique, on utilise de plus en plus les deux termes indifféremment pour désigner une personne s’introduisant sur un système informatique de manière illicite, ce qui est interdit dans tous les cas. Les intrusions peuvent provenir de deux endroits : - de l’extérieur : il s’agit d’une personne agissant hors du réseau de l’entreprise qui pourrait s’attaquer à la présence externe du réseau (serveur web, utiliser un serveur mail pour le spam…). Cette personne pourrait essayer d’attaquer le firewall pour atteindre une machine du réseau interne. Ces intrusions peuvent venir d’Internet ou du réseau d’un partenaire (vendeur, client …). - de l’intérieur : il s’agit de personnes utilisant légitimement les ressources du réseau mais qui abusent de celles-ci pour effectuer des opérations illicites (par exemple, un administrateur de base de données allant modifier sa fiche de paie dans la base de données qu’il doit gérer). Il peut aussi s’agir de personnes utilisant les accès plus privilégiés d’un autre utilisateur en utilisant le terminal ou l’ordinateur d’une autre personne par exemple. Cette personne pourrait acquérir les privilèges d’un administrateur en profitant d’une faille d’un programme, souvent un problème de buffer overflow. Un buffer overflow est provoqué en entrant plus de caractères que prévu dans une zone de saisie du programme, par exemple entrer un nom de deux mille caractères dans un champ d’un formulaire prévu pour en recevoir deux cents. Si les caractères « en trop » sont bien choisis et si le programme ne prévoit aucun garde-fou (ce qui est malheureusement trop souvent le cas), l’attaquant pourra exécuter une commande système et ainsi récupérer des droits supplémentaires. Pour récupérer les droits d’administrateur, l’intrus pourra utiliser un programme spécial du genre Root Kit. Un Root Kit est un programme qui permet d’obtenir les privilèges administrateurs à partir d’un simple compte. Les buffer overflow et les Root Kit seront abordés de manière plus approfondie dans un chapitre ultérieur. On peut classer les intrusions en plusieurs catégories. Il existe des personnes qui essaient de s’introduire sur un réseau uniquement pour le fun, pour prouver (souvent même uniquement à euxmêmes) qu’elles ont les compétences techniques nécessaires. D’autres personnes le font par pur vandalisme (défigurer un site web, bloquer un système par des attaques de type déni de service) ou par idéologie (taguer un site pro-nazi peut être bien perçu). D’autres encore essaieront de s’introduire dans un système pour leur profit personnel, pour voler des données confidentielles ou pour payer moins cher des articles sur un site de commerce électronique par exemple. Avec le développement attendu du commerce électronique, il faut s’attendre à un déferlement d’attaques de ce genre, d’autant plus que des sites sur Internet expliquent comment réaliser ce genre d’attaque. On trouve aussi sur Internet, et c’est particulièrement inquiétant, de nombreux logiciels permettant d’effectuer nombre d’attaques sans avoir besoin de connaissances en informatique très poussées. 2. Les différents types d’intrusions Il existe plusieurs types d’intrusions : - les intrusions physiques : si un intrus peut avoir un accès direct à une machine du système, c’est-à-dire s’il peut se trouver devant l’ordinateur et qu’il peut le manipuler librement, il pourra le pénétrer. Par exemple sous Linux, on peut accéder au système grâce à une disquette de boot. Une fois à l’intérieur du système, il suffit d’éditer le fichier des mots de passe et de créer un nouvel utilisateur avec les privilèges root. Sous Unix, la structure du fichier des mots de passe est suffisamment simple pour créer une nouvelle entrée sans mot de passe. On a ainsi accès à toutes les ressources du système. Il y a bien sûr moyen d’interdire l’accès au système via une disquette de boot en jouant avec les paramètres de configuration mais c’est parfois utile de pouvoir se connecter sur une machine dont on a perdu le mot de passe administrateur ou si un intrus a modifié le compte administrateur (le cas s’est présenté chez NETLine lors de mon stage). Un intrus pourrait aussi retirer un disque dur d’une machine pour aller le lire et écrire dessus sur une autre machine. - les intrusions système : ce type d’intrusion suppose que l’intrus possède déjà un compte utilisateur avec de faibles privilèges. À partir de ce compte, s’il existe une faille dans l’un des programmes ou dans le système d’exploitation qui tourne sur la machine, l’intrus pourra acquérir des privilèges plus élevés et pourra ainsi utiliser toutes les ressources du système. Pour éviter au maximum ce type d’intrusion, il est vivement conseillé d’installer les derniers patches de sécurité pour tous les programmes tournant sur la machine. Des sites web documentent en effet les failles et celles-ci peuvent dès lors être exploitées par un grand nombre de hackers, même peu compétents. Vous pourrez trouver l’adresse de tels sites dans la bibliographie Internet. Ces sites peuvent être ceux des constructeurs eux-mêmes expliquant les failles de leur système ou ceux d’organismes indépendants informant le monde sur la sécurité ou encore les sites de groupe de hackers. - les intrusions à distance : comme son nom l’indique, c’est quand un intrus tente d’accéder à distance à travers le réseau. L’intrus commence donc sans aucun privilège. Un firewall rendra bien sûr la tache plus ardue à l’assaillant. 3. Autre classement des intrusions On classe aussi les intrusions en deux grandes catégories : Utilisation frauduleuse (misuse) On parle d’utilisation frauduleuse quand un utilisateur enfreint une règle de fonctionnement définie au préalable. Par exemple, une personne non autorisée pourrait se connecter à un serveur FTP pour installer un cheval de Troie (trojans en anglais), lui permettant de récupérer un accès « légitime » sur le système. Un autre cas d’utilisation frauduleuse serait d’utiliser un serveur mail d’une société pour envoyer des messages à caractère publicitaire sous le couvert d’une adresse e-mail de l’entreprise, c’est-à-dire faire du spam. Utilisation anormale (anomaly) Une utilisation anormale consiste en un comportement non usuel ou statistiquement rare. Par exemple, un employé, qui travaille normalement pendant la journée, se connecte à sa machine à trois heures du matin. Ou bien quelqu’un se connecte à votre compte utilisateur pendant que vous êtes vous-même déjà connecté. 4. Les différents types de problèmes de sécurité Les problèmes de sécurité peuvent provenir soit de bogues dans les programmes, soit de l’administration du système. Problèmes liés aux programmes La grande majorité des problèmes de sécurité ne viennent pas des systèmes d’exploitation mais des programmes qui tournent dessus. Rappelons-nous d’abord quelques principes de base, comme le ferait Monsieur de la Palisse : - - Les programmes ont toujours des bogues. Les programmes sécurisés et de sécurité aussi. Plus un programme est gros et compliqué, plus il est bogué. Si on n’exécute pas un programme, peu importe qu’il soit bogué ou non. si un programme n’est pas exécuté, peu importe s’il possède ou non des problèmes de sécurité. Il est dès lors fortement conseillé de limiter au maximum le nombre de programmes tournant sur votre machine. Si vous devez par exemple installer Linux sur une machine, n’installez pas la distribution (SuSE, RedHat…) dans son inégralité (même si c’est plus simple et que vous venez d’acheter un nouveau disque dur d’une capacité pharaonique). N’installez que les programmes qui sont nécessaires et évitez d’installer les programmes dont vous ne connaissez pas l’usage. Vous pourrez toujours compléter votre système par la suite. Les installations par défaut sont en général créées dans le but d’avoir un système facile à utiliser. Mais malheureusement, facile à utiliser signifie souvent facile à hacker. Un premier exemple : sous Linux, toute une série de services par défaut (un serveur mail, un serveur ftp,…) sont installés. Il faudra aller modifier les fichiers de configuration pour enlever les services superflus. En général, dans le monde UNIX, la plupart des services TCP et UDP sont initialisés à partir du fichier /etc/inetd.conf. Ce fichier permet de configurer le démon internet : inetd. Inetd est un processus fonctionnant en arrière-plan dont le rôle est de lancer à la demande tous les services disponibles à travers le réseau. On évite ainsi de démarrer des services dont on n’aura peutêtre pas besoin. Voici un extrait d’un fichier inetd.conf : Inetd services -- sample inetd.conf ftp stream tcp nowait #telnet stream tcp nowait #shell stream tcp nowait #login stream tcp nowait -- sample inetd.conf section -(1) (2) (3) (4) root root root root (5) section /usr/libexec/ftpd /usr/libexec/telnetd /usr/libexec/rshd /usr/libexec/rlogind (6) -ftpd -l telnetd rshd rlogind (7) Explication des champs du fichier /etc/inetd.conf : 1. nom du service 2. type de socket (stream ou datagram) 3. type de protocole (TCP or UDP) 4. wait/nowait – si le paramètre est positionné à nowait , inetd démarre un processus de service indépendant sans attendre la fin du processus en cours. Si le paramètre est positionné à wait, le démon inetd ne doit pas démarrer un nouveau processus supplémentaire mais il doit attendre la fin du processus démarré. 5. identificateur d’utilisateur, c’est-à-dire avec quels droits d’utilisation le processus doit être exécuté. 6. 7. nom du programme à démarrer. paramètres à passer lors de l’appel du programme. Sur les systèmes sur lesquels les processus ne sont pas lancés par tcpd (démon tcp), le premier argument doit être le raccourci de l’appel du programme, c’est-à-dire le nom du programme lui-même. Il s’agit d’une vieille convention Unix. Pour désactiver un service on met en commentaire la ligne qui le lance au moyen du caractère #. Inversément, on active un service en enlevant ce caractère. On active les modifications en demandant à inetd de relire son fichier de configuration au moyen du signal hangup. En pratique, on utilise la commande killall –HUP inetd. Sous Windows NT, par défaut tous les disques sont partagés. Il existe une vulnérabilité dans IIS (le serveur web de Microsoft) permettant de voir le contenu des répertoires partagés. Il suffit de post-fixer une URL de $DATA. Les répertoires partagés seront alors visibles par les autres membres de votre domaine. Doit-on leur faire confiance ? Pour empêcher le partage automatique des disques durs à chaque nouveau démarrage, il faut ajouter une entrée dans la base de registre (registry) de windows avec le programme regedt32. Cette entrée est : - dans le cas de Windows NT Workstation : aller dans la registry et accéder à la clef HKEYLOCAL_MACHINE\System\CurrentControlSet\Services\ LanManagerServer\Parameters Si elle n’existe pas, il faut créer une clé AutoShareWks, de type Reg_Dword Data et dont la valeur est 0. - dans le cas de Windows NT Server : aller dans la registry et accéder à la clef HKEYLOCAL_MACHINE\System\CurrentControlSet\Services\ LanManagerServer\Parameters Si elle n’existe pas, il faut créer une clé AutoShareServer, de type Reg_Dword Data et dont la valeur est 0. Il faut aussi installer les derniers service packs et les derniers patches de sécurité aussi bien pour le système d’exploitation que pour les applications qui tournent dessus. On doit travailler avec des disques au format NTFS qui est beaucoup plus sécurisé que le système de fichier FAT. NTFS permet, entre autres, d’autoriser ou de refuser l’accès à un fichier ou à un répertoire. Il est conseillé de ne pas installer Windows dans le répertoire par défaut (c:\WINNT). Dans certains cas, un intrus peut accéder plus aisément à certains fichiers s’il connaît son chemin d’accès. Internet Information Server (de Microsoft) installe par défaut des exemples de code dont un script ASP nommé showcode.asp. Il permet, à quelqu’un qui se connecte à ce serveur web, de voir le contenu du disque où est installé ce script. Il suffit que l’intrus connaisse le nom et le répertoire du fichier qu’il veut voir. Par conséquent, si Windows est installé dans son répertoire par défaut, certains fichiers sensibles peuvent être lus, comme par exemple : c:\winnt\drwatson.log c:\winnt\$winnt$.inf c:\inetpub\wwwroot\global.asa c:\program files\ws_ftp\ws_ftp.ini c:\winnt\win c:\winnt\system.ini c:\winnt\odbc.ini On pourrait ajouter à cette liste de fichiers sensibles, entre autres, le contenu des boîtes e-mail, les fichiers de log. Pour éviter ce genre de désagrément, il suffit de supprimer le script showcode.asp. Voici une liste de scripts dangereux avec leur emplacement par défaut (certains sont cités plusieurs fois car ils peuvent être installés à des endroits différents) : /iissamples/Exair/Howitworks/Codebrws.asp /iissamples/Exair/Howitworks/Code.asp /iissamples/Exair/Howitworks/Codebrw1.asp /iissamples/sdk/asp/docs/codebrws.asp /iissamples/sdk/asp/docs/codebrw2.asp /msadc/Samples/selector/showcode.asp /Sites/Knowledge/Membership/Inspired/ViewCode.asp /Sites/Knowledge/Membership/Inspiredtutorial/ViewCode.asp /Sites/Samples/Knowledge/Membership/Inspired/ViewCode.asp /Sites/Samples/Knowledge/Membership/Inspiredtutorial/ViewCode.asp /Sites/Samples/Knowledge/Push/ViewCode.asp /Sites/Samples/Knowledge/Search/ViewCode.asp /SiteServer/Publishing/viewcode.asp Voici un exemple permettant d’exploiter cette vulnérabilité, le hacker demande une page sur le serveur someserver où est installé l’exemple showcode.asp. Il entre l’URL suivante : http://www.someserver.com/msadc/Samples/SELECTOR/Showcode.asp?source=/msadc/Samples/../../. ./../../boot.ini , il peut ainsi accéder au fichier boot.ini dans le répertoire racine. Les exemples précédents ne sont qu’une partie infime des réglages possibles d’un système permettant d’avoir une configuration sécurisée. Pour connaître tous les réglages possibles, on utilise un scanner de vulnérabilité du style Internet Secure Scanner de la société Internet Secure System ou Retina de la société Eeye. Ces produits scannent les machines de votre réseau afin de trouver tous les problèmes de configuration pouvant entraîner des failles de sécurité. Chaque fois qu’une faille potentielle est trouvée, ils vous indiquent quelle est la marche à suivre pour « colmater » la brèche. Comme ces produits vous indiquent les clés à insérer dans la registry de Windows pour une meilleure sécurité du système, cela vous évite de les retenir toutes. Si vous devez vérifier toutes les configurations des machines d’un réseau « manuellement », c’est-à-dire inspecter toutes les registry de Windows et la configuration de tous les programmes tournant sur chaque système par exemple, vous passerez sans aucun doute à côté de problèmes potentiels et vous devrez y passer un temps beaucoup plus important. Les scanners de vulnérabilités sont abordés dans un autre chapitre. 5. Les mots de passe Les mots de passe constituent la première barrière empêchant un intrus d’utiliser les ressources d’un système. Si quelqu’un possède le nom d’utilisateur (le login) et le mot de passe correspondant, il pourra entrer dans le système (logique !). Si le compte utilisateur pénétré possède les privilèges d’administration (compte root sous Unix ou compte administrateur sous Windows), l’intrus pourra tout faire. L’attaquant aura ainsi le contrôle total du système pour peu qu’il ait les connaissances suffisantes pour exploiter cet avantage (entrer sur un système Unix sans connaître ses commandes ne sert évidemment pas à grand-chose). Si le compte utilisateur pénétré ne possède pas de privilèges d’administration, l’intrus a bien sûr des possibilités beaucoup plus limitées. Ces possibilités, même réduites, suffisent souvent à endommager un système, l’étendue des dégâts dépendant des possibilités accordées à l’utilisateur. Une autre chose à savoir : il est plus facile de prendre le contrôle d’une machine sur laquelle on possède déjà un compte que de partir de rien. On peut utiliser une faille d’un logiciel tournant sur le système, par exemple une vulnérabilité par buffer overflow ou on peut installer un troyen pour prendre le contrôle du système. Je reviendrai dans un chapitre ultérieur sur le mécanisme de buffer overflow et sur les chevaux de Troie. Il est donc très important de bien choisir son mot de passe. Ce qui suit peut paraître évident mais il faut pourtant insister. Il faut éviter d’utiliser un mot de passe trop facile à deviner. Le nom de l’utilisateur, son prénom, ses initiales, le nom de la société, le nom ou prénom du conjoint ou de la conjointe, de ses enfants, le numéro de plaque de la voiture seront les premiers mots testés. Il faut également éviter un mot de passe trop courant qui pourrait se trouver dans un dictionnaire. Le mot de passe doit contenir de préférence des lettres majuscules et minuscules, des chiffres et des signes de ponctuation. Le mot de passe ne devra pas non plus être trop court. Plus celui-ci sera long, plus il sera dur à cracker. Microsoft conseille une longueur supérieure à quatorze caractères pour une sécurité optimale. Le problème d'un bon mot de passe, c’est qu’il faut s’en souvenir. Plus un mot de passe sera compliqué, plus on a de chances de l’oublier. Certaines personnes particulièrement inconscientes n’hésitent pas à se passer de mot de passe laissant ainsi le système à la merci de la première personne malveillante venue ou bien on scotche le mot de passe sur la machine. Le problème de mémorisation se pose d’autant plus que les mots de passe ont tendance à se multiplier. Pour rendre un mot de passe difficile à deviner, il suffit souvent d’insérer un caractère supplémentaire ou une faute dans le mot ou nom facile à retenir qu’on désire utiliser. Au lieu d’utiliser leblanc comme mot de passe, on utilisera une variante : le !blanc, lewhite, leblancC, … Ces petites modifications bloqueront toute tentative d’attaque par dictionnaire. Mais dans un environnement sécurisé, je conseillerais quand même d’utiliser un mot de passe plus compliqué. Les mots de passe doivent bien sûr être stockés sous forme cryptée. Un mot de passe stocké en clair (c’est-à-dire sans être crypté) ne nécessiterait que de récupérer le fichier où il est stocké pour pouvoir le récupérer. Malgré que ce soit évident, il existe encore beaucoup d’applications qui enregistrent les mots de passe dans des fichiers temporaires, dans la cache de votre navigateur… en clair. La méthode de cryptage du mot de passe ne doit pas être trop évidente. Un algorithme basé sur une simple substitution, où chaque caractère est remplacé par un autre défini préalablement (par exemple a=c, b= k, c=h…) ou par rotation, où chaque caractère est remplacé par le caractère dont la valeur est supérieure du nombre de la rotation (par exemple si on a une rotation de trois, a deviendra d, b deviendra e, ainsi de suite), sera aisément cracké. Il faut, quand c’est possible, utiliser un algorithme de cryptage plus complexe du style DES, RSA… Un administrateur a intérêt à surveiller la qualité des mots de passe utilisés par les utilisateurs du réseau. Pour cela, il doit utiliser un logiciel qui cracke les mots de passe. Sous Windows NT 4 ou Windows 98, le logiciel l0phtCrack de l0pht (http://www.l0pht.com/l0phtcrack/ ), conseillé par Microsoft, permet de tester tous les mots de passe des comptes utilisateurs présents sur la machine. Ce logiciel recherche les mots de passe soit dans la SAM (le fichier où sont stockées les informations sur la sécurité de Windows NT), soit dans la base de registre (registry), soit encore dans les paquets SMB (protocole de message utilisé par LAN Manager pour communiquer) circulant sur le réseau. L’application se présente comme ceci : Plus un mot de passe est « faible », plus le temps nécessaire pour le cracker est court. Les mots de passe les plus faciles à deviner peuvent être visualisés dans un délai très bref. Dans la capture d’écran ci-dessus, certains mots de passe n’ont pas encore été trouvés, cela signifie qu’ils sont « bons ». L0phtCrack est capable de décrypter n’importe quel mot de passe en 480 heures avec une machine disposant de quatre processeurs Intel Xeon tournant à 400 MHz. L’algorithme de cryptage de Windows NT 4 n’est pas très robuste mais Windows 2000 corrige cette faiblesse. Crackage de mot de passe Pour cracker un mot de passe, il existe deux méthodes : Brute force attack Ce type d’attaque consiste à essayer toutes les combinaisons possibles de caractères pour trouver le mot de passe. Cette technique permet de trouver relativement facilement un mot de passe composé de quatre caractères en lettres minuscules mais sera beaucoup moins performante sur un mot de passe de 7 caractères composés aussi bien de lettres minuscules et majuscules que de chiffres et de signes de ponctuation. On passe en effet de plus ou moins un demi-million de possibilités à plus de 10 trillions 1 de possibilités. Dans le dernier cas, même avec un ordinateur très performant, il faut compter des mois pour pouvoir trouver le mot de passe. Attaque par dictionnaire 1 Un trillion = un milliard de milliard = la 18ème puissance de dix Pour ce type d’attaque, on essaie tous les mots contenus dans un dictionnaire. Dans ces dictionnaires, on trouve tous les mots et les noms courants. On trouve sur Internet plein de dictionnaires : des dictionnaires des noms communs en plusieurs langues, des dictionnaires de noms propres… En général, ces dictionnaires peuvent être personnalisés sans difficulté. On peut ainsi, par exemple, ajouter les noms, les prénoms, les initiales et d’autres informations sur les personnes utilisant le système attaqué. 6. Les sniffers Les sniffers sont des outils qui interceptent les trames d’un réseau et qui permettent de visualiser leur contenu. Un sniffer sur un réseau Ethernet pourra capturer toutes les trames circulant sur son segment, les trames sur les autres segments n’étant pas visibles. Plusieurs protocoles de la suite TCP/IP transmettent les mots de passe en clair, c’est-à-dire en noncrypté. C’est le cas, entre autres, des protocoles telnet, FTP, http… Une personne mal intentionnée ayant placé un sniffer sur un segment de réseau peut intercepter les mots de passe et le login des utilisateurs. Avec ces mots de passe, un hacker entrera sans aucune difficulté sur un système. Si un sniffer est « bien » placé, il pourra récupérer énormément de mots de passe. Certains sniffers ont pour particularité de rechercher uniquement les mots de passe dans les trames. Un exemple de ce type de sniffer est dsniff (http://www.monkey.org /~dugsong/dsniff/), il récupère les mots de passe pour FTP, Telnet, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, NFS, YP, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB et Oracle SQL*Net auth info. Il examine les trames de chaque protocole pour uniquement récupérer les mots de passe. Si les mots de passe sont cryptés, un hacker, après avoir enregistré le mot de passe, doit le hacker. Si un mot de passe a été mal choisi, il peut être décrypté relativement vite par un hacker (voir la partie consacrée aux mots de passe). De plus, un hacker pourrait enregistrer le trafic entre deux machines. Une fois l’enregistrement effectué, un hacker peut réutiliser les données servant à l’identification d’un utilisateur pour rentrer dans un système. Un hacker n’a donc pas besoin de décoder un mot de passe crypté, il n’a qu’à l’intercepter et le réutiliser. On parle alors de « replay attack ». Pour éviter les « replay attack », on utilise pour l’identification une variable définissant le temps en plus du mot de passe et du login. Un serveur qui reçoit une demande de connexion venant d’un utilisateur vérifie si aucune autre demande de connexion précédente n’a pas déjà utilisé une valeur du temps égale ou supérieure. Si ça devait être le cas, la connexion est refusée par le serveur. Pour que cette méthode fonctionne, il faut bien évidemment que les informations sur une connexion changent dans le temps. Les sniffers ne servent pas uniquement à récupérer les mots de passe : un hacker pourrait les utiliser pour récupérer des informations confidentielles. Une entreprise concurrente à la vôtre pourrait utiliser un sniffer pour récupérer des informations sur vos futurs produits. Pour augmenter la sécurité des transmissions sur un réseau, on crypte les communications. Sur un réseau TCP/IP, on peut continuer à utiliser un protocole spécialement dédicacé au cryptage des communications comme IPSec. IPSec est le protocole par défaut des VPN (réseau crypté) chez Cisco. Une autre méthode pour crypter les données consiste à utiliser un protocole TCP/IP non sécurisé et à crypter les données contenues dans les trames. On utilise par exemple SSH qui signifie Secure Shell. Cette méthode est moins performante que celle utilisée pour IPSec car elle nécessite d’abord une récupération préalable des données dans la trame avant d’effectuer le décryptage des données. Les sniffers sont des dispositifs passifs : ils n’interviennent pas sur les communications qu’ils surveillent. Ils sont donc difficiles à détecter. Heureusement, il existe des logiciels permettant de détecter les sniffers. Pour pouvoir capturer toutes les trames d’un réseau, un sniffer doit se mettre en « promiscuous mode ». Quand un système est dans ce mode, il réagit différemment aux messages qu’on pourrait lui envoyer. Un exemple de programme permettant de détecter un sniffer peut se trouver à l’adresse http://www.l0pht.com/antisniff (logiciel AntiSniff de l0Pht). Un sniffer capable de dissimuler sa présence au logiciel AntiSniff a fait son apparition : il s’appelle Anti-AntiSniff (on peut le trouver sur le site de securityfocus, voir la bibliographie). 7. Les modems dans un réseau Quand un réseau doit être connecté à Internet, il est fortement déconseillé d’installer des modems sur les machines. Chaque modem constitue un point d’entrée dans votre réseau et chaque point d’entrée est une porte qu’un hacker peut exploiter. Il est donc préférable d’avoir un point d’accès unique à Internet via un routeur. De plus, avoir un point d’accès unique au réseau est économiquement plus intéressant car on ne paie qu’une connexion à Internet. Si vous possédez un Firewall surveillant le trafic venant de l’extérieur du réseau, sachez que tout modem installé sur une machine du réseau rend votre Firewall inutile. Il faut donc empêcher les employés de votre d’entreprise d’installer des modems qui mettent la sécurité de votre réseau en danger. Systèmes de détection d’intrusion La détection d’intrusion est la surveillance des événements survenant sur un réseau ou un système informatique ainsi que leur analyse afin de découvrir des signes de problèmes de sécurité. Par analogie avec le monde réel, on parlerait des alarmes contre les cambriolages et les systèmes de surveillance vidéo qu’on trouve dans les banques ou les commerces (ou dans certaines écoles). Même si la technique de surveillance et les buts sont différents, l’idée générale reste la même. Un système de détection d’intrusion est composé principalement en trois parties : - Une source d’informations qui fournit un flux d’enregistrement d’événements (SOURCE DE DONNEES). - Un dispositif d’analyse qui détectera les signes d’intrusion (SENSEUR + ANALYSEUR). - Un composant qui générera une réponse en fonction des sorties du dispositif d’analyse (MANAGER). OPERATEUR Notification SOURCE DE DONNEES Activité SENSEUR Evenement ANALYSEUR Alerte Réponse MANAGER Politique de sécurité ADMINISTRATEUR Un système de détection d’intrusion, quand il croit avoir détecté une tentative d’intrusion, devra aussi être capable de : - déterminer le responsable de l’intrusion. Ces informations permettront de réagir vis-à-vis de cet individu. Par exemple, on pourrait lui bloquer l’accès au réseau. On pourrait aussi entreprendre des actions en justice. Pour cela, il faut bien sûr garder des traces de l’intrusion. - déterminer quelles actions frauduleuses ont été commises et quels sont les dégâts qui en résultent. - déterminer quelles sont les étapes nécessaires pour réparer les dommages et restaurer le système. En anglais, on parlera d’Intrusion detection system ou IDS en abrégé. Les différents types de systèmes de détection d’intrusion Il existe plusieurs types de détection d’intrusion. On les classifie en fonction des ressources qu’ils surveillent. Selon la source d’information que vous allez choisir, il se peut, et même il est fort probable, que vous trouviez un classement différent. Vous pourrez, lors de lectures ou de recherches, trouver un classement plus précis. Certaines personnes font, par exemple, la distinction entre, d’une part, un système qui scrute les fichiers de log ou d’événements d’un système d’exploitation et, d’autre part, un système qui vérifie les fichiers de log d’une application. Tous ces choix sont bien sûr arbitraires. Certaines personnes peuvent aussi utiliser une autre nomenclature. Dans tous les cas, vous retrouverez un classement qui référence les mêmes types de détecteurs d’intrusion mais dans des catégories différentes ou sous des noms différents. Système basé sur un host (host based intrusion detection system) Dans cette catégorie, je range toute une série de systèmes : ceux basés sur les applications et ceux qui sont des vérificateurs d’intégrité. Ce genre de détecteur analyse les fichiers de log générés par le système d’exploitation et par les différentes applications tournant sur celui-ci. Par exemple, on analyse le journal des événements de Windows NT pour trouver les traces d’une tentative d’intrusion. On fera de même avec les fichiers de log du serveur web, du serveur de mail…. Ces systèmes de détection d’intrusion vérifient aussi l’intégrité de certains fichiers. Ils tentent de détecter tous les accès illicites ou suspects à ces fichiers. Un exemple célèbre dans le monde Unix est le logiciel Tripwire de la société Tripwire Inc. (www.tripwire.com). On parle dans ce cas de système de vérification d’intégrité (system integrity verifiers ou SIV). Ils utilisent des sommes de contrôle pour vérifier si un fichier n’a pas été modifié. Système basé sur le trafic réseau (network based intrusion detection system ou NIDS) Comme son nom l’indique, ce type de système surveille un réseau : interception de tous les paquets circulant sur le segment et, à partir de ceux-ci, recherche des traces d’une intrusion éventuelle. Depuis quelques années, les réseaux ne cessent de se répandre, de s’étendre et de s’interconnecter, notamment via le développement d’Internet. Cette « ouverture » des réseaux informatiques sur le monde extérieur entraîne bien sûr une forte croissance du nombre d’attaques venant des réseaux. Il est donc intéressant de détecter les intrusions provenant de cette source. De plus, ce type de système de détection d’intrusion n’a aucune incidence sur les performances d’un réseau. Ils ne font qu’analyser les trames passant sur le segment où il est placé. Système hybride Ce type de système est le plus complet : il analyse à la fois les trames d’un réseau et les informations recueillies dans les fichiers de log générés par le système d’exploitation et les différentes applications. Ce genre de détecteur demandant beaucoup de ressources, surtout s’il doit surveiller un ordinateur combinant les fonctions de serveur web, de serveur mail, de serveur DNS… Le système de détection est découpé en plusieurs modules qui sont répartis sur les différents équipements du réseau. On parlera donc de système distribué. On placera, par exemple, un module qui analysera les informations venant d’un host sur une ou plusieurs machines, un autre module analysant le trafic du réseau sur une autre machine et un serveur qui collectera et recoupera les informations en provenance des différents modules. Ce serveur générera des rapports et des alertes qu’il communiquera à l’un des administrateurs. Système de leurre (deception system) Connu aussi sous le nom de pot de miel (honeypots) ou leurre (lures), il s’agit d’un système qui contient de pseudo-services dont le but est d’émuler une faille bien connue. On espère ainsi piéger le hacker éventuel qui croira avoir réussi à entrer dans le système. Ce système permet de détecter facilement les intrusions car c’est leur seul objectif. Comme un utilisateur « normal » ne devrait pas y accéder, toute tentative d’accéder à ce système est considérée comme suspecte. De plus, une technique couramment utilisée par les hackers consiste à scanner toutes les machines d’un réseau dans le but de déterminer les points faibles du réseau (voir le chapitre sur les scanners). Si le système de leurre a été scanné, il y a de fortes chances que les autres machines du réseau l’aient été aussi. Les systèmes de détection possèdent quelques désavantages. La machine attaquée pourrait être utilisée comme point de départ pour attaquer les autres machines du réseau. Il faut donc isoler convenablement ce système des autres systèmes du réseau. Tout ceci rend plus complexe l’administration du réseau et en matière de sécurité, la complexité engendre une augmentation des risques d’être exposé à une faille. Il ne faut pas oublier que ce genre de système devra être entretenu comme tout autre système. De plus, rien ne permet de dire que le système de leurre sera attaqué pendant qu’une autre machine subira une tentative d’intrusion. Enfin, un système de leurre, en simulant des failles sur une machine, peut inciter un hacker, content d’avoir trouvé une faille, à tenter de pénétrer dans les autres machines du réseau. Quelques exemples de honeypots : on peut utiliser une installation par défaut de Windows NT 4 avec un serveur web IIS 4 non patché dont on enregistrera toutes les tentatives d’accès. Il existe aussi des systèmes entièrement dédiés à cette tâche comme le Deception Tool Kit. Un « Deception Tool Kit » ressemble de l’extérieur à un service ordinaire mais, dans la pratique, il ne fait que simuler le fonctionnement de celui-ci. L’intrus croit voir un serveur de mail actif. En fait, le Deception Tool Kit simule l’activité du serveur mail en renvoyant à l’intrus des messages qui paraissent normaux. Pendant toute la durée de l’opération le Deception Tool Kit enregistre toute l’opération et prévient l’administrateur d’une activité suspecte. Un autre exemple est l’émulation d’un fichier de mots de passe dont toutes les entrées, même si elles paraissent correctes, sont en fait entièrement bidon. Dès que quelqu’un essaie d’accéder au fichier il sera immédiatement repéré. On peut trouver un Deception Tool Kit avec son code source à l’adresse http://all.net/dtk.html (il est destiné aux système Linux). Différenciation des systèmes de détection d’intrusion en fonction du facteur temps L’analyse des sources d’information (enregistrement des trames d’un réseau, fichiers de log d’une application) peut se faire soit en temps réel, soit en différé à intervalles réguliers. A intervalles réguliers Dans ce mode, la source d’information doit être enregistrée dans un fichier avant de pouvoir être analysée. On doit donc limiter l’accès à ce fichier pour éviter qu’un processus ou un utilisateur indélicat ne vienne le corrompre. Ce type de détecteur d’intrusion est surtout utilisé dans les anciens systèmes de détection car il ne nécessite pas beaucoup de ressources. On ne détecte donc une intrusion que lors de la phase d’analyse des données et il est peut-être déjà trop tard. En temps réel Dans ce mode, on analyse les informations dès leur disponibilité. On doit donc disposer de suffisamment de ressources pour traiter directement toutes les données scrutées (trafic du réseau, toutes les entrées dans les fichiers de log des applications…). Par ressources, on entend mémoire centrale car il faut beaucoup de mémoire pour reformer et maintenir à jour toutes les connexions passant par le détecteur d’intrusion. Il faut aussi disposer d’un processeur suffisamment puissant pour pouvoir traiter rapidement tout le flux d’information. Si le système n’est pas assez performant, il passera à côté d’une partie des événements. Par exemple, le système ne pourrait analyser qu’une partie des paquets passant sur le réseau. La détection en temps réel permet de répondre immédiatement à une attaque. On peut arrêter une connexion suspecte directement ou prévenir l’administrateur avant qu’il ne soit trop tard. Différenciation des systèmes de détection d’intrusion en fonction du type d’intrusion Détection d’utilisation frauduleuse (misuse detection) Ce type de détection est basé sur un système de règles définissant ce qu’est une utilisation frauduleuse. Pour définir ces règles, il faut s’informer sur les vulnérabilités, les attaques, les outils d’attaques… Il faut aussi transformer les données à analyser pour pouvoir les comparer aux règles définies. Les règles de ce type de système peuvent être divisées en signature en un seul morceau (ou atomique) et les signatures en plusieurs parties. Un exemple de signature atomique serait la détection d’un paquet mal formé (incohérence entre les informations fournies par le header et le contenu du paquet). Un exemple de signature en plusieurs parties serait une tentative de spammer un serveur mail (l’attaque est réalisée en plusieurs étapes : on se connecte au serveur mail, on s’identifie et puis on envoie un message). Ce type de système de détection d’intrusion ne peut évidemment détecter que les intrusions définies dans les règles à appliquer. Détection d’utilisation anormale (anomaly detection) Dans ce type de détecteur, on recherche les comportements inhabituels ou bizarres. Quand un employé se connecte à trois heures du matin alors qu’il ne devrait pas être au bureau, cela peut constituer un comportement suspect. On détecte aussi les accès à certains fichiers ou répertoires pour chaque utilisateur. Le fichier des mots de passe ne devrait pas être manipulé par n’importe qui. Ce type de détecteur pourrait compter aussi le nombre de tentatives ratées de login. Un ordinateur ou un périphérique peut aussi avoir un comportement anormal : par exemple, un ordinateur dont le taux d’occupation du processeur est en permanence proche de cent pour cent. On regardera aussi le taux d’occupation de la mémoire centrale et des disques durs. Pour pouvoir détecter les anomalies, il faut déterminer quel comportement est normal ou pas. On devra établir des profils d’utilisation normale. Ces profils permettront de mesurer dans quel mesure un comportement est normal ou pas, ils servent de système « métrique ». En général, ces profils sont créés sur base d’une analyse statistique des comportements des utilisateurs ou des ordinateurs. On établira ces profils en collectant des informations sur un système en fonctionnement. On enregistrera l’heure de connexion et de déconnexion d’un utilisateur. On étudiera les applications qu’il utilise et peut-être ses temps d’utilisation. On assignera à tous les comportements des valeurs en fonction des actions effectuées. Toutes ces valeurs seront stockées dans des tables qui peuvent prendre beaucoup de formes différentes. On pourrait enregistrer les profils dans des structures de données diverses choisies en fonction des choix d’implémentation. On peut utiliser des tableaux, des structures… Toutes les informations collectées pour établir les profils doivent donc être stockées sous une forme permettant des comparaisons aisées avec les données recueillies par le détecteur. On représentera donc au maximum les comportements sous forme numérique, ce qui facilite les comparaisons et permet de définir un degré de tolérance qu’on pourra quantifier en pour cent. Le système de détection analyse les données et crée un profil de session. Il compare le profil de session avec le profil « historique » (celui qui définit le comportement normal). Si le détecteur trouve une trop grande différence entre les deux profils, il génère une alerte. Principe de fonctionnement d’un NIDS Un système de détection d’intrusion réseau (Network based Intrusion Detection System) capture toutes les trames qui passent par le segment. Pour récupérer toutes les trames, on positionne l’interface réseau en « promiscuous mode ». Dans ce mode, chaque trame réseau génère une interruption. On peut ainsi surveiller tout le trafic et pas seulement le trafic dirigé vers le système hébergeant le détecteur. On trie les trames en fonction de leur protocole pour en extraire les informations dont on a besoin. Attaques pouvant affecter un NIDS Comme tout programme sur un réseau, un système de détection d’intrusion est susceptible de se faire attaquer. Il est même fort probable qu’il sera la première cible d’un pirate. Celui-ci a tout intérêt à mettre hors d’usage ou à « aveugler » tous les systèmes qui pourraient déceler sa tentative d’intrusion. Pour déjouer la vigilance d’un système de détection d’intrusion, un hacker tentera d’empêcher le système de détection d’intrusion de voir le trafic réseau de la même manière que la machine cible (endsystem). Pour ce faire, il insérera des paquets dans ses communications réseau. Ces paquets additionnels seront formés de telle manière que leur contenu pourrait être mal interprété ou mal reformé par un outil de détection d’intrusion. Si un paquet est mal interprété, il fausse tout le sens d’une communication. Le détecteur d’intrusion ne détecte dès lors pas une attaque ou détecte à tort une attaque. Il faudra donc faire très attention dans la manière dont on reconstituera les différentes connexions qui seront analysées. Les communications sur le réseau IP sont reconstruites à partir des paquets de données circulant sur le réseau. Un système de détection d’intrusion peut être victime de deux types de problème. Insertion Un système de détection d’intrusion peut accepter un paquet que la machine victime de l’attaque refuse. Seul le détecteur d’intrusion accepte les mauvais paquets, les autres systèmes sur le réseau n’en tiennent pas compte. En général, les attaques par insertion ont lieu quand le système de détection d’intrusion gère de manière moins stricte les paquets que le système destinataire du paquet. Pour corriger ce problème, il faut s’assurer que le détecteur d’intrusion est le plus strict possible quand il analyse les paquets lus sur le réseau. Evasion Le système destinataire d’un paquet peut accepter un paquet que le détecteur refuse. Le détecteur d’intrusion ne voit qu’une partie des informations sur une communication, il n’a pas alors suffisamment d’informations pour reconnaître une attaque. Un détecteur d’intrusion « passe à côté » de certains paquets quand il est trop strict dans la gestion des paquets. Le détecteur refuse des paquets que le système victime de l’attaque accepte. Les attaques par évasion et par insertion en pratique Heureusement, les attaques par insertion ou par évasion ne sont pas facilement utilisées. Un attaquant n’a pas toujours la possibilité d’insérer des paquets dans un flux de données. Certains protocoles sont faciles à analyser car ils ne nécessitent que l’envoi d’une simple requête par un système et attendent ensuite la réponse du système contacté. C’est le cas, par exemple, des requêtes simples à un DNS via UDP. D’autres protocoles sont plus complexes et nécessitent l’analyse de plusieurs paquets avant de pouvoir déterminer la signification d’une communication. Un détecteur d’intrusion doit analyser tous les paquets d’une connexion utilisant le protocole TCP avant de pouvoir déterminer si la connexion est suspecte ou non. Le protocole TCP autorise n’importe quelle quantité de données transportées dans des paquets différents. Chaque paquet peut arriver dans le désordre même s’ils ont été transmis dans l’ordre. Pour pouvoir reformer les connexions, on numérote chaque paquet avec ce qu’on appelle un numéro de séquence. C’est le destinataire qui assemble et réordonne le flux de paquets TCP. Les paquets au niveau IP peuvent aussi être découpés en paquets de plus petite taille, ce processus étant appelé fragmentation. Pour chaque fragment, un champ, appelé offset, spécifie la position du fragment à l’intérieur du paquet avant fragmentation. Une attaque par insertion ajoute des paquets au flux de données vues par le détecteur d’intrusion. Le système de détection d’intrusion assemble la communication différemment du système destinataire. Comme la séquence des données peut être différente, le système de détection ne voit pas nécessairement les données qui suivent de manière correcte. Dans certains cas, les données insérées par le hacker sont écrites sur les données déjà acceptées, le détecteur d’intrusion voit alors la communication de manière totalement différente du système destinataire. Dans d’autres cas, l’attaque par insertion provoque juste un ajout des données au flux vu par le système destinataire, ce qui suffit parfois à tromper la vigilance d’un système de détection d’intrusion. Une attaque par évasion perturbe l’assemblage du flux de données, le détecteur d’intrusion manque une partie des données. Les paquets « oubliés » par le détecteur d’intrusion peuvent être vitaux au bon assemblage du flux de données. Par exemple, si le détecteur d’intrusion n’est pas capable de « voir » le paquet avec le numéro de séquence numéro 6, il attendra la réémission de ce paquet, qui ne viendra jamais car le système destinataire l’a bien vu mais ne saura pas quoi faire des paquets suivants : doit-il s’en débarrasser ou doit-il tenter de reformer la communication avec les seuls paquets qu’il possède ? Dans certains cas, se défendre contre les attaques par insertion ou par évasion est simple : les paquets insérés sont simplement incorrects. Le détecteur doit vérifier que le checksum (somme de contrôle) d’un paquet est correct ou que les champs de l’en-tête du paquet sont corrects. Dans d’autres cas, résoudre les problèmes d’insertion ou d’évasion n’est pas aisé. Dans certaines situations, le détecteur d’intrusion ne peut pas déterminer si un paquet est accepté par le système destinataire uniquement en observant le trafic passant sur le réseau. La manière de gérer le réassemblage et la défragmentation des paquets d’une connexion varie dans certains cas d’un système d’exploitation à l’autre. Si deux fragments avec le même offset mais avec des données différentes arrivent, Windows NT 4 et Linux réagissent différemment : Windows NT 4 conserve les données contenues dans le premier fragment arrivé alors que Linux fait l’inverse. Certaines options des paquets TCP sont implémentées sur certains systèmes d’exploitation qui acceptent le paquet alors que d’autres systèmes d’exploitation refusent ces paquets avec ces options. Le détecteur d’intrusion doit donc connaître le système d’exploitation destinataire du paquet. Un paquet peut être aussi refusé par un système si sa mémoire est saturée, si le CPU est utilisé à cent pour cent ou si le système est saturé avec des connexions réseau… En plus, il y a un délai entre le moment où le système de détection d’intrusion et le système destinataire reçoivent un paquet. Le détecteur d’intrusion peut déjà avoir traité un paquet avant que le système destinataire ne le reçoive. Pendant ce délai il peut arriver quelque chose au système destinataire empêchant celui-ci de traiter le paquet. Le système de détection d’intrusion a aussi peut-être besoin de connaître la topologie du réseau pour déterminer s’il doit accepter ou non un paquet. S’il y a un routeur entre le système de détection d’intrusion et le système destinataire, un paquet n’est pas nécessairement vu par les deux systèmes. A chaque fois qu’un paquet passe par un routeur, la valeur du champ TTL (Time To Live) est décrémentée d’une unité. Dès que cette valeur atteint zéro, le routeur se débarrasse du paquet. Donc si le détecteur d’intrusion voit un paquet valide avec une valeur du champ TTL à un, il le considère comme bon mais le système destinataire, derrière le routeur, ne le recevra jamais. Le système de détection d’intrusion doit donc connaître la présence de routeur entre lui et les différents systèmes du réseau, il peut ainsi contrôler le champ TTL. Un hacker peut aussi exploiter une autre propriété des réseaux. Si le système de détection d’intrusion et le système destinataire sont sur des parties de réseau utilisant des supports physiques différents (par exemple de la fibre optique et du câble coaxial), la taille maximum des paquets (MTU) est différente. Un hacker peut profiter de cette propriété pour envoyer des paquets de la taille maximale et positionner le flag « don’t fragment » (DF) dans l’en-tête du paquet IP. Ce flag interdit la fragmentation des paquets. Mais pour passer d’un réseau à un autre réseau ayant une MTU plus petite, il faut fragmenter les paquets. Le paquet avec le flag DF positionné n’est pas autorisé à passer entre les deux réseaux, le système de détection d’intrusion et le système destinataire ne reçoivent donc pas le paquet envoyé par le hacker. Un système de détection d’intrusion peut être victime d’attaques par déni de service (voir chapitre sur les attaques par déni de service). Si un attaquant peut crasher le détecteur d’intrusion ou consommer toutes ses ressources, il pourra attaquer les autres machines du réseau comme si le détecteur d’intrusion n’existait pas. Il faut donc s’intéresser à ce problème. Toutes les considérations que je viens d’aborder sur les attaques contre les détecteurs d’intrusion ne constituent qu’un survol du problème. Je vous conseille, si vous voulez en savoir plus sur le sujet, de lire un document intitulé « Insertion, Evasion, Denial of Service : Eluding Network Intrusion Detection » de Thomas H. Ptacek et Timothy N. Newsham. On peut trouver ce document sur Internet (voir bibliographie). Les trois diagrammes ci-dessus sont tirés de ce document, j’ai simplement traduit les termes en français. Placement d’un NIDS Selon l’endroit où l’on positionne le système de détection, on ne surveille pas la même chose. Il est donc très important de bien placer son détecteur. INTERNET NIDS n°1 F I R E W A L L NIDS n°3 Réseau interne de l'entreprise NIDS n°4 NIDS n°2 Je vais voir les différentes positions où peut être placé un système de détection d’intrusion réseau. On prend comme exemple un réseau très simple, c’est-à-dire sans switch (un NIDS placé dans le réseau interne « voit » tout le trafic du réseau) avec un accès à Internet via un firewall (voir le schéma cidessus). - NIDS n°1 : Le système de détection d’intrusion se trouve entre la connexion Internet et le Firewall. Le système de détection d’intrusion est capable de détecter toutes les tentatives provenant de l’extérieur du réseau, même celles qui sont arrêtées par le Firewall. - NIDS n°2 : Le système de détection d’intrusion se trouve sur le Firewall. Cet emplacement est peu utilisé car le Firewall ne produit pas suffisamment d’informations permettant une détection efficace de l’intrusion. - NIDS n°3 : Le système de détection d’intrusion est placé entre le Firewall et le réseau interne de l’entreprise. Ce positionnement permet de détecter les attaques ayant franchi le Firewall. - NIDS n°4 : Le système de détection d’intrusion est placé à l’intérieur du réseau de l’entreprise. Les attaques internes au réseau de l’entreprise sont détectées. Réponse d’un NIDS à une attaque Un système de détection d’intrusion peut répondre de deux manières différentes. Il peut bloquer ou affecter d’une autre manière la progression d’une attaque : on parle alors de réponse active. Le système de détection d’intrusion peut aussi se contenter d’enregistrer l’attaque ou de prévenir l’administrateur du réseau : on parle alors de réponse passive. Ces deux types de réponse ne sont pas exclusives. Si un système de détection d’intrusion décide de prendre des mesures contre un utilisateur, cela ne l’empêche pas d’enregistrer en même temps l’attaque. Je vais voir maintenant plus en détails les deux types de réponse possibles. Réponse active Une réponse active implique que le détecteur d’intrusion prenne des mesures en réaction face à une attaque. Ces mesures peuvent prendre plusieurs formes mais on peut les classer en trois grandes catégories. Voici la liste des catégories avec leur explication respective : Prendre des mesures contre l’attaquant La forme la plus agressive de réponse serait de trouver la source de l’attaque et d’attaquer celle-ci. Cette forme de réponse est très tentante, surtout si le gestionnaire de la sécurité du réseau en a marre de se faire attaquer sans arrêt. Malheureusement, il ne faut pas oublier que la source de l’attaque peut être une machine dont le contrôle a été pris par le hacker. Si le détecteur d’intrusion attaque cette machine, il peut s’en prendre à la victime innocente du hacker et non au hacker lui-même. Même si le hacker coordonne son attaque depuis sa machine, il peut utiliser une adresse IP spoofée lors de son attaque. La contre-attaque peut donc viser une machine totalement étrangère au hacker. Une contre-attaque trop agressive peut aussi entraîner une escalade dans la violence des attaques. Le hacker qui, au début, se contentait de scanner les machines de votre réseau peut décider de lancer, en représailles de la contre-attaque du détecteur, une attaque hostile de grande envergure contre votre réseau. Enfin, il ne faut pas oublier qu’attaquer une machine peut entraîner des poursuites judiciaires à votre encontre, même si l’on croit avoir de bonnes raisons de le faire. Une forme plus bénigne de mesure contre un attaquant consiste à simplement arrêter la connexion tcp en cours de l’attaquant. Pour cela, il suffit de créer un paquet avec le flag RST (reset) positionné et de l’envoyer. Une autre forme de réponse consiste à demander au Firewall ou au routeur d’empêcher tout paquet provenant de l’adresse IP source de l’attaque d’entrer dans le réseau. Le détecteur d’intrusion peut aussi envoyer un e-mail à l’administrateur du réseau d’où provient l’attaque, lui demandant son assistance pour régler le problème de l’attaque. Modifier le comportement du système attaqué Le détecteur d’intrusion modifie son propre comportement ou celui de la machine cible pour mieux réagir à l’attaque. Quelques exemples : - Le système de détection d’intrusion détecte une attaque contre une machine, il arrête alors la cible de l’attaque avant que des données confidentielles ou critiques ne soient mises à jour. - Le détecteur d’intrusion peut aussi demander à la machine cible de ne plus accepter aucune connexion provenant de l’adresse IP de l’attaquant. - Le détecteur d’intrusion détecte une attaque, il va rechercher dans ses bases de données les instructions permettant de se protéger contre cette attaque et il envoie ses instructions à la machine cible qui les applique pour augmenter la qualité de ses défenses. Le détecteur peut aussi lancer un programme qui a pour mission de traiter l’attaque. - Le système de détection d’intrusion détecte une attaque contre une machine et surveille alors de manière plus précise toute l’activité de cette machine. Ces réponses sont parfois les plus optimales mais aussi les plus dures à implémenter. Collecter plus d’informations Collecter plus d’informations sur l’attaquant et l’attaque est surtout utile dans le cas où le système attaqué est un système critique et si on désire poursuivre l’auteur de l’attaque en justice. Le système de détection d’intrusion essaie de tracer l’attaquant pour retrouver le point d’origine de l’attaque. Le détecteur essaie de collecter le plus d’informations possible sur l’attaquant comme, par exemple, le nom de la compagnie hébergeant la machine du hacker ou le nom de la personne responsable de cette machine. Pour collecter le plus d’informations possible, l’administrateur du réseau peut utiliser des serveurs spéciaux qui simulent l’activité d’un vrai serveur qui, en fait, ne fait qu’enregistrer que les informations sur un intrus. On les appelle système de leurre ou, de manière plus imagée, pot de miel. Réponse passive Une réponse passive consiste à fournir à l’utilisateur du système de détection d’intrusion des informations sur l’attaque. L’utilisateur du système de détection d’intrusion, l’administrateur du réseau ou le responsable de la sécurité, décide lui-même des mesures à prendre en fonction des informations fournies par le détecteur d’intrusion. Une réponse passive consiste à générer des alarmes ou des notifications d’une attaque. Ces alarmes sont générées soit directement par le système de détection d’intrusion, soit par un programme différent qui, dès qu’il a été prévenu d’une attaque par le détecteur d’intrusion, envoie l’alarme ou la notification. Ces alarmes ou notifications peuvent prendre plusieurs formes. Voici quelque exemples : - Une alarme sonore : le programme émet un signal sonore ou joue un fichier son contenant un message comme « vous êtes attaqué ». En cas d’attaques répétées, cette technique peut devenir gênante. - Une alarme visuelle : un message est affiché sur la console ou l’écran de la personne responsable de la sécurité. Cette personne doit être en permanence derrière son ordinateur. Les alarmes visuelles sont intéressantes quand le système est visualisé via des graphes d’activité - Alarme via e-mail : un e-mail décrivant l’attaque est envoyé à l’administrateur responsable du système. Ces e-mails doivent contenir le maximum d’informations possible sur l’attaque. Ces informations peuvent inclure la gravité de l’attaque (un simple scannage de port ou la prise de contrôle d’une machine ont des niveaux de gravité), la description de l’attaque la plus exhaustive possible, des informations sur la cible de l’attaque, éventuellement la parade permettant de protéger le système attaqué… - Envoi de message SMS : variante d’une alarme par e-mail qui consiste à envoyer un message SMS sur le GSM de l’administrateur. Efforts de normalisation Un système de détection d’intrusion seul ne suffit pas toujours pour détecter toutes les tentatives d’intrusion. Si un système surveille l’activité du réseau, il ne pourra pas détecter les personnes qui essaient de prendre le contrôle d’une machine à partir de celle-ci. Il se peut donc que ce système ne possède pas suffisamment d’informations pour identifier certaines attaques ou déterminer l’identité d’un intrus éventuel. Pour avoir une sécurité optimale, on devra utiliser plusieurs types de système. Un système vérifiera l’intégrité des fichiers sensibles, un autre surveillera l’activité du réseau, un autre encore détectera les tentatives de login… Tous ces systèmes devront communiquer entre eux pour pouvoir faire des recoupements, pour partager leurs informations. Pour pouvoir communiquer entre eux, les systèmes de détection d’intrusion doivent pouvoir se comprendre (logique !). Comme ces systèmes utilisent des sources d’information différentes pour repérer les intrusions, il est fort probable qu’ils représentent les alertes de manière différente. Un système qui surveille un réseau identifiera un intrus par son adresse IP alors qu’un contrôleur d’intégrité de fichier l’identifiera sûrement avec un identificateur d’utilisateur (uid sous Unix). Si, en plus, tous ces systèmes viennent de fournisseurs différents, les faire communiquer entre eux va devenir très compliqué. Normalisation de nomenclature des vulnérabilités Quand on reçoit des informations sur des vulnérabilités provenant de plusieurs sources (système de détection d’intrusion, scanner de vulnérabilité…), on a besoin de savoir si on parle des mêmes vulnérabilités ou pas. Si on reçoit une alarme d’un système de détection d’intrusion, on doit pouvoir déterminer si la cible de l’attaque a été protégée contre cette attaque. Si on découvre une vulnérabilité affectant une machine, on doit pouvoir collecter et distribuer toutes les informations qu’on dispose sur cette faille. On doit être capable de comparer différents outils pour déterminer quel système est le plus complet, c’est-à-dire celui qui reconnaît le plus de vulnérabilités. Comme chaque outil identifie les vulnérabilités de manière différente, tous ces problèmes sont parfois difficiles à gérer. Certains systèmes identifieront une vulnérabilité de manière unique alors que d’autres identifieront séparément toutes les variantes de cette même vulnérabilité. Pour pouvoir comparer et faire communiquer entre eux ces différents systèmes, il est nécessaire de posséder un standard de nomenclature de vulnérabilité. CVE MITRE Corporation, une compagnie indépendante à but non lucratif, travaillant pour le gouvernement américain, a développé CVE (pour Common Vulnerability Enumeration) qui consiste en un effort de standardisation des noms de vulnérabilités. Les buts de CVE sont : - comptabiliser et différencier toutes les vulnérabilités, - assigner un nom unique et standard pour chaque vulnérabilité, - - exister indépendamment de chaque vue possible d’une vulnérabilité (un scanner de vulnérabilités ne représente pas une vulnérabilité de la même manière qu’un système de détection d’intrusion) , être « ouvert » et distribuable sans restriction. Il existe déjà des bases de données de vulnérabilités. Certaines proviennent des concepteurs de logiciels, tandis que d’autres viennent d’organismes officiels (CERT Advisories). Toutes ces bases sont souvent incomplètes car elles ont été créées dans le but de répondre à un problème particulier. Les logiciels n’ont dans leurs bases de données que les informations sur les vulnérabilités qu’ils tentent de détecter. Un système qui surveille l’activité d’un réseau ne connaît que les attaques venant du réseau. Un scanner de vulnérabilités ne possède que les informations sur ces tests. Certains organismes fournissent des bases de données incomplètes. CERT ne référence que les vulnérabilités potentiellement très dangereuses ou très répandues. Les vendeurs de logiciels ne publient des bulletins d’informations que sur les logiciels qu’ils commercialisent. Microsoft ne publie des informations sur la sécurité que pour les produits Windows et plus particulièrement les siens. D’autres bases de données ne sont pas publiquement accessibles ou possèdent des restrictions de distribution. Par exemple, la base ISS X-Force (xforce.iss.com) de la société Internet Secure System (ISS), une des bases de données les plus complètes, possède des copyrights empêchant de la distribuer librement. Le modèle de CVE est très simple : une vulnérabilité est identifiée par un identificateur unique (CVEannée-numéro) et par une description simple permettant de différencier chaque vulnérabilité. Eventuellement, une référence au nom donné dans d’autres bases de données est fourni. Voici un extrait de CVE : Name CVE19990011 CVE19990012 CVE19990013 CVE19990014 CVE19990016 CVE19990017 Description References CERT:CA-98.05.bind_problems Denial of Service vulnerabilities SGI:19980603-01-PX in BIND 4.9 and BIND 8 HP:HPSBUX9808-083 Releases via CNAME record and SUN:00180 zone transfer. XF:bind-axfr-dos Some web servers under Microsoft Windows allow remote CERT:CA-98.04.Win32.WebServers attackers to bypass access XF:nt-web8.3 restrictions for files with long file names. Stolen credentials from SSH clients via ssh-agent program, CERT:CA-98.03.ssh-agent allowing other local users to NAI:NAI-24 access remote accounts XF:ssh-agent belonging to the ssh-agent user. Unauthorized privileged access HP:HPSBUX9801-075 or denial of service via SUN:00185 dtappgather program in CDE. CERT:CA-98.02.CDE CERT:CA-97.28.Teardrop_Land FreeBSD:FreeBSD-SA-98:01 HP:HPSBUX9801-076 CISCO:http://www.cisco.com/warp/public/770 /land-pub.shtml Land IP denial of service XF:cisco-land XF:land XF:95-verv-tcp XF:land-patch XF:ver-tcpip-sys FTP servers can allow an CERT:CA-97.27.FTP_bounce attacker to connect to arbitrary XF:ftp-bounce ports on machines other than the XF:ftp-privileged-port FTP client, aka FTP bounce. (1) - (2) (3) (1) : identifiant de la vulnérabilité. (2) : description de la vulnérabilité (3) : référence aux autres bases de données de vulnérabilités, quand elle existe. Ce minimalisme dans la description des vulnérabilités facilite l’acceptation de ce standard. Le système d’exploitation touché par cette vulnérabilité n’est pas précisé dans un champ spécifique de la base de données. On pourrait catégoriser les systèmes de différentes manières. Certains préféreront les ranger en familles : Unix, Windows, Macintosh et les autres. D’autres utiliseront un classement plus précis mais beaucoup plus fastidieux où toutes les versions de chaque système d’exploitation atteintes par la vulnérabilité seront précisées (pour être rigoureux, il faudrait aussi indiquer quel patch ou service pack est installé). Grâce à cette simplicité dans la représentation, on peut représenter toutes les vulnérabilités. Cette représentation ne repose sur aucune représentation particulière des données. Un système de détection d’intrusion ne représente pas une vulnérabilité de la même manière qu’un scanner de vulnérabilités. Le CVE est une représentation minimale d’une vulnérabilité comportant uniquement les attributs nécessaires et suffisants pour représenter toutes les vulnérabilités. Un schéma de données plus complet n’aurait pas l’adhésion de tous les acteurs utilisant ce type de base de données. Certaines personnes trouveraient ce schéma inadapté à leurs besoins. Souvent, les développeurs d’outils de sécurité ou les organismes de sécurité ne publient pas de manière claire leur base de données sur les vulnérabilités. Ou bien ils publient leurs informations sous copyright ou restreignent leur distribution. Le CVE permet d’avoir une base de données intermédiaire servant de pont entre les différentes sources d’information. Patches Assessment Probe IDS Exploit Signature CVE Advisory Software Faults Enterprise Perspective Ce pont unique entre les différents systèmes permet aussi de réduire le nombre de liens entre les différentes bases de données. Si on possède n sources de données différentes, l’utilisation d’un CVE diminue leFigure nombre1:deExtensions liens d’un ordre n à un ordre n². to a Common Vulnerability Enumeration a) Sans CVE b) Avec CVE. Gestion du mapping entre des bases de données. L’utilisation de CVE pour mapper plusieurs sources de données a bien sûr un désavantage : la perte de précision. Le CVE ayant un schéma de données très simple, la liaison directe de deux bases de données est plus précise. Mais ce désavantage est minime en regard du gain de temps lors de l’utilisation de CVE. Il est bien sûr à espérer que les efforts de normalisation de nomenclature se développent dans le futur, permettant d’avoir des bases de données plus précises. Pour avoir un produit compatible CVE, il faut remplir trois conditions : - Un utilisateur devrait pouvoir entrer un nom venant de la base CVE pour trouver des informations. Les informations seront représentées en incluant le nom CVE correspondant. Un mécanisme permettant de relier sa base de données avec une base CVE devrait être présent. Format des messages envoyés par les outils de détection d’intrusion L’IETF, ou plus précisément un de ses groupes de travail appelé « intrusion detection working group » (idwg), est en train de développer les spécifications d’un format d’échange de données entre les différents éléments d’un ou plusieurs systèmes de détection d’intrusion. Ce format est orienté objet. Les messages seront sous la forme d’une hiérarchie de classes. Ce choix permet de le rendre extensible. On peut aussi ajouter ses extensions propriétaires. L’IETF définit aussi une version de ce format en utilisant l’Extensible Markup Language, plus connu sous son diminutif XML. Voici l’explication de la hiérarchie de classes utilisée pour représenter les messages échangés entre les détecteurs d’intrusion : ANALYSER analyserID : INTEGER analyserHost : NODE analyserProc : PROCESS ALERT 1 version : INEGER alertID : INTEGER confidence : INTEGER im pact : ENUM method : ENUM time : TIME signature : STRING reaction : STRING NAME 1 origin : ENUM name : STRING 1..* 0..* 0..* TARGET SOURCE ToolALert command : STRING alertIDs : INTEGER[] OverflowAlert size : INTEGER buffer : BYTE program : STRING CorrelationALert alertIDs : INTEGER[] Le composant principal de ce modèle est une classe ALERT. Chaque alerte est associée avec l’analyseur, qui l’a générée, et avec un temps unique. Elle est aussi associée avec une liste de zéro ou plusieurs cibles et une liste de zéro ou plusieurs sources de l’attaque. On remarque aussi qu’il a été prévu d’incorporer des informations supplémentaires en fonction du type d’alerte. Ces ajouts sont définis dans des classes spécifiques pour chaque type de problème. Par exemple, la classe ToolALert définit des informations supplémentaires sur les outils d’attaque utilisés, la classe OverflowAlert définit les alertes concernant les attaques par buffer overflow et la classe CorrelationAlert apporte des informations en rapport avec la corrélation des informations sur les alertes. Les cibles (TARGET) et les sources (SOURCE) des attaques sont, bien entendu, aussi décrites sous forme de classes. NODE TARGET 0..1 targetID : INTEGER decoy : ENUM USER 0..1 PROCESS 0..1 0..1 SERVICE La classe TARGET est composée d’un identifiant et d’un booléen indiquant si la cible est réelle ou spoofée. Une cible est spoofée quand son adresse IP est fausse : au lieu de donner sa véritable adresse IP, un intrus donne une adresse IP bidon. Un intrus utilise une adresse IP spoofée soit pour empêcher d’être identifié, soit pour se faire passer pour une personne ayant un accès légitime au service attaqué. Ses autres attributs sont spécifiés via d’autres classes qui seront instanciées ou pas, selon le type de la cible. Par exemple, un système de détection d’intrusion basé sur le réseau instanciera la classe NODE. Celle-ci définit un nœud sur un réseau, ce pourrait être un des ordinateurs, un routeur… Dans le cas d’un système de détection qui surveillerait la bonne exécution des programmes, on instanciera la classe PROCESS. NODE 0..1 SOURCE sourceID : INTEGER spoofed : BOOLEAN USER 0..1 0..1 PROCESS Les informations sur la source de l’attaque sont encodées dans la classe SOURCE de manière similaire à celles enregistrées dans la classe TARGET. IDENT ident : INTEGER ADDRESS PROCESS category : INTEGER data : STRING NODE pid : INTEGER name : STRING path : STRING arguments : STRING[] environ : STRING[] name : STRING location : STRING 0..* USER SERVICE name : STRING dport : INTEGER sport : INTEGER protocol : STRING WEBSERVICE url : STRING cgi : STRING method : STRING args : STRING category : INTEGER name : STRING uid : INTEGER group : INTEGER gid : INTEGER serialID : STRING SNMPSERVICE Oid : STRING Comm unity : STRING Comm and : STRING Voici la hiérarchie de classe définissant les objets définissant un nœud (NODE), un service (une application disponible à travers le réseau), un processus tournant sur une machine (PROCESS), un utilisateur (USER)… Toutes ces classes dérivent de la classe IDENT qui ne contient qu’un identificateur prédéfini par les analyseurs et les managers des systèmes de détection d’intrusion. Donc, au lieu d’utiliser une description complète d’un objet, on peut juste utiliser un identificateur qui devra bien sûr être unique. Cet identificateur empêche toute confusion possible entre la définition d’une alerte par différents programmes. Il se peut qu’une cible d’une attaque soit définie par son adresse IP par un NIDS et par son nom par un système de détection d’intrusion basé sur un host. Pour plus de détails, je renvoie le lecteur curieux à la RFC correspondante : http://www.ietf.org/internetdrafts/draft-ietf-idwg-data-model-02.txt Protocole de communication des systèmes de détection d’intrusion L’IETF est en train de développer un protocole de communication d’alertes : l’Intrusion Alert Protocole ou IAP. Ce protocole appartient à la couche application de la pile TCP/IP, comme le protocole FTP ou TELNET. Il s’inspire grandement du protocole HTTP. Lorsqu’une opération non conforme est effectuée, un code d’erreur du type 4xx ou 5xx est renvoyé. Ce type d’erreur est renvoyé quand on fait une demande erronée de page web par exemple. A l’heure de l’écriture de ce mémoire, les spécifications de ce protocole ne sont qu’au stade de brouillon (draft). Un numéro de port n’a pas encore été attribué par l’IANA. Pour plus de détails, je renvoie le lecteur curieux à la RFC correspondante : http://www.ietf.org/internet-drafts/draft-ietf-idwg-iap-01.txt Vulnérabilités et failles 1. Les Buffer Overflow Description rapide Quand des données sont saisies par un programme, elles sont stockées dans une zone mémoire appelée buffer. Une situation de Buffer Overflow se produit quand plus de données que celles prévues sont entrées et qu’il n’y a aucune vérification de dépassement de taille ou accroissement automatique de taille du buffer. Par exemple, un programmeur crée une zone mémoire de 256 caractères pour contenir le nom de l’utilisateur. Il croit ainsi réserver suffisamment de place pour considérer tous les cas possibles. Il a tort : un hacker tentera d’entrer plus de caractères encore. Les Buffer Overflow touchent principalement les programmes écrits dans des langages qui laissent la vérification de la taille des données à entrer dans les buffers au soin du programmeur. Les langages les plus touchés sont le C (Linux et beaucoup d’autres programmes sont écrits en C) et le C++ . Les langages les plus immunisés contre les Buffer Overflow sont les langages du type de Java ou Visual Basic qui effectuent toutes les vérifications de la taille des paramètres automatiquement sans aucune intervention du programmeur. Il en va de même du C ou du C++ quand on utilise les fonctions de l’API de Windows (zones d’édition). Les Buffer Overflow sont dangereux car cela revient à écrire des données au-delà de l’espace alloué au buffer. Ecrire des données supplémentaires peut causer le crash de l’application, modifier le comportement de l’application ou n’avoir aucun impact sur le bon déroulement du programme (la chance étant alors du côté du programmeur). Les Buffer Overflow permettent aussi modifier les paramètres de retour d’une fonction ou, ce qui est plus dangereux encore, d’exécuter une commande arbitraire du système. Par exemple, les hackers essaient d’exécuter un shell, leur permettant d’agir à leur guise surtout si le programme victime du Buffer Overflow tourne avec les privilèges root, ce qui est le cas de beaucoup de programmes qui doivent accéder à des ressources du système. Les attaques par Buffer Overflow touchent aussi bien le monde Windows que le monde Unix. Sous Linux, comme beaucoup de programmes sont disponibles avec leur code source, un hacker peut aisément trouver les problèmes de Buffer Overflow. En général, ces failles sont rendues publiques rapidement et un correctif est vite sorti. Sous Windows, trouver les Buffer Overflow est plus compliqué mais les hackers sont des gens déterminés et ils les trouvent. Comment s’en prémunir Si vous programmez en C, vérifiez qu’il n’y a aucun dépassement de taille des données à insérer dans un buffer. Certaines fonctions standard du C sont particulièrement à surveiller. En voici la liste : Fonction Séverité gets Solution Utilisation de fgets(buf, size, stdin). La plus risquée strcpy Très risquée Utiliser strncpy à la place. strcat Très risquée Utiliser strncpy à la place. sprintf Très risquée Utiliser strncpy à la place ou utiliser un indicateur de précision. scanf Très risquée Utiliser un indicateur de précision ou faire vousmême la vérification de la taille des données entrées. sscanf Très risquée Utiliser un indicateur de précision ou faire vousmême la vérification de la taille des données entrées. fscanf Très risquée Utiliser un indicateur de précision ou faire vousmême la vérification de la taille des données entrées. vfscanf Très risquée Utiliser un indicateur de précision ou faire vousmême la vérification de la taille des données entrées. vsprintf Très risquée Utiliser vsnprintf à la place ou utiliser un indicateur de précision. vscanf Très risquée Utiliser un indicateur de précision ou faire vousmême la vérification de la taille des données entrées. vsscanf Très risquée Utiliser un indicateur de précision ou faire vousmême la vérification de la taille des données entrées. streadd Très risquée Vous assurer que vous allouez 4 fois la taille du paramètre source pour la taille de la destination. strecpy Très risquée Vous assurez que vous allouez 4 fois la taille du paramètre source pour la taille de la destination. strtrns Risquée Vérifier manuellement que la destination est au moins aussi grande que la source. realpath Allouer votre buffer pour qu’il soit au moins de la Très risquée (ou taille de MAXPATHLEN. Et vérifier manuellement moins selon que l’argument d’entrée n’est pas plus grand que l’implémentation) MAXPATHLEN. syslog getopt getopt_long getpass Très risquée (ou moins selon l’implémentation) Très risquée (ou moins selon l’implémentation) Très risquée (ou moins selon l’implémentation) Très risquée (ou moins selon l’implémentation) Limiter les chaînes de caractères à une taille raisonnable avant de la passer. Limiter les chaînes de caractères à une taille raisonnable avant de la passer. Limiter les chaînes de caractères à une taille raisonnable avant de la passer. Limiter les chaînes de caractères à une taille raisonnable avant de la passer. getchar Risque modéré S’assurer de respecter les limites du buffer si cette fonction est utilisée dans une boucle. fgetc Risque modéré S’assurer de respecter les limites du buffer si cette fonction est utilisée dans une boucle. getc Risque modéré S’assurer de respecter les limites du buffer si cette fonction est utilisée dans une boucle. read Risque modéré S’assurer de respecter les limites du buffer si cette fonction est utilisée dans une boucle. bcopy Risque faible S’assurer que le buffer est aussi grand que ce vous ne le dites fgets Risque faible S’assurer que le buffer est aussi grand que ce que vous ne le dites memcpy Risque faible S’assurer que le buffer est aussi grand que ce que vous ne le dites snprintf Risque faible S’assurer que le buffer est aussi grand que ce que vous ne le dites strccpy Risque faible S’assurer que le buffer est aussi grand que ce que vous ne le dites strcadd Risque faible S’assurer que le buffer est aussi grand que ce que vous ne le dites strncpy Risque faible S’assurer que le buffer est aussi grand que ce vous ne le dites vsnprintf Risque faible S’assurer que le buffer est aussi grand que ce que vous ne le dites Voici deux exemples de tests à effectuer pour éviter un Buffer Overflow avec la fonction strcpy. Première méthode : if(strlen(src) >= dst_size) /* Faire quelque chose d’approprié comme lancer une erreur { */ } else strcpy(dst, src); Deuxième méthode : dst = (char *)malloc(strlen(src)+1); strcpy(dst, src); Il existe des applications qui testent les codes sources pour trouver des possibilités de Buffer OverFlow. Je citerai comme exemple le compilateur StackGuard (http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/), qui est un compilateur pour système Linux qui immunise votre code contre les Buffer Overflow. Stackguard ne modifie pas votre code source. Un autre exemple est its4 (www.rstcorp.com/its4/), un logiciel qui scanne votre code pour trouver toutes traces de code vulnérables aux Buffer Overflow. Pour se protéger contre les Buffer Overflow, on peut aussi utiliser une « application » appelée libsafe (http://www.bell-labs.com/org/11356/libsafe.html) qui intercepte tous les appels à des fonctions à risque en C et les remplace par son propre code sécurisé. Libsafe intercepte les appels aux fonctions de la librairie C à l’exécution et n’a donc pas besoin de connaître le code source de l’application qu’on exécute. Libsafe empêche alors l’écriture. Libsafe est disponible pour Linux. 2. Les scanners de vulnérabilités Les scanners de vulnérabilités sont des outils remarquables car ils permettent de découvrir les failles de sécurité ouvertes sur une machine ou un ensemble de machines. Les scanners de vulnérabilités sont des outils indispensables pour tout administrateur de système qui désire tester la sécurité des machines d’un réseau. Ces outils sont bien sûr tout autant prisés par les hackers qui y trouvent les mêmes intérêts que les administrateurs de système. Les scanners de vulnérabilités permettent d’automatiser la recherche de failles sur un système. Si vous devez gérer un nombre important de machines, rechercher les failles des différents systèmes peut devenir une tâche très rébarbative. Même si les scanners ne peuvent pas repérer toutes les failles qui touchent un système, ils en trouvent beaucoup et, en général, bien plus que si vous ne deviez le faire manuellement. Il nous arrive toujours d’oublier de faire un test et il existe des failles que l’on n’imagine pas. Les scanners de vulnérabilités scannent les ports d’une machine et déterminent quels sont les services qui sont en attente d’une connexion via le réseau. Comme chaque service à l’écoute sur un port est une porte ouverte potentielle pour un hacker, débarrassez-vous des services dont vous n’avez pas besoin. Les scanners de vulnérabilités testent beaucoup d’autres choses : ils testent les clés de la registry de Windows et testent la présence de failles dans une grande variété de logiciels : les serveurs web, serveurs mail, serveur FTP… Je vais donner quelques exemples de scanners de vulnérabilités. Scanners commerciaux : - Internet Security Scanner de la société ISS (www.iss.net) existe en version Windows et Linux. - Retina de la société Eeye (www.eeye.com) existe seulement en version Windows. Ces scanners possèdent des versions d’évaluations téléchargeables. Scanners à l’utilisation libre : - SATAN (http://www.porcupine.org/satan/) et ses dérivés SARA (http://www-arc.com/sara/) et SAINT (http:://wwdsilx.wwdsi.com/saint/) . - NESSUS (www.nessus.org) Tous ces scanners fonctionnent sur des machines Unix et leur code source est disponible librement. Voici un petit exemple d’utilisation du logiciel Retina de Eeye : Quand vous activez l’option « Miner » de ce programme, vous obtenez un résultat tel qu’il est présenté sur la capture d’écran ci-dessus. Dans la colonne du milieu, vous pouvez voir la liste des adresses IP des machines du réseau. Quand vous cliquez sur une de ces adresses, vous obtenez un affichage dans la troisième colonne de toutes les vulnérabilités de la machine spécifiée. Une description de la vulnérabilité ainsi que la méthode pour s’en prémunir sont affichées dans le volet du bas de la troisième colonne. 3. Les attaques par déni de service (Denial Of Service ou DOS) Description Une attaque par déni de service a pour but d’empêcher la victime d’avoir accès à une ressource particulière. Les utilisateurs légitimes ne pourront plus utiliser le service2 attaqué. Voici quelques exemples : - Tenter de saturer un réseau pour perturber le trafic réseau légitime. - Tenter d’interrompre le trafic entre deux machines pour rendre un service inutilisable. - Tenter d’empêcher un utilisateur particulier d’accéder à un service. - Tenter d’interrompre un service à un système spécifique ou à une personne. 2 Le mot service doit être compris au sens général et non spécifiquement aux services de Windows NT. Un service pourrait être un serveur web par exemple. Tous les problèmes affectant les services ne sont pas des attaques par déni de service même si elles résultent d’une activité malicieuse. Le déni de service peut être utilisé lors d’une attaque de plus grande envergure. Une utilisation inappropriée d’un service peut engendrer un déni de service. Par exemple, on installe un serveur FTP accessible à tout le monde (accès anonyme). Des utilisateurs indésirables vont y stocker des données illicites ou inappropriées (photos de pingouins, logiciels pirate, etc). La forte demande de bande passante et d’espace disque empêchera une utilisation normale du service. Les attaques par déni de service ne nécessitent pas nécessairement d’obtenir un accès au réseau. Certaines attaques consistent uniquement à envoyer des paquets, souvent mal formés, à une machine. L’attaquant n’a pas besoin de droits d’accès particuliers sur le système attaqué : il lui suffit juste d’avoir la capacité d’envoyer des paquets IP à la machine visée. Impact Une attaque par déni de service peut causer un crash de la machine cible. Ou si la cible n’est pas crashée, la rendre inutilisable. Certaines de ces attaques ne nécessitent pas beaucoup de ressources pour être exécutées mais peuvent « mettre à genoux » un système sophistiqué. On parle dans ce cas d’attaque asynchrone. Les différents modes d’attaque Les attaques par déni de service peuvent revêtir beaucoup de formes différentes et peuvent être dirigées contre une grande variété de services. On peut les classer dans trois grandes catégories : - Consommation de ressources limitées, rares ou non renouvelables. Destruction ou altération d’informations de configuration. Destruction physique ou altération de composants du réseau. Consommation de ressource limitée Les ordinateurs et les réseaux ont besoin pour fonctionner de certaines choses : de la bande passante (réseau), de la mémoire centrale et de l’espace disque, du temps CPU, de structures de données, d’accéder à d’autres ordinateurs ou réseau et, bien sûr, de courant et d’air frais. Connectivité réseau Les attaques par déni de service les plus fréquentes sont exécutées contre la connectivité réseau. L’exemple plus célèbre est le « SYN flood » (qui est plus loin). Ce type d’attaque ne dépend pas de la capacité d’un attaquant à consommer la bande passante mais de sa capacité à remplir les structures de données du kernel utilisées pour établir les connexions réseau. Même un réseau très rapide peut en être victime. Les machines victimes de ce type d’attaque ne seront plus capables ou auront des difficultés à accepter les connexions légitimes au système. Un site de commerce électronique incapable de recevoir les connexions de ses clients perdra inévitablement de l’argent. Utilisation des ressources d’un système contre lui-même Dans ce type d’attaque, l’attaquant utilise les propres ressources d’un réseau contre le réseau luimême. En général, l’intrus utilise les services basés sur le protocole UDP : echo, time, chargen, daytime. Le protocole UDP est utilisé de préférence pour ce type car il est facile de se faire passer pour une machine du réseau attaqué (IP spoofing). L’attaquant initialisera des connexions entre deux machines en utilisant des paquets UDP forgés (c’est-à-dire fabriqués de toute pièce) pour se faire passer pour l’une d’elles. L’autre machine répondra à la première en renvoyant des paquets de données, puis la machine qui a été spoofée pourrait à son tour répondre. Si l’attaquant envoie suffisamment de paquets forgés, les deux machines qui s’échangent des messages pourraient consommer toute la bande passante du segment de réseau où elles se trouvent. Consommation de la bande passante Un attaquant pourrait envoyer un nombre impressionnant de paquets aux différentes machines du réseau et ainsi saturer le réseau. Le réseau serait alors inutilisable. Un exemple célèbre est le Ping Flood. La commande « ping » permet de vérifier si une machine est accessible sur le réseau. Cette commande permet aussi, entre autres, de déterminer la qualité d’une liaison entre deux machines. Quand on exécute la commande, on envoie un paquet ICMP avec des données à une machine et celle-ci renvoie un paquet avec des données identiques. Le Ping Flood consiste à effectuer un grand nombre de commandes ping d’affilée contenant des données de taille importante. Toutes ces requêtes ICMP ainsi que leurs réponses génèrent un tel trafic que toute la bande passante est consommée. Ce type d’attaque requiert une grande bande passante pour le hacker. Il doit être capable d’envoyer suffisamment de paquets pour saturer le réseau cible. Parfois, pour exécuter ce type d’attaque, une machine ne suffit pas et l’attaquant utilise alors plusieurs machines à la fois. On parle alors d’attaques distribuées par déni de service (voir plus loin). Consommation d’autres ressources En plus de la bande passante, un intrus pourrait consommer d’autres ressources nécessaires au bon fonctionnement du système. Par exemple, dans beaucoup de systèmes d’exploitation, il existe un nombre limité de structures de données pour contenir les informations sur les processus en cours d’utilisation (identifiants de processus, tables de processus,…). L’intrus n’aura qu’à créer un script ou programme qui se réplique à l’infini pour saturer ces structures de données. Beaucoup de systèmes d’exploitation actuels, mais pas tous, possèdent un mécanisme de quota empêchant ce type d’attaque. Même si les structures de données servant à gérer les processus ne sont pas remplies, le nombre de processus créés empêche le système de fonctionner correctement. Le système d’exploitation est fortement ralenti car le processeur (CPU) passe plus de temps à changer de processus (task switching) qu’à les exécuter. On dit qu’il entre en situation de trashing. Un hacker pourrait essayer de consommer un maximum d’espace disque sur la machine attaquée. Il existe plusieurs méthodes pour consommer tout l’espace disque : - Générer un nombre impressionnant de messages e-mail (mail bombing). Profiter d’une zone de FTP ou d’un répertoire réseau partagé accessible en écriture pour y placer un nombre impressionnant de fichiers. Générer intentionnellement des erreurs qui seront loguées. De manière générale, toute action permettant d’écrire sur un disque peut être utilisée pour effectuer une attaque par déni de service s’il n’existe aucune restriction sur la quantité de données pouvant être écrites sur le disque. Dans beaucoup de sites, il existe un mécanisme bloquant une session après un certain nombre d’échecs de login. Un attaquant pourrait profiter de cette propriété pour empêcher un utilisateur légitime de se connecter. Les comptes administrateurs pourraient être vulnérables à ce type d’attaque. Il faut donc être sûr qu’on a, à tout moment, un moyen de se connecter en tant qu’administrateur. Un intrus peut aussi causer un crash ou rendre instable votre système en envoyant un paquet IP mal formé à destination d’une machine. L’exemple le plus célèbre est le « Ping of Death » (voir plus loin). Destruction ou altération des informations de configuration Un ordinateur mal configuré fonctionnera mal ou pas du tout. Un hacker pourrait donc essayer de modifier les paramètres d’une machine. Par exemple, si un hacker modifie les tables de routage d’un routeur, tout le réseau risque d’être inaccessible. De même, si un hacker arrive à modifier certaines entrées dans la registry de Windows, certains programmes risquent de ne plus tourner. Destruction physique ou altération de composants réseaux Ces attaques concernent principalement la sécurité physique et non la sécurité logicielle. On doit empêcher une personne malveillante d’approcher les ordinateurs, les routeurs, les câbles, les infrastructures électriques… La sécurité physique a pour but de protéger vos installations contre tout type d’attaque et pas uniquement les attaques par déni de service. On doit se protéger contre les vols, le vandalisme,etc. Pour toute information sur ce sujet, on se réfèrera aux services de police en tout genre et aux firmes privées actives dans le domaine. Prévention et réponse Les attaques par déni de service peuvent provoquer de sérieuses pertes de temps et donc d’argent. Quelques options permettent de se protéger contre les attaques par déni de service. Selon les besoins de votre réseau, vous pouvez utiliser certaines de ces options mais d’autres ne sont pas applicables, tout dépend de vos besoins. Voici la liste de ces options : - Filtrer les paquets au niveau du routeur. C’est-à-dire interdire les paquets entrants (ceux venant de l’extérieur du réseau) ayant une adresse IP source locale et interdire les paquets sortants (ceux venant de l’intérieur du réseau) ayant une adresse IP source ne faisant pas partie du réseau. Ces mesures empêchent certaines attaques par déni de service, principalement celles utilisant l’IP spooffing, et en plus empêche certaines attaques par déni de service d’être lancées à partir de votre réseau. Pour implémenter ces filtres, je vous conseille de consulter la documentation de votre routeur. Certaines autres adresses spéciales sont réservées à l’usage des réseaux privés et ne sont jamais attribuées à des machines joignables via Internet. On doit donc empêcher les paquets dont l’adresse IP source ou destination appartient à cette classe d’adresse. Voici la liste des plages d’adresse à filtrer : - 10.0.0.0 - 10.255.255.255 réservées aux réseaux privés de classe A - 127.0.0.0 - 127.255.255.255 loopback - 172.16.0.0 - 172.16.255.255 réservées aux réseaux privés de classe B - 192.168.0.0 - 192.168.255.255 réservées aux réseaux privés de classe C - S’ils sont disponibles, installez les patches pour se prémunir contre SYN Flood. Ces patchs réduisent les chances de réussite d’une attaque de ce type mais ne les empêchent pas complètement. Sous Linux, il est parfois plus facile d’installer un kernel plus récent que d’utiliser un patch. Pour trouver ces patches, il faut consulter le site web de la société qui commercialise le système à protéger. - Désactivez les services réseau non utilisés ou non nécessaires. Cela limite la capacité de l’attaquant à utiliser ces services pour effectuer des attaques par déni de service. - S’ils sont disponibles, activez les quotas système de votre système d’exploitation. Par exemple, si votre système d’exploitation exploite les quotas disque, appliquez-les à tous les comptes de votre système, spécialement si ces comptes utilisent des services réseau. Si, en plus, votre système d’exploitation supporte les partitions ou les volumes (par exemple des systèmes de fichiers montés à des endroits différents avec des attributs différents), il serait judicieux de séparer sur des partitions différentes les ressources critiques des autres. - Observez les performances de votre système et établissez un niveau de base définissant un comportement normal d’utilisation du système. Grâce à ce niveau de base, on peut comparer les performances du système avec des valeurs de référence. Ces comparaisons permettent de détecter un comportement bizarre d’une des machines du réseau. Les performances d’un système sont définies par l’activité disque, l’utilisation du CPU, le trafic réseau… Il existe des programmes capables de surveiller ces performances comme par exemple « Big Brother » de BB4 Technologies. - Utilisez un logiciel de vérification d’intégrité de fichiers du genre de Tripwire ( de Tripwire Inc.) pour détecter toute modification de vos fichiers de configuration. - Investissez et configurez une machine qui en cas de panne ou de mal fonctionnement d’un système peut le remplacer immédiatement et assurer une continuité dans la fourniture d’un service. Cette machine de remplacement vous permet de rétablir le système compromis à « votre aise », cette opération pouvant parfois prendre un certain temps. - Investissez dans des configurations de réseaux redondantes et à tolérance de panne. - Etablissez et maintenez à jour régulièrement une politique de sauvegarde des données (backup) et plus particulièrement des informations de configuration de vos systèmes importants. Ces sauvegardes vous permettront de rétablir un système compromis plus rapidement. - Etablissez et maintenez à jour une politique appropriée de mot de passe, spécialement pour les comptes avec de hauts privilèges comme le compte root sous Unix ou le compte administrateur sous Windows. Des mots de passe facilement devinables faciliteront le travail des hackers. Changez régulièrement les mots de passe. - Etablissez une politique de sécurité physique pour surveiller l’accès au ordinateurs, aux routeurs et aux autres équipements du réseau, aux câbles du réseau, au dispositif électrique… 4. SYN Flood Ce type d’attaque est aussi connu sous le nom de TCP SYN Flood car elle exploite une propriété du protocole TCP. Mais, en général, on l’appelle SYN Flood. Les attaques par SYN Flood peuvent être dirigées contre n’importe quel service réseau basé sur le protocole TCP. Elles peuvent être dirigées contre un serveur FTP, un serveur Mail, un serveur web… Une attaque par SYN Flood peut aussi être dirigée contre un routeur ou tout autre système utilisant le protocole TCP. Description Quand un système, appelé client, tente d’établir une connexion à un système fournissant un service, appelé serveur, le client et le serveur échange une séquence de messages. Le schéma de connexion est le même pour tous les services TCP : telnet, web, e-mail… Une connexion TCP se passe en trois temps : 1) Le client envoie un signal SYN qui correspond à une demande de connexion. Cette requête spécifie le port, donc le service, auquel on veut se connecter. 2) Le serveur répond avec un acquiescement (SYN-ACK) . 3) Le client finit d’établir une connexion en répondant avec un message d’acquiescement (ACK). La connexion avec le serveur est alors ouverte (open). Les échanges de données spécifiques à chaque protocole (telnet, FTP, Web) sont alors possibles. Voici le schéma de l’échange de messages lors de l’ouverture d’une connexion : Client Serveur SYN(1000) connexion à demi-ouverte SYN(2000), ACK(1001) ACK(2001) connexion ouverte Pour exécuter une attaque par SYN Flood, l’attaquant profite du moment où le serveur a renvoyé un acquittement (SYN-ACK) au client mais n’a pas encore reçu le message ACK du client. On dit que la connexion est à demi-ouverte (half-open). Le serveur possède en mémoire une table de données contenant les informations sur toutes les connexions en attente. Cette table, caractérisée par une taille finie, peut être saturée en créant intentionnellement trop de connexions à demi-ouvertes. Créer des connexions à demi-ouvertes est trivial, il suffit d’envoyer des demandes de connexion au serveur (message SYN). L’attaquant, profitant de l’ « IP spooffing » pour spécifier une adresse IP source fantaisiste, empêche le serveur de lui renvoyer un message SYN-ACK . Le message d’acquittement final (ACK) ne sera jamais reçu par le serveur qui l’attend. Les connexions à demi-ouvertes finissent par remplir la structure de données où elles sont enregistrées. Le serveur n'est plus alors capable d’accepter de nouvelles connexions tant que cette structure ne sera pas vidée, que ces connexions soit légitimes ou pas. Il existe certes un time-out sur chaque connexion pendante, et dès que le temps imparti est expiré, la connexion à demi-ouverte est supprimée. Dès que le serveur a supprimé les connexions en attente, il peut à nouveau recevoir de nouvelles connexions. Cependant, l’attaquant peut simplement continuer à envoyer des paquets « spooffés » de demande de connexion. Si l’envoi de nouveaux paquets est plus rapide que le temps nécessaire au time-out du serveur pour supprimer une connexion, le serveur ne pourra se rétablir que quand l’attaque se terminera. Impact Dans la plupart des cas, ce type d’attaque empêche un serveur d’accepter de nouvelles connexions mais les connexions en cours, aussi bien en sortie qu’en entrée, ne sont pas affectées. Mais dans certains cas, le système peut consommer toute sa mémoire, se crasher ou cesser d’être opérationnel. Les attaques par SYN Flood rendent inaccessibles les services TCP disponibles via Internet pendant la durée de l’attaque et pour quelque temps après. Solutions A l’heure actuelle, il n’existe pas de solution généralement acceptée pour résoudre ce problème. Les attaques par SYN Flood se basent sur une « faiblesse » des protocoles basés sur IP autorisant l’IP spoofing. Mais il existe des moyens permettant de « limiter la casse », les voici : - Filtrer les paquets au niveau des routeurs (voir précédemment). Installer les différents patchs fournis par les développeurs du système. L’attaque par SYN Flood étant très répandue et utilisée depuis longtemps, des patches permettant de limiter l’impact de ce type d’attaque ont été livrés par les développeurs de systèmes d’exploitation (Windows, Linux,…) ainsi que par les fabricants d’équipements réseaux (Cisco, 3Com, …). Ces patches diminuent le temps d’expiration d’une connexion à demi-pendante ou implémentent des mécanismes empêchant les structures de données de se saturer (la technique utilisée varie avec chaque implémentation de ces patches). - Utiliser les « SYN cookies ». Cette solution est disponible pour Linux sous forme de patch du kernel (http://www.dna.lth.se/~erics/software/tcp-syncookies-patch-1.gz). Ce patch permet aux connexions TCP/IP de se dérouler normalement jusqu’à ce que la table où sont stockées les informations sur les connexions à demi-ouvertes soit presque pleine. Alors, au lieu de renvoyer un message SYN-ACK, le serveur envoie un SYN cookie, une demande de connexion au client avec dans le header une « signature », le cookie. Le serveur attend une réponse du client au cookie pour envoyer son SYN-ACK. Quand il envoie un cookie, le serveur élimine la connexion à demiouverte de ses tables. Comme les cookies expirent après un bref délai, ils empêchent quelqu’un de remplir les tables du système complètement. Si quelqu’un essaie de saturer le système à l’aide de demandes de connexion avec une adresse spoofée, cette personne ne sera pas capable de répondre aux cookies. Si une personne essaie de saturer les tables du système avec son adresse IP réelle, cette personne ne pourra pas, ou difficilement, à la fois répondre aux cookies et envoyer des demandes de connexions au serveur. Détection Pour savoir si votre ordinateur est attaqué par quelqu’un utilisant le SYN Flood, il suffit d’utiliser la commande : netstat –n –p tcp Cette commande montre toutes les connexions en cours via le protocole TCP (paramètre –p tcp) avec les adresses sous forme numérique (le paramètre –n spécifie qu’on veut les adresses avec le numéro de port sous forme numérique). Les connexions à demi-ouvertes sont marquées par un état SYN_RECEIVED. Cette commande fait apparaître un texte qui aura la forme suivante : Active Connections Proto TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP Local Address 127.0.0.1:1030 127.0.0.1:1032 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:21 10.57.8.190:4801 Foreign Address 127.0.0.1:1032 127.0.0.1:1030 10.57.14.154:1256 10.57.14.154:1257 10.57.14.154:1258 10.57.14.154:1259 10.57.14.154:1260 10.57.14.154:1261 10.57.14.154:1262 10.57.14.154:1263 10.57.14.154:1264 10.57.14.154:1265 10.57.14.154:1266 10.57.14.221:139 State ESTABLISHED ESTABLISHED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED SYN_RECEIVED TIME_WAIT Si un grand nombre de connexions est dans l’état SYN_RECEIVED, il est vraisemblable qu’on est attaqué. 5. Les attaques distribuées par déni de service (Distributed Denial Of Service ou DDOS) Ce type d’attaque est très à la mode. Au lieu de lancer une attaque à partir d’un point unique, on utilise plusieurs ordinateurs pour l’effectuer. On installe des nœuds, dispositifs capables d’attaquer une cible, sur plusieurs machines et on les pilote via une machine unique, le client. L’utilisation de plusieurs points de départ pour ces attaques permet de « mettre à genoux » plus facilement la cible. Voici le schéma de base d’une attaque distribuée par déni de service : ATTAQUANT CLIENT Commande aux noeuds NOEUD NOEUD NOEUD NOEUD N'importe quel nombre d'attaques VICTIME Il existe des programmes célèbres permettant d’exécuter des attaques distribuées par déni de service. On peut citer TFN, pour Tribe Flood Network (il en existe plusieurs versions caractérisées par leur numéro), trinoo, stacheldraht … Je vais en expliquer un, j’ai choisi trinoo. Exemple : trinoo Voici les étapes d’une attaque utilisant trinoo : 1) L’attaquant stocke, sur un compte volé sur un système, les fichiers du programme trinoo sous forme pré-compilée. Ceux-ci sont composés d’un maître (master) et d’un démon (daemon), ainsi que des programmes permettant de hacker des systèmes où on installera les composants de trinoo. Ces outils comprennent des outils d’attaque (pour pénétrer les systèmes vulnérables), des outils de type scanner (pour trouver les machines « hackables »), des sniffers (récupération de mot de passe) et des root kits (pour prendre le contrôle des machines cibles et dissimuler ses traces). On volera un compte de préférence sur un système avec beaucoup d’utilisateurs, avec peu de surveillance administrative et avec la plus grande bande passante possible, pour des transferts de fichiers rapides. 2) A partir du compte volé, on scanne une plage d’adresses IP en vue de trouver des systèmes susceptibles d’ « accueillir » le ou les maîtres et les démons de trinoo. Les cibles privilégiées de trinoo sont Solaris de Sun et Linux (sur ces systèmes des sniffers, des Root Kit et toutes sortes de outils du « parfait petit hacker » sont disponibles gratuitement sur Internet) mais un compte volé sur n’importe quel autre système fait bien sûr l’affaire. 3) La liste de systèmes vulnérables créée précédemment est utilisée pour générer un script qui exploite ces vulnérabilités pour associer un shell à un port TCP (en général, le port TCP 1524). Le script généré automatise une connexion à ce shell pour confirmer que l’accès aux systèmes est bien effectif. Dans certains cas, un e-mail de confirmation de la prise de contrôle du système sera automatiquement envoyé à une boîte aux lettres électronique gratuite du style de celles fournies par Hotmail. L’attaquant dispose alors d’une liste de systèmes hackés permettant d’héberger les démons et les maîtres trinoo ainsi que les autres outils susceptibles d’être utilisés par le hacker, comme un Root Kit ou un sniffer. 4) A partir de cette liste de systèmes compromis, le hacker choisit les systèmes qui l’intéressent en fonction de l’architecture que l’on veut utiliser dans son réseau trinoo. Un hacker pourrait avoir une préférence pour les systèmes Linux qu’il connaîtrait mieux. A partir de son choix d’architecture, il compile les sources de trinoo et les stocke sur un compte sur Internet. 5) Un script est exécuté. Il prend la liste des systèmes compromis choisis et génère un nouveau script qui automatise le processus d’installation et exécute chaque installation en tâche de fond pour profiter au maximum du multi-tâche. 6) Optionnellement, un Root Kit est installé pour cacher la présence de programmes, de fichiers ou de connexions réseau. C’est surtout utile pour les maîtres indispensables au bon fonctionnement d’un réseau trinoo. Le hacker peut aussi installer des sniffers pour récupérer les mots de passe des autres machines du réseau de la machine compromise. Il peut ainsi hacker les autres machines simplement. Le hacker peut aussi installer d’autres programmes lui permettant de prendre le contrôle des autres machines du réseau. Si toutes les étapes se sont déroulées sans encombre, le hacker a installé son réseau trinoo. ATTAQUANT MAÎTRE DEMON DEMON MAÎTRE DEMON ATTAQUANT MAÎTRE DEMON DEMON MAÎTRE DEMON DEMON Schéma d'un "réseau trinoo" Le hacker prend alors le contrôle d’un ou des maîtres en utilisant le programme telnet. Il commande alors le ou les maîtres qui envoient des commandes aux démons qui attaqueront la ou les victimes. Détection Par défaut, un réseau trinoo utilise les ports suivants : - de l’attaquant au(x) maître(s) : 27665/tcp - d’un maître au(x) démon(s) : 27444/udp - d’un démon au(x) maître(s) : 31335/udp Un détecteur d’intrusion doit surveiller le trafic réseau utilisant ces ports. Pour communiquer entre eux, le démon et le maître envoient des chaînes de caractères « *HELLO *» (du démon au maître), « png » (du maître au démon) ou « PONG » (du démon au maître) entre autre. On peut donc détecter les communications entre un maître et un démon en surveillant les ports et le contenu des données. On peut aussi détecter la présence sur sa machine d’un des éléments d’un réseau trinoo en analysant les connexions ouvertes avec la commande netstat et la liste d’informations sur les fichiers ouverts par un processus (la commande Unix lsof) : Sur une machine où est installé un maître, on peut voir : # netstat -a --inet Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 *:27665 *:* . . . udp 0 0 *:31335 *:* . . . # lsof | egrep ":31335|:27665" master 1292 root 3u inet master 1292 root 4u inet # lsof -p 1292 COMMAND PID master 1292 master 1292 master 1292 master 1292 master 1292 master 1292 master 1292 master 1292 master 1292 master 1292 master 1292 USER root root root root root root root root root root root FD cwd rtd txt mem mem mem 0u 1u 2u 3u 4u TYPE DIR DIR REG REG REG REG CHR CHR CHR inet inet DEVICE 3,1 3,1 3,1 3,1 3,1 3,1 4,1 4,1 4,1 2534 2535 2460 2461 State LISTEN UDP *:31335 TCP *:27665 (LISTEN) SIZE NODE NAME 1024 14356 1024 30492 14357 342206 28976 63878 29116 4016683 29115 2967 UDP TCP /tmp/... 2 / /tmp/.../master /lib/ld-2.1.1.so /lib/libcrypt-2.1.1.so /lib/libc-2.1.1.so 2967 /dev/tty1 2967 /dev/tty1 /dev/tty1 *:31335 *:27665 (LISTEN) -----------------------------------------------------------------------------Sur une machine où est installé un démon (le code exécutant le démon s’appelle ns), on peut remarquer : -----------------------------------------------------------------------------# netstat -a --inet Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address . . . udp 0 0 *:1024 *:* udp 0 0 *:27444 *:* . . . # lsof | egrep ":27444" ns 1316 root 3u inet # lsof -p 1316 COMMAND PID USER FD TYPE DEVICE ns 1316 root cwd ns 1316 root rtd ns 1316 root txt /tmp/.../ns 2502 SIZE NODE DIR 3,1 DIR 3,1 REG 3,1 State UDP *:27444 NAME 1024 1024 6156 153694 /tmp/... 2 / 153711 ns ns ns ns ns ns ns ns 1316 root 1316 root /lib/libcrypt-2.1.1.so 1316 root 1316 root /dev/tty1 1316 root /dev/tty1 1316 root /dev/tty1 1316 root 1316 root mem mem REG REG 3,1 3,1 342206 63878 mem 0u REG CHR 3,1 4,1 4016683 29115 1u CHR 4,1 2967 2u CHR 4,1 2967 3u 4u inet 2502 inet 2503 28976 /lib/ld-2.1.1.so 29116 /lib/libc-2.1.1.so 2967 UDP *:27444 UDP *:1024 -----------------------------------------------------------------------------Une fois qu’un démon ou un maître a été détecté, il faut déterminer où se trouvent les autres éléments du réseau trinoo. Pour déterminer l’adresse des autres machines compromises, on peut soit analyser le trafic réseau et récupérer la ou les adresses IP des autres machines du réseau trinoo, soit essayer d’ « entrer » dans le démon ou le maître pour exécuter la commande qui permet de récupérer l’adresse des autres machines compromises. Les démons et/ou les maîtres peuvent être protégés par un mot de passe. Heureusement, l’algorithme de cryptage est très élémentaire. Un éditeur hexadécimal permettra de changer facilement un mot de passe dans le code du démon ou du maître. Comme le mot de passe du démon « voyage » sur le réseau en texte clair, il est facile de l’intercepter. Enfin, si la chance est avec nous, le hacker n’a pas modifié les mots de passe par défaut. Les maîtres possèdent une commande « bcast » qui affiche la liste de tous les démons qu’ils commandent. Nous pouvons ainsi repérer tous les démons. Les démons possèdent les commandes « shi pass » ou « png pass » (le paramètre pass spécifie le mot de passe permettant d’accéder aux maîtres) qui envoient des messages à son ou à ses maîtres, nous pouvons alors intercepter les adresses des maîtres en interceptant les paquets envoyés par les démons. Toutes les informations sur trinoo écrites ci-dessus ne sont valables qu’avec le code source original. Le code source est disponible sur Internet, rien ne dit qu’un hacker ne va pas le modifier et toute modification de celui-ci rend bien sûr la détection de trinoo (doit-on encore l’appeler ainsi ?) plus difficile. Pour plus d’informations sur les attaques distribuées par déni de service en général ou plus spécifiquement sur trinoo, je vous conseille de consulter les sites web spécifiés dans la bibliographie. 6. Les virus du type « I love you » Pour être précis, on doit dire ver (worm) au lieu de virus. Un ver, à la différence d’un virus, se propage tout seul sans aucune interaction avec un être humain. Un virus se propage quand deux individus échangent des fichiers d’une machine à l’autre ou qu’une personne exécute le programme infecté par le virus. En pratique, un virus et un ver n’ont pas beaucoup de différences et le terme générique de virus est dés lors utilisé aussi bien pour un ver que pour un virus. A titre d’exemple, je vais voir quelles sont les actions effectuées par « I love you » qui s’attaque aux machines Windows et qui vient de faire l’objet d’une large couverture médiatique et qui risque de faire de nombreux émules. « I love you » est un script Visual Basic qui se présente sous la forme d’un attachment, appelé "LOVELETTER-FOR-YOU.TXT.VBS". Le sujet du message est "ILOVEYOU" et le contenu du message contient le texte suivant : "kindly check the attached LOVELETTER coming from me.". Dès que cet attachement est ouvert, il va effectuer un certain nombre d’opérations illicites à l’intérieur du système. « I love you » modifie un certain nombre de fichiers dont voici la liste : - il recherche tous les fichiers avec une extension vbs ou vbe et les remplace par son propre code, - il recherche tous les fichiers avec une extension js, jse, css, wsh, sct ou hta et les remplace par son propre code et change leur extension en .vbs, - il recherche tous les fichiers avec une extension jpg ou jpg, leur ajoute une extension .vbs et remplace leur contenu par une copie de son propre code. - il recherche tous les fichiers avec une extension mp3 ou mp2 et crée une copie de lui-même dans un fichier portant le nom du fichier mp3 ou mp2 auquel il ajoute l’extension .vbs, le fichier original (avec l’extension .mp3 ou .mp2) n’étant pas effacé mais ses attributs étant changés (il devient caché). Tous les fichiers modifiés par « I love you » sont difficiles à récupérer puisqu’ils sont écrasés par le code d’« I love you ». Si quelqu’un va exécuter un des fichiers qui a été modifié, « I love you » est à nouveau lancé. « I love you » va, entre autres, créer des clés dans la registry pour pouvoir continuer à causer des dégâts après le redémarrage de la machine. Voici la liste des clés de la registry modifiée : HKLM\Software\Microsoft\Windows\CurrentVersion\Run\MSKernel32 HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices\Win32DLL HKLM\Software\Microsoft\Windows\CurrentVersion\Run\WIN-BUGSFIX HKCU\Software\Microsoft\Windows Scripting Host\Settings\Timeout HKCU\Software\Microsoft\Internet Explorer\Main\Start Page HKCU\Software\Microsoft\WAB\* « I love you » génère un script mIRC lui permettant de se propager via IRC, il modifie aussi la page de démarrage d’Internet Explorer…Et surtout, « I love you » envoie une copie de lui-même à toutes les personnes présentes dans carnet d’adresses de la personne infectée. Tous ces e-mails créés génèrent un trafic très important sur les serveurs mail et beaucoup de serveurs mail ont été saturés de cette manière. Après avoir vu les conséquences que peut avoir le virus « I love you », je vais expliquer quelques parades possibles en commençant par un conseil trivial et peut-être tardif : - mettre à jour votre logiciel anti-virus ou, si vous n’en possédez pas, vous en procurez un de toute urgence ; - désactiver la fonction Windows Scripting Host (WSH) nécessaire pour l’exécution des VBS (Visual Basic Script, le langage utilisé pour écrire « I love you »). Toute l’opération est décrite à l’adresse http://www.sophos.com/support/faqs/wsh.html/ . Attention : WSH est peut-être utilisé par d’autres applications qui l’utilisent légitimement et ces applications ne tourneront peut-être plus; - désactiver la fonction la fonction « active scripting » dans Internet Explorer. Avec Internet Explorer 5 version française, il faut activer OutilsOptions Internet…Sécurité (un des onglet)Personnaliser le niveau et cocher la case activer spécifique à l’« active scripting ». Attention : l’« active scripting » est peut-être utilisé par d’autres applications qui l’utilisent légitimement et ces applications ne tourneront peut-être plus; - filtrer les messages au niveau du serveur. Cette option est la plus intéressante car elle n’implique aucune modification des programmes clients et évite de laisser à des personnes non expertes la tâche de gérer le problème d ‘ « I love you ». La méthode la plus simple consiste à supprimer tout message donc le sujet (subject) est « ILOVEYOU ». et le contenu du message (body) est « kindly check the attached LOVELETTER coming from me ». Un filtrage plus fin consiste à analyser le contenu des attachements pour trouver les lignes de code VBS suivantes : - CreateObject("Outlook.Application") // message - RegRead("HKEY_ // - RegWrite("HKEY_ // CreateObject("WScript.Shell") CreateObject("Scripting.FileSystemObject") // utilisé pour envoyer le à d’autres utilisateurs lecture d’une clé de la registry écriture d’une clé de la registry Filtrer le contenu des attachments pour trouver ces chaînes de caractères permet de se prémunir contre toute variante de « I love you » mais cette méthode est peut-être un peu radicale. On peut aussi refuser tout message qui comporte un attachment avec une extension VBS, VBE, WSF, WSH, HTA. Je vous ai présenté quelques solutions de filtrage, à vous de choisir laquelle est la plus adaptée à vos besoins. Pour la mise en pratique de filtres sur votre serveur mail, je vous renvoie à la documentation de votre serveur web ou au site web de l’éditeur de celui-ci. Il existe déjà des variantes d’ « I love you », et elles fonctionnent sur le même principe. Le code source d’ « I love you » étant disponible, il n’est en effet pas très compliqué d’en écrire une variante. 7. Les root kits Les Root Kit sont un ensemble de programmes, appelé chevaux de Troie (trojans en anglais), qui remplacent certains programmes et sont nommés de la même manière que les programmes remplacés. Ces programmes permettent de prendre le contrôle d’une machine et/ou de cacher toute trace de l’intrusion. Je vais maintenant expliquer le fonctionnement du Linux Root Kit dans sa version 4 (ftp://ftp.technotronic.com/unix/trojans/lrk4.src.tar.gz). Il remplace certains programmes de Linux. Voici la liste de ces programmes avec un bref descriptif : chfn fonctionnement normal ajouts de la version modifiée changement du nom d’un utilisateur et de ses informations. permet à un simple utilisateur de récupérer les privilèges root. chsh fonctionnement normal ajouts de la version modifiée changement de shell permet de récupérer les privillège root à partir d’un compte simple utilisateur. crontab fonctionnement normal exécution de commande à intervalles réguliers permet de cacher certaines entrées dans la table crontab qui liste les commandes à exécuter à intervalles réguliers. ajouts de la version modifiée du fonctionnement normal ajouts de la version modifiée find fonctionnement normal affichage de l’espace disque utilisé par des fichiers ou des répertoires. permet de cacher certains fichiers. recherche récursive de fichiers dans un répertoire. ifconfig ajouts de la version modifiée permet de cacher certains fichiers fonctionnement normal affiche, entre autre, l’état des interfaces réseaux. permet de cacher une interface en « promiscuous mode ». En pratique, cache la présence d’un sniffer. ajouts de la version modifiée inetd fonctionnement normal ajouts de la version modifiée killall fonctionnement normal ajouts de la version modifiée login fonctionnement normal ajouts de la version modifiée ls fonctionnement normal ajouts de la version modifiée netstat fonctionnement normal ajouts de la version modifiée démon par lequel passent toutes les demandes à un service réseau. permet de récupérer un accès à distance. envoi d’un signale à un ou plusieurs processus. Par défaut, c’est le signal SIGTERM qui termine un processus. permet d’empêcher d’arrêter les processus cachés. commence une session sur le système permet de récupérer un accès à distance sur le système en entrant n’importe quel nom d’utilisateur et le mot de passe défini dans le Root Kit. Quand le hacker utilise la version modifiée de login, l’history qui enregistre toutes les connexions est désactivé. affichage des informations sur les répertoires et les fichiers qu’ils contiennent. permet de cacher la présence de certains fichiers affichage d’informations réseau de l’ordinateur. permet de cacher la présence de certaines connexions. passwd fonctionnement normal ajouts de la version modifiée modification du mot de passe. permet à un simple utilisateur de récupérer les privilèges root. Il lui suffit d’entrer le mot de passe Root Kit à la place de son ancien mot de passe. pidof fonctionnement normal permet de récupérer le pid (son numéro) d’un programme qui tourne. permet de cacher certains processus ajouts de la version modifiée ps fonctionnement normal ajouts de la version modifiée rshd fonctionnement normal ajouts de la version modifiée syslogd fonctionnement normal ajouts de la version modifiée affichage de l’état des processus en cours permet de cacher certains processus. serveur shell à distance permet l’exécution de commandes à distance. permet l’exécution de commandes à distance avec les privilèges root. démon qui gère les fichiers de log. permet d’empêcher certaines chaînes de caractères d’être insérées dans les fichiers de log. tcpd fonctionnement normal ajouts de la version modifiée top fonctionnement normal ajouts de la version modifiée démon qui intercepte les appels du démon inetd, vérifie les paramètres nécessaires au protocole et les autorisations. permet de cacher certaines connexions et empêche tout refus d’une demande de service réseau. affichage de l’activité du CPU et des processus qui l’utilisent. permet de cacher certains processus. Linux Root Kit 4 contient aussi quelques outils intéressants (du point de vue du hacker), en voici la liste : Bindshell permet d’associer à un shell un port, le hacker peut ainsi accéder au système à distance. Fix remplace les dates et les checksums d’un fichier pour qu’il ressemble au fichier modifié. Linsniffer un sniffer, rien n’interdit au hacker d’utiliser un autre sniffer s’il le désire. sniffchk programme qui teste si le sniffer est toujours actif et fonctionne correctement. Wted un éditeur de fichier wtmp et utmp, ces fichiers enregistrent les informations sur les utilisateurs quand ils se connectent au système (login) et quand ils se déconnectent du système (logout). L’éditeur permet d’aller modifier les informations contenues dans ces fichiers et, ainsi, dissimuler le passage d’un hacker. z2 programme qui efface les dernières entrées dans les fichiers utmp et wtmp (voir plus haut) pour un utilisateur donné. Détecter la présence d’un Root Kit après son installation n’est pas évident, Il faut donc essayer de détecter son installation. Pour cela, on doit surveiller toutes les modifications aux programmes remplacés par le Root Kit comme ps, ls, netstat… Pour découvrir ces modifications, l’administrateur du système doit vérifier l’intégrité des fichiers. Il utilise pour cela des programmes du type de md5 qui appliquent un algorithme de hachage sur un fichier, une valeur numérique est ainsi récupérée à partir de cet algorithme. On compare cette valeur numérique avec celle qui est générée à partir du fichier original. Si les deux valeurs correspondent, les deux fichiers sont identiques. Dans le cas contraire, le fichier sur votre système a été modifié. Ces comparaisons peuvent être automatisées grâce à un outil du style de Tripwire de Tripwire Inc. (www.tripwire.com). Pour vérifier l’intégrité des fichiers, il faut les comparer avec les fichiers originaux. Ces fichiers originaux doivent provenir d’une source fiable et non-inscriptible comme le CD-ROM d’installation du programme ou du site Internet ou FTP de l’éditeur du logiciel. En général, ils fournissent avec le logiciel un fichier contenant la valeur générée par l’application du programme md5 sur les fichiers de l’application. Pour détecter la présence d’un hacker une fois qu’un Root Kit est installé, je vous conseille d’utiliser d’autres programmes que ceux qui sont en général remplacés par le Root Kit, par exemple le programme libre de droit lsof (List of open file). lsof permet de voir la liste des processus et les utilisateurs qui les utilisent, les connexions ouvertes ainsi que la liste des fichiers ouverts. Pour se débarrasser d’un Root Kit, il faut réinstaller tous les programmes modifiés avec les fichiers originaux. Il existe aussi des Root Kit pour d’autres Unix (FreeBSD, Solaris…) : on peut les trouver à l’adresse ftp://ftp.technotronic.com/unix/trojans/ ou http://packetstorm.securify.com/trojans/ ainsi que des versions plus récentes de Linux Root Kit. Windows possède aussi son Root Kit : il permet de cacher des entrées dans la registry. Il permet aussi d’exécuter des programmes de l’administrateur avec des privilèges de simple utilisateur. Pour plus d’informations : http://phrack.infonexus.com/search.phtml?view&article=p55-5 An Introduction to Intrusion Detection by Aurobindo Sundaram Introduction In the last three years, the networking revolution has finally come of age. More than ever before, we see that the Internet is changing computing as we know it. The possibilities and opportunities are limitless; unfortunately, so too are the risks and chances of malicious intrusions. It is very important that the security mechanisms of a system are designed so as to prevent unauthorized access to system resources and data. However, completely preventing breaches of security appear, at present, unrealistic. We can, however, try to detect these intrusion attempts so that action may be taken to repair the damage later. This field of research is called Intrusion Detection. Anderson, while introducing the concept of intrusion detection in 1980 [1], defined an intrusion attempt or a threat to be the potential possibility of a deliberate unauthorized attempt to access information, manipulate information, or render a system unreliable or unusable. Since then, several techniques for detecting intrusions have been studied. This paper discusses why intrusion detection systems are needed, the main techniques, present research in the field, and possible future directions of research. The need for Intrusion Detection Systems A computer system should provide confidentiality, integrity and assurance against denial of service. However, due to increased connectivity (especially on the Internet), and the vast spectrum of financial possibilities that are opening up, more and more systems are subject to attack by intruders. These subversion attempts try to exploit flaws in the operating system as well as in application programs and have resulted in spectacular incidents like the Internet Worm incident of 1988 [12]. There are two ways to handle subversion attempts. One way is to prevent subversion itself by building a completely secure system. We could, for example, require all users to identify and authenticate themselves; we could protect data by various cryptographic methods and very tight access control mechanisms. However this is not really feasible because: 1. In practice, it is not possible to build a completely secure system. Miller [10] gives a compelling report on bugs in popular programs and operating systems that seems to indicate that (a) bug free software is still a dream and (b) no-one seems to want to make the effort to try to develop such software. Apart from the fact that we do not seem to be getting our money's worth when we buy software, there are also security implications when our E-mail software, for example, can be attacked. Designing and implementing a totally secure system is thus an extremely difficult task. 2. The vast installed base of systems worldwide guarantees that any transition to a secure system, (if it is ever developed) will be long in coming. 3. Cryptographic methods have their own problems. Passwords can be cracked, users can lose their passwords, and entire crypto-systems can be broken. 4. Even a truly secure system is vulnerable to abuse by insiders who abuse their privileges. 5. It has been seen that that the relationship between the level of access control and user efficiency is an inverse one, which means that the stricter the mechanisms, the lower the efficiency becomes. We thus see that we are stuck with systems that have vulnerabilities for a while to come. If there are attacks on a system, we would like to detect them as soon as possible (preferably in real-time) and take appropriate action. This is essentially what an Intrusion Detection System (IDS) does. An IDS does not usually take preventive measures when an attack is detected; it is a reactive rather than pro-active agent. It plays the role of an informant rather than a police officer. The most popular way to detect intrusions has been by using the audit data generated by the operating system. An audit trail is a record of activities on a system that are logged to a file in chronologically sorted order. Since almost all activities are logged on a system, it is possible that a manual inspection of these logs would allow intrusions to be detected. However, the incredibly large sizes of audit data generated (on the order of 100 Megabytes a day) make manual analysis impossible. IDSs automate the drudgery of wading through the audit data jungle. Audit trails are particularly useful because they can be used to establish guilt of attackers, and they are often the only way to detect unauthorized but subversive user activity. Many times, even after an attack has occurred, it is important to analyze the audit data so that the extent of damage can be determined, the tracking down of the attackers is facilitated, and steps may be taken to prevent such attacks in future. An IDS can also be used to analyze audit data for such insights. This makes IDSs valuable as real-time as well as post-mortem analysis tools. Spafford [13] reports: Information theft is up over 250% in the last 5 years. 99% of all major companies report at least one major incident. Telecom and computer fraud totaled $10 billion in the US alone. It is thus more important than ever before that since it seems obvious that we cannot prevent subversion, we should at least try to detect it and prevent similar attacks in future. In the following sections, we use definitions from the pioneering work in intrusion detection[1] Risk : Accidental or unpredictable exposure of information, or violation of operations integrity due to the malfunction of hardware or incomplete or incorrect software design. Vulnerability : A known or suspected flaw in the hardware or software or operation of a system that exposes the system to penetration or its information to accidental disclosure. Attack : A specific formulation or execution of a plan to carry out a threat. Penetration : A successful attack -- the ability to obtain unauthorized (undetected) access to files and programs or the control state of a computer system. Anderson also classified intruders into two types, the external intruders who are unauthorized users of the machines they attack, and internal intruders, who have permission to access the system, but not some portions of it. He further divided internal intruders into intruders who masquerade as another user, those with legitimate access to sensitive data, and the most dangerous type, the clandestine intruders who have the power to turn off audit control for themselves. Classification of Intrusion Detection Systems Intrusions can be divided into 6 main types [11] 1. Attempted break-ins, which are detected by atypical behavior profiles or violations of security constraints. 2. Masquerade attacks, which are detected by atypical behavior profiles or violations of security constraints. 3. Penetration of the security control system, which are detected by monitoring for specific patterns of activity. 4. Leakage, which is detected by atypical use of system resources. 5. Denial of service, which is detected by atypical use of system resources. 6. Malicious use, which is detected by atypical behavior profiles, violations of security constraints, or use of special privileges. However, we can divide the techniques of intrusion detection into two main types. Anomaly Detection : Anomaly detection techniques assume that all intrusive activities are necessarily anomalous. This means that if we could establish a "normal activity profile" for a system, we could, in theory, flag all system states varying from the established profile by statistically significant amounts as intrusion attempts. However, if we consider that the set of intrusive activities only intersects the set of anomalous activities instead of being exactly the same, we find a couple of interesting possibilities: (1) Anomalous activities that are not intrusive are flagged as intrusive. (2) Intrusive activities that are not anomalous result in false negatives (events are not flagged intrusive, though they actually are). This is a dangerous problem, and is far more serious than the problem of false positives. The main issues in anomaly detection systems thus become the selection of threshold levels so that neither of the above 2 problems is unreasonably magnified, and the selection of features to monitor. Anomaly detection systems are also computationally expensive because of the overhead of keeping track of, and possibly updating several system profile metrics. Some systems based on this technique are discussed in Section 4 while a block diagram of a typical anomaly detection system is shown in Figure 1. Misuse Detection: The concept behind misuse detection schemes is that there are ways to represent attacks in the form of a pattern or a signature so that even variations of the same attack can be detected. This means that these systems are not unlike virus detection systems -- they can detect many or all known attack patterns, but they are of little use for as yet unknown attack methods. An interesting point to note is that anomaly detection systems try to detect the complement of "bad" behavior. Misuse detection systems try to recognize known "bad" behavior. The main issues in misuse detection systems are how to write a signature that encompasses all possible variations of the pertinent attack, and how to write signatures that do not also match non-intrusive activity. Several methods of misuse detection, including a new pattern matching model are discussed later. A block diagram of a typical misuse detection system is shown in Figure 2 below. Anomaly Detection Systems There have been a few major approaches to anomaly intrusion detection systems, some of which are described below. Statistical approaches: In this method, initially, behavior profiles for subjects are generated. As the system continues running, the anomaly detector constantly generates the variance of the present profile from the original one. We note that, in this case, there may be several measures that affect the behavior profile, like activity measures, CPU time used, number of network connections in a time period, etc. In some systems, the current profile and the previous profile are merged at intervals, but in some other systems profile generation is a one time activity. The main advantage to statistical systems is that they adaptively learn the behavior of users; they are thus potentially more sensitivte than human experts. However there are a few problems with statistical approaches: they can gradually be trained by intruders so that eventually, intrusive events are considered normal, false positives and false negatives are generated depending on whether the threshold is set too low or too high, and relationships between events are missed because of the insensitivity of statistical measures to the order of events. An open issue with statistical approaches in particular, and anomaly detection systems in general, is the selection of measures to monitor. It is not known exactly what the subset of all possible measures that accurately predicts intrusive activities is. Static methods of determining these measures are sometimes misleading because of the unique features of a particular system. Thus, it seems that a combination of static and dynamic determination of the set of measures should be done. Some problems associated with this technique have been remedied by other methods, including the method involving Predictive Pattern Generation, which takes past events into account when analyzing the data. Predictive pattern generation: This method of intrusion detection tries to predict future events based on the events that have already occurred [14]. Therefore, we could have a rule E1 - E2 --> (E3 = 80%, E4 = 15%, E5 = 5%) This would mean that given that events E1 and E2 have occurred, with E2 occurring after E1, there is an 80% probability that event E3 will follow, a 15% chance that event E4 will follow and a 5% probability that event E5 will follow. The problem with this is that some intrusion scenarios that are not described by the rules will not be flagged intrusive. Thus, if an event sequence A - B - C exists that is intrusive, but not listed in the rulebase, it will be classified as unrecognized. This problem can be partially solved by flagging any unknown events as intrusions (increasing the probability of false positives), or by flagging them as non-intrusive (thus increasing the probability of false negatives). In the normal case, however, an event is flagged intrusive if the left hand side of a rule is matched, but the right hand side is statistically very deviant from the prediction. There are several advantages to this approach. First, rule based sequential patterns can detect anomalous activities that were difficult with traditional methods. Second, systems built using this model are highly adaptive to changes. This is because low quality patterns are continuously eliminated, finally leaving the higher quality patterns behind. Third, it is easier to detect users who try to train the system during its learning period. And fourth, anomalous activities can be detected and reported within seconds of receiving audit events. Another approach taken in intrusion detection systems is the use of neural networks. The idea here is to train the neural network to predict a user's next action or command, given the window of n previous actions or commands. The network is trained on a set of representative user commands. After the training period, the network tries to match actual commands with the actual user profile already present in the net. Any incorrectly predicted events (events and commands are used interchangeably in this discussion) actually measure the deviation of the user from the established profile. Some advantages of using neural networks are: [8] they cope well with noisy data, their success does not depend on any statistical assumption about the nature of the underlying data, and they are easier to modify for new user communities. However, they have some problems. First, a small window will result in false positives while a large window will result in irrelevant data as well as increase the chance of false negatives. Second, the net topology is only determined after considerable trial and error. And third, the intruder can train the net during its learning phase. Misuse Detection Systems There has been significant research in misuse detection systems in the recent past, including attempts at SRI, Purdue University and the University of California-Davis. Some of these systems are explained in depth in this section. Expert systems are modeled in such a way as to separate the rule matching phase from the action phase. The matching is done according to audit trail events. The Next Generation Intrusion Detection Expert System (NIDES) developed by SRI is an interesting case study for the expert system approach. NIDES follows a hybrid intrusion detection technique consisting of a misuse detection component as well as an anomaly detection component. The anomaly detector is based on the statistical approach, and it flags events as intrusive if they are largely deviant from the expected behavior. To do this, it builds user profiles based on many different criteria (more than 30 criteria, including CPU and I/O usage, commands used, local network activity, system errors etc.) [8]. These profiles are updated at periodic intervals. The expert system misuse detection component encodes known intrusion scenarios and attack patterns (bugs in old versions of sendmail could be one vulnerability). The rule database can be changed for different systems. One advantage of the NIDES approach is that it has a statistical component as well as an expert system component. This means that the chances of one system catching intrusions missed by the other increase. Another advantage is the problem's control reasoning is cleanly separated from the formulation of the solution. There are some draw backs to the expert system approach too. For example, the expert system has to be formulated by a security professional and thus the system is only as strong as the security personnel who programs it [7]. This means that there is a real chance that expert systems can fail to flag intrusions. It is for this reason that NIDES has an anomaly as well as a misuse detection component. These two components are loosely coupled in the sense that they perform their operations independently for the most part. The NIDES system runs on a machine different from the machine(s) to be monitored, which could be unreasonable overhead. Furthermore, additions and deletions of rules from the rule-base must take into account the inter-dependencies between different rules in the rulebase. And there is no recognition of the sequential ordering of data, because the various conditions that make up a rule are not recognized to be ordered. Keystroke monitoring is a very simple technique that monitors keystrokes for attack patterns. Unfortunately the system has several defects -- features of shells like bash, ksh, and tcsh in which user definable aliases are present defeat the technique unless alias expansion and semantic analysis of the commands is taken up. The method also does not analyze the running of a program, only the keystrokes. This means that a malicious program cannot be flagged for intrusive activities. Operating systems do not offer much support for keystroke capturing, so the keystroke monitor should have a hook that analyses keystrokes before sending them on to their intended receiver. An improvement to this would be to monitor system calls by application programs as well, so that an analysis of the program's execution is possible. Model Based Intrusion Detection states that certain scenarios are inferred by certain other observable activities. If these activities are monitored, it is possible to find intrusion attempts by looking at activities that infer a certain intrusion scenario. The model based scheme consists of three important modules[4]. The anticipator uses the active models and the scenario models to try to predict the next step in the scenario that is expected to occur. A scenario model is a knowledge base with specifications of intrusion scenarios. The planner then translates this hypothesis into a format that shows the behavior as it would occur in the audit trail. It uses the predicted information to plan what to search for next. The interpreter then searches for this data in the audit trail. The system proceeds this way, accumulating more and more evidence for an intrusion attempt until a threshold is crossed; at this point, it signals an intrusion attempt. This is a very clean approach. Because the planner and the interpreter know what they are searching for at each step, the large amounts of noise present in audit data can be filtered, leading to excellent performance improvements. In addition, the system can predict the attacker's next move based on the intrusion model. These predictions can be used to verify an intrusion hypothesis, to take preventive measures, or to determine what data to look for next. However, there are some critical issues related to this system. First, patterns for intrusion scenarios must be easily recognized. Second, patterns must always occur in the behavior being looked for. And finally, patterns must be distinguishing; they must not be associated with any other normal behavior. In the State Transition Analysis technique, the monitored system is represented as a state transition diagram. As data is analyzed, the system makes transitions from one state to another. A transition takes place on some Boolean condition being true (for example, the user opening a file). The approach followed in USTAT [5] is to have state transitions from safe to unsafe states based on known attack patterns. To make this model clearer, we illustrate with an example based almost entirely on an example in Ilgun's thesis. 1. The attacker creates a link starting with "-" (say -x) to root's setuid shell script containing the #!/bin/sh mechanism. 2. The attacker executes -x. The point of this attack is that whenever a hard link to a file is created, a new inode with the target's original permissions is created. Since invoking a script with the #!/bin/sh mechanism ianvokes a subshell, and further, if the name of the subshell begins with a dash an interactive shell is created, we see that the attacker has obtained an interactive shell with root privileges. The state diagram for this is shown in Figure 3. We see that for the final compromised state to be reached, some conditions have to be fulfilled. If these guard conditions are true, then there is almost certainly an intrusion attempt going on. However, if any of these conditions do not hold, the probability of an intrusive action is considerably decreased. We see that the guard conditions exist to filter the intrusive activities from the non-intrusive ones. Hence, this can serve as a data pruning mechanism as observed in the model based scheme above. Some advantages of this approach are: it can detect co-operative attacks, it can detect attacks that span across multiple user sessions, and it can foresee impending compromise situations based on the present system state and take pre-emptive measures. However there are also a few problems with state transition systems. First, attack patterns can specify only a sequence of events, rather than more complex forms. Second, there are no general purpose methods to prune the search except through the assertion primitives described above. And finally, they cannot detect denial of service attacks, failed logins, variations from normal usage, and passive listening -- this is because these items are either not recorded by the audit trail mechanism, or they cannot be represented by state transition diagrams. A small point to be noted is that USTAT was never meant to be a stand-alone intrusion detection system; indeed, it is meant to be used with an anomaly detector so that more intrusion attempts may be detected by their combination. Some of the weaknesses of state transition systems are remedied by the Pattern Matching Model, discussed next. Kumar [6] proposed a new misuse detection system based on Pattern Matching. This model encodes known intrusion signatures as patterns that are then matched against the audit data. Like the state transition analysis model, this model attempts to match incoming events to the patterns representing intrusion scenarios. The implementation makes transitions on certain events, called labels, and Boolean variables called guards can be placed at each transition. The difference between this and the state transition model is that the state transition model associates these guards with states, rather than transitions. The important advantages of this model are: 1. Declarative Specification : It only needs to be specified what patterns need to be matched, not how to match them. 2. Multiple event streams can be used together to match against patterns for each stream without the need to combine streams. This means that streams can be processed independently, and their results can be analyzed together to give evidence of intrusive activity. 3. Portability : Since intrusion signatures are written in a system independent script, they need not be rewritten for different audit trails. The patterns' declarative specifications enable them to be exchanged across different Operating Systems and different audit trails. 4. It has excellent real-time capabilities. Kumar reports a CPU overhead of 5-6% when scanning for 100 different patterns, which is excellent. 5. It can detect some attack signatures like the failed logins signature that the state transition model cannot do. One problem with this model it it can only detect attacks based on known vulnerabilities (a problem with misuse detection systems in general) In addition, pattern matching is not very useful for representing illdefined patterns and it is not an easy task to translate known attack scenarios into patterns that can be used by the model. Also, it cannot detect passive wire-tapping intrusions, nor can in detect spoofing attacks where a machine pretends to be another machine by using its IP address. An interesting fact about Kumar's IDS is that it is called IDIOT (Intrusion Detection In Our Time), and we leave it to the reader to ponder the appropriateness of the name for the state of the art in intrusion detection. 6 Other Models and Directions in Research Dorothy Denning [3] introduced a Generic Intrusion Detection Model that was independent of any particular system, application environment, system vulnerability, or type of intrusion. The basic idea of the model is to maintain a set of profiles for subjects (usually, but not necessarily users of a system). When an audit record is generated, the model matches it with the appropriate profile and then makes decisions on updating the profile, checking for abnormal behavior and reporting anomalies detected. To do this, it monitors system services such as file accesses, executable programs, and logins. It has no specific knowledge of the target system's vulnerabilities, although this knowledge would be extremely useful in making the model more valuable. In fact, the Intrusion Detection Expert System (IDES) developed at SRI was based on this model. The basic ideas in this model appear with little modification in many systems built. However, there are some systems that do not fit easily into this model. NSM (Network Security Monitor) is an intrusion detection system developed at the University of California-Davis. NSM is a network-based IDS that differs from all of the IDSs discussed earlier because it does not use or analyze the host machine(s) audit trails. Rather, it monitors network traffic in order to detect intrusions [9]. Since network based attacks are expected to be prevalent in the future due to the mushrooming of the Internet, NSM could prove to be a valuable tool to detect intrusive activity. NSM has several perceived advantages. First, the IDS gets instantaneous access to network data. Second, the IDS is hidden from the intruder because it is passively listening to network traffic. Therefore, it cannot be shut off or its data compromised. Finally, the IDS can be used with any system, because it is monitoring network traffic, protocols for which (TCP, UDP etc.) are standardized. There is no problem with different audit files, for example. Researchers at Purdue University are working on several issues in intrusion detection. Crosbie and Spafford [2] propose to build an IDS using Autonomous Agents. Instead of a single large IDS defending the system, they propose an approach where several independent, small processes operate while co-operating in maintaining the system. The advantages claimed for this approach are efficiency, fault tolerance, resilience to degradation, extensibility and scalability. The foreseen drawbacks include the overhead of so many processes, long training times, and the fact that if the system is subverted, it becomes a security liability. An interesting possibility they open up is that of an active defense, that can respond to intrusions actively instead of passively reporting them (it could kill suspicious connections, for example). Conclusion Intrusion Detection is still a fledgling field of research. However, it is beginning to assume enormous importance in today's computing environment. The combination of facts such as the unbridled growth of the Internet, the vast financial possibilities opening up in electronic trade, and the lack of truly secure systems make it an important and pertinent field of research. Future research trends seem to be converging towards a model that is a hybrid of the anomaly and misuse detection models; it is slowly acknowledged that neither of the models can detect all intrusion attempts on their own. This approach has been successfully adopted in NIDES, and we can expect more such attempts in the future. Some schools doing research in this field include The COAST group at Purdue University, The University of California-Davis, and The University of California-Santa Barbara. The interested reader is encouraged to browse the provided links for more information. References 1. J.P Anderson. Computer Security Threat Monitoring and Surveillance. Technical report, James P Anderson Co., Fort Washington, Pennsylvania, April 1980. 2. Mark Crosbie and Eugene Spafford. Defending a Computer System Using Autonomous Agents. Technical Report CSD-TR-95-022, Department of Computer Sciences, Purdue University, 1995. 3. Dorothy E Denning. An Intrusion Detection Model. In IEEE Transactions on Software Engineering, Number 2, page 222, February 1987. 4. T D Garvey and Teresa F Lunt. Model based intrusion detection. In Proceedings of the 14th National Computer Security Conference, pages 372-385, October 1991. 5. Koral Ilgun. USTAT - A Real-time Intrusion Detection System for UNIX. Master's Thesis, University of California at Santa Barbara, November 1992. 6. Sandeep Kumar. Classification and Detection of Computer Intrusions. Ph.D. Dissertation, August 1995. 7. Teresa F Lunt. Detecting Intruders in Computer Systems. Conference on Auditing and Computer Technology, 1993. 8. Teresa F Lunt. A survey of intrusion detection techniques. In Computers and Security, 12(1993), pages 405-418. 9. Biswanath Mukherjee, L Todd Heberlein and Karl N Levitt. Network Intrusion Detection, IEEE Network, May/June 1994, pages 26-41. 10. Barton P Miller, David Koski, Cjin Pheow Lee, Vivekananda Maganty, Ravi Murthy, Ajitkumar Natarajan, Jeff Steidl. Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services. Computer Sciences Department, University of Wisconsin, 1995. 11. Steven E Smaha. Haystack: An Intrusion Detection System. In Fourth Aerospace Computer Security Applications Conference, pages 37-44, Tracor Applied Science Inc., Austin, Texas, December 1988. 12. Eugene H Spafford. The Internet Worm Program: An Analysis. In ACM Computer Communication Review; 19(1), pages 17-57, Jan 1989. 13. Eugene H Spafford. Security Seminar, Department of Computer Sciences, Purdue University, Jan 1996. 14. Henry S Teng, Kaihu Chen and Stephen C Lu. Security Audit Trail Analysis Using Inductively Generated Predictive Rules. In Proceedings of the 11th National Conference on Artificial Intelligence Applications, pages 24-29, IEEE, IEEE Service Center, Piscataway, NJ, March 1990. FAQ: Network Intrusion Detection Systems 0. Information about this FAQ 0.1 Copyright Copyright 1998-2000 by Robert Graham (mailto:[email protected]. All rights reserved. This document may be reproduced only for non-commercial purposes. All reproductions must contain this exact copyright notice. Reproductions must not contain alterations except by permision. 0.6 Where to get it My homepage: (slow link) http://www.robertgraham.com/pubs/network-intrusion-detection.html (HTML) http://www.robertgraham.com/pubs/network-intrusion-detection.txt (text) TICM (fast link)http://www.ticm.com/kb/faq/ Shake Communications (Australia)http://www.shake.net/misc/network-intrusion-detection.htm IT Sec (Germany)http://www.it-sec.de/mirrors/ids/network-intrusion-detection.html Russian translation: http://www.citforum.ru/internet/securities/faq_ids.shtml Japanese translation: http://www.sfc.keio.ac.jp/~keiji/ids/ids-faq-j.html 0.7 Thanks to Thanks to the following people for helpful info and comments (note: to avoid automated spam address collection systems, I've munged their e-mail addresses in an obvious way). Olaf Schreck <chakl at syscall de> John Kozubik <john_kozubik at hotmail com> (see http://www.networkcommand.com/john/index.html for NT login-script tips). Aaron Bawcom <abawcom at pacbell net> Mike Kienenberger <mkienenb at arsc edu> Keiji Takeda <keiji at sfc keio ac jp> Scott Hamilton <sah at uow edu au> Holger Heimann <hh at it-sec de> 1. Introduction 1.1 What is a "network intrusion detection system (NIDS)"? An intrusion is somebody (A.K.A. "hacker" or "cracker") attempting to break into or misuse your system. The word "misuse" is broad, and can reflect something severe as stealing confidential data to something minor such as misusing your email system for spam (though for many of us, that is a major issue!). An "Intrusion Detection System (IDS)" is a system for detecting such intrusions. For the purposes of this FAQ, IDS can be broken down into the following categories: network intrusion detection systems (NIDS) monitors packets on the network wire and attempts to discover if a hacker/cracker is attempting to break into a system (or cause a denial of service attack). A typical example is a system that watches for large number of TCP connection requests (SYN) to many different ports on a target machine, thus discovering if someone is attempting a TCP port scan. A NIDS may run either on the target machine who watches its own traffic (usually integrated with the stack and services themselves), or on an independent machine promiscuously watching all network traffic (hub, router, probe). Note that a "network" IDS monitors many machines, whereas the others monitor only a single machine (the one they are installed on). system integrity verifiers (SIV) monitors system files to find when a intruder changes them (thereby leaving behind a backdoor). The most famous of such systems is "Tripwire". A SIV may watch other components as well, such as the Windows registry and chron configuration, in order to find well known signatures. It may also detect when a normal user somehow acquires root/administrator level privleges. Many existing products in this area should be considered more "tools" than complete "systems": i.e. something like "Tripwire" detects changes in critical system components, but doesn't generate real-time alerts upon an intrusion. log file monitors (LFM) monitor log files generated by network services. In a similar manner to NIDS, these systems look for patterns in the log files that suggest an intruder is attacking. A typical example would be a parser for HTTP server log files that looking for intruders who try well-known security holes, such as the "phf" attack. Example: swatch deception systems (A.K.A. decoys, lures, fly-traps, honeypots) which contain pseudo-services whose goal is to emulate well-known holes in order to trap hackers. See The Deception ToolKit http://www.all.net/dtk/ for an example. Also, simple tricks by renaming "administrator" account on NT, then setting up a dummy account with no rights by extensive auditing can be used. There is more on "deception" later in this document. Also see http://www.enteract.com/~lspitz/honeypot.html other For more info, see http://www.icsa.net/idswhite/. 1.2 Who is misusing the system? There are two words to describe the intruder: hacker and cracker. A hacker is a generic term for a person who likes getting into things. The benign hacker is the person who likes to get into his/her own computer and understand how it works. The malicious hacker is the person who likes getting into other people's systems. The benign hackers wish that the media would stop bad-mouthing all hackers and use the term 'cracker' instead. Unfortunately, this is not likely to happen. In any event, the word used in this FAQ is 'intruder', to generically denote anybody trying to get into your systems. Intruders can be classified into two categories. Outsiders Intruders from outside your network, and who may attack you external presence (deface web servers, forward spam through e-mail servers, etc.). They may also attempt to go around the firewall to attack machines on the internal network. Outside intruders may come from the Internet, dial-up lines, physical break-ins, or from partner (vendor, customer, reseller, etc.) network that is linked to your corporate network. Insiders Intruders that legitimately use your internal network. These include users who misuse priviledges (such as the Social Security employee who marked someone as being dead because they didn't like that person) or who impersonate higher privileged users (such as using someone else's terminal). A frequently quoted statistic is that 80% of security breaches are committed by insiders. There are several types of intruders Joy riders hack because they can. Vandals are intent on causing destruction or marking up your web-pages. Profiteers are intent on profiting from their enterprise, such as rigging the system to give them money or by stealing corporate data and selling it. 1.3 How do intruders get into systems? The primary ways a intruder can get into a system: Physical Intrusion If a intruders have physical access to a machine (i.e. they can use the keyboard or take apart the system), they will be able to get in. Techniques range from special privileges the console has, to the ability to physically take apart the system and remove the disk drive (and read/write it on another machine). Even BIOS protection is easy to bypass: virtually all BIOSes have backdoor passwords. System Intrusion This type of hacking assumes the intruder already has a low-privilege user account on the system. If the system doesn't have the latest security patches, there is a good chance the intruder will be able to use a known exploit in order to gain additional administrative privileges. Remote Intrusion This type of hacking involves a intruder who attempts to penetrate a system remotely across the network. The intruder begins with no special privileges. There are several forms of this hacking. For example, a intruder has a much more difficult time if there exists a firewall on between him/her and the victim machine. Note that Network Intrusion Detection Systems are primarily concerned with Remote Intrusion. 1.4 Why can intruders get into systems? Software always has bugs. System Administrators and Programmers can never track down and eliminate all possible holes. Intruders have only to find one hole to break in. 1.4.1 Software bugs Software bugs are exploited in the server daemons, the client applications, the operating system, and the network stack. Software bugs can be classified in the following manner: Buffer overflows: Almost all the security holes you read about in the press are due to this problem. A typical example is a programmer who sets aside 256 characters to hold a login username. Surely, the programmer thinks, nobody will ever have a name longer than that. But a hacker thinks, what happens if I enter in a false username longer than that? Where do the additional characters go? If they hackers do the job just right, they can send 300 characters, including code that will be executed by the server, and voila, they've broken in. Hackers find these bugs in several ways. First of all, the source code for a lot of services is available on the net. Hackers routinely look through this code searching for programs that have buffer overflow problems. Secondly, hackers may look at the programs themselves to see if such a problem exists, though reading assembly output is really difficult. Thirdly, hackers will examine every place the program has input and try to overflow it with random data. If the program crashes, there is a good chance that carefully constructed input will allow the hacker to break in. Note that this problem is common in programs written in C/C++, but rare in programs written in Java. Unexpected combinations: Programs are usually constructed using many layers of code, including the underlying operating system as the bottom most layer. Intruders can often send input that is meaningless to one layer, but meaningful to another layer. The most common language for processing user input on the web is PERL. Programs written in PERL will usually send this input to other programs for further evaluation. A common hacking technique would be to enter something like "| mail < /etc/passwd". This gets executed because PERL asks the operating system to launch an additional program with that input. However, the operating system intercepts the pipe '|' character and launches the 'mail' program as well, which causes the password file to be emailed to the intruder. Unhandled input: Most programs are written to handle valid input. Most programmers do not consider what happens when somebody enters input that doesn't match the specification. Race conditions: Most systems today are "multitasking/multithreaded". This means that they can execute more than one program at a time. There is a danger if two programs need to access the same data at the same time. Imagine two programs, A and B, who need to modify the same file. In order to modify a file, each program must first read the file into memory, change the contents in memory, then copy the memory back out into the file. The race condition occurs when program A reads the file into memory, then makes the change. However, before A gets to write the file, program B steps in and does the full read/modify/write on the file. Now program A writes its copy back out to the file. Since program A started with a copy before B made its changes, all of B's changes will be lost. Since you need to get the sequence of events in just the right order, race conditions are very rare. Intruders usually have to tries thousands of time before they get it right, and hack into the system. 1.4.2 System configuration System configuration bugs can be classified in the following manner: Default configurations: Most systems are shipped to customers with default, easy-to-use configurations. Unfortunately, "easy-to-use" means "easy-to-break-in". Almost any UNIX or WinNT machine shipped to you can be hacked in easily. Lazy administrators: A surprising number of machines are configured with an empty root/administrator password. This is because the administrator is too lazy to configure one right now and wants to get the machine up and running quickly with minimal fuss. Unfortunately, they never get around to fixing the password later, allowing intruders easy access. One of the first things a intruder will do on a network is to scan all machines for empty passwords. Hole creation: Virtually all programs can be configured to run in a non-secure mode. Sometimes administrators will inadvertently open a hole on a machine. Most administration guides will suggest that administrators turn off everything that doesn't absolutely positively need to run on a machine in order to avoid accidental holes. Note that security auditing packages can usually find these holes and notify the administrator. Trust relationships: Intruders often "island hop" through the network exploiting trust relationships. A network of machines trusting each other is only as secure as its weakest link. 1.4.3 Password cracking This is a special category all to itself. Really weak passwords: Most people use the names of themselves, their children, spouse/SO, pet, or car model as their password. Then there are the users who choose "password" or simply nothing. This gives a list of less than 30 possibilities that a intruder can type in for themselves. Dictionary attacks: Failing the above attack, the intruder can next try a "dictionary attack". In this attack, the intruder will use a program that will try every possible word in the dictionary. Dictionary attacks can be done either by repeatedly logging into systems, or by collecting encrypted passwords and attempting to find a match by similarly encrypting all the passwords in the dictionary. Intruders usually have a copy of the English dictionary as well as foreign language dictionaries for this purpose. They all use additional dictionary-like databases, such as names (see above) and lists of common passwords. Brute force attacks: Similar to a Dictionary attack, a intruder may try all possible combinations of characters. A short 4-letter password consisting of lower-case letters can be cracked in just a few minutes (roughly, half a million possible combinations). A long 7-character password consisting of upper and lower case, as well as numbers and punctuation (10 trillion combinations) can take months to crack assuming you can try a million combinations a second (in practice, a thousand combinations per second is more likely for a single machine). 1.4.4 Sniffing unsecured traffic Shared medium: On traditional Ethernet, all you have to do is put a Sniffer on the wire to see all the traffic on a segment. This is getting more difficult now that most corporations are transitioning to switched Ethernet. Server sniffing: However, on switched networks, if you can install a sniffing program on a server (especially one acting as a router), you can probably use that information to break into client machines and trusted machines as well. For example, you might not know a user's password, but sniffing a Telnet session when they log in will give you that password. Remote sniffing: A large number of boxes come with RMON enabled and public community strings. While the bandwidth is really low (you can't sniff all the traffic), it presents interesting possibilities. 1.4.5 Design flaws Even if a software implementation is completely correct according to the design, there still may be bugs in the design itself that leads to intrusions. TCP/IP protocol flaws: The TCP/IP protocool was designed before we had much experience with the wide-scale hacking we see today. As a result, there are a number of design flaws that lead to possible security problems. Some examples include smurf attacks, ICMP Unreachable disconnects, IP spoofing, and SYN floods. The biggest problem is that the IP protocol itself is very "trusting": hackers are free to forge and change IP data with impunity. IPsec (IP security) has been designed to overcome many of these flaws, but it is not yet widely used. UNIX design flaws: There are number of inherent flaws in the UNIX operating system that frequently lead to intrusions. The chief problem is the access control system, where only 'root' is granted administrative rights. As a result, 1.5 How do intruders get passwords? Intruders get passwords in the following ways: Clear-text sniffing: A number of protocols (Telnet, FTP, HTTP Basic) use clear-text passwords, meaning that they are not encrypted as the go over the wire between the client and the server. A intruder with a protocol analyzer can watch the wire looking for such passwords. No further effort is needed; the intruder can start immediately using those passwords to log in. Encrypted sniffing: Most protocols, however, use some sort of encryption on the passwords. In these cases, the intruder will need to carry out a Dictionary or Brute Force attack on the password in order to attempt decryption. Note that you still don't know about the intruder's presence, as he/she has been completely passive and has not transmitted anything on the wire. Password cracking does not require anything to be sent on the wire as intruder's own machine is being used to authenticate your password. Replay attack: In some cases, intruders do not need to decrypt the password. They can use the encrypted form instead in order to login to systems. This usually requires reprogramming their client software in order to make use of the encrypted password. Password file stealing: The entire user database is usually stored in a single file on the disk. In UNIX, this file is /etc/passwd (or some mirror of that file), and under WinNT, this is the SAM file. Either way, once a intruder gets hold of this file, he/she can run cracking programs (described above) in order to find some weak passwords within the file. Observation: One of the traditional problems in password security is that passwords must be long and difficult to guess (in order to make Dictionary and Brute Force cracks unreasonably difficult). However, such passwords are often difficult to remember, so users write them down somewhere. Intruders can often search a persons work site in order to find passwords written on little pieces of paper (usually under the keyboard). Intruders can also train themselves to watch typed in passwords behind a user's back. Social Engineering: A common (successful) technique is to simply call the user and say "Hi, this is Bob from MIS. We're trying to track down some problems on the network and they appear to be coming from your machine. What password are you using?" Many users will give up their password in this situation. (Most corporations have a policy where they tell users to never give out their password, even to their own MIS departments, but this technique is still successful. One easy way around this is for MIS to call the new employee 6-months have being hired and ask for their password, then criticize them for giving it to them in a manner they will not forget :-) 1.6 What is a typical intrusion scenario? A typical scenario might be: Step 1: outside reconnaissance The intruder will find out as much as possible without actually giving themselves away. They will do this by finding public information or appearing as a normal user. In this stage, you really can't detect them. The intruder will do a 'whois' lookup to find as much information as possible about your network as registered along with your Domain Name (such as foobar.com. The intruder might walk through your DNS tables (using 'nslookup', 'dig', or other utilities to do domain transfers) to find the names of your machines. The intruder will browse other public information, such as your public web sites and anonymous FTP sites. The intruder might search news articles and press releases about your company. Step 2: inside reconnaisance The intruder uses more invasive techniques to scan for information, but still doesn't do anything harmful. They might walk through all your web pages and look for CGI scripts (CGI scripts are often easily hacked). They might do a 'ping' sweep in order to see which machines are alive. They might do a UDP/TCP scan/strobe on target machines in order to see what services are available. They'll run utilities like 'rcpinfo', 'showmount', 'snmpwalk', etc. in order to see what's available. At this point, the intruder has done 'normal' activity on the network and has not done anything that can be classified as an intrusion. At this point, a NIDS will be able to tell you that "somebody is checking door handles", but nobody has actually tried to open a door yet. Step 3: exploit The intruder crosses the line and starts exploiting possible holes in the target machines. The intruder may attempt to compromise a CGI script by sending shell commands in input fields. The intruder might attempt to exploit well-known buffer-overrun holes by sending large amounts of data. The intruder may start checking for login accounts with easily guessable (or empty) passwords. The hacker may go through several stages of exploits. For example, if the hacker was able to access a user account, they will now attempt further exploits in order to get root/admin access. Step 4: foot hold At this stage, the hacker has successfully gained a foot hold in your network by hacking into a machine. The intruder's main goal is to hide evidence of the attacks (doctoring the audit trail and log files) and make sure they can get back in again. They may install 'toolkits' that give them access, replace existing services with their own Trojan horses that have backdoor passwords, or create their own user accounts. System Integrity Verifiers (SIVs) can often detect an intruder at this point by noting the changed system files. The hacker will then use the system as a stepping stone to other systems, since most networks have fewer defenses from inside attacks. Step 5: profit The intruder takes advantage of their status to steal confidential data, misuse system resources (i.e. stage attacks at other sites from your site), or deface web pages. Another scenario starts differently. Rather than attack a specific site, and intruder might simply scan random internet addresses looking for a specific hole. For example, an intruder may attempt to scan the entire Internet for machines that have the SendMail DEBUG hole. They simply exploit such machines that they find. They don't target you directly, and they really won't even know who you are. (This is known as a 'birthday attack'; given a list of well-known security holes and a list of IP addresses, there is a good chance that there exists some machine somewhere that has one of those holes). 1.7 What are some common "intrusion signatures"? There are three types of attacks: reconnaisance These include ping sweeps, DNS zone transfers, e-mail recons, TCP or UDP port scans, and possibly indexing of public web servers to find cgi holes. exploits Intruders will take advantage of hidden features or bugs to gain access to the system. denial-of-service (DoS) attacks Where the intruder attempts to crash a service (or the machine), overload network links, overloaded the CPU, or fill up the disk. The intruder is not trying to gain information, but to simply act as a vandal to prevent you from making use of your machine. 1.8 What are some common exploits? 1.8.1 CGI scripts CGI programs are notoriously insecure. Typical security holes include passing tainted input directly to the command shell via the use of shell metacharacters, using hidden variables specifying any filename on the system, and otherwise revealing more about the system than is good. The most well-known CGI bug is the 'phf' library shipped with NCSA httpd. The 'phf' library is supposed to allow server-parsed HTML, but can be exploited to give back any file. Other well-known CGI scripts that an intruder might attempt to exploit are: TextCounter, GuestBook, EWS, info2www, Count.cgi, handler, webdist.cgi, php.cgi, files.pl, nph-test-cgi, nph-publish, AnyForm, FormMail. If you see somebody trying to access one or all of these CGI scripts (and you don't use them), then it is clear indication of an intrusion attempt (assuming you don't have a version installed that you actually want to use). 1.8.2 Web server attacks Beyond the execution of CGI programs, web servers have other possible holes. A large number of selfwritten web servers (include IIS 1.0 and NetWare 2.x) have hole whereby a file name can include a series of "../" in the path name to move elsewhere in the file system, getting any file. Another common bug is buffer overflow in the request field or in one of the other HTTP fields. Web server often have bugs related to their interaction with the underlying operating system. An old hole in Microsoft IIS have been dealing with the fact that files have two names, a long filename and a short 8.3 hashed equivalent that could sometimes be accessed bypassing permissions. NTFS (the new file system) has a feature called "alternate data streams" that is similar to the Macintosh data and resource forks. You could access the file through its stream name by appending "::$DATA" in order to see a script rather than run it. Servers have long had problems with URLs. For example, the "death by a thousand slashes" problem in older Apache would cause huge CPU loads as it tried to process each directory in a thousand slash URL. 1.8.3 Web browser attacks It seems that all of Microsoft's and Netscape's web browsers have security holes (though, of course, the latest ones never have any that we know about -- yet). This includes both URL, HTTP, HTML, JavaScript, Frames, Java, and ActiveX attacks. URL fields can cause a buffer overflow condition, either as it is parsed in the HTTP header, as it is displayed on the screen, or processed in some form (such as saved in the cache history). Also, an old bug with Internet Explorer allowed interaction with a bug whereby the browser would execute .LNK or .URL commands. HTTP headers can be used to exploit bugs because some fields are passed to functions that expect only certain information. HTML can be often exploited, such as the MIME-type overflow in Netscape Communicator's <EMBED> command. JavaScript is a perennial favorite, and usually tries to exploit the "file upload" function by generating a filename and automatically hidden the "SUBMIT" button. There have been many variations of this bug fixed, then new ways found to circumvent the fixes. Frames are often used as part of a JavaScript or Java hack (for example, hiding web-pages in 1px by 1px sized screens), but they present special problems. For example, I can include a link to a trustworthy site that uses frames, then replace some of those frames with web pages from my own site, and they will appear to you to be part of that remote site. Java has a robust security model, but that model has proven to have the occasional bug (though compared to everything else, it has proven to be one of the most secure elements of the whole system). Moreover, its robust security may be its undoing: Normal Java applets have no access to the local system, but sometimes they would be more useful if they did have local access. Thus, the implementation of "trust" models that can more easily be hacked. ActiveX is even more dangerous than Java as it works purely from a trust model and runs native code. You can even inadvertently catch a virus that was accidentally imbedded in some vendor's code. 1.8.4 SMTP (SendMail) attacks SendMail is an extremely complicated and widely used program, and as a consequence, has been the frequent source of security holes. In the old days (of the '88 Morris Worm), hackers would take advantage of a hole in the DEBUG command or the hidden WIZ feature to break into SMTP. These days, they often try buffer overruns. SMTP also can be exploited in reconnaissance attacks, such as using the VRFY command to find user names. 1.8.5 Access Failed login attempts, failed file access attempts, password cracking, administrative powers abuse 1.8.6 IMAP Users retrieve e-mail from servers via the IMAP protocol (in contrast, SMTP transfers e-mail between servers). Hackers have found a number of bugs in several popular IMAP servers. 1.8.7 IP spoofing There is a range of attacks that take advantage of the ability to forge (or 'spoof') your IP address. While a source address is sent along with every IP packet, it isn't actually used for routing. This means an intruder can pretend to be you when talking to a server. The intruder never sees the response packets (although your machine does, but throws them away because they don't match any requests you've sent). The intruder won't get data back this way, but can still send commands to the server pretending to be you. IP spoofing is frequently used as part of other attacks: SMURF Where the source address of a broadcast ping is forged so that a huge number of machines respond back to victim indicated by the address, overloading it (or its link). TCP sequence number prediction In the startup of a TCP connection, you must choose a sequence number for your end, and the server must choose a sequence number for its end. Older TCP stacks choose predictable sequence numbers, allowing intruders to create TCP connections from a forged IP address (for which they will never see the response packets) that presumably will bypass security. DNS poisoning through sequence prediction DNS servers will "recursively" resolve DNS names. Thus, the DNS server that satisfies a client request will become itself a client to the next server in the recursive chain. The sequence numbers it uses are predictable. Thus, an intruder can send a request to the DNS server and a response to the server forged to be from the next server in the chain. It will then believe the forged response, and use that to satisfy other clients. 1.8.8 Buffer Overflows Some other buffer overflow attacks are: DNS overflow Where an overly long DNS name is sent to a server. DNS names are limited to 64-bytes per subcomponent and 256-bytes overall. statd overflow where an overly long filename is provided 1.8.9 DNS attacks DNS is a prime target because if you can corrupt the DNS server, you can take advantage of trust relationships. DNS cache poisoning Every DNS packet contains a "Question" section and "Answer" section. Vulnerable servers will believe (and cache) Answers that you send along with Questions. Most, but not all, DNS servers have been patched as of November, 1998. DNS poisoning through sequence prediction See above DNS overflow See above 1.9 What are some common reconnaisance scans? 1.9.1 Ping sweeps This simple scan simply pings a range of IP addresses to find which machines are alive. Note that more sophisticated scanners will use other protocols (such as an SNMP sweep) to do the same thing. 1.9.2 TCP scans Probes for open (listening) TCP ports looking for services the intruder can exploit. Scans can use normal TCP connections or stealth scans that use half-open connections (to prevent them from being logged) or FIN scans (never opens a port, but tests if someone's listening). Scans can be either sequential, randomized, or configured lists of ports. 1.9.3 UDP scans These scans are a little bit more difficult because UDP is a connectionless protocol. The technique is to send a garbage UDP packet to the desired port. Most machines will respond with an ICMP "destination port unreachable" message, indicating that no service is listening at that port. However, many machines throttle ICMP messages, so you can't do this very fast. 1.9.4 OS identification By sending illegal (or strange) ICMP or TCP packets, an intruder can identify the operating system. Standards usually state how machines should respond to legal packets, so machines tend to be uniform in their response to valid input. However, standards omit (usually intentionally) the response to invalid input. Thus, each operating system's unique responses to invalid inputs forms a signature that hackers can use to figure out what the target machine is. This type of activity occurs at a low level (like stealth TCP scans) that systems do not log. 1.9.5 Account scans Tries to log on with accounts Accounts with no passwords Accounts with password same as username, or "password". Default accounts that were shipped with the product (a common problem on SGI, done to make setup easier) Accounts installed with software products (common on Microsoft as well as Unix, caused by products that run under their own special user account). Anonymous FTP problems (CWD ~root) Scan for rlogin/rsh/rexec ports, that may supported trusted logins. 1.10 What are some common DoS (Denial of Service) attacks? 1.10.1 Ping-of-Death Sends an invalid fragment, which starts before the end of packet, but extends past the end of the packet. 1.10.2 SYN Flood Sends TCP SYN packet (which start connections) very fast, leaving the victim waiting to complete a huge number of connections, causing it to run out of resources and dropping legitimate connections. A new defense against this are "SYN cookies". Each side of a connection has its own sequence-number. In response to a SYN, the attacked machine creates a special sequence number that is a "cookie" of the connection then forgets everything it knows about the connection. It can then recreate the forgotten information about the connection when the next packets come in from a legitimate connection. 1.10.3 Land/Latierra Sends forged SYN packet with identical source/destination address/port so that system goes into infinite loop trying to complete the TCP connection. 1.10.4 WinNuke Sends OOB/URG data on a TCP connection to port 139 (NetBIOS Session/SMB), which cause the Windows system to hang. 1.11 How much danger from intrusions is there? I frequently hear from people the statement "There's nothing on the system that anybody would want anyway". I walk them through various scenarios, such as simple ones if they've ever paid for anything on-line with a credit card or if they have any financial records or social security number on their personal machine. More importantly, there is the issue of legal liability. You are potentially liable for damages caused by a hacker using your machine. You must be able to prove to a court that you took "reasonable" measures to defend yourself from hackers. For example, consider if you put a machine on a fast link (cable modem or DSL) and left administrator/root accounts open with no password. Then if a hacker breaks into that machine, then uses that machine to break into a bank, you may be held liable because you did not take the most obvious measures in securing the machine. There is a good paper http://www.cert.org/research/JHThesis/Start.html by John D. Howard that discusses how much hacking goes on over the Internet, and how much danger you are in. 1.12 Where can I find current statistics about intrusions? CyberNotes by NIPC (http://www.fbi.gov/nipc/welcom.htm) CyberNotes is published every two weeks by the National Infrastructure Protection Center (NIPC). Its mission is to support security and information system professionals with timely information on cyber vulnerabilities, hacker exploit scripts, hacker trends, virus information, and other critical infrastructurerelated best practices. The NIPC was set up by the FBI in mid 1998, and its first major activity was to help track down the source of the Melissa virus (W97M.Melissa). The CyberNotes archive goes back to January 1999. AusCERT Consolidated Statistics Project (http://www.auscert.org.au/Information/acsp/index.html) A project to collect intrusion statistics from around the web and consolidate them. They want people to join and send them info. An Analysis Of Security Incidents On The Internet 1989 - 1995 (http://www.cert.org/research/JHThesis/Start.html) A dissertation by John D. Howard, Carnegie Mellon University CERT Reports, Articles, and Presentations (http://www.cert.org/nav/reports.html) CERT has a number of historical statistics on intrusions, but they aren't nearly as up-to-date as the NIPC. 1999 CSI-DBI Survey (http://www.gocsi.com/summary.htm) or (http://www.gocsi.com/prelea990301.htm CSI (Computer Security Institute) does a number of surveys about intrusions and security 2. Architecture 2.1 How are intrusions detected? 2.1.1 Anomaly detection The most common way people approach network intrusion detection is to detect statistical anomalies. The idea behind this approach is to measure a "baseline" of such stats as CPU utilization, disk activity, user logins, file activity, and so forth. Then, the system can trigger when there is a deviation from this baseline. The benefit of this approach is that it can detect the anomalies without having to understand the underlying cause behind the anomalies. For example, let's say that you monitor the traffic from individual workstations. Then, the system notes that at 2am, a lot of these workstations start logging into the servers and carrying out tasks. This is something interesting to note and possibly take action on. 2.1.2 Signature recognition The majority of commercial products are based upon examining the traffic looking for well-known patterns of attack. This means that for every hacker technique, the engineers code something into the system for that technique. This can be as simple as a pattern match. The classic example is to example every packet on the wire for the pattern "/cgi-bin/phf?", which might indicate somebody attempting to access this vulnerable CGI script on a web-server. Some IDS systems are built from large databases that contain hundreds (or thousands) of such strings. They just plug into the wire and trigger on every packet they see that contains one of these strings. 2.2 How does a NIDS match signatures with incoming traffic? Traffic consists of IP datagrams flowing across a network. A NIDS is able to capture those packets as they flow by on the wire. A NIDS consists of a special TCP/IP stack that reassembles IP datagrams and TCP streams. It then applies some of the following techniques: Protocol stack verification A number of intrusions, such as "Ping-O-Death" and "TCP Stealth Scanning" use violations of the underlying IP, TCP, UDP, and ICMP protocols in order to attack the machine. A simple verification system can flag invalid packets. This can include valid, by suspicious, behavior such as severally fragmented IP packets. Application protocol verification A number of intrusions use invalid protocol behavior, such as "WinNuke", which uses invalid NetBIOS protocol (adding OOB data) or DNS cache poisoning, which has a valid, but unusually signature. In order to effectively detect these intrusions, a NIDS must reimplement a wide variety of application-layer protocols in order to detect suspicious or invalid behavior. Creating new loggable events A NIDS can be used to extend the auditing capabilities of your network management software. For example, a NIDS can simply log all the application layer protocols used on a machine. Downstream event log systems (WinNT Event, UNIX syslog, SNMP TRAPS, etc.) can then correlate these extended events with other events on the network. 2.4 What happens after a NIDS detects an attack? Reconfigure firewall Configure the firewall to filter out the IP address of the intruder. However, this still allows the intruder to attack from other addresses. Checkpoint firewall's support a "Suspicious Activity Monitoring Protocol (SAMP)" for configuring firewalls. Checkpoint has their "OPSEC" standard for re-configuring firewalls to block the offending IP address. chime Beep or play a .WAV file. For example, you might hear a recording "You are under attack". SNMP Trap Send an SNMP Trap datagram to a management console like HP OpenView, Tivoli, Cabletron Spectrum, etc. NT Event Send an event to the WinNT event log. syslog Send an event to the UNIX syslog event system. send e-mail Send e-mail to an administrator to notify of the attack. page Page (using normal pagers) the system administrator. Log the attack Save the attack information (timestamp, intruder IP address, victim IP address/port, protocol information). Save evidence Save a tracefile of the raw packets for later analysis. Launch program Launch a separate program to handle the event. Terminate the TCP session Forge a TCP FIN packet to force a connection to terminate. 2.5 What other countermeasures besides IDS are there? Firewalls Most people think of the firewall as their first line of defense. This means if intruders figure out how to bypass it (easy, especially since most intrusions are committed by employees inside the firewall), they will have free run of the network. A better approach is to think of it as the last line of defense: you should be pretty sure machines are configured right and intrusion detection is operating, and then place the firewall up just to avoid the wannabe script-kiddies. Note that almost any router these days can be configured with some firewall filtering. While firewalls protect external access, they leave the network unprotected from internal intrusions. It has been estimated that 80% of losses due to "hackers" have been internal attacks. authentication You should run scanners that automated the finding of open accounts. You should enforce automatically strict policies for passwords (7 character minimum, including numbers, dual-case, and punctuation) using crack or built in policy checkers (WinNT native, add-on for UNIX). You can also consider single-sign on products and integrating as many password systems as you can, such as RADIUS/TACACS integration with UNIX or NT (for dial-up style login), integrating UNIX and WinNT authentication (with existing tools are the new Kerberos in Windows 2000). These authentication systems will help you also remove "clear-text" passwords from protocols such as Telnet, FTP, IMAP, POP, etc. VPNs (Virtual Private Networks) VPNs create a secure connection over the Internet for remote access (e.g. for telecomuters). Example #1: Microsoft includes a a technology called PPTP (PPP over TCP) built into Windows. This gives a machine two IP addresses, one on the Internet, and a virtual one on the corporate network. Example #2: IPsec enhances the traditional IP protocol with security. While VPN vendors claim their product "enhance security", the reality is that they decrease corporate security. While the pipe itself is secure (authenticated, encrypted), either ends of the pipe are wide open. A home machine compromised with a backdoor rootkit allows a hacker to subvert the VPN connection, allow full, undetectable access to the other side of the firewall. encryption Encryption is becoming increasingly popular. You have your choice of e-mail encryption (PGP, SMIME), file encryption (PGP again), or file system encryption (BestCrypt, PGP again). lures/honeypots Programs that pretend to be a service, but which do not advertise themselves. It can be something as simple as one of the many BackOrifice emulators (such as NFR's Back Officer Friendly), or as complex as an entire subnet of bogus systems installed for that purpose. 2.6 Where do I put IDS systems on my network? network hosts Even though network intrusion detection systems have traditionally been used as probes, they can also be placed on hosts (in non-promiscuous mode). Take for example a switched network where an employee is on the same switch as the CEO, who runs Win98. The windows machine is completely defenseless, and has no logging capabilities that could be fed to a traditional host-based intrusion detection system. The employee could run a network-based password cracker for months without fear of being caught. A NIDS installed like virus scanning software is the most effective way to detect such intrusions. network perimeter IDS is most effective on the network perimeter, such as on both sides of the firewall, near the dial-up server, and on links to partner networks. These links tend to be low-bandwidth (T1 speeds) such that an IDS can keep up with the traffic. WAN backbone Another high-value point is the corporate WAN backbone. A frequent problem is hacking from "outlying" areas to the main corporate network. Since WAN links tend to be low bandwidth, IDS systems can keep up. server farms Serves are often placed on their own network, connected to switches. The problem these servers have, though, is that IDS systems cannot keep up with high-volume traffic. For extremely important servers, you may be able to install dedicate IDS systems that monitor just the individual server's link. Also, application servers tend to have lower traffic than file servers, so they are better targets for IDS systems. LAN backbones IDS systems are impractical for LAN backbones, because of their high traffic requirements. Some vendors are incorporating IDS detection into switches. A full IDS system that must reassemble packets is unlikely to keep up. A scaled-down system that detects simpler attacks but can keep up is likely to be a better choice. 2.7 How does IDS fit with the rest of my security framework? 1. 2. 3. 4. 5. 6. Put firewalls between areas of the network with different security requirements (i.e. between internet-localnet, between users-servers, between company-parterns, etc). Use network vulnerability scanners to double check firewalls and to find holes that intruders can exploit. Use host policy scanners to make sure they conform to accepted practices (i.e. latest patches). Use Network intrusion detection systems and other packet sniffing utilities to see what is actually going on. Use host-based intrusion detection systems and virus scanners to flag successful intrusions. Create an easy to follow policy that clearly states the response to intrusions. 2.8 How can I detect if someone is running a NIDS? A NIDS is essentially a sniffer, so therefore standard sniffer detection techniques can be used. Such techniques are explained in http://www.robertgraham.com/pubs/sniffing-faq.html#detect. An example would be to do a traceroute against the victim. This will often generate a low-level event in the IDS. Traceroutes are harmless and frequent on the net, so they don't indicate an attack. However, since many attacks are preceded by traceroutes, IDSs will log them anyway. As part of the logging system, it will usually do a reverse-DNS lookup. Therefore, if you run your own DNS server, then you can detect when somebody is doing a reverse-DNS lookup on your IP address in response to your traceroute. 3. Policy 3.1 How do I increase intrusion detection/prevention under WinNT? The following lists items that make WinNT more secure, including detection as well as prevention. These are roughly listed in order of importance. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Install the latest service packs and "hot fixes". These are listed at http://www.microsoft.com/security/. If you are using WinNT 4.0 and you don't have Service Pack #3 (SP3) installed, an intruder can break into your system. INSTALLATION: Use NTFS instead of FAT. NTFS allows permissions to be set on a perfile/per-directory basis. NTFS also allows auditing on a per-file/per-directory basis. Note that many people recommend using FAT as the boot drive and NTFS for all other drives (due to the ease-ofuse in using DOS to fix things on a FAT drive). However, using NTFS for all drives is definitely more secure. USRMGR: Rename the "administrator" account. A common attack is to use a Dictionary or brute force attack on the "administrator" account. Normal accounts can be configured to automatically (and temporarily) "lock out" after a few failed password attempts. However, this feature isn't possible for the administrator account because this allows a denial of service attack (i.e. prevent administration of the machine by locking out the administrator account). USRMGR: Create a new account named "administrator" for detecting intrusion attempts. USRMGR: Disable the "guest" account. You may also want to rename this account as (much like "administrator"). Once you've renamed the "guest" account, you may want to create a new account named "guest" for detecting hacking attempts. NTFS: Disable "write" access for "Everyone" on the %systemroot%/system32 directory. REGEDT32: Turn on auditing for "HKEY_LOCAL_MACHINE\Security" in order to detect remote registry browsing. INSTALLATION: Do not install in "C:\WINNT" directory. Sometimes intruders will be able to access files if they know the filename; installing in some other directory prevents a priori knowledge. Better yet, install in C:\WINNT, then reinstall in some other directory, then turn auditing on within that directory to alert you to people accessing those older files. INSTALLATION: Use the boot partition only for booting and for system files. Put data and applications on a separate partition. It is also a good idea to separate applications from data. CONTROLPANEL: Enable "Password Protected" on the screensaver. The best screensaver is "Blank Screen". You would think that screensavers run at idle priority, but this isn't always the case, so you can increase the performance of your server by using "Blank Screen". Also, this will reduce power consumption in monitors, especially those that can detect a blank screen and turn themselves off. Finally, some screensavers (i.e. PointCast) are probably hackable. REGEDT32: Turn off automatic sharing of ADMIN$, C$, D$, etc. via the "AutoShare" parameter in the registry. This parameter is under "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters", and is "AutoShareServer" for WinNT Server or "AutoShareWks" for WinNT Workstation. This is a DWORD, with a value of '1' for enabled (default), or a value of '0' for disabled. You will have to add the value yourself because it doesn't already exist in the registry. REGEDT32: Turn of account/share information via anonymous access. Add "RestrictAnonymous" DWORD with a value of "1" to the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA" Note that if you see an error "Could not find domain controller for this domain." while setting domain trust relationships, you may have to change it back. USRMGR: If you are using Domains (rather than Workgroups), change the user right "Access this computer from the network" to "Authenticated Users" rather than "Everyone". This disables remote access via local accounts on your machine, and allows only access through domain accounts. PASSPROP: Enable lockout of the "administrator" account for remote access. This enables the situation where the remote intruder fails to guess the correct password after three tries. After lockout, the administrator can only log in locally at the system console. You can also disable remote administrator access completely in USRMGR by removing the right "Access this computer from the network" from "Administrators", but this disables all remote administration, which make administration too difficult in a large WinNT environment. Also consider physical intrusion prevention network wide. John Kozubik suggests using login scripts to force the built-in password protected screen-saver. In the login script, include the line like: regedit /s \\MY_PDC\netlogon\scrn.reg And in the file "scrn.reg", put the text: REGEDIT4 [HKEY_CURRENT_USER\Control Panel\Desktop] "ScreenSaveTimeOut"="1800" "ScreenSaveActive"="1" "SCRNSAVE.EXE"="c:\winnt\system32\logon.scr" "ScreenSaverIsSecure"="1" This will trigger the password prompt to appear 30-minutes after a user is away from the desktop (it doesn't log them out; just forces them to re-enter the password before they have access again). 3.2 How do I increase intrusion detection/prevention under Win95/Win98? This section assumes you are a home user using Win95/Win98 to access the Internet. Win95/Win98 has no auditing or logging capabilities; you really should upgrade to WinNT if you are using the system for any serious purpose. The following are techniques for the typical user: 1. 2. Install the latest patches (of course). Turn off print sharing. When print sharing is turned on, the system creates a PRINTER$ share that allows remote systems to access printer drivers from the local system32 directory. Unfortunately, this allows remote systems to access non-driver files, such as the Win95 password file (combined with other Win95 bugs). 3. Turn off file sharing. As a home user, you probably don't need it. If you must share files, make sure that you choose a strong password, and only turn it on for brief moments while you need to share the files, then turn it off again. 4. (more forthcoming) John Kozubik suggests the following techniques for corporate users (who presumably run login scripts from the servers). Since Win95/Win98 is so vulnerable, they provide easy penetration to the rest of the corporate environment. Win95 caches passwords in easy-to-read formats, so you want to remove them. del c:\windows\*.pwl The password cache file will be the first one intruders look for. It has the same name as the user name, and poorly encrypts the cached passwords. Beware that this deletes dial-up passwords as well, so users that bring their notebooks into work and connect to the network will find their home dial-up passwords deleted. Disable internal caching of passwords Run: REGEDIT /s \\MY_PDC\netlogon\nocache.reg where "nocache.reg" consists of: REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Netwo rk] "DisablePwdCaching"=dword:00000001 3.3 How do I increase intrusion detection/prevention under UNIX? 1. Do not install more services than you need. I installed everything on my RedHat Linux distribution and the machine lights up like a Xmas tree when port scanned. I already know of a few holes on that (test) machine that I can use to break in. 2. Use 'netstat' or a TCP/UDP scanner and 'rpcinfo' to list all services on your machine. Again, make sure that everything you don't explicitly understand is turned off. 3. (more forthcoming; frankly, I've been more of an WinNT admin lately so my skills are getting rusty) 4. Read ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist. Of course, you might want to consider upgrading the system. There are a large number of SunOS 4.x systems out there, for example, even though Sun stopped "officially" supporting it many years ago. 3.4 How do I increase intrusion detection/prevention under Macintosh? Macintoshes are 'end-user' systems, and support few services that can be hacked. In comparison, Windows machines are more numerous, and UNIX machines have a lot more interesting (hackable) services running on them. Thus, Macintoshes are frequently not the target of intruders. Beyond that, I know of nothing in particular. 3.5 How do I increase intrusion detection/prevention for the enterprise? First and foremost, create a security policy. Let's say that you are watching the network late in the evening and you see an intrusion in-progress. What do you do? Do you let the intrusion progress and collect evidence? Do you pull the plug? If so, do you pull the plug on the firewall between the intra- and extra- net? Or do you take down the entire Internet connection (preventing users from getting to you web site)? Who has the authority to pull the plug? The priorities need to be set in place by the CEO of the corporation. Let's consider the scenario where you think you are being attacked, so you pull the plug. The users get up in arms, and complain. And, as it turns out, you were wrong, so your but gets fried. Even when blatant attacks are going on, few people pull the plug for fear of just such repercussions. Data theft is theoretical; ticked-off users are very real. Therefore, you need a policy from the very top that clearly states the importance of things and clearly lays out a procedure for what happens when an intrusion is suspected. [Author: does anybody have sample policies they can send me?] Once you have the priorities straight, you need to figure out the technology. That's described in the next section. 3.6 How should I implement intrusion detection my enterprise? Think about how you can configure the following systems in order to detect intruders: 1. 2. 3. 4. 5. Operating Systems such as WinNT and UNIX come with integrated logging/auditing features that can be used to monitor security critical resources. A section below discusses how to configure Windows and UNIX in order to enable intrusion detection. Services, such as web servers, e-mail servers, and databases, include logging/auditing features as well. In addition, there are many tools that can be used to parse these files in order to discover intrusion signatures. Network Intrusion Detection Systems that watch network traffic in an attempt to discover intrusion attempts. A section below lists a number of these products. Firewalls usually have some network intrusion detection capabilities. After all, blocking intrusions is their primary purpose; it would be foolish not to detect intrusions as well. Network management platforms (such as OpenView) have tools to help network managers set alerts on suspicious activity. At minimum, all SNMP devices should send "Authentication Failure" traps and management consoles should alert administrators when these go off. 3.7 What should I do when I've been hacked? Read CERT's intruder detection checklist at ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist. For the most part, a good response requires that you've set up good defensive measures in the first place. These include: incident response team Set up an "incident response team". Identify those people who should be called whenever people suspect an intrusion in progress. The response team needs to be "inter-departmental", and include such people as: upper management Need to identify somebody with the authority to handle escalated issues. For example, if the company has an online trading service, you need to identify somebody with enough power to "pull the plug". Going off-line on such a service will have a major impact -- but would still be better than hackers trading away people's stocks. HR (Human Resources) Many attacks come from internal employees. This consists of both serious attacks (cracking into machines) as well as nuisance attacks, such as browsing inappropriate servers looking for files like customer lists that might be left open. technical staff Security is often separate from normal MIS activity. If security personel detects a compromised system, they need to know who in MIS they need to call. outside members Identify people outside the company that may be contacted. This might be a local ISP person (for example, helping against smurf attacks), the local police, or the FBI. These aren't necessarily "formal" team members. They might not know anything about this, or they might simply be a "role" (like [email protected]). But put their names on the list so that everyone knows who to call. security team Of course, the most important team members will be the security people themselves. Note that not all "team members" need to be involved with every incident. For example, you only need to ping upper management on serious attacks. They may never be called upon, but they do need to be identified, and they do need to be prepared as to the types of decisions they will have to make. response procedure Figure out guidelines now for the response action. For example, you need to decide now what your priorities are between network uptime and intrusion: can you pull the network plug whenever you strongly suspect intrusion? Do you want to allow continued intrusion in order to gather evidence against the intruder? Decide now, and get the CEO's approval now, because you won't have time during the attack. lines of communication Figure out guidelines for communication. Do you propagate the information up the corporate food chain from your boss up to the CEO, or horizontally to other business units? Do you take part in incident reporting organizations such as FIRST (Forum of Incident Response and Security Teams) at http://www.first.org/? Do you inform the FBI or police? Do you notify partners (vendors/customers) that have a connection to your network (and who may be compromised, or from whom the attack originated)? Do you hide the intrusion from the press? Note that the FBI has a webpage for reporting crime at: http://www.usdoj.gov/criminal/cybercrime/reporting.htm logging procedures Set up your logging/auditing/monitoring procedures now; one of the most common thoughts after an attack is how much they wished they had adequate logging in the first place in order to figure out what happened. training/rehearsal Get training on all these issues. Each person involved needs to understand the scope of what they need to do. Also carry out dry runs. Assume a massive hacker penetration into your network, and drill what happens. Most hacker penetrations succeed because companies practice at being unprepared for their attack. Since computer networks are growing so fast, there are not enough trained people to handle intrusions. Likewise, networks grow in an ad hoc fashion, so logging/auditing is haphazard. These conditions lead to the state that people don't know what to do when they've been attacked, and their networks aren't robust enough to recover well from the attack. 3.8 How should I respond when somebody tells me they've been hacked from my site? On the IDS mailing list, someone asked how they should respond to the following e-mail: Below is a log showing a telnet connection from a machine within your domain. The machine it connected to does not offer this service publicly so this can only be assumed to be an IP space probe for vulnerable machines. We take this matter seriously, and hope that you will as well. Please take action on this issue as is appropriate and respond to this address with your actions. Nov 6 07:13:13 pbreton in.telnetd[31565]: refused connect from xx.xx.xx.xx This log entry was likely generated by tcpwrappers, a facility that enhances logging and access control to services on UNIX. It shows an unauthorized attempt from your site to the specified machine. As claimed in the e-mail message, it may be an automated sweep of some sort. The most popular protocols people sweep with are ICMP, FTP, SMTP, NNTP, and Telnet. In any case, this is evidence of a probe, not an attack. Furthermore, there is no other corroborating evidence. As pointed out by Greg Drew <gdrew at computer dot org> there could be a number of benign reasons: Somebody typed "telnet xx.xx.xx.xx" and mistyped the IP address. Somebody meant to type "telnet xx.xx.xx.xx 25" to connect to the STMP service in response to receiving spam from the site. The person might have forgotten the "25" or mistyped "23". Somebody might have actually done a more extensive scan on the target machines in response to spam. I've personally done light scans before (finger, rusers, etc.) to track down the source of spam. May have been an honest mistake (i.e. somebody used to have an account on that machine, but no longer does). But there are also some nefarious possibilities: Your site may have already been hacked, and the hacker is running scans from the compromised machine. One of your employees is using the machine to hack (I've worked at a company where this happened -- though since the company made protocol analyzers, it was kinda stupid and they were quickly detected). <vick at macdoon dot lerc dot nasa dot gov> pointed out another possibility: this might be a social engineering attack. The message asks (commands) you to contact them to describe what actions you have taken. If you do so, it will tell a lot about your network: The target is a legal IP address (though not so interesting). Your IP address (the above message was likely sent to "postmaster" or some such wellknown address, but you will likely respond using your own address. Your readiness level: if you come back with a lame response (such as "we can't take action because we have no log files") then they know that your network is prime hacking territory. This may be "social engineering spam". The sender of the message may be a company looking to resell intrusion detection products. Like responding to spam, there is probably little good that can come about responding to this e-mail message (unless you find evidence that some hacker has been using your network as a stepping stone). It probably would be a good idea to check you system logs for the data/time in question, and if you don't have logs, now might be a good time to turn logging on. As it turns out, the incident was benign. The target network had reconfigured itself, and the "unauthorized" user didn't know about it yet, and wasn't logging in correctly. 3.9 How do I collect enough evidence about the hacker? An interesting field of IDS is collecting enough information about the incident to identify the hacker. This can be very hard because truely elite hackers will be bouncing their attacks from another compromised system. Hackers will also often employ IP address spoofing, which may appear as if attacks are coming from machines that aren't even turned on. As far as I can tell, the best technique is to collect as much information as you can. For example, I've put a packet sniffer capturing to tracefiles on our T-1 line saving to files on a 16-gigabyte disk (most any sniffing program on most platforms can do this). You may not think it fun, but I enjoy perusing these files. It's amazing how many TCP/UDP scans and other probes I see on a regular basis. Likewise, you should make sure you have full auditing and logging enabled on any/all systems exposed to the Internet. These will help you figure out what happened when you were hacked. 4. Products This section discusses the major network IDS products. 4.1 What freeware/shareware intrusion detection systems are available? The most complete list on the net seams to be the COAST Intrusion Detection System Resources page at http://www.cs.purdue.edu/coast/ids. See sections 4.4 and 4.5 below for a discussion of some freeware technologies. 4.2 What commercial intrusion detection systems are available? Note: I've removed the table of info because it has gotten dangerously out-of-date Reviews can be found at: http://www.nwc.com/1023/1023f19.html Several of these have comments from the vendors themselves that they e-mailed me. Also note that this information can quickly become out of date. The industry has gone through several major changes since I started this document. The site http://www.internations.net/uk/talisker/ has done a good job of wading through the marketing hype and pulling out the salient points about each of the commercial products. 4.2.0 BlackICE by Network ICE Vendor comments: BlackICE has multiple versions. The core is built around "BlackICE Sentry", a full networkbased intrusion detection system. There are also host/hybrid versions that run on Windows desktops with a built-in personal firewall. The list of intrusions it detects is at: http://www.networkice.com/advICE/Intrusions Distinguishing features of BlackICE Sentry are: Full 7-layer, stateful, protocol analysis Anti-evasion techniques (handles fragmentation, whisker scans, a whole suite of signature changing attacks) Extremely fast, easily handles full 100-mbps bandwidth. Goto http://www.networkice.com/ for more information. 4.2.1 CyberCop Monitor by Network Associates, Inc. Vendor comments: CyberCop Monitor is a hybrid host/network based IDS that analyzes network traffic to and from the host as well as Windows NT EventLog audit trails and Windows NT authentication activity. Developed under the Microsoft Management Console user interface, both CyberCop Monitor and the SMI Console integrate to provide an easy to use graphical interface for local / remote reporting, and remote installation. Configuration editor allows for custom settings and thresholds to suit every environment, including security profiles, account groups, time and subnets. Extensive filtering using ordered filter rules for each signature. Report coalescing feature suppresses denial of service on the IDS itself. Report collating of monitoring and scanning information per system with trend analysis options, including 3D charting and graphing from an SQL database. Goto <http://www.nai.com/> for more information. CyberCop Monitor was written from the ground up by NAI. There is NO connection with the CyberCop Network v.1.0 product developed by Network General/WheelGroup or the Haystack product from TIS - This was aging technology and shelved some months after each subsequent acquisition. 4.2.2 RealSecure by Internet Security Systems (ISS), Inc. Vendor comments: Internet Security Systems is the first and only company that has tied both intrusion detection (ISS RealSecure) and vulnerability detection (ISS Internet Scanner) into an integrated security platform for organization to help plan, analyze, and manage their security on a continuous basis. ISS RealSecure is a component of ISS SAFEsuite family of products that cover managing security risk across the enterprise. ISS RealSecure is the market-leader in Intrusion Detection with an integrated host and network based solution. ISS RealSecure comes with over 400 attack signatures with the ability for customers in both the network and host based solution to add or modify their own signatures. 4.2.3 NetRanger by WheelGroup/Cisco Originally by Wheelgroup, bought by Cisco. It has been recently renamed, though I'm not sure to what. Goto http://www.wheelgroup.com/. 4.2.4 eTrust Intrusion Detection by Computer Associates Formerly Memco/Abirnet/PLATINUM SessionWall, this is now owned by Computer Associates and marketed as eTrust Intrusion Detection. Goto http://www.cai.com/solutions/enterprise/etrust/intrusion_detection. Originally, SessionWall started out as more of a firewall/content-inspection platform that interposed itself in the stream of traffic. I'm not sure where it is now. 4.2.6 NetProwler by Axent Goto http://www.axent.com/. 4.2.7 Centrax by Cybersafe Goto http://www.cybersafe.com/solutions/centrax.html. 4.2.9 NFR by Network Flight Recorder Vendor comments: NFR is available in multiple forms: a freeware/research version (see below), the "NFR Intrusion Detection Appliance" which comes as bootable CD-ROM, and bundles from 3rd party resellers that add their own features on top of it (like Anzen). One of the popular features of NFR is "N-code", a fully featured programming language optimized for intrusion detection style capabilities. They have a fulll SMTP parser written in the N-code. Most other systems have either simply add signatures or force you to use raw C programming. Numerous N-code scripts are downloadable from the Internet from sources such as L0pht. NFR does more statistical analysis than other systems. The N-code system allows easy additions into this generic statistical machine. A general description can be found at http://www.nfr.net/forum/publications/LISA-97.htm 4.2.10 Dragon by Security Wizards Goto http://www.network-defense.com/ 4.3 What is a "network grep" system? A "network grep" system is based around raw packet capture pumped through a "regular expression" parser that finds patterns in the network traffic. An example pattern would be: "/cgi-bin/phf", which would indicate an attempt to exploit the vulnerable CGI script called "phf". Once building such a system, you would then analyze well-known attacks, extract strings specific to those attacks, and add them to your databse of patterns. See http://www.packetfactory.net/ngrep/ for an example. "Regexp" (regular expression) is a common pattern-matching language in the UNIX environment. While it has traditionally been used for searching text files, it can also be used for arbitrary binary data. In truth, such systems have more flexible matching criteria, such as finding ports or matching TCP flags. "libpcap" (library for packet capture) is a common library available for UNIX systems that "sniffs" packets off a wire. Most UNIX-based intrusion detection systems (of any kind) use libpcap, though many also have optimized drivers for a small subset of platforms. The source code for both modules is freely available. A large number of intrusion detection systems simply feed the output of libpcap (or tcpdump) into the regular expression parse, where the expressions come from a file on the disk. Some even simpler systems don't even use regular expressions and simply compare packets with well-known byte patterns. If you want to build a system like this yourself, read up on 'tcpdump' and regular expressions. To understand libpcap/tcpdump, the following document will be helpful: http://www.robertgraham.com/pubs/sniffing-faq.html. This class of intrusion detection system has one advantage: it is the easiest to update. Products of this class will consistently have the largest number of "signatures" and be the fastest time-to-market for detecting new popular attack "scripts". However, while such systems may bost the largest number of "signatures", they detect the fewest number of "serious" intrusions. For example, the 8 bytes "CE63D1D2 16E713CF" when seen at the start of UDP data indicates Back Orifice traffic with the default password. Even though 80% of Back Orifice attacks use the default password, the other 20% use different passwords and would not be detected by the system. For example, changing the Back Orifice password to "evade" would change the pattern to "8E42A52C 0666BC4A", and would go undetected by "network grep" systems. Some of these systems do not reassemble IP datagrams or TCP streams. Again, a hacker could simply reconfigure the MTU size on the machine in order to evade regexp-pcap systems. Such systems result in larger numbers of false positives. In the BackOrifice example above, the 64-bit pattern is not so uncommon that it won't be seen in other traffic. This will cause alarms to go off even when no Back Orifice is present. Systems based upon protocol analysis do not have these problems. They catch all instances of the attack, not just the common varieties; they result in fewer false positives; and they often are able to run faster because a protocol decode doesn't have to "search" a frame. They are also able to more fully diagnose the problem; for example distinguish between a "Back Orifice PING" (which is harmless) and a "Back Orifice compromise" (which is an extreme condition). On the other hand, it can often take a week to add a new protocol analysis signature (rather than hours) due to the design and testing involved. Also, overly-agressive attempts to reduce false positives also leads to missing real attacks in some cases. However, such systems have an advantage over protocol analysis systems. Because they do not have pre-conceived notion about what network traffic is supposed to look like, they can often detect attacks that other systems might miss. For example, if a company is running a POP3 server on a different port, it is likely that protocol analysis systems will not recognize the traffic as POP3. Therefore, any attacks against the port will go undetected. On the other hand, a network-grep style system doesn't necessarily care about port numbers and will check for the same signatures regardless of ports. 4.3.1 Dragon See above. 4.3.2 Bro Vern Paxson's Bro intrusion detection system. Vern Paxson wrote large portions of libpcap that many other intrusion detection systems are based on (like NFR and Dragon). I haven't heard of anyone actually using Bro itself. Read the paper http://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z for more information. 4.3.3 Snort http://www.clark.net/~roesch/security.html Snort has recently become very popular, and is considered really cool by a lot of people. It contains over 100 of its own signatures, and others can be found on the Internet. Following is an example rule: # here's an example of PHF attack detection where just a straight text string # is searched for in the app layer alert tcp any any -> 192.168.1.0/24 80 (msg:"PHF attempt"; content:"/cgi-bin/phf";) It says to alert an a TCP connection from any IP address and any port to the 192.168.1.x subnet to port 80. It searches for the content "/cgi-bin/phf" anywhere in the content. If it find such content, it will alert the console with a message "PHF attempt". Usage of snort is usually done in the following manner: BPF filters (part of libpcap) are configured to narrow down the focus to cetain types of traffic. A decision is made about which IP addresses are internal and which are external to further narrow down the focus. Rules are edited to fit the local environment. System runs Rules are further edited to remove false positives. Also, snort has a number of options to be used just to sniff network traffic. Rules: http://snort.rapidnet.com/ http://www.whitehats.com/ 4.3.4 Argus Argus isn't an intrusion detection system itself. However, it monitors packets off the wire and generates logfile events. You can then process those log entries (or peruse them yourself) to find intrusions. See ftp://coast.cs.purdue.edu/pub/tools/unix/argus for more info. Also see ftp://ftp.sei.cmu.edu/pub/argus-1.5 4.4 What tools do intruders use to break into my systems? 4.4.1 UNIX utilities These utilities either come with your favorite UNIX platform or you can download them for free. ping to see if a host is alive. traceroute to find the route to the host nslookup/dig to discover all your DNS information whois finds out Internic registration information finger finds out who is logged in and info about users rpcinfo finds out what RPC services are running showmount display shares on a machine SAMBA displays info about WinNT SMB shares telnet the granddaddy of them all -- allows you to connect and play with any text-based protocol (HTTP, FTP, SMTP, etc.) 4.4.2 WinNT utilities All of the UNIX utilities mentioned above can be used with WinNT. There are also some WinNT specific ones. nbtstat discovers NetBIOS information on remote machine net view is the LANMAN program that allows you to remotely view WinNT shares 4.4.3 Hacking-specific utilities The standard toolkit for a intruder. netcat is characterized as a "TCP/IP" Swiss Army Knife, allows intruders to script protocol interactions, especially text-based protocols. crack / NTcrack / L0phtCrack / etc. that crack network passwords (Dictionary or Brute Force). These packages also contain utilities for dumping passwords out of databases and sniffing them off the wire. Sniffing utilities for watching raw network traffic, such as Gobbler, tcpdump, or even an honest-to-god Network Associates Sniffer© Network Analyzer TCP and UDP port scanners for scanning/strobing/probing which TCP ports are available. TCP port-scanners can also run in a number of stealth modes to evade/elude loggers. Ping sweepers for pinging large numbers of machines to see which ones are active. Exploit packs which are a set of one or more programs that know how to exploit holes on systems (usually, once the user is logged in). Remote security auditors such as SATAN that look for a number of well known holes in machines all across the network. War dialers that dial lots of phone numbers looking for dial-in ports. NAT is based upon the SAMBA code, and is useful for discovering NetBIOS/SMB info from Windows and SAMBA servers. Scanners are programs (like SATAN, ISS, CyberCop Scanner) that probe the system for vulnerabilities. That have a huge number of vulnerabilities they check for and are generally automated, giving the hacker that highest return for the minimal effort. 4.5 What other free/shareware intrusion detection products should I be aware of? 4.5.0 NFR, Research Version The "NFR Research Version" is a configurable toolkit, available from the Internet for research and noncommercial use. It is "as is" software that requires expertise from the end user to install and configure. It is not a "plug and play" intrusion detection system. (quote from NFR) See above for info on the commercial version. 4.5.1 tcpwrappers Tcpwrappers are an add-in for UNIX, and sit between inetd and services (like ftp, telnet, etc.). The inetd will first call tcpwrappers, which will do some authentication (by IP address) and logging. Then, tcpwrappers will call the actual service, if need be. 4.5.2 IDS for Checkpoint Firewalls Log file analysis of firewalls is very similar to network analysis. See http://www.enteract.com/~lspitz/intrusion.html for an example. 4.5.3 Shadow I think it is a project used in the Navy to track intrusions, and generate reports on them. They have an interesting report at http://www.nswc.navy.mil/ISSEC/CID/co-ordinated_analysis.txt where they describe coordinated, slow attacks they have detected using this system. 4.5.4 AAFID Purdue's COAST distributed agent idea. I'm not sure how much of this is proposals, and how much is real. 4.6 Are there NIDS available for my host? A new class of NIDS runs on hosts in non-promiscuous mode. 4.6.1 Network ICE / BlackICE Defender The first such system was BlackICE Defender from Network ICE released in mid-1999. The system also contains a personal firewall. It runs on Win95, Win98, WinNT, and Win2k. It is targetted at both endnodes and servers. 4.6.2 Network Associates / CyberCop Monitor v2.0 The second system is CCM from Network Associates, released in late 1999. While billed primarily as a "host-based IDS", the majority of the intrusions it detects are network-based. It currently supports WinNT (and presumably Win2k) and they have announced support for Solaris. 4.6.3 CyberSafe / Centrax NNID In February of 2000, CyberSafe announced their "network node intrusion detection (NNID)". Apparently, versions of their Centrax NIDS come in both promiscuous and non-promiscuous licenses starting with version 2.3. 4.6.4 ISS / RealSecure Micro-Agent ISS has pre-announced a "Micro-Agent" version of the RealSecure NIDS. The announcement indicates that it will also contain "blocking" features, which presumably will consist of some sort of personal firewall. They have announced that this will be available for both WinNT (and presumably Win2k) as well as Solaris. 6. Resources 6.1 Where can I find updates about new security holes? 6.1.1 CERT (Computer Emergency Response Team) If it is a security problem, you will eventually see it appear in a CERT advisory. CERT (Computer Emergency Response Team) was set up by a number of universities and DARPA in response to the Morris Worm of 1988. Goto http://www.cert.org/. 6.1.2 AUSCERT (AUStralian Computer Emergency Response Team) AUSCERT is the AUStralian Computer Emergency Response Team. For registration information, see their web site on: http://www.auscert.org.au/ For more details, contact AUSCERT directly on [email protected]. 6.1.3 CIAC (Computer Incident Advisory Capability) by US Department of Energy Has a number of useful advisories. Goto http://www.ciac.org/. 6.2 What are some other security and intrusion detection resources? 6.2.1 Purdue's COAST archive This is the best site on the net for learning about IDS and security in general. See http://www.cs.purdue.edu/coast, http://www.cs.purdue.edu/coast/intrusion-detection, and http://www.cs.purdue.edu/coast/ids. 6.2.2 SANS Institute I think this may be the best site for security information for people who are not themselves hackers. Their target audience is MIS professionals who have to defend their networks. Goto http://www.sans.org/ 6.2.3 L0pht Heavy Industries These are some hackers with some pretty good tools and useful alerts, targeted at Windows. Goto http://www.l0pht.com/ 6.2.4 Technical Incursion Countermeasures I like this site; it has a bunch of well organized info on intrusion (A.K.A. incursion). Goto http://www.ticm.com/ 6.2.5 IDS mailing list Email "subscribe ids" to [email protected] Email questions to [email protected] This is a nice, low-volume list with interesting discussions from time-to-time. 6.2.6 Michael Sobirey's Intrusion Detection Systems page http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html 6.2.7 advICE database http://www.networkice.com/advice/Countermeasures/Intrusion_Detection/default.htm 6.3 What are some sites that are interesting? Here are some sites that aggregate info from other sites. Could be worth a look. 6.3.1 NIH security site Goto http://www.alw.nih.gov/Security/ 6.3.2 NTSecurity.net Goto http://www.ntsecurity.net/. 7. IDS and Firewalls 7.2 Why do I need IDS if I already have a firewall? A common misunderstanding is that firewalls recognize attacks and block them. This is not true. Firewalls are simply a device that shuts off everything, then turns back on only a few well-chosen items. In a perfect world, systems would already be "locked down" and secure, and firewalls would be unneeded. The reason we have firewalls is precisely because security holes are left open accidentally. Thus, when installing a firewall, the first thing it does is stops ALL communication. The firewall administrator then carefully adds "rules" that allow specific types of traffic to go through the firewall. For example, a typical corporate firewall allowing access to the Internet would stop all UDP and ICMP datagram traffic, stops incoming TCP connections, but allows outgoing TCP connections. This stops all incoming connections from Internet hackers, but still allows internal users to connect in the outgoing direction. A firewall is simply a fence around you network, with a couple of well chosen gates. A fence has no capability of detecting somebody trying to break in (such as digging a hole underneath it), nor does a fence know if somebody coming through the gate is allowed in. It simply restricts access to the designated points. In summary, a firewall is not the dynamic defensive system that users imagine it to be. In contrast, an IDS is much more of that dynamic system. An IDS does recognize attacks against the network that firewalls are unable to see. For example, in April of 1999, many sites were hacked via a bug in ColdFusion. These sites all had firewalls that restricted access only to the web server at port 80. However, it was the web server that was hacked. Thus, the firewall provided no defense. On the other hand, an intrusion detection system would have discovered the attack, because it matched the signature configured in the system. Another problem with firewalls is that they are only at the boundary to your network. Roughly 80% of all financial losses due to hacking come from inside the network. A firewall a the perimeter of the network sees nothing going on inside; it only sees that traffic which passes between the internal network and the Internet. Some reasons for adding IDS to you firewall are: Double-checks misconfigured firewalls. Catches attacks that firewalls legitimate allow through (such as attacks against web servers). Catches attempts that fail. Catches insider hacking. "Defense in depth, and overkill paranoia, are your friends." (quote by Bennett Todd <bet at mordor dot net>). Hackers are much more capable than you think; the more defenses you have, the better. And they still won't protect you from the determined hacker. They will, however, raise the bar on determination needed by the hackers. 7.2.1 How is it that hackers can get through firewalls? Editors Note: This just clarifies the point above. Consider bridge building throughout history. As time goes on, technology improves, and bridges are able to span ever larger distances (such as the Golden Gate bridge in SF, whose span is measured in kilometers). Bridge builders are very conservative due to the immense embarassment (not to mention loss of life) should the bridges fail. Therefore, they use much more material (wood, stone, steel) than they need, and they don't create spans nearly as long as they think they can. However, as time goes on, as bridges prove themselves, engineers take more and more risks, until a bridge fails. Then all the engineers become much more conservative again. As has been quoted "It's easy to build a bridge that doesn't fall down; what takes skill is building a bridge that just barely doesn't fall down." In much the same way, most firewall administrators take the conservative approach. It is easy to build a firewall that can't be hacked by being overly conservative and paranoid, and simply turn off all but the absolutely necessary services. However, in the real world, engineers are not allowed to be sufficiently paranoid. Just like bridge builders want to span ever wider rivers and gorges, corporations want to ever expand the services of the Internet. This puts immense pressure on firewall admins to relax the barriers. This process will continue up to the point where there system is hacked, at which point the corporation will become much more conservative. From this perspective, one could say that corporate dynamics are such that they will generally force the system to the point where it gets hacked. As every firewall admin knows, the system is under constant attack from the Internet. Hackers from all over the world are constantly probing the system for weaknesses. Moreover, every few months a new security vulnerability is found in popular products, at which point the hackers simply scan the entire Internet looking for people with that hole, causing thousands of websites to be hacked. Such recent holes have been the ColdFusion cfmdocs bug and the Microsoft .htr buffer overflow. 7.3 If I have a intrusion detection, do I need firewall? Of course. Every corporation needs a well managed, single point of entry. There are a huge number of "script-kiddies" that are always running automated programs (like SATAN) on the Internet looking for holes. Without a firewall, these automated programs can detect and exploit holes literally in the blink of an eye. Even dial-up users who use the Internet only a few hours a week are getting scanned on a regular basis; high-profile corporate sites will be scanned by script-kiddies much more often. 7.4 Where does the intrusion detection system gets its information? The firewall? No. While some log file analysis program do scan firewall logs for signs of intrusions, most intrusion detection systems get their information elsewhere. Remember that firewalls are simple rule-based systems that allow/deny traffic going through them. Even "content inspection" style firewalls do not have the capability to clearly say whether the traffic constitues an attack; they only determine whether it matches their rules or not. For example, a firewall in front of a web server might block all traffic except for TCP connections to port 80. As far as the firewall is concerned, any port-80 traffic is legitimate. An IDS, on the other hand, examines that same traffic and looks for pattern of attack. An IDS system doesn't really care if the manager decided to allow port 80 and deny the rest: as far as the IDS is concerned, all traffic is suspicious. This means that an IDS must look at the same source of data as the firewall: namely, the raw network traffic on the wire. If an IDS sat "downstream" from the firewall isntead of side-by-side, it would be limitted to only those things the firewall considered attacks. In the above example, the firewall would never pass port 80 traffic to the IDS. +-+ . |F| +-----+ . |I+--+IDS#1| . /============\ |R| +-----+ /============\ . H H |E| H corporate H . H internet H--------+--------+ +------+------H network H . H H | |W| | H +-----+ \============/ +--v--+ |A| +--v--+ \=========+IDS#4| |IDS#3| |L| |IDS#2| +-----+ +-----+ |L| +-----+ . +-+ . IDS #1 Few IDSs work this way. Firewalls don't produce enough information in order to effectively detect intrusions. IDS #2 This popular placement of an IDS detects attacks that successfully penetrate the firewall. IDS #3 This placement detects attacks that are attempted against the firewall. IDS #4 By placing intrusion detection systems throughout a corporate network, attacks by insiders will be detected. 8. Implementation Guide 8.1 What questions should I ask my IDS vendor? CSI (Computer Security Institute) has a good page on this, where they posed questions to IDS vendors, as well as asked them what the difficult questions are. This site is at http://www.gocsi.com/intrusion.htm. Some common questions are: What does it cost? Of course. What do signature updates and maintanance cost? Intrusion detection is much like virus protection, a system that hasn't been updated for a year will miss common new attacks. At what real-world traffic levels does the product become blind, in packets/second? First, what segments do you plan on putting the IDS onto? If you have only a 1.5-mbps connection to the Internet that you want to monitor, you don't need the fastest performing system. On the other hand, if you are trying to monitor a server farm in your corporation in order to detect internal attacks, a hacker could easily smurf the segment in order to blind the sensor. The most important metric is packets/second. Marketing people use weasle words to say that their products can keep up with a full 100-mbps networks, but that is only under ideal conditions. A Network World did a review in August of 1998 where products failed at roughly 30% network load (50,000 pacets/second). Likewise, Network Computing did a review in September of 1999 with real-world traffic where several products that claimed 100-mbps could still not keep up. How easy is the product to evade? Go down the list in section 9.4 and ask the vendor if such activities will evade the IDS. If you want to give the vendor heartburn, ask them about section 9.5 . How scalable is the IDS system as a whole? How many sensors does the system support? How big can the database be? What are the traffic levels when forwarding information to the management console? What happens when the management console is overloaded? These are tough questions. How much will it cost to run and maintain the product? How good is the reporting architecture? How easy is it to manage false positives? How long does it take to track down alerts and identify the situation? How many people do I need to use this product? The following questions are commonly asked, but are less likely to produce meaningful answers: How many signatures does the system support? Unfortunately, vendors dramatically inflate their signature count. This is the game that all vendors must play, even though it is becoming less and less important. What intrusion response features does the product have? A feature like automatically reconfiguring a firewall sounds really cool, but in real life, few security managers implement it. Reconfiguring a corporate firewall is extremely dangerous. 8.2 How do I maintain the system on an on-going basis? I put this question in here hoping for feedback; I really don't have an answer. If you install an intrusion detection system, you WILL see intrusions on an on-going basis. In a SOHO environment, you will likely get scanned by a hacker once a week. On a well-known web-site, hackers will probe your site for vulnerabilies many times per day. On a large internal corporate network, you will find constant suspicious activities by internal employees. The first problem that you are likely to be confronted with is employees surfing p-orn sites on the web. Just about every long-term administrator I know has interesting stories about this. Most don't care about p-orn, it just embarrassing knowing what people are up to. It is interesting that many otherwise conservative corporations do not outright restrict such surfing -because it is often the executives themselves that do it. Lower-level engineers detecting such activities usually fear to bring the subject up. The next problem that engineers face is a Human Resource (HR) issue. You will find users doing things they shouldn't, so a lot of time is spent interfacing with HR working with the offending employee. The last problem is what to do about Internet script-kiddies and hackers probing your system. Usually, a call to ISP in question or e-mail to their "abuse@" mail box suffices. Sometimes the ISP will be grateful - because their own systems have been compromised. Remember that even what appears to be the most egregious hack may, in fact, be innocuous, so aproach other people with dignity and respect. 8.4 How do I stop innapropriate web surfing? One of the biggest concerns for corporations today is employees surfing "innapropriate" web sites. To some extent, companies are worried about employees wasting company time on the Internet, and to another extent, companies are worried about legal liability, such as when an employee surfs p-orn sites that causes a sexual harassment lawsuit. However, companies do not like being in the position of being "big brother". Rules against inappropriate surfing inevitably lead to grey areas (for example: Playboy.com recently had an article on computer security, which an employee could easily have stumbled across while doing a legitimate search on the web). Intrusion detection systems, firewalls, proxy servers, and sniffing programs can be configured to log all web surfing traffic to log files, including who accessed which websites. Most companies already have these logs, but few make use of this information. Network technicians do not want to take on the role of HR and prosecute people. (In many cases, the culprits are executives and going after them can be a career limiting move (CLM)). One elegant solution is posting such information to a public internal website. This has been known to dramatically affect inappropriate surfing. Rather than having a central authority judging appropriateness, it leaves it up to the individual to make that judgement. 8.5 How can I build my own IDS (writing code)? Simple intrusion detection systems are easy to build. Simply grab an input source (log files, network traffic) and pass it through a pattern match (regexp). Along with it, through the same data through some statistical analysis, much like how SETI@Home sends radio noise through some Fourier analysis looking for repeated patterns. For example, section 4.3 above discusses a "network grep" system that passes network traffic through a pattern match system. Such a system could be built with some knowledge of C and a UNIX system. Similarly, section 4.5.2 describes a PERL based system that parses log files from a firewall. 8.7 What is the legality of NIDS (since it is a form of wiretap)? Different countries and states have different laws, but it is generally legal to monitor your OWN traffic for intrusions. One concern that people have is that running a NIDS on a corporate network results in network managers viewing employee Internet surfing activity (sometimes network managers find top executives surfing porn sites). As the network equipement and the user's workstation belong to the company, the legal precident is that use of the corporate equipment implies consent to monitoring. However, it is recommended that companies explicitly state in employee handbooks that their network activity will be monitored. At minimum, it avoid embarrasing situations. 8.8 How do I save logfiles in a tamper-proof way? The first thing a hacker does is delete/change the logfiles in order to hide evidence of the break in. Therefore, a common need is to have a "write-once" storage system whereby once data is written, it can never be altered. WORM (Write-Once-Read-Many) drives have historically been used for this purpose, but they are expensive and finnicky. They probably don't have drivers for your system, and you software is likely incompatible with them in other ways (i.e. some systems do alter the files a little bit as they create them, which doesn't work on a worm). One problem with any system is that entropy sets in. It may be provable secure today, but it is unlikely to stay that way. For example, one technique for logging would be to employ syslog where the receiver doesn't have a TCP/IP stack but instead uses TCPDUMP to save the raw packets to a file (presumably, a utility would be run a later date to reconstruct the syslog entries). From the entropy perspective, there is no guarantee that a TCP/IP stack won't be installed during an update, or when a new person joins the team, or when machines get shuffled around. To combat such entropy, the model system uses the "snipped-wire" approach. In this model, an extra Ethernet adapter is installed in the machine who is generating the data, and the receive wire is cut. If an accident later happens such that the extra adapter is connected to an unsecured network, then few problems are likely to result. In much the same way, the receiving system should have only a single Ethernet adapter, and its transmit wire should be cut. It would be best to also disable the TCP/IP stack and instead force the data through packet sniffing utilities. (Yes, there are attacks that can compromise the system even when no responses are ever received). Normal TCP/IP won't work in this scenario. You will need to hard-code the route and ARP tables on the generating machine in order to force the traffic out the one-way wire. Similarly, you will need to use special utilities on the receiving machine in order to parse incoming packets back into useful data. UDP-based transports like 'syslog' and SNMP Traps are the most useful transports in this situation. They are easy to generate on the outgoing machine as they are built into most systems. Since responses aren't generated anyway, it doesn't hamper the normal flow of applications. Likewise, they are easy to parse back into SNMP messages or syslog files on the receiving end, or at least, it is easy to harden a TCP/IP stack to receive only those ports. At very least, TFTP or NFS can be configured to transport files to a TCP/IP stack on the other side. One problem that goes along with this is data management. You cannot connect the data repository to a network, so anything you use to backup the system must be installed on the system itself. Personally, the system I use is an old Pentium-90 computer with a 6-gig drive, CD-ROM writer, and a sniffing utility that dumps all the network traffic (a 416-kbps DSL connection) to packet capture files on the disk. A couple simple filters remove a lot of the bulk so downloading the latest RedHat distribution doesn't fill up the disk. I prefer this solution over actual log files because it captures absolutely everything that happens on the wire, even all numerous so-called stealth attempts. 9 What are the limitations of NIDS? Network intrusion detection systems are unreliable enough that they should be considered only as secondary systems designed to backup the primary security systems. Primary systems such as firewalls, encryption, and authentication are rock solid. Bugs or misconfiguration often lead to problems in these systems, but the underlying concepts are "provably" accurate. The underlying concepts bhind NIDS are not absolutely accurate. Intrusion detection systems suffer from the two problems whereby normal traffic causes many false positives (cry wolf), and careful hackers can evade or disable the intrusion detection systems. Indeed, there are many proofs that show how network intrusion detection systems will never be accurate. This doesn't mean intrusion detection systems are invalid. Hacking is so pervasive on today's networks that people are regularly astounded when they first install such systems (both inside and outside the firewall). Good intrusion detection systems can dramatically improve the security of a site. It just needs to be remembered that intrusion detection systems are backup. The "proveably accurate" systems regularly fail (due to human error), and the "proveably incorrect" systems regularly work. 9.1 Switched network (inherent limitation) Switched networks (such as 100-mbps and gigabit Ethernet switches) poses dramatic problems to network intrusion detection systems. There is no easy place to "plug in" a sensor in order to see all the traffic. For example, somebody on the same switched fabric as the CEO has free reign to attack the CEO's machine all day long, such as with a password grinder targetting the File and Print sharing. There are some solutions to this problem, but not all of them are satisfactory. Embed IDS within the switch Some vendors (Cisco, ODS) are imbedding intrusion detection directly into switches. As far as I can tell, however, these IDS systems do not have the broad range of detection as traditional NIDS. Monitor/span port Many switches have a "monitor port" for attaching network analyzers. A NIDS can easily be added to this port as well. An obvious problem is that the port runs at a much lower speed than the switch backplane, so the NIDS will not be able to see all the traffic on a heavily loaded switch. Moreover, such ports are often used by sniffers for network management purposes, and must often be swapped out occasionally. Tap into the cable (for inter-switch or switch-to-node) A monitor can be connected directly to the cable in order to monitor the traffic. These may be cables between switches or cables from the switch to a host. Different techniques would be: inline taps Inline taps are devices that insert themselves directly into the stream of communication and make a copy of it. A typical example would be the Shomiti Century Tap (http://www.shomiti.com/productsf/tapfamilyf.html) which plugs into a 100-mbps full duplex line, and allows a computer equipped with 2 adapters to read both channels. vampire taps In the olden days, vampire taps were a mainstay of thick coax Ethernet, and were the preferred way of connecting end-nodes to the network. inductance taps Most taps can be detected with TDR (Time Domain Reflectometer) equipement. Inductance taps do change the cable in any way, but instead site on the outside and monitor the electromagnetic noise emitted by the cables. Only used by spies. The problem with tapping into the cable, especially those between switches, is that they generate huge amounts of traffic. Most NIDS cannot handle very high loads before going "blind". Thanks to Christopher Zarcone < czarcone at acm dot org > for this info. Host-based sensors From a conceptual point of view, the only way to defeat the resource limitations of switched networks is to distribute host-based intrusion detection. Several host-based agents, such as BlackICE and CyberCop Monitor, contain a network-based component that monitors only that host's traffic. Others do the traditional logfile and audit analysis. 9.2 Resource limitations Network intrusion detection systems sit at centralized locations on the network. They must be able to keep up with, analyze, and store information generated by potentially thousands of machines. It must emulate the combined entity of all the machines sending traffic through its segment. Obviously, it cannot do this fully, and must take short cuts. This section lists some typical resource issues. 9.2.1 Network traffic loads Current NIDS have trouble keeping up with fully loaded segments. The average website has a frame size of around 180-bytes, which translates to about 50,000 packets/second on a 100-mbps Ethernet. Most IDS units cannot keep up with this speed. Most customers have less than this, but it can still occasionally be a concern. When buying an IDS, ask the vendor how many packets/second the system can handle. Many vendors will try to tell you how many bits/second, but per-packet is the real performance bottleneck. Virtually all vendors can handle 100-mbps traffic using 1500-byte packets, few can handle 100-mbps traffic using 60-byte packets. 9.2.2 TCP connections IDS must maintain connection state for a large number of TCP connections. This requires extensive amount of memory. The problem is exacerbated by evasion techniques, often requiring the IDS to maintain connection information even after the client/server have closed it. When buying an IDS, ask the vendor how many simultaneous TCP connections it can handle. 9.2.3 Other state information TCP is the simplest example of state information that must be kept by the IDS in memory, but other examples include IP fragments, TCP scan information, and ARP tables. 9.2.4 Long term state A classic problem is "slow scans", where the attacker scans the system very slowly. The IDS is unable to store that much information over that long a time, so is unable to match the data together. 9.3 Attacks against the NIDS The intrusion detection system itself can be attacked in the following ways. 9.3.1 Blind the sensor Network intrusion detection systems are generally built as "passive monitors" from COTS (commercialoff-the-shelf) computers. The monitors are placed alongside the networking stream, not in the middle. This means that if they cannot keep up with the high rates of traffic, they have no way to throttle it back. They must start dropping packets. This is known as trying to drink from a firehose. Few NIDS today can keep up with a fully saturated 100-mbps link (where "saturated" means average sized packets of 180 bytes, which is roughly 50,000 packets/second). Not only will the sensor start dropping packets is cannot process, high traffic rates can completely shut down the sensor. For example, consider a sensor that can process a maximum of 20,000 frames/second. When the proferred load is 40,000 frames/second, it usually drops actual processing down to 10,000 frames/second or 5,000 frames/second, or maybe even zero. This is because frame reception and frame analysis are two different acitivities. Most architectures require the system to capture the packet even when it is too busy to analyze it, which takes even more time away from analysis. Therefore, an intruder can attack the sensor by saturating the link. If the intruder is local, he/she can simply use a transmit program. A 400-Mhz box can fully saturate a link with 60-byte packets, breaking most IDS systems that might be attached to the system. A remote attacker can execute smurf or fraggle attacks, likewise saturating links. It is unlikely an attacker will have a fast enough link themselves (100-mbps is quite rare) in order to be able to attack head-on in this manner. 9.3.2 Blind the event storage (snow blind) The 'nmap' port scanning tool contains a feature known as "decoy" scans. It scans using hundreds of spoofed source addresses as well as the real IP address of the attacker. It therefore becomes an improbable task for the administrator to find discover which of the IP addresses was real, and which was one of the decoy addresses. Any attack can be built from the same components. A massive attack with spoofed addresses can always hide a real attack inserted somewhere inside. Administrators would be hard pressed to discover the real attack inside of all that noise. These two scenarios still retain forensics data, though. If the attacker is suspected, the data is still there to find. Another attack is to fill up event storage. When the database fills up, no more attacks will be discovered, or older attacks will be deleted. Either way, no evidence exists anywhere that will point to the intruder. 9.3.3 DoS (Denial of Service) A NIDS is an extremely complex system, equivelent in complexity to an entire TCP/IP stack running numerous services. This means the NIDS is susceptible to such attacks as SYN floods and smurf attacks. Moreover, the numerous protocols NIDS analyze leave them open to outright crashes when unexpected traffic is seen. Attackers can often buy the same intrusion detection systems used by their victim, then experiment in many ways in order to find packets that will kill the IDS. Then during the attack, the intruder kills the IDS, then continues undetected. 9.4 Simple evasion This section describes simple evasion tactics that fool basic intrusion detection systems. The next section will describe advanced measures. 9.4.1 Fragmentation Fragmentation is the ability to break up a single IP packet into multiple smaller packets. The receiving TCP/IP stack then reassembles the data back again before forwarding the data back up to the application. Most intrusion detection systems do not have the ability to reassemble IP packets. Therefore, there exist simple tools (like fragrouter) that can auto-fragment attacks in order to evade IDS. Note that fragmenting the IP packets in the middle of the TCP header has long been used to evade firewall port filtering. Some industrial grade NIDS can reassemble traffic. Also, some firewalls can "normalize" traffic by forcing reassembly before passing the traffic through to the other end. 9.4.2 Avoiding defaults People often use firewalls as easy NIDS, where they make assumptions that the destination port uniquely identifies the protocol. A hacker who successfully installs a backdoor can run standard protocols on non-default ports. For example, a hacker may send a user a Back Orifice infected program, but change the port from the default of 31337. Most intrusion detection systems will no longer identify the traffic correctly (though a few do). 9.4.3 Slow scans Because of the volume of traffic on the wire, NIDS have difficulty maintaining long-term traffic logs. It is therefore difficult to detect "slow scans" (ping sweeps or port-scans) where intruders scan one port/address every hour. 9.4.4 Coordinated, low-bandwidth attacks Sometimes hackers get together and run a slow scan from multiple IP addresses. This make it difficult for an intrusion detection system to correlate the information. 9.4.5 Address spoofing/proxying One goal of intrusion detection is to point fingers at who is attacking you. This can be difficult for a number of reasons. In 'Smurf' attack, for example, you receive thousands of replies from a packet that you never sent. The NIDS and detect those replies, but cannot discover who sent the forged packet. In TCP Sequence Number Prediction, forged IP addresses are used so that the NIDS does not know precisely where the intruder is coming from. Finally, most intruders will 'bounce' their attacks via FTP or Web proxies, or stage their attacks from other sites they have broken into. Thus, it will be very difficult to find out who is attacking your site, and configuring IP address filters in your firewall won't help. 9.4.6 Pattern change evasion Many simple network intrusion detection systems rely upon "pattern matching". Attack scripts have well know patterns, so simply compiling a database of the output of known attack scripts provides pretty good detection, but can easily be evaded by simply changing the script. For example, some POP3 servers are vulnerable to a buffer overflow when a long password is entered. There exist several popular attack scripts for this vulnerability. One intrusion detection system might contain 10 patterns to match match the 10 most common scripts, while another intrusion detection system looks at the password field and alarms when more than 100 bytes have been entered. The first system is easy to evade simply by changing the attack script, while the second system catches any attack on this point. The typical example is simple changes to the URL. For example, this document can be retrieved through the URL: http://www.robertgraham.com/pubs/network-intrusion-detection.html. Even though the exact pattern has changed, the meaning hasn't been altered. A NIDS looking for the original URL on the wire won't detect this alered one unless it has anti-evasion countermeasures. 9.5 Complex evasion Talented hackers can direct their attacks at their victims in ways to bypass intrusion detection systems. An early paper by Vern Paxson on his NIDS called "Bro" describes some of these problems. The original PostScript version is at ftp://ftp.ee.lbl.gov/papers/bro-usenix98-revised.ps.Z. The seminal paper on network intrusion detection "evasion" was written by Thomas H. Ptacek and Timothy N. Newsham. The original PostScript version is available at http://www.aciri.org/vern/PtacekNewsham-Evasion-98.ps, while an HTML mirror is available at http://www.robertgraham.com/mirror/Ptacek-Newsham-Evasion-98.html. Thomas H. Ptacek claims that many/most of the commercial products still (October 1999) have serious problems in this regard. Much this this section summarizes these two papers. These papers describe the abstract concept that the network model used by the network intrusion detection system is different than the real world. For example, an intruder might send a TCP FYN packet that the NIDS sees, but which the victim host never sees. This causes the NIDS to believe the connection is closed, but when in fact it isn't. Since TCP connections do not send "keep-alives", the intruder could wait hours or days after this "close" before continuing the attack. In practice, most interesting services do kill the connection after a certain time with no activity, but the inruder still can cause a wait of several minutes before continuing. The first such attack is to find a way to pass packets as far as the NIDS, but cause a later router to drop packets. This depends upon the router configuration, but typical examples include low TTL fields, fragmentation, source routing, and other IP options. If there is a slow link past the NIDS, then the hacker can flood the link with high priority IP packets, and send the TCP FIN as a low priority packet -the router's queuing mechanism will likely drop the packet. Another approach is to consider what the host will or will not accept. For example, different TCP stacks behave differently to slightly invalid input (which programs like 'nmap' and 'queso' use to fingerprint operating systems). Typical ways of causing different traffic to be accepted/rejected is to send TCP options, cause timeouts to occur for IP fragments or TCP segments, overlap fragments/segments, send slight wrong values in TCP flags or sequence numbers. The Ptacek/Newsham paper concentrated on IP fragmentation and TCP segmentation problems in order to highlight bugs in IDSs. For example, they noted that if overlapping fragments are sent with different data, some systems prefer the data from the first fragment(WinNT, Solaris), whereas others keep the data from the last fragment (Linux, BSD). The NIDS has no way of knowing which the endnode will accept, and may guess wrong. Their TCP connection analysis was even more in depth, discussing ways of "de-synchronizing" TCP connections, which are much more fragile than one would think. Again, the IDS cannot correctly model all possible TCP/IP stack behavior and figure out what the end-node will accept as data. TCP also has the overlap problems that IP fragmentation has. For example, intrusion detection systems might accept the first segment and ignore later segments, but most hosts accept the later segmetns. They ran tests against various intrusion detection systems in order to figure out if they could evade intrusion detection systems. Their results were dismal -- one major intrusion detection system could be completely evaded simply by fragmenting packets, others could be thrown off by "desynchronizing" from the data the end-node would accept. 9.9 Tools The following tools may help in evaluating IDS systems for these problems. Anzen NIDSbench http://www.anzen.com/research/nidsbench/. Contains the "fragrouter" that forces all traffic to fragment, which demonstrates how easy it is for hackers/crackers to do the same in order to evade intrusion detection. This accepts incoming traffic then fragments it according to various rules (IP fragmentation with various sizes and overlap, TCP segmentation again with various sizes and overlaps, TCP insertion in order to de-synchronize the connection, etc.). Also contains the "tcpreplay" program, which dumps high loads onto an Ethernet segment in order to veriy a NIDS can keep up. CASL NAI's CyberCop Scanner comes with CASL built in. This was used in the Insertion/Evasion paper above to carry out validation tests. It allows scripting of low-level TCP/IP packets. Some scripts for CASL are at: http://www.roses-labs.com/labs/labs.htm 10. Misc. 10.1 What are some standardization/interoperability efforts? 10.1.1 COAST audit trails format A much more narrowly defined effort that solves a specific problem. Hasn't produce proposals yet. See http://www.cs.purdue.edu/coast/projects/audit-trails-format.html 10.1.2 Universal Format for Logger Messages See http://www.ietf.org/internet-drafts/draft-abela-ulm-04.txt 10.1.3 IETF Intrusion Detection Working Group Charter: http://www.ietf.org/html.charters/idwg-charter.html Archive: http://www.semper.org/idwg-public/ Subscribe: http://www.ticm.com/kb/faq/[email protected] 10.1.4 CIDF (Common Intrusion Detection Framework) Has specified a lisp-like format for messages between "Event Generators", "Event Analyzers", "Event Databases", and "Response Units". Currently very theoretical with little industry input. 10.1.5 SAF (Security Advisory Format) An attempt to standardize security advisories, such as those that come from CERT, the FBI, etc. http://www.ietf.org/internet-drafts/draft-debeaupuis-saf-00.txt 10.1.6 Mitre's CVE effort "Common Vulnerabilities and Exposures (CVE)" - aims to standardize the names for all publicly known vulnerabilities and security exposures. While this is primarily an academic effort, it does have some vendor input from the major vulnerability assessment and IDS vendors. The CVE effort is best thought of as a "concordance": it allows people to sync up between the various advisories and IDS/scanner checks. It solves the problem that different products detect such things differently. For example, one intrusion detection system might detect a buffer overflow by examining the length of a field, and therefore map to multiple CVE entries and advisories for different products that have buffer overflows in the same field. Likewise, another IDS system might match the signatures of specific exploits (from published scripts) of a single vulnerability. Therefore, there might be one-to-many, many-to-one, or many-to-many mappings between any product or set of advisories. The CVE provides a concordance between various systems. http://www.cve.mitre.org/ Travaux Pratiques Intrusion Detection, Take Two November 15, 1999 Behind the Numbers How We Tested Intrusion Detection Focusing our tests on sensitivity to hostile activity, reporting capabilities and packet reassembly, we gauged how fierce an attack these systems could handle. By Greg Shipley It's not easy to test intrusion-detection systems. We spent several months in our Chicago lab putting these packages through their paces, using an assortment of attack tools, utilities and loadgeneration mechanisms. Our goal was to measure how accurately the systems detected hostile activity, how well they conveyed such activity to the user and how far we had to push them before they'd fall over. We also conducted some substantial testing of the systems' ability to reassemble fragmented packets. Although the problem with fragmentation has not been well-publicized, it is an extremely important issue. In 1998, Secure Networks (since acquired by Network Associates) published a paper detailing the problems that modern-day intrusion-detection systems had with fragmentation. A later article in Phrack Magazine revisited the issue (see www.phrack.com). The authors proved that by simply fragmenting the packets that carried their attacks, they could sneak past every commercial IDS on the market. Unfortunately, most vendors have ignored this issue, allowing skillful intruders to sneak past many IDS signatures. Earlier this year, a tool called "fragrouter" was released by Anzen's Dug Song that allowed for the easy fragmentation of all hostile traffic. Vendors have finally noticed. We used fragrouter in our testing, and sure enough, only Network Security Wizards' Dragon, Network Flight Recorder's NFR Intrusion Detection Appliance and Network Ice Corp.'s BlackIce detected the fragmented attacks. Of the three, only Dragon kept reassembling at higher speeds (see the measurements of fragmentation reassembly thresholds in "Network IDS Failure Points" at below to the right). Our Test Setup We deployed the intrusion-detection sensors on 500-MHz Compaq Pentium III systems with 256 MB of RAM. On the attack front (see "Testing Environment," above), we used a vast assortment of exploit scripts and reconnaissance tools available in the security community (for more information on these tools, see Packet Storm Internet Security Solutions' Web site at packetstorm.securify.com). We combined scanning and exploiting techniques in series, just as a real intruder would. Our arsenal included: version numbers. It also performs some CGI querying. his Perl script tests basic vulnerabilities in FTP and Web servers. Designed to set off IDS alarms, Chaff was used extensively in our fragmentation testing. -up port-scanner. -scan: This Perl script mutates nmap's scanning behavior. Most port-scanning is performed vertically; that is, one host is scanned for x ports, the next is scanned for x ports and so on. Wacky-scan performs "horizontal" scanning and introduces a greater amount of delay between recon packets. -IDS checking abilities. RFP's Whisker looks for a defined set of CGI programs known to have security flaws. In our tests, it was able to sneak past everything. -known stand-alone exploits and denial-ofservice attacks: LAND, teardrop, kod, Bind exploits, wu-ftpd exploits and imap/ pop exploits, among others. Our target servers were placed on a 100-Mbps shared Ethernet segment with two entry points: one from the Internet and one from a WAN connection. We deployed an assortment of BSD, IBM AIX, Linux, Windows 95/98 and NT and Solaris machines. We then added an assortment of load-generating machines using Coffee Computing's FileMetric 1.2, Ganymede Software's Chariot and RND Network's Webload. We had to be careful with load generation because of the issues surrounding fragmentation and TCP sequencing, which only some products track. If the IDS sees an attack or packet go by with the same TCP sequence, it will ignore that intruder, which would nullify any attempts at fair testing. Therefore, we couldn't rely on some of the more basic load-generation and replay tools. Our first round of testing had one goal: Make sure the intrusion-detection systems caught just what they claimed they would. On an idle network, these products perform almost flawlessly--but no one uses them on an idle network. Our second round introduced varying levels of traffic using Chariot. (See the measurements for start of inspection failure in "Network IDS Failure Points" to the right.) After about 40 Mbps, several products began dropping frames. For example, Cisco Systems' NetRanger stopped detecting our Winnuke attacks (only seven packets), but continued to pick up our ftp exploits. However, at 80 percent utilization (at approximately 12,000 packets per second) many started failing horribly--they stopped detecting almost everything. Our third round got flat-out nasty. We brought in fragrouter to validate vendors' packet reassembly claims, and things got ugly. Machines began rebooting. Axent Technologies' NetProwler tossed Dr. Watson at us religiously. CyberSafe Corp.'s Centrax was crashing at random intervals. Of the networkbased systems, only the machines running Internet Security Systems' RealSecure, BlackIce and Dragon did not crash or reboot at some point during the testing. Greg Shipley is a Chicago-based consultant. Send your comments on this article to him at [email protected]. CIDF Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection Thomas H. Ptacek mailto:[email protected] Timothy N. Newsham mailto:[email protected] Secure Networks, Inc. January, 1998 "Not everything that is counted counts, and not everything that counts can be counted." Albert Einstein ". . . yes, a game where people throw ducks at balloons, and nothing is what it seems. .." Homer J. Simpson Abstract All currently available network intrusion detection (ID) systems rely upon a mechanism of data collection---passive protocol analysis---which is fundamentally flawed. In passive protocol analysis, the intrusion detection system (IDS) unobtrusively watches all traffic on the network, and scrutinizes it for patterns of suspicious activity. We outline in this paper two basic problems with the reliability of passive protocol analysis: (1) there isn't enough information on the wire on which to base conclusions about what is actually happening on networked machines, and (2) the fact that the system is passive makes it inherently "fail¡open," meaning that a compromise in the availability of the IDS doesn't compromise the availability of the network. We define three classes of attacks which exploit these fundamental problems---insertion, evasion, and denial of service attacks --- and describe how to apply these three types of attacks to IP and TCP protocol analysis. We present the results of tests of the efficacy of our attacks against four of the most popular network intrusion detection systems on the market. All of the ID systems tested were found to be vulnerable to each of our attacks. This indicates that network ID systems cannot be fully trusted until they are fundamentally redesigned. 1 Introduction Intrusion detection is a security technology that attempts to identify and isolate ``intrusions'' against computer systems. Different ID systems have differing classifications of ``intrusion''; a system attempting to detect attacks against web servers might consider only malicious HTTP requests, while a system intended to monitor dynamic routing protocols might only consider RIP spoofing. Regardless, all ID systems share a general definition of ``intrusion'' as an unauthorized usage of or misuse of a computer system. Intrusion detection is an important component of a security system, and it complements other security technologies. By providing information to site administration, ID allows not only for the detection of attacks explicitly addressed by other security components (such as firewalls and service wrappers), but also attempts to provide notification of new attacks unforeseen by other components. Intrusion detection systems also provide forensic information that potentially allow organizations to discover the origins of an attack. In this manner, ID systems attempt to make attackers more accountable for their actions, and, to some extent, act as a deterrent to future attacks. 1.1 The CIDF Model of Intrusion Detection Systems There are many different ID systems deployed world-wide, and almost as many different designs for them. Because there are so many different ID systems, it helps to have a model within which to consider all of them. The Common Intrusion Detection Framework (CIDF)[1] defines a set of components that together define an intrusion detection system. These components include event generators (``E-boxes''), analysis engines (``A-boxes''), storage mechanisms (``D-boxes''), and even countermeasures (``C-boxes''). A CIDF component can be a software package in and of itself, or part of a larger system. Figure 1 shows the manner in which each of these components relate. The purpose of an E-box is to provide information about events to the rest of the system. An ``event'' can be complex, or it can be a low-level network protocol occurrence. It need not be evidence of an intrusion in and of itself. E-boxes are the sensory organs of a complete IDS--- without E-box inputs, an intrusion detection system has no information from which to make conclusions about security events. A-boxes analyze input from event generators. A large portion of intrusion detection research goes into creating new ways to analyze event streams to extract relevant information, and a number of different approaches have been studied. Event analysis techniques based on statistical anomaly detection[2], graph analysis[3], and even biological immune system models[4] have been proposed. E-boxes and A-boxes can produce large quantities of data. This information must be made available to the system's operators if it is to be of any use. The D-box component of an IDS defines the means used to store security information and make it available at a later time. Figure 1: CIDF component relationships Many ID systems are designed only as alarms. However, most commercially available ID systems are equipped with some form of countermeasure (C-box) capability, ranging from shutting down TCP connections to modifying router filter lists. This allows an IDS to try to prevent further attacks from occurring after initial attacks are detected. Even systems that don't provide C-box capabilities can be hooked into home-brewed response programs to achieve a similar effect. 1.2 Network Intrusion Detection and Passive Analysis Many ID systems are driven off of audit logs provided by the operating system, detecting attacks by watching for suspicious patterns of activity on a single computer system. This type of IDS is good at discerning attacks that are initiated by local users, and which involve misuse of the capabilities of one system. However, these ``host based'' (and multi-host) intrusion detection systems have a major shortcoming: they are insulated from network events that occur on a low level (because they only interpret high-level logging information). Network intrusion detection systems are driven off of interpretation of raw network traffic. They attempt to detect attacks by watching for patterns of suspicious activity in this traffic. Network ID systems are good at discerning attacks that involve lowlevel manipulation of the network, and can easily correlate attacks against multiple machines on a network. It's important to understand that while network ID has advantages over host-based ID, it also has some distinct disadvantages. Network ID systems are bad at determining exactly what's occurring on a computer system; hostbased ID systems are kept informed by the operating system as to exactly what's happening. It is probably impossible to accurately reconstruct what is happening on a system by watching ``shell'', ``login'', and ``telnet'' sessions. Network ID systems work by examining the contents of actual packets transmitted on the network. These systems parse packets, analyzing the protocols used on the network, and extract relevant information from them. This is typically accomplished by watching the network passively and capturing copies of packets that are transmitted by other machines. Figure 2: An example network topology using a passive monitor Passive network monitors take advantage of ``promiscuous mode'' access. A promiscuous network device, or ``sniffer'', obtains copies of packets directly from the network media, regardless of their destination (normal devices only read packets addressed to them). Figure 2 shows a simplified network topology in which a passive network monitor has been deployed. Passive protocol analysis is useful because it is unobtrusive and, at the lowest levels of network operation, extremely difficult to evade. The installation of a sniffer does not cause any disruption to the network or degradation to network performance. Individual machines on the network can be (and usually are) ignorant to the presence of sniffer. Because the network media provides a reliable way for a sniffer to obtain copies of raw network traffic, there's no obvious way to transmit a packet on a monitored network without it being seen. 1.3 Signature Analysis The question of what information is relevant to an IDS depends upon what it is trying to detect. For a system that is monitoring DNS traffic, the names of the hosts being queried for (and the responses to these queries) might be relevant. For a system attempting to detect attacks against FTP servers, the contents of all TCP connections to the FTP port would be interesting. Some attacks can be discerned simply by parsing IP packets; an attempt to circumvent a packet filter using IP fragments is clearly observable simply by examining the fragment offset fields of individual IP fragments. Other attacks occur over multiple packets, or must be interpreted outside the context of the actual protocol (for instance, a DNS query might only be relevant if it involves a certain host). Figure 3: CIDF model of a network IDS Most ID systems identify such attacks using a technique called ``signature analysis'' (also called ``misuse detection''). Signature analysis simply refers to the fact that the ID system is programmed to interpret a certain series of packets, or a certain piece of data contained in those packets, as an attack. For example, an IDS that watches web servers might be programmed to look for the string ``phf'' as an indicator of a CGI program attack. Most signature analysis systems are based off of simple pattern matching algorithms. In most cases, the IDS simply looks for a substring within a stream of data carried by network packets. When it finds this substring (for example, the ``phf'' in ``GET /cgi-bin/phf?''), it identifies those network packets as vehicles of an attack. Signature analysis and passive protocol analysis together define the event generation and analysis techniques used by the majority of commercially available ID systems. Figure 3 shows how these components fit into the CIDF model. For simplicity's sake, the remainder of this paper refers to systems that work like this as ``network ID systems.'' 1.4 The Need for Reliable Intrusion Detection Because of its importance within a security system, it is critical that intrusion detection systems function as expected by the organizations deploying them. In order to be useful, site administration needs to be able to rely on the information provided by the system; flawed systems not only provide less information, but also a dangerously false sense of security. Moreover, the forensic value of information from faulty systems is not only negated, but potentially misleading. Given the implications of the failure of an ID component, it is reasonable to assume that ID systems are themselves logical targets for attack. A smart intruder who realizes that an IDS has been deployed on a network she is attacking will likely attack the IDS first, disabling it or forcing it to provide false information (distracting security personnel from the actual attack in progress, or framing someone else for the attack). In order for a software component to resist attack, it must be designed and implemented with an understanding of the specific means by which it can be attacked. Unfortunately, very little information is publicly available to IDS designers to document the traps and pitfalls of implementing such a system. Furthermore, the majority of commercially available ID systems have proprietary, secret designs, and are not available with source code. This makes independent third-party analysis of such software for security problems difficult. The most obvious aspect of an IDS to attack is its ``accuracy''. The ``accuracy'' of an IDS is compromised when something occurs that causes the system to incorrectly identify an intrusion when none has occurred (a ``false positive'' output), or when something occurs that causes the IDS to incorrectly fail to identify an intrusion when one has in fact occurred (a ``false negative''). Some researchers[5] discuss IDS failures in terms of deficiencies in ``accuracy'' and ``completeness'', where ``accuracy'' reflects the number of false positives and ``completeness'' reflects the number of false negatives. Other attacks might seek to disable the entire system, preventing it from functioning effectively at all. We say that these attacks attempt to compromise the ``availability'' of the system. 1.5 Points of Vulnerability in ID Systems Each component identified by the CIDF model has unique security implications, and can be attacked for different reasons. As the only inputs of raw data into the system, E-boxes act as the eyes and ears of an IDS. An attack against the event generation capabilities of an IDS blinds it to what's actually happening in the system it's monitoring. For example, an attack against the E-box of a network IDS could prevent it from obtaining packets off the network, or from appropriately decoding these packets. Some intrusion detection systems rely on sophisticated analyses to provide security information. In such systems, the reliability of the A-box components used is important because an attacker that knows how to fool them can evade detection --- and complicated analytical techniques may provide many avenues of attack. On the other hand, overly simplistic systems may fail to detect attackers that intentionally mask their attacks with complex, coordinated system interactions from multiple hosts[6]. The need for reliable data storage is obvious. An attacker that can subvert the D-box components of an IDS can prevent it from recording the details of her attack; poorly implemented data storage techniques can even allow sophisticated attackers to alter recorded information after an attack has been detected, eliminating its forensic value. The C-box capability can also be attacked. If a network relies on these countermeasures for protection, an attacker who knows how to thwart the C-box can continue attacking the network, immune to the safety measures employed by the system. More importantly, countermeasure capabilities can be fooled into reacting against legitimate usage of the network --- in this case, the IDS can actually be turned against the network using it (often un-detectably). It is apparent that there are many different points at which an intrusion detection system can be attacked. A comprehensive treatment of all potential vulnerabilities is far outside the scope of this paper. Rather than attempting to document general problems common to all ID systems, we focus on a specific class of attacks against certain types of intrusion detection systems. There exist several serious problems with the use of passive protocol analysis as an event-generation source for signature-analysis intrusion detection systems. This paper documents these problems, presents several attacks that exploit them to allow an attacker to evade detection by ID systems, and verifies their applicability to the most popular commercial ID systems on the market. 2 Problems with Network ID Systems Our work defines two general problems with network intrusion detection: first, that there is insufficient information available in packets read off the wire to correctly reconstruct what is occurring inside complex protocol transactions, and next, that ID systems are inherently vulnerable to denial of service attacks. The first of these problems reduces the accuracy of the system, and the second jeopardizes its availability. 2.1 Insufficiency of Information on the Wire A network IDS captures packets off the wire in order to determine what is happening on the machines it's watching. A packet, by itself, is not as significant to the system as the manner in which the machine receiving that packet behaves after processing it. Network ID systems work by predicting the behavior of networked machines based on the packets they exchange. The problem with this technique is that a passive network monitor cannot accurately predict whether a given machine on the network is even going to see a packet, let alone process it in the expected manner. A number of issues exist which make the actual meaning of a packet captured by an IDS ambiguous. A network IDS is typically on an entirely different machine from the systems it's watching. Often, the IDS is at a completely different point on the network. The basic problem facing a network IDS is that these differences cause inconsistencies between the ID system and the machines it watches. Some of these discrepancies are the results of basic physical differences, others stem from different network driver implementations. For example, consider an IDS and an end-system located at different places on a network. The two systems will receive any given packet at different points in time. This difference in time is important; during the lag, something can happen on the end-system that might prevent it from accepting the packet. The IDS, however, has already processed the packet---thinking that it will be dealt with normally at the end-system. Consider an IP packet with a bad UDP checksum. Most operating systems will not accept such a packet. Some older systems might. The IDS needs to know whether every system it watches will accept such a packet, or it can end up with an inaccurate reconstruction of what happened on those machines. Some operating systems might accept a packet that is obviously bad. A poor implementation might, for example, allow an IP packet to have an incorrect checksum. If the IDS doesn't know this, it will discard packets that the endsystem accepts, again reducing the accuracy of the system. Even if the IDS knows what operating system every machine on the network runs, it still might not be able to tell just by looking at a packet whether a given machine will accept it. A machine that runs out of memory will discard incoming packets. The IDS has no easy way to determine whether this is the case on the end-system, and thus will assume that the end-system has accepted the packet. CPU exhaustion and network saturation at the end-system can cause the same problem. Together, all these problems result in a situation where the IDS often simply can't determine the implications of a packet merely by examining it; it needs to know a great deal about the networking behavior of the end-systems that it's watching, as well as the traffic conditions of their network segments. Unfortunately, a network IDS doesn't have any simple way of informing itself about this; it obtains all its information from packet capture. 2.2 Vulnerability to Denial of Service A ``denial of service'' (DOS) attack is one that is intended to compromise the availability of a computing resource. Common DOS attacks include ping floods and mail bombs --- both intended to consume disproportionate amounts of resources, starving legitimate processes. Other attacks are targeted at bugs in software, and are intended to crash the system. The infamous ``ping of death'' and ``teardrop'' attacks are examples of these. Denial of service attacks can be leveraged to subvert systems (thus compromising more than availability) as well as to disable them. When discussing the relevance of DOS attacks to a security system, the question of whether the system is ``fail-open'' arises. A ``fail-open'' system ceases to provide protection when it is disabled by a DOS attack. A ``fail-closed'' system, on the other hand, leaves the network protected when it is forcibly disabled. The terms ``fail-open'' and ``fail-closed'' are most often heard within the context of firewalls, which are access-control devices for networks. A fail-open firewall stops controlling access to the network when it crashes, but leaves the network available. An attacker that can crash a fail-open firewall can bypass it entirely. Good firewalls are designed to ``fail-closed'', leaving the network completely inaccessible (and thus protected) if they crash. Network ID systems are passive. They do not control the network or maintain its connectivity in any way. As such, a network IDS is inherently fail-open. If an attacker can crash the IDS or starve it of resources, she can attack the rest of the network as if the IDS wasn't even there. Because of the obvious susceptibility to DOS attacks that network ID systems have, it's important that they be fortified against them. Unfortunately, denial of service attacks are extremely difficult to defend against. The resource starvation problem is not easily solvable, and there are many different points at which the resources of an IDS can be consumed. Attacks that crash the IDS itself are easily fixed, but finding all such vulnerabilities is not easily done. 3 Attacks We discuss in this paper three different types of attacks against sniffer-based network ID systems. Two of them attempt to subtly thwart protocol analysis, preventing the signature-recognition system from obtaining adequate information from which to draw conclusions. The third leverages simple resourcestarvation attacks to disrupt or disable the entire system. All of our attacks involve an attacker that is specifically manipulating her network usage to create abnormal, or even pathological, streams of traffic. In most cases, they require low-level packet forgery. However, unlike normal ``spoofing'' attacks, these techniques are simplified by the fact that the attacker is manipulating her own sessions, not attempting to disrupt those of other users. Two of our attacks are new1, and specific to traffic analysis systems (though not necessarily to intrusion detection). Both are mechanisms by which an attacker can fool a protocol analyzer into thinking that something is (or is not) happening on the network. The first of these, which we call ``insertion'', involves an attacker stuffing the system with subtly invalid packets; the second, ``evasion'', involves exploiting inconsistencies between the analyzer and an end system in order to slip packets past the analyzer. 3.1 Insertion An IDS can accept a packet that an end-system rejects. An IDS that does this makes the mistake of believing that the end-system has accepted and processed the packet when it actually hasn't. An attacker can exploit this condition by sending packets to an end-system that it will reject, but that the IDS will think are valid. In doing this, the attacker is ``inserting'' data into the IDS --- no other system on the network cares about the bad packets. We call this an ``insertion'' attack, and conditions that lend themselves to insertion attacks are the most prevalent vulnerabilities in the intrusion detection systems we tested. An attacker can use insertion attacks to defeat signature analysis, allowing her to slip attacks past an IDS. To understand why insertion attacks foil signature analysis, it's important to understand how the technique is employed in real ID systems. For the most part, ``signature analysis'' uses patternmatching algorithms to detect a certain string within a stream of data. For instance, an IDS that tries to detect a PHF attack will look for the string ``phf'' within an HTTP ``GET'' request, which is itself a longer string that might look something like ``GET /cgi-bin/phf?''. The IDS can easily detect the string ``phf'' in that HTTP request using a simple substring search. However, the problem becomes much more difficult to solve when the attacker can send the same request to a webserver, but force the IDS to see a different string, such as ``GET /cgibin/pleasedontdetecttthisforme?''. The attacker has used an insertion attack to add ``leasedontdetectt'', ``is'', and ``orme'' to the original stream. The IDS can no longer pick out the string ``phf'' from the stream of data it observes. Figure 4 gives a simple example of the same attack. An attacker confronts the IDS with a stream of 1character packets (the attacker-originated data stream), in which one of the characters (the letter `X') will be accepted only by the IDS. As a result, the IDS and the end system reconstruct two different strings. In general, insertion attacks occur whenever an IDS is less strict in processing a packet than an end-system. An obvious reaction to this problem might be to make the IDS as strict as possible in processing packets read off the wire; this would minimize insertion attacks. However, another severe problem (``evasion'' attacks) occurs when this design approach is taken. Figure 4: Insertion of the letter 'X' 3.2 Evasion An end-system can accept a packet that an IDS rejects. An IDS that mistakenly rejects such a packet misses its contents entirely. This condition can also be exploited, this time by slipping crucial information past the IDS in packets that the IDS is too strict about processing. These packets are ``evading'' the scrutiny of the IDS. We call these ``evasion'' attacks, and they are the easiest to exploit and most devastating to the accuracy of an IDS. Entire sessions can be carried forth in packets that evade an IDS, and blatantly obvious attacks couched in such sessions will happen right under the nose of even the most sophisticated analysis engine. Evasion attacks foil pattern matching in a manner quite similar to insertion attacks. Again, the attacker causes the IDS to see a different stream of data than the end-system --- this time, however, the endsystem sees more than the IDS, and the information that the IDS misses is critical to the detection of an attack. In the insertion attack we mentioned above, the attacker sends an HTTP request, but muddies its contents on the IDS with additional data that make the request seem innocuous. In an evasion attack, the attacker sends portions of the same request in packets that the IDS mistakenly rejects, allowing her to remove parts of the stream from the ID system's view. For example, the original request could become ``GET /gin/f'', which would have no meaning to most ID systems. Figure 5 shows the same type of attack. Figure 5: Evasion of the letter 'A' 3.3 Real World Insertion and Evasion In reality, insertion and evasion attacks are not this easy to exploit. An attacker usually does not have the luxury of injecting arbitrary characters into a stream. However, these attacks can come into play well before pattern matching becomes a consideration. One example of a place in which insertion attacks can be leveraged at a very low level is stream reassembly. To understand how insertion and evasion play into reassembly, we'll first explain what we mean by the term. Many network protocols are simple and easy to analyze. They involve one system sending a single request to another, and waiting for that system to respond. For example, a network monitor can easily determine the purpose of a single UDP DNS query by looking at one packet. Other protocols are more complex, and require consideration of many individual packets before a determination can be made about the actual transaction they represent. In order for a network monitor to analyze them, it must statefully monitor an entire stream of packets, tracking information inside each of them. For example, in order to discover what is happening inside of a TCP connection, the monitor must attempt to reconstruct the streams of data being exchanged over the connection. Protocols like TCP allow any amount of data (within the limits of the IP protocol's maximum packet size) to be contained in each discrete packet. A collection of data can be transmitted in one packet, or in a group of them. Because they can arrive at their destination out of order, even when transmitted in order, each packet is given a number that indicates its place within the intended order of the stream. This is commonly referred to as a ``sequence number'', and we call collections of packets marked with sequence numbers ``sequenced''. Figure 6: Sequenced reassembly The recipient of a stream of TCP packets has the responsibility of re-ordering and extracting the information contained in each of them, reconstructing the original collection of data that the sender transmitted. The process of taking a collection of unordered, sequenced packets and reconstructing the stream of data they contain is termed ``reassembly''. Figure 6 shows an example of how a stream of data tagged with sequence numbers might be reassembled. Reassembly issues manifest themselves at the IP layer, as well; IP defines a mechanism, called ``fragmentation'', that allows machines to break individual packets into smaller ones. Each individual fragment bears a marker that denotes where it belongs in the context of the original packet; this field is called the ``offset''. IP implementations must be able to accept a stream of packet fragments and, using their offsets, reassemble them into the original packet. Insertion attacks disrupt stream reassembly by adding packets to the stream that would cause it to be reassembled differently on the end-system---if the end system accepted the disruptive packets. The inserted packets could change the sequencing of the stream (consuming hundreds of sequence numbers), preventing the IDS from dealing properly with the valid packets that follow it. Packets can be inserted that overlap old data, rewriting the stream on the IDS. And, in some situations, packets can be inserted that simply add content to the stream which changes its meaning. Evasion attacks disrupt stream reassembly by causing the IDS to miss parts of it. The packets lost by the IDS might be vital for the sequencing of the stream; the IDS might not know what to do with the packets it sees after the evasion attacks. In many situations, it's fairly simple for the attacker to create an entire stream that eludes the IDS. 3.4 Ambiguities In many cases, defending against insertion and evasion attacks is easy. The behavior that an attacker is exploiting to insert packets into the IDS is, in these cases, simply wrong. The IDS might not be verifying a checksum or examining a header field correctly; fixing the problem merely involves modifying the IDS to check these things. Section Info Needed Ambiguity Section Network Topology IP TTL field may not be large enough for the number of 4.1.1 hops to the destination Section 4.1.1 Network Topology Packet may be too large for a downstream link to handle without fragmentation Section 4.1.2 Destination Configuration Destination may be configured to drop source-routed packets Section 4.3.1 Destionation OS Destination may time partially received fragments out differently depending on its OS Section 4.3.3 Destination OS Destination may reassemble overlapping fragments differently depending on its OS Section 5.2.2 Destination OS Destination host may not accept TCP packets bearing certain options Section 5.2.2 Destination OS Destination may implement PAWS and silently drop packets with old timestamps Section 5.4.3 Destination OS Destination may resolve conflicting TCP segments differently depending on its OS Section 5.5.1 Destination OS Destination may not check sequence numbers on RST messages Figure 7: Ambiguities identified in this paper In some cases, however, fixing the problem is not easy. There are situations in which a network monitor cannot determine by looking at a packet whether it will be accepted. This can be due to varying end-system behavior (one operating system might process a packet differently from another). Basic network ambiguities can also cause problems. In some cases, unless the IDS knows exactly what path the packet is going to take to get to its destination, it won't know whether it will actually arrive there. Attacks that exploit these kinds of problems cannot easily be defended against unless the IDS has a source of information that resolves the ambiguity. If the IDS knows what operating system is running on the destination system, it may be able to discern whether a packet is acceptable to that system. If the IDS can reliably track the topology of the network, it may be be able to determine whether or not a packet will ever be received by an end-system. In general, we say a traffic analysis problem is ``ambiguous'' if an important conclusion about a packet cannot be made without a secondary source of information. Figure 7 shows the ambiguities this paper identifies. Each ambiguity can potentially be resolved if the IDS has certain information (either a reliable view of the topology of the network, the configuration of the end-systems it's watching, or the OS and version of those systems). This is, of course, not an exhaustive list. The next two sections of this paper provide examples of how insertion and evasion attacks affect protocol analysis at the network (IP) and transport (TCP) layers. These sections provide real-world examples of attacks on IP network ID systems in great detail, working from the basic attacks we've defined here. 4 Network¡Layer Problems We begin our discussion of specific, observable problems in network intrusion detection systems at the IP layer. An insertion or evasion problem occurring within the IP processing of an IDS affects all higher levels of processing as well; a problem that allows an attacker to insert an arbitrary IP packet allows that attacker, by extension, to insert an arbitrary (well-formed) UDP or ICMP packet. It is thus extremely important that an ID system be immune to insertion or evasion attacks on this level. Line Description 229 No IP addresses set yet 232 Received packet is too short to be an IP datagram. 240 Received packet is too short to be an IP datagram. 247 IP version isn't `4' 253 IP ``header length'' field too small 257 IP ``header length'' is set larger than the entire packet 269 Bad header checksum 278 IP ``total length'' field is shorter than ``header length'' 348 Packet has IP options and ip dooptions() returns an error 437 Not addressed to this host 450 Too small to be a fragment Figure 8: FreeBSD 2.2 ip input() packet discard points (netinet/ip input.c) 4.1 Simple Insertion Attacks There are many ways that an attacker can send an IP packet that only an IDS will accept. We collected candidate methods by examining the IP driver source code of the 4.4BSD operating system. Any condition that causes 4.4BSD to drop a received packet must be accounted for in an intrusion detection system. An inconsistency between 4.4BSD and an IDS represents a potential insertion or evasion attack against that IDS. Figure 8 lists all the points in FreeBSD 2.2's ``ip input'' routine that discard received datagrams. 4.1.1 Bad Header Fields The easiest way for an IP datagram to be discarded by an endpoint is for it to have an invalid header field. The header fields of an IP packet are described in RFC731[7]. One problem with attempting to use packets with bad header fields for insertion attacks is that doing so often prevents the packet from being forwarded by Internet routers. This makes it difficult to use such packets for an attack, unless the IDS is situated on the same LAN as the attacker (in which case the attacker can already manipulate the IDS via packet forgery). A good example is the ``version'' field; assigning a value other than 4 to this field will prevent the packet from being routed. Another problem with using bad header fields is the fact that some of them need to be correct for the packet to be parsed correctly (``correctly'' here meaning ``in the manner intended by the attacker''). For instance, incorrectly specifying the size of the IP packet itself, or the size of its header, may prevent the IDS from locating the transport layer of the packet. One IP header field that is easy to neglect is the checksum. It may seem unnecessary for an IDS to verify the accuracy of the checksum on each captured IP packet; however, a datagram with a bad checksum will not be processed by most IP implementations. An IDS that does not reject packets with bad checksums is thus vulnerable to a very simple insertion attack. A harder problem to solve is the TTL field. The TTL (time to live) field of an IP packet dictates how many ``hops'' a packet can traverse on its way to its destination. Every time a router forwards a packet, it decrements the TTL. When the TTL runs out, the packet is dropped. If the IDS is not on the same network segment as the systems it watches, it is possible to send packets that only the IDS will see by setting the TTL just long enough for the packet to reach the IDS, but too short for the packet to actually arrive at its destination.[17] A similar problem occurs in relation to the ``Don't Fragment'' (DF) flag in the IP header. The DF flag tells forwarding devices not to split a packet up into fragments when the packet is too large to be forwarded, but instead to simply drop the packet. If the maximum packet size of the network the IDS is on is larger than that of the systems it watches, an attacker can insert packets by making them too large for the destination network and setting the DF bit.[17] Both of these problems can lead to ambiguities that are only solveable if the IDS has an intimate knowledge of the topology of the network it is monitoring. 4.1.2 IP Options The IP checksum problem is fairly simple to solve; an IDS can reasonably assume that if the checksum is wrong, the datagram will not be accepted by the endsystem it's addressed to. A trickier problem is that of parsing IP options. This is more likely to vary between hosts, and the interpretation of options requires specialized processing. For example, most end-systems will drop a packet that is ``strict source routed''[9] when the host's own address is not in the specified source route. It is reasonable for an IDS to drop such packets, avoiding an insertion attack. However, many operating systems can be configured to automatically reject source routed packets. Unless the IDS knows whether a source-routed packet's destination rejects such packets, the correct action to take is ambiguous. Examination of source route options on IP packets may seem like an obvious requirement for a security program. However, there are other options that must be accounted for that are less obviously relevant. For instance, the ``timestamp'' option requests that certain recipients of the datagram place a timestamp within the packet. The code that processes the timestamp option can be forced to discard the packet (if the option is malformed). If the sniffer does not validate the timestamp option in the same manner as the end systems it watches, the inconsistency can be exploited. Figure 9 lists all the places in which FreeBSD Line Option Description 837 Any Bad option length 858 Source Route Option offset is less than `4' 866 Strict Source Route This host is not one of the listed hops 886 Source Route This host is configured to drop source routed packets 911 Source Route No route to next hop in route 927 Record Route Option offset is less than `4' 943 Record Route No route to next hop 957 Timestamp Option length is too short 960 Timestamp Timestamp recording space is full and the overflow counter has wrapped back to zero 971 Timestamp Not enough record space to hold timestamp and IP address 985 Timestamp Not enough record space to hold timestamp and IP address 995 Timestamp Bad timestamp type given Figure 9: FreeBSD 2.2 ip dooptions() packet discard points 2.2's option processing code discards incoming datagrams. Most IP option processing problems in the 4.4BSD option processing code results in the transmission of an ICMP error message, notifying the sender of the errant datagram of the problem. An IDS could potentially listen for such messages to determine whether an oddly-specified option is correct. This is not always reliable; some operating systems (Sun Solaris, for instance) will rate-limit ICMP, suppressing the error messages. Furthermore, tracking ICMP responses to datagrams bearing options requires the IDS to keep state for each IP packet; this will consume resources and potentially allow an attacker an avenue for a denial of service attack. 4.2 MAC Addresses Although obviously not an IP problem per se, the same implications for insertion attacks exist due to link-layer addressing. An attacker on the same LAN as a network monitor can direct link-layer frames to the IDS, without ever allowing the host specified as the IP destination to see the packet. If the attacker knows the link-layer address of the IDS, she can simply address her fake packet to the IDS. No other system on the LAN will process the packet, but, if the IDS doesn't check the MAC address on the received packet, it won't know this. Figure 10 shows an example of an attacker that inserts a character in the IDS by directing a packet to the IDS via the Ethernet link-layer. Figure 10: Insertion Attacks at the Link Layer Even if the attacker doesn't know the link-layer address of the network monitor, she can exploit the fact that the network monitor is operating in promiscuous mode by addressing the frame to a fake address. Again, unless the IDS verifies the destination address in the IP header against the correct link-layer address (and can do so reliably), it can be fooled by falsely-addressed link-layer frames. 4.3 IP Fragmentation IP packets can be broken into smaller packets, and reassembled at the destination. This is termed ``fragmentation'', and is an integral part of the IP protocol. IP fragmentation allows the same information to travel over different types of network media (which may have different packet size limits) without limiting the entire protocol to an arbitrary small maximum packet size. A detailed explanation of IP fragmentation can be found in Stevens[8], or in RFC791[9]. Because end-systems will reassemble a stream of IP fragments, it is important that a network monitor correctly reassemble fragments as well. An IDS that does not correctly reassemble fragments can be attacked simply by ensuring that all data is exchanged between machines using artificially fragmented packets. 4.3.1 Basic Reassembly Problems Streams of IP fragments usually arrive in order. The last fragment in a stream is clearly marked (the IP header contains a flag that specifies whether more fragments follow a given packet). However, even though it rarely happens, the protocol allows fragments to arrive in any arbitrary order. An end system must be able to reassemble a datagram from fragments that arrive out of order. Because fragments usually arrive in order, it's easy to make the mistake of assuming that they always will. An IDS that does not properly handle outof-order fragments is vulnerable; an attacker can intentionally scramble her fragment streams to elude the IDS. It's also important that the IDS not attempt to reconstruct packets until all fragments have been seen. Another easily made mistake is to attempt to reassemble as soon as the marked final fragment arrives. Another significant problem is the fact that received fragments must be stored until the stream of fragments can be reassembled into an entire IP datagram. An IDS can be attacked by flooding the network with partial, fragmented datagrams, which will never be completed. A naive IDS will run out of memory as it attempts to cache each fragment, since the fragmented packets are never completed. End-systems must deal with this problem as well. Many systems drop fragments based on their TTL, to avoid running out of memory due to over-full fragment queues. An IDS that eventually drops old, incomplete fragment streams must do so in a manner consistent with the machines it's watching, or it will be vulnerable to insertion (due to accepting fragment streams that end-systems have dropped already) or evasion (due to dropping fragments that end-systems have not yet discarded) attacks. 4.3.2 Overlapping Fragments It has long been known that there are serious security implications arising from interactions between fragmentation and network access control devices (like packet filters). Two well-known attacks involving fragmentation allow attackers to potentially evade packet filters by employing pathological fragment streams. The first of these attacks involves simply sending data using the smallest fragments possible; the individual fragments will not contain enough data to filter on. The second problem is far more relevant to ID systems. It involves fragmentation overlap, which occurs when fragments of differing sizes arrive out of order and in overlapping positions. If a fragment arriving at an end-station contains data that has already arrived in a different fragment, it is possible that the newly arrived data may overwrite some of the old data. This presents problems for an IDS. If the IDS does not handle overlapping fragments in a manner consistant with the systems it watches, it may, given a stream of fragments, reassemble a completely different packet than an endsystem in receipt of the same fragments. An attacker that understands the specific inconsistency between an end-system and an IDS can obscure her attack by couching data inside of overlapping fragment streams that will be reassembled differently on the two systems. Overlap resolution is further complicated by the fact that data from conflicting fragments is used differently depending on their positions. In some situations, conflicts are resolved in favor of the new data. In others, the old data is preferred and the new data is discarded. An IDS that does this incorrectly is vulnerable to evasion attacks. Figure 11 shows the different scenarios involved in fragmentation overlap. Figure 11: Forward and Reverse Overlap Operating System Overlap Behavior Windows NT 4.0 Always Favors Old Data 4.4BSD Favors New Data for Forward Overlap Linux Favors New Data for Forward Overlap Solaris 2.6 Always Favors Old Data HP-UX 9.01 Favors New Data for Forward Overlap Irix 5.3 Favors New Data for Forward Overlap Figure 12: IP fragment overlap behavior for various OS's 4.3.3 Effects of End¡System Fragmentation Bugs ID systems aren't the only IP implementations that can incorrectly handle overlapping fragments. The IP drivers in end-systems can have bugs as well. The complexity of IP fragment reassembly makes the existence of incorrect implementations quite likely. Unless the IDS knows exactly which systems have nonstandard drivers, it is incapable of accurately reconstructing what's happening on them. For example, Windows NT resolves overlapping fragments consistently in favor of the old data (we were unable to create a fragment stream that forced Window NT to rewrite a previously received fragment). This differs from 4.4BSD, which resolves conflicts as suggested by the standard (in favor of the new data in cases of forward overlap)[10]. Figure 12 gives examples of how several popular operating systems resolve overlap. The end result is that fragmentation reassembly is different on the endsystem depending on the operating system. Unless the IDS knows which OS the system is running, it will have absolutely no way of knowing what form of conflict resolution was performed, and thus no conclusive evidence of what was actually reassembled. 4.3.4 IP Options in Fragment Streams IP packets can bear options. When an IP packet is fragmented, the question arises as to whether the options from the original packet should be carried on all the fragments. RFC791[9] dictates that certain IP options are to be present in every fragment of a datagram (for example, the ``security'' option), and others must appear only in the first fragment. A strict implementation of IP could discard fragments that incorrectly present options. Many implementations do not. If the IDS doesn't behave exactly like the machines it's watching in this respect, it will be vulnerable to insertion and evasion attacks. 4.4 Forensic Information from IP Packets It is an unfortunate fact that the IP version 4 protocol is in no way authenticated. This poses some problems to ID systems attempting to collect evidence based on information seen in IP headers; anyone can forge an IP packet appearing to come from some arbitrary host. This problem is particularly severe with connectionless protocols. In connection-oriented protocols, a weak conclusion can be drawn as to the origin of a session based on whether a valid connection is created; the sequence numbers employed by protocols like TCP provide at least cursory assurance that the attack is originating at the address it appears to come from. An IDS can observe that a connection uses consistantly correct sequence numbers and have a reasonable assurance that it's not being blindly spoofed. Unfortunately, no such assurance exists with connectionless protocols; an attack against the DNS, for instance, could be sourced from any address on the net. It is important that operators of ID systems be aware of the questionable validity of the addressing information they're given by their system. 5 TCP Transport¡Layer Problems A large portion of the attacks detected by ID systems occur over TCP connections. This imposes the requirement that an IDS be able to reconstruct the flow of data passing through a stream of TCP packets. If the IDS can't do this in a manner consistent with end systems it's watching, it is vulnerable to attack. For normal TCP connections, initiated by innocuous network applications like ``telnet'', this is not difficult. Against an attacker, who is stretching the TCP protocol to its limits (and, in exploiting OS bugs, beyond those limits) to avoid detection, the problem is far more difficult. There are many different ways to implement a TCP connection monitor. Each has its advantages, and each has serious flaws. The lack of a canonical ``Right Way'' to process a captured stream of TCP packets is a major problem with network ID systems. 5.1 Definition of Terms TCP connection monitoring is a complicated subject. In order to simplify our discussion, we define several terms describing information used by the monitor to track and record information flowing through a TCP session. For the most part, these terms are synonymous with those used by the BSD TCP implementation. Every TCP connection has four identifiers (two for the client, two for the server) which distinguish it from any other connection on the network. These are the client (or source) and server (or destination) IP addresses, and the client and server TCP port numbers. Two connections cannot exist on the network that share these identifiers. We'll refer to this information as the ``connection parameters''. The TCP protocol specification (RFC793[12]) defines several ``states'' that any given connection can be in. In this paper, we refer only to states observable by an IDS (those involving the actual exchange of data between two hosts). The vast majority of all possible connections exist in the ``CLOSED'' state, meaning that no connection currently exists using those parameters. An active, established connection is said to be in ``ESTABLISHED'' state. We'll introduce other states when they become relevant to our discussion. TCP implements a reliable, sequenced stream protocol. By ``reliable'', we mean that each end of a connection can determine whether data it has sent was successfully received, and can do something to remedy the situation when it isn't. TCP is ``sequenced'' because it employs ``sequence numbers'' to determine where any piece of data represented in a packet belongs within a stream. In order for an IDS to reconstruct the information flowing through a TCP connection, it must figure out what sequence numbers are being used. We call the process that an IDS goes through to determine the current valid sequence numbers for a connection ``synchronization''. A scenario in which the IDS becomes confused about the current sequence numbers is termed ``desynchronization''. When an IDS is desynchronized from a connection, it cannot accurately reconstruct the data being passed through the connection. In many cases, ID systems become completely blinded (not reconstructing any data from the connection) when this occurs. Thus, a major goal of an attacker is to desynchronize the IDS from her connections. Along with sequence numbers, TCP tracks several other pieces of information about a connection. TCP defines a flow-control mechanism that prevents one side of a connection from sending too much data for the other side to process; this is tracked through each side's ``window''. TCP also allows for out-of-band data to be sent in a stream, using the ``urgent pointer''. This collection of state information can be represented internally on an endsystem in any manner. We refer to the abstract concept of the block of information that an implementation must manage to follow a single connection as a ``TCP control block'', or ``TCB''. A network IDS must maintain a TCB for every connection that it watches. 5.1.1 IDS State Transition TCBs are only useful for connections that are not (in fact) in CLOSED state. Because it would be infeasible for an IDS to maintain a TCB for every possible connection, any network IDS defines a mechanism by which TCBs can be created for newly detected connections, and destroyed for connections that are no longer relevant. In our discussion of IDS TCP problems, we isolate three different points at which the processing of a connection by an IDS can be subverted. These are TCB creation (the point at which an IDS decides to instantiate a new TCB for a detected connection), stream reassembly (the process an IDS uses to reconstruct a stream associated with an open TCB), and TCB teardown (the point at which the IDS decides to retire a TCB). Contributing to attacks against each of these three points are data insertion attacks, which can allow an attacker to confuse the IDS as to what data is actually arriving at the end-system. In some cases, such as within the context of stream reassembly, data insertion attacks make the reliable monitoring of a TCP session practically impossible; it is thus important the the IDS not be vulnerable to insertion attacks. This is not an easy goal to achieve. 5.2 Simple Insertion Attacks As with the IP protocol, there are several different ways in which a single packet can be inserted into an IDS. TCP input processing is complex, and there are many different cases that can cause a received packet to be dropped. As always, if an IDS doesn't process TCP packets in the same manner as the end-systems it's monitoring, it is potentially vulnerable to insertion attacks. As with our analysis of IP monitoring, we used the source code to the 4.4BSD kernel to obtain candidate cases for potential insertion attacks. Again, any point in 4.4BSD's tcp input() function that causes a received packet to be dropped without complete processing was identified as a possible problem. Figure 13 lists points in FreeBSD 2.2's tcp input() code where incoming segments are dropped. A TCP segment is acknowledged if the receiving system generates a message in response to the segment; when this occurs, we indicate whether this is via an RST or ACK message. The transmission of a message in response to a bad segment is significant because an IDS could potentially detect invalid segments by examining the manner in which they are acknowledged, though this is complicated both by resource and efficiency issues, as well as the potential for inconsistant behavior across different operating systems. 5.2.1 Malformed Header Fields Data from a TCP packet can be extracted and used in reassembly without looking at many of the header fields. This makes it dangerously easy to design a TCP session monitor that is vulnerable to packet insertion; it is important to validate the header fields of a TCP packet before considering its data. One very easily overlooked field is the ``CODE'', which determines the type of message being sent in a given TCP segment. The TCP code is specified as a series of binary flags. Certain combinations of these flags are invalid, and should result in a discarded packet. Additionally, many TCP implementations will not accept data in a packet that does not have the ``acknowledge'' (``ACK'') flag set. According to the TCP specification, TCP implementations are required to accept data contained in a SYN packet. Because this is a subtle and obscure point, some implementations may not handle this correctly. If an IDS doesn't consider data in a SYN packet, it is vulnerable to a trivial evasion attack; if it does, it may be vulnerable to insertion attacks involving incorrect end-system implementations. Another often overlooked TCP input processing issue is checksum computation. All TCP implementations are required to validate incoming packets with the Internet checksum. Many ID systems fail to perform this check; packets can be inserted into these systems simply by sending TCP segments with intentionally corrupt checksums. 5.2.2 TCP Options As in IP, it is important that the IDS process TCP options correctly. Unfortunately, processing of TCP options is significantly trickier than processing IP options. One reason for this is the fact that several TCP options have only recently been created (timestamp and window scale, for instance). Another is the fact that TCP specifies rules for when a TCP option can appear within the context of a connection. Certain options can be invalid in certain connection states. RFC1323[13] introduces two new TCP options designed to increase the reliability and performance of TCP in high-speed environments. With these new options came the possibility that TCP options could appear on packets that were not SYN segments, a departure from the previous convention. RFC1323 dictates that options can only appear in non-SYN segments if the option has been specified and accepted previously in that connection. Line Acknowledged? Condition 295 No Actual received packet too short 312 No Bad checksum 323 No Offset too Short (into TCP header) or too long 331 No Actual received packet too short 369 RST No listening process 382 RST No listening process 384 No Connection is in CLOSED state 404 No Packet other than SYN received in LISTEN state 409 RST ACK packet received in LISTEN state 423 No Can't track new connections 628 No Received RST packet in LISTEN state 630 RST ACK packet received in LISTEN state 632 No Any packet without SYN received in LISTEN state 639 No Broadcast or Multicast SYN received 643 No Out of resources 655 No in pcbconnect() failure 662 No Out of resources 773 No ACK packet, bad sequence numbers 789 No In SYN SENT state, received packet other than SYN 796 No In SYN SENT state, received packet has bad CC.ECHO 936 No In TIME WAIT state, packet has bad CC option 945 No Any other packet received in TIME WAIT state 979 ACK Bad timestamp (too old) 993 No In T/TCP, no CC or bad CC on non¡RST packet 1048 RST Listening user process has terminated 1087 ACK Packet is out of receive window 1156 No ACK bit not set on non¡SYN data packet 1175 RST ACK packet, bad sequence numbers 1234 No Duplicate ACK 1300 ACK ACK packet sent out of window 1443 ACK In TIME WAIT state, received ACK Figure 13: FreeBSD 2.2 tcp input() packet drop points (netinet/tcp input.c) Because certain TCP implementations may reject non-SYN segments containing options not previously seen, it's important that the IDS not blindly accept such a packet. On the other hand, some endsystems may simply ignore the bad options, but continue to process the packet; if the IDS doesn't correctly determine what the end-system has done, it will either be vulnerable to an insertion attack or another trivial packet evasion attack. Another concept defined by RFC1323 is PAWS, or ``protection against wrapped sequence numbers''. Systems implementing PAWS track timestamps on segments; if a segment is received that contains a timestamp echo that is older than some threshold time, it is dropped. An attacker can trivially create a TCP segment with an artificially low timestamp, which will cause PAWS-compliant TCP stacks to drop the packet without further processing. Not only does the IDS need to know whether the end-system supports PAWS, but it also needs to know what the end-system's threshold value for timestamps is. Without this information, an IDS may erroneously process invalid TCP segments, or, even worse, make an incorrect guess as to the validity of a segment and enable evasion attacks. 5.3 TCB Creation The first point at which TCP session monitoring can be subverted is in TCB creation. The TCB creation policies of an IDS determine the point at which it begins recording data for a given connection, as well as the initial state (sequence numbers, etc) used to synchronize the monitoring with the actual session. TCB creation is a troublesome issue. There are many different methods that can be employed to determine when to open a TCB, and none of the straightforward methods is without problems. Some techniques are obviously inferior to others, however, and it's important to indicate which these are. TCB creation establishes the initial state of a connection, including its sequence numbers; the ability to forge fake TCBs on the IDS can allow an attacker to desynchronize future connections that use the same parameters as the forged connection. TCB creation as a concept revolves around the TCP three-way handshake (or ``3WH''), which is an exchange of TCP packets between a client (the ``active opener'' of a connection) and server (the ``passive opener''). The 3WH establishes the initial sequence numbers used for that connection, along with any other parameters (the use of running timestamps, for instance) that may be important. There are very few options available to an end-system in implementing TCB creation; a TCB cannot be completely opened until a three-way handshake is completed successfully. Without the 3WH, the two ends of a connection have no agreed-upon sequence numbers to use, and will be unable to exchange data. An IDS, on the other hand, has many options. ID systems can attempt to determine the sequence numbers being used simply by looking at the sequence numbers appearing in TCP data packets (we refer to this as ``synching on data''), or it can rely entirely on the 3WH. Compromises can be made to either approach; information from a 3WH can be used, but not relied upon, by the IDS, and the IDS does not necessarily need to wait for an entire 3WH before opening a TCB. We attempt to outline all the straightforward mechanisms for establishing TCBs on an IDS here. This is by no means a complete list of all the ways this task can be accomplished, but these are the techniques that we expect to see utilized in typical ID systems. 5.3.1 Requiring Three¡Way Handshake The first decision for IDS designers to make is whether or not to rely completely on the three-way handshake for TCB initiation. An IDS that relies on the 3WH will not record data in a connection for which it did not observe a handshake. This has a few distinct disadvantages. The first and most obvious is the fact that the IDS will miss entirely any TCP connection for which it does not see the 3WH. This obviously presents problems at program initialization time (the IDS will only be able to see connections that start after it does), but also presents a serious opportunity for connection evasion by an attacker who can prevent the IDS from seeing the 3WH. Another problem occurs in combination with TCP reassembly. If an IDS uses the 3WH to determine the initial sequence numbers of a connection, and then validates data against those sequence numbers, it can potentially be tricked into desynchronization by an attacker who forges a realistic-looking (but fake) handshake. If the IDS records the sequence numbers from the handshake, a real connection, using different sequence numbers but the same parameters, will be undetectable as long as the attackercreated TCB is open. TCP options compound this problem. In order to correctly deal with TCP extensions such as PAWS, the IDS must see the three-way handshake (the handshake determines whether the use of certain options is legitimate with the connection). If the IDS fails to detect this, it will be vulnerable to insertion attacks against some operating systems (notably 4.4BSD). The Effects of Filtering on Handshake Detection Many security-conscious networks have network filtering in place that makes it difficult for a remote attacker to send packets to the network that have source addresses of machines behind the filter. This technique, which is referred to as ``inside-outside'' filtering or ``spoof-protection'', makes some attacks against TCB creation harder; the attacker, trying to trick the IDS into opening or desynchronizing a TCB, cannot easily forge server response packets. An IDS can take advantage of this by trusting packets that appear to originate from machines behind such filters (the IDS assumes that the presence of these filters makes forging such packets impossible). Trusted packets can be used as a reliable indicator of connection state. It's important to base the decision on whether to ``trust'' a packet off the source address on the packet, and not on the type of TCP message it contains. An IDS that ``trusts'' SYN+ACK packets, assuming that they are server response messages and thus protected by packet filters, cannot accurately detect attacks against network clients (in which the filtered addresses are the clients, not the servers). Of course, the IDS must be configured to know which addresses are trustworthy and which aren't. An IDS which blindly relies on the fact that addresses on its own LAN are spoof-protected will be completely vulnerable if no actual spoof protection exists. The configuration of the IDS must be consistent with that of the actual packet filters. Requiring Full Handshake An IDS that requires a full 3WH will not record data for a connection until it sees and accepts all 3 packets in the three-way handshake. Two of these packets are sent by the client (and thus, for server attacks, can be considered under the complete control of an attacker), and 1 of them is sent by the server. In TCP terminology, this means that the IDS doesn't start recording until the connection enters ESTABLISHED state. As mentioned previously, requiring a complete handshake makes it dangerously easy to miss connections (due to packet evasion techniques, simple performance problems on the TCP monitor that cause it to miss packets, or even attacker-induced performance problems). Allowing Partial Handshake An IDS that requires at least a partial 3WH will not record data for a connection until it sees some portion of the handshake occur. Evidence of a three-way handshake validates TCB initiation (we'll see that there are problems with blindly creating TCBs to synch up to data streams), and potentially reduces the ability of an attacker to trick the system into creating false TCBs. Requiring only partial handshakes also decreases the probability that a connection will be missed due to packet drops under load. The question that then arises is ``what portion of the three-way handshake needs to be seen by the IDS before a TCB is created?''. An IDS can create a TCB when it sees the initial connection solicitation (the client SYN), or when it sees the server return a positive response (the server SYN+ACK). In the presence of inside-outside filtering, it can be difficult for an attacker to spoof the server response; server SYN+ACK responses are thus a more reliable indication that a connection is occurring. If an attacker cannot spoof the server response, the SYN+ACK also contains the valid sequence numbers for the connection, allowing the IDS to more accurately initialize the TCB. In either case, it's important to note that until the handshake is completed, a connection doesn't actually exist. The only indication an IDS has that a connection isn't being spoofed is when then the client responds to the server SYN+ACK with an ACK confirming the server's initial sequence number. If an IDS uses partial handshakes to open TCBs, it can be tricked into opening TCBs for nonexistent connections. 5.3.2 Data Synchronization The alternative to requiring a three-way handshake to open a TCB is to deduce the initial state of a connection by looking at data packets, presumably after a connection has been opened. Since the IDS is not an active participant in the connection, it doesn't necessarily even have to consider 3WH packets; it is entirely feasible to track normal connections simply by looking at ACK packets (packets containing data). The primary advantage of this technique, which we refer to as ``synching on data'', is that the sniffer picks up more data than systems that require handshakes. The system can recover from the loss of an important 3WH packet, and can detect connection that began before the program was started. Unfortunately, synching on data creates the possibility that the sniffer will accept data that doesn't correspond to any open connection. Worse still, ID systems that synch on data and are strict about sequence number checking can be desynchronized by an attacker who pollutes the observable connection state with forged data before initiating her attack. Using SYN Packets A potential antidote to this problem is to allow the IDS to synch on data, but have it pay attention to 3WH packets that occur sometime after it starts recording data. These systems will initialize connection state from the first observed data packets, but will re-initialize themselves if they see evidence that a real 3WH is being performed (the 3WH is then presumed to set the real state, and previous state and data recorded should be regarded as intentionally faked). It is important that this technique be implemented reliably. Because the process of combining data synchronization with handshake synchronization necessarily allows the monitor to resynchronize the connection based on some packet input, poor implementations can result in TCP session monitors that can be desynchronized (due to falsely injected 3WH packets) at will by an attacker. One poor implementation strategy relies solely on client SYN packets to resynchronize the connection. If a SYN packet is received sometime after the TCB is opened, the IDS resets the appropriate sequence number to match that of the newly received SYN packet. An attacker can inject fake SYN packets at will; all she needs to do is send a SYN packet with a completely invalid sequence number, and the IDS will be desynchronized. Legitimate data being exchanged on the connection will no longer (as far as the IDS is concerned) have valid sequence numbers, and the IDS, discarding the valid data, will be blinded. One simple way to address this problem is to only accept the first SYN packet seen on a connection. Presumably, this will be the legitimate three-way handshake packet, and not a forged desynch attempt. This does not work. There are three major problems with this approach: the IDS remains vulnerable to desynch attacks on connections that start before the program does (it never examines the original 3WH, so no legitimate SYN will ever appear on the connection), the IDS has no reliable way to determine whether any given SYN is in fact the first SYN to appear on the connection (packet drops complicate this), and, most importantly, an attacker can permanently desynchronize the connection by inserting an invalid SYN packet before the legitimate connection starts. A better approach is to rely on SYN+ACK packets to resynchronize. As long as the attacker can't forge a valid looking SYN+ACK packet from the server, the IDS can make the assumption that SYN+ACKs from the server are legitimate and represent real connection handshakes. There are problems associated with this too. If the IDS is observing a stream of data, for which it has not yet detected a three-way handshake, it does not necessarily know which host is the client and which is the server. The observation of a 3WH determines which end is the client and which is the server. An attacker can forge a SYN+ACK packet that makes it appear like her end of the connection is the server; if the IDS cannot determine correctly whether that is the case, it will be desynchronized. Ignoring SYN Packets A TCP monitor need not resynchronize on 3WH packets; SYN packets can be ignored entirely, and data be used as the basis for sequence number initialization. If this is implemented in a naive fashion, any forged data packet can potentially desynchronize the connection. A smarter implementation might only consider (for synchronization purposes) data packets that originate from local hosts, assuming that the attacker cannot forge packets appearing to come from these hosts. 5.4 TCP Stream Reassembly The most difficult task for a network intrusion detection system to accomplish is the accurate reconstruction of the actual data being exchanged over a TCP connection. TCP provides enough information for an end-system to determine whether any piece of data is valid, and where that data belongs in the context of the connection. Even so, the 4.4BSD code to manage this process is over 2000 lines long, and is some of the most involved in the entire TCP/IP protocol implementation. The end-points of a connection have a distinct advantage over an observing monitor --- if they miss data, the other side of the connection will automatically retransmit it after some period of time. Both participants of the connection can actively manipulate the other, to ensure that their data is exchanged correctly. The TCP session monitor does not have this luxury. If it misses a packet, it cannot (practically) request retransmission --- moreover, it cannot easily detect whether a missing piece of data is due to out-oforder packet arrival or a dropped packet. Because the IDS is strictly a passive participant in the connection, it is quite easy for it to miss data. This problem is made even more acute by the fact that proper reassembly of a stream of TCP packets requires accurate sequence number tracking. If an IDS misses enough packets, it can potentially lose track of the sequence numbers. Without some recovery mechanism, this can permanently desynchronize the connection. The techniques used by an IDS to recover from packet loss (and resynchronize with the connection) can also be attacked. 5.4.1 Basic Reassembly Problems Some ID systems do not use sequence numbers at all. Instead, they insert data into the ``reassembled'' stream in the order it is received. These systems do not work. An attacker can blind such a system simply by accompanying her connection with a constant stream of garbage data; the output of the monitor's TCP driver will be meaningless. These systems do not work even on normal TCP streams. The arrival of TCP segments out of order is a normal occurrence (happening whenever the route between TCP endpoints changes and reduces the latency of the path between them)[18]. Unfortunately, when this happens, the ID system does not correctly re-order the packets. The output of the system is again inaccurate. Of course, an attacker could also send her stream of data out of order; the end-system will correctly reassemble, and the effectively crippled IDS will see meaningless data. 5.4.2 Challenges To Reassembly Even if the system does check sequence numbers, there is no assurance that a given segment (even with correct sequence numbers) will be accepted by the endsystem to which it is addressed. Several issues can cause a TCP implementation to drop properly sequenced data. The simplest of these are the IP and TCP insertion problems, but other, higher-level issues present problems as well. One major problem the IDS must cope with is each end-system's advertised window. The ``window'' of a connection represents the number of bytes of data it will accept, preventing the other end of the connection from sending too much data for it to buffer. Data sent past the window is discarded. In addition, the time at which the IDS detects the change in the window is different from the time at which the end-system detects the change and reacts to it. Packets that arrive within the period of time that the IDS and the end-system are inconsistent can cause problems. An IDS that does not account for this in some manner is potentially vulnerable to an insertion attack. The information available to the IDS from captured packets provides one useful indication of endsystem state --- the acknowledgment sequence number. The acknowledgment number represents the next sequence number an end-system expects to see. Presumably (end-system TCP bugs can break this assumption), any valid piece of data will eventually be acknowledged by an ACK message. It may be apparent at this point that an IDS can reliably monitor a stream simply by waiting for acknowledgment before acting on a piece of data. This is not as easy at it may seem. The acknowledgment number is cumulative; it represents the next expected piece of data within the context of the entire connection. Every segment sent is not necessarily directly acknowledged --- even though an acknowledgment is generated in response to it. Several segments worth of data can be acknowledged by one ACK; an IDS cannot simply wait for an acknowledgement to each individual packet it sees. Operating System TCP Overlap Behavior Irix 5.3 Favors New Data for Forward Overlap HP-UX 9.01 Favors New Data for Forward Overlap Linux Favors New Data for Forward Overlap AIX 3.25 Favors New Data for Forward Overlap Solaris 2.6 Favors New Data for Forward Overlap FreeBSD 2.2 Favors New Data for Forward Overlap Windows NT 4.0 Always Favors Old Data Figure 14: TCP Overlap Behavior in Various Operating Systems Another great problem in IDS stream reassembly is the fact that an attacker can send several identically sequenced packets with varying data. The header information will not change from packetto-packet (except the checksum), and each packet will alter end-system state in exactly the same manner, but only one of the packets will actually be processed by the destination host. Unfortunately, only the end-system knows which one was actually processed. There is not enough information exchanged on the wire for a IDS to determine which packet was valid. Worse still, an insertion attack against an IDS coupled with this ambiguity can allow an attacker to determine which packets will be accepted by the IDS, by sending segments that the end-system will reject without acknowledging, and then sending valid packets after some brief delay. The IDS will most likely accept the bad data and move the sequence space forward, causing it to ignore the valid data and potentially desynchronizing the IDS from the actual connection. This is very similar to the TCP hijacking attack described by Laurent Joncheray[14]. 5.4.3 Overlap Like IP fragments, TCP segments can arrive out of order and in varying sizes. As in IP fragmentation, this can cause new data to overlap old data. As always, if the IDS does not resolve this problem in a manner consistent with the hosts it's watching, it will not accurately reassemble the stream of data. The rules for handling TCP segment overlap are quite similar to those of reassembling fragmented IP datagrams. In some cases, end-systems will resolve the conflict in favor of the old data; in others, the conflict is resolved in favor of the new data. There is, again, a great potential for bugs here, and, as in IP reassembly, a bug on either the end-system or the IDS is exploitable by the attacker. Figure 14 details the overlap resolution behavior of various operating systems. Using overlapping TCP segments, it is possible for an attacker to create a stream of packets that will assemble to a completely innocuous string if sent alone, or to an attack signature if it's accompanied by a single overlapping segment. Playing with segment overlap allows the attacker to literally rewrite the packet stream on the destination host, and, unless the IDS resolves overlap in exactly the same manner as the end-system, it will not see the attack. 5.4.4 Endpoint TCP Overlap Bugs As in IP fragmentation overlap resolution, there is a large potential for inconsistency of implementation between vendors in TCP reassembly code. As an example, Windows NT resolves conflicts in out-oforder TCP segments consistently in favor of the old data, and 4.4BSD resolves conflicts as indicated in the RFC, occasionally in favor of the new data. As with fragmentation reassembly, unless the IDS knows how each system on the network reassembles streams containing conflicting segments, it will be unable to accurately monitor certain types of end-systems. 5.4.5 Summary of Reassembly Issues These issues do not present a great problem for most connections; most of the TCP segments in a normal connection arrive in-order, and there aren't any fake TCP segments injected into the stream specifically to confuse the IDS. However, in the real world, an attacker trying to evade an IDS will attempt to make the TCP stream as hard to monitor as possible, and will stretch the limits of the protocol to do this. Vulnerabilities in IDS TCP reassembly code are insidious because they are not immediately obvious; a specific problem may manifest itself only when the IDS is given some pathological sequence of inputs. The majority of the time, the IDS may appear to be reassembling TCP streams perfectly. Testing IDS TCP implementations for problems is time consuming and expensive; it's easy for a vendor to skip this testing almost entirely. 5.5 TCB Teardown The TCB teardown policies of an IDS determine the point at which the system ceases recording data from a connection. TCB teardown is necessary because the state information required to track a connection consumes resources; when a connection ceases to exist, it no longer makes sense to dedicate resources to tracking it. A system that did not destroy old TCBs at some point would be trivially defeatable, simply by flooding it with meaningless connections until it ran out of resources to track future connections. In TCP, connections close after they're explicitly requested to do so. Two TCP messages (RST and FIN) exist specifically to terminate a connection. Barring sudden crashes on both endpoints, TCP connections are only terminated by the exchange of these messages. Because TCP explicitly provides notification of terminated connections, it may be logical to design an IDS that uses these messages to decide when to close a connection TCB. This is not enough to adequately manage the per-connection resource problem. TCP connections do not implicitly ``time out''. A connection can be alive without the exchange of any data indefinitely. TCP provides a mechanism to ensure that both hosts are alive, by periodically exchanging messages, but this mechanism is not commonly used and takes far too long to recognize dormant connections to be of practical use. Without some method to time out arbitrary dormant connections, the IDS remains attackable simply by flooding it with connections that do not explicitly terminate. The problem with TCB teardown is that an IDS can be tricked into tearing down a connection that is still active, and thereby force the system to lose state. Within the context of a pattern matching engine, this means that the stream of input abruptly terminates. An attacker that can induce the incorrect termination of the TCB tracking her can prevent pattern matching from working by abruptly halting pattern matching before the complete attack signature passes across the network. On the other hand, an IDS that fails to tear down a TCB for a connection that really has closed is also vulnerable; as soon as the connection is legitimately closed, its parameters can be re-used for a new connection with completely different sequence numbers (technically, the systems must wait for a period of time before reusing connection parameters [12] --- not all operating systems enforce this). In the absence of synchronization recovery techniques, this can completely blind the IDS to entire connections. Because an ID system's TCB teardown policies can be attacked, their design is relevant to our discussion. We've identified a few options that can contribute to how an IDS ceases to track connections, and will discuss their ramifications here. This is by no means an exhaustive summary of all the possible options. 5.5.1 Using TCP Connection Teardown Messages One possible way for an IDS to determine when to stop tracking a connection is to listen for TCP control messages that indicate the connection is being shut down. Doing so allows an IDS to quickly recover resources for connections that have actually terminated, and also prevents desynchronization for new connections using the same parameters. Unfortunately, because some connection termination request messages may be under the control of an attacker, there is significant risk involved in trusting these messages. TCP provides two connection teardown messages. The first message allows for ``orderly'' connection teardown, where both sides of the connection acknowledge the end of the connection and ensure that their data is completely sent before the connection closes. The second message abruptly terminates a connection due to error. FIN Processing TCP provides orderly teardown via the FIN message. A system sending a FIN message is indicating that it has finished sending data, and is ready to close the connection. FIN messages are acknowledged, and each side of the connection sends a message to shut it down. In the presence of inside-outside filtering, FIN messages are reliable indicators of terminated connections. A connection is not completely terminated until both sides send a FIN message, and acknowledge the other side's message. An attacker cannot fake the FIN shutdown of a connection without forging packets that appear to come from the server. RST Processing It's not enough for an IDS to rely on FIN messages to terminate connection TCBs. TCP provides a method to abruptly notify the other end of a connection that the connection has been closed, using the Reset (RST) message. RST segments are not acknowledged; the only way to know if an RST message has been accepted by an end-system is to see if it continues sending data on the connection. The only way to do this practically within an IDS is to time the connection out after seeing an RST; however, this means that an IDS can potentially mistakenly shut down a connection that is alive but dormant. The RST problem is more severe due to end-system TCP bugs. Technically, an RST message is only valid if it is correctly sequenced --- RST messages with spurious sequence numbers (which can be created by an attacker in an effort to illicitly tear down connections) should be ignored. Not all operating systems check the sequence number on RST messages. 5.5.2 Relying on Timeouts for TCB Teardown An alternative to using TCP connection teardown messages is to simply time connections out when they become dormant for some threshold time period. This prevents the IDS from being fooled by false TCP teardown messages, and potentially simplifies the IDS TCP code. There is a cost to this simplicity --- systems that rely on timeouts for TCB teardown can easily be circumvented. In what has been termed the ``Sneakers'' attack (after the famous suspense movie, where Robert Redford evades a sophisticated alarm system by employing a similar technique), the attacker renders the sum of her movements undetectable to the IDS by waiting for the IDS to time out between packets. The Sneakers attack is particularly troublesome because, as we noted previously, the IDS must employ some form of connection timeout TCB teardown, as dormant TCP connections can remain established for far longer than the IDS can devote resources to track them. If an attacker can induce this timeout, either by waiting long enough or by filling the IDS with enough interesting (but meaningless) connections that it is forced to garbage-collect older connections, she can potentially evade the IDS by causing it to lose state. Additionally, systems which completely ignore TCP teardown messages can be desynchronized when the connection is legitimately closed. Even though the connection has ceased to exist, the IDS maintains a TCB for it until it times out. If a new connection occurs using the same parameters before the connection times out on the IDS, the system will be desynchronized, due to the use of different sequence numbers on the new connection. This attack can be carried out without any specialized code; an attacker simply uses ``telnet'' to create a connection, closes the connection, and re-opens it. If the sequence numbers on her machine change enough between the two connections, a vulnerable IDS will not be able to track the second connection. 6 Denial of Service Attacks Denial of service attacks against ID systems are severe because, by their very nature, passive ID systems ``fail open'' --- unlike a good firewall, access to the network isn't cut when a monitor system becomes unresponsive. A basic goal, then, for an attacker is to cause the IDS to fail without losing access to the machines being attacked. Some denial of service attacks exist due to buggy software. An IDS that crashes when it receives a certain bad packet, or a series of bad control messages, or anything else that can be cued by a remote attacker, can be defeated instantly. Fortunately, these kinds of bugs are quickly and easily fixed by vendors. Unfortunately, finding all such bugs requires painstaking software audits. It is also interesting that some ID systems can themselves be used to launch denial of service attacks on other systems. An ID system that includes a countermeasure capability, such as the ability to set packet filters in reaction to an attack, can be fooled via false positives (due to forged attacks) to react to attacks that haven't actually occurred. 6.1 Resource Exhaustion There are many different types of denial of service attacks that are valid against ID systems. The attacks we'll discuss here all involve resource exhaustion --- the attacker identifies some point of network processing that requires the allocation of some sort of resource, and causes a condition to occur that consumes all of that resource. Resources that can be exhausted by an attacker include CPU cycles, memory, disk space, and network bandwidth. The CPU processing capabilities of an IDS can be exhausted because the IDS spends CPU cycles reading packets, determining what they are, and matching them to some location in saved network state (for example, an IP fragment needs to be matched to the other fragments of the datagram it represents). An attacker can determine what the most computationally expensive network processing operations are, and force the IDS to spend all its time doing useless work. ID systems require memory for a variety of things. TCP connection state needs to be saved, reassembly queues need to be maintained, and buffers of data need to be created for pattern matching. The system requires memory simply to read packets in the first place. As the system runs, it allocates memory as needed to perform network processing operations (for example, the receipt of an IP fragment means that the ID system will need to obtain memory to create and maintain an IP fragment queue for that packet). An attacker can determine which processing operations require the ID system to allocate memory, and force the IDS to allocate all its memory for meaningless information. At some point, most ID systems will need to store logs of activity on disk. Each event stored consumes some amount of disk space, and all computers have a finite amount of disk space available. An attacker can create a stream of less events and, by having them continually stored, eventually exhaust all disk space on the IDS, which will then be unable to store real events. Finally, network ID systems track activity on the networks they monitor. For the most part, they are capable of doing this only because networks are very rarely used to their full capacity; few monitor systems can keep up with an extremely busy network. The ID system, unlike the end-systems, must read everyone's packets, not just those sent specifically to it. An attacker can overload the network with meaningless information and prevent the ID system from keeping up with what's actually happening on the network. Other resources exist as well, depending on the design of the system. For instance, in systems that set router filters in response to attacks, we must consider the fact that the router has a limited capacity for storing filter entries; at some point, the router's filter storage will be completely consumed, and the system will be unable to add new entries. An ID system that doesn't take this into account can be defeated by forcing it to spend the router's filter storage on reactions to fake attacks. The basic problem with resource consumption on an IDS is that the system must simulate the operation of all the machines it's watching, in order to track what's actually occurring on them. The endsystems themselves only need to concern themselves with network traffic that directly involves them. The IDS, which is spending more resources coping with the network than any other system on the network, is thus inherently more prone to resource starvation attacks than the end-systems. This problem is exacerbated by the fact that most network ID systems operate in ``promiscuous'' mode, reading all traffic off the wire, regardless of its destination. Resources can be consumed on the IDS by the processing of traffic that isn't even destined for a real machine; apart from the network bandwidth consumed by this traffic, no other system on the network will be affected by this. Again, performance on the IDS is degraded to an greater extent than on the end-systems it's trying to track, making it more difficult for the IDS to keep up and giving the attacker an edge. 6.1.1 Exhausting CPU Resources An attacker's goal in exhausting an ID system's computational capability is to prevent it from keeping up the network. A CPU-starved IDS will not process captured packets quickly enough and, as these packets fill the buffering capacity of the operating system, captured data starts being dropped. An example of why this occurs is useful. On 4.4BSD Unix, packet capture is accomplished through the ``Berkeley Packet Filter'' (BPF) device. BPF interacts directly with low level network drivers (such as the Ethernet interface driver), taking snapshots of packets before they're handed up to the IP layer for processing. As packets are captured by BPF, they are stored in a kernel buffer, where they stay until an application reads them out. If an application doesn't read data out of the buffer faster than the buffer is filled up by newly captured packets, space for queuing up captured packets runs out. When this happens, captured packets are necessarily dropped before the application ever has a chance to examine them. An attacker can prevent an ID system from keeping up with packet capture by forcing it to spend too much time doing useless work. In order to do this, the attacker must identify operations that she can force the IDS to perform that consume large amounts of processing time. In many ID systems, this is easy; inefficient algorithms are used to process, save, and look up state about network traffic. The attacker can cause the system to process information that forces these algorithms to work in their worst-case conditions. A concrete example of this is IP fragmentation. As IP fragments arrive, they must be stored, until all the related fragments arrive. To facilitate reassembly, most systems store fragments in the order that their data will appear in the final packet. This means that, as each fragment arrives, the system needs to locate the correct fragment storage area, and then find the right place in that area to store that specific fragment. Many systems use a simple ordered list to store incoming fragments. As new fragments arrive, the system must locate the correct list for that packet, and then do a full linear lookup to determine whether the new fragment was already received and, if not, where in the list the fragment should go. As new fragments arrive, this list gets longer, and the time required to look up fragments in the list increases. An attacker can force this process to operate in its worst case by sending large amounts of traffic using the smallest possible fragments --- large amounts of CPU cycles will be consumed tracking tiny IP fragments. Some protocol parsing can be expensive by itself. An IDS that needs to somehow analyze encrypted traffic may spend a large amount of time simply decrypting packets (encryption and decryption can be extremely expensive operations). While the demand for this kind of processing is not now very great, it will increase as technologies such as IP-sec[11] are deployed. 6.1.2 Exhausting Memory ID systems require memory to operate. Different types of protocol processing have differing memory requirements. An attacker that can force an IDS to consume all available memory resources can render the system nonfunctional; the system may simply quit abruptly when it runs out of memory, or it may thrash trying to squeeze more space out of slow virtual memory systems, causing the same effects as CPU exhaustion. An attacker trying to exhaust memory on an IDS examines the system, trying to determine the points at which the system allocates memory. The attacker attempts to isolate network processing events that cause the system to allocate memory for a long duration of time; the attacker then induces this processing by sending packets that the IDS will be forced to process in that manner. After being flooded with such packets for some time, the IDS will run out of memory to process the incoming packets. Some ID systems employ ``garbage collection'' to automatically reclaim memory that is not being actively used. Unfortunately, used incorrectly, garbage collection can present its own problems. A garbage collection system that isn't aggressive enough in reclaiming memory will not be able to keep up with demand, and will only slow down memory exhaustion attacks. A garbage collection system that is too aggressive will consume memory that is needed for real processing, causing the system to incorrectly process network traffic. Examples of attackable memory allocations include TCP TCB creation (the attacker creates a flurry of connections to various hosts on the ID system's network, or, using packet forgery, creates a flood of entirely fake connection) and TCP reassembly (the attacker sends large amounts of traffic in streams of out-of-order data that will need to be reassembled, forcing the system to consume memory not only for the data but also for reassembly queues). 6.1.3 Exhausting Network Bandwidth Perhaps the simplest way to starve an IDS of resources is simply to create too much raw network traffic for the system's low-level network interface to keep up with. As each packet arrives, the interface must copy the packet off the wire and into a buffer, interrupt the system, and cause the system to copy the packet into the kernel. The interface is capable of handling only a limited amount of traffic before it is overwhelmed by the load and starts dropping incoming packets. Although modern network interfaces operate efficiently enough to keep up with drastically high network loads, older hardware cannot do so. The point at which old ISA-bus based network interfaces become saturated is drastically lower than the point at which the network media itself becomes saturated. If an attacker creates enough traffic, she can prevent such interfaces from keeping up without saturating the network itself. Targeted packet floods can also work in some circumstances. On switched networks, it's possible to create large amounts of traffic that will only be seen by certain systems. If an attacker can create a flood of packets that will only be switched to the IDS, she can flood the IDS while maintaining the ability to communicate with the machines she's attacking. This type of attack is closely related to CPU exhaustion, and, indeed, many times the system will run out of CPU cycles long before the network interface is saturated. Regardless of which component of the system fails first, the effect is the same for the attacker; the IDS cannot keep up with the network, and misses significant packets. 6.2 Abusing Reactive ID Systems In some circumstances, the IDS itself can become an instrument of denial of service attacks. If the IDS has a ``reactive'' countermeasure capability, and is vulnerable to attacks that create false positives, it can be forced to react to attacks that don't actually exist. The countermeasures employed can be subverted to completely block access for legitimate traffic, or to shut down valid connections. In these cases, the reactive capabilities of network ID systems are actually doing more harm than good. The most basic problem with reacting to attacks discovered by monitoring IP traffic is that the IP addresses are not always trustworthy. An attacker can forge traffic appearing to come from almost any IP address, and, if this traffic appears to contain an attack, the ID system may react to it. In some circumstances, this is very easy to do. For example, many attacks occur over ``connectionless'' protocols, for which the attacker doesn't need to see the responses to her packets. Instead, she simply creates and blindly sends forged packets, and the IDS is fooled into believing that the attack is coming from somewhere that it isn't. Good examples of this include ICMP ping floods, SYN floods, ``death'' packets (such as the ping-ofdeath attack involving large ICMP echo requests), and UDP packet storms. Even attacks that involve TCP connections can be faked if the IDS doesn't correctly identify the threeway handshake. If the IDS doesn't require a handshake at all before recording data, TCP attacks can be faked as easily as ping floods; even if it does, the specific manner in which it tracks handshakes can be attacked for the same effect. The essential issue here is that the attacker can trigger alarms about events occurring from fake addresses. The IDS, which has no idea what the ``real'' source of the attack was, reacts falsely to the forged events by restricting connectivity to the faked addresses. The addresses used by the attacker can be specifically chosen to maximally affect overall connectivity (for example, the attacker can cut off access to all the network's DNS servers). The amount of damage that can be caused by such attacks depends on the manner in which the IDS reacts to attacks in general. Some ID systems limit themselves to shutting down TCP connections that appear to be vehicles of attack; these systems can be abused to shut down legitimate connections (by forging traffic that makes it appear that an attack is being performed using those connections), but cannot easily be abused to impact overall connectivity, unless specific TCP connections are vital for the network's connectivity (for instance, BGP4 routing). Other systems have more effective ways to react to attacks; they modify router filters on the fly to cut all traffic from sites that appear to be originating attacks. These systems pay for that extra power by being vulnerable to more damaging denial-of-service subversions; an attacker that can cause the IDS to recognize false attacks can cut all access of to critical network resources by strategically forging addresses. Regardless of what countermeasures are actually employed, it is important to realize that such facilities are dangerous as long as an attacker can forge attacks. Some types of attacks may never be a legitimate basis for deployment of countermeasures, simply due to the fact that they can be performed blindly using forged addresses. Other attacks can only be safely reacted to if the IDS has a rock-solid network processing implementation. 7 Methodology We support our assertions regarding vulnerabilities in ID systems with the results of extensive tests against actual, commercially available intrusion detection systems. The purposes of these tests were to ascertain characteristics of each subject' s TCP/IP implementation, and to provide concrete examples of actual attacks that could be performed against them. Our tests were designed to be easily repeatable, and to illustrate in the most obvious possible manner the deficiencies of each tested system. 7.1 Overview Each of our tests involve injecting packets onto a test network, on which the subject ID system was running. By tracking the subject's administrative console output, we were able to observe many characteristics of the system's underlying TCP/IP implementation. To this extent, all of our tests involved consideration of the subject as a ``black box''. All our tests involved the TCP protocol. In most cases, the tests involved interactions between our injected packets and a third host, representing a hypothetical ``target'' of attack. In each test, this target host was the explicit addressee of all of our packets. The presence of the target host allowed us to easily create ``real'' TCP connections for the subject IDS to monitor. In addition, the target host also acted as a ``control'' for our experiments. The target's reactions to our injected packets allowed us to observe empirically the behavior of a ``real'' TCP/IP implementation, and contrast that behavior to the deduced behavior of the subject IDS. All of our tests involved mimicking a ``PHF'' webserver attack. The PHF attack exploits a specific Unix CGI script (``phf'') to attempt to gain access to a webserver. We used PHF because the attack is detected by all our subject ID systems, and because the attack is easily reproduced using standard TCP network tools (like ``telnet''). In order to reproduce a PHF attack, we sent the string ``GET /cgibin/phf?'' to the target host. In each test, we created network conditions that could make it appear as if a PHF attack was being attempted. In each test, the specific packets injected into the network differed subtly. The subject ID system reacted to each test by either reporting or not reporting a PHF attack. By considering the ID system's output and the specific types of packets used for the test, we were able to deduce significant characteristics of the subject IDS. Before conducting complicated or subtle tests against the subject, we conducted a series of ``baseline'' tests. The purpose of these tests was to ensure that the subject IDS was configured properly and was functioning at the time our tests were conducted, and that the IDS did in fact detect a PHF attack based on our PHF reproduction string. In almost all test cases, a process on the target host ran which accepted incoming TCP connections on the HTTP port and printed any input obtained from the machine's TCP stack. By examining the output of this process, we were able to deduce whether the subject IDS should have detected the attack based on the network conditions we created. 7.2 Tools Used The primary tool we employed in our tests was CASL, a specialized scripting language developed at Secure Networks, Inc. that allows for programmable generation and capture of raw packets. Each of our tests used a CASL script to inject packets onto the network, and, in most cases, read and parse the responses. A more detailed overview of CASL is provided in [15]. Our target host ran FreeBSD 2.2, an implementation of 4.4BSD. The 4.4BSD TCP/IP stack is one of the best documented and most easily obtainable IP implementations available, and FreeBSD is by far the most popular BSD implementation. FreeBSD 2.2 was, at the time of our testing, the most recent ``stable'' release of the operating system. For each test, we used Hobbit's ``netcat'' tool[16] to listen on TCP port 80 and print the input from the target host's TCP stack. Hobbit's tool is an all-purpose, bare-bones diagnostic program that is widely available, popular, and documented; in its ``listening'' mode, the tool simply accepts an incoming connection, and prints each character of data the TCP driver presents to it. As we ran each test, we observed the specific packets being transmitted on the network using LBL ``tcpdump''[19]. Tcpdump is a low-level network diagnostic tool that passively monitors networks in promiscuous mode, and prints summaries of each captured packet. We ran the ``tcpdump'' tool from the test platform on the first execution of each specific test script. Tcpdump provided us with IP-level packet traces to accompany our test results, which made it easier to discern exactly what was happening on the network during each of our tests. Our test network was non-switched 10BaseT Ethernet. The hosts on the network included the IDS, the target host, and the test platform. The network was dormant at the time we conducted our tests. 7.3 Test Execution Each of our tests involved a CASL script, run from an interpreter on the test platform, which generated and injected packets addressed to the target host. We define each of these tests in terms of the script's name, its specific network interactions, the IDS characteristic it attempts to ascertain, and its validity to the 4.4BSD TCP/IP driver (that is, whether our target host completely and accurately reconstructed the PHF string our test attempted to send). A test that was not ``valid'' to 4.4BSD should not have resulted in the detection of a PHF attack by the subject IDS. We suggest that the subject IDS should not detect attacks in ``invalid'' tests, and should reliably detect attacks within the valid ones. In cases where the IDS failed to detect an attack in either type of test, we re-initialized the IDS and reran the test multiple times. Before concluding that a subject IDS was not detecting our attack signatures, we re-ran the baseline test to confirm its operational integrity, and immediately ran the considered test. 7.4 Test Definitions Name baseline-1 Operation Complete a TCP handshake, send the test string in a single TCP data segment. Behavior Tested Is the IDS configured properly, and does our test string adequately reproduce a PHF attack to the subject? Target Validity Valid Name baseline-2 Operation Complete a TCP handshake, send the test string in a series of ordered, 1character TCP data segments. Behavior Tested Is the IDS configured properly, and does our test string adequately reproduce a PHF attack to the subject? Target Validity Valid Name frag-1 Operation Complete a TCP handshake, send the test string in a single TCP data segment which is broken into 8-byte IP fragments and sent in order. Behavior Tested Does the subject IDS perform IP fragment reassembly at all? Target Validity Valid Name frag-2 Operation Complete a TCP handshake, send the test string in a single TCP data segment which is broken into 24byte IP fragments and sent in order. Behavior Tested Does the subject IDS perform IP fragment reassembly at all? Target Validity Valid Name frag-3 Operation Complete a TCP handshake, send the test string in a single TCP data segment which is broken into 8byte fragments, with one of those fragments sent out of order. Behavior Tested Can the subject IDS handle basic out-of-order IP fragmentation reassembly? Target Validity Valid Name frag-4 Operation Complete a TCP handshake, send the test string in a single TCP data segment which is broken into 8-byte fragments, with one of those fragments sent twice. Behavior Tested Can the subject IDS handle reassembly when fragments are completely duplicated? Target Validity Valid Name frag-5 Operation Complete a TCP handshake, send the test string in a single TCP data segment broken into 8-byte fragments, sent completely out of order and with an arbitrary duplicated fragment. Behavior Tested Can the subject IDS handle reassembly in pathological (but correct) cases? Target Validity Valid Name frag-6 Operation Complete a TCP handshake, send the test string in a single TCP data segment which is broken into 8-byte fragments, sending the marked last fragment before any of the others. Behavior Tested Does the subject IDS correctly wait for all fragments to arrive before attempting reassembly? Target Validity Valid Name frag-7 Operation Complete a TCP handshake, send a stream of fragments containing the signature string with the word ``GET'' replaced with the string ``SNI''. Send a forwardoverlapping fragment rewriting the ``SNI'' back to ``GET'' on the target host. Behavior Tested Does the subject IDS correctly handle forward overlap in IP fragments? Target Validity Valid Name tcp-1 Operation Complete a TCP handshake, simulate the disconnection of the target host from the network, and send the target string in a series of 1-byte TCP data segments. Behavior Tested Does the subject IDS wait for TCP acknowledgment from the target before acting on data from captured packets? Target Validity Inapplicable Name tcp-2 Operation Complete a TCP handshake, send the test string in a stream of 1-byte TCP data segments where the sequence number wraps back to zero. Behavior Tested Does the IDS correctly deal with wrapped sequence numbers? Target Validity Valid Name tcp-3 Operation Complete a TCP handshake, send the test string in a stream of 1-byte TCP data segments, duplicating entirely one of those segments. Behavior Tested Does the IDS correctly handle completely duplicate TCP segments? Target Validity Valid Name tcp-4 Operation Complete a TCP handshake, send the test string in a stream of 1-byte TCP data segments, sending an additional 1-byte TCP segment which overlaps a previous segment completely but contains a different character. Behavior Tested Does the subject IDS correctly handle duplicate TCP segments? Target Validity Valid Name tcp-5 Operation Complete a TCP handshake, send the test string, with the letter `c' replaced with the letter `X', in a series of 1-byte TCP data segments. Immediately send a 2-byte TCP data segment that overlaps (forward) the modified letter, rewriting it back to `c' on the target host. Behavior Tested Can the subject IDS handle overlap in out-of-order TCP streams? Target Validity Valid Name tcp-6 Operation Complete a TCP handshake, send the test string in a series of 1-byte TCP data segments, and increase the sequence number by 1000 midway through the stream. Behavior Tested Does the IDS ``recover'' from sudden changes in the sequence number? Target Validity Invalid Name tcp-7 Operation Complete a TCP handshake, send the test string in a series of 1-byte TCP data segments, interleaved with a stream of 1-byte data segments for the same connection but with drastically different sequence numbers. Behavior Tested Does the subject IDS check sequence numbers during reassembly? Target Validity Valid Name tcp-8 Operation Complete a TCP handshake, send the test string in a series of 1-byte TCP data segments, with one of those segments sent out of order. Behavior Tested Can the subject IDS handle basic out-of-order TCP reassembly? Target Validity Valid Name tcp-9 Operation Complete a TCP handshake, send the test string in a series of 1-byte TCP data segments, sent in random order. Behavior Tested Can the IDS handle pathological out-of-order TCP reassembly? Target Validity Valid Name tcbc-1 Operation Do not complete a TCP handshake, but send the test string in a series of 1-byte TCP data segments as if a handshake had occurred for some arbitrary sequence number. Behavior Does the IDS require a handshake before it will start recording data from a Tested connection? Target Validity Invalid Name tcbc-2 Operation Complete a TCP handshake, send the test string in a series of 1-byte TCP segments, interleaved with SYN packets for the same connection parameters. Behavior Tested Does the IDS resynchronize on a SYN packet received after a complete TCP handshake? Target Validity Valid Name tcbc-3 Operation Do not complete a TCP handshake, but send a stream of arbitrary data at a random sequence number as if one had occurred. Use the same connection parameters to connect with ``netcat'' and type the test string in manually. Behavior Tested Can the IDS be desynchronized due to badly sequenced fake data prior to a real connection initiation? Target Validity Valid Name tcbt-1 Operation Complete a TCP handshake and immediately shut the connection down with an RST. Re-connect over the same parameters, with drastically different sequence numbers, and send the test string in a series of 1-byte TCP data segments. Behavior Tested Does the IDS correctly resynchronize after a connection is legitimately torn down with an RST? Target Validity Valid Name tcbt-2 Operation Complete a TCP handshake and send the test string in a series of 1-byte TCP data segments. Midway through the stream, tear the connection down with an RST (but continue to send the rest of the data segments). Behavior Tested Does the IDS stop recording data when it sees an RST? Target Validity Invalid Name insert-1 Operation Complete a TCP handshake and send the test string in a series of 1-byte TCP data segments, each with a bad IP checksum. Behavior Tested Does the IDS verify the IP checksum on received packets? Target Validity Invalid Name insert-2 Operation Complete a TCP handshake and send the test string in a series of 1-byte TCP data segments, each with a bad TCP checksum. Behavior Tested Does the IDS verify the TCP checksum on received segments? Target Validity Invalid Name insert-3 Operation Complete a TCP handshake and send the test string in a series of 1-byte TCP data segments, none of which have the ACK bit set. Behavior Tested Does the IDS accept TCP data in segments without the ACK bit? Target Validity Invalid Name evade-1 Operation Complete a TCP handshake, include the test string in the initial SYN packet. Behavior Tested Does the IDS accept data in a SYN packet? Target Validity Valid 7.5 Summary Because our tests are scripted, they are well-defined, easily repeated, and fast. After defining and perfecting the test suite, we were able to completely test new ID systems in a matter of minutes. The majority of our testing time was spent defining new tests. Running the individual tests against ID systems took negligible time. We are in the process of releasing the scripting tool that we used for the tests to the public. When this process has completed, we intend to make the suite of IDS test scripts we've developed available to the public as well. It is our hope that our work can define a framework within which arbitrary network ID systems can quickly be evaluated. Our test suite is by no means complete; we provide these test results to support the points in our paper, not to define a complete evaluation process for ID systems. With the tools to conduct these tests in the hands of the community, we hope that our tests can be extended to define a more complete test suite. 8 Results We applied our tests to four of the most popular network intrusion detection systems on the market. In each case, our tests identified serious, exploitable problems in the manner that the IDS reconstructed data transmitted on the network. The results of our tests are not surprising, and we believe that they support the basic points we make in this paper. In many cases, the ID systems we tested had general problems that precluded them from passing entire collections of specific tests. For example, none of the systems we tested correctly handled IP fragmentation; thus, the systems incorrectly handled all the specific fragmentation tests. We ran every test we could against each ID system. One of the systems we tested, WheelGroup's NetRanger system, is available only with its associated hardware. We were unable to test this system on our own network, but rather had to obtain the cooperation of an organization already using the product. This prevented us from running many of our tests against this product; NetRanger was the second system we tested, and we added many tests after our first (and only) exposure to the system. One of our tests (``tcp-1'') also required us to have access to the local network the test machine was on --- we did not have this access for NetRanger. Another system we test, Network Flight Recorder's NFR system, is not an intrusion detection system per se, but rather a network monitoring engine that can be used to build an intrusion detection system (among many other things). Our results are significant to the usage of NFR as an automated network IDS, but not necessarily to the product as a whole. It's important to note that the number of ``failed'' tests each product has is not necessarily an indication of the relative quality of the product. The number of tests each IDS passes is biased heavily based on the presence of specific bugs. Our test suite was not designed to provide a ``score'' for each product, but rather to highlight specific characteristics about them. 8.1 Specific Results The systems we tested were Internet Security Systems' ``RealSecure'' (version 1.0.97.224 for Windows NT), WheelGroup Corporation's ``NetRanger'' (version 1.2.2), AbirNet's ``SessionWall¡3'' (version 1, release 2, build v1.2.0.26 for Windows NT), and Network Flight Recorder's ``NFR'' (version beta-2). We present the overall results from our tests for every IDS in Figure 15. Each individual IDS is described after the table, along with an interpretation of the results. For each test, a plus sign (`+') indicates that the IDS saw a PHF attack as a result of the packets our test injected. A minus sign (`-') indicates that the IDS reported no attack after we ran our test. A question-mark (`?') indicates that we were unable to perform the test on that product. Test Name Expected Result RealSecure NetRanger SessionWall NFR baseline-1 baseline-2 frag-1 frag-2 frag-3 frag-4 frag-5 frag-6 frag-7 tcp-1 tcp-2 tcp-3 tcp-4 tcp-5 tcp-6 tcp-7 tcp-8 tcp-9 tcbc-1 tcbc-2 tcbc-3 tcbt-1 tcbt-2 insert-1 insert-2 insert-3 evade-1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ? ? + + + + + + ? ? ? ? + ? - + + + + + + + + + + - + + ? + + + + + + + + + + + + + + Figure 15: IDS Test Suite Results 8.2 Overviews of Specific ID Systems 8.2.1 ISS RealSecure ISS RealSecure is an automated network intrusion detection system. We performed our tests on the Windows NT version of the product, although it is available for Unix platforms as well. RealSecure appears to have two independent network monitor components. The first of these handles signature recognition within captured packets; the second provides a ``realtime playback'' capability that allows administrators to watch the information being exchanged in a TCP connection in real-time. We found significant differences between the playback facility and the signature recognition facility. Unlike RealSecure's signature recognition engine, the playback system does not appear to sanity check TCP packets before presenting their contents to the user. No sequence number checking was performed in session playback, and out-of-order packets were displayed out of order. An attacker can trivially obscure her actions in RealSecure session playback simply by accompanying her connection with a stream of meaningless, unsequenced TCP packets for the connection; she can also confuse administrators by sending all her packets out of order. The most significant problem with RealSecure, as with all the other systems we tested, was that it did not handle IP fragmentation reassembly at all. An attacker can completely evade RealSecure by fragmenting every packet she sends across the network. RealSecure also appeared to have serious problems with TCP reassembly when duplicate segments appeared on the network. RealSecure never detected an attack in any of the tests we ran that involved sending multiple TCP segments with the same sequence number, even though those tests resulted in valid reassembly of the test string on the target host. RealSecure does not appear to pay attention to TCP RST messages. We were able to desynchronize RealSecure by closing a connection with a client RST message, and then immediately reconnecting using the same parameters. RealSecure recognized attacks in streams even after their connection was reset. RealSecure also does not appear to pay attention to TCP SYN messages; we were able to desynchronize RealSecure from our connections by preceding them with arbitrary data segments with random sequence numbers. Finally, RealSecure was vulnerable to all of our insertion attacks. It did not appear to check IP or TCP checksums, nor did it verify that the ACK bit was set on TCP data segments. 8.2.2 WheelGroup NetRanger NetRanger is an automated network intrusion detection system by WheelGroup Corporation. NetRanger interfaces a passive network monitor with a packet filtering router, creating a ``reactive'' IDS; the ability to respond in realtime to attacks by ``shunning'' addresses (filtering them at the router) is a major feature of the system. We had very limited access to the NetRanger system. The hardware requirement (and price) of this system made it impractical for us to obtain our own copy for testing; rather, we relied on the cooperation of an organization already using the product. Because of this, our tests were performed over the global Internet, and we were only able to perform certain tests (due to timing issues). Our test results for NetRanger still showed major problems. Like all the systems we reviewed, NetRanger (in the version we tested) is completely unable to handle fragmented IP packets. An attacker can evade NetRanger completely by fragmenting all her packets. We were able to evade NetRanger by injecting duplicate sequenced segments with different data into our connection stream (the ``tcp-8'' test). NetRanger did not detect data in a SYN packet, so an attacker can evade many of NetRanger's checks by putting crucial data in her initial SYN packet. We were able to desynchronize NetRanger from our connections by preceding the connection with fake, randomly sequenced data. NetRanger failed to detect attacks in a connection, using the same parameters, that followed this. Finally, NetRanger was vulnerable to one of our insertion attacks (it doesn't appear to validate TCP checksums). NetRanger did appear to reliably verify IP checksums. Many of our tests were not performed against NetRanger. We can't conjecture as to whether NetRanger is vulnerable to the attacks those tests measure. Hopefully, these tests can be run against NetRanger in the future. 8.2.3 AbirNet SessionWall¡3 SessionWall is an automated network intrusion detection system by AbirNet. We tested the Windows NT version of AbirNet SessionWall-3. Although AbirNet appears to have realtime connection playback capabilities, we were unable to get it working in the evaluation copy we used for our tests. Of all the ID systems we tested, AbirNet appeared have the most strict network monitoring system. SessionWall-3 did not record data for connections that weren't marked by a three-way handshake. It stopped recording when a connection was torn down with an RST packet. This prevented our TCB desynchronization tests from disrupting the system; however, the strictness of SessionWall's implementation may be attackable as well (insertion of RST packets, for instance, could be used for evasion attacks). SessionWall validated IP and TCP checksums, and did not accept data without the ACK bit set. It did not appear to wait for acknowledgment before accepting data, however. We were able to desynchronize SessionWall-3 from our connections by injecting fake SYN packets into our stream; the SYNs were ignored by the endpoint, but SessionWall apparently resynchronized to them and lost pattern matching state. Like NetRanger, SessionWall-3 also failed to detect data in SYN packets. SessionWall did not reassemble overlapping TCP segments in a manner consistant with 4.4BSD, and is thus vulnerable to an evasion attack. Like all the systems we reviewed, SessionWall-3 is completely unable to handle fragmented IP packets. An attacker can evade SessionWall-3 by fragmenting all her packets. 8.2.4 Network Flight Recorder NFR is a network monitoring engine by Network Flight Recorder. Unlike the other systems we tested, NFR is not an automated network intrusion detection system; rather, NFR provides a network monitoring component that can be used in a variety of applications. NFR is user-programmable and extensible, and available in source code. We reviewed NFR because its engine could be used as an automated network intrusion detection system. This is not the intent of the product, and our results do not have significant bearing on NFR's non-security uses. Additionally, because NFR is completely programmable (the product is really an interpreter for a network programming language), it is possible for users of the product to address many of the concerns we bring up in our paper without modifying the underlying engine. NFR was able to handle IP fragmentation; we verified this in an independent testing process that confirmed NFR's ability to reassemble a fragmented UDP packet (we were able to perform this test because of NFR's available source code). Unfortunately, NFR was unable to handle pattern matching in a TCP stream that was sent in fragmented IP packets; it therefore ``failed'' all of our fragmentation tests. NFR, in version beta-2, was vulnerable to all our insertion attack tests. It did not verify IP or TCP checksums, and accepted data without the ACK bit set. NFR detects data in SYN packets. NFR does not immediately tear down a connection TCB when an RST is seen. We were able to desynchronize NFR by sending spurious SYN packets in our connections, but were unable to successfully desynchronize it with any of our other tests. NFR did not reassemble overlapping TCP segments consistantly with 4.4BSD, and is thus vulnerable to an evasion attack. 9 Discussion Our tests revealed serious flaws in each system we examined. Every IDS we examined could be completely eluded by a savvy attacker. We have no reason to believe that skilled attackers on the Internet don't already know and aren't already exploiting this fact. Many of the problems we tested for were minor, and easily fixed. The very presence of such vulnerabilities leads us to believe that ID systems have not adequately been tested. The ability to forge packets, and the ability to ``insert'' packets into ID systems, makes it fairly trivial for an attacker to forge ``attacks'' from arbitrary addresses. The ability to react to attacks by reconfiguring packet filters was a major advertised feature of many of the systems we tested. Our work shows that this capability can be leveraged against the system operators by an attacker; these facilities may do more harm than good. Several of the problems we outline in this paper have no obvious solution. Without adding a secondary source of information for the IDS, allowing it to conclusively identify which packets have been accepted by an end-system, there appear to be ways to create connections that cannot be tracked by passive ID systems. Since the network conditions an attacker needs to induce to elude an IDS are abnormal, an IDS may be able to detect that an attack is occurring; unfortunately, this will be all that an IDS will be able to say. Regardless of whether a problem is obviously solvable or not, its presence is significant to both IDS users and designers. Users need to understand that the manner they configure the IDS (and their network) has a very real impact on the security of the system, and on the availability of their network. Designers need to understand the basic problems we identify with packet capture, and must begin testing their systems more rigorously. Finally, the security community (buyers of network ID systems, designers of such systems, as well as interested third parties like us) as a whole can do much to enhance the reliability and security of intrusion detection systems. Additional, independent third-party analysis and testing of ID systems will, to a large extent, define how secure these systems will be in the future. 9.1 Implications to Operators There are several things that can be done by IDS operators to enhance the overall security of the system as a whole. Additionally, IDS operators need to understand that the outputs of their systems must be read critically; ``session playback'' data may not represent what's actually occurring in a session, and the source addresses of attacks may not be valid at all. One critically important step that must be taken before an IDS can be effectively used is to set up ``spoof protection'' filters, which prevent attackers on the Internet from injecting packets with addresses forged to look like ``internal'' systems into the network. Bidirectional packet forgery can completely confuse network intrusion detection systems. It's important to understand that an attacker that successfully breaks into an IDS-protected network probably controls the IDS. An attacker with direct access to the network she's attacking can forge validlooking responses from systems she's attacking. These forged packets can prevent the IDS from obtaining any coherent picture of what's happening on the network. As soon as an IDS records a ``successful'' attack on the network, administrators should assume that all bets are off, and further attacks are occurring without the knowledge of the IDS. An attacker can fool ``session playback'' facilities into playing arbitrary data back to the operators. Session playback may not accurately represent what's happening inside of a connection. Real-time connection monitoring (when based on an ID system's reconstruction of what's happening in a TCP stream, rather than on printing and recording every packet on the wire) should not be trusted. Finally, it's of critical importance that ID system operators do not configure their system to ``react'' to arbitrary attacks. An attacker can easily deny service to the entire network by triggering these reactions with faked packets; ID systems that reconfigure router filters are particularly vulnerable to this, as an attacker can forge attacks that appear to come from important sites (like DNS servers), and cause the IDS to cut off connectivity to these sites. One possible step that can be taken to mitigate the risk of countermeasure subversion is to allow the system to be configured never to react to certain hosts. None of the systems we tested appeared to allow this type of configuration. Of course, if an attacker can spoof connections from the ``untouchable'' hosts, she can exploit this to evade countermeasures entirely. Attacks that can be trivially forged (ping floods, UDP-based attacks, etc.) should not be reacted to; an attacker can, simply by forging packets, cause countermeasures to be deployed that might disrupt the network. Systems that aren't strict about reconstructing TCP sessions (ie, that don't wait for threeway handshakes before recording data) present the same vulnerability for TCP connections as well. 9.2 Implications to Designers This paper has particularly great relevance to designers of intrusion detection systems, as it outlines in detail many attacks that such systems need to be resistant to. In that sense, this entire paper presents conclusions relevant to IDS designers. However, there are some overall issues that need to be addressed by IDS vendors. Most of the problems we outline in this paper occur only when very abnormal series of packets are injected onto the network. Overlapping IP fragments or TCP segments are not common; connections consisting entirely of overlapping segments are almost certainly attacks. Even if it's not possible to reliably reconstruct information contained in such streams, it is possible to alert administrators to the presence of the abnormal packets. Of course, this doesn't work as a design strategy; the value of an IDS is drastically reduced when all it can tell an administrator is ``I've detected an attack against this host, but can't tell you specifically what it is.'' Nevertheless, some information is better than the complete lack of information available now. The most important issue that vendors need to address is testing. Some of the problems we discovered were so basic (the conditions leading to these problems occur frequently even in normal traffic) that it appeared as if no indepth testing had been performed at all. We found severe flaws in systems that attempted to address problems --- for instance, a program that reassembled fragments, but could not perform signature recognition in packets that had been fragmented. Testing network intrusion detection systems is not simple. In order to test a network IDS, carefully coordinated streams of forged packets need to be injected onto a network; tools that are capable of doing this in a manner flexible enough to test ID systems are products in and of themselves. Our work defines the beginning of a framework within which ID systems can be tested, and, hopefully, the availability of our tools will increase the ability of vendors to test their systems. 9.3 Implications to the Community The number of attacks against network ID systems, and the relative simplicity of the problems that were actually demonstrated to be exploitable on the commercial systems we tested, indicates to us that network intrusion detection is not a mature technology. More research and testing needs to occur before network intrusion detection can be looked to as a reliable component in a security system. Much of this research must be done independently of the vendors. No credible public evaluations of network intrusion detection systems currently exist. The trade press evaluates security products by their features and ease of use, not by their security. Because network intrusion detection is so fragile, it's important that they receive more scrutiny from the community. Our paper defines methods by which network intrusion detection systems can be tested. It is obvious that our tests can be extended, and that our methodology can be improved. Everyone stands to benefit from such work, and it is hoped that our work can serve as a catalyst for it. One issue that drastically impacted our ability to test ID systems was the availability of source code. Only one product we reviewed made source code available. Because intrusion detection is so susceptible to attack, we think it's wise to demand source code from all vendors. Products with freely available source code will obtain more peer review than products with secret source code. If our work makes anything clear, it's that marketing claims cannot be a trusted source of information about ID systems. References [1] S. Staniford¡Chen, ''Common Intrusion Detection Framework,'' http://seclab.cs.ucdavis.edu/cidf/ [2] H. S. Javits and A. Valdes ``The SRI Statistical Anomaly Detector,'' In Proceedings of the 14th National Computer Security Conference, October 1991. [3] S. Staniford¡Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, C. Wee, R. Yip and D. Zerkle, ``GrIDS -- A GraphBased Intrusion Detection System for Large Networks,'' In The 19th National Information Systems Security Conference, 1996. [4] K. L. Fox, R. R. Henning, J. H. Reed and R. P. Simonian, ``A Neural Network Approach towards Intrusion Detection,'' In Proceedings of the 13th National Computer Security Conference, October 1990. [5] P. A. Porras and A. Valdes, ``Live Traffic Analysis of TCP/IP Gateways,'' To appear in Internet Society's Networks and Distributed Systems Security Symposium, March 1998. [6] N. F. Puketza, K. Zhang, M. Chung, B. Mukherjee and R. A. Olsson , ``A Methodology for Testing Intrusion Detection Systems,'' IEEE Transactions on Software Engineering, vol. 22, pp. 719-729, October 1996. [7] M. StJohns, ``Authentication Server,'' RFC 931, TPSC, January 1985. [8] W. R. Stevens, TCP/IP Illustrated, Vol 1. Addison¡Wesley, Reading, MA, 1994. [9] J. Postel, ``Internet Protocol ¡ DARPA Internet Program Protocol Specification,'' RFC 791, USC/Information Sciences Institute, September 1981. [10] J. Postel, ``Internet Protocol ¡ DARPA Internet Program Protocol Specification.'' RFC 791, USC/Information Sciences Institute, Section 3.2, line 1099, September 1981. [11] R. Atkinson, ``Security Architecture for the Internet Protocol.'' RFC 1825, Naval Research Laboratory, August 1995. [12] J. Postel, ``Transmission Control Protocol ¡ DARPA Internet Program Protocol Specification,'' RFC 793, USC/Information Sciences Institute, September 1981. [13] V. Jacobson, R. Braden and D. Borman, ``TCP Extensions for High Performance,'' RFC 1323, LBL, ISI, Cray Research, May 1992. [14] L. Joncheray, ``A Simple Attack Against TCP,'' In 5th USENIX UNIX Security Symposium, June 1995. [15] Secure Networks, Inc., Custom Attack Simulation Language (CASL), User manual, 1998. [16] Avian Research, netcat, Available for download at ftp://avian.org/src/hacks/nc110.tgz [17] V. Paxson, ``Bro: A System for Detecting Network Intruders in Real¡Time,'' In 7th Annual USENIX Security Symposium, January 1998. [18] V. Paxson, ``End¡to¡End Internet Packet Dynamics,'' In ACM SIGCOMM '97, September 1997, Cannes, France. [19] Lawrence Berkeley National Laboratory, tcpdump, Available for download at ftp://ftp.ee.lbl.gov/tcpdump.tar.Z Thanks This work would not have been possible without the assistance of many people. Several people gave us valuable input and criticism, and some of our tests would not have been possible without the cooperation of companies running ID systems. We'd like to express our sincere appreciation for this help. This work was made possible by Secure Networks, Inc. We'd like to thank Alfred Huger, Oliver Friedrichs, and Jon Wilkins for their assistance with this project. We obtained valuable comments from several of the vendors we reviewed. We'd specifically like to thank Marcus Ranum of Network Flight Recorder, Mike Neumann of EnGarde, and Elliot Turner of MimeStar for their comments and critiques of our technical work. Vern Paxson of LBL published, as this document was being finished, a paper regarding the design of his real-time network intrusion detection system, ``Bro''[17]. His paper details several attacks against network ID systems (many of which we did not catch ourselves). We'd like to thank Mr. Paxson for his extremely valuable input on our own work. Of course, we appreciate greatly the fact that Network Flight Recorder made their source code available to the public for review. This was a courageous and honorable thing to do (especially in a market as competitive as this), and NFR's approach to source code release is a model that should be followed by other vendors. Finally, this paper would not have been possible without the assistance of Jennifer Myers at EnterAct, L.L.C., who effectively rewrote our technical results into a coherant document. About CASL Our tests were made possible by the development of a security tool called CASL. CASL is a network protocol exploration tool designed to allow security auditors to quickly and easily simulate network events at a very low level. With a minimal amount of effort, CASL can effectively be used to forge any kind of IP packet. With slight programming ability, CASL can be used to perform complex protocol interactions with other networked hosts. CASL was inspired by tools like Darren Reed's well-known ``ipsend'' utility, which allowed experimenters to forge a large number of IP packets. However, CASL expands significantly on these types of tools. Some of the benefits of CASL over its predecessors include: A complete programming language, with most typical high-level language control constructs (e.g., ``if'', ``while'', and ``for'' statements), and designed to be as easy to learn and use as shell-script languages, but with network programming functionality rivaling that of ``C'' code. The ability to create arbitrary packets --- not just the ones we thought up as we designed the program! Unlike some tools, which allow users to to create arbitrary packets by including ``raw'' data (presumably built with some other tool), CASL allows users to lay out the format of new packet types with an expressive and simple ``record'' syntax, allowing protocol header fields to be laid out bit-by-bit and byte-by-byte. The ability to input packets, reading promiscuously off the wire, and quickly extract information from them. Network reads use familiar ``tcpdump'' expressions to select packets, and any number of packets can be read in and examined simultaneously. CASL is a self-contained, free-standing program that doesn't depend on other network or programming tools to operate. It can be installed quickly, and a CASL script will work on any supported platform. The tool is small, and consumes a fairly low amount of resources; CASL programs can easily share a system with other large applications, and don't consume the large amounts of memory and CPU that general-purpose languages (like Perl and Tcl) tend to. We designed this tool to meet the needs of two very different audiences: on one hand, CASL is expressive and powerful enough to be a useful tool for experienced, fluent ``C'' programmers; on the other, it's simple enough to be picked up by a nonprogrammer as quickly as Bourne shell scripting. A CASL script can be little more than a 5 line packet template for users who simply want to forge packets, or it can be tens or hundreds of lines of functional code, with loops, variables, conditionals, subroutines, and other high-level-language capabilities. We are making CASL available for free for noncommercial use, in the hopes that it can be used to further the state of the art in security research. For more information about CASL, contact Secure Networks Inc. About Secure Networks, Inc. Secure Networks, Inc. is a security research and development company located in Calgary, Alberta, Canada. In addition to extensive publically available security research results, Secure Networks also sells security assessment tools. You can find out more about our work at http://www.secnet.com. Secure Networks is reachable via email at ``[email protected]'', and via telephone at 403-262-9211. Intrusion Detection Resources Introduction This site is a listing of many of the internet resources associated with Intrusion Detection. The list is divided into sections to make finding information easier. It would be great if all our computer systems were totally secure but, unfortunately, they are not and will not be anytime soon. And even if they were, there is always the possibility of an authorized user misusing his or her privileges. The purpose of an intrusion detection system (or IDS) is to detect unauthorized access or misuse of a computer system. Intrusion detection systems are kind of like burglar alarms for computers. They sound alarms and sometimes even take corrective action when an intruder or abuser is detected. Many different intrusion detection systems have been developed but the detection schemes generally fall into one of two categories, anomaly detection or misuse detection. Anomaly detectors look for behavior that deviates from normal system use. Misuse detectors look for behavior that matches a known attack scenario. A great deal of time and effort has been invested in intrusion detection, and this list provides links to many sites that discuss some of these efforts. The field of intrusion detection is fast-paced and rapidly changing. If you see something we've missed or have any suggestions, please let us know using this comment form. Intrusion Detection Systems Research Projects AID (Adaptive Intrusion Detection system) ASAX (Advanced Security audit trail Analysis on uniX Autonomous Agents for Intrusion Detection EMERALD (Event Monitoring Enabling Responses to Anomalous Live Disturbances) Electornic Commerce and Financial Information Systems: Widely Distributed Data Mining and Fraud Detection GASSATA (Genetic Algorithm for Simplified Security Audit Trail Analysis) GrIDS (Graph-based Intrusion Detection System) IDIOT (Intrusion Detection In Our Time) Misuse Detection Project NADIR (Network Anomaly Detection and Intrusion Reporter) Neural Networks Intrusion Detection Project NID (Network Intrusion Detector) USTAT (State Transition Analysis Tool for UNIX) Commercial Products VCC/TripwireTM CMDS (Computer Misuse and Detection System) by SAIC INTOUCH NSA (Network Security Agent) by TTI Kane Security Analyst by Intrusion Detection, Inc NetRanger by Wheelgroup OMNIGUARD Intruder Alert by Axent POLYCENTER Security Intrusion Detector by Digital Real Secure by ISS Stalker by Haystack Labs Watch Dog by InfoStream Other Lists of Intrusion Detection Systems COAST Intrusion Detection Systems Michael Sobirey's Intrusion Detection Page NIST Intrusion Detection Tools Intrusion Detection Bibliographies COAST Intrusion Detection Bibliography Michael Sobirey's IDS Bibliography NITB's Intrusion Detection Reference Collections Mailing Lists Intrusion Detection Mailing List Archive Other Resources COAST Intrusion Detection Pages MCN's Intrusion Information NITB Intrusion Detection and Response Katherine Price Last modified: Sat Jul 18 10:23:49 EST 1998 How to Handle and Identify Network Probes "What to do when your DNS server gets FIN-SYN scanned from Russia at 4:00 in the morning." By Ron Gula April 1999 mailto:[email protected] http://www.network-defense.com Copyright 1999 Network Defense Consulting Abstract Do you know what to do when suspicious network probes are detected on your network? It's surprising, but many people do not follow common sense and simple logic when analyzing malicious network activity. Even worse, when contacting other organizations to complain, security incidents can be misrepresented because all of the facts are not in order, incorrect or even erroneous theories. This paper details a variety of steps that you can take to get the most effectiveness and accuracy from your intrusion detection system. It also concentrates on determining the who, what, why, where, when and how of any network security event so that you can accurately relay this information to others. Introduction This paper is loosely organized into a list of rules that can be applied to your network operation in the event of an external network scan. Each rule has several examples of what can go wrong and what can go right for a given situation. The rules are also in the order they should be applied in a network security situation. The last section discusses how to handle internal security events at a high level. Please use this paper as a guide. Think about it and what it means for your particular network. It may make the difference between deterring a network attack and having to respond to a network compromise. Rule #1: Don't Panic It's 2:00 AM. You are in a deep sleep when suddenly the phone comes to life. Speaking to you is a late shift network operator who is frantically describing a list of ISS RealSecure events. The operator also describes that the firewalls are also going crazy and two NT machines just mysteriously rebooted. The VP of Operations has been notified and she is on her way in. What do you do? Even though network security events are reported in the media and they are a very serious threat, they are not likely to occur to you on a daily basis. (If they are occurring to you on a daily basis you must be pretty good at dealing with them by now and probably don't need this paper.) Most network organizations that suffer multiple attacks and probes experience them in groups. They are not sporadic events. With this in mind we can roughly classify network probes into two categories. First, the security event could actually be the result of a non-security event. This is known as a 'false positive'. In this case there is nothing to worry about. Second, the security event could have been a probe that tested your site for something. Tests could include determining the type of operating system of a server or even sweeping the network for open ports. If the probe turns up negative, there is a good chance that 'they' won't be coming back. With this situation, there is also little to worry about. At your leisure, you can pursue those responsible for the probe. If the probe seems to have found something that is vulnerable, then you may have returning visitors. Regardless of the outcome of the probe, it requires careful analysis and some judgement calls to determine its nature. That's what the rest of this paper is about. When presented with a security event, all you really know is that further investigation is required. However, knowing that these things don't happen that often shouldn't cause you to put the analysis of the event off to long. Timely analysis of any security event is the key to quickly finding the real ones from the false positives. Panic or at least an adrenaline rush is experienced by many network administrators when security incidents occur. Here are some rules of thumb to keep in mind when handling the situation. Initially, only tell people about the security event on a need to know basis Telling one person who tells another can cause any office or operations center to quickly fill with people who are not the right ones to deal with the problem. They may also get in the way. Discretion is highly recommended. Watch out for overworked people When any network event occurs, there is a tendency for normal people to rise to the challenge and work long hours to see the event through. Security events are no different. If an event occurs at the end of a normal duty day or a shift, people working extra hours may suffer from fatigue, irritability and hunger. All of these can impair the judgement of any person. It may also endanger them for their ride home. Later on we discuss the importance of documentation. Documentation and tracking of a security event can make change over between employees much easier. Don't let people jump to conclusions During high pressure situations, some people may feel the need to blame others in an attempt to find answers. It's important to downplay any of these comments until all of the facts are considered. Get second opinions on 'rash' decisions When conducting a security investigation, it is very important to get input from peers and even management about your current theories and plans. For example, it may seem like a good idea to take the corporate web server offline for analysis, but a second opinion might ask you to stand up a replacement. If probes are occurring in real time, it is also temping to take certain courses of action such as 'hack backs', setting up of honey-pots or even trying to slow the scanning down. All of these actions may have unintended repercussions on your company or network. Focus on any obvious explanations It may not seem obvious, but suspicious activity can be explained away most of the time with normal network events. Consider recent network changes or scheduled network testing when analyzing a security event. Like it or not, as the network security guru, you are also in a position of leadership during security events. If you are not sure of yourself, panic stricken or exhibiting a high level of stress, these traits can easily spread to other people. In ideal situations, the network security staff (if there are more than one of you) is regularly involved in network operations. Knowing your co-workers and making sure that they know you will reduce stress and panic during security events. "Don't worry", you say to the late shift operator, "I will dial in and check the logs. Tell Beth I'll give her an initial status report in about fifteen minutes. If it looks bad, I'll be coming in." Rule #2: Document Activity It's Monday morning and you receive a call from the Vice President of Information Security. He wants to know how many network probes we have received over the last three months and if any of them came from our competitors. What would you tell him? When any network security event occurs, you should document it. It doesn't matter how you record the information as long as it is secure, accurate and can be stored for some time. I like to keep a log book, but log books can be lost. Some network shops record suspicious logs directly to CD-ROM. More and more network shops are using ticketing systems to track security events. These have the advantage of existing in a database which can easily be searched for event correlation. You need a solution which is right for you. Why document? There are several reasons: People forget, even security gurus Having a physical record of security events from days gone past is an immense help when analyzing security events of today and tomorrow. Being able to answer questions like, "Has this IP address ever scanned us before?", or "How many other IMAP probes have we had this year?" can only be answered by reviewing historical logs. Security systems may not keep logs forever Some security programs do not keep logs forever. They delete old logs to make room for new ones. If you have a system such as this, then those security events from last month might not be in your security system any more. Keeping logs separate from the production systems ensures a greater level of data protection also. What happens if you have a hard drive crash? Many security systems do not use back-ups for data integrity. It might be evidence in court If you keep good logs (and good is subject to lawyer's interpretation), then those logs may be used as evidence in a court case. It is very important to keep a 'chain of evidence' with any log system. This means you need to have proper access control on the log information. If the security or integrity of the log can be questioned, then the log may not be admissible in court. Paper print outs and CD-ROMs tend to be more believable than electronic media. Even logging of DNS names instead of IP addresses may be an issue, since DNS name resolution can be corrupted. It helps you sell security If you are like most companies, network security is viewed as an important but expensive thing. Firewalls, intrusion detection systems and conferences to Black-Hat are all expensive. Keeping logs can help show management that there is indeed a threat and they are getting their money's worth from you and the fancy security equipment. Final thoughts: During the heat of the moment is when it is most important to write down or record any information about a security event. Don't forget to record the people involved, their phone numbers and what they have said. Recording all of the information allows for more efficient processing of the data once it is assembled together. Later on, when things are less hectic, it is good practice to write up the security event in a one or two page paper. Sharing this paper with any lessons learned can have a very positive effect on your entire network staff. Keeping records of these reports can also help you and possibly your successor. "I can have a report for you this afternoon," you tell the VP of Information Security. After hanging up, you leave your Quake 2 session and start to work on the report. You utilize the last three monthly security incident reports and look at some of the more interesting recorded logs from those events. You conclude that your network was probed four times, all from Asian IP domains, but never from your competitor's address space. You deliver the report to the VP and emphasize where the information came from and how the security staff is responsible for maintaining it. Rule #3: Identify Activity While looking at the intrusion detection logs, you observe a variety of TCP packets going only to your DNS servers. The TCP FIN and SYN flags are set in each packet. The destination ports for the packets are ports 0, 21, 143 and 2049. None of those ports are active. What is going on? Depending on the situation and the available information, it can be very difficult to get a clear picture of all aspects of a security event or network probe. Distinct events may not seem related until another piece of the puzzle is added for clarity. Attempting to answer the basic questions of who, what, why, when and where is a good place to start and can provide you with a framework to paint a picture of what has transpired. WHO? If this is a network security event, then you are probably obtaining network data from an intrusion detection system, a firewall or some other network element. In most cases you know the source and destination IP addresses involved. This is the 'who' and there are a wide variety of tools that can be used to glean information about the owners of the addresses. nslookup This tool is available on NT and UNIX. The command can convert IP addresses to DNS names and vice versa. It is usually a good place to start to get some quick information about a suspicious IP address. Some care should be taken though. DNS information can be spoofed. One of the neatest hacks is to modify DNS answers to throw network security investigators off of your trail. DNS queries may also be observed by the network attacker. This may alert them that their scanning has been discovered. Many ISPs have taken to naming their dial-up PPP or SLIP addresses with the word 'dial', 'ppp', 'modem' or 'slip'. If you see these, there is a good chance that the source of the scan is a modem user. Similar assumptions can be made for 'home.com' names in which those IP addresses are assigned to cable modems. Consider obtaining a shell account well away from your corporate network to conduct DNS lookups. This may not alert the scanner that you have detected their activity. whois Once you have a DNS name, you can query the 'whois' database to find out contact information for that domain. When domains are registered, they usually require some sort of contact information to include a phone number, an email address and a name. Don't underestimate that the name in the 'whois' database could be the fellow doing the scanning. It's unlikely, but it has been known to happen. There are a variety of web interfaces to the 'whois' database and UNIX clients have a built in 'whois' command. Here is example 'whois' output for network-defense.com which has been slightly modified: [root@gigan /root]# whois network-defense.com [rs.internic.net] Registrant: Company Name (NETWORK-DEFENSE-DOM) 9305 Sun Down Pl Nowhere, MD 21047 US Domain Name: NETWORK-DEFENSE.COM Administrative Contact, Technical Contact, Zone Contact: Gula, Ron (RG15449) [email protected] 410-212-9898 Billing Contact: Gula, Ron (RG15449) [email protected] 410-212-9898 Record last updated on 24-Nov-98. Record created on 24-Nov-98. Database last updated on 7-Apr-99 12:28:52 EDT. Domain servers in listed order: NS.AUTONO.NET 209.48.2.11 NS10.AUTONO.NET 206.86.247.30 It can be seen here that there is a lot of information that can be used for documentation and contact purposes. There is a home address in case you want to launch Tomahawk missiles and a telephone number for voice contact. There is also an email address and a listing of which root level DNS servers 'take care of' the queried domain. arin The ARIN [1] database is publicly available at http://www.arin.net/whois/arinwhois.html and allows one to find out the owners of a particular IP address. When DNS has not offered an answer to what a search, doing a reverse IP lookup at ARIN can still provide useful information. Here is an example ARIN search output for 24.3.17.92 which is a home.com IP address: @Home Network (NETBLK-ATHOME) ATHOME 24.0.0.0 - 24.7.255.255 @Home Network (NETBLK-MD-COMCAST-HWRD-1) MD-COMCAST-HWRD-1 24.3.16.0 - 24.3.23.255 This query provides us with some interesting information. First, we know that the IP address is part of the home.com (@Home) ISP. A lot of hackers get cable modems. A lot of hackers hack people with cable modems. The second pieces of information tells us that @Home is using the Comcast Cable company for local access. One could even venture a bet that the 'MD' referred to Maryland and the 'HWRD' referred to Howard county. It's dangerous to assume things like this, but in some cases it makes sense. For instance, not every net block that has a 'TX' in it is from Texas. Use good judgement. The Web If you know the IP address of a network probe source, you may want to try to look for web servers on that network. An easy way to do this is through guess work. Let's say a target's DNS name resolves to name1.place.com for an example. Attempting to go to the web server at www.place.com may provide you with the network's public web server. In some cases, using a tool such as Nmap[2] to scan a class C network for any web server can be fruitful. This should only be done as a last resort. In ISP networks, scanning a class C network may not bring you any closer to information about the scanner as you connect with one unrelated user's web page after another. The goal here of course is to discover some sort of contact for you to voice your distress over the network scanning. It is also very important to understand exactly 'who' locally is involved in the scanning. Recording IP addresses is not enough. What is the second level relationship between them. Is this a sequential scan? Are these systems mail systems? Do they run IRC daemons? Are they all DNS servers? You get the picture. Figuring this out may allow you to understand what drew the network scanners to your network in the first place. WHAT? Determining what a network scanner is probing for can be a very difficult activity. I offer some general guidelines to analyze suspicious activity, but no one can be certain exactly what the intention of a particular scan is without asking the person doing the scanning. More importantly, we discuss a variety of scanning techniques and the type of information that the scan returns. Using this to analyze activity on your network can be interesting. We do not consider techniques for direct vulnerability probing because this is a very cumbersome topic and a lot has been written about it already. Topology Mapping Much suspicious network activity concerns discovery of target network and systems by malicious individuals. Sophisticated attempts exist that can map out a network. Attackers equipped with knowledge of a network's hierarchy can plan effective attacks. Here are some common and not so common topology scanning techniques that you may observe on your networks. ICMP Sweeps ICMP packets may be used to determine if a target IP address is alive or not. Typically, a scanning program may send an ICMP ECHO REQUEST packet and anticipate an ICMP ECHO RESPONSE. When multiple hosts are queried this way, it is better know as a 'ping sweep'. If the host isn't there, there is no response. Firewalls and routers can be used to block this sort of traffic. This type of scan can be directed at one host, or many. It can also be spread out over time such that a target network may not become alarmed that it is being scanned. More advanced ICMP scanning techniques make use of non-ECHO ICMP protocols. There are a wide variety of ICMP protocols besides ECHO. These include support to request timestamp and netmask information. Many firewall and packet filter designers forget to block all ICMP traffic and only filter ECHO traffic. In this case, making non-ECHO requests is still a valid form of host identification. The ICMP protocol can also be used with broadcast addresses. Typically associated with ICMP denial of service attacks, ICMP broadcast packets may be able to map out large portions of a network with one packet. TCP/UDP Sweeps Most people associate TCP and UDP scanning with determining which ports are available on a particular network server. The reality is that responses from any port may indicate that an IP address is active. Sending a UDP or TCP packet to a high port and receiving a response is a good indication that something is there. Exactly what comes back depends on the target operating system, the packet sent and any firewalls or packet filters. TCP packets have flags that indicate which part of a TCP conversation they are in. Typically, TCP sessions start with a SYN packet from a client to a server. This is followed by a SYN-ACK packet from the server to the client if the target service (or port) is active. If it isn't, then the server responds with a RESET packet. Both the SYN-ACK and the RESET packets can be used to identify active IP addresses by network scanners. It should be noted that some firewalls can spoof a RESET packet from an IP address, so that technique may not be that reliable. UDP scanning is tougher to do than TCP for a variety of reasons. First, UDP packets can be dropped by routers as they cross the Internet. This is true! Try it for yourself! (Use a program to send UDP packets across the net and see how many actually get there). Second, many UDP services don't respond when correctly probed. It's the response of an ICMP PORT UNREACHABLE message that identifies a UDP port that is not active. Considering that UDP packets may be dropped, and firewalls may also be configured to drop them, UDP scanning may seem very unreliable. UDP scanning does have an advantage of being able to make use of IP broadcast addresses. A network that allows UDP packets could be mapped by sending a packet to the broadcast address on a high port. If the port were not filtered, then the scanning node would receive ICMP PORT UNREACHABLE messages from many target network systems. SNMP Scanning The Simple Network Management Protocol (SNMP) is used and supported by a wide variety of network elements and network management software. Modern hubs, switches and routers all support SNMP. Many servers such as Solaris and Windows NT also have SNMP functionality. SNMP has several versions, the most common of which is version 1. Security in version 1 is handled by a clear text community string that functions as a password. Any SNMP packet must have the proper community string. Without it, the packet is rejected. The problem with SNMP is that all network vendors ship their products with default community strings of 'public'. Any scanner that has access to SNMP enabled network nodes simply uses the 'public' community string and starts to send queries. Data obtained over SNMP can completely diagram a network and include other information such as CPU type, firewall rule configurations and even web server performance. Tools exist that help attackers brute force community strings. Obtaining Router Configurations Another way to map a network is to get a copy of some router configuration files. With enough different router configurations, a network scanner can map your network without sending any packet probes. I've even been on some penetration tests where a network organization has published there router configurations publicly on a web server! This information should be protected. Many routers and network elements such as hubs and switches also have vendor passwords that are used for diagnostics and maintenance. These passwords are well known to network crackers and can easily be used to obtain configurations, which in turn can be used to map a network. Some routing protocols allow for polling of route information. RIP is a classic example of this. With RIP, any client can query another network device to obtain the routing table. Time To Live Almost every one has used the 'traceroute' program. This program discovers the number of hops between IP addresses. It does this though the use of the IP time-to-live value. Every time a packet is routed, this value decrements by one. When the value is zero, the packet is discarded and an ICMP error message is returned to the sending IP address. The TTL prevents packets that are misrouted from floating around on the Internet forever. By purposely sending out packets with low TTL values and watching for the ICMP error messages, automated programs can be used to discover how many hops (routers) there are between them and a particular IP address. When attempting to map the topology of a remote network, combinations of 'traceroute' attempts can provide a good picture of how the network is put together. Attackers can use this information to find subnetworks that may be weakly defended and possibly exploit trust relationships. Scanning with non-standard IP Protocols Another technique to map out a network and identify live hosts is to send IP packets to target networks that are non-standard protocols. Lets assume that the 'standard' IP protocols are ICMP(1), TCP(6) and UDP(17). Most firewalls and packet filters designers tend to focus on these protocols when designing firewall rules. They may inadvertently allow traffic from other protocols. There are 128 possible IP protocols. Experimenting with different operating systems may show a way to remotely identify certain types. If so, then a network scanner may be able to illicit a response from a target IP address by sending in this sort of 'non-standard' traffic. The response will most likely be an ICMP PROTOCOL UNREACHABLE message. Some of these protocols may also be sent to the broadcast address. Multicast Packets The last example of scanning to discover a target network's topology is by exploiting multicast packets. Multicast IP addresses have been set aside by the Internet community and are handled different by routers and servers. With multicast packets, one IP address can theoretically send the same packet to many other IP addresses. If a network scanner is 'upstream' from you, they may be able to send multicast packets into your network for mapping purposes. The scanner needs to be upstream so that the multicast packets go only to the target and not to the rest of the Internet. Being 'upstream' is required so the scanner can correctly spoof multicast packets only to your network. Some packet filters and servers ship with multicast functionality enabled. This can be exploited by remote network scanners to discover live hosts. Remote Operating System Identification Another piece of information that network probes attempt to discern is the type of operating system of a given IP address. There are a variety of methods that exist to do this and we discuss them here. These scanning techniques are very popular in the hacker community. Banner Grabbing If a system is not secured behind a firewall or through disabling of network resources, then most services can be used to identify an operating system. The TELNET banner is a classic example of this. Almost all TELNET banners have a very distinct look about them and actually say what the operating system is. Other services such as mail transfer agents can identify the operating system too. DNS names If you observe many DNS queries, a remote network scanner may gain knowledge of your operating systems if you've named them descriptively. Many DNS schemes include the operating system. Examples such as 'node123-w95.example.com' and 'nt4-102.example.com' could name Windows 95 and Windows NT systems. TCP Trickery A technique that uses distinct variations in TCP stack implementations to determine the type of remote operating system is known as TCP fingerprinting. The basic concept of this probe is to send specific TCP packets to an IP address and observe the response. The TCP traffic sent is a rather odd combination of destination ports and flag combinations. TCP responses are also considered in the identification process. These responses include sequence number randomness and initial window sizes. There are probably other techniques. Several tools exist such as QueSO [3] and Nmap that have a large database of responses to these odd TCP probes and can be used to reliably identify servers and network elements. Some of the more common techniques you may see are TCP probes that have the FIN and SYN bits set. This combination does not occur naturally. (At least I have not observed it). Other flag combinations used are nulls which have no flags set and SYN-RESET. Both of these scan types occur naturally in a variety of network traffic such as normal web browsing. This is important to consider because every TCP packet that has no flags set is not part of an operating system probe. Consider the source. Strange TCP packets to high volume DNS(53) and WEB(80) servers may be explained. But a few stray packets to low volume ports such as IMAP(143) and NFSD(2049) should be viewed as suspicious. One of the more advanced scanning techniques I've come across is the use of a bogus 'error' packet. The packet is TCP with a normal IP header. All of the TCP data is identical except for the TCP flags. For example, the TCP packet could entirely consist of bytes with the value of '0x4e'. This would correspond to a source and destination port of 20046. But for the TCP flags, the correct bit values for a FIN-SYN or a SYN-RESET would be used instead of '0x4e'. If the packet is recorded, it may look like an error packet and be ignored by a network analyst. But it could be performing remote operating system identification. Standard services When trying to identify a particular remote operating system, another technique used is to probe for specific combinations of ports. These port combinations can reliably identify the target platform. Testing for DNS or SMTP services are not distinct enough for scanners to test for because they are very common. However testing for servers that have IMAP(143) and NFSD(2049) active may indicate the Linux operating system. Solaris servers have a variety of RPC services that are enabled by default. The same goes for HP-UX and SGI. Network scanners who know these combinations can identify target systems this way. Peculiar Behavior Some network nodes may exhibit very odd or strange protocol behaviors. This can best be illustrated with an example. Cisco routers communicate with each other on port 1999. During the three way TCP handshake, the Cisco router will identify itself by placing the word 'cisco' in the data portion of the SYNACK packet. This is a very trivial way to identify Cisco routers. Knowledge of this type of behavior can help discreetly identify remote systems. Port Scanning Techniques Many network probes are attempts to discover active services on a network or on a particular server. Typically, these scans are automated and connect with ranges of ports for a given IP address. They then report the ports that were open or active. Network attackers can then select exploits based on the active ports found. Here are some different port scanning techniques that you may encounter when analyzing network probes. Slow Scanning Since typical port scans can show up in system logs (syslog, Klaxon [4], etc. ) , network scanners can simply spread out the scan over a long period of time. Determining if a single packet is part of a larger port scan is very difficult if the other packets aren't there. Depending on the level of network activity, it may be possible to avoid detection simply by delaying scan packets for one minute. Random Scanning Again, another way to avoid port scan detection is to randomize the order in which the ports are tested for. Many commercial IDS products and firewalls watch for sequential connection attempts. They may have a threshold of common sequential destination ports and when this threshold is crossed, a port scan is reported. Randomizing the port testing avoids exceeding the sequential destination port threshold. SYN Scans A SYN scan is yet another attempt to bypass system level port scan detection. On most systems, a network connection is only recorded if the TCP three way handshake is completed. SYN scans send a single SYN packet to the destination port and then wait to see the response. If the response is a RESET packet, then the port is dead and no further action is taken. If the response is a SYN-ACK packet, then a RESET packet is sent back to the target that disengages the three way handshake. Sometimes this RESET packet is generated by the SYN scan program and other times it is generated directly by a response from the scanning operating system's IP stack. Spoofed SYN scan A trivial modification to the SYN scanning technique is to completely spoof the SYN packet from another IP address on the scanner's network. The spoofed IP address has to be one in which the return traffic from the server will flow past the scanner. It sniffs the network traffic to discover which ports are active. If a scanner is 'upstream' from a spoofed IP address (for instance in a DMZ in front of 10,000 computers) then it can be very hard to trace. The spoofed IP address can be from a machine that is alive or dead. This technique can also be used to generate many other simultaneous scans from other IP addresses. A defending network would perceive that it is being scanned by several different networks. The extra data can be missed by IDS nodes and can also be very hard to analyze. Determining the real IP address responsible for the scan is possible in some cases, but usually not. One way to tell if you are the victim of spoofed scans is to check for similar time-to-live (TTL) values in each of the scanned packets. If all of the incoming packets have the exact same TTL values, then this is suspicious. Conducting a 'traceroute' [5] to each of the IP addresses may allow you to eliminate some of the spoofed sources. Some network scanners such as Nmap randomize their initial TTL settings with a value between 51 and 65. Fragmented Scan In an attempt to hide their probes, network scanners may also fragment their packets. All IP packets that carry data can be fragmented. For TCP packets, fragmentation can occur in which the destination port is in one packet and the flags are in another. Network IDS nodes may incorrectly reassemble or completely miss portions of the scan. Fragmentation that places ports in one packet and flags in another is something that does not occur naturally on IP stacks. Proxy Scanning If a protocol or service can be exploited by a network scanner such that the service can make arbitrary network connections, then the protocol can be used for port scanning. Some proxy servers and most FTP daemons can be used to conduct port scans. The classic example is the FTP Port Scanner in which a surrogate FTP server is used to make many network connections to a target system. The FTP protocol allows for the client to specify which IP address and port the server should send data to. Information returned by the FTP server can be used to identify open or closed ports on the target system. Finding Targets of Opportunity Some scanning is only focused on one thing, finding vulnerable systems. This type of scanning is subjective, but basically involves a lot of automation. There are different strategies used by network scanners to find vulnerable systems. Here are a few of them: Wide Scanning Very simply, a network scanner will scan large sets of IP addresses for a particular service or set of services. Scanning usually encompasses 'Class B' ranges of IP addresses. This type of scanning can be identified by two factors. One, the scanning is very sequential. It is so sequential that computers not part of the range scanned don't see any traffic from the scanning host. Second, follow on activity from the scanning host usually doesn't happen for some finite amount of time. This could be a day or a few hours. It reflects the notion that a scanning program takes a long time to complete. Once it is complete, the person running the scanner usually starts to test out the data. Finding vulnerable servers using that service When looking for vulnerable servers, many exploitable services have their own system of organization. DNS is a classic example. If a hacker wants to find a list of DNS servers, there are a variety of tools and databases that can be utilized. The same goes for IRC, Usenet News and web crawlers. Probes that occur on your network may be the result of chance or they could be happening simply because you have that service! Your service is actually part of a larger network of services on the Internet. Later on we consider what draws hackers to one network over another. Access Control List Mapping Fire-walking Very recently, a paper was released [6] that detailed a technique dubbed 'fire-walking'. This technique combines port scanning and 'traceroute' tools. This tool analyzes the aggregate protocol map allowed to a particular host. In other words, this allows remote users to map out a particular set of firewall rules or access control lists. Knowing what sort of packet filter or firewall rules are present, can help an attacker plan their exploits. SNMP SNMP queries may be inadvertently allowed directly to firewalls and packet filters. If this condition is true, then remote network scanners could be able to obtain the exact filter rules for your network. Direct RPC Scanning Normal RPC scanning (rpcinfo -p) sends a query to the rpcbind program which is more commonly known as the portmapper. This query can ask for a list of all other RPC programs on the server. RPC programs historically have always existed around port 1024, or usually below that. Several years ago, Solaris and many other flavors of UNIX started to run RPC programs around port 32771. Many packet filter and firewall designers were unaware of this situation and deployed access control lists that did not prevent connections to these ports. In the case of 'normal' RPC behavior, it is possible for an RPC program to be assigned a port slightly above port 1024. If the firewall rules do not prevent this sort of connection, then the RPC service is directly accessible from external IP addresses. The same goes for RPC programs that are assigned ports above port 32771. These are a problem because they may be directly connected to. Network scanners may search for these 'high' RPC ports by using port scanning to identify ports and then conduct RPC queries to any ports that are open. If an RPC service is identified, it may have a vulnerability that can be exploited. WHY? Figuring out 'why' a particular suspicious network event occurred can be a very challenging and daunting task. The important thing to realize (and sometimes this only comes through experience) is that some things can't be explained. When an explanation seems to elude you or your staff, don't let it consume more and more resources. Prioritize your investigation and don't let it be hindered by not understanding exactly why something happened. For example, a server may have been rebooting sporadically and your staff suspects that a new denial of service attack is being used. Sniffing, intrusion detection and system security analysis indicate otherwise. Finally, a maintenance person discovers a faulty power supply. This example may seem trivial, but occurs many times on modern networks. Another example of a 'why' explanation is to consider the source of the security information. Many network management intrusion detection systems are complex and have many threshold levels for causing alarms to trip. If these threshold levels are drastically changed, then all of a sudden there may be many system alerts and possible intrusions. Try to identify any recent system changes that could attribute such activity. Unfortunately, all suspicious network activity can not be ruled out. Network probes should be considered hostile until you know exactly what you are dealing with. Why would someone want to break into your network? You tell me! There are many reasons for breaking into networks. Are they looking to deface a web page? Do you have political enemies that are network savvy? The good news is that you may have detected their early network probing efforts and now you can act accordingly. WHEN? Knowing when something happened allows you to construct a timeline or order of events. The order of events may be very crucial for determining the exact steps taken by hackers using network probes. Did they attempt a DNS zone transfer before we deployed the new DNS server? Did the scan on the internal web server occur after the firewall changes? These are example questions that depend on accurate time reporting. One key to determining the order of events is to use a common time source. The Network Time Protocol (NTP) is very reliable, accurate and resistant to a variety of attacks. NTP can be used to synchronize all network and server nodes with a very accurate and uniform time source. With all of them synchronized, log analysis becomes a lot easier. I also recommend trying to keep all of your systems on the same time zone clock. If you are unlucky enough to have servers in multiple time zones all keeping local time, then log analyses can become very cumbersome. With one unified time clock, it may be easier to detect network wide probes of your systems. Having a good and reliable time system is also crucial if you want to enter any of the logs into a court case as evidence. WHERE? When analyzing network probes, the question of 'where' is often overlooked. We are referring to the physical and electronic location of all of the computers involved, including the security systems. Identification of system locations is important to help understand and analyze recorded data. It may also explain why some information is missing or inaccurate. Confirmation of physical and logical location is often necessary when conducting an investigation. Your network maps may not be up to date. There have been cases when a simple network connection mistake has placed a vulnerable server outside of a protecting firewall. It may be helpful (and surprising) to obtain a remote account and conduct network mapping probes to see how things are connected. The use of Ethernet addresses can also be of great use when identifying the sources of spoofed IP packets. Although Ethernet packets can be trivially spoofed locally, they can't be spoofed across the Internet. This can help you determine which router or switch interface spoofed packets may have originated from. Analysis of the IP packets indicate an automated probe of only the DNS servers. Other ISP security contacts report their DNS servers have been scanned for similar ports. You theorize that the port 0 is being used to remotely identify LINUX servers. This theory is further corroborated when you also realize that ports 21, 143 and 2049 have all had recent LINUX remote buffer overflow attacks published. Rule #4: Determine if you are vulnerable Continuing with this scenario, you do a quick inventory check of the DNS servers and discover that one of them is a brand new LINUX install. The server is on the other side of the country and they won't be up for another four hours. What do you do? Every network security program should conduct regular vulnerability testing using commercial and free network security tools. It is one of the best ways to determine if you are at risk to common network attacks. But what if someone is probing you on a port that you have never heard of? What if they are probing you on a port that you thought had no security problems? There are several things you can do. The first thing to do is to identify the port if it is not well known to you. Set up a network analyzer and collect some traffic on that port. Analysis of the traffic may help identify it. There are a variety of proprietary network protocols such as PC Anywhere. These may seem very strange and unfamiliar to you. Another technique you could try is to take an inventory of all of your network software. This is unrealistic in a short time frame, but usually identifies a variety of programs (and protocols) that could cause the traffic you are looking for. If all else fails, consult the Internet news groups. There is a lot of open discussion about network protocols and you may be lucky enough to find one about yours. For example, when I first got my cable modem, I saw a variety of traffic to my computer that was UDP and port 22. All of the packets contained two bytes of ASCII data that were 'NQ'. I had no luck finding out what the protocol was until I stumbled onto a firewalls discussion list that was talking about PC Anywhere. Once you know the target, try to determine the threat. Again, this is very subjective. I try to look for recent vulnerabilities described in the various network security groups on the Internet. Recently, I've begun to observe scanning for port 21 on a variety of firewalls and intrusion detection platforms I have access to. Prior to this about three weeks ago, there were several posts that could remotely exploit the Washington University FTP daemon. It makes sense that people are looking for FTP servers to attack because this is a new vulnerability. Of course, the only way to know that you are vulnerable is to actually test the problem. You can be safe and disable the service if you don't need it, but not everyone has that luxury. Getting your hands on the latest exploits is usually not a problem. There are a wide variety of full disclosure security mailing lists and web sites. There are also a wide variety of consultants available to help you with this sort of thing. Testing your network lets you know what hackers and network scanners may see or already have seen. Don't believe that you may not be vulnerable to an attack just because an exploit has not be created for your particular operating systems and platforms. This is a trap that many system administrators fall into. For example, there are all sorts of remote buffer overflows written for the LINUX platform. Just because you are running a SPARC station, does not mean you are safe and out of harm's way. Ports of exploits to new systems can appear at any moment and any hacker worth his or her salt should be able to covert exploits between systems. If you are vulnerable, then you may have a problem. First of all, you've seen scanning and you think you are vulnerable. It would be wise to approach the box with caution as it may have been compromised. Second, you need to figure out what sort of impact that box has on the network so you can decide what actions you want to take to secure it. Can you down the box to make some patches? Is the box a single point of failure for the network? Can you protect the box by making a firewall rule change someplace else? The important thing here is to mitigate any negative impact on your network. Using a port scanner on the LINUX server finds five open ports including FTP(21), IMAP(143) and NFSD(2049). Your staff also confirms that the server is used for testing. Because of the malicious scanning, the possible vulnerabilities and its lack of impact on the network, you decide to disable the server. You connect to the west coast SSH gateway and disable the Ethernet port on the network switch, effectively isolating the server in case it was compromised. Rule #5: Tell Someone! Continuing with this scenario, you send some encrypted email to your counterparts on the west coast. You also leave some voice mail explaining the situation. Their security staff will conduct a forensic analyses of the server. Trying to keep everyone in the loop, you document the situation and email your management and selected operations people. You also contact the corporate security staff. You also consider putting the incident in your monthly security newsletter, but decide that the information is still need-to-know. It may seem surprising, but many security problems and events do not get reported for a variety of reasons. These reasons are a combination of technical and political factors that prevent a clear reporting system. We will discuss some of the specific reasons that security incidents don’t get reported. Blame Many system and network administrators do not report security events because they believe it will reflect poorly on them. An administrator may have previously boasted that "no one" can break into their network. Managers need to realize that these claims are ludicrous and should expect to see monthly security reports detailing suspicious network activity. Chain of Command Who should a security event get reported to? If an organization has not stated how to handle security events, then when one happens it will get handled ad hoc. Most people correctly assume they should tell their immediate supervisor. This is true, but if a security department exists that has been trained to handle security situations, then they may be kept out of the loop. It may also be unclear what your supervisor may do with the information. (They should inform their supervisor and so on.) Management Indifference It may be difficult to explain exactly why a specific type of network activity is 'bad' to inexperience management. Technology marches on and it is difficult to keep up with it for some people. However, this should not prevent an employee from reporting a possible security situation. Don't be afraid to use analogies to get your points across about network probes. Be prepared to demonstrate how an attacker could be probing your network to gain proprietary information. Management Overreaction The opposite of the above example is true. If a network manager is not accustomed to experiencing network probes and scans, then the first time they occur may be traumatic. The best way to handle this is to be up front about the threat to your networks when you talk with your manager or supervisor. Be wary of any drastic measures taken by your management such as calling the FBI or the newspapers. That may not be the best course of action for the given situation. The corporate security staff contacts you immediately. They have hired computer security consultants to conduct a penetration test of the corporate networks. So far you have been the only person to detect and report the scanning. Rule #6: Continue to Monitor On a different day, one of your TCPDUMP sensors starts to collect a variety of suspicious traffic. Someone had caused a bunch of RealSecure alarms a few days ago. You responded with placing some TCPDUMP sensors on your network that collected anything from the suspicious IP addresses. It is strange that none of this traffic has caused a RealSecure alarm. What could it be? Once security probes have been noticed, the most important thing that a network administrator can do to their network is to make sure it is monitored. Depending on you network, you may be able to leverage your operations center. You may also have to place extra intrusion detection sensors to monitor uncovered network sections. Some people may even wish to deploy packet analyzers. Regardless of your technique, it is important to keep a watchful eye for any suspicious activity. The heightened state of alert exists because your network has been probed and you have made a determination that a network attack may be imminent. When leveraging any operations center, its important that you give them as much information on how to contact you and to accurately describe the security situation. In security situations, most operations personnel will contact you when anything suspicious occurs. Unfortunately, this may include normal network performance problems such as routers failing and Windows NT machines blue screening for no reason. Giving an operations center access to the intrusion detection systems is also a good thing. Hopefully, this has already occurred on your network. Leveraging quality 24x7 people can only be effective if they are properly trained and have well planned security response procedures. If you choose to deploy extra intrusion detection infrastructure, then you really have two choices. You can change the current rules used by the IDS to be more sensitive or you can deploy completely new systems. All IDS products are 'tuned' to a particular network. Thresholds need to be set and when they are exceeded, alerts and events are recorded. In a hostile environment where an attack may be imminent, lowering these thresholds may record extra probing from an attacker. It will also record more false positives. Deploying more IDS platforms may also be an option. If you have portions of your network that are not covered by the current set of IDS platforms, then deploying additional sensors may expose further attacks or network probe activity. Some security gurus may also wish to deploy a set of packet analyzer filters. The most common of these is TCPDUMP. These packet analyzers are deployed with similar strategies to packet based IDS platforms. You want to expose them to as much traffic as possible. In a switched environment, there is a possibility that you may want to run TCPDUMP on a web server or some other isolated production server. If you do this, keep in mind that you should try to obscure the sniffing program. Most network attackers are very familiar with network packet monitors. If they compromise a server that has a network analyzer running, they may find these logs and delete or modify them. When constructing packet filters to monitor suspicious traffic there are several strategies. You can log by destination port, destination address, source address or for a specific packet signature. Watching for specific destination ports can be very effective if you are in an environment where those ports are not active. Consider monitoring the network for all IMAP traffic which may be a service that a network scanner is targeting. If you do not have any IMAP servers, then scan attempts for this service will stand out. Sniffing all HTTP traffic in a web environment would not be a good idea unless you had some sophisticated analysis tools to deal with the barrage of recorded data. The same rules apply to destination addresses. If you have busy server, then logging all traffic to it may not be a good idea. But if the server is not heavily loaded, then recording all traffic may be an option. Sniffing based on the source IP address or source IP network may also find interesting activity. And finally, if you know or suspect the scanning techniques in use by a hacker, consider writing specific packet capture rules. A very easy example of this type would be to record any FIN-SYN packets. Hopefully your IDS is doing that already. Analysis of the traffic shows that the attacker is directly probing for RPC ports in the 32700-32800 range only on your Solaris servers. They must have performed some operating system fingerprinting last time they scanned your network. Looking at the traffic, there are an equal number of packet to each Solaris server except for two. Both of those have a third party backup program on them which uses an open RPC port. Sure enough, the scanning has focused in on these two servers. Your interest becomes very intense when you realize that there was an attempt to spawn an XTERM session from one machine to the attacker's IP address. Rule #7: Contact the Source Continuing with this scenario, after consulting with your security staff, you decide to contact the ISP where these RPC scanning events are originating from. You get all of the facts together and find the 'abuse' point of contact on their web page. Luckily, the ISP is in the same time zone so you can call during normal business hours. The ISP security manger tells you they had one of their LINUX DNS servers compromised and it was used to scan other networks. They are sorry for the inconvenience and assure you it won't happen again. When you choose to contact another network organization that is part of the Internet, you must keep a lot of things in mind. The most important thing you can be is organized and present your information clearly. Separate your conclusions from your solid data. Allow the person you are contacting to think about the situation for a moment. Don't demand immediate action. Here are some other guidelines to use when making contact: Don't expect to talk to someone right away Other security people are just like you. They get sick, go to lunch and take vacations. It is not unreasonable to contact an organization and find your security point of contact unavailable. In this case, you may have to deal with someone who is less skilled in security terminology or network administration. When this happens I like to ask for anyone who operates the servers or routers. Usually these people are very capable and can help analyze security events. Language If you attempt to contact foreign countries to chase down suspicious events, you may encounter someone who does not speak your language. English is very common worldwide, but there is no guarantee that you can use it to tell someone about a security incident. Some cultures can read English better than listening to it so consider sending emails or even fax communications. If you have any nonEnglish speaking assets in your organization, it may be a good opportunity to tap them for translator duty. Time Zone Most commercial networks have some sort of 24x7 operations, but security gurus still seem to keep normal daylight hours. The person you are calling may be asleep. Realizing this, you may be lucky enough to get an organization that realizes the importance of your call and follows a procedure to wake the key individuals up for some analysis and hopefully some answers. On the other hand, you may also call and get an answering machine. In this situation you should leave concise information and multiple points of contact on your end. Remember, they may call back when you are asleep. You may be talking to the hacker In some cases, the person listed as the security point of contact may actually be responsible for the scanning of your network. Many hackers get jobs at ISP and other commercial network organizations. Many of them even get jobs in network security capacities. It is not unthinkable that these individuals may abuse their powers. Some telltale signs of this may include apathy to the situation, denial of the events and even open hostility. If nobody asks you for your name, telephone number or email address then something may be amiss. If the person has any knowledge of the scanning that you did not volunteer, then this may also be an indicator they are hiding something. They might not do anything Some network organizations are very busy. In rare cases, the people you contact won't do anything. Some ISP networks have an attitude that they provide unrestricted connectivity for their users and aren't responsible for their actions. Other organizations will help you, but are so busy with other security events that it may take some time before they can handle your complaint. Providing clear and concise facts about the incident can make their job easier and get quicker results for yourself. They might do to much Depending on what the situation is, your information could get some people fired, kicked out from the ISP and even sent to jail. I've had at least one ISP tell me they have "black listed" an individual for hacking. Some security events are honest mistakes, but it is possible for your point of contact to overreact and take some action that you are not comfortable with. For instance, an ISP may place a rule in their outbound packet filters that prevents any traffic to your network from theirs. This is very secure, but now nobody from that network can get to your web servers, send email or play Quake. They may have had a break in During many security situations, the people you are contacting may have suffered a security compromise. If this is the case then either they know it or they don't. If they know about the break-in, then they may be forth coming with all sorts of information. They may also be deceptive and try to hide the incident. If they do not indicate that they have been compromised, but you think they have, it's very important to try and get this information to the correct people. Telling a receptionist isn't going to help the problem get fixed unless you need his or her help to find the correct people. Taking a chance and calling a webmaster, the sales line or even customer support will usually get you within one or two phone calls of the correct person to talk with. They may ask you to work with them in analyzing and tracking down hackers. Be carefully not to discus any proprietary network information or security invents that do not directly involve your point of contact. This will shield you from inadvertently compromising someone's right to privacy. Everything you say may be used against you It's been said before, but I'll say it again. All of the conversations, intrusion detection events, logs, packet dumps and reports that you or your staff are involved in may be admissible in a court case. Be careful who you give logs to. You may or may not want your logs used in a court case or even have you or members of your security staff called as witnesses in a trial. I'm not going to preach moral values of network security, but it might not be in your best interests to assist some other network organization half way across the country to prosecute a hacker. Of course, the corollary to this is true also. Wouldn't you like it if another security expert was willing to testify that they detected probes from the individual(s) on trial for breaking into your network? Another aspect to keep in mind is to only give out log information to people who truly need access to it. The data can contain a variety of privacy information such as passwords and network usage. Only give the data to people you feel have a need to know and can effect responsible changes to prevent further network abuse. Email may have been compromised One last comment is to think twice before sending security event information over email. Email can be easily compromised. However, monitoring a large volume of email traffic may be outside the scope of a hacker. I like to email points of contact that have multiple accounts and choose one that is not on the possibly compromised network. Also consider the use of encryption. Final thoughts: Be professional when you handle yourself with other people outside of your organization. If you are in the business of selling Internet access, professionalism and common courtesy can take you a long way. The security community is very small and you may be surprised how often you'll run into other security people from different organizations. You are satisfied with your analysis and resulting conversation about the RPC scanning with the ISP. However, when writing the summary report you realize that the scanning did not originate from the ISP's DNS server, but one of their file servers. There is a good chance that they have been further compromised and do not know it. You review your logs once more to confirm your suspicions and then contact the ISP once again. Rule #8: Consider Telling Outsiders When security events occur, you may want to consider getting the word out to other Internet groups. There are a variety of outlets for this sort of information. What is right for you depends on the situation. Consider telling other organizations through the following means: FBI or Authorities The FBI and other authorities are continually getting better at tracking down hackers. The United States military also has an excellent program to track down suspicious network events. Regardless, the security events that you wish to bring to the attention of these organizations should be something new or serious activity. What is this sort of activity? I would say any activity that spans multiple networks or organizations. An example of this could be organized targeting of web servers that accepted credit card data at multiple locations at multiple companies. Another reason to contact the authorities is if you have information that could be useful to an ongoing investigation. Many security events are covered in the media and your information could be related and prove useful. CERT Organizations Computer Emergency Responses Teams track network security events and in some cases, will directly respond to them. Most people have heard of CERT advisories. Some of these advisories do not have vulnerability information, but warn of hacker activity. Information that you report to CERT can help produce better and more timely advisories. If you think that network scanners are looking for a new vulnerability, then CERT can use this information when issuing new vulnerability advisories. There are many different CERT organizations. If you are in the United States military, you should report security incidents to your branch's CERT agency. There are many CERT organizations that span international and corporate entities. Choosing which CERT agency to report an incident is sometimes a difficult task, but can get you more focused support. Mailing Lists In some cases, reporting scanning activity directly to a security mailing list can be beneficial for a variety of reasons. First, the information is very timely. Readers of the mailing lists are there to exchange information about new security vulnerabilities and your report of network scanning may spawn discussion as to what it could mean. Second, other people that have had similar network security events may come forward with other information. They may post to the mailing list or contact you directly. One word of caution though, hackers and malicious individuals also have access to these mailing lists. Don't disclose any information about vulnerabilities in your network or unique information about your network such as IP addresses or domain names. You may even want to get a second shell account just to send email to these mailing lists. Free web based email services such as Hotmail are very useful for this sort of activity. Security Web Sites There are also a wide variety of security web servers on the Internet today. These sites track vulnerabilities and hacker activity. Writing a story or submitting some content about recent scanning activity may help find a solution to the problems. Follow the same sanitation rules with your content to prevent drawing undue attention to your network. Company Outsiders In some cases, it may be appropriate to raise the level of concern at your company. If more money or resources should be involved with network security, then telling Vice-Presidents and other upper corporate management may get you some results and raise awareness. In some cases, CEOs and CIOs may have misconceptions about the current level of network security. There is nothing like a security event to bring a little reality to the situation. The Media Bringing the media into a security situation is usually a recipe for disaster. Most security experts agree that the last thing you should do is to tell other people how secure you are or tell them that you are under network attack. This is a magnet for hackers. You might as well hang a sign on your web page that says, "Hack Me!". Realistically though, the media can be used to tell your customers about your network security if it is done right. If you have firewalls and intrusion detection systems, then there is really nothing wrong with telling people that you have firewalls and intrusion detection systems. Just don't make the leap and state that you have "impenetrable" security. With security incidents, care must be taken to present a positive image about your company or network without reflecting poorly on yourself. Press releases are an excellent tool for this purpose. Rule #9: Determine What Attracted Attention Any investigation of suspicious activity should attempt to conclude what attracted the network scanning in the first place. By attempting to discover this information, you may prevent some scanning in the future. Hackers tend to be opportunistic. Unless they have a bone to grind with you, most malicious hackers are simply looking for vulnerable servers to compromise. Here are some things that opportunistic hackers look for: Default Web Server Splash Pages One of the easiest ways to quickly assess the security of a network is to visit each of its web servers and see how many of them display the default Internet Information Server or Apache splash pages. These can usually indicate recently deployed systems, development networks or systems that are not maintained that well. All of these may have security problems. The combination of the security possibilities and the lack of maintenance can be a green light to most hackers. DNS Entries If your DNS server has names for network nodes such as 'test-linux-1', 'guest' or even 'webdevelopment', then these names could attract a hacker's attention. Naming things by their function ('router1', 'firewall-3', etc.) tells your staff and the entire world exactly what the operation of a particular network node is. If an attacker is looking for a particular exploit to try, they may consult your DNS server to find a target. In some cases, poorly maintained DNS entries can also indicate a poorly administered network. Many hackers (correctly) assume this also means poor security. A good example of a DNS problem is the advertisement of RFC 1918 addresses through normal DNS queries. Default Exploitable Services Many hackers will conduct a quick limited probe to find out how secure or unsecured a given network is. What they may be looking for is a group of computers not protected by a firewall and offering a variety of services such as DNS, TELNET, FTP, SMTP, HTTP and RPC. For example, if a hacker does conduct a quick port scan of a web server which results in only port 80 being active, then the hacker may conclude that the site is reasonably secured. Compare this to a port scan of the web server that discovers twelve active ports. Each situation represents a different level of perceived security posture. Press Releases Nothing draws attention to your site like the media. If your company or clients to your company have media exposure, then it follows that some hackers will get the idea to try and scan or hack you. At least one ISP I am aware of was dismayed when one of its customers actually challenged hackers to break into their web server. The ISP suffered fratricide when attacks on the web server spilled over to the operations center. Internet Relay Chat Running IRC servers is an easy way to attract hackers. Many hackers stereotypically spend hours on end chatting about a variety of topics. When hackers disagree with each other, they will use a variety of denial of service attacks to disable the other person's network access. In some cases direct attacks on the other person's network will also ensue. Having network users that spend time in IRC chat discussions is also an advertisement to hackers. The debate to allow or not to allow IRC access from your network may be abated by providing free access to a shell accounts outside of your network, or by placing an IRC server outside of your firewall. Hacker Web Pages Nothing attracts hordes of hackers like a hacker web page. Many of these pages suffer network attacks. Many of these pages are also seen as 'trophy' pages that various hacker groups would like to claim credit for hacking. If you run a network that has this sort of information, you may be experiencing a certain level of security events simply because people are poking around your network looking for ways to break into the hacker web page. Do you have hackers working for you? If you have a hacker working for you or at your company, then the suspicious probes you may see could be coming from the hacker during off hours or from the hacker's friends (or enemies). Could it be corporate espionage? Not all hacking events are random acts of opportunity on a hacker's part. The suspicious events could indicate a coordinated effort to compromise the security of your network to obtain some level of information. This information could include email, trade secrets, plans, spread sheets or any number of other proprietary pieces of information. Internal Security Events If you suspect that an internal person in your company is conducting network probes or doing something nefarious, then you should follow some loose guidelines when analyzing and presenting evidence. Limit your opinions Do not spread rumors or false accusations about any individual suspected of abusing their network access. This could be viewed as slander in a court case. When presenting suspicious internal security information to other individuals, do not associate any suspected individuals with the data. Try to sanitize the data before presenting it to any group of people. Once someone is branded a hacker, they have a tough time loosing that image even if they are shown to be innocent. Also keep in mind that other people may not have the same opinions about security as you do. Depending upon their position and yours, you may have to work out an agreement or get an interpretation of your network security policy. Document, Record & Save Try to save as much information about the suspicious events as possible. In most cases, these events are more powerful and damaging (and damning) than your word alone. Make sure that the records are in a secured place where they cannot be tampered with. Physical media such as CD-ROMs are ideal for this sort of application. These records will become very crucial in any decisions to terminate an individual. They may also play a role in any police or FBI investigations. Involve Human Resources and Corporate Security Most companies have an HR department that deals with personnel issues. Some companies also have a corporate security group that handles internal security issues. Involving both of these organizations can help protect your interests as well as the company's . They may also have other information that you don't have. Consider the example where an employee has submitted their two week notice and has started to hack the network form the inside. This is a very serious situation which you may have only perceived as a minor network nuisance. If you are the technical subject matter expert on security, you may be asked by these groups to assist in an investigation. Avoid Target Fixation We are all human. Chances are you would not like your actions to be monitored on a regular basis. Small acts such as taking office supplies for home use seem much more serious when an investigation is underway. The same is true for network security investigations. For example, just because a person is visiting hacker web sites does not mean they are a hacker. Focusing to much on a person's network activities can provide a myopic view of the big picture. Challenge The Individual Once the proper authorities are involved and there is agreement that the individual is doing something strange on the network, the individual should be challenged. If this is done correctly, then the individual will be surprised and may give themselves away through statements they make. That is of course if they are hiding something. You should carefully use these meetings to find out what the individual was doing. Ask direct questions about network usage and try to find anything that can explain the suspicious network traffic. If you hit a brick wall, you may want to tell the individual what sort of traffic was observed. Stereotypically, this is when the person confides that they let Bruce from the accounting department use the computer during lunch time. You should also have a physical inspection of the computer performed while the meeting is taking place. These may seem like very extreme measures, but if an individual is to be terminated immediately, the chance to discover Trojan horse programs or logic bombs needs to be addressed. Also a physical inspection of their computer may provide contradicting evidence to their testimony or explanation of their activity. Final thoughts: Computer analysis should best be left to computer experts. However, since security events involve people, the best chance of catching an internal hooligan may come from an ex-police officer or an exinvestigator. People with these backgrounds and some good computer knowledge are becoming very popular to handle computer crime investigation. If your company has these assets, then I strongly urge you to involve them in computer security incidents. Final - 'Final Thoughts' Following the steps outlined here may save you a lot of time and headaches when dealing with network probes and security events. I urge you to discuss these concepts with your staff and management. You should also discuss this information with any other people in your organization associated with network operations. The one thread that holds all of these rules together is 'common sense'. Analysis and termination of network probes and security events occurs in the human world. It does not occur in the computer world. Dealing with other people can be tricky. Be nice. Be courteous. There are some people at your company and at other networks that won't be easy to work with, but this is a fact of life that usually shows itself during a security event. Act professional and stick to the facts. For a variety of reasons, many people tend to forget these when placed under pressure and in high tension situations. Good luck! References: 1. ARIN is the American Registry for Internet Numbers. http://www.arin.net 2. Nmap is a network and port scanning tool written by Fyodor ([email protected]). It is available at http://www.insecure.org/nmap/index.html 3. QueSO can fingerprint operating systems remotely using a variety of techniques. It is available at http://www.apostols.org/projectz/queso/ 4. Klaxon is a tool that detects port scans. Available at the COAST security archive. ftp://coast.cs.purdue.edu/pub/tools/unix/klaxon/klaxon.tar.gz 5. Van Jacobson, traceroute documentation and source code, Lawrence Berkeley National Laboratory 6. David Goldsmith and Michael Schiffman, "Firewalking: A Traceroute-Like Analysis of IP Packet Responses to Determine Gateway Access Control Lists", Cambridge Technology Partners Watching Your Logs mailto:[email protected] Logs are a critical asset to successfully running your systems. They tell us what is and what is not happening. However, logs can be extremely copious, quickly overwhelming us with information. Soon they become useless files that just fill up disk space. This article will cover how to solve this by automating the filtering of your logs, freeing up your time while alerting you with the information you need. Filtering Logs are an incredible asset, unfortunately they are often ignored. You have too little time to review too much information. Wouldn’t it be nice to automate the process, a process that reviews the logs for you, then notifies you with only the information you need. Well, we are going to do just that. I am going to cover how to filter your logs for the information you need, then implement a notification system. The first part of this article will cover developing a plan on what you want to filter, and what you want to be notified of. The second half will be on implementing the filter. For this article, I will be using swatch as a filter, written by Todd Atkins. We will also be using sendmail logs as an example of the filtering process. However, you can apply these guidelines to any type of logging. Where to begin The best place to start is with a plan. There are three steps to planning for automated logging. The first step is define what you want to know. Determine what information you need out of your system logs. The second step is to identify which logs contain that information. The third step is identifying the trigger, what defines the critical information? For example, lets say you are concerned about the security of your sendmail, specifically you want to know if someone attempts to use your mail server as a spam relay. You also want to know if anyone is attempting to gain unauthorized information with SMTP commands, such as expn. We have completed the first step by determining what we want to know. The second step is identifying the source, or what log contains this information. The best place to find that is /etc/syslog.conf, this configuration file will show you what information is logged where. For mail, we see that all mail information is logged to /var/log/syslog on our Solaris system (/var/log/maillog for Linux). goalith #cat /etc/syslog.conf | grep mail mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost) The final step is defining the trigger. What specific entries in the logs define the information we are looking for. For sendmail, we are looking for two triggers. 1. relay. 2. off. Trigger that shows un-authorized IP addresses attempting to use our mail server as a mail Trigger that shows someone is attempting to use the expand command, which we have turned The best way to define the trigger is to recreate the incident while monitoring the log with /usr/bin/tail –f. If you can’t do this on a production system, find a lab system you can replicate the trigger on. First, lets recreate the incident for the first trigger, unauthorized use of our system as a mail relay . From an unauthorized IP address, attempt to use your mailserver as a relay. With /usr/bin/tail –f you see the log entry in /var/log/syslog (Refer to Figure A). There we see the error message of someone at moo.com attempting to relay email, potentially a sign of spam. This is the trigger for unauthorized mail relay. Notice how the error also includes the IP address, verifying the domain. Now, lets recreate the second trigger, unauthorized use of the expn command. Telnet to the SMTP port and execute expn. Meanwhile monitor the /var/log/syslog with tail –f (Refer to Figure B). There we see the error message of someone at moo.com attempting to expand the username root. This is the trigger if anyone attempts to exploit the "expn" command. Notice how the error also includes the IP address, verifying the domain. We have now completed the three steps in planning for automated log filtering. We first identified the information important to us, unauthorized attempts to use our mail server as a mail relay and use of the expn command. We then identified the logs that contain this information, /var/log/syslog. Last, we identified the triggers for this information by recreating the incidents. We are now ready to build our automated filter. SWATCH SWATCH, "The Simple WATCHer and filter", is a perl program developed by Todd Atkins that monitors your logs in real time. Swatch monitors your logs for specific triggers, when those triggers are matched swatch notifies you in a pre-determined manner. In our case, we are going to implement swatch to alert us whenever someone is messing with our sendmail. The program is extremely simple to install. Swatch comes with a useful install script that will copy all the libraries, man pages, and perl files to their respective directories. You might need to compile and install several perl modules, the installation script will let you know. Once done installing, all that is left is creating a configuration file and then launching the program. You can download swatch at ftp://ftp.stanford.edu/general/security-tools/swatch. The configuration file, called swatchrc, is the heart of the swatch program. This text file tells swatch what logs to monitor, what triggers to look for, and what to do if triggered. Swatch works by looking for regular expressions that match the triggers defined in swatchrc. When it finds a match, it executes the notification procedure defined in swatchrc. Swatch monitors the files in real time, using /usr/bin/tail –f. We will now create a swatchrc file for our sendmail logging we discussed above. The goal is to have sendmail email us whenever someone is messing with our email system. We defined this earlier as anyone attempting unauthorized mail relay or the expn command. The syntax of a swatchrc file is as follows. It consists of four fields, the first two fields are required, the last two fields are optional. The first field is /pattern/pattern/ where pattern is a regular expression that swatch is looking for. This is our trigger. The second field is Action,action… where action is what to do if the pattern is matched. Swatch has various options for actions, including email, paging, or executing any file you select. The third field 'throttle' (which is optional) is a time interval defined as HH:MM:SS HH is for hours, MM for minutes, and SS for seconds. This time interval is the amount of time swatch will ignore identical matched patterns that repeat themselves. For example, if you define this period as 5 minutes, swatch will only report one identical matched pattern over that time period, even though it might have matched 20 identical entries. The fourth field (required if you are using the third field) is a timestamp, defined as start:length. This defines the location and length of the timestamp in the notification message. For our sendmail example, we want to create a swatchrc file that looks for patterns matching our two triggers (See Figure A and Figure B). When it matches either of these patterns, we want it to notify via email [email protected] and to include the matched pattern in the email. However, we have to be careful not to be flooded with warnings. For example, if someone attempts to relay off us with 1000 emails a minute, we would be overwhelmed with notifications. So, we will set a time interval of 5 minutes. Regardless of how many identical patterns are matched in a five minute period, we will receive only one warning. Our swatchrc file would look as follows: watchfor /Relaying denied|expn/ echo=normal [email protected],subject=--- Sendmail Alert! --throttle 5:00 0:16 The first field has "/Relaying denied|expn/". If swatch matches either pattern in the regular expression, it will send an alert. The first pattern "Relaying denied" is found in trigger #1 (Figure A), this log is the result of someone attempting an unauthorized mail relay. The pattern "expn" is found in trigger #2 (Figure B), it is the result of someone attempting to use the expn command. You will find both expressions in the triggers we covered in the first part of the article. The second filed has "echo=normal,[email protected]" This field states email a warning to [email protected], and echo the matched log entry. The third and fourth field (which are optional), have "5:00 0:16". This states do not repeat any warning for identical patterns matched within 5 minutes. The last field states the location and length of the timestamp. We now have a properly configured swatchrc file. The last step is starting swatch itself. Swatch can be launched with a variety of options. However, we will launch with the following syntax. /usr/local/bin/swatch -c /var/log/syslogrc -t /var/log/syslog & The –c option points to the configuration file, and the –t option monitors the log file in realtime. The "&" runs the swatch in the background. Once launched, swatch forks a child, so swatch will be running as two processes. Be sure to kill both processes in any stop/start scripts you create. That’s it. Your sendmail logs will be automatically filtered. Whenever someone messes with your sendmail system, you will be instantly notified via email, with the matched trigger in the log included (See Figures A and Figure B). Conclusion Logs are powerful tools, yet they can easily overwhelm us with data. When this happens, we start ignoring this valuable source because we don’t have time to scan through megs of data. Automating the filtering of such logs solves the problem. These automated filters do the work for us, alerting us in real time with the information we need. Hopefully this article has given you ideas on how to automate the filtering of your log files. Figure A Trigger for anyone attempting un-authorized mail relay from your sendmail server. Oct 3 14:48:51 homer sendmail[6704]: OAA06704: ruleset=check_rcpt,[email protected], [email protected] [206.54.252.1],reject=550 [email protected]... Relaying denied Figure B Trigger for anyone attempting to utilize the expn command on your sendmail server. Oct 2 20:28:37 homer sendmail[5453]: NOQUEUE: [email protected][206.54.252.1]: expn root [rejected] Author’s bio Lance Spitzner enjoys learning by blowing up his Unix systems at home. Before this, he was an Officer in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at [email protected] . Filtres Internet Firewall Aucun réseau informatique relié au réseau Internet n'est invulnérable, mais des protections peuvent être installées. La première ligne de défense est le pare-feu, dont les deux types le plus fréquemment utilisés agissent soit au niveau des messages transmis, soit au niveau des logiciels. Le premier fonctionne sur une machine nommée routeur. Il examine dans chaque message entrant ou sortant les adresses de la source et de la destination, qu'il compare à des règles d'accès. Les messages autorisés sont transmis, les autres sont bloqués. Le second examine les adresses et le contenu des messages. Plus lent qu'un filtre de messages, il permet toutefois une politique de sécurité plus raffinée. L'illustration représente un réseau informatique d'entreprise protégé par des pare-feu. Les lignes vertes symbolisent les messages autorisés, et les rouges les messages potentiellement suspects. À l'extérieur du pare-feu (en orange), l'entreprise possède un réseau accessible au public, qui permet aux clients d'envoyer des courriers électroniques vers l'entreprise ou de naviguer sur ses différents sites informatiques. Cette zone (A) est analogue à l'espace d'accueil réservé au public que l'on trouve à l'entrée de certains établissements : aucune information confidentielle n'y est présente. Un pare-feu fonctionnant au niveau des logiciels ressemble aux salles de police des aéroports (B) : les courriers électroniques sont inspectés. Les programmes reçus par le réseau Internet, qui peuvent contenir des instructions néfastes, sont envoyés sur un serveur mandataire, puis à un programme mandataire qui fonctionne en toute sécurité sur le réseau. Un programme mandataire est l'analogue du factotum (personnage en bleu) qui reçoit des messages de l'extérieur et les délivre au personnel. Les pare-feu ne sont pas invincibles, ils peuvent être contournés (C) grâce à un modem téléphonique, à des disquettes ou à des bandes magnétiques volées, contenant des données confidentielles. Lorsque l'entreprise s'agrandit, des pare-feu supplémentaires sont nécessaires pour protéger les systèmes informatiques de services importants, tel celui de la comptabilité. Ces protections ressemblent à la porte d'acier d'une chambre forte (D) ; elles défendent les systèmes vitaux contre des attaques de l'intérieur ou de partenaires. Un pare-feu fonctionnant au niveau des messages possède un peu la même fonction que les gardes de certaines entreprises (personnages en bleu). Selon la politique de sécurité de l'établissement, le filtre peut n'autoriser que l'entrée de messages provenant de certaines adresses, par exemple celles des partenaires d'affaires ou celles des fournisseurs. Les contrefaçons d'adresses sont évitées par une authentification codée, analogue à un badge de sécurité, qui assure que le fichier ou le programme entrant provient bien d'une adresse d'un partenaire de confiance. Un firewall., mur coupe-feu en français, c'est comme un routeur, sauf qu'au lieu de router sans réfléchir, il obéit à une police, un ensemble de règles très précises. Ces règles vont par exemple empêcher les paquets FTP de rentrer dans votre réseau sécurisé. Ainsi, même si votre serveur FTP interne est mal configuré et que tout le monde peut écraser vos fichier, vous n'aurez pas à vous tracasser puisque personne ne pourra faire de connexions FTP sur votre machine. Elles seront arrêtées par le firewall. Le firewall s'occupe aussi de vous informer de qui fait quoi. Vous pouvez ainsi détecter la moindre anomalie, le moindre geste suspect. Il est évidement tout à fait fondamental que personne à part vous n'ait de compte sur le firewall. Les types de machines Packet Filter Le packet filter, comme son nom l'indique, filtre les paquets dans les deux sens. Pour ce faire, il utilise des fonctions de routage interne classiques. Ce sont des protections efficaces, mais pas toujours suffisantes. Certaines attaques complexes peuvent déjouer les règles. De plus, configurer un Packet Filter sans failles n'est pas facile et le risque d'erreur est grand. Il est généralement utilisé en tête de réseau comme premier filtre avec un autre système de défense derrière. Par exemple, certains routeurs comme les CISCO ou les Livingston ont cette possibilité. Screening Router Evite le IP spoofing en vérifiant que les adresses d'origine des paquets qui arrivent sur chaque interface sont cohérentes et qu'il n'y a pas de mascarade. Exemple: un paquet qui a une adresse de votre réseau interne et qui vient de l’extérieur est un Spoofed Packet. Il faut le jeter et prévenir le plus vite l'administrateur qu'il y a eu tentative d'attaque. Screening Routers. Un screening router est un routeur qui filtre les paquets sur base : de l'adresse IP source de l'adresse IP de destination du type de protocole (TCP, UDP, ICMP) du port Le système a ses limites : la syntaxe pour définir les filtres devient vite complexe certains services (FTP, RPC) sont très difficiles à filtrer aucun fichier log ne recense les attaques Dual-Homed Host Il s'agit d'une machine que n'a pas de fonction de routage au niveau kernel, c'est à dire au niveau du protocole. Les paquets arrivant sur les interfaces réseaux sont donc bloqués. On contourne le routage du niveau kernel par un routage spécial, au niveau application, avec un système de store-and-forward. Les applications utilisées pour le routages sont des programme tels que SOCKS,... Le grand désavantage de cette méthode est que les clients doivent être écrits pour utiliser ce routage au niveau application. Les paquets doivent donc être redirigés vers un port et une machine spéciale avant d'être forwardés sur le réseau. Les architectures Bastion Host C'est l'architecture de défense la plus classique, mais aussi la moins coûteuse: une machine, située en tête de réseau, reçoit tout le trafic, éventuellement déjà filtré par un screening-router, et prend des mesures de sécurité. Le bastion host peut exister avec une ou plusieurs interfaces réseau configurées. Il est à noter qu'on est beaucoup plus à l'abri des attaques avec plusieurs interfaces réseau, puisque les réseaux sont physiquement séparés. Dual-Bastion On a parfois besoin d'une zone moins bien protégée qu'une autre. Je pense à une zone moins sécurisée que l'on pourrait joindre de l'extérieur avec par exemple un serveur WWW, un serveur de mail, un DNS,... et une zone très sécurisée pour, par exemple, les machines internes de la société. On utilise alors un filtrage à deux niveaux: un premier bastion host qui laisse juste passer ce qu'il faut pour la zone tampon, constituée des serveurs de mail,... et un second bastion, qui relie le réseau très sécurisé à la zone tampon. Le réseau très sécurisé bénéficie alors d'un filtrage à deux étapes. Les Firewalls Un Firewall (les Français préfèrent parler de système pare-feu) est un système qui renforce la politique d’accès entre deux réseaux. Les différentes implémentations des Firewalls varient d’un constructeur à l’autre. Mais ils fonctionnent selon le principe d’autorisation ou d’interdiction. La configuration d’un firewall consiste à indiquer les actions qu’on autorise (permit) et celles qu’on interdit (deny). Le but de ces permissions et ces interdictions est d’empêcher toute personne indésirable d’accéder au réseau protégé par le Firewall. On peut comparer le rôle d’un Firewall avec celui des permissions accordées aux utilisateurs dans un système d’exploitation. Il existe deux sortes de Firewall : les Firewalls de niveau réseau, les Firewalls de niveau application. - Firewall de niveau réseau Les Firewall de niveau réseau permettent de refuser ou d’autoriser l’accès à un réseau sur la base de plusieurs éléments : l’adresse IP source, le protocole, le numéro de port, le contenu. - Ce type de Firewall se retrouve souvent dans les routeurs car leur implémentation est aisée. Il suffit de les installer, de configurer quelques règles et le tour est joué. De plus, si votre réseau est connecté en permanence à Internet, vous devez avoir un routeur donc un Firewall au niveau du routeur vous offre une solution intégrée. Malheureusement, l’implémentation des Firewalls sur les routeurs ne permet pas nécessairement un filtrage très évolué : un filtrage trop évolué entraîne une baisse de performance significative, ce qu’un fournisseur d’accès à Internet a tout intérêt à éviter au maximum. Ce type de Firewall ne nécessite pas l’arrêt du réseau qu’il protège car il représente une solution externe, il opère en bordure de réseau. Il ne nécessite pas une reconfiguration des diverses machines du réseau. Quelques exemples de ce que permettent les Firewalls de niveau réseau : autoriser uniquement le trafic utilisant le protocole http, interdire tout trafic venant d’une adresse particulière. - Exemple de liste d’accès d’un routeur Cisco qui utilise le système d’exploitation IOS v10.3 ou supérieure (exemple de fichier de configuration) : 1. no ip source-route 2. ! 3. interface ethernet 0 4. ip address 195.55.55.1 5. ! 6. interface serial 0 7. ip access-group 101 in 8. ! 9. access-list 101 deny ip 195.55.55.0 0.0.0.255 10. access-list 101 permit tcp any any established 11. ! # adresse du routeur 12. access-list 101 permit tcp any host 195.55.55.10 eq smtp 13. access-list 101 permit tcp any host 195.55.55.10 eq dns 14. access-list 101 permit udp any host 192.55.55.10 eq dns 15. ! 16. access-list 101 deny tcp any any range 6000 6003 17. access-list 101 deny tcp any any eq 2049 18. access-list 101 deny udp any any eq 204 19. ! 20. access-list 101 permit tcp any 20 any gt 1024 21. ! 22. access-list 101 permit icmp any any 23. ! 24. snmp-server community FOOBAR RO 2 25. line vty 0 4 26. access-class 2 in 27. access-list 2 permit 195.55.55.0 255.255.255.0 Dans cet exemple, toutes les lignes commençant par access-list indiquent les commandes servant à contrôler le flux de paquets passant par le routeur. - Ligne 9 : on interdit tous les paquets venant de l’extérieur possédant une adresse IP du réseau. - Ligne 10 : on autorise tous les paquets appartenant à une connexion TCP déjà établie. - Lignes 12, 13 et 14 : toutes les connexions aux ports «well-known» (en dessous de 1024) sont interdites sauf pour le SMTP et le DNS. - Lignes 16, 17, 18,19 : on bloque tous les services écoutant sur des ports hauts (supérieur à 1024), y sont inclus les services de X-Windows (serveur graphique sous Unix) qui utilisent les ports supérieurs à 6000, le service NFS (port 2049) - Ligne 20 : on suppose que tout trafic provenant du port 20 et se connectant à un port supérieur à 1024 est utilisé pour le FTP. - Ligne 27 : access-list 2 limite l’accès au routeur lui-même (telnet et SNMP). Firewall de niveau application On parle aussi de Firewall proxy ou de passerelle applicative pour ce type de Firewall. Comme l’un de ses noms l’indique, Firewall proxy fait généralement office de proxy. Il intercepte les connexions venant de l’extérieur du réseau et il modifie légèrement les paquets transmis pour leur permettre d’atteindre une machine à l’intérieur. En fait, le proxy transforme les adresses externes au réseau en adresses internes via le protocole NAT (Network Address Translation) ou PAT (Port Address Translation). Le proxy inversement transforme les adresses internes du réseau en adresses externes. Une personne extérieure au réseau ne connaît pas les adresses internes du réseau qui sont privées, à l’opposé des adresses externes du réseau qui sont publiques. Un Firewall proxy permet de cacher les machines internes à un réseau aux personnes venant de l’extérieur. Un Firewall proxy permet, en plus des fonctions de proxy, de filtrer le contenu des paquets, le port ou l’adresse qu’on veut atteindre. Les Firewall de niveau application nécessitent parfois la reconfiguration des programmes utilisés à l’intérieur du réseau pour qu’ils puissent communiquer avec l’extérieur. Il faut peut-être reconfigurer les browsers (utilisés pour naviguer sur Internet), les logiciels de FTP, de mail… Si tous ces logiciels ne sont pas reconfigurés, il se peut qu’ils ne puissent tout simplement pas passer à travers le Firewall proxy. Les Firewalls et les systèmes de détection d’intrusion réseau Les systèmes de détection d’intrusion et les Firewalls sont des dispositifs complémentaires. Un Firewall est un système qui bloque tout par défaut et laisse à l’administrateur du Firewall la tâche de configuration afin de laisser passer certains types de trafic réseau, autorisant ainsi les communications entre le réseau interne à l’entreprise et le monde extérieur. Toutes les autorisations qu’on implémente dans le Firewall sont spécifiées à travers un système de règles. Donc tout trafic conforme aux règles de fonctionnement du Firewall est autorisé à entrer dans le réseau. Si un Firewall autorise le trafic http, c’est-à-dire autorise les connexions à votre serveur web, et qu’un hacker exploite un bug de votre serveur web, il y a de fortes chances que votre Firewall ne le détecte pas. Un système de détection d’intrusion qui surveille tout le trafic réseau et qui possède la signature de l’attaque contre le serveur web est néanmoins capable de détecter l’attaque. Un Firewall est utilisé pour filtrer les connexions entre deux réseaux. Si une personne mal intentionnée tente de pénétrer dans un système interne au réseau à partir d’une autre machine du réseau, le Firewall ne le détectera jamais. Alors qu’un système de détection d’intrusion placé à l’intérieur du réseau est capable de détecter cette tentative d’intrusion. Voici quelques raisons pour avoir un système de détection en plus d’un Firewall : - Un système de détection d’intrusion fait office de double vérification et deux vérifications valent mieux qu’une. - Un système de détection d’intrusion peut intercepter certaines attaques qu’un Firewall considérerait comme légitimes (par exemple une attaque contre un serveur web). Un système de détection d’intrusion peut repérer les tentatives d’intrusion internes au réseau. - Firewall est un terme automobile. Dans une voiture, un firewall est une pièce qui sépare le bloc-moteur du compartiment passagers. Il est prévu pour protéger les passagers en cas d'explosion du véhicule. En informatique, un firewall est un composant logique qui protège la partie privée d'un réseau de la partie publique. Le fonctionnement en est le suivant~: 1. 2. 3. 4. 5. Vous prenez un ordinateur qui a des fonctionnalités de routage (comme une machine Linux) Placez-y deux interfaces (c.à.d. ports série, Ethernet, Token Ring, etc.) Empêchez la transmission IP Connectez l'internet sur une interface connectez le réseau protégé sur l'autre interface Maintenant, vous avez deux réseaux distincts, qui se partagent un ordinateur. L'ordinateur firewall, qui sera nommé "firewall", peut atteindre à la fois le réseau protégé et internet. Le réseau protégé ne peut atteindre l'internet, ni l'internet toucher le réseau protégé. Pour atteindre l'internet depuis l'intérieur du réseau protégé, on doit se connecter au firewall par telnet, puis utiliser internet à partir de là. Symétriquement, pour entrer dans le réseau protégé, on doit passer d'abord par le firewall. Cela offre un excellent niveau de sécurité contre les attaques en provenance de l'internet. Si quelqu'un veut réaliser une attaque concertée contre le réseau protégé, il doit passer d'abord le firewall, s'en faire un marchepied, puis, plus difficile, attaquer. Si quelqu'un veut attaquer le réseau protégé par une méthode plus classique, comme l'invasion de courrier, ou l'infâme "Internet Worm", il ne sera pas à même d'atteindre le réseau protégé. Cela réalise une excellente protection. 2.1 Inconvénients des firewalls Le plus gros problème des firewalls réside dans leur forte inhibition de l'accès à l'internet depuis l'intérieur. Fondamentalement, ils réduisent l'usage de l'internet pour ceux qui y auraient eu accès vi un compte en accès entrant. Devoir se loger sur le firewall puis seulement avoir l'accès à l'internet est une sévère restriction. Des programmes comme Netscape, qui nécessitent une connexion internet directe, ne fonctionneront pas depuis l'arrière d'un firewall. Etre incapable de FTPer directement sur votre ordinateur est un autre gros problème, qui nécessite une configuration à deux niveaux internet>firewall->ordinateur protégé. La réponse à ces problèmes réside dans l'utilisation d'un serveur proxy. 2.2 Serveurs proxy Les serveurs proxy sont des constructions qui permettent l'accès direct à l'internet depuis derrière un firewall. Leur fonctionnement réside dans l'ouverture d'une socket sur le serveur, permettant la communication vers l'internet via cette socket. Par exemple, sur mon ordinateur, drig se trouve dans le réseau protégé, et je veux parcourir le Web en utilisant Netscape. Je vais configurer un serveur proxy sur le firewall. Le serveur proxy sera configuré pour permettre aux requêtes depuis mon ordinateur cherchant à accéder au port 80 de se connecter à son port 1080, puis il redirigera toutes les requêtes vers les emplacements idoines. Quiconque a utilisé TIA ou Term a déjà rencontré ce concept. A l'aide de ces deux programmes, vous pouvez rediriger un port. Un ami dispose de TIA configuré pour permettre à quiconque appelant le port 4024 à l'adresse 192.251.139.21 de se connecter à son serveur Web. Le serveur proxy fonctionne ainsi, mais à l'envers. Pour se connecter au port 80 de quelqu'un d'autre, vous devez utiliser le port 1080 (ou tout port que vous aurez configuré pour). L'idée majeure concernant les serveurs proxy est qu'ils sont complètement sûrs, lorsqu'ils sont configurés correctement. Ils ne permettront à personne d'entrer au-travers d'eux. 3 Configurer tout ça 3.1 Matériel nécessaire Pour notre exemple, l'ordinateur est un 486-DX66, 8~Mo de RAM, 500~Mo de partition Linux, avec une connexion PPP à son fournisseur internet par un modem 14,4~kbps. Cette configuration est votre machine Linux de base. Pour en faire un firewall, nous ajoutons une carte Ethernet NE2000. Il est alors connecté à trois PC sous Windows 3.1 avec Trumpet Winsock et deux Sun sous SunOS 4.1. Cette configuration a été choisie car elle est très classique et qu'elle comporte deux plate-formes qui me sont familières. J'imagine qu'une grande partie des éléments dont je parle est réalisable sur Mac, mais comme je n'utilise pas assez souvent ceux-ci, je ne sais pas vraiment. 3.2 Configurer le logiciel Bien, vous avez une machine Linux connectée au réseau via une ligne PPP à 14,4~kbps. Vous avez ensuite un réseau Ethernet connecté à cette machine Linux et tous les autres ordinateurs. D'abord, vous devez recompiler le noyau Linux avec les options appropriées. A ce point, je vous renvoie au Kernel HOWTO, à l'Ethernet HOWTO et au NET-2 HOWTO. Ensuite, faites un "make config"~: Activez le support du réseau Activez le protocole TCP/IP Désactivez la transmission IP (CONFIG_IP_FORWARD) Activez le Firewalling IP Vraisemblablement, activez la gestion des comptes. Cela semble prudent puisque nous configurons un système de sécurité Activez le support des équipements réseau Nous activons les supports PPP et Ethernet, mais cela dépend de vos interfaces Ensuite, nous recompilons, réinstallons le noyau et relançons le système. Les interfaces doivent apparaître dans la séquence de démarrage, et tout doit être correct. Sinon, plongez-vous à nouveau dans les autres HOWTO jusqu'à ce que tout fonctionne. 3.3 Configurer les adresses réseau C'est la partie réellement intéressante. Puisque nous ne souhaitons pas laisser l'accès depuis internet, il n'est pas nécessaire d'utiliser des adresses réelles. Une bonne classe C à utiliser est 192.0.2.xxx qui a été conservée à part en tant que domaine de test "à blanc". Ainsi, personne ne l'utilise, et il n'entrera en conflit avec aucune requête vers l'extérieur. Ainsi, dans cette configuration, une seule adresse IP réelle est nécessaire. Les autres sont libres et n'affecteront pas du tout le réseau. Assignez l'adresse IP réelle au port série utilisé pour PPP. Assignez 192.0.2.1 à la carte Ethernet du firewall. Assignez une adresse de ce dernier domaine à toutes les autres machines du réseau protégé. 3.4 Tester le tout Premièrement, essayez un ping sur l'internet depuis le firewall. J'avais l'habitude d'utiliser nic.ddn.mil comme point de test. C'est toujours un bon test, mais il a prouvé qu'il était moins fiable que je l'espérais. Si cela ne fonctionne pas dès l'abord, essayez un ping sur quelques autres endroits qui ne soient pas connectés à votre réseau local. Si cela ne fonctionne pas, alors votre PPP est mal configuré. Relisez le NET-2 HOWTO, et essayez à nouveau. Maintenant, essayez des ping entre les machines du réseau protégé. Tous les ordinateurs doivent êtres capables d'atteindre tous les autres. Dans le cas contraire, repassez une couche de NET-2 HOWTO et retravaillez encore un peu votre réseau. Puis, chaque machine du réseau protégé doit être capable d'atteindre le firewall par ping. Sinon, retournez une fois de plus en arrière. Rappelez-vous d'essayer sur l'adresse 192.0.2.1 et non sur l'adresse PPP. Ensuite, essayez d'atteindre l'adresse PPP du firewall depuis l'intérieur du réseau protégé. Si vous le pouvez, c'est que vous n'avez pas désactivé la transmission IP et que vous devez recompiler le noyau. Le fait d'assigner le domaine 192.0.2.1 au réseau protégé indique qu'aucun paquet ne doit être transmis à ce domaine d'aucune manière, mais il est plus sûr, en tout cas, d'avoir désactivé la transmission IP malgré tout. Cela vous permet de conserver le contrôle, plutôt que de le laisser entre les mains de votre fournisseur PPP. Finalement, essayez un ping sur chaque machine du réseau depuis le firewall. A cet instant, cela ne devrait poser aucun problème. Maintenant, vous avez une configuration de base de votre firewall. 3.5 Sécuriser le firewall Le firewall n'est pas bon s'il reste ouvert aux attaques. Premièrement, regardez le fichier /etc/inet.conf. Ce fichier est ce qu'on appelle un "super-serveur". Il lance un tas de démons serveurs sur demande. Exemples~: Telnet Talk FTP Daytime Il n'est pas nécessaire de tout désactiver. Faites-le au moins pour netstat, systat, tftp, bootp et finger. Vous pouvez vouloir aussi inhiber telnet et permettre seulement rlogin, ou vice-versa. Pour désactiver un service, placez simplement un # devant. Ensuite, envoyez un signal SIG-HUP au processus inetd, selon la syntaxe suivante~: kill -HUP <pid>, où pid est le numéro du processus inetd. Cela force inetd à relire son fichier de configuration (inetd.conf) et à se relancer. Testez par telnet sur le port 15 du firewall, qui est le port de netstat. Si vous obtenez une réponse de netstat, c'est que vous n'avez pas relancé inetd correctement. 4 Le serveur proxy 4.1 Installer le serveur proxy Le serveur proxy nécessite un logiciel complémentaire. Vous pouvez l'obtenir sur l'un des nombreux miroirs de~: ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz. Il ya aussi un exemple de fichier de configuration dans ce répertoire "socks-conf". uncompressez et détarez les fichiers dans un répertoire de votre système, et suivez les instructions pour le confectionner. J'ai eu quelques problèmes pour le réaliser. Vérifiez les Makefiles. Certains sont corrects, d'autres, non. 4.2 Configurer le serveur proxy Le programme de connexion nécessite deux fichiers de configuration distincts. L'un pour indiquer les accès autorisés, l'autre pour rediriger les requêtes vers le serveur proxy approprié. Le fichier d'accès doit se trouver sur le serveur. Le fichier de routage peut être placé sur n'importe quelle machine Un*x. Les ordinateurs DOS et, je pense, les Macintosh font leur propre routage. Le fichier d'accès Avec socks4.2 Beta, le fichier d'accès s'appelle "sockd.conf". Il doit contenir deux lignes~: une ligne d'autorisations et une ligne d'interdiction. Chaque ligne doit avoir trois champs~: l'identificateur ("permit" ou "deny") l'adresse IP le modificateur d'adresse L'identificateur est soit permit, soit deny. Vous devez avoir une ligne permit et une ligne deny. L'adresse IP contient une adresse à quatre octets en notation classique IP, soit, par exemple, 192.0.2.0. Le modificateur d'adresse est aussi une adresse à quatre octets en notation classique IP, et fonctionne comme un masque réseau. Représentez-vous ce nombre sur 32~bits. Si un bit est à 1, le bit correspondant de l'adresse qu'il contrôle doit concorder avec le bit correspondant du champ de l'adresse IP. Par exemple, si la ligne est~: permit 192.0.2.23 255.255.255.255 alors elle autorisera seulement l'adresse dont chaque bit correspond à 192.0.2.23, soit 192.0.2.23. Tandis que la ligne~: permit 192.0.2.0 255.255.255.0 autorisera toute adresse du groupe 192.0.2.0 à 192.0.2.255, soit tout le domaine de la classe C. Il ne faut pas avoir la ligne~: permit 192.0.2.0 0.0.0.0 qui autoriserait toute adresse, sans distinction. Bien, d'abord autorisez toute adresse que vous souhaitez, puis interdisez le reste. Pour autoriser quiconque dans le domaine 192.0.2.xxx, les lignes~: permit 192.0.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0 fonctionneront très bien. Notez le premier "0.0.0.0" dans la ligne "deny". Avec un modificateur de 0.0.0.0, le champ adresse IP n'a aucune importance. Tous les champs à 0 est la norme, car c'est facile à écrire. On peut utiliser plusieurs lignes de chaque type. Des utilisateurs spécifiques peuvent aussi se voir accorder ou refuser l'accès. Cela est réalisé par l'authentification d'identité. Tous les systèmes ne supportent pas le système ident, y compris Trumpet Winsock, donc nous n'irons pas plus loin en ce qui concerne cela. La documentation de socks est tout à fait adéquate. Le fichier de routage Le fichier de routage de socks est bêtement nommé "socks.conf". Je dis "bêtement", car il est si proche du nom du fichier d'accès qu'il est aisé de les confondre. Le fichier de routage sert à indiquer aux clients de socks quand il est nécessaire d'utiliser celui-ci. Par exemple, dans notre réseau, 192.0.2.3 ne nécessite pas l'usage de socks pour communiquer avec le firewall 192.0.2.1. Il a une connection directe Ethernet. Il définit 127.0.0.1, le port de bouclage, automatiquement. Evidemment, il n'est pas nécessaire d'utiliser socks pour vous parler à vous-même. Il y a trois entrées~: deny direct sockd Deny indique à socks quand rejeter une requête. Cette entrée a les trois mêmes champs que ceux de sockd.conf~: identificateur, adresse et modificateur. Généralement, puisqu'il est aussi manipulé par sockd.file, le fichier d'accès, le champ modificateur est positionné à 0.0.0.0. Si vous voulez vous protéger de tout appel externe, vous pouvez le faire là. L'entrée "direct" indique pour quelles adresses ne pas utiliser socks. Il s'agit des adresses pouvant être atteintes sans le serveur proxy. A nouveau, nous avons les trois champs~: identificateur, adresse et modificateur. Dans notre exemple, nous aurions~: direct 192.0.2.0 255.255.255.0 Donnant l'accès direct pour toute machine de notre réseau protégé. L'entrée sockd indique à l'ordinateur l'emplacement du démon serveur de socks. La syntaxe est la suivante~: sockd @=<liste de serveurs> <adresse IP> <modificateur> Notez l'entrée @=. Elle vous permet de configurer les adresses IP de plusieurs serveurs proxy. Dans notre exemple, nous utilisons un seul serveur proxy, mais vous pouvez en avoir plusieurs pour permettre un plus grand trafic et pour assurer une tolérance aux pannes. Les champs adresse IP et modificateur fonctionnent exactement comme dans les autres exemples. Vous spécifiez ainsi où va quelle adresse. 4.3 Travailler avec un serveur proxy Unix Pour faire fonctionner vos applications avec un serveur proxy, celles-ci doivent être "sockifiées". Il vous faudra deux telnet différents~: un pour la communication directe, et un autre pour celle avec le serveur proxy. Le paquetage socks contient des indications pour sockifier un programme, ainsi qu'un certain nombre de programmes pré-sockifiés. Si vous utilisez la version sockifiée pour aller directement quelque part, socks basculera automatiquement sur la version directe pour vous. A cause de cela, il nous faut renommer tous les programmes sur notre réseau protégé et les remplacer par leur version sockifiée. "Finger" devient "Finger.orig", "telnet" devient "telnet.orig", etc. Vous devez indiquer chacun d'eux à socks à l'aide du fichier include/socks. Certains programmes manipulent le routage et la sockification eux-mêmes. Netscape est l'un d'entre eux. Vous pouvez utiliser un serveur proxy sous Netscape en donnant l'adresse du serveur (192.0.2.1 dans le cas qui nous intéresse) dans le champ SOCKs sous Proxies. Chaque application nécessite au moins un petit coup d'oeil, quelle que soit son attitude vis-à-vis d'un serveur proxy. MS Windows avec Trumpet Winsock Trumpet Winsock contient des fonctionnalités de serveur proxy incluses. Dans le menu "setup", donnez l'adresse IP du serveur, ainsi que celles de tous les ordinateurs directement accessibles. Trumpet se débrouillera alors avec tous les paquets sortants. 4.4 Faire fonctionner le serveur proxy avec les paquets UDP Le paquetage socks fonctionne seulement avec les paquets TCP, pas avec les UDP. Cela le rend quelque peu moins utile. De nombreux programmes très utiles, comme talk et Archie, utilisent UDP. Il existe un paquetage prévu pour être utilisé comme serveur proxy pour les paquets UDP appelé UDPrelay, de Tom Fitzgerald <[email protected]>. Malheureusement, à l'heure où ces lignes sont écrites, il n'est pas compatible avec Linux. 4.5 Inconvénients avec les serveurs proxy Le serveur proxy est, avant tout, un système de sécurité. Son utilisation pour augmenter le nombre d'accès Internet avec un nombre limité d'adresses aura de nombreux inconvénients. Un serveur proxy autorisera un plus grand accès de l'intérieur du réseau protégé vers l'extérieur, mais laissera l'intérieur totalement inaccessible de l'extérieur. Ce qui implique aucun serveur, aucune connexion talk ni Archie, ni e-mail direct vers les ordinateurs de l'intérieur. Ces inconvénients peuvent sembler légers, mais regardez-les sous l'angle suivant~: Vous avez laissé un document en cours sur votre ordinateur à l'intérieur du réseau protégé. Vous êtes à la maison, et décidez que vous voulez retravailler celui-ci. Vous ne le pouvez pas. Vous ne pouvez atteindre votre ordinateur, car il est derrière le firewall. Vous essayez de vous loger d'abord sur le firewall, mais comme tout le monde a accès au serveur proxy, vous n'avez pas de compte dessus. Votre fille va au collège. Vous souhaitez lui envoyer un e-mail. Vous avez différents choses de caractère privé à discuter, et préfèreriez recevoir directement votre courrier sur votre machine. Vous avez pleine confiance dans votre administrateur réseau, mais, malgré tout, il s'agit de courrier privé. L'impossibilité d'utiliser les paquets UDP représente un gros inconvénient avec les serveurs proxy. Je pense que les fonctionnalités UDP arriveront sous peu. De plus, les serveurs proxy sont lents. A cause de la dégradation du rapport information/protocole, n'importe quel autre moyen d'obtenir cet accès sera plus rapide. En deux mots, si vous avez les adresses IP nécessaires, et que la sécurité n'est pas un impératif pour vous, n'utilisez pas le firewall ni les serveurs proxy. Si vous n'avez pas suffisamment d'adresses IP, mais que, de même, la sécurité n'est pas fondamentale, vous pouvez jeter un coup d'oeil aux émulateurs IP, comme Term, Slirp ou TIA. Term est disponible sur ftp://sunsite.unc.edu, Slirp est disponible sur ftp://blitzen.canberra.edu.au/pub/slirp, et TIA est disponible sur marketplace.com. Ces paquetages iront plus vite, permettront de meilleures connexions, et fourniront un accès supérieur à l'intérieur du réseau depuis l'internet. Les serveur proxy sont utiles pour ces réseaux qui comportent de nombreuses machines se connectant au vol à l'internet, avec un setup et peu de travail ensuite. 5 Configurations avancées Je voudrais aborder une configuration particulière avant de refermer ce document. Celle que j'ai soulignée précédemment suffira probablement pour de nombreux cas. Néammoins, je pense que la situation suivante montrera une configuration plus avancée qui éclaircira certains points d'ombre. S'il vous reste des questions après ce que je viens de décrire, ou simplement que l'adaptabilité des serveurs proxy et des firewalls vous intéresse, lisez encore. 5.1 Un grand réseau avec sécurité renforcée Disons, par exemple, que vous êtes le gourou de la secte de la 23ème Cabale de la Discorde du Milwaukee. Vous souhaitez mettre votre site en réseau. Vous avez cinquante ordinateurs et un sousréseau de trente-deux adresses IP (sur cinq bits). Vous avez différents niveaux d'accès. Vous dites à vos disciples différentes choses en fonction de leur niveau. Evidemment, vous voudrez protéger certaines parties du réseau des disciples qui n'ont pas acquis un certain niveau. Avertissement~: Je ne suis pas membre des Discordiens. Je ne connais pas leur terminologie, et en fait, je m'en fiche. Je les utilise seulement à titre d'exemple. Veuillez envoyer toute remarque acerbe à (NdT~: la destination manque dans le texte original). Les niveaux sont les suivants~: 1. Le niveau extérieur. C'est celui qui est montré à tout un chacun. En gros, c'est l'histoire et les ragots sur Eris, la divinité de la Discorde, et tout le reste du dogme. 2. Sage. C'est le niveau des gens qui ont passé le niveau extérieur. C'est là que vous leur dites que la discorde et la structure ne font qu'un, et qu'Eris est aussi Jeovah. 3. Adepte. C'est là que se trouve le plan réel. Dans ce niveau sont stockées toutes les informations sur la manière dont la Société des Discordiens prendra le pouvoir sur le monde, à l'aide d'un plan déviationniste, mais humoristique, impactant Newt Gingrich, Wheaties Cereal, O.J. Simpson, et cinq cents cristaux, tous marqués "6,5~MHz" par erreur. La configuration du réseau Les numéros IP sont arrangés ainsi~: 23 des 32 adresses IP sont allouées à 23 machines qui seront accessibles depuis internet. Une adresse IP supplémentaire va à une machine Linux sur ce réseau Une autre va à une autre machine Linux de ce réseau. 2 numéros IP vont au routeur 5 sont laissées libres, mais recoivent les noms de domaine paul, ringo, george et billy, juste pour compliquer un peu les choses. Les réseaux protégés ont tous deux des adresses 192.0.2.xxx Puis, deux réseaux séparés sont construits, chacun dans une pièce différente. Ils sont routés par Ethernet infrarouge pour les rendre complètement invisibles de la pièce extérieure. Par chance, l'Ethernet infrarouge fonctionne tout à fait comme l'Ethernet normal (du moins je crois), donc il nous suffit de les considérer comme normaux. Ces réseaux sont connectés chacun à sa machine Linux avec une adresse IP supplémentaire. Il y a un serveur de fichiers qui relie les deux réseaux protégés. C'est parce que les plans pour prendre le pouvoir sur le monde prennent en compte certains des sages les plus élevés. Le serveur de fichiers a les adresses 192.0.2.17 pour le réseau des sages et 192.0.2.23 pour le réseau des adeptes. Il doit avoir des adresses IP différentes, car il doit avoir deux cartes Ethernet différentes. La transmission IP y est désactivée. La transmission IP est aussi désactivée sur les deux machines Linux. Le routeur ne transmettra pas les paquets destinés à 192.0.2.xxx sauf si on lui demande explicitement de le faire, donc l'internet ne pourra pas entrer. La raison de la désactivation de la transmission IP ici est d'empêcher les paquets du réseau des sages d'atteindre le réseau des adeptes, et vice versa. Le serveur NFS peut aussi être configuré pour présenter différents fichiers aux différents réseaux. Cela peut devenir pratique, et assez astucieux d'utiliser les liens symboliques pour partager les fichiers communs. Cette configuration associée à une autre carte Ethernet peut ainsi permettre l'usage d'un seul serveur de fichiers pour les trois réseaux. La configuration proxy Maintenant, puisque les trois niveaux doivent être capables de piloter le réseau pour leurs propres besoins déviationnistes, tous les trois ont besoin d'un accès internet. Le réseau extérieur est connecté directement à celui-ci, donc nous n'avons pas à nous préoccuper d'un serveur proxy ici. Les réseaux des sages et des adeptes sont derrière des firewalls, il est donc nécessaire de leur configurer des serveurs proxy. Les deux réseaux seront configurés de manière similaire. Tous deux ont les mêmes adresses IP assignées. Je vais ajouter quelques paramètres, afin de rendre les choses encore plus intéressantes. 1. Personne ne peut utiliser le serveur de fichiers pour l'accès internet. Cela exposerait le serveur de fichiers aux virus et autres choses désagréables, et il est très important, donc il est derrière les limites. 2. Nous ne voulons pas donner aux sages l'accès au World Wide Web. Il sont encore en entraînement, et cette puissance de recherche d'informations peut se révéler dangereuse. Ainsi, le fichier sockd.conf de la machine Linux des sages contiendra cette ligne~: deny 192.0.2.17 255.255.255.255 Et sur la machine des adeptes~: deny 192.0.2.23 255.255.255.255 Et la machine Linux des sages contiendra cette ligne~: deny 0.0.0.0 0.0.0.0 eq 80 Cela indique l'interdiction d'accès pour toutes les machines tentant d'accéder au port 80, le port http. Cela laisse l'accès à tous les autres services, et interdit juste l'accès Web. Ensuite, les deux fichiers auront~: permit 192.0.2.0 255.255.255.0 pour permettre à tous les ordinateurs du réseau 192.0.2.xxx d'utiliser ce serveur proxy sauf pour ceux à qui cela a déjà été interdit (ie. le serveur de fichiers et l'accès Web pour le réseau des sages). Le fichier sockd.conf du réseau des sages aura l'allure suivante~: deny 192.0.2.17 255.255.255.255 deny 0.0.0.0 0.0.0.0 eq 80 permit 192.0.2.0 255.255.255.0 et le fichier des adeptes aura celle-ci~: deny 192.0.2.23 255.255.255.255 permit 192.0.2.0 255.255.255.0 Cela doit tout configurer correctement. Chaque réseau est isolé comme il faut, avec le niveau d'interaction approprié. Chacun peut être heureux. Maintenant, cherchez vos cristaux 6,5~MHz. Honeypot 11. Honeypots and Deception Systems While not strictly sniffer-based intrusion detection systems, honeypots still process network protocols in much the same ways. Therefore, I've decided to add this section to my FAQ. 11.1 What is a honeypot? A honeypot is a system designed to look like something that an intruder can hack. Examples can be: Installing a machine on the network with no particular purpose other than to log all attempted access. Installing an older unpatched operating system on a machine. For example, the default installation of WinNT 4 with IIS 4 can be hacked using several different techniques. A standard intrusion detection system can then be used to log hacks directed against the machine, and further track what the intruder attempts to do with the system once it is compromised. Install special software designed for this purpose. It has the advantage of making it look like the intruder is successful without really allowing them access. Any existing system can be "honeypot-ized". For example, on WinNT, it is possible to rename the default "administrator" account, then create a dummy account called "administrator" with no password. WinNT allows extensive logging of a person's activities, so this honeypot will track users attempting to gain adminstrator access and exploit that access. 11.2 What are the advantages of a honeypot? An early-alarm that will trip only upon hostile activity. Network intrusion detection systems have a problem distinguishing hostile traffic from benign traffic. Isolated honeypots have a much easier time because they are systems that should not normally be accessed. This means that all traffic to a honeypot system is already suspect. Network management discovery tools and vulnerability assessment tools still cause false positives, but they otherwise give a better detection rate. A hostile-intent assessment system. Honeypots often present themselves as easily hacked systems. One of the most common things hackers do is scan the Internet doing "banner checks". The honeypot can be setup to provide a banner that looks like a system that can easily be hacked, then to trigger is somebody actually does the hack. For example, the POP3 service reports the version of the software. Several versions of well-known packages have buffer-overflow holes. A hacker connections to port 110, grabs the version info from the banner, then looks up the version in a table that points to which exploit script can be used to break into the system. 11.3 What are the disadvantages of a honeypot? If the system does indeed get hacked, it can be used as a stepping stone to further compromise the network. Some people believe that since honeypots lure hackers in, that legal rights to prosecute hackers are reduced. This is a misconception, because honeypots are not active lures -- they do not advertise themselves. A hacker can only find a honeypot in the first place by running search programs on a network. Honeypots add complexity. In security, complexity is bad: it leads to increased exposure to exploits. Honepots must be maintained just like any other networking equipment/services. This leads many people to turn them off after a while. You think that a 468 running RedHat Linux 4.2 that you setup 2 years ago doesn't require maintainance, but in reality it does. How do you know the logging is working right? What do you do when a new network management platform or vulnerability assessment system starts being used and alarmas start going off? What do you do when alarms stop coming in because a hacker has compromised the system and is using it launch other attacks against you (or worse, back out to the Internet)? 11.4 How can I setup my own honepot? The thing to remember is that setting up honepots is really easy. While honeypot products are cool, virtually any existing hardware/software can be setup to be your honeypot. Your gameplan should consist of the following steps: documentation, documentation, documentation The first step in any network management endeavor (actually, the last step when people discover the pain of not having done it in the first place). maintainance plan How do you plan on maintaining it? alarm reporting How do you plan on receiving alarms from the system? reaction plan What do you plan on doing when an alarm goes off? 11.5 What are the types of honeypots? Port monitors The simplest honeypot is simply a sockets-based program that opens up a listening port. A typical example of this is the program NukeNabber (for Windows) that listens on ports typically scanned for by hackers. This alerts the user that they are being scanned. The disadvantage of these programs are: In most cases where they are used, it is actually better to setup a personal firewall to block access from the attacker. Port monitors don't log any better than firewall would. They alert the hacker that such a system is running because they first accept, then drop, the connection. Deception systems The next logical step beyond the port monitor is a system that actually interacts with the hacker. For example, rather than simply accepting port 110 for POP3, then dropping it, a deception system will actually respond as if it were a POP3 server. It may give a generic banner, or it may generate a banner with a version number that hackers know they can hack. Since 99% of attacks against POP3 are bufferoverruns in the username or passwords, most deception systems only implement that portion of the protocol. Likewise, most deception systems implement only as much of the protocol machine as necessary to trap 90% of the attacks against the protocol. Multi-protocol deception systems Packages like Specter or Fred Cohen's Deception Toolkit offer most of the commonly hacked protocols in a single toolkit. Likewise, these systems come with multiple banners in order to emulate packages for different operating systems. Full systems Beyond products targetted directly at deception, you can also implement full systems. Most systems have the ability to alert on exception conditions. By using the native logging/auditing built into such Full systems plus NIDS Along with the full system mentioned above, you might want to include a full intrusion detection system to supplement the internal logging. 11.6 What are the pros/cons of setting up a system that can be hacked? The three most commonly hacked servers on the net are unpatched systems running older Linux (like RedHat 5.0), Solaris 2.6, and Microsoft IIS 4.0. Therefore, as part of your honeypot plan, you might want to setup one or all three of these systems. Remember: if you put one of these systems on the Internet, within a month it will be discovered and hacked. Pros: Learn about incidence response Most people believe "it can't happen to them", and are unprepared when it does. Setting up systems that hackers break into will teach you about how to detect hacker breakins and how to clean up after them. Learn about hacking techniques Watching hackers break into your system teaches you a lot about hacking. If you need a secure system inside your company (for example, one that holds financial information), setup a similar system outside your company with bogus data. If a hacker compromises that system, you'll learn how to protect the one inside your company from similar exploits. Early warning systems Setting up servers inside your company that can easily be hacked will alert you to hostile activity long before real systems get compromised. Hackers try the simpler techniques first before moving on to harder ways of breaking into system. Therefore, setting up an easily hacked system will clearly indicate the hostile intent of somebody. Cons: Launching Point The biggest danger is that somebody could use that system to launch further attacks against either you or other people. In particular, there might be legal considerations when a system you control attacks a third party. 11.7 Are there examples of people using honeypots? The book The Cuckoo's Egg by Clifford Stoll is an engaging story about a researcher who bumbles his way into tracking down a hacker who was abusing the university's computer systems. The researcher basically left the system open and vulnerable for about a year in order to track the hacker's activities. The San Diego Supercomputer Center has left machines up that can be hacked. http://security.sdsc.edu/incidents/worm.2000.01.18.shtml 11.8 What honeypot products are available? The following are products that I know of. Fred Cohen's Deception Toolkit http://www.all.net/dtk/ Specter http://www.specter.ch/ NAI CyberCop Sting http://www.nai.com/ netcat The netcat tool can be used to respond with deceptive banners. 11.9 What are deception countermeasures? Beyond honeypots in particular, you can setup "deception countermeasures". Your network "leaks" lots of information about itself, which hackers in turn use to break into your network. Therefore, if you leaks deceptive information about you network, then you'll at minimum misdirect your attackers, but hopefully trigger alerts. I personally have done the following sorts of things: E-mail headers A classic problem on the web is that e-mail systems insert the IP address of the system sending the message to it. If you are inside a corporation and send e-mail out, you reveal internal e-mail servers. If you are using a free e-mail system like Yahoo mail or Hotmail, the IP address of the machine you used to send the mail is included in the header. This process can go several level deep as e-mail inside companies often travel several hops through gateway, firewalls, and anti-virus content scanners. It's difficult, but you can reprogram things in order to insert bogus IP addresses in to the headers. DNS info One of the first things a hacker will do against you is a DNS Zone Transfer. Many admins blocks access to TCP port 53 to stop this (though that breaks other DNS services). By inserting bogus machines or even entire bogus subdomains you misdirect the hacker. For example, I could setup a machine called "bogus.robertgraham.com" with an IP address of 192.0.2.132, then tell my IDS to trigger whenever it sees traffic to that address. Since my IDS already triggers on Zone Transfers, this'll catch somebody who is seriously trying to scope out my network. anti-sniffers Are you certain that your ISP isn't sniffing you? Well, in order to find out, setup machines elsewhere on the Internet to connect to some of your boxes using clear-text passwords. Then setup your IDS to trigger when anybody else uses those passwords. This is best used with a honeypot that doesn't have real services. For example, I've setup a virtual Telnet daemon on that another machines logs into every once-and-a-while. I've setup the IDS to trigger if anybody but that machine logs in using that account name. When they log in, they will soon find out it isn't real account. anti-sniffers, part deux Similar to above, you can transfer password files across the network that contain easily crackable passwords, then have the IDS trigger whenever anybody attempts to login. For example, setup a batch file that regularly transfers files via FTP, one of which is /etc/passwd. This will tell you if anybody has sniffed that file. 11.10 What are the legal implication of honeypots? 11.10.1 Do honeypots constitute entrapment? No. This is the most commonly asked question about honeypots, and the answer is a clear no. Entrapment has a clear legal definition whereby law enforcement officers encourage somebody to a commit a crime that they were not otherwise disposed to do. This means: If you are not a law enforcement officer, you cannot entrap. Affording the means for somebody to commit a crime is not the same as encouraging the crime. The FBI can setup a honeypot without risk of entrapment. If the FBI contacts somebody in alt.2600 and posts a bounty for cracking into a system, then it would be entrapment. 11.10.2 Am I aiding and abetting a crime? Possibly. You are centainly not abetting the person breaking into your system. However, if the he/she uses your system to launch attacks against other systems, you might be partially liable for the actions. http://www.nylj.com/stories/00/03/030200a5.htm IP-Masquerading IP-Masquerading est une technique géniale pour protéger très efficacement un réseau local des attaques, tout en gardant une grande transparence. A l'heure actuelle, seul Linux est capable de réaliser cela pour un prix raisonnable - Linux est gratuit! -. Le fonctionnement de ce système n'est pas difficile à comprendre, mais bien à expliquer! Dans les grandes lignes, voici la philosophie: on déclare une machine comme étant ambassadrice pour un réseau donné à sécuriser. On dit aux machines d'utiliser cet ambassadeur pour faire leurs demandes. En pratique, vous devez configurer cette machine comme gateway pour tous les clients. Ce gateway n'est rien d'autre qu'une machine avec Linux et IP-Masquerading correctement configuré. Cela se fait à l'aide du programme ipfwadm, qui bénéficie d'une documentation très claire.. Lorsqu'une demande arrive sur le gateway depuis de réseau local, elle est mise de coté et le gateway génère une nouvelle demande, identique, qu’il envoit à l’extérieur. Lorsque le gateway a la réponse, il la renvoie à la machine qui avait demandé le paquet. Le client croit que son paquet a fait un chemin normal et est revenu par la voie normale alors qu'en réalité, il a été intercepté. Ce système présente des avantages incroyables, qu'on ne trouve nulle par ailleurs: Le firewall est absolument transparent pour toutes les applications. Que ce soit un programme de mail, de l'IRC ou du Real-Audio! C'est le gateway qui réalise toutes les demandes. On n’a donc besoin que d'une seule adresse IP réelle, les autres pouvant être fictives. Vous pouvez d'ailleurs vous en servir chez vous, pour relier plusieurs machines sur Internet en même temps avec un seul modem. IP-Masquerading offre une excellente protection contre les attaques. Il est d'ailleurs (jusqu'à preuve du contraire) d'accéder aux ressources internes. Le système est simple à mettre en oeuvre. Linux vous offre les fonctionnalités d'un firewall évolué pour protéger le firewall lui-même. IPsec : présentation technique © Ghislaine Labouret Hervé Schauer Consultants Introduction Le terme IPsec (IP Security Protocol) désigne un ensemble de mécanismes destinés à protéger le trafic au niveau d'IP (IPv4 ou IPv6). Les services de sécurité offerts sont l'intégrité en mode non connecté, l'authentification de l'origine des données, la protection contre le rejeu et la confidentialité (confidentialité des données et protection partielle contre l'analyse du trafic). Ces services sont fournis au niveau de la couche IP, offrant donc une protection pour IP et tous les protocoles de niveau supérieur. Optionnel dans IPv4, IPsec est obligatoire pour toute implémentation de IPv6. Une fois IPv6 en place, il sera ainsi possible à tout utilisateur désirant des fonctions de sécurité d'avoir recours à IPsec. IPsec est développé par un groupe de travail du même nom à l'IETF (Internet Engineering Task Force), groupe qui existe depuis 1992. Une première version des mécanismes proposés a été publiée sous forme de RFC en 1995, sans la partie gestion des clefs. Une seconde version, qui comporte en plus la définition du protocole de gestion des clefs IKE, a été publiée en novembre 1998. Mais IPsec reste une norme non figée qui fait en ce moment même l'objet de multiples Internet drafts, notamment sur la protection des accès distants. Cette présentation couvre uniquement les RFC de novembre 1998. 1. Vue d'ensemble Cette partie présente le principe de fonctionnement d'IPsec, les différents éléments qui le composent, la façon dont ils interagissent et les différentes utilisations possibles. 1.1. Architecture d'IPsec Pour sécuriser les échanges ayant lieu sur un réseau TCP/IP, il existe plusieurs approches, en particulier en ce qui concerne le niveau auquel est effectuée la sécurisation : niveau applicatif (mails chiffrés par exemple), niveau transport (TLS/SSL, SSH...), ou à l'opposé niveau physique (boîtiers chiffrant toutes les données transitant par un lien donné). IPsec, quant à lui, vise à sécuriser les échanges au niveau de la couche réseau. Les mécanismes AH et ESP Pour cela, IPsec fait appel à deux mécanismes de sécurité pour le trafic IP, les "protocoles" AH et ESP, qui viennent s'ajouter au traitement IP classique : Authentication Header (AH) est conçu pour assurer l'intégrité et l'authentification des datagrammes IP sans chiffrement des données (i.e. sans confidentialité). Le principe de AH est d'adjoindre au datagramme IP classique un champ supplémentaire permettant à la réception de vérifier l'authenticité des données incluses dans le datagramme . Encapsulating Security Payload (ESP) a pour rôle premier d'assurer la confidentialité, mais peut aussi assurer l'authenticité des données. Le principe de ESP est de générer, à partir d'un datagramme IP classique, un nouveau datagramme dans lequel les données et éventuellement l'en-tête original sont chiffrés. Ces mécanismes peuvent être utilisés seuls ou combinés pour obtenir les fonctions de sécurité désirées. La notion d'association de sécurité Les mécanismes mentionnés ci-dessus font bien sûr appel à la cryptographie, et utilisent donc un certain nombre de paramètres (algorithmes de chiffrement utilisés, clefs, mécanismes sélectionnés...) sur lesquels les tiers communicants doivent se mettre d'accord. Afin de gérer ces paramètres, IPsec a recours à la notion d'association de sécurité (Security Association, SA). Une association de sécurité IPsec est une "connexion" simplexe qui fournit des services de sécurité au trafic qu'elle transporte. On peut aussi la considérer comme une structure de données servant à stocker l'ensemble des paramètres associés à une communication donnée. Une SA est unidirectionnelle ; en conséquence, protéger les deux sens d'une communication classique requiert deux associations, une dans chaque sens. Les services de sécurité sont fournis par l'utilisation soit de AH soit de ESP. Si AH et ESP sont tous deux appliqués au trafic en question, deux SA (voire plus) sont créées ; on parle alors de paquet (bundle) de SA. Chaque association est identifiée de manière unique à l'aide d'un triplet composé de : L'adresse de destination des paquets. L'identifiant d'un protocole de sécurité utilisé (AH ou ESP). Un index des paramètres de sécurité (Security Parameter Index, SPI). Un SPI est un bloc de 32 bits inscrit en clair dans l'en-tête de chaque paquet échangé ; il est choisi par le récepteur. Pour gérer les associations de sécurité actives, on utilise une "base de données des associations de sécurité" (Security Association Database, SAD). Elle contient tous les paramètres relatifs à chaque SA et sera consultée pour savoir comment traiter chaque paquet reçu ou à émettre. La gestion des clefs et des associations de sécurité Comme nous l'avons mentionné au paragraphe précédent, les SA contiennent tous les paramètres nécessaires à IPsec, notamment les clefs utilisées. La gestion des clefs pour IPsec n'est liée aux autres mécanismes de sécurité de IPsec que par le biais des SA. Une SA peut être configurée manuellement dans le cas d'une situation simple, mais la règle générale est d'utiliser un protocole spécifique qui permet la négociation dynamique des SA et notamment l'échange des clefs de session. D'autre part, IPv6 n'est pas destiné à supporter une gestion des clefs "en bande", c'est-à-dire où les données relatives à la gestion des clefs seraient transportées à l'aide d'un en-tête IPv6 distinct. Au lieu de cela on utilise un système de gestion des clefs dit "hors bande", où les données relatives à la gestion des clefs sont transportées par un protocole de couche supérieure tel que UDP ou TCP. Ceci permet le découplage clair du mécanisme de gestion des clefs et des autres mécanismes de sécurité. Il est ainsi possible de substituer une méthode de gestion des clefs à une autre sans avoir à modifier les implémentations des autres mécanismes de sécurité. Le protocole de négociation des SA développé pour IPsec s'appelle "protocole de gestion des clefs et des associations de sécurité pour Internet" (Internet Security Association and Key Management Protocol, ISAKMP). ISAKMP est en fait inutilisable seul : c'est un cadre générique qui permet l'utilisation de plusieurs protocoles d'échange de clef et qui peut être utilisé pour d'autres mécanismes de sécurité que ceux de IPsec. Dans le cadre de la standardisation de IPsec, ISAKMP est associé à une partie des protocoles SKEME et Oakley pour donner un protocole final du nom d'IKE (Internet Key Exchange). Ces protocoles seront décrits en détail au chapitre "3. La gestion des clefs". Politique de sécurité Les protections offertes par IPsec sont basées sur des choix définis dans une "base de données de politique de sécurité" (Security Policy Database, SPD). Cette base de données est établie et maintenue par un utilisateur, un administrateur système ou une application mise en place par ceux-ci. Elle permet de décider, pour chaque paquet, s'il se verra apporter des services de sécurité, sera autorisé à passer outre ou sera rejeté. La SPD contient une liste ordonnée de règles, chaque règle comportant un certain nombre de critères qui permettent de déterminer quelle partie du trafic est concernée. Les critères utilisables sont l'ensemble des informations disponibles par le biais des en-têtes des couches IP et transport. Ils permettent de définir la granularité selon laquelle les services de sécurité sont applicables et influencent directement le nombre de SA correspondante. Dans le cas où le trafic correspondant à une règle doit se voir attribuer des services de sécurité, la règle indique les caractéristiques de la SA (ou paquet de SA) correspondante : protocole(s), modes, algorithmes requis... 1.2. Principe de fonctionnement Le schéma ci-dessous représente tous les éléments présentés ci-dessus (en bleu), leurs positions et leurs interactions. - Figure 1. Organisation de IPsec On distingue deux situations : Trafic sortant Lorsque la "couche" IPsec reçoit des données à envoyer, elle commence par consulter la base de donnée des politiques de sécurité (SPD) pour savoir comment traiter ces données. Si cette base lui indique que le trafic doit se voir appliquer des mécanismes de sécurité, elle récupère les caractéristiques requises pour la SA correspondante et va consulter la base des SA (SAD). Si la SA nécessaire existe déjà, elle est utilisée pour traiter le trafic en question. Dans le cas contraire, IPsec fait appel à IKE pour établir une nouvelle SA avec les caractéristiques requises. Trafic entrant Lorsque la couche IPsec reçoit un paquet en provenance du réseau, elle examine l'en-tête pour savoir si ce paquet s'est vu appliquer un ou plusieurs services IPsec et si oui quelles sont les références de la SA. Elle consulte alors la SAD pour connaître les paramètres à utiliser pour la vérification et/ou le déchiffrement du paquet. Une fois le paquet vérifié et/ou déchiffré, la SPD est consultée pour savoir si l'association de sécurité appliquée au paquet correspondait bien à celle requise par les politiques de sécurité. Dans le cas où le paquet reçu est un paquet IP classique, la SPD permet de savoir s'il a néanmoins le droit de passer. Par exemple, les paquets IKE sont une exception. Ils sont traités par IKE, qui peut envoyer des alertes administratives en cas de tentative de connexion infructueuse. 1.3. Types d'utilisations possibles Après avoir vu comment est constitué IPsec et comment il fonctionne, nous allons maintenant nous intéresser aux différentes façons de l'utiliser. Un point important à retenir est que le fait d'intervenir au niveau réseau rend la sécurisation totalement transparente pour les applications. Équipement fournissant IPsec IPsec peut être utilisé au niveau d'équipements terminaux ou au niveau de passerelles de sécurité (security gateway), permettant ainsi des approches de sécurisation lien par lien comme de bout en bout. Trois configurations de base sont possibles : - Figure 2. Différentes configurations possibles suivant l'équipement mettant IPsec en ?uvre La première situation est celle où l'on désire relier des réseaux privés distants par l'intermédiaire d'un réseau non fiable, typiquement Internet. Les deux passerelles de sécurité permettent ici d'établir un réseau privé virtuel (en anglais Virtual Private Network, VPN). La deuxième situation correspond au cas où l'on désire fournir un accès sécurisé au réseau interne pour des postes nomades. Le réseau non fiable peut être Internet, le réseau téléphonique... Enfin, dans la troisième situation, deux tiers désirent communiquer de façon sécurisée mais n'ont aucune confiance dans le réseau qui les sépare. On peut également imaginer des configurations plus complexes où plusieurs associations de sécurité, apportant éventuellement des services de sécurité différents, se succéderaient ou se superposeraient partiellement : - Figure 3. Exemples de double utilisation d'IPsec Dans les exemples ci-dessus, la première association peut servir à assurer les services de sécurité requis par la politique de sécurité externe (authentification et confidentialité par exemple), et la seconde à assurer les services requis par la politique de sécurité interne (authentification vis-à-vis de l'hôte final par exemple). Modes de fonctionnement Pour chacun des mécanismes de sécurité d'IPsec, il existe deux modes : le mode transport et le mode tunnel. En mode transport, seules les données en provenance du protocole de niveau supérieur et transportées par le datagramme IP sont protégées. Ce mode n'est utilisable que sur des équipements terminaux ; en effet, en cas d'utilisation sur des équipements intermédiaires, on courrait le risque, suivant les aléas du routage, que le paquet atteigne sa destination finale sans avoir traversé la passerelle sensée le déchiffrer. En mode tunnel, l'en-tête IP est également protégé (authentification, intégrité et/ou confidentialité) et remplacé par un nouvel en-tête. Ce nouvel en-tête sert à transporter le paquet jusqu'à la fin du tunnel, où l'en-tête original est rétabli. Le mode tunnel est donc utilisable à la fois sur des équipements terminaux et sur des passerelles de sécurité. Ce mode permet d'assurer une protection plus importante contre l'analyse du trafic, car il masque les adresses de l'expéditeur et du destinataire final. 2. Les mécanismes de sécurité : AH et ESP Ainsi que nous l'avons déjà mentionné dans le chapitre précédent, deux mécanismes de base permettent d'assurer l'ensemble des fonctions de sécurité fournies par IPsec. Ce sont : Authentication Header (AH), qui est conçu pour assurer l'intégrité et l'authentification des datagrammes IP sans chiffrement des données (i.e. sans confidentialité). Encapsulating Security Payload (ESP), dont le rôle premier est d'assurer la confidentialité. Ces mécanismes peuvent être utilisés seuls ou combinés pour obtenir les fonctions de sécurité désirées. Les mécanismes IPsec ne sont liés à aucun algorithme cryptographique spécifique, donc ces algorithmes peuvent être modifiés sans affecter les autres éléments d'une implémentation. Pour assurer l'interopérabilité, des algorithmes cryptographiques par défaut sont toutefois indiqués. Par ailleurs, les propriétés de l'algorithme utilisé influenceront les fonctions de sécurité fournies. Nous allons commencer par rappeler les quelques principes relatifs aux services et mécanismes de sécurité dans le cadre de la protection des échanges, avant de détailler le fonctionnement des protocoles AH et ESP. 2.1. Rappels sur les services de sécurité et les mécanismes associés Confidentialité La confidentialité est un service de sécurité qui consiste à s'assurer que seules les personnes autorisées peuvent prendre connaissance d'un ensemble de données. Le mécanisme qui permet d'obtenir ce service est généralement le chiffrement des données concernées à l'aide d'un algorithme cryptographique. Dans le cadre du chiffrement d'échanges réseau, on utilise toujours, pour des raisons de performance, des algorithmes de chiffrement symétriques. Si seules les données transportées sont chiffrées, un espion peut tout de même observer des caractéristiques extérieures du trafic transitant sur un réseau afin de tenter d'en tirer des informations : fréquence des transmissions, identités des tiers communicants, quantités de données transférées. Associées à des informations de nature différente (date de rendez-vous, actualité...) ces éléments peuvent permettre aux adversaires de faire des déductions intéressantes. On parle de protection contre l'analyse du trafic lorsqu'on tente d'empêcher l'analyse du trafic en cachant les adresses source et destination, la taille des paquets, la fréquence des échanges... Authentification et intégrité On distingue deux types d'authentification : L'authentification d'un tiers est l'action qui consiste à prouver son identité. Ce service est généralement rendu par l'utilisation d'un "échange d'authentification" qui implique un certain dialogue entre les tiers communicants. L'authentification de l'origine des données sert à prouver que les données reçues ont bien été émises par l'émetteur déclaré. L'intégrité est un service de sécurité qui consiste à s'assurer que seules les personnes autorisées pourront modifier un ensemble de données. Dans le cadre de communications, ce service consiste à permettre la détection de l'altération des données durant le transfert. On distingue deux types d'intégrité : L'intégrité en mode non connecté permet de détecter des modifications sur un datagramme individuel, mais pas sur l'ordre des datagrammes. L'intégrité en mode connecté permet en plus de détecter la perte de paquets ou leur réordonnancement. Lorsque l'on communique avec une autre personne au travers d'un canal peu sûr, on aimerait que le destinataire puisse s'assurer que le message émane bien de l'auteur auquel il est attribué et qu'il n'a pas été altéré pendant le transfert. Les services correspondant sont l'authentification de l'origine des données et l'intégrité. Les fonctions de hachage à sens unique permettent d'assurer l'intégrité des données : appliquée à un ensemble de données, une telle fonction génère un bloc de taille plus petite appelée empreinte. Toute modification des données entraîne une modification de l'empreinte, et il est très difficile de générer un message ayant la même empreinte que l'original. Si l'on dispose d'un canal sûr (mais plus coûteux) en parallèle du canal de communication normal, on peut communiquer l'empreinte des messages par l'intermédiaire de ce canal. À la réception, le destinataire recalcule l'empreinte et la compare à l'original pour vérifier que les données n'ont pas été modifiées. Sans canal sûr, le problème se complique : si l'on transfère l'empreinte sur un canal de communication non sûr, un intercepteur peut modifier les données puis recalculer l'empreinte. Il convient donc de trouver une méthode pour s'assurer que seul l'expéditeur est capable de calculer l'empreinte. Pour cela, on peut utiliser, par exemple, une fonction de hachage à sens unique qui fonctionne de plus avec une clef secrète ou privée. On remarquera que, ce faisant, on fournit également l'authentification de l'origine des données. Inversement, si on désire fournir l'authentification de l'origine des données et que l'on utilise pour cela un moyen qui ne garantit pas l'intégrité des données authentifiées, un intrus peut modifier le message et donc faire accepter comme authentifiées des données qu'il a choisies. C'est pourquoi intégrité et authentification de l'origine des données sont généralement fournies conjointement par un même mécanisme. Le terme "authenticité" désigne l'intégrité jointe à l'authentification des données. Par abus de langage, le terme "authentification" est également couramment utilisé pour désigner en fait authentification et intégrité. Les deux mécanismes permettant d'assurer l'authenticité des données transmises sont le scellement et la signature. Le scellement consiste à adjoindre au message un sceau ou code d'authentification de message (Message Authentication Code, MAC), qui est le résultat d'une fonction de hachage à sens unique à clef secrète. L'empreinte dépend à la fois des données et de la clef ; elle n'est donc calculable que par les personnes connaissant la clef. La signature numérique assure également l'authenticité des données et fournit en plus la nonrépudiation : l'émetteur ne peut pas nier avoir émis un message qu'il a signé. Ce dernier point différencie la signature des codes d'authentification de message, et a pour conséquence que la plupart des algorithmes de signature utilisent la cryptographie à clef publique. Dans le cadre de la protection d'échanges réseau, on utilise toujours, pour des raisons de performance, un mécanisme de scellement. Enfin, la protection contre le rejeu est une forme partielle d'intégrité en mode connecté qui permet de contrer les attaques au cours desquelles un adversaire envoie un message intercepté précédemment, en espérant qu'il sera accepté comme valide par le destinataire. Elle est généralement assurée par l'utilisation d'un numéro de séquence. 2.2. Authentication Header (AH) AH assure l'intégrité des données en mode non connecté, l'authentification de l'origine des données et, de façon optionnelle, la protection contre le rejeu. L'absence de confidentialité dans AH permet de s'assurer que ce standard pourra être largement répandu sur l'Internet, y compris dans les endroits où l'exportation, l'importation ou l'utilisation du chiffrement dans des buts de confidentialité est restreint par la loi. Cela constitue l'une des raisons de l'utilisation de deux mécanismes distincts. Dans AH, intégrité et authentification sont fournies ensembles, à l'aide d'un bloc de données supplémentaire adjoint au message à protéger. Ce bloc de données est appelé "valeur de vérification d'intégrité" (Integrity Check Value, ICV),terme générique pour désigner soit un code d'authentification de message (Message Authentication Code, MAC), soit une signature numérique. Pour des raisons de performances, les algorithmes proposés actuellement sont tous des algorithmes de scellement (code d'authentification de message et non signature). La protection contre le rejeu se fait grâce à un numéro de séquence ; elle n'est disponible que si IKE est utilisé, car en mode manuel aucune "ouverture de connexion" ne permet d'initialiser le compteur. Voici l'organisation de l'en-tête d'authentification : - Figure 4. Format de AH L'expéditeur calcule les données d'authentification à partir de l'ensemble des champs invariants du datagramme IP final, AH compris, ce qui permet d'étendre l'authentification au SPI et au numéro de séquence notamment. Les champs variables (TTL, routage...) et le champ destiné à recevoir les données d'authentification sont considérés comme égaux à zéro pour le calcul. Les données d'authentification sont alors adjointes au paquet IP par le biais de l'en-tête d'authentification (AH). Le récepteur vérifie l'exactitude de ces données à la réception. Les figures ci-dessous indiquent la position de AH et le service apporté en fonction du mode choisi (transport ou tunnel). - Figure 5. Position de AH en mode transport (IPv4) - - Figure 6. Position de AH en mode tunnel (IPv4) Les algorithmes par défaut que doit fournir toute réalisation de IPsec pour AH sont, au moment où ce document est rédigé, HMAC-MD5 et HMAC-SHA-1. Les autres algorithmes prévus sont KPDK-MD5, DES-MAC et HMAC-RIPE-MD. 2.3. Encapsulating Security Payload (ESP) ESP peut assurer, au choix, un ou plusieurs des services suivants : confidentialité (confidentialité des données et protection partielle contre l'analyse du trafic si l'on utilise le mode tunnel), intégrité des données en mode non connecté et authentification de l'origine des données, protection contre le rejeu. La confidentialité peut être sélectionnée indépendamment des autres services, mais son utilisation sans intégrité/authentification (directement dans ESP ou avec AH) rend le trafic vulnérable à certains types d'attaques actives qui pourraient affaiblir le service de confidentialité. Comme dans AH, authentification et intégrité sont deux services qui vont de pair et que l'on désigne souvent sous le terme "authentification" ; ils sont fournis par l'utilisation d'une ICV (en pratique, un MAC). La protection contre le rejeu ne peut être sélectionnée que si l'authentification l'a été et que IKE est utilisé. Elle est fournie par un numéro de séquence que le destinataire des paquets vérifie. Contrairement à AH, où l'on se contentait d'ajouter un en-tête supplémentaire au paquet IP, ESP fonctionne suivant le principe de l'encapsulation : les données originales sont chiffrées puis encapsulées entre un en-tête et un trailer. Voici l'organisation de ESP : - Figure 7. Format de ESP - Le champ bourrage peut être nécessaire pour les algorithmes de chiffrement par blocs ou pour aligner le texte chiffré sur une limite de 4 octets. Les données d'authentification ne sont présentes que si ce service a été sélectionné. Voyons maintenant comment est appliquée la confidentialité dans ESP. L'expéditeur : Encapsule, dans le champ "charge utile" de ESP, les données transportées par le datagramme original et éventuellement l'en-tête IP (mode tunnel). Ajoute si nécessaire un bourrage. Chiffre le résultat (données, bourrage, champs longueur et en-tête suivant). Ajoute éventuellement des données de synchronisation cryptographiques (vecteur d'initialisation) au début du champ "charge utile". Si elle a été sélectionnée, l'authentification est toujours appliquée après que les données ne soient chiffrées. Cela permet, à la réception, de vérifier la validité du datagramme avant de se lancer dans la coûteuse tâche de déchiffrement. Contrairement à AH, l'authentification dans ESP est appliquée uniquement sur le "paquet" (en-tête + charge utile + trailer) ESP et n'inclut ni l'en-tête IP ni le champ d'authentification. Les figures ci-dessous indiquent la position de ESP et les services apportés en fonction du mode choisi (transport ou tunnel). - Figure 8. Position de ESP en mode transport (IPv4) - - Figure 9. Position de ESP en mode tunnel (IPv4) Les algorithmes prévus pour être utilisés avec ESP sont, au moment où ce document est rédigé : Confidentialité : DES triple (obligatoire), DES, RC5, CAST, IDEA, IDEA triple, Blowfish, RC4 et NULL pour le cas ou le chiffrement n'est pas souhaité. Authentification : HMAC-MD5 (obligatoire), HMAC-SHA-1 (obligatoire), DES-MAC, HMACRIPE-MD, KPDK-MD5 et NULL pour le cas où l'authenticité n'est pas sélectionnée. 3. La gestion des clefs Les protocoles sécurisés présentés dans le chapitre précédent ont recours à des algorithmes cryptographiques et ont donc besoin de clefs. Un des problèmes fondamentaux d'utilisation de la cryptographie est la gestion de ces clefs. Le terme "gestion" recouvre la génération, la distribution, le stockage et la suppression des clefs. 3.1. Concepts généraux relatifs à la gestion des clefs Ce paragraphe a pour but de présenter un certain nombre de concepts utiles pour la compréhension des parties de cette présentation relatives à la gestion des clefs. 3.1.1. Types de clefs On peut définir plusieurs types de clefs suivant leurs rôles : Clefs de chiffrement de clefs Ces clefs servent exclusivement à chiffrer d'autres clefs et ont généralement une durée de vie longue. On notera que leur utilisation, restreinte au chiffrement de valeurs aléatoires que sont des clefs, rend les attaques par cryptanalyse plus difficiles à leur niveau. La cryptographie à clef publique est souvent utilisée pour le transport de clefs en chiffrant la clef à transporter à l'aide d'une clef publique. Clefs maîtresses Les clefs maîtresses sont des clefs qui ne servent pas à chiffrer mais uniquement à générer d'autres clefs par dérivation. Une clef maîtresse peut ainsi être utilisée, par exemple, pour générer deux clefs : une pour le chiffrement et une pour la signature. Clefs de session ou de chiffrement de données D'une durée d'utilisation généralement faible (elle peut aller jusqu'à changer à chaque message), une telle clef, par opposition aux précédentes, sert à chiffrer des données. Du fait de leur lenteur, les algorithmes asymétriques sont très peu utilisés en chiffrement de données, et les clefs de session sont donc généralement des clefs secrètes. Il est à noter que des abus de langage ont souvent lieu avec ces termes. Ainsi, on parle parfois de clef de session pour désigner en fait une clef maîtresse de même durée de vie et servant à générer plusieurs clefs : une pour l'authentification, une pour le chiffrement... 3.1.2. Infrastructures à clef publique De nombreux protocoles et applications utilisent la cryptographie à clef publique à grande échelle et doivent donc pouvoir gérer des listes importantes de clefs publiques pour des systèmes distribués. Pour cela, ils ont recours à des à des infrastructures à clés publiques, systèmes de gestion des clés publiques prévus pour une utilisation à grande échelle. La plupart de ces systèmes se basent sur des autorités de certification (Certificate Authorities, CA) qui sont habilitées à délivrer des certificats. Plus précisément, elles vérifient et authentifient des clés publiques. Ces autorités sont généralement organisées en une hiérarchie qui permet une plus grande souplesse pour la gestion des clés publiques par le biais de certificats signés par ces autorités et de listes de révocations de certificats (Certificate Revocation Lists, CRL). Il existe de nombreuses PKI, la plupart en cours d'évolution. Des exemples d'infrastructures à clef publiques sont PKIX (Public-Key Infrastructure X.509) et SPKI (Simple Public Key Infrastructure) et DNSSEC (Domain Name System Security), qui font toutes trois l'objet d'une normalisation à l'IETF. 3.1.3. Échange de clefs et authentification Pour établir une communication sécurisée, on procède généralement, en premier lieu, à une authentification à des fins de contrôle d'accès. Puis, un échange de clef permet l'utilisation d'un mécanisme de sécurisation des échanges : l'authentification est ainsi étendue à la suite de la communication. Il va de soi que l'échange de clef doit nécessairement être authentifié. La combinaison de l'authentification et de l'échange de clef prend la forme d'un échange de messages appelé protocole d'authentification mutuelle avec échange de clef. 3.1.4. Propriétés des protocoles d'échange de clef Diffie, Van Oorschot et Wiener définissent, dans [DOW92], la notion de protocole d'authentification mutuelle avec échange de clef sûr. Un protocole est dit sûr si les deux conditions suivantes sont valables dans chaque instance du protocole où l'un des deux tiers, par exemple Alice, exécute le protocole honnêtement et accepte l'identité de l'autre tiers : Au moment où Alice accepte l'identité de Bob, les enregistrements des messages échangés par les deux tiers se correspondent (i.e. les messages n'ont pas été altérés en route). Il est matériellement impossible pour toute personne autre que les tiers en présence de retrouver la clef échangée. La propriété évoquée ci-dessus représente le minimum requis pour tout protocole. Cependant, d'autres propriétés des protocoles d'échange de clef peuvent être souhaitables : La propriété dite de Perfect Forward Secrecy (PFS) est garantie si la découverte par un adversaire du ou des secrets à long terme ne compromet pas les clefs de session générées précédemment : les clefs de session passées ne pourront pas être retrouvées à partir des secrets à long terme. On considère généralement que cette propriété assure également que la découverte d'une clef de session ne compromet ni les secrets à long terme ni les autres clefs de session. La propriété de Perfect Forward Secrecy peut être fournie, par exemple, par la génération des clefs de session au moyen du protocole Diffie-Hellman (voir cidessous), où les exponentiels Diffie-Hellman sont des valeurs à court terme. La propriété dite de Back Traffic Protection est fournie si la génération de chaque clef de session se fait de manière indépendante : les nouvelles clefs ne dépendent pas des clefs précédentes et la découverte d'une clef de session ne permet ni de retrouver les clefs de session passées ni d'en déduire les clefs à venir. On dit qu'il y a authentification directe (Direct Authentication) si, à la fin du protocole, les valeurs servant à générer le secret partagé sont authentifiées ou si chaque tiers a prouvé qu'il connaissait la clef de session. Par opposition, l'authentification est dite indirecte (Indirect authentication) si elle n'est pas garantie à la fin du protocole, mais dépend de la capacité de chaque tiers à utiliser, dans la suite des échanges, la ou les clefs mises en place précédemment. On parle de protection de l'identité (Identity Protection) lorsque le protocole garantit qu'un attaquant espionnant les échanges ne pourra pas connaître les identités des tiers communicants. Enfin, l'utilisation du temps (Timestamps) afin d'éviter la rejouabilité est très controversée du fait, principalement, de sa trop grande dépendance d'horloges synchronisées. 3.1.5. Diffie-Hellman Inventé en 1976 par Diffie et Hellman, ce protocole permet à deux tiers de générer un secret partagé sans avoir aucune information préalable l'un sur l'autre. Il est basé sur la cryptologie à clef publique (dont il est d'ailleurs à l'origine), car il fait intervenir des valeurs publiques et des valeurs privées. Sa sécurité dépend de la difficulté de calculer des logarithmes discrets sur un corps fini. Le secret généré à l'aide de ce protocole peut ensuite être utilisé pour dériver une ou plusieurs clefs (clef secrète, clef de chiffrement de clefs...). Voici le déroulement du protocole : 1. Alice et Bob se mettent d'accord sur un grand entier n tel que (n-1)/2 soit premier et sur un entier g primitif par rapport à n. Ces deux entiers sont publics. 2. Alice choisit de manière aléatoire un grand nombre entier a, qu'elle garde secret, et calcule sa valeur publique, A = ga mod n. Bob fait de même et génère b et B = gb mod n. 3. Alice envoie A à Bob ; Bob envoie B à Alice. 4. Alice calcule KAB = Ba mod n ; Bob calcule KBA = Ab mod n. KAB = KBA = gab mod n est le secret partagé par Alice et Bob. Une personne qui écoute la communication connaît g, n, A=ga mod n et B=gb mod n, ce qui ne lui permet pas de calculer gab mod n : il lui faudrait pour cela calculer le logarithme de A ou B pour retrouver a ou b. En revanche, Diffie-Hellman est vulnérable à l'attaque active dite attaque de l'intercepteur. Le principe de l'attaque de l'intercepteur (man-in-the-middle attack) est que, pendant que deux tiers procèdent à un échange de clef, en utilisant un protocole du type Diffie-Hellman par exemple, un adversaire se positionne entre les deux tiers et intercepte les échanges. De cette façon, il procède à un échange de clef avec chaque tiers. À la fin du protocole, chaque tiers utilisera donc une clef différente, chacune de ces clefs étant connue de l'intercepteur. Pour chaque message transmis par la suite, l'intercepteur procédera à son déchiffrement avec la clef correspondante puis le rechiffrera avec l'autre clef avant de l'envoyer à son destinataire : les deux tiers croiront communiquer de façon sûre alors que l'intercepteur pourra en fait lire tous les messages, voire même forger de faux messages. Voici comment se déroule cette attaque dans le cas de Diffie-Hellman : 1. Alice envoie sa valeur publique A = ga mod n à Bob ; Ingrid l'intercepteur remplace cette valeur publique par la sienne. Bob reçoit donc I = gi mod n. 2. Bob envoie sa valeur publique à Alice ; Ingrid remplace là aussi cette valeur par la sienne. 3. Alice génère le "secret" KAI = Ia mod n. Ingrid génère le même secret en calculant Ai mod n. 4. Bob génère le "secret" KBI = Ib mod n. Ingrid génère le même secret en calculant Bi mod n. Alice et Bob croient tous les deux être en possession d'un secret partagé, mais en fait chacun d'eux partage un secret différent avec Ingrid. Une façon de contourner le problème de l'attaque de l'intercepteur est d'authentifier les valeurs publiques utilisées pour la génération du secret partagé. Cela peut se faire à deux niveaux : En utilisant des valeurs publiques authentifiées, à l'aide de certificats par exemple. Cette méthode est notamment à la base du protocole SKIP. En authentifiant les valeurs publiques après les avoir échangées, en les signant par exemple. Cette méthode est utilisée entre autres par le protocole Photuris. L'inconvénient, dans les deux cas, est que l'on perd un gros avantage de Diffie-Hellman, qui est la possibilité de générer un secret partagé sans aucune information préalable sur l'interlocuteur. Mais, si les valeurs publiques sont de courtes durée, Diffie-Hellman authentifié fournit la propriété de perfect formard secrecy. 3.2. Les protocoles d'authentification mutuelle avec échange de clef développés pour IP Il existe de nombreux protocoles d'authentification mutuelle avec échange de clef, qui se différencient suivant les prérequis qu'ils imposent (secret partagé préalable, infrastructure à clef publique...) et les propriétés qu'ils vérifient (direct authentication, perfect forward secrecy...). Dans le cadre des protocoles d'échange de clef développés pour la sécurisation des échanges sous IP, une distinction supplémentaire s'impose entre les protocoles orientés connexion et ceux sans connexion. Dans le premier cas, on a recours à un protocole d'établissement de clef de session authentifiée, hors bande, avant la communication. La clef résultante est ensuite utilisée pour sécuriser le trafic IP. L'inconvénient de cette approche est qu'elle nécessite l'établissement et la gestion d'une pseudo couche session sous IP, alors qu'IP est un protocole sans connexion. Dans le second cas, on a recours à une gestion des clefs sans état (stateless), qui ne nécessite donc pas de connexion. Ceci est réalisable à travers un système en bande, où la clef ayant servi à chiffrer le paquet est transmise avec celui-ci, chiffrée avec la clef publique du destinataire par exemple. L'inconvénient de ce système est qu'il ajoute des données à chaque paquet transmis. D'autre part, Diffie-Hellman est très utilisé dans tous les protocoles présentés ici, les différences venant de la durée de vie des valeurs publiques utilisées et de la façon dont elles sont authentifiées et échangées. 3.2.1. SKIP SKIP (Simple Key management for Internet Protocols) est un exemple de protocole qui ne se base pas sur l'établissement d'une "connexion". En effet, aucun échange préalable de messages n'est nécessaire avant de pouvoir envoyer un paquet chiffré et chaque paquet transporte l'information qui permettra de le déchiffrer. Au niveau des couches réseau, cela se traduit par le fait que SKIP se situe au niveau IP, et non au-dessus de TCP ou UDP comme la plupart des protocoles de gestion de clefs. D'autre part, SKIP se base sur une génération de secret partagé Diffie-Hellman avec valeurs publiques authentifiées, donc le seul prérequis est que chaque participant doit être en possession d'une valeur publique Diffie-Hellman authentifiée. Historique SKIP a été créé en 1994 par Ashar Aziz et Whitfield Diffie de Sun Microsystems. Un brevet fut déposé par Sun Microsystems en juin 1994 puis placé dans le domaine public peu de temps après. SKIP fut proposé comme protocole de gestion des clefs standard pour IPsec, et un certain nombre d'Internet drafts furent publiés dans ce sens jusqu'en août 1996. À cette époque, les deux standards possibles pour la gestion des clefs avec IPsec étaient SKIP et ISAKMP/Oakley. Un choix s'imposait, et la question fut tranchée en faveur de ISAKMP/Oakley en septembre 1996. Si ISAKMP/Oakley a été choisi pour être le protocole imposé dans toute implémentation, l'utilisation de SKIP n'est pas exclue. Cependant, la publication d'Internet drafts à son sujet a cessé depuis cette date. Sun Microsystems continue à développer ce protocole et à l'intégrer dans un certain nombre de produits, notamment SunScreen SKIP. SKIP est également utilisable pour la gestion des clefs IPsec dans le produit Firewall-1 de Check Point. Principe SKIP est basé sur le principe de génération de secret partagé Diffie-Hellman, avec authentification pour éviter une possible attaque de l'intercepteur. Les deux tiers possédant chacun une valeur publique Diffie-Hellman authentifiée, ils peuvent, à partir de la connaissance de la valeur publique de l'interlocuteur et de leur propre valeur privée, générer un secret partagé. Pour implémenter SKIP, chaque tiers doit donc posséder une valeur publique Diffie-Hellman authentifiée. Cette authentification peut être obtenue de différentes façons : certificat X.509, DNS sécurisé, clef PGP signée... D'autre part, pour communiquer avec un interlocuteur choisi, un tiers doit obtenir sa valeur publique. Une façon de réaliser cela est de distribuer les valeurs publiques à l'aide d'un "service d'annuaire" (directory service) ou à l'aide du "protocole de découverte de certificats" (Certificate Discovery Protocol, CDP). Soient I et J les deux tiers. Les valeurs privées sont respectivement i et j et les valeurs publiques gi mod p et gj mod p. Chaque tiers obtient le secret partagé en élevant la valeur publique de son interlocuteur à la puissance sa valeur privée : (gj mod p)i = (gi mod p)j. gij mod p est appelé secret partagé à long terme et sert à dériver une clef secrète Kij. En effet, gij mod p sera typiquement de longueur 1024 bits ou plus, alors que Kij est une clef secrète de longueur 40 à 256 bits typiquement. Dans SKIP, Kij est constituée des bits de poids faible de gij mod p. Voilà pour la partie échange de clef proprement dite. SKIP va plus loin en précisant comment cette clef est ensuite utilisée pour protéger les échanges entre I et J. Kij est en fait une clef de chiffrement de clef, c'est-à-dire qu'elle est utilisée exclusivement pour chiffrer des clefs de durée de vie beaucoup plus faible. En effet, Kij est utilisée pour chiffrer une clef Kp, appelée clef de paquet, qui est elle-même utilisée pour générer deux clefs, servant respectivement au chiffrement et à l'authentification d'un paquet IP ou d'un ensemble réduit de paquets. Le mode de fonctionnement de SKIP, s'il ne requiert pas d'échange préalable à l'envoi de paquet chiffré, implique en revanche une augmentation de la taille de chaque paquet. En effet, un en-tête supplémentaire, dit en-tête SKIP, est adjoint au datagramme IP ; il sert notamment à transmettre la clef Kp (chiffrée avec Kij) et à indiquer les algorithmes utilisés. Extension pour la propriété de perfect forward secrecy Le fonctionnement exposé ci-dessus présente le défaut de ne pas fournir la propriété de perfect forward secrecy. En effet, si Kij est découverte, l'ensemble des clefs de session Kp utilisées par le passé sont compromises. Une extension de SKIP garantissant cette sécurité supplémentaire a donc été développée. Elle se présente sous la forme d'une génération de clefs Diffie-Hellman dite éphémère, car reposant sur des valeurs publiques à court terme. Le secret partagé ainsi généré remplace le secret partagé à long terme de la version classique de SKIP. L'utilisation d'une génération de clefs Diffie-Hellman éphémère implique l'échange de certificats contenant les valeurs publiques correspondantes. Cet échange se fait à l'aide du protocole CDP (Certificate Discovery Protocol) et utilise la clef Kij. Contrairement à la version de base de SKIP, l'extension SKIP PFS requiert donc un échange de données entre les tiers avant de leur permettre de communiquer. SKIP PFS fournit également la protection des identités, ce que ne garantissait pas SKIP. 3.2.2. Photuris Contexte Développé depuis 1995 par Phil Karn de chez Qualcomm et William Simpson de chez DayDreamer, Photuris utilise le même principe que le protocole STS (Station-To-Station) créé par Diffie, Van Oorschot et Wiener [DOW92]. Il a fait l'objet d'Internet drafts et de RFC indépendants de tout groupe de travail, et est utilisable avec IPsec. Quelques implémentations l'utilisent d'ailleurs actuellement, même si IKE est bien plus répandu. Contrairement à SKIP, Photuris est un protocole "orienté connexion" au sens où il comporte un certain nombre d'échanges (pour la négociation d'options et la génération de clef) préalables à tout échange de messages chiffrés. Photuris s'est vu attribué le port UDP 468 par l'IANA. Principe Photuris est basé sur la génération d'un secret partagé selon le principe de Diffie-Hellman. Ce secret partagé a une durée de vie faible : il sert à générer les clefs de session nécessaires pour protéger la suite des échanges. Afin de contrer l'attaque de l'intercepteur à laquelle est vulnérable Diffie-Hellman, l'échange des valeurs servant à générer le secret partagé est suivi d'une authentification de ces valeurs à l'aide des secrets à long terme. Ces secrets servant uniquement à l'authentification, Photuris fournit la propriété de perfect forward secrecy. Un problème de Diffie-Hellman est que ce protocole requiert des opérations coûteuses en ressources système, ce qui le rend vulnérable à des attaques en déni de service appelées "attaques par inondation" (flooding attacks). Afin de rendre de telles attaques plus difficiles, Photuris a recours à un échange de cookies avant de procéder à l'échange de valeurs Diffie-Hellman. La valeur du cookie dépend des tiers en présence, en particulier par l'intermédiaire de l'adresse IP et du port UDP, ceci afin d'empêcher un attaquant d'obtenir un cookie valable puis de l'utiliser pour inonder la victime de requêtes provenant d'adresses IP et/ou de ports arbitraires. D'autre part, il ne doit pas être possible, pour un attaquant, de générer des cookies qui seront acceptés par une entité comme générés par ellemême. Ceci implique que l'entité émettrice utilise une information locale secrète dans la génération de ses cookies et dans leur vérification ultérieure. Le protocole Photuris est composé des trois étapes suivantes : 1. Un échange de cookies permet de contrer certaines attaques simples en déni de service. Chaque tiers en présence génère un cookie, et les cookies sont répétés dans chaque message transmis. 2. Un échange de valeurs publiques pour la génération d'un secret partagé. 3. Un échange d'identités afin que les tiers s'identifient l'un l'autre et vérifient l'authenticité des valeurs échangées durant la phase précédente. Cet échange est protégé en confidentialité grâce à des clefs privées dérivées du secret partagé et des cookies entre autres. D'autres messages peuvent être échangés ultérieurement pour changer les clefs de session ou les paramètres de sécurité. Ces messages seront protégés en confidentialité de la même façon que les messages de l'échange 3. En parallèle aux échanges exposés ci-dessus, les tiers communicants se mettent d'accord sur la méthode de génération du secret partagé, puis sur un certain nombre de paramètres de sécurité utiles à l'association de sécurité mise en place. 3.2.3. SKEME Contexte Développé spécifiquement pour IPsec, SKEME est une extension de Photuris proposée en 1996 par Hugo Krawczyk de l'IBM T. J. Watson Research Center. Contrairement à Photuris, qui impose un déroulement précis du protocole, SKEME fournit divers modes d'échange de clef possibles. Principe De la même façon que les protocoles STS et Photuris, le mode de base de SKEME repose sur l'utilisation de clefs publiques et sur une génération de secret partagé Diffie-Hellman. SKEME n'est cependant pas restreint à l'utilisation de clefs publiques, mais permet également l'utilisation d'une clef précédemment partagée. Cette clef peut avoir été obtenue par distribution manuelle ou par l'intermédiaire d'un centre de distribution de clef (Key Distribution Center, KDC), comme pour Kerberos. Le KDC permet aux entités communicantes de partager un secret par l'intermédiaire d'un tiers de confiance. L'utilisation de ce secret pour l'authentification du secret Diffie-Hellman et non directement en tant que clef de session diminue la confiance requise en le KDC. Enfin, SKEME permet également d'effectuer des échanges plus rapides en omettant d'utiliser Diffie-Hellman lorsque la propriété de perfect forward secrecy n'est pas requise. En résumé, SKEME comporte quatre modes distincts : Le mode de base, qui fournit un échange de clef basé sur des clefs publiques et présentant la propriété de PFS grâce à Diffie-Hellman. Un échange de clef basé sur l'utilisation de clefs publiques, mais sans Diffie-Hellman. Un échange de clef basé sur l'utilisation d'une clef partagée précédemment et sur DiffieHellman. Un mécanisme de changement de clef rapide basé uniquement sur des algorithmes symétriques. D'autre part, SKEME se décompose en trois phases : SHARE, EXCH et AUTH. Durant la phase de partage (SHARE), les tiers échangent des demi-clefs, chiffrées avec la clef publique l'un de l'autre. Ces deux demi-clefs permettent de générer une clef secrète K. Si l'on désire protéger l'anonymat des tiers en présence, leur identité est également chiffrée. Dans le cas où l'on possède déjà un secret partagé, cette phase est sautée. La phase d'échange (EXCH) est utilisée, suivant le mode choisi, pour échanger des valeurs publiques Diffie-Hellman ou des nombres aléatoires. Le secret partagé Diffie-Hellman ne sera calculé qu'après la fin des échanges. Les valeurs publiques ou nombres aléatoires précédents sont authentifiées pendant la phase d'authentification (AUTH), à l'aide de la clef secrète établie durant la phase SHARE. Il va de soi que les messages correspondant à ces trois phases ne se suivent pas nécessairement de la façon décrite ci-dessus, mais sont en pratique combiné pour minimiser le nombre de messages à échanger. Une autre phase, dite phase COOKIES, peut être ajoutée avant la phase SHARE afin de protéger contre les attaques en déni de service en ayant recours au mécanisme des cookies introduit par Photuris. 3.2.4. Oakley Initialement proposé par Hilarie Orman du département informatique de l'université d'Arizona, Oakley a fait l'objet d'une RFC dans le cadre du groupe IPsec et est, avec ISAKMP et SKEME, à la base de l'échange de clef pour IPsec. Oakley est un protocole d'échange de clef qui ressemble beaucoup à SKEME, en ce sens qu'il possède également plusieurs modes, a recours aux cookies et ne nécessite pas le calcul du secret partagé Diffie-Hellman avant la fin du protocole. Il se distingue des protocoles présentés jusqu'à présent par le fait qu'il permet explicitement aux tiers en présence de se mettre d'accord sur les mécanismes d'échange de clef, de chiffrement et d'authentification utilisés. De fait, le but d'Oakley est de permettre le partage, de façon sûre entre les tiers, d'un ensemble d'informations relatives au chiffrement : nom de la clef, clef secrète, identités des tiers, algorithmes de chiffrement, d'authentification et fonction de hachage. Plusieurs options sont disponibles dans Oakley. En plus du classique Diffie-Hellman, Oakley peut être utilisé pour dériver une nouvelle clef d'une clef ancienne ou pour distribuer une clef en la chiffrant. Ces options se traduisent par l'existence de plusieurs modes. Le principe général d'Oakley est que l'initiateur de l'échange commence par spécifier autant d'information qu'il le désire dans un premier message. Son interlocuteur lui répond en fournissant également autant d'information qu'il le désire. La conversation se poursuit jusqu'à ce que l'état recherché soit atteint. Le choix de la quantité d'information à inclure dans chaque message dépend des options sélectionnées (utilisation de cookies sans état, protection de l'identité, PFS, non-répudiation...). Les trois composants du protocole sont : 1. échange de cookies (éventuellement sans état), 2. échange de valeurs publiques Diffie-Hellman (optionnel), 3. authentification (options : anonymat, PFS sur les identités, non-répudiation). 3.3. La gestion des clefs pour IPsec : ISAKMP et IKE IKE (Internet Key Exchange) est un système développé spécifiquement pour IPsec qui vise à fournir des mécanismes d'authentification et d'échange de clef adaptés à l'ensemble des situations qui peuvent se présenter sur l'Internet. Il est composé de plusieurs éléments : le cadre générique ISAKMP et une partie des protocoles Oakley et SKEME. Lorsqu'il est utilisé pour IPsec, IKE est de plus complété par un "domaine d'interprétation" pour IPsec. 3.3.1. ISAKMP Nous avons vu au début de cette présentation que l'apport de services de sécurité passait par l'utilisation d'associations de sécurité qui permettent de définir les paramètres (clefs, protocoles...) nécessaires à la sécurisation d'un flux donné. ISAKMP (Internet Security Association and Key Management Protocol) a pour rôle la négociation, l'établissement, la modification et la suppression des associations de sécurité et de leurs attributs. Indépendance vis à vis des mécanismes : les domaines d'interprétation et les phases ISAKMP est un cadre générique indépendant des mécanismes en faveur desquels la négociation a lieu. En effet, ISAKMP est a priori utilisable pour négocier, sous forme d'associations de sécurité, les paramètres relatifs à n'importe quels mécanismes de sécurité : IPsec, TLS... Il est en effet prévu pour supporter la négociation de SA pour n'importe quel protocole de niveau supérieur ou égal à IP. Ceci est possible grâce à la façon dont les négociations ont lieu. Tout d'abord, ISAKMP est prévu pour fonctionner indépendamment des mécanismes pour lesquels il travaille : les données relatives à la gestion des clefs seront transportées à part. ISAKMP peut être implémenté directement au-dessus d'IP, ou au-dessus de tout protocole de la couche transport. Il s'est notamment vu attribuer le port 500 sur UDP par l'IANA. Ensuite, ISAKMP définit un cadre pour négocier les associations de sécurité, mais n'impose rien quant aux paramètres qui les composent. Un document appelé "domaine d'interprétation" (Domain of Interpretation, DOI) doit définir les paramètres négociés et les conventions relatives à l'utilisation de ISAKMP dans un cadre précis. Un identificateur de DOI est utilisé pour interpréter le contenu des messages ISAKMP. La [RFC 2407] définit le DOI pour l'utilisation de ISAKMP avec IPsec. Nous reviendrons sur ce document dans le chapitre suivant. Enfin, ISAKMP comporte deux phases, qui permettent une séparation nette de la négociation des SA pour un protocole donné et de la protection du trafic propre à ISAKMP : Durant la première phase, un ensemble d'attributs relatifs à la sécurité est négocié, les identités des tiers sont authentifiées et des clefs sont générées. Ces éléments constituent une première "association de sécurité", dite SA ISAKMP. Contrairement aux SA IPsec, la SA ISAKMP est bidirectionnelle. Elle servira à sécuriser l'ensemble des échanges ISAKMP futurs. La seconde phase permet de négocier les paramètres de sécurité relatifs à une SA à établir pour le compte d'un mécanisme de sécurité donné (par exemple AH ou ESP). Les échanges de cette phase sont sécurisés (confidentialité, authenticité...) grâce à la SA ISAKMP. Celle-ci peut bien sûr être utilisée pour négocier plusieurs SA destinées à d'autres mécanismes de sécurité. Les paramètres de la SA ISAKMP peuvent être propres à ISAKMP seulement, ou comporter également des éléments propres à un protocole de sécurité donné et définis dans le DOI correspondant. Dans le premier cas, on parlera de Generic ISAKMP SA, et celle-ci pourra servir pour la négociation de SA pour n'importe quel protocole de sécurité. Dans le second cas, la SA ISAKMP ne pourra être utilisée que pour négocier une SA dépendant du même DOI. Indépendance vis à vis du protocole de gestion des clefs : la construction des messages par blocs ISAKMP est également indépendant de la méthode de génération des clefs et des algorithmes de chiffrement et d'authentification utilisés. Il est donc indépendant de tout protocole d'échange de clef, ce qui permet de séparer clairement les détails de la gestion des associations de sécurité des détails de l'échange de clef. Différents protocoles d'échange de clef, présentant des propriétés différentes sont ainsi utilisables avec ISAKMP. Ceci est possible à cause du fait que ISAKMP n'impose pas un déroulement fixe, basé sur la définition d'un ensemble de messages limité. ISAKMP est plutôt une sorte de "kit de construction", puisque les messages d'ISAKMP sont constitués d'un en-tête suivi d'un nombre variable de blocs. Ces blocs ( payloads en anglais) sont les briques de base d'ISAKMP. Chaque message ISAKMP commence par un en-tête (ISAKMP Header) de longueur fixe. Celui-ci comprend notamment deux cookies, l'initiator cookie et le responder cookie, qui, en plus du rôle classique de protection contre le déni de service (anti-clogging), permettent d'identifier l'association de sécurité ISAKMP en cours (contrairement aux autres SA, elle n'est pas identifiée pas un SPI). Un champ Exchange Type permet de connaître le type d'échange en cours (voir plus loin) et donc de connaître l'organisation et le nombre des messages. L'en-tête ISAKMP comprend également un champ, Next Payload, qui indique le type du premier bloc du message. Chaque bloc commence à son tour par un en-tête propre, qui indique la longueur du bloc courant et le type du bloc suivant. Le dernier bloc du message indique 0 comme type de bloc suivant. La construction des messages ISAKMP repose donc sur le chaînage de blocs. Le document de base sur ISAKMP définit 13 types de blocs différents : Nom Sigle Security Association SA Proposal P Transform T Key Exchange KE Identification ID Certificate CERT Certificate Request CR Hash HASH Signature SIG Nonce NONCE Notification N Delete D Vendor ID VID Le bloc Security Association (SA) est utilisé pour négocier les attributs de sécurité. En lui-même, il contient des champs qui indiquent le contexte de la négociation (DOI et situation). La situation est un paramètre qui dépend du DOI et qui permet d'indiquer quel type de politique de sécurité on désire utiliser. Une valeur de 0 pour le DOI pendant la phase 1 indique que l'on négocie une SA ISAKMP générique. Une valeur de 1 indique le DOI IPsec. Un bloc SA est toujours suivi d'un ou plusieurs blocs Proposal, qui permettent de faire des propositions (présentées par ordre de préférence) à l'interlocuteur. Chaque bloc Proposal constitue une proposition d'un ensemble d'attributs relatifs à une association de sécurité. En lui-même, le bloc Proposal indique le mécanisme de sécurité que l'on désire utiliser (AH, ESP...) ainsi que le SPI à associer à la SA si cette proposition est retenue. Comme il est possible de laisser le choix à l'interlocuteur en lui faisant plusieurs propositions, chaque bloc Proposal est numéroté. Lorsque plusieurs propositions constituent un tout (par exemple si l'on veut négocier une protection par AH + ESP), elles portent le même numéro et résulteront en la création d'un paquet de SA. Un bloc P est toujours suivi d'un ou plusieurs blocs Transform, qui permettent de préciser les attributs choisis pour la SA en question. Chaque bloc Transform indique une transformation (algorithme de chiffrement, fonction de hachage...) et ses attributs. Ces éléments dépendent bien sûr du DOI et du mécanisme de sécurité sélectionné dans les blocs précédents. Comme pour les blocs Proposal, les blocs Transform sont numérotés : si deux blocs portent le même numéro, ils forment un tout et doivent être sélectionnés ensemble ; des blocs de numéros différents indiquent une possibilité de choix. Ces trois premiers types de blocs ne sont pas indépendants et on peut considérer qu'ils sont emboîtés. On désigne donc souvent par le bloc SA seul l'ensemble des blocs SA, P et T. - Figure 10. Organisation des blocs SA, P et T ? L'ensemble représenté dans le schéma ci-dessus pourrait être un ensemble de propositions envoyé par un tiers à un autre. Le destinataire de ce message doit répondre par une suite identique dans laquelle il ne conserve que la proposition (ou le groupe de propositions) retenue. L'association de sécurité (ou le paquet d'associations de sécurité) résultant de cette négociation se verra attribué le SPI de la proposition retenue. Le bloc Key Exchange sert à transporter les données nécessaires à la génération de la clef de session. Son interprétation dépend du DOI et du protocole d'échange de clefs choisi. Le bloc Identification sert à transporter les données nécessaires à l'identification des tiers. Son interprétation dépend du DOI. Un champ intitulé ID Type indique le type de donnée d'identification contenu dans le bloc. Pour ISAKMP ce sont une adresse IP (IPv4 ou IPv6) ou une plage d'adresses IP (adresse / masque de sous-réseau). Chaque DOI peut définir différents types d'identification. Le bloc Certificate fournit un moyen de transporter des certificats ou toute autre information en relation avec les certificats. Un champ intitulé Certificate Encoding indique le type de certificat ou de donnée relative aux certificats contenue dans le champ Certificate Data. Les types définis actuellement sont : o PKCS #7 wrapped X.509 certificate o PGP certificate o DNS signed key o X.509 certificate ? signature o X.509 certificate ? key exchange o Kerberos tokens o Certificate revocation list (CRL) o Authority revocation list (ARL) o SPKI certificate o X.509 certificate ? attribute Le bloc Certificate Request permet à un tiers de réclamer un certificat à son interlocuteur. Comme dans le bloc précédent, un champ indique le type de certificat requis. Un second champ, intitulé Certificate Authority, contient les références d'une autorité de certification acceptable par le demandeur. Ce champ est facultatif. Le bloc Hash contient le résultat de l'application d'une fonction de hachage sélectionnée au préalable à tout ou partie du message ou à une variable d'état donnée. Ce bloc peut être utilisé à des fins de vérification de l'authenticité d'un message ISAKMP. De même, le bloc Signature contient le résultat de l'application d'une fonction de signature numérique sélectionnée au préalable à tout ou partie du message ou à une variable d'état donnée. L'utilisation est la même que pour le bloc Hash. Le bloc Nonce sert à transporter des aléas. Le bloc Notification sert à véhiculer des messages d'erreur ou d'information sur l'état actuel des négociations. Son interprétation dépendant du DOI, celui-ci est indiqué au début du bloc. Le début du bloc contient également les références de l'association de sécurité concernée (mécanisme et SPI). Le message est représenté par deux champs : Notify Message Type et Notification Data (facultatif). Le bloc Delete permet à l'émetteur de signaler à son interlocuteur qu'il vient de supprimer une association de sécurité et que celle-ci n'est donc plus valable. Un seul bloc permet éventuellement d'indiquer plusieurs SA, à conditions qu'elles soient toutes relatives au même mécanisme. Dans ISAKMP, la modification des SA se fait en créant une nouvelle SA puis en supprimant l'ancienne. Le bloc Vendor ID peut être utilisé par un programmeur pour permettre à deux instances de son implémentation de se reconnaître et de pouvoir ensuite utiliser des éléments propres à cette implémentation. Interopérabilité et ligne directrice : les types d'échanges À partir de ces blocs, ISAKMP définit des types d'échanges (exchange types). Un type d'échange est une spécification de l'ensemble des messages constituant un type d'échange donné (nombre, contenu...). Chaque type d'échange est conçu pour fournir un certain nombre de services de sécurité spécifiques, comme l'anonymat, la propriété de perfect forward secrecy, l'authentification mutuelle... Le document de base sur ISAKMP, [RFC 2408], définit, à des fins d'interopérabilité et surtout pour indiquer comment doivent être utilisés les blocs dans le cadre d'une négociation donnée, des types d'échanges par défaut. D'autres types peuvent bien sûr être définis, en fonction du protocole d'échange de clef utilisé et du DOI notamment. D'autre part, plusieurs propositions de types d'échanges supplémentaires pour ISAKMP font l'objet d'Internet Drafts séparés. La spécification actuelle de ISAKMP comporte cinq types d'échanges par défaut : Base Exchange, Identity Protection Exchange, Authentication-Only Exchange, Aggressive Exchange, Informational Exchange. Seul ce dernier est obligatoire. Tous ces échanges peuvent être utilisés soit durant la phase 1, soit durant la phase 2. Dans les descriptions qui vont suivre, on utilisera les notations suivantes : HDR ISAKMP Header SA Security Association Payload KE Key Exchange Payload ID Identity Payload AUTH Authentication Payload (HASH ou SIG) NONCE Nonce Payload * Signifie que le message est chiffré - Figure 11. Notations pour les échanges ISAKMP L'échange de base (Base Exchange) est conçu pour permettre le transfert simultané des données d'identification et des données servant à la génération de la clef, ce qui permet de réduire le nombre total de messages nécessaires, au détriment de la protection de l'anonymat des tiers en présence. En effet ; les identités sont échangées avant qu'un secret partagé ne soit établi et ne permette de les chiffrer. Les données échangées au cours des messages 3 et 4 sont protégées, par le biais du bloc AUTH, par la fonction d'authentification sélectionnée au cours de la négociation des messages 1 et 2. L'échange de protection d'identité (Identity Protection Exchange), quant-à-lui, repousse l'envoi des données d'identification à après l'échange des données permettant la génération du secret partagé, assurant ainsi l'anonymat des tiers. L'échange d'authentification seule (Authentication Only Exchange) est conçu pour aboutir uniquement à l'authentification des tiers, évitant ainsi le temps de calcul engendré par la génération de clef lorsque celle-ci n'est pas nécessaire. Cet échange est particulièrement utile durant la seconde phase, où il sera protégé par les services de sécurité négociés au cours de la première phase. L'échange agressif (Aggressive Exchange) combine les données de négociation de la SA, d'authentification et d'échange de clef en un seul message afin de réduire au maximum le nombre de messages nécessaires. Tout comme pour l'échange de base, l'anonymat des tiers n'est donc pas préservé. De plus, seule une proposition et une transformation (i.e. aucun choix possible) peuvent être offertes dans la négociation de l'association de sécurité pour que l'échange agressif puisse fonctionner. L'échange d'information (Informational Exchange) est constitué d'un seul message et sert à transmettre une information relative à la gestion des SA : message d'erreur, information d'état, annonce de suppression de SA... Il utilise soit un bloc Notification, soit un bloc Delete. Ce message est protégé par la SA ISAKMP si celle-ci a déjà été établie, sinon il n'est pas protégé. 3.3.2. IPsec DOI ISAKMP définit un cadre pour négocier les associations de sécurité, mais n'impose rien quant aux paramètres qui les composent. Un document appelé "domaine d'interprétation" (Domain of Interpretation, DOI) définit les paramètres négociés et les conventions relatives à l'utilisation de ISAKMP dans un cadre précis. Un identificateur de DOI est utilisé pour interpréter le contenu des messages ISAKMP. La [RFC 2407] définit le DOI pour l'utilisation de ISAKMP avec IPsec. Bloc SA : situation Utilisé dans le bloc SA de ISAKMP, le champ situation permet de préciser la situation à laquelle doit être rattachée la négociation. Le DOI IPsec définit trois situations différentes : Identity only, qui impose une identification des tiers par le biais d'un bloc ID. Secrecy, qui permet l'utilisation d'indicateurs de niveaux de confidentialité. Integrity, qui permet l'utilisation d'indicateurs ne niveaux pour l'intégrité. Le DOI IPsec définit également des champs supplémentaires dans le bloc SA pour transporter les données relatives à la situation : niveau de confidentialité, niveau d'intégrité... Bloc P : protocole de sécurité Les protocoles (ou mécanismes) qui entrent dans le cadre du DOI IPsec sont : ISAKMP (pour une négociation de phase 1 avec le DOI IPsec au lieu de Generic ISAKMP) AH ESP IPCOMP IPCOMP est un protocole de compression des données au niveau IP. Le chiffrement des données rendant inefficace toute compression ultérieure, il peut être intéressant de compresser les données avant de les chiffrer. Bloc T : transformation et attributs À chacun des quatre protocoles mentionnés ci-dessus sont associées des transformations permettant de faire des choix par le biais de blocs Transform. Pour ISAKMP, cette méthode permet de choisir le protocole d'échange de clef à utiliser. Le seul choix possible dans le cadre de IPsec est IKE. Les transformations relatives à AH sont MD5, SHA et DES. Cette information est à compléter, par le biais du champ SA Attributes du bloc Transform, par la référence de l'algorithme à utiliser. D'où en fait quatre possibilités : HMAC-MD5, KPDK-MD5, HMAC-SHA, DES-MAC. Les transformations relatives à ESP sont DES_IV32, DES_IV64 (DES en mode CBC avec un vecteur d'initialisation de longueur 32 ou 64 respectivement), DES (DES en mode CBC, demande une précision par le biais d'attributs), 3DES (demande une précision par le biais d'attributs), RC5, IDEA, CAST, BLOWFISH, 3IDEA, RC4 et NULL (permet d'utiliser ESP sans chiffrement des données). Enfin, les transformations utilisables avec IPCOMP sont OUI (transformation propriétaire, à préciser par le biais d'un attribut), DEFLATE, LZS et V42BIS. En plus des attributs mentionnés ci-dessus, il est possible d'avoir recours à divers attributs pour préciser le groupe sur lequel effectuer les calculs relatifs à Diffie-Hellman, la durée de vie de la SA, la longueur de la clef pour les algorithmes à clef de longueur variable... Ces éléments sont décrits en détail dans [RFC 2407]. Bloc ID Le DOI IPsec ajoute au bloc ID les champs Protocol ID (UDP, TCP...) et Port, et définit les modes d'identification suivants : Adresse IPv4, adresse IPv6 Sous réseau IPv4 ou IPv6 (adresse / masque de sous-réseau) Plage d'adresses IPv4 ou IPv6 (adresse de début, adresse de fin) FQDN (foo.bar.com) User FQDN ([email protected]) Binary DER encoding of an ASN.1 X.500 Distinguished Name [X.501] binary DER encoding of an ASN.1 X.500 General Name [X.509] KEY ID : information propre à un fournisseur et permettant d'identifier le secret partagé préalable à utiliser Bloc N 3 nouveaux messages de statut sont introduits : RESPONDER-LIFETIME REPLAY-STATUS INITIAL-CONTACT 3.3.3. IKE Si le DOI IPsec précise la contenu des blocs ISAKMP dans le cadre de IPsec, IKE en revanche utilise ISAKMP, pour construire un protocole pratique. Le protocole de gestion des clefs associé à ISAKMP dans ce but est inspiré à la fois d'Oakley et de SKEME. Plus exactement, IKE utilise certains des modes définis par Oakley et emprunte à SKEME son utilisation du chiffrement à clef publique pour l'authentification et sa méthode de changement de clef rapide par échange d'aléas. D'autre part, IKE ne dépend pas d'un DOI particulier mais peut utiliser tout DOI. IKE comprend quatre modes : le mode principal (Main Mode), le mode agressif (Aggressive Mode), le mode rapide (Quick Mode) et le mode nouveau groupe (New Group Mode). Main Mode et Aggressive Mode sont utilisés durant la phase 1, Quick Mode est un échange de phase 2. New Group Mode est un peu à part : ce n'est ni un échange de phase 1, ni un échange de phase 2, mais il ne peut avoir lieu qu'une fois une SA ISAKMP établie ; il sert à se mettre d'accord sur un nouveau groupe pour de futurs échanges Diffie-Hellman. Phase 1 : Main Mode et Aggressive Mode Les attributs suivants sont utilisés par IKE et négociés durant la phase 1 : un algorithme de chiffrement, une fonction de hachage, une méthode d'authentification et un groupe pour Diffie-Hellman. Trois clefs sont générées à l'issue de la phase 1 : une pour le chiffrement, une pour l'authentification et une pour la dérivation d'autres clefs. Ces clefs dépendent des cookies, des aléas échangés et des valeurs publiques Diffie-Hellman ou du secret partagé préalable. Leur calcul fait intervenir la fonction de hachage choisie pour la SA ISAKMP et dépend du mode d'authentification choisi. Pour connaître les formules exactes, référez-vous à [RFC 2409]. Composé de siw messages, Main Mode est une instance de l'échange ISAKMP Identity Protection Exchange : Les deux premiers messages servent à négocier les paramètres IKE : algorithme de chiffrement, fonction de hachage, méthode d'authentification des tiers et groupe pour DiffieHellman. - Figure 12. Main Mode : exemple de premier échange Les quatre méthodes d'authentification possibles sont la signature numérique, deux formes d'authentification par chiffrement à clef publique et l'utilisation d'un secret partagé préalable. Les deux seconds messages permettent l'établissement d'un secret partagé via l'utilisation de à l'échange de valeurs publiques Diffie-Hellman. - Figure 13. Main Mode : second échange Le secret partagé sert à dériver des clefs de session, deux d'entre elles étant utilisées pour protéger la suite des échanges avec les algorithmes de chiffrement et de hachage négociés précédemment. Les deux derniers messages servent à l'authentification de des valeurs publiques. - Figure 14. Main Mode : troisième et dernier échange Aggressive Mode est une instance de l'échange ISAKMP Aggressive Exchange : il combine les échanges décrits ci-dessus pour Main Mode de façon à ramener le nombre total de messages à trois. Dans ces deux cas, la méthode choisie pour l'authentification influence le contenu des messages et la méthode de génération de la clef de session. Les quatre méthodes d'authentification possibles sont la signature numérique, deux formes d'authentification par chiffrement à clef publique et l'utilisation d'un secret partagé préalable. La [RFC 2408] détaille les messages échangés dans chaque cas et les formules de calcul des signatures et empreintes. Phase 2 : Quick Mode Les messages échangés durant la phase 2 sont protégés en authenticité et en confidentialité grâce aux éléments négociés durant la phase 1. L'authenticité des messages est assurée par l'ajout d'un bloc HASH après l'en-tête ISAKMP, et la confidentialité est assurée par le chiffrement de l'ensemble des blocs du message. Quick Mode est utilisé pour la négociation de SA pour des protocoles de sécurité donnés comme IPsec. Chaque négociation aboutit en fait à deux SA, une dans chaque sens de la communication. Plus précisément, les échanges composant ce mode ont le rôle suivant : Négocier un ensemble de paramètres IPsec (paquets de SA) Échanger des nombres aléatoires, utilisés pour générer une nouvelle clef qui dérive de celle de la SA ISAKMP. De façon optionnelle, il est possible d'avoir recours à un nouvel échange Diffie-Hellman, afin d'accéder à la propriété de Perfect Forward Secrecy, qui n'est pas fournie si on se contente de générer une nouvelle clef à partir de l'ancienne et des aléas. Optionnellement, identifier le trafic que ce paquet de SA protégera, au moyen de sélecteurs (blocs optionnels IDi et IDr ; en leur absence, les adresses IP des interlocuteurs sont utilisées) Les échanges composant ce mode sont les suivants : Ou, en terme de composition des messages par blocs : Les groupes : New Group Mode Le groupe à utiliser pour Diffie-Hellman peut être négocié, par le biais du bloc SA, soit au cours du Main Mode, soit ultérieurement par le biais du New Group Mode. Dans les deux cas, il existe deux façons de désigner le groupe à utiliser : Donner la référence d'un groupe prédéfini : il en existe actuellement quatre, les quatre groupes Oakley (deux groupes MODP et deux groupes EC2N). Donner les caractéristiques du groupe souhaité : type de groupe (MODP, ECP, EC2N), nombre premier ou polynôme irréductible, générateurs... Phases et modes Au final, le déroulement d'une négociation IKE suit le diagramme suivant : Onduleurs RAID SSL Introduction Aujourd'hui la solution la plus répandue pour sécuriser les transactions est SSL (Secure Socket Layer, créé par Netscape). Son succès s'explique par sa simplicité d'utilisation et par son intégration dans tous les navigateurs du marché : vous remarquerez en bas à gauche de votre navigateur Netscape une petite clé, qui devient automatiquement entière si le serveur qui vous envoit les informations utilise SSL. SSL (Secure Socket Layer) est un protocole de communication d'information qui permet d'assurer l'authentification, la confidentialité et l'intégrité des données échangées. Ce protocole utilise un moyen de cryptographie reconnu : l'algorithme à clé publique RSA (du nom de ses concepteurs - Rivest - Shamir - Adleman - ). Une clé RSA est le résultat d'opérations entre nombres premiers. Le but recherché par les entreprises commerciales est un moyen permettant une communication sûre avec leurs clients, et plus précisément, une façon sûre d'obtenir le paiement des biens/services vendus. Dans un tel cadre commercial, les données qui sont primordiales de protéger lors de la transmission sont constituées des informations concernant la carte de crédit du client (généralement). Dans le cas de vente de contenu électronique ou de service électronique il faut également protéger la transmission de ces données. La libre circulation non-protégée de ces données grugerait une partie des ventes des marchands. Les transactions commerciales qui s'effectuent sur Internet sont généralement ponctuelles. C'est-à-dire qu'elle ne sont ni régulières, ni périodiques. Un système de cryptographie permettant d'assurer ce type de communication doit tenir compte de ces éléments. Le browser Navigator de la compagnie Netscape Communications Corporation utilise l'implantation du protocole SSL. Ce protocole effectue la gestion des clés et l'authentification du serveur avant que les informations ne soient échangées. Processus Le processus est le suivant : Un utilisateur quelconque utilise le logiciel Netscape client et entre en communication avec un logiciel serveur de type commercial. Le serveur possède déjà sa paire de clés publique/privée. C'est cette paire de clés qu'il utilise dans ses communication avec tous les logiciels clients. Le logiciel client, une fois reconnu par le logiciel serveur, génère une paire de clés publique/privée. Le logiciel client demande au logiciel serveur de lui fournir sa clé publique (celle du serveur). La clé publique du client est aussitôt encryptée avec la clé publique de serveur et transmise au serveur. Le serveur décode le message avec sa clé privée serveur et authentifie la clé publique de l'utilisateur. Le serveur envoie ensuite au logiciel client une confirmation, encryptée, du bon déroulement de l'opération. Toutes les informations suivantes qui seront transmises entre l'utilisateur et le serveur commercial seront désormais encryptées. De plus, il n'y a que ce serveur qui est en mesure de communiquer avec cet utilisateur puisqu'il n'y a que ce serveur qui connaît la clé publique de cet utilisateur. L'utilisateur et le serveur commercial peuvent maintenant échanger toutes les données voulues de façon sûre. L'ensemble de ce processus est maintenant complètement transparent pour l'utilisateur. Avec ce protocole, une nouvelle paire de clés est générée à chaque établissement de la communication entre le logiciel client de l'utilisateur et le logiciel serveur. La communication est donc entièrement sûre, mais en aucun cas le serveur commercial ne peut s'assurer de l'identité de l'utilisateur à l'autre extrémité. Une façon de résoudre ce problème, est de joindre à ce processus un système de validation, comme par exemple un numéro d'identification personnel (NIP) qui s'obtient par une inscription préalable. Fonctionnement Le système repose sur l'algorithme RSA (Rivest, Shamir et Adleman, les trois concepteurs comme indiqué plus haut), un standard utilisé pour le cryptage des données et la signature de messages électroniques. Cet algorithme est très utilisé pour l'authentification et le cryptage des données dans le domaine informatique. Deux paires de clés - une pour le verrouillage et l'autre pour le déverrouillage - à 40 bits sont utilisées. Chaque paire est composée d'une clé publique et d'une privée. La clé publique est faite afin d'être distribuée alors que la clé privée n'est jamais distribuée, elle est toujours gardée secrète. Les données qui sont cryptée avec la clé publique peuvent seulement être décryptées avec la clé privée. Et inversement, les données qui sont cryptée avec la clé privée peuvent seulement être décryptées avec la clé publique. C'est cette asymétrie qui fait que la clé publique est si utile. Démonstration par l’exemple (L’exemple ci-dessous provient du site Netscape) L'authentification est la procédure de vérification d'identité, pour que chacun soit sûr que l'autre soit bien celui qu'il prétend être. Dans l'exemple suivant la notation {SOMETHING} KEY signifie que {SOMETHING} a été crypté ou décrypté en utilisant une clé KEY. Imaginons que Alice (A) désire authentifier Bob (B). B a une paire de clés, une publique et une privée. Il révèle à A sa clé publique. A génère un message aléatoire et l'envoie à B : A B RANDOM-MESSAGE Bob utilise sa clé privée pour crypter le message reçu et le retourne à Alice : B A {RANDOM-MESSAGE} BOB'S-PRIVATE-KEY Alice reçoit le message et le décrypte en utilisant la clé publique révélée précédemment. Elle compare le message décrypté avec l'original qu'elle a envoyé à Bob ; s'ils correspondent, elle sait qu'elle est entrain de parler à Bob. Un imposteur n'aurait pas pu connaître la clé privée de Bob et par conséquent serait incapable de crypter correctement le message envoyé à Alice pour validation. Une fois qu'Alice a authentifié Bob, elle peut alors lui envoyer des messages que seul Bob peut décoder. A B {SECRET} BOB'S-PUBLIC-KEY Seule la clé privée de Bob est capable de décoder le message. Et par conséquent, même si quelqu'un d'autre est entrain d'observer la communication entre Alice et Bob, il ne peut pas déchiffrer ce message. NB: Il est a savoir que Alice et Bob sont des prénoms utilisés dans presque tous les livres traitant de la cryptologie. Certificats Un certificat est un document électronique qui atteste qu'une clé publique est bien liée à une organisation ou personne. Il permet la vérification de la propriété d'une clé publique pour prévenir la contrefaçon de clés publiques. Un certificat contient généralement une clé publique, un nom ainsi que d'autre champs pour identifier le propriétaire, une date d'expiration, un numéro de série, le nom de l'organisation qui contresigne le certificat et la signature elle-même. Le format des certificats est définie par la norme X509. Le certificat est donc une attestation que les informations qu'il contient sont exactes. Pour cela, le certificat doit être généré par un tiers de confiance, c'est-à-dire un organisme indépendant qui contrôle la véracité de ces informations. Le CA (Certifying Authority, autrement dit l'organisme certificateur) donne la crédibilité au certificat. Il existe typiquement deux types de certificats utilisés avec SSL : pour serveur et pour client. Techniquement ils utilisent le même format mais diffèrent par l'information qu'ils contiennent. Ainsi un certificat coté client sert à identifier un utilisateur, il contiendra donc des information sur cet utilisateur. Coté serveur, le certificat a pour but d'authentifier le serveur et l'organisme qui l'exploite. C'est ce type de certificat dont vous avez besoin pour mettre en place un serveur "sécurisé" HTTPS. Il ne sera pas expliqué ici comment obtenir un certificat serveur. Il existe plusieurs fournisseurs de certificats serveurs SSL. Pour plus d'informations sur ce sujet, consulter le site de Netscape et celui de SSL hosting. Certificat pour client Un certificat client est un certificat qui identifie l'utilisateur d'un navigateur web, et qui a vocation à identifier avec certitude un unique individu. Ce certificat est basé sur une clé publique/privée qui est stockée par le navigateur (à l'avenir, cette clé sera probablement sur carte à puce). De la même façon qu'un certificat pour serveur n'a pas de sens tant qu'il n'est pas authentifié par un tiers, le certificat client à besoin d'être signé. On peut différencier deux types de certificats suivant leurs signatures: les certificats signés par un serveur ou un organisme local (par exemple l'entreprise qui exploite un serveur SSL) et les certificats signés par un tiers certificateur reconnu de tous. Les certificats signés par un organisme local prennent tout leur sens dans la cadre d'un intranet/extranet. Ainsi certaines entreprises au lieu de donner des couples username/password à leurs employés leur font générer une clé SSL qu'ils vont ensuite signer. Il suffira alors d'indiquer au serveur de n'accepter les connexions SSL que de possesseurs de certificats signés par l'entreprise. On peut bien sur aller plus loin et utiliser les champs que contiennent les certificats pour créer des ACLs, et autoriser l'accès à des zones spécifiques du serveur en fonction de l'appartenance à tel ou tel service, par exemple. Ces certificats signés par une entité locale ont leurs limites dès qu'il s'agit de travailler avec des clients d'origines différentes. Ainsi un consommateur qui utilise des banques et des centres commerciaux SSL se retrouve rapidement avec des dizaines de certificats différents, fournis par chacun des serveurs. Aussi les certificats signés localement ne conviennent pas au grand public. La solution est que chaque individu souhaitant s'identifier sur plusieurs serveurs utilise un certificat signé par un tiers de certification. Ce dernier aura effectué toutes les vérifications nécessaires pour prouver que le certificat est authentique (qu'il identifie bien la bonne personne). L'individu fournira alors aux serveurs qu'il veut utiliser son certificat personnel signé par le tiers. Le serveur utilisera alors ce certificat pour assurer la sécurité (l'affectera dans les ACLs qui conviennent). L'utilisateur n'aura à stocker qu'un seul certificat (le sien, qui est en quelque sorte sa signature électronique) et n'aura à retenir qu'un seul mot de passe, celui qui protège son certificat. Ce système simplifie la vie de l'utilisateur, mais aussi de l'administrateur des serveurs. En effet, même si à l'échelle d'une entreprise il est simple d'attribuer avec certitude un certificat à la bonne personne, ce n'est plus le cas pour un magasin virtuel. Comment être sûr à distance que l'on signe le certificat de son client (que l'on n'a jamais vu)? Ce problème d'attribution des certificats signés se pose dès lors que les acteurs ne sont pas locaux et ne se connaissent pas. Il est donc nécessaire d'utiliser un tiers certificateur. Il existe d'ores et déjà plusieurs tiers qui fournissent des certificats SSL clients, dont Thawte. SSL et les logiciels de communications SSL est un protocole de communication qui est indépendant du protocole de communication de plus haut niveau qui repose sur lui. Il est donc possible de porter les logiciels de communications usuels (ftp, telnet, http, etc.) sur SSL sans grande modification, et de façon quasiment transparente pour l'utilisateur. SSL peut alors négocier la méthode de chiffrement à utiliser, authentifier les acteurs de la communication, et chiffrer au vol tout ce qui transite par son canal. Les spécifications de SSL sont publiques, mais son implémentation de référence (SSLREF) n'est pas exportable des USA. Heureusement, il en existe une implémentation librement accessible à partir de l'Australie. Il existe des patchs pour intégrer SSL aux logiciels de communications usuels: http (Mosaic et NCSA httpd), telnet, ftp, etc. Sources & divers liens pouvant vous intéresser : Université de Genève (en Français) http://cuisung.unige.ch/TechInternet/Securite/SSL.html Netscape (en Anglais) http://help.netscape.com/products/server/enterprise/3x/manual/encrypt.htm Ecole Polytechnique Fédérale de Lausanne (en Français) http://www.epfl.ch/SIC/SA/publications/FI95/fi-7-95/7-95-page3.html Unix Tcpdump Ntop Security Guide VPN Windows NT / Windows 2000 NT 4 System Security • • • • • • • • Removing The Last Logged On Username Displaying A Logon Message Allowing Automatic Logons Setting Permissions On Registry Keys Setting Auditing On Registry Keys Changing The Logon Screen Locking And Unlocking Windows NT Configuring A Screen Saver To Automatically Lock Administrator’s Notes... Components of the Windows NT security system are encountered in virtually all chapters of this book. This is because the Windows NT security system is a fundamental and underlying component of the operating system. The points covered in this chapter are pure security issues, along with the technology used to implement the security system. (For a more complete picture of Windows NT security, these points should be combined with the account information in Chapter 5 and the NTFS permissions discussion in Chapter 4.) In addition, Chapter 8 provides details on examining the security audit log. A key point regarding Windows NT security is that the security system can only protect data when the operating system is in use. In other words, physical security needs to be considered. If the Windows NT system can be restarted using a different operating system, the data held on Windows NT volumes can be accessed. Like all other operating systems, Windows NT does not encrypt the data held on disk. The Logon Process The following steps describe the components used in the validation of an interactive logon for a user. Key components are then covered in more detail. 1. Pressing Ctrl+Alt+Del invokes the Windows NT Logon Information dialog box. 2. The user enters the user account details, i.e., username and password. 3. The logon process called the Local Security Authority (LSA) runs the logon authentication package. 4. The username and password are verified by the authentication package against the account information contained in the Security Accounts Manager (SAM). 5. If the logon information is found to be incorrect, the logon attempt is rejected, and the Logon Message dialog box appears, displaying a logon failure warning message. 6. If the logon information is valid, the authentication package creates a logon session and passes the necessary account information to the LSA for the Security Access Token (SAT) to be created. 7. The Win32 subsystem is called by the logon process to create a user process to which the Security Access Token is attached. The Win32 subsystem starts the Windows NT desktop. Local Security Authority (LSA) The Local Security Authority plays a key role in the Windows NT security system and provides the software interface between the user and kernel modes of Windows NT. Its main functions include: • Calling the appropriate user authentication package • Generating the Security Access Token • Logging audit messages generated by the Security Reference Monitor • Controlling the Audit policy Security Access Token (SAT) When a Windows NT logon occurs, the operating system generates a Security Access Token (SAT) containing the Security ID (SID) of the user who is logging on, the Security ID of any groups to which the user belongs, plus any user rights assigned to the user. The Security ID is discussed further in Chapter 5. The SAT is only generated upon logon, so any changes made to either the user’s rights or to the groups to which the user belongs will only take effect when the user next logs on. In other words, if a user is currently logged on and added to the Administrators group, this group membership will only take effect when the user logs off and back on again. By comparing the Security IDs contained in the SAT to the permissions assigned to the object, Windows NT can verify that the user has sufficient permissions to access an object. Each process that runs on behalf of a user receives a copy of the SAT, which the process will use to access objects. Security Reference Monitor The Security Reference Monitor verifies whether the requested access to an object is allowed and whether the requesting process has permission to perform the required operation on the object. The Security Reference Monitor is also responsible for generating audit messages. Access Control List (ACL) The access control list (ACL) contains access control entries (ACEs). The ACEs contain access masks, which are used to identify which users or groups have been granted or denied access to an object. When access to an object—for instance, a file, printer, or folder—is requested, the security system searches the ACL to see if the requested access is allowed. The ACEs are ordered in the ACL so that the no-access ACEs are listed first. If the access to the object has been blocked, this ACE will be reached before the grant-access ACEs. Therefore, if a user requests access to a file with an ACE that allows access, but the user is also a member of a group that is denied access, the user will be denied access. The following steps show the method used to either allow or deny access to an object. 1. When access to an object is requested, a desired access mask is created that contains the process’s access request. 2. The process’s SAT is compared to the first ACE in the ACL. If a match is found between the Security IDs contained in the SAT and those contained in the ACE, further processing of the access request is done. If no match is found in this ACE, the next ACE is checked in the same way. If no match is found in any ACE contained in the object’s ACL, access to the object is denied. 3. If access is denied, the desired access mask is checked to see whether the request is to change the object’s permissions. If it is, and the process requesting the access is either the owner of the object or an administrator, the access will be allowed. If not, access to the object will be denied and no further ACEs will be checked. 4. If the access is allowed, the ACL entries are checked until an ACE is found with the exact match to the desired access mask. If the match is found, the access is allowed; if not, the access is denied. System Startup And Shutdown • • • • • • • • Changing The System Selection List Display Time Setting The Default Operating System System Hangs During System Startup Creating And Using A Hardware Profile Setting System Service For Hardware Profiles Starting And Stopping System Services Setting System Services To Start Automatically Adding The Shutdown Button • Removing The Shutdown User Right • Shutting Down Windows NT Administrator’s Notes... The system startup of Windows NT is a potential problem area for the Windows NT administrator. This chapter concentrates on the actual startup procedure, the files involved, and recovery techniques. When combined with the information in Chapter 9, which is the troubleshooting chapter, these techniques will help you diagnose and resolve startup problems. It should be noted that the specific startup process depends on the processor architecture on which the computer is based. System Startup When an Intel x86-based system is started, the Windows NT startup sequence is as follows: 1. Power-on self tests are run. 2. The boot device is located, and the master boot record is executed. 3. The master boot record locates the system partition and loads the boot sector from it. 4. The Windows NT boot loader, NTLDR, is loaded into memory and executed. 5. The processor is switched into 32-bit mode. The relevant minifile system is now started, supporting either FAT or NTFS volumes. 6. The BOOT.INI file is read, and the available operating system selections are displayed. The selections will appear for the length of time specified in the display list configuration line in BOOT.INI. 7. NTLDR runs NTDETECT.COM, which will detect the currently installed hardware and prepare a list. The list is passed back to NTLDR. 8. NTLDR then inquires if you want to invoke the Hardware Profile/Last Known Good. Pressing the spacebar while this message is displayed will invoke the relevant menu. 9. NTLDR then loads the Windows NT kernel, NTOSKRNL.EXE, and passes to it the hardware information gathered by NTDETECT.COM. At this point, the relevant device drivers are loaded but not initialized. 10. The kernel initializes and turns the screen blue when it has successfully taken control. 11. The device drivers that were loaded during the kernel load are now initialized. In addition, a second group of drivers is loaded and initialized by the kernel. 12. The high-level operating subsystems and services are now initiated by the session manager, SMSS.EXE. 13. An automatic boot time, CHKDSK, is run on each partition to verify partition integrity. 14. The paging file (or swap file) is set up. 15. The required subsystem is started—for example, the Windows subsystem, WIN32, which controls all I/O from the video screen. 16. WIN32 starts WINLOGON.EXE, which, in turn, starts the local security administrator, LASS.EXE. At this point, the Logon dialog box appears, inviting you to log on. 17. Although you can now log on, the startup process will continue and the necessary system services will be started in the background. Once a user has successfully logged on, the startup is considered good. The HKEY_LOCAL_MACHINES\System\LastKnownGood registry subkey is updated to point to the registry key that contains the configuration used to start the operating system successfully. The RISC startup is more dependent on the processor hardware. Table 3.1 points out which files are used for both x86- and RISC-based architectures, along with their location, attributes, and function. Table 3.1 The Windows NT startup files. File Location NTLDR Root folder of boot drive Attributes Hidden, read-only system file Function Windows NT system loader;also allows the loading of other operating systems; x86-based BOOT.INI Root folder of boot drive BOOTSECT.DOS Root folder of boot drive NTDETECT.COM Root folder of boot drive OSLOADER.EXE \Os\Winnt40 NTOSKRNL.EXE %systemroot% \System32 systems only. Read-only system Provides the operating system file selection list; x86-based systems only. Hidden system file Used to boot a different operating system from within NTLDR, e.g., MS-DOS. Hidden, read-only Builds installed hardware list and system file passes back information to NTLDR; x86-based systems only. The operating system loader for RISC systems. This provides, along with the RISC hardware, the same functions as NTLDR. The Windows NT kernel. As you will see in Chapter 9, there are various problems that can occur during startup that can be corrected by a competent system administrator. The system startup configuration can be modified by using the System icon contained in the Control Panel. The Startup/Shutdown tab is shown in Figure 3.1. BOOT.INI The BOOT.INI file supports the starting of not only Windows NT, but a selection of other operating systems, including non-Microsoft products. Figure 3.2 shows the BOOT.INI file configured for a dualboot system. The operating systems in this case are Windows NT and MS-DOS. [boot loader] timeout=5 default=multi(0)disk(0)rdisk(0)partition(2)\NT2000 [operating systems] multi(0)disk(0)rdisk(0)partition(2)\NT2000="Microsoft Windows 2000 Server" /fastdetect Figure 3.2 The BOOT.INI file. There are two lines of code used to start Windows NT. One line is the normal Windows NT startup line. The second is the VGA start line and is used to boot a standard VGA configuration. This uses the /BASEVIDEO switch to overcome display problems caused by selecting the wrong video driver—which may mean that you can’t read the display upon firing up Windows NT (which makes managing a Windows-based system slightly difficult, to say the least). The Disk And File Systems • • • • • • • • • Modifying The Disk Administrator Display Creating And Preparing A Partition/Volume Assigning Drive Letters Creating A Volume Set Extending A Volume Or Volume Set Creating A Mirror Set Breaking A Mirror Set Creating A Stripe Set Creating A Stripe Set With Parity • • • • • • • Setting And Viewing File And Folder Permissions Copying And Moving Folders Or Files Creating A New Folder Taking Ownership Of Folders And Files Configuring Auditing On Folders And Files Compressing Volumes, Folders, And Files Disabling The 8.3 Short File Name Creation Administrator’s Notes... The disk subsystem can be defined as encompassing the necessary hardware and software components to implement a robust file system. In this chapter, the hardware components are discussed in generic terms as adhering to the design goals of Windows NT, and our discussion will remain hardware-independent. In addition, the fault-tolerance issues discussed are based on the standard software functions of Windows NT and are not reliant on hardware-based, fault-tolerant solutions. The Disk Subsystem The disk subsystem is controlled by the I/O Manager, which controls all input and output requests for Windows NT. The I/O Manager is a component of the NT Executive, which acts as the interface between the high- and low-level components of the operating system—in other words, between the kernel (low) and the Win32 subsystem (high). The I/O Manager consists of a series of layered drivers that communicate with each other via the Executive I/O Manager, as shown in Figure 4.1. For example, for the file system driver to communicate with a disk drive, an I/O request would have to be routed via the I/O Manager. The I/O Manager, in turn, communicates with the disk driver and the disk controller. Because the I/O Manager is used to pass I/O requests between the drivers, each driver is kept as a self-contained module, making it easy to replace, remove, or add a driver without affecting the entire operating system. Figure 4.1 The I/O Manager and layered drivers. A good analogy for the way the I/O Manager and drivers interact is an elevator in an office block. To move from one floor to the next, employees have to use the elevator. If a particular floor is closed, the elevator still delivers the other employees to their required locations, and the organization as a whole continues to function. If you substitute I/O requests for employees, drivers for floors, and the I/O Manager for the elevator, you end up with a pretty good idea of how the disk subsystem works. The Disk Administrator The disk subsystem is managed with the Disk Administrator, which is a graphical system management tool accessed via the Administrative Tools menu. The Disk Administrator can be used to perform the following tasks: • • • • • Create and delete partitions Create, delete, format, label, and extend volumes and volume sets Create and delete stripe sets Assign drive IDs Save and restore the drive configuration In addition, with Windows NT Server, the Disk Administrator can do the following: • Establish and break disk mirroring or duplexing • Create, delete, and regenerate stripe sets with parity To use the Disk Administrator, you need to be a member of the Administrator group. When you invoke the Disk Administrator for the first time, a signature is written to disk 0. This signature does not overwrite any data and is used internally by Windows NT. Disk Administrator provides two views of the disk configuration: partition view, shown in Figure 4.2, and volume view, shown in Figure 4.3. Figure 4.2 The Disk Administrator partition view. Figure 4.3 The Disk Administrator volume view. To use the Disk Administrator effectively, you need to have an understanding of both the terminology and underlying technology, which is explained in the following section. Windows NT Workstation And Server The following terms apply to technology and features common to both the Server and Workstation versions of Windows NT: • System and boot partitions—Under Windows NT, the system partition is the volume that contains the files required to load Windows NT. This must be on the disk that is accessed by the computer system on startup. On x86-based systems, this partition must be marked as active. The boot partition contains the Windows NT operating system files. This partition can be the same partition as the system partition, but it doesn’t have to be. RISC-based systems do not use an active partition to boot, but instead have a hardware-based boot configuration. • Primary partition—A partition that can be marked as active and could be used to load an operating system. There can be a maximum of four primary partitions per physical disk. • Extended partition—This is used to subdivide free disk space into smaller logical areas. There can be only one extended partition per disk. • Volume— An area of disk that is partitioned and formatted for any of the Windows NT-supported file systems. • Volume sets—Disk partitions joined together into a single logical area. The partitions can be on the same or different physical disks and can include disks of different types. There can be up to 32 separate areas of disk joined together to form a single volume set. The data is written to volume sets in a sequential fashion, i.e., one area of the volume set is filled up before moving on to the next. The system and boot partitions cannot be part of a volume set. Note: Both volumes and volume sets can be extended in size without reformatting the volume, as long as the volume is formatted for use by NTFS. If the volume you wish to extend is formatted for FAT use, you must first convert it to NTFS and then extend it. The conversion from FAT to NTFS is a one-way process. • Stripe sets—In a stripe set, data is written across different physical disks in 64 K stripes on partitions of equal size, as shown in Figure 4.4. This technique is often used to increase the disk I/O performance; because the I/O load is spread over a number of disk spindles, I/O throughput is increased. Stripe sets can be configured over 2 through 32 physical disks. Disk striping provides no fault tolerance. If any of the disk drives containing a stripe fails, all data in that stripe set will be lost. The User Environment • Creating A User Account • Setting The Expiration Date On A User Account • Setting Workstation Logon Restrictions • • • • • • • • • • • • • • • • • • • • • • Setting Restrictions On Logon Hours Renaming A User Account Copying A User Account Disabling A User Account Deleting A User Account Changing The Rights Assigned To A User Creating A Group And Adding Members To The Group Viewing And Removing Group Members Adding Rights To A Group Removing Rights From A Group Changing User Passwords Setting The Password Expiration Date Enabling The Password History Setting The Minimum Password Age Setting The Number Of Allowed Bad Logon Attempts Clearing A Locked Account Defining A User’s Home Directory Creating And Assigning A Profile Returning A User’s Personal Profile Back To Default Creating A Domain-Wide User Policy Adding A User-Specific Policy To An Existing Configuration Deleting A User Policy Administrator’s Notes... Administrating the user environment in any reasonably large Windows NT installation is something with which the Windows NT administrator quickly becomes proficient. When creating user accounts, you should give careful consideration to the user environment. Assigning appropriate properties during the creation of user account templates is considerably more productive than creating accounts and then configuring the required properties, especially as the number of accounts increases. User Accounts For NT workstations configured as a workgroup, user accounts are managed with the User Manager administration tool. For NT servers in a domain, the User Manager For Domains tool is used. Shown in Figure 5.1, User Manager For Domains is identical to User Manager, with a few additional features. Figure 5.1 The User Manager For Domains tool. Windows NT user accounts are identified by the username, which may be up to 20 characters long. Letters, numbers, and some special characters may be used in the username. Each user account may be assigned a password of up to 14 characters, or the password may be blank, if the account policy is configured to allow this. Passwords may be constructed of letters, numbers, and some special characters. Windows NT can be configured to retain a password list of up to the last 24 passwords used so that users are unable to keep reusing the same passwords when forced to change them by the account policy. When a user account is created, a Security ID, or SID, is assigned to the account. This is used by Windows NT internally to identify the user accounts. Windows NT creates the SID by using a hashing algorithm based on three 32-bit numbers generated from the following information: • Computer name. • System time on the computer. • User mode execution time of the process used to create the SID. Using this method ensures a unique SID is generated for each account. Once generated, the SID is never changed, so if a user account is renamed, the account will still be recognized by Windows NT and retain its rights and permissions. However, if the user account is deleted and then added using the same username and password, the account would have a different SID than the original, so it would not gain the permissions or rights of the original account. In this case, the required permissions and rights would have to be re-created. To avoid this headache, always make sure that a user account will not be required at a later date before deleting it. Account Policies User account configurations are set by the account policy in force for either a specific computer in a workgroup or for the entire domain. The domain account policy has several more options available than the workgroup. Figure 5.2 shows the Account Policy dialog box for a Windows NT domain. The following section explains the policies and the differences between the two configurations. Figure 5.2 The Account Policy dialog box. Networking • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Installing Network Adapters Sharing A Folder Who’s Accessing The Server? Changing Workgroup Workstations To Domains Changing The System Name Installing And Configuring NetBEUI Installing And Configuring IPX/SPX Installing And Configuring TCP/IP Checking TCP/IP Connectivity Installing And Configuring A DHCP Server Configuring Clients To Use The DHCP Server Configuring And Using WINS Configuring And Using DNS Which DHCP Client Is Using What TCP/IP Address? Installing And Configuring Gateway Services For NetWare Remote Access Service Replicator Service Locating The PDC And The BDCs Promoting A BDC To A PDC Promoting A BDC To PDC When The PDC Is Down Synchronizing The Domain Configuring Domain Trusts Removing Computers From A Domain Managing A Domain From A Windows NT Workstation Sending A Message To A Remote Computer Installing And Configuring Macintosh Services Configuring And Using Macintosh Print Services Creating And Using Macintosh Volumes Configuring Macintosh Logon Messages Using The Internet Via A Dial-Up Line Administrator’s Notes... The networking facilities provided with Windows NT are extensive. The multiple standard networking protocols help make the integration of Windows NT into existing networks relatively straightforward. Windows NT is a protocol-independent operating system and will function with whichever protocols best suit your requirements. Key Network Components The following lists the key network components of Windows NT. Each is discussed in detail in this chapter. • • • • • • • • • PDCs, BDCs, and servers Browsers Replicator service Protocols (NWLink, NetBEUI, TCP/IP, AppleTalk, and DLC) Domain Name System Windows Internet Naming Service NetWare Gateway Service Remote Access Service Macintosh services Network Utility The Network utility contained in the Control Panel is where virtually all network software components are installed from and configured. The majority of changes made to the network software components require you to restart the system before these changes take effect. When making any network protocolrelated changes, you will see that Windows NT automatically reconfigures the network bindings, either when you exit the Network utility or when you select the Bindings tab. Bindings are the communication connections between the networking subsystem—for instance, the adapter card, protocols, and services. The Network utility management window is shown in Figure 7.1. Figure 7.1 The Network utility management window. The Domain Model Windows NT networks can be constructed in one of two ways: around a workgroup or around a domain model. (Chapter 1 provides more detail regarding the differences between these two configurations.) From a networking point of view, we will concentrate on the domain model and the additional steps required to administrate and support this model. Workgroup administration, on the other hand, is more concerned with the administrative overhead of supporting multiple security account databases. The key issue to understand about the domain model is that a single security database is used to validate the security and logons for the whole domain. Keeping this database available and synchronized is our main concern. When computers are added to the domain, a user account for each computer is created in the domain Security Account Manager database. Server Manager under Administrative Tools can be used to add or remove systems from the domain. Primary Domain Controller (PDC) The PDC is used to hold the domain Security Account Manager database, or SAM, which contains all the domain account security information. Here is where all updates are made to the database. There should only ever be one PDC per domain. In addition, the PDC can be used to validate domain logons. Backup Domain Controllers (BDCs) The BDCs hold read-only copies of the domain database. There can be multiple BDCs in a domain. BDCs can validate domain logons and, in doing so, reduce the load on the PDC. The BDC copies of the domain databases are automatically synchronized with the PDC. In addition, the system administrator can force this synchronization to take place immediately. BDCs should be carefully placed in your network design to ensure that the domain logons are validated evenly across the network. Also, wherever possible, the validation should not take place across slow wide-area links. The BDC is only synchronized automatically with the PDC at 15-minute intervals. A situation could arise where a user changes his or her password at the PDC, logs out of the domain, and then logs back on. If that logon is handled by a BDC that hasn’t yet synchronized the password change with the PDC, the logon would be invalid. When the BDC can’t validate a logon, it passes the logon to be validated by the PDC, and the user would gain access to the domain. Note: To move either a PDC or BDC between domains, you will need to reinstall Windows NT. Any BDC has the potential of being promoted to a PDC. When a BDC is promoted, the existing PDC is automatically demoted to a BDC. Servers Servers take no part in the validation of domain logons and do not hold copies of the domain database. The computers designated as servers are often used for mission-critical applications, and their resources are required in running the application instead of validating domain logons. Note: The role a system plays in the domain is designated upon installation. If the system has been designated as a server, that system cannot be promoted to either a BDC or PDC. To allow servers to be promoted, you must reinstall Windows NT. To move servers between domains, no reinstallation is necessary. The relationship between the PDC, BDCs, and servers is shown in Figure 7.2, along with the validation of domain logons. Figure 7.2 Domain and server relationships. Event And System Monitoring Tools • • • • • • • • Locating And Examining Unsuccessful Logon Attempts Modifying Event Log Settings Fixing Local System Performance Problems Changing A Process’s Priority Monitoring System Performance Logging And Viewing Performance Data Configuring System Alerts Network Monitoring Administrator’s Notes... One of the biggest problems faced by the administrator of any multiuser, multitasking operating system is keeping track of what system events have occurred and what caused them. The Windows NT system administrator faces these same problems. Fortunately, NT provides some excellent system monitoring tools. Although the tools are easy to use, the interpretation of the results produced by these tools often causes the most problems, especially in the area of performance monitoring. This chapter hopes to provide you with enough information about these tools to point you in the right direction in tracking down your problems. The Event Viewer The Event Viewer is a system event log viewer accessed via the Administrative Tools menu. This tool provides a graphical management interface to view the contents of the system, security, and application logs. No special user rights are required to view the system and application logs; however, to view the security log, you must be a member of the Administrator group or have the relevant individual right assigned. All three logs can only be cleared down or have their log settings changed by an administrator. The Event Viewer is shown in Figure 8.1, and a description of the columns is listed in Table 8.1. The different functions of the three event logs are explained in Table 8.2. Figure 8.1 The Event Viewer. Table 8.1 The Event Viewer column descriptions. Column Date Time Source Category Event User Computer Description Date on system that event was logged. Time on system that event was logged. Software application or system component that logged the event. Source software-defined category for this type of event. Number assigned by the source software to identify events. User name of the user logged on when the event occurred. Computer name of the system where the event occurred. Table 8.2 The event log file usage. Log File System Security Application Description of Use Used to log events generated by the operating system. System security events based on the Audit Policy setup are logged here. Both system and user application events are logged here. In addition to current log files, the Event Viewer can be used to view previously saved event files. This is of particular interest to high-security sites where saving security event files for several years is a normal practice. The characteristics of the log files can be set on a per-log basis, and items that can be configured include the maximum log file size and how long events are kept before being overwritten. The defaults for the log settings are 512 K maximum size and 7 days before events are overwritten. Often, the first log setting to be changed is the security log overwrite time, because it is often advisable to keep a security audit trail for longer than a week. Events may be retained for a maximum of one year. The basic one-line event message can be expanded to reveal more detail. The detail view not only provides a text description of the event record but sometimes includes additional hex data in the lower part of the event record. This data can be used by Windows NT support personnel to further diagnose the event. A sample detail record is shown in Figure 8.2. Figure 8.2 Detailed view of the event record. Five different event types are used to categorize all events. These are shown in Table 8.3, along with a brief description of the audit events to which they are assigned. Event logs can be viewed on remote systems by using the Select Computer option from the Log menu. You must have administrator rights on the remote system to view the event logs. Table 8.3 Audit event types and descriptions. Event Type Description Error Warning Failure Audit Information Success Audit Major error has occurred; used for the most serious errors. Warning of impending problems or non-critical errors. Failed audit event has been received; logon failures generate this event. Used to indicate the successful conclusion of a system event. Success audit event has been received; successful logons generate these events. As event logs become filled with data, locating a particular event becomes increasingly difficult. To help with this task, a search utility is included in the View menu. Also, you can set the order in which the events are displayed—for instance, oldest or newest first. In addition, you can filter the events, which is useful in removing irrelevant event records from the Viewer. This filter is only applied to the display and does not affect the actual log files. Note: The Event Viewer is static; no new event records will be added to the Viewer display as they occur. To display these new records, either use the View Refresh option or the F5 function key. Event log files can be saved for future use in one of three formats: • Event file format—This is the native Event Viewer file format. When files are saved, the Event Viewer can be used to view these files directly. • Text file format—Files in this format can be viewed in applications such as word processors. • Comma-delimited text file format—Log files in this format can be viewed in applications such as spreadsheets. Troubleshooting • • • • • • • • • • • • • • • Creating A Boot Floppy Creating A Fault-Tolerant Boot Floppy Recovering From A Failed Primary Mirror Member System Disk Creating An Emergency Repair Disk Restoring The Administrator Password Fixing A Corrupt Operating System Saving The Disk Configuration Information Restoring The Disk Configuration Information Clearing Stuck Print Jobs Diagnosing RAS Connection Problems Diagnosing Problems With PPP Connections Configuring System Recovery Generating A Diagnostic Report Displaying IRQs In Use Resolving Device Detection Problems • Running The Hardware Detection Tool • Installing A Service Update Pack • Checking Disks For Errors Administrator’s Notes... Troubleshooting an operating system is one of those tasks you hope to avoid; when you are called upon to perform such tasks, your skills are often rusty. This chapter hopes to point you in the right direction concerning common troubleshooting techniques. In addition to this chapter, you should refer to Chapter 8, which includes details on using the Event Viewer. This utility can often provide vital clues when you are trying to resolve a problem. Also, Chapter 3 provides details on the system startup process, which may help resolve boot problems. Windows NT Diagnostics Windows NT Diagnostics, contained in the Administrative Tools program group, can be used to display the current hardware and software configurations of both local and remote systems. The configuration information displayed by Windows NT Diagnostics is, in most cases, obtained from the Registry, but Diagnostics provides a much more user-friendly way of displaying the configuration data. The Windows NT Diagnostics sheet has nine information pages available: Version, System, Display, Drives, Memory, Services, Resources, Environment, and Network. The System page is shown in Figure 9.1. Figure 9.1 The System page in Windows NT Diagnostics. Windows NT Boot Problems As far as users are concerned, one of the most visible problems is a completely unavailable system—in other words, the system doesn’t start. If the system in question is a critical server, the pressure to return the server to service quickly mounts. Table 9.1 provides the most common boot problems and the fixes for them. Table 9.1 Common boot problems. Boot Errors Possible Causes and Fixes NTDETECT failed. NTDETECT.COM in the root folder of the boot drive is corrupt or missing. Try booting from a boot floppy. If this starts Windows NT successfully, copy NTDETECT from the boot floppy to the Windows NT boot disk root folder. Alternatively, you can boot using the Windows NT setup disk and repair the system using the emergency repair disk. A kernel file is missing from the disk. NTLDR in the root folder of the boot drive is missing. This problem can also be fixed by using either the boot floppy or the emergency repair disk to copy NTLDR into the root folder of the boot drive. Windows NT could not start because of a The path and device boot line in BOOT.INI could computer disk hardware configuration problem. be incorrect. Refer to Chapter 3 for more on the Could not read from the selected boot disk. Check structure of the boot command line. boot path and disk hardware. No error message displayed, but the system starts Windows NT without displaying the operating system selection menu and waiting for the boot time-out period. Windows NT could not start because the following file is missing or corrupt: <WINNT ROO>\SYSTEM32\NTOSKRNL.EXE. Please reinstall a copy of the above file. The BOOT.INI file is missing from the root folder of the boot drive. Once the system has started, log on to Windows NT and copy BOOT.INI from the boot floppy to the root folder of the boot disk. The reason and resolution given could be the correct action to take; however, if the BOOT.INI file is pointing toward the wrong partition, this error can occur. Try booting using the boot floppy. If this works, check or replace the BOOT.INI file. If the boot floppy displays the same error message, use the Windows NT setup disk and the emergency repair disk to resolve the problem. A boot floppy can be used to correct many boot problems quickly and efficiently. In fact, you can start the system by using the boot floppy, allowing you to resolve the boot problem at a more convenient time. (The Practical Guide in this chapter provides full details on how to create a boot floppy.) The boot information detailed in this chapter applies to Windows NT systems running x86-based computers; RISC systems rely on onboard firmware to configure the initial boot process. Details on the RISC boot process can be obtained from the manufacturer of your RISC system. Windows NT Boot Floppy One of the most useful tools that system administrators can create is a Windows NT boot floppy. Although this floppy can’t hold the entire Windows NT operating system, it can contain the key boot files that can be used to diagnose and repair boot problems. The boot floppy is the only way to start a Windows NT system with a failed primary mirror member system disk. (Further details are given in the Practical Guide.) The Windows NT boot floppy is a generic boot disk. In other words, if the hardware configuration of your Windows NT systems are all the same, with Windows NT located on the same disk partitions, a single boot floppy can be used to support them. Hints And Tips • • • • • • • • • • • • • • Disabling The CD-ROM Autorun Using The Recycle Bin To Restore A File Configuring The Recycle Bin Properties Changing The Network Bindings Order Using The AT Command Creating Shortcuts Converting FAT Volumes To NTFS Changing The Default Installation Device Configuring Automatic Adjustment For Daylight Saving Time Changing The Installed Software Components Using The Find Utility To Locate A Computer Using The Find Utility To Locate Files And Folders Configuring The Inbox For Internet Mail Optimizing Server Throughput Administrator’s Notes... This chapter does not focus on one particular area but, instead contains a mixed bag of hints and tips that don’t neatly fit into the other chapters. Many of the points covered in this chapter are provided to make the day-to-day workload a little easier for the system administrator. Scheduling One area of weakness in the current release of Windows NT is scheduling. A basic scheduling utility is provided, managed via the AT command, that enables commands and programs to be scheduled to run at a specified date and time. However, no dependencies can be set (for example, setting the system to run Job 3 only after Job 1 and Job 2 have successfully been run). Such dependencies are often required for complex scheduling tasks. The AT command is used from the Windows NT command prompt and is not the most user-friendly administration tool. In fact, incorrect AT commands are often entered, which then fail at the specified time. This can be very frustrating, because little information is usually given regarding the cause of the problem. It’s worth checking the System Event log if you have problems with failing jobs. The Schedule service needs to be running before you can use the AT command. Help can be obtained by adding a ? switch to the command, for instance, AT /?. Shortcuts To increase productivity and make frequently used programs and applications easier to locate, you can create a shortcut to the object from the Windows NT desktop. A shortcut can be configured on any object, including folders, disk drives, computers, and printers. When created, a shortcut appears as an icon with a small arrow in its left-hand corner. In addition, shortcuts can be placed in the Startup program group to automatically start the object upon logon. Multiple shortcuts can be configured on the same object, and different security can be configured on each one. The deletion of a shortcut doesn’t affect the original object. Finding Resources Locating computers in a large network by using the browser tools—for example, Network Neighborhood—can get increasingly difficult as the network expands, especially when the computer names are similar. For example, many companies employ a computer naming scheme that indicates where a computer is located in the organization, such as BL1A6 for Building 1, Area 6. Although this is useful for physically locating computers, it is less than ideal when using the browser tools. Locating files and folders can be just as troublesome, especially if you’re not sure of the full name of the object you want to locate. The Find utility, shown in Figure 11.1, is a handy alternative. In addition to locating computers, Find can be used to locate files and folders. Various search options are available with Find, including searching for files that contain a particular text string. Figure 11.1 The Findutility dialog box. Windows Messaging Windows Messaging is a term used to describe user communication. For example, email and faxing are both parts of Windows Messaging. Windows NT is shipped with a client version of Microsoft Exchange, which can be used to connect to both Microsoft mail post offices and Internet mail services, and provide email facilities. These facilities are accessed via the Inbox icon on the desktop. The Practical Guide for this chapter contains an example of configuring Windows Messaging for use with Internet mail. Projects: Practical Guide To Hints And Tips The following section provides real-life hints and tips in step-by-step format. Disabling The CD-ROM Autorun Whenever you’re in a hurry, which, of course, is all the time, the slightest holdup can send your blood pressure climbing. One feature of Windows NT that adds to your problems (at least, it does to mine) is the Autorun facility. Autorun brings up the Windows NT CD-ROM dialog box, as shown in Figure 11.2, each time you insert any application CD into your CD-ROM drive. Although the Autorun feature can be handy, especially when browsing a new CD-ROM, it’s a pain to have to close this dialog box every time you load the Windows NT source software to be used by an administration tool. Figure 11.2 The Windows NT CD-ROM dialog box. Don’t worry. You can use the Registry to disable this feature and keep your blood pressure from going off the scale. 1. Choose Start|Run. The Run dialog box appears. 2. Click Browse, and use the Browse dialog box to select the Registry Editor REGEDT32, located in the SYSTEM32 subfolder. Click OK. The Registry Editor window appears. 3. Select the HKEY_LOCAL_MACHINE subtree. Select the SYSTEM\CurrentControlSet\Services\Cdrom subkey, as shown in Figure 11.3. 4. Double click the Autorun data value in the right-hand pane of the Registry Editor. The DWORD Editor dialog box appears. Change the data entry from 1 to 0, and click OK. 5. Exit the Registry Editor. You’ll need to restart the system for the change to take effect. Figure 11.3 The Registry Editor, HKEY_LOCAL_MACHINE subtree Windows NT User Rights Table C.1 provides a complete list of Windows NT user rights and the rights that are defined as advanced are indicated with an X. Table C.1 The Windows NT user rights. Right Advanced Right Description Access this computer connections to this computer. - Allows users to log on or establish network Act as part of the operating system X Operations can be performed as part of the operating system. Currently used by some of the Windows NT subsystems. Add workstations to domain Permits non-Administrator accounts to add workstations to the domain. This right is not currently implemented. Back up files and directories Permits users to back up files and folders that they don’t have direct access to (overrides the file and folder permissions). Bypass traverse checking X Allows users to access files and folders contained in a parent folder that they have been denied access to. This right needs to be removed from users who require POSIX compliance. Change the system time to be changed. - Allows the time of the Windows NT computer Create a pagefile not currently implemented. X Allows a pagefile to be created. This right is X Used internally with Windows NT to create Create a permanent shared object special permanent objects. Create a token object X the user Security Access Token on logon. Used by the Local Security Authority to create Debug programs Permits the user to debug low-level objects. X Force shutdown from a remote system remote system. This right is not currently implemented. Generate security audits generated. X Permits computer to be shut down from a Permits security audit log entries to be Increase quotas X right is not currently implemented. Allows object quotas to be increased. This Increase scheduling priority be increased. X Permits the scheduling priority of a process to - Permits device drivers to be installed and Load and unload device drivers removed. Lock pages in memory X Permits pages to be locked into memory. Locked pages will not be paged out from main memory to the pagefile. Log on as a batch job X processes. This right is not currently implemented. Permits jobs to be logged on as batch Log on as a service X Permits a process to be run as a service. Log on locally keyboard. - Permits local logon using the workstation Manage auditing and security log Permits the events that are to be audited on an object to be defined. Also allows the security event log to be managed. Modify firmware environment values X Allows the modification of system variables contained in nonvolatile RAM. Only used with computers with necessary hardware. Profile single process process. X Permits the performance sampling of a single Profile system performance system. X Permits the performance sampling of the Replace a process level token X modify a process’ security access token. A right used only by the operating system to Restore files and directories they do not have direct access to. Permits users to restore files and folders that Shut down the system Permits the system to be shut down. Take ownership of files or - other objects overriding the assigned permissions. Permits ownership of objects to be taken, Table 4.1 File permissions. Permission Description Standard File Access Permissions No Access (None) All access to the file is blocked, overriding all other permissions. Read (RX) Allows data to be viewed and executed if it is a program. Change (RWXD) Same access as Read, plus data may be modified or the file deleted. Full Control (All) Same access as Change, plus file permissions may be changed and ownership of the file taken. Special File Access Permissions Read (R) File may be opened and data viewed. Write (W) File data may be modified. Execute (X) Allows execution of program file. Delete (D) File may be deleted. Change Permissions (P) File access permissions may be changed. Take Ownership (O) Allows ownership of the file to be taken. Table 4.2 Folder permissions. Permission Description Standard Folder Access Permissions No Access (None)(None) Blocks all access to the folder, overriding all other permissions. List (RX)(not specified) Allows listing of file names and moving to subfolders. Read (RX)(RX) The same as List, plus files may be viewed and executed. Add (WX)(not specified) Allows files to be added to the folder and subfolders created. Add & Read (RWX)(RX) The same as List, plus Add at folder level. Files may be viewed and executed. Change (RWXD)(RWXD) The same as Add & Read at folder level, plus folder may be deleted. Files may be viewed and executed. Files and subfolders may be modified and deleted. Full Control (All)(All) The same as Change, plus file and folder permissions may be changed, and ownership of folder and files may be taken. Special Folder Access Permissions Read (R) File and subfolder names may be listed. Write (W) Files and subfolders may be added to the folder. Execute (X) Moving to subfolder permitted. Delete (D) Folder may be deleted. Change Permission (P) Folder permissions may be changed. Take Ownership (O) Ownership of folder may be taken. Practical Guide to System Security The following section provides real-life examples and step-by-step instructions on how to administrate Windows NT security. As previously stated, the Windows NT security system cannot be separated from the total operating system, so examples on using and configuring security can be found in most chapters. Some of these examples use the Registry Editor REGEDT32 to directly change the Registry. Be careful when using REGEDT32; incor rect changes to the Registry can prevent Windows NT from functioning. Removing The Last Logged On Username You have a lot of general-user Windows NT workstations—in other words, systems not allocated to any particular user but available for anyone to use. You often find that users are trying to log on using the wrong username, and at the moment, the last logged on username is displayed. This isn’t a particular security issue for you, but it does mean that user accounts are getting locked by mistake. You decide to remove the last logged on username from the logon screen. The last username is removed by changing the Registry. This can be done in one of three ways: a. Using the System Policy Editor in a domain to create a domain policy. b. Using the System Policy Editor to change the local Registry. c. Using the Registry Editor REGEDT32 to change the Registry. Method A—Creating A Domain Policy 1. Choose Start|Programs|Administrative Tools|System Policy Editor. The System Policy Editor window appears. 2. Choose File|New Policy. The Policy window shows the Default Computer and Default User icons. Double click the Default Computer icon to display the Default Computer Properties window. 3. Double click the Windows NT System icon, then the Logon Book icon. 4. Select the Do not display last logged on user name option, as shown in Figure 2.2. Click OK. You are returned to the System Policy Editor window. 5. Choose File|Save As, and save the policy file to the NetLogon folder of the Primary Domain Controller with a file name of NTCONFIG.POL. Figure 2.2 Logon policy settings in the Default Computer Properties window. Method B—Changing The Local Registry 1. Choose Start|Programs|Administrative Tools|System Policy Editor. The System Policy Editor window appears. 2. Choose File|Open Registry. The local Registry is opened. 3. Double click the Local Computer icon. The Local Computer Properties window appears. 4. Double click the Windows NT System icon, then double click the Logon Book. Check the Do not display last logged in user name option. Click OK. You are returned to the System Policy Editor window. Click File|Save to save the changes to the local Registry. Method C—Changing The Registry Directly 1. Choose Start|Run. The Run dialog box appears. 2. Use the Browse button to select the Registry Editor REGEDT32, which is located in the SYSTEM32 subfolder, as shown in Figure 2.3. Click OK. The Registry Editor window appears. 3. Select the HKEY_LOCAL_MACHINE hive. Select the SOFTWARE\Microsoft\Windows NT CurrentVersion\Winlogon subkey. 4. If the DontDisplayLastUserName value entry doesn’t exist, you need to create it. Choose Edit|Add Value. The Add Value dialog box appears. Enter “DontDisplayLastUserName” into the Value Name field, and select REG_SZ in the Data Type field. Click OK. The String Editor dialog box appears. Enter “1” into the dialog box, and