This repository has been archived by the owner on Oct 25, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathREADME
454 lines (347 loc) · 18.9 KB
/
README
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
NOTE: this tool is now outdated and is presented here for historical reasons.
FTester - Introduction and Tutorial
The Firewall Tester (ftester for friends), is a tool designed for testing
firewalls filtering policies, from version 0.6 it also includes an Intrusion
Detection System (IDS) testing feature. Basically ftester is made of a packet
generator tool (ftest) and a sniffer (ftestd), the first script injects custom
packets with a signature in the data part while the sniffer listens for such
marked packets, the comparison of the sniffer logs with the injector ones
permits the identification of firewall filtering rules. Unlike common firewall
testing tools or packet generators ftester is capable of generating network
traffic that will looks like real connections to the firewall or IDS system
tested, this feature allows us to test stateful inspection firewalls (like
netfilter or ipfilter) and IDS (like snort). Another advantage of this
architecture is that we can spoof crafted packets source address since the
sniffer knows which packets are generated by it's counterpart, some tricks
involving TTL permits the spoofing also when simulating real connections, this
is described as the 'connection spoofing mode'.
The ftester components are perl scripts so they can be executed on any platform
with a recent version of perl (at least 5.6.1 is recommended) and the three perl
modules Net::RawIP, Net::PcapUtils, NetPacket, they can be downloaded at
www.cpan.org or using the CPAN shell.
Installation is quite simple, just untar the archive ftester-X.X.tar.gz and
everything we need will be decompressed in the ftester-X.X directory, here
we'll find:
- ftest (the client-side packet generator)
- ftestd (the sniffer)
- ftest.conf (ftest example configuration file)
- freport (a script for comparing ftest and ftestd log files)
the rest is documentation (I recommend reading the man page ftester.8).
The invocation of ftest and ftestd without options will show an usage summary,
look at the documentation for a detailed explanation regarding these options and
the configuration file.
# ./ftest
Firewall Tester client v1.0
Copyright (C) 2001-2006 Andrea Barisani <[email protected]>
Configuration options:
-f <conf_file>
-c <source_ip>:<source_port>:<dest_ip>:<dest_port>:<flags>:<protocol>:<tos>
-v <verbose>
Timing options:
-d <delay, 0.25 = 250 ms>
-s <sleep time, 1 = 1 s>
Evasion options:
-e <evasion method>
-t <ids_ttl>
Connection options:
-r <reset connection>
-F <end connection>
-g <IP fragments number, es. 4|IP fragments size, es. 16b>
-p <TCP segments number, es. 4|TCP segments size, es 6b>
-k <cksum value, es. 60000>
-m <marker>
# ./ftestd
Firewall Tester sniffer v1.0
Copyright (C) 2001-2006 Andrea Barisani <[email protected]>
Configuration options:
-i <interface>
-g <fragments reassembly>
-m <marker>
-v <verbose>
Connection options:
-c <ttl1:ttl2> (ttl1 setting currently works only on Linux systems)
The definition of the packets we want to send for test if they can traverse the
firewall is mainly specified in a configuration file (usually ftest.conf), the
main syntax is:
Source Address:Source Port:Destination Address:Destination Port:Flags:Protocol:Type of Service
for TCP and UDP packets
Source Address:Source Port:Destination Address:Destination Port:Flags:ICMP:icmp_type:icmp_code
for ICMP packets
here's are a few examples:
# SYN packet to 10.1.7.1 port 80
192.168.0.10:1024:10.1.7.1:80:S:TCP:0
# PSH,ACK reply from 192.168.0.10
192.168.0.10:20:10.1.7.1:1022:AP:TCP:22
# UDP packet
192.168.0.10:53:10.1.7.1:53::UDP:0
# ICMP packet type 3 code 5
192.168.0.10::10.1.7.1:::ICMP:3:5
# ranges are allowed for source address, source port, destination port
# source address can also be specified in CIDR form
192.168.0.1-255:1024:10.1.7.1:22:S:TCP:0
192.168.0.1:1024:10.1.7.1:1-65535:S:TCP:0
192.168.0.1:1-1024:10.7.0.1:20-25:S:TCP:22
192.168.3.0/24:1-1024:10.7.0.1:20-25:S:TCP:0
192.168.0.0/22:1024:10.7.0.1:80:S:TCP:0
A stop signal is necessary for telling ftestd that our test is completed, this
can be accomplished with the following syntax:
stop_signal=192.168.0.1:666:10.1.7.1:666:S:TCP:
the stop_signal can be a TCP, UDP or ICMP packet, this packet will cause the
termination of the sniffer so every packet specified after the stop_signal
directive wont be seen by ftestd.
Let's first see it's basic usage in testing basic non-stateful firewall
filtering policies. We'll use the ftest script on a machine placed outside the
firewall and ftestd on a machine placed inside the firewall on the DMZ we want
to test (of course if we want to test outbound filtering we can reverse ftest
and ftestd placement).
----------- ------------
| Host A |----------<firewall>---------| Host B |
| (ftest) | | (ftestd) |
----------- ------------
Host A IP Address: 192.168.0.10
Host A IP Address: 10.1.7.1
Step 1:
For testing which privileged services can be reached from the outside we'll use
the following simple configuration file:
- ftest.conf -
# checking privileged ports (<1025)
192.168.0.10:1025:10.1.7.1:1-1025:S:TCP:0
# checking proxy port
192.168.0.10:1025:10.1.7.1:3128:S:TCP:0
stop_signal=192.168.0.10:80:10.1.7.1:1025:AP:TCP:0
of course we must be sure that the stop signal will reach ftestd, in this case
we've verified that the firewalled host can surf the web so a reply from port 80
should be fine.
Step 2:
Let's start as root ftestd on Host B:
[root@hostb]# ./ftestd -i eth0 -v
Let's injects the packets as root on Host A:
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01
We see an output displaying every packet sent and the ftest.log file is
created.
- ftest.log -
# ftest started on Tue Jun 4 22:37:11 CEST 2002
1 - 192.168.0.10:1025 > 10.1.7.1:1 S TCP 0
2 - 192.168.0.10:1025 > 10.1.7.1:2 S TCP 0
3 - 192.168.0.10:1025 > 10.1.7.1:3 S TCP 0
...
... (cutted for the sake of brevity)
...
1023 - 192.168.0.10:1025 > 10.1.7.1:1023 S TCP 0
1024 - 192.168.0.10:1025 > 10.1.7.1:1024 S TCP 0
1025 - 192.168.0.10:1025 > 10.1.7.1:1025 S TCP 0
1026 - 192.168.0.10:1025 > 10.1.7.1:3128 S TCP 0
1027 - 192.168.0.10:80 > 10.1.7.1:1025 PA TCP
# ftest stopped on Tue Jun 4 22:38:42 CEST 2002
On Host B ftestd shows the same messages and creates the ftestd.log file.
As we can see each packet is marked with an unique identifier (the first number
of the line) which corresponds to the packet IP ID field, this will help us for
comparing the different log files.
Step 3:
Finally we copy the two log files on the same host and we compare them using
freport:
[root@hostb]# ./freport ftest.log ftestd.log
Authorized packets:
-------------------
21 - 192.168.0.10:1025 > 10.1.7.1:21 S TCP 0
22 - 192.168.0.10:1025 > 10.1.7.1:22 S TCP 0
23 - 192.168.0.10:1025 > 10.1.7.1:23 S TCP 0
25 - 192.168.0.10:1025 > 10.1.7.1:25 S TCP 0
80 - 192.168.0.10:1025 > 10.1.7.1:80 S TCP 0
110 - 192.168.0.10:1025 > 10.1.7.1:110 S TCP 0
113 - 192.168.0.10:1025 > 10.1.7.1:113 S TCP 0
1027 - 192.168.0.10:80 > 10.1.7.1:1025 PA TCP 0
Modified packets (probably NAT):
--------------------------------
443 - 192.168.0.10:1025 > 10.1.7.1:443 S TCP 0
>>>>>>>>
443 - 192.168.0.10:1025 > 10.1.7.5:443 S TCP 0
Filtered or dropped packets:
----------------------------
1 - 192.168.0.10:1025 > 10.1.7.1:1 S TCP 0
2 - 192.168.0.10:1025 > 10.1.7.1:2 S TCP 0
3 - 192.168.0.10:1025 > 10.1.7.1:3 S TCP 0
...
... (cutted for the sake of brevity)
...
1026 - 192.168.0.10:1025 > 10.1.7.1:3128 S TCP 0
As we can see ftp,telnet,ssh,smtp,http,pop3,auth are apparently reachable from
the outside, https is forwarded to host 10.1.7.5 and the rest, including the
proxy port is filtered, of course NAT regarding the destination address can be
detected only if we sniff on a non-switched environment otherwise only port
address translation or source address translation can be detected.
The sniffing of packet 1027 (the PSH,ACK from port 80) demonstrate that we are
dealing with a simple firewall that does not perform connection tracking,
however as of today stateful inspection firewalls are more likely to be found in
real environments. Stateful inspection firewalls usually performs connection
tracking and they are not suppose to pass unmatched packets that aren't part of
a previously initiated connection, for this reason if we need to test the
filtering policies regarding PSH,ACK and moreover URG,RST,FIN packets we have to
create a real connection with the proper SYN,SYN-ACK,ACK handshake before
sending them with the correct sequence numbers, the ftestd process will send the
correct replies. However when simulating the connection if we are spoofing the
source address the stack of the destination host will reply to our spoofed
packets and the real host that we'are spoofing will consequently reset the
connection since it hasn't started it. So we have to do two things, hiding the
stack response to the spoofed host and to the firewall and make sure that ftestd
reply will traverse the firewall by not reaching the spoofed host. Hiding the
stack response could be done by setting a very low default TTL in
/proc/sys/net/ipv4/ip_default_ttl (Linux only). Hiding to the spoofed host
ftestd reply is done by setting its TTL to a low value equal to the hop delay
between ftestd and the firewall. The -s flag for ftest and the -c flag for
ftestd must be tuned for this mode, for example use ./ftestd -c 0:3 for
temporarily setting default stack ttl to 0 and ftestd reply ttl to 3, the
ip_default_ttl will be restored when a stop_signal is received.
The so called 'connection spoofing mode' can be activated with the 'connect='
prefix, let's use this mode:
- ftest.conf -
# simulating a ssh connection
connect=192.168.0.10:1025:10.1.7.1:22:AP:TCP:0
# checking unmatched RST packets
192.168.0.10:1025:10.1.7.1:23:UR:TCP:0
# checking matched RST packets
connect=192.168.0.10:1025:10.1.7.1:23:UR:TCP:0
stop_signal=192.168.0.10:1025:10.1.7.1:80:S:TCP:0
and again:
[root@hostb]# ./ftestd -i eth0 -c 0:3 -v
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1
Sent Syn Probe => 192.168.0.10:1025 > 10.1.7.1:22 S TCP
Sleeping for 1 seconds
Sent Ack Reply => 192.168.0.10:1025 > 10.1.7.1:22 A TCP
3 - 192.168.0.10:1025 > 10.1.7.1:22 AP TCP 0
5 - 192.168.0.10:1025 > 10.1.7.1:23 UR TCP 0
Sent Syn Probe => 192.168.0.10:1025 > 10.1.7.1:23 S TCP
Sleeping for 1 seconds
Sent Ack Reply => 192.168.0.10:1025 > 10.1.7.1:23 A TCP
8 - 192.168.0.10:1025 > 10.1.7.1:23 UR TCP 0
Stop packet => 192.168.0.10:1025 > 10.1.7.1:80 S TCP
note that this time ftest is configured to wait 1 second for ftestd replies.
It's useful to see what traffic we are generating using tcpdump:
[root@hostb]# tcpdump -n -v -i eth0
# the first connection
15:16:04.969929 192.168.0.10.1025 > 10.1.7.1.22: S [tcp sum ok] 18679:18687(8) win 65535 (DF) (ttl 200, id 1, len 48)
15:16:04.973880 10.1.7.1.22 > 192.168.0.10.1025: S [tcp sum ok] 19703:19703(0) ack 18687 win 65535 (DF) [tos 0x10] (ttl 200, id 1, len 40)
15:16:05.991877 192.168.0.10.1025 > 10.1.7.1.22: . [tcp sum ok] ack 1 win 65535 (DF) (ttl 200, id 2, len 40)
15:16:06.001927 192.168.0.10.1025 > 10.1.7.1.22: P [tcp sum ok] 1:16(15) ack 1 win 65535 (DF) (ttl 200, id 3, len 55)
15:16:06.012034 192.168.0.10.1025 > 10.1.7.1.22: P [tcp sum ok] 16:21(5) ack 1 win 65535 (DF) (ttl 200, id 4, len 45)
15:16:06.014798 10.1.7.1.22 > 192.168.0.10.1025: . [tcp sum ok] ack 21 win 65535 (DF) [tos 0x10] (ttl 200, id 2, len 40)
# the unmatched RST
15:16:06.023391 192.168.0.10.1025 > 10.1.7.1.23: R [tcp sum ok] 0:15(15) win 65535 urg 0 [RST ftestertcpprobe] (DF) (ttl 200, id 5, len 55)
# the second connection
15:16:06.032223 192.168.0.10.1025 > 10.1.7.1.23: S [tcp sum ok] 63848:63856(8) win 65535 (DF) (ttl 200, id 6, len 48)
15:16:06.034946 10.1.7.1.23 > 192.168.0.10.1025: S [tcp sum ok] 64872:64872(0) ack 63856 win 65535 (DF) [tos 0x10] (ttl 200, id 1, len 40)
15:16:07.051963 192.168.0.10.1025 > 10.1.7.1.23: . [tcp sum ok] ack 1 win 65535 (DF) (ttl 200, id 7, len 40)
# the correct RST
15:16:07.061863 192.168.0.10.1025 > 10.1.7.1.23: R [tcp sum ok] 63856:63871(15) win 65535 urg 0 [RST ftestertcpprobe] (DF) (ttl 200, id 8, len 55)
15:16:07.072021 192.168.0.10.1025 > 10.1.7.1.23: R [tcp sum ok] 63871:63876(5) win 65535 urg 0 [RST ackme] (DF) (ttl 200, id 9, len 45)
15:16:07.074616 10.1.7.1.23 > 192.168.0.10.1025: . [tcp sum ok] ack 21 win 65535 (DF) [tos 0x10] (ttl 200, id 2, len 40)
# the stop_signal
15:16:07.083321 192.168.0.10.1025 > 10.1.7.1.80: S [tcp sum ok] 0:11(11) win 65535 (DF) (ttl 200, id 10, len 51)
again here's the logs comparison:
[root@hostb]# ./freport ftest.log ftestd.log
Authorized packets:
-------------------
3 - 192.168.0.10:1025 > 10.1.7.1:22 PA TCP 0
8 - 192.168.0.10:1025 > 10.1.7.1:23 UR TCP 0
10 - 192.168.0.10:1025 > 10.1.7.1:80 S TCP 0
Modified packets (probably NAT):
--------------------------------
>>>>>>>>
Filtered or dropped packets:
----------------------------
5 - 192.168.0.10:1025 > 10.1.7.1:23 UR TCP 0
the first RST has been dropped this confirm that we'are probably dealing with a
stateful inspection firewall.
If more than one packet is specified with the 'connect=' prefix and the same
connection parameters (source address/port, destination address/port) the
-r/-F flags must be used to correctly close (with a RST or a FIN handshake) each
connections, otherwise, if the firewall is performing sequence numbers tracking,
connections other than the first will be blocked.
The IDS testing option permits the injection of arbitrary packets with custom
payload, using a payload that is supposed to trigger an IDS alert we can test
IDS visibility on the network and it's ability of sniffing fragmented/segmented
packets. A number of common IDS evasion techniques are also implemented for
activation during packets injection. The configuration file for this mode will
use the standard syntax with the 'ids=' and 'ids-conn=' prefixes, additionally
ftest can directly use a snort (http://www.snort.org) rule definition file
(check documentation for currently supported keywords). Here's a syntax example:
- ftest.conf -
ids=192.168.0.10:1025:10.1.7.1:25:S:TCP:0:VRFY
ids=192.168.0.10::10.1.7.1:::ICMP:3:5:+++ath
ids-conn=192.168.0.10:23:10.1.7.1:1025:PA:TCP:0:to su root
ids-conn=192.168.0.10:1025:10.1.7.1:80:PA:TCP:0:cmd.exe
ids-conn=192.168.0.10:1026:10.1.7.1:80:PA:TCP:0:ftp.exe
insert /etc/snort/exploit.rules 192.168.0.10 10.1.7.1 0
insert-conn /etc/snort/web-misc.rules 192.168.0.10 10.1.7.1 0
The '-conn' options works just like the 'connect' option, this is useful if the
IDS is performing stateful inspection, the ftestd presence is needed when using
this mode otherwise since we are only testing the IDS the sniffer is not
required.
The 'insert' option take 4 arguments, the definition file, the source address,
the destination address and the type of service.
Let's use this feature to test snort ability in eluding evasion techniques,
we'll use a common alert and we'll assume that snort is performing stateful
inspection discarding unmatched traffic.
Step 1:
The configuration file:
- ftest.conf -
ids-conn=192.168.0.1:1025:10.7.0.1:80:PA:TCP:0:cmd.exe
Step 2:
Let's start snort on our sensor:
[root@ids1] snort -A full -c /etc/snort/snort.conf -D -b -d -i eth0 -l /var/log \
-s -z
Let's start as root ftestd on Host B:
[root@hostb]# ./ftestd -i eth0 -c 0:3 -v
Let's injects the packets as root on Host A:
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F
Sent Syn Probe => 192.168.0.10:1025 > 10.1.7.1:80 S TCP
Sleeping for 1 seconds
Sent Ack Reply => 192.168.0.10:1025 > 10.1.7.1:80 A TCP
6 - 192.168.0.10:1025 > 10.1.7.1:80 PA TCP 0 "cmd.exe"
Immediately snort alerts us with the following syslog message (notice that snort
also warn us about ftest signature in the SYN packet):
Jun 5 16:25:13 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection [Classification: Unknown Traffic] [Priority: 3]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:25:14 lcars snort[4467]: [1:1002:2] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
We can repeat the process using some dirty tricks like fragmentation and evasion
techniques (see documentation for a detailed description):
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -g 2
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e stream -p 3
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e stream -p 1b
[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e desync1
and so on...
Since snort rocks it identifies correctly the triggering payload each time:
Jun 5 16:29:32 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:29:34 lcars snort[4467]: [1:1002:2] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:30:16 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:30:18 lcars snort[4467]: [1:1002:2] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:30:40 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:30:42 lcars snort[4467]: [1:1002:2] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:31:00 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
Jun 5 16:31:02 lcars snort[4467]: [1:1002:2] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
The generated log will help in clarifying what has been sent:
- ftest.log -
# ftest started on Wed Jun 5 16:25:13 CEST 2002
IDS mode >> 3 - 192.168.0.10:1025 > 10.1.7.1:80 "cmd.exe" PA TCP 0
# ftest stopped on Wed Jun 5 16:25:15 CEST 2002
# ftest started on Wed Jun 5 16:29:32 CEST 2002
IDS mode >> 3 - 192.168.0.10:1025 > 10.1.7.1:80 "cmd.exe" PA TCP 0
# ftest stopped on Wed Jun 5 16:29:35 CEST 2002
# ftest started on Wed Jun 5 16:30:16 CEST 2002
IDS mode >> 3 - 192.168.0.10:1025 > 10.1.7.1:80 "cm" PA TCP 0
IDS mode >> 4 - 192.168.0.10:1025 > 10.1.7.1:80 "d." PA TCP 0
IDS mode >> 5 - 192.168.0.10:1025 > 10.1.7.1:80 "exe" PA TCP 0
# ftest stopped on Wed Jun 5 16:30:18 CEST 2002
# ftest started on Wed Jun 5 16:30:40 CEST 2002
IDS mode >> 3 - 192.168.0.10:1025 > 10.1.7.1:80 "c" PA TCP 0
IDS mode >> 4 - 192.168.0.10:1025 > 10.1.7.1:80 "m" PA TCP 0
IDS mode >> 5 - 192.168.0.10:1025 > 10.1.7.1:80 "d" PA TCP 0
IDS mode >> 6 - 192.168.0.10:1025 > 10.1.7.1:80 "." PA TCP 0
IDS mode >> 7 - 192.168.0.10:1025 > 10.1.7.1:80 "e" PA TCP 0
IDS mode >> 8 - 192.168.0.10:1025 > 10.1.7.1:80 "x" PA TCP 0
IDS mode >> 9 - 192.168.0.10:1025 > 10.1.7.1:80 "e" PA TCP 0
# ftest stopped on Wed Jun 5 16:30:42 CEST 2002
# ftest started on Wed Jun 5 16:31:00 CEST 2002
IDS mode >> 3 - 192.168.0.10:1025 > 10.1.7.1:80 "cmd" PA TCP 0
IDS mode >> 4 - 192.168.0.10:1025 > 10.1.7.1:80 "" S TCP 0 EVASION PACKET!
IDS mode >> 5 - 192.168.0.10:1025 > 10.1.7.1:80 ".exe" PA TCP 0
# ftest stopped on Wed Jun 5 16:31:02 CEST 2002