Security Question

cjthedj45

Hello,

I have just started a new company and it would seem that network security is less of a priorty then in my last job. However as I was invloved a lot in security in my last postion and that why my boss said i got the job. I have been there for a month and one of the Outside access lists on the firewalls permits ICMP any any, SSH, DNS and they have lots of application created by developers thats use custom ports. My boss said I dont really see that as a problem unless you do and I was like well yeah I do becuase this access is from the outside would make us vulnerable to quite a few different type of attacks/threats.

I was asked the other day to vet a change to permit access to a server in the DMZ which also has some access to an SQL server on the inside network. They wanted a custom port 9001 permitted from the outside to the server in the DMZ. This access will let a user on the outisde download the developers application to their machine.

I have advised that this is not recommended becuase the port does not use an encryption so once installed the username and password are sent in the clear. Potentially I think a hacker could intercept the traffic and see whats being exchanged and gain unauthroised access to the system.

Also would I be right in saying its not normally best practice to open custom ports for anyone to connect on them from the outside. I'm not sure if this is correct or not becuase whats the difference with having port 80 open on a server or 9001 neither are secured?

Any advice is appreciated

DevilWAH

90% of the job is understanding and controlling traffic not blocking traffic.

How secure is the application that will receive the traffic on 9001?
who looks after the server OS security and what is this security.
Are there measures in place to insure a hacker with access to the DMZ server could not compromise the SQL back end server?

If password and username are sent in clear text then yes this is a security risk.. But that does not mean it is a business risk. What could a user do with that data, could the potential down load the file them selves or is it a one time pass word that it deleted once it has been used?

There is nothing wrong with opening a port in the fire wall (or indeed removing the firewall completely) if you can have given proper thought to what issues this could cause and reported and they have been signed off.

You need to go back to the business with questions like..

Opening this port will give unknown users potential access to this server and application X, can we be sure that this application is secure against malicious users? If some one did manage to exploit this application what would the concquences be? If the server its self was compromised could this be used to compromise the back end SQL server. If any part is compromised is there a financial or public face cost?

This is the job of the security engineer. to raise the questions and notify the management to issues. You need to give the list of issues it might cause and either state how they can be mitigated, or if you believe they can't be and for that reason the port should remain closed.

in my company we have to have custome ports open due to the types of applications and people connecting. we mitigate issues in various ways, placing servers in there own prvt protected networks, or may be using a proxy to filter the traffic. IT is all a balancing act, between total security (air gaped networks) and usability. As in all It there is no right or wrong, just good and bad, and where the line for good and bad is drawn depends very much on the indivual situation.

f0rgiv3n

Also, from what I see you assume that since it's a custom port that it's not encrypted. You can actually send an encrypted protocol on any port technically. So I would say research the protocol they will be using and that will help you a lot more in the decision making process.

DevilWAH

To help further in a large orginisation for a port like this to be open, it will have to go through change mangment. once the change is requests it will be sent to the security team, the owner of the server, the application owner, the business/department owner, and possible others.
Each of these will be expected to rasie any questions and only once they are happy for the change to be made do the aprove it. It will then pass to a over riding change manager who should review each persons comments, check it aginst the companies policies. And only once they are happy with it give it final aproval to be implemented.

This then puts a record of who reviewed it and the outcome, and insured changed don't get made that put the business at risk. while at the same time allowing the system to be flexable and insuring that the correctly trained people review and aprove them.

cjthedj45

Hi Devilwah,

I agree that the traffic should be controlled but I think a non standard port should be blocked. I believe this is best practice. Opening the port invites hackers to connect to the system on that port and look for vulnerabiltes. I think they should get the application to use https. I know there have been vulnerabilities found in https but this port provides a service to use ssl/tls and then data that flow is encrypted. The custom port that the application uses opens up the application and gives hackers the opportunity to look for vulnerabilities in the code of the application for example.

Apparently the servers are not kept very up to date with the windows patches therefore this also presents a risk. If a hacker could compromise the server then there is the potential for them to get access to the sql server as there are rules permitting this possibly on SQL port 1433. Ideally any inside access s from the DMZ should be by a proxy threat management gateway in my opinion.

I now have to attend a meeting with the developers and a few of the managers. Its seems what I have said has made an impact. Hopefully the meeting will be about how we can move forward in making the application more secure.

Thank for you reply though you have raised some good points. Like you sais I think we need to establish what value the data has and what impact could it have if someone was able to intercept it. Personally I think it should be protected as it sounds like customers personal details could be at risk. It could be an uphill struggle at the new place. They seems to think having a network/server monitoring in the dmz monitoring servers and network kit on the inside it okay.

paul78

If an IP enabled application on the Internet has vulnerabilities, it doesn't matter which port is used. It's a common misconception that using a non-standard port increases or decreases the security posture of an application.

Additionally, as @f0rgiv3n pointed out - if you want to use HTTPS or TLS, it doesn't really matter which port you are accepted connections for that traffic.

I also want to point out that just because you are using HTTPS or TLS, that doesn't secure the application unless you are using mutual-TLS to authenticate the client.

What type of ingress filtering controls do you have in place? And do you have any detective controls like an IDS that could detect attempts to probe and exploit your network?

DevilWAH

Https the hole in the fire wall.

Https does not secure the network, it just encryptes the traffic, which can make it even harder for a firewall to inspect the traffic flow.

The port number is unimportant, for a network to be secure, it must be protected at all 7 layers of the osi. A non standard port is no more or less secure than a standard one. They are all just numbers.

If I ran a https web server over port 675 is it any less or more secure than 443?

cjthedj45

thanks everyone for your replys. Just need some further clarificatiion I understand a port is just a number. However that number provides a service https and http provide a service. In this case 9001 provides a services to allow any outside host to connect to it and download this particular software.

An ideal solution in my mind is that the firewall is opened up from the outside on 443 the service that has been opened is https this allows the 3 way ssl handshake etc then data between the outside host and application flows and is encrypted. As shown in example 1.

example1
https://example/9001

example2
http://example:9001

In example 2 port 9001 has to be open from the outside firewall. The service this port provides allows connections directly into the application. This then gives a hacker the potential to try and exploit vulnerabiltes in the application.

In example 1 the port 9001 is not visible to the hacker therefore for a hacker to exploit a vulnerabilty in the application they would need to first exploit a vulnerabilty in https.

Therefore in my mind its best not to open ports that applications use to provide a service. Perhaps I ahve misunderstood something here but that is how I see it. If this seems wrong then please let me know your thoughts

paul78

I think you are misunderstanding how that works.

For me to exploit an application vulnerabilty, it doesn't matter if you are using HTTPS or not. The defect is in the application and it doesn't matter if you are tunneling the application traffic over TLS or not. In your first example, I don't need to exploit HTTPS if I can access your application, I go right for the application.

Using 443 does not assure HTTPS, you can run HTTPS on any port: I.e https://example:9001 . It depends on whether your app proxy or app container is supporting HTTPS.

cjthedj45

Hi Paul,

Thanks that helped. So what we are saying is regardless of what port is being used a connection is still being made into the application. The SSL part is sitting on top if you like encrypting the traffic but a connection is still being made into the application and therefore if the server is vulnerable then a hacker could exploit the vulnerability and compromise the server.

I have a meeting tomorrow and I will need to find out how valuable the data is. If they want to keep using the unencrypted method then we need to verify that the data truly holds no value if it ends up in the wrong hands. I would have thought this would not be the case as it is customers personal details. I will also need to see what they do to ensure the server is secure and if they test the software for vulnerabilities. My concern is that the server sits in the DMZ and is permitted through to the inside to communicate with a SQL server.

Thanks again for you help its is really appreciated

paul78

You got it. It's really about the application and app container (IIS, Apache, Websphere, etc.) being vulnerable, not so much the server that should be your primary focus. So patching is a key control.

Also, while you are right that a breach could result in data disclosure, don't forget that there is also reputational damage to consider. And if the app or SQL server is breached, a question to ask is if it can be used as a pivot into the rest of the network.

BTW- it is common and best practice to place database and application servers inside the protected network and not in the DMZ. Normally, only proxies or presentation servers are in the DMZ. My preferred architecture is to see an app proxy in the dmz and everything else inside the protected network.