I’ve already covered the XOOPS
dynamic Web site development tool from a couple of angles; before you are too
deeply embedded into the system, I’d like to cover a few tips, tricks, and
hacks to help your server perform faster and safer. Grab your keyboard and get
ready to hack around.
Optimizing for search engines
Before we get into any file hacking, I wanted to give a little search engine
advice. Most Webmasters don’t fret much over optimizing their sites for search
engines. This is a shame, since many of these sites are selling a product or a
service. Without a little tweaking for search engines, how will people find
your site? Without knowing the site’s exact name or URL, they won’t. So use the
following guidelines to aid in your search for better search engine
the W3C recommendations and standards when writing code or hacking XOOPS
modules and files: every tag that opens must close.
your content, layout, and scripting.
your ALT tags: remember, search engines cannot read images, so the use of
the ALT attribute to describe the purpose of each image will help search
engines to read those images. Use ALT attributes that convey meaning to
your visitors, rather than only your colleagues. (Don’t forget to close
your IMG tag.)
engines cannot look into SWF files, so use Flash like an image. Using
Flash for navigation is a waste of good search engine readable links.
the correct DOCTYPE.
your META tags: set the content-language, content-type, keywords,
description, and robots. Choose balanced and unique keywords and
descriptions that suit your site and your products, but don’t be so
specific that you eliminate related industries. Don’t forget to set a long
and descriptive title for your site. Check out the referrers in your
server access logs to discover the search strings used to find your site.
a robots.txt file in the root of your site. Take a look at robotstxt.org for more information.
your code using the W3C-validator.
sure your Web server is sending out correct and optimized headers.
plenty of interesting content on your site. Update frequently.
your site listed on the most popular search engines like Yahoo, Google, HotBot, Lycos, or MetaCrawler.
Do not rely on programs for submitting your site to 4,000 search engines
at a time. Make sure your site is working correctly before submitting.
search engine optimization does not happen overnight. It can take several
weeks or months before search engines start to crawl your site.
link exchanges with other popular sites.
use relative URLs. Write a wrapper to output absolute URLs.
link your own banners and mastheads back to your site.
a site map with a link for every page on your site using descriptive link
I’ve spent many hours optimizing sites for search engines. The results are
worth all of the hard work.
During the installation process, you are asked to use a table prefix for
your database. Avoid using the default: when using a XOOPS site and a XOOPS
prefix, it is too easy for crackers to guess.
If you have installed your site with XOOPS default table prefix, you can use
GIJOE’sXoops protector module. This module offers a
number of security features otherwise not available in the XOOPS tool. Let’s
take a look.
The Protector Module
Installation of the module is the same as any XOOPS module. Move the .tar
(or .zip) file into the XOOPS modules directory, unpackage
the file, go to the System Admin button (once logged in as the site
administrator), click on Modules, and click on the install button for the
Now that the module is installed, click on the module button (from within
the System Admin area), and you’ll first see the Protect Center. The primary
purpose of the Protect Center is to enable you to ban certain IP addresses. To
ban an IP just enter the IP address in the text area, click the Enable IP Bans
checkbox and click GO! The IP has been banned, just like that.
The Protector Module also has an outstanding feature called the Security
Advisory. This feature checks your XOOPS installation for weaknesses. From a
basic install, the Protector Module gave me the following warnings:
'register_globals' : on Not secure
This setting invites a variety of
If you can put .htaccess,
edit or create...
on Not secure
setting allows attackers to execute arbitrary scripts on remote servers.
can change this option.
If you are an admin, edit php.ini or
Sample of httpd.conf:
it to your administrators.
setting invites 'SQL Injections'.
forget turning 'Force sanitizing *' on in this module's preferences.
missing precheckNot secure
should edit your mainfile.php like written in README.
'Password for rescue': Unset
Outside of the poorly written English, this module offers us some keen
insight into our installation.
The last listing tells us to set a password for rescue. If you peek into the
last tab of the module (also the meat of the module – called Preferences),
you’ll notice the very last entry is the rescue password. The rescue password
enables you to get back into your site should the administrator IP address
accidentally get banned.
Along with the rescue password, the preferences tab allows you to configure
- Temporary disabled: All protections are
disabled in temporary. Don’t forget turn this off after trouble shooting.
- Reliable IPS: Set IPs
you can trust. Separated IPs with |
. The ^ character matches the head of string, and the $ character
matches the tail of string.
- Logging level: None, quiet, full
- Protected IP bits for the session: Anti
Session Hi-Jacking: Default 32 bit (All bits are protected). When your IP
is not stable, set the IP range by number of the bits. If your IP can move in
the range of 192.168.0.0-192.168.0.255, set the bits to 24.
- Groups disallowed IP moving in a session: Anti Session Hi-Jacking: Select groups which are disallowed to move their
IP in a session. I recommend turning Administrator on.
- Sanitizing null-bytes: The
terminating character “\0” is often used in malicious attacks. A null-byte will be changed to a space. Highly recommended set to on.
- Exit if bad files are uploaded: If
someone tries to upload files which have bad extensions like .php, this module exits your XOOPS site. If you often attach
PHP files into B-Wiki or PukiWikiMod,
turn this off.
- Action if a contamination is found:
Select the action when someone tries to contaminate system global variables
into your XOOPS. The recommended option is blank screen.
- Action if an isolated comment-in is found:
Anti SQL Injection: Select the action when an isolated “/*” is
found. “Sanitizing” means adding another “*/” in tail. It
is recommended to set this option to Sanitizing.
- Action if a UNION is found: Anti SQL
Injection: Select the action when some syntax like
UNION of SQL. “Sanitizing” means changing “union” to “uni-on”. It is recommended to set this option to
- Force intval to
variables like id: All requests named “*id” will be treated
as integer. This option protects you from some kind of XSS and SQL Injections.
Though it is recommended to turn this option on, it can cause problems with
- Protection from Directroy
Traversals: It eliminates “..” from all
requests looks like Directory Traversals.
- Anti Brute Force: Set count you allow
guest try to login within 10 minutes. If someone fails to login more than this
number, her/his IP will be banned.
- Modules out of DoS/Crawler
checker: Set the dirnames of the modules
separated with |. This option will be useful with the chatting module.
- Watch time for high loadings (sec): This
value specifies the watch time for high-frequent reloading (F5 attack) and high
- Bad counts for F5 Attack: Preventing from
DoS attacks. This value specifies the reloading
counts to be considered as a malicious attack.
- Action against F5 Attack: None, sleep,
blank screen, ban IP, or deny by .htaccess.
- Bad counts for crawlers: Prevent
high-loading crawlers. This value specifies the access counts to be considered
as a high-load crawler.
- Action against high loading crawlers:
None, sleep, blank screen, ban IP, or deny by .htaccess.
- Welcomed User-Agent: A Perl regex pattern for User-Agent. If it matches, the crawler is
never considered as a high loading crawler. An example is /(msnbot|Googlebot|Yahoo! Slurp)/i
- Groups never registered as Bad IP: A user
who belongs to the group specified here will never be banned. It is recommended
to turn Administrator on.
- Disable dangerous features in XOOPS: xmlrpc, xmlrpc+18.104.22.168 bugs, none
The XOOPS system is one of the securest systems available. However,
the core system does have its Achilles heels, all of which are addressed by the
Move Username and Password out of Mainfile.php
The XOOPS system stores the MySQL username and
password in the mainfile.php file within the XOOPS
directory tree. Because information in your mainfile.php
is worldly readable by anyone it only makes sense to get the sensitive
information out of docroot.
Assume that your webservers doc root is /var/www/html/ and your XOOPS install is in /var/www/html/xoops. Create a folder outside of your
servers root directory (we’ll create one called data in the root
directory of the server: so /data.) Create a php
file (we’ll call this file xoops.php) and insert the
= "db username"; //database username here
"db password"; //database password
= "db name"; //your database name here
NOTE: Make sure there is no white space after the ?>
because PHP is highly sensitive to this and it will cause you a world of
headaches (until you remember you left white space there.)
Now run the command chmod 644 /data/xoops.php on the file.
Now modify the XOOPS mainfile.php
file. You might want to back up the mainfile.php
first. To edit this file you’ll have to change the permissions with the
command: chmod 777 mainfile.php. Now add
the following line in top of the mainfile.php file:
You will also need to modify the following setting in mainfile.php:
// Database Username
// Your database user account on the host
// Database Password
// Password for your database user account
// Database Name
// The name of database on the host. ...
NOTE: There should be no quotes around $db_user, $db_passwd, and $db_name.
Save the file and test your site. If your website continues to function,
congratulations: your site is a bit safer. Don’t forget to change the
permissions to the mainfile.phpfile back to 444
when you’re done. The command chmod 444 mainfile.php will do the trick.
No Web site is immune to hackers, but all attempts to thwart attacks will
help ensure the reliability and longevity of your site. XOOPS helps create a
strong environment which to work from, and it only takes a few extra steps to
raise the bar on that already high-security level.