Flags del Kernel para Firewall o Tuneando el /proc

Opciones de Seguridad en el kernel de Linux (proc)

 

IpTables es la herramienta en espacio de usuario, que permite establecer filtros con NetFilter, el cual es parte del kernel de Linux. Pero independientemente de las herramientas en espacio de usuario, existe una forma de indicar al kernel, como manejar ciertas cosas. Esta forma es, a saber, mediente variables del kernel que pueden modificarse desde el directorio /proc.

/proc

No tengo que detenerme mucho sobre le directorio /proc, ya que basta googlear para encontrar información sobre este pseudo sistema de ficheros. Solo hay que decir que mediante el proc podemos acceder a información del kernel, y modificar “on the fly” ciertas configuraciones.

Por ejemplo en /proc/sys/kernel/hostname encontramos el hostname de nuestro linux, y lo cambiamos haciendo

echo otroHostname > /proc/sys/kernel/hostname

De esta misma manera, podremos cambiar “a mano” ciertos valores del funcionamiento del kernel, y consecuentemente, el comportamiento del networking del mismo. Sin embargo, existe una manera mas “prolija”: sysctl

Sysctl, nos permite configurar las mismas variables (ver mas abajo) que esten configuradas en el /proc/sys , de forma centralizada en el archivo /etc/sysctl.conf. Siendo su sintaxis muy simple:

clave.a.configurar = valor

Para no ahondar mucho sobre el tema, simplemente hagamos un breve repaso y vayamos a lo importante

Breve repaso:

 

sysctl -a # muestra todas las variables configurada
sysctl -w kernel.hostname=MyHaxorName # asigna "MyHaxorName" como hostname del sistema
sysctl kernel.hostname # muestra el valor asignado a la variable
echo "kernel.hostname = MyHaxorName" >> /etc/sysctl.conf # cada vez que se inicie el sistema, sysctl configurará
las variables como se encuentran en este archivo 

A continuación, una lista de las variables mas importantes a tener en cuenta para la seguridad de nuestro firewall

Filtro anti-spoof

/proc/sys/net/ipv4/conf/eth0/rp_filter

En /proc/sys/net/ipv4/conf tenemos una carpeta por cada interfaz de red (eth0, lo, wlan0.. etc, además de las carpetas default y all). En cada una de ellas, encontramos archivos que configuran comportamiento especifico de cada interfaz, en el caso de rp_filter, es un filtro anti spoof: solo permite que la respuesta a un paquete sea enviada por la misma interfaz por la cual se recibió el paquete.

Habilitamos con 1, deshabilitamos con 0.

Ignorar pings

/proc/sys/net/ipv4/icmp_echo_ignore_all

Bastante conocido, con un 1 en este archivo, ignoramos todos los paqutes ICMP tipo echo, es decir, los pings.

El no responder pings, permite que pasemos desapercibidos en algunos escaneos simples, pero también nos bloquea la posibilidad de hacer pruebas de pings.

Syn Cookies

/proc/sys/net/ipv4/tcp_syncookies

El ataque syncooky conciste en enviar muchos paquetes TCP con el flag SYN activado,  pero no completa el HandShake, por lo que ocupa memoria en conexiones que quedan a la espera, causando un DoS. Colocando un 1 en este archivo, le pedimos al kernel, que no abra un buffer hasta que la conexión este abierta.

Paquetes Marcianos

/proc/sys/net/ipv4/conf/all/log_martians

Envia señales a syslog cuando entran paquetes de redes ilegales (cuando el kernel no sabe como rutearlas).

Paquetes Icmp Redirect

/proc/sys/net/ipv4/conf/all/accept_redirects

Un paquete ICMP Redirect, informa cuando hemos mandado un paquete a travez de una ruta que no es la optima.

Un ejemplo casero, es cuando tenemos ROUTER1 conectado a internet y a la LAN, en la cual existen 2 pc (PC1 y PC2), la configuración normal seria configurar a PC1 y PC2 con Default Gatewat en ROUTER1. Si cometieramos la tontera configurar PC2 con su default gateway en PC1 (teniendo por Default Gateway a ROUTER1 en esta pc) PC1 nos informaria que hay una ruta mas directa, y es atravez de ROUTER1. Esa funcion de anunciar esa ruta la cumple los paquetes ICMP Redirect. Con este tipo de paquetes, “alguien” podría realizarte un MITM.

ICMP Send_Reditect

/proc/sys/net/ipv4/conf/all/send_redirects

La explicación de esta variable esta explicada en Paquetes ICMP Redirect, pero en este caso, implica no enviar dichos paquetes ICMP.

Si tu linux no actua como ruter, en una red con varios routers, lo mas aconsejable es deshabilitarlo, poniendo un 0.

Ip Connection Tracking

/proc/sys/net/ipv4/ip_conntrack_max ó

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

En este archivo podemos colocar un numero, el cual será la cantidad máxima de conexiones IP que el kernel puede manejar. Este numero suele estar fijado segun la cantidad de memoria ram que poseamos. Esto puede ser un punto clave a la hora de lidiar con DoS. Asi mismo, podemos encontrar unos cuantos archivos similares, pero más especificos, haciendo ls /proc/sys/net/ipv4/netfilter/ip_conntrack*, los nombres de cada uno dan una idea de funcionalidad, y si conoces bien el funcionamiento del protocolo IP podrás retocar estos valores.

Source Route

/proc/sys/net/ipv4/conf/all/accept_source_route

Cuando internet nacio, inocentemente creia que todos serían buenas personas, por lo que sus protocolos, permitian a cualquiera obtener mucha información, en este caso, Ipv4,  permite que solicitemos a un determinado host, una ruta especifica por donde enviar paquetes, pudiendo ser utilizada esta información para conocer las “Relaciones de Confianza” entre routers. Fuera de eso, hoy en dia no se usa. Lo deshabilitamos con un 0

ICMP Broadcasting  (protección smurf)

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

ICMP tiene la facultad de poder enviar paquetes Broadcast, es decir, enviar un paquete, el cual todos los hots reconoceran como enviados hacia si mismos, ya que el destino de dicho paquete es una dirección de broadcast. Al recibir este paquete, el host actua en consecuencia y lo responde. Si todo funcionara como corresponde, no habria problema con esta funcionalidad… pero si “alguien” decide enviar paquetes ICMP Broadcast a una gran lista de IPs con un “source” spoofeado, todos los IPs de la lista enviarian una respuesta a la IP inocente (la spoofeada), causandole probablemente un DoS. Para evitar que nos usen como “reflector” enviandonos paquetes broadcast, ignoramos dichos paquetes colocando un 1 en este archivo.

ICMP Dead Error Messages

/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

El RFC 1122, nos pide que los paquetes ICMP erroneos sean completamente descartados silenciosamente, para no probocar tormentas de broadcast.  Para cumplir con dicho requerimiento, colocamos un 1 en dicho archivo.

IP Forward

/proc/sys/net/ipv4/ip_forward

Conocida por todos, esta variable, habilita o deshabilita el reenvio de paquetes. En los casos donde nuestro linux haga NAT, debe estar habilitada, en caso contrario, es recomendable deshabilitarlo.

TCP FIN TimeOut

/proc/sys/net/ipv4/tcp_fin_timeout

Tiempo en segundos que esperaremos antes de descartar una conexión parcialmente cerrada, por defecto 60 segundos, ya que así lo pide el RFC correspondiente a TCP, pero si queremos podemos disminuirlo a fin de evitar algún DoS.

TCP KeepAlive Time

/proc/sys/net/ipv4/tcp_keepalive_time

Cantidad de segundos que esperará el kernel, antes de enviar un paquete para mantener abierta la conexión, a pesar de que no esta siendo utilizada momentaneamente. Por defecto el valor es 7200 (2 horas),  pudiendo ser reducido en algunos casos a 1 hora o 1/2 hora, en segundos 3600 o 1800.

Proxy Arp

/proc/sys/net/ipv4/conf/all/proxy_arp

Con un 0 podemos deshabilitar esta funcionalidad, que no suele ser necesaria, a menos que seamos servidor de VPN, Firewall o Router que lo requiera.

Cache ARP

/proc/sys/net/ipv4/neigh/[interfaz de red]/gc_stale_time

Los segundos que configuremos en esta variable, definiran el tiempo en que se actualiza el cache ARP. Dicho cache, es el que se envenena cuando se realiza un ARP Poisoning Attack, por lo que cuanto mas bajo sea, mas vulnerable a este ataque, pero al mismo tiempo,  mas rapido sabremos cuando una IP quedo fuera de servicio o una MAC cambio de IP (arp -n para verificar las entradas del cache y su estado)

Escalado de Ventana

/proc/sys/net/ipv4/tcp_window_scaling

Dicha variable, habilita (con un 1) o deshabilita (con un 0) la posibilidad de que la conexión TCP negocie el tamaño de la ventana. Dependiendo del segmento de la red y la topologia de la misma, suele ser conveniente que esté habilitada, sin embargo, nos expone a ciertos escaneos (nmap windows scaling) y a posibles DoS.

Algoritmo SACK

/proc/sys/net/ipv4/tcp_sack

SACK es un algoritmo para detectar perdidas de paquetes. Si habilitamos dicha opción (colocando un 1) siempre y cuando pueda, TCP lo utilizará, en caso contrario, ignorará dicha opción. Es recomendable habilitar dicha opción, ecepto que nuestras conexiones TCP las hagamos en un ambito sin demasiadas perdidas de paquetes.

Rango de Puertos Locales

/proc/sys/net/ipv4/ip_local_port_range

En este archivo no colocaremos ni un 1 ni un 0, si no que colocaremos de números, que definiran un rango de puertos, el cual será utilizado para puertos locales, es decir, puertos desde donde comenzaremos conexiones hacia el exterior. En general el rago es 1024 a 4999, pero es conveniente ejecutar:

#echo "32768 61000" > /proc/sys/net/ipv4/ip_local_port_range

en sistemas donde se usen los puertos 1024 a 4999 para brindar servicios.

TTL de nuestros paquetes

/proc/sys/net/ipv4/ip_default_ttl

TTL es Time To Live, o bien, el tiempo de vida que le otorgaremos a los paquetes generados por nuestro host. Este “tiempo” no se cuenta en segundos, sino en cantidad de routers que puede atravesar antes de ser descartado (morir). Es asi que cada router, descuenta uno a dicho valor.

Llegar de sudamerica a china nos cuesta de 12 a 20 saltos, por lo que un paquete que tenga mas de 30 saltos es un tanto raro. El valor mas recomendado en general es 64 (traceroute y a sacarnos las dudas)

Explicit Congestion Notification

/proc/sys/net/ipv4/tcp_ecn

Como lo recita su nombre, ECN es una opción de TCP que permitenotificar cuando un host esta congestionado, para que se busque otra ruta. Algunos firewalls o routers pueden llegar a filtrar los paquetes que tengan esta opción habilitada, pero son los menos. Habilitamos con un 1, que sería lo mas recomendable.

Conclusión:

A la hora de armar un Firewall para nuestro linux, no es cuestión de ejecutar cualquier script a fin, si no conocer bien que es lo que necesitamos, para que y como. El conocer estas variables nos permite conocer donde debemos tocar en caso de ser necesario.

Usando plugins y themes para hackearte

A modo de troyano, CryptoPHP infecta tu CMS (wordpress, joombla, Drupal) con un sospechoso pero poco visible:

<?php include('assets/images/social.png'); ?>

Siendo social.png no una imagen si no un PHP ofuscado.
CryptoPHP fue lanzado en su primera versión (0.1) el 25 Sep de 2013, y el 12 de Noviembre de este año vio la luz la versión 1.0a y según las evidencias el autor ha de estar en Modova.
La info completa de este threat pueden leerla en el siguiente paper liberado por Fox-IT.

~have fun

Sentimentalismo de la #Eko10 episodio 2 (o generación del 80-90)

En el panel de comienzo de la #eko10, se hablo de como comenzo todo (el hacking en Argnetina), una charla bastante sentimental, sobre las primeras experiencias de quienes hoy son referentes en la seguridad infromática en argentina. Ahora bien, no soy de la misma generación, yo no me conecte nunca a una BBS, ni leí virus report. Pero soy de una generación (calculo yo, no seré el único) que leía la EKO y HBO magazines en txt (algunas bajadas de zinestore), que aún compilaba kernels, que uso el NetBUS, el Sub7, que jugaba al AgeOfEmpires, que instalo el “Caldera Linux” y leyó el libro de Facundo Arena de Linux Avanzado (con cd slackware 7!) y las primeras 3 ediciones de USER Linux (antes del relanzamiento), y de los que maldijeron los “winmodems”.

Los recuerdos son muchos, y similares a los que se presentaron en ese panel. Para ambos el inframundo era mas inocente, para ambos la cuenta de teléfono fue un problema. Ellos abrieron un camino,  nosotros lo continuamos y abrimos los propios.  El hacking no sólo se trata de lo que suele suponerse, si no de descubrir nuevos caminos, cada uno a su manera y en lo que le gusta.

En fin, además del sentimentalismo y la nostalgia, esta edición de la EKO me dejó un par de conocidos muy interesantes. Si no fuiste te animo a que pienses en hacerlo la próxima edición, no solo se trata de seguridad informática, si no de un lugar de encuentro para SysAdmins, Frikis, Hackers, Developers, y todo tipo de Nerds/Informáticos jugando a abrir candados, capturar paquetes wifi, pegandolé al muñeco de SysARmy, etc etc.

IPtables AutoCompletion

Una de mis herramientas favoritas es iptables. Si bien no me es muy difícil armar las lineas de memoria, muchas personas tienen problemas con iptables justamente por no recordar los parámetros posibles. Por eso quiero compartirles esta útil herramienta.

iptables-bash_completion-1.3.tar

Al descomprimirlo obtendremos el archivo “iptables-bash_completion”. Basta con copiarlo en /etc/bash_completion.d/ y de ahí en mas la tecla TAB hará su trabajo.

Sencillo pero muy útil.

~have fun

Seguridad en archivos

Proteger tus archivos en GNU/Linux puede es la roca fundamental de la seguridad

Los Firewalls, rootkit hunters, IDS, Itrusion prevention systems, etc etc no sirve si el administrador del sistema no sabe lo que esta haciendo. Una de las tareas mas importantes en la seguridad que el administrador debe conocer, es controlar la seguridad en nuestros sistemas de archivos.

En este post haremos un repaso de las medidas de seguridad disponibles en GNU/Linux, a la hora de cuidar nuestros archivos:

UGO

Heredado de Unix, los sistemas de archivos en linux, tienen una lista de control de acceso. Esta lista, enumera a tres sujetos. El usuario (el dueño del archivo), el grupo (grupo dueño del archivo) y otros (es decir, todos los que no son ni dueños ni pertenecientes al grupo dueño del archivo. Cada uno de estos sujetos puede tener permiso para, leer (r de read), escribir (w de write) y ejecución (x de eXecution).  Todo esto ya lo sabemos y si no, la wikipedia puede ser una ayuda.

Hay algunas peculiaridades que debes conocer de este sistema:

Falsa restricción de lectura en carpeta

Si una carpeta no tiene permiso de lectura (r), no podrás listar su contenido (hacer un ls), pero si conoces de la existencia de un archivo dentro de ella, podrás listarlo y leerlo (si tienes permisos sobre el mismo).
Ejemplo:

# ls -ld  test
drwxr-xr-x 1 user group 0 sep 1 12:00 test
# ls -l test/
-rwxr-xr-x 1 user group 0 sep 1 12:00 file
# chmod u-r test
# ls -l test/
ls: no se puede acceder a test: No existe el fichero o el directorio
# ls -l test/file
-rwxr-xr-x 1 user group 0 sep 1 12:00 file

Para evitar esto, la correcta manera de denegar el acceso a una carpeta, es quitando el permiso de ejecución (x):

# ls -ld  test
drwxr-xr-x 1 user group 0 sep 1 12:00 test
# chmod u-x test
# ls -l test/
-????????? ? ? ? ? ? file

De esta manera, si bien podríamos listar los archivos contenidos en la carpeta, no podríamos acceder a ellos, ni a las carpetas que estén dentro.

Falsa restricción de ejecución de scripts

Si queremos que un script no se ejecutable por ciertas personas, debemos tener mucho cuidado. Solamente quitar el permiso de ejecución no siempre sirve ya que si otro usuario tiene permiso de lectura del script puede copiarlo y ejecutarlo. Otra forma de hacer esto mismo es ejecutandoló como “source”

# ls -l script.sh
-rwxr--r-- 1 user group 0 sep 1 12:00 script.sh
# chmod -x script.sh
# . script.sh 

Con un . o bien con el comando source, podemos ejecutar el script como si estuviéramos tirando los comandos directamente desde la consola.

El comando perdido

Pocos conocen le uso del comando ‘newgrp’.  Este comando nos permite cambiar nuestro grupo por defecto momentáneamente. Veamos un ejemplo:

# id user
uid=10000(user) gid=10000(group) groups=10000(group),11000(oracle)
# newgrp oracle
# touch newfile
# ls -l newfile
-rwxr--r-- 1 user oracle 0 sep 1 12:00 newfile

Como verán, el archivo newfile fué escrito con el grupo oracle. Para terminar este switch momentaneo podemos ejecutar exit, ya que newgrp en realidad ha abierto una nueva shell, donde nuestro grupo por defecto es oracle.

Bits especiales

Aunque conocidos, no siempre son bien comprendidos.  El sistema de control de lista de acceso a los archivos tiene unas exenciones llamadas SUID, SGID y Sticky Bit. Los tres bit especiales son mostrados (cuando estan activados) en lugar de la x de ejecución.

El SUID, es un bit que permita que un binario o script, sea ejecutable con los permisos del dueño (user) de dicho archivo (effective user id). Es decir:

#ls -l script.sh
-rwsr-xr-- 1 user group 0 sep 1 12:00 script.sh

Si alguien del grupo group ejecuta dicho script, lo hará con los permisos del usuario (user)  y no con sus permisos.
Esto requiere especial atención dadas sus implicaciones!
El SGID, es igual que el SUID, pero aplicado al grupo.

Y finalmente el Stiky bit, se utiliza hoy en dia, solo para directorios. La wikipedia reza:

Cuando se le asigna a un directorio, significa que los elementos que hay en ese directorio sólo pueden ser renombrados o borrados por el propietario del elemento, el propietario del directorio o el usuario root, aunque el resto de usuarios tenga permisos de escritura y, por tanto, puedan modificar el contenido de esos elementos.

El sticky bit está a menudo configurado para el directorio /tmp.

Estos bits, son un parche, a las limitaciones del sistema de control de acceso, y se complementan con los atributos extendidos que veremos a continuación.

Extended Attributes

Los atributos extendidos es una característica soportada por la mayoría de los sistemas de archivos (tanto en linux, como en los unix, y en windows). Por supuesto, cada cual tiene su propia implementación. En este caso, veremos la implementación de ext2,3 y 4 dado que son los sistemas de archivos mas comunes en GNU/Linux.

Estos atributos extendidos nos permiten añadir peculiaridades al comportamiento de acceso a los archivos.  Veamos cuales son:

  • a : append only 
  • c : compressed
  • d : no dump
  • e : extent format
  • i : immutable
  • j : data journalling
  • s : secure deletion
  • t : no tail-merging
  • u : undeletable
  • A : no atime updates
  • C : no copy on write
  • D : synchronous directory updates
  • S : synchronous updates
  • T : top of directory hierarchy

He señalado sólo dos que están mas relacionados con la seguridad. Los otros, o bien no tienen relevancia en la seguridad, o bien no están realmente implementados.  Cada atributo tiene su explicación y uso, y para mas info les recomiendo este link.

El atributo de Append Only, sirve, por ejemplo, para archivos de logs, a los que se les agrega continuamente información. Adicionalmente no estamos interesados en que sean borrados. Para esto podemos utilizar este atributo, de la siguiente manera:

# lsattr file
---------------- file
#chattr +a file
#lsattr file
-----a---------- file
#echo "more data" > file
bash: file: Operación no permitida
#echo "more data" >> file
#

Como verán, podemos agregar mas data, pero no sobre escribirla. Así mismo si utilizamos el atributo inmutable, el archivo no puede ser modificado en absoluto.
Estos atributos pueden ser asignados sólo por el root, y quitados con el mismo comando chattr.
Si bien no son un garantía, son una barrera mas que ayudan a securizar cierta data.

ACL

El sistema UGO, tiene sus limitaciones, y ACL es la respuesta.
Por ejemplo, una limitación clásica del sistema UGO, es que no podemos dar distintos permisos a distintos usuarios, indistintamente del grupo al que pertenezcan. Esto, si se puede hacer con las ACL.
Para que nuestro sistema de archivos soporte esta característica, hay que montarlo con el flag “acl”, ya sea desde el comando mount o desde el fstab.

/dev/sdb1 /pendrive ext3 acl 1 2

ó

mount -o acl /dev/sdb1 /pendrive

En todo caso, al montar el sistema de archivos con soporte de acl, podemos configurar permisos avanzados (siempre utilizando la metodología de lista de control de acceso)
Archivos con ACLs
Cuando listamos archivos que tienen ACLs, los visualizaremos con un + al final de los permisos:

#ls -l script.sh
-rwxr-xr--+ 1 user group 0 sep 1 12:00 script.sh

Listar ACLs

Para conocer que ACLs tiene un archivo, utilizmos getfacl:

# getfacl script.sh
# file: script.sh
# owner: user
# group: group
user::rw-
user:john:rwx
group::r--
mask::rwx
other::r--

Como ven, en este caso, el usuario john, tiene permisos de lectura,escritura y ejecución.

Establecer ACLs
Finalmente, para establecer una ACL, utilizamos setfacl

# setfacl -m "u:john:r-x" script.sh

En este caso, quitamos el permiso de ejecución a john.
Para su uso mas extedido, te recomiendo leas la doco de RedHat

Conclusiones

Configurar correctamente nuestros archivos, es fundamental. Un bit de permisos mal configurados puede ser la ruina del servidor, por consiguiente de la red..
Aunque estos temas son muy básicos para los administradores avanzados, aveces se pierde de vista su importancia. Además de los sistemas repasados, existen medidas mas avanzadas, como por ejemplo, selinux, tripwire, encriptación LUKE, etc. Estas van mas allá de los sistemas de archivos, pero estan muy relacionadas. Las veremos mas adelante.

Antes de dormir hoy, no olvides revisar tu file sytems 😛

~have fun!

EFI Shell – Itanium – HP-UX/Linux

Que es y para que sirve? que podemos hacer con la EFI shell?

La EFI es la precursora de la UEFI, hoy en dia bastante difundida en equipos de uso hogareño. Pero este no es por lejos el tema que nos ocupa, si no mas bien la utilidad de la EFI Shell en servidores del tipo Itanium. Encontrarás en este post, el uso básico y algunos tips de utilidad a la hora de instalar o recuperar sistemas operativos.

Introducción

Si te primera pregunta es: Que es EFI?
La respuesta mas clara la tiene Wikipedia cuando dice:

La Interfaz Extensible del Firmware, Extensible Firmware Interface (EFI), es una especificación desarrollada por Intel dirigida a reemplazar la antigua interfaz del estándar IBM PC BIOS, interactúa como puente entre el sistema operativo y el firmware base.

Básicamente cuando HP decidió vender servidores con procesadores Intel, se comenzó a desarrollar un sistema que permita a los servidores tener altas prestaciones (esto fue cerca del 2002), por ejemplo soportar hasta 9,4 Zetta Bytes en lugar de los 10 Teras que podia llegar a soportar la BIOS en el mejor de los casos. Otro excelente ejemplo es la posibilidad de funcionar nativamente con 32 y 64 bits, cuando BIOS fue diseñada originalmente para andar con 16 bits.

AmiBios2
Server con iLO 2 Booteando con BIOS AMIBIOS

Ademas de estas y otras adelantos que conlleva el uso de la EFI, esta posee un Boot manager y una shell desde donde se pueden ejecutar ciertos programas prescindiendo de un OS.

En este post nos centraremos en esos beneficios, los commandos de EFI y el Boot Manager.

EFI Standard Commands

EFI tiene un set de comandos específicos, los cuales podemos observarlos utilizando el comando help -?. También pueden encontrar una lista completa de los comandos de la EFI en este link.

El funcionamiento de esta “shell” es muy al estilo DOS, aunque tiene un par de ayudas para los que venimos del mundo unix, y escribir ‘dir’ en lugar de ‘ls’ nos cuesta muchísimo.
La primer ayuda que tenemos es el comando ‘alias’, el cual nos mostrará los alias de los comandos y crear nuestros propios ‘comandos’.

La mayoria de las descripciones de los comandos en el comando help -? son muy explicativas, en caso de que necesitemos mas información sobre un comando en particular podemos ejecutar ‘help commando’ o bien ‘commando -?’.

Aquí les dejo algunos comandos básicos:

ver

Existen varias versiones de EFI, por lo que te recomiendo ejecutar el comando ver, para saber que versión de EFI estas usando. Una de las diferencias entre versión y versión es la lista de comando. Quizás alguno de los comandos que tratamos aquí no estén disponibles en tu EFI.

Hardware desde la EFI

A la hora de configurar el hardware del servidor, tenemos algunos comando muy útiles.

map

El comando map, nos muestra una lista de dispositivos reconocidos por la EFI.

Shell> map
Device mapping table
fs0 : Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig8E89981A-0B97-11D7-9C4C-AF87605217DA)
blk1: Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)
blk2: Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig8E89981A-0B97-11D7-9C4C-AF87605217DA)
blk3: Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part3,SigC9D7945C-0BA7-11D7-9B31-FBA1AECDAF7E)

Este listado, por supuesto varía de servidor en servidor, dependiendo de que dispositivos (discos, fibras, placas de red, etc etc)
Puedes encontrar aquí una explicación de la nomenclatura usada.

Si quisiéramos refrescar (escanear nuevamente) el listado

map -r

Si quisiéramos listar sólo los filesystems

map -Fs

Si quisiéramos listar sólo los dispositivos de bloque

map -Blk
devices
Este comando, nos hará un listado de todos los dispositivos administrados por la efi (es decir la efi tiene drivers para esos dispositivos). Este comando es muy útil para poder saber que hard tenemos en el servidor.
devtree
Complementario al comando devices, con devtree podemos hacer prácticamente el mismo listado, pero con vista de árbol.

Acceso a un disco/lun

Para acceder a un filesystem, ejecutamos (muy al estilo MS-DOS):

Shell> fs0
fs0:>

Una vez dentro del filesystem podemos hacer uso de los siguientes comandos:
cd, comp, cp, edit, eficompress, efidecompress, hexedit, ls, mkdir, mode, mv, rm

Detallar estos comandos sería un despilfarro de letras, ya que son lo que todos queremos que sean, sin mas ni menos. Sin embargo, estos mismos comandos son útiles para scripts que podemos realizar con el fin de acortar ciertas tareas (tema que quedará pendiente para un futuro post).

Termino dejando un manual de la UEFI en servers proliants

~have fun!

EFI Devices Mapping

Esta es una pequeña explicación de la nomenclatura utilizada por intel en la EFI Shell.

Un ejemplo, es cuando utilizamos el comando map, una de las entradas se vería algo así:

fs0 : Acpi(HWP0002,100)/Pci(1|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig8E89981A-0B97-11D7-9C4C-AF87605217DA)

Explicación:

Acpi(HWP0002,100):

  • Tipo de dispositivo HWP0002 (= Logical Block Address (LBA) device)
  • PCI número de host 100 (“ROPE“ = circuitry handling I/O for PCI; defines I/O card slot)

Pci(1|0):

  • device/slot número 1
  • función numero 0

Scsi(Pun0,Lun0):

  • Pun: Physical Unit (SCSI address)
  • Lun: Logical Unit

HD(PartX,SigY):

  • Partición X
  • Disco con código Y

Hacking desde Debian 7

Uso Debian, ni Ubuntu, ni Backtrak, ni Kali Linux, Debian. Y no es que sea caprichoso, solo es que mi laptop no solo es una herramienta de pentesting, si no tambíen mi herramienta de estudio, mi centro multimedia, me enviroment de programación, y mi herramienta de trabajo diario ademas de mi laboratorio de experimentos. Y es que Debian es “The universal operating system”.

En fin, sea por la razón que sea, en este post haré una lista de programas disponibles en el repositorio de Debian, que nos sirven para utilizar nuestra pc como herramienta de pentesting, preparando nos para la guerra!

El escenario es el siguiente:

Debian 7 Testing en amd64.
Repositorios con main, non-free y contrib (puritanos por favor no se peguen un tiro en la cabeza… o si.. )

Agregamos la arquitectura i386 usando:

dpkg --add-architecture i386

Básico

Una vez que tenemos nuestro sistema al dia, procederemos a la instalación de los paquetes básicos, que no son de pentesting en sí, si no de uso general, pero muy útiles para trabajar.

fluxbox
terminator
guake
tint2
vim
dia
keepassx
keepnote
gedit + gedit plugins

Packet crafting

A la hora de crear paquetes  tenemos varias opciones, dependiendo de la profundidad y el tipo de análisis que necesitemos:

yersinia
python-scapy
netexpect
netwox + netwag
hping3
netexpect
packeth
arping
irpas
macchanger

Sniffing

Para saber exactamente que es lo que pasa por nuestras redes, nada mejor que unos buenos sniffers

wireshark
tshark
dsniff
tcpdump

Scanning / Discovering

Una herramienta típica e infaltable, los scanners:

nmap + zenmap
pnscan
sslscan
sshscan
doscan
netdiscover
dnstracer
dnswalk
smb-nat
xprobe
p0f
cdpr

Brutefoce

Con inteligencia mas la fuerza bruta podemos llegar lejos

hydra + hydra-gtk  (xhydra)
medusa
john
aircrack-ng

Web

Algo de analisis web
w3af
whatweb
wapiti
nikto
aria2
ratproxy
wget
httest
links2
webhttrack

Otros (no menos importante)

corkscrew
tor
privoxy
ipcalc
netmask
gns3

Resumiendo todo en una linea:

apt-get install fluxbox terminator guake tint2 vim dia keepassx keepnote
gedit gedit-plugins yersinia python-scapy netexpect netwox netwag hping3 netexpect
packeth arping irpas macchanger wireshark tshark dsniff tcpdump nmap zenmap pnscan
sslscan sshscan doscan netdiscover dnstracer dnswalk smb-nat xprobe p0f hydra hydra-gtk
medusa john aircrack-ng cdpr w3af whatweb wapiti nikto aria2 ratproxy wget httest
links2 webhttrack corkscrew tor privoxy ipcalc netmask gns3

Conclusiones: Esta no es una lista exhaustiva, pero contiene muchas herramientas que podemos instalar de forma prolija desde los repositorios de debian. Ahora les toca estudiar el uso correcto de cada herramienta!

~ have fun!

Hacking – QuickLinks

Aunque en general en este blog nos restringimos a generar información y no a copiar y pegar, me pareció apropiado compartir esta lista de recursos vista en otro blog. Ya que amplia nuestra recomendación de frameworks para estudiar pentesting

Recursos para bajar:

Virtual Machines (VMs) o ISOs:

Recursos Online

Bueno… les queda practicar.
Fuente Taddong
~ have fun!

Aclaración sobre que es Unix

Al igual que el último post (PCs y Servidores), quiero hacer una excepción en la temática general de mi blog, y escribir un tema sobre el que veo mucha confusión. Aunque principalmente se da en los usuarios nuevos de linux, hay muchos usuarios avanzados de linux y *BSD que también están des informados al respecto, y cuando alguien pregunta sobre UNIX se dicen barbaridades.

Que es UNIX®?

Para contestar, hay que explicar primero que existen dos respuestas válidas, pero muchas veces mal entendidas o interpretadas:

El histórico sistema operativo Unix: Escuetamente podemos decir que en 1969, un par de  geeks de los ‘Bell labs’ de AT&T desarrollaron un sistema operativo básico, al que llamaron UNICS al principio y luego UNIX. AT&T distribuyo este sistema en algunas universidades (que era donde había computadoras en aquellos momentos), posteriormente la universidad de California, con sede en Berkeley, sacaba su versión bajo licencia BSD.
AT&T siguió desarrollando versiones de Unix y comercializandolas. En 1993 Unix pasó a manos de Novell, y en 1995 a SCO. La última versión de este antiquísimo sistema operativo se llama UnixWare 7.1.4… Pero la verdad es que nadie le presta mucha atención.

Unix como estándar: Existe un estándar basado en Unix, se llama Single Unix Specification (SUS). Este estándar es manejado por el OpenGroup, cuyos Patinium partners son HP, IBM, Oracle y Philips. La última versión de la SUS es la “UNIX 03” y los sistemas operativos certificados como “UNIX 03” son:

Apple Inc. Mac OS X 10.5 y 10.6
HP-UX 11i V3 Release B.11.31 y posteriores
IBM AIX 5L V5.3 (y V5.2 con ciertas actualizaciones) y 6 v6.1.2 SP1
Sun (y Fujitsu) Solaris 10, versiones de 32 y 64 bits para SPARC y para Intel x86

Es decir estos sistemas operativos son los famosos Unix like.
Tambien existen otras versiones anteriores a la “UNIX 03” en la cual otros sistemas operativos están certificados (vean los links de abajo).

Para que sirve el estándar? Para que un programa/sistema que utilice los métodos sugeridos por el estándar pueda ser fácilmente portado de un sistema a otro.

Ahora bien, existe algo así como un equivalente abierto, este es POSIX. POSIX es una serie de estándares definido por la IEEE. Actualmente la SUS UNIX 03 tiene como base la POSIX y son casi lo mismo, aunque UNIX03 abarca un poco mas.

Mas especificamente: POSIX:2008 = IEEE Std. 1003.1-2008 = SUSv4 = The Open Group Specification Issue 7.

Vale aclarar:
Un sistema UNIX 03, es POSIX.
Un sistema POSIX no necesariamente es un UNIX 03
Certificar POSIX o UNIX 03 es caro.
UnixWare, el heredero directo del sistema operativo Unix, no esta certificado como Unix03!!!

Vamos a las conclusiones y preguntas mas frecuentes…

Conclusiones

Cuando hablamos propiamente, un sistema Unix, es solo aquel que certifica con OpenGroup, actualmente AIX, HP-UX, Solaris y Mac OS (en sus versiones mas recientes).
Y Linux?
Linux es un sistema que se adhiere casi completamente POSIX, esto depende de la distribución, y aunque alguna distribución pueda ser 100% probablemente no este certificada como POSIX ya que cuesta mucho dinero.
Y *BSD?
Esta en la misma situación que linux.
Yo quiero saber Unix para ser un hacker, como hago?
Linux y *BSD son mas que suficiente para tí. Cuando conozcas bien Linux, o mejor aún *BSD, conocerás bastante sobre Unix.
Quiero saber Unix para programar sistemas portables en Unix, que hago?
En el caso de quien quiere programar, le vale estudiar un poco mas los estándares, pero para comenzar Linux y *BSD le sobran. Luego estudia sobre POSIX.

Links de interés para ahondar mucho mas:
Sitio del estandar UNIX 03: http://www.unix.org/
Listado de partners de Open Group: http://reports.opengroup.org/membership_report_all.pdf
Productos registrados bajo UNIX 03: http://www.opengroup.org/openbrand/register/xy.htm
Especificaciones SUS: http://www.unix.org/what_is_unix/single_unix_specification.html
Mas sobre POSIX: http://es.wikipedia.org/wiki/POSIX

~ have fun!