General thought to the multiple choice questions: a couple of practicals
have come through with the multiple choice question 'what port is this' or
similar.
This is really silly. Of course one should recognize most common ports, but
if one doesn't, /etc/services (or /usr/share/nmap/nmap-services) is never
more that a command away. I would love to see questions regarding something
more substantive that the reader should have {seen|learned} in the paper.
Sorry to be so crotchety, monday morning and all ;)
Cheers,
Chris Meidinger
> -----Original Message-----
> From: intrusions-bounces@xxxxxxxxxxxxxx
> [mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of
> StevensonJA@xxxxxxx
> Sent: Saturday, May 08, 2004 9:37 PM
> To: intrusions@xxxxxxxxxxxxx
> Subject: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical
> Detect James Stevenson
>
> Hello,}
>
> This is my 3rd detect for the GCIA Practical, Any comments
> would be greatly appreciated!
>
> Many Thanks in advance,
> James Stevenson
>
>
> Trace #3: TCP Connections to port 1080,3128,8080
>
> Source of trace:
>
> This trace was extracted from the log file dated 2002.6.2
> located at incidents.org/logs/raw. This log file is available
> from the following URL:
>
> http://www.incidents.org/logs/raw/2002.6.2
>
> It's important to note that this log file has been sanitised.
> All of the IP addresses from the protected network space have
> been "munged" [1] and no information has been provided with
> regards to the network layout.
>
> Detect was generated by:
>
> This log file was generated by a Snort Intrusion Detection
> System running in binary logging mode, hence only packets
> that violate the ruleset will appear in the log. A small
> amount of time was spent interrogating the log file using
> Windump and a variety of filters, after which an interesting
> trace was eventually detected with regards to an external
> host with an IP address of 66.60.157.246. In order to analyse
> this detect accurately its imperative that we can view as
> much packet information as possible from the log file, hence
> why the following parameters were used when running Windump:
>
> windump -n -v -X -r 2002.6.2 host 66.60.157.246
>
> In addition to the -n switch (Do not resolve host addresses
> and port numbers to names), the -v switch was also used to
> increase the verbose output so that ttl and total length
> fields in each IP packet are printed. In addition, the -X
> switch was used to tell Windump to print hex and its
> associated ascii aswell. In this instance a custom filter
> file (-F <file>) has not been applied in order to show the
> exact syntax applied in this filter. This windump filter
> provided the following detect of interest:
>
> windump -n -v -X -r 2002.6.2 host 66.60.157.246
>
> 15:15:12.464488 IP (tos 0x0, ttl 48, id 14162, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum d74
> (->86c)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33239493 0> (DF)bad cksum
> 87d6 (->82ce)!
> 0x0000 4500 003c 3752 4000 3006 87d6 423c 9df6
> E..<7R@.0...B<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 0d74 0000 0204 05b4 0103 0300 ..@..t..........
> 0x0030 0101 080a 01fb 31c5 0000 0000 ......1.....
> 15:15:15.624488 IP (tos 0x0, ttl 48, id 14584, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum c48
> (->740)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33239793 0> (DF)bad cksum
> 8630 (->8128)!
> 0x0000 4500 003c 38f8 4000 3006 8630 423c 9df6
> E..<8.@.0..0B<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 0c48 0000 0204 05b4 0103 0300
> ..@..H..........
> 0x0030 0101 080a 01fb 32f1 0000 0000 ......2.....
> 15:15:18.324488 IP (tos 0x0, ttl 48, id 15021, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum b1c
> (->614)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33240093 0> (DF)bad cksum
> 847b (->7f73)!
> 0x0000 4500 003c 3aad 4000 3006 847b 423c 9df6
> E..<:.@.0..{B<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 0b1c 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 341d 0000 0000 ......4.....
> 15:15:21.284488 IP (tos 0x0, ttl 48, id 15541, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum 9f0
> (->4e8)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33240393 0> (DF)bad cksum
> 8273 (->7d6b)!
> 0x0000 4500 003c 3cb5 4000 3006 8273 423c 9df6
> E..<<.@.0..sB<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 09f0 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 3549 0000 0000 ......5I....
> 15:15:24.284488 IP (tos 0x0, ttl 48, id 16013, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum 8c4
> (->3bc)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33240693 0> (DF)bad cksum
> 809b (->7b93)!
> 0x0000 4500 003c 3e8d 4000 3006 809b 423c 9df6
> E..<>.@.0...B<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 08c4 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 3675 0000 0000 ......6u....
> 15:15:27.284488 IP (tos 0x0, ttl 48, id 16475, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum 798
> (->290)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33240993 0> (DF)bad cksum
> 7ecd (->79c5)!
> 0x0000 4500 003c 405b 4000 3006 7ecd 423c 9df6
> E..<@[@.0.~.B<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 0798 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 37a1 0000 0000 ......7.....
> 15:15:33.354488 IP (tos 0x0, ttl 48, id 17278, len 60)
> 66.60.157.246.2312 > 46.5.130.100.1080: S [bad tcp cksum 540
> (->38)!] 4218369424:4218369424(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33241593 0> (DF)bad cksum
> 7baa (->76a2)!
> 0x0000 4500 003c 437e 4000 3006 7baa 423c 9df6
> E..<C~@.0.{.B<..
> 0x0010 2e05 8264 0908 0438 fb6f 3590 0000 0000
> ...d...8.o5.....
> 0x0020 a002 4000 0540 0000 0204 05b4 0103 0300
> ..@..@..........
> 0x0030 0101 080a 01fb 39f9 0000 0000 ......9.....
> 15:15:36.324488 IP (tos 0x0, ttl 48, id 17726, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 48ce
> (->43c6)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33241894 0> (DF)bad cksum
> 79ea (->74e2)!
> 0x0000 4500 003c 453e 4000 3006 79ea 423c 9df6
> E..<E>@.0.y.B<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 48ce 0000 0204 05b4 0103 0300
> ..@.H...........
> 0x0030 0101 080a 01fb 3b26 0000 0000 ......;&....
> 15:15:39.454488 IP (tos 0x0, ttl 48, id 18146, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 47a2
> (->429a)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33242194 0> (DF)bad cksum
> 7846 (->733e)!
> 0x0000 4500 003c 46e2 4000 3006 7846 423c 9df6
> E..<F.@.0.xFB<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 47a2 0000 0204 05b4 0103 0300
> ..@.G...........
> 0x0030 0101 080a 01fb 3c52 0000 0000
> ......<R....
> 15:15:42.324488 IP (tos 0x0, ttl 48, id 18519, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 4676
> (->416e)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33242494 0> (DF)bad cksum
> 76d1 (->71c9)!
> 0x0000 4500 003c 4857 4000 3006 76d1 423c 9df6
> E..<HW@.0.v.B<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 4676 0000 0204 05b4 0103 0300
> ..@.Fv..........
> 0x0030 0101 080a 01fb 3d7e 0000 0000 ......=~....
> 15:15:45.304488 IP (tos 0x0, ttl 48, id 18902, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 454a
> (->4042)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33242794 0> (DF)bad cksum
> 7552 (->704a)!
> 0x0000 4500 003c 49d6 4000 3006 7552 423c 9df6
> E..<I.@.0.uRB<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 454a 0000 0204 05b4 0103 0300
> ..@.EJ..........
> 0x0030 0101 080a 01fb 3eaa 0000 0000
> ......>.....
> 15:15:48.304488 IP (tos 0x0, ttl 48, id 19290, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 441e
> (->3f16)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33243094 0> (DF)bad cksum
> 73ce (->6ec6)!
> 0x0000 4500 003c 4b5a 4000 3006 73ce 423c 9df6
> E..<KZ@.0.s.B<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 441e 0000 0204 05b4 0103 0300
> ..@.D...........
> 0x0030 0101 080a 01fb 3fd6 0000 0000 ......?.....
> 15:15:51.294488 IP (tos 0x0, ttl 48, id 19681, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 42f2
> (->3dea)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33243394 0> (DF)bad cksum
> 7247 (->6d3f)!
> 0x0000 4500 003c 4ce1 4000 3006 7247 423c 9df6
> E..<L.@.0.rGB<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 42f2 0000 0204 05b4 0103 0300
> ..@.B...........
> 0x0030 0101 080a 01fb 4102 0000 0000 ......A.....
> 15:15:57.394488 IP (tos 0x0, ttl 48, id 20410, len 60)
> 66.60.157.246.3013 > 46.5.130.100.1080: S [bad tcp cksum 409a
> (->3b92)!] 2268160598:2268160598(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33243994 0> (DF)bad cksum
> 6f6e (->6a66)!
> 0x0000 4500 003c 4fba 4000 3006 6f6e 423c 9df6
> E..<O.@.0.onB<..
> 0x0010 2e05 8264 0bc5 0438 8731 6256 0000 0000
> ...d...8.1bV....
> 0x0020 a002 4000 409a 0000 0204 05b4 0103 0300
> ..@.@...........
> 0x0030 0101 080a 01fb 435a 0000 0000 ......CZ....
> 15:16:48.404488 IP (tos 0x0, ttl 48, id 27951, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum 737
> (->22f)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33249097 0> (DF)bad cksum
> 51f9 (->4cf1)!
> 0x0000 4500 003c 6d2f 4000 3006 51f9 423c 9df6
> E..<m/@.0.Q.B<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 0737 0000 0204 05b4 0103 0300
> ..@..7..........
> 0x0030 0101 080a 01fb 5749 0000 0000 ......WI....
> 15:16:51.384488 IP (tos 0x0, ttl 48, id 28337, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum 60b
> (->103)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33249397 0> (DF)bad cksum
> 5077 (->4b6f)!
> 0x0000 4500 003c 6eb1 4000 3006 5077 423c 9df6
> E..<n.@.0.PwB<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 060b 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 5875 0000 0000 ......Xu....
> 15:16:54.344488 IP (tos 0x0, ttl 48, id 28724, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum 4df
> (->ffd6)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33249697 0> (DF)bad cksum
> 4ef4 (->49ec)!
> 0x0000 4500 003c 7034 4000 3006 4ef4 423c 9df6
> E..<p4@.0.N.B<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 04df 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 59a1 0000 0000
> ......Y.....
> 15:16:57.394488 IP (tos 0x0, ttl 48, id 29128, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum 3b3
> (->feaa)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33249997 0> (DF)bad cksum
> 4d60 (->4858)!
> 0x0000 4500 003c 71c8 4000 3006 4d60 423c 9df6
> E..<q.@.0.M`B<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 03b3 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 5acd 0000 0000 ......Z.....
> 15:17:00.334488 IP (tos 0x0, ttl 48, id 29518, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum 287
> (->fd7e)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33250297 0> (DF)bad cksum
> 4bda (->46d2)!
> 0x0000 4500 003c 734e 4000 3006 4bda 423c 9df6
> E..<sN@.0.K.B<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 0287 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 5bf9 0000 0000
> ......[.....
> 15:17:03.344488 IP (tos 0x0, ttl 48, id 29884, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum 15b
> (->fc52)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33250597 0> (DF)bad cksum
> 4a6c (->4564)!
> 0x0000 4500 003c 74bc 4000 3006 4a6c 423c 9df6
> E..<t.@.0.JlB<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 015b 0000 0204 05b4 0103 0300
> ..@..[..........
> 0x0030 0101 080a 01fb 5d25 0000 0000 ......]%....
> 15:17:09.434488 IP (tos 0x0, ttl 48, id 30606, len 60)
> 66.60.157.246.4860 > 46.5.130.100.3128: S [bad tcp cksum ff02
> (->f9fa)!] 4216456306:4216456306(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33251197 0> (DF)bad cksum
> 479a (->4292)!
> 0x0000 4500 003c 778e 4000 3006 479a 423c 9df6
> E..<w.@.0.G.B<..
> 0x0010 2e05 8264 12fc 0c38 fb52 0472 0000 0000
> ...d...8.R.r....
> 0x0020 a002 4000 ff02 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 5f7d 0000 0000 ......_}....
> 15:18:24.414488 IP (tos 0x0, ttl 48, id 40021, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum f63f
> (->f137)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33258701 0> (DF)bad cksum
> 22d3 (->1dcb)!
> 0x0000 4500 003c 9c55 4000 3006 22d3 423c 9df6
> E..<.U@.0.".B<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 f63f 0000 0204 05b4 0103 0300
> ..@..?..........
> 0x0030 0101 080a 01fb 7ccd 0000 0000 ......|.....
> 15:18:27.554488 IP (tos 0x0, ttl 48, id 40397, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum f513
> (->f00b)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33259001 0> (DF)bad cksum
> 215b (->1c53)!
> 0x0000 4500 003c 9dcd 4000 3006 215b 423c 9df6
> E..<..@.0.![B<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 f513 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 7df9 0000 0000 ......}.....
> 15:18:30.444488 IP (tos 0x0, ttl 48, id 40757, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum f3e7
> (->eedf)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33259301 0> (DF)bad cksum
> 1ff3 (->1aeb)!
> 0x0000 4500 003c 9f35 4000 3006 1ff3 423c 9df6
> E..<.5@.0...B<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 f3e7 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 7f25 0000 0000 .......%....
> 15:18:33.474488 IP (tos 0x0, ttl 48, id 41136, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum f2bb
> (->edb3)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33259601 0> (DF)bad cksum
> 1e78 (->1970)!
> 0x0000 4500 003c a0b0 4000 3006 1e78 423c 9df6
> E..<..@.0..xB<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 f2bb 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 8051 0000 0000
> .......Q....
> 15:18:36.434488 IP (tos 0x0, ttl 48, id 41538, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum f18f
> (->ec87)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33259901 0> (DF)bad cksum
> 1ce6 (->17de)!
> 0x0000 4500 003c a242 4000 3006 1ce6 423c 9df6
> E..<.B@.0...B<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 f18f 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 817d 0000 0000 .......}....
> 15:18:39.404488 IP (tos 0x0, ttl 48, id 41899, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum f063
> (->eb5b)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33260201 0> (DF)bad cksum
> 1b7d (->1675)!
> 0x0000 4500 003c a3ab 4000 3006 1b7d 423c 9df6
> E..<..@.0..}B<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 f063 0000 0204 05b4 0103 0300
> ..@..c..........
> 0x0030 0101 080a 01fb 82a9 0000 0000 ............
> 15:18:45.404488 IP (tos 0x0, ttl 48, id 42614, len 60)
> 66.60.157.246.2550 > 46.5.130.100.8080: S [bad tcp cksum ee0b
> (->e903)!] 1727560173:1727560173(0) win 16384 <mss
> 1460,nop,wscale 0,nop,nop,timestamp 33260801 0> (DF)bad cksum
> 18b2 (->13aa)!
> 0x0000 4500 003c a676 4000 3006 18b2 423c 9df6
> E..<.v@.0...B<..
> 0x0010 2e05 8264 09f6 1f90 66f8 79ed 0000 0000
> ...d....f.y.....
> 0x0020 a002 4000 ee0b 0000 0204 05b4 0103 0300
> ..@.............
> 0x0030 0101 080a 01fb 8501 0000 0000 ............
>
> Although there is no information regarding the location or
> configuration of this Snort device, we are able to speculate
> what Snort rules triggered these alerts. Based upon detailed
> analysis, this detect was most likely triggered by a
> combination of the following rules:
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 1080 (msg:"SCAN
> SOCKS Proxy attempt"; stateless; flags:S,12;
> reference:url,help.undernet.org/proxyscan/;
> classtype:attempted-recon; sid:615; rev:5;)
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 3128 (msg:"SCAN
> Squid Proxy attempt"; stateless; flags:S,12;
> classtype:attempted-recon; sid:618; rev:5;)
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 8080 (msg:"SCAN
> Proxy Port 8080 attempt"; stateless; flags:S,12;
> classtype:attempted-recon; sid:620; rev:6;)
>
> All three rules are designed to detect any external host
> sending a TCP-SYN packet (as defined in the snort.conf file),
> in an attempt to initiate a TCP connection with the protected
> destination host over ports 1080,3128 and 8080 respectively.
>
> Probability source address was spoofed:
>
> It is considered unlikely that the source address was
> spoofed. This logged activity most likely represents an
> attacker conducting network reconnaissance, specifically
> searching for open proxy servers on TCP ports 1080, 3128 and
> 8080. In order for this reconnaissance activity to be of any
> use, it's vital that the response from the target host is
> sent back to the attacking host. On this basis if the
> attacker spoofed the source address, the response (if any)
> from the target host would be sent back to the spoofed
> address and not the attackers.
>
> With this logic now established we are able to gather some
> intelligence regarding the attacking source IP. Performing a
> Whois query using Sam Spade provided the following information:
>
> Trying 66.60.157.246 at ARIN
> Trying 66.60.157 at ARIN
>
> OrgName: Surewest Internet
> OrgID: SURW
> Address: P.O. Box 969
> City: Roseville
> StateProv: CA
> PostalCode: 95678
> Country: US
>
> NetRange: 66.60.128.0 - 66.60.191.255
> CIDR: 66.60.128.0/18
> NetName: SUREWEST-INTERNET
> NetHandle: NET-66-60-128-0-1
> Parent: NET-66-0-0-0-0
> NetType: Direct Allocation
> NameServer: NS1.SUREWEST.NET
> NameServer: NS2.SUREWEST.NET
>
> While an nslookup query against the attacking IP provided the
> following information:
>
> nslookup 66.60.157.246
> Canonical name: 246.157-60-66-fuji-dsl.static.surewest.net
>
> Based upon this information we are able to determine that an
> ISP named Surewest provides the IP address assigned to the
> attacker. Furthermore, based upon the Canonical name provided
> by the nslookup query, we can be confident that Surewest
> provides high-speed Internet connections, one of which is
> utilised by the attacker. Surewest's website confirms the
> availability of high-speed connections
> http://www.surewestbroadband.com.
>
> What is interesting is that the attacker appears to have
> utilised a static IP address. If a victim were to trace an
> attack back to the source, the process of contacting the ISP
> with attack information is made somewhat easier if a static
> IP is involved, since its usually assigned to a specific
> user. There is a possibility however that the source address
> in this instance has been compromised and is being used as
> platform to launch attacks against other hosts including
> ours. This is a common tactic employed by many in an attempt
> to prevent anyone tracing an attack back to its true origin.
> On this basis we may find the true attacker is hiding behind
> multiple hosts in an attempt to minimise the risk of being
> traced. Many attackers prefer to use dial-up accounts because
> they're cheaper, readily available and will only be assigned
> a temporary address from a large IP pool when they dial-up.
> Since the probability of an attacker being assigned the same
> IP address twice (within a medi um timeframe) is minimal,
> the chance of a victim correlating attacks from an array of
> IP's to one specific user is extremely unlikely. Furthermore,
> if an attack was relatively aggressive, the victim may
> subsequently block the source IP (whether through an
> automated or manual process) at their border routers etc.
> Since it would be impractical for the victim to block the
> entire ISP netrange, the attacker only needs to Dial-up again
> to obtain a different IP address in order to continue their
> malicious activity.
>
> Description of attack:
>
> This detect represents an attackers reconnaissance technique
> in the form of port scanning in search for specific proxy
> servers, namely:
>
> 1080/tcp (SOCKS Proxy)
> 3128/tcp (Squid Proxy)
> 8080/tcp (Proxy)
>
> This attacker like many others in the wild are attempting to
> discover live hosts potentially running common proxy
> services. The discovery of a miss-configured proxy server
> could be exploited to the extent that its used as a platform
> to launch attacks, thus any attack would appear to originate
> from the compromised proxy host rather than the attackers
> true source address. In a sense the attacker is hiding behind
> another IP address to obfuscate the true attack source, or to
> remain anonymous when conducting other illegitimate
> activities. Additionally, if the compromised proxy is
> situated behind a firewall, it could potentially be used to
> gain further access to the network from which it resides.
>
> Port scanning from a generalised perspective is not uncommon
> and is one of the most popular techniques an attacker uses to
> discover listening hosts and services. Port scanning activity
> can be loosely defined into three categories, Horizontal
> Scanning (many hosts targeted looking for few services on
> each), Vertical Scanning (few hosts targeted looking for
> multiple services on each) or Block Scanning (many hosts many
> services). By correlating the log evidence available in this
> detect, combined with these established scanning definitions
> we can class the attack in this instance as a vertical scan.
>
> Based on the log evidence alone we can only speculate that
> the attacker was performing network reconnaissance in an
> attempt to find listening proxy services. On this basis there
> are no specific CVE entries that suggest the above proxy
> services are vulnerable to simple SYN connection requests.
> There is however a variety of exploitable vulnerabilities
> with regards to specific proxy services if the attacker was
> so inclined to discover and exploit them. Since we are
> unaware of the attackers exact intentions and attack vectors
> available in his/her arsenal, it would be impractical in this
> case to explore and explain all vulnerabilities related to
> all proxy services. To summarise, this attack only represents
> a reconnaissance effort with no immediate threat, however,
> this activity should not be ignored on these grounds because
> reconnaissance activities are usually a precursor to more
> intrusive attacks.
>
> Attack Mechanism:
>
> In this detect, the attacker specifically targeted
> 46.5.130.100 and sent multiple SYN packets to TCP ports
> 1080,3128 and 8080. The duration of the scan occurred between
> the timestamps of 15:15:12 and 15:18:45, during which 28 SYN
> packets were captured in total.
>
> By analyzing all available log data, it appears the attacker
> failed to discover any listening proxy services running on
> the target. A target host listening on these ports would
> reply with a SYN-ACK packet once the SYN packet was received.
> The fact that there was no such response would explain why
> the attacker sent multiple SYN packets. The use of a static
> source port and initial sequence number (ISN) for each
> connection attempt would also confirm no response was
> established. For example: Each SYN packet sent to port
> 8080/tcp had a static source port of 2550 and ISN of
> 1727560173 as printed on the windump filter below:
>
> windump -n -r 2002.6.2 host 66.60.157.246 and port 8080
>
> 15:18:24.414488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33258701 0> (DF)
> 15:18:27.554488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33259001 0> (DF)
> 15:18:30.444488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33259301 0> (DF)
> 15:18:33.474488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33259601 0> (DF)
> 15:18:36.434488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33259901 0> (DF)
> 15:18:39.404488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33260201 0> (DF)
> 15:18:45.404488 IP 66.60.157.246.2550 > 46.5.130.100.8080: S
> 1727560173:1727560173(0) win 16384 <mss 1460,nop, wscale
> 0,nop,nop,timestamp 33260801 0> (DF)
> 28
>
> In addition, 7 SYN packets in total were sent within 21
> seconds before eventually giving up. After the first SYN
> packet was sent, the source host waited 3 seconds for a
> SYN-ACK response. Since there was no such response, another
> SYN packet was sent automatically using the same source port
> and ISN as previous. All of these factors most likely
> indicate an automated process that occurred because a
> connection could not be established. A similar process also
> occurred with connection attempts to both 1080 and 3128. It
> would appear that the attacker was reluctant to give up and
> move on to other potential targets.
>
> There are a number of possibilities why the desired SYN-ACK
> response was not detected. Firstly, it's possible that the
> host is currently offline. Maybe the attacker knows the
> existence of proxy services on this host, but is unaware of
> its current status. That would explain why the attacker was
> persistent and specifically targeted this host rather than
> conducting a horizontal scan across the entire network.
> Secondly, it's possible that the targets firewall and/or
> border routers have IP filtering/ACL policies in place that
> subsequently dropped the SYN packets before they even arrived
> at the target host. Finally, it's possible the target host
> was live, but responded with a RST packet because it was not
> listening on these ports. Since we didn't detect any reply
> from the target host we could assume that a firewall or
> router blocked such a response. This action is common to
> prevent attackers gaining information based upon response
> type, which in-turn can provide key hints
> with regards to a hosts current status, potential services
> running or OS type etc. All such information would be used to
> collate a profile of the potential victim(s) and perimeter
> defenses before an attacking strategy can be implemented.
>
> By investigating the TTL field within each packet we could
> determine the OS probably running on the source (although not
> 100% accurate). By reviewing our complete detect we can see
> that every packet had a TTL value of 48. This most likely
> means that the packet had to traverse over 16 hops to reach
> the target host, thus the original TTL value was 64. On this
> basis we could speculate that the packet was sent from a
> linux or freeBSD box. We can further increase the probability
> of discovering the OS type by investigating the set window
> size in each packet. All packets in this detect have a window
> size of 16384, by default the following OS set this window
> size: FreeBSD, and Windows 2000. Since Windows 2000 sets the
> TTL value to 128 not 64 we could speculate that the source is
> most likely running FreeBSD. Again I must emphasize that this
> is based upon probability and is not 100% accurate,
> especially since the default TTL value can be configured and
> even spoofed.
>
> An article on Passive OS fingerprinting (p0f) detailing TTL
> and Windows size values as per OS type can be viewed here:
>
> http://www.stearns.org/p0f/devel/p0f.fp
>
> The last question to address is what tool was the attacker
> using to aid in the search for open proxies on ports
> 1080,3128 and 8080? In all probability, the attacker
> conducted the scan with the assistance of a port-scanning
> tool rather than conducting the reconnaissance on a manual
> basis (certainly the slower alternative). A popular
> port-scanning tool such as Nmap is most likely, but really
> any scanning tool that can identify remote hosts listening on
> these ports could be used.
>
> Correlations:
>
> This scan type is not uncommon, while the reports of such
> activity have been logged for quite some time now. Scanning
> activity for 1080/tcp has only recently been knocked off the
> www.Incidents.org Top Ten List, however, it will most likely
> regain a position in this chart due to its sporadic nature.
>
> The use of open proxy servers is so popular that many sites
> provide and maintain a list of known open proxies to use.
> Some sites claim to provide legitimate proxy services for all
> that require it:
>
> http://theproxyconnection.com/httplist.html
>
> With sites such as this you can become a proxy member that
> provides you with a list of proxies available for use at any
> time. An example of another site providing a list of
> anonymous proxy severs can be seen here:
>
> http://www.multiproxy.org/
>
> Whether these sites are really legitimate is another
> question, however, sites do exist that illegally scan the
> Internet for open proxy servers. It is possible that the
> attacker in this detect is attempting to maintain a list of
> open proxy servers for sites such as this or for private use.
>
> Finally, many fellow GCIA participants have provided detailed
> analysis on proxy scanning activity. Although a multitude of
> detects exist, one example of such analysis can be seen here:
>
> http://cert.uni-stuttgart.de/archive/intrusions/2003/11/msg00053.html
>
> Evidence of active targeting:
>
> Based upon log evidence alone one could assume that this
> attacker actively targeted the host located at 46.5.130.100.
> However, it's possible that additional scans have targeted
> hosts not monitored by this snort device, or have been
> conducted over a time period not contained within our log
> file. A larger selection of logs would need to be obtained
> for this to be confirmed. It's highly unlikely that an
> attacker with malicious intent would rely purely on one proxy
> server, because most have a reputation for maintaining a list
> of multiple proxies to abuse. With this in mind its entirely
> possible that this detect only represents a small part of the
> complete scanning, maintenance and discovery process.
>
> Severity:
>
> The severity of this detect is calculated using the following formula:
>
> (Criticality + Lethality) - (System Countermeasures + Network
> Countermeasures)
>
> Criticality = 1
>
> Since there is no information regarding network topology or
> services running on this host we are unable to provide an
> accurate criticality rating. Analysing the log file shows no
> evidence of the target host conducting activity on any port.
> This was confirmed by the following filter windump -n -r
> 2002.6.2 host 46.5.130.100. Only SYN packets from the
> attacking source were printed on this filter. Without knowing
> what traffic this host sends and receives makes it impossible
> to speculate what services are running, thus will be rated as
> a non-critical system.
>
> Lethality = 2
>
> The scanning activity itself is not destructive in nature,
> however, this reconnaissance activity is usually a precursor
> to a more intrusive attack. If a follow-on exploit were
> successful the attacker would be able to conduct a variety of
> illegitimate activities from anonymous web surfing to using
> the host as a launch pad for successive attacks against other
> hosts. Although the potential lethality is rated at level
> 3-4, the actual potential of reconnaissance activity itself
> should only be rated at level 2.
>
> System Countermeasures = 3
>
> As we are unaware of the target systems response to the
> multiple SYN packets, we are unable to confirm whether it's
> running a proxy service on TCP ports 1080,3128 or 8080. In
> addition, we are also unable to determine if the host is
> allowing unauthorised access if it is indeed running a proxy
> service. In this situation it's best to play it safe and
> provide and average score of 3. This will at least imply that
> improvements can be made to booster system countermeasures.
>
> Network Countermeasures =3
>
> The fact that a Snort device detected this attack proves the
> network does at least have minimal defence mechanisms in
> place. Since there was no response from the target we could
> assume that either the host is down, or any SYN-ACK responses
> from the target is being blocked by the upstream routers
> (assuming a service is running on these ports). It is of
> course possible that these SYN packets never reached the
> target host because they were dropped by ACL's present on the
> border router. This is all speculation, but all theories
> point to some form of defence mechanism in place. As there is
> limited information with regards to network topology, while
> working on the basis that something can always be done to
> strengthen your network security stance, a modest 3 will be awarded.
>
> Total Score = -3
>
> Defensive recommendation:
>
> Since the attacker failed to find any listening proxy
> services on the target host its highly likely the attacker
> moved on in search for less protected networks. Nevertheless,
> aim to be proactive rather than reactive. Ensure that any
> legitimate proxy servers are running fully patched and have
> been security audited to confirm that unauthorized access is
> not permitted from the external network. Achieve this via
> properly configured firewalls and routers and utilize strong
> authentication and encryption to reduce the risk of
> compromise. If you are not running any form of proxy server
> ensure that your routers and firewalls are configured to drop
> any traffic destined for TCP ports 1080,3128 and 8080.
>
> Multiple Choice Question:
>
> What service is commonly run on TCP port 3128?
>
> (a) SOCKS
> (b) Telnet
> (c) SQUID
> (d) ALT HTTP
> (e) SMTP
>
> The correct answer is (c). The Squid Proxy service is
> commonly run on TCP port 3128.
>
> Part II Trace 3 References:
>
> [1] http://www.incidents.org/logs/
> [2] http://www.snort.org/snort-db/sid.html?sid=615
> [3] http://www.snort.org/snort-db/sid.html?sid=618
> [4] http://www.snort.org/snort-db/sid.html?sid=620
> [5] http://project.honeynet.org/papers/finger/
> [6]
> http://www.dshield.org/pipermail/intrusions/2002-October/005636.php
> [7] http://windump.polito.it/docs/manual.htm
> [8] http://www.insecure.org/nmap/
> [9]
> http://cert.uni-stuttgart.de/archive/intrusions/2003/11/msg00053.html
> _______________________________________________
> Intrusions mailing list
> Intrusions@xxxxxxxxxxxxxx
> http://www.dshield.org/mailman/listinfo/intrusions
>
_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions
|