CCBC Firewall Architecture and Management

The firewall environment should be understood as a layered model rather than as a single device or policy location. At the innermost layer, individual servers have operating-system firewall controls that determine which services on that server can be reached. Outside the server itself, network Access Control Lists provide segmentation between VLANs and larger network zones. At the outer edge of the environment, enterprise firewalls inspect and control traffic moving between the internal college network, the DMZ, and the Internet.

This layered approach is important because each control operates at a different point in the communication path. A server firewall limits what a system will accept. A network ACL limits whether traffic should move from one segment to another. The enterprise perimeter firewalls enforce broader boundary and application controls. When used together, these controls reduce the chance that a single misconfiguration or exposed service will provide unrestricted access across the environment.

Server-based firewalls are the first layer of protection around individual systems. These controls sit between the operating system and any other network communication, including communication from elsewhere in the institution and from the Internet. The expected posture is that the firewall remains enabled by default and is restricted to the services required for the applications running on the server.

On Windows servers, the native Windows Firewall is used. The standard approach described in the meeting is to enable the domain-level firewall and then allow only the services the server is expected to provide. This approach helps prevent a server from exposing ports or services simply because a feature was installed or enabled locally.

On Linux servers, firewall management may include iptables and, on newer Oracle Linux releases, the firewall command interface associated with firewalld. The transcript also identified SELinux as part of the server-side security model. Taken together, these tools provide packet filtering and operating-system level controls that help prevent unauthorized or unexpected changes in how services are exposed.

For technical staff, the practical takeaway is that server firewall rules should be treated as part of the server’s baseline configuration. If an application requires network access, the required ports and services should be identified deliberately and opened intentionally. Services that are not required for the server’s role should remain blocked.

Network Access Control Lists provide segmentation inside the CCBC network. They are configured on Cisco network equipment and are used to prevent traffic from moving freely between VLANs. This is especially important in an environment where different types of systems, users, and instructional areas may have different trust levels and different communication requirements.

The meeting described the ACL model as a permit-based approach with a deny rule at the end. In practice, this means that approved traffic is explicitly allowed, while traffic that has not been specifically permitted is denied. This model is consistent with a restrictive segmentation posture because it requires a known need before traffic is allowed between segments.

Historically, these ACLs were used primarily between Banner network segments and the rest of the environment. The transcript indicates that ACL usage has expanded and now also exists between 

administrative segments and student segments. These ACLs are run on the core routing infrastructure at the campuses.

Because ACLs are implemented through Cisco configuration, technical staff working with these controls should be comfortable reviewing Cisco ACL syntax and understanding the order in which permit and deny entries are processed. Rule order matters, and the final deny behavior means an omitted permit can have the same operational effect as an intentional block.

The enterprise firewall layer includes two major platforms: Palo Alto firewalls and Cisco ASA devices, now referred to in the transcript as Firepower. These platforms protect traffic at the boundary between the college environment, the DMZ, and the Internet. They also provide different types of inspection and policy enforcement, so the order in which traffic encounters them is operationally significant.

The Palo Alto firewalls provide application-layer inspection. The transcript described these devices as looking at Layer 7 information, which is where application-based blocking occurs. This makes the Palo Alto layer important for decisions that depend on the application being used rather than simply on source, destination, port, or protocol.

The Cisco ASA/Firepower layer operates on a policy model similar in concept to network ACLs. There are permit rules for traffic that is allowed and a deny behavior at the bottom of the policy set. According to the meeting transcript, these devices are processed first when traffic comes in from the Internet and last when traffic leaves the campus for the Internet.

Traffic processing differs depending on the direction of travel. The transcript emphasized that the Palo Alto and Cisco ASA/Firepower devices are both involved in traffic that crosses the internal, external, and DMZ boundaries, but they are encountered in different orders depending on the source and destination.

The transcript also identified several specialized arrangements that exist outside the standard enterprise firewall model. These environments are important to document because they may not be centrally managed in the same way as the core enterprise firewall platforms.

The Dental Hygiene program at the Dundalk campus currently has a SonicWall firewall. The transcript notes that this device is under review and may be replaced with a more Cisco-aligned firewall so that it can be monitored and managed more consistently by IT staff.

The cybersecurity instructional environments use network ACLs to isolate lab activity from the production infrastructure. These controls allow the environments to reach only the ports they need while preventing activity in those teaching environments from interfering with the internal network infrastructure.

The Planetarium environment was described as having a firewall that is believed to be a Barracuda device. The transcript states that this firewall is managed by the outside vendor responsible for the Planetarium systems and is not administered by central IT staff.

When working with firewall-related issues, staff should begin by identifying the location of the control that is most likely to affect the traffic. A connection to a service on a specific server may be blocked by the server firewall. A connection between two VLANs may be blocked by a network ACL. Traffic entering from or leaving to the Internet, or traffic involving the DMZ, may involve both the Palo Alto and Cisco ASA/Firepower layers.

The most important operational principle is that traffic should be permitted because there is a documented need, not because broader access is easier to configure. The meeting transcript repeatedly reflected a deny-by-default model: ACLs end with a deny rule, enterprise firewall policies include a denial at the bottom, and server firewalls should be limited to the services required by the applications on the machine.

Changes to firewall rules should be specific and traceable. Staff should document the source, destination, service, application need, and business reason for the rule. Where possible, access should be limited to the narrowest practical scope. This makes future troubleshooting easier and reduces the risk of allowing unintended traffic.