Chapter 1
[ 37 ]
Check your physical security—you/your employees: How
much "information" do you leak? The author uses the term
"coffee-house" rules to describe a method of communicating
in public. What this means is that with the plethora of
wireless hot-spots in coffee shops and other areas, an intruder
can (and it has happened) set up a "fake" hot-spot for free.
Your machine connects, and he or she is the "man-in-the-
middle" now. He or she forwards your requests on, all the
while collecting vital information. But what about the human
element? Another famous technique that works quite well
for gaining passwords is "shoulder-surng". This is where
someone watches over your shoulder to steal some, or all
of your passwords. Establishing a good program for your
staff would be one of security awareness and education. The
metric could be attendance, testing, and so forth. One other
item to be somewhat aware of is the physical key loggers that
can be attached to a keyboard. They appear innocuous but are
deadly. If there is any possibility of outsiders being in your
facility, it's a great idea to establish a program to check your
equipment for tampering.
Wireless security: Have you tested it? Can anyone get
on? There are several attack tools meant to break WEP
encryption. So again, establishing a good password schema,
and a plan to update and change it on a regular basis is vital.
If by some weird chance you are running default settings on
your wireless equipment, put this book down right now and
go set up your security.
Rouge devices: Has someone added a wireless device that
you don't know about in your facility? It has been known to

it make sense? Are you giving the readers enough information to support you? In
essence, if you feel you have been, or you know you have been hacked, here are a
few rules for the forum that will prevent the dreaded aming nonsense:
DO NOT publish the code that was used to attack you. This WILL result in
censorship and for a good reason. You don't want to reveal that information
for a lot of reasons.
DO your research before posting. Start with checking and searching for
keywords, looking in the forums and reading a few postings, and so on. You
might be surprised by what you nd.
DO NOT use offensive language, even if you are called a name.
DO REPORT FACTS so others can help you. Often, you will see a desperate
poster who puts up a post that says, "Help I've been hacked", and then
they begin to bemoan their misery to you. This is not helpful. How was it
attacked? What occurred? Why are you posting it? Do you need help? If so,
ask! State how you were hacked (for instance a defacement), and then move
on to getting the assistance you need. But do so by formulating a question
before hitting send.
•
•
•
•
•
•
•
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Chapter 1
[ 39 ]
There are several other good-citizen type things, but these will specically help you
in the middle of a crisis.

extension has been released, but not thoroughly tested, or when you want to add
a new feature to your site. Making these changes on a production system could be
devastating. If you made a mistake, or the extension caused a conict, an outage
could occur.
With a test environment, you will have a fully functional "copy" of your site, enabling
you to test and develop safely. To accomplish this, we will cover the following topics
to give you a professional method to have a secure and truly great site:
Test and development environment
What does it have to do with security?
The evil hamster wheel of upgrades
Developing your test plan
Using your test/dev system for disaster recovery
Crafting good documentation
Using a Software Development Management system
Using the Ravenswood Joomla! Server
Roll-out
•
•
•
•
•
•
•
•
•
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Test and Development
[ 42 ]
Welcome to the Laboratory!

extension. As a developer, you have the obligation to think about how your tools will
be used in a common setup, and how they will react with other extensions. As a user
or administrator, testing will help to uncover many such issues.
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Chapter 2
[ 43 ]
What Does This Have to Do with Security?
So…what do you say? I'll pick another tool or write my own if I can't get the
extension developer to write a good tool. Good for you! That's a perfect thing, and
not out of the scope of reality. In fact, it's right in line with Joomla!. However, I
would postulate you would have the same problems. How will you assure security
unless you go through rigorous regression testing, where you set up hundreds of
combinations of extensions, versions of Joomla! and hosting combinations to make
sure it's safe? You won't. Therefore, you still need a cursory run at it to make sure it
works for you. Another scenario is, let's say, you nd a replacement extension that
does exactly what you want; it's perfect, easy to install, and looks wonderful. The
documentation is adequate and useable. "Yes. This is the tool for me.", you think
and you deploy it without testing. It doesn't work, and you nd out it requires
Register_Globals be set to 'on'. You discover, after you have been attacked by
a kiddie-script, that they took advantage of the register global setting. What if it
requires permissions to be set for 777, or worse (and likely) they did not sanitize the
input and someone hit you with an SQL injection? This is WHY you need a test and
development environment to test for security.
Another not too uncommon scenario is of the host that has restricted php.ini and
you cannot make changes. You would catch this in your test environment. By clear
documentation on your test site, and following those steps on your production
environment, you would see that it cannot be changed. You can begin to see that a
sandbox environment has everything to do with security. It should be an integral
part of your business and your website development plan.

This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604
Chapter 2
[ 45 ]
The hamster wheel of upgrades means our ingrained need to add any new feature,
patch, and update that the developers deem necessary or t. Often they are correct.
If they tell you an "xyz" extension has been demonstrated to have these errors, then
don't hesitate to update, but only after testing it in your sandbox. Changing your
patch and upgrading philosophy to be of a more secure mindset is the direction you
should take.
Determine the Need for Upgrade
As we spoke about the need for a good baseline in our previous chapter, we want
that to have a starting point in time. We cannot reach our destination unless we
know: "Where do we want to go? Where is it? And where are we?" Let's say, for the
sake of conversation, that you need the new SuperMosWhizBang extension from
your favorite developer. This new extension sports eight hundred new features
that you must have! If we approach this with a sober mind and consider a few data
points, we might determine that this would not only open us up for risk, but might
be a waste of time and money. Or it might be easily proved that the extensions are
needed, and we can begin the testing and deployment. The next step is taking the
following into consideration:
1. Which of these new features are in line with my business goals?
2. How will these features help me reach my goals?
3. What is the cost, in dollars, to obtain this extension?
4. How many man-hours will be required to implement this extension safely?
5. Are well-written instructions available?
6. Is the developer available to support me in a problem scenario?
7. Has the developer tested for SQL injection attacks?
8. Will my end users need to be re-trained after the upgrade?
9. What would be my cost of downtime, should this new feature break my site?

defined( '_VALID_MOS' ) or die
( 'Direct Access to this location is not allowed.' );
This code is a gatekeeper for your site. This ensures that visitors cannot browse (or
access) this le "directly". Rather, they must go through Joomla! to gain access. This
is a very important section of code that is sometimes forgotten, thus exposing the
system to threats.
Now you will need to modify and test your site. If the developer has not released a
patched version, or an upgrade means, then you will have to add this code yourself.
This material is copyright and is licensed for the sole use by Thomas Rosenblum on 4th December 2008
1010 SW High Ave., , Topeka, , 66604