One Article Review
| Source |  Errata Security |
|---|---|
| Identifiant | 8304047 |
| Date de publication | 2023-01-25 16:09:34 (vue: 2023-01-25 22:05:52) |
| Titre | I\'m still bitter about Slammer |
| Texte | Today is the 20th anniversary of the Slammer worm. I'm still angry over it, so I thought I'd write up my anger. This post will be of interest to nobody, it's just me venting my bitterness and get off my lawn!!Back in the day, I wrote "BlackICE", an intrusion detection and prevention system that ran as both a desktop version and a network appliance. Most cybersec people from that time remember it as the desktop version, but the bulk of our sales came from the network appliance.The network appliance competed against other IDSs at the time, such as Snort, an open-source product. For much the cybersec industry, IDS was Snort -- they had no knowledge of how intrusion-detection would work other than this product, because it was open-source.My intrusion-detection technology was radically different. The thing that makes me angry is that I couldn't explain the differences to the community because they weren't technical enough.When Slammer hit, Snort and Snort-like products failed. Mine succeeded extremely well. Yet, I didn't get the credit for this.The first difference is that I used a custom poll-mode driver instead of interrupts. This the now the norm in the industry, such as with Linux NAPI drivers. The problem with interrupts is that a computer could handle less than 50,000 interrupts-per-second. If network traffic arrived faster than this, then the computer would hang, spending all it's time in the interrupt handler doing no other useful work. By turning off interrupts and instead polling for packets, this problem is prevented. The cost is that if the computer isn't heavily loaded by network traffic, then polling causes wasted CPU and electrical power. Linux NAPI drivers switch between them, interrupts when traffic is light and polling when traffic is heavy.The consequence is that a typical machine of the time (dual Pentium IIIs) could handle 2-million packets-per-second running my software, far better than the 50,000 packets-per-second of the competitors.When Slammer hit, it filled a 1-gbps Ethernet with 300,000 packets-per-second. As a consequence, pretty much all other IDS products fell over. Those that survived were attached to slower links -- 100-mbps was still common at the time.An industry luminary even gave a presentation at BlackHat saying that my claimed performance (2-million packets-per-second) was impossible, because everyone knew that computers couldn't handle traffic that fast. I couldn't combat that, even by explaining with very small words "but we disable interrupts".Now this is the norm. All network drivers are written with polling in mind. Specialized drivers like PF_RING and DPDK do even better. Networks appliances are now written using these things. Now you'd expect something like Snort to keep up and not get overloaded with interrupts. What makes me bitter is that back then, this was inexplicable magic.I wrote an article in PoC||GTFO 0x15 that shows how my portscanner masscan uses this driver, if you want more info.The second difference with my product was how signatures were written. Everyone else used signatures that triggered on the pattern-matching. Instead, my technology included protocol-analysis, code that parsed more than 100 protocols.The difference is that when there is an exploit of a buffer-overflow vulnerability, pattern-matching searched for patterns unique to the exploit. In my case, we'd measure the length of the buffer, triggering when it exceeded a certain length, finding any attempt to attack the vulnerability.The reason we could do this was through the use of state-machine parsers. Such analysis was considered heavy-weight and slow, which is why others avoided it. State-machines are faster than pattern-matching, many times faster. Better and faster.Such parsers are no |
| Envoyé | Oui |
| Condensat | 000 0x15 0x21 100 20th 300 39003 500 64k about accept accurate address after against aggregate all alternative analysis analyst and faster anger angry anniversary another any apache apologize appliance appliances are arrived article artificial attached attack attacker attempt avoided away back based because behind being believe better between big bit bitching bitter bitterness blackhat blackice both buffer bulk but came can case cases causes centralized certain chest choices claimed claiming clogging coalesced coalescer coalescing code combat common community competed competitors complaint complex computer computers conceive consequence considered console consoles correctly cost could couldn count cpu crazy creating credit custom customer customers cybersec data day ddos deliberately design designed desktop detection did didn difference differences different disable does doesn doing down dpdk driver driver instead drivers dual easily easy electrical else end enough etc ethernet even event events every everyone example exceeded excess exciting exciting: expect explain explaining exploit exploited extremely failed fall far fast faster fell filled finding first flaw flood forwarding from gartner gave gbps get gets gigabit gigabyte gives going had handle handler hang happening hardware has have heavily heavy higher hit how http identified ids idss iiis implement impossible included industry inexplicable info input instead interest intermix interrupt interrupts intrusion isn iss just keep knew knowledge last later lawn lead length less light lighthttpd like limit link links linux little load loaded logging logic luminary machine machines made magic makes management many masscan uses matching may mbps measure meeting method million mind mine mode modern months more most much napi needed network networks nginx nginx source nobody norm normal not now number off often one only open other others out over overflow overload overloaded packet packets paper parse parsed parsers pattern patterns pentagon pentium people per performance poc||gtfo point pointing poll polling portscanner post power practice presentation pretty prevent prevented prevention problem product products program protocol protocols radical radically ran ranges as read reader real reason recognize reduced refute remember remote repeated reported requests rightly ring roughly running sales saw saying searched second second difference sending sensor server servers ship shows signature signatures simplified simply slammer slow slower slowly small snort software somehow something sometimes source sources spaces specialized spending spoof spooling sql stand standing start state struggling subjecting succeeded successfully such survived sweep switch system systems targets techies technical technique technology tell test tested than them themselves then theory these they thing things third third difference those though thought three through throw thus time timeout times timestamp today traffic triggered triggering turning typical udp understand unique unprecedented unsure upshot uri use used useful using vain venting version very vulnerability want wasn wasted watching way wc wc2o web weight well weren what when where which why will word words work worked works world worm would write written wrote yet you |
| Tags | Vulnerability Guideline |
| Stories | |
| Notes | ★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.