Specific IP TCP/UDP Ports - Firewall rules

  • 6 January 2007
  • 8 replies

  • Contributor III
  • 72 replies
I'm about to lock down my outbound Internet ports on my firewall, and stick only the the standard protocols (like 80) and then open up whatever special ports might be needed.

I've searched the forums unsuccessfully.

Are there specific outbound ports I should open up?

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

8 replies

Userlevel 4
Badge +2
I found this in the FAQ
Excellent find.

While I'm repeating the guts of the FAQ (it will make it easier for those in the future that search the forums for the same info), the info helps with my follow up question.

80 (HTTP)
445 (CIFS)
3400 (UPnP incoming events)
443 (Integrated Rhapsody)

136-139 (NetBIOS)
1900 (UPnP advertisements / device discovery)
1901 (UPnP m-search responses)
6969 (Getting Started process)


Which ports are for the exterior firewall. I imagine the UPnP and NetBIOS are only for the interior network and SHOULD NOT be opened on the exterior firewall, nor should the 6969 (Getting Started) nor the 445 (file system).

QUESTION: So maybe only 80 (which is already open) and Rhapsody (443)?

QUESTION: However when watching the firewall (in permit all outbound mode) I do not see 443 being used. Also, having trouble actuallly finding the source of the music stream. QUESTION: Anyone know the IP of the Rhapsody music stream?
Maybe someone can help me confirm that the stream comes from potential range of through

This is registered to Limelight Networks and my specific connection I am seeing is

QUESTION: So maybe only 80 (which is already open) and Rhapsody (443)?

As a general rule you'll almost certainly want port 443 open anyway. It's the standard port for any secure websites which use https URLs.

Having said that, 443 isn't the only port used. Many websites use alternative ports (such as 8443) for https and it's also relatively common for alternative ports to be used for standard http transactions too. For instance, some webapp frameworks use port 8000.

I'm wondering what you expect to achieve by locking down outbound ports. The security benefit in most cases is negligible and the inconvenience factor can be very high.

The only times I see outbound port restriction tends to be in a corporate environment where the IT dept want to restrict their users from running unauthorised applications (to prevent cyber-skiving or abuse of the corporate Internet bandwidth). In a home environment or even in most SME's I don't normally see a compelling reason for doing this.


two reasons

One just to learn about what is happening on the network - so curiosity.

But more importantly, the more I read of the new attacks, a traditional anti-virus product may longer protect against morhping threats. So instead of trying to combat future attacks by signature updates only and managing mutliple home computer outbound firewalls, I am exploring putting up the outbound defense in a central location.

Obviously this won't protect against attacks going out the usual port 80 (and so forth), but might bring other defenses into play.

Such a project atleast will give me a baseline to understand the normal traffic on my home nework, as I build a set of rules with documented ports.

Would never recommend this to someone that doesn't haunt these Digital Expert forums.
Userlevel 4
Badge +14
Android controller (and maybe even iPhone?) seems to use port 3500 for uPnP events (dunno why). So in addition to 3400, you should open up 3500 as well.
>First, Best Practices:
There is nothing to gain by locking down outgoing ports and only your sanity to lose if you do. As was mentioned, there can be uses in a corporate environment to limit what employees can get to but that is usually done on an IP address basis (or FQDNs). There are several services which provide listings of IP addresses and Fully Qualified Domain Names for blocking but I have never seen anyone blocking ports.

>Now, Networking 102:
The firewalls (physical boxes, not on PCs) that are in place today are "Stateful Firewalls" or firewalls that do "Stateful Packet Inspection". They expect to have all outbound ports wide open and all incoming ports blocked, except for ports that unsolicited inbound traffic is expected to come to, like 80 & 443 for HTTP(s) and others like SMTP. Almost all programs and protocols on a PC, for example, initiate all network "conversations" by sending out packets to an Internet host on a specific port, some of which are predefined (well-known ports -- 1 thru 1023), some are “registered” (1024 thru 49,151 – assigned by IANA) and the rest called Ephemeral ports (49152 thru 65535). When these packets pass through the firewall in an outbound direction, the firewall “inspects” the packets to see the destination of that packet (IP address and port) and then it sets-up a temporary inbound connection for the destination host, back through firewall and to the initiating host. Think of it as a hole poked through the firewall based upon a conversation started on the PC. The open inbound connection, with the port, is left open until the “conversations” finishes up, or after a timeout.

>Networking 103:
When a PC on the Internet wants to connect to the network/hosts behind the firewall, not on a well-know and permitted port, the firewall will block it UNLESS “Port Forwarding” is set-up. Port forwarding, simply put, is another type of hole poked in the firewall but it is more restrictive in that it is limited to one external port (and maybe one external address) and one internal address and port. When a connection is made, the traffic passing outward from the internal host, through the firewall, to the external host, the firewall does it’s stateful inspection thing and opens up any additional ports needed in the inbound direction.

>Quick Summary
So, in the case of the Sonos, there should be no need to set-up any inbound ports in the firewall UNLESS some external host (music service) initiates some form of connection that is not on a well-known (and allowed) port. I do not believe that is the case but please speak up if you know of one.

>Networking 104:
All the above connection stuff probably includes NAT, PAT and SNAT which is another set of lecture notes, so… Fuhgeddaboudit.
@sjf - There is +much+ to be gained by locking down outbound ports; in fact, it is very much a best practice in corp sec. The attack vector may or may not be affected by the security or insecurity of the network perimeter, but a breached system more than likely will attempt an _outbound_ connection for CnC, exfiltrative, or other purposes. If outbound traffic is not filtered then an attacker can utilize whatever protocol they want over whichever socket they desire -- e.g. the attacker may initiate a connection to the dst port of, say 39211, but then use SSH or HTTP as the transport protocol, and if you aren't filtering outbound connections then the attacker is now able to get past your network defenses even if you have full filtration on your inbound traffic. Now, if you filter outbound traffic such that only 80 & 443 are allowed, for example, then the attacker may only use one of those two ports. From there, the best practice is to apply application-aware rules on the FW - we now will only allow the HTTP protocol over those two ports -- or to force the traffic through a web security gateway, which inherently only allows a couple protocols. From there, the best practice is to decrypt and inspect the session to look for malignant behavior (e.g. CnC call-backs). While imperfect, this is a formidable defense technique and is a best practice for network security.

You could achieve similar results w/o filtering outbound ports, but now we're vastly increasing the complexity of the downstream security systems, and there's no reason to do this when outbound filtration is trivial to implement.

SPIF and NAT/PAT/SNAT are not material to the discussion.