1

In an effort to protect my site from bad bots including ridiculous hackers that can login to the server, I want to secure access_log and error_log as much as possible without breaking apache or cpanel.

I do believe that whatever user apache is running as should have read and write access to the log file.

I'm not sure if cpanel has any special requirements for accessing the log file. and I'm not sure if something in cpanel will break if I make the permissions of the log file too restrictive.

Currently I have it where everyone has read access to the log file and only root and the group root is in has read and write access. I want to take read access off for everyone else, but will it affect cpanel or apache in any way?

My goal is to improve website/webserver security and continue to serve pages at high speed without breaking functionality.

My server is linux based.

Improve this question
7
  • Your logs files should not be within your web space at all. By default, the first site is create in /var/log/httpd or apache2. I am not sure about cPanel, however, it should have followed some similar pattern for each additional site. This would mean that Apache users cannot even get to your log files. Keep in mind that any website normally configured cannot access anything outside of the sites web space except for Apache's own functions. If cPanel is not configuring sites correctly, you can change this. But you should not need to mess with file permissions.
    – closetnoc
    Nov 22, 2015 at 1:38
  • They are outside of document root of each domain on the server. My issue is someone being able to access them if they crack into the shell. When I logged into a standard user account with the shell, I was able to see the logs
    – Mike -- No longer here
    Nov 22, 2015 at 1:46
  • Got it. There is some level of this you will not be able to control, however, if your sites run under different usernames, then you can use the username and group per site/log files. Otherwise, you should be able to use the Apache user and group. As long as no-one has access to root or sudo if they get in, this should work. But I will caution you that each configuration is different and I could be telling you a bunch of ****. ;-) In other words, be careful that you can reverse anything you have done. My sites have the site owner/user permissions.
    – closetnoc
    Nov 22, 2015 at 1:51
  • "login to the server" / "crack into the shell" - if this should happen I would have thought you'd have a lot more problems than just access to log files?
    – MrWhite
    Nov 22, 2015 at 10:56
  • if someone was smart enough to get into the server - limiting their access to the log files would be my primary concern, because the first thing a smart hacker will do once gain entry into your system is remove the log entries they generated during the attack to gain entry.
    – the_velour_fog
    Nov 22, 2015 at 11:51

2 Answers 2

Reset to default
1

If they are able to login via your SHELL then its pretty much game over and as mentioned by @w3d Apache log files are least of your worries.

  • Apache writes to log files directly, no one can view those logs unless they are stored within the hosting path.

If security is a major concern then you should confirm that you use the following practices:

  • Your SSH should be secured using SSH Keys, not username or password, or even better... disabled when you are not using it, and launched it when required.
  • Your cPanel account should use a complex password, ideally... use something at least 12-18 digits long with numbers, capitals and symbols. cPanel is also in the process of adding two-way authentication, as soon as this is released you should enable it, same goes for every platform outside the realms of cPanel.
  • FTP should be disabled in favour of FTPS, or FTP TLS/SSL. The server should block brute cracking using fail2ban or similar.
Improve this answer
2
  • I understand all that, but I'm trying to figure out how cpanel deals with the log files because it has some modules that need read access to them but I'm not 100% sure what user name cpanel uses to read them.
    – Mike -- No longer here
    Nov 22, 2015 at 17:07
  • cPanel will have access through the group policy's. To find out the user simply do ls -l logfile then do groups groupname. It'll list all users who have access to that group, and file/folder.
    – Simon Hayter
    Nov 22, 2015 at 17:58
1

I basically agree with Simon Hayters statement that if they gained shell access - unless they had limited shell access by injection into say a php application that was using shell_exec - I personally would start thinking about restoring the system from trusted sources. But then the question becomes - if you don't learn how they got in that time - how can you stop them the next time? - having uncompromised log entries can help reconstruct the break in.

But to the question, here is how nginx (and from memory apache is the same) sets up log file permissions on Ubuntu 14.04.

$ls -al /var/log/
... 
drwxr-s---  2 mysql     adm      4096 Nov 22 06:38 mysql
-rw-r-----  1 mysql     adm         0 Nov 20 17:39 mysql.err
-rw-r-----  1 mysql     adm         0 Nov 22 06:38 mysql.log
drwxr-x---  2 www-data  adm      4096 Nov 22 06:38 nginx
-rw-------  1 root      root        0 Nov 22 06:38 php5-fpm.log
-rw-r-----  1 syslog    adm      9734 Nov 23 00:17 syslog
...

By giving "others" no permissions on the nginx directory itself - ordinary users can't even see the files themselves - let alone read them. If they had root permissions, they could do this

$ sudo ls -al nginx/
total 28
drwxr-x---  2 www-data adm    4096 Nov 22 06:38 .
drwxrwxr-x 13 root     syslog 4096 Nov 22 06:38 ..
-rw-r-----  1 www-data adm    2082 Nov 23 00:30 access.log
-rw-r--r--  1 root     root   9803 Nov 22 06:26 access.log.1
-rw-r-----  1 www-data adm       0 Nov 22 06:38 error.log

Now, unless you are www-data,adm or root you won't be able to read logs. access.log.1 which is not created by the webserver but the log archiving utility logrotate has read permissions - but because anyone who is not root, www-data or adm won't have permissions along every segment in the path to /var/log/nginx/access.1.log so they still can't read the file (the directory permission is still blocking them).
So you could try this permission structure - which will be annoying for you to administer as you need to elevate to su or add your user to www-data or adm groups or similar - depending on your system - just to get into the log directories and read logs.
Also - its IMPORTANT you don't break the permissions of the logrotate facility - its what cleans up your log records (archiving and deleting log entries over a certain age - usually a year).

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.