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
__________________________________________________________
Find your next car at http://autos.yahoo.ca
__________________________________________________________
Find your next car at http://autos.yahoo.ca
