Joomla! Discussion Forums

Wow 

Great, hard, very useful, top-grade, work done there

Am bookmarking it for all further reference.

Congrats !

My hats off to you rliskey, that really is a great compilation and I plan to read up on it as well as refer back to it often.  It's the best I've seen yet.  This definitely makes it easier on me (and the community I'm sure)

Thanks for the kudos, but I really have to say that RobS did the real work of compiling all that info. All I did was copy his collection into the FAQs.

The following item was added under: 5. Installing, Upgrading, and Configuring Joomla! Core and Apache Server

Maybe an advice to upgrade to new PHP-Version 5.2.0 which has an option to enable url includes and is off by default. So it is no more possible to include files from the net which is very often unwanted behaviour.

The following password tidbit was added...

• Never use the same id/password in more than one critical location. For example, don't use the same password for your Joomla! site and your DNS registration.

Added this to the FAQ: http://forum.joomla.org/index.php/topic,110987

yup...very good point. i would be more specific...not only same location, but also same server...you don't want somebody seeing your configuration.php file and seeing your SQL password in cleartext there, to have full CPANNEL/Plesk/console or root access...

e.g.:

• Never use the same id/password in more than one critical location and usage. For example, don't use the same password for your Joomla! site and your DNS registration. Also use different passwords on your server: e.g. different passwords for your control panel/ftp access, SQL database, and Joomla administrator account (change also the username from default "admin" to something more personal.

Every now and then I hear from people who say they can't understand the checklist. To better understand why the information is too confusing, I've added the following. Let the flood begin...

I may get flamed for this and maybe I deserve it....LOL

I am not a big fan of telling people to have 10 different passwords they use...
Neither am I a fan of changing these passwords often. Changing on a monthly basis is not really effective as any brute forcing of the password won't take that long. Unless you were changing it on a weekly basis it's effectiveness is limited.

I tell users that they should have no more than 3 levels of Passwords and webmasters no more than 5! And each level must be completely unrelated to the others in terms of what is used.

Level 5 - is the password you use on public sites. It is not imperative that you use a different password on every site. In Fact it's more effective to use a different username on every site than it is to use a different password truth be told! Knowing the username allows easy hacking...half the work is done! knowing the password is useless unless you know what account it goes to!

Level 4 (Webmaster) - Reserved for SQL Only. this is a password that would only be used by SQL and limited to a specific database in SQL. The best way to protect SQL is by limiting each account to just being able to do the minimum that DB requires. In some cases it is even wise to have a read only account for display and a seperate write account that the backend write functions use. But that doesn't apply to J! at all... for J! the best practice is to set up an individual account (not root for sure) that only has read and write access to the J! DB nothing else.

Level 3 (Webmaster) - FTP and Server Access. these can be the same user:pass combo since both if compromised can do the most damage. doesn't matter if the backend or Cpanel is safe if the FTP is not and the same goes the other way!

Level 2 - Personal Data Access. this password should be used for any sites or locations that contain personal data with the exception of Banking (see level 1). these sites are often used for social engineering data such as medical records, service accounts and any financial records not directly related to banking! You want these to be secure but also different from the real threat of security...your money!

Level 1 - Banking! this needs to be the most secure in fact if you have two different banks it actually pays to have a different user:pass for each just to be sure!

Ok that was a bit off topic but it does explain a bit about how webmasters should compartmentalize their security.

Here's your official flame: I LIKE IT! 

I copied your post to the Security FAQ section and will link to it from the checklist. Thanks Asphyx!

I guess there's room for many password protection schemes on this crazy, beautiful, lonely, confused planet. Selecting the one perfect scheme will probably always be a moving target. Your scheme makes great sense to me. I'm converted!

LOL and thanks!

Just one edit to make on Level 3...Should read Server Admin Access which would encompass, CPanel, FTP, SQL Root and Backend.

I think the main point I expected to get flamed for was the not changing the passwords on a regular basis.
The theory of making passwords a moving target seems logical but in my experience I have found that people tend to use less secure passwords as time goes on. And what might be a really good password (as in hard to hack or guess) might get changed to something less secure simply because you forced them to change....

And it is importortant to note that forgetting passwords can do more to expose them than any other activity. If some site or server needs to email you your password it is easy for someone to intercept that un-encrypted notification...

But the bottomline of good security isn't really a function of password. It starts with good account settings and management. By limiting accounts you limit the damage any hacked password might do. That is where the real challenge lies.

Keeping passwords safe is nothing more than a matter of restriting the amount of data you give a potential hacker to hack with...
As I said knowing a password doesn't work if you don't know the account. And even knowing an account it is hard to crack if you don't really know how many places are in the password. Is it a 5 character pass or 10? they have to try every combination.

the only REAL NO-NO as far as passwords are concerned is in using a simple word as your pass!
this allows the dictionary hack which is much faster than any brute force attack!
A combination of letters and numbers (even symbols like parenths and #) will thwart any attempt at a dictionary hack.
It can still be done via Brute Force but the amount of time it takes to run such a hack means they really won't bother unless there is a very big payoff at the end!

They simply won't bother if there isn't!

You can't make it 100% secure ever but you can make it hard enough so that it isn't worth the effort!

To be sure the checklist meets as many people's needs as possible, I added a poll where you can choose from the following. Please vote early and often. Note, that you can change your vote as the checklist evolves and your opinions age. 

• too basic
• about right
• too techncial

http://forum.joomla.org/index.php/topic ... #msg415762

This is really good stuff.
And makes good reading.

I started making up passwords in my head ( and recording them of course ) but it's a pain for long passwords. So now I use a couple of password generators:
https://www.grc.com/passwords.htm
http://www.rochen.com/passwordgenerator.php

Lord knows which is better but I reckon that 16 character passwords from either are good enough.

Keep up the good work.

Nick

Another thing i've been meaning to post about.

rliskey says:

Could someone explain why that is such a good thing and why so many extensions don't seem to support doing it.

Nick

I think this is a great question. I reworked my original answer, included suggestions from others, and moved it to:
Security FAQ: Isn't locating all Joomla! files inside public_html a security risk?

Part of the problem is that there are a lot of programers who don't totally understand Server Security either...Not the case with J! and not even the case with many of the 3PDs who do good work for J!

And there is a slight problem in that how a server security is set up changes from server to server.
Add to it how many people run on shared servers and you really have a bit of a mess in how best to do security because to give apache privs means you could be giving it to anyone else who runs a site on that server as well!

Much of these issues will go away once 1.5 is final as you can set Apache (php and therefore Joomla!) to be able to write as the FTP account and therefore the OWNER!
you can shut off read write and execute for just about everyone else once that happens and simply limit access to the owner account.

Most if not all of the files in a standard Joomla setup don't even need to be readable by the public!
Since most calls to any php file comes from J!'s index.php (in the web root) It can easily read these files for the user making it unneccesary to make them world readable! The onloy publicly readable files and folders would be index.php in the root and the images files and folders!

But only if J! is operating as the owner of the files....
because until now there was no way other than suexec to make that happen you had to make the files readable to at least a group that apache was a member of. And since most users don't have the ability to create their own groups they were forced to keep files world readable so that apache could see them too!
Only folders like the images folder must be readable to the general public. and those must be locked down as tight as possible to ensure that no one but the owner can write to them.

The danger isn't so much in the writeable aspect of folders...You can write malware to a drive all day but it is useless unless it is executable (or readable in the case of PHP).

This is why any folder that you have that is world writeable must NOT also be world readable! If it is they can write the malware and then have the server read that file and or execute it they can compromise your security!
It works just as well to make a writeable but unreadable folder in the public space as it does to place it above the public space...it is the same concept really but adds a bit of bakground code to chache the file and save it to the proper location...you can't just FTP there since it is outside the filesystem...


this is the concept behind placing writeable folders above the public space and instead using abpath in your application so that PHP can see and police how the file is used!

By doing that even if they write a bad PHP file there... unless the PHP that calls to it as an include, it can't do any damage!

IE say you have a gallery....
you have users upload pictures...
Someone uploads a PHP instead of a jpg...
the gallery app that calls to the file only has code to show a picture... not php...the file will not run.

And if they can't see the file without going through that gallery app the hack attempt won't work.

So yes more 3PDs should try and protect any folder that needs to be writeable (and very often most do!)
J! 1.5 and it's FTP Layer will help make the job much easier for them.

Because you can leep the tight security and retain the functionality at the same time now.
And that will allow us to shut down world readable and world writeable without hurting any functionality.

It will also get rid of the constant problem of the server creating files on install of extentions that can't be written to by FTP because FTP doesn't own them...

they key to good security is really a fight to just give access to as little and minimum of what the user needs to read to get the product!

And with FTP layer and better use of AbPaths by 3PDs we can really lock things down and only need to worry about the few backdoors in PHP that can be exploited!

OK, let's see if I understand this.

What you are both saying is something like this:

• How things are in 1.x is historical rather than designed for security.
• 1.x can be made fairly secure but only if:
  
  • Every php file has the right magic incantations at the top.
  • php files aren't owned by the Apache process.
  • All files except cache and a small number of others is 644.
  • Things like making administrator password protected are done.
  • Usernames and passwords are chosen carefully.
  • Etc.
• 1.5 is designed so that more of J! can be outside web root and thus those parts can't be directly exploited.
• Having writable directories outside web root means that any files written there can't be exploited because they can't be directly accessed from a browser.

I got a bit lost about why having Joomla! write files as the FTP user AKA the owner is a GOOD THING apart from the obvious that one doesn't have to keep changing the owner back from the Apache user.

What else have I not understood?

Nick

This is a really nice password generator and tracker program I've been using for quite awhile now. It's Open Source.

http://keepass.sourceforge.net/ KeePass Password Safe

That looks interesting. I will give it a try I have loads of passwords to keep track of.

Nick

Incorrect! How things are in 1.0.x is historical only in the sense that it was based on legacy code written with a 1999 mindset. Both in terms of security AND functionality. Server security is really a seperate issue than PHP Security. Where the security was compromised was usually at the user level end because they either didn't have the tools the knowledge to set up their webspace and set the permissions in a secure way. Basically what I'm saying applies to users on shared and rented servers.
If you own your own server and have access to all the security tools of that server it is easy to lock down Joomla from attack as far as permissions go without hurting functionality. If every user was on his own server that he had full control of the only security issue would be specific PHP exploits that trick PHP into doing something you don't want it to do!



This is true for any PHP program and not specific to Joomla!



FALSE! Apache can securely own the files in fact it works better when it does! This is only an issue non shared servers since you need to seperate YOUR instance of apache from the other users! This is what the FTP Layer of 1.5 does!


True! but what we are actually saying is that any catchall chmod number is going to miss something! You have to be very specific for each folder involved when setting the proper chmod to use! and it will change depending on owner/group/world set up on each server! You could easily set up Apache and FTP into a group if you had a dedicated server and chmod 664 which would do the same under 1.0.X that 1.5 will give you with it's FTP layer!


Any extra hoop you make a hacker jump through will deter or delay any entry and give you a way to detect that attempt in progress!


This is true for all password protection schemes it is not Joomla Specific.


Well no...as I was trying to convey was there is no need to put things outside the web root at all. Not if you have a system set up with proper permissions for each folder. It was problematical to get there under 1.0.X simply because you had two different accounts trying to write to files and folders but 1.5 simply added a feature that allows you to set both to use the same account!
So now you can set the owner to be the only account with power to write (and if you wanted for many files even remove public read) becuase both J! (apache) and FTP are now acting as a single user!


Half correct....where it is is irrelevant! a write only folder in the root is just as unreadable as a write only folder above the root! The only difference is that apache can't access a file above the root on it's own! It will require some programming (and lots of it) to find and deal with any file it might find there and also police how that file is used!
This "Above the root" is more of a historical concept of securing. The issue isn't where it is the REAL issue is who has the right to do something in it? One user? (Owner) Two or more users (group)? or everyone?
You can just as easily make a folder inside the root that is readable by the public and only writeable by the owner and add your file policing code to the upload system. By limiting uploads to jpg and gif there is no way a php can get on the system! and even if they rename a php file to gif since they can not rename the file (which requires write privs) PHP will never parse it as a PHP!



I touched on this above....
The most secure way of setting security is to limit what can be done to a single account!
the only security setting for a single account is OWNER! that means chmod 6##. the first number will be assigned to both FTP account and (your instance of) apache which means only YOU (via FTP) and YOUR install of Joomla will have the proper security account to do anything that could hurt your system. The other can be locked down tight so that the only way to write to a file or folder is as the owner! Now since one chmod number defines both accounts that need ownership you can shut off all the stuff the public does not need to see via permissions...that means you should technically be able to chmod 600 a good chunk of the filesystem and keep a writeable (by owner) folder readable to everyone else as you would do for the images folder!

The issue is that currently the first number in chmod sets permissions for the FTP account and you need to set another chmod number so that Joomla can do things in folders it is not the owner!

there are many ways around the problem under 1.0.x, but it depends on the server you are using...

If you are the only one on the server:
1 - Set Apache to owner of the entire web root. Since your instance of apache will be the only one on that server you will be relatively secure with only the usual PHP exploit as a potential hole (which is going to be there no matter what you do!)
2 - Leave FTP the owner but add the WWW group (varies from server to server) and set chmod 66X so that there are now two users who you can set permissions for while leaving everyone else locked down
3 - use suexec which acts similarly to the FTP layer in that Apache acts as a specific user for that instance and again allows you to lock down the everyone account!

If you are on a shared server it becomes much more difficult as many ISPs will not be willing to go that extra mile to give you a custom apache, PHP and user account settings needed for the fine tuning of good security! But it is possible....
1 - You should have access (via FTP, Shell or CPANEL) to the following:

• httpd or virtualdomain.conf
• php.ini
• suexec

2 - set suexec so that your instance of apache uses your FTP account to do file system business
3 - set PHP for proper security as advised by the devs in regards to J! security
4 - as on the dedicated server set chmod appropriatly so that only one account can do something dangerous!




I think your concentrating too much on the location of the files which is irrelevant. What is important is what you set in chmod and how you CAN set it for best security and lockdown.
You must fine tune read and write permissions for each folder and to do that you have to find a way to rip the permissions you need for Joomla to work from the EVERYONE (3rd number) of chmod and put them in either of the first two numbers of that setting!

The way to do that is to either assign it to owner or group. But before you can do that you also have to make sure that no other apache instance on that system (that is not in your control) can mess with your space!

this is problematical for users in a shared rented enviornment but quite easy for those of us with a dedicated or owned server.

In a shared eviornment you probably have not been given all the tools needed to accomplish this yourself...J! 1.5 attempts to put some of this control back into your hands by allowing you to define apache as the owner without making every instance of apache as owner of YOUR FILES!

If you own your own server you can easily make the setting changes to completly lock down J! filesystem from attack...
Simply make Apache owner or group or configure it to use the owner account (as J! 1.5 does for everyone!)

And here is a little tutorial on chmod and what it means....

command syntax
chmod ###

significance of each number
chmode OGE O=Owner G=Group E=Everyone else

each number O,G and E represent a binary code for what can be done....
rwe    stands for Read Write Execute
000 0 - No access at all
001 1 - Execute access only
010 2 - Write Access only
011 3 - Write and Execute
100 4 - Read Only
101 5 - Read and Execute
110 6 - Read and Write
111 7 - Read Write and Execute

the suggested chmod 644 means the owner can read and write, Group and Everyone can only read!
This works well for things like images folder where you don't need to write a ton of policing code to show images. everyone can read these files but no one can write to them!
If J! (apache) is not the owner of this folder it can't write to this folder either...Many users set writeable to everyone which is a catch all and allows everyone to write leaving a major hole in security. By making Apache the owner somehow you can shut off write access to everyone and you are safe!

I've gotten a bit long here so I'll stop and try to answer any questions you may have after this.

Asphyx I am beginning to wish that I had never asked.

I have just read you post about three times and now have steam coming out of my ears.

35 years of software development seems to be either not long enough or far, far too long.

I will read it again tomorrow before commenting further.

Nick

LOL....

I'll try to simplify it via analogy...

You have a bank....there are many places to keep money in a bank...
There is the main vault which only the bank manager has the key to...he is the OWNER Only the manager or owner can take money out or put money in...you have to have their permission!

There are the different teller locations all behind a high bullet proof wall with money in it as well...This is the GROUP space...The owner selects a few trusted people to be part of the group that says who gets and who does not get money!

Then there is the Night deposit box which will allow you to put money in but not take any out! (this would be the world writeable no read space!)

The key to good security is to allow people to upload (deposit) what is needed without letting them utilize that data (money) without going through your teller (which in this case would be a PHP APP...

And it doesn't matter if the teller's cash drawer is right in front of them or way back in a spot where no public is allowed to see...you can't get at it until someone says ok here it is! The teller has read privs on their drawer and determines how and what circumstances that money is given out!

By making a writeable folder unreadable there is no need to place it above the root cause in essence it isn't in the public root anymore the second you shut off read access for the general public to it! It's in the same container of the public root but it is not a public folder anymore! there is no real advantage to placing it above the public space because now you have to write a ton of extra code to deal with the fact it is not URL accessible in either relative or absolute form.

By keeping it in the public-html folder but shutting off public read permits you can target exactly who DOES have read permits and not bother with all the extra code...Just make sure that the ONLY account that can read it is apache and no one will be able to see that file unless apache retrieves it for them!


To put it above the root adds some chores to the programming...

1 - Upload - your PHP now has to cache the file and then save it via AbPath. How much code is required to do all that?
2 - retrieval - you have to create code to read files via abpath again extra code to replace what would be a simple URL

whereas the other way you simply:
1 - Upload - users use any standard FTP method for sending the file to the url accessible folder
2 - Retrieval - Simply have PHP read the URL and if it doesn't conform to an img tag it won't display!

No need to create a ton more work to do something you can just as easily do and just as securely by using the chmod settings properly!

set write only privs for everyone so they can upload.
Set read write privs for Owner or group which is or includes apache as a member...

And if the enviornment is shared then you have to use the owner setting only to limit the permissions and that is why the FTP Layer is the way to go!

IT's confusing because there are many different situations that can be encountered...

You have users who own their own server and have complete control over...(Easiest to secure)
You have users who have a dedicated server but no access to the OS...(a little bit harder that above but still quite easy to secure because of the rediuced access to the box
Then you have the majority of users who are on shared rented server who have no real access to the OS, no real access to even the minimal configurations needed to make a box secure and literally 50 other people they can't trust not to screw up their site because they don't know them!

They are all using the same apache!
so you have to distinguish YOUR apache code from theirs!
which is where the FTP layer comes in...

in regards to configuration files again it is only Apache or PHP that actually needs to be able to read them!
Configuration.php if owned or group read by apache has no reason to be public readable!
No need to put that above the root simply shut off read access to everyone but apache and FTP...

How you skin that cat has many solutions...
which one you use depends on the situation your server exists in and how easy is it to define your instance of apache from everyone else's!

What do you think about data corruption? I think at least a weekly hard backup is a good way to have a fallback. E.g. a hacker corrupts the data validity.

It really depends on your site how often to backup...

If you don't register users, and only update content once a month then a monthly backup is just fine!
The files never change so making a backup after any install is just fine...
I suggest a two teir backup system for files...

One folder called backup and another called current.
When your about to install an extention or patch you copy the entire file system to the backup folder...(you should make a DB backup as well and save it to this folder)
Then do your install and test. If there are no problems then copy the entire file system to the Current folder...(again save the DB with it's new table structure if any to the current folder)
Now you have a way to go back to a pre patch(install) state and a backup that you can use to restore the file system until you install something new...

This method gives you two level undo capability and eases the backup requirements since all you need to backup is the DB...

How often you need to do that depends on how often that DB might change....
No user regs and you only need to backup once per article posting.
If you register users then once a week is probably best.
Same for weekly updates....Unless you want to save a text of the articles locally for a month so you can restore them in case of corruption.

I do a weekly backup myself. And if you have a very large DB you can do an incremental backup...
Do a full backup of the DB once a month and an incremental backup of the user and article tables on a weekly basis.
but thats where the meat of your data is anyway....So you might as well just do a full and delete old backups once a month....



I think a daily backup is way overkill personally...Obviously it is a bit more important for a commerce site than a normal site as you don't want to lose orders to a bad DB...and the high activity means much greater chance of corruption.

No need to waste bandwidth alotment just to backup thyough....simply back it up to the server! It's cheaper to buy more drive space than it is to buy more bandwidth!

The other alternative is to set up a master slave replication setup where the slave writes data to the master and the master replicates to the slave. This is the way most corporate sites do things especially in commerce where they do much more with the data than simply spit it out via the web. With this system you can even use the data from the master in an accounting program and inventory software.
This data will be protected since it doesn't need the web to operate it runs locally to the master server.

I think the main advantages to keeping sensitive files outside of public_html are conceptual and organizational. It's a lot easier to maintain a complex system with already enough to worry about if you have one and only one clearly defined directory that is world accessible through the Web server. Then you only have one hole in your system opened via the Web server to the world. If you keep all your Web accessible files there, and not in other places, it's much easier to troubleshoot possible problems. Why complicate things by mixing metaphores?

Yes, you can secure files inside public_html, but why bother? It's just as easy to put each file in the place where it is appropriately protected by the system. Why put a file in public _http if it's not meant to be public?



I don't understand this point. There is no additional code to write, and less security tweaking to worry about. Absolute paths to any file on the system are coded in exactly the same way, such as:

Absolute path to a file in public_html:


Absolute path to a file outside of public_html


Relative paths are no harder. To reach secret_config.php from index.php in the above example, just add two dots and a slash to the path:


The above example assumes that secret_config.php is a file that the Web server needs access to, but that no user should be trying to browse. This is the suggested way to deal with such issues at Apache.org.

Well think about what it will mean to move a site when you do that...You no longer can get away with changing config.php after the move you also have to reconfigure any extentions that are using abpath to find files it needs...It may be more organized but it also means more work on the management of the data.



If it is a user writeable folder the data in it actually IS meant to be public. unless the user is uploading files that are not meant for use on the site at all which is not what we are talking about here...
Say a user wants to upload pictures for a gallery. which is the example we have been using.
Those pictures are meant to be readable to the users we are simply restricting HOW they read that file....
The files actually ARE readable to the owner (apache in this case) just not readable to the world.

What you say about sensitive files and data is correct but we are talking two different things here. I am talking about writeable folders which some components require so users can submit content the system will use.


Again that works for configs which are only read but not a gallery...There is extra code in tha backend....
You need to write the FTP routine that will save the file into a location the user can't see...
You have to write the code to parameter where the files go and are read from.
If you wanted to use a module you have more than one abpath per extention to maintain.
Basically your doing a lot more maintenance than you have to to get the same security.

If the Joomla filesystem followed the practice your suggesting it might make some sense. But then again if it did that there really would be no need for any of this...All configurations would already be above the public space

But I think the main difference in both schools of thought are in WHAT is public and what is not....

I agree that configs and files the public are never meant to read should be above the public space. The entire Joomla folder save the templates, index.php and images folder should be above the public space. But what I was referring to was public data that is submitted by the user....
We want the user to be able to submit either via FTP or some ftp system inside php...
This data is very much PUBLIC in the sense that they are writing it to the server with the intention of sharing it with the other users.
We only want to restrict them from uploading a PHP file and then quickly reading it...
Now you can do that by denying public read and adding code to the system that will read and restrict how that uploaded code is used. No matter which system you use that is a requirement.
Same work.
But by putting it above the public space you also add the code and maintenance of multiple abpaths for each instance of writeable folder...

What your suggesting is quite possible under 1.5 but was not under the 1.0.x system...
And it might be smart to look at the idea of putting all of the non public J! files above the public_html as well to keep configurations from private eyes.

as it stands what you say may be more secure, but at a cost of maintenance.
My method is just as secure for public data

We both agree on the secure config files though...
configuration.php should be the first thing we send above the public space though.
Maybe the administrator folder next!

v1.1 update: Added the following great tip by friesengeist:


Increase the security of the all-critical configuration.php file by moving it outside of public_html.
FAQ: How do I move confidental files outside of public_html?

Yes, I can see that there are pros and cons to each approach and that each approach can be made secure. It looks like it comes down to simple preference for which kinds of work we prefer.

To deal with the issue of tracking abs paths I would use one of the following methods. The first one seems very portable.

1.  $path_var = dirname( __FILE__ ) . '/../joomla.conf';

2. Add a variable to your configuation file for the secure directory:


A directory structure might be:

/home/my_account/public_html/index.php <-- public stuff
/home/my_account/secure_dir/                <-- secure stuff
/home/my_account/secure_dir/docman/
/home/my_account/secure_dir/gallery2/

That would be a fine addition to the core settings....

But you know this whole thing is a day late and a dollar short...LOL

1.5 makes it all irrelevent!

Instead of setting writeable privs for Joomla we will be setting READABLE status after a default chmod of 600! LOL
Installer would check for read privs for index.php and images and the rest can all be NO ACCEESS at all!
No better security than that! LOL