Se supone que el usuario medio no debe acceder a esas carpetas, y ocultándolas se simplifica el uso, ocultando las complejidades del sistema.

En este caso, la carpeta que ha “desaparecido” es Library (o Librería), donde se almacenan los ficheros de soporte de las aplicaciones, y en un directorio en particular, las preferencias de usuario para cada una de estas. Desafortunadamente, muchas soluciones a problemas pasan por acceder a estas carpetas, y borrar ficheros o directorios de las mismas.

Aunque personalmente siempre accedo mediante una terminal (hay costumbres que nunca se quitarán), hay quien prefiere acceder desde el Finder o desde otra aplicación, sin más complicaciones.

Por lo pronto, se me ocurren cuatro métodos para acceder a estar carpeta en Mac OS X Lion, tres temporales y uno definitivo:

• Menú Ir de Finder.
  Abrimos una ventana de Finder, y en el menú superior, en la opción Ir, elegimos Ir a la carpeta…. Ahí teclearemos la ruta ~/Library y nos abrirá una nueva ventana ubicada en ese directorio.
• Mediante una terminal.
  La carpeta Library no está inaccesible, solo oculta. Por tanto, desde la terminal siempre estará accesible. Si quieres abrir una ventana de Finder desde la terminal, no tendrías más que lanzar el siguiente comando:Open ~/Library

• El tercer método, desde Finder y el menú Ir de nuevo. En esta ocasión, el “truco” consiste en pulsar la tecla cmd mientras está desplegado el menú Ir. Aparecerá una nueva opción llamada Biblioteca.
• El cuarto método, es el definitivo. Se trata de cambiar los atributos del directorio para que deje de ser oculta. Para ello, desde una terminal, tecleamos el siguiente comando
  chflags nohidden ~/Library

Resulta curioso que siendo una carpeta tan importante, Apple no sea consistente en la nomenclatura que le da, siendo Library a nivel del sistema de archivos, pero utilizando como localización unas veces Library y otras Biblioteca.

• Comprobar las instalaciones de MPIO y MPIO Manager en todos los nodos del clúster.
• Activar VMQ en las tarjetas de red.
• Considerar excluir del análisis del antivirus los procesos vmms.exe y vmswp.exe, así como los directorios que albergan los ficheros de configuración y los discos virtuales de las maquinas.
• Cambiar la localización por defecto de las maquinas virtuales que se almacenen en la maquina host, por defecto se ubican en el disco donde está instalado el sistema operativo de base, se recomienda que se cambie para que apunte al almacenamiento de la SAN
• Elegir discos de tamaño fijo en vez de dinámicamente expansibles, el rendimiento será mejor, la tendencia a la fragmentación se reducirá y la gestión de los discos físicos será más sencilla, se recomienda la desfragmentación de las unidades del Host previa a la creación de nuevos discos virtuales.
• Utilizar un producto capaz de realizar una monitorización consciente de la virtualización como por ejemplo System Center Operations Manager 2007.
• Usar backups a disco a través de VSS y copiar después a través del sistema actual de backup.
• Comunicación entre nodos por IPv6.
• Configurar los graficos para el mejor rendimiento en las VM.
• Usar adaptadores virtuales SCSI en vez de IDE (excepto para el SO).
• La paginación dentro del guest es perjudicial, ajustar la memoria adecuadamente.
• Windows 2008 esta preparado específicamente para Hyper-V y es el mejor guest posible. Con diferencia.
• Para máquinas 2003: NTFSDisableLastAccessUpdate HKLM\System\CurrentControlSet\Control\FileSystem\ (REG_DWORD)
• Configurar las tarjetas de red para habilitar offload LSOv1.
• Para usar offload y VLANS es necesario que el interfaz soporte NDIS_ENCAPSULATION_IEEE_802_3_P_AND_Q_IN_OOB encapsulation.
• Afinidad de interrupciones entre procesadores y tarjetas de red (intpolicy).
• No usar interfaces de red legacy.
• Quitar los dispositivos que no se utilicen de las VM (CDs, etc.).
• No tener la consola de hyper-v abierta en el servidor.

Son algunas notas, tomadas sin orden, pero que conviene observar para, en muchos casos, incrementar considerablemente el rendimiento de la máquina Guest.

Sin encontrar ninguna razón en los logs del sistema, comprobando que el proceso no responde a las señales de Kill, y que queda en estado zombie al finalizarlo, en una medida desesperada (por la esperanza en que fuese la solución) he pasado Onyx, sin que la situación mejorase.

Finalmente, he encontrado la solución en un comentario de un mensaje del ¡año 2004!, para Mac OS X 10.3 Panther.
Resulta que si tienes enchufado un iPod Firewire y este está completamente cargado, SystemUIServer deja de responder.

Así que he desenchufado mi iPod 3G del puerto Firewire, y ¡voilá! un segundo después SystemUIServer vuelve a la vida. Como curiosidad, el iPod Classic sigue conectado y cargado, aunque este es por USB.

Un bug que existe desde (al menos) Mac OS X 10.3 Panther, y que parece que se repite con cierta frecuencia en 10.5 Leopard y 10.6 Snow Leopard (desconozco si en 10.4 Tiger ocurría, pero cabe pensar que si).

Si es así, has estado cerca de la solución, seguro.

El método a seguir es:

Ir al Menú -> Ajustes -> Aplicaciones -> Administrar Aplicaciones, buscar Google Apps, seleccionarlo y entonces pulsar Borrar datos.

Ya podrás volver a abrir una aplicación de Google, Gmail por ejemplo, y aparecerá el asistente para configurar tu cuenta Google asociada al teléfono.

Me lo dejo por aquí apuntado por si vuelvo a necesitarlo.

Un caso habitual se produce cuando nuestro equipo pertenece a la red local de nuestra empresa, por ejemplo, a la vez que tiene acceso a otra red en la que hay dominios diferentes del local y sin posibilidad de relacionarlos. Pongamos por ejemplo, internet.

En este escenario, tenemos un equipo que queremos que resuelva direcciones de dominios válidos en internet y a la vez que resuelva direcciones de nuestro dominio local, que no tiene por que ser válido en internet, ni estar registrado como tal.

En una configuración típica, especificaríamos una lista de servidores DNS a utilizar en orden, de forma que las consultas se harían siempre al primero de la lista y solo se consultaría al segundo si el primero no respondiese por algún motivo.

En este caso, si el primer servidor DNS de la lista es el correspondiente a nuestro dominio local, este resolverá los nombres que conoce, y no lo hará para dominios públicos, como por ejemplo google.es. Podríamos configurar nuestro(s) servidor(es) DNS locales para que reenviasen las peticiones que no supiesen resolver a otros servidores, incluso públicos.

De hecho, este sería el funcionamiento normal y lógico de los servidores DNS.

El problema se plantea cuando nuestros servidores DNS locales no pueden reenviar las peticiones a servidores públicos, siendo la razón más común que nuestra red se encuentra aislada de internet.

Resumiendo, no podemos aprovecharnos de los reenvíos de los servidores DNS, porque ninguno de los dos disponibles conoce nada del otro, ni tiene forma de conocerlo.

Para solventarlo, podemos instruir a nuestro cliente DNS (resolver) para que utilice en cada momento el servidor DNS que nos interese. Para ello, hemos de crear un fichero, con el nombre de la red privada, en:

/etc/resolver/dominiolocal.com

En este fichero, pondremos los servidores DNS que queremos que resuelvan las peticiones para el dominio dominiolocal.com, de la forma:

nameserver 1.2.3.4
nameserver 1.2.3.5

De esta forma, nuestro cliente DNS utilizará siempre los servidores de nombres que tengamos definidos en nuestro sistema (en /etc/resolv.conf) para resolver cualquier dominio (todos los públicos), mientras que cuando se le solicite la dirección de un equipo de nuestra red local (equipo.dominiolocal.com), consultará a los servidores definidos en /etc/resolver/dominiolocal.com.

Más información sobre el fantástico cliente DNS de Mac OS X en:

man 5 resolver

• Promover espacios de discusión de ideas tendentes a mejorar los servicios al ciudadano por parte de las AA.PP. a través de las Tecnologías de la Información y la Comunicación
• Mantener al ayuntamiento de Adeje como referente en el ámbito de las Web de Administraciones Públicas Locales.
• Aumentar los niveles de acceso a la Sociedad de la Información de la vida socioeconómica municipal a través de la organización de eventos TIC de alto nivel en el que puedan participar y compartir conocimientos las empresas del municipio.

Se puede consultar el programa, conocer más a los ponentes, inscribirte (inscripción gratuita) en la web del evento. También puedes seguirlo por twitter y por Facebook.

Allí estaremos, bien atentos y prestos a tomar buena nota de todo, que el programa promete.

El primer paso es sacarlo del todopoderoso Google. Ya hay quien dice que si no estás en google no existes, así que, como precisamente esa era mi intención, dejar de existir para el público, hacia ahí dirigí mis pasos.

Básicamente hay dos acciones a realizar. Una, evitar que los buscadores sigan indexando, y otra, intentar que olviden todo lo que ya han indexado.

La primera acción se consigue con el fichero robots.txt, un fichero que colocado en el directorio raiz de la web, indica a las arañas de los buscadores cómo deben corportarse con nuestro sitio. Así, pues, el primer paso es colocar el fichero con el siguiente contenido:

User-agent: *
Disallow: /

Con esto ya hemos conseguido que los buscadores (todos, como se indica en el User-agent: *) ya no indexen nada de nuestro dominio (deshabilitamos todo a partir de la raiz, es decir, todo el sitio).

El siguiente paso, es eliminar el contenido indexado. Empezamos por google, por ser el más utilizado hoy en día.

Necesitamos tener cuenta en Google y nuestro sitio verificado. Para ello, accedemos a nuestra cuenta y desde ahí vamos a las Herramientas para Webmasters o Webmaster tools. Añadimos nuestro sitio, en caso de no tenerlo aún y lo verificaremos.

Para verificar que el sitio es nuestro, Google nos indicará como proceder, pudiendo elegir entre modificar la cabecera de nuestra página índice añadiendo un campo meta, o bien, subiendo o creando un fichero con un nombre específico.

Hecho este paso, le diremos a google que prosiga con la verificación, con lo que ya habremos demostrar a Google que el sitio es nuestro.

Para no hacerlo eterno, y dada la facilidad con la que se hace, solo nos queda hacer click sobre nuestro dominio y a continuación elegir las Herramientas y dentro de estas, la Eliminación de URL, donde haremos una nueva solicitud de eliminación, pudiendo elegir qué eliminar (el sitio entero, un directorio, páginas o imagenes específicas).

Hecha la solicitud, quedará pendiente hasta que en la siguiente indexación, Google eliminará todo el contenido solicitado de su índice.

Yahoo.

La filosofía es la misma. En este caso accedemos a Yahoo! Site Explorer, donde realizaremos idénticos pasos que los descritos en el caso de Google para verificar nuestro sitio. Una vez verificado, podemos explorar el índice que tiene Yahoo! de nustro sitio, y en los resultados de la exploración junto a los enlaces a nuestro sitio, aparecerá un botón (al pasar el ratón sobre cada fila) que nos permitirá borrar una URL y/o path. Ahí haremos la solicitud, que al igual que en el caso de Google, quedará programada. Comentar que no es necesario borrar uno por uno todos nuestros enlaces. Se pueden utilizar rutas y así se borra todo lo contenido en esa ruta.

Microsoft Live Search.

Hasta el momento, desconozco la forma de salir de este buscador. Parece ser que se puede realizar algún tipo de solicitud al respecto, mediante correo electrónico y un formulario de solicitud genérico de incidencias. No me preocupa sobremanera, puesto que el sitio en cuestión lo cambiaré de ubicación y estará protegido de las arañas de los buscadores. En cualquier caso, un punto negativo para el buscador de Microsoft.

Archive.org

El último sitio del que quería eliminarlo es de archive.org, o “la máquina para viajar atrás en el tiempo”, como se definen. Este sitio mantiene un historial de nuestra web a lo largo del tiempo, pudiendo consultar, por ejemplo, como era el diseño del sitio hace cuatro años. Para sacar nuestro sitio de este particular indexador, basta con el fichero robots.txt descrito antes. La próxima vez que archive.org indexe nuestro sitio, acatará el contenido de dicho fichero y bloqueará nuestro contenido.

Y así, hemos logrado limpiar un poco internet. Seguramente sean muy raros los casos en que alguien quiere hacer desaparecer por completo su sitio, pero seguro que es mucho más común el interés por eliminar una ruta en particular, un fichero, o alguna imagen determinada, y para eso, también nos sirven estas herramientas.

Es cierto que, aunque las ventajas del greylisting superan, a mi parecer, las desventajas, puede no ser el caso para todos, pudiéndose convertir en algún momento en un problema inaceptable.

Esta técnica adolece principalmente de una molestia y de un problema.

La molestia del greylisting.

Los correos se demoran.

Puede darse la circunstancia de que esto no sea aceptable. Es cierto que es una molestia, cuando, por ejemplo, nos registramos en algún sitio y tenemos que esperar el tiempo de embargo para que nos llegue el correo de registro. Esos minutos se hacen eternos, haciendo dudar al receptor de si ha puesto correctamente su dirección de correo. No es raro el caso en que el usuario insiste en registrarse una y otra vez en ese servicio, probando incluso con direcciones distintas. Lógicamente, si las direcciones de correo radican en servidores que utilicen greylisting, no conseguirá nada más que recibir un aluvión de correos de registro una vez pasado el tiempo de embargo.

Esto es lo que yo denomino una molestia, y que para algunos, ciertamente, puede alcanzar el grado de problema. A veces es necesaria la inmediatez en el correo. La solución: paciencia. No hay más.

El problema del greylisting: distintos servidores de correo.

Aquí si que existe un problema se mire por donde se mire. Recordando el funcionamiento del greylisting, este se basaba en guardar una terna (<dirección IP del emisor>,<correo electrónico del emisor>,<correo electrónico del receptor>). Esta terna se almacenaba, y se devolvía un error al servidor emisor, quien reintentaría el envío más tarde.

El problema surge cuando el emisor no es un servidor único, sino es parte de una granja de servidores, donde el correo no tiene por que ser enviado siempre desde la misma dirección IP. Este es el caso de Gmail, por ejemplo, que dispone de una cantidad ingente de servidores de correo, y es muy común que el primer intento de correo y sus posteriores reintentos no provengan de la misma dirección, por lo que la terna nunca será la misma y el correo no se aceptará.

Perder un correo válido no es aceptable. Cualquier lucha contra el spam debe basarse en esta máxima.

Para paliar este problema, se utilizan las listas blancas, con rangos de direcciones IPs conocidas. De esta forma, le podemos indicar a nuestro sistema de greylisting que si el emisor proviene de una de las direcciones IP contenidas en nuestras listas blancas, se acepte el envío (siempre y cuando supere el resto de pruebas que realicemos a los mensajes entrantes, lógicamente).

Algunos sistemas de greylisting son capaces incluso de aprender e ir alimentando el fichero de listas blancas, detectando las granjas de servidores.

RedIRIS provee dos listas muy interesantes para añadir a nuestra solución de greylisting: La lista ESWL y la lista MTAWL. En la lista ESWL figuran las IPs de los servidores de correo salientes gestionados por ISPs españoles miembros del Foro ABUSES. La lista MTAWL es una lista de IPs de servidores de correo propuestos y validados por los miembros del Foro ABUSES de servidores de correo cuyo tráfico consideran no debe ser bloqueado (Hotmail, Gmail, Yahoo, bancos, agencias de viaje, etc).

La técnica del greylisting normalmente se acompaña de otras, como el RBL, SPF, DomainKeys, etc. Se pueden combinar estas técnicas con el greylisting, de forma que no sean comprobaciones independientes sino que se complementen. De esta forma, por ejemplo, podemos relajar las condiciones de la comprobación SPF, y en vez de denegar el acceso a quien no lo cumpla, y a quien lo cumpla dejarlo pasar para realizarle luego el greylisting, podríamos cambiar el test de SPF para que sea más permisivo y asi ayudar al greylisting. En este ejemplo, haríamos que quien pase el SPF sea aceptado automáticamente por nuestra solución de greylisting, haciendo que solo caiga en ella quien falle la prueba del SPF. Podemos meter en la ecuación también la comprobación de DomainKeys.

Lo que está claro es que hay un mundo de posibilidades (y de trabajo) para luchar contra el SPAM, que no es solo la molestia de un correo no deseado en nuestro buzón, sino que también es causa, como ya he comentado alguna que otra vez, de gastos importantes de recursos, y que lamentablemente no existe una solución de enchufar-y-listo válida para todas las situaciones.

El funcionamiento del troyano parece ser que consiste en, con la excusa de una corrupción en un fichero de preferencias, solicitar la contraseña de administrador parar poder reparar el fichero y aprovechar esa escalada de privilegios para, en su lugar, enviar el hash de las contraseñas a un determinado servidor.

En principio, podríamos pensar, que bueno, visto que pide la contraseña de administrador, nadie va a caer en el engaño, porque ¿quien va a dar la contraseña de administrador?. Lamentablemente, mucha gente. Y es normal, porque ante la costumbre de los sistemas operativos de preguntar continuamente por la contraseña de administrador, aparece la costumbre del usuario de dar permiso de forma casi automática. Los usuarios de Windows Vista, sufridores de este mal en un nivel superior (por la frecuencia con que lo pregunta Windows Vista) saben lo que es (¿cuantos no han desactivado ya el UAC?).

Pero este troyano, que no debería de preocuparnos más allá de un simple ataque que dependen de la interacción del usuario, nos hace pensar sobre otra vulnerabilidad mucho más grave que aun no ha sido resuelta.

Hace unos días se hablaba de Root Exploit in Apple Remote Desktop, que permite que cualquier usuario o aplicación pudiese ejecutar comandos como root sin ningún tipo de autorización.

Sumando ambos casos, es facil ver el resultado de la ecuación: cualquier programa malintencionado puede obtener los datos que consigue el troyano sin necesidad de solicitar autorización.

Esto es un problema grave. Muy grave. Cualquier programa puede, sin ningún tipo de problemas, tomar el control completo de nuestro Mac, obtener los datos que quiera, y si así lo quiere, destruir su contenido sin ningún impedimento.

La solución pasa, como siempre, por no descargar y ejecutar programas de fuentes no fiables (¡vaya novedad!). Mala solución, cierto, pero es la que nos queda.

Y aunque no tenga que ver directamente, no pierdo la oportunidad de aprovechar para recomendar la instalación de Little Snitch, un indispensable en seguridad en nuestros macs.

Este era el precio a pagar que ya auguraban por el aumento de la cuota de mercado de los Macs.

Habrá que irse haciendo a la idea de que los antivirus van a empezar a tocar el timbre de Mac OS X con insistencia.

Existen múltiples sistemas de comprobar el grado de validez de un correo en el momento de su entrada en el servidor destino, que es cuando queremos pararlo. Recordemos, cuanto antes lo paremos mejor: menos tráfico consumido, menos recursos consumidos y antes le decimos al spammer que no nos la ha colado.

Entre las comprobaciones básicas, podemos encontrar las listas negras (listas dinámicas de direcciones IP conocidas de spammers. Si el emisor está en una de estas listas, terminamos la conexión), fallo en la validez del protocolo SMTP (obligamos a seguir estrictamente todos los protocolos, incluyendo el de identificarse correctamente el servidor emisor), comprobación de que el emisor existe (el servidor receptor hace una nueva conexión hacia el servidor de correo del emisor, para comprobar que el remitente es una dirección válida).

Tras esta primera batería de comprobaciones, vendría la aceptación del correo en si. Otra medida que se puede utilizar es ir analizando el correo a medida que va entrando, y desde que se tenga la certeza de que es spam, un virus, o incumpla alguna de las normas, terminar la conexión en ese momento, rechazando el correo y dejándolo a medias.

Dependiendo de la agresividad de los filtros, los correos no se dejarán entrar o se aceptarán todos y se marcarán como SPAM para que el usuario final los revise. No aceptarlos tiene el peligro de perder correos válidos, y aceptarlos todos tiene el peligro de que cara a los spammers nuestra dirección de correo es buena y acepta el SPAM, por lo que no saldremos nunca de esas listas.

Estos métodos necesitan cada vez de un mayor consumo de recursos, al ir adaptándose los spammers para saltárselos, lo que obliga a mejorar las medidas de detección, haciéndolas más complejas y por tanto necesitando más tiempo de cómputo.

Es aquí donde surgen una serie de medidas interesantes y de alto impacto. Son tres de las que voy a hablar: Greylisting, SPF y DomainKeys.

GreyListing.

Hoy por hoy, es mi medida preferida. Tiene una eficacia increíble para la sencillez de la idea. Es cierto que tiene alguna contrapartida, pero los resultados son tan impresionantes que creo que merecen la pena.

Su funcionamiento se basa en quedarse a medio camino entre las listas blancas (white lists), listas de emisores y/o receptores válidos y confiables, y las listas negras (black lists), listas de emisores y/o receptores denegados.

Las listas blancas se utilizan para saltarse las comprobaciones de correo de ciertos remitentes que sabemos que son seguros, o para algunos receptores que no quieren que su correo pase por ningún filtro. Las listas negras, imagino que a estas alturas ya se sabe para que son.

A medio camino, las listas grises. El funcionamiento consiste en denegar inicialmente cualquier intento de entrega de correo, informando al emisor de que en ese instante no podemos aceptar su correo y que vuelva a intentarlo más tarde (código de error 451 de SMTP).

Antes de rechazar el correo, el receptor ha tomado nota y apunta la siguiente tripleta: <Dirección IP del emisor, dirección de correo del emisor, dirección de correo del receptor>. Esta tripleta se “embarga” durante un tiempo definido por el receptor.

Si el emisor del correo es un servidor de correo que cumple con los estándares, volverá a intentar la conexión pasado un tiempo. Si aun no se ha cumplido el tiempo de embargo, el servidor receptor volverá a informar del mismo error, indicando que aun no puede recibir el correo.

El emisor volverá a intentarlo más tarde, y eventualmente llegará el momento en que en su intento ya haya pasado el tiempo de embargo, por lo que el receptor aceptará el correo sin más problema.

Por el lado del receptor, una vez aceptado el correo, se almacena la tripleta y se mantendrá válida durante un tiempo definido por el servidor, por ejemplo un mes. Cualquier correo posterior que coincida con la misma tripleta, se aceptará directamente, sin demora, y además, pondrá a cero el contador de esa tripleta, dándole de nuevo otro mes de validez.

La gran pega de este método es que el primer correo desde un emisor, tardará en entrar. Al menos tanto como tengamos definido como tiempo de embargo, que puede variar desde 5 minutos hasta varias horas.

Y aquí surge la pregunta ¿Y en qué ayuda esto en la lucha contra el SPAM?. La mayoría del SPAM se genera desde equipos zombies, o mediante programas encargados de lanzar miles de correos a listas de destinatarios, pero que no son servidores de correo completos, o que no respetan todos los requisitos del protocolo SMTP. También se puede deber al hecho de que el coste, para estos emisores de spam, de reintentar enviar un correo con las direcciones que fallan es demasiado alto (errores de destinatario no válido, buzón lleno, servidor no puede tramitar la solicitud en este momento, correo rechazado por ser spam…).

El hecho es que estos emisores masivos no vuelven a intentar enviar una vez recibido el error inicial, con lo que los hemos descartado sin siquiera tener que recibir un solo bit del correo ni haber gastado un ciclo de CPU en analizarlo.

Para mi se ha convertido en uno de los mejores sistemas por que me ha demostrado ser capaz de evitar el 95% del SPAM. Y eso supone muchos cientos de miles de correos semanales (si, no me he equivocado en el número). Después de todo, la mayoría de nuestro correspondencia la hacemos con los mismos interlocutores, por lo que estos siempre estarán marcados como válidos. Los nuevos interlocutores, los que no conocemos aun de nada, son de los que desconocemos sus intenciones, y por eso nos tomamos un tiempo en aceptar su correo.

Además, es de los sistemas de detección y protección que marcan las direcciones de correo de los destinatarios como no válidas para los spammers, por lo que (y esto es otro dato que he comprobado con el tiempo) acaban saliendo de algunas de estas listas, reduciendo el volumen de spam que se les intenta enviar. Doble beneficio a cambio de la demora de un correo.

Uno solo.

Merece la pena.

Soy un fan declarado del greylisting y de la belleza de su sencillez y eficacia.

Y aunque a Juanjo no le guste, el post se me ha alargado demasiado, por lo que seguiré hablando de los otros métodos de los que quería hablar (SPF y DomainKeys) en otra entrada.

Permanezcan atentos a la pantalla.