Securing Hazelcast (tcp) traffic with Stunnel

Hazelcast is a distributed in-memory data grid, which allows to evenly share data among nodes in clustered environments. The open source version of Hazelcast does not support encryption at the transport or even at the cache level. So in order to secure traffic in the Hazelcast cluster, we need to extend it by making some code changes, which may not always be an option.

There is however another way to secure the transport by using stunnel. As the official documentation states, “Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs’ code”. This sounds like a perfect option in our case, and allows us to decouple transport encryption from our Hazelcast applications.

Continue reading at Medium…

Docker and iptables firewall

Docker works perfectly fine when no firewall is running on the host machine. Without the firewall docker containers can communicate with each other and with the outside world. But with the firewall we need to setup some rules in order to allow traffic to and from the docker interface. Below it is detailed how we can configure the firewall for docker on a Centos server.

First of all let us find the docker interface and IP, we can do that using the ifconfig command:

Here the interface name is docker0. Now we can setup firewall rules using the iptables command:

With these rules setup, Docker containers can now talk to each other and the outside world.

If you use CSF (Config Server Firewall), a custom chain with these rules can be added to csfpost.sh file, like below:

And then reload the firewall rules using the command below:

Protect your identity from SSH servers

Recently I came across a tweet that highlighted a serious privacy issue related to SSH servers and online services that publish user information in public domain without having to explicitly take permission from users.

In this tweet the guy talks about running a SSH server that matches the incoming connection’s public key with the public keys of Github users, which for some reason Github has kept in the public domain (totally not cool!).

So I decided to give it a go and below is what I found.

kamran@kamran-laptop: ~_005

My public keys were already captured by this server from Github, and so it knew who I was. Which kind of creeped me out. But the feeling was only momentary because I knew what I had to do to protect myself.

The answer lies in the way the public key is shared. Public key is like a signature of the user. My mistake was that I was using my Github public/private key as my default SSH key. So now it was time to change this.

SSH allows you to configure keys per host, therefore limiting the use of the SSH keys for only the specified hosts. This SSH key and host mapping can be configured in ~/.ssh/config file.

So the solution is to backup your existing SSH key and configure the SSH client to use it for the right service.

Then generate a new default public/private key pair.

Now when I connect to Filippo’s dodgy SSH server, it doesn’t know who I am 🙂

kamran@kamran-laptop: ~_007

Note: Another thing to be aware of; if you are using ssh-agent to manage your keys, then it will send all the public keys to any SSH server you connect to. It is better to avoid using ssh-agent, and configure host specific keys in the SSH config file for identity protection.

Sharing VPN connection on Linux

Most VPN servers allow a single remote session per user, which is all you need most of the times. But sometimes it is necessary to connect multiple devices to the VPN server; but using a single user account it is impossible if the server doesn’t allow it. There is a way around this problem by sharing the VPN connection from a central node to other computers by setting up an ad-hoc wireless network using the wireless modem of the central computer as a hot-spot. The idea is fairly simple provided the central computer has two network cards:

  1. Use a central computer to connect to VPN via ethernet or one of the network cards
  2. Setup a hotspot on the central computer so that devices in range can connect to it over wifi
  3. Route all traffic (inbound & outbound) from the hotspot to the ethernet/vpn connection
The diagram below illustrates this.
vpn_share

So how do we do this? Below is an example to setup this configuration on a Linux box. I used Linux Mint desktop in this example. Here are the steps:

  1. Install and configure hostapd application so that you can turn your wireless modem into a hotspot
  2. Install and configure a DHCP server so that IP addresses are assigned to devices connected to the hotspot
  3. Allow IP masquerading to share the ethernet/vpn connection with the devices connected to the hotspot.

Install and configure hostapd

Use the following command to install the hostapd application

Configure hostapd by editing the /etc/hostapd/hostapd.conf file as follows

You can check the wireless interface name by using the iwconfig command, on my machine the interface name was wlan0. Now you can start hostapd using the following command:

Install and configure dhcp

Install the dhcp server using the following command

Edit the /etc/dhcp/dhcpd.conf file to setup subnet by adding the following lines to the file

Edit /etc/default/isc-dhcp-server and add the wireless network interface name like below:

Configure a new interface and start the dhcp server

Allow IP masquerading

Now when the linux box is connected to the VPN, we can share this VPN connection over wifi hotspot by running following commands:

In this example the vpn interface is tun0, you can check the interface name using iwconfig command.

So now VPN sharing is setup and all your devices (computers, tablets, smart phones etc.), connected to the hot-spot of your central linux box, can access all the available network resources on VPN.

Cas-Acegi-Spring integration on JBoss

CAS and Acegi are popular open source authentication and identity solutions available for enterprise java applications. CAS is a Centralized Authentication Server used for single sign-on and to decouple authentication mechanism from applications. Acegi is an authentication API used to put role-based access control on application. This is a simple example that shows how to integrate CAS and Acegi using Spring IoC container in a JBoss Application Server.

This example was tested on JBoss 4.0.4. See the readme file for more details.

Download Example Source