Is this the backwards approach? Know what to call it, then hope you recognize it when you see it? Not exactly. Know what to expect and implement measures to defeat it.
In some cases, there are patches which enable applications to recover from attacks more gracefully.
|Denial of Service||A variety of attacks consume resources (such as bandwidth, CPU, memory, ports, or file system quotas) and prevent intended use of resources|
|Smurf||Spoofed ICMP Echo request receives replies which overwhelm victim and network||
|Fraggle||See Smurf, but change ICMP to UDP.||
|SYN Flood||TCP packet with SYN flag (and probably spoofed IP address) received, TCP packet with SYN and ACK flags sent, then … nothing. Do this enough times, and the server cannot accept requests until the spurious connections time out.||
|Teardrop||Maliciously crafted small packet fragments which cannot be “recombined”.||
|MAC flood||Spoofed source MAC address and port in packet (requests a destination, of course); this takes a slot in the CAM table and broadcasts requests for the destination MAC address. Repeat sufficiently and fill the CAM table and consume bandwidth. This is a layer 2 attack which requires port access; port access can reveal information to a network device in promiscuous mode.||
|ICMP Sting||No such thing|
|Distributed Denial of Service (DDoS)||Denial of Service (DoS) technique, but originating from multiple sources.||
The TLS renegotiation attack is explained at educatedguesswork.org, and tested at netsekure.org. Note that there are many mitigation methods (alunj blog, F5 community post), so simply having a web server platform which accepts renegotiation requests does not mean that your application is vulnerable. See the Qualys SSL Labs SSL Server Test for examples of servers which superficially accept TLS renegotiation, but upon further inspection (at netsekure.org) can be found to be not vulnerable. Note: If you are vulnerable, you should fail a PCI DSS audit.
Was my IP address known to be communicating with the Shady Rat Command and Control servers (that is, was I compromised)?
Have an internal system that isn’t using port 80? Consider implementing a “honeyport” to capture malicious internal activity.
See also: Verizon 2011 Data Breach Investigations Report: Breaches Increased Dramatically While Data Loss Was at All-Time Low