MY CALF.- SAMBA PARA COMPARTIR UNA IMPRESORA CON LAS WIN$.- Por Buzz LightYear.
SMB (acrónimo de Server Message Block) es un protocolo, del Nivel de Presentación del modelo OSI de TCP/IP, creado en 1985 por IBM. Algunas veces es referido también como CIFS (Acrónimo de Common Internet File System, http://samba.org/cifs/) tras ser renombrado por Microsoft en 1998. Entre otras cosas, Microsoft añadió al protocolo soporte para enlaces simbólicos y duros así como también soporte para ficheros de gran tamaño. Por mera coincidencia esto ocurrió por la misma época en que Sun Microsystems hizo el lanzamiento de WebNFS (una versión extendida de NFS, http://www.sun.com/software/webnfs/overview.xml).
SMB fue originalmente diseñado para trabajar a través del protoclo NetBIOS, el cual a su vez travaja sobre NetBEUI (acrónimo de NetBIOS Extended User Interface, que se traduce como Interfaz de Usuario Extendida de NetBIOS), IPX/SPX (acrónimo de Internet Packet Exchange/Sequenced Packet Exchange, que se traduce como Intercambio de paquetes interred/Intercambio de paquetes secuenciales) o NBT, aunque también puede trabajar directamente sobre TCP/IP.
Acerca de Samba.
SAMBA es un conjunto de programas, originalmente creados por Andrew Tridgell y actualmente mantenidos por The SAMBA Team, bajo la Licencia Publica General GNU, y que implementan en sistemas basados sobre UNIX® el protocolo SMB. Sirve como reemplazo total para Windows® NT, Warp®, NFS® o servidores Netware®.
Sustento lógico necesario.
Necesitará tener instalados los siguientes paquetes, que seguramente vienen incluidos en los discos de instalación de su distribución predilecta:
• samba: Servidor SMB.
• samba-client: Diversos clientes para el protoclo SMB.
• samba-common: Ficheros necesarios para cliente y servidor.
aptitude install samba smb samba-client samba-common
Configuración básica de Samba.
Para la mayoría de los casos la configuración de Samba como servidor de archivos es suficiente.
Alta de cuentas de usuario.
Es importante sincronizar las cuentas entre el servidor Samba y las estaciones Windows®. Es decir, si en una máquina con Windows® ingresamos como el usuario "paco" con clave de acceso "elpatito16", en el servidor Samba deberá existir también dicha cuenta con ese mismo nombre y la misma clave de acceso. Como la mayoría de las cuentas de usuario que se utilizarán para acceder hacia samba no requieren acceso al interprete de mandatos del sistema, no es necesario asignar clave de acceso con el mandato passwd y se deberá definir /sbin/nologin o bien /bin/false como interpete de mandatos para la cuenta de usuario involucrada.
useradd -s /sbin/nologin usuario-windows
smbpasswd -a usuario-windows
No hace falta se asigne una clave de acceso en el sistema con el mandato passwd puesto que la cuenta no tendrá acceso al interprete de mandatos.
Si se necesita que las cuentas se puedan utilizar para acceder hacia otros servicios como serían Telnet, SSH, etc, es decir, que se permita acceso al interprete de mandatos, será necesario especificar /bin/bash como interprete de mandatos y además se deberá asignar una clave de acceso en el sistema con el mandato passwd:
useradd -s /bin/bash usuario-windows
passwd usuario-windows
smbpasswd -a usuario-windows
El fichero lmhosts
Es necesario empezar resolviendo localmente los nombres NetBIOS asociándolos con direcciones IP correspondientes. Para fines prácticos el nombre NetBIOS debe tener un máximo de 11 caracteres. Normalmente tomaremos como referencia el nombre corto del servidor o el nombre corto que se asigno como alias a la interfaz de red. Este lo estableceremos en el fichero /etc/samba/lmhosts, en donde encontraremos lo siguiente:
127.0.0.1 localhost
Debemos añadir entonces el nombre que hayamos elegido asociado a la dirección IP que se tenga dentro de la red local. Opcionalmente podrá añadir también los nombres y dirección IP del resto de las máquinas que conformen la red local. La separación de espacios se hace con un tabulador. Ejemplo:
127.0.0.1 localhost
192.168.1.5 maquinalinux
192.168.1.6 isaac
192.168.1.7 finanzas
192.168.1.8 direccion
Parámetros principales del fichero smb.conf.
Modifique el fichero /etc/samba/smb.conf con cualquier editor de texto. Dentro de este notará que la información que le será de utilidad viene comentada con un símbolo # y los ejemplos con ; (punto y coma), siendo estos últimos los que tomaremos como referencia.
Empezaremos por establecer el grupo de trabajo editando el valor del parámetro workgroup asignando un grupo de trabajo deseado:
workgroup = MIGRUPO
Opcionalmente puede establecer con el parámetro netbios name otro nombre distinto para el servidor si acaso fuese necesario, pero siempre tomando en cuenta que dicho nombre deberá corresponder con el establecido en el fichero /etc/samba/lmhosts:
netbios name = maquinalinux
El parámetro server string es de carácter descriptivo. Puede utilizarse un comentario breve que de una descripción del servidor.
server string = Servidor Samba %v en %L
Parámetros útiles para la seguridad.
La seguridad es importante y esta se puede establecer primeramente estableciendo la lista de control de acceso que definirá que máquinas o redes podrán acceder hacia el servidor. El parámetro hosts allow sirve para determinar esto. Si la red consiste en la máquinas con dirección IP desde 192.168.1.1 hasta 192.168.1.254, el rango de direcciones IP que se definirá en hosts allow será 192.168.1. de modo tal que solo se permitirá el acceso dichas máquinas. Note por favor el punto al final de cada rango. Modifique ésta de manera que quede del siguiente modo:
hosts allow = 192.168.1. 127.
El parámetro interfaces permite establecer desde que interfaces de red del sistema se escucharán peticiones. Samba no responderá a peticiones provenientes desde cualquier interfaz no especificada. Esto es útil cuando Samba se ejecuta en un servidor que sirve también de puerta de enlace para la red local, impidiendo se establezcan conexiones desde fuera de la red local.
interfaces = 192.168.1.254/24
Impresoras en Samba.
Las impresoras se comparten de modo predeterminado, así que solo hay que realizar algunos ajustes. Si se desea que se pueda acceder hacia la impresora como usuario invitado sin clave de acceso, basta con añadir public = Yes en la sección de impresoras del siguiente modo:
[printers]
comment = El comentario que guste.
path = /var/spool/samba
printable = Yes
browseable = Yes
writable = no
printable = yes
public = Yes
1.- donde dice "printers" alli colocaras el nombre del recurso compartido debe ser igual al nombre que tiene en cups tu impresora.
Eso es todo, sencillo no?
Introducción
Al conectarnos a internet en nuestras casas, de forma explícita nos estamos conectando, en AMBOS sentidos: directamente a la red, "desnudos" si se me permite la analogía. El objetivo de este artículo es, medinte iptables, lograr cierta protección y seguridad. Nótese que un firewall no garantiza 100% de seguridad.
Para este artículo, se requieren conocimientos básicos/intermedios acerca de linux y TCP/IP, obviamente implementado bajo dicho sistema operativo.
Cabe destacar que para utilizar iptables, es necesario tener un kernel preparado para éste, y el módulo ip_tables cargado. Del mismo modo, si estas utilizando ipchains, se deben descargar sus módulos antes de cargar los de iptables.
Iptables es una utilidad de linux que se encarga de darle directivas al kernel, acerca del filtrado de paquetes TCP/IP. Un paquete TCP/IP consta de varios campos, con información adicional a los datos que se transmiten en sí. No viene al caso describir cada uno de ellos, sino los que consideraremos mas relevantes, es decir, aquellos campos que mediante iptables, empezaremos a "vigilar". Ejemplo: direccion origen, direccion destino, puerto origen, puerto de destino, etc.
¿Como funciona?
El kernel de linux posee (predefinidas "de fábrica") 3 cadenas (chains) de reglas: INPUT, FORWARD y OUTPUT. Cada paquete TCP/IP que ingresa/atraviesa/sale desde/hacia una maquina con iptables funcionando, pasará por la cadena INPUT, FORWARD o OUTPUT respectivamente. Las cadenas,no son mas que un listado de reglas, con las cuales controlamos cada uno de los paquetes que pasan. Ahora se preguntaran, que es una regla?. Para evitar las confusiones, vamos a simplificar su definición al máximo, y luego mostrarles algunos ejemplos. Una regla consta de 2 partes, y no es mas que una condición y una acción. Si se cumple la condición se ejecuta la acción. Simple, ¿verdad?
Algo para tener en cuenta mas adelante: si un paquete atravesó todas las reglas de una cadena, sin hallar coincidencia, iptables se fijará en la politica por defecto de esa cadena(default policy).
Resumiendo lo anteriormente dicho:
1) Lo mas importante: tener conocimientos previos en linux y TCP/IP !!!
2) El kernel de linux trae 3 cadenas de reglas (INPUT, FORWARD y OUTPUT)
3) Con iptables se pueden agregar/eliminar reglas (entre otras cosas).
Supongamos la siguiente situación...Había una vez, una red local 192.168.1.0 con 50 PC's, de las cuales destacaremos:
1) aquihacker.mired.lan (192.168.1.15)
2) neutral.mired.lan (192.168.1.18)
3) jose.mired.lan (192.168.1.20)
Nosotros somos los operadores de "jose.mired.lan", estamos corriendo un servicio ftp (wu-ftpd*), y estamos enterados de que el muchacho que usa "aquihacker", es alguien muy curioso, que le gusta investigar en máquinas ajenas, utilizando su interfaz de red.
Experimentando con paquetes icmp
Vamos a ver cual es el estado de nuestras 3 cadenas, listando lo que hay en ellas. Para eso ejecutamos el siguiente comando:
[root@malevolo/]# /sbin/iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Si la salida obtenida no se parece a lo que ven aqui arriba, significa que no tenéis instalados los módulos correspondientes en el kernel, o que ya hay un firewall funcionando, o para confundirlos más: significa que ya se ejecutó un script probablemente en el inicio del sistema donde se cargan las reglas del firewall. Consultad la documentación de la distribución que instaláteis
Suponiendo que la salida que obtuvieron es igual a la escrita aqui arriba, la situación es la siguiente: quiere decir que el firewall esta aceptando todos los paquetes, o lo que es lo mismo, no filtra absolutamente nada. Esto nos indica 2 cosas:
- Las 3 cadenas (INPUT/FORWARD/OUTPUT) estan vacías
- Las 3 cadenas tienen como politica default "ACCEPT".
Es normal que al hacer un ping a localhost (nosotros mismos) recibamos respuesta:
[root@malevolo/][root@malevolo/]# ping localhost
PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=255 time=0.3ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=255 time=0.1ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=255 time=0.1ms
(y así sucesivamente...)
Vamos a agregar una regla, para entender el funcionamiento:
[root@malevolo/]# /sbin/iptables --append INPUT --protocol icmp --source 127.0.0.1 --jump DROP
Qué es esto? Simple: Agregar (append) la siguiente regla a la cadena INPUT: al recibir un paquete del tipo icmp (--protocol) con origen (--source) "127.0.0.1" y con cualquier destino (ya que no lo especificamos), enviamos ese paquete (--jump) a DROP, que por cierto es lo mismo que dejarlo tirado =). ¿Qué? No pasó nada, ¿verdad? ¿Seguro? Entonces listemos otra vez las reglas que tenemos cargadas (te olvidaste como se hacia??)
[root@malevolo/]# /sbin/iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 127.0.0.1 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Notamos que en la cadena INPUT, se nos agregó una regla, cuya función es impedir que se haga ping desde nuestra propia máquina. Podrán notar que esta regla no es demasiado útil a los fines prácticos, pero si lo es para ejemplificar el uso. ¿Y que es lo que faltaría?
¡¡Comprobar su funcionamiento!! ¡¡Por supuesto!!
[root@malevolo/]# ping localhost
PING localhost.localdomain (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
(y se quedará esperando una respuesta que nunca llegará...)
¿Nuestro firewall está invisible? Claro que no. De hecho, veremos que desde la pc "aquihacker", hacemos ping sin problemas, y nuestra maquina le responde.
[root@aquihacker /]# ping malevolo.mired.lan
PING jose.mired.lan (192.168.1.20) from 192.168.1.15 : 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=0 ttl=255 time=2.524 msec
64 bytes from 192.168.1.20: icmp_seq=1 ttl=255 time=1.319 msec
Con lo cual, con un simple ping, nuestro amigo operador de "aquihacker" puede notar la presencia de nuestro PC. A no desesperar que esto empieza ahora.
Restringiendo paquetes provenientes del exterior
Puesto que nuestro firewall está filtrando los paquetes ICMP locales, y deja pasar los remotos. Vamos a cambiar un poco las reglas "del juego". Borramos la regla que anteriormente agregamos:
[root@malevolo/]# /sbin/iptables --delete INPUT --protocol icmp --source 127.0.0.1 --jump DROP
Esto se logra con la opción "-D", y el resto, es la transcripción EXACTA de la regla que queremos borrar.
NOTA: conociendo que era la única regla, hubieramos logrado el mismo resultado escribiendo:
[root@malevolo/]# /sbin/iptables --delete INPUT 1
Ahora lo que importa: Restringir el acceso a paquetes icmp desde la red!!!
[root@malevolo/]# /sbin/iptables -A INPUT -p icmp -s 192.168.1.15 -j DROP
Nótese que es indistinto escribir -A o --append, -p o --protocol, etc. Ahora, listamos nuestra cadena INPUT:
[root@malevolo/]# /sbin/iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 192.168.1.15 0.0.0.0/0
Listo, ahora cualquier paquete icmp con origen en 192.168.1.15 será "DROPeado". Por ello, cuando nuestro amigo curioso hace ping desde su máquina a la nuestra, jamás tendrá respuesta..
[root@aquihacker /]# ping jose.mired.lan
PING malevolo.mired.lan (192.168.1.20) from 192.168.1.15 : 56(84) bytes of data.
Listo. Para nuestro amigo, nuestra máquina está invisible, por consiguiente, logramos nuestro objetivo de asegurarla.
¿Cierto? ¡¡NOOO!! ¡¡Sacrilegio!! ¡NO no no y nooooO!
Nuestro amigo, extrañado por que el comando ping no respondió, en un principio pensó que tendríamos la PC apagada, pero luego ejecutó...
[root@aquihacker /]# ftp malevolo.mired.lan
Connected to malevolo.mired.lan.
220 malevolo FTP server (Version wu-2.6.1-16) ready.
Name (malevolo:root):
Oh Oh! Nos hemos olvidado que teníamos un FTP server corriendo... Y corriendo apurados agregamos la siguiente regla:
[root@malevolo/]# /sbin/iptables -A INPUT -p tcp -s 192.168.1.15 --dport 21 -j DROP
Listamos la cadena INPUT y obtenemos:
[root@malevolo/]# /sbin/iptables -nL INPUT
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 192.168.1.15 0.0.0.0/0
DROP tcp -- 192.168.1.15 0.0.0.0/0 tcp dpt:21
Por su parte, nuestro "amigo" se aburrirá de esperar hasta que nuestro FTP le responda (cosa que no sucederá). Interesante, ¿verdad?
Ahora pensemos lo siguiente: ¿que pasa si en nuestra red, de las 50 PC's que la conforman, la mayoría son "amigos curiosos" ??. Agregaremos una regla para cada uno de ellos? Sería un trabajo bastante tedioso, y poco eficiente.
Además, un detalle realmente importante: si bien todas estas reglas, se aplicarían sin problemas, y son correctas sintácticamente, es MUY ACONSEJABLE seguir la filosofía de "Todo lo que no está EXPLICITAMENTE permitido, entonces está prohibido".
Como logramos esto? Como primer paso, setearemos la politica por defecto en DROP (descartar). Cualquier paquete que circula por la cadena INPUT es DROPeado si no coincide con ninguna regla.
En caso de que estén editando el iptables desde una consola local, pueden ignorar el parrafo siguiente:
-------------
* NOTA IMPORTANTE: para aquellos que estan toqueteando el iptables remotamente (ya sea por telnet o ssh), si setean como política DROP para la cadena INPUT se les caerá la conexión. De hecho me pasó a mi, es por eso que previamente deberan agregar la siguiente regla:
[root@malevolo/]# /sbin/iptables -A INPUT -p tcp -s #ORIGEN# --dport #PUERTO# -j DROP
Donde #ORIGEN# es el IP desde donde se están conectando al linux con iptables y #PUERTO# debe ser el 22 (si es conexion ssh) o 23 (si usan telnet).
-------------
Ahora, como decíamos, continuaremos seteando la política de INPUT en DROP (con la opción -P)
[root@malevolo/]# /sbin/iptables -P INPUT -j DROP
Vaciamos todas las cadenas con la opción -F (flush)
[root@malevolo/]# /sbin/iptables -F
Listamos lo que tenemos:
[root@malevolo/root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
Aunque no tengamos ninguna regla, nadie va a poder acceder a nuestra PC por ningun motivo. Justamente, cualquier paquete que entra, es expuesto a cada regla de la cadena (en nuestro caso nuestra cadena esta vacía), al no encontrar coincidencias, el destino del paquete, lo decide la política de la cadena, osea DROP. El problema aquí es que aunque nosotros podamos realizar
conexiones salientes, las respuestas de los servidores serán descartadas. Para solucionar esto, agregamos la siguiente regla:
[root@malevolo/root]# /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Por la cual dejamos pasar cualquier paquete cuya conexión ya se ha establecido (ESTABLISHED), o cuya conexión es nueva, pero está relacionada a una conexión ya establecida (RELATED), según las man pages del iptables (les dije que las lean, no?) Por enésima vez, listamos lo que tenemos en nuestra cadena INPUT!!
[root@malevolo/root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
Con lo cual, nadie podrá iniciar una conexion a nuestra maquina, salvo que
especifiquemos... Como veréis, por defecto tenemos un DROP. Ahora podemos empezar a permitir conexiones. Acceso local:
[root@malevolo/root]# /sbin/iptables -A INPUT -i lo -s 127.0.0.1 -j ACCEPT
-i lo : Con esto especifico como interfaz de red a localhost (lo).
[root@malevolo/root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT all -- 127.0.0.1 0.0.0.0/0
Le permito a "neutral", el acceso ftp (puerto 21)
[root@malevolo/root]# /sbin/iptables -A INPUT -p tcp -s 192.168.1.18 --dport 21 -j ACCEPT
[root@jose /root]# /sbin/iptables -nL INPUT
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
RELATED,ESTABLISHED
ACCEPT all -- 127.0.0.1 0.0.0.0/0
ACCEPT tcp -- 192.168.1.18 0.0.0.0/0 tcp dpt:21
Consejos útiles y comentarios finales
Por último, no apaguéis aun vuestra máquina. Los cambios realizados 'on-the-fly' a iptables, no quedan guardados en ningún archivo, sino que se almacenan en memoria, y como sabréis, al reiniciar, los cambios se borrarán. Tened en cuenta los siguientes consejos:
1) Guardad todas vuestras reglas en un script prolijo, y con comentarios explicando cada regla o grupo de reglas aplicadas
2) En caso de ejecutar el script automáticamente al iniciar la máquina, considerad hacerlo antes de levantar ningún servicio, o mejor aún, antes de levantar ninguna interfaz de red. No os preocupéis por las reglas que hacen referencia a interfaces no levantadas, igualmente son aceptadas por iptables.
