seguridad 1

Corba

Routing & InternetworkingUnixware

Seguridad & ConectividadSeguridad Bsica Servidor Proxy Firewalls Conectividad Linux Windows Correo Electrnico Ruteo y Encaminamiento IP Configuracin de Routers

Local Apple Talk

Linux PoweRed

Sun Solaris

Microsoft Windows

Novell Netware

Ing. Eduardo A. Aparicio C. CCNP

Seguridad bsica de servicios de redNo se pueden empezar a asegurar servicios hasta que no se sepa qu se est ejecutando. Para este tipo de tareas, ps y netstat no tienen precio; ps dice qu se est ejecutando (httpd, inetd, etc.) y netstat te dir cul es el estado de los puertos (llegados a este punto, estamos interesados en los puertos que estn abiertos y escuchando, es decir, esperando conexiones). Se les puede echar un vistazo a los diferentes ficheros de configuracin que controlan los servicios de red.

Salida de psEl programa ps nos muestra el estado de procesos (informacin disponible en el sistema de ficheros virtual /proc). Las opciones ms comnmente utilizadas son "ps -xau", que muestra algo as como toda la informacin que siempre quisiste saber. Por favor, ten en cuenta: estas opciones cambian entre sistemas Unix, Solaris, SCO, todos se comportan de manera diferente (lo cual es increblemente molesto). Lo que viene a continuacin es una salida tpica de una mquina (utilizando "ps -xau"). USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND bin 320 0.0 0.6 760 380? S Feb 12 0:00 portmap daemon 377 0.0 0.6 784 404? S Feb 12 0:00 /usr/sbin/atd named 2865 0.0 2.1 2120 1368? S 01:14 0:01 /usr/sbin/named -u named -g named t/home/named nobody 346 0.0 18.6 12728 11796? S Feb 12 3:12squid nobody 379 0.0 0.8 1012 544? S Feb 12 0:00 (dnsserver) nobody 380 0.0 0.8 1012 540? S Feb 12 0:00 (dnsserver) nobody 383 0.0 0.6 916 416? S Feb 12 0:00 (dnsserver) nobody 385 0.0 0.8 1192 568? S Feb 12 0:00 /usr/bin/ftpget -S 1030 nobody 392 0.0 0.3 716 240? S Feb 12 0:00 (unlinkd) nobody 1553 0.0 1.8 1932 1200? S Feb 14 0:00 httpd nobody 1703 0.0 1.8 1932 1200? S Feb 14 0:00 httpd root 1 0.0 0.6 776 404? S Feb 12 0:04 init [3] root 2 0.0 0.0 0 0? SW Feb 12 0:00 (kflushd) root 3 0.0 0.0 0 0? SW Feb 12 0:00 (kswapd) root 4 0.0 0.0 0 0? SW Feb 12 0:00 (md_thread) root 64 0.0 0.5 736 348? S Feb 12 0:00 kerneld root 357 0.0 0.6 800 432? S Feb 12 0:05 syslogd root 366 0.0 1.0 1056 684? S Feb 12 0:01 klogd root 393 0.0 0.7 852 472? S Feb 12 0:00 crond root 427 0.0 0.9 1272 592? S Feb 12 0:19 /usr/sbin/sshd root 438 0.0 1.0 1184 672? S Feb 12 0:00 rpc.mountd root 447 0.0 1.0 1180 644? S Feb 12 0:00 rpc.nfsd root 458 0.0 1.0 1072 680? S Feb 12 0:00 /usr/sbin/dhcpd root 489 0.0 1.7 1884 1096? S Feb 12 0:00 httpd root 503 0.0 0.4 724 296 2 S Feb 12 0:00 /sbin/mingetty tty2 root 505 0.0 0.3 720 228? S Feb 12 0:02 update (bdflush) root 541 0.0 0.4 724 296 1 S Feb 12 0:00 /sbin/mingetty tty1 root 1372 0.0 0.6 772 396? S Feb 13 0:00 inetd root 1473 0.0 1.5 1492 1000? S Feb 13 0:00 sendmail: accepting connections on port 25 root 2862 0.0 0.0 188 44? S 01:14 0:00 /usr/sbin/holelogd.named /home/named/dev/log root 3090 0.0 1.9 1864 1232? S 12:16 0:02 /usr/sbin/sshd root 3103 0.0 1.1 1448 728 p1 S 12:16 0:00 su -root 3104 0.0 1.3 1268 864 p1 S 12:16 0:00 -bash root 3136 0.0 1.9 1836 1212? S 12:21 0:04 /usr/sbin/sshd Los interesantes son: portmap, named, Squid (y su servidor dns, los procesos hijos unlinkd y ftpget), httpd, syslogd, sshd, rpc.mountd, rpc.nfsd, dhcpd, inetd, y sendmail (este servidor parece estar proveyendo servicios de puerta de enlace, correo y comparticin de ficheros fns). La forma

Ing. Eduardo A. Aparicio C.

Pgina 2

ms fcil de aprender a leer la salida de ps es irse a la pgina del manual de ps y aprender a qu se refiere cada campo (la mayora se explican por s mismos, tales como el %CPU, mientras que algunos como SIZE son un poco ms oscuros: SIZE es el nmero de pginas de memoria de 4k que est utilizando un programa). Para averiguar qu programas se estn ejecutando, una apuesta segura es hacer man ; lo cual casi siempre suele sacar la pgina del manual que pertenece a ese servicio (como httpd). Te dars cuenta de que servicios como telnet, ftpd, identd y otros no aparecen aunque estn ah. Esto es debido a que se ejecutan desde inetd, el "superservidor". Para encontrar estos servicios, mira en /etc/inetd.conf o en la salida de "netstat vat".

Salida de netstatnetstat informa acerca de casi cualquier cosa que se pueda imaginar relacionada con la red. Es especialmente buena para sacar listados de conexiones y sockets activos. Al usar netstat se puede encontrar qu interfaces estn activas en qu puertos. Lo que viene a continuacin es la salida tpica de un servidor, con netstat an. Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 24.108.11.200:80 205.253.183.122:3661 ESTABLISHED tcp 0 0 0.0.0.0:1036 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 10.0.0.10:53 0.0.0.0:* LISTEN tcp 0 0 28.208.55.254:53 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:635 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN udp 0 0 127.0.0.1:1031 0.0.0.0:* udp 0 0 0.0.0.0:1029 0.0.0.0:* udp 0 0 0.0.0.0:800 0.0.0.0:* udp 0 0 0.0.0.0:1028 0.0.0.0:* udp 0 0 10.0.0.10:53 0.0.0.0:* udp 0 0 28.208.55.254:53 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 10.1.0.1:138 0.0.0.0:* udp 0 0 10.1.0.1:137 0.0.0.0:* udp 0 0 10.0.0.10:138 0.0.0.0:* udp 0 0 10.0.0.10:137 0.0.0.0:* udp 0 0 0.0.0.0:138 0.0.0.0:* udp 0 0 0.0.0.0:137 0.0.0.0:* udp 0 0 0.0.0.0:2049 0.0.0.0:* udp 0 0 0.0.0.0:635 0.0.0.0:* udp 0 0 0.0.0.0:514 0.0.0.0:* udp 0 0 0.0.0.0:111 0.0.0.0:* raw 0 0 0.0.0.0:1 0.0.0.0:* raw 0 0 0.0.0.0:6 0.0.0.0:* En mi opinin la salida numrica es ms fcil de leer (una vez que se memoriza /etc/services). Los campos que nos interesan son el primero, el tipo de servicio, el cuarto campo, que es la direccin


Pgina 3

IP de la interfaz y el puerto, la direccin externa (si no es 0.0.0.0.* significa que alguien le est hablando activamente), y el estado del puerto. La primera lnea es un cliente remoto hablando con el servidor de web de esta mquina (puerto 80). Cuando se ve el servidor www escuchando en 0.0.0.0:80 que significa, todos los interfaces, puerto 80, seguidos del servidor DNS ejecutndose en las 3 interfaces, un servidor samba (139), un servidor de correo (25), un servidor NFS (2049), etc. Observars listado el servidor de ftp (21), que aunque se ejecuta desde inetd, y aunque actualmente no est en uso (p. ej., no hay nadie activo haciendo un ftp), sale en el listado de la salida de netstat. Lo cual convierte a netstat en una herramienta especialmente til para averiguar qu es lo que est activo en una mquina, haciendo ms sencillo el inventariado en el servidor del software activo e inactivo.

isoflsof es un prctico programa cuya idea es similar a la de ps, excepto en que muestra qu ficheros/etc estn abiertos, lo cual puede incluir sockets de red. Desafortunadamente, el lsof medio saca bastante informacin, de modo que ser necesario utilizar grep o redireccionarlo mediante less ("lsof | less") para hacerlo ms cmodo de leer. squid 9726 root 4u inet 78774 TCP localhost:2074->localhost:2073 (ESTABLISHED) squid 9726 root 5u inet 78777 TCP localhost:2076->localhost:2075 (ESTABLISHED) squid 9726 root 6u inet 78780 TCP localhost:2078->localhost:2077 (ESTABLISHED) squid 9726 root 7w CHR 1,3 6205 /dev/null squid 9726 root 14u inet 78789 TCP host1:3128 (LISTEN) squid 9726 root 15u inet 78790 UDP host1:3130 squid 9726 root 16u inet 78791 UDP host1:3130 squid 9726 root 12u inet 167524 TCP host1:3128->host2:3630 (ESTABLISHED) squid 9726 root 17u inet 167528 TCP host1:3424->www.ejemplo.org:http (SYN_SENT) Este ejemplo muestra que se tiene ejecutndose a Squid, escuchando en los puertos 3128 y 3130, las ltimas dos lneas muestran una conexin abierta desde un host interno al servidor de Squid y la accin resultante que ha emprendido Squid para cumplir con la solicitud (ir a www.playboy.com) host1 es el servidor de Squid y host2 es la mquina cliente haciendo la peticin. Es una herramienta que no tiene precio para hacerse una idea exacta de qu es lo que est ocurriendo con tu servidor en la red. Se puede conseguir lsof con algunas distribuciones. Ten en cuenta que las versiones de losf compiladas para las versiones del kernel 2.0.x no funcionarn con el kernel 2.2.x y vice versa, pues hay bastantes cambios. El sitio primario de lsof es: ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/

Seguridad en redLa seguridad de las conexiones en red merecen en la actualidad una atencin especial, incluso por medios de comunicacin no especializados, por el impacto que representan los fallos ante la opinin pblica. El propio desarrollo tanto de Linux, como de la mayora del software que lo acompaa, es de fuentes abiertas. Podemos ver y estudiar el cdigo. Esto tiene la ventaja de que la seguridad en Linux no sea una mera apariencia, sino que el cdigo est siendo escrutado por muchas personas distintas que rpidamente detectan los fallos y los corrigen con una velocidad asombrosa. Si adems comprendemos los mecanismos que se siguen en las conexiones en red, y mantenemos actualizados nuestros programas, podemos tener un nivel de seguridad y una funcionalidad aceptables. Tampoco tienen las mismas necesidades de seguridad un equipo domstico, con conexiones espordicas a Internet, que un servidor conectado permanentemente y que acte como pasarela entre una intranet e Internet. Para describir las pautas de actuacin seguras iremos examinando cmo actan las conexiones y cmo podemos protegerlas.


Pgina 4

inetdPara atender las solicitudes de conexin que llegan a nuestro equipo existe un demonio llamado inetd que est a la escucha de todos los intentos de conexin que se realicen a su mquina. Cuando le llega una solicitud de conexin ir dirigida a un puerto (nmero de servicio, quizs sea ms claro que puerto), por ejemplo, el 80 sera una solicitud al servidor de pginas web, 23 para telnet, 25 para smtp, etc. Los servicios de red que presta su mquina estn descritos en /etc/inetd.conf (y en /etc/services los nmeros de puertos). Por ejemplo, en /etc/inetd.conf podemos encontrar las siguientes lneas: (...) pop3 stream tcp nowait root /usr/sbin/tcpd ipop3d # imap stream tcp nowait root /usr/sbin/tcpd imapd Esto quiere decir que, cuando llegue una solicitud de conexin al puerto 110 (pop3) se ejecutar el programa /usr/sbin/tcpd ipop3d. Sin embargo, el servicio imap est deshabilitado (est comentado con un # delante), por lo que el sistema no le responde.

Tcp wrapperEl siguiente paso es /usr/sbin/tcpd, que es el tcp_wrapper: un servicio que verifica el origen de las conexiones con su base de datos /etc/hosts.allow (equipos autorizados) y /etc/hosts.deny (equipos a los que se les deniega la conexin). tcpd anota todos los intentos de conexin que le llegan en /var/log/secure para que tenga la posibilidad de saber quin intenta conectarse a su mquina y si lo consigue. Si tcpd autoriza la conexin, ejecuta ipop3d que es el programa que realmente atiende la conexin, ante el cual se tiene que validar el usuario mediante una clave. Observe que ya llevamos tres niveles de seguridad: prestar un servicio, autorizar una conexin y validar un usuario. Un consejo que es conveniente seguir: No tenga abiertos los servicios que no necesita; esto supone asumir un riesgo a cambio de nada. Tampoco limite la funcionalidad del sistema, si tiene que usar un servicio, hgalo sabiendo lo que hace. Tambin hay que asegurarse de que el programa ipop3d no tenga ninguna vulnerabilidad, es decir, que est actualizado. Existen numerosos medios para estar al da de las vulnerabilidades que aparecen. Una buena lista de correo o una revista electrnica tal vez sean la forma ms rpida de conocer los incidentes, las causas y las soluciones. Posiblemente la mejor lista de correo para el mundo Unix sea Bugtraq (busque en frums). Pero esto no es todo, adems puede filtrar las conexiones que le lleguen desde el exterior para que ni siquiera alcancen a los tcp_wrappers. Por ejemplo, en el caso de conexiones a Internet por mdem: ipchains -A input -j DENY -s 0/0 -d $4/32 23 -p tcp -i ppp0 l poniendo la anterior lnea en el fichero /etc/ppp/ip-up (y ipchains -F input en ip-down) estaramos aadiendo (-A) un filtro de entrada (input), que deniega (-j DENY) desde cualquier sitio de internet (-s 0/0) dirigidas a nuestro equipo (-d $4/32) al puerto telnet (23) por tcp (-p tcp) que lleguen desde internet (en este caso -i ppp0) y que adems las anote en el registro de incidencias (-l) ($4 es la direccin IP que obtenemos dinmicamente). El mecanismo de filtrado de conexiones se realiza en el ncleo del sistema operativo y si ha sido compilado con estas opciones. Normalmente lo est. Este filtrado se realiza a nivel de red y transporte: cuando llega un paquete por un interfaz de red se analiza siguiendo los filtros de entrada. Este paquete puede ser aceptado, denegado o rechazado, en este ltimo caso se avisa al remitente. Si los filtros de entrada aceptan el paquete, pasa al sistema si era su destino final o pasa por los filtros de reenvo o enmascaramiento, donde se vuelve a repetir una de las acciones. Por ltimo, los paquetes que proceden del propio sistema o los que han sido aceptados por los filtros de reenvo o enmascaramiento pasan al filtro de salida. En cualquiera de estos filtros se puede indicar que lo anote en el registro de incidencias.


Pgina 5

Registro y conocimiento de incidenciasA parte de todo esto, puede conocer las incidencias que ocurren durante el funcionamiento del sistema. Por un lado conviene familiarizarse con los procesos que se ejecutan habitualmente en una mquina. Es una buena costumbre ejecutar peridicamente ps axu. Cualquier cosa extraa debiramos aclararla. Puede matar cualquier proceso con la orden kill -9 pid (o killall -9 nombre_proceso). Pero en caso de ataque activo, lo mejor es desconectar de la red inmediatamente, si es posible, claro est. Despus tenemos los registros de incidencias (las ubicaciones pueden ser diferentes dependiendo del sistema, pero no radicalmente distintas) de /var/log. Trabajando en modo texto se puede hacer en una consola virtual (como root) tail -f /var/log/messages y tail -f /var/log/secure de esta forma podemos ir viendo las incidencias del sistema. Conviene tambin familiarizarse con las anotaciones que aparecen habitualmente para diferenciarlas de las que puedan presentar un problema. En modo grfico hay un programa llamado ktail que le muestra las incidencias de una forma similar a la anterior.

Comunicaciones segurasPor ltimo, nos interesar mantener unas comunicaciones seguras para garantizar la privacidad e integridad de la informacin. Actualmente existen las herramientas necesarias para cada necesidad. Podemos usar cifrados simtricos como pgp y gpg para documentos, correo electrnico y comunicaciones sobre canales inseguros. Podemos crear canales de comunicacin seguros de distinto tipo: SSH (Secure Shell) stelnet: SSH y stelnet son programas que le permiten efectuar conexiones con sistemas remotos y mantener una conexin cifrada. Con esto evitamos, entre otras cosas, que las claves circulen por la red sin cifrar. Cryptographic IP CIPE cifra los datos a nivel de red. El viaje de los paquetes entre hosts se Encapsulation (CIPE): hace cifrado. A diferencia de SSH que cifra los datos por conexin, lo hace a nivel de socket. As una conexin lgica entre programas que se ejecutan en hosts diferentes est cifrada. CIPE se puede usar en tunnelling para crear una Red Virtual Privada. El cifrado a bajo nivel tiene la ventaja de poder hacer trabajar la red de forma transparente entre las dos redes conectadas en la RVP sin ningn cambio en el software de aplicacin. SSL: Secure Sockets Layer, fue diseado y propuesto en 1994 por Netscape Communications Corporation junto con su primera versin del Navigator como un protocolo para dotar de seguridad a las sesiones de navegacin a travs de Internet. Sin embargo, no fue hasta su tercera versin, conocida como SSL v3.0 que alcanz su madurez, superando los problemas de seguridad y las limitaciones de sus predecesores. En su estado actual proporciona los siguientes servicios: a) Cifrado de datos: la informacin transferida, aunque caiga en manos de un atacante, ser indescifrable, garantizando as la confidencialidad. b) Autenticacin de servidores: el usuario puede asegurarse de la identidad del servidor al que se conecta y al que posiblemente enve informacin personal confidencial. c) Integridad de mensajes: se impide que modificaciones intencionadas o accidentales en la informacin mientras viaja por Internet pasen inadvertidas. d) Opcionalmente, autenticacin de cliente: permite al servidor conocer la identidad del usuario, con el fin de decidir si puede acceder a ciertas reas protegidas


Pgina 6

Consejos finalesLimite las acciones que realice como root al mnimo imprescindible, y sobre todo no ejecute programas desconocidos. Por ejemplo, en un juego (el quake) que distribua una revista haba un programa llamado runme que enviaba por mail las caractersticas de la mquina a una direccin de correo. En este caso se trataba de un troyano inofensivo, pero ofrece una idea de lo que puede hacer un programa ejecutado sin saberse lo que hace. Linux tambin tiene la posibilidad de proporcionar acceso transparente a Internet a una red local mediante ip masquerade. En este caso, si usamos direcciones de red privadas, nos aseguramos que los equipos de la red interna no son accesibles desde Internet si no es a travs del equipo Linux. Tambin podemos instalar un servidor proxy con cach, que a la vez que acta de filtro de conexiones a nivel de aplicacin, puede acelerar el acceso a servicios desde la red local.

Servidores proxyUn servidor proxy es en principio un equipo que acta como intermediario entre los equipos de una red de rea local (a veces mediante protocolos, con excepcin del protocolo Tcp/ip) e Internet. Generalmente el servidor proxy se utiliza para la web. Se trata entonces de un proxy http. Sin embargo, puede haber servidores proxy para cada protocolo de aplicacin (ftp, etc).

Principio operativo de un servidor proxyEl principio operativo bsico de un servidor proxy es bastante sencillo: se trata de un servidor que acta como "representante" de una aplicacin efectuando solicitudes en Internet en su lugar. De esta manera, cuando un usuario se conecta a Internet con una aplicacin del cliente configurada para utilizar un servidor proxy, la aplicacin primero se conectar con el servidor proxy y le dar la solicitud. El servidor proxy se conecta entonces al servidor al que la aplicacin del cliente desea conectarse y le enva la solicitud. Despus, el servidor le enva la respuesta al proxy, el cual a su vez la enva a la aplicacin del cliente.

Caractersticas

El proxy combinado con un firewall puede proveerle seguridad a una red local (Lan). La exposicin de la red interna a hackers es menor porque las computadoras no son directamente accesibles desde el otro lado del firewall. El proxy puede funcionar como filtrador de trfico para paquetes de web. Porque toda la informacin pasa con el proxy antes de alcanzar al cliente, puede ser manipulada de maneras tiles. Por ejemplo, el proxy puede leer los paquetes de las peticiones entrantes del http (protocolo usado en www) y botar aquellos procedentes desde host predeterminados.


Pgina 7

Los administradores podran utilizar esta opcin para evitar que los clientes tengan acceso a sitios pornogrficos (obscenos), por ejemplo. El proxy podra tambin reducir el nmero de comerciales desplegados en las pginas de web. Adems, algunas configuraciones permiten el retiro de pop-up windows (ventanitas pop-up) indeseadas. El proxy puede disminuir grandemente el tiempo de acceso para todos los clientes. El servidor proxy economiza ancho de banda de la red, cuando se requiera hacer una consulta directa a la red el canal estar descongestionado. Almacena las pginas ms vistas para optimizar ancho de banda y acelerar la navegacin. Con este se puede controlar sobre los sitios que sus empleados visitan, estableciendo un esquema de usuario y contrasea, que adems de filtrar los contenidos indebidos, le permitir sacar todo tipo de estadsticas por usuario, sitios navegados, kbytes etc.

En lo sucesivo, con la utilizacin de tcp/ip dentro de redes de rea local, la funcin de retransmisin del servidor proxy est directamente asegurada por pasarelas y routers. Sin embargo, los servidores proxy siguen utilizndose ya que cuentan con cierto nmero de funciones que poseen otras caractersticas.

Beneficios Seguridad El proxy combinado con firewall puede proveerle seguridad a una red local (lan). La exposicin de la red interna a hackers es menor porque las computadoras no son directamente accesibles desde el otro lado del firewall.

Administracin Los administradores podran utilizar esta opcin para evitar que los clientes tengan acceso a sitios pornogrficos (obscenos). Se puede reducir el nmero de comerciales desplegados en las pginas de web. Algunas configuraciones permiten el retiro de pop-up windows (ventanitas pop-up) indeseadas. Con este se puede controlar sobre los sitios que sus empleados visitan, estableciendo un esquema de usuario y contrasea, que adems de filtrar los contenidos indebidos, le permitir sacar todo tipo de estadsticas por usuario, sitios navegados, kbytes etc. Mediante el proxy el administrador puede restringir a las estaciones los servicios a la red externa Internet/Intranet, asegurando usuarios con y sin acceso, horarios de conexin, lugares autorizados de visita, y navegacin de servicios como chat, netphone y otros, como usted lo prefiera.

Requerimientos Linux version Empresarial Enlace a internet 1gb ram, Disco duro 50gb, Procesador P4

Que incluye el servicio Instalacin y configuracin de Linux (RedHat Enterprise SuSE Enterprise) Instalacin y configuracin de proxy Instalacin de reglas para filtrado de contenido

Tiempo de implementacinLa implementacin se lleva a cabo en un da


Pgina 8

Servicios recomendados Soporte por evento plizas de soporte 7x24

Almacenamiento en cacheLa mayora de los proxy tienen una cach, es decir, la capacidad de guardar en memoria (en cach) las pginas que los usuarios de la red de rea local visitan comnmente para poder proporcionarlas lo ms rpido posible. De hecho, el trmino "cach" se utiliza con frecuencia en informtica para referirse al espacio de almacenamiento temporal de datos (a veces tambin denominado "bfer"). Un servidor proxy con la capacidad de tener informacin en cach (neologismo que significa: poner en memoria oculta) generalmente se denomina servidor "proxy-cach". Esta caracterstica, implementada en algunos servidores proxy, se utiliza para disminuir tanto el uso de ancho de banda en Internet como el tiempo de acceso a los documentos de los usuarios. Sin embargo, para lograr esto, el proxy debe comparar los datos que almacena en la memoria cach con los datos remotos de manera regular para garantizar que los datos en cach sean vlidos.

FiltradoPor otra parte, al utilizar un servidor proxy, las conexiones pueden rastrearse al crear registros de actividad (logs) para guardar sistemticamente las peticiones de los usuarios cuando solicitan conexiones a Internet. Gracias a esto, las conexiones de Internet pueden filtrarse al analizar tanto las solicitudes del cliente como las respuestas del servidor. El filtrado que se realiza comparando la solicitud del cliente con una lista de solicitudes autorizadas se denomina lista blanca; y el filtrado que se realiza con una lista de sitios prohibidos se denomina lista negra. Finalmente, el anlisis de las respuestas del servidor que cumplen con una lista de criterios (como palabras clave) se denomina filtrado de contenido.

AutenticacinComo el proxy es una herramienta intermediaria indispensable para los usuarios de una red interna que quieren acceder a recursos externos, a veces se lo puede utilizar para autenticar usuarios, es decir, pedirles que se identifiquen con un nombre de usuario y una contrasea. Tambin es fcil otorgarles acceso a recursos externos slo a las personas autorizadas y registrar cada uso del recurso externo en archivos de registro de los accesos identificados. Este tipo de mecanismo, cuando se implementa, obviamente genera diversos problemas relacionados con las libertades individuales y los derechos personales.

Servidores de proxy inversosUn proxy inverso es un servidor proxy-cach "al revs". Es un servidor proxy que, en lugar de permitirles el acceso a Internet a usuarios internos, permite a usuarios de Internet acceder indirectamente a determinados servidores internos.


Pgina 9

El servidor de proxy inverso es utilizado como un intermediario por los usuarios de Internet que desean acceder a un sitio web interno al enviar sus solicitudes indirectamente. Con un proxy inverso, el servidor web est protegido de ataques externos directos, lo cual fortalece la red interna. Adems, la funcin cach de un proxy inverso puede disminuir la carga de trabajo del servidor asignado, razn por la cual se lo denomina en ocasiones acelerador de servidor. Finalmente, con algoritmos perfeccionados, el proxy inverso puede distribuir la carga de trabajo mediante la redireccin de las solicitudes a otros servidores similares. Este proceso se denomina equilibrio de carga .

Configuracin de un servidor proxySin duda, el proxy ms utilizado es Squid, un software de uso libre y gratuito, disponible para diversas plataformas que incluyen a Windows y Linux. En windows, existen diferentes programas para configurar un servidor proxy en una red de rea local a un bajo costo: Wingate es la solucin ms comn (pero no es gratuito) La configuracin de un proxy con un servidor Java cada vez es ms comn Windows 2000 incluye Microsoft Proxy Server (MSP), que funciona con Microsoft Proxy Client.

Qu es un proxy?Un proxy es un sistema de software que permite la conexin de una lan entera al exterior con slo una direccin ip de salida, es decir, si montamos en el servidor principal de la red un modem, tarjeta de red, adaptador RDSI, etc, e instalamos el proxy (Configurando tambin las aplicaciones cliente en los terminales), tendremos acceso al exterior de todos y cada uno de los terminales con una sola cuenta de acceso a internet.

Pero, cmo se consigue esto?El fundamento es el siguiente: El terminal #1 tiene, por ejemplo el Netscape abierto, y el usuario le introduce http://www.maestrosdelweb.com en la barra de direccin, ahora el cliente del proxy le pide sta direccin al Proxy, y ste es el que realmente se encarga de pedir la direccin pero con su IP y no con la del terminal. Despus, cuando tiene lo que le han pedido, se la enva al terminal que lo ha solicitado (el #1) y le aparece al usuario en su navegador exactamente igual que si solo tuviera una conexin con un proveedor de acceso a internet va mdem.


Pgina 10

Tambin hay que hacer referencia al cache de que van provistos los proxy, en el cual buscar las peticiones de los usuarios antes que en el exterior de la red, para as agilizar las transmisiones. Aunque por ahora todo son ventajas maravillosas tambin hay algunos peros, como por ejemplo el tema del ancho de banda de conexin. Si la conexin principal al exterior es de x Kbs, al ir aumentando el nmero de usuarios tambin ir bajando el ancho de banda.


Pgina 11

Sobre configuraciones el tema merece un estudio, es decir, podemos tener un proxy en una oficina (Seguimos con el ejemplo de la fig. 1 con 3 terminales), para dar el acceso a esos 3 usuarios en donde el cach de ste, sirva para mejorar el ancho de banda disponible en la red (Si el terminal 1 pide la pgina de http://www.maestrosdelweb.com/ y por ejemplo, el terminal 2 la estuvo viendo hace 1 semana, el proxy la tendr en el cach, que ser de donde la coja, no disminuyendo el ancho de banda de la red pidiendo algo al exterior que ya tiene), pero tambin existen los servidores proxy basados en hardware . Antes de explicar los fundamentos de estos servidores tengo que hacer una aclaracin: Cuando se dice que algo est basado no quiere decir que sea, es decir, basado no tiene por que implicar sintaxis o definicin, solo una forma de hablar. Esto viene por los fundamentos de los Servidores proxy basados en hardware; en stos lo nico que se hace es montar muchos discos duros de gran capacidad (Esto si es fsico) y del orden de 128 Megas de ram (Variable segn necesidades, como todo claro). Pues bien, stas unidades solo tienen una funcin, que es la de almacenar datos en zonas intermedias o en sitios con gran flujo de peticiones para agilizar la transmisin de datos. Para una mejor comprensin su nombre podra ser mirror aunque no exactamente. Seguro que alguno os habis bajado algo de Microsoft, por ejemplo, y no precisamente de sus servidores en Usa, sino de algn Mirror en otro pas, que puede o no puede ser un ser proxy, y esto es lo ms bonito. Si te fijas en la siguiente figura podrs comprender mejor lo que intento explicar:

Los router (Encaminadores) se sitan entre dos redes y a la vez que encaminan los paquetes entre una red y otra buscando los recorridos ms rpidos o ms precisos, realizan o pueden realizar un


Pgina 12

filtrado de paquetes (por eso tambin le podramos llamar firewall, porque estn haciendo ese trabajo), comprobando las ip y los puertos (cada paquete lleva una franja de informacin en la cul se incluyen las ip de salida y destino y el puerto). El router no es solo un elemento fsico para conectar una lan a internet (wan), sino que es una muy buena opcin a la hora de ampliar una lan. Los router traen de fbrica ciertas ip que se filtraran automticamente, aparte de las que nosotros le podremos asignar ms adelante con las que no nos interesara tener contacto por peligrosidad u otros. Hay router (Lo ltimo de lo ltimo) que soportan el uso de NAT (Encapsulacin de ip interna en cada paquete enviado) Conclusiones: Ya deberas conocer un poco cmo se pueden conectar dos redes, qu es un proxy, un router, etc, aunque bastante por encima. Si te ests preguntando como trasladar esto a tu realidad, es decir, un Pc normal con ventanucos, Linux o algn otro, te recomiendo que te bajes el Pc Conseal Firewall (Un cortafuegos para Pc) y lo instales, que empieces a jugar con la configuracin del mismo y te des cuenta de lo que pasa al restringir algunos puertos, etc. Aqu tienes una foto de mi consola funcionando:

Seguridad con proxy DefinicinProxy es un sistema intermediario entre hosts internos de una red y los hosts de Internet de forma tal que reciba las requisiciones de unos y se las pase a la otra previa verificacin de accesos y privilegios. Este sistema puede correr en hosts "dual-homed" o hosts "bastin" los cuales sern llamados Servidores Proxy. Los sistemas proxy son efectivos solo si se utilizan junto a mtodos de restriccin de trfico IP entre clientes y servidores reales. De este modo, un cliente no podr "bypasear" el servidor proxy para comunicarse con un servidor real utilizando este protocolo.

FuncionamientoEl programa cliente del usuario se comunica con el servidor proxy enviando pedido de conexin con un servidor real. El servidor proxy evala esta requisicin y decide si se permitir la conexin. Si el servidor proxy permite la conexin, enva al servidor real la solicitud recibida desde el cliente. De este modo, un servidor proxy se ve como "Servidor" cuando acepta pedidos de clientes y como "cliente" cuando enva solicitudes a un servidor real. Una vez que establecida la comunicacin entre un cliente y un servidor real, el servidor Proxy acta como un re transmisor pasando comandos y respuestas de un lado a otro. Un punto


Pgina 13

importante a tener en cuenta en este tipo de conexin es que es totalmente transparente. Un usuario nunca se entera de que existe un "intermediario" en la conexin que ha establecido. La comunicacin entre el programa cliente y el servidor Proxy puede realizarse de dos formas distintas: Custom Client Software: El cliente debe saber como opera el servidor proxy, como contactarlo, como pasar la informacin al servidor real, etc. Se trata de un software cliente standard que ha sido modificado para que cumpla ciertos requerimientos. Custom User Procedures: El usuario utiliza un cliente standard para conectarse con un servidor Proxy y usa diferentes procedimientos (comandos del servidor proxy) para pasar informacin acerca del servidor real al cual quiere conectarse. El servidor proxy realiza la conexin con el servidor real

Tipos de servidores proxyServidor Proxy de Aplicacin: Es un servidor que conoce sobre una aplicacin en particular y provee servicios proxy para ella. Entiende e interpreta comandos de un protocolo en particular. Con este tipo de servidores es necesario contar con uno de ellos para cada servicio. Recibe tambin el nombre de servidor Dedicado. Servidor Proxy de Circuito: Crea un circuito virtual entre el cliente y el servidor real sin interpretar el protocolo de la aplicacin. Son llamados Proxys Genricos.

VentajasPermite a los usuarios acceder a los servicios de Internet ocultando totalmente la red interna. Permite un buen servicio de logs a nivel de cada aplicacin. Debido a que todo el trfico pasa a travs del servidor proxy se puede registrar gran cantidad de informacin con fines de auditoria y seguridad. El servidor proxy de Circuito provee soporte para un conjunto grande de protocolos.

DesventajasA menudo se requiere la modificacin del software cliente. Hay software que esta disponible solo para ciertas plataformas: Por Ej: gateway es un package proxy para ftp y telnet de Sun que corre solo sobre Sun. La disponibilidad de estos tipos de paquetes a menudo no es inmediata. En el caso de servidores proxy de aplicacin se requiere un servidor proxy para cada servicio. Algunos servicios no son viables para trabajar con servidores proxy (Ej: talk). El uso de servidores proxy introduce algn retardo en las comunicaciones. Los servidores proxy de circuitos no brindan control especfico sobre las aplicaciones.

Posicin del servidor proxy rpc y los servidores de seguridad corporativaAl implementar RPC a travs de http en el entorno de la empresa, hay varias estrategias de implementacin disponibles para ubicar el servidor proxy RPC y los servidores de seguridad. La estrategia de implantacin recomendada para su entorno de mensajera es implementar un servidor de seguridad avanzado, como Microsoft Internet Security and Acceleration (ISA) Server 2000 con el Service Pack 1 y Feature Pack 1 o superior, en la red perimetral. A continuacin, ubique el servidor proxy RPC en la red corporativa y utilice la arquitectura de servidores de aplicaciones para l usuario y servidores de servicios de fondo de Exchange. Si se utiliza ISA Server en la red perimetral para enrutar solicitudes de RPC a travs de http y se ubica el servidor de aplicaciones para el usuario de Exchange en la red corporativa, basta con abrir el puerto 443 del servidor de seguridad interno para que los clientes de Microsoft Office Outlook 2003 puedan establecer la comunicacin con Exchange. En la siguiente ilustracin se muestra este escenario de implementacin.


Pgina 14

Implementacin de rpc a travs de http utilizando ISA Server como servidor proxy inverso en la red perimetral

Cuando se ubica en la red perimetral, el servidor ISA enruta las solicitudes RPC a travs de http hacia el servidor de aplicaciones para usuario de Exchange que acta como servidor proxy RPC. El servidor proxy RPC se comunica entonces a travs de puertos especificados con otros servidores que utilizan RPC a travs de http. Aunque no es la opcin recomendada, es posible ubicar el servidor de aplicaciones para el usuario final de Exchange Server 2003 que acta como servidor proxy RPC en la red perimetral. Para obtener informacin detallada sobre la ubicacin de un servidor de aplicaciones para el usuario de Exchange en una red perimetral, consulte el tema "Escenarios para la implantacin de una topologa de aplicaciones para el usuario y servidores de servicios de fondo" de Topologa de aplicaciones y servicios de fondo para Exchange Server 2003 y Exchange 2000 (http://go.microsoft.com/fwlink/?LinkId=34216). En este escenario, configure los servidores de Exchange como en la escenario 1. Sin embargo, necesitar asegurarse de abrir los puertos que requiere RPC a travs de http en el servidor de seguridad interno, adems de los que ya se necesitan para un servidor de aplicaciones para el usuario de Exchange. Los puertos siguientes son los requeridos para RPC a travs de http. TCP 6001 (Servicio Almacn de informacin de Microsoft Exchange) TCP 6002 (servicio de referencia del componente Proxy del servicio de directorio (DSProxy)) TCP 6004 (servicio proxy del componente Proxy del servicio de directorio (DSProxy)) Para obtener una lista completa de los dems puertos necesarios en los servidores de aplicaciones para el usuario y en los servidores de servicios de fondo de Exchange, consulte "Consideraciones para la implementacin de una topologa de servidores de aplicaciones para el usuario y servidores de servicios de fondo" de Topologa de aplicaciones y servicios de fondo para Exchange Server 2003 y Exchange 2000 (http://go.microsoft.com/fwlink/?LinkId=34216). En la siguiente ilustracin se muestra este escenario de implementacin.

Implementacin de rpc a travs de http en el servidor de aplicaciones para el usuario de Exchange en la red perimetral


Pgina 15

Si tiene pensado utilizar un nico servidor como servidor de buzn de Exchange y servidor proxy RPC o si tiene pensado utilizar un nico servidor como servidor de buzn de Exchange, servidor proxy RPC y servidor de catlogo global, y no tiene un servidor de aplicaciones para el usuario de Exchange independiente, consulte uno de los temas siguientes: Cmo implementar RPC a travs de http por primera vez en Exchange Server 2003 SP1, sin servidor de aplicaciones para el usuario Cmo implementar RPC a travs de http por primera vez en Exchange Server 2003, sin servidor de aplicaciones para el usuario. Cmo implementar RPC a travs de http por primera vez en Exchange Server 2003, sin servidores de aplicaciones para el usuario, servidor de servicios de fondo en un servidor de catlogo global En la siguiente ilustracin se muestra este escenario de implementacin.

Implementacin de un nico servidor de Exchange

En este escenario, es necesario configurar adems el servidor para que utilice los puertos especificados para RPC a travs de http. Los puertos siguientes son los requeridos para RPC a travs de http: TCP 6001 (Servicio Almacn de informacin de Microsoft Exchange) TCP 6002 (servicio de referencia de DSProxy) TCP 6004 (servicio proxy de DSProxy)


Pgina 16

Puede utilizar un servidor distinto del servidor de aplicaciones para el usuario de Exchange para que se encargue del descifrado del Nivel de sockets seguros (SSL) para las conexiones de clientes. En este escenario, es necesario definir un valor del Registro especial para permitir que se produzca un descifrado de SSL en un equipo distinto del servidor de aplicaciones para el usuario. Para obtener informacin, consulte Cmo configurar el servidor proxy RPC para que permita la descarga de SSL en un servidor independiente. En la siguiente ilustracin se muestra este escenario de implementacin.

Implementacin de rpc a travs de http utilizando ISA Server como servidor proxy inverso en la red perimetral con descarga de SSL

Definicin de proxy webUn proxy web es utilizado para interceptar la navegacin de pginas web por motivos de seguridad, anonimato, rendimiento, etc. Un proxy web se puede acceder por una direccin IP, gratuito o de pago, que es agregada a un navegador (tambin existen programas proxy para evitar el proceso de configuracin). Cuando alguien utiliza el navegador, todo lo que se haga en el mismo pasa primero por el proxy primero (el servidor proxy). O sea, si se pide una pgina web el proxy remoto se encarga de buscarla y enviarla a nuestra computadora. En este paso intermedio el proxy puede servir para: Navegacin annima: si el proxy est configurado de esta manera, todo aquel que navegue a travs de ese proxy lo har de forma annima, las pginas destino no podrn saber la direccin IP (la identificacin) de la computadora que navega; slo vern la direccin IP del proxy. Si un proxy no est configurado para ser annimo se dice que es de navegacin transparente. Navegacin segura: un proxy se encarga de filtrar o alertar sobre aquellas pginas web inseguras o filtran el contenido para indeseado (como contenido adulto). Navegacin ms rpida: ya sea porque el proxy tiene una mejor conexin a internet y enva al navegador ms rpido los datos, o porque el proxy funciona como cach, guardando las pginas ms visitadas (o las visitadas recientemente). Control del trfico: existen programas espas y otros malwares que configuran la computadora para que todo el trfico web pase primero por un proxy. Este proxy se encarga de espiar el trfico, pudiendo sacar todo tipo de informacin del usuario. Si los datos (como claves y tarjetas de crdito) no estn cifrados, cualquiera puede leerlos. Este tipo de proxy tambin puede enviar publicidad a las computadoras infectadas (publicidad que no exite en las pginas web originales).


Pgina 17

Proxy de team foundation server y control de cdigo fuenteEl proxy de team foundation server est diseado para mejorar el rendimiento de la red haciendo copias en la memoria cach de los archivos de control de cdigo fuente en una ubicacin remota, local para el desarrollador que necesita los archivo pero fuera de la ubicacin del control de cdigo fuente principal. Mediante el almacn de copias en la ubicacin remota, normalmente conectada a la ubicacin de origen a travs de un vnculo ms lento que la red de rea local, el servidor proxy evita que cada usuario descargue archivos en su rea de trabajo con la conexin ms lenta. En su lugar, el proxy de team foundation server generalmente cumple las solicitudes de cliente devolviendo los archivos desde la cach local con una conexin local ms rpida. Cuando una archivo no se encuentra en la cach local, ste se descarga desde el proxy a la cach local desde Team Foundation Server, antes de que se devuelvan los archivos al cliente.

Operaciones bsicasEl funcionamiento del proxy de team foundation server se puede ver desde el cliente y desde el servidor. Al igual que todos los proxy de Internet, configure el cliente de team foundation para utilizar el proxy, de modo que el proxy de team foundation server controle la administracin de los archivos. Como usuario del cliente de team foundation, permita que el proxy controle la descarga de archivos. Para obtener ms informacin, vea Cmo: Configurar el control de cdigo fuente de team foundation para utilizar el servidor proxy. La primera tarea del administrador es configurar el proxy de team foundation server en el servidor. Para obtener ms informacin sobre la instalacin del proxy de team foundation server, vea la gua de instalacin de team foundation que se encuentra en lnea en http://go.microsoft.com/fwlink/?linkid=40042 o bien el archivo TFSInstall.chm incluido con el producto. A continuacin, puede configurar el servidor proxy a fin de habilitar el almacenamiento en cach del archivo editando el archivo Proxy.config. Para obtener ms informacin, vea Cmo: Habilitar el almacenamiento en cach de control de cdigo fuente para un proxy de team foundation server. El lmite mximo se establece en la cantidad de espacio de almacenamiento que el proxy de team foundation server puede utilizar para guardar los archivos en cach. Cuando se alcanza el lmite, los archivos antiguos de la cach se eliminan para liberar espacio de almacenamiento de modo que se pueda utilizar para almacenar nuevos archivos solicitados. El liberador de espacio quita los archivos teniendo en cuenta la ltima vez que se obtuvo acceso a ellos. Se eliminan primero los archivos a los que no se haya tenido acceso durante ms tiempo.


Pgina 18

Tambin se puede cambiar la configuracin de la memoria cach de las maneras siguientes: Especificar una carpeta raz diferente para la cach. Cambiar el lmite en el que los archivos antiguos se quitan de la cach. Cambiar la cantidad de espacio que se dejar libre al quitar archivos antiguos. Para obtener ms informacin, vea Cmo: Cambiar la configuracin de la memoria cach para un proxy de team foundation server.

MantenimientoEs importante supervisar y administrar peridicamente el rendimiento de la cach del proxy de team foundation server. Por ejemplo, debe examinar los contadores de rendimiento siguientes: Tamao actual de la cach Total de visitas a la cach - recuento y porcentaje Total de solicitudes de descarga Total de archivos en la cach Total de errores en la cach - recuento y porcentaje Estos contadores de rendimiento estn registrados como parte de la instalacin del proxy. Los contadores de rendimiento del proxy tienen varias instancias, lo que significa que existe un conjunto de contadores para cada nivel de aplicacin que haya configurado en el archivo Proxy.config. La recopilacin de estos datos permite entender mejor el rendimiento y la actividad del proxy de team foundation server mientras se ejecuta. Para obtener ms informacin, vea Cmo: Examinar el rendimiento de la memoria cach para un proxy de team foundation server.

SeguridadEl proxy de control de team foundation server utiliza un esquema de vale autenticado previamente para determinar si el usuario que lo solicita est autorizado a ver el contenido del archivo solicitado. En este esquema, el cliente del usuario se pone en contacto con el servidor del control de cdigo fuente maestro y, si es usuario est autorizado, se le proporciona al cliente un vale firmado digitalmente que contiene los detalles del archivo solicitado. El cliente entonces presenta el vale al servidor proxy. Este uso de las firmas de clave privada y pblica permite al proxy asegurarse de que el vale proviene del servidor y que el usuario, por tanto, est autorizado para


Pgina 19

ver el archivo. El proxy busca en la cach si puede ofrecer la solicitud y si no, pide el archivo al servidor y lo incluye a la cach.

Arquitectura de seguridad de team foundation serverPara analizar y planear la seguridad de team foundation server, debe tener en cuenta el nivel de aplicacin de team foundation, el nivel de datos de team foundation, el nivel de cliente de team foundation, team foundation build, el servidor proxy de team foundation server y las interacciones entre todos ellos. Tendr que saber qu servicios web, bases de datos y modelos de objetos se utilizan. Tambin tendr que saber qu puertos y protocolos de red se utilizan de forma predeterminada y qu puertos se pueden personalizar. Adems de sus propios servicios, team foundation server depende de otros servicios para funcionar. Para obtener ms informacin sobre las dependencias de team foundation server, vea

Conceptos de seguridad de team foundation server Modelo de objetosTeam foundation server incluye un modelo de objetos que habilita la comunicacin entre el nivel del cliente de team foundation y el nivel de la aplicacin de team foundation. Este modelo de objetos tambin permite que los integradores de software y otros proveedores personalicen y amplen la funcionalidad de team foundation server.

Modelo de objetos de team foundation serverEl modelo de objetos de team foundation server es un conjunto de API administradas que incluyen las interfaces siguientes: Servicios comunes de team foundation Servicio de registro Servicio de seguridad Servicio de vinculacin Servicio de eventos Servicio de clasificacin Modelo de objetos de control de versiones Modelo de objetos de seguimiento de elementos de trabajo El modelo de objetos de team foundation server se documenta pblicamente en la documentacin de extensibilidad de team foundation server en el Visual Studio SDK.

Servicios web y bases de datosTeam foundation server incluye un conjunto de servicios web y bases de datos. Estos servicios y bases de datos se instalan y configuran de forma independiente en el nivel de la aplicacin, nivel de los datos y nivel del cliente de team foundation. Las figuras siguientes muestran brevemente servicios web, aplicaciones y bases de datos en team foundation server y en equipos cliente.


Pgina 20

Nivel de aplicacinEl nivel de aplicacin de team foundation contiene los servicios web Asp.Net siguientes que corresponden al servidor proxy o a los modelos de objetos respectivos en el nivel de cliente. En general, estos servicios web no estn diseados para que los integradores de otros proveedores programen con ellos, a excepcin del servicio web MSBuild, que est documentado en la documentacin de extensibilidad de team foundation server en el visual studio SDK. Servicios comunes de team foundation Servicio web de registro Servicio web de seguridad Servicio web de vinculacin Servicio web de eventos


Pgina 21

Servicio Servicio Servicio Servicio

web de clasificacin web de control de versiones web de seguimiento de elementos de trabajo web de team foundation build

Nivel de los datosEl nivel de datos de team foundation est compuesto de los almacenes operativos siguientes dentro de SQL Server 2005. Esto incluye datos, procedimientos almacenados y otra lgica asociada. En general, estos almacenes operativos no estn diseados para que los integradores de otros proveedores los utilicen para programar. Seguimiento de elementos de trabajo Control de versiones Servicios comunes de team foundation Team foundation build Almacn de datos de informes

Nivel de clienteEl nivel de cliente utiliza los mismos servicios web mostrados en el nivel de aplicacin para comunicar con el nivel de aplicacin de team foundation, a travs del modelo de objetos de team foundation server. Adems del modelo de objetos de team foundation server, el nivel de cliente de team foundation est formado por los componentes de visual studio industry partners (VSIP), la integracin con Microsoft Office, las interfaces de lnea de comandos y una estructura de directivas de proteccin para la integracin con team foundation server y la integracin personalizada. Para obtener ms informacin sobre cmo ampliar y personalizar el nivel del cliente, consulte la documentacin de extensibilidad en visual studio SDK.

Puertos y protocolos de redDe forma predeterminada, team foundation server est configurado para utilizar puertos y protocolos de red concretos. El diagrama siguiente muestra el trfico de red de team foundation server en una implementacin de ejemplo.

Configuracin de la red predeterminadaIng. Eduardo A. Aparicio C. Pgina 22

De forma predeterminada, la comunicacin entre el nivel de aplicacin de team foundation, el nivel de datos de team foundation, los servidores de compilacin y el servidor proxy de team foundation server utilizan los puertos y protocolos de la lista siguiente.

Servicio y nivelNivel de aplicacin: servicios web

Protocolohttp

Puerto8080 Este puerto se genera de forma aleatoria durante la instalacin de Windows sharepoint services. 80 9191

Nivel de aplicacin: Administracin de http Windows sharepoint services Nivel de aplicacin: Windows sharepoint http services y Sql reporting services Servidor de compilacin: Acceso remoto .Net desde el servidor de nivel de la aplicacin Remoting de team foundation Nivel de datos Nivel de datos

Tcp de Ms 1443 Sql Udp de Ms 1444 Sql 8081 8080 80 8080

Servidor proxy de team foundation server: http Cliente a servidor proxy Servidor proxy de team foundation server: http Servidor proxy en el nivel de aplicacin Nivel de cliente: Reporting services Nivel de cliente: Servicios web http http

Configuracin de la red personalizablePuede optar por modificar team foundation server para que utilice https y SSL (secure socket layer) en lugar de http para los servicios web y Microsoft SQL Reporting Services. La comunicacin entre el nivel de la aplicacin, de los datos y del cliente cambiara como se describe en la tabla siguiente.

Servicio y nivelNivel de aplicacin: servicios web con SSL

Protocolo Puertohttps Configurado administrador Configurado administrador 443 443 Configurado administrador por el por por el el

Nivel de aplicacin: Administracin de windows https sharepoint services Nivel de aplicacin: Windows sharepoint services y https Sql reporting services Nivel de cliente: Reporting services Nivel de cliente: Servicios web https https

Implementacin de software cliente/servidor (protocolos binarios)Ing. Eduardo A. Aparicio C. Pgina 23

En esta prctica vamos a realizar el diseo y la implementacin de un proxy Socksv5 y unas funciones de librera que permitan construir clientes compatibles con este servicio. Para comenzar, partimos del cdigo fuente de sockets implementado en la prctica anterior1, junto al material adicional resumen de Socksv5 (pdf) y RFCs 1928-1929.

Implementacin del cliente Requisitos Conseguir conexiones tcp y obtencin de servicios a travs del proxy. Uso de RFC 1929 para autenticacin Usuario/Contrasea. Se crearn las siguiente funciones int socks5tcp_connect (int sockstream_handle, struct sockaddr* dst, size_t dstlen) Esta funcin se encarga de establecer la negociacin con el servidor proxy, Los parmetros son idnticos a la llamada connect de la interfaz socket. Si todo fue bien, la funcin devuelve el valor acostumbrado: 0. En caso contrario, devolver: 1 si existi un error en la llamada a connect (por lo que se consultar la variable global errno); y 2 en otro caso, actualizando la variable global socks5_errno a uno de los siguientes valores: S5_ESRVFAIL Error del servidor SOCKSv5 (general) S5_EPERM El servidor SOCKS rechaz la conexin (sin permisos) S5_EUNREACH El servidor SOCKS no alcanz el destino S5_ECONNREFUSED El servidor destino rechaz la conexin S5_ENOSERV Servidor SOCKS no encontrado En Sun OS / Solaris, se aaden las directivas de enlazado -lsocket lnsl, en la llamada a gcc para generar ejecutables de comunicaciones. Struct sockaddr * socks5_getSOCKSserv (). Esta funcin sirve como soporte a la anterior, proporcionando la informacin necesaria para conectar con el servidor proxy, en su valor de retorno. Estos datos aparecen en el directorio home del usuario que ejecutar el proceso: ~/.socks5c.conf. En caso de error, la funcin devuelve NULL. Para obtener el valor de la variable de entorno home usar la funcin getenv (consulta el manual).

Implementacin del servidor Requisitos Aceptar conexiones de clientes autorizados (RFC 1929) y establecer la comunicacin real con el servicio deseado. Actuar como pasarela en la comunicacin entre extremos (cliente y servicio). El servidor proxy tiene un doble papel: por un lado, acta como servidor de cara a los clientes socksificados, aceptando conexiones en el puerto 1080. Con ellos establece la negociacin de seguridad. Por otro, acta como cliente ante el servicio real, haciendo de pasarela entre los datos que se intercambian ambos extremos. La implementacin del servidor proxy debe estar bien estructurada, ya que el seguimiento de la comunicacin, as como la deteccin de errores, pueden convertirse en labores complicadas. Se recomienda al alumno que encapsule en distintas funciones las tareas crticas. La autorizacin se hace en base a dos criterios: 1. Direccin ip del cliente: Solo se autoriza el ip del cliente si existe el fichero correspondiente a la direccin dentro del directorio ~/. socks5s.conf/


Pgina 24

2. Usuario/Contrasea: En el fichero correspondiente a dicha ip, debe existir una lnea con el par usuario: passwd, coincidente con los datos enviados por el cliente. Una sugerencia para implementar una pasarela entre dos sockets (el que est abierto con el cliente y el que se mantiene con el servidor), es utilizar la llamada al sistema select.

Criterios de evaluacinAdems de los ya conocidos (estilo, robustez del cdigo ante errores), se valorarn las ampliaciones propuestas: UDP, select y en particular, la atencin del proxy a mltiples clientes. Las funciones cliente y los nuevos cdigos de error, se implementarn en socks5api.c, incorporando sus prototipos desde socks5api.h. Demostrar la utilidad de esta librera a travs de la implementacin de un cliente simple de http que haga uso de sus servicios. Truco: Las consultas se hacen mediante sockets tcp y un comando que se construye as: sprintf (buf,"GET %s http/1.0\n\n",pagina);

Tcp wrapper IntroduccinPara todo administrador de sistemas, tener mquinas conectadas a una red pblica como es Internet, conlleva una serie de responsabilidades implcitas. Una de las ms importantes es salvaguardar la integridad de dichas mquinas, as como proteger los datos de sus usuarios ante eventuales intrusos. Todos, hemos ledo o visto en TV. noticias acerca de hackers asaltando sistemas, tal vez pensemos que so slo les ocurre a otros o que slo pasa en Amrica. La realidad es otra, cualquiera de nosotros somos susceptibles de ser objetivo de un ataque. Para contrarrestar en parte los peligros antes mencionados, existen diferentes alternativas, las cuales no son excluyentes, lo cual quiere decir que se pueden combinar de forma que encontremos un buen ratio entre eficacia y funcionalidad para nuestros usuarios. Vamos a explicar en este documento una herramienta que nos va a permitir que nuestras mquinas Unix rechacen conexiones Udp y Tcp segn el origen de las mismas. La herramienta en concreto se llama tcp wrapper y algunas de sus mejores virtudes son: Es gratis, Muy fcil de instalar y manejar, Hiperconfigurable, Genera mltiples logs.

Introduccin a inetd (El super servidor de internet)Antes de explicar como trabaja la herramienta tcp wrapper, es necesario comprender la forma tradicional que los sistemas Unix tienen para procesar las peticiones de determinados servicios. Como ya todos sabemos los servidores en Internet tienen unos puertos lgicos (software) que nos permiten desde una estacin remota, lanzar un cliente para establecer una conexin con dicho servicio. Ejemplo: desde nuestra estacin de trabajo, lanzamos un cliente pop que se conecta con el servidor en el puerto 110 para poder enviar o recibir correo. Ahora entra en escena INETD, el super servidor de Internet, que es un gestor de servicios, de forma que escucha en la red posibles solicitudes de servicios para dependiendo de a que puerto va avisar al programa o daemon correspondiente. Pongamos un ejemplo, INETD es el seor que est en la puerta de nuestra oficina atendiendo a las personas que vienen a visitarnos, y dependiendo del servicio que demanden, avisa al trabajador adecuado (daemon) para que lo atienda. El funcionamiento es perfecto, pero necesitamos que segn que personas (conexiones) vengan a visitarnos, poder rechazarlas de una forma eficaz y elegante. En este contexto, es donde va a trabajar el programa al que dedicamos este documento, tcp wrapper nos va a permitir rechazar las conexiones dependiendo de su origen y/o de su ident.


Pgina 25

Los wrapper tcp y el comando xinetdEl control del acceso a los servicios de red es una de las tareas de seguridad ms importantes que un administrador de servidores debe enfrentar. Afortunadamente, bajo Red Hat Enterprise Linux, hay un gran nmero de herramientas que hacen justamente estas tareas. Por ejemplo, un cortafuego basado en iptables dejan afuera los paquetes de red que no son bienvenidos dentro de la pila de red del kernel. Para los servicios de red que lo utilizan, los tcp wrappers aaden una capa adicional de proteccin mediante la definicin de cules hosts tienen permitido conectarse a los servicios de red "wrapped". Uno de los servicios de red wrapped es el super servicio xinetd. Este servicio se le llama super servicio porque controla la conexin a un subconjunto de servicios de red y refina an ms el control de acceso. El diagrama es una ilustracin bsica de cmo estas herramientas funcionan para proteger los servicios de red.

Control de acceso a los servicios de red Wrapper tcpEl paquete tcp wrapper (tcp_wrapper) est instalado por defecto y proporciona control de acceso basado en host a los servicios de red. El componente ms importante dentro del paquete es la biblioteca /usr/lib/libwrap.a. En trminos generales, un servicio tcp wrapped es uno que ha sido compilado con la biblioteca libwrap.a. Cuando un intento de conexin es hecho a un servicio wrapped tcp, el servicio primero referencia los archivos de acceso a host (/etc/hosts.allow y /etc/hosts.deny) para determinar si el cliente tiene permitido conectarse. En la mayora de los casos, luego utiliza el demonio syslog (syslogd) para escribir el nombre del host solicitante y el servicio solicitado a /var/log/secure o /var/log/messages. Si a un cliente se le permite conectarse, los wrapper tcp liberan el control de la conexin al servicio solicitado y no interfieren ms con la comunicacin entre el cliente y el servidor. Adems del control de acceso y registro, los wrapper tcp pueden activar comandos para interactuar con el cliente antes de negar o liberar el control de la conexin al servicio solicitado.


Pgina 26

Puesto que los wrapper tcp son una utilidad de gran valor a las herramientas de seguridad de cualquier administrador de servidor, la mayora de los servicios de red dentro de Red Hat Enterprise Linux estn enlazados con la biblioteca libwrap.a. Algunas de tales aplicaciones incluyen /usr/sbin/sshd, /usr/sbin/sendmail, y /usr/sbin/xinetd. Para determinar si un binario de servicio de red est enlazado con la librera libwrap.a, escriba el comando siguiente como usuario root: strings -f | grep hosts_access Reemplace con el nombre del binario de servicio de red. Si aparece un indicador de comandos, entonces el servicio de red no est enlazado con libwrap.a.

Ventajas de los wrapper tcpLos wrapper tcp ofrecen las siguientes ventajas bsicas comparadas con las otras tcnicas de control de servicios de red: Transparencia tanto para el host cliente y el servicio de red wrapped; El cliente que se est conectando as como tambin el servicio de red wrapped no estn al tanto de que estn en uso los wrapper tcp. Los usuarios legtimos son registrados y conectados al servicio solicitado mientras que las conexiones de clientes prohibidos fallan. Administracin centralizada de mltiples protocolos; Los wrapper tcp operan separadamente de los servicios de red que ellos protegen, permitiendo a muchas aplicaciones de servidor compartir un conjunto comn de archivos de configuracin para una administracin ms sencilla.

Archivos de configuracin de wrapper tcpPara determinar si una mquina cliente tiene permitido conectarse a un servicio, los wrapper tcp referencian los siguientes dos archivos, los cuales se conocen comnmente como archivos de acceso a host: /etc/hosts.allow /etc/hosts.deny Cuando una solicitud de un cliente es recibida por un servicio wrapped tcp, sigue los pasos siguientes: 1. Referencias a /etc/hosts.allow; El servicio wrapped tcp analiza secuencialmente el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si encuentra una regla que coincide, permite la conexin. Si no, se va al prximo paso. 2. Referencias /etc/hosts.deny; El servicio wrapped tcp analiza secuencialmente el archivo /etc/hosts.deny. Si encuentra una regla que coincide, rechaza la conexin. Si no, se concede acceso al servicio. Lo siguiente son puntos muy importantes a considerar cuando se usen wrapper tcp para proteger servicios de red: Puesto que las reglas de acceso en hosts.allow son aplicadas primero, ellas toman precedencia

sobre las reglas en hosts.deny. Por lo tanto, si se permite el acceso a un servicio en hosts.allow, una regla negando el acceso al mismo servicio en hosts.deny es ignorada. Las reglas en cada archivo son ledas de arriba hacia abajo y la primera regla que coincida para un servicio dado es la nica aplicada. Por lo tanto el orden de las reglas es extremadamente importante. Si no se encuentra ninguna regla para el servicio en ninguno de los archivos, o si no existe ninguno de los archivos, se concede el acceso al servicio.


Pgina 27

Los servicios wrapped tcp no hacen cach de las reglas desde los archivos acceso de host, por

lo tanto cualquier cambio a hosts.allow o a hosts.deny tomarn efecto de inmediato sin tener que reiniciar el servicio de red. Aviso Si la ltima lnea de un archivo de acceso a host no es un carcter de nueva lnea (creado al presionar la tecla [Intro]), la ltima regla en el archivo fallar y se registrar un error bien sea a /var/log/messages o a /var/log/secure. Este es tambin el caso para reglas que se expanden en mltiples lneas sin usar la barra oblicua. El ejemplo siguiente ilustra la porcin relevante del mensaje registrado por una falla de una regla debido a alguna de estas circunstancias: warning: /etc/hosts.allow, line 20: missing newline or line too long

Formatear reglas de accesoLos formatos para /etc/hosts.allow y /etc/hosts.deny son idnticos. Cualquier lnea en blanco que comience con un smbolo de numeral o almohadilla (#) ser ignorada, y cada regla debe estar en su propia lnea. Las reglas se tienen que formatear de la siguiente manera: : [: : : ...] ; Una lista separada por comas de los nombres de procesos (no de los nombres

de servicios) o el comodn ALL (consulte Seccin 17.2.1.1). La lista de demonios tambin acepta operadores (consulte la seccin 17.2.1.4) para permitir mayor flexibilidad. ; Una lista separada por comas de nombres de host, direcciones IP, patrones especiales (consulte la seccin 17.2.1.2), o comodines especiales (consulte la seccin 17.2.1.1) la cual identifica los hosts afectados por la regla. La lista de clientes tambin acepta operadores listados en la seccin 17.2.1.4 para permitir mayor flexibilidad. ; Una accin opcional o una lista separada con puntos y comas de acciones realizadas cuando la regla es activada. Los campos de opciones soportan expansiones (consulte la seccin 17.2.2.4), lanzan comandos desde el shell, otorgan o prohiben el acceso y alteran el comportamiento de la conexin (consulte la seccin 17.2.2). A continuacin una muestra bsica de una regla de acceso: vsftpd : .example.com Esta regla instruye a los wrapper tcp a que estn atentos por conexiones al demonio ftp (vsftpd) desde cualquier host en el dominio example.com. Si esta regla aparece en hosts.allow, la conexin ser aceptada. Si esta regla aparece en hosts.deny, la conexin ser rechazada. El prximo ejemplo de regla de acceso es un poco ms complejo y utiliza dos campos de opciones: sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny


Pgina 28

Note que cada campo de opcin est precedido por una barra oblicua invertida (\). Use la barra para prevenir que falle la regla debido al largo de la misma. Esta regla de ejemplo indica que si una conexin al demonio SSH (sshd) se intenta desde un host en el dominio example.com, ejecute el comando echo (lo cual registrar el intento a un archivo especial) y rechace la conexin. Puesto que se usa la directiva opcional deny, esta lnea rechazar el acceso an si aparece en el archivo hosts.allow.

ComodinesLos comodines permiten a los wrapper tcp coincidir ms fcilmente grupos de demonios o hosts. Son usados con mayor frecuencia en el campo de lista de cliente de las reglas de acceso. Se pueden utilizar los siguientes comodines: ALL; Hace corresponder todo. Se puede usar para la lista de demonios o en la lista de clientes. LOCAL; Hace corresponder todos los nombres de mquinas que no contengan un punto (.), tal como localhost. KNOWN; Hace corresponder todas las mquinas cuyos nombres y direcciones son conocidos o donde el usuario es conocido. UNKNOWN; Hace corresponder todas las mquinas cuyos nombres y direcciones sean desconocidas o en el caso en el que se desconozca el usuario. PARANOID; Hace corresponder todas las mquinas cuyo nombre no se corresponda con la direccin.

AtencinLos comodines KNOWN, UNKNOWN y PARANOID tienen que usarse con cuidado porque si se utilizan de una manera incorrecta los usuarios que s que tengan acceso a un determinado servicio pueden perderlo.

PatronesLos patrones se pueden utilizar en el campo de lista de cliente de las reglas de acceso para especificar de forma ms precisa grupos de host clientes. La siguiente es una lista de los patrones ms comnmente aceptados para una entrada de lista de cliente: Nombre de host comenzando con un punto (.); Al colocar un punto al comienzo de un nombre

de host, se hace coincidir todos los hosts compartiendo los componentes listados del nombre. El ejemplo siguiente aplicara a cualquier host dentro del dominio example.com: ALL : .example.com Direccin ip que termina con un punto (.); Al colocar un punto al final de una direccin ip hace

corresponder todos los hosts compartiendo el grupo numrico inicial de una direccin ip. El ejemplo siguiente aplicar a cualquier host dentro de la red 192.168.x.x: ALL: 192.168. Par direccin ip/mscara; Las expresiones de mscaras de red tambin pueden ser usadas

como un patrn de control de acceso a un grupo particular de direcciones ip. El ejemplo siguiente aplicara a cualquier host con una direccin de 192.168.0.0 hasta 192.168.1.255:


Pgina 29

ALL : 192.168.0.0/255.255.254.0

ImportanteCuando se est trabajando en el espacio de direcciones de IPv4, no se soporta el largo del par direccin/prefijo (prefixlen). Slo las reglas IPv6 pueden utilizar este formato. Par [Direccin IPv6]/prefixlen; Los pares [net]/prefixlen tambin pueden ser usadas como un

patrn de control de acceso a un grupo particular de direcciones IPv6. El ejemplo siguiente aplicara a cualquier host con una direccin de 3ffe:505:2:1:: hasta 3ffe:505:2:1:ffff:ffff:ffff:ffff: ALL : [3ffe:505:2:1::]/64 El asterisco (*); Los asterscos pueden ser usados para coincidir grupos completos de nombres

de host o direcciones IP, siempre y cuando no se mezclen en la lista de cliente conteniendo otros tipos de patrones. El ejemplo siguiente aplicara a cualquier host dentro del dominio example.com: ALL : *.example.com La barra oblicua (/);

Si una lista de cliente con una barra, es tratado como un nombre de archivo. Esto en muy til si es necesario reglas especificando un gran nmero de hosts. El ejemplo siguiente se refiere a wrapper tcp en el archivo /etc/telnet.hosts para todas las conexiones de Telnet: in.telnetd : /etc/telnet.hosts

Portmap y wrapper tcpCuando se crean reglas de control de acceso para portmap, no utilice nombres de host pues la implementacin de wrapper tcp de portmap no soporta la bsqueda por host. Por esta razn, slo utilice direcciones ip o la palabra clave ALL cuando especifique hosts en hosts.allow o en hosts.deny. Adems, cambios a las reglas de control de acceso portmap pueden que no tomen efecto de inmediato si no se reinicia el servicio portmap. Los servicios ampliamente usados, tales como NIS y NFS, dependen de portmap para funcionar, por lo tanto este consciente de estas limitaciones.

OperadoresActualmente, las reglas de control de acceso aceptan un operador, EXCEPT. Se puede usar tanto en la lista de demonios como en la lista de cliente de una regla. El operador EXCEPT permite excepciones especficas a coincidencias ms amplias dentro de la misma regla. En el ejemplo siguiente desde un archivo hosts.allow, todos los hosts de example.com pueden conectarse a todos los servicios excepto cracker.example.com:


Pgina 30

ALL: .example.com EXCEPT cracker.example.com En el otro ejemplo desde un archivo hosts.allow, clientes desde la red 192.168.0.x pueden usar todos los servicios excepto para FTP: ALL EXCEPT vsftpd: 192.168.0.

Campos de opcionesAdems de las reglas bsicas para permitir o prohibir el acceso, la implementacin de Red Hat Enterprise Linux de wrapper tcp soporta extensiones al lenguaje de control de acceso a travs de los campos de opciones. Mediante el uso de campos de opciones dentro de las reglas de acceso al host, los administradores pueden llevar a cabo una gran variedad de tareas tales como alterar el comportamiento del registro, consolidar el control de acceso y lanzar comandos del shell.

RegistroLos campos de opciones les permiten a los administradores cambiar fcilmente la facilidad de conexin y el nivel de prioridad para una regla usando la directiva severity. En el ejemplo siguiente, las conexiones al demonio SSH desde cualquier host en el dominio example.com son registrados a la facilidad por defecto authpriv syslog (debido a que no se especifica un valor de facilidad) con una prioridad de emerg: sshd : .example.com : severity emerg Es tambin posible especificar una facilidad utilizando la opcin severity. El ejemplo siguiente registra cualquier intento de conexin SSH por cualquier hosts desde el dominio example.com a la facilidad local0 con una prioridad de alert: sshd : .example.com : severity local0.alert

Control de accesoLos campos de opciones tambin les permiten a los administradores explcitamente otorgar o prohibir el acceso de mquinas en una sola regla, aadiendo la directiva allow o deny al final de la opcin. Por ejemplo, las dos reglas siguientes permiten conexiones SSH desde client-1.example.com, pero prohben conexiones desde client-2.example.com: sshd : client-1.example.com : allow sshd : client-2.example.com : deny Al permitir el control de acceso por regla, el campo de opciones permite a los administradores consolidar todas las reglas de acceso en un slo archivo: bien sea hosts.allow o hosts.deny. Algunos consideran que esta es una forma ms fcil de organizar reglas de acceso.


Pgina 31

Comandos de la shellLos campos de opciones permiten a las reglas de acceso lanzar comandos de la shell a travs de las directivas siguientes: Spawn; Lanza un comando de la shell como un proceso hijo. Esta directiva de opcin puede

realizar tareas como el uso de /usr/sbin/safe_finger para obtener ms informacin sobre el cliente solicitante o la creacin de archivos de registro especiales usando el comando echo. En el ejemplo siguiente, los clientes intentando accesar servicios Telnet desde el dominio example.com son registrados discretamente a un archivo especial: in.telnetd : .example.com \ : spawn /bin/echo `/bin/date` from %h>>/var/log/telnet.log \ : allow Twist; Reemplaza el servicio solicitado con el comando especificado. Esta directriz se utiliza a

menudo para colocar trampas para intrusos (tambin llamados "potes de miel"). Tambin se puede utilizar para enviar mensajes a los clientes que se estn conectando. La directriz twist debe estar al final de la lnea de la regla. En el ejemplo siguiente, los clientes intentando accesar servicios FTP desde el dominio example.com se les enva un mensaje a travs del comando echo: vsftpd : .example.com \ : twist /bin/echo "421 Bad hacker, go away!" Para ms informacin sobre las opciones de comando de la shell, consulte la pgina del manual de hosts_options.

ExpansionesLas expansiones, cuando se utilizan en conjunto con las directrices spawn y twist, proporcionan informacin sobre el cliente, servidor y los procesos relacionados. Abajo se encuentra una lista de las expansiones soportadas: %a, Suministra la direccin IP del cliente. %A, Suministra la direccin IP del servidor. %c, Proporciona informacin variada sobre el cliente, como el nombre de usuario y el de la mquina o el nombre del usuario y la direccin ip. %d, Proporciona el nombre del proceso demonio. %h, Suministra el nombre de la mquina del cliente (o la direcccin ip, si el nombre de la mquina no est disponible). %H, Suministra el nombre de la mquina del servidor (o la direccin ip si el nombre de la mquina no est disponible). %n, Proporciona el nombre de la mquina del cliente. Si no est disponible aparecer unknown. Si el nombre de la mquina y la direccin de la mquina no se corresponden, aparecer paranoid. %N, Proporciona el nombre de la mquina del servidor. Si no est disponible aparecer unknown. Si el nombre de la mquina y su direccin no coinciden, aparecer paranoid. %p, Suministra el ID del proceso demonio. %s, Suministra informacin varia del servidor como el proceso demonio y la mquina o la direccin IP del servidor. %u, Proporciona el nombre de usuario del cliente. Si no est disponible aparecer unknown.


Pgina 32

El ejemplo siguiente usa una expansin en conjunto con el comando spawn para identificar el host cliente en un archivo de registro personalizado. Cuando se intentan conexiones al demonio SSH (sshd) desde un host en el dominio example.com, ejecute el comando echo para registrar el intento, incluyendo el nombre del host cliente (usando la expansin %h), a un archivo especial: sshd : .example.com \ : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \ : deny De forma similar, las expansiones se pueden utilizar para personalizar mensajes de vuelta al cliente. En el ejemplo siguiente, los clientes intentando accesar servicios FTP desde el dominio example.com son informados que se les ha prohibido acceder al servidor: vsftpd : .example.com \ : twist /bin/echo "421 %h has been banned from this server!" Para una explicacin completa de las expansiones disponibles, as como tambin opciones de control de acceso adicionales, revise la seccin 5 de la pgina man para hosts_access (man 5 hosts_access) y la pgina man de hosts_options.

xinetdEl demonio xinetd es un super servicio wrapped tcp que controla el acceso a un subconjunto de servicios de red populares incluyendo ftp, imap y telnet. Tambin proporciona opciones de configuracin especficas al servicio para el control de acceso, registro mejorado, re direccionamiento y control de utilizacin de recursos. Cuando un host cliente intenta conectarse a un servicio de red controlado por xinetd, el sper servicio recibe la peticin y verifica por cualquier regla de control de acceso wrapper tcp. Si se permite el acceso, xinetd verifica que la conexin sea permitida bajo sus propias reglas para ese servicio y que el servicio no est consumiendo ms de la cantidad de recursos o si est rompiendo alguna regla definida. Luego comienza una instancia del servicio solicitado y pasa el control de la conexin al mismo. Una vez establecida la conexin, xinetd no interfiere ms con la comunicacin entre el host cliente y el servidor.

Archivos de configuracin xinetdLos archivos de configuracin para xinetd son los siguientes: /etc/xinetd.conf El archivo de configuracin global de xinetd. /etc/xinetd.d/ El directorio que contiene todos los archivos especficos al servicio.

El archivo /etc/xinetd.confEl archivo /etc/xinetd.conf contiene parmetros de configuracin generales los cuales afectan cada servicio bajo el control de xinetd. Se lee una vez cuando el servicio xinetd es iniciado, por esto, para que los cambios de la configuracin tomen efecto, el administrador debe reiniciar el servicio xinetd. Abajo se muestra un ejemplo del archivo /etc/xinetd.conf: defaults { instances log_type

= 60 = SYSLOG authpriv


Pgina 33

log_on_success log_on_failure cps } includedir /etc/xinetd.d

= HOST PID = HOST = 25 30

Estas lneas controlan los siguientes aspectos de xinetd: Instances; Configura el mximo nmero de peticiones que xinetd puede manejar simultneamente. log_type; Configura xinetd para usar la facilidad de registro authpriv, el cual escribe las entradas de registro al archivo /var/log/secure. Al agregar una directiva tal como FILE /var/log/xinetdlog aqu, crear un archivo de registro personalizado llamado xinetdlog en el directorio /var/log/. log_on_success; Configura xinetd a registrar si la conexin es exitosa. Por defecto, la direccin IP del host remoto y el ID del proceso del servidor procesando la peticin son grabados. log_on_failure; Configura xinetd para registrar si hay una falla de conexin o si la conexin no es permitida. Cps; Configura xinetd para no permitir ms de 25 conexiones por segundo a cualquier servicio dado. Si se alcanza este lmite, el servicio es retirado por 30 segundos. includedir /etc/xinetd.d/; Incluye las opciones declaradas en los archivos de configuracin especficos del servicio localizados en el directorio /etc/xinetd.d/. Consulte la seccin 17.4.2 para ms informacin sobre este directorio.

El directorio /etc/xinetd.d/El directorio /etc/xinetd.d/ contiene los archivos de configuracin para cada servicio manejado por xinetd y los nombres de los archivos que se correlacionan con el servicio. Como sucede con xinetd.conf, este archivo slo es ledo cuando el servicio xinetd es arrancado. Para que los cambios tengan efecto, el administrador debe reiniciar el servicio xinetd. El formato de los archivos en el directorio /etc/xinetd.d/ usan las mismas convenciones que /etc/xinetd.conf. La razn principal por la que la configuracin para cada servicio es almacenada en un archivo separado es hacer ms fcil la personalizacin y que sea menos probable afectar otros servicios. Para tener una idea de cmo estos archivos estn estructurados, considere el archivo /etc/xinetd.d/telnet: service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = yes } Estas lneas controlan varios aspectos del servicio telnet: service; Define el nombre del servicio, usualmente uno listado en el archivo /etc/services.


Pgina 34

Flags; Configura cualquier nmero de atributos para la conexin. REUSE instruye xinetd a

reutilizar el socket para una conexin Telnet. socket_type; Configura el socket de red a escribir a stream. Wait; Define si el servicio es de un slo hilo (yes) o de mltiples hilos (no). User; Define bajo qu ID de usuario se ejecutar el proceso. Server; Define el binario ejecutable a lanzar. log_on_failure; Define los parmetros de registro para log_on_failure adems de aquellos ya definidos en xinetd.conf. disable; Define si el servicio est activo o no.

Modificar archivos de configuracin xinetd Opciones de registroLas siguientes opciones de registro estn disponibles para /etc/xinetd.conf y los archivos de configuracin especficos al servicio en el directorio /etc/xinetd.d/. Abajo se muestra una lista de algunas de las opciones de registro usadas ms comnmente: ATTEMPT; Indica que se intent realizar una conexin pero que sta fall (log_on_failure). DURATION; Indica el tiempo que un sistema remoto usa un servicio (log_on_success). EXIT; Indica el estado de salida o la seal de trmino del servicio (log_on_success). HOST; Indica la direccin IP de la mquina remota (log_on_failure y log_on_success). PID; Indica el ID del proceso del servidor que recibe la peticin (log_on_success). USERID; Registra el usuario remoto que est usando el mtodo definido en RFC 1413 para todos los servicios de multi procesos (log_on_failure y log_on_success). Para una lista completa de las opciones de registro, consulte la pgina de manual de xinetd.conf.

Opciones de control de accesoLos usuarios de servicios xinetd pueden seleccionar usar reglas de acceso a hosts wrapped tcp, proporcionar control de acceso a travs de los archivos de configuracin xinetd, o una mezcla de ambos. El control de acceso xinetd es diferente del mtodo usado por los wrappers tcp. Mientras que los wrapper tcp colocan toda la configuracin del acceso dentro de dos archivos, /etc/hosts.allow y /etc/hosts.deny, el control de acceso de xinetd se encuentra en el archivo de configuracin de cada servicio dentro del directorio /etc/xinetd.d. Las opciones de acceso a host siguientes son soportadas por xinetd: only_from; Slo permite que las mquinas especficas usen el servicio. no_access; Impide que estas mquinas usen el servicio. access_times; Especifica el intervalo de tiempo en el que un determinado servicio puede ser usado. El rango de tiempo debe especificarse en formato de 24 horas, hh: mm-hh:mm. Las opciones only_from y no_access pueden usar una lista de direcciones ip o nombres de hosts, o pueden especificar una red completa. Como los wrapper tcp, combinando el control del acceso xinetd con una configuracin de conexin apropiada puede mejorar la seguridad mediante el bloqueo de peticiones de hosts vetados mientras que graba cada intento de conexin. Por ejemplo, el siguiente archivo /etc/xinetd.d/telnet puede ser usado para bloquear el acceso a Telnet desde un un grupo de red particular y restringir el rango de tiempo general que inclusive los usuarios permitidos pueden conectarse: service telnet { disable flags socket_type

= no = REUSE = stream


Pgina 35

wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID no_access = 10.0.1.0/24 log_on_success += PID HOST EXIT access_times = 09:45-16:15 } En este ejemplo, cuando un sistema cliente desde la red 10.0.1.0/24, tal como 10.0.1.2, intenta accesar el servicio Telnet, recibir un mensaje indicando lo siguiente: Connection closed by foreign host. Adems, sus intentos de conexin son registrados en /var/log/secure como sigue: May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2 May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2 May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256 Cuando est usando wrapper tcp en conjunto con controles de acceso xinetd, es importante entender la relacin entre los dos mecanismos de control de acceso. A continuacin se muestra el orden de las operaciones seguido por xinetd cuando un cliente solicita una conexin: 1. El demonio xinetd accesa las reglas de acceso a hosts wrapper tcp a travs de una llamada a la librera libwrap.a. Si alguna regla de rechazo coincide con el host cliente, la conexin se rechaza. Si una regla de aceptacin coincide con el host cliente, la conexin es pasada al xinetd. 2. El demonio xinetd verifica sus propias reglas de acceso para el servicio xinetd y el servicio solicitado. Si una regla de rechazo coincide con el host cliente la conexin es rechazada. De lo contrario, xinetd inicia una instancia del servicio solicitado y pasa el control de la conexin al mismo.

Vincular y redirigir opcionesLos ficheros de configuracin de servicios para el comando xinetd tambin soportan la vinculacin del servicio a una direccin ip y el desvo de las peticiones entrantes para dicho servicio a otra direccin ip, nombre de la mquina o puerto. La vinculacin es controlada con la opcin bind que se encuentra en el archivo de configuracin especfico del servicio, y une especficamente el servicio a una direccin ip del sistema. Una vez configurada, la opcin bind slo permite peticiones para la direccin ip apropiada para accesar el servicio. De esta forma se pueden vincular servicios diferentes a interfaces de red diferentes basados en la necesidad. Esto es til sobre todo para los sistemas con mltiples adaptadores de red o con mltiples direcciones ip. En tales sistemas, los servicios inseguros como Telnet, se pueden configurar de modo que solo escuche a la interfaz conectada a una red privada, y no a la interfaz conectada a Internet.


Pgina 36

La opcin redirect acepta la direccin ip o el nombre de la mquina seguido del nmero de puerto. Dice al servicio que desve todas las peticiones para dicho servicio a una localizacin y nmero de puerto especficos. Esta caracterstica se usa para establecer otro nmero de puerto en el mismo sistema, desviar la peticin a otra direccin ip en la misma mquina, cambiar la peticin a otro sistema y puerto completamente diferentes o con la combinacin de cualquiera de estas opciones. De esta manera, un usuario que est conectado a un determinado servicio en un sistema puede ser redirigido a otro sistema sin ninguna interrupcin. El demonio xinetd lleva a cabo este desvo lanzando un proceso que mantenga la conexin entre la mquina cliente que est mandando la peticin y la mquina que est dando en ese momento el servicio, transfiriendo los datos de un sistema a otro. El mayor beneficio de estas dos opciones se obtiene cuando se usan juntas. Vinculando un servicio a una direccin ip determinada en un sistema y luego desviando las peticiones de dicho servicio a una segunda mquina que solo puede ver la primera mquina, se puede usar un sistema interno que ofrez

seguridad 1

Documents