Por supuesto la segunda opción es mucho mas rápida y agiliza mucho el proceso de crear la misma configuración en diferentes máquinas Vyatta pero lleva consigo riesgos añadidos ya que los comandos se ejecutarán directamente y se pondrán en funcionamiento si posibilidad previa de prueba y error, por lo que recomiendo este método solo para usuarios expertos en Vyatta y que sepan muy bien lo que hacen y lo que van a configurar.

Vamos con un ejemplo de demostración:

Imaginemos que queremos implementar una nueva regla de firewall idéntica en cada una de nuestras máquinas Vyatta remotas, dicha regla permitirá el acceso SSH desde la LAN hacia el exterior, sabemos que la interfaz LAN de nuestras máquinas Vyatta remotas tiene aplicada un conjunto de reglas de firewall llamado LANin y que la regla 18 no está en uso (cuidado de no machacar reglas existentes y en funcionamiento). Creamos, en la máquina que vamos a usar para conectar por SSH a las remotas, un fichero de texto plano con el nombre que queramos y lo editamos para almacenar en él la lista de comandos necesarios, quedando algo así:

hnoguera@ubdesktop:~$ cat firewall-cmd
configure
edit firewall name LANin rule 18
set action accept
set destination port 22
set protocol tcp
set state new enable
commit
save
exit
exit
exit

Una vez tenemos el fichero con la lista de comandos almacenada lo mejor sería asegurarse de que exactamente esos comandos tendrán el efecto deseado. Una vez seguros lo único que queda es lanzar a cada uno de nuestros hosts Vyatta remotos el fichero por SSH usando el parámetro -tt:

hnoguera@hnoguera-ubdesktop:~$ ssh -p 22 -tt user@host-remoto1 < firewall-cmd
hnoguera@hnoguera-ubdesktop:~$ ssh -p 22 -tt user@host-remoto2 < firewall-cmd
hnoguera@hnoguera-ubdesktop:~$ ssh -p 22 -tt user@host-remoto3 < firewall-cmd

y así con todos los hosts Vyatta remotos.

Donde:

-p -> es para especificar el puerto SSH en el que escucha el servidor SSH del host Vyatta a conectar (si es el 22 por defecto no hace falta incluir esta opción).
user -> usuario local en Vyatta con privilegios de administrador.
host-remoto -> FQDN o IP del host Vyatta remoto.
-tt -> fuerza la asignación tty necesaria.

Como podéis ver, echándole imaginación puede resultar un recurso sencillo y tremendamente útil.

Creeis que un script del tipo...

#!/bin/bash

for i in `cat ip.lst` ; do 
     ssh -tt user@${i} "<
EOF
"
done

...valdría para tener la lista de IPs de hosts Vyatta remotos en el fichero ip.lst y hacerlo todo a la vez de un plumazo??


Fuente: foro de la comunidad Vyatta

Can, revolucionarios a finales de los 60 y durante la década de los 70 fue una de las bandas más importantes del movimiento Kraut Rock rock
psicodélico y experimental surgido en Alemania Occidental y que sirvió de fuerte influencia para muchas otras vertientes musicales posteriores.

Aquí os dejo Vitamin C, una joya, un tema del 72 que forma parte de su cuarto disco Ege Bamyasi, ornamentado con un video de nosequien incapaz de dejarte indiferente.


Muchas gracias por la contribución JuanPe!

netstat -plan|grep :80|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1

Si quieres saber como funcionan los ataques DoS y DDoS aquí tienes un interesante artículo de Vinagre Asesino

tar -zcvf nombre-nuevo-archivo-comprimido.tar.gz /ruta/directorio-a-comprimir

Pero si queremos comprimir un directorio excluyendo alguno de sus subdirectorios el comando sería:

tar -zcvf nombre-nuevo-archivo-comprimido.tar.gz --exclude='/ruta/directorio-a-comprimir/subdirectorio-a-excluir' --exclude='/ruta/directorio-a-comprimir/subdirectorio-a-excluir-2' /ruta/directorio-a-comprimir

Como dijimos en Que es Vyatta, el sistema Vyatta VC6.2, VC6.3 o VC6.4 se basa en Debian Squeeze, por lo que los pasos de configuración para agregar los repositorios correctos a nuestras máquinas son:

1 – Agregar el repositorio a la configuración de Vyatta:

vyatta:~# configure
[edit]
root@vyatta# set system package repository squeeze components main
[edit]
root@vyatta# set system package repository squeeze url http://ftp.es.debian.org/debian
[edit]
root@vyatta# set system package repository squeeze distribution squeeze
[edit]

2 – Commit para poner en funcionamiento los cambios hechos a la configuración:

root@vyatta# commit
Adding new entry to /etc/apt/sources.list...
[edit]

3 – Actualizamos los repositorios:

root@vyatta# aptitude update

Get:1 http://ftp.es.debian.org/debian squeeze Release.gpg [1033B]
Get:2 http://packages.vyatta.com stable Release.gpg [71B]
Get:3 http://ftp.es.debian.org/debian squeeze Release [73.8kB]
Get:4 http://packages.vyatta.com stable Release [1500B]
Get:5 http://packages.vyatta.com stable/main Packages [83.5kB]
Get:6 http://ftp.es.debian.org/debian squeeze/main Packages [6720kB]

Fetched 6880kB in 21s (322kB/s)

Reading package lists... Done
Current status: 38 updates [+38], 21985 new [+21984].
[edit]

Tras esto podremos instalar en Vyatta cualquier software Debian desde los repositorios.

Nota: Para instalar nuevo software en Vyatta se recomienda hacerlo en una máquina de pruebas. Una VM para tal efecto es perfecta, tanto en cuanto a la velocidad de despliegue como en cuanto a la facilidad de eliminarla y volver a empezar de cero.

01/06/2012

Vyatta está preparado para hacer de webproxy de una red local, funcionamiento que se lleva a cabo:

• Mediante un proceso de filtrado web y otro de almacenamiento en cache de paginas webs (webfiltering + webcache).
  
  Durante el filtrado web la máquina Vyatta gestionará los accesos web según la configuración dada, permisos a grupos, horarios, permisos por IP, etc.
  Durante el almacenamiento en cache la máquina Vyatta guarda las respuestas de páginas webs hechas a los servidores webs que han pasado el filtro anterior, lo que permite que para sucesivas solicitudes de las mismas páginas éstas sean entregadas al cliente web directamente de la copia almacenada en cache sin tener que volver a solicitarla al servidor web. Por tanto este proceso permite un ahorro de ancho de banda de Internet ya que evita múltiples solicitudes redundantes.
  
  

• Por otro lado dicho webproxy puede funcionar de forma transparente o de forma no transparente.
  
  La configuración por defecto es como proxy transparente, esto significa que el sistema automáticamente intercepta y redirige todo el tráfico HTTP (puerto 80) al servidor proxy web (que por defecto escucha en el puerto 3128), el cual gestiona cada una de las conexiones llevando a cabo todo el proceso descrito en los puntos anteriores. Esta configuración de Vyatta como webproxy transparente permite que no haya que configurar uno por uno los equipos de la red para que hagan sus solicitudes de conexión web a un proxy.
  
  También es posible hacer que Vyatta actúe como webproxy no transparente, lo que se consigue con el comando “set service webproxy listen-address disable-transparent”. Esta configuración deshabilita la captura de tráfico HTTP que vaya al puerto 80, dicho tráfico habría que dirigirlo al puerto 3128 del sistema Vyatta configurando uno a uno los equipos de la red. Una configuración mucho más tediosa pero a la vez más segura, ya que mucho del malware que se transmite por web no está preparado para saltarse este tipo de restricción. Por otra parte, la configuración de webproxy en modo no transparente también permite gestionar el tráfico a URLs seguras por HTTPS (puerto 443) mediante el webproxy. Ver un poco mas abajo la explicación del tráfico HTTPS.
  
  

A partir de aquí es necesario tener en cuenta:

• Si tenemos configurado y habilitado el firewall en la interfaz o interfaces que va a usar el servicio de webproxy tenemos que permitir el acceso a puerto 3128 TCP con destino local a dicha interfaz, tanto si hemos configurado un webproxy transparente como no transparente.
  Por ejempo:
  
  

  vyatta@R1# show firewall name eth0local
  ...
     rule X {
         action accept
         destination {
              port 3128
         }
         protocol tcp
         state {
              new enable
         }
     }
  ...

  
  

• El tráfico de navegación segura HTTPS (puerto 443) no puede ser gestionado por el webproxy de Vyatta Core cuando está configurado en modo transparente debido a la encriptación TLS que lleva la sesión, por lo tanto, las opciones para permitir o inhibir las conexiones HTTPS son:
  
  

  • Gestión por firewall, podemos crear un grupo de direcciones IPs correspondientes a los servidores webs seguros a los que permitimos conectar y crear una regla similar a:
    
    

    vyatta@R1# show firewall group address-group HTTPS
    	address x.x.x.x
    	address y.y.y.y
    	address x.x.y.y
    	address y.y.x.x
    ...
    vyatta@R1# show firewall name eth0in
    ...
       rule X {
           action accept
           destination {
                group {
    		address-group HTTPS
    	    }
                port 443
           }
           protocol tcp
           state {
                new enable
           }
       }
    ...
    vyatta@R1# show interfaces ethernet eth0 firewall
    	in {
    	   name eth0in
    	}
    	local {
    	   name eth0local
    	}
    

    
    

  • Pagar una versión Vyatta Plus que permite gestionar por el webproxy también el tráfico HTTPS en modo transparente. También ofrece numerosas ventajas de seguridad en cuanto a clasificación de URLs maliciosas para bloqueo por categorías.
    
    

• La versión Core de Vyatta ofrece una lista negra en la que de forma comunitaria se adjuntas IPs peligrosas, con intenciones maliciosas, etc. Esta lista está dividida en categorías, que pretenden englobar IPs de servicios webs de potencial peligrosidad o encuadrables en categorías que permitan dar acceso o limitarlo a dichas categorías, drogas, adultos, malware, ads…
  
  

• El funcionamiento de una conexión web filtrada en Vyatta desde un cliente se hace en dos pasos, en el primero el cliente hace la solicitud de una web en cuestión y en la segunda el webproxy gestiona la conexión y establece una nueva desde Vyatta hasta el destino, por lo que en realidad es la máquina Vyatta quien sirve la página al cliente y el también quien solicita la página al servidor.
  

vyatta$ configure
vyatta# set system package repository lenny components main
vyatta# set system package repository lenny url http://archive.debian.org/debian
vyatta# set system package repository lenny distribution lenny
vyatta# commit
vyatta# aptitude update 
vyatta# cd /tmp
vyatta# wget http://packages.vyatta.com/vyatta-dev/larkspur/unstable/pool/main/linux-vyatta-kbuild_2.6.32-1+vyatta+42+larkspur11_i386.deb
vyatta# dpkg -i linux-vyatta-kbuild_2.6.32-1+vyatta+42+larkspur11_i386.deb
vyatta# cd /usr/src
vyatta# ln -s linux-image/debian/build/build-i386-none-586-vyatta linux
vyatta# ln -s linux-image/debian/build/build-i386-none-586-vyatta linux-headers-2.6.31-1-586-vyatta 
vyatta# apt-get install build-essential
vyatta# apt-get install make gcc gcc-4.2 gcc-4.3
vyatta# cd /tmp
vyatta# wget http://www.openredes.com/wp-content/files/AR81Family-linux-v1.0.1.14.tar.gz
vyatta# tar zxvf AR81Family-linux-v1.0.1.14.tar.gz 
vyatta# cd src/
vyatta# make
vyatta# make install
vyatta# cp /tmp/src/atl1e.ko /lib/modules/$(uname -r)/kernel/drivers/net/atl1e
vyatta# modprobe atl1e
vyatta# exit
vyatta$ exit

Mas información de la vulnerabilidad en concreto está disponible en esta página del NIST (National Institute of Standards and Technology).

Instrucciones de actualización de sistemas Vyatta:

• Usuarios de sistemas VC6.1 y anteriores: se recomienda actualizar a versiones VC6.2, VC6.3 o VC6.4
  

• Usuarios de sistemas VC6.2 o VC6.3 pueden parchear el sistema instalando los paquetes openssl y libssl0.9.8 de los repositorios debian security con los comandos siguientes:
  
  
  

vyatta$ configure
vyatta# set system package repository debian-security components main
vyatta# set system package repository debian-security distribution squeeze/updates
vyatta# set system package repository debian-security url http://security.debian.org/debian-security
vyatta# commit
vyatta# save
vyatta# exit
vyatta$ sudo apt-get update
vyatta$ sudo apt-get install openssl libssl0.9.8
vyatta$ reboot 

Como se puede apreciar en la página de descargas de la comunidad Vyatta esta vez solo ofrecen una iso lista para instalar en máquinas x86 físicas y una iso genérica para hypervisores. Ambas en versiones tanto de 32 como de 64 bits, pero al igual que en VC6.3 la versión de 64 bits sigue siendo experimental.

Toda la información de cambios y nuevas funciones de Vyatta Network OS 6.4 aquí.

Notas oficiales de la versión Vyatta Network OS 6.4