Wer ein eigenes, oder mehrere Blogs betreibt, sei es zu persönlichen oder besonders zu gewerblichen Zwecken, wird zur Absicherung von Sicherheitsrisiken Plugins verwenden. Einige davon werden in den einschlägigen Ratgebern eigentlich bei jeder Installation uneingeschränkt empfohlen und gehören so selbstverständlich dazu, wie ein Antivirenschutz zum Betriebssystem des Fensterlesprogrammierers aus Redmond.
Hierzu gehört der Kommentarspam. Nicht nur ist es lästig und zeitraubend täglich eine Vielzahl von Kommentaren nach Spam und manchmal strafrechtlich relevanten Äußerungen zu durchkämmen, es schadet auch der eigenen Reputation wenn die Webseite als Linkschleuder mißbraucht wird.
Ein solches Plugin leistete uns bisher ganz gute Dienste, diese Arbeit von uns fern zu halten. Mit einem Update wurde der Support für den Webserver Nginx urplötzlich eingestellt. Ein Ersatz wurde gesucht und schnell gefunden. Bei der Suche nach Gründen entdeckte ich allerdings einen Rant des Pluginentwicklers, in welchem er seine Erfahrung und Leumund in die Waagschale wirft um dem Webserver schwere Architekturfehler zu unterstellen, für welchen seine Firma gerade den Support gestrichen hatte.
Abwägung der Argumente
Anit Sundi hält dagegen eine sehr stichhaltige Darstellung entgegen, welche auf die architektonischen Unterschiede der beiden Webserver eingeht, dabei aber klar darlegt, daß der Funktionsumfang beider Systeme gleich auf ist und es keineswegs zu den behaupteten Sicherheitsrisiken kommt. Im Folgenden eine kleine Zusammenfassung, die vor allen Dingen Betreibern kleinerer Blogs oder Firmennetzwerke zur Orientierung dienen mag:
Nginx als Reverse Proxy und Serverperformanz
Scott Allen, Author des Plugins von welchem Eingangs die Rede ist, empfahl in seinem Artikel Nginx wegen Konfigurationsproblemen als Reverse Proxy einzusetzen, während dahinter ein vollwertiger Apache als Webserver läuft. Das wäre ihm persönlich natürlich am genehmsten, da er in einer langen Litanei im Grunde genommen nach Ausflüchten sucht um seine Firma in besserem Licht dastehen zu lassen, welche den Support für Nginx zum Ärger zahlreicher Nutzer unvermittelt zusammenstreicht. Er behauptet auf diese Weise das Beste aus beiden Welten verbinden zu können.
Nun ist es tatsächlich so, daß Apache in Verbindung mit einem Reverse Proxy tatsächlich performanter zu betreiben ist und dabei seine ursprünglichen Vorteile beibehält, trotzdem ist dies eine Scheinalternative.
Nginx wird als Webserver durch viele der größten Webseiten wie Wikipedia, Github, Sourceforge, Netflix und witzigerweise sogar WordPress selbst, eingesetzt und hat damit seine Leistungsfähigkeit und Vorteile gegen Apache eindeutig unter Beweis gestellt. Es eignet sich nicht nur für die größten Webseiten, welche durch Effektivität große Ressourceneinsparungen erzielen können, sondern gerade auch für kleinere Betreiber, welche eine oder mehrere Webseiten möglichst preisbewußt betreiben möchten um schneller einen Break-Even-Point erreichen zu können. An diesem Zeitpunkt ist die Entscheidung aus guten Gründen bereits für Nginx gefallen. Einen weiteren, noch fetteren Webserver zusätzlich zu betreiben, beide zu verschränken und dessen Speicherverbrauch hinzunehmen alleine um ein lausiges Plugin zu betreiben ist da nicht hinnehmbar. Das als Alternative darzustellen ist geradezu lächerlich.
Verzeichnisweite Einstellungen
Ein großer Teil des Streits bewegt sich um die Tatsache, daß Scott Allens Plugin Einstellungen manipuliert, welche in der Datei .htaccess gespeichert sind und jeweils Zugriffsberechtigungen und Verhalten des Verzeichnisses regeln, in welchem sie abgelegt ist. So wird es bei Apache gehandhabt und es gebt mehrere Plugins die auf dieses Verhalten ausgelegt sind. Diese ermöglicht es Seitenbetreibern Einstellungen zu ändern ohne eine zentrale Konfigurationsdatei anzufassen, was einer der Gründe ist Apache als System für Shared Hosting einzusetzen, dessen Benutzer natürlich keine Rechte haben Einstellungen mit serverweiten Auswirkungen zu ändern. Unter Nginx ließe sich ein solches Verhalten nachstellen, indem in der Hauptkonfiguration auf eine weitere Datei verwiesen würde, welche durch Benutzer frei geändert werden könnte. Der Regelfall liegt jedoch unter Nginx klar so, daß die meisten Einstellungen und Zugriffsberechtigungen, anders wie bei Apache, zentral geregelt werden.
Für mich persönlich ist dies ohnehin aus Sicherheitsperspektive zu bevorzugen, anstatt es einer potentiell großen Anzahl von Plugins und Verwaltungsfrontends wie Plesk zu erlauben willkürlich wichtige Systemdesignentscheidungen außer Kraft zu setzen. Zwar kann ich nachvollziehen warum Apache in einer Shared Hosting Umgebung nach wie vor breite Anwendung findet, doch finde ich es nicht nachvollziehbar dieser Tatsache überhaupt keine Beachtung mehr zu schenken oder gar Sicherheitsbedenken ins Feld zu führen, wo Nginx auch klare Vorteile gegenüber einer Standardkonfiguration bietet.
Kompatibilität weit verbreiteter Plugins
WordPress wurde selbst entwickelt Apache und Nginx gleichermaßen zu unterstützen. Einsteiger werden beim Shared Hosting sicherlich eher eine vorkonfigurierte Umgebung mit Apache vorfinden, während Nginx eher ambitionierte Administratoren anspricht, welche einen administrativen Mehraufwand in Kauf nehmen um beträchtliche Steigerungen der Serverleistung zu erzielen. Die behauptete Inkompatibilität der beliebtesten Plugins unter WordPress mit Nginx ist so allerdings nicht bewiesen. Die meisten davon laufen bereits out-of-the-box, einige davon erfordern kleine Änderungen die meist in unter 10 Minuten zu realisieren sind. Scott Allens Plugin ist das einzige, zugegebenerweise weit Verbreitete, welches dies nicht unterstützt. Die Verbreitung desselben scheint gerade aber nachzulassen.
Fazit
Die beiden Webserver sind funktional völlig gleichwertig. Apache wird eher als Standard betrachtet während Nginx große Performanzvorteile verspricht für Administratoren mit Vollzugriff auf eine eigene VPS- oder Serverumgebung. Die Tatsache, daß dies durch ein Entwicklerstudio aus völlig eigennützigen Überlegungen, in Zweifel gezogen wird ist geradezu lächerlich aber auch ärgerlich. Das behauptete Sicherheitsrisiko entsteht, wenn das darunterliegende System in einen Kontext gehoben wird, für das es nicht vorgesehen ist.