ACLs are "access control lists" that filter incoming network traffic based on rules.
- Customer should work with their carrier(s) to implement ACLs to block traffic that is not sourced from Silverline
- Helps protect against attacks where the attacker targets the original IP address and thus still reach the customer's data center infrastructure.
Here is why you must implement ACLs:
When using an F5 Silverline's Proxy configuration, a single application will flow through the Silverline scrubbing center, as demonstrated in Diagram 1. Once the DNS change has been made, and DNS TTL expires, traffic will begin to flow through Silverline, by resolving to the ingress proxy IP address assigned to your configuration (ex. 184.108.40.206).
However, if attackers don't use DNS and target the original IP address (in Diagram 2: 220.127.116.11), attack traffic will bypass Silverline and still reach the customer's data center infrastructure. This is why you need ACLs to only allow Silverline's traffic through to your network, and block all other incoming traffic. -- See ACLs: Always On vs. Always Available Customers
1. Work with your carrier(s) to implement ACLs to block traffic that is not sourced from Silverline's address range(s) -- Q&A: What are the Silverline Subnets / IP Address ranges?
2. It is recommended that the customer also implement the same ACL on the external-facing interface of your border router or firewall, so that application functionality testing can be completed before the carrier applies the blocking ACL. Having the carrier apply or remove the ACL may take longer than making the change on the customer's equipment.
ACLs: Always On vs. Always Available Customers
All Customers should work with their carrier(s) to put ACL(s) in place to block traffic that has not been scrubbed by Silverline.
- For Always-On Proxy customers, the carrier ACLs should be left in place at all times.
- For Always-Available Proxy customers, the carrier ACLs should only be active when traffic has been directed through Silverline. If possible, work with the carrier(s) in advance to have the ACL(s) staged, that in the event the ACLs would be needed, time to implement will be reduced.
hostname customer-router ! interface ethernet0 ip access-group 55 in !
access-list 55 permit ip 18.104.22.168 0.0.7.255
access-list 55 permit ip 22.214.171.124 0.0.15.255
access-list 55 permit ip [$OTHER.VALID.RANGES.HERE]
access-list 55 deny ip any any
set policy-options prefix-list trusted-sources 126.96.36.199/21
set policy-options prefix-list trusted-sources 188.8.131.52/20
set policy-options prefix-list trusted-sources [$OTHER.VALID.RANGES.HERE]
set policy-options prefix-list everyone-else 0.0.0.0/0
set firewall family inet filter silverline term allow-silverline from source-prefix-list trusted-sources
set firewall family inet filter silverline term allow-silverline then accept
set firewall family inet filter silverline term allow-silverline from source-prefix-list everyone-else
set firewall family inet filter silverline term allow-silverline then discard
set interfaces fe0 family inet filter input silverline
- Proxy Set-up Guide: Proxy / App Configuration in Silverline Portal
- Q&A: What are the Silverline Subnets / IP Address ranges?
- How to Test the Silverline Proxy Using 'hosts' File on Windows PC
- Q&A: Regional PoPs: How is the traffic flow through Silverline infrastructure different with Regional PoPs?