[Tfug] Lightweight IDS options/strategy/policy

[Zack Breckenridge]

Talk of neural networks in this context reminds me of this old Defcon
presentation: http://www.youtube.com/watch?v=3GkgUbJhhvI

- Zack


On Tue, Sep 24, 2013 at 3:08 PM, Kramer Lee <krameremark1 at gmail.com> wrote:

> 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
> >
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20130924/76db1e92/attachment-0002.html>