[Tfug] Lightweight IDS options/strategy/policy

[Kramer Lee]

The best thing would be to be able to keep packets of your information
from going out of the computer.  So what if there is an intrusion? it
only is a problem if there is an outflow of information as a result of
the intrusion.

On 6/13/13, Bexley Hall <bexley401 at yahoo.com> wrote:
> 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
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>