Re: Outgoing IPSEC

[Securi Net <securinet2004 () yahoo ca>]

Thanks again, Jason.

That clarifies it and gives me a strong case in
denying such requests.

Thank you everyone for your responses.

Regards

CP

--- Jason Thompson <securitux () gmail com> wrote:

> No problem.
>
> With a stateful inspection device (firewall), it
> does allow
> bidirectional traffic as long as your client
> initiates the VPN
> connection to the endpoint. Once the client connects
> to the endpoint
> it creates a connection that your firewall
> recognizes as 'in state'
> and allows traffic between the two devices. This is
> by design. So with
> a stateful inspection firewall, even though you are
> creating rules
> that say allow only outbound from client to
> endpoint, you are
> essentially saying 'only the client is allowed to
> initiate a
> connection'. Once the client creates the tunnel,
> bidirectional traffic
> is permitted so long as it obeys the rules of IP
> "state" (same IP
> addresses, connection kept alive, in the case of
> TCP: syn, syn/ack,
> ack, push, push/ack, sequence numbers,
> acknowledgement numbers, etc).
> UDP state is also kept using timeouts, since UDP is
> a stateless
> protocol.
>
> Keep in mind, the ACTUAL TCP, UDP, and IP header (of
> a tunnelled
> connection) from a client or VPN endpoint is
> encrypted / encapsulated
> with a completely different header. So an IKE UDP
> packet's
> encapsulated data from the endpoint to the client
> (which is in state)
> may be a TCP SYN (beginning of a TCP connection from
> the other network
> to the client).
>
> -J
>
> On 11/21/05, Securi Net <securinet2004 () yahoo ca>
> wrote:
> > Jason,
> >
> > Thank you for your elaborate response to my query.
> >
> > Excuse my ignorance of the way IPSEC tunnels are
> > established here, but by permitting only outgoing
> > traffic on port 500, would I not succeed in
> forcing a
> > uni-directional tunnel to the external
> organization.
> > Or is my understanding of the technology off the
> mark.
> > We have mulled over the option of forcing him onto
> a
> > seprate VLAN, but need a clinical argument about
> the
> > secuirty risks in opening up IPSEC for him. This
> is
> > also being backed by an acceptable use policy.
> >
> > Thanks again for your responses.
> >
> > CP
> >
> > --- Jason Thompson <securitux () gmail com> wrote:
> >
> > > Here's one of the big issues which deals with
> the
> > > endpoint rather than
> > > Internet threats.
> > >
> > > Once the VPN connection is established, you have
> no
> > > control over what
> > > traffic is transmitted on the tunnelled network.
> You
> > > essentially open
> > > an unchecked bidirectional link between the VPN
> > > client and the network
> > > to which he is connecting on the other end. You
> are
> > > essentially
> > > relying on the other company to enforce a policy
> on
> > > that contractor,
> > > which  is a nauseating thought. Also in the case
> of
> > > a split tunnel,
> > > that contractor's PC could be used by someone or
> > > something in the
> > > other organization as a jumping point into your
> > > network. Further to
> > > that, since the traffic is encrypted, you do not
> > > have the ability to
> > > monitor what the contractor is doing. This
> > > individual could be doing
> > > anything from browsing questionable sites
> through
> > > company X's network
> > > to receiving the worm-du-jour. Single tunnel
> does
> > > nothing here,
> > > because in a single tunnel situation once
> > > disconnected from company
> > > X's network, it will spread throughout yours.
> > >
> > > It's all about acceptable risk of course, and
> > > unfortunately in a lot
> > > of cases contractor access to VPN is a
> requirement,
> > > so do what you can
> > > to lock it down. First off put the contractor on
> a
> > > different VLAN than
> > > other users and do not allow access to your
> internal
> > > resources; the
> > > VLAN should route right to your firewall. If
> s/he
> > > needs access to
> > > internal resources, then s/he does it with one
> of
> > > your company's PC's.
> > > Also, make the contractor and the other
> organization
> > > sign an
> > > acceptable use policy as well as a policy
> specifying
> > > that 'due care'
> > > will be taken while operating inside the network
> (AV
> > > always on,
> > > desktop firewall, regular AV scans and updates,
> > > etc). That way if they
> > > introduce something nasty into your environment
> and
> > > they didn't
> > > exercise due care, they can be held liable. But
> most
> > > importantly, the
> > > policy shows the other organization that you
> take
> > > information security
> > > seriously and you have your eye on them.
> > >
> > > If s/he needs access just to get e-mail, the
> > > consulting company should
> > > be putting up an OWA server with two factor
> auth...
> > > if they don't have
> > > one already. Some companies require it as they
> don't
> > > allow VPN out at
> > > all.
> > >
> > > -J
> > >
> > > On 11/18/05, Securi Net <securinet2004 () yahoo ca>
> > > wrote:
> > > > Hello List members,
> > > >
> > > > I have a question on risks associated with
> > > allowing
> > > > outgoing IPSEC traffic on a firewall.
> > > >
> > > > I have a contractor who works onsite within
> our
> > > > network and needs outgoing port 500 opened  on
> our
> > > > firewall for him to vpn into his company
> network.
> > > > I would like to know about the risks involved
> in
> > > > facilitating such access outside, as I have
> heard
> > > some
> > > > talk about security issues around split
> > > tunnelling. As
> > > > far as I can understand it, the only threat to
> our
> > > > network from the outside would be if someone
> on
> > > the
> > > > outside tries to spoof a session inside using
> an
> > > > existing outward connection.
> > > >
> > > > Can anyone shed some light on what I shud be
> > > concerned
> > > > about here.
> > > >
> > > > CP
=== message truncated ===



        

        
                
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca