Nach 1.2 update seite lädt endlos


#1

Hallo,

habe heut unter piwik.watch-wiki.org update von 1.1.1 auf 1.2 gemacht (per auto updater) und lief aich fehlerfrei durch.

wenn ich jedoch jetzt die wiki aufrufe lädt diese ewig. bzw lädt er die piwik.js ewig. kann mir jemand helfen? Ich hab keine Ahnung wieso!


(Thomas Seifert) #2

Bei mir lädt er Deinen piwik.js in 37ms, also nicht wirklich “ewig” …


#3

Hmm bei mir lädt er die Website bis kurz vor Ende und wird dann einfach nicht fertig. Eine idee was das sein kann? Browser Cache is auch schonmal geleert worden.

Problem besteht mit Fox (latest 3.6.16) und auch Chrome. IE scheint fertig zu laden!?


#4

Wir hatten das Problem ebenfalls. Ursache war eine Block-Regel im Snort-IDS für unser Hausnetz, die bei piwik.js zugeschlagen hat:
2011:03:16-17:19:38 vpn snort[18199]: id=“2101” severity=“warn” sys=“SecureNet” sub=“ips” name=“Intrusion protection alert” action=“drop” reason=“WEB-CLIENT Mozilla regular expression heap corruption attempt” group=“320” srcip=“62.146.104.136” dstip=“192.168.8.48” proto=“6” srcport=“80” dstport=“50895” sid=“8443” class=“Attempted User Privilege Gain” priority=“1” generator=“1” msgid=“0”

Kurzfristig ist uns allerdings keine andere Möglichkeit eingefallen als die IP-Adresse unseres Piwik-Webservers für Snort zu whitelisten. Ich gehe davon aus, dass auch andere Piwik-User dieses Problem haben werden, wenn sie hinter einem IDS sitzen. Snort dürfte ja nicht gerade exotisch sein.

Viele Grüße

Markus


(Peterbo) #5

Bei mir wird der Pixel auch flott geladen. Scheint wirklich so etwas zu sein, was Markus anspricht. Danke für die Aufklärung!


#6

Hi alle zusammen.

Danke Markus für den Tipp. Tatsächlich wars das gleiche Problem mit meiner Astaro (ASG v8 latest) -->
2011:03:17-14:32:58 reticulum snort[30191]: id=“2101” severity=“warn” sys=“SecureNet” sub=“ips” name=“Intrusion protection alert” action=“drop” reason=“WEB-CLIENT Mozilla regular expression heap corruption attempt” group=“320” srcip=“88.198.111.242” dstip=“192.168.1.5” proto=“6” srcport=“80” dstport=“52997” sid=“8443” class=“Attempted User Privilege Gain” priority=“1” generator=“1” msgid=“0”

eine exception für die IP als Ziel-Host mit ausnahme des IDS hilft, sollte aber keine dauerlösung sein.

Viele Grüße

PS: Wer hilfe beim Einrichten der Exception ist, ich helf gern mit Astaro (bin da sogar ACA Zertifiziert), IPCop und anderen weiter.

Martin


(Matthieu Aubry) #7

Hi
I don’t really understand all of this, but are you saying that in 1.2 there is a new security warning for Piwik http requests?

What is triggering the issue exactly?


#8

Yes, at least that’s what Snort says. As I’m not the admin for our internal network, I cannot really say what’s exactly behind that rule “WEB-CLIENT Mozilla regular expression heap corruption attempt”, but it there’s definitely something in the JS that’s triggering a false positive for this kind of attack - that’s why the JS gets dropped from the reply to the client, so the browser shows it as loading endlessly because the reply never reaches him behind the firewall.


(Matthieu Aubry) #9

Hi guys

you seem to have experienced 2 different software protections, AVG and Snort config changes ?

Could you please, post in a new Topic in the ENglish forum,

  • the software you used,
  • the error you got,
  • how you fixed the error?

I think many users will search for this info and it will be great to have a forum post to summarize the solution :slight_smile: thanks


#10

It’s the same problem, really: Snort in Astaro (ASG v8 latest). There is no fix, just a workaround. I’ll post a new topic.


#11

with piwik 1.2.1 the problem still exists - same workaround - @Piwik Developer: PLEASE fix that! its peeving and the stats arent corrent anmore (until the workaround is made)


(Thomas Seifert) #12

The problem is a false positive in snort rules, not in piwik.


#13

Thanks for the Information! Ill report it to astaro maybe they can do something…and snort if i find a contact


(vipsoft) #14

There’s actually a bigger problem with the Snort IDS rule which I’ve already reported upstream. In the meantime, we have implemented a workaround in svn trunk, which will go out in the next Piwik release.