[Tfug] Lightweight IDS options/strategy/policy

Kramer Lee krameremark1 at gmail.com
Tue Sep 24 15:08:36 MST 2013

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

More information about the tfug mailing list