Tải bản đầy đủ - 0 (trang)
Chapter 4. Routing Engine Protection and DDoS Prevention

Chapter 4. Routing Engine Protection and DDoS Prevention

Tải bản đầy đủ - 0trang

The goal of this section is to provide an up-to-date example of a strong RE protection

filter for both IPv4 and IPv6, and to address the topic of why basic filters may not guard

against resource depletion, which, if allowed to go unchecked, can halt a router’s operation just as effectively as any “hacker” who gains unauthorized access to the system

with nefarious intent.

The topic of router security is complex and widespread. So much so that informational

RFC 6192 was produced to outline IPv4 and IPv6 filtering best practices, along with

example filters for both IOS- and Junos OS-based products. There is much overlap

between the examples in this section and the RFC’s suggestions, which is a good sign,

as you can never have too many smart people thinking about security. and It’s good to

see different approaches and techniques as well as a confirmation that many complex

problems have common solutions that have been well tested.



IPv4 RE Protection Filter

This section provides the reader with a current best practice example of an RE protection filter for IPv4 traffic. Protection filters are applied in the input direction to filter

traffic arriving on PFE or management ports before it’s processed by the RE. Output

filters are generally used for CoS marking of locally generated control plane traffic, as

opposed to security-related reason as you generally trust your own routers and the

traffic they originate. Figure 4-1 provides the topology details that surround this case

study.



Figure 4-1. DDoS Protection Lab Topology.



236 | Chapter 4: Routing Engine Protection and DDoS Prevention



www.it-ebooks.info



The example, used with permission from Juniper Networks Books, is taken from Day

One: Securing the Routing Engine by Douglas Hanks, also the coauthor of this book.

Note: Router security is no small matter. The reader is encouraged to

examine the filter carefully before adapting it for use in his or her own

network.



The principles behind the filter’s operation and the specific rationale behind its design

framework are explained in the Day One book, and so are not repeated here in the

interest of brevity. The filter is included here as a case study example for several reasons:

• RE protection is important and needed, and this is a really good filter. There’s no

point in recreating an already perfectly round wheel, and the Day One book is freely

available as a PDF.

• The example makes great use of some important Junos features that are not necessarily MX-specific, and so have not been covered in this chapter, including filter

nesting (a filter calling another filter), apply-path, and prefix-list. All are powerful tools that can make managing and understanding a complex filter much simpler. The examples also make use of the apply-flags omit statement. This flag

results in the related configuration block not being displayed in a show configura

tion command, unless you pipe the results to display omit. Again, while not a filterspecific feature, this is another cool Junos capability that can be utilized to make

living with long filters that much easier.

• It’s a good test of this chapter and the reader’s comprehension of the same. This

is a real-world example of a complex filter that solves a real issue. While specific

protocol nuances, such as the specific multicast addresses used by OSPF, may not

be known, having arrived here, the reader should be able to follow the filter’s operation and use of policing with little guidance.

• The example is comprehensive, providing support for virtually all known legitimate routing protocols and services; be sure to remove support for any protocols

or services that are not currently used, either by deleting the filter in question or

by simply not including that filter in the list of filters that you ultimately apply to

the lo0 interface. For example, as IS-IS is used in the current lab, there is currently

no need for any OSPF-specific filter. Also, be sure to confirm that the prefix lists

contain all addresses that should be able to reach the related service or protocol.

When first applying the filter list, you should replace the final discard-all term with

one that matches all with an accept and log action. This is done as a safeguard to prevent

service disruption in the event that a valid service or protocol has not been accommodated by a previous term. After applying the filter, pay special attention to any log hits

indicating traffic has made it to the final catch-all term, as this may indicate you have

more filter work to do.



RE Protection Case Study | 237



www.it-ebooks.info



Before applying any RE filter, you should carefully evaluate both the

filters/terms and their application order to confirm that all valid services

and remote access methods are allowed. In addition, you must also edit

the sample prefix list to ensure they accurately reflect all internal and

external addresses from where the related services should be reachable.

Whenever making this type of change, console access should be available in the event that recovery is needed, and you should strongly consider the use of commit confirmed command.



When your filter is correctly matched to the particulars of your network, the only traffic

that should fall through to the final term should be that which is unsupported and

therefore unneeded, and safe to drop. Once it is so confirmed, you should make the

discard-all filter the last in the chain—its ongoing count and logging actions simplify

future troubleshooting when a new service is added and no one can figure out why it’s

not working. Yes, true security is a pain, but far less so in the long run then the lack of,

or worse yet, a false sense of security!

Let’s begin with the policy-related configuration where prefix lists are defined in such

a way that they automatically populate with addresses assigned to the system itself, as

well as well-known addresses associated with common protocols. This small bit of

upfront work makes later address-based matches a snap and makes ongoing address

and peer definition changes painless, as the filter automatically keeps up. Note that the

sample expressions catch all addresses assigned, including those on the management

network and GRE tunnels, etc. The sample presumes some use of logical systems (a

feature previously known as logical routers). Where not applicable you can safely omit

the related prefix list.

{master}[edit]

regress@R1-RE0# show policy-options | no-more

prefix-list router-ipv4 {

apply-path "interfaces <*> unit <*> family inet address <*>";

}

prefix-list bgp-neighbors {

apply-path "protocols bgp group <*> neighbor <*>";

}

prefix-list ospf {

224.0.0.5/32;

224.0.0.6/32;

}

prefix-list rfc1918 {

10.0.0.0/8;

172.16.0.0/12;

192.168.0.0/16;

}

prefix-list rip {

224.0.0.9/32;

}

prefix-list vrrp {

224.0.0.18/32;

}



238 | Chapter 4: Routing Engine Protection and DDoS Prevention



www.it-ebooks.info



prefix-list multicast-all-routers {

224.0.0.2/32;

}

prefix-list router-ipv4-logical-systms {

apply-path "logical-systems <*> interfaces <*> unit <*> family inet address <*>";

}

prefix-list bgp-neighbors-logical-systems {

apply-path "logical-systems <*> protocols bgp group <*> neighbor <*>";

}

prefix-list radius-servers {

apply-path "system radius-server <*>";

}

prefix-list tacas-servers {

apply-path "system tacplus-server <*>";

}

prefix-list ntp-server {

apply-path "system ntp server <*>";

}

prefix-list snmp-client-lists {

apply-path "snmp client-list <*> <*>";

}

prefix-list snmp-community-clients {

apply-path "snmp community <*> clients <*>";

}

prefix-list localhost {

127.0.0.1/32;

}

prefix-list ntp-server-peers {

apply-path "system ntp peer <*>";

}

prefix-list dns-servers {

apply-path "system name-server <*>";

}



You can confirm your apply-path and prefix lists are doing what you expect by showing

the list and piping the output to display inheritance. Again, it’s critical that your prefix

lists contain all expected addresses from where a service should be reachable, so spending some time here to confirm the regular expressions work as expected is time well

spent. Here, the results of the router-ipv4 apply-path regular expression are examined.

{master}[edit]

jnpr@R1-RE0# show policy-options prefix-list router-ipv4

apply-path "interfaces <*> unit <*> family inet address <*>";

{master}[edit]

jnpr@R1-RE0# show policy-options prefix-list router-ipv4 | display inheritance

##

## apply-path was expanded to:

##

192.168.0.0/30;

##

10.8.0.0/31;

##

192.0.2.0/26;

##

192.0.2.64/26;

##

10.3.255.1/32;

##

172.19.90.0/23;



RE Protection Case Study | 239



www.it-ebooks.info



##

apply-path "interfaces <*> unit <*> family inet address <*>";



If you do not see one or more commented prefixes, as in this example, then either the

related configuration does not exist or there is a problem in your path statement. As

additional confirmation, consider the sample BGP stanza added to R1, consisting of

three BGP peer groups: two IPv6 and one IPv4:

{master}[edit]

jnpr@R1-RE0# show protocols bgp

group int_v4 {

type internal;

local-address 10.3.255.1;

neighbor 10.3.255.2;

}

group ebgp_v6 {

type external;

peer-as 65010;

neighbor fd1e:63ba:e9dc:1::1;

}

group int_v6 {

type internal;

local-address 2001:db8:1::ff:1;

neighbor 2001:db8:1::ff:2;

}



Once again, the related prefix lists are confirmed to contain all expected entries:

{master}[edit]

jnpr@R1-RE0# show policy-options prefix-list bgp-neighbors_v4 | display inheritance

##

## apply-path was expanded to:

##

10.3.255.2/32;

##

apply-path "protocols bgp group <*_v4> neighbor <*>";

{master}[edit]

jnpr@R1-RE0# show policy-options prefix-list bgp-neighbors_v6 | display inheritance

##

## apply-path was expanded to:

##

fd1e:63ba:e9dc:1::1/128;

##

2001:db8:1::ff:2/128;

##

apply-path "protocols bgp group <*_v6> neighbor <*>";



And now, the actual filter. It’s a long one, but security is never easy and is more an

ongoing process than a one-point solution anyway. At least the comprehensive nature

of the filter means it’s easy to grow into new services or protocols as you simply have

to apply the related filters when the new service is turned up:

{master}[edit]

jnpr@R1-RE0# show firewall family inet | no-more

prefix-action management-police-set { /* OMITTED */ };

prefix-action management-high-police-set { /* OMITTED */ };

filter accept-bgp { /* OMITTED */ };



240 | Chapter 4: Routing Engine Protection and DDoS Prevention



www.it-ebooks.info



filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter

filter



accept-ospf { /* OMITTED */ };

accept-rip { /* OMITTED */ };

accept-vrrp { /* OMITTED */ };

accept-ssh { /* OMITTED */ };

accept-snmp { /* OMITTED */ };

accept-ntp { /* OMITTED */ };

accept-web { /* OMITTED */ };

discard-all { /* OMITTED */ };

accept-traceroute { /* OMITTED */ };

accept-igp { /* OMITTED */ };

accept-common-services { /* OMITTED */ };

accept-sh-bfd { /* OMITTED */ };

accept-ldp { /* OMITTED */ };

accept-ftp { /* OMITTED */ };

accept-rsvp { /* OMITTED */ };

accept-radius { /* OMITTED */ };

accept-tacas { /* OMITTED */ };

accept-remote-auth { /* OMITTED */ };

accept-telnet { /* OMITTED */ };

accept-dns { /* OMITTED */ };

accept-ldp-rsvp { /* OMITTED */ };

accept-established { /* OMITTED */ };

accept-all { /* OMITTED */ };

accept-icmp { /* OMITTED */ };

discard-frags { /* OMITTED */ };



Not much to see, given the omit flag is in play. Easy enough to fix:

{master}[edit]

jnpr@R1-RE0# show firewall family inet | no-more | display omit

prefix-action management-police-set {

apply-flags omit;

policer management-1m;

count;

filter-specific;

subnet-prefix-length 24;

destination-prefix-length 32;

}

prefix-action management-high-police-set {

apply-flags omit;

policer management-5m;

count;

filter-specific;

subnet-prefix-length 24;

destination-prefix-length 32;

}

filter accept-bgp {

apply-flags omit;

term accept-bgp {

from {

source-prefix-list {

bgp-neighbors_v4;

bgp-neighbors-logical-systems_v4;

}

protocol tcp;

port bgp;



RE Protection Case Study | 241



www.it-ebooks.info



}

then {

count accept-bgp;

accept;

}

}

}

filter accept-ospf {

apply-flags omit;

term accept-ospf {

from {

source-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

destination-prefix-list {

router-ipv4;

ospf;

router-ipv4-logical-systms;

}

protocol ospf;

}

then {

count accept-ospf;

accept;

}

}

}

filter accept-rip {

apply-flags omit;

term accept-rip {

from {

source-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

destination-prefix-list {

rip;

}

protocol udp;

destination-port rip;

}

then {

count accept-rip;

accept;

}

}

term accept-rip-igmp {

from {

source-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

destination-prefix-list {

rip;



242 | Chapter 4: Routing Engine Protection and DDoS Prevention



www.it-ebooks.info



}

protocol igmp;

}

then {

count accept-rip-igmp;

accept;

}

}

}

filter accept-vrrp {

apply-flags omit;

term accept-vrrp {

from {

source-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

destination-prefix-list {

vrrp;

}

protocol [ vrrp ah ];

}

then {

count accept-vrrp;

accept;

}

}

}

filter accept-ssh {

apply-flags omit;

term accept-ssh {

from {

source-prefix-list {

rfc1918;

}

destination-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

protocol tcp;

destination-port ssh;

}

then {

policer management-5m;

count accept-ssh;

accept;

}

}

}

filter accept-snmp {

apply-flags omit;

term accept-snmp {

from {

source-prefix-list {

snmp-client-lists;



RE Protection Case Study | 243



www.it-ebooks.info



snmp-community-clients;

}

destination-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

protocol udp;

destination-port snmp;

}

then {

policer management-5m;

count accept-snmp;

accept;

}

}

}

filter accept-ntp {

apply-flags omit;

term accept-ntp {

from {

source-prefix-list {

ntp-server;

}

destination-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

protocol udp;

port ntp;

}

then {

policer management-1m;

count accept-ntp;

accept;

}

}

term accept-ntp-peer {

from {

source-prefix-list {

ntp-server-peers;

}

destination-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

protocol udp;

destination-port ntp;

}

then {

policer management-1m;

count accept-ntp-peer;

accept;

}

}

term accept-ntp-server {



244 | Chapter 4: Routing Engine Protection and DDoS Prevention



www.it-ebooks.info



from {

source-prefix-list {

rfc1918;

}

destination-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

protocol udp;

destination-port ntp;

}

then {

policer management-1m;

count accept-ntp-server;

accept;

}



}

}

filter accept-web {

apply-flags omit;

term accept-web {

from {

source-prefix-list {

rfc1918;

}

destination-prefix-list {

router-ipv4;

router-ipv4-logical-systms;

}

protocol tcp;

destination-port [ http https ];

}

then {

policer management-5m;

count accept-web;

accept;

}

}

}

filter discard-all {

apply-flags omit;

term discard-ip-options {

from {

ip-options any;

}

then {

count discard-ip-options;

log;

syslog;

discard;

}

}

term discard-TTL_1-unknown {

from {

ttl 1;



RE Protection Case Study | 245



www.it-ebooks.info



}

then {

count discard-all-TTL_1-unknown;

log;

syslog;

discard;

}

}

term discard-tcp {

from {

protocol tcp;

}

then {

count discard-tcp;

log;

syslog;

discard;

}

}

term discard-netbios {

from {

protocol udp;

destination-port 137;

}

then {

count discard-netbios;

log;

syslog;

discard;

}

}

term discard-udp {

from {

protocol udp;

}

then {

count discard-udp;

log;

syslog;

discard;

}

}

term discard-icmp {

from {

protocol icmp;

}

then {

count discard-icmp;

log;

syslog;

discard;

}

}

term discard-unknown {

then {



246 | Chapter 4: Routing Engine Protection and DDoS Prevention



www.it-ebooks.info



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 4. Routing Engine Protection and DDoS Prevention

Tải bản đầy đủ ngay(0 tr)

×