Port Based ACLs vs Protocol Enforcement

[shocko]

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]

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]

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.

[shocko]

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. 

[lobstercreed]

Ok, so you misrepresented the issue at hand in your first message (which I had suspected may be the case):

"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. "

That latter part of that statement is completely false.  Of course it does allow TLS (HTTPS) over 443.  No protocol inspection necessary.  What it doesn't do is ONLY allow HTTPS traffic over 443, and based on this more recent message that seems to be your concern.  "But yet I sent non-http traffic across that ACL."

So to address this paragraph:

"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. "

Yes, you are absolutely correct about that.  Again, it is helpful to think in terms of OSI layers (if you're not familiar, do some Googling).  IP+port-based ACLs only enforce layers 3 and 4, which is the traditional purpose of firewalls.  That's NOT to say that Fortinet firewalls don't do more than that, as they can and do.  But if you're only using it for the port-based ACLs, then yeah that's all you'll prevent.

SSL-inspection is vital if you're concerned about DLP.  I don't even have to do something other than HTTPS over 443 to siphon data from your enterprise as long as you allow connections to Google Drive, etc.  You can't see if I'm loading a virus or stealing customer records unless you're breaking into the HTTPS traffic.  This is one of the most pressing needs where I work, so I get to learn some new things too.  :)

[shocko]

Hi, yes you are correct. I have read it back and it was misleading and I should have stated 'Only Allow' so apologies there. You have also answered my intended question. 

I guess we need to look in detail at the comms between systems and decided what we trust and where the risk is e.g. we allow system A talk to system B over port 443 with the intention that this is TLS/HTTPS. If it isn't we accept our app layers are misconfigured. We have change control or breach issues then :) Otherwise, we implement inspection and accept the overhead this might introduce or potential issues. 

Note: I see Forti kit can do SSL inspection but from some testing it seems some of our Azure comms for example breaks with SSL inspection enabled (and not just for Forti kit but with other SSL inspection kit too). Seems like strict SSL validation at the app to blame. I also see Forti offers protocol enforcement which I will read up on now. I think VPN will also need to be on the table for some links.

Thanks for all the help and I have learned a few things along the way ;)