Jozef Mares – Page 10 – jozefmares.com
Home Author
Author

Jozef Mares

V kontexte ostatných udalostí a útokov na české firmy, média a banky sa ukázalo že väčšina ľudí predpokladá že tento typ útoku je výhradne aktom vandalizmu. Ukážeme si že to tak nie je. Doba kedy sa útoky (nielen) kategórie Denial of service / Distributed denial of service robili čiste ako demonštrácia technologických schopností geekov sú dávno preč.

Útoky typu DoS boli populárne odjakživa, je pomerne široko známy napríklad Ping of death prípadne Ping flood.
Neskôr boli široko používane útoky z kategórie SYN flood, UDP flood a podobne. Tento typ bol obzvlášt obľúbený na univerzitnej pôde kde boli široké linky a minimum ochranných mechanizmov. Študenti sa bežne zabávali s nástrojmi ako je hping a vzájomne si zhadzovali mašiny, najmä tým ktorý tomu menej rozumeli. :)

Presný termín kedy sa z tychto útokov stal výnosný biznis model nepoznám (netuším kto speňažil prvý botnet), ale pre majiteľa botnetu je najlepší biznis prenájom kapacity napadnutých počítačov. Takto je napríklad odosielaný spam a sú realizované i DDoS útoky (samozrejme na DDoS sú aj iné metódy, viď napríklad LOIC a Anonymous, ale pre potreby krátkosti tento aspekt vynechávam).

Skúste si predstaviť že ste v pozícií biznisu ktorý na elektronickej komunikácií závisí – ste e-shop, banka s e-bankingom, webový portál. Vaše príjmy závisia výrazne na tom že sú vaše weby dostupné online. Nie je neobvyklé že na vás demonštratívne zaútočia na dve hodiny (botnety sa často účtujú po hodine) a následne príde oznámenie že sa budete deliť o zisky, inak budete nedostupný. Tento model bol veľmi populárny okolo roku 2006 a cielený na e-shopy.

Ako som sa dozvedel po novom sa poskytuje ochrana pred týmto útokom a to tak že zaplatíte pevnú čiastku a ako bonus v prípade že vaša konkurencia požiada o útok na vás bude táto požiadavka ignorovaná.

Tým sa dostávam k obchodnému modelu dva. Model spočíva v tom že útočník prevedie analýzu trhu, najde si minimálne dva relevatné subjekty a nechá ich licitovať na koho bude útok vedený. To mi príde zvlášt pikantné a sadistické.

Ako sa stanovuje cena za ochranu?
Útočníci často vedia koľko stojí kapacita linky, paušál v nejakej CDN alebo napríklad u CloudFlare a stanovia cenu nižšiu ako vychádzajú uvedené obranné mechanizmy. Takáto jednoduchá ekonómia za tým všetkým je.

Ako je vidieť ide v zásade o obdobu výpalníctva známeho z devätdesiatych rokov, teda nič inovatívne.

Veľmi kreatívny spôsob zarábania zvolili script kiddies v roku 2010 keď prišli s požiadavkou že útokom bude možné odolať v prípade že si cieľ kúpi ich prostredníctvom služby veľmi známej CDN ktorá spustila affiliate program. V tomto prípade však stačilo požiadať o informácie ako a kam zaplatiť a CDN informovať o tom že ich affiliate partner takýmto spôsobom zneužíva program. Je pravda že existovalo pre klienta riziko že DDoS bude pokračovať, ale odhad bol správny že ide iba o amatérsky pokus.

Ďalší dôvod prečo sa objavia útoky na mediálne exponované stránky je demonštrácia sily botnetu. Ide o to že na navštevovaných stránkach sa demonštruje sila a skutočnému cieľu príde iba výzva na úhradu s tým že keď veľké portály neodolali ako chcú odolať oni? Opäť ide ale o variáciu známeho výpalníctva. V prípade zaznamenanom na českom internete môže ísť o demonštráciu sily s tým že Česká republika poslúžila ako digitálna strelnica.

Na záver: koľko vlastne stojí prenájom botnetu a kto za to môže?
Hoci to môže znieť šokujúco botnety sú celkom lacné, v roku 2010 keď som sa problematikou zaoberal najvýraznejšie bolo možné prenajať botnet už od 10 USD za hodinu a priemerná cena bola okolo 150 USD za 24 hodín. Kvalitnejšie botnety ktoré garantovali útočnú kapacitu stáli od cca 200 USD. Holt, i skladník ve šroubárně si může pronajat botnet. :)

Za najväčšie zlo posledných cca dvoch rokov pokladám Javu vzhľadom k tomu ako Oracle pečie na jej bezpečnostné opravy a client side útoky to myslím celkom potvrdzujú, takže ak chcete jednoznačného vinníka vylejte si zlosť na Oracle. Možno ten bordel začnú opravovať. :)

I recently have “honour” to be a part of the team which mitigated SYN flood attack to Czech news sites (of course not all, but one of the greatest and best). :)

You can read more about issue here in English or here in Czech.

Technical details about attack are now part of the investigation but basically this was form of a SYN flood based DDoS originating from Russia (we know it now, but we did not knew before). There were spoofed headers so it looked like traffic is going from many locations (e.g. Switzerland).

So, first and very brutal method is to block international traffic – you should consult this with upstream provider. It is always better for effectiveness to blackhole traffic on upstream routers. Unfortunately this helped only during phase one of attack.

But let’s dig deeper into a problem. How does this attack is created and realized?

I will use GNU/Linux based examples as I’m much better with this OS than with MS Windows. But concept applies to almost every OS.

SYN flood is based on resource exhaustion on target system (well, every DoS or DDoS is based on this concept).

Attacker achieves this by abusing thing called three way handshake, which means in normal conditions:

1. the client requests a connection by sending a SYN (synchronize) message to the server;
2. the server acknowledges this request by sending SYN-ACK back to the client;
3. the client responds with an ACK, and the connection is established.

This is kind a core of TCP communication (and I took it from Wikipedia).

A SYN flood attack works by not responding to the server with the expected ACK code. The malicious client can either simply not send the expected ACK, or by spoofing the source IP address in the SYN, causing the server to send the SYN-ACK to a falsified IP address – which will not send an ACK because it “knows” that it never sent a SYN. (this is from Wikipedia too, you can try to read it by yourself

There are a few countermeasures you can implement on your GNU/Linux box:

1. enable SYN cookies (this works on FreeBSD too):

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

2. check how many entries you have in your conntrack table:

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

3. check how much entries can be stored in your conntrack table:

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

4. if you are lucky and you have dedicated GNU/Linux firewall you can adjust number of conntrack entries.

Basic formula: CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (X / 32) where X is your number of bits in pointer (yes, it is 32 or 64 for most systems).

5. modify number of buckets in hash table. You can find it in:

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_buckets

which is only read only alias for module parameters in:

cat /sys/module/ip_conntrack/parameters/hashsize

Formula for hashsize is: CONNTRACK_MAX = HASHSIZE * 8.

6. disable conntrack for certain destination IP and port

iptables -t raw -A PREROUTING -d <server IP> -p tcp --dport 80 -j NOTRACK
iptables -t raw -A PREROUTING -s <server IP> -p tcp --sport 80 -j NOTRACK

I did not knew that there is this option and I could not switch conntrack completely off because I needed to do NAT (oh how I hate it) to keep production on-line.

During peak of the attack conntrack table has this kind of growth (there are some stupidities in graph as we have been adjusting settings without changing monitoring):conntrack peak

After communication with upstream provider, and with tuning of conntrack (especially disabling for HTTP traffic) problem was gone.

By the way, this kind of attack is pretty lame, and for media at all: this is not a hacking attack. You can’t spot real hack. ;)

I manage multiple certificate authorities – two are for my company, three are for customers, one is my personal and so on. I run certificate authorities because I do not like feeling dependant on companies with stupid security policies like commercial certificate companies. It my sound like I hate these companies but I only consider them as pure security evil (yet, I still must use them). :)

If you are asking, why you should manage your own certificate authority consider things like very own VPN server (based on OpenVPN or IPSEC), securing your sites and applications like OwnCloud or SOGo, signing emails (yes, you can do it with GPG) and so on. x509 standard is good – implementation and realisation is really bad.

So, if I do not want go usual way I need to manage CA on my own. I just to use TinyCA2 which seems to be dead, and I’m on OS X now so TinyCA2 did not fit to my system and workflow. Thank you for your service, but it is time to move to new home dear TinyCA2.

I found few other options like OpenVPN easy-rsa, some shell-hacked-ultimate-wrappers on Github, huge projects like OpenCA and so on. I even tried to use certificate helper integrated in Keychain Access on OS X.

Results:

* Keychain Access is good for generating certificate request for user, but sucks on CA management;
* OpenCA is way to big for me;
* easy-rsa and shell-hacked-ultimate-wrappers seemed to be solution, yet I do not like it;

Bummer.

Then I started to google around again and I realised I totally missed XCA project. After installation I really did not liked user interface, but it is just about habit. TinyCA2 UI was just different, you have to get used to new software (and is good if you know how certificates work – it will help :) ).

I did not made migration of old CA’s to new system as I’m waiting ’till certificates will expire and then I will migrate users to new standard with 4096 bit long keys.

What else you should know about this software?
* XCA stores whole CA in single file with suffix xdb;
* has pretty decent UI with glitches but I can survive them;
* supports whole subset of formats like DER, PEM, PFX and so on;
* allows you to sign external requests – I needed this;
* supports revocation lists – with little bit scripting you can automate it;
* has templates – I hate to fill forms again and again with same informations;
* has pretty good documentation;

Hope this software will stay with me as long as TinyCA2.