Los servicios que corren en su sistema pueden ser asegurados de dos maneras:
Restringir los servicios de modo que solamente puedan ser accedidos desde un lugar dado puede ser hecho restringiendo el acceso al nivel del kernel (i.e. cortafuego), configúrelos sólo para escuchar en un interfaz dada (algunos servicios no pueden suministrar ésta característica) o usando otros métodos, por ejemplo el parche linux vserver (para 2.4.16) puede ser usado para forzar procesos de forma que usen solo una interfaz.
En cuanto a los servicios usados desde inetd
(telnet, ftp, finger,
pop3...) cabe notar que inetd no puede ser configurado de forma que los
servicios solo escuchen en una interfaz dada. Sin embargo, su sustito el
metademonio xinetd
incluye un bind justamente para
ste problema. Vea xinetd.conf(5)
.
service nntp { socket_type = stream protocol = tcp wait = no user = news group = news server = /usr/bin/env server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin +/usr/sbin/snntpd logger -p news.info bind = 127.0.0.1 }
Laa siguientes secciones detallan como cada servicio determinado puede ser configurado debidamente dependiendo de los usos que se quieran dar.
Si aún está usando telnet en vez de ssh, debe detener la lectura de este manual y cambiar esto. Ssh debería ser usado para todas las entradas remotas en vez de telnet. En una época donde es fácil husmear el tráfico de internet y obtener contraseñas en texto plano, debe usar sólo protocólos que usen criptografía. De una vez, ejecute un apt-get install ssh en su sistema.
Anime a todos los usuarios de su sistema para usar ssh en vez de telnet, o
mejor aún, desinstale telnet/telnetd. Además, debe evitar las entradas al
sistema usando ssh como root y use métodos alternativos en vez de root, como
su o sudo. Finalmente, el archivo
sshd_config
, dentro de /etc/ssh
, debe ser modificado
para aumentar la seguridad así:
Haga que ssh escuche solo la interfaz dada, sólo en un caso de que haya más de uno (y no necesite un ssh disponible sobre éste) o que en un futuro agrege una nueva tarjeta de red (y no necesite una conexión desde ssh en ésta).
Intente no permitir al Root entrar tanto como sea posible. Si alguien quiere volverse root por vía ssh, dos logins serán necesarios y la contraseña root no puede ser obtenida a fuerza bruta por vía SSH.
Cambie el puerto de escucha de tal manera que el intruso no pueda estar completamente seguro de si está corriendo un demonio de sshd. (Note que esto es seguridad por oscuridad).
Las contraseñas en blanco convierten en broma la seguridad del sistema.
Permita que solamente ciertos ususarios tengan acceso vía ssh a esta máquina.
Permita que solamente los miembros de ciertos grupos tengan acceso vía a ssh a esta máquina. AllowGroups y AllowUsers tienen directivas equivalentes para denegar el acceso a una máquina. Predeciblemente se llaman "DenyUsers" y "DenyGroups".
Queda completamente a su elección lo que usted quiera hacer. Es más seguro permitir el acceso a la máquina solamente a usuarios con llaves ssh en el archivo ~/.ssh/authorized_keys. Si es lo que quiere déle el valor "no".
Como nota final, dese cuenta que estas directivas son de los archivos de la configuración de OpenSSH. Ahora mismo hay tres demonios SSH usadados habitualmente, ssh1, ssh2, y el OpenSSH de la gente de OpenBSD. Ssh1 fue el primer domonio ssh diaponible y aún es el más comunmente usado (hay rumores de que existe incluso un porte a windows). Ssh2 tiene muchas ventajas sobre ssh1, pero se distribuye con una licencia mixta de código abierto-cerrado. OpenSSH es un demonio completamente libre que soporta tanto ssh1 como ssh2. La versión instalada en Debian cuando se escoge el paquete 'ssh' es OpenSSH.
Usted puede leer más información acerca de la configuración de SSH con PAM en
el security
mailing list archives
.
Squid es uno de los servicios más populares de proxy/cache,y hay alunos
problemas de seguridad que deben tenerse en cuenta. Por defecto Squid impide
todas las solicitudes de los ususarios. Usted debe configurar Squid para
permitir el acceso a los ususarios, servidores o redes confiables o redes
definidas en una Lista de Control de Acceso en /etc/squid.conf
,
mire la guía del usuario de Squid en Squid User's
Guide
para más información acerca de la definición de las reglas
ACL.
Además, si no configuró debidamente, algúien puede enviar correo a través de Squid, puesto que el diseño de los protocolos HTTP y SMTP es semejante. El archivo de configuración Squid niega por defecto el acceso al puerto 25. Si desea permitir las conexiones del puerto 25 adiciónelo a la lista Safe_ports. Sin embargo, esto NO is recomendado.
Ajustar y configurar debidamente el proxy/cache es solamente una parte para mantener su sitio seguro. Otra tarea necesaria es analizar los registros de Squid asegurándose que todas las cosas que están trabajando, deben hacerlo como se espera. Hay algunos paquetes en Debian GNU/Linux que pueden ayudar al administrador a hacer esto. Los siguientes paquetes estan disponibles en woody (Debian 3.0):
calamaris
- Analizar de las bitácoras de los proxy Squid y Oops.
modlogan
- Analizador modular de bitácoras.
sarg
- Generador de Reportes de Análisis de Squid.
ARREGLAME: Add more information about security on Squid Accelerator Mode
Si realmente tiene que usar FTP (sin enmascararlo con sslwrap o dentro de un
tunel ssl o ssh), debería hacer cambio del directorio raíz de FTP hacia el
directorio de los usuarios ftp, de modo que que el usuario sea incapaz de mirar
cualquier otra cosa que su propio derectorio. De otra manera ellos pueden
atravesar su sistema de archivos tal como si tuvieran una línea de comandos.
Usted puede añadir la siguiente línea en su proftpd.conf
en la
sección global para habilitar esta característica del cambio de directorio
raíz: feature:
DefaultRoot ~
Reinicie proftpd con /etc/init.d/proftpd restart y revise si puede escapar desde su directorio raíz ahora.
Para impedir los ataques de Proftp DoS use ../../.., y adicione la siguiente
línea en /etc/proftpd.conf
: DenyFilter \*.*/
No olvide que FTP envía login y contraseñas de autenticación en el texto plano
(esto no es un problema si usted está proporcionando un servicio público
anónimo) y hay buenas alternativas en Debian para ésto. Por elemplo,
sftp
(sumistrado por ssh
). También hay
implementaciones libres de SSH para otros sistemas operativos, por ejemplo:
putty
y
cygwin
.
Sin, embargo, si aún mantiene el servidor de FTP mientras los usuarios acceden
a SSH podría encontrar un problema típico. Usuarios que acceden a los
servidores Anónimos de FTP dentro de un sistema asegurado con SSH es el camino
intentar entrar en el servidor FTP. Mientras el acceso se niegue, la
contraseña nunca se enviará por la red en texto plano. Para evitar esto, el
desarrollador de ProFTPd, TJ Saunders, creó un parche que impide a los usuarios
anónimos del servidor FTP intentar contraseñas con cuentas SSH válidas. Más
información y parches disponibles en: ProFTPD Patches
.
Hoy en día, más y más empresas usan las terminales X cuando necesitan un servicio para muchas estaciones de trabajo, ésto puede ser peligroso porque necesita permitir que un servidor de archivos se conecte con los clientes (el servicio X, desde el punto de vista X. X intercambia la definición de cliente y servidor) Si sigue la (muy mala) sugerencia de muchos documentos, tecleé xhost + en su máquina. Esto permite conenctar con su sistema a cualquier cliente X. Para tener una seguridad ligeramente mejor, puede usar el comando xhost +hostname en vez de la anterior para permitir un acceso desde servidores específicos.
Una solucón mucho más segura es usar ssh como túnel de X y encriptar la sesión
completa. Ésto se hace automáticamente cuando se hace ssh a otra máquina.
Esto puede habilitarse en el archivo /etc/ssh/ssh_config
colocando
X11Forwarding a yes. Cuando use SSH, usted de
suspender completamente el acceso basado de xhost.
Para mayor seguridad, si no necesita acceso a X desde otras máquinas, dehabilite el enlace con el puerto tcp 6000 tecleando simplemente: startx -- -nolisten tcp
Este es el comportamiento original en XFree 4.0 (el servidor X suministrado en
Debian 3.0). Si está usando XFree 3.3.6 (i.e. tiene un Debian 2.2 instalado)
puede editar /etc/X11/xinit/xserverrcc
para que tenga unas líneas
como las siguientes:
#!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp
Si usted está usando XDM digite /etc/X11/xdm/Xservers
: :0
local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp
Lea mas sobre la seguridad X Window en XWindow-User-HOWTO
(/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz
).
ARREGLAME: Add info on thread of debian-security on how to change config files of XFree 3.3.6 to do this.
Si usted solamente quiere tener un administrador visual instalado para el uso local (teniendo un bonito login grafico), asegurarse que el material seguro XDMCP (control de protocolo de administrador visual X) este inhabilitado. En XDM usted puede hacer esto con la siguiente linea. /etc/X11/xdm/xdm-config:
DisplayManager.requestPort: 0
Normalmente, todos los administradores visuales estan configurados para no iniciar los servicios de XDMCP por defecto en Debian.
Imagine, que usted llega al trabajo, y la impresora está botando interminables cantidades de papel porque alguien está negando el servicio de linea de su demonio de impresión. ¿No es terrible?
En cualquier arquitectura de impresión Unix, tiene que haber la forma de enviar
los datos de los clientes a los servidores de impresión. En el
lpr
ylp
tradicional, el comando del cliente es
copiado o se hace un enlace simbólico de los datos en el directorio de cola
(por lo cual usualmente estos programas son SUID o SGID).
Para evitar algunos asuntos usted debe mantener seguros, los servidores de
impresión. Esto significa que usted necesita configurar su servicio de
impresión para que solo se permita la conexión del conjunto de servidores
confiables. Para hacer esto es necesario, añadir los servidores a los que se
les va a permitir imprimir en /etc/hosts.lpd
.
Sin embargo, incluso si usted hace esto, el demonio lpr
acepta las
conexiones entrantes en el puerto 515 de cualquier interfaz. Deberia
considerar hacer una regla de cortafuegos para las conexiones de red/servidor a
las cuales no se permite la impresión (el demoniolpr
no puede ser
limitado a escuchar únicamente a una dirección IP dada).
Lprng
se prefiere en lugar de lpr
porque este puede
ser configurado para hacer el control de acceso a IP, ademas se puede
especificar cual interfaz va a emplear (aunque sea un poco extraño).
Si está usando el servicio de impresión de su sistema, pero solo localmente, no
querrá compartir este servicio en la red. Puede considerar el uso de otros
sistemas de impresión, como el servicio proporcionado en cups
PDQ
el cual se basa en
el permiso de un usuario del dispositivo/dev/lp0
En cups
, los datos de impresión se transfieren al servidor vía el
protocolo http. Esto significa que el programa del cliente no necesita ningún
privilegio especial, solamente requiere que el servidor esté escuchando sobre
un puerto cualquiera.
Sin embargo, si usted quiere usar cups
, pero solo localmente usted
puede configurar esto para escuchar a la interfaz loopback cambiando
/etc/cups/cupsd.conf
:
Listen 127.0.0.1:631
Hay muchas otras opciones de seguridad, como por ejemplo permitir o negar redes
y servidores en este archivo de configuración. Sin embargo si no los necesita,
debería limitar posibilidad de escuchar el puerto. Cups
también
ofrece documentación a través del puerto HTTP, si no quiere revelar información
potencialmente útil para agresores externos (estando abierto el puerto),
también agregue:
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 </Location>
Este archivo de configuración puede ser modificado para añadir muchas caracteristicas incluyendo certficados SSL/TLS y criptografía. Los manuales estan disponibles en http://localhost:631/ or at cups.org.
ARREGLAME: Add more content (the article on Amateur Fortress Building
provides
some very interesting views).
ARREGLAME: Check if PDG is available in Debian, and if so,suggest this as the preferred printing system.
ARREGLAME: Check if Farmer/Wietse has a replacement for printer daemon and if it's available in Debian.
Si su servidor no es un sistema de correo, usted realmente no necesita tener un demonio de correo escuchando conexiones entrantes, pero usted podría querer envío de correo local, por ejemplo para recibir el correo del usuario Root desde cualquier sistema de alerta que usted tenga en algún lugar.
Para hacer esto en un sistema Debian, tendrá que eliminar el demonio smtp desde inetd:
$ update-inetd --disable smtp
y configurar el demonio de correo solo para escuchar en la interfaz loopback.
En exim (el MTA por defecto) usted puede hacer esto añadiendo la siguiente
línea editando: /etc/exim.conf
y añadiendo la siguiente linea:
local_interfaces = "127.0.0.1"
Reinicie ambos demonios (inetd y exim) y estarán escuchando en el socket 127.0.0.1:25 solamente. Sea cuidadoso, y primero desconecte inetd, de lo contrario, exim no iniciara ya que el demonio inetd está manejando las conexiones entrantes.
Para usar postfix edite /etc/postfix/main.conf
:
inet_interfaces = localhost
Si usted solo quiere un correo local, este metodo es mejor que usar la cubierta
tcp-wrapping al demonio de correo o añadir las reglas del cortafuego para
limitar el acceso de cualquier persona a este. Sin embargo, si necesita que
escuche en otras interfaces, debería considerar lanzarlo desde inetd y añadir
un tcp-wraping de forma que las conexiones sean revisadas contra
/etc/hosts.allow
y /etc/hosts.deny
también será
advertido cuando un acceso no autorizado está atentando en contra de su demonio
de correo, usted debe instaurar un registrador apropiado para cualquiera de los
metodos mencionados anteriormente.
Leer/recibir correo es el protocolo más común de texto plano. Si usted usa
POP3 o IMAP para obtener su correo, la contraseña es enviada en texto plano a
través de la red, de modo que casi cualquiera podría leer su correo a partir de
ahora. En lugar de esto, use SSL (Capa segura de Sockets) para recibir su
correo. La otra alternativa es ssh, si tiene una cuenta shell en la máquina
que actua como el servidor POP o IMAP. Este es un ejemplo básico
fetchmailrc
para demostrar esto:
poll my-imap-mailserver.org via "localhost" with proto IMAP port 1236 user "ref" there with password "hackme" is alex here warnings 3600 folders .Mail/debian preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref my-imap-mailserver.org sleep 15 </dev/null > /dev/null'
La preconexión es la línea más importante. Este lanza una sesión ssh y crea el tunel necesario, el cual automaticamente envía las conexiones para tener acceso a localhost puerto 1236 al servidor de correo IMAP, pero codificado. Otra posibilidad seria, usar el fetchmail con la caracteristica ssl.
Si usted quiere suministrar un servicio de correo codificado como POP e IMAP,apt-get install stunnel e inicie sus demonios de esta es la forma:
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
Este comando encapsula al demonio proveido (-l) en el puerto (-d) y usa el certificado ssl especificado (-p).
Hay diferentes consideraciones que puede implementar para asegurar el demonio de servidor de nombres, las cuales son similares a las mismas que cuando se asegura cualquier servicio dado:
Deberia restringir alguna de la información que es dada por el servidor DNS
para clientes externos para que no pueda ser usado para acceder a información
valiosa de su organización que usted no quiere dar. Esto incluye añadir las
siguientes opciones: allow-transfer, allow-query,
allow-recursive y version.Puede limitar en una sección global
(para que se aplica a todas las zonas presentes) o sobre una base por zona.
Esta información esta documentada en el paquete bind-doc
, lea más
sobre esto en /usr/share/doc/bind/html/index.html
una vez el
paquete este instalado.
Imagine que su servidor está conectado a Internet y a su red interna (su IP
interno es 192.168.1.2)(un servicio de multi domicilio basico). Usted no
quiere dar ningun servicio para Internet y solo quiere permitir el lookups DNS
desde su servidor interno. Usted podria restringir esto para incluirlo en:
/etc/bind/named.conf
:
options { allow-query { 192.168.1/24; } ; allow-transfer { none; } ; allow-recursive { 192.168.1/24; } ; listen-on { 192.168.1.2; } ; forward { only; } ; forwarders { A.B.C.D; } ; };
La opciónlisten-onhace el bind DNS solo para la interfaz que tiene la dirección interna, pero si esta interfaz es la misma como la interfaz que se conecta a Internet (por ejemplo, si usted está usando NAT), las dudas seran solamente aceptadas si llegan desde su servidor interno. Si el sistema tiene multiples interfaces y el listen-on no está presente, solamente los usuarios internos podrian pregutar, ya que el puerto seria accesible para los atacantes exteriores, ellos podrian tratar de arrojarlo al servidor DNS (o explotar el amortiguador desbordandose agresivamente). Usted aun podría leer esto en 127.0.0.1 si usted no está dando el servicio DNS por ningun otro sistema que el de usted mismo.
El registro version.bind en la clase caos contiene la versión del proceso bind que se está ejecutando. Esta información es frecuentemente usada por dispositivos automaticos e individuos maliciosos que desean determinar si el bind de uno es vulnerable a un ataque específico. Para proporcionar falsa o negativa información en el registro de la version.bind, uno limita la probabilidad que un servidor pueda ser atacado basandonos en la versión publicitaria.Para suministrar su proia versión, utilice la version dirigida de la siguiente manera:
options { ... various options here ... version "Not available."; };
Cambiar el registro de la version.bind que no proporciona una protección actual
en contra de los ataques, pero este debería ser considerado un salva guardia
útil. Con respecto a limitar los privilegios de BIND, usted debe darse cuenta
que si un usuario del non-root recorre Bind, Bind no podra detectar las nuevas
interfaces automaticamente. Como por ejemplo si usted pone en un portatil una
tarjeta PCMCIA. Cambie el archivo README Debian en el directorio nombrado
(/usr/share/doc/bind/README.Debian
)para mas información acerca de
este uso. Recientemente han habido muchos problemas de seguridad en lo que
concierne a BIND, y por esto es necesario cambiar el usuario util cuando sea
posible.
Para correr BIND bajo un usuario diferente, primero cree un usuario separado y un grupo para esto (no es buena idea usar,not nobody o nogroup para todo sevicio que no corra como raiz). En este ejemplo, el usuario y el grupo namedserán usados. Usted puede hacer esto entrando a:
addgroup named adduser --system --ingroup named named
Ahora edite /etc/init.d/bind con su editor favorito y cambie la linea comenzando con:
start-stop-daemon --start
a
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
Todo lo que usted necesita hacer ahora es reiniciar Bind'/etc/init.d/bind, y luego cambiar su syslog por dos entradas como estas:
Sep 4 15:11:08 nexus named[13439]: group = named Sep 4 15:11:08 nexus named[13439]: user = named
Gwow! su nombre ahora no corre como raíz. Para archivar la máxima seguridad
de Bind, ahora contruya su aseguramiento del cambio de directorio raiz (verUso del cambio de directorio raíz, Sección
4.11)alrededor de su demonio. Hay una forma fácil para hacer esto: la
opción -t (ver el manual de pagina named(8)
). Esto
le permitirá por si mismo un cambio de directorio raiz Bind, dentro del
directorio dado, sin que usted necesite instlar un aseguramiento en el cambio
de directorio raiz y sin preocuparse por la dinamica de librerias. Los únicos
archivos que necesitan estar en ese cambio de aseguramiento de directorio son:
dev/null etc/bind/ - should hold named.conf and all the server zones sbin/named-xfer - if you do name transfers var/run/named/ - should hold the pid and the name server cache (if any) this directory needs to be writable by named user var/log/named - if you setup logging to a file, needs to be writable for the named user dev/log - syslogd should be listening here if named is configure to log through it
Para que su denmonio BIND trabeje apropiedamente, este necesita permiso en los archivos nombrados. Ésta es una tarea fácil ya que los archivos de configuarción estan siempre en /etc/named/. Tenga en cuenta que esto solamente necesita acceso de lectura para los archivos de la zona, a menos que este sea un secundario o un servidor llamado cache. Si este es su caso usted tendra que dar permiso de lecto-escritura a las zonas necesarias (asi como la zona transferida desde los tarbajos del servidor primario).
Si usted quiere leer mas información sobre porque BIND no corre como el usuario
non-root sobre los sistemas Debian, por favor revise el sistema Bug Tracking
relacionado a BIND, específicamente Bug #50013: bind should not run as
root
.
Usted, también puede encontrar mas información con respecto al cambio de raiz
de BIND. Chroot-BIND-HOWTO
(analizar Bind 9) y Chroot-BIND8-HOWTO
(analizar Bind8). Estos mismos documentos deberian estar disponibles a traves
de la instalación de doc-linux-text
(versión de texto) o
doc-linux-html
(versión html).
Si usted está instaurando un aseguarmiento del cambio de directorio raiz completo (i.e no solo -t)para BIND 8.2.3 en Debian (potato), asegurese de tener los siguientes archivos en:
dev/log - syslogd should be listening here dev/null etc/bind/named.conf etc/localtime etc/group - with only a single line: "named:x:GID:" etc/ld.so.cache - generated with ldconfig lib/ld-2.1.3.so lib/libc-2.1.3.so lib/ld-linux.so.2 - symlinked to ld-2.1.3.so lib/libc.so.6 - symlinked to libc-2.1.3.so sbin/ldconfig - may be deleted after setting up the chroot sbin/named-xfer - if you do name transfers var/run/
ARREGLAME, merge info from http://www.cryptio.net/~ferlatte/config/
(Debian-specific) and http://www.psionic.com/papers/whitep01.html
.
ARREGLAME. Add content.
Usted puede limitar el acceso a el servidor Apache si si usted quiere usar esto
solo internamente (para objetivos de prueba, para tener acceso al
archivodoc-central
etc..) y si no quiere que extraños tengan esto.
Para hacer esto use el Listen o BindAddress dirigidos
en /etc/apache/http.conf
.
Usando Listen:
Listen 127.0.0.1:80
Usando BindAddress:
BindAddress 127.0.0.1
Luego reinicie Apache con /etc/init.d/apache restart y vera que
esto es de solo Audición en la interfaz loopback
.
De todos modos, que usted no este usando todo lo funcionamiento suministrado
por Apache, usted podria querer dar un vistazo a otro servicio de la web
proporcionados en Debian como dhttpd
.
La Apache
Documentation
proporciona información relacxionada con las medidas
de seguridad que deben ser tomadas en el servidor web del Apache (esta misma
información está suministrada en Debian por el paqueteapache-doc
).
Si usted quiere recorrer el servicio de finger, primero preguntese si usted
necesita realizar esto. Si lo hace, usted mismo descubrira que Debian
proporciona muchos demonios finger (Puest fuera de apt-cache search
fingerd
):
ffingerd
es el demonio finger recomendado para si usted va ausar
esto para un servicio publico. De todos modos usted se fortalece, cuando
establece este a traves de inetd, xinetd o tcpserver para: limitar el numero de
procesos que estaran corriendo al mismo tiempo, limitar el acceso para el
demonio finger a partir de un numero dado por los servidores (usando el
wrappers tcp) y teniendo esto solamente por audición para la interfaz en la que
usted necesita estar.
Es probablemente favorable decir que la complejidad de BIND es la razón por la cual este ha sido revelado a muchos atacantes en los años recientes (ver seguridad Bind en la pagina 52). (ver Asegurando BIND, Sección 5.8)
Otros programas con caracteristicas complejas y una larga base del usuario instalado incluyen Sendmail y algunos demonios (e.g. WUftpd). (Evidentemente un programa sin caracteristicas y sin satisfacer que pueden ser muy inseguros, e ineficacez).
De cualquier modo, usted recorre cualquiera de estos, considere los dispositivos similares para ellos -revocando los privilegios de root, corriendo en un aseguramiento del cambio de directorio raiz- reemplazandolos con una equivalencia mas segura.
Usted deberia tratar de evitar cualquier servicio de red el cual envia y recibe contraseñas en un texto claro sobre una red como FTP/Telnet/NIS/RPC. El autor recomienda para todos el uso de ssh en cambio de telnet y ftp.
Mantenga en mente que migrar de telenet a ssh pero usando otros protocolos de texto claro no aumentan su seguridad de NINGUNA forma! lo mejor seria eliminar ftp, telnet, pop, imap, http y suplantarlos con sus respectivos servicios codificados. Usted debe considerar moverse desde otros servicios hasta sus versiones SSL, ftp-ssl, telnet-ssl, pop-ssl, https...
Muchos de estas indicaciones numeradas en la parte superior se aplican a documentos en todo el sistema Unix (Usted los encontrara si lee cualquier otro hardening-related relacionado con lo que tiene que ver con Linux y otros Unix).
Es posible que usted no tenga que usar NIS, en el servicio de información de la red, porque este permite que la contraseña actue. Este puede ser demasiado inseguro si su organización está rota.
Si usted necesita que la contraseña actue entre maquinas, usted deberia
considerar usar otras alternativas. Por ejemplo usted puede colocar un
servidor LDAP y configurar PAM en su sistema para contactar el servidor LDAP
para la autenticación del usuario. Usted puede encontrar una detallada
organización en el LDAP-HOWTO
(/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz
).
Lea mas sobre la seguridad en NIS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz
).
ARREGLAME (jfs): Add info on how to setup this in Debian
Usted deberia desactivar donde quiera que sea posible. Muchas fallas seguras
de este sevicio son conocidas y pueden ser fácilmente exploradas. Por otra
parte los servicios NFS son totalmente importantes en algunas redes, de esta
manera usted encontrara un balance de seguridad y utilidad en su red. El DDoS
(distribución negativa del servicio)ataca el uso de RPC que son explotados para
entrar en el sistema y actuar tanto como el llamado agente/manipulador. Lea
mas sobre la seguridad NFS en NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz
).
Inhabilitar el paquete portmap
es super sencillo. Hay diferentes
mátodos. Uno de los más sencillos en un sistema Debian 3.0 es hacer un
desinstalamiento del paquete portmap
. Si usted está usando otra
versión, tendrá que desactivar el servicio como se ve en Deshabilitar los demonios, Sección 3.6.1,
esto es debido a el programa que forma parte del paquete net-base
(el cual no puede ser desinstalado sin que el sistema se haya destruido).
Esto en realidad elimina toda conexión con el sistema relacionado a el
portmap
en /etc/rc${runlevel}.d/,lo cual es algo que
usted también hacerlo manualmente. Otra posibilidad es chmod
644/etc/init.d/portmap, pero que da un mensaje de de error o cuando se
entra a el sistema. Usted también puede deshacer
start-stop-daemon en la parte /etc/init.d/portmap
que
es la cubierta del escrito.
El Sistema operativo Debian GNU/Linux que tiene capacidades built-in
proporcionadas por Linux kernel. Esto significa que si usted instala un
sistema potato (descargar Debain 2.2) (el Kernel defectuoso es 2.2) usted
tendra el corta-fuegos ipchains
disponible en el Kernel el cual
seguramente estara instalado (debido a su prioriedad). Si usted instala
instala un sistema woody (Descargar Debian 3.0) (el Kernel defectuoso es 2.4)
usted tendra el corta fuegos ipchains
disponible.
iptables
.
Algunos usuarios podrian colocar reglas a el corta-fuegos como fuente para este
escrito. Sin embargo revise que programas o caracteristicas del corta fuegos
usted debe usar ya que ellos pueden explorar otros archivos y cambiar las
definiciones que usted agrego en el inicio. Por ejemplo,
firewalk
, para uno, usara otro archivo de configuración para
colocar el corta fuegos.
Si usted está usando Debian 3.0, usted notara que el paquete
iptables
lo tiene instalado. Este es el soporte para el 2.4.4+ de
la implementación de un filtro de la red de Kernel. Ya que solo despues de la
instalación el sistema no puede conocer ninguna regla corta-fuegos (reglas del
corta-fuegos son también sistemas específicos) usted debe habilitar
iptables
.
Para hacerlo como se debe, es de la siguiente manera:
/etc/default/iptables
de tal manera que la variable.
enable_iptables_initd este colocada para true
iptables(8)
) o algunas herramientas proporcionadas
por el paquete corta fuegos Debian (verPaquetes del
Corta Fuegos, Sección 5.15.4). Debe crear una estructura de reglas del
corta fuegos para ser usada cuando el cortafuego esté activo y otra
cuando el corta fuegos esté inactivo (estas pueden ser reglas vacías).
Una vez esté hecha la estructura del corta fuegos, ésta es almacenada en el
directorio /var/lib/iptables/
y será ejecutada cuando el sistema
arranque (o cuando reinicie el script con los argumentios start y
stop). Por favor tenga en cuenta que la configuración inicial de
Debian carga el código del corta fuegos en los niveles del multiusos (2-5),muy
pronto (10). Es detenido en el nivel monousuario (1), cámbielo si no es la
política local.
Prevenga que algunos de los paquetes se encuentran fuera de la linea pueden intrducir escritos del corta fuegos para ser recorrido, esto afectara indudablemente a la estructura comun y a usted entoces tendra un efecto indeseado. Consulte la documentación del paquete de documentación y use algunas de estas organizaciones.
Si usted no tiene un indicio sobre como colocar sus reglas al corta fuegos
consulte el Paquete Filtrador HOWTO proporcionado por
iptables
al leer fuera de la linea en
/usr/share/doc/iptables/html/
Usted puede usar las reglas de corta fuegos cono una forma para asegurar el acceso en un sistema local, invluso para limitaer la salida de comunicación hecha por este. Las reglas corta fuegos pueden ser usadas también para protejer procesos que no pueden ser configurados apropiadamente ni proveer servicios para algunas redes, direcciones, IP, etc...
Sin embargo, este paso se presentara despues en el manual, basicamente porque es mucho mejor para no depender únicamente de la capacidad del corta fuegos para protejer un sistema dado. La seguridad en un sistema no puede ser hecho de cubiertas, el corta fuegos deberia ser el ultimo en incluirse, una vez todos los servicios hayan sido fortalecidos. Usted puede fácilmente imaginar un plan en el cual el sistema está protegido solamente por un corta fuegos incorporadoy un administrador blissfully que remueve las reglas del corta fuegos por cualquiera que sea la razón (problemas con la instalación, molestias, errores humanos...), este sistema abierto ampliamnete para un ataque.
Un corta fuegos de Debian también puede ser instalado para proteger, con reglas de filtración, el acceso a los sistemas detras de este, limitando sus exposición en Internet.
Usted aun puede colocar un buzon Debian GNU/Linux como un camino hacia el corta fuegos, i.e. un filtrador de corta fuegos completamente transparente a la red puede hacer falta en la dirección IP pudiendo ser atacado directamente.
Si usted no sabe mucho acerca del corta fuegos, lea el Cortar fuegos-howto que
pueden ser encontrados en el doc-linux-text
(otros formatos del
documento también disponibles). Vea Estar
enterado de los problemas de seguridad generales., Sección 2.2 para mas
apuntes.
Hay un software completo que pueden ser usados para colocar reglas de corta fuegos en un sistema Debian
fwbuilder
mason
, el cual puede proponer reglas de corta fuegos basadas en el
trafico de la red a su sistema "sees".
bastille
(En medio de los fuertes pasos que pueden hacer nuevas
versiones de bastille, es la posibilidad de añadir reglas del corta fuegos del
sistema para ser ejecutado en el sistema.)
ferm
fwctl
easyfw
firewall-easy
ipac-ng
gfcc
knetfilter
firestarter
Los ultimos paquetes: gfcc son administradores GUIS usados o bien en GNOME (los primeros dos) o en KDE (el último), están orientados a usuarios (i.e. para usuarios caseros) ya que los otros paquetes en la lista, están más orientados para administradores.
ARREGLAME: Add more info regarding this packages
ARREGLAME: Check Information on Debian firewalling and what/how does it change from other distributions.
ARREGLAME: Where should the custom firewalling code be enabled (common FAQ in debian-firewall?)
Manual de Seguridad de Debian
2.4 (revisión de traducción 3) 20 septiembre 2003 Tue, 30 Apr 2002 15:41:13 +0200jfs@computer.org