[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Firewall - Very limited Access - suggestions



On Sat, May 29, 2004 at 03:53:57PM -0400, Kevin F. Berrien wrote:

> I'm intersted in building a bastion firewall for the following 
> sistuation.  Have a closed network (police dept).  There are no crosses 
> to the internet.  However, we'd like VERY LIMITED access by the Windows 
> DC server for the following: Windows update (via SUS), Symantec AV 
> updates, VNC/or remote desktop connection to 1 or 2 workstations on our WAN.
> 
> Thus, I want to limit all traffic except various protocols/ports between 
> specific IP's/URL's.
> 
> Certianly FC and iptables can do this, does anyone recommend a 
> configuration utility, start off  scripts, etc?  Should I be looking 
> more into LRP (now defunct), etc?  My iptables knowledge is not great 
> (did it years ago), so some configuration utility would be great, and my 
> co-workers isn't experienced in this area at all.

This class of good question will be more an more common.

Each software vendor should be asked for and be able to provide the
specific information needed to operate in a firewall environment!

They do not need to know what firewall (Cisco, FC2 with iptables, etc)
you are using.  In fact that detail should be opaque to them (use words
like restricted or classified).  They should be able to tell you
specific ports, protocols and hosts and if their tools are firewall
friendly.  Remember that they do not need to support firewalls they
need to support you in your use of a firewall with sufficient openness
and disclosure.

Then with the necessary info from the vendor the questions to groups
like this get simple and focused:

  How to configure iptables, on FC2
     port, protocol, hosts in, hosts out, time of day....
  Or if Cisco, How to configure my Cisco Firewall
     port, protocol, hosts in, hosts out, time of day....
  Or Free-BSD
  Or WindowZ
  etc...

One  example of software that punches selected holes in the firewall
is /etc/init.d/ntpd.  You can see how it opens and closes ports
for NTP to specific hosts.  You may wish to strip out all the sed
and awk stuff in a copy for clarity.

By documenting the meta problem fully then switching tools
becomes possible.

Sadly some services do not lend themselves to firewall tricks.  The
vendor should however have a solution, if not, complain to the vendor
in writing ;-).

For some, you may need to establish a proxy or a resource mirror.
Tell the software vendor that you are mandated to be able to move and
audit the updates via sneaker-net on CDROM.

Some virus vendors use distributed download services.  Since these
services are used by many other companies it may be difficult to
isolate the good connections from all the others.  If this is the case
you need a local redistribution site.  Proxy or Socket services at the
firewall can have their own configuration controls.

For virus and software updates you may find that it is good to audit
the list of boxes that are updated and search out those that need
updates.  This is facilitated if you have an internal master
distribution host.  It is a little harder to track what was done if
you pass the connections through a firewall.

Each administrator has their own style, I like the idea of 
small focused single purpose tools touching things when possible.
  /etc/init.d/ntpd			 # Only NTP ports
  /etc/init.d/SunnydalePD-SemanticAV	 # Only SemanticAV updates
  /etc/init.d/SunnydalePD-VNC		 # Only VNC access 
  /etc/init.d/SunnydalePD-WinUpdateSUS

With specific information from  each of the vendor services you can decide
how to move ahead one script at a time.  Then review the resulting
tables for conflicts unintended interactions etc...

If you get it right you can do stuff like

   sudo service SunnydalePD-VNC [stop|restart|start]
   sudo service SunnydalePD-ALL stop

Change control, review and audit of small scripts is easy compared to
big piles of stuff.  service start|stop|restart can also be done via a
simple ssh text connection.  That could important if you need to lock
things down or open them up quickly.

For goodness sake make sure you have a small test environment.
When not used for testing it can be used as a honey pot ;-)


-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]