Archive forNetworking

The Age of Insecurity (part 3)

Vorbesc deja de ceva ani (in mod repetat) despre “The Age of Insecurity”.

Ei bine, am avut ocazia să țin recent un curs de security. Și ca de fiecare dată când îmi fac temele pentru așa ceva, m-am speriat de ce se întâmplă în jur.

În primul rând, numărul de atacuri reușite la adresa companiilor mari a crescut dramatic în ultima vreme. Doar în 2013 și-au luat-o Twitter, Evernote, Living Social, Northrop Grumman (da, băieții care fac bombardiere B2, drone, etc :) ), Adobe (care a pierdut 150 de milioane de conturi, cu username și parole), Yahoo! Japan, eBay, Target, T-Mobile

Și cele de mai sus sunt doar o mică parte dintr-o listă foarte mare – dacă sunteți curioși, aruncați un ochi aici. Filtrați după anul 2013, și veți vedea zeci de exemple. Și țineți cont că în general site-ul se limitează doar la cazurile din US!

Partea cea mai gravă este însă alta – în timp ce atacurile se intensifică, software-ul de securitate are probleme din ce în ce mai mari. OpenSSL a avut Heartbleed, și acum au găsit încă vreo 6 vulnerabilități prin el. Denyhosts este unmaintained de ceva timp, și ca urmare a fost scos din repository-urile Ubuntu 14.04. Și Truecrypt a fost și el discontinued recent (pentru TC chiar nu știu vreun înlocuitor rezonabil pe Windows. Și vă rog, nu spuneți Bitlocker!!).

Se spune că un blestem chinezesc zice „may you live to see interesting times!” Ei bine, se anunță vremuri interesante…

Comments (2)

IOS ZBF DNS Translation

People who have worked with Cisco ASA probably know about an interesting feature – “DNS doctoring”. Basically, if you have static NAT configured on an ASA, and the device sees a DNS query/reply going between the NAT inside and outside interfaces, it will actually look inside the packet, and change its contents. Which is actually a useful feature in cases where one cannot (or doesn’t want to) configure split DNS on the name server.

For example, let’s say you have an internal mail server (172.16.1.10), statically translated to a public IP address (5.5.5.10). When the internal clients try to access “mail.example.com”, the (internal) nameserver will give them the correct (internal) IP – 172.16.10.10. When external clients try the same query, the reply will go through the ASA, and the external clients will receive the correct (external) IP – 5.5.5.10. And everything works.

The problem starts when Cisco IOS starts to do the same thing. It appears that if you’re running ZBF (Zone-Based Firewall) on Cisco IOS, it will automatically have the same behavior – translating DNS A and PTR queries as they go across the NAT.

However, there are two issues with the implementation:

1) Something is wrong with the translation. It seems to change the query, but not the answer. Using the same example as above, I try a reverse query for the external IP of the mail server:
root@thermite:~# host -vv  5.5.5.10
Trying “10.5.5.5.in-addr.arpa”
;; Question section mismatch: got 10.1.16.172.in-addr.arpa/PTR/IN

Notice the issue? I ask about the public address. My query gets translated by ZBF, and the server receives a query about the private address. However, when the reply comes back to me, the “question” section in the reply is not translated back. My client asked about 10.5.5.5.in-addr.arpa, and received a reply about 10.1.16.172.in-addr.arpa – which is ignored. Hence, my DNS resolution doesn’t work…

Not a problem – I’ll just disable DNS deep packet inspection! After all, it used to be quite easy on the ASA (just remove DNS from the list of deep-inspected protocols). Well… there’s the second problem!

2) Disabling the feature isn’t easy. After spending a long time looking through Cisco’s documentation (with no results), I managed to find the answer on the support forums:

no ip nat service alg tcp dns

no ip nat service alg udp dns

And yes, I have to agree with the person asking the question – “Very funny, Cisco! Now whose bright idea was that????!!”

 

Comments

vSphere Lab Storage Tests

Having just completed an upgrade of my vSphere lab equipment (and having nothing better to do over a weekend :) ), I decided to test several free shared storage options. And I have to admit – the results were… pretty surprising!

What I used for the test:

  • server OS: vSphere 5.1
  • client virtual machine – IOMeter running on Windows 7, 4 vCPUs, 4GB RAM. To avoid any issues with contention, I dedicated an entire server just for this machine.
  • storage VMs: Ubuntu Linux 12.04LTS (NFS), FreeNAS (iSCSI and NFS), and NexentaStor Community Edition (iSCSI and NFS). Each VM had 16GB of RAM and 4vCPUs (with a notable exception for Ubuntu, mentioned below). Again, an entire server was dedicated to each machine, to avoid contention issues.
  • storage subsystem: 4x1TB SATA disks, 7200 RPM, RAID5 on a dedicated controller. The array was presented as an RDM to each storage VM in turn (in case you’re wondering how I got local SATA to work via RDM, this link will help . In my case, I used vmkfstools -z). In the storage VM, the RDM was connected to a separate SCSI controller, and configured as an independent persistent disk
  • network connectivity: 1Gbps Ethernet

As you can see, there is nothing “high performance” about this setup. My goal was not to see which software is best in a production environment (there are plenty of such benchmarks online, and plenty of other factors affecting that decision). I was simply trying to answer a simpler question – given a small lab deployment, what storage solution would allow me to play with vSphere’s advanced features, while at the same time being easy to set up and offering decent performance?

I made no attempt to improve performance – I just took the RDMs, and presented them via NFS or iSCSI, without changing any other settings (with the exception of NFS synchronous mode for

As a control, I also ran the tests against a Synology DS411j box (4x2TB 7200rpm SATA drives, RAID5), as well as against a vmdk on a pair of local drives (2x320GB 10K SAS drives, RAID1).

Moving on to IOMeter settings, here they are:

  • 4 workers
  • 1 outstanding I/O request for each worker
  • 0% random (so sequential requests only)
  • 100% read or write
  • 512B/4KB/32KB request size

Each test was run for 3 minutes, with a 10 second ramp-up time. The same 10GB .icf file was used for each test (I just vMotioned the corresponding disk from one storage device to another).

And here are the results:

IOPS Results

Bandwidth Results

Some comments:

  • I was amazed to see that the “basic” NFS configuration on Ubuntu was by far the fastest (IOPS-wise), surpassing both Nexenta and FreeNAS by a margin of more than 50% (!). Even more amazed, in fact, considering that the Ubuntu VM I had available was running on only 1vCPU and 1GB of RAM (!!). That is why I ran the test two more times – once after changing the settings to match the other VMs (4vCPUs and 4GB RAM), and once more after finishing all the other tests (just to make sure that this was not a glitch). The results stayed the same.
  • For FreeNAS, the initial NFS tests were disappointing (writes would peak at around 500 IOPS). After some digging around, it looks like even after enabling asynchronous mode under NFS settings, vSphere writes are still treated as synchronous. So I ran the test once again after forcing asynchronous mode ( zfs set sync=disabled volume/name ), with improved results. Quick note – do NOT do this unless you have a NVRAM/battery backed storage unit (or you don’t care about the data getting corrupted)!
  • You can see the same write penalty on NexentaStor. In that case, the NFS settings were left as “default” (neither forced sync nor forced async), which led to the same issue with synchronous writes.
  • Other than the NFS sync/async issue, there was no significant difference between iSCSI and NFS
  • There is also a write penalty on the local disks, which I cannot explain (it goes well beyond the expected 2:1 penalty imposed by RAID-1)
  • The bandwidth graphs are limited by the network – at larger request sizes, most solutions are easily able to saturate the 1Gbps link I had available.
  • The Synology unit was limited by its hardware. The j-series are the low-end 4-bay units, and this impacts performance – during testing, the CPU would stay above 90% utilization. Had I had access to a higher-end unit (a DS15XX, or even a RackStation), I am sure that the results would have been very different. But this was all I could afford at the moment :)

The conclusion? If you want to play with shared storage in your lab (and have some Linux experience), running a simple NFS server is both the easiest to configure and the fastest solution (you can find a tutorial here – just don’t forget to use async instead of sync if  you have battery backup – or if performance means more to you than your data :) ).

If you don’t like the Linux CLI, I highly recommend FreeNAS. It is easy to install and configure, and offers decent performance.

And, of course, if you’d like to play with a more advanced system (and you’re not afraid of the steep learning curve), NexentaStor might just be the one for you. The Community Edition is completely free (up to 18TB of used storage capacity).

Before people start saying “software X is way better than that, why didn’t you do Y?”, please keep in mind that this was NOT meant to be a comparison of the software solutions. If I had taken the time to follow the official recommendations to improve performance, I am sure that the results would be very different. But I just wanted to compare the results “out of box” – present the disks to the software, and see what it can do with them.

Comments

Cisco, RDS si IPv6

Dacă tot se termină adresele IPv4 și RDS a început să ofere adrese IPv6, mi-am luat inima în dinți și am zis „hai să încerc și eu, măcar să văd dacă merge”.

Setup-ul folosit? Foarte simplu – una bucată router Cisco 881W, plus una conexiune RDS fiber-link.

Etapa 1 – citirea documentației.

Aflu că trebuie să activez serviciul online la RDS – nu-i problemă, 2 click-uri și se rezolvă.

După ce îl activez, aflu că „tot ce trebuie să faceţi în acest moment pentru a începe testele este să adăugaţi cuvântul “ipv6test” (case sensitive) în câmpul “Service Name” al clientului PPPoE”.

Pare simplu, numai că… oricât sap prin documentația Cisco, nu reușesc deloc să găsesc cum se setează „Service Name”. Sau, mai exact, găsesc doar cum se folosește el pe partea server-side, nu și cum (sau dacă) l-aș putea seta eu ca și client.

Noroc că dau pe net peste techtorials.ro . Unde Liviu listează exact configurațiile necesare. Profit de ocazie pentru a-i mulțumi încă o dată! :)

Etapa 2 – configurația propriu-zisă.

În cazul meu, interfața externă (PPPoE) este Dialer1 (peste interfața fizică FastEthernet4), iar interfața internă (spre LAN) este VLAN1. Configurația de adăugat arată cam așa:

ipv6 unicast-routing
ipv6 cef

ipv6 route ::/0 Dialer1 FE80::1

interface FastEthernet4
pppoe enable
pppoe-client dial-pool-number 1 service-name “ipv6test”

interface Dialer1
ipv6 enable
ipv6 address dhcp
ipv6 dhcp client pd PD_PREFIX

interface Vlan1
ipv6 address PD_PREFIX ::C:15C0/64
ipv6 enable

Pare simplu… n-ar trebui să îmi ia mai mult de 10 minute să îl configurez…

Etapa 3 – versiuni și licențe.

Începe distracția – constat că sunt comenzi care nu sunt acceptate. De exemplu “ipv6 address dhcp”, sau “ipv6 client dhcp pd”.

Bănuiesc inițial o problemă de versiune IOS, așa că fac un upgrade. Din păcate, nu ajută – se pare că un simplu feature de CLIENT DHCP este considerat de Cisco „advanced IP feature”. Ceea ce înseamnă că am nevoie de licență separată (Advanced IP Services) pentru a realiza configurația. Mă văd nevoit să amân testul până când reușesc să instalez licența.

Etapa 4 – descoperirea bug-urilor…

Am licența, configurez router-ul, și… încep să găsesc bug-uri. Mai exact:

  • pe IOS 15.x ( testat pe 15.1(3)T1 și 15.2(1)T1 ) , Prefix Delegation nu funcționează deloc. Văd cum se primește prefixul prin DHCP pe interfața externă, variabila PD_PREFIX e populata corect, dar prefixul nu apare și pe interfața internă. Apar în schimb o serie de erori destul de urâte – %SYS-2-BADPOOL si %ALIGN-3-SPURIOUS (erori de alocare/acces la memorie)
  • pe IOS 12.4(22)T Prefix Delegation funcționează corect, dar nu este suportată comanda „ipv6 address dhcp” (da, suportă Prefix Delegation via DHCPv6, dar nu știe să ia și adresă prin DHCPv6! Nu mă întrebați cum…). Am reușit însă să îl conving să își ia adresă prin autoconfig ( „ipv6 address autoconfig default” pe interfața externă ).
  • IOS 12.4(24)T5 a fost singurul IOS dintre cele testate care a mers OK. Și pare să meargă în continuare.

Per total, mi se pare îngrijorător faptul că tocmai codul recent din 15.x este cel cu probleme. Lucru care mă face să îmi fie un pic teamă de momentul în care vom fi nevoiți să trecem la IPv6 în producție…

Comments (4)

The End of IPv4?

Am auzit de el de mai bine de 10 ani. L-am așteptat cu înfrigurare, teamă, curiozitate… Și de fiecare dată a apărut ceva care l-a amânat.

Ei bine, se pare că se întâmplă. APNIC a primit încă 2 blocuri /8, ceea ce înseamnă că au mai rămas doar 5 blocuri nealocate. Conform politicilor IANA, ultimele 5 blocuri vor fi alocate rapid, câte unul pentru fiecare RIR.

Mai departe, RIR-urile vor aloca IP-uri către ISP-uri și utilizatori. Când se termină și rezervele… well… it’s IPv6 or this. :)

Comments (3)

RoTLD Reloaded

Cum în ultima vreme mă joc cu niște migrări măricele de zone, mă tot plimb pe site-ul RoTLD. Dacă tot am vorbit (și eu și Meekuu) de genialul mod în care se face validarea NS-urilor, nu pot să nu mai adaug două comentarii:

1. Stau de câteva minute să sap ca să îmi dau seama dacă parola de administrare a domeniului se trimite în clar sau nu. Până la urmă se pare că e HTTPS, dar nu e tocmai frumos să deschizi un link https într-un frame. Nu de alta, dar utilizatorul nu are nici o modalitate de a verifica certificatul primit.

Se pare că băieții care au făcut implementarea au fost colegi de clasă cu cei care au făcut implementarea 3DSecure (care e fix la fel de inspirată :) )

2. Nu pot să nu menționez modalitatea de plată cu cardul. Care presupune completarea unui formular cu toate datele cardului, și trimiterea lui prin fax împreună cu copie față-verso după card (adică număr card, nume deținător, CVV, absolut tot ce este necesar ca să îți dispară toți banii din cont). Și da, trebuie să ai o naivi^H^H^H^H^H încredere nemărginită că hârțoaga respectivă este procesată și stocată în mod sigur. Nu de alta, dar eu personal sunt foarte greu de convins că ea nu rămâne aruncată pe un birou, unde numai cine nu vrea nu poate înhăța datele respective.

Ambele mi se par niște lucruri cumva… neașteptate. Mai ales venind de la cei care se ocupă de aproape tot ce înseamnă Internetul din .ro.

Comments (4)

RoTLD si NS-urile fantoma

Acum ceva timp (când s-a desființat Thawte Web of Trust) am avut ocazia de a obține în mod gratuit un certificat SSL VeriSign. Ei bine, am pierdut ocazia respectivă – o condiție obligatorie pentru obținerea certificatului era reprezentată de validarea datelor deținătorului domeniului (informațiile whois). Și se pare că RoTLD este singurul registrar din lumea asta care refuză complet publicarea datelor respective în cazul în care deținătorul este persoană fizică (nu, cuvintele nu îmi aparțin – cei de la VeriSign au spus, textual, „așa ceva nu se poate – orice registrar trebuie să facă publice informațiile respective!”). Ei bine, la RoTLD se poate protecție cu forța.

Dar să trecem la subiect. La subiectul unor servere DNS care există și răspund bine-mersi, dar RoTLD se jură că „acest nameserver nu există. Vă rugăm contactaţi administratorul domeniului părinte!”.

Eu unul dețin mai multe domenii .ro (ubergeek fiind unul dintre ele). Și rulez propriile servere DNS. Pe care le mai mut din când în când, ocazie cu care trebuie să le schimb și IP-ul. Ca urmare, ca să nu trebuiască la fiecare mutare să schimb adresele IP ale NS-urilor pentru 10 domenii pe rotld.ro, am ales să configurez un singur set de NS-uri (fie ele ns1.ubergeek.ro și ns2.ubergeek.ro), și să le folosesc pe ele pentru toate domeniile. Dacă mă mut cu NS-urile, le schimb într-un singur loc (pe pagina de configurare a ubergeek.ro), și scap de bătaia de cap.

Soluția merge de ceva ani, și m-a ajutat foarte mult. Ca urmare, am încercat să aplic ceva asemănător și într-o anumită instituție de învățământ pentru care mai fac muncă voluntară :-P . Acolo aveam ns1.yyy.zzz.ro / ns2.yyy.zzz.ro, și am rugat oamenii care aveau domenii găzduite acolo să folosească doar NS-urile respective.

Nu a trecut mult timp și am început să primesc mesaje cu „nu merge”. Inițial am crezut că greșesc utilizatorii, și folosesc formularul de „adaugă NS pe domeniul curent”. Dar nu – am încercat și eu, și… surpriză! „Acest nameserver nu există!”.

Cum naiba nu există? E configurat corect la părinte – NS-urile pentru zzz.ro au configurate cele 2 NS-uri ale mele, împreună cu glue-urile (adresele IP) corespunzătoare. Am ping în adresele respective. Serverele sunt autoritative pe zona pe care vreau să o configurez, și răspund corect la cereri. Cum naiba îmi spui tu că „nu există”??

Ca urmare, mă decid să pun mâna pe telefon și să aflu răspunsul direct de la sursă (inițial am vrut să trimit un mail, dar nu credeați că autoritatea care se ocupă de numele de domenii Internet are și o adresă electronică de contact pe site, nu??). Să văd și eu ce înseamnă la ei „nu există”.

Sun, și trec pe la vreo 3 oameni până să dau de cineva care părea de la tehnic. Și care chiar părea dispus să mă ajute. Și începe o conversație de vreo 30 de minute, care a fost cel puțin… fascinantă.

De ce? Pentru că persoana cu care am vorbit (deși chiar bine intenționată, și dispusă să mă ajute) nu avea răspunsurile. Și mă tot punea on-hold, și îl întreba pe altul. Și după vreo 15 minute, a început să uite să mă pună on hold, și am avut plăcerea să aud pe fundal „ce puii mei vrea? Am treabă! Spune-i să facă așa, și gata!”, sau „Dacă mi-l dai la telefon, îi închid și am rezolvat problema!!”

Până la urmă reușesc să prind la telefon „vocea din fundal”. Și aflu că e obligatoriu ca NS-urile configurate să „existe la ei” (mai exact, să fie configurate glue-urile pentru ele pe TLD-ul corespunzător).

Ceea ce… pentru mine e cam neplăcut. Pentru că eu am un subdomeniu. Sunt autoritativ pe o zonă mică, pe yyy.zzz.ro. Nu am control asupra TLD-ului (zzz.ro), și nici nu ar trebui să am. Pentru că asta este toată ideea din spatele DNS-ului – delegarea responsabilității!

Încerc să îi explic și lui faptul că e ciudată restricția. Și el îmi spune că e normal ca ei să aibă în baza lor de date toate serverele NS pentru .ro (?!), și că restricția „e la fel la orice registrar”. Pun mâna pe tastatură și îi spun că nu pare să fie chiar la fel peste tot – am domeniu.net cu NS-uri ns1/ns2.xxx.sk. Și nu a comentat nimeni că „nameserver-ul nu există”. Îmi spune că dacă vreau pot să pun NS din .com pentru domeniile din .ro (!), dar dacă vreau să pun din .ro trebuie să existe la ei. Îi mulțumesc pentru explicații, și închid. Nu mai e nimic de zis, și nu are rost să mă cert.

Pe de o parte, chiar înțeleg și atitudinea de „lasă-mă naibii în pace, că am de lucru”. Am avut-o și eu de destule ori la viața mea (AJ știe :-P ). În plus, am o bănuială că tehnicii respectivi nu sunt atât de bine plătiți încât să stea să dea explicații detaliate pentru orice procedură implementată.

Pe de altă parte însă, undeva chiar se exagerează. Se impun niște restricții aberante, care nu ajută pe nimeni. Nici măcar pe ei, pentru că restricțiile respective nu îi ajută să mențină informațiile din baza de date la zi (am reușit să introduc un nameserver care era configurat la ei, dar nu era rezolvat de NS-ul superior, și ca urmare era complet useless).

Comments (4)

HP vs Oracle

[ Cititorii mei fideli au observat probabil (ambii :-P ) faptul că nu am mai postat nimic de mult timp. Motivele sunt destul de simple, legate de „real life getting in the way” și „I didn’t really care enough about anything to post it” :) . Totuși, din când în când mai apare câte o poveste interesantă, și simt nevoia să o postez. ]

După ce HP s-a certat cu Cisco (și cu EMC acum ceva timp), acum a reușit să se certe și cu Oracle. Ajungându-se până la punctul în care Larry Ellison (CEO Oracle) spune că a devenit „virtually impossible for Oracle and HP to continue to cooperate and work together”.

Motivele (cel puțin cele publice :D ) le găsiți aici. Așteptăm cu interes evoluția evenimentelor…

Comments (6)

DNSSEC Rollout

Mâine, 5 mai, este ziua în care se va realiza deployment-ul DNSSEC pe toate serverele root. Dacă aveți vreun PIX/ASA care să filtreze mesajele DNS, vedeți aici ce modificări sunt necesare pentru a suporta pachetele (semnificativ mai mari) necesare pentru noul format de mesaje.

Comments (1)

Porumbelul african si porumbelul romanesc

Un porumbel african a avut o misiune nobilă: trimis să demonstreze că Internetul lor merge prost, a reușit acest lucru. Știrea a apărut prin mai multe locuri, inclusiv aici și aici.

Știrea a fost preluată și de presa de la noi, care reușește să scape „porumbelul românesc”: „O companie de tehnologie IT, din Africa de Sud, a început să folosească porumbei pentru a transmite date, pentru că păsările sunt mai rapide” (da, citatul este FIX așa cum a apărut în „presă”!!)

Parcă văd cum șefii de la marii ISP-uri de pe la noi își convoacă subalternii: „Uite, băi, ăia au reușit să facă treaba asta cu porumbei!! Noi de ce n-o facem tot așa, că uite, e mai ieftin și mai rapid?!”

Mare dreptate avea Meekuu atunci când vorbea de „strânsa legătură” dintre jurnaliștii noștri și mediul IT…

O companie de tehnologie IT, din Africa de Sud, a început să folosească porumbei pentru a transmite date, pentru că păsările sunt mai rapide

Comments (4)

« Previous entries