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.
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-v4
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-v4 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
!
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-v4
deny ip 100.68.X.0 0.0.0.255 any
permit ip any any
!
interface GigabitEthernet0/0
ip access-group from-nren-v4 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
!
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 following1 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.
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 VTY-v4
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 VTY-v6
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 VTY-v4 in
ipv6 access-class VTY-v6 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 ssh source-interface Loopback0which will now source all SSH 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?
What about access from switch to Border and Core routers?
Are you able to explain what is happening now?
Discuss in your group what is going on. Why do you think we have set the filters up this way?
Now that we’ve protected the access to the control plane of the routers and switches in our network, we also need to protect access to the SNMP port.
The current configuration on the switches and core router is below:
snmp-server group ReadGroup v3 auth
snmp-server user admin ReadGroup v3 auth sha NetManage
snmp-server location Campus Network Design Workshop
snmp ifmib ifindex persist and the equivalent on our border router is:
snmp-server group ReadGroup v3 auth
snmp-server user admin ReadGroup v3 auth sha NetManage
snmp-server location Campus Network Design Workshop
snmp-server ifindex persist(Note that the definition of the user admin will not appear in the displayed configuration.)
The first line creates the SNMPv3 access group name and the Security Level2 used (authNoPriv). Currently there is no access-control list provided which means the whole world (in theory) could access the SNMP port on our devices. We need to fix this so that only our monitoring systems can access the SNMP port for queries.
The Network Monitoring and Management server we have sitting on our server LAN has the IP address 100.68.X.130 (replace X with your campus number). The Network Monitoring and Management Workshop which continues on from this workshop configures this system with various tools - we are using it purely for demonstration purposes.
Also, the classroom network has monitoring systems on 100.64.0.248 (LibreNMS), 100.64.0.249 (ELK/Kibana), and 100.64.0.250 (the classroom NOC). We’ll add these three to the ACL as well, like this:
ip access-list standard SNMPv4
permit 100.68.X.128 0.0.0.15
permit 100.64.0.248
permit 100.64.0.249
permit 100.64.0.250
deny any log
!We will do the same for IPv6:
ipv6 access-list SNMPv6
permit ipv6 2001:DB8:X:1::/64 any
permit ipv6 host 2001:DB8::248 any
permit ipv6 host 2001:DB8::249 any
permit ipv6 host 2001:DB8::250 any
deny ipv6 any any log
!and then we apply the IPv4 and IPv6 ACLs to the SNMP configuration:
snmp-server group ReadGroup v3 auth access ipv6 SNMPv6 SNMPv4Cisco IOS syntax has both the IPv6 and IPv4 filters inline. The ipv6 keyword expects the name of IPv6 ACL to appear immediately afterwards. The IPv4 ACL can then be appended after that.
Note Well: If the IPv6 filters are omitted and the device has IPv6 connectivity, then the device is wide open to SNMP access over IPv6 - be careful!
Once this is done we’ll have protected the device so that SNMP access is only from trusted devices on the network.
Once the previous steps have all been completed, the campus network infrastructure will be minimally protected from other devices on the network. Plus we will have made significant strides to preventing spoofed traffic from leaving the campus network, thereby ensuring that our network meets some of the global requirements for connecting to the Internet.
Demonstrate your configuration to the lab instructors. Can you think of ways of demonstrating that the filters are working?
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.
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 wormThe following is extremely useful and is only applied to inbound filters:
permit tcp any any established ! only allow established TCP connectionsThis 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.
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.
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).