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

  • Follow
    the W3C recommendations and standards when writing code or hacking XOOPS
    modules and files: every tag that opens must close.
  • Separate
    your content, layout, and scripting.
  • Optimize
    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.)
  • Search
    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.
  • Use
    the correct DOCTYPE.
  • Optimize
    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.
  • Make
    a robots.txt file in the root of your site. Take a look at robotstxt.org for more information.
  • Validate
    your code using the W3C-validator.
  • Make
    sure your Web server is sending out correct and optimized headers.
  • Put
    plenty of interesting content on your site. Update frequently.
  • Get
    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.
  • Remember,
    search engine optimization does not happen overnight. It can take several
    weeks or months before search engines start to crawl your site.
  • Do
    link exchanges with other popular sites.
  • Don’t
    use relative URLs. Write a wrapper to output absolute URLs.
  • Always
    link your own banners and mastheads back to your site.
  • Create
    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.

Securing XOOPS


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
Protector Module.

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
injecting attacks.

If you can put .htaccess,
edit or create...


php_flagregister_globals off

on  Not secure

setting allows attackers to execute arbitrary scripts on remote servers.

Only administrator
can change this option.

If you are an admin, edit php.ini or

Sample of httpd.conf:
php_admin_flagallow_url_fopen  off
Else, claim
it to your administrators.

off ok


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
the following:

  • 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, 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
    other modules.
  • Protection from Directroy
    : 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
    : 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
    loading crawlers.
  • 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+ 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
    Protector Module.

    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_passwd =
    "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:

    include ("/data/xoops.php");

    You will also need to modify the following setting in mainfile.php:

    // Database Username
    // Your database user account on the hostdefine('XOOPS_DB_USER', $db_user);

    // Database Password
    // Password for your database user account
    define('XOOPS_DB_PASS', $db_passwd);

    // Database Name
    // The name of database on the host. ...define('XOOPS_DB_NAME', $db_name);

    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.

    Final thoughts

    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.