Good question! You don't have to address the attack to the IDS.
By definition, it's capturing all the traffic on the netowrk and
doing at least some preliminary analysis on it. that means that
every packet has an opportunity to affect the IDS.

The degree of difficulty would be directly affected by your objective.

If the primary target is another machine, then the objective is to
create a DoS on the IDS. Rather than evading the IDS, just kill it.
This would allow you to attack other machines with relative impunity.

If the target is the IDS machine, then it becomes more interesting to
see what the IDS may have on the back-end network. If it connects to
the main network then perhaps the IDS can come back to the attacker
through that connection. If it connects to a separate back-end network
then that may interesting to explore.

In any case, it does open up some interesting opportunities for
"thought experiments".

It's easy to discard this whole thread because, "How will they know
what IDS I'm running?" and "I have the TX wires cut" but security
through obscurity has been demonstrated to be useful but not insurmountable.

This deserves some serious consideration by IDS vendors/providers.

<bait>
This could be an interesting argument for open/closed source. :)
(aren't religious wars fun?)
</bait>

-----Original Message-----
From: Michael Lea [mailto:mleaATOMICBLUEBEAR.ORG]
Sent: Tuesday, January 09, 2001 12:43 PM
To: FOCUS-IDSSECURITYFOCUS.COM
Subject: Two-headed NIDS - security risk?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One common suggestion I've seen for implementing NIDS is to have two
interfaces in the box. One interface is unaddressed, and is used to
monitor the target network. The other interface has an address and is
connected to a network that is isolated from the target. This second
interface is used for management, alerting, and whatever else you might
want the box to do.

For the especially paranoid, people have recommended snipping the TX wires
on the unaddressed interface or using some sort of tap to enforce a
listen-only behaviour.

The theory behind this, as I understand it, is that since the NIDS does
not have an addressable interface on the monitored (and "untrusted")
network, it is not subject to attacks. However, as NIDS is becoming more
complex with protocol decoding and the like, isn't it possible (even
likely) that an attacker could craft an attack that would cause the NIDS
to execute arbitrary code and be used as a launching point for an attack
into the "trusted" world.

You can take the recent (i.e. November) protocol decode bugs in Ethereal
and tcpdump as an example of this in action.

Have those of you with two-headed NIDS considered this? Is it a serious
concern, or am I being overly paranoid? Is there a solution?

- - Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: Made with pgp4pine 1.75-6

iEYEARECAAYFAjpbd/sACgkQc9EFi4qQZEyZRgCfSHaV2iCstKkJ/5wdvwAlu/Cp
7BYAoNswHnZj4WIVBzGmK7t4cLGaD1YG
=6Dfj
-----END PGP SIGNATURE-----

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