RouterOS vs. buffer overflow: who would win?

 

Pe scurt, mi-am schimbat routerul software (RouterOS x86) cu unul hardware (Mikrotik RB3011 RouterOS ARM) si am vrut sa ma joc cu OpenVAS. In timp ce am scanat toata reteaua, routerul s-a restartat de cateva ori. Am zis ca am setat o scanare prea intensa si ca a crapat din cauza asta (ceea ce ar fi destul de naspa), asa ca am ales o scanare mai simpluta doar pentru Mikrotik. Din pacate iar s-a restartat de cateva ori. Am asteptat sa se termine scanarea si sa primesc raportul. Se pare ca exista o vulnerabilitate si poti sa o explotezi foarte simplu. Vulnerabilitatea exista de ceva timp si a fost rezolvata din ce am cautat, dar aparent inca exista in RouterOS, sau mai bine zis in webserverul din RouterOS/Mikrotik.

Partea buna? Esti afectat daca ai UPnP activ, si problema devine reala doar daca cineva din interiorul retelei o exploateaza, deci temporary solution: disable UPnP, real men do Port Address Translation.
Pe unele soutere doar crapa serviciul de UPnP.  Pe al meu crapa tot routerul, dar daca am pornit /tool profile (sau daca sunt conectat prin SSH?) nu crapa decat atunci cand ies din SSH (si opresc /tool profile)

Anyway, mai multe detalii aici, plus bonus:

 

 

EDIT: In ziua in care am descoperit bug-ul am deschis tichet la Mikrotik. Dupa aproximativ 4 zile, problema a fost rezolvata de catre Mikrotik. In 3 saptamani a aparut un firmware nou cu bugfix-ul.

Integrare Zabbix cu Slack

Vreau sa fie clar de la inceput, nu e vorba de Slackware (distributia) ci de Slack (platforma/clientul de chat).

Acum ceva vreme am reusit sa integrez Zabbix cu un client de Zabbix pe iOS ce avea posibilitatea sa trimita notificari push atunci cand se intampla ceva in infrastructura mea. Lucrul asta nu mai functioneaza de la iOS 11 pentru ca developerul aplicatiei n-a mai updatat-o si pentru ultimul OS iPhone.
Nu am vrut sa activez notificarile prin email, deci am cautat alte metode prin care as putea sa trimit notificarile din Zabbix si am gasit ca cea mai usoara ar fi prin Slack. Am incercat sa integrez si prin alte metode, cum ar fi IFTTT (ma scarpinam invers) sau PubNub (prea complicat) dar am renuntat la idee.

Dupa „analiza pietei” am zic ca Slack e cea mai simpla rapida si mai usoara metoda. Plus ca inregistrarea in Slack dureaza maxim 3 minute (mai mult mi-a luat sa ma prind de ce nu primesc si pe telefon notificarile), e gratis, aplicatia e multiplatforma (Web, iOS, Android, Linux, Windows, Mac), iar in maxim 15-20 de minute ai terminat de configurat Slack si Zabbix.

Pasi pentru integrare (recomand sa cititi aici mai multe informatii):

  1. Dupa configurarea workspace-ului Slack, trebuie activat webhooks in Slack. La configurarea Webhooks eu am ales un canal nou in loc de un user, chiar daca sunt un one-man show. Poti sa configurezi sa trimiti notificari catre mai multe canale sau mai multi useri. E util cand ai mai multi oameni care se ocupa de diferite lucruri.
  2. Descarci scriptul si-l pui in folderul de alerte in Zabbix. In momentul asta poti sa testezi daca ai facut bine integrarea/configurarea Webhooks cu Slack. Daca reusesti sa trimiti mesaje din shell, atunci poti merge la pasul urmator
  3. Configrezi in Zabbix un media type nou, o alerta noua, o actiune noua, etc. Mai multe detalii gasesti aici. Din momentul asta nu mai ai treaba cu Slack si Webhooks. Daca la pasul 2 ai reusit sa trimiti mesajul de test, tot ce trebuie sa mai faci e sa configurezi Zabbix sa trimita alerte cum vrei tu.
  4. Dupa ce ai configurat Zabbix, poti opri agentul de pe un server si poti sa testezi daca notificarile ajung in canalul de Slack ales de tine.

 

Mai sus e un exemplu de notificare reala.

Bonus: By default aplicatia de mobil nu te notifica daca nu esti idle pe aplicatia de pe PC. Practic atata timp cat nu folosesti aplicatia de mobil (sau cat timp esti logat pe PC si il folosesti) primesti notificari doar pe PC. Acest lucru se poate dezactiva din setarile aplicatiei.

Comenzi ce nu trebuie rulate pe Linux (daca nu stii ce fac)

O sa scriu o lista cu cateva comenzi ce nu ar trebui rulate pe Linux daca nu stii ce fac.

  1. (sudo) rm -rf / – e probabil cea mai cunoscuta comanda si functiona acum ~10 ani.
    Ce face?
    Sterge sistemul de operare si toate discurile ce sunt montate in momentul ala pe sistem. Observati cuvintele „toate discurile montate”. Ce nu e montat, e salvat de la stergere. Ce este montat in momenul rularii comenzii, se va sterge (chiar si remote file-systems).
    De ce era functionala acum ~10 ani? Pentru ca acum nu mai merge:
  2. rm -rf .* – o variatie a comenzii de mai sus. Alte variante ar fi rm -rf * sau rm -rf /*
    Ce face?
    Primele doua comenzi sterg continutul folderului in care te afli. Ultima face acelasi lucru ce incearca comanda de la punctul 1 sa faca, dar de data asta functioneaza fara warning.
  3. dd if=/dev/zero of=/dev/sdX
    Ce face?
    Scrie cu 0 pe HDD. Nu vad vreo problema in a scrie cu 0 tot HDD-ul daca asta vrem sa facem. Trebuie doar sa fim atenti pe ce HDD scriem. Pana la urma, aici e vorba de atentie. Eu folosesc dd-ul ca sa scriu imagini pe stick-uri USB si in 10 ani de Linux am reusit o singura data sa imi stric MBR-ul si root-ul.
    Alternativa:> /dev/sdX
  4. mkfs.ext4 /dev/sdXY
    Ce face?
    Formateaza o partitie. Dar poate chiar asta vreau sa fac. La fel ca la comanda anterioara, trebuie doar sa fim atenti ce partitie formatam. Alternative ar fi inlocuirea ext4 cu ext3, btrfs, xfs, etc.
  5. cd ~; for x in `ls`; do mv -f $x $y; y=$x; done
    Ce face?
    Redenumeste fisierele din folderul in care este rulata comanda si sterge primul fisier.
    Exemplu: avem fisierele „a” cu continutul „a” si fisierul „b” cu continutul „b”. Dupa ce comanda a rulat, o sa avem fisierul „a” dar cu continutul „b”.

  6. find -type f -mtime +30 -exec mv {} /dev/null \;
    Ce face?
    Cauta fisierele mai vechi de 30 de zile si le muta in groapa de gunoi a Linuxului. (/dev/null)
    Alternative: mv ~ /dev/null sau mv / /dev/null. Prima sterge home-ul, a doua face acelasi lucru ca si comenzile de la 1 si 2.

Bonus:

:(){:|:&};:
rm -f /usr/bin/sudo
rm -f /bin/su
chmod -R 777 /*
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf /* || echo "You live" #ruleta ruseasca

 

De la 6-10MB/s la 60MB/s

Cum am cateva zile libere am zis aseara sa ma ocup putin de infrastructura mea de acasa, asa ca am inceput sa fac update la ultimele versiuni de OS pentru fiecare VM in parte, am rezolvat problemele pe care le-am descoperit de cand am setat Zabbix-ul sa trimita notificari, am facut o realocare a resurselor, (aparent dupa ce am refacut niste roluri pe pfSense mi-am dat seama ca nu are nevoie de 6GB de RAM), etc.

Dupa ce am terminat partea cu OS-urile am zis ca ar fi o idee buna sa fac niste modificari si la host, nu numai la masinile virtuale. Mi-a fost prea lene sa fac upgrade la ESXI, asa ca m-am intors la partea usoara: reconfigurarea masinilor virtuale. M-am hotarat ca e timpul sa renunt la clientul de Windows pentru VMWare si sa fac totul din interfata web pentru ESXI 6.5, asa ca am facut upgrade la VIrtual Hardware la versiunea 13, la doua masini ce nu sunt importante.

Din pacate am avut ceva probleme cu ele dupa upgrade (kernel panic cu toate versiunile de kernel) si singurul lucru pe care-l puteam vedea in loguri era legat de placa de retea. Am schimbat placa de retea din VMXNET3 in E1000 si n-am avut probleme timp de 12-13 ore, asa ca am zis sa fac upgrade si la torrentbox. Totul a decurs fara probleme, dar am fost curios care e diferenta (reala/practica) intre VMXNET3 si E1000.

Am intrebat pe Gogu si am nimerit peste un link in care se plangea cineva ca pe E1000 are aceeasi performanta (slaba) si cu TSO on si cu TSO off. Am vrut sa vad mai multe despre TSO si am dat peste link-ul asta si am rulat comanda ethtool -K ens33 tso off tx off sg off gro ca primarul. Din secunda aia all hell broke loose:

Spike-urile pe retea sunt de la niste teste de viteza rulate ca sa vad daca cineva face misto de mine. Aparent nu. Nu stiu de ce, dar faptul ca am dat disable la TSO a ajutat la cresterea vitezei destul de mult (de aproape 10 ori). Mai jos aveti o poza cu traficul pe ore, direct in pfSense, incepand cu ora 11 si pana acum cateva minute (16:23).

 

Inca ma mai gandesc daca sa fac aceeasi miscare si pe pfSense (upgrade la VM13 + E1000 + TSO off), dar daca o fac, revin cu un update in postarea asta.

 

UPDATE 15.08.2017

Se pare ca de fapt exista un bug in ESXI si aparent sunt afectat de el. Cum am spus, am updatat totul la zi (inclusiv kernelul). Se pare ca poti folosi orice versiune de kernel mai mica de 4.8 cu orice versiune de VM Hardware sau orice versiune de kernel cu VM Hardware < 12 ca sa nu ai probleme cu bug-ul.

Eu am VMH13 cu Kernel 4.11 pe masinile mele. O sa incerc un kernel LTS mai vechi cu VMXNET3 si VMH13 sa vad ce se intampla.