"John R. Jackson" <[EMAIL PROTECTED]> writes:
> This is described in the doc I quoted in the other letter, but in brief,
> Amanda only uses UDP to contact the client and make a request (e.g.
> sendsize, selfcheck, sendbackup).
I do some firewalling and network administration, so I'll allow myself
to digress into some reflections on the "firewallability" -- for lack
of a better word -- of Amanda.
These UDP datagrams use a specific destination port, and are thus
easily firewallable. Using OpenBSD's PF configuration syntax as an
example (and assuming "pass out" is the default on all interfaces):
pass in on $internal_if proto udp from $amanda_server to $amanda_client port = amanda
> "Small" answers (everything but sendbackup) come back as UDP as
> well.
These, too, are easily described in terms of firewall rules, e.g.:
pass in on $dmz_if proto udp from $amanda_client port = amanda to $amanda_server
(Here, afaict, the source port is the amanda port, and the destination
port is the (random) source port from the request.)
> But the real data motion (e.g. the actual backup image) you pointed
> out from your log file is done via TCP (the names stream_server and
> stream_accept imply a "stream", a.k.a. TCP, connection).
This one's a bit worse, as the port numbers used on both sides are
quite random. Opening for this through a stateless firewall would
create a very big hole[1] between the backup server and the client,
but it could be done somewhat like this[2]:
pass in on $internal_if proto tcp from $amanda_server port $something to
$amanda_client port $something_else
pass in on $dmz_if proto tcp from $amanda_client port $something_else to
$amanda_server port $something
block in log on $dmz_if proto tcp from $amanda_client port $something_else to
$amanda_server port $something flags S/SA
The trouble is that both $something and $something_else are huge port
ranges, som the two hosts could do almost anything together. (The
"flags S/SA" block rule is there to prevent the client from initiating
a connection with the server.)
A better effect could be achieved by using a stateful firewall rule,
but $amanda_server would still have to be able to contact quite a lot
of ports on $amanda_client, not necessarily doing amanda stuff.
I understand from another post that the range ($something_else) of
ports that the amanda client offers to open can be configured at
build-time, and this makes for tighter, but not tight, firewall rules.
A different firewalling approach would be to create an "amanda
firewall plug-in", that watched the amanda UDP packets for port
numbers to use and opened these up through the firewall dynamically.
This is a common way to pass active FTP through firewalls, but afaik
no-one has written such a beast for Amanda.
Yet another way would be to let the amanda client listen on a specific
TCP port for all the data connections, and multiplex these to the
different processes as needed. This would probably require changes in
the protocol, and it would certainly require changes in the
implementation, but the firewall rules would be much simplified.
Assuming we use the amanda port for TCP as well, the complete rules
needed to let amanda through would become:
pass in on $internal_if proto { tcp, udp } from $amanda_server to $amanda_client port
amanda
pass in on $dmz_if proto { tcp, udp } from $amanda_client port amanda to $amanda_server
block in log on $dmz_if proto tcp from $amanda_client port amanda to $amanda_server
flags S/SA
[1] not necessarily exploitable, but still a hole
[2] untested and probably buggy.
--
Arvid
