Pero se puede dar el caso de que estemos trabajando en una terminal como un usuario normal, y de repente necesitemos llevar a cabo una acción que solicite permisos de administrador para realizarla. En estos casos es cuando aparece sudo. Sudo es una aplicación (común de los sistemas UNIX y deribados) que nos permite ejecutar acciones con los privilegios de otros ususarios, por lo general del usuario root.

En Debian no viene instalado y configurado por defecto este programa, pero no desesperen porque gracias a Dios viene en los repositorios, por lo que basta con ejecutar:

# aptitude install sudo

Una vez con el sudo instalado deberemos agregar nuestro usuario en la sección “User privilege specification” en el archivo /etc/sudoers, de tal forma que la sección quede así:

# User privilege specification
root ALL=(ALL) ALL
tu_usuario ALL=(ALL) ALL

Una vez configurado esto, ya podremos ejecutar acciones de administrador desde una terminal común, anteponiendo el sudo a la acción a realizar.

aircrack-ptw , nuevo algoritmo implementado para suite de aircrack. Con este podemos desencriptar las claves wep mucho más rápido y con menos ARPs.

aircrack-ptw no viene en los repositorios de Debian , por lo que hay que instalarlo desde las fuentes:
Download aircrack-ptw

$ tar -zxvf aircrack-ptw-1.0.0.tar.gz
$ cd aircrack-ptw-1.0.0

Necesitamos instalar la siguiente dependencia:

aircrack-ptw-1.0.0# aptitude install libpcap0.8-dev

Ahora si podemos compilar:

aircrack-ptw-1.0.0$ make
aircrack-ptw-1.0.0# cp aircrack-ptw /usr/bin

Y a desencriptar:

$ aircrack-ptw captura.cap
For more informations see http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/
allocating a new table
bssid = 00:21:7C:79:B3:09  keyindex=0
stats for bssid 00:21:7C:79:B3:09  keyindex=0 packets=31460
Found key with len 05: 11 11 11 11 11
$

Fuente

En mayo la criptografía sufrió un grave revés. Se descubrió que el generador de números aleatorios del paquete OpenSSL de Debian era predecible. Las claves generadas con él en los últimos dos años ya no eran fiables o verdaderamente seguras. A efectos prácticos, se podría deducir la clave privada a partir de la pública de los usuarios, con lo que la criptografía asimétrica dejaba de ser fiable para la autenticación y para la confidencialidad. Pronto se generó todo el espacio posible de claves vulnerables (públicas y privadas) y se desarrollaron exploits específicos para poder acceder a sistemas SSH protegidos con criptografía pública.

Los administradores que controlan sus sistemas a través de SSH se suelen autenticar a través de su clave privada (el servidor de SSH almacena la pública correspondiente). Esta es una alternativa a la autenticación a través de la clásica contraseña simétrica. Si la pareja de claves ha sido generada con el OpenSSL vulnerable, se puede hacer un ataque de fuerza bruta sobre un espacio de claves muy pequeño, algo que tarda unos 20 minutos con un ordenador de hoy día. Los que hayan protegido el uso de las claves con contraseña, están en principio a salvo.

Aunque el US-CERT no habla de este problema en concreto, probablemente es el que está siendo aprovechado para llevar a cabo estos ataques durante estos días. Los atacantes están intentando acceder a servidores con SSH activo, protegido por criptografía pública y claves privadas vulnerables. Con esto consiguen acceso de forma fácil al sistema. Si el kernel no está actualizado, utilizan algún exploit para conseguir acceso local como root (existen decenas) y una vez dentro, instalan el rootkit Phalanx2 que les permite (entre otras cosas) obtener otras claves SSH para acceder a otros sistemas.

En el apartado de más información se ofrece información sobre cómo detectar el rootkit.

Como advertíamos en mayo, el problema criptográfico del paquete OpenSSL de Debian traerá de cabeza a los administradores durante mucho tiempo. Fueron casi dos años de generación de claves vulnerables en cientos de miles de máquinas, y pasará mucho tiempo hasta que todos los administradores parcheen sus sistemas y sobre todo, vuelvan a generar sus claves públicas y privadas con un sistema actualizado.

Fuente

#apt-cache search kismet
ismet - Wireless 802.11b monitoring tool

Fuente

1. Descomprimimos la utlidad:

# wget http://www.rootkit.nl/files/lynis-1.1.7.tar.gz
# tar zxfv lynis-1.1.7.tar.gz

2. Ejecutamos la aplicacion:

# cd lynis-1.1.7

# ./lynis –check-all

Con esto comenzamos la auditora de nuestro sistema, acontinuacion vamos a dar algunos titulos de los analisis:

[+] Boot and services
[+] Kernel
[+] Memory and processes
[+] Users, Groups and Authentication
[+] Shells
[+] File systems
[+] Ports and packages
[+] Networking
[+] Printers and Spools
[+] Software: e-mail
[+] Software: firewalls
[+] Software: webserver
[+] Databases
[+] LDAP Services
[+] Software: PHP
[+] Software: Malware scanners
[+] System Tools
[+] Home directories
[+] Logging and files
[+] Banners and identification
[+] Scheduled tasks
[+] Accounting
[+] Time and Synchronization
[+] Cryptography
[+] Virtualization
Veamos una captura de pantalla de la utilidad:

Aqui vemos el reporte que nos entrego al analizar uno de los equipos del staff:

Fuente

Con este comando podemos ver los ultimos usuarios que se han logueado en el sistema y que terminales usaron, asi como también los ultimos reinicios del sistema.
Su sintaxis es tan simple como:

$: last

facundo pts/3 localhost Thu Mar 27 04:07 – 04:07 (00:00)
facundo :0 Wed Mar 26 19:11 still logged in
reboot system boot 2.6.24-1-amd64 Wed Mar 26 19:10 – 05:23 (1+10:13)
facundo :0 Tue Mar 25 15:54 – down (12:40)
reboot system boot 2.6.24-1-amd64 Tue Mar 25 15:33 – 04:34 (13:01)

Y obtendremos una salida como esta, la verdad es muy sencillo.
Entre la informacion que nos muestra se encuentran de izquierda a derecha, el usuario, la terminal que uso, el kernel con que arranco este usuario, la fecha del login, la hora de acceso y la hora de salida, asi como un resumen (entre parentesís) de la cantidad de horas que este usuario estuvo en el sistema.
Con el agregado de modificadores, encontraremos mucha mas información que nos puede ser realmente muy util.
Podemos utilizar pipes (tuberias) y hacer uso de la redirección estándar, como con cualquier comando, por ejemplo si queremos generar un archivo sobre los ultimos logins del usuario overclock podemos hacer lo siguiente:

$: last | grep overclock > login_overclock.txt

overclock pts/3 localhost Thu Mar 27 04:07 – 04:07 (00:00)
overclock :0 Wed Mar 26 19:11 still logged in
overclock :0 Tue Mar 25 15:54 – down (12:40)

Existen otras formas de filtrar al usuario overclock, pero esto lo veeremos mas adelante.

El modificador -n [numero] nos muestra los ultimos X cantidad de logins del usuario. Por ejemplo si necesitamos saber los utlimos dos logins en el sistema hariamos:

$: last -n 2

facundo pts/3 localhost Thu Mar 27 04:07 – 04:07 (00:00)
facundo :0 Wed Mar 26 19:11 still logged in

El modificador [username] nos muestra los ultimos accesos al sistema de un usuario en particular, por ejemplo si queremos saber sobre los accesos de "root", cosa que por defecto no muestra la salida de este comando, hacemos:

$: last root

root tty1 Tue Mar 18 23:20 – 23:21 (00:00)
root tty4 Tue Mar 18 23:20 – 23:20 (00:00)
root tty3 Tue Mar 18 23:01 – 23:20 (00:19)

El modificador [ttyX] donde X es un numero real, que identifica a la terminal, nos muestra los ultimos logins en esa shell para ello:

$: last tty1

facundo tty1 Sun Mar 23 01:37 – crash (00:05)
facundo tty1 Sun Mar 23 01:37 – 01:37 (00:00)
root tty1 Tue Mar 18 23:20 – 23:21 (00:00)
root tty1 Tue Mar 18 23:20 – 23:20 (00:00)
root tty1 Tue Mar 18 23:01 – 23:20 (00:19)

Estas entradas por lo general son leidas de un log, este es el archivo /var/log/wtmp, comunmente en ciclos de 30 días, por lo que siempre tendremos una copia del mes anterior llamada wtmp.1 (nunca dos meses, ya que se sobreescriben), a menos que hagamos una copia de este archivo, por ejemplo estableciendo con el cron, un backup mensual de este archivo.

El modificador -f especifica el archivo del cual deben ser leidas las entradas, por ejemplo nosotros actualmente queremos ver las del mes anterior por lo que hacemos:

$: last -f /var/log/wtmp.1

root tty1 Sat Mar 1 05:04 gone – no logout
root tty1 Sat Mar 1 05:04 – 05:04 (00:00)
facundo :0 Sat Mar 1 05:02 gone – no logout
reboot System boot 2.6.22-2-486 Sat Mar 1 05:02 – 04:50 (27+00:48)
facundo :0 Sat Mar 1 02:38 – down (02:22)
root tty1 Sat Mar 1 02:36 – down (02:25)

El modificador -i, nos dice desde que dirección de IP se loguearon en nuestro sistema.

$: last -i

juan tty1 192.168.1.3 Sat Mar 1 05:04 gone – no logout
raul tty1 192.150.1.5 Sat Mar 1 05:04 – 05:04 (00:00)

Por su parte el comando lastb nos muestra una información que puede ser tan util como la anterior, los intentos fallidos de login en el sistema, su uso es simliar al anterior, la diferencia reside en que se “fija” en el archivo /var/log/btmp.
Como dije anteriormente su sintaxis es similar a el comando last, por lo cual solo pondremos un ejemplo.
Si queremos conocer los intentos fallidos de login del usuario “facundo” hacemos:

$: lastb facundo
facundo Fri Mar 14 23:11 – 23:11 (00:00)

Y la salida es esta, el usuario facundo, el viernes (friday) 14 de marzo, a las 23:11, hasta las 23:11 (pues no entro al sistema), tuvo un intento fallido de login.

Para mas información sobre este comando, ya sabén:

$: man last

El manual de ayuda es similar tanto para last como para lastb.

Fuente