Saltar al contenido

Linux

How To Disable ipv6 Fedora 17/18

Source: http://lifeofageekadmin.com/how-to-disable-ipv6-fedora-1718/

IPV6 is coming, but it is not here yet, so say you want to disable it on your Fedora 18 system. Pretty simple to do. First let’s edit the /etc/sysctl.conf file.

$ sudo vi /etc/sysctl.conf

Add and save the changes

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

To eliminate the default ipv6 addresses still appear on the interfaces open a terminal and type

Type ifconfig to get the inet6 info and the adapter

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84  bytes 7100 (6.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 7100 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a00:27ff:fedc:5b71  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:dc:5b:71  txqueuelen 1000  (Ethernet)
        RX packets 234990  bytes 115274228 (109.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210670  bytes 40730873 (38.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
$ sudo ip addr del ::1/128 dev lo
$ sudo ip addr del fe80::a00:27ff:fedc:5b71/64 dev p2p1

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84  bytes 7100 (6.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 7100 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 08:00:27:dc:5b:71  txqueuelen 1000  (Ethernet)
        RX packets 235487  bytes 115320518 (109.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210678  bytes 40731473 (38.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Comment out ::1 in /etc/hosts

$ sudo vi /etc/hosts

# ::1 localhost

Autenticación en Apache: básica y PAM

  • admin 

FUENTE: http://blog.unlugarenelmundo.es/2010/03/13/autenticacion-en-apache-basica-y-pam/

 

El servidor web Apache puede acompañarse de distintos módulos para proporcionar diferentes modelos de autenticación. Hoy vamos a echarle un vistazo a la configuración básica de dos de los más utilizados y sencillos.

PRIMER METODO

La primera forma que veremos es la más simple. Usamos para ello el módulo de autenticación básica que viene instalada “de serie” con cualquier Apache. La configuración que tenemos que añadir en el fichero de definición del Virtual Host a proteger podría ser algo así:

<Directory "/var/www/miweb/privado">
Order deny,allow
AuthUserFile "/etc/apache2/claves/passwd.txt"
AuthName "Palabra de paso"
AuthType Basic
<Limit GET POST>
Require valid-user
</Limit>
</Directory>

La información a personalizar está marcada en negritas. En Directory escribimos el directorio a proteger, que puede ser el raíz de nuestro Virtual Host o un directorio interior a este. En AuthUserFile ponemos el fichero que guardará la información de usuarios y contraseñas que debería de estar, como en este ejemplo, en un directorio que no sea visitable desde nuestro Apache. Ahora comentaremos la forma de generarlo. Por último, en AutnName personalizamos el mensaje que aparecerá en la ventana del navegador que nos pedirá la contraseña. Existen otras directivas adicionales o modificaciones a estas útiles para personalizar el acceso: AuthGroupFile, Require user, Require group, etc.

El fichero de contraseñas se genera mediante la utilidad htpasswd. Su sintaxis es bien sencilla. Para añadir un nuevo usuario al fichero operamos así:

# htpasswd /etc/apache2/claves/passwd.txt carolina
New password:
Re-type new password:
Adding password for user carolina

Para crear el fichero de contraseñas con la introducción del primer usuario tenemos que añadir la opción -c (create) al comando anterior. Si por error la seguimos usando al incorporar nuevos usuarios borraremos todos los anteriores, así que cuidado con esto. Las contraseñas, como podemos ver a continuación, no se guardan en claro. Lo que se almacena es el resultado de aplicar una función hash.

josemaria:rOUetcAKYaliE
carolina:hmO6V4bM8KLdw
alberto:9RjyKKYK.xyhk

Para denegar el acceso a algún usuario basta con que borremos la línea correspondiente al mismo. No es necesario que le pidamos a Apache que vuelva a leer su configuración (/etc/init.d/apache2 reload) cada vez que hagamos algún cambio en este fichero de contraseñas, pero si lo es después de hacer los cambios en el fichero de definición del Virtual Host.

autenticación en apacheLa principal ventaja de este método es su sencillez. Sus inconvenientes: lo incómodo de delegar la generación de nuevos usuarios en alguien que no sea un administrador de sistemas o de hacer un front-end para que sea el propio usuario quien cambie su contraseña. Y, por supuesto, que dichas contraseñas viajan en claro a través de la red. Si queremos evitar esto último podemos crear una instancia Apache con SSL.

SEGUNDO METODO

El segundo método que vamos a tocar usa PAM, el propio sistema de autenticación de la máquina donde está instalado nuestro servidor de Apache. Si ya tenemos alguna herramienta de gestión de usuarios y contraseñas en la misma este sistema nos ahora el engorro de tener que generar otro tipo de usuario. En caso contrario no ganamos mucho en este sentido y seguimos teniendo el problema de que las contraseñas viajan en claro con el agravante adicional de que ahora se trata de usuarios de la máquina… así que ya sabéis: o configuráis ssl o usáis el truco que comentamos el otro día por aquí para deshabilitar la conexión remota.

Usaremos para ello el módulo mod_auth_pam y lo primero que tenemos que hacer es instalarlo:

# sudo apt-get install libapache2-mod-auth-pam

En el fichero de configuración del Virtual Host tendríamos que incluir algo así:

<Directory "/var/www/privado">
AuthType Basic
AuthName "Palabra de paso"
AuthPAM_Enabled On
AuthBasicAuthoritative Off
AuthUserFile /dev/null
Require user josemaria gemma fernando araceli
</code>

Si en este caso la directiva usada fuese Require valid-user se permitiría el acceso a cualquier usuario con cuenta en la máquina. Ah, y no olvides hacer un reload de apache después de este cambio.

Sólo nos quedan un par de pasos. Primero, añadir el usuario www-data (el que usa apache) al grupo shadow para que pueda verificar las contraseñas:

usermod -a -G shadow www-data

Y dos, hacer un enlace como el que sigue. Ignoro la causa, pero el motivo de que esto sea necesario es debido a que apache (en los binarios de Debian y Ubuntu, al menos) pretende leer del archivo /etc/pam.d/http mientras que el módulo de autenticación ha creado el archvo /etc/pam.d/apache2. El módulo auth_pam hace años que no está soportado e imagino que esto tiene algo que ver, pero no lo se a ciencia cierta. Simplemente lo leí por ahí…

ln -s /etc/pam.d/apache2 /etc/pam.d/httpd

Y con esto está todo listo. No lo he probado nunca pero también he leído que la autenticación se hace contra el directorio activo si Apache está instalado en una máquina windows configurada en un dominio. Existe también un módulo para autenticar contra un ldap (mod_auth_ldap).

Ejemplos de reglas IPTABLES

  • Muchas de las acciones que se listan abajo requieren ejecutarse como usuario root.
  • Los siguientes comandos deberían funcionar en cualquier distro linux moderna.
  • Esto NO es un tutorial de como configurar iptables.  Es más bien una referencia rápida de los comandos más comunes de iptables.

 

#1: Mostrando el estado de nuestro firewall

Teclea el siguiente comando como root:

iptables -L -n -v

Ejemplos de salidas:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

El resultado de arriba indica que el firewall no está activo. La siguiente salida es la del firewall activado:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
  394 43586 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
   93 17292 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
    1   142 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  br0    br0     0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
    0     0 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    0     0 wanin      all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0
    0     0 wanout     all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0
Chain OUTPUT (policy ACCEPT 425 packets, 113K bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain wanin (1 references)
 pkts bytes target     prot opt in     out     source               destination
Chain wanout (1 references)
 pkts bytes target     prot opt in     out     source               destination

Donde,

  • -L : Muestra las reglas.
  • -v : Muestra información detallada.
  • -n : Muestra la dirección ip y puerto en formato numérico. No usa DNS para resolver nombres. Esto acelera la lista.

#1.1:Para Inspeccionar el firewall con número de lineas:

iptables -n -L -v --line-numbers

Salida:

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
Chain FORWARD (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
2    DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID
3    TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
4    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
5    wanin      all  --  0.0.0.0/0            0.0.0.0/0
6    wanout     all  --  0.0.0.0/0            0.0.0.0/0
7    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
Chain wanin (1 references)
num  target     prot opt source               destination
Chain wanout (1 references)
num  target     prot opt source               destination

Podemos usar los números de línea para borrar o añadir nuevas reglas al firewall.

#1.2: Mostrar las reglas de cadena de entrada y salida:

iptables -L INPUT -n -v
iptables -L OUTPUT -n -v --line-numbers

#2: Parar / Iniciar / Reiniciar el firewall

Si usas CentOS / RHEL / Fedora linux:

service iptables stop
service iptables start
service iptables restart

También se puede usar propio comando iptables para detenerlo y borrar todas las reglas.

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Donde:

  • -F : Borra todas las reglas.
  • -X : Borra cadenas
  • -t table_name : Selecciona una tabla y elimina reglas
  • -P : Establece la política por defecto (como DROP, REJECT o ACCEPT)

#3: Borrar reglas del firewall

Para mostrar los números de línea junto a otra información para reglas existentes:

iptables -L INPUT -n --line-numbers
iptables -L OUTPUT -n --line-numbers
iptables -L OUTPUT -n --line-numbers | less
iptables -L OUTPUT -n --line-numbers | grep 202.54.1.1

Obtendrendremos la lista de IPs. Miramos el número de la izquierda y lo usamos para borrarla. Por ejemplo para borrar la línea 4:

iptables -D INPUT 4

O para encontrar una ip de origen y borrarla de la regla

iptables -D INPUT -s 202.54.1.1 -j DROP

Donde:

  • -D : Elimina una o más reglas de la cadena seleccionada.

#4: Insertar reglas:

Para insertar una o más reglas en la cadena seleccionada como el número de cadena dada usamos la siguiente sintaxis. Primero encontramos el número de línea:

iptables -L INPUT -n --line-numbers

Salida:

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  202.54.1.1           0.0.0.0/0
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED

Para insertar una regla entre 1 y 2;

iptables -I INPUT 2 -s 202.54.1.2 -j DROP

Para ver las reglas actualizadas

iptables -L INPUT -n --line-numbers

Salida:

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    DROP       all  --  202.54.1.1           0.0.0.0/0
2    DROP       all  --  202.54.1.2           0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED

#5: Guardar reglas

Para guardar reglas en CentOS / RHEL / Fedora Linux:

service iptables save

En este ejemplo, eliminamos una ip y guardamos las reglas del firewall:

iptables -A INPUT -s 202.5.4.1 -j DROP
service iptables save

Para todas las demás distros usamos:

iptables-save > /root/my.active.firewall.rules
cat /root/my.active.firewall.rules

#6: Restaurar reglas

Para restaurar reglas desde un archivo llamado /root/my.active.firewall.rules:

iptables-restore < /root/my.active.firewall.rules

Bajo CentOS / RHEL / Fedora Linux:

service iptables restart

#7: Estableces políticas de firewall por defecto

Para borrar todo el tráfico:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -L -v -n
## you will not able to connect anywhere as all traffic is dropped ###
ping cyberciti.biz
wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.2-rc5.tar.bz2

#7.1: Solo tráfico entrante bloqueado

Para borrar todos los paquetes entrantes / enviados pero permitir el tráfico saliente:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -L -v -n
# *** now ping and wget should work *** ###
ping cyberciti.biz
wget http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.2-rc5.tar.bz2

#8: Borrar direcciones de red privadas en la interfaz pública

IP Spoofing es nada más que para detener los siguientes rangos de direcciones IPv4 para redes privadas en sus interfaces públicas. Los paquetes con direcciones de origen no enrutables deben rechazarse mediante la siguiente sintaxis:

iptables -A INPUT -i eth1 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

#9: Bloqueando una direción IP (BLOCK IP)

PAra bloquear una ip atacante llamada 1.2.3.4:

iptables -A INPUT -s 1.2.3.4 -j DROP
iptables -A INPUT -s 192.168.0.0/24 -j DROP

#10: Bloquear peticiones entrantes de un puerto (BLOCK PORT)

Para bloquear todas las solicitudes de servicio en el puerto 80:

iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -i eth1 -p tcp --dport 80 -j DROP

Para bloquear el puerto 80 para una ip:

iptables -A INPUT -p tcp -s 1.2.3.4 --dport 80 -j DROP
iptables -A INPUT -i eth1 -p tcp -s 192.168.1.0/24 --dport 80 -j DROP

#11: Bloquear ips de salida

Para bloquear el tráfico saliente a un host o dominio en concreto como por ejemplo cyberciti.biz:

host -t a cyberciti.biz

Salida:

cyberciti.biz has address 75.126.153.206

Una vez conocida la dirección ip, bloqueamos todo el tráfico saliente para dicha ip así:

iptables -A OUTPUT -d 75.126.153.206 -j DROP

Se puede usar una subred como la siguiente:

iptables -A OUTPUT -d 192.168.1.0/24 -j DROP
iptables -A OUTPUT -o eth1 -d 192.168.1.0/24 -j DROP

#11.1: Ejemplo – Bloquear el dominio facebook.com

Primero, encontrar la dirección ip de facebook.com

host -t a www.facebook.com

Salida:

www.facebook.com has address 69.171.228.40

Buscar el CIDR para 69.171.228.40:

whois 69.171.228.40 | grep CIDR

Salida:

CIDR:           69.171.224.0/19

Para prevenir el acceso externo a facebook.com:

iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP

Podemos usar también nombres de dominio:

iptables -A OUTPUT -p tcp -d www.facebook.com -j DROP
iptables -A OUTPUT -p tcp -d facebook.com -j DROP

De la página del man de iptables:

… specifying any name to be resolved with a remote query such as DNS (e.g., facebook.com is a really bad idea), a network IP address (with /mask), or a plain IP address …

#12: Log y borrar paquetes

Escribe lo siguiente para añadir al log y bloquear IP spoofing en una interfaz pública llamada eth1

iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j LOG --log-prefix "IP_SPOOF A: "
iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

Por defecto el log está en el archivo /var/log/messages

tail -f /var/log/messages
grep --color 'IP SPOOF' /var/log/messages

#13: Log y borrar paquetes con un número limitado de entradas al log

El módulo -m limit puede limitar el número de entradas al log creadas por tiempo. Se usa para prevenir que el archivo de log se inunde. Para añadir al log y elminar spoofing cada 5 minutos, en ráfagas de 7 entradas:

iptables -A INPUT -i eth1 -s 10.0.0.0/8 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix "IP_SPOOF A: "
iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP

#14: Aceptar o denegar tráfico desde dirección MAC

iptables -A INPUT -m mac --mac-source 00:0F:EA:91:04:08 -j DROP
## *only accept traffic for TCP port # 8080 from mac 00:0F:EA:91:04:07 * ##
iptables -A INPUT -p tcp --destination-port 22 -m mac --mac-source 00:0F:EA:91:04:07 -j ACCEPT

#15: Bloquear o permitir peticiones ping ICMP

Para bloquear peticiones ping ICMP

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -j DROP

Las respuestas al ping también se puede limitar a ciertas redes o hosts.

iptables -A INPUT -s 192.168.1.0/24 -p icmp --icmp-type echo-request -j ACCEPT

Lo siguiente solo acepta limitados tipos de peticiones ICMP:

### ** assumed that default INPUT policy set to DROP ** #############
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
## ** all our server to respond to pings ** ##
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

#16: Abrir un rango de puertos

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 7000:7010 -j ACCEPT

#17: Abrir un rango de direcciones ip

## only accept connection to tcp port 80 (Apache) if ip is between 192.168.1.100 and 192.168.1.200 ##
iptables -A INPUT -p tcp --destination-port 80 -m iprange --src-range 192.168.1.100-192.168.1.200 -j ACCEPT
 
## nat example ##
iptables -t nat -A POSTROUTING -j SNAT --to-source 192.168.1.20-192.168.1.25

#19: Bloquear o abrir puertos comunes

Replace ACCEPT with DROP to block port:
## open port ssh tcp port 22 ##
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT

## open cups (printing service) udp/tcp port 631 for LAN users ##
iptables -A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 631 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 631 -j ACCEPT

## allow time sync via NTP for lan users (open udp port 123) ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT

## open tcp port 25 (smtp) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT

# open dns server ports for all ##
iptables -A INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT

## open http/https (Apache) server port to all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

## open tcp port 110 (pop3) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 110 -j ACCEPT

## open tcp port 143 (imap) for all ##
iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT

## open access to Samba file server for lan users only ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 445 -j ACCEPT

## open access to proxy server for lan users only ##
iptables -A INPUT -s 192.168.1.0/24 -m state --state NEW -p tcp --dport 3128 -j ACCEPT

## open access to mysql server for lan users only ##
iptables -I INPUT -p tcp --dport 3306 -j ACCEPT

#20: Restringir el número de conexiones paralelas a un servidor por direccion Ip del cliente.

Se puede usar connlimit para crear algunas restricciones. Para permitir 3 conexiones ssh por cliente:

iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT

Establecer las peticiones HTTP a 20:

iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j DROP

donde:

  • –connlimit-above 3 : Coincide si el número de conexiones existentes está por encima de 3.
  • –connlimit-mask 24 : Grupos de hosts usando el prefijo de longitud. Para IPv4, debe ser un número entre 0 y 32 (incluyéndolos.)

#21: HowTO: Use iptables Like a Pro

Para más información sobre iptables, échale un vistazo al manual:

man iptables

Para ver la ayuda en general o de un comando específico:

iptables -h
iptables -j DROP -h

#21.1: Probando nuestro firewall

Conocer si hay puertos abiertos o no:

netstat -tulpn

Es recomendable instalarse un sniffer como tcpdupm y ngrep para probar la configuración de nuestro firewall.

Conclusión

Esta entrada solo lista las reglas básicas para los usuarios nuevos en linux. Se pueden crear reglas más complejas. Requiere una buena comprensión de TCP/IP, tunning del kernel linux via sysctl.conf y un buen conocimiento de nuestra configuración.

Fuente original: cyberciti

Más reglas cortesía de Jker

a)a. Reestablece las reglas por defecto.

sudo su
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X

IPtables -nL para ver que estan vacias

b)b. Configura la máquina para que sólo se pueda acceder desde ella a las webs http://www.google.es y http://www.iesgoya.com y a ninguna otra.

iptables -A OUTPUT -d http://www.google.es -j ACCEPT
iptables -A OUTPUT -d http://www.iesgoya.com -j ACCEPT
iptables -A OUTPUT -p tcp –dport 80 -j DROP # Mas exigente –> iptables -A OUTPUT -p all -j DROP

##como google tiene muchas IPs puede que tengamos un problema para ello realizamos lo siguiente antes de la regla EXIGENTE:

iptables -I OUTPUT 1 -d 212.106.221.0/24 -j ACCEPT
iptables -I OUTPUT 1 -d 173.194.0.0/16 -j ACCEPT

# MOstrar las reglas que llevamos hasta el momento:

iptables -nL –line-numbers

#Si queremos borrar reglas:

iptables -D OUTPUT 5

c)c. Cierra todos los puertos bien conocidos menos los necesarios para acceder a estas dos webs.

iptables -A OUTPUT -p TCP –dport 53 -j ACCEPT
iptables -A OUTPUT -p UDP –dport 53 -j ACCEPT
iptables -A OUTPUT -p TCP –dport 1:1024 -j DROP
iptables -A OUTPUT -p UDP –dport 1:1024 -j DROP

d)d. Investiga de qué forma podrías hacer que las peticiones entrantes a tu máquina virtual al puerto 81 por http vayan mediante NAT al puerto 80 de la máquina local (arranca WAMP para comprobar que funciona).

Arrancamos wamp en la maquina fisica y comprobamos que accedemos a wamp desde localhost.
Comprobamos que podemos acceder desde la maquina virtual y se encuentra cortado

Miramos la IP de la maquina virtual.
Ahora desde la maquina fisica intentamos acceder desde el puerto 81 con la IP esa.

Habilitamos el enrutamiento entre tarjetas de red de nuestro equipo:

echo 1 > /proc/sys/net/ipv4/ip_forward

#Ejecutamos las siguientes reglas

iptables -t nat -A PREROUTING -p tcp –dport 81 -j DNAT –to- destination 192.168.203.200:80

iptables -t nat -A POSTROUTING -s 192.168.203.0/24 -j MASQUERADE

#Para ver las reglas introducidas:

iptables -t nat -nL –line-numbers

e)e. Permite sólo los mensajes entrantes desde la IP del compañero de tu máquina física (prueba desde otro sitio para ver si funciona).

iptables -A INPUT -s 192.168.203.200 -j ACCEPT
iptables -A INPUT -j DROP

iptables -A FORWARD -s 192.168.203.200 -j ACCEPT
iptables -A FORWARD -s -j DROP

f) #Activa el log sobre todas las reglas y verifica que se anotan los mensajes.

Insertamos en IPTABLEs las reglas para activar el log:

iptables -I FORWARD 1 -j LOG –log-prefix ‘IPTABLESFORWARD: ‘
iptables -I INPUT 1 -j LOG –log-prefix ‘IPTABLESINPUT: ‘

iptables -t nat -I PREROUTING 1 -j LOG –log-prefix ‘IPTABLESPREROUTING: ‘
iptables -t nat -I POSTROUTING 1 -j LOG –log-prefix ‘IPTABLESPREROUTING: ‘

iptables -I OUTPUT 1 -j LOG –log-prefix ‘IPTABLESOUTPUT: ‘

NOTA: hay que ponerlas las primeras para que haga log antes de rechazarlo.

#Ahora editamos el archivo:

gedit /etc/rsyslog.d/50-default.conf

#E incluimos al final:

kern.warning /var/log/iptables.log

Virtual Linux

  • admin 

Traducción de un artículo publicado en IBM Developerworks, escrito por M. Tim Jones. Fuente original: http://www-128.ibm.com/developerworks/linux/library/l-linuxvirt/

 

Virtualización significa muchas cosas diferentes para diferentes personas. Un aspecto candente en la virtualización es la virtualización de servidores, o como alojar múltiples sistemas operativos independientes en un único ordenador anfitrion. Este artículo explora las ideas tras la virtualización y discute algunas de las múltiples maneras de implementarla. También se revisan diferentes tecnologias de virtualización, como la virtualización de sistema operativo en Linux.

 

Virtualizar significar aparentar que algo con una forma tiene otra. Virtualizar un ordenador significa aparentar que se trata de múltiples ordenadores o de un ordenador completamente diferente.

Virtualización tambien puede significar conseguir que varios ordenadores parezcan uno solo. A este concepto se le suele denominar agregación de servidores (server aggregation) o grid computing.

Comencemos con los orígenes de la virtualización.

Una visión historica de la virtualización

La virtualización no es un tema nuevo, de hecho ronda desde hace 40 años. Los primeros usos de la virtualización incluyen el IBM 7044, el Sistema de Tiempo Compartido Compatible (CTSS – Compatible Time Sharing System) desarrollado en el Instituto Tecnológico de Massachusetts (MIT – Massachussets Institute of Technology) en el IBM 704. Y el proyecto Atlas de la Universidad de Manchester (uno de los primeros superordenadores del mundo), que fué pionero en el uso de memoria virtual con paginación y llamadas de supervisor.

Virtualización de hardware

IBM reconoció la importancia de la virtualización en la década de 1960 con el desarrollo del mainframe System/360 Model 67. El Model 67 virtualizó todas las interfaces hardware a través del Monitor de Máquina Virtual (VMM – Virtual Machine Monitor). En los primeros días de la computación, el sistema operativo se llamó supervisor. Con la habilidad de ejecutar sistemas operativos sobre otro sistema operativo, apareció el termino hypervisor (termino acuñado en la década de 1970).

El VMM se ejecutaba directamente sobre el hardware subyacente, permitiendo múltiples máquinas virtuales (VMs). Cada VM podía ejecutar una instancia de su propio sistema operativo privado — al comienzo este era CMS, o Conversational Monitor System. Las máquinas virtuales han continuado avanzando, y hoy se pueden encontrar ejecutándose en el mainframe System z9. Lo que proporciona compatibilidad hacia atrás, incluso hasta la línea System/360.

Virtualización del procesador

Java Virtual Machine (JVM)
El lenguaje Java ha seguido el modelo P-code en su máquina virtual. Esto ha permitido la amplia distribución de programas Java sobre incontables arquitecturas simplemente portando la JVM.

Otro de los usos iniciales de la virtualización, en este caso de un procesador simulado, es la máquina de pseudo-código (P-code machine). P-code es un lenguaje máquina que se ejecuta en una máquina virtual en lugar de en hardware real. P-code alcanzó la fama en la década de 1970 en el sistema Pascal de la Universidad de California, San Diego (UCSD), que compilaba programas Pascal en P-code (o pseudo-código), y luego los ejecutaba en una máquina virtual P-code. Esto permitió que los programas P-code fuesen muy portables y pudiesen ejecutarse en cualquier lugar donde estuviese disponible una máquina virtual P-code.

El mismo concepto se utilizó en la decada de 1960 para el Basic Combined Programming Language (BCPL), un antepasado del lenguaje C. En este caso, un compilador compilaba código BCPL en un código máquina intermedio llamado O-code. En un segundo paso, el O-code era compilado en el lenguaje nativo de la máquina de destino. Este modelo se utiliza en los compiladores modernos para proporcionar flexibilidad al portar los compiladores hacia nuevas arquitecturas destino (separando el front-end y el back-end por un lenguaje intermedio).

Virtualización del juego de instrucciones

La virtualización del juego de instrucciones, o la traducción binaria, es un aspecto nuevo. En este modelo, un juego de instrucciones virtual se traduce al juego de instrucciones físico del hardware subyacente, normalmente de forma dinámica. Cuando se va a ejecutar el código se realiza la traducción de una porción. Si se produce una ramificación (salto), se obtiene y traduce una nueva porción de código. Este proceso es similar a las operaciones que se realizan con memoria cache, donde bloques de instrucciones se mueven desde la memoria hasta una memoria cache local rápida antes de su ejecución.

La CPU Crusoe diseñada por Transmeta es un ejemplo reciente de este modelo. Esta arquitectura implementa traducción binaria bajo la marca registrada Code Morphing. Un ejemplo similar es el análisis de código en tiempo de ejecución utilizado en las soluciones de virtualización completa, que buscan y redirigen instrucciones privilegiadas (para evitar algunos problemas con ciertos juegos de instrucciones).

Tipos de virtualización

La virtualización y los juegos
Un artículo sobre virtualización no estaría completo sin una referencia a MAME (Multiple-Arcade Machine Emulator). MAME, como su propio nombre explica, es un completo emulador de muchos juegos arcade antiguos. Además de virtualizar los procesadores utilizados en esos juegos, se virtualiza la máquina completa, incluyendo el hardware de gráficos, sonido y controles. MAME es una gran aplicación, es muy interesante revisar su código para entender el alcance de lo que ha logrado.

No existe una sola manera de realizar la virtualización. De hecho, existen diversas técnicas que alcanzan el mismo resultado a través de diferentes niveles de abstracción. Esta sección presenta tres de las técnicas de virtualización más comunes en Linux, identificando sus puntos fuertes y sus debilidades. La industria algunas veces utiliza diferentes términos para describir el mismo método de virtualización. Aquí se utilizará el término más común, con referencias a otras denominaciones.

Emulación Hardware

La virtualización más compleja consiste en la emulación de hardware. Con esta técnica, en el sistema anfitrión se utiliza una máquina virtual que emula el hardware, como muestra la Figura 1.

figure1.gif

Figura 1. La emulación de Hardware utiliza una máquina virtual (VM) para simular el hardware

Emulación y desarrollo
Uno de los usos más interesantes de la emulación hardware es el codesarrollo de firmware y hardware. En lugar de esperar hasta que el hardware real esté disponible, los desarrolladores del firmware pueden utilizar una máquina virtual del hardware para validar muchos detalles de su código en una simulación.

Como puede suponer, el principal problema con la emulación hardware es que puede resultar terriblemente lenta. Ya que cada instrucción debe ser simulada por el hardware subyacente, no es extraño obtener una velocidad 100 veces más lenta. Si se pretende conseguir una emulación muy fiel que incluya precisión en los ciclos, simulación de los pipelines de la CPU, y comportamiento de cache, la diferencia de velocidad real puede ser 1000 veces más lenta.

La emulación de hardware tiene sus ventajas. Por ejemplo, utilizando la emulación hardware, es posible ejecutar un sistema operativo sin modificar diseñado para un PowerPC sobre una máquina anfitrión con procesador ARM. Incluso es posible ejecutar múltiples máquinas virtuales, cada una simulando un procesador diferente.

Virtualización completa

La virtualización completa, también llamada virtualización nativa, es otra interesante técnica de virtualización. Este modelo utiliza una máquina virtual que media entre el sistema operativo invitado y el hardware nativo (ver Figura 2). «Mediar» es la palabra clave aquí porque la VMM está entre el sistema el sistema operativo invitado y el hardware real. Algunas instrucciones protegidas deben capturarse y manejarse dentro del hipervisor ya que el hardware subyacente no es propiedad de un sistema operativo sino que es compartido a través del hipervisor.

 

figure2.gif

Figura 2. La virtualización completa utiliza un hipervisor para compartir el hardware subyacente

Hipervisores en hardware antiguo
Parte del hardware antiguo, como el x86, crea problemas para la técnica de la virtualización completa. Por ejemplo, no se capturan ciertas instrucciones que deben ser manejadas por la VMM. Por lo tanto, los hipervisores deben revisar y capturar de forma dinámica el código en modo privilegiado para lidiar con este problema.

La virtualización completa es más rápida que la emulación hardware, pero el rendimiento es menor que cuando se utiliza hardware pelado debido a la mediación del hipervisor. La gran ventaja de la virtualización completa es que un sistema operativo puede ejecutarse sin modificaciones. La única restricción es que el sistema operativo debe soportar el hardware subyacente (por ejemplo, PowerPC).

Paravirtualización

La paravirtualización es otra técnica popular que cuenta con algunas similitudes con la virtualización completa. Este método utiliza un hipervisor para compartir el acceso al hardware subyacente pero integra código que está al tanto de la virtualización en el propio sistema operativo (ver Figura 3). Esta aproximación evita la necesidad de recompilar y capturar ya que los propios sistemas operativos cooperan en el proceso de virtualización.

 

figure3.gif

Figura 3. La paravirtualización comparte el proceso con el SO alojado (Guest OS)

Como ya he mencionado, la paravirtualización precisa que los sistemas operativos alojados sean modificados por el hipervisor, lo que es una desventaja. Pero la paravirtualización ofrece un rendimiento próximo al de un sistema no virtualizado. Del mismo modo que con la virtualización completa, es posible soportar varios sistemas operativos diferentes de manera concurrente.

Virtualización en el nivel del sistema operativo

La última técnica que exploraremos, la virtualización en el nivel del sistema operativo, utiliza una técnica diferente a las que hemos visto. Esta técnica virtualiza los servidores encima del propio sistema operativo. Este método soporta un solo sistema operativo y símplemente aisla los servidores independientes (ver Figura 4).

 

figure4.gif

Figura 4. La virtualización en el nivel del sistema operativo aisla a los servidores

La virtualización en el nivel del sistema operativo requiere cambios en el núcleo del sistema operativo, la ventaja es un rendimiento igual a la ejecución nativa.

Qué importancia tiene la virtualización ?

Antes de examinar algunas de las opciones de virtualización disponibles hoy en Linux, vamos a examinar las ventajas de la virtualización.

Desde una perspectiva de negocio, hay muchas razones para utilizar virtualización. La mayoría están relacionadas con la consolidación de servidores. Simple, si puedes virtualizar un número de sistemas infrautilizados en un solo servidor, ahorrarás energia, espacio, capacidad de refrigeración y administración ya que tienes menos servidores. Como puede ser difícil determinar el grado de utilización de un servidor, las tecnologias de virtualización soportan la migración en directo. La migración en directo permite que un sistema operativo y sus aplicaciones se muevan a un nuevo servidor para balancear la carga sobre el hardware disponible.

La virtualización también es importante para los desarrolladores. El núcleo Linux ocupa un solo espacio de direcciones, lo que significa que un fallo en el núcleo o en cualquier driver provoca la caída del sistema operativo completo. La virtualización supone que puedes ejecutar varios sistemas operativos, y si uno cae debido a un fallo, el hipervisor y el resto de sistemas operativos continuarán funcionando. Esto puede hacer que depurar el nucleo sea una tarea más parecida a depurar aplicaciones en el espacio del usuario.

Proyectos de virtualización relacionados con Linux

La Tabla 1 muestra diferentes posibilidades de virtualización en Linux, centrándose en aquellas soluciones de código abierto.

 

Proyecto Tipo Licencia
Bochs Emulación LGPL
QEMU Emulación LGPL/GPL
VMware Virtualización completa Privativa
z/VM Virtualización completa Privativa
Xen Paravirtualización GPL
UML Paravirtualización GPL
Linux-VServer Virtualización en el nivel del sistema operativo GPL
OpenVZ Virtualización en el nivel del sistema operativo GPL

Tabla 1. Proyectos de virtualización relacionados con Linux

 

 

Bochs (emulación)

Virtualización a nivel de biblioteca
Aunque aquí no se haya tratado, otro método de virtualización que emula porciones de un sistema operativo a través de una biblioteca es la virtualización a nivel de biblioteca. Algunos ejemplos son Wine (parte de la API Win32 para Linux) y LxRun (parte de la API Linux para Solaris)

Bochs simula un ordenador x86, es portable y se ejecuta sobre diferentes plataforas, incluyendo x86, PowerPC, Alpha, SPARC y MIPS. El interés de Bochs es que no solo emula el procesador sino el ordenador entero, incluyendo los periféricos, como el teclado, ratón, hardware gráfico, adaptadores de red, etc.

Bochs puede configurarse como un antiguo Intel 386, o sucesores como el 486, Pentium, Pentium Pro, o una variante de 64 bits. Incluso emula instrucciones gráficas opcionales como MMX y 3DNow.

Utilizando el emulador Bochs, puedes ejecutar cualquier distribución Linux en Linux, Microsoft Windows 95/98/NT/2000 (y una variedad de aplicaciones) en Linux, incluso los sistemas operativos BSD (FreeBSD, OpenBSD, etc…) sobre Linux.

QEMU (emulación)

QEMU es otro emulador, como Bochs, pero tiene algunas diferencias que son bienvenidas. QEMU soporta dos modos de operación. El primero es el modo de emulación de sistema completo. Este modo es similar a Bochs ya que emula todo un ordenador personal (PC) con su procesador y periféricos. Este modo emula varias arquitecturas, como x86, x86_64, ARM, SPARC, PowerPC y MIPS, con velocidad razonable utilizando traducción dinámica. Utilizando este modo es posible emular los sistemas operativos Windows (incluyendo XP) y Linux sobre Linux, Solaris y FreeBSD. Tambien se soportan otras combinaciones de sistemas operativos (consulte la sección recursos para obtener más información).

QEMU también soporta un segundo modo llamado User Mode Emulation. En este modo, que sólo puede ser alojado en Linux, puede lanzarse un binario para una arquitectura diferente. Esto permite, por ejemplo, que se ejecute en Linux sobre x86 un binario compilado para la arquitectura MIPS. Entre las arquitecturas soportadas por este modo se encuentran ARM, SPARC, PowerPC y otras que están en desarrollo.

VMware (virtualización completa)

VMware es una solución comercial para la virtualización completa. Entre los sistemas operativos alojados y el hardware existe un hipervisor funcionando como capa de abstracción. Esta capa de abstracción permite que cualquier sistema operativo se ejecute sobre el hardware sin ningún conocimiento de cualquier otro sistema operativo alojado.

VMware también virtualiza el hardware de entrada/salida disponible y ubica drivers para dispositivos de alto rendimiento en el hipervisor.

El entorno virtualizado completo se respalda en un fichero, lo que significa que un sistema completo (incluyendo el sistema operativo alojado, la máquina virtual y el hardware virtual) puede migrarse con facilidad y rapidez a una nueva máquina anfitrión para balancear la carga.

z/VM (virtualización completa)

Aunque el IBM System z estrena nombre, realmente tiene una larga historia que se origina en la decada de 1960. El System/360 ya soportaba virtualización utilizando máquinas virtuales en 1965. Es interesante observar que el System z mantiene la retrocompatibilidad hasta la antigua línea System/360.

En el System z, se utiliza como hipervisor del sistema operativo a z/VM. En su interior está el Programa de Control (CP – Control Program), que proporciona la virtualización de los recursos físicos a los sistemas operativos alojados, incluyendo Linux (ver Figura 5). Esto permite que varios procesadores y otros recursos sean virtualizados para un número de sistemas operativos alojados.

 

figure5.gif

Figura 5. Virtualización a nivel de SO utilizando z/VM

z/VM también puede emular una LAN virtual para aquellos sistemas operativos hospedados que quieren comunicarse entre sí. La emulación se realiza por completo en el hipervisor, con lo que se obtiene una gran seguridad.

Xen (paravirtualización)

Xen es la solución de fuente abierta proporcionada por XenSource para obtener paravirtualización a nivel de sistema operativo. Recuerde que en la paravirtualización el hipervisor y el sistema operativo colaboran en la virtualización, se requieren cambios en el sistema operativo pero se obtiene un rendimiento próximo a la ejecución nativa.

Como Xen precisa colaboración (modificaciones en el sistema operativo alojado), solo pueden virtualizarse en Xen sistemas operativos parcheados. Desde el punto de vista de Linux, que es de fuente abierta, se trata de un compromiso razonable porque se consigue un mejor rendimiento que con la virtualización completa. Pero desde el punto de vista de un soporte amplio (que incluya otros sistemas operativos que no sean de fuente abierta), se trata de un claro inconveniente.

Es posible ejecutar Windows como SO alojado en Xen, pero solo en sistemas hardware que soporten la tecnología Vanderpool de Intel o Pacifica de AMD. Otros sistemas operativos soportados por Xen son: Minix, Plan 9, NetBSD, FreeBSD y OpenSolaris.

User-mode Linux (paravirtualización)

User-mode Linux (UML) permite que un sistema operativo Linux ejecute otros sistemas operativos Linux en el espacio del usuario. Cada sistema operativo Linux alojado existe como un proceso en el sistema operativo Linux anfitrión (ver Figura 6). Lo que permite a varios núcleos Linux (con sus propios espacios de usuario asociados) ejecutarse en el contexto de un solo núcleo Linux.

 

figure6.gif

Figura 6. Alojamiento de Linux en User-mode Linux

Desde el núcleo Linux 2.6, UML se encuentra en la rama principal del núcleo, pero debe ser activado y recompilado antes de utilizarse. Estos cambios proporcionan, entre otras cosas, virtualización de dispositivos. Lo que permite a los sistemas operativos alojados compartir los dispositivos físicos disponibles, como los dispositivos de bloques (floppy, CD-ROM, y sistemas de ficheros), consolas, dispositivos NIC, hardware de sonido y otros.

Puesto que los núcleos alojados se ejecutan en el espacio del usuario deben estar compilados para este uso (aunque puede tratarse de diferentes versiones del núcleo). Existirá un núcleo anfitrión (que se ejecutará sobre el hardware) y uno o varios núcleos alojados (que se ejecutarán en el espacio de usuario del núcleo anfitrión). Es posible anidar estos núcleos, de manera que un núcleo alojado actúe como anfitrión de otro.

Linux-VServer (virtualización a nivel de sistema operativo)

Linux-VServer es una solución de virtualización a nivel de sistema operativo. Linux-VServer virtualiza el núcleo Linux de manera que varios entornos de espacio de usuario, también llamados Virtual Private Servers (VPS), se ejecutan de foma independiente sin tener conocimiento del resto. El aislamiento del espacio de usuario se consigue gracias a diferentes modificaciones del núcleo Linux.

Para aislar cada uno de los espacios de usuario del resto hay que estudiar el concepto de un contexto. Un contexto es un contenedor para los procesos de un VPS, de manera que herramientas como pssolo muestran información sobre los procesos del VPS. Para el arranque inicial el núcleo define un contexto por defeto. Tambien existe un contexto espectador para la administración (ver todos los procesos en ejecución). Como puede suponer, tanto el núcleo como las estructuras internas de datos se han modificado para dar soporte a esta técnica de virtualización.

Con Linux-VServer también se utiliza un tipo de chroot para aislar el directorio raíz de cada VPS. Recuerde que una chroot permite  que se especifique un nuevo directorio raíz, además se utilizan otras funciones (llamadas Chroot-Barrier) para que un VPS no pueda escapar desde su confinamiento en el directorio raíz. Cada VPS cuenta con su propia raíz y lista de usuarios y contraseñas.

Linux-VServer está soportado en los núcleos Linux v2.4 y v2.6, pudiendo funcionar sobre diferentes plataformas: x86, x86-64, SPARC, MIPS, ARM y PowerPC.

OpenVZ (virtualización a nivel de sistema operativo)

OpenVZ es otra solución de virtualización a nivel de sistema operativo, como Linux-VServer, pero tiene algunas diferencias interesantes. OpenVZ es un núcleo modificado para la virtualización que soporta espacios de usuario aislados, VPS, con un conjunto de herramientas de usuario para la administración. Por ejemplo, es fácil crear un nuevo VPS desde la línea de comandos:

Listado1. Creación de un VPS desde la línea de comandos

$ vzctl create 42 --ostemplate fedora-core-4
Creating VPS private area
VPS private area was created
$ vzctl start 42
Starting VPS ...
VPS is mounted

También puede listar los VPSs creados con vzlist, que opera de una forma similar al comando ps.

Para planificar los procesos, OpenVZ utiliza un planificador de dos niveles. Primero se determina qué VPS debe obtener la CPU. Después, el segundo nivel del planificador escoge el proceso a ejecutar basándose en las prioridades standard de Linux.

OpenVZ también incluye los llamados beancounters. Un beancounter consiste en un número de parámetros que definen la distribución de recursos para un VPS. Esto proporciona cierto nivel de control sobre un VPS, definiendo la cantidad de memoria y el número de objetos para la comunicación entre procesos (IPC) disponibles.

Una característica única de OpenVZ es la habilidad de establecer un punto de control y migrar un VPS desde un servidor físico a otro. Establecer un punto de control significa que el estado de un VPS en ejecución se congela y se guarda en un fichero. Este fichero puede llevarse a un nuevo servidor para restaurar la ejecución del VPS.

Entre las arquitecturas soportadas por OpenVZ se encuentran: x86, x86-64 y PowerPC.

Soporte hardware para la virtualización completa y la paravirtualización

Recuerde que la arquitectura IA-32 (x86) crea ciertos problemas cuando se intenta virtualizar. Algunas instrucciones del modo privilegiado no se pueden capturar y pueden devolver diferentes resultados en función del modo. Por ejemplo, la instrucción STR recupera el estado de seguridad, pero el valor que retorna depende del nivel de privilegios de quien realizó la ejecución. Lo que es problemático cuando se intenta virtualizar diferentes sistemas operativos en diferentes niveles. Por ejemplo, la arquitectura x86 soporta cuatro anillos de protección, el nivel 0 (mayor privilegio) normalmente ejecuta el sistema operativo, los niveles 1 y 2 dan soporte a los servicios del sistema operativo, y el nivel 3 (el menor de los privilegios) soporta las aplicaciones. Los fabricantes de hardware han detectado este defecto (y otros), y han producido nuevos diseños que soportan y aceleran la virtualización.

Intel está produciendo una nueva tecnologia de virtualización que soportará hipervisores en dos de sus arquitecturas, tanto en x86 (VT-x) como en Itanium (VT-i). VT-x soporta dos nuevos modos de operación, uno para la VMM (root) y otro para los sistemas operativos hospedados (no root). En el modo root se cuentan con todos los privilegios, mientras que en el modo no root no se tienen privilegios (incluso para el nivel 0). La arquitectura también permite cierta flexibilidad al definir las instrucciones que provocan que una VM (sistema operativo hospedado) retorne al VMM y almacene el estado del procesador. También se han añadido otras capacidades, consulte la sección recursos.

AMD está produciendo la tecnologia Pacifica en la que el hardware asiste a la virtualización. Entre otras cosas, Pacifica mantiene un bloque de control para los sistemas operativos hospedados que se guarda con la ejecución de instrucciones especiales. La instrucción VMRUN permite a una máquina virtual (y sus sistema operativo hospedado asociado) ejecutarse hasta que el VMM recupere el control (lo que también es configurable). Las opciones de configuración permiten que el VMM adapte los privilegios de cada uno de los huespedes. Pacifica también compensa la traducción de direcciones con unidades de gestión de memoria (MMU) para el anfitrion y los huespedes.

Estas nuevas tecnologias pueden utilizarse en varias de las técnicas de virtualización que se han discutido, como Xen, VMware, User-mode Linux y otras.

Linux KVM (Kernel Virtual Machine)

Las notícias más recientes que provienen de Linux son la incorporación de KVM en el núcleo (2.6.20). KVM es una completa solución de virtualización única al convertir al núcleo Linux en un hipervisor utilizando un módulo del núcleo. Este módulo permite a otros sistemas operativos alojados ejecutarse en el espacio de usuario del núcleo Linux anfitrión (ver Figura 7). El módulo KVM en el núcleo expone el hardware virtualizado a través del dispositivo de carácteres /dev/kvm. El sistema operativo alojado se comunica con el módulo KVM utilizando un proceso que ejecuta un QEMU modificado para obtener la emulación de hardware.

 

figure7.gif

Figura 7. Virtualización con Kernel Virtual Machine (KVM)

El módulo KVM introduce un nuevo modo de ejecución en el núcleo. Donde el kernel vanilla (standard) aporta el modo kernel y el modo user, KVM aporta el modo guest. Este modo es utilizado para ejecutar todo el código del huesped en el que no se utiliza entrada/salida, y el modo normal de usuario proporciona la entrada/salida para los huespedes.

La presentación de KVM es una interesante evolución de Linux, ya que es la primera tecnologia de virtualización que pasa a formar parte del propio núcleo Linux. Existe en la rama 2.6.20, pero puede utilizarse como un módulo del núcleo en la versión 2.6.19. Cuando se ejecuta en hardware que soporta la virtualización es posible hospedar a Linux (32 y 64 bits) y Windows (32 bits). Para más información sobre KVM consulte la sección de recursos.

Resumen

La virtualización es la nueva estrella, si se puede llamar «nuevo» a algo con unos 40 años de antiguedad. Históricamente se ha utilizado en diferentes situaciones, pero en la actualidad su principal interés es la virtualización de servidores y sistemas operativos. Como Linux, la virtualización proporciona muchas opciones de rendimiento, portabilidad y flexibilidad. Lo que significa que puede escoger la solución que mejor se ajusta a sus necesidades y a su aplicación.

Recursos

Aprender

  • La página New to IBM Systems es útil si los sistemas IBM no son territorio conocido. La página detalla entre otros los sistemas i, p, x y z.
  • En developerWorks Grid computing zone es posible aprender sobre grid computing, un conjunto abierto de standards y protocolos que virtualizan un ordenador distribuido permiten crear un sistema poderoso.
  • En la zona developerWorks Linux puede encontrar más recursos para desarrolladores Linux
  • Puede mantenerse al día con developerWorks technical events and webcasts.

    • Productos y tecnologias

    • Bochs y QEMU son emuladores de PC que permiten que sistemas operativos como Windows o Linux se ejecuten en el espacio de usuario de un sistema operativo Linux.
    • VMware es una solución comercial popular que proporciona virtualización completa y puede virtualizar sistemas operativos sin modificar.
    • z/VM es el sistema operativo VM más nuevo para la arquitectura z/Architecture de 64 bits. z/VM proporciona virtualización completa con asistencia de hardware y soporta un amplio abanico de sistemas operativos, incluido Linux.
    • Xen es una solución de fuente abierta para la paravirtualización que requiere modificaciones a los sistemas operativos hospedados pero, al colaborar con el hipervisor, alcanza rendimientos próximos a la ejecución nativa.
    • User-mode Linux es otra solución de fuente abierta para la paravirtualización. Cada sistema operativo huesped se ejecuta como un proceso del sistema operativo anfitrion.
    • coLinux, o Cooperative Linux, es una solución de virtualización que permite a dos sistemas operativos compartir de forma cooperativa el hardware subyacente.
    • Linux-Vserver es una solución de virtualización a nivel de sistema operativo para los sistemas GNU/Linux que aisla de forma segura a los servidores hospedados.
    • OpenVZ es una solución de virtualización a nivel de sistema operativo que soporta puntos de control y migración de VPSs sobre la marcha.
    • Linux KVM es la primera tecnologia de virtualización que ha sido capaz de integrarse en la línea principal de producción del núcleo Linux. Con solo un módulo del núcleo, un núcleo Linux que se ejecute sobre hardware con soporte para la virtualización es capaz de actuar como hipervisor y soportar sistemas operativos Linux y Windows  sin modificar como huespedes.
    • Order the SEK for Linux, dos DVDs con las últimas versiones de evaluación de software de IBM para Linux: DB2, Lotus, Rational, Tivoli y WebSphere.
    • Base su próximo proyecto sobre Linux en el IBM trial software disponible para descarga directa desde developerWorks.

    Comentarios

    Sobre el autor

    p-mjones.jpgM. Tim Jones es un arquitecto de software empotrado y autor de GNU/Linux Application Programming, AI Application Programming, y BSD Sockets Programming from a Multilanguage Perspective. Su experiencia como ingeniero incluye desde el desarrollo de núcleos para satélites geosíncronos hasta el desarrollo de arquitecturas para sistemas empotrados y protocolos de red. Tim es un Consultant Engineer para Emulex Corp. en Longmont, Colorado.

     

    Hot Plugging: hotplug

    • admin 

    Fuente: http://debian-handbook.info/browse/stable/sect.hotplug.html

    Introduction

    The hotplug kernel subsystem loads drivers for peripherals that can be hotplugged. This includes USB peripherals (increasingly common), PCMCIA (common expansion cards for laptops), IEEE 1394 (also called “Firewire” or “I-Link”), some SATA hard drives, and even, for some high-end servers, PCI or SCSI devices.

    The kernel has a database that associates each device ID with the required driver. This database is used during boot to load all the drivers for the peripheral devices detected on the different buses mentioned, but also when an additional hotplug device is connected.

    Once a driver is loaded, a message is sent to udevd so it will be able to create the corresponding entry in /dev/.
    The Naming Problem

    Before the appearance of hotplug connections, it was easy to assign a fixed name to a device. It was based simply on the position of the devices on their respective bus. But this is not possible when such devices can come and go on the bus. The typical case is the use of a digital camera and a USB key, both of which appear to the computer as disk drives. The first one connected may be /dev/sdb and the second /dev/sdc (with /dev/sda representing the computer’s own hard drive). The device name is not fixed; it depends on the order in which devices are connected.

    Additionally, more and more drivers use dynamic values for devices’ major/minor numbers, which makes it impossible to have static entries for the given devices, since these essential characteristics may vary after a reboot.

    udev was created precisely to solve this problem.

    NOTE: IN PRACTICE Network card management
    Many computers have multiple network cards (sometimes two wired interfaces and a wifi interface), and with hotplug support on most bus types, the 2.6 kernel no longer guarantees fixed naming of network interfaces. But a user who wants to configure their network in /etc/network/interfaces needs a fixed name!

    It would be difficult to ask every user to create their own udev rules to address this problem. This is why udev was configured in a rather peculiar manner; on first boot (and, more generally, each time that a new network card appears) it uses the name of the network interface and its MAC address to create new rules that will reassign the same name on subsequent boots. These rules are stored in /etc/udev/rules.d/70-persistent-net.rules.
    This mechanism has some side effects that you should know about. Let’s consider the case of computer that has only one PCI network card. The network interface is named eth0, logically. Now say the card breaks down, and the administrator replaces it; the new card will have a new MAC address. Since the old card was assigned the name, eth0, the new one will be assigned eth1, even though the eth0 card is gone for good (and the network will not be functional because /etc/network/interfaces likely configures an eth0 interface). In this case, it is enough to simply delete the /etc/udev/rules.d/70-persistent-net.rules file before rebooting the computer. The new card will then be given the expected eth0 name.

    How udev Works
    When udev is notified by the kernel of the appearance of a new device, it collects various information on the given device by consulting the corresponding entries in /sys/, especially those that uniquely identify it (MAC address for a network card, serial number for some USB devices, etc.).
    Armed with all of this information, udev then consults all of the rules contained in /etc/udev/rules.d/ and /lib/udev/rules.d/. In this process it decides how to name the device, what symbolic links to create (to give it alternative names), and what commands to execute. All of these files are consulted, and the rules are all evaluated sequentially (except when a file uses “GOTO” directives). Thus, there may be several rules that correspond to a given event.
    The syntax of rules files is quite simple: each row contains selection criteria and variable assignments. The former are used to select events for which there is a need to react, and the latter defines the action to take. They are all simply separated with commas, and the operator implicitly differentiates between a selection criterion (with comparison operators, such as == or !=) or an assignment directive (with operators such as =, += or :=).
    Comparison operators are used on the following variables:

     

    • KERNEL: the name that the kernel assigns to the device;
    • ACTION: the action corresponding to the event (“add” when a device has been added, “remove” when it has been removed);
    • DEVPATH: the path of the device’s /sys/ entry;
    • SUBSYSTEM: the kernel subsystem which generated the request (there are many, but a few examples are “usb”, “ide”, “net”, “firmware”, etc.);
    • ATTR{attribut}: file contents of the attribute file in the /sys/$devpath/ directory of the device. This is where you find the MAC address and other bus specific identifiers;
    • KERNELS, SUBSYSTEMS and ATTRS{attributes} are variations that will try to match the different options on one of the parent devices of the current device;
    • PROGRAM: delegates the test to the indicated program (true if it returns 0, false if not). The content of the program’s standard output is stored so that it can be reused by the RESULT test;
    • RESULT: execute tests on the standard output stored during the last call to PROGRAM.

    The right operands can use pattern expressions to match several values at the same time. For instance, * matches any string (even an empty one); ? matches any character, and [] matches the set of characters listed between the square brackets (or the opposite thereof if the first character is an exclamation point, and contiguous ranges of characters are indicated like a-z).
    Regarding the assignment operators, = assigns a value (and replaces the current value); in the case of a list, it is emptied and contains only the value assigned. := does the same, but prevents later changes to the same variable. As for +=, it adds an item to a list. The following variables can be changed:

    • NAME: the device filename to be created in /dev/. Only the first assignment counts; the others are ignored;
    • SYMLINK: the list of symbolic links that will point to the same device;
    • OWNER, GROUP and MODE define the user and group that owns the device, as well as the associated permission;
    • RUN: the list of programs to execute in response to this event.

    The values assigned to these variables may use a number of substitutions:
    $kernel or %k: equivalent to KERNEL;
    $number or %n: the order number of the device, for example, for sda3, it would be “3”;
    $devpath or %p: equivalent to DEVPATH;
    $attr{attribute} or %s{attribute}: equivalent to ATTRS{attribute};
    $major or %M: the kernel major number of the device;
    $minor or %m: the kernel minor number of the device;
    $result or %c: the string output by the last program invoked by PROGRAM;
    and, finally, %% and $$ for the percent and dollar sign, respectively.
    The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be.
    A concrete example
    Let us consider the case of a simple USB key and try to assign it a fixed name. First, you must find the elements that will identify it in a unique manner. For this, plug it in and run udevadm info -a -n /dev/sdc (replacing /dev/sdc with the actual name assigned to the key).
    # udevadm info -a -n /dev/sdc
    […]
    looking at device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0/block/sdc’:
    KERNEL==»sdc»
    SUBSYSTEM==»block»
    DRIVER==»»
    ATTR{range}==»16″
    ATTR{ext_range}==»256″
    ATTR{removable}==»1″
    ATTR{ro}==»0″
    ATTR{size}==»126976″
    ATTR{alignment_offset}==»0″
    ATTR{capability}==»53″
    ATTR{stat}==» 51 100 1208 256 0 0 0 0 0 192 25 6″
    ATTR{inflight}==» 0 0″
    […]
    looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0’:
    KERNELS==»9:0:0:0″
    SUBSYSTEMS==»scsi»
    DRIVERS==»sd»
    ATTRS{device_blocked}==»0″
    ATTRS{type}==»0″
    ATTRS{scsi_level}==»3″
    ATTRS{vendor}==»I0MEGA »
    ATTRS{model}==»UMni64MB*IOM2C4 »
    ATTRS{rev}==» »
    ATTRS{state}==»running»
    […]
    ATTRS{max_sectors}==»240″
    […]
    looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2’:
    KERNELS==»9:0:0:0″
    SUBSYSTEMS==»usb»
    DRIVERS==»usb»
    ATTRS{configuration}==»iCfg»
    ATTRS{bNumInterfaces}==» 1″
    ATTRS{bConfigurationValue}==»1″
    ATTRS{bmAttributes}==»80″
    ATTRS{bMaxPower}==»100mA»
    ATTRS{urbnum}==»398″
    ATTRS{idVendor}==»4146″
    ATTRS{idProduct}==»4146″
    ATTRS{bcdDevice}==»0100″
    […]
    ATTRS{manufacturer}==»USB Disk»
    ATTRS{product}==»USB Mass Storage Device»
    ATTRS{serial}==»M004021000001″
    […]
    To create a new rule, you can use tests on the device’s variables, as well as those of one of the parent devices. The above case allows us to create two rules like these:
    KERNEL==»sd?», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/disk»
    KERNEL==»sd?[0-9]», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/part%n»
    Once these rules are set in a file, named for example /etc/udev/rules.d/010_local.rules, you can simply remove and reconnect the USB key. You can then see that /dev/usb_key/disk represents the disk associated with the USB key, and /dev/usb_key/part1 is its first partition.
    GOING FURTHER Debugging udev’s configuration

    Like many daemons, udevd stores logs in /var/log/daemon.log. But it is not very verbose by default, and it’s usually not enough to understand what’s happening. The udevadm control –log-priority=info command increases the verbosity level and solves this problem. udevadm control –log-priority=err returns to the default verbosity level.