Justin's IT and Security Pages

Archive for October, 2010

Flower NFA Update

leave a comment

I’ve made some significant updates both to the Flower Visualization Server and to the supporting Analysis Server:

  • Visualization Server
    1. I implemented changes necessary to support the additional resolutions noted in the Analysis Server section. This is transparent to the end-user (the proper resolution is automatically selected).
    2. New dialog boxes were added to support AD configuration.
      Active Directory Configuration

      Active Directory Configuration

    3. Many, minor aesthetic changes were made to the Network Map output.
      Network Map

      Network Map

    4. Fonts (@font-face) are used more consistently throughout the workings of the console.
    5. The most significant recent changes to the Visualization Server are in the area chart output:
      Volume Chart

      Volume Chart


      I changed the chart from arithmetic to logarithmic because I found that my UDP data was being pushed down to 1 pixel as it was tremendously outweighed by the TCP data. Horizontal scale lines were added to illustrate the fact that the bottom of the graph represents an amount of data many orders of magnitude less than the top of the graph. I also wrote code to insert vertical lines at the beginning of each hour, day and month to better make sense of the data. Here is a 30-day graph shown within it’s containing window (data older than a few days is not pictured because I had to reset the database when I implemented the resolution concept):
      Volume Window

      30 Days

  • Analysis Server
    1. In line with the changes I noted in my last update to how statistical flow data is stored, I’ve introduced multiple levels of summarization to greatly decrease the time it takes to complete queries for longer time durations. The levels are configurable, but presently data is stored in 10 second, 1000 second, and 10000 second resolutions.

      To put that in to perspective, at a resolution of 10 seconds, a query for 30 days worth of data would need to scroll through 259,200 records. That same query would need to traverse only 2,592 records at a 1,000 second resolution and only 260 records at a 10,000 second resolution.

    2. I updated the chart data generation code to take advantage of the new resolution levels. Network maps represent data within a time period with little regard for how that data is distributed, so we can use a very low resolution and access the data very quickly.

      Area charts are more sensitive to how data is distributed throughout a time period and I’ve updated the code to dynamically select a resolution based on the width (in pixels) of the ultimate output and the time period selected. For example, a chart that is 600 pixels wide wouldn’t be well supported by a 30 day query split into 260 intervals. The Analysis server would select a 1,000 second resolution (2,592 intervals) to provide an adequate level of granularity with an optimal query structure.

    3. Microsoft Active Directory (AD) may now be used as an authentication and authorization source with minimal configuration. I’ve implemented code that interfaces with AD servers using LDAP/S (or optionally, and highly discouraged, over LDAP). AD servers are identified automatically by leveraging SRV records provided by the DNS server used by the Analysis Server.

      To enable this capability, an administrator need only specify the fully-qualified domain name of the forest root (e.g., “internal.company.com”) and the group(s) to authenticate against. Each group can be specified as “privileged” to permit management of the Flower systems themselves.

      No AD user data is stored within the Flower systems and all communication occurs over SSL (unencrypted authentication may be selected, but that option is not exposed yet and would be highly dangerous if not handled properly). Importing the SSL certificate from AD into the GlassFish server is a little tricky, and I’ll write up a wiki entry for that soon. Java is very particular about working only with trusted certificates. It is, of course, essential that it be so.

  • Overall Updates
    • The whole system may be configured to use SSL (from Visualization to Analysis and from Analysis to Active Directory). I have had great success using StartSSL’s free certificates.
    • Both the Visualization and Analysis servers may (should!) be installed behind an Apache server. I prefer this because it permits me to use Apache for SSL and mod_security. I’ve found that mod_proxy works best for the Visualization server and mod_jk works best for the Analysis server (mod_proxy with Analysis causes the WSDL files to be generated with “localhost” as the destination and mod_jk seemed unstable with the Visualization server).

    To try all of this out for yourself, download, compile and install the Analysis Server from the GitHub repository and head over to http://app.jdthomas.net and log in to your new Flower Network Flow Analysis system.

Written by justin

October 7th, 2010 at 10:00 pm

Posted in flower,programming

OpenIndiana and XenServer

27 comments

Now that OpenSolaris is officially dead and the drama has died down a bit, I thought it might be time to figure out how to install OpenIndiana on my XenServer. I’ve heard some say that you can’t install the new distribution on Xen as a domU, but that is demonstrably incorrect (although as I understand it, dom0 is presently out of the question due to Oracle pulling out the relevant xVM bits).

Installing OpenIndiana 147 on XenServer 5.5 is nearly identical to installing OpenSolaris on the same (as would be expected considering OpenIndiana’s roots).

  1. Create a new VM using the “Other Install Media” profile within XenCenter. Set up the VM with 10GB of disk space and 1GB of RAM.
  2. Copy the /platform/i86xpv/kernel/amd64/unix and /platform/i86pc/amd64/boot_archive files from the OI install disk over to the XenServer host.
  3. On the XenServer, determine the UUID of the newly created OpenIndiana VM using xe vm-list; just note the first 3 or 4 characters and tab completion will enter the rest when necessary.
  4. Configure the following parameters:
    1. xe vm-param-set uuid=<vm uuid> PV-kernel=<full path to the 'unix' file on the XenServer>
    2. xe vm-param-set uuid=<vm uuid> PV-ramdisk=<full path to the 'boot_archive' file on the XenServer>
    3. xe vm-param-set uuid=<vm uuid> PV-args='/platform/i86xpv/kernel/amd64/unix -B console=ttya'
    4. xe vm-param-set uuid=<vm uuid> HVM-boot-policy=
    5. xe vm-param-set uuid=<vm uuid> PV-bootloader=
  5. Mount the OpenIndiana install CD in the appropriate drive (e.g., select the correct ISO in XenCenter)
  6. Boot the OpenIndiana VM. Log in as jack/jack when appropriate to do so.
  7. Configure basic networking if needed; my Windows 2008 DHCP server never works to assign addresses to OpenSolaris/OpenIndiana (for whatever reason) so this is generally a mandatory step.
  8. Connect to the OpenIndiana server with an SSH client with X-tunneling enabled using the jack/jack account.
  9. Execute: pfexec /usr/bin/gui-install. The graphical install process will begin. Complete the steps as requested.
  10. After the installation is completed (and before rebooting), change the PV-args on the XenServer to: xe vm-param-set uuid=<vm uuid> PV-args='/platform/i86xpv/kernel/amd64/unix -B console=ttya,zfs-bootfs=rpool/ROOT/openindiana,bootpath="/xpvd/xdf@51728:a"'. Note the two changes from the OpenSolaris instructions from an earlier blog post: the zfs-bootfs is openindiana, not opensolaris and the bootpath is 51728 instead of 51712. I have no idea why the latter change is necessary – I just know that there was no 51712 in my devices directory, only 51728 and a 51760.

Reboot, and you’re good to go! Remember to run bootadm update-archive after the first boot (and anytime you make changes that require that file to be updated) and copy out the updated /platform/i86pc/amd64/boot_archive to the XenServer before rebooting.

Here’s a screenshot; note that I don’t know what’s up with the savecore error. Considering the unstable nature of the code, those sorts of hiccoughs don’t surprise me.

OpenIndiana on XenServer

Written by justin

October 1st, 2010 at 7:47 pm

Posted in infrastructure