Today, personal computer systems and servers are being compromised at an alarming rate. Servers such as yours that are hacked into are often used to sell "time" by organized criminals around the world. They are selling time on desktops and servers by the minute, hour, purpose, speed available, and other attributes. The reason for their sale is to send out SPAM (unsolicited bulk email), to use as denial of service attack points, or for any other unintended purpose.
Joomla!, a very popular Content Management System (CMS), is as you may know an easy-to-deploy-and-use content management system. This ease of use has lent itself to rapid growth of both the CMS and extensions for it. You can install it on almost any host, running Linux or Windows. This highly versatile software has found itself in such lofty places as large corporate web portals, and humble places such as the simple blog.
All of these share a common thread. They exist on the Web, which is one of the most lawless places on the planet. Every day the "bad-guys" are out pacing the good guys—and for a good reason. An ordinary user, who wants a powerful and yet an easy-to-set-up website might choose Joomla!. He or she is not a specialist in security, either good security or bad security. He or she is merely a target to be taken down. While Joomla! itself is inherently safe but misconfigurations of the CMS, vulnerable components, hosts that are poorly configured, and weak passwords can all contribute to the downfall of your site.
You will need to ensure that your copy of Joomla! is original and not compromised. Once you install it, you will need to check a few key settings. And lastly, we'll establish the permission settings of various files and folders. The intent of this chapter is to get you prepared to have a good, solid setup before you go live. So let's take a detailed look at the following:
Common Terminology
Hosting—Selection and Unique Needs
Architecting for a successful Joomla! install
Downloading Joomla!
Important settings
Permissions
Common trip ups
Setting up metrics to measure security
Joomla!, a very popular Content Management System (CMS), is as you may know an easy-to-deploy-and-use content management system. This ease of use has lent itself to rapid growth of both the CMS and extensions for it. You can install it on almost any host, running Linux or Windows. This highly versatile software has found itself in such lofty places as large corporate web portals, and humble places such as the simple blog.
All of these share a common thread. They exist on the Web, which is one of the most lawless places on the planet. Every day the "bad-guys" are out pacing the good guys—and for a good reason. An ordinary user, who wants a powerful and yet an easy-to-set-up website might choose Joomla!. He or she is not a specialist in security, either good security or bad security. He or she is merely a target to be taken down. While Joomla! itself is inherently safe but misconfigurations of the CMS, vulnerable components, hosts that are poorly configured, and weak passwords can all contribute to the downfall of your site.
You will need to ensure that your copy of Joomla! is original and not compromised. Once you install it, you will need to check a few key settings. And lastly, we'll establish the permission settings of various files and folders. The intent of this chapter is to get you prepared to have a good, solid setup before you go live. So let's take a detailed look at the following:
Common Terminology
Hosting—Selection and Unique Needs
Architecting for a successful Joomla! install
Downloading Joomla!
Important settings
Permissions
Common trip ups
Setting up metrics to measure security
For clarity, the following are a few terms that you may or may not be familiar with:
Hacker: A person who learns about technology to enable him/her to write a better code, build better machines, or to employ it in his/her profession or hobby.
Cracker: This is a person who learns about technology for the sole purpose of criminal or border-line criminal activity. A cracker is never viewed as one of the good guys, unless it's by the other crackers. When a system is attacked, a cracker's intent is to steal, "own", destroy, or spy.
Owned: This refers to the state of a machine after a cracker has successfully penetrated your defences and has placed a code to listen, steal, spy, or destroy your box.
Exploit: This is a vulnerability in software that can be used for breaking security or attacking an Internet host over the network. The Ping O' Death is a famous exploit.
More grammatically, it's a program that exploits an exploit.
In the "dot-bomb" days, everyone had an idea for the next Million Dollar deal. The Internet enabled the clicks and bricks strategy of taking traditional businesses to the Web or even an 'Internet' only business. Some like eBay and Amazon, survived the "dot-bomb" days, as did others. But many failed to survive.
One interesting type of business that rose up to support the growth was hosting companies. In those days, I met with several hosting companies in my career and they were running very well, in fact, most of them are still running quite well. Yet the advent of cheap hardware, the demand for growth in the Internet landscape, and the abundance of high-speed software have caused a glut of cheap hosting. Many of these hosts are not the best choices for you, due to the inadequate security models they have set up.
In this section, we'll discuss a little about what a host is, and how to select one that will fit the needs of your Joomla! site and your business.
For the completely uninitiated, a "web host"' or host is a company that houses your website on its servers. They typically provide DNS, email, tech support, registration of your domain name, firewalls and security, and much more.
If you've spent any time at all searching for a host, you will no doubt have found about eight-bazillion different hosts, each claiming to be the best hosting site on the Web. While this book will not be recommending one, we will cover ways to evaluate and learn more about them; what the different terms mean, and some important differences between hosts such as "shared" versus "dedicated". These are all critical to know if you want to have a successful launch of your Joomla! site. Typically, the hosts are housed in a physically secure facility, and provide emergency power in the form of a generator or other means of battery backed-up power. Often, they have more than one connection to the Internet. Most of them can provide you with as much bandwidth and speed as you need, allowing you to buy what you need. These facilities should provide a great deal of protection for your website. They should be enabled with fire-suppression and protection, water-detection, security personnel, caged and locked access to servers, and more. One data center the author is familiar with personally, has a fully-redundant network, meaning, if a backhoe were to cut through their data lines leading to the Internet, the hosts would be able to continue their operations through another path. This is important to understand because if they are down, you are down. Another mark of a good host is 24-7 network monitoring with live personnel.
For instance, if you call them at 2:00 am local time (local to you), they should pick up the phone and be able to address your questions. If they cannot offer you this support, then find another host. One question you may wish to ask when evaluating a host is to ask about their "emergency power". Chances are they will say "we have a generator". Ask them- How long will it run without refueling? This is expressed in hours, such as seventy-two hours or forty-eight hours, and so on. The next question is to ask them if they have fuel-contracts and what is the delivery time? What you are asking them is—Can you get these noisy beasts refueled before they run out of fuel? The person you are speaking with may or may not know it, but ask them to find out. This is an industry norm.
You will need to determine right away the type of hosting you need, shared or dedicated. The questions to help you determine which one you need are beyond the scope of this book, but we will discuss the differences between the two.
You may be a two-person shop in your field, but that makes you a leader. As a leader, you cannot sit still; you must be planning for the future. You must be on the lookout for threats to your business, and the opportunities to grow. Your host has to be flexible to accommodate your needs in this area. Face it, if you select a host simply due to them being the lowest cost provider, you are being "penny wise and pound foolish", which is to say that you are saving a penny through your efforts that is costing you a dollar! Remember, selecting a provider on cost alone is a terrible mistake; one that will cost you dearly. Take some time and review your competition in your field. Where are they hosted? Why are they hosted there? What are the costs and the associated setup fees to set up there and so on. I am not advocating that you follow them into the abyss of hosting. However, they may know something you do not. Hosting is not your business, unless you are a hosting company. Your business is whatever it is, yet, hosting is an integral part of your business web strategy and should be considered as such. It's not an after-thought, anymore than, 'gee' I don't care if I live in a terrible, crime ridden neighborhood while I don't have to; its 'cheap'. Take the time to review what your web strategy is. Evaluate your strategy in terms of your questions.
What physical security measures do the hosts have in place? I have visited countless data centers in my career; yet, the ones that stand out in my memory are those that had a very strong security. This is not to mean that they have a card swipe on the server room door. No, this is a strong perimeter set at the front door, a strong authentication at the check-in desk that you are supposed to be there. Once there, can you open the rack or cage of anyone's servers? If you can, this is a bad sign.
Having a strong security presence on the floor always gives me a sense of security about the data center. Of course, there are cameras but so what! A guard who's wearing a weapon, and walking on the floor will do a lot to deter a social engineer who might have made it to the floor.
As you are researching or interviewing the prospective host, one thing that is usually not asked by the average consumer is the security of the facility. It's important because this will often tell you if the host is simply reselling, or if it runs the facility. If they do not know, or brush it off, they are probably only 'reselling' someone else's hosting. That does not mean it's bad; it means they do not know.
If that is not the case, then the person you email or speak with by telephone should be able to address your questions. These are some of the questions a large company would ask during the interview of a "co-lo" or co-location facility, during the sales process. Why should your business be any different?
Asking the following questions and obtaining answers that satisfy you is another step in your security chain:
What are your check-in and checkout procedures for guests, visitors, and employees?
Do you check if your staff has a criminal background?
What is your policy for dealing with potential security breaches?
Do you have a terrorism response plan?
How are the employees trained to handle bomb threats, fire drills, or fire?
Do you have a physical security guard patrolling the floor?
How is your dedicated (should you choose to have one) server protected?
Do you have a "man-trap" entrance to the building and/or the data center floor?
Does your data center have windows? (You might be surprised at this one.)
Are you near a flood zone?
What emergency power are you provided with?
How long can the system run on that emergency power? (hours/days)
Is the data center on a "raised floor"?
Is there water detection under this raised floor?
How much cooling is provided in the data center?
Is there redundant cooling?
Do you have a humidity-controlled environment?
Do you have a site disaster plan? If so how often is it tested?
Note
Did you know that in the US, the Government maintains flood zone maps?
Is your data center in a flood zone? I know of a one large sitting next to a river that 'tends' to get out of its banks quite often; something to consider.
http://msc.fema.gov/webapp/wcs/stores/servlet/CategoryDisplay?catalogId=10001&storeId=10001&categoryId=12001&langId=-1&userType=G&type=1
These are some basic questions that will help you have a secure hosting environment. Keep in mind that not all questions may be answerable from the sales person's head, but they should be able to locate it quickly.
We'll discuss patching soon; however, it is important to gain an understanding about patching of the O/S and the web server (in our example, Linux and Apache.) For instance, when a critical vulnerability is discovered in the Linux kernel, you should be able to know if it affects your shared or dedicated hosts. You should know when it will be patched by the host (shared, virtual, or private), and if they maintain the O/S for you on your dedicated equipment when it will be handled. Time matters when vulnerability becomes public. Knowing the patch methodology (identification, documentation, build of the patch, testing, and deployment) is just a part and parcel of your security experience. Remember, you are ultimately responsible for the uptime and security of your site. Turning a blind eye to the host won't make you secure. They may have the task and responsibility of patching, for instance, but at the end of the day, your customers will not care whose fault it is, if you are breached. They will want you to explain it.
In essence, shared hosting is renting space on a server. This, by far, is the most economical route to get your website published, and the author would venture to guess the most common route. This means they "carve out" a small portion of the server's bandwidth, CPU, memory, and disk and assign it to you. You may see something like the following screenshot when you FTP in:
As you can see, there are several shared server folders displayed, namely, the public_html and www folders. These may vary based on your host, but the point is "above" these folders are areas that their administrators can see, but we cannot. Next in the directory there would be another set of folders that host another website. We don't have the appropriate permissions to see them or interact with them. The memory, disk, CPU, network bandwidth, and other portions of the server are shared with everyone on this physical server. This shared model is economical because the cost to run it is spread across many websites. The hosting company is responsible for patching the systems and ensuring their uptime and maintenance. You are only responsible for your own.
One situation that can arise through the shared model is, if a "neighbor" website is compromised (meaning, broken into by a 'cracker'), your site may be attacked as well. The attackers, depending on how deeply they are able to penetrate, can often wreak havoc on a box, destroying everything in their path. If a host finds out that the attack originated through your website, it is likely to cancel your account or shut you down till you can prove that you have patched your stuff. For instance, let's say you were running an older version of Joomla!, one with a renowned and well-published exploit. Now, if a young punk in a cyber café finds your site to be open and cracks your site, defaces it, and then laughs and goes on leaving you holding the bag, the host is not going to try to block the entire country of the attack's origin. The host will simply lock down your site and account after they clean up. They get real grumpy over this. They feel it's your responsibility to keep up with patching your own site.
A good place to check for exploited software is the online searchable database: http://osvdb.org/search.php.
Patching is a way of life if you have a website, and it is something that we'll spend time on later. For now, keep in mind that if you have a site, you should take the appropriate time, review the forums, search the databases, and check the extension sites to make sure that you are not running anything that has exposed flaws.
Shared hosting almost always comes with a control panel much like the following screenshot, known as cPanel:
As you can see in the previous figure, we can tell many things about our site, such as the number of MySQL databases we can have, our shared hosting IP address, and more. Here is where we would control the setup of our databases, other applications, and things like backups, FTP, stats, and more. Each host may vary in what its control panel looks like. However, many hosts do use the cPanel hosting applet. Dedicated hosting often uses the same panel and features, but exceptions abound.
Often a dedicated host is what you will choose if you want the full power of the server. You might want this if you are expecting a ton of traffic to the site, in which you would not want to "share" the resources of the box.
In this case, you will have to either administer the system or pay the host to administer the box for you. You probably will have to do the patching of the operating system, in addition to the other components. You may not have to keep the hardware running, as you are renting an entire box.
Other forms of dedicated hosting are when you purchase the hardware yourself and place it into a co-location facility. Known as a co-lo, these businesses provide you "pipe, power, and ping". In other words, they will give you a secure place to house your machine, provide the power, provision the IP address, and provide security.
Both these options are very costly, with the last one being the most time and money consuming on your part.
How do you choose what to do? If you are starting out for the first time, a convenient and economical choice is to go with the shared hosting, month-to-month. This way, if you discover problems with the hosting, you can always move and not incur a great deal of expense.
Again, the author does not make any recommendations for hosting; however, a couple of great places to start your search are:
http://www.webhostingtalk.com/
http://whreviews.com/searchstrategy.htm
These two sites can provide you with a great deal of knowledge about different hosts, their costs, the level of support you can expect and so forth.
In this book, we are going to focus on the Linux, Apache, MySQL, PHP environment, and as such, you can review hosts that support this environment as well as the Joomla! environment.
If you have friends who have a website, ask them how the support is. Call into the tech support and see how open and friendly they are to help you as a prospective customer. If they won't help you as a prospect, you can rest assured you won't get help as a customer.
As you work towards making a decision, ask about your ability to change several of the key variables such as open_base_dir, safe_mode, register_globals and others that are important in supporting your site in a secure manner. Be sure to inquire how you will change those, if they have to be changed and so on. Sometimes you have access to the .htaccess for your shared host, and sometimes you don't (this doesn't apply in dedicated because you have complete control), and this is important to know.
As at the time of this writing, there is a definitive line drawn in the sand in the Joomla! world about allowing or not allowing encrypted extensions. No matter which side of debate your feelings are, if you decide to purchase and use an encrypted extension, make sure in advance of your purchase that your host supports Zend or IONcube (depending on the app), or whatever means that may be deployed. If they don't, you will have to attempt to get your money back, change hosts or discover a method to make them work. Translation, do your homework in advance.
Your border security begins with the host where your site is residing. If you choose a poorly run host, then expect trouble, successful attacks, and more. That is not to say that a well run host is free from attacks. It just lowers some of the obvious problems.
Take time to learn all you can about the prospective host, but don't base your purchase on price and flashy sales pitches by the host.
Believe it or not, planning for your site rather than diving in will help you have a much more secure site. How, you may ask. Through careful planning, you can establish a path and a direction to get there. You can research the pitfalls and find ways to avoid them. Thus, you will be operating in the parameters of wisdom, which will enable you to depend on others' experiences, and learn from the mistakes that they made.
If I had $1.00 every time a client said, "I need a website" and I asked, "What is it going to do?" I would probably be sitting on a beach drinking something with an umbrella in it rather than writing! Though seriously, it's more common than not. The answer is often not well thought out, thus causing many uncomfortable questions to be asked.
Here's a real life scenario: Customer "X" says that he works in the financial world and needs a 'secure' website. He needs to "securely" make available his highly confidential financial documents to his clients via the Web. "Security is very important to us" they stated multiple times.
OK—what would you ask if this were you? What steps would you take? Let's walk through this together and follow the trail of knowledge.
Step one: Define the current business practices that do not interrupt the business process flow. In other words, you want your website to reflect the most reasonable and currently established business practices, as closely as possible.
Step two: What will be the purpose of this site for your customers? Is it e-commerce? Is it a membership site? Is it a secure document repository?
Step three: If this is highly secure (read: e-commerce), have you researched the cost of the security (SSL) certificate for your site? If you are doing any type of financial transactions such as taking money, you will more than likely need an SSL setup. This can influence the choice of the hosts.
Step four: Where will you host? Is this your favorite nephew's "really-smokin' hot box" in his basement? Not a good plan. Is this a "free" host?—might be good, but hey, if this is important, spend a few dollars and get a solid host. Check the reputation for the host. Surf around and read reviews. You'll figure out quickly who's good and who's not.
Step five: If you need SSL, does the host you selected in step 4 support the inclusion of certificates? Can you buy a certificate from them? Believe me you want to check this one.
Step six: Draw out the functionality of the site you want. What it will do, what content it will serve, how the users and visitors should interact. After balancing out the three factors of ease of use, speed, and security, you can decide.
Step seven: Taking step six a bit further, what extensions will you need? Will you have one written? Two problems exist right away for either of these.
Existing third-party extensions. Check the vulnerability list. Are they on it? If so, you will need to make the call if you can live with it (probably not), or if you can fix it. If they are on the list, contact the developer and see if he/she has fixed it. If not, then find another way to accomplish what you need done.
Custom work. There abound thousands of developers for Joomla! and a good places to check are http://www.jcd-a.org and http://www.joomlancers.com. Both these sites offer lots of either well-written extensions or in the case of Joomlancers, a rent-for-hire coder. You may say Great! I can hire someone and put them on the task of building my UBER customer extension! Here's where it gets weird. You need to ensure the testing methods they will use (demonstrable) to prevent SQL injections, buffer overflows, and so on. And the second thing is, get them to agree to fix any vulnerability with their original code that is discovered in the future, as part of the deal.
What if you upgrade? Will your extension be compatible? Maybe, and maybe not. If you upgrade from say 1.0.12 to 1.0.15 or even 1.5.x, which you may consider is an easy jump, then will it work? A lot of extensions may fail or not even be compatible after that. This can cause potential security holes? Yes.
Step eight: A very large percentage of security problems are caused by the employees and customers; sometimes on purpose, and sometimes by accident. Therefore you need to consider this as a part of how you will prevent bad security issues with customers and employees. The ideas include mandatory password lengths, changing passwords frequently (30 days to 60 days is a common time frame), and educating customers and employees on "social engineering" tactics.
Step nine: Read this book thoroughly, as well as others. Learn (if you don't know already) a bit about PHP programming. I recommend W. Jason Gilmore's book.
Note
W. Jason Gilmore, Beginning PHP and MySql 5 — From Novice to Professional (California: Apress, 2006).
Research the security forum on Joomla.org, as there is a ton of information available to you. Know what settings are available; know what happens when a setting goes wrong. Remember, security is not a "defensive" action; it is a proactive action. The best time to get the bad guy out of your site is before he or she gets in.
Step ten: Draw up a plan to test your site, check your permissions, check your php.ini, and your .htaccess file. Then test some more. Consider doing or hiring out a "pen-test" or "penetration test" on your site to see where it can be broken into. Do this on your test site BEFORE you go live. Decide WHEN you will need to upgrade and why. Don't update unless there's a valid reason to upgrade, such as a major vulnerability in the CORE code is discovered, and then be careful. Deciding this upfront and before you start it will enable you to be aware of why you are upgrading rather than just following the Joomla! herd and upgrading because of a new release.
Step eleven: The last decision you have to make is which version of Joomla! do you want to use? Do you want the 1.0x series? Or do you want the Joomla! 1.5 series? Each offers a powerful CMS, and each offers a plethora of reasons to use them. How you decide this is beyond the scope of the book, but this needs to be mentioned.
In this section, we will discuss a few relevant points necessary to security. However, detailed instructions for installing either of the two versions can be found in the following Packt Publication books:
Joomla! 1.0.x series—http://www.packtpub.com/joomla-v1/book
Joomla! 1.5 series—http://www.packtpub.com/joomla-version-1-5/book
If you are not familiar with installation, I highly recommend you to read one or more of these in detail before installing Joomla!
Now that you have chosen a host, and have your site prepared, its time to download Joomla! But wait? Which one do I choose? Surely, you chose this already in Step 11 from Joomla! 1.0.15, or the new and completely redesigned Joomla! 1.5.X. It is important to understand a few differences about each of these versions before you make an initial decision. Just as your choice of a version is important, so is it important to ensure that you download it from a reputable source, preferably Joomla.org. There are other sources from where you can download it preconfigured, and with add-ons. There's nothing wrong with that, but check it thoroughly. The point to remember here is that you must be very sure that it's a trusted source and that it hasn't been tampered with. Later, we'll learn about some tools developed by the community that will help you keep track of the health of your site. When you download your copy of Joomla!, it should be provided to you in a ZIP format. That zip file itself has an MD5 hash, which is a 'digital signature' ensuring that nothing has been changed. Note: At the time of writing this book, the MD5 Hash for Joomla! 1.0.15 was not available from Joomla.org.
If your hash is different, then the package contents have been tampered with. This could indicate something as simple as a bad download, or it could be tampering. I would suggest you not to use this package, rather delete it and re-download. In any event, the MD5 Hash is a good protection mechanism to ensure the "Authenticity" of the compressed file.
Note
Where did you download it from?
Always take the extra caution of downloading your source directly from Joomla! to ensure that you are always getting the correct package. This is not to say that other reputable sites aren't offering it, but it's an easy step to ensure security.
One of the key security differences between 1.0.12 and 1.0.13 is the way a password is stored. In fact, it's so different that if you upgrade to 1.0.13 from 1.0.1x, you cannot go back in the event of a problem. At the time of writing the book, this is presenting a problem for some extensions. It is highly recommended that you check on the Joomla.org site for changes that will have come before this book reached publication.
Another important difference in 1.0.13 is that the Register Globals emulation setting has been moved to the main configuration file and can be adjusted in the backend administrator interface, as opposed changing it in globals.php in 1.0.12 and lower.
Joomla! 1.5 is a newly redesigned version that streamlines quite a few of the traditional methods. These include features such as the installer being universal, not broken out separately, a new FTP layer, new API for third-party extensions, easier development, and promises of robust performance. However it is a different Joomla! and the reader should familiarize themselves with it in detail before determining which path to take.
The following are some settings you will need to make before you launch your Joomla! site. Doing so will prevent some nasty surprises later.
The file known as php.ini is a PHP configuration file used to control some of the settings of the PHP interpreter. A php.ini file enables you to customize such settings as whether the global variables are turned on, the default directory to upload files to when writing upload scripts, and the maximum allowed size for uploaded files. There are many other settings we'll cover in later chapters. For this portion, we're going to cover the necessary parts to set up a secure environment for your system. They will help you in making your system more secure. But again, as was pointed out in the introduction, there is no such thing as a completely secure system. One additional thought is that these settings may need to reside in more than one place, depending on the way your host has its servers configured. As such, you are encouraged to read the Joomla! forums regarding php.ini to see if someone has already solved this problem with your host or not. Many times, they have. What we will cover here are the basic php.ini settings that are needed for Joomla! 1.0.xx series. We'll cover the Joomla! 1.5 settings following this.
For each setting, we name its default value and a short blurb on why we must select it. In a later chapter, we'll cover php.ini in greater detail.
Following this will be the settings for other files such as .htaccess and global.php.
In the PHP version 4.2.0, the support for one important variable was changed. We won't go into the details as to the battle that must have ensued to change this, but you can read about it at http://www.php.net; look up Register Globals. It is noteworthy to point out that in PHP 6 this is completely gone.
register_globals = off (you may also see it as = 0)
If this is left on, someone attempting to break your site could use it to inject your scripts with all sorts of variables. This is a typical problem with some extensions and has been the death of many a good site. The attacker could use this to insert request variables from HTML forms as a means to break the site open. In the past, it was assumed that PHP simply worked this way, and so many extensions and applications were written that required it to be on. There are only two things you should do in that case, fix the extension by coding in the proper support to sanitize and check, or dump it and get a different extension. Note that in Joomla! 1.0.13, this is now included in the control panel.
magic_quotes_gpc (by default it is on)
First and foremost, this is on by default and should remain on. This "escapes" all variables that are sent to the database. The crackers will use scripts loaded with all kinds of goodies, meant to pass through to the database or other parts of the system. By escaping them, it actually neutralizes their power to harm you. DO NOT TURN THIS OFF.
In segments of the PHP community, there is a great deal of preference for leaving this off and ensuring that you write cleaner code, putting in proper escape characters, and so forth. That topic is beyond the scope of what we're discussing, and unless you write all your own code, leave it on. You don't know unless you verify it what someone else's code is doing.
allow_url_fopen = off
This function treats remote files as if they were local files on the server. The preferred setting is default. This is a PHP command that says if the filename takes the form of
http://..., orftp://...it is assumed to be a URL. The PHP engine takes off in search of a correct wrapper or handler to deal with it. As you can see, this is a neat way to mess with the system. If it cannot find the right protocol, in this example FTP or HTTP, then it issues some warnings and treats as if it is a local file.This may not always work and you may have to trade off running it "ON" if you have certain extensions that are required to have it "ON". As always, your mileage may vary.
expose_php = off (default value = on)
One of the first steps an 'attacker' takes is to learn as much as possible about your site and you. Therefore, while we don't advocate security by obscurity as a matter of course, due to it being generally a weak plan, a little misdirection can be a good thing. This setting when set to off can reduce the amount of information an attacker could glean.
safe_mode = off (default)
This one can be tricky, but it is recommended by Joomla! to leave it in its default state of off. Turning it on will disable quite a few features, including, but not limited to:
parses_ini_file(), chmod(), chown(),exec(),system()and more.However, being in a shared world, you may run into situations where it needs to be changed to on. If it is turned on, there are several options that go along with it. And there are several things that may not work with Joomla!—so use it with caution.
There are several other optional settings in php.ini that change how the system functions, but these are the key ones.
Next you will need to make changes to your globals.php file if you haven't made them already. Note that this applies to Joomla! 1.0.12 and older. For Joomla! 1.0.13, change this in the configuration panel.
Make the following change to the highlighted line—Please change the 1 to a 0
/**
* Use 1 to emulate register_globals = on
*
* Use 0 to emulate regsiter_globals = off [sic]
*/
define( 'RG_EMULATION', 1 );
/**
* Adds an array to the GLOBALS array and checks that the GLOBALS variable is
* not being attacked
* @param array
* @param boolean True if the array is to be added to the GLOBALS
*/
In Joomla! 1.0.13, in the administrative console select GLOBAL CONFIGURATION | SERVER. You will see this box:
If you are using Joomla! 1.5.3, add the value to your php.ini file of:
register_globals = off
Be sure to add a php.ini file to your administrator folder as well as in your Joomla! 1.5 configuration.
Note
Please note that some hosting configurations have an hourly update whereby they clear the cache on the server of the former .htaccess and php.ini files. If you don't see an immediate change to your system after you add your .htaccess or your php.ini files, wait for an hour and come back.
This is not too uncommon, but it does vary by host. You can inquire about it with the technical support staff or check the frequently asked questions section to see if this is the case.
How critical is Register Globals ?—Very!
The setting may be "1" out of the box. If so, make sure you change this to zero. This will ensure that Register Globals is turned off. This is very critical to the operation of your site. By ignoring this, you are leaving your system open to all kinds of shenanigans by the bad guys.
.htaccess is a wonderful and powerful tool on which we'll spend a lot of time later, but for now, make sure you include the following code in yours. If you are not familiar with .htaccess or if you have a default setup of Joomla! you will see in the root directory a file called htaccess.txt. This file provides you the power to modify several things on the basis of a per directory file, notably the directives. Here is the portion you should be running. This has been included since Joomla! 1.0.11 in the base htaccess.txt file. Check yours to ensure that you are running this highly valuable security measure.
########## Begin - Rewrite rules to block out some common exploits
## If you experience problems on your site block out the operations listed below
## This attempts to block the most common type of exploit `attempts` to Joomla!
#
#IF the URI contains a "http:" or "ftp:" or "https"
RewriteCond %{QUERY_STRING} http\: [OR]
RewriteCond %{QUERY_STRING} ftp\: [OR]
RewriteCond %{QUERY_STRING} https\: [OR]
#OR if the URI contains a "["
RewriteCond %{QUERY_STRING} \[ [OR]
#OR if the URI contains a "]"
RewriteCond %{QUERY_STRING} \] [OR]
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits
You will need to append the previous code segment to the end of your .htaccess file. If you haven't done so, please change the name from htaccess.txt to .htaccess.
This .htaccess patch from the Joomla.org core team has proven its worth against a slew of attacks that are common. As you can read through, the RewriteCond is being used to filter common attacks that could prove harmful to your site. The last line in the file:
RewriteRule ^(.*)$ index.php [F,L]
directs the system to forward all requests to damage your site to a : 403 Forbidden page.
Another interesting command you could add to your .htaccess file is a set of commands to stop a specific robot, in our case "EvilRobot", from digging into the sensitive areas of your site.
RewriteCond %{HTTP_USER_AGENT} ^EvilRobot.*
RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$
RewriteRule ^/kljiwlslci/secret/data/.+ - [F]
Note
To learn more about the RewriteCond and the RewriteRule, visit the following links available from apache.org:
http://httpd.apache.org/docs/2.2/rewrite/
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
One simple way to protect yourself is to ensure that you have the permissions set on your files and directories. The following settings are the recommended permissions:
.htaccess............644
configuration.php... 644
Directories .........755
Files............... 644
While these are recommendations, your particular needs may be different and you should adjust accordingly.
When you set up your site, there are several different methods to manage users and their permissions. The permutations are numerous and I would suggest you to pick up a copy of Barrie North's book:
The Joomla Admin Manual: A Step by Step Guide to a Successful Website
Or
Joomla! A User's Guide
You can find both of these at joomlabook.com or Amazon.com
Later, we are going to learn about tools to help you post-install. However, if you have taken these steps, you are doing very well indeed.
While an entire volume could be filled with common mistakes, we'll focus on a few of them here. They are presented here in no particular order.
One big problem comes in if you are using a component that is vulnerable. To start with, why would we deliberately set up our site to be broken into? A quick review of the current vulnerability list shows at the time of writing of over sixty known vulnerable extensions.
Here is one chosen at random known as AutoStand. I followed the link listed in Joomla! and found the security site FrSIRT. They list this as a critical exploit.
Advisory ID : FrSIRT/ADV-2007-1392
CVE ID : CVE-2007-2319
Rated as : High Risk Remotely Exploitable : Yes
Locally Exploitable : Yes
Release Date : 2007-04-16
A vulnerability has been identified in AutoStand (module for Joomla), which could be exploited by remote attackers to execute arbitrary commands. This issue is caused by an input validation error in the "mod_as_category.php" script that does not validate the "mosConfig_absolute_path" parameter, which could be exploited by remote attackers to include malicious PHP scripts and execute arbitrary commands with the privileges of the web server.
Affected Products:
AutoStand (module for Joomla) version 1.1 and prior
Solution:
The FrSIRT is not aware of any official supplied patch for this issue.
References:
http://www.frsirt.com/english/advisories/2007/1392
According to this alert, Autostand version 1.1. and prior is vulnerable, and this advisory mentions that at the time of writing there was not a fix. To be fair, by the time this book comes to print, it is likely that it will have been taken care of. What is important is that we can see there is a highly critical vulnerability (see frsirt.com advisory for severity level). The actual nature of this attack is input validation, meaning, the programmer for this particular version did not properly sanitize the user's input. If I were "Johnny Craxbox" the kiddie script guy from somewhere in the world, I might pass arbitrary commands to the system such as the following:
rm -rf *
Whether this would work or not is unknown, but please do not try it, and it's most likely that it will be unknown to the cracker. But if it did pass through with the privileges of the web server, then I have instructed the server in the last part to delete the entire web document tree. Not a good thing to say the least. These vulnerabilities are almost always known to the bad guys before they are known by the good guys, or even the author of the application. Checking the third-party vulnerability list is not only easy and quick, it's simply a very good idea. To fail to check the list is tantamount to laziness. Take off a few minutes right now and bookmark this location:
Note
Tip to check the third-party Vulnerability list from Joomla.org.
http://help.joomla.org/component/option,com_easyfaq/task,view/id,186/Itemid,268/
As discussed earlier, having Register Globals enabled is a huge problem. This is so prevalent that a search on the Joomla! forums will turn up multiple instances of this repeated offense.
Seeing 777 may be lucky if you're in Las Vegas, but it's hell to pay on your site. We discussed the correct permissions settings earlier, but it bears mentioning them here again. If you have made all your directories and files 777, then get a backup, sit back, and wait to start your restore.
While this may be a bit out of the scope with this book, writing down your database settings can be invaluable in an emergency situation. If you are cracked, you may need to reference the authentication information quickly. Write it down! Store it in a safe place.
Surprisingly few people have backups much less practice backing up, preparing a plan, or testing the plan. DO NOT let this simple action keep you from doing it. Back up.
There are several ways to go about backing up. You have to choose the method that works best for you, but whatever method you choose, it must have the following elements in it:
Ability to capture directory structures, files, permissions, and database.
Ability to lay your hands on it quickly.
It must work when restoring is needed.
It must be fresh and up-to-date.
Establish a multi-session backup scheme. You should have three to four weekly rolling backups. That way if you were cracked in week two of the month, but you know week one is good, you have that copy.
You need a standard enumeration method (fancy word for naming) for your backups.
You should practice restoring a few times to make sure you have it.
If you do these simple things you are going to be way ahead of the pack.
Note
Disaster Recovery and Business Continuity
This topic is beyond the scope of this book. However, one key question to ask your prospective host, shared, dedicated or co-location is, "Who does the backups?", "How can you get them restored?", and "What is the cost and time to restore?". You will be shocked to learn that in quite a few cases you will be expected to back up your own data and take it off site. For a more detailed discussion of this topic, the reader is encouraged to read the author's disaster recovery book: Dodging the Bullets, a Disaster Preparation Guide for Joomla! Web Sites. Or take the time to research and set up a good, solid back up, and recovery plan.
What is a security metric, and why would we want to have one? For the purpose of this book, a security metric is a set of measures put in place to track key incident events. For instance, number of attempted incursions into your site, and so forth. This section will be discussed from a high level and will not delve into heavy specifics. The intent is to make you aware of the need to measure your security and some high-level views on measurement. In this section, we will discuss establishment of baselines, setting up good measures, and metrics. These metrics will apply to your site and to the machines you use to work on your site. We will wrap up with a few words and precautions on reporting to forums, and reporting to hosts about incidents.
You can think of a baseline as a "known good" standard. This is like the "foot" standard in the United States, or in the metric standard, the "meter". These are known lengths that are used to ensure our "copy" of the foot or meter is accurate. In your site, you need a known good "baseline" to measure the future changes against.
What is a good baseline?
A baseline is a snapshot in time when things are good or are performing their best. The reason for this is two-fold: one, it will give you an opportunity to put your measures and metrics in place to measure security. If this goes awry, it will affect your uptime and the availability of your site to the clients and customers who may want your goods and services. The second reason for establishing this base line is to help you design procedures that assure you are doing everything you can to protect yourself. If you are working with more than one person, you will want to work with your staff to come up with a set of metrics that are meaningful, will yield actionable data, and can be proven under most circumstances. A good metric that's often used is the "uptime" of an important system. However, just giving me a figure and saying that it is up and running does not tell me anything 95% of the time. There are many factors involved in this measurement. Establishing what is important to that number is your baseline uptime number. While it may not be spoken, you can be assured that most people will be unforgiving if you don't have the perception of 100% uptime. Note that I said perception. As you know, with Joomla!, you can switch the site off and put up a friendly message stating that its down for maintenance, or an upgrade. This could be a ruse on your part if you are defaced, to simply cover it up while you activate your disaster recovery plan. On the whole, this baseline will be your model of a secure (as you can make it) site. Here's an instance to consider. You set up your fancy new website, using say version 1.0.15 from the Joomla Forge site. You research your extensions carefully, and you follow the directions to install them. Your site is up and you submit it to Google for the entire world to see. Let's say you even advertise that your site is up and running for business! A few brisk weeks of sales, and you are happy. Then one day you wake up and find that you've been attacked by some third-world punk who defaced your site! Barring anything else, that alone would give most customers a pause to purchase from you.
What happened in our fantasy example? Here, you did not rename
htaccess.txtto.htaccessand put in some base controls to stop ordinary kiddie scripts. Having a baseline of understanding would prevent a mistake such as this from happening.What are you going to measure?
That is a good question, and is VERY dependent on your site and your situation. There are a few common things that should be a part of your baseline measurement, for instance, log files. Your baseline should have a way to collect and review them. There are several logging tools from the community and you will have to pick one. In any case, the logs should be collected every "x" minutes. This metric would yield all kinds of actionable data relating to security.
Here is an example:
Our required data points are as follows:
The number of visitors over a twenty-four hour period.
Where they originated from.
What they did while they were there (this could be anything).
Metrics:
"X" visitors came to our site in the last twenty-four hours.
Of those "X" visitors, "Y" attempts were made to do an SQL injection on our site.
The IP addresses attempting the attack (barring IP spoofing) are originating from a specific region in the world.
The SQL attack is on an extension that we do not have on our site.
No other attempts were made on the site itself from the logs.
Action Required:
This has two answers—one, you could do a DENY FROM, and put in the country's IP block, or just those specific IPs to stop them in your
.htaccessfile. Two, you could ignore them and laugh at them because they are "lamers". A good cracker would have researched your site to determine if you were using it. Either way, that choice is yours to make. But because you have established a metric that provided you with actionable data, you have the information needed to make the right choice.
You can see a simple example, on monitoring attacks by IP/type of attack. However, and I strongly caution you to think this through, if that extension in our example were vulnerable, you would not be reading the footprints these lamers left behind. You would likely be mopping up the damage. This example is to show you how to collect actionable data. The following is an example of a report you may produce for your site showing % of attacks by visitors:
The things you may wish to measure include the following:
Number of attempted attacks
Type of attempted attacks
Locations where the attacks are coming from (geography)
Attempts to authorize credit cards multiple times
Attempts to "obtain" a lost password more than once from an IP
These are just a few examples of what kind of things you can measure. Some may apply to you; some may not apply to you.
How are you going to measure?
You cannot measure anything without a tool or a set of standards. How you measure is as important as what you measure. In the previous example, we may be running the logging tool BSQ-SITE SITES (visit: bs-squared.com to review this logging tool) to collect our stats. If so, we will have crafted a simple process to use this tool and to respond to the events. For example, as this chapter was being written, the author stopped to review his own logs. Sure enough, three attempts were made to use "kiddie-scripts" to break into the site. They were not successful because the site was not running the vulnerable scripts they were attacking. The actionable data, that is the standard policy, is to block the IP address. This is not because of the concern that they may eventually get in, rather it helps to filter the attempted criminal activity from real paying customer activity. We are concerned with both, and taking time for reviewing log entries only to discover multiple attempts to break in is a waste of time if you do not take action. Additionally, it is doubtful that anyone who attempts this will come back with intent to spend money. Hence, locking them out saves time, bandwidth, money, frustration, and potential future attacks. Once you have determined your metrics, take time to decide how you will measure them.
The tools that can be used to gather these statistics are abundant:
These are just a few of the tools available out there. The author doesn't recommend a particular one, because each tool measures things slightly differently, and with different emphasis on how they collect statistics. The key take away: Pick a tool that will gather the data you need. Learn it, keep it updated, and use it.
Where will we gather these numbers from?
For the most part in our example site, the stats were gathered from the log files that are written constantly. In fact, there is so much log data collected that you could write an entire volume on logging alone. Other sources may be a credit card authorization and verification system, such as
authorize.net. They will collect information that would not be picked up by our tracking systems at all. This could help you establish a trend that could impact you. For instance, you might be held liable in some instances for credit card fraud. Knowing that fraudulent activity is taking place will help you negate the effects. Again, establish the baseline, measure, and create actionable data.When will the baseline be established?
If you have a brand new site, then establishment of your baseline should be a part of your design criteria. In other words, design it as if you were adding an extension. Later, we'll cover some tools that are available, and should be a part of your site. More than likely if you have an established a site, this is a bit of a different tack. You will need to ensure that you are safe and secure by adding in the items that are missing, for instance, a common problem is leaving Register Globals ON. This could be part of cleanup, and will secure your site. Once you have done all the right things then you are ready to establish that snapshot.
What are you going to measure?
You have several items to establish here. Some are technical in nature, and some are social in nature.
Permissions checked: This is a baseline activity. You will need to make sure that you set it properly.
Host security: This might require a call to your host. Ask them how and what they do specifically to protect your site. Some of the common things that are (should be) in place for sure: firewalls, load balancers, Apache
mod_security. If they cannot tell you these things, get a different host. If you are hosting your site in-house, then make sure you take the necessary precautions to protect your data and infrastructure. This is of paramount importance if you are taking and accepting credit cards. Security of a server is a full time job. Another item you will require to gather information on is patching: When is it done, how is it tested, what are the critical-path items currently in place on the server.
Host IDS (Intrusion Detection System): Think of this as an alarm on your server. It monitors for attempted intrusions, allowing the NOC (network operation center) to respond to the attacks. This tool would be useful for detection of a DoS (denial of service) attack on your site as well. This tool works by placing "sensors" around the network, to detect intrusion or attempted intrusion into a system. Placement of these sensors can occur inside the firewall: that makes them an intrusion detection system. Placing them outside the firewall sets them up to be an attack detection device. A very good article that covers this topic in detail can be found at: http://www.linuxjournal.com/article/5616. There are several intrusion detection systems available, and having a cursory knowledge of them will be vital in your research. Here is an abbreviated list:
Snort (http://www.snort.org/) note: this is one of the best-known out there on the market.
LIDS (http://www.lids.org)
Ask your host about which one they use and if they don't have any, ask why.
Threats, Vulnerabilities, Countermeasures: Another metric you need to establish is a research metric to research on a regular basis about the threats that exist, the vulnerabilities discovered, and the counter measures you can deploy.
http://www.joomspyder.com has a collection of news articles kept up to date via RSS feeds from several different security sites.
You probably thought this whole book was about Joomla! security—you're right. However, this small detour off our main road is very important. Why Personal Computing Security Metrics?—that is because the Joomla! site is set up from somewhere, and that somewhere is your desktop.
The clients that visit your site won't be likely to browse it from the confines of their server's browser. They will be using their desktop or notebook computer. These devices, which are easily compromised if not protected, can become an attack point to break into your site.
While you cannot guarantee the integrity of your visitors' computers, you can ensure that you are safe. And perhaps you will gain some knowledge about how to communicate security to your clientele.
Basic protection mechanisms
The author recently switched the anti-virus prevention and detection from a well-known package to Kapersky (see www.kapersky.com), and it (kapersky) found three viruses on his machine that the very popular package seemed to have missed. This is not an endorsement of Kapersky; however, it is a worthwhile package to consider. It has hourly updates, it has a running total of new threats discovered, the time to put out a patch, and much more. Whatever you do, put the metric of anti-virus updating in place. The following is a list of a few things to consider for measuring and doing:
Anti-virus protection on your machines: Personally, I use Kaperesky; however there are several fine products available. Make sure you choose one and use it.
Spam protection: One excellent service that is available to filter your email is known as MXlogic (see:http://www.mxlogic.com). This system actually filters your email before it reaches you for spam, viruses, and spyware junk. Additionally, it can help with compliance by monitoring your outbound mail for restricted materials leaving your computers.
Good (read strong) passwords: You need to establish a metric and reporting process to change passwords of your employees, your computers, your website, and so on frequently. A good time frame is at least once in thirty days. By doing so, you will lower the risk of password compromise.
Spyware: This is an extremely viable threat to you. Through the use of spyware, you can for instance, get a Trojan horse on your machine that could watch for passwords to your website, your bank, and so on. If they were able to obtain your website administrative password, there would be no way to stop them from getting in. Products such as Webroot (http://www.webroot.com) do a great job in preventing and removing spyware. There are many free spyware products in the market, and some of them are known to be a cover-up for putting spyware on your machine. This is a bit of a social engineering attack.
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-surfing". 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 happen frequently. Sweep your building for these devices on a regular basis.
Eventually, you may need to visit the Joomla! forum or contact your host about security-related issues. Here are a few thoughts on proper usage and what you might encounter. When you approach the Joomla! forum, be aware that there is a ton of really good information available and by spending a few minutes researching you are likely to net your answer. However, if you do your research and find that the answer is obscure or does not exist, then yes, report it. Be prepared to get three kinds of responses from the forum:
No Response
Excellent help and pointers to postings that might answer your question
Flaming, name calling, censorship
Sadly, the last one does occurs more than it should on Joomla! and other forums. In the author's opinion, this is partially because those who donate their time to support the forum will become exasperated when you haven't researched the issue. This is your responsibility and it makes you a good Joomla! citizen to not waste everyone's time. It is not their responsibility to look it up for you.
However, sometimes, some people are just jerks and that's the way it is. Some of the moderators are heavy-handed and believe they should censor your posts. So be prepared.
Fortunately though, the first two are the prevalent items. If you do not get a response, research your facts again, check the way you are asking the question. Does 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 flaming 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 find.
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.
There are several other good-citizen type things, but these will specifically help you in the middle of a crisis.
We spanned several topics here in this chapter, all aimed at establishing both a good security baseline for your site, and a quick look at managing security metrics. In this chapter the necessary php.ini and .htaccess settings were covered, and a good planning tool to lay out your site for installation on the properly chosen host was discussed.
It cannot be stressed enough that following these steps will not only help you to have great uptime, but it will also secure the door well enough to keep all but the highly motivated from breaking in. Remember NO server is 100% secure, if you want a 100% secure server, turn it off, remove its power cord and network cable and stick it in a locked cabinet, and it is not a matter of IF you will be attacked and possibly penetrated, but when.
What can you do after having done all this? Create a good disaster recovery plan. A great place to start is the author's Disaster Preparation book Dodging the Bullets—a Disaster Preparation Guide for Joomla! Web Sites.
The nature of physical security was touched upon as it is frequently ignored.
Next, we will discuss setting up a successful test and development system to ensure good security.
