Malware
Quarantine
Quarantine is isolating a suspect file so it cannot run, while keeping it for review or restore. Nothing is deleted yet.
How it is measured
In practice it is a move plus a lock: the file goes to a restricted folder, loses execute permission, may be renamed or encrypted, and its original path and hash are logged. On a server, chmod 000 and moving it out of the web root are the basics.
Verify that it worked: request the old URL and expect a 404 or 403, check that no process has the file open, and confirm no scheduled job or include still references it. Record who quarantined it, when, and the hash.
Worked example
A scan on a recipe site flags /wp-content/uploads/2024/04/img_01.php. The admin moves it to /home/site/quarantine/ with permissions 000 and notes its SHA-256 in the ticket. The old URL now returns 404, but the access log shows 6 more POSTs to that path after the move.
The POSTs get 404 as expected. The admin then reads the logs backward and finds the first write came through a contact-form plugin, which is where the real fix goes. Quarantine stopped the file; it did not close the hole.
How it differs
A sandbox runs the file in a controlled setting so you can watch what it does. Quarantine keeps the file from running at all. You quarantine to stop harm now and sandbox to learn what the file is; a sample can sit in quarantine for months without anyone knowing what it does.
Common errors
Leaving the quarantined file inside the web root. Letting the folder stay executable. Quarantining without noting the original path, so a false positive cannot be restored. Assuming the problem is over once the file is isolated. Forgetting copies in backups.
In practice
Set up a quarantine directory outside the web root with locked permissions before you need it, and record hash, path, and time for every move. Review quarantined items weekly, restore false positives, and delete or archive confirmed malware once the entry point is fixed.