Commit | Line | Data |
---|---|---|
e80b4c2d MW |
1 | \documentclass[article, a4paper, 10pt, notitlepage, numbering]{strayman} |
2 | \usepackage[palatino, helvetica, maths=cmr]{mdwfonts} | |
3 | \usepackage[T1]{fontenc} | |
4 | \usepackage{at} | |
5 | \usepackage[mdwmargin]{mdwthm} | |
6 | \usepackage{mdwtab} | |
7 | \usepackage[all, dvips]{xy} | |
8 | ||
9 | \atdef l#1{{\normalfont\sffamily #1}} | |
10 | \atdef c#1{\textbf{#1}} | |
11 | ||
12 | \newtheorem*{observation}{Observation} | |
13 | ||
14 | \def\cbox#1{% | |
15 | \vbox{% | |
16 | \let\\\cr% | |
17 | \halign{% | |
18 | \hfil\strut\ignorespaces##\unskip\hfil\cr% | |
19 | #1% | |
20 | \crcr% | |
21 | }% | |
22 | }% | |
23 | } | |
24 | ||
25 | \errorcontextlines=999 | |
26 | ||
27 | \begin{document} | |
28 | \title{@l{distorted.org.uk} network design} | |
29 | \author{Mark Wooding} | |
30 | \maketitle | |
31 | ||
32 | \thispagestyle{empty} | |
33 | \pagestyle{empty} | |
34 | ||
35 | \tableofcontents | |
36 | \listoffigures | |
37 | \listoftables | |
38 | ||
39 | \clearpage | |
40 | \pagestyle{fancy} | |
41 | ||
42 | %%%-------------------------------------------------------------------------- | |
43 | \section{Concepts} | |
44 | ||
45 | We begin by defining our basic concepts. | |
46 | \begin{description} | |
47 | \item[@c{Safe}] A @c{safe} network is one whose hosts are protected from | |
48 | potentially dangerous network traffic. Hosts on a @c{safe} network may | |
49 | communicate only (a) using trusted protocols (e.g., SSH) or (b) with | |
50 | @c{trusted} hosts. | |
51 | \item[@c{Trusted}] A @c{trusted} network is one whose hosts are permitted to | |
52 | communicate with @c{safe} networks. | |
53 | \end{description} | |
54 | ||
55 | \begin{observation} | |
56 | It is impossible to protect hosts on a @c{safe} network from each other. | |
57 | Therefore, a @c{safe} network must be @c{trusted}. As an immediate | |
58 | corollary, an @c{untrusted} network cannot be @c{safe}. | |
59 | \end{observation} | |
60 | ||
61 | We therefore distinguish three types of networks: | |
62 | \begin{enumerate} | |
63 | \item @c{Safe}, and therefore @c{trusted}. | |
64 | \item @c{Trusted} but @c{unsafe}. | |
65 | \item @c{Untrusted}, and therefore @c{unsafe}. | |
66 | \end{enumerate} | |
67 | ||
68 | ||
69 | %%%-------------------------------------------------------------------------- | |
70 | \section{Existing hosts} | |
71 | ||
72 | We have the following hosts. All of them should be @c{trusted}. | |
73 | \begin{description} | |
74 | \item[@l{metalzone}] A Linux server and desktop machine. It is capable of | |
75 | providing most services to the network, including mail, news, web proxying, | |
76 | etc., and of providing services to the Internet at large. It can also | |
77 | provide a powerful and versatile firewall. It should not be kept @c{safe}. | |
78 | \item[@l{tubescreamer}] A dual-boot Linux desktop and Windows desktop. It | |
79 | spends most of its time running Windows. It must be kept @c{safe}. | |
80 | \item[@l{fuzzface}] A small Linux laptop. It doesn't have enough disk | |
81 | capacity for running services, and wouldn't be around or turned on | |
82 | regularly enough anyway, but it is capable of firewalling itself. We'd | |
83 | like to attach this to a wireless network. It need not be kept @c{safe} | |
84 | and we'd like it to be @c{trusted}. | |
85 | \item[@l{guvnor}] An ADSL router. It is capable of providing minimal | |
86 | services, and it has a fairly powerful firewall built-in. It must not be | |
87 | kept @c{safe}. | |
88 | \item[@l{evolution}] (Not yet commissioned.) A wireless access point. It is | |
89 | capable of running Linux, but due to limited memory capacity cannot provide | |
90 | many services. It has a powerful and versatile firewall. It cannot be | |
91 | kept @c{safe}. | |
92 | \end{description} | |
93 | ||
94 | We may also have guest machines. We suspect that keeping these @c{safe} | |
95 | would be onerous to our guests, requiring configuration of web proxies and | |
96 | suchlike. Guest machines can probably be @c{trusted}: violations of this | |
97 | trust can be rectified using a cluebat. | |
98 | ||
99 | %%%-------------------------------------------------------------------------- | |
100 | \section{Structure} | |
101 | ||
102 | We require the following physical networks. | |
103 | \begin{itemize} | |
104 | \item A (wired) Ethernet, for the permanent desktop machines and servers, and | |
105 | for any guest hosts which need physical wiring. | |
106 | \item A wireless Ethernet, for laptops. | |
107 | \end{itemize} | |
108 | ||
109 | ||
110 | \subsection{The wired network} | |
111 | ||
112 | Some hosts on our wired network (particularly @l{tubescreamer}) must be | |
113 | @c{safe}; others (e.g., @l{metalzone}) must not in order for them to do their | |
114 | jobs. It is tempting to split the wired network into two parts: @c{unsafe} | |
115 | and @c{safe}. But this introduces a new potential point of failure, and | |
116 | anyway fails to acknowledge the fact that both sides are already @c{trusted}. | |
117 | ||
118 | ||
119 | \subsection{The wireless network} | |
120 | ||
121 | It is important to note that the security provided by wireless networks is | |
122 | minimal, and cannot be relied upon. Therefore a wireless network must be | |
123 | both @c{untrusted} and @c{unsafe}. We may allow unrestricted communication | |
124 | with the global Internet, and to other @c{unsafe} networks, though hosts on | |
125 | the wireless network must not be allowed to communicate with @c{safe} | |
126 | networks. | |
127 | ||
128 | This restriction is annoying, and motivates us to introduce a @/virtual | |
129 | private network/, providing authentication and encryption; hosts on the VPN | |
130 | can be @c{trusted}, since we know who they are and (ideally) how they're | |
131 | configured. | |
132 | ||
133 | ||
134 | \subsection{Virtual private networks} | |
135 | ||
136 | As discussed earlier, we want a VPN so that hosts attached to the wireless | |
137 | network can communicate with @c{safe} hosts. Also, we wish to participate in | |
138 | the Sinister Green VPN. This introduces two kinds of VPN: our own can be | |
139 | @c{trusted}, but the SGVPN should not be. | |
140 | ||
141 | The question arises: should our VPN be @c{safe}? We can see no particular | |
142 | reasons why it shouldn't be: after all, a host on the VPN already has a route | |
143 | to the global Internet (either it's communicating with us over the Internet | |
144 | already, or it's on some @c{unsafe} network). | |
145 | ||
146 | Finally, we wish to provide some @/emulated hosts/, running old operating | |
147 | systems; for example, a machine running ITS.% | |
148 | \footnote{The Incompatible Timesharing System -- an old PDP--10 operating | |
149 | system, which hosted MACLISP and the original EMACS implementation.} | |
150 | Such old operating systems are likely to have major security problems, and | |
151 | should be kept @c{safe} from outside attack. It seems reasonable to place | |
152 | these emulated hosts in the @l{virtual} network, since (a)~we've just | |
153 | determined that @l{virtual} hosts should be @c{safe}, and (b)~emulated hosts | |
154 | are `virtual' in a sense anyway. | |
155 | ||
156 | ||
157 | %%%-------------------------------------------------------------------------- | |
158 | \section{Networks and numbering} | |
159 | ||
160 | We therefore have the following networks. | |
161 | \begin{description} | |
162 | \item[@l{fretwank} (wired, @c{safe}/@c{unsafe} mix)] Contains @l{guvnor} | |
163 | (router to the Internet and main firewall), @l{metalzone} (main server), | |
164 | @l{evolution} (wireless router), and @l{tubescreamer}. Also contains guest | |
165 | machines allocated addresses by DHCP. | |
166 | \item[@l{wireless} (wireless, @c{untrusted})] Contains @l{fuzzface}, at least | |
167 | sometimes, and a number of guest machines allocated addresses by DHCP; | |
168 | @l{evolution} is its router. | |
169 | \item[@l{virtual} (virtual, @c{safe})] Contains @l{fuzzface} again, and | |
170 | possibly various other hosts. Not really a proper network: more a random | |
171 | collection of point-to-point associations. No dynamic allocation required. | |
172 | \end{description} | |
173 | See figure~\ref{fig:network} for a diagrammatic representation of the | |
174 | network, and how the various hosts fit into it. | |
175 | ||
176 | \begin{figure} | |
177 | \[\begin{xy} | |
178 | 0; <1cm, 0cm>: | |
179 | (0, 0) ="fwA"; (11, 0) ="fwB" **[butt][|3pt][=NET]@{-}, | |
180 | ?(.5) ="fwM" ?(.18) ="fwX" ?(.82) ="fwY", | |
181 | "fwM" *+!U\cbox{@l{fretwank} (172.29.199.0/25)}, | |
182 | "fwM" + (0, 2) *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>] | |
183 | \cbox{@l{guvnor} \\ 83.105.60.35 \\ 172.29.199.1} ="guvnor", | |
184 | "guvnor"; "fwM" **@{-}, | |
185 | "guvnor"; + (0, 4) | |
186 | *+=(4, 3)[o][F][F*:red] \cbox{Global \\ Internet} | |
187 | **@{-} ?<>(.5) *@{//} *+!L{A}, | |
188 | "fwY"; p + (0, 2) | |
189 | *+=(3, 1.5)[F:<12pt>]\cbox{(DHCP guests)} | |
190 | **@{-}, | |
191 | "fwY"; p - (0, 2) | |
192 | *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>] | |
193 | \cbox{@l{evolution} \\ 172.29.198.1 \\ 172.29.199.3} ="evolution" | |
194 | **@{-}, | |
195 | "fwX"; p + (0, 2) | |
196 | *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>] | |
197 | \cbox{@l{tubescreamer} \\ 172.29.199.65} | |
198 | **@{-}, | |
199 | "fwX"; p - (0, 2) | |
200 | *+=(3, 1.5)[F:<12pt>][F*:green:<12pt>] | |
201 | \cbox{@l{metalzone} \\ 172.29.199.2} ="metalzone" | |
202 | **@{-}, | |
203 | "metalzone" + (-3, 1) ="sgvpnA"; p - (0, 10) ="sgvpnB" **[NET]@{-}, | |
204 | ?(.5) ="sgvpnM", | |
205 | "sgvpnM" *[left]+!R\cbox{SGO VPN (various RFC1918 addresses)}, | |
206 | "metalzone"; p - (3, 0) **@{-} ?<>(.5) *@{//} *+!U{B}, | |
207 | "metalzone" + (3, 1) ="vpnA"; p - (0, 8) ="vpnB" **[NET]@{-}, | |
208 | ?(.5) ="vpnM", | |
209 | "vpnM" *[left]+!L\cbox{@l{virtual} (172.29.199.128/28)}, | |
210 | "metalzone"; p + (3, 0) **@{-} ?<>(.5) *@{//} *+!U{C}, | |
211 | "metalzone" - (0, 2) | |
212 | *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>] | |
213 | \cbox{@l{fuzzface} \\ 172.29.199.129} ="fuzzface"; | |
214 | p + (3, 0) **@{-}, | |
215 | "fuzzface" - (0, 2) | |
216 | *+=(3, 1.5)[F:<12pt>][F*:yellow:<12pt>] | |
217 | \cbox{@l{mz} \\ 172.29.199.130} ="mz"; | |
218 | p + (3, 0) **@{-}, | |
219 | "mz" - (0, 2) | |
220 | *+=(3, 1.5)[F:<12pt>]\cbox{(VPN hosts)} ="x"; | |
221 | p + (3, 0) **@{-}, | |
222 | "x" - (0, 2) | |
223 | *+=(3, 1.5)[F:<12pt>]\cbox{(SGO hosts)} ="x"; | |
224 | p - (3, 0) **@{-}, | |
225 | "evolution" + (3, 1) ="wlanA"; p - (0, 4) ="wlanB" **[NET]@{-}, | |
226 | ?(.5) ="wlanM", | |
227 | "wlanM" *[left]+!L\cbox{@l{wireless} (172.29.198.0/26)}, | |
228 | "evolution"; p + (3, 0) **@{-} ?<>(.5) *@{//} *+!U{D}, | |
229 | "evolution" - (0, 2) | |
230 | *+=(3, 1.5)[F:<12pt>]\cbox{(DHCP guests)}; | |
231 | p + (3, 0) **@{-}, | |
232 | \end{xy}\] | |
233 | ||
234 | \caption{Diagram of @l{distorted.org.uk} networks} | |
235 | \label{fig:network} | |
236 | \end{figure} | |
237 | ||
238 | We must assign address ranges to these networks. The @l{distorted.org.uk} | |
239 | domain has a block of 512 addresses allocated from the Cambridge G-RIN: | |
240 | 172.29.198.0/23. The low 256 addresses, 172.29.198.0/24, are used for | |
241 | @c{untrusted} hosts; the upper addresses, 172.29.199.0/24, are used for | |
242 | @c{trusted} and @c{safe} hosts. | |
243 | ||
244 | The @c{untrusted} address range is currently only used for the @l{wireless} | |
245 | network. It is allocated 64 addresses. This seems relatively generous: | |
246 | however, there is no small practical limit (such as the number of available | |
247 | ports on switches or hubs) on the number of hosts which can join the network. | |
248 | Since hosts on the network are granted temporary addresses via DHCP, the | |
249 | network can be resized relatively easily by reconfiguring @l{evolution}: a | |
250 | major flag day is not necessary. | |
251 | ||
252 | The @c{trusted} network is more difficult. We start with the wired Ethernet | |
253 | @l{fretwank}. The number of hosts which can join the Ethernet is limited by | |
254 | the number of available ports on the various switches and hubs. Currently we | |
255 | have | |
256 | \begin{itemize} | |
257 | \item 4 ports on @l{guvnor}'s built-in switch, | |
258 | \item 8 ports on a Netgear fast Ethernet switch, and | |
259 | \item 16 ports on an old 10baseT hub, | |
260 | \end{itemize} | |
261 | for a total of 28 ports. (In fact, the total is only 24, since four of the | |
262 | ports would be used up joining the hub and switches together.) Hence, a | |
263 | single block of 32 addresses would suffice. However, this makes | |
264 | administration difficult. Instead, we allocate @/four/ groups of 32 | |
265 | addresses: | |
266 | \begin{itemize} | |
267 | \item a group for @c{trusted} but @c{unsafe} hosts with fixed addresses, used | |
268 | for servers and routers; | |
269 | \item a group for @c{safe} hosts with fixed addresses, used for our | |
270 | vulnerable workstations; | |
271 | \item a group for @c{trusted} but @c{unsafe} hosts with addresses dynamically | |
272 | allocated by DHCP, for guests; and | |
273 | \item a group of addresses reserved for some currently unforeseen purpose. | |
274 | \end{itemize} | |
275 | ||
276 | The VPN is at this stage allocated 32 addresses. This can be increased | |
277 | easily should the need arise; but we envisage that the various VPN hosts will | |
278 | each need individual treatment in the firewall rules. | |
279 | ||
280 | The network address allocations are shown in detail in | |
281 | table~\ref{tab:addresses}. | |
282 | ||
283 | \begin{table} | |
284 | \begin{tabular}[C]{|lll|} \hlx{hv} | |
285 | @*Network* & @*Status* & @*Address range* \\ \hlx{vhv} | |
286 | @l{wireless} & @c{Untrusted} & 172.29.198.0/26 (64) \\ \hlx{v} | |
287 | @l{fretwank} & Mixture & 172.29.199.0/25 (128) \\ | |
288 | \quad Unsafe, fixed & @c{Trusted} & 172.29.199.0/27 (32) \\ | |
289 | \quad Unsafe, DHCP & @c{Trusted} & 172.29.199.32/27 (32) \\ | |
290 | \quad Safe & @c{Safe} & 172.29.199.64/27 (32) \\ | |
291 | \quad Reserved & --- & 172.29.199.96/27 (32) \\ \hlx{v} | |
292 | @l{virtual} & @c{Safe} & 172.29.199.128/27 (32) \\ \hlx{v} | |
293 | Reserved & --- & $\vcenter{ | |
294 | \hbox{172.29.199.160/27 (32)} | |
295 | \hbox{172.29.199.192/26 (64)} | |
296 | } \Bigr\}$ (96) \\ \hlx{vh} | |
297 | \end{tabular} | |
298 | ||
299 | \caption{Network address allocations} | |
300 | \label{tab:addresses} | |
301 | \end{table} | |
302 | ||
303 | ||
304 | %%%-------------------------------------------------------------------------- | |
305 | \section{Firewall considerations} | |
306 | ||
307 | We filter network traffic at four points, shown as | |
308 | `$\begin{xy}*+@{//}\end{xy}$' in figure~\ref{fig:network}: | |
309 | \begin{itemize} | |
310 | \item at the boundary with the global Internet, at @l{guvnor} ($A$); | |
311 | \item at the join between the @l{wireless} network and our @c{trusted} | |
312 | networks, at @l{evolution} ($D$); and | |
313 | \item at the join between the VPNs and our @c{trusted} networks, ($B$ and | |
314 | $C$). | |
315 | \end{itemize} | |
316 | (Technically, since we trust hosts on @l{virtual}, we needn't introduce | |
317 | filtering between it and @l{fretwank}, but doing so is cheap and relatively | |
318 | easy, and it does little harm.) | |
319 | ||
320 | The main purpose of the firewalls is to protect the hosts which are supposed | |
321 | to be @c{safe}. Their secondary purposes are to act as an additional | |
322 | protection for @c{trusted} hosts providing services, and to limit access to | |
323 | some services to @c{trusted} hosts only. | |
324 | ||
325 | ||
326 | \subsection{Externally visible services} | |
327 | ||
328 | The server @l{metalzone} provides a number of services which need to be | |
329 | externally available: these are shown in table~\ref{tab:services}. | |
330 | ||
331 | \begin{table} | |
332 | \centering | |
333 | \begin{minipage}{0.8\textwidth} | |
334 | \begin{tabular}[C]{|*{3}{ll|}} \hlx{hv} | |
335 | @*Service* & @*Port(s)* & | |
336 | @*Service* & @*Port(s)* & | |
337 | @*Service* & @*Port(s)* \\ \hlx{vhv} | |
338 | FTP & TCP 20, 21 & SSH & TCP 22 & SMTP & TCP 25 \\ | |
339 | DNS & TCP/UDP 53 & Finger & TCP 79 & HTTP & TCP 80 \\ | |
340 | Ident & TCP 113 & NTP & UDP 123% | |
341 | %%\footnote{Only to upstream ISP's time servers.} | |
342 | & HTTPS & TCP 443 \\ | |
4acd4890 | 343 | rsync & TCP 873 & GIT & TCP 9418 & TrIPE & UDP 22\,003 \\ \hlx{vh} |
e80b4c2d MW |
344 | \end{tabular} |
345 | \end{minipage} | |
346 | ||
347 | \caption{Externally visible services} | |
348 | \label{tab:services} | |
349 | \end{table} | |
350 | ||
351 | Additionally, @l{metalzone} provides a web proxy on port 3128 which should be | |
352 | available to all hosts, including @c{untrusted} hosts, whose connection to | |
353 | the global Internet is via @l{guvnor}. (Allowing external users to use the | |
354 | proxy is bad, because they can eat up our 'net connection bandwidth very | |
355 | easily. Disallowing @c{untrusted} hosts from using the proxy is silly, | |
356 | though, since they can @/already/ gobble the 'net connection, and using the | |
357 | proxy may help reduce the impact of many users.) | |
358 | ||
359 | Finally, @l{metalzone} supports active FTP, and occasionally other temporary | |
360 | services, on high-numbered ports. TCP and UDP ports with numbers in the | |
361 | range 32\,000--65\,535 should be left unfiltered. | |
362 | ||
363 | ||
364 | \subsection{Trusted protocols} | |
365 | ||
366 | All hosts, including @c{safe} hosts, are permitted to contact any address on | |
367 | TCP port~22, for the purpose of setting up an SSH connection. (Messing about | |
368 | with proxies for SSH is too tedious.) So that this can stand a chance of | |
369 | working properly, we also allow ICMP. This isn't, perhaps, ideal, but all | |
370 | manner of things go wrong if ICMP is blocked. Besides, it means that @/ping/ | |
371 | is likely to work, which is also useful. | |
372 | ||
373 | ||
374 | ||
375 | ||
376 | %%% A | |
377 | %%% 1. Packets from WAN | |
378 | %%% if src-addr in rfc1918-addresses: DROP | |
379 | %%% if src-addr in localnet: DROP | |
380 | %%% if src-addr == guvnor.demon: DROP | |
381 | %%% if dest-addr not in distorted-net: DROP | |
382 | %%% if protocol == icmp: ACCEPT | |
383 | %%% if protocol == tcp and src-port == 22 and ack: ACCEPT | |
384 | %%% if dest-addr in fretwank-safe: DROP | |
385 | %%% if dest-addr in vpn: DROP | |
386 | %%% if protocol == tcp and ack: ACCEPT | |
387 | %%% if dest-addr == metalzone.fretwank and | |
388 | %%% protocol/dest-port in external-services: | |
389 | %%% ACCEPT | |
390 | %%% DENY | |
391 | %%% | |
392 | %%% 2. Packets from LAN | |
393 | %%% if src-addr not in distorted-net: DROP | |
394 | %%% ACCEPT | |
395 | ||
396 | %%% D | |
397 | %%% 1. Packets from WLAN | |
398 | %%% if src-addr not in wireless: DROP | |
399 | %%% if dest-addr not in distorted-net: DROP | |
400 | %%% if protocol == icmp: ACCEPT | |
401 | %%% if protocol == tcp and src-port == 22 and ack: ACCEPT | |
402 | %%% if dest-addr in fretwank-safe: DROP | |
403 | %%% if dest-addr in vpn: DROP | |
404 | %%% if protocol == tcp and ack: ACCEPT | |
405 | %%% if dest-addr == metalzone.fretwank and | |
406 | %%% (protocol/dest-port in external-services or | |
407 | %%% protocol == tcp and dest-port == 3128): | |
408 | %%% ACCEPT | |
409 | %%% DENY | |
410 | %%% | |
411 | ||
412 | ||
413 | \end{document} |