Información
Actualidad
Aquí encontraras noticias de actualidad sobre Gnu Linux y Open Source.

Además de información sobre la comunidad LiGNUx.
Distribuciones y entornos
Información ordenada sobre los diferenes sistema operativos Gnu Linux y las diferentes opciones de entornos gráficos.
Tutoriales y guías
Todos los pasos e informaciones que puedes desear para tu día a día.
Tutoriales
Tutoriales
Programación
Programación
About Us
Get to know the people behind the code and the mission behind the work
how we handle data
Privacy
Security
Legal

Protección de un sistema GNU/Linux

22 julio, 2016

A very weird pic

Siguiendo con la recopilación de buenas prácticas y consejos, vamos a adentrarnos un poco más al campo de la seguridad, ahora en servidores, estaciones de trabajo, maquinas personales y un poco de criptografía.

Vamos a empezar con algo sencillo configurando algunos archivos de red:

TCP_WRAPPERS

Usar TCP_WRAPPERS hace que el asegurar servidores contra intrusiones externas sea bastante más simple y menos doloroso...
TCP_WRAPPERS se controla desde dos ficheros:

/etc/hosts.allow
/etc/hosts.deny

Primero se comprueba hosts.allow, y las reglas se comprueban desde la primera a la última. Si encuentras una regla que te permita específicamente entrar (E.g., una regla que permita a tu host, dominio, máscara de subred, etc.) te deja conectar al servicio. Si no puedes encontrar ninguna regla que te corresponda en hosts.allow, entonces va a comprobar hosts.deny en busca de una regla que te deniegue la entrada. De nuevo comprueba las reglas de hosts.deny desde la primera a la última, y la primera regla que encuentre que te deniega acceso (E.g., una regla que deshabilite tu host, dominio, máscara de subred, etc.) significa que no te deja entrar. Si tampoco puede encontrar una regla negándote la entrada, entonces por defecto te deja entrar. Si eres paranoico/a como yo, la última regla (o la única regla si se va a utilizar una política por defecto no optimista en cuanto a seguridad) debería ser:

ALL: 0.0.0.0/0.0.0.0

Niega el acceso a TODO. Servicios, lugares, TODO.
O si solamente quieres denegar el acceso al tonto TELNET, solamente configura en host.allow lo siguiente: in.telnetd:

10.0.0.0/255.255.255.0 # permitir acceso desde la red interna de 10.0.0.*

En host.deny:
in.telnetd: 0.0.0.0/0.0.0.0 # denegar acceso a telnetd desde cualquier parte.

Si se deja activado un servicio que no debería figurar en inetd.conf y NO se tiene una política de denegación por defecto, se pueden tener problemas. Es más seguro (y lleva un poco más de trabajo, pero a la larga es menor que tener que
reinstalar el servidor) tener reglas de denegación por defecto para el cortafuegos y TCP_WRAPPERS, de modo que si se olvida algo por accidente, por defecto no tendrá acceso. Si quieres leer aún más abre tu terminal y lee los manuales que no están de adorno: man host.allow y man host.deny

TCP-IP y la linda ARPANET.

El TPC-IP se creó en una época y en una situación donde la seguridad no era algo que importara demasiado. Inicialmente la Arpanet, consistía en unos pocos hosts, todo eran sitios académicos, grandes empresas o gobiernos. Todo el mundo se conocía, y acceder a Internet era un asunto serio. La suite de protocolos TCP-IP es bastante robusta (todavía no ha fallado 😉 , pero desafortunadamente no está prevista para la seguridad (E.g. autentificación, verificación, cifrado, etc.). Hacer spoofing de paquetes, interceptar paquetes, leer la carga de los datos, y demás, es algo bastante fácil en el Internet de hoy en día. Los ataques más
comunes son los ataques de negación de servicio, ya que son los más fáciles de ejecutar y los más difíciles de impedir, seguidos del sniffing de paquetes, escaneo de puertos y otras actividades relacionadas.

Se puede empezar por denegar los datos entrantes que dicen originarse desde tu red o redes, puesto que estos datos son evidentemente falsos.Y para evitar que tus usuarios, u otros que hayan irrumpido en tu red puedan lanzar ataques
falsificados, se deberían bloquear todos los datos salientes que no provengan de tu dirección IP. Si todo en Internet tuviera filtros salientes (es decir, restringir todo el tráfico saliente a aquel que se originase desde las direcciones IP internas), los ataques mediante spoofing serían imposibles, y a la vez sería mucho más fácil tracear el origen de los atacantes.

Cifrado de servicios y datos.

Prácticamente todo el tráfico de red viaja sin cifrar y puede ser leído con facilidad por un atacante. Si alguien revienta una máquina del lado de Internet e instala un sniffer de contraseñas (un sniffer de paquetes básico con un filtro), la red entera puede verse comprometida en unas horas. Esta es una de las razones por las cuales es una buena idea el cifrado del tráfico de datos.

Existen varios mecanismos para cifrar el tráfico de red, en diferentes niveles de la pila de red. Algunos esquemas sólo cifran los datos que se envían (como el correo cifrado con GPG), algunos cifran la sesión (SSL), y algunos cifran la carga de datos de los paquetes como las VPN. Hay algo muy lindo llamado SSL, el SSL cifra los datos a nivel de sesión, de modo que si tu aplicación soporta SSL y el servidor soporta SSL, se está de suerte.

Para que el cifrado sea efectivo, especialmente a gran escala como con IPSec a lo largo de muchos hosts, se necesitan buenas fuentes de datos aleatorios y criptográficamente seguros. En Linux, están el /dev/random y el /dev/urandom, que son buenos pero no siempre fenomenales. Parte de la ecuación está en medir sucesos "aleatorios", manipulando esos datos y después poniéndolo disponible (vía (u)random). Estos sucesos aleatorios incluyen: entrada de teclado y ratón, interrupciones, lecturas de disco, etc.

Copias de seguridad.

tar y gzip. ¿Por qué? Porque al igual que el vi o nano, puedes apostar por el hecho de que cualquier sistema UNIX tendrá tar y gzip. Pueden ser lentos, feos y viejos, pero son una herramienta universal que harán su trabajo. Me he dado cuenta de que con Linux, la instalación de un sistema típico suele llevar entre 15-30 minutos, dependiendo de la velocidad de la red/cdrom, la configuración otros 5-15 minutos (suponiendo que tenga copias de seguridad o que sea muy simple) y la restauración de datos lleva lo que lleva (definitivamente no es algo en lo que uno debería apresurarse). Un buen ejemplo: recientemente hice una copia de seguridad de un servidor y acto seguido procedí a cargarme el sistema de ficheros (y eliminar físicamente 2 discos duros que ya no necesitaba), después instalé Debian  y reconfiguré 3 tarjetas de red, Apache (para cerca de 10 sitios virtuales) y algunos otros servicios en 15 minutos. (Ojo que lo hice por diversión/investigación que no soy SysAdmin ni trabajo en esto)

De regalo unos consejos sobre ataques.

Enfrentarse con un ataque depende de diferentes factores, ¿el ataque está en progreso? ¿Has descubierto que el plan de tu empresa se está enviando por el servidor de correo a una dirección de GMail? ¿Te han llamado para localizar un servidor o un cluster muertos? ¿Cuáles son tus prioridades? ¿Restaurar el servicio? ¿Asegurar que los datos confidenciales están a salvo? ¿Perseguir
al/los atacante(s)? Varias cosas a tener en cuenta:

  1. La respuesta del administrador dependerá del entorno en que está. El atacante puede haber comprometido las cuentas administrativas, de forma que enviar correo puede no funcionar.
  2. La mayoría de los sitios no quiere dar publicidad de sus ataques (ya sean exitosos o no), debido a problemas relativos
    a las relaciones públicas.
  3. La mayoría de los ataques rápidos, ataques de negación de servicio y similares, están falseados. Llegar hasta el atacante es muy difícil y consume muchos recursos.
  4. Incluso si todo va bien, existe una posibilidad de que la policía (Puede ser el FBI o la NSA!) confisquen tu equipo como prueba, y se queden con él, no es algo que se deba tomar a la ligera.
  5. ¿Sabes cómo entró el atacante? (NFR lo registró) Si es así, quizás prefieras corregir los fallos y dejarlo estar.
  6. No intentes ignorar los ataques, si bien al mismo tiempo ten en cuenta que existe mucha gente ejecutando ataques basura para hacer perder el tiempo y las energías de los administradores (y posiblemente distraerlos de ataques más grandes).

Igualmente, antes de enfrentarse un ataque, tendrías que consultar con la política de la empresa. Si no se dispone de una, consulta con el jefe, el departamento legal, etc. También es una buena idea contar con un plan para tratar los ataques (E.g. el servidor de correo es de prioridad uno, comprobar los servidores de ficheros es prioridad dos, a quién se notifica, etc.) lo cual evitará un montón de problemas a medida que vayan surgiendo (estate preparado).

El libro "Practical Unix and Internet Security". Los ataques DoS (Denial of Service) ya sabes que son, investiga si no lo sabes; Ping flooding, inunda de datos la red, Envenenamiento de caché DNS, algo muy feo.

No hay virus para Linux, dicen por ahí otros blogs mainstream...Los gusanos gozan de una larga y orgullosa tradición en el mundo UNIX, explotando agujeros de seguridad conocidos (generalmente, muy pocos explotan agujeros nuevos/desconocidos) y replicándose pueden exprimir una red. En la actualidad existen diferentes gusanos que están abriéndose paso en máquinas Linux, la mayoría explotando software viejo. Vencerlos es sencillo, como lo es mantener actualizado el software. Haz copias de seguridad de tus datos, formatea y reinstala el sistema desde medios conocidos. Una vez que el atacante consigue root en un sistema Linux, puede hacer literalmente cualquier cosa, desde comprometer el gcc/egcs hasta cargar interesantes módulos del kernel al arrancar. No confíes en el software no fiable como root. Comprueba las firmas PGP de los ficheros que descargas, etc. Un poco de prevención bloqueará la diseminación de virus, gusanos y troyanos bajo GnuLinux.

Escrito por Denisse

Edward Snowden es mi novio <3

Suscribirse
Notificarme las
guest
11 Comentarios
Los más recientes
Los más antiguos Más votados
Feedbacks en línea
Ver todos los comentarios
LiGNUx trabaja sobre una licencia de Creative Commons Reconocimiento 4.0 Internacional.
cloudflagpaperclipprinterfile-emptyfilm-playcamera-videopicturelaptop-phonebriefcasecrossmenu
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram