[Tfug] Lightweight IDS options/strategy/policy

[Bexley Hall]

Hi Yan,

On 9/26/2013 1:18 AM, Yan wrote:
> Out of curiosity, if you use MAC addresses for access control in your
> network (unless that was a simplified example), how do you prevent MAC
> spoofing on your networks? I'd imagine you'd have to go with something like
> 802.1x, at least.

Essentially, I *first* look at everything that you *assume* about
a "connection" (IP, MAC, protocol, etc.) and verify/enforce those
assumptions.  This catches "wiring errors" (the security camera
is plugged into the wrong router port, etc.) and "software bugs"
(why is the hot water heater trying to talk to the doorbell?)
along with naive/unintentional misuse (why is this laptop trying
to access my music server?) and most "amateur" attacks.

These are all trivial to implement and have very little cost.
They also offset bits of code that would otherwise have been
included in the network stack (e.g., I don't have to snoop
connections to keep ARP cache up-to-date... it's "hardwired"!)

Beyond the trivial tests, I use encryption with frequent key changes
to make initial penetration "very difficult".

And, if you manage to correctly "impersonate" *THE* device on
that port, all you can do is exactly what that device could do.
E.g., a security camera can send video to a particular port
on the "DVR" -- it can't telnet to the authentication server
or talk to the HVAC system, or ...

Finally, when I see something wrong on a connection, I take the
connection *down*.  I.e., you have to get through the security
layers *quickly* -- you can't just sit on a port hammering away
*hoping* to get through.  "The device on this connection is
either exhibitting software bugs or a deliberate attack.  I'll
just ignore *everything* on this wire until someone has manually
intervened"

> On a slightly different topic: the DNS communication method you
> demonstrated is quite realistic, aside from being a good example of a
> covert channel.

Yes, I've used it to "smuggle" configuration data in/out of
corporate firewalls -- when dealing with BofH's was just not
worth the effort.

> There's a cool tool called iodine (
> http://code.kryo.se/iodine/) that uses the technique to create an
> IP-over-DNS tunnel. It's intended use is punching through WiFi paywalls.
> Just figured I'd toss it out there in case someone was unaware of it and
> interested.

Any protocol that a device can be expected to support in its normal
operation can be repurposed to provide a covert channel.  E.g.,
SMTP, NNTP, HTTP, etc.  Of course, you probably want to disguise
the payload so it's not too obvious.

For long-lived connections/uptimes, its just not practical to examine
all transactions *hoping* to see something fishy.  Esp if the details
of a particular device's implementation are "proprietary".  You're
just told what holes to drill through your firewall/packet filter
and have to *hope* its not being used for nefarious purposes.

Similarly, if you install an "app" on your <whatever> (e.g., smartphone)
and it *claims* to need access to <something>, how do you know it is
using that <something> in a way that doesn't harm you?  Or, *benefit*
someone else (without compensating you)??

What if the app claims to need access to *lots* of <something>s?
Are you qualified to evaluate whether it *should* need that access?
Are you capable of imagining how that access  can leak *other*
information that you wouldn't otherwise want to grant access to
if the app had explicitly asked for it??