[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[microsound] traffic analysis
Great links! And a "digital wind chime" is a perfect way to phrase
what I'm aiming at, music from the ether winds.
The Ping Melody is an interesting project as it combines a live
performance with the variances of network traffic. The second project
is probably closer to what I have in mind right now, although it´s
difficult to figure out exactly what they´re doing to "pluck the
network" - Both projects seem to be using pings (icmp) as the only
variable of the traffic.
> - what are you using for packet sniffing? tcpdump, snort, etc?
I have an "invisible" Linux bridge/IDS, so all traffic on this network
is piped through this box. On here I then have Snort - logging to
a MySQL database. Currently this is simply an IDS used for security
and general analysis.
Snort seems perfect for a project like this because it can parse the
traffic and create output based on whatever you wish to implement
(by writing your own 'rules'). So different types of traffic can
easily be converted into a useful format.
For example, if I wanted to create a different chime sound for each
server/workstation, then perhaps a different pitch for each chime reflecting
the type of traffic (email, web, dns, ping, etc...) I would write
a snort rule that would create output based on this...
alert tcp SERVERx 21 -> any any (msg:"chime.01")
(basically, if SERVERx is using FTP then sound = chime.01.mp3)
alert tcp SERVERx 80 -> any any (msg:"chime.14")
(if SERVERx is surfing the web, then sound = chime.14.mp3)
With this method you have access to a huge range of variables... You can
set a different sound for when each machine contacts any other
(so already for me that's 900 (30 x 30) possibilities):
alert tcp SERVERx any -> SERVERy any (msg:"chime.xy") or
alert tcp SERVER33 any -> WORKSTATION91 any (msg:"chime.3391")
- before even plugging in any variation based on the class of traffic.
Instead of using MySQL for this, I would make it simple: log all events,
or "alerts" to a text file (default is "alert.ids" - which would just look like a
long list of the alerts above). But this could just as easily
be directed to a database or dumped into your chosen delimited format.
The challenge I'm facing is finding the best method of converting this
output into sound.
The simplest interpretation might be to have a single script grep/cat the results
and simply play the associated sound through a command line tool (on linux: "play").
(Search File / Find Pattern / Play sound / Loop)
Alternatively it would be easy enough to have a script parse the results
and create a simple sequence:
"chime311, chime14, chime22, chime71, chime102, silence, chime291"
This seems perhaps a more efficient and portable method - because you
could export this sequence to any other suitable program.
all in all I get the impression that it may sound very "serial" - which
might get boring. the challenge could be to implement enough variables in
both the captured alerts and associated samples/variations, so that you really
have an intricate result.
- - -
"Catting" tcpdump output and dropping the result into /dev/audio, as someone
suggested, would sorta work, but it seems you'd have no control over the types of
sounds used. Creating sounds from the raw dumps, like the sox.mp3 example,
doesn't really appeal to me either, as I'm not a massive fan of unmitigated noise
- it just seems too easy.
If I want to hear chimes, even voice or raindrop samples associated with the
results, it doesn't seem to be possible through these methods.
For me this is important, although this may separate me slightly from the true
.microsound approach : )
- - -
all of this can just as easily be run on windows (& OSx), there are suitable
versions of Snort and Windump available.
If you wanted to run this project without have access to the vast traffic of a
corporate network... there is still enough data with a standalone workstation
surfing the web (or sniffing the local café´s wifi network,) I suppose you just have
to be more creative with the variables available. Creating a series of "pings,"
traceroutes or the odd denial-of-service would give you a ton of useful material.
- - -
Finally, I swear, one other related project I want to look at in the future is to
create "Internet feedback" by hosting two ShoutCast streaming servers that are
tied simply looped into each other. One side would stream the input from the other,
which would do the same - no other source sounds. I'm not sure at all what would happen,
perhaps we'd break the Internet...
thanks for your feedback, sorry for the lengthy report!
- R