From KAREN wiki

Contents 1 Audience 2 Network Principles 3 What is a Firewall? 4 Network Firewalling 5 Location of Firewalls 6 Firewall Specifications 7 Combined Routers and Firewalls 8 Other Security 9 FCAPS and Services Management 10 Governance Level Statements 11 Firewall Metrics 12 What Are Schools and Aggregation Networks Doing

Audience

The audience for this wiki entry is those with an interest in an overview of schools firewalls for the National Education Network. It is intended for a 'soft technical' audience and as such principles will be introduced and discussed. It will be used to facilitate discussion and does not represent a policy statement and it is intended to change and evolve.

Network Principles

KAREN relies on Inter-networking design principles and as such the following is adhered to:

• Keep local traffic local
• Switch where possible
• Route where necessary

What is a Firewall?

Recommendation: That the definition of firewall is limited to network firewalling for the purposes of planning the connectivity portion of the NEN. It is also recommended that semantically a clear distinction is made between a network firewall and other security functions.

---

A firewall in the eyes of many has become a synonym for security. While a firewall generally provides perimeter security functions, it does not fully cover the host of threats on the Internet, nor the host of threats that are present on any networks whether a local area network (LAN), or a wide area network (WAN). Many threats exist outside of the lower layers that KAREN and aggregation networks do not operate at.

While definitions of firewalls exist and can easily be quoted the perceptions of what a firewall does and how it affects the network and end user are diverse and cover a major spectrum. Perhaps due to the now accepted view a network must have a firewall we have see in the past decade; major creep in the the definition with many many functions being sold under the term firewall. The emergence of Unified Threat Management (UTM) encompassing not only a network firewall function but a whole host of services and this being seen as a ‘firewall’ has made the expectations of what a firewall delivers even more muddied.

The diagram below shows network firewall functions and UTM functions, this is intended to show where confusion may arise when firewall is used as a term.

It is acknowledged that UTM services will be required by school, these could be potentially provided by an appliance that also does network firewalling or by separate devices and/or services.

Network Firewalling

Recommendation: Network firewalling is not mandatory for schools on the NEN but encouraged. Network firewalls are to allow rules to be applied to the following:

• Source IP address
• Source port
• Destination IP address
• Destination port
• Service like WWW or FTP, SMTP
• Protocol

---

Network firewalling may not be wanted by some schools. It would be valuable to understand what some of these use cases are and what threat they may be opening themselves up to.

Network firewalling at the basic level deals with some simple things:

Source IP - the originating computer or device; there may be a requirement to stop particular devices making connections with particular places, an example of this might be a VOIP PABX that may only initiate a connection with its appropriate SIP server.

Source Port - Outgoing connections on some ports may be undesirable - port 25 which is used for outgoing SMTP traffic, if an internal computer were compromised it could be used in distribution of spam and 'blacklisting' of the network.

Destination IP Address - Where the connection will be to. Connections to certain IP addresses may be blocked. This one is interesting as it could be viewed as an IP based content filter but this would be a very coarse and unreliable way of filtering content.

Destination Port - the port on the remote host that is being connected to.

Services - dropping or allowing of certain services.

Protocol -

Location of Firewalls

Recommendation: Firewalls should be located at schools in the logical sense, they will form part of the schools internal network inside the deamarc for the KAREN part of the NEN.

---

Options for the physical and logical location of the firewall device can be defined as:

1. Firewall at the school
2. Integrated firewall and router at the school
3. Firewall at the aggregation router
4. Firewall at aggregation router and as the school
5. Firewall on the host

Options 3 and 4 may be considered a 'firewall in the cloud' from the schools perspective as they sit on the other side of the aggregation network, and importantly on the upstream side of the router.

The network effect cannot be ignored and schools on the NEN will take value from the network effect at the local level.

It is related to the fact that the number of unique connections in a network of a number of nodes (n) can be expressed mathematically as the triangular number n(n − 1)/2, which is proportional to n2 asymptotically<ref>Template:Cite web</ref>.

The above diagram shows the increasing utility or value of the network based on the number of connected users. If we make the assumption that this value is ascribed back to the connected user then the value to an end user will be increased by their number of connections they can make. By increasing the number of connections that can be made locally the local value to all users increases.

The above diagram shows that unless all connections to an aggregation network are implicitly trusted then the connection between schools and local services must be through the main firewall at the distribution router. By way of example if there were a shared resource such as a backup service in one single school accessible to all; no route (whether static or dynamic) between the school and the backup service could exist unless there was an implicit trust. This level of trust is unlikely as it would require trusting every end user.

Firewall Specifications

Recommendation: A firewall must meet the minimum specifications as defined by REANNZ and the NEN. The network wrangler is to determine suitability.

---

Firewalls must be able to pass packets without limiting the available bandwidth or breaking any protocols that are expected to run across of the NEN via KAREN. This will be dependent on a number of factors, these include:

• Configuration of the firewall rules.
• Additional functions outside of network fire-walling that are taking place such as UTM functions.
• The number of connections the stateful firewall must monitor
• The volume of packets passing through the firewall

The majority of schools will be connected to KAREN at a minimum of 100Mbps, a level of connectivity above that of homes and most businesses. Valid concerns have been raised that the firewall could be a single point of failure as solutions recommended by third parties may not be capable of handling the 100 Mbps throughput and destroying the KAREN and NEN experience. This has been observed already as perfectly capable SOHO router and firewall appliances have been recommended that would not sustain much more than 10Mbps throughput.

There have been some concerns over complex configurations slowing traffic as well.

Combined Routers and Firewalls

Recommendation: The suitability of the access router to act as a firewall should be investigated and the appropriateness for schools assessed .

---

The NEN Edge Router RFP released in April 2010 specified routing functions, not specifically firewalling capability. It is likely that a the router that is acquired may have firewall functions built into it. This is empahsised by the requirement for DMZ functionality.

The use of the router as a firewall would provide a common build and platform which may enable much easier and efficient services management/FCAPS. This could be carried out by the wrangler or centralised depending on demarc.

Other Security

Recommendation: xxx.

---

As discussed the firewall has become a synonym for security. There is a real possibility that other security could be assumed to exist within the firewall. However a lot of security as defined in UTM is provided at the application layers not the network layers. This does mean while we may have been conditioned to think of security as a single thing, in reality it is a series of applications working at a different network layer. As a result these security functions do not need to be in one place, and in reality that can exist quite separately (they need not though).

Looking at the non network Layer security functions it is possible to identify where these may be provided in the network and by whom.

E-mail filtering -

Spam filtering - is something well handled by either the mail provider (where a third party is used) or on the mail server. It should be noted that in delivering the NEN the via KAREN direct peers with Microsoft and Google will exist, in this instance the Gmail and Microsoft-Live@EDU services provided to schools will have this incorporated into it. It will be interesting going forward to see how many schools retain mail infrastructure given its move in general to the cloud.

Reporting -

VPN Concentrator -

Content Filtering -

FCAPS and Services Management

Recommendation: xxx.

---

Changes to firewall rules are expected be minimal post initial configuration. If a school has a defined security policy there should not be major exceptions to it, exceptions may include:

• Port forwards to services inside of the firewall, although a DMZ on the router may lower the need for this
• Blocking of protocols or services should they become problematic e.g. Should bittorrent is used for non legitimate purposes

It would be good to understand how often changes are made to a network firewall in a schools environment. It is anticipated to be minimal.

This is an example of a change given by TheLoop, as it is a service used by all schools, the change is made once across all firewalls. This example is from the EVO manual ([1])

Mandatory:

While EVO works fine in a Network Address Translation environment (NAT), the local or institute firewall (if any) should permit communication on the following port. IN/OUT

• UDP/TCP: 46015

Optional: Allowing these TCP outgoing ports will offer the possibility to your Koala client to estimate in real-time what are the best Panda servers to connect to in function of your location, network parameters (bandwidth, packet loss...) and load.

OUT - TCP on specific IP

1. LUSs Services: 4042, 4043, 4044 evo01.cern.ch (192.91.244.138) evo01.caltech.edu (131.215.116.151)
2. Proxy Services: 60001, 60002, 60003 evo01.cern.ch (192.91.244.138) evo01.caltech.edu (131.215.116.151)
3. Topology Services: 10090 evo01.cern.ch (192.91.244.138)

Governance Level Statements

Recommendation: A governance level statement is developed with the primary audience be DP level. This statement will define what a school needs to provide in firewall capability.

---

Drawing from the NEN technical mailing list as suggestion was put forward that the following options exist in ascending order:

1. There is a NEN governance statement of the expectations of what schools should be doing to ensure effective firewalls – and that this be written in to the NEN agreement
2. The NEN provides network wrangling resource to support the loops in their management of the firewall environment – if ever there was an aspect that needs serous wrangling then this is it!
3. There is capital made available for loops that are interested and able to develop and manage an appropriate combination of firewall solution(s) for their constituent’s schools. The Nelson Loop has shown that this can be done as long as the structure and expectations are clear – but it is a costly exercise in terms of $$$$ and time.
4. The NEN take over firewall responsibility – would be great for schools? But just too hard – and the solution could well be unresponsive to educational and local needs.

Firewall Metrics

A question that needs to be addressed is how do we measure a firewall and what thresholds does a measurement need to reach. We want to look at more than a feature and actually define what is required and what must be met.

With the evolving firewall a long list could be created. Some suggested metrics are below:

Metric	Units	Notes	How this would vary between schools
Throughput	Mbps	Should be at least 100Mbps but may need to be 1 Gbps depending on aggregation network.	xyz
Concurrent Connections	Number (bi-directional?)		Larger schools will likely have more concurrent connections
Interfaces	Number

What Are Schools and Aggregation Networks Doing

School	Type	Aggregation Network	Current Connection Speed	Roll	Firewall Solution	Notes
Nayland College	Secondary	TheLoop (Nelson)	1Gbps	1600	Watchguard, AT4550 and ISA	A hosted external Watchguard firewall manages standard firewalling. Granular management is done locally with a parallel solutions usually include a ISA firewall for web traffic and a hardwired firewall for other protocols.
TheLoop Schools	Primary	Net	1Gbps	600	Watchdog and AT440S	Hard schools to protect. The ‘real’ firewall is usually done by a AT440S router but does drag on fast networks... but most schools this size have not got fast networks that will tax this firewall. SNUP schools should move to a hosted firewall such as the above Watchguard firewall to avoid slowdowns.
TheLoop Schools	Primary	Net	xMbps	100	Watchdog and SmartNet	SmartNet have a turnkey system with a Linux squid setup. Simple and easy but limited in bandwidth as it is a soft firewall. Good for small school (suits half of NZ school). Loop firewall or Watchdog do email/spam etc.