Ciekawe jest też to, że atak Slowloris jest przeprowadzany po cichu. Apache nie zapisuje pliku logu połączenia dopóty, dopóki zapytanie nie zostanie ukończone, a więc w tym przypadku w logu nie znajdziemy śladu tego ataku. Slowloris był (a czasem nadal jest) zabójczy szczególnie dla serwerów opartych na Apache. Od czasu opublikowania Slowloris powstało wiele mechanizmów ochronnych, w tym m.in. dedykowane moduły mod_antiloris oraz mod_noloris.

Ale Slowloris to już historia (2009 r.). Od tego czasu powstało wiele innych narzędzi. Przykładem może być slowhttptest stworzony przez firmę Qualys, oparty na pomyśle Sergeya Shekyana, który czerpał z koncepcji Slowloris, ale też aplikacji Sockstress ("slow-read" w wydaniu dla protokołu TCP). W tym przypadku spowalniane są odpowiedzi serwera. Dzieje się tak dzięki wykorzystaniu sposobu, w jaki zaprojektowano TCP - sesja jest podtrzymywana, nawet jeżeli w jej trakcie występuje znikome natężenie ruchu. Do przeprowadzenia ataku wystarczy poprosić o coś, co w odpowiedzi przekracza rozmiar, który może być obsłużony w jednym kawałku przez bufor "send" serwera. Serwer musi wtedy podzielić odpowiedź na kilka mniejszych fragmentów. Następnie, aby zapełnić bufor "send", klient spowalnia odbieranie danych poprzez ustawienie po swojej stronie wartości niższej niż wartość buforu "send". Standardowe bufory mają wielkość od 65 do 128 KB. Należy zatem wysłać zapytania o coś większego niż 128 KB lub kilka razy poprosić o mniejsze zasoby (pod warunkiem, że serwer obsługuje HTTP pipelining). Skuteczność tego ataku można sprawdzić bardzo łatwo w domowym labie. My przeprowadziliśmy test polegający na instalacji Apache w wersji 2.2.20 na serwerze Ubuntu i wykonaliśmy polecenie:

# slowhttptest -c 8000 -X -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -uhttp://192.168.127.136/index.html -p 3

Serwis www przestał być dostępny już po kilku sekundach. Wystarczyło przerwać atak, aby znowu zaczął odpowiadać. Oczywiście, zastosowaliśmy domyślną konfigurację Apache, ale fakty są takie, że większość serwerów w internecie jest skonfigurowana w ten właśnie sposób.

Zaatakowane mogą być w zasadzie dowolne komponenty usługi. Niekoniecznie musi być to portal. Wiele organizacji, wymieniając między sobą informacje (np. finansowe), korzysta z rozmaitych API. Skuteczny atak w ten interfejs również skończy się odmową dostępu do usługi.

Ataki DDoS mogą być (i są) skierowane niekoniecznie bezpośrednio na ofiarę. Ich celem padają także serwery DNS, których awaria oznacza niedostępność serwisu dla zwykłego użytkownika (zawsze można posługiwać się adresami IP). Są również ataki wykorzystujące IPv6, a w zasadzie fakt, że spora część infrastruktury w dalszym ciągu nie jest w stanie go obsłużyć. Możemy sobie także wyobrazić skuteczne ataki na usługi VoIP, których dostępność to podstawa działania call center.

Funkcjonują również ataki wykorzystujące fakt, że dostęp do usługi jest szyfrowany. W przypadku serwisów webowych DoS tego typu często polega na zalewaniu serwera zapytaniami GET i POST (odpowiednio: GET Flooding i POST flooding). Jeżeli infrastruktura bezpieczeństwa nie jest w stanie deszyfrować ruchu i poddawać go inspekcji, stajemy się nieporadni i musimy skorzystać z mechanizmów spoza warstwy aplikacyjnej - najczęściej od warstwy 2 do 4.