Blog de Javi

Uno ya esta familiarizado con las máscaras de red en IPv4 pero hay que tener que en IPv6 su valor real es muy diferente.

/128 1 dirección IPv6 – Una interfaz de red
/64 1 Subred IPv6 – 18,446,744,073,709,551,616 direcciones IPv6
/56 256 Prefijo LAN Popular para un sitio suscriptor
/48 65,536 Prefijo LAN Popular para un sitio suscriptor
/32 65,536 /48 sitios suscriptores – Asignación mínima de IPv6
/24 16,777,216 sitios suscriptores 256 veces mas grande que la asignación mínima de IPv6

Como ven cuando hablamos de tamaños de redes e IP en IPv6 nos damos cuenta de su magnitud. Cuando nos suscribimos a algún túnel broker, éstos nos asignan un /48 para nosotros, con lo cual tenemos muchísimas IPs con las que hacer pruebas y divertirnos.

Una opción interesante cuando tenemos una red grande que gestionar, con varias VLANs y queremos disponer de movilidad, son las VLANs dinámicas que nos ofrecen los Switches y Routers de CISCO. Si disponemos de un Router de Cisco que permita hacer de Servidor VMPS podemos saltarnos el primer paso, pero debéis buscar en alguna otra página web como configurarlo.

En este caso vamos a utilizar un servidor Linux con Debian Lenny como servidor VMPS. Desde la página web del proyecto OpenVMPS bajamos la última versión estable del paquete. Lo compilamos y lo instalamos.

La instalación por defecto se queda de la siguiente forma:

• Binario: /usr/local/bin/vmpsd
• Configuracion: /usr/local/etc/vlan.db

Debemos ejecutar el binario en segundo plano o prepararnos un script de arranque y parada, de tal manera que cada vez que hagamos un cambio en el archivo de configuración podamos reiniciar el servicio facilmente.

El archivo de configuración de VLAN lo deberemos dejar de la siguiente forma:


vmps domain MiDominio
vmps mode secure
vmps fallback VLAN_fallback
vmps no-domain-req allow

!
!MAC Addresses
!
vmps-mac-addrs
address 000c.1234.0001 vlan-name VLAN_nombre1
address 000c.1234.0002 vlan-name VLAN_nombre2

Como veis, especificamos un nombre de dominio MiDominio y las VLANs están escritas con nombre y no de forma numérica. Esta la opcion de fallback, que sirve para que cuando una MAC no esta en la lista de direcciones MAC la mete en esa VLAN predeterminadamente.

Ahora nos toca configurar el Switch. Nos metemos en modo privilegiado y ejecutamos los siguientes comandos:

configure terminal
vmps server 192.168.34.10 primary
vtp domain MiDominio
end

La dirección IP 192.168.34.10 es la IP del servidor Linux donde tenemos ejecutándose el vmpsd y al cual, deberemos tener acceso desde el switch, obviamente.

Y después configuramos la boca. Hay que sacarla de la VLAN en la que este antes de ponerla que es VLAN dinámica.

configure terminal
interface fastethernet 0/xx
no switchport port-security mac-address xxxx.xxxx.xxxx
no switchport access vlan xxx
switchport access vlan dynamic
end

Esto con todas las bocas que queramos. Cuando acabemos de configurar las bocas escribimos:

vmps reconfirm

Y con estos simples pasos ya tenemos VLANs dinámicas en nuestra red.

Respecto a lo de pasar Windows XP de modo IDE a modo AHCI sin tener que reinstalarlo (en este caso con controladora SATA de chipset INTEL):

1. Con SATA en modo IDE en BIOS y el PC arrancado en Windows XP, descargar el INTEL MATRIX STORAGE DISKETTE lo más actualizado posible desde la web de Intel.

2. Extraer del fichero descargado todos los archivos a una carpeta y después copiar el archivo “IASTOR.SYS” de la misma a “C:\WINDOWS\SYSTEM32\DRIVERS”.

Con esto ponemos el driver necesario dónde Windows lo necesita. El problema es que Windows de momento, no sabe que está ahí, ni sabe cómo y cuándo debe cargarlo. Esto lo solucionaremos en el siguiente paso.

3. Copiar este código a un NOTEPAD y salvarlo con el nombre que queramos pero extensión “.REG”, no sirve “.REG.TXT”, si no luego se volverá a abrir con el bloc de notas en vez de importarse al registro:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_2681&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_27C1&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_27C5&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_2821&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_2829&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_2922&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_2929&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_3A02&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#VEN_8086&DEV_3A22&CC_0106]
"ClassGUID"="{4D36E96A-E325-11CE-BFC1-08002BE10318}"
"Service"="iastor"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iastor]
"ErrorControl"=dword:00000001
"Group"="SCSI Miniport"
"Start"=dword:00000000
"Tag"=dword:0000001b
"Type"=dword:00000001
"ImagePath"="\\SystemRoot\\system32\\DRIVERS\\iastor.sys"
"DisplayName"="Intel(R) SATA AHCI Controller"

En ese código, agreamos al registro los PNP ID de la controladora AHCI en una sección de dispositivos críticos, que son de los que Windows debe cargar drivers antes de otras cosas.

Yo he pegado este REG de un fichero que me creé en su día a partir del fichero INF del driver “IAAHCI.INF” de INTEL, que recoge todos esos PNP ID (un PNP ID es este número por ejemplo: “pci#VEN_8086&DEV_3A02&CC_0106″, que es un número único que define el hardware para la correcta instalación de los drivers necesarios para el mismo. Así se asegura que no se pueden meter drivers equivocados). Pero ahora en placas nuevas y por lo tanto con nuevos chipsets, es posible que haya nuevas controladoras SATA con PNP ID diferentes a esos (por ser más nuevas) y que esta solución no funcione (aunque con actualizar los PNP ID desde el INF del driver, se solucionaría rápido este pequeño problemilla).

Aparte, en la sección final del código posteado, se ve que creamos un SERVICIO nuevo. Se llama “IASTOR”. Windows lee “CRITICALDEVICEDATABASE” para ver si el dispositivo SATA del que arranca está en esa lista. Si lo encuentra, dentro lee que tiene que cargar el servicio “IASTOR”, el servicio “IASTOR” a su vez le dice que debe cargar “IASTOR.SYS” aparte de otros parámetros, como el tipo de controlador, el grupo, el orden de carga, etc.

4. Una vez salvado el fichero con extensión “.REG” y que contiene el código posteado, debemos hacer doble click sobre este fichero para importar su contenido al registro de Windows. Lo hacemos y respondemos que “SÍ” a la pregunta de importar, etc., etc…

5. Ahora que Windows ya tiene en su base de datos de dispositivos críticos el SATA en modo AHCI, reiniciamos el PC y en la BIOS establecemos el modo SATA en AHCI.

6. Windows debería arrancar normalmente. Si la cosa no ha ido bien, dará un pantallazo azul con un STOP 0x7B (hay muchos ceros, pero se omiten después del “0x”).

7. Al terminar de arrancar (entonces la cosa ha ido bien), detectará el SATA y pedirá drivers porque no está bien instalado, ya que lo hemos hecho nosotros directamente editando el registro pero hacen falta más cosas que son las que hace el INF del driver. (Puede que no pida el driver al arrancar, no recuerdo bien, pero aunque no lo pida, hay que instalarlo desde el admin de dispositivos).

Reinstalamos el driver de modo normal (lo que hicimos antes era sólo para que Windows arrancara sin pantallazo azul), es decir, cuando salga el asistente de dispositivo nuevo encontrado blablabla que corresponde al SATA AHCI, hay que instalar manualmente el driver y decirle la ubicación dónde habíamos descomprimido antes los ficheros del mismo (IASTOR.SYS, IAAHCI.CAT, IAAHCI.INF y alguno más) y seleccionar el “IAAHCI.INF”. Lo abrimos y siguiente siguiente hasta que lo termine de instalar. Si pide reinicia se reinicia y listo.

Así ya tenemos XP con SATA en modo AHCI sin formatear ni reinstalar.

OTRAS NOTAS:

* El fichero INF es un fichero de texto que contiene instrucciones sobre cómo Windows debe instalar un controlador. El fabricante se encarga de diseñar el INF de acuerdo a las especificaciones de Microsoft de cómo se debe hacer (y normalmente revisado por Microsoft si ha obtenido la firma WHQL). Dentro de ese fichero se hace referencia al PNP ID del dispositivo a instalar (para que no se usen drivers equivocados en dispositivos que no corresponden), a los archivos del driver en sí, dónde se deben copiar, modificaicones en el registro que se deben realizar, servicios a crear, etc.).

* El fichero SYS es el del driver en sí, programado por el fabricante del dispositivo (y normalmente revisado por Microsoft si ha obtenido la firma WHQL). Es el fichero que carga Windows para que Windows sepa como controlar el dispositivo para el cuál el driver fue desarrollado.

* El fichero CAT es el fichero de firma digital del driver, expedido por WHQL. Contiene certificados digitales con un HASH de cada fichero del driver. Normalmente se firman el INF y el SYS, de este modo se asegura que los drivers no han sido modificados por terceros desde que pasaron la certificación de Microsoft WHQL.

Fuente: Varias paginas web citan los mismos pasos, asi que la fuente es innecesaria.

Tenemos un comando en Linux que se llama “smartctl” el cual nos da informacion vital sobre el disco duro consultado. Datos tales como temperatura, horas en funcionamiento, promedio de fallo, etc…

equipo ~# smartctl -a -d ata /dev/sda
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 67
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 247181777
9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21179
... ... ...

Tenemos 4 columnas: VALUE, WORST, THRESH y RAW_VALUE

VALUE es el valor actual que nos da el indicador que debe de ser superior a THRESH. En caso contrario vamos mal, ya que quiere decir que hay algo que está fallando (Old_age fallo típico de disco duro, Pre_fail fallo crítico en 24 horas).

WORST es el valor más bajo que nos ha dado este indicador, se cumple lo mismo que con el anterior, si es más bajo que THRESH, malo.

Y ahora viene el rollo del normalizado.

RAW_VALUE es el valor sin normalizar del indicador, la forma más fácil de explicarlo es con el valor de Power_On_Hours, horas que lleva el disco encendido.

Por ejemplo, el disco viene de fábrica con una vida útil de 100.000 horas, puede durar más o menos, pero en estudios que hemos hecho hemos observado unos porcentajes.

Hasta 30.000 horas falla el 1%
Hasta 50.000 horas falla el 5%
Hasta 70.000 horas falla el 15%
Hasta 95.000 horas falla el 30%
Hasta 100.000 horas falla el 55%
Hasta 120.000 horas falla el 80%
Hasta 130.000 horas falla el 100%

El RAW_VALUE puede contener cualquier cosa (horas, segundos, lunas, periodos de 18.3 segundos…) aquí cada fabricante guarda lo que el estima oportuno, pero este RAW_VALUE me lo tiene que traducir a un valor normalizado. Siguiendo el ejemplo anterior el número de horas lo puede traducir a los valores 100,99,98,97,96,95,94 con un THRESH situado en el 96. ¿por qúe de 100 a 94? porque el fabricante lo decide así, podría haber sido de 60 a 54 o de 100 a 0 con intervalos más grandes, logicamente el THRESH se mueve en la misma escala.

¿Y el RAW_VALUE?
Como he dicho el valor del RAW lo decide cada fabricante, que marque 60 en temperatura no indica obligatoriamente que el disco esté a 60 grados, pueden haber comenzado la escala a -10 grados, emplear grados farenheit o cualquier otra medida. Lo importante es que el valor normalizado (43 en tu caso, sean los grados que sean) es inferior al THRESH establecido para ese disco (45)

Hay algunos fabricantes que si que ofrecen la interpretación exacta del RAW_VALUE pero pocas veces necesitamos conocer tanto detalle .

De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Fuente: Bosque Viejo