[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Lindsay van Eden
Lindsay van Eden
lindsay at issecurity.co.za
Fri Jul 9 14:05:48 GMT 2004
Network Detect 1 - TCP Destination Port 0
[**] [1:524:7] BAD-TRAFFIC tcp port 0 traffic [**]
[Classification: Misc activity] [Priority: 3]
07/16-19:11:40.464488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 len:0x42
211.47.255.22:40844 -> 46.5.214.181:0 TCP TTL:47 TOS:0x0 ID:0 IpLen:20
DgmLen:52 DF
******S* Seq: 0xADA02A9A Ack: 0x0 Win: 0x16D0 TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
07/16-19:11:40.464488 211.47.255.22:40844 -> 46.5.214.181:0
TCP TTL:47 TOS:0x0 ID:0 IpLen:20 DgmLen:52 DF
******S* Seq: 0xADA02A9A Ack: 0x0 Win: 0x16D0 TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
1. Source of Trace
The raw log analyzed within this section was obtained from
http://www.incidents.org/logs/raw/2002.6.16, with the following actions
taken in determining the network layout, source and type of attack.
Viewing of trace file and overview of expressions used:
tcpdump -neqr 2002.6.16 -c 2
02:05:05.884488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 294: 61.83.144.42.1463 >
46.5.180.133.http: tcp 240 (DF)
02:05:06.874488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 419: 61.83.144.42.1467 >
46.5.180.133.http: tcp 365 (DF)
tcpdump -ner 2002.6.16 |more
02:05:05.884488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 294: 61.83.144.42.1463
> 46.5.180.133.http: P 3698072451:3698072691(240) ack 3357659451 win
16824 (DF)
02:05:06.874488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 419: 61.83.144.42.1467
> 46.5.180.133.http: P 3698689090:3698689455(365) ack 3351137157 win
17520 (DF)
-n No name resolution.
-e Print link-level header on each dump line.
-q Quick output.
-r Read packets from file <name>
-c Count
Captured MAC addresses:
tcpdump -ner 2002.6.16 |gawk '{print $2}' |sort -u
0:0:c:4:b2:33
0:3:e3:d9:26:c0
cut -d Remove delimitated sections
from each line
sort Sort lines from output
gawk '{print$2}' Pattern scanning and printing of
second variable.
OUI Registration:
http://standards.ieee.org/cgi-bin/ouisearch
00-03-E3 (hex) Cisco Systems, Inc.
0003E3 (base 16) Cisco Systems, Inc.
00-00-0C (hex) CISCO SYSTEMS, INC.
00000C (base 16) CISCO SYSTEMS, INC.
Associated addresses of MAC 0:3:e3:d9:26:c0:
tcpdump -neqr 2002.6.16 ether src 0:3:e3:d9:26:c0 |awk '{print $5}' |sort -u
12.107.51.109.http
12.36.134.2.http
128.102.196.25.39572
128.167.120.16.http
128.242.213.251.http
129.186.1.198.ftp-data
12.96.216.4.8276
134.180.228.45.44326
<truncated>
Traffic going to MAC 0:3:e3:d9:26:c0:
tcpdump -neqr 2002.6.16 ether src 0:3:e3:d9:26:c0 |awk '{print $7}' |
awk -F \. '{print $1 "." $2 "." $3 "." $4}' |sort -u
46.5.0.245
46.5.100.65
46.5.101.240
46.5.102.170
46.5.10.23
46.5.103.183
46.5.104.38
46.5.110.39
<truncated>
tcpdump -neqr 2002.6.16 ether src 0:3:e3:d9:26:c0 |awk '{print $7}' |
awk -F \. '{print $1 "." $2 "." $3 "." $4}' |sort -u | wc -l
142
Associated addresses of MAC 0:0:c:4:b2:33:
tcpdump -neqr 2002.6.16 ether dst 0:0:c:4:b2:33 |awk '{print $7}' |sort -u
46.5.0.245.http:
46.5.100.65.printer:
46.5.101.240.http:
46.5.102.170.domain:
46.5.10.23.printer:
46.5.103.183.domain:
46.5.104.38.http:
46.5.110.39.http:
46.5.11.16.printer:
46.5.113.74.http:
46.5.113.85.http:
<truncated>
Traffic going to MAC 0:0:c:4:b2:33
tcpdump -neqr 2002.6.16 ether src 0:0:c:4:b2:33 |awk '{print $7}' | awk
-F \. '{print $1 "." $2 "." $3 "." $4}' |sort -u
12.232.96.61
12.252.53.145
12.5.136.100
130.166.151.185
134.96.234.34
141.35.14.47
146.145.124.89
156.143.35.241
159.43.254.50
194.225.40.7
194.67.23.251
194.67.35.196
195.209.49.241
<truncated>
tcpdump -neqr 2002.6.16 ether src 0:0:c:4:b2:33 |awk '{print $7}' | awk
-F \. '{print $1 "." $2 "." $3 "." $4}' |sort -u | wc -l
99
Based on the above findings, it would seem that 0:0:c:4:b2:33 has a
consistent /16 range of addresses associated to it, while
0:3:e3:d9:26:c0 has a number of inconsistent or random addresses. Thus
I conclude that the 46.5.0.0/16 network is the monitored range with the
latter being external.
Un-trusted Network------External Cisco Device----|-------- Perimeter Cisco Device--------Monitored Network
0:3:e3:d9:26:c0 | 0:0:c:4:b2:33
|
Snort
While reviewing the type of traffic captured, I noticed an interesting
port and subsequently determined it was an incoming Syn to destination
port 0:
tcpdump -nnr 2002.6.16 | awk '{print $2 "\n"$4}' | awk -F \. '{print
$5}' | awk -F : '{print $1}' | sort -u | awk '{if ($1<=1023) print $1}'
0
20
21
443
515
53
80
tcpdump -ner 2002.6.16 dst port 0
19:11:40.464488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 66: 211.47.255.22.40844
> 46.5.214.181.0: S 2912955034:2912955034(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
19:11:43.444488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 66: 211.47.255.22.40844
> 46.5.214.181.0: S 2912955034:2912955034(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
19:11:49.354488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 66: 211.47.255.22.40844
> 46.5.214.181.0: S 2912955034:2912955034(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
19:12:01.534488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 66: 211.47.255.22.40844
> 46.5.214.181.0: S 2912955034:2912955034(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
<truncated>
2. Detect was generated by:
The raw log was read by Snort Version 2.1.3.RC1 (Build 26), rules last
modified June 19, 2004. No changes where made to the snort.conf file
other than specifying the HOME_NET as 46.5.0.0/16.
Alerts where generated with the following variables:
snort -c snort.conf -dek none -r 2002.6.16 -l snortdump -q
-c <rules> Use Rules File <rules>
-d Dump the Application Layer
-e Display the second layer header info
-k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none)
-r <tf> Read and process tcpdump file <tf>
-l <ld> Log to directory <ld>
-q Quiet. Don't show banner and status
report
[**] [1:524:7] BAD-TRAFFIC tcp port 0 traffic [**]
[Classification: Misc activity] [Priority: 3]
07/16-19:11:40.464488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 len:0x42
211.47.255.22:40844 -> 46.5.214.181:0 TCP TTL:47 TOS:0x0 ID:0 IpLen:20
DgmLen:52 DF
******S* Seq: 0xADA02A9A Ack: 0x0 Win: 0x16D0 TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
[**] [1:524:7] BAD-TRAFFIC tcp port 0 traffic [**]
[Classification: Misc activity] [Priority: 3]
07/16-19:11:43.444488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 len:0x42
211.47.255.22:40844 -> 46.5.214.181:0 TCP TTL:47 TOS:0x0 ID:0 IpLen:20
DgmLen:52 DF
******S* Seq: 0xADA02A9A Ack: 0x0 Win: 0x16D0 TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
[**] [1:524:7] BAD-TRAFFIC tcp port 0 traffic [**]
[Classification: Misc activity] [Priority: 3]
07/16-19:11:49.354488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 len:0x42
211.47.255.22:40844 -> 46.5.214.181:0 TCP TTL:47 TOS:0x0 ID:0 IpLen:20
DgmLen:52 DF
******S* Seq: 0xADA02A9A Ack: 0x0 Win: 0x16D0 TcpLen: 32
TCP Options (6) => MSS: 1460 NOP NOP SackOK NOP WS: 0
Explanation of alert:
[**] [1:524:7] BAD-TRAFFIC tcp port 0 traffic [**]
Snort ID or SID and message
[Classification: Misc activity] [Priority: 3]
Classification and Severity
07/16-19:11:49.354488
Date and time of alert
0:3:E3:D9:26:C0 Source MAC address
0:0:C:4:B2:33
Destination MAC address
type:0x800
Encapsulating protocol Type IP
len:0x42
Length of frame 66 Bytes
211.47.255.22
Source address
40844
Source port
46.5.214.181
Destination address
0
Destination port
TCP
Protocol type TCP
TTL:47
IP Time to live
TOS:0x0
IP type of service
ID:0
IP Identification value
IpLen:20
IP Header length
DgmLen:52
Total datagram length
DF
Do not fragment bit set
******S* SYN flag set
Seq: 0xADA02A9A Hex Sequence Number
Ack: 0x0
Ack not set
Win: 0x16D0
Window Size 5840
TcpLen: 32
TCP header length
TCP Options (6)
6 TCP options set
=> MSS: 1460
Maximum Segment Size
NOP NOP
No operation
SackOK
Selective Ack permitted
NOP
No operation
WS: 0
Window scale 0
The following rule generated SID number 524, which can be found under
$Snort/rules/bad-traffic.rules. SID 524 documentation can be viewed at
http://www.snort.org/snort-db/sid.html?sid=524
SID 524 Message BAD-TRAFFIC tcp port 0 traffic Signature alert tcp
$EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC tcp port 0 traffic";
flow:stateless; classtype:misc-activity; sid:524; rev:8;)
As TCP port 0 is an invalid destination port normally indicating
reconnaissance type activity, and in more serious cases, system
compromise, any traffic with a destination port of 0 will generate the
alarm and should be regarded as suspicious.
3. Probability the source address was spoofed:
The use of Hping's default setting to port 0 has been mentioned in
previous discussions (3). However, the evidence contained within this
log file alone is simply not enough to conclusively determine the
validity of host 211.47.255.22.
A dig -x 211.47.255.22 reports that the range is assigned to Korea
Network Information Center. A small concern as many individuals believe
that servers based in Korea and China are most frequently used in attacks.
<<>> DiG 9.2.1 <<>> -x 211.47.255.22
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22506
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;22.255.47.211.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
47.211.in-addr.arpa. 10708 IN SOA ns.krnic.net.
domain.krnic.net. 2004060716 21600 900 604800 43200
Unfortunately, a 'dig any' reported the same information and would
appear that the IP address currently has no further records. There are
a number of ways in which this attack could play out with the following
three scenarios likely candidates. Of course they remain unconfirmed as
the log file is generated by a pre-defined set of rules unbeknownst to
myself.
* Scenario 1 Spoofed: Denial of Service
My first assumption when reviewing the type of traffic would be that the
source address is in-fact spoofed and perhaps part of a denial of
service attack. Initial response would be to verify that 211.47.255.22
is not a customer network, remote branch, user or business critical
site. The reason being that an Hping Syn connect to port 0 is so
blatantly obvious that any IPS/NIDS would possibly have shunned this
network/host, thus preventing a legitimate service. I was unable to
find any other traffic within this log file, to or from the source
address or range that could verify the legitimacy of the source. Thus
leading into the next possible scenario...
* Scenario 2 Spoofed: Reconnaissance Decoy
As previously mentioned, a Syn connect to port 0 would just about set
off any NIDS alarm, alerting the firewall admin and IT staff. If an
attacker, assuming they knew what they where doing, where using hping
for host and network fingerprinting, it is very unlikely they would use
the default port zero while purposely setting the Syn flag as any hope
of remaining undetected would be futile.
hping2 -S -a 211.47.255.22 46.5.214.181 -j
HPING 46.5.214.181 (eth0 46.5.214.181): S set, 40 headers + 0 data bytes
A typical response to this type of activity would be to review any "out
of state" packets logged, assuming a stateful firewall where part of the
perimeter defenses and Syn connect floods as more than likely, the real
source IP address would be among them.
i.e. Nmap Hide Scan: * -Ddecoy_host1,decoy2[,...] Hide scan using
many decoys
· Scenario 3 IP ID Sequencing
The source address could either be spoofed (zombie) or a legitimate
host. The attacker sends a Syn request to port 0 hoping for reset
packet, thus obtaining the IPID Sequence Generation information needed
for session hi-jacking and OS fingerprinting.
4. Description of attack:
This appears to be more reconnaissance activity than an attack. TCP Syn
packets are sent from 211.47.255.22 with random source ports to host
46.5.214.181, destination port 0. Typical characteristics of an idle
host scan, provided the attacker receives a RST or ACK packet, as
mentioned is scenario 3. Why destination Port 0 in particular is
targeted is still unclear as any standard firewall or access-controlled
router should be configured to drop connections to port 0, unless the
attackers goal where to obtain information on the router access lists or
firewall policy based on returned reject packets.
A shot in the dark, however vague is that the traffic is an attempted
random exploit of the vulnerability found in Xfree86, Fedora Core 1 and
2. The vulnerability could allow attackers to gain remote access via
Xdm, on random TCP sockets but remains unlikely due to the affected
versions, release dates and current rule files.
CVE under review:
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0419:
"XDM in XFree86 opens a chooserFd TCP socket even when
DisplayManager.requestPort is 0, which could allow remote attackers to
connect to the port, in violation of the intended restrictions."
Replicating the scan with Hping:
Original packet:
19:13:25.404488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 66: 211.47.255.22.42091
> 46.5.214.181.0: S 3000316664:3000316664(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
19:13:37.454488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 ip 66: 211.47.255.22.42091
> 46.5.214.181.0: S 3000316664:3000316664(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
Possible hping variables used:
-s --baseport base source port
-y --dontfrag set do not fragment flag
-o --tos type of service
-w window size set window size
-S syn flag set syn flag
-a spoof source spoof source address
-H --ipproto set the IP protocol field, only in RAW
IP mode
-0 --rawip RAW IP mode
-d --data data size
[root at fluffybunny lindsay]# hping2 -w 5840 -S -a 211.47.255.22 46.5.214.181
HPING 46.5.214.181 (eth0 46.5.214.181): S set, 40 headers + 0 data bytes
Captured file on localhost:
[root at fluffybunny lindsay]# tcpdump -ner hping host 46.5.214.181
15:37:39.916038 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 54:
211.47.255.22.1442 > 46.5.214.181.0: S 1421001844:1421001844(0) win 5840
15:37:40.909743 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 54:
211.47.255.22.1443 > 46.5.214.181.0: S 741291124:741291124(0) win 5840
Sample Debug to localhost:
[root at fluffybunny lindsay]# hping2 -S -D -V 127.0.0.1
DEBUG: Output interface address: 1.148.0.64
DEBUG: if lo: OK
using lo, addr: 127.0.0.1, MTU: 16436
DEBUG: Trying to open PF_PACKET socket... DEBUG: PF_PACKET, SOCK_RAW open OK
HPING 127.0.0.1 (lo 127.0.0.1): S set, 40 headers + 0 data bytes
45 00 00 28 65 F3 00 00 40 06 00 00 7F 00 00 01 7F 00 00 01 08 0A 00 00
6B 57 AA 5F 5A 22 BB FF 50 02 02 00 7B FD 00 00
len=40 ip=127.0.0.1 ttl=64 DF id=0 tos=0 iplen=40
sport=0 flags=RA seq=0 win=0 rtt=0.3 ms
seq=0 ack=1800907360 sum=c94 urp=0
45 00 00 28 F6 41 00 00 40 06 00 00 7F 00 00 01 7F 00 00 01 08 0B 00 00
66 B3 BE 2E 05 15 EC 87 50 02 02 00 91 56 00 00
len=40 ip=127.0.0.1 ttl=64 DF id=0 tos=0 iplen=40
sport=0 flags=RA seq=1 win=0 rtt=0.3 ms
seq=0 ack=1723055663 sum=e084 urp=0
5. Attack mechanism:
Like any other reconnaissance activity, an attempted idle session or
fingerprint scan would notify the network admin that a potentially
malicious host is gathering information about their network layout, type
of operating systems, services and most importantly, could be a prelude
to an attack.
Based on the same three scenarios previously mentioned, the attack
mechanisms would be:
Scenario 1: Spoofed - Denial of Service
An attacker intent on stopping legitimate services could easily achieve
their goal by deploying a denial of service or distributed denial of
service attack on the targeted host or network, flooding their site with
packets, utilizing their entire bandwidth allocation or causing a site
crash. However, Internet Service Providers as well as vendors have
become more affluent at minimizing the impact of the more common attacks
such as teardrop, smurf, fragment and syn floods. As such, an
alternative or at least a more creative way to cause a denial of service
is using the target networks own IDS system against them, by setting off
an alarm and causing the sensor to block or shun the source address
range of a legitimate service.
Basically, the attacker sends a spoofed packet to destination port zero,
source address the target network. The crafted packet to destination
port zero has a known IDS signature, which notifies the sensor
management, in turn, shunning the network host from any other attempted
connections for a user defined period of time. For this type of attack
to be truly effective would require the attacker to have done their
homework, in the sense of reconnaissance. They would have to be
completely sure that IP address 211.47.255.22, possibly a natted
firewall IP requires business critical access to the 46.5.214.181
host/network.
I remain skeptical about the likelihood of this scenario as I was unable
to find any correlation within the existing logs, nor verify source
address as a legitimate host or site.
Scenario 2: Spoofed Reconnaissance Decoy
Due to the sheer blatancy of the attack, my next assumption is that it
is part of a reconnaissance decoy. The administrators would be so busy
monitoring the type of traffic coming from the source address range or
to destination port 0, the actual reconnaissance activity would go
unnoticed.
Hping's use of random source addresses or nmap's use of decoys:
Hping --rand-source random source address mode.
Nmap -Ddecoy
nmap -v -sS -O -D211.47.255.22,211.47.255.21,211.47.255.20 46.5.214.181
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Host (46.5.214.181) appears to be up ... good.
Initiating SYN Stealth Scan against (46.5.214.181)
caught SIGINT signal, cleaning up
tcpdump -ner log host 46.5.214.181
12:03:03.489233 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 42: 211.47.255.22 >
46.5.214.181: icmp: echo request
12:03:03.489338 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 42: 211.47.255.21 >
46.5.214.181: icmp: echo request
12:03:03.489632 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 42: 211.47.255.21 >
46.5.214.181: icmp: echo request
12:03:03.489814 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 42: 211.47.255.20 >
46.5.214.181: icmp: echo request
12:03:03.489908 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 54:
211.47.255.22.39975 > 46.5.214.181.http: . ack 711052103 win 2048
12:03:03.489971 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 54:
real.ip.host.39975 > 46.5.214.181.http: . ack 711052103 win 2048
12:03:03.490031 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 54:
211.47.255.21.39975 > 46.5.214.181.http: . ack 711052103 win 2048
12:03:03.490091 0:c0:4f:2a:a:1b 0:d:29:54:1b:56 ip 54:
211.47.255.20.39975 > 46.5.214.181.http: . ack 711052103 win 2048
Unfortunately, there is no true means to conclusively justify this
scenario as there would ultimately appear to be no correlation of
packets or data.
Scenario 3: IP ID sequencing
As port 0 is an illegitimate service, a Syn connect to port 0 on the
target host will cause it to respond with a Rst packet, provided the
target host is not protected by a firewall of some sort. A way of
identifying an IP ID increment with Nmap for example is to first
identify a 'zombie' (1) host. I.e. Zombie Host A. By sending a SYN-ACK
packet to the zombie, the host will respond with a RST packet, taking
note of the IP ID sequence number, i.e. 30001. Next, the attacker
sends a spoofed packet with source address of Zombie Host A, target host
responding with a RST. The attacker than sends another SYN-ACK to the
zombie host, receiving a RST with IP ID sequence number 30002,
indicating that the port is closed, with an IP ID increment of +1.
A very simple reconnaissance technique with tools Nmap and Hping (2),
which is the most likely out of all three scenarios.
6. Correlations:
One of the earliest accounts of IP ID idle host scanning was first
recorded by a Salvatore Sanfilippo way back in December of 1998.
Originally posted to the bugtraq mailing list, followed by the author of
Nmap, Fyodors paper on Idle host scanning, released September of 2002.
http://www.insecure.org/nmap/idlescan.html
http://wiki.hping.org/8
Numerous forums and vendors have published paper, articles and
discussions citing the threat associated to idle host scans. Ultimately
referring back to the original posting of Fyodor.
GCIA students making reference to Port 0 idle host scans include Jason B
Anderson, Version 3.2 Detects.
http://www.dshield.org/pipermail/intrusions/2002-October/005735.php
Barbara Morgan, Version 3.2 Detects
http://www.dshield.org/pipermail/intrusions/2002-September/005400.php
Patrick Patenaude, Version 3.3 Detects
http://www.dshield.org/pipermail/intrusions/2003-April/007432.php
7. Evidence of active targeting:
Captured in the 2002.6.16 log file is the same single host IP of
211.47.255.22, which initiated it's scan at 19:11:40.464488, consistent
destination IP address of 46.5.214.181, ending at 19:13:37.454488. This
would at first appear to indicate active targeting, however, can not
verify a known exploit while at the same time could be part of a larger
network slow scan.
To further substantiate my findings, I decided to review the logs from
2002.6.15, as well as 2002.6.17.
Logs - 2002.6.15
211.47.255.23 > 46.5.84.109
Started at 06:35:41.514488
Ended at 06:37:38.514488
211.47.255.22 > 46.5.227.153
Started at 17:16:12.164488
Ended at 17:18:09.164488
211.47.255.22 > 46.5.106.99
Started at 23:29:10.964488
Ended at 23:31:07.914488
Logs - 2002.6.17
211.47.255.21 > 46.5.29.60
Started at 07:43:56.674488
Ended at 07:45:53.674488
211.47.255.24 > 46.5.107.136
Started at 08:27:27.874488
Ended at 08:29:24.874488
211.47.255.24 > 46.5.15.88
Started at 15:01:06.604488
Ended at 15:03:03.604488
This to me would indicate a slow scan using addresses from the same
source address allocation to random destination addresses, all within
the 46.5/16 range.
8. Severity:
Severity = (criticality + lethality) - (system countermeasures +
network countermeasures)
(2+3) - (2+4) = 0
Scale of 1 to 5 - 1 being the lowest, 5 being the highest.
Criticality = 2
The purpose of the destination address 46.5.214.181 is unknown, nor is
there any other traffic destined to the IP on any other ports. As such,
a conservative value of 2 has been assigned.
Lethality = 4
While most often considered reconnaissance activity and not of great
lethality, network and host mapping could be a prelude to a later
attack. More importantly, IPID sequencing or even the possibility that
the machine has in fact already been compromised. Unauthorized network use.
System countermeasures = 2
Although no return traffic was seen in the log file, by default, a host
will respond to a TCP port 0 SYN connection with a RST ACK, which is
after all the nature of TCP/IP. So unless a personal firewall where
installed, the host would indeed respond.
Network countermeasures = 4
As previously mentioned, no return traffic was seen so assume that there
is a packet filtering device or firewall protecting the host in question.
9. Defensive recommendations:
Thankfully, most firewalls drop anything that is not explicitly
permitted. So, provided one's firewall is configured correctly, there
should be nothing to worry about. Unfortunately, this is not a perfect
world and any firewall, router or packet-filtering device is only as
strong as the policy it enforces. A "permit any any", which, believe it
or not, is seen far to often would certainly NOT protect against an
attack, little alone this type of reconnaissance activity.
Defence in depth can easily be achieved just by using the existing
hardware we are already aware of, which are two Cisco Devices. Assuming
one of which is a router, it is more than likely owned by the service
provider or Telco. My first point of action would be to request the
addition of very basic access lists. For example, implementing bogon
routing (5) and RFC 1918 (4) if not already implemented, which any first
tier service provider would do. Thus reducing the use of bandwidth by
unnecessary scans, spoofed addresses and general broadcasts etc. Next,
securing the customer side router with basic filtering similar to that
as configured on the perimeter firewall. Depending on the current
load, perhaps even updating the code with support for the IOS firewall
feature set / CBAC. I.e. Any incoming domain transfers be dropped and
logged etc. An excellent reference would be the National Security
Agency's Securing Cisco Routers Guide (6)
ip access-list extended [linetag]-access-filters
!
<truncated>
deny udp any any eq 69
deny udp any any eq 111
deny udp any any eq 2049
deny udp any any eq 31337 ! default backorifice port
permit udp any any
<truncated>
deny tcp any eq 20 any eq 2049
deny tcp any eq 20 any range 6000 6004
permit tcp any eq 20 any gt 1023
permit tcp any any gt 1023 established
!
10. Multiple choice test question:
15:01:32.949207 0:c0:4f:2a:a:1b 0:2:a5:28:8b:fe ip 54: HOSTA.2407 >
HOSTB.8080: SF 275897171:275897171(0) win 512
15:01:32.949353 0:2:a5:28:8b:fe 0:c0:4f:2a:a:1b ip 60: HOSTB.8080 >
HOSTA.2407: S 3625528744:3625528744(0) ack 275897172 win 57344 <mss
1460> (DF)
15:01:32.949427 0:c0:4f:2a:a:1b 0:2:a5:28:8b:fe ip 54: HOSTA.2407 >
HOSTB.8080: R 275897172:275897172(0) win 0 (DF)
What is wrong with the above connection with the greatest cause for concern?
A) Destination port 8080 is indicative of a backdoor Trojan. The host
has become infected as it is acknowledging the connection attempt, data
has been compromised.
B) Both Syn and Fin flags are set, which should never occur under normal
TCP connection attempts. Possible cause for alarm is the bypassing of
stateful firewalls.
C) HOSTA is not listening on port 2047, which resets the connection,
preventing a legitimate service.
Answer: B
While A is not entirely impossible, there are legitimate services such
as proxy services which runs on port 8080 while a Syn and Fin flag will
never be set.
More information about the Intrusions
mailing list