Zockertown: Nerten News

Durch die Analyse mit Matomo bin ich einem Pänomen auf die Spur gekommen.

Aus Gründen der email Problematik muss jede Domain, die auf unseren Server liegt, einen MX Eintrag haben.
Macht man dies nicht, gibt es Probleme mit einigen großen email Anbietern wie. z.B. gmx.

Nun habe ich vor Monaten meine eigenen Seiten mit der Search Console von Google untersucht.
Dabei fand ich sagenhaft viele Links, die natürlich erfolglos eine große Mange von Seiten auf der Subdomain mail.domain.de  (domain ist hier ein Platzhalter)
erreichen wollten.

Das klappt natürlich nicht und wird mit Fehlern von Google quittiert.
Ich habe lange gerätselt, welche Ursachen das haben könnte.
Denn nirgendwo auf meinen Seiten gibt es diese URLs.

Da kam mit Matomo mit dem Graphen Kanaltypen gerade recht. Man kann in der Auswertung sehen von wo die Zugriffe auf diese Phantom mail.domain.de herkommen.

So wie ich das sehe, scheint es Bots zu geben, die einfach probieren auf der mail subdomain Dinge zu erreichen, die auf anderen Domains durchaus — ohne mail subdomain — gültig sind.

Im Screenshot ist jetzt nur eine halbe Woche betrachtet.

Meine Gegenmassnahme:
Ich habe in ISPConfig eine Subdomain mail angelegt und ein permanenten Redirect auf die Domain weitergeleitet. Das führt nun einfach auf die Homepage und produziert keine Fehler mehr

Seit 2 Tagen ist dies nun aktiv und offenbar kommen keine neuen mail subdomain Zugriffe mehr.

Ich habe das auch auf den anderen betroffenen Domains so eingerichtet.

Da das Mailsystem selbst Port 80 und 443 nicht tangiert, gibt es naturgemäß damit auch keine Kollision.

Fazit:

Anfangs war ich von Matomo ja nicht so begeistert, da ich das System nun aber konsequent auf ausschliessliche Logfile Analyse basierend aufgesetzt habe und auch die Möglichkeiten der Anonymisierung nutze, konnte ich mich mit den Graphen näher beschäftigen und sagen, das ist wirklich nicht nutzlos und Overhead, sondern sehr nützlich, auch für Hobbyprojekte.

Es geistern mehrere Lösungen rum, die netdata mit basic auth und nginx abzusichern.

Es geht aber auch mit einer reinen Apache Lösung, die auch in der Doku von netdata beschrieben ist.

Hier meine Gedächtnisstütze.

ich verwende ISPconfig, entsprechend sind hier die notwendigen Einträge bei der Website in der Config.

Apache Direktiven:

  RewriteEngine on
  RewriteRule ^/\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^/\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
  RewriteRule ^/\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^/\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]

    
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    

    
        Require all granted
    

    # Local Netdata server accessed with '/netdata/', at localhost:19999
    ProxyPass "/netdata/" "http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on
    #ProxyPass "/netdata/" "unix:/var/run/netdata/netdata.sock|http://localhost:19999/" connectiontimeout=5 timeout=30 keepalive=on


If
    ProxyPassReverse "/" "http://localhost:19999/"
    # if the user did not give the trailing /, add it
    # for HTTP (if the virtualhost is HTTP, use this)
    RewriteRule ^/netdata$ http://%{HTTP_HOST}/netdata/ [L,R=301]
    # for HTTPS (if the virtualhost is HTTPS, use this)
    #RewriteRule ^/netdata$ https://%{HTTP_HOST}/netdata/ [L,R=301]
    # add a  section
    
        AuthType Basic
        AuthName "Protected site"
        AuthUserFile /etc/apache2/.htpasswd
        Require valid-user
        Order deny,allow
        Allow from all
    

Damit ist Let's Encrypt frei Haus, da die Hauptdomain bereits ssl enabled ist.

Jetzt nicht vergessen, mit

htpasswd -c /etc/apache2/.htpasswd monitoruser

einen user für die "basic auth" anzulegen.

und dann kann in   /etc/netdata/netdata.conf bind auf localhost gestellt werden.

... und die vorhandende Firewall Freischaltung für Port 19999 kann dann auch gleich raus. Denn die Kommunikation damit findet nur jetzt nur lokal statt.

So, ISPConfig 3 ist nun bei uns produktiv.

Dabei ist mir aufgefallen, das die email User, wenn Sie keine eigene Domain besitzen, also nicht als Kunde eingerichtet sind, sich kein Passwort setzen können.

Das ist natürlich nicht nur mir aufgefallen, sondern schon ein paar anderen

Lösung für Roundcube: im HowtoForge

Die Lösung für Squirrelmail: im Howtoforge

Letztes Wochenende war es endlich mal wieder soweit.

Ich habe die Admin Oberfläche ISPConfig auf 2.2.35 aktualisiert.

Wesentliche Neuerung ist, das jetzt AWstats nicht mehr als extra Paket installiert wird, sondern mit zum Grundpaket gehört.

Damit dann die Webseiten auch wieder die Statistiken bekommen, muß einmalig im Admin Menü ausgewählt werden, ob man webalizer oder AWstats als Logfile Analyzer haben möchte.

Ein kleiner Schönheitsfehler ist die fehlerhafte Spamassassisin Version. Das Problem liegt an einer im Code implementierten Regex, die alles nach 2009 für "weit" in der Zukunft hält und so einen dicken Score Malus auf die ankommenden Mails draufschlägt.

Hier Spamassassin 2010 bug?? wird allerdings beschrieben, wie das Problem leicht und zuverlässig zu beheben ist.

Unser Rootserver ist übrigens an seinem Lebensende angekommen, wir werden auf das Nachfolgemodell umsteigen. Ich habe dafür max. 2 Monate parallelbetrieb vorgesehen.

Mit großer Wahrscheinlichkeit werden ich die ISPConfig V3 einsetzen. Der der Neuinstallation wird Debian Lenny dann auf eine LVgroup aufgesetzt. Großartige Veränderungen an Zockertown wird es sehr wahrscheinlich nicht geben. Das Blog wird wieder auf Serendipity aufgesetzt werden, allerdings dann gleich in der neuesten Version.

Es grüßt der Tuz. Nachdem ich meinen Laptop erfolgreich mit Linux Kernel 2.6.29 versorgt habe, habe ich mich an das upgrade unseres Root-Servers gemacht. Der lief bis heute noch auch Etch mit einem 2.6.23.rc6 Kernel

Auf dem Server, wenn man nicht selber Hand anlegen kann ist man ja eher etwas gehemmt, mal eben so Distributionsupgrades und Kernel updates zu machen. Jedenfalls geht mir das so. Nun wars soweit. Das Upgrade auf Lenny lief wie erwartet völlig problemlos durch. Der Apache hat zwar jetzt beim starten gemeckert,  "Warning: SuexecUserGroup directive requires SUEXEC wrapper." aber da alles noch funktioniert ist das zweitrangig. Als ich die Erfolgsmeldung an meine Mitsteiter senden wollte, habe ich dann doch noch ein Problem erkannt. Die Mail ging nicht raus, weil angeblich das Passwort nicht stimmte, oder der Dienst nicht verfügbar war, wie icedove meinte. Doch im mail.log auf dem Server war nichts auffälliges zu sehen. Auch keine Login failed Meldungen! Ich habe dann über Tante google hier die Lösung gefunden :Nach Upgrade von Debian Etch zu Lenny: cannot connect to saslauthd server: Permission - OVH-Forum. Allerdings brauchte und durfte ich nicht die OPTIONS= in /etc/default/saslauthd anpassen. Also fürs Protokoll: Auf mit ispconfig Installation konfigurierten Debian Etch muß man nach dem upgrade auf Lenny folgenden Schritte durchführen:

dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd

adduser postfix sasl

/etc/init.d/saslauthd restart

/etc/init.d/postfix restart

Ich habe heute unsere ISPConfig auf 2.2.30 upgedated (Changelog) und auch die diversen tools wie roundcube, awstats, phpmyadmin auf den neuesten Stand gebracht. Wieder einmal keine Probleme, dank meiner eigenen Hinweise, die ich ja bereits im Blog hatte. Also immer die /root/ispconfig/httpd/conf/httpd.conf sichern, awstats erneut installieren  cd  /usr/src/ISPConfig_awstats_pkg ./install.sh

aus dem  /etc/apache2/apache2.conf den unnötigen Eintrag von awstats rauswerfen (um Zeile 247) und auch die Crontab von dem nun doppelten awstats aufruf befreien. Die Webserver neustarten.

ISPConfig - OpenSource ISP management and Hosting Control Panel - Downloads

Mal wieder war es soweit. Seit ein paar Tagen ist die Version 2.2.27 draussen.

Das Changelog liest sich nicht besonders spannend, aber alleine die Aktualisierung von Clamav und SpamAssisin rechtfertigen den (zugegeben) geringen Aufwand.  Daran denken: /root/ispconfig/httpd/conf/httpd.conf sichern, awstats erneut installieren (ugly, aber kein Bock den Fehler auszubauen): cd  /usr/src/ISPConfig_awstats_pkg ./install.sh

aus dem  /etc/apache2/apache2.conf den unnötigen Eintrag von awstats rauswerfen (um Zeile 247) und auch die Crontab von dem nun doppelten awstats aufruf befreien.

Ein neues Tool wurde installiert. Wir haben nun einen Newsletter für die "Kunden" und jeder, der möchte kann für sein Web so etwas auch bekommen. Html Mail scheint noch nicht richtig zu funktionieren, aber die Text Variante funktioniert prima.

Fehler in der Vhosts_ispconfig.conf melden gemacht. Doch bis da etwas umgesetzt ist, wird es noch ein wenig dauern. Da ist Selbsthilfe angesagt. Wie gut, das man mit httpd -t -f Vhosts_ispconfig.conf_tt-mm-jj_hh-mm-ss auch gesicherte Dateien checken kann und nicht nur die aktuelle.[update 21.03.09] Schwierig wird es, wenn in den Vhosts_ispconfig.conf Dateien Sachen wie Rewrite Rules, setEnv und soweiter drin sind. Denn dann beschwert sich der httpd (neuer: apache2ctl) mit Syntaxfehler, obwohl da keiner ist.

Abhilfe: Ich habe mir mit grep -v '^#' /etc/apache2/apache2.conf >/root/apache2.conf eine einfaches Testszenario augebaut. an

In der letzten Zeile steht üblicherweise Include /etc/apache2/vhosts/Vhosts_ispconfig.conf, die passe ich dann an die letzte Vhosts_ispconfig.conf_tt-mm-jj_hh-mm-ss an und kann dann in Ruhe den Fehler suchen. Diesmal war es ein unnötiger Zeilenumbruch, der zum Syntaxfehler führte.

Seit dem 12 Februar ist ISPConfig 2.2.21 veröffentlicht ISPConfig - OpenSource ISP management and Hosting Control Panel News

Neu ist u.a. Ruby Unterstützung.
Ich habe es heute endlich mal geschafft, das Update durchzuführen. Schmerzlos einfach. Nur nicht vergessen, die gerettete ispconfig/httpd/conf/httpd.conf zurück zu spielen und awstats in /usr/src/ISPConfig_awstats_pkg mit ./install.sh

erneut zu installieren. Dann nicht vergessen, Crontab reparieren, awstats hat einen neuen Eintrag angelegt, der bereits drin ist und in /etc/apache2/apache2.conf at line 247 auch.

Na ja, ist etwas reisserisch formuliert, aber lest selbst

Ich habe als Admin eine Benachrichtigung bekommen,

Mail an den Admin:
Username:                     web11_king
Used Storage Space:           87.13 MB
Allocated Storage Space:      1.00 MB
User's Real Name:               King
User's Email Address:           king@dn.de
Web Site:                       www.dn.de
Group Of Web Site:              web11

[...]
Customer's Web Site:           https://zockertown.de/s9y/

This customer does not belong to a reseller.

# mit find nach user suchen (userid ist auch ok)
 nice find / -user web11_king>/tmp/web11_king.txt

Heute ist ISPConfig 2.2.19 erschienen. Da ausser mir noch nicht wirklich was auf dem neuen Server im Wirkbetrieb ist, habe ich gleich zugeschlagen. Ich wollte wissen, wie ein update funktioniert. Neu: Bugfixes, und upgedatete clamv, spamassisin und php5

Prima funktioniert es! Man sollte aber daran denken, seine root/ispconfig/httpd/conf
Dateien zurückzuspielen, wenn man wie ich den ispconfig webserver auf anderen Port als 81 betreibt und/oder sonst noch Änderungen gemacht hat.
Aber die Installation rettet sie auch und andere Sachen in tgz's in /tmp/
Damit sind die Meckermeldungen ala Your ClamAV installation is OUTDATED!
Im mail.log auch weg.
Gute Arbeit!

Ergänzung:

Der default crypt Algorithmus ist nun 'md5';. Das braucht man also selber nicht mehr anpassen. Meine installierte AWstats Erweiterung, war allerdings nicht mehr scharf. Ein cd /usr/src/ISPConfig_awstats_pkg und ./install.sh

Hört sich immer so einfach an, mal eben von einem virtuellen Server auf einen Root Server umziehen. Als erstes stellt sich die Frage, macht man alles selber, oder möchte man eine Server Administration Software verwenden. Alles selber machen, heisst aber auch sich viel mit dem System beschäftigen, ständig auf Zuruf Mailadressen einrichten und Webs pflegen. Auf den neuen Rootserver sind nur ein paar Freunde, aber dennoch kommt da einiges zusammen. Ausprobiert habe ich Syscp und ISPConfig. Beides sind Expertensysteme, von der Oberfläche sind sie ähnlich, beide haben Sachen in der Konfiguration, die sich nur durch ausprobieren und Nachfragen erschliessen. Das mächtigere von beiden ist ISPConfig, mir persönlich gefällt die Integration von Mail mit Antispam und Virenscanner ganz gut. ISPConfig kann über eine Update Schnittstelle mit Zusatzpaketen erweitert werden, diese Schnittstelle ist leicht zu beherrschen und lädt zum bauen eigener Erweiterungen ein. Obwohl ich eigentlich nur einen kleinen Server zu betreuen habe, habe ich mich für ISPConfig entschieden, weil es vom Start weg zum Beispiel konsequent auf SSL abgestellt ist. Mein Hauptärgernis des alten Rootservers war nämlich, das ich den Webmail Client nicht mit https erreichen konnte. Mal davon abgesehen war der Vserver in die Jahre gekommen (suse 9.3 mit Plesk 7.54) und ich hätte gerne Debian mit einem Opensource Server Administration tool. Im Anschluß an diese Einführung folgt meine Installation und die Punkte, die es zu beachten gab. Vielleicht interessierts ja jemanden.

[Update 05.01.2007] (Original 13.12.2007)