[Tfug] Lightweight IDS options/strategy/policy

Bexley Hall bexley401 at yahoo.com
Thu Jun 13 01:40:13 MST 2013


Hi Bender,

On 6/12/2013 5:49 PM, Bender wrote:
> Two words... Neural Networks

ANN's are a good approach when the problem is "squishy"
(i.e., hard to define firm constraints) or when it needs
to learn/adapt to *actual* usage.  E.g., identifying
*your* "normal" usage patterns/traffic so it can identify
*differences* from that norm.

In my case, all of the interactions are rigidly defined
and known a priori.  I.e., node Ns at MAC Ms and IP Is will
use protocol Ps to interact with node Nd at MAC Md and IP Id.
(Repeat for all other nodes that Ns interacts with; then
repeat for all other nodes in the system...)

So, I can easily tell when something "foreign" enters the
network as one of these invariants will be contradicted.
In those cases, I can ignore/block the traffic and protect
the devices in the system.

These events can happen in one of two scenarios:
- something is trying to infiltrate the network
- something is *broken*
(the remedy in each case is to block the defective traffic).

E.g., a "security camera" should never be trying to open a
telnet connection to the "irrigation system" (the irrigation
system will refuse the connection, and...????); a "foreign"
IP should never be trying to open *any* connections to
*any* of these devices, etc.

[I know where every node is -- IP,MAC -- along with what it
*does*... and *how* (protocols, etc.)]

So, violating any of these invariants means something is
apparently "wrong/broken":  why is that security camera
trying to open a telnet connection?  (there's no telnet
client code *in* the security camera!!!  WTF?)  I can
treat this, intially, as a possible "fluke" (perhaps a
device has crashed and needs to be reset; if so, try
commanding this and, if that doesn't work, cycle power;
then watch to see if the problem persists/repeats)

[Note there are a *lot* of invariants that I can enforce.
E.g., if I've powered down the "security camera" and I
see *any* traffic originating over that physical link,
then I know it's not the security camera!!  :-/ ]

If something is "broke", then I can inform the user accordingly.

The bigger problem is how to deal with traffic on semi-open
drops that is "wrong".  E.g., if someone plugs in a laptop and
accidentally or innocently tries to telnet to a "device" that
isn't supposed to accept incoming telnet connections, when
do I decide that this has progressed from an "innocent mistake"
to a "concerted attack effort"?

And, other than blocking the traffic (which is a normal behavior),
what should the user be told?  And, what can he be expected to
do to remedy it??

[How many "PC" users know when/if their systems are being
probed, attacked, etc.?  Is there even a mechanism in place
to *detect* these things -- other than those folks actively
running IDS's?]

> thanks for an entertaining post, don.

You should see it in FULL COLOR with the FOUR PART HARMONY
accompaniment!  Truly impressive!!  ;>

--don




More information about the tfug mailing list