ULYSSIS documentation - User contributions [en]

Secure file permissions

2024-06-11T07:13:32Z

Arnodb:

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by others, because Apache reads these as its own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Home directory security ===

For the permissions mentioned above to fully work, it is important for the parent directories to have the correct permissions. Our system already gives your home directory the correct permissions for this. Other users cannot read your files, or even find out what files exist. Even in case you mistakingly give everyone every permission to one of your files, only you can access it, because others do not have permission to go into your home directory.

{{notice|Important|If you have any secret files in your www directory, it may be publicly accessible via your website! Therefore, please make sure any files you want to protect are not in the www directory.}}

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

Secure file permissions

2024-06-09T09:12:16Z

Arnodb:

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by other users, because Apache reads these as its own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Home directory security ===

For the permissions mentioned above to fully work, it is important for the parent directories to have the correct permissions. Our system already gives your home directory the correct permissions for this. Other users cannot read your files, or even find out what files exist. Even in case you mistakingly give everyone every permission to one of your files, only you can access it, because others do not have permission to go into your home directory.

{{notice|Important| If you have any secret files in your www directory, it may be publicly accessible via your website! Therefore, please make sure any files you want to protect are not in the www directory. }}

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

Secure file permissions

2024-06-09T09:10:55Z

Arnodb:

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by other users, because Apache reads these as it's own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Home directory security ===

For the permissions mentioned above to fully work, it is important for the parent directories to have the correct permissions. Our system already gives your home directory the correct permissions for this. Other users cannot read your files, or even find out what files exist. Even in case you mistakingly give everyone every permission to one of your files, only you can access it, because others do not have permission to go into your home directory.

{{notice|Important| If you have any secret files in your www directory, it may be publicly accessible via your website! Therefore, please make sure any files you want to protect are not in the www directory. }}

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

Secure file permissions

2024-06-07T21:34:07Z

Arnodb: /* Home directory security */

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by other users, because Apache reads these as it's own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

=== Home directory security ===

For the permissions mentioned above to fully work, it is important for the parent directories to have the correct permissions. Our system already gives your home directory the correct permissions for this. Other users cannot read your files, or even find out what files exist. Even in case you mistakingly give everyone every permission to one of your files, only you can access it, because others do not have permission to go into your home directory.

{{notice|Important| If you have any secret files in your www directory, it may be publicly accessible via your website! Therefore, please make sure any files you want to protect are not in the www directory. }}

Secure file permissions

2024-06-07T09:27:30Z

Arnodb: /* Home directory security */

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by other users, because Apache reads these as it's own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

=== Home directory security ===

For the permissions mentioned above to fully work, it is important for the parent directories to have the correct permissions. Our system already gives your home directory the correct permissions for this. Other users cannot read your files, or even find out what files exist. Even in case you mistakingly give everyone every permission to one of your files, only you can access it, because others do not have permission to go into your home directory.

{{notice|Important| If you any secret files into your www directory, it may be publicly accessible via your website! Therefore, please make sure any files you want to protect are not in the www directory. }}

Secure file permissions

2024-06-07T09:26:24Z

Arnodb:

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by other users, because Apache reads these as it's own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

=== Home directory security ===

For the permissions mentioned above to fully work, it is important for the parent directories to have the correct permissions. Our system already gives your home directory the correct permissions for this. Other users cannot read your files, or even find out what files exist. Even in case you mistakingly give everyone every permission to a file, only you can access it, because others do not have permission to go into your home directory.

{{notice|Important| If you any secret files into your www directory, it may be publicly accessible via your website! Therefore, please make sure any files you want to protect are not in the www directory. }}

Secure file permissions

2024-06-06T22:13:07Z

Arnodb:

PHP code is run with PHP-FPM as your ULYSSIS user. This means you can tighten up you website's security by denying other users the permission to read your PHP files. However, due to the way the Apache webserver works, it must be able to determine the existence of your PHP files. Non-PHP files in your www directory must remain readable by other users, because Apache reads these as it's own user.

=== Recommended permissions ===

* www directory (and other directories from where websites are served), including subdirectories: <code>0705/drwx---r-x</code>
* Static website files (css, images, html, ...): <code>0604/-rw----r--</code>
* Configuration files containing secrets/passwords: <code>0600/-rw-------</code>
* Other directories and files that are not part of a website: <code>0600/-rw-------</code> or <code>0700/-rwx------</code>

=== Securing configuration files containing secrets/passwords ===

If you have any files that you want to protect from the prying eyes of other users, such as API keys, first you need to ensure that the directory containing your important file, is not writeable by other users. This is easiest to do by creating a new directory, dedicated to housing your protected files. For this you can run <code>mkdir safe</code>, followed by <code>chmod 700 safe</code> and finally moving the file into the safe directory. Then you can make your file readable and writeable solely by you. To do this you run <code>chmod 600 safe/name_of_file</code>.

In Cyberduck, you can do this by making a new directory, right-clicking on it, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions so that for "Owner", all the boxes ("Read", "Write" and "Execute") are ticked and for "Group" and "Other", no boxes should be ticked. Next you can move the protected file into the safe directory. Once you go into the safe directory, you can then finish by right-clicking on the secret file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing database login info ===

Suppose you have a file called <code>config.php</code>, containing login information for your database. To secure this information, you can make it readable and writeable by only you, and nobody else using <code>chmod 600 config.php</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Config-php-dropdown.png]]

[[File:Config-php-permissions.png]]

=== Securing uploads directory ===

Also, if there are directories that you made writeable by others, e.g. an uploads folder, this is no longer necessary. If this directory is called <code>uploads</code>, you can remove write rights for others with <code>chmod go-w uploads</code>. In Cyberduck, you can do this by right-clicking on the config file, clicking on "Info", clicking on the "Permissions" tab, and changing the permissions according to the following screenshots:

[[File:Uploads-dropdown.png]]

[[File:Uploads-permissions.png]]

[[Category:Files]]

[[Category:Security & anti-spam]]

Getting SSL/TLS

2022-04-09T21:43:50Z

Arnodb: /* Generating certificates */

ULYSSIS does not sell or offer any other SSL certificates than our self-signed certificate. We will however guide requests and install a certificate from the KU Leuven is you are eligible for one, and we will also install certificates you have bought or obtained elsewhere.

==Requesting SSL from the KU Leuven==

The KU Leuven partners with other universities through TERENA/Géant to arrange certificates for its services, organisations and academic structures. We have permission to request free SSL/TLS certificates for student unions (kringen) recognized by LOKO or faculty consultative bodies (facultaire overlegorganen) recognized by Studentenraad KU Leuven as well as organisations (vrije verenigingen) recognized by LOKO or KU Leuven. We are not eligible to request SSL/TLS certificates for individuals with a personal account, nor research groups or staff associations. We suggest those latter groups request certificates from KU Leuven ICTS directly or consider Let's Encrypt or another third party service.

Before sending us a request, the following steps have to be performed:
* Set up the site that needs SSL if that's not already the case
* Make sure our nameservers are being used for the involved domain(s), as explained on [[Adding domain names]]
* Consider all subdomains (whether separate websites or not) you wish to have certificates for
* Make a list of all relevant arguments for your use of SSL/TLS certificates. It's important to consider aspects of your website where important or personal information is exchanged: registration, login pages, newsletter signup, etc.

When '''all''' steps are done, the account holder of the ULYSSIS account can send an email to ulyssis@ulyssis.org containing their name, the name of the organisation, the relevant arguments what you will use SSL for and the domain and if needed a list of subdomains that should be covered by the certificate.

Based on our previous experience and our arrangements with ICTS we will consider whether you are eligible for certificates and whether your request is well-founded. We will then generate the required cryptographic key and request and submit them on the certificate platform supplied by ICTS and its partners. Depending on the situation, the verification and delivery of the certificate can take some time. As soon as the certificate has been issued, we will install it and notify you.

For procedures to request certificates, we follow instructions from ICTS. These instructions have changed several times in the past, so it's possible for a new request or for a renewal, you may have to follow a different procedure or make changes.

{{notice|Limitations|ICTS does not allow SSL requests for historic *.student.kuleuven.be domains. We judge requests for username.ulyssis.be and username.studentenweb.org on an individual basis.}}

==External certificates==
To install external certificates we require the certificate itself, the private key, and possibly the chain. We prefer you also send us (a link to) the documentation of your supplier. As certificate files, especially private keys, are a delicate matter we suggest you just email us the path in your homedirectory you've put them and we will move them over to the webserver safely. For more information concerning this procedure you can always contact us on ulyssis@ulyssis.org

===Let's Encrypt===
We currently do not have an automated system for renewing and deploying certificates such as those supplied by Let's Encrypt. We are however looking into automating this process in the future. Since more of our users are starting to use Let's Encrypt, and all of their certificates need to be renewed frequently, we have a specific procedure now.

When wishing to add a certificate with Let's Encrypt to your website, or renew your existing one, first create a folder <code>letsencrypt</code> in your '''home directory'''. Then add a folder per domain or group of domains:

mkdir -p ~/letsencrypt/mydomain.be

Certificates should be stored in these folders, according to the following file structure:

letsencrypt/
└── mydomain.be/
├── mydomain.be.chain (the CA file)
├── mydomain.be.crt (the cert file; "public key")
└── mydomain.be.key (the key file; "private key")

If you already possess the necessary files, renaming and copying them accordingly is sufficient.
'''You still have to email us to install your certificate.''' More information in the last section on this page.

Otherwise, you can generate or renew your certificates using acme.sh. This is explained in the next section.

==== Generating certificates ====
{{notice|If you use a <code>.htaccess</code> file in the webroot of the domain name, make sure to add the following lines at the top of the file:|<pre><IfModule mod_rewrite.c>
RewriteRule "^.well-known/acme-challenge" - [L]
</IfModule></pre>}}
Because the normal method of generating Let's Encrypt certificates, certbot, requires root access, it's impossible for normal users to do so on our servers. Luckily there are plenty of alternatives which implement the Let's Encrypt protocol. In this tutorial, we'll show how to use the acme.sh program to generate certificates on the ULYSSIS servers. '''If you already followed this section to generate certificates, skip to the next section on renewing certificates.'''

Firstly, execute the following commands to download the acme.sh script in your home directory and make it executable:

curl -o ~/acme.sh https://raw.githubusercontent.com/acmesh-official/acme.sh/master/acme.sh
chmod +x ~/acme.sh

Next, determine for which domains and subdomains you want to generate a certificate. You will need to generate a single certificate for each domain and subdomain which points to the same folder on your account (in most cases this is <code>www</code> in your home directory).

The following example command will generate a certificate for <code>mydomain.be</code> and <code>www.mydomain.be</code> which points to the <code>www</code> folder in the home directory. '''Change the parameters''' as explained below before executing this command!

~/acme.sh --issue --cert-file ~/letsencrypt/mydomain.be/mydomain.be.crt --key-file ~/letsencrypt/mydomain.be/mydomain.be.key --ca-file ~/letsencrypt/mydomain.be/mydomain.be.chain -m "email@mydomain.be" -w ~/www -d mydomain.be -d www.mydomain.be --server letsencrypt

The explanation of these many parameters is as follows:
* <code>--issue</code> tells acme.sh to generate a new certificate.
* <code>--cert-file ~/letsencrypt/mydomain.be/mydomain.be.crt</code> tells acme.sh to store the certificate file in the <code>letsencrypt/mydomain.be</code> folder in your home directory, using the special file name as required by the file structure. '''This folder should already exist''', please refer to the previous section if you have not created this folder yet.
* <code>--key-file ~/letsencrypt/mydomain.be/mydomain.be.key</code> tells acme.sh to store the key file in the <code>letsencrypt/mydomain.be</code> folder in your home directory, using the special file name as required by the file structure.
* <code>--ca-file ~/letsencrypt/mydomain.be/mydomain.be.chain</code> tells acme.sh to store the CA file in the <code>letsencrypt/mydomain.be</code> folder in your home directory, using the special file name as required by the file structure.
* <code>-m "email@mydomain.be"</code> tells acme.sh the email address associated with the certificate. Let's Encrypt will remind this email address (if provided) when the certificate is close to expiring.
* <code>-w ~/www</code> tells acme.sh where the domains in this certificate point to. Make sure to change the <code>www</code> part if the domains point to a different folder in your home directory.
* <code>-d mydomain.be</code> and <code>-d www.mydomain.be</code> tell acme.sh that the certificate should protect <code>mydomain.be</code> and <code>www.mydomain.be</code>. The first domain name will be the "main domain", which is important for renewing. You should '''add all domain names''' pointing to the <code>-w</code> folder.
* <code>--server letsencrypt</code> tells acme.sh to use https://letsencrypt.org/ as Certificate Authority (CA).

After executing this command with the right parameters, your certificate should be generated successfully. When you have to renew the certificate in the future, you should follow the instructions in the next section. '''Don't forget to email us to install your new certificate.''' More information in the last section on this page.

==== Renewing certificates ====
To renew the certificates of <code>mydomain.be</code>, just execute:
~/acme.sh --renew -d mydomain.be

For the <code>-d</code> parameter, you have to provide the '''first''' domain name you provided when generating the certificate (in the previous section, this was <code>mydomain.be</code>.

If you are not sure which domain name to use, you can execute the command:
~/acme.sh --list

This will generate a list of available certificates, which looks a bit like this:
Main_Domain KeyLength SAN_Domains CA Created Renew
mydomain.be "" www.mydomain.be LetsEncrypt.org ... ...
... ... ... ... ... ...

In this example, the main domain is <code>mydomain.be</code>.

The renewed certificates will automatically be copied to the files you provided in the command to generate the certificates (see previous section).

'''After renewing the certificate, you have to email us to install your certificate.''' More information in the next section.

==== Getting your certificates installed ====
Check whether everything is stored correctly by executing the following command:
ulyssis-certificate check mydomain.be

If everything looks good, you should only see lines starting with <code>[ OK ]</code>. Any line starting with <code>[FAIL]</code> or <code>[ABRT]</code> means a check has failed, you must correct this error before asking us to install your certificate.

Once all steps are done and if you are the '''account holder''', '''you can send us an email clearly stating the account name, for which domains we need to add certificates and where the files are stored'''. If you are renewing existing certificates, also clearly state that in your email.

We have largely automated the installation of certificates. If you do not follow these instructions, your request will be denied or you may end up with broken SSL, so make sure you follow this procedure carefully.

[[Category:Webserver]]