RE: Sandboxing
From: Jared Valentine (hidden@xmission.com)Date: 05/17/02
- Previous message: John Sciandra: "RE: Sandboxing"
- In reply to: Bill Royds: "RE: Sandboxing"
- Next in thread: Lawless, Tim: "RE: Sandboxing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Jared Valentine" <hidden@xmission.com> To: "Bill Royds" <sf-lists@royds.net>, "John Van Boxtel" <john@whoowl.com> Date: Fri, 17 May 2002 01:01:38 -0600
Bill:
Yes, the 3Com Embedded Firewall would be extremely useful and enabling (in
your case) when you look at it in a VPN context. We don't have a VPN client
on the Embedded Firewall yet, but you can accomplish quite a bit with the
already available firewall functionality. Assume a security policy that
looks like this:
1.) Allow DHCP Client
2.) Allow DNS Client
3.) Allow VPN to Corporate VPN Concentrator #1
4.) Allow VPN to Corporate VPN Concentrator #2
5.) Deny all other traffic
This security policy will accomplish quite a few things: It keeps the
remote machine secure while connected to ANY network (home broadband,
hotel/visitor networks, etc.). It prevents split tunnelling, which
ultimately keeps the corporate network secure. It is compatible with any
IP-based VPN client software, and most importantly, it extends the
protection of your corporate perimeter firewall to the remote machine. By
virtue of only allowing VPN, you can also filter web traffic, apply
corporate Internet policy at the border, and even inspect the traffic with a
NIDS box!
Since we're talking about remote telecommuters, I must point out that our
current solution is only available on PCI cards for desktops and servers. A
Cardbus Firewall card for notebook computers is <very> close, though.
Jared Valentine
Network Security Consultant
3Com Corporation
jared_valentine@3com.com
-----Original Message-----
From: Bill Royds [mailto:sf-lists@royds.net]
Sent: Thursday, May 16, 2002 5:39 PM
To: Jared Valentine; John Van Boxtel
Cc: Loki; focus-ids@securityfocus.com; forensics@securityfocus.com
Subject: RE: Sandboxing
Would this be useful in a home VPN context? By having the NIC be a hardware
VPN with a secure remote configuration option, one would control access so
that unauthenticated traffic would not pass, and all traffic would follow a
policy.
I recommended against remote VPN access to my employer because of the
risk of trojaned home computers having full access to corporate LAN. This
would alleviate the problem in a manner that would be much more transparent
to employee at home.
-----Original Message-----
From: Jared Valentine [mailto:hidden@xmission.com]
Sent: Thu May 16 2002 16:05
To: John Van Boxtel
Cc: Loki; focus-ids@securityfocus.com; forensics@securityfocus.com
Subject: Re: Sandboxing
John:
> Did anyone else see this as interesting as an idea to INCREASE security?
I'd like to think so, but then again, I am the vendor. :) I would also
welcome input from the community as to how they view this.
Individual machine security was at the top of the list when DARPA
contributed to this product's research, and the Navy is calling this the
"most promising technology."
"embedded firewall demonstrated tremendous success in stopping a military
red team during the 2001 Fleet Battle Experiment India, where it was
identified by the Navy as the most promising technology."
(http://www.darpa.mil/body/NewsItems/darpa_fact.html)
The 3Com Embedded Firewall is not meant to replace perimeter firewalls, ACLs
on routers (although it could), antivirus or Host/Network-based Intrusion
Detection Systems. From an IDS standpoint (since this is an IDS list),
setting up proper rules on these firewalls will reduce the types and amount
of traffic that H/NIDS systems need to inspect, since only traffic which
conforms to policy is allowed in and out of systems.
It is positioned as an additional layer of security by being tamper
resistant, hardware-based, centrally managed, and distributed (in the
machine you want to protect).
> I would be interested in how the NIC authenticates requests coming to it
as legit from the policy server....
During the Policy Server installation, a public/private keypair is
generated. This generated keypair is then used to create a 'customized'
firmware installation package. This firmware update burns that public key
into the firmware of the NIC.
When the network interface card boots up, it encrypts a random 3DES session
key using the Policy Server's public key, and then registers to that Policy
Server (or group of policy servers). The Policy Server unencrypts the 3DES
key with it's private key, and then implements that session key for policy
updates from the server.
A rogue policy server won't have the private key. Without that key, it will
be unable to determine the random 3DES session key and will be unable to
push policy to the NIC. This architecture prevents someone from just
setting up a rogue policy server and pushing policy.
Of course, you will want to protect the Policy Server. This includes
physical security, machine/login access, and network security (which can be
handled by a 3Com Embedded Firewall as well).
Additionally, all attempts to re-flash/upgrade the NIC will be denied unless
the action has specifically been authorized by the Policy Server first.
ACLs on routers can block traffic between subnets, but the 3Com Embedded
Firewall is the only (economical) hardware solution that can control that
traffic down to a per-machine level. Additionally, it also prevents
compromised machines from sniffing/promiscuous mode, and spoofing).
I apologize for the long-winded reply. These answers will probably generate
more questions. Additional questions are welcomed at my 3Com address or to
the list as well.
Thank you,
Jared Valentine
Network Security Consultant
3Com Corporation
jared_valentine@3com.com
- Previous message: John Sciandra: "RE: Sandboxing"
- In reply to: Bill Royds: "RE: Sandboxing"
- Next in thread: Lawless, Tim: "RE: Sandboxing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
