6

A friend's start-up has implemented a number of business critical services on a Hudson/Jenkins server run on a Tomcat container. This is not an open-source project, in fact many aspects of this project are confidential. Jenkins is used primarily as a means of running batches & gthering results from those batches.

To some-extent the system has been locked down, for example a plugin has been installed which is intended to block brute-force password guessing attacks. The Jenkins system has been configured to the only thing you can see before you log-in is a login screen, hence these users can re-configure or run anything on the Jenkins server.

The question: Does this system pose any significant security threat to the business? Have we taken all the relevant, reasonable security measures.

For example, it's possible that some kind of as-yet unknown vulnerability in the stack might become the basis of an exploit, but how concerned should we be about a risk which is at best unquantifiable, at worst only theoretical?

Improve this question
0

4 Answers 4

Reset to default
7

You need to take measures like :

  • A firewall to make sure only the ports that are needed to be accessible are
  • Whitelist rather than blacklist (meaning, deny access from all and just give access to whatever actually needs access)
  • Should it be accessible from the internet ? (Is a VPN maybe enough)
  • ...

And there might always be an exploit, the problem with exploits is you never know when someone will find a hole in your system. And you can not grade how concerned you should be unless you take a look at the source code and design of the service. When you see it is has poor validation or bad design, you know you have to be alarmed, if it is well-designed ,well-coded and there is decent validation, you can be less concerned. But there is always a possibility that it might happen.

Your question is quite broad on one hand and very localized on the other.

Improve this answer
13
  • 1
    "you can not grade how concerned you should be unless you take a look at the source code and design of the service" Nonsense - If you could find exploits/vulnerabilities by having just anyone eyeball the code, commercial software (where hundreds of people get paid to do nothing but eyeball code) would be exploit free. At best you can find obvious flaws in the design of the software (presuming you are at least a good a coder as the writer)
    – Jim B
    Commented Jan 17, 2012 at 12:47
  • 2
    I did not mean it that way, but you can at least find how concerned you should be. I meant if it is crappy code you know it can be a threat, otherwise you can be less concerned.
    – Lucas Kauffman
    Commented Jan 17, 2012 at 12:48
  • 3
    @Jim B: There is an obvious difference between Open Source, a 'hodgepodge' and bad code.
    – Dave
    Commented Jan 17, 2012 at 16:45
  • 2
    So from your security perspective closed source is better ? This means security through obscurity...
    – Lucas Kauffman
    Commented Jan 17, 2012 at 17:56
  • 2
    Indeed you expect it but you don't know it.
    – Lucas Kauffman
    Commented Jan 17, 2012 at 21:46
5

If it's not possible to move Hudson/Jenkins to another server, then I'd use a reverse proxy to disable remote access to anything but Hudson (also add SSL).

There's always a probability that there are bugs in Tomcat in Hudson, etc. You can only minimise the impact they can cause.

Improve this answer
4

There is a risk. That risk is unquantified (we don't know, or at the moment care, how risky it is). Against that risk, there's no benefit to leaving it public. Thus, it's not really worth evaluating the risk because whatever that risk is, the ratio is against nothing.

Since I know from another question you were looking at EC2, make use of a private security zone that only allows access from your private company IP addresses. If you do keep it internal instead of on EC2, I suggest making similar efforts to drop any traffic that isn't from your expected network.

Improve this answer
1

Looking at your setup, I am wondering whether you really need access from outside the company? If yes, can you use VPN, HTTPS, certificates, ... To secure the communication from your client to the Jenkins Server?

One of your comments is really concerning me:

... these users can re-configure or run anything on the Jenkins server.

Do the users need to be able to do anything on that Jenkins server (Only give permission/access to what is actually needed and not what might be needed in some unforeseeable future)? Can the authority be lowered for Jenkins/Tomcat (Does Jenkins runs with root/service level authority)? Can you limit the users to be viewers only when they are connecting from outside the company? How about securing your company network from any possible threat from the Jenkins server (Firewalls). In other words treat the Jenkins server as if it would be not part of your company network.

Improve this answer

You must log in to answer this question.