El SNMP (Protocolo Simple de Gestión de Red, Simple Network Management Protocol) se diseñó para permitir que sistemas heterogéneos y equivalentes hablasen entre sí, generasen informes y permitiesen modificaciones de sus configuraciones sobre una red TCP-IP.
Por ejemplo, un dispositivo SNMP (como un router Cisco) se puede monitorizar/configurar desde un cliente SNMP, y se pueden escribir con sencillez scripts, para, digamos, alertarte si los paquetes denegados/segundo suben por encima de 20.
Por desgracia, SNMP no trae seguridad incluida. El SNMPv1 se propuso originalmente en el RFC 1157 (Mayo de 1990) y la sección 8 (Consideraciones de Seguridad) dice: "En esta memoria no se discuten asuntos de seguridad". Creo que eso lo resume todo. En 1992/1993, salió el SNMPv2, y contenía consideraciones de seguridad, sin embargo éstas se eliminaron más tarde cuando demostraron ser totalmente rompibles. De modo que hoy hemos acabado con un SNMPv2 sin seguridad.
Actualmente, la única forma de proteger los dispositivos SNMP consiste en configurar el nombre de la comunidad por algo difícil de adivinar (pero es muy fácil hacer un sniffing del cable y encontrar el nombre), y filtrar con el cortafuegos el SNMP de modo que sólo los hosts que necesiten hablar entre sí puedan hacerlo (lo cual te deja abierto al spoofing). Los ataques al nombre de la comunidad mediante fuerza bruta son fáciles de llevar a cabo, y suelen ser efectivos, y existen varios métodos para monitorizar específicamente las transmisiones SNMP y reventar por completo una comunidad SNMP, es un mundo peligroso el que existe por ahí fuera.
Estos riesgos se pueden mitigar ligeramente dada la utilidad que tiene el SNMP, puesto que si está soportado e implementado de forma correcta, puede hacer significativamente más sencilla la administración de la red. Casi en cada
implementación de SNMP, el nombre por defecto de la comunidad es "public" (en cuanto a Linux, NT, etc), hay que cambiarlo, por algo más oscuro (el nombre de la empresa es una mala idea). Una vez que alguien ha conseguido el nombre de la comunidad, puede llevar a cabo un "snmpwalk" y entrar en la red. El SNMP se ejecuta sobre UDP en los puertos 161 y 162; hay que bloquear esto en todas las entradas a la red (la backbone, el pool de acceso telefónico, etc.). Si un
segmento de la red no tiene habilitados dispositivos SNMP o una consola SNMP, habría que bloquear el SNMP hacia y desde esa red. Esta es la única línea de defensa en cuanto a SNMP.
Por añadidura, el uso de IPSec (u otro software VPN) puede reducir considerablemente el riesgo de sniffing. Los RFC's del SNMPv3 se centran con intensidad en la seguridad (específicamente el RFC 2274, Ene 1998) de modo que queda algo de esperanza en el futuro. Si se están comprando productos SNMP, asegúrate de que soportan SNMPv3, pues sólo así tendrás oportunidades reales de seguridad.
Con el cu-snmpd no existen problemas específicos per-se, aparte de los problemas generales del SNMP anteriormente cubiertos. Las herramientas y utilidades cu-snmp sólo soportan SNMPv1 y SNMPv2, de modo que recuerda tener
cuidado al utilizarlas sobre redes no fiables, puesto que la principal línea de seguridad (el nombre de la comunidad) quedará expuesta a que lo vea cualquiera.
ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 161:162
ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 161:162
ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 161:162
ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 161:162
ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 161:162
ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 161:162
Finger
El Finger es una de esas cosas que la mayoría de los administradores deshabilitan e ignoran. Es una herramienta útil según la ocasión, pero si se quiere permitir que otros administradores se hagan una idea de cuál de tus usuarios está intentando reventar el sistema, utiliza identd. El Finger revela demasiada información, y es la herramienta favorita para pruebas niciales, y recopilación de datos sobre los objetivos. Existen otro tipo de ataques DOS, la mayoría consistentes en el envío de cientos de peticiones de finger y en ciertas configuraciones simplemente en observar el murmullo del servidor. Por
favor, no ejecutes el finger. Muchas distribuciones vienen con él habilitado, pero citando el inetd.conf de Red Hat:
# Finger, systat y netstat proporcionan información que puede ser
# valiosa para potenciales "revienta sistemas". Muchos sitios eligen
# deshabilitar alguno de estos servicios para mejorar la seguridad.
Si todavía se tiene la sensación de que es absolutamente imprescindible utilizarlo, ejecútalo con –u para denegar las peticiones de tipo finger @host que sólo se utilizan para reunir información para futuros ataques. Deshabilita finger, de veras. Recientemente Fingerd también ha sido la causa de unos pocos ataques severos de denegación de servicio, especialmente si se ejecuta el NIS con grandes mapas, NO, repito NO ejecutes fingerd. El finger se ejecuta en el
puerto 79, y el cfinger se ejecuta en el puerto 2003, ambos utilizan tcp.
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 79
ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 79
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 79
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 79
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 79
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 79
Cfingerd
Cfingerd (fingerd configurable) es un buen reemplazo del fingerd original, se construyó teniendo en cuenta la seguridad, normalmente se ejecuta como usuario no-root, y los usuarios lo pueden configurar con facilidad de modo que no se
les pueda hacer un finger. Cfingerd se encuentra disponible en:
http://ftp.bitgate.com/cfingerd/
PFinger
El PFinger es parecido al Cfingerd en la forma en que supone un reemplazo seguro del fingerd original. Se puede conseguir en:
http://www.xelia.ch/unix/pfinger/
IdentdEl servicio identd se utiliza para mapear usuarios/procesos a puertos en uso.
Por ejemplo, la mayoría de los servidores irc intentan averiguar quién se está conectando a ellos haciendo una petición identd, lo cual consiste básicamente en preguntarle al servidor identd desde el ordenador cliente qué información
tiene sobre un número de puerto, y la respuesta puede varias desde ninguna (si nadie está utilizando ese puerto en particular) a un nombre de usuario, un nombre de grupo, un id de proceso y otra información interesante. La configuración por defecto de la mayoría de las distribuciones es que el identd está activado (es elegante ejecutarlo, los servidores de irc y las versiones más recientes de sendmail comprueban las respuestas de identd), y sólo distribuirán el nombre de usuario. El uso principal del identd es permitir a los sistemas remotos algún tipo de forma de seguir la pista de los usuarios que se están conectando a sus servidores, irc, telnet, correo, u otros, por propósitos de autentificación (no es una buena idea, ya que es muy fácil de falsear). La universidad local de Edmonton requiere que se ejecute el identd si se quiere hacer un telnet a cualquiera de los servidores de shell, principalmente de forma que puedan seguir con rapidez la pista de las cuentas comprometidas.
Ejecutar el identd en tu máquina ayudará a otros administradores a la hora de hacer el seguimiento de problemas, puesto que no sólo consiguen la dirección IP y la hora del problema, sino que utilizando identd pueden averiguar el nombre del usuario. Esta forma es una espada de doble filo, mientras que proporciona información útil para seguir a usuarios maliciosos (definitivamente la gente a la que se quiere mantener alejada de los servidores) también se puede utilizar para conseguir información de los usuarios del sistema, lo cual dé como resultado que sus cuentas sean comprometidas. Ejecutar identd en los servidores sólo tiene sentido si están albergando cuentas de shell.
Identd soporta bastantes características, y se puede configurar con sencillez para que se ejecute como usuario no-root. Dependiendo de las políticas de seguridad, se puede querer o no dar mucha información, o se puede querer informar lo máximo posible. Simplemente activa la opción en inetd.conf, después en in.identd (las configuraciones por defecto son –l –e –o).
-p port
-a address
Se puede utilizar para especificar a qué puerto y en qué dirección se enlaza (en el caso de una máquina con IP's en forma de alias, o a múltiples interfaces), generalmente sólo es útil si se quiere que conecten máquinas internas, puesto que a las máquinas externas probablemente no les sea posible imaginarse a qué puerto se cambió.
-u uid
-g gid
Se utilizan para configurar el usuario y el grupo bajo el que el identd tendrá privilegios después de conectar al puerto, lo cual da como resultado el ser menos susceptible de comprometer la seguridad del sistema. En cuanto al manejo de la cantidad de información que proporciona:
-o
Especifica que identd no devuelva el tipo de sistema operativo, decir Copyright © 1999, Kurt Seifried, José Antonio Revilla
simplemente "UNKNOWN" es una muy buena opción.
-n
Hará que identd devuelva números de usuarios (p.ej. su UID) y no el nombre de usuario, lo cual todavía les proporciona suficiente información para ti y para seguir la pista del usuario con facilidad, sin proporcionar valiosas pistas a posibles atacantes.
-N
Permite a los usuarios hacer crear un fichero ~/.noident , lo cual forzará que el identd devuelva "HIDDEN-USER" en lugar de información. Esto les permite a los usuarios la opción de tener un cierto grado de privacidad, pero un usuario malicioso lo utilizará para evadir la identificación.
-F format
Te permite especificar mucha más información que la standard, cualquier cosa desde el nombre y número del usuario hasta el PID real, nombre de comando, ¡y los argumentos dados! Esto sólo lo recomendaría para uso interno, puesto que es
mucha información que los atacantes encontrarían útil.
En general, recomendaría utilizar el identd en servidores con cuentas de usuario shell, o si no deshabilitarlo, principalmente debido al número de ataques de denegación de servicio a los que es susceptible. Ejecutar identd le hará la vida mucho más fácil a otros usuarios a la hora de seguir pistas provenientes de tu sitio, algunas con mejoras de seguridad (no lo aseguro todavía pues aún no he podido comprobarlo):
http://insecurity.net/ - El identd seguro de Paul, escrito en Perl
http://www.ojnk.un/~odin/ - ojnk identd
http://www.tildeslash.org/nullidentd.html - null identd
http://www.ajk.tele.fi/~too/sw/ - identd falso
http://p8ur.op.het.net/midentd/ - midentd
http://www.nyct.net/~defile/programs/ident2/ - ident2
Identd se ejecuta en el puerto 113 utilizando tcp, y por lo general sólo se necesitará si que quiere hacer IRC (muchas redes irc requieren una respuesta identd), o ser amable con los sistemas ejecutando demonios (tales como tcp_wrapped telnet, o sendmail) que hagan revisiones identd en las conexiones.
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 113
ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 113
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 113
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 113
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 113
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 113
NTPD
El NTP (Protocolo de Red de Tiempo, Network Time Protocol) es bastante simple en cuanto a su misión, mantiene sincronizados los relojes de los ordenadores. ¿Y qué? Intenta comparar ficheros de log desde 3 servidores separados si sus
relojes están fuera de sincronismo por unos cuantos minutos. El NTP funciona simplemente mediante un cliente que se conecta a un servidor de tiempo, averiguando el retraso entre ellos (en una red de área local podría ser de sólo
1-2ms, a través de internet puede ser de varios cientos de ms), y después pregunta la hora y configura el reloj propio. Además, los servidores se pueden colocar en "cluster" para mantenerse sincronizados entre ellos, las posibilidades de que 3 o más servidores pierdan la pista de la hora que es (también llamado "deriva", "drift" ) es relativamente baja.
Habitualmente, la señal de tiempo se suele generar por un reloj atómico o una señal GPS, medida por un ordenador, estos son los servidores "stratum 1", más abajo se indican servidores de tiempo "stratum 2" que se encuentran generalmente abiertos al público, una compañía podría mantener sus propios servidores de tiempo "stratum 3" si es lo suficientemente necesario, etcétera.
Los datos que intercambia el NTP por supuesto que no son sensibles, es una señal de tiempo, sin embargo, si a un atacante le fuese posible interferirla, podrían ocurrir todo tipo de cosas desagradables: los ficheros de log se podrían volver inutilizables, las cuentas podrían expirar antes de tiempo, los trabajos del cron que hacen la copia de seguridad del servidor se podrían ejecutar en hora punta causando retrasos, etc. De modo que es una buena idea ejecutar tu propio servidor de tiempo y configurar el ajuste máximo que harán a sólo unos pocos segundos (en cualquier caso, tampoco deberían derivar mucho más). Si se es realmente paranoico, o se tiene un gran número de clientes, habría que considerar comprar una unidad de tiempo GPS.
Vienen de todo tipo de formas y tamaños, desde un rack de 1Unidad que se enchufa directamente a la LAN hasta tarjetas ISA o PCI que se conectan en un servidor y tienen una antena. Es una buena idea filtrar con el cortafuegos el servidor de tiempo, puesto que podrían darse ataques de negación de servicio en detrimento de la red. Además de esto, si es posible, utilizar el cifrado disponible en ntpd, basada en DES, suele ser suficiente para desalentar a la mayoría de atacantes. El NTP se encuentra disponible en: http://www.eecis.udel.edu/~ntp/. Generalmente, ntpd o xntpd no suelen traer páginas de manual (genial, eh?) pero se puede encontrar documentación en /usr/doc/ntp-xxx/, o en:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/index.htm.
NTP se ejecuta en el
puerto 123 utilizando udp y tcp, de modo que filtrarlo con el cortafuegos es relativamente sencillo:
ipfwadm –I –a accept –P udp –S 10.0.0.0/8 –D 0.0.0.0/0 123
ipfwadm –I –a accept –P udp –S un.host.fiable –D 0.0.0.0/0 123
ipfwadm –I –a deny –P udp –S 0.0.0.0/0 –D 0.0.0.0/0 123
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 123
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 123
o
ipchains –A input –p udp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 123
ipchains –A input –p udp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 123
ipchains –A input –p udp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 123
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 123
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 123
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/123
CVS
CVS permite trabajar juntos a múltiples desarrolladores en proyectos con enorme cantidad de código fuente, y mantiene una gran base de código en alguna parte de forma limpia. Los mecanismos internos de seguridad del CVS son bastante
simples por sí mismos; de hecho, si alguien dijera que son débiles, le tendría que dar la razón. La autentificación del CVS se suele conseguir a través de la red, utilizando pserver, los nombres de usuario se envían en texto claro, y las contraseñas tienen un hash trivial (en realidad no existe seguridad).
Para evitar esto, se cuenta con varias opciones buenas. En un entorno Unix, probablemente el método más simple sea utilizar SSH para pasar las conexiones por un túnel entre las máquinas clientes y el servidor. "Tim el PierdeTiempo" (Tim Hemel) ha escrito una excelente página ocupándose de esto, disponible en:
http://cuba.xs4all.nl/~tim/scvs/. Una aproximación algo más complicada (pero a la larga mejor en cuanto a grandes instalaciones) es "kerberizar" el servidor CVS y los clientes.
Las redes grandes (especialmente en entornos universitarios) ya han establecido una infraestructura con Kerberos. Detalles en la "kerberización" del CVS disponibles en: http://www.cyclic.com/cyclic-pages/security.html. Aparte de que
recomendaría encarecidamente filtrar con el cortafuegos el CVS, a menos que se esté utilizando para cualquier tipo de propósito público (como un proyecto de código abierto a través de Internet).
Otra herramienta que acaba de aparecer para asegurar CVS es "cvsd", un wrapper para pserver que hace chroot y/o suid el pserver al de un usuario no dañino.
cvsd se encuentra disponible en: http://cblack.mokey.com/cvsd/ en formato rpm y en tarball fuente.
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 2401
ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 2401
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 2401
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 2401
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 2401
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 2401
rsync
El rsync es un método extremadamente eficiente para hacer mirroring de ficheros, ya sea de ficheros de código desde un árbol CVS, un sitio web, o incluso este documento. rsync mantiene los permisos de ficheros, enlaces, hora de los ficheros y más. Además de esto, soporta modo anónimo (lo cual por cierto, utilizo para hacer el mirroring de este documento) lo cual hace la vida muy sencilla en lo concerniente.
El programa rsync puede actuar por sí mismo como cliente (se ejecuta desde una línea de comandos o un script) y como servidor (generalmente se ejecuta desde inetd.conf). El programa en sí es bastante seguro: no requiere privilegios de root para ejecutarse como cliente ni como servidor (aunque se puede hacer si se quiere) y se puede hacer chroot a sí mismo en el directorio raíz o cualquiera que esté siendo hecho mirror (sin embargo esto requiere privilegios de root y puede ser más peligroso de lo que merezca la pena).
También se puede mapear el id del usuario y el id del grupo con acceso al sistema (por defecto, es nobody para la mayoría de los paquetes de rsync precompilados y probablemente sea la mejor elección). En modo no-anónimo, rsync soporta nombres de usuarios y contraseñas que se cifran fuertemente utilizando MD4 de 128 bit. La página del manual "man rsyncd.conf" cubre claramente la configuración de un servidor rsync y lo hace relativamente seguro. El fichero de configuración por defecto es /etc/rsyncd.conf. Tiene una sección global y sección modular (básicamente cada directorio compartido es un módulo):
ejemplo de rsyncd.conf
motd file = /etc/rsync.motd # Especifica fichero a mostrar
etcmax connections = 5 # número máximo de conexiones, para evitar saturación
[pub-ftp]
comment = public ftp area # comentario simple
path = /home/ftp/pub # path al directorio exportado
read only = yes # hacerlo de sólo lectura, para directorios exportados
chroot = yes # chroot a /home/ftp/pub
uid = nobody # configurar explícitamente el UID
gid = nobody # configurar explícitamente el GID
[asuntos-secretos]
comment = mis asuntos secretos
path = /home/user/secretos # path a mis secretos
list = no # ocultar este módulo cuando pidan una lista
secrets file = /etc/rsync.users # fichero de contraseñas
auth users = me, bob, santa # lista de usuarios a los que se permite ver mis
secretos
hosts allow = 1.1.1.1, 2.2.2.2 # lista de hosts permitidos
Como se puede ver, el rsync es bastante configurable, y generalmente es
bastante seguro, excepción hecha de que las transiciones de ficheros no van
cifradas de ninguna forma. Si se necesita seguridad, sugeriría utilizar el SSH
para abrir una conexión mediante un túnel, o alguna solución VPN como
FreeS/WAN. Igualmente asegúrate de estar ejecutando rsync 2.3.x o una versión
más alta, ya que se encontró un compromiso de root en la 2.2.x. Rsync se
encuentra disponible en: http://rsync.samba.org/. Rsync se ejecuta en el puerto
873, tcp.
ipfwadm –I –a accept –P tcp –S 10.0.0.0/8 –D 0.0.0.0/0 873
ipfwadm –I –a accept –P tcp –S un.host.fiable –D 0.0.0.0/0 873
ipfwadm –I –a deny –P tcp –S 0.0.0.0/0 –D 0.0.0.0/0 873
o
ipchains –A input –p tcp –j ACCEPT –s 10.0.0.0/8 –d 0.0.0.0/0 873
ipchains –A input –p tcp –j ACCEPT –s un.host.fiable –d 0.0.0.0/0 873
ipchains –A input –p tcp –j DENY –s 0.0.0.0/0 –d 0.0.0.0/0 873
GEOTOOLBAR el contador útil
El Mundo de Ubuntu en las Redes Sociales
Espero que esta publicación te haya gustado. Si tienes alguna duda, consulta o quieras complementar este post, no dudes en escribir en la zona de comentarios. También puedes visitar Facebook, Twitter, Google +, Linkedin, Instagram, Pinterest, restantes Redes Sociales y Feedly donde encontrarás información complementaria a este blog. COMPARTE EN!