Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Visualizing LAN traffic



On Fri, Jan 20, 2012 at 1:51 PM, Derek Martin <invalid at pizzashack.org> wrote:
> I'm inclined to agree with this, though I must admit I find the idea
> somewhat intriguing... ?I'm wondering if anyone has actually used this
> for real monitoring. ?If so, how did you find it?

I've never used it, but I'm inclined to have a different (not
necessarily opposite) view from what you wrote below.  Hopefully my
comments will, despite my lack of experience, will be interesting
rather than hollow speculation ;)

> Perhaps so. ?Still, this kind of tool strikes me as most useful when
> the computing environment being monitored is large enough to require a
> team to do the job, and I think therein lies the trouble.

Do you mean that the large monitoring space would be a problem, or
that the large number of people would be a problem?  I see the "listen
to it" solution as being perfect for a large monitoring space - our
brains are great at filtering sounds for useful information and
blocking out things that are uninteresting.  You could throw a ton of
information into an audio stream and reasonably expect most people to
be able to pick it apart, even while focused on something else.

> I expect
> many people probably could block out the background noise, whereas
> others might have a great deal of trouble.

This would be a challenge.  If I were going to use it, I'd wear head
phones so only I had to hear to it.  I like to listen to some
random-ish noise while I program anyway, to block out the distracting
things that are going on around me.

> The paper discusses the idea that typical network monitoring tools are
> reactive and therefore interrupt-driven, and that they only provide
> negative feedback, and no positive feedback.

I'm not sure how you could give positive feedback... unless he meant
it would actively probe your network for security problems, which (in
my mind) is a related, but different, problem set.

> Paging or some sort of audible
> alerting can be used to trigger action, so that only infrequent active
> monitoring, or even none at all, is required.

I may have the wrong idea about network monitoring, then.  Isn't it a
matter of picking through a constant stream of (normal, safe) data for
the few "weird" events which could potentially be dangerous, and then
investigating them?  It seems like listening to something, and relying
on your brain to provide the heuristics, might be a good solution.
Also, isn't live monitoring (so that you can respond quickly) better
than going through logs of past events, which may have already done
their damage?  If those assumptions I'm making are wrong, then I would
agree that it's more of a clever hack than a practical tool.

-Dan



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org