As you may be aware, we have a new firewall to replace our existing firewall. This blog posting will go into more detail on what is happening and why than the normal communications.
And BTW: In case you’ve seen a certain spam being pushed out, no we don’t need you to re-validate your email credentials.
Our existing firewall – an FWSM blade in a Cisco 65xx chassis – is old. It was installed nearly 11 years ago, and although the software has been updated from time to time, fundamentally the capabilities have not changed since it was installed. Whilst the firewall has been demonstrated to be stable enough, there does come a point where older equipment starts having “issues” and replacing it before that time makes a great deal of sense. In addition, the existing firewall is only capable of connecting at 1Gbps which is somewhat less than our Internet connection (10Gbps). Upgrades do exist, but we would need to upgrade enough components that we would be essentially installing a whole new firewall. Finally, the firewall world has moved on since the mid-2000s and modern firewalls have much more capabilities than our current firewall. Utilising a modern firewall would offer greater levels of defence against all the threats out there.
The replacement firewall will be a pair of Palo Alto Networks PA5060s running in active-standby mode. Both will be configured as “firewalls on a stick” whereby all the network plumbing is on the existing network infrastructure. At this stage, the firewalls will be configured with the base level of capability with decisions on capabilities such as URL filtering to be made in the second phase of the project. From the time the new firewall is installed, we will have an elevated level of protection against :-
- Viruses. Stream-based anti-virus protection will be applied to all unencrypted streams of traffic.
- Threats. Again, stream-based threat protection will be applied to all unencrypted streams of traffic.
- Denial of service. Although our existing firewall provides some protection, the new firewall offers a greater level of protection.
On the day the switch-over will be made – the 17th of January – the existing firewall will be disabled and the new firewall enabled. Unfortunately this is a disruptive process, so apologies for that. During the switch-over process, we will be performing potentially disruptive tests to verify that the fail-over capabilities of the new firewall work as expected in a variety of different failure scenarios. All being well, the amount of disruption will be minimal but disruption may continue for some time if we encounter issues that need a resolution. After the period of disruption, the service will be “at risk” for an extended period whilst testing takes place. Whilst we are currently undergoing a very large programme of testing, it is not feasible to test every single application and every single rule in advance. During the “at risk” window, we have the opportunity to evaluate how the firewall performs for real and make changes to the rule set to fix issues as they arise. At an early stage during the “at risk” window, a decision on whether to roll back to the old firewall will be made. That is only likely to happen in a situation where the new firewall encounters issues so fundamental that ordinary use is not possible – and we have already had a test that indicates that this is unlikely. By Monday (although it is still strictly speaking within the “at risk” window), we expect everything to be working normally. And hopefully a bit quicker than before. Without wishing to jinx the whole process, it is probable that after about 10:00, the Internet will be usable but there remains the risk of disruption.
The new firewall has a number of interesting capabilities, including capabilities which whilst might be perfectly normal in a corporate environment, may be somewhat controversial within an academic environment. That has already been hinted at with the mention of URL filtering.
The IS Security Team doesn’t do censorship. Deciding what you can and cannot view on the web is not a decision for the security team; we may block access to web sites for security reasons and we may monitor network traffic for security reasons. URL filtering is not currently a subscription we’ve signed up to on the firewall, but if it were to be used, it would at present (pending any University policy changes) only be used to block access to malware distribution sites and phishing sites.
The new firewall has the capability to decrypt certain types of traffic. If you are communicating with a secure web site, all of the traffic between you and the server is encrypted to prevent eavesdropping. This is of course a good thing and we encourage the use of encrypted web sites (https not http) but there is a disadvantage for a firewall that looks in detail at the data for security issues with the data. Such as viruses, malware or direct attempts to exploit. By decrypting such traffic, we can perform security checks against such traffic. At present no decision on whether to use decryption has been made.
The new firewall performs a stream-based anti-virus scan on any of the traffic that passes through it. If it finds a virus, it will attempt to block access to it (it isn’t always possible). This supplements (but does not replace) workstation based anti-virus scanning and common sense.