Tag Archives: computers

lio fun stuff

Acu multi ani, cand voiai sa faci un target de ISCSI pe Linux, existau tgtd si tgtadm. Pen’ca tgtd rula in userspace, avea ceva penalitati de performanta, ca luai chestii de pe disk si le trimiteai peste retea. Niste oameni, adica Datera prin http://linux-iscsi.org/wiki/LIO au scris toata partea de target si initiator in kernel ca sa nu mai faci context-switching aiurea fara motiv.

Partea misto e ca pe langa ISCSI “normal” au implemenant si primitivele VAAI ale lui VMware si accelereaza diverse operatiuni pe care le face ESXi: gen zero-ing, copiere si scriere de date de pe acelasi LUN etc.

Intr-un proiect de acu aveam nevoie de shared storage pentru niste ESXi-uri si m-am apucat sa fac niste target-uri pe un CentOS7. Initial din toate discurile de aveam sa le export, am exportat unul singur mi-am facut treaba si restul sa le export cand aveam nevoie de ele.

Intr-o zi cu soare am ajuns si la exportat restul de discuri ca aveam nevoie de loc unde sa fac backup, sa mut niste masini pe niste discuri mai rapide etc.

Am adaugat si restul de discuri ca LUN-uri, le-am mapat in ESXi-uri si m-am luat cu alta treaba. A doua zi incepe lumea sa se agite ca bai nu mai merge “serverul”, unde “serverul” era un VM pe care lucrau oamenii. Pana a ajuns la mine asta, pana am terminat ce aveam de facut, a inceput sa mearga “serverul”. Am zis ca cine stie, o fi sughitat reteaua sau ceva (ca lumea era pe Wi-Fi si na… nu e obligatoriu sa mearga mereu ca te mai pui cu laptop-ul aiurea si poate nu ai cel mai bun semnal) si d’aia n-a mers, ca nici nu a stiu lumea sa-mi spuna exact ce inseamna “nu merge”.

A doua zi dupa incident, eram eu pe langa rack-uri si trageam de niste cabluri pe acolo, cand aud un bipait din ala de cand buteaza un server. M-am apucat sa ascult sa vad de unde e, da pana am gasit un monitor, pana l-am montat, pana am luat-o din server in server, totul era iar OK. Dupa aia am luat-o cu verificat de uptime-uri, pana dau de asta cu storage care avea uptime de cateva minute.

Evident, dictai WTF-ul pe fata mea, ca n-atinsesem nimic care sa-l afecteze. Noroc ca mai eram cu cineva acolo pe post de martor, ca zicea lumea ca-i sabotez. E, cat incercam io sa ma uit in loguri sa vad ce-ar fi putut sa aiba (bine, sperand sa gasesc loguri), vad cum incepe un kdump sa ruleze si buf, reboot iar.

Cat am apucat io sa vad ce scria pe ecran, baga ceva cu “BIOS corrupted by…”. Zic sa vezi acu distractie, ca daca e ceva de BIOS si nu exista update la producator, o sa se lase cu sugeri maxime, ca aia n-o sa fixeze peste noapte si o sa dureze pana se prind ce ma-sa are.

Cat ma gandeam eu la posibilitati si ce-ar putea sa aiba, s-a rebutat, a pornit fain frumos, a mai mers vreo 10-15 minute si iar kdump si biiip restart.

Eram asa un pic cu morcovul in cur ca 1) lumea chiar avea nevoie de storage pentru VM-uri 2) eu propusesem solutia. Mai mult 2) ma ardea maxim. Ca ma gandeam c-am pizdit-o grav. Desi era prima oara cand se intampla asta, am auzit de atatea ori scuza asta la diversi cu “pana acu nu mi s-a intamplat” ca ma gandeam ca sigur o sa ma creada din parti clientul daca zic si io asta. Ca eu sigur nu l-as fi crezut pe unul cand zice asta.

Si m-am apucat sa ma gandesc ca ma-sa s-a schimbat intre timp, ce-am facut, unde, de ce. Si nu imi venea nimic in cap sa fi facut acolo, care sa prezinte un risc. Pana cand dupa vreo ora asa, si vreo 2 reboot-uri, m-a palit ca poate e de la ISCSI ca adaugasem alea 2 LUN-uri in portal.

Le-am demonat de pe ESXi-uri, le-am sters din portal si am asteptat sa vad daca mai crapa.

Si n-a mai crapat.

Dupa ce mi-a trecut sperietura cu asta, am inceput sa ma gandesc ca “ba bine, nu mai crapa, da acu ce cacat fac cu restul de discuri, ca nu pot sa nu le mai prezint la ESXi-uri, ca am nevoie de ele”. Cat timp ma gandeam eu la asta, mi-am adus aminte de kdump. Si m-am apucat sa ma uit prin ele, ca se salvasera toate de cand a inceput sa moara kernelul.

Si mi-a trecut panica, ca absolut de fiecare data crapa in acelasi loc:

[ 5241.534120] BUG: unable to handle kernel NULL pointer dereference at 000000000000001c
[ 5241.534194] IP: [<ffffffff816abb5c>] _raw_spin_lock+0xc/0x30
[ 5241.534245] PGD 0 
[ 5241.534264] Oops: 0002 [#1] SMP 
[ 5241.536014] Call Trace:
[ 5241.536048] [<ffffffffc05d1c90>] ? target_complete_ok_work+0x180/0x330 [target_core_mod]
[ 5241.536109] [<ffffffff810a881a>] process_one_work+0x17a/0x440
[ 5241.536153] [<ffffffff810a94e6>] worker_thread+0x126/0x3c0
[ 5241.536196] [<ffffffff810a93c0>] ? manage_workers.isra.24+0x2a0/0x2a0
[ 5241.536244] [<ffffffff810b098f>] kthread+0xcf/0xe0
[ 5241.536281] [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[ 5241.536327] [<ffffffff816b4f58>] ret_from_fork+0x58/0x90
[ 5241.536367] [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[ 5241.536410] Code: 5d c3 0f 1f 44 00 00 85 d2 74 e4 0f 1f 40 00 eb ed 66 0f 1f 44 00 00 b8 01 00 00 00 5d c3 90 0f 1f 44 00 00 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 a4 2a ff ff 5d 
[ 5241.536649] RIP [<ffffffff816abb5c>] _raw_spin_lock+0xc/0x30
[ 5241.536694] RSP <ffff88085de0fdf8>
[ 5241.536720] CR2: 000000000000001c

Bine, mi-a trecut panica ca m-am gandit eu ca ba, sa vezi ca se confuzeaza in vreo chestie de concurrency ca mai multe host-uri vor chestii relativ similare de pe mai multe discuri in acelasi timp si poate se dezaloca ceva aiurea si d’aia ajunge ala in NULL pointer dereference. Sau poate cand aloca nu si incrementeaza numarul de alocari si prima dezalocare merge da restul nu mai au cum… Sau ceva de SerDes aiurea la scrieri/citiri.

Da’ fiind in _raw_spin_lock cand crapa… slabe sanse sa pot debuga ceva, ca asta e treaba de lucruri low level in kernel.

Long-story short: mai multe LUN-uri intr-un portal exportate la mai multe host-uri != love.

Acum stiam de ce crapa, da nu-mi rezolva problema, si anume sa pot folosi toate discurile din sistem.

Si mi-am adus aminte ca atunci cand am mai avut probleme din astea cand nu mergeau mai multe lucruri in acelasi timp in kernel am folosit VM-uri se separ pe caprarii componentele.

Asa am ajuns ca pentru fiecare disc pe care trebuie sa-l export sa fac cate o masina cu KVM la care sa-i atasez discul din host, sa fac cate o configuratie simpla de ISCSI target si s-o prezint mai departe la ESXi-uri. E o solutie scarpinata pe dupa ureche, da’ merge si pentru ca virtualizare si discuri din host in VM direct, nu se observa nici un overhead.

Nu e cea mai eleganta solutie, dar merge fara prea mult efort de administrare.

ipv6 & ipsec & bugs

Mai anul trecut la inceput de vara ma jucam io in niste masini virtuale cu Layer2 peste Layer3 in Linux. Anul asta am gasit un client unde sa bag jucaria in productie sa vad ca toate treburile merg cum trebuie si pe bune :)

Eh, pentru ca atunci cand ai optiuni multe iti vin idei, am zis ce-ar fi daca intre 2 gateway-uri de VPN as face io conexiunea pe IPV6 in loc de IPv4, ca e bine sa fim pregatiti de viitor :))

Am pus io doua CentOS 7, configurat interfete & shit, am pus libreswan, am facut un tunel IPSec si am dat ping6 intre cele doua masini si a mers jucaria (tcpdump zicea ca vede ESP pe fir).

Ca oricem om prevazator, zic sa dau reboot ca poate am uitat sa configurez ceva sa porneasc la boot si daca ramai fara curent sau s-o panica kernelul de singuratate, sa mearga treaba cand dai restart de la buton.

Si dau io restart si evident ca pula tunel. ipsec status zicea ca e in CONNECTING, da nici in loguri si nici pe fir nu vedeam vreun pachet plecat la alalalt gateway. Ce-are, ce-are. Dat restart la libreswan, o lua. Am zis ca poate e vreo problema cu libreswan, ca mai dadusem de una draguta un pic inainte.

Aia draguta era misto, ca fix imediat dupa boot nu voia sa ridice tunelul de nici un fel. ipsec auto –up $nume_conexiune zicea ca nici una din cheile RSA nu e buna de folosit pentru autentificare, insa fara a modifica nimic, dupa un libreswan restart brusc deveneau bune cheile.

De draci ajunsesem la o varianta taraneasca, dupa pornirea sistemului sa-si dau un start/stop manual s-o ia.

Hai ca zic merge tunelul, sa fac niste teste de trafic cu ping6 sa vad daca MTU-ul e cum trebuie, dau io ping6 -s 1500 si timeout. Pe la vreo 1300 bytes si ceva payload mergea. Pun de mana MTU-ul la 9000 (ca interfete gigabit) si dau iar ping6, si iar timeout. Mai dau si un restart lu’ libreswan (ca vorba aia: when in doubt, restart) ca poate fiind pornit se uita o data la MTU si dupa aia o tine cumva cont de el. tcpdump zicea ca pachetele pleaca da nu ajung.

Uite asa m-am trezit io in zona crepusculara, unde lucrurile in teorie trebuiau sa mearga iar in practica erau diferite de teorie. Si e frustrant ca zici ca, mortii ma-sii, e un VPN, mai mult de cateva ore n-are ce sa ia, ca doar ma dau cu IPsec pe Linux de cand eram mic si stiam ce fac.

Dupa o zi de injuraturi, am oprit IPSec, si zic hai ca in clar tre sa mearga cacatul si o iau dupa aia pe dos sa vad unde se strica. Intre astea doua masini aveam un switch ca sa simulez realitatea. Si zic sa pun un cablu direct intre ele sa elimin orice element in plus care ar putea sa induca erori.

Evident, cu cablu direct mergea treaba de n’avea aer. Acuma switch-ul avea porturi gigabit si cablurile erau bagate in el in porturile alea. Si totusi ce n’avea switch-ul pe porturile gigabit? Jumbo frames in pizda ma-sii. Jumbo frames n-avea. Ca HP in vasta sa inteligenta s-a gandit ca probabil nu sunt bune si n-a implementat suport pentru ele in switch. Si uite asa ai conexiune la gigabit da cu frame-uri de maxim 1504 bytes, sa incapa si un VLAN tag acolo da nimic in plus.

Dupa dracii cu HP, m-am intors la problema initiala, de ce ma-sa dupa reboot n-o ia tunelul. S-a facut tarziu si m-am dus sa dorm.

Evident ca n-am dormit ca ma rodea problema, mi-am facut repede un laborator cu doua CentOS 7 si zic sa incerc strongswan in loc de libreswan, ca poate o avea ala suport mai bun pentru ce fac. Suport in a vorbi cu framework-ul de XFRM din kernel unde se intampla magia.

Fac repede o configuratie si dau reboot la un nod, si dupa reboot pula tunel. Dupa niste tcpdump ma loveste problema: Cand un neighbor IPv6 vrea sa afle ce adresa MAC are alt neighbor, trimite pe multicast FF02::1 un mesaj de Neighbor Solicitation (echivalent de mesajul trimis pe broadcast in IPV4 pentru a afla MAC-ul unui computer din reteaua locala) si primeste unicast un raspuns.

Ce se intampla in kernel in combinatie cu IPSec-ul: pachetele de solicitation plecau cum trebuie si ajungeau la alalalt nod, ala raspundea unicast si nodul care a trimis solicitarea le ignora pentru ca… tananana… se astepta sa fie criptate conform configuratiei (SA-urile erau facute intre 2 /128).

Acu la 2 noaptea stiam care e problema, sa o si rezolv:

conn ipv6nd
   auto=route
   keyexchange=ikev2
   authby=never
   type=passthrough
   leftsubnet=2001:abc:def:ffff::2/128[ipv6-icmp/136]

Unde leftsubnet reprezinta IP-ul aluilalt gateway, iar pe ala se face pe dos configuratia. Et voila, merg chestiile dupa configuratia asta.

Ce inseamna ce-am facut mai sus? Inseamna ca sistemul va accepta pachete ICMPv6 Neighbor Advertisement necriptate. E important ca regula asta sa fie scrisa prima in config ca sa aiba precedenta fata de urmatoarele. E ca la firewall, de sus in jos :)

Asa, acu c-am rezolvat-o, am trecut la pasul urmator. Tipul conexiunii era de tip transport, ca aveam treaba sa protejeze doar traficul intre cele 2 gateway-uri.

Peste am facut un tunel L2TPv3 si cateva sesiuni sa car niste VLAN-uri dintr-o parte in alta. Pe fiecare cap aveam o interfata fizica cu tag-uri de VLAN, una de pseudowire, ambele bagate intr-un bridge.

Pe o interfata de bridge am pus o adresa IPv4, la fel si pe alalalt gateway si minune… mergea ping-ul intre ele. Scopul declarat fiind sa le folosesc pe post de adrese de management pe un VLAN de management.

Cu experimentul pe IPv4 reusit, am pus un set de adrese IPv6 pe interfetele de bridge asteptand acelasi rezultat. Si-am asteptat, si-am asteptat… cum asteapta un caine parasit stapanii care nu se mai intorc.

Pentru ca IPv6 e special, cand ai o adresa pusa pe interfata de bridge, neighbor solicitation nu se duce doar pe interfetele de compun bridge-ul, ci pe toate interfetele din sistem, mai putin pe alea de pseudowire.

Aci ma panicasem un pic, ca sa nu pot sa fac management pe IPv6 nu era un capat de lume, da incepusem sa ma gandesc ca daca se intampla la fel si pe trafic intre 2 host-uri din acelasi VLAN care trec prin jucaria mea?

Well, aci am avut noroc si asta nu se intampla. De aflat am aflat testand si injurand iar HP-ul ca are ceva cu pachetele de IPv6 multicast si nu merge Neighbor Discovery. O sa investighez daca intr-o versiune mai noua de firmware au facut lucrurile sa mearga.

De ramas am ramas la strongswan din mai multe motive:

  • pare mai robust fata de libreswan
  • suporta DH Group 19/20/21 (curbe eliptice, chei mai mici, securitate mai mare)
  • suporta chei de tip ECDSA (cu ocazia asta mi-am facut si niste certificate digitale pe 521biti de tip Elliptic Curve)
  • nu are dilemele lui libreswan cu cheile (ba sunt bune, ba nu sunt bune)
  • merge OK partea de fragmentare a pachetelor care depasesc MTU la nivel de IKE (e misto sa dai ping cu -s 65000 si sa mearga fara sa faci nimic)
  • are suport de TFC (traffic flow confidentiality) pe IKEv2 in mod tunel. Asta inseamna ca face padding pana la MTU-ul interfetei si indiferent de cat trafic ai de fapt, unu care sta cu urechea pe fir va vedea mereu pachete de 9000 bytes (in cazul gigabit ethernet), fara sa stie exact cat sunt date utile si cat e gunoi.

Cu procesoare care au AES-NI (Intel Ivy Bridge sau mai noi) exista si accelerare hardware pentru criptare, via aesni_intel, mai ales daca AES e folosit in GCM. La fel, functiile de hash pentru integritatea datelor pot fi efectuate direct pe procesor prin sha512-ssse3 daca se foloseste SHA512 la IPSec.

Long story short, merge. Bine, merge da violat un pic tot setup-ul ca am dat de un bug in kernel care e nefixat in toate versiunile cu care am testat, adica de la 3.10 la 4.5 sau 4.10 cat era ultimul din CentOS 7 plus cand am testat.

BUG-ul e super misto: dupa cam o saptamana, moare treaba si fara reboot nu-si revine. Si asta se intampla pe ambele gateway-uri.

Dupa miliarde de draci si debug in fata serverului cu monitor si tastatura ca in vremurile bune, am descoperit problema, si anume un leak in kernel, mai mult de file descriptors din ce am bunghit pana acum.

Ce se intampla, ca e atunci cand se schimba cheile, nu se face free la esp6 si xfrm6 daca pe aceasi masina e si un tunel L2TP pentru setup-ul de pseudowires. Si creste utilizarea modulelor pana se strica jucaria.

[[email protected] ~]# lsmod | grep esp6
esp6 17180 1566 
[[email protected] ~]# lsmod | grep xfrm6
xfrm6_mode_transport 12631 3132

Si cand ajungi la cateva sute sau chiar mii, pocneste si nu mai merge. Si asta doar in combinatie cu modulul de L2TP pentru IPv6.

Pentru a rezolva asta, varianta cea mai buna a fost sa fac o masina virtuala in care sa termin partea de L2TP. Adica pe masina fizica am partea de IPSec intre capete, dupa care pe masina virtuala am facut multe interfete: una de inbound pe unde vin pachetele de L2TP si multe pe care sa scot pachetele in cate in un bridge, VLAN tagged sa le dau mai departe.

Postul asta trebuia sa-l public anul trecut cam acum (28 Septembrie 2016), da am uitat de el, da nu conteaza, ca BUG-ul nu e fixat nici acu si jucaria merge de atunci, line rate, fara nici o problema. Ar fi frumos sa fie si BUG-ul ala fixat pentru simplificarea setup-ului.

Cum setup super perfect nu exista, acum e un pic urata adaugarea de noi VLAN-uri pe acelasi pseudowire, in sensul ca trebuie sa le adaug de mana si sa editez si fisierele de configuratie astfel incat sa fie ce trebuie la reboot. Asta e din cauza ca pe CentOS nu exista script de network pentru a seta interfete de tip l2tp_eth. Insa e OK, ca nu schimb zilnic setari.

#slack

De prin Noiembrie asa de cand sunt intr-un contract nou lucrez intr-o echipa distribuita, fiecare de pe unde apuca. Pentru comunicatie si sincronizare la ce facem folosim Slack.

Slack, pentru comunicatie e asa… “the next best thing since sliced bread”. Poti sa te uiti sa vezi ce au discutat oamenii inainte sa intri pe un canal, ca de exemplu ce zicea lumea inainte sa vii in corporatie. Sa pornesti clientul si sa te lase acolo unde a inceput convorbirea de cand te-ai logat ultima oara.

Se integreaza cu tot felul de aplicatii (gen Dropbox pentru link-uri la poze/documente). Eu sunt mare fan ca pot sa uploadez poze cu diverse chestii, pot sa fac highlight pe text, pot sa editez ce-am scris (in mare parte pentru a corecta typo-uri), pot sa fac echivalentul a preformatted cand am snippet-uri de configuratie sau cod.

Si arata super bine. Fontul la scris, temele, cum sunt aranjate discutiile. Poate nu parea important, da pentru mine conteaza sa nu folosesc aplicatii care-mi displac cum arata.

Ce suge la Slack sunt thread-urile, da ii dau asa doar juma de bila neagra ca abia au fost introduse si probabil o sa le mai schimbe de cateva multe ori pana o sa gaseasca formula sa arate si alea normal si decent.

Nu e Slack o noutate, da voiam de mai demult sa scriu despre un el ca pur si simplu este foarte misto si pentru cine n-o fi auzit de el, recomand cu cea mai mare caldura.

turop

Pentru un proiect de-al meu, in scop didactic, am nevoie sa pot emite certificate digitale cat mai usor cu putinta. Si cum tot am inceput sa mai apas butoane si in limbaje de programare, am zis ca ce bine, pot sa scriu ceva simplu pe web.

Asa ca azi am creat turop, o aplicatie web in care cine are nevoie face paste la CSR si primeste un certificat digital inapoi. E mega quick & dirty, in special dirty. Da merge si isi face treaba.

ammit

De ceva vreme am tot cochetat cu invatatul de Python in contextul dezvoltarii de chestii web based (sa le zicem servicii). Pentru ca am tot felul de idei, da nu prea stiu programare, m-am apucat sa fac experimente micute sa inteleg cum functioneaza treburile, cum se leaga componentele intre ele si alte lucruri din astea super de baza.

Unul din experimentele astea se cheama Ammit si  este un URL shortener foarte basic bazat pe Bottle si Redis (via redis-py). Poate fi rulat ca aplicatie UWSGI din nginx. Ce e comis pe GitHub, ruleaza ca si standalone app pentru testare/dezvoltare.

GitHub il folosesc ca sa invat de stuff cu git si version control.

defcamp 2015 (ziua 2)

Ziua a inceput cu “Modern approaches to Wi-Fi attacks” tinuta de un polonez fost militian care a explicat foarte frumos cum poti face brute forcing la parole pentru WPA2 la routere din comert. A vorbit foarte misto si de entropia parolelor si de faptul ca daca un router nu foloseste setari din fabrica si pune utilizatorul sa seteze o parola, parola respectiva tinde sa fie chiar buna si nu foarte simpla. Foarte, foarte misto explicat.

Dupa nenea asta a fost un turc de la KPN Netherlands, care a vrut sa vorbeasca despre “Why nation-state malwares target Telco Networks: Dissecting technical capabilities of Regin and its counterparts”, dar a reusit sa ma plictiseasca si sa ma enerveze maxim. A citit toate slide-urile de le-a avut, foarte monoton, n-a zis nimic interesant, numai generalitati, a pus cateva slide-uri cu acronime si a tinut mortis sa zica de la ceva vine fiecare acronim si dupa aia sa treaca mai departe la alte chestii fara nici o legatura cu ce a citit mai devreme.

Dupa aia am nimerit la “How to mess with Android Intents” tinuta de un romanas de la Intel care a vorbit despre cum poti face DDoS la un telefon cu Android daca il conectezi la computer folosind un cablu USB. Si dupa aia citit help-ul de la programul scris de el si de inca o tanti, tot de la Intel. Nu m-am prins care a fost scopul, ca o data ce ai telefonul fizic in mana…

Am luat o gura de aer si am stat destul de mult si la “Hacking and Securing Network Monitoring Systems: End-to-end walkthrough example on Ganglia” unde un tip (foarte bun pe firmware si chestii conexe) a vorbit despre cum poti cauta servere de monitorizare accesibile din Internet, sa exploatezi cumva interfata web si dupa aia sa ataci serverele stiind ce chestii ruleaza pe ele. #nimicnou (macar aia sunt amuzanti).

Asa a venit pauza de masa si m-am dus cu Sorinache la Beraria Bragadariu la o bere (duh!) si la o portie de coaste. M-am gandit ca un pic de alcool o sa ma faca sa-mi treaca dracii cu prezentarile astora.

Well, dupa ce-am halit si am ajuns inapoi, m-am dus la o prezentare numita “Breaking in Bad (I’m the one who doesn’t knock)” tinuta de un tip de lucreaza la Pwnie Express, cu subiectul “Social Engineering”. Asta e primul tip care a vorbit din experienta, documentat cu filmulete si poze, despre cum se face asa ceva. Omul are har de prezentator, e simpatic si stie cum sa faca o poveste interesanta. Mi-a placut enorm prezentarea lui, pe departe a fost cea mai misto.

Imediat dupa el a urmat “Building a Cyber Security Operations Center” tinuta de un nene din UAE despre cum sa faci un SOC, reglementari, complianta si restul de crapuri de le auzi de la un producator comercial. Eram langa mine cu o fosta colega si i-am zis ca o invit la o apa, si ea “am sa accept”. Cam asta era nivelul de interes si plictiseala.

Am stat un pic dupa pauza sa vad “What’s in a name? DNS use for exfiltration, and monitoring for detection”, motivul fiind ca era tinuta de Teodor Cimpoesu si stiam ca se pricepe la din astea. Dar minune, prezentarea nu a avut titlul asta, s-a schimbat in altceva oribil si pe la jumate asa cand m-am prins ca n-o sa fie nimic interesant, mi-am bagat pula intr-un mod diplomat si m-am dus acasa. Singura parte distractiva a fost asocierea numelui UTI cu “Trusted advisor” si “incredere”. Buna gluma.


Fata de anul trecut, anul asta a supt maxim. Calitatea prezentarilor a fost slaba spre execrabila, iar organizarea foarte defectuoasa. Privind lucrurile si dintr-o perspectiva pozitiva, o sa-mi fac puncte pentru CEH si CISSP :)

defcamp 2015 (ziua 1)

Azi fusei la DefCamp 2015. Am mai fost si anul trecut si mi-a placut, asa ca am zis s-o bifez si anul asta, mai ales ca s-a nimerit sa fiu pe aici. Mai putini cunoscuti ca anul trecut, foarte multi oameni, se pare ca s-au inscris cam 800 la conferinta si anul asta ca noutate au avut 2 sesiuni in paralel. Treaba care a cam supt un pic ca pareau interesante diferite sesiuni paralele. Ma intalnii de dimineata si cu unul cu care am lucrat in Abu Dhabi si cu care am fost foarte amabil, ca sunt trei sferturi somer si cam trebuie sa-mi gasesc chestii de facut :))

Prima prezentare s-a numit “From Hype Hangover to Happy Hacking: Shaping the World through Shaping Actions” si a fost tinuta de un nene de a fondat sau lucreaza la “I am the Cavalary initiative”, un fel de think tank care se focuseaza pe cum poate fiecare sa ajute atunci cand sunt probleme de securitate. Prezentarea in sine a fost foarte misto si aratat binele pe care-l face cercetarea in securitate si cum poate sa “back fire” o data ce presa/media face reportaje bombastice despre diverse vulnerabilitati si lumea se panicheaza complet aiurea.

A doua prezentare, “A new Hope – CTF stories & IoT Hacking” a fost tinuta de Bitdefender (unul din prezentatori a fost Jay, alalalt nu stiu cine era) si s-a vorbit mai mult de Capture the Flag, cam cum vede lumea Internet of Things si problemele de securitate asociate cu asta. Nu imi aduc aminte prea multe detalii, probabil din cauza ca eram inca rupt in gura de somn.

Am vrut sa vad “Building a Weaponized Honeybot”, dar n-a venit prezentatorul, asa ca m-am dus la “Game of Hacks: Play, Hack & Track”, tinuta de un tip de la Checkmarx, despre cum poti invata hack-uri si metode de programare sigure prin jocuri. A facut si un demo live cu platforma la care au participat ~145 persoane din sala. M-am bagat si eu si am ajuns undeva pe locul 30.

Dupa asta am ars-o pana la pranz, ca urmtoarea prezentare mi s-a parut extrem de bullshitista din titlu, si anume “App2Own Bug Bounty Awards, Orange Romania”. A dat securitatea in operatorii mobili…

Dupa pranz m-am dus la “IoT Security”, prezentare tinuta de doi rusi, co-fondatori la un startup de securitate. Background tehnic super misto, insa abilitatile lor de prezentare invers proportionale. M-am plictisit in primele 10 minute si m-am tirat in ailalta sala unde a fost o prezentare numita “Challenges on Reversing Layered Malware” tinuta de un nene de la Fortinet. Foarte misto, foarte tehnica prezentarea, chiar am invatat niste lucruri noi despre cum se impacheteaza malware-ul modern, cum incearca sa detecteze daca ruleaza intr-un debugger sau intr-o masina virtuala.

Urmatoarea prezentare s-a numit “When Steganography Stops Being Cool” tinuta de un spaniol de la Trend Micro. Asta chiar mi-a placut ca a explicat cum malware-ul foloseste metode steganografice de a downloada sau a uploada date in moduri in care nu poate fi detectat de solutiile antimalware existente. Una din metode este de a encoda date in imagini folosind pattern-uri de culoare imperceptibile ochiului uman, insa perfect vizibile unui computer (RGB 255,255,255 este la fel cu RGB 255,255,254 pentru om, insa distinct pentru computer), aflarea centrelor de comanda si control folosind interogari DNS pentru TXT records si multe altele. Chiar mi-a placut foarte mult prezentarea, pot sa zic ca pe ziua de azi a fost cea mai misto.

Dupa aceea a urmat una legata de firmware reverse engineering, numita “(In)Security of Embedded Devices Firmware – Fast and Furious at Large Scale”. Tipul care prezinta stie despre ce vorbeste, a avut o prezentare foarte misto anul trecut, insa cea de anul asta nu mi s-a parut foarte interesanta. Pe la jumate m-a luat somnul si m-am dus spre casa.

Cam asta a fost prima zi la DefCamp. Maine se arata o zi mai interesanta si chiar sper sa fie asa.

Aseara am nimerit la cina prezentatorilor si se pare ca international este foarte bine vazut DefCamp, era un nene (fost profesor universitar) din San Francisco care venise special pana aici sa fie prezent sa vada cum e. La fel si unii din Albama si South Carolina.

Cateva chestii mai mult organizatorice:

  • Varianta cu sesiuni paralele suge, ca trebuie sa alegi intre una si alta.
  • Cafeaua a fost putina si s-a terminat repede, abia a iesit cam un pahar de fiecare pentru aia de beau cafea.

pyodbc & centos 6

Pe CentOS 6, versiunea de pyodbc este 2.1.7 si are un mic bug atunci cand are de interoperat cu baze de date care tin mortis sa dea datele encoded UTF-16 si face double-encoding la orice rezultat primit de la baza de date in urma unei interogari, daca ruleaza pe un sistem pe 64 de biti (cam asta am inteles io din descrierea problemei).

Descrierea BUG-ului se afla la https://code.google.com/p/pyodbc/issues/detail?id=78 iar rezolvarea se face prin modificarea unei singure linii de cod si stergerea unei litere :)

La http://www.imacandi.net/sin/blog/wp-content/uploads/2015/09/pyodbc-2.1.7-1.el6.x86_64.rpm se gaseste un RPM cu pyodbc patchuit si recompilat.

Cu ocazia asta mi-am adus aminte si de cum se foloseste rpmbuild.

double failures

In anii astia de acum (adica 2014/2015) eu nu pricep de ce vreun producator de echipamente ar face doar echipamente cu o interfata “IN” si una “OUT” si desi face clustering, nu poti face agregare in nici un fel astfel incat sa ai protectie in caz de pica switch-ul A si echipamentul B (incrucisat adica). Complicat nu este, mai ai un nivel de abstractizare cu impact minim ca toti linucsii astora de fac “appliance”-uri stiu de bonding si alte crapuri.

Srsly, nu pricep de ce toti zic, eh, lasa ca te descurci tu cum faci asta, noi nu vrem sa te ajutam in nici un fel, noi punem cat mai putine interfete pe chipamente si aia e.

Scapi de nenumarate griji cu un setup din asta, se pot strica chestii si poti sa-ti vezi de ale tale pana ai timp sa le repari tot asa… dar nu, s-au gandit unii ca de ce sa fie simplu cand poate sa fie complicat.

Asta e un rant de voiam sa-l zic de mai demult, de prin mai, da a trebuit sa fixez ce era muit si am uitat de el. Priorities, priorities.

ip number

Well, se pare ca m-am prostit si am descoperit niste roti patrate. Noroc ca #mumu e vigilent si imi zice cand sunt prost. Cred ca trebui sa raman la consultanta, nu la chestii din astea de implementare.

SELECT city,country FROM geoip_v4 WHERE
ip_from <= inet_aton('10.20.30.40')
AND
ip_to >= inet_aton('10.20.30.40');

Dar pentru istorie, ca sa mai rada si altii de ce chestii debitez cateodata, ramane si textul initial, cu mentiunea:

<rpetre> ce credeai ca e formula aia magica de ip to number? :)

Exista niste unii, care se cheama IP2Location de vand informatii de IP GeoLocation, adica pe scurt iti zic in ce oras/tara este inregistrat un subnet. Ei datele astea le dau CSV sa le incarci in ce vrei tu si dupa aia sa faci cautari in ele.

Pentru ca nu toate bazele de date au IP/subnet ca tip de data, daca te uiti dupa o singura adresa IP si tu tii subnet-uri in DB trebuie sa faci niste programare la mijloc sa afli de al cui sunbnet apartine o adresa IP. Asa ca oamenii astia au inventat ei o chestie de se cheama IP number: adica transformi 1.2.3.4 intr-un numar dupa o formula si dupa aia vezi tu cam intre ce valori se situeaza numarul ala in baza de date si afli cum ii cheama pe aia de-l utilizeaza si unde sunt inregistrati.

In baza de date informatiile sunt tinute sub forma de IP_FROM, IP_TO, CITY, COUNTRY plus alte chestii irelevante pentru post-ul asta. IP_FROM e numarul de la care “pleaca” un subnet si IP_TO numarul unde se “termina” subnetul. Formula dupa care se calculeaza IP number este:

X = A x (256*256*256) + B x (256*256) + C x 256 + D

In SQL (PostgreSQL* compatibil), un lookup dupa 10.20.30.40 se transforma in:

SELECT city, country FROM geoip_v4

WHERE ip_from <= 

((split_part('10.20.30.40','.',1)::INT * (256*256*256))
+
(split_part('10.20.30.40','.',2)::INT * (256*256))
+
(split_part('10.20.30.40','.',3)::INT * 256)
+
split_part('10.20.30.40','.',4)::INT)

AND ip_to >=

((split_part('10.20.30.40','.',1)::INT * (256*256*256))
+
(split_part('10.20.30.40','.',2)::INT * (256*256))
+
(split_part('10.20.30.40','.',3)::INT * 256)
+
split_part('10.20.30.40','.',4)::INT)

<= si >= ajuta sa faci match pe adresa de retea si pe broadcast daca stii exact unde ma-sa se termina subnet-ul pe care-l cauti si daca chiar vrei asta, altfel e bine doar cu < si >.

Cast-ul la INT l-am pus ca baza de date imi facea cast in FLOAT dupa care il compara cu INT si ca sa-l compare mai facea un cast din FLOAT in INT. Am sarit un pas, ca profilerul pentru acelasi query zicea ca dureaza ~500msec sa se uite in 11M de inregistrari (beware of my small data) pentru VARCHAR::INT si vreo 45sec sa se uite tot acolo dupa VARCHAR::FLOAT::INT. E un pic dubios rezultatul de la profiler pentru ca nu cred ca dureaza asa mult sa te faci ca n-ai nimic dupa virgula, dar si faptul ca daca rulezi un query cu cele doua variante diferenta ochiometrica intre ele e de maxim 2 secunde.

Pe de alta parte, nu-s mare fan ideii de “la mine pe laptop merge”, mai adaugati voi hardware sa mearga repede si la voi.