Capitulos de este wiki
  1. 1 Introducción y conceptos previos
  2. 2 Sobre la seguridad
  3. 3 Sobre las redes
  4. 4 Seguridad física de los sistemas
  5. 5 Protección del hardware
  6. 6 Protección de los datos
  7. 7 Radiaciones electromagnéticas
  8. 8 Administradores, usuarios y personal
  9. 9 Ataques potenciales
  10. 10 Qué hacer ante estos problemas
  11. 11 El atacante interno
  12. 12 El sistema de ficheros
  13. 13 Sistemas de ficheros
  14. 14 Permisos de un archivo
  15. 15 Los bits SUID, SGID y sticky
  16. 16 Atributos de un archivo
  17. 17 Listas de control de acceso: ACLs
  18. 18 Recuperación de datos
  19. 19 Almacenamiento seguro
  20. 20 Programas seguros, inseguros y nocivos
  21. 21 La base fiable de cómputo
  22. 22 Errores en los programas
  23. 23 Fauna y otras amenazas
  24. 24 Programación segura
  25. 25 Auditoría del sistema
  26. 26 El sistema de log en Unix
  27. 27 El demonio syslogd
  28. 28 Algunos archivos de log
  29. 29 Logs remotos
  30. 30 Registros físicos
  31. 31 Copias de seguridad
  32. 32 Dispositivos de almacenamiento
  33. 33 Algunas órdenes para realizar copias de seguridad
  34. 34 Políticas de copias de seguridad
  35. 35 Autenticación de usuarios
  36. 36 Sistemas basados en algo conocido: contraseñas
  37. 37 Sistemas basados en algo poseído: tarjetas inteligentes
  38. 38 Sistemas de autenticación biométrica
  39. 39 Autenticación de usuarios en Unix: autenticación clasi
  40. 40 Autenticación de usuarios en Unix: mejora de la seguridad (II)
  41. 41 Pam
  42. 42 Solaris
  43. 43 Seguridad física en SPARC
  44. 44 Servicios de red
  45. 45 Usuarios y accesos al sistema
  46. 46 El sistema de parcheado
  47. 47 Extensiones de la seguridad
  48. 48 El subsistema de red
  49. 49 Parametros del núcleo
  50. 50 Linux
  51. 51 Seguridad física en x86
  52. 52 Usuarios y accesos al sistema
  53. 53 El sistema de parcheado
  54. 54 El subsistema de red
  55. 55 El núcleo de Linux
  56. 56 Aix
  57. 57 Seguridad física en RS/6000
  58. 58 Servicios de red
  59. 59 Usuarios y accesos al sistema (I)
  60. 60 Usuarios y accesos al sistema (II)
  61. 61 El sistema de log
  62. 62 El sistema de parcheado
  63. 63 Extensiones de la seguridad: filtros IP
  64. 64 El subsistema de red
  65. 65 Hp-ux
  66. 66 Seguridad física en PA-RISC
  67. 67 Usuarios y accesos al sistema
  68. 68 El sistema de parcheado
  69. 69 Extensiones de la seguridad
  70. 70 El subsistema de red
  71. 71 El núcleo de HP-UX
  72. 72 Seguridad de la subred: el sistema de red
  73. 73 Algunos ficheros importantes
  74. 74 Algunas órdenes importantes
  75. 75 Servicios
  76. 76 Algunos servicios y protocolos
  77. 77 Servicios basicos de red
  78. 78 El servicio FTP
  79. 79 El servicio TELNET
  80. 80 El servicio SMTP
  81. 81 Servidores WWW
  82. 82 Los servicios r-
  83. 83 XWindow
  84. 84 Cortafuegos: Conceptos teóricos
  85. 85 Características de diseño
  86. 86 Componentes de un cortafuegos
  87. 87 Arquitecturas de cortafuegos
  88. 88 Firewall-1
  89. 89 Ipfwadm/ipchains/iptables
  90. 90 IPFilter
  91. 91 PIX Firewall (I)
  92. 92 PIX Firewall (II)
  93. 93 Escaneos de puertos
  94. 94 Spoofing
  95. 95 Negaciones de servicio
  96. 96 Interceptación
  97. 97 Ataques a aplicaciones
  98. 98 Sistemas de detección de intrusos
  99. 99 Clasificación de los IDSes
  100. 100 Requisitos de un IDS
  101. 101 IDSes basados en maquina
  102. 102 IDSes basados en red
  103. 103 Detección de anomalías
  104. 104 Detección de usos indebidos
  105. 105 Implementación real de un IDS (I)
  106. 106 Implementación real de un IDS (II)
  107. 107 Algunas reflexiones
  108. 108 Kerberos
  109. 109 Arquitectura de Kerberos
  110. 110 Autenticación
  111. 111 Problemas de Kerberos
  112. 112 Criptología
  113. 113 Criptosistemas
  114. 114 Clasificación de los criptosistemas
  115. 115 Criptografía clasica
  116. 116 Un criptosistema de clave secreta: DES
  117. 117 Criptosistemas de clave pública
  118. 118 Funciones resumen
  119. 119 Esteganografía
  120. 120 Algunas herramientas de seguridad
  121. 121 Titan (I)
  122. 122 Titan (II)
  123. 123 TCP Wrappers
  124. 124 Ssh
  125. 125 Tripwire
  126. 126 Nessus
  127. 127 Crack
  128. 128 Gestión de la seguridad
  129. 129 Políticas de seguridad
  130. 130 Analisis de riesgos
  131. 131 Estrategias de respuesta
  132. 132 Outsourcing
  133. 133 El "Área de Seguridad"
  134. 134 Apéndice 1: Seguridad basica para administradores (I)
  135. 135 Apéndice 1: Seguridad basica para administradores (II)
  136. 136 Apéndice 2: Normativa (I)
  137. 137 Apéndice 2: Normativa (II)
  138. 138 Apéndice 2: Normativa (III)
  139. 139 Apéndice 2: Normativa (IV)
  140. 140 Recursos de interés en INet
  141. 141 Glosario de términos anglosajones
  142. 142 Conclusiones
  143. 143 Bibliografía (I)
  144. 144 Bibliografía (II)
  145. 145 Bibliografía (III)
  146. 146 Bibliografía (IV)
  147. 147 Bibliografía (V)

Seguridad en Unix y redes - El servicio TELNET

79 - El servicio TELNET

[editar]
Tutorial creado por Antonio Villalón Huerta. Extraido de: http://es.tldp.org/Manuales-LuCAS/doc-unixsec/unixsec-html/
28 de Febrero de 2006
El protocolo TELNET (TCP, puerto 23) permite utilizar una máquina como terminal virtual de otra a través de la red, de forma que se crea un canal virtual de comunicaciones similar - pero mucho más inseguro - a utilizar una terminal físicamente conectada a un servidor; la idea es sencilla: estamos accediendo remotamente en modo texto a un equipo - en principio potente - igual que si estuviéramos utilizando su consola o una de sus terminales físicas, lo que nos permite aprovechar toda su potencia de cálculo si necesidad de desplazarnos hasta la ubicación de ese servidor, sino trabajando cómodamente desde nuestro propio equipo.
TELNET es el clásico servicio que hasta hace unos años no se solía deshabilitar nunca: no es habitual adquirir una potente máquina corriendo Unix y permitir que sólo se trabaje en ella desde su consola; lo más normal es que este servicio esté disponible para que los usuarios puedan trabajar remotamente, al menos desde un conjunto de máquinas determinado. Evidentemente, reducir al mínimo imprescindible el conjunto de sistemas desde donde es posible la conexión es una primera medida de seguridad; no obstante, no suele ser suficiente: recordemos que TELNET no utiliza ningún tipo de cifrado, por lo que todo el tráfico entre equipos se realiza en texto claro. Cualquier atacante con un analizador de red (o un vulgar sniffer) puede capturar el login y el password utilizados en una conexión; el sniffing siempre es peligroso, pero más aún en sesiones TELNET en las que transmitimos nombres de usuarios y contraseñas: estamos otorgando a cualquiera que lea esos datos un acceso total a la máquina destino, bajo nuestra identidad. Por tanto, es muy recomendable no utilizar TELNET para conexiones remotas, sino sustituirlo por aplicaciones equivalentes pero que utilicen cifrado para la transmisión de datos: SSH o SSL-Telnet son las más comunes. En estos casos necesitamos además de la parte cliente en nuestro equipo, la parte servidora en la máquina remota escuchando en un puerto determinado.
Aparte del problema de los atacantes esnifando claves, los demonios telnetd han sido también una fuente clásica de problemas de programación (se puede encontrar un excelente repaso a algunos de ellos en el capítulo 29 de [Ano97]); básicamente, cualquier versión de este demonio que no esté actualizada es una potencial fuente de problemas, por lo que conviene conseguir la última versión de telnetd para nuestro Unix particular, especialmente si aún tenemos una versión anterior a 1997. Otros problemas, como la posibilidad de que un atacante consiga recuperar una sesión que no ha sido cerrada correctamente, el uso de telnet para determinar qué puertos de un host están abiertos, o la utilización del servicio telnet (junto a otros, como FTP) para averiguar el clon de Unix concreto (versión de kernel incluida) que un servidor utiliza, también han hecho famosa la inseguridad de este servicio.
Antes hemos hablado de la configuración de un entorno restringido para usuarios FTP invitados, que accedían mediante su login y su contraseña pero que no veían la totalidad del sistema de ficheros de nuestra máquina. Es posible - aunque ni de lejos tan habitual - hacer algo parecido con ciertos usuarios interactivos, usuarios que conectarán al sistema mediante telnet utilizando también su login y su password, pero que no verán el sistema de ficheros completo: sólo la parte que a nosotros nos interese (en principio).
Para que un usuario acceda mediante telnet a un entorno restringido con chroot() necesitamos en primer lugar un entorno parecido al que hemos visto antes: a partir de su directorio $HOME, una serie de subdirectorios bin/, lib/, etc/...Dentro de este último existirá al menos un fichero group y otro passwd (igual que sucedía antes, no se usan con propósitos de autenticación, por lo que no es necesario - ni recomendable - que existan claves reales en ninguno de ellos). En el directorio bin/ incluiremos los ejecutables que queremos que nuestro usuario pueda ejecutar, y en lib/ (o usr/lib/) las librerías que necesiten; si usamos el shellscript anterior - de nuevo, con alguna pequeña modificación - para crear este entorno, en la variable $PROGS podemos definir tales ejecutables para que automáticamente se copien junto a las librerías necesarias en el directorio correspondiente:
PROGS="/bin/ls /bin/sh"

Finalmente, en el archivo /etc/passwd real hemos de definir un shell para el usuario como el siguiente:

luisa:~# cat /home/toni/prog/shell.c #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <pwd.h> #define SHELL "/bin/sh" int main(){ struct passwd *entry=(struct passwd *)malloc(sizeof(struct passwd)); char *const ARGS[2]={SHELL,NULL}; while((entry=getpwent())->pw_uid!=getuid()); endpwent(); if(chdir(entry->pw_dir)<0) perror("chdir()"); if(chroot(entry->pw_dir)<0) perror("chroot()"); if(setuid(getuid())<0) perror("setuid()"); if(execvp(SHELL,ARGS)<0) perror("execvp()"); No alcanzado return(0); } luisa:~#

Este código, convenientemente compilado, será el
shell real del usuario restringido; como vemos, obtiene el directorio $HOME del mismo, hace un chroot() a él, y ejecuta en este entorno el shell secundario (bin/sh, que realmente será $HOME/bin/sh). Para que el chroot() sea correcto el programa ha de estar setuidado bajo la identidad de root (sólo el superusuario puede realizar esta llamada), con los riesgos que esto implica; al contrario de lo que diría Knuth, yo sólo defiendo que el código anterior funciona, no que sea correcto...o seguro :)
Si tenemos que crear un entorno como este para usuarios interactivos hemos de tener en cuenta ciertas medidas de seguridad relativas a los ejecutables que situemos - o que permitamos situar - en dicho entorno. Para empezar, hemos de evitar a toda costa los ejecutables
setuidados, así como las llamadas mknod(), chmod() o la propia chroot(); además, no debe ser posible obtener privilegios de administrador dentro del entorno restringido, ya que para el root estas restricciones pierden su sentido: no tenemos más que pensar que si un usuario con privilegios de root dentro del entorno es capaz de generar un dispositivo que represente un disco duro, con algo tan sencillo como la utilidad mknod, automáticamente accederá a la totalidad de ese disco, olvidando ya el chroot() y la potencial protección que pueda ofrecernos. Algo similar ocurre con la memoria del sistema, ciertos dispositivos físicos, o estructuras de datos del núcleo: si esto es accesible desde el entorno restringido, es muy probable que nuestra seguridad se vea rota tarde o temprano (más bien temprano). Tampoco es aconsejable permitir la ejecución de compiladores de C o de intérpretes de Perl.
Como hemos dicho, este tipo de entornos es mucho menos habitual que los de FTP, aparte de bastante más peligrosos. Una tarea tan habitual como cambiar la contraseña no es posible - al menos de forma trivial - en este entorno (aunque podríamos modificar el código anterior para que se ofrezca al usuario esta posibilidad antes de situarlo en el entorno restringido). >Y que sucede si necesitamos que el usuario acceda no a un sólo directorio, sino a dos? Las soluciones - al menos las seguras - no son inmediatas.
[editar]

11 opiniones

ff

fff
Configurar Unix

Hola buen articulo, actualmente tengo un problema parecido, en un servidor UNIX (AIX 5.3) tengo unstalado Oracle 10g con algunas bases de datos funcionando, por otro lado tengo un servidor Linux Suse 10 como servidor de Correo, ¿Como hago para configurar las alertas de Oracle y me puedan llegar a mi correo electronico si el suse esta configurado para perir autenticacion y Oracle no tiene esa opcion?¿Es necesario abrir puertos en Suse? ¿tengo que instalar el servicio SMTP en UNIX? ojalá alguien pudiera orientarme, de ANTEMANO MIL GRACIAS. Saludos
Copiar una imagen.

Hola amigos!! yo trabajo con el software unix y necesito como copiar unas imagenes de ese sofware por que estoy trabajando con unos programs. Y no se como copiarlo y tenerlo en un pendrive o tenerlo en pc norma de window. Espero sus respuestas!!.
Unix para todos.

Hola , les dejo una web para analizar y disfrutar * solounix argentina * está diseñado para todas aquellas personas que conozcan de plataformas unix o quieran aprender de unix el sistema operativo por excelencia. Podes bajar manuales de distintos sistemas operativos unix. Recorda que para gozar de este recurso debes registrate. Como usuario registrado podes disfrutar de una cuenta shell gratis
para que puedas probar comandos de unix.
Bueno.

Es informativo pero carece de aspectos puntuales, por ejemplo en el apartado referente al tipo de amenazas: (a) interrupción, (b) interceptación, (c) modificación y (d) fabricación. Enesencia es bueno.
1 2 3 | siguiente >

Tutoriales relacionados con 'Seguridad en Unix y redes'

A lo largo de este trabajo se va a intentar hacer un repaso de los... Más »
Esta guía no es un documento general de seguridad. Esta guía está específicamente orientada a... Más »
Documento con fundamentos teóricos de control de accesos en redes telemáticas; se tratan temas como... Más »
En muchos foros y cosas similares he visto muchas consultas sobre cómo montar servidores de... Más »
Debian es el nombre de una organización dedicada al desarrollo y mantenimiento de sistemas operativos... Más »

Autor y licencia de 'Seguridad en Unix y redes'


Tutorial de Antonio Villalón Huerta. Extraido de: http://es.tldp.org/Manuales-LuCAS/doc-unixsec/unixsec-html/ CopyLeft
Licencia GNU Free Documentation License: http://www.gnu.org/copyleft/
Este contenido ha sido recopilado por el equipo de Wikilearning. Todo el contenido recopilado se ha obtenido respetando y comunicando en nuestro site la licencia de cada fuente.
Wikilearning tiene permiso expreso por escrito de los autores para publicar los contenidos que ha extraído de otras webs, incluyendo su uso comercial.