Download Sécurité - Netline

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:
Pr(Pu(Pu (Pr())))=
..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 OutilsOptions 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