Re: Stateful Perimeter Firewall

[Matthew Wollenweber <mjw () CYBERWART COM>]

Couldn't agree with this more. Plan out your transition in a very
detailed manner. Additionally, do it in stages. Start every rule
change to a LOG and then move to a DENY after you've reviewed the
logs. Start with blocking known "bad" ports such as NetBIOS, IRC, SMTP
to non-mail servers, Proxies, etc. Gradually increase the rules list
until you can get to default deny. If you simply hit the switch to
default deny without a detailed and iterative transition things are
going to break -- badly.


On Tue, Oct 13, 2009 at 10:59 AM, Di Fabio, Andrea <adifabio () nsu edu> wrote:
> 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



-- 
Matthew Wollenweber