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 - Sobre las redes

3 - Sobre las redes

[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

Redes `normales'


En este trabajo, como ya hemos comentado, no se pretende ni mucho menos adentrarse en temas de seguridad que se podría considerar `de alto nivel', como la necesaria en un entorno militar2.7, de inteligencia, o en una gran empresa que maneje datos muy apetecibles para sus competidores. Un fallo en la seguridad de los sistemas informáticos de una central nuclear puede ser catastrófico - en el más amplio sentido de la palabra -; un pequeño fallo en los sistemas encargados de lanzar un satélite nos costaría a todos miles de millones de dólares...si en lugar de ser un satélite es un misil, podemos imaginarnos las consecuencias. Por fortuna para todos nosotros, esos sistemas son altamente seguros y por supuesto no son simples ordenadores conectados a Internet...ni siquiera a redes de propósito general.
Pero lo más probable es que todas estas cosas nos queden demasiado lejos a la mayoría de mortales; para nosotros los problemas de seguridad diarios son intrusiones, virus (sin comentarios), negaciones de servicio contra una máquina que sirve páginas web...algo mucho más terrenal que todo lo anterior. Es en este tipo de entornos donde los mecanismos que estudiaremos se pueden aplicar más fácilmente, tanto por las características de los sistemas utilizados como por el - relativamente - bajo peligro de nuestros atacantes: imagino que la CIA o el KGB no estarán dispuestos a pagar a piratas profesionales para que entren y lean nuestro correo; los intrusos potencialmente interesados en nuestras máquinas serán chavales que sólo buscan un cierto status social en un grupo de aficionados a la piratería, o que acaban de ver una película - de cuyo nombre no quiero acordarme - y tratan de emular a los actores. Gente que ante la más mínima dificultad para acceder a nuestra red, la abandonará y se dedicará a objetivos más fáciles (como la red de nuestro vecino). Contra este tipo de personas es contra quien debemos esforzarnos: ya hemos dicho que es inútil intentar parar a un atacante profesional, pagado, o muy interesado en nuestras máquinas; el que su ataque tenga éxito es sólo cuestión de tiempo, y seguramente depende más de la suerte que tenga él frente a la que tengamos nosotros. Pero estos atacantes son minoría, y lo que debemos buscar es defendernos contra la mayoría.
Ejemplos de redes `normales', de entornos con unos requerimientos de seguridad medios (pero requerimientos, al fin y al cabo), son las redes de I+D (universidades, centros de investigación...), las de empresas medianas y las de proveedores de acceso a Internet; vamos a hablar en este punto de las características de cada una de ellas.

Redes de I+D

En cualquier tipo de red, basada en Unix o no, la seguridad es siempre un factor a tener en cuenta a la hora de administrar la propia red y sus máquinas. Por supuesto las redes de I+D no son ninguna excepción, y aunque con demasiada frecuencia su seguridad es mínima - o ni siquiera existe - merece la pena invertir tiempo, y por qué no, dinero, para garantizar un mínimo nivel de seguridad que proporcione un entorno de trabajo aceptable.
Las redes de I+D tienen unas características propias que no poseen otras redes, por ejemplo las militares o las pertenecientes a empresas. El rasgo diferenciador de redes I+D más importante es su carácter extremadamente abierto: mientras que una empresa puede limitar el acceso exterior a través de un simple firewall, u ofrecer sólo determinados servicios al exterior de la empresa, como unas páginas web, una red de I+D no puede permitirse este carácter tan cerrado. Esto es debido a que el aspecto de la seguridad más importante en las redes de investigación es la disponibilidad: a todo el personal investigador le interesa que sus publicaciones sean lo más accesibles a través de la web, al alumnado le interesa poder consultar sus datos académicos desde casa, por Internet, etc. Y es muy difícil hacerles cambiar de opinión, o al menos concienciarlos de los problemas de seguridad que una excesiva apertura supone: si un profesor acude a una conferencia en cualquier lugar del mundo no se le puede obligar, por ejemplo, a kerberizar todas las aplicaciones de su ordenador portátil simplemente para poder leer el correo a distancia; simplemente desea ejecutar un telnet, igual que si estuviera en el campus, para hacerlo.
La característica que acabamos de comentar es algo muy negativo de cara a mantener la seguridad de los sistemas; no podemos limitarnos a establecer una férrea política de filtrado de paquetes o a restringir servicios, ya que los usuarios no van a aceptarlo. Sin embargo, no todas las características de las redes de I+D son un problema para su seguridad; por ejemplo, un importante punto a favor es el escaso interés para un pirata de los datos con los que se trabaja generalmente en institutos de investigación o centros universitarios. En entornos de estas características no se suele trabajar con datos que impliquen información valiosa para un espía industrial o militar, ni tampoco se mueven grandes cantidades de dinero a través del comercio electrónico; casi todo lo que un intruso va a encontrar en una máquina de I+D son programas, documentos, resultados de simulaciones...que a muy poca gente, aparte de sus autores, interesan.
Entonces, >contra quién nos enfrentamos? Muy pocos de los intrusos que podamos encontrar en redes de I+D son piratas expertos; la mayoría son gente poco experimentada, que incluso ataca nuestras máquinas desde sus PCs en casa corriendo MS-DOS (desde 6.2 hasta 2000) sin saber nada sobre Unix o redes. La mejor defensa contra estos individuos consiste simplemente en cerrar los servicios que no sean estrictamente necesarios y mantener actualizado el software de nuestras máquinas que se pueda considerar crítico (núcleo, demonios, ficheros setuidados...). Casi todos ellos suelen actuar movidos únicamente por el afán de conseguir un cierto status en comunidades virtuales de piratas; ni siquiera actúan por curiosidad o para ampliar sus conocimientos, con lo que tenemos una importante ventaja contra ellos: es muy raro - pero no imposible - que se obsesionen por nuestra red o sus máquinas, de forma que si conseguimos que sus primeros intentos por acceder no sean fructíferos directamente dejarán el ataque para dedicarse a objetivos más fáciles. En cuanto a los piratas con un mayor nivel de conocimientos, si los encontramos en una red de I+D seguramente será porque utilizan nuestros equipos como plataforma para atacar servidores `más interesantes' para un intruso, como máquinas militares o de centros de investigación muy importantes, como la NASA; en estos casos es obligatorio poner sobre aviso al organismo de mayor nivel responsable de la seguridad en la red: este organismo es, en el caso de la red universitaria española, IrisCERT, cuya información de contacto se cita al final del proyecto junto a la de otros organismos relacionados con la seguridad informática a distintos niveles.
Empresas

Las redes y sistemas pertenecientes a empresas son, a priori, las que mayores ventajas presentan en lo relativo a su protección; en primer lugar, se trata de redes que suelen ser muy aislables: muchas empresas disponen de una LAN en el edificio donde están ubicadas, red que se puede aislar perfectamente del exterior mediante cortafuegos. Incluso si se han de ofrecer servicios hacia el exterior (típicamente, correo electrónico y web), se pueden situar los servidores en una zona desmilitarizada entre el router y la red interna. Además, en muchos casos la LAN de la empresa ni siquiera es realmente necesario que esté conectada a Internet, aunque esto cada día es menos habitual más por requisitos humanos que técnicos: aunque no haga falta para el trabajo la conexión a Internet, el clima de descontento entre nuestro personal que puede suponer bloquear el acceso hacia el exterior es una gran traba de cara al aislamiento - y por tanto, a la seguridad -.
Esta es la teoría; como siempre, casi perfecta: vamos a añadirle problemas reales para comprobar que las cosas no son tan bonitas como las acabamos de pintar. En primer lugar: imaginemos una empresa con varias sucursales - oficinas, almacenes...- separadas geográficamente. Si la distancia entre todas ellas es corta y la empresa solvente, quizás se puedan permitir una red propia, dedicada, y protegida por los técnicos de la propia compañía; pero esto rara vez es así: conforme aumenta la separación, la idea de la red dedicada se va difuminando (simplemente con una distancia de un par de kilómetros - o menos, dependiendo de la zona - ya resulta imposible esta aproximación). Ahora entra en juego una red de propósito general como base de comunicaciones, seguramente la red telefónica, o incluso Internet; la protección de la red ya no depende exclusivamente de nuestra organización, sino que entran en juego terceras compañías - posiblemente Telefónica, con todo lo que ello implica...-. Es casi indispensable recurrir a redes privadas virtuales (Virtual Private Networks, VPN), canales de comunicación seguros dentro de esa red insegura. Al menos podemos mantener comunicaciones seguras entre las diferentes sucursales...pero no todas las compañías recurren a estos mecanismos: realmente, es más fácil utilizar la red de propósito general como si fuera segura, enviando por ella toda la información que queramos intercambiar entre oficinas, sin proteger. Además, la seguridad no suele ser tangible: seguramente nuestro jefe estará más contento si en un día tiene montada la red aunque sea insegura, sin esperar a la configuración de la red privada - evidentemente, más costosa -, aunque a la larga resulte una solución mucho peor.
Compliquemos aún más la seguridad de nuestra compañía: ahora entran en juego estaciones móviles, por ejemplo comerciales con portátiles que deben comunicarse con los equipos fijos, o ejecutivos que al salir de viaje de negocios quieren poder seguir leyendo su correo. Estas estaciones están dando muchos quebraderos de cabeza, tanto a nivel de conectividad como de seguridad...otro potencial problema para nuestra empresa; realmente, no tan potencial: seguramente esa persona que está de viaje acabará conectado su portatil a la línea telefónica de un hotel, y conectando con las máquinas fijas vía módem. Por supuesto, esa persona ni ha oído ni quiere oir hablar de conexiones cifradas: es más fácil un telnet o un rlogin contra el servidor para poder leer el correo; a fin de cuentas, los piratas son algo que sólo existe en las películas...
Hasta ahora todos los ataques contra la empresa eran - en principio - externos; pero imaginemos que uno de nuestros empleados no está contento con su sueldo y decide irse a la competencia. Y no sólo quiere irse, sino que decide llevarse varios documentos confidenciales, documentos a los que ha tenido un fácil acceso simplemente acercándose a una de las impresoras comunes, recogiendo los listados, y fotocopiándolos antes de entregarlos a su dueño. O incluso más fácil: en nuestra empresa los ordenadores de los empleados utilizan Windows 9x, y todos los puestos ofrecen los discos duros como recursos compartidos; a fin de cuentas, así es mucho más fácil el intercambio de información entre empleados. Esa persona, sin ni siquiera levantarse de su puesto de trabajo, tiene acceso a casi toda la información de nuestra empresa...Por cierto, esto no pretende ser un ataque a la seguridad de estos productos (aunque fácilmente podría serlo), sino una realidad que se puede ver en muchísimas empresas, sobre todo pequeñas y medianas.
Como acabamos de ver, ha sido suficiente con plantear un par de situaciones - de lo más normales - para romper toda la idea de seguridad fácil que teníamos al principio; y eso sin plantear problemas más rebuscados: >qué sucede si a una empresa de la competencia le da por sabotear nuestra imagen atacando nuestras páginas web? >y si le interesa leer nuestros e-mails? No hace falta que se trate de una multinacional poderosa dispuesta a contratar piratas profesionales: es suficiente con que el administrador de la red de nuestra competencia tenga unas nociones sobre seguridad...y bastantes ganas de fastidiarnos.
ISPs

Las empresas dedicadas a ofrecer acceso a Internet a través de la línea telefónica, así como otros servicios de red (principalmente, hospedaje de páginas web) son los conocidos ISPs (Internet Service Providers); conocidos tanto por sus servicios como por su inseguridad. Y es que realmente no es fácil compaginar una amplia oferta de servicios con una buena seguridad: cualquier administrador de máquinas Unix sabe que cada puerto abierto en su sistema es una potencial fuente de problemas para el mismo, por lo que conviene reducir al mínimo su número. Si los ISPs viven justamente de permitir accesos - a Internet o a sus propios servidores - parece obvio que no podrán aplicar estrictas políticas de seguridad en las máquinas: mientras que por ejemplo en una empresa el administrador puede obligar - relativamente - a sus usuarios a utilizar protocolos cifrados, si un ISP no permite acceso ftp a los clientes que deseen colgar sus páginas web y les obliga a usar un protocolo de transferencia de archivos que aplique criptografía, es muy probable que muchos de esos clientes abandonen y se vayan a la competencia: es más fácil utilizar el ftp clásico que instalar software adicional para poder actualizar una página web.
Imaginemos un proveedor que ofrece conexión a Internet a sus clientes; sin duda esos clientes querrán conectar a páginas web, hacer IRC, transferir archivos o utilizar telnet. Nada problemático a primera vista: las conexiones se realizan hacia el exterior de nuestra red, no hacia el interior. Pero además esos clientes querrán utilizar ICQ o NetMeeting, querrán instalar servidores de todo tipo en sus máquinas para que sus amigos los utilicen - desde servicios web hasta NFS -, con lo que empiezan los primeros problemas. Y no nos quedamos aquí: seguramente quieren poder descargar su correo POP3 desde cualquier lugar, no sólo desde el rango de direcciones del proveedor (por supuesto, sin oir hablar de cifrado en la conexión) y también les hace gracia un espacio para publicar sus páginas web de forma permanente...y mucho mejor para ellos si se les permite programar e instalar sus propios CGIs en dichas páginas; aquí ya no hay opción: o simplemente se les niega esta última posibilidad, o si se les permite y deseamos un entorno medianamente seguro hemos de dedicar recursos - y no pocos - a verificar la seguridad de esos programas. Hagamos lo que hagamos, tenemos problemas: si no permitimos que los usuarios usen sus propios CGIs, y otro proveedor sí que lo permite, seguramente cambiarán de ISP...si revisamos la seguridad, tampoco les va a hacer gracia tener que modificar su programa una y otra vez hasta que lo consideremos seguro; a fin de cuentas, estarán modificándolo para conseguir algo que probablemente ni siquiera entiendan.
Sigamos añadiendo problemas: puestos a pedir, los usuarios también pueden pedir acceso a bases de datos en sus páginas, por ejemplo vía PHP3; ya nos afectan los problemas que pueda tener este tipo de software. Incluso pueden querer instalar sistemas completos de comercio electrónico, sistemas capaces de convertir nuestra red en un auténtico agujero. Es más, si permitimos hospedaje de máquinas es muy probable que el cliente que usa este servicio quiera acceder remotamente vía telnet - o peor, rlogin-, incluso para tareas de administración; ni oir hablar de cosas como SSH o SSL Telnet: a fin de cuentas, hacen lo mismo y son más complicados que un sencillo telnet...
La seguridad de los ISPs sufre además el problema clásico de la seguridad en cualquier entorno, pero quizás de una forma mucho más grave: estamos trabajando con algo intangible, con algo muy difícil de ver. Si se realiza una inversión de tiempo o dinero para adquirir equipos nuevos, la mejora se nota inmediatamente; si esa inversión se realiza para incrementar la seguridad, quizás las mejoras obtenidas nunca las pueda notar un usuario. Y si las nota, con toda probabilidad es peor: es porque han fallado. La mayor parte de los potenciales clientes de un ISP preferirá una conexión un poco más rápida frente a una conexión o unos servicios más seguros.
Con situaciones tan sencillas y comunes como las anteriores podemos hacernos una idea de la potencial inseguridad de los ISPs; se trata de problemas reales, no meramente teóricos: en ambientes underground no es raro encontrar piratas con casi todas - o con todas - las claves de los clientes de un proveedor (personalmente he conocido varios casos). Sólo tenemos un punto a nuestro favor, si se puede considerar así: hace un par de años esas claves eran algo más o menos valioso para un pirata, ya que con ellas conseguía un acceso a Internet gratuito y - más importante - si dar ninguno de sus datos. Hoy en día, y debido a empresas que ofrecen ese tipo de acceso - por ejemplo como Alehop, con unas contraseñas genéricas y gratuitas para todo el mundo -, las claves de los clientes de un ISP no son algo tan codiciado.
Seguridad en Unix?

En la década de los ochenta para mucha gente el concepto de seguridad era algo inimaginable en el entorno Unix: la facilidad con que un experto podía acceder a un sistema, burlar todos sus mecanismos de protección y conseguir el máximo nivel de privilegio era algo de sobra conocido por todos, por lo que nadie podía pensar en un sistema Unix seguro.
Afortunadamente, los tiempos han cambiado mucho desde entonces. Aunque en un principio y según uno de sus creadores, Unix no se diseñó para ser seguro ([Rit86]), a finales de los 80 se convirtió en el primer sistema operativo en alcanzar niveles de seguridad quasi militares ([HJAW88], [Ser91]...). En la actualidad se puede considerar el sistema operativo de propósito general más fiable del mercado; desde los clones habituales (Solaris, HP-UX, IRIX...) hasta los `Trusted Unix' (de los que hablaremos a continuación), pasando por los sistemas gratuitos (Linux, FreeBSD...), cualquier entorno Unix puede ofrecer los mecanismos de seguridad suficientes para satisfacer las necesidades de la mayoría de instituciones. Los Unices habituales, como Solaris o Linux, son bastante inseguros tal y como se instalan por defecto (out-of-the-box), como veremos a la hora de hablar de la seguridad lógica; esto significa que requieren de una mínima puesta a punto, en cuanto a seguridad se refiere, antes de ponerlos a trabajar con unas mínimas garantías de fiabilidad. Una vez realizada esta puesta a punto suelen tener una seguridad aceptable en redes de propósito general. El problema es que en muchas ocasiones se pone a trabajar a Unix tal y como se instala por defecto, lo que convierte a cualquier sistema operativo, Unix o no, en un auténtico agujero en cuanto a seguridad se refiere: cuentas sin password o con passwords por defecto, servicios abiertos, sistemas de ficheros susceptibles de ser compartidos...
Dentro de la familia Unix existen una serie de sistemas denominados `Unix seguros' o `Unix fiables' (Trusted Unix); se trata de sistemas con excelentes sistemas de control, evaluados por la National Security Agency (NSA) estadounidense y clasificados en niveles seguros (B o A) según [B+85]. Entre estos Unix seguros podemos encontrar AT&T System V/MLS y OSF/1 (B1), Trusted Xenix2.8 (B2) y XTS-300 STOP 4.1 (B3), considerados los sistemas operativos más seguros del mundo (siempre según la NSA). La gran mayoría de Unices (Solaris, AIX...) están clasificados como C2, y algunos otros, como Linux, se consideran sistemas C2 de facto: al no tener una empresa que pague el proceso de evaluación de la NSA no están catalogados, aunque puedan implementar todos los mecanismos de los sistemas C2.
A la vista de lo comentado en este punto, parece claro que Unix ha dejado de ser ese sistema arcaico e inseguro de sus primeros tiempos para convertirse en el entorno de trabajo más fiable dentro de la gama de sistemas operativos de propósito general; sin embargo, por alguna extraña razón, mucha gente tiende a considerar todavía a los equipos Unix como amenazas en la red, especialmente a los clones gratuitos como Linux o FreeBSD que habitualmente se ejecutan en PCs; el hecho de que sean gratuitos no implica en ningún momento que sean inestables, y mucho menos, inseguros: empresas tan importantes como Yahoo! (www.yahoo.com) o Citroën (www.citroen.com), o el propio servicio postal de Estados Unidos utilizan estos entornos como servidores web o como firewall en sus redes. No obstante, las políticas de marketing de ciertas empresas desarrolladoras tienden a popularizar (y lamentablemente lo consiguen) ideas erróneas sobre la seguridad en Unix, lo que motiva que algunas organizaciones intenten buscar sistemas alternativos, casi siempre sustituyendo máquinas Unix por entornos Windows NT o Windows 9x. No creo que haga falta hacer comentarios sobre la seguridad de estos sistemas, por lo que no entraremos en detalles sobre ella; si alguien está interesado, o duda de la capacidad de Unix frente a estos entornos, puede consultar alguna de las comparativas o de los artículos publicados sobre el tema por universidades o por prestigiosos nombres dentro del mundo de la seguridad informática, o simplemente interesarse por el tipo de sistemas utilizados en centros de investigación como AT&T y la NASA, o en organismos de seguridad como el FBI y la NSA: Unix, por supuesto.
[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.