On Sunday 18 January 2009 20:12:28 Grant wrote: > >> I have some users on a system and some services. How can I make sure > >> only certain users can log into certain services? Do I need to > >> explicitly define which users can log into each service? Are there > >> different types of users so that some can only log into certain > >> services? > >> > >> For example, I know any user that has their shell set to /bin/nologin > >> can't log into a shell. How can I check on users' shell settings? > >> > >> - Grant > > > > To do this you configure each service separately (there is no central > > registry-type thing for this). You don't say what "services" you are > > interested in, so I have to make some assumptions. > > > > apache, samba, ftp servers, all have their own authentication methods. > > You have to research what methods they provide, and choose which is most > > appropriate. For instance, Samba can auth against kerberos/ldap or using > > a local smbpasswd file. For a specific user to be able to access > > something via samba, you ensure they have an entry in AD or a line in > > smbpasswd. > > > > For more simple local services, you can use user and group permissions. I > > have to restrict cron and wget at work, I find the easiest way is to: > > chown root:trusted /usr/bin/wget > > chown root:trusted /usr/bin/crontab > > users authorized to use wget/cron must then be put in the trusted group. > > > > cron has it's cron.allow and cron.deny files that you can also use. > > > > sshd has config options to limit who can do what in sshd_config. > > > > If you post back with more specifics about what you want to achieve, we > > can assist you better. > > As far as open ports, most of my systems only run sshd and cupsd. > I've set AllowUsers in sshd_config to only allow my own non-root user > to log in, and I've locked down cupsd.conf. However, one of my > systems runs things like apache2, postfix, courier-imap, saslauthd, > mysql, and sshd. I set them up to be secure when I installed them, > but I wonder about the different users on my system (none of them with > shell access) and their access to the different services. Should I go > through each of these services and set up something similar to > AllowUsers so that only certain users have access to certain services?
Yes, that is the way of it. You really so need to attack each service individually and set it up appropriately. You can limit your exposure by removing most of those users from /etc/passwd if all services they need use virtual users. For instance, if people only need a pop mailbox, make them virtual users defined only in your pop server. Whether you can do this universally depends very much on your exact needs and how you like to set things up. Unix daemons are extremely flexible, this is their strength and weakness. Strength because you can always get exactly what you want somehow, weakness because there's no standard howto recipe > On the subject of users, there are a lot of users in /etc/passwd, > although most of them have /bin/false or /sbin/nologin. There are 8 > users who have a different shell defined. The first 3 are fine: > > root /bin/bash > user /bin/bash What is this? Looks like some generic catch-all account. That's usually a recipe for disaster as it's the kind of thing that gets forgotten. It's definitely not a standard user for any distro I've ever seen, so why do you have it? > cart /bin/bash > > The next 3 are probably fine: > > sync /bin/sync > shutdown /sbin/shutdown > halt /sbin/halt > > But I don't recognize the following 2. Should I userdel them? > > operator /bin/bash > guest /dev/null What are they used for? I've just done a huge project to clean up and centrally manage all users on all my servers (about 100 machines), so I learned some tricks to find redundant users: grep -r <username> /etc/* look at mailboxes look in crontabs ps axu | grep <username> lsof -u <username> find / -user <username> -ls sift through all these outputs looking for evidence of an account that is actually used. Again, there's no standard recipe. This kind of audit absolutely requires eyeballs and a brain > mysql only needs to connect to a daemon running on the same system, > and I think it does so via a unix socket as opposed to tcp. I can see > from netstat that /var/run/mysqld/mysqld.sock is connected, there is > no mention of a tcp mysql connection, and nmap does not show a mysql > port to be open. Is there anything else I should do as far as locking > down mysql? I'm the only one with shell access to the system. mysql should be running as a non-root user (probably mysql) and for what you use, should be listening on localhost only. If you need to connect over the network, the usual technique is to allow access only to specified users and only to specified machines. The latter can be done with a. The service's own config (many services support this) b. hosts.[allow|deny] is the service is built against libwrap c. iptables if nothing else suffices (this is hard to manage so it's a last resort) > I would appreciate any other security advice regarding any of the > above-mentioned services. -- alan dot mckinnon at gmail dot com
