Archives

sh2log pentru momentele când vrei să știi.

Sunt momente când mai mulți oameni lucră pe aceeași mașină/server iar pentru a evita discuții inutile, au fost inventate diverse sisteme de monitorizare.

Și, la fel ca în multe alte cazuri, cele mai eficiente se dovedesc a fi cele vechi (oldies but goldies?)

sh2log este un keylogger (de prin 2006), o aplicație care întregistrează toate comenzile care sunt rulate pe o anumită mașină și apoi oferă posibilitatea vizualizării integrale (și foarte interesant – interactive) a unei sesiuni de lucru.

Am apucat să testez această aplicație pe sisteme CentOS(5) și Ubuntu(10.04, 12.04) și nu pot garanta funcționarea pe alte sisteme, așa că nu recomand testarea decât pe mașini de test.

Despre sh2log se poate citi pe pagina dedicată din packet storm.

Singura cerință pentru a putea instala și rula sh2log este să existe biblioteca de development libX11.
Aceasta trebuie instalată înainte de a compila sh2log.

Pe sisteme Ubuntu comanda de instalare este:

$ sudo apt-get install libx11-dev 

În cazul sistemelor CentOS (cu drepturi de root):

# yum install libX11-devel 

După aceasta procesul e foarte simplu.
Întâi trebuie descărcată arhiva, extrase fișierele și compilat sursele.

# wget http://packetstormsecurity.com/files/download/51780/sh2log-1.0.tgz
# tar zxvf sh2log-1.0.tgz
# cd sh2log-1.0
# make linux

Odată compilarea încheiată, trebuie înlocuite executabilele bash și sh (păstrând și o copie a fișierelor inițiale):

#mkdir /bin/shells/
# cp -p /bin/sh /bin/shells/
# cp -p /bin/bash /bin/shells/
# rm -rf /bin/sh /bin/bash
# cp -p sh2log /bin/sh
# cp -p sh2log /bin/bash

La final, după ce toți pașii au fost executați cu succes, se lansează aplicația de monitorizare:

# ./sh2logd

Din acest moment, orice nouă consolă (fizică sau virtuală) va fi înregistrată.
În directorul în care a fost compilată aplicația vor apărea fișiere având nume de tipul sh2log-20140207-082100.bin

Pentru a vizualiza înregistrările se lansează executabilul parser.

# parser sh2log-20140207-082100.bin 

iar apoi se selectează modul în care se dorește a fi făcută vizualizarea.

Deși nu e o practică recomandată, uneori oferă informații utile despre activitățile desfășurate pe un computer.

Cisco AnyConnect și problemele lui în Ubuntu

Dacă ar fi să calculez orele pierdute încercând să dau de cap diferitelor probleme între echipamente și servicii Cisco (fie ele routere nu neapărat ieftine, Webex sau mai nou clienți de VPN), aș crede că la Cisco au rămas doar echipele de dezvoltatori specializați pe .Net.

Nu de alta dar altfel nu-mi explic cum au reununțat de exemplu la suportul pentru Linux și Mac la meetmenow.

Recent am avut o nouă surpriză.

Unul din clienții ne dă acces spre serverele sale, servere aflate într-un VPN. Până aici, nimic nou sub soare. Însă în momentul în care am instalat versiunea pentru Linux a AnyConnect (care printre altele e relativ bine ascunsă și ajungi la linkul spre ea doar după ce crapă componenta Java), când să configurez clentu’ iaca surpriză… acesta nu funcționa, afișând o minunată eroare: “AnyConnect cannot confirm it is connected to your secure gateway. The local network may not be trustworthy. Please try another network.”

Acuma, ce să zic… m-aș fi dus eu în altă cameră, în altă rețea (eventual aia din crâșma vecină) dar conștiința nu și nu… și mă apuc de căutat soluții.

Cu puțin noroc (a fost o zi cu karmă bună) am găsit pe oit.ncsu.edu soluția problemei mele, se pare că pentru a aplicația se uită aiurea după certificatele, în special la CA prezente în sistem.

După ce am făcut structura de directoare pe placul său – /opt/.cisco/certificates/ca/ am copiat în directorul ca toate fișierele din  /etc/ssl/certs.

$sudo cp /etc/ssl/certs/* /opt/.cisco/certificates/ca 

Nu am testat, dar e posibil ca un link simbolic să rezolve de asemenea problema.

Ce este de asemenea de ținut minte, Cisco AnyConnect nu merge dacă este lansat ca root (cu sudo).

Oameni înfometați….

De când cu atâtea variațiuni pe temă dată (distribuții GNU/Linux, sisteme de operare mobile etc) încep să cred că, așa la modul general, foamea de informație vine din stomac 🙂

Nu de alta dar nu e zi să nu aud de YUM, Yaourt, Ice Cream Sandwitch, Kit Kat și alte lucruri care-mi excită găurile din stomac într-un mod nu neapărat plăcut…

Nu știu dacă prin KDE mai găsesc chocolat…. însă dacă mai scriu mult despre asta îmi va pluti tastatura…

SkyJack, caută, convinge și aduce acasă dronele (altora)

Nu (mai) este un scenariu de film SF…. nu că n-aș fi văzut aduse la viață (în viața asta, culmea) mai toate ideile interesante din filmele copilăriei… dar asta-i cea mai recentă.

Mai săptămâna trecută citeam știrea conform căreia Amazon testează serviciul de livrări utilizând drone, drone care-ți lasă pachetu’n fața ușii și-și văd cuminți (și ieftin, fără a cere drepturi sindicale, dar asta e altă discuție) de treabă. Bine, asta funcționează (va funcționa) în țări “pă’ orizontală” că la mine-n bloc în afară de hoți, polițai și ăia de aduc biblii (cam toți în aceeași echipă nu-i așa?) nu nimerește mai nimeni etajul. Până și găgâl îmi arată pe hărțile astea actualizate blocul mai la două străzi de unde e el de fapt 🙂

Foto: BBC

Dar, revenind la livrările cu drone… numa’ bine ce-a povestit Amazon de ideea de a expedia pachete cu drone și au apărut primele încercări de deturnare a dronelor. Și despre un astfel de proiect voi povesti eu acuma.

Pre numele lui SkyJack, proiectul dezvoltat de @SamyKamkar propune o dronă care știe să caute singurică semnalul altor drone aflate în zbor, apoi prin fireless prea controlul asupra dronelor găsite și le transformă (așa cum spune inventatorul) într-o armată de drone zobmie aflate sub controlul tău.

Nu toate dronele pot fi atacate, momentan aplicația poate deturna doar dronele Parrot AR.Drone folosindu-se de adresele MAC ale companiei Parrot.
Aplicația este disponibilă în githul și este scrisă în perl, așa că poate rula pe orice mașină GNU/Linux, folosește aircrack-ng pentru a pune în modul de monitorizare placa sa wi-fi,apoi folosește aireplay-ng pentru a scoate drona de sub controlul proprietarului de drept și la final, folosind node-ar-drone (Javascript și node.js) controlează drona spre casă.

Ca dispozitive fizice, au fost testate și funcționează: o dronă Parrot AR.Drone 2, un Raspberry Pi, un adaptor fireless Alfa AWUS036H și unul USB Edimax EW-7811Un și o baterie USB.

Sursele pot fi accesate de la https://github.com/samyk/skyjack iar pagina de urmărit pentru viitoarele faze ale proiectului este http://samy.pl/skyjack

BIOS-uri idioade vs LVM = timp pierdut, nervi și mulți morcovi….

Se pare că uneori, după ce reușesc să rezolv unele probleme, mintea mea izolează (șterge sau ce-o face ea) evenimentul… și din păcate (uneori) soluția găsită.

Pe tiparul acesta, zilele trecute când un coleg a venit cu un harddisk bușit am stat și am dat cu presupusul mai bine de o oră până când am găsit rezolvarea.

Problema era că acel hard fusese introdus într-o mașină (mai veche) al cărei BIOS a hotărât că SATA trebuie tratat ca RAID. Drept pentru care a bușit partiția. Cum discul era inițial era LVM, de aici start distracție.

Acum câteva luni am avut parte de o distracție similară, când unul din serverele unui client a cedat iar când a sosit serverul nou, discul vechi nu a mai putut fi folosit dar după cum ziceam, memoria mea se dovedește a fi scurtă, scurtă…

Dar, revenind la cazul acesta, după ce am reușit să refac sistemul de fișiere cu Testdisk, am obținut doar mesajul de oroare atunci când încercam să montez partiția cu pricina:

mount: unknown filesystem type 'LVM2_member'

Fdisk-ul afișa corect partițiile și sistemul însă de pomană.

După înjurături și căutări care în marea majoritate îmi întorceau răspunsuri de tipul “formatează și pune din backup” am (re)găsit soluția salvatoare… și mi s-au activat senzorii

Am instalat lvm2, apoi cu un lvmdiskscan am obținut lista partițiilor:

# lvmdiskscan
/dev/ram0 [ 62.50 MB]
/dev/ram1 [ 62.50 MB]
/dev/hda1 [ 101.94 MB]
/dev/sda1 [ 39.19 MB]
/dev/ram2 [ 62.50 MB]
/dev/hda2 [ 485.58 GB] LVM physical volume
/dev/sda2 [ 2.01 GB]
/dev/ram3 [ 62.50 MB]
/dev/sda3 [ 60.00 GB]
/dev/ram4 [ 62.50 MB]
/dev/sda4 [ 86.96 GB]
/dev/ram5 [ 62.50 MB]
/dev/ram6 [ 62.50 MB]
/dev/ram7 [ 62.50 MB]
/dev/ram8 [ 62.50 MB]
/dev/ram9 [ 62.50 MB]
/dev/ram10 [ 62.50 MB]
/dev/ram11 [ 62.50 MB]
/dev/ram12 [ 62.50 MB]
/dev/ram13 [ 62.50 MB]
/dev/ram14 [ 62.50 MB]
/dev/ram15 [ 62.50 MB]
0 disks
21 partitions
0 LVM physical volume whole disks
1 LVM physical volume

După care, cu lvmdisplay, am obținut numele volumului

# lvmdiskscan
lvdisplay
--- Logical volume ---
LV Name /dev/VolGroup00/LogVol00
VG Name VolGroup00
LV UUID xxxxxxxxx

și toate celelalte componente ale sale.

Cu toate astea și încercarea de a monta volumul folosind numele a fost un eșec.

# mount /dev/VolGroup00/LogVol00 /mnt/tempdisk/
mount: special device /dev/VolGroup00/LogVol00 does not exist

La scanare am văzut că statusul e inactiv:

# lvscan
inactive '/dev/VolGroup00/LogVol00' [485.58 GB] inherit
inactive '/dev/VolGroup00/LogVol01' [14.42 GB] inherit

Apoi, mulțumită unui “pățit”  am găsit soluția:

# modprobe dm-mod
# vgchange -ay
# lvscan
ACTIVE '/dev/VolGroup00/LogVol00' [485.58 GB] inherit
ACTIVE '/dev/VolGroup00/LogVol01' [14.42 GB] inherit
# mount /dev/VolGroup00/LogVol00 /mnt/tempdisk

Și am făcut un om fericit că-și poate accesa datele de pe discul cu pricina.

Conectarea la o mașină Ubuntu prin RDP

Se făcu’ că prin conjucția unor planete (nu știu care) o companie ia hotărârea să renunțe la folosirea Windows pe computerele din anumite departamente. O decizie salutară… care însă a născut o problemă: cum se mai pot face conexiuni la distanță pe acele mașini, de pe stațiile de lucru care încă rulează Windows, fără a instala pe acestea din urmă nici o aplicație suplimentară.
Pam, pam… temă de casă.
După momentul Kodak… am propus soluția RDP prin VNC :D… toată lumea a fost fericită… amu’ rămâne doar să fie pusă în practică… iar cum în spatele meu nu era nimeni caruia să-i “pasez pisica”… am suflecat mânecile de la maiou și… am purces la căutări.
Din fericire, soluția există și culmea… mai și funcționează… așa că, pentru nemurirea informațiunii (vorba volant):
În primul rând, soluția funcționează pe Ubuntu 12.04 (adică pe versiunea asta am testat, e posibil să funcționeze și pe altele însă… eu nu știe).

Prima dată trebuie permis accesul remote:
– Click pe dash, scris “desktop” și clic pe “Desktop Sharing” iar apoi se bifează prima opțiune “Allow other users to view your desktop”. Clic pe “Close”.
desktopsharing

În momentul acesta, în teorie “vino”  este instalat și are o configurație de bază.

Amu’ e momentul instalării xrdp

$ sudo apt-get update && sudo apt-get --no-install-recommends install xrdp 

Partea cu –no-install-recommends nu am știut-o la început și m-am trezit cu o căruță de lucruri care au făcut să nu-mi funcționească conexiunea…
Pe parcursul instalării trebuie citit cu atenție ce “varsă” terminalul și nu în ultimul rând, cheile sunt generate corect și salvate corespunzător.

Acum trebuie să configurăm vino:

$ sudo vi /usr/share/applications/vino-preferences.desktop 

Aici trebuie comentată linia
OnlyShowIn=GNOME;

Salvat/închis.

Iar apoi, trebuie să-i spunem și xrdp-ului că trebuie să lucre prin vncc

$ sudo vi /etc/xrdp/xrdp.ini 

În care trebuie să rămână doar:

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1

[xrdp1]
name=RDP2VINO
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=5900

Salvat, închis și restartat serviciul

$ sudo service xrdp restart 

În mod normal, atât ar trebui să fie suficient pentru a putea folosi clientul de Remote Desktop din Windows pentru a efectua o conexiune la o stație Ubuntu.

În cazul în care nu e ziua aceea norocoasă și conexiunea nu se întâmplă… ar mai fi de gâdilat:

De exemplu, dacă după conectare apare doar un desktop gol (cum am avut eu nenorocul pe 2 stații de lucru) trebuie forțat xrdp să folosească ubuntu-2D (sau gnome-fallback) ca environment pentru desktop.
Pentru a face asta, trebuie creeat în directorul utilizatorului, un fișier pe numele lui .xsession care să conțină:

gnome-session –session=ubuntu-2d 

În cazul meu asta fost suficient pentru a face lucrurile să funcționeze conform cerinței.

Orice hard poate fi umplut…

Și bineînțeles, de cele mai multe ori, cu cât e discul mai mare, cu atât mai puțină atenție va primi… Și așa se face că azi dimineață, după un upgrade m-am trezit că partiția mea de boot mai are doar 200Kb liberi… și că noul kernel care vrea să se instaleze acolo…. nu prea mai are pre unde.

Și m-am apucat eu să caut prin linkurile salvate hăt prin toate browserele folosite în cursul timpului și am dat de un link (de prin 2011, probabil ultima dată când m-am confruntat cu o problemă asemănătoare) care oferă probabil cea mai rapidă soluție de curățenie:

 $ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge 

remove_kernel

Și se făcu așadar lumină-n sat și 4Gb am câștigat 🙂  și pre acilea am notat… ca data viitoare să nu mai caut ca orbu’ Brăila.

Mici probleme cu Munin 1.2.5 după un upgrade hardware

Se întâmplă că unul dintre clienți și-a upgradat serverele…. Toate bune și frumoase, performanțele sunt vizibile… însă apar și bubele.

Munin-ul de acolo a fost instalat în mezoliticul timpuriu și a rămas neactualizat atunci când acest lucru s-ar fi putut face fără pierderea graficelor și a datelor istorice.

Astfel că acum după ce au apărut mai multe procesoare decât se aștepta să vadă Munin acolo iar conexiunea la rețea este de asemenea mult mai rapidă… s-a întâmplat că datele din grafice nu mai prezintă realitatea.

Dacă pentru problema traficului pe plăcile de rețea am putut înlocui plugin-ul if_ cu ip_, pentru procesor am avut de săpat.

Până la urmă, afișarea poate fi “reparată” prin modificarea unei linii în plugin-ul cpu.
La linia 72 (presupun că numărul liniei poate varia) se află:

 NCPU=`expr \`grep '^cpu. ' /proc/stat | wc -l\` - 1` 

Pentru a afișa din nou corect graficul cpu când serverul are mai mult de 8 procesoare, linia trebuie modificată încât să arate astfel:

 NCPU=`expr \`grep '^cpu.\{1,2\} ' /proc/stat | wc -l\` - 1` 

În următoarele minute de după restartarea munin-node graficul cpu ar trebui să arate valori corecte care să fie reprezentative pentru toate procesoarele din sistem.

Pentru a activa pluginul ip_ in locul if_ sunt necesari următorii pași:

1 – În fișierul de configurare munin-node (de obicei în calea etc/munin/plugin-conf.d/munin-node) se adaugă:

[ip_*]
user root 

2 – Se creează o regulă în iptables pentru a colecta datele pe un ip specific:

 iptables -A INPUT -d <ip>;iptables -A OUTPUT -s <ip> 

3 – Se instalează plugin-ul pentru ip-ul specificat la pasul anterior:

  ln -s /usr/share/munin/plugins/ip_ /etc/munin/plugins/ip_<ip> 

4 – Se restartează munin-node.

Pașii 2 și 3 se repetă pentru fiecare ip pe care vrem să-l vedem în graficele Munin.

Ubuntu pe laptopul personal… o mică discuție despre securitate.

Probabil toți am auzit cel puțin o dată – “Nu există viruși în Linux” sau că “Linux e cel mai sigur sistem de operare”.

Las la o parte discuția despre distribuții și faptul că Linux e până la urmă doar kernelul sau orice altă discuție legată de care distribuție este “mai bună”. Ceea ce vreau să aduc în discuție este securitatea în Ubuntu (aceasta este distribuția pe care-mi petrec cel mai mult timp și despre care pot vorbi cât de cât în cunoștință de cauză). Iar dacă tot se cheamă că sunt “propagandist” (ca să citez un amic), iată câteva sfaturi despre securitatea mașinii personale.

Comparativ cu oricare versiune a sistemelor de operare Windows, Ubuntu oferă o mult mai bună securitate, chiar și fără ca utilizatorul să intervină în vreun fel. Dar, chiar și Chuck Norris dacă ar sta cu chiloții la nivelul gleznelor și aplecat să citească de pe chiștoace în parcul Operei s-ar putea să aibă vizitatori… așa că, mai ales în vremurile acestea când majoritatea datelor importante (proiecte, documente, emailuri) stau pe mașini portabile și conectarea la rețele mobile gratuite devine un lucru din ce în ce mai uzual, cred că e un moment bun să aduc în discuție câteva recomandări de bun simț (nu inventez apa caldă, au fost toate enunțate până acuma însă… repetiția e mama învățăturii…).

Folosiți parole “adevărate”.

O parolă ca “123456”, chiar dacă îi pui și numele sau prenumele ca prefix/sufix este o parolă vulnerabilă. Folosește pentru fiecare utilizator configurat o parolă cât mai complicată. Numele melodiei sau formației preferate (înlocuind litere cu numere și/sau semne speciale) poate fi o parolă bună (ex. [email protected] sau orice altă combinație pe modelul ăsta poate da ceva bătăi de cap unui vizitator nepoftit care încearcă să se conecteze la calculatorul tău). Nu uita că odată ce ai oferit acces fizic la tastatură, orice parolă este inutilă, indiferent cât de complicată este ea.

SSH pe orice alt port decât cel standard.

Dacă ai nevoie să ții un server de SSH pornit pentru a oferi acces de la distanță pe laptopul tău, asigurăte că modifici portul de conectare. Folosește porturi din gama superioară, porturi care nu sunt în intervalul scanat de obicei de către programele care caută automat vulnerabilități. Folosirea unui port ca 21347 reduce cel puțin cu 80% numărul de încercări de conectare pe SSH.

Nu țineți terminale deschise ca root.

root este nivelul de securitate cel mai ridicat. Cine are în mână contul de root poate face orice pe mașina cu pricina. În Ubuntu, conectarea ca root se poate face (și ăsta e un lucru bun în opinia mea) doar după ce te-ai logat cu un alt utilizator, folosind sudo. În cazul în care ai de făcut instalări/configurări/reconfigurări, folosește pe cât posibil sudo. Dacă totuși sunt lucruri care nu pot fi făcute cu sudo și este necesară utilizarea unei console cu utilizatorul root, asigură-te că nu lași alte persoane să-ți butoneze laptopul.

Instalează actualizările de sistem.

Ubuntu este un sistem în care comunitatea este foarte importantă. În fiecare moment, utilizatorii care identifică bug-uri sau au probleme raportează acete lucruri iar dezvoltatorii încearcă să fixeze problemele. În acest mod, problemele, vulnerabilitățile etc. ajung să fie fixate de multe ori înainte ca tu să te lovești sau să afli de ele. Un sistem actualizat este mult mai sigur.

Instalează un antivirus.

Deși probabilitatea infectării cu un virus “de Linux” este redusă, în momentul în care schimbi informații cu alți utilizatori, un antivirus este necesar. Scanează fișierele pe care le primești, chiar dacă teoretic nu-ți pot face rău. Nu e frumos să dai mai departe viruși.
ClamAV sau oricare antivirus open-source sau gratuit e ok

Nu rula comenzi copy/paste dacă nu știi ce fac.

Sunt nenumărate site-uri și bloguri unde oamenii oferă soluții sau arată cum se pot face mai ușor, mai simplu, mai eficient lucruri direct din consolă. Deși marea majoritate pot fi bine intenționați, unii pot greși și pune comenzi greșite. Nu-ți dorești să-ți ștergi toate fișierele (de exemplu) pentru că cel care a scris linia cu pricina conține din greșeală un “rm” (cu opțiunile de rigoare).

Citește cu atenție linia, copiaz-o într-un editor text pentru a te asigura că sintaxa e ok și face ceea ce te aștepți și doar după aceea rulează acea comandă.

Folosește un firewall.

Instalează-ți o aplicație de firewall (o interfață grafică eventual). Firestarter sau Gufw te pot scăpa de multe dureri de cap.

Ai grijă ce surse folosești pentru aplicații.

Asigură-te că aplicațiile pe care le instalezi provin din surse de încredere. Chiar dacă pare un PPA ok, aruncă un ochi în ce se mai află acolo. Altfel poți risca să instalezi pachete care-ți pot da peste cap sistemul.

Folosește o aplicație ca Wireshark.

Dacă ai cel mai mic dubiu că se întâmplă ceva ciudat în rețeaua în care ești pornește un Wireshark (sau orice aplicație similară care ți se pare a fi ok). Așa poți vedea ce trafic se desfășoară prin plăcile tale de rețea.

Folosește conturi separate pentru utilizatori

Dacă pe laptopul tău lucrează și nevasta, copilul, mătușa Tamara, etc. fă-le câte un cont separat. Așa te asiguri că sistemul tău nu va fi pus în pericol din greșeală iar eventualele probleme cauzate de comenzi greșite se vor limita la contul sub care vor fi rulate.

Cam astea-s lucrurile care-mi vin în cap în acest moment… Orice alte recomandări sunt binevenite.

Avem Ubuntu 12.04 Precise Pangolin – de unde-l putem descărca

De ieri din jurul prânzului avem parte de Ubuntu 12.04 LTS. Noutatea majoră (din punctul meu de vedere) este prelungirea de la 3 la 5 ani a suportului pentru versiunea de desktop.

Cum imediat după ce a fost publicat oficial site-ul Ubuntu a fost luat cu asalt, m-am gândit că e utilă o enumerare a metodelor alternative de descărcare.

În primul rând Ubuntu 12.04 poate fi descărcat folosind un client de torrente folosind unul din torrentele :

Când scriu acest post, acestea oferă o viteză decentă de descărcare.

În cazul în care nu aveţi un client de torrente şi/sau nu puteţi descărca, puteţi descărca prin http/ftp sau rsync de la oricare din adresele prezentate în lista oficială de mirror-uri, listă pe care o puteţi găsi aici.

Din această listă am extras serverele din România astfel:

 Server Protocol Viteză
UPC Romania http ftp 1 Gbps
Agency ARNIEC/RoEduNet http ftp rsync 1 Gbps
xServers Hosting – Romania http ftp rsync 1 Gbps
ArLUG (Arad Linux Users Group) http ftp 10 Mbps

Succes la descărcare.

© 2009-2019 Alex. Burlacu
%d bloggers like this: