#Qlikview I know I know, it took me forever to try the document analyzer

Needless to say, it is very cool!

http://qlikviewcookbook.com/download/document-analyzer/

#AlienVault Cool Brute Force Detection

So I have been pleased with AlienVault. It recently detected a ‘Brute Force’ attack. In reality it was a user account that had been disabled and Outlook was still trying to log in to it. All and all, very nifty stuff!

#AlienVault 5.0 install on ESXi 5.1.0

So after I finally got OSSEC working, I had kept running across references to AlienVault… well I finally realized AlienVault has OSSEC included as well as a number of other things… so figured I may as well attempt an install!

First off, AlienVault 5.0 does not seem to like the vmxnet3 drivers so I went back to the E1000

I will have to try http://bookmarklust.blogspot.com/2010/03/ossim-vmtools-and-you.html

This post explains how to install vmware tools on debian http://blog.rebelit.net/456

I was successful with installation and changing the NICS over to the vmxnet3 driver.

I want to just add one device, when I went to install the HIDS it was not easily apparent that you should click your node and then select the machine that drops down.

Gah, and you have to hit the ‘deploy’ button as well ;-)

I definitely like that Alien automagically deploys the HIDS and sets up the key, having to do it manually is a chore :)

Now I’m trying to figure out assets :)

This is a great overview!

http://linoxide.com/security/install-configure-alienvault-siem-ossim/

#OSSEC-VM 2.8.1 install on #ESX5.1i Notes 1

Need to hardcode an IP address

I just used the network config GUI

Install vmware tools

Do the stuffs here http://www.shellhacks.com/en/HowTo-Install-VMware-Tools-on-CentOS-RHEL

Installed this for grins so I can right click and check the checksums

http://code.kliu.org/hashcheck/

Ok, install the windows HIDS agent

Use putty to connect to the OSSEC vm, log in, and then execute /var/ossec/bin/manage_agents

Enter E to extract the agent key

–except it only let me in once… and now I think its denying me access :)

To fix (from http://www.ossec.net/?p=685)

OK I figured out what is going on. We ship the OSSEC virtual appliance with no default SSH keys in /etc/sshd/. When you attempt to login via SSH for the first time after booting the appliance, OSSEC rule 40101 will kick in which causes iptables to address the IP address from you are logging in, which is what you observed. The quick cure for this to do the following:

1. sudo iptables –flush
2. service iptables stop

After doing this you’ll be able to login again, because by this time default SSH keys have been created and iptables will remain disabled.

Ok, so back to running /var/ossec/bin/manage_agents

Press A to add agent, put in computer name and IP

Press E to extract a megga key

copy that into the windows agent

Q to quit, don’t forget to RESTART OSSEC

/var/ossec/bin/ossec-control restart

Save (windows agent)

Start agent.

Check logs, you are looking for Connected to the server

I’m reading more here about what to do next

https://blog.savoirfairelinux.com/wp-content/uploads/2014/03/SFL-ED01-OSSec-the-quick-and-dirty-way-140326-01.pdf

hmm I also was getting a bunch of logon logoff events so I followed this here

https://www.alienvault.com/forums/discussion/1058/ossec-collecting-too-many-windows-logon-events

You can modify the level for these rules to 0. In this way ossec will not generate an alert when one of these events come to sensor and ossim-agent will not process them.
The rules are in /var/ossec/rules/msauth/msauth_rules.xml file and you will need to restart ossec to apply this change. Although an update could be overwrite it.

#OSSEC-VM 2.8.1 install on #ESX5.1i second attempt SOLVED

Solution, bring up the VM in virtual box and then use vmware converter to bring it into ESXi

Update the VM using YUM and using the newest newest vmware converter.

So, running uname -r now gives me 2.6.32-504.16.2.el6.x86_64

VMware converter standalone is now 5.5.3

Choosing ‘To Basic’ and unchecking create optimized partition layout

In order to try this the GUI is hard to follow, you have to

  • On the Options page of the Conversion wizard, click Data to copy in the options list.
  • Click Advanced and select the Destination layout tab.
  • Select the volume that contains the root directory and click To basic.

Capture

Click there and then the ‘To Basic’ option becomes available

Then I was finally able to boot!

I did replace the E1000 NIC since it tends to PSOD vmware

—- Notes of various attempts below —

This time around I’m going to try firing it up in Virtual box and then use the vmware converter.

First step, run vmware converter as an admin.

I choose to not bring up the network automagically, hopefully I can avoid a second PSOD

Gahck

FAILED: An error occurred during the conversion: ‘ * got kernel major revision as ERROR:
kernel version has to be in format 2.6.*, version 2.6.32-504.1.3.el6.x86_64 is not supported (return code 1)’

time to hit the google

Ok that was vmware converter 5.1.0, now going to try 5.5.0 newer is better right?

Ok 5.5.0 converted successfully! Let’s see if it boots

gah, lot’s of no such device messages

So, a hint from here http://www.linuxquestions.org/questions/linux-newbie-8/won’t-mount-dev-root-on-sysroot-during-boot-907463/

In order to try this the GUI is hard to follow, you have to

  • On the Options page of the Conversion wizard, click Data to copy in the options list.
  • Click Advanced and select the Destination layout tab.
  • Select the volume that contains the root directory and click To basic.

Capture

Click there and then the ‘To Basic’ option becomes available

—-

Ok, now we get to have more fun!

Get yourself a rescue CD

mount –bind /proc /mnt/sysimage/proc
mount –bind /dev /mnt/sysimage/dev
mount –bind /sys /mnt/sysimage/sys
chroot /mnt/sysimage

For CentOS 6:

Create a backup copy of the current initramfs using the kernel version identified earlier:

cp -p /boot/initramfs-2.6.32-358.el6.x86_64.img /boot/initramfs-2.6.32-358.el6.x86_64.img.bak

Now create the initramfs for the current kernel using the specific kernel version we documented at the beginning:

dracut -f /boot/initramfs-2.6.32-358.el6.x86_64.img 2.6.32-358.el6.x86_64

Hmm still not much success, I’m going to try updating the VM using YUM and using the newest newest vmware converter.

So, running uname -r now gives me 2.6.32-504.16.2.el6.x86_64

VMware converter standalone is now 5.5.3

Choosing ‘To Basic’ and unchecking create optimized partition layout

OSSEC-VM 2.8.1 install on ESX5.1i Failed

— I actually managed to cause a PSOD, tread carefully

Unzip the OVA file

I got the error ” The OVF package requires unsupported hardware. Details: Line 522: Unsupported hardware family ‘virtualbox-2.2′. I did a search on the .ovf and removed

<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>

From this post http://www.ossec.net/?p=1160

– uncompress the ova file (with an unzip-like utility)
– modify the ovf file to reflect what’s been said by Daimonji
– recalculate the checksum of the ovf file and enter it in the mf file (you can use the FCIV tool if you’re under Windows : https://support.microsoft.com/fr-fr/kb/841290)
– Deploy this new OVF, ignoring any warning.

— Ok found even more explicit instructions here http://osdir.com/ml/ossec-list/2014-10/msg00188.html

  • Used 7zip to extract the .ova file from the .gz file.
  • Found this web site:   http://www.itsecurenet.com/virtualbox-ova-to-vsphere-ovf/
  • Downloaded the VMWare OVF Tool from VMWare
  • Installed the OVF Tool on my PC.
  • Ran the OVF Tool as command line:  ovftool.exe –lax <source.ova>  <destination.ovf> Do not forget the option –lax   There are TWO dashes in front of lax.
  • This converts the .ova file to multiple files that end in:   .ovf, .mf and –disk1.vmdk
  • Found this web site:  http://www.cnblogs.com/eshizhan/p/3332020.html
  • Open the .ovf file with an editor (notepad) and make the following changes:
  1. Change the line:  <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
  2. To:  <vssd:VirtualSystemType>vmx-07</vssd:VirtualSystemType>
  3. Change the line:  <OperatingSystemSection ovf:id=”80“>
  4. To:  <OperatingSystemSection ovf:id=”101“>
  • Download Microsoft Checksum Verify utility :  http://support.microsoft.com/kb/841290 (Need to check SHA1)
  • Install the Microsoft Checksum Verify utility.
  • Run this command line:  fciv.exe -sha1 <filename.ovf>
  1. Replace <filename.ovf> above with the name of the .ovf file you edited in step 7.
  • Edit the .mf file.  Take the SHA1 value calculated above and replace the SHA1 value in the .mf file for the .ovf entry (line 1)
  • Use vSphere to deploy the OVF.   Select the .ovf file.
  • DONE

So the OVFtool makes you accept a license… quite annoying and it complains about the following system identifier ‘RedHat_64′ which it maps to ‘Other <32-bit>’ also didn’t like the ‘virtualbox-2.2′ with an unsupported hardware family.

grrr…. for what ever reason I only got two files out of the .ova, oh well I just recreated a 64bit centos virtual machine and added the ossec-vm-2.8.1-disk1.vmdk

That was…. easy.

And then on boot it PSODed the whole kit and kaboodle… hmm this virtual machine is quite the pain

#Qlikview preceding Load versus resident Load wisdom of HIC

I would put any transformation or string operation or creation of a new field in a preceding Load, rather than in a resident Load. I.e. if possible – always choose preceding Load.

But there are some transformations you cannot do in a preceding Load, e.g anything that you want to do after a Crosstable Load or after a Join. For these I would use a resident Load.

From

https://community.qlik.com/blogs/qlikviewdesignblog/2013/03/04/preceding-load

Follow

Get every new post delivered to your Inbox.

Join 247 other followers