Traffic Attack from Baidu Address Space

Yesterday I noticed that one of my servers was seeing more traffic than usual. The hourly traffic limit I had set was reached and my mailbox filled with traffic warning messages. I wanted to look into the matter but wondered: how can I quickly see which IP connections exist? Fortunate to be on a Debian Linux, I decided to install the package iptraf. This IP LAN monitor generates various network statistics and showed me that most of the new connections came from one particular IP range: 180.76.0.0/16. WHOIS DB shows, that this range belongs to BAIDU, the famous search enterprise in China. Generating several hundred Megabytes of traffic per hour was too much for me. You can see the traffic line here:

Graph showing the Baidu Traffic Attack
Start of the Baidu traffic phenomenon
Graph showing the Baidu Traffic Attack
Trying to counter the Baidu traffic phenomenon.

First of all I thought it might be the indexing work of many Baidu spiders, or of spiders claiming to be Baidu. In this regard, I found a very helpful post by the folks at Perishablepress, which explains how to block the Baidu spidering process through the .htaccess file.

This did not really solve the problem, so I took more serious measures and blocked the whole address space of Baidu via iptables Firewall. This is the command you need (please be root before using it):

iptables -A INPUT -s 180.76.0.0/16 -j DROP

Just remember, that this statement really blocks all the traffic from the Baidu network. So if your servers are meant to reach Chinese visitors, you might want to think twice before you block it all!

Konfigurationen rund um VMware Server 2

Bisher lief auf meinem Linuxsystem ein VMware Server in der Version 1.0. Nach dem ich nun den Linuxserver auf Debian Lenny aktualisiert habe, wollte ich auch den VMware Server auf die Version 2.0 bringen. Dabei bin ich in diverse „Fallen“ gerannt, die ich hier kurz beschreiben möchte.

  1. Die Installation brachte gleich als erstes einen Fehler bezüglich der eingesetzten „gcc“ Version.
  2. Your kernel was built with „gcc“ version „4.1.3“, while you are trying to use
    „/usr/bin/gcc“ version „4.2.3“. This configuration is not recommended and

    VMware Server may crash if you’ll continue. Please try to use exactly same
    compiler as one used for building your kernel. Do you want to go with compiler
    „/usr/bin/gcc“ version „4.2.3“ anyway? [no]

    Nach etwas googlen fand ich dafür den entscheidenden Hinweis:

    Mit

    ls -l /usr/bin/gcc*

    überprüft man, welche Versionen auf dem System installiert sind.

    Mit

    export CC=/usr/bin/gcc-4.1

    legt man fest, welche Version von gcc verwendet werden soll. Danach konnte ich ohne Probleme vmware-config.pl ausführen.

  3. Ich möchte mit meinen Firefox 3.6 auf das VMware Webinterface zugreifen, bekomme jedoch ständig Fehler. Selbst wenn ich die „Exception“ eines selbstsignierten Zertifikats akzeptiere, verbindet sich Firefox nicht mit dem VMware WebGUI. Bei der Fehlersuche stieß ich auf den Hinweis, dass SSL 2 im Firefox 3.6 standardmäßig ausgeschaltet ist. Also habe ich es wieder aktiviert: Aufruf von „about:config“ und Suche nach der Zeile „security.enable_ssl2“ – per Doppelklick setzt man den Feldwert von „false“ auf „true“.

How to Release Banned Content from Amavis + Spamassassin auf Debian Linux Etch

This topic has bothered me ever since I installed a proper mailgateway which screens my incoming emails for viruses and unwanted content and then forwards clean emails to my email server. The system is running Debian GNU/Linux Etch and utilizes the Amavis filter plus spamassassin. Whenever a .exe file is found in an email, the email will be quarantined.

Now at certain times I do want to receive an email containing a .exe file, for instance if that happens to be the driver I am waiting for some time already. Or, for instance, if Lexware sends you their „FDBUSupportTool.exe“. Even though it comes as zipped file, the .exe inside is recognized and the whole mail is quarantined:

BANNED CONTENTS ALERT

Our content checker found
    banned name: multipart/related |
      application/octet-stream,.zip,FDBUSupportTool.zip |
      .exe,.exe-ms,FDBUSupportTool.exe

My question now was: How do I get the quarantined mail delivered to me? And voilá! A solution was finally found, because fiddling around with mutt on the server didn’t bring the wanted results.

What did help was the proper use of the command „amavisd-release“. You just have to look for the following line in your quarantine-message:

The message has been quarantined as: banned-mm73nK4IZBY8

and take note of the underlined part (it may look different in your case, for instance if you zip/gzip the banned mails.

Then you issue the following command on the command line of the server where the amavis tool quarantines mails:

amavisd-release

AMAVIS says:

amavisd-release version 1.1
Usage:  $ amavisd-release mail_file [secret_id [alt_recip1 alt_recip2 …]]
  or to read request lines from stdin:  $ amavisd-release –

Now you go ahead an issue:

amavisd-release banned-mm73nK4IZBY8
250 2.6.0 Ok, id=rel-mm73nK4IZBY8, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 1FBE117C745

This let’s the formerly banned and quarantined email appear in your inbox.

Die meistgesuchten Kombis – Tilde und Pipe

Viele aus der Linux-Welt bekannte Zeichen werden auch auf dem Mac gebraucht, z.B. um im Konsolefenster aktiv zu werden. Heute habe ich mal wieder das Tilde-Zeichen (oft Schlangenlinie genannt) und das Pipe-Zeichen gesucht.

Das TildeZeichen (~) wird am Mac durch drücken von „Alt + n“ erzeugt. Das PipeZeichen (|) wird über „Alt + 7“ eingegeben.

OpenSSL und Vertrauen durch Zertifikate

Nachdem die Sicherheitslücke bei Debian OpenSSL Kreise zieht, sammle ich hier einfach mal Informationen zu Dingen, die man sinnvollerweise tun sollte:

1. Updaten. Ganz klar, das Debian Security Advisory DSA 1571 gibt dazu weitere Infos.

2. Auch Webserver mit einem SSL-Zertifikat können betroffen sein, wenn der Zertifikatsrequest (CSR) auf einem Debian-System erstellt wurde. Dazu informiert die „Certification Authority“ COMODO in ihrer KnowledgeBase. (COMODO ist übrigens laut eigenen Angaben die zweitgrößte CA.)

3. Wenn es kein offiziell ausgestelltes SSL-Zertifikat war/ist, dann kann man sich mit neuaustellen und eigener CA auch weiterhelfen. Dazu fand ich den folgenden Artikel sehr hilfreich: http://www.debian-administration.org/articles/284

4. Und um ein günstiges offizielles SSL-Zertifikat zu erwerben, schaut man am Besten hier vorbei: www.ibh.de. Da gibt es verschiedenste offizielle Zertifikate, und diese auch auf Rechnung. (Ein offizielles Zertifikat hat den Vorteil, dass es von den meisten Browsern ohne Rückfrage akzeptiert wird.)

Den Mailfluß im Blick behalten – mit mailgraph.cgi

Dieses Thema hat heute überhaupt nichts mit MacOS zu tun, aber ich finde es dennoch äußerst spannend. Es geht um die Beobachtung des Mailtransfers auf einem Mailserver. Mit dem Werkzeug mailgraph.cgi kann man eine schöne grafische Übersicht erhalten. Ich habe das ganze auf einem Debian Server laufen.

Informationen zu dem Tool erhält man hier:

http://mailgraph.schweikert.ch/

Folgender Link zeigt, wie es im Live-Betrieb aussieht:

http://www.stat.ee.ethz.ch/mailgraph.cgi

Folgender Artikel hat mir beim Installieren gut weitergeholfen:

http://howtoforge.com/mailgraph_pflogsumm_debian_etch

Interessant ist, dass das mailgraph.cgi Werkzeug bei mir ohne Probleme auch mit sendmail zusammenarbeit. Ich bekomme also den Graphen mit den „Mail Statistics“ für meinen Linux-Server angezeigt.

Was zunächst nicht funktionieren wollte, ist die Anzeige des Anteils an Spam-Emails. Da hat mir der folgende Link sehr weitergeholfen:

http://lists.ee.ethz.ch/mailgraph/msg00141.html

Ich habe also genau diese Änderung im Programmcode vorgenommen (vi /usr/sbin/mailgraph.pl) und habe die Zeile

if($text =~ /^identified spam/) {

durch

if($text =~ /identified spam/) {

ersetzt.

Das Ergebnis nach einem Restart von mailgraph: Jetzt zeigt meine Statistik auch die Menge der erkannten Spam-Mails an! Die Spitzenwerte waren gerade 21 Mails pro Minute, die als Spam erkannt werden, während 109 Nachrichten pro Minute rejected wurden.