Whatever expressed in this blog is strictly my own opinion. They do not reflect any other entity 'am associated with. The comments expressed by the blog viewers are their opinion they do not necessarily reflect mine.

My top security predictions for 2017

January 30, 2017 Leave a comment

My Top predictions for Cloud:
DoS/DDoS: More and more enterprises are joining public cloud for shifting production workloads from internal data centers to Cloud that’s managed by various cloud providers. Attackers are constantly hunting for innovative ways to bring down the services. Considering the history of disruptions (5-hour outage of AWS, Dyn’s DNS infrastructure disrupting Twitter/Spotify/AWS etc) there are potential outages to happen in the next year too.
Software Defined Networking: Insecure configuration of Control and Data Plane Layers will open the doors for the attackers to disrupt your hybrid cloud, private cloud environment. Most of the time teams that configure or manage SDN are not Security folks, hence the risk is double!
Ransomware: Malicious software designed to block access to the victim’s files until the victim pays a ransom in Bitcoin is a potential threat that we can see a rise in the next year. With the advent of cloud-based services, this is going to be increasingly common threat next year.
Data Loss/Leakage: Growing volumes of sensitive data in the cloud will invite hackers. Trust no one should be the principle to adopt. Strict Key Management Systems (KMS) should be adapted for data at rest and use Transport Layer Security for data in motion.
My Top predictions for Enterprise-level:
Mobile Malware: Facing this age old problem that always surfaces with a new face is quite a daunting task! At the enterprise level – effective antivirus products and malware defenses can combat malware to a larger extent. But the problem is with mobile devices joining the corporate internal wireless network are becoming soft targets! Attacks such as memory-resident malware is an emerging trend and forensically difficult to detect. Take a note of that!
My Top predictions for Home User:
IoT (Internet of Things): With the advent of Siri and Alexa, Privacy of individuals is undoubtedly a big challenge. This “always on” feature is a bit disturbing fact, though! Though security standpoint of this product is still unclear, but few experts say the product is secure with no obvious backdoors, however, only the times to come will decide the security posture of such products till hacked or especially in cases where software updates/patching flow-in opening the back doors. IoT is next big thing to lookup and a possible source of cyber attacks!
Categories: General

2017 Cyber Security Trends – 20 Professionals Speak Out

January 30, 2017 Leave a comment

VeriClouds recently polled a field of Cyber Security professionals to get their opinions on the predominate threat trends in 2017. Our experts are CEO’s, CISOs, Engineers, Security Architects and Consultants working in universities, private consulting firms and corporations. Cyber Security 2017 Summary All responses, including those persons wishing to remain anonymous, were considered in writing […]

Source: 2017 Cyber Security Trends – 20 Professionals Speak Out

Categories: General

Limitations with Kubernetes Secrets

December 29, 2016 Leave a comment

I’ve been working in Kubernetes space for quite some time now and ‘ve been coding in Go and directly contributing to this project in opensource world. Well coming to the subject of this blog, I would like to touch base here on a loosely designed object i.e. “secret store” in kubernetes. This topic has been a center of discussion in various forums, ‘am just trying to re-echo their voice in this blog.

Right now Kubernetes stores it’s secrets in etcd under /registry/secrets location. All the secrets are just base64 encoded and stored in etcd. This is what is the primary risk that security guys like me have been barking about. Now is there a way to get out of this issue? Yes but with a possible enhancement i.e. to externalize the secret store from Kubernetes system to something like HashiCorp’s HashiVault or Barbican coupled with Hardware Security Module (HSM).

Following are few risks adapting secret store mechanism in K8s:

  1. API server secret data is stored as plaintext (base64 encoded only) in etcd
  2. Secrets are shared if multiple replicas of etcd are run
  3. root on any node can read any secret from the api server
  4. User creating a pod that uses secret can also see the value of that secret
  5. No secret store access control at Kubernetes cluster level
  6. Key max length of 253 chars, Secret value <= 1MB. It is possible to accidentally push the Secrets definition to version control

Here is the change that ‘am looking for…It can be Barbican or HashiVault…

Barbican_k8s.png

 

Currently there is no plug-in to K8S that can help externalize the secret store to Hashi Vault or Barbican. I developed one for both HashiVault and Barbican, I will upload the github link soon for it.

Categories: General

OpenStack Barbican & HSM Flow

December 28, 2016 Leave a comment

I assume you know what Hardware Security Module in short HSM is… if not https://en.wikipedia.org/wiki/Hardware_security_module

HSM Limitations

  • Maximum 20 partitions/slots (eg: Luna HSM)
    • Enough space to hold an RSA key-pair
    • Default total storage space on the HSM is 2 MB (upgrade to 15MB)
  • Only limited number of keys can be stored
  • Performance subject to network latency, scale and HSM performance

Barbican is an Openstack module for storing secrets. I’ll write few blog posts on Barbican PoC later. Barbican + HSM can make a great combination for storing your cloud secrets to meet security and PCI based compliance requirements. Not wasting time, here is how integration flow looks like…

barbican_hsm_flow

High-Level flow of Barbican & HSM integration

  • MKEK (Master Key Encryption Key) is global key to Barbican
  • Project level unique KEK stored in Barbican (in fact encrypted KEK is stored)
  • Data Encryption Keys (DEK) stored in Barbican (in fact encrypted DEK is stored)
  • MKEK wraps every project’s unique KEK
  • KEK wraps project’s DEK

 

Kubernetes start local cluster with internal IP

November 9, 2016 Leave a comment

$ ./hack/local-up-cluster.sh

This starts-up the local cluster with 127.0.0.1

Requirements:

  • Access this cluster from outside environment
  • Run this cluster with an IP address instead of 127.0.0.1
  • UP local cluster with IP and make sure to have NO_PROXY configured in kubernetes.

Solution:

If you are behind a corporate firewall and wish to run cluster with an IP, you need to have NO_PROXY configured inside kubernetes appropriately. For this and above reqs, follow all or certain steps that meet your need.

  • Modify your local-up-cluster.sh script
API_CORS_ALLOWED_ORIGINS=${API_CORS_ALLOWED_ORIGINS:-
"/127.0.0.1(:[0-9]+)?$,/192.160.0.105(:[0-9]+)?$"

Here 192.160.0.105 is my internal IP address, you should replace it with your IP.

  • Go to ./hack/lib/init.sh (I tried KUBERNETES_NO_PROXY env variable, but this didn’t work, ’cause init.sh script no_proxy doesn’t have predefined $no_proxy prefix for export command! This I think is a bug!)

search for “no_proxy”

export no_proxy=127.0.0.1,localhost (default value)

Change this to below

export no_proxy=127.0.0.1,192.160.0.105,10.122.49.221,localhost

You can add list of IP addresses that you want for no_proxy.

  • After this you can make changes to local-up-cluster.sh start_apiserver method to have your internal ip 192.160.0.105 instead of 127.0.0.1 (etcd ip can be retained to 127.0.0.1) for insecure-bind-address, bind-address.

Finally, do UP your local cluster…


$./hack/local-up-cluster.sh

Categories: General, kubernetes Tags: ,

Tomcat 2 way SSL Configuration (Step-by-Step)

August 9, 2016 1 comment

The is a working POC for 2 way SSL configuration in Tomcat server, where client and server has OpenSSL key pairs. This POC covers CA, Server & Client all running on same machine.

Step 1: Create your own root CA


~/openssl$ mkdir -m 0700 /home/ubuntu/openssl/CA /home/ubuntu/openssl/CA/certs /home/ubuntu/openssl/CA/crl /home/ubuntu/openssl/CA/newcerts /home/ubuntu/openssl/CA/private

~/openssl$ touch /home/ubuntu/openssl/CA/indext.txt

~/openssl$ echo 1000 >> /home/ubuntu/openssl/CA/serial

~/openssl$ mv karun-tomcat-root-ca.key CA/private/

~/openssl$ sudo vi /etc/openssl.cnf
 # Make changes here
 dir = /home/ubuntu/openssl/CA
 #optionally change policy definitions as well

~/openssl$ openssl genrsa -des3 -out karun-tomcat-root-ca.key 2048
#In below command make sure to use CN=<hostname of your machine>

~/openssl$ openssl req -new -x509 -days 36520 -key karun-tomcat-root-ca.key -out karun-tomcat-root-ca.crt -config openssl.cnf

~$ sudo cp ~/openssl/CA/certs/karun-tomcat-root-ca.crt /usr/share/ca-certificates/

# make sure in the UI you enable/select the certificate created above

~$ sudo dpkg-reconfigure ca-certificates

# Now reboot ubuntu machine just to make sure certificates are loaded successfully and tomcat picks it

 

Step 2: Create Tomcat Server’s Key Pair


~$ openssl genrsa -out tomcat-server.key 2048

# Use common name =<Give IP address>, department = Tomcat Server CSR

~$ openssl req -new -sha256 -config ~/openssl/openssl.cnf -key tomcat-server.key -out tomcat-server.csr

~$ openssl x509 -req -sha256 -days 36520 -in tomcat-server.csr -signkey tomcat-server.key -CA ~/openssl/CA/certs/karun-tomcat-root-ca.crt -CAkey ~/openssl/CA/private/karun-tomcat-root-ca.key -CAcreateserial -out tomcat-server.crt

~$ openssl pkcs12 -export -name karun-tomcat-server-cert -in tomcat-server.crt -out tomcat-server.p12 -inkey tomcat-server.key -CAfile ~/openssl/CA/certs/karun-tomcat-root-ca.crt -caname karun-root -chain

~$ keytool -importkeystore -destkeystore tomcat-server.jks -srckeystore tomcat-server.p12 -srcstoretype pkcs12 -alias karun-tomcat-server-cert

~$ keytool -import -alias karun-root -keystore tomcat-server.jks -trustcacerts -file ~/openssl/CA/certs/karun-tomcat-root-ca.crt

# Run this once client cert is generated
~$ keytool -importkeystore -alias karun-tomcat-client-cert -srckeystore ~/client-certs/tomcat-client.p12 -srcstoretype PKCS12 -destkeystore tomcat-server.jks -deststoretype JKS

# Run this once tomcat server started successfully
~$ openssl s_client -connect localhost:8443 -cert ~/client-certs/tomcat-client.crt -key ~/client-certs/tomcat-client.key -debug -showcerts 

Step 3: Create Client Side Key Pair


~$ openssl genrsa -out tomcat-client.key 2048
# Use common name = <tomcat-user.xml's user say 'admin'>, department = Tomcat Client CSR

~$ openssl req -new -sha256 -config ~/openssl/openssl.cnf -key tomcat-client.key -out tomcat-client.csr

~$ openssl x509 -req -sha256 -days 36520 -in tomcat-client.csr -signkey tomcat-client.key -CA ~/openssl/CA/certs/karun-tomcat-root-ca.crt -CAkey ~/openssl/CA/private/karun-tomcat-root-ca.key -CAcreateserial -out tomcat-client.crt

~$ openssl pkcs12 -export -name karun-tomcat-client-cert -in tomcat-client.crt -out tomcat-client.p12 -inkey tomcat-client.key -CAfile ~/openssl/CA/certs/karun-tomcat-root-ca.crt -caname karun-root -chain

~$ (optional step) keytool -importkeystore -destkeystore tomcat-client.jks -srckeystore tomcat-client.p12 -srcstoretype pkcs12 -alias karun-tomcat-client-cert

~$ (optional step) keytool -import -alias root -keystore tomcat-client.jks -trustcacerts -file ~/openssl/CA/certs/karun-tomcat-root-ca.crt

<p class="lang-java prettyprint prettyprinted">

Step 4: Tomcat Changes


<p class="lang-java prettyprint prettyprinted"><!-- Make this change in server.xml of tomcat server -->
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="/opt/tomcat/openssl-certs/tomcat-server.jks"
keystorePass="password"
keyAlias="karun-tomcat-server-cert"
truststoreFile="/opt/tomcat/openssl-certs/tomcat-server.jks"
truststorePass="password"
clientAuth="true" sslProtocol="TLS" /></p>
<p class="lang-java prettyprint prettyprinted">

Step 5: Restart Tomcat Server && check logs to ensure no errors at bootup

Step 6: Upload Client cert to browser

In your browser, eg: firefox, navigate Preferences -> Advanced -> Certificate -> View Certificates -> Your Certificates

Import “tomcat-client.p12”

https://localhost:8443/

References

http://pages.cs.wisc.edu/~zmiller/ca-howto/

http://www.area536.com/projects/be-your-own-certificate-authority-with-openssl/

Docker & Kubernetes Cheat Sheet

Categories: General, Security Tags: , ,