1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
|
Name: How to use access controls
File: access.txt
Date: 27 November 2001
Auth: Russell Kroll <rkroll@exploits.org>
Conversion notice
=================
This document has been rolled into the new upsd.conf(5) man page,
and will go away eventually to reduce duplication of content.
============================================================================
With the introduction of access controls, steps can be taken to keep the
whole world from pounding on your ups server. These controls should be
used in addition to appropriate firewalling measures for total protection.
ACLs
====
Access control lists define a group of addresses. They should be listed
one per line in the upsd.conf file with the following format:
ACL <aclname> <ip block>
The ip block must include the network address and the netmask
information. This can be either CIDR format (/nn) or the traditional
n.n.n.n format.
These examples show both forms. Pick one you like and stick with it.
To create an entry for localhost:
ACL localhost 127.0.0.1/32
ACL localhost 127.0.0.1/255.255.255.255
Perhaps you have a traditional class C and want to list it:
ACL mynet 206.253.95.0/24
ACL mynet 206.253.95.0/255.255.255.0
Or maybe you want to cover _everything_:
ACL all 0.0.0.0/0
ACL all 0.0.0.0/0.0.0.0
Once you've defined your IP blocks, use them in access controls.
Access Controls
===============
These switch access on and off based on ACLs. This way, you can say that
a certain group can do anything while another has limited access and
everyone else gets nothing at all.
The format:
ACCESS <action> <level> <aclname> [<password>]
<action> can be:
- grant - allow this for the group <aclname>
- deny - refuse this for <aclname> and send an error message
- drop - like deny, but with no error message sent - silent failure
<level> can be one of the following:
base: basic commands, no info retrieval (also allows TCP connections)
monitor: base + information retrieval (read-only)
login: monitor + login for shutdown sync
master: login + forced shutdown abilities for multi-ups client sync
manager: master + variable setting + instant commands
all: match any level
<aclname> is one of the ACLs you defined earlier.
The password is only checked for certain access levels. If you set a
password on an access line, any client matched by the corresponding ACL
must have that password set. This only applies to "login" and up right
now.
Example:
- "server" has a UPS attached to a serial port. It runs the model driver,
upsd, and upsmon in master mode. The password is 'magicpass'.
- "workstation" draws from the same UPS as "server", but has to monitor
it over the network. It runs upsmon in slave mode. The password is
'anotherpass'.
- "webserver" doesn't get power from this UPS at all, but it runs
the CGI programs so it can make nice status displays.
- an abuser is silently dropped
- everyone not yet covered is denied nicely
ACL server 10.20.30.1/32
ACL workstation 10.20.30.2/32
ACL webserver 10.20.30.3/32
ACL abuser 192.168.255.128/32
ACL all 0.0.0.0/0
ACCESS grant master server magicpass
ACCESS grant login workstation anotherpass
ACCESS grant monitor webserver
ACCESS drop all abuser
ACCESS deny all all
Access controls should go from most specific to least specific. The
first match with a sufficient access level is the one used when applying
permissions.
Along the same lines, everyone is a member of "all", but we want to match
everything else first so they don't hit the deny at the bottom.
If you don't have a final "all" match at the bottom, it will force one for
you as a deny. So, if you want the whole world to have access, add an
explicit allow for it. Think of it as a big repeating "if-then-else"
structure.
Potential problems to avoid
===========================
You can get into a bit of trouble if things are defined out of order.
Take the following example:
ACCESS grant manager myhost pass2
ACCESS grant login myhost pass1
That looks fine at a glance, but will cause problems whenever someone
on "myhost" tries to do login functions. The reason is that the first
line encountered matches the host *and* has sufficient access for the
task at hand, so that password is used.
The solution is to put the most powerful lines last, so they don't
match too early.
ACCESS grant login myhost pass1
ACCESS grant manager myhost pass2
This way, the manager functions miss the first line entirely and
instead match the second one, which has the right password.
|
