Monitorizar una IP o tu conexión a internet. Script BASH

¿Alguna vez has querido monitorizar tu conexión a internet para detectar si cae o tiene perdida de paquetes, o monitorizar quizás un servidor en internet?

En esta ocasión os traigo un pequeño script bash para realizar esto. El script comprobará si existen perdida de paquetes a una IP en concreto y lo reflejará en el log del sistema, ademas, aprovecharemos y guardaremos la caída en un archivo llamado log_fails.txt.

El tema del aviso tambien se puede configurar para que os envie un SMS a cualquier móvil, un mail… un sin fin de posibilidades.

El script en cuestión seria este:


#!/bin/bash
SITIO1=8.8.8.8 # DNS de Google principal
SITIO2=8.8.4.4 # DNS de Google secundario

while true
do
ping -c8 ${SITIO1} >/dev/null 2>/dev/null

respuesta1=$? #Guardamos estado de stderr

if [ $respuesta1 -eq 1 ];
then
sleep 10 # Esperamos 10 segundos para realizar una 2º prueba
ping -c3 ${SITIO2} >/dev/null 2>/dev/null
respuesta2=$?
if [ $respuesta2 -eq 1 ];
then
logger SERVIDOR CAIDO. HORA: $(date)
echo "SERVIDOR CAIDO. HORA: $(date)" >> log_fails.txt
fi
fi
sleep 10 # Esperamos 10 segundos para volver a comprobar desde el inicio
done

Guardamos este archivo con el nombre check.sh por ejemplo….

Le damos permisos de ejecución y ejecutamos con &exit para que quede en proceso de 2º plano:


chmod +x check.sh
sh check.sh &exit

Como podeis observar registramos la caída con el comando logger. Esto simplemente añade una linea con el texto “SERVIDOR CAIDO. HORA: ” en /var/log/messages…

Esta pequeña receta con pocas lineas, nos servirá de mucho si queremos monitorizar nuestra conexión a internet o cualquier otra IP de nuestra red o de internet.

Si lo que quereis es monitorizar es solamente una IP, tendreis que fijar en las variables ‘SITIO1’ y ‘SITIO2’ la misma IP.

Espero os sirva de ayuda.
Un saludo.

Share

Clonar paquetes hacia otra máquina con iptables

Con la extensión ‘TEE’ de iptables podemos clonar un paquete dirigido hacia otra máquina a la nuestra.

Si quisieramos clonar el trafico de entrada del host 192.168.1.5 y mandarlo a nuestra maquina (192.168.1.100):


iptables -t mangle -A PREROUTING -d 192.168.1.15 -j TEE --gateway 192.168.1.100

Si buscamos hacer lo mismo con el trafico de salida del host 192.168.1.5 y mandarlo a nuestra maquina (192.168.1.100):


iptables -t mangle -A PREROUTING -s 192.168.1.15 -j TEE --gateway 192.168.1.100

Fuentes:

http://ipset.netfilter.org/iptables-extensions.man.html

http://superuser.com/questions/853077/iptables-duplicate-traffic-to-another-ip

Share

Tormenta broadcast NETGEAR ONO

Hola de nuevo a todo el mundo!

Despues de mucho tiempo offline volvemos a mostrarnos al mundo. Esta vez vengo a plasmar una experiencia personal con los famosos router netgear que entrega ONO.

Por cuestiones tecnicas del escenario que nos encontrábamos, el router de ONO debía estar configurado en modo NAT, es decir, en el mismo router, una ip publica y otra privada para nuestra LAN.

La máquina con Gentoo conectada a un puerto ethernet del router NETGEAR, seria algo así:


ROUTER ONO -----> 84.128.X.X. -- PUBLICA
192.168.1.1 -- PRIVADA


MAQUINA GENTOO -------> IP WAN 192.168.1.2
-------> IP LAN 192.168.10.1

Una vez realizado lo anterior. ¡Nos pusimos a probar nuestra instalación!
Todo funcionaba de maravilla hasta pasar 15 o 20 minutos. Poco a poco la velocidad a Internet caía, casi no podia abrir simples paginas web..

Con lo que, despues de horas y horas de pruebas y no encontrar una solución, puse a funcionar ‘tcpdump’ en la tarjeta de red donde estaba conectado el router NETGEAR.

Y esto fué lo que me encontré (lineas y lineas de lo que pego a continuación):


ARP Who has 192.168.1.2 Tell 192.168.1.1
ARP Who has 192.168.1.3 Tell 192.168.1.1
ARP Who has 192.168.1.4 Tell 192.168.1.1
ARP Who has 192.168.1.5 Tell 192.168.1.1
ARP Who has 192.168.1.6 Tell 192.168.1.1
ARP Who has 192.168.1.7 Tell 192.168.1.1
ARP Who has 192.168.1.8 Tell 192.168.1.1
ARP Who has 192.168.1.9 Tell 192.168.1.1
ARP Who has 192.168.1.10 Tell 192.168.1.1
ARP Who has 192.168.1.11 Tell 192.168.1.1
ARP Who has 192.168.1.12 Tell 192.168.1.1
ARP Who has 192.168.1.13 Tell 192.168.1.1
ARP Who has 192.168.1.14 Tell 192.168.1.1
ARP Who has 192.168.1.15 Tell 192.168.1.1
ARP Who has 192.168.1.16 Tell 192.168.1.1
ARP Who has 192.168.1.17 Tell 192.168.1.1
ARP Who has 192.168.1.18 Tell 192.168.1.1
ARP Who has 192.168.1.19 Tell 192.168.1.1
ARP Who has 192.168.1.20 Tell 192.168.1.1
ARP Who has 192.168.1.21 Tell 192.168.1.1
ARP Who has 192.168.1.22 Tell 192.168.1.1
.........

Esto, lo emitia el router de ONO cada 2 o 3 segundos. Estaba provocando una tormenta broadcast impresionante. Parecia que el router estaba intentando ponerse en contacto con equipos que no existian en la red, desde 192.168.1.2 hasta 192.168.1.254.

No conozco el porque de esto, supongo que será algun defecto del router.

¿LA SOLUCIÓN?

Bastaria con configurar el NETGEAR en modo bridge. O si necesitamos si o si una ip local, configurariamos el NETGEAR en modo bridge y lo conectariamos a un router, y este a la máquina Linux configurada para manejar el trafico.

INSISTO. En la instalación que estaba realizando era ESTRICTAMENTE NECESARIO trabajar con el router del proveedor en modo NAT. Si no hubiera sido así podria haber configurado en modo bridge el router y problema solucionado.

Espero que esta entrada le sirva a alguien de ayuda ya que yo estuve pegando cabezazos hasta que encontré el por que y una solución.

Share

Network Address Translation. Tipos de NAT.

Hola a todos.  Esta vez voy a escribir un pequeño texto que estoy seguro, les servirá de utilidad. Lo voy a hacer a modo de apunte personal, pero como he dicho, seguro que les servirá a más de uno.. Empecemos…

 

1. ¿Que es NAT? ¿Y que hace exactamente?

Las siglas NAT significa Network Address Translation y fué creado para “ahorrar” direcciones IPv4 gracias al gran auge de internet. Si no hubiera sido por NAT la migración a IPv6 ya haría muchisimo tiempo que se habría completado.

Realiza la traducción para que los equipos internos de una red local puedan comunicarse con el mundo exterior.

 

 

Veamos un ejemplo:

Hemos contratado una linea ADSL, el proveedor nos a facilitado un router el cual tiene 4 bocas LAN para conectar 4 ordenadores en casa.

El router en este caso tendria 2 direcciónes IP: 99.99.99.99 (la publica) y 192.168.1.1 (la privada).

Los ordenadores conectados al router también tendrían direcciones ips privadas..

(A – 192.168.1.2), (B- 192.168.1.3), (C – 192.168.1.4), y (D – 192.168.1.5).

 

 

Lógicamente las direcciones privadas de los ordenadores conectados a ese router no son alcanzables desde internet ni ellos tampoco pueden acceder al mundo exterior. (por ahora…jeje)

Pero el caso… es que, cuando tenemos este escenario tan tipico, los pc’s internos de nuestra casa conectados al router, si pueden entrar a internet perfectamente….¿Que pasó? ¿¿¿¿ como es que funciona???  He ahí la magia de NAT.

Lo que hace en este caso es, cuando desde el pc A (192.168.1.2) se intenta conectar con un destino remoto de internet (22.22.22.22)…

El paquete es dirigido desde el pc A al router:

PC 192.168.1.2 —————> Router 192.168.1.1

– El router comprueba que la dirección IP con la que se desea establecer la conexión es de Internet, con lo que, convierte mediante un mecanimo (más adelante veremos los distintos tipos) la IP Privada del pc A 192.168.1.2 en la IP Externa 99.99.99.99.

– El router una vez hecha la traducción envía la petición al equipo de Internet (22.22.22.22) apareciendo ahora el router (99.99.99.99) como remitente de la conexión.

– Dicha conversión se guarda en una tabla internamente en el equipo enrutador.

– El equipo remoto (22.22.22.22) recibe la petición y contesta al remitente de la conexión (aparece como remitente 99.99.99.99)

– El router (que es el que contiene la ip 99.99.99.99) recibe la contestación del equipo de Internet (22.22.22.22). Ahora el router verifica los registros de la tabla NAT. Se realiza internamente la siguiente pregunta:

¿Que equipos conectados a mi quisieron contactar con 22.22.22.22? Y ahí esta en la tabla de NAT. El equipo 192.168.1.2 fué el que origino la conexión.

– El router envia desde su ip interna (192.168.1.1) la contestación del equipo remoto (22.22.22.22) al pc interno (192.168.1.2)

 

Para dicha conversión NAT juega con los puertos TCP y UDP. Depende del tipo de NAT, elije de una forma u otra la asignación de dichos puertos.

 

2. Tipos de NAT

Como he dicho anteriormente. NAT realiza asignaciones de de puerto origen/puerto destino para poder realizar esas conversiones. No siempre se realiza de la misma forma y esto depende del tipo de NAT que contenga el equipo enrutador.

 

Full cone:  Se fijan un único par  Ip puerto interno / Ip puerto router. Esta establecido desde el principio no hace falta que el cliente inicie una petición de conexión. Por ejemplo: Ya estaría establecido que el pc con IP 192.168.1.2 y puerto 80 sale por la IP 99.99.99.99 y puerto 2211.  Si el equipo de internet 22.22.22.22 envia un paquete a la IP 99.99.99.99 y puerto 2211, este paquete será reenviado automáticamente al pc interno 192.168.1.2.

No entiende de control de sesiones. Es bastante inseguro. Este tipo de NAT ya casi a desaparecido.

 

Restricted cone NAT: Conocida como NAT estricta. Se establece la IP y Puerto publico solamente cuando el cliente inicia un inicio de conexión a una máquina remota. El enrutador guarda la dirección ip de destino y solo atenderá tráfico de respuesta de esa dirección. Con este tipo de NAT un equipo remoto no podrá “responder” a una petición si primero no a realizado el inicio de conexión.

Este tipo de NAT es muy utilizado por los administradoes con Netfilter/Iptables y se basa en, aceptar conexiones pertenecientes a  una sesión (conexión) ya establecida. (RELATED en iptables). Máxima seguridad.

 

Port Restrited Cone NAT: Lo mismo que Restricted cone NAT pero añade un dato más a la asociación, el puerto. Si el destino quiere contestar al remitente y no envia su numero de puerto la información no llegará al cliente.

 

Symetric NAT:  Para cada petición de cada máquina remota se asocia un numero de puerto. Puertos aleatorios. Si el destino quisiera responder al remitente deberá saber el puerto que se le asigno para su sesión, si no, no podrá hacerlo.

 

 

Espero que lo hayan comprendido correctamente he intentado explicar cada concepto y cada escenario de la manera más amena posible.

 

Un saludo y muchas gracias por visitar este blog.

Hasta la próxima!

PD: Debo añadir, que actualmente los enrutadores comerciales, mezclan varios tipos de NAT y no se basan estrictamente en uno de los aquí listados, esto es solamente, para que sepan como trabaja por lo general NAT.

 

Share

Intento Hack Asterisk. Fuerza Bruta contra Asterisk

Hoy me encontraba navegando tranquilamente y monitorizando todos los servidores propios, cuando de repente en la consola de asterisk me aparece lo siguiente:

[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5465″<sip:5465@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5466″<sip:5466@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5467″<sip:5467@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5468″<sip:5468@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”44114411″<sip:44114411@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5469″<sip:5469@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5470″<sip:5470@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”44124412″<sip:44124412@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5471″<sip:5471@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5472″<sip:5472@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5473″<sip:5473@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”44134413″<sip:44134413@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5474″<sip:5474@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5475″<sip:5475@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5476″<sip:5476@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”44144414″<sip:44144414@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5477″<sip:5477@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5478″<sip:5478@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5479″<sip:5479@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5480″<sip:5480@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5481″<sip:5481@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5482″<sip:5482@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5483″<sip:5483@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5484″<sip:5484@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5485″<sip:5485@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5486″<sip:5486@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5487″<sip:5487@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5488″<sip:5488@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5489″<sip:5489@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5490″<sip:5490@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5491″<sip:5491@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5492″<sip:5492@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5493″<sip:5493@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5494″<sip:5494@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found
[Feb 26 00:54:13] NOTICE[8658]: chan_sip.c:21821 handle_request_register: Registration from ‘”5495″<sip:5495@81.56.122.35>’ failed for ‘139.153.12.78’ – No matching peer found

Es obvio que estan atacando a nuestro asterisk con un ataque Brute Force (Fuerza bruta).
Seguro que no es ningúna persona fisica si no cualquier máquina comprometida con software instalado para tal fin
(Encontrar máquinas con asterisk y realizár ataques de fuerza bruta).
Con la cual pueden intentar millones de combinaciones para autentificarse en nuestro Asterisk.

La ip que generaba esto era la: 139.153.12.78 y según he podido averiguar es de una universidad de UK la cual tiene asignado un rango de ips que es el siguiente:

139.153.0.0/16

La solución fué sencilla, para este tema, Iptables como no 😛

iptables -t filter -A INPUT -s 139.153.0.0/16 -j DROP

Todo el tráfico que venga de ese rango, lo dropeará.

Ya he informado a la gente que administra dicha red y se han puesto manos a la obra para solventar el problema.

Saludos.

Share

Tormentas Broadcast (ARP Storm). Descubriendo el pc infectado

Hola.

En este articulo les enseñaré como descubrir el dispositivo que tantas peticiones  broadcast esta generando y tanto dolor de cabeza nos esta creando.

No vamos a utilizar ningún software milagroso ni nada excepciónal, nos valdremos de nuestro entorno bash, tcpdump y algo de ingenio con bash scripting…..

1 – Nuestro primer objetivo es ver el tráfico arp de nuestra red con tcpdump…
Sigue leyendo

Share

Tuneles: Conexiones INseguras convertidas en seguras

Hola. Esta vez vengo con un paper que a muchos les podra servir de útlidad. Vamos a hablar de los tuneles.

La definición & comprensión, al principio puede ser algo complicado, con lo que intentaré ser lo más claro posible.

¿Que es un Túnel?

Un tunel en la informática tiene el mismo significado que un túnel en nuestro lenguaje humano. Se trata de transportar un protocolo dentro de otro, y es lo que vamos a hacer a continuación.

No me quedo muy claro…

Vamos con un ejemplo entonces.

Imagina que la gente viaja en coche por un tramo, y este tiene gran porcentaje de accidentes con coche.

Por otro lado tenemos el tren por ejemplo que es mucho más seguro y los accidentes por este medio de transporte han sido muchisimos menos, con lo que es más seguro.

¿Que se haria si quisieramos bajar ese porcentaje de accidentes en ese tramo?

Lógicamente, meteriamos el coche dentro del tren y este, pasaria el tramo que es tan peligroso para el coche. Con esto  hemos creado un “tunel”, hemos metido el coche dentro del tren para utilizar los beneficios del tren para nuestro vehiculo el coche….

Esto es exáctamente lo que vamos a hacer en este paper, utilizar ssh para obtener las grandes ventajas de su criptografia y asi que nuestras contraseñas/tráfico no viajen por la red en texto plano (totalmente legible).

Los pasos de la conexión

Los pasos que se siguen para crear un túnel son los siguientes:

– El cliente ssh (putty en este ejemplo), conecta con el servidor ssh. Este nos pide user y pass y lo introducimos.

– Una vez logeados correctamente, el serivdor ssh conecta con nuestra máquina por el puerto que hemos querido realizár el tunel.  Se realiza una conexión inversa (reverse). El servidor conecta con el cliente, y le facilita el servicio del túnel creado (en este caso Cpanel, puerto 2550).

Creando el túnel


Para crear el túnel necesitamos una ip de un servidor ssh que tengamos (en este caso 192.168.0.1).

– El puerto de que servicio queremos hacer el túnel (en este caso quiero hacerlo de un panel de control Cpanel que funciona por el puerto 2550)

– Abrir la conexión con el servidor ssh, logearnos con nuestros datos y mantener la sesión activa para que el túnel con el servidor ssh —–> nuestra máquina.   Sigan funcionando.

Manos a la obra……

Aunque parezca una tarea muy tediosa no lo és. Nosotros lo vamos a hacer con putty.

Introducimos en la ventana principal (Session), la ip y puerto de nuestro servidor ssh.

(IP: 192.168.0.1; Puerto: 22)

Connection —> SSH —> Tunnels

Buscamos el texto ‘Add new forwarded port:

Source port: (Escribimos el puerto al que nos conectaremos para abrir el servicio) (mi ejemplo 8888)

Destination: (Escribimos IP:Puerto. La ip del servidor que queremos hacer tunneling y el servicio (puerto)) ( mi ejemplo: 192.168.0.1:2550)

Pulsamos el boton Open.

Introducimos el usuario y password de nuestro servidor ssh y dejamos la sesión activa.

Ahora, como al servicio que queria acceder era un cpanel, y en Source Port hemos elejido de puerto Local 8888, lo único que tenemos que hacer es abrir una ventana de navegador y escribir:

http://192.168.0.1:8888

Con esto tendré acceso al servicio de 2550 del otro lado del túnel, pero pasando por el túnel de SSH, que convertirá la conexión en encriptada.

Un saludo.

ZaPa.

Share

Enviando ficheros con Netcat: La Navaja Suiza

Como muchos sabeis netcat se apoda “La navaja suiza” de los hackers, ya que, como muchos desconocen (yo también) permite hacer muchas más cosas de las que creemos.

Lo que vamos a hacer en este caso es transmitir un fichero con netcat, es muy sencillo.

1. EL SERVIDOR NETCAT (EL QUE ESCUCHA & RECIBE)

Lo primero que tenemos que hacer es en la máquina server (la que recibirá el fichero) dejar netcat a la escucha con el siguiente comando:

#############################
netcat -l -p 1111 > recibido.txt
##########################

Como podeis observar, dejamos netcat a la escucha en el puerto 1111.

Algunos os preguntareis “¿que significa ‘>’?”
Este caracter permite reedirecionar las salidas de los comandos a ficheros de todo nuestro sistema.
Con lo cual, con este comando lo que le decimos es que, la salida de netcat en todo momento lo guarde en el fichero recibido.txt
(Ahora aún no va a generar ningún contenido dentro de recibido.txt ya qué ningún cliente se nos ha conectado al servidor netcat)…

2. LA CONEXIÓN DEL CLIENTE.

Anteriormente hemos dejado el servidor a la “escucha” de que alguien se conecte. Pero nosotros vamos a realizár una conexión pero utilizando tuberias, es decir, “la salida de un comando la pasará a netcat y el servidor lo podrá recibir”…Manos a la obra:

################################
cat ficheroaenviar.txt | netcat IPSERVIDOR  1111
################################

Aquí utilizamos varias cosas nuevas.

– Tuberias (como he dicho anteriormente). Con cat leemos el ficheroaenviar.txt y la salida de cat (el contenido del fichero) se lo pasará a netcat.

– IPSERVIDOR – Este parámetro se debe completar para la conexión desde un cliente a un servidor netcat, si netcat no sabe la ip donde conectarse no realizará la conexión.

– Puerto – Utilizamos el puerto que definimos en el servidor, y es el (1111).

3. LEYENDO EL ARCHIVO

Si todo ha funcionado correctamente, nos dirijimos al terminal donde dejamos el servidor netcat funcionando y pulsamos ControlZ (Control y Z) para pausar la escucha de netcat.

Ahora simplemente nos queda hacer un:

#################
cat recibido.txt
#################

Y podemos observar que tenemos el contenido que creamos en el cliente con el nombre ‘ficheroaenviar.txt’.

Si aplicamos algo de ingenio a todo esto,podemos realizar transferencia de archivos de cualquier tipo,ficheros binarios y demás.

4. AGRADECIMIENTOS.

A todos los foreros de gentoo forums y en especial a Inodoro_Pererya que sin él este howto no hubiera sido posible.
Saludos para todos (;

Un saludo.
Att. ZaPa.

Share