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
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

About these ads

Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: