Ingress & Egress Filtering Lab

Introduction

These exercises will show important IP filtering techniques that significantly improve the security of your network, and the whole Internet, by preventing IP packets with “spoofed” source addresses from either entering or leaving your AS. For a more complete explanation of these concepts, see IETF’s BCP 38 and BCP 84 documents.

Outbound Packet Filtering

Traffic leaving your campus should not have source IP addresses which are not part of your campus public IP address space:

On your Border router:

ip access-list extended to-nren
 remark Permit Campus X public IPv4 address block
  permit ip 100.68.X.0 0.0.0.255 any
 remark Permit NREN point to point link address
  permit ip host 100.68.0.Y any
 remark Deny any other sources
  deny ip any any
!
interface GigabitEthernet0/0
 ip access-group to-nren out
!

(Note: 100.68.0.Y is your Border router's own interface address on GigabitEthernet0/0)

Do the same for IPv6:

ipv6 access-list to-nren-v6
 remark Permit Campus X public IPv6 address block
  permit ipv6 2001:DB8:X::/48 any
 remark Permit NREN point to point link address
  permit ipv6 host 2001:DB8:100:X::1 any
 remark Deny any other sources
 deny ipv6 any any
!
interface GigabitEthernet0/0
 ipv6 traffic-filter to-nren-v6 out
!

Inbound Packet Filtering

Traffic received from outside your campus should never be sourced from IP addresses that belong to your campus.

On your Border router:

ip access-list extended from-nren
 deny ip 100.68.X.0 0.0.0.255 any
 permit ip any any
!
interface GigabitEthernet0/0
 ip access-group from-nren in
!

Do the same for IPv6:

ipv6 access-list from-nren-v6
 deny ipv6 2001:DB8:X::/48 any
 permit ipv6 any any
!
interface GigabitEthernet0/0
 ipv6 traffic-filter from-nren-v6 in
!

Unicast Reverse Path Forwarding

While we can put a anti-spoofing filter on the border router to block packets with source addresses not part of our address space from heading out to the NREN and other upstreams, many campuses are using address translation for their IPv4 address space, meaning that packets with invalid source addresses will be translated into the public pool used by the campus, and therefore hidden from the Border Router’s anti-spoofing filters. (See the next session which covers NAT.)

To solve this problem, we apply anti-spoofing filters directly on the core router, which connects all the campus VLANs. The technique is called “Unicast Reverse Path Forwarding” (uRPF), and is implemented by a single command applied to the VLAN interface on the core router.

To implement uRPF, configure the following¹ on the Core Router:

interface Vlan 10
 ip verify unicast source reachable-via rx allow-self-ping
 ipv6 verify unicast source reachable-via rx
!

Do the same for the other Vlan interfaces on the Core Router.

We also need to do this on the management server interface:

interface GigabitEthernet0/3
 ip verify unicast source reachable-via rx allow-self-ping
 ipv6 verify unicast source reachable-via rx
!

Only implement this command on access interfaces, facing end users or services. It must not be implemented on links with diverse paths to other destinations - and is not needed on the link to the border router either.

Management Access

In the Layer2 labs, we created a management VLAN for managing the switches (SSH, SNMP, etc. ). In order to protect that network from malicious access, we need to set up filters on the devices on the management VLAN.

We want to allow the Campus NOC network to be able to access the management VTY of every device. We also want to allow the core and border router to be able to connect to each other as well.

First we construct the IPv4 access-list:

ip access-list extended ipv4-vty
 permit ip 100.68.X.128 0.0.0.15 any      ! allow NOC network
 permit ip host 100.68.X.241 any          ! allow Border router
 permit ip host 100.68.X.242 any          ! allow Core router
 deny   ip any any log

and do the same for IPv6 as well:

ipv6 access-list ipv6-vty
 permit ipv6 2001:DB8:X:1::/64 any        ! allow NOC network
 permit ipv6 host 2001:DB8:X:2::241 any   ! allow Border router
 permit ipv6 host 2001:DB8:X:2::242 any   ! allow Core router
 deny   ipv6 any any log

And then we apply this same ACL on all the devices in our network, like this:

line vty 0 4
 access-class ipv4-vty in
 ipv6 access-class ipv6-vty in
!

For the core and border routers, we restricted access to be only from the Loopback interface. So on those two devices, we will add the following command:

ip telnet source loopback0

which will now source all telnet connections coming from the Border or Core routers to be from the Loopback interface.

Check connectivity to the Management subnet. Are you able to access the Management addresses for the building switches from the Border and Core routers now? What about access from switch to switch? Are you able to explain what is happening now?

Appendix - More Sophisticated Campus Filters

This appendix looks at some of the possible filtering strategies for campuses looking to secure their infrastructure from some of the more common vulnerabilities targeted by worms and other malicious software on compromised systems connected to the Internet.

If you still have time in the class, try them out on your Campus Border Router by adding them on to what you already have configured.

Filters

The following list is a common list of filters that many operators install on their border routers, both inbound and outbound. The list can be applied to IPv4 and IPv6, and inbound as well as outbound on the external interface. Don’t forget for IPv6 to allow the Link Local address block, otherwise IPv6 will not work between your router and your NREN.

 deny   tcp any any eq 23               ! block telnet - insecure
 deny   udp any any eq 69               ! block TFTP - never seen from outside
 deny   udp any any range 135 139       ! netbios stuff
 deny   tcp any any range 135 139       ! netbios stuff
 deny   tcp any any eq 445              ! Blaster worm
 deny   udp any any eq 514              ! SYSLOG - never seen from outside
 deny   tcp any any eq 1025             ! Microsoft RPC exploit
 deny   tcp any any eq 1337             ! Redshell backdoor
 deny   tcp any any eq 1433             ! MS SQL worm
 deny   udp any any eq 1434             ! MS SQL worm
 deny   udp any any eq 2049             ! Sun NFS
 deny   tcp any any eq 2745             ! Blaster worm
 deny   tcp any any eq 3001             ! NessusD backdoor
 deny   tcp any any eq 3127             ! MyDoom! worm
 deny   tcp any any eq 3128             ! MyDoom! worm
 deny   tcp any any eq 5000             ! WindowsXP UPnP port
 deny   tcp any any eq 6129             ! Dameware backdoor
 deny   tcp any any eq 11768            ! Dipnet/Oddbob worm
 deny   tcp any any eq 15118            ! Dipnet/Oddbob worm

The following is extremely useful and is only applied to inbound filters:

 permit tcp any any established         ! only allow established TCP connections

This would be applied first in the inbound packet filter to only allow the return packets from outbound TCP sessions. It will not allow any remote site to initiate an incoming TCP connection. For that, a specific entry in the packet filter matching that TCP port will be required. It’s a very powerful and necessary filter line for a campus border router.

Other ports to block

You may want to consider blocking other ports too. Here are some examples:

Do you run a web server on campus? If so, is it using https (tcp/443) with certificate generated by Letsencrypt? Or are you still using http (tcp/80)? So maybe only allow port 80/443 to known web servers, so as not to create the opportunity for vulnerabilities if any end users accidentally start up a web server on their computing device (applies to those using public IP address space).
Only allow NTP to devices acting as NTP sources for the campus (consult the Campus Best Operations Practices presentation for more details).
Incoming and outgoing email using SMTP (tcp/25) should only use your official SMTP servers. Blocking SMTP for the rest of the campus address space is strongly recommended. Users sending email via third party relays will be using tcp/465 or tcp/587, never tcp/25.

There are many more examples. Discuss with your colleagues in your group.

Ports and Services never to block

There are also ports and services never to block:

ICMP - Internet Control Message Protocol
SSH and VPNs - end users will want to use Secure Shell to connect to remote R&E institutions and other sites.
All of UDP - this will break name lookups using the DNS. Even allowing DNS and blocking everything else UDP in the hope that peer-to-peer traffic will be blocked just will mean that peer-to-peer will use TCP instead (which a lot of it is doing these days anyway).

Older Cisco routers use a slightly different version of this command: ip verify unicast reverse-path allow-self-ping and ipv6 verify unicast reverse-path ↩