Onderwerp: Wat is er gaande? (Nog niet veel ervaring)

Een klant van mij heeft een wordpress site. Deze maand doet hij ineens erg veel traffic. Als ik naar zijn bezoekersaantallen kijk, zit hij op nog geen 200 deze maand. Hij heeft een cap van 250 mailtjes per dag. Zijn wordpress website is up to date (plugins, core en theme). En toch doet ie zoveel bandbreedte.

DA sloot dit account automatisch af en ik heb m wel wat extra bandbreedte gegeven omdat ik over heb dus is ie nu wel online.

Wat is er gaande?
Hoe kan ik dat zien?
Wat kan ik er aan doen?

wat is veel?

begin eens met updaten van wp en de plugins naar de laatste versie.

De wp site is volledig up to date.
Veel is van een paar mb paar dag naar bijna 1gb per dag.

Soms wel meer dan 1 gb. Afgelopen week was t 5 gb op 1 dag.

250 mails op 1dag is aardig wat. Zou dit eens na lopen.

Meestal is dit een brak gastenboek of conment module. In iedergeval een plugin. Check je maillog ff welk script die mails stuurt. En kijk dan of het van 1 op komt ofzo.

Helaas denk ik eerder een grote DDOS (vanuit naar schatting 30k hosts) dat zorgt wel voor wat traffic.

Tijdelijke oplossing -> /etc/httpd/conf/httpd.conf

Onderaan ->

<Files wp-login.php>
order deny,allow
deny from all
allow from ipadresvanklant # Klant IP
</Files>

Oorspronkelijk geplaatst door Bart L

Helaas denk ik eerder een grote DDOS (vanuit naar schatting 30k hosts) dat zorgt wel voor wat traffic.

Tijdelijke oplossing -> /etc/httpd/conf/httpd.conf

Onderaan ->

<Files wp-login.php>
order deny,allow
deny from all
allow from ipadresvanklant # Klant IP
</Files>

Bij ons is het op die wp sites meestal een brakke plugin of 1 ip. Haal je er ook vaak wel uit met apache server-status.

Sent from my GT-I9300 using webhostingtalk mobile app

met server-status even kijken wie wat doet en dat IP in de blocklist gooien

Onze ervaring is, helaas, dat het geen enkele IP's zijn die je dan kunt blocken. We zien aanvallen met 500-1000 verschillende IP's per keer.

"A large botnet of around 90,000 compromised servers has been attempting to break into WordPress websites by continually trying to guess the username and password to get into the WordPress admin dashboard."

http://www.inmotionhosting.com/suppo...e-force-attack

Extra htaccess op de admin dir kan ook een hoop helpen hierbij

Oorspronkelijk geplaatst door Alexander

Extra htaccess op de admin dir kan ook een hoop helpen hierbij

Dat is leuk voor een enkele website, maar op shared hosting servers is dat wat minder eenvoudig te realiseren.

Jesper Weiland van Exonet had een oplossing die server-wide werkt. Inmiddels heb ik dit ook op mijn shared hosting servers toegepast.

Een password bestand aanmaken:

htpasswd -c /etc/httpd/conf/wordpress.passwd login

Daarmee een wachtwoord aanmaken voor user login (in dit voorbeeld user:login en passwd:login) het maakt in feite niet uit, het gaat erom dat we hiermee een extra stap inbouwen om toegang tot wp-login.php te beperken.

En dan in httpd.conf onderaan het volgende toevoegen:

<Files wp-login.php>
AuthType basic
AuthName "Vanwege aanhoudende bruteforce-aanvallen op WordPress websites hebben we een extra inlog maatregel moeten nemen. Gebruik de volgende gegevens om in te loggen gebruikersnaam: login wachtwoord: login"
AuthBasicProvider file
AuthUserFile /etc/httpd/conf/wordpress.passwd
Require valid-user
ErrorDocument 401 default
</Files>

Jesper bedankt! Ere wie ere toekomt.

Helaas kan ik het bericht niet meer aanvullen.

Het lijkt erop dat dat gezeik nu ook begint op Joomla websites ( /administrator/index.php)

Jesper, top! Lijkt me een prima oplossing die minder storend is voor de gebruikers

Ik denk dat er een nettere oplossing mogelijk is. Ik heb niet gekeken naar de requests, maar over het algemeen geven bots geen referrer mee. Dan kun je daar in principe ook op filteren.

Code:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-login\.php*
RewriteCond %{HTTP_REFERER} !.*%{HTTP_HOST}.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]

Niet getest overigens (ik weet ook niet 100% zeker of dit binnen een <Files> element mag), maar lijkt mij minder opdringerig dan een extra inlog scherm. Hoe effectief het ook is.