HTTP Error 403 zonder duidelijke reden

[Wildfire]

Ik ben sinds kort als (part-time) zelfstandige actief met een computerhulpbedrijf. Heb bij Webreus een domein lopen daarvoor en heb er een Joomla 1.7 site op draaien. Ik dacht dat alles OK was, site werkte perfect, is in Google ook goed vindbaar op de door mij gewenste zoekwoorden.

Maar vandaag kwam ik erachter dat mijn site bij sommige users of robots (zoals de headercheck van http://www.webconfs.com/http-header-check.php) HTTP error 403 retourneert in de HTTP-headers. Ik heb echter geen enkel idee waarom. Ik zou verwachten dat HTTP error 403 ook zou betekenen dat Google niets kan indexeren, maar Google indexeert dus wel gewoon. Net zoals dat als ik de site bekijk alles goed gaat.

Voordat ik de URL van m'n site noem: aub geen discussie over de content van de site, daar is dit topic niet voor. Ik ben hier puur om met jullie hulp te achterhalen waarom de HTTP headers een 403 error geven.

URL Van de site is: *niet relevant*

Ik las ergens dat dit veroorzaakt zou kunnen worden door enkele Joomla templates of plugins als deze niet aangeschaft zouden zijn. Het template is echter gewoon de default beez_20 template met een lichte aanpassing en commerciële plugins heb ik netjes gekocht (RS Firewall, RS Forms) dus dat lijkt me dan ook niet het probleem.

Mijn .htaccess (comments eruit gefilterd):

code:

Options +FollowSymLinks

RewriteEngine On

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F]

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_URI} !^/index\.php
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]

[ Voor 44% gewijzigd door RobIII op 18-01-2012 01:24 ]

[RobIII]

Je site is niet relevant en zolang 't geen minimale testcase is om je probleem te reproduceren en dus verwijst naar een aller-erop-en-eraan site valt 't onder spam. Als je een 403 krijgt (die ik overigens niet zie; ik krijg een 200 OK volgens Chrome) geloven we dat zo ook wel. Eventueel doe je een copy/paste van de headers zoals je ze krijgt (dat kan met Firebug/IE F12 Dev.tools/Chrome Dev.tools/Safari Dev.tools/Opera Dragonfly/Fiddler2/Wireshark).

Verder zou ik eens beginnen met een CTRL-F op "403" in (o.a.) je htaccess en je directory waar alle bestanden staan om eens na te gaan waar eventueel een 403 gegeven zou kunnen worden. Ik zie er sowieso al 1 in je htaccess staan, maar die is 't niet lijkt me.

Ook stellen we 't op prijs als je code post dat je enkel relevante(!) delen post; en dan ook nog als 't even kan tussen code tags i.p.v. quote-tags. Zo kunnen, bijvoorbeeld, de eerste 20 regels en een hele zut "comments" (# vooraan de regel) van je htaccess al weg, dat maakt de zaak al meteen stukken overzichtelijker.

Dit is wat ik zie op de meeste pagina's die ik aanklikte:

code:

Request URL:http://example.org/diensten.html
Request Method:GET
Status Code:200 OK

Cache-Control:no-cache
Connection:close
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Wed, 18 Jan 2012 00:12:08 GMT
P3P:CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Pragma:no-cache
Server:Apache/2.0.54 (Fedora)
Transfer-Encoding:chunked
X-Content-Encoded-By:Joomla! 1.6
X-Powered-By:PHP/5.2.17

[ Voor 36% gewijzigd door RobIII op 18-01-2012 01:26 ]

[Wildfire]

RobIII schreef op woensdag 18 januari 2012 @ 01:09:
Je site is niet relevant; als je een 403 krijgt (die ik overigens niet zie; ik krijg een 200 OK volgens Chrome) geloven we dat zo ook wel. Eventueel doe je een copy/paste van de headers zoals je ze krijgt (dat kan met Firebug/IE F12 Dev.tools/Chrome Dev.tools/Safari Dev.tools/Opera Dragonfly/Fiddler2/Wireshark)).

Ja, hier bij mij gaat alles probleemloos. Werd door iemand anders (site waar een link van mij wordt opgenomen maar link terug via mij werkt niet, hun site checkt dat en kreeg een 403) geconstateerd.

Als je via http://www.webconfs.com/http-header-check.php checkt (bv. voor de frontpage) zie je dit:

HTTP/1.1 403 Forbidden =>
Date => Wed, 18 Jan 2012 00:14:24 GMT
Server => Apache/2.0.54 (Fedora)
X-Powered-By => PHP/5.2.17
Set-Cookie => d582036c922b877e9bda64eed8fc8b25=be9e9ff5e375bd0bd4b01f635b76451b; path=/
Connection => close
Content-Type => text/html

Maar als ik de site zelf hier open werkt alles prima (HTTP 200 dus). Erg maf.

Verder zou ik eens beginnen met een CTRL-F op "403" in (o.a.) je htaccess en je directory waar alle bestanden staan om eens na te gaan waar eventueel een 403 gegeven zou kunnen worden. Ik zie er sowieso al 1 in je htaccess staan.

Die in de .htaccess is default van Joomla dus was al zo.

Ook stellen we 't op prijs als je code post dat je enkel relevante(!) delen post; en dan ook nog als 't even kan tussen code tags i.p.v. quote-tags. Zo kunnen, bijvoorbeeld, de eerste 20 regels en een hele zut "comments" (# vooraan de regel) van je htaccess al weg, dat maakt de zaak al meteen stukken overzichtelijker.

Is aangepast.

[Ventieldopje]

code:

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit `attempts` to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

Nou weet ik niet hoe het bij webreus zit met beveiliging maar volgens mij is dit zelfs met de standaard PHP instellingen al niet eens meer mogelijk wat ze hier in de htaccess proberen te voorkomen

Bovendien is dat het blok dat je probleem veroorzaakt op een of andere manier lijkt mij, sloop dat er uit en het zal werken Wel erg jammer dat dit nou weer een compleet topic nodig heeft terwijl je hier gewoon makkelijk zelf op had kunnen komen zoals hier boven ook al genoemd wordt. Ik kan het niet vaak genoeg zeggen maar ... lezen!

[ Voor 7% gewijzigd door Ventieldopje op 18-01-2012 01:19 ]

[RobIII]

Wildfire schreef op woensdag 18 januari 2012 @ 01:16:
Ja, hier bij mij gaat alles probleemloos. Werd door iemand anders (site waar een link van mij wordt opgenomen maar link terug via mij werkt niet, hun site checkt dat en kreeg een 403) geconstateerd.

Als je via http://www.webconfs.com/http-header-check.php checkt (bv. voor de frontpage) zie je dit:

Ik weet niet wat Joomla of die plugins allemaal precies doen, maar ik kan me voorstellen dat bepaalde useragents (of bijvoorbeeld met *bot* of iets dergelijks in de naam) een 403 krijgen om eender welke reden. Of dat dan zo ingesteld is, aan een plugin ligt, een bug is of whatever remains to be seen.
Als ik je url in, bijvoorbeeld, http://validator.w3.org mik lijkt die wel een zinnige response te krijgen. Evenals deze, deze en deze. Deze krijgt weer wel een 403.

Wildfire schreef op woensdag 18 januari 2012 @ 01:16:
Die in de .htaccess is default van Joomla dus was al zo.

Ik zei ook al: dat lijkt 'm me niet te zijn.

[ Voor 19% gewijzigd door RobIII op 18-01-2012 01:23 ]

[Wildfire]

Oorzaak gevonden: de RS Firewall plugin. Als ik die disable krijg ik via http://www.webconfs.com/http-header-check.php gewoon een HTTP 200 te zien.

Ik ga nu dutten, morgen maar eens contact opnemen met de makers van die plugin.

-- Edit: specifiek het 'Protect against DoS attacks' gedeelte dat tegen overvloedige requests van bots zou moeten beschermen. Die maar even uitgezet en de rest aan laten staan.

[ Voor 28% gewijzigd door Wildfire op 18-01-2012 01:40 ]

[RobIII]

Out of curiosity: hoe heb je dat nu ontdekt? Gewoon een-voor-een plugins gaan uitschakelen? Of je directory/directories doorzocht op de string "403" of...?

[Wildfire]

RobIII schreef op woensdag 18 januari 2012 @ 01:41:
Out of curiosity: hoe heb je dat nu ontdekt? Gewoon een-voor-een plugins gaan uitschakelen? Of je directory/directories doorzocht op de strinf "403" of...?

Gegoogled op 'joomla http 403 no reason', één van de sites noemde security plugins als mogelijke oorzaak. Dus meteen naar RS Firewall gegaan, compleet uitgeschakeld werkte alles OK. En toen optie-voor-optie (was gelukkig één van de eerste opties) even alles nagelopen.

* Wildfire gaat nu echt dutten, zonder dit 403-gedoe had ik al een uur liggen dutten

[Ventieldopje]

Even gekeken naar dat RSFirewall, naar mijn inzien kun je die plugin beter verwijderen en je geld terug vragen. Het enige nuttige, en dan ook het enige (als het goed geïmplementeerd is) dan is het de CAPTCHA bij het administrator paneel.

Verder zijn het gewoon simpele dingen die je zelf ook kan doen zoals een extra wachtwoord op het administrator paneel d.m.v.. htaccess. Die database "check" is al helemaal waardeloos, ze kijken of er iets loos is met je database en "proberen" dat dan te fixen met standaard MySQL optimise commando's

Als je webhost goed zijn werk doet en zijn server(s) veilig houd en jij gewoon Joomla blijft updaten en geen gekke plug-ins installeert is er niks aan de hand