Debian Chile

Ahora que ya tenemos configurado los hosts a monitorear identifiquemos con una imagen en su icono y status map.

Editemos el archivo /etc/nagios3/server.cfg previamente creado con los parametros de configuracion de host, donde debemos agregar las siguiente lineas

icon_image base/server.gif
statusmap_image base/server.gd2

Existe una lista de iconos en /usr/share/nagios3/htdocs/images/logos/ el cual solo se referencia el subdirectorio dentro de "logos"

A modo de ejemplo:

############################################################
# Switch Core
define host{
use generic-host
host_name switch-core
alias Switch Core
icon_image base/ng-switch40.gif
statusmap_image base/ng-switch40.gd2
address 192.168.88.3
check_command check-switch-alive
max_check_attempts 20
notification_interval 60
notification_period 24x7
notification_options d,u,r
}

#############################################################
# Configuracion Server1
define host{
use generic-host
host_name server1
alias Server Linux 1
icon_image base/redhat.gif
statusmap_image base/redhat.gd2
address 192.168.88.4
parents switch-core
check_command check-host-alive
max_check_attempts 20
notification_interval 60
notification_period 24x7
notification_options d,u,r
}

Realizamos un reload al servicio

nagios-debian:~# invoke-rc.d nagios3 reload

Ahora hacemos un refresh en el monitor de nagios y veremos las imagenes de cada uno de los hosts.

Ahora a configurar nuestro servidor Nagios para monitoreo remoto, luego realizaremos configuracion del cliente nrpe para monitorear recursos locales.

1.- Editamos el archivo /etc/nagios3/nagios.cfg agregando el nuevo archivo de configuracion.

# Servidores a Monitorear
cfg_file=/etc/nagios3/server.cfg

2.- Dentro del archivo de configuracion de nagios.cfg se debe habilitar el chequeo de comandos externos

check_external_commands=1

Por defecto en la instalacion el comando /var/lib/nagios3/rw/nagios.cmd que nos permite realizar chequeos a traves del browser queda con owner nagios:nagios es por eso que debemos modificar esto dandole permisos para que el usuario de nuestro apache si pueda ejecutarlo, esto lo arreglamos con:

nagios-debian:~# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw

nagios-debian:~# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3

Ahora es necesario reiniciar nagios que tome los cambios, no olvidar crear el archivo server.cfg

nagios-debian:~# invoke-rc.d nagios3 restart
Restarting nagios3 monitoring daemon: nagios3
.

2.- Editamos archivo server.cfg dentro de /etc/nagios3

vi /etc/nagios3/server.cfg

Y comenzamos a crear el hosts a monitorear

a modo de ejemplo:

############################################################
# Switch Core
define host{
use generic-host
host_name switch-core
alias Switch Core
address 192.168.88.3
check_command check-switch-alive
max_check_attempts 20
notification_interval 60
notification_period 24x7
notification_options d,u,r
}
#############################################################
# Configuracion Server1
define host{
use generic-host
host_name server1
alias Server Linux 1
address 192.168.88.4
parents switch-core
check_command check-host-alive
max_check_attempts 20
notification_interval 60
notification_period 24x7
notification_options d,u,r
}

Una vez agregado todos los servidor a monitorear reiniciar o reload a nagios

nagios-debian:~# invoke-rc.d nagios3 reload
Reloading nagios3 monitoring daemon configuration files: nagios3.

Finalmente deberian tener algo asi.

Instalando componentes

nagios-debian:~# apt-get install nagios3

Nos preguntara una password para nuestro administrador de nagios y autoconfigurara configuracion de apache, ahora puedes ver la instalacion por defecto en http://localhost/nagios3

Si no recuerdas la clave ingresada, puedes crearla nuevamente con el comando htpasswd, este comando lo utilizaremos para crear usuarios con distintos perfiles en el sistema como es un administrador u operador.

nagios-debian:/etc/nagios3# htpasswd htpasswd.users nagiosadmin

New password:
Re-type new password:
Updating password for user nagiosadmin


* Todo la instalacion la estoy realizando con debian testing.

Una red privada virtual (VPN) es usada para establecer una conexión encriptada, punto-a-punto, entre dos computadores. El uso más común de una VPN es para exportar en forma remota aplicaciones X, o incluso el escritorio completo del servidor. Por ejemplo, podemos correr en el computador de casa aplicaciones o el escritorio del servidor del trabajo.

El escritorio se puede levantar en forma remota con XDMCP, de hecho es la manera de usarlo dentro de una red interna, pero cuando la conexión viaja por Internet, en donde no se puede suponer que existe privacidad alguna, una VPN es la manera de asegurarlo.

En la configuración a continuación, el servidor remoto y computador local (cliente) pueden ser intercambiados sin mayores consideraciones.

Instalando y configurando OpenVPN

Instala el paquete openvpn en servidor y cliente,

# apt-get install openvpn


Genera una llave secreta,

# openvpn --genkey --secret /etc/openvpn/static.key


en uno y copiala en forma segura al segundo, por ejemplo, con Secure Copy,

# scp -p /etc/openvpn/static.key root@servidor.debian:/etc/openvpn/


En el servidor remoto (el que va a servir el escritorio), crea el archivo /etc/openvpn/tun0.conf y agrega,

dev tun0
ifconfig 10.9.8.1 10.9.8.2
secret static.key


Los números IP 10.x.x.x pueden modificarse a gusto. Lo importante es asignarle, dentro de una misma subred (10.x.x), un IP a cada computador. La llave secreta se encarga que solo aquellos computadores que tienen la llave puedan crear el túnel. Por eso es importante proteger la llave bien (como cualquier otra llave encriptada). En este caso, 10.9.8.1 es el IP del servidor remoto, 10.9.8.2 el IP del cliente.

En el computador cliente (local), crea también el archivo /etc/openvpn/tun0.conf y agrega,

remote 100.10.2.10
dev tun0
ifconfig 10.9.8.2 10.9.8.1
secret static.key


en donde "remote" es el IP público del servidor remoto. En la configuración del cliente, los IPs asignados van revertidos.

Inicia el servidor OpenVPN en servidor remoto y cliente,

# /etc/init.d/openvpn start

El servidor OpenVPN va a crear en ambos una interfase de red llamada tun0,

# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.9.8.2  P-t-P:10.9.8.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


que hay que tratar igual que una interfase de red normal. En particular, hay que incluirla en el cortafuegos. Usa como guía la versión servidor de http://man-es.debianchile.org/cortafuego.html.

Edita /etc/network/if-pre-up.d/firewall y agrega en la cadena INPUT,

  # VPN
  $IPTABLES -A INPUT -i tun0 -s 10.9.8.1 -j ACCEPT


en el cliente y,

  # VPN
  $IPTABLES -A INPUT -i tun0 -s 10.9.8.2 -j ACCEPT


en el servidor.

Es también necesario abrir el puerto 1194 UDP en la interfase externa. Edita /etc/network/if-up.d/firewall y agrega,

  # VPN
  $IPTABLES -A pqtes-udp-permitidos -p UDP -m state --state NEW --dport 1194 -j ACCEPT


El cortafuegos se puede reiniciar con,

# export IFACE=lo ; /etc/network/if-pre-up.d/firewall ; export IFACE=eth0 ; /etc/network/if-up.d/firewall


Eso es todo. Ahora prueba conexiones desde el cliente hacia el servidor remoto, por ejemplo,

$ ping -c3 10.9.8.1
PING 10.9.8.1 (10.9.8.1) 56(84) bytes of data.
64 bytes from 10.9.8.1: icmp_seq=1 ttl=64 time=25.2 ms
64 bytes from 10.9.8.1: icmp_seq=2 ttl=64 time=28.2 ms
64 bytes from 10.9.8.1: icmp_seq=3 ttl=64 time=27.0 ms

--- 10.9.8.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 25.274/26.834/28.206/1.204 ms


De aquí en adelante establece cualquier conexión privada con el IP 10.9.8.1.

El wiki OpenVPN muestra como exportar el escritorio del servidor remoto.

(Editado por admin)

Instalación de Zeitgeist y GNOME Activity Journal.-

1.- Qué es Zeitgeist y GNOME Activity Journal?

Zeitgeist y GNOME Activity Journal son una de las tantas maravillas que traerá Gnome 3, básicamente consiste en una utilidad/herramienta que nos permitirá/ayudará a encontrar archivos en nuestro equipo de una manera bastante “novedosa”, ya que está enfocado a búsquedas según:

• Tipo de datos
• Fuente
• Tiempo
• Nombre
• Etiquetas (Tags)
• Archivos similares
• Comentarios
• Localizacion de uso(GPS)

2.- Instalamos lo necesario:

Caturra:/# apt-get install bzr gnome-common

3.- Bajando e instalando Zeitgeist.-

La verdad es que puede ser en cualquier directorio, lo elegí /usr/local/src/ porque pienso ir actualizándolo para usarlo seguido,

# cd usr/local/src/
# mkdir Gnome3
# cd Gnome3/
# bzr get lp:zeitgeist; bzr get lp:gnome-activity-journal


4.- Ejecutar:

Como $USER ejecutamos lo siguiente:

$ ./zeitgeist-daemon.py &
$ ./gnome-activity-journal

Con eso levantamos, para sacarle el máximo provecho hacemos:

# cd usr/local/src/Gnome3/zeitgeist/
# ./autogen.sh
# make
# make install

PD: He omitido la salida por ser innecesaria.

Con esto tenemos listo, lo que nos crea dos comandos:

zeitgeist-daemon zeitgeist-datahub

Y listoco, ahora para ahorrarnos algunas cosas lo automatizamos:

Vamos a:

Sistema ==> Preferencias ==> Aplicaciones

Al inicio le damos a “Añadir” y agregamos:

Nombre: Gnome Zeitgeist
Comando: zeitgeist-daemon
Comentario: Nice

Con esto tenemos el demonio listo, agregamos GNOME Activity Journal al Menú: para lo cual usamos “alacarte”.

5.- Actualizamos el código regularmente:

Creamos un archivo con el nombre que queramos, con algo similar a esto, es bastante rudimentario pero sirve,

#!/bin/bash
cd /usr/local/src/Gnome3/zeitgeist/ && bzr pull && sh autogen.sh && make && make install &&
cd /usr/local/src/Gnome3/gnome-activity-journal/ && bzr pull


Le damos permiso de ejecución y lo alojamos en /etc/cron.daily o pueden usar `crontab -e`, etc.

Acá tienen un ejemplo de Zeitgeist y GNOME Activity Journal en su máxima expresión.

http://seilo.geekyogre.com/2010/01/a-mockup-is-worth-a-thousand-lines-of...

Eliminando e instalando paquetes en el sistema comenzamos a generar una serie de componentes (mucha de esas simples configuraciones) en nuestro sistema que nunca jamas volvemos a utilizar, para saber que esta instalado y no usamos podemos realizar el siguiente comando:

debian:~# dpkg -l | grep -v ^ii | awk '{print $2}' | sed '1,5d'

y si el resultado lo queremos eliminar bastaria enviando la salida a un dpkg --purge

debian:~# dpkg -l | grep -v ^ii | awk '{print $2}' | sed '1,5d'|xargs dpkg --purge

Espero sea de utilidad.

Recientemente hice una modificación pequeña a la configuración de Exim4 para eliminar ataques de diccionario. La modificación fue tan exitosa que la publiqué en el Blog,

http://www.debianchile.org/?q=node/135

La configuración descrita impone una demora de dos minutos si el IP intenta repartir más de un correo a un receptor inexistente, dentro de ese lapso. En un periodo menor a una semana habían cesado todos los ataques de diccionario.

Quedé sorprendido que una simple demora de dos minutos hiciera desistir a spameros de atacar mi sitio. Esta demora debe ser costosa. ¿Por que? Este es mi razonamiento: Los spameros basan su éxito en la teoría de probabilidades. Si bien la probabilidad de éxito (lograr que un SPAM pase todos los escrutinios de Exim y Spamassassin) es bastante baja, la cantidad de pruebas, número bien grande, hace que al fin se cuelen uno que otro SPAM. En eso consiste el éxito de un spamero. El número importante es entonces el máximo de conexiones posible que el servidor del spamero puede establecer. Ese número es grande, pero no infinito. Si Exim mantiene por dos minutos la conexión abierta, a la espera, para después responder que deniega la conexión, el costo de la demora se torna inaceptable para el spamero si dentro de esos dos minutos puede en vez hacer miles de otros intentos. Ese es el motivo por el cual una pequeña demora se torna tan costosa.

He encontrado varios puntos en la configuración de Exim en donde insertar una leve demora hace desistir otros ataques recurrentes, o al menos disminuirlos.

Edita el archivo /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt y modifica según descrito.

1. DNSBL
   
   

   # DNS blacklist
drop
   log_message = listed by $dnslist_domain
   dnslists = bl.spamcop.net : b.barracudacentral.org : zen.spamhaus.org : dnsbl.sorbs.net
   delay = 2m


   Esta modificación impone una demora de dos minutos si el sitio ya está marcado por una lista negra DNS y puede aplicarse en cualquier punto a partir de aceptar una conexión autenticada,

   accept
   authenticated = *
   control = submission/sender_retain


   Aplicarla antes de la autenticación puede bloquear a usuarios locales que envían correo desde redes dinámicas (que generalmente están todas en listas negras DNS).

2. Intentos de relay.

   Modifica,

   require
   message = relay not permitted
   domains = +local_domains : +relay_to_domains


   por,

   drop
   message = relay not permitted
   !domains = +local_domains : +relay_to_domains
   delay = 2m


   Es en el fondo la misma regla, excepto a que bota inmediatamente el mensaje, imponiéndole la demora a quien intente usarnos ilegalmente como relay.

3. Verificación de dirección.
   
   

   # .ifdef CHECK_RCPT_VERIFY_SENDER
   deny
     message = Sender verification failed
     !acl = acl_local_deny_exceptions
     !verify = sender
     delay = 2m
# .endif


   Eficiente para aquellos intentos que usan emisor con dominio falso, inexistente o inventado.

4. Receptor verificable.

   Modifica,

   require
   verify = recipient


   por,

   drop
   !verify = recipient
   delay = 2m


   Es en el fondo la misma regla, excepto a que bota inmediatamente el mensaje si el receptor no existe, imponiéndole además la demora.

Todas estas modificaciones hay que usarlas con cuidado, porque Exim tiene un máximo de 25 conexiones simultaneas. Si el sitio es atacado a una tasa alta, las demoras pueden fácilmente agotar las conexiones y botar no solo SPAM, sino también correo legítimo. Una buena práctica es ir insertando las modificaciones una a la vez e ir monitoriando el efecto, porque la tasa de ataques irá disminuyendo con cada una de ellas, pero a medida que transcurra el tiempo.

Hecha cualquier modificación, actualiza la configuración y reinicia el servidor,

# update-exim4.conf
# /etc/init.d/exim4 restart


Un nuevo depósito ha surgido a partir del otrora Debian Unofficial. Este nuevo depósito, llamado "Unofficial Maintainers", distribuye como antes paquetes no oficiales que, por motivo de licencia o restricciones varias, no se encuentran en el depósito oficial de Debian. Incluye software como,

lame
libdvdcss
xvidcore
mplayer-codecs
ttf-microsoft
flash-player
opera
skype


entre otros. Muchos de estos son también parte de Debian Multimedia, aunque no todos.

Debian Chile mantiene una réplica en,

http://apt.debianchile.org/debian-unofficial

La manera de usarlo es como de costumbre. Inserta en /etc/apt/sources.list,

deb http://apt.debianchile.org/debian-unofficial lenny/backports main contrib non-free restricted


También se puede usar la versión sid o unstable. Está anunciada una estructura para Squeeze (testing), pero ésta vendrá más adelante.

El antiguo depósito Debian Unofficial, que dejó de actualizarse hace mucho, ha sido movido a,

http://apt.debianchile.org/debian-archive

para aquellos que aún lo usan con Sarge o Etch.

Escenario: tengo un servidor remoto con conexion PPP? cambio la IP? = perdi conectividad para controlar el servidor, que hacemos?

Creemos un script que nos diga cual es la nueva ip :)

#!/bin/bash

set -e -u

MAILTO='sysadmin@dominio.cl'
IPADDR=`ifconfig | egrep -A 1 '^ppp[0-9]' | grep 'inet addr:' | awk '{print $2}' | sed -e 's/.*://'`

echo "[${IPADDR}]" > /etc/mailname
postfix reload

mail -s "`date`: Servidor PEPITO cambio de direccion IP!" ${MAILTO} < El servidor PEPITO (VPN) tiene la direccion IP: ${IPADDR}

EOF

Scrip que a traves de MASQUERADE envia trafico de una Pequeña LAN a la LAN principal, esto se podria realizar con VPN (ipsec, openvpn, openswan, etc).

#!/bin/bash

modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

iptables -F
iptables -F -t nat
iptables -F -t mangle

iptables -X
iptables -X -t nat
iptables -X -t mangle

case "$1" in
start|"")
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -d 192.168.1.255 -j DROP #Eliminamos broadcast de la LAN
iptables -A INPUT -d 255.255.255.255 -j DROP
iptables -A INPUT -p tcp --dport 135 -j DROP #Eliminamos a M$ :)
iptables -A INPUT -p udp --dport 137 -j DROP
iptables -A INPUT -p udp --dport 138 -j DROP
iptables -A INPUT -p tcp --dport 139 -j DROP
iptables -A INPUT -p tcp --dport 445 -j DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
iptables -A INPUT -i icmp -j ACCEPT
iptables -A INPUT -j LOG --log-prefix 'REJECT INPUT: '
iptables -A INPUT -j REJECT

iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state NEW -j ACCEPT
iptables -A OUTPUT -j LOG --log-prefix 'REJECT OUTPUT: '
iptables -A OUTPUT -j REJECT

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state NEW -j ACCEPT
iptables -A FORWARD -j LOG --log-prefix 'REJECT FORWARD: '
iptables -A FORWARD -j REJECT

iptables -t nat -A POSTROUTING -o ppp+ -s 192.168.1.1 \
-d ! 172.16.32.0/24 -j MASQUERADE #Enviamos a nuestra LAN Principal
;;
stop)
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
;;
esac