Posts Tagged ‘Cyon’

Montag, 8. Mai 2017

Die nervende WAF von Cyon deaktivieren

Gut gemeint, funktioniert aber nicht: Die Cyon WAF (Web Application Firewall).

Gerade eben kämpfte ich massiv mit meinem Server bei Cyon, deren WAF und meiner WordPress-Installation: Den Artikel tftp funktioniert über NAT nicht wollte der Server partout nicht speichern und gab stattdessen einen HTTP 403 zurück. Wahrscheinlich enthielt das Web-Formular zu viele „gefährlich“ tönende Befehle.

Das Problem behebt man ganz einfach, indem man die .htaccess der WordPress-Installation um folgende Zeilen ergänzt:

...
<IfModule mod_security2.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
...

Tags: , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 28. April 2017

Unterstützt mein Hoster DNSSEC?

Verisign liefert ein Tool, mit welchem man unter Eingabe eines Domain-Namens testen kann, ob der Betreiber des Nameservers der Domain DNSSEC unterstützt:

DNSSEC Analyzer

Antwort in meinem Fall für Cyon (April 2017): Leider nein.

image-7272

image-7273

Tags: , , ,
Labels: Web

1 Kommentar | neuen Kommentar verfassen

Samstag, 6. Juni 2015

Ctrl-l bei Cyon SSH-Zugängen wieder zum Laufen bringen (sowie: Kritik an Cyon)

Vor Jahren war der Shared Hosting-Anbieter Cyon ein Lichtlein am Horizont — klasse Design, einfach zu bedienende Admin-Oberfläche ohne irgendwelchen Schnick-Schnack.

In den letzten Monaten hat der Anbieter bei mir leider viel Goodwill eingebüsst; es scheint, als passe Cyon bald im Monatsrhythmus seine Infrastruktur an, und der Leidtragende ist der Kunde:

  • Web Application Firewall. Unter dem Motto „Wir machen Web-Hosting noch sicherer!“ wurde primär einfach mal mein auf PHP und MySQL basierendes Site Management Tool zerschossen, welches seit bald 15 Jahren bei unzähligen Hostern produktiv läuft (und von mir auch regelmässig angepasst wird). PHP-Code darf nun nicht mehr per HTTP POST übermittelt werden, denn das sei grundsätzlich einmal ein Sicherheitsrisiko. Und überhaupt. Was zur Folge hat, dass meine Daten sowie diejenigen meiner betroffenen Kunden auf einen anderen Web-Server gezügelt werden mussten, welcher von einer nicht so paranoiden WAF abgeschirmt wird.
  • Lüpfen ohne Vorwarnung oder Testsystem. Ungefähr jedes halbes Jahr lüpft der Anbieter über Nacht die PHP-Standardversion. Finde ich im Grunde Klasse und äusserst fürsorglich. Wenn dann die Sysadmins dort wenigstens ein wenig Hirn walten lassen würden und meine für Cyon adaptierte php.ini ebenfalls von Version zu Version portieren würden. Aber nein, bei jedem PHP-Upgrade kriegt man eine liebevoll von Cyon vorbereite php.ini vorgesetzt, welche natürlich alle selber vorgenommenen Spezialeinstellungen nicht enthält. Ohne irgendwelche Vorwarnung, teilweise um 10 Uhr morgens. Dann heisst es auf der Arbeit, alles liegen und stehen lassen, irgendwie per SSH Verbindung zum Web-Server aufnehmen und die zerschossene php.ini mit einer Sicherheitskopie überschreiben. Dasselbe passierte übrigens mit oben genannter Problematik: Von einem Tag auf den anderen waren alle meine Web-Sites plötzlich wieder hinter einer amoklaufenden WAF aufgeschaltet und funktionierten wieder einmal nicht mehr. Nach Interventionen und langer Wartezeit bequemte sich ein System Engineer dort, den althergebrachten Zustand wieder herzustellen.
  • Kommunikation? Vergesst es. In der heutigen Zeit wäre es mittels E-Mail, Blog und RSS-Feeds ja echt keine Sache, die professionellen und semi-professionellen Kunden über geplante Änderungen zu informieren. Mit genügend Vorlaufzeit, damit das Datum im Kalender markiert werden kann und allenfalls bereits Anpassungen am Code vorgenommen werden können. Aber bei Cyon lebt man nach dem Grundsatz „Was der Kunde nicht weiss, macht ihn nicht heiss.“ Was halt leider dazu führt, dass der Kunde immer wieder aus heiterem Himmel eine grundlegende Anpassung vorgesetzt erhält.

Was mich zu meinem eigentlichen Problem führt: Es scheint, als hätte Cyon kürzlich den Web-Server von LiteSpeed auf Apache gewechselt (ich kämpfe derzeit mit Zeichensatzproblemen, weil AddDefaultCharset utf-8 in .htaccess nicht mehr beachtet werden). Nun gut und recht. Zusammen mit diesem Wechsel kommt auch die SSH-Shell komisch daher.

Insbesondere nervte mich tödlich, dass ich neuerdings das aktuelle Terminal-Fenster nicht mehr mittels Ctrl-l löschen konnte (analog zum Befehl clear, halt simpler und schneller). Wenn ich die Tastenkombination betätigte, erschien einfach eine neue Zeile mit der Befehlseingabe.

Nach einigen längeren Nachforschungen und Pröbeleien (wohl so eine Eigenheit von bash mit .bash_profile und .bashrc) löste folgender Eintrag in .bashrc mein Problem.

...
# User specific aliases and functions
bind -x $'"\C-l":clear;'

Quelle: To bind clear to ^l in Bash

Tags: , , , , , , , , , , , , ,
Labels: IT

5 Kommentare | neuen Kommentar verfassen

Freitag, 27. Juni 2014

Spam-Mails mit imapfilter in einen Unterordner verschieben

Der falsche Weg, wie ich ihn bis heute angewendet hatte:

...
-- SPAM
messages = mbox.INBOX:contain_subject('[SPAM]')
messages:move_messages(mbox['Spam'])
...

Das führte in diesem einen speziellen Fall dazu, dass ein legitimes E-Mail eines Kollegen mit „[SPAM]“ im Subject gekennzeichnet wurde. Da das elektronische Gespräch hin- und herging, landeten alle Antworten des Empfängers immer wieder in meinem Spam-Ordner.

Der richtige Weg — jedenfalls für Mail-Accounts, die bei Cyon GmbH gehostet werden — ist:

...
-- SPAM
messages = mbox.INBOX:contain_field('X-Spam-Status','Yes')
messages:move_messages(mbox['Spam'])
...

Tags: , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 27. Juni 2014

.ch-Domains zu cyon transferieren

Heute schreckte mich Blogging Tom auf Facebook mit der Meldung auf, dass SWITCH/nic.ch per 1. Januar 2015 keine .ch-Domains mehr verwaltet. Bis spätestens zu diesem Stichdatum müssen .ch-Domains zu privaten schweizerischen Anbietern gezügelt werden.

Ich besitze ein halbes Dutzend .ch-Domains und lasse diese bereits alle auf meinen Shared Server bei der Cyon GmbH in Basel zeigen. Zum Glück hat der dortige Support in seiner Knowledgebase bereits eine bebilderte und „dubelisichere“ Anleitung aufgeschaltet, an Hand derer ich den Transfer innert 5 Minuten hingekriegt habe:

Wie kann ich meine Domain von SWITCH zu cyon transferieren?

ACHTUNG: Die ursprüngliche Google-Suche leitete mich auf folgenden Artikel, welcher diesen Spezialfall leider nicht behandelt:

Wie kann ich meine Domains transferieren?

Tags: , , , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Montag, 13. Januar 2014

Das PHP Error-Log von einem Cyon-Server täglich per E-Mail zusenden

Ein guter Web-Entwickler hält das PHP Error-Log seiner Web-Sites und -Applikationen stets im Auge. Ich persönlich habe mir zum Ziel gesetzt, dass nur ein leeres Log ein gutes Log ist. Dies bedeutet demzufolge, dass man auf Produktivsystemen sauberen Code ausliefert. Und sollten doch einmal Fehlermeldungen, Warnungen und Infos im PHP Error-Log auftauchen, gilt es diese zeitnah zu beheben.

Damit man eine Web-Präsenz, welche auf einem Cyon-Server mit SSH-Zugang läuft, überwachen kann, sind folgende Anpassungen nötig:

php.ini

Bei meinen Hostings befindet sich diese Konfigurationsdatei unter ~/etc/php_settings/default/php.ini. In dieser Datei sollten die folgenden Parameter gesetzt sein:

...
error_log = /home/%CYON-ACCOUNT%/var/log/php.err
...
error_reporting = E_ALL # Allenfalls auch & ~E_DEPRECATED
...

Dabei sollte man sicherstellen, dass das Verzeichnis /home/>benutzernamen>/var/log/ existiert und schreibbar ist.

mail-php-error-log.sh

Nachfolgendes Script sorgt dafür, dass der Inhalt der heutigen php.err per E-Mail an eine frei definierbare E-Mail-Adresse gesendet wird. Nach dem Versand wird die php.err kopiert und das Original danach gelöscht. Dem Dateinamen der Kopie wird dabei der aktuelle Tag des Jahres (1 bis 365) angehängt, womit wir eine Art automatisiertes logrotate durchführen:

#!/bin/sh

LOG="/home/%CYON-ACCOUNT%/var/log/php.err"

if [ ! -f "$LOG" ]
then
        echo "File '$LOG' not found"
        exit 1
fi

LINES=`cat "$LOG" | wc -l`

if [ $LINES -lt 1 ]
then
        exit 0
fi

#echo "Since log file is not empty ($LINES lines) I'm now posting its content to the webmaster"
cat "$LOG" | mail -s "php.err" logger@domain.tld
#echo "Would now be sending mail"

# Secret Sauce
DAYOFYEAR=$(date +%j)
cp "$LOG" "$LOG.$DAYOFYEAR"
rm "$LOG"

exit 0

Dieses Script habe ich in meinem Home-Folder abgelegt und mittels chmod 700 für meinen Benutzer ausführbar gemacht.

crontab

Schlussendlich richtet man sich noch einen Eintrag in crontab ein, damit das Script automatisiert einmal im Tag aufgerufen wird:

$ crontab -e

Der Inhalt dieser Datei lautet:

MAILTO="logger@domain.tld"
...
12 23 * * * /home/%CYON-ACCOUNT%/mail-php-error-log.sh

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Dezember 2013

Den Netatmo PHP API-Client mit weniger strikten SSL-Anforderungen patchen

Vor einigen Tagen hörte mein Raspberry Pi-Dashboard auf, die Werte meiner Netatmo NWS01 Wetterstation für Apple iPhone und Android anzuzeigen.

Auf meinem lokalen Mac funktionierte das Dashboard hingegen problemlos; d.h. ich konnte mittels dem Netatmo PHP API-Client die JSON-Datei mit den aktuellen Messwerten wie Temperatur, Luftdruck und -feuchtigkeit abrufen.

Die genaue Ursache hinter dem Problem kenne ich bis heute nicht, doch ich vermute mit dem jetzigen Wissensstand, dass die Cyon-Ingenieure an der Konfiguration ihrer Server herumgewerkelt haben und dabei unter anderem das Root-Zertifikat entfernt haben, welches der Netatmo API-Client zur HTTPS-verschlüsselten Kommunikation mit den Netatmo-Servern verwendet.

Nachdem ich nämlich die Exception mittels vardump() genauer betrachtete, welche NACurlErrorType zurücklieferte, war der Fall schnell sonnenklar:

...
[message:protected] => SSL peer certificate or SSH remote key was not OK
...

Nun … gut! Was macht man da? Ich habe die Datei NAApiClient.php gepatcht, indem ich cURL mit der auf false gesetzten Option CURLOPT_SSL_VERIFYHOST sage, unverifizierte SSL-Zertifikate kommentarlos zu akzeptieren:

...
        else 
        {
            $opts[CURLOPT_HTTPHEADER] = array('Expect:');
        }
        
        $opts[CURLOPT_SSL_VERIFYHOST] = false;
        
        curl_setopt_array($ch, $opts);
...

Bei einer API wie Netatmo ist diese manuell herbeigeführte Schwachstelle zu verantworten. Ginge es um Mailverkehr oder Online-Banking, würde ich eine solche Option definitiv nicht aktivieren.

Tags: , , , , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. September 2013

Hostpoint: Immer mal wieder zickt die Datenbank …

Irgendwann ab den frühen 2000ern habe ich alle meine Web-Projekte über das Shared Hosting von Hostpoint AG im Internet bereitgestellt, und dort sind sie in den meisten Fällen noch heute.

Spätestens seit ich diese mit eMeidi.smt laufenden Web-Sites jede Minute mit Pingdom überwache, realisiere ich, wie instabil Hostpoints Hosting ist. Verglichen mit einem an der Uni Bern gehosteten virtualisierten Root-Server (Debian und VMware ESX) und eMeidi.com, welches beim Hoster meines Vertrauens Cyon GmbH in Basel läuft, haben wir es bei Hostpoint mit einem hostingmässigen Drittwelt-Land zu tun.

Dank den vom eMeidi.smt im Dateisystem abgelegten Fehlermeldungen lässt sich rückwirkend jeweils rasch eruieren, wo denn das Problem des Pingdom-Alarms lag. Als Beispiel sei hier der Ausfall vom 13. September 2013 zwischen 8:47 und 9:23 erwähnt:

#2003: Can't connect to MySQL server on 'sekneueg.mysql.db.internal' (13) in /home/sekneueg/public_html/irgendwo/mysql.class.php:240 for URI </> with referer <unknown>

Tjach, dumm gelaufen, ne? In den letzten 30 Tagen betrug die Uptime für diese spezifische Web-Site nur 99.68%, was Ausfällen von insgesamt 2 Stunden und 21 Minuten entspricht. Die längsten Ausfälle fanden am 26. August (57 Minuten), 13. September (36 Minuten) und am 22. August (11 Minuten) statt. Erbärmlich, zumal es sich dabei nicht etwa um Wartungsarbeiten mitten in der Nacht gehandelt hat, sondern um Ausfälle während Bürozeiten.

Der Fall ist klar: Die Profis von heute hosten bei der Cyon GmbH. Da hilft es auch nichts, wenn der Ausfall-anfällige Konkurrenzhoster aus Rapperswil-Jona den bloggenden Tom anheuert – dessen Lohn (sorry, Tom!) würde man lieber in bessere und stabilere Hard- und Software stecken als unnütze Gutfühl-PR.

Tags: , ,
Labels: Web

3 Kommentare | neuen Kommentar verfassen

Sonntag, 9. Juni 2013

Mit postfix über cyons SMTP E-Mails versenden

Wer wie ich zu Hause einen Linux-Server betreibt, benötigt manchmal auch die Möglichkeit, E-Mails zu versenden.

Mit folgenden Einstellungen versende ich mit Linux E-Mails über meinen schweizerischen Qualitätshoster cyon:

/etc/postfix/main.cf

...
relayhost = [server00.cyon.ch]
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = login
smtp_sasl_password_maps = hash:/etc/postfix/sasl/outgoing
smtp_sasl_security_options = noanonymous

Damit der Versand aber effektiv klappt, muss ich wie im Attribut smtp_sasl_password_maps angegeben noch die Zugangsdaten eines cyon-Mail-Kontos hinterlegen:

/etc/postfix/sasl/outgoing

[server00.cyon.ch] user@domain.tld:password

Bevor postfix zum ersten Mal gestartet wird, muss diese Datei gehasht werden:

# postmap /etc/postfix/sasl/outgoing

Damit wird eine neue Datei unter /etc/postfix/sasl/outgoing.db angelegt, welche von postfix beim nächsten Start eingelesen wird.

Test

Zu Testzwecken versende ich nun per Kommandozeile eine E-Mail:

$ echo "Bla" | mail -s "Test" user@domain.tld

WICHTIG: Es empfiehlt sich, im cyon-Control Panel eine dediziertes E-Mail-Konto anzulegen, welches nur dem E-Mail-Versand dient. Sollte der Server gehackt werden, kann sich der Angreifer so nicht im privaten E-Mail-Verkehr herumtummeln.

Die beiden Dateien /etc/postfix/sasl/outgoing und /etc/postfix/sasl/outgoing.db sollten zudem nur für den Besitzer lesbar gemacht werden:

# chmod 600 /etc/postfix/sasl/outgoing /etc/postfix/sasl/outgoing.db

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 27. September 2012

Wenn imapfilter plötzlich mit meinem bei Cyon gehosteten Mail-Server nicht mehr funktioniert

Da verreise ich als auf einen IT-Audit ins „Ländle“, und prompt versagt mein geliebter imapfilter seinen Dienst. Fazit: Meine INBOXes sind plötzlich voller Mails, welche von imapfilter sonst schön brav spätestens 5 Minuten nach deren Ankunft auf meinen Mail-Konti in einen Unterordner verschoben werden. Zuerst dachte ich, dass mein lokaler Linux-Server, auf welchem imapfilter läuft, wegen eines Stromunterbruchs ausgefallen ist.

Doch mittels des äusserst nützlichen SSH-Clients Prompt hatte ich bereits am Dienstag realisiert, dass der Server am Netz hängt und ansprechbar ist.

Ein Blick in das von meinem imapfilter.sh-Script erzeugten Log zeigte, dass das Problem erstmals am Montag um 17 Uhr 15 Minuten aufgetaucht ist (Montag kurz vor Feierabend – dann scheinen die Cyon Sysadmins am liebsten ihre Zertifikate zu erneuern?)

2012-09-24 17:15 - <imapfilter Script> - Error '5' checking mail

Nun gut … letzter Ausweg: Ich versuche mich mittels

imapfilter -d -c <imapfilter Script>

interaktiv anzumelden und Debug-Meldungen abzulegen. Doch zur Analyse dieses Debug-Dumps kommt es nicht, denn auf der Kommandozeile strahlt mich folgender Hinweis an:

Server certificate subject: /OU=Domain Control Validated/CN=*.cyon.ch
Server certificate issuer: /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - G2
Server key fingerprint: 39:E9:08:A5:D9:EC:C3:A3:3E:0F:73:7C:14:B7:F2:A5
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Mittels Eingabe von p akzeptiere ich das neue Zertifikat, und gut isses.

Da hat Cyon also einfach nur sein Server-Zertifikat geändert. Wieso nimmt man immer gleich das Schlimmste an?

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen