Item 1:   Bacula Dir, FD and SD to support proxies
  Origin: Karl Grindley @ MIT Lincoln Laboratory <kgrindley at ll dot mit dot 
edu>
  Date:   25 March 2009
  Status: proposed

What:
Support alternate methods for nailing up a TCP session such as SOCKS5, SOCKS4 
and HTTP (CONNECT) proxies.  Such a feature would allow tunneling of bacula 
traffic in and out of proxied networks.

Why:
Currently, bacula is architected to only function on a flat network, with no 
barriers or limitations.  Due to the large configuration states of any network 
and the infinite configuration where file daemons and storage daemons may sit 
in relation to one another, bacula often is not usable on a network where 
filtered or air-gaped networks exist.  While often solutions such as ACL 
modifications to firewalls or port redirection via SNAT or DNAT will solve the 
issue, often however, these solutions are not adequate or not allowed by hard 
policy.

In an air-gapped network with only a highly locked down proxy services are 
provided (SOCKS4/5 and/or HTTP and/or SSH outbound) ACLs or iptable rules will 
not work.

Notes:
Director resource tunneling: This configuration option to utilize a proxy to 
connect to a client should be specified in the client resource
Client resource tunneling: should be configured in the client resource in the 
director config file?  Or configured on the bacula-fd configuration file on the 
fd host itself?  If the ladder, this would allow only certain clients to use a 
proxy, where others do not when establishing the TCP connection to the storage 
server.
Storage resource tunneling: right now bacula does not initiate TCP session from 
the storage resource, however, if Item 2 is implemented, proxy support would be 
highly desired here as well.

Also worth noting, there are other 3rd party, light weight apps that could be 
utilized to bootstrap this.  Instead of sockifing bacula itself, use an 
external program to broker proxy authentication, and connection to the remote 
host.  OpenSSH does this by using the "ProxyCommand" syntax in the client 
configuration and uses stdin and stdout to the command.  Connect.c is a very 
popular one. 
(http://bent.latency.net/bent/darcs/goto-san-connect-1.85/src/connect.html).  
One could also possibly use stunnel, netcat, etc.

------------------------------

Item 2:   Bacula FD support callback to SD for TCP sessions
  Origin: Karl Grindley @ MIT Lincoln Laboratory <kgrindley at ll dot mit dot 
edu>
  Date:   25 March 2009
  Status: proposed

What:
Ability to configure, based on the client resource -> storage resource, which 
direction the TCP handshake is established.  Ie, if a file daemon is firewalled 
off via a one way connection (NAT or proxy), one could configure the storage 
daemon to establish the TCP connection to the file daemon to funnel data to the 
storage device(s).

Why:
Currently, bacula is architected to only function on a flat network, with no 
barriers or limitations.  Due to the large configuration states of any network 
and the infinite configuration where file daemons and storage daemons may sit 
in relation to one another, bacula often is not usable on a network where 
filtered or air-gaped networks exist.  While often solutions such as ACL 
modifications to firewalls or port redirection via SNAT or DNAT will solve the 
issue, often however, these solutions are not adequate or not allowed by hard 
policy.

In an air-gapped network with only a highly locked down proxy services are 
provided (SOCKS4/5 and/or HTTP and/or SSH outbound) ACLs or iptable rules will 
not work.

The ability to reverse the TCP handshake would be extremely useful and allow 
bacula to play on many other network architectures.

Notes:
Since this affects the all clients, this should be configured (at least) as 
part of the client and maybe storage resource within the director.  Perhaps a 
way to specify the handshake direction based on the storage resource name would 
be useful.  Configuring director callbacks from the client (when the director 
cannot establish the tcp connection) might also be an idea, but not sure how 
one would implement this since the director kicks an event by nailing up a TCP 
session.

------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to