[Buildbot-devel] proxy support?

[Benoit Sigoure]

Quoting Brian Warner <warner-buildbot at lothar.com>:

>> We have a situation where our buildbot master for an Open Source project
>> we use lives outside the company, but we would like to run buildbot
>> slaves for two target platforms inside the company firewall.
>> Our sysadmin (rightly) refuses to just open the port the buildbot master is
>> listening on (9989),
>
> <rant directed_against="that sysadmin's policies, not you!">
>
> I have to disagree with that "rightly" there. I know it seems to be
> fashionable in contemporary IT circles to lock down everything inbound and
> outbound, and to refuse to honor requests to open ports, but what purpose
> does this serve other than to inhibit their customers (i.e. the employees)
> from getting their job done?
>
> I appreciate that network-using applications are too hard to implement safely
> and represent too large of an attack surface, such that prohibiting arbitrary
> inbound connections represents a reasonable compromise between safety and
> utility: the practice is meant to protect internal machines that are too
> buggy to protect themselves, at the expense of being unable to use the
> network in new and interesting ways.
>
> And to protect certain services on external machines, some environments
> require that all connections to, say, port 25 must go through an
> accounting/proxy box, prohibiting any direct connection to external hosts at
> this port. This allows the proxy box to function as a monitoring tool to
> detect when an internal machine is spewing spam, probably because it has been
> converted into a spam-zombie by a virus that arrived through some other
> vector. This is a compromise between protecting external hosts and reducing
> the robustness and efficiency of the network (now all your outbound mail is
> dependent upon that one accounting/proxy box, even though your local machine
> is perfectly capable of speaking SMTP itself).
>
> But what benefit can there be to prohibiting outbound connections to a
> non-well-known port like 9989? There aren't any public services being offered
> there (except for the buildmaster you're trying to connect to), so there's
> nothing external to protect. Malware that takes over a local machine that
> wants to phone home will go through some other port, usually 80, to make
> itself look less suspicious, and will probably just take advantage of the
> same proxy settings as everything else on your system.
>
> If the goal of the proxy/firewall is monitoring, then the sysadmin would want
> the different kinds of traffic to look as different as possible. Forcing both
> virus authors and application developers to make their traffic pretend to be
> HTTP on port 80 just to get past these filters is only reducing the amount of
> information available, and making it more expensive to inspect the packets to
> figure out what they're for.
>
> (in a related vein, requiring that applications run as root to listen on port
> 80 increases the capabilites of the server, which makes any bug or server
> compromise much more dangerous, and/or requires code to shed root after
> obtaining the port which is easy to get wrong)

This is not true, most of these daemons are set-uid root and open the 
privileged
port as root and then drop their privileges.

>
> It's hard for me to imagine a reason for these sorts of policies that doesn't
> stem from either a desire for power/control or from a lack of analysis. If
> this were my office, I'd ask the sysadmin to reconsider that policy, and if
> they wouldn't, I'd ask the management to reconsider the sysadmin.
>
> In an engineering environment, IT is there to provide safe services to the
> engineers. If there is an antagonistic relationship between the two,
> something is wrong.
>
> </rant>
>
> Whew! :)
>
> So I'd ask your sysadmin if they would allow just your buildslave to make a
> direct connection to the buildmaster, at that one port: a hole in the
> firewall that is specific to the 3-tuple of (buildslave_ipaddr,
> buildmaster_ipaddr, buildmaster_port). If they refuse, ask them what security
> benefit is gained by that prohibition (at least make them think about the
> question.. they may benefit in other ways from doing that sort of analysis).
> Then rig up some sort of proxy to work around the bug.
>

I mostly agree with this but the fact is that many sysadmins out there just
don't want to bother, they lock up everything and when something goes wrong
(worms bypassing the firewall by going through the web proxy, for instance)
they just shrug and go like "yeah but it's using the port 80, what can we do
against this? doh!"

The thing is, as long as you can send any kind of data to a remote host 
(be it a
TCP, UDP or ICMP packet) you can just reach the whole world by means of
proxies/tunnels (DNS tunnels, ICMP tunnels, HTTP tunnels, SSH tunnels, 
etc) and
that's the reason why restricting outgoing connections is completely 
stupid and
pointless (unless they can argue that they can't be blamed because the worms
are spreading through the port 80 whereas they could be blamed if they let the
eMule or BitTorrent ports open, although it does not prevent people from
downloading through a SSH/HTTP tunnel).

I would not bother with such sysadmins, simply set up SSH tunnels. It easily
scales to multiple buildfarms (I have 12 tunnels for 12 buildfarms), the
connectivity is good (quite reliable, good payload etc.) and data privacy is
ensured by SSH (which is a good thing, it makes me sleep better at night).

Cheers,

-- 
SIGOURE Benoit aka Tsuna
   _____
  /EPITA\ Promo 2008, LRDE