HTTPs port restriction

34 Views Asked by At

I have a website on Port 443 on an nginx server. The port of this server is wide open to the internet. The website that is hosted on the server, has a valid SSL cert, has a login ID, password and 2FA configured to login to the application. My concern is, is there a way that can an unauthorized user or a hacker can get a backdoor entry into the server through port 443?

If there is a chance of back door entry into the server, what security constraints can I put in place to secure the unauthorized entries.

1

There are 1 best solutions below

1
deceze On

A machine needs to actively accept incoming network traffic. Just because you plug a network cable into a machine doesn't mean you can now do anything on it. You can only send data packets over that network cable. When those data packets arrive at the network port… by default they do nothing. The machine needs to actively read the data packets and do something with them, otherwise nothing's going to happen.

If the only thing you've set up on the machine is a web server on port 443, then incoming data packets for port 443 will be received by that web server. That web server reads those data packets and then decides what to do with them. That means a data packet would need to conform to HTTPS standards and initiate some sort of HTTPS communication, because that's the only thing the web server is configured to do. Anything that does not fit that pattern should be ignored. Unless the web server offers some "backdoor" service on port 443, there's no "backdoor" there.

Having said that, if the web server has some vulnerability in its parsing code, and it misinterprets incoming data, and it can be tricked into doing things it's not supposed to do (see buffer overflow), then an attacker may be able to establish some sort of backdoor using a service which isn't supposed to have one.

But since nginx is a widely used server and no such flagrant issues are widely known, it's probably fine. Such vulnerabilities may also exist at other layers of the network stack, at the network interface firmware level, the operating system level, or wherever else. But again, assuming these are all tried and true components, there's usually nothing to worry about. The biggest risk for "backdoors" is usually boneheaded stuff you install, mis-configure or write yourself.