1 |
OPAS 1.0 Stephane Thiell |
2 |
Draft (v.1.0.0) December 2003 |
3 |
|
4 |
|
5 |
|
6 |
|
7 |
Open Proxy Ascertainment Service (OPAS) |
8 |
|
9 |
|
10 |
|
11 |
Status of this Memo |
12 |
|
13 |
This document is a working personal document which may be used as |
14 |
reference material althrough it's a work in progress. It might be |
15 |
updated to become an Internet Draft if the community think it's |
16 |
really needed. |
17 |
|
18 |
The latest version of this document is available at |
19 |
http://www.bugged.org/opas/draft-opas-1.txt |
20 |
|
21 |
|
22 |
Copyright Notice |
23 |
|
24 |
Copyright (C) Stephane Thiell (2003). All Rights Reserved. |
25 |
|
26 |
|
27 |
Abstract |
28 |
|
29 |
This document specifies the Open Proxy Ascertainment Service (OPAS) |
30 |
protocol, used (1) for interaction between OPAS servers and OPAS |
31 |
clients and (2) for interactions among multiple OPAS servers to |
32 |
create a distributed system of OPAS servers (proxy scanners). Due |
33 |
to the overwhelming abuse of open proxy servers being exploited |
34 |
daily for common Internet services like HTTP, SMTP or IRC, the need |
35 |
of having open proxy checking services has grown. OPAS provides a |
36 |
lightweight and efficient way to handle such a verification service |
37 |
even in an heterogeneous environment. |
38 |
|
39 |
Comments are solicited and should be addressed to the authors. |
40 |
|
41 |
|
42 |
Acknowledgements |
43 |
|
44 |
<todo> |
45 |
|
46 |
|
47 |
Table of Contents |
48 |
|
49 |
Status of this Memo |
50 |
Copyright Notice |
51 |
Abstract |
52 |
Acknowledgements |
53 |
1. OPAS Architectural Components |
54 |
1.1. OPAS Client |
55 |
1.2. OPAS Server |
56 |
2. OPAS Protocol |
57 |
2.1. Protocol level |
58 |
2.2. OPAS messages |
59 |
2.2.1. Structure of an OPAS message |
60 |
2.2.2.1 Ping/Pong |
61 |
2.2.2.2 Query (Client->Server) |
62 |
2.2.2.3 Reply (Server->Client) |
63 |
2.2.2.4 User commands |
64 |
[3.x Distributed system] |
65 |
A - Resource Classification |
66 |
A.1 OPAS types of open proxy |
67 |
|
68 |
|
69 |
1. OPAS Architectural Components |
70 |
|
71 |
The Open Proxy Ascertainment Service is destined to other Internet |
72 |
services which want to verify their own clients for possible open |
73 |
proxy insecurity. Such a service will be called an OPAS client here, |
74 |
as it will query an OPAS server for the verification. |
75 |
|
76 |
|
77 |
1.1. OPAS Client |
78 |
|
79 |
OPAS clients initiate transactions with OPAS servers using the OPAS |
80 |
protocol. An IRC server is an example of possible OPAS client. |
81 |
After an OPAS session is initialized, the client sends queries to |
82 |
an OPAS servers and listen/wait for a positive or negative reply. |
83 |
|
84 |
|
85 |
1.2. OPAS Server |
86 |
|
87 |
After eventual initialization (like authentification), OPAS servers |
88 |
respond to OPAS protocol queries. An OPAS server can be a |
89 |
standalone proxy scanner that will do all the checks, or can |
90 |
redirect some or all queries to another OPAS servers. The goal of |
91 |
this draft is not to deal with the choices of such actions (it |
92 |
could be to provide load balancing or for network reachability |
93 |
reasons), we won't even deal with the procedure to really check |
94 |
an open proxy or how to manage the cache. No, our real goal here is |
95 |
to support all these possible cases with a description of the |
96 |
functionality and eventual limits. |
97 |
|
98 |
|
99 |
2. OPAS Protocol |
100 |
|
101 |
|
102 |
2.1. Protocol level |
103 |
|
104 |
The OPAS protocol is not dependant to the network layer. Meanwhile |
105 |
as it's used in an Internet context, we will mainly consider OPAS |
106 |
over IP (TCP or UDP). |
107 |
|
108 |
|
109 |
2.2. OPAS messages |
110 |
|
111 |
|
112 |
2.2.1. Structure of an OPAS message |
113 |
|
114 |
An OPAS message (query or reply) shares the same 32 bit header |
115 |
structure, which is described as follow. |
116 |
|
117 |
0 7 8 15 16 23 24 31 bit |
118 |
+--------+--------+--------+--------+ |
119 |
| OPAS version | flags | length | |
120 |
+--------+--------+--------+--------+ |
121 |
|
122 |
Fields |
123 |
------ |
124 |
|
125 |
OPAS version is a representation of the OPAS client protocol |
126 |
version. Bits 0-7 contain the major version and bits 8-15 the minor |
127 |
version. For example, for OPAS version 1.0, only bit 7 is set. |
128 |
|
129 |
Message flags determines what's next. Here is a table of current |
130 |
used bits. |
131 |
|
132 |
Bit | If set... |
133 |
---------------------------------------------------------------- |
134 |
17 | it's a ping/pong message |
135 |
18 | the IP to verify uses IPv6 |
136 |
19 | an user command is following this message |
137 |
|
138 |
Reply only |
139 |
---------- |
140 |
20 | the message is a reply (originated from an OPAS server) |
141 |
21 | the IP is an open proxy |
142 |
22 | result was found in a cache (no scan was really performed) |
143 |
23 | error message - scan wasn't performed |
144 |
|
145 |
Server to server only |
146 |
--------------------- |
147 |
16 | it's a server to server message (remote query) |
148 |
|
149 |
Bit 19 allows an application to use OPAS messages to enhance the |
150 |
protocol with private commands/queries. Care should be taken when |
151 |
adding commands for security reasons, ie. proper verification must |
152 |
be done by the server. |
153 |
|
154 |
The length field specifies the length in bytes of the message |
155 |
following the 4-bytes header. So we have: |
156 |
|
157 |
total message length = 4 + length (bytes) |
158 |
|
159 |
|
160 |
2.2.2. Client to server proxy verification |
161 |
|
162 |
2.2.2.1 Ping/Pong |
163 |
|
164 |
A bit is reserved for the use of ping/pong messages. Only an header |
165 |
is sent using this bit. The pong message adds the reply bit, and |
166 |
that's all. OPAS servers and even clients should use this ping/pong |
167 |
capability to quickly detect a dead connection. |
168 |
|
169 |
This is one of the rare convenience currently offered by the OPAS |
170 |
protocol. You can implement more elaborated ping/pong messages using |
171 |
a custom user command message (see 2.2.2.4) if you want. |
172 |
|
173 |
|
174 |
2.2.2.2 Query (Client->Server) |
175 |
|
176 |
Header: all flags bits must be 0 for an IPv4 proxy verification, or |
177 |
only bit 18 set for an IPv6 verification. |
178 |
|
179 |
Header's length field should contain 8 for IPv4, 20 for IPv6. |
180 |
|
181 |
32 bits user data next to the header are data reserved for the |
182 |
application and are not modified by the server. The reply message |
183 |
from the OPAS server will always contain those bits intact. |
184 |
|
185 |
The IP (v4 or v6) is then appended to the message. |
186 |
|
187 |
Summary: query message |
188 |
---------------------- |
189 |
12 (IPv4) |
190 |
byte 0 4 8 24 (IPv6) |
191 |
+-----------+-----------+--------...+ |
192 |
| header | user data | IP | |
193 |
+-----------+-----------+--------...+ |
194 |
|
195 |
|
196 |
2.2.2.3 Reply (Server->Client) |
197 |
|
198 |
The header of a reply message should set the reply bit to 1 (bit |
199 |
20) and if the IP is known to host an open proxy, the result bit |
200 |
should be set too (bit 21). |
201 |
|
202 |
A negative reply message is sent back to the client when the server |
203 |
is sure the host isn't an open proxy according to its own |
204 |
configuration. Usually a scan has been performed or a successful |
205 |
cache hit occured. |
206 |
|
207 |
Summary: negative reply message (header bit 21 not set) |
208 |
------------------------------- |
209 |
IPv4/v6 |
210 |
0 4 8 12/24 |
211 |
+-----------+-----------+--------...+ |
212 |
| header | user data | IP | |
213 |
+-----------+-----------+--------...+ |
214 |
|
215 |
It's just the same message back (as the query one) but with bit 20 |
216 |
(reply) set. |
217 |
|
218 |
|
219 |
An error reply message is sent back to the client when the server |
220 |
encountered a problem to answer (hardware, network, etc.). Current |
221 |
choice is to reply after having appended an 32 bit error code to |
222 |
the query and set the reply and error bits. |
223 |
|
224 |
OPAS error numbers are defined in Appendix A.2. |
225 |
|
226 |
Summary: error reply message (header bit 23 set) |
227 |
------------------------------- |
228 |
IPv4/v6 IPv4/v6 |
229 |
0 4 8 12/24 16/28 |
230 |
+-----------+-----------+--------...+-----------+ |
231 |
| header | user data | IP | error no | |
232 |
+-----------+-----------+--------...+-----------+ |
233 |
|
234 |
|
235 |
Finally, a positive reply message is sent back to the client when |
236 |
the server ascertained the presence of an open proxy with success. |
237 |
|
238 |
Summary: positive reply message (header bit 21 set) |
239 |
------------------------------- |
240 |
IPv4/v6 |
241 |
0 4 8 12/24 16/28 18/30 20/32 |
242 |
+-----------+-----------+--------...+-----------+-----+-----+ |
243 |
| header | user data | IP | timestamp | type| port| |
244 |
+-----------+-----------+--------...+-----------+-----+-----+ |
245 |
|
246 |
20/32 |
247 |
+-----------+--------... |
248 |
| proxy description... |
249 |
+-----------+--------... |
250 |
|
251 |
Fields |
252 |
------ |
253 |
|
254 |
timestamp: Contains the value of time in seconds since 0 hours, |
255 |
0 minutes, 0 seconds, January 1, 1970, Coordinated |
256 |
Universal Time (the "epoch"). |
257 |
|
258 |
type: OPAS type of proxy, see appendix A.1. |
259 |
|
260 |
port: The port (TCP or UDP) at which the proxy has been found. |
261 |
|
262 |
proxy description: variable length human readable proxy description |
263 |
zero terminated C string. |
264 |
|
265 |
To calculate the length of the proxy description, use: |
266 |
|
267 |
descr_len = length - (20 - 4) = length - 16 (for IPv4) |
268 |
descr_len = length - (32 - 4) = length - 28 (for IPv6) |
269 |
|
270 |
where length is the length field of the header. |
271 |
|
272 |
If the length of the description is zero, the message is invalid. |
273 |
|
274 |
|
275 |
2.2.2.4 User commands |
276 |
|
277 |
As seen in section 2.2.1, OPAS support user commands transport |
278 |
between an OPAS client service and an OPAS server. OPAS does not |
279 |
define any "standard" commands; in the meanwhile, ideas of commands |
280 |
are: statistical commands, remote control of the OPAS server, |
281 |
get the types of scan supported, etc. Security concerns like |
282 |
authentication (which might be embedded in OPAS's user commands) |
283 |
are let to the OPAS client and server developer. |
284 |
|
285 |
If the OPAS server doesn't understand the user command, then a |
286 |
reply with bits 20 and 21 set and a zero data length field can be |
287 |
used. |
288 |
|
289 |
Summary: user command |
290 |
--------------------- |
291 |
0 4 8 12 |
292 |
+-----------+-----------+-----------+ |
293 |
| header | user data |data length| |
294 |
+-----------+-----------+-----------+ |
295 |
|
296 |
Fields |
297 |
------ |
298 |
|
299 |
Header's flags bit 19 must be set to indicate it's an user command. |
300 |
For the reply, the reply flag (bit 20) must be also set. |
301 |
|
302 |
The user data field is always a 32 bit free area which is returned |
303 |
intact by the OPAS server to the OPAS client. |
304 |
|
305 |
The data length field is the user command data length following |
306 |
this message. |
307 |
|
308 |
The user command data should not be counted in the header's length |
309 |
field, which should always be set to 12 - 4 = 8 for user command |
310 |
messages. This allow long user command query or reply to be |
311 |
supported. |
312 |
|
313 |
|
314 |
Appendix A - Resource Classification |
315 |
|
316 |
|
317 |
A.1 OPAS types of open proxy |
318 |
|
319 |
O. Unknown/generic type |
320 |
1. WinGate proxy |
321 |
2. Socks v.4 |
322 |
3. Socks v.5 |
323 |
4. HTTP proxy (using the "CONNECT" method) |
324 |
5. HTTP "POST" |
325 |
6. Insecure Cisco router |
326 |
7. Insecure IRC bouncer |
327 |
|
328 |
A.2 OPAS reply error numbers |
329 |
|
330 |
Error numbers from 0 to 255 (8 lower bits) are reserved by the OPAS |
331 |
protocol as follow: |
332 |
O. Unknown error (still an error) |
333 |
1. Network is down |
334 |
2. Network is unreachable |
335 |
|
336 |
Other numbers (on 24 higher bits) are available for private usage. |