rsyslog a bad idea? Problems with ssh, openssh-server, fail2ban

[Anna]

Hi guys,

after writing this I realised that the introduction is quite long; for the actual question you can hop to the last paragraph.

I naively used ssh to connect my phone to the computer, until I recently found out that this is apparently very insecure.

So now I am trying to harden the system by
-excluding IPv6 adresses (done)
-changing the port (yet to be done)
-using a key instead of a password (yet to be done; there's a brief manual in the wiki, but I could not do it, so I will have to look for more foolproof resources)
-installing fail2ban

After installing fail2ban (which is supposed to block IP adresses which fail to enter a correct password for more than x times) I noticed that it did not work: I could enter as many wrong passwords as I pleased and still log in. I finally found out that the reason was that the file /var/log/auth.log was missing and that I could solve the problem by installing rsyslog.

Was it a bad idea to install rsyslog? I'm asking because I guess that the devs had a reason to leave it out. Could it maybe drain the battery, quickly use up a lot of disk space or do anyting else that would be undesired on a pinephone?

[vongillus]

I think that you should make sure that rsyslog writes to a ramdisk and not persistent storage like eMMC or SD card. This to prevent too many write cycle on flash storage. Check may be if other logs are not already available on the default Mobian which would be compatible with fail2ban.

[Anna]

I think that you should make sure that rsyslog writes to a ramdisk and not persistent storage like eMMC or SD card. This to prevent too many write cycle on flash storage. Check may be if other logs are not already available on the default Mobian which would be compatible with fail2ban.

Thank you!

That was a good hint: As I found out, there's no need to install rsyslog (even though that does work); all you need to do is to copy the file /etc/fail2ban/jail.conf as jail.local, open that newly created file /etc/fail2ban/jail.local and change "backend = auto" to "backend = systemd".

Then fail2ban works.

However, after proceeding further, a troubling question occurred to me:

If I use a key instead of a password and ban ssh from accepting passwords altogether ("PasswordAuthentication no" in etc/ssh/sshd_config) is there any benefit at all in using fail2ban? Or was the whole installation completely futile? Would it even be better to purge it?

[mob]

 is there any benefit at all in using fail2ban? Or was the whole installation completely futile? Would it even be better to purge it?

If I understand your set up well you need to connect your PP to your computer at home on a private network, likely behind your modem firewall. fail2ban is typically installed on servers reachable through a public ip 24/24 like webservers storing commercial information. So the risks are lower in your setting to be subject of brute force attacks. Doesn't mean you shouldn't be concerned about security, but your thread model is different from webservers.
If you have a router firewall + on your machines (useful if your devices are mobile), are using your sshd occasionally when your machine is on, using basic hardening (prevent root login, use key authentification + password), limit login to the private ip of the second device, apply security updates regularly, then the risks are low.
Since f2b is installed, if you have disk space it doesn't hurt to keep it.
If you are interested in system hardening you can have a look at lynis (check cysofy on github). But use workstation parameters, if I understand your setting, server mode would be a bit too much.

[Anna]

If I understand your set up well you need to connect your PP to your computer at home on a private network, likely behind your modem firewall. fail2ban is typically installed on servers reachable through a public ip 24/24 like webservers storing commercial information. So the risks are lower in your setting to be subject of brute force attacks. Doesn't mean you shouldn't be concerned about security, but your thread model is different from webservers.
If you have a router firewall + on your machines (useful if your devices are mobile), are using your sshd occasionally when your machine is on, using basic hardening (prevent root login, use key authentification + password), limit login to the private ip of the second device, apply security updates regularly, then the risks are low.
Since f2b is installed, if you have disk space it doesn't hurt to keep it.
If you are interested in system hardening you can have a look at lynis (check cysofy on github). But use workstation parameters, if I understand your setting, server mode would be a bit too much.

Thank you for this!

I do indeed only have a very basic understanding of networks and security and was not sure which access third parties might have to my phone when I use it at home via the router or ouside via the cellular network.

Lynis turned out to be a great tool and surprisingly user friendly -- I will have to spend more time on it.

What I have done so far is to
  -switch to key authentification from my Laptop
  -add the line ALL: ALL in the file etc/hosts.deny and ALL: <IP.ADDR.OF.MY.LAPTOP> in etc/hosts.allow (to exclude other clients)
  -change "LLMNR=yes" to "no" in /etc/systemd/resolved.conf (to close port 5355 which for some reason is open by default)
  -change the following entries in etc/ssh/sshd_config like so:
       Port 55673 (or some other unusual port number instead of the standard 22)
       AddressFamily inet (to exclude IPv6 adresses)
       PermitRootLogin prohibit-password (to prevent root logins)
       PasswordAuthentication no (to prevent logins without the key on my laptop)
       UsePAM no (because some Linux book told me to)
-install the uncomplicated firewall ufw and deny access from all machines except my laptop via "sudo ufw allow from <IP.ADDR.OF.MY.LAPTOP>"

[mob]

Not sure if TCP wrappers with custom host flies works on modern mobian. The alternative is to control it via the sshd config file:
AllowUsers username@private_static_ip (or ip ranges)
You can also associate ip to authorized_keys file.
As you are using active ufw:
allow from <private_ip> to any port <custom port>
Note that changing default port only protect from dumb bots, it is easy to find sshd associated custom port with nmap or similar tools.
Finally I would set PermitRootLogin to no in sshd config.
This is open to any comment from the community but IMHO it is a reasonable setting, you can sleep peacefully

[Anna]

This is open to any comment from the community but IMHO it is a reasonable setting, you can sleep peacefully

Done. hosts.deny seems to work though, at least I cannot log in when I remove my IP from hosts.allow. Lynis had quite a few additional suggestions for the sshd_config file that I included.But I will have to stop using lynis -- makes me feel completely inadequate and paranoid ;-)

[juju]

IMHO, the essential part is refuse password authentication and enforcing ssh key.
You can directly restrict source IP in your user authorized keys. I'm using this as prefix
from="192.168.*,10.*"
= only local network ssh will be accepted