Firstly, download the files here.
The static page for nsm-console is here.

I finally got around to releasing the next version of the nsm-console. This version incorporates a large amount of bug fixes and additional features, first, I’ll start with some of the features I’m the most happy about Most of these features are in the new Hex 1.0.2 release which came out yesterday (go download it now!)

• Categories
  • You can now toggle certain categories on and off, for instance, one category shipped with the new release is the ‘flow’ categories, you treat them just like a regular module. Simply use “toggle flow” to toggle the flow category (and all of it’s modules) on and off.
  • You can easily add your own categories to customize your work environment, all you have to do is create a file named the same name as the category name in the modules/categories directory.
• Directory analysis
  • When you normally run the nsm-console, you would specify a single pcap file to perform analysis on, now you can use the same “file” command to specify a directory full of files  instead of a single file. When the “run” command is executed, all the toggled module’s operations will be executed on each file in the directory (recursively)
  • To better accommodate this type of operation, I encourage anyone that is writing any modules to write them to output the results into an output file named something like ${PCAP_BASE}.tcpdstat.out (so if you had more than 1 file, the output will go into more than one file)
• The ‘exec’ command
  • I added the exec command because I was tired of spawning an additional shell in order to run a simple ‘tcpdump’. I hope this helps with the automation that I’m going to talk about below.

The directory functionality and the exec command isn’t in the current Hex release, but hopefully it will be in the next release.

Part of the reason I think nsm-console is neat is the ease of automation you can do using simple text files. For instance, if you created a text file called “automate.txt” and put the following lines in it:

file /pcap/data.pcap
output automated-output
toggle aimsnarf
toggle tcpdstat
toggle chaosreader
run
quit

Then, you can run the command:

./nsm < automate.txt > output.txt

Which will run all the commands in the text file automatically, placing all the output in output.txt, simple eh?

If you have any questions, comments or suggestions, feel free to leave a comment or send an email I’d love to hear if/how you’re using nsm-console

Return with me, for a moment, back to the computational hardware class you took in college (if you did take one, don’t worry if you didn’t). Do you remember discussing program/memory flow? How about locality of reference for RAM access? Well, I wanted to discuss a few ideas about locality of reference in regards to network security.

First off, let’s define the different kinds of locality of reference, first there is temporal locality, then spatial locality and finally sequential locality. Here are the quick-and-dirty definitions:

Temporal locality states that when you access something, it is likely you will access the same thing again

Spatial locality states that when you access a particular piece of data, you are likely to access data near that piece in the future.

Sequential locality states that when you access a piece of data, you are likely to access nearby data in either an ascending or descending fashion.

So, what does this have to do with information security? (if anything) Well, I believe you can apply this kind of data collection methods to network traffic when looking at a whole network. For a simple example, take for instance 2 machines, each one one serving DNS records to clients on a network. In a typical example, a client would query one of the two machines (probably the first one, using the 2nd as backup if the first didn’t respond), retrieve it’s name record and be done with the connection right? How about in the case of something scanning the network for DNS servers as potential targets? You could expect to see both DNS servers queried within a short amount of time, by the same host. In this case, the person doing automated scanning exhibited symptoms of locality (in this case, spatial, although it could have been sequential depending on the IP assignments) when scanning for vulnerabilities.

How does this help us? Well, as we increase in our security monitoring, we may be able to gain an additional edge over scanning tools by classifying network traffic according to the locality of it’s flow. An nmap scan of an entire subnet (even just 1 port), for example, would be displaying sequential locality that would most likely not show up during legitimate use. An nmap scan of 1 host, all ports (let’s pretend nmap doesn’t randomize port scanning order) shows sequential locality as far as ports are concerned (which is also an example of determining wether it was automated or human scanning.

Each of the different kinds of locality you would expect to see in a different environment, in the case of temporal locality, if you had, say, a DHCP server, you would expect to see a small amount of temporal locality between hosts (for legitimate uses) since each host would only send out a DHCP request if it either lost it’s current address (needed to renew), or was just joining the network for the first time. Seeing one host exhibit a great deal of DHCP temporal locality (say…requesting a DHCP license 50 times in 1 minute), should trigger an alarm.

Another thing this can help us determine is whether it is a real-live person generating this traffic, or an automated tool. Example:

A live person is gathering data about auditing a network, they decide to start with DNS servers, they gather a list of DNS servers, then manually gather information about each server by attempting to log in, grabbing banners, etc.

An automated tool scans a subnet, noting any DNS servers it finds, it then (sequentially), attempts to gather information from each server the same exact way. It makes no distinction between different kinds of DNS servers, etc, the network traffic sent is the same for each server.

A sensor, capturing this traffic, looks at the traffic sent by the live person, sees the lack of a sequential scan packets against DNS servers, the direct approach (“I know what information I’m gathering and how to gather it directly without resorting to a scan”) and notes the lack of sequential and temporal locality.

The same sensor looks at the traffic sent by the automated tool, sees the network flow example of sequential locality (scanning a subnet, incrementing IPs by 1) and temporal locality (since many automated tools query the same server multiple times). It also compares the traffic sent to each of the different DNS servers (was the exact same query sent each time?) and from that, determines the amount of locality exceeds the threshold to classify it as an automated scan/attack.

Unfortunately, I don’t have any kind of tool to do this kind of analysis right now, I also don’t know of any tool that specifically handles looking at data with locality of reference in mind. Think about your network, what servers do you have where temporal locality would be expected? Now what kind of locality would you NOT expect to see against the same machine, website crawling? Port traversal? What locality differences would you expect to see in a human vs. automated usage of your network? How about applying it at a filesystem level, expecting to see sequential file access for a group of files?

I certainly don’t claim to be an expert in locality of reference (or NSM, for that matter), but I was curious if anyone has come across anything else like this. If you have, leave me a comment with a link to a paper or article about it, I’m very interested in reading more about it. I would appreciate it

I’ve been trying to get this compiled for 2 days now, finally found out how to do it. Figured I’d share for everyone else.

If you try this without making the change to the configure file it will complain about you not having support for pthreads, so here’s what you do:

Open the configure script, search for the line that say something like "$OS" != "MACOSX", you need to change this line to say "$OS" != "DARWIN", voila!
./configure && make && make install away! Enjoy ettercap!

Now if I could only get dsniff working as well… :-/

Enable IPv6 on *most* Cisco switches (I used a 3750):
1. Telnet to the switch
2. Use “enable” to escalate privledges
3. configure terminal
4. sdm prefer dual-ipv4-and-ipv6 routing
5. end
6. reload (this will reboot the switch)

If you need to make sure it’s set correctly, telnet into the switch, enable and then run “show sdm prefer” and verify that it’s running ipv4-and-ipv6.

Enabling IPv6 on Solaris:
1. touch /etc/hostname6.<interfacename>
<interfacename> is the name of the hardware interface, something like ce0 or e1000g0, etc.

Enabling IPv6 on RedHat Linux
1. system-config-network, select the interface, edit the properties and check the box that says “Enable IPv6 on this interface”

Enabling IPv6 on Windows
1. ipv6 install at a command prompt.

You can test it using ping on Solaris and ping6 on Linux and Windows. Good luck!

Okay, after reading Himanshu Dwivedi’s presentation[PDF] on iSCSI security (insecure-SCSI hur hur hur) I decided to try and replicate one of the attacks that he mentioned in the presentation. Following is how I managed to get the data shown of a different machine.

Firstly, I needed to get the initiatorname for the iscsi daemon on the target host. In this case the /etc/initiatorname.iscsi file is -rw-------, so I needed a way to find out the initiator name without root privileges. In this case I used wireshark (used to be ethereal) to sniff the traffic for a plain-text initiator name. Okay, so here’s what I did:

Fire up Wireshark (Ethereal) and set it to promiscuous mode, with a filter for port 3260 (the iscsid port), feel free to filter by host, etc. Run the live capture for a while, what you’re going to be looking for is a sequence of packets that look more like this:
…
iSCSI Login Command
TCP [PSH,ACK] <other information>
TCP [ACK] <other information>
iSCSI Login Response (Success)
…
I can’t say how long it’s going to take this, but it’s much easier to get when the iscsi service is being started on the machine you’re trying to sniff, therefore, if you can sniff while a machine is coming online from a reboot you will most likely have a much better chance of detecting this.

There’s another easier way of getting what you want just doing a string search. Search for the string “Initiator” below you can see a picture what you should be looking for in Wireshark:

Note the highlighted text at the bottom, this is what you’re looking for. Copied straight out you get something like this:
`
7LrEN@@
By"p/
InitiatorName=iqn.1987-05.com.cisco:01.87956e84f925InitiatorAlias=lava2163SessionType=DiscoveryHeaderDigest=NoneDataDigest=NoneMaxRecvDataSegmentLength=8192DefaultTime2Wait=0DefaultTime2Retain=0IFMarker=NoOFMarker=NoErrorRecoveryLevel=0X-com.cisco.PingTimeout=5X-com.cisco.sendAsyncText=YesX-com.cisco.protocol=draft20

All we really care about in that text is the part that is bolded, using this, we can manually set the /etc/initiatorname.iscsi file on a different Linux server to have the line “InitiatorName=iqn.1987-05.com.cisco:01.87956e84f925“. Don’t forget to change the /etc/iscsi.conf file to have the following line in it:
DiscoveryAddress=<ip of iscsi target host>
Fill in the host with the IP address that your sniffing showed (in this case, it was 10.5.140.229 as you can see in the picture)

After this step, if this were a real attack it would probably be a good idea to preform a DOS attack on the original target to knock it out of connection with the server (you don’t really want 2 hosts attempting to get the same information from an iSCSI target). Then start the iscsi daemon with “/etc/init.d/iscsi start” and you should be seeing the data originally meant for the other host.

This is really a simple attack and barely requires any technical knowledge of iSCSI to exploit it. It’s nothing special, but it does show that you really need to implement some kind of security in your network (CHAP or whatever else suits you).

What kind of security do you use for iSCSI? CHAP? None? Leave a comment and let me know!

EDIT: Blog O’Matty has an article on the Solaris iSCSI stack in the August issue of SysAdmin magazine if you’re interested. I find his articles to be very insightful and I highly recommend checking out some of the other ones at prefetch.net. Check it out!