Examples

0

Nutanix Calm – a deeper look from an automation consultant perspective (Part 2)

This post will be the second post on Nutanix Calm and will build up on my first post which can be found here: http://www.vcoportal.de/2018/09/nutanix-calm-a-deeper-look-from-an-automation-consultant-perspective-part-1/ if you missed it.

 

In the last post we only created a virtual machine without any customization. In this post we will install additional packages and add an SSH Key for login to the VM.

Let’s go back to our previously created Blueprint. On the left site we have the tab “Package”. Choose this, give the Package a Name and use “Configure install”

 

What you will see is that beside the LinuxServer Icon a new Icon will open up. Here we choose “+ Task” to create some modifications during the VM build process.

 

On the left site you must configure some values. You provide a name, choose what you want to do (I want to execute a Shell Script), and take the Credentials you need to access the VM. In the script section you past your script (Linux Bash programming in my case) which you want to execute.

My script for example looks like this:


#!/bin/bash

cat <<'EOF' > /etc/resolv.conf

# Generated by NetworkManager

search vcoportal.de

nameserver 192.168.1.10

nameserver 192.168.1.20

EOF

yum -y update

yum -y install net-tools traceroute bind-utils

First, I declare my script as bash script (line 1). Then I change the DNS Server configuration (line 2 to 7) and update everything on my VM and then install some tools like dig, traceroute and so on for my virtual machine.

When you are finished, save the Blueprint and give it a try for a run.

In the Audit Section of the Application you can take a look at your installation and configuration. As you will see the new generated section InstallSoftware will also be there as point. You can see what the Output of the section is. When you click on the Small window in the market red rectangle you can pop up a bigger window with the output.

On the button you can also have a look at the created script.

In the next step we will insert an SSH Key. This key can be insert from the user wo execute the Blueprint. So, let’s go back to our Blueprint. Here we go the the “Service” Section from our Service. There we insert a Name for the Variable (in my case SSHKey) and a default value. It is important that you activate the “Runtime” checkbox. We want the SSHKey auf our user, not the default and so the user can insert “his” key.

 

When we are finished with the variable we add a “Task”. This task we use to insert the SSH Key into the authorized_keys field for a specific account (I am lacy so I use the root account. For security reason I would not recommend this in production….)

 

The script itself is also a Linux Bash script and easy.


#!/bin/bash

mkdir /root/.ssh

touch /root/.ssh/authorized_keys

echo "@@{SSHKey}@@" >> /root/.ssh/authorized_keys


 

In the first line we declare the script as a Linux Bash script. The second line create the necessary directory and the third line creates the file. In the last line we insert something in the create file……

Did you recommend the “@@{SSHKey}@@ in the last line? What’s that for a strange value?
In Calm variables which we use in script are market with “@@{VALUE}@@” so in our case that means we take the value of the before created Variable and replace the “@@{SSHKey}@@” field with the content.

One note why I used a new task and not placed the script in the first task we already did. From my point of view, I would recommend to create a new task for every goal which I want to reach. I personally thing that debugging is much easier in this case because we can see what went wrong (in which script). The next thing for me is, that even on script maybe doesn’t function like expected we still have the chance to access the VM and fix it during life time.

After we are done with our script, save the Blueprint and Launch the VM. When we are on the Blueprint just open the “Configuration” part and insert the SSH Key which you want to access the VM without password.

 

When everything works like expected you can login in your VM via SSH. If not, take a look in the Audit section.

As you can see the start with calm is very easy and there are a lot of things we can be done with calm.

During my “play around” with Calm I found some things which must be improved within Calm or limit Calm at the moment:

  • Calm is limited to Nutanix, vSphere-Cluster and Cloud Solutions. So, some customers still have to use a second solution for their automation need.
  • You cannot export created Blueprint and import them with all needed scripts, variables and images. With our easy Blueprint that is not a big issue but when you create a Blueprint with plenty of variables there is a “room” for mistakes and typos.
  • At the moment Calm has some limitations to work with for example ServiceNow and so on.

Some Ideas for Calm for future functions / extension:

  1. RFE: Blueprint Full Backup with images, scripts, cloudinit etc. à Provide a central repository in PC to make things re-usable: cloudinit, sysprep, scripts, images etc.
  1. RFE: DNS-Update Feature when VXLAN-DHCP from PE assigns IP-address à Autofill connection URL after application deployment (aka openshift) in the app description
  2. RFE: Integration of 3rd-Party config-mgmt tools like git, puppet, chef etc. in the GUI (dropdown menu, not via scripts) à Make existing scripts / tools / 3rd-party development re-useable
  3. RFE: Must-have: Native container integration to push CALM! No customer with an existing automation or configuration solution will switch to CALM without that feature.
  4. RFE: VM customization options with cloudinit for linux and sysprep for windows delivered as one-click/dropdown options in CALM (forgot that in the call)

 

If you can life with this limitations Calm is a good choice to start automation in your Nutanix environment.

0

VMware vSphere Autodeployment (virtuallyGhetto)

Did I already mention that I am a huge fan of the Autodeploy Script from William Lam? William created a bunch of script which help you to deploy a nested VMware environment in an automated way. The environment itself is built with a VSAN based datastore.

You can find the Blog Post from William here:

vGhetto Automated vSphere Lab Deployment for vSphere 6.0u2 & vSphere 6.5

 

and his GIT repository with the scripts here:

https://github.com/lamw

When you look at the Blog Post from William you can see that he uses a single ESX Hosts for his deployment. In case that you maybe have more ESX host there is a small issue in case that you have a VSAN based cluster. For the deployment of a nested VSAN environment on a VSAN bases Cluster you must set a VSAN Parameter (not recommended for production usage!). William makes these settings only for one host as you can see in this script


if($datastore.Type -eq "vsan") {
My-Logger "VSAN Datastore detected, enabling Fake SCSI Reservations ..."
Get-AdvancedSetting -Entity $vmhost -Name "VSAN.FakeSCSIReservations" | Set-AdvancedSetting -Value 1 -Confirm:$false | Out-File -Append -LiteralPath $verboseLogFile
}

 

In my environment a have a four node cluster hosts with HA and DRS configured. In some cases, DRS kicks-in during the enrollment of the nested environment. When a virtual ESX Hosts ends up on a Hosts were the settings was node made, the deployment fails.

In my case I made an improvement (for my usage) to the script where I configure the Fake SCSI settings for all Hosts of a cluster.

 

if($datastore.Type -eq "vsan") {
$FakeVSANhosts = $cluster | Get-VMHost | ForEach-Object {
My-Logger "VSAN Datastore detected, enabling Fake SCSI Reservations for Host $_ ..."
Get-AdvancedSetting -Entity $_ -Name "VSAN.FakeSCSIReservations" | Set-AdvancedSetting -Value 1 -Confirm:$false | Out-File -Append -LiteralPath $verboseLogFile
}

 

So, if someone of you runs into the same problem, just change the lines in the script from William and everything should work like expected.

0

VMware vCloud Director and Cassandra DB

In the last week I had a customer appointment where we made an update of the VMware vCloud Director installation to the vCD Version 9.1. For this update we had to make a couple of steps and also a migration of the used MS SQL Database. Everything went smooth to the new versions and then des customer decided that he wanted to use the VM Performance monitoring for the vCD Customers.
The installation and configuration is documented in the VMware vCD Docs (https://docs.vmware.com/en/vCloud-Director/9.1/com.vmware.vcloud.admin.doc/GUID-55D8360A-B4F9-4CDC-8BDA-972C4F387D74.html). So, we started with the installation of the Cassandra cluster and the configuration of the vCD. After everything was configured the customers chose the option to not provide all performance metrics to the customers. Therefore you can limit the metric collection (https://docs.vmware.com/en/vCloud-Director/9.1/com.vmware.vcloud.admin.doc/GUID-983C566A-7DE5-4F06-9044-C979F8AE7C99.html). We created the /tmp/metrics.groovy file with the required input:


configuration {
metric("cpu.usage.average")
metric("cpu.usagemhz.average")
metric("cpu.usage.maximum")
metric("disk.used.latest") {
currentInterval=300
historicInterval=300
entity="VM"
instance=""
minReportingInterval=1800
aggregator="AVERAGE"
}
}

And after that we imported everything and everything looked good.
After a last restart of a cell we ran into an error on the cell:


2018-08-23 15:00:05,027 | INFO | Cell Application | AbstractCellApplication | Application startup event: Application startup complete. |
2018-08-23 15:00:05,027 | DEBUG | Cell Application | LifecycleStateManager | Transition complete: com.vmware.vcloud.common.main.LegacyCellApplication@7bac686b transition from STOPPED to STARTED via STARTING_FROM_STOPPED |
2018-08-23 15:00:05,132 | INFO | OSGI Delegator - listener dispatcher | BootstrapApplication | Cell startup completed in 1m 35s |
2018-08-23 15:00:05,381 | DEBUG | Spring Context: com.vmware.vcloud.ui-vcloud-webapp | OsgiBundleSpringContextFactory | Finished constructing ApplicationContext for Bundle: com.vmware.vcloud.ui-vcloud-webapp in 3 seconds |
2018-08-23 15:00:58,666 | DEBUG | ell DiscoveryAgent listener: 484a81d5-738e-4c08-9f17-e013e8f98aab:Thread-94 | CellDiscoveryAgent | ADDING Cell to Broker Network. Cell UUID 810fe296-828e-4ead-8354-e9209f1ef044, Broker URI: tcp://172.16.6.105:61616 |
2018-08-23 15:00:58,802 | DEBUG | .105:61616@48618, localBroker= vm://484a81d5-738e-4c08-9f17-e013e8f98aab#16 | CellAuthenticatedBrokerFactory | Successfully authenticated user |
2018-08-23 15:01:53,538 | DEBUG | ActiveMQ Transport: tcp:///172.16.6.105:36820@61616 | CellAuthenticatedBrokerFactory | Successfully authenticated user |
2018-08-23 15:01:58,672 | DEBUG | ell DiscoveryAgent listener: 484a81d5-738e-4c08-9f17-e013e8f98aab:Thread-94 | CellDiscoveryAgent | ADDING Cell to Broker Network. Cell UUID 6bc3326d-df7b-4f37-8d59-cd76f7394d47, Broker URI: tcp://172.16.6.106:61616 |
2018-08-23 15:01:58,704 | DEBUG | .106:61616@34410, localBroker= vm://484a81d5-738e-4c08-9f17-e013e8f98aab#18 | CellAuthenticatedBrokerFactory | Successfully authenticated user |
2018-08-23 15:02:01,647 | DEBUG | ActiveMQ Transport: tcp:///172.16.6.106:59120@61616 | CellAuthenticatedBrokerFactory | Successfully authenticated user |
2018-08-23 17:53:02,838 | WARN | processor-NetworkingWeb | DatabaseConfiguration | Internal error |
java.sql.SQLException: SHUTDOWN ist in Bearbeitung.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:372)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2820)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2258)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:632)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:477)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatement.java:776)
at org.apache.commons.configuration.DatabaseConfiguration.getProperty(DatabaseConfiguration.java:177)
at com.vmware.vcloud.common.configuration.impl.CombinedConfiguration.getProperty(CombinedConfiguration.java:105)
at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1160)
at org.apache.commons.configuration.AbstractConfiguration.getInteger(AbstractConfiguration.java:831)
at org.apache.commons.configuration.AbstractConfiguration.getInt(AbstractConfiguration.java:806)
at com.vmware.vcloud.common.configuration.impl.ConfigurationServiceImpl.getInteger(ConfigurationServiceImpl.java:264)
at com.vmware.vcloud.common.configuration.impl.ConfigurationServiceImpl.getInteger(ConfigurationServiceImpl.java:282)
at com.vmware.vcloud.common.activity.dao.impl.ActivityQueueServiceImpl.claimWithCheckForExpectedExceptions(ActivityQueueServiceImpl.java:106)
at com.vmware.vcloud.common.activity.dao.impl.ActivityQueueServiceImpl.lambda$claimNextRunnableActivity$5(ActivityQueueServiceImpl.java:87)
at com.vmware.vcloud.common.retry.impl.HeartbeatAwareRetryingExecutorServiceImpl$WorkItem.run(HeartbeatAwareRetryingExecutorServiceImpl.java:240)
at com.vmware.vcloud.common.retry.impl.HeartbeatAwareRetryingExecutorServiceImpl.submitInner(HeartbeatAwareRetryingExecutorServiceImpl.java:517)
at com.vmware.vcloud.common.retry.impl.HeartbeatAwareRetryingExecutorServiceImpl.submit(HeartbeatAwareRetryingExecutorServiceImpl.java:455)
at com.vmware.vcloud.common.activity.dao.impl.AbstractActivityService.execute(AbstractActivityService.java:31)
at com.vmware.vcloud.common.activity.dao.impl.ActivityQueueServiceImpl.claimNextRunnableActivity(ActivityQueueServiceImpl.java:87)
at com.vmware.vcloud.activity.toolkit.queueing.DefaultActivityQueue.dequeue(DefaultActivityQueue.java:96)
at com.vmware.vcloud.activity.toolkit.queueing.DefaultActivityQueueProcessor.dequeueElement(DefaultActivityQueueProcessor.java:313)
at com.vmware.vcloud.activity.toolkit.queueing.DefaultActivityQueueProcessor.access$100(DefaultActivityQueueProcessor.java:54)
at com.vmware.vcloud.activity.toolkit.queueing.DefaultActivityQueueProcessor$1.run(DefaultActivityQueueProcessor.java:192)
2018-08-23 17:53:02,839 | WARN | processor-ValFabric | DatabaseConfiguration | Internal error |
java.sql.SQLException: SHUTDOWN ist in Bearbeitung.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:372)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2820)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2258)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:632)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:477)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatement.java:776)
at org.apache.commons.configuration.DatabaseConfiguration.getProperty(DatabaseConfiguration.java:177)
at com.vmware.vcloud.common.configuration.impl.CombinedConfiguration.getProperty(CombinedConfiguration.java:105)
at org.apache.commons.configuration.AbstractConfiguration.resolveContainerStore(AbstractConfiguration.java:1160)
at org.apache.commons.configuration.AbstractConfiguration.getInteger(AbstractConfiguration.java:831)
at org.apache.commons.configuration.AbstractConfiguration.getInt(AbstractConfiguration.java:806)
at com.vmware.vcloud.common.configuration.impl.ConfigurationServiceImpl.getInteger(ConfigurationServiceImpl.java:264)
at com.vmware.vcloud.common.configuration.impl.ConfigurationServiceImpl.getInteger(ConfigurationServiceImpl.java:282)
at com.vmware.vcloud.common.activity.dao.impl.ActivityQueueServiceImpl.claimWithCheckForExpectedExceptions(ActivityQueueServiceImpl.java:106)
at com.vmware.vcloud.common.activity.dao.impl.ActivityQueueServiceImpl.lambda$claimNextRunnableActivity$5(ActivityQueueServiceImpl.java:87)
at com.vmware.vcloud.common.retry.impl.HeartbeatAwareRetryingExecutorServiceImpl$WorkItem.run(HeartbeatAwareRetryingExecutorServiceImpl.java:240)
at com.vmware.vcloud.common.retry.impl.HeartbeatAwareRetryingExecutorServiceImpl.submitInner(HeartbeatAwareRetryingExecutorServiceImpl.java:517)
at com.vmware.vcloud.common.retry.impl.HeartbeatAwareRetryingExecutorServiceImpl.submit(HeartbeatAwareRetryingExecutorServiceImpl.java:455)
at com.vmware.vcloud.common.activity.dao.impl.AbstractActivityService.execute(AbstractActivityService.java:31)
at com.vmware.vcloud.common.activity.dao.impl.ActivityQueueServiceImpl.claimNextRunnableActivity(ActivityQueueServiceImpl.java:87)
at com.vmware.vcloud.activity.toolkit.queueing.DefaultActivityQueue.dequeue(DefaultActivityQueue.java:96)
[.......]

The Cell wasn’t come up and also after a restart of the other Cell we hade the same issue on every Cell which was restarted. After a log of searching I figured out that the created configuration for the performance metrics produced this error. Problems / errors in the vCD Database stopped the start of the vCD Services.
After some search I found a Blog Post on the VMware Blogs (https://blogs.vmware.com/vcat/2017/11/virtual-machine-performance-metrics-vmware-vcloud-director-9-0.html) which didn’t indicate this problem but the solution from there also worked in my case.
The relevant Information’s are these lines:
2. Edit the content of the /tmp/metrics.groovy file to:

configuration {
}

3. Run the following command:

# cell-management-tool configure-metrics –metrics-config /tmp/metrics.groovy

After that I was able to restart my cells and everything went smooth again.

0

Honeypot as a Service (HaaS) Part 3

This is the third Post of the Haas Series…..

After we have everything up and running would should take a deeper look at the vRealize Log Insight.  There we get our notifications in the interactive analytics. In normal cases nobody will monitor the whole time the interactive analytics therefore we create a Dashboard. The create dashboard is only for your custom view. The log Insight documentation state it like this “You can add, modify, and delete dashboards in your Custom Dashboards space.”

So, in the first step we create a dashboard for your personal view. The creating is quite easy. So, if you have an alert in the interactive analytics you can create the Dashboard from there.

 

 

Just click in the New Dashboard Icon on the right site. In the Wizard you create a new dashboard. Provide a Name and if you want share the Dashboard with other Users in the environment.

I use the chart graph for my Dashboard. After you are finished you will find your Dashboard in on the Dashboard View under Shared Dashboards.

Quite Easy or? But would It be better to get an Alert Notification from Log Insight?

This is also very easy. When you go back in the Interactive Analytics just take the Alerts Button.

In the Windows we choose “Create Alert from Query”.

There you provide the required Details for the Alert. Be sure that you configured your SMTP Server before when you use E-Mail as alert notification.

That was cool so far, or?

In the last months I made a couple of NSX Implementations. NSX provides us some really cool feature like the possibility to move VMs into Quarantine to isolate them from the communication with other VMs. So why wo should not use these feature, to migrate the VM were the Access violation was made, into a quarantine location to research what is happening on this VM? When the access was done from a physical machine, we can also create a firewall rule which deny the access to the virtual environment? From my point of view this is security in an automated way.

In this blog Post I will not show how to install and configure the NSX Part of this series. There are a lot of useful information available.

To archive these goal, we can use a REST API Call to the vRO Server to call a workflow which we develop to migrate the VMs or create the firewall rule. One of the first things which we need, is the possibility to interact with NSX from the VMware Orchestrator. Therefore, will install the VMware Orchestrator NSX Plugin. The plugin can be found on the VMware Page:

https://my.vmware.com/web/vmware/details?downloadGroup=NSXV_VROPLUGIN_120&productId=417

We also need two additional Plugins The first plugin is needed to decrypt the BASE64 encrypt string from the Shim in vRO. The Plugin can be found here: https://communities.vmware.com/docs/DOC-24991

The next Plugin is not really necessary but from my point of view the JSON Implementation in vRO is not the best in the world…. therefore, I use the jsonPath for Orchestrator Plugin frim Soeldner-Consulting. The documentation and the Link to the VMware Solution Exchange can be found here:

jsonPath for Orchestrator

After we download the all plugins we can install them via the vRO Control center.

After we are finished with that, we have to create our Workflow that must start when an alert is triggered. The triggering can be done via email or REST API Call. I prefer the REST-API Call du the circumstance that this more flexible, but wait…….here we have a problem. The VMware vRealize Log Insight doesn’t offer any option to create a REST API Call. In the Web GUI only Webhook Notification is available. Therefore, we need a translation between the Webhook and the REST API Call which we need for the vRealize Orchestrator. As always there is an solution available…..Steve Flanders create a Shim which can act as Proxy for the Webhook notification in direction of the VMware vRealize Orchestrator. Steve has a GIT Repository with a good documentation about the different available versions and the installation. I will not go further on the installation as already everything is explained here: https://github.com/vmw-loginsight/webhook-shims

Another useful post can you find here:

https://blogs.vmware.com/management/2017/03/webhook-shims-now-available-on-docker-hub.html

After we installed and configured the Shim, we are ready to make our next steps.

I created a vRO Workflow which used as Input parameter the name of the Attacker VM. The workflow checks the Attacker VM against the configured Datacenter. When it is a virtual machine, then an NSX Security Profile is attached to the virtual machine and all communication is denied. When it is not a virtual machine, then an IPSet is created and this IPSet is added to a Security Group

For the workflow it is necessary, that the NSX Manager is configured within vRO. Also, that a security Policy exist which we can use in the workflow. Also, the Datacenter which host our virtual machines in our environment must be provided.

Now let’s have a look at the Workflow:

The Workflow consists from different areas. In the First Part of the Workflow (the yellow box) we have to decode the Base64 string and parse the VM Name from the Log Insight Message.

When we are finished with that, we check if the Attacker Machine is a virtual machine (the red box).  When the machine is a VM, we apply the security Group to the VM (the light brown box) which denies all communication via the Security Policy.

When the Attacker VM is not a virtual machine then the machine will be checked against DNS (the green box) to gather the IP. The DNS checking is done via vRO DNS query so the Orchestrator Appliance must be configured correctly with DNS Server. The DNS Check is done via Name and FQDN. When the name could be resolved and we have the IP Address, then an IPSet is created and the Attacker machine is applied to the security Policy. This only protects the virtual environment!

In all cases a email is created (the blue box) and send to an Administrator.

The Workflow itself has some Attributes which must be filled:

  1. Datacenter –> The Datacenter were to check against the Attacke Machine if it is a VMs
  2. SecurityGroupID –> The Securitygroup ID. The ID is not the name but should look like this: securitygroup-98765. If you don’t know the SecurityGroupID, you can Browse within vRO in the NSX Manager Connection. There you can find the correct name
  3. NSXManager –> Your corresponding NSX Manager (which must be configured before in vRO)
  4. smtpHost –> Your Mail Server
  5. fromName –>  Email Sender Name
  6. fromAddress –>  Email Sender Address
  7. toAddress –> Were the Mail should arrive
  8. DNSDomain –> Your DNS Name to check against FQDN
  9. Optional: SMTPUsername –> The Mail Server Username, if required
  10. Optional: SMTPPassword –> Password for the Mail Server user

For the Workflow itself there is room for optimizing. A loop to check against different Datacenter, or a loop to check against different Domain names……For me and this Demo the Workflow makes his job….

The Workflow can be found here: http://www.vcoportal.de/download/workflow/de.vcoportal.HaaS_.package

 

Honeypot as a Service (HaaS) Part 1 Link: http://wp.me/p7tsEp-C1
Honeypot as a Service (HaaS) Part 2 Link: http://wp.me/p7tsEp-Cb

0

Honeypot as a Service (HaaS) Part 2

In the second Post of this series, we create the Log File Reporting which we will send to vRealize Log Insight.

 

After our samba server is configured (in Part 1) we have to deal with our logfiles and report them to our vRealize Log Insight.

In our Samba Server we already configured the logging which is done in the path /var/log/samba. There files are created for every client which tries to access our server. As long as no client tried to access the file the director should log like this:

When you already accessed your server, you will have a log entry like log.192.168.157.10 or similar.

I will create an event every time a client is accessing the share. Therefore, I will use the inotify-tools. unfortunately, these program is not included the standard CentOS Repository so we have to add an additional repo. I use the fedoraproject repo where we download the Repo configuration and install it.


wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-10.noarch.rpm

rpm -ivh epel-release-7-10.noarch.rpm

After that we can install the inotify-tools with yum.


yum -y install inotify-tools-devel.x86_64

After that we create the string to monitor the samba server for client access.


inotifywait -mrq -e create -e modify -e delete /var/log/samba

In this monitoring we ignore changes to the log.smbd file, due the circumstance that this a a standard file form the samba service. The output of this monitoring locks like this:


/var/log/samba/ MODIFY log log.client1-vcoportal

As we want the information on a remote server, we have to extend our logging string with logger to send the information to a remote server.


inotifywait -mrq -e create -e modify -e delete /var/log/samba  | while read file; do ( logger -n loginsight.vcoportal.de-t securitybreak $file ) done

I send my string to a vRealize Log Insight server and tag the log entry with the word “securitybreak”. In Log Insight we can filter for that word……

So, if you use the interactive analyses you can search for your string.

For me the is still room for improvement. The only relevant information for me is the client name. So, let’s modify the monitoring string.


inotifywait -mrq -e create -e modify -e delete /var/log/samba/host | while read file; do hostname=$(echo $file | cut -d '.' -f2,3,4,5 ); (logger -n loginisght.vcoportal.de -t securitybreak $hostname) done

 

We strip done the string we send to our Log Insight Server to just the Client name. I guess there is a better way to create the string but for me this one work fine.

Now we get only the Client name reported in our Log Insight

How cool is that?

The last thing we have to do is to create a startup script for our monitoring string.

In our case, we will want to run inotifywait as a service and create an init script. First we will create our configuration file:


# specify log file

LOGFILE=/var/log/inotify.log

# specify target directory for monitoring

MONITOR=/var/log/samba

# specify target events for monitoring ( comma separated )

# refer ro man inotifywait for kinds of events

EVENT=create,delete,modify

# Log Insight or SNMP Server

SNMPSERVER=loginsight.vcoportal.de

# Security tag

SECURITYTAG=securitybreak

 

Next, we will create the init script where we use the config file we created before as input for the variables.


#!/bin/bash

# inotifywait: Start/Stop inotifywait

#

# chkconfig: 2345 10 90

# description: inotifywait waits for changes to files using inotify.

#

# processname: inotifywait

. /etc/rc.d/init.d/functions

. /etc/sysconfig/network

. /etc/inotifywait.conf

LOCK=/var/lock/subsys/inotifywait

RETVAL=0

start() {

echo -n $Starting inotifywait:

# Clear Log File

if [ -e $LOGFILE ];then /usr/bin/truncate -s0 $LOGFILE;fi

# Start the Monitoring

/usr/bin/inotifywait -e $EVENT -dmrq $MONITOR --exclude ‘\(log.smbd\)*’ -o $LOGFILE | cut -d '.' -f2,3,4,5 $LOGFILE | while read file; do (/usr/bin/logger -n $SNMPSERVER -t $SECURITYTAG $file) done

RETVAL=$?

echo [ $RETVAL -eq 0 ] && touch $LOCK return $RETVAL

}

stop() {

echo -n $Stopping inotifywait:

killproc inotifywait

RETVAL=$?

echo [ $RETVAL -eq 0 ] && rm -f $LOCK return $RETVAL

}

case $1 in start)

start;;

stop)

stop;;

status)

status inotifywait;;

restart)

stop

start;;

*)

echo $Usage: $0 {start|stop|status|restart}

exit 1

esac

exit $?

 

The permissions need to be 755:


chmod 755 /etc/rc.d/init.d/inotifywait

 

We can start the service now:


/etc/rc.d/init.d/inotifywait start

 

The result will be like this:


[root@backup ~]# /etc/rc.d/init.d/inotifywait start

Starting inotifywait (via systemctl):                      [  OK  ]

 

We need to ensure that the service starts when the server boots, so we need to add it to chkconfig


chkconfig --add inotifywait

chkconfig inotifywait on

 

The log entry is written in the /var/log/inotify.log file and from there they were cut down to post the to the log insight server. We have to use this loop due the circumstance, that in our start script inotiywait is used in daemon mode. There a logfile is mandatory.

That’s it for Part 2

 

Honeypot as a Service (HaaS) Part 1 Link: http://wp.me/p7tsEp-C1
Honeypot as a Service (HaaS) Part 3 Link: http://wp.me/p7tsEp-Cl