por ·6 comentarios

O de como se le va haciendo cada vez mas dificil la vida al spammer promedio.

Como decía, me gustaba mas antes, cuando era como el lejano oeste. No había tantas trabas, no existían tantas regulaciones, ni leyes, uno podía ir por internet haciendo desastres sin que nada ni nadie lo impida…

Eran épocas de gloria y pena, donde los hackers eran leyenda , no existía el concepto de zero-day, las cosas no se parchaban tan rápidamente, apache y sendmail caían todos en la volteada. Los antivirus no detectaban troyanos premanufacturados, los virus infectaban ejecutables y realmente hacían daño del que duele borrando y rompiendo, uno podía mandar un paquete mal parido formado y hacer caer windows 95 –aunque parece que ahora, con windows Vista, Server 2008 y Windows Seven caminamos sobre huellas del pasado-, el ambiente under era realmente under… Eran tiempos salvajes!

Continúa leyendo

por ·4 comentarios

Viene de la época en que el manual de Gentoo ofrecía como alternativa la posibilidad de que un amigo mas experimentado «te ayude» durante la instalación del sistema operativo, con todos los perjucios que eso conlleva mas adelante a la hora del mantenimiento periódico…

Screen es una herramienta poderosísima a la que no termino nunca de encontrarle nuevos usos. Entre tantas cosas que permite hacer, se puede usar para compartir una sesión en la consola de comandos con N cantidad de personas, donde todos pueden leer los comandos que los demás tipean y la salida por consola que estos comandos devuelven y todos pueden escribir en la misma consola de comandos. Es como una orgía, pero en Bash.

Por hacer una comparación, sería como una especie de VNC o Terminal Server pero para el modo texto de linux, en tiempo real y multiusuario.

Muy útil para mostrarle a algún colega/cliente/amigo como se hace tal o cual cosa en linux mientras se mantiene a la par una conversación por video conferencia, teléfono, chat, etc.

Nunca he asistido a uno de esos FLISOL pero esto se me ocurre que sería una buena alternativa también.

*COF*puedeservirparachatearyparacontrolarunabotnet*COF*

Teniendo Screen instalado, el funcionamiento es bastante sencillo, por ejemplo:

  • Una pc remota de nombre pcremota
  • Un usuario remoto identificado como usuarioremoto
  • Un usuario local identificado como usuariolocal
  • Usuariolocal necesita compartir una sesión de consola con usuarioremoto en pccremota.

Como se pone en funcionamiento:

Usuariolocal se conecta a pcremota identificádose a si mismo como usuarioremoto:

~ $ ssh usuarioremoto@pcremota

Usuariolocal inicia screen en pcremota:

~ $ screen -S sesioncompartida

Usuarlocal inicia el modo multiusuario de screen presionando las teclas [CTRL] + [a] y luego tipeando:

:multiuser on

Usuarioremoto se conecta a la sesión compartida:

~ $ screen -x usuarioremoto/

Y eso es todo. Durante toda la sesión ambos pueden leer y escribir sobre la misma consola.

Al ejecutar screen -S sesióncompartida se está especificando un nombre para la  sesión en cuestión. Si cualquiera de los usuarios conectados se desconectara, podría recuperar todo en donde lo dejó usando:

~ $ screen -r sesioncompartida

¿Y si son usuarios distintos?

Si se trata de usuarios distintos, por poner un ejemplo, donde usuariolocal se autentica contra pcremota como root y usuarioremoto se va a conectar a la sesión de root, entonces el ejecutable de screen necesita tener habilitado el bit SUID:

~ $ chmod u+s /usr/bin/screen

Por otro lado, luego de habilitado el modo multiusuario de la sesión screen que inició root, este tendría que darle permiso a usuarioremoto para que se conecte a su sesión. Como todos los comandos en scren, presionando primero [CTRL] + [a] y tipeando:

:acladd usuarioremoto

Y  así sucesivamente N cantidad de veces, una por cada usuario que se va a conectar a la sesión screen con credenciales diferentes a las del usuario que inició el proceso.

por ·2 comentarios

Eramos tan pobres…

En Argentina, país bananero si los hay, que nos hace bien cuesta arriba el acceso a nuevas tecnologías, cuando algo se rompe, lo atamos con alambre para seguir usándolo.

Este es uno de esos casos: Resucitar esos viejos módulos de memoria RAM rotos, que ya dabas por muertos y que de otra forma no servirían mas que para hacerse un llavero y competir contra tus amiguitos –cada cual mas nerd que el anterior– a ver quien tiene mas megas de ram desperdiciados en el bolsillo.

…Había una vez, un tal Rick Vanrein, que era mucho mas pobre que todos los Argentinos juntos y que sabía de programación. Motivado por un interés púramente económico escribió en su página web:

Summary: This page proposes an approach to support RAMs with defective addresses, This may open interesting business perspectives, where those RAMs can be sold under a white label for less money rather than discarded of without any profit.

Claro que no tuvo en cuenta que su idea de negocio iba en contra de la producción en serie y que globalización –y chinos que trabajan por el plato diario de arroz– de por medio el costo de fabricación de memoria RAM se abarataría muchísimo dando por tierra con su proyecto.

Lo importante es que lo hizo: BadRAM, un módulo para el kernel de linux que permite a este sistema operativo funcionar normalmente inclusive cuando la memoria RAM está en mal estado.

¿Y como funciona?

Facil, se basa en la salida de memtest86 para saber cuales son las direcciones de memoria defectuosas y por medio del gestor de arranque, pasárselas como parámetro al kernel para que no las use. Genial, ¿No?.

Como se usa:

Primero lo primero; Tu kernel tiene que tener soporte para BadRAM. En kernels relatívamente nuevos (desde 2.6.16 si no recuerdo mal) BadRAM viene ya pre-incluído en el kernel… A lo sumo tocará activarlo si no lo estuviera pero eso está «out of the scope of this guide» como dicen en inglés cuado quieren decir «me da flojera entrar tan en detalle».

En versiones anteriores del kernel se puede incluir soporte para badram bajando el parche en cuestión y recompilando el kernel parchado:

~ # cp BadRAM-2.6.19.1.patch /usr/src/linux

~ # cd /usr/src/linux

~ # patch -p1 < BadRAM-2.6.19.1.patch

Segundo – Memtest86:

Habiéndole dado soporte a tu kernel para BadRAM si hiciera falta, bien por medio del parche o bien habilitándolo en donde el kernel lo incluya por defecto, lo siguiente es ejecutar memtest86 para diagnosticar cuales son los rangos de direcciones de memorias que están fallando.

De nuevo, memtes86 viene de serie hoy en día incluído en el kernel por defecto y habilitado o no dependiendo de cada distribución.

Ejecutado memtest, tendrán en pantalla algo como esto:

Memtest86 enseñandole a ese módulo de memoria defectuoso quien es el jefe.

Memtest86 enseñandole a ese módulo de memoria defectuoso quien es el jefe.

Lo importante es cambiar la configuración de memtest86 para que muestre los errores de salida en formato badram. Esto se hace con la tecla «C» para entrar en la configuración, activando la opción 5 – Error Reporting Mode y por ultimo eligiendo la opción 2 – BadRam Patterns, saliendo de cada menú y submenú con la tecla «0»

Hay que dejarlo correr al menos una «pasada» completa de tests.

Arriba a la derecha el primer indicador de porcentaje indica justamente el avance de cada pasada.
Al terminar una pasada completa en pantalla quedan una serie de rangos de memoria expresados en hexadecimal que se ven mas o menos así:

badram=0xfefdffc,0x2404ea30,0xfe05fffc etc.

Tomar nota (yo lo hice en papel pero seguro hay una forma mas elegante de hacerlo) de todos estos rangos de memoria que fallan para pasarselos al kernel.

Por último, iniciar la PC en modo «lo mas seguro posible»

Iniciar la pc en modo interactivo frenandola con la tecla «4», o pasarle init=/bin/bash a la línea que menciona al kernel editando al vuelo el menú de Grub, o bien cambiando las memorias rotas por unas en buen estado.

Montar /boot/ si no lo estuviera y agregar una entrada nueva para BadRam en /boot/grub/menu.lst que en mi caso quedó así:

title  Gentoo Linux Kernel 2.6.30-r4 con memorias rotas
root (hd0,0)
kernel /boot/kernel2.6.30-r4 root=/dev/sda2 badram=0x2400ea30,0xff81fffc,0xffd07ffc,0x24016a30,0xfe01fffc

Y eso es todo! Linux se salteará limpiamente las direcciones de memoria conocidas como defectuosas con lo que no deberías volver a tener inconvenientes siempre y cuando tu memoria RAM no se siga rompiendo con el uso.

Si se dispone del tiempo necesario, es conveniente dejarle hacer como mínimo dos pasadas a memtes86 antes de fiarse de los resultados. Cuantas mas, mejor. Aveces ciertas fallas se presentan recién después de un tiempo de uso, cuando el modulo dimm toma temperatura.