IT department says our windows 10 server is 100% going to be hacked because of port-forwarding my software

Question

We have a local virtual windows 10 server hosting some custom software. This VM is only hosting this service and nothing else. This software is made of:

• An ASP.Net core web app, public API, only returns data, never writes
• Custom UDP communication server (with its own reliable implementation), does some CRUD operations but only after authentication is certified
• FTP server configured a usual, port 21 for authentication, 20 for data transfer. Does only allow file transfer within a given folder and only to users authenticated with the correct email/password.

We want to host this service to the outside world so our customers can use our platform. When I asked the network manager to allow these connections to this specific VM, he said it is very dangerous and that there is a 100% chance that we will get hacked.

I'm wondering if he is right. In my knowledge, it is very unlikely that someone might be able to penetrate my custom software and get something useful out of it, let alone cause any harm with it.

The only weak spot I might come up with is our FTP service, which could be "hacked" and the intruder could potentially transfer malicious files to this certain folder. I could upgrade to SFTP but I'm not very familiar with this service and have no idea if it's a major improvement.

Are there any major security leaks with this setup if we port forward it? Are we, as he states, 100% going to be hacked?

Edit

The UDP Server is used for fast real-time communication. It has an internal state that is shared among all clients but that's view data only. the UDP Server itself does not execute CRUD directly, but talks to a separate layer that implements all logic which then speaks to the database layer.

This logic layer does check for authentication on the server-side, if the host is not authenticated, crucial CRUD operations are not permitted. The authentication is based on a salted hashed password which grants a session token for a limited duration (30min). This connection is not encrypted, but I have not enough knowledge of knowing why it should. This is the part where I doubt myself.

This application is not going to be used by a lot of people. I doubt it would fall into the hands of anyone who knows how to break this. But I just want to be sure.

Answer 1

I see a couple red flags a network administrator would notice:

• Custom Software

A custom software does not have a security tracking record. If it was an off the shelf software, even a buggy one, a systems administrator would know what they are handling. A custom software don't have it and the network admin must assume it's the most buggy software ever made, with lots of backdoors, shells, and so.

• Custom UDP service

UDP is not the most network-admin friendly protocol. If you take into account that forging the origin of any UDP packet is trivial, and any service that accepts data on UDP and replies more data than it got will be used in a UDP amplification attack, it's easy to see why your network admin is not willing to allow this. Try to test if you really need UDP for this, and if the timing over TCP is enough. Most of the time, TCP is fast enough.

• Custom authentication protocol

Another issue is this custom part. It have the same issues as the custom software: no tracking record, no external validation, only the developer assumption that it is secure. Consider using a currently used protocol that is being installed, attacked and patched already.

• Plain FTP

Stay away from FTP, unless you have a really good reason no other solution would work. If file upload is really necessary, try to upload using HTTPS. Apart from being plain-text, the protocol have some interesting properties, like allowing an external client to connect to internal ports using FTP as a proxy. So stay away from it.

This application is not going to be used by a lot of people. I doubt it would fall into the hands of anyone who knows how to break this.

...as far as you know. Don't count on it.

own reliable implementation...

In my knowledge...

The only weak spot I might come up with...

Those are just assumptions, and you don't have anything to base them on. The problem is that you are the one making the software and at the same time the one vouching for its security. This is not the way to do, you need an external validation.

I don't want to be blunt, but if I went to your house and ask you to plug an unknown device on your internal network, open to the internet, and sending and receiving data, and giving you only assumptions, you would not be much willing to allow me, right?

---

I would ask you to redesign your application. Use only one interface for everything. Use TLS. Test to see if the latency is really a problem, and if one second of delay is acceptable. Ditch the custom UDP protocol, and custom authentication, and employ a known authentication library. Don't implement your own authentication, and don't even think about implementing your own encryption. Use a known framework for building the software, so you have a solid base to work on. And don't use Windows 10 as a server, it was not made for this.

If your company don't have the budget to pay for an external audit, you need to reduce the attack surface as much as possible, and reduce complexity. As it is designed, there's lots of custom parts, and a lot can go wrong.

Answer 2

We have a local virtual windows 10 server hosting some custom software.

Windows 10 might not be a good choice for hosting an Internet service, performance and security wise.

Custom UDP communication server (with its own reliable implementation)

Peer reviewed and pen-tested? Shouldn't be called reliable otherwise.

FTP server configured a usual

FTP needs to be secured with TLS, by itself it's insecure.

When I asked the network manager to allow these connections to this specific VM, he said it is very dangerous and that there is a 100% chance that we will get hacked.

He's likely correct unless your service was specifically hardened for Internet use. Any service available from the Internet will be attacked and when there's a security problem it will be found, sooner or later.

In my knowledge, it is very unlikely that someone might be able to penetrate my custom software

Based on what premise?

and get something useful out of it, let alone cause any harm with it.

It's quite enough to pass a not fully filtered parameter as SQL query, for instance, to allow SQL injection. That opens the door to steal your data or manipulate it, including user passwords.

The only weak spot I might come up with is our FTP service, which could be "hacked" and the intruder could potentially transfer malicious files to this certain folder.

Unless authentication is encrypted, it'd be easy to intercept user credentials, allowing impersonation.

I could upgrade to SFTP but I'm not very familiar with this service and have no idea if it's a major improvement.

SFTP uses mandatory encryption and is generally accepted as being more advanced and reliable.

Are there any major security leaks with this setup if we port forward it?

We can't really tell unless your code is properly reviewed and tested.

The authentication is based on a salted hashed password which grants a session token for a limited duration (30min). This connection is not encrypted, but I have not enough knowledge of knowing why it should.

Again, we don't really have enough information to comment. Generally, you should be sure that everything's tight.

This application is not going to be used by a lot of people. I doubt it would fall into the hands of anyone who knows how to break this. But I just want to be sure.

If it can be reached from the Internet it's going to be attacked.

Answer 3

Are we, as he states, 100% going to be hacked?

Likely not. But this is actually the wrong question to ask. The question should not be if the system gets definitely hacked but if there is a realistic chance that it might get hacked, i.e. the probability does not need to be 100% but 10% might be risky enough.

Imagine only what the result might be if the system got hacked. Since you ask for port forwarding I expect your system to be part of the larger network - so somebody compromising your system might try to use your system to compromise this entire network from inside. How well protected is this network against such attacks from inside?

And even if this is an isolated machine: it serves data which by design should only be available when properly authorized. Consider the impact when somebody can bypass this requirement and steal the data or manipulate the data to their own advantage.

In my knowledge, it is very unlikely that someone might be able to penetrate my custom software and get something useful out of it, let alone cause any harm with it.

Basically you expect the network manager and us to trust your experience in writing sufficiently secure software just because you say so. I don't know what your experience in this area really is. But it looks like the network manager is not trusting your experience and why should we? If you are really sure that everything is properly done get well respected security experts you have in the company or hire external ones. Provide them with the risk analysis for your setup, design documents which show how you address these risks, implementation details etc. This way it is not only your word that the software is secure enough, but the word of acknowledged experts and the network manager will probably listen to these.