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