lunes, 21 de noviembre de 2011

Usar/configurar Nessus en Backtrack5




Por defecto Nessus ya viene instalado en BAcktrack 5, para poder hacer uso de este útil escáner de vulnerabilidades en BT5, se deben seguir los siguentes pasos:
  • Conseguir la clave o el código de activación, registrandose en el sitio WEb de Teneable/Nessus, en este enlace.
Luego de ingresar los datos y registrarse, una clave es enviada al correo.
  • Ingresar la clave/código de activación
Esto lo podemos realizar mediante el siguiente comando:
#/opt/nessus/bin/nessus-fetch –register xxxx-xxxx-xxxx-xxxx, donde se reemplaza las X por el código que nos fue asignado
  • Crear un nuevo usuario, con su respectiva contraseña:
A traves del siguiente comando:
#/opt/nessus/sbin/nessus-adduser
  • Iniciar el servicio:
# /etc/init.d/nessusd start
  • Finalmente, arrancar nessus a traves del navegador, colocando en el mismo: https://127.0.0.1:8834
Fuente: cesarin

domingo, 20 de noviembre de 2011

Mover app "no movibles" a SD en Android

Muchos usuarios en un día se encuentran con que les falta memoria en sus teléfonos con OS Android, hoy toco y a mi. Viendo kit de herramientas de seguridad para android me puse instalar y probar muchas de ellas, y en un momento me salio un aviso que hace falta memoria para instalar app.

Existen aplicaciones que se pueden moverse a sd sin problemas con applicacion como App2sd, pero muchas aun no son movibles por defecto.

En internet existen muchos manuales como mover las apps "no movibles", yo probe a2sd [una de las mas famosas] pero no funciono. Googleando encontré app Link2sd, y me funciono, asi que os dejo un pequeño manual como usarlo.

Cómo pasar las aplicaciones a la SD con Link2SD

Paso 0

 Para comenzar necesitamos tener permiso de root!

Paso 1 Particionar la SD

Cuidado, al particionar la SD borraremos todo el contenido. Haced una copia antes.
Para pasar una aplicación a la SD, lógicamente necesitaremos una SD particionada. ¿Cómo se hace eso? Muy sencillo.

Opción 1: Con ROM Manager.

Tan solo hay que seleccionar la opción Particionar la SD y dejar los valores que nos sugiere.

Opción 2: Desde un PC
  • Aquí tenéis un buen tutorial muy sencillo para Windows.
  • Aquí otra para Ubuntu.
  • Para Mac podéis probar esto o bien utilizar un LiveCD de Ubuntu.

Paso 2: Link2SD

Si ya eres root y tienes la SD particionada, ya lo tienes casi todo hecho. Para pasar las aplicaciones a la SD utilizaremos Link2SD.

La idea es la misma que con las otras aplicaciones de apps2sd, pero difiere en dos aspectos. El primero es que en lugar de vincular la carpeta /data/app ( lo que significa mover todas las aplicaciones), puedes seleccionar las aplicaciones que deseas mover. El segundo es que es una aplicación (no un script), por lo que  tiene una interfaz de usuario y puedes gestionar las aplicaciones, crear o eliminar los enlaces con un solo click (en las otras apps tan solo puedes decir que se muevan a la SD).
Para pasar una aplicación a la SD, basta con elegir la app que queramos y seleccionamos la opción Crear Link. Y ya está.
En resumen, una muy buena aplicación, funciona desde Android 1.6+ , es sencilla y funciona a las mil maravillas.



Fuente: elandroidelibre

sábado, 19 de noviembre de 2011

Kit de herramientas de seguridad y hacking para Android


Esta no es una lista cerrada (la iremos ampliando), vamos a mostrar algunas aplicaciones gratuitas que convierten tu Android en un auténtico road warrior para la auditar la seguridad de todo tipo de redes y sistemas.
Lo primero ya sabes, es necesario que tengas tu Android rooteado, la mayoría de estas aplicaciones lo requieren. Android es
prácticamente
un Linux, y por lo tanto estas aplicaciones de bajo nivel requieren acceso root a la mayoría de las funciones del sistema.
Vamos con esta auténtica navaja suiza de la seguridad Android:

Router Passwords: más que una aplicación, es una base de datos con toda la información  (login y passwords por defecto) de multitud de routers de todas las marcas.

Router Brute Force: si no quieres molestarte mirando el diccionario en la aplicación anterior, puedes intentar averiguarla (por fuerza bruta, usando diccionarios) a través de este programa. Si ya tienes acceso a una red, esta herramienta es perfecta para intentar acceder al router.

Terminal Emulator: necesario, tener siempre a mano una ventana de línea de comandos (shell de Linux) por lo que pueda pasar ;)

Wireless Tether:  si necesitas conectar el ordenador a Internet, esta es la aplicación perfecta para hacerlo desde el móvil. Crea un WiFi desde la cual puedes conectar cualquier ordenador y tener acceso a la web.

NetWork Discovery: creo que es la aplicación que más información te ofrece sobre una red. Es capaz de escanear una red y mostrar un listado de todos los dispositivos conectados a la misma con sus respectivas direcciones IP y MAC. Pero no sólo eso, además te lo identifica, si es un router, un PC, una impresora, etc.

PulWifi: muestra las contraseñas por defecto de algunos puntos de acceso WiFi. Soporta las de WLAN_XXXXX, JAZZTEL_XXXXX, YACOMXXXXX, WIFIXXXX, algunos modelos de D-Link y de Huawei. Perfecto para analizar el nivel de seguridad de tu WiFi.

Shark: sniffer  de red que funciona en 3G y Wifi. Es un port del famoso tcpdump. Te permite examinar los paquetes TCP/IP que pasan por tu sistema.

ConnectBot: cliente Telnet/SSH de código abierto, permite también hacer SSH tunneling (técnica utilizada para evitar cortafuegos ó proteger tu información).

WifiAnalyzer: otra herramienta más para analizar a fondo una WiFi. Muestra los canales, MAC, tipo de encriptación y la potencia de la señal. Ideal para encontrar el canal perfecto para ajustar nuestro hardware.

ElectroDroid: cuando tienes que pasar a la acción a nivel hardware, esta aplicación puede que te venga bien. Es una biblioteca de referencia sobre Electrónica, que incluye código de color de resistencias, calculadora de varias fórmulas electrónicas, patillaje de todos los puertos de un ordenador y de aparatos de video, tablas de todo tipo, etc. Indispensable.

WLANAudit: aplicación para encontrar redes WiFi y comprobar su seguridad. Con algunos puntos es capaz de calcular la contraseña por defecto del cifrado empleado.

WiFi File Explorer: permite compartir ficheros desde tu dispositivo móvil. En otras palabras, convierte tu móvil en un servidor de ficheros dentro de la red.

Bluetooth File Transfer: busca, explora y gestiona ficheros en cualquier dispositivo Bluetooth usando FTP y OPP. No sólo vivimos de WiFi’s ;)

Hackers Dictionary: por si olvidas algún término, aquí tienes el famoso Jargon File.

Working with BackTrack: desde la instalación de BackTrack hasta todo tipo de información sobre esta distribución Linux de seguridad. Incluye vídeos y documentos de todo tipo, altamente recomendable.

Droidsheep: si ya conoces Firesheep ya sabes de que va esta herramienta. Como la definen en su web “Secuestro de sesiones en un sólo click” o como diría yo (tuxotron) “Secuestro de sesiones a golpe de
ratón
dedo” :) .

Faceniff: permite capturar sesiones web sobre wifi. Funciona sobre redes Abierta/WEP/WPA-PSK/WPA2-PSK. Es parecida a Droidsheep.

Router Keygen: al igual que PullWifi, detecta y genera las claves de encriptación (WEP y WPA) por defecto de: Routers basados enThomson (Thomson, SpeedTouch, Orange, Infinitum, BBox, DMax, BigPond, O2Wireless, Otenet, Cyta , TN_private ), DLink (sólo algunos modelos), Pirelli Discus, Eircom, Verizon FiOS (sólo algunos modelos), Alice AGPF, FASTWEB Pirelli and Telsey, Huawei (algunos Infinitum), Wlan_XXXX or Jazztel_XXXX (Comtrend y Zyxel), Wlan_XX (algunos modelos), Ono ( P1XXXXXX0000X ), WlanXXXXXX, YacomXXXXXX y WifiXXXXXX (también conocido como wlan4xx ), Sky V1, Clubinternet.box v1 y v2 (TECOM), InfostradaWifi

Fing – Network Tools: herramienta que nos provee funcionalidades para sacar todo tipo de información de un red: network discovery, escaneo de servicios, ping, traceroute, DNS lookup, etc. Muy completa.

Shark Reader: lector de ficheros pcap. Por lo visto tiene problemas con ficheros grandes, pero nos podría resultar muy útil para echar un vistazo rápido después de haber capturado tráfico de red.

Arpspoof: una utilidad casi indispensable para capturar tráfico de red que no vaya dirigido a nosotros usando lo que se conoce como arp spoofing. Digo casi indispensable, porque que podemos conseguir lo mismo con tcpdump.

tcpdump: este no lo teníamos en la lista y que puede decir de éste. Tcpdump es la herramienta de facto de cualquier máquina *nix, para analizar el tráfico de red y por consiguiente capturarlo. Esta versión para Android no tiene la potencia que la de un sistema *nix, pero nos ofrece las funcionalidades básicas, entre ellas la captura de paquetes.

Anti: Android Network Toolkit es un conjunto de utilidades que nos permite explotar servicios en una red local. Es una especie de mini metasploit para Android. El problema es que tiene varias versiones y con lo que te ofrece la gratuita lo puedes hacer con el resto de herramientas aquí listadas, pero se eres un profesional de la seguridad informática, ésta seria una gran adición a tu caja de herramientas.

Routerpwn: colección de vulnerabilidades para los rourters más conocidos y dispositivos embebidos.
Bueno esta lista supongo que se puede ampliar, esperamos vuestras aportaciones.
Por supuesto, CyberHades Y D00m3dR4v3n no se hacen responsables del mal uso de todas estas aplicaciones, vamos que ya somos mayorcitos ;) 

Fuente: cyberhades

Curso online sobre Python

Aquí tenéis una lista vídeos magníficos si os queréis iniciar y/o profundizar en la programación en Python:

Fuente:  cyberhades

Como ejecutar app de Windows en Mac

Apple Mac son mucho más rápidos y elegantes de la PC con Windows, pero hay una gran cosa acerca de Windows de la PC, que no se puede negar, es que, el sistema operativo Windows tiene una colección muy grande de aplicaciones en comparación con el Mac OS. Si usted es un usuario de Mac, entonces no debería ser necesario preocuparse ahora, ya que ahora se puede ejecutar cualquier aplicación de Windows en su Mac OS utilizando WinOnX.

Todo lo que necesitas es tener un sistema operativo Mac 10.6 o superior para instalar este programa. WinOnX es un increíble debe haber emulador de Mac OS y se puede descargar desde la tienda MacApp por sólo $ 4.99.

¿Cómo ejecutar programas de Windows en Mac OS X utilizando WinOnX:

Paso 1: Lo primero es descargar e instalar WinOnX de la Mac App Store.


  

Paso 2: Descargar e instalar cualquier aplicación de Windows que desea ejecutar en el Mac OS.


Paso 3: El último paso es buscar el programa en tu Mac. Haga doble clic en él y empezar a disfrutar de la aplicación de Windows en su Mac OS.


Bueno, de esta manera se puede utilizar cualquier aplicación de Windows en tu Mac OS por sólo $ 4.99.

Fuente:  limera1n

En principio es igual que WINE para Linux, aun no tuve posibilidad de probarlo bien, asi que cuando hago unas pruebas ya os contare si es igual o mucho mejor.
 

viernes, 18 de noviembre de 2011

Interesante listado de enlaces sobre Python

 Esta colección de enlaces te puede venir bien si estás desarrollando o aprendiendo el lenguaje Python. Desde una guía a la programación en red con Python, videos y hasta un intérprete de Lisp:
“Must read”:
Begin­ner Python:
Python Style:
Python Books:
Python Videos:
  • Python Miro Com­mu­nity
    • This con­tains hun­dreds of videos from Python con­fer­ences all over the world includ­ing past PyCons.
Python Classes:
Python Inter­nals:
Python His­tory:
PyPy:

Fuente: cyberhades

miércoles, 9 de noviembre de 2011

.htaccess

.htaccess es un archivo de texto oculto que contiene una serie de directivas para el servidor Apache. Cuando un cliente solicita un archivo al servidor, este busca desde el directorio raíz hasta el subdirectorio que contiene el archivo solicitado el archivo .htaccess y tiene en cuenta estas reglas antes de proceder con la petición, es decir, se aplican las normas especificadas al directorio en el que se encuentre .htaccess y los directorios por debajo de él.

Ejemplos de usos para .htaccess pueden ser restringir el acceso a determinados archivos, impedir el listado de los archivos de un directorio, redireccionar, personalizar las páginas de error o impedir el acceso a determinadas IPs o rangos de IP.

Impedir el listado del contenido de un directorio
Cuando se intenta acceder a un directorio, en ausencia de un archivo de índice, Apache muestra por defecto el contenido del directorio. Si queremos impedir al usuario ver el contenido de un directorio, bastaría con crear un archivo de índice, por ejemplo index.html, pero existe una solución más elegante mediante la directiva Options. Basta crear un archivo .htaccess que contenga la línea:
Options -Indexes
También podríamos utilizar la directiva DirectoryIndex, que especifica qué archivos actúan como índice por defecto, y que archivo mostrar en el caso de que estos no se encuentren. Por ejemplo la línea:
DirectoryIndex index.php index.html index.htm /prohibido.php
indicaría al servidor que debe buscar los archivos index.php, index.html o index.htm, en ese orden, y en el caso de no encontrar ninguno de ellos, cargar el archivo prohibido.php.

Redireccionar el tráfico web
Si nos encontramos con la necesidad de enviar al usuario a una determinada dirección web cuando pida una cierta página, por ejemplo porque la hallamos movido, podemos utilizar la directiva Redirect de Apache.
Redirect /antiguo.php http://mundogeek.net/otros/nuevo.php

Crear un mensaje de error personalizado
Este es uno de los usos más frecuentes para el archivo .htaccess. En ocasiones se pueden producir errores que deben ser notificados al usuario, por ejemplo en el caso de que se intente acceder a una página que no existe, bien por un fallo del usuario al introducir la url, o bien porque la página haya sido movida o eliminada. Estos mensajes suelen estar escritos en inglés, no ofrecen demasiada información al usuario, y rompen la estética general del sitio, por lo que es imprescindible personalizarlos.

Para lograrlo utilizamos la directiva ErrorDocument, del que tenemos un ejemplo a continuación:
ErrorDocument 403 "Acceso denegado
ErrorDocument 404 /404.php
ErrorDocument 500 /500.php


Los códigos de error 403, 404 y 500 son los más comunes, y se producen respectivamente cuando no se tiene permiso para acceder a una página, cuando no se encuentra un archivo y debido a un error interno del servidor.

La primera línea indica al servidor que muestre el mensaje ‘Acceso denegado’ siempre que se produzca el error 403. Las otras líneas ilustran la forma de indicar al servidor que muestre una determinada página cuando se produzca un error (se puede usar direcciones relativas o absolutas).

Fuente:  mundogeek.net

lunes, 7 de noviembre de 2011

Python threads synchronization: Locks, RLocks, Semaphores, Conditions, Events and Queues

Aqui os dejo un manual sobre  "Python threads synchronization: Locks, RLocks, Semaphores, Conditions, Events and Queues" que me gusto mucho y que esta muy bien explicado.

This article describes the Python threading synchronization mechanisms in details. We are going to study the following types: Lock, RLock, Semaphore, Condition, Event and Queue. Also, we are going to look at the Python internals behind those mechanisms.
The source code of the programs below can be found at github.com/laurentluce/python-tutorials under threads/.
First, let’s look at a simple program using the threading module with no synchronization.

Threading


We want to write a program fetching the content of some URLs and writing it to a file. We could do it serially with no threads but to speed things up, we are going to create 2 threads processing half of the URLs each.
Note: The best way here would be to use a queue with the URLs to fetch but this example is more suitable to begin our tutorial.
The class FetchUrls is thread based and it takes a list of URLs to fetch and a file object to write the content to.

class FetchUrls(threading.Thread):
  """
  Thread checking URLs.
  """

  def __init__(self, urls, output):
    """
    Constructor.

    @param urls list of urls to check
    @param output file to write urls output
    """
    threading.Thread.__init__(self)
    self.urls = urls
    self.output = output

  def run(self):
    """
    Thread run method. Check URLs one by one.
    """
    while self.urls:
      url = self.urls.pop()
      req = urllib2.Request(url)
      try:
        d = urllib2.urlopen(req)
      except urllib2.URLError, e:
        print 'URL %s failed: %s' % (url, e.reason)
      self.output.write(d.read())
      print 'write done by %s' % self.name
      print 'URL %s fetched by %s' % (url, self.name)

The main function starts the 2 threads and then wait for them to finish.

def main():
  # list 1 of urls to fetch
  urls1 = ['http://www.google.com', 'http://www.facebook.com']
  # list 2 of urls to fetch
  urls2 = ['http://www.yahoo.com', 'http://www.youtube.com']
  f = open('output.txt', 'w+')
  t1 = FetchUrls(urls1, f)
  t2 = FetchUrls(urls2, f)
  t1.start()
  t2.start()
  t1.join()
  t2.join()
  f.close()

if __name__ == '__main__':
  main()

The issue is that both threads are going to write to the file at the 
same time, resulting in a big mess. We need to find a way to only have 1
 thread writing to the file at a given time. To do that, one way is to 
use synchronization mechanisms like locks.

Lock

 

Locks have 2 states: locked and unlocked. 2 methods are used to manipulate them: acquire() and release(). Those are the rules:
  • if the state is unlocked: a call to acquire() changes the state to locked.
  • if the state is locked: a call to acquire() blocks until another thread calls release().
  • if the state is unlocked: a call to release() raises a RuntimeError exception.
  • if the state is locked: a call to release() changes the state to unlocked().
To solve our issue of 2 threads writing to the same file at the same time, we pass a lock to the FetchUrls constructor and we use it to protect the file write operation. I am just going to highlight the modifications relevant to locks. The source code can be found in threads/lock.py.

class FetchUrls(threading.Thread):
  ...

  def __init__(self, urls, output, lock):
    ...
    self.lock = lock

  def run(self):
    ...
    while self.urls:
      ...
      self.lock.acquire()
      print 'lock acquired by %s' % self.name
      self.output.write(d.read())
      print 'write done by %s' % self.name
      print 'lock released by %s' % self.name
      self.lock.release()
      ...

def main():
  ...
  lock = threading.Lock()
  ...
  t1 = FetchUrls(urls1, f, lock)
  t2 = FetchUrls(urls2, f, lock)
  ...

Let’s look at the program output when we run it:
$ python locks.py
lock acquired by Thread-2
write done by Thread-2
lock released by Thread-2
URL http://www.youtube.com fetched by Thread-2
lock acquired by Thread-1
write done by Thread-1
lock released by Thread-1
URL http://www.facebook.com fetched by Thread-1
lock acquired by Thread-2
write done by Thread-2
lock released by Thread-2
URL http://www.yahoo.com fetched by Thread-2
lock acquired by Thread-1
write done by Thread-1
lock released by Thread-1
URL http://www.google.com fetched by Thread-1
The write operation is now protected by a lock and we don’t have 2 threads writing to the file at the same time.
Let’s take a look at the Python internals. I am using Python 2.6.6 on Linux.
The method Lock() of the threading module is equal to thread.allocate_lock. You can see the code in Lib/threading.py.

Lock = _allocate_lock
_allocate_lock = thread.allocate_lock

The C implementation can be found in Python/thread_pthread.h. We 
assume that our system supports POSIX semaphores. sem_init() initializes
 the semaphore at the address pointed by lock. The initial value of the 
semaphore is 1 which means unlocked. The semaphore is shared between the
 threads of the process.

PyThread_type_lock
PyThread_allocate_lock(void)
{
    ...
    lock = (sem_t *)malloc(sizeof(sem_t));

    if (lock) {
        status = sem_init(lock,0,1);
        CHECK_STATUS("sem_init");
        ....
    }
    ...
}

When the acquire() method is called, the following C code is 
executed. waitflag is equal to 1 by default which means the call blocks 
until the lock is unlocked. sem_wait() decrements the semaphore’s value 
or blocks until the value is greater than 0 e.g. unlocked by another 
thread.

int
PyThread_acquire_lock(PyThread_type_lock lock, int waitflag)
{
    ...
    do {
        if (waitflag)
            status = fix_status(sem_wait(thelock));
        else
            status = fix_status(sem_trywait(thelock));
    } while (status == EINTR); /* Retry if interrupted by a signal */
    ....
}

When the release() method is called, the following C code is 
executed. sem_post() increments the semaphore’s value e.g. unlocks the 
semaphore.

void
PyThread_release_lock(PyThread_type_lock lock)
{
    ...
    status = sem_post(thelock);
    ...
}

You can also use the “with” statement. The Lock object can be used as
 a context manager. The advantage of using “with” is that the acquire() 
method will be called when the “with” block is entered and release() 
will be called when the block is exited. Let’s rewrite the class 
FetchUrls using the “with” statement.

class FetchUrls(threading.Thread):
  ...
  def run(self):
    ...
    while self.urls:
      ...
      with self.lock:
        print 'lock acquired by %s' % self.name
        self.output.write(d.read())
        print 'write done by %s' % self.name
        print 'lock released by %s' % self.name
      ...

RLock

 

RLock is a reentrant lock. acquire() can be called multiple times by the same thread without blocking. Keep in mind that release() needs to be called the same number of times to unlock the resource.
Using Lock, the second call to acquire() by the same thread will block:
lock = threading.Lock()
lock.acquire()
lock.acquire()
If you use RLock, the second call to acquire() won’t block.
rlock = threading.RLock()
rlock.acquire()
rlock.acquire()
RLock also uses thread.allocate_lock() but it keeps track of the owner thread to support the reentrant feature. Following is the RLock acquire() method implementation. If the thread calling acquire() is the owner of the resource then the counter is incremented by one. If not, it tries to acquire it. First time it acquires the lock, the owner is saved and the counter is initialized to 1.

def acquire(self, blocking=1):
    me = _get_ident()
    if self.__owner == me:
        self.__count = self.__count + 1
        ...
        return 1
    rc = self.__block.acquire(blocking)
    if rc:
        self.__owner = me
        self.__count = 1
        ...
    ...
    return rc

Let’s look at the RLock release() method. First is a check to make 
sure the thread calling the method is the owner of the lock. The counter
 is decremented and if it is equal to 0 then the resource is unlocked 
and available for grab by another thread.

def release(self):
    if self.__owner != _get_ident():
        raise RuntimeError("cannot release un-acquired lock")
    self.__count = count = self.__count - 1
    if not count:
        self.__owner = None
        self.__block.release()
        ...
    ... 
 

Condition

 

This is a synchronization mechanism where a thread waits for a specific condition and another thread signals that this condition has happened.
A good way to illustrate this mechanism is by looking at a producer/consumer example. The producer appends random integers to a list at random time and the consumer retrieves those integers from the list. The source code can be found in threads/condition.py.
Let’s look at the producer class. The producer acquires the lock, appends an integer, notifies the consumer thread that there is something to retrieve and release the lock. It does that forever with a random pause in between each append operation.

class Producer(threading.Thread):
  """
  Produces random integers to a list
  """

  def __init__(self, integers, condition):
    """
    Constructor.

    @param integers list of integers
    @param condition condition synchronization object
    """
    threading.Thread.__init__(self)
    self.integers = integers
    self.condition = condition

  def run(self):
    """
    Thread run method. Append random integers to the integers list at random time.
    """
    while True:
      integer = random.randint(0, 256)
      self.condition.acquire()
      print 'condition acquired by %s' % self.name
      self.integers.append(integer)
      print '%d appended to list by %s' % (integer, self.name)
      print 'condition notified by %s' % self.name
      self.condition.notify()
      print 'condition released by %s' % self.name
      self.condition.release()
      time.sleep(1)

Next is the consumer class. It acquires the lock, checks if there is 
an integer in the list, if there is nothing, it waits to be notified by 
the producer. Once the element is retrieved from the list, it releases 
the lock.
Note that a call to wait() releases the lock so the producer can acquire the resource and do its work.

class Consumer(threading.Thread):
  """
  Consumes random integers from a list
  """

  def __init__(self, integers, condition):
    """
    Constructor.

    @param integers list of integers
    @param condition condition synchronization object
    """
    threading.Thread.__init__(self)
    self.integers = integers
    self.condition = condition

  def run(self):
    """
    Thread run method. Consumes integers from list
    """
    while True:
      self.condition.acquire()
      print 'condition acquired by %s' % self.name
      while True:
        if self.integers:
          integer = self.integers.pop()
          print '%d popped from list by %s' % (integer, self.name)
          break
        print 'condition wait by %s' % self.name
        self.condition.wait()
      print 'condition released by %s' % self.name
      self.condition.release()


We need to write our main creating 2 threads and starting them:

def main():
  integers = []
  condition = threading.Condition()
  t1 = Producer(integers, condition)
  t2 = Consumer(integers, condition)
  t1.start()
  t2.start()
  t1.join()
  t2.join()

if __name__ == '__main__':
  main()

The output of this program looks like this:
$ python condition.py
condition acquired by Thread-1
159 appended to list by Thread-1
condition notified by Thread-1
condition released by Thread-1
condition acquired by Thread-2
159 popped from list by Thread-2
condition released by Thread-2
condition acquired by Thread-2
condition wait by Thread-2
condition acquired by Thread-1
116 appended to list by Thread-1
condition notified by Thread-1
condition released by Thread-1
116 popped from list by Thread-2
condition released by Thread-2
condition acquired by Thread-2
condition wait by Thread-2
Thread-1 appends 159 to the list then notifies the consumer and releases the lock. Thread-2 acquires the lock, retrieves 159 and releases the lock. The producer is still waiting at that time because of the time.sleep(1) so the consumer acquires the lock again then waits to get notified by the producer. When wait() is called, it unlocks the resource so the producer can acquire it and append a new integer to the list before notifying the consumer.
Let’s look at the Python internals for this condition synchronization mechanism. The condition’s constructor creates a RLock object if no existing lock is passed to the constructor. This lock will be used when acquire() and release() are called.

class _Condition(_Verbose):

    def __init__(self, lock=None, verbose=None):
        _Verbose.__init__(self, verbose)
        if lock is None:
            lock = RLock()
        self.__lock = lock

Next is the wait() method. We assume that we are calling wait() with 
no timeout value to simplify the explanation of the wait() method’s 
code. A new lock named waiter is created and the state is set to locked.
 The waiter lock is used for communication between the threads so the 
producer can notify the consumer by releasing this waiter lock. The lock
 object is added to the waiters list and the method is blocking at 
waiter.acquire(). Note that the condition lock state is saved at the 
beginning and restored when wait() returns.

def wait(self, timeout=None):
    ...
    waiter = _allocate_lock()
    waiter.acquire()
    self.__waiters.append(waiter)
    saved_state = self._release_save()
    try:    # restore state no matter what (e.g., KeyboardInterrupt)
        if timeout is None:
            waiter.acquire()
            ...
        ...
    finally:
        self._acquire_restore(saved_state)
 
The notify() method is used to release the waiter lock. The producer calls notify() to notify the consumer blocked on wait().

def notify(self, n=1):
    ...
    __waiters = self.__waiters
    waiters = __waiters[:n]
    ...
    for waiter in waiters:
        waiter.release()
        try:
            __waiters.remove(waiter)
        except ValueError:
            pass

You can also use the “with” statement with the Condition object so 
acquire() and release() are called for us. Let’s rewrite the producer 
class and the consumer class using “with”.

class Producer(threading.Thread):
  ...
  def run(self):
    while True:
      integer = random.randint(0, 256)
      with self.condition:
        print 'condition acquired by %s' % self.name
        self.integers.append(integer)
        print '%d appended to list by %s' % (integer, self.name)
        print 'condition notified by %s' % self.name
        self.condition.notify()
        print 'condition released by %s' % self.name
      time.sleep(1)

class Consumer(threading.Thread):
  ...
  def run(self):
    while True:
      with self.condition:
        print 'condition acquired by %s' % self.name
        while True:
          if self.integers:
            integer = self.integers.pop()
            print '%d popped from list by %s' % (integer, self.name)
            break
          print 'condition wait by %s' % self.name
          self.condition.wait()
        print 'condition released by %s' % self.name

Semaphore

 

A semaphore is based on an internal counter which is decremented each time acquire() is called and incremented each time release() is called. If the counter is equal to 0 then acquire() blocks. It is the Python implementation of the Dijkstra semaphore concept: P() and V(). Using a semaphore makes sense when you want to control access to a resource with limited capacity like a server.
Here is a simple example:

semaphore = threading.Semaphore()
semaphore.acquire()
# work on a shared resource
...
semaphore.release()

Let’s look at the Python internals. The constructor takes a value 
which is the counter initial value. This value defaults to 1. A 
condition instance is created with a lock to protect the counter and to 
notify the other thread when the semaphore is released.

class _Semaphore(_Verbose):
    ...
    def __init__(self, value=1, verbose=None):
        _Verbose.__init__(self, verbose)
        self.__cond = Condition(Lock())
        self.__value = value
        ...

Next is the acquire() method. If the semaphore’s counter is equal to 
0, it blocks on the condition’s wait() method until it gets notified by a
 different thread. If the semaphore’s counter is greater than 0, it 
decrements the value.

def acquire(self, blocking=1):
    rc = False
    self.__cond.acquire()
    while self.__value == 0:
        ...
        self.__cond.wait()
    else:
        self.__value = self.__value - 1
        rc = True
    self.__cond.release()
    return rc

The semaphore’s release() method increments the counter and then notifies the other thread.

def release(self):
    self.__cond.acquire()
    self.__value = self.__value + 1
    self.__cond.notify()
    self.__cond.release()

Note that there is also a bounded semaphore you can use to make sure 
you never call release() too many times. Here is the Python internal 
code use for it:

class _BoundedSemaphore(_Semaphore):
    """Semaphore that checks that # releases is <= # acquires"""
    def __init__(self, value=1, verbose=None):
        _Semaphore.__init__(self, value, verbose)
        self._initial_value = value

    def release(self):
        if self._Semaphore__value >= self._initial_value:
            raise ValueError, "Semaphore released too many times"
        return _Semaphore.release(self)

You can also use the “with” statement with the Semaphore object so acquire() and release() are called for us.
semaphore = threading.Semaphore()
with semaphore:
  # work on a shared resource
  ...

Event

 

This is a simple mechanism. A thread signals an event and the other thread(s) wait for it.
Let’s go back to our producer and consumer example and convert it to use an event instead of a condition. The source code can be found in threads/event.py.
First the producer class. We pass an Event instance to the constructor instead of a Condition instance. Each time an integer is added to the list, the event is set then cleared right away to notify the consumer. The event instance is cleared by default.

class Producer(threading.Thread):
  """
  Produces random integers to a list
  """

  def __init__(self, integers, event):
    """
    Constructor.

    @param integers list of integers
    @param event event synchronization object
    """
    threading.Thread.__init__(self)
    self.integers = integers
    self.event = event

  def run(self):
    """
    Thread run method. Append random integers to the integers list at random time.
    """
    while True:
      integer = random.randint(0, 256)
      self.integers.append(integer)
      print '%d appended to list by %s' % (integer, self.name)
      print 'event set by %s' % self.name
      self.event.set()
      self.event.clear()
      print 'event cleared by %s' % self.name
      time.sleep(1)

Next is the consumer class. We also pass an Event instance to the 
constructor. The consumer instance is blocking on wait() until the event
 is set indicating that there is an integer to consume.

class Consumer(threading.Thread):
  """
  Consumes random integers from a list
  """

  def __init__(self, integers, event):
    """
    Constructor.

    @param integers list of integers
    @param event event synchronization object
    """
    threading.Thread.__init__(self)
    self.integers = integers
    self.event = event

  def run(self):
    """
    Thread run method. Consumes integers from list
    """
    while True:
      self.event.wait()
      try:
        integer = self.integers.pop()
        print '%d popped from list by %s' % (integer, self.name)
      except IndexError:
        # catch pop on empty list
        time.sleep(1)

This is the output when we run the program. Thread-1 appends 124 to the list and then set the event to notify the consumer. The consumer’s call to wait() stops blocking and the integer is retrieved from the list.
$ python event.py
124 appended to list by Thread-1
event set by Thread-1
event cleared by Thread-1
124 popped from list by Thread-2
223 appended to list by Thread-1
event set by Thread-1
event cleared by Thread-1
223 popped from list by Thread-2
Let’s look at the Python internals. First is the Event constructor. A condition instance is created with a lock to protect the event flag value and to notify the other thread when the event has been set.

class _Event(_Verbose):
    def __init__(self, verbose=None):
        _Verbose.__init__(self, verbose)
        self.__cond = Condition(Lock())
        self.__flag = False

Following is the set() method. It sets the flag to True and notifies 
the other threads. The condition object is used to protect the critical 
part when the flag’s value is changed.

def set(self):
    self.__cond.acquire()
    try:
        self.__flag = True
        self.__cond.notify_all()
    finally:
        self.__cond.release()

Its opposite is the clear() method setting the flag to False.

def clear(self):
    self.__cond.acquire()
    try:
        self.__flag = False
    finally:
        self.__cond.release()

The wait() method blocks until the set method is called. The wait() method does nothing if the flag is set.

def wait(self, timeout=None):
    self.__cond.acquire()
    try:
        if not self.__flag:
            self.__cond.wait(timeout)
    finally:
        self.__cond.release()

Queue

 

Queues are a great mechanism when we need to exchange information between threads as it takes care of locking for us.
We are interested in the following 4 Queue methods:
  • put: Put an item to the queue.
  • get: Remove and return an item from the queue.
  • task_done: Needs to be called each time an item has been processed.
  • join: Blocks until all items have been processed.
Let’s convert our producer/consumer program to use a queue. The source code can be found in threads/queue.py.
First the producer class. We don’t need to pass the integers list because we are using the queue to store the integers generated. The thread generates and puts the integers in the queue in a forever loop.

class Producer(threading.Thread):
  """
  Produces random integers to a list
  """

  def __init__(self, queue):
    """
    Constructor.

    @param integers list of integers
    @param queue queue synchronization object
    """
    threading.Thread.__init__(self)
    self.queue = queue

  def run(self):
    """
    Thread run method. Append random integers to the integers list at random time.
    """
    while True:
      integer = random.randint(0, 256)
      self.queue.put(integer)
      print '%d put to queue by %s' % (integer, self.name)
      time.sleep(1)

Next is our consumer class. The thread gets the integer from the 
queue and indicates that it is done working on it using task_done().

class Consumer(threading.Thread):
  """
  Consumes random integers from a list
  """

  def __init__(self, queue):
    """
    Constructor.

    @param integers list of integers
    @param queue queue synchronization object
    """
    threading.Thread.__init__(self)
    self.queue = queue

  def run(self):
    """
    Thread run method. Consumes integers from list
    """
    while True:
      integer = self.queue.get()
      print '%d popped from list by %s' % (integer, self.name)
      self.queue.task_done()

Here is the output of the program.
$ python queue.py
61 put to queue by Thread-1
61 popped from list by Thread-2
6 put to queue by Thread-1
6 popped from list by Thread-2
The Queue module takes care of locking for us which is a great advantage. It is interesting to look at the Python internals to understand how the locking mechanism works underneath.
The Queue constructor creates a lock to protect the queue when an element is added or removed. Some conditions objects are created to notify events like the queue is not empty (get() call stops blocking), queue is not full (put() call stops blocking) and all items have been processed (join() call stops blocking).

class Queue:
    def __init__(self, maxsize=0):
        ...
        self.mutex = threading.Lock()
        self.not_empty = threading.Condition(self.mutex)
        self.not_full = threading.Condition(self.mutex)
        self.all_tasks_done = threading.Condition(self.mutex)
        self.unfinished_tasks = 0

The put() method adds an item or waits if the queue is full. It 
notifies the threads blocked on get() that the queue is not empty. See 
above for an explanation on the Condition object for more details.

def put(self, item, block=True, timeout=None):
    ...
    self.not_full.acquire()
    try:
        if self.maxsize > 0:
            ...
            elif timeout is None:
                while self._qsize() == self.maxsize:
                    self.not_full.wait()
        self._put(item)
        self.unfinished_tasks += 1
        self.not_empty.notify()
    finally:
        self.not_full.release()

The get() method removes an element from the queue or waits if the 
queue is empty. It notifies the threads blocked on put() that the queue 
is not full.

def get(self, block=True, timeout=None):
    ...
    self.not_empty.acquire()
    try:
        ...
        elif timeout is None:
            while not self._qsize():
                self.not_empty.wait()
        item = self._get()
        self.not_full.notify()
        return item
    finally:
        self.not_empty.release()

When the method task_done() is called, the number of unfinished tasks
 is decremented. If the counter is equal to 0 then the threads waiting 
on the queue join() method continue their execution.

def task_done(self):
    self.all_tasks_done.acquire()
    try:
        unfinished = self.unfinished_tasks - 1
        if unfinished <= 0:
            if unfinished < 0:
                raise ValueError('task_done() called too many times')
            self.all_tasks_done.notify_all()
        self.unfinished_tasks = unfinished
    finally:
        self.all_tasks_done.release()

def join(self):
    self.all_tasks_done.acquire()
    try:
        while self.unfinished_tasks:
            self.all_tasks_done.wait()
    finally:
        self.all_tasks_done.release()




 Fuente laurentluce.com

domingo, 6 de noviembre de 2011

Python Module of the Week || PyMOTH

Aprendiendo python tengo que googlear mucho, para encontrar una librería o un ejemplo que me dará pista, y una cosa muy util que encontre es PyMOTW.

Es un manual en pdf o html en cual van agregando explicaciones y ejemplos como funcionan librerías estándares de python.
Y los ejemplos que tiene son muy buenos.

Asi que os recomiendo ;)

PyMOTH 1.132 versión actual [version HTML]

PyMOTH 1.132 versión actual [version PDF]

Os recomiendo que os suscribiréis a RSS o por correo

Ahora mismo están traduciendo este manual a castellano.

OSSTMM - Manual de la Metodología Abierta de Testeo de Seguridad

La organización ISECOM, el Instituto para la Seguridad y las Metodologías Abiertas, acaba de publicar la versión en castellano de la metodología abierta para la verificación de la seguridad, la OSSTMM. Por otra parte, también se ha publicado una sección especial de esta metodología especializada para el análisis de redes inalámbricas.

El "Manual de la Metodología Abierta de Testeo (sic) de Seguridad" es un documento que reúne, de forma estandarizada y ordenada, las diversas verificaciones y pruebas que debe realizar un profesional de la seguridad informática durante el desarrollo de las auditorías y verificaciones de la seguridad. Es un documento en constante evolución, fruto del trabajo conjunto de más de 150 colaboradores de todo el mundo.

La participación directa de estos profesionales, que desarrollan su actividad profesional en el sector de la seguridad, en la confección de la metodología le permite incorporar los más recientes cambios y nuevas tendencias en el mundo de la seguridad informática.

OSSTMM - Manual de la Metodología Abierta de Testeo de Seguridad OSSTMM.es.2.1.pdf

Fuente: hispasec.com

Rastreo y penetración de sistemas con Nmap y hping2 [Teoria]

Las herramientas como Nmap y hping2 pueden automatizar el escaneo pero no son 100% fiables. Siempre debemos interpretar los resultados devueltos por los programas. Por esta razón debemos conocer en profundidad el proceso llevado a cabo en cada una de las técnicas empledas.

Las técnicas de escaneo pueden dividirse en dos grupos: Open scanning (escaneo abierto), Halfopen scanning (escaneo a medio abrir) y Stealth scanning (escaneo sigiloso). Esta división se hace en función del grado de conexión realizada contra la máquina destino y en función de las
características de los paquetes enviados. Conocer qué técnica es la más adecuada depende de la topología de la red, de si existe o no un IDS detrás, del grado de “logueo” del sistema.

El empleo de un escaneo de tipo Open scanning nos proporciona un nivel de fiabilidad muy levado y conveniente, pero hay que tener en cuenta que los logs dejados son altos y harían saltar a cualquier sistema IDS y el escaneo sería conocido. Por otra parte, si usamos Stealth scanning, podremos evitar determonados sistemas IDS y sobrepasar ciertas reglas de cortafuegos. Sin embargo, un inconveniente de esta técnica es que determinadas circunstancias, suele proveer de falsos positivos, por lo que deberemos saber cómo interpretar los resultados.

Full TCP Connection

Si deseamos una fiabilidad del 100% en los resultados devueltos, ésta es la técnica que debemos aprovechar, siempre teniendo en mente que es la que más rastros deja en el log del sistema remoto y la más sencilla de filtrar. Si no nos importa que nos detecten, ya sea porque se trata de un sistema al que estemos haciendo una auditoría, porque es un equipo de nuestra propiedad o cualquier otra razón, ésta técnica es la más efectiva y rápida.


Figura N°1 Full TCP Connection: Puerto Abierto

La técnica del Full TCP Connection implica abrir una conexión completa con el equipo remoto con el modo de conexión normal, conocido como three-way TCP/IP handshake29. En la figura 1 podemos ver el proceso llevado a cabo para crear y establecer la conexión. Se hace uso de los siguientes flags para crear y establecer la conexión: SYN, SYN/ACK, ACK.

Inicialmente la máquina origen (cliente) envía un paquete con el flag SYN activado a la máquina destino (servidor). El servidor responde con los flags SYN/ACK activados, lo que indica que el puerto al que nos hemos intentado conectar se encuentra abierto. Después de que el cliente envía el ACK de confirmación, se completa el Three-way TCP/IP handshake y la conexión es terminada por el cliente, volviendo a realizar el mismo proceso para el resto de los puertos que deseemos escanear.

En la figura dos podemos apreciar lo que sucedería si el puerto del servidor se encontrara cerrado.

Figura N°2 Full TCP Connection: Puerto Cerrado

Aquí, el servidor devuelve un RST/ACK. El servidor informa al cliente que debe terminar la conexión debido a que el puerto se encuentra cerrado. Ésta técnica es muy fácil de identificar, ya que al realizar una conexión completa, los logs del sistema y un IDS lo detectarían. Una vez detectado, un cortafuegos bloquearía el resto de las peticiones.

Half Open Scan Method

Éste método se llama Half open porque el cliente termina la conexión antes de que se haya completado el proceso de intercambio Three-way TCP/IP Handshake, por lo que pasará inadvertido a los IDS basados en conexión, aunque es muy probable que devuelva falsos positivos.


Figura N°3 Half Open Scan Method

SYN Scanning

Ésta técnica es exactamente igual al Full TCP conection, excepto que en el último paso el envío del ACK por parte de la máquina cliente no se lleva a cabo y en su lugar, el cliente termina la conexión mediante el envío de un RST. En realidad, es el sistema operativo quien se toma la tarea de enviar el RST. En la figura tres se esquematiza este tipo de escaneo.

Si en respuesta a nuestro SYN el servidor envía un SYN/ACK, nos está informando que el puerto está abierto. Si lo que envía es un RST/ACK, significa que el puerto está cerrado. Ésta técnica es muy fácil de identificar por un IDS, ya sea el Snort, TCPWrappers o IPLog. El hecho de que éste método haya sido utilizado para generar DoS (denial of service – Denegación de servicios que veremos más adelante en este documento) SYN Flood es un inconveniente ya que provocó que muchos cortafuegos tengan reglas específicas para prevenir este tipo de escaneos. Mediante ésta técnica podemos realizar rápidos escaneos que puedan pasar inadvertidos a los IDS débiles, pero la desventaja es que debe ser ejecutado con privilegios de administrador.

Stealth Scanning

Ésta técnica se denominó así debido a que permitía evitar los sistemas de detección y logeo de los IDS. Hoy día, este tipo de escaneo tiene que ver con algunas de las técnicas siguientes: uso de determinados flags, técnicas de sobrepasar filtros, cortafuegos, routers, casual network traffic, etc.

SYN/ACK Scanning

Ésta técnica tiene la característica de eliminar la primera parte del Three-way TCP/IP Handshake. Se envía el SYN/ACK y en función de la respuesta podremos saber el estado en que se encuentra el puerto. El servidor termina la conexión pensando que se ha producido algún tipo de fallo en las transacciones con este puerto, en el que no se ha producido un SYN previo.

En el caso de que el puerto se encontrase abierto, no recibiríamos ninguna respuesta por parte del servidor. Hay que saber leer con detenimiento este resultado, porque los falsos positivos en este tipo de escaneo son muy probables. La ausencia de respuesta puede deberse a algún tipo de filtrado, por ejemplo, de un cortafuegos de tipo stateless.

FIN Scanning

Desafortunadamente esta técnica se aprovecha de una mala implementación del código de los BSD, que han usado muchos sistemas operativos para construir su pila TCP/IP. En teoría, cuando se envía un paquete con el flag FIN activo, un puerto cerrado responderá con un RST, mientras que los puertos abiertos se quedarán “callados” (RFC 793, pp64). Véase la figura 4.


Figura N°4 FIN Scanning

En éste caso hay que mencionar que los sistemas de Microsoft han decidido ignorar completamente los estándares e implementar lo que a ellos les ha parecido mejor. De modo que ésta técnica, junto con XMAS scanning y Null scanning no son válidas para sistemas ejecutando Win95/NT.

Por otra parte podemos aprovechar esta característica para identificar si el sistema se trata de un Windows. Si mediante ésta técnica encontramos puertos abiertos, sabremos que no se trata de un sistema Windows, pero si no encontramos ningún puerto abierto y por medio de un SYN scanning sí encontramos puertos abiertos, entonces sabremos que se trata de un sistema Windows. Existen otros sistemas que responden con un RST cuando el puerto está abierto, en vez de desechar el paquete (que es lo que el estándar dispone que debe hacerse). Algunos de estos sistemas son Cisco, Solaris, BSDI, MVS e IRIX.

Ésta técnica también nos devuelve falsos positivos por lo que debemos interpretar los resultados.
Cualquier sistema de filtrado puede estar bloqueando los RST de los puertos cerrados. Como resultado obtendríamos un escaneo erróneo y deberemos aplicar otras técnicas o bien, comparar los resultados obtenidos mediante esta técnica con los que obtenemos con otras diferentes como los escaneos SYN o SYN/ACK.

ACK Scanning

Éste método, utilizando el programa Nmap con la opción -sA, se usa generalmente para poder averiguar las reglas de filtrado de los cortafuegos. Concretamente nos permite indagar si el cortafuegos es stateful o sencillamente un sistema de filtrado simple que bloquea los paquetes SYN entrantes.

En ésta técnica enviamos un paquete ACK con un ID de secuencia aleatoria al puerto especificado. Cuando recibimos paquetes con flags RST activados los puertos son clasificados como “no filtrados”, mientras que si no recibimos ninguna respuesta o se nos envía un ICMP Unreachable, se clasificarán los puertos como “filtrados”. Una característica del Nmap y de este tipo de filtrado reside en que los puertos que deberían aparecer como “no filtrados” no aparecen. Sólo obtendremos aquellos puertos que que hemos detectado como “filtrados”. Otra técnica empleando el envío de ACK fue descrita utilizando un bug30 (error en software o hardware) que existía en la capa IP de los sistemas operativos. Mediante el envío de ACK, teníamos dos técnicas para detectar el estado de los puertos atacados. El primer método implica evaluar el campo TTL (Time To Live) del paquete, mientras que en el segundo debemos analizar el campo WINDOW de éste. En ambos es imperativo analizar los paquetes que recibamos con el flag RST activado.

En el primer caso, un análisis de la cabecera IP de los paquetes, para determinados sistemas operativos, nos descubre que el valor de TTL de los paquetes que nos retorna un puerto abierto es menor que el del TTL que se obtiene como respuesta de puertos cerrados.

Esto se explica mejor con el ejemplo siguiente: esto es en backtrack
Packet 1: host XXX.XXX.XXX.XXX port 20:1RST -> ttl: 70 win:0 => closed
Packet 2: host XXX.XXX.XXX.XXX port 21:1RST -> ttl: 70 win:0 => closed
Packet 3: host XXX.XXX.XXX.XXX port 22:1RST -> ttl: 40 win:0 => open
Packet 4: host XXX.XXX.XXX.XXX port 23:1RST -> ttl: 70 win:0 => closed

Vemos en el paquete de respuesta del puerto 22, el valor TTL es menor que en los puertos que se hallan cerrados.

Éste es dependiente del sistema operativo de la versión de éste, ya que en versiones recientes este bug ha sido parchado y no puede emplearse como método de detección de puertos abiertos o cerrados.

NULL Scanning

En éste método dejamos inactivos todos los flags del paquete (ACK, FIN, RST, URG, SYN, PSH).

Cuando un paquete de ésta clase llega a un servidor, si el puerto se encuentra cerrado se enerará un RST por parte del servidor. Sin embargo, si el puerto se encuentra abierto, éste desechará el paquete y no responderá de ninguna manera. Esta forma de escaneo queda esquematizado en la figura 5.

Los estándares RFC no marcan ninguna clase de respuesta especifica con respecto de este tipo de paquetes por lo que el escaneo es dependiente del sistema operativo que está siendo escudriñado, como siempre confrontando Window Vs. UNIX.


Figura N°5 NULL Scanning

XMAS Scanning

Ésta técnica es todo lo contrario a la anterior y no tiene nada que ver con la navidad. En éste método activamos todos los flags presentes en la cabecera TCP (ACK, FIN, RST, URG, SYN, PSH). Al igual que en los casos anteriores, ésta técnica es dependiente de que la pila TCP/IP del equipo remoto esté basada en el código BSD, por lo que se limita a sistemas UNIX.

En éste proceso, cuando el servidor recibe un paquete con estas características, si el puerto se encuentra abierto, el kernel desechará el paquete, mientras que responderá con un RST si el puerto se encuentra cerrado. Todo lo demás es igual al NULL scanning con respecto de la respuesta del servidor.

IDLE Scanning

Éste procedimiento fue publicado en Bugtraq hace ya algunos años. Es la técnica más interesante y de gran utilidad. Hay que tener dos cosas en mente: siempre se debe efectuar de manera adecuada y tenemos que conocer la forma de interpretar los resultados que se obtienen. El método nos permite escanear una máquina remota utilizando paquetes “spoofeados” (es decir, con una dirección IP diferente de la nuestra) y una máquina zombie, que una computadora que se emplea como intermediaria para realizar ataques a una computadora víctima sin que ella tenga conciencia del procedimiento.

La idea es que nuestra computadora no pueda ser detectada desde la máquina atacada. En el IDLE scanning se usa una zombie para cuestiones de escaneo en nuestra red local propia. Para llevar a cabo este escaneo se aprovechara uno de los puntos débiles que se han descubierto al TCP/IP: números de secuencia IPID predecibles.

Los aspectos de TCP/IP básicos a tener en cuenta para llevar a cabo éste escaneo son los siguientes:

1. Una máquina responde con un SYN/ACK a un SYN si el puerto se encuentra abierto.
2. Una máquina responde con un RST a un SYN si el puerto se encuentra cerrado.
3. Una máquina responde con un RST a un SYN/ACK.
4. Una máquina no responde con nada a un RST.
5. Podemos conocer el número de paquetes que la máquina remota está enviando mediante el
campo IDIP de la cabecera IP.

Para explicar éste procedimiento, chequemos la figura 6.

Figura N°6 IDLE Scanning : Paso 1
En el paso uno debemos encontrar una máquina que no tenga mucho tráfico y en la que podamos controlar las variaciones de la secuencia IPID. Para ello podemos utilizar la herramienta Hping2 y comprobar la variación de este valor.

Shell-console
hping2 -i u1000 -p 80 -r -S -A zombie

shell-console
HPING zombie (eth0 zombie): S set, 40 headers + 0 data bytes
60 bytes from zombie: flags=RA seq=0 ttl=64 id=41660 win=0 time=1.2ms
60 bytes from zombie: flags=RA seq=1 ttl=64 id=+1 win=0 time=75ms
60 bytes from zombie: flags=RA seq=2 ttl=64 id=+1 win=0 time=91ms
60 bytes from zombie: flags=RA seq=3 ttl=64 id=+1 win=0 time=90ms
60 bytes from zombie: flags=RA seq=4 ttl=64 id=+1 win=0 time=91ms
60 bytes from zombie: flags=RA seq=5 ttl=64 id=+1 win=0 time=87ms

Con la opción -r obtenemos el valor relativo del campo id, es decir, la diferencia entre el id anterior y el nuevo id. Mediante esta variación podemos conocer si la máquina está enviando mucho o poco tráfico. Éste será el valor que nosotros utilizaremos para realizar el escaneo.

En el siguiente paso, una vez conocido el id de la respuesta al SYN que hemos enviado, será enviar un SYN a la máquina destino, pero con la IP spoofeada a la máquina zombie. Tecleamos:

Shell-console
hping2 -i -u1000 -p 22 -S -a zombie www.xxx.yyy.zzz


Figura N°6 IDLE Scanning : Paso 2

Enviamos a la máquina destino paquetes SYN diciendo que somos la máquina zombie. Si el puerto estuviese abierto en la máquina destino, ésta respondería al zombie con un SYN/ACK. El zombie, al recibir un SYN/ACK que no se corresponde con un SYN previo, envía un RST. De ésta forma, al enviar paquetes el zombie, el número de secuencia aumenta. Si el puerto estuviese cerrado, la máquina destino enviaría un RST al zombie. Al tratarse de un RST, la máquina no responde de ninguna forma y desecha el paquete.

En el paso 3, y último, se comprueba si el id de la máquina zombie se ha modificado o no. Como cualquier máquina genera suficiente tráfico como para que éste valor varíe frecuentemente, en vez mde tener en cuenta si el valor id ha variado en una o dos unidades, como se representa en la figura 6 paso 1 y 2, lo que haremos es lanzar dos procesos: uno que envía SYN/ACK a la máquina zombie (para controlar la variación del campo id) y otro que enviará los SYN spoofeados a la máquina destino. De esta forma podremos comprobar en tiempo real si al lanzar el segundo proceso (paquetes spoofeados, el valor del id devuelto por la máquina zombie varía o permanece dentro de unos límites).

Figura N°6 IDLE Scanning : Paso 3

Una buena opción para asegurarnos de que esta variación es consecuencia de nuestro envío de paquetes, es enviar una gran cantidad de paquetes, de esta manera, si vemos el valor del id presentará saltos en la misma proporción que el número de paquetes enviado por segundo. Para hacer pruebas es sugerible que se lancen los siguientes procesos en dos terminales diferentes. Debemos adecuar los puertos según la intención del escaneo:

Terminal 1
Shell-console
hping2 -i -u10 -p 80 -r -S -A zombie

www.xxx.yyy.zzz

Terminal 2
Shell-console
hping2 -i -u10 -p 22 -S -A zombie

Con el parámetro -i controlamos el tiempo de espera entre el envío de cada paquete. En este caso, enviamos un paquete cada 10 microsegundos. Como el tráfico generado va a ser muy abundante, si el puerto 22 de la máquina www.xxx.yyy.zzz se encuentra abierto, enviará el mismo número de paquetes SYN/ACK a la máquina zombie, que responderá con el mismo número de paquetes RST, produciéndose un incremento en el valor del campo id que será fácilmente apreciable. 

Fuente: taringa.net

Identificación remota del sistema operativo de un servidor (Fingerprinting) [Practico]

En la actualidad, existen multitud de Sistemas Operativos diferentes (Windows, HP-UX, Linux, Solaris, etc.) y cada uno tiene sus propias características que lo diferencian de los demás: distintas implementaciones de la pila TCP/IP, diferentes comportamientos ante el envío de según qué paquetes especialmente formados, distintas respuestas en función del protocolo utilizado (TCP, ICMP, ARP), etc.

Al realizar una revisión de seguridad, auditoría o test de intrusión, es importante, antes de empezar a enumerar qué servicios hay activos, reconocer el Sistema Operativo del servidor remoto que se está analizando ya que el procedimiento, las herramientas y las técnicas a emplear son diferentes. Esto es lo que se conoce como Fingerprinting de Sistemas.

El Fingerprinting de Sistemas es la técnica que usan la mayoría de analizadores de puertos avanzados (como Nmap) para intentar descubrir el Sistema Operativo de un servidor remoto. Está identificación se basa en los tiempos de respuesta a los diferentes paquetes ACK y SYN al establecer una conexión en el protocolo TCP/IP.

Básicamente, existen dos formas principales de intentar descubrir el Sistema Operativo presente en un host remoto: forma activa y/o pasiva y existen cantidad de herramientas que, usando cualquiera de los dos métodos, permiten realizar el fingerprinting remoto tales como Nmap, Xprobe, el antiguo QueSO, P0f o incluso la más moderna SinFP. Las técnicas tradicionales de reconocimiento de Sistemas mediante la captura del banner de algún servicio activo tipo TELNET, FTP, etc. que proporcionan información acerca del Sistema Operativo son limitadas y obsoletas y están prácticamente en desuso debido a la facilidad para modificar el banner de servicio y ofuscar, de esta manera, la identificación del Sistema Operativo presente en el servidor.
Además, existe un método alternativo de descubrir qué sistema está presente en la mayoría de servidores remotos importantes presentes en Internet, sin hacer ningún tipo de ruido ni ninguna prueba complicada que es utilizar NETCRAFT (http://www.netcraft.com). NETCRAFT, compañía dedicada, básicamente, a realizar estadísticas del uso de software en Internet, dispone de un servicio Web en el que con, simplemente, introducir el nombre del servidor a analizar, en breves segundos proporciona la información acerca del servidor Web, el Sistema Operativo, etc.

En el presente documento se va a realizar un estudio de las principales técnicas de Fingerprinting activo, cómo combinarlas y cómo conseguir determinar con un alto grado de exactitud el Sistema Operativo de un servidor así como también se van a enumerar las principales herramientas utilizadas en la actualidad.

REFERENCIAS:


 
Fuente: hacktimes.com

Tcptraceroute, una manera de hacer traceroute de ruta con los cortafuegos en el medio del camino

Introducción

Hoy quiero mostrarles una verdadera herramienta de buena administración de la red, si haces administración de red, usted debe usar ping y traceroute para comprobar cada vez que un host está vivo o no.
 
Tal vez los pasos de la prueba es el primero el ping al servidor, y si no hay respuesta, se intenta con traceroute para ver en qué parte del recorrido existe una interrupción.
Traceroute funciona el envío de paquetes ICMP a todos los routers en el camino hacia el host de destino, pero en estos días routers más y más y el servidor tienen los paquetes ICMP filtrado, por lo que aquí es donde tcptraceroute viene a salvar el día.
Como se puede adivinar por su nombre tcptraceroute es como traceroute, pero envía paquetes TCP en lugar de paquetes ICMP evitando el filtrado de los paquetes en la ruta.
 

Instalación

 

Debian / Ubuntu
apt-get install tcptraceroute
Fedora / CentOS
Asegúrese de tener Dag Wieers depósito habilitado y luego ejecutar:
yum tcptraceroute instalar
 

Uso

 

tcptraceroute [nNFSAE-] [-i interface] [-f primera ttl] [-l longitud] [-q número de consultas] [-t tos] [-m max ttl] [-p puerto de origen] [-s dirección de origen ] [-w tiempo de espera] host [puerto de destino] [largo]
 

Ejemplos

 

tcptraceroute www.tu_dominio.com
Esto va a enviar los paquetes al puerto TCP 80 y le mostrará la ruta para llegar a www.tu_dominio.com

Fuente  go2linux