Zimbra Open Source

Hace tiempo que quería probar esta aplicación y por fin he podido ponerla en producción. Realmente la definiría como impecable. Tiene una instalación sencilla si utilizas alguna de las plataformas para las que han paquetizado como OpenSuse SLES10, Red Hat... El único problema que me he encontrado en la instalación era el DNS. Tiene que estar configurado el MX y resolver el nombre del servidor correctamente, sino, no funciona nada. El resto ha sido fácil.

linux-2et7:~/zcs-5.0.11_GA_2695.openSUSE_10.2.20081117121220 # ./install.sh
Operations logged to /tmp/install.log.5907
Checking for existing installation...
zimbra-ldap...FOUND zimbra-ldap-5.0.11_GA_2695
zimbra-logger...FOUND zimbra-logger-5.0.11_GA_2695
zimbra-mta...FOUND zimbra-mta-5.0.11_GA_2695
zimbra-snmp...NOT FOUND
zimbra-store...NOT FOUND
zimbra-apache...FOUND zimbra-apache-5.0.11_GA_2695
zimbra-spell...FOUND zimbra-spell-5.0.11_GA_2695
zimbra-proxy...NOT FOUND
zimbra-archiving...NOT FOUND
zimbra-convertd...NOT FOUND
zimbra-cluster...NOT FOUND
zimbra-core...FOUND zimbra-core-5.0.11_GA_2695
...

Finalmente si todo va bien aparece el Main Menú donde hay que poner el password para el usuario admin@dominio.com

Main menu

1) Common Configuration:
2) zimbra-ldap: Enabled
3) zimbra-store: Enabled
+Create Admin User: yes
+Admin user to create: admin@dominio.com
******* +Admin Password UNSET

y después de unos minutos, todo estará funcionando.

Se puede entrar en la cuenta de admin a través del espectacular webmail (ajax) y tambien a la web de administración por https://direccion:7071/zimbraAdmin/
-

Xen + OpenSUSE Virtualización Open Source para todos

OpenSuse fué una de mis distros favoritas, el hecho de integrar un gestor de maquinas virtuales (virt-manager) en el Yast,  facilita la vida. Actualmente estoy en proceso de virtualización de mis servidores a Xen opensource con Opensuse 11.1 y la verdad es que es una joya. Ya desde la 10.2 el tema de la virtualización, lo llevan implementando muy bien. El tema se complica cuando ya configuras hearbeat, iscsi, etc... 

Protege SSHD - configuración segura

Configuración del servidor SSH

LoginGraceTime 30

Cantidad de segundos en que la pantalla de login estará disponible para que el usuario capture su nombre de usuario y contraseña, si no lo hace el login se cerrará, evitando así dejar por tiempo indeterminado pantallas de login sin que nadie las use, o peor aun, que alguien este intentando mediante un script varias veces el adivinar un usuario y contraseña. Aqui conviene identificar en nuestros usuarios el tiempo promedio que tardan en ingresar su usuario y contraseña y darles unos cuantos segundos más de margen por los usuarios lentos para que ingresen sus credenciales. Si somos el único usuario del sistema considero que con 20 o 30 segundos es mas que suficiente.

PermitRootLogin no
Root no entra directamente por ssh

AllowUsers Ferran
Solamente mi usuario entrara.

AllowGroups wheel

AllowUsers ferran@192.168.1.25     (solo desde la IP indicada)
AllowUsers ferran@192.168.1.*       (Toda la red indicada) 

MaxAuthTries 2: El número indica la cantidad de veces que podemos equivocarnos en ingresar el usuario y/o contraseña, en este caso después de dos intentos, se perderá o cerrará la conexión. Claro, es totalmente posible volver a intentarlo, pero como son dos intentos por vez, evitaremos ataques basados en la persistencia de la conexión, como se perderá al tercer intento de conexión, el ataque cesará.

MaxStartups 3: El número indica la cantidad de pantallas de login, o cantidad de conexiones simultaneas de login que permitirá el sshd por ip que intente conectarse. Hay ataques muy efectivos que dividen el ataque en decenas y puede ser que en cientos (si el sistema atacado lo permite) de conexiones de login. Es decir, el ataque divide en una gran cantidad de logins los intentos por ingresar, aumentando sus posibilidades de más rapidamente adivinar al usuario y contraseña. Con esta directiva limitamos a tan solo 3 pantallas de login. Que quede claro, una vez logueados en el sistema, es posible tener mas de 3 terminales de ssh, se refiere exclusivamente a pantallas de login.

En el artículo de linuxtotal.com.mx Sergio Gonzalez Duran redactó una buena pauta a seguir.
http://www.linuxtotal.com.mx/index.php?cont=info_seyre_004

Resumiendo...

Protege SSHD de pesados ataques de fuerza bruta con IPTABLES

Después de ver la cantidad de logs que tengo en mi servidor por culpa de estos barridos de IPs en busca de passwords débiles, he encontrado las siguientes reglas que pueden ser útiles. Lo pongo en formato script copy/paste:

#/bin/bash
iptables -A SSH -m recent --name SSH_ABL --update --seconds 3600 -j REJECT
iptables -A SSH -m recent --name SSH --rcheck --seconds 60 --hitcount 5 -j SSH_ABL
iptables -A SSH_ABL -m recent --name SSH_ABL --set -j LOG --log-level warn --log-prefix "ABL: +SSH: "
iptables -A SSH_ABL -j REJECT
iptables -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG --log-level warn --log-prefix "RATE: "
iptables -A SSH -m recent --name SSH --update --seconds 2 -j REJECT
iptables -A SSH -m recent --name SSH_ABL --remove -j LOG --log-level warn --log-prefix "ABL: -SSH: "
iptables -A SSH -m recent --name SSH --set -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH

Otro más

iptables -A INPUT -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP
iptables -A INPUT -m recent --set --name SSH --rsource -j ACCEPT

Si tengo un poco de tiempo explicaré cada una de estas línias. A grandes rasgos los dos hacen lo mismo, no deja entrar una misma IP si hace más de 5 intentos en 60 segundos.

Aumentar el tamaño de buffer del MYSQL

Me encontré una vez un cliente que utilizaban una aplicación LAMP para registrar incidencias informáticas donde los usuarios podian subir imagenes para mostrar sus pantallazos de error.

Un buen día esta aplicación la tuve que migrar a un nuevo servidor y cuando todo parecía ir bien, los ficheros de más de dos MB no había manera de subirlos. Urgando en el código de la aplicación vi que el fichero se almacenaba binariamente en un campo de una tabla y ya me hizo sospechar que MYSQL tendria alguna variable para restringir el tamaño de buffer.

la susodicha variable es max_allowed_packet y controla el tamaño máximo del buffer de comunicación. Para establecer el valor de la variable max_allowed_packet de mysql en 16MB, use cualquiera de los siguientes comandos:

shell> mysql --max_allowed_packet=16777216
shell> mysql --max_allowed_packet=16M

El primer comando especifica el valor en bytes. El segundo especifica el valor en megabytes. Los valores de las variables pueden tener un sufijo K, M, o G (ya sea en mayúsculas o minúsculas) para indicar la unidad, que puede ser kilobytes, megabytes, o gigabytes.

En un fichero de opciones, la variable se coloca sin precederla con dos guiones:

[mysql]
max_allowed_packet=16777216

O bien:

[mysql]
max_allowed_packet=16M

RINETD Redirigiendo el trafico TCP/IP entre servidores

Seguro que muchas veces has pensado, como puedo hacer para que en un momento pueda redirigir el trafico de un puerto de una máquina o otra con otro puerto. Para ello, aparte de Iptables, tenemos rinetd.

Este se define como un redirector de conexiones TCP de una IP y puerto a otra IP. Es un programa pequeño y sencillo que solo tiene un proceso, capaz de manejar un gran numero de conexiones. Los servicios como FTP que requieren varios sockets no se pueden redirigir.

Una utilidad practica es si en un servidor tomcat que escucha por el puerto 8080, queremos que se vea por el puerto 80 y así no instalar el conector de apache para tomcat, con rinetd es sencillisimo.

bindaddress bindport connectaddress connectport

10.1.1.2 80         10.1.1.2 8080
allow 10.1.1.*

Y con iptables seria:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port 8080

Con IPTABLES, mejor que mejor. Siempre obtendrás un rendimiento más óptimo

Referencias
web oficial: http://www.boutell.com/rinetd/

Proxy inverso con Pound

Navegando por la red, encontré diferentes forma de hacer un proxy inverso y de todas las que probé, POUND, me convenció mucho, primera por su facilidad y segundo por su flexibilidad.

Pound no es solo un proxy inverso http, también permite balancear cargas y permite https. Fue desarrollado para permitir la distribución de la carga entre varios servidores Web y para permitir un cómodo entorno SSL a los servidores web que no lo ofrecen de forma nativa. Se distribuye bajo la licencia GPL

Escenario:

        Internet   ------------>>>>     Firewall    ------>>  Servidor Linux
                     
                                                                     |
                                                                     |
                                                                     |
                                                                    LAN
                                                                   EMPRESA

En los repositorios basicos y en Packman de OpenSuse 11 se encuentra ya el rpm. Supongo que debian y ubuntu tambien tendran su paquete.

Debian)apt-get install pound

Suse/CentOS) rpm -Uvh pound*

OpenSuse) zypper install pound

Es tan sencillo como instalarlo y configurar el fichero de configuración /etc/pound.cfg

# Start pound as User with Group
User "pound"
Group "pound"
#IP d'origen http
ListenHTTP
Address IP_LOCAL_PROXY_INVERSO
Port 80
End
#IP d'origen https
ListenHTTPS
Address IP_LOCAL_PROXY_INVERSO
Port 443
Cert "/etc/ssl/local.server.pem"
End

Service
HeadRequire "Host: .*IP_INTERNET.*"
BackEnd
Address IP_SERVIDOR_WEB_LAN
Port 80
End
End


Para generar el certificado ssl hacemos:

# cd /etc/ssl && openssl req -x509 -newkey rsa:1024 -keyout local.server.pem -out local.server.pem -days 365 -nodes

Referencias y más info

Un buen how to: http://www.cyberciti.biz/faq/linux-http-https-reverse-proxy-load-balancer/

Web oficial: http://www.apsis.ch/pound/