Chapter 1 (one)
-intro:
Hola aqui me encuentro sentado tecleando esta intro de esta ezine que espero que les guste y si no ..bueno ya saben ...es su mundo yo simplemente vivo en el.... a veces las cosas no suceden.
gordian_knot
__________________________________
-I have the money...por donde empiezo:
situ:
venia usando una una vieja pentium 100 con un overclock a 133 con un redhat con kernel 2.0 y un w98 que andaba re-lento y seguido de pantallazos azules hasta que luego de 6 meses el w98 no quería arrancar, el redhat funcionaba pero cuando queria actualizar a kernel 2.2 se colgaba. El problema era el overclock que habia hecho mierda el micro, el mother opti viper que era una cagada palmo....
situ
agosto 2001
venia juntando guita y decidi comprarme una pc.........primero tenia que elegir donde la compro.... si donde ? si caí en un local de la famosa galería jardín ( ese lugar que dicen que es barato porque tienen mercadería afanada.) Fue allí donde pedi presupuesto para de una pc standar . el primer local que entre me atendió puto que me quería vender lo que el tenia . Luego fui al piso de arriba donde estaba datasoft , pero parecían medio chantas entonces termine en new heaven ahi me atendieron bien y habia buen precio. entonces pedí la siguiente configuracion:
mother: asus a7a 266 ddr
ram: 256 ddr
disco Wdigital 30 gb udma ata100
lectora dvd pioner 40x/16x
grabadora de cd sony 140e
micro amd 1200 mhz 266 fsb
video : geforce 2 mx 200 32 megas
scanner genius usb
el monitor lo compre en un supermercado un philips 107 s 17 pulgadas junta la impresora epson c20 ux usb
el modem tenia uno usrobotic externo 56k un caño!! //que era de la oficina
sonido sblive
tardaron una semana en armármela ....según ellos porque el mother no lo conseguían . cuando la recibí me dejaron un win me que se lo saque a la mierda.
después le agregue un disco de 4 gb maxtor que te por ahi tirado
_________________________________
Instalando:
primero instale un w98 en el disco de 4 gb (d:) despues parti el disco c: (30gb) en dos
una particion de 10 y una de 15 en la de 15 instale un win advanced server y despues de instalarlo, con fips le hice lugar al linux slackware 3gb.
_________________________________
configurando:
Config de w98:
este win que lo instale en el disco de 4gb lo deje pelado, solo lo usaria por si palmaba el win server .
Config de ventanas 2000 servidor avanzado?
lo primero que hice despues de instarlo fue ponernerle el sp2 despues le pude un programa que realiza auditorias al os (retina 4.7) le pase un scan a 127.0.0.1 y saltaron un monton de fallas despues gracias al programa me baje todos los parches.
nota: el secreto de que un w2k sea seguro es primero tener todo actualizado cuando digo todo me refiero a que este al día tanto los servicios que corremos a la escucha en un puerto como los antivirus y los firewalls. En mi caso le puse el norton antivirus 2002 y el norton personal firewall que ambos se actualizan con el famoso live update . También esta todo lo que respecta a las auditorias de usuarios y de sistemas pero es un todo un tema muy largo que no tienen demasiado sentido si la maquina la usa una sola persona.
tips que lei en la net acerca de la seguridad en w2k
-crear el disco de emergencia:
necesitas un disco 1.44 en blanco y después anda a:
Start -> Programs -> Accessories -> System Tools -> Backup. Select Backup Tab, go to Tools, and select "Create an Emergency Repair Disk".
y lo crean .Si alguna vez se les haga mierda el w2k reinician con un disco de arranque ponen el cd de w2k van a al dir i386 y después escriben winnt y eligen reparar y listo.
-cuentas de usuarios
la cuenta invitado desactívenla. En los discos con ntfs vayan a propiedades y quitan el usuario todos y pongan usuarios autentificados.
-contraseñas:
no vayan a poner boludeces como admin adminnt .Pongan contraseñas jodias de 7 caracteres bien jodidas como d5ja6gm etc.
-update win
creen un acceso directo a: SystemRoot%\system32\wupdmgr.exe asi cuando cuando se conecten a internet les avisara cuando hay una actualizacion critica
-servicios al pedo si no corren un servidor web como iis
Clipbook
Computer Browser
DHCP Client (
Fax Service
Indexing Service
Internet Connection Sharing
IPSEC Policy Agent
Net Logon
Netmeeting Remote Desktop Sharing
Remote Registry Service
Routing and Remote Access
Server
SNMP Service
SNMP Trap Service
Task Scheduler
TCP/IP NETBIOS Helper Service
Telnet
nota: apaguen el FTP puerto 21 también y servicio de publicación web puerto 80
hagan un : netstat -a vean que puertos tienen abiertos
-recursos compartidos
w2k cada vez que reinicia comparte las unidades entonces para cagarlo y que no lo haga hagan lo siguiente
vayan al regedit
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters, seleccionar Edit -> New -> Dword Value y ponganle 0 (cero). como nombre pongan "AutoShareWks" para Windows 2000 Pro and "AutoShareServer para el server.
también deshabiten en conexiones de acceso telefónico a redes : compartir archivos y impresoras"
el puerto 139 que este cerrado !!!
si lo quieren compartir a ya ustedes es su mundo!!
- Internet explorer y outlook express
si usan ie 5 o 6 desabiliten las siguientes opciones
- "Disable"
under "Download signed ActiveX controls"
- "Disable" under "Download unsigned ActiveX controls"
- "Disable" under "Initialize and script ActiveX controls not marked as safe"
- "Disable" under "Run ActiveX controls and plug-ins"
- "Disable" under "Script ActiveX controls marked safe for scripting"
- "Disable" under "Allow cookies that are stored on your computer"
- "Disable" under "Allow per-session cookies (not stored)"
- "Disable" under "File Download"
- "Disable" under "Font Download"
- "Disable Java" under "Java permissions"
- "Disable" under "Access data sources across domains"
- "Disable" under "Don't prompt for client certification selection..."
- "Disable" under "Drag and drop or copy and paste files"
- "Disable" under "Installation of desktop items"
- "Disable" under "Launching programs and files in an IFRAME"
- "Disable" under "Navigate sub-frames across different domains"
- "High Safety" under "Software channel permissions"
- "Disable" under "Submit non-encrypted form data"
- "Disable" under "Userdata persistence"
- "Disable" under "Active scripting" (this is what the Microsoft fix mentioned
above changes)
- "Disable" under "Allow paste operations via script"
- "Disable" under "Installation of desktop items"
- "Disable" under "Scripting of Java applets"
-Dcom
Distributed Component Object Model
vayan a \system32\dcomcnfg.exe
en la solapa propiedades predeterminadas saquen dcom
-conclucion seguridad win 2000
como ven como de estos retoques hay miles, esto solo un buen comienzo con respecto hay firewall el de norton configurarlo de manera que no respondan a los pings y personalizar los programas que accedan a internet
-Config linux
si se deciden instalar linux fijense que sea una que tenga el kernel 2.4, ya que soporta iptables . (en mi caso opte por el ultimo slackware ). elijan el sistema de archivos reiser fs ya que es mas seguro.
1. Seguridad en GNU/Linux
-------------------------
A veces se le ha atribuido al sistema GNU/Linux una escasez de
seguridad, a pesar de ser un sistema multiusuario real, y sí que han
existido conocidos agujeros de seguridad, no en el sistema en su
conjunto sino en diversas aplicaciones. El gestor de correo, enorme y
complejo, _sendmail_ tiene el triste prestigio de ser un programa en
el que había problemas de seguridad frecuentes. Este gestor no era
específico de Linux, pero sí de sistemas UNIX en general.
Por esto, y a pesar de que la respuesta de los desarrolladores de las
diversas distribuciones de GNU/Linux, y de los creadores de
aplicaciones ha sido siempre rápida, es posible que en un sistema no
se tapen los agujeros de seguridad porque el administrador no ha
tenido tiempo de actualizar a la última versión, no conoce de la
existencia de aquél, o no ha sabido configurar adecuadamente las
aplicaciones o servicios ofrecidos.
Las distribuciones basadas en GNU/Linux ofrecen a sus usuarios una
gran cantidad de información en sus servidores de WWW referentes a
actualizaciones de paquetes que proporcionaban programas a los cuales
les ha sido detectado un posible peligro de seguridad. RedHat hace
esto frecuentemente, incluso se vió obligada a sacar la versión 5.1 de
forma acelerada para tapar el gran número de agujeros existentes en su
versión estrella, la 5.0. Debian también pone avisos de seguridad,
cuando son recibidos, relacionados con los programas que se ofrecen
dentro de la distribución, aunque con su modelo de desarrollo más
abierto, veáse por ejemplo el BTS (Bug Tracking System), consigue
ofrecer antes nuevas versiones de los programas con los problemas de
seguridad resueltos. Así mismo, Debian, con posterioridad a la salida
de la versión final de su distribución, crea una nueva sección llamada
_stable-updates_ que contiene actualizaciones a paquetes de la versión
estable en su mayor parte relacionadas con problemas de seguridad.
Sin embargo los problemas que dan lugar a que una determinada máquina
esté "comprometida" no se limita exclusivamente a que se haya
instalado la última versión de un determinado programa, también es
necesario cuidar la configuración de ciertos programas, vigilar la
información ofrecida a los extraños y el contenido de los diversos
ficheros de un sistema.
El sistema GNU/Linux se surte, desde sus principios, de los programas
surgidos dentro de la comunidad UNIX en muchos ámbitos, ya que éste es
un sistema UNIX para PCs, como ya saben los lectores de la revista.
Desde gestores de correo, a servidores de ftp o servidores de WWW,
algunos de los existentes en GNU/Linux son, o provienen de, programas
diseñados en principio para otros sistemas UNIX, aunque con el auge
actual de GNU/Linux estos programas se diseñan específicamente para
Linux. Es por lo primero que los problemas de seguridad de estos
programas se pueden trasladar a una distribución de GNU/Linux, pero
también es por esto que existen gran cantidad de auditores de
seguridad para Linux.
Se tratarán primero herramientas que no son específicas de GNU/Linux,
sino del mundo UNIX en general, y tratando de comentar las
particularidades de aquellos en cuanto a GNU/Linux se refiere.
Posteriormente se comentarán también herramientas exclusivas, surgidas
más recientemente, para GNU/Linux, y se incidirá en las facilidades (o
problemas) de portabilidad de estas herramientas a GNU/Linux.
-------------------------------------------------------------------------------
2. Auditores de seguridad
-------------------------
2.1. ¿Qué son los programas auditores de seguridad?
---------------------------------------------------
Los programas auditores de seguridad son herramientas tremendamente
útiles para la administración de un sistema, ya que permiten detectar,
de forma rutinaria, problemas de seguridad para los que pudieran
existir ataques conocidos.
Un programa auditor de seguridad debería ser capaz de detectarlos sin
vulnerar la integridad del sistema, es decir, no debería, por ejemplo,
detectar que un sistema es vulnerable a un ataque del tipo DoS (Denial
of Service), dejando al sistema "colgado". Este tipo de programas no
sustituyen al sentido común ni a la experiencia de un buen
administrador, sino que suponen una ayuda para realizar algunas tareas
rutinarias que pueden llevar mucho tiempo a un administrador normal.
Estos programas pueden operar a muchos niveles, desde la comprobación
de la pertenencia de archivos a usuarios y grupos del sistema hasta
pruebas sobre aplicaciones instaladas para verificar si éstas tienen
agujeros conocidos. Una forma sencilla de demonstrarlo sería, por
ejemplo, mirar la versión de ésta última, y ver si se trata de una
versión que tuviera un problema especialmente grave.
2.2. Los precursores: COPS, Tiger, Tripwire e ISS
-------------------------------------------------
Llamamos a estos programas precursores porque fueron los primeros que
empezaron a desarrollarse en la línea de automatizar las tareas del
administrador para vigilar la seguridad de la máquina. Todos estos
sugieron en el mundo UNIX al principio de la decada de los 90, aunque
algunos se mantienen aún hoy vigentes o han sido "remozados" para
adaptarlos a los nuevos tiempos.
COPS (Computer Oracle and Password System) es un paquete de
herramientas de seguridad disponible de forma pública. Están
diseñadas para ayudar a la tarea de un administrador identificando
problemas de seguridad en un sistema UNIX, aunque no pretende arreglar
las discrepancias que encuentra sino que simplemente produce un
informe de lo que ha encontrado y lo almacena o lo envía por correo.
COPS fue realizado por Dan Farmer, uno de los creadores de SATAN y
distribuido el 31 de enero de 1989.
El paquete se divide en dos partes: un conjunto de programas que
automatizan comprobaciones rutinarias y la documentación para
manejarlo e interpretar su salida. COPS requiere ser ejecutado en
cada máquina a chequear y es multiplataforma. El programa
inicialmente fue escrito en base a shell scripts (en el intento de
asegurar la portabilidad de éste) y en programas en C (para aquellas
acciones que necesitan ejecutarse rápidamente), la última versión de
este paquete (1.0.4, 6 de marzo de 1992) está realizada, además, en
Perl.
COPS realiza un buen número de comprobaciones, con la intención de
buscar vulnerabilidades:
* chequeo de permisos de ficheros, directorios y dispositivos.
* cracker de passwords a dos niveles, que de hecho ha sido
realizado usando el notorio _Crack_ (ver más abajo).
* comprobación del contenido, formato y seguridad de los ficheros
de passwords y ge grupo.
* chequeo de programas que se ejecutan en /etc/rc* y en el cron.
* búsqueda de programas setuid root, con permiso de escritura y
avisa si son shell scripts.
* comprobación a través CRC de binarios y ficheros importantes para
evitar modificaciones.
* comprobación de permisos de escritura en los directorios de los
usuarios y de sus ficheros de configuración.
* comprobacion automática de avisos del CERT, descargándolos
previamente y comprobando si existe algún aviso nuevo para el
tipo de máquina sobre el que se ejecuta.
* un sistema experto llamado Kuang que en base a una serie de
reglas indica si el sistema ha sido o no comprometido.
* chequeos varios: directorios en el patg, hosts.equiv,
exportaciones por NFS...
Dado que no realiza ninguna modificación, no necesita ser ejecutado
con privilegios de superusuario (como "root") sino que lo puede
ejecutar cualquier usuario. Eso sí, para descubir parte de la
información, como por ejemplo analizar todos los ficheros con el bit
setuid, puede que sea necesario ejecutarlo como superusuario ya que
puede que algunos ficheros (o directorios) no tengan permisos de
lectura para todo el mundo.
Junto con COPS se distribuye CARP (COPS Analysis and Reporting
Program), programa que realiza informes gráficos en base a los
resultados de COPS.
Tiger es similar a COPS, pues se dedica a conseguir información que
pueda descubrir problemas de seguridad en máquinas UNIX pero está más
actualizado que COPS y más configurable. La última versión disponible
es de marzo de 1994.
Tiger, que toma el nombre de un equipo de futbol americano, es un
conjunto de Bourne shell scripts, programas en C y ficheros de datos
que se usan para realizar una auditoría de seguridad de sistemas UNIX.
Es multiplataforma, entre ellas SunOS 4.x y 5.x.
Se desarrolló para escanear sistemas que se querían fueran accesibles
desde el exterior de un campus, y se ejecuta localmente.
El objetivo primordial de Tiger es analizar el sistema para tratar de
encontrar maneras de obtener privilegios de superusuario. Su diseño
parte de la hipótesis de que cualquier otro uid o gid puede ser
obtenido por personas no autorizadas, es decir, que cualquie persona
puede hacerse pasar por un usuario cualquiera de la máquina, excepto,
por supuesto, por el superusuario.
Algunos de los chequeos que reliza Tiger son:
* aliases de mail.
* exportación por NFS.
* variables de inetd.
* variables del PATH.
* ficheros .rhosts y .netrc.
* permisos de ficheros y directorios.
* avisa de la existencia de parches de mantenimiento.
* paths que se encuentren en ficheros que den algún warning.
* ofrece ayuda sobre todos los temas.
* lanza automáticamente el CRACK.
Tiger está disponible para Linux 2.x, gracias al trabajo realizado por
Robert L. Ziegler, aunque la versión distribuida originalmente tenía
soporte para Linux 0.99. Tiger tiene soporte para muchas
arquitecturas, en función de la arquitectura sobre la que se ejecuta
se define las comprobaciones que va a realizar.
Por otro lado tenemos a Tripwire, un programa que comprueba la
integridad de ficheros y directorios. Genera, en su primera pasada
información sobre éstos en una base de datos, y posteriormente los
comprueba y avisa de cualquier diferencia (incluso borrados y
añadidos). Ejecutado de manera regular permite encontrar cambios en
ficheros críticos que podrían haber tenido lugar por la entrada de un
"intruso".
Lo que Tripwire hace es marcar en la base de datos tanto los permisos
y usuarios de los ficheros como un código de redundancia cíclica (CRC)
con el que luego comprueba si ha sido modificado un determinado
fichero. El paquete `tripwire' está disponible para Debian GNU/Linux.
Finalmente dentro de este tipo de programas y en la misma época, se
encuentra el ISS (Internet Security Scanner), de Christoper Klaus. En
un principio el programa fue realizado por un interés, por parte del
autor, de conocer los problemas de seguridad en Internet en 1993.
Posteriormente, el autor creó una compañía alrededor de este producto,
y distinguió la versión comercial de la versión de prueba, que carece
de interfaz gráfico y de parte de la funcionalidad que tiene la
primera.
En cualquier caso ISS se trata de una de las primeras herramientas
que, a pesar de carecer del interfaz gráfico que luego proveerá SATAN
y otras herramientas posteriores, pone en marcha el desarrollo de
herramientas auditoras de seguridad de redes automatizadas. COPS,
TIGER y Tripwire constituyen el primer paso ya que se tratan de
herramientas que sólo ven el sistema sobre el que se ejecutan y
comprueban las vulnerabilidades en éste. ISS es capaz de comprobar
vulnerabilidades comunes en una o varias subrededes (en la línea de
comandos se le dará un rango de una red que indica las máquinas que
debe comprobar)
ISS es un programa monolítico escrito en C, que realiza comprobaciones
sobre los puertos abiertos en el servidor y de los servicios RPC
ofrecidos, estudio de las particiones exportadas por NFS, observación
del servidor de correo, comprobaciones sobre el NIS (antes llamado YP
- Yellow Pages) y accesos mediante telnet haciendo uso de pares de
usuario/password comunes (que en algunos casos venían de fábrica y no
se modificaban).
ISS se convierte así en uno de los primeros programas que implementan
estas baterías de pruebas, de forma que para un administrador resulta
más sencillo comprobar todas las máquinas a su cargo de un sólo
vistazo. Más tarde, aunque muy cercano en el tiempo, llegaría SATAN,
causando una auténtica revolución.
2.3. SATAN
----------
SATAN es el acrónimo de Security Administrator Tool for Analyzing
Networks (ver listado Section A.1, `Curiosidades de SATAN'). Se
trata, más que de un programa, de un conjunto de programas unidos en
un interfaz común. Cuando éste fue escrito por Dan Farmen
(programador de COPS) y Wietse Venema de la Universidad de Tecnología
de Eindhoven, lo que se hizo fue poner una interfaz gráfica que ya se
preveía poderosa, y al mismo tiempo "amigable", como es el WWW a un
conjunto de programas, algunos ya existentes y otros creados de cero
por sus autores, que probaban vulnerabilidades conocidas.
SATAN no es una herramienta novedosa en el aspecto técnico, pero causó
una auténtica revolución. Las herramientas de este tipo, pueden
convertirse, como todas las herramientas, en utensilios útiles o en
armas mortíferas. Los autores tuvieron la "osadía", entonces, de
poner el resultado de su trabajo en Internet y permitiendo la
distribución libre de binarios y fuentes. Había otros programas
disponibles libremente como COPS, para probar vulnerabilidades en un
sólo sistema, o el ISS, para probarlas en sistemas remotos, pero este
último, por ejemplo, carecía de suficiente funcionalidad y de un
interfaz gráfico en la versión pública, aunque sí en la versión
comercial. Los autores decidieron distribuirlo de forma libre ya que
su experiencia les indicaba que los esfuerzos de limitar la
distribución de información de seguridad y herramientas para este fin
no había mejorado las cosas, dado que los elementos "no deseables" los
conseguían de todas formas y las personas que deberían haber tenido
acceso a ellas no lo habían tenido debido a limitaciones arbitrarias o
injustas.
Esto tuvo como consecuencia una grave polémica, por la cual incluso
uno de los creadores fue despedido de su trabajo. SATAN fue concebida
como una herramienta para admininistradores, pero también podía ser
usada como un arma por crackers. Incluso se diseñaron programas para
detectar "ataques" de SATAN, como por ejemplo Courtney (desarollado
por CIAC) o Gabriel.
El problema entonces, y también ahora, es que la mayor parte de los
administradores de sistemas no eran capaces de estar al tanto del
conjunto de agujeros de seguridad que salían en programas de uso
frecuente en muchos sistemas UNIX. Un cracker, bien informado, podía
hacer uso de estas vulnerabilidades reconocidas (pero aún no
resueltas), para atacar a sistemas que aún no se habían actualizado a
una versión del programa que resolviera los fallos.
En un sistema concurren muchos servicios que se "ven" en el exterior,
como por ejemplo: servidores de WWW, de correo o de FTP, gestores de
bases de datos, exportación de discos via NFS, etc... Estar al tanto
de actualizaciones de todos estos y de la forma en que pueden ser
usados para obtener información de un servidor que puede servir e
intentar acceder a éste puede ocupar gran parte del tiempo de un
administrador de sistemas.
Estar al tanto de listas de distribución como bugtrack, los avisos del
CERT (ver listado Section A.4.1, `Dónde buscar información relativa a
la seguridad') no es fácil y, además, si no se hace de forma contínua
se puede dejar un "agujero" que un intruso puede intentar aprovechar.
SATAN abrió la polémica al poner en manos de todo el mundo un
programa, de fácil uso, que descubriera todas estas vulnerabilidades a
un tiempo, a la vez que ponía al descubierto información sobre las
relaciones entre máquinas, lo que los autores denominaron "relación de
Confianza".
SATAN obtiene tanta información como le es posible de servicios de red
como finger, NFS, NIS, ftp y tftp, rexd, y otros. La información
extraída no sólo indica las fuentes por las que un intruso podría
ganar información del sistema, sino también fallos potenciales de
seguridad generalmente debidos a una mala configuración de estos
servicios, problemas conocidos en herramientas de red o malas
políticas de seguridad.
Pero el concepto novedoso de SATAN es el extraer, de la información
inicial y con un conjunto de reglas configurables por el usuario, las
relaciones de dependencia entre máquinas o servicios dados de una a
otra. Esto hace posible el análisis de todos los servidores de una
red para analizar las implicaciones de la política de confianza y
servicios ofrecidos que, en palabras de los autores "les permitarán
hacer decisiones razonables sobre el nivel de seguridad de los
sistemas involucrados". Los autores de SATAN hablan de confianza
cuando recursos locales de un servidor (discos duros, acceso de
usuarios, servidores de X...) son usados por un cliente con o sin la
autorización debida. Si el sistema X confía en el Y, un intruso que
pueda poner en peligro Y podrá también poner en peligro X. Los
autores indican que cualquier tipo de confianza puede ser subvertida,
no sólo porque se pueda acceder a Y, sino porque el sistema que valida
el acceso de Y pueda estar fuera del control del administrador. Por
ejemplo, si se identifica a Y por el nombre de la máquina y se
subvierte el servidor de nombres (el DNS), o si se hace uso de la
técnica de IP spoofing para hacerle creer a X que otra máquina es Y.
A este respecto los autores de SATAN escribieron un excelente ensayo
sobre seguridad en sistemas UNIX y en Internet en general que se
titula "Improving the Security of Your Site by Breaking Into It"
("Mejorar la seguridad de su servidor entrando a la fuerza en él"),
lectura recomendable para todos aquellos interesados en seguridad (ver
listado Section A.4.1, `Dónde buscar información relativa a la
seguridad')
Hay que decir que SATAN es una herramienta que podría considerarse ya
obsoleta, las vulnerabilidades que intenta descubrir, eran comunes (y
conocidas) cuando fue diseñada, pero se tratan de "agujeros" que, hoy
por hoy, deberían estar "tapados", si se detecta algunos de estos es
debido a una incompetencia por parte del administrador de la máquina.
Sin embargo, donde aún sí resulta útil SATAN es en la función de
recopilación de información y en la aplicabilidad del concepto de
confianza.
2.3.1. Ejecución de SATAN
-------------------------
SATAN debe ser ejecutado como usuario _root_ (superusuario) ya que
algunos de los tests que realiza necesita los requisitos de este
usuario para funcionar (ver listado Section A.2, `El problema de
ejecución de binarios como root'). Hace uso, por ejemplo, de sockets
abriéndolos como SOCK_RAW, para hacer accesos a bajo nivel de éstos.
Es posible ejecutar SATAN como cualquier otro usuario, pero algunos de
los tests, no funcionarán en absoluto.
Han existido algunos problemas a este respecto en la distribución de
SATAN, ya que si el programa se ejecuta como superusuario, y el código
fuente está disponible, es posible que algún desaprensivo distribuya
una versión de SATAN "modificada" de forma que, al ejecutarla, se
introduciría un troyano en el sistema, es decir, la copia modificada
realiza más de lo que debería, enviando información, por ejemplo, de
nuestro sistema al exterior. Por ello es una buena medida obtener
SATAN directamente de la fuente original y comprobar que no ha sido
modificado (mediante la suma MD5 del fichero recibido)
Para ejecutar SATAN hace falta Perl 5 (en este lenguaje están
programados los scripts que generan las páginas automáticamente y
algunos de los tests) y un navegador de WWW, bien sea textual (Lynx) o
gráfico (Netscape Navigator o similares). Los programas que realizan
las tareas de prueba sobre los diversos sistemas se escribieron en C,
perl o lenguaje de la shell, utilizando código disponible en los
grupos de noticias (comp.sources.misc.*), y de hecho es posible añadir
nuevos programas a todo el conjunto de la herramienta. Otras
herramientas posteriores, como Section 2.3.3, `SAINT', que se
comentarán más adelante, o Section 2.4, `NESSUS', hacen más fácil el
introducir nuevos programas mediante la descripción de reglas.
Cuando se arranca el programa, éste obtiene la configuración de los
ficheros localizados en el directorio _config/_. Estos ficheros
indican dónde se encuentran herramientas habituales en entornos UNIX
(como _finger_ o _ping_) así como el navegador de WWW que se utilizará
(almacenado en la variable _$MOSAIC_). Estas herramientas serán
utilizados por los diversos programas de los que está compuesto SATAN,
y se pueden configurar a mano o bien utilizando el _script_
proporcionado por los autores (reconfig), que busca la localización de
estas utilidades en el servidor en el que se instale SATAN.
Seguidamente, lanzará un servidor de WWW y el navegador de WWW que se
haya configurado para acceder directamente a la página principal de
SATAN. Desde ésta se seleccionará 'Run SATAN', posteriormente el
servidor al que va a acceder, se podrá limitar si se va a probar sobre
el servidor o sobre su subred, el nivel del escáner y finalmente
'Start the scan'. El acceso al servidor de WWW creado por SATAN (y
que se encuentra en un puerto dedicado, en el espacio de usuario, esto
es, por encima del 1024), se realiza mediante una llave de un sólo uso
que SATAN genera para cada ejecución. Dado que esta llave se guarda
en los ficheros HTML generados por SATAN, es importante que estos
ficheros tengan permisos de lectura sólo para el superusuario y no
para otros. Si no fuera así, cualquier usuario podría acceder al
servidor de WWW con la clave proporcionada en ellos y acceder a toda
la información disponible sobre los escáners realizados por el
superusuario mientras SATAN está siendo ejecutado.
En la selección de Objetivos el usuario puede seleccionar el nivel de
ataque: Ligero, Normal o Duro. Un ataque "Ligero" sólo indicará los
servidores que existen y qué servicios de RPC (llamada remota a
procedimiento) ofrecen. Un ataque "Normal" escaneará los objetivos
probando conexiones telnet, FTP, WWW, gopher y SMTP. Se utilizará
para establecer qué sistema operativo es (aunque para esto es mejor
QueSO, ver listado Section A.2.1, `QueSO, un programa que indica el
SO'). Un ataque "Duro" buscará otras vulnerabilidades, como
servidores de FTP que permiten escribir a todos los usuarios o
servidores de confianza.
SATAN puede ejecutarse con diversas opciones que indiquen qué
servidor/es probar y el nivel de ataque a utilizar, así como
limitaciones en el número de servidores a probar. Además muestra de
forma gráfica los resultados ordenando las vulnerabilidades por tipos,
organizadas de muy diversas maneras (por nivel de riesgo, por sistema
operativo...), aunque los autores indican que un trabajo a realizar
sería mostrar de forma más gráfica (quizás a través de un grafo) las
interrelaciones entre los servidores. Existen además tutoriales que
dan información más en detalle de los problemas concretos de algunas
de las vulnerabilidades, que son útiles para que el administrador
busque más información antes de tomar una decisión sobre cómo arreglar
el problema.
Toda la información recopilada sobre las distintas máquinas se
almacena en una base de datos (se puede tener más de una base de datos
sobre máquinas), que se mantiene entre ejecuciones del programa, y es
útil para inferir relaciones entre máquinas que las pueda hacer
vulnerables.
Además SATAN es configurable con reglas (en el directorio _facts/_)
que le permiten inferir nueva información y detonar nuevos tests en
función de los servicios que se ofrezcan. Estas reglas están escritas
en Perl y, a través de ellas se puede extender el programa con nuevos
tests. De hecho la decisión de qué test realizar en función de la
información recibida se encuentra en estas reglas.
2.3.2. Compilar SATAN para Linux
--------------------------------
SATAN no fue desarrollado originalmente para GNU/Linux, sino que su
documentación indica que funciona en una gran variedad de sistemas
UNIX: SunOS 4.x y 5.x, AIX, IRIX5, HP-UX 9.x, SYSV-R4 y Ultrix 4.x.
Sus autores destacan que hace falta modificarlo para hacerlo funcionar
bajo GNU/Linux.
De hecho es así, siendo necesario modificar los ficheros que se
incluyen al compilar el código fuente para hacerlo funcionar con la
versión de la librería de C de GNU/Linux. Aunque los cambios difieren
para libc5 y para libc6, básicamente debido a la redefinición de la
implementación de los formatos de paquete de IP e ICMP en la librería
estándar. Esto se puede arreglar modificando el fichero `lcompat.h'
(que funciona para libc5) y comentando toda la definición del paquete
ip e icmp, para dejar que sea la librería de C (viene definido en el
fichero `/usr/include/netinet/ip.h') la que los defina. Asimismo se
puede eliminar las referencias en el código fuente a la librería
proporcionada en el paquete, si se dispone de las cabeceras de la
librería de C (en Debian las proporciona el paquete `libc6-dev') para
compilar el programa.
Finalmente, para adaptarse a los "nuevos tiempos" y usar los módulos
de Perl instalados en el sistema en lugar de los proporcionados por el
programa (como es el caso del módulo que proporciona en Perl la
función _getopts_ o _ctime_), es necesario cambiar ligeramente el
programa principal (`satan') y algunos de los tests, que están
escritos en Perl.
También los autores asumen el comportamiento de la llamada al sistema
_select_ (que sirve para quedarse a la espera de recibir datos en
diversos descriptores) y se ha de modificar el fichero `tcp_scan.c'
que es el responsable de escanear todos los puertos TCP disponibles en
un servidor.
Todos estos cambios se han realizado en la versión de SATAN
distribuida junto con Debian. Aunque para beneficio de los usuarios
de GNU/Linux se puede usar el fichero de diferencias
(satan-1.1.1.diff.linux). Utilizando este fichero, realizado con el
programa `diff') se podrían modificar las fuentes originales (haciendo
uso del programa `patch', ver página de manual patch(1)).
En general, un usuario que instale SATAN dentro de una distribución de
GNU/Linux no tendrá que resolver estos problemas, dado que los
responsables de la distribución, presumiblemente, los habrán resuelto
para que se integre dentro de ésta. Sin embargo no está de más
conocerlo, caso de que se desee obtener SATAN de la fuente original y
recompilarlo antes de usarlo, algo bastante aconsejable dado el hecho
de que va a ser el usuario con los máximos privilegios el que va a
hacer uso de éste.
Para compilar SATAN para Linux, una vez realizados los cambios arriba
indicados, es necesario, desde el directorio raíz, ejecutar _make
linux_ seguido de _perl reconfig_. Posteriormente se puede configurar
los valores que ha obtenido automáticamente editando directamente,
como ya se ha dicho antes, los ficheros en el subdirectorio `config/'.
2.3.3. SAINT
------------
SAINT (Security Administrator's Integrated Network Tool) es un
producto de World Wide Digital Solutions Inc. (WWDSI) derivado de
SATAN, realizado en 1998. En versiones previas no se distribuía bajo
la misma licencia que SATAN, aunque versiones posteriores se han
distribuido bajo una licencia _Open Source_ (aunque no es la GPL).
Esta nueva licencia permite su distribución por parte de aquellos que
lo obtienen así como modificaciones, sin embargo no se puede cobrar su
uso más allá de los costes de distribución. Las diferencias con SATAN
en cuanto a interfaz son mínimas, ambos hacen uso de un navegador de
WWW, y los pasos a dar para poner en marcha el programa son los
mismos.
SAINT añade a SATAN lo que éste ahora mismo no tiene y es actualidad.
El programa no sólo prueba las vulnerabilidades que contemplaba SATAN,
sino que añade comprobaciones de las vulnerabilidades conocidas hasta
la fecha de su creación. Los tests incluyen comprobaciones sobre
servidores de WWW, POP o SMB, y nuevas reglas para dirigir el
funcionamiento de éste. Además, la compañía que lo diseñó lo
actualiza con cierta regularidad.
A todo esto hay que añadir muchos nuevos tutoriales, hasta un total de
43, sobre las distintas vulnerabilidades que se puedan encontrar, que
ayudan al administrador dándole más información sobre el peligro de
ésta y sobre cómo eliminarlo. Las vulnerabilidades están clasificadas
en tres categorías: Peligrosas (rojo), Proceder con Cautela (amarillo)
o de Categoría Desconocida (marrones), no en dos como en SATAN.
SAINT demuestra que es posible realizar un producto comercial sobre un
producto que se distribuye de forma gratuita, y con excelentes
resultados. Además se trata de un programa que está siendo aún
mantenido por la compañía que lo creo, que acepta envíos de nuevos
módulos para su inclusión en el programa.
2.4. NESSUS
-----------
Se han visto previamente herramientas, quizás ya algo antiguas, para
intentar introducir el concepto de auditores de seguridad. Ahora toca
el turno de hablar de una herramienta de última generación para
GNU/Linux, y este es el caso de NESSUS (ver http://www.nessus.org).
NESSUS da un paso más alla en el diseño de herramientas de seguridad.
Con SATAN (y SAINT) se vió que se podía introducir una gran capacidad
para detectar fallos comunes haciendo uso de un sencillo interfaz.
Pero el uso de un interfaz WWW, aunque bueno por su facilidad de
manejo (y porque quizás sea el interfaz genérico más usado
actualmente) plantea un problema respecto a la autentificación de los
administradores que hagan uso de SATAN en una máquina.
Por un lado obliga a que SATAN sea ejecutado localmente por parte del
administrador y a que luego éste lanze el navegador en la misma
máquina, de hecho es el primer paso que realiza SATAN. El problema
puede darse cuando se quiera instalar SATAN en una máquina que carece
de interfaz gráfico, es necesario exportar la aplicación (el cliente
de WWW) a través de la red a otra que sí lo tenga. Esto no es
problema si el administrador usa _lynx_ ya que puede seguir utilizando
un interfaz textual para la aplicación y ejecutar el navegador en la
conexión remota.
Si se desea también acceder desde un servidor a otro para ejecutar
SATAN en aquél, es necesario que el navegador de WWW envíe en todas
las peticiones al servidor de WWW que SATAN lanza, el número mágico
que ha generado al arrancar y se encuentra almacenado en los ficheros
HTML. Por ello la primera petición del navegador es a un fichero (su
URL es file://) y posteriormente al servidor (con el URL http://).
Este número es la única prueba para SATAN de que el cliente es quien
dice ser, si cualquier otro intercepta este número y accede al
servidor de SATAN podrá acceder a toda la información almacenada en
este, e incluso ¡hacer sus propias pruebas de seguridad sobre otros
servidores! Esto se podría evitar haciendo uso del protocolo seguro
de conexión a servidores de WWW, _https_ (que usa el SSL de Netscape).
Esta situación no es del todo insospechada, ya que si el cliente y el
servidor están separados, los paquetes enviados de uno a otro, las
solicitudes mediante el protocolo HTTP y las respuestas mediante
páginas en HTML, no están cifradas ni van por un canal cifrado.
Cualquier "espía" en el camino de estos datos podría sacar fácilmente
el número utilizado como prueba de autentificación del administrador.
NESSUS es una herramienta que consta de dos módulos separados. De un
lado el servidor, que debe ser ejecutado como superusuario, que es el
encargado de realizar los tests y que funciona como un demonio en la
máquina en la que se lanza, y en el otro el cliente, que puede estar
en otra máquina distinta. La comunicación entre ambos se hace a
través de un protocolo (que los autores han llamado NTP: Nessus
Transfer Protocol) que, en su última versión (1 de febrero de 1999:
990201) puede llevarse a cabo de forma cifrada (con clave
pública/privada), de forma que el servidor no podría ser usado por
alguien que "espiara" la red y fuera capaz de obtener la palabra clave
utilizada. Esta funcionalidad no estaba presente en la anterior
versión estable del programa (16 de octubre de 1998: 981016).
Si no se compila NESSUS con la opción de encriptación (`./configure
--enable-cipher'), sin embargo, la autenticación entre el cliente y el
servidor se realiza mediante un nombre de usuario y una palabra clave
cuyo intercambio debe darse antes de solicitarle ninguna acción al
servidor. Las palabras clave están almacenadas en un fichero en el
servidor, y es posible limitar sobre qué máquinas puede realizar
pruebas de seguridad a un usuario dado.
Existen clientes para GNU/Linux, usando la librería gráfica `gtk' (la
última versión de NESSUS utiliza la versión 1.1), con la que se ha
diseñado el famoso programa `Gimp' y el entorno `GNOME' (ver
http://www.gnome.org, pero también los hay escritos en Java y para
Windows NT. El servidor, sin embargo, ha de ejecutarse en un servidor
Linux. La interfaz gráfica con gtk (es expléndida, con un buen
aspecto y muy sencilla de manejar. Además de todo esto, y algo a
destacar por su tremenda importancia, NESSUS está siendo desarrollado
bajo la licencia GPL, lo que significa que su modelo de desarrollo es
abierto (cualquiera puede colaborar) y que el código fuente del
programa está disponible para su revisión.
El diseño de NESSUS, como se puede ver en el código fuente, es muy
modular. Todos los tests (algunos los llamarían "ataques") están
escritos por separado, y es fácil insertar nuevos programas.
Actualmente tiene más de 180 pruebas de seguridad de diversa índole,
que el interfaz agrupa por tipos según sean, por ejemplo: agujeros de
sendmail, problemas con servidores de FTP, problemas con servidores de
WWW... Aunque las vulnerabilidades no están tan detalladas como en
otras herramientas (veáse las anteriores), si se da una breve
descripción del problema y una ayuda de cómo solucionarlas.
Al igual que SATAN o SAINT, NESSUS puede expandir los servidores que
conoce de varias maneras: vía subredes de un dominio, haciendo uso del
DNS o cuando ve nuevos servidores a los que se les da acceso mediante
NFS. Se pueden definir reglas para limitar a los servidores que va a
acceder, de una forma más compleja que hacía SATAN (y por ende SAINT),
en éste es posible definir la "profundidad" de la prueba y servidores
que nunca serán probados, pero en NESSUS es posible limitar de tres
formas: no probar ('n'), sí probar ('y') y no probar _nunca_ ('N').
Por ejemplo la regla: "n:*; y:*.foo.org; N:ppp*.foo.org" probaría sólo
sobre las máquinas en el dominio foo.org (y:*.foo.org), excepto todas
las máquinas en este dominio cuyo nombre empezara por ppp
(N:ppp*.foo.org), otras máquinas que se puedan encontrar no serán
probadas (n:*).
Los usuarios puede definir sus propias reglas, aunque existen unas
reglas predefinidas por defecto. Las reglas se almacenan en el
fichero `/usr/local/share' (aunque si se instala un paquete de una
distribución en lugar de las fuentes originales, seguramente lo
instale en `/usr/share').
2.4.1. Instalar NESSUS
----------------------
Si la distribución que usa el lector provee el paquete NESSUS, la
instalación de éste se limitará a instalar dicho paquete y
configurarlo apropiadamente. Este es el caso de Debian. Sin embargo,
si éste no es su caso, será necesario obtener las fuentes originales
(ver listado Section A.3, `Programas relacionados con la seguridad y
dónde encontrarlos.').
Una vez obtenidas, se deben seguir los siguientes pasos para instalar
el programa:
* ejecutar `autoconf' seguido de `configure', que hará uso de
herramientas GNU para configurar el programa a nuestro sistema.
En la documentación indica que debe ser el superusuario el que
ejecute este programa, ya que para probar el tipo de ordenación
de los sockets, es necesario privilegios especiales.
* ejecutar `make' para que compile los programas. Este es un
proceso largo ya que ha de compilar cada uno de los tests de
seguridad que luego se convertirán en librerías que cargará
dinámicamente. Para compilar el programa es necesario tener la
versión de desarrollo de `gtk', que incluye las cabeceras
(ficheros .h) para compilar programas que utilizen esta librería.
En Debian
* ejecutar _make install_. Los programas (`nessus' y `nessusd')
así como las librerías y las páginas de manual serán instaladas
en el sistema.
Una vez hecho esto la configuración, según indica la página de manual
nessus(1) , será creada al arrancar el programa `nessusd' en el
directorio `/usr/local/share/nessus'. La forma de configurarlo está
perfectamente documentada en el Manual que acompaña el programa.
2.5. Gate Security
------------------
NESSUS no es el único programa de este estilo diseñado para GNU/Linux,
también existe `Gate Security', de Stan Lanford, con un interfaz del
tipo curses (en consola). El autor indica que es muy modular y que
sería fácil de ampliar con nuevos tests, ya que actualmente cuenta con
tan sólo tres sobre los servicios de: finger, NFS y WWW. Está aún en
fase de desarrollo (la última versión de mayo de 1998 es la 0.1.4),
así que quizás en su versión final sea un programa a valorar.
2.6. smb-nat
------------
Con este programa se pueden realizar varias comprobaciones de
seguridad sobre servidores remotos que estén compartiendo servicios de
ficheros a través de NetBIOS. Está basado en el paquete `samba' y se
encuentra disponible en la distribución Debian GNU/Linux.
-------------------------------------------------------------------------------
3. Escáneres remotos
--------------------
3.1. Nmap
---------
Nmap es una herramienta para explorar redes y determinar qué
servidores están activos y qué servicios ofrecen. La ventaja con
respecto a otras herramientas es que ofrece múltiples técnicas de
escáner. Las versiones más recientes también ofrecen la posibilidad
de detectar el sistema operativo remoto en función a la implementación
del protocolo TCP/IP. El programa dispone incluso, a partir de la
versión 2.0, de un interfaz gráfico realizado con gtk llamado `nmapfe'
que permite realizar los escáneres sin necesidad de conocer las
múltiples opciones de línea de comandos disponibles. Se trata de una
herramienta muy útil en conjunción de otras, como `scotty' (ver
Section 7.1, `Scotty (antes tkined)', para conocer la estructura de la
red heterogénea que se está intentando auditar. La posibilidad de
hacer un escáner, además, de un grupo de servidores, permite extraer
rápidamente información que pueda servir para hacer un escáner en
mayor profundidad sobre servidores que posiblementa puedan ser
comprometidos.
3.2. Detectar escáneres remotos
-------------------------------
Dado que las herramientas de seguridad mediante tests remotos (SAINT,
SATAN...) pueden convertirse en un arma en manos de una persona que
pretenda utilizarla para fines ilícitos, es necesario disponer de
programas que sean capaces de avisar al administrador cuando se
detecte accesso a la máquina realizados por estos programas con la
intención de obtener información o de probar vulnerabilidades.
3.2.1. Courtney y Gabriel
-------------------------
Este es el caso de `Courtney' y `Gabriel', se verá algo más de éste
último más adelante. El primero de ellos es un programa desarrollado
en la Universidad de California por Marvin J. Christensen. Está
diseñado para detectar este tipo de paquetes. Aunque se distribuya
indicando que dectará ataques de SATAN en realidad será capaz de
detectar un tipo de ataques concreto, denominado _port scanning_,
consistente en probar todos (o un gran número) de los puertos de una
máquina (cada puerto está ligado a un servicio, ver inetd.conf(5)).
Los programas pueden así encontrar servicios vulnerables o no usados
para hacerse una idea más precisa de los servicios ofrecidos por una
máquina.
Se va a estudiar `Courtney' para observar el funcionamiento de estos
detectores. Este programa está escrito en Perl, con lo que es más
fácil de interpretar. El flujo de control del programa es como sigue:
una vez leídas e interpretadas las opciones, ejecuta el programa
`tcpdump' junto con una reglas de filtro de paquetes. El programa
`tcpdump' devolverá todos los paquetes que se lean en una interfaz de
red dada que cumplan alguna de las reglas, estas reglas especifican
que, por ejemplo, se deben mostrar los paquetes dirigidos a diversos
puertos. `Courtney' leerá de éste todas las conexiones de interés
cuando se produzca alguna, y se apuntará su origen, posteriormente
comprobará si ese mismos origen ha hecho acciones similares y, si es
así, avisa al sistema mediante la llamada a _logger_ y envía un
mensaje de correo al administrador.
Así pues, si un ordenador accediera uno detrás de otro a todos los
puertos de una máquina que tuviera `Courtney', éste empezaría a "hacer
saltar las alarmas" del sistema. Posteriormente el administrador
podría tomar la decisión de cerrar el acceso a la máquina atacante o
no, en función de la política de seguridad de éste.
Se puede ajustar el "nivel de alarma" del programa, que indica bajo
qué condiciones se disparará esta. Hay que fijar adecuadamente este
nivel ya que si es muy bajo se disparará ante eventos que son
perfectamente normales (un usuario de una máquina hace una conexión
vía slogin y posteriormente una conexión de FTP), y si es muy alta no
se disparará con los denominados "ataques ligeros", que esperan un
determinado tiempo antes de realizar la siguiente conexión.
Otro programa de las mismas características es _Gabriel_, diseñado
originalmente para Solaris 1 y 2. Éste hace algo similar pero
utilizando los filtros de paquetes de estas plataformas (`etherfind' y
`snoop' respectivamente), pero además incorpora en su configuración
otras formas de avisar al administrador (ver más abajo)
3.2.1.1. Adaptar Gabriel a GNU/Linux
------------------------------------
_Gabriel_ es un programa de Los Altos Technologies, Inc., como ya se
ha indicado detecta escáneres en la red como SATAN. Pero tiene el
aliciente de que es distribuido, los clientes (implementados en
_gabriel_client.c_) avisan de un execeso de accesos a la red y el
servidor (implementado en _gabriel_server.c_) integra la información
de estos y avisa de diversas formas al administador: mediante correo
electrónico, vía el demonio _talk_, en la pantalla e incluso a través
del teléfono o el beeper si existen las pasarlelas adecuadas (y un
módem).
La idea que da lugar a que exista un cliente y un servidor parte del
hecho de que SATAN es capaz de realizar tests sobre más de un host de
una misma red, e incluso descubrirlos a medida que realiza los tests.
Así, puede ser más fácil localizar el segmento de red en que se
encuentra el ordenador que está ejecutando SATAN si se recibe la
información de todos los ordenadores en varios segmentos.
El cliente esta escrito enteramente en C y muy ligado a su plataforma
original, ya que utiliza filtros de paquetes ya existentes, para poder
comprobar todos los paquetes iniciales de conexión (ICMP, UDP y TCP).
En principio sólo tiene soporte Solaris 1.x o 2.x, y aún no ha sido
portado a Linux. Sin embargo este programa sirve como muestra botón
de la manera en que se portan este tipo de programas al sistema
GNU/Linux. Una de las ventajas fundamentales es que la librería de C
de los sistemas UNIX es bastante compatible entre diversas
plataformas, con lo que el código original no es necesario casi
tocarlo si hace uso de ésta. Otra ventaja es que no hace falta
modificar casi el servidor, ya que éste es un shell script que hace
uso de programas comúnes en la comunidad UNIX (como awk)
Por tanto las modificaciones para poder portar este programa a Linux
serían modificar el cliente para soportar la plataforma Linux haciendo
uso de tcpdump, modificar los scripts de shell caso de que hubiera
diferencias entre éstas, y modificar el fichero _Makefile_ para poder
compilar la versión de Linux.
3.2.2. Scanlogd
---------------
-------------------------------------------------------------------------------
4. Otros auditores para GNU/Linux
---------------------------------
Aunque parezca complicado portar este tipo de programas a GNU/Linux,
la experiencia demuestra lo contrario. Por ejemplo, Robert L.
Ziegler, como ya se ha comentado, modificó _Tiger_ para que pudiera
ser usado en RedHat 5.1 el 14 de septiembre de 1998.
Y también es posible diseñar auditores de forma que sean portables
entre plataformas, como es el caso del denominado _gomagog_ de C.
Parisel, que ha sido probado sobre AIX 4.2, HP-UX 10 y Linux 2.0
Este paquete de seguridad se divide en tres módulos: un cliente _gog_,
un servidor _magog_, y un interfaz para el servidor vía HTML llamado
_gogview_.
El cliente _gog_, es un script en shell que recoge información sobre
los directorios indicados en la configuración, que, por ejemplo,
pueden ser el directorio _/etc_ y los directorios donde se almacen los
binarios del sistema. Sobre estos extrae la información de permisos y
pertenencia, al tiempo que extrae una firma del documento a través de
la función _md5_. Toda esta información es almacenada en un
directorio determinado. Se supone que esta información se recrea cada
cierto tiempo, la documentación sugiere que mediante una entrada en el
_cron_.
El servidor _magog_ accede vía FTP a los clientes identificándose con
un nombre de usuario y password y recupera los ficheros que éstos han
dejado con la información sobre cada uno de sus sistemas. Comprueba
esta información con los históricos que ha almacenado y avisa de algún
cambio.
De esta forma es posible saber si se ha modificado un binario (quizás
indique que un intruso ha instalado un troyano), o si se han
modificado los permisos (quizás alguien le ha puesto el bit de
_setuid_ a alguno de los ficheros).
La idea general es que los clientes ejecuten rutinariamente _gog_ y
que cada cierto tiempo se ejecute _magog_ para comprobar los cambios.
Además, la filosofía de descentralización permite que todos los
clientes sean gestioados desde una sóla máquina.
El interfaz añadido en la segunda versión del paquete (que fue
distribuida el 21 de diciembre de 1998) llamado _gogview_, permite
configurar el programa servidor añadiendo y eliminando clientes a los
que debe acceder, y ver la integridad de cada uno de los clientes, que
puede estar en uno de cuatro estados: en buen estado, con una
alteración en el perfil, con varias alteraciones en el perfil o
inalcanzable. Los programas que lo forman deben ser instalados en el
directorio _/cgi-bin/_ de un servidor de WWW ya funcional. Los
programas de configuración del programa que acompañan la distribución
realizan automáticamente esta tarea.
-------------------------------------------------------------------------------
5. Seguridad en las passwords
-----------------------------
5.1. CRACK, comprobar la seguridad de las passwords adivinándolas
-----------------------------------------------------------------
Finalmente, se va a ver una de las herramientas más usadas en
auditorías de seguridad, y no es para menos, ya que una de las formas
habituales de tener acceso a una máquina UNIX es directamente
accediendo a cuentas (vía telnet, rlogin o slogin) con passwords que
se han descubierto fácilmente (o inexistentes). Es por tanto
importante probar los mismos métodos que probaría un cracker para
asegurar que una máquina es segura a estos intentos. Aunque esto no
impide que los usuarios puedan dejarse las password escrita, olvidada
por algún lado, si servirá para asegurar que las passwords del
sistemas no son fácilmente vulnerables.
Aunque atrás quedan los tiempos en que los sistemas UNIX no
registraban los accesos no autorizados y los sistemas VMS eran
considerados más seguros por hacerlo, uno de los métodos empleados por
posibles "intrusos" es obtener el fichero de passwords del sistema a
través de cualquier agujero de seguridad de la máquina, por ejemplo,
un PHP/FI en el servidor de WWW mal configurado. El conjunto de
herramientas _shadow_ ha hecho esto más difícil a posibles intrusos
dado que por un lado se almacena la información del usuario en el
fichero _/etc/passwd_ y por otro las passwords de los usuarios en el
fichero _/etc/shadow_. El primero puede ser leído por cualquier
usuario del sistema, el segundo sólo por root.
Este fichero contiene las passwords de los usuarios encriptadas, es
decir, no están en claro, pero la función que utilizan los sistemas
UNIX (un triple DES), que, aunque es difícil de romper por fuerza
bruta, sí es posible "atacarla" mediante el uso ingenioso de un
diccionario y de reglas. El ataque consiste en encriptar una palabra
dada con la función (que es pública) y compararla con el valor
encriptado de la password (que es el que contiene el fichero), el
algoritmo de encriptación asegura que si ambos son iguales entonces la
palabra usada es la password que se quiere adivinar.
El programa _Crack_ realizará esta función. Dado un fichero de
claves, intentará "adivinar" las claves de todos los usuarios que en
ella encuentre usando un diccionario de palabras comunes y un conjunto
de reglas que indican cambios frecuentes que se realizan sobre ellas.
Serían reglas, por ejemplo, el poner la primera y la última letra en
mayúsculas, o el cambiar todas las vocales por su número
correspondiente (la 'a' por '1', la 'e' por '2'...). Con estas reglas
_Crack_ realiza manipulaciones con las palabras: las invierte, mezcla,
cambia la capitalización, transpone letras.. según una serie de
reglas. El programa viene con unas 240 reglas de manipulación aunque
se pueden construir otras nuevas. Además, es posible conseguir
abundantes diccionarios por FTP, y no sólo de palabras comunes, sino
de hobbies, películas, argot...
Así mismo es capaz de realizar ataques de fuerza bruta, aunque se
estima que para poder adivinar una password de ocho caracteres (el
máximo) con la actual potencia de un ordenador se tardarían varias
decenas de años (debido al gran número de posibilidades, más de cien
billones, teniendo en cuenta todos los caracteres ASCII imprimibles),
si se limita el ataque a un menor número de caracteres (por ejemplo
4), y de menor rango (por ejemplo sólo números) el número desciende
considerablemente (diez mil en el caso propuesto).
Este tipo de ataque puede dar resultados sorprendentes, en poco
tiempo, ya que si no se ha obligado a los usuarios a hacer uso de
passwords difíciles será capaz de adivinar un buen número de ellas.
El programa incopora una función para poder avisar a un usuario de que
su password es excesivamente fácil, para lograr que la cambie, al
tiempo que almacena sus resultados en una base de datos para consulta
posterior del administrador.
Este auditoría sobre la seguridad de las passwords se puede evitar (o
se pueden evitar "sorpresas") de varias formas:
* adiestrando a los usuarios en la búsqueda de palabras claves
fáciles de recordar pero díficiles de adivinar por estos métodos.
* entregando al usuario al principio una password del estilo arriba
mencionado.
* sustituyendo el programa de cambio de passwords por uno que
impida el uso de passwords inseguras, como por ejemplo, de menos
de tres cifras, o sólo con letras o sólo con números. Muchas de
las distribuciones de GNU/Linux existentes traen un programa de
estas características.
* habilitar un mecanismo de "envejecimiento" de passwords, de forma
que el usuario se vea obligado a cambiar su password cada cierto
tiempo.
-------------------------------------------------------------------------------
6. Utilizar sniffers
--------------------
También útiles para ver cómo de vulnerable es el tráfico que pasa por
la red. Un sniffer es un programa que sirve para analizar el tráfico
que pasa por una red. La relación con una auditoría de seguridad es
inmediata, no sólo falicita el localizar tráfico no esperado dirigido
de/hacia un servidor determinado sino que además permite filtrar un
tipo de tráfico determinado para ver qué conexiones
6.1. Sniffers disponibles
-------------------------
6.1.1. Tcpdump e ipgrab
-----------------------
Se pueden conseguir herramientas para analizar los ficheros de tráfico
generados en http://www.acm.org/sigcomm/ITA/
6.1.2. Sniffit
--------------
6.1.3. Karpski
--------------
Se trata de un analizador de tráfico con un interfaz en GTK. Aunque
es menos potente que otros analizadores de tráfico pero posiblemente
más fácil de usar. Dispone de una tabla de equipos con los permite
identificar fácilmente el fabricante del equipo en base a la dirección
física de su tarjeta (dirección MAC). Se puede ``pinchar'' una
conexión para ver todos aquellos paquetes con origen en el servidor
elegido, así como guardar todos los paquetes recibidos.
6.1.4. Ipgrab
-------------
6.1.5. Ethereal
---------------
Se trata de otro analizador de tráfico con un interfaz en GTK, pero
que usa la misma librería que `tcpdump', es capaz de capturar los
paquetes usando filtros que se definen de la misma forma que para este
programa y facilita el análisis _a posteriori_ de los paquetes. Dado
que desempaqueta completamente los paquetes es una herramienta que
necesita de muchos recursos para funcionar correctamente, pero,
asimismo, es tremendamente instructiva porque se puede ver el
contenido del paquete con respecto a información hexadecimal enviada
en la trama. A diferencia de otros analizadores no está orientado a
supervisar de forma inmediata la captura de paquetes, sino a descargar
los paquetes en un fichero y posteriormente estudiarlos a través del
interfaz. Se trata de software aún experimental pero es bastante
usable. Se puede descargar de http://ethereal.zing.org.
6.2. Detectar la actividad de un sniffer
----------------------------------------
-------------------------------------------------------------------------------
7. Monitorizar la red
---------------------
Es útil también tener una herramienta de monitorización de red para
ver los servidores activos.
7.1. Scotty (antes tkined)
--------------------------
-------------------------------------------------------------------------------
8. Auditorías y Debian GNU/Linux
--------------------------------
En Debian GNU/Linux posiblemente estén disponibles dentro de la
distribución muchos más programas útiles para hacer una auditoría de
seguridad que en cualquier otra distribución de GNU/Linux. Con la
ventaja añadida de, no sólo su disponibilidad, sino su fácil
instalación, ya que los desarrolladores de los paquetes
correspondientes ya se han preocupado de solventar los problemas de
compilación e instalación existentes.
_______________________________________________________________________________________
DVD - divx
Aqui les voy a explicar como crackear la lectora de dvd para que sea multizona y también como pasar películas dvd a divx.
Primero se tienen bajar que un programa que se llama region info este les dirá que la lectora de dvd rom tiene proteccion de zona y los cambios que nos quedan (recordar que son 4 cambios )
nuestro objetivo es sacarle la proteccion de zona para poder ver dvd en zona 1,2,3,4,5 y 6
cambiando de zonas las veces que queramos.
paso 1
van a www.google.com y buscan ATAPI DVD-116 Patched FIRMWARE UPGRADE 1.09 este es para
el caso de una pioner dvd rom 116 ustedes deben cambiarlo por las que le dice el programa region info
una vez que se lo bajan deben ponerla la lectora en ide secundario maestro en como les dicen el txt de ayuda que viene con el crack . tengan cuidado porque si lo hacen mal se les caga
la lectora , ya que estan escribiendo en la rom de la misma.
------------------------------------------------------------------------------
dvd a divx
una pelicula de dvd puede ocupar unos 5 gigas minimo y al pasarlo a divx lograran que esos 5 gigas se reduzcan a 650 aprox. como es esto? es algo parecido mas o menos a lo que pasa con el wav y el mp3 (sacando lo que el oido humano no percibe etc) al pasar un dvd a divx se reduce la calidad, pero realmente se nota muy poco . Ustedes piensan que el ojo humano percibe los 32 bits de color. con solo 16 bits (32.000 colores) es mas que suficiente!!
Hay dos programas bastante buenos que utilizo son el easydivx y el flaskmpeg. el primero es muy facil de usar pero últimamente estoy teniendo problemas con películas como el exorcista y swordfish . El segundo es un muy bueno hasta ahora es el mejor que conozco también es muy fácil de usar. Realmente estos programas son muy facil de usar no vale la pena que me ponga a explicar paso a paso el proceso. sino bajen el tutorial que anda dando vuelta por ahí
nota: no se olviden que primero hay que ripear la pelicula , el programa smartripper es muy bueno ,. Necesitaran mucho disco rígido 10 gb libres para estar cómodo .El smartripper lo que hace es desencriptar la película al disco rígido. luego bájense el flaskmpeg con todos sus plugins.
Problemas:
Puede que tengan problemas de sincronización del vídeo con el audio por eso hay que prestar atención a la cantidad de cuadros por segundos. Con respecto a los subtítulos pueden usar el programa Subrip.
____________________________________________________________________________________________________________
Written by gordian_knot from aisle.