hooheads kleine Welt
Der 28C3 steht unmittelbar vor der Tür und da machte ich eben noch mein Thinkpad Lanparty ready (System neu aufsetzen ist vor / nach solchen Veranstaltungen irgendwie generell Pflicht 
).
Damit im Netzwerk befindliche Clients nicht auf den eigenen Apache Zugriff bekommen, kann man die Zugriffe die nicht von Localhost kommen generell aussperren.
Unter Ubuntu (getestet mit 10.04) die Datei /etc/apache2/sites-available/default mit folgenden Erweiterungen füttern:
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Order allow,deny
allow from 127.0.0.1
</Directory>
<Directory /usr/share/phpmyadmin/>
Options Indexes FollowSymLinks MultiViews
AllowOverride all
Order allow,deny
allow from 127.0.0.1
</Directory>
Zugreifen können wir dann auf den eigenen Apache nur noch per http://127.0.0.1
Gerade eben folgende Email vom devl0r via Mailer erhalten:
Servus,
ich bin auf folgende Seite gestoßen:http://ipfuck.paulds.fr/
https://addons.mozilla.org/de/firefox/addon/ipflood/
Klingt fast schon zu schön, mir fehlen allerdings die Kenntnisse um diese Methode wirklich zu verstehen.
Wenn du dich dafür interessierst und etwas Zeit hast, wäre ich sehr an deiner Meinung dazu interessiert, vielleicht gibts ja sogar einen Blog Eintrag.LG devl0r
So einen Blogbeitrag verfasse ich doch gerne, hier also die Erklärung wie man Firefox Addons untersucht und was ipFlood macht.
Firefox Addons liegen im .xpi Format vor, das sind im Grund ganz normale .zip Files.
Sprich Ihr ändert die Dateiendung und entpackt das Ganze, oder Ihr entpackt das .xpi File direkt, wenn euer Packer das mitmacht.
Nun können wir uns die entsprechenden Files analysieren, ich beschränke mich in dem Beitrag einmal auf die Datei ipfuck.js die im Ordner /chrome/content/ zu finden ist.
Im Screenshot das entsprechende Codefragment, dass die sogenannte “Proxyfunktion” beinhaltet.
Das Plugin erweitert den Browser-Request um weitere Request-Header und versucht so einen “falsche” Ip vorzugaugeln.
Das bedeutet, die Anfrage als solche wird nach wie vor direkt zwischen Client (Firefox) und Webserver übertragen, was solch ein Plugin in seiner Eigenschaft als “Proxy” völlig nutzlos macht.
Die eigentlich IP des Nutzers ist nach wie vor unverschleiert sichtbar, täuschen lassen sich damit nur Seiten, die explizit “X-FORWARDED-FOR” etc. auswerten (und selbst dann ist die echte IP immer noch in den Webserver Logs sichtbar).
Screenshot: Ip Auswertung mit ipFlood (VM) und ohne Plugin.
In meiner Scriptbase findet Ihr übrigens einen Example Code fürs “X-FORWARDED-FOR” testen.
Meine Freundin hat sich eben auch mal hingesetzt, um die gestellte Frage zu beantworten :
Frage: Wie untersucht man Firefox Addons; Antwort: Gar nicht, weils keinen interessiert. Deswegen sind die Methoden oder was ein ipFlood macht absolut und total uninteressant. Ich hoffe der Beitrag hat Euch, bei Euren Fragen weiter geholfen, zumindest wisst Ihr jetzt daß Ihr Euch lieber um Eure Freundinnen kümmern sollt, statt solche dämlichen Fragen zu beantworten. Beitrag Ende.
Heute möchte ich die erste Version des hoodog veröffentlichen, die mich dieses Jahr vor einigen kleineren Flooding Angriffen schützte.
Grundsätzlich sind solche Mechanismen sicherlich hilfreich um kleinere Flooder abzuhalten, gegen größere Botnetze insbesondere wenn man nur einen kleinen VServer zur Verfügung hat, sind auch solche Schutzmechanismen hilflos.
Bevor der hoodog zum Einsatz kommt, möchte ich noch auf ein paar Worte zur Serverkonfiguration verlieren.
Im Netz an Informationen zu gelangen, wie man einen Webserver richtig einrichtet, ist leider gar nicht so einfach.
Es gibt zahlreiche Beiträge mit Leuten die gefährliches Halbwissen als Fakten verkaufen.
Da ich mir mein Wissen selbst zusammen googlen musste um in Tests „on the wild“ herauszufinden, was gut und nicht so gut ist, möchte ich hier nur die Dinge wiedergeben, bei denen ich mir sicher bin dass sie stimmen.
Der Webserver (bei meinen Tests ein Apache), stellt eine besondere Schwachstelle bei Floodingangriffen dar – besonders im Zusammenspiel mit PHP kann man die beiden Komponenten schnell zum Aufgeben bringen.
Grundsätzlich muss der Webserver den Hardware Gegebenheiten angepasst werden, sind die Resourcen zu großzügig vergeben, versagt der komplette Webserver den Dienst, bevor irgend welche Schutzmechanismen greifen (Danke an dieser Stelle an die Flooder, die mir beim Einrichten geholfen haben 
).
Der Apache selbst bringt einige Möglichkeiten mit, sich gegen solche Floodingangriffe zu wehren, zum Bsp. das Modul mod_evasive … welches leider nicht besonders wirkungsvoll ist.
Besser ist es eine Lösung zu finden, bei denen der Webserver entlastet wird – iptables ist meiner Meinung nach eine recht gute Möglichkeit.
Eine schmale Lösung als bash / shellscript gibt es bereits online – DDOS Deflate, siehe DDOS Deflate.
Mein hoodog macht im Grunde nichts anderes als DDOS Deflate – zumindest in der V1 – in der aktuellen Version sind einige Features eingebaut, die auch „niederschwelliges flooden“ lokalisiert.
Ihr benötigt php-cli um den hoodog zu betreiben, unter einem Debian →
apt-get install php5-cli
PHP safe_mode (Webserver) und PHP safe_mode (php-cli) kann übrigens unabhängig von einander konfiguriert werden – bei der php-cli muss safe_mode deaktiviert sein.
Der hoodog wird per cronjob gestartet, sprich ihr müsst die /etc/crontab editieren.
Um den hoodog im Minutentakt auszuführen, folgenden Eintrag mittels root in die Datei einpflegen:
*/1 * * * * root php /root/hoodog.php
Der hoodog liegt natürlich im /root/ Verzeichnis mit dem entsprechendem Namen.
Meiner Meinung nach ist es sinnvoll Flooder für eine längere Zeit auszusperren – sprich ein Flooder wird jetzt per iptables geblockt und bleibt dann auch auf der Liste.
In den frühen Morgenstunden – auch per cronjob werden dann die iptables rules gelöscht und die neuen Regeln definiert, das entsprechende Updatescript → flushiptables.php
Der cronjob:
30 4 * * * root php /root/flushiptables.php
Nachdem die iptables rules gelöscht sind, werden noch 2 Shellscripte ausgeführt.
In das 1. legt Ihr eure Firewall Regeln (ich habe schon einige reingehauen, ihr müsst selbst testen in wieweit euer Server / Vserver die Regeln akzeptiert, bzw. entscheiden was ihr noch benötigt).
In das 2. könnt Ihr Server die auffällig waren dauerhaft sperren.
In der entsprechenden Liste sind schon einige Server eingepflegt, die durch flooding oder Einbruchversuche auf hoos Area gesperrt sind.
Anpassungen die ihr am Script treffen müsst:
$count =180; ← hier die Anzahl an max Anfragen (pro Minute) bevor geblockt wird.
Bei mail eure email Adresse eintragen, ihr bekommt dann eine email mit dem Hinweis, dass ein Flooder blockiert wurde.
$datei / — Pfad zum speichern der Logdatei – schützt diese unbedingt durch einen htacess – zwecks dem Datenschutz und so.
Die 1. Version des hoodog bietet noch eine Menge Möglichkeiten trotzdem durch Floodingattacken ärger zu machen.
Die neue Version soll hier effizienter arbeiten – befindet sich aber noch in Beta Status.
Den hoodog stelle ich hiermit als Open Source Projekt online, wer Lust hat diesen weiter zu entwickeln (wie ich gerade ) darf das gerne machen – die hoohead Credits bleiben im Source (ist Ehrensache, oder?).
Zum Thema Syn-flood und syn_cookies möchte ich euch noch folgenden Artikel von dotxed ans Herz legen: syn_cookies aktivieren.
Der Einsatz vom hoodog geschieht auf eigene Gefahr, insbesondere Proplay Nutzern würde ich dringend ans Herz legen keine iptables rules zu flushen, da euch sonst der Server abschmiert.
Noch ein paar Worte zum hoodog V2 – dieser arbeitet mit einer MySql Datenbank und beinhaltet neben der „normalen“ flooding Protection diverse Auswertungen um „unterschwelliges flooden“ zu lokalisieren (hierunter fallen auch Bruteforce Angriffe, die „langsam“ ausgeführt werden).
Auf der rechten Seite seht Ihr eine Grafik (unter hoodog:) die den aktuellen Status der Firewall anzeigt (je nach Angriff ändert sich die Farbe von grün (alles OK) – über Gelb nach Rot.
Zum kommenden Wochende wird die Textgrafik evtl. durch eine Zeichnung ersetzt, ich möchte aber nicht zu viel versprechen.
Dateien:
Soeben wurde eine XSS (Cross Site Scripting Lücke) bei Twitter bekannt.
Der 15 Jährige Belmin Vehabovic hat die Lücke via Twitter veröffentlich.
Glückwunsch an dieser Stelle.
Wie bereits gestern angekündigt, läuft seit heute der neue Dienst des hoodog.
Ziel der Anwendung, den entsprechenden Traffic anhand der IP auszuwerten und “niederschwellige Floodingangriffe” zu lokalisieren.
“on the wild” habe ich solche Angriffsmuster noch nicht entdeckt, bzw. bin ich mir nicht sicher, ob das bereits überhaupt Jemand so umgesetzt hat.
Geloggt werden die Zugriffe anhand der IP, wobei die Anzahl der verursachten Requests aufgezeichnet werden.
Ein Blockieren bei zu hoher Last ist eine der Funktionen die unter anderem im hoodog integriert sind, was neu ist: hoodog soll “intelligent” Zugriffe auswerten und verdächtige Ips melden (per email).
Ein temporärer 24h Bann sowie das permanente manuelle Sperren von Servern die zum flooden missbraucht werden sollen das Ziel sein, auch wenn Zugriffe nicht über den voreingestellten Schwellenwert fallen.
Dazu werden neben den Requests und der IP auch die Anzahl der Wiederholungen und die Anzahl der in Folge auftretenden Wiederholungen in eine Datenbank gespeichert.
Zum Abschluss wird noch täglich ein Reporting mit den betreffenden Informationen erstellt, sprich ein IP Zugriff wird max. 48h lang gespeichert werden.
Nicht gespeichert werden: “User Agent, Referer, besuchte Seiten, Verweildauer oder sonstige personenbezogenen Daten”.
Aktuell befindet sich der hoodog V2 im Beta Modus, sprich die Auswertungen werden bereits erfasst, scharf stellen werde ich die Erweiterung vermutlich zum kommendem Wochenende.
Nochmals zur Info – solche per iptables gesteuerten Schutzmechanismen helfen sicherlich bei kleineren Floodinattacken, bei einem entsprechend großem Botnetz bringen sie natürlich nichts.
Den hoodog werde ich erst veröffentlichen, wenn ich 100% mit ihm zufrieden bin – soll einfach kein Projekt werden, dass dann ständig Updates benötigt um zu funktionieren.
Fiktive Angriffsszenarien spiele ich immer wieder gerne durch und es juckt immer verdammt in den Fingern, diese auch mal “on the wild” durchzuziehen.
Das N900 ist ja ein wirklich geniales Handy, Dank der “App” Easy Debian lassen sich so gut wie alle Programme aus den Lenny Backports auf das N900 bewegen, ob nun der Apache, Metasploit, nmap …
Die Tage habe ich mir überlegt, ob man nicht auch mit dem Handy einen effektiven Man-in-the-middle Angriff durchführen könnte.
Heute einen Hilferuf via twitter erhalten, aktuell scheint wohl ein Erpresser gegen deutsche Webseitenbetreiber vorzugehen.
Der Horni erzählte mir dann, dass auch ein Erpresserschreiben eingegangen ist, mit folgendem Inhalt:
hi, wie du siehst stehst du schon seit einiger zeit unter ddos. ich habe genug mittel und geld um dir für immer den hahn abzudrehen, wenn du nicht zahlst. ab jetzt bekommen ich 500 EUR monatlich via UKASH oder LibertyReserve von dir. sollte ich nichts von dir hören, geht der ddos weiter.
Da es sich bei dem Angriff um einen einfachen Syn-flood handelte, genügte es bei ihm die Syn-Cookies zu aktivieren um den Angriff ins Leere laufen zu lassen
(Syncookies aktiviert man unter Debian / Ubuntu in dem man folgende Zeile in /etc/sysctl.conf setzt: net.ipv4.tcp_syncookies = 1 … Netzwerk Restart nicht vergessen).
Ein Kollege vom Horni (www.dealdoktor.de) hat übrigens genau das selbe Erpresserschreiben erhalten, dieser ist aber seit 2 Tagen offline.
Des weiteren ist es sinnvoll, seinen Server (soweit möglich) gegen Floodingangriffe zu schützen – zum besagten Thema werde ich in Kürze ein Tutorial veröffentlichen und auch eine Version meines hoodog public machen (den hat seit heute auch der Horni am Start ).
Da RTL die Netzgemeinde ständigt trollt, dachte ich mir – schlagen wir mal zurück.
THIS IS RTL TROLLING – mfg hoohead
Falls Trollface nicht erscheint – erneut auf hoos Area gehen, diesen Artikel aufrufen und erneut auf den Link klicken (der Internetexplorer braucht 2 Anläufe – weil der euch quasi auch trollt).
Vor kurzem veröffentlichte ich einen Beitrag zum Thema: “Wie Spammer arbeiten“.
Gestern und heute wollte ich meine These einmal etwas weiter durchspielen und deshalb setzte ich mal hin um zu überlegen, wie man einen Spam-Welle auf die entsprechenden Blog loslassen könnte, natürlich nur zu Demozwecken.
Bevor es ans coden ging, machte ich mich aber erst mal schlau, schließlich stellt unberechtigtes spammen einen Straftatbestand dar.
Was ist spammen – bzw. was noch viel wichtiger ist, was sieht unser Gesetzgeber als spammen (deutsche Gesetzte sind sehr konfus meiner Meinung nach).
Soviel konnte ich in Erfahrung bringen: Spammer verschaffen sich einen wirtschaftlichen Vorteil, indem sie ungefragt und unberechtigt Werbung oder Links zu Projekten verteilen.
Ein Blog bietet ja seinen Gästen die Möglichkeit einen Kommentar zu hinterlassen und um die Gesichtspunkte “wirtschaftlicher Vorteil” auszugrenzen, wollte ich bei meinem Versuch keinen Backlink einbringen.
Über die wahllos ausgesuchte Bestenliste kam ich an insgesamt 13.366 Linkadressen, wenn man mit einem eleganten Socketscript nun Kommentare verteilen wollte, müsste man zuerst heraus finden wie die Seiten aufgebaut sind, also ob ein CMS läuft und welches und wie man automatisiert einen Kommentar hinterlassen kann.
Zudem wäre es sinnvoll den entsprechenden Kommentar in den neusten Blogbeitrag zu posten was die ganze Sache nochmals etwas erschwert – würde man sich ein entsprechendes CMS System vornehmen (Wordpress zum Beispiel), dann wäre es trotzdem noch nicht so einfach den Link aus dem Quelltext herauszuschneiden (zum neusten Blogbeitrag), da unterschiedliche Themes die Seiten unterschiedlich darstellen.
Nach einige Überlegungen hatte ich eine Lösung um gleich 2 Fliegen mit einer Klappe zu schlagen – ich überprüfte ob ein bestimmtes Feature (welches unter Wordpress läuft) vorhanden ist und nutze dann RSS Feed um an den neusten Beitrag zu kommen.
Der Code war schnell geschrieben und Crawler präsentierte nach einigen Stunden eine Liste mit immer noch 6.540 (von 13.366) Links zu den neusten Beiträgen.
Schritt 2 schreiben eines Kommentares auf diesen 6.540 mit anschließender Überprüfung ob der Kommentar direkt freigeschaltet wurde.
Das Ergebnis war mehr als zufriedenstellend, von diesen 6.540 Blogs sind bei 6.432 die Einstellungen so, dass die Kommentare zuerst durch die Moderation wandern, oder entsprechende Schutzmechanismen eingebaut wurden um automatisiertes posten zu verhindern (Captchas).
Schutzmechanismen wie Akismet sind übrigens wirkungslos, weil:
Es ist ganz schön schwachsinnig, dass die Schutzmechanismen nur dann greifen wenn bestimmte Parameter in die Anfrage mit übergeben werden (Akismet Session etc.) – man aber ohne Parameterübergabe trotzdem kommentieren kann.
Insgesamt gingen also 108 Kommentare durch, wobei 10 dieser Kommentare mittlerweile der manuellen Nachzensur zum Opfer vielen.
Zum Abschluss durchsuchte ich die restlichen 98 Blogs noch auf Aktuallität und stellte fest, dass über 50% keinen Beitrag in den letzten 3 Monaten veröffentlicht haben – diese 98 Blogs hatten im Durchschnitt aber ein sehr hohes Spamaufkommen in den Gesamtkommentaren.
Als Fazit lässt sich festhalten, dass Blogbetreiber die Ihre Blogs in Bestenlisten eintragen früher oder später zu der Erkenntnis gelangen, geeignete Maßnahmen gegenüber automatisierten Spambots zu ergreifen.
Die Dau-Rate unter den Blogbetreibern liegt unter 2 % (1,498 %) – erfreulich oder?
Ab und zu führt man kleinere Pentests im Auftrag durch und ab und zu findet man auch einen htaccess Passwort geschützten Bereich, den man mal eben schnell testen möchte.
Wenn die Aufgabenstellung einen Black-Box-Test verlangt, sollte man neben den üblichen serverspezifischen Tests auch mal eben auf Standardlogins oder schwache Passwörter testen.
Natürlich gibt es für viele solcher Aufgaben schon fertige Tools und natürlich kann man auch mit fertigen Programmen solche Aufgaben erledigen – um zu begreifen wie verschiedene Mechanismen arbeiten, schreibe ich mir meine Helferlein jedoch selber.
Ihr findet deshalb ab heute meinen htaccess Bruter in der Scriptbase, eine Anleitung wie man das PHP-Script nutzt gibt es nicht.
Über Verbesserungsvorschläge, gerne auch über meinen mailer bin ich immer dankbar 
