From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 21

1,252 Words. Plan about 8 minute(s) to read this.

Last section on this chapter that’s taken me way longer to plow through than I’d expected. We’ll talk about general recommendations, ACLs and ACEs, smurf attacks, sundry TCP header bits, and the like. Prepare to review what you think you already know.

General Layer 3 Security Recommendations

  • Secure telnet to the router, and use SSH instead of telnet if you can.
  • Use SNMP security, and move up to SNMPv3 if you can.
  • Disable all unneeded service on the router. (You know, like “tcp-small-servers”, the http GUI engine, that kind of stuff.)
  • Turn on logging so that there’s an audit trail.
  • Use routing protocol authentication.
  • Use CEF to avoid flow-based paths like fast-switching.
  • RFCs 2827 and 3704 describe other router-protection best-practices.
    • If your company owns a specific IP block, traffic from that block shouldn’t be coming inbound to you from the Internet.
    • Drop packets with non-unicast source IP’s (like 127.0.0.1, broadcast, multicast, etc.)
    • Subnet-specific broadcasts should not be allowed unless you have a good reason.
    • If you don’t have a route back to the source IP of an inbound packet, drop it. This is called the reverse-path-forwarding check.

IP Access Control Lists (I’m going to keep my comments on ACLs high-level. The book goes into quite a bit of detail. I’ll hit the highlights, but I’m making the hopefully correct assumption that if you’re reading this page, you’ve probably done a lot of ACL maintenance work. I know I have, and I still screw them up when I’m not paying attention, like today when I totally lost my train of thought when a router unexpectedly lost its freaking mind, barfed up a massive traceback, and discourteously hurled me into ROMMON. Lucky for me, I was on the console port and captured the whole ugly event on film, so to speak. But then when I got back to my actual ACL review after resetting the router, I blew it completely. Duh. I was distracted, I swear!)

  • The book mentions a healthy list of IOS commands for creating access lists and access control entries. I’m not listing them. I’ll go nuts if I do. And you don’t want to see that. You just don’t.
  • A quick ACL primer
    • gt – greater than
    • lt – less than
    • eq – equals
    • ne – not equal
    • range – range of port numbers, inclusive
    • established – matches if the TCP header ACK flag is set. This is the case of all except the first segment of a new connection setup.
    • log – generate a periodic log message, once for the first hit, and once every 5 minutes after that.
    • log-input – same as “log”, except there’s more info about the incoming interface of the packet matching the ACE.
    • standard ACLs – only match on source IP, 1-99 and 1300-1999.
    • extended ACLs – 100-199 and 2000-2699.
    • numbered ACLs can’t delete one ACE at a time; named ACLs can using sequence numbers.
    • You match IP address groups in ACEs using a wildcard mask, which is the same as a regular mask, but the bits are flipped. If a regular mask is 255.255.254.0, the wildcard mask would be 0.0.1.255.

General Layer 3 Security Considerations

  • Smurf Attacks
    • A host sending a large number of ICMP echo requests with strange IP addresses as the destination – a subnet broadcast address, aka directed broadcast address. Every host on the targetted LAN segment will get a copy of the broadcast. They will all respond with an ICMP echo reply, but the reply will not go the originator. Rather, the respond will go to someone on their LAN segment that is the end target of the attack.
    • Smurfy mitigation strategies
      • Hire Azrael.
      • “no ip directed-broadcast” – interface command will prevent a router from forwarding that directed-broadcast onto the LAN segment.
      • “ip verify unicast source reachable-via {rx|any} [allow-default][allow-self-ping][list] enabled the reverse path forwarding check.
        • Strict RPF – uses the RX keyword. Verifies that there’s a route back to the source that exactly matches the interface the packet arrived on (potentially not nice in async routing environments).
        • Loose RPF – uses the any keyword. Verifies that there’s any route back to the source.
        • “allow-default” will allow a default route to match the RPF check.
        • “allow-self-ping” sets off a ping from the router to the source to verify the connectivity. (Icky-poo. Could you imagine this on a busy production router?)
        • If used, the “list” would be an ACL telling the router which IPs must pass an RPF check.
  • Fraggle attack – same as a smurf attack, but with UDP echos instead of ICMP. Same mitigation strategies.
  • Inappropriate IP addresses – IPs known to carry smut and anarchy websites. Not really. What we’re talking about here are attacks sourced from IP addresses that don’t make sense in the context of your network. Should you ever see packets from your ASN coming in from OUTSIDE your ASN? No…no you should not. Probably an attack of some kind. Should you ever see RFC1918 addresses on the Internet flowing into your network? Nay, thou shouldest not. Should you route traffic for IPs that are not currently allocated by the IANA? Nope. These sorts of IPs are called “bogons”.
    • You can use a freeware tool called Router Audit Tool (RAT) for general router security recommendations, including a bogon ACL.
    • Cisco offers the IOS AutoSecure feature to build bogon ACLs, among other functions. (I had not heard of AutoSecure, but here it is.)
  • TCP SYN Flood attacks
    • A SYN flood is a large number of TCP connections that never finish. The attacker sends in a SYN, and the receiver responds with a SYN/ACK. At which point, the attacker is supposed to finalize the socket open request with an ACK. But he doesn’t…because he’s an attacker. And he’s evil. And we hate him. Instead, the evil, hated attacker keeps half-opening TCP connections, intending to bring down the host he’s attacking by exhausting his precious TCP stack resources.
    • Flooding mitigation strategies
      • Build an ark
      • Remember that firewalls are really cut out to mitigate this sort of attack.
      • Use IOS to filter packets with only the SYN flag set. This presumes that you shouldn’t accept inbound SYNs to certain hosts, ergo, that those host should only be initiating outbound conversations, but not accepting new connections inbound. IOS can’t match on the SYN flag specifically, but you can use the established keyword in an ACE, which matches everything that has the ACK flag set. This matches anything that isn’t the very first TCP packet sent in a new conversation, ergo, the SYN packet.
      • Use the IOS TCP intercept feature.
        • Watch mode – the router maintains state information about TCP connections. If a TCP connection doesn’t complete in a timely fashion, TCP intercept will send a RST to the server, cleaning up the connection. Also, if TCP intercept detects more than 1100 new connections in a single second, new connections get dropped.
        • Intercept mode – the router actually replies to inbound TCP requests itself. If the 3-way handshake completes between the client and the router, the router will create a connection between the router and the server, and forwards between the two. This is a little hard on the router.
        • IOS commands to configure tcp intercept:
          • “ip tcp intercept mode watch” – enables watch mode instead of the default of intercept.
          • “ip tcp intercept-list <list>” – tells the router which packets to watch based on the ACL.
          • “ip tcp intercept watch-timeout <seconds>” – allows you to set a timeout value on the 3-way handshake to a value other than 30 seconds.