![]() |
|
mark@grennan.com
elozanof@terra.es
mgnaranjo@terra.es
hgsoto@terra.es
alexis_martel@hotmail.com
davidfti@hotmail.com
lantnezs@idecnet.com
v0.80, 26 de febrero de 2000
Revision History | ||
---|---|---|
Revision 1.0 | octubre de 2001 | Revised by: kerberos |
Revisi�n de la primera traducci�n castellana |
Este documento est� dise�ado para describir los fundamentos de los sistemas de cortafuegos, al mismo tiempo que le explica c�mo instalar un filtro y un cortafuegos proxy en un sistema basado en Linux. La versi�n HTML de este documento se puede obtener en la siguiente direcci�n http://www.grennan.com/Firewall-HOWTO.html
David Rudder escribi� la versi�n original de este C�mo de Cortafuegos hace ya alg�n tiempo y, desde aqu�, quiero agradecerle que me permita actualizar su trabajo.
Tambi�n me gustar�a dar las gracias a Ian Gough por ayudarme en el proceso de redacci�n.
Los cortafuegos han adquirido gran popularidad de un tiempo a esta parte y se consideran el �ltimo grito en la seguridad en Internet, pero como ocurre con la mayor�a de los temas candentes, los cortafuegos a menudo han dado lugar a malentendidos. En este C�mo se explican las bases de lo que es un cortafuegos y de c�mo se pueden instalar.
Hemos utilizado kernel 2.2.13 y RedHat 6.1 para desarrollar este C�mo, y los ejemplos que aqu� se utilizan se basan, por lo tanto, en esta distribuci�n. Si encuentra diferencias en la suya, por favor, p�ngase en contacto conmigo para actualizar este C�mo.
Cualquier apoyo o cr�tica a este documento ser�n bienvenidos. �POR FAVOR, RUEGO ME COMUNIQUEN CUALQUIER INEXACTITUD QUE VEAN EN �L! No soy un experto, y puedo cometer errores. Si encuentra alg�n fallo, por favor, h�gamelo saber. Intentar� responder a todos los correos electr�nicos, pero soy una persona muy ocupada, as� que no se enfade si no lo hago.
Mi direcci�n de correo electr�nico es mark@grennan.com
NO ME HAGO RESPONSABLE POR NING�N DA�O PRODUCIDO POR ACCIONES DERIVADAS DE ESTE DOCUMENTO. Este documento pretende ser una introducci�n a los cortafuegos y los servidores proxy. No soy, ni lo pretendo ser, un experto en seguridad. Simplemente soy un tipo que ha le�do mucho y al que le gustan los computadores m�s que al resto de la gente. Por favor, escribo esto esto para ayudar a la gente a entender m�s sobre este tema, y no estoy preparado para hacer depender mi vida de la exactitud de lo que hay aqu�.
A menos que se especifique lo contrario, los documentos C�mo de Linux son propiedad intelectual de sus respectivos autores. Estos documentos C�mo de Linux se pueden reproducir y distribuir total o parcialmente en cualquier medio, ya sea f�sico o electr�nico, siempre y cuando aparezca la marca de propiedad intelectual en todas las copias. La redistribuci�n comercial est� permitida y, de hecho, se recomienda. No obstante, al autor le gustar�a que se le notificara cualquier distribuci�n de este tipo.
Todas las traducciones, trabajos derivados o trabajos de recopilaci�n que incorporen cualquier documento C�mo de Linux deben llevar la marca de propiedad intelectual, es decir, no se puede producir ning�n trabajo derivado de un Como y a�adirle restricciones adicionales a su distribuci�n. Se podr�n establecer excepciones a estas normativas bajo ciertas condiciones. Por favor, contacte con el coordinador de C�mos de Linux.
En resumen, deseamos promover la difusi�n de esta informaci�n por todos los canales posibles, pero nos gustar�a mantener la propiedad intelectual de los C�mos. Por ello, rogamos se nos comunique cualquier intenci�n de redistribuci�n de los C�mos.
Si tiene alguna duda, por favor no dude en ponerse en contacto conmigo. (V�ase arriba)
Hace varios a�os, mientras trabajaba para el estado de Oklahoma como �Administrador de Internet�, me pidieron que �pusiera al Estado en Internet�, sin presupuesto alguno. (Nota: En aquella �poca no hab�a tal puesto de trabajo; simplemente era una persona que lo hac�a todo). La mejor manera de conseguirlo era utilizar todos los "software" gratuitos y los "hardwares" que pudiera. Para ello contaba tan s�lo con Linux y con algunos equipos 486 obsoletos.
Los cortafuegos comerciales tienen precios excesivos y la documentaci�n que explica c�mo funcionan se considera de alto secreto. Por lo tanto, crear un cortafuegos propio era una tarea casi imposible.
En el siguiente encargo, me ped�an instalar un cortafuegos. Linux acababa de introducir un c�digo de cortafuegos. De nuevo, sin presupuesto, empec� a dise�ar un cortafuegos con Linux. Seis meses m�s tarde el cortafuegos ya estaba instalado y comenc� a actualizar este documento.
Un cortafuegos es una barrera para evitar que el fuego se expanda. Los edificios disponen de cortafuegos, muros de ladrillos que dividen las diferentes secciones del edificio. En un coche, un cortafuegos es la plancha de metal que separa al motor del compartimento de los pasajeros.
La misi�n de los cortafuegos de Internet es garantizar la seguridad de nuestro equipo ante los peligros cibern�ticos de la red de �rea local (LAN) o bien, mantener a los miembros de esa LAN al margen de las malignas intenciones de Internet.
El primer cortafuegos en un ordenador fue una m�quina Unix que no realizaba tareas de encaminamiento con conexiones a dos redes distintas.Una tarjeta de red conectada a Internet y la otra al LAN privado. Si quer�a acceder a Internet desde la red privada, ten�a que registrarse en un servidor (Unix) de cortafuegos. Por lo tanto, se utilizaban los recursos del sistema para acceder a Internet. Por ejemplo, podr�a utilizar X-windows para ejecutar el navegador de Netscape con el sistema de cortafuegos y poder usarlo en una estaci�n de trabajo. Con el navegador ejecutado en el cortafuegos se tiene acceso a dos redes.
Este tipo de sistema de origen dual (un sistema con dos conexiones de red) es muy bueno si tiene PLENA CONFIANZA en todos sus usuarios. Se puede instalar un sistema Linux y darle una cuenta a todo aquel que quiera tener acceso a Internet. Con esta instalaci�n, el �nico computador de su red privada que conoce todo sobre el mundo exterior es el cortafuegos. Nadie puede descargar en su computador directamente. Primero deber� descargar el fichero al cortafuegos y despu�s descargarlo del cortafuegos a sus estaci�n de trabajo.
IMPORTANTE: El 99% de las instrusiones comienza con el acceso al sistema que se va a atacar. Por esta raz�n, no se recomienda este tipo de cortafuegos, adem�s de que es muy limitado.
No crea que lo �nico que necesita es una m�quina de cortafuegos. Establezca las pol�ticas primero.
Los cortafuegos se utilizan con dos objetivos:
para denegar el acceso a los piratas y gusanos
para permitir el acceso a empleados, ni�os, etc.
Cuando empec� a trabajar con los cortafuegos, me llam� la atenci�n ver que la empresa estaba m�s interesada en espiar a sus empleados que en denegar a su red el acceso a los piratas.
Al menos en el estado de Oklahoma, los empresarios tienen derecho a hacer llamadas telef�nicas y acceder a Internet siempre y cuando se informa de ello a los empleados.
El Gran Hermano no es el gobierno. Gran Hermano = Gran Negocio.
No me malinterpreten. La gente debe trabajar, y no dedicarse a jugar durante las horas de trabajo. En mi opini�n, se est� dejando a un lado cada vez m�s la �tica del trabajo. No obstante, tambi�n he observado que son los mismos encargados los primeros que no cumplen las normas. He visto trabajadores por hora que han sido reprendidos por utilizar Internet para buscar el recorrido del autobus del trabajo a casa, mientras que los mismos directores durante horas de trabajo se dedicaban a buscar buenos restaurantes y salas de fiesta para llevar a sus futuros clientes.
Mi error antes este tipo de abusos es publicar un acceso a cortafuegos en una p�gina web para que todo el mundo lo pueda leer.
La cuesti�n de la seguridad puede ser escalofriante. Si es usted un administrador de cortafuegos, c�brase las espaldas.
Hay muchos art�culos en los que se explica c�mo crear una pol�tica de seguridad. Despu�s de muchos a�os de experiencia, les puedo recomendar que no se f�en en absoluto. Crear una pol�tica de seguridad es algo muy simple:
describa para qu� es el servicio
describa el grupo de personas a las que va dirigido el servicio
describa a qu� servicio necesita acceder cada grupo
describa, para cada grupo de servicio, c�mo se puede mantener seguro el servicio
redacte un informe en el que se considere violaci�n cualquier otro tipo de acceso
Esta pol�tica se ir� haciendo cada vez m�s compleja, no intente abarcar demasiado en este punto. Procure que sea sencilla y clara.
Hay dos tipos de cortafuegos.
Cortafuegos de filtrado - que evitar� el acceso no autorizado a determinados paquetes de la red.
Sevidores Proxies (a veces llamados cortafuegos) - encargados de establecer las conexiones a la red.
El Filtrado de Paquetes es el tipo de cortafuegos integrado en el n�cleo de Linux.
Un cortafuegos de filtrado trabaja a nivel de red. Los datos salen del sistema s�lo si las reglas del cortafuegos se lo permiten. Cuando los paquetes llegan son filtrados atendiendo al protocolo utilizado, la direcci�n fuente y destino, y la informaci�n que sobre el puerto viene contenida en cada paquete.
Muchos encaminadores o routers de red tienen la posibilidad de desarrollar servicios cortafuegos. Los cortafuegos de filtrado nos los podemos imaginar como un tipo de encaminador. Por este motivo Usted necesitar� tener un profundo conocimiento de la estructura de los paquetes IP para trabajar con uno.
Puesto que son muy pocos los datos que se analizan y registran, los cortafuegos de filtrado de paquetes requieren menos CPU y crean menos latencia en su red.
Los cortafuegos de filtrado no prev�n los controles mediante el uso de contrase�a. Los usuarios no pueden identificarse. Lo �nico que identifica a un usuario es el n�mero IP asignado a su estaci�n de trabajo. Esto puede convertirse en un problema is usted tiene la intenci�n de usar DHCP (Dynamic IP assignments). Esto se debe a que las reglas se basan en los n�meros IP que tendr� que ajustar a las reglas cuando se asignen los nuevos n�meros IP. Desconozco la forma de automatizar este proceso.
Los cortafuegos de filtrado resultan m�s transparentes para el usuario, que no tiene que establecer reglas en sus aplicaciones para acceder a Internet. No sucede los mismo con la mayor�a de los servidores proxy.
Este tipo de servidores se usa principalmente para controlar, o supervisar, el tr�fico hacia el exterior. Algunos proxy de aplicaci�n almacenan en una memoria de almacenamiento intermedio una copia local de los datos solicitados. Esto reduce el ancho de banda preciso y acelera el acceso a los mismos datos para el siguiente usuario. Ofrece una inequ�voca prueba de lo que fue transferido.
Existen dos tipos de servidores proxy
Servidores proxy de aplicaci�n - son los que hacen el trabajo por Usted.
Servidores proxy SOCKS - establecen conexiones entre puertos.
El mejor ejemplo es el de una persona que se comunica con otro computador y, desde all�, establece contacto con el mundo exterior. Con un servidor proxy de aplicaci�n el proceso se automatiza. Cuando usted se comunica con el mundo exterior el cliente le env�a a Usted primero al servidor proxy. El servidor proxy establece la comunicaci�n con el servidor que ha solicitado (el mundo exterior) y le devuelve los datos.
Los servidores proxy se encargan de manejar todas las comunicaciones, caracter�stica que le permite registrar todo lo que ellos (usted) haga. Los servidores proxy HTTP (web) tienen muy en cuenta las URL que ellos o usted visiten. Los proxy FTP incluyen cada fichero que usted descargue. Incluso pueden filtrar las palabras �inapropiadas� de los sitios que visite o escanear esos lugares en busca de virus.
Los servidores proxy de aplicaci�n pueden autenticar a los usuarios. Antes de establecer una conexi�n con el exterior, el servidor le puede pedir que se identifique primero. A un usuario de la red le pedir�a una identificaci�n para cada sitio que visite.
Un servidor proxy SOCKS se parece bastante a un panel de conmutaci�n. Tan s�lo establece la conexi�n entre su sistema y otro sistema externo.
La mayor�a de los servidores SOCKS presentan el inconveniente de que s�lo trabajan con conexiones del tipo TCP y como cortafuegos no suministran autenticaci�n para los usuarios. Sin embargo, su ventaja es que registran los sitios a los que cada usuario se ha conectado.
Existen muchas maneras de estructurar su red para proteger su sistema mediante el uso de un cortafuegos
Si tiene una conexi�n exclusiva para Internet a trav�s de un encaminador, podr�a conectarlo directamente a su sistema cortafuegos o podr�a pasar por un concentrador de red (hub) para proporcionar a los servidores que se encuentran fuera del cortafuegos un acceso completo.
Si usa un servicio conmutado como una l�nea ISDN, se podr�a usar una tercera tarjeta de red que permita disponer de una red perim�trica (DMZ). Esto proporciona un control absoluto sobre los servicios de Internet, manteni�ndolos separados de la red regular.
______________ _/\__/\_ | | ____________ | | | Sistema de | (LAN) | Estacion/ | / Internet \---| Cortafuegos |--(HUB)--| estaciones | \_ _ _ _/ |_____________| | de trabajo | \/ \/ \/ | |____________| (DMZ) (HUB)
En el encaminador existe la posibilidad de establecer algunas reglas estrictas para el filtro, siempre y cuando haya un encaminador o un m�dem de cable entre usted e Internet y usted sea el propietario del encaminador. Si el propietario del encaminador es su ISP y, en este caso, no tiene los controles que necesita, puede pedir a su ISP que agregue los filtros.
____________ _____________ _/\__/\_ |Encaminador| | | | | | o | (DMZ) | Sistema | (LAN) / Internet \--|Cablem�dem |--(HUB)--| Cortafuegos|--(HUB) \_ _ _ _/ |___________| | |____________| | \/ \/ \/ | | (Servidor) _______+____ (Externo) |Estacion/ | |Estaciones | |de Trabajo | |___________|
Si tiene que controlar por d�nde se mueven los usuarios de su red, la cual es peque�a, puede integrar un servidor proxy en su cortafuegos. Algunas veces, los ISP lo hacen para confeccionar una lista de inter�s de sus usuarios con el fin de revenderlas a agencias de marketing.
_____________ _/\__/\_ | Sistema | _______________ | | | Proxy/ | (LAN) | Estaci�n/ones | / Internet \----| Cortafuegos |--(HUB)--| de trabajo | \_ _ _ _/ |_____________| |_______________| \/ \/ \/
Si lo prefiere, puede integrar el servidor proxy en su LAN, en cuyo caso, el cortafuegos debe poseer unas �rdenes que hagan posible que el servidor proxy s�lo se conecte a Internet para aquellos servicios que ofrece. De esta manera, los usuarios s�lo podr�n acceder a Internet a trav�s del proxy.
_____________ _/\__/\_ | | ________________ | | | Cortafuegos | (LAN) | Estacion/ones | / Internet \----| Sistema |--(HUB)--| de trabajo | \_ _ _ _/ |_____________| | |________________| \/ \/ \/ | | __________ | | Servidor | |+----| Proxy | |__________|
Si va a ejecutar un servicio como YAHOO o, tal vez, SlashDot, puede que desee compilar un programa multim�dulo en su sistema empleando encaminadores redundantes y cortafuegos. ( Vea el C�mo de Alta Disponibilidad.)
Mediante la utilizaci�n de t�cnicas de circuito c�clico DNS para dar acceso a varios servidores web desde una URL y varios ISP, es posible crear un servicio de funcionamiento �ptimo del 100% con encaminadores y cortafuegos que usan t�cnicas de alta disponibilidad.
_/\__/\_ _/\__/\_ | | | | / ISP #1 \______ (WAN)______/ Socios \ \_ _ _ _/ | (HUB) \_ _ _ _/ \/ \/ \/ | ___|____ \/ \/ \/ __|____ |_______ | ______ _/\__/\_ |______ | |Sistemas|| |Est. | | | |Enca- || (DMZ) |Corta- || (LAN) |Trab./| / ISP #2 \--|minador||--(HUB)--| fuegos ||--(HUB)--|Serv. | \_ _ _ _/ |________| | |________| | |______| \/ \/ \/ | | | ______ | (Servidor) (Servidor) | | | ------ | (Externo) (Compartido) +---|Proxy | |Est. | | |______| |Trab./|-+ |Serv. | |VPN | |______|
Es muy f�cil que la red se le vaya de las manos. Verifique cada conexi�n. Todo lo que necesita es un usuario con su m�dem para comprometer su LAN.
Los cortafuegos filtrados no requieren de un hardware muy sofisticado. Son poco m�s que simples encaminadores.
Todo lo que necesita es:
un 486-DX66 con 32 megas de memoria RAM
un disco 250m (se recomienda uno de 500)
conexiones a la red (tarjetas LAN, puertos serie, �inal�mbricos?)
monitor y teclador
Algunos sistemas que usan una consola con puerto serie pueden, incluso, prescindir del monitor y del teclado.
Si necesita un servidor proxy que soporte mucho tr�fico, deber�a conseguir el sistema m�s completo que pueda permitirse. Esto se debe a que cada vez que un usuario se conecta al sistema, �ste crear� otro proceso.Si tuviese 50 o m�s usuarios fijos, estimo que necesitar�:
un Pentium II con 64 megas de memoria
un disco duro con dos gigas para almacenar todas las operaciones de registro
dos conexiones a la red
un monitor y un teclado
Para crear un cortafuegos de filtrado no es necesario ning�n software especial. Linux lo har�. En el momento de escribir este C�mo, estoy usando RedHat 6.1.
La construcci�n en Linux del cortafuegos ha cambiado varias veces. Si est� utilizando un n�cleo antiguo de Linux (1.0.x o anterior) h�gase con una nueva copia. Los m�s antiguos usaban ipfwadm de http://www.xos.nl/linux/ipfwadm/ que ya no est� admitido.
Si est� usando 2.2.13 o superior, estar� usando ipchaining, que aparec�a en http://www.rustcorp.com/linux/ipchains/
Si est� utilizando el n�cleo m�s reciente 2.4, hay una nueva utilidad de cortafuegos con m�s caracter�sticas. Pronto escribir� sobre ello.
Si desea establecer un servidor proxy, necesitar� uno de estos dos paquetes:
Squid
El TIS Firewall Toolkit (FWTK)
SOCKS
Squid es un gran paquete y trabaja con la caracter�stica de Proxy Transparente de Linux. Le indicar� c�mo instalar este servidor.
En el momento de redactar este C�mo, se han fusionado Network Associates y Trusted Information System's (TIS). As� que mant�ngase atento a los sitios web para ver m�s informaci�n sobre Tool Kit puede a�n ser descargado desdehttp://www.tis.com/research/software/
Trusted Information System saca a la luz una colecci�n de programas dise�ados para facilitar la creaci�n de cortafuegos. Con este toolkit, usted instala un demonio para el servicio (WWW, telnet ect.) que est� usando en cada momento.
Instale tan s�lo lo imprescindible del sistema Linux. Mi instalaci�n comenz� con la configuraci�n del servidor y luego desactiv� todos los servicios en /etc/inetd.conf. Para m�s seguridad, deber� desinstalar los servicios innecesarios.
Puesto que la mayor�a de las distribuciones no disponen de un n�cleo que se adapte a sus necesidades, ser� preciso que compile su propio n�cleo. Lo mejor ser� hacerlo con otro computador que no sea el cortafuegos. Si usted ha instalado un compilador C y otras utilidades en su cortafuegos, desinst�lelos despu�s de completar la configuraci�n del n�cleo.
Comience con una instalaci�n m�nima de su distribuci�n Linux. Cuantos menos programas cargue, menos agujeros, puertas traseras o fallos introducir�n problemas de seguridad en su servidor.
Use un n�cleo estable. Yo uso el n�cleo 2.2.13 en mi sistema, por lo que esta documentaci�n se basa en la instalaci�n en ese n�cleo.
Necesitar� recompilar el n�cleo Linux con las opciones apropiadas. Si usted no ha recompilado antes su n�cleo, lea el C�mo N�cleo, el C�mo Ethernet, y el C�mo NET-2.
Aqu� tiene la configuraci�n relativa a la red en la que trabajo. He marcado algunas l�neas con ?. Si usted usa esta aplicaci�n, act�vela tambi�n.
Yo uso "make menuconfig" para editar la configuraci�n de mi n�cleo.
<*> Packet socket [ ] Kernel/User netlink socket [*] Network firewalls [ ] Socket Filtering <*> Unix domain sockets [*] TCP/IP networking [ ] IP: multicasting [*] IP: advanced router [ ] IP: kernel level autoconfiguration [*] IP: firewalling [?] IP: always defragment (required for masquerading) [?] IP: transparent proxy support [?] IP: masquerading --- Protocol-specific masquerading support will be built as modules. [?] IP: ICMP masquerading --- Protocol-specific masquerading support will be built as modules. [ ] IP: masquerading special modules support [*] IP: optimize as router not host < > IP: tunneling < > IP: GRE tunnels over IP [?] IP: aliasing support [*] IP: TCP syncookie support (not enabled per default) --- (it is safe to leave these untouched) < > IP: Reverse ARP [*] IP: Allow large windows (not recommended if <16Mb of memory) < > The IPv6 protocol (EXPERIMENTAL) --- < > The IPX protocol < > Appletalk DDP < > CCITT X.25 Packet Layer (EXPERIMENTAL) < > LAPB Data Link Driver (EXPERIMENTAL) [ ] Bridging (EXPERIMENTAL) [ ] 802.2 LLC (EXPERIMENTAL) < > Acorn Econet/AUN protocols (EXPERIMENTAL) < > WAN router [ ] Fast switching (read help!) [ ] Forwarding between high speed interfaces [ ] PU is too slow to handle full bandwidth QoS and/or fair queueing --->
Despu�s de realizar la configuraci�n que usted necesita, deber� recompilar, reinstalar el n�cleo y reiniciar.
Use la orden:
make dep; make clean; make bzlilo; make modules; make modules_install;init 6 para llevarlo a cabo en un solo paso
Si su ordenador dispone de dos tarjetas de red, necesitar� a�adir una l�nea adicional a su fichero /etc/lilo.conf para describir el IRQ y la direcci�n de ambas tarjetas. La l�nea adicional ser� similar a �sta:
append="ether=12,0x300,eth0 ether=15,0x340,eth1"
Ahora comienza la parte divertida de la instalaci�n. No entrar� en detalles sobre c�mo instalar una LAN, para ello, lea el C�mo de redes en Linux.
Nuestro objetivo es disponer de dos conexiones a red para su sistema de filtro cortafuegos. Uno en el lado de Internet (el lado inseguro) y el otro en el LAN (el lado seguro).
De todas formas, tendr� que tomar decisiones.
�Usar� un n�mero de direcci�n IP real, o se inventar� alguno para su LAN?
�Su ISP asignar� la direcci�n IP din�micamente, o usar� direcciones IP fijos?
Puesto que lo que usted quiere es que desde Internet no se pueda acceder a su red privada, no deber� utilizar "direcciones reales", simplemente inv�ntese direcciones para su LAN privada. Esto no es muy recomendable, porque si los datos salen de su LAN, podr�an terminar en el puerto de otro sistema.
Existe un rango de n�meros de direcci�n para Internet destinado a redes privadas. Este rango es 192.168.1.xxx, el mismo que usaremos en nuestros ejemplos.
Para ello necesitar� usar la m�scara IP. Con este proceso, el cortafuegos enviar� paquetes y los traducir� a una direcci�n IP "REAL " " para navegar por Internet.
Usando una direcci�n IP sin ruta, su red ser� m�s segura. Los encaminadores de Internet no pasar�n paquetes con estas direcciones.
Llegado este punto puede resultar aconsejable que lea el C�mo de IP Masquerade.
24.94.1.123 ____________ 192.168.1.1 _/\__/\_ \ | | / _______________ | | \| Sistema |/ | Estaci�n/ones | / Internet \--------| Cortafuegos |----------| de Trabajo | \_ _ _ _/ |_____________| |_______________| \/ \/ \/
Deber� tener una direcci�n IP "real" para asignarle su tarjeta IP de red. Esta direcci�n le podr� ser asignada permanentemente. (Una direcci�n IP fija) o se le podr� asignar un tiempo de conexi�n a la red por el proceso PPP.
Elija el n�mero IP interno. Por ejemplo, 192.168.1.1 a la tarjeta LAN. Esta ser� su direcci�n IP de puerta de enlace. De la misma forma, se podr� asignar a los dem�s computadores de la red protegida (LAN) un n�mero del rango 192.168.1.xxx. (192.168.1.2 hasta 192.168.1.254)
Yo uso RedHat Linux para configurar la red y a�ado un fichero ifcfg-eth1 en el directorio /etc/sysconfig/network-scripts. Tambi�n podr� encontrar un fichero ifcfg-ppp0 o ifcfg-tr0 en este directorio. Estos ficheros 'ifcfg-' se usan en RedHat para configurar y desactivar los dispositivos de red al reiniciar el equipo, y se ejecutan despu�s de la conexi�n. Se nombran despu�s del tipo de conexi�n.
Aqu� mostramos el fichero ifcfg-eth1 (segunda tarjeta ehternet) como ejemplo;
DEVICE=eth1 IPADDR=192.168.1.1 NETMASK=255.255.255.0 NETWORK=192.168.1.0 BROADCAST=192.168.1.255 GATEWAY=24.94.1.123 ONBOOT=yes
Si usa una conexi�n conmutada, necesitar� ver los ficheros ifcfg-ppp0 y chat-ppp0, que controlan su conexi�n PPP.
El fichero ifcfg debe tener un aspecto parecido al siguiente:
DEVICE="ppp0" ONBOOT="yes" USERCTL="no" MODEMPORT="/dev/modem" LINESPEED="115200" PERSIST="yes" DEFABORT="yes" DEBUG="yes" INITSTRING="ATZ" DEFROUTE="yes" HARDFLOWCTL="yes" ESCAPECHARS="no" PPPOPTIONS="" PAPNAME="LoginID" REMIP="" NETMASK="" IPADDR="" MRU="" MTU="" DISCONNECTTIMEOUT="" RETRYTIMEOUT="5" BOOTPROTO="none"
Empiece usando las �rdenes ifconfig y route. Si usted tiene dos tarjetas de red, ifconfig deber� presentar un aspecto similar a �ste:
# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:1620 errors:0 dropped:0 overruns:0 TX packets:1620 errors:0 dropped:0 overruns:0 collisions:0 txqueuelan:0 eth0 Link encap:10Mbps Ethernet HWaddr 00:00:09:85:AC:55 inet addr:24.94.1.123 Bcast:24.94.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1000 errors:0 dropped:0 overruns:0 TX packets:1100 errors:0 dropped:0 overruns:0 collisions:0 txqueuelan:0 Interrupt:12 Base address:0x310 eth1 Link encap:10Mbps Ethernet HWaddr 00:00:09:80:1E:D7 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1110 errors:0 dropped:0 overruns:0 TX packets:1111 errors:0 dropped:0 overruns:0 collisions:0 txqueuelan:0 Interrupt:15 Base address:0x350
y su tabla de encaminado similar a:
# route -n Kernel routing table Destination Gateway Genmask Flags MSS Window Use Iface 24.94.1.0 * 255.255.255.0 U 1500 0 15 eth0 192.168.1.0 * 255.255.255.0 U 1500 0 0 eth1 127.0.0.0 * 255.0.0.0 U 3584 0 2 lo default 24.94.1.123 * UG 1500 0 72 eth0
Nota: 24.94.1.0 se encuentra en lado de Internet del cortafuegos y 192.168.1.0 en el lado de la red privada (LAN).
Aseg�rese de que todos los computadores de su LAN puedan conectar con la direcci�n interna de su sistema cortafuegos. (192.168.1.1 en este ejemplo) Si no conectan, vuelva al C�mo de Redes en Linux y trabaje en la red un poco m�s.
Luego, desde el cortafuegos, trate de conectar con Internet. Yo uso www.internic.net com p�gina de prueba. Si no funciona, int�ntelo con un servidor de su ISP. Si a�n as� no funciona, es que alguna parte de su conexi�n a Internet es err�nea. Desde el cortafuegos, deber�a poder conectarse a cualquier direcci� de Internet. Trate de revisar la configuraci�n de su puerta de enlace por defecto. Si usted usa una conexi�n conmutada, revise su nombre (ID) y contrase�a (Password), relea el C�mo Net-2, e int�ntelo de nuevo.
A continuaci�n, trate de conectar con la direcci�n externa del cortafuegos (24.94.1.123) desde el computador de su LAN. Esto no deber�a ser posible, pero si lo consigue es que la m�scara o el IP Forwarding est�n activados, o que ya se han filtrado grupos de paquetes. Apague los equipos e int�ntelo de nuevo, puesto que necesita saber si el filtro est� activo.
Para n�cleos posteriores al 2.1.102 pueder usar la orden;
echo "0" > /proc/sys/net/ipv4/ip_forward
Si usa un n�cleo anterior (�por qu�?), necesitar� recompilar su n�cleo con el reenv�o de paquetes desactivado. (O mejor actual�celo)
Intente conectar de nuevo con la direcci�n externa del cortafuegos (24.94.1.123). Ahora no deber�a conseguirlo.
Conecte a continuaci�n el reenv�o de paquetes o la m�scara. Deber�a ser capaz de conectar con cualquier p�gina de Internet desde cualquier equipo de su LAN.
echo "1" > /proc/sys/net/ipv4/ip_forward
NOTA IMPORTANTE: Si usted usa una direcci�n IP "REAL" (que no sea 192.168.1.*) y no puede conectar con Internet, pero PUEDE hacerlo desde el lado de Internet del cortafuegos, aseg�rese de que su proveedor de servicios de internet (ISP) encamina paquetes para la direcci�n de su red privada.
Una manera de comprobarlo es que alg�n amigo, usando un proveedor local, se conecte con su red. Si la conexi�n se detiene en el encaminador de su proveedor, entonces no permiten la entrada de informaci�n.
�Funciona? Estupendo. La parte m�s dif�cil ha terminado.
Un cortafuegos es in�til si el sistema en el que est� instalado es vulnerable a ataques externos. Un "chico malo" podr�a acceder desde un servicio sin cortafuegos y modificar el sistema seg�n sus propias necesidades. Usted tendr� que desactivar cualquier servicio innecesario.
Mire el fichero /etc/inetd.conf Con �l se configurar� el inetd, tambi�n llamado "super servidor", que controla varios servidores demonio y los inicia, cuando se requiere, por un paquete que llega a un puerto "bien conocido".
Deber� desactivar cualquier echo, discard, daytime, chargen, ftp, gopher, shell, login, exec, talk, ntalk, pop-2, pop-3, netstat, systat, tftp, bootp, finger, cfinger, time, swat que tenga en su cortafuegos.
Para apagarlo, ponga # como primer car�cter de la l�nea de servicio. Una vez hecho esto, env�e un SIG-HUP al proceso mediante la orden "kill -HUP <pid>", donde <pid> es el n�mero de preocesos de inetd. Con esto, el inetd se releer� su fichero de configuraci�n (inetd.conf) y reiniciar� sin apagar el sistema.
Compru�belo haciendo telnet al puerto 15 (netstat) de su cortafuegos. Si se produce una salida de informaci�n por pantalla, no ha desactivado todos los servicios.
telnet localhos 15
Usted tambi�n puede crear el fichero /etc/nologin. Escriba unas cuantas l�neas de texto del tipo (MORRALLA RELLENO). Una vez creado el fichero, la entrada de identificaci�n no permitir� la conexi�n al usuario. Podr� ver los contenidos de este fichero pero no podr� conectar. S�lo root puede hacerlo.
Tambi�n puede editar el fichero /etc/securetty. Si el usuario es root, entonces la entrada de identificaci�n debe estar registrada en una tty listada en /etc/securetty. Los errores se registrar�n en la utilidad syslog. Con estas dos medidas activadas, la �nica manera de conectar con el cortafuegos ser� desde la consola de root.
NUNCA haga un telnet a un sistema identific�ndose como root. Si necesita realizar acceso root remoto utilice SSH (Secure Shell); tal vez deber�a incluso desactivar telnet.
Si es usted realmente paranoico tendr� que usar el "lids" (Linux Intrusion Detect System), un parche para el n�cleo de Linux que detecta cualquier intrusi�n en el sistema; el "lids" protege ficheros importantes impidiendo su modificaci�n. Una vez activado, nadie (incluyendo root) puede modificar ficheros, directorios o subdirectorios, a menos que reinicie el sistema con la opci�n de LILO security=1, especialmente concebido para modificar ficheros protegidos. (Yo iniciar�a adem�s el equipo en el modo de usuario �nico).
Si est� usando el n�cleo 2.1.102 o uno m�s reciente, vaya directamente a la secci�n sobre IPCHAINS.
En versiones anteriores al reenv�o de paquetes IP se activa por defecto en el n�cleo y, por eso, su red deber� comenzar deneg�ndole el acceso a todo y purgando cualquier orden ipfw que fuera ejecutada por �ltimas vez. Este fragmento del gui�n debe entrar en el de arranque de red. (/etc/rc.d/init.d/network)
# # setup IP packet Accounting and Forwarding # # Forwarding # # By default DENY all services ipfwadm -F -p deny # Flush all commands ipfwadm -F -f ipfwadm -I -f ipfwadm -O -f
Este es el �ltimo cortafuegos y nada podr� atravesarlo.
Ahora cree el fichero /etc/rc.d/rc.firewall. Este gui�n permitir� tr�fico de correo, web y DNS ;-)
#! /bin/sh # # rc.firewall # # Bibioteca de funciones fuente . /etc/rc.d/init.d/functions # Obtenemos la configuracion . /etc/sysconfig/network # Comprobamos que la red esta activada. if [ ${NETWORKING} = "no" ] then exit 0 fi case "$1" in start) echo -n "Iniciando servicios de cortafuego: " # Permitir que el correo llegue # hasta el servidor de correo /sbin/ipfwadm -F -a accept -b -P tcp \ -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25 # Permitir conexiones de correo # hacia los servidores de correo externos /sbin/ipfwadm -F -a accept -b -P tcp \ -S 192.1.2.10 25 -D 0.0.0.0/0 1024:65535 # Permitir conexiones de correo # hasta nuestro servidor Web /sbin/ipfwadm -F -a accept -b -P tcp \ -S 0.0.0.0/0 1024:65535 -D 192.1.2.11 80 # Permitir conexiones web # hacia los servidores web externos /sbin/ipfwadm -F -a accept -b -P tcp \ -S 192.1.2.* 80 -D 0.0.0.0/0 1024:65535 # Permitir trafico DNS /sbin/ipfwadm -F -a accept -b -P udp \ -S 0.0.0.0/0 53 -D 192.1.2.0/24 ;; stop) echo -n "Deteniendo los servicios de cortafuegos: " ipfwadm -F -p deny ;; status) echo -n "Se muestran ahora estad�sticas del cortafuegos?" ;; restart|reload) $0 stop $0 start ;; *) echo "Uso: firewall {start|stop|status|restart|reload}" exit 1 esac
NOTA: En este ejemplo tenemos el servidor de e-mail (smtp) ejecut�ndose en el 192.1.2.10, el cual debe ser capaz de recibir y enviar al puerto 25 (servidor web ejecut�ndose en el 192.1.2.11). As�, estamos permitiendo a cualquiera en el LAN acceder a redes externas y servidores DNS.
Sin embargo, esto no es muy seguro, ya que el puerto 80 no tiene que usarse como puerto de web, pues un hacker habilidoso podr�a usar este puerto para crear una red virtual privada (VPN) a trav�s del cortafuegos. La forma de evitar esto es instalar un web proxy y s�lo permitir actuar al proxy a trav�s del cortafuegos. As�, los usuarios de LAN tendr�an que atravesar el proxy para acceder a servidores de web externos.
Usted podr� estar interesado en eliminar tr�fico a trav�s de su cortafuegos. Este gui�n contabilizar� cualquier paquete y usted podr� a�adir una o dos l�neas para eliminar los paquetes destinados a un �nico sistema.
# Flush the current accounting rules ipfwadm -A -f # Accounting /sbin/ipfwadm -A -f /sbin/ipfwadm -A out -i -S 192.1.2.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 192.1.2.0/24 /sbin/ipfwadm -A in -i -S 192.1.2.0/24 -D 0.0.0.0/0 /sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 192.1.2.0/24
Si todo lo que usted necesita es un cortafuegos de filtro, puede parar aqu�. Pru�belo y disfr�telo.
Ipchains es una nueva versi�n del c�digo cortafuegos en Linux IPv4 y de ipfwadm, que, seg�n creo, deriva del c�digo de filtrado en BSD (ipfw). Para poder administrar los filtros de paquete IP en Linux, se requiere una versi�n del n�cleo 2.1.102 o superior.
Las limitaciones del c�digo de filtrado BSD (ipfw) son que no trabaja con fragmentos, tiene contadores de 32 bits (al menos en Intel), s�lo puede manejar los protocolos TCP, UDP o ICMP, no permite hacer grandes cambios de forma autom�tica, no permite especificar reglas inversas, presenta algunas anomal�as, y, sin embargo, puede servir para gestionar (aunque es m�s f�cil que se comentan errores). Al menos, eso es lo que dice el autor.
En realidad, no voy a profundizar sobre c�mo controlar un cortafuegos IPChains, porque sobre ello ya existe un �GRAN! C�mo en la direcci�n http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html. Simplemente acabar�a duplic�ndolo aqu�. Apuntar� los conceptos b�sicos.
Empieza con tres listas de reglas denominadas "chains" (cadenas): input, output y forward, que no se pueden borrar. Usted mismo puede crear cadenas y, entonces, las reglas pueden ser insertadas o eliminadas desde ese conjunto de reglas.
Las operaciones para trabajar con cadenas completas son:
Crear una nueva cadena (-N).
Borrar un cadena vac�a (-X).
Cambiar la pol�tica por defecto de una cadena (-P).
Listar las reglas contenidas en una cadena (-L).
Vaciar una cadena eliminando las reglas que contiene (-F).
Poner a cero los contadores de bytes y de paquetes en todas las reglas de una cadena (-Z).
Existen varias formas de maninpular las reglas de una cadena:
A�adir una nueva reglas a una cadena ya existente (-A).
Insertar una nueva reglas en una posici�n determinada en una cadena (-I).
Reemplazar la regla que ocupa una posici�n determinada en una cadena (-R).
Eliminar la regla que ocupa una posici�n determinada en una cadena (-D).
Eliminar la primera regla igual a la especificada de entre todas las reglas de una cadena (-D).
Tambi�n hay algunas operaciones relativas al enmascaramiento IP, a falta de un lugar mejor donde colocarlas:
Ver una lista de todas las conexiones actuales que est�n siendo enmascaradas (-M -L).
Establecer el tiempo de espera m�ximo para una conexi�n enmascarada (-M -S).
Hay algunos elementos de la temporalizaci�n que pueden alterar las reglas del cortafuegos; por ello, si no es usted cuidadoso, podr�a dejar pasar alg�n paquete mientras realiza los cambios. Una aproximaci�n simple es hacer lo siguiente:
# ipchains -I input 1 -j DENY # ipchains -I output 1 -j DENY # ipchains -I forward 1 -j DENY
... hacer los cambios ...
# ipchains -D input 1 # ipchains -D output 1 # ipchains -D forward 1 #
Esto evitar� que entren paquetes mientras usted est� realizando los cambios.
Aqu� le presento un duplicado de las reglas del cortafuegos anterior en una IPChains.
#!/bin/sh # # rc.firewall # ## Flush everything, start from scratch /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -F forward ## Redirect for HTTP Transparent Proxy #$IPCHAINS -A input -p tcp -s 192.1.2.0/24 \ -d 0.0.0.0/0 80 -j REDIRECT 8080 ## Create your own chain /sbin/ipchains -N my-chain # Allow email to got to the server /sbin/ipchains -A my-chain -s 0.0.0.0/0 smtp \ -d 192.1.2.10 1024:-j ACCEPT # Allow email connections to outside email servers /sbin/ipchains -A my-chain -s 192.1.2.10 \ -d 0.0.0.0/0 smtp -j ACCEPT # Allow Web connections to your Web Server /sbin/ipchains -A my-chain -s 0.0.0.0/0 www \ -d 192.1.2.11 1024: -j ACCEPT # Allow Web connections to outside Web Server /sbin/ipchains -A my-chain -s 192.1.2.0/24 1024: \ -d 0.0.0.0/0 www -j ACCEPT # Allow DNS traffic /sbin/ipchains -A my-chain -p UDP -s 0.0.0.0/0 dns \ -d 192.1.2.0/24 -j ACCEPT ## If you are using masquerading # don't masq internal-internal traffic /sbin/ipchains -A forward -s 192.1.2.0/24 \ -d 192.1.2.0/24 -j ACCEPT # don't masq external interface direct /sbin/ipchains -A forward -s 24.94.1.0/24 \ -d 0.0.0.0/0 -j ACCEPT # masquerade all internal IP's going outside /sbin/ipchains -A forward -s 192.1.2.0/24 \ -d 0.0.0.0/0 -j MASQ ## Deny everything else /sbin/ipchains -P my-chain input DENY
No se detenga aqu�. Este cortafuegos no es muy grande y estoy seguro de que usted tiene otros servicios que le pueden ayudar. Por ello, lea de nuevo el C�mo IPCHAINS.
El servidor proxy squid est� disponible en http://www.squid-cache.org/.
Los desarrolladores SQUID incluyen los paquetes RedHat y Debian. Si puede, use el paquete espec�fico de su distribuci�n.
El TIS FWTK se puede conseguir en http://www.tis.com/research/software/.
No cometa el mismo error que yo comet�. Cuando transfiera los archivos desde TIS, LEA EL APARTADO "L�AME". El TIS fwtk se encuentra bloqueado en un directorio oculto de su servidor.
TIS requiere que lea sus condiciones en http://www.tis.com/research/software/fwtk_readme.html y luego env�e un e-mail a fwtk-request@tislabs.com con la palabra accepted en el cuerpo del mensaje para conocer el nombre del directorio oculto. No es necesario que escriba ning�n asunto en el mensaje. Posteriormente, su sistema le enviar� el nombre del directorio (v�lido durante 12 horas) para descargar la fuente.
La versi�n 2.1. del FWTK resulta m�s f�cil de compilar que cualquier versi�n previa.
La versi�n 2.1 del FWTK se compila mucho m�s f�cilmente que cualquiera de las versiones anteriores.
Ejecute make ahora.
Ejecute make install.
El directorio de la instalaci�n por defecto es /usr/local/etc. Podr�a cambiarlo a un directorio m�s seguro. Yo opt� por cambiar el acceso a este directorio por chmod 700.
Por �ltimo, s�lo queda configurar el cortafuegos.
Ahora es cuando realmente empieza lo divertido. Debemos ense�ar al sistema a denominar a estos nuevos servicios y a crear las tablas para controlarlos.
No voy a intentar rescribir aqu� el manual de TIS FWTK. Le mostrar� la configuraci�n que encontr� hecha y explicar� los problemas que me surgieron y c�mo los solucion�.
Los archivos que componen estos controles son tres:
/etc/services
Le dice al sistema en qu� puertos se encuentra un servicio.
/etc/inetd.conf
Le dice a inetd a qu� programa llamar cuando alguien intenta conectarse a un puerto de servicio.
/usr/local/etc/netperm-table
Le dice a los servicios FWTK a qui�n admitir y a qui�n denegar el servicio.
Para conseguir que el FWTK funcione, debe editar estos archivos de abajo hacia arriba. Editar el archivo de servicios sin haber configurado correctamente el archivo inetd.conf o netperm-table, podr�a hacer su sistema inaccesible.
Este archivo controla qui�n puede acceder a los servicios del TIS FWTK. Deber�a pensar en el tr�fico y usar el cortafuegos desde ambos lados. La gente que se encuentre fuera de su red deber�a identificarse antes de poder tener acceso, y la que se encuentre dentro podr�a acceder directamente.
Para que la gente pueda identificarse, el cortafuegos utiliza un program llamado authsrv para tener una base de datos con los n�meros de identificaci�n (IP) y contrase�as de los usuarios. La secci�n de autenticaci�n de netperm-table controla d�nde se guarda la base de datos y qui�n puede tener acceso a ella.
Tuve algunos problemas a la hora de cerrar el acceso a este servicio. Observe que la entrada premit-hosts que muestro usa un *' para dar acceso a cualquiera. Si consigue que funcione, la configuraci�n correcta para esta l�nea es '' authsrv: premit-hosts localhost.
# # Tabla de configuraci�n del proxy # # Reglas de autenticaci�n de clientes y servidores authsrv: database /usr/local/etc/fw-authdb authsrv: permit-hosts * authsrv: badsleep 1200 authsrv: nobogus true # Client Applications using the Authentication server *: authserver 127.0.0.1 114
Para iniciar la base de datos debe hacerlo desde el usuario root y ejecutar ./authsrv en el directorio /var/local/etc para crear el registro administrativo del usuario. A continuaci�n tiene un ejemplo de una sesi�n.
Lea la documentaci�n FWTK para aprender a a�adir usuarios y grupos.
# # authsrv authsrv# list authsrv# adduser admin "Auth DB admin" ok - user added initially disabled authsrv# ena admin enabled authsrv# proto admin pass changed authsrv# pass admin "plugh" Password changed. authsrv# superwiz admin set wizard authsrv# list Report for users in database user group longname ok? proto last ------ ------ ------------------ ----- ------ ----- admin Auth DB admin ena passw never authsrv# display admin Report for user admin (Auth DB admin) Authentication protocol: password Flags: WIZARD authsrv# ^D EOT #
Los controles de la puerta de enlace telnet (tn-gw), son muy sencillos y son los primeros que deber�a instalar.
En mi ejemplo, dejo que el sistema que se encuentra en la red privada tenga acceso sin tener que identificarse (permit-hosts 19961.2.* -passok), pero el resto de los usuarios deben introducir su n�mero de identificaci�n y contrase�a para poder usar el proxy (permit-hosts * -auth)
Tambi�n dejo que otro sistema aparte (192.1.2.202) tenga acceso directo al cortafuegos sin tener que pasar por �ste. Existen dos l�neas inetacl-in.telnetd para hacerlo. M�s tarde explicar� c�mo se llaman estas l�neas.
El intervalo de espera (timeout) de Telnet deber� ser corto.
# telnet gateway rules: tn-gw: denial-msg /usr/local/etc/tn-deny.txt tn-gw: welcome-msg /usr/local/etc/tn-welcome.txt tn-gw: help-msg /usr/local/etc/tn-help.txt tn-gw: timeout 90 tn-gw: permit-hosts 192.1.2.* -passok -xok tn-gw: permit-hosts * -auth # Only the Administrator can telnet # directly to the Firewall via Port 24 netacl-in.telnetd: permit-hosts 192.1.2.202 \ -exec /usr/sbin/in.telnetd
Las �rdenes que empiezan con la letra r- funcionan de la misma manera que telnet.
# rlogin gateway rules: rlogin-gw: denial-msg /usr/local/etc/rlogin-deny.txt rlogin-gw: welcome-msg /usr/local/etc/rlogin-welcome.txt rlogin-gw: help-msg /usr/local/etc/rlogin-help.txt rlogin-gw: timeout 90 rlogin-gw: permit-hosts 192.1.2.* -passok -xok rlogin-gw: permit-hosts * -auth -xok # Only the Administrator can telnet #directly to the Firewall via Port netacl-rlogind: permit-hosts 192.1.2.202 \ -exec /usr/libexec/rlogind -a
No deber�a permitir que nadie, incluyendo el FTP, acceda directamente a su cortafuegos; por lo tanto, no le ponga un servidor FTP.
Una vez m�s, la l�nea de acceso de los sitemas principales permite que cualquiera que se encuentre en la red protegida tenga libre acceso a Internet, mientras que los dem�s deben identificarse. Inclu� el registro de cada fichero enviado, as� como los que recib� en mis controles. (-log { retr stor })
El intervalo de espera ftp controla el tiempo que tardar� en cortarse una mala conexi�n, as� como el tiempo que se mantendr� abierta la conexi�n sin que sea usada.
# ftp gateway rules: ftp-gw: denial-msg /usr/local/etc/ftp-deny.txt ftp-gw: welcome-msg /usr/local/etc/ftp-welcome.txt ftp-gw: help-msg /usr/local/etc/ftp-help.txt ftp-gw: timeout 300 ftp-gw: permit-hosts 192.1.2.* -log { retr stor } ftp-gw: permit-hosts * -authall -log { retr stor }
La web, el gopher y el navegador basado en el ftp se modifican con el http-gw. Las dos primeras l�neas crean un directorio para almacenar el ftp y los documentos de la web a medida que pasan por el cortafuegos.Estos ficheros los creo bajo una ra�z y los coloco en un directorio al que s�lo se puede acceder a trav�s de esa ra�z.
La conexi�n a la web deber� ser corta. Controla el tiempo que tendr� esperar el usuario en el transcurso de una mala conexi�n.
# www and gopher gateway rules: http-gw: userid root http-gw: directory /jail http-gw: timeout 90 http-gw: default-httpd www.afs.net http-gw: hosts 192.1.2.* -log { read write ftp } http-gw: deny-hosts *
Realmente, la ssl-gw es una puerta de enlace. Tenga cuidado con esto. En este ejemplo dejo que cualquiera que se encuentre en la red protegida se conecte a cualquier servidor externo a la red, excepto a las direcciones 127.0.0.* y 192.1.1.*, y s�lo de los puertos del 443 al 563. Los puertos del 443 al 563 se conocen como puertos SSL.
# ssl gateway rules: ssl-gw: timeout 300 ssl-gw: hosts 192.1.2.* \ -dest { !127.0.0.* !192.1.1.* *:443:563 } ssl-gw: deny-hosts *
A continuaci�n hay un ejemplo sobre c�mo usar la conexi�n gw para permitir las conexiones a un servidor de noticias. En este ejemplo, dejo que cualquiera que se encuentre dentro de la red protegida se conecte a un solo sistema y a su puerto de noticias.
La segunda l�nea permite al servidor de noticias transferir sus datos a la red protegida.
Dado que la mayor�a de clientes permanecen conectados mientras el usuario lee los datos, el intervalo de espera de un servidor de datos deber� ser largo.
# NetNews Pluged gateway plug-gw: timeout 3600 plug-gw: port nntp 192.1.2.* -plug-to 24.94.1.22 -port nntp plug-gw: port nntp 24.94.1.22 -plug-to 192.1.2.* -port nntp
La puerta de enlace finger es sencilla. Cualquiera que se encuentre en la red protegida debe, en primer lugar, acceder al sistema y, posteriormente, nosotros le permitimos usar el programa finger, que se localiza en el cortafuegos. Los dem�s tan solo recibir�n un mensaje como el siguiente:
# Enable finger service netacl-fingerd: permit-hosts 192.1.2.* \ -exec /usr/libexec/fingerd netacl-fingerd: permit-hosts * -exec /bin/cat \ /usr/local/etc/finger.txt
No he instalado los servicios de Mail y X-windows, as� que no voy a dar ejemplos. Si alguien tiene un ejemplo, le agradecer�a que me enviase un e-mail.
Aqu� es donde empieza todo. Cuando un cliente se conecta al cortafuegos, �ste se conecta a un puerto desconocido (inferior al 1024); por ejemplo, telnet se conecta al puerto 23. El demonio de inetd verifica esta conexi�n y busca el nombre del servicio en el fichero /etc/services. Luego llama al programa que tiene asignado este nombre en el fichero /etc/inetd.conf.
Algunos de los servicios que estamos creando no suelen encontrarse en el fichero /etc/services. Puede asignar algunos al puerto que desee; por ejemplo, he asignado el del administrador telnet (telnet-a) al puerto 24. Si hubiese querido, podr�a haberle asignado el puerto 2323. Para que el administrador (USTED) se conecte directamente al cortafuegos, tendr� que realizar una conexi�n telnet al puerto 24 y no al 23, y si instala su fichero netperm-table, como yo lo hice, s�lo podr� hacerlo desde uno de los sistemas que se encuentran en su red protegida.
telnet-a 24/tcp ftp-gw 21/tcp # this named changed auth 113/tcp ident # User Verification ssl-gw 443/tcp
El servidor proxy SOCKS se encuentra disponible en http://www.socks.nec.com/.
Una vez descomprimidos, introduzca los archivos en un directorio de su sistema, y siga las instrucciones sobre c�mo hacerlo. Tuve algunos problemas cuando lo hice. Aseg�rese de que sus Makefiles son correctos.
Una cuesti�n importante que se debe tener en cuenta es que el servidor proxy necesita ser incluido en /etc/inetd.conf. Para ello debe a�adir la l�nea:
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
, que le comunica al servidor cu�ndo ha de ejecutarse.
El programa SOCKS necesita dos ficheros de configuraci�n: uno para comunicarnos que se nos permite el acceso, y otro para enviar las peticiones al servidor proxy correspondiente. El fichero de acceso deber�a estar en el servidor y el fichero encaminador deber�a incluirse en cada sistema UNIX. Los computadores DOS y, supuestamente, Macintosh encaminar�n por s� mismos.
Con socks4.2 Beta, el fichero de acceso se llama "sockd.conf". Deber�a contener dos tipos de l�neas: las de permiso y las de prohibici�n. Cada l�nea tendr� tres entradas:
El Identificador (permit/deny)
La direcci�n IP
El modificador de direcci�n
El identificador es o "permit" (permitir) o "deny" (denegar). Deber�a tener una l�nea de cada.
La direcci�n IP se compone de cuatro octetos seg�n la usual notaci�n de puntos; por ejemplo, 192.168.1.0.
El modificador de direcci�n es tambi�n una direcci�n IP de cuatro octetos. Funciona como una m�scara de red. Hay que verlo como 32 bits (unos o ceros). Si el bit es 1, el bit correspondiente de la direcci�n que est� comprobando debe coincidir con el bit correspondiente del campo de direcci�n IP; por ejemplo, si la l�nea es:
permit 192.168.1.23 255.255.255.255
admitir� s�lo direcciones IP en las que coincida cada bit de 192.168.1.23; por ejemplo, s�lo 192.168.1.3. La l�nea:
permit 192.168.1.0 255.255.255.0
admitir� todas las direcciones desde la 192.168.1.0 hasta la 192.168.1.255, la subred de clase C completa. No deber�a aparecer la l�nea:
permit 192.168.1.0 0.0.0.0
ya que �sta permitir�a el acceso a cualquier direcci�n, pase lo que pase.
As� que, permita primero todas las direcciones que quiera admitir, y luego prohiba el resto. Para permitir a cualquiera de la subred 192.168.1.xxx, las l�neas:
permit 192.168.1.0 255.255.255.0 deny 0.0.0.0 0.0.0.0
trabajar�n perfectamente. Observe los primeros "0.0.0.0" en la l�nea de deny. Con un modificador de 0.0.0.0, el campo de direcci�n IP no importa. Se suele poner 0 porque es m�s f�cil de teclear.
Se permite m�s de una entrada de cada clase.
Tambi�n se puede conceder o denegar el acceso a usuarios concretos. Esto se consigue gracias a la autenticaci�n ident. No todos los sistemas admiten ident, incluyendo Trumpet Winsock, as� que no entrar� en ello aqu�. La documentaci�n que acompa�a a socks trata este tema adecuadamente.
El fichero de encaminado tiene el desafortunado nombre de "socks.conf". Digo que es "desafortunado" porque se parece mucho al fichero de control de acceso, por lo que resulta f�cil confundirlos.
El fichero de encaminado tiene la funci�n de comunicar a los clientes de SOCKS cu�ndo usar socks y cu�ndo no. Por ejemplo, en nuestra red 192.168.1.3 no necesita usar socks para comunicarse con la 192.168.1.1, el cortafuegos. Tiene una conexi�n directa v�a Ethernet. La direcci�n 127.0.0.1 define la vuelta atr�s autom�ticamente. Por supuesto que no se necesita SOCKS para hablar consigo mismo. Existen tres tipos de entradas:
deny
direct
sockd
La entrada deny (denegar) comunica a SOCKS cu�ndo rechazar una petici�n. Esta entrada dispone de los mismos tres campos que en sockd.conf, identifier, address y modifier. Generalmente, dado que de esto tambi�n se encarga el fichero sockd.conf, el fichero de control de acceso, el campo del modificador se pone a 0.0.0.0. Si quiere abstenerse de conectar a un determinado lugar, se puede hacer aqu�.
La entrada direct nos dice para qu� direcciones no se usa socks. Estas son todas las direcciones a las que se puede llegar sin el servidor proxy. De nuevo hay tres campos: identifier, address y modifier. Nuestro ejemplo tendr�a
direct 192.168.1.0 255.255.255.0
Lo que nos llevar�a directamente a cualquier m�quina de nuestra red protegida.
La entrada sockd comunica en qu� computador se encuentra el servidor demonio de socks. La sintaxis es:
sockd @=<serverlist> <IP address> <modifier>
Observe la entrada @=. Esta permite establecer las direcciones IP de una lista de servidores proxy. En nuestro ejemplo, s�lo utilizamos un servidor proxy, pero puede tener muchos para admitir una carga mayor y un margen para redundancia en caso de fallo.
Los campos del modificador y de la direcci�n IP funcionan exactamente igual que en los otros ejemplos. Especifican a qu� direcciones se van a trav�s de los servidores 6.2.3. DNS desde detr�s de un cortafuegos.
Instalar un servicio de nombres de dominio (DNS) desde detr�s de un cortafuegos es una tarea relativamente sencilla. S�lo necesita instalar el DNS en el sistema cortafuegos. A continuaci�n, configure cada sistema detr�s del cortafuegos para usar este DNS.
Para que sus aplicaciones funcionen con el servidor proxy, necesitan ser "sockificadas". Ser� necesario disponer de dos telnets distintos: uno para la comunicaci�n directa y otro para la comunicaci�n por medio del servidor proxy. SOCKS se acompa�a de instrucciones sobre c�mo SOCKificar un programa, as� como un par de programas pre-SOCKificados. Si se usa la versi�n SOCKificada para conectar con alg�n sitio con el que se tiene acceso directo, SOCKS cambiar� de manera autom�tica a la versi�n para acceso directo. Por ello, tendremos que dar un nuevo nombre a todos los programas de nuestra red protegida y reemplazarlos por los programas SOCKificados. As�, "Finger" pasar� a ser "finger.orig", "telnet" pasar� a ser "telnet.orig", etc. Todo esto se dar� a conocer a SOCKS mediante el fichero include/socks.h.
Algunos programas encaminar�n y sockificar�n por s� mismos. Netscape es uno de ellos. Se puede usar un servidor proxy con Netscape simplemente introduciendo la direcci�n del servidor (en nuestro caso 192.168.1.1) en el campo SOCKs de Proxies. Todas las aplicaciones necesitar�n alg�n retoque, independientemente de c�mo procese un servidor proxy.
Trumpet Winsock viene con capacidad para el servidor proxy incorporada. En el men� "setup", se debe poner la direcci�n IP del servidor, y las direcciones de todos los computadores a los que llega directamente. Trumpet se encargar� entonces de todos los paquetes de salida.
El paquete SOCKS trabaja s�lo con paquetes TCP, no con UDP. Esto le resta utilidad. Muchos programas �tiles, tales como talk y Archie, usan UDP. Existe un programa de aplicaci�n dise�ado para ser utilizado como servidor proxy para los paquetes UDP, denominados UDPrelay de Tom Fitzgerald <fitz@wang.com>. Desafortunadamente, en estos momentos, no es compatible con Linux.
El servidor proxy es, por encima de todo, un dispositivo de seguridad. Usarlo para aumentar el acceso a Internet cuando se tienen pocas direcciones IP presentan muchos inconvenientes. Un servidor proxy permite un mayor acceso desde dentro de la red protegida al exterior, pero mantiene el interior completamente inaccesible desde el exterior. Esto significa la ausencia de servidores, de conexiones talk o archive, o el env�o directo de correo a los computadores interiores. Estos inconvenientes podr�an parecer insignificantes, pero piense en ello de la siguiente forma:
Ha dejado un informe que est� haciendo en su computador dentro de una red cortafuegos protegida. Est� en casa y decide repasarla. No puede. No puede acceder a su computador, porque est� detr�s del cortafuegos. Intenta entrar primero al cortafuegos, pero como todo el mundo tiene acceso al exterior desde el servidor proxy, nadie se ha preocupado de abrirle una cuenta en �l.
Su hija va a la universidad. Quiere enviarle un e-mail. Tiene cosas privadas que comentarle y preferir�a que el correo llegara directamente a su computador. Conf�a plenamente en el administrador de su sistema; pero, sin embargo, es correo privado.
La incapacidad de utilizar paquetes UDP representa un gran inconveniente con los servidores proxy. Supongo que no por mucho tiempo.
FTP causa otro problema con un servidor proxy. Cuando se hace un ls, el servidor FTP establece una conexi�n con la m�quina cliente y manda la informaci�n por ella. Un servidor proxy no lo permitir�, as� que el FTP no funciona demasiado bien.
Adem�s, un servidor proxy tarda en ejecutarse. Debido a la gran sobrecarga, casi cualquier otro medio de lograr acceso ser� m�s r�pido.
En resumen, si tiene suficientes direcciones IP, y no le preocupa la seguridad, no use cortafuegos o servidores proxy. Si no dispone de suficientes direcciones IP, y tampoco le preocupa la seguridad, podr�a considerar la idea de utilizar un emulador IP, como Term, Slirp o TIA. Term est� disponible en ftp://sunsite.unc.edu, Slirp se encuentra en ftp://blitzen.canberra.edu.au/pub/slirp, y TIA, en marketplace.com. Estos programas de aplicaci�n van m�s r�pido, permiten mejores conexiones y proporcionan un mayor nivel de acceso a la red interior desde Internet. Los servidores proxy est�n bien para las redes que tienen muchos sistemas que quieren conectar con Internet sobre la marcha, con una instalaci�n y un mantenimiento m�nimo.
Hay un configuraci�n que me gustar�a repasar antes de concluir este documento. La que acabo de esbozar posiblemente ser� suficiente para la mayor�a de la gente; sin embargo, creo que el siguiente ejemplo mostrar� una configuraci�n m�s avanzada que puede aclarar algunas cuestiones. Si tiene duda sobre cualquier otro aspecto no tratado, o simplemente est� interesado en la versatilidad de los servidores proxy y cortafuegos, siga leyendo.
Digamos, por ejemplo, que usted es el l�der del clan millisha y quiere poner su sitio web. Dispone de 50 computadores y una subnet de 32 (5 bits) direccions IP. Necesita varios niveles de acceso dentro de su red porque comunica cosas diferentes a sus disc�pulos; por consiguiente, necesitar� proteger ciertas partes de la red del resto.
Los niveles son:
El nivel externo. Este es nivel que se ense�a a todo el mundo. Aqu� es donde hecha una perorata para conseguir adeptos.
Nivel iniciado Este es el nivel de la gente que ha superado el nivel externo. Es el lugar en el que les ense�an sobre el maldito gobierno y sobre c�mo fabricar bombas.
Nivel adepto Aqu� es donde se guardan los aut�nticos planes. En este nivel se almacena toda la informaci�n sobre c�mo el gobierno del tercer mundo va a hacerse con el poder mundial, subplanes que involucran a Newt Gingrich, Oklahoma City, productos de escasa garant�a y lo que realmente se almacena en ese hangar del �rea 51.
Los n�meros IP est�n dispuestos de la siguiente forma:
un n�mero es 192.168.1.255, que es la difusi�n y no es utilizable.
23 de las 32 direcciones IP se asignan a las 23 m�quinas que ser�n accesibles a Internet.
una direcci�n IP extra es para una m�quina Linux en esa red
una direcci�n IP extra es para otra m�quina Linux en esa red
dos n�meros de direcciones IP son para el encaminador
sobran cuatro, pero se les da los nombres de paul, ringo, john, y george, s�lo para confundir las cosas un poco.
Las dos redes protegidas tienen direcciones del tipo 192.168.1.xxx
Entonces, se crean dos redes diferentes, cada una en espacios diferentes. Son enviadas por medio de Ethernet infrarrojo, de manera que sean completamente invisibles al espacio exterior.
Cada una de estas redes est� conectada a una m�quina Linux con una direcci�n IP extra.
Existe un servidor de ficheros que conecta a las dos redes protegidas. Esto se debe a que los planes para hacerse con el poder mundial implica a algunos de los iniciados m�s aventajados. El servidor de ficheros presenta la direcci�n 192.168.1.17 para la red de iniciados y la 192.168.1.23 para los adeptos. Tiene que tener asociadas diferentes direcciones IP ya que tiene dos tarjetas Ethernet. El reenv�o de paquetes IP est� desconectado.
El reenv�o de paquetes IP tambi�n est� conectado en ambas m�quinas Linux. El encaminador no enviar� paquetes destinados a 192.168.1.xxx a menos que se le indique expl�citamente lo contrario, as� que Internet no podr� entrar. La raz�n para desconectar el reenv�o de paquetes IP aqu� es para que los paquetes de la red de adeptos no llegue a la de iniciados, y viceversa.
El servidor NFS tambi�n se puede utilizar para ofrecer diferentes ficheros a las diferentes redes. Esto puede venir muy bien, y el empleo de algunos trucos con enlaces simb�licos puede hacer que se compartan ficheros comunes a todos. Con esta instalaci�n y otra tarjeta Ethernet, el mismo servidor de ficheros puede dar servicio al conjunto de las tres redes.
Ahora, dado que los tres niveles quieren navegar por Internet en beneficio de sus propios intereses, los tres necesitan tener acceso a ella. La red externa est� conectada directamente a Internet, as� que aqu� no tenemos que modificar los servidores proxy. Las redes de adeptos e iniciados est�n detr�s del cortafuegos, as� que es necesario instalar aqu� los servidores proxy.
Ambas redes se instalar�n de forma muy parecida. Ambas tienen asignadas las mismas direcciones IP. Expondr� un par de requisitos, s�lo para a�adir mayor inter�s.
Nadie puede usar el servidor de ficheros para acceder a Internet. Esto expone al servidor de ficheros a virus y a otras cosas desagradables, y es muy importante, por lo que queda prohibido.
No se permitir� a los iniciados acceso a la World Wide Web. Est�n en pruebas y la adquisici�n de este tipo de informaci�n podr�a resultar perjudicial.
As� que, el fichero sockd.conf en el Linux de los iniciados presentar� esta l�nea:
deny 192.168.1.17 255.255.255.255
y en la m�quina de los adeptos:
deny 192.168.1.23 255.255.255.255
Y, la m�quina Linux de los iniciados tendr� estea l�nea
deny 0.0.0.0 0.0.0.0 eq 80
Esto significa denegar el acceso a todas las m�quinas que traten de acceder al puerto igualr (eq) a 80, el puerto http. Aunque esto a�n permita el acceso al resto de los servicios, deniega el acceso a la Web.
A continuaci�n, ambos ficheros tendr�n:
permit 192.168.1.0 255.255.255.0
para permitir a todos los computadores de la red 192.168.1.xxx usar este servidor proxy, exceptuando aqu�llos a los que ya se le ha denegado (por ejemplo, cualquier acceso desde el servidor de ficheros y el acceso a la Web desde la red iniciados)
El fichero sockd.conf de los iniciados ser�:
deny 192.168.1.17 255.255.255.255 deny 0.0.0.0 0.0.0.0 eq 80 permit 192.168.1.0 255.255.255.0
y el de los adeptos:
deny 192.168.1.23 255.255.255.255 permit 192.168.1.0 255.255.255.0
Con esto, todo deber�a quedar configurado correctamente. Cada red se encuentra aislada como corresponde, con el grado de interacc�n adecuado. Todos deber�amos estar satisfechos.
Existen varios paquetes de software que facilitar�n la gesti�n de su cortafuegos.
Tenga cuidado, no utilice estas herramientas a menos que pueda prescindir de ellas. Estas programaciones de guiones tanto pueden facilitarle la tarea como conducirle a errores.
Tanto las interfaces de la web como las gr�ficas han sido dise�adas para trabajar con las normas de filtraci�n de Linux. Algunas compa��as incluso han creado cortafuegos comerciales basados en Linux introduci�ndolo en su propia m�quina con su propio c�digo de gesti�n. (todo un detalle)
En realidad, no soy un tipo GUI. Sin embargo, llevo utilizando cortafuegos con interfaces GUI desde hace alg�n tiempo. He descubierto que ayudan proporcionando un buen informe de todas las reglas de forma muy clara.
gfcc (GTK+ Firewall Control Center) es una aplicaci�n GTK+ capaz de controlar las reglas y directrices del cortafuegos de Linux, basadas en el paquete ipchains. Vaya a http://icarus.autostock.co.kr y h�gase con una copia. Sinceramente es una excelente herramienta.
He incluido listados de guiones RC en el ap�ndice A. Estos guiones funcionan con y sin gfcc.
Existen muchas programaciones de guiones disponibles para instalar un cortafuegos. Una l�nea de gui�n bastante completo est� disponible en http://www.jasmine.org.uk/~simon/bookshelf/papers/instant-firewall/instant-firewall.html. Otra se encuentra en http://www.pointman.org/.
El cortafuegos K es un punto de inicio GUI para cadenas ipchains o ipfwadm (dependiendo de la versi�n de su n�cleo). http://megaman.ypsilonia.net/kfirewall/
FCT es una herramienta basada en HTML para la configuraci�n de un cortafuegos. Genera programaci�n de guiones de manera autom�tica para �rdenes de filtraci�n IP (ipfwadm) en un cortafuegos para m�ltiples interfaces y cualquier servicio de Internet. http://fct.linuxfirewall.org
WebMin es un paquete de aplicaci�n admin para sistemas. No le ayudar� a gestionar las reglas, pero le ayudar� a la hora de activar y desactivar demonios y procesos. Es un programa MUY bueno, estoy esperando que el se�or J. Cameron incluya un m�dulo de cadenas IPCHAINS. http://www.webmin.com/
Si es usted un ISP, querr� saber sobre IPFA (Contabilidad para Cortafuegos IP) http://www.soaring-bird.com/ipfa/. Le permite hacer registros cronol�gicos por mes, por d�a o por minutos y dispone de una administraci�n por interfaz gr�fica de usuario basada en Web.
Le revelar� lo f�cil que resulta burlar un sistema cortafuegos tan solo para arruinarle el d�a y para que se mantenga alerta en lo que respecta al tema de la seguridad. Precisamente ahora que ha seguido todos los pasos de este documento y tiene un servidor y una red muy seguros. Dispone de una red perim�trica (DMZ ) y nadie puede acceder a su red; adem�s, cualquier conexi�n que se haga al exterior queda registrada. Cualquier usuario que quiera acceder a la red debe hacerlo a trav�s de un servidor proxy.
Entonces uno de sus usuarios, con conexi�n propia, averigua lo dehttptunnel. httptunnel crea un t�nel bidireccional de datos virtuales en los HTTP solicitados. Estos HTTP pueden ser enviados a trav�s de un servidor proxy HTTP si as� se desea. O, en sus sistemas instalan una Red Privada Virtual (VPN). V�ase a este respecto: http://sunsite.auc.dk/vpnd/
O, quiz� este usuario simplemente ponga un m�dem en su sistema NT y establezca el encaminado. Por �ltimo, en la estaci�n de trabajo, en la LAN privada, cambia la puerta de enlace por defecto para indicarle la nueva ruta que debe seguir para acceder a Internet. Ahora, desde esta estaci�n de trabajo, puede ir a cualquier parte. La �nica cosa que el admin del cortafuegos podr�a ver ser�a una conexi�n que no deja ver que es realmente una larga visita DNS. Ahora, !tome el control del mundo!
#!/bin/bash # # Firewall Script - Version 0.9.1 # # chkconfig: 2345 09 99 # description: firewall script for 2.2.x kernel # Set for testing # set -x # # NOTES: # # This script is written for RedHat 6.1 or better. # # Be careful about offering public services # like web or ftp servers. # # INSTALLATION: # 1. place this file in /etc/rc.d/init.d # (you'll have to be root..) # call it something like "firewall" :-) # make it root owned --> "chown root.root (filename)" # make it executable --> "chmod 755 (filename)" # # 2. use GFCC to create your firewall rules # and export them to a file # named /etc/gfcc/rules/firewall.rule.sh. # # 3. add the firewall to the RH init # structure --> "chkconfig --add (filename)" # next time the router boots, # things should happen automagically! # sleep better at night # knowing you are *LESS* vulnerable than before... # # RELEASE NOTES # 30 Jan, 2000 - Changed to GFCC script # 11 Dec, 1999 - # updated by Mark Grennan <mark@grennan.com> # 20 July, 1999 - # initial writing - Anthony Ball <tony@LinuxSIG.org> # ################################################ # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 # See how we are called case "$1" in start) # Start providing access action "Starting firewall: " /bin/true /etc/gfcc/rules/firewall.rule.sh echo ;; stop) action "Stoping firewall: " /bin/true echo 0 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -F forward echo ;; restart) action "Restarting firewall: " /bin/true $0 stop $0 start echo ;; status) # List out all settings /sbin/ipchains -L ;; test) action "Test Mode firewall: " /bin/true /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -F forward echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -A input -j ACCEPT /sbin/ipchains -A output -j ACCEPT /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -i $PUBLIC -j MASQ echo ;; *) echo "Usage: $0 {start|stop|restart|status|test}" exit 1 esac
Este gui�n fue generado por el programa de Cortafuegos Gr�fico (GFCC). Este no es el conjunto de reglas en funcionamiento, sino el conjunto de reglas exportadas.
#!/bin/sh # Generated by Gtk+ firewall control center IPCHAINS=/sbin/ipchains localnet="192.168.1.0/24" firewallhost="192.168.1.1/32" localhost="172.0.0.0/8" DNS1="24.94.163.119/32" DNS2="24.94.163.124/32" Broadcast="255.255.255.255/32" Multicast="224.0.0.0/8" Any="0.0.0.0/0" mail_grennan_com="192.168.1.1/32" mark_grennan_com="192.168.1.3/32" $IPCHAINS -P input DENY $IPCHAINS -P forward ACCEPT $IPCHAINS -P output ACCEPT $IPCHAINS -F $IPCHAINS -X # input rules $IPCHAINS -A input -s $Any \ -d $Broadcast -j DENY $IPCHAINS -A input -p udp -s $Any \ -d $Any netbios-ns -j DENY $IPCHAINS -A input -p tcp -s $Any \ -d $Any netbios-ns -j DENY $IPCHAINS -A input -p udp -s $Any \ -d $Any netbios-dgm -j DENY $IPCHAINS -A input -p tcp -s $Any \ -d $Any netbios-dgm -j DENY $IPCHAINS -A input -p udp -s $Any \ -d $Any bootps -j DENY $IPCHAINS -A input -p udp -s $Any \ -d $Any bootpc -j DENY $IPCHAINS -A input -s $Multicast \ -d $Any -j DENY $IPCHAINS -A input -s $localhost \ -d $Any -i lo -j ACCEPT $IPCHAINS -A input -s $localnet \ -d $Any -i eth1 -j ACCEPT $IPCHAINS -A input -s $localnet \ -d $Broadcast -i eth1 -j ACCEPT $IPCHAINS -A input -p icmp -s $Any \ -d $Any -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any -j ACCEPT ! -y $IPCHAINS -A input -p udp -s $DNS1 domain \ -d $Any 1023:65535 -j ACCEPT $IPCHAINS -A input -p udp -s $DNS2 domain \ -d $Any 1023:65535 -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any ssh -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any telnet -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any smtp -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any pop-3 -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any auth -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any www -j ACCEPT $IPCHAINS -A input -p tcp -s $Any \ -d $Any ftp -j ACCEPT $IPCHAINS -A input -s $Any \ -d $Any -j DENY -l # forward rules $IPCHAINS -A forward -s $localnet -d $Any -j MASQ # output rules
#!/bin/bash # # Firewall Script - Version 0.9.0 # chkconfig: 2345 09 99 # description: firewall script for 2.2.x kernel # Set for testing # set -x # # NOTES: # # This script is written for RedHat 6.0 or better. # # This firewall script should work for most routers, # dial-up or cable modem. # It was written for RedHat distributions. # # Be careful about offering public # services like web or ftp servers. # # INSTALLATION: # 1. This file planned for a RedHat system. # It would work on other distro's # with perhaps no modification, but again... # Who knows?!!? # These instructions apply to RedHat systems. # # 2. place this file in /etc/rc.d/init.d # (you'll have to be root..) # call it something like "firewall" :-) # make it root owned # --> "chown root.root <filename>" # make it executable # --> "chmod 755 <filename>" # # 3. set the values for your network, # internal interface, and DNS servers # uncomment lines further down # to enable optional in-bound services # make sure "eth0" is your internal NIC # (or change the value below) # test it # --> "/etc/rc.d/init.d/<filename> start" # you can list the rules --> "ipchains -L -n" # fix anything that broke... :-) # # 4. add the firewall # to the RH init structure # --> "chkconfig --add <filename>" # next time the router boots, # things should happen automagically! # sleep better at night knowing you are # *LESS* vulnerable than before... # # RELEASE NOTES # 20 July, 1999 - initial writing - # Anthony Ball <tony@LinuxSIG.org> # 11 Dec, 1999 - updated by # Mark Grennan <mark@grennan.com> # ################################################ # Fill in the values below to match your # local network. PRIVATENET=xxx.xxx.xxx.xxx/xx PUBLIC=ppp0 PRIVATE=eth0 # your dns servers DNS1=xxx.xxx.xxx.xxx DNS2=xxx.xxx.xxx.xxx ################################################ # some handy generic values to use ANY=0.0.0.0/0 ALLONES=255.255.255.255 # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 # See how we are called case "$1" in start) # Start providing access action "Starting firewall: " /bin/true ## ## Setup Envirement ## # Flush all lists /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -F forward # Plug up everything /sbin/ipchains -I input 1 -j DENY # set policy to deny (Default is ACCEPT) /sbin/ipchains -P input DENY /sbin/ipchains -P output ACCEPT /sbin/ipchains -P forward ACCEPT # Turn on packet forwarding echo 1 > /proc/sys/net/ipv4/ip_forward ## ## Install Modules ## # Insert the active ftp module. # This will allow non-passive ftp to machines # on the local network # (but not to the router since it is not masq'd) if ! ( /sbin/lsmod | /bin/grep masq_ftp > /dev/null ); \ then /sbin/insmod ip_masq_ftp fi ## ## Some Security Stuff ## # turn on Source Address Verification # and get spoof protection # on all current and future interfaces. if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done else echo echo "PROBLEMS SETTING UP IP SPOOFING PROTECTION" echo "BE WORRIED." echo fi # deny bcasts on remaining interfaces /sbin/ipchains -A input -d 0.0.0.0 -j DENY /sbin/ipchains -A input -d 255.255.255.255 -j DENY # deny these without logging # because there tend to be a lot... # NetBIOS over IP /sbin/ipchains -A input -p udp -d $ANY 137 -j DENY # NetBIOS over IP /sbin/ipchains -A input -p tcp -d $ANY 137 -j DENY # NetBIOS over IP /sbin/ipchains -A input -p udp -d $ANY 138 -j DENY # NetBIOS over IP /sbin/ipchains -A input -p tcp -d $ANY 138 -j DENY # bootp /sbin/ipchains -A input -p udp -d $ANY 67 -j DENY # bootp /sbin/ipchains -A input -p udp -d $ANY 68 -j DENY # Multicast addresses /sbin/ipchains -A input -s 224.0.0.0/8 -j DENY ## ## Allow private network out ## # allow all packets on the loopback interface /sbin/ipchains -A input -i lo -j ACCEPT # allow all packets from the internal "trusted" interface /sbin/ipchains -A input -i $PRIVATE -s $PRIVATENET \ -d $ANY -j ACCEPT /sbin/ipchains -A input -i $PRIVATE \ -d $ALLONES -j ACCEPT ## ## Allow Outside Services into the firewall (if you dare) ## # allow ICMP /sbin/ipchains -A input -p icmp -j ACCEPT # allow TCP /sbin/ipchains -A input -p tcp ! -y -j ACCEPT # allow lookups to DNS (on firewall) /sbin/ipchains -A input -p udp -s $DNS1 domain \ -d $ANY 1023: -j ACCEPT /sbin/ipchains -A input -p udp -s $DNS2 domain \ -d $ANY 1023: -j ACCEPT # or (BETTER IDEA) run a caching DNS server # on the router and use the # following two/four lines instead... # /sbin/ipchains -A input -p udp -s $DNS1 domain \ # -d $ANY domain -j ACCEPT # /sbin/ipchains -A input -p udp -s $DNS2 domain \ # -d $ANY domain -j ACCEPT # uncomment the following to allow ssh in /sbin/ipchains -A input -p tcp -d $ANY 22 -j ACCEPT # uncomment the following to allow telnet in (BAD IDEA!!) /sbin/ipchains -A input -p tcp -d $ANY telnet -j ACCEPT # uncomment to allow NTP # (network time protocol) to router # /sbin/ipchains -A input -p udp -d $ANY ntp -j ACCEPT # uncomment to allow SMTP in # (not for mail clients - only a server) /sbin/ipchains -A input -p tcp -d $ANY smtp -j ACCEPT # uncomment to allow POP3 in (for mail clients) /sbin/ipchains -A input -p tcp -d $ANY 110 -j ACCEPT # allow auth in for sending mail or doing ftp /sbin/ipchains -A input -p tcp -d $ANY auth -j ACCEPT # uncomment to allow HTTP in # (only if you run a web server on the router) /sbin/ipchains -A input -p tcp -d $ANY http -j ACCEPT # uncomment to allow FTP in /sbin/ipchains -A input -p tcp -d $ANY ftp -j ACCEPT ## ## Masquerading stuff ## # masquerade packets forwarded from internal network /sbin/ipchains -A forward -s $PRIVATENET -d $ANY -j MASQ ## ## deny EVERYthing else ## and log them to /var/log/messages /sbin/ipchains -A input -l -j DENY # Remove the Plug /sbin/ipchains -D input 1 ;; stop) action "Stoping firewall: " /bin/true echo 0 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -F forward echo ;; restart) action "Restarting firewall: " /bin/true $0 stop $0 start echo ;; status) # List out settings /sbin/ipchains -L ;; test) ## ## This is about as simple as it gets ## (This is not secure AT ALL) action "WARNING Test Firewall: " /bin/true /sbin/ipchains -F input /sbin/ipchains -F output /sbin/ipchains -F forward echo 1 > /proc/sys/net/ipv4/ip_forward /sbin/ipchains -A input -j ACCEPT /sbin/ipchains -A output -j ACCEPT /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -i $PUBLIC -j MASQ echo ;; *) echo "Usage: $0 {start|stop|restart|status|test}" exit 1 esac
#!/bin/sh # # vpnd This shell script takes care of starting and stopping # vpnd (Vertual Privage Network connections). # # chkconfig: - 96 96 # description: vpnd # # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 [ -f /usr/sbin/vpnd ] || exit 0 [ -f /etc/vpnd.conf ] || exit 0 RETVAL=0 # See how we were called. case "$1" in start) # Start daemons. echo -n "Starting vpnd: " daemon vpnd RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/vpnd echo ;; stop) # Stop daemons. echo -n "Shutting down vpnd: " killproc vpnd RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/vpnd echo ;; restart) $0 stop $0 start ;; *) echo "Usage: vpnd {start|stop|restart}" exit 1 esac exit $RETVAL
El INSFLUG forma parte del grupo internacional Linux Documentation Project, encarg�ndose de las traducciones al castellano de los Howtos (C�mos), as� como la producci�n de documentos originales en aquellos casos en los que no existe an�logo en ingl�s.
El INSFLUG se orienta preferentemente a la traducci�n de documentos breves, como los COMOs y PUFs (Preguntas de Uso Frecuente o FAQ), etc.
Dir�jase a la sede del INSFLUG para m�s informaci�n al respecto.
En la sede del INSFLUG encontrar� siempre las �ltimas versiones de las traducciones: http://www.insflug.org. Aseg�rese de comprobar cu�l es la �ltima versi�n disponible en el Insflug antes de bajar un documento de un servidor r�plica.
Se proporciona tambi�n una lista de los servidores r�plica (mirror) del Insflug m�s cercanos a Vd., e informaci�n relativa a otros recursos en castellano.
El equipo coordinador de Insflug, insflug@insflug.org
Hosting by: hurra.com
Generated: 2007-01-26 18:00:33