CONCLUSIONES
CAPÍTULO 3. INSTALACIÓN DEL INTRANET NAFIN
ÍNDICE
El autor: David Hernández 

CAPÍTULO 4

ADMINISTRACIÓN DEL INTRANET NAFIN 

4.1 Seguridad

"The project will not aim... to use sophisticated network authorization sytems. Data will be either readable by the world (literally), or will be readable only on one file system, in wich case the file system's protection system will be used for privacy. All network traffic will be public."
- Fragmento de la proposición inicial del Web en CERN (Lincoln D. Stein, How to Set Up and Mantain a World Web Site, pág. 131).

Cuando el Web fue creado, se pensaba más en un acceso universal que en la seguridad, así lo demuestra la cita anterior. "El proyecto no tenderá... a usar sofisticados sistemas de autorización de red. Los datos serán legibles para todo el mundo (literalmente), o serán legibles en un solo sistema de archivos, en tan caso el sistema de protección del sistema de archivos será usado para privacía. Todo el tráfico de la red será público."

Pero al hacer público un sitio Web se le expone a ciertos riesgos, por ejemplo:

En capítulos anteriores se han visto algunas de las bondades, que en cuestión de seguridad que ofrece el servidor NCSA Httpd.
Para el desarrollo del Intranet Nafin, el problema específico de seguridad se resume en los siguientes puntos: A continuación mostraré fueron empleadas algunas características del servidor, más algunas del sistema operativo para lograr una combinación de seguridad que se ajuste a dichos puntos.
 

4.1.1 Restringir el uso del servidor

El archivo access.conf contiene, entre otras, las instrucciones Directory y Limit.
Con Directory se abre un área definiendo el directorio en que se desee aplicar la instrucción Limit.
Se editó el archivo: 
/usr/local/etc/httpd/conf >vi access.conf
Y fue modificada la sección donde se encontraba la instrucción Directory. Se encontraba como sigue: 
<Directory /oraman/nodoinfo>
<Limit GET>
order allow,deny
allow from all
</Limit>
</Directory>
"GET" quiere decir que la instrucción va a tener efecto cuando el cliente obtenga documentos o realice scripts.
"order" es el orden en que va a interpretar las subsecuentes instrucciones, como estaba, primero iba a ejecutar todas las que permitan y después todas las que nieguen, esto es importante pues se aceptan contraórdenes. Por ejemplo, negar a un grupo y después permitir a ciertos usuarios del mismo grupo es lógico, si primero se da acceso y después se niega, la negación incluye a quienes se dio acceso anteriormente.
"allow from all" permite de todos, frente a la instrucción "allow from" puede haber direcciones específicas, nombres de dominio, y puede haber varias líneas con instrucciones "allow from".
Después de las modificaciones quedó así (con más líneas "allow from", por supuesto): 
<Directory /oraman/nodoinfo>
<Limit GET POST>
order deny,allow 
deny from all
allow from 130.0.1.54
allow from 130.0.1.58
</Limit>
</Directory>
"Limit GET POST" fue usado para para referirse a los dos métodos de acceso más populares, "POST" es para los clientes que ponen scripts.

El orden escogido fue negar y después permitir, ya que se restringió a la mayoría, si fuese a restringir a una minoría se haría al contrario, primero se le da acceso a todo mundo y se discrimina a unos cuantos.

Se usó "deny from all", negando el acceso a todo mundo, y después con "allow from" se incluyen a los amigos.
Se cerró el área Limit dentro del área Directory con: 

</Limit>
</Directory>

4.1.2 Restricciones de acceso a ciertos directorios.

Posteriormente se añadió otro grupo con líneas similares para otro directorio dentro del arbol abarcado previamente, en este caso solo tres personas fueron incluidas en líneas "allow from". De esta forma se limita un área como de uso exclusivo para estas tres.
 

4.1.3 Evitar que usuarios locales tengan acceso a los archivos.

Se modificaron los derechos de archivos y directorios, para que solo un usuario los utilice (dhernand), anteriormente era root, pero si se restringe a que solo root consulte los documentos se tendría que dar esa identidad a los procesos que se lanzan para los usuarios que navegan, así que se eligió dhernand como la identidad de los procesos lanzados en las consultas para los navegadores.
Para ello se editó la línea User del archivo httpd.conf para que quede así: 
User dhernand
Group #-1
Para esto el servidor standalone debe de correrse como root. El demonio original corre como root, pero los procesos que corran al haber peticiones van a correr como el usuario dhernand. En cuanto al grupo, definido en la siguiente línea, quedó sin restricciones.
Por supuesto, fueron modificados los principales directorios de documentos, del servidor y de los programas para que solo el usuario dhernand tenga todos los derechos y suprimidos los derechos de "group" y "others".
 

4.2 Mantenimiento

4.2.1 Estándares

El asunto de los estándares es uno de los que tienen más influencia en la industria informática.
A fin de cuentas el estándar como camino a seguir, nos puede guiar zigzagueando a una pesadilla, o puede ser un camino recto hacia cada vez mejores resultados.

Estándares en diseño HTML
Como en toda publicación, se puede aplicar creatividad al diseño de páginas Web, pero al mismo tiempo hay que estar conscientes de la funcionalidad.

Algunas observaciones básicas en pro de la eficiencia:
 

 

4.2.2 Las páginas del www en modo local.

Uno de los servicios del intranet es tener una copia de páginas del WWW para satisfacer la curiosidad de todos los interesados en determinado tema. Esto es un ahorro de tiempo de conexión a Internet, ya que solo se consulta una vez y se copia en el mismo formato. Estas páginas se depositan en un lugar común donde están disponibles a todo el intranet.

Pero hay una amenaza, la información copiada es mucha, (llegó a representar el 50% del contenido del intranet), y podría incrementarse, además, en un momento dado llega a ser obsoleta, o simplemente, ya no es interesante o necesaria.

Como precaución se colocó una fecha de caducidad en la página principal de las páginas del WWW en el intranet, hoy 28 de mayo es colocada la liga para documentos relativos a Java y Hot Java, y entre paréntesis: cad. 28/nov/96. Lo mismo a las demás.

Al llegar a su fecha de caducidad el directorio será borrado. Se optó por ésto en vez de actualizarlo, ya que la actualización dejaría archivos obsoletos huérfanos, es decir sin ligas a la información actualizada.

Seis meses de vida para cada tema, el criterio fue la velocidad con que los usuarios interesados la asimilarían y la que le toma al documento ser obsoleto.
 

4.2.3 Respaldos

La frecuencia establecida para los respaldos es: diaria para la información, e inmediatamente después de cada actualización para el servidor y la programación.

Respaldo de la información
El esquema de respaldo para los subdirectorios que contienen la información se basa en una copia idéntica hacia otro servidor, creando un arbol de directorios igual bajo un directorio personal.
La primera vez que se realizó simplemente fue una copia total, esto es muy sencillo: 

# rcp -r /oraman/nodoinfo tmpr04:/usr/users/dhernand/oraman
Se utilizó el comando remote file copy incluyendo subdirectorios para mandar todo al servidor tmpr04, pero esto es solo la primera vez, después no tendrá sentido copiar archivos que no han cambiado, además, con 40 MB de archivos se tarda unos 9 minutos.
Para los respaldos diarios el sistema fue copiar solo los archivos que han cambiado hasta sus directorios correspondientes en tmpr04.
Ésto se logró con el script siguiente, los comentarios incluidos lo explican: 
# Primero un prompt para pedir la fecha que buscamos respaldar
echo "Escribe la fecha (Mmm dd) de los archivos a respaldar"
# Capturo en la variable fecha
read fecha
# Me interesa saber a que hora comencé el respaldo,
# así que la escribo en el archivo tiempo.
date > tiempo
# La siguiente línea es algo larga
ls -lR /oraman/nodoinfo |grep "$fecha" | grep -v 'drwx' |cut -c46-79 |awk '{print "find /oraman/nodoinfo -name " $1 " -print"}' > respa_buscar
# Pido el directorio (ls) en formato amplio incluyendo los subdirectorios (-lR)
# a partir del directorio donde está la información (/oraman/nodoinfo).
# Direcciono la salida hacia el comando grep para buscar la expresión
# capturada en la variable $fecha sobre cada línea.
# Las líneas que coinciden con la fecha son direccionadas a otro grep para
# buscar entre ellas las que no sean directorios.
# Direcciono hacia el comando cut para recortar el rango de columnas que
# contiene el nombre del archivo en cada línea.
# Lo direcciono al lenguaje awk para que coloque la instrucción find a partir
# del directorio que importa, buscando el nombre de archivo que el 
# comando anterior le envió y pidiendo que imprima la ruta cuando lo encuentre,
# (el objeto de la búsqueda es tener la ruta).
# Todo eso es direccionado al archivo respa_buscar.
chmod 700 respa_buscar
# Cambio el modo del archivo para que yo lo pueda leer, escribir y ejecutar.
# A continuación lo muestro para que el usuario tenga idea de qué va a pasar.
cat respa_buscar
# Lo ejecuto, me entrega los archivos con su ruta, y le añado el comando rcp
# para hacer la copia remota del archivo hasta tmpr04 en la misma ruta, pero
# solo escribo las instrucciones en el archivo respa_copiar
respa_buscar | awk '{print "rcp " $1 " tmpr04:/usr/users/dhernand" $1}' > respa_copiar
# Cambio el modo del archivo respa_copiar como hice con respa_buscar.
chmod 700 respa_copiar
# Lo ejecuto, entonces se realiza la copia.
respa_copiar
# Escribo la hora, entre otras cosas en el archivo tiempo.
date >> tiempo
# Lo leo para ver cuanto se tardó. Es todo.
cat tiempo
Respaldo de HTTPd Y glimpseHTTPD
Estando en el directorio 
/usr/local/etc
El directorio httpd fue empacado y comprimido en el archivo http.tar.Z 
# tar -cvf http.tar httpd
# compress http.tar
Se transfirió a una PC, al hacerlo el nombre del archivo cambió a http.tar, entonces, desde el prompt se utilizó la utilería pkzip (Pkware Inc., info@pkkware.com) para archivarlo sin compresión en dos disquetes previamente formateados y vacíos. 
 pkzip -e0& a:http-tar.z http.tar
Después de que escribió en los dos discos se incluyó el archivo PKUNZIP.EXE en el segundo.
Los disquetes fueron protegidos contra escritura y etiquetados "Respaldo HTTPd y GlimpseHTTP, Disco 1 de 2", y 2 de 2, respectivamente.

Respaldo de Glimpse
Este programa no cambia, por lo tanto no requiere más de un respaldo.
Desde /usr/local se empacó y comprimió el directorio creado originalmente al obtener Glimpse de Internet: 

# tar -cvf glimpse.tar glimpse-3.5.bin.dec-ultrix-4-3
# compress glimpse.tar
Se transfirió usando FTP a una PC, al hacerlo el nombre del archivo cambió a glimpse.tar, entonces, desde el prompt se utilizó pkzip para archivarlo sin compresión en dos disquetes previamente formateados y vacíos. 
 pkzip -e0& a:glimpse.z glimpse.tar
Después de que escribió en los dos discos se incluyó el archivo PKUNZIP.EXE en el segundo.
Los disquetes fueron protegidos contra escritura y etiquetados "Respaldo Glimpse, Disco 1 de 2", y 2 de 2, respectivamente.
 

4.2.4 Instrucciones para instalar desde el respaldo

HTTPd Y glimpseHTTPD
Introducir el disco etiquetado "Respaldo HTTPd y GlimpseHTTP disco 2 de 2" en el drive A:
Ejecutar desde el prompt de MS-DOS: 
 A:> pkunzip http.z c:\
Al ejecutarse, pkunzip pedirá el primer disco del set de respaldo, introduzca el etiquetado "Respaldo HTTPd y GlimpseHTTP disco 1 de 2" y presione Enter. Cuando pida el segundo inserte el "... Disco 2 de 2" y presione Enter.
Esto extraerá el archivo http-tar.z en c:\. Utilicé FTP binario para transferirlo al intranet en el directorio /usr/local/etc.
Una vez ahí renómbrelo, descomprímalo, extraiga los archivos y borre el empacado. 
 mv http-tar.z http.tar.Z
uncompress http.tar.Z
tar -xvf http.tar
rm http.tar
Consulte la sección correspondiente para arrancar del servidor HTTP.
GlimpseHTTP utiliza Glimpse, si es necesario consulte la sección sobre primera instalación de Glimpse (página nn [entre paréntesis para el texto impreso allí habrá texto en negrillas o título, link para Web versión] ) como instalarlo desde el respaldo viene a continuación.

Glimpse
Introducir el disco etiquetado "Respaldo Glimpse disco 2 de 2" en el drive A:
ejecutar desde el prompt de MS-DOS: 

 A:> pkunzip glimpse.z c:\
Al ejecutarse, pkunzip pedirá el primer disco del set de respaldo, introduzca el etiquetado "Respaldo Glimpse disco 1 de 2" y presione Enter. Cuando pida el segundo inserte el "... Disco 2 de 2" y presione Enter.
Esto extraerá el archivo glimpse.tar en c:\.
Utilice FTP binario para transferirlo al intranet en el directorio /usr/local.
Una vez ahí renómbrelo, descomprimalo, extraiga los archivos y borre el empacado. 
# mv glimpse.tar glimpse.tar.Z
# uncompress glimpse.tar.Z
# tar -xvf glimpse.tar
# rm glimpse.tar
Consulte la sección correspondiente sobre uso de Glimpse.
 

4.2.5 Actualizar índices de búsqueda

Los índices de búsqueda se actualizan el día primero de cada mes, o antes si se elimina o agrega una cantidad relevante de información que sea necesario tener disponible.
Para esto solamente se corre el script ghreindex y Glimpse vuelve a indexar con los mismos parámetros que cuando se instaló.
 

4.2.6 Actualizar estadísticas de uso

Esta taréa se realiza cada mes.
El procedimiento con el que se obtienen los datos y son colocados en el intranet es el siguiente:
CONCLUSIONES
CAPÍTULO 3. INSTALACIÓN DEL INTRANET NAFIN
ÍNDICE
El autor: David Hernández