Archivos raros (y el uso del comando file)

Hace un par de días que me descargué el tema de una canción con la extensión de firefox "Video Download Helper", que aparte de que se pueden deskrgar perfectamente los videos de youtube, puede bajar todos los archivos multimedia que suenan en sitios como "enladisco.com"(*), "http://www.nuevaq.net/Cristianas/", y de sitios similares, que para todos los gustos hay :)

La cuestión fue que el archivo de música que me descargó tenía una extensión rara, que cuando lo quise abrir con el reproductor de multimedia no me lo reconoció, pues este tenía una extensión .fdk (y raro porque yo pensaba que en GNU/Linux (ok, estoy usando Ubuntu) abre los archivos de acuerdo a su estructura no por su extensión).

Entonces eso fue ya hace rato y se me olvidó que dejé ahí ese archivo...

Ahora que estoy haciendo los respaldos necesarios para pasar la compu del trabajo de Ubuntu 9.10 (ya tenía ratos de no hacer un apt-dist upgrade XD) a Debian Squeeze, en mi /home/edwin/Escritorio/misc encontré un archivo "856945270.fdk" el ícono que tenía es como cuando no están asociados a ningún programa para que sean abiertos, así que antes de eliminarlo, esta vez se me prendió el foco y utilicé el comando file, que nos da una breve descripción de la estructura del archivo (tenga este extensión o no), y pues cuando lo ejecuté este fue el resultado:

edwin@ubuntu910:~/Escritorio/misc$ file 856945270.fdk
856945270.fdk: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo

Bueno, como podemos ver, dice que en realidad es un archivo MPEG de capa 3 (layer III), en buen castellano, es un archivo MP3 :)

Así que solo fue cosa de renombrarlo a su extensión correcta y ya pudo ser reproducido por Rhythmbox! :D

Moraleja:
* No es un gran descubrimiento, pero algo aprendí, que la seguridad a través de oscuridad no siempre funciona. Hay algunos sitios que solo renombran la extensión de la música y creen que no habrá alguien que se le ocurra cambiarle la extensión al archivo descargado y será completamente útil para escuchar off-line.

* No creo que sea un gran problema de seguridad, de hecho no creo que lo sea, pero querer esconder la verdadera extensión para que no sea útil el archivo sin estar en el sitio no fue buena idea.

* No esperaba que al menos el Rhithmbox no reproduciera los archivos según su estructura interna, pero veo que los clasifica segun su extensión para ver si es un formato reconocido.

* El comando file es una gran cosa! :D

Bytes!

Read more ►

GNU/Kirlian Zepeda (Q.D.E.P.)

Desde un rincón del igloo del TuxRacer se recuerda un año más la lamentable pérdida de una de las mentes más brillantes (y no ególatras) de El Salvador.

Parece como que si fue hace unos meses atrás cuando Kirlian llegó a una empresa donde yo trabajaba... él llegó a configurar un mail server con Qmail, vi en el escritorio en que trabajaba junto a su laptop Toshiba el libro "hackers" (1a. Edición).

Mi primera reacción...

- ¿Eres un hacker?

- Jaja... No, simplemente me gusta mantenerme informado, ellos son muy hábiles con las computadoras.

- Crees que yo pueda llegar a ser uno?

- Si te lo propones.

- Hey, puedes utilizar bien M$-DOS!!! (al ver en la pantalla de líneas donde escribía comandos...)

- No, de hecho este es un Linux y me estoy conectando a otra computadora por medio de SSH. (A todo esto, yo quizá estaba boqui-abierto por pensar que me hablaba en chino simplificado!)

- Entonces utilizas telnet por el puerto 23? (era lo único que yo sabía... XD).

- No, pues fíjate que SSH utiliza el puerto 22...

Él era una persona que a pesar mis intenciones en aquellos días no fuera pensar en el hacking como un Admin de Red o Sistemas, pero en lo que recuerdo, nunca me abochornó por lo más "simple" que fuera la pregunta...

Y bla, bla, bla... fue corto el tiempo en que pude platicar con él.

Dios nos manda personas que nos enseñen cosas, o que nos motiven a aprender algo, y tengo que admitirlo que Kirlian fue, indirectamente, un maestro de GNU/Linux, del Software Libre y porqué no, también del arte de la (in)seguridad informática de forma ética.

Luego mi Dios ha ido poniendo personas y recursos para que siga aprendiendo, ya sea a pasos cortos o a pasos rápidos, pero ahí vamos en el camino.

Por lo que a mi respecta, un año más le recuerdo con mucho aprecio a un gran mentor y amigo. Que Dios lo tenga en su gloria.

Read more ►

Seguridad mínima en OpenSSH Server

Tras casi una semana de haber dejado mi antiguo lugar de trabajo por diversas razones personales, haciendo unas revisión general para ver cómo estaban las cosas, me dio la curiosidad y me puse a revisar el servidor Ubuntu que tienen a ver que había de nuevo...

Sorpresa!!! al darme una vuelta por los logs de autenticación veo que han querido acceder por medio de un ataque de fuerza bruta (con el usuario root y algunos otros) al servicio sshd mostrando las siguientes entradas en el archivo /var/log/messages/auth.log.0 :

Jan 17 08:51:45 ubuntu sshd[24173]: Failed password for root from 115.146.138.5 port 36764 ssh2
Jan 17 08:51:48 ubuntu sshd[24179]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Jan 17 08:51:50 ubuntu sshd[24179]: Failed password for root from 115.146.138.5 port 37070 ssh2
Jan 17 08:51:52 ubuntu sshd[24183]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Jan 17 08:51:54 ubuntu sshd[24183]: Failed password for root from 115.146.138.5 port 37377 ssh2
Jan 17 08:51:57 ubuntu sshd[24187]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root
Jan 17 08:51:59 ubuntu sshd[24187]: Failed password for root from 115.146.138.5 port 37706 ssh2
Jan 17 08:52:01 ubuntu sshd[24191]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.146.138.5 user=root

Correcto! Estaban atacando el servicio SSH (sshd) queriendo ingresar con el usuario root y aparte de este usuario habían otros como: sasha, bryan, peter, guest, john, www-data, etc.

La seguridad mínima (pero muy mínima...) que se le puede aplicar a un servidor ssh recién instalado es poner la directiva PermitRootLogin en no en el archivo /etc/ssh/sshd_config y reiniciar solamente el servicio sshd con /etc/init.d/ssh restart

Luego de esta sorpresita, le hice un escaneo de puertos al server y pues obviamente, al tener el puerto predeterminado abierto encontré lo siguiente:

tuxracer@hackerbox:~# nmap -O -vv server1.mi-ex-trabajo.com

Starting Nmap 4.76 ( http://nmap.org ) at 2010-01-22 16:02 CST
Initiating OS detection (try #1) against server1.mi-ex-trabajo.com
Retrying OS detection (try #2) against server1.mi-ex-trabajo.com
Host server1.mi-ex-trabajo.com appears to be up ... good.
Interesting ports on server1.mi-ex-trabajo.com:
Not shown: 991 closed ports
PORT STATE SERVICE
22/tcp open ssh (interesante... ¬¬)
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1025/tcp filtered NFS-or-IIS
1720/tcp filtered H.323/Q.931
4444/tcp filtered krb524
5000/tcp filtered upnp
OS fingerprint not ideal because: Host distance (7 network hops) is greater than five
Aggressive OS guesses: Linux 2.6.24 (95%), Linux 2.6.9 - 2.6.26 (95%), Linux 2.6.22 - 2.6.23 (94%)...

Entonces, como segundo paso de la seguridad más mínima que se le puede aplicar a un servidor SSH es cambiarle el puerto predeterminado, ya que la mayoría de botnets que dejan algunos delincuentes informáticos al lanzar pruebas de intrusión lo hacen a servicios que tienen el puerto que viene por default en su archivo de configuración, el 22 en este caso para sshd.

Para cambiarlo, editamos siempre el archivo /etc/ssh/sshd_config y buscamos la directiva port para cambiar el valor a cualquier número arriba del 1024 (y menor de 65535) que no esté siendo utilizado por otro servicio que estemos ofreciendo, quedando (por ejemplo) de esta manera:

port 25259

Y como siempre, reiniciamos solamente el servicio sshd para que surtan efecto los cambios realizados. Así, al pasar un escaneo de puertos nuevamente ya no lo reconoce como un servicio estándar y de hecho, ya no lo muestra en el otro escaneo de puertos (sencillo) que le realicé.

tuxracer@hackerbox:~# nmap -O -vv server1.mi-ex-trabajo.com

Starting Nmap 4.76 ( http://nmap.org ) at 2010-01-22 16:22 CST
Initiating OS detection (try #1) against server1.mi-ex-trabajo.com
Retrying OS detection (try #2) against server1.mi-ex-trabajo.com
Host server1.mi-ex-trabajo.com appears to be up ... good.
Interesting ports on server1.mi-ex-trabajo.com:
Not shown: 992 closed ports (aparece 1 puerto cerrado más que en el escaneo anterior)
PORT STATE SERVICE
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1025/tcp filtered NFS-or-IIS
1720/tcp filtered H.323/Q.931
4444/tcp filtered krb524
5000/tcp filtered upnp
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Bravo!!! ya no aparece listado el servicio de sshd por el puerto 22, es más ni en ningún otro puerto*.

Es cierto, la seguridad por medio de la obscuridad, no es confiable, además la herramienta nmap tiene muchas opciones las cuales también pueden ser agregadas y encontrar un sin fin de cosas, pero como mencionaba, esas 2 directivas son básicas para dar una seguridad de lo más mínima a un servidor que esté ofreciendo conexiones por medio de ssh.

(Eso de las dos directivas "más básicas" es una subjetividad mía, los que son expertos en seguridad de servicios en Sistemas GNU/Linux o que tengan más experiencia pueden tener otra apreciación de mi punto de vista)

En el archivo de configuración /etc/ssh/sshd_config hay muchas opciones de seguridad que más adelante (en otro post) las iré comentando, sin mencionar que se pueden crear reglas con iptables o también se puede echar mano de fail2ban.

En fin, las opciones para asegurar servicios (y en especial ssh) son muy variadas que ni siquiera las conozco todavía, pero en lugar de creer que GNU/Linux por sí solo es muy seguro y podemos dejar las configuraciones por default de los servicios que ofrecemos al público, sabre decir que no es una muy buena idea, a pesar de que (comparado con el S.O. de Redmond) es muy bueno, seguro y robusto, éste tampoco hace milagros en cuanto a la seguridad, revisiones y actualizaciones que uno debe de realizar periodicamente.

Y de hecho, que por qué sigo al tanto de la seguridad (que yo humildemente conozco) de un servidor donde ni siquiera trabajo ya y ni me pagan por ello?

Simple, no hay que pagar un mal con otro mal. Al menos cuando llegue algun empleado que le gusten un poco los servidores GNU/Linux y la seguridad informática (mínima o básica) como me gusta a mi, pues cambiará los medios de acceso y con respecto a la seguridad sabrá qué hacer. No hacer nada también es una opción, pero...

También, Proverbios 3:27 dice: "No te niegues a hacer el bien a quien es debido, Cuando tuvieres poder para hacerlo."

Saludos!

[Editado: 24/14/2010 00:22:58]

Después de hacer los cambios en el puerto de escucha del servidor ssh, tengo que mencionar/aclarar que para nuevas conexiones a los servidores con el nuevo puerto en cuestión se tiene que agregar la opción de especificación de puerto a ssh (-p #de-puerto) antes del nombre o dirección IP del servidor, ya que cuando quise volverme a conectar poniendo dicha opción al final del nombre del servidor, si lo hacía de la forma:

# ssh usuario@server1.mi-ex-trabajo.com -p 25259

La respuesta que obtenía después de unos 5 minutos (aprox.) era que la conexión se cerraba por caducarse el tiempo.

# ssh usuario@server1.mi-ex-trabajo.com -p 25259

ssh: connect to host server1.mi-ex-trabajo.com port 25259: Connection timed out

Si lo hacía de esta:

# ssh -l usuario server1.mi-ex-trabajo.com -p 25259

Después de 1 hora no obtuve respuesta alguna, sin embargo tampoco obtenía el mensaje que me dijera que la conexión se cerraba porque se había caducado el tiempo para establecer tal conexión.

Así que, la forma correcta de hacerlo es:

# ssh -p 25259 usuario@server1.mi-ex-trabajo.com

ó

# ssh -l usuario -p 25259 server1.mi-ex-trabajo.com

# ssh -p 25259 -l usuario server1.mi-ex-trabajo.com

Bytes!

Read more ►

Cómo configurar la tecla "Win" en Debian o Ubuntu

Por lo general (y porque así es el Marketing) los teclados de nuestros equipos, llámese laptop o desktop, al lado de la tecla Alt, ya traen una tecla con el logo del "otro" Sistema Operativo (si es que se le puede llamar así a esa colección de bugs ¬¬), que usualmente esa tecla no tiene ningún uso inicial (por el momento) en nuestro Debian (usando Gnome) o Ubuntu.

Pues leyendo los blogs que sigo, me encontré en UbuntuLife una forma para darle utilidad a "esa" tecla que ya tenía días de no usarla, y la podemos "setear" para que nos abra las opciones del menú principal de Gnome y la forma para hacerlo es digitar en una consola lo siguiente:


gconftool-2 --set /apps/metacity/global_keybindings/panel_main_menu --type string "Super_L"


Para dejarla como antes si es que ya la teníamos configurada con otro(s) atajos del teclado volvemos a teclear:

gconftool-2 –unset /apps/metacity/global_keybindings/panel_main_menu "Super_L"

Como es de notar, para activar o desactivar, lo único que cambia es la opción "--set ó --unset" que se le pasa a gconftool-2.

La fuente en donde lo leí es esta: UbuntuLife.

Yo no uso KDE, pero ha de existir una utilidad semejante/similar para utilizar el menú principal con esa tecla.

Bytes!

Update: A mi no me sirvió la forma anterior expuesta en la línea de comandos para regresarla a la normalidad, porque con esa tecla ya tenía activada otra funcionalidad del Compiz-Fusion y pues la solución express (y menos complicada) para desasociar la tecla "Super-L" es yéndose al menú: Sistema, Preferencias, Combinaciones de teclas luego buscar la acción "Escritorio" abajo de ahí, buscar: Show the panel's main menu y presionar la tecla Backspace. Con eso quedará la tecla "del logo" con el uso de antes (Si es que realizaba alguno ñ__ñ).

Read more ►

Filtrando contenido con Squid+Dansguardian+Iptables

(Aparte del título del post, se soluciona un problema de resolver conexiones https)

Respetando la autoría intelectual del propietario del artículo/solución presentada (Adolfo Maltéz), el contenido original de este post puede ser encontrado en el archivo de la lista de la comunidad de Usuarios Debian GNU/Linux de El Salvador: (http://lists.debian.org.sv/pipermail/debian-sv/2009-April/000387.html)

Saludos Lista.

Hace varios meses (Junio 2008), tenia un problema con SQUID.
emonge me paso el tutorial (http://blog.debian.org.sv/?p=30)
de la instalacion de servidor, pero aun asi no solventava mi problema,
porque el escenario es distinto.
Pero ya lo solucione :)

Planteamiento:
Existe en la empresa un servidor HTTP Proxy SQUID, que es administrado
por otro departamento.
A mi no me dejan ni verlo :(
Debo instalar un servidor HTTP proxy en una pequenia LAN, pero la
unica salida a internet es el Proxy Padre.
En mi caso el proxy que debo configurar es un proxy Hijo.
La autenticacion la debe realizar el proxy padre como de costumbre,
En mi proxy tengo DansGuardian.

Todo bien con el Tutorial http://blog.debian.org.sv/?p=30

Las dos tarjetas son necesarias.

Problemas que aparecieron:

1. Necesito pasarle las credenciales de los usuarios al proxy padre,
para que este las valide y les de el INTERNET.
Eso se resuelve configurando squid (/etc/squid/squid.conf) con esta linea.

cache_peer 192.168.100.5 parent 8080 0 default no-query login=PASS

Donde 192.168.100.5 es la IP del proxy padre, que escucha en el 8080,
y lo mas importante login=PASS quiere decir que las contrasenias y
usuarios para el uso del proxy las solicita el padre. el hijo solo se
las alcanza ;)


2. No me resolvia conexiones con SSL (https para ser exactos), despues
de buscar y buscar, encontre que habia que poner la siguiente linea,
en el fichero de configuracion (/etc/squid/squid.conf):

nonhierarchical_direct off


Esto es para que le mande toda peticion (incluida https) al padre, ojo
que por defecto esta on

La verdad la configuracion de SQUID es un relajo, se pueden hacer
tantas cosas (y se pueden no hacer otras, si no se configura bien).

Eso soluciono mi problema, talves a alguien le sirve luego.

Nos vemos luego.

Att. Adolfo Maltez

Read more ►