PDA

Bekijk Volledige Versie : Een instabiele dedicated server met slechts 1 website



M.Vermeer
15/09/13, 02:31
Beste,

Ik zit met het volgende probleem. Ik heb 1 website die per dag 2000 bezoekers moet kunnen ontvangen. Het liefst ook dat er 40 mensen tegelijkertijd de site kunnen bezoeken. Om dit te kunnen bewerkstelligen heb ik een dedicated server type Versio #1 NL (http://www.versio.nl/dedicatedservers.php)

Helaas kunnen zij er niet voor zorgen dat deze server stabiel draait. Iedere keer als ik de site van mijn oude webhost, naar de server verhuis, kan de DS het slechts enkele uren aan, voordat hij eruit knalt. In die uren is de site overigens wel helemaal naar wens qua snelheid. Volgens de provider komt dit doordat de aanvragen te veel zijn voor dit type server.

De site is gemaakt met wordpress, maar heeft een aardig geavanceerde template. de inhoud is voornamelijk tekst en afbeeldingen. De database is ongeveer 25mb. Er is een firewall op de DS geïnstalleerd. Daarnaast is de DS voorzien van Varnisher (o.i.d. vanwege cache).

Het enige wat ik wens is een werkende website die gewoon snel te laden is. Kan iemand mij helpen? Vraag gerust om extra informatie mocht dat nodig zijn. Houd er wel rekening mee dat ik geen expert ben op dit gebied, al ben ik bereid om alles te leren ;)

Bart L
15/09/13, 08:37
Er zijn een hoop partijen die je kunnen en willen helpen, maar ik betwijfel of een budget van 29,99 per maand daarbij helpt.

24x7group
15/09/13, 09:59
Je zal ff moeten uitzoeken waarom de server uitvalt, anders kan je ook geen oplossing vinden.
Komt het door een te hoge load? Is de disk i/o de bottleneck? Mogelijk het geheugen.

Het is op dit moment effe moeilijk om je hier een geschikt advies in te geven. Wil versio dit niet voor je bekijken / oplossen?

dreamhost_nl
15/09/13, 10:06
Doe eens een onderzoek en kijk hoeveel geheugen er alleen al nodig is per bezoeker en doe dit dan maal de hoeveelheid aan bezoekers die je gelijkertijd wenst te hebben. Hoogstwaarschijnlijk kom je dan met 8GB aan geheugen al meer in de buurt.

SF-Jeroen
15/09/13, 11:11
Aangezien we niet weten wat de bottleneck is kan niemand hier natuurlijk precies zeggen wat de oplossing is. Is Varnish uberhaupt goed geconfigureerd (check headers even van je frontpage) en hoeveel geheugen is er aan varnish gegeven?

ichosting
15/09/13, 12:25
Een ander mogelijkheid is, gezien het wordpress is, dat het een ddos op wordpress logins zelf is? Dat kan de machine ook onderuit halen.
Probeer hier eerst eens een beveiliging op toe te passen?

M.Vermeer
15/09/13, 16:53
De bottleneck is waarschijnlijk een enorme load. Ik krijg ook continue mailtjes van brute force attack. Maar Versio zou daar een beveiliging voor geïnstalleerd hebben. Hoe Varnish is geïnstalleerd en hoeveel geheugen die heeft, weet ik niet. Hoe kom ik daarachter?

Hoe beveiliging is een ddos op wordpress logins?

Ter aanvulling: ik maak ook gebruik van Cloudflare

ichosting
15/09/13, 17:24
Je kunt een extra login laag plaatsen (via .htaccess) op de wp-login.php file.
De hoge load wordt vermoedelijk wel veroorzaakt door die aanvallen.

Als je de kans hebt, zou je met je server-status pagina ten tijde van de load eens gaan kijken welke scripts er op dat moment draaien.

M.Vermeer
15/09/13, 17:55
Hoe plaats ik die extra login laag? wat doet dat in praktijk met de site?

Ik zou dat inderdaad wel eens willen zien, al weet ik natuurlijk niet wanneer zo'n load plaatsvind.

Bart L
15/09/13, 18:23
Je vertelde dat je graag alles zelf uitzoekt, dat is ook prima want je hebt een non-managed omgeving.
Zoek eens op google op Wordpress login ddos etc , er is zelfs een prima topic te vinden op WHT met het nodige aan uitleg hierover.

M.Vermeer
15/09/13, 20:10
Ik heb gezegd dat ik graag leer, dat is iets anders natuurlijk. Ik ben al weken bezig met dit probleem, heb vele google-sessies achter de rug, maar kom hier simpelweg niet uit.

Vandaar mijn vraag: hoe zorg ik dat ik dit oplos? Er komt een antwoord over het plaatsen van een extra loginlaag via .htaccess. Ik heb geen idee wat dat is, wat het in praktijk doet met de site. Daarom vraag ik om wat uitleg ;)

SF-Jeroen
15/09/13, 20:14
Met alle respect, htaccess is echt basiskennis. Als je dat niet weet is het echt onmogelijk om zelf een dedicated server te onderhouden, laat staan een niet standaardconfiguratie met Varnish. Ik zou dus niet verder zoeken naar een oplossing, maar gewoon ergens een managed server nemen, of een shared hostingpakket op clusterhosting bij een van de aanbieders hier in NL. Hierbij staat je site verdeelt over diverse servers en zal capaciteit geen probleem meer zijn. Daarnaast is dit niet duurder en heb je geen zorgen meer over het managen van de machines en kun je je bezighouden met de site zelf.

M.Vermeer
15/09/13, 20:21
Ik heb een server met basic support van Versio. Dat houdt in dat ik geen root toegang heb en Versio voor mij die Varnish heeft geïnstalleerd. Ik kan dan ook niet controleren wat de configuratie daarvan is.

En als ik dan een managed server moet nemen. Kan ik dan beter een VPS nemen of maakt dat niet uit?

CT0
15/09/13, 20:23
Dit is wel een handige link voor je:

http://codex.wordpress.org/Brute_Force_Attacks

Je kunt makkelijk uitsluiten of het aan een brute force ligt door de admin er tijdelijk uit te slopen. Volgens mij is dat een kwestie van de wp-admin te renamen (weet ik niet zeker).

Je kunt natuurlijk ook altijd in het vraag en aanbod deel van het forum een oproep plaatsen voor een managed server of commerciele support. Het zou ook kunnen dat je mysql of apache onder de requests bezwijkt.

Maar volgens mij zou een managed VPS ook al voldoende voor je zijn (qua CPU en mem, storage kan ik niet inschatten).

SF-Jeroen
15/09/13, 20:24
Daar verschillen de meningen over, maar dat kun je doen ja. Maar ik zou eigenlijk eerder voor clusterhosting gaan. Pieken van 40 bezoekers is natuurlijk niet echt veel voor clusters van 20+ servers zoals verschillende bedrijven dat aanbieden. Daarnaast is dit veel goedkoper dan een HA VPS. Die van Versio zijn zowel niet HA als uberhaupt vooruit te branden volgens velen.

cyrano
15/09/13, 21:34
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?

systemdeveloper
15/09/13, 23:04
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.

Domenico
16/09/13, 11:49
Wacht even, unmanaged maar GEEN root access? Dat begrijp ik niet.

M.Vermeer
16/09/13, 13:01
Het is een server met basic support van Versio waardoor je geen rootaccess meer hebt.

Age
16/09/13, 13:53
En hoe moet je de non-basic (=uitgebreide/geavanceerde) werkzaamheden dan uit (laten) voeren?


Vanaf mijn s4 met wht app

asusk7m550
16/09/13, 16:34
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?

M.Vermeer
16/09/13, 16:42
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?

dreamhost_nl
16/09/13, 16:52
Een dedicated server zonder root toegang is m.i. als een auto zonder wielen.

systemdeveloper
16/09/13, 16:57
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 ;)

M.Vermeer
16/09/13, 18:46
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?

Dreas
16/09/13, 18:50
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.

systemdeveloper
16/09/13, 18:59
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>

M.Vermeer
16/09/13, 19:27
Gelukt, login pagina heeft een andere naam. Betekent dit ook dat de ddos aanvallen kansloos zijn en het probleem verholpen moet zijn?

asusk7m550
16/09/13, 20:08
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?

M.Vermeer
16/09/13, 20:20
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.

M.Vermeer
16/09/13, 20:51
De site gaat nu terug naar een error pagina. Als ik die terug zou laten leiden naar een pagina op mijn webhost, zou dat schelen? Die webhost gebruik ik toch bijna niet.

asusk7m550
16/09/13, 22:35
Ik zou de error pagina op de server zelf houden. Die moet niet zoveel performance trekken.

Hostinger
16/09/13, 22:46
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 las net dat je gebruikt maakt van Cloudflare, daarom werkt een .htaccess IP block sowieso niet out of the box. Cloudflare fungeert als een proxy, dus standaard komen alleen de IP adressen van Cloudflare bij de server binnen en niet je eigen. Even the mod_cloudflare module installeren en het is klaar, maar zonder root-toegang en "basis management" kun je dat ook vergeten.

M.Vermeer
17/09/13, 01:13
Ik heb een plugin gevonden (WP Security) die eigenlijk alles in huis lijkt te hebben wat ik nodig heb: het verbergen van de inlogpagina, het doorverwijzen van brute force attacks naar de eigen host van de attacker ipv een eigen error pagina en limit login attemps. Daarnaast heeft de plugin nog vele opties. Ik ben zeer benieuwd of dit afdoende is en zal dat morgen even testn.

M.Vermeer
19/09/13, 16:13
De plugin lijkt te werken. De site draait op de server en die is er nog niet uitgeklapt.

M.Vermeer
19/09/13, 23:48
De server kan niet meer dan 10 a 15 bezoekers aan. Is dat normaal?

Boyke
20/09/13, 01:03
Als je nu even de URL van je website hier plaatst dan kan er gekeken worden of de pagina (delen) goed ge-cached worden. 10 a 15 gelijktijdige bezoekers is erg weinig in ieder geval.

The-BosS
20/09/13, 01:18
De server kan niet meer dan 10 a 15 bezoekers aan. Is dat normaal?

Niet echt nee, maar als je dan toch een managed dedicated server hebt is het dan niet aan de leverancier om je probleem op te lossen. En dan geen oplossing als neem een zwaardere dedicated, want dat is complete zever als hij al onderuit gaat na 15 bezoekers.

dreamhost_nl
20/09/13, 09:41
De server kan niet meer dan 10 a 15 bezoekers aan. Is dat normaal?

En wat is er op zo'n moment aan de gang?
Is er een (te) hoge server load... klappen er services uit... is de server geheel niet meer bereikbaar...?

M.Vermeer
02/10/13, 02:14
Volgens het hostingbedrijf lag het aan het aantal aanvragen. Server is veranderd naar een met meer capaciteit. Problem solved.

The-BosS
02/10/13, 07:09
Volgens het hostingbedrijf lag het aan het aantal aanvragen. Server is veranderd naar een met meer capaciteit. Problem solved.

Hoezo het lag aan het aantal aanvragen, met wat je opgegeven hebt lijkt mij de server krachtig genoeg voor 15 tot 50 bezoekers of je moet er aanzienlijk meer gehad hebben dan. De vraag is dus of je probleem hier mee daadwerkelijk opgelost is, ga je in de toekomst telkens zwaardere hardware er tegen gooien of lijkt het je niet beter om misschien eens wat zaken te gaan optimaliseren.

olaf2
02/10/13, 10:30
Een beetje drukke Wordpress website kan wel wat problemen veroorzaken :)
Maar een kleinere server met Directadmin kan het wel aan.
Voor de WP sites die ik in beheer heb zorg voor:

Login beperken met htacces (in public_html)

<Files wp-login.php>
order deny,allow
Deny from all
# je IP adres
allow from 00.00.00.00
</Files>

Helaas werkt dit niet wanneer een onbekend aantal gebruikers moet inloggen. In dot geval zou je een plugin voor frontend login moeten gebruiken.

Beveilig je wp-admin map met htaccess (plaats een .htaccess bestand in de wp-admin map)

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Password Protected Area"
AuthType Basic
order deny,allow
deny from all
# je IP adres
allow from 00.00.00.00


Verder heb je echt een cache plugin nodig, mijn favoriet is Supercache. Wanneer je op een pagina veel afbeeldingen hebt zou ik nog een CDN gebruiken (MaxCDN is erg goed en voordelig)

Wanneer je DA op je server draait kan je met de CSF firewall de forum spam bots blokkeren, Versie kan deze plugin voor je installeren. Het CSF config bestand heeft erg veel info over hoe het werkt.

Verder zou het zeker helpen om je website te optimaliseren, zoals hier omschreven:
http://www.web-development-blog.com/archives/optimize-your-wordpress-website/

Op enkele sites gebruik ik sinds een aantal maanden de volgende plugin, werkt erg goed:
http://www.wordfence.com/

Ik hoop dit helpt :)