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: http://www.all.net/ CIDF, http://www.gidos.org/ and http://www.semper.org/idwg-public/ Tripwire: ftp://coast.cs.purdue.edu/pub/tools/unix/Tripwire and www.tripwiresecurity.com/ SPI: http://ciac.llnl.gov/cstc/ Popular vulnerability scanner: http://www.nessus.org/ Phonesweep: http://www.sandstorm.net/ 3 IDIC - SANS GIAC LevelTwo ©2000, 2001 3 More URLs •Coast ( http://coast.cs.purdue.edu) • http://ipindex.dragonstar.net/ • http://packetstorm.securify.com/archive s.shtml • http://netgroup-serv.polito.it/windump/ • http://www.tcpdump.org/ http://www.nttoolbox.com/ http://www.yahoo.com/ >> search engines http://www.mygale.org/cdc/trojanh.htm http://www.robertgraham.com/pubs/firewall-seen.html#subseven http://linux-firewall-tools.com/linux/ports.html http://vil.mcafee.com/dispVirus.asp?virus_k=10171 http://vil.mcafee.com/dispVirus.asp?virus_k=10171 http://www.progenic.com/t100/ http://www.hildrum.com/ports.htm http://www.pspl.com/trojan_info/win32/happy99.htm http://www.ltsw.se/knbase/tcp/tcp1.htp http://www2.merton.ox.ac.uk/~security/bugtraq-199812/0229.html http://www.securityfocus.com/bid/701.html http://advice.networkice.com/advice/Exploits/Ports/ >> A great resource!! http://advice.networkice.com/advice/Exploits/Ports/138/default.htm http://www.mulino.it/frame6.htm http://www.mulino.it/index2.htm http://www.tcrz.net/ http://post.tcrz.net: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. [...]... 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 11 Firewalls and Intrusion. .. example of better firewall logging 17 Firewalls and Access Denied TCP 80 aglimpse IFS 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 IDIC - SANS... 2001 12 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...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 IDIC - SANS GIAC LevelTwo ©2000, 2001 11 Over the years I have... 3128 we will show two examples of 3128 and an 80 IDIC - SANS GIAC LevelTwo ©2000, 2001 20 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... 26 Jot down its purpose and severity Key to Understanding: 1234 and 27374 are probably ports for Trojan horse software that runs on Windows systems As you calculate severity try to avoid the mental trap of “the firewall blocked it so there is no risk” There are a number of ways through a firewall such as every system in the facility with a modem and also tunneling through http and sending files as email... 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... following slides we will look at firewalls a bit more, and also consider the architecture for intrusion detection 11 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... a lot more of them and the concepts will be repeated 20 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... 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 . 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. a bit more, and also consider the architecture for intrusion detection. 12 IDIC - SANS GIAC LevelTwo ©2000, 2001 12 Firewalls and Intrusion Detection •