oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: network

podcast 1×08: CAS, Central Authentication Server

Reading time: 3 – 4 minutes

L’objectiu d’aquest podcast és donar una visió conceptual del funcionament de CAS 2.0, un servidor d’autenticacions SSO (Single Sign On). Bàsicament esta orientat a usuaris d’aplicacions amb interficie Web. A movilpoint l’estem usant tal com vaig comentar al podcast 1×07.

La diferència entre 1.0 i 2.0 és que la versió 1.0 només podia autenticar usuaris contra aplicacions web i aquests serveis no podien autenticar-se a la seva vegada contra altres serveis (serveis backend).

Amb l’esquema que hi ha a continuació i la previa lectura de les entitats d’un sistema CAS podreu seguir el podcast:


CAS - Central Authentication Server (schema)

A continuació descric les entitats que intervenen en un sistema CAS.

  • Service Ticket (ST): és una cadena de text que usa el client com a credencial per obtenir accés a un servei. Aquest tiquet s’obté del servidor CAS. La forma d’obtenir-lo és a través d’una cookie que es guarda al navegador.
  • Ticket Granting Cookie (TGC): cookie que s’envia al CAS quan un browser ja ha estat autenticat previament per aquest CAS, llavors aquest reconeix la cookie i li dona al browser un Service Ticket (ST) sense haver de passar el procés d’autenticació manual. Caduca en unes 8h aproximadament.
  • NetID: identifica a un ususari, el que coneixem habitualment com username.
  • ServiceID: identificador d’un servei, normalment en format URL.
  • Proxy Ticket (PT): és una altre cadena de text que usa un servei com a credencial per obtenir accés a un servei de backend. O sigui, que el primer servei per tal de desenvolupar la seva activitat li fa falta accedir a un altre servei (servei de backend), per tal d’obtenir accés a aquest darrer servei el primer usarà un proxy ticket. Aquest tiquets s’obtenen al CAS quan el servei que vol l’accés presenta un PGT (Proxy-Granting Ticket) i un identificador de servei que es refereix al servei de backend.
  • Proxy-Granting Ticket (PGT o PGTID): es tracta d’una altre cadena de text que com hem vist al punt anterior l’usa el servei per aconseguir un Proxy Ticket (PT) que li doni accés a un backend service l’accés a aquest servei serà amb les mateixes credencials que l’usuari original, o sigui, el que s’ha autenticat al primer servei.
  • Proxy-Granting Ticket IOU (PGTIOU): com no podia ser d’altre manera és una cadena de text que es passa com a resposta del serviceValidate i del proxyValidate usada per correlacionar un Service Ticket o una validació de Proxy Ticket amb un Proxy-Granting Ticket (PGT) particular.

Ara només queda escoltar el podcast:

[display_podcast]

Els enllaços relacionats amb el podcast:

NOTA: donar les gràcies al Marc Torres per la seva feina, gràcies nano.

Pound: reverse proxy i load balancing

Reading time: 3 – 4 minutes

A través d’un howto de howtoforge he descobert aquesta eina anomenada Pound. Realment m’ha deixat impressionat per la seva simplicitat i potència al mateix temps. A més m’ha donat molt confiança saber que hi ha almenys un site processant 30M de peticions al dia, unes 600 per segon amb aquest aplicatiu. Aquest tipus de números sempre ajuden a donar confiança en les eines.

Doncs bé, l’eina bàsicament es dedica a capturar totes les peticions HTTP i HTTPs repartint-les després contra els servidors que té en el backend. En cap moment fa de caché ni res similar. Tot i que cal destacar la capacitat de poder fer de SSL wrapper. Així doncs, no cal que els backend facin de servidors SSL, només de servidor HTTP. Obviament pel client s’establirà una connexió HTTPs completament transparent. Si la validació SSL no és correcte Pound ja no envia peticions als servidors que té darrera.

Les funcions de balancejador de càrrega (load balancer) permeten no perdre les sessions establertes pels navegadors dels clients contra els servidor de backend, de fet, Pound implementa sis formes diferents de capturar una sessió per tal de no enviar peticions a un dels backends que no conegui la sessió del navegador.

Suporta funcions de fail-over, així doncs totes les peticions es direccionen només als servidors de backend que se sap que funcionen, la validació que es fa per saber si un servidor esta actiu o no és força simple i a grans trets es basa en paquets ICMP.

Finalment també cal destacar una funcionalitat que m’ha cridat molt l’atenció, ja que permet fer de wrapper d’URL i enviar les peticions que acompleixin certes expressions regulars cap a un o altre servdidor. Això permet, per exemple, enviar els dominis virtuals cap a un o altre servidor. A més, també podem per exemple, enviar les peticions d’imatges cap certs servidors de backend específics.

Al llegir-me la documentació d’aquesta eina el que més m’ha intrigat és saber com resolien el típic problema que presenten les eines d’aquest tipus, els fitxers de logs. M’explico, una cosa molt important a poder controlar des del punt de vista d’un servidor web és saber d’on arriben les peticions si el servidor web no rep les peticions directes d’internet sinó a través d’un balancejador com Pound la IP origen de la petició es perd i per tant, els fitxers de logs dels servidors web no són reals sinó que tenen com a origen sempre el balencejador. A més de totes els problemes associats a no saber d’on venen les peticions, com el control d’accés i d’altres similars.

Doncs bé, bàsicament això es soluciona a través d’una capçalera HTTP afegida des de Pound a la petició web. Així doncs és en aquesta capçalera que s’han d’anar a buscar les dades necessaries per recomposar el fitxer de logs del servidor web. També hi ha mod’s d’apache que ja solucionen aquest tema directament capturant aquesta nova entrada en la capçalera HTTP, concretametn val la pena que no perdeu de vista mod_extract_forwarded2.

Sota el meu punt de vista un gran descobrint i una eina molt interessant per tal de poder montar servidors web’s amb més cara i ulls. No sé si algú l’haura provat 😉

Rack Tables: inventari dels servidors que tenim als racks

Reading time: 2 – 3 minutes

racktables.png

A primer com de vista i pel que puc veure en la demo, ja que no l’he usat mai encara, m’agrada molt el que preten fer el Rack Tables. Bàsicament la idea és mantenir un inventari de què hi tenim montat a cada un dels armaris rack que tenim destribuits per tot el món. Això quan tens un garbuix al cap del que té cada client com em passa a mi sovint pot ser molt útil. Sobretot perquè s’hi poden adjuntar fotografies o portar un control exahustiu de les U’s que hi tenim lliures, dels ports de switch ocupats, etc. Per tant, diria que és una eina molt recomanable per administradors de sistemes. Fins hi tot diria que imprescindible per admins d’empreses de serveis que no tenen contacte diari amb els datacenters dels clients.

També permet portar un registre dels espais d’IPv4 en això s’assembla una mia al IPplan malgrat les funcions d’aquest aplicatiu són molt més simples i es redueixen a funcions purament d’inventari. Al estar orientat a servidors ens permet mantenir un registre dels serveis virtuals que tenim corrent, pools de màquines i fins hi tot algunes funcions de monitorització a nivell de gràfiques sobretot. Per cert, m’agradaria descatar que potm ostrar l’estat dels balancejadors de carrega web, per exemple.

És important recordar que és una eina d’inventari, en això vull dir que el que aquí interessa no és pas veure com les coses canvien en temps real. Sinó poder mantenir un registre de com tenim o volem tenir montada l’infraestructura. És a dir quelcom més proper a una ajuda per mantenir la documentació que no pas una eina de supervisió. Per això ja tenim nagios, no?

No ho havia comentat però l’aplicació funciona via web i malgrat no m’hi he fixat massa diria que és la típica aplicació feta amb PHP i MySQL. Potser per ser una aplicació web la trobo una mica massa anticuada tan en el disseny com en la poca introducció de funcionalitats AJAX que la facin més usable i atractiva a l’usuari.

p4p la evolució del p2p

Reading time: 1 – 2 minutes

Aquesta setmana arran d’un article de bandaancha he descobert el P4P. La idea té molt bona pinta, a més és una solució en la que sembla que tots hi sortirem guanyant els usuaris de P2P i els operadors. Es tracta de que quan fem una connexió P2P el ISP intentarà que el tràfic dels nostres peers vingui de dintre de la mateixa xarxa. Així doncs, l’operador no ha d’enviar tràfic cap a d’altres operadors sinó que tot queda a casa. A més als usuaris ens beneficiem perquè ens arribarà més ràpid.

p4p.png

Doncs pel que he pogut investigar el tema esta encara molt verd. Ja que no he trobat cap prova de concepte i tampoc cap snippet ni res de res. Així doncs encara estic amb les ganes de veure alguna cosa decent. Tot i que resulta que hi ha operadors com Telefonica que estan fent proves, estaria bé que expliquessin com. Perquè molt presentar resultats però res més.

Si algú sap algo del tema que avisi…

mikrotik: failover gateway

Reading time: 4 – 6 minutes

Avui he refrescat una mica la meva memòria, feia algún que altre mes que no jugava amb els mikrotik. Doncs bé, per un client havia de montar un failover gateway i com que ja sabeu que sóc un fan declarat dels mikrotik per fer això he usat un RB150. Per si això ús sona a xinès segur que amb una petita explicació ho trobareu molt útil. Doncs bé, cada cop més empreses tenen dos sortides a internet i el que volen és que quan alguna de les dues sortides caigui l’altre sortida assumeixi tot el tràfic sense haver de tocar res.

Obviament per fer això el que hem de tenir és un element que s’encarregui de redirigir tot el tràfic cap a un router o cap a l’altre segons si la sortida a internet esta fallant o no. La solució que plantejo és molt simple i pot perfeccionar-se moltíssim. Per exemple, l’únic que explicaré és a usar un dels dos routers i quan aquest falla enviar el tràfic cap a l’altre però no és gaire difícil crear unes policy routes per balancejar tràfic entre els dos routers mentre aquests estiguin operatius. Però per no liar la cosa em quedaré amb l’exemple bàsic. A partir d’aquí, la base estarà més que feta perquè feu coses més xules.

routerboard-inabox-02.png

escenari

El RB150 tindrà a l’ethernet 1 la xarxa LAN. A la ethernet 4 la WAN1 i a la ethernet 5 la WAN2. Amdues interficies tenen el router ADSL en monopuesto. O sigui, que tinc la IP pública a l’interficie del router.

funcionament

Per defecte, sortirem per la WAN1 i quan aquesta falli sortirem per la WAN2.

configuració

Assumeixo que les configuracions bàsiques ja estan fetes, o sigui, assignació d’IPs a interficies i l’enmascarament d’IP internes cap a internet. Això suposo que no té cap dificultat si algú necessita ajuda que avisi.

Creem dos scripts a llençar quan s’hagi de llençar la connexió via WAN1 i l’altre via WAN2:

Script per la WAN1:

:log info wan_1
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN1

Script per la WAN2:

:log info wan_2
/ip route set [/ip route find dst-address="0.0.0.0/0"] gateway=IP_GW_WAN2

Si ens interessa en cada un dels scripts hi podem afegir el que calgui. Per si no esteu habituats a treballar amb scripts al mikrotik els heu de colocar a /system scripts. Allà afegiu dues entrades i llestos. Com sempre això serà molt més còmode fer-ho des del winbox que no pas des de la cli.

Ara només cal que creem una entrada a l’eina netwatch, això es fa a /tool netwatch. A l’entrada li direm que faci pings cada un interval de temps que decidirem i que tingui un timeout fixe i si els pings no tornen llavors s’executarà l’script indicat. Bàsicament le entrades de netwatch tenen dos estats el up i el down i podem associar un script a llençar en cas de que hi hagi una oscil·lació cap a un dels dos estats. Això es fa així:

add host=208.67.222.222 timeout=10s interval=1m up-script=wan1 down-script=wan2 \
comment="Failover Gateway Script" disabled=no

El que fem és mirar si arribem a un dels servidors d’OpenDNS cada 1minut i ens esperem com a molt 10s perquè el ping torni. Després fixeu-vos com associem cada un dels scripts que em programat abans als estats d’aquesta prova.

Com podeu veure això és ben senzill, la gràcia esta en que jugueu amb els ECMP i els policy routing i feu del RB150 tot un balencejador de càrrega amb suport de fallides de línia. També és molt senzill que balancegeu el tràfic d’entrada d’internet cap a una ADSL o cap a l’altre, per fer això ús recomano que jugueu amb el DDNS que podeu actualitzar a través dels scripts comentats, només cal que li llenceu la petició d’actualitzar la IP associada al DDNS i els usuaris remots entraran per una o altre línia.

SSH tricks: control usuaris i col·lisions en la fingerprint

Reading time: 2 – 3 minutes

Un parell de tricks per l’SSH un pel servidor (sshd) i l’altre pel client (ssh).

Si volem deixar accedir només a alguns usuaris al nostre sistema via SSH s’ha de posar al fitxer /etc/ssh/sshd_config la comanda AllowUsers. Aquest eginy l’he extret de Restrict SSH per user.

Un exemple:

AllowUsers root oysteivi otheradmin

L’altre enginy és molt útil quan programem scripts que usen per exemple: scp, rsync o d’altre similars. A vegades per molt que usem un sistema d’autenticació per clau pública amb ssh això no és suficient perquè hi pot haver un conflicte den la fingerprint que tenim guardada (o no) del servidor on anem a connectar. Llavors se’ns pregunta si volem guardar aquesta fingerprint sinó la tenim guardada o si assumim que hi ha conflicte entre la fingerprint guardada i la que ens esta enviant el sevidor. Per més detalls sobre el problema podeu consultar aquest article de securityfocus SSH Host Key Protection. A més segur que aquest exemple ajudarà a refrescar la memòria sobre el que em refereixo.

 $ ssh ssh-server.example.com
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes

Per tal de controlar el comportament d’aquest event ho podem fer amb el paràmetre StrictHostKeyChecking=[yes|no|ask], això ho podem posar a /etc/ssh/ssh_config o bé a la línia de comandes a través del flag -o.

Exemple forçant la comprovació:

  $ ssh -o 'StrictHostKeyChecking=yes' ssh-server.example.com
  No RSA host key is known for localhost and you have requested strict checking.
  Host key verification failed.

Exemple preguntant la comprovació:

  $ ssh -o stricthostkeychecking=ask ssh-server.example.com
  The authenticity of host 'ssh-server.example.com (12.18.429.21)' can't be established.
  RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
  Are you sure you want to continue connecting (yes/no)? yes

OpenDNS – els millors DNS que podeu usar per navegar

Reading time: 2 – 2 minutes

opendns.gif

Sovint quan et pregunten quins DNS li poso a la màquina acostumo a contestar 194.179.1.100 com a primari i 194.179.1.101 al secundari, això ho vaig aprendre a l’època del primer infovia el del 055. Des de llavors se m’han quedat grabats aquest parell de DNS públics. Doncs bé, si a més d’això a cada empresa que vaig, a la xarxa de la meva feina o la meva intranet a tot arreu hi tinc un servidor DNS intern llavors mai tinc la necessitat de configurar-me servidors DNS externs. Així doncs, mai havia tingut la necessitat de plantejar-me quins eren millor o pitjors i què m’oferien uns o altres. Doncs bé, aquest cap de setmana tot llegint el blog de l’Alex King, concretament l’article sobre l’OpenDNS he descobert aquest servei tan interessant.

Algunes de les avatatges de l’OpenDNS són:

  • Temps de resolució molt ràpid. Servidors per tot el món.
  • Correcció d’errors tipogràfics comuns (p.e. convertir .xom -> .com)
  • Avisa si s’intenta entrar en una pàgina de phishing. Per tant, és ideal per protegir d’aquests atacs.
  • Es pot forçar l’update d’un domini, forçant el refresc.
  • A més és gratuït. Viuen de la publicitat que posen a la web i a les pàgines de bloqueig de phishing.

Trick: Winsock del WinXP es queda tonto

Reading time: 1 – 2 minutes

En les versions antigues del windows quan la pila TCP/IP es quedava tonta era molt senzill reinstal·lar-la sobretot al 95 que cada 2×3 te la feia tornar a instal·lar. Però en la versió XP ja és més fotuda la cosa i quan el winsock2 es queda tonto és realment difícil reinicar-lo o reinstal·lar-lo.

Per resetejar-lo podeu usar l’ordre:

netsh winsock reset catalog

També podem eleminar dues entrades del registre per forçar una re-instal·lació de la pila winsock:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Winsock2

Re-iniciem la màquina i després anem a les propietats de l’interficie de xarxa i instal·lem de nou el protocol TCP/IP.

Si voleu més informació sobre ambdues solucions podeu anar a: