Pagina1 van 1

WordPress – Mod_security problemen bij posts en opmerkingen opgelost

WordPress – Mod_security problemen bij posts en opmerkingen opgelost
   0

In de wereld van WordPress, is het volgende probleem niet onbekend;

Een gebruiker plaatst een opmerking of een post en na het drukken op de “submit” of “plaatsen” knop wordt hij of zij meteen doorgestuurd naar de hoofdpagina en er wordt helemaal niks geplaatst. Al het werk weg en een gefrustreerde gebruiker zonder wat voor uitleg dan ook.

Bij WordPress wordt dit vaak veroorzaakt door een zogenaamde false-positive van mod_security.

In dit korte artikel, laat ik je zien hoe je dit probleem kunt vinden en oplossen zonder al te veel moeite.




WordPress, Mod_Security en False Positives

Wat ik zelf gemerkt hij, bij mijn web-server, is dat mod_security soms een false-positive genereert.

De taak van mod_security is om gevaarlijke “code” te vangen die jouw web-server en/of database zouden kunnen beschadigen of vernielen.
Een van de meest voorkomende false-positives is de zogenaamde “SQL injectie“, een techniek waarbij een kwaadwillende “aanvaller” bepaalde tekens (als voorbeeld) in een tekst zet waardoor het SQL (database) statement anders wordt dan gedacht en schade kan aanrichten op jouw web-server.

Uiteraard willen we dat soort ongein niet, en mod_security doet het goed voor wat betreft dat soort foute “injecties”.

Het is echter wel heel moeilijk om een 100% perfect regel te maken die dit soort injecties kan afvangen, en een gevolg daarvan is dat je dus soms een zogenaamde false-positive krijgt – dus iets wat goed is, toch als fout gezien gaat worden. Het gevolg: na het proberen te plaatsen van een legitieme opmerking beland de gebruiker op de hoofdpagina en zijn of haar opmerking is verloren.

Mod_security heeft overigens meerdere regels om kwaadaardige “aanvallen” af te vangen. Het is dus niet maar een enkel regeltje. De regel die echter heel vaak problemen levert is rule “300016” met de melding “Generic SQL injection protection”.

Je kunt dit op jouw web-server controleren door de mod_security log bestanden te bekijken.
Op mijn server us dat: /etc/httpd/logs/modsec_audit.log of /etc/httpd/logs/error.log

Als je deze log gaat bekijken, via een shell of SSH, dan kun je met het “tail” commando kijken wat de fout melding is door dit gelijk na het plaatsen van een falende opmerking uit te voeren. Als voorbeeld:


tail /etc/httpd/logs/error_log

[Sun Mar 14 07:57:23.857486 2016] [:error] [pid 1328] [client 77.161.107.217] ModSecurity: Access denied with code 500 (phase 2).
Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+
from|bulk[[:space:]]+insert|union.+select|convert.+(.*from)" at ARGS:comment.
[file "/usr/local/apache/conf/modsec2.user.conf"] [line "379"] [id "300016"]
[rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"]
[hostname "www.example.com"] [uri "/wp-comments-post.php"]
[unique_id "VuVVo0UQ6TcBBAUwzDEAABBAb"]

Als je meldingen zoals deze ziet, dan ben je het juiste artikel aan het lezen … uiteraard wel even controleren dat de meldingen betrekking hebben op WordPress pagina’s en jouw website, dus b.v. kijken of de link uri "/wp-comments-post.php" legitiem is, en betreffende “rule id” en zo zin maken.

Uitschakelen van mod_security regels voor WordPress

Een optie is natuurlijk om een regel gewoon uit te zetten. Maar daarmee stel je jouw web-server onnodig blood aan risico’s en dat is dus niet zo’n goed idee.

Het is een beter idee om de regel alleen voor bepaalde pagina’s uit te zetten.

Daarnaast heeft WordPress ook functies ingebouwd die posts en opmerking “schoonmaken” (sanitize) zodat kwaadaardige meldingen weinig kans hebben om schade aan te richten door dus alleen maak gecontroleerde en schoongemaakte tekst in de database te zetten.

Nu we dit allemaal weten kunne we voor specifieke links in onze WordPress setup “whitelisten“.
Ik wil nogmaals benadrukken dat we dit zo min mogelijk willen doen natuurlijk – hoe minder uitzonderingen, hoe veilig voor onze web-server.

Gedeelde of Virtuele Web-Servers 

Het kan zijn dat jouw website op een server staat die gedeeld wordt met andere websites. De zogenaamde virtuele webservers.
In een dergelijke situatie kun je vaak niets aan de configuratie veranderen omdat het de andere websites op diezelfde server kan beïnvloeden.

In zo’n geval zul je contact moeten opnemen met jouw web-host provider.

Root access nodig! 

Om de mod_security config bestanden (whitelist in dit geval) te kunnen bewereken, zul je over het algemeen ROOT ACCESS NODIG hebben.

De zogenaamde whitelist heet whitelist.conf of exclude.conf wat afhankelijk is van jouw server configuratie.

Op mijn server (CentOS) staat het hier: /usr/local/apache/conf/modsec2/whitelist.conf

Voor we een whitelist gaan maken, zullen we echter eerst moeten kijken welke regels dus een false-positive veroorzaken. In mijn configuratie zag ik dat de volgende regels het meest voorkomen: 300013, 300015, 300016 and 300017. Hierbij is 300013 de meest voorkomende!

Uiteraard hangt dit allemaal sterk af van de soort website die je hebt en wat voor berichten daar geplaatst worden.

De whitelist.conf (of exclude.conf) kan met een gewone tekst-editor zoals “vi” of “nano” bewerkt worden:


cd /usr/local/apache/conf/modsec2/
nano whitelist.conf

Het kan zijn dat dit bestand al uitzonderingen bevat – laat deze dus gewoon staan en verander deze niet tenzij je weet waar je mee bezig bent,

Uiteraard is het goed om dubbele uitzonderingen te voorkomen.

Een voorbeeld van regels die ik gebruikt heb:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<locationmatch "/wp-comments-post.php">
  SecRuleRemoveById 300013
  SecRuleRemoveById 300015
  SecRuleRemoveById 300016
  SecRuleRemoveById 300017
</locationmatch>
<locationmatch "/wp-admin/post.php">
  SecRuleRemoveById 300013
  SecRuleRemoveById 300015
  SecRuleRemoveById 300016
  SecRuleRemoveById 300017
</locationmatch>
<locationmatch "/bb-post.php">
  SecRuleRemoveById 300013
  SecRuleRemoveById 300015
  SecRuleRemoveById 300016
  SecRuleRemoveById 300017
</locationmatch>

Dit minimaliseert problemen bij het maken van opmerkingen, posts en posts in een bbPress forum.

Heb je geen bbPress in gebruik, dan kun je al uit de voeten met:


1
2
3
4
5
6
7
8
9
10
11
12
<locationmatch "/wp-comments-post.php">
  SecRuleRemoveById 300013
  SecRuleRemoveById 300015
  SecRuleRemoveById 300016
  SecRuleRemoveById 300017
</locationmatch>
<locationmatch "/wp-admin/post.php">
  SecRuleRemoveById 300013
  SecRuleRemoveById 300015
  SecRuleRemoveById 300016
  SecRuleRemoveById 300017
</locationmatch>

In bepaalde configuraties heb ik ook de volgende uitzondering gezien, maar voeg deze alleen toe als betreffende regel bij jouw configuratie problemen veroorzaakt:


1
2
3
<LocationMatch "/wp-admin/edit-comments.php">
  SecRuleRemoveById 2000149
</LocationMatch>

De volgorde in de lijst maakt niet zoveel uit (voor zover ik weet).

Uitschakelen van mod_security regels voor bbPress

Nu heb ik gemerkt dat bbPress soms zijn eigenaardigheden heeft en dat de eerder gedefinieerde regels niet altijd helpen omdat de URL niet consistent is (verandert per forum en forum-topic).
In dat geval moeten we met regular expression aan de slag.

Een voorbeeld van de error log:


1
2
3
4
5
6
7
[Mon Apr 12 17:34:09.310851 2016] [:error] [pid 13207] [client 134.171.197.17]
ModSecurity: Access denied with code 500 (phase 2).
Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+
from|bulk[[:space:]]+insert|union.+select|convert.+\\\\(.*from)" at ARGS:bbp_topic_content.
[file "/usr/local/apache/conf/modsec2.user.conf"] [line "247"] [id "300016"] [rev "2"]
[msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname "www.example.com"]
[uri "/forum/development/sql/"] [unique_id "VxVNbUUQ6TcAADOXFTsAAAAB"]

Het probleem is dat de URL alle voor dit forum onderwerp dit is: /forum/development/sql/
Maar anderen zouden kunnen zijn: /forum/development/delphi/ of /forum/development/lazarus/

Moeten we nu voor elk een rule maken? Gelukkig niet.
We kunnen dit oplossen met een (soort van) regular expression.

Stel we willen bepaalde regels uitzetten voor alle URLs die met “/forum/development/” beginnen:


1
2
3
4
5
6
<locationmatch "^/forum/development/.*">
  SecRuleRemoveById 300013
  SecRuleRemoveById 300015
  SecRuleRemoveById 300016
  SecRuleRemoveById 300017
</locationmatch>

Herstarten van Apache

Als je de wijzigingen opgeslagen hebt (in nano: CTRL+X, Y, en druk dan op ENTER), zullen we Apache opnieuw moeten starten zodat het met de nieuwe regeltjes aan de slag gaat.

Herstarten van Apache kan op meerdere manieren gedaan worden, ik gebruik meest cPanel’s WHM (Web Host Manager).
Als alternatief kan het ook via de shell of SSH, maar dan heb je wel root toegang nodig.

Hier 4 varianten, er zijn er vast nog meer.


1
2
3
4
sudo /etc/init.d/apache2 restart
sudo service apache2 restart
sudo restart apache2
sudo apache2ctl restart

Alternatieve Whitelists voor WordPress

Uiteraard heb ik het Internet flink lopen afzoeken voor ik hier aan begon.
Een goed artikel is bijvoorbeeld dit artikel van WPSecure, welke wat dieper op het e.e.a. in gaat …
Omdat ze toch handig kunnen zijn, zeker als je een beetje in de gaten gaat hebben hoe de uitzonderingen in elkaar steken, heb ik hieronder nog 2 voorbeelden geplaatst.

Nogmaals; plaats niet te veel uitzonderingen in de whitelist – hoe minder hoe beter voor de veiligheid van jouw web-server. Let vooral op de regel met “LocationMatch” zodat je weet waar ze bij horen.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<LocationMatch "/wp-admin/post.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904
</LocationMatch>

<LocationMatch "/wp-admin/admin-ajax.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904
</LocationMatch>

<LocationMatch "/wp-admin/page.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904
</LocationMatch>

<LocationMatch "/wp-admin/options.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904
</LocationMatch>

<LocationMatch "/wp-admin/theme-editor.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904
</LocationMatch>

<LocationMatch "/wp-includes/">
  SecRuleRemoveById 960010 960012 950006
</LocationMatch>

 

De volgende is behoorlijk uitgebreid, en voor de meesten onder ons veel te uitgebreid (bron) :


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
<LocationMatch "/wp-admin/post.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-admin/admin-ajax.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-admin/page.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-admin/options.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-admin/theme-editor.php">
  SecRuleRemoveById 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-content/plugins/">
  SecRuleRemoveById 300015 340151 1234234 340153 1234234 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-includes/">
  SecRuleRemoveById 960010 960012 950006 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-content/themes/">
  SecRuleRemoveById 340151 340153 1234234 950006 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-content/plugins/sociable/">
  SecRuleRemoveById 960010 960012 950006 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-content/plugins/wp-recaptcha/">
  SecRuleRemoveById 340151 340153 1234234 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch "/wp-content/plugins/fancybox-for-wordpress/">
  SecRuleRemoveById 960010 960012 950006 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

<LocationMatch “/wp-includes/js/tinymce/plugins/spellchecker/rpc.php”>
  SecRuleRemoveById 960010
  SecRuleRemoveById 960012
  SecRuleRemoveById 959006
</LocationMatch>

<LocationMatch "/wp-content/themes/YOURTHEMEFOLDER/thumb.php">
  SecRuleRemoveById 340151 340153 1234234 300015 300016 300017 950907 950005 950006 960008 960011 960904 959006
  SecRuleRemoveById phpids-17
  SecRuleRemoveById phpids-20
  SecRuleRemoveById phpids-21
  SecRuleRemoveById phpids-30
  SecRuleRemoveById phpids-61
</LocationMatch>

Ondersteun ons ...


Jouw ondersteuning wordt zeer gewaardeerd, en hoeft zelfs niets te kosten. Bijvoorbeeld door links naar ons te delen op social media, of andere websites.

Andere vormen kunnen ook gratis zijn (b.v. shoppen op Amazon).
Alle opbrengsten worden gebruikt voor web-hosting kosten, project hardware en software, koffie, etc.

Hartelijk dank voor wie al heeft bijgedragen!
Het is altijd geweldig om te zien hoe men mijn artikeltjes en applicaties weet te waarderen.

Merk op dat het klikken op affiliate links een kleine commissie voor ons kunnen genereren - dit wordt zeer gewaardeerd.

Reacties


Er zijn nog geen reacties geplaatst.
Je kunt jouw eigen opmerkingen plaatsen m.b.v. dit formulier, of een reactie op een bestaande opmerking plaatsen door op de "Beantwoorden" knop te klikken.



Jouw Opmerking ...

Plaats hier geen grote bestanden (zoals source codes, log files of config files). Gebruik hiervoor het Forum.

Delen:
*
*
Laat me per email weten als er nieuwe reacties zijn.
       Je kunt jouw RSS reader gebruiken om reacties te volgen.


Tweaking4All gebruikt de gratis Gravatar dienst voor Avatar weergave.