logging in or signing up IMS 2005 Kestrel Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 140 Category: Entertainment License: All Rights Reserved Like it (0) Dislike it (0) Added: October 07, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Slide1: The Internet Motion Sensor: A Distributed Blackhole Monitoring System Michael Bailey Research Project Manager University of Michigan Lockdown 2005 Friday, July 15th, 2005Global Threats: Global Threats Networks increasingly subjected to threats that impact the reliability and availability of critical infrastructure. Distributed Denial of Service (DDoS) SCO 2003, DNS 2005 Fast moving worms CodeRed, Nimda, Sapphire, Blaster, Witty, Sasser Survey of 19 research universities shows that each spent an average of $299,579 during a five-week period last summer to undo the havoc wrought by the so-called Blaster worm [Chronicle of Higher Ed, 2004]Addressing These Threats is Hard: Addressing These Threats is Hard Globally scoped, respecting no geographic or topological boundaries. At peak, 5 Billion infection attempts per day during Nimda including significant numbers of sources from Korea, China, Germany, Taiwan, and the US. [Arbor Networks, Sep. 2001] Zero- day threats, exploiting vulnerabilities for which no signature or patch has been developed. In Witty, "victims were compromised via their firewall software the day after a vulnerability in that software was publicized” [Moore et. el. 2004] Exceptionally virulent, propagating to the entire vulnerable population in the Internet in a matter of minutes. During Slammer, 75K hosts infected in 30 min. [Moore et al, NANOG February, 2003]Well we gotta try …: Well we gotta try … .. But doing anything at line speeds is hard (OC-768 in the core or 10-GigE at the Edge). So need to divide and conquer. A common technique is to use routing infrastructure to collect malicious traffic (hopefully a small fraction) and send it to a box to be analyzed. How do you figure out what to pull off? attacked customer traffic outbound to Bogon space inbound to addresses which may be announced, but not usedOur Approach: Our Approach A Blackhole/Dark IP/Telescope sensor monitors an unused globally advertised address block that contains no active hosts Traffic is the result of DDoS backscatter, worm propagation, misconfiguration, or other scanning Related Projects CAIDA http://www.caida.org/analysis/security/ Team Cymru http://www.cymru.com/Documents/darknet-project.html iSink http://www.cs.wisc.edu/~pb/Blackhole Monitoring: Blackhole MonitoringSo you want one?: So you want one? Great, that was easy: Get an unused address block Monitor the packets Detect Threats and Prosper But… some challengesDifferent Perspectives: Different Perspectives Each IMS block sees very different local preference Worms can have a local preference Local service scanning Local mis-configurationDifferentiate Threats: Differentiate Threats Outbreak of the Sasser worm observed at a /24 Noise on TCP/445 Signal: A Sasser signature Outbreak of the Sasser worm observed at a /24Why not Build Service Modules?: Why not Build Service Modules? Backdoor ports Increase in backdoor scanning over 5 months Difficult to get payloads on backdoor ports using honeypots/service modulesIMS System Components: Challenges: Need better address coverage Need to be able to differentiate threats IMS System Components Distributed Monitoring Infrastructure Increase coverage of threat activity Lightweight Active Responder Capture payloads to differentiate threats Payload Signatures and Caching Improve performance and scalability Our Solution:Distributed Monitoring Infrastructure: Distributed Monitoring Infrastructure IMS Supports blackhole sensors of any size Distributed architecture scaling to many sensorsLightweight Active Responder: Lightweight Active Responder Goal: obtain enough fidelity to differentiate threats with the minimum resource cost TCP needs to establish a connection before data is sent Use lightweight SYN-ACK Active Responder Receive a SYN => Respond with a SYN-ACKBlaster Worm - Live Host: Blaster Worm - Live Host Buffer Overflow Backdoor: Fetch & Execute wormBlaster Worm - Passive Monitor: Blaster Worm - Passive Monitor Misses Important FeaturesBlaster Worm - IMS: Blaster Worm - IMS Captures Important FeaturesActive Responder Limitations : Active Responder Limitations Application-level response may be required to differentiate certain threats. (e.g. Agobot) Threats like Agobot can be differentiated using scanning behavior Sensors can be fingerprinted and avoided IMS focused on globally scoped threats (threat model does not include targeted manual attacks) Many sensors of different sizes in many networks near live hosts makes avoidance very hard Rotate active responders within address blockPayload Signatures and Caching: Payload Signatures and Caching Compute MD5(payload without headers) Only store payload if MD5 is new MD5 signature cache hit rate 96% Same “stuff” seen repeatedly Factor of 2 savings in disk MD5 Signature Cache hit rate over 16 days at three sensorsSlide19: Recent Deployment ResultsIMS Deployment: IMS Deployment Tier 1 ISPs, Large Enterprise, Broadband, Academic, National ISPs, Regional ISPs Initial /8 deployment in 2001. Currently 60 address blocks at 18 networks on 3 continents Deployment Statistics: Deployment Statistics DDoS Reconnaissance/Scanning Internet Worms Bots! 17,094,016 IPs monitored 1.25% of routed IPv4 space 27 /8 blocks with an IMS sensor 21% of all routable /8 blocks have at least one sensor IMS has provided insight into:Recent TCP/42 Activity: Recent TCP/42 Activity November 24, 2004 vulnerability announced on remotely exploitable overflow in the WINS server component of Microsoft Windows December 2004, an increase in activity to tcp/42 was reported January 2005, news of significant amounts of increased activity on tcp/42 was noted in multiple reports. Vulnerability Announced Increased Activity Detected Significant Activity Reported Exploit PublishedTCP/42 Payloads: TCP/42 Payloads Captured live payloads that match byte-for-byte with template exploit code Same exploit is being reused to inject many different payloads (same exploit with very different shellcode) Evidence suggest attacks are from manual tools not automated worm. However vulnerability is “wormable” http://ims.eecs.umich.edu/reports/port42/Recent TCP/6101 Activity: Recent TCP/6101 Activity December 16, 2004 iDEFENSE Announces Buffer overflow vulnerability in Veritas Backup Agent January 11, 2005 Hat-Squad publishes exploit code January 11, 2005 IMS detects activity on TCP/6101 Vulnerability Announced Significant Activity Reported Exploit PublishedTCP/6101 Payloads: TCP/6101 Payloads Captured live payloads that match byte-for-byte with template exploit code Evidence suggest attacks are from manual tools not automated worm. However vulnerability is “wormable” Both port 42/6101 were zero-day threats! Exploit released and the same day the attacks began http://ims.eecs.umich.edu/reports/port6101/IMS Insights into Threat Trends: Worms: IMS Insights into Threat Trends: Worms Demographics Korea no longer top spot (TLD analysis) Global broadband still biggest source (2LD) Exploit trends Faster time to market? Faster cleanup Hours, not days Escalated Threats DDoS agent carrier, spread is DDoS PersistenceWorm persistence: Worm persistence 100,000s of infected hosts left over from infections dating by to 2001! Packets Unique HostsRise of the Zombies: Rise of the Zombies New personal attacks often rely on an another resource (e.g. phishing site, SPAM relay) Anonymous use of resource highly desirable => attackers use another compromised system as a proxy! Attackers have learned a compromised system is more useful alive than dead!Big Bad Bots: Big Bad Bots Total infected bot hosts 800,000 - 900,000 [CERT CA-2003-08] > 100,000 nodes/botnet 1000’s of new bots each day [Symantec 2005] Many articles/press citing thousands of infected hosts [IEEE S&P, Register] Difficult to measure: => Population likely much much larger!Bot/Botnet Measurements - Operators: Bot/Botnet Measurements - Operators Very little hard data on botnets! We asked operators (five Tier-1 & Tier-2 ops): They are actively fighting the problem # of Botnets - increasing Bots per Botnet - decreasing Used to be 80k-140k, now 1000s (evasion/economics?) More firepower: Broadband (1Mbps Up) x 100s == OC3!!! Custom botnets (all .edu, .gov/.mil) - economics? Bots Futures: Bots Futures Bots provide support infrastructure for a large range of devastating Internet attacks IRC-based botnet detection may be effective tool today Tomorrow must focus on holistic view of bot behavior - detect infections, command, and behavior Interesting questions: How do we measure bots? Who is responsible for cleanup? (Organizations/ISPs/Law Enforcement) Global enforcement => bots in US attack China?Slide32: IMS ToolIMS Portal: Basics: IMS Portal: BasicsIMS Portal: Analysis: IMS Portal: Analysis Each view can also be analyzed in a number of ways: => Cumulative unique source IP’s over time => Cumulative unique MD5 signatures over time => Top offending source IP’s => Top offending source IP’s (with reverse DNS) => Top payload signatures Smoothing filters can be applied to all graphs Results can be filtered by source IPIMS Portal: Analysis: IMS Portal: AnalysisIMS Portal: Signatures: IMS Portal: Signatures Each unique payload captured by IMS is stored in its entirety All unique payloads can be viewed using the IMS Portal Clicking on a signature fetches the binary from the remote sensor The binary data is fed to tethereal Analysis is shown in real-timeIMS Portal: Signatures: IMS Portal: SignaturesIMS Portal: Aggregation: Each sensor process data independently so its possible to run queries in parallel We leverage this ability with the IMS aggregation feature => TCP over EECS & CAEN The output is automatically normalized so that results from different sensors with different sized can be compared => TCP port 135 over EECS /24 and a /18 Can track threat between sensors IMS Portal: AggregationIMS Portal: Aggregation: IMS Portal: AggregationIMS Alert!: IMS Alert! IMS alerting system Automatically detect emerging threats Notify subscribers with relevant information Alert: detect a significant increase in number of unique sources contacting a specific port Compare average number of unique sources contacting over last 12 hours vs. previous 6 days If recent average > 3x historical “norm”, then alert Avoids using human defined threshold; universal across all portsExample: MySQL worm: Example: MySQL wormWhat you need to deploy IMS: What you need to deploy IMS 1+ blocks of unused address space within your public or private network (> /24) Advertise blocks and route to IMS sensor Rack, power, IP_ADDRs for a two interfaces Management BlackholeWhat you get: What you get Reports Global IMS Networks Alerts IMS Portal access to your sensor and other IMS participants Local data store: optimized binary format set of command-line tools to assist in access to the data store machine# logview /var/data 03-04-2004 05-15-2004 23:57:43 00024c30 10.49.151.77 768 > 192.168.100.158 768 ICMPPrivacy: Privacy Data providers keep local copies of their data Aggregated data is shared only among IMS participants Michigan is a center for the DHS PREDICT project and we will disseminated data through that project We are in the IRB process to release additional data Outreach: Outreach IMS used daily by operator community to investigate new threats We provide reports and forensics to NSP-SEC and NANOG operator community Higher Ed: Recently deployed at REN-ISAC Planning an academic community to share data with each otherAcknowledgements: Acknowledgements For more information on the Internet Motion Sensor: http://ims.eecs.umich.edu ims@umich.edu Thanks to the ISPs, academic institutions, and organizations for hosting the IMS! Thanks to Danny McPherson, Jose Nazario, Robert Stone, Rob Malan, and Dug Song at Arbor Networks and Larry Blunk, Bert Rossi, and Manish Karir at Merit Network. And of course our sponsor: You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
IMS 2005 Kestrel Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINTLite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 140 Category: Entertainment License: All Rights Reserved Like it (0) Dislike it (0) Added: October 07, 2007 This Presentation is Public Favorites: 0 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Slide1: The Internet Motion Sensor: A Distributed Blackhole Monitoring System Michael Bailey Research Project Manager University of Michigan Lockdown 2005 Friday, July 15th, 2005Global Threats: Global Threats Networks increasingly subjected to threats that impact the reliability and availability of critical infrastructure. Distributed Denial of Service (DDoS) SCO 2003, DNS 2005 Fast moving worms CodeRed, Nimda, Sapphire, Blaster, Witty, Sasser Survey of 19 research universities shows that each spent an average of $299,579 during a five-week period last summer to undo the havoc wrought by the so-called Blaster worm [Chronicle of Higher Ed, 2004]Addressing These Threats is Hard: Addressing These Threats is Hard Globally scoped, respecting no geographic or topological boundaries. At peak, 5 Billion infection attempts per day during Nimda including significant numbers of sources from Korea, China, Germany, Taiwan, and the US. [Arbor Networks, Sep. 2001] Zero- day threats, exploiting vulnerabilities for which no signature or patch has been developed. In Witty, "victims were compromised via their firewall software the day after a vulnerability in that software was publicized” [Moore et. el. 2004] Exceptionally virulent, propagating to the entire vulnerable population in the Internet in a matter of minutes. During Slammer, 75K hosts infected in 30 min. [Moore et al, NANOG February, 2003]Well we gotta try …: Well we gotta try … .. But doing anything at line speeds is hard (OC-768 in the core or 10-GigE at the Edge). So need to divide and conquer. A common technique is to use routing infrastructure to collect malicious traffic (hopefully a small fraction) and send it to a box to be analyzed. How do you figure out what to pull off? attacked customer traffic outbound to Bogon space inbound to addresses which may be announced, but not usedOur Approach: Our Approach A Blackhole/Dark IP/Telescope sensor monitors an unused globally advertised address block that contains no active hosts Traffic is the result of DDoS backscatter, worm propagation, misconfiguration, or other scanning Related Projects CAIDA http://www.caida.org/analysis/security/ Team Cymru http://www.cymru.com/Documents/darknet-project.html iSink http://www.cs.wisc.edu/~pb/Blackhole Monitoring: Blackhole MonitoringSo you want one?: So you want one? Great, that was easy: Get an unused address block Monitor the packets Detect Threats and Prosper But… some challengesDifferent Perspectives: Different Perspectives Each IMS block sees very different local preference Worms can have a local preference Local service scanning Local mis-configurationDifferentiate Threats: Differentiate Threats Outbreak of the Sasser worm observed at a /24 Noise on TCP/445 Signal: A Sasser signature Outbreak of the Sasser worm observed at a /24Why not Build Service Modules?: Why not Build Service Modules? Backdoor ports Increase in backdoor scanning over 5 months Difficult to get payloads on backdoor ports using honeypots/service modulesIMS System Components: Challenges: Need better address coverage Need to be able to differentiate threats IMS System Components Distributed Monitoring Infrastructure Increase coverage of threat activity Lightweight Active Responder Capture payloads to differentiate threats Payload Signatures and Caching Improve performance and scalability Our Solution:Distributed Monitoring Infrastructure: Distributed Monitoring Infrastructure IMS Supports blackhole sensors of any size Distributed architecture scaling to many sensorsLightweight Active Responder: Lightweight Active Responder Goal: obtain enough fidelity to differentiate threats with the minimum resource cost TCP needs to establish a connection before data is sent Use lightweight SYN-ACK Active Responder Receive a SYN => Respond with a SYN-ACKBlaster Worm - Live Host: Blaster Worm - Live Host Buffer Overflow Backdoor: Fetch & Execute wormBlaster Worm - Passive Monitor: Blaster Worm - Passive Monitor Misses Important FeaturesBlaster Worm - IMS: Blaster Worm - IMS Captures Important FeaturesActive Responder Limitations : Active Responder Limitations Application-level response may be required to differentiate certain threats. (e.g. Agobot) Threats like Agobot can be differentiated using scanning behavior Sensors can be fingerprinted and avoided IMS focused on globally scoped threats (threat model does not include targeted manual attacks) Many sensors of different sizes in many networks near live hosts makes avoidance very hard Rotate active responders within address blockPayload Signatures and Caching: Payload Signatures and Caching Compute MD5(payload without headers) Only store payload if MD5 is new MD5 signature cache hit rate 96% Same “stuff” seen repeatedly Factor of 2 savings in disk MD5 Signature Cache hit rate over 16 days at three sensorsSlide19: Recent Deployment ResultsIMS Deployment: IMS Deployment Tier 1 ISPs, Large Enterprise, Broadband, Academic, National ISPs, Regional ISPs Initial /8 deployment in 2001. Currently 60 address blocks at 18 networks on 3 continents Deployment Statistics: Deployment Statistics DDoS Reconnaissance/Scanning Internet Worms Bots! 17,094,016 IPs monitored 1.25% of routed IPv4 space 27 /8 blocks with an IMS sensor 21% of all routable /8 blocks have at least one sensor IMS has provided insight into:Recent TCP/42 Activity: Recent TCP/42 Activity November 24, 2004 vulnerability announced on remotely exploitable overflow in the WINS server component of Microsoft Windows December 2004, an increase in activity to tcp/42 was reported January 2005, news of significant amounts of increased activity on tcp/42 was noted in multiple reports. Vulnerability Announced Increased Activity Detected Significant Activity Reported Exploit PublishedTCP/42 Payloads: TCP/42 Payloads Captured live payloads that match byte-for-byte with template exploit code Same exploit is being reused to inject many different payloads (same exploit with very different shellcode) Evidence suggest attacks are from manual tools not automated worm. However vulnerability is “wormable” http://ims.eecs.umich.edu/reports/port42/Recent TCP/6101 Activity: Recent TCP/6101 Activity December 16, 2004 iDEFENSE Announces Buffer overflow vulnerability in Veritas Backup Agent January 11, 2005 Hat-Squad publishes exploit code January 11, 2005 IMS detects activity on TCP/6101 Vulnerability Announced Significant Activity Reported Exploit PublishedTCP/6101 Payloads: TCP/6101 Payloads Captured live payloads that match byte-for-byte with template exploit code Evidence suggest attacks are from manual tools not automated worm. However vulnerability is “wormable” Both port 42/6101 were zero-day threats! Exploit released and the same day the attacks began http://ims.eecs.umich.edu/reports/port6101/IMS Insights into Threat Trends: Worms: IMS Insights into Threat Trends: Worms Demographics Korea no longer top spot (TLD analysis) Global broadband still biggest source (2LD) Exploit trends Faster time to market? Faster cleanup Hours, not days Escalated Threats DDoS agent carrier, spread is DDoS PersistenceWorm persistence: Worm persistence 100,000s of infected hosts left over from infections dating by to 2001! Packets Unique HostsRise of the Zombies: Rise of the Zombies New personal attacks often rely on an another resource (e.g. phishing site, SPAM relay) Anonymous use of resource highly desirable => attackers use another compromised system as a proxy! Attackers have learned a compromised system is more useful alive than dead!Big Bad Bots: Big Bad Bots Total infected bot hosts 800,000 - 900,000 [CERT CA-2003-08] > 100,000 nodes/botnet 1000’s of new bots each day [Symantec 2005] Many articles/press citing thousands of infected hosts [IEEE S&P, Register] Difficult to measure: => Population likely much much larger!Bot/Botnet Measurements - Operators: Bot/Botnet Measurements - Operators Very little hard data on botnets! We asked operators (five Tier-1 & Tier-2 ops): They are actively fighting the problem # of Botnets - increasing Bots per Botnet - decreasing Used to be 80k-140k, now 1000s (evasion/economics?) More firepower: Broadband (1Mbps Up) x 100s == OC3!!! Custom botnets (all .edu, .gov/.mil) - economics? Bots Futures: Bots Futures Bots provide support infrastructure for a large range of devastating Internet attacks IRC-based botnet detection may be effective tool today Tomorrow must focus on holistic view of bot behavior - detect infections, command, and behavior Interesting questions: How do we measure bots? Who is responsible for cleanup? (Organizations/ISPs/Law Enforcement) Global enforcement => bots in US attack China?Slide32: IMS ToolIMS Portal: Basics: IMS Portal: BasicsIMS Portal: Analysis: IMS Portal: Analysis Each view can also be analyzed in a number of ways: => Cumulative unique source IP’s over time => Cumulative unique MD5 signatures over time => Top offending source IP’s => Top offending source IP’s (with reverse DNS) => Top payload signatures Smoothing filters can be applied to all graphs Results can be filtered by source IPIMS Portal: Analysis: IMS Portal: AnalysisIMS Portal: Signatures: IMS Portal: Signatures Each unique payload captured by IMS is stored in its entirety All unique payloads can be viewed using the IMS Portal Clicking on a signature fetches the binary from the remote sensor The binary data is fed to tethereal Analysis is shown in real-timeIMS Portal: Signatures: IMS Portal: SignaturesIMS Portal: Aggregation: Each sensor process data independently so its possible to run queries in parallel We leverage this ability with the IMS aggregation feature => TCP over EECS & CAEN The output is automatically normalized so that results from different sensors with different sized can be compared => TCP port 135 over EECS /24 and a /18 Can track threat between sensors IMS Portal: AggregationIMS Portal: Aggregation: IMS Portal: AggregationIMS Alert!: IMS Alert! IMS alerting system Automatically detect emerging threats Notify subscribers with relevant information Alert: detect a significant increase in number of unique sources contacting a specific port Compare average number of unique sources contacting over last 12 hours vs. previous 6 days If recent average > 3x historical “norm”, then alert Avoids using human defined threshold; universal across all portsExample: MySQL worm: Example: MySQL wormWhat you need to deploy IMS: What you need to deploy IMS 1+ blocks of unused address space within your public or private network (> /24) Advertise blocks and route to IMS sensor Rack, power, IP_ADDRs for a two interfaces Management BlackholeWhat you get: What you get Reports Global IMS Networks Alerts IMS Portal access to your sensor and other IMS participants Local data store: optimized binary format set of command-line tools to assist in access to the data store machine# logview /var/data 03-04-2004 05-15-2004 23:57:43 00024c30 10.49.151.77 768 > 192.168.100.158 768 ICMPPrivacy: Privacy Data providers keep local copies of their data Aggregated data is shared only among IMS participants Michigan is a center for the DHS PREDICT project and we will disseminated data through that project We are in the IRB process to release additional data Outreach: Outreach IMS used daily by operator community to investigate new threats We provide reports and forensics to NSP-SEC and NANOG operator community Higher Ed: Recently deployed at REN-ISAC Planning an academic community to share data with each otherAcknowledgements: Acknowledgements For more information on the Internet Motion Sensor: http://ims.eecs.umich.edu ims@umich.edu Thanks to the ISPs, academic institutions, and organizations for hosting the IMS! Thanks to Danny McPherson, Jose Nazario, Robert Stone, Rob Malan, and Dug Song at Arbor Networks and Larry Blunk, Bert Rossi, and Manish Karir at Merit Network. And of course our sponsor: