Eddy,
I'm the one that "fixed" it...
A wildcard DNS entry was added (God I hate web admin tools) that was pointing to a different IP than what the actual host for the site is. The phishing/malware links were the only issue reported at the time.
And for your list ...
Blacklisted
Eh? It's not listed under SURBL as blocked on that link.
Suspicion of Spam
What's wrong with the CSS file? I'll need to look at it again to verify, but there's no code that will be executed in that file... especially with a type of 'text/css'. So, that's spam? I know the code from joomla is crap, but calling it spam is a bit much...
Problems on that ASN
Umm... again, I see nothing under these that jumps out and yells "problem". Am I missing something?
Outdated software
*sigh* Yeah... I've back ported some updates, but it's not feasible to do a full update without rewriting custom code ... and I just don't have the time to do that, and I didn't write it originally. So... This version it stays with the patchwork that can be done. :/
DNS problems
A singe NS listed in the SOA is a DNS problem?? Yeah, for the site, but not anyone else. For the SOA warning ... well, no kidding the reverse isn't found. We don't control it.
$ dig -t SOA dokuga.com | grep -A1 'ANSWER' | grep ^dok
dokuga.com. 86376 IN SOA ns1.dokuga.com. dokugasitemail.gmail.com. 2015040801 10800 3600 604800 10800
Notice something that is different from the others in that? Here...
$ whois 74.125.204.26 | grep ^OrgName
OrgName: Google Inc.
That DNS check is making assumptions, and if it falls outside of those assumptions then it's "bad".
HUGE(!) security problems
Yeah, I'd like to get an actual SSL cert. But the way the vhost'ing is currently configured it'd be a pain... *sigh*.
The current SSL cert is self signed, and only really works with the web administration... The http roots for SSL and non-ssl are different.
Pointing to blacklisted site
Huh... tinypic got blacklisted eh? *shrug* Not surprising. Sites that allow user content get blacklist constantly.
Google: 44546 bytes Firefox: 44597 bytes
Diff: 51 bytes
Now... huh? What exactly are you talking about difference? If you're talking about what's sent.... yeah, good luck. What the server sees for avail compression, if the browser detection code works right, etc... you're going to get differences. Comparing what two different browser receive is comparing two (IE should add in a 3rd!) different beasts *unless* you're just looking at the rendering. And, the data received from the site can change from minute to minute since it does allow user postings and they do go to the front page.
Edit: Chrome and Firefox should be pretty close on the size IIRC. I think there may have been one specific webkit check that changed a function slightly.
Edit 2: Oh yeah. There's also a "Random Artwork" section that changes on every request, so the links to those thumbnails will change every time as well.
And a phishing link was added.
No... that was the original problem. If you look at the URL it's in the form of: blah.blah1.blah2.domain.com .... This is from the wildcard DNS entry that was added (i.e. *.domain.com).
If their hosting says everything is fine, they are lying.
A hosting company that is using outdated server software and Joomla can't be trusted when it comes to security and detection of malware.
I am the one that says it's "fine". I am the one that fixed the DNS wildcard issue. It's as fine as it can be anyway. There are issues I know of, but without a complete rewrite (and more time on my side to actually do that re-write), it isn't being updated as much as would be nice. So, patchwork security it is. *sigh* :/
-J
