Tag 354/2016: 1 Mal hinschauen, sofort geblockt

Ich schau mir gerade die WHOIS-Einträge aller IP-Adressen an, die auf einem meiner Hobby-VPS in die „ufw-blocker“-Falle getappt sind.

„ufw-blocker“ ist ein einfacher fail2ban-Filter, der in der syslog-Datei nach von der ufw-Firewall geblockten Einträgen sucht:

[Definition]
failregex = ^.*\[UFW BLOCK\] .*SRC=<HOST>.*$

Wahlweise nach einem oder zwei Versuchen (z.B. Tests auf Telnet-Port, allgemeine Port-Scans etc.) werden erneute Anfragen von der entsprechenden IP-Adresse für ein paar Stunden abgewiesen. Macht mit zunehmendem IPv6 natürlich irgendwann keinen Sinn mehr, aber aktuell gehts noch).

Damit man sich nicht selbst aussperrt bzw. Leute, die Zugriff haben dürfen, ist die „ignoreip“-Direktive mit diversen IP-Adressen gewhitelisted.

Als „banaction“ verwende ich immer die effiziente „iptables-ipset-proto6-allports.conf“, in der eine minimal angepasste Anweisung die IP-Adressen in die raw-Tabelle schiebt:

actionstart = ipset create fail2ban-<name> hash:ip
 iptables -t raw -A PREROUTING -m set --match-set fail2ban-<name> src -j DROP

Dadurch wird das Connection-Tracking umgangen; Informationen, dass die IP z.B. erneut geblockt wurde, interessieren mich im Logfile nicht – sondern rohe Geschwindigkeit beim Ablehnen. Eine Angewohnheit nach DDoS-Vorfällen.

Die IP-Adressen liste ich dann z.B. via „ipset list fail2ban-ufw-blocker“ auf:

Name: fail2ban-ufw-blocker
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 896
References: 1
Members:
211.36.yyy.xxx
42.117.yyy.xxx
223.241.yyy.xxx
59.127.yyy.xxx
31.203.yyy.xxx
109.49.yyy.xxx
61.240.yyy.xxx
220.134.yyy.xxx

Und aus den WHOIS-Einträgen ergibt sich u.a. Seoul, Vietnam, 2x China, Kuwait, Lissabon, Taiwan…

The usual visits.

Tag 296/2016: Internet of Sh*t, Part II

Gestern gab es wieder große DDoS-Angriffe auf Infrastrukturen, konkret auf den DNS-Dienstleister Dyn. Brian Krebs informiert hier darüber, spezifischer auch hier. Hier die Heise-Meldung. Konkret werden wohl auch wieder zigtausende völlig unsicher programmierte Billiggeräte, die am Netz hängen, für die Angriffe missbraucht. Böse Zungen, nein, realistische Zungen, sprechen deswegen vom Internet of Shit, nicht dem Internet of Things. Erst wenn diese Geräte aus dem Netz genommen werden, sind sie keine Gefahr mehr. Die meist völlig ahnungslosen Besitzer der Geräte werden das aber nicht ohne entsprechende Hinweise von außen tun. In der Praxis merkt man ja auch nicht, ob eine IP-Kamera, ein Telefon oder ein Kühlschrank 1x pro 30 Sekunden irgendeine Adresse im Internet aufruft… Und mehr braucht es ja auch nicht: DDoS bedeutet ja verteilte Angriffe, also koordinierte gemeinsame Angriffe auf das Ziel. Die Summe macht es und zwingt das Ziel in die Knie.

DNS ist ein wesentlicher Grundbestandteil eines funktionierenden Netzes. Wenn große Anbieter wie Dyn angegriffen werden, äußert sich das z.B. darin, dass Websites wie Amazon, Twitter, Tumblr, Reddit, Spotify oder Netflix für viele Nutzer des Dienstes (nicht nur Clients, auch andere Unternehmen die Dyn-Angebote nutzen) nicht oder schlecht erreichbar sind. Zwar ist der konkrete Anbieter wie Amazon nicht von einem Dienstausfall seiner eigenen Infrastruktur betroffen, aber die Besucher seines Angebots „finden“ nicht zu ihm. Wer technisch versiert ist, mag sich mit dem Wechsel zu einem anderen DNS-Anbieter behelfen, solange dieser die Ziel-Adresse noch in seinem Zwischenspeicher (Cache) vorhält. Allerdings ist das auch nur eine kurzfristige Lösung.

Ohne koordinierte Aktionen der großen Netzbetreiber wird man dem Problem wohl nicht Herr. Die Frage ist nur, wie groß der Schmerz noch werden muss, bis in die entsprechende Technik (bzw. Prozesse und Konfigurationen) investiert wird. Die Dimension solcher Angriffe sollte auch denjenigen Politikern ein Denkanstoß sein, die für Hintertüren in kryptographischen Systemen plädieren: Egal ob eine Applikation durch Inkompetenz oder absichtliche Maßnahmen geschwächt wird – am Ende wird die Lücke gefunden und jemand nutzt sie aktiv aus. Und das sind nicht immer die vermeintlich Guten.

Tag 293/2016: Besuch der IT-Security-Messe it-sa in Nürnberg

Um 6:40 Uhr in den Bus Richtung Hauptbahnhof, mit kurzer Zwangspause auf Höhe Bischof-Konrad-Straße, wegen eines Unfalls bei der Kreuzung Galgenbergstraße vor der Mälze. Hoffentlich niemandem was passiert! Jedenfalls noch pünktlich Abfahrt mit Zug Richtung Nürnberg.

Zur Messe geht es easy in 8 Minuten mit der U1. Dort alles perfekt organisiert. Kurz vor dem offiziellen Einlass um 9:00 Uhr bin ich dann auch schon drinnen.

Foto eines Messestands von Akamai auf der IT-Security Messe it-sa in Nürnberg
Mein vorrangiges Interesse auf der Messe galt Web Application Firewalls und DDoS-Schutz. Hier ein Foto vom Akamai-Stand.
Eine wasserdichte Sache, Foto von der IT-Security Messe it-sa in Nürnberg
Ein netter Hingucker, diese wasserdichte Appliance. Auf dem Stand meinem alten Bekannten Richard Hallo gesagt.

Bei irgendeinem Stand haben sie einen DeLorean geparkt. Das Marketing hat bei mir jedenfalls nicht funktioniert – ich habe keinerlei Erinnerung mehr daran, was die eigentlich verkaufen.

Foto mit Blick in die Menge auf der IT-Security Messe it-sa in Nürnberg
Insgesamt: Ordentlich was los.
Und wieder nach Regensburg.
Und tschüss, Nürnberg!

Tag 166/2016: Web-App-Vulnerability Scanner

Verschiedene Open-Source-Tools um Schwachstellen in Web-Applikationen zu finden, teils voll-, teils halb-automatisiert; teils Kommandozeile, teils GUI; teils aktueller, teils älter.

Auch geeignet, um die Bandbreite an potentiellen Schwachstellen kennenzulernen und ein wachsameres Auge in eigenen Programmierprojekten zu haben.