Monta un servidor DNS en casa y controla tu dominio.

A continuación una manera para poder abandonar nuestro ISP de hosting con el que tengamos contratado nuestro dominio y el alojamiento. La idea es que nosotros controlemos nuestro dominio desde NIC.es y que el alojamiento lo sirvamos nosotros en casa montando un servidor de DNS en LINUX, en este caso Ubuntu.

 Bien para ellos, lo primero que tenemos que hacer es controlar nuestro nombre de dominio .es, para ellos no dirigimos a NIC.es, a continuación arriba nos sale “accesibilidad”, y luego en la nueva página a la derecha “Gestiona”.

 Se nos piden dos, cosas un identificador de usuario y una contraseña, el primero lo obtenemos haciéndole un whois a nuestro nombre de dominio, lo introducimos en la casilla correspondiente, y luego clicamos en “Recuperar contraseña”, la cual será enviada por parte de NIC a tu e-mail (mail con el que registraste el dominio el el proveedor con el que lo tienes contratado).

 Ahora que ya tenemos los dos valores, entramos y clicamos en “renunciar al agente registrador”, después de este paso ya no tendremos acceso a nuestro agente registrador, ni al hosting ni a las cuentas de correo, por ello debemos de hacer una copia de seguridad antes,y estar seguros de los que hacemos.

 Una vez renunciado, pasamos a “un panel” en el que podemos modificar los datos de dominio, incluido los DNS que haremos apuntar a nuestra máquina DNS.

 COMO MONTAR UN SERVER DNS EN CASA:

Linux Ubuntu:

$sudo apt-get install bind9$ sudo gedit /etc/bind/named.conf

Añadimos lo siguiente: 

zone “freelogs.net” {
type master;
file “/etc/bind/freelogs.net.hosts”;
};

 $ sudo gedit /etc/bind/freakfic.net.hosts

Pegamos esto: 

 $TTL 864800
@ IN SOA
www.freelogs.net. root.www.freelogs.net. (
1 ;serial
360000 ;refresh every 100 hours
3600 ;retry
3600000 ;expire
3600 ;negative cache
)
@ IN NS
www.freelogs.net.
www IN A <IP de la maquina donde tengamos el hosting>

 Todo listo, por último iniciar el server:

 $ sudo named -g &

 ————————————–

Como tener la máquina en una disponibilidad de 24h es una tarea tediosa, puede que nos interese redireccionar los DNS hacia un alojamiento gratuito, el único que he encontrado es awardspace.com, puesto que alojamiento gratuito nos lo ofrece cualquiera pero el problema es el control DNS en ese espacio.

 

 

Problema HP Pavilion series dv2000/dv6000/dv9000 y Compaq Presario series V3000/V6000

NOTA: Este post tiene más de 200 visitas diarias, lo que me hace pensar que todavía hay mucha gente sin solucionar el problema de los pavilion defectuosos de hace unos años.

La manera más barata y casera de solucinar este problema es siguiendo el siguiente tutorial:

http://ghipeli.blogspot.com/2009/02/blog-post.html

Una persona con unos conocimientos algo avanzados de informática, con algo de experiencia montando equipos, puede realizarlo perfectamente.

Yo personalmente he sustituido el secador industrial por uno de pelo y la moneda han sido 5 céntimos de euro.

A día de hoy, y muy temeroso de que un portátil me salga igual de malo, uso un MacBook pro de 13″, que a las malas  podré llevar a uno de los muchos SAT de Apple.

Seguridad y Hacking de redes inalámbricas: Clave WEB

Este tema está muy descrito por la red pero bueno, nunca biene mal tener una forma rápida y fácil de hacerlo.

 

En primer lugar descargamos una LiveCD que nos hará la vida más fácil: “Troppix1.2”, las quemamos, arrancamos con ella y en consola:

 

iwlist ra0 scan

 

Con esto escaneamos las redes al alcance. El resultado sería algo similar a esto:

 

Cell 01 – Address: 01:04:C9:BC:CC:DA

                    Mode:Managed

                    ESSID:”elviña_vella”

                    Encryption ***:on

                    Channel:12

                    Quality:0/100  Signal level:-60 dBm  Noise level:-204 dBm

          Cell 02 – Address: 00:06:C9:EF:FE:16

                    Mode:Managed

                    ESSID:”udcwifi”

                    Encryption ***:on

                    Channel:10

                    Quality:0/100  Signal level:-70 dBm  Noise level:-143 dBm

 

Suponiendo que queremos probar la seguridad de la primera entrada de la lista, y teniendo en cuenta que ya disponemos de las herramientas necesarias en nuestro sistema, comenzamos a hacer el trabajo.

 

airodump ra0 captura1 11

 

Con este comando hacemos que la tarjeta entre en modo monitor y se ponga a “escuchar” en el canal 11.

 

*** Es posible que tu tarjeta no entre en modo monitor, asegúrate de ello antes de todo el proceso.

 

iwconfig ra0 rate 1

 

Este comando es muy recomendable ejecutarlo, ya que al bajar la velocidad de transmisión a 1 Megabyte hacemos que la comunicación sea más estable a mayor distancia, y es útil si empleáis dispositivos inalámbricos de larga distancia.

 

aireplay -1 0 -e Essid1 -a 01:04:C9:BC:CC:DA -h 55:44:33:22:11:00 ra0

 

Sólo clientes debidamente autenticados y asociados al AP(Punto de acceso) podrán “entablar comunicación” con éste. El ataque -1 lo que hace es asociar la dirección MAC que definimos en -h con el AP con ESSID ‘udcwifi’ y BSSID.

 

Ahora, y si no recibimos paquetes de autenticación, estamos asociados al AP. O mejor dicho está la MAC asociada al AP.

 

Necesitaremos aproximadamente un mínimo de un millón de paquetes encriptados para poder averiguar la clave WEP que se está utilizando para cifrar la comunicación. Si pretendemos capturar este volumen de datos de forma pasiva (sólo “oyendo”) pues hay que esperar sentados. Y mucho tiempo por cierto. Es por ello por lo que se usa la reinyección.

 

 

La reinyección consiste en básicamente capturar un paquete ARP para modificarlo ligeramente y enviárselo al AP. Éste, aunque fuera para mandarnos a hacer gárgaras, nos responde con un paquete también cifrado, pero con un nuevo vector de inicialización. Estos vectores de inicialización diferentes son justo lo que necesitamos.

 

Si en el comando que escribimos anteriormente para ejecutar airodump escribiésemos un ‘1’ al final, entonces le estaríamos diciendo que sólo capturase los vectores de inicialización (de aquí en adelante IVs), en lugar de los paquetes cifrados completos. El comando quedaría así:

 

airodump ra0 captura1 11 1

 

Pasamos a reinyectar, como si fuésemos el cliente asociado:

 

aireplay -3 -b 01:04:C9:BC:CC:DA -h 55:44:33:22:11:00 ra0

 

Debemos esperar, ya que hasta que no capturemos ese ARP no comenzará la reinyección.

 

Cuando ésta se produzcan veremos como el valor de #data comienza a subir rápidamente. Todos esos paquetes quedarán almacenados en el archivo de captura que airodump ha creado al iniciarse. Pero ojo, se perderán si reiniciamos, ya que estamos trabajando con una livecd. Hay dos soluciones alternativas: Usar una distribución instalada al disco duro (recomiendo ésta por supuesto) o guardar la captura en algún tipo de medio.

 

Una vez tenemos ese ansiado millón de paquetes podemos probar a lanzar aircrack sobre él para ver si nos da la clave.

 

Desde el mismo directorio donde lanzamos la captura:

 

aircrack *.cap

 

 

 

 

Cambio de direcciones MAC

En determinadas ocasiones es interesante cambiar la MAC de nuestros dispositivos de red.

 

Por ejemplo yo lo utilizo para cambiar la MAC de una antena adquirida recientemente por la dirección de mi dispositivo inalámbrico del portátil para que pueda conectarme sin problemas a la cuenta wifi de la facultad desde casa.

 

Pero siempre se le pueden encontrar utilidades tales como suplantar la MAC del vecino para conectarse a su wifi que autentifica por MAC, o bien tener una MAC no registrada, fichada o similar…

 

Bien la cosa es tan siempre como bajarse este programita: Etherchange.exe

 

No necesita ni siquiera instalación, con un clic entramos en un modo consola en el que en menos de 3 pasos muy intuitivos cambiaremos la MAC.

Localizar Websites que requieren autentificación SSL

 

La metodología no es brillante pero en bastantes casos funciona, además una parte del análisis de la plataforma en la que se ejecutan determinadas aplicaciones consiste en tratar de averiguar si SSL se encuentra habilitado, o resolver los algoritmos que utiliza.

 

En muchas páginas web, como pueden ser las de comercio electrónico, de banca o intercambio de información “peligrosa” que no puede viajar por la red sin encriptar, la totalidad de la aplicación que trata los datos debería trabajar con SSL, pero en numerosas ocasiones nos encontramos que tan sólo la página inicial de la aplicación posee el certificado, como son la página de conexión y la de elaboración del perfil.

 

La técnica que posteo trata en sustituir las regencias https:// por http:// y comprobar si la aplicación objetivo sigue sirviendo la información en bandeja como antes de realizarlo.

 

La mayoría de los programadores tienen por manía elaborar las aplicaciones para que respondan a las situaciones esperadas, dando por supuesto que la página de conexión se redirige del puerto 80 al 443, y de ahí se mantendrá el user, pero para usuarios malintencionados puede que no sea el caso, y los programadores debería de asegurar que todos los datos sensibles se trasmitan mediante SSL.

 

 

Bueno la cosa es sencilla pero comprobando que SSL no está activado en derminado recurso podemos dejar volar la imaginación y aprovercharnos de datos que no están protegidos y que viajan libremente por la red.

 

Asimismo si alguien puede aportar algo mas acerca de SSL, de su violación, de técnicas de rastreo del mismo etc, lo puede postear replicando a este mismo post.