Compiling NetXMS Agent on Alpine Linux

I needed to use the NetXMS agent on my Alpine Linux system which I am using as a utility linux server. The source-code download link for NetXMS v2.2.10 (latest at the time of this writing) is at https://www.netxms.org/download/releases/2.2/2.2.10/netxms-2.2.10.tar.gz

Here is the quick set of dependent packages and libraries I needed to install to be able to compile the NetXMS agent for my Alpine Linux box.

apk add --update alpine-sdk
apk add gcc glibc 
apk add g++ automake openssl-dev
apk add libcurl curl-dev
apk add libssh-dev
apk add mosquitto-libs mosquitto-dev
apk add cmake
apk add linux-headers

After installing the above, I could compile and install the NetXMS Agent component with:

tar -xzvf netxms-2.2.10.tar.gz
cd netxms-2.2.10
sh ./configure --with-agent
make
make install

After successful installation you can just modify your NetXMS Agent config at /etc/nxagentd.conf (or copy it over from one of your other linux boxes) and launch the agent as a daemon using:

nxagentd -D

Monitoring Windows RDP Sessions with Splunk

Install Splunk UF on Windows via Command Prompt/PowerShell:

This little one-liner can be used to install the Splunk Universal Forwarder (UF) on Windows Systems supporting powershell. Ofcourse you need administrative priviliges for the user running the powershell session and the installer MSI file needs to be accessible in the provided location (Network paths can also be used)

msiexec.exe /i \temp\splunkforwarder-7.2.0-x64.msi DEPLOYMENT_SERVER="<splunk-deployment-server>:8089" RECEIVING_INDEXER="<splunk-indexer>:9997" AGREETOLICENSE=Yes SPLUNKPASSWORD="SP#fc82kre" /L*v \temp\logfile.txt

Monitoring RDP Login Users with Source IP

Generally the Windows Security Logs have a decent bunch of information and can be monitored by default using the Splunk UF and the Splunk Add-On for Windows but there is a major pain when it comes to corelating Logon IDs with the actual Source IP Address of the incoming RDP connection and also differentiating local console sessions from RDP sessions. The better approach is to monitor the TerminalServices-LocalSessionManager -> Operational logs. To get it running, add the following stanza to your inputs.conf.

#$SPLUNKPATH/apps/Splunk_TA_windows/local/inputs.conf
[WinEventLog:Microsoft-Windows-TerminalServices-LocalSessionManager/Operational]
disabled = 0

Once you have logs rolling in for the above source, you can use the below search queries to show “completed” or “currently running” RDP sessions. I have yet to test whether it also logs “Local” console sessions but I think it does.

RDP Completed Sessions:

index=main source="wineventlog:microsoft-windows-terminalservices-localsessionmanager/operational" NOT Message="*arbitration*" NOT Message="Session *" host="<your-host-here>"
| eval Message = replace(Message,"[\n\r]+", " ")
| eval userstring = mvindex(User, -1)
| eval Domain = mvindex(split(userstring,"\\"),0)
| eval Domain=mvfilter(NOT match(Domain,"NOT_TRANSLATED") )
| eval User = mvindex(split(userstring,"\\"),1)
| transaction Session_ID, User, Source_Network_Address startswith=( ( Message="*logon succeeded*") OR (Message="*reconnection succeeded*") ) endswith=( ( Message="*logoff succeeded*") OR (Message="*Session has been disconnected*") )
| eval start_time = strftime(_time, "%Y-%m-%d %H:%M:%S")
| eval end_time = strftime(_time+duration, "%Y-%m-%d %H:%M:%S")
| table start_time, end_time, Session_ID, Domain, User, Source_Network_Address, duration
| rename Session_ID as "Session ID", Source_Network_Address as "Source Address", duration as "Duration", start_time as "Start Time", end_time as "End Time"

RDP Timeline: (Requires Timeline Visualization Addon)

index=main host="<your-host-here>" source="wineventlog:microsoft-windows-terminalservices-localsessionmanager/operational" NOT Message="*arbitration*" NOT Message="Session *" 
| eval Message = replace(Message,"[\n\r]+", " ") 
| eval userstring = mvindex(User, -1) 
| eval Domain = mvindex(split(userstring,"\\"),0) 
| eval Domain=mvfilter(NOT match(Domain,"NOT_TRANSLATED") ) 
| eval User = mvindex(split(userstring,"\\"),1) 
| transaction Session_ID, User, Source_Network_Address startswith=( ( Message="*logon succeeded*") OR (Message="*reconnection succeeded*") ) endswith=( ( Message="*logoff succeeded*") OR (Message="*Session has been disconnected*") ) 
| eval durationmilliseconds=duration*1000 
| eval usersession=User." (S#".Session_ID.")" 
| table _time usersession Source_Network_Address durationmilliseconds Session_ID

Happy Splunking!

TinyCore based super low RAM VM Image

When looking for a VM Image which can boot with 64MB RAM or less, I came accross the excellent image created by Iwan Rahabok of VMWare. (original post here)

I needed serial console functionality so I re-mastered it using the guidelines posted at

http://brezular.com/2013/10/02/core-linux-installation-with-a-console-support-on-qemu-image/

A few things like openssh server and nginx have been included and are set to autostart (called from /opt/bootlocal.sh)
The interface configuration can be modified by editing /opt/eth0.sh

The disk image can be downloaded here.
Feel free to reach out to me if you have questions.

Installing Wok and Kimchi on Ubuntu 16.04 LTS

I’ve been looking for a nice graphical front-end for KVM ever since I started using KVM and OpenVSwitch on an Ubuntu host (which also happens to be a VM, nested virtualization FTW). I stumbled accross Kimchi and decided to try it out. Installing it from the ubuntu repo fails and the dpkg postinstall process hangs (bug reported here. )

So I guessed I’d have to install it the right way:

(1) Install the official Wok deb package

wget http://kimchi-project.github.io/wok/downloads/latest/wok.noarch.deb
dpkg -i wok.noarch.deb

(2) Install the official Kimchi deb package

http://kimchi-project.github.io/kimchi/downloads/latest/kimchi.noarch.deb
dpkg -i kimchi.noarch.deb

(3) (Optional) Install the official Ginger-Base deb package

wget http://kimchi-project.github.io/gingerbase/downloads/latest/ginger-base.noarch.deb
dpkg -i ginger-base.noarch.deb

After all this is done, you’ll just need to place the SSL Certificates for Wok in the path mentioned in /etc/nginx/conf.d/wok.conf and restart nginx.

At this stage you should be able to access the Wok/Kimchi interface at https://<your-host-ip>:8001/

Here is what mine looks like:

Kimchi Interface

Kimchi gives a nice little dasbhoard showing running libvirt managed VMs and also provides the ability to define new templates, guests and even networks. Ginger-base gives some rudimentary host management features. VNC access is provided in-browser using the noVNC plugin and works like a charm.