Splunk Management Port

The Splunk management port 8089 has come up repeatedly in enterprise wide security scans. I understand the security team's concerns: This port runs HTTPS with a self-signed certificate, which is a big no-no for any IT person who is even slightly security conscious.

Self-signed TLS certificate is not a security threat in and of itself. The main weakness is that, unless the Certificate Authority is known to clients connecting to the port, the clients are left to trust that certificate, rendering the connection prone to man-in-the-middle attacks.

To make a self-signed certificate as secure as a public CA signed one, Splunk just need to verify the self-signed cert using the signing CA cert. Or, even better yet, mutual authentication may be performed on these connections. However, that also means much stricter management of these certs.

My organization's security team suggested that we get third-party signed certificates for all the Splunk forwarders, which means we would need to obtain hundreds of certificates. That number could potentially grow to over a thousand or two. We are part of a large university with the benefit of largely self-administered certificate signing. But managing such a number of certificates is still a pretty big task unless the entire workflow of certificate creation, signing and renewal can be automated.

One remedy is to disable the port on all Splunk installations where the port is not absolutely needed. That means all the Universal Forwarders, whose main purpose is to collect data and forward to indexers. However, port 8089 is labeled a management port. Access to Splunk's REST APIs goes through that port. Disabling it means apps depending on the REST APIs, such as the UFMA app, may not function as designed.

The management port obviously exists for a reason. Beyond the REST API, do we lose any other functionality if we have to disable the port?

So, You Can't Even Buy VPN App in China

I went to Amazon to buy the Cisco AnyConnect app to connect back to UM through VPN.

As it turns out, you can't even do that in China:

Does Anyone Still Care About the Basics?

Cisco's software has always been challenging. Much of those challenges, to put it bluntly, come from the company's neglect.

Here is a simple example: Click this link, select the "Cisco 4500" from the "Cisco Access Products" list, and click the "Go" button, instead of another page seemingly from the year of 1996, you get a 550 error.



How pathetic is that?

Splunk, SSO, Enterprise Security

Splunk is a powerful tool, therefore it is natural that the need to secure it in an enterprise is strong. With the push from upper management to secure access to privileged systems, 2-factor authentication (2FA) is the next defensive weapon to be deployed against attacks from both the outside and inside.

Looking into authentication and authorization mechanisms, especially SSO (single sign-on) in Splunk, it is amazing how much things have stayed the same since I first installed Splunk 4 back in 2011. This time, I am investigating the feasibility of using SAML 2 for Splunk to achieve both single sign-on and role-based access control (RBAC).

What I have found so far are not very encouraging and I seriously hope that someone prove me wrong.

Splunk has a number of ways for user authentication:

• Splunk internal: User information is stored in Splunk itself. A user would have to sign on each and every time visiting a different Splunk web host.
• LDAP: Splunk uses an LDAP server as user ID store.
• Proxy SSO: Splunk web must run behind a proxy server, such as Apache or IIS, which actually implements the sign-on part of SSO.
• Scripted authentication: Splunk calls a custom script to perform user ID acquisition and authentication.

 For user access authorization:

• LDAP: Using LDAP for authentication allows Splunk to map LDAP groups to Splunk roles for access control.
• Script: The script for authentication is also used to assign roles to the user.

Splunk does not seem to allow both SSO and RBAC simultaneously: The only mechanism for SSO is running Splunk web behind a proxy server. But in that case, it still relies on internally stored user information or LDAP group mappings to assign roles to an authenticated user, if this post in the Splunk Answers still holds true. Even if that changes, fronting every Splunk web service with a proxy creates an administrative challenge when you have many Splunk search heads running on both Linux and Windows, for example. Unless, of course, one uses something like Novel NetIQ or Citrix NetScaler. But those mechanisms introduce complexities of their own.

Scripted authentication would offer a way to implement both SSO and RBAC simultaneously if Splunk passes along HTTP request headers to the script. But that does not seem to be the case from reading their documentation.

Asus C300M: A Nice Chromebook but I want Linux

I bought an Asus C300M Chromebook yesterday, with the plan to turn it into a little Mint Linux laptop.

Went searching online, there were lots to be found but all seemed to be about older Asus Chromebooks, like C200 or C300. Not sure if C300M is related to C300 or not. But so far I have not been able to get into the Developer Mode yet, although I did get it to flash this with a "localhost login" prompt on the screen:

The problem is that the prompt just flashes for a fraction of a second. There is no time to login.

I will keep on trying to figure this out. But if anyone has any tips on how to get into the Developer Mode, please share! Thanks in advance.

By the way, Chrome OS works nicely on this little machine. But I want to take the box to a country where most of Google's services are blocked by the government, which is the main reason for me to try installing Linux besides the fun of breaking things.

Weak Product, Bad Design

Received with Bulbs Bumping Around Loose in Box

Purchased the product on eBay to replace burnt out bulbs. The package came pretty fast. I heard something knocking around inside. I opened the padded envelope, took out the box and saw the bulbs running loose in it.

The plastic piece in the box is obviously designed to hold the bulbs in place for transportation. But it is not doing the job. I actually spend a couple of minutes trying to figure out if the bulbs could be put in the holder. I finally give up as it seems that the bulbs simply would not fit.

From the packaging, I am sure that this is not the only box that went out with the product jumping around inside. I do not know if that could damage the bulbs or shorten their lives in anyway. But I am positive that the manufacturer does not want the bulbs running loose, as otherwise they would not need the holder and save a penny with the packaging and transportation.

I installed the bulbs and turned on the low beam. I was not sure if I messed up or something since there seemed to be no light coming out of the headlights -- Only did I see the lights when I stepped right in front of car. The light was bright white, but not as much as I expected.

All in all, I have to say I am less than impressed by the product so far. It seems to be much weaker than advertised. I will have to wait for a drive out in the dark to get a real feeling of how the bulbs work.

VirtualBox Raw Disk Access Problem on Windows 7

For quite a while I have enjoyed running a guest Mint Linux virtual machine on a laptop that must run Windows 7: I pulled out the PC's SATA CD/DVD drive and put a second SSD in its place. To run a VM from a raw disk, VirtualBox has to be manually configured to do that and it must be run as Administrator in Windows.

All that was well, although not without a few kinks I considered minor, until this morning. All of a sudden, I got a dialog box from VirtualBox saying that it failed to start due to permission issues. Here is a list of relevant messages I've copied from the log file, which should read better than the small dialog box:

00:00:01.774460 VDInit finished
00:00:01.775010 AIOMgr: Endpoint for file 'D:\MEMEME\vbox\mint.vmdk' (flags 00040723) created successfully
00:00:01.775716 AIOMgr: Endpoint for file 'D:\MEMEME\vbox\mint.vmdk' (flags 00040781) created successfully
00:00:01.775867 AIOMgr: Endpoint for file '\\.\PhysicalDrive1' (flags 000c0781) created successfully
00:00:01.775885 VMSetError: D:\tinderbox\win-4.3\src\VBox\Devices\Storage\DrvVD.cpp(3061) int __cdecl drvvdConstruct(struct PDMDRVINS *,struct CFGMNODE *,unsigned int); rc=VERR_VD_IMAGE_READ_ONLY
00:00:01.775911 VMSetError: Failed to open image 'D:\MEMEME\vbox\mint.vmdk' for writing due to wrong permissions
00:00:01.775923 VD: Opening the disk took 1593453 ns
00:00:01.776149 VMSetError: D:\tinderbox\win-4.3\src\VBox\Devices\Storage\DrvBlock.cpp(1077) int __cdecl drvblockConstruct(struct PDMDRVINS *,struct CFGMNODE *,unsigned int); rc=VERR_VD_IMAGE_READ_ONLY
00:00:01.776153 VMSetError: Failed to attach driver below us! Image is read-only.
00:00:01.776169 VMSetError: D:\tinderbox\win-4.3\src\VBox\Devices\Storage\DevAHCI.cpp(8450) int __cdecl ahciR3Construct(struct PDMDEVINS *,int,struct CFGMNODE *); rc=VERR_VD_IMAGE_READ_ONLY
00:00:01.776171 VMSetError: AHCI: Failed to attach drive to Port0
00:00:01.776180 PDM: Failed to construct 'ahci'/0! VERR_VD_IMAGE_READ_ONLY (-3205) - Image is read-only.
00:00:01.910243 ERROR [COM]: aRC=E_FAIL (0x80004005) aIID={8ab7c520-2442-4b66-8d74-4ff1e195d2b6} aComponent={Console} aText={Failed to open image 'D:\MEMEME\vbox\mint.vmdk' for writing due to wrong permissions (VERR_VD_IMAGE_READ_ONLY).
00:00:01.910298 Failed to attach driver below us! Image is read-only. (VERR_VD_IMAGE_READ_ONLY).
00:00:01.910299 AHCI: Failed to attach drive to Port0 (VERR_VD_IMAGE_READ_ONLY)}, preserve=false
00:00:01.927049 Power up failed (vrc=VERR_VD_IMAGE_READ_ONLY, rc=E_FAIL (0X80004005))
00:00:02.011279 UIMachineLogicFullscreen::maybeAdjustGuestScreenSizeOpenGL Error: Render SPU: (MakeCurrent) failed to make 0xe00112d5, 0x10000 current with 0x6 error.

I have checked the permissions on the "mint.vmdk" file, both my account and the local Administrators group had full control on the file. So that couldn't have been the file with read-only permission causing this indigestion.

I have also run DISKPART and checked that the disk was not set to READ-ONLY.

I have discarded my saved image and tried to start the VM from a clean state. All to no avail.

I am trying to fix this problem, but thought I may be able to get some help from the community by posting it to the VirtualBox forum.

[EDIT 2014-12-02]:Upgraded to VirtualBox 4.3.20. The problem persists. My suspicion of DDP|E grows deeper.

[EDIT 2014-11-25]: No progress on this issue. Sent email to Credent support (DDP|E was purchased from Credent, I guess.) Falling back to boot Linux on the laptop.

[EDIT 2014-11-23]: From every troubleshooting I could think of, it seems that the disk is held by some process that prevents VirtualBox from being able to write to it.

C:\Program Files\Oracle\VirtualBox>.\VBoxManage.exe internalcommands
listpartitions -rawdisk \\.\PhysicalDrive1
VBoxManage.exe: error: Cannot open the raw disk: VERR_SHARING_VIOLATION

C:\Program Files\Oracle\VirtualBox>.\VBoxManage.exe internalcommands
listpartitions -rawdisk \\.\PhysicalDrive2
Number  Type   StartCHS       EndCHS      Size (MiB)  Start (Sect)
1       0x07  0   /130/3   1023/254/63        122747         8192

From the SystemInternals Process Explorer, it seems that the Dell Data Protection's CmgShieldSvc.exe process is the most suspicious.

[EDIT 2015-05-08]: The issue is resolved in the latest DDP|E release --- kudos to our Windows image team and their working with the Dell (Credent) engineers.