🚀 go-pugleaf

D./D�a. Gonzalo =?ISO-8859-15?Q?P=E9rez?= de Olaguer
=?ISO-8859-15?Q?C=F3rdo?= =?ISO-8859-15?Q?ba?=, 
 el d�a del Se�or dom 02 dic 2007 12:09:37p
 expres� publicamente en "es.comp.hackers":

> Hola PepeGotera <no@lodoy.ya>
> el Sat, 1 Dec 2007 19:37:23 +0000 (UTC) escribiste:
> 
>> >>> PepeGotera escribi�:
>> >>> 
>> >>>> Hola,
>> >>>> 
>> >>>> estoy buscando una herramienta que haga lo siguiente:
>> >>>> 
>> >>>> - Ejecuta un programa que se conecta a INET
>> >>>> - Conecte a una IP/puerto determinado
>> >>>> - Bloquea/desbloquee a petici�n la emisi�n e informaci�n que el
>> >>>> programa env�a a petici�n (osea, un pause).
>> >>>> - Lleve una consola para poder enviar informaci�n en ambos
>> >>>> sentido 
> s,
>> >>>> hacia mi ejecutable y hacia la conexi�n remota.
>> >>>> 
>> >>>> La idea es enviar una informaci�n por consola en primer lugar a
>> >>>> una conexi�n remota y despu�s que el programa que tengo se
>> >>>> comunique 
>  a
>> >>>> trav�s de la misma conexi�n sin interrunpirla al remoto.
>> >>>> 
>> >>>> 
>> >>>> 
>> >>>> 
>> >>>> Se agradece cualquier tipo de informaci�n, webs donde consultar,
>> >>>> etc...
>> >>>> 
>> >>>> 
>> >>> 
>> >>> �chale un vistazo a netcat.
>> >>> 
>> >> 
>> >>  
>> >>  Roberto,
>> >>  
>> >>  Se agradece mucho la informaci�n, veo que el Netcat esta de p.m.,
>> >>  y 
>  
>> le
>> >>  he estado echando un vistado y creo que sirve como servidor �
>> >>  como cliente, pero como servidor y cliente al mismo tiempo no hay
>> >>  coj... a que funcione �Hago algo mal?
>> > 
>> > �A qu� te refieres con servidor y cliente al mismo tiempo?
>> > 
>> 
>> 
>> Pues que lo que busco es que haga de proxy, pero los datos enviados
>> por la conexi�n de servidor se puedan "manipular".
>> 
>> El netcat he visto que, � hace se servidor � hace de cliente, pero no
>  a 
>> la vez.
>> 
>> Lo que busco es hacer �sto, pero necesito hacerlo por la misma conexi
> �n. 
>> 
>> Programa1 ---\
>>               \-------- Remoto
>> Programa 2---/
>> 
>> 
>> Abrir la conexi�n con el programa 1 (una consola), teniendo bloqueado
>> e 
> l 
>> programa 2, y despu�s desploquedo el programa2 para que se pueda 
>> comunicar con el remoto. El programa1 se puede quedar� a la escucha 
>> (osea, har�a de snnifer), mostrandome la informaci�n en la consola.
>> 
>> 
>> �Se entiende mejor � es m�s l�o?
> 
> A ver si lo he entendido:
> 
> - est�s en el ordenador local y ejecutas programa2, el cual se conecta
>   a un puerto determinado del ordenador remoto y se comunica con �l
> 
> - sigues en el ordenador local, y ejecutas el programa1, el cual
>   intercepta la comunicaci�n entre programa2 y remoto, y te suministra
>   una consola desde la que puedes controlar el flujo de informaci�n,
>   deteni�ndolo, desvi�ndolo, insertando o suprimiendo datos, etc.
> 
> �Es eso?
> 
> No conozco ning�n programa que haga exactamente eso. Engancharse a un
> socket ya en uso, para capturar el tr�fico, lo puedes hacer con
> tcpdump, por ejemplo, pero no s� si puedes insertar mensajes. Los
> mensajes los podr�as insertar con netcat, supongo, pero usando puertos
> distintos a los usados por programa2. Para enviar paquetes con
> direcciones hackeadas puedes usar hping.
> 
> Para pasar de esto:
> 
> programa2 <--> remoto
> 
> a esto:
> 
> programa2 <--> programa1 <--> remoto
> 
> podr�as usar NAT (iptables) para redirigir el tr�fico.
> 
> Vaya, yo lo veo un poco complicado.
> 
> �No puedes hacerlo de otra manera? �No se puede ejecutar programa1
> antes que programa2? �programa2 puede redirigirse a otro ip:puerto
> remoto? 
> 



Gonzalo, el primer planteamiento que hice es el que t� has entendido, con 
la salvedad que el primer intercambio de datos lo har�a la consola.

programa2 <--a--> programa1 (con consola)  <--b--> remoto

En este caso la conexi�n "a" se debe poder bloquear/desbloquear 
manualmente.Osea, si la conexi�n "a" est� bloqueada los datos solo 
aparecer�an en consola.

Resumiendo, el programa buscado "programa1"
Tipo de conexiones en programa1:
"a" como servidor, con bloqueo de datos. Tambi�n ser�a v�lido un filtro de 
datos en vez del bloqueo.
"b" como cliente

con lo que:
"a" en programa2 es cliente
"b" en remoto es servidor







El segundo planteamiento que hago, y que tambi�n ser�a v�lido es el 
siguiente: 

Cualquier consola<-------c----------\
                                     \>Programa1<--e--->Remoto  
                                     /  
Programa2<-------------d------------/

En este caso el programa buscado ser�a tambi�n el programa1. La consola 
evidentemente no es problema.

La diferencia con lo que t� planteas es que el primer intercambio de datos 
ser�a desde consola, con lo cual la conexi�n "d" debe 
bloquearse/desbloquearse desde el programa1 manualmente.

Las conexiones en el programa1 ser�an:

"c" como servidor.
"d" como servidor, con bloqueo � filtro configurable de datos
"e" como cliente

con lo que:
"c" en consola es cliente
"d" en programa2 es cliente
"e" en remoto es servidor 



Respecto a tus preguntas:

> �No puedes hacerlo de otra manera? �No se puede ejecutar programa1
> antes que programa2? �programa2 puede redirigirse a otro ip:puerto
> remoto? 
> 

 1.- Las 2 maneras que veo son las que he expuesto.
 2.- S� se puede ejecutar programa1 antes de programa2, de hecho es lo que 
necesito.
 3.- programa2 no se entiende con remoto nada m�s abrir la conexi�n, sino 
que necesita de unas pocas instrucciones de consola para que se pueda 
entenderse. 

Digamos que "programa2" y "remoto" son t�midos y necesitan que "programa1" 
los presente para que ellos empiecen a hablar.


Un saludo 
PepeGotera







  


.
.
.
.
.
.
.
.