RE: Sources for Extranet Designs?

["Baumann, Sean C." <Sean.Baumann () celera com>]

> -----Original Message-----
> There are a couple of approaches that I can think of off hand.
Approach 1
> is
> to design the services with extranet connections in mind. Simply put,
> maybe
> the mainframe isn't the right place to house that resource. This is
> probably
> not the answer that you want to hear though. Approach 2 is to accept
that
> you have a business limitation that is going to force you to implement
a
> less than ideal security solution. At that point, you mitigate it.
What
> precise ports need to be opened from the extranet to the internal
resource
> and grant *only* that access. If they need SQL access but not NFS
access
> then make sure that your firewall only permits SQL traffic to pass
between
> the two networks. Things like that.

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.

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 :) ).

> Depends. Assuming that you are going to be using firewalls and
advertising
> your internal resources as something else (through the use of NAT,
etc.)
> then you can do that and make the routable addresses what the extranet
> partners think they are going to connect with. That being said, you
can
> pretty much pick any RFC1918 address space at that point and use it in
a
> similar fashion. The obvious alternative is that someone will need to
> change
> their address space.

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?

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