Mam nadzieje,ze nikt nie wykorzysta moich 'porad’ do niecnych celów. Chce po prostu pokazać jak dwoma bardzo prostymi, ale jakże skutecznymi metodami można powodować niemałe straty na serwerze znajomego. Mam nadzieje, że kiedyś powstanie jakiś skuteczny sposób na walkę z tym, ponieważ obecnie nie istnieje metoda potrafiąca od razu identyfikować taki atak, a jak już jest jakieś alternatywne wyjście z takiej sytuacji, to mało kto się do tego stosuje…ponieważ jest nieopłacalne i dość sporo utrudnia optymalne funkcjonowanie serwera. Oczywiście mowa tutaj o serwerze dedykowanym, ponieważ na typowym koncie shared za 50zl/rok takie sztuczki nie powinny się udać z racji szybkiej reakcji przedstawicieli firm hostingowych…ale kto wie…druga metoda na pewno zda egzamin :)

Czy to sposoby są legalne? Nie wiem, ciężko mi się określić, ponieważ nie znam kruczków prawnych, ale myślę, że jak ktoś się uprze to może faktycznie pociągnąć do odpowiedzialności za takie czyny. Ponieważ można je zaliczyć do ataków DoS.

Wykonujecie je na własną odpowiedzialność – najlepiej w sieci lokalnej do prywatnych testów !

1. Przeciążenie procesora

Nic za bardzo nie trzeba się gimnastykować. Nie trzeba ściągać żadnego dodatkowego oprogramowania. Wszystko mamy podane na talerzu w systemie Linux. A jeśli się mylę, to wystarczy doinstalować serwer Apache i mamy komplet narzędzi.

A to cudo nazywa się: ApacheBenchmark (skrót: AB) :]

ab -n 10000 -c 100 -k http://localhost/

n – ilość zapytań
c – ilość zapytań w tym samym czasie
k – wymusza użycie stałego połączenia

w/w komenda wpisana w terminalu/konsoli spowoduje:
Pobranie pliku index.php 10000 razy, przy czym jednocześnie będzie przeprowadzonych 100 połączeń.

Możecie wierzyć lub nie, ale pierwotnie AB został stworzony do testowania wydajności, poprawnej konfiguracji serwera, a jak widzicie można go użyć trochę inaczej :)
Kiedy to uruchomimy na serwerze pojawi się kilkanaście równoczesnych instancji Apache, które łączenie spożytkują 100% mocy serwera. Jeśli Apache jest dobrze skonfigurowany powinien wyjść z tego cało. Jeśli nie to zawiesi się pracując ciągle na pełnych obrotach. W czasie tych testów mogą występować także liczne problemy z dostępem do bazy danych mysql.

2. Zużycie transferu

Serwery dedykowane są sprzedawane w 3 wariantach pod względem dostarczanego transferu.
– bez jakichkolwiek ograniczeń;
– linia 100MBit, ale nie można stawiać żadnych usług streamingowych i ostro przeciążających łącze;
– linia 100MBit z limitem 1000GB miesięcznie;

Pierwsza opcja jest bardzo droga – coś koło 1500zł/miesiąc za tego typu łącze do serwera, więc raczej na pewno nikt ze znajomych nie ma takiego serwera :)
Druga opcja jest m.in. w www.ovh.pl, www.hetzner.de, trzecia w www.livenet.pl.

Jeśli użyjemy tej metody na serwerze dedykowanym to będzie to prawie niezauważalne. Ale jeśli na zwykłym koncie hostingowym, gdzie limit transferu wynosi średnio ~10GB będzie jak znalazł :)

Tworzymy dowolny plik na komputerze, a w nim umieszczamy:

#!/bin/bash

while [ true ] ; do
wget http://localhost/ctlogo3year.jpg -O /dev/null
done

WAŻNE: Musimy podać odnośnik do istniejącego pliku!!
Skrypt ten powodować będzie w nieskończonej pętli pobieranie graficznego pliku (ten wyżej ma 114KB). Warto dopisać ten dodatkowy atrybut -O /dev/null ponieważ linux jest tak „sprytny”, że jeśli widzi, że ściągnięty plik istnieje, to zamiast go nadpisać tworzy obok o podobnej nazwie, ale z dodatkową cyferką. Więc aby nie zapchać sobie dysku twardego tysiącami plików warto od razu „zapisywać” je w koszu – wirtualnym tajemniczym urządzeniu /dev/null :]

W zależności jak szybkie mamy łącze i jak szybkie ma serwer możemy wygenerować spory ruch.
Proste obliczenia:
(w moim przypadku średnio 2x na sekundę był ściągany taki 114KB plik)

– doba to 86400 sekund
– 86400 sec = 172800 ściągnięć pliku
– 172800 plików = 19’699’200 KB = 19’237,5 MB = 18,79 GB transferu w ciągu doby

Więc bez problemu można sporo transferu zeżreć :) a jak uruchomić taki skrypt na 2 i więcej serwerach jednocześnie to w ogóle będzie pogrom :P Transfer wsiąknie zanim zdążymy się zorientować, ponieważ najczęściej statystyki transferu są generowane raz dziennie.

No chyba, że administrator serwera zauważy znaczy wzrost ruchu, który powoduje duże straty w transferu… wtedy albo zablokuje Nasze IP, albo całe konto i poczeka na decyzję właściciela konta.

3. Zaśmiecenie logów serwera

Właściwie przez przypadek wpadłem na to, że też tak można :]
Uruchamiamy skrypt z pkt.2, ale wpisujemy odwołanie do jakiegoś nieistniejącego pliku. I Tyle :]
W logach serwera Apache będzie mnóstwo wpisów o błędnej lokalizacji pliku. I taki plik z logami może powiększać się w nieskończoność i może zająć cały dysk twardy ;] haha

Niestety, ale najczęściej logi serwera nie są „z gumy” i będą się same czyścić.

Trzeba także powiedzieć o ujemnych stronach tych sposobów.

Robicie je na własną odpowiedzialność i nie zachęcam do „próbowania” ich na serwerach znajomego ;) heh