Port Based ACLs vs Protocol Enforcement

5 replies
6551 views

I recently was discussing network security with some experienced network guys (and I am not a networking guy!).This was in the context of connectivity to cloud systems. I was arguing that port based ACLs did not really enforce protocols that could traverse that ACL and that they only literally enforce the dst/src TCP/UDP port. For example, a rule allowing port 443 is often presented at architecture meetings as allowing TLS/SSl but to my eye it does nothing of the sort. Only protocol inspection/enforcement would do that. They argued the opposite.

Who's correct!? :)

lobstercreed

New Member

They are. Anytime you say you're arguing with experienced networking guys and you're not a networking guy but you're trying to have an intelligent conversation about TCP/UDP ports, I'm going to say the networking guys know what they're talking about.

If I understand what you're trying to point out, you may be correct in a certain very narrow way. Much like you would be if someone said "Kleenex?" while holding out a box of store brand facial tissues and you wanted to pick an argument over their semantics. It's pointless and completely unhelpful.

However, I'm not sure you're even THAT much correct, as the protocol is the more specific definition, not less specific. To say the application layer (layer 7) protocol runs on TCP port (layer 4) 443 is correct in most cases. Yes, it's trivial to make an application listen on a different port if desired, but the end user has to be aware of that as well so they can connect the right way (for example to use https://mysite.com:4443 in their URL bar, instead of just https://mysite.com -- a browser will always assume 443 if it's connecting via HTTPS).

Basically, either learn about networking enough to know how firewalls work and what the experienced network guys are trying to tell you, or admit that's not your bailiwick and quit trying to argue useless semantics. :)

lobstercreed

New Member

The more I think about this, the more wrong I realize you are. If you were talking about *blocking* a particular application, you might be right about needing the higher level inspection to determine what exactly is using the port.

For example if I want to allow HTTPS web traffic over 443 but I want to block a VPN tunnel or something like that. Then I need to allow port 443, but use application inspection to block the more specific protocol.

However if my only goal is to allow the HTTPS traffic, and if that happens to include some SSL-VPN traffic, so be it, then all I have to do is allow port 443, just as your networking guys said.

And if the service is running HTTPS on 4443 for example, the application inspection isn't going to do a blessed thing to help allow that traffic if that port is blocked in the firewall. It won't get to that point. Think OSI layers....lower levels have to work for the higher levels to work.

shockoAuthor

Explorer III

Hi lobstercreed. Thanks for taking the time to reply. Just FYI these are healthy arguments and networking guys are fully engaged and encourage them. To this statement:

'Basically, either learn about networking enough to know how firewalls work and what the experienced network guys are trying to tell you, or admit that's not your bailiwick and quit trying to argue useless semantics.'

I am trying to learn. I don't agree that this is an argument on useless semantics to be honest. That is your opinion which you are of course entitled to.

Let me elaborate a little:

[ul]

No browsers involved these are all applications (microservices) we are developing that are talking together

DLP is a big concern for our company[/ul]

I don't necessarily agree that this is a semantical argument. The argument was actually the result of a pen test. So say for example I have a rule on a firewall that only allows port 443. A lot of architecture diagrams I see will display this with a blurb like 'only allow TLS/HTTPS'. Security will look at this and go 'great, only encrypted traffic will traverse this.

I guess what I'm trying to find out is if this is really the case. From some quick coding its not and I can write some code/apps at either end to send un-encrypted data on a protocol other than HTTP/S on port 443. You state:

however if my only goal is to allow the HTTPS traffic, and if that happens to include some SSL-VPN traffic, so be it, then all I have to do is allow port 443, just as your networking guys said.

But yet I sent non-http traffic across that ACL.

So from what I have implemented, that ACL on the firewall does not allow/block based on anything other that port. So if protocol enforcement is required we need to look at inspection at the firewall or controls at the app layers or layer VPN atop some of the links we are concerned about.

Appreciate your feedback here.

Sign up

Login with SSO

Login to the community

Login with SSO