[microsound] traffic analysis

[COSTELLOE Richard <Richard.COSTELLOE@xxxxxxxxx>]

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