lunes, abril 28, 2008
ASTALAVISTA SECURITY TOOLBOX DVD v 4.0
Web del autor: http://www.astalavista.com/index.php?page=257
Enlace Torrent: http://btjunkie.org/torrent/Astalavista-s-Security-Toolbox-DVD-v4-0/4486bbb079c7b0eaf3b08e71e7a2bde050cae265b4a4
IPsec
Sumario
Los protocolos de IPsec actúan en la capa de red, la capa 3 del modelo OSI. Otros protocolos de seguridad para Internet de uso extendido, como SSL, TLS y SSH operan de la capa de transporte (capas OSI 4 a 7) hacia arriba. Esto hace que IPsec sea más flexible, ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendo TCP y UDP, los protocolos de capa de transporte más usados. IPsec tiene una ventaja sobre SSL y otros métodos que operan en capas superiores. Para que una aplicación pueda usar IPsec no hay que hacer ningún cambio, mientras que para usar SSL y otros protocolos de niveles superiores, las aplicaciones tienen que modificar su código.
Arquitectura de seguridad
IPsec está implementado por un conjunto de protocolos criptográficos para (1) asegurar el flujo de paquetes, (2) garantizar la autenticación mutua y (3) establecer parámetros criptográficos.
La arquitectura de seguridad de IP utiliza el concepto de asociación de seguridad (SA) como base para construir funciones de seguridad en IP. Una asociación de seguridad es simplemente el paquete de algoritmos y parámetros (tales como las claves) que se está usando para cifrar y autenticar un flujo particular en una dirección. Por lo tanto, en el tráfico normal bidireccional, los flujos son asegurados por un par de asociaciones de seguridad. La decisión final de los algoritmos de cifrado y autenticación (de una lista definida) le corresponde al administrador de IPsec.
Para decidir qué protección se va a proporcionar a un paquete saliente, IPsec utiliza el índice de parámetro de seguridad (SPI), un índice a la base de datos de asociaciones de seguridad (SADB), junto con la dirección de destino de la cabecera del paquete, que juntos identifican de forma única una asociación de seguridad para dicho paquete. Para un paquete entrante se realiza un procedimiento similar; en este caso IPsec coge las claves de verificación y descifrado de la base de datos de asociaciones de seguridad.
En el caso de multicast, se proporciona una asociación de seguridad al grupo, y se duplica para todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un grupo, utilizando diferentes SPIs, y por ello permitiendo múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, permitiendo autenticación, ya que un receptor sólo puede saber que alguien que conoce las claves ha enviado los datos. Hay que observar que el estándar pertinente no describe cómo se elige y duplica la asociación a través del grupo; se asume que un interesado responsable habrá hecho la elección.
Estado actual del estándar
IPsec es una parte obligatoria de IPv6, y su uso es opcional con IPv4. Aunque el estándar está diseñado para ser indiferente a las versiones de IP, el despliegue y experiencia hasta 2007 atañe a las implementaciones de IPv4.
Los protocolos de IPsec se definieron originalmente en las RFCs 1825 y 1829, publicadas en 1995. En 1998 estos documentos fueron sustituidos por las RFCs 2401 y 2412, que no son compatibles con la 1825 y 1829, aunque son conceptualmente idénticas. En diciembre de 2005 se produjo la tercera generación de documentos, RFCs 4301 y 4309. Son en gran parte un superconjunto de la 2401 y 2412, pero proporcionan un segundo estándar de Internet Key Exchange. Esta tercera generación de documentos estandarizó la abreviatura de IPsec como "IP" en mayúsculas y "sec" en minúsculas.
Es raro ver un producto que ofrezca soporte de RFC1825 y 1829. "ESP" se refiere generalmente a 2406, mientras que ESPbis se refiere a 4303.
Propósito de diseño
IPsec fue proyectado para proporcionar seguridad en modo transporte (extremo a extremo) del tráfico de paquetes, en el que los ordenadores de los extremos finales realizan el procesado de seguridad, o en modo túnel (puerta a puerta) en el que la seguridad del tráfico de paquetes es proporcionada a varias máquinas (incluso a toda la red de área local) por un único nodo.
IPsec puede utilizarse para crear VPNs en los dos modos, y este es su uso principal. Hay que tener en cuenta, sin embargo, que las implicaciones de seguridad son bastante diferentes entre los dos modos de operación.
La seguridad de comunicaciones extremo a extremo a escala Internet se ha desarrollado más despacio de lo esperado. Parte de la razón a esto es que no ha surgido infraestructura de clave pública universal o universalmente de confianza (DNSSEC fue originalmente previsto para esto); otra parte es que muchos usuarios no comprenden lo suficientemente bien ni sus necesidades ni las opciones disponibles como para promover su inclusión en los productos de los vendedores.
Como el Protocolo de Internet no provee intrínsecamente de ninguna capacidad de seguridad, IPsec se introdujo para proporcionar servicios de seguridad tales como:
- Cifrar el tráfico (de forma que no pueda ser leido por nadie más que las partes a las que está dirigido)
- Validación de integridad (asegurar que el tráfico no ha sido modificado a lo largo de su trayecto)
- Autenticar a los extremos (asegurar que el tráfico proviene de un extremo de confianza)
- Anti-repetición (proteger contra la repetición de la sesión segura).
Modos
Así pues y dependiendo del nivel sobre el que se actúe, podemos establecer dos modos básicos de operación de IPsec: modo transporte y modo túnel.
Modo transporte
En modo transporte, sólo la carga útil (los datos que se transfieren) del paquete IP es cifrada y/o autenticada. El enrutamiento permanece intacto, ya que no se modifica ni se cifra la cabecera IP; sin embargo, cuando se utiliza la cabecera de autenticación (AH), las direcciones IP no pueden ser traducidas, ya que eso invalidaría el hash. Las capas de transporte y aplicación están siempre aseguradas por un hash, de forma que no pueden ser modificadas de ninguna manera (por ejemplo traduciendo los números de puerto TCP y UDP). El modo transporte se utiliza para comunicaciones ordenador a ordenador.
Una forma de encapsular mensajes IPsec para atravesar NAT ha sido definido por RFCs que describen el mecanismo de NAT-T.
Modo túnel
En el modo túnel, todo el paquete IP (datos más cabeceras del mensaje) es cifrado y/o autenticado. Debe ser entonces encapsulado en un nuevo paquete IP para que funcione el enrutamiento. El modo túnel se utiliza para comunicaciones red a red (túneles seguros entre routers, p.e. para VPNs) o comunicaciones ordenador a red u ordenador a ordenador sobre Internet.
Detalles técnicos [editar]
IPsec conta de dos protocolos que han sido desarrollados para proporcionar seguridad a nivel de paquete, tanto para IPv4 como para IPv6:
- Authentication Header (AH) proporciona integridad, autenticación y no repudio si se eligen los algoritmos criptográficos apropiados.
- Encapsulating Security Payload (ESP) proporciona confidencialidad y la opción -altamente recomendable- de autenticación y protección de integridad.
Los algoritmos criptográficos definidos para usar con IPsec incluyen HMAC- SHA1 para protección de integridad, y Triple DES-CBC y AES-CBC para confidencialidad. Más detalles en la RFC 4305.
Authentication header (AH)
AH está dirigido a garantizar integridad sin conexión y autenticación de los datos de origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code (HMAC) através de algún algoritmo hash operando sobre una clave secreta, el contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la posibilidad de emplear NAT, que puede ser implementada con NAT transversal. Por otro lado, AH puede proteger opcionalmente contra ataques de repetición utilizando la técnica de ventana deslizante y descartando paquetes viejos. AH protege la carga útil IP y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes, es decir, aquellos que pueden ser alterados en el tránsito. En IPv4, los campos de la cabecera IP mutantes (y por lo tanto no autenticados) incluyen TOS, Flags, Offset de fragmentos, TTL y suma de verificación de la cabecera. AH opera directamente por encima de IP, utilizando el protocolo IP número 51. Un cabecera AH mide 32 bits, he aquí un diagrama de cómo se organizan:
0 - 7 bit | 8 - 15 bit | 16 - 23 bit | 24 - 31 bit |
---|---|---|---|
Next header | Payload length | RESERVED | |
Security parameters index (SPI) | |||
Sequence number | |||
Hash Message Authentication Code (variable) |
Significado de los campos:
- Next header
- Identifica el protocolo de los datos transferidos.
- Payload length
- Tamaño del paquete AH.
- RESERVED
- Reservado para uso futuro (hasta entonces todo ceros).
- Security parameters index (SPI)
- Indica los parámetros de seguridad que, en combinación con la dirección IP, identifican la asociación de seguridad implementada con este paquete.
- Sequence number
- Un número siempre creciente, utilizado para evitar ataques de repetición.
- HMAC
- Contiene el valor de verificación de integridad (ICV) necesario para autenticar el paquete; puede contener relleno.
Encapsulating Security Payload (ESP)
El protocolo ESP proporciona autenticidad de origen, integridad y protección de confidencialidad de un paquete. ESP también soporta configuraciones de sólo cifrado y sólo autenticación, pero utilizar cifrado sin autenticación está altamente desaconsejado porque es inseguro[1] [2] .[3] Al contrario que con AH, la cabecera del paquete IP no está protegida por ESP (aunque en ESP en modo túnel, la protección es proporcionada a todo el paquete IP interno, incluyendo la cabecera interna; la cabecera externa permanece sin proteger). ESP opera directamente sobre IP, utilizando el protocolo IP número 50.
Un diagrama de paquete ESP:
0 - 7 bit | 8 - 15 bit | 16 - 23 bit | 24 - 31 bit |
---|---|---|---|
Security parameters index (SPI) | |||
Sequence number | |||
| |||
Padding (0-255 bytes) | |||
Pad Length | Next Header | ||
Authentication Data (variable) |
Significado de los campos
- Security parameters index (SPI)
- Identifica los parámetros de seguridad en combinación con la dirección IP.
- Sequence number
- Un número siempre creciente, utilizado para evitar ataques de repetición.
- Payload data
- Los datos a transferir.
- Padding
- Usado por algunos algoritmos criptográficos para rellenar por completo los bloques.
- Pad length
- Tamaño del relleno en bytes.
- Next header
- Identifica el protocolo de los datos transferidos.
- Authentication data
- Contiene los datos utilizados para autenticar el paquete.
Implementaciones
El soporte de IPsec está normalmente implementado en el núcleo con la gestión de claves y negociación de ISAKMP/IKE realizada en espacio de usuario. Las implementaciones de IPsec existentes suelen incluir ambas funcionalidades. Sin embargo, como hay un interfaz estándar para la gestión de claves, es posible controlar una pila IPsec de núcleo utilizando las herramientas de gestión de claves de una implementación distinta.
Por esta razón, hay confusión en los orígenes de la implementación de IPsec que se encuentra en el núcleo de Linux. El proyecto FreeS/WAN realizó la primera implementación completa y de código abierto de IPsec para Linux. Consiste en una pila IPsec de núcleo KLIPS, junto con un demonio (pluto) y muchos scripts de shell. El proyecto FreeS/WAN fue desmantelado en marzo de 2004. Openswan y strongSwan son continuaciones de FreeS/WAN. El proyecto KAME también implementó soporte IPsec completo para NetBSD y FreeBSD. Su demonio de gestión de claves se llama racoon. OpenBSD hizo su propio demonio ISAKMP/IKE, llamado simplemente isakmpd (y ha sido portado a otros sistemas, incluyendo Linux).
Sin embargo, ninguna de estas pilas IPsec de núcleo estaba integrada en el núcleo de Linux. Alexey Kuznetsov y David S. Miller escribieron desde cero una implementación de IPsec de núcleo para el núcleo de Linux alrededor de finales de 2002. Esta pila fue posteriormente lanzada como parte de Linux 2.6, y es llamada por varios "nativa"o "NETKEY".
Por lo tanto, contrariamente a la creencia popular, la pila IPsec de Linux no se originó en el proyecto KAME. Como soporta el protocolo estándar PF KEY (RFC 2368) y el intefaz nativo XFRM para gestión de claves, la pila IPsec de Linux puede utilizarse junto con pluto de Openswan/strongSwan, isakmpd del proyecto OpenBSD, racoon del proyecto KAME o sin ningún demonio ISAKMP/IKE (utilizando claves manuales).
Las nuevas arquitecturas de procesadores de red, incluyendo procesadores multinúcleo con motores de cifrado integrados, han cambiado la forma en que las pilas IPsec son diseñadas. Un Fast Path dedicado es utilizado para descargar el procesado de las tareas de IPsec (SA, búsquedas SP, cifrado, etc). Estas pilas Fast Path deben estar cointegradas en núcleos dedicados con Linux o RTOS corriendo en otros núcleos. Estos SO son el plano de control que ejecuta ISAKMP/IKE de la pila IPsec Fast Path.
Hay bastantes implementaciones de los protocolos IPsec e ISAKMP/IKE. Entre otras:
- 6WINDGate, pila IPsec Fast Path para procesador de red multinúcleo
- NRL [1] IPsec, una de las fuentes originales de código IPsec [2]
- OpenBSD, con su propio código derivado de NRL IPsec
- La pila de KAME, que está incluida en Mac OS X, NetBSD y FreeBSD
- "IPsec" en el software IOS de Cisco [3]
- "IPsec" en Microsoft Windows, incluyendo Windows XP[4] [5], Windows 2000[6], y Windows 2003[7]
- Las herramientas QuickSec de SafeNet [8]
- IPsec en Solaris [9]
- El sistema operativo AIX de IBM
- z/OS de IBM
- IPsec e IKE en HP-UX (HP-UX IPSec)
- "IPsec e IKE" en VxWorks [10]
Lista de RFCs relacionados con IPsec
- RFC 2367
- PF_KEY Interface
- RFC 2401 (sustituye a RFC 1825 y fué sustituida por RFC 4301)
- Security Architecture for the Internet Protocol
- RFC 2402 (sustituida por RFC 4302 y RFC 4305)
- Authentication Header
- RFC 2403
- The Use of HMAC-MD5-96 within ESP and AH
- RFC 2404
- The Use of HMAC-SHA-1-96 within ESP and AH
- RFC 2405
- The ESP DES-CBC Cipher Algorithm With Explicit IV
- RFC 2406 (sustituida por RFC 4303 y RFC 4305)
- Encapsulating Security Payload
- RFC 2407 (sustituida por RFC 4306)
- IPsec Domain of Interpretation for ISAKMP (IPsec DoI)
- RFC 2408 (sustituida por RFC 4306)
- Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409 (sustituida por RFC 4306)
- Internet Key Exchange (IKE)
- RFC 2410
- The NULL Encryption Algorithm and Its Use With IPsec
- RFC 2411
- IP Security Document Roadmap
- RFC 2412
- (sustituye a RFC 1829) The OAKLEY Key Determination Protocol
- RFC 2451
- The ESP CBC-Mode Cipher Algorithms
- RFC 2857
- The Use of HMAC-RIPEMD-160-96 within ESP and AH
- RFC 3526
- More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
- RFC 3706
- A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
- RFC 3715
- IPsec-Network Address Translation (NAT) Compatibility Requirements
- RFC 3947
- Negotiation of NAT-Traversal in the IKE
- RFC 3948
- UDP Encapsulation of IPsec ESP Packets
- RFC 4106
- The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
- RFC 4301 (sustituye a RFC 2401)
- Security Architecture for the Internet Protocol
- RFC 4302 (sustituye a RFC 2402)
- IP Authentication Header
- RFC 4303 (sustituye a RFC 2406)
- IP Encapsulating Security Payload (ESP)
- RFC 4304
- Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 4305 (sustituida por RFC 4835)
- Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
- RFC 4306 (sustituye a RFC 2407, RFC 2408, and RFC 2409)
- Internet Key Exchange (IKEv2) Protocol
- RFC 4307
- Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
- RFC 4308
- Cryptographic Suites for IPsec
- RFC 4309
- Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
- RFC 4478
- Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
- RFC 4543
- The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
- RFC 4555
- IKEv2 Mobility and Multihoming Protocol (MOBIKE)
- RFC 4621
- Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
- RFC 4718
- IKEv2 Clarifications and Implementation Guidelines
- RFC 4806
- Online Certificate Status Protocol (OCSP) Extensions to IKEv2
- RFC 4809
- Requirements for an IPsec Certificate Management Profile
- RFC 4835 (sustituye a RFC 4305)
- Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
- RFC 4945
- The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
Referencias
- ↑ Bellovin, Steven M. (1996). "Problem Areas for the IP Security Protocols". Proceedings of the Sixth Usenix Unix Security Symposium: 1-16. Revisado el 13-11-2007.
- ↑ K.G. Paterson y A. Yau (2006). "Cryptography in theory and practice: The case of encryption in IPsec". Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004: 12-29. Revisado el 13-11-2007.
- ↑ J.P. Degabriele y K.G. Paterson (2007). "Attacking the IPsec Standards in Encryption-only Configurations". IEEE Symposium on Security and Privacy, IEEE Computer Society: 335-349. Revisado el 13-11-2007.
domingo, abril 27, 2008
La SGAE tambien tiene "pufos"
Los problemas de la Sociedad con Hacienda se remontan a 1992 donde se produjo la primera inspección fiscal y un expediente sancionador por retención irregular del pago de derechos de autor, que recurrió hasta el tribunal supremo, rechazando éste su recurso, pagando finalmente deudas tributarias de 12 millones de euros.
Además tiene pendiente otro pago por 5,85 millones de euros de intereses de demora, también recurrido. Para hacer frente a estas deudas la SGAE ha tenido que dotar presupuestariamente gastos extraordinarios por valor de 18,5 millones.
Muy acostumbrada a pleitear, solo en 2007 se resolvieron 122 casos contra instituciones y empresas por el cobro de derechos de autor, siendo favorables el 95% de las sentencias.
¿Para cuándo una auditoría gubernamental completa y no solo fiscal para una sociedad que tiene prohibido por Ley el ánimo de lucro?
jueves, abril 17, 2008
Guia de compras UMPC
Si estás pensando en comprarte un ordenador nuevo por navidad y quieres algo con más movilidad que un ordenador portátil y con más funcionalidades que una PDA, puedes probar con el futuro de la informática: los UMPCs u ordenadores ultra móviles.
Estos ordenadores tienen un tamaño reducido pero albergan una potencia suficiente para usarlos como ordenadores normales, salvo por algunas aplicaciones exclusivas que necesitan un plus de potencia, aún así ya explicamos cuales eran los pros y los contras de los UMPCs.
Aquí en Gizmos os ofrecemos una guía y comparativa con los mejores modelos del mercado, revisando sus pros y sus contras.
Samsung Q1 Ultra:
El Samsung Q1 Ultra es sin duda el UMPC por excelencia a día de hoy, es la evolución del Samsung Q1, uno de los pioneros y ofrece un completo y potente ordenador con pantalla táctil de 7 pulgadas con teclado en los laterales, algo imprescindible para un UMPC.
Su procesador es un Intel McCaslin a 800 MHz, acompañado de 1 GB de RAM, 60 GB de disco duro, WiFi 802.11b/g, Bluetooth 2.0, una pantalla táctil de 7 pulgadas de tamaño con una resolución de 1.024 x 600 píxeles y tarjeta gráfica Intel GMA 945.
Tiene un tamaño de 227.5 x 123.9 x 22.9mm, un peso de 960 gramos y viene con Windows XP Pro Tablet Edition, una webcam frontal de 0.3 megapíxeles y otra trasera de 1.3, 2 puertos USB 2.0, salida VGA y slot para tarjetas SD.
Por si fuera poco, el Samsung Q1 Ultra está disponible por menos de 1.000 euros, teniendo disponible también un modelo con HSDPA incluido por unos 1.300 euros.
OQO model 02:
El OQO model 02 es uno de los UMPCs más pequeños que podemos encontrar, pero no por eso sus prestaciones son bajas. Con una pantalla de tan sólo 5 pulgadas, ofrece además un teclado deslizante completo.
Existen dos versiones disponibles para distintos presupuestos, la primera ofrece un procesador a 1.5 GHz, disco duro de 60 GB y sistema operativo Windows Vista Business, todo por un precio de 1.250 euros. La otra versión tiene un procesador a 1.6 GHz y un gran disco duro de 120 GB con Windows Vista Ultimate instalado, con un precio que asciende a los 1.480 euros.
Ambos modelos vienen con Bluetooth, WiFi a/b/g y con 1GB de memoria DDR2. Destacar también la reciente actualización del OQO model e2 que incluye HSDPA.
Raon Digital Everun Lite:
El Raon Digital Everun Lite, es el UMPC más pequeño junto al OQO model 2, incluso podría pasar por una PDA de tamaño grande. También hay que tener en cuenta que tiene unas prestaciones más bajas que el resto de UMPCs, lo que lo sitúa además en los precios más bajos.
Su procesador es un AMD Geode LX800 a 500 MHz, con 512 MB de RAM y disco duro de 30 GB, prestaciones justas para tirar del sistema operativo Windows XP Home Edition.
Su pantalla tiene un tamaño de 4,8 pulgadas y una resolución de 800 x 480 píxeles, aunque conectado a un monitor puede alcanzar hasta los 1.920 x 1.200 píxeles.
Ofrece WiFi b/g, Bluetooth y teclado integrado junto a una salida VGA, altavoces estéreo, un tamaño de 170 x 83 x 25 mm, un peso de 460 gramos y una autonomía suficiente de 5 a 6 horas de uso.
Destacar el modelo Everun S60H que ofrece un procesador de 600 MHz y 60 GB de disco duro, todo por un precio de unos 916 euros, mientras que la versión anterior se queda en tan solo 680 euros.
ASUS R2E:
El ASUS R2E es uno de los UMPCs más completos, quedando por detrás del Samsung Q1 Ultra solo por el mejor funcionamiento de este.
Su procesador es un Intel Stealy 800, acompañado de 1.280 MB de RAM y un disco duro de 80 GB en el cual viene instalado Windows Vista. Su pantalla táctil de 7 pulgadas ofrece una resolución máxima de sólo 800 x 480 píxeles, algo baja en comparación con los rivales.
Otras características son su webcam de 1.3 megapíxeles, Bluetooth 2.0, DVD Dual Externo por USB, Wifi b/g, receptor GPS, HSDPA, DVBT, teclado plegable y 3 puertos USB, de aquí lo de que es de los más completos.
Sin duda el ASUS R2E es el mejor UMPC en cuando a relación calidad/precio, ya que por 916€ euros nos ofrece todo lo mencionado anteriormente. También existe un ASUS R2HE con HSDPA.
TabletKiosk V7110:
El Tabletkiosk V7110 es un UMPC de lo más normalito, de ahí su precio algo más bajo que el de sus competidores, aunque sus prestaciones también se quedan bastante bajas.
Su procesador es un VIA C7 a 1GHz, junto a 512 MB de memoria RAM y un disco duro de 40GB. Todo esto en una pantalla táctil de 7 pulgadas y con WiFi b/g.
Su sistema operativo es Windows XP Tablet OS y ofrece bolsa de transporte por un económico precio de 842€.
Sony VAIO VGN-UX1XN:
El Sony VAIO VGN-UX1XN fué uno de los primeros UMPCs en aparecer, y aunque muchos no lo consideran un UMPC por su excesivo precio, su diseño y su teclado desplegable argumentan todo lo contrario.
Con un procesador Intel Centrino a 1.33 GHz y acompañado de 1 GB de memoria SDRAM, el Sony Vaio UX es uno de los primeros en añadir un disco duro flash de 32GB para aumentar así la autonomía de la batería.
Su pantalla tiene un tamaño de 4.5 pulgadas y alcanza una resolución de 1.024 x 600 píxeles, ofrece WiFi, Webcam frontal de 0.3 megapíxeles y trasera de 1.3, además de venir con Windows Vista instalado de serie.
El único problema, su excesivo precio, que oscila entre los 1.100 € del modelo más barato y sin disco duro flash, a los casi 2.000€ de los modelos con mejores prestaciones.
HTC Shift:
HTC tiene una gran experiencia en el mercado de las PDAs, experiencia que traslada al mundo de los UMPC gracias a su HTC Shift.
El HTC Shift tiene una pantalla de 7 pulgadas de tamaño y una resolución de 800 x 480 píxeles, procesador Intel Stealey a 800 MHz, sistema operativo Windows Vista Business, 1GB de RAM y disco duro a elegir entre 40 y 60GB.
En cuanto a conectividad ofrece 3.5G (HSDPA), Bluetooth 2.0, WiFi, receptor GPS y lector de huellas, además de una gran cantidad de puertos para tarjeta SIM, USB, VGA, etc. Lástima que la batería solo dure 2 horas.
Como podemos observar es un digno competidor del Samsung Q1 Ultra, además de ofrecer un diseño muy elegante con un precio de unos 1.200 euros.
Amtek T770:
El Amtek T770 se presenta como la alternativa flash al resto de UMPCs, ya que apuesta por versiones de 8 y 16 GB de almacenamiento en discos SSD.
El procesador del Amtek T770 es un VIA C7M NaNo a 1.2 GHz, acompañado de 1 GB de memoria DDRII y gráfica VIA VX700. Viene con sistema operativo a elegir entre Vista o XP Tablet Edition y cámara de 1.3 megapíxeles.
Su pantalla táctil tiene un tamaño de 7 pulgadas, alcanzando los 1.024 x 600 píxeles de resolución. Respecto a conectividad ofrece WiFi b/g y Bluetooth.
Las dos versiones existentes son prácticamente iguales salvo por los discos duros, costando la versión de 8GB unos 960€ y la de 16GB unos 1.135€.
Sin duda no es un mal UMPC pero los discos flash están muy verdes aún como para ofrecer grandes capacidades a precios económicos.
Conclusión:
Si lo que buscamos es un UMPC completo y potente, que pueda dar la cara cuando lo conectemos a una pantalla y lo usemos como PC normal, ese es sin duda el Samsung Q1 Ultra, el cual por unos 1.000€ se presenta como la mejor alternativa sin llegar a ser muy cara, quedando en segundo lugar, el completísimo ASUS R2E.
Al mismo nivel que el Samsung Q1 Ultra colocaríamos al HTC Shift, pensado especialmente para disponer de una completa oficina móvil, incluida tarjeta SIM.
En cambio si buscamos un dispositivo pequeño las mejores opciones son claramente el Everun y el OQO Model 2, siendo el primero ideal para presupuestos bajos y el segundo para los que no escatiman en gastos, ya que el Everun quizás tenga poca potencia para algunas funciones, mientras que el OQO se mantiene al nivel del resto de UMPCs. Si no tenemos problemas económicos la elección es sin duda el Sony VAIO UX.
Guia tomada de: http://www.gizmos.es/6470/ordenadores/guia-compras-umpc/
lunes, abril 14, 2008
Phreack - Manual + software
Software Symbian s60: http://www.phreak.ch/files/s60/bluebox.SIS (bluebox, redbox,dtmf)
Pagina oficial: http://www.phreak.ch
domingo, abril 13, 2008
VirtualCenter - Manual de instalacion y configuracion.
Instalación, configuración y administración de Virtual Infrastructure mediante VMware Virtual Center y VMware Infrastructure Client,
En este procedimiento se explica cómo montar un VirtualCenter para administrar nuestra Infraestructura Virtual, con ello los servidores ESX y sus máquinas virtuales, para ello necesitamos un servidor que tenga el VirtualCenter Server, a él nos conectaremos con el cliente: "VMware Virtual Infrastructure Client" y desde ahí administraremos todo.
- Instalación de VMware VirtualCenter Server - AKI
- Instalación de VMware Virtual Infrastructure Client - AKI
- Administración de VMware Virtual Center / VMware Virtual Infraestructure - AKI
Instalación de VMware VirtualCenter Server,
Lo primero es tener el Virtual Center almacenado en algún servidor. Para instalar el VirtualCenter, nos lo podemos bajar de internet, o si nos conectamos con un navegador a un servidor ESX podremos descargarla desde ahí.
Comienza con un asistente que nos indica que es la instalación de la VMware VirtualCentar Server 2.0, "Next",
Aceptamos el acuerdo de licencia "I accept the therms in the license agreement" & "Next",
Indicamos un nombre y a la organización a la que se pertenece, datos descriptivos, "Next",
El directorio de instalación, por defecto "C:\Archivos de programa\VMware\VMware VirtualCenter 2.0\", podemos cambiarlo o seguir,
Que instalación haremos? normalmente una típica que son los componentes necesarios, podemos quitar la consola de administración, pero no tiene sentido, "Typical" & "Next",
Necesitamos una BD de SQL o de Oracle, si tenemos un servidor en la red meteremos la BD ahí para un rendimiento óptimo, en este caso yo no tengo ningún servidor de base de datos en la red, así que me instalaré una versión limitada de SQL llamada MSDE, me creará una instancia llamada MSDE_VC.
Si es una primera instalación, necesitamos un servidor de licencias, un VMware License Server, así que marcamos la primera opción (este caso), si ya lo tenemos instalado marcaremos la segunda opción, "Next",
Al haberle indicado que vamos a instalar un servidor de licencias, nos pide por un fichero .lic que es el que tiene las licencias. Si no tenemos uno, nos podemos descargar un fichero lic con un tiempo limite, de evaluación. Buscamos nuestra licencia desde "Browse" y continuamos. "Next",
Estos son los puertos que se van a asignar para los siguientes servicios, voy a dejar los que vienen por defecto:
VMware Virtual Infrastructure Web Service HTTPS port: 443
VMware Virtual Infrastructure Web Service HTTP port: 80
VMware VirtualCenter diagnostics port (TCP): 8083
VMware VirtualCenter port (TCP): 902
VMware VirtualCenter heartbeat port (UDP): 902
Necesitamos un servidor web para el VirtualCenter, usaremos Tomcat y el puerto predeterminado será el 8086, vamos a marcar los dos checks, para que arranque Tomcat automaticamente con Windows, y marcamos el otro check para que nos arranque Tomcat ahora. "Next",
Bien, comenzamos a installar "Install",
Nos instala MSDE si lo hemos elegido antes...
... nos instala el servidor de licencias si anteriormente lo hemos elegido...
... instalando VirtualCenter...
"Finish" y ya ha finalizado el proceso de instalación de la parte servidor.
Instalación de VMware Virtual Infrastructure Client,
Una vez instalada la parte de VMware VirtualCenter, nos falta el cliente, que será el programa que usaremos para gestionar el entorno virtual, para instalarlo lo haremos conectandonos con un navegador al VirtualCenter o a un servidor ESX. Por supuesto esta instalación la haremos en un puesto desde donde querramos tener acceso a la gestión VI, lo normal es desde nuestro puesto con Windows XP (x ejemplo).
Abrimos un navegador contra el servidor donde hemos instalado VMware VirtualCenter, nos bajamos e instalamos pinchando en "Download the VMware Infrastructure Client".
Comenzará un asistente breve el cual nos instalará el cliente, iniciamos la instalación pinchando en "Next",
Aceptamos el acuerdo de licencia "I accept the terms in the license agreement" y continuamos "Next",
Indicamos un nombre y a la organización a la que se pertenece, datos descriptivos, "Next",
Ese es el path por defecto de la instalación del cliente, podemos cambiar la ruta si queremos desde "Change", continuamos, "Next",
Y ya comenzamos la instalación desde "Install",
... esperamos unos segundos...
Bien, "Finish" ya por fin hemos acabado con todo el proceso de instalación, ya podemos jugar un poco :D
Administración de VMware Virtual Center / VMware Virtual Infraestructure,
Lo primero para comenzar es abrir el "VMware Virtual Infrastructure client", es el cliente con el que nos conectaremos al VMware VirtualCenter,
Metemos el nombre del servidor o la dirección IP del VirtualCenter, y un usuario/contraseña con credenciales de administrador para administrarla y pulsamos sobre "Log In"...
Al de unos segundos nos habrá abierto la consola, en este documento se comentará por encima las posibilidades que nos da, aunque son muchísimas más. Lo primero que vermos es un inventario de los hosts (servidores ESX), si tenemos algún clúster... Lo primero para organizar es crearse un Datacenter que será donde trabajaremos en un futuro, yo ahí meteré mis servidores ESX, mis máquinas virtuales... Así que sobre "Hosts & Clusters" > botón derecho > "New Datacenter".
Le indicamos un nombre, en mi caso, "Bujarra". Vemos en "Recent Tasks" las tareas que vamos realizando y su progreso, si se han finalizado o no.
Bueno, en mi caso, cómo voy a crear un clúster para que haya un sistema de alta disponibilidad con HA o DRS, luego meteré dos hosts en él y sus correspondientes máquinas virtuales, para crear un clúster, sobre el Datacenter con el botón derecho "New Cluster..."
Le indicamos un nombre al clúster, yo que soy muy original le llamaré CLUSTER, y marcamos los checks que nos interesen, tenemos dos:
"VMware HA" es para que podamos mover una máquina virtual de un host a otro migrandolo y sin parar la maquina virtual. Y también por supuesto por si se cae un host que las máquinas virtuales que tenga en uso en ese momento se encenderían de forma automática en otro host (esta última prueba yo no la puedo realizar con este documento, así que al finalizar el mismo, simplemente, quita el cable de alimentación de un ESX, algo brusco, pero comprobarás cómo las máquinas que estaban en uso en un host pasan a iniciarse en el otro host.
"VMware DRS", esto nos permite, primero, crearnos los pool de recursos para gestionar el hardware que queremos que tengan ciertas maquinas virtuales; y por otra parte tiene un sistema que según cómo lo configuremos nos aconseja o nos hace el siguiente trabajo de forma automática: Si un host tiene X máquinas virtuales y tenemos otro host más libre de carga, nos sugerirá que movamos alguna maquina virtual al host más liberado, o directamente nos la migrará él.
Marcamos ambas y "Next",
Al seleccionar el VMware DRS, tenemos tres opciones:
"Manual", nos sugiere que migremos ciertas máquinas virtuales pero él nunca nos las moverá.
"Partially automated", al arrancar una máquina virtual nos la arrancará en el host que esté más liberado pero luego no nos las moverá entre los host, simplemente nos lo aconsejará.
"Fully automated", al arrancar nos pone las máquinas virtuales en el host más libre de carga y según la cantidad de estrellas que tenga una maquina virtual nos la moverá a otro host o no, podemos configurarlo desde la barra, desde "Conservative" a "Aggressive".
Marcamos la que nos interese y "Next",
En "VMware HA" especificaremos cuantos fallos nos permitirá de hosts en el clúster, lo normal es 1.
Comprobamos que todo está bien y finalizamos la creación.
Bien, ahora no queda otra cosa que agregar a los servidores ESX, para ello, sobre el clúster con botón derecho "Add Host..."
Indicamos el nombre de los servidores ESX, en mi caso serán host1 y host2, los agregamos uno a uno. En este caso pongo o bien el nombre o bien la IP y el usuario para poder conectarnos a él. "Next",
Nos ve la información del servidor ESX, continuamos, "Next",
En que Datacenter meteremos las máquinas virtuales de este host...
Comprobamos que todo está bien y "Finish",
Habría que agregar todos los hosts que tengamos, en mi caso sólo estos dos. Ahora, desde uno de ellos repasaremos las pestañas que tenemos, la primera "Summary", veremos un resumen del hardware del ESX, que tipo de servidor es, cuantas máquinas virtuales tiene, cuanta memoria tiene disponible y cuanta ocupada al momento, idem con la CPU; y los Datastore que es donde se almacenarán las máquinas virtuales. Además tenemos más opciones por si queremos apagarlo, reiniciarlo...
En la pestaña de "Virtual Machines", veremos que máquinas virtuales tiene, si están encencidas o no, cuanta CPU y memoria están consumiendo y su estado, muy importante. Desde aquí también podremos crear máquinas virtuales.
En la pestaña de "Performance" tenemos una gráfica del estado de rendimiento del servidor ESX, consumo de CPU, memoria... podemos personalizar este cuadro.
La pestaña "Configuration" es donde podremos configurar bastantes opciones, cómo cuantos procesadores queremos asignar a las MV de este host, memoria, adaptadores de red... Podremos configurar parametros de red desde aquí así como el tema de licencias. Desde "Add Storage" es desde donde le he agregado el almacenamiento común llamado "iSCSI" para poder crear el clúster y almacenar las máquinas virtuales en él.
Tenemos más pestañas cómo la de "Tasks & Events" que simplemente son tareas de mantenimiento programadas por nosotros o eventos. La de "Alarms" es una pestaña donde veremos alarmas del host, por ejemplo si una máquina virtual está consumiendo más de lo normal o se acerca a los límites establecidos. En la de "Permissions" es donde daremos permisos si queremos a otro administrador sobre este host para que también lo pueda administrar. Y la pestaña de "Maps" es un breve mapa de la configuración, de forma visual.
Después de meter los host, lo que se suele hacer es crear los pool de recursos o "Resource Pool"; esto es una forma muy cómoda de compartir el hardware de un host, para que se reserve un mínimo por ejemplo de rendimiento a las máquinas que nos interese y no nos tire otras máquinas. Por ejemplo crearía un pool de recursos para meter un servidor virtual de SQL y si le hacen grandes consultas y tiene picos de CPU, que los tenga sólo esta máquina virtual y su pool y no me afecte para nada a la CPU de otras máquinas virtuales. Simplemente para reservar recursos y que se respeten las MV. Para crear uno, sobre el clúster con botón derecho "New Resource Pool..."
Le indicaremos un nombre, por ejemplo para hacer pruebas, yo para las máquinas virtuales del dpto. de Producción. Compartimos la CPU de forma normal, y le reservaré como mínimo 1Ghz de CPU por si alguna máquina de otro pool quiere usar más CPU, este gigaherzio no me lo cojerá :D Y hago lo mismo con la memoria RAM, le reservo como mínimo 512Mb de RAM a este pool y de máximo que podrán usar será 1Gb (las cantidades numéricas son ejemplos, es que mis hosts eran muy pobres :D). Tenemos la posibilidad de marcar "Unlimited" en algún caso para no poner límite máximo de CPU/RAM. "OK".
Ahora, vamos a ver cómo crear una plantilla de una máquina virtual para luego no tener que instalar de nuevo el sistema operativo en otra máquina virtual, si no usar estas plantillas, para empezar deberemos de cambiarnos a "Virtual Machines And Templates".
Y crearemos un directiorio donde meteremos estas máquinas virtuales que usaremos cómo plantilla, sobre el Datacenter con botón derecho "New Folder"
Y al directorio este le llamaremos por ejemplo "Plantilla", ahí meteremos plantillas de MV, por ejemplo esa que se ve en la imagen llamada "Plantilla XP", lo usaremos más adelante.
Bueno, volvemos a "Host And Clusters" para crear ya por fín una máquina virtual!!!
Bien, para crear una máquina virtual, sobre el pool de recursos que hemos creado antes o en el que nos interese, botón derecho "New Virtual Machine..."
Y este asistente ya es facilon, simplemente es para crear una máquina virtual, seleccionamos la configuración de la MV "Tipical" o "Custom"
Indicamos el nombre de la máquina virtual y en que carpeta la vamos a guardar del inventario. Por ejemplo si queremos que sea una plantilla la guardaremos en la del inventario de Plantilas, o si es una MV para el departamento de Desarrollo pues en su inventario o directamente en uno genérico llamado "VM". "Next"
Seleccionamos donde la vamos a almacenar, los ficheros de la máquina virtual, si queremos usar un clúster, tienen que ir en un almacenamiento compartido al que puedan acceder multiples hosts y no sólo uno, así que lo seleccionamos y "Next",
Seleccionamos el S.O. y "Next",
Cuantas CPUs tendrá la MV, "Next",
Le asignamos ya la memoria RAM...
Y cuantos adaptadores de red queremos ponerle a la máquina virtual, y si queremos que esten conectados al arrancar la máquina virtual.
Indicamos la capacidad para el disco duro de la máquina virtual...
Comprobamos que está todo bien y finalizaríamos. "Finish".
Vemos ahora la organización que tenemos desde la consola. Repasamos que pestañas tiene una máquina virtual, comenzamos por la primera, marcamos una máquina virtual, por ejemplo "DC" y en la pestaña "Summary" podemos ver como su nombre indica un breve resumen de la máquina virtual, su estado, su S.O., sus recursos...
Desde la pestaña "Performance" veremos el rendimiento del hardware virtualizado,
En "Console" veremos la propia consola del S.O. si es un Windows desde ahí podremos mover el ratoón o si es otro sistema operativo será desde donde lo gestionemos.
En "Permissions" son los permisos que queremos dar a los demás administradores sobre esta máquina virtual, podemos agregar aquí un usuario y que tenga control total sobre esta MV, así que cuando abra el VMware Virtual Server Client y se conecte a VMware VirtualCenter con su usuario sólo verá las máquinas vituales a las que tendrá acceso.
Aquí ahora veremos cómo mover/migrar una máquina virtual de un host a otro sin detenerla, por ejemplo para cualquier tarea de mantenimiento sobre un host, por supuesto los usuarios no se darían cuenta que la máquina sobre la que están trabajando se está moviendo de un host a otro. Para moverla manualmente, la seleccionamos y con botón derecho "Migrate..."
Seleccionamos el host de destino a donde la queremos mover, por ejemplo "host1", "Next",
Y a que "Resource Pool" si es que la queremos cambiar de pool de recursos, "Next",
Y la prioridad de movimiento, alta o baja,
Bueno, comprobamos que todo está bien y le damos s "Finish", nos comenzaría a mover la máquina virtual de un host a otro; desde la barra de abajo de "Recent Tasks" podremos ver el estado de la migración de la MV, tardará dependiendo de los recursos de la máquina virtual.
Y poco más se puede comentar sobre VirtualInfraestructure en un documento, es probar los servidores ESX y administrandolo todo con las herramientas "VirtualCenter Server" y "Virtual Infrastructure Client".
www.bujarra.com - Héctor Herrero - nheobug@bujarra.com - v 1.0