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 |
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 | |
We also thank MIT for the use of their facilities. |