RE: [fw-wiz] Sources for Extranet Designs?

From: Baumann, Sean C. (Sean.Baumann_at_celera.com)
Date: 02/23/04

  • Next message: Mitchell Rowton: "RE: [fw-wiz] Sources for Extranet Designs?" 
    To: "Wes Noonan" <mailinglists@wjnconsulting.com>, "R. DuFresne" <dufresne@sysinfo.com>
Date: Mon, 23 Feb 2004 15:32:52 -0500

    > -----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

  • Next message: Mitchell Rowton: "RE: [fw-wiz] Sources for Extranet Designs?"

    Relevant Pages

    • RE: [fw-wiz] Sources for Extranet Designs?
      ... One thing I always wonder about in Extranet designs: ... Customer B's orders, or even to hack Customer B's network, how liable are ... Its one thing to protect the host organization from Extranet clients: ... More detailed design you will probably have to pay me for. ...
      (Firewall-Wizards)
    • My Inbox, My Calendar web part access from extranet
      ... My Calendar Web Parts cannot be displayed from extranet. ... work fine when accessing via default url from within LAN. ... Is this by design? ...
      (microsoft.public.sharepoint.portalserver)