8

I've been told that I might have more luck posting here than on Stack Exchange, so here goes:

I'm looking for a way to lock down a 3rd party application in IIS. It's a web service, so there's no login page or anything, it's meant for use in a VPN environment. I'm trying to put it online without a VPN and am thinking of ways to add some sort of security to it. I need to restrict it to certain networks, its a business product, so I can probably get away with saying that you need to be on a private network (ie not public wifi) to use it. My idea is to use IP Address Restriction in IIS, and write an app that the users install and have it update the server with their current IP every few minutes, the server then blocks all except the ones recently updated.

How secure would this be? Is there a major flaw in this idea? Or is there perhaps a better way to do this in IIS?

edit: To clarify - the software is not modifiable by me. It consists of a few web applications in IIS, that are WCF web services. Then the client computer has a program which connects to those. I am not able to edit the client program or the server, I'm merely hoping to either allow or deny the connection by injecting some sort of security measures onto IIS, or perhaps intercept the packets in conjunction with my own custom software that could be installed on the client PC to do the authentication.

Improve this question

2 Answers 2

Reset to default
8

Really does depend on your threat model, how valuable is the information and functionality offered by the web service? What type of attackers and specific attacks are you worried about?

IP address restriction is the most basic form of protection and really does not give you any security. It is trivial to bypass via a proxy for example. Also if you whitelist a corporate public address, you have no idea what machines behind that NAT are connecting. So if it is a basically a public service or you are using IP address restriction as a defense in depth mechanism to authentication then that is fine otherwise you are getting no security benefit and may as well not do it (for the trade-off in additional management and troubleshooting). Getting users to install anything with the troubleshooting and support this involves is generally a very bad idea.

If it is a valuable web service the standard way to authenticate is:

  • Mutual authentication via certificates. http://msdn.microsoft.com/en-us/library/aa292114%28v=vs.71%29.aspx . This provides you strong authentication and no passwords to manage. A certificate cannot be brute-forced nor guessed and you provide assurance to the third parties that they are connecting to the genuine service. You can cut the certificate cost by using something like startssl.com but you do have to issue, support install, renew, revoke certificates

  • API key - the other most popular method is to provide an API key for each user of the web service. This is effectively a password and carries all the risks and benefits of a password. You need sufficient length, complexity, lockout/back-off to mitigate brute-force and guessing risks

I would be very careful about putting a web service designed for an internal corporate environment meant to be used over a VPN on the Internet. I would recommend getting it security tested from an application and infrastructure perspective before you do this. There is a high likelihood of cross site scripting, SQL injection and other common web application vulnerabilities especially if you are using REST web services.

Improve this answer
6
  • Thanks for your response. I am unable to edit the 3rd party web service (or the client that consumes that web service) at all, except for the web application settings in IIS, am I able to setup the certificate authentication without editing web configs and the code itself?
    – RodH257
    May 24, 2011 at 13:21
  • Yes you can do it with just IIS, no changes to code or webconfig required: microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/… . Alternatively setup a ngix proxy in front: wiki.nginx.org/HttpSslModule#ssl_client_certificate
    – Rakkhi
    May 24, 2011 at 15:56
  • @Rakkhi, you'd still need to configure the client to use its private key and certificate. It's not always easy to do without modifying the client code (it really depends on how it has been designed).
    – Bruno
    May 24, 2011 at 18:45
  • Is it possible i could write my own software to do the certificate authentication for their IIS website, and then when they run the actual software it has already done the authentication?
    – RodH257
    May 25, 2011 at 3:12
  • @RodH257 probably although you will get better help on that on stackoverflow. I had assumed the client was anther web server or browser in which case installing the client certificate is trivial
    – Rakkhi
    May 25, 2011 at 9:55
6

According to the OWASP Top Ten (note that this link is not the latest because they have dumbed down the T10 Project over time) -- using authentication based on IP addresses, IP prefixes, or DNS names should not be relied upon. It's a dangerous practice because A) it is not tied to a single person per credential, and B) it can be spoofed, tricked, proxied, or otherwise made available to adversaries for illegitimate use.

Do not rely upon spoofable credentials as the sole form of authentication, such as IP addresses or address range masks, DNS or reverse DNS lookups, referrer headers or similar

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .