Any suggestion on other ports to deny?

On the network edge ACLs I am currently blocking ports 135 and 445 in and out TCP and UDP. I was blocking port 139 but due to an AD rollout and Unicenter RCO, I was asked to open that up (and boy did we get slammed for a bit) but I warned 'em:-)

Can anyone give me suggestions of other ports that are exploited as well.

I've Googled for this and came up with:

111 (SUNRPC)
666 (hack favorite)
999 (Winsatan)
27444 27665 and 31335 (Trinoo)
31337 (Back Orifice)

Any thoughts or ideas about the current and proposed ports? Just don't want to run into triage afterwards and still want to be as protected as possible.

Thanks for your time.

Instead of just closing single ports, why don't you just close down all the ports and only allow ports that you and/or your company need to use? much better doing it this way and much safer. Also, disable ICMP and your all set.

Disabling ICMP will probably blocks 90% of the hackers trying to infiltrate your company. 10% are renegade hackers the other 90% are script kiddies looking for open boxes.

I agree - "If in doubt, keep it out". Only open the ports that you need to support the applications/services you want to use/allow. Block everything else by default. Yes it's more work for the administrator but it's more secure and hey, work pays the bills!

Thanks TheBishop and eddyreni. The suggestion is more viable than my plan. My issue with this is that it will be a break fix situation with me running around like a chicken trying to discover all of the ephemeral ports that our vendors' custom apps are running on.

We support centralized clinical applications that run in our data center and are served to 100 or so hospitals across the country on a private WAN. Many of our apps, are "patient care" affecting when they are down ie. pharmacy orders and cross referencing, test results, radiology and the like. I would certainly be under the gun to open the ports and would create a storm of helpdesk calls (and I like the helpdesk girls otherwise I wouldn't care (joke).) Coordinating the list of ports that these custom apps run on would be a nightmare, sometimes vendors leave ports out or aren't aware of some of the ports when you request a comprehensive list. They forget they are running on this or that database or that their app is based on...blah blah... technology (Jave, activeX...etc.) the list goes on and on.

It's bad enough having to school vendors when they bring up apps and call me to find out why they aren't working. Most clinical apps are written for local traffic and developers don't take into consideration that someone may want to run them over a WAN. I have ongoing battles on TCP optimization with developers to get them to make their apps WAN friendly.

Now, I'm not against work, like you say TheBishop, "...work pays the bills!" but I think if I added as many known abused ports as I could muster, there would be much less downtime and pain for me while protecting my sites. Now on the other hand our edges to the public for Internet/VPN traffic are pessimistically filtered which is a better fit for the public edges.

So, while I think your plan is way better (pessimistic filtering), I really need to be gentle in this situation (optimistic filtering) or there will be many a doctor/hospital administrator taking note of my name.

Alright, I have a few suggestions then.

I have a little cool app called, "Advanced Administrative Tools" - This has a nice port scanner built with it. What you can do, is port scan your own firewall and it will show you all the open ports and vulnerabilities / available attacks on those ports.

Here is what mine looks like:



As you can see, I have most ports closed down, except the ones I use.

You can get the following application by visiting:

mirror1.glocksoft.com/aatools.zip

After you port scan your server, you can decide to close down the ports you desire that might harm your company in any way possible. I hope that helps.

Alternative suggestion - stick a packet capture tool or similar on your network as it is at the moment. Find a tool that can list out every protocol and port that it spots being used. (I use Network Instruments Observer which does this virtually automatically but it's not free!). If you leave the tool on there for say a week, you'll have your list of ports that need to be open. But go thyrough the list first - you might find some 'interesting' traffic that you want to investigate and justify before you open a port for it