septiembre 27, 2014

Compartición de archivos

Es común hoy en día encontrar organizaciones con redes de área local donde coexisten terminales, conectados, con una topología definida o híbrida, con una variedad de sistemas operativos, (Windows, Mac, Linux, Android, etc) hardware diverso, y con una administración centralizada (router, hotspot o un servidor PVS (Proxy Virtual Server) o PS (Proxy Server), entre otros).
Estas conexiones en muchas ocasiones son persistentes, porque cuando los terminales están activos se conectan permanentemente, con una dirección IP fija (ipv4 o ipv6), asignada por el administrador IT, ya sea manualmente o por el servidor DHCP, el cual asigna las ips por nombre de usuario, en un proceso que se conoce en el argot informático como "amarrar host+IP").
Por este "servidor centralizado" pasa casi todo el tráfico de la red (in-out) y por lo general maneja un firewall (como iptables o sus derivados front-end o firewalls privados), un proxy (Squid, etc) y una serie de servicios tipo AIO (All-in-one), como defensa perimetral, servidor de correo, dns, compartición de archivos, impresoras, webserver y un largo etc.
Si bien no es lo recomendado, ya que implica el riesgo de "si cae el servidor, un efecto dominó afecta los demás servicios", no significa que haya que comprar un servidor para cada cosa, ya que para una pequeña empresa u organización sería muy costoso. Para contrarrestar esta deficiencia lo más acertado son el uso de máquinas virtuales para separar estos servicios (al menos los más críticos), y los discos virtuales se alojan en discos físicos "esclavos", diferentes al que usa el servidor host para el S.O., con el objeto de que si cae el proxy, se pueda retirar el disco y conectarlo a un equipo/servidor de respaldo y correr las virtualizaciones; o también se puede hacer clonaciones virtuales incrementales o físicas hacia dispositivos externos con este mismo propósito.
Uno de los servicios que presenta más problemas en este esquema es la compartición de archivos, no solo por la naturaleza de la red local y su segmentación (DMZ, impresoras, etc), sino por configuraciones erradas o cambio de versiones del producto que conducen a fallos. Tal es el caso de la compartición carpetas con el archiconocido Samba.
Como muchos ya conocen, según Wikipedia, "esta implementación libre del protocolo para la compartición de archivos (SMB también conocido como CIFS), permite la compartición entre sistemas tan diferentes como Windows, Unix, Linux y Mac. Samba también permite validar usuarios haciendo de Controlador Principal de Dominio (PDC), como miembro de dominio e incluso como un dominio Active Directory para redes basadas en Windows; aparte de ser capaz de servir colas de impresión, directorios compartidos y autentificar con su propio archivo de usuarios".
La importancia de Samba y de la compartición de archivos públicos radica en que los dispositivos usb, comúnmente utilizados para pasarse archivos entre los usuarios de las organizaciones, se han convertido en el mayor agente transmisor de todo tipo de "enfermedades informáticas" (virus, malware, troyanos, etc), sobre todo en Latino América (el segundo son los móviles) y responsable de muchas modalidades de robo de datos y otros delitos cibernéticos. Por esta razón muchas organizaciones están optando por bloquear los puertos usb de los terminales de sus usuarios y en reemplazo crean discos en red o dedicados dentro o fuera de sus servidores para el intercambio de información de sus usuarios. Y si alguien trae un dispositivo usb con información necesaria para la organización, pasa primero por el filtro del administrador IT, quien le hace una revisión exhaustiva antes de colocar la información en la carpeta compartida o en el usuario destino.
Sin embargo algunos administradores IT se enredan con los permisos (heredados), vetos y demás configuraciones que debe tener una compartición hecha por Samba y abrirle camino en el firewall para que todos sus usuarios puedan acceder a ésta unidad compartida desde su estación de trabajo.
Es por esto que dedicaremos unas líneas para explicar de la manera más sencilla posible la implementación de comparticiones (Debian/Ubuntu). Y si bien existen front-end (como GAdmin-Samba GTK+ sudo apt-get install gadmin-samba perteneciente al pack Gadmin tools) que pueden configurar Samba vía GUI, lo haremos por consola para mayor fiabilidad.
Instalación y Configuración
Instalamos samba
sudo apt-get install samba
Editamos el archivo de configuracion (vim, nano, gedit, etc)
sudo vim /etc/samba/smb.conf
Grupo de trabajo de Windows (Opcional)
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
  workgroup = redlocal
Para este caso de ejemplo escogimos como Grupo de Trabajo "redlocal". Cámbielo a su gusto
Compartiendo Archivos
Supongamos que vamos a crear una carpeta en el servidor Linux llamada "publica", y en ella todos los usuarios de nuestra red local compartirán sus archivos de forma pública, pero solo accesible desde dentro de la red local. Como sabemos de antemano es una organización mediana, calculamos entonces que es más viable destinar un disco duro o una partición para alojar estos archivos, ya que con el tiempo los "gigas irán creciendo". Como no queremos que la llenen rápidamente con videos y música (que es lo que más consume), vamos a establecer sobre ella un 'veto' y finalmente le daremos permisos para que los usuarios puedan crear, eliminar y modificar los archivos de esta carpeta a su antojo.
Nota: Es bueno advertirles a nuestros lectores que este tipo de carpetas no es para manejar información sensible, ya que es pública, así sea interna de la organización y que deben siempre hacer copia de respaldo de los archivos que en ésta coloquen, ya que cualquier usuario puede acceder a un archivo o carpeta y eliminarla.
De acuerdo a lo expuesto, al final del archivo smb.conf deberán colocar lo siguiente:
[publica]
 comment = publica
 delete readonly = yes
 writeable = yes
 path = /home/servidor/publica
 veto files = /*.mp3/*.wmv/*.wma/*.mpg/*.3gp/*.mpeg/*.mkv/*.rmvb/*.flv/*.avi/
 browseable = yes
 valid users = nobody
Lo anterior quiere decir que tenemos una carpeta llamada "publica", en la ruta /home/servidor/publica, que se puede navegar por ella (browseable = yes), y que no se pueden almacenar una serie de archivos con determinadas extensiones (veto files), tales como música (.mp3, wma, etc) y videos (mpeg, 3gp, etc). Pueden extender el veto a las extensiones que quieran (.inf, .msi, .cab, exe, etc), o eliminar el veto y permitir de todo.
Ahora creamos la carpeta en nuestro servidor, (previamente establecida en el smb.conf) y le damos los permisos
sudo mkdir -p /home/servidor/publica/
sudo chmod 777 /home/servidor/publica/
Y reiniciamos Samba
# servicios de Samba (Start/Stop/Restart/Status)
sudo service smbd start
sudo service smbd stop
sudo service smbd restart
sudo service nmdb start
sudo service nmdb stop
sudo service nmdb restart
# check the name of the service:
sudo service nmdb status
sudo service smbd status
service --status-all
Y si decidimos asignar un disco duro físico "esclavo" a esta carpeta (no una partición o simplemente una carpeta dentro de nuestro servidor), entonces el paso adicional es montar el disco duro en la carpeta "publica".
Conectamos el disco duro al servidor, nos aseguramos que este desmontado, abrimos el terminal y ejecutamos blkid para determinar el UUID del disco.
usuario@usuario:~$ sudo blkid -c /dev/null
/dev/sda1: UUID="3bb21fce-2952-47e2-bf1e-39a81dcba822" TYPE="ext4" 
/dev/sda2: LABEL="Data" UUID="780C74D60C74900C" TYPE="ntfs" 
/dev/sda4: UUID="115a57b3-ee36-4598-a000-833b402d23a6" TYPE="ext4" 
/dev/sda5: UUID="917990ec-d630-414f-89ab-580g83fb3d1b" TYPE="swap" 
En este ejemplo tenemos conectado a nuestro servidor un disco duro (sda2) en formato NTFS (que es un formato nativo de Windows), con la etiqueta o nombre "Data" y vamos a agregarlo al fstab del servidor, para que en el arranque el disco duro siempre se monte en la carpeta compartida. La ventaja de dedicar un disco a las carpetas compartidas empresariales es la misma de dedicar un disco duro para almacenar los discos virtuales, explicada anteriormente.
Editamos el fstab y agregamos el UUID
sudo gedit /etc/fstab
#Entry for /dev/sda2 :
UUID=780C74D60C74900C  /home/servidor/publica ntfs-3g  defaults,locale=es_ES.UTF-8  0  0
Y ahora montamos el disco rígido en la carpeta publica
sudo mount -a
Automatizando el proceso
Otra manera de hacerlo es inyectando directamente al cron, la partición NTFS. Primero la detectamos con:
sudo fdisk -l | grep NTFS | cut -d" " -f1
# y el resultado es, por ejemplo:
/dev/sda6
y luego creamos la carpeta y metemos la particion:
sudo mkdir -p /media/windows >/dev/null 2>&1
sudo echo "/dev/sda6 /media/windows ntfs-3g auto,user,exec,nosuid,nodev,nofail,defaults,umask=000 0 0" >> /etc/fstab
Lo anterior se puede guardar en un script y ejecutarlo. Los parámetros son de elección de usuario. Digite el comando id en consola para saber los parametros de su equipo y poderlos agregar a la línea, por ejemplo uid, git, unmask (000 significa 777), etc
Acceder a la carpeta publica desde un terminal Linux
Si queremos conectarnos desde un terminal linux a la "publica" del servidor y que cada vez que iniciemos nuestro terminal, siempre aparezca montada (similar a las carpetas de red que se montan con la letra Z por defecto en Windows), entonces agregamos en el fstab del terminal del "usuario", lo siguiente:
//192.168.1.2/publica /home/usuario/publica cifs sec=ntlm,defaults,uid=1000,gid=1000,user=servidor,password=abc123,_netdev    0    0
En el ejemplo anterior, la IP del servidor que tiene la carpeta o unidad compartida es la 192.168.1.2, la cual será montada en la ruta home/usuario/publica del terminal Linux de la red local. Si la compartida tiene clave entonces deberá incluir esta clave y usuario en la línea. Para este ejemplo usamos user=servidor,password=abc123. Caso contrario, elimine de la línea del fstab.
Tenga en cuenta que debe crear primero la carpeta compartida "pública" en el terminal del usuario (/home/usuario/publica) y darle los permisos chmod antes de proceder a montarla.
Nota: En el caso de que un terminal linux de la red local quiera acceder a la carpeta privada del servidor y montarla en el terminal es necesario primero agregar el usuario al servidor y luego asignarle la clave
Para agregar, ver y eliminar usuarios samba
# Agregando usuario al samba
sudo adduser usuario
# Para ver usuarios agregados al samba
sudo pdbedit -L
# Para eliminar usuarios agregados al samba
sudo smbpasswd -x usuario
# Para eliminar usuarios completamente del sistema
sudo userdel usuario
Asignando clave al usuario agregado
usuario@usuario:~$ sudo smbpasswd -a usuario
[sudo] password for usuario: 
New SMB password:
Retype new SMB password:
Parámetros adicionales
El parámetro allow host, establece que solo determinados terminales sean los que accedan a esta carpeta compartida
allow hosts = 192.168.1.40 # si quieres que accedan solo desde una ip determinada
Para modificar la seguridad
security = user
Para ponerle clave al usuario de Samba (clave de ejemplo: abc123)
sudo smbpasswd abc123
Para establecer los usuarios que van a acceder a la compartida
valid users = servidor # en este caso solo se accede con el servidor
valid users = nobody # en este caso accede todo el mundo
Creando usuario de Samba
sudo adduser servidor
Rendimiento
El rendimiento de samba depende de muchos factores. Velocidad del disco duro y sus cables de datos, dma, el hardware del servidor, sistema operativo y versión, la arquitectura de la red local, etc.
En el caso específico de los discos duros o carpetas compartidas en el servidor o discos en red, las tasas de transferencia pueden caer cuando se transporta datos entre particiones diferentes (Ej: NTFS/ntfs-3g, RAID5/softRAID Linux) o cuando los discos son de distintas tecnologías (SATA vs ATA). La tasa de transferencia "normal" de un disco duro moderno SATA no debe ser inferior a 60 MB/sec
usuario@usuario:~$ sudo hdparm -t /dev/sda
[sudo] password for usuario: 
/dev/sda:
 Timing buffered disk reads: 204 MB in  3.01 seconds =  67.72 MB/sec
No existe una regla general para optimizar las tasas de transferencia entre la red local y una carpeta compartida "publica" con Samba, pero se puede mejorar la optimización aplicando algunas técnicas conocidas como Samba Tuning (aunque no representa mejoras significativas en algunos entornos) con agregar unas líneas a la configuración y aumentar el buffer de envío y recepción.
Por ejemplo, agregamos a la sección [Global] de smb.conf
use sendfile = yes
strict locking = no
read size = 65536
read prediction = true
max xmit = 65535
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65535 SO_RCVBUF=65535
read raw = yes
write raw = yes
max connections = 65535
max open files = 65535
oplocks = yes
deadtime = 15
getwd cache = yes
Nota: Los valores más comunes para SO_RCVBUF y SO_SNDBUF son 8192, 64240 y 65535. Puede activar o desactivar "read raw" y "write raw" en dependencia de su hardware y software e ir comprobando la tasa de transferencia hasta obtener un rendimiento óptimo.
Firewall
Ahora solo falta autorizar los puertos del Samba en el Firewall Iptables para que los usuarios de la red local puedan acceder sin problemas.
# ACCESO DE LA LAN A CARPETA COMPARTIDA (PUBLICA) EN EL SERVIDOR (SAMBA)
for mac in `sed $route/macs-redlocal`; do
 $iptables -A INPUT -i eth1 -m mac --mac-source $mac -p tcp -m multiport --dports 135:139,445 -j ACCEPT
 $iptables -A INPUT -i eth1 -m mac --mac-source $mac -p udp -m multiport --dports 135:139,445 -j ACCEPT
done
Donde:
$iptables=/sbin/iptables
$route/macs-redlocal es la ruta home/servidor/acl/macs-redlocal (acl que contiene todas las macs de nuestra red local),
eth1 es la interfaz en el servidor de la red local (eth0 es la interfaz de internet del servidor)
Logs
Muchas máquinas Windows, sobre todo XP, consultan varios puertos tcp y udp del Samba (135:139 y 445) pero normalmente solo se conectan a uno. En ocasiones esto genera un mensaje en los logs de tipo sm-sta; una alerta por sendmail, que es un programa de mensajería interna de Linux. (Manual)
Usted puede corregir esto, bien sea seleccionando en el archivo smb.conf un solo puerto de escucha, lo cual no es muy recomendable:
smb ports=139
O ejecutar en el terminal
sudo makemap hash /etc/mail/aliases.db < /etc/mail/aliases
O instalar o desinstalar sendmail
sudo apt-get install sendmail
sudo apt-get remove sendmail
O usar postfix en reemplazo de sendmail
sudo apt-get install postfix
Compartición por otros sistemas
Samba presenta algunas limitaciones, entre ellas que no puede actuar como controlador de dominio de Active Directory, que actúa como BDC para un Windows PDC (y viceversa), son los permisos heredados y los controles de permisos en NTFS, con comparticiones en redes segmentadas, entre otras limitaciones, dada su "avanzada edad".
Es por esta razón que los administradores IT recurren a otras soluciones, como es el caso de HTTP File Server (HFS) o Secure Copy (SCP).
La ventaja de HFS es que es portable y puedes crear tu propio servidor compartido en una memoria usb, ya que utiliza la plataforma web y con esto garantiza mayor compatibilidad con cualquier sistema (con Samba puede ser más complicado), sin embargo es un ejecutable de Windows y depende de Wine para correr en plataformas Linux, lo cual no siempre es una alternativa viable.
Un buen tutorial de HFS puede consultarlo AQUI.
Por su parte, SCP es un protocolo y programa a la vez bastante estable y puede cubrir muchas de estas necesidades, en especial si se trata de backups "seguros", o montar carpetas con acceso remoto.
Blackhold nos trae una solución ingeniosa para montar una carpeta remota y sincronizarla, tan solo usando ssh y rsync para la sincronización y un script o fstab para el montaje.
Instalamos en nuestro equipo sshfs
apt-get install sshfs
Compartimos las claves con el servidor en el cual tenemos el disco duro remoto conectado
# cd /root/.sshmen
# ssh-keygen -t rsa
# ssh-copy-id -i id_rsa.pub root@10.139.39.76
En la maquina remota tenemos el disco montado en /mnt/hd y en la local queremos montarlo también en /mnt/hd
# mkdir /mnt/hd
# sshfs root@10.139.39.76:/mnt/hd/ /mnt/hd
Ahora para montarlo en el arranque agregamos las respectivas líneas en /etc/fstab o creamos un script
#!/bin/bash
sshfs root@10.139.39.76:/mnt/hd/ /mnt/hd
mount -n -t simfs /mnt/hd /var/lib/vz/root/100/mnt/hd -o /mnt/hd
Entornos Windows
Para los amantes de Windows (Server), pueden echar mano de File Screening Management para realizar el veto de archivos o carpetas compartidas (share) y Network Access Protection para evitar virus y malware, Para mayor información sobre este punto visite:
También pueden emplear Applocker para bloquear programas y muchas otras cosas. Computerhoy nos trae un buen tutorial sobre el uso de esta aplicación.
Montaje de unidades compartidas por Samba en terminales Windows con diferentes credenciales.
Al contrario de Linux (que permite múltiples conexiones con un servidor utilizando credenciales diferentes), Windows solo permite conectarse a un servidor con la misma credencial. Esto puede representar un problema si en nuestro samba del servidor local tenemos varias carpetas compartidas.
Veamos el siguiente ejemplo:
Como en el caso anterior, supongamos que tenemos configurado en nuestro servidor dos carpetas compartidas; una llamada "pública" (que no tiene contraseña), destinada para todos los usuarios de nuestra red local puedan compartir cualquier cosa, y una segunda carpeta llamada "privada" (que tiene contraseña), solo para almacenar copias de seguridad, archivos sensibles, etc. En el smb.conf quedaría de la siguiente manera:
Carpeta compartida "pública"
[publica]
 comment = publica
 delete readonly = yes
 writeable = yes
 path = /home/servidor/publica
 veto files = /*.mp3/*.wmv/*.wma/*.mp4/*.mpg/*.3gp/*.mpeg/*.mkv/*.rmvb/*.flv/*.avi/
; browseable = yes
 valid users = nobody
 security = share
Carpeta compartida "privada"
[privada]
 comment = privada
 delete readonly = yes
 writeable = yes
 path = /home/servidor/privada
; browseable = yes
 security = user
 valid users = server
Donde valid users = server es el nombre del usuario samba del servidor y la contraseña que le haya asignado al momento de crearlo.
Si intentamos conectarnos a la carpeta pública desde un terminal Windows no habría problemas, basta con buscar el servidor en la red y ver las carpetas compartidas y montar una de ellas. Para el caso de la "pública",  nos conectamos como unidad de red. Sin embargo al intentar conectarnos a la carpeta "privada", Windows nos arrojará un mensaje de error similar al siguiente:
Múltiples conexiones a un servidor o recurso compartido por el mismo usuario, utilizando más de un nombre de usuario, no están permitidas. Desconecte todas las conexiones anteriores al servidor o recurso compartido y vuelva a intentarlo.
Esto se debe a que cuando utilizamos las credenciales de usuario para conectarse a un recurso compartido de red desde un equipo basado en Windows, la carpeta de red especificada actualmente se asigna mediante otro nombre de usuario y contraseña. En otras palabras Windows no acepta conexiones a carpetas compartidas que tengan usuarios y contraseñas diferentes.
Para solucionarlo, conéctese a la primera carpeta compartida (pública), por el método tradicional, ya sea buscando la carpeta directamente en el servidor, o en ejecutar:
 \\servidor\compartida
Y para el caso de la segunda carpeta compartida (privada) que tiene usuario y contraseña , conéctese mediante la ip del servidor. Ejemplo:
\\192.168.1.2\privada
Donde la ip del servidor es 192.168.1.2 (cámbiela según su red). Y seguido coloca las credenciales (usuario y contraseña). De esta manera ya podrá utilizar ambas carpetas sin entrar en conflicto de credenciales.
Security User
Samba trae por defecto activada la directiva security = user. Esto trae como consecuencia que si en las carpetas compartidas no se especifica la seguridad, Samba tomará por defecto que la seguridad le pertenece al usuario. Para solucionarlo, especifique siempre la seguridad a usar en cada carpeta compartida, o en su defecto busque en el smb.conf la línea security = user y coméntela, y luego en cada carpeta compartida especifique que tipo de seguridad le va a asignar. En el ejemplo de arriba, para la carpeta "publica" usamos security = share y para la privada security = user
Lo mismo aplicaría para impresoras y demás comparticiones de samba.

Vea Compartición de Archivos II
Maravento, Actualizado en: 9:49
Escrito por: Maravento Studio
 
© 2017 Maravento. All Rights Reserved | Powered by Maravento
Design by Novatoz and Maravento | Bloggerized By LawnyDesignz
# https://github.com/google/code-prettify