Installing AlienVault’s Open Source OSSIM to Azure

I have been testing a host of different tools as SIEMs, for Vuln Scanning etc. Paid and Free. I have come back to AlienVault numerous times and decided that for most cases, gaining a better security posture can start with the basics of scanning for vulnerabilities and building from there. For this post I have decided that I need an externally hosted box with enough grunt to work well to scan perimeter devices. Contracting a 3rd party in each time a port gets opened, or waiting for a yearly re-run of the vuln scan section of a pentest report is not a great way to react, and potentially leaves holes.

Having a self-service and inexpensive way to vuln scan the perimeter seems a no-brainer and AlienVault’s OSSIM is my favourite tool for this job.

Hope the below helps anybody in a similar situation or is just interested how to get something non-standard and non-templated up and running. I searched around for other guides and could only find old ones with the Classic Azure portal. This is ARM end-to-end and minimal requirement for PowerShell for those who love a GUI. Enjoy,

1)    Download the latest ISO –

2)    Install a Hyper-V Gen1 machine

a.    8GB RAM (use Dynamic if you have more RAM to throw at it –if you do use Dynamic ensure you disable Dynamic before you upload to Azure)

b.    12GB HDD is fine for now and makes it manageable; we’ll increase the size after it’s in Azure

3)    Setup the NIC for an external connection and set the IP, Mask and GW to the same that you will use in Azure when you power the machine on

4)    If you run a constant ping of the IP you’ll notice it briefly responds during the setup and then stops again (mine gave 6x wobbly replies then stopped)

5)    Install tends to hang at this stage; it’s a slow process so be patient 🙂

6)    Boot the new AV OSSIM machine; often if you have not given it enough RAM you will get some graphics corruption like the below; and ping will drop in and out. Sometimes just the graphics look bendy and you can press ALT-F1 to kick the session into life with a login prompt

7)    Give it more ram or ALT-F1 it and you’ll end up with a login prompt

8)    You can now browse the IP with HTTPs, it will prompt you to set name, location and a password, following that you will get the login prompt

9)    You can log in and have a play/dig around if required and run any updates (might not be enough space on the disk so you can wait until it’s in Azure if needed); or shut the machine down ready to upload

10) To shut the vm down cleanly open the HyperV manager and connect to the console; login as root and the password you chose at install and then choose shutdown from the list

11) In HyperV manager you will now need to convert the disk to VHD and Fixed Disk size ready for upload to Azure; right click the vm in the management console, select Edit Disk from the Action window, choose the option to convert to VHD and then Disk Type of Fixed Disk

12) Next we create the Azure Storage group

Set the various options you require in terms of redundancy, account kind can be left as (general v1)

13) There are several ways to upload the VHD, you can upload in the Azure portal, via PowerShell or a 3rd party tool eg CloudXplorer; below I’m using CloudXplorer

14) In the Azure portal find the Storage account you created above, open Settings – Access Keys

15) In CloudXplorer click Accounts and create a New account ‘Azure Blobs Account’

16) Use the Storage account name and the Key1

17) Create a new Container (eg, called vhds)

18) Open the container upload the vhd as a ‘page blob’ file when prompted

19) Once the upload completes you’ll see the vhd listed in the container and you can also see it in the Azure Portal. You will now want to right click and expand the disk to be more than 12GB. If you are using it just a vuln scaner then 50GB-100GB will be more than enough, if you want to use it as a SIEM then expand accordingly.

20) Next we create the virtual network; make the Address space and Address range match the subnet you used when originally installing OSSIM onto Hyper-V at the beginning of the tutorial

21) Under ‘More Services’ type images and click ‘images’

22) If you have no images it shows as below; click Create Images

23) Open up the storage account and into the vhds folder create from above

24) Name it, use the existing Resource Group created earlier; set the OS type as Linux

25) Select the VHD

26) Now in the Image overview, click Create VM

27) You can now create a VM from the Image and set it’s name, the ‘user name’ here doesn’t mean anything, it users the default root/password that you set in the Hyper-V install. Set a username and a strong password (not used, but good habit!) and select the Resource Group

28) Choose machine size to suit (2cpu/8gb ram minimum for a useful instance)

29) Set the SSD or HDD depending on the machine type if it doesn’t match it shows a grey notice at the top until resolved to match

30) Set the Diagnostic Storage account to the correct one for azavossim – it tends to default to another/first if you have Azure stuff already

31) Enable auto-shutdown; can’t ever hurt to turn it off and save a bit of cash in case you forget to turn it off (you will forget! 🙂

32) Set a static IP on the public and private addresses; the private address must match what you have configured when you create the machine in Hyper-V

33) Check the boot diags on the VM

34) Keep trying via SSH and once it boots you can login with the original user/pass created in the Hyper-V machine and it will come up with the SSH based menu.

35) Next we need to open the Network Security Group (NSG) to allow HTTPS through to the OSSIM. In the Resource Group find the (eg) ‘avossim-nsg’

36)  Click on Inbound Security Rules; there is a default-ssh rule that you can edit and restrict only to your IP if you wish. Create a new rule “Add”, Source: change the dropdown to IP Addresses and enter your IP here. Destination Port is 443. Priority 1010 (doesn’t need to be, just conforms to the existing rules) and name it eg HTTPS. We could enable “Just In Time VM” access here; but that is another post entirely.

37) Now when you browse to the Public IP created above you will see the same logon prompt from the Hyper-V instance earlier – and it will only be accessible from your IP that was set; try accessing it from a mobile on 3G/4G and confirm it blocks you loading it

38) Now we need to increase the disk size from the original (eg) 12GB to match the size we expanded to in CloudXplorer, in my case 100GB.

39) SSH into the box, run a ‘screen’ session if you’re familiar with screen in case the SSH connection drops.

40) “df -h” shows the current size in a human readable format; its 12GB for me

41) Run “cfdisk” and delete all of the partitions (take a screen copy first for sanity 🙂

42) Create a New partition of the right size, taking into account the Swap and Extended partitions (370MB for me).

43) Before and After shots for me below; don’t forget to set the new one as Bootable, and set the correct Type for sda+sda5 when recreated. If you’re precious on space, play about until the purple row is consumed.

44) Run Resize2fs /dev/sda1 and it will expand your disk from the original 12GB up to the new size set. If you are running in a ‘screen’ session create another tab and run df -h and you’ll see the disk size increasing.

45) Be brave; and reboot – if everything has gone accordingly you’ll have a working OSSIM with bags of space to play with.

Thanks for following all the way to the end; I hope this has been useful!



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at

Up ↑

%d bloggers like this: