How to secure guide for noob

Support
1

I thibk yunohost is a fantastic project because help average user to make his own home server
I’m concerned about security, on web i found alot of stuff i don’t understant, how to configure fail2ban for ssh mail and https and other things.
I’m here to ask some question
First of all what’s the best and easiest way to monitor the system log to see if someonw tryed or had the access to my server?
Should i chroot processes or working with containers apparmor and similar?
How can i do all those things? Or why are not necessary. A system update could brake it?
What yunohost have as default customization about security instead of vanilla debian?
There are general tips or step by step noob guide to harden server/yunohost?

2

YunoHost automatically install and configure Fail2ban, so you don’t really have to worry about this … It should automatically at least have a jail enabled to protect from SSH brute-force, among other things. If you find that “our” current configuration of Fail2ban does not cover enough stuff, then we could discuss about integrating it :wink:

The mail and HTTP stacks are also automatically configured and we try to keep these up to date with the best practices (c.f. the ciphers, or stuff like SPF, DKIM, …). For these, basically :

  • install a Let’s Encrypt certificate
  • for mail : make sure your DNS conf is similar to what yunohost domain dns-conf your.domain.tld tells you

Fail2ban already kind of does that, so, I don’t know if that’s necessary… Of course, if you want to be extra careful about security, then you should monitor a few things, but my guess is that it quickly becomes technical (you need to know what you’re looking at and what you should pay attention to) and shouldn’t be necessary for the average user if YunoHost does its job properly.

This is a recurring question in the YunoHost ecosystem / app packaging. Since you install different apps on your instance, shouldn’t isolate them as much as you can, e.g. with containers, or chroot ? At this point, good quality apps are ran with their own user (e.g. a user wordpress) and/or have their own PHP worker pool for instance. Some other apps don’t, for various reasons, and so are ran with the basic web user ‘www-data’ for instance…

The question of wether or not we should go for “more advanced isolation” (containers / chroot…) is a complicated question. My personal opinion is that it would add overhead and even more complexity, and the security gain is not so important, in the context of “casual self-hosting for yourself, your friends/family or your local association” I think. The biggest security risks lies not in the technical aspects but in the human aspects.

Basically, imho, you should be safe by following those “simple” guidelines :

  • Use reasonably strong passwords ;
  • Limit the attack surface of your server by not installing tons of apps that you won’t need in the mid/long term ;
  • Try to avoid installing apps with bad reputation in terms of security. For instance : wordpress and phpmyadmin. (I would not recommend shellinabox either). If you need to for whatever reason, try to not install lots and lots of random themes / plugins on those, and keep an eye on them, make sure they’re up to date… ;
  • Do not give access to your server to random people on the internet ;
  • Do some goddamn backups regularly and keep a copy elsewhere
  • Of course if you have some top secret data, be extra careful about those…

With this, you should be pretty fine :+1:

3 Likes
3

Thank you for your reply
Do you think change ssh port is advised?
Is Admin user a user with sudo power or is just like root user? If is root user is advised to add user and give it the sudo power and use it to access the server trought ssh for security purpose?

The mail server do already have a spam filter?
Do fail2ban lock also bruteforce from web interface and trials coming from mail client?

What about port knocking? Someone suggested me to use it is it a good idea in your opinion? If yes could be implemented as standard and already configured in yunohost?

An autoupdate option for apps and system will be implemented on future? Cron daily apt update && apt dist-upgrade and a weekly reboot (usually needed for some package) are advised or could break something?

I know i’m bit paranoid but with hackers who scan the web for botnet or to steal data i prefear to do anything i can to secure my server

4

“hackers who scan the web for botnet” are basically automated script who essentially rely on bruteforce and maybe will try to find/exploit not-up-to-date or badly configured wordpress, stuff like this… One needs to understand that automated attacks are quite different from targeted attacks. You can protect yourself against automated attacks just by using the simple advices from the previous post.

It can help, yes, basically not many brute-force bots will try something else than port 22.

Admin is a different user than root, but it has “sudo” powers (so basically it can easily become root). What you can improve, with respect to this, is to disable “password SSH login for admin” (root SSH login should already be totally disabled by default on yunohost) and to use asymmetric key authentication instead.

I’m not sure about that, but that’s not really security, more like convenience stuff…

It blocks some bruteforce attempt for mail-related stuff as far as I remember, yes… Also yes, it should block brute force attempts on the mail interface. Not sure about the yunohost sso. But an automated attacker is unlikely to automate attack on yunohost, as we’re too small for now anyway. And anyway brute force is useless if you’re using good passwords.

Not sure about this, I have no experience / understanding about port knocking. Yunohost implements a firewall with iptables, I don’t know how an attacker could circumvent it…

Personally I’m kind of opposed to this. To me, automatic upgrade is a security flaw. Automatic upgrade can lead to automatic deployment of backdoor / whatever nasty stuff. As a developer/maintainer of YunoHost (but this is valid for any project) I can make a deb build of yunohost that will run a rm -rf /* during next upgrade. If upgrade are automatic, then this give no time for other people in the project to notice, warn and fix this before the apocalyptic situation occurs.

Also reboot is generally not needed. For instance, it was recently needed for stuff like Meltdown/Spectre flaws, but this is relatively rare situation. And automatic reboot also sounds like a bad idea…

Imho there’s no need to be too crazy about upgrades. Personally, I consider that not upgrading your server for 3 months is fine, as long as there isn’t any huge security flaw which just got revealed… Ideally we should implement a system as some point in yunohos that tells you that you haven’t upgraded your server for a while and you should, but that’s all. This is Debian Stable, so the system should be kinda safe…

Of course, this whole security discussion depends of what we are really talking about.

  • If you want to use yunohost to operate a nuclear plant, then definitely you need some more security.
  • If you are concerned about targeted attacks because your organization is monitored by state-level intelligence services, then the security of a YunoHost is probably kinda fine (c.f. previous advices) and you should focus on other security aspect in the way people communicate with each other and administrate their own laptop/smartphone, for instance.
  • If you are just self-hosting your family, friends or your local sport club/association, then you’re fine. Just implement some reasonable security practices, keep some backups and don’t store crazy data like credit card numbers on your server, and you’re fine.
3 Likes
5

Fail2ban monitor Yunohost SSO as far I know (I’ve reduced the number of try&errors possible on http connections, and I’ve been bloqued quite a few times since).

Regarding update, apart from Yunohost’s apps you also have all packets installed on your system. Keep them up to date (in case of security fix).
Personally I’ve installed apticron app, that sends you an email each time apt packages need an update. (with also the urgency / changelog if provided)
Maybe it’s better than have to think about checking what’s available on a regular basis (it reduces the time-to-react when an update is available).

1 Like
6

If i change ssh port do i need to change something inside fail2ban is it right? This doesn’t break anything in other processes?

7

hi yes you can change ssh port.
But in /etc/fail2ban/jail.conf it’s not required to be done. (unless you want to ban IPs that test port 22)
Modify SSH port

To prevent SSH connection attempts by robots that scan the Internet for any attempt SSH connections with any server accessible, you can change the SSH port.

On your server, edit the ssh configuration file, in order to modify SSH port.

nano /etc/ssh/sshd_config

Search line “Port” and remplace port number (by default 22) by another not used number # to replace by 9777 for example

#What ports, IPs and protocols we listen for
Port 22

Save and restart SSH daemon.

Then restart the iptables firewall and close the old port in iptables.

yunohost firewall reload
yunohost firewall disallow <your_old_ssh_port_number> # port by default 22
yunohost firewall disallow --ipv6 TCP <your_new_ssh_port_number> # for ipv6

For the next SSH connections you need to add the -p option followed by the SSH port number.

Sample:

ssh -p <new_ssh_port_number> admin@<your_yunohost_server>

source : YunoHost • index

2 Likes
8

Thanks now ssh should be safe
Do fail2ban block also web ui admin wrong attempt?

I see now yuno is based on jessie are you working to go with stretch? Wheb this will happen a normal update from webui is enough or we should modify sources.list and upgrade with apt as debian?

9

i’ve done some trials and as i see user and admin webui are not protected by fail2ban, i’ve made alot of attempt from another ip, and i was not banned

how can i setup fail2ban to block ip for x min when y failed attempt was tried?

10

Eh okay :confused: I was able to reproduce the issue on a few machines of mine … A fix is on the way :confused:

1 Like
11

Yes, we’re working on it with limited manpower… This will happen as a “migration”, i.e. a particular kind of upgrade. This should be integrated in the webadmin such that, if we did our job properly, all you’ll have to do is to click “Run the migration”, wait a bit and everything should be transparent for you (ideally) :ok_hand:

Edit: c.f. the roadmap : https://dev.yunohost.org/versions/14

12

thank you very much

i have another question, i’m playing with users made on webui, i’m sending mail each other. If i delete an user from webui, and i create another one with the same name, i still have the old data, i see it from used space in user section, i’ve tryed to delete the username_folder inside home trough ssh but do not delete the user in webui neither data, in webui i see the account and the used data is still occupied, where are user data/account stored? how can i manage it with terminal?

thanks for the support

edit: up
Edit2: up

1 Like
13

what about securing the administrative backend? anyone can go to https://yourdomain.tld/yunohost/admin/#/login and attempt to login. it doesn’t even have a username [which would at the very least boost entropy]… and using google authenticator for 2FA isn’t hard [i see you’re already using python-CGI and there’s tonnes of scripts out there for that already] and its not like you have to modify the SSO engine or anything. afaik, only the LDAP back end would care about that. so “mostly easy to introduce” and just have it off by default until you login to set up your first account. that first account replaces root [and then yunohost would use that username for admin login and also disable root account, giving that first username sudo group.] or even easier. use the yunohost command to make a user in the terminal… and get the information for the username/password upon install via the graphical install menu… so that root is never actually activated at all… also what’s neat is that in the newer installers when you make your user they ask if you want ssh to auth via password or ssh certs… and then you can just enter your GitHub account name to download all your certs there… i’m not saying you should go out of your way to put that in the installer… BUT it would be suuuuuper epic to have a yunohost command like “yunohost ssh github localuser username” and it’d download all the ssh keys from “username” on GitHub and put them in “localuser’s” ~/.ssh/authorized_keys file so that that when you use the yunohost “yunohost ssh allow username” then they can login with their keys instead of password and it’d be like a super super simple process. updating GitHub with your keys… replacing deleting… as long as their on GitHub, using that command could rewrite your authorized_keys file and be simple for keeping track of stuff like how ubuntu server does it. would literally just a be a copy pasta script too then chown and chmod the file so it is able to be used. my last suggestion is just an add on of that. literally a switch like “yunohost ssh cert-only true/false” and by default it’d be false until someone like me would want to turn it on. i know its just editing like one thing in the ssh server config, but then some of the other yunohost commands are super simple too. so it’d be a super easy really nice thing to have.

edit: i know full well the admin panel can be unloaded and disabled… i’m just giving out opinions and suggestions on what i think would help yunohost benefit from most and better or “more easily” protect users.

1 Like
14

Loved "

2 Likes
15

I think she raises an important point. Can something be done to make access more secure?

16
  • YunoHost supposedly already integrates a fail2ban configuration to autoban IP with too many failed authentication attempt (5~10)
  • Choose a robust password
  • In case that make things more scary or less scary (idk) automated attacks from the internet are more likely to target a “generic” SSH auth attempt rather than a custom web authentication form
3 Likes