Tor Exit Relay: WordPress Kommentar-Spam mit iptables blockieren

Aktuell beschäftige ich mich wieder mit meinem Dilemma. Anhand von Traces sehe ich, dass mein Tor Exit Relay von Spammern missbraucht wird. Eigentlich ist es die Aufgabe des Seitenbetreibers seine Kommentar-Funktion anständig abzusichern. Ich möchte aber zumindest ein bisschen Helfen, in dem ich keine WordPress Kommentare über mein Relay erlaube.
Zuerst dachte ich an einen vorgeschalteten Proxy Server. Bei meiner Recherche fand ich aber heraus, dass iptables für mein Vorhaben völlig ausreicht.

Analyse

Seit Freitag gegen 9 Uhr verbiete ich sämtliche ausgehende POST Anfragen an meinem Tor Exit Relay, die an einen HTTP Server gehen. Dazu habe ich diese iptables Regel eingefügt:

iptables -I OUTPUT -s 31.220.45.6 -p tcp --dport 80 -m string --string 'POST /' --algo bm -j REJECT --reject-with tcp-reset -m comment --comment "Tor POST block"

Diese Regel ist seitdem ca. 616.000 mal zur Geltung gekommen und hat 380 MB an Traffic geblockt.
Diese Regel ist natürlich nicht sinnvoll, da sie nicht nur WordPress Kommentare blockiert, sondern auch Captchas usw.

Wichtig: HTTPS Verbindungen sind von dieser Regel nicht betroffen, da iptables oder ein Proxy nicht das SSL/TLS aufmachen kann, ohne dass der Nutzer davon etwas mitbekommt. Zum Glück :-)

Read More „Tor Exit Relay: WordPress Kommentar-Spam mit iptables blockieren“

Tor Exit Relay: Block WordPress Comment-Spam with iptables

I’ve seen in network traces that my Tor exit relay is heavily used by spammer. Normally it’s the „victims“ job to secure their comment section but I want to help by rejecting WordPress comments over my relay.
My first idea was to route the Tor traffic through a proxy. But while researching I found out that iptables is capable of doing some basic kind of traffic inspection.

Checking

Since Friday 9 o’Clock I reject every POST request to a HTTP server over my exit relay. This was done using the following rule:

iptables -I OUTPUT -s 31.220.45.6 -p tcp --dport 80 -m string --string 'POST /' --algo bm -j REJECT --reject-with tcp-reset -m comment --comment "Tor POST block"

Since that, this rule was used for round about 616.000 times and rejected 380 MB traffic. It’s of course not very usefull since every POST request is blocked (like when solving captchas) and not just WordPress comment submissions.

Hint: Only unencrypted HTTP is affected by this rule. Encrytped HTTP over TLS/SSL can’t be filtered without getting noticed by the user. I’m glad for that :-)

Read More „Tor Exit Relay: Block WordPress Comment-Spam with iptables“

Logitech G930 and Ubuntu 15.10 / 16.04

Storytime

My loved Roccat Kave died from cable break and is now not usable anymore. I’ve had it for round about 6 years and was replaces two times (each because of cable break). I don’t want to buy a new one because I wanted a cordless headet. The benefits are

  • No cable breaks anymore
  • Stand up and walk around without cables in the way
  • No pulling when the cable gets stuck somewhere
  • You can take your friends in TeamSpeak with you to the toilet :-)

There are a few negative aspects as well: You are limited in the range the headset operates and when the battery is low it’s a wired headset again.
I decided that I want a cordless headset. For me it was important that it has to work in Ubuntu because I don’t have Windows. I’ve had a closer look on the Logitech G930 which costs currently round about 105 € on Amazon. Explicit Linux support is stated neither on the the product sice nor on the vendor site. Read More „Logitech G930 and Ubuntu 15.10 / 16.04“

Logitech G930 und Ubuntu 15.10 / 16.04

Vorgeschichte

Mein gutes altes Roccat Kave – das ich die letzten sechs Jahre nutzte und zwei mal getauscht wurde – ist durch einen Kabelbruch unbrauchbar. Ein neues Kave wollte ich nicht kaufen. Stattdessen wollte ich ein tolles kabelloses Headset. Die Vorteile liegen auf der Hand:

  • Kein Kabelbruch mehr
  • Aufstehen ohne es absetzen zu müssen
  • Kein ziehen wenn das Kabel irgendwo festhängt
  • Man kann seine Kollegen im TeamSpeak mit aufs Klo nehmen :-)

Ein paar Nachteil hat es natürlich auch: Die Reichweite ist jetzt nicht so groß und wenn der Akku leer wird hat man wieder ein Kabel. Trotz alledem wollte ich ein kabelloses headset.
Wichtig war, dass es unter Ubuntu läuft. Mein Blick viel auf das Logitech G930, mit einem aktuellen Preis von 105 € auf Amazon. Auf der Produktseite findet sich leider kein Hinweis auf Linux Unterstützung und auf der Herstellerseite wird nun Windows angegeben. Read More „Logitech G930 und Ubuntu 15.10 / 16.04“

pfSense: AES-NI Hardware Crypto Acceleration in KVM

I already mentioned that I’m using pfSense as firewall and router as a KVM guest. I wanted to connect the place where I live with the place of my grandparents over a site-to-site VPN using OpenVPN. For this purpose I’ve bought a PcEngines APU.1D4. A test in my local gigabit LAN was very low HD Streaming, but the APU.1D4 was not the bottleneck.

No delegation of hardware features

I found the bottleneck on my KVM hostsystem. The configured CPU for the pfSense machine was the QEMU CPU. I have configured this for most machines to reduce overhead simulating a „real“ CPU. But the QEMU CPU ist not capable of delegation hardware features like AES-NI, SSE, etc.
I’ve changed the settings to emulate a „Sandy Bridge“ processor which afterwards is recognized an an E3 processor.

Read More „pfSense: AES-NI Hardware Crypto Acceleration in KVM“

New GPG Key

I was shot during the weekend. Now I’ve a new GPG key:

Fingerprint:

87A8C897300C3464E9F8B0ABFB7F2741CA106CBC

It can be found on the keyservers or on the About Me page.

* Update 2015-05-09*

Of couse I wasn’t shot. I wanted to revoke a subkey but imported and published the revoke certificate for the master key. I had to create a new keypair.

Neuer GPG Key

Am Wochenende wurde ich eleminiert. Deshalb gibt’s nun einen neuen GPG Key.

Fingerprint:

87A8C897300C3464E9F8B0ABFB7F2741CA106CBC

Zu finden auf den Keyservern und auf der About Me Seite.

*Update 09.05.2016*

Natürlich wurde ich nicht erschossen. Ich wollte einen Subkey revoken. Dabei habe ich leider den Master Key revoked und gepublished. Als mir das aufgefallen ist, war es aber schon zu spät. Mir blieb also nichts anderes übrig, als einen neuen zu erstellen.
Über Nacht haben sich rund 40 Personen gemeldet, die schon voll schockiert waren und fragten, was passiert ist :-)

KVM: Low entropy in guests | Virtualized Hardware RNG

While I diagnosed some slow TLS/SSL connections I found out that some of my KVM guests are low on entropy. The value was between 150 and 190.
Right after booting up the entropy pool was near emptry and slowly increased after quite some time.
This behaviour is pretty normal, because a virtual server has (other than a physical server) nearly no load and hardware to gather good entropy data.

Side fact: Entropy and linux

Linux has an entropy pool where „good“ random data is stored. These pools can be accessed by using the two virtual devices

  • /dev/random (blocking) and
  • /dev/urandom (non-blocking)

Normally every application using random numbers is taking it out of the entropy pool. A heavy utilization occures for example when you work much with cryptography (TLS connections, Generating key pairs, etc).

Read More „KVM: Low entropy in guests | Virtualized Hardware RNG“

check_rdns: Reverse DNS/PTR Records monitoren

Frei nach dem Motto „Monitoren was geht“, habe ich wieder mal versucht, mit den Boardmitteln check_dig und check_dns meine Reverse DNS/PTR Records zu monitoren.
Leider geht das nicht so, wie ich mir das vorgestellt habe. Deshalb habe ich einen kurzen Check für diese Usecase geschrieben. Zu finden ist das gute Stück auf GitHub.

Das Script nimmer zwei Parameter:

  • –address und
  • –expected

Der Parameter „–address“ nimmt eine IPv4 oder IPv6 Adresse. Mit Hilfe von dem Kommando „dig“ wird der Reverse DNS Lookup durchgeführt und das Ergebnis mit dem Wert von „–expected“ verglichen. Das Ergebnis ist entweder ein Match oder eben kein Match. Read More „check_rdns: Reverse DNS/PTR Records monitoren“

Icinga 2: DNSBL Check mit Icinga 2 und check_rbl

Viele Mailserver überprüfen vor dem anliefern eine E-Mail, ob der versendende Server auf einer Blacklist steht. Dazu fragen sie via DNS bei einem Blacklist Provider an. Gibt dieser eine IP Adresse aus dem Bereich 127.0.0.1/24 zurück, dann steht der Server auf der Blacklist. Das Resultat: Die E-Mails werden nicht mehr angenommen. Wird der Fehler NXDOMAIN (also „nicht gefunden“) zurück geliefert ist kein Eintrag auf der Blacklist vorhanden.
Für Firmen ist ein Eintrag auf einer Blacklist nichts schönes, doch auch für private Mailserver ist so ein Check sinnvoll. Normalerweise landet man schneller auf einer Blacklist als eine Abusemeldung beim Provider eintrifft und bearbeitet wird. Sobald diese eintrifft, kann man den Provider wenigstes beschwichtigen und sagen, dass das Problem schon bekannt und hoffentlich auch schon behoben ist.

Mit den Boardmitteln check_dns oder check_dig kann man leider nicht arbeiten, da man nicht auf NXDOMAIN prüfen kann.

check_rbl

Es gib auf GitHub das Plugin check_rbl von Matteo Corti, mit dem die Prüfung möglich ist. Das Script nimmt eine Domain oder IP-Adresse und prüft sie gegen eine Liste von Blacklists. Leider wird kein CheckCommand mitgeliefert. Das CheckCommand von Markus Benning hat mir nicht gefallen, da ich dort nicht in der Lage bin verschiedene IPs gegen verschiedenen Blacklists zu checken. Deshalb habe ich es etwas angepasst: Read More „Icinga 2: DNSBL Check mit Icinga 2 und check_rbl“