Joomla! Discussion Forums

Hello,

I am looking for documentation on the recommended security settings for a new Joomla installation on a remote web host. I've seen some scattered posts but I'm looking for a comprehensive document.

Thanks.

If you are in a shared environment you will be responsible for your top level application security. If you are a low level server administrator, you would be responsible for both the lower level security + application security.

As far as an all in one security document for a webserver, I've never found one myself. Just studied individual application security procedures. Joomla itself is a single application. If you are on a shared server you have little control over security other than correct file permissions, .htaccess limiting certain directories, etc..

Thanks for the reply.

Yes, I am on a shared webhost server. Joomla is all that I am installing in the main /httpdocs/ directory. I am looking for the correct settings (permissions) for the Joomla directories and files, and as you mentioned within the .htaccess.

I have a dedicated server, any suggestions for me?

I soon will be moving a couple of sites to a shared hosting site.

Can someone please point us to the appropriate documentation.  If it doesn't exist, that's really sad. 

There are not a lot default security documents around, there used to be one but can't find it at the moment. Joomla only advises a few PHP settings, for the rest all security is done on operating system, apache, firewall, and php level. I would search the net for security documents for each of those subjects. Joomla is only the application on those items. The biggest piece of advise is to install a Joomla patch if there is a security label attached to it.

Thanks.  It's unfortunate there is no documentation.  What I'm looking for is relatively obvious and painless.

Just to recap what I'm looking for.  When I installed and developed a few Joomla sites on my local machine recently (with the intent of eventually moving them to a shared hosting environment), the directory permissions were naturally opened full bore. I can't imagine that this is the way permissions should remain (i.e. 777), and I dread regression testing individually each directory to see how much things can be clamped down.

Can someone please simply state what the permissions settings should be for the respective Joomla directories?

What other hardening needs to take place in the 1.0.5 release?

I can address PHP & MySQL independently.

Thanks

Hi,

yes same question is mine too.

Regards,

Adnan

644 for files, and 755 for directories. With these settings your site will work fine, but you can't install any new components (Joomla 1.1 FTP installer is going to solve this). When you want to install any new components, check the Installers screen. That screen shows you which directories need to be 777 for installing/uninstalling components. For the moment, I just set the correct directories to 777, install a component, and then change it back to 755 again.

Ok understood
Many Thanks

Thanks, that's what I was looking for.

I'm running Joomla on IIS 6 at the moment.  Would someone be able to tell me what the linux permissions of 644 and 755 translate to in the windows world using NTFS?  I realize Apache would be better, but I'm not able to run that at the moment ( I'd like to get there eventually though ).

Any help would be much appreciated!

777 is the equal to rights for owner - group - public. Each 7 is a combination of three attributes, read(1), write(2), execute(4). This means that rights equal to 755 will give the owner read, write, execute rights, if you are member of a group read and execute, and public also read and execute. You can do the translation to NTFS file rights yourself now probably.

That helps a lot, thanks Tonie.  One last question since I'm Linux deficient...  when someone surfs to a site that's hosted on Linux, do they fall under the "World" permissions?  Or what user are they acting as?  Or is it a specific group that apache uses?

There is normally a seperate user that is just being used for apache. It basically only has rights to operate Apache. This account is called nobody/apache a lot of the times.

Absolutely.

1) Start with low level operating system lockdown procedures. ex: settings in the /etc/. There are quite a few changes to be made here on every distobution of Linux created. Same with FreeBSD or any Unix. You will need search the web for linux security measures. It will be quite some time before you perfect this and have down a lockdown procedure in your head.
2) Install nmap and nmap yourself. No-one else. nmap localhost, nmap -sU localhost. netstat --nap |grep tcp |more and locate running services and on what ports they are running. Make note of them. Learn them by heart.
3) For all ports you are responsible. For all applications running you are responsible. Know them well, know what you are running and what port it's supposed to be running on. Remove any applications not needed. Remove any boot init's that are not needed for each of those applications.
4) install a firewall. I prefer firehol script for iptables. Learn your firewall configuration options. Only allow incoming and outgoing connections based on the knowledge you have gained of what services you are running and on what port they run. Configure your firewall to allow only those connections to such open ports. Set dest and src for incoming and outgoing IP.
5) Get acquainted with linux and then on to bind. Start on learning the top level applications like apache, php, mysql, mailserver,  and any other program you run on an open port etc... Know how they work to the best of your ability.
6) Lock down the above mentioned programs by looking them up on google. This is where you are looking for answers that many times take up a hundred pages of study. Just your mailserver running on 25 can be a nightmare if you do not know how it works or how to lock down the mail application. That and, you can become a promoter of spam through open relays. Crackers love port 25. Remember that. Do install antispam and antivirus software on your mail server. I use spamassassin and clamav. Know these programs and keep them updated as well as the rule sets. If you are new to mail server administration, start with a simpler postfix and migrate to a more heftly Qmail at a later time. Unless you are pumping some mail, postfix or exim will do just fine. Stay away from sendmail. Trouble since it's introduction and a clunky mess at that.

In terms of pop/imap mail, do not allow unsecured connections to your server on ports 110(pop),143(imap). Configure a server cert and run port 995(pop3s), 993(imaps). Firewall off 110 and 143. A decent pop server I would recommend would be dovecot. Simple and configurable.

Do the same procedures of locking down the rest of your apps as you have your mail port. Mysql ports should be closed off on localhost and not available. You can alter this with skip-networking in your [mysqld] of the /etc/my.cnf.
7) If you are also administrating the network of machines, put a gateway router/fw in front for a parameter firewall and NAT your IP to internal networking IP. Make sure your parameter gateway is set to not allow access incoming or outgoing to private IP classes ex: 172.0, 192.0, 10.0, send your gateway logs to an internal machine. For this I prefer monowall. While I realize this is more network security than server administration/security, they do truly go hand in hand.

Compile the lastest version of open source tripwire. They are working on it again. You can get it at freshmeat/sourceforge.net. Configure tripwire correctly before tripwire --init. Llearn the prompt commands to properly run it, make sure it's set for cron and emails sent to admin on a daily basis.
a) Install an anti intrusion detection system and learn it. I use snort although it has too many false positives.
b) Install a log sifter. Or a logwatch mechanism. Logwatch will do fine. Configure and learn it. Have emails sent to you on a daily basis to an offsite location.
c) Install either rkhunter or chkrootkit and set if for cron. Rkhunter creates a small database with known good on the /etc/passwd and other important data, if anything has changed when you run it, it will be in red.
d) Get rid of any and all server panels you are running. Unless you are hosting 50 or more sites, dump the panels. No webmin, no cpanel, nothing... notta.... none. I cannot express enough how much crap server panels are. They are a security threat the minute you install them. That and they take over your server by installing whatever the applications they want to. Not at all good for securely administrating a server. Most people install a Cpanel and have no clue what it's doing to the server. I know, I've been there and to this date I cannot tell you what the panels did actually did to the poor server except mess up a perfectly running operating system. Do your work from the prompt. Hosting 10 sites? no problem, you can do your dns, apache vhosts, mail, mysql administration etc.. from the prompt. You would be silly not to. It's much faster when you know what your doing.
e) Choose your distrobution wisely. Debian, slackware, etc... need be learned. You can use a redhat distro anyday if you choose, start with compiling a custom kernel on Debian or Slack so you can get the feel for it. You might even setup a FreeBSD box to mess around on. It's an excellent operating system and I do prefer it over Linux. If you still choose to rpm it and run your site off redhat, hey I'm ok with it. No problem. You will however miss apt and the non-bloated slim and trim operating system. That's a promise. Besides, you don't need "chkconfig" or "service whatever restart". You can do a /etc/init.d/whatever start stop restart. You need to learn the boot up process, it's runlevels, and how init scripts work so you can modify what you need as you go. Linux maintenance runlevel is a must to perform lower level file system and other types of maintenance. It need be learned.
f) NEVER RUN X ON A SERVER. If you have to have a desktop to administrate, you are not administrating. This is an uneeded security risk. If I mention to not run panels, you surely wouldn't run a desktop.
g) Use ssh for both telnet replacement as well as sftp file maintenance. SSh can be accessed at the sublevel and allow a secure
ftp connection. No reason to use FTP or Telnet. None. Everytime you telnet or ftp into the server you are sending your password in
broad open unencrypted text format. You ask to be cracked.
h) Disable ssh root login. You don't need it. su -l root and work from there.
i) Alter your .bashrc with the following to report any logins to any account on the box. ex:

echo 'ALERT - Root Shell Access on:' `date` `who` | mail -s "Alert: Root Access from `who | awk '{print $6}'`" me@myoffsiteemailaddress.com

This mails the administrator the IP of each login and informs them of the event.

=========
This is just a simple and very broad overview with some suggestions. There are many documents available on the web concerning server security and administration. Depending upon your linux knowledge, you will succeed in some areas and fail in others as you learn. Look up security documents based on your linux distribution and couple that knowledge with standard linux security measures such as kernel security modules etc... The kernel itself must be watched continually for updates and vulnerabilities. Security pretty much starts here in terms of the linux server. Of course none of this will matter if you are administrating your server from a windows box with every known service running in the background. Crackers do as anyone else would, take the path of least resistance. A cracker will pick the locks on your windows box to see what they can have and show you how to administrate your server for you from there. Learn the adminsitration of windows if you choose to use it. The services and the security of windows is just as important on the client side. Turn off uneeded services in the control panel and keep your winbox up2date. If possible put your client machines behind a gateway/fw to access your server and and promote your client side security first and foremost.

Always remember this... It's not knowing it all, it's knowing where to look. Be sure to document all the pages that you study and burn them to cd. Get a txt directory going for all your quick lookups for what you forget. If you are serious about server, networking, or TCP/IP protocol security of anykind, you should have a minimum of a couple hundred security text documents at your disposal.

A book or two on bind administration/security alone is a must if you run your own DNS servers. Such issues such as dns pollution need be understood. Understanding the process of DNS need be understood. You need a broad understanding of BIND "before" you administrate it on a live server. Undstanding SQL injection need be understood.  My suggestion for DNS is let the datacenter host it, that or outsource it unless you are hosting 50 sites. Seriously DNS hosting isn't worth the hassle for 10 sites. Your datacenter will have no issues hosting your DNS for you.

Each open port and application layers you administrate requires time, diligence, and understanding. This is not achieved overnight. It's a continual learning process just as security is achieved in layers and accomplished by working on it daily and keeping up with the latest vulnerabilities. Once you have a grip on linux security in terms of setup and configuration, and you have a grip on the top level hosting apps, it's time to learn how to tweak for performance. Apache, Mysql, PHP, Mail, and Linux itself has many facets of configuration that need be tweaked for performance.

I order these books mentioned through O'Reilly most of the time.

Excellent Topic !!!!!!!!

One small correction to this, read is (4), write is (2), and execute is (1).  Hence, 4+2 = 6 = read / write.  I imagine this is just a typo, but, thought it would be a good idea to clarify. 

up