Phase 2 is complete!

With the addition of AppID functionality to fw.noc’s beta branch, we can now declare Phase 2 of the firewall migration project complete! AppID is a huge step for us as this is feature is not offered by any other vendor at this time. This will allow us to create new firewall rules based on Application signatures, rather than on a port and protocol. Here are a couple of screenshots from fw.noc that show the difference, from our admin view, between the two.

The first screenshot is a sample of our current firewall rules that we put in front of network equipment. One group is TCP ports, the other is UDP. We can mouse over a group to get a list of ports contained in that group:

This next screenshot shows the rules for the same IP address after converting them to AppID. Rather than a port and protocol, we have applications: ssh, web-browsing (http), ssl (https), and snmp:

 

The rule is pushed from fw.noc onto the relevant Palo Alto virtual firewall, and the result is this (apologies for formatting):

These new rules still have a port and protocol setting. By default we are using ‘application default’ which will still only allow this application on its standard port. Now, rather than allowing any traffic on port 22/tcp as we were with port/protocol rules, we are only allowing ssh traffic on port 22/tcp with AppID rules. We have the ability to create a rule that allows an App on an alternate port, or any port. For example, we can create a rule that allows ssh on port 2022/tcp, or a rule that allows ssh on any tcp port.

We have two steps going forward with this feature. The first will be add AppID to fw.noc self service. The next will be to migrate as many of our existing rules to AppID where possible.

We are working on our goals for Phase 3 of this project, which we hope to announce very soon.

Dropped Threat Statistics, week of June 1st, and appID progress

First, here are some dropped threat statistics for the campus border for the week of June 1st. This is traffic between on-campus networks and the internet. Virtually all of the spyware hits are SIPVicious probes, which are more of a nuisance than anything.

Next we have the blocked threats for intra-campus traffic. We have had a few false positives for viruses recently, so please let us know if you see anything weird.

 

Adding AppID functionality into fw.noc is now our primary focus going into July. We have a work-in-progress demo in our development branch. We are planning to move that into beta, after our current beta branch becomes production. One enhanced function is that it should address AppID dependencies, where one AppID requires another AppID to work properly, which is something not offered by the native Palo Alto interface.

External Dynamic Lists now in use

One new feature that we have available to us with Palo Alto firewalls is External Dynamic Lists. An External Dynamic List is an object that points to an external list that is maintained and updated frequently by a vendor or service, which will typically contain high risk IP addresses, network blocks, domains, or URLs. We can then use this Object in a security policy. This allows us to create rules which reference this frequently updated list so that they remain current and do not require a manual update.

We spent some extra time on this as we wanted to integrate this feature into fw.noc by mapping a Global Scope to a Palo Alto EDL. Example follows:

Here we have the EDL template in our Panorama management server:

We then map this EDL to a Global Scope in fw.noc:

Next we use this mapped Global Scope in a rule on fw.noc:

And once deployed, this rule is now in our security policy on the Palo Alto virtual firewall instance:

Intra-Campus Security Protections in place

As of March 25th, we now have Intra-campus security protections in place for all unit-level firewalls on Palo Alto appliances. This means we are blocking viruses, spyware, and other vulnerabilities between each campus subnet. We also have some DDoS protections in place that are alerting us to host and port scanning and TCP/UDP floods. We will be monitoring the results of these measures and fine tuning these rules over the next few weeks.

 

Phase 2 Progress

We have now implemented intra-campus security features on about 100 networks with no major issues. We had a very small but important success overnight, blocking the transfer of an infected file over a windows file share between two business critical subnets. We have also completed the migration of the final firewall performing NAT.

Phase 2 Begins!

We have recently began implementing some of the features that are part of Phase 2. Most of the firewalls which perform NAT operations have been migrated, and we expect to do the remaining one by the end of March. The biggest project we are working on at the moment is the implementation of Intra-Campus Security Profiles which includes Antivirus, Anti-spyware, and Vulnerability Protection: aka Intrusion Prevention. We are also implementing what is called Zone Protection. This feature provides data-plane protections against DDoS attacks and other malicious traffic. At the moment it is only set to give us alerts, but once we have a baseline it will be configured to block such traffic.

So far we have implemented these changes on our departmental firewall with no major issues.

Palo Alto Firewall Migration, Winter Update

On behalf of the firewall team, I would like to give everyone an update on the next steps for the Palo Alto firewall migration project

 

Our main migration from Cisco ASAs to Palo Alto appliances was completed at the end of October. Since then, we have continued development work on the fw.noc application to manage some of the new Palo Alto features. We have also been working through some bugs on the platform, which we are resolving through a series of code updates that we expect to complete by the end of January.

 

Phase 2 of this project includes new features we plan to implement over time. These new features include:

 

  • Migrating NAT firewalls from ASAs to Palo Altos. We have a few firewalls that are performing NAT operations for security or regulatory compliance. The Palo Altos do this differently than Cisco, so it is taking some extra time to prepare.
  • Implementing Security Profiles for intra-campus traffic. This feature includes Antivirus, Anti-spyware, and Vulnerability Protection: aka Intrusion Prevention. We have had these features running on our campus border for some time, and have had them set to send alerts for intra-campus traffic. This enhancement will block malicious traffic detected between campus networks.
  • Implementing DoS protection features for intra-campus traffic. This protects the data plane of the appliance and will drop malicious traffic, such as a SYN flood, before it ever hits a security policy.
  • Adding the ability to create new firewall rules via fw.noc that use AppID, which bases a security policy rule on the application rather than port and protocol. This can prevent malicious traffic, such as non-web traffic traversing a port intended for web only.
  • Updating our firewall course as we add AppID features into fw.noc. We will also be offering a shorter refresher course for existing authorized requesters.

 

These new features will be rolled out over the course of Phase 2, and we will be sure to notify the campus IT community as each of these features are placed into production. Please let us know if you have any questions.

 

Sincerely,

The Firewall Team

GT Savannah migration complete

A very late update from us. We performed our final Phase 1 firewall migration October 26th, migrating GT Savannah over to a Palo Alto appliance. We’ve just been letting things cook since then with no major issues.

East Interconnect migration complete, and another RMA replacement

The Palo Alto 5200 series has four disk drives, one pair are SSDs and are used for the system OS, the other pair are mechanical are used for local log storage. We had issues with the syslog drives of one of our bcdc1-dept-pa units soon after it was initially deployed. Palo Alto send us replacement disks, but a month later we were getting errors again. Palo Alto RMAed the chassis. This is the second chassis we have had to replace, which is a pain, but it’s nice that the vendor is pretty proactive about RMAing the hardware, which isn’t cheap. Here’s hoping that’s our last one.

East Interconnect was also migrated this morning with no major issues. Phase One is nearly complete!