Onderwerp: Een instabiele dedicated server met slechts 1 website

Eén raad: kick WordPress.

Het is ronduit belachelijk dat je een dedi nodig hebt om 2.000 bezoekers per dag en 40 simultaan aan te kunnen...

Ik draai meer dan één site met 5.000 bezoekers per dag en ca. 80-100 simultaan op een shared LAMP accountje. Te gek voor woorden dat je daar nog Varnish tegenaan moet gooien.

Of is er iets dat ik niet snap, wat betreft "geavanceerde" templates?

Wat verwacht je van een dedi met een processor van amper 50 euro? Ik hoop geen wonderen

En varnish heeft natuurlijk niet echt veel effect (behalve dat het je ram en cpu cycles kost) als je dat op dezelfde bak draait met weinig ram. Het zal wellicht iets helpen als je totaal niks van caching binnen je WordPress gebruikt, maar dat lijkt me sterk omdat het vrij standaard is om een cache module in je wordpress te gooien.
Nu kan het zelfs zijn dat je varnish je ram 'gebruikt' om een zooi te cachen dat in principe reeds static is. (images, html, wp cache bestanden) etc.
Sterker nog, wegens het weinige ram (2GB) heb je zelfs kans dat varnish een diskfile voor zijn cache gebruikt. Als dat zo is dan kun je beter eens goed over je setup nadenken totdat je dat 'Hey, WTF?!?!' moment krijgt

Wellicht kun je eens een vps bij een goede partij overwegen. Een beetje vpsnode heeft namelijk vaak wel processors die 20 keer zo duur zijn waardoor een cpu core gewoon x keer zo snel kan zijn dan een cpu core van je dedi, ook al zijn de snelheden gelijk. En dan zeg ik nog niks over het snellere ram, snellere disk-io e.d.

En een beetje faire beheerder is natuurlijk ook nooit weg. Hoe kun je nu fatsoenlijk controleren wat de issues op je server zijn, als je geen root login hebt op een unmanaged server...?
Bij 40 gebruikers hoeft een server echt niet plat te gaan. Traag als str... modder, ok, maar plat hoeft echt niet.

Wacht even, unmanaged maar GEEN root access? Dat begrijp ik niet.

Het is een server met basic support van Versio waardoor je geen rootaccess meer hebt.

En hoe moet je de non-basic (=uitgebreide/geavanceerde) werkzaamheden dan uit (laten) voeren?


Vanaf mijn s4 met wht app

Wat kun je dan nog wel op de server? Op dit website van Versio lees ik trouwens dit

Bij een dedicated server van Versio krijgt u altijd volledige root toegang tot de server. Hiermee kunt u alles op de server naar wens aanpassen. Dit betekent dat u bijvoorbeeld PHP modules op de server kunt installeren, terwijl dit bij een webhosting pakket of reseller pakket niet mogelijk is. Voor ingewikkelde applicaties is een dedicated server dus uitstekend.

Ben je niet beter af met een VPS?

Klopt, maar als je gaat configureren en kiest voor basic, staat er dit:

Basic
Als u voor deze optie kiest is het CentOS besturing systeem verplicht, ook het DirectAdmin controlepaneel is verplicht. Wij loggen één keer per maand in op de dedicated server, controleren alle logs, updaten alle software en zorgen er voor dat de dedicated server goed beveiligd is. U krijgt zelf bij dit support plan geen root toegang tot de dedicated server.

Ik begin daar steeds meer naar te neigen inderdaad. Maar hoe weet ik dat ik daar niet dezelfde problemen krijg?

Een dedicated server zonder root toegang is m.i. als een auto zonder wielen.

Fijn als je NU een lek hebt en dan een maand kunt wachten totdat iemand inlogt en het update scriptje aantrapt of de beveiliging checked. Maar ja, op elke potje past een dekseltje

Ik ben er nu achter dat het hoogstwaarschijnlijk gaat om een DDOS op de login pagina van Wordpress. (credits komen toe aan ichosting) Ik heb geprobeerd om een extra login laag te creeëren met password protected dir. maar dat werkte niet. Althans, ik hoefde helemaal geen extra wachtwoord in te voeren.

Het blokken van het benaderen van de loginpagina via .htaccess werkte wel, maar dan kon ik er zelf niet meer in. Ondanks dat ik mijn eigen ip adress wel toegestaan had.

Ik heb mijn hosting bedrijf gevraagd om deze laag te creëren via rootaccess daar ik die zelf niet heb. Maar zij reageren heel traag.

Iemand nog ideeën hoe ik dit zelf kan oplossen? Zou het helpen als de login pagina niet wp-login.php heet? Zoja, hoe verander ik dat?

Je kan kijken of de Wordpress addon "Better WP Security" het voor je oplost. Die heeft ook een functie om de login pagina te beschermen.

Of probeer dit eens:

<IfModule mod_rewrite.c>

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
RewriteCond %{HTTP_HOST} ^([^.]+\.)*([^.]+\.[a-z]{2,6})$ [NC]
RewriteCond %2@@%{HTTP_REFERER} !^([^@]*)@@https?://\1/.*
RewriteCond %{HTTP_HOST}@@%{HTTP_REFERER} !^([^@]*)@@https?://([^.]+\.)*\1/.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://%{REMOTE_ADDR}/ [R=301,L]

</ifModule>

Gelukt, login pagina heeft een andere naam. Betekent dit ook dat de ddos aanvallen kansloos zijn en het probleem verholpen moet zijn?

Dat ligt er een beetje aan. Was de ddos attack gericht op het login script?

En wat krijg je nu als je naar de login pagina gaat? Als je nu je normale website krijgt, heb je nog steeds kans dat je site er uit klapt.

Als je doorgestuurd wordt naar een error pagina gaat het waarschijnlijk al en stuk beter. Maar je kunt er ook dan nog steeds last hebben, aangezien die pagina ook vanuit je webserver geserveerd wordt.

je kunt het het beste even aankijken om te zien wat er gebeurd. Heb je statistieken van het moment waarop het gebeurt?

Geen idee, men probeerde gewoon echt in te loggen, zo blijkt uit de lading mailtjes die ik kreeg. Die zijn nu nagenoeg verdwenen, althans, ik krijg er nog steeds een paar binnen.

Als iemand nu naar de oorspronkelijke pagina gaat, komt met op een pagina in de stijl van de template dat de pagina niet gevonden is.

Ik heb helaas geen statistieken omdat ze niet zie aankomen. Google Analytics herkent ze op een of andere manier niet. In de DA kan ik het niet zien omdat de site tijdelijk op een webhost staat en niet op de DS (die hield dat niet lang vol). Ik denk ook dat ik het weer wil gaan uittesten door hem weer op de DS te zetten.