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.allowto 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.
