Firewalling best practices...

[chalsall]

I didn't know where this should go. If there's a better place, could a Supermod please move it there.

I have encountered a weird issue. A (somewhat large) client of mine seems to configure their firewalls such that "high" ports (I haven't determined the actual range, but let's say above 1023) are blocked for outgoing traffic. Not new incoming, but new outgoing.

I can think of absolutely no security advantage in doing this. And, I always use non-standard "high" ports for services like SSH, so I can't access my systems while within their networks. (Yes, I know doing this doesn't give any security advantage, but it greatly lessens the "noise" in the logs from script kiddies.)

Before I start the (long) process of trying to have their (human) policies changed, can anyone think of a reason or situation this would make sense?

[retina]

Originally Posted by chalsall

I didn't know where this should go. If there's a better place, could a Supermod please move it there.

I have encountered a weird issue. A (somewhat large) client of mine seems to configure their firewalls such that "high" ports (I haven't determined the actual range, but let's say above 1023) are blocked for outgoing traffic. Not new incoming, but new outgoing.

I can think of absolutely no security advantage in doing this. And, I always use non-standard "high" ports for services like SSH, so I can't access my systems while within their networks. (Yes, I know doing this doesn't give any security advantage, but it greatly lessens the "noise" in the logs from script kiddies.)

Before I start the (long) process of trying to have their (human) policies changed, can anyone think of a reason or situation this would make sense?

I assume you mean high port numbers for destination traffic, not for source traffic?

I guess the perceived advantage is to reduce the chance of employees using bittorrent and other P2P services that like to use high port numbers by default.

[PhilF]

That's probably a good place to start: Find out if the policy is meant to help secure the network, or instead clamp down on what the network users can do.

[chalsall]

Originally Posted by retina

I assume you mean high port numbers for destination traffic, not for source traffic?

Yes.

Originally Posted by retina

I guess the perceived advantage is to reduce the chance of employees using bittorrent and other P2P services that like to use high port numbers by default.

Ah... Yes, that makes sense.

I would have managed that kind of thing by way of protocol filtering and/or traffic metering, but this is probably easier for them and impacts few users.

Unfortunately, this /is/ impacting my "handler" and his team. But they're non-nominal users. We'll have to ask for exeption rules to be added.

Thanks for the rational explanation. For the life of me, I didn't see it.

[xilman]

Originally Posted by chalsall

Yes.



Ah... Yes, that makes sense.

I would have managed that kind of thing by way of protocol filtering and/or traffic metering, but this is probably easier for them and impacts few users.

Unfortunately, this /is/ impacting my "handler" and his team. But they're non-nominal users. We'll have to ask for exeption rules to be added.

Thanks for the rational explanation. For the life of me, I didn't see it.

Rule of thumb for all security measures: first evaluate your (or your client's in this case) threat model. From your description it appears that they are concerned about internal threats. From that, subsequent explanations follow naturally.

[kriesel]

Originally Posted by retina

bittorrent and other P2P services that like to use high port numbers by default.

Trojans and other malware love those high port numbers too.

[Madpoo]

Originally Posted by kriesel

Trojans and other malware love those high port numbers too.

That's what I was going to say. There are quite a few critters out there that talk to some command/control servers over non-standard ports > 1024. Blocking those outbound means that at least if a machine is infected, it might not be able to hit some C&C server.

Although I feel like most C&C servers are running on standard things (80, 443, etc), especially the IRC port. And it's been so long since I've used IRC, I've forgotten what that port # is.

I could be wrong... maybe more bad stuff is happening now over the high ports than I'm aware of... One thing I'm fairly confident of is that blocking high ports won't really help much in the end, and usually ends up blocking ports that people use for legit reasons.

On the other hand, if the reason is to keep people from deliberately doing things you don't want them to do and make sure they're only using approved things, then that'll sure help. Maybe they have a stateful inspection firewall that's inspecting everything over standard ports, and then they block everything else.

[kriesel]

Originally Posted by Madpoo

I could be wrong... maybe more bad stuff is happening now over the high ports than I'm aware of... One thing I'm fairly confident of is that blocking high ports won't really help much in the end, and usually ends up blocking ports that people use for legit reasons.

On the other hand, if the reason is to keep people from deliberately doing things you don't want them to do and make sure they're only using approved things, then that'll sure help. Maybe they have a stateful inspection firewall that's inspecting everything over standard ports, and then they block everything else.

Default deny. Defense in depth. Secure the end user devices. Secure the perimeter. Log and analyze. Detect exceptions and consider what they mean about what has happened on your network. I think default deny rather than default allow is more appropriate for use of an intrusion detection system. It's been bad out there for decades, but if you don't look, you don't know. I knew a guy who ran a linux based departmental network and someone got in, and had enough time to compromise multiple systems. First time around fixing it, was a continual whackamole game, which they conceded to the intruder. Second pass, they isolated their departmental network from the rest of the world for as long as it took to reinstall everything from zero on every system to regain control, while with a single system connected to the world their staff took turns using that for email etc, like people queuing up at the only water cooler to each drink in their turn. Pretty ugly, best not repeated.
https://eugene.kaspersky.com/2012/10...bout-deny-all/

[chalsall]

Hey guys. Thanks for the follow-up on this. And for retina's initial insight which made it all clear to me.

To follow-up on this... It seems this is my client's default position, or perhaps it is their various other consultants'.

Over the weekend we bypassed a firewall on a "public-facing" server, in order to make it functional. I have absolutely no idea why the firewall was deployed; it provided no advantage (the built-in firewall in CentOS is more than capable of doing the job, and it's useful to log the attack attempts).

It was doing NAT, and blocking all out-going connections to "high ports", in addition to all outgoing ICMP traffic. To say again, outgoing. On an "edge" server.

It's a good thing I meditate; otherwise, I'd scream (more than I nominally do)...

P.S. Always happy to be corrected in my thinking.

[chalsall]

Originally Posted by chalsall

I have absolutely no idea why the firewall was deployed; it provided no advantage...

I just found out the reason the firewall was deployed.

Not only did it cost several thousand dollars in "CapEx", but my client was being billed a couple of thousand dollars per year for "software updates".

Sigh...