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 | Blog | 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



It works better in conjunction with other tools. Let's say you use Nagios
to monitor things. Something bad starts to happen, and it may be five
minutes before Nagios detects it. A lot of damage can be done in five
minutes. And if you're using email alerts, you might not see the alert
immediately if you're away from your computer when it arrives. And
Nagios typically waits a couple hours between alerts.

With Peep, the change in the sounds alerts you immediately that
something unusual is happening, and can start investigating immediately.
Even if you can't instantly recognize the exact problem, you're still
alerted that a problem exists, and if it takes more than five minutes to
figure it out, at least you're already primed to catch the Nagios alerts
as soon as they arrive.


On Fri, Jan 20, 2012 at 3:33 PM, Daniel C. <dcrookston at gmail.com> wrote:
> 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
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss



-- 
John Abreau / Executive Director, Boston Linux & Unix
OLD GnuPG KeyID: D5C7B5D9 / Email: abreauj at gmail.com
OLD GnuPG FP: 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99
2011 PGP KeyID: 32A492D8 / Email: abreauj at gmail.com
2011 PGP FP: 7834 AEC2 EFA3 565C A4B6 ?9BA4 0ACB AD85 32A4 92D8



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