1 |
On Sunday 18 January 2009 20:12:28 Grant wrote: |
2 |
> >> I have some users on a system and some services. How can I make sure |
3 |
> >> only certain users can log into certain services? Do I need to |
4 |
> >> explicitly define which users can log into each service? Are there |
5 |
> >> different types of users so that some can only log into certain |
6 |
> >> services? |
7 |
> >> |
8 |
> >> For example, I know any user that has their shell set to /bin/nologin |
9 |
> >> can't log into a shell. How can I check on users' shell settings? |
10 |
> >> |
11 |
> >> - Grant |
12 |
> > |
13 |
> > To do this you configure each service separately (there is no central |
14 |
> > registry-type thing for this). You don't say what "services" you are |
15 |
> > interested in, so I have to make some assumptions. |
16 |
> > |
17 |
> > apache, samba, ftp servers, all have their own authentication methods. |
18 |
> > You have to research what methods they provide, and choose which is most |
19 |
> > appropriate. For instance, Samba can auth against kerberos/ldap or using |
20 |
> > a local smbpasswd file. For a specific user to be able to access |
21 |
> > something via samba, you ensure they have an entry in AD or a line in |
22 |
> > smbpasswd. |
23 |
> > |
24 |
> > For more simple local services, you can use user and group permissions. I |
25 |
> > have to restrict cron and wget at work, I find the easiest way is to: |
26 |
> > chown root:trusted /usr/bin/wget |
27 |
> > chown root:trusted /usr/bin/crontab |
28 |
> > users authorized to use wget/cron must then be put in the trusted group. |
29 |
> > |
30 |
> > cron has it's cron.allow and cron.deny files that you can also use. |
31 |
> > |
32 |
> > sshd has config options to limit who can do what in sshd_config. |
33 |
> > |
34 |
> > If you post back with more specifics about what you want to achieve, we |
35 |
> > can assist you better. |
36 |
> |
37 |
> As far as open ports, most of my systems only run sshd and cupsd. |
38 |
> I've set AllowUsers in sshd_config to only allow my own non-root user |
39 |
> to log in, and I've locked down cupsd.conf. However, one of my |
40 |
> systems runs things like apache2, postfix, courier-imap, saslauthd, |
41 |
> mysql, and sshd. I set them up to be secure when I installed them, |
42 |
> but I wonder about the different users on my system (none of them with |
43 |
> shell access) and their access to the different services. Should I go |
44 |
> through each of these services and set up something similar to |
45 |
> AllowUsers so that only certain users have access to certain services? |
46 |
|
47 |
Yes, that is the way of it. You really so need to attack each service |
48 |
individually and set it up appropriately. |
49 |
|
50 |
You can limit your exposure by removing most of those users from /etc/passwd |
51 |
if all services they need use virtual users. For instance, if people only |
52 |
need a pop mailbox, make them virtual users defined only in your pop server. |
53 |
|
54 |
Whether you can do this universally depends very much on your exact needs and |
55 |
how you like to set things up. Unix daemons are extremely flexible, this is |
56 |
their strength and weakness. Strength because you can always get exactly what |
57 |
you want somehow, weakness because there's no standard howto recipe |
58 |
|
59 |
> On the subject of users, there are a lot of users in /etc/passwd, |
60 |
> although most of them have /bin/false or /sbin/nologin. There are 8 |
61 |
> users who have a different shell defined. The first 3 are fine: |
62 |
> |
63 |
> root /bin/bash |
64 |
> user /bin/bash |
65 |
|
66 |
What is this? Looks like some generic catch-all account. That's usually a |
67 |
recipe for disaster as it's the kind of thing that gets forgotten. |
68 |
|
69 |
It's definitely not a standard user for any distro I've ever seen, so why do |
70 |
you have it? |
71 |
|
72 |
> cart /bin/bash |
73 |
> |
74 |
> The next 3 are probably fine: |
75 |
> |
76 |
> sync /bin/sync |
77 |
> shutdown /sbin/shutdown |
78 |
> halt /sbin/halt |
79 |
> |
80 |
> But I don't recognize the following 2. Should I userdel them? |
81 |
> |
82 |
> operator /bin/bash |
83 |
> guest /dev/null |
84 |
|
85 |
What are they used for? I've just done a huge project to clean up and |
86 |
centrally manage all users on all my servers (about 100 machines), so I |
87 |
learned some tricks to find redundant users: |
88 |
|
89 |
grep -r <username> /etc/* |
90 |
look at mailboxes |
91 |
look in crontabs |
92 |
ps axu | grep <username> |
93 |
lsof -u <username> |
94 |
find / -user <username> -ls |
95 |
|
96 |
sift through all these outputs looking for evidence of an account that is |
97 |
actually used. Again, there's no standard recipe. This kind of audit |
98 |
absolutely requires eyeballs and a brain |
99 |
|
100 |
> mysql only needs to connect to a daemon running on the same system, |
101 |
> and I think it does so via a unix socket as opposed to tcp. I can see |
102 |
> from netstat that /var/run/mysqld/mysqld.sock is connected, there is |
103 |
> no mention of a tcp mysql connection, and nmap does not show a mysql |
104 |
> port to be open. Is there anything else I should do as far as locking |
105 |
> down mysql? I'm the only one with shell access to the system. |
106 |
|
107 |
mysql should be running as a non-root user (probably mysql) and for what you |
108 |
use, should be listening on localhost only. If you need to connect over the |
109 |
network, the usual technique is to allow access only to specified users and |
110 |
only to specified machines. The latter can be done with |
111 |
|
112 |
a. The service's own config (many services support this) |
113 |
b. hosts.[allow|deny] is the service is built against libwrap |
114 |
c. iptables if nothing else suffices (this is hard to manage so it's a last |
115 |
resort) |
116 |
|
117 |
> I would appreciate any other security advice regarding any of the |
118 |
> above-mentioned services. |
119 |
|
120 |
|
121 |
|
122 |
|
123 |
-- |
124 |
alan dot mckinnon at gmail dot com |