Unable to load the 'main' template.

[Kindred]

egads....

no no no no no no no no no no no and a million time no.

that is so wrong in so many ways....

Any code which needs to be included like that should be dropped into index.php at the very least....   but more likely, it should be dropped into index.template.php instead.

what is zblock supposed to do anyway?

[tricities]

Well, it blacklists what it thinks are attacks or something and stops attacks.  I've been blacklisted several times from my playing with files and seeming like an attacker who shouldn't be doing the things they're doing - and it works wonderfully and I just white list myself when I'm blocked.  It's very widely known.  It's so over and above Akismet or whatever that wordpress spam blocker is.  There must be a reason why they targeted the Settings.php file and not the index and it must be because it's where the database password is located.  I'll ask them, but for now I'll leave it as they suggest since for 10 or so years it's been working on both domains. (until now but remember Fred didn't do updates on either the PMB or websites for all those years either - so even though a Trojan I do not blame any programming other than Fred, himself - the old webmaster)

[Kindred]

The only reason I can think that they said to use settings ie because they want it loaded on every page of the forum and they have no clue how the SMF setup actually works.


As I said, it is BAD BAD BAD process to do what they did...

and even if inserting into settings was the right thing to do, they did it poorly.
the process of adding a full additional <?php ... ?> before the real opening <?php is just bad...   and is actually one of the first indicators you should normally check to see if you have been hacked.


(I have not had any issues with spam in 2 years on my site, using bad behavior + httpBL and good questions)

[tricities]

That makes sense.

What does this mean? httpBL and good questions

[Kindred]

bad behavior + httpBL is a mod...
http://custom.simplemachines.org/mods/index.php?mod=2502
(httpBL links to the project honeypot database)

good questions...
questions are a standard feature in SMF 2.x which are 10000x better than captcha in preventing spam bots.

[Arantor]

As for ZB Block (which is what you're using, and is a different product to ZBlock), I actually wouldn't recommend it personally.

Its mentality is... interesting... and the way it is written is actually quite inefficient. The benchmark figures the author gives for performance are only valid when run in isolation but no production forum is ever run in such isolation.

And yes, it should be placed in index.php not Settings.php.

[tricities]

http://www.spambotsecurity.com/forum/viewtopic.php?f=41&t=499

They answered over there.
I don't understand most of it.

What are your opinions on why and how our forum got infected?  Is there a way to tell how a Trojan got in?

[Kindred]

well....   what they are saying has nothing at all to do with how your forum got infected.

I would assume - if you were running an outdated version of SMF (or any other software) that some hacker took advantage of a known security issue that remained because you did not update with the security patches.

As for what they said...  they are both right and wrong.

right - I was a little vehement. perhaps overly so... and using the double headers is not technically wrong.   It is, however, messy.  It makes sense to do things like that in scripts that use the open/close/open/close style of coding (like Joomla or WordPress, for instance). It is contrary to SMF style coding, however -- and as I said (and they admitted) -- it is one of the first things to check to see if code has been injected through a hack.   Having extraneous code like that just means that it is one more thing that you have to remember "is OK" when doing a quick scan.

wrong - despite their arguments, the code should not be placed in Settings.php.  It should be placed, as I suggested and Arantor confirmed, in index.php (which actually, is loaded before Settings.php anyway)   Although it obviously does work, doing it in Settings.php is wrong, from several coding viewpoints.   If the ZB Block code is supposed to pre-parse the request, then the main index.php file is the proper location - since **ALL** requests to the server location process THROUGH index.php if your site is properly configured.

[tricities]

I know I'm ignorant but if one does a Google search, one can land on an inner page, so why can't a Trojan look for the best target of Settings.php, the file which contains the database login details, and smartly bypass the index file? (no, I'm not saying they use Google! LOL)

On our main website, the old webmaster installed the coding on every page not just the config.php page, so I guess it doesn't hurt to install it on both pages, unless you feel it damages the Settings.php in some way to have it there.

[Kindred]

no. You can not install it on both pages.   It should only be run once. In index.php

And no...  you can not "get to any inner page" on the website.
If you access ANY default part of SMF directly, it either bounces you to the index or it displays a message - "hacking attempt"

try it...   try going to your site/Sources/Subs.php file directly...

[tricities]

Cool.  But enlighten me.  I wouldn't think that Trojans would use browsers to directly get to a page.  Can't they just worm their way into Settings through cyberspace much like when someone sends emails and they're snatched up in cyberspace and info stolen and that's why it's not safe to send passwords or credit card info through email?

[Arantor]

Uhhhhh... no. It doesn't work like that.

[tricities]

Okay.  But I think I have an uh-oh.  I got the hacking attempt on the file you said to go to but not on my Setting.php file.  I could see the page and view the source code (if there were actual html in it, but you know what I mean)

http://ucfm2.com/pmb/Settings.php

[Arantor]

That's not an uh-oh. That's how it's supposed to be.

But you'll notice... the link doesn't give you any content. Not even if you 'view source' in your browser...

[tricities]

Yes, but no PHP page will show any content unless html is included in that page.  This is not something that SMF does but what PHP normally does. 

On my server:
Subs permission is 666
Settings permission is 644

Totally confused on permissions but I have a forum post here that says to set everything to 755 folders and 644 files.  I haven't done so yet but just made Settings.php to 666 but it gives write permissions to groups and public and it still didn't show the hacking attempt.  I set it back to 644.  But on your instruction manual or a page of support about permissions it says to use 777 and 666 if we could but some hosts won't allow such high settings (or words similar to that).  But the 666 gives write permissions.  Not sure what a write permission is other than someone being able to write to it which to me is dangerous.  Maybe ZB Block knows the Settings.php with SMF isn't protected like the rest of them and one would normally access index.php directly?  It makes more sense on what they're suggesting than what you're saying but you had a hand in developing this forum, so I look to you firstly, but am totally confused.

[Arantor]

That's not actually accurate.

I haven't done so yet but just made Settings.php to 666 but it gives write permissions to groups and public and it still didn't show the hacking attempt.

It won't. It isn't supposed to for Settings.php. I already pointed this out. I am a former member of the development team, and I have Zend certification in PHP. I am well aware of how PHP operates, and specifically how SMF operates. It is operating correctly under the conditions described. And it will not just output if HTML is included in the page (especially if you start doing things like writing command line scripts or even desktop graphical user interface apps in PHP)

Changing permissions on Settings.php will not give you that message. 644 or 444 is recommended, but you may require 664 or even 666 for certain settings to be set from inside SMF (where it has to update Settings.php), e.g. forum title, maintenance mode, webmaster email address.

Maybe ZB Block knows the Settings.php with SMF isn't protected like the rest of them and one would normally access index.php directly?

Or ZB Block took the quickest route rather than the correct route.

Putting ZB Block into Settings.php does not magically protect it against anything that it wouldn't be protected against anyway. There is no logic in Settings.php that can be exploited, no forms or content handling that can be abused. In short: no benefit to it actually being there.

The correct place to put it is in index.php.

However, I would also note that I have reviewed the code of ZB Block and find it very inefficient and could not recommend it anyway.

[tricities]

Oh, I didn't mean it would output the php if html is included.  But just shows the html.

So how come Settings.php doesn't give the same hacker attempt warning as Subs.php does?

[Arantor]

Because it doesn't check, for technical/historical reasons dating back years.

All the other files check that SMF has already been started, but since Settings.php is sometimes used outside of SMF, it cannot safely test if SMF has been started without breaking some of the bridges to other software (e.g. the old Joomla bridge)

[tricities]

Okay, so it doesn't check for hackers but a hacker cannot get to php coding that's not protected because they first have to go through the index file to get to it and it is protected.  Does that sum it up in layman's terms?

[Arantor]

Not really.

Hackers can't get to your site's PHP coding unless there's a fault in the server that lets them in (e.g. weak password, improper security/permissions that allows someone in from outside your account while on the same server), or a fault in the code that allows them to smuggle some PHP in that they can run.