Stunnel

Please note latest versions of HAProxy can support Stunnels features with higher performance and lower complexity.

The stunnel software is awesome. It allows you to encrypt any connection between local or remote systems. We will use it to perform the SSL Offloading for our system. This tool will take care of all the SSL encryption, releasing that burden from the web servers, because web servers are … well, web servers, not SSL managers.

We will use stunnel to:

1. Listen for secure SSL connections on port 443 of our external IPs
2. Manage the encryption/decryption
3. Request (without encryption) the web page from the Web servers
4. Send the request back to the client encrypted

From the Stunnel web page:

The stunnel program is designed to work as an SSL encryption wrapper between remote client and local (inetd-startable) or remote server. It can be used to add SSL functionality to commonly used inetd daemons like POP2, POP3, and IMAP servers without any changes in the programs’ code. Stunnel uses OpenSSL libraries for cryptography, so it supports whatever cryptographic algorithms you compiled into your library.

Stunnel can benefit from FIPS 140-2 certification of the OpenSSL library, as long as the building process meets its Security Policy.

Stunnel is a free software authored by Michal Trojnara. Although distributed under GNU GPL version 2 or later with OpenSSL exception, stunnel is not a community project. We retain the copyright of the source code. Please contact us for support or non-GPL licenses.

The obsolete 3.x branch is no longer maintained. Use stunnel3 perl script as a drop-in replacement for backward compatibility.

Ideally you could run your own farm of TLS/SSL Offloaders using their own hardware (in combination with a balancing  software tools like HAproxy / Wackamole / Spread  / UltraMonkey you can have your own home made High Availability Load Balancer). As mentioned before, this would allow you to release the encryption load from the Web tier.

sshd

The sshd daemon will be used to access the system. If we want to have multiple web instances, each one managed by different individuals, we’d usually think about setting up a FTP server and create virtual users (so we know they cannot log in). Or, we can use the SFTP subsystem, rely on the OS user management and also have Secure FTP only access to our system. Even more, we can create RSA keys for the users so they don’t need to worry about passwords. The main features of the setup would be:

• We will grant only SFTP access to the UNIX accounts of the web instances, this way we will have a Secure FTP server that relies on the system accounts. No shell access will be granted to these users.
• The access to the root user is disabled (we can allow forced commands to run rsync scripts)
• The UNIX group sshusers defines the users that can access to a shell via ssh
• The UNIX group sftpweb defines the users that will only access the system via SFTP (they cannot get a shell).This group contains all the users created to run the Web instances. In fact, they will only be able to access a particular directory (in this example this directory is /home/user/data, where the user will find his htdocs/ and logs/ directories of the web instance)
• In the case that Public Key authentication is going to be used, make sure we manage the public keys, so the users cannot modify them.

The idea

I’ve run web servers at home for a quite long time. I used to have my LAMP system (compiled to fit my needs) running on Slackware and it covered all my needs for many years. But during the last years I found myself running very different flavors of Application Servers and I found that my LAMP setup was not flexible enough to deal with such an heterogeneous systems.

I wanted to have a solution that would allow me to run different web servers (apache, nginx, Jetty, flask…), different Application Servers (tomcat, WebLogic, JBoss, Django, perl scripts, etc..) all of them isolated as much as possible from the others.

Since this is a home solution and I cannot afford to have a rack full of blades at home, all these services should run in commodity hardware. I’ve chosen to run it on a laptop, that gives me a UPS service (battery) although it has the drawback of not much CPU power and (most important)  not much RAM. Of course, the solution could be extrapolated to multiple machines, having the ability to grow either horizontally or vertically. But for now, this solution will be confined into a single server 🙁

My ideal solution should, if possible, cover these needs:

Pues hace ya algunos días que habíamos dejado macerando en el artículo anterior el script de python getRunningserver.py que nos enseñaba la lista de instancias WebLogic que están corriendo (modo RUNNING). Vamos a ver ahora si podemos integrar este script en otro de bash, de forma que podamos fácilmente ejecutarlo desde la línea de comandos.

Teníamos este comando para ejecutar nuestro script (ojo, acordáos que en en el artículo anterior habíamos definido una serie de variables de entorno!) :

${JAVA_HOME}/bin/java -Dpython.cachedir=/tmp weblogic.WLST \
getRunningservers.py userconfig.properties userkey.properties \
t3://localhost:7001

Vale, la jugada ahora es integrar todos los requisitos que necesitamos para lanzar este script desde otro de bash, a saber:

• Cargar las variables de entorno de WebLogic vía  setDomainEnv,sh
• Definir la JVM en caso de que queramos usar otra que la que usa WL
• Definir los archivos de autorización de WLST
• Definir la URL de administración de WL

Vamos allá

WLS…qué?

Desde hace ya algún tiempo tenía en mente hacer una serie de posts sobre como automatizar tareas en Oracle WebLogic® con WLST (WebLogic Scripting Tool) vía bash.

Desde las versiones 9.x de WebLogic, este componente viene por defecto. Para 8.x, existía un jar que se podía descargar en las páginas del Dev2Dev de Bea, pero tras su adquisición por Oracle, perdí la pista a esa página y, por tanto, también a la posibilidad de correr WLST en esa versión.

Básicamente, lo que WLST nos ofrece es un entorno de scripting para gestionar los dominios de WebLogic basado en jython (implementación de python en java).  Al ejecutar la consola de WLST tendremos un intérprete de jython con una serie de funciones predefinidas para administrar WebLogic, de forma que podremos arrancar o parar servidores, crear JDBC pools…lo que sea!