Educause Security Discussion mailing list archives

Re: Stateful Perimeter Firewall


From: "Di Fabio, Andrea" <adifabio () NSU EDU>
Date: Tue, 13 Oct 2009 10:59:54 -0400

We have been running border firewalls for a many years now.  I was actually the person who started the project and 
implemented it years back.  Here are a few pointers from what I recall was done at the time.  Your mileage may vary.

 

1.       Plan, plan, plan … did I say plan …?

 

2.       Have a Firewall Policy approved before implementation and have procedures and a strict change control in 
place.  In addition you should have a comprehensive firewall change form, which should be approved by your ISO, and the 
department VP or Manager requesting the change for each change.  Make sure you leave some slack in your policy and 
procedures for emergency changes … those happen more often than the planned one ;-)  Our form has 3 sections, one to be 
filled by a technical person, one to be filled by the project sponsor and one for IT.  We ask questions such as: is the 
system used for financial transaction or does it store PII, how is it patched? Etc.

 

3.       Log , log, log … did I say log?  And BTW your firewall policies and procedures should mention logs, where they 
are, who reviews them and how often and how long they are retained for.

 

4.       Once you have all your bureaucratic mambo jambo in place, you may want to look at

·         External DNS, to get an idea of what services have names outside

·         Routers and VLAN ACL sometimes may have entries for services allowed and blocked

·         Netflow, ntop or any flow or traffic analyzer you may have in place, nessus or other security scan logs to 
see what incoming services are being used the most.

 

5.       Outbound traffic control is as important as inbound.  Make sure you go over some firewall best practices such 
as protecting the firewall itself, only allowing SMTP from your email servers, dropping and not logging MS NETBIOS 
traffic, etc.  Use rule comments and note the reason, expiration and POC for the rule at a minimum.

 

6.       Inspection, inspection, inspection … did I say inspection?  Make sure you enable inspection for the well know 
firewall unfriendly protocols such as SIP, RTSP, FTP, etc., or you’ll break things.

 

7.       Whenever possible, use a staged approach, enabling ranges of IP addresses, starting with the least problematic 
ones (maybe the one where you think there may be no services at all) and ending with the server ranges.  This way you 
will avoid headaches and calls.  By that time you should have that process down.

 

I hope this helps, not very comprehensive but it should get you thinking.

 

Good luck!

 

Andrea Di Fabio

Information Security Officer

High Performance Computing Technology Coordinator

Norfolk State University

Office of Information Technology

Marie V. McDemmond Center for Applied Research, Rm 401F

555 Park Avenue, Suite 401

Norfolk, Virginia 23504

757-823-2896 Office

757-823-2128 Fax

 

 

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Dean 
Halter
Sent: Tuesday, October 13, 2009 9:11 AM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Stateful Perimeter Firewall

 


We are considering setting up our firewalls in a stateful, default deny manner.  Our folks would be able to communicate 
out normally, but folks on the outside would only be able to access resources for which there were explicit exceptions. 
 Anyone else doing this that might give us pointers on what we need to do in advance and what to watch for?  Is it 
problematic for certain types of software – p2p, grid, etc.?  Is this, as some of our folks say, too corporate? 

Thanks in advance, 
Dean Halter
IT Risk Management Officer
University of Dayton

"Security is a process, not a product."  Bruce Schneier 

Attachment: smime.p7s
Description:


Current thread: