SIUC Campus Firewall

The SIUC Internet Firewall provides network-based protection of computing resources at SIUC from Internet based attacks. For general information about the campus firewall, please see the Fall 2004 Dawgbytes firewall article.

NETWORK FIREWALLS ARE ONE IMPORTANT LINE OF DEFENSE BUT SHOULD NOT BE THE ONLY LINE OF DEFENSE.

If you need to add a resource to the Campus Firewall, please use this Firewall Rule Request Worksheet. Prior to submitting a worksheet, please read the following guidelines for faster and more efficient service.

Network Traffic Policies

IT runs a firewall at the network edge, between SIUC and the Internet. The default inbound policy is to deny anything that's not specifically allowed through. This stops a great deal of exploitation and scanning attempts (often thousands of potential attacks per day). The default outbound policy is to block certain types of dangerous traffic and then allow everything else outbound. Traffic regarded as dangerous includes Windows networking (SMB/CIFS - TCP/UDP 139, 445), Microsoft Remote Procedure Call (MSRPC - TCP/UDP 135), MS SQL Server (TCP 1433, UDP 1434), and other types of traffic commonly associated with malware. Outbound email is also filtered to reduce the problem of SIUC being a source of SPAM. This means that any system that must initiate outbound email connections using TCP port 25 (SMTP) must be documented and submitted to the firewall management team. At this stage all known authorized email sources on campus are already documented and functioning.

Submitting and Updating Firewall Rules

Several departments on campus are forgetting to update their firewall rule requests when their networks change. Please review the firewall rules you have submitted and be aware of the need to re-submit changes as the change is a manual process. If the hostname and IP address of any system changes, every firewall rule affecting that host must be edited. Therefore, please take the time to ensure that the proper ports are listed on your worksheet.

When firewall rules must change, please clearly indicate what rules should be removed, added or modified in your worksheet and include the date.

The IT edge firewall administrators won't accept rule requests unless they are filled out properly according to the guidelines and using the rule worksheet found at-

http://www.infotech.siu.edu/security/services/Campus_Firewall_Rule_Submission_Form.xls

All firewall rule requests should come from a LAN Administrator or other authorized computer support staff and should be mailed to firewall@siu.edu. Do not send a firewall rule request to any other email address. Please be sure to fill out all information in the rules worksheet. The first entry in the otherwise blank worksheet is an example that you may follow.

If you are uncertain about what ports or protocols a specific application uses, please reference your vendors documentation or use system utilities to determine this information. If you cannot easily determine this information, please contact your vendor directly.

All firewall rule submissions are confidential and will be verified. The Network Security team reserves the right to allow or disallow any particular type of service at any time.

Rule submission for email servers

Campus email servers must be approved by the IT Security team before they will be allowed access through the firewall. Email rules exist both directions through the firewall and therefore require a different syntax as demonstrated in the following example worksheet-

http://www.infotech.siu.edu/security/services/SIUC_Email_Server_Submission_Form.xls

Network Firewalls - what they can, and cannot protect

A network firewall is a big help, but the trend in attacks these days is to attack applications directly. Most network firewalls can't block an attack directed towards a service that's allowed through the firewall. For instance, if you submit a firewall rule to allow anyone in the world to connect to port 80 on your web server, then the firewall is useless in stopping attacks against that server on that port. So if you have misconfigured or unpatched web applications (such as apps based on PHP, ASP, JSP, cgi, etc.) then they will become targets. The same principle is true for any other service. For instance, if you open SSH (secure shell) on your OSX server to the world on TCP port 22, then expect that attackers will be trying to guess passwords. In that case, if you have weak passwords on your system that are easily guessed or very common, then an attacker may penetrate your system and the firewall won't do anything to stop it because as far as it knows, it's doing it's job. This is one reason why a suggested workaround for the above SSH scenario is that people use the IT VPN instead if they must SSH into a system for systems admin work.

Since Windows is the dominant platform on campus, and receives the greatest number of attacks, we will focus on Windows for our example below. These same principles apply to OSX, Linux, and any other system.

Now that Windows XP features a client firewall that's enabled by default in Service Pack 2, a great deal of Windows PC's are now protected from the garden variety worm and network based attack that targets open ports that correspond to vulnerable services. There are some scenarios where ports will still be open and XP desktop users will still be at risk from network-based worms, but these scenarios are becoming fewer over time. Servers on the other hand, that are built to allow access to services, will continue to be a larger hole if they are not patched and configured securely. Windows 2000 does not contain a firewall by default although add-ons are available (ZoneAlarm, Mcafee 8i, etc). While network based attacks are still very common, contemporary attackers are now spending their time targeting things such as web browsers, instant messaging clients, system library components (image library DLLs, etc), multi-media apps (flash, audio/video players, plugins) and other client-side vulnerabilities and also network-enabled apps such as web applications and backup software. Even anti-virus software has become a target for exploitation.

The SANS Institute top-20 vulnerability list now includes a great deal of application specific issues. I recommend any computing professional on campus read this list and understand your particular risks:

http://www.sans.org/top20/

Some client-side applications require a manual update and therefore are less likely to be patched as quickly (or at all) than the core OS. Attackers know this, so should you.