1

I have created a service (WCF) that acts as a backend for a DB. For now it does basic operations such as INSERT, SELECT etc. I have run it locally and now it is time to expose her to the internet and enter 'production'. Is there a best practice to doing so? Bear in mind this service will be hosted on a PC as a Windows Service (not IIS). This is the first time I am putting a Windows Service into production so I am hazy on the details but I think this is the main idea:

  1. On the service: Check for 'rookie' errors such as SQL Injection. Set maximum message sizes to ones marginally higher than the largest message that should be transmitted by my service. Also upgrade self signed X.509 certificate to one issued by a CA. (Where does one store this certificate? Locally on the PC?)

  2. On the PC: Fully patched software (OS etc) and windows firewall with a specific set of rules that allows traffic only on the ports being used (I suppose the safest way to do this is to use the windows tool Allow a program or feature through Windows Firewall ?). Furthermore an updated antivirus running.

  3. On the Network: For the network router, port forward the respective ports being used (the base address is declared as http://localhost:8080 so I guess port 80 for HTTP and 443 for HTTPS? I am using message level Security.)

  4. General precautions: Full message logging on the service to analyze traffic and potential attackers. Also run a Network intrusion detection system such as Snort so that I can sleep a bit better at night.

Am I missing anything obvious?

EDIT

I am new to WCF and creating these types of services in general so I am not sure if I am using the correct terminology.

I have throttled the service by setting an upper bound on the number of maximum concurrent calls, sessions & instances (I realise this does not explicitly protect from HTTP attacks but at least my system will not run out of memory and crash).

As far as I understand the methods in my service can only be called via a SOAP client with the service contracts pre-configured. I am not sure if an attacker can engineer these contracts. Furthermore it seems like anyone who knows the base address of my service can download the service reference and will therefore have the service contracts ready. (Solved: by disabling metadata exchange)

The binding which specifies the communication between endpoints is 'wsHttpBinding' with 'message' level security.

My question is is slightly different though, can the setup of 1,2,3 & 4 as specified above jeopardize the network in which the machine with this service is running?

Kafros
  • 11
  • 3
  • Wait, wait, wait, you are placing a piece of code on the internet without a wbeserver in front of it. That is terrible. You will need to code inside your application defences against HTTP attacks. Get a webserver in front of it, do not run a production application with a listening port open to the internet. – grochmal Sep 06 '16 at 02:45
  • Care to elaborate? I guess this means I should use IIS? – Kafros Sep 06 '16 at 07:43
  • Yes, IIS would be the Microsoft option. But anything that is a proper webserver would do. You could run apache, cherokee, nginx, on a different box and use that as a reverse proxy to the one running the web service. Point being web frameworks are not meant to face the internet, webserver should face the internet. The internet is a bad and evil place where people do scan your servers for vulnerabilities. – grochmal Sep 06 '16 at 15:31
  • I have not read about this as a danger of hosting from a Windows Service before, but the clarification makes sense. I will host using IIS. – Kafros Sep 06 '16 at 15:33
  • @grochmal That is not good advice at all. Opening a service to the internet has 0 technical difference from opening a web server to the internet if the correct security protocols and standards are put in place for the non-HTTP service, which are absolutely implementable for a WCF service running outside of IIS. – Patrick Bell Sep 06 '16 at 18:49
  • @PatrickBell - I disagree, you cannot defend yourself from a DoS on a web framework. You are vulnerable because a framework has no protection on performance and packet level, webservers do. On the other hand, I admit that I never ever did absolutely nothing on an internet facing Microsoft machine. It is my assumption that WCF (as part of .NET) is a framework not a webserver. – grochmal Sep 06 '16 at 18:54
  • @grochmal seems to be assuming this is a web service. Internet != Web. OP explicitly mentions this is *not* a web service. – GnP Sep 06 '16 at 20:15
  • @GnP - Hmm... you may be right. I got misguided by the tags ([web-service] is in there). I guess we wait for OP to clarify. I'm particularly clueless on Microsoft stuff, but I would never allow something akin of `php-fpm`, `rails` or `django` to listen on a port bound to a public IP. That would be asking for trouble, and that is from where I am coming from. – grochmal Sep 06 '16 at 21:15
  • It is **advisable** to put it behind something like IIS otherwise you need to handle all security stuff yourself in your app. Configuring IIS to get an A with SSLLabs is a whole lot easier then managing TLS versions/ciphers yourself. We just moved away from that because it was too much work and our webservice now simply serves HTTP to IIS, which only accepts incoming HTTPS. –  Sep 07 '16 at 08:52
  • If I have specified the (for now self signed) X509 certificate, custom server authentication and the binding is a wsHttpBinding what else do I have to manage? I assumed that after a user has been authenticated all traffic is secure. Checking the message level logs, I could see no authentication information being exchanged in plaintext (so i assume it is encrypted). – Kafros Sep 07 '16 at 09:07
  • For now a MITM attack could be a vulnerability due to the self signed cert, however after the certificate has been issued by a CA I assume this wont be an issue... – Kafros Sep 07 '16 at 09:13

0 Answers0