Montar proxy squid3 en Ubuntu

Las ventajas de instalar un proxy en nuestra red son muchas:

Control de usuarios que acceden a internet, así como de páginas visitadas.

Velocidad de acceso a páginas, ya que permite el cacheo.

Filtrado, tanto de las IP origen que pueden acceder al proxy, como de las páginas que pueden visitar.

Anonimato, todos salen a través del proxy y el control reside en el administrador del mismo.

Hoy le damos un repasito a uno de los famosos, en Ubuntu: SQUID3.

Para instalar, tan sencillo como apt-get install squid3. Así que, instala el CALAMAR 😉

Squid
Squid

En /etc/squid3 vamos a encontrar squid3.conf, el archivo de configuración del proxy.

ACL

Las listas de acceso se pueden definir tanto de origen (IP que acceden al proxy) como de destino (IP visitadas por los usuarios). La sintaxis es:

acl nombre_acl tipo_acl descripción …

acl nombre_acl tipo_acl “fichero_de_descripciones” …

Por tipo_acl, podemos tener:

Read more

Cifrado SSL en Apache (Ubuntu)

Este es un tutorial para los que conocemos Apache en CentOS/RHEL y encontramos algunas diferencias con apache2 en Ubuntu.

El fichero de configuración de apache2 de Ubuntu es apache2.conf. Podemos ver claramente que este fichero es muy similar a nuestro httpd.conf de CentOS/RHEL, de hecho, tiene una línea que incluye este fichero para que introduzcamos configuraciones personales de usuario:

Include httpd.conf

Algo que difiere con CentOS/RHEL es que los módulos no se cargan por defecto sobre el archivo de configuración, que podría hacerse. En apache2  tenemos que colocar el módulo en el directorio mods-enabled, ya que en apache2.conf:

Include mods-enabled/*.load
Include mods-enabled/*.conf

No hay que colocar aquí los módulos. Este directorio contiene enlaces a otro directorio donde están todos los módulos disponibles: mods-available. Es tan sencillo como crear los enlaces (“ln”) o usar la utilidad a2enmod.

Para cargar el módulo de SSL: a2enmod ssl

apache2 Ubuntu
apache2 Ubuntu

Read more

Aumentar número máximo de ficheros abiertos por Apache

En un servidor en producción con bastante carga puede ocurrir errores tipo “Too many open files” o algo parecido. Se debe a que en Linux se pueden establecer limites de ficheros abiertos simultaneamente y ésta limitación es por usuario. Para solucionarlo hay que cambiar la configuración en varios sitios, pero primero hay que comprobar la configuración actual:

# ulimit -n

esto nos indicará la cantidad máxima por usuario y sessión. El valor por defecto es 1024, lo que no es suficiente para Apache y Tomcat, ya que trabajan con muchos ficheros temporales y los necesita mantener abiertos por questiones de rendimiento. Para cambiar este valor:

#ulimit -n 75000

Este comando aplicará el cámbio en terminos de la sesión actual. Para hacerlo persistente tenemos que editar los limites a nivel de configuración del sistema:

Read more

Configurar LDAP y LDAPS en Apache

Aquí están los tutoriales explicativos de cómo se configura un servidor web Apache para que los usuarios se autentique contra un LDAP.

El servidor web podrá hacerlo mediante protocolo LDAP, sin autenticación de servidor (sin confianza) y en claro mediante usuario y password. Pero también podrá requerir, mediante LDAPS, confianza en el servidor mediante certificado y cifrado SSL.

Configuring LDAP authentication for a resource in virtual hosts

In this part, defining the AuthLDAPURL value is the most complex task because it combines many parameters into a single, nondescriptive error-prone line. Also, this is the only place that contains values that are Active Directory-specific: the baseDN must match the domain controllers setup, the search attribute and the objectclass definition must be set as shown. The example below shows a whole authentication setup for a directory resource in a virtual host. The comments are meant to make the configuration self-explaining.

Read more

Rotado de logs en CENTOS/RHEL. Ejemplo con apache

Y como queremos seguir promoviendo CENTOS/RHEL hoy vamos a hablar del rotado de logs en estas distribuciones.

Pues vienen perfectamente preparadas con una utilidad de rotado de logs llamada logrotate.

Por defecto este programa se ejecuta diariamente, no como servicio, sino a través de /etc/cron.daily. Aquí encontraremos un script similar a éste:

#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate “ALERT exited abnormally with [$EXITVALUE]”
fi
exit

Es decir, toma la configuración del archivo logrotate.conf, donde definimos lo que queremos rotar y bajo qué condiciones:

# see “man logrotate” for details
# rotate log files weekly
weekly
# keep 24 weeks worth of backlogs. 6 MESES de logs
rotate 24

En estas sentencias definimos la configuración por defecto. Por ejemplo en este caso, aunque logrotate se ejecute diariamente, hemos definido que los logs se roten por defecto semanalmente. Muy importante es también “rotate 24”, donde definimos que queremos 24 archivos de log, que al haberse rotado semanalmente tenemos histórico de 24 semanas (6 meses de logs en la máquina).

Read more