According to the paper "Secure, User-level Resource-constrained Sandboxing"[1]
by F. Chang, A. Itzkovitz and V. Karamcheti:

  "Sandboxes (are) environments that impose irrevocable qualitative and
  quantitative restrictions on resource usage."

Because we are talking about network traffic/NIDS here; the devices
best suited for imposing these restrictions are routers, switches
and firewalls. A properly configured, stand-alone NIDS is more trustworthy
than any HIDS in my commercial security industry development experience
(outlined at the end of the email).

Cisco NetRanger has the ability to "shun" networks after they trigger events
in the NIDS by communicating with routers and updating ACLs. Others may have
this capability under a different name. This is very practical in any size
environment and relies on thorough analysis of attack methodologies and
well-written IDS signatures.

An excellent tool "SnortSam"[2] allows snort to update Checkpoint FW-1 and
Cisco PIX firewall ACLs/rulesets.

I would never trust a daemon sitting on each of my servers to bring its own
interfaces down after detecting an attack. Given the widespread use of syscall
hijacking trojans and the frightening statistic that loadable kernel modules
are enabled on many production servers; unless you took stringent measures to
ensure your machines are locked-down I would prefer the shun/snortsam method.

The BSD securelevel facility is wonderful and should be used by more people.
Bruce Simpson ported this to Solaris last year as an LKM and should be
available on the 'net somewhere.

A brief point about sending RST packets to the source of an attack after a
signature has been triggered: the attack has already done the damage. If the
exploit payload was written properly, one packet may be all that is necessary
to bind a shell to a port; allowing the attacker remote root access. Without
shunning the source(s) [for lack of a non-commercial term], the "RST method"
of "stopping" attacks is useless.

If not already available, I'm certain that soon SnortSam will support other
firewalls such as the open-source iptables, ipf, pf, and others.

[1] http://csdocs.cs.nyu.edu/Dienst/UI/2.0/Describe/ncstrl.nyu_cs%2FTR1999-795

Signed,
-jbl

On Wed, May 15, 2002 at 04:46:07PM -0400, Loki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lists:
>
> I was wanting to get the advice and feedback from the community on
> the idea of sandboxing compromised systems. What other than
> developing a daemon that sits on systems that can communicate with a
> central server awaiting commands to shut its interfaces down in the
> case of a compromise, are there? This is obviously possible but not
> practical in large network environments. Who here has had experience
> with this idea and/or implemented a viable solution in large
> networks?
>
> For those who might use a different term for this, sandboxing would
> be akin to sending a virtual RST to the machine to cut its
> communication off from the rest of the network in the event its
> compromised; protecting the rest of the network.
>
> Eric Hines
> Founder, Chief Research Scientist
> Fate Research Labs
> www.fatelabs.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBPOLJDht+6/TskgCXEQL14gCeN/KF3i7NP2WQ7qnVDzty59ZAsfIAoImN
> 5kWwf3vEWXnwQ6Lz7Tgphoyc
> =xjBS
> -----END PGP SIGNATURE-----
>

-- 
---=[ Practice is not a matter of years and months. It is concentration. ]=--
---=[ Email: jblsubterrain.net o0o Web: http://www.subterrain.net/~jbl/ ]=--
---=[ PGP fingerprint: 345A A958 67A3 A215 0270 5102 8002 8B4C 3803 A9BC ]=--

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]