Anyone experiencing various missing assets (mainly images)?

[Pate]

Hello,

First of all I must say I'm very impressed how CB2 is moving along and hope DA will continue to improve like this. It makes me glad I chose DA those many years ago.

However I got this weird problem with the server I upgraded to CB2.0. Running NGiNX with PHP5.6 by PHP-FPM. Versions: (DA 1.49.1, PHP 5.6. Nginx 1.8, Debian 7 (64-bit))

On some sites configured on the server (mostly wordpress) I get various missing assets (mainly images as thats easiest to notice, but seen for CSS/JS as well) on some loads and on some reloads I even get assets showing up on different places on the page (like it would be some kind of cache configured incorrectly).

Example of two scenarios:
1. First page loads fine. Second page the resource logo.png won't show up on the page, but in Network in Google Chrome tools it still shows up with a response code 200 (but with a loading time over 2 seconds and also no data sent).

2. First page loads fine. Second page the content of the logo.png might show up instead of a resource called facebook.png further down the page.

I understand this is a vague error report, but mainly just asking for ideas of what things I could try. What makes it harder is that it's all randomly and cannot be fully replicated. As it's static assets I doubt it has anything to do with the scripting (i.e. PHP and WordPress).

I run another DA server with CB1 (Apache) and have never seen anything like this before.

Anyone got ideas what to try? I tried disabling the firewall (CSF) to see if it was some kind of setting where IP was temporary blocked or something. Gladly accept any ideas or just any random thoughts that might pop up in your head that might lead me to find the problem.

 

[smtalk]

Are you running standalone Nginx or in combination with Apache as a reverse proxy?

 

[Pate]

I'm using Nginx directly (standalone, without reverse proxy).

 

[smtalk]

Is ngx_pagespeed used? Or any page caching modules?

 

[Pate]

No, ngx_pagespeed is not used as far as I know and neither is any other caching modules.

Output from nginx -V:

nginx version: nginx/1.8.0
built by gcc 4.7.2 (Debian 4.7.2-5)
built with OpenSSL 1.0.1e 11 Feb 2013
TLS SNI support enabled
configure arguments: --add-module=../modsecurity_nginx-2.9.0/nginx/modsecurity --user=nginx --group=nginx --prefix=/usr --sbin-path=/usr/sbin --conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid --http-log-path=/var/log/nginx/access_log --error-log-path=/var/log/nginx/error_log --with-ipv6 --without-mail_imap_module --without-mail_smtp_module --with-http_ssl_module --with-http_realip_module --with-http_stub_status_module --with-http_gzip_static_module --with-http_dav_module --with-cc-opt=''-D FD_SETSIZE=32768''

Any ideas/recommendations to what I could try?

 

[smtalk]

I think it must be ModSecurity related. Try disabling it and let us know if it solves the problem.

 

[Pate]

Just disabled ModSecurity and rebuilt Nginx. Seems to have solved to problem.

As of now I'm just glad it seems to work, but still curious what about ModSecurity could have caused these issues. You have any ideas?

Anyway - thanks for your help Martynas!

 

[smtalk]

Even though ModSecurity marks it's release as stable, 2.9.0 isn't stable enough for Nginx... Quote from ModSecurity developer zimmerle:

We are currently working in a new version of ModSecurity for nginx. It is something that we are targeting for ModSecurity version 3. The version 3 will no longer depend on Apache and/or APR, it will be an independent library that may be consumed by the "nginx connector", this connector is a replacement for the current nginx addon.

• ModSecurity version 3 information:
  https://github.com/SpiderLabs/ModSecurity/tree/libmodsecurity
• nginx connector information:
  https://github.com/SpiderLabs/ModSecurity-nginx/tree/experimental/

 

[Omines]

I have experienced similar issues with mod_security on Apache in the past. The mod_security authors actually explicitly advise to run the module in "dry mode" for a while before fully activating it, to ensure no harmful false positives are triggered, or at least discovered in logs first. In my opinion this only makes it practically usable for (semi) dedicated servers, not for hosting servers where the sysadmin does not know which applications will be run.

Having said that I do fully agree that Wordpress should be preventively blocked by every security system in the world as it's a fundamentally flawed insecure PoS, but that's kinda offtopic.