6

I've setup an SSH server on my Raspberry Pi. I use RSA keys to login, I disabled root login, password authentication and I use port forwarding to login from outside my network.

I can see the connection logs from the file /var/log/auth.log but I noticed that it is cleared on regular basis (I think some days) and can be modified by a standard user.

Isn't this a security problem, someone that manages to break into it could clear the log and leave no traces, can I prevent this?

Improve this question
6
  • I just checked the permissions on /var/log/auth.log on my Raspberry Pi Model B with a recent and up-to-date Raspbian and they are as follows: -rw-r----- 1 root adm 26787 Feb 8 14:20 /var/log/auth.log. Which Linux Distribution do you use? Maybe setting the right permissions might already solve your problem.
    – rbialon
    Commented Feb 8, 2015 at 13:22
  • I have raspbian on a rpi b+. The permissions are exactly the same.
    – Matteo
    Commented Feb 8, 2015 at 14:43
  • There's nothing about the Raspberry Pi hardware that would cause this to happen. The question is, what Linux distribution are you running?
    – 200_success
    Commented Feb 8, 2015 at 18:16
  • If thepermission are -rw-r----- 1 root adm, a standard user will not be able to modify the file. Could it be a service such as logrotate that is automatically cleaning up the old logs?
    – limbenjamin
    Commented Feb 8, 2015 at 22:30
  • Sorry for making you waste time, i've checked and in fact i can't edit the auth.log as a standard user. But why is the file cleared periodically? How can i check logrotate? I have the standard raspbian downloaded from the official raspberry pi website. Thank you
    – Matteo
    Commented Feb 9, 2015 at 6:20

1 Answer 1

Reset to default
5

There will be a cronjob which runs logrotate daily as root, you can check the configuration in /etc/logrotate.conf and /etc/logrotate.d/*. If you make any changes you should run /usr/sbin/logrotate -dv /etc/logrotate.conf to make sure there are no errors in the new configuration.

In addition to auth.log you should also rotate and keep wtmp and btmp (the second one tracks failed login attempts), most systems will keep just one rotation of those.

The normal setup is that /var/log/ is not word-writeable, log files within are also not world-writeable, and sometimes not world-readable (the latter for files like auth.log which may accidentally contain passwords entered into username fields, CWE-532).

You should check the file permissions are as expected, it's the job of logrotate to create new log files and set the correct owner/permissions (see the create directive). However, the default is to apply the permissions and ownership of the current file: if owner/permissions are changed once, those will be maintained on every new instance of that log file (so a previous mistake can come back to haunt you).

Even though a normal user cannot write to or directly modify those files, a local user can probably append to them indirectly via syslog:

logger -p auth.info -it sshd \
  "Accepted password for root from host.badguys.com port 31337 ssh2"

(The situation is worse if you accept syslog messages via UDP over the network, but that's not usually enabled by default in any sane configuration.) This is an example of CWE-117, and shows one of a number of problems with syslog.

A different method must be used to actually overwrite or delete data if a login is acquired by an attacker (or untrusted user), e.g. privilege escalation, or creative use of setuid/setgid programs.

But, there is opportunity for denial-of-service type attacks here. If you don't have some form of rate-limiting or lockout on sshd, an attacker may be able to flood your logs with connection logging (and if he breaks in, may be able to cover his tracks with forged entries). If logrotate is using size-based rotation (not default) he may be able to rotate telltale entries out of existence, with no extra privileges. If you use time-based rotation, he may be able to trivially fill the filesystem you are logging to, and prevent further events being logged.

To summarise:

  • if the log file permissions are wrong, yes an attacker could remove telltale log file entries (if an attacker can leverage some other local privilege escalation, he can do this anyway of course, but then you have a bigger problem)
  • you should check the log file permissions are to your satisfaction, e.g. not world-writeable, and possibly not world-readable — most configurations do not hard-code paranoid permissions in the logrotate.conf
  • standard syslog has a number of problems, including authenticity, integrity and rate-limiting
  • consider using /etc/hosts.allow to whitelist your remote IP blocks for sshd access, if possible, it's a reasonable mitigation measure
  • you should use some type of dynamic blocking (on a Pi you might look at Micro Fail2Ban)

One of the best ways to limit what an attacker can do to your log files is to log them to a different system over a secure network. Other possible solutions include append-only files enforced by the OS (see this on Unix & Linux.SE), this is tamper-resistant.

You can also read about improvements to *nix logging in the rsyslog maintainer's blog. One of the features discussed there is linked-timestamping, which is tamper-evident.

Improve this answer
1
  • Thank you very much, i don't think i need all of these security measurements but i'll take them into account.
    – Matteo
    Commented Feb 10, 2015 at 8:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .