1 / 41

Advanced IDS

Advanced IDS. Brian Caswell & Jeff Nathan. Kung Fu IDS. Brian Caswell Jeff Nathan bmc@snort.org jeff@snort.org. The life of a packet through Snort’s detection engine. Overview of protocol decoding and protocol anomaly detection. Static Decoders Normalization of Data.

koren
Download Presentation

Advanced IDS

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. Advanced IDS Brian Caswell & Jeff Nathan

  2. Kung Fu IDS Brian Caswell Jeff Nathan bmc@snort.org jeff@snort.org

  3. The life of a packet through Snort’s detection engine

  4. Overview of protocol decoding and protocol anomaly detection • Static Decoders • Normalization of Data

  5. Recent detection improvements • Advanced content options (distance, within, byte_test and byte_jump) • All purpose state engine (conversation) • Improved message passing between components

  6. Recent detection improvements • Advanced content options (distance, within, byte_test and byte_jump) • All purpose state engine (conversation) • Improved message passing between components

  7. Distance content:"SITE"; nocase; content:"EXEC"; distance:0; nocase;

  8. Within content: "Content-type\: video/x-ms-asf"; content:"|0a|"; within:2;

  9. Byte jump byte_jump:4,4, relative,align; byte_jump:4,4, relative,align; content: "|00 01 86 A5|"; within:4;

  10. Byte test byte_test:1,>,7,1;

  11. Advantages Relatively Fast State-based implementations Disadvantages Users are not programmers Requires recompilation of the entire system Requires specific knowledge of the protocol (in addition to Snort) Advantages and Disadvantages of static preprocessors

  12. The promise of advanced rules • A quicker development cycle for discrete protocol anomaly detection • Only requires knowledge of Snort’s rule language and the protocol itself • NO NEED TO LEARN C

  13. Where existing advanced rules and preprocessors fall short • New preprocessors can require significant development time • Preprocessors rely on Snort’s pattern matching for detection of normalized data • No advanced constructs (loops, regex, and data munging) • Not all vulnerabilities can be covered with advanced rules and existing preprocessors

  14. A new solution: sp_perl Two new detection keywords: • “perlre” provides real regular expressions • “perl” provides runtime evaluation of virtually any perl code

  15. sp_perl, are we nuts? • Extensibility through perl • No additional CPU cost for non-perl rules • Rapid updates to Snort’s detection capabilities without re-implementing N-CODE (And since you asked, we are nuts, but not because we added perl to Snort)

  16. OK, so we’re nuts. How does this actually work? • Create an embedded perl interpreter • Parse all the rules and store perl data for later • When a perl rule option is triggered: • Convert the Payload, IPs, and Ports to perl scalars • Pass perl scalars to perl • Evaluate packet data and persistent data • On exit, destroy the runtime interpreter

  17. Embedded perl PerlInterpreter *my_perl = perl_alloc(); perl_construct(my_perl); perl_parse(my_perl, NULL, 2, perl_cmdline_opts, NULL) perl_run(my_perl); perl_destruct(my_perl); perl_free(my_perl);

  18. OK, but how does that work inside of Snort? SetupPerlKungFoo() • Verifies the file with our perl functions is there • Registers our keywords as valid detection options • Allocates a runtime perl interpreter • Initializes the perl stack for our runtime interpreter • Parses our perl file to get our functions into the runtime environment • Stores the persistent data specific to sp_perl in the OptTreeNode(s)

  19. sp_perl, what the ugly C does • Calls perl_regex with the pattern, type of test (perl vs perlre), along with the IP addresses and ports • Pushes args onto a local copy of the perl stack, then replace the global perl stack with our stack • Calls the appropriate perl function using the new global perl stack • Pops the return code from the perl stack, convert to an integer • Returns the next test on the OptTreeNode on success, otherwise 0

  20. Example Rules

  21. IMAP LSUB Buffer Overflow CAN-2000-0284 11/11-10:45:41.482210 172.16.2.130:33012 -> 10.2.2.250:143 ***AP*** Seq: 0x6F578C60 Ack: 0xFE6E84A1 Win: 0x16D0 TcpLen: 32 31 20 4C 53 55 42 20 22 22 20 7B 31 30 36 34 7D 1 LSUB "" {1064} 0D 0A .. 11/11-10:45:41.482699 10.2.2.250:143 -> 172.16.2.130:33012 ***AP*** Seq: 0xFE6E84A1 Ack: 0x6F578C72 Win: 0x7BFC TcpLen: 32 TCP Options (3) => NOP NOP TS: 26213694 338288987 2B 20 52 65 61 64 79 20 66 6F 72 20 61 72 67 75 + Ready for argu 6D 65 6E 74 0D 0A ment.. 11/11-10:45:41.483459 172.16.2.130:33012 -> 10.2.2.250:143 ***AP*** Seq: 0x6F578C72 Ack: 0xFE6E84B7 Win: 0x16D0 TcpLen: 32 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................

  22. IMAP LSUB Buffer Overflow, continued • Our content: 1 LSUB “” {1064}\r\nSHELLCODEHERE • So how do we detect this? • Regex • Regex and some math

  23. IMAP LSUB Buffer Overflow, regex 1 LSUB “” {1064}\r\nSHELLCODEHERE • Regex ^\d+\s+LSUB\s+""\s+{\d{4,}}

  24. IMAP LSUB Buffer Overflow, regex and some math 1 LSUB “” {1064}\r\nSHELLCODEHERE • Regex ^\d+\s+LSUB\s+""\s+{(\d+)} • Math $1 > 1000

  25. IMAP LSUB Buffer Overflow, the rules alert ip any any -> any any (perlre:/^\d+\s+LSUB\s+""\s+{\d{4,}/;) alert ip any any -> any any (perl:"$content =~ /\d+\s+LSUB\s+""\s+{(\d+)}/\; && $1 > 1000";)

  26. IMAP LSUB Buffer Overflow, the optimized rules alert tcp any any -> any 143 ( flow:to_server,established; content:"LSUB"; nocase; perlre:/^\d+\s+LSUB\s+""\s+{\d{4,}/;) alert tcp any any -> any 143 ( flow:to_server,established; content:"LSUB"; nocase; perl:"$content =~ /\d+\s+LSUB\s+""\s+{(\d+)}/\; && $1 > 1000";)

  27. FTP Port Bounce CVE-1999-0017 12/31--5:00:00.007051 10.1.1.254:3161 -> 10.1.1.113:21 ***AP*** Seq: 0x4FE9C1C4 Ack: 0x1E001761 Win: 0x7D78 TcpLen: 32 70 6F 72 74 20 31 37 32 2C 31 36 2C 30 2C 33 32 port 172,16,0,32 2C 31 32 2C 37 32 0A ,12,72.

  28. FTP Port Bounce, continued • Our content: port 172,16,0,32,12,72\n • So how do we detect this? • Regex and some perl

  29. FTP Port Bounce, regex and some perl port 172,16,0,32,12,72 • Regex $content =~ /port\s+(\d+),(\d+),(\d+),(\d+)/ • The Perl $srcip ne $1.'.'.$2.'.'.$3.'.'.$4

  30. FTP Port Bounce, the rules alert ip any any -> any any (perl:"$content =~ /port\s+(\d+),(\d+),(\d+),(\d+)/i && $srcip ne $1.'.'.$2.'.'.$3.'.'.$4";)

  31. FTP Port Bounce, the optimized rules alert tcp any any -> any 21 ( flow:to_server,established; content:”port”; nocase; perl:"$content =~ /port\s+(\d+),(\d+),(\d+),(\d+)/i && $srcip ne $1.'.'.$2.'.'.$3.'.'.$4";)

  32. HTTP Unknown Version 04/06-20:04:12.457297 10.200.1.100:33599 -> 66.35.250.150:80 TCP TTL:64 TOS:0x0 ID:58321 IpLen:20 DgmLen:56 DF ***AP*** Seq: 0xDD594D3E Ack: 0xAEE Win: 0x1490 TcpLen: 20 47 45 54 20 2F 20 48 54 54 50 2F 30 2E 32 0A 0A GET / HTTP/0.2..

  33. HTTP Unknown Version, continued • Our content: GET / HTTP/0.2\n\n • So how do we detect this? • Regex • Regex and some perl

  34. HTTP Unknown Version, regex GET / HTTP/0.2\n\n • Regex \s+HTTP/(0\.9|1\.1|1\.0)[\r]\n

  35. HTTP Unknown Version, regex and some perl GET / HTTP/0.2\n\n • Regex \s+HTTP/([^\n]*)\n • Perl $1 ne '1.1' && $1 ne '1.0' && $1 ne '0.9'

  36. HTTP Unknown Version, building the rules alert ip any any -> any any (perlre:\s+HTTP/(0\.9|1\.1|1\.0)[\r]{0,1}\n;) alert ip any any -> any any (perl:"$content =~ ! HTTP/(.{3})! && $1 ne '1.1' && $1 ne '1.0' && $1 ne '0.9'";)

  37. HTTP Unknown Version, the optimized rules alert tcp any any -> any 80 (flow:to_server,established; content:”HTTP”; perlre:\s+HTTP/(0\.9|1\.1|1\.0)[\r]{0,1}\n;) alert tcp any any -> any 80 (flow:to_server,established; content:”HTTP”; perl:"$content =~ ! HTTP/(.{3})! && $1 ne '1.1' && $1 ne '1.0' && $1 ne '0.9'";)

  38. Even more advanced foo • So, you want one or two specific rules to email you when they fire. • Add this to snort.pl sub insane { my ($srcip,$content) = @_; use Net::SMTP; my $server = "mail.server.com"; my $email = "perlfoo\@snort.org"; my $smtp = Net::SMTP->new($server) || die "Can't connect to mail server"; $smtp->mail($from); $smtp->to($to); $smtp->data(); $smtp->datasend("To: $email\nFrom: $email\n"); $smtp->datasend("Subject: perl alert - srcip = $srcip\n\n$content\n"); $smtp->dataend(); $smtp->quit(); } • Then use it in your rule: insane($srcip,$content)

  39. Future Work • Cache any perl specific data in the Packet struct • Figure out how to pass struct and pass *p directly with pack/unpack foo in perl • Instead of raw perl, use swig • Buy flak jackets to save us from the rest of the Snort developers

  40. Jed Rules

More Related