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