• Snort module with community rules
  • self-contained snort module will all the community rules and configuration file, this’ll generate alerts into a file after reading the pcap file. I wasn’t sure whether to use community or bleeding edge rules, it’s still easy to point the snort module to your own snort.conf file and do it that way.
• Exec command will do substitution now on the following variables:
  • ${PCAP_FILE}
  • ${PCAP_BASE}
  • ${MODULE_DIR}
  • ${OUTPUT_DIR}
  • This’ll let you do something like “exec tcpdump -X -n -r ${PCAP_FILE}“
  • In addition, exec now logs all the commands run into the regular logfile
• The ‘logfile’ command, real simple, just specifies a new logfile
• Whitespace is handled much much better, there were a lot of bugs with whitespace being handled correctly for the “set” command (among others), it should be handled much better now.
• Category loading now handles non-files much better, before, if you left a “CVS” directory in the categories folder, it would read it but when it went to do a “toggle all”, it would error out, this has been fixed.
• Lots of bugfixes

You can grab the new version here:

http://writequit.org/projects/nsm-console/files/nsm-console-0.3-DEVEL.tar.gz

It’s definitely stable enough for daily use, highly recommended over the older versions. I’m still hoping to get cvs-web interface up to be able to browse the code.

• About the author
• Aimsnarf
• NSM-Console

Hopefully this makes it easier to link to a particular project. Take a look and let me know if you find anything missing! I’m hoping to add a link for packages I’ve created soon also!

Also, I’m contemplating future posts, are there any requests for particular posts on a certain topic? More ZFS posts? More security tool posts? More how-to posts? Leave me a comment and let me know!

Download the script here.

Read about aimsnarf in the previous post about it.

Changes in this version:

• Trillian is now supported, as well as AOL’s AIM client. Most other clients should be supported too, I figured out the variable length/number of TLV fields in the packet, so aimsnarf is much smarter about decoding them
• Code cleaned up to be more readable
• Fixed some misc messages that were showing up, you still might see a few

Todos:

• Figure out what the heck iChat is doing, it doesn’t seem to be sending the same kind of data as all the other AIM clients
• Still do OTR stuff
• Maybe add support for different protocols?
• More testing!

If you find any bugs, send me a note or leave a comment. If you really want to help, you can send me some pcap data to analyze   If you have any feature requests, lemme know!

I started out writing the script in Perl, which at this point is the scripting language I know the best, I then decided that now is as good a time as any to learn Ruby (which I’ve been interested in for a while now), so I re-wrote the entire program in Ruby (first *useful* script I’ve actually written in Ruby). Then, one day at work I was told that I needed to extend the program to support 5000 simultaneous threads doing disk I/O. I thought about this for a while and (after talking with my friend Jon about it) decided on using Java, as the threading was much more robust (something I had problems with using Ruby and Perl). Well, I’ve got working versions of all 3 programs and I thought I’d share my perspective on the pro’s and con’s of each one:

Java pro’s:

• Most robust thread implementation of the 3 languages
• Handles SMP much better than ruby
• Code is portable with minimum requirements to run
• OO language (a bigger pro to actual developers who this matters more to)

Java con’s:

• JVM overhead (not really that much nowadays)
• More difficult to read due to Java’s extreme verbosity
• Requires jdk 1.5+ (1.4 is still the only actual “supported” JDK in my company)

Ruby pro’s:

• Most readable code of all 3 (shortest too)
• I got to learn Ruby
• Ruby implementation available for most platforms
• More OO than Perl (not that I used OO…)

Ruby con’s:

• Ruby only took advantage of 1 of my CPU cores (Java used both)
• Ruby is slower than Perl (maybe one day they’ll be just as fast?)
• Almost no one in my department has heard of Ruby

Perl pro’s:

• Super-easy to install with ActiveState for windows, comes default with most *nix
• Super-easy to install the required module: perl -MCPAN -e shell ; install File::Random
• Allows fine-grain tuning of thread parameters (adjustable thread stack size)

Perl con’s:

• If you don’t have threaded perl, gotta reinstall (/cry @ Solaris)
• Least readable code (unless you loooovvve punctuation)
• Perl doesn’t like me spawning millions of threads and detaching all of them

Overall, since I need code that’s portable to multiple platforms easily, while allowing for very large amounts of IO, I’ll probably stick to the java version (which was renamed CIOSim [Customer I/O Simulator] because you actually pronounce it :P), followed by the Ruby version (so easy to write), and then the Perl version, which, actually has the largest amount of features.

I haven’t written all the features into each version yet (except for the Perl one), but, if you’d like to take a look at them, here they are:

Java version
Ruby version
Perl version

Next tool I need to write, I’ll probably be looking at Ruby

Anyone out there use anything different for sysadmin tools? Python? Lisp? Assembler? Leave a comment and let me know