Attacks

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.

• Disable broadcast
• Reject inbound packets from internal networks (spoofed addresses)
• Filter ICMP traffic
• Your IDS probably logs Smurf attacks
• Install patches

Fraggle: See Smurf, but change ICMP to UDP.

• Disable broadcast
• Reject inbound packets from internal networks (spoofed addresses)
• Filter UDP traffic
• Your IDS probably logs Fraggle attacks
• Install patches

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.

• Decrease timeout
• Increase connections
• Your IDS probably logs SYN flood attacks
• Your IPS / firewall should be catching SYN flood attacks
• Install patches

Teardrop: Maliciously crafted small packet fragments which cannot be “recombined”.

• Drop malformed packets
• Reassemble packets at the router before forwarding them.
• Install patches

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.

• Limit number of source MACs per port
  Switch(config-if)#switchport port-security [maximum value]
violation {protect | restrict | shutdown}
• Restrict port to specific addresses

Distributed Denial of Service (DDoS): Denial of Service (DoS) technique, but originating from multiple sources.

• Bandwidth over-provisioning
• Your IDS probably logs the Smurf / Fraggle / SYN flood attacks
• Verisign Internet Defense Network “in the cloud” measure which profiles your normal activity and omits unusual activity upon demand
• Corero ReputationWatch blocks access to “bad” IP addresses on-the-fly based on reputation or geographic origin to dynamically stop DDoS attacks and other malicious activity
• See Hemant Jain’s Distributed Denial of Service Attacks – A Primer, and slide decks such as 10 DDoS mitigation techniques,
• IPv6 and multiple spoofed IP addresses may make your blacklist pproach obsolete
• DDoSAttacks.biz information from Neustar
• Blog from 360 Netlab regarding DDos

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

Attack of the Shuriken 2015: Many Hands, Many Weapons lists many DDoS attack types.