D-Link DFL-260 Product Manual - Page 318

Insertion/Evasion Attack Prevention, Initial Packet Processing, Checking Dropped Packets

Page 318 highlights

6.5.4. Insertion/Evasion Attack Prevention Chapter 6. Security Mechanisms HTTP Normalization Each IDP rule has a section of settings for HTTP normalization. This allows the administrator to choose the actions that should be taken when IDP finds inconsistencies in the URIs embedded in incoming HTTP requests. Some server attacks are based on creating URIs with sequences that can exploit weaknesses in some HTTP server products. The URI conditions which IDP can detect are: • Invalid UTF8 This looks for any invalid UTF8 characters in a URI. • Invalid hex encoding A valid hex sequence is where a percentage sign is followed by two hexadecimal values to represent a single byte of data. An invalid hex sequence would be percentage sign followed by something which is not a valid hexadecimal value. • Double encoding This looks for any hex sequence which itself is encoded using other hex escape sequences. An example would be the original sequence %2526 where %25 is then might be decoded by the HTTP server to '%' and results in the sequence '%26'. This is then finally decoded to '&'. Initial Packet Processing The initial order of packet processing with IDP is as follows: 1. A packet arrives at the firewall and NetDefendOS performs normal verification. If the packet is part of a new connection then it is checked against the IP rule set before being passed to the IDP module. If the packet is part of an existing connection it is passed straight to the IDP system. If the packet is not part of an existing connection or is rejected by the IP rule set then it is dropped. 2. The source and destination information of the packet is compared to the set of IDP Rules defined by the administrator. If a match is found, it is passed on to the next level of IDP processing which is pattern matching, described in step below. If there is no match against an IDP rule then the packet is accepted and the IDP system takes no further actions although further actions defined in the IP rule set are applied such as address translation and logging. Checking Dropped Packets The option exists in NetDefendOS IDP to look for intrusions in all traffic, even the packets that are rejected by the IP rule set check for new connections, as well as packets that are not part of an existing connection. This provides the firewall administrator with a way to detect any traffic that appears to be an intrusion. With this option the only possible IDP Rule Action is logging. Caution should of course be exercised with this option since the processing load can be much higher when all data packets are checked. 6.5.4. Insertion/Evasion Attack Prevention Overview When defining an IDP Rule, the administrator can enable or disable the option Protect against Insertion/Evasion attack. An Insertion/Evasion Attack is a form of attack which is specifically 318

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330
  • 331
  • 332
  • 333
  • 334
  • 335
  • 336
  • 337
  • 338
  • 339
  • 340
  • 341
  • 342
  • 343
  • 344
  • 345
  • 346
  • 347
  • 348
  • 349
  • 350
  • 351
  • 352
  • 353
  • 354
  • 355
  • 356
  • 357
  • 358
  • 359
  • 360
  • 361
  • 362
  • 363
  • 364
  • 365
  • 366
  • 367
  • 368
  • 369
  • 370
  • 371
  • 372
  • 373
  • 374
  • 375
  • 376
  • 377
  • 378
  • 379
  • 380
  • 381
  • 382
  • 383
  • 384
  • 385
  • 386
  • 387
  • 388
  • 389
  • 390
  • 391
  • 392
  • 393
  • 394
  • 395
  • 396
  • 397
  • 398
  • 399
  • 400
  • 401
  • 402
  • 403
  • 404
  • 405
  • 406
  • 407
  • 408
  • 409
  • 410
  • 411
  • 412
  • 413
  • 414
  • 415
  • 416
  • 417
  • 418
  • 419
  • 420
  • 421
  • 422
  • 423
  • 424
  • 425
  • 426
  • 427
  • 428
  • 429
  • 430
  • 431
  • 432
  • 433
  • 434
  • 435
  • 436
  • 437
  • 438
  • 439
  • 440
  • 441
  • 442
  • 443
  • 444
  • 445
  • 446
  • 447
  • 448
  • 449
  • 450
  • 451
  • 452
  • 453
  • 454
  • 455
  • 456
  • 457
  • 458
  • 459
  • 460
  • 461
  • 462
  • 463
  • 464
  • 465
  • 466
  • 467
  • 468
  • 469
  • 470
  • 471
  • 472
  • 473
  • 474
  • 475
  • 476
  • 477
  • 478
  • 479
  • 480
  • 481
  • 482
  • 483
  • 484
  • 485
  • 486
  • 487
  • 488
  • 489
  • 490
  • 491
  • 492
  • 493
  • 494
  • 495
  • 496
  • 497
  • 498
  • 499
  • 500
  • 501
  • 502
  • 503
  • 504
  • 505
  • 506
  • 507
  • 508
  • 509
  • 510
  • 511
  • 512
  • 513
  • 514
  • 515
  • 516
  • 517
  • 518
  • 519
  • 520
  • 521
  • 522
  • 523
  • 524
  • 525
  • 526
  • 527
  • 528
  • 529
  • 530
  • 531
  • 532
  • 533
  • 534
  • 535
  • 536
  • 537
  • 538
  • 539
  • 540
  • 541
  • 542
  • 543
  • 544
  • 545

HTTP Normalization
Each IDP rule has a section of settings for
HTTP normalization
. This allows the administrator to
choose the actions that should be taken when IDP finds inconsistencies in the URIs embedded in
incoming HTTP requests. Some server attacks are based on creating URIs with sequences that can
exploit weaknesses in some HTTP server products.
The URI conditions which IDP can detect are:
Invalid UTF8
This looks for any invalid UTF8 characters in a URI.
Invalid hex encoding
A valid hex sequence is where a percentage sign is followed by two hexadecimal values to
represent a single byte of data. An invalid hex sequence would be percentage sign followed by
something which is not a valid hexadecimal value.
Double encoding
This looks for any hex sequence which itself is encoded using other hex escape sequences. An
example would be the original sequence
%2526
where
%25
is then might be decoded by the
HTTP server to '
%
' and results in the sequence '
%26
'. This is then finally decoded to '
&
'.
Initial Packet Processing
The initial order of packet processing with IDP is as follows:
1.
A packet arrives at the firewall and NetDefendOS performs normal verification. If the packet is
part of a new connection then it is checked against the IP rule set before being passed to the
IDP module. If the packet is part of an existing connection it is passed straight to the IDP
system. If the packet is not part of an existing connection or is rejected by the IP rule set then it
is dropped.
2.
The source and destination information of the packet is compared to the set of IDP Rules
defined by the administrator. If a match is found, it is passed on to the next level of IDP
processing which is pattern matching, described in step below. If there is no match against an
IDP rule then the packet is accepted and the IDP system takes no further actions although
further actions defined in the IP rule set are applied such as address translation and logging.
Checking Dropped Packets
The option exists in NetDefendOS IDP to look for intrusions in all traffic, even the packets that are
rejected by the IP rule set check for new connections, as well as packets that are not part of an
existing connection. This provides the firewall administrator with a way to detect any traffic that
appears to be an intrusion. With this option the only possible IDP Rule Action is logging. Caution
should of course be exercised with this option since the processing load can be much higher when
all data packets are checked.
6.5.4. Insertion/Evasion Attack Prevention
Overview
When defining an IDP Rule, the administrator can enable or disable the option
Protect against
Insertion/Evasion attack
. An
Insertion/Evasion Attack
is a form of attack which is specifically
6.5.4. Insertion/Evasion Attack
Prevention
Chapter 6. Security Mechanisms
318