Re: phpbb, to avoid hacking
On 04/01/12 02:15, T o n g wrote:
> On the second day that we put our private forum on the web, we
> already saw crackers trying to hack into the forum, using some kind
> of automated tools.
Unfortunately this is very common - though generally those "crackers"
are just scripts running on zombied machines.
> I'm totally new to phpbb, but I guess the automated tool will try to
> attack some well known predefined urls,
Yes. Obscurity and deception are useful tools in your kit.
> for phpbbs it'd be site/phpbb/ ucp.php?mode=register, it that so?
That's one of them. There are a few sites you can use to keep up with
attach trends and exploits[*1].
Another "desirable" file is memberlist.php[*2] - it sounds like the best
practise in your situation is just to remove it.
There are a number of other attractive targets which depend upon what
extensions you have installed[*1].
> If I move our forum entry off the well known /phpbb place, into
> something the automated tools never knew, would it at least prevent
> those existing cracking tools?
IMO the six main mistakes people make with CMSs are:-
1. failing to update judiciously
2. failing to set correct permissions (including umask, .htaccess, and
user and program permissions, allowing unneeded ftp/ssh/remote mysql access)
3. reusing passwords
4. installing unnecessary extensions and plug-ins (and keeping unneeded
files eg. faq.php and install/update directories)
5. broadcasting the details of the software and versions being used
6. leaving vulnerable files and logins in default places without a
A couple of general suggestions:-
; use mod_rewrite and .htaccess to prettyfy links - it stops dumb
scripts doing this sort of thing:-
; I like to redirect requests for the default login page (which I always
relocate) to somewhere that bites.
; consider banning HTML in posts
; don't allow remote images in posts (including user icons)
; consider running a home development server - make all changes there
first - test in the secure environment and minimise you exposure time
when making changes to the production server.
; IDS is also a must - doesn't have to be tripwire, can be just cron
based awstat scrapes or similar.
; regularly checking your site while using the browseragent to emulate
Google will show some of the most common hijack indicators.
; VirusTotal is a *very* handy tool.
You can get some general advice here:-
Disclaimer: I don't have a lot to do with phpbb - though I regard it
highly. Your best info is going to be available on the phpbb forums.
[*1] For general trends:-
NOTE: if you run KDE there's a handy little tool:-
For a little lead time on 0 day exploits:-
[*2] you should also remove the member list links from overall_header.tpl
Iceweasel/Firefox extensions for finding answers to Debian questions:-