Support

Akeeba Backup for Joomla!

#30589 – Zip vs jpa backups virus scans

Posted in ‘Akeeba Backup for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Monday, 26 November 2018 08:41 CST
Please look at the bottom of this page (under Support Policy Summary) for our support policy summary, containing important information regarding our working hours and our support policy. Thank you!

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

I specifically got this to backup my sites hosted on SiteGround and sync them via cloud storage to my home server to scan for viruses as a service to my clients. I wanted to use the jpa format but it appears my virus scanner cannot scan them but can scan a zip file. I would like to use them for restore if needed in case of any issues.

1. Is there a virus scanner that can scan this format you know of?
2. Can the zip be converted to jpa if needed?
3. How problematic is a restore with a zip vs jpa?

Thank you.
Custom Fields
Joomla! version (in x.y.z format)
3.9.0
PHP version (in x.y.z format)
7.1
Akeeba Backup version (x.y.z format)
6.3.1
Edited by DaveOzric on 2018-11-26 14:41
 
Monday, 26 November 2018 09:00 CST
JPA is a format specific to Akeeba Backup. To the best of my knowledge there is no virus scanner which would bother opening it. You can always back up to the ZIP file format.

Please note that the ZIP file format has a restriction when backing up, not when restoring. The ZIP format requires the calculation of CRC32 checksums for every file included in the archive. We try to do that using PHP's hash extension. In the very few servers where this is not available we would normally have to load every file in memory, calculate the CRC32 checksum and then proceed to backing up the file. With files larger than 1MB this would cause the PHP memory to run out and the backup would fail. In those servers and for these larger files we instead use a fake CRC32 checksum of 000000. This will be reported as a CRC checksum error or broken ZIP error by archive extraction tools but, in fact, the archive is just fine. Besides that there is no other concern using ZIP files.

I would like to point out that running a virus scanner against a .php file is an exercise in futility. These files are source code. Essentially the virus scanner would have to derive intent reading prose. This is just not possible with the current level of technology known to the mankind. At best you will get a report about which files you should take a second look at based on patterns which are commonly but not exclusively used by malicious software. I can tell you upfront that several files of Joomla! and Akeeba Backup itself will appear as suspect because they are performing low-level functionality, using the more rarely used PHP functions which are also used by malicious software (since that also performs low-level functionality). That is to say, seeing a "virus" report on .php files does not mean with absolute certainty that there is a problem. It only means "you need to have an experienced human developer look at the file and figure out the intent of that code". FYI this is the same thing we do with the Threat Score in Admin Tools' PHP File Change Scanner.




Nicholas K. Dionysopoulos


Lead Developer and Director






Greek: native


English: excellent


French: basic






Please keep in mind my timezone and cultural differences when reading my replies. Thank you!






Monday, 26 November 2018 09:27 CST
That's interesting. I wonder what can scan these backups more effectively than a desktop virus program? There must be something that can do this?

How is it a infected website is detected by the antivirus I use but a scan of the files won't show the infection?
 
Tuesday, 27 November 2018 01:10 CST
Please read again my previous reply. You are missing the point. What I am saying is that any antivirus, malware scanner, whatever-marketing-calls-it is NOT 100% accurate. It simply cannot be. Even if you get 99% accuracy (which is unrealistic; most antivirus go up to 98% for binary executables, far less for source code) it means that 1 of 100 files will be either a false positive or a false negative. On a typical Joomla! site you have about 5000 files. You can do the math.

So, yes, most hacked sites will be reported as such.

Some not hacked sites will be reported hacked as well (false positive); you should not trust that as an absolute truth, you should investigate further. The best thing you can do is compare those files to a known good state.

Some hacked sites will be reported as not hacked (false negative). I've seen a very ingenuous hacking script which posed as a legitimate Joomla! file, followed the Joomla! coding standard, had comments even, but had a malicious intent hidden as a subtle bug in one of the legitimate-looking methods. At first glance something bothered me. When I read the code again I did a double take. That file was designed to let an attacker execute arbitrary commands remotely.

Both false positives and false negatives can be caught more easily using Admin Tools' PHP File Change Scanner. Please read its documentation on reading the reports (especially what I've written under Threat Score). If you see a .php file popping up without having installed an update an alarm bell should be going off; this is usually a sign of malicious activity. If you see a .php file being added or modified exactly after an update you can mark it as safe even if it registers a very high threat score; it's obviously a false positive since it only got created/modified right after an update you initiated yourself.

If that's too much work (it is; I'll give you that) you can still rely on scanning your sites with an antivirus. You should just be aware of the possibility of false positives which spook you for no good reasons and the far less likely but much more serious possibility of false negatives.

I like car analogies (my degree is in Mechanical Engineering) so let me put it this way. The antivirus is seatbelt and airbag. It will protect you in case of a minor to medium severity crash. The airbag may also deploy on a small crash when it really isn't necessary and cause minor injuries you can laugh about after a quick visit to A&E. The PHP File Change Scanner is installing a roll cage and putting on a five-point harness, helmet and Nomex clothing. It will protect you even in some of the most scary crashes at the expense of being a serious pain in the posterior. There are some cases where you still get seriously injured and/or die. Thankfully, unlike real life, you can resurrect i.e. restore your site from a backup -- which is why having frequent, automated, off-site backups is very important.




Nicholas K. Dionysopoulos


Lead Developer and Director






Greek: native


English: excellent


French: basic






Please keep in mind my timezone and cultural differences when reading my replies. Thank you!






Tuesday, 27 November 2018 10:22 CST
Thanks again for some more details. I am not expecting anything perfect. I do backup 6 months of weekly site copies but need to do this on my SiteGround hosting accounts too. I'll use zip and scan like I am now. And yes doing a php file scan is not going to happen.

Thanks for your help.
 
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.