Network Security Defense

Fernando Gont

8th Regional CaribNOG Meeting Willemstad, Curacao. September 29-October 3, 2014 About...

●I have worked in security assessment of communication protocols for:

●UK NISCC (National Infrastructure Security Co-ordination Centre)

●UK CPNI (Centre for the Protection of National Infrastructure)

●Currently working as a security researcher and consultant for SI6 Networks (http://www.si6networks.com)

●Active participant at the Internet Engineering Task Force (IETF)

●Moderator of LACNIC's security forum

●More information at: http://www.gont.com.ar

●Do a brief introduction of Information and Network Securty

●Walk up the protocol stack

●Discuss vulnerabilities

●Discuss possible mitigation techniques

●Confidentiality

●Prevent unauthorized use or disclosure of information

●Integrity

●Safeguards the accuracy and completeness of information

●Availability

●authorized users have reliable and timely access to information

●privacy vs. company (or govt) wants to be able to see what you’re doing

●losing data vs disclosure (copies of keys)

●denial of service vs preventing intrusion

●Source: Radia Perlman's “Network Security Protocols: A Tutorial” (2004)

●The ability to permit or deny the use of an object by a subject.

●It provides 3 essential services:

●Authentication (who can login)

●Authorization (what authorized users can do)

●Accountability (what a user did)

●A means to verify or prove a user’s identity

●The term “user” may refer to:

●Person

●Application or process

●Machine or device

●To prove identity, a user must present either of the following:

●What you know (password)

●What you have (token, key, etc.)

●Who you are (biometrics)

●Defines the user’s rights and permissions on a system

●Grants a user access to a particular resource and what actions he is permitted to perform on that resource

● Access criteria based on the level of trust:

●Roles

●Groups

●Location

●Time

●Transaction type

●Security goal that generates the requirement for actions of an entity to be traced uniquely to that entity, e.g.:

●Senders cannot deny sending information

●Receivers cannot deny receiving it

●Users cannot deny performing a certain action

●Security goal that generates the requirement for protection against either intentional or accidental attempts to violate data or system integrity

●Data integrity

●The property that data has when it has not been altered in an unauthorized manner

●System integrity

●The property that a system has when it performs its intended function in an unimpaired manner, free from unauthorized manipulation

●“Limit the damage that can be produced by an event”

●e.g., compartments and watertight subdivision's of a ship's hull:

●Examples:

●Multiple smaller subnets vs. single large subnets

●Single admin account vs. multiple per-service admin accounts

●A weakness in security procedures, network design, or implementation that can be exploited to violate a security policy

●Software bugs

●Configuration mistakes

●Network design flaw

●Lack of encryption

●The active exploitation of a vulnerability

●Masquerading

● An entity claims to be another entity

●Eavesdropping

●An entity reads information it is not intended to read

●Authorization violation

●An entity uses a service or resource it is not intended to use

●Loss or modification of information

●Data is being altered or destroyed

●Denial of communication acts (repudiation)

●An entity falsely denies its participation in a communication act

●Denial of Service

●Any action that aims to reduce the availability and/or correct functioning of services or systems

●Unauthorized users to gather information about the network or system before launching other more serious types of attacks

●Information gained from this attack is used in subsequent attacks

●Examples of relevant information:

●Names, email addresses

●Nodes' addresses

●Domain names

●Network topology

●Attempt to make a machine or network resource unavailable to its intended users.

●Methods to carry out this attack may vary

●Saturating the target with external communications requests (such that it can’t respond to legitimate traffic) – SERVER OVERLOAD

●Simply

●Examples:

●SYN flooding

●Reflection attacks

●DDoS attacks are more dynamic and come from a broader range of attackers

●OSI Reference model:

●DARPA Reference model:

OSI layer-7 OSI layer-4 OSI layer-3

OSI layer-1

●Layer-2 attacks include:

●Eavesdropping (sniffing)

●ARP Spoofing

●MAC flooding

●DHCPv4/DHCPv6 attacks

●IPv6 ND attacks

●IPv6 SLAAC attacks

●Goal: Gain unauthorized access to information being transmitted over a communications channel

●For “shared media” networks, this can be as simple as running the so- called “protocol analyzers”:

●e.g. Wireshark

●Do not use insecure protocols

●HTTPS vs HTTP

●Telnet vs. SSH

●etc.

●Where possible, prevent unnecessary access (“compartmentalize”)

●The Address Resolution Protocol (ARP) maps IP addresses into link- layer addresses

●It works (roughly) as follows:

●Host A wants to send a packet to Host B

●Host A sends an ARP request to all nodes “Who has IP address B?”

●Host B sends an ARP response to Host A: “I have IP address B, and my MAC address is 11:22:33:44:55:66”

●Host A can now send its packets

●Forging ARP response packets can be used for Man In the Middle Attacks

●ARP cache poisoning prevention

●Static ARP cache entries

●ARP inspection (e.g., Cisco's DAI)

●ARP spoofing detection

●arpwatch

●Add a static entry In Linux:

●arp -i INTERFACE -s IP_ADDRESS HARDWARE_ADDRESS

●Show current entries (Linux):

●arp

●Monitor ARP request/response exchanges, and only allow valid mappings

●Valid mappings can be:

●manually-configured

●dynamically learned (e.g., by monitoring DHCP packets)

●Cisco's implementation: DAI (Dynamic ARP Inspection)

●Monitor ARP request/response exchanges

●Contrast them against a local database

●Report invalid mappings

●Open-source implementation: arpwatch

●Goal: DoS to clients

●Vector #1:

●Masquerade the server: Forge DHCP responses, denying IP addresses

●Vector #2:

●Masquerade as clients: Forge lots of DHCP request, to exhaust the address pool

●Protect the client:

●DHCP snooping

●DHCPv6 Shield (IPv6-version of DHCP snooping)

●Protect the server:

●ARP monitoring (e.g., Cisco's DAI)

●ND-monitoring (e.g. Cisco's First Hop Security)

●Mitigation technique employed on the local switch

●It (roughly) works as follows:

●The switch is configured with the port where the DHCP server is connected

●The switch monitors traffic, and only allows DHCP-server packets on the configured port

●Goal: To allow eavesdropping on a switched network.

●It (roughly) works as follows:

●The switch has a CAM (Content Addressable memory) table, that stores mappings of MAC address -> physical port

●The client forges lots ARP packets, thus exhausting the CAM table

●The switch falls-back to “hub” operation: all packets are now transmitted on all ports

●The attacker can now eavesdrop the network

●Same as for ARP cache poisoning

●Essentially, IPv6's ARP

●Employs ICMPv6 Neighbor Solicitation and Neighbor Advertisement -- so it's not really “layer-2”

●It (roughly) works as follows:

●Host A sends a NS: Who has IPv6 address B?

●Host B responds with a NA: I have IPv6 address B, and the corresponding MAC address is 06:09:12:cf:db:55.

●Host A caches the received information in a “Neighbor Cache” for some period of time (this is similar to IPv4’s ARP cache)

●Host A can now send packets to Host B

●Essentially IPv6 versions of IPv4's ARP attacks

●Additional concern:

●There's no “artificial limit” for the Neighbor Cache size

●Deploy SEND (SEcure Neighbor Discovery)

●Monitor Neighbor Discovery traffic (e.g., with ipv6mon)

●Restrict access to the local network

●Use static entries in the Neighbor Cache

●Cryptographic approach to the problem of forged Neighbor Solicitation messages:

●Certification paths certify the authority of routers

●Cryptographically-Generated Addresses (CGA) bind IPv6 addresses to an asymmetric key pair

●RSA signatures protect all Neighbor Discovery messages

●SEND is hard to deploy:

●Not widely supported

●The requirement of a PKI is a key obstacle for its deployment

●Other key pieces of the puzzle remain unsolved (DNS, etc.)

●Some tools (e.g. NDPMon) keep record of the legitimate mappings (IPv6 -> Ethernet), and sound an alarm if the mapping changes

●This is similar to arpwatch in IPv4

●However, these tools can be trivially evaded:

●ND runs on top of IPv6

●Packets may contain IPv6 Extension Headers

●Packets may be fragmented

●And since traffic occurs in the local network, there is no "man in the middle" to reassemble the packets or "normalize" them

●Fundamental problem: complexity of traffic to be “processed at layer-2”

●Example:

●Partitioning a network limits the impact of a possible attack

●However,

●It increases complexity

●Costs money

●There's always a limit for the extent to which you can partition a network

●Static entries avoid "dynamic" mapping

●This is similar to static entries in the ARP Cache en IPv4

●If a static NC entry is present for an IPv6, the host need not employ Neighbor Discovery

●Beware that some implementations used to remain vulnerable to ND attacks anyway!

●The Neighbor Cache is manipulated with the "ndp" command

●Static entries are added as follows:

●# ndp –s IPV6ADDR MACADDR

●If IPV6ADDR is a link-local address, an interface index is specified as follows:

●# ndp –s IPV6ADDR%IFACE MACADDR

●An attacker performs a brute-force scan of a /64

●The attack creates one NC entry per address at the last-hop router

●The last-hop router can't handle it

●Use smaller subnets for PTP links (e.g. /126)

●Enforce ACLs at the last-hop routers (e.g., in DMZs)

●Enforce artificial limits on the number of entries in the NC

●Two auto-configuration mechanisms in IPv6:

●Stateless Address Auto-Configuration (SLAAC)

–Based on ICMPv6 messages

●DHCPv6

–Based on UDP packets

●SLAAC is mandatory, while DHCPv6 is optional

●Basic operation of SLAAC:

●Host solicit configuration information by sending Router Solicitation messages

●Routers convey that information in Router Advertisement messages:

●Essentially the same as DHCP attacks against clients

●Additional concern:

●No artificial limit for e.g. number of addresses to be configured at the client

●Deploy SEND (SEcure Neighbor Discovery)

●Monitor Neighbor Discovery traffic (e.g., with NDPMon)

●Restrict access to the local network

●Deploy Router Advertisement Guard (RA-Guard)

●Filtering policy enforced by layer-2 devices

●Works (roughly) as follows:

●RA-Guard allows RAs only if they are received on pre-specified ports

●Otherwise, they are dropped

●RA-Guard assumes that it is possible to identify RAs

●All known implementations can be evaded with IPv6 Extension Headers and/or fragmentation

●Fundamental problem: complexity of traffic to be “processed at layer-2”

●Example:

●Layer-3 attacks include:

●IPv4/IPv6 address forgery/spoofing (and variants)

●IPv4/IPv6 fragment flooding

●Routing Protocols attacks

●Issues arising from IPv4/IPv6 interaction

●IP address scanning attacks

●Evasion of Security Controls

●Strictly speaking, nodes can configure any address that they want

●Forged IP addresses can result in:

●IPv4/IPv6 trust relationship exploitation

●Reflection attacks

●IP smurf attacks

●Network ingress filtering (BCP38) is “being a good network citizen”

●Unfortunately, it is not widely enforced

●IP address-based trust is poor's man trust relationship

●Access controls based on IP source address can be trivially circumvented

●They are DoS attacks in which the actual attack traffic hitting he victim is sent by a third-party (the reflector)

●It is a reflection attack that employs subnet-directed broadcast destination addresses for amplification

●Filter packets destined to subnet-directed broadcast addresses at your network edge

●IP fragment reassembly is a stateful operation for an (otherwise) stateless protocol:

●A node that receives a fragment must store the fragment and wait for the other fragments to perform fragment reassembly

●An attacker can send lots of forged fragments to a victim for DoS purposes

●It is difficult to defend against this sort of attack

●To the extent that is possible, avoid the use of IP fragmentation

●Enforce OS-level limits, for compartmentalization purposes

●Some operators are known to filter IP fragments altogether

●net.inet6.ip6.maxfragpackets: maximum number of fragmented packets the node will accept

●defaults to 200 in OpenBSD and 2160 in FreeBSD

●0: the node does not accept fragmented traffic

●-1: there’s no limit on the number of fragmented packets

● net.inet6.ip6.maxfrags: maximum number of fragments the node will accept

●defaults to 200 in OpenBSD and 2160 in FreeBSD

●0: the node will not accept any fragments

●-1: there is no limit on the number of fragments

●Unless proper authentication is in place routing messages can be tampered with.

●Additionally, an authenticated message might contain un-authorized data

●Mitigations depend on the specific routnig protocol

●e.g., for BGP this may include:

●TCP-MD5/TCP-AO for protecting the underlying TCP connection

●GTSM for compartmentalization

●RPKI for validating the routing information

●Most systems have some some IPv6 support enabled by default

●Dual stack

●Teredo

●ISATAP

●etc.

●As a result,

●Most “IPv4 networks” have already partially deployed IPv6

●Dormant IPv6 support can be enabled on an “IPv4-only” network:

●Sending Router Advertisements

●Enabling transition/co-existence technologies

●Transition technologies may increase host exposure

●Teredo enables NAT traversal

●As a result,

●There are no “IPv4-only” networks

●IPv6 security implications should also be considered for IPv4 networks

●If you don't mean to employ IPv6, make sure that that is the case

Transition technology Filtering rule Dual-stack Automatic (if network does not support IPv6) or EtherType == 0x86DD IPv6-in-IPv4 tunnels IPv4.Protocol == 41 6to4 IPv4.Protocol == 41 && IPv4.{src,dst} == 192.88.99.0/24 ISATAP IPv4.Protocol == 41 Teredo IPv4.dst == known_teredo_servers && UDP.DstPort == 3544 TSP (IP proto 41) || (UDP Dest Port 3653 || TCP Dest Port 3653)

●Typical scenario:

●You connect to an insecure network

●You establish a VPN with your home/office

●Your VPN software does not support IPv6

●Trivial to trigger a VPN leakage

●Spoof RA's or DHCPv6-server packets, to set the recursive DNS server

●Simply trigger IPv6 connectivity, such that dual-stacked hosts leak out

●Even legitimate dual-stacked networks may trigger it

●Mitigation:

●Employ IPv6-enabled VPN software

●The IPv4 address search space is small

●Brute-force address scans are “good enough” and “feasible”

●It is trivial to sweep an entire prefix, or even the whole Internet address space

●Tools:

●nmap

●zmap

●etc.

| n bits | m bits | 128-n-m bits |

Global Routing Prefix Subnet ID Interface ID

●A number of possibilities for generating the Interface ID:

●Embed the MAC address (traditional SLAAC)

●Embed the IPv4 address (e.g. 2001:db8::192.168.1.1)

●Low-byte (e.g. 2001:db8::1, 2001:db8::2, etc.)

●Wordy (e.g. 2001:db8::dead:beef)

●According to a transition/co-existence technology (6to4, etc.)

“Thanks to the increased IPv6 address space, IPv6 host scanning attacks are unfeasible. Scanning a /64 would take 500.000.000 years” – Urban legend

Is the search space for a /64 really 264 addresses?

●Leverage IPv6 all-nodes link-local multicast address

●Employ multiple probe types:

●Normal multicasted ICMPv6 echo requests (don't work for Windows)

●Unrecognized options of type 10xxxxxx

●Combine learned IIDs with known prefixes to learn all addresses

●Example:

●# scan6 -i eth0 -L

●IPv6 address scanning attacks are feasible, but typically harder than in IPv4

●They require more “intelligence” on the side of the attacker

●It is possible to make them infeasible

●Do not employ predictable addresses!

●For local address scans:

●Do not respond to multicasted ICMPv6 echo requests

–Currently implemented in Windows

●However, it's virtually impossible to mitigate IPv6 address scanning of local networks

–Think about mDNS, etc.

●Generally achieved by “confusing” the network security device

●Security device tricked to believe traffic is non-malicious

●Evasion techniques are protocol-dependent, e.g.:

●IPv6/IPv4 fragmentation

●Use of IPv6 Extension header

●Transport-protocols can be subject to various types of attacks.

●TCP attacks include:

●SYN-floods

●Connection-reset attacks

●Connection-flooding attacks

●Reflection attacks

●TCP requires that the endpoints of a connection keep track of the current connection state.

●The initial packet (SYN) of a connection can be trivially forged.

LISTEN

SYN-RECEIVED

ESTABLISHED

●The attacker sends many forged TCP SYN segments

●The limit of “pending connections” is hit

●Further connections cannot be established

●The tcp6 tool can send arbitrary TCP/IPv6 packets

●SYN-flood attack:

●# tcp6 -s SRCPRF -d TARGET -a DSTPORT -X S -F 100 -l -z 1 -v

●Goal is to reduce the amount of state kept at the victim node

●Main mitigation: SYN cookies

●The incoming SYN does not create a connection in the SYN-RECEIVED state

●The sate information is encoded in the SYN/ACK packet, and decoded in the final ACK.

●Drawbacks of SYN cookies:

●They can only encode so many bits of state

●e.g., they cannot encode the values of all TCP options

●Layer-7 (Application) attacks vary from application to application

●Some of the generic attacks for web-based applications are:

●SQL injection

●cross-site-scripting

●etc.

●DNS cache poisoning attacks have been known and exploited for a long time

●Off-path attacks trivial (at some point) due to predictable port numbers and TxIDs

●On-path attacks still trivial, since mot domains are not really signed

●The DNS supports one primary and a number of secondary servers (for each zone) for redundancy purposes

●Secondary servers can update their zone data via zone transfers (AXFR)

●Primary DNS servers should only allow AXFR from secondary servers

●Allowing zone transfers from any DNS stub would reduce in an information leakage

●DNS zrsily checked with:

●dig @NAMESERVER ZONE axfr

●Layer-3: IPsec

●Layer-4: SSL/TLS

●Layer-7: PGP

●IETF's Internet Security Architecture

●Can operate in both client mode or transport mode

●Transport mode: sits between IP and the transport protocol

●Tunnel mode: Encapsulates entire IP packets

●Main deployment obstacle: requirement for a PKI

●TLS and SSL encrypts the segments of network connections above the Transport Layer.

● Versions:

●SSLv1 – designed by Netscape

●SSLv2 – publicly released in 1994; has a number of security flaws; uses RC4 for encryption and MD5 for authentication

●SSLv3 – added support for DSS for authentication and DH for key agreement

●TLS – based on SSLv3; uses DSS for authentication, DH for key agreement, and 3DES for encryption

●TLS is the IETF standard which succeeded SSL.

●Layer 3 idea: don’t change applications or API to applications, just OS

●Layer 4 idea: don’t change OS, only change application. They run on top of layer 4 (TCP/UDP)

●layer 3 technically superior

●Rogue packet problem

–TCP doesn’t participate in crypto, so attacker can inject bogus packet, no way for TCP to recover

●easier to do outboard hardware processing (since each packet independently encrypted)

●layer 4 easier to deploy

●And unless API changes, layer 3 can’t pass up authenticated identity

●IPv6 options are included in “extension headers”

●These headers sit between the IPv6 header and the upper-layer protocol

●There may be multiple instances, of multiple extension headers, each with multiple options

●Hence, IPv6 follow a “header chain” type structure. e.g.,

●Large number of headers/options may have a negative impact on performance

●It is harder to spot e.g. layer-4 information (if at all possible)

●Many routers can only look into a few dozen bytes into the packet

●State-less IPv6 packet can be quite difficult:

●The attacker sets the Hop Limit to a value such that the NIDS sensor receives the packet, but the target host does not.

●Counter-measure: Normalize the “Hop Limit” at the network edge (e.g. to 64) or block incomming packets small “Hop Limits”

●An attacker can exploit IPv4 overlapping fragments to create ambiguity and evade a NIDS

Attacker

Victim Result

NIDS

Fernando Gont [email protected]

IPv6 Hackers mailing-list http://www.si6networks.com/community/

www.si6networks.com