External Access to Bug Tracking but not Source Conrol

[ptmruphy]

I would like for my consultants to be able to report bugs while on the road using the web interface. In order to accomplish this, I have opened up the firewall to the Fortress Web Server (changing the default port). If the bug tracking software gets broken into, it's not THAT big of a deal, as I have disabled access for the web users to the repository.

However, this process also allows the Fortress Client to connect to the Fortress Source Code Repository (Vault) database using the same address as the "Server" in the client login. I really don't want to allow this. Obviously the source code is the more sensitive data, and I would like for that to only be accessed on the internal network.

Is there a way to do this - Allow web access to bug tracking, but no allow Client access to the repository?

Thanks,

PTM

[DetroitJ]

I realize that this probably isn't the answer that you are looking for but, you could build your own web interface for bug tracking. SourceGear provides a very nice API to access work items. I built my own front end to the work item tracking for very much the same reason.

[ptmruphy]

Yeah, not exactly what I am looking for. I don't have the IT staff for that.

Hopefully Linda or someone else at SourceGear will have some suggestions.

[Beth]

You could set permissions to Deny on any of the source control repositories for the logins you don't want to see it. They would still see the tab, but can't see any repositories or code. That would be set in the repository access portion of the admin web page. You don't want to set that in folder security, because the users could still see a list of the repositories then.

[ptmruphy]

Beth,

Thanks for the response, but not exactly what I am looking for.

I don't want the Fortress Client (GUI Application) to be able to connect outside of the firewall. As I have it right now, the web client can connect (as I want it to, and I have set the permissions how I want them so most users cannot see the source code) externally. However, so can the Fortress GUI Client, which I don't really want it to.

This is really a security issue. If someone breaches security and can only login to the web client, there is not a lot a damage that can be done. However, if someone can connect with the GUI Client, that is a different story, as source can then be modified, deleted, changed, etc.

Make sense?

Thanks,

PTM

[Beth]

If a user doesn't have permissions to see code or a repository, it won't matter if they are using the web client or the GUI client. They wouldn't be able to get to the code in the GUI client either.

Of course, if what is breached is an internal user's login credentials, then a person could log into Fortress and make changes. Fortunately, all of that will be reversible and can be tracked down, so the damage won't be permanent. It would cost some work time to get back though. If one gets the admin account and obliterates code, then you would restore your last SQL backup to get to where you were before.

An internal login that has permissions could also just use the web client to get an entire copy of the code if it was just code they wanted to take.

When you are worried about a breach, are you just concerned about the logins that don't have code access, or are you also concerned about your internal user's logins and passwords being obtained? Brute force is the only way I think one could come up with an internal user's logon, unless the internal user gave it out or wrote it down where others could see it.

Also, are you only concerned about changes to the code or repository being checked in, or are you concerned about someone having access to see the code and pull it down?

I'm guessing that you could block soap requests at the firewall, which should be enough to stop a GUI client from connecting. I need to speak with a few others before I can say more on that.

[jeremy_sg]

You could go to your IIS manager, and right-click the VaultService.asmx, and click Properties. In the File Security tab, click the IP Address and Domain Restrictions Edit button. Select the Denied Access radio button, and create an exemption for your internal ip addresses. No external IP should be able to load the asmx file, or log in with the full client.

Other asmx files that could be similarly locked down are: VaultAdminService.asmx and Fortress/DragnetWebService.asmx.

[Xavier]

Hi

this would obviously be a great idea. The problem is not that someone would obliterate the code, it that he could steal it !!

My suggestion is that some users could only access the website locally (most won't go on customer's site) and that only some users could access fortress remotely.

Best regards

Xavier PICAT

[lbauer]

Thanks for the suggestions.

[ptmruphy]

Xavier - you are exactly correct in the reasoning. Our source code is our business and I don't really want anyone to have access to it, no matter how remote the possibility.

Linda - I presume by your comment that there is no way to do this currently?

Thanks,

PTM

[lbauer]

There's no setting in Vault/Fortress to limit client access based on whether the client is local or remote. There may be other ways to do this using IIS, firewalls, etc., but we don't have any recommended configurations, as we've never tried to do this.

[Xavier]

Hello

I do not think there is other way to do that as IIS cannot which user is logged in.
And it would be easier and obvious, rather than going to a third party module.

Regards

XAvier

[jeremy_sg]

There are two different levels of security being discussed on this thread.

1. Restricting access to the asmx files based on IP. This was requested by ptmruphy to prevent all GUI client's connecting from outside the firewall. This has to be done through IIS or a firewall or a proxy. ptmurphy's concern was that if the asmx is available, then an attacker could find some way to bypass the built-in repository access permissions in Fortress. I gave him a way to do that using IIS to reject asmx calls based on IP address.

2. Restricting access by a Fortress User/IP combination. This has all of the downsides that ptmruphy distrusted about using repository access restrictions (the asmx file has to be open to the world). Also, it seems like a much simpler solution to set up a reverse proxy that requires authentication when requests come from outside the firewall. The reverse proxy can then apply rules based on the authenticated user, and those rules can be much more powerful than what we can build into Fortress. One of the benefits of building our product on existing web protocols is that all of the tools and knowledge around securing web sites can be used to secure Fortress.

[ptmruphy]

Jeremy,

Thanks for the detailed explanation and suggestions. I will get with our IT department and block access based on IP address. We do have a VPN, so anyone outside the physical four walls would have to have a secure VPN connection to log in via the full GUI.

Thanks again,

PTM

[jeremy_sg]

You're welcome.