Tài liệu Intrusion Detection Patterns and Analysis ppt

1
IDIC – SANS GIAC LevelTwo
©2000, 2001
1
Intrusion Detection
Patterns and Analysis
Stephen Northcutt
Version 4.0
You have learned a lot already, our job is to build on this
foundation and help you become a
combat ready
analyst.
Welcome! I’m Stephen Northcutt from the Global Incident Analysis Center and in the next series of
course modules we are going to cover some new material, but also begin to wrap up everything that
you have learned so far. In our course we will continue to develop your analysis techniques and in
addition expose some new patterns and signatures. You will notice as we work though the material
that many of the detects we use have been contributed by GCIA graduates. Though we operate a
number of sensors and have access to a large data repository of intrusions, we need your help.
Without you, there is no way that we will be able to make sense of the normal and anomalous traffic
on the Internet. Please remember to give a little bit back to the community, we hope that you will
become an active participant on GIAC at www.sans.org/giac.htm. The next few slides contain a
number links that students have tried and feel are helpful.
2
IDIC - SANS GIAC LevelTwo
©2000, 2001
2
Frequently referred to URLS
•Snort
(www.snort.org)
• Portsentry/Logsentry
(www.psionic.com)

•Shadow
(www.nswc.navy.mil/ISSEC/CID)
•CVE
(CVE.mitre.org)
• NT Tools
(www.ntobjectives.com)
Of course, everyone has their favorite resources on the Net, we encourage you to take some time to
give these a try and if you find something really super that isn’t listed here, let us know about it.
These URLs are listed to provide you with some very useful information pertaining to the different
types of Intrusion Detection software that are available for download, as well to provide some
resources for discovering the latest news on common vulnerabilities, etc. We are going to skip your
next slide, it is too full of links and pick up after that with the slide titled “Roadmap – What we will
Cover.”
DTK Deception Toolkit: />CIDF, and />Tripwire: and www.tripwiresecurity.com/
SPI:
Popular vulnerability scanner: />Phonesweep: />3
IDIC - SANS GIAC LevelTwo
©2000, 2001
3
More URLs
•Coast (
)
• />• />s.shtml
• />• /> /> >> search engines
/> /> /> /> /> /> /> /> /> /> /> >> A great resource!!
/> /> /> />:81/
4
IDIC - SANS GIAC LevelTwo
©2000, 2001
4

Roadmap - What we will cover
• Intrusion Detection First Principles
–Threat, Terminology
–Firewalls, Firewall Detect Analysis
–Interoperability and architecture
• Hacking From a Network
–Mitnick Attack
When you started this course, you began with some very technical material as we learned TCP and
technical traffic analysis. Now we are going to make sure we have the fundamental concepts,
terminology and principles. This will be a slightly easier section that some of the material you have
been working on, so hopefully it will give your brain a bit of a rest. Listed in this slide and the next
are the key topics we will be covering in this course.
5
IDIC - SANS GIAC LevelTwo
©2000, 2001
5
• Network Based Intrusion Detection
Tutorial
• Intrusion Detection Using Traffic
Analysis Techniques
• Traffic Analysis Patterns Primer
• A large number of trace examples
Roadmap - What we will cover
In the end, we will turn the fact flow rate back up to fire hose mode and close with some additional
training in traffic analysis and then review a large number of signatures.
Well, time to get to it. The first topic we will cover is known as First Principles. We will start on the
following slide, and finish in the next section. At the end of each section we will have a quiz.
We have seen a number of anomalous network traces in our previous courses, on the next few slides
we will take a close look at software that serves as a nice example of the kind of tool that attackers
use to clobber our networks. The network trace we will look at on the next slide is an example of a

trace that is created by the attack tool we will be looking at.
6
IDIC - SANS GIAC LevelTwo
©2000, 2001
6
UDP Flooding
Jan 1999
17:58:13 doomer.echo > 172.20.196.51.666: udp 1024 (DF)
17:58:13 doomer.echo > 172.20.196.51.666: udp 426 (DF)
18:03:24 doomer.echo > 172.20.46.79.666: udp 1024 (DF)
18:03:24 doomer.echo > 172.20.46.79.666: udp 426 (DF)
18:24:49 doomer.echo > 192.168.26.106.666: udp 1024 (DF)
Please examine notes pages to see DNS lookup response from site
protected by “realtime” IDS. This could tip off an alert attacker.
This trace is an example of the Pepsi UDP flooder code. The idea is to just send out UDP packets as fast as you can.
This particular attack takes advantage of the echo port for amplification and also to hide the identity of the attacker.
Be certain to notice the source port and destination port, that will be important in our analysis. Also, if you look
closely at the additional data in your notes pages, you can see how long it took to trigger the real time intrusion
detection system. Pretty neat trace, isn’t it? Notice two sites are under attack. Also notice that eventually this is
detected by the IDS and a DNS lookup is issued. Think through those DNS lookups carefully, since a clever attacker
can log the lookup. We often run with just the IP addresses.
18:03:24.133079 doomer.echo > 172.2046.79.666: udp 1024 (DF)
18:03:24.157238 doomer.echo > 172.2046.79.666: udp 426 (DF)
18:24:49.369992 doomer.echo > 192.16826.106.666: udp 1024 (DF)
18:24:49.370593 doomer.echo > 192.16826.106.666: udp 426 (DF)
19:18:07.683271 doomer.echo > 192.16812.28.666: udp 1024 (DF)
19:18:07.742207 doomer.echo > 192.16812.28.666: udp 426 (DF)
19:51:32.330779 doomer.echo > 192.168242.68.666: udp 1024 (DF)
19:51:32.355470 doomer.echo > 192.168242.68.666: udp 426 (DF)
20:34:19.626463 doomer.echo > 192.168.21.66.666: udp 1024 (DF)

20:34:19.639686 doomer.echo > 192.168.21.66.666: udp 426 (DF)
20:51:54.355215 doomer.echo > 172.2094.86.666: udp 1024 (DF)
20:51:54.380065 doomer.echo > 172.2094.86.666: udp 426 (DF)
21:04:25.113394 doomer.echo > 192.16851.81.666: udp 1024 (DF)
21:04:25.137953 doomer.echo > 192.16851.81.666: udp 426 (DF)
21:05:22.503299 172.20.1.10.domain > doomer.domain: 42815 (44)
21:05:26.152327 doomer.domain > 172.20.1.10.domain: 42815* 2/0/0 (98) (DF)
23:50:15.728480 doomer.echo > 172.2076.2.666: udp 1024 (DF)
23:50:15.751821 doomer.echo > 172.2076.2.666: udp 426 (DF)
7
IDIC - SANS GIAC LevelTwo
©2000, 2001
7
#Defines
/* pepsi.c
* Random Source Host UDP flooder
* Author: Soldier
*/
#define REGISTERED_TO "David, 7h4 LiGHT m4574h"
#define VERSION "Pepsi.c v1.7+OSM+LM"
#define DSTPORT 7
#define SRCPORT 666
#define PSIZE 1450
#define DWAIT 1
#define RELEASE_DATE "[12.30.1996]"
This trace was a file found on a compromised system. It was called pepsi.c. Here we see the attackers
set the default source and destination ports using the #define (pronounced “pound define”) that will
serve as a partial signature for this code. Did you notice the destination ports and source ports on the
previous slide? How would you square that up with what you are seeing now? As an analyst, you
will need to be alert for things like this. The attacker could have overwritten the defaults with a

command line switch, but it is far more likely there are two victims in this attack. On the previous
slide, the host doomer is being hit on his echo port by a spoofed packet with your IP addresses. That
is why your sensor is picking up this traffic.
Why is the packet size designated as 1450? If you look at the previous slide’s output you notice that
the UDP datagram data lengths are pairs of 1024 and 426? Combined they equal 1450, but why
don’t we see datagram data lengths of 1450. When you are dealing with UDP, there are two factors
that can determine that maximum datagram length. First, the application interface such as written
above designates a length. But, the Unix kernel might limit this size as well. We speculate that the
Unix kernel on the host on which this was executed had a maximum UDP datagram data length of
1024 and that is why you see two packets generated of different sizes. Or, perhaps the code that
generated the trace on the previous slide was slightly different than the code shown here. Who can
say?
8
IDIC - SANS GIAC LevelTwo
©2000, 2001
8
User Input
void usage(char *pname)
{
printf("Usage:\n ");
printf("\t Source, where packets are comming from.\n");
printf("\t Number of UDP packets to send.\n");
printf("\t Packet Size Default is 1450\n");
printf("\t Dest Port - Default is \n", DSTPORT);
printf("\t Source Port - Default is \n", SRCPORT);
printf("\t Wait time between packets - Default is 1\n");
printf("\t Destination/Victim \n");
exit(EXIT_SUCCESS);
}
This slide shows the usage screen. For most attacker code this is all the documentation that you get.

Note the attacker can override the default source and destination ports as well as other parameters.
When the attacker executes the compiled version of the code, and manages to get it to print out the
usage, he/she is given the parameters that can be overridden to change the default execution of the
program.
9
IDIC - SANS GIAC LevelTwo
©2000, 2001
9
if (srchost && *srchost)
ip->saddr = resolve(srchost);
ip->daddr = dst;
ip->version = 4;
ip->ihl = 5;
ip->ttl = 255;
ip->protocol = IPPROTO_UDP;
ip->tot_len = htons(sizeof(struct iphdr) +
sizeof(struct udphdr) + psize);
ip->check = in_cksum(ip, sizeof(struct iphdr));
udp->source = htons(srcport);
udp->dest = htons(dstport);
udp->len = htons(sizeof(struct udphdr) + psize);
Constructing the packet
What this code represents is setting the fields of the actual IP datagram. Once the datagram is
constructed it will be sent using system calls to be sent to the network.
Some of the fields that have to be supplied in the IP datagram are shown; a resolution of source and
destination hostnames to IP numbers has to be done to put them in the datagram. Remember IP speaks
IP numbers not host names. Next you see the version of IP is the current version of IP 4. The IP header
length is assigned the value of 5. This metric is 5 32-bit words and since a byte is 8 bits, a word is 4
bytes. So, the actual header length is 20 bytes which is normal. Then you see an initial TTL of 255
assigned. This gives the attack the maximum possible range, but also would help to serve as a partial

signature. You also see where this is constructed to have UDP as the embedded protocol. Other fields
are assigned as well, and then the data is formatted for the network. Note that the source address is
spoofed, but has a valid name since it is being resolved.
There is a function executed above known as htons which converts the hosts byte order of data to the
network byte order. This ensures that the source code will be portable to any host regardless of byte
order.
10
IDIC - SANS GIAC LevelTwo
©2000, 2001
10
if (sendto(sen, packet, sizeof(struct iphdr) +
sizeof(struct udphdr) + psize,
0, (struct sockaddr *) &dstaddr,
sizeof(struct sockaddr_in)) == (-1)) {
puts("Error sending Packet!");
perror("SendPacket");
exit(EXIT_FAILURE);
}
Delivering the packet
This final code segment takes the datagram created in the previous slide, and attempts to send it to
the socket interface. The actual code is not much larger than this. To date this has been a
characteristic of Denial of Service flooder code, small tight loops. To summarize what we have
seen, in this case we are able to match an actual detect in the wild with code found on an exploited
system. When possible, we prefer to use detects in the wild over laboratory created traces to make
sure the course is as accurate as possible. From time to time this will not be feasible, but we will
make every lab created trace appropriately. We looked at the definitions part of the program where
default values were initialized. We saw the usage screen which we pointed out is a hacker man page.
We constructed the packet with the values we wanted it to have and finally we fired it out on the
network. This is the same type of software we commonly see in attacker code. As we continue with
first principles we will begin to consider the effects of firewalls and perimeters on anomalous traffic.

11
IDIC - SANS GIAC LevelTwo
©2000, 2001
11
First Principles Objectives
• Relationship of firewalls and firewall
policy to intrusion detection
• Introduction to the common intrusion
detection framework architecture
• Familiarity with issues related to push
and pull. Be very skeptical of the
marketing term
REAL TIME
Over the years I have been fascinated by the evolution of firewalls. My first experience was with the
“TIS Toolkit”. This was a proxy based firewall, the software was freely available and fairly easy to
read, at least the proxies were fairly easy to read. Needless to say firewalls have become more
complex, but also more removed from the user. Today, the primary trend seems to be appliances,
boxes that you put on your DMZ or internally, and as the name appliance implies, essentially forget
them. So what does any of this have to do with intrusion detection? Well, when I was teaching in
Monterey in October 2000, I ran into three vendors that were all excited about their integrated
intrusion detection and firewall developing products. Depending on where they take the products
this could be a wonderful trend since the firewall/IDS could have the ability to fake out the attacker
with techniques similar to the Raptor firewall’s active defense. In the following slides we will look
at firewalls a bit more, and also consider the architecture for intrusion detection.
12
IDIC - SANS GIAC LevelTwo
©2000, 2001
12
Firewalls and Intrusion Detection
• Firewalls perturb traffic – disrupt 3-way

handshake
• Firewall logs are still the primary
method of doing intrusion detection
• Consider the fidelity of the logging
when purchasing a firewall
It's naïve to assume that just installing a firewall is going to
protect you from all potential security threats.
Kevin Mitnick
September 2000
Firewalls are an important factor in intrusion detection. More people use firewalls as their primary
sensor than intrusion detection systems, if the reports to GIAC can be considered a guide. If you are
not factoring in your firewall logs to your analysis, this may be the time to start! It is critical to see
how they perturb the traffic so you can understand what is actually going on. We will show
examples of this.
13
IDIC - SANS GIAC LevelTwo
©2000, 2001
13
INTERNET
ISP
S
DMZ
DMZ (Demilitarized Zone),
is the area between an ISP
and the outermost firewall
interface
A sensor, or event
detector, is used to
instrument the DMZ
Firewall

Firewall as IDS Sensor
This slide shows a firewall with an IDS sensor. A firewall is a pretty good sensor if and only if the
packet is addressed to one of its interfaces. Firewalls don’t care about the traffic on the DMZ; they
only care about the traffic that they pass from the outside to the inside and vice versa. Firewalls also
tend to be TCP-centric which means that they miss a lot.
If a packet tries to pass through a firewall that violates the policy, it will probably detect it.
14
IDIC - SANS GIAC LevelTwo
©2000, 2001
14
Alternate Definition DMZ
INTERNET
ISP
S
Front End
DMZ (Demilitarized Zone),
is a screened subnet off of
one leg of a firewall.
Firewall
DNS Email
The correct definition of a DMZ is another religious debate. The definition of a religious debate is
one in which no amount of reasoning will convince the other side to change their minds.
This confusion of DMZ seems to hail from certain firewall vendors, such as Secure Computing’s
Sidewinder, incorrectly naming the third leg of their firewall “DMZ”
The term DMZ is borrowed from the military. If you consider North Korea and South Korea, you
realize they are potentially at war at any time. Between the two countries is an area that is not North
Korea, or South Korea, it is a buffer zone. It is called a DMZ. Which example is closer to this
analogy? The first. You can use any definition for DMZ you want, but if you choose the screening
subnet, please know you are wrong.
15

IDIC - SANS GIAC LevelTwo
©2000, 2001
15
DMZ
Getting the DMZ Thing Straight
This slide shows the most famous active DMZ in the world, the border between North and South
Korea. Take a close look at the picture and then notice the network architecture on the previous
slide. Which do you think is closest to a DMZ?
16
IDIC - SANS GIAC LevelTwo
©2000, 2001
16
Firewall Logging (1)
MAR 02 05:17:35 2000 IP Packet discarded from
207.168.44.6 for port 1880
MAR 02 17:17:57 2000 IP Packet discarded from
207.168.44.6 for port 1882
MAR 03 17:15:57 2000 IP Packet discarded from
207.168.44.6 for port 1881
Key to Understanding:
The firewall log gives us a fact, but we do not have enough
Information to interpret what is going on.
This is a soho firewall log.
We might want to know why the firewall is blocking port 1880. Well that is simple enough, it
probably has a deny all policy and simply doesn’t have a rule for 1880.
But 1880 is a reasonable number for an ephemeral port, what if this is a SYN/ACK? This could be a
response to something initiated from the inside, or, someone spoofing the address space of the
computers inside. There simply is no way to know. Compare this to the next trace.
17
IDIC - SANS GIAC LevelTwo

©2000, 2001
17
Firewall Logging (2)
03/02/2000 16:08:32.592 - UDP packet dropped -
Source:167.8.29.91, 2820, WAN -
Destination:192.168.1.32, 33434,LAN Rule33
Key to Understanding:
This is a trace route. This time we get additional information,
we get the source port as well as the destination port. This
begins to create a picture.
This trace is from a SonicWall firewall. A system from the site went out to a web server and the load
balancing technique used to trace back is a traceroute from multiple backbones. The high number
33,400 range UDP is very typical of a traceroute. The point of the slide, though, is to show an
example of better firewall logging.
18
IDIC - SANS GIAC LevelTwo
©2000, 2001
18
A deny all except which is allowed makes a wonderful policy for
intrusion detection and security in general. An allow everything
not specifically denied firewall policy makes site customized
intrusion detection very hard. In either case, the firewall or
filtering router logs can and should be used as ID sensors.
TCP 80
aglimpse
IFS
Firewalls and Access Denied
Firewalls work! In fact, with a few caveats, filtering routers work quite well. If a site adds internal
firewalls then they are in much better shape.
What is in a word. :) Many analysts switch to call the attack attempts that do not penetrate the

firewall “network detects”; this is a fairly good word. We can then restrict the term intrusion to
describe attempts that penetrate our defenses.
If one denies all first and then adds back the things that are allowed by exception, then the odds of
getting blindsided by an attack you didn’t know about, a service you didn’t know you were running,
or something that you did know about, but overlooked, goes way down. This is certainly the
recommended approach.
Allow everything and then deny what you are afraid of is a risky approach, but may be necessary in
organizations where freedom is valued above security, such as in research labs or educational
institutions.
19
IDIC - SANS GIAC LevelTwo
©2000, 2001
19
A Day in the Life of a Cable
Modem User
Dec 24 01:10:09 cc1014244-a kernel: securityalert: tcp if=ef0
from attacker1:2103 to victim on unserved port 1243
Dec 24 02:45:53 cc1014244-a kernel: securityalert: tcp if=ef0
from attacker2:3851 to victim on unserved port 12345
Dec 24 03:42:21 cc1014244-a kernel: securityalert: udp if=ef0
from attacker3:1542 to victim on unserved port 31337
Dec 24 04:35:25 cc1014244-a kernel: securityalert: udp if=ef0
from attacker4:2322 to victim on unserved port 1
Dec 24 05:26:37 cc1014244-a kernel: securityalert: tcp if=ef0
from attacker5:810 to victim on unserved port 111
Dec 24 11:49:06 cc1014244-a kernel: securityalert: tcp if=ef0
from attacker6:1894 to victim on unserved port 12345
This is one of the best arguments for desktop firewalls that we have seen. If you don’t think your
home computer is being attacked while you are online, just look at the trace above. The trace is
truncated, on the slide, the rest is shown below. Nine different attackers over a 24 hour period to this

cable modem. Trojans and PC-Anywhere seem to be the targets of interest.
Dec 24 17:27:46 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:2902 to victim on unserved port 5632
Dec 24 17:27:46 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:2902 to victim on unserved port 22
Dec 24 18:02:13 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:1044 to victim on unserved port 22
Dec 24 18:03:15 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:1046 to victim on unserved port 5632
Dec 24 18:03:15 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:1046 to victim on unserved port 22
Dec 24 18:04:08 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:1048 to victim on unserved port 5632
Dec 24 18:04:08 cc1014244-a kernel: securityalert: udp if=ef0 from
attacker8:1048 to victim on unserved port 22
Dec 24 22:21:04 cc1014244-a kernel: securityalert: tcp if=ef0 from
attacker9:3349 to victim on unserved port 1243
20
IDIC - SANS GIAC LevelTwo
©2000, 2001
20
The Next Three Slides
• Are all examples of detects because of
a deny all not allowed policy
• Were all submitted during the hunt for
the RingZero trojan, SEP-OCT 99
• Are all similar, the RingZero pattern was
80, 8080, 3128 we will show two
examples of 3128 and an 80
The teaching style used in this course is to talk about concepts and then illustrate them with network

detects. The concept here is using a firewall’s policy – deny anything you don’t have an allow rule
for – as a tool for intrusion detection.
It is still early in the course and if the examples look a bit odd, that isn’t a problem, we will see a lot
more of them and the concepts will be repeated.
21
IDIC - SANS GIAC LevelTwo
©2000, 2001
21
Cisco Router ACL
Oct 12 01:04:26 ucc3.edu 45725: 8w5d^I: %SEC-6-IPACCESSLOGP:
list 190 denied tcp 202.159.123.192(2235) ->
172.20.8.233(3128), 1 packet
Oct 12 01:10:14 ucc3.edu 45730: 8w5d^I: %SEC-6-IPACCESSLOGP:
list 190 denied tcp 202.159.123.192(2235) ->
172.20.8.233(3128), 3 packets
Key to Understanding:
Protocol is TCP and the destination port is 3128, so, this
was an attempt to reach a SQUID Proxy that was blocked by
this packet filtering system.
More of the same, here again, the packet is denied access; this site does not allow 3128 TCP to pass.
This router message also includes information about the source IP and port. Access list 190 is the
one that causes the block of traffic and it is almost certain that this represents an access list for
inbound traffic. It is perfectly acceptable to block outbound traffic as well if you don’t want internal
users accessing particular services, such as IRC. But, that would be done using a different access list
and assigned a different access list number. The name of the router that has blocked the access is
ucc3.edu.
From: />• What is Squid? Squid is a high-performance caching proxy server for web clients. It supports FTP,
gopher, and HTTP protocols.Squid servers can operate in a hierarchical fashion. A server can have
any number of parents or siblings. Caches in a hierarchy use the ICP (Internet Cache Protocol) to
query each other for discovery of cached objects.Squid is available in source form under the GNU

Public License.It can be built on most modern Unix operating systems that have anANSI C compiler.
• Why is Squid a good thing? Caching proxy servers improve performance for end users' web
browsers, and reduce bandwidth utilization.
•Where can I get Squid?The current version of Squid is available at:
<URL: />> <URL: />22
IDIC - SANS GIAC LevelTwo
©2000, 2001
22
Packet Filter+
Sep 22 11:53:52 mute kernel: Packet log: forward REJECT eth0 PROTO=6
202.103.190.56:2823 203.24.49.19:3128 L=60 S=0x00 I=51905 F=0x4000 T=44
Sep 22 11:54:02 mute kernel: Packet log: forward REJECT eth0 PROTO=6
202.103.190.56:1961 203.24.49.20:3128 L=60 S=0x00 I=56800 F=0x4000 T=44
Sep 22 11:54:05 mute kernel: Packet log: forward REJECT eth0 PROTO=6
202.103.190.56:2832 203.24.49.21:3128 L=60 S=0x00 I=58202 F=0x4000 T=44
Sep 22 11:54:14 mute kernel: Packet log: forward REJECT eth0 PROTO=6
202.103.190.56:1512 203.24.49.24:3128 L=60 S=0x00 I=62628 F=0x4000 T=44
Key to Understanding:
Protocol 6 is TCP of course and the destination port is
3128, so, this was an attempt to reach a SQUID Proxy that
was blocked by this packet filtering system.
Again the point of this slide is really simple. The incoming packet did not match the security policy
and was rejected. But here is some further information on reading IP Chains logs.
L = 60 (the length of Ethernet frame 14 bytes + minimum IP datagram length over Ethernet 46 bytes
There are four seldom-used bits in the IP header, called the Type of
Service (TOS) bits. They effect the way packets are treated; the four
bits are "Minimum Delay", "Maximum Throughput", "Maximum Reliability"
and "Minimum Cost". Only one of these bits is allowed to be set.
TOS Name Value Typical Uses
Minimum Delay 0x01 0x10 ftp, telnet

Maximum Throughput 0x01 0x08 ftp-data
Maximum Reliability 0x01 0x04 snmp
Minimum Cost 0x01 0x02 nntp
F = appears to be Flags - the only one I have been able to nail down is that
0x4000 seems to correlate to DF.
T = ttl
SYN - is a SYN packet
#64 is the rule it dropped on.
23
IDIC - SANS GIAC LevelTwo
©2000, 2001
23
Proxy Firewall
Oct 1 06:47:02 gate gwcontrol: 201 http[3785494487]: access
denied for smak.mplik.ru to www.rusftpsearch.net [default rule]
[no rules found]
Oct 1 06:47:02 gate httpd[7188]: 121 Statistics: duration=0.15
id=w7Ii3 sent=357 rcvd=402
srcif=hme1 src=195.58.0.243/61332 srcname=smak.mplik.ru
dstif=hme1 dst=206.253.222.89/80 dstname=www.rusftpsearch.net
op=GET
arg= />ost=167.33.61.23&pstport=80
result="403 Forbidden" proto=http (request denied by gwcontrol)
Key to Understanding:
Access was denied
This is a trace from an application gateway sensor. We think it is a Raptor; this was a breakthrough
logfile in the search for RingZero. These detailed logs alerted us that we were searching for
rusftpsearch. Please note that access denied is in bold as well as the default rule! The main point
then of these three slides is the firewall will reject anything that doesn’t have a matching rule. This
means if we set our firewall up tightly, only allow the services we need in, we have a great tool for

intrusion detection.
Because this is an application proxy sensor, it is able to examine the content of the payload. The
other firewalls that have been discussed examine the packet at the IP header, or perhaps the
embedded protocol header. They don’t attempt to look at the payload as this firewall does.
24
IDIC - SANS GIAC LevelTwo
©2000, 2001
24
Firewall Allow All Except That
Which Is Denied
Feb 26 00:35:40 134.161.1.101 22024: %SEC-6-
IPACCESSLOGP: list ingress denied udp
38.29.63.57(4523) -> 10.161.67.71(34555), 1 packet
Key to Understanding:
Windows version of Trinoo discovered at a .edu site
By their nature they need to be open so they only
implement filters as required. Once added they made
the detect.
This is from March 2000. Gary Flynn at JMU had found a Windows version of Trinoo and had
documented the effort, but over a week went by with no correlation. Virus companies were slow to
build signature and the US Government (CERT/FBI etc) was not sharing information. This was a
critical detect. Until Ken added the filter rule to his perimeter defense he was very unlikely to make
this detect. Here are his words:
“We have identified a single machine on our campus network that was hosting a copy of the window
variant of the trinoo daemon. The machine was also hosting a copy of Back Orifice. Both have been
removed from the machine in question.
I began filtering and logging ingress packets aimed at UDP 34555 late last week after reading Gary
Flynn's report on this program. The log of attempted connections is below. Timestamps are CST
and should be reasonably accurate since we use NTP to a stratum 2 clock.
Please get in touch if there is more information that you need.

-Ken”
25
IDIC - SANS GIAC LevelTwo
©2000, 2001
25
Firewall Detect Analysis
• The analyst is only presented with
packets that were blocked – this is a
very important concept to keep in
mind!
1. Determine service or purpose of
packet
2. Estimate severity – what if the packet
got through another way
Firewalls have some limitations in intrusion detection, but they are the primary tool used to do this
sort of work, so we will have some examples to practice.
Always keep in mind you aren’t seeing all the traffic, only the exceptions that are presented to you.
In the Winoo slide, ( Trinoo on windows is often called Winoo ), they couldn’t make that detect until
they installed the filter!
The process is really simple; figure out what the packet is usually by its destination port and then
determine severity.