S.O. De Xarxes d'Àrea Local by Gabriel

Gestió de xarxes d’àrea local

TEMA 3: S.O. De Xarxes d'Àrea Local Introducció

SO de Xarxes 3 Introducció......................................................................................................................4 3.0 Instal·lació d'un SO Lan..........................................................................................4 3.0.1 Instal·lació de Linux .......................................................................................5 3.0.1.1 Instal·lació amb els Cds o el DVD..........................................................5 3.0.1.2 sense Cds.................................................................................................5 3.1 Instal·lació d’una LAN............................................................................................6 3.1.1 LAN en DOS...................................................................................................6 3.1.2 LAN en Windows...........................................................................................7 3.1.21 Configuració TCP/IP des de consola......................................................13 3.1.3 LAN en Linux...............................................................................................14 3.1.3.1 LAN sense fils en Linux........................................................................18 3.2 Configuració automàtica de xarxes.......................................................................21 3.2.1 Bootstrap protocol.........................................................................................21 3.2.2 DHCP............................................................................................................22 3.2.3 Configuració de DHCP en Linux..................................................................23 3.2.4 Configuració de DHCP en Windows............................................................24 3.3 Usuaris..................................................................................................................25 3.3.1 Windows 2000/XP........................................................................................28 3.3.2 Linux / Unix..................................................................................................29 3.3.3 Contrasenyes.................................................................................................30 3.3.4 Dominis.........................................................................................................32 3.3.5 NIS................................................................................................................33 3.2.5.1 Configuració del servidor......................................................................33 3.2.5.1.1 Configuració del servidor en Mandriva.........................................33 3.2.5.1.2 Configuració del servidor en Ubuntu............................................34 3.2.5.2 Configuració dels clients.......................................................................35 3.2.5.2.1 Configuració en Mandriva.............................................................35 3.2.5.2.2 Configuració en Ubuntu................................................................35 3.2.5.3 Comprovar el funcionament..................................................................36 3.2.5.4 Servidors esclaus...................................................................................36 3.3.6 Serveis de directori........................................................................................38 3.3.7 OpenLDAP....................................................................................................40 3.3.7.1 Instal·lació d'un servidor OpenLDAP...................................................43 3.3.7.1.1 Instal·lació del servidor en Ubuntu................................................43 3.3.7.1.2 Instal·lació del servidor en Fedora.................................................44 3.3.7.1.3 Entrada de dades ...........................................................................46 3.3.7.1.4 Gestió de LDAP.............................................................................47 3.3.7.2 Instal·lació dels clients...........................................................................48 3.3.7.2.1 Configuració del client en Fedora..................................................48 3.3.7.2.2 Configuració del client en Ubuntu.................................................48 3.3.7.2.2 Configuració del client en Ubuntu 2..............................................49 3.3.7.3 Comprovació de la instal·lació.........................................................50 3.3.8 Active Directory de Windows.......................................................................51 3.3.8.1 Instal·lació d’un controlador de Domini d’Active Directory ...............52 3.3.8.2 Afegir un client en un Domini d’Active Directory ..............................58 3.3.8.3 Iniciar-se en el domini...........................................................................60 3.3.8.4 Iniciar-se en el Domini des de Linux....................................................61 1

Gestió de xarxes d’àrea local 3.3.8.5 Fer servir Samba com a DC de Windows.............................................66 3.4 Compartició d’arxius............................................................................................67 3.4.1 Compartició en Windows: NetBIOS.............................................................67 3.4.2 Compartició de fitxers Windows-Linux: SAMBA.......................................76 3.4.3 Compartició de fitxers Unix: NFS................................................................79 3.4.3.1 NFS en Linux........................................................................................79 3.5 Compartició d’impressores...................................................................................83 3.5.1 Compartir impressores en Windows.............................................................83 3.5.2 Compartir impressores en Linux...................................................................84 3.5.2.1 Impressió des de la línia de comandes..................................................84 3.5.2.2 CUPS.....................................................................................................84 3.5.3 CUPS.............................................................................................................87 3.5.3.1.1 CUPS i Windows 9x......................................................................89 3.5.3.1.1 CUPS i Windows 2000, XP o Vista..............................................91 3.6 Servidors per administració remota......................................................................93 3.6.1 Telnet.............................................................................................................93 3.6.1.1 Client de Telnet.....................................................................................93 3.6.2 SSH...............................................................................................................93 3.6.2.1 Instal·lació d'un servidor........................................................................93 3.6.2.2 Client ssh...............................................................................................95 3.6.2.2.1 dsh un client ssh distribuït.............................................................97 3.6.2.2.1 Clients gràfics................................................................................98 3.6.3 Administració remota gràfica........................................................................99 3.6.3.1 VNC.......................................................................................................99 3.6.3.1.1 Instal·lació en Unix......................................................................100 3.6.3.2 NX.......................................................................................................101 3.6.3.2.1 Instal·lació del servidor a Ubuntu Feisty.....................................101 3.7 Configuració de servidors web...........................................................................105 3.7.1 Introducció..................................................................................................105 3.7.2 Apache web server......................................................................................106 3.7.2.1 Instal·lació d’Apache...........................................................................107 3.7.2.2 Configuració d'Apache........................................................................108 3.7.2.2.1 Pàgines personals.........................................................................110 3.7.2.2.2 Virtual Hosting............................................................................111 3.7.2.2.3 Protecció de directoris amb contrasenya.....................................114 3.7.2.2.4 Configuració de SSL....................................................................116 3.7.3 IIS................................................................................................................118 3.7.2.1 Instal·lació de IIS.................................................................................118 3.7.2.2 Configuració de IIS.............................................................................120 3.7.2.2.1 Protecció de directoris amb contrasenya.....................................121 3.7.2.2.2 Configuració de SSL....................................................................123 3.7.4 Lighttpd.......................................................................................................129 3.7.4.1 Instal·lació...........................................................................................129 3.7.4.2 Configuració........................................................................................131 3.7.4.2.1 Virtual Hosting............................................................................133 3.7.4.2.2 Protecció de directoris amb contrasenya.....................................134 3.7.4.2.3 Configuració de SSL....................................................................136 3.8 Configuració de correu electrònic.......................................................................137 3.8.1 MTA............................................................................................................137 3.8.1.1 Sendmail..............................................................................................138 3.8.1.2 Postfix..................................................................................................139 3.8.1.2.1 Configuració ...............................................................................139

Gestió de xarxes d’àrea local 3.8.1.3 Exim....................................................................................................140 3.8.1.3.1 Configuració................................................................................140 3.8.1.4 qMail....................................................................................................141 3.8.1.5 Microsoft Exchange Server.................................................................143 3.8.1.6 Filtres de correu...................................................................................144 3.8.1.6.1 Antivirus: clamav.........................................................................144 3.8.1.6.2 AntiSpam: spamassassin..............................................................144 3.8.1.6.3 Amavis-new.................................................................................145 3.8.2 Bústies de correu.........................................................................................147 3.8.2.1 Courier IMAPD...................................................................................148 3.8.2.2 Cyrus IMAPD......................................................................................149 3.8.2.3 Dovecot................................................................................................150 3.8.3 Webmail......................................................................................................152 3.8.3.1 SquirrelMail.........................................................................................153 3.8.4 Altres...........................................................................................................154 3.8.4.1 Fetchmail.............................................................................................154 3.8.4.2 Procmail...............................................................................................154 3.9 Servidors de noms...............................................................................................157 3.9.1 DNS.............................................................................................................157 3.9.1.1 Bind.....................................................................................................157 3.10.1.2 Djbdns................................................................................................158 3.10.1.3 PowerDNS.........................................................................................159 3.10.1.4 Microsoft DNS..................................................................................160 3.9.2 WINS...........................................................................................................161 3.10 Proxies...............................................................................................................162 3.10.1 Tipus de proxies........................................................................................163 3.10.1.1 Proxies de web...................................................................................163 3.10.1.2 Proxys transparents............................................................................164 3.10.1.3 Open Proxies.....................................................................................164 3.10.1.4 Reverse Proxies.................................................................................164 3.10.1.5 Split proxies.......................................................................................164 3.10.1.6 Riscos dels proxies ...........................................................................165 3.10.1.7 Programari de proxy popular.............................................................166 3.10.2 Squid.........................................................................................................167 3.10.2.1 Instal·lació.........................................................................................167 3.10.2.2 Configuració......................................................................................169 3.10.2.3 Filtres de continguts.........................................................................173 3.10.2.3.1 SquidGuardian...........................................................................173 3.10.2.3.2 DansGuardian............................................................................174 3.10.2.4 Delay Pools........................................................................................175 3.10.3 Tor.............................................................................................................177 3.11 Xarxes Privades Virtuals (VPN).......................................................................178

Gestió de xarxes d’àrea local

3 Introducció Amb l’aparició dels ordinadors personals en xarxa, una de les coses que va deixar de tenir sentit era el treball individual. Que cada persona tingui els seus propis programes faria que es perdessin els recursos de que disposi la organització (impressores, dades d’usuaris, missatges,...) – que poden facilitar tasques i fomentar el treball en equip amb altres usuaris de la mateixa xarxa. Actualment pràcticament ja no existeixen els sistemes monousuari, tots els nous sistemes operatius es desenvolupen per poder treballar en xarxa. Això té els seus avantatges, però ens obliga a prendre precaucions: cal establir permisos i seguretat sobre els recursos disponibles, cal fer còpies de seguretat, etc..

3.0 Instal·lació d'un SO Lan 1) Fer sempre una còpia de seguretat de les dades quan s'instal·li un sistema operatiu sobre un ordinador que ja contingui dades. A més es recomana fer la còpia de totes les dades del disc, encara que només vulguem fer la instal·lació en una de les particions. (les precaucions sempre són poques) 2) Fer un pla d'avant mà de com seran les particions que farem i quin sistema de fitxers tindrà cada una de les particions que farem servir (ext3, reiserFS, ntfs, ... ). Cal tenir en compte perquè es farà servir cada una de les particions tenint en compte els avantatges i inconvenients que tenen cada una de les particions . 3) Entrar a la BIOS i posar la opció: PnP aware OS a NO ! I evidentment posar el CDROM en el primer ordre de la instal·lació (si estem instal·lant el sistema operatiu des de CD-ROM) 4) Connectar tots els dispositius que tindrà el sistema: impressores, escànners, etc... (els programes d'instal·lació són bastant bons en la configuració automàtica i ens estalviarà temps) 5) En tots els CD hi ha un arxiu README i/o INSTALL en el quan hi pot haver informació útil per instal·lar. 6) Triar la contrasenya de l'administrador (les contrasenyes de l'administrador triades en darrer moment s'obliden!) 7) Intentar avançar-se a totes les preguntes que farà el sistema operatiu. Les decisions preses en el moment fallen.

Gestió de xarxes d’àrea local

3.0.1 Instal·lació de Linux

3.0.1.1 Instal·lació amb els Cds o el DVD

3.0.1.2 sense Cds Mandriva FTP Install Here is what you do for the FTP-Install: 1). Get the "boot.iso" and burn it to CD: ftp://ftp.nluug.nl/pub/os/Linux/distr/Man...images/boot.iso 2). Boot from the CD and press Enter at the first screen 3). Select "FTP-Server" from the next screen 4). Next screen: Select DHCP ( or whatever suitable for your connection ) 5). Next screen: Fill in anything you want 6). You get a message "Bringing up the network" . . this might take a minute 7). Next screen: Proxy . . . leave blank 8). Next screen: The Address . . . . watch out here . . . on the first line you put: ftp.nluug.nl on the 2nd line: /pub/os/Linux/distr/Mandrake/official/2005/i586/ ( !! Case Sensitive !! ) 9). The "normal" install procedure will start . .

Gestió de xarxes d’àrea local

3.1 Instal·lació d’una LAN Tenim diverses formes de formar una LAN amb PCs: targeta de xarxa, port paral·lel, port sèrie. Veurem diferents formes de configurar-les en diversos Sistemes Operatius

3.1.1 LAN en DOS •

Confecció d’una xarxa local a través de cable sèrie sobre MS-DOS

MS-DOS 6.22 té una utilitat per comunicació per ports sèrie i paral·lel: es tracta dels fitxers INTERLNK.EXE i INTERSVR.EXE Es pot aconseguir més informació sobre aquests programes amb el HELP del sistema, però, en resum, direm que INTERLNK ha d’estar configurat en el fitxer CONFIG.SYS: DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE NOEMS BUFFERS=15,0 FILES=30 DOS=UMB LASTDRIVE=H FCBS=4,0 DEVICEHIG /L:1,12192 = C:\DOS\SETVER.EXE DOS=HIGH COUNTRY=034, C:\DOS\COUNTRY.SYS DEVICEHIGH /L:0; 1, 9424 /S = C:\DOS\INTERLNK.EXE

Quan s’executi INTERSVR, es mapejaran les unitats de disc i les impressores. A partir d’aquest moment ja es podran fer servir les unitats lògiques remotes com si fossin locals. •

Configuració de la targeta de xarxa en DOS

Com en els altres sistemes, el que cal fer és carregar el driver adequat a memòria per poder utilitzar la xarxa. Només cal tenir compte de triar la xarxa adequada. ne2000 Veurem l’exemple per una targeta compatible amb ne2000 que van ser una de les targetes Ethernet que van ser estàndards durant un temps. Per carregar el driver de la ne2000 es recomanable carregar-lo en arrancar el PC (un bon lloc és l’Autoexec.bat) Aquest driver ve en format .com (el que vol dir que és executable) i per tant només l’hem de cridar. ne2000 0x7e 0x0b 0x300

Gestió de xarxes d’àrea local 0x7e : IRQ software, 0x0b : IRQ de la targeta, 0x300 : I/O de la targeta

A partir d’aquest moment podrem fer servir la targeta de xarxa per comunicar-nos amb altres ordinadors (però ens cal un protocol) • Configuració de TCP/IP en MSDOS No hi ha una sola forma de configurar una targeta de xarxa TCP/IP en DOS. Donat que en el moment en que les xarxes, i sobretot Internet, es van començar a fer populars el DOS encara era un dels SO força utilitzats, però no disposava de res per connectar-s’hi. Diferents companyies van elaborar implementacions de TCP/IP per DOS: -

WATTCP (Waterloo TCP). Un dels més populars. Es configura a través d’un fitxer WATTCP.CFG Entre les variables que definim en aquest arxiu hi ha (MYIP(adreça), REMIP(gateway), NETMASK(màscara), PEERMRU(mru del ppp)). Per exemple: MY_IP = 192.168.1.15 HOSTNAME = dos NETMASK = 255.255.255.0

I cal establir la variable WATTCP perquè apunti a l’arxiu: SET WATTCP=B:\WATTCP.CFG -

Trumpet. També molt popular, però sobretot per la implementació que van fer del TCP/IP per Windows 3.1 Microsoft: Els amos del MSDOS també van fer una implementació de la pila TCP/IP

3.1.2 LAN en Windows •

Configuració de la targeta de xarxa amb Windows

Un cop s’ha instal·lat físicament la targeta de xarxa iniciem l’ordinador i si aquesta targeta és de tecnologia Plug & Play, el Windows detectarà que tenim una targeta nova. (depenent de la versió de Windows que tinguem sortirà una pantalla que serà més o menys com aquestes, per això anirem fent els exemples en diferents versions del Windows):

Gestió de xarxes d’àrea local

En el cas en que no tinguem una targeta Plug & Play, podem arribar a la pantalla següent a través del “panell de control” (veiem la pantalla també del Windows XP)

Posteriorment ens demanarà d’on volem treure el controlador de la xarxa. És recomanable utilitzar el CD-ROM que haurem obtingut amb la targeta de xarxa o bé els controladors que haurem baixat de la web del fabricant. (Tot i que en molts casos utilitzar el controlador que ve amb el Windows serà suficient).

Gestió de xarxes d’àrea local

Veiem amb versió XP com podem forçar la instal·lació d’un driver específic per a la nostra targeta. Des del panell de control seleccionem afegir hardware:

Gestió de xarxes d’àrea local

Configuració de TCP/IP en Windows Per fer aquest exemple mostrarem les pantalles de Windows 2000, ja sabem que depenent de la versió de Windows que tinguem, la pantalla i/o la forma d’accedir-ho variarà lleugerament. Per poder configurar el TCP/IP en Windows hem d’anar a les propietats de la xarxa i ens trobarem una pantalla com la següent. Hi podem accedir anant a: Inicio  Configuración  Conexiones de red y de acceso telefónico

Gestió de xarxes d’àrea local i després triar “Propiedades” de la connexió que volem configurar (amb el botó dret al damunt). Això ens ensenyarà quines són les característiques que tenim habilitades en aquesta connexió de xarxa:

El TCP/IP hi és per defecte des de Windows 98, però si no hi fos, l’hauríem d’instal·lar amb el botó “Instalar...”. Si triem les propietats de “Protocolo Internet TCP/IP” veurem una pantalla com la següent:

Per defecte el Windows intenta obtenir les adreces IP automàticament, si això no és el que volem només hem d’escriure l’adreça en el quadre corresponent.

Gestió de xarxes d’àrea local Si tot ha anat bé en la finestra tindrem una icona com la següent que ens indica que tot funciona correctament.

En cas d’error la icona estarà marcada amb una creu que ens indicarà que la connexió falla.

3.1.21 Configuració TCP/IP des de consola En Windows també es pot fer la configuració de TCP/IP sense haver de recórrer a l'entorn gràfic. Per fer-ho podem fer servir la comanda netsh

Gestió de xarxes d’àrea local

3.1.3 LAN en Linux •

Carregar el mòdul

1. Carregar el mòdul El primer que hem de fer és carregar el mòdul (driver) de la nostra targeta de xarxa. Aquest pas normalment amb les distribucions modernes ens el podem saltar perquè es farà automàticament però si no es dóna el cas sempre podem recórrer a fer-ho manualment. La llista dels mòduls de xarxa normalment està a /lib/modules/2.X.XX/net o a /lib/modules/2.X.XX/kernel/drivers/net (on 2.X.XX serà la versió del nucli que farem servir) Ja hem dit que normalment el sistema d’arrancada del nostre sistema ja carregarà el mòdul. Per veure-ho podem fer servir ‘lsmod’ # lsmod ... cdrom floppy 8139too mii ntfs

37184 59444 23712 4992 85932

2 0 0 1 1

sr_mod, ide_cd

8139too

...

En l’exemple el driver de la targeta és “8139too” que es correspon a una Realtek STR8139. En el cas en que el mòdul no hagués estat carregat la podríem iniciar, primer assegurant-se de que no tenim la xarxa en marxa: # service network stop

I carregar el driver, crear el fitxer de dependències i tornar a engegar la xarxa: # depmod -a # modprobe 8139too # service network start

Generalment mirant a l’arxiu: /etc/modules.conf o /etc/modprobe.conf (segons la versió de Linux que fem servir) podrem veure una línia que ens indica quin driver carrega per la targeta al iniciar el sistema: # cat /etc/modprobe.conf .. alias eth0 8139too ..

Un cop s’ha aconseguit que el driver de la targeta estigui carregat, podem passar a el següent pas que és configurar-lo

Gestió de xarxes d’àrea local •

Configuració de targeta de xarxa i TCP/IP amb Linux

El TCP/IP en Linux és el protocol per defecte, per tant, no ens cal fer-hi cap configuració extra i diferenciada Per configurar una targeta de xarxa en Linux ens cal només configurar correctament la targeta de xarxa. Per fer-ho les diferents distribucions disposen de diferents programes d’entorn gràfic o automatitzats que ens fan tota la feina. Per exemple aquesta és la pantalla gràfica de configuració de xarxes que sortia en el centre de control de Mandrake Linux 10.0

Però tot això es pot fer també a mà, amb l'avantatge de que d'aquesta forma funcionarà en totes les distribucions 1. Configurar la xarxa Un cop tenim el mòdul de xarxa carregat, ens caldrà configurar l’adreça TCP/IP d’aquesta targeta. Això ho fem de la següent forma: # ifconfig eth0 192.168.0.10 netmask 255.255.255.0

Gestió de xarxes d’àrea local Els valors de l’adreça ( 192.168.0.10 ) i la màscara (255.255.255.0) seran els que nosaltres desitgem. Es pot comprovar que tot ha anat bé executant la instrucció i mirant a veure si la targeta que hem especificat té adreça IP: # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:05:1E:7F:24:9B inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::205:1caa:fd3d:5b9b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:161753 errors:0 dropped:0 overruns:0 frame:0 TX packets:190347 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:47714516 (45.5 Mb) TX bytes:191077789 (182.2 Mb) Interrupt:5 Base address:0x3000

Si el que volem és rebre l'adreça IP per dhcp només hem d'executar: # dhclient eth0

2. Definir la sortida per defecte Ara ens cal dir-li cap a on aniran els paquets que no sàpiga entregar. Per fer-ho fem servir route (ruta estàtica): # route add default gw 192.168.0.1

Això farà que els paquets que no sàpiga on van vagin a la estació amb número 192.168.0.1. Podem comprovar que ara tenim una adreça a ‘default’ amb la instrucció: # route Kernel IP routing table Destination Gateway 192.168.0. * 0 127.0.0.0 * default 192.168.0. 1

Genmask 255.255.255. 0 255.0.0.0 0.0.0.0

Flags U

Metric 0

Ref 0

Use 0

Iface eth0

U UG

0 0

lo eth0

O com a usuari amb netstat amb el flag –r. Això ens ensenyarà alguna cosa semblant a l’anterior: # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0. 0.0.0.0 255.255.255. U 0 0 0 eth0 0 0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0. 0.0.0.0 UG 0 0 0 eth0 1 La opció –n fa que s’hagin de veure les adreces IP en comptes dels símbols (cal recordar que en els flags U:Up, G: Gateway, H:Host, D: Dynamic route i M:Modified)

Gestió de xarxes d’àrea local 3. Fer la configuració persistent Cal tenir en compte que el procés que hem descrit fins ara només estarà activa fins que tornem a engegar la màquina o bé tornem a canviar-la. Per fer-la persistent hem d'escriure la informació en els arxius de configuració. Però els arxius de configuració no són sempre iguals en totes les configuracions: * Configuració de xarxa permanent en Ubuntu/Debian La configuració de la xarxa en Ubuntu/Debian està en l'arxiu /etc/network/interfaces. Per tant només hem d'editar-lo per aconseguir que s'adapti al que volem. Per posar una adreça fixa, canviem totes les referències a la targeta per: iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1

Si volem que la targeta rebi l'adreça per dhcp canviem totes les refències a la targeta que volem canviar i les substituim per (eth0 en l'exemple): auto eth0 iface eth0 inet dhcp

* Configuració de xarxa permanent en Red Hat/Mandriva/Fedora En els sistemes basats en Red Hat l'arxiu a editar és /etc/sysconfig/networkscripts/ifcfg-eth0 (la part final del nom especifica la targeta a la que farem referència. Per posar l'adreça fixa de l'exemple anterior editem l''arxiu i al acabar hem de tenir una cosa semblant a això: DEVICE=eth0 IPADDR=192.168.0.2 NETMASK=255.255.255.0 GATEWAY=192.168.0.1 ONBOOT=yes

O si el que volem és que les adreces s'aconsegueixin a través de dhcp el contingut de l'arxiu ha de ser com: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes

En aquests sistemes és important també revisar l'arxiu /etc/sysconfig/network per veure que la xarxa estigui activa

Gestió de xarxes d’àrea local 4. Configuració dels DNS Els DNS es canvien igual en qualsevol de les distribucions. Cal tenir en compte que en Linux no hi ha diferents DNS per cada una de les diferents targetes de xarxa, només hi ha un sol fitxer que conté l'adreça del DNS que farà el nostre sistema. Aquest arxiu és /etc/resolv.conf, l'editem i hi posem l'adreça del DNS en el lloc de la que hi hagi. Si volem posar 80.58.0.33 com a servidor DNS editem l'arxiu i hi posem això: nameserver 80.58.0.33

Podem posar tants servidors de noms com vulguem sense cap restricció

3.1.3.1 LAN sense fils en Linux A part dels diferents sistemes gràfics per connectar-se a una xarxa sense fils també podem gestionar les connexions a través de l'entorn de comandes.

A diferència del que passa amb els entorns gràfics, en que moltes distribucions han fet el seu programa el sistema a través de l'entorn de comandes funciona amb totes les distribucions. La comanda bàsica és 'iwconfig' que ens informarà de quins dels dispositius tenen suport per xarxes sense fils i si estem connectats on estem connectats (en el nostre cas estem connectats a través de eth1 al punt d'accés que té per ESSID IESCENDRASSOS. # iwconfig lo

no wireless extensions.

eth0

no wireless extensions.

eth1

IEEE 802.11g ESSID:"IESCENDRASSOS" Mode:Managed Frequency:2.412 GHz Access Point: 00:13:46:BA:C5:0D Bit Rate:54 Mb/s Tx-Power:15 dBm Retry limit:15 RTS thr:off Fragment thr:off Power Management:off Link Quality=93/100 Signal level=-35 dBm Noise level=-36 dBm Rx invalid nwid:0 Rx invalid crypt:26 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:40 Missed beacon:0

Gestió de xarxes d’àrea local Combinant 'iwconfig' i 'ifconfig' podem configurar la nostra xarxa sense fils Entre les opcions de iwconfig tenim varies possibilitats: a) Connectar-nos a un punt d'accés especificant la clau i l'ESSID # iwconfig eth1 essid “IESCENDRASSOS” key 0102030405061 Les claus de 64 bits són sempre 10 dígits hexadecimals o 5 ASCII les de 128 són 26 hexadecimals o 13 ASCII

b) Forçar a que sempre es connecti amb el mateix punt d'accés independentment de la força amb la que arribi el senyal # iwconfig eth1 ap 00:65:1D:01:23:45

o bé que es connecti amb el que ens faci arribar el senyal més fort # iwconfig eth1 ap any

o que no es connecti amb cap # iwconfig eth1 ap off

c) Forçar la velocitat amb la que ens connectarem # iwconfig eth1 rate 11M

o deixar que trii ell mateix # iwconfig eth1 rate auto

d) Podem canviar el mode de funcionament de la nostra targeta (Managed / AdHoc / Monitor) # iwconfig eth1 mode Managed Cal recordar que en mode monitor no ens podem connectar a cap punt d'accés. Si ho volem fer abans hem de canviar el mode de funcionament # iwconfig eth1 mode Ad-Hoc # iwconfig eth1 mode Monitor

e) Triar el canal, la sensibilitat mínima de la targeta, etc.. # iwconfig eth1 channel 0 # iwconfig eth1 freq 2.422G # iwconfig eth1 sens -80

Gestió de xarxes d’àrea local Disposem també d'altres comandes que ens permeten fer altres coses. Per exemple iwpriv ens informa de les característiques que suporta la nostra targeta de xarxa sense fils: # iwpriv eth1 eth1

Available private ioctls : set_power (8BE0) : set get_power (8BE1) : set set_mode (8BE2) : set get_mode (8BE3) : set set_preamble (8BE4) : set get_preamble (8BE5) : set reset (8BE7) : set monitor (8BE6) : set

1 0 1 0 1 0 0 2

int int int int int

& & & & & & & &

get get get get get get get get

0 80 char 0 80 char 0 16 char 0 0

I la comanda iwlist ens permet veure de quina forma està funcionant la targeta o per exemple, veure els punts d'accés que detecta: # iwlist eth1 scan eth1

Scan completed : Cell 01 - Address: 00:13:46:BA:C5:0D ESSID:"IESCENDRASSOS" Protocol:IEEE 802.11bg Mode:Master Channel:1 Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 22 Mb/s; 24 Mb/s 36 Mb/s; 48 Mb/s; 54 Mb/s Quality=94/100 Signal level=-35 dBm Noise level=-35 dBm Extra: Last beacon: 68ms ago

O altres... # iwconfig eth1 txpower eth1

unknown transmit-power information. Current Tx-Power:15 dBm

(31 mW)

Podem veure què podem preguntar a la targeta amb 'iwlist' sense paràmetres.

Gestió de xarxes d’àrea local

3.2 Configuració automàtica de xarxes 3.2.1 Bootstrap protocol Inicialment el Bootstrap era, i és, una alternativa a RARP (protocol que serveix per obtenir la IP demanada una adreça física) 02:60:8c:48:84:49 – 172.16.3.10 Però té més versatilitat i permet fer molt més. Bootstrap fa servir UDP ( i per tant no li calen protocols extres tal com li passa al ARP). Normalment fa servir els ports 67 (el servidor) i 68 (el client) El client BOOTP envia un missatge broadcast (BOOTREQUEST) que conté com a mínim l’adreça física del client. S’envia fent servir l’adreça 255.255.255.255 (limited broadcast address) i s’espera una resposta del servidor. En cas de no rebre cap resposta es torna a demanar. El servidor respon amb BOOTREPLY a tots els host informant-los. Com que això es fa en temps d’inici de l’ordinador, el client encara no coneix la seva IP, i el protocol aprofita per enviar-li una sèrie de dades per la configuració.

Gestió de xarxes d’àrea local

3.2.2 DHCP Està dissenyat per ser compatible amb BOOTP. Fa servir UDP pels ports 67 i 68, i aprofita els missatges de BOOTREQUEST i BOOTREPLY (expandint-los a 312 bytes, BOOTP era de 64), però millora el protocol en: -

Els paràmetres donats pel DHCP donen tot el definit en els requeriments per un host d’Internet DHCP permet l’assignació automàtica d’adreces IP i d’altres paràmetres de configuració de la xarxa (molts d’aquests paràmetres moltes vegades no calen perquè ja estaven definits) La majoria de vegades només ens interessa l’assignació automàtica d’adreces IP.

DHCP (Dynamic Host Configuration Protocol) pot funcionar de tres formes: •

Assignació manual: L’administrador té el control de les adreces i les assigna específicament als clients • Assignació automàtica: El servidor assigna les adreces automàticament a partir d’un rang d’adreces que hem definit. • Assignació dinàmica: El servidor assigna les adreces per un temps limitat (lease). Quan aquest temps s’ha acabat el client l’ha de tornar, però pot demanar una extensió al servidor. També pot tornar-la quan vulgui abans de que s’acabi el temps. El servidor reclama l’adreça quan s’acabi el temps. L’assignació dinàmica és útil quan tenim molts ordinadors i n’hi ha molts que es connecten i desconnecten (així només fem servir les adreces que ens fan falta) No tots els ordinadors poden tenir adreces dinàmiques. Els servidors de noms (DNS), els servidors de correu, els hosts de login, etc... no poden funcionar amb DHCP. Els servidors de DNS especialment tenen problemes amb les assignacions d’adreces automàtiques perquè canvien constantment. En els llocs on es fa servir DHCP tenim una mescla de: - Adreces permanents assignades als sistemes - Adreces manuals assignades a clients amb DHCP/BOOTP - Adreces dinàmiques de clients DHCP.

Gestió de xarxes d’àrea local

3.2.3 Configuració de DHCP en Linux La configuració del servidor DHCP en Linux, com sempre, es pot fer amb els múltiples assistents que tenen les diferents distribucions o simplement editant el fitxer de configuració. Aquest fitxer es a /etc/dhcp.conf El primer que ens cal és dir a qui respondrà el servidor de DHCP a través de la línea “subnet” subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option subnet-mask 255.255.255.0; option domain-name “xarxa.net”; option domain-name-servers 192.168.1.1; range dynamic-bootp 192.168.1.100 192.168.1.200; default-lease-time 21600; max-lease-time 43200; }

En aquest exemple definim que les adreces que repartirà el servidor de DHCP seran des del 192.168.1.100 al 192.168.1.200. (range dynamic-bootp) El temps que un ordinador tindrà l’adreça en prestec, i quin serà el màxim si demana que se li allargui el temps ( default-lease-time i max-lease-time ) També enviem quin és el router (routers) i el DNS per defecte (domain-name-servers) i el nom del domini de la xarxa (domain-name). S’ha de tenir en compte que totes les línies han d’acabar amb un “;” També podem forçar a que el servidor enviï sempre la mateixa adreça a un ordinador en concret. Per això ens caldrà averiguar l’adreça MAC de l’ordinador. host P4 { hardware ethernet 00:05:ba:32:09:cd; fixed-address 192.168.1.2; }

Podem repetir aquestes seccions tantes vegades com calgui per tots els ordinadors de la nostra xarxa.

Gestió de xarxes d’àrea local

3.2.4 Configuració de DHCP en Windows Instal·lació del servei DHCP en Windows X Server Sota Windows 2000 per instal·lar el servei de DHCP cal fer el següent: 1. Iniciar el programa d’afegir/eliminar programes en el Panell de Control 2. En el costat “Afegir/Eliminar Windows components” 3. Premem el botó “Components” per iniciar l’assistent 4. “Següent” 5. Serveis de Xarxa  Detalls 6. ‘Dynamic Host Configuration Protocol (DHCP)’ i ok 7. “Següent” fins al final La configuració del DHCP en Windows es fa també des de l’entorn gràfic

Gestió de xarxes d’àrea local

3.3 Usuaris En un sistema monousuari, l'únic usuari del sistema és l'usuari que s'asseu davant de l'ordinador. Aquest usuari té accés a tots els recursos de l'ordinador sense cap restricció. Quan comencem a tenir sistemes multiusuari tenim la necessitat de saber quin usuari accedeix a cada un dels recursos. Considerem un sistema multiusuari a aquell que compleix aquesta condició: permet l'accés a determinats recursos en funció de quin usuari és. Per tant per distingir cada un dels usuaris s'han de crear comptes d'usuari individuals que tenen associades unes característiques que el distingeixen dels altres. Per distingir els diferents usuaris els sistemes guarden informació diversa, però el més corrent és: • • •

•

• • •

Nom de l'usuari (o compte): És el nom pel qual l'usuari s'identificarà. Normalment és un nom fàcil de recordar i únic al sistema. Nom complet de l'usuari i informació d'identificació. Informació de la durada del compte. Sol ser corrent no crear usuaris amb comptes il·limitats sinó amb una durada determinada que un cop ha passat el compte queda anul·lat. Contrasenya. En la majoria dels sistemes és la forma d'identificar els usuaris. Normalment cal obligar als usuaris a triar una paraula clau que compleixi uns criteris de seguretat i que no sigui fàcil d'endevinar. Grup al que pertany Programes d'inici. Quins són els programes que s'inicien quan l'usuari entra al sistema. Directori propi. A cada usuari se li assigna un directori en el sistema de fitxers en el qual pot emmagatzemar els seus programes i dades.

Un cop creat l'usuari se li han de definir els accessos als diferents recursos. Des d'un punt de vista de xarxes, totes les persones que tinguin accés a la xarxa han de tenir un compte d'usuari. Un compte d'usuari fa possibles diverses coses: • • •

Autenticar la identitat de la persona que es connecta a la xarxa. Controlar l'accés als recursos del domini Auditar les accions realitzades fent servir el compte.

Cada persona que faci servir el sistema ha de tenir el seu propi compte d'usuari. Rarament és una bona idea que diverses persones facin servir el mateix compte. No només hi ha el problema de seguretat, sinó que els comptes es poden fer servir per identificar unívocament a tots els usuaris. S'HA DE SABER QUI ESTÀ FENT QUÈ. Especialment en una xarxa gran i ocupada, la gestió dels comptes d'usuari és un procés continu d'afegiment, eliminacions i canvis de comptes. Encara que aquests canvis són relativament senzills, poden consumir temps i s'han de gestionar amb compte.

Gestió de xarxes d’àrea local Grups Quan es volen definir característiques comunes a diferents usuaris de forma senzilla existeixen els grups. En un grup s'especifiquen una sèrie de permisos per a tots els usuaris de manera que sempre podem crear un usuari i definir-li permisos per defecte afegint-lo a un grup. La informació que es guarda dels grups depen del sistema, però normalment sol ser: • • •

Nom del grup: Nom que identifica al grup i que el diferencia dels altres. Han de ser únics al sistema Descripció. Generalment indica la finalitat de la creació del grup. Usuaris que pertanyen al grup.

Les assignacions d'accés als recursos és millor fer-les directament als grups en comptes de als usuaris perquè d'aquesta forma es podran crear usuaris amb els mateixos permisos fàcilment. Si no es fa així afegir permisos a un usuari ens pot portar molta feina ja que haurem de recórrer el sistema de fitxers per assignar permisos al nou usuari. L'altre avantatge serà que podrem treure els permisos a qualsevol usuari

Gestió de xarxes d’àrea local Dominis en Windows NT Un domini és un conjunt d’ordinadors (servidors + estacions de treball que comparteixen característiques comunes segons els accessos. Un usuari registrat en un domini amb un nom d’usuari, automàticament és capaç d’accedir a tots els serveis del domini fent servir el mateix nom i la mateixa contrasenya. Dins dels servidors de domini hi ha dues jerarquies: El servidor PDC (Primary Domain Controller) i els servidors BDC (Backup Domain Controller). Per cada domini hi ha d’haver com a mínim hi ha d’haver un PDC, i només 1, i possiblement diversos BDC. Les dades sobre els usuaris es guarden en una base de dades anomenada SAM, que la té qualsevol PDC. El PDC s’encarrega de copiar aquesta base de dades d’usuaris a tots els altres servidors de forma periòdica. Això allibera l’administrador de molta feina. Windows NT Server ve preparat amb els protocols adequats per suportar diversos tipus de clients: MS-DOS, Windows per treball en grup, OS/2, Windows 9x ... Entre els dominis hi ha relacions de confiança. Es diu que un domini A confia en un de B, o que hi ha una relació de confiança des de A a B si qualsevol usuari del domini B pot entrar a A. Un grup local és un grup d’usuaris, de forma que qualsevol usuari del grup pot entrar i accedir als recursos del servidor PDC del domini al que pertany el grup. Un grup global és igual que l’anterior, però pot ser vist des de qualsevol dels dominis que confien en el nostre. La diferència entre global i local és doncs la visibilitat.

Gestió de xarxes d’àrea local

3.3.1 Windows 2000/XP Windows 2000 només crea dues comptes predefinides: Administrador, que permet a l'usuari tots els permisos i la de convidat, que té drets limitats. La resta dels comptes els ha de crear l'administrador i són comptes del domini en un Server ( vàlides per tot el domini de forma predeterminada) o comptes locals (només serveixen per la màquina on es creen) Opcions: En les opcions dels comptes d'usuaris en un domini NT podem destacar: • Hores d'inici de sessió: De forma predeterminada, un usuari pot iniciar la sessió en qualsevol hora del dia o de la nit. Per raons de seguretat això es pot restringir a determinades hores o determinats dies. • Iniciar sessió a: Per defecte, tots els usuaris poden iniciar la sessió en qualsevol estació de treball. Per raons de seguretat es pot limitar l'accés per iniciar la sessió en màquines en concret a través de NetBIOS. • Caducitat del compte: Es pot fer que els comptes d'usuari caduquin. Grups d'usuaris: En Windows XP per defecte hi ha, per exemple, els següents grups d'usuaris: • Administradors: Són comptes que tenen accés complet a l'equip o al domini. • Duplicadors: Poden fer còpies d'arxius en un domini. • Convidats: Poden fer el mateix que els usuaris, excepte que perden el compte al apagar la sessió. • Operadors de configuració de xarxa: Poden tenir privilegis d'administració de la xarxa. • Usuaris: No poden fer canvis accidentals o esporàdics de la configuració del sistema. • Usuaris avançats: Tenen alguns privilegis més, però algunes restriccions. Poden executar aplicacions heretades i certificades. Instal·lar nou programari. • Usuaris d'escriptori remot: Poden accedir al sistema des de fora de l'equip.

Gestió de xarxes d’àrea local

3.3.2 Linux / Unix El sistema manté una certa quantitat d'informació sobre l'usuari. Aquesta informació és: • • • • • • •

Nom d'usuari: El nombre de usuari és l'identificador únic donat a cada usuari del sistema. Els noms d'usuari es limiten a 8 caràcters. ID d'Usuari: La ID és un número únic que es dóna a cada usuari del sistema. El sistema normalment manté la pista de la informació per ID i no pel nom de l'usuari. Group ID : La ID de grup és la identificació del grup de l'usuari per defecte. Contrasenya: El sistema emmagatzema la contrasenya xifrada del l'usuari. La comanda passwd es fa servir per posar i canviar les claus dels usuaris. Nom real complert: Nom de l'usuari. Directori inicial: El directori inicial és el directori en el que es col·loca l'usuari quan es connecta. Cada usuari ha de tenir el seu propi directori d'usuari que normalment està a /home Intèrpret de comandes d'inici: Quin és el programa que els usuaris fan servir per interactuar amb el sistema ( ex. /bin/bash o /bin/tcsh )

Aquesta informació està a el fitxer /etc/passwd. El format de cada línia és: nom: contrasenya encriptada :UID:GID: nom complet :dir inici : intèrpret a usar

Un exemple pot ser: xavier:Xv8Q981g71oKK:102:100:Xavier Sala:/home/xavier:/bin/bash Les contrasenyes es xifren fent servir una clau secreta. Només si es coneix la clau es pot desxifrar. Alguns sistemes, actualment quasi tots, fan servir claus en “ombra”, en la que la informació xifrada està en el fitxer /etc/shadow ja que el /etc/passwd és llegible per tots els usuaris i així es té un grau superior de seguretat. En el shadow es tenen unes funcions extres com poden ser: expiració de les contrasenyes. El quart camp, el GID és un número que determina a quin grup pertany un usuari. Aquesta informació es guarda en el /etc/group. Per deshabilitar temporalment un usuari, podem iniciar la contrasenya per '*' i d'aquesta manera l'usuari no podrà entrar. adduser – userdel L'usuari root pot establir la contrasenya de tots els usuaris simplement amb “passwd usuari” Grups d'usuaris: Cada usuari pertany a un o més grups. La única importància real dels grups d'usuaris és la que fa referència als permisos de fitxers. Cada fitxer té un grup propietari i un conjunt de permisos de grup que defineixen de quina forma pot accedir a un arxiu un usuari.

Gestió de xarxes d’àrea local Per defecte en un sistema Unix hi ha diferents grups definits ( bin, mail, sys ... ). Els usuaris no han de pertànyer a cap d'ells, es fan servir per permisos del fitxers del sistema. El fitxer /etc/group conté informació sobre els grups. El format de la línia és: nom de grup:contrassenya:GID:altres membres Exemple: usuaris:*:100:mdw,torvalds (els usuaris mdw i torvalds pertanyen al grup usuaris.) El grup root és un grup especial que el sistema reserva per l'administrador. (número 0) La clau del grup rarament es fa servir. addgroup o groupadd ( o editar ) i per esborrar s'esborra directament.

3.3.3 Contrasenyes S'hauria de fer que tots els usuaris tinguin contrasenyes ben escollides i se'ls hauria demanar que les canviessin periòdicament. Els comptes haurien d'establir-se de forma que es bloquegin quan es posin contrasenyes incorrectes ( el millor és deixar tres intents abans de procedir al bloqueig) Una bona contrasenya té les següents característiques: • • • •

No és una rotació dels caràcters de nom d'inici de sessió. Conté almenys dos caràcters alfabètics i un de no alfabètic. Té una llargada de almenys 6 caràcters. No és una dada relativa a l'usuari: inicials, inicials dels fills, o dades significatives o una mescla d'algun d'aquests aspectes amb informació personal de fàcil disponibilitat ( data de naixement, DNI, número de telèfon o número de matrícula).

Entre les millors contrasenyes es troben els acrònims alfanumèrics de frases que tenen algun significat per l'usuari però que no es provable que els altres usuaris hi trobin lògica. Això fa que la contrasenya sigui fàcil de recordar per l'usuari, i que també sigui difícil d'endevinar per una persona de fora. Convé educar els usuaris sobre les contrasenyes i la seva privacitat, però sobretot, hem de fer cas del consells nosaltres mateixos: La contrasenya del 'administrador / root ha de ser bona i l'hem de canviar de manera habitual. Això reduirà les possibilitats de que algú accedeixi il·legalment al sistema. Cal extremar la seguretat en cas de que els usuaris es connectin per mitjà de línies públiques ( telefòniques, etc ... ) Tots els administradors haurien de tenir dos comptes: la de l'administrador i un compte d'usuari normal per fer servir habitualment, excepte quan hagin de fer tasques d'administració. 30

Gestió de xarxes d’àrea local Els intrusos en un sistema el que busquen són els comptes d'administració.

Gestió de xarxes d’àrea local

3.3.4 Dominis La idea dels dominis és molt senzilla: tenir un lloc centralitzat en el que guardarem la informació de la nostra xarxa local que podrà ser consultada pels clients. Els dominis van per facilitar les tasques d'administració de les xarxes ja què a mesura que les xarxes anaven creixent la feina per mantenir-les al dia era cada vegada més gran. Per això, per fer aquestes tasques més senzilles col·locar tota la informació en un punt centralitzat feia que només calgués administrar aquest punt sense haver d'anar a totes les estacions.

Gestió de xarxes d’àrea local

3.3.5 NIS El NIS (o YP yellow pages) és un sistema de gestió de Dominis que funciona principalment en sistemes Unix i que permet centralitzar informació en servidors. El seu objectiu és que qualsevol usuari pugui identificar-se en qualsevol estació de treball d'una xarxa local sense haver de donar-lo d'alta a totes les estacions. Com a mínim hem de tenir un servidor i diversos clients per poder fer funcionar un sistema amb NIS. Tot i així les possibilitats són moltes (diversos servidors col·laborant, diversos servidors amb un primari i els altres secundaris ... ) Els servidors secundaris són avisats dels canvis en la Base de dades amb el programa yppush i automàticament sincronitzen les seves dades. Tot i que és possible, no és recomanable que els clients cridin als servers a través de broadcast.

3.2.5.1 Configuració del servidor 3.2.5.1.1 Configuració del servidor en Mandriva Perquè NIS pugui funcionar cal que el servidor NIS estigui en marxa. Programari: •

ypserv

•

yp-tools

•

ypbind (només si volem que també sigui client)

Cal tenir el portmap engegat! En l'exemple que seguirem el domini serà: nis_linux. El nom del servidor NIS serà: servidor

Per començar cal que declarem el domini NIS en el sistema: Editem el fitxer /etc/sysconfig/network (a Redhat & variants) o a /etc/rc.config (altres). Cal modificar o afegir la línia següent: NISDOMAIN=nis_linux

També hem de fer la configuració del servidor. Dins del directori /var/yp caldrà editar el fitxer Makefile i verificar les opcions següents:

Gestió de xarxes d’àrea local NOPUSH=false MERGE_PASSWD=false MERGE_GROUP=false all: passwd group shadow \ # hosts rpc services netid protocols mail \ # netgrp publickey networks ethers bootparams printcap \ # amd.home auto.master auto.home auto.local passwd.adjunct \ # timezone locale netmasks La primera línia serveix per definir si tenim un servidor NIS secundari (false) o no (true) La segona línia i la tercera serveix per definir si fem servir shadow passwords o no. la darrera línia serveix per dir què és el que volem exportar. (en aquest cas /etc/passwd, /etc/hosts, /etc/group

Tanmateix podem veure que hi ha moltes més possibilitats per compartir all: passwd group hosts rpc services netid protocols mail \ # netgrp shadow publickey networks ethers bootparams printcap \ # amd.home auto.master auto.home auto.local passwd.adjunct \ # timezone locale netmasks

Podem fer servir el programa de generació de mapes per defecte: # /usr/lib/yp/ypinit -m

Un cop tinguem preparada la configuració, caldrà que activem el servidor (però no oblidar d'assignar el domini): # nisdomainname nis_linux # cd /var/yp # make

Això ens generarà dades dins d'un directori al fitxer /var/yp (són els mapes) Després editem el fitxer de configuració del servidor: /etc/ypserv.conf hi hem d'afegir: #Host

:Map

:Security

192.168.1. 192.168.1.

:passwd.byname :passwd.byuid

:port :port

:Passwd_mangle :yes :yes

Un cop estigui tot fet, només hem d'engegar el servidor i comprovar que s'iniciarà quan reiniciem la màquina: # # # #

/etc/rc.d/init.d/yppasswdd start /etc/rc.d/init.d/ypserv start chkconfig --add yppasswdd chkconfig --add ypserv

(En principi yppasswdd no hauria de caldre perquè ypserv ja el cridarà) Si es fan modificacions en el fitxer /etc/hosts cal tornar a fer els mapes dins de /var/yp

3.2.5.1.2 Configuració del servidor en Ubuntu

Gestió de xarxes d’àrea local

3.2.5.2 Configuració dels clients 3.2.5.2.1 Configuració en Mandriva Cal que tinguem tots els programes instal·lats per poder fer la instal·lació del NIS en Linux: Programari necessari: • •

yp-tools ypbind (ypbind és el dimoni que connecta amb el servidor)

De la mateixa forma que amb el servidor cal modificar alguns fitxers: Afegir a /etc/sysconfig/network o /etc/rc.config: NISDOMAIN=nis_linux

Al fitxer /etc/yp.conf domain nis_linux server 192.168.1.1 ypserver nis_linux

Ens podria interessar, sobretot si tenim diversos servidors que el NIS busqui el servidor per la xarxa enviant missatges de broadcast: domain nis_linux broadcast

A més ens cal informar al sistema que també es podran fer logins a través de la xarxa: • Editem el /ect/nsswitch.conf passwd : group : hosts :

•

files nis files nis files nis dns

No cal oblidar que ens cal dir-li al sistema quin és el domini NIS i després reiniciar el sistema: # nisdomainname nis_linux # /etc/rc.d/init.d/ypbind start

•

Afegir-lo als serveis per defecte quan tornem a iniciar l'equip # chkconfig --add ypbind

3.2.5.2.2 Configuració en Ubuntu En Ubuntu no es distingeix entre programes pel client i programes pel servidor o sigui que només cal instal·lar el mateix paquet del servidor •

nis

## FALTA

Gestió de xarxes d’àrea local

3.2.5.3 Comprovar el funcionament El primer que fem és veure si el client reconeix el nostre servidor: # ypwhich

Ens ha de tornar el nom del servidor # ypwhich -m

Ens dóna el nom del servidor master Cal recordar que per modificar els passwords no s'ha de fer servir passwd sinó yppasswd En cas de no connexió sense cap motiu aparent, cal vigilar els arxius: /etc/hosts.allow i /etc/hosts/deny

3.2.5.4 Servidors esclaus Per poder fer servir servidors esclaus ens cal fer diverses passes: 1. Afegir la IP del server esclau que volem afegir a el fitxer /var/yp/ypservers 2. Comprovar qui és el server master # ypwhich –m server

3. Després d’haver comprovat que l’ypbind està aturat preparem el sistema per copiar-hi el mapa de dades # ypinit -c # ypwhich –s server

En els clients podem afegir la IP de l’esclau al /etc/yp.conf

Gestió de xarxes d’àrea local

Exportar directori home Per poder exportar el directori /home de cada usuari ens obligarà a que aquest directori estigui compartit amb NFS. Per fer-ho afegim a /etc/exports la línia: /home

Eventualment si només volem que les màquines toto, titi i tata puguin accedir al directori /home, la línea serà: /home titi(rw) tata(rw) toto(rw)

Perquè el fitxer pugui ésser pres en consideració no cal oblidar de fer la exportació: exportfs –a

En aquest cas ja gairebé estem, només ens falta fer un enllaç de la carpeta en que es munti l’exportat a /home (suposem que és /export) : # mkdir /export # ln -s /home /export

I modificar l’arxiu /etc/passwd i remplaçar /home per /export/home com mostra l’exemple següent: veronique:3GGWf/uWiPoWM:4002:4000::/export/home/veronique:/bin/bash

NOTA: En el cas de que tinguem shadow passwords, veurem que la contrassenya només serà una x. Cal recordar que després de modificar el passwd, ens caldrà tornar a generar el mapa yp, per tant caldr’a anar a /var/yp i fer: # cd /var/yp # make

Gestió de xarxes d’àrea local

3.3.6 Serveis de directori Els serveis de directori no són res nou, el sistema de gestió de noms d'Internet (DNS) ja era una aproximació als serveis de directori. Però és ara quan els serveis de directori s'estan convertint en els dominadors de la gestió centralitzada de xarxes, tot i que encara són més populars pel que “poden arribar a fer” que no pas pel que estan fent actualment. La idea general d'un sistema de directori és la de consolidar tots els serveis disponibles en una xarxa en un directori al que els clients hi podran fer-hi consultes. Aquests clients poden ser qualsevol cosa: des de navegadors, clients de correu, servidors de correu, etc.. Emmagatzemar tota la informació en un sol lloc no consisteix només en emmagatzemar-la de qualsevol forma sinó que requereix que estigui ben pensat com s'organitzarà per respondre a les preguntes dels clients. Els serveis de directori ens permetran reduir la redundància de dades en els sistemes. ● ●

En quants ordinadors hi ha la configuració de les impressores, els fitxers hosts repetits, etc..? Evidentment, els comptes d'usuari també es poden emmagatzemar en el directori. Però a més d'aquesta forma podrem reduir la quantitat de llocs en les que es guardarà l'usuari i la contrasenya (el servidor de correu també fa servir el mateix compte, l'accés a determinades carpetes, etc..)

Es tracta de fer una passa més enllà de la que ens oferien els dominis i emmagatzemar qualsevol informació referent a la xarxa. L'objectiu és eliminar totes les dades redundants de la nostra xarxa (Evitar coses com que eliminar un usuari signifiqui haver d'anar recorrent ordinadors per eliminar-ne el rastre). Les dades redundants sempre corren el perill, en un moment o un altre, de convertir-se en desfasades perquè s'han actualitzat en alguns llocs i en d'altres no. Com són? Un directori és una base de dades jeràrquica optimitzada per la lectura, recerca i filtrat d'informació. Els directoris d'aquesta base de dades contenen informació descriptiva (atributs) Un directori no és exactament una Base de Dades perquè està dissenyat pensant en que serà llegit moltes vegades més que escrit, mentre que les base de dades es dissenyen pensant en que les lectures i escriptures seran equilibrades. Això fa que els sistemes de directori no necessitin suport per transaccions i bloquejos d'escriptura (o almenys que no en siguin un component essencial) sinó que quan sigui necessari en tenen prou amb fer canvis en un directori o bé substituir-lo totalment. ● ● ●

En cada directori s'hi pot posar molt tipus diferent d'informació: des de dades a requisits sobre com es pot consultar o canviar la informació, etc.. Hi poden haver serveis de directori locals, donar informació sobre una sola màquina o bé globals (es poden posar serveis de directori a Internet). Quan un servei de directori és massa gran, generalment s'implenta distribuït (les dades es reparteixen entre diferents màquines que cooperen per formar el directori)

Gestió de xarxes d’àrea local D'entre tots els serveis de directori que existeixen nosaltres en veurem dos: - Active Directory - OpenLDAP

Gestió de xarxes d’àrea local

3.3.7 OpenLDAP OpenLDAP és un servei de directori que implementa l'estàndard Lightweight Directory Access Protocol (LDAP). LDAP és un conjunt de protocols oberts que es fan servir per accedir a informació guardada centralment a través de la xarxa. •

•

• • • •

Informació global centralitzada: L’avantatge més gran d’LDAP és que la informació per tota la organització es pot consolidar dins d’un repositori central. Per exemple, en comptes d’administrar llistes d’usuaris per cada grup dins d’una organització, es pot fer servir LDAP com directori central accessible des de qualsevol part de la xarxa. Seguretat de la informació: Donat que LDAP suporta Secure Socket Layers (SSL) i Transport Layer Security (TLS), les dades delicades es poden protegir dels curiosos. També pot fer servir els TCP Wrappers per evitar que s'accedeixi a la informació basant-nos en el lloc on ens la demanen. Però també té utilitats de control d'accés molt potents poden controlar l'accés a la informació en funció de informació LDAP, IP, noms de domini, etc.. Varietat de Bases de Dades: LDAP suporta un gran número de bases de dades per guardar-hi els directoris. Això permet que els administradors tinguin la flexibilitat necessària per desplegar la base de dades més indicada per cada tipus d’informació que el servidor ha de guardar. Programable: També té una interfície de programació (API) ben definida, el número de programes per LDAP és molt gran i creixen cada dia en quantitat i qualitat. Suporta internacionalització fent servir Unicode i etiquetes de llenguatge Es pot configurar el dimoni perquè vagi emmagatzemant rèpliques de la BDD a altres llocs seguint l'esquema un mestre/molts esclaus. Però es segur que en el futur suportarà molts/molts. La part negativa de LDAP és que pot ser complicat de configurar.

Informació La informació a LDAP està basada en les entrades que tindran un únic nom distingit (DN) i una col·lecció d'atributs. Cada atribut té: • •

Entrada – Una entrada és una unitat en un directori LDAP. Cada entrada s’identifica amb el seu nom únic dn (Distinguished Name), cn (common name) Atributs – Els atributs són peces d’informació directament associada amb la entrada. Per exemple, una organització pot ser representada com una entrada LDAP. Els atributs associats amb la organització poden ser número de fax, adreça, etc.. La entrada poden ser també persones i els atributs el telèfon, el correu electrònic, etc.. Alguns atributs poden ser obligatòris i altres opcionals. Una definició objectclass determina quins atributs fan falta i quins no per cada entrada. Les definicions objectclass estan en diferents fitxers dins del directori /etc/openldap/schema/.

Aquestes entrades poden emmagatzemar una gran varietat d’informació i també es poden fer servir de forma semblant a la de NIS (Network Information Service),

Gestió de xarxes d’àrea local permetent que qualsevol pugui accedir al seu compte des de qualsevol màquina de la xarxa LDAP. LDAP també es pot fer servir com un directori telefònic virtual, permetent als usuaris accedir fàcilment a la informació de contacte pels altres usuaris encara que el seu objectiu va més enllà ja que és capaç de propagar els seus directoris a altres serveis LDAP per tot el món, permetent accés global a la informació. Organització jeràrquica La informació s'organitza de forma jeràrquica fent servir directoris. Això tradicionalment servia per representar geogràficament les organitzacions agrupant-les per països i sota les organitzacions s'hi incloïa la informació necessària: treballadors, impressores, documents, etc.. Però una forma més corrent actualment és que aquesta s'organitzi aprofitant-se dels noms de domini d'Internet

En l'exemple podem veure que hi ha una persona que s'identifica com a 'xavier' en la organització 'prova.com' La forma de referir-s'hi serà a través del seu RDN (nom relatiu distingit) que en l'exemple anterior seria: “uid=xavier,ou=People,dc=prova,dc=com” El format complet dels DN està descrit al RFC2253: LDAP v3: UTF-8 String representation of Distingished Names” Necessitat del backend Cal tenir en compte que LDAP només és un protocol i que per tant necessita un backend per guardar les dades persistents. El protocol no diu res sobre de quina forma s'han de guardar les dades en disc i per tant cal tenir algun mecanisme per fer-ho. Els clients però, no tindran mai informació sobre la forma en que es guarda la informació, ni del backend que es farà servir. Per això openLDAP ens aporta uns backends de base de dades amb els quals podem treballar. En principi qualsevol dels que té disponibles funcionarà bé encara que per defecte els assistents en recomanen un. Funcionament

Gestió de xarxes d’àrea local LDAP és un sistema client-servidor. El servidor pot fer servir diferents bases de dades per guardar un directori, cada un optimitzat per operacions de lectura ràpides i de gran volum. Quan una aplicació de client LDAP es connecta a un servidor LDAP pot, o bé consultar un directori, o intentar modificar-lo. • •

En una consulta, el servidor, o bé la contesta, o, si no pot contestar localment, pot dirigir la consulta a una altre servidor LDAP que tingui la resposta. Si l’aplicació client vol modificar la informació del directori LDAP, el servidor verifica que tingui permís per efectuar el canvi i després afegeix o actualitza la informació.

Els fitxers LDIF LDIF és el format d’intercanvi de dades de LDAP (LDIF) i és una representació en text ASCII d’entrades LDAP. Els arxius fets servir per importar dades als servidors LDAP han d’estar en format LDIF. Una entrada LDIF es ven com: [<id>] dn: <distinguished name> <attrtype>: <attrvalue> <attrtype>: <attrvalue> <attrtype>: <attrvalue>

Una entrada pot contenir tants parells d’ <attrtype>: <attrvalue> com sigui necessaris. Una línea en blanc indica el final de una entrada. Cal no oblidar que cada parella ha d’estar definida en l’arxiu d’esquema corresponent per fer servir aquesta informació. Qualsevol valor comprès dins de “<” i “>” és una variable i pot ser configurat quan es creï una nova entrada LDAP, excepte per <id>. El <id> és un número determinat per l’aplicació que es fa servir per modificar una entrada. En principi no hi ha d’haver mai necessitat de modificar valors LDIF manualment. Per això hi ha les aplicacions LDAP.

Gestió de xarxes d’àrea local

3.3.7.1 Instal·lació d'un servidor OpenLDAP Com que en les diferents distribucions la instal·lació del servei de directori és diferent veurem com fer la instal·lació amb dues distribucions que ho fan de formes relativament diferents.

3.3.7.1.1 Instal·lació del servidor en Ubuntu Els paquets que calen en Ubuntu són els servidors slapd i slurpd, aquest segon només si tenim altres servidors, i a més són recomanables els paquests ldap-utils i migrationstools. # apt-get install slapd ldap-utils migrationtools

Com que la configuració no és complerta necessitem reconfigurar el servidor perquè ens pregunti tota la configuració important. # dpkg-reconfigure slapd

Això ho podem contestar fent servir la lògica excepte la opció de si volem fer servir la versió 2 del protocol que només cal que l'activem si ens fa falta perquè tenim algun programa vell. En el nostre exemple farem servir el domini “prova.com” Per algun motiu la configuració no es grava completament en el fitxer de configuració o sigui que haurem de definir qui serà l'administrador d'openLDAP i comprovar que ens ha emplenat el domini correctament i que l'administrador té contrasenya. Aquest fitxer està a /etc/ldap/slapd.conf database suffix rootdn rootpw

bdb "dc=prova,dc=com" "cn=admin,dc=prova,dc=com" {SSHA}5WcnZ/3lXJXf72pyS5Nv2z3sjNVrpm2m

# La base de dades estarà a: directory /var/lib/ldap

Per poder conèixer quina és la contrasenya que hem de posar a 'rootpw' fent servir la comanda ldappasswd i copiar el que ens surt per pantalla: # sldappasswd

New password: Re-enter new password: {SSHA}5WcnZ/3lXJXf72pyS5Nv2z3sjNVrpm2m Sembla que en teoria Ubuntu/Debian no fan servir el valor rootdn per definir l'usuari que té drets sobre tot el directori, sinó que crea l'usuari admin i l'injecta directament al directori. si volguessim podríem especificar l'atribut rootdn. O sigui que potser en un futur proper no calgui afegir les línies rootdn i rootpw però en les proves que he fet no funcionava. Un cop fet això podem iniciar el servidor per comprovar que tot funciona:

Gestió de xarxes d’àrea local # /etc/init.d/slapd start Starting slapd:

[

]

Ho podem comprovar fent una consulta al servidor per veure quines dades hi ha a dintre: $ ldapsearch -x -b dc=debuntu,dc=local

O bé amb slapcat (però no ens en podem fiar gaire perquè funciona fins i tot amb el servei slapd aturat) # slapcat

3.3.7.1.2 Instal·lació del servidor en Fedora Els paquets en Fedora tenen un nom diferent però la resta és pràcticament igual. # yum install openldap openldap-devel nss_ldap openldap-clients openldap-servers

També hem de comprovar que tot està bé al fitxer de configuració que ara està a /etc/openldap/slapd.conf database suffix rootdn rootpw

bdb "dc=prova,dc=com" "cn=admin,dc=prova,dc=com" {SSHA}5WcnZ/3lXJXf72pyS5Nv2z3sjNVrpm2m

# La base de dades estarà a: directory /var/lib/ldap

Per poder conèixer quina és la contrasenya que hem de posar a 'rootpw' fent servir la comanda ldappasswd i copiar el que ens surt per pantalla: # sldappasswd

New password: Re-enter new password: {SSHA}5WcnZ/3lXJXf72pyS5Nv2z3sjNVrpm2m Un cop fet això podem iniciar el servidor per comprovar que tot funciona: # service ldapd start Starting slapd:

[

]

I ens assegurem que al reinicar la màquina tornarà a engegar-se # chkconfig ldapd on

De la mateixa forma podem comprovar que tot està funcionant correctament amb 'ldapsearch'

Gestió de xarxes d’àrea local $ ldapsearch -x -b dc=debuntu,dc=local

Gestió de xarxes d’àrea local

3.3.7.1.3 Entrada de dades La primera cosa que cal fer abans d'entrar dades és crear-ne l'arbre. Per això necessitem crear un fitxer LDIF. En el nostre cas com que només volem importar els usuaris i els grups el fitxer serà com el següent: dn: ou=People, dc=prova, dc=com ou: People objectclass: organizationalUnit dn: ou=Group, dc=prova, dc=com ou: Group objectclass: organizationalUnit

Això ens servirà per crear els dos nodes 'People' i 'Group' que ara podrem poblar amb les dades. Per crear-los hem de fer servir ldapadd: # ldapadd -x -W -D "cn=admin,dc=prova,dc=com" -f esquema.ldif

-x no volem SASL -W demanarà contrasenya -D identifiquem l'administrador En comptes de fer el fitxer amb les dades dels clients i grups manualment podem fer servir les migrationtools que són uns scripts en Perl que ens faran la feina. Abans de fer-les servir necessitem definir el nostre domini al fitxer 'migrate_common.pl'. En aquest fitxer necessitem buscar les línies que veiem a continuació i editar-les d'acord amb el nostre domini. (aquestes línies no estan al principi). # cd /usr/share/migrationtools/ # joe migrate_common.pl

... $DEFAULT_MAIL_DOMAIN = "prova.com"; $DEFAULT_BASE = "dc=prova,dc=com"; ...

I després ja podem anar per feina per crear els arxius LDIF que després importarem: # ./migrate_group.pl /etc/group ~/grups.ldif # ./migrate_passwd.pl /etc/passwd ~/contrasenyes.ldif

En comptes d'importar tots els usuaris del sistema podríem haver creat un fitxer que només contingués els que ens interessen # grep xavier /etc/passwd > usuaris.importats # grep pere /etc/passwd >> usuaris.importats ... # ./migrate_passwd.pl usuaris.importats ~/contrasenyes.ldif

Gestió de xarxes d’àrea local Un cop creat el fitxer LDIF podem comprovar que tot està bé i ja el podem importar a la base de dades de la mateixa forma que hem creat els nodes inicials # ldapadd -x -W -D "cn=admin,dc=prova,dc=com" -f grups.ldif # ldapadd -x -W -D "cn=admin,dc=prova,dc=com" -f contrasenyes.ldif

Els fitxers LDIF dels usuaris tindran una forma semblant a: dn: uid=pere,ou=People,dc=prova,dc=com uid: pere cn:: VXRKK=dQ== objectClass: account objectClass: posixAccount objectClass: top userPassword: {crypt}x loginShell: /usr/bin/git-shell uidNumber: 1010 gidNumber: 1000 homeDirectory: /home/pere gecos: Pere,,, ...

3.3.7.1.4 Gestió de LDAP Per gestionar el servidor LDAP podem fer servir molts programes. Entre els més populars hi ha “LDAP Client Browser” que està en Java i ens permet treballar-hi a través de diferents sistemes operatius (http://www-unix.mcs.anl.gov/~gawor/ldap/) També hi ha un programa en PHP phpldapadmin que podem fer servir a partir d'un servidor web. (http://wiki.phpldapadmin.info/tiki-index.php)

Gestió de xarxes d’àrea local

3.3.7.2 Instal·lació dels clients La instal·lació d'un client pot ser bastant diferent en funció de la distribució que estiguem fent servir. Pot anar des del simple emplenat de dades en un entorn gràfic fins a la edició de diferents arxius de configuració.

3.3.7.2.1 Configuració del client en Fedora La configuració del client en Fedora es pot fer des de l'entorn gràfic o des d'assistents sense problemes. Això ho podem fer des de l'entorn gràfic amb # system-config-authentification

O des de la consola amb: # authconfig

I només hem d'activar el suport LDAP i especificar el domini i l'adreça del servidor que farem servir.

3.3.7.2.2 Configuració del client en Ubuntu Instal·lem els paquets necessaris per un client LDAP: ● Un dels destacats és nscd que és un servidor que farà que s'identifiqui per nosaltres quan se'ns demani la contrasenya. ● libpam-ldap ens permetrà que el sistema es pugui autentificar a través de LDAP. ● libnss-ldap serveix per resolució de noms i grups # apt-get install libnss-ldap libpam-ldap nscd

Editem l'arxiu /etc/libnss-ldap.conf perquè faci resolució de noms host server base dc=prova,dc=com ldap_version 3 Amb això ja hauríem de poder fer la resolució de noms # getent passwd

Podríem definir la contrasenya a /etc/libnss-ldap.secret Això vol dir que podrem mapejar els identificadors del servidor i del client però encara no es podrà entrar. Per fer-ho necessitem editar més arxius/etc/pam_ldap.conf host server base dc=prova,dc=com ldap_version 3 rootbinddn cn=admin,dc=exemple pam_password md5

També podríem definir la contrasenya a /etc/pam_ldap.secret.

Gestió de xarxes d’àrea local

Sembla que en les noves versions de Ubuntu (a partir de Gutsy) la configuració dels fitxers /etc/pam_ldap.conf i de /etc/libnss-ldap.conf s'han unificat en un sol fitxer que és el /etc/ldap.conf. A més en 7.10 l'assistent deixa les dades d'aquest fitxer mal posades. O sigui que m'he trobat amb la necessitat d'editar-lo a mà perquè reflecteixi realment la configuració del nostre sistema: Host 192.168.0.104 ... base dc=prova,dc=com ... bind_policy=soft

Perquè els serveis facin servir LDAP necessitem afegir-lo als mòduls PAM que es troben a /etc/pam.d. El que fan servir tots els serveis és el common-* En teoria podría quedar com aquests però cal fer-hi proves ! /etc/pam.d/common-auth auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure /etc/pam.d/common-account account sufficient pam_ldap.so account required pam_unix.so # Per crear home directoris session required pam_mkhomedir.so umask=0022 skel=/etc/skel/ silent /etc/pam.d/common-password password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5 /etc/pam.d/common-session session sufficient pam_ldap.so session required pam_unix.so session optional pam_foreground.so

Alguns clients necessiten que canviem el fitxer /etc/ldap/ldap.conf per poder funcionar BASE dc=prova,dc=com URI ldap://server

s'ha d'editar el fitxer /etc/nsswitch.conf per definir-hi que les contrasenyes i els grups han de funcionar també amb ldap passwd: group: shadow:

compat ldap compat ldap compat ldap

Sembla que a vegades cal reiniciar el servidor nscd i que a vegades perquè funcioni cal canviar el 'compat ldap' per 'files ldap'

3.3.7.2.2 Configuració del client en Ubuntu 2 També podem fer la configuració del client fent servir AuthClientConfig (https://wiki.ubuntu.com/AuthClientConfig)

Gestió de xarxes d’àrea local

El que es pot fer és editar /etc/ldap/ldap.conf base dc=prova,dc=com bind_policy soft I després # sudo auth_client_config -a -p lac_ldap

Encara no he provar aquest sistema però sembla que funciona.

3.3.7.3 Comprovació de la instal·lació Per comprovar la instal·lació només hem de fer login al sistema client (millor des de la consola perquè ens donarà més detalls si alguna cosa no va bé). Un dels problemes que tindrem és que amb la instal·lació que hem fet fins ara tindrem que no es crearan els directoris 'home' dels usuaris. I per tant quan algun usuari entri per primera vegada al sistema no tindrà arxiu 'home'.

Gestió de xarxes d’àrea local

3.3.8 Active Directory de Windows Active Directory és un servei de directoris i el seu objectiu principal és guardar informació sobre els usuaris, recursos i entitats de xarxa i donar aquesta informació a tot aquell que tingui els permisos adequats per veure-la. Tot i que és una base de dades, no és una base de dades relacional, com l’SQL, sinó que la informació hi està representada com objectes que es creen per cada una de les entitats: usuaris, grups, ordinadors, impressores, gent de contacte, carpetes compartides, serveis, recursos, informació de configuració... Active Directory reemplaça les bases de dades d’usuaris i els models de domini de les versions anteriors de Windows (apareix per primera vegada en Windows 2000) •

Serveis d’Usuaris: Podem crear usuaris i controlar-los: com fan servir la xarxa, registrar què fan i fer-los complir les polítiques de seguretat que establim. • Serveis Empresa: Dóna una estructura escalable per gestionar xarxes de qualsevol mida. Podem, per exemple, delegar feines a estacions de nivells inferiors i especificar polítiques específiques per cada una. • Serveis de Directori: Podem guardar informació rellevant sobre qualsevol cosa del sistema i permetre-hi l’accés a qui ens interessi. Ex. Podem buscar usuaris per nom, impressores per característiques... Aquest servei es pot donar també fora de la nostra xarxa, segons els permisos. Podem fer-ne disponible una part a Internet. En general la informació de l’AD és d’una de dues característiques: • Significant: Afecta el funcionament del sistema (com entren els usuaris, quins serveis poden fer servir, etc..) • Informacional: Poden ser dades interessants pels usuaris del AD però són irrellevants pel sistema (Adreça postal, codi per entrada a un edifici) Si resumim molt, en Active Directori tenim tres tipus d’usuaris: - Administradors: Gestionen, configuren tot el relacionat amb la xarxa. Creen objectes específics i determinen qui hi pot accedir. - Usuaris del domini: - Aplicacions, serveis i ordinadors: Poden llegir la seva configuració de l’Active Directory i obrar en conseqüència. En alguns casos fins i tot poden guardar-hi informació. Un programa de fax pot fer servir la informació de l’Active Directory per averiguar a quin número s’ha d’enviar Els serveis poden publicar en quins ports estan disponibles perquè els programes hi puguin accedir.

Gestió de xarxes d’àrea local

3.3.8.1 Instal·lació d’un controlador de Domini d’Active Directory La instal·lació té uns requeriments dels que ens hem d’assegurar abans de començar: • •

Cal que hi hagi una partició en NTFS v5 en el sistema (versió de Windows 2000) Cal tenir un servidor DNS. Active Directory fa servir el DNS per emmagatzemar informació sobre els controladors de domini (DC) de la xarxa. Els sistemes client troben un DC per autenticar-se a través de consultes al DNS. El servidor DNS que fa servir Active Directory no té perquè estar executant-se en la mateixa màquina, ni cal que sigui el DNS de Microsoft, però cal que suporti el registre de Localització de recursos de RFC 2052 i el protocol d’Actualització dinàmica definit en la RFC 2136. Es pot fer servir Bind com a DNS

Si no tenim un servidor DNS, l’assistent d’instal·lació ens oferirà la possibilitat d’instal·lar-lo. (Microsoft DNS Server) perquè és necessari poder accedir al DNS per poder instal·lar Active Directory i per promoure un sistema a Controlador del Domini. • Cal tenir 250 Mb disponibles en el disc (200 per la base de dades i 50 pels logs) Instal·lació del primer DC 1. Iniciar el programa dcpromo.exe Es pot fer amb la eina “Configuración del Servidor” des del menú de “Herramientas Administrativas” o bé executar el programa dcpromo.exe des de la consola, bé des de la opció de menú “Ejecutar”. Evidentment cal ser Administrador

Gestió de xarxes d’àrea local 2. Tria del tipus de Controlador de Dominis que volem instal·lar. Després de la pantalla de benvinguda, l’assistent ens mostrarà una pantalla que determinarà què volem fer. Si el servidor ja és un controlador de domini, l’assistent només proporcionarà la opció de deixar de ser DC o fer-se membre d’un altre. En un equip que no és un DC, l’assistent mostra la pantalla:

•

Controlador de dominio para un nuevo dominio: Instal·la Active Directory en el servidor i el designa com el primer controlador de domini d’un nou domini. Això fa que l’assistent instal·li els arxius de suport d’Active Directory, crei el nou domini i el registri en el DNS

•

Controlador de dominio adicional para un dominio existente: Instal·la Active Directory en el servidor i replica la informació del directori des d’un domini existent

Gestió de xarxes d’àrea local • •

• •

Crear un nuevo árbol de dominios: Configura el nuevo controlador de dominio pare que aloje el primer dominio de un nuevo árbol. Crear un nuevo dominio secundario en un árbol de dominios existente: Configura el nuevo controlador de dominio para que aloje un hijo de un dominio de un árbol que ya existe. 3. Crear o unir-se a un bosc de dominis.

Crear un nuevo bosque de árboles de dominios: Configura el controlador de domini perquè sigui l’arrel d’un nou bosc d’arbres. Situar este nuevo árbol de dominios en un bosque existente: Configura el controlador de domini perquè afegeixi el domini en un arbre que ja té arbres de dominis.

En aquest cas seleccionem “Crear” perquè el primer DC de Windows 2000 serà sempre un nou domini, en un nou arbre, en un nou bosc. Quan instal·lem més DC haurem de posar-los on els correspongui. 4. Nom del domini. Per identificar el controlador de domini s’ha d’especificar un nom DNS vàlid pel domini que s’està creant. Aquest nom no té perquè ser el mateix del domini que tingui la empresa per Internet (encara que pot ser-ho). El nom no cal que estigui registrat a InterNIC, però és una bona idea si els usuaris qu accediran als recursos de la xarxa accediran a recursos d’Internet o hi accediran via Internet.

Gestió de xarxes d’àrea local

Quan els usuaris accedeixen als recursos d’Internet al mateix temps que als recursos de la xarxa, hi ha la possibilitat de que un nom de domini no registrat entri en conflicte amb un domini d’Internet registrat que faci servir el mateix nom. 5. Nom del domini NetBIOS. Després del nom DNS pel domini, ens demanarà el seu nom equivalent en NetBIOS pels clients que no suporten Active Directory. El Windows 2000 encara fa servir el nom NetBIOS pels noms d’equip, però Active Directory fa servir DNS pels dominis.

Si es tenen clients de sistema inferior ( Windows NT 4, Windows 9x, Microsoft Windows per Treball en grup o Client de xarxa Microsoft per sistemes MS-DOS), aquests només seran capaços de veure el nou domini a través del nom NETBIOS. Ha de ser de15 caràcters o menys.

Gestió de xarxes d’àrea local 6. Situar la Base de dades i el volum compartit. Després d’especificar els noms de domini, l’assistent ens demanarà on volem guardar la base de dades, el registre i el volum del sistema. S’aconsella, per millorar el rendiment, que no estiguin dins del mateix disc físic en que hi ha el sistema operatiu. La base de dades contindrà els objectes d’Active Directory i les seves propietats El registre contindrà les activitats del servei de directori.

El volum del sistema és un recurs compartit que conté informació del domini que s’aplica ala resta dels controladors del domini de la xarxa.

La base de dades, els registres i el volum del sistema d’Active Directory s’ha de situar en volums que facin servir el sistema d’arxius NTFS 5. Si l’assistent detecta que algun dels volums escollits no fa servir NTFS 5, s’hauran de convertir o seleccionar un altre volum perquè la instal·lació no falli.

Gestió de xarxes d’àrea local Es recomana que s’instal·lin, si és possible, en un altre disc físic del que hi ha el sistema operatiu. 7. Instal·lació opcional del DNS. En aquest punt ja es té tota la informació necessària per la instal·lació de l’Active Directory i fer a l’equip DC. El sistema comprova que els noms de domini no s’estan fent servir. També determina si el servidor DNS suporta el protocol d’Actualització dinàmica. Si no pot comunicar amb el DNS o el DNS que hi ha no compleix els requeriments, l’assistent ens ofereix instal·lar el Microsoft DNS Server i configurar-lo perquè funcioni com servidor autoritzat del domini. 8. Finalitzar la instal·lació. Després comença el procés d’espera mentre es copien totes les dades necessàries. - Es guarda un registre de informació en els arxius DCPromo.log i Dcpromoui.log que estan a la carpeta %systemRoot%\debug. - S’ha de reiniciar el sistema per acabar. - Es crea un compte d’administrador de domini amb el mateix nom que l’administrador de la màquina local.

Gestió de xarxes d’àrea local

3.3.8.2 Afegir un client en un Domini d’Active Directory A fer la instal·lació d'un sistema Windows client que pugui funcionar en grup se'ns demanarà, al fer la configuració de la xarxa, que ens unim a un domini existent o a un grup de treball. Si el controlador de domini encara no està disponible en el moment de la instal·lació, ens hi podem unir més endavant. Abans de començar el procés cal assegurar-se que l’equip té accés al mateix segment de xarxa de manera que pugui comunicar-se amb el domini. En la xarxa s’ha d’especificar l’adreça IP del servidor DNS del domini. Per unir-se a un domini n’hi ha prou amb unes senzilles passes: 1. Fer clic amb el botó secundari del ratolí a “Mi PC” i seleccionar “Propietats” 2. En el quadre de diàleg “Propiedades del sistema”, fem clic a la etiqueta “Identificación de red” i després a “Propiedades”

Normalment amb “Propiedades” en fem prou perquè l'assistent en molts casos fa un grup de preguntes que no deixen gaire clar què és el que farà. Cal no oblidar que com especifica a la part de sota, quan es faci un canvi el sistema s'haurà de reiniciar perquè funcioni amb la nova configuració.

Gestió de xarxes d’àrea local 3. En el quadre de diàleg “Cambios de identificación”, escrivim el nom del domini complet (en el nostre cas “informatica.cat”) a “Miembro de” “Dominio” i acceptem.

4. Ens demanarà un nom d’usuari i la contrasenya del domini. 5. Si tot ha anat bé ens donarà la benvinguda i si no ha anat bé, ens donarà un missatge d’error.

Estem obligats a reiniciar el sistema perquè els canvis comencin a funcionar.

Gestió de xarxes d’àrea local

3.3.8.3 Iniciar-se en el domini En Active Directory, cada compte d'usuari té un nom principal que consta de dues parts, el nom principal de seguretat i el sufix de nom principal. El nom principal és el que es fa servir per iniciar la sessió i el sufix és el nom predeterminat del DNS arrel de l'arbre de dominis. Ex. xavier en el domini informatica.cat serà xavier@informatica.cat. Amb Active Directory tenim: •

La copia de seguretat dels documents d’usuari està centralitzada.

•

Els usuaris poden accedir als seus directoris principals des de qualsevol equip client..

•

Es pot accedir als directoris principals des de clients que executin qualsevol sistema operatiu de Microsoft (MS-DOS i totes les versions de Windows).

Gestió de xarxes d’àrea local

3.3.8.4 Iniciar-se en el Domini des de Linux Amb l’aparició de Samba 3, Linux i els altres Sistemes que poden fer servir Samba, tenen la capacitat d’unir-se a un domini en Active Directory fent servir Kerberos per identificar-se. Samba 3 ofereix dos mètodes per identificar els usuaris d’Active Directory: •

Fer server comptes locals – Amb aquest sistema tots els usuaris han de tenir un compte local a /etc/passwd. Quan un client s’intenta connectar, es passen el nom d’usuari i contrassenya al DC. Tot menys les contrassenyes es guarda en els fitxers Linux.

•

Fer servir Winbind – Winbind és una extensió de Samba que permet executar un servidor Samba sense tenir que mantenir els comptes al Unix. La informació de convertir els UID de cada sistema és transparent perquè se n’encarrega el dimoni.

En l'exemple tindrem el domini INFORMATICA.LOCAL amb el servidor a 192.168.0.100 i el client a 192.168.0.2 Configuració prèvia Instal·lem els paquets necessaris: # aptitude install samba smbclient winbind krb5-user krb5-config

La configuració de Kerberos ens demanarà unes quantes coses, però posteriorment he modificat la configuració a mà per si de cas... What are the Kerberos servers for your realm? servidor.informatica.local What is the administrative server for your Kerberos realm? servidor.informatica.local

Per començar és millor assegurar-se de que la xarxa funciona correctament, que tenim accés al servidor fent-hi ping i de passada millor que no haguem de resoldre el nom del servidor cada vegada o sigui que editem el /etc/hosts i l'hi afegim: 192.168.0.2 client client.informatica.local 192.168.0.100 servidor servidor.informatica.local

I comprovar que tenim el DNS del Active Directory al sistema editant el /etc/resolv.conf (en el nostre exemple suposem que està allà mateix) nameserver 192.168.0.100

Edició de la configuració de Kerberos La identificació de AD es fa a través de Kerberos. Per tant necessitem configurar el Kerberos perquè s'entengui amb Linux. Editem el /etc/krb5.conf i incloem: [libdefaults] default_realm = INFORMATICA.LOCAL clockskew = 300

Gestió de xarxes d’àrea local [realms] INFORMATICA.LOCAL = { kdc = 192.168.0.100 default_domain = informatica.local admin_server = 192.168.1.254 } pruebas.local = { kdc = 192.168.0.100 default_domain = informatica.local admin_server = 192.168.0.100 } pruebas = { kdc = 192.168.0.100 default_domain = informatica admin_server = 192.168.0.100 } [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [domain_realm] .informatica = informatica .informatica.local = INFORMATICA.LOCAL [appdefaults] pam = {

ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 try_first_pass = true

}

Comprovem la configuració fent servir la comanda kinit # kinit administrador@informatica.local Password for Administrador@INFORMATICA.LOCAL: ****

Ens assegurem de que s’accepta la contrasenya (ha de ser alguna que tingui permisos administratius en el domini). Amb klist hauríem de veure un ticket vàlid pel domini INFORMATICA.CAT # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: Administrator@INFORMATICA.LOCAL Valid starting Expires Service principal 01/21/05 10:28:51 01/21/05 20:27:43 krbtgt/INFORMATICA.LOCALCOM@INFORMATICA.LOCAL renew until 08/21/08 20:28:51

Configuració de Samba Cal configurar Samba per funcionar com un member d’Active Directory incloent les opcions següents a /etc/samba/smb.conf (en negreta les més importants): [global] security = ADS netbios name = client realm = INFORMATICA.CAT

Gestió de xarxes d’àrea local password server = servidor.informatica.local workgroup = INFORMATICA log level = 1 syslog = 0 idmap uid = 10000-29999 idmap gid = 10000-29999 winbind separator = + winbind enum users = yes winbind enum groups = yes winbind use default domain = yes template homedir = /home/%D/%U template shell = /bin/bash client use spnego = yes domain master = no server string = linux client encrypt passwords = yes ##compartir el home [homes] comment = Home Directories valid users = %S browseable = No read only = No inherit acls = Yes [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700

Després d'editar l'arxiu s'ha de reiniciar el servidor i crear el directori del domini (hem especificat que tindríem els usuaris del domini a /home/INFORMATICA/usuari ) # mkdir /home/INFORMATICA # /etc/init.d/samba start

Iniciar-se en l'AD Podem entrar el sistema en l'Active Directory # net ads join -S servidor.informatica.local -U administrador Using short domain name – INFORMATICA Joined 'CLIENT' to realm 'INFORMATICA.LOCAL'

Cal tenir en compte que els dos sistemes han de tenir el rellotge configurat o donarà error Administrador's password: [2007/08/25 16:58:33, 0] libsmb/cliconnect.c:cli_session_setup_spnego(785) Kinit failed: Clock skew too great Failed to join domain!

Configuració de winbind Winbind és un dimoni que s’encarrega de fer les traduccions entre els UIDS d’Active Directory i els de Unix. Per tant com que farà falta per poder comprovar els usuaris hem d'editar el /etc/nsswitch.conf passwd: group:

files winbind files winbind

Gestió de xarxes d’àrea local shadow: hosts:

files winbind files dns winbind

I reinciem el servidor: # /etc/init.d/winbind restart

Comprovar que tot està funcionant bé Per comprovar que estem ben integrats en el domini podem fer unes consultes # net rpc testjoin Join to 'INFORMATICA' is OK # net ads info LDAP server: 192.168.0.100 LDAP server name: servidor.informatica.local Realm: INFORMATICA.LOCAL Bind Path: dc=INFORMATICA,dc=LOCAL LDAP port: 389 Server time: dom, 2 ago 2008 14:57:04 MDT KDC server: 192.168.0.100 Server time offset: 11 # net rpc info -U usuari Domain Name: INFORMATICA Domain SID: S-1-5-21-2472964809-304577640-1130498633 Sequence number: 1136 Num users: 19 Num domain groups: 11 Num local groups: 32

Comprovem que winbind està funcionant. Disposem de diverses eines per comprovar que winbind està funcionant correctament: wbinfo -u

Llista els usuaris del domini

wbinfo -g

Llista els grups del domini

getent passwd

Mostra els usuaris locals i del domini

getent group

Mostra els grups locals i del domini

Configurar l'inici des de Linux Necessitem afegir els mòduls PAM perquè els usuaris es puguin identificar en el sistema a través de winbind. Per exemple en Debian podem modificar els següents arxius: /etc/pam.d/common-account account sufficient account required

pam_winbind.so pam_unix.so try_first_pass

/etc/pam.d/common-auth auth auth

sufficient required

pam_winbind.so pam_unix.so nullok_secure try_first_pass

/etc/pam.d/common-password password password

sufficient required

pam_winbind.so pam_unix.so nullok obscure min=4 max=8 md5

Gestió de xarxes d’àrea local try_first_pass

/etc/pam.d/common-session session required session sufficient session required

pam_mkhomedir.so skel=/etc/skel/ umask=0022 pam_winbind.so pam_unix.so try_first_pass

Si estem en Ubuntu també podem necessitar donar permisos al sudo: /etc/pam.d/sudo auth sufficient pam_winbind.so auth sufficient pam_unix.so use_first_pass auth required pam_deny.so @include common-account

A partir d'això els usuaris del domini podran entrar amb el nom ( 'usuari' o bé amb 'domini+usuari' )

Gestió de xarxes d’àrea local

3.3.8.5 Fer servir Samba com a DC de Windows

Gestió de xarxes d’àrea local

3.4 Compartició d’arxius 3.4.1 Compartició en Windows: NetBIOS Per compartir impressores i / o carpetes en Windows ( en principi en les versions 95, 98, 2000, XP funciona d’una manera molt semblant cal tenir prèviament activades les opcions de compartir impressores i arxius: Prémem les propietats de la xarxa, i en la finestra resultant caldrà prémer el botó de “compartir carpetes i arxius”

Un cop haguem marcat el que ens interessa, el Windows voldrà fer allò que més li agrada fer:

Gestió de xarxes d’àrea local

Després de reiniciar, ja tindrem el nostre equip preparat per compartir impressores i arxius. Recursos compartits especials A més dels recursos compartits creats per un usuari o un administrador, el sistema crea diversos recursos compartits especials que no s’haurien de modificar o eliminar. El recurs compartit especial que es veurà més provablement és l’ADMIN$ que apareix com a C$, D$, E$, etc... Aquests recursos compartits permeten als administradors connectar-se a unitats que en altre cas no estarien compartides. Els recursos compartits especials existeixen com a part de la instal·lació del sistema operatiu. Depenent de la configuració de l’equip, estaran presents tots, o alguns dels recursos compartits especials. En principi, segons Microsoft, cap d’ells no s’hauria de modificar o eliminar. •

ADMIN$: Es fa servir durant l’administració remota d’un equip. La ruta d’accés sempre és la ubicació de la carpeta en que es va instal·lar Windows (això és l’arrel del sistema). Només els Administradors, Operadors de còpia i Operadors de servidors poden connectar-se a aquest recurs compartit.

•

Lletra_de_Unitat$: La carpeta arrel d’una unitat especificada. Només els Administradors, Operadors de còpia i Operadors de servidors poden connectar amb aquests recursos compartits en un servidor Windows 2000.

•

IPC$: Es fa servir durant l’administració remota i quan es revisen els recursos compartits. Aquest recurs compartit és essencial en la comunicació i no s’ha de canviar, modificar o eliminar.

•

NETLOGON: El fa servir el servei d’inici de sessió de xarxa d’un servidor que executa Windows NT Server quan processa els inicis de sessió en el domini. Aquest recurs només el proporcionen els servidors, no els Windows NT Workstation.

•

PRINT$: Un recurs que suporta impressores compartides

•

REPL$: Es crea en un servidor quan un client de fax està enviant un fax.

Per connectar-se a una unitat de disc no compartida en un altre equip, s’ha de fer servir la barra de direccions de qualsevol finestra i introduir-ne la direcció de la següent forma: \\nom_equip\[lletraunitat]$ Per exemple \\SERVIDOR\C$ Per connectar-se a la carpeta arrel del sistema ( la carpeta en que hem instal·lat Windows) d’un altre equip fem pràcticament el mateix: 68

Gestió de xarxes d’àrea local

\\nombre_equipo\admin$ La resta dels recursos compartits especials, com IPC$ i PRINT$ els crea i els utilitza només el sistema. NETLOGON és un recurs compartit especial en servidors Windows 2000 i NT i es fa servir per iniciar sessions en un domini. Si utilitzem la consola del sistema ( cmd ), amb “net share” podem veure quins recursos compartits té la nostra màquina: C:\Documents and Settings\user>net share Nombre Recurso Descripción ---------------------------------------------------------------------IPC$ IPC remota print$ C:\WINDOWS\System32\spool\drivers Controladores de impresora ADMIN$ C:\WINDOWS Admin remota C$ C:\ Recurso predeterminado Se ha completado el comando correctamente.

Des d’un sistema Linux també podem saber quines carpetes comparteix un sistema Windows ( si tenim Samba instal·lat ) utilitzant smbclient : $ smbclient -L pepe -R bcast -N added interface ip=192.168.168.89 bcast=192.168.168.255 nmask=255.255.255.0 Password: Domain=[DOMAIN7] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0] Sharename --------NETLOGON ADMIN$ IPC$ C$ D$ printer

Type ---Disk Disk IPC Disk Disk Printer

Comment ------Logon server share Remote Admin Remote IPC Default share Default share Epson FX-1050

Compartició de recursos amb comandes NET La comanda net serveix per diverses coses, però pel que fa a compartició de carpetes, el que ens interessa és la part de “net share” net share net share test=c:\test /remark:"Carpeta Test" /users:3 Crea una carpeta compartida en l’ordinador en el que estem anomenada “test” que està a C:\test i que com a comentari tindrà “carpeta test”. Aquesta carpeta podrà ser accedida només per 3 usuaris alhora. net share test=c:\test /users:unlimited Fa el mateix que la anterior, però sense restriccions d’accés pel que fa a número d’usuaris.

Gestió de xarxes d’àrea local net share test Ens dóna les característiques de la carpeta test net share test /delete Elimina el share test. net file També ens interessa el “net file” que serveix per veure quins arxius estan oberts a través de la xarxa. net file Dóna una llista dels arxius que estan oberts a través de la xarxa. net file 4 /close Tanca l’arxiu amb l’identificador número 4. net session Ens mostrarà qui està connectat a la nostra màquina, per desconnectar a algú només cal clicar: net session \\ipmaquinaremota /delete ej: net session \\192.168.1.20 /delete Si no posem la ip o el nom de la màquina que volem tancar, però només posem net session /delete es tancaran totes les connexions amb les altres màquines. Display a local share NET SHARE sharename Display a list of computers in the current domain. NET VIEW To see a list of shares on a remote computer NET VIEW \\ComputerName To see a list of all shares in the domain: NET VIEW /DOMAIN To see a list of shares on a different domain NET VIEW /DOMAIN:domainname To see a list of shares on a remote Netware computer NET VIEW /NETWORK:NW [\\ComputerName] Create a new local file share NET SHARE sharename=drive:path /REMARK:"text" [/CACHE:Manual | 70

Gestió de xarxes d’àrea local Automatic | No ] Limit the number of users who can connect to a share NET SHARE sharename /USERS:number /REMARK:"text" Remove any limit on the number of users who can connect to a share NET SHARE sharename /UNLIMITED /REMARK:"text" Delete a share NET SHARE {sharename | devicename | drive:path} /DELETE Delete all shares that apply to a given device NET SHARE devicename /DELETE In this case the devicename can be a printer (Lpt1) or a pathname (C:\Docs\) Join a file share (Drive MAP) NET USE [driveletter:] \\ComputerName\ShareName /PERSISTENT:YES Join a file share (Drive MAP) - Win 2K / XP NET USE [driveletter:] \\ComputerName\ShareName\folder1\folder2 /PERSISTENT:YES Join a file share (Drive MAP) - with a "long" share name NET USE [driveletter:] "\\ComputerName\ShareName" Join a password protected file share (Drive MAP) NET USE [driveletter:] \\ComputerName\ShareName[\volume] [password | *] [/USER:[domainname\]username] [/PERSISTENT:YES] In the above command /USER can also be specified as: [/USER:[dotted domain name\]username] [/USER:[username@dotted domain name] Join a file share (Drive MAP) and wait before continuing START /wait NET USE [driveletter:] \\ComputerName\ShareName Join a Printer Share NET USE [LPTx:] \\ComputerName\printer_share /PERSISTENT:YES Join a Printer Share - with a "long" share name NET USE [LPTx:] "\\ComputerName\printer_share" Connect a user to their HOME directory NET USE [devicename | *] [password | *]] [/HOME] Disconnect from a share NET USE [driveletter:] /DELETE Change the default connection type NET USE [/PERSISTENT:{YES | NO}] Display all the open shared files on a server and the lock-id

Gestió de xarxes d’àrea local NET FILE Close a shared file (disconnect other users and remove file locks) NET FILE id /CLOSE List all sessions connected to this machine NET SESSION List sessions from a given machine NET SESSION \\ComputerName Disconnect all sessions connected to this machine NET SESSION /DELETE Disconnect all sessions connected to this machine (without any prompts) NET SESSION /DELETE /y Disconnect sessions from a given machine NET SESSION \\ComputerName /DELETE

net user juanito ju4n /add --crea cuenta juanito con password "ju4n" net user juanito /del -- elimina cuenta de juanito.

Gestió de xarxes d’àrea local Recursos compartits dels usuaris Per compartir una carpeta, només hi hem de fer click amb el botó dret i triar (o “propietats” o bé “compartir” Després, només cal marcar-la com a compartida i donar-li un nom. El nom que es posa en aquesta finestra és el nom que veuran els clients quan accedeixin remotament al nostre ordinador. No té perquè coincidir amb el nom de la carpeta (en l’exemple no coincideix)

Gestió de xarxes d’àrea local Permisos dels recursos compartits Els permisos dels recursos compartits estableixen el màxim àmbit d’accés disponible. Altres assignacions de permisos (en un volum NTFS) poden ser més restrictives, però no poden expandir-se més enllà dels límits que estableix el recurs compartit. En els sistemes que tenen usuaris, es poden definir quins són els permisos que tindran els usuaris que accedeixin remotament als nostres arxius. Per fer-ho utilitzem el botó “Permisos” de la pantalla de compartir que ens mostrarà la llista d’usuaris i quins permisos tenen cada un d’ells En el nostre exemple només tenim el grup d’usuaris especial “Todos” que són tots els usuaris del sistema i tenen tots els permisos Es poden fer servir els botons “Agregar” i “Quitar” per afegir/treure usuaris o grups de la llista. Cal tenir en compte els usuaris i grups especials: Tots, SYSTEM, INTERACTIVE, NETWORK, i Usuaris autentificats. Els tipus de permisos dels recursos compartits des del menys al més restrictiu són: •

Llegir: Permet veure els noms dels arxius i subcarpetes, sempre es pot revisar i esborrar el registre de seguretat.

•

Modificar: Permet l’accés de llegir i a més permet afegir arxius i subdirectoris a la carpeta compartida, modificar la informació dels arxius i eliminar arxius i subdirectoris.

•

Control Total: Permet l’accés de Modificar, a més de permetre canviar permisos (només en volums NTFS) i prendre possessió (només en volums NTFS)

Windows 2000 Server té un conjunt de permisos estàndard que són combinacions de classes d’accés especifiques. Els permisos individuals són: Control Total, Modificar, Lectura i execució, Llistar el contingut de la carpeta, Llegir i Escriure. Cada un d’aquests permisos controla un grup de permisos especials. Permís especial Recórrer carpeta / Executar

Control total Sí

Permisos especiales para las carpetas Lectura i Llistar la Modificar execució carpeta Sí

Sí

Llegir

Escriure

Sí

Gestió de xarxes d’àrea local Llistar carpeta / Llegir dades Atributs de lectura Atributs estesos de lectura Crear arxius / Escriure dades Crear carpetes / Afegir dades Atributs d’escriptura Atributs estesos d’escriptura Eliminar arxius i subcarpetes Eliminar Permisos de lectura Canviar permisos Prendre possessió

Sí

Qualsevol usuari o grup que tingui assignat Control Total en una carpeta pot eliminar arxius i subcarpetes independentment dels permisos que tinguin els arxius o subcarpetes individuals. Els permisos per els arxius individuals s’assignen de la mateixa forma que per les carpetes. Tot i així, s’ha de recordar que per facilitar l’administració, sempre és millor: •

Concedir permisos a grups sempre que sigui possible, en comptes de a usuaris individuals

•

S’han de crear grups i assignar-los permisos d’arxius en comptes d’assignar permisos directament a grups locals.

Gestió de xarxes d’àrea local

3.4.2 Compartició de fitxers Windows-Linux: SAMBA Molt sovint els usuaris de Windows quan comencen a fer servir sistemes Unix, o Linux, volen que les coses funcionin de la mateixa forma en que ho fan quan estan al Windows. (volen que els ordinadors de la xarxa apareguin com a “Entorno de Red”, que si tenen algun ordinador en Linux els aparegui a l’”Entorno de Red” de Windows ... ) Desafortunadament, els dos sistemes venen de cultures diferents i és difícil fer-los coexistir sense mediació ... i aquesta és la funció que fa el Samba ( www.samba.org ) Samba corre en plataformes Unix, però parla als clients Windows com si la màquina tingués instal·lat un Windows. Permet que les màquines Linux apareguin en l’“Entorno de Red” sense problemes i així els usuaris Windows poden sentir-se realitzats accedint als arxius amb el seu sistema sense haver de saber que estan guardats en un Unix. Tot això es fa a través d’una pila de protocols que es coneix com “Common Internet File System”, CIFS. En el cor d’aquest protocols hi ha el Server Message Block (SMB) que és el sistema que utilitzen els Windows per compartir fitxers. El protocol CIFS no només es pot accedir a través de Windows, o Samba, molts altres sistemes operatius donen suport a CIFS ( OS/2 per exemple, també ho fa ) Samba ha estat portat a diversos sistemes operatius que no són Unix ( VMS, Amiga OS, NetWare ... ) Què és Samba? Samba consisteix en dos programes claus, més unes quantes utilitats. Els dos programes importants són: Smbd (Smb Daemon) Nmbd (Nmb Daemon) El seu objectiu és implementar les quatre bàsiques funcions del CIFS, les quals són: • Serveis de fitxers i d’impressió • Autentificació i autorització • Resolució de noms • Navegació Evidentment els més importants són el “servei de fitxers i d’impressió”. Aquests serveis estan donats per smbd. Smbd dóna també autentificació en “mode compartició” (Share mode – una contrasenya per poder accedir a la carpeta o la impressora) i en “user mode” (mode usuari – una contrasenya per identificar-te) O sigui, podem protegir els arxius compartits amb contrasenyes. El sistema de dominis de NT, permet que existeixi un ordinador que s’encarrega de l’autentificació per a cada un dels serveis de la xarxa que pertanyen a un domini NT. (Domain Controler) Les altres dues parts de CIFS, les dóna el nmbd ( browse i resolució de noms): Bàsicament manejament i distribució de noms NetBIOS.

Gestió de xarxes d’àrea local netbios-ns netbios-dgm netbios-ssn microsoft-ds

137/udp 138/udp 139/tcp 445/tcp

#NETBIOS Name Service #NETBIOS Datagram Service #NETBIOS Session Service #Direct-Hosted Service

Samba porta diverses utilitats. Les utilitats més corrents són : smbclient Un client de SMB simple, amb un interfície similar al FTP. Pot ser utilitzat des d’un sistema Unix per connectar amb una compartició SMB, transferir-hi fitxers i enviar fitxers a impressores remotes. nmblookup Un servei de noms NetBIOS. Es pot fer servir per trobar noms de NetBIOS en una xarxa, buscar les seves adreces IP, i per preguntar a una màquina remota per la llista de noms que conté. swat Samba Web Administration Tool. Swat permet configurar Samba a través d’un navegador web. testparm Un dels problemes més corrents és tenir mal configurat el samba. Per verificar que tot està correctament, es dóna un programa que permet comprovar-lo. $ /bin/tesparm /etc/smb.conf Evidentment n’hi ha més, però per explicar-los caldria concentrar-se més en el funcionament del CIFS, SMB i Samba. findsmb

- list info about machines that respond to SMB name queries on a

subnet make_unicodemap - construct a unicode map file for Samba make_smbcodepage - construct a codepage file for Samba rpcclient - Tool for executing client side MS-RPC functions smbcacls - Set or get ACLs on an NT file or directory names smbcontrol - Send messages to smbd, nmbd or winbindd processes smbmnt - Helper utility for mounting SMB filesystems smbmount - Mount an smbfs filesystem smbpasswd - Change or create a user's SMB password smbspool - Send a print file to an SMB printer smbstatus - Report on current Samba connections smbtar - Shell script for backing up SMB/CIFS shares directly to UNIX

tape

drives testprns - Check printer name for validity with smbd wbinfo - Query information from winbind daemon winbindd - Name Service Switch daemon for resolving

names from NT servers

La configuració dels serveis samba es fa en l’arxiu smb.conf que normalment està en /etc/smb.conf o a /etc/samba/smb.conf La configuració d’aquest arxiu es fa d’una forma semblant a la dels arxius *.INI de Windows.

Gestió de xarxes d’àrea local Per compartir carpetes del servidor Linux i que aquestes estiguin accessibles des dels Windows hem de definir-ho en l’arxiu smb.conf creant una nova secció (en qualsevol lloc, però sol posar-se al final). Això, per exemple, definirà una carpeta compartida, que els usuaris Windows veuran amb el nom “public”, que serà accessible per tothom. [public] path = /home/public public = yes only guest = yes writable = yes printable = no

En canvi per connectar-se a ordinadors Windows, cal muntar les carpetes compartides o fer servir la utilitat smbclient: $ smbclient -L Servidor

L’exemple anterior ens ensenyarà quines són les carpetes compartides de l’ordinador “Servidor” La següent finestra ens mostra com accedir a la carpeta compartida del “Servidor” a través de Linux ( smbclient ) i de Windows ( net use ) sense utilitzar cap entorn gràfic. $ smbclient //Servidor/tmp C:\> net use x: \\Servidor\tmp

En Linux també podem muntar la carpeta per poder-hi accedir de forma local, com si fos un directori més (simplement cd /mnt/disk): $ mount //[CLIENT]/[DIRECTORY] -t smbfs /mnt/disk

Això ho podem fer permanent, definint-ho a el fitxer de dispositius que es munten automàticament al iniciar l’ordinador: /etc/fstab //[CLIENT]/[SHARE] [MOUNT POINT] smbfs password=[PASSWORD],gid=[GID]

Gestió de xarxes d’àrea local

3.4.3 Compartició de fitxers Unix: NFS ●

RFS (Remote File System): Va ser definit per AT&T pel System V (Unix). Quasi tots els Unix el tenen, però no es fa servir perquè té greus problemes de seguretat

●

AFS (Andrew File System): Té moltes millores, especialment en entorns WAN.

●

NFS (Network File System): NFS va ser definit per Sun Microsystems per donar suport als equips sense disc. Està preparat per funcionar en entorns de LAN i està implementat en tots els entorns Unix i fins i tot en altres sistemes operatius (MacIntosh)

3.4.3.1 NFS en Linux Els paquets necessaris varien en funció de la distribució que tinguem però bàsicament són el portmap i el servidor que s'anomena de forma diferent en les paquets (nfs-server, nfs o nfs-kernel-server..). En l'exemple ens concentrem en Mandriva. La idea del NFS és bastant simple. En un servidor nosaltres hi posem un directori amb les carpetes que volem compartir als clients ( /etc/exports ) En l’arxiu exports hi posem les línies de la forma: Directori_que_compartirem subxarxa_que_hi_accedirà (Opcions)

Les opcions més corrents seran les següents: ro rw secure insecure async sync

La carpeta compartida només es pot llegir. No es pot escriure Es pot escriure a la carpeta compartida Requereix que la petició original estigui en un port inferior a 1024. Aquesta és una opció per defecte El contrari de l’anterior Envia confirmacions abans de que totes les dades estiguin escrites. Això fa que tot vagi més ràpid, però si el servidor s’apaga es podrien donar pèrdues de dades. El contrari de l’anterior

N’hi ha moltes més, per veure-les consulteu la pàgina man. Per exemple per compartir la carpeta /home/xavier, afegim a l’arxiu exports el següent: /home/xavier

192.168.0.0/24(rw)

A més de quina és la carpeta que estem compartint, li diem altres coses: Estem compartint la carpeta en mode escriure i llegir (  ho veiem pel rw ) i només permetem connexions a les carpetes compartides als ordinadors amb adreces de xarxa 192.168.0.0 Cal tenir en compte que cal reiniciar els servidors un cop s'ha editat el fitxer de configuració. En algunes distribucions es pot fer servir “exportfs -a” per refrescar la informació del que es comparteix

Gestió de xarxes d’àrea local El client per poder llegir les carpetes les ha de muntar, és a dir executar la comanda mount per incorporar aquestes carpetes a l’arbre de directoris. mount –t nfs –o rw 192.168.0.101:/home/xavier /mnt/prova

Això farà que el client pugui accedir a la carpeta /home/xavier del servidor com si estès en el propi ordinador a /mnt/prova. (Es poden posar diferents opcions, consulteu el man) Cal observar que en aquest muntatge fem servir el tipus de fitxer “nfs” i no el sistema de fitxers del servidor. També es pot fer que una unitat nfs es munti automàticament quan s'inicia el sistema afegint la línia a /etc/fstab ... 192.168.0.101:/home/xavier /mnt/prova nfs rw,defaults 0 0

Problemes? Essencialment això és tot, és realment simple, però a la pràctica cal tenir en compte diverses coses que fan que ens trobem amb problemes: • • • •

Cal que el servidor tingui un dimoni NFS, i el Portmap engegats Cal vegilar amb els UIDs d’usuaris perquè sinó ens podem trobar que no podem llegir la carpeta Els firewalls solen ser molt hostils al NFS Problemes amb els DNS fan que a vegades les connexions fallin

Guia de resolució de problemes: Problema Si no es pot muntar la carpeta en el client Es munta bé, però no es pot accedir a les dades Tarda mont en muntar, es monta molt a poc a poc, o falla a vegades idem

Causa Segurament no estan engegats el dimoni de portmap o el de nfs Problemes amb els permisos, amb els uids o gids Problemes amb els firewalls o amb els filtres de paquets El DNS del servidor està malament

Comprovar que els dimonis de nfs i portmat estan engegats: Perquè el servei nfs funcioni cal que els dos dimonis estiguin en marxa, per comprovarho fem servir la utilitat chkconfig: [root@servidor]# chkconfig --list portmap portmap 0: off 1:off 2:off 3:on 4:on 5:on 6:off Això de dalt significa que els runlevels 3,4 i 5 executaran cada vegada el dimoni portmap. Si no estessin en on es s’hi poden posar amb: [root@servidor]# chkconfig portmap on

Gestió de xarxes d’àrea local Podem comprovar que realment s’està executant en aquest moment mirant el resultat de ps: [root@servidor]# ps ax | grep portmap 3171 ? S 0:00 portmap 4251 pts/0 S 0:00 grep portmap El mateix ho hem de fer amb el dimoni NFS: [root@servidor]# chkconfig --list nfs nfs 0: off 1:off 2:off 3:on 4:on 5:on 6:off [root@servidor]# ps ax | grep nfs 3192 ? S 0:00 nfs 4251 pts/0 S 0:00 grep portmap Segons la distribució, pot ser que es trobin diversos dimonis nfs, això és correcte. Podem reiniciar-los per estar segurs que agafin els nostres canvis, en cas de que n'hagem fet algun. Cal vigilar que s’iniciï primer el portmap [root@servidor] service portmap restart [root@servidor] service nfs restart Cada vegada que es canviï el /etc/exports, s’han de reiniciar els dimonis per tal que agafin la nova configuració. Problema dels uid’s Cada usuari d’un sistema Unix està associat a un número ( el root sempre és el 0, però cada vegada que es dóna d’alta un usuari, el sistema li assigna un número (que anomenem uid) i un grup (que anomenem guid). Podeu veure quin és l’uid de cada usuari i el grup en l’arxiu /etc/passwd: [usuari@server] cat /etc/passwd pere:x:501:501:Pere Gallerí:/home/pere:/bin/bash amadeu:x:502:501:Amadeu Garcia:/home/amadeu:/bin/bash L’uid d’usuari és el primer número i el del grup és el segon

Tot i que per als usuaris és més fàcil de recordar el nom de l’usuari i el grup en llenguatge natural, internament el Linux el que fa és fer servir els números. Per això ens podem trobar que tot i que per nosaltres el usuari es digui igual a totes dues màquines, per a el unix, són usuaris diferents. [usuari@server] cat /etc/passwd pere:x:501:501:Pere Gallerí:/home/pere:/bin/bash amadeu:x:502:501:Amadeu Garcia:/home/amadeu:/bin/bash [usuari@client] cat /etc/passwd .. amadeu:x:502:502:Amadeu Garcia:/home/amadeu:/bin/bash pere:x:508:508:Pere Gallerí:/home/pere:/bin/bash 81

Gestió de xarxes d’àrea local

En aquest exemple, l’usuari amadeu no tindria problemes perquè té els mateixos números en les dues màquines, però l’usuari pere podria tenir-ne.

Per solucionar aquest problema hi ha molts procediments: -

Crear un grup especial per compartir Mirar de que totes les màquines de la xarxa tinguin els mateixos uid (a través de LDAP per exemple).

Problemes amb els firewalls i dns Molts problemes dels que es culpa als NFS són en realitat culpa dels firewalls. Per fer que el NFS funcioni correctament cal que el firewall tingui habilitat el següent: -

Paquets ICMP tipus 3 Port 111 obert (Pel dimoni portmap) Port 2049 obert (Pel dimoni nfs) Obrir el port assignat al dimoni mountd

Si encara hi ha problemes, poden ser deguts al DNS, consulteu el /etc/resolv.conf per veure que tot està correctament.

Gestió de xarxes d’àrea local

3.5 Compartició d’impressores 3.5.1 Compartir impressores en Windows NetBIOS

Gestió de xarxes d’àrea local

3.5.2 Compartir impressores en Linux 3.5.2.1 Impressió des de la línia de comandes Independentment del sistema d’impressió que fem servir, en Linux disposem d’una sèrie de comandes que ens permeten controlar la impressora des de fora de l’entorn gràfic. De totes formes no cal oblidar que qualsevol UNIX tindrà un entorn gràfic per gestionar les impressores. El que veurem és com es pot fer per configurar i gestionar les impressores des de l’entorn de comandes. Molta gent prefereix els entorns gràfics quan treballen amb sistemes operatius que no coneixen perfectament i perquè és més senzill, però a mesura que es coneix el sistema es pot descobrir que les comandes ens donen un control molt més precís i ràpid d’allò que volem fer.

3.5.2.2 CUPS Moltes distribucions de Linux han adoptat un nou estàndard d’impressió, CUPS (Common UNIX Printer System). Aquesta és la primera actualització del món d’impressió de UNIX en molts anys i entre altres coses permet: • • • •

Suport natiu per IPP, Internet Printing Protocol Suport natiu per impressores Windows Capacitat d’explorar impressores per la xarxa Suport per PPD, PostScript Printer Definitions

Les anteriors versions del sistema d’impressió de Unix estaven basades en línies d’impressió, les antigues impressores d’impacte que només imprimien text en el paper. CUPS permet molta més funcionalitat i dóna suport per moltes impressores. També permet algunes capacitats gràfiques que no eren suportades anteriorment. Comandes d’impressió de Linux En Linux hi ha moltes comandes d’impressió diferents per poder imprimir des de la línea de comandes. Moltes són permeses per als usuaris normals, però també n’hi ha que només poden ser executades pel root. • • • • • • • • • •

/usr/bin/lp - Enviar treballs d’impressió /usr/bin/lp.cups - Enviar treballs d’impressió /usr/bin/lpoptions - Gets and sets printer options for a single user when run by a user or for the system when used by root /usr/bin/lppasswd - Changes printing passwords for an individual user or adds, deletes, and changes printer users and passwords when run by root /usr/bin/lpq - Shows the status of a printer queue /usr/bin/lpq.cups - Shows the status of a printer queue /usr/bin/lpr - Used to submit print jobs /usr/bin/lpr.cups - Used to submit print jobs, forcing use of CUPS /usr/bin/lprm - Used to remove print jobs from a queue /usr/bin/lprm.cups - Used to remove print jobs from a queue

Gestió de xarxes d’àrea local • • • • • • • • • • •

/usr/bin/lpstat - Gives status of the CUPS system, such as queue lengths and printers /usr/bin/lpstat.cups - Gives status of the CUPS system, such as queue lengths and printers /usr/bin/cancel - Cancels a print job /usr/bin/enable - Enables a print queue or class of printers, requires a management password /usr/bin/disable - Disables a print queue or class of printers, requires a management password /usr/sbin/lpadmin - Manages printers and classes, requires a management password /usr/sbin/lpc - A compatibility program for Berkley style printers, limited to queue status in CUPS /usr/sbin/lpc.cups - A compatibility program for Berkley style printers, limited to queue status in CUPS /usr/sbin/lpdomatic - A filter script provided to be used in setting up printers /usr/sbin/lpinfo - Shows available printer devices and drivers on the system /usr/sbin/lpmove - Moves the jobs destined for a queue to another queue

Les comandes següents només les pot executar l'usuari 'root': ● ● ●

/usr/bin/lprsetup.sh – script per configurar la impressió /usr/sbin/accept – Fa que la cua d'impressió accepti peticions /usr/sbin/reject – Fa que la cua d'impressió rebutji peticions

Les comandes que tenen la extensió .cups solen ser del sistema d'impressió CUPS. La majoria de les comandes que no són de CUPS solen ser enllaços simbòlics. Que en el cas de que tinguem CUPS configurat pot ser que apuntin a els anteriors. Configurar una impressora Per configurar una impressora necessitem tenir permisos de root. I després caldrà que sapiguem quines són les impressores del sistema i en quin estat es troben: # lpstat -t

Si no n'hi ha cap, el que sortirà serà alguna cosa com: Scheduler is running no system default destination

Com la majoria de les utilitats, lpstat té moltes possibilitats que ens permeten refinar l'estat. • • • • • •

-a [printer name(s)] - Report the acceptance status of the printers -c [class name(s)] - Report the printers in the class(s) -l - Long listing of printers, classes, and jobs -r - Tells if the scheduler is running -h <server name> - Connect to the CUPS <server name> -s - Summary of all printers, classes, and associated devices

lpadmin

Gestió de xarxes d’àrea local Un cop hem confirmat que l'scheduler està en execució i que tenim dispositiu disponible, el següent pas és afegir la impressora amb lpadmin. Lpadmin permet afegir la impressora al sistema amb totes les característiques: # lpadmin -p Impressora -m laserjet.ppd -v parallel -D “LaserJet V” -L “Office 502”

Les opcions que hem fet servir són: • -p : Nom de la impressora • -m: Especificació PostScript de la impressora • -v: El dispositiu de sortida • -D: Descripció en text de la impressora. • -L: Descripció del lloc on és la impressora. Si tot ha anat bé, no sortirà res per pantalla. Si alguna cosa no va bé sortirà l'error. Podem comprovar si ha anat bé amb lptstat. Normalment el que veurem és que no està activada, o sigui que necessitarem activar-la i dir-li que accepti treballs: # enable Impressora # accept Impressora

Amb lpstat -a -p Impressora veurem en quin estat es troba. Ara podem enviar treballs a la impressora amb la comanda lpr: # lpr -P Impressora -#2/home/usuari/fitxer

Gestió de xarxes d’àrea local

3.5.3 CUPS Cups significa “Common Unix Printing System” És un sistema d’impressió universal per sistemes Unix que ve a solucionar el problema de les impressions en xarxes heterogènies. Una de les característiques que té és que es pot gestionar directament a través de l’entorn web ( http://localhost:631 ) Com que permet la impressió des de xarxes heterogènies permet que els usuaris des dels sistemes Windows puguin imprimir en impressores unides a un Unix. •

Win95, Win98, Win Millenium  S’hi pot imprimir, però fa falta tenir instal·lat Samba

•

Win2K, WinXP  Podem imprimir amb el protocol IPP (que ja ve en Windows)

També permet utilitzar drivers Postscript directament, sense haver de fer cap mena de conversió. Configuració de CUPS La majoria de distribucions de Linux tenen un programa per configurar CUPS de forma senzilla, i això fa que sigui difícil fer una explicació genèrica. Per aquest motiu veurem com fer una configuració manual. 1. Comprovar que tenim els paquets necessaris instal·lats Pel CUPS generalment seran els paquets libcups i *cupsys * També calen tenir la col·lecció de drivers de foomatic. * Si tenim una impressora HP, els drivers hpijs fets pel fabricant, en principi seran els que funcionaran millor. * El paquet gimp-print són drivers lliures de diverses impressores. * El paquet de drivers Omni són drivers creats per IBM Els drivers d’impressió en Linux són filtres que converteixen la entrada, normalment Postscript, en un format que la impressora entengui. 2. Carregar el mòdul de control de la impressora Si tenim la impressora connectada al port paral·lel: # modprobe lp

Si està connectada al port USB # modprobe printer

( Per versións del nucli 2.4.x )

# modprobe usblp

(Per versions del nucli 2.6.x)

3. S’ha de buscar el fitxer PPD de la impressora Moltes vegades aquest fitxer ve en el CD de la impressora, però per si no fos així, podem anar a http://www.linuxprinting.org i amb el model de la impressora descarregar-lo.

Gestió de xarxes d’àrea local Els arxius PPD són arxius en que hi ha informació sobre les característiques específiques de funcionament de la impressora. Això fa que el sistema sàpiga quines coses pot fer la impressora i com les pot fer.

L’arxiu descarregat normalment s’ha de posar dins del directori /usr/share/cups/model/ 4. Comprovar que funciona La instal·lació ja està acabada, per comprovar que tot funciona correctament amb un navegador anem a http://localhost:631 per veure si funciona.

L’idioma en que ens sortirà la pantalla dependrà de la configuració del sistema host.

Gestió de xarxes d’àrea local Anem a “Do Administration Tasks” i ens demanarà usuari i contrassenya. Si no hem entrat mai, és root / root 5. Afegir una impressora Cliquem a “Add Printer” i omplim el que ens va demanant ( nom de la impressora, on està connectada, fabricant, driver que volem fer servir, ... ) Al final ens dirà que tot ha anat bé “Success” 6. Comprovar el funcionament de la impressora Des de “Manage Printers”, entre altres coses, podem fer pàgines de prova

3.5.3.1.1 CUPS i Windows 9x Per fer servir la impressora amb Windows 9x ens cal tenir instal·lat i configurat Samba en l’ordinador. Editem l’arxiu /etc/samba/smb.conf Anem a la secció [global] i cal afegir o canviar: [global] ... printing=cups printcap name=cups load printers=yes ... Després cal deixar la secció [printers] com la següent:

Gestió de xarxes d’àrea local

[printers] Comment=Impressores path=/var/spool/samba browseable=no public=yes guest ok=yes writeable=no printable=yes printer admin=root És bastant provable que tinguem una línia que diu “invalid users=root”, si hi és cal eliminar-la. A la secció [print$] afegim (si la secció no hi és la afegirem): [printers] comment=Printer drivers path=/etc/samba/drivers browseable=yes guest ok=yes read only=yes write list=root Deixem la edició i executem # cupsaddsmb -a Per defecte CUPS només accepta dades RAW, i després les formata abans d’imprimir, això té un problema amb Windows, perquè Windows les formata abans d’enviar-les. Hem d’editar les característiques MIME de cupsd que estan als arxius /etc/cups/mime.convs i /etc/cups/mime.types Dintre /etc/cups/mime.convs cal buscar dues línies com les següents i eliminar el símbol de comentari ( # ) que hi ha # application/octet stream application/vnd.cups –raw o En el /etc/cups/mime.types cal buscar la línia # application/octet stream i treure-li el comentari. Després tornem a posar la línia “invalid users=root” a /etc/samba/smb.conf i reiniciem CUPS i Samba. Ja només ens queda anar al Windows i configurar la impressora.

Gestió de xarxes d’àrea local

3.5.3.1.1 CUPS i Windows 2000, XP o Vista Microsoft en les seves darreres versions ja inclou un driver IPP en els seus sistemes operatius, de manera que es pot imprimir directament en CUPS. Utilitzem l’assistent per afegir una impressora i només hem d’especificar que volem una impressora que està a Internet o a la xarxa local. En Windows XP el quadre posem l’adreça en que trobarà la impressora que volem afegir al sistema http://Minerva:631/printers/HPLASER Minerva és el servidor Unix que té la impressora HPLASER és el nom que hem donat a la impressora

La configuració en Windows 2000 serà semblant, però Windows 2000 té un bug en el IPP que fa que no funcioni bé. Per solucionar-ho hem de fer servir classes per imprimir. Així doncs amb el CUPS hem de crear una classe nova. Entrem des de l’entorn web, “Do Administration Tasks” i “Add Class”. En el quadre de definició d’impressores de Windows hi posem l’adreça http://Minerva:631/classes/CLASSE Minerva és el servidor Unix que té la impressora CLASSE és el nom que hem donat a la classe

En principi amb això ja n’hauríem de tenir prou, però cal fer un parell de passes més: 1.

El Windows no ens trobarà el servidor Minerva i si intentem fer-ho amb la seva adreça IP ens dirà que no vol adreces IP en el nom. Per solucionar això ens cal definir el host a Windows. El CUPS per seguretat no deixa que ningú s’hi connecti, ens caldrà obrir les connexions a la nostra xarxa local

1. Definir el Host al Windows XP

Gestió de xarxes d’àrea local Per solucionar això hem d’afegir el servidor a l’arxiu hosts que està en la carpeta C:\ WINDOWS\SYSTEM32\DRIVERS\ETC (en Vista no cal)

2. Obrir les connexions al CUPS Per defecte la configuració per defecte de CUPS no deixa que ningú s’hi connecti, només la màquina local, per tant, ens cal obrir la porta a possibles connexions: Editar l’arxiu /etc/cups/cupsd.conf i buscar: <Location /> Order Deny, Allow Deny From All Allow From 127.0.0.1 </Location >

I si volem donar accés a la xarxa local, afegir-hi la línia Allow From 192.168.0.*

Hem d’editar les característiques MIME de cupsd que estan als arxius /etc/cups/mime.convs i /etc/cups/mime.types Dintre /etc/cups/mime.convs cal buscar dues línies com les següents i eliminar el símbol de comentari ( # ) que hi ha # application/octet stream application/vnd.cups –raw o -

En el /etc/cups/mime.types cal buscar la línia # application/octet stream

i treure-li el comentari. Reiniciar CUPS i el Windows ja podrà imprimir.

Gestió de xarxes d’àrea local

3.6 Servidors per administració remota 3.6.1 Telnet El servei de Telnet està pràcticament abandonat per culpa dels problemes de seguretat que té el protocol. Tot i així encara ens podem trobar amb llocs que el fan servir. La instal·lació del servidor de telnet és relativament senzilla tant en sistemes Linux com en Windows. En Linux després de instal·lar el paquet del servidor (normalment anomenat telnetd) hem de revisar la configuració de inetd o xinetd per comprovar que s'adiu a les nostres necessitats. En Windows el servidor de telnet està com un servei més, deshabilitat per defecte, i si ens fa falta només hem d'activar-lo. Sempre que es faci servir el servidor de telnet s'ha d'anar amb molt de compte i configurar les mesures de seguretat adequades per evitar problemes. És altament perillós activar un servidor de telnet que accepti connexions a través d'Internet

3.6.1.1 Client de Telnet Al client de telnet se li han trobat altres utilitats a part de la connexió a servidors de telnet que segurament són molt més utilitzades actualment que la funció original. L'ús més important que es dóna al client de telnet actualment és per treballar amb sessions interactives contra servidors d'altres coses: Per exemple per l'enviament de correus electrònics, o per recollir informació sobre un servidor web, etc.. $ telnet 192.168.0.140 25 Trying 192.168.0.2... Connected to 192.168.0.2. Escape character is '^]'. GET / <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html dir="ltr"> <head> ...

3.6.2 SSH 3.6.2.1 Instal·lació d'un servidor Per defecte en gairebé qualsevol distribució es creen fitxers de configuració per defecte, però és recomanable fer-hi un cop d'ull per des d'un punt de vista comprovar: –

Quin protocol fem servir. Sempre que sigui possible es recomana fer servir només la versió 2 del protocol

Gestió de xarxes d’àrea local –

Des d'un punt de vista de la seguretat ens hauríem de plantejar si deixem que els usuaris entrin amb usuari+contrasenya o bé només els deixem entrar a partir de clau pública+clau privada

–

Millor que l'usuari root no pugui entrar mai, però sempre depenem de les necessitats del lloc en que l'estem implantant.

–

Permetem la execució de programes d'entorn gràfic?

Mai hem de deixar la configuració per defecte i sempre hem de modificar el fitxer de configuració per adaptar-lo a les nostres necessitatts. Un exemple de fitxer de configuració del servidor podria ser: (/etc/ssh/sshd_config) Port 22 # Només permetrem l'entrada pel protocol 2 Protocol 2 ListenAddress x.x.x.x HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 60 KeyRegenerationInterval 3600 # Denegar el permís d'entrada remot al root PermitRootLogin no IgnoreRhosts yes IgnoreUserKnownHosts yes StrictModes yes X11Forwarding no X11DisplayOffset 10 PrintMotd yes KeepAlive yes SyslogFacility AUTHPRIV LogLevel INFO RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication no PasswordAuthentication yes PermitEmptyPassowrds no # Usuaris que poden entrar AllowUsers sysadmin AllowUsers xavier UsePrivilegeSeparation yes Subsystem sftp /usr/libexec/openssh/sftp-server

En aquesta configuració, indiquem que només s'utilitza el protocol SSHv2, la interfície (indicada per l'adreça IP) associada al servidor, la ubicació de les claus del servidor, la mida de la clau i l'auto-regeneració automàtica de la mateixa, ignorar els fitxers rhosts i shosts, els tipus d'autenticació que es permeten (com hem configurat el servidor perquè només utilitzi SSHv2, no permetem la utilització de claus RSA per a l'autenticació) , etc. També pot ser interessant evitar que es puguin fer connexions des de màquines “estranyes”. Això es pot fer molt facilment via tcp wrappers $ joe /etc/hosts.allow # Només permetre connexions locals sshd : localhost sshd : 10. 192.168. sshd : .mydomain.com .mydomain.net

Gestió de xarxes d’àrea local I denegar els altres intents de connexió i a més registrar-los en el fitxer de logs $ joe /etc/hosts.deny # Denegar-ho tot per defecte i registrar-ho ALL : ALL : severity auth.info

També s'ha de revisar el fitxer de configuració de client (/etc/ssh/ssh_config) Host * ForwardAggent no ForwardX11 no RhostsAuthentication no RhostsRSAAuthentication no RSAAuthentication no PasswordAuthentication yes FallBackToRsh no UseRsh no BatchMode no CheckHostIP yes StrictHostKeyChecking yes IdentityFile ~/.ssh/identity IdentityFile ~/.ssh/id_dsa IdentityFile ~/.ssh/id_rsa Port 22 Protocol 2 Cipher blowfish EscapeChar ~ Host x.x.x.x # Opcions específiques per a un # servidor SSH concret

En aquest fitxer de configuració s'activen les característiques generals de seguretat del client SSH per a realitzar únicament connexions amb protocol SSHv2, permetent l'autenticació mitjançant contrasenyes. Igualment es deshabiliten expressament algunes opcions que poden provocar forats en la seguretat, com la possibilitat d'utilitzar rsh si no és possible establir una connexió SSH. Addicionalment, en funció de la versió del sistema operatiu que s'utilitzin hi ha d'altres arxius que pot ser necessari configurar, tals com la configuració del suport PAM de l'OpenSSH (habitualment, /etc/pam.d/sshd) i l'script per a executar sshd automàticament cada vegada que arrenca el sistema.

3.6.2.2 Client ssh El client de ssh ens serveix per treballar contra servidors ssh de forma segura (la informació anirà xifrada) però a més ens serveix per altres coses com crear túnels xifrats per altres aplicacions, etc.. Podem treballar amb el client ssh interactivament a partir de usuari i contrasenya com si es tractés d'un telnet normal $ ssh usuari@192.168.0.2 The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established. RSA key fingerprint is f2:99:d8:9d:b7:dc:1d:91:32:02:cb:eb:b9:2c:d6:96. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.0.2' (RSA) to the list of known

Gestió de xarxes d’àrea local hosts. usuari@192.168.0.2's password: Last login: Wed Feb 20 19:58:55 2008 from 192.168.0.151 $

I d'aquesta forma podrem treballar amb una consola remota. O bé ho podem fer a partir de clau pública / privada de manera que no farem servir les contrasenyes d'accés als equips sinó que la verificació es farà a través de clau pública. Per això necessitem crear la clau del client (podem crear claus rsa i dsa): $ ssh-keygen -t dsa Generating public/private rsa key pair. Enter file in which to save the key (/home/pepet/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/pepet/.ssh/id_rsa. Your public key has been saved in /home/pepet/.ssh/id_rsa.pub. The key fingerprint is: fa:a3:f3:52:ad:2a:bc:fc:f1:a4:96:b4:5e:6c:5b:c4 pepet@superman

I després hem d'enviar la nostra clau pública al servidor. En el nostre directori local (generalment ~/.ssh hi trobarem les claus i el fitxer known_hosts que porta el registre del fingerprint del servidor i en cas de que canviï ens informarà de que pot ser que s'hagi produït un problema): $ cd .ssh/ $ ls id_dsa id_dsa.pub known_hosts $ ssh-copy-id -i id_dsa.pub usuari@192.168.0.2 usuari@192.168.0.2's password: Now try logging into the machine, with "ssh 'usuari@192.168.0.2'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.

Un cop fet això podrem entrar directament en el servidor sense que se'ns torni a demanar la clau d'usuari mai més $ ssh usuari@192.168.0.2 Last login: Mon Feb 25 18:17:47 2008 from 192.168.0.206 $

Hi ha la possibilitat de que el servidor només permeti accedir a aquells que tinguin la seva clau en el sistema. Si passa això el ssh-copy-id fallarà. L'alternativa és portar la clau pública al servidor i afegir-la a mà en el fitxer 'authorized_keys' o 'authorized_keys2' (si només permetem la versió 2 del ssh) $ ssh usuari@192.168.0.2 Last login: Mon Feb 25 18:17:47 2008 from 192.168.0.206 $

Gestió de xarxes d’àrea local Execució de programes remotament Podem fer servir el client de ssh per executar un programa en la màquina client només afegint-lo al darrera del programa. $ ssh usuari@192.168.0.2 uname Linux

Si el programa és gràfic en tenim prou amb afegir -X $ ssh usuari@192.168.0.2 -X xclock

3.6.2.2.1 dsh un client ssh distribuït També disposem d'una consola que ens permet executar comandes en diversos servidors alhora. El dsh 'Dancer's shell' $ apt-get install dsh

Aquest client ens permetrà executar la mateixa comanda en diferents ordinadors sense haver d'entrar-hi cada vegada. Les màquines han d'estar configurades a ~/.ssh/machines.list o a /etc/machines.list Host Federicu Hostname 192.168.0.2 user pepet IdentyFile ~/.ssh/id_dsa Port 22 Host Marcelinu Hostname 192.168.0.5 user pepeta IdentyFile ~/.ssh/id_dsa Port 22

I definim els grups a $ ~/.dsh/group/nom. Per exemple el /etc/dsh/group/servers podria ser: 192.168.0.1 192.168.0.2 192.168.0.3 Amb dsh podrem executar la mateixa comanda en les dues màquines que tenim configurades: $ dsh -a 'uname'

En màquines específiques: $ dsh -m Federicu -m Marcelinu 'uname'

O treballar a partir de les que pertanyen a un grup (i amb -M per veure resultats detallats)

Gestió de xarxes d’àrea local $ dsh -M -g servers 'uname'

Té el problema que no permet sessions interactives però és d'una gran utilitat pels administradors. Per exemple per instal·lar un programa a tots els servidors de cop: $ dsh -g grup 'apt-get install joe'

També podem fer que faci els hosts un per un afegint la opció -w

3.6.2.2.1 Clients gràfics Putty Konqueror

Gestió de xarxes d’àrea local

3.6.3 Administració remota gràfica Amb el progrés dels sistemes operatius moderns, ens podem trobar amb la necessitat d'haver d'accedir a un escriptori gràfic remot per fer-hi tasques d'administració. Per això també disposem de diferents alternatives. Només en veurem dues però n'hi ha moltes més

3.6.3.1 VNC VNC són les sigles de Virtual Network Computing i es tracta d'un programa de programari lliure basat en una estructura client – servidor que ens permet controlar l'escriptori gràfic de l'ordinador remot a través d'un programa client. Es tracta d'un programa que permet tenir independència del sistema operatiu que facin servir tant el client com el servidor: Es pot compartir la pantalla de qualsevol sistema operatiu des de qualsevol altre sistema operatiu sempre que en tinguem un client. Es pot fer servir per múltiples funcions: Mostrar a un usuari inexpert com funciona un programa o mostrar com es realitza una tasca a múltiples clients diferents. Els components del sistema són 3: –

Un servidor: Que serà l'encarregat d'enviar la pantalla als clients. Un cop ha enviat la primera part després només ha d'enviar la part gràfica que canvia. En Unix el servidor VNC és l'Xvnc que permet fer dues coses: Treballar-hi com si fos una pantalla X normal o fer-lo servir per veure l'escriptori d'un altre usuari. Això vol dir que en Unix no tenim perquè veure necessàriament l'escriptori que està veient l'usuari que es troba davant de l'ordinador. En Windows VNC només permet compartir l'escriptori actual però en sistemes X Window es poden crear més pantalles virtuals. Per això si creem un servidor nou es compartirà un escriptori diferent de l'actual :1 o :2 però si volem compartir l'escriptori actual executem: $ x0rfbserver

O si estem en KDE podem fer: $ krfb

Amb alguns servidors hi ha la possibilitat de configurar el programa servidor com a servidor d'HTTP de manera que es podrà mostrar la pantalla compartida en un navegador que tingui suport Java i d'aquesta forma el client no ha d'instal·lar res ja que se li descarregarà el navegador automàticament. –

Un client: Que s'encarregarà de mostrar per pantalla la informació que rebi del servidor.

–

Un protocol de comunicacions (RFB) que és molt senzill i està basada en l'enviament de primitives gràfiques del servidor al client (“Envia un rectangle de

Gestió de xarxes d’àrea local pixels a la posició X,Y” i missatges d'events del client al servidor. El servidor envia petits rectangles del buffer de pantalla del client. Això fa que en la seva versió més senzilla aquest protocol faci servir molt d'ample de banda i s'han implementat diversos mètodes per reduir-ne aquest problema (a través de codificacions per incrementar l'eficiència i permetre que el client i el servidor negociïn el protocol abans de funcionar. Per defecte el protocol no és segur perquè que encara que les contrasenyes no s'envien en text planer es pot fer servir un sistema de força bruta un cop s'ha capturat la contrasenya amb un sniffer. Per això molts dels seus derivats han afegit xifrat en les seves implementacions. Al ser de codi obert i com que se'n permetia la modificació, actualment a part de l'orginal, VNC, existeixen una gran quantitat de versions d'aquest programa: TightVNC, RealVNC, UltraVNC, Bozteck VNC, ... Algun d'ells ofereix característiques extres com xifrat o transferència de fitxers, etc..

3.6.3.1.1 Instal·lació en Unix

100

Gestió de xarxes d’àrea local

3.6.3.2 NX Normalment per administrar remotament el server n'hi ha prou amb la consola però algun cop, normalment per treballar amb alguns programes gràfics amb els que no se'n pot veure l'estat des de consola, cal alguna forma d'accedir gràficament de forma remota a l'escriptori. La opció anterior, el VNC, té alguns problemes: • •

La seguretat: El xifrat de els contrasenyes de VNC és poc segur. I crear túnels SSH cada vegada és un rotllo La velocitat: El seu funcionament no és gaire ràpid. Especialment amb connexions lentes.

NX està desenvolupat per la empresa italiana NoMachine que n'ha alliberat el codi però també existeix una implementació lliure anomenada FreeNX. NX és un sistema que permet l'accés a l'escriptori a través de TCP/IP. Dóna una velocitat semblant a la que hi ha en connexions locals fins i tot a través de línies amb respostes de latència alta, o en enllaços de banda baixa. El nucli de les llibreries pertany a la empresa NoMachine i està sota llicència GPL. FreeNX és una implementació GPL del servidor NX. NX aconsegueix connexions remotes a X11 molt ràpides i està optimitzat per fer-se servir a través de connexions lentes. Aconsegueix aquesta eficiència en la velocitat fent una compressió directa del protocol X11 i fent servir caché per reaprofitar dades. A més xifra la comunicació enviant-la a través de SSH. Per tant perquè funcioni la connexió a través d'NX s'ha de tenir el servidor de SSH instal·lat i funcionant. I a més per defecte necessitem que: – – –

Admeti identificació a través de clau pública Escolti el port 22 Les claus estiguin a autorized_keys2

També podem trobar molta informació sobre com gestionar el servidor NX a http://www.nomachine.com/documents/admin-guide.php

3.6.3.2.1 Instal·lació del servidor a Ubuntu Feisty A la màquina que s'ha d'administrar remotament li hem d'instal·lar el servidor freeNX. En Ubuntu això té el problema que en els repositoris per defecte no hi ha el servidor freeNX. Això només implica que no podem instal·lar-lo només amb "apt-get install" sinó que: • •

O el recuperem des de codi font i el compilem nosaltres O bé es busca algun repositori que ja el tingui empaquetat perquè el puguem fer servir

Una simple recerca a Google ens dóna que hi ha un repositori anomenat Seveas on hi ha els paquets preparats per diferents versions d'Ubuntu. Per trencar amb el que faig sempre, faré servir el paquet d'aquest repositori. Per afegir "Seveas" als repositoris gestionats automàticament de la meva màquina 101

Gestió de xarxes d’àrea local editem l'arxiu /etc/apt/sources.list i hi afegim les dues línies següents: deb http://free.linux.hp.com/~brett/seveas/freenx feisty-seveas freenx deb-src http://free.linux.hp.com/~brett/seveas/freenx feisty-seveas freenx

Com que es tracta d'un nou repositori que gestionarà automàticament hem de descarregar les seves claus públiques per poder comprovar que els paquets no han estat modificats quan els descarreguem $ wget http://free.linux.hp.com/~brett/seveas/freenx/seveas.gpg -O- | sudo apt-key add -

i després d'actualitzar ja tindrem el servidor disponible: $ sudo apt-get update $ sudo aptitude install freenx

Configurar el servidor Segons he llegit durant la instal·lació el procés de postconfiguració hauria d'haver-me demanat quin sistema de claus vull fer servir però en el meu cas no m'ha demanat res. O sigui que l'he hagut de configurar a mà. He fet la configuració fent servir les claus que porta per defecte, encara que segurament seria molt millor generar claus pròpies. La comanda que he fet és aquesta (després he vist que es pot fer interactivament): $ sudo nxsetup –install –setup-nomachine-key –clean –purge

En la execució solen sortir una sèrie d'errors que segons he llegit en una web són normals perquè fan la detecció dels diferents components buscant els fitxers en un lloc que no és el mateix on Ubuntu els posa. En el cas que tinguem les nostres claus podem executar nxsetup i respondre el que vagi demanant: $ sudo nxsetup Password: ------> You did select no action. FreeNX guesses that you want to _install_ the server. Type "y" to abort the installation at this point in time. "N" is the default and continues installation. Use "/usr/sbin/nxsetup --help" to get more detailed help hints. Do you want to abort now? [y/N] ------> It is recommended that you use the NoMachine key for easier setup. If you answer "y", FreeNX creates a custom KeyPair and expects you to setup your clients manually. "N" is default and uses the NoMachine key for installation. Do you want to use your own custom KeyPair? [y/N]

102

Gestió de xarxes d’àrea local

Instal·lar el client Les màquines que vulguin accedir al servidor necessiten tenir instal·lat el client. Hi ha clients per diferents sistemes operatius: Windows, Linux, MacOS X i Solaris (http://www.nomachine.com). Instal·lar el client en Feisty té un problema: si fem "sudo aptitude install nxclient" ens instal·la la versió 2.1.0-17 que no he tingut forma de fer que funcionés... El resultat sempre era un error estrany just després d'identificar-se correctament: NX> 105 /usr/lib/nx/nxserver: line 891: 9976 Terminado ( sleep $AGENT_STARTUP_TIMEOUT; exit 1 ) NX> 504 Session startup failed. NX> 1004 Error: nxagent failed to start with: Unrecognized option: 1 NX> 1001 Bye. Killed by signal 15.

Per això s'ha d'instal·lar la versió anterior del client: nxclient_1.5.0-141_i386.deb que he vist que és el de Dapper (o almenys això és el que ha solucionat els meus problemes) Un cop instal·lat només s'ha d'engegar el programa i sortirà un assistent que ens permetrà preparar una connexió. $ /usr/NX/bin/nxclient &

Ens demanarà un nom de sessió, l'adreça del servidor al que ens volem connectar i el seu port, quin escriptori volem i la resolució desitjada.

103

Gestió de xarxes d’àrea local

Un cop acabat l'assistent tenim una bonica icona que ens permetrà connectar amb el servidor que hem configurat sense haver de fer totes les passes una altra vegada:

104

Gestió de xarxes d’àrea local

3.7 Configuració de servidors web 3.7.1 Introducció Un dels al·licients avui en dia en el vast món d'Internet és el de la publicació de pàgines web on poder emmagatzemar uns continguts força atractius per a nosaltres i que alhora poden ser consultats des d'arreu del món per tothom. Aquests tipus de documents, en la seva majoria HTML, han de ser allotjats en una màquina que sigui capaç d'emmagatzemar en directoris concrets fitxers HTML, imatges, programes cgi d'entorn web..., i alhora que sigui capaç d'entendre tot tipus d'extensió dels arxius que rep en ambdós sentits de la comunicació. També ha d'ésser capaç d'incorporar tot tipus d'aplicació de mercat com java, javascript, oracle, documents XML, Flash, vídeo MPEG..., i adaptar-se ràpidament a qualsevol aplicació nova seguint el vertiginós món d'Internet. Tot això ho ha de poder fer tenint en compte la seguretat a la xarxa, així haurà d'estar preparada amb protocols de comunicació segurs, com per exemple els desenvolupats amb l'https utilitzant claus i estratègies de xifrat gràcies a les eines SSL. Aquesta màquina rep el nom de Servidor Web i per assolir tots els objectius comentats ha de rodar sobre una aplicació-base que faci possible totes aquestes tasques. Es pot trobar una estadística actualitzada per mesos de l'ús que es fa dels servidors web a NetCraft: http://news.netcraft.com/archives/web_server_survey.html Els requeriments més importants d'un servidor són l'espai de disc necessari per poder emmagatzemar l'estructura de la nostra web i una bona connexió de xarxa perquè el consum de CPU és força baix. El funcionament dels servidors web és especial ja que té la característica que tendeix a tenir consums de recursos puntuals (podem estar temps sense peticions i el servidor 'adormit' i de cop tenir peticions molt importants). Això fa que els servidors web tendeixin a tenir un número baix de processos en espera (Apache per exemple n'arrenca 8 per defecte) i en va arrencant més a mesura que calguin. No totes les peticions consumeixen el mateix, les peticions que executin programes o les que requereixin xifrat (https) consumeixen més recursos que les tradicionals pàgines estàtiques. Les descàrregues d'arxius també seran un altre factor a tenir en compte a l'hora de dimensionar l'ample de banda de xarxa necessari pel servidor ja que s'hi poden provocar autèntics colls d'ampolla.

105

Gestió de xarxes d’àrea local

3.7.2 Apache web server El servidor web Apache és un dels majors triomfs del programari de lliure distribució ja que té una part molt important de la quota de mercat dels servidors web. La seu principal del projecte httpd Apache, iniciat i potenciat per l'Apache Software Fundation, la podeu trobar a: http://httpd.apache.org/ Apache fou inicialment uns 'parxes' (A PAtCHy sErver) per al servidor de WWW de NCSA cap a principis de 1995 conegut com httpd. A l'igual que GNU/Linux, va ser un projecte que va atraure molta gent pel gran interès de la seva fita: aconseguir el servidor web més ràpid, més eficient i amb major funcionalitat sempre sota l'enfocament de la lliure distribució, regit per la llicència GNU General Public License. L'Apache és un servidor web flexible, ràpid i eficient, contínuament actualitzat i adaptat als nous protocols HTTP/1.1. De la gran quantitat de característiques en destaquen: • • •

• •

És multiplataforma (Linux, Unix, Windows, ... ) Segueix els protocols estàndards internacionals ( HTTP/1.1, ...) És modular , cosa que li permet adaptar-se a diferents entorns i necessitats poden activar només aquelles parts que són necessàries. També disposa d'una API de programació de mòduls que permet que els usuaris puguin programar els seus propis mòduls específics Es desenvolupa de forma oberta i es retroalimenta de noves idees, 'logs' d'errades i 'parxes' per a la resolució dels problemes que vagin trobant. És extensible, ja que gràcies a la seva característica modular s'han desenvolupat diverses extensions com les de programació (PHP, Python, Java, Perl, ...) que es correspon amb un llenguatge de programació que camina paral·lelament al servidor i que permeten connectar amb múltiples Bases de Dades (Oracle, Informix, MySQL, PostgreSQL, Adabas, ... ) D'entre aquestes extensions també en podem destacar SSL, que està associat a la possibilitat de fer servir aquest servidor web de cares al comerç electrònic. Aquest mòdul ens permet tenir xifrat i autentificació via Certificats.

Actualment s'estan mantenint diferents versions del servidor web d'Apache (1.3, 2.0 i 2.2) on les noves versions ofereixen noves característiques per adaptar-se a les noves necessitats.

106

Gestió de xarxes d’àrea local

3.7.2.1 Instal·lació d’Apache Generalment la majoria de distribucions de Linux tenen en els seus repositoris una versió d'Apache actualitzada però en cas de necessitat sempre podem recórrer a descarregar-lo directament des de la pàgina web i fins i tot des de la mateixa pàgina web podem descarregar la versió de Windows.

En principi la instal·lació per defecte no té gaires dificultats més que executar el programa instal·lador, ja sigui a través del executable de Windows o cridant el programa de instal·lació de la distribució Linux que estiguem fent servir. Per exemple en Ubuntu en tenim prou amb fer: $ sudo apt-get install apache

I si tot va bé portant el navegador a la nostra màquina ( http://localhost )ens hauria de mostrar la pàgina de prova que ens demostra que tot està funcionant.

En comptes d'aquesta en algunes distribucions també ens pot sortir una pàgina on només hi surt “It works!”

107

Gestió de xarxes d’àrea local

3.7.2.2 Configuració d'Apache Apache per defecte guarda la configuració en un arxiu que normalment es diu httpd.conf (en alguns sistemes l'he vist reanomenat a apache2.conf) i que en Linux sol estar a /etc/httpd, /etc/apache2 o en el directori de Windows que hagem especificat i pot ser estès a través de la directiva Include La directiva Include serveix per incloure altres arxius de configuració i normalment es fa servir per tenir la configuració més organitzada amb diferents tipus d'arxius (per exemple un per cada host virtual). Això permet que puguem tenir la configuració més organitzada i trobar els errors que sorgeixin ràpidament. Include /usr/local/apache2/conf/ssl.conf Include /usr/local/apache2/conf/vhosts/*.conf

És impossible veure totes les directives que suporta Apache (per això el millor és recórrer a la documentació del servidor http://httpd.apache.org/docs/) però en destacarem algunes: Listen

Quan Apache arranca ha d'escoltar les connexions que li arribin per algun port. Encara que per defecte el port que es fa servir és el 80 en podem escoltar d'altres simplement especificant-los. ex. Escoltarà el 80 i el 8080 Listen 80 Listen 8080

També podríem definir quins són els dispositius de xarxa que escoltarem: Listen 0.0.0.0:80 Listen 192.168.0.2:8080

ServerRoot

Defineix en quin lloc hi ha la configuració del servidor i normalment tindrà els directoris conf i logs ex.

DocumentRoot

ServerRoot /etc/httpd

Defineix des de quin lloc es serviran els fitxers. On és la pàgina web. ex. DocumentRoot /var/www/

ServerName

Té el nom i port que el servidor fa servir. Té especial importància a l'hora de configurar hosts virtuals per nom. ex. ServerName www.patata.cat:80

DirectoryIndex

Defineix una llista de possibles noms de fitxers que el servidor agafarà com a fitxer per defecte en el cas en que no se n'especifiqui cap. El servidor els mostrarà per ordre (o sigui que si hi ha el primer aquest serà el que mostrarà encara que també hi hagi el segon) ex. DirectoryIndex index.html index.php

108

Gestió de xarxes d’àrea local User

Usuari amb els permisos del qual s'executaran les instàncies del servidor Apache. Això implica que el servidor encara que s'arranqui com a root els processos tindran els permisos d'aquest usuari. ex.

Alias

User apache

Alias serveix per posar directoris que estan fora de l'arrel del servidor de manera que siguin accessibles com si fossin a dins. ex.

Alias /alegria “/var/alegria” farà que poguem accedir a /var/alegria només especificant el directory darrere del nom del servidor. http://www.patata.com/alegria

Timeout

Defineix el temps que el servidor esperarà a que passi un determinat event ex. Timeout 300

Errorlog

Es tracta d'una comanda important perquè és el lloc on Apache anirà guardant els errors i informació de diagnòstic que es vagin produint en el funcionament. Normalment serà el primer lloc on anirem a mirar quan alguna cosa falli. ex. ErrorLog /var/log/httpd/error_log

LogLevel

Defineix quina quantitat d'informació s'anirà guardant sobre el funcionament del servidor. Anant de més informació a menys pot tenir els valors: debug, info, notice, warn, error, crit, alert, emerg ex.

LogLevel warn

Es tracta d'una directiva que es fa servir per definir característiques que només s'aplicaran al directori especificat i no a tot el servidor (per això s'ha de tancar). Podem reescriure gairebé qualsevol de les directives per el directori. ex.

LoadModule

<Directory /usr/local/httpd/htdocs> Options Indexes FollowSymLinks AllowOverride None </Directory>

Es fa servir per carregar els diferents mòduls del servidor i és el que ens permet estendre les possibilitats del servidor. ex. LoadModule status_module modules/mod_status.so

Ara veurem algunes de les possibilitats que té aquest servidor que poden ser interessants. Per defecte faré servir la distribució Ubuntu però la majoria de les coses poden ser utilitzades en altres distribucions i plataformes simplement localitzant en quin lloc s'han de fer.

109

Gestió de xarxes d’àrea local

3.7.2.2.1 Pàgines personals Es pot fer que Apache ens permeti que els diferents usuaris que treballen en la màquina tinguin la seva pròpia pàgina personal. Per defecte hi podran accedir afegint a l'adreça del servidor ~usuari. Això vol dir que si el nostre servidor està a http://www.patata.com i tenim un usuari que es diu pepet la seva pàgina personal estarà a http://www.patata.com/~pepet Per fer-ho només hem de comprovar que a la configuració del servidor hi hagi la directiva UserDir configurada. ... Userdir public_html ...

Amb això la única cosa que ha de fer l'usuari per tenir la seva pròpia pàgina personal és crear el directori public_html al seu directori i posar-hi a dins la seva pàgina. (per exemple en Linux normalment la pàgina estarà /home/pepet/public_html ) Podem restringir quins usuaris tenen pàgina personal fent servir enabled/disabled: ... UserDir enabled UserDir disabled root mariano ...

En aquest exemple tots els usuaris tindran web personal menys el 'root' i en 'mariano'.

110

Gestió de xarxes d’àrea local

3.7.2.2.2 Virtual Hosting La idea del virtual host fa referència a fer veure que estem executant més d'un servidor alhora en la mateixa pàgina. Hi ha dos tipus de virtual hosts a través de nom (diversos noms per la mateixa adreça IP) i a través de adreça IP (cada web té una adreça diferent). Virtual Hosts per nom Per configurar un servidor que contingui diferents web el primer pas ha de ser configurar els DNS perquè apuntin a la mateixa màquina ( o sigui que www.patata.com i www.tomata.net estiguin definides en els DNS cap a la nostra màquina). Per fer-ho hem de definir una directiva NameVirtualHost i després una VirtualHost per cada una de les pàgines. Normalment si la IP és la mateixa en tindrem prou amb definir * com a paràmetre de NameVirtualHost. NameVirtualHost * <VirtualHost *> ... (definició de www.patata.com) </VirtualHost> <VirtualHost *> ... (definició de www.tomata.com) </VirtualHost>

Evidentment això es pot definir en el fitxer de configuració però la majoria de distribucions de Linux han definit una política per fer que els diferents Virtual Hosts estiguin organitzats en un fitxer diferent i s'inclouen a través de la directiva Include. Com a exemple veurem el procediment en Ubuntu/Debian Configuració de virtual host per nom en Ubuntu En Ubuntu els VirtualHosts es crea un arxiu per cada host a /etc/apache2/sitesavailable . Per defecte ja hi trobarem un arxiu 'default' que té la configuració per defecte i que haurem de modificar perquè s'hi defineixi el NameVirtualHost (no cal fer-hi cap més canvi) # cd /etc/apache2/sites-available # joe default NameVirtualHost *:80 <VirtualHost *:80> ... </VirtualHost>

Un cop fet el podem fer servir de plantilla per crear els altres dos fitxers # cp default patata # cp default tomata

I després només ens hem de limitar a canviar els fitxers perquè facin referència a els noms que volem definir nosaltres. En aquest cas la clau està en el que posem a 'ServerName' ja que és el que farà servir Apache per triar una pàgina o una altra. Per tant editem l'arxiu 'patata' i el deixem més o menys com aquest: NameVirtualHost *:80

111

Gestió de xarxes d’àrea local <VirtualHost *:80> ServerName www.patata.com ServerAdmin root@patata.com DocumentRoot /var/www/patata ErrorLog /var/log/httpd/patata-error_log TransferLog /var/log/httpd/patata-access_log <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/patata> </VirtualHost>

I el mateix hem de fer amb l'arxiu 'tomata' NameVirtualHost *:80 <VirtualHost *:80> ServerName www.tomata.com ServerAdmin root@tomata.com DocumentRoot /var/www/tomata ErrorLog /var/log/httpd/tomata-error_log TransferLog /var/log/httpd/tomata-access_log <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/tomata> </VirtualHost>

En altres sistemes segurament amb això en faríem prou però perquè funcioni el virtual host en Ubuntu cal que els activem. Per fer-ho fem: # a2ensite patata # a2ensite tomata

En el cas en que ens calgui desactivar algun host virtual ho podem fer amb la comanda a2dissite. Per exemple aquesta comanda desactivaria el host 'patata': # a2dissite patata

En realitat el que fa és enllaçar el que tenim al directori sites-available a sites-enabled. Com que hem fet canvis en la configuració ens caldrà reiniciar el servidor o bé dir-li que recarregui la configuració: # /etc/init.d/apache2 force-reload

Virtual Hosts per IP La idea de la configuració a través d'adreces IP és que tenim una màquina que té varies IP diferents (ja sigui a través de diferents targetes de xarxa o bé a través de interfícies virtuals). El funcionament és semblant amb la diferència que només hem de definir la IP o el nom del host en la línia que defineix el host virtual (es recomana fer servir la IP en comptes del nom però jo faig servir el nom perquè s'entengui)

112

Gestió de xarxes d’àrea local NameVirtualHost * <VirtualHost www.patata.com> ... (definició de www.patata.com) </VirtualHost> <VirtualHost www.tomata.com> ... (definició de www.tomata.com) </VirtualHost>

113

Gestió de xarxes d’àrea local

3.7.2.2.3 Protecció de directoris amb contrasenya Podem restringir l'accés a zones del servidor web de manera que calgui entrar-hi a través d'usuari i contrasenya o bé si s'hi accedeix a través d'un rang d'adreces IP. Això ho podem fer definint-ho a través d'una directiva <Directory> o bé creant en el directori que volem restringir un fitxer .htaccess El primer que cal és que en el directori afectat no hi hagi activa la directiva “AllowOverride None”. Per això si volem protegir amb contrasenya el directori /var/www/secret i no volem canviar al configuració per defecte de les altres pàgines hi afegim una directiva específica (tenim diverses opcions que ens permetran fer això: All, AuthConfig) ... <Directory /var/www/secret> Options FollowSymLinks AllowOverride AuthConfig </Directory> ...

En aquesta mateixa directiva hi podríem posar els permisos d'accés però ho farem a través del fitxer .htaccess perquè ens permetrà fer canvis sense haver de tocar la configuració del servidor. Apache permet crear fitxers especials d'usuaris per accedir als directoris sense haver de recórrer als del sistema. Per crear un fitxer d'usuaris es fa servir la comanda htpasswd (i -c només quan vulguem crear el fitxer). # htpasswd -c /var/fitxer pepet New password: Re-type new password: Adding password for user pepet # htpasswd /var/fitxer mariano New password: Re-type new password: Adding password for user mariano

A continuació només cal crear un fitxer de nom .htaccess en el directori que volem protegir (/var/www/secret). El fitxer contindrà la configuració següent: AuthType Basic AuthUserFile /var/fitxer AuthName "Espai protegit" require valid-user

A partir d'aquest moment als que accedeixin al directori especificat se'ls demanarà usuari i contrasenya. També podríem restringir l'accés per usuaris. Per exemple per només permetre que pugui entrar l'usuari pepet canviem la darrera línia 'require valid-user' per 'require user pepet'. AuthType Basic AuthUserFile /var/fitxer

114

Gestió de xarxes d’àrea local AuthName "Espai protegit" require user pepet

També podíem haver especificat tota la configuració en la directiva <Directory> de la següent forma (i per tant no caldria el fitxer .htaccess) ... <Directory /var/www/secret> Options FollowSymLinks AllowOverride AuthConfig AuthType Basic AuthUserFile /var/fitxer AuthName "Espai protegit" require user pepet </Directory> ...

No cal dir que després de canviar la configuració caldrà reiniciar el servidor (però no per fer canvis en el fitxer .htaccess o si només volem afegir usuaris nous al fitxer que fem servir) Accés per IP Per permetre que la gent que està dins de la nostra xarxa local o des de 192.168.1.1 puguin accedir a la pàgina sense que se'ls hi demani contrasenya podem definir-ho dins de la directiva <Directory> que hem definit abans: ... <Directory /var/www/secret> Options FollowSymLinks AllowOverride All Allow from 192.168.0 192.168.1.1 Deny from All </Directory> ...

Es evident que podem combinar les dues coses (accés amb usuari i per IP) però tenint en compte l'ordre en que es faran les coses ... <Directory /var/www/secret> Options FollowSymLinks AllowOverride All Allow from 192.168.0 Deny from All AuthType Basic AuthUserFile /var/fitxer AuthName "Espai protegit" require user pepet Satisfy any </Directory> ...

La comanda important és 'Satisfy any' que ens permetrà que no calgui complir les dues condicions sinó només una de les dues.

115

Gestió de xarxes d’àrea local

3.7.2.2.4 Configuració de SSL Una altra de les configuracions que podem fer amb Apache és habilitar-hi l'accés segur a través de SSL. L'accés a aquestes pàgines es fa a través de https:// en comptes d'a través de http:// (entre altres coses això implica que les connexions es faran a través del port 443 en comptes de a través del 80) Per fer servir SSL necessitem varies coses: que el servidor tingui un certificat per poder xifrar la comunicació entre nosaltres i el client que s'hi connecti, i activar el mòdul d'SSL. Configuració d'un servidor web amb SSL en Ubuntu En el cas que no tinguem el mòdul instal·lat només l'hem d'instal·lar: $ sudo apt-get install apache2-ssl-certificate

Hem de comprovar que el servidor web perquè escolti el port 443. Simplement editem l'arxiu de configuració i hi afegim la comanda Listen adequada. Editem l'arxiu de configuració /etc/apache2/ports.conf (Ubuntu defineix els ports en un arxiu especial) i hi afegim: ... Listen 443 ...

Per activar el mòdul SSL en Ubuntu només hem de fer servir la comanda a2enmod (enable module) i en el cas en que el volguéssim desactivar (a2dismod) $ a2enmod ssl

Per crear un certificat podem fer servir l'script 'apache2-ssl-certificate' i respondre les preguntes adequades: $ apache2-ssl-certificate

creating selfsigned certificate replace it with one signed by a certification authority (CA) enter your ServerName at the Common Name prompt If you want your certificate to expire after x days call this programm with -days x Generating a 1024 bit RSA private key ........++++++ ....................++++++ writing new private key to '/etc/apache2/ssl/apache.pem' ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [GB]:ES State or Province Name (full name) [Some-State]:Catalunya Locality Name (eg, city) []:Cabanes Organization Name (eg, company; recommended) []:Xavier Organizational Unit Name (eg, section) []:cap server name (eg. ssl.domain.tld; required!!!) []:mixkin.xaviersala.local Email Address []:xavier@xaviersala.local

116

Gestió de xarxes d’àrea local

Una forma alternativa (que és la que utilitzaré) és fer servir la comanda openssl per crear el certificat que ens crearà els dos fitxers (server.key i server.crt) que necessitarà el sistema i de passada els poso en un directori perquè quedi tot ben ordenat: $ mkdir /etc/apache2/conf.d/certs $ cd /etc/apache2/conf.d/certs $ openssl req -new -x509 -nodes -out server.crt -keyout server.key

Creem un host virtual nou pel SSL: $ cd /etc/apache2/sites-available $ cp default ssl

I el configurem perquè sàpiga que volem que sigui una pàgina amb SSL NameVirtualHost *:443 <VirtualHost *:443> SSLEngine on ServerAdmin webmaster@localhost DocumentRoot /var/www/ssl ...

Creem l'arxiu de configuració de SSL /etc/apache2/conf.d/ssl-local SSLProtocol all SSLCipherSuite HIGH:MEDIUM SSLCertificateFile /etc/apache2/conf.d/certs/server.crt SSLCertificateKeyFile /etc/apache2/conf.d/certs/server.key

I activem el virtual host i reiniciem el servidor: # a2ensite ssl # /etc/init.d/apache2 force-reload

117

Gestió de xarxes d’àrea local

3.7.3 IIS Internet Information Services , IIS, són una sèrie de serveis pels ordinadors que funcionen sota Windows. Inicialment només eren una opció per Windows NT però posteriorment va ser integrat en els sistemes operatius de Microsoft destinats a oferir serveis com Windows 2000 o 2003. També hi ha una versió limitada en XP (només suporta 10 connexions simultànies i un sol lloc web) i Vista (ja no limitat les connexions però si el flux de tasques). IIS ofereix diferents serveix com: FTP, SMTP, NNTP, HTTP i HTTPS de manera que l'ordinador es pot convertir en un servidor d'Internet tant local com remot. El servidor web es basa en mòduls que li donen capacitat per processar els diferents tipus de pàgines que se li demanen com ASP (Active Server Pages) i ASP.NET però també estan disponibles mòduls de PHP o Perl.

3.7.2.1 Instal·lació de IIS La instal·lació de IIS és realitvament senzilla perquè estarà disponible en el CD de Windows o sigui que només hem d'accedir al panell de control i clicar en la instal·lació de components de Windows

Després ens sortirà l'assistent d'instal·lació de components i només hem de marcar l'adequat

118

Gestió de xarxes d’àrea local Amb els detalls podem definir quins dels serveis que ofereix volem instal·lar:

Abans de posar el servidor en funcionament no està de més fer una passada per el Windows Update (o Microsoft Update) per comprovar que no hi ha pedaços de seguretat a instal·lar. A pesar de que el servidor ara és bastant segur, té una llarga tradició de fallades de seguretat.

Un cop acabada la instal·lació ja tindrem el assistent de configuració a punt:

119

Gestió de xarxes d’àrea local

3.7.2.2 Configuració de IIS Com sol ser corrent en Windows podem accedir a la configuració de IIS a través de múltiples llocs diferents (propiedades de “Mi PC”, Panel de control->Herramientas administrativas, etc..) . Però la configuració la farem a través de la consola MMC

I podem accedir a les característiques de la configuració de cada una de les carpetes a través de “propiedades” i es fa tot en un entorn gràfic a través de pestanyes:

120

Gestió de xarxes d’àrea local

3.7.2.2.1 Protecció de directoris amb contrasenya La protecció de directoris per contrasenya en IIS es pot fer de moltes formes diferents però sempre fent servir els mecanismes que dóna Windows per fer-ho (usuaris, grups d'usuaris, etc...)

Això ens permet fer servir diferents formes d'identificació d'usuaris basades en els sistemes d'identificació d'usuaris de Windows (llistes de control NTFS, etc...)

121

Gestió de xarxes d’àrea local Per fer una autentificació a l'estil d'Apache, cosa sempre interessant, podem fer-ho amb un programa que han desenvolupat a Troxo ( http://www.troxo.com ): IISPassword ISPassword és un component ISAPI per IIS que permet protegir el contingut d'una pàgina web sense haver de configurar comptes d'usuari (que és el procediment normal en IIS). El programa s'integra en les propietats de IIS de la consola MMC i permet definir de forma senzilla quines carpetes s'han de protegir i amb quins usuaris/contrasenyes. IISPassword és compatible amb els fitxers htaccess de Apache i per tant permet fer el canvi de forma senzilla

122

Gestió de xarxes d’àrea local

3.7.2.2.2 Configuració de SSL El procediment que dóna IIS per crear certificats ens fa tota la feina i prepara el certificat per ser enviat a una entitat de certificació. Això no és el que volem ara, sinó que volem tenir un certificat signat per nosaltres mateixos per poder xifrar les connexions que es facin contra la nostra pàgina web. Per fer això necessitem instal·lar el paquet OpenSSL per Windows per poder crear-nos una Entitat d'Autentificació (això ens permetrà signar certificats que podran fer servir les nostres pàgines web). Està clar que els navegadors no ens reconeixeran com una Entitat d'Autenticació vàlida i els mostrarà un avís, però ens serveis per ús intern. Per defecte farà la instal·lació a c:\OpenSSL i per fer les coses més còmodes el millor és que afegim al path els executables. Com que només ho farem servir una vegada obrirem una consola i afegirem el camí temporalment per fer el certificat. C:> PATH = %PATH%;C:\OpenSSL\Bin C:>

Els certificats els crearem a C:\SSL i sense tancar la consola anterior creem els directoris necessaris i crear els dos arxius database.txt i serial.txt C:> md SSL C:> cd SSL C:\SSL> md KEYS C:\SSL> md REQUESTS C:\SSL> md CERTS C:\SSL> copy con database.txt ^Z C:\SSL> copy con serial.txt 01 ^Z C:\SSL>

Un cop fet això ja podem crear el certificat. Primer de tot creem la clau que farem servir per fer els certificats: C:\SSL> openssl genrsa -des3 -out keys/ca.key 1024 Loading 'screen' into random state - done

warning, not much extra random data, consider using the -rand option Generating RSA private key, 1024 bit long modulus ...........++++++ ..................++++++ e is 65537 (0x10001) Enter PEM pass phrase: ******** Verifying password - Enter PEM pass phrase: ******** C:\SSL>

Això crearà un arxiu a c:\ssl\keys\ca.key on hi haurà la clau que servirà per fer els certificats.

123

Gestió de xarxes d’àrea local Un cop tenim la clau ja podem crear el certificat mestre que servirà per signar altres certificats: C:\ssl>openssl req -config openssl.conf -new -x509 -days 1001 -key keys/ ca.key -out certs/ca.cer Using configuration from openssl.conf Enter PEM pass phrase: - type your passphrase here. You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) []:ES State or Province Name (full name) []:Girona Locality Name (eg, city) []:Cabanes Organization Name (eg, company) []:tomata.net Organizational Unit Name (eg, section) []: Common Name (eg, your websites domain name) []:ssl.tomata.net Email Address []:ssl@tomata.net

Això crearà l'arxiu de certificat de la nostra Entitat de Certificació que quedarà emmagatzemat a c:\ssl\certs\ca.cer Ara tornem a la configuració de la web. Per poder fer servir certificats en IIS abans hem de crear una petició de certificat que en teoria s'ha d'enviar a la Entitat de Certificació perquè la signi. La petició la podem fer a través de les eines que ens dóna IIS i que al final ens generarà la petició que estarà en l'arxiu certreq.txt. Anem a l'arrel del servidor web i en la pestanya de “Seguridad de directorios” premem “Certificado de servidor...”

124

Gestió de xarxes d’àrea local El que fem serà deixar la petició pendent d'enviament perquè com que hem creat la nostra Entitat de Certificació no cal que la enviem enlloc.

Després de respondre a les preguntes sobre les dades que volem que identifiquin a la nostra web només ens caldrà especificar en quin lloc es guardarà la petició que hem d'enviar:

Ara simulem l'enviament a la entitat de certificació copiant l'arxiu en el directori Requests del nostre directori: C:> COPY certreq.txt C:\SSL\Requests

Ara tornem a posar-nos en la pell de la “Entitat de Certificació” i procedirem a signar el certificat que tenim pendent i que ha d'anar de retorn al servidor.

125

Gestió de xarxes d’àrea local Per fer-ho l'hem d'acceptar i després convertir-lo al format x509 perquè la pugui fer servir el IIS: C:\SSL> openssl ca -policy policy_anything -config openssl.conf -cert certs/ca.cer -in requests/certreq.txt -keyfile keys/ca.key -days 360 -out certs/iis.cer Using configuration from openssl.conf Loading 'screen' into random state - done Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows commonName :PRINTABLE:'myCommonName' organizationalUnitName:PRINTABLE:'myOrganisationalUnit' organizationName :PRINTABLE:'myOrganisation' localityName :PRINTABLE:'myLocality' stateOrProvinceName :PRINTABLE:'myProvince' countryName :PRINTABLE:'GB' Certificate is to be certified until Feb 2 01:13:14 2004 GMT (360 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

C:\SSL> openssl x509 -in certs/iis.cer -out certs/iisx509.cer

El darrer pas serà importar el certificat en el IIS accedint a la pestanya de “Seguridad de directorios” premem “Certificado de servidor...”

126

Gestió de xarxes d’àrea local

I després de seleccionar el certificat x509 que hem preparat ens presentarà les dades que vam incloure en el certificat i ja el tindrem disponible per poder-lo fer servir en les nostres pàgines. Per fer-ho, dins de la nostra web seleccionem la carpeta a xifrar i entre les propietats anem a “Seguridad de directorios” i “Modificar...” de la secció “Comunicaciones seguras”:

127

Gestió de xarxes d’àrea local Ens apareixerà la pantalla en la que cal seleccionar “Requerir canal seguro (SSL)” que forçarà a que tots els accés la la carpeta sigui a través del protocol HTTPS. Això forçarà a que la comunicació entre el client i el servidor sigui obligatòriament a través de SSL i per tant xifrada.

128

Gestió de xarxes d’àrea local

3.7.4 Lighttpd Lighttpd és un servidor web que darrerament està tenint molt d'èxit per exemple en la seva web destaquen que webs molt importants com YouTube o la Wikipedia estan fent servir aquest servidor. Està programat tenint en ment evitar alguns dels problemes que alguns usuaris troben a Apache i per això s'intenta que sigui: ràpid, segur, flexible i que compleixi estrictament els estàndards. L'objectiu és que es pugui fer servir en entorns on la velocitat és el més important i per això consumeix poca CPU i memòria (menys que la majoria dels altres grans servidors).I a pesar d'això té una gran quantitat de característiques: FastCGI, SCGI, Auth, Compressió, Reescriptura d'URL, Virtual hosting, ... Està sota llicència BSD i funciona primàriament en Linux/Unix però també hi ha una versió del servidor per Windows.

3.7.4.1 Instal·lació La instal·lació és tant senzilla com ho és la dels altres servidors. Després de l'èxit que ha tingut sol estar en qualsevol de les distribucions de Linux i normalment es podrà instal·lar fent servir les eines per defecte com: # apt-get install lightttpd

S'ha de tenir en compte que s'han de complir els requeriments que normalment son les llibreries: ●

libpcre

●

libz

Per exemple en Ubuntu les dependències es poden instal·lar de la següent forma: $ sudo apt-get install libpcre3-dev $ sudo apt-get install zlib1g-dev $ sudo apt-get install libglib2.0-dev

129

Gestió de xarxes d’àrea local

També el podem instal·lar en Windows d'una forma relativament senzilla Independent de la forma en que l'haguem instal·lat, quan tot vagi bé podrem comprovar que la instal·lació ha funcionat bé accedint a “localhost” i ens hauria de sortir la pàgina de confirmació de la instal·lació (en alguns sistemes ens trobarem pàgines diferents però el que hem de confirmar és que en surt alguna)

130

Gestió de xarxes d’àrea local

3.7.4.2 Configuració La configuració de lighttpd està en l'arxiu lighttpd.conf que en els sistemes Linux estarà a /etc/lighttpd/lighttpd.conf En el cas en que només vulguem un servidor de pàgines web estàtiques la configuració pot ser tan senzilla com: server.document-root = "/var/www/servers/www.patata.net/pages/" server.port = 80 server.username = "www"

server.groupname = "www" accesslog.filename = "/var/www/logs/access" server.errorlog = "/var/www/logs/error" mimetype.assign = ( ".html" => "text/html", ".txt" => "text/plain", ".jpg" => "image/jpeg", ".png" => "image/png" ) static-file.exclude-extensions = ( ".fcgi", ".php", ".rb", "~", ".inc" ) index-file.names = ( "index.html" )

Només ens hem d'assegurar que l'usuari que executa el servidor tingui permisos per accedir al directori de la pàgina web (en l'exemple l'usuari és 'www'). D'entre les comandes de configuració més bàsiques en podem destacar: server.document-root

Definim en quin lloc hi ha les nostra pàgina web

server.port

Definim el port que estarà escoltant el nostre servidor

server.username server.groupname

Usuari que executarà el servidor un cop el 'root' hagi pres possessió del port

index-file.names

Nom que tindran els fitxers per defecte ex. index-file.names = ("index.php","index.html", "index.htm", "default.htm" )

server.errorlog

On es guardaran els errors del servidor

accesslog.filename

Definim en quin lloc es guardarà el registre d'accés del nostre servidor

server.max-connections

Número màxim de connexions que accepta el servidor.

131

Gestió de xarxes d’àrea local server.modules

Serveix per especificar quins mòduls s'han de carregar quan s'inicia el servidor Ex. server.modules

= ( "mod_rewrite", "mod_redirect", "mod_alias", "mod_access", "mod_auth", "mod_status")

Evidentment n'hi ha moltes més i en el cas que hagem de fer alguna configuració molt especial el millor lloc per trobar informació és el manual d'usuari de la pàgina de lighttpd (http://www.lighttpd.net) o en la documentació del producte (en Ubuntu està a lighttpd-doc) La majoria de les característiques especials es fan a través de mòduls que com hem vist es poden carregar fent servir server.modules Després d'editar la configuració una bona cosa a fer és comprovar que el fitxer de configuració que hem fet està bé: $ lighttpd -t -f lighttpd.conf

132

Gestió de xarxes d’àrea local

3.7.4.2.1 Virtual Hosting Podem crear servidors virtuals que compartiran les característiques del principal simplement definint-los en la configuració: ... $HTTP["host"] == "www.tomata.net" { server.document-root = "/var/www/servers/www.tomata.net/pages/" }

Aquest servidor compartirà les característiques per defecte del servidor principal però amb un lloc diferent a disc. Però podem definir-hi altres característiques o fins i tot definir característiques especials per un directori en concret: ... $HTTP["host"] == "www.tomata.net" { server.document-root = "/var/www/servers/www.tomata.net/pages/" $HTTP["url"] =~ "^/download/" { dir-listing.activate = "enable" } }

En l'exemple anterior només el directori download, al que accedirem amb www.tomata.net/download/ ) permetrà que es vegi la llista d'arxius i els altres no. També podem fer servir variables per no haver d'escriure cada vegada el directori: ... $HTTP["host"] == "www.exemple.org" {

var.basedir = "/var/www/servers/www.example.org/" server.document-root = basedir + "pages/"

}

133

Gestió de xarxes d’àrea local

3.7.4.2.2 Protecció de directoris amb contrasenya La configuració de protecció de directoris amb contrasenya es fa a través del mòdul mod_auth. La forma d'afegir el mòdul estàndard consisteix en afegir el mòdul a la comanda de càrrega de mòduls: ... server.modules

= ( ..., "mod_auth", ...)

...

Però en sistemes basats en Debian ho podem fer amb: $ lighty-enable-mod auth

Lighttpd suporta els dos mètodes d'autentificació definits en el RFC 2617: el bàsic (S'envien l'usuari i la contrasenya en planer per la xarxa) o el digest (només transmet un valor de hash). Els mètodes que pot fer servir per guardar la identificació d'usuaris poden ser: plain

Consisteix en tenir un fitxer que guarda l'usuari i la contrasenya separades per “:” i sense xifrar de cap forma ex. pepet:secreta

htpasswd

Un fitxer que conté la llista d'usuaris i contrasenyes però les contrasenyes estaran xifrades amb 'crypt()'. Normalment el millor és fer servir htpasswd per generar aquest fitxer ex. pepet:P2aY5JwrAVBXsQ

digest

En el fitxer hi tindrem: l'usuari, el reialme, i la contrasenya xifrada amb 'md5()'. Per generar el fitxer es pot fer servir htdigest d'Apache. ex. pepet:Servidor segur:8364d0044ef57b3defcfa141e8f77b65

ldap

Si tenim un servei LDAP que serveix per identificar els nostres usuaris també podem fer-lo servir per controlar quins usuaris poden accedir a les carpetes compartides i quins no.

En l'exemple farem servir el sistema de protecció de directoris d'Apache via htpasswd, per fer-ne qualsevol d'altre consulteu la documentació. 134

Gestió de xarxes d’àrea local

Lighttpd no suporta protecció de fitxers via .htaccess o sigui que si volem protegir un directori l'hem d'especificar en la configuració del servidor (en el fitxer lighttpd.conf) Una de les característiques dels mòduls és que les comandes comencen amb el nom del mòdul i per tant totes les comandes que necessitem en aquest cas començaran amb auth ... auth.backend = "htpasswd" auth.backend.htpasswd.userfile = "/var/www/htpasswd.user" auth.require = ( "/segur" => ( "method" => "basic", "realm" => "Directory Segur", "require" => "valid-user" ) ...

També podríem haver definit un o més usuaris d'una forma similar a la que fa servir Apache canviant la línia 'require': ... "require" => "user=pepet|user=pepeta" ...

El significat de les comandes que hem fet servir és: auth.backend

Definim de quina forma es guarda la autentificació dels usuaris (plain, htpasswd, ldap or htdigest)

auth.debug

Definim quin nivell de debug volem en l'ús d'aquest mòdul (0 desactivat, 1 guarda qui s'ha identificat, 2 informació detallada)

auth.require

Definim quins directoris tenen protecció i de quines condicions tenim per identificarlos.

auth.backend.htpasswd.userfile

Fitxer amb les contrasenyes i els usuaris en el cas que fem autentificació al sistema d'apache.

135

Gestió de xarxes d’àrea local

3.7.4.2.3 Configuració de SSL Per poder configurar el servidor per fer servir SSL necessitem tenir un certificat. Com les altres vegades fem servir openssl per crear-nos el nostre propi certificat autosignat: $ cd /etc/ssl/certs $ openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 365 -nodes $ chown www:www lighttpd.pem $ chmod 600 lighttpd.pem

I editem l'arxiu de configuració perquè faci servir el certificat en les connexions pel port 443: $SERVER["socket"] == ":443" { ssl.engine = "enable" ssl.pemfile = "/etc/ssl/certs/lighttpd.pem" ssl.ca-file = "/etc/ssl/CA.crt" }

Si tenim un fitxer amb la clau i un certificat podem generar un fitxer .pem només encadenant-los (el ca-file només cal per evitar problemes amb alguns navegadors): $ cat host.key host.crt > host.pem

Lighttpd no pot fer servir virtualhost per nom en lighttpd, si volem fer-ho ho hem de fer a través de IP: var.confdir = "/etc/lighttpd" $SERVER["socket"] == "15.15.15.15:443" { ssl.engine = "enable" ssl.pemfile = var.confdir + "/www.domain.com.pem" ssl.ca-file = var.confdir + "/gd_intermediate.crt" server.name = var.confdir + "/www.domain.com" server.document-root = "/my/document/root/" }

També podem redirigir totes les peticions que arribin al seu equivalent pel port 443: $SERVER["socket"] == ":80" { $HTTP["host"] =~ "(.*)" { url.redirect = ( "^/(.*)" => "https://%1/$1" ) } }

136

Gestió de xarxes d’àrea local

3.8 Configuració de correu electrònic 3.8.1 MTA Un servidor de correu electrònic (MTA, Mail transfer agent) és un programa que transfereix missatges de correu electrònic d'un ordinador a un altre. També pot rebre altres noms com “mail transport agent”, “message transfer agent” o “smtpd”. Des del punt de vista dels DNS també solen ser anomenats mail exchanger (MX) i en aquest cas fa referència a la adreça IP assignada a l'ordinador que corre el programa. El funcionament bàsic és fer 'relay' (transferir un missatge que ve des del programa origen (MUA, mail user agent), funcionant com a un MSA, mail submission agent. L'enviament dels missatges nomalment va dirigit cap a una bústia de correu determinada i molts MTA tenen capacitats de redirecció dels missatges que els arriben o bé poden fer servir altres servidors, com procmail, per tenir més capacitat d'organització. En les enquestes que s'han fet els servidors de correu més importants que es fan servir són: Sendmail, Microsoft Exchange Server, Postfix i Exim que cobreixen aproximadament un 85% del mercat.

Spam

L'spam és un dels problemes més importants als que han de fer front els MTA i per això s'han esmerçat molts recursos per evitar-lo. Les solucions per evitar el correu electrònic no desitjat han estat molt diverses i variades. Entre d'altres: – – – – –

Bloqueig d'IP Llistes negres Llistes blanques Llistes grises

Open Relay

Un servidor de correu rep el nom d'Open Relay quan permet l'enviament de correu electrònic de qualsevol que els hi enviï (tant anònimament o per altres mitjans). Els open relay actualment estan molt mal considerats perquè han estat usats indiscriminadament pels spammers i actualment és bastant corrent que els MTA no acceptin el correu que els arribi des de servidors 'open relay'. Molts dels ISP fan servir llistes negres de servidors open relay i alguns MTA es poden configurar fàcilment per fer-les servir

137

Gestió de xarxes d’àrea local

3.8.1.1 Sendmail Sendmail és el MTA més popular en sistemes Unix i el responsable de la majoria dels enviaments de correu electrònic d'Internet encara que històricament se li ha criticat la seva gran quantitat de problemes de seguretat (molts arreglats ràpidament) i el seu sistema de configuració que no és gaire senzill. Va néixer com a descendent del programa delivermail d'ARPANET i és un programa molt flexible que suporta moltes formes de transferència i entrega de missatges. La primera versió va ser creada al principi dels 80 per Eric Allman en la Universitat de Berkeley. Sendmail continua sent un dels MTA més populars de Internet però provablement això és degut a que és el MTA estàndard de moltes variants de Unix però està deicreixent notablement (en l'any 2001 es calculava que tenia al voltant del 42% del mercat, mentre que el 2007 s'hi comptava un 29'4%). Els programes que li estan traient més quota de mercat són sobretot el Microsoft Exchange Server, Exim i Postfix. Sendmail és un paquet complexe amb una gran quantitat de funcions que pot ser complicat, per un administrador que no hi estigui acostumat, de configurar. Entre els motius més importants hi ha: – –

La documentació del paquet no ha estat sempre actualitzada per reflectir-ne els canvis recents Molts programes de configuració de sendmail no sempre recullen les característiques recents i provoquen que sovint s'hagi de configurar a mà.

Les característiques més importants d'aquest MTA són la flexibilitat i la escalabilitat, el suport de múltiples protocols (SMTP, ESMTP, DECnet mail, Hylafax, QuickPage i UUCP) i a més suporta “milters” (capacitat de filtrat extern de correus electrònics) en cada una de les passes de la conversa.

138

Gestió de xarxes d’àrea local

3.8.1.2 Postfix Postfix (abans conegut com Vmailer o IBM Secure Mailer) és un MTA de programari lliure per l'encaminament i enviament de correu electrònic que es va crear per ser una alternativa més ràpida, segura, fàcil d'administrar i senzilla que Sendmail. Inicialment va ser programat per Wietse Venema en un dels centres d'IBM i continua programant-se activament. Això l'ha dut a ser el MTA per defecte en diferents distribucions de Linux i en Mac OS X. Les característiques més importants de Postfix són: – Suporta TLS (Transport Layer Security) – Pot delegar les polítiques de SMTP a un procés extern (Llistes grises i filtrat avançat) – Pot treballar amb dades de diferents bases de dades (Berkeley DB, CDB, DBM, LDAP, MySQL i PostgreSQL) – Pot treballar amb bústies de correu de diferents tipus: mbox, MailDir i dominis virtuals – Permet la reescriptura d'adreces, VERP, SMTP-AUTH via SASL – Suport de “milters” compatible amb SendMail – Funciona en diferents sistemes entre els que hi ha AIX, BSD, HP-UX, IRIX, Linux, MacOS X, Solaris, Tru64 i normalment amb qualsevol Unix o en qualsevol sistema que compleixi l'estàndard POSIX i els sockets BSD. Entre les característiques de les que es destaca més és la seva resistència davant els atacs més corrents (Buffer overflows) i la seva capacitat de tractar grans quantitats de correu electrònic. Postfix està desenvolupat en base a una xarxa de dimonis que cooperen entre ells. Cada un dels servidors només se n'encarrega d'una tasca concreta i s'executa amb el mínim de privilegis possibles perquè si es compromet la seva seguretat no es pugui comprometre tot el sistema. Només hi ha un procés amb privilegis d'administrador, el 'master', i pocs ('local', 'virtual', 'pipe') que actualment escriuen a disc o invoquen programes externs.

3.8.1.2.1 Configuració Tota la configuració resideix en el directori de configuració (normalment /etc/postfix) i es fa en els arxius 'master.cf' i 'main.cf' ● ●

main.cf guarda els paràmetres de configuració especifíca de Posftix master.cf defineix els diferents dimonis que s'execten de Postfix

En la pàgina web de Postfix hi ha un manuals i tutorials sobre la configuració ( per exemple el Postfix Basic Configuration )

139

Gestió de xarxes d’àrea local

3.8.1.3 Exim Exim (EXperimental Internet Mailer) és un MTA sota llicència GPL desenvolupat per la Universitat de Cambridge i funciona en la majoria dels sistemes Unix (també Linux) encara que hi ha compilacions per Windows. La primera versió va ser escrita per Philip Hazel el 1995 per fer-la servir en la Universitat de Cambridge i està basat en un antic MTA anomenat Smail. Exim segueix el model de disseny de Sendmail (monolític) que es considera menys segur que el model de creació en components encara que no s'han trobat problemes seriosos de seguretat a Exim en molts anys. Exim és altament configurable, i té característiques que altres MTA no tenen. Té eines per gestionar correu a través de polítiques de manera que l'administrador pot controlar qui pot enviar o reenviar correu a través del sistema. Té una gran flexibilitat en els camins que poden seguir els missatges segons el seu origen i per presentar funcionalitats per evitar spam, llistes de bloqueig basats en DNS, antivirus, control de relay, usuaris i dominis virtuals que poden ser configurats de forma relativament senzilla. Això el fa especialment interessant a l'hora de definir polítiques de correu. S'ha fet servir en llocs amb molt transit tractant milers de correu per hora de forma eficient. Exim ha estat dissenyat per entregar el correu electrònic immediatament i no té un gestor de cues (com qmail i Postfix) encara que pot encuar els missatges i això fa que tingui problemes de rendiment quan les cues es fan grans. (per tant no funciona gaire bé en entorns en els que els missatges s'han d'encuar abans d'entregar-los) Compta amb una bona documentació i exemples i és el MTA que es carrega per defecte en Debian GNU/Linux. Exim fa servir una peculiar forma d'anomenar les seves versions: El primer dígit només es canvia quan tota la documentació està actualitzada (això vol dir que 0.01 tindrà canvis en el programa però no és segur que estiguin documentats, quan ho siguin tindrem la versió 0.1)

3.8.1.3.1 Configuració La configuració es fa a través de un o més fitxers de configuració, que pot incloure la secció 'main' amb característiques genèriques i variables i seccions opcionals: – – – – – –

ACL: defineix com tractar les sessions SMTP Routers: inclou els elements que operen en les adreces Transport: com transmetre missatges al destí Retry: Quina política seguim per tornar a enviar els missatges que han fallat Rewrite: Com ho farà el sistema per reescriure les adreces dels missatges que passen Authenticators: característiques de SMTP AUTH

140

Gestió de xarxes d’àrea local

3.8.1.4 qMail qMail és un servidor de correu electrònic (SMTP) fet per sistemes Unix. Fa servir el format maildir per emmagatzemar missatges (un arxiu per missatge) perquè el problema mbox té problemes. qMail és distribuït com codi font i està escrit en llenguatge C Va ser desenvolupat per Daniel J Bernstein entre el 1995-98 perquè buscava una alternativa millor a Sendmail. Bernstein desitjava tenir una arquitectura senzilla ja que creia que com més senzill sigui el disseny més segur, estable i eficient serà la seva operació. El programa ha demostrat que això pot ser cert perquè no ha tingut pràcticament cap canvi des de la versió 1.03. El programa està estructurat en mòduls que s'executen de forma separada i cada un d'ells té funcions separades. És senzill reemplaçar qualsevol part de qMail amb un nou mòdul simplement mantenint-hi la interfície original. ● ● ● ● ●

qmail-smtpd: Aten a les transaccions SMTP entrants i posa els missatges a la cua qmail-queue: Gestiona la cua de missatges, emmagatzemant els missatges i invocant al procés d'enviament (qmail-send) qmail-send: Inicia la entrega de missatges en la cua als destinataris locals o remots qmail-rspawn / qmail-remote: Envien els missatges sortints als servidors SMTP on hi ha els destinataris qmail-lspawn / qmail-local: Distribueix els missatges entrants als seus destinataris locals

Entre les característiques de qMail: – També pot fer servir QMTP i QMQP a més de SMTP – Els missatges rebuts en cada servidor poden ser filtrats a voluntat a través d'arxius “.qmail”. Cada usuari pot tenir la seva pròpia regla de filtres/reenviaments o fins i tot executar algún programa o script que faci tasques arbitraries amb els missatges entrants. – A més de maildir es pot fer servir el format mbox – Les caselles poden estar associades a usuaris reals o virtuals i també es poden atendre simultàniament diversos dominis en un sol servidor. Es considera un MTA molt ràpid i segur

141

Gestió de xarxes d’àrea local

142

Gestió de xarxes d’àrea local

3.8.1.5 Microsoft Exchange Server Microsoft Exchange Server és un programari de col·laboració entre usuaris i missatgeria desenvolupat per Microsoft i forma part de la família de productes Microsoft Server ja que és un dels programes destinats a l'ús de servidors. Exchange es fa servir especialment per dotar de solucions a grans empreses coorporatives. Entre altres coses ofereix calendaris, contactes, correu electrònic i tasques compartides, suport per mòbils i accés a la informació a través de sistemes web i emmagatzemament d'informació. La primera versió pública de Exchange Server que es va conèixer va ser Exchange Server Beta 1 el 1995 i a partir d'aquella han anat apareixen noves versions afegint noves característiques ( MS Exchange Server 4.0, 5.0, 5.5, 2000, 2003 i 2007). Especialment destacable va ser l'aparició de filtres en la versió 2003 Exchange Server 2007 va sortir el 2006 i afegia integració de correu per veu, un millor sistema de recerca i suport als serveix web, millors opcions de filtrat i una nova interfície d'accés web per Outlook. Pot funcionar en plataformes de 64 bits a més de les de 32 bits però només en sistemes Windows Server. Es permet descarregar gratuïtament una versió de 32 bits de prova però les empreses que estan fent servir la versió de 32 bits estaran obligades a actualitzar el seu maquinari si volen poder actualitzar en el futur. Les principals millores segons Microsoft són: • Protecció anti-spam, antivirus, clustering amb replicació de dades, millores en la seguretat i el xifrat • Millora en els components de calendari, unificació de missatgeria (poden rebre correu, missatges de veu, fax, en una bústia), en la mobilitat (accepta comandes de veu) i en l'accés web. • Rendiment alt en plataformes 64 bits i escalabilitat • Un entorn de comandes amb un llenguatge d'scripts, i simplificació de l'entorn gràfic simplificat separant les tasques i l'encaminament. • Eliminada la mida màxima en la base de dades i s'han incrementat el número de grups disponibles i les base de dades per server (en funció del sistema que tinguem).

143

Gestió de xarxes d’àrea local

3.8.1.6 Filtres de correu Actualment cap administrador es pot permetre el luxe d'instal·lar un MTA sense tenir com a mínim filtres de correu per antivirus i algun filtre per detectar l'spam abans que arribi al destinatari. Els correus amb virus i els basura s'han convertit en una part molt important del correu que corre per Internet. La idea general és que el MTA passi tots els correus electrònics entrants cap a un programa de filtrat que s'encarregarà de passar-los per un antivirus i que hi faci una prova d'spam.

3.8.1.6.1 Antivirus: clamav La majoria dels desenvolupadors de programes antivirus ofereixen filtres que es poden incorporar en el nostre MTA tant si està en Windows com si està en Linux. Un dels antivirus més usats és el ClamAV (segurament perquè és gratuït) $ sudo apt-get install clamav-daemon

Generalment aquest paquet tindrà moltes dependències amb paquets de compressors perquè necessitem analitzar els fitxers que vinguin comprimits amb els formats més corrents. La configuració, per si la volem modificar, està a /etc/clamav. El servidor que s'encarregarà d'actualitzar periòdicament l'antivirus està a freshclam.conf i el podrem actualitzar en el moment en que vulguem executant la comanda $ sudo freshclam

3.8.1.6.2 AntiSpam: spamassassin D'entre els programes que serveixen per controlar l'spam el més popular és SpamAssassin. La seva instal·lació és relativament senzilla en la majoria de les distribucions Linux $ sudo apt-get install spamassassin

També podríem fer servir els protectors col·laboratius contra Spam: Pyzor i Razor. El que fan és calcular un hash del missatge i consulten a un servidor de Internet si corresponen a un mail en spam. $ sudo apt-get install pyzor razor

Podem refinar la configuració d'spamassassin amb els arxius de /etc/spamassassin i en especial en l'arxiu local.cf on hi podem posar les nostres preferències preferides.

144

Gestió de xarxes d’àrea local

3.8.1.6.3 Amavis-new Amavis-new és un programa que ens permetrà tenir només un port local obert en el MTA i que s'encarregarà de passar els correus que enviï el MTA per un antivirus i pel filtre antispam. $ sudo apt-get install clamav-new

Només hem de configurar el MTA perquè passi els missatges entrants per un port local. Per exemple amb Postfix només hem d'afegir les següents línies en el fitxer /etc/postfix/ main.cf (farem que els paquets entrants surtin pel port 10024) ... content_filter = smtp-amavis:[127.0.0.1]:10024

I definir el servidor de sortida i de reentrada en el /etc/master.cf (en aquest cas fem que retornin pel port 10025). S'ha d'anar amb compte de posar el mateix nom que hem posat en el main.cf al especificar el port de sortida: ... smtp-amavis unix n -o smtp_data_done_timeout=1200 -o disable_dns_lookups=yes

smtp

127.0.0.1:10025 inet n n - smtpd -o content_filter= -o disable_dns_lookups=yes -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000

La configuració de amavis-new està en el directori /etc/amavis/conf.d i està divida en diferents arxius: $ ls /etc/amavis/conf.d/ 01-debian 05-node_id 15-content_filter_mode 20-debian_defaults 25-amavis_helpers 50-user 05-domain_id 15-av_scanners 30-template_localization

En aquests arxius definim què volem que faci amavis i per tant és molt important que definim en el fitxer 15-content_filter_mode què hi volem fer. Per passar antivirus i antispam hem de deixar-lo com aquest: @bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \ $bypass_virus_checks_re); @bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \

145

Gestió de xarxes d’àrea local $bypass_spam_checks_re); 1;

Si analitzem el codi font del correu electrònic rebut podrem veure que hi hem passat el filtre antivirus i antispam: ... X-Quarantine-ID: <Th+kfR55wsvb> X-Virus-Scanned: Debian amavisd-new at Mixkin.xaviersala.local X-Spam-Flag: YES X-Spam-Score: 7.588 X-Spam-Level: ******* X-Spam-Status: Yes, score=7.588 tag=2 tag2=6.31 kill=6.31 tests=[ALL_TRUSTED=-1.8, BAYES_80=3, DRUGS_ERECTILE=0.493, HTML_MESSAGE=0.001, HTML_MISSING_CTYPE=2.518, HTML_SHORT_LENGTH=1.574, NO_REAL_NAME=0.961, UNDISC_RECIPS=0.841] Received: from Mixkin ([127.0.0.1]) by localhost (casa.xaviersala.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th+kfR55wsvb for <xavier@Mixkin>; Wed, 16 Apr 2008 23:30:58 +0200 (CEST) ...

Generalment no s'aconsella que els correus spam no es deixin passar per si de cas el filtre antispam ha donat falsos positius. Per fer-ho hem de deixar que els deixi passar modificant la configuració per D_PASS a 20-debian-defaults $final_virus_destiny $final_banned_destiny $final_spam_destiny $final_bad_header_destiny

= = = =

D_DISCARD; D_BOUNCE; D_PASS; D_PASS;

En cas contrari els trobarem a /var/lib/amavis/virusmails en format comprimit. Aquesta és la carpeta en la que van els correus que estan en “quarentena” És important que el domini de recepció estigui correcte perquè alguns usuaris informen que si no ho és el filtre antispam té tendència a no marcar els missatges.

146

Gestió de xarxes d’àrea local

3.8.2 Bústies de correu Actualment s'estan fent servir dos protocols per comunicar-se amb bústies de correu: POP3 i IMAP i ambdós poden establir connexions xifrades per evitar els problemes dels sniffers. L'avantatge de IMAP (Internet Messange Access Protocol) sobre POP3 (Post Office Protocol) està en que IMAP ens permet consultar el correu electrònic des de diferents ordinadors perquè no l'hem de descarregar sinó que es manté en el servidor. Aquest avantatge ha fet que actualment estigui desplaçant els servidors de POP del mercat. És per això que els servidors de bústies de correu més importants fins i tot incorporen el nom IMAPD al seu nom a pesar de continuar oferint suport per POP. ( Courier IMAPD, Cyrus IMAPD, etc..) Mentre POP3 funciona descarregant els missatges que hi ha a la bústia des de la darrera vegada que ens hi varem connectar. (podríem no descarregar-los però després quan busquéssim els nous ens els tornaria a descarregar). Això és així perquè POP va ser pensat per fer-se servir en mode “offline” ja que va ser dissenyat en el moment en que la majoria dels usuaris es connectaven a Internet via mòdem i seguien un procés molt semblant a: connectar, descarregar correu, desconnectar, llegir correu. IMAP va ser dissenyat per poder treballar en el servidor de correu sobretot “online” (encara que pot fer-ho d'altres formes) entre les característiques més interessants de IMAP inclouen: – – – – –

Ser totalment compatible amb els estàndards de missatgeria: MIME Permet l'accés des de diferents ordinadors al correu Permet suport per connexions en mode “online”, “offline” i “desconnectat” Permet accés múltiple a les carpetes compartides Els clients de correu no necessiten saber com està implementada la bústia per treballar-hi ja que inclou mecanismes per crear, esborrar i canviar el nom de les bústies, recerca de missatges, modificació d'estat, etc..

147

Gestió de xarxes d’àrea local

3.8.2.1 Courier IMAPD

148

Gestió de xarxes d’àrea local

3.8.2.2 Cyrus IMAPD

149

Gestió de xarxes d’àrea local

3.8.2.3 Dovecot Un avantatge de Dovecot sobre els altres dos és que suporta els dos sistemes actuals d'emmagatzemament de correu electrònic: Maildir i mbox. •

•

Mbox és bàsicament un sol arxiu en el que els correus estan concatenats un rere l'altre. Mentre això és fantàstic per sistemes petits, no és gaire eficient per llegir, reordenar els missatges. També té problemes de bloquejos de fitxers. (els fitxers de mbox normalment es posen a /var/mail/ Maildir es basa en carpetes i estructures de fitxers. Els diferents missatges es guarden en fitxers diferents. Normalment la carpeta es crea en el directori de l'usuari.

La meva tria és fer servir Maildir, per tant a més de configurar Dovecot també hauré d'informar al MTA (que és Postfix) de que ha de posar els missatges en el lloc adequat que serà dins de la carpeta de cada usuari 1. La primera cosa és instal·lar-lo: $ sudo apt-get install dovecot-imapd

Donada la poca seguretat dels servidors de correu farem la instal·lació perquè només es permetin connexions segures a través de SSL, o sigui imaps que necessitem fer unes passes més: 2. Com que no tinc massa necessitats i el certificat només és per mi, em crearé el meu propi certificat per poder fer connexions segures (hem de respondre algunes preguntetes de res): $ openssl req -new -x509 -nodes -out public.pem -keyout private.pem days 999999 Generating a 1024 bit RSA private key ..++++++ ..................++++++ unable to write 'random state' writing new private key to 'private.pem' ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Girona Locality Name (eg, city) []:Cabanes Organization Name (eg, company) [Internet Widgits Pty Ltd]:Maquinotes Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []: Email Address []:maquinotes@falsa.com

Després les copiaré a un lloc que el servidor les pugui abastar. Per exemple a: $ sudo cp public.pem /etc/ssl/certs/public.pem $ sudo cp private.pem /etc/ssl/private/private.pem

Ara em cal editar /etc/dovecot/dovecot.conf i posar-hi el mailbox que volem fer servir i els certificats i treure els altres protocols de la línia protocols:

150

Gestió de xarxes d’àrea local

protocols = imaps ssl_disable = no ssl_cert_file = /etc/ssl/certs/public.pem ssl_key_file = /etc/ssl/private/private.pem ... default_mail_env = maildir:/home/%u/Maildir/ ...

Ara com que fem servir Maildir necessitem que el MTA sàpiga on deixar el correu dels usuaris, per defecte Postfix fa servir mbox i els sol posar a /var/mail/usuari i com que volem fer servir Maildir hem d'editar la configuració de Postfix edito el /etc/posfix/main.cf i hi posem la carpeta en la que volem que s'acumulin els missatges (en el meu cas l'original nom Maildir): ... home_mailbox = Maildir/ ...

Per acabar la instal·lació només s'ha de reiniciar tot plegat: $ sudo /etc/init.d/postfix restart $ sudo /etc/init.d/dovecot start

Evidentment a cada usuari se li ha de crear la carpeta Maildir perquè se li acumulin allà els missatges. Per això el millor sol ser crear la carpeta dins de /etc/skel perquè que ja estigui creada automàticament per cada usuari nou.

151

Gestió de xarxes d’àrea local

3.8.3 Webmail Les connexions permanents a Internet van fomentar l'aparició d'una nova forma de llegir el correu electrònic que ja no requeria l'ús d'un programa client ni que l'usuari hagués de fer cap tipus de configuració per fer-lo servir: el webmail Un webmail és un programa que corre sota un servidor web i que permet accedir al correu electrònic instal·lat en un servidor (normalment IMAP o POP) que generalment està instal·lat en la mateixa xarxa que el client. D'aquesta forma es permet llistar, desplegar, llegir correu electrònic amb els mateixos avantatges que oferia IMAP (podem connectar-nos-hi des d'un altre ordinador) només tenint un navegador web i a més és independent de la plataforma en la que estiguem. Si un sistema operatiu té navegador podrem accedir al correu electrònic. Moltes empreses ofereixen serveis de correu electrònic d'aquest tipus: Google (gmail), Yahoo (Yahoo mail), Microsoft (Windows Live Hotmail), etc..

Hi ha molts programes d'aquest tipus que podem instal·lar en els nostre servidor web. Però entre els que destacaré: ● ● ● ● ● ●

Squirrelmail (http://www.squirrelmail.org/) Horde (www.horde.org) OpenWebMail (openwebmail.org/openwebmail/) RoundCube (http://www.roundcube.net/) Zimbra (http://www.zimbra.com/) Basilix (http://basilix.sourceforge.net/index.php?lang=en)

L'avantatges més gran d'aquests sistemes és que al córrer sota servidors web en tenim prou amb que el servidor web suporti el llenguatge amb el que ha estat programat el webmail i per tant a més de ser multiplataforma pels clients també ho pot ser com a servidor.

152

Gestió de xarxes d’àrea local

3.8.3.1 SquirrelMail El procés d'instal·lació és relativament simple però pot variar en funció de la distribució que tinguem. En l'exemple d'aquí a sota farem servir Ubuntu com a exemple. Per poder fer la configuració d'Squirrrelmail necessitem almenys tenir: • • •

Un MTA instal·lat (Postfix, Sendmail, ...) Un servidor de IMAP (Courier, Dovecot, ... ) Apache configurat amb el plugin de PHP

La configuració d'squirrelmail està integrada en el paquet o sigui que podem instal·lar-lo i configurar-lo simplement fent: $ sudo apt-get install squirrelmail $ sudo squirrelmail-configure

Entre les coses més importants que ens demanarà hi ha on són els servidors: 2. Mail Server Settings ... A. Update IMAP Settings B. Update SMTP Settings ...

: localhost:143 (other) : localhost:25

També hem de dir-li a l'Apache que tenim el nou programa instal·lat. Per fer-ho ens aprofitem del virtualhost que ve per defecte en el paquet d'Ubuntu. El copiem i l'activem: $ sudo cp /etc/squirrelmail/apache.conf /etc/apache2/sites-available/squirrelmail $ a2ensite squirrelmail $ sudo /etc/init.d/apache2 restart

I comprovem que funciona http://localhost/squirrelmail

153

Gestió de xarxes d’àrea local

3.8.4 Altres 3.8.4.1 Fetchmail Fetchmail és un programa que té per finalitat poder descarregar el correu electrònic de diferents comptes per tenir-lo centralitzat. Es tracta d'un programa molt útil per centralitzar el nostre correu electrònic quan tenim molts comptes diferents en servidors diferents. La seva configuració és relativament simple. Generem un fitxer .fetchmailrc dins del nostre directori i dins hi especifiquem les dades dels nostres comptes poll pop.telefonica.net proto pop3 user "pepet", with password "meravella!", is pepet here; poll pop.gmail.com proto pop3 user "pepet@gmail.com", with password "westi4l!", is pepet here options ssl;

Després només hem d'iniciar el programa cada vegada que volem que es descarreguin els correus o bé deixar-lo com a programa resident que vagi baixant els correus periòdicament: $ fetchmail $ fetchmail -d 6000

En el cas de que es configuri el compte per l'administrador, podrem definir a quin usuari han d'anar els correus.

3.8.4.2 Procmail Es tracta d'un programa de classificació de correu electrònic a partir de regles. El que hem de fer és que el nostre MTA en comptes d'entregar el correu directament a la bústia el passi al Procmail. Per exemple en Postfix la configuració requereix que especifiquem en l'arxiu main.cf el següent: ... mailbox_command = procmail -a "$EXTENSION" ...

Un cop configurat correctament el MTA cada usuari podrà fer les seves pròpies regles definint el seu fitxer .procmailrc. Com que la configuració pot arribar a ser una mica complexa, es recomana fer servir algun sistema que ens permeti guardar-la en fitxers individuals: #### Secció de VARIABLES ################## SHELL=/bin/sh ## LOG=" ## " ## VERBOSE=yes MAILDIR=$HOME/Maildir DEFAULT=./ PMDIR=$HOME/Procmail

154

Gestió de xarxes d’àrea local LOGFILE=$PMDIR/pmlog #### Fi de VARIABLES #### #### Secció de PROCES ###################### INCLUDERC=$PMDIR/rc.llistes INCLUDERC=$PMDIR/rc.logs INCLUDERC=$PMDIR/rc.spam INCLUDERC=$PMDIR/rc.jo INCLUDERC=$PMDIR/rc.utrescu #### Fi de PROCESS ####

En l'exemple definim les regles de filtrat en el directori $HOME/Procmail i per tant només les hem d'especificar: ###### pepet@tomata.net :0 *^TO_ .*pepet@tomata\.net .INBOX.pepet/

#########

:0 *^Cc:.*pepet@tomata\.net .INBOX.pepet/ ##### pepet@tomata.org ########## :0 *^TO_ .*pepet@tomata\.org .INBOX.pepet/ :0 *^Cc:.*pepet@tomata\.org .INBOX.pepet/ # In the next line, note the missing 2nd colon (:), which means "do not use a lockfile" ###### SCRIBUS ######### :0 * ^Subject:.*\[Scribus\] .INBOX.Scribus/ # In the previous line, note the leading dot (.) and trailing slash (/) ###### LLISTA CUTRE ######## :0 * ^Subject:.*\[Cutre\] .INBOX.Cutre/ ###### LLISTA COMICS ######### :0 *^Sender:.*comis@googlegroups.com .INBOX.Comis/

###### SPAMASSASSIN ######### :0 * ^Subject:.*\*SPAM\* .Trash/ ###### pepet@carai.net :0 *^TO_ .*pepet@carai\.net .INBOX.carai/

#########

:0 *^Cc:.*pepet@carai\.net

155

Gestió de xarxes d’àrea local .INBOX.carai/

156

Gestió de xarxes d’àrea local

3.9 Servidors de noms 3.9.1 DNS 3.9.1.1 Bind BIND (Berkeley Internet Name Domain) is the most commonly used DNS server on the Internet, especially on Unix-like systems, where it is a de facto standard. Supported by Internet Systems Consortium. BIND was originally created by four graduate students with CSRG at the University of California, Berkeley and first released with 4.3BSD. Paul Vixie started maintaining it in 1988 while working for DEC. A new version of BIND (BIND 9) was written from scratch in part to address the architectural difficulties with auditing the earlier BIND code bases, and also to support DNSSEC (DNS Security Extensions). Other important features of BIND 9 include: TSIG, DNS notify, nsupdate, IPv6, rndc flush, views, multiprocessor support, and an improved portability architecture. It is commonly used on Linux systems.

157

Gestió de xarxes d’àrea local

3.10.1.2 Djbdns The djbdns program is a simple and security-aware DNS implementation created by Daniel J. Bernstein due to his frustrations with repeated BIND security holes. There is an as-yet-unclaimed $500 prize (see External Links, below) for the first person to find a privilege escalation security hole in djbdns. There is a known security problem where an attacker can send a specially crafted TCP packet to force dnscache to restart (losing its cache). Since this attack is a denial of service attack and not a privilege escalation attack, it does not qualify for the prize. Third party fixes for the problem are available here and here. As of 2004, it was the second most popular DNS server.[1]

158

Gestió de xarxes d’àrea local

3.10.1.3 PowerDNS PowerDNS is a versatile DNS server, written in C++ and licensed under the GPL. It runs on most Unix derivatives and on Microsoft Windows. PowerDNS features a large number of different backends ranging from simple BIND style zonefiles to relational databases and load balancing/failover algorithms. A DNS recursor is also included as a separate program. Anecdotal evidence suggests that around 10% of all world domains are powered by this nameserver, 49% of the German .DE zone and 7% of the .NET zone. PowerDNS is a product of the Dutch company PowerDNS.COM BV, with numerous contributions from the Open Source community. The principal author is Bert Hubert.

159

Gestió de xarxes d’àrea local

3.10.1.4 Microsoft DNS The Domain Name System support in Microsoft Windows NT, and thus, its derivatives Windows 2000, Windows XP, and Windows Server 2003, comprises two clients and a server. Every Microsoft Windows machine has a DNS lookup client, to perform ordinary DNS lookups. Some machines have a Dynamic DNS Update client, to perform Dynamic DNS Update transactions, registering the machines' names and IP addresses. Some machines run a DNS server, to publish DNS data, to service DNS lookup requests from DNS lookup clients, and to service DNS update requests from DNS update clients. The server software is only supplied with the server versions of Windows.

160

Gestió de xarxes d’àrea local

3.9.2 WINS

161

Gestió de xarxes d’àrea local

3.10 Proxies Un servidor de proxy és un ordinador que ofereix un servei que permet a un client fer una connexió indirecta a un altre servei. El client es connecta al servidor de proxy i li fa la petició. El servidor de proxy pot respondre de dues formes: connectant-se al destinatari o bé servint la resposta des de la seva caché. Un servidor de proxy també pot actuar com ho fan els tallafocs.

162

Gestió de xarxes d’àrea local

3.10.1 Tipus de proxies 3.10.1.1 Proxies de web Un dels proxies més corrents són els proxies web. Donen una caché propera de les pàgines i fitxers que formen part d'una web remota. Això fa que els clients més propers aconsegueixin accés a la web d'una forma més ràpida. Quan es rep una petició d'un client d'una web, el servidor primer mira si el destí està dins de la seva caché. Si hi és retorna el document de la caché. Si no hi és el demana al destí, i en guarda una còpia a la caché. Per la caché normalment es fa servir algun algorisme d'expiració per determinar les pàgines que s'han d'esborrar, segons el temps que fa que hi són, la seva mida o el seu historial d'accessos. Els més usats solen ser: • •

Least Recent Used (LRU): elimina els més vells Least Frequently Used (LFU): elimina els que es demanen menys

Els proxies web poden també: - Filtrar el contingut de les webs. Alguns programes de censura – que pretenen bloquejar contingut web perillós – estan implementats en proxies web. - Alguns altres reformaten les webs per algun objectiu en concret. ( ex. Skweezer formata les webs perquè es vegin bé en mòbils) - També es poden fer servir per interceptar virus CGI Proxies Un cas especial de proxies són els “CGI proxies”. Aquest són llocs que permeten accedir a altres llocs a través d'ells. http://www.hidemyass.com/ http://anonymouse.ws/ http://webwarper.net/ http://www.proxyforall.com/ Es poden fer servir per accedir a llocs web que algun proxy d'empresa ha bloquejat o per fer connexions anònimes a una web determinada.

163

Gestió de xarxes d’àrea local

3.10.1.2 Proxys transparents Moltes empreses fan servir proxys per obligar als seus treballadors a seguir les polítiques d'empresa (censorware) o donar seguretat i serveis de caché. Generalment el proxy no és transparent a les aplicacions dels clients: s'ha de configurar el programa per fer servir el proxy, per tant algú simplement reconfigurant el programa pot saltar-se el proxy (si no és que el proxy és el que fa NAT cap a Internet). Un proxy transparent és una combinació d'un proxy amb NAT per compartir la connexió a Internet per incrementar la seguretat. Tot i això són molt més difícils de configurar que els proxys normals. També es poden implementar amb dispositius de xarxa que intercepten les peticions dels usuaris i les redirigeixen als servidors de proxy-caché (sense haver de configurar res). Les peticions es solen identificar per port. Els proxies transparents generen molta controvèrsia en la comunitat d'Internet, ja que violen el principi de comunicació end-to-end del disseny TCP.

3.10.1.3 Open Proxies Un proxy obert és el que accepta connexions des de qualsevol IP i permet connectar a qualsevol recurs d'Internet. L'abús dels open proxies ha fet que estiguin molt mal vistos perquè són origen de molt de l'spam que corre per Internet. Per això molts administradors han pres mesures per evitar que s'hi connecti ningú des dels proxies oberts.

3.10.1.4 Reverse Proxies Un reverse proxy està instal·lat al voltant de servidors web. Tot el transit que ve des d'Internet amb destí a un dels servidors web passarà a través d'un servidor web. Hi ha moltes raons per instal·lar reverse proxies: • • • • •

Seguretat: El proxy és una capa addicional de defensa pels servidors web. Encriptació / Acceleració SSL: Quan es creen servidors segurs, la encriptació SSL no es fa des del servidor web sinó des del proxy. Distribució de càrrega: Poden repartir les peticions de connexió entre els diferents Servir contingut estàtic: Poden descarregar els servidors web de peticions, guardant-ne el contingut estàtic. Compressió: Els servidor proxy pot optimitzar i comprimir el contingut per incrementar el temps de lectura.

3.10.1.5 Split proxies Un split proxy són un parell de proxies instal·lats al voltant de dos ordinadors. Poden comunicar de forma més eficient perquè són part del mateix programa. Ideal per compartir dades a través d'un enllaç lent. Pot fer servir compressió per incrementar el rendiment Server1 > Proxy1(comprimeix/envia)>....> Proxy 2(descomprimeix/envia)>Server2

Ex. Google's Web Accelerator

164

Gestió de xarxes d’àrea local

3.10.1.6 Riscos dels proxies A part dels problemes clàssics: – Les entrades del proxy poden no haver-se actualitzat des del darrer cop que es va accedir a la pàgina – Impedeixen l'ús de determinats serveis avançats a través d'alguns ports i protocols I tenim que: –

–

L'administrador del proxie podria aconseguir les contrasenyes d'accés als llocs privats si la informació hi passa sense xifrar. O sigui que podria guardar les contrasenyes a més de la pàgina. El proxy es pot fer servir per monitoritzar activitat dels usuaris que el fan servir de manera que es pugui arribar a vulnerar la intimitat d'algunes persones.

165

Gestió de xarxes d’àrea local

3.10.1.7 Programari de proxy popular • • • • • • • • • • • •

Squid caché: proxy web de Linux Apache HTTP Server: es pot configurar per actuar com un servidor proxy Wingate: proxy server amb NAT per redireccionar transit de hosts Windows Privoxy és un proxy lliure de codi obert amb característiques de privacitat AnalogX Proxy – Proxy molt petit que permet filtrar HTTP, HTTPS, POP3, SMP, NNTP, FTP i Socks4 parcialment Socks5 FreeProxy The elhttp server -- Servidor proxy lleuger per Windows i Unix Microsoft Internet and Security and Acceleration Server (Windows 2k o 2k3) CGIProxy – Open CGI Proxy de codi obert Sun Java System Web Proxy Server. Tor. Proxy basat en anonimització de comunicacions a Internet. Proxomitron – Proxy configurable que permet reescriure pàgines web en el moment.

Altres: Tutorial servidor Proxy (http://compnetworking.about.com/cs/proxyservers/a/proxyservers.htm) Proxys gratuïts (http://dmoz.org/Computers/Internet/Proxying_and_Filtering/Hosted_Proxy_Services/Free/Proxy_Lists/ )

166

Gestió de xarxes d’àrea local

3.10.2 Squid Aquest proxy es pot descarregar des de ( www.squid-cache.org) encara que normalment amb el paquet de la distribució en farem prou. Squid és un servidor proxy d'alt rendiment que ha estat desenvolupat des de fa anys i que és molt popular en sistemes Unix i derivats. Destaca per ser molt robust, confiable i versàtil i es distribueix sota GPL. Entre altres coses pot funcionar com a Proxy i caché de contingut dels protocols HTTP, FTP, GOPHER i WAIS, Proxy de SSL, caché transparent, WWCP, acceleració HTTP, caché de consultes DNS i altres com filtrat de contingut i control d'accés per IP i per usuari. Squid consisteix en un programa principal que fa de servidor, un programa per fer recerques en servidors DNS, programes opcionals per reescriure sol·licituds i fer identificació i algunes eines per l'administració i pels clients. Al iniciar Squid s'inicien una sèrie de processos de recerca en servidors DNS per reduir la quantitat de temps d'espera en les recerques DNS

3.10.2.1 Instal·lació Per instal·lar un proxy necessitem que el servidor que el contingui tingui adreça estàtica. Això és degut a que hem de fer que tots els clients redirigeixin el transit cap a ell. Per comprovar que tenim una adreça estàtica editem l'arxiu /etc/network/interface i ens assegurem que està així (important que tingui una línia gateway): # The loopback network interface auto lo iface lo inet loopback # Interficie primària auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1

I reiniciem la xarxa si cal. # /etc/init.d/networking restart

Abans d'instal·lar un proxy cal que tinguem algunes idees clares: Com serà la caché? Squid consumeix i obre alhora molts fitxers i sockets per atendre a les peticions dels usuaris per això pot passar que no tinguem prous filedescriptors i això provocarà que es crei una denegació de servei. Podem veure els filedescriptors amb: # ulimit -a proxy core file size

(blocks, -c) 0

167

Gestió de xarxes d’àrea local data seg size (kbytes, -d) unlimited max nice (-e) 20 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited max rt priority (-r) unlimited stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

La que ens interessa és la línia que diu 'open files' i normalment els haurem d'incrementar # ulimit -n 8192 proxy # echo 8192 > /proc/sys/fs/file-max

I també ho hauríem d'afegir a /usr/include/bits/typesizes.h on hi posarem: #define _ _ FD _ SETSIZE 8192

Quina quantitat de disc destinarem al proxy Això ho haurem de decidir nosaltes en funció de la capcitat de caché que volguem guardar però es recomana no posar-lo en un disc RAID perquè Squid funciona millor treballant sense On guardarem aquesta caché? En un directori o en una partició? El millor és una partició a part (un deu per cent més gran que la caché que tinguem prevista) i muntada ambb un sistema d'arxius amb 'noatime' i 'rw'. No cal comprovar la integritat de la caché o sigui que millor el que sigui més ràpid. Millor particions diferents i com més ràpids siguin els discs durs millor. Amb quin sistema d'arxius funcionarà Squid suporta diversos models de caché: ● ufs o el model que ve por defecte. ● aufs el mateix que l'anterior però asíncron i arranca múltiples dimonis squid per lectura, escriptura, modificació, opertura i esborrat del sistema d'arxius de la caché. És molt més ràpid però consumeix molts més recursos. ● diskd, semblant a l'anterior però només amb un sol dimoni ● coss és el que té més rendiment ja que fa servir un sistema d'arxius especial però està sense afinar totalment ● null no fa cap caché. Quina quantitat de memòria RAM hi destinarem? Dependrà de si aquest ordinador té altres serveis activats o no Per quina xarxa s'accedirà a squid?

168

Gestió de xarxes d’àrea local El millor és que si tenim més d'una targeta de xarxa hi fem bonding per evitar els colls d'ampolla que s'hi puguin produir Instal·lem Squid des dels repositoris d'Ubuntu (però la seva compilació en cas de necessitat no és gaire complicada): # apt-get install squid

3.10.2.2 Configuració Veurem que s'ha creat un arxiu especial per squid en el directori /etc. La configuració bàsica està a /etc/squid/squid.conf: D'aquest arxiu són especialment importants el port en el que el proxy estarà escoltant que està definit per la directiva http_port. Per defecte escolta el 3128 i normalment no l'haurem de canviar: ... http_port 8080 ...

També són importants les línies que defineixen com i on en servidor desarà els fitxers dels usuaris: cache_mem 16 MB #memoria que farà servir cache_dir ufs /var/spool/squid 100 16 256#esto es la cache

Cache_mem és la directiva que defineix quina quantitat de memòria RAM es reservarà Squid per les seves coses i cache_dir defineix quin sistema de fitxers farem servir, on és, la mida en KB, el número de directoris i de subdirectoris També és important definir amb quin usuari s'executarà squid (en el nostre cas proxy) i a qui se li enviarà un correu quan les coses no vagin bé cache_effective_user proxy cache_effective_group proxy cache_mgr administrador@proxy.com

Les directives d'acceleració d'httpd: httpd_accel_host virtual httpd_accel_port 80 httpd_accel_single_host off httpd_accel_with_proxy on httpd_accel_uses_host_header on

I sobretot les llistes ACL que determinen els permisos d'accés al proxy acl nostra_xarxa src 192.168.1.0/24 192.168.2.0/24 http_access allow nostra_xarxa

Es poden fer regles tan complexes com vulguem però sempre després d'haver definit les xarxes a través de ACL i després hem de definir si poden o no poden passar. En

169

Gestió de xarxes d’àrea local l'exemple anterior permetem que la gent de la nostra xarxa pugui fer servir el proxy i la resta del món no: acl xarxa1 src 192.168.1.0/24 acl xarxa2 src 192.168.2.0/24 acl all src 0.0.0.0/0.0.0.0 http_access http_access http_access http_access

allow localhost allow xarxa1 allow xarxa2 deny all

Les possibilitats són moltes, podem podar permisos a certes hores, fer que s'identifiquin amb usuari i contrasenya, etc.. També podem carregar les regles a partir de una llista d'adreces IP que tinguem en un fitxer: acl permesos src "/etc/squid/acl/permesos.acl"

En la que hi posarem el nom de l'ordinador o bé la IP que volem deixar passar: 192.168.0.104 192.168.0.12 mariano.empresa.com l01.empresa.com servidor.empresa.com

O una llista de dominis web acl dominisprohibits dstdomain "/etc/squid/acl/proohibits.acl"

Que n'hi ha prou que sigui de la forma: pepet.com sexo.com youtube.com www.locas.com .domini.com

Podem filtrar l'accés per hores, per exemple per permetre l'accés de 23:00 a 8:00 acl Restringir time MTWHF 08:00-23:00 http_access deny !RestringirPorHoras ... http_access deny all

Podem bloquejar arxius de diferents tipus o pàgines que continguin paraules simplement especificant regles com: acl paraulesNo url_regex "/etc/squid/acl/paraulesprohibides.acl" acl fitxersNo urlpath_regex -i "/etc/squid/acl/fichersprohibits.acl" http_access deny paraulesNo http_access deny fitxersNo

170

Gestió de xarxes d’àrea local I els fitxers han de ser com aquests # Extensions de fitxers prohibides .mp3$ .avi$ .jpeg$ mp3 avi jpeg #paraules prohibides porno juego chat video peli

O fins i tot podem prohibir l'accés al proxy als usuaris de Internet Explorer o el Messenger: # Prohibeix Internet Explorer acl NoIE browser MSIE http_acces deny NoIE # Prohibeix messenger acl msnNo req_mime_type ^application/x-msn-messenger$ http_access deny msnNo

Però si tenim Windows el millor serà deixar-los anar a Windowsupdate acl NoIE browser MSIE # Permitir windowsupdate con IE acl windowsupdate dstdomain .windowsupdate.com acl windowsupdate dstdomain .microsoft.com acl windowsupdate dstdomain .public-trust.com acl windowsupdate dstdomain .windows.com acl windowsupdate dstdomain .webiqonline.com acl windowsupdate dstdomain 207.46.224.158 acl windowsupdate dstdomain .msn.com always_direct allow windowsupdate http_access deny NoIE http_access allow windowsupdate

En el fitxer /var/log/squid/access.log tindrem registrat l'accés que facin els usuaris al proxy Podem comprovar que la configuració està ben feta amb: # squid -k parse

I crear la caché amb: # squid -k

171

Gestió de xarxes d’àrea local Proxy transparent Per convertir el proxy en un de transparent necessitem modificar el tallafocs perquè redirigeixi les peticions que els arribin al proxy. Això amb un sistema en Linux és relativament senzill fent servir iptables iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT – to-port 8080

Per fer que s'inicii automàticament quan s'arrenqui la màquina ho posem en un arxiu per exemple firewall.sh i: # cp firewall.sh /etc/init.d # update-rc.d firewall.sh defaults

Només l'hem de definir com a porta d'enllaç dels clients i tots passaran a través de proxy sense adonar-se'n...

172

Gestió de xarxes d’àrea local

3.10.2.3 Filtres de continguts Actualment donada la dificultat de filtrar els continguts als que accedeixen els usuaris a través de llistar els noms de les pàgines webs els proxys es solen acompanyar amb filtres de continguts

3.10.2.3.1 SquidGuardian La instal·lació de SquidGuardian no pot ser més senzilla perquè es troba en els repositoris d'Ubuntu. També necessitarà un servidor de pàgines web: # apt-get install squidguardian apache2

La configuració està a /etc/squid/squidGuard.conf Una de les coses que hem de fer es informar a squid del lloc en el que es troba SquidGuardian. Editem el fitxer de configuració d'squid i canviem la línia 'redirect_program' i ens assegurem que les xarxes que passaran pel proxy poden arribar al destí: ... redirect_program /usr/bin/squidGuard –c /etc/squid/squidGuard.conf ... acl xarxes src 192.168.0.0/24 192.168.1.0/24 http_access allow xarxes ... visible_hostname localhost

Un cop ho tenim tot fet només hem de començar a fer la configuració. Per exemple crearem una llista de dominis a bloquejar. Per exemple bloquejarem els dominis que parlen de com es planten tomates: # mkdir /var/lib/squidguard/db/tomates # joe /var/lib/squidguard/db/tomates/dominis Plantar-tomates.cat tomatoes.com viscalatomata.net pambtomata.cat

Falta donar permisos al proxy perquè pugui accedir als fitxers de base de dades: # sudo chown -R proxy:proxy /var/lib/squidguard/db

Editem l'arxiu de configuració /etc/squid/squidGuard.conf i esborrem tot el que hi ha més enllà de logdir /var/log/squid i hi posem: dest tomates { domainlist tomates/dominis } acl { default { pass !tomates redirect http://192.168.1.2/block.html }

173

Gestió de xarxes d’àrea local }

El redirect serveix perquè en comptes de les pàgines afectades els hi surti una pàgina definida per nosaltres. (ens hauríem d'assegurar de que aquesta pàgina existeixi) Abans que la cosa rutlli hem de compilar les base de dades de dominis # squidGuard –C all

I només falta reconfigurar el proxy # /etc/init.d/squid restart # squid -k reconfigure

3.10.2.3.2 DansGuardian DansGuardian permet filtrar continguts de moltes formes: per URL i domini (fent-ne llistes), per frases (comprovarà que no hi hagi frases associades a la pornografia, etc..) , imatges, tipus de fitxers, extensions de fitxers, o limitació POST (limitem l'enviament) Es poden definir excepcions, es pot fer servir tunnels SSL i es pot definir la forma en que els usuaris poden identificar-se en el nostre sistema La instal·lació de DansGuardian no pot ser més senzilla perquè es troba en els repositoris d'Ubuntu... # apt-get install dansguardian

Editem la configuració perquè sàpiga que tenim l'squid instal·lat (tota la configuració està a /etc/dansguardian/ ): # UNCONFIGURED filterip = filterport = 8080 proxyip = 127.0.0.1 proxyport = 3128

Podem editar la configuració dels filtres simplement editant algun dels arxius # ls /etc/dansguardian bannedextensionlist bannediplist bannedmimetypelist bannedphraselist bannedregexpurllist bannedsytelist banneduserlist exceptioniplist exceptionphraselist exceptionsitelist exceptionurllist exceptionuserlist exceptionvirusextensionlist

174

Gestió de xarxes d’àrea local exceptionvirusmimetypelist exceptionvirussitelist exceptionvirusurllist

Un cop fet només hem de reiniciar-ho tot i llestos... # /etc/init.d/dansguardian stop # /etc/init.d/squid restart # /etc/init.d/dansguardian start

Ara només hem de posar el client perquè faci les peticions al proxy al port 8080 i si intentem anar a una de les webs protegides ens en mostrarà la prohibició.

3.10.2.4 Delay Pools Squid és un dels millors proxy-caché que existeixen per HTTP, és estable, fàcil de configurar i amb algunes precaucions bàsiques relativament segur. La majoria de la gent que instal·la un proxy-caché és perquè volen reduir la càrrega de treball que el trànsit habitual fa sobre la connexió a Internet. Tenir una caché redueix aquest transit però no soluciona el problema perquè si un usuari decideix que es vol baixar un DVD de 700 MB segurament aquest DVD no estarà en la caché o sigui quees estarà ocupant el canal de sortida durant molta estona afectant als altres. O sigui que un sol usuari pot provocar una baixada de rendiment de la connexió a Internet de tots els usuaris d'una xarxa i el mateix passarà quan arranqui programes de P2P. Què fer? 1. Identificar el problema: si són un conjunt d'usuaris potser és el moment d'ampliar l'ample de banda. 2. S'ha d'identificar el coll d'ampolla: s'ha d'estar segur que el problema no està en la configuració de la nostra LAN 3. Revisar la configuració d'Squid 4. Si el programa és de P2P la solució no està només en un proxy sinó polítiques agressives de tallafocs i un proxy no transparent amb Delay Pools Els Delay Pools són una eina per controlar l'ample de banda del proxy sense penalitzar els objectes que venen des de la caché. La idea és regular el consum d'ample de banda sense que ningú pugui cometre abusos i consumir tot l'ample de banda de la xarxa impedint-ne l'ús o limitant-lo als altres. Aquest control es pot dur a terme de diferents formes: a partir de la màquina origen, l'adreça, la pàgina de destí o el tipus de transferència. Només un exemple de les coses que s'hi poden fer: a) Limitar la descàrrega dels fitxers wmv que siguin més grans de 1 Mb a 8 k/s delay_pools 1 delay_class 1 1 delay_parameters 1 8192/1048576 acl ficheros_wmv url_regex \.wmv$ delay_access 1 allow ficheros_wmv

175

Gestió de xarxes d’àrea local b) Tenim una connexió a Internet de 4Mbps i volem que l'ample de banda dedicat a la consulta de pàgines web des de les IP 192.168.0.102 a 192.168.0.112 sigui de 1Mbps com a màxim: delay_pools 1 delay_class 1 1 delay_parameters 1 131072/8192 acl llista src 192.168.0.102-192.168.0.112/32 delay_access 1 allow llista

176

Gestió de xarxes d’àrea local

3.10.3 Tor Tor és un sistema de comunicació anònim de baixa latència que fa servir un disseny de capes de ceba. Un rutejat de capes de ceba és un sistema que està pensat per donar als usuaris anonimat en les seves connexions a Internet fent servir un conjunt de nodes i negociant a través d'ells un circuit virtual de manera que la xarxa de cada node només coneix el seu predecessor i el seu successor però a ningú més. El transit sortint es xifra amb una clau simètrica que es farà servir per tornar enrere. Basically Tor provides a distributed network of servers ("onion routers"). Users bounce their tcp streams (web traffic, ftp, ssh, etc) around the routers, and recipients, observers, and even the routers themselves have difficulty tracking the source of the stream. Note that Tor does no protocol cleaning. That means there is a danger that application protocols and associated programs can be induced to reveal information about the initiator. Tor depends on Privoxy and similar protocol cleaners to solve this problem. Client applications can use the Tor network by connecting to the local onion proxy. If the application itself does not come with socks support you can use a socks client such as tsocks. Some web browsers like mozilla and web proxies like privoxy come with socks support, so you don't need an extra socks client if you want to use Tor with them. This package enables only the onion proxy by default, but it can be configured as a relay (server) node. Remember that this is development code -- don't rely on the current Tor network if you really need strong anonymity. The latest information can be found at http://tor.eff.org/, or on the mailing lists, archived at http://archives.seul.org/or/talk/ or http://archives.seul.org/or/announce/.

177

Gestió de xarxes d’àrea local

3.11 Xarxes Privades Virtuals (VPN)

Xavier Sala Pujolar

178