RE: Sources for Extranet Designs?

["Wes Noonan" <mailinglists () wjnconsulting com>]

> I totally agree with what you are saying.  Of course, we would be taking
> (and already do) the minimalist approach.  In other words, we only allow
> very specific things into our network (extranet or internal, doesn't
> matter).  However, allowing these connections does not preclude someone
> from trying to abuse our servers/services.  I guess I am not comfortable
> with just [stateful] packet filtering or other non-application-aware
> security gateways.  Maybe I should look into some other type of IPS.

IPS would be a no brainer for me in this scenario. One thing I don't want to
do is give you the impression that packet filtering is the only way to go.
Was it Marcus that said "Security is like onions, there are many layers"?
That is a good way to approach it. Using CITRIX front ends are another
option I would look at to determine if it is viable or not. I know of many
folks who are doing this or using Citrix on WYSE terminals running XP
embedded to do this kind of a thing. Gives them even more control.
 
> Perhaps I need to investigate something that can perform the same
> functions that our DMZ web servers perform.  Perhaps something that can
> act as a go-between or proxy, which we can be sufficiently locked-down.
> Anybody know of anything that can do this, besides SOCKS (which would
> only provide authentication, I suppose)?  While you are giving your
> partner 1521 access to a particular server, there could be many
> databases located there.  What if you just want them to have access to
> one?  I guess you could design your DB architecture better, but that is
> beyond this discussion :)  The key would probably be the SID in my
> situation, but that would require something that can look into the
> application data (please no SEF/Raptor firewall references please :) ).

Actually, I don't think it is beyond the scope of the discussion. In fact, I
think that a lot of the problems that are created by these scenarios are the
lack of someone to look at the problem and solution from top to bottom. The
network guys work the network, the app guys work the app and no where do
they work together. When you start to get into questions of "what about the
other databases on that server" that is where I think the app guys have to
step up and do the necessary hardening at that level, especially if you have
a limitation of not being able to separate resources.

> Yes, this is what we will most likely implement.  NAT on our side,
> hiding our real address scheme, using some routable addresses we already
> own.  However, do you usually require your customers to present you with
> routable address from their side?

I'm indifferent. Like David said it is easier to use routable addresses. If
not, work some NAT magic. Doesn't matter too much to me.

HTH

Wes Noonan
mailinglists () wjnconsulting com  
http://www.wjnconsulting.com  
Hardening Network Infrastructure - A concise how to guide
Available Spring 2004
Order at http://tinyurl.com/2nof4 



_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards