Jul 27, 2018

The Microsoft License Verification Process Scam

Oh man, oh man do I hate Microsoft! Not the software so much, I mean they do actually put out really good products. What I hate is their licensing rules, and how they make it so damned convoluted and confusing! On top of that, right after you've worked with your Microsoft Licensing re-seller to button up your licenses, you may periodically get contacted to participate in the Microsoft License Verification Process! Weeeeee!

I'm not sure what happened, but about two years ago was my first experience with this. We complied, and Microsoft came back and said we were out of compliance based on random changes they had made to their licensing since our last true-up with our re-seller, and we had to fork over about $30,000 that we didn't budget for to become compliant again.

To be fair, our previous re-sellers did give us some bad information about licenses, so after that audit we switched re-sellers.

Well, I just got picked again this year. In the 13 years I've worked in Information Technology, these last two years were the first time I'd ever seen this... And now I think I know why. It's basically a shady marketing tool!

I reached out to our new re-seller about this so called audit, and here is what they said:
We’ve run into this a lot recently and over the years. Their wording seems to hide the fact that you don’t have to do this. 
The emails starting with “v-“ are not Microsoft and they are not audits. They are voluntary, but the results are shared with Microsoft at which point you would be required to reconcile anything they find.  
If you want to do an engagement like this to assess your licensing, we can do it for you. We don’t share the results with Microsoft and just deliver them to you.
In their frequently asked questions, the people contacting me about this Microsoft Verification Process say this:


I asked my rep about that too and they said:
Man I don’t like that wording. “us” 
That v- in the email means that person doesn’t work for Microsoft, but is contracted. Microsoft allows this to happen, but it’s not really their employees. I see these all the time and we just ignore them unless you would like to do an engagement. 
Microsoft does audit occasionally, but this email is pretty threatening. Microsoft audits don’t come in email form, I’m 99% sure.
So long story short, if you are contacted about participating in a Microsoft License Verification and the people contacting you have a "v-" before their email address, you should ignore them and reach out to your re-seller instead. It's really just a ploy so Microsoft can increase their bottom line before your annual true-up!

Have you experienced one of these? Did you comply? Is my rep wrong? Let us know your story in the comments!


Jun 29, 2018

I've switched to Let's Encrypt for TLS encryption on my personal email server

Years ago I started using iRedmail for my personal email. I love it, and it's super easy to setup. Way back then I purchased a three year Comodo SSL certificate for it. Well that certificate expired, and it looks like none of the affordable SSL companies are offering three year certificates anymore... Bummer.

Oh, well. I figured why waste the money anyway when I could just get a free certificate from Let's Encrypt! The only issue I have with Let's Encrypt is that they only issue three month certificates. Apparently they think it's more secure that way. Here are the reasons they give from their blog:

  • They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.
  • They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenient than longer ones.

Well, they are right about one thing, the automated renewal process is pretty convenient. The only issue I had with it was that they recommend using Certbot for Linux based servers. When I followed this post (How To Secure Nginx with Let's Encrypt on Ubuntu 16.04) on how to install it, I got a bunch of errors and jacked up my Ubuntu based iRedmail server... (Thank God for backups!)

Anyway, there are much easier scripts and utilities around that can basically do the same thing. I opted for acme.sh! From their page:
  • An ACME protocol client written purely in Shell (Unix shell) language.
  • Full ACME protocol implementation.
  • Support ACME v1 and ACME v2
  • Support ACME v2 wildcard certs
  • Simple, powerful and very easy to use. You only need 3 minutes to learn it.
  • Bash, dash and sh compatible.
  • Simplest shell script for Let's Encrypt free certificate client.
  • Purely written in Shell with no dependencies on python or the official Let's Encrypt client.
  • Just one script to issue, renew and install your certificates automatically.
  • DOES NOT require root/sudoer access.
  • Docker friendly
  • IPv6 support
  • It's probably the easiest & smartest shell script to automatically issue & renew the free certificates from Let's Encrypt.
Installation was easy, and so was requesting my first certificate. A part of the install process is that it creates a cron job to automatically renew your certificates. The one modification I had to do was to create a script with the following to copy the new certs from the default location in the installer user's home directory to the directory where I keep my certificates and keys:

 #!/bin/bash  
 cd ~/.acme.sh/domainname.com/  
 yes | cp -rf *.cer /pathto/ssl/certs/  
 yes | cp -rf *.key /pathto/ssl/private/  
 service apache2 restart  
 service dovecot restart  
 service postfix restart  

After that, I created a cron job to run that script nightly since their renewal script runs twice a day. Boom, done! Now I shouldn't have to worry about SSL certificates on this server for a very long time, or until I built my next one.

Do you use Let's Encrypt on your servers? Do you like it? Why or why not? Let us know in the comments!

Jun 14, 2018

Script To Configure Your Azure Application Gateway For TLS 1.2 Only

If you are just reading this post, you are cutting things pretty close with PCI/DSS compliance! After all, you have until the end of the month to remove older versions of TLS to remain PCI compliant.

Well, if you are using Application Gateways in Azure to secure your web servers, you're in luck, because setting a custom SSL policy is pretty easy. You just have to do it via PowerShell.

Now, this script assumes you've already created your Application Gateway. If you are trying to configure one from scratch, you'll have to keep Googling my friend... Sorry.

Before you can run your script, you must first connect to Azure via PowerShell, and select your subscription.

  • Connect-AzureRmAccount
  • Select-AzureRmsubscription -SubscriptionName "<Subscription name>"

After that, you can copy and paste the below script to set your custom SSL policy. Be sure to replace the Application Gateway Name and the Resource Group Name to match your environment.

Here's the script:

 # get an application gateway resource  
 $gw= Get-AzureRmApplicationGateway -Name <Application Gateway Name> -ResourceGroup <Resource Group Name>  
 # set the SSL policy on the application gateway  
 Set-AzureRmApplicationGatewaySslPolicy -ApplicationGateway $gw -PolicyType Custom -MinProtocolVersion TLSv1_2 -CipherSuite "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256", "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA", "TLS_RSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_256_CBC_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA256"  
 # validate the SSL policy locally  
 Get-AzureRmApplicationGatewaySslPolicy -ApplicationGateway $gw  
 # update the gateway with validated SSL policy  
 Set-AzureRmApplicationGateway -ApplicationGateway $gw  

After that, your Application Gateway will only support TLS 1.2, and will use the following ciphers in order:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
Pretty easy right? Did this help you out? Let us know in the comments!

May 24, 2018

A faster and easier way to make LUN files for your SCST SAN

I've been writing a lot lately about SCST iSCSI SANs again. It's been a few years since I've had a chance to configure one of these from scratch, and a lot has changed since 2012 when I first started using these.

In the past I've always used dd to create LUN files for use with SCST. For thin provisioned LUNs I would run something like the following:
sudo dd if=/dev/zero of=lun1 bs=1 count=0 seek=1T
For thick provisioned LUNs I would run this instead:
 sudo sudo dd if=/dev/zero of=lun1 bs=1024 count=1T seek=1T
Well, I found two utilities that do the same thing, but they are way faster and the syntax is way easier! One is called fallocate and the other is called truncate!

To create a thick provisioned LUN, you would use fallocate to create your file by running:
sudo fallocate -l 1T lun1
To create a thin provisioned LUN, you would use truncate to create your file by running:
truncate -s 1T lun1
So simple right? Why am I just learning about this now!?

May 23, 2018

How to specify a thin provisioned LUN in SCST

The other day I wrote about how to install SCST 3.4.0 on Ubuntu 18.04. If you are not familiar with SCST, it is basically a SAN target software that you can run on Linux so you can build your own low cost SAN storage. I've been using it for years, and just recently I've started to learn a few new things about it.

For instance, I used to think that for thin provisioning, all you had to do was to create a thin provisioned disk file to present as a LUN. To do that you just run the following:
sudo dd if=/dev/zero of=lun1 bs=1 count=0 seek=1T
The above creates a thinly provisioned 1TB LUN file called lun1. Simple right?

Well, this is great and all, but if you want to use features like TRIM or UNMAP to reclaim disk space, you also need to tell SCST that this LUN file is a thin provisioned LUN. To do that, you need to add the thin_provisioned parameter to the device section of your /etc/scst.conf file. See below for an example:

 HANDLER vdisk_fileio {  
     DEVICE lun1 {  
         filename /data/lun1  
         nv_cache 1  
         thin_provisioned 1  
     }  
 }  
 TARGET_DRIVER iscsi {  
     enabled 1  
     TARGET iqn.2018-05.bauer-power.net:iscsi.lun1 {  
         enabled 1  
         rel_tgt_id 1  
         GROUP VMWARE {  
             LUN 0 lun1  
             INITIATOR iqn.2018-05.com.vmware1:8bfdfcd0  
         }  
     }         
 }  

After making this change, you can either restart the scst daemon, or reboot your SAN. If you can't reboot the SAN you will have to actually remove the LUN on the fly to make this change. To do that you have to do the following:
  • sudo scstadmin -rem_lun 0 -driver iscsi -target iqn.2018-05.bauer-power.net:iscsi.lun1 -group VMWARE
  • sudo scstadmin -close_dev lun1 -handler vdisk_fileio
  • sudo scstadmin -open_dev lun1 -handler vdisk_fileio -attributes filename=/data/lun1 thin_provisioned=1 
  • sudo scstadmin -add_lun 0 -driver iscsi -target iqn.2018-05.bauer-power.net:iscsi.lun1 -group VMWARE -device lun1
Obviously, you need to change the lun names, file names and target names to match your environment. Special thanks to Gilbert Standen from the Scst-devel mailing list for the above steps on making this change on the fly! Check out his blog here: (brandydandyoracle)

There are a lot of parameters you can add to your config file as well. Here's a list from SCST's Source Forge page:

  - filename - contains path and file name of the backend file.  
  - blocksize - contains block size used by this virtual device.  
  - write_through - contains status of write back caching of this virtual  
   device.  
  - read_only - contains read only status of this virtual device.  
  - o_direct - contains O_DIRECT status of this virtual device.  
  - nv_cache - contains NV_CACHE status of this virtual device.  
  - thin_provisioned - contains thin provisioning status of this virtual  
   device.  
  - removable - contains removable status of this virtual device.  
  - rotational - contains rotational status of this virtual device.  
  - size_mb - contains size of this virtual device in MB.  
  - t10_dev_id - contains and allows to set T10 vendor specific  
   identifier for Device Identification VPD page (0x83) of INQUIRY data.  
   By default VDISK handler always generates t10_dev_id for every new  
   created device at creation time based on the device name and  
   scst_vdisk_ID scst_vdisk.ko module parameter (see below).  
  - usn - contains the virtual device's serial number of INQUIRY data. It  
   is created at the device creation time based on the device name and  
   scst_vdisk_ID scst_vdisk.ko module parameter (see below).  
  - type - contains SCSI type of this virtual device.  
  - resync_size - write only attribute, which makes vdisk_fileio to  
   rescan size of the backend file. It is useful if you changed it, for  
   instance, if you resized it.  

Pretty cool right? Let us know what you think in the comments!

May 18, 2018

How to install SCST 3.4.0 in Ubuntu 18.04

Well crap. The other day I talked about how I re-configured one of my Bauer-Power iSCSI SANs using tgt. It was an easy setup, but once I started using it I noticed that tgt performed like shit. CPU's were spiking like crazy on the SAN itself, and when I was backing stuff up I couldn't access the drive on the backup server. It would get completely unresponsive!

I decided I had to go back to SCST. Luckily installing it is way easier than it used to be. To install version 3.4.0 now just do the following:
  • Create an empty working directory
 rm -rf ~/scst-build  
 mkdir ~/scst-build  
 cd ~/scst-build  
  • Install dependencies
 sudo apt install git devscripts equivs dkms 
 git clone -b ubuntu-3.4.x https://github.com/ubuntu-pkg/scst.git  
 cd scst  
 sudo mk-build-deps -i -r  
  • Build the package
 dpkg-buildpackage -b -uc  
  • Pre-install, create two directories (For some reason the deb packages don't do it...)
 sudo mkdir -p /var/lib/scst/pr  
 sudo mkdir -p /var/lib/scst/vdev_mode_pages  
  • Install
 sudo dpkg -i ../scst-dkms_*deb  
 sudo dpkg -i ../iscsi-scst_*.deb  
 sudo dpkg -i ../scstadmin_*deb  

Now you just have to configure your LUN using the instructions in my tgt post, and configure your /etc/scst.conf file using my old SCST post. Once those are done restart the scst service.

 sudo service scst restart  

Of course, if you don't want to mess with all of the above stuff, you could just download my pre-packaged scst 3.4.0 deb files for Ubuntu 18.04 and run my install script...

 cd ~  
 wget https://mail.bauer-power.net/drop/scst/scst-3.4.0-Ubuntu.tgz  
 tar -xzvf scst-3.4.0-Ubuntu.tgz  
 cd scst*  
 sudo chmod +x install.sh  
 sudo ./install.sh  

Boom! Now just setup your LUN and your /etc/scst.conf file and you're off to the races!

May 17, 2018

How to Re-IP An OSSEC Agent

At my day job we use OSSEC for host based intrusion detection. It works great! It does all sorts of things from verifying registry integrity, checking files for changes, reading security logs etc., and sends email alerts for anything out of the ordinary.

Well, we're in the process of migrating servers from on-premise to Azure, so that means that some of our servers are getting new IP addresses. Googling around, I didn't find a good way to re-IP the agents except to remove them, and re-add them. I didn't want to do that.

It turns out, there is an easier way. All you have to do is edit /var/ossec/etc/client.keys with your favorite text editor and modify the IP address of the client you want to change. If you don't want to deal with this in the future, you can replace the IP address with 'any' so that OSSEC will accept connections from that client as long as the hostname and the client key match.

After you make your change, restart the OSSEC daemon on your OSSEC server:
sudo service ossec restart
Re-run /var/ossec/bin/manage_agents and extract the key again for the agent you want to update. Then on the client, open OSSEC Agent Manager as an administrator, click Manage > Stop OSSEC, re-paste the key, click Save, then restart OSSEC by clicking Manage > Start OSSEC.

Boom! Done! You should now be able to connect using the new IP address or 'any'.



Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | stopping spam