Bekijk Volledige Versie : Wat is er gaande? (Nog niet veel ervaring)
energykind
24/08/13, 09:06
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.
energykind
24/08/13, 09:11
De wp site is volledig up to date.
Veel is van een paar mb paar dag naar bijna 1gb per dag.
energykind
24/08/13, 09:12
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>
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/support/news/general/wp-login-brute-force-attack
Extra htaccess op de admin dir kan ook een hoop helpen hierbij
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.
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.
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:
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:
Jesper bedankt! Ere wie ere toekomt.
Zo hebben wij het ook gedaan inderdaad. Op een iets andere manier, maar wel dezelfde strekking. Dit werkt enorm goed moet ik zeggen.
Wel hebben we hier nog een aanvulling op en dat is dat we een keer per dag de login gegevens automatisch aanpassen, zodat dit niet steeds hetzelfde is.
In /etc/wp-login.sh kun je het volgende plaatsen (gebaseerd op bovenstaande):
echo "Generating random username (6 alphanumeric characters)..."
username=`cat /dev/urandom | tr -dc 'a-z0-9' | fold -w 6 | head -n 1`
echo "Generating two random numbers for math..."
n=$RANDOM
n1=$((RANDOM%20+10))
n2=$((RANDOM%9+1))
result=$(($n1 + $n2))
echo "Creating and saving configuration file..."
CONFFILE="\n
<LocationMatch \"wp-login.php\">\n
AuthType basic\n
AuthName \"WordPress attack protection CAPTCHA. Gebruikersnaam: $username - Wachtwoord: het resultaat van $n1+$n2\"\n
AuthUserFile /etc/httpd/conf/wordpress.passwd\n
Require valid-user\n
</LocationMatch>\n
ErrorDocument 401 \"Authentication required\"\n
\n"
echo -e $CONFFILE > /etc/httpd/conf/wordpressprotect.conf
/bin/chmod 0755 /etc/httpd/conf/wordpressprotect.conf
/bin/rm -f /home/wp-admin-attack-htpasswd-file
htpasswd -bc /etc/httpd/conf/wordpress.passwd $username $result
/bin/chmod 0755 /home/wp-admin-attack-htpasswd-file
echo "Restarting Apache (and nginx if exists)..."
/etc/init.d/httpd restart
echo "All done!"
Geeft enorme rust iig.
Helaas kan ik het bericht niet meer aanvullen.
Het lijkt erop dat dat gezeik nu ook begint op Joomla websites ( /administrator/index.php)
In theorie kun je deze oplossing ook voor Joomla gebruiken.
energykind
25/08/13, 23:38
Hmmm erg handig deze tips. Ik ga morgen even kijken wat mogelijk is.
Wij gebruiken hiervoor mod_security. Voor Wordpress is het heel makkelijk; een host die 10x in korte tijd wp-login.php aanroept is per definitie fout bezig en wordt (tijdelijk) geblokkeerd. Joomla is iets lastiger, omdat de login wordt verwerkt door 'index.php', maar ook daar hebben we een filter voor geschreven die op locaties als '/admin/' en /administrator/ een ratelimiter toepast. Scheelt aanzienlijk, hoewel het bij requests van tientallen verschillende hosts tegelijk soms nog pittig is.
Overigens, wij worden helemaal tureluurs van de attacks de laaste maanden. Echt absurd hoe sommige sites spontaan worden overspoeld met requests en kort daarna alles weer rustig is.
Hostbedrijf.nl
26/08/13, 00:47
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?
Beste,
Dit had ik paar dagen terug ook bij een klant van mij. Op één of andere manier is er een botnet geupload waardoor er veel traffic is gebruikt. Klanten konden niet meer mailen omdat er opeens bleek dat ze de limiet van 250 emails per dag hebben verbruikt.
Je moet de server/hosting opschonen vervolgens moet je je klanten aanraden om wijzigingen van hun script via directadmin/cpanel te doen ( alleen als ze geen virusscanner hebben op pc ). Want merk dat filezilla niet echt waterdicht is. Laatste tijd is er veel van die virussen.
vervolgens moet je je klanten aanraden om wijzigingen van hun script via directadmin/cpanel te doen ( alleen als ze geen virusscanner hebben op pc ). Want merk dat filezilla niet echt waterdicht is. Laatste tijd is er veel van die virussen.
Dat is onzin. Veel hacks gebeuren door brakke outdated software, slechte wachtwoorden of malware. Met Filezilla is niets mis, echter moeten mensen hun pc schoon houden van meuk. Als er malware opstaat kunnen ze ook je DA login achterhalen net zoals je FTP wachtwoord.
Ik vind het anders wel een erg kwalijke zaak dat Filezilla de site manager entries in plane tekst opslaan. Enige encryptie, of op zijn minst de mogelijkheid daartoe met een master key oid, zou in mijn ogen wel op zijn plaats zijn. Maar ik deel overigens wel de mening dat outdated versies van populaire CMS systemen een grotere dreiging vormen.
Ik vind het anders wel een erg kwalijke zaak dat Filezilla de site manager entries in plane tekst opslaan. Enige encryptie, of op zijn minst de mogelijkheid daartoe met een master key oid, zou in mijn ogen wel op zijn plaats zijn. Maar ik deel overigens wel de mening dat outdated versies van populaire CMS systemen een grotere dreiging vormen.
Volg ik deels, maar je zou het ook zo kunnen bekijken, waarom op een plain text protocol als ftp de wachtwoorden encrypted opslaan. Als er malware op je pc staat kan de malware even goed met een tcpdump achter de gegevens komen. Dat het zou helpen is een feit, maar er is meer dan 1 manier om wachtwoorden te weten te komen eens je toegang hebt op een client zijn pc door middel van malware/exploits.
Cas-hosting
02/09/13, 22:42
Hoe reageren jullie klanten op deze aanvulling met extra bescherming? Vinden ze het lastig? Of zijn ze juist blij dat jullie pro-actief actie ondernemen?
Persoonlijk lijkt het mij een ideale oplossing tegen de brute force aanvallen.
energykind
03/09/13, 09:03
Het probleem zat in een oude template van zijn site. Ik heb deze geupdate en alles ging weer terug naar vroeger :)
Volg ik deels, maar je zou het ook zo kunnen bekijken, waarom op een plain text protocol als ftp de wachtwoorden encrypted opslaan. Als er malware op je pc staat kan de malware even goed met een tcpdump achter de gegevens komen. Dat het zou helpen is een feit, maar er is meer dan 1 manier om wachtwoorden te weten te komen eens je toegang hebt op een client zijn pc door middel van malware/exploits.
We gaan wel een beetje offtopic zo maar goed. Ik ben zeker met je eens dat er vele manieren zijn om wachtwoorden te stelen. Het grote verschil tussen sniffen of het Filezilla configuratie bestandje te copieren en dat is dat het configuratie bestand altijd aanwezig is en er niet altijd een verbinding gemaakt wordt die opgepikt kan worden. Bovendien kan Filezilla ook overweg met ftps wat het sniffen alweer wat lastiger maakt. Maar ja op een gecomprimeerd systeem / netwerk is natuurlijk alles mogelijk.
Voor deze categorie mensen die dagelijks verbinding maken met een enkele FTP server is het risico even groot op sniffen of het Filezilla bestandje. Neem echter bv een (luie) webbouwer met 50 klantjes of een website eigenaar die 1 keer jaar FTP gebruikt om een PDF document te overschrijven. Dan zou het wel degelijk een groot verschil maken in termen van tijd tussen infectie met de malware en de diefstal van de gegevens. Die tijd geeft virusscanners misschien mooi de tijd om hun detectie rules te updaten.
Het is niet altijd dat er geen referer word meegegeven, daar zou ik dus niet vanuit gaan.
Je kunt de tekst van cfmweb beter korter maken omdat sommige browsers de tekst inkorten (o.a. chrome). Je krijgt dan alleen het eerste en laatste stukje te zien en dan is het onduidelijk. Ik heb er zelf dit van gemaakt "Voor meer informatie www.firemultimedia.nl/wpbeveiliging Login met GEBRUIKERSNAAM: login en WACHTWOORD: login"
vitahostnl
13/10/13, 15:42
De DDOS heeft niks WP te maken, de SYN_SEND paketten zorgen voor je dataverkeer. Ik zou zeggen bespreek met de ISP je mogelijkheden.
TotallyHosted
14/10/13, 11:54
Wel een slimme oplossing zo server-wide. Denk echter dat het via een mooie mod_security-regel wellicht eenvoudiger voor de klant werkt. Heeft iemand hier nog een mooie regel voor?
Wij gaan het in elk geval vanmiddag ook bespreken, aangezien het steeds vaker voorkomt.
Het is niet altijd dat er geen referer word meegegeven, daar zou ik dus niet vanuit gaan.
Je kunt de tekst van cfmweb beter korter maken omdat sommige browsers de tekst inkorten (o.a. chrome). Je krijgt dan alleen het eerste en laatste stukje te zien en dan is het onduidelijk. Ik heb er zelf dit van gemaakt "Voor meer informatie www.firemultimedia.nl/wpbeveiliging Login met GEBRUIKERSNAAM: login en WACHTWOORD: login"
Klopt helemaal. Ik heb hem inmiddels ook ingekort.
TotallyHosted
14/10/13, 13:14
Inmiddels naast Wordpress met <DirectoryMatch "/administrator/"> (in plaats van de Files-regel, en dan natuurlijk ook </DirectoryMatch> in plaats van </Files>) hetzelfde gedaan bij Joomla.
Hoe reageren jullie klanten op deze aanvulling met extra bescherming? Vinden ze het lastig? Of zijn ze juist blij dat jullie pro-actief actie ondernemen?
Persoonlijk lijkt het mij een ideale oplossing tegen de brute force aanvallen.
De extra bescherming staat er nu twee dagen op en het is een drama. De helft van de mails en telefoontjes van afgelopen twee dagen gaan hierover. Voor het inschakelen is er een nieuwsbrief gestuurd, bericht op Twitter, Facebook en op de website bij het nieuws dus heb toch wel m'n best gedaan om de klant te informeren. Het blijkt maar weer dan mensen niet lezen en daardoor dus de gebruikersnaam en wachtwoord niet zien.
Het liefste zou ik de oplossing van Transip gebruiken. Zie http://www.webhostingtalk.nl/beveiliging/181581-captcha-code-voor-wordpress-admin-login.html#axzz2hbRTTbNQ.
De extra bescherming staat er nu twee dagen op en het is een drama. De helft van de mails en telefoontjes van afgelopen twee dagen gaan hierover. Voor het inschakelen is er een nieuwsbrief gestuurd, bericht op Twitter, Facebook en op de website bij het nieuws dus heb toch wel m'n best gedaan om de klant te informeren. Het blijkt maar weer dan mensen niet lezen en daardoor dus de gebruikersnaam en wachtwoord niet zien.
Het liefste zou ik de oplossing van Transip gebruiken. Zie http://www.webhostingtalk.nl/beveiliging/181581-captcha-code-voor-wordpress-admin-login.html#axzz2hbRTTbNQ.
Dat mensen niet lezen is bekend. Maar je kunt supportvragen hierover kort beantwoorden met een verwijzing naar het bericht op je website. (copy-paste antwoord)
Persoonlijk beantwoord ik liever deze vraag, dan vragen waarom de server traag is of er helemaal uit ligt als gevolg van een bruteforce-aanval. Men verwijt ons dan dat we er niks aan (kunnen) doen. Nu heeft men over het algemeen begrip, en vinden het positief dat we er proactief mee omgaan.
De oplossing van TIP laadt nog steeds een pagina en is dus minder effectief tegen de overbelasting van je server.