Argus 3: German Article

My friend Stefan has sent me this link about argus 3 but it is in German language, so I think it's good to share with others. You can click the link here -

- The Argus-eye watches(German)

Thanks to Google Translator, you can view the english version here -

- The Argus-eye watches(English)

Basically the article demonstrates the usages of argus client tools, and gives brief explanation about them, the article is written by Ralf Spenneberg and it should be good read for people who just started to adapt to argus 3.

Cheers ;]

Argus 3: Statistics for Major Protocols

Most people would like to have macro view of the network, for example how many bytes have been utilized for protocol such as tcp, udp and icmp, or other things like the amount of packets that have been transmitted or received.

Previously in argus 2.x, argus offers racount -ar to generate the general statistics but the option -a is gone in argus 3.x, so how can you generate the network utilization for major protocols? I have shown the usage of racluster previously here for network session reconstruction and now I will demonstrate another example of using racluster.

Before I move on, I would like to rephrase racluster's functions from the man page -

Racluster reads argus data from an argus-data source, and clusters/merges the records based on the flow key criteria specified either on the command line, or in a racluster configuration file, and outputs a valid argus-stream. This tool is primarily used for data mining, data management and report generation.

Here you go, you can cluster or merge the records based on the flow key and it is suitable for data mining, data management and report generation, let's generate the statistical report using protocol as flow key. Notice I specify -m proto in command line below and using -s to print the field I want -

shell>racluster -L0 -m proto -r data.arg3 -s proto trans pkts bytes appbytes -\
tcp or udp or icmp
Proto Trans TotPkts TotBytes TotAppByte
udp 18115 72665 8488022 5430758
tcp 22996 1291078 969152661 895531494
icmp 1089 1933 424733 346837

This is something simple from racluster but you maybe scratching your head to figure how to do it when you are still new with argus 3(in fact I did), it is considered one of the most powerful tool in argus 3 client suite and maybe sooner, I will talk more about it. Hopefully you find it helpful(hint, hint).

Enjoy (;])

Loopback header

For system and network adminstrator who put loopback interface for good use(local proxy and so forth), have you ever thought of looking at the network traffics that pass through it? I took a closer look at the packet capture lately and it looks interesting though on different OS platform. Here's the result that I get by capturing it from Ubuntu linux box -

shell>sudo tcpdump -c 1 -XXttttnni lo
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
2008-01-28 15:39:37.190524 IP 127.0.0.1.55555 > 127.0.0.1.33108: P 1689457265:1689461100(3835) ack 1687382572 win 283
0x0000: 0000 0000 0000 0000 0000 0000 0800 4500 ..............E.
0x0010: 0f2f 9c2f 4000 4006 9197 7f00 0001 7f00 ././@.@.........
0x0020: 0001 d903 8154 64b3 1271 6493 6a2c 8018 .....Td..qd.j,..
0x0030: 011b 0d24 0000 0101 080a 01ef 6ceb 01ef ...$........l...
0x0040: 6c47 e938 36b7 4cc3 c0dd d673 2e3a cc65 lG.86.L....s.:.e
0x0050: c257 5cd0 7a0f dc7a d2d7 066d eee3 deb8 .W\.z..z...m....

lo is the loopback interface on my Ubuntu box, and you may notice the link type is ethernet which is 14 bytes.

0000 0000 0000 0000 0000 0000 0800

Since there's no source and destination mac address for loopback interface, they are just padded with 0000 0000 0000 0000 0000 0000(12 bytes) and with another 2 bytes(0800) as next layer protocol) so total up 14 bytes. I think that way it is much easier to read and decode.

However when I capture the packet through the loopback interface on FreeBSD, I got this result -

shell>sudo tcpdump -c 1 -XXttttnni lo0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes
2008-01-28 15:40:50.695859 IP 127.0.0.1.65304 > 127.0.0.1.6343: UDP, length 304
0x0000: 0200 0000 4500 014c 73f0 0000 4011 07af ....E..Ls...@...
0x0010: 7f00 0001 7f00 0001 ff18 18c7 0138 7937 .............8y7
0x0020: 0000 0005 0000 0001 7f00 0001 0000 0000 ................
0x0030: 0000 2369 09e4 5558 0000 0002 0000 0001 ..#i..UX........
0x0040: 0000 0090 0000 0c8c 0000 0001 0000 0001 ................
0x0050: 0000 0000 0000 0000 0000 0001 3fff ffff ............?...

The loopback interface is lo0 and the link type is null? If you are familiar with IPv4 header(usually it starts with 45 if the header length is 20 bytes(no ip options enabled)). So you can identify that the loopback has the header of 4 bytes -

0200 0000

This tells us that the implementation of both operating system for loopback interface are different. I'm wondering if other packet analysis tools will have problem parsing the packets that are captured from FreeBSD loopback interface. I haven't taken look on other OS yet and maybe you can tell me more about this. Any thoughts?

Enjoy (;])

More tools

There are few interesting projects out there that looks interesting to me, here's the list -

- Netams

- Comixwall

- Network Forensic Search Engine

I haven't really tried them out except Network Forensic Search Engine(Net/Fse), to me Net/Fse is still in early stage where it is basically providing the interface to allow you to search the collected netflow data with your preferred web browser when there's alert for certain network event, I think it is still in its infancies stage as their developers are keen on developing more supports for different kind of data. Net/Fse is using nfdump as back end engine to collect netflow data so it should scale well(I learn this from my past experience) however marketing wise, Net/Fse is smart enough to give its name(Network Forensic Search Engine) that maybe misleading, it is just allowing you to search through the historical netflow or syslog data. For the moment, you can just use nfsen to do the same thing, or better use sguil as you can query the session data that are collected by sancp instantly once you have any alert event. The only advantage of collecting netflow data is because it is built in for most of Cisco based routers and ISP should learn to love them. If you are GUI phobia, argus and silktools are best suited for the job as it has own set of analysis tools to perform in depth flow analysis using CLI.

I don't have much comment about Comixwall and Netams as I haven't tried them out, Comixwall is the firewall system based on OpenBSD, for more detail you can check out here. Netams is more of web based network traffic accounting and monitoring system based on collected netflow data. Maybe I will spend sometime to take closer look at them.

Otherwise, I'm toying with network graphing. There are two graphing toys you should take a look in case you haven't -

- Gnuplot

- Rrdtool

All for now, I'm still not into blogging mood but I will keep it up.

Cheers ;]

Hex from Errata Security

I follow Errata Security blog for quite sometime. Living in defensive security, you will still have to see what people with offensive security mindset can come out with. I just came across this post from Errata Security and it's about base 16 - Hexadecimal magic and the role of it in computer security. Personally I like this post a lot(not because it has the same name as our HeX system) but one of the reason why I give HeX system its name is because of its evil spell(curse) and the hex number where packet monkeys need to deal with. More details can be found here. On the other hand, I used to mention this in my training class - it's important to master hexadecimal when comes to dissecting protocol header(mind you, more importantly the application layer protocol).

I think hex is double edge sword, it plays important role for both offensive and defensive security, the blog post from Errata Security demonstrates the use of hex number with short but incredibly clear explanation and I hope you enjoy reading their post too.

By the way, me and spoonfork will conduct the network security training for HITB again. I hope we can deliver new analysis mechanism for network based forensics and again we wish to see you in HITB Dubai in coming April 2008!!!!!

Cheers (;])

Malaysia HoneyNet Project

Ok, I have to admit I'm being lazy to blog, I'm playing game(blame warcraft) and poking with argus 3 most of the time.

On the other hand, there's another project that quietly moving into main stream(we won't put HeX aside but currently it should be in honeymoon status due to the delay release of FreeBSD 7). The project is HornyD liveCD, chfl4gs_ is currently working on its base system, and hopefully the developer version will be released as soon as possible so whoever interested can work on it. Other than that, most of the things are ready, you can check out the official announcement here.

While we welcome anyone interested to join us, we encourage Malaysian(especially University/College students) because this is more of local project but so far except the core team members, we don't hear anything from local people yet.

Don't be horny, you will get trapped.

Cheers ;]

Tidbits for Packetysis

I have uploaded new tidbits here -

http://www.rawpacket.org/papers/geek00ls-junk

Those two are -

1. SANS: Christmas Packet Challenge
2. Cheatsheet: TCPdump VS Snoop

Most properly the first one is how I get to finish the SANS Christmas Packet Challenge and the second is the TCPdump VS Snoop cheat sheet as my own reference when I need to deal with Sun Operating System. Feel free to check it out if you like network packet analysis.

Enjoy (;])

NSM Console: Screencast

We are trying to prepare couple of screencasts for HeX demonstration, unfortunately December is really bad month for productivity but slacking.

For dakrone's dedication to HeX system, I would like to make my first post in 2008 about the tool he has written for HeX - NSM Console.

NSM Console is great to glue all the network packet analysis tools. Aside from that, it provides the unified interface to run all the analysis tools, the standardization command line can help you to easily adapt to most of the tools easily while it also provides you flexible environment to run the tool with its own arguments and options natively. There are many tools that offering same functionality but doing it in different way, in that case you can write the module to combine all of them and just execute the module in one shot to produce more trustworthy result you want(you don't believe in one tool, do you). To cut it short, NSM Console provides supportive environment for people who like to poke with network packets.

This time, dakrone has brought you the first screencast of his tool - NSM Console, more details can be found at -

http://thnetos.wordpress.com/2008/01/05/screencast-an-introduction-to-nsm-console/

Feel free to enjoy the screencast and comment, and email either me or dakrone if you are interested in NSM Console development.

Enjoy (;])