Our good friend "admin" posted this rather important article about Phishing sites taking advantage of the /.well-known/ directory that is used by the ACME protocols. While the article does suggest a change to the nature of the /.well-known/ directory, it doesn't talk about fixing the root cause of this issue.
These phishing sites are set-up, generally, by outsiders that have found a way to gain write access to the system and using that ability to drop their phishing site code.
This is often very easy to do because many web sites are set-up such that the content directories are writable by the web server user. Thus any weakness that allows a remote-write to happen give the hacker easy access to write to the content directories.
Likewise, many of us who make use of the ACME protocol don't want to run those scripts as 'root' and instead make the logical choice of going with our web server user account. Although simple, this is not a very secure option.
Many of the simplest of remote content dumping attacks can be avoided by preventing the system account(s) that serve the pages from having write access to the content directories. It is a bit more work to set-up but a lot more secure.
The 'apache' or 'webserver' account can be used to run the web server but should have read-only access to the document root and all sub-directories. It may be provided write access to a small subset of directories outside the document root for storing cookie files and other activities.
If server side scripts (php, perl, phyton, etc.) are used, run them under fast-cgi and use the fast-cgi feature of giving them their own system account. This account should not be able to write to directories in the document root either. If they have to write to the file system, write your code so that they store their data outside the document root.
The acme script can, and should, be treated the same way. It should have it's own user. That user has write access to a directory outside the document root. Aliases in the web server can be used for the specific files/directories needed by the acme protocol script. One could even consider putting a wrapper around the acme script (run by root) that change permissions restrict write access by the acme system account to only those times when it is running. We have the ability to run scripts as root that spawn scripts as other system accounts. We should use these tools.
The above won't stop your web server from being hacked and used as a phishing server. But it will make it more difficult for the attacker. Combining techniques such as above with good monitoring tools and alerting when suspicious activity occurs on your server can give you enough time to respond and block the attack before damage is done.
What are your thoughts?
These phishing sites are set-up, generally, by outsiders that have found a way to gain write access to the system and using that ability to drop their phishing site code.
This is often very easy to do because many web sites are set-up such that the content directories are writable by the web server user. Thus any weakness that allows a remote-write to happen give the hacker easy access to write to the content directories.
Likewise, many of us who make use of the ACME protocol don't want to run those scripts as 'root' and instead make the logical choice of going with our web server user account. Although simple, this is not a very secure option.
Many of the simplest of remote content dumping attacks can be avoided by preventing the system account(s) that serve the pages from having write access to the content directories. It is a bit more work to set-up but a lot more secure.
The 'apache' or 'webserver' account can be used to run the web server but should have read-only access to the document root and all sub-directories. It may be provided write access to a small subset of directories outside the document root for storing cookie files and other activities.
If server side scripts (php, perl, phyton, etc.) are used, run them under fast-cgi and use the fast-cgi feature of giving them their own system account. This account should not be able to write to directories in the document root either. If they have to write to the file system, write your code so that they store their data outside the document root.
The acme script can, and should, be treated the same way. It should have it's own user. That user has write access to a directory outside the document root. Aliases in the web server can be used for the specific files/directories needed by the acme protocol script. One could even consider putting a wrapper around the acme script (run by root) that change permissions restrict write access by the acme system account to only those times when it is running. We have the ability to run scripts as root that spawn scripts as other system accounts. We should use these tools.
The above won't stop your web server from being hacked and used as a phishing server. But it will make it more difficult for the attacker. Combining techniques such as above with good monitoring tools and alerting when suspicious activity occurs on your server can give you enough time to respond and block the attack before damage is done.
What are your thoughts?
