[Baass]

My snow leopard operated macbook is using ports 49000-65000 for all web activities. Shouldnt it be using ports 80 and 443? If I blocked port range 49000-65000, I cannot connect to internet. Since firewall directives are based on standard port usage assumptions, this seems to negate the purpose of having the firewall as such. Did anyone experience the same default port usage issue?

[besson3c]

How do you know that these ports are being used for outbound connections? Might this be some sort of internal proxy, maybe the DNS precache thing that Safari does? Since the web servers you connect to only accept connections on the above 2 ports normally, you are definitely sending outbound connection attempts on these ports.

[Baass]

Yes. Outbound connection requests are going from 49000-65000. This is irrespective of the browser or any other application used. How does it happen by default in a freshly installed and updated system? What is the best way to change this to the normal port usage? I am not using any DNS service at all.

[Baass]

All outbound and inbound requests are forced to be logged. The first outgoing request itself is from these random ports.

[besson3c]

You must be using a DNS service, it would be impossible to not be. I'm pretty sure OS X itself caches all DNS request, hence the dscacheutil utility. I don't know of a way to rely on the DNS server's cache rather than the OS X proxy, nor do I really understand why you'd want to?

I'm also pretty sure what you are saying is inaccurate. My understanding is that your browser will request the little DNS cache proxy service listening on a port from 49000-65000, and then direct the request outbound. The reason why blocking access (inbound, I'm assuming?) to those ports blocks your internet connectivity is because this proxy is unavailable this way.

It is pretty common to have services running on those high number ports for internal usage. These services are bound to your localhost interface, so they would not be responding to requests from the outside world, and therefore do not need explicit firewall rules to block inbound access to these ports (although if you have a firewall enabled if the default is to deny these requests would be blocked anyway). Most firewall configs permit all access to the localhost interface too. Therefore, this is not pose a security risk.

What evidence do you have of outbound requests via one of those ports?

[Baass]

Initially, I was thinking of the same as you have pointed out. Playing with an additional firewall that I put into place rovided interesting details. application firewall logs shows that the outgoing requests are from port 49000-65000. Again, its all purely DHCP (TCP). flushcache does not resolve any of these issues. My understanding is that these ports are not generally used for most TCP connections and if you look at the old ipfw firewall, everything revolves around the commonly used ports rather than 49000-65000. I have blocked inbound alone and outbound alone separately and both have the same effect- no connectivity. Even telnet works through these random ports.

[Baass]

Forgot to mention that the connections times out quickly and I am having to refresh the link to have the connections reestablished. In other words, if I logged into yahoo mail, as I am typing my mail, the connection is lost and when I click the send button, a fresh connection is requested and this is used for sending mails. Some folks receive only half portion of the mail.

[besson3c]

Originally Posted by Baass 

Initially, I was thinking of the same as you have pointed out. Playing with an additional firewall that I put into place rovided interesting details. application firewall logs shows that the outgoing requests are from port 49000-65000. Again, its all purely DHCP (TCP). flushcache does not resolve any of these issues. My understanding is that these ports are not generally used for most TCP connections and if you look at the old ipfw firewall, everything revolves around the commonly used ports rather than 49000-65000. I have blocked inbound alone and outbound alone separately and both have the same effect- no connectivity. Even telnet works through these random ports.

You need to look at something other than your application firewall logs for definitive information, maybe something like ethereal will give you better information. To the application firewall logs it may seem to it that there are outgoing requests on one of those high ports because it isn't aware of what the proxy (for lack of a better term for it) is actually doing, this is out of its jurisdiction. I'm not even sure if the application firewall is kernel based - if it isn't, all the more reason why those logs should not be treated as anything definitive. The fact of the matter is that there are outbound requests going to port 80 of the destination server, or else you wouldn't be able to access any webpages.

Using DHCP does not mean that you do not use a DNS server. Using DHCP means that your IP address is assigned by the DHCP server, your DHCP server has nothing to do with domain to IP mapping though, that is the role of your DNS server. Do a:

cat /etc/resolv.conf

to see what DNS server(s) you are using. If your application firewall logs are showing that telnet connections are going through these same ports, this is more evidence that I'm correct. Like I said, this proxy will be bound to localhost, it is completely harmless - not a security risk.

[Cold Warrior]

Clients on a LAN will use so-called 'ephemeral' ports for a lot of comms between gateway/router and the WAN. Often these are in higher ranges, including those you mentioned.

besson's suggestion is good, use a packet sniffer on your suspect machine to see the ports and protocols flowing to and from. Cocoapacketanalyzer is good, as is packetpeeper, both specific to the Mac OS.

Once loaded, visit some web pages and then examine the entries. I bet you will see your web traffic but in the dynamic range.

[Baass]

Besson,

cat /etc/resolv.conf says that

#This file is not used by the host name and address resolution or the DNS querry mechanisms used by most processes on this mac osX system. This file is automatically generated.

I Agree that using DHCP does not mean the system is not using any DNS. Can there be a scenario that the router itself is acting as a domain name server? Not even remotely likely right?
I made an ipfw based firewall and installed it to see the transactions at all ports and I don't find any outgoing request from ports 80 or 443. In very little is happening away from 49000-65000. Tried to learn about the application firewall and am not able to find any documentation at all.

What concerns me most is the fact that the connection are getting timed out quickly. I typed a response to your suggestions and before I even finished it, the connection is timed out. I had to open another window and log back in again.
This is the second time I am typing this reply. Is it likely that the reverse DNS is not matching with the querry and therefore the timing out?

The possibility that cold warrior mentioned had already been probed into. Probing the ports with nmap suggested that these ephemeral or otherwise random ports are not used by the router (ATT Uverse) as I had expected (I have an HD DVR connected to one of the ethernet ports of the router). It was likely that they use these ports for providing gaming applications, which I dont use any way.
I had an ipp port open on my notebook and I blocked it because I dont use this service.
Recently, as I was attempting to look at the established connections in response to a gmail querry, I found a bunch of connections from Hurricane Electric's backbone and I was astonished to see this, particularly because the connections to the actual gmail servers timed out quickly and the only ones that did not time out was that of the connection from HE backbone (65.49.0.0/16 block). I contacted the ATT UVerse to see if they are using HE servers to relay the requests and they informed me that they are not using any of the HE services at all. (apparently ATT UVerse Routing tables are devoid of anything related to HE backbones). This phenomenon was not restricted to gmail. It was true for most of the websites that I visited. Even as I type, this single connection to macnn is associated with a bunch of requests from port 80 of machines at the HE backbone.

According to Hurricane Electric, those IP addresses once belonged to its past customers and that these were not assigned to anyone particular at this point of time. Request to Hurricane electric to provide information regarding the customer was turned down.

[besson3c]

Originally Posted by Baass 

Besson,

cat /etc/resolv.conf says that

#This file is not used by the host name and address resolution or the DNS querry mechanisms used by most processes on this mac osX system. This file is automatically generated.

I Agree that using DHCP does not mean the system is not using any DNS. Can there be a scenario that the router itself is acting as a domain name server? Not even remotely likely right?

Some routers will perform DNS requests for machines on the network using the ISP's DNS server, but I was expecting that in this case you'd have the IP address of your router in /etc/resolv.conf. What do you see in your Network Preference Pane? I'm assuming based on the spelling mistakes that you retyped the above? Did you leave anything out?

I made an ipfw based firewall and installed it to see the transactions at all ports and I don't find any outgoing request from ports 80 or 443. In very little is happening away from 49000-65000. Tried to learn about the application firewall and am not able to find any documentation at all.

Let's see your ipfw rules...

The possibility that cold warrior mentioned had already been probed into. Probing the ports with nmap suggested that these ephemeral or otherwise random ports are not used by the router (ATT Uverse) as I had expected (I have an HD DVR connected to one of the ethernet ports of the router). It was likely that they use these ports for providing gaming applications, which I dont use any way.

AFAIK they are bound to your localhost interface, and are therefore completely inaccessible outside of your machine.

I had an ipp port open on my notebook and I blocked it because I dont use this service.
Recently, as I was attempting to look at the established connections in response to a gmail querry, I found a bunch of connections from Hurricane Electric's backbone and I was astonished to see this, particularly because the connections to the actual gmail servers timed out quickly and the only ones that did not time out was that of the connection from HE backbone (65.49.0.0/16 block). I contacted the ATT UVerse to see if they are using HE servers to relay the requests and they informed me that they are not using any of the HE services at all. (apparently ATT UVerse Routing tables are devoid of anything related to HE backbones). This phenomenon was not restricted to gmail. It was true for most of the websites that I visited. Even as I type, this single connection to macnn is associated with a bunch of requests from port 80 of machines at the HE backbone.

According to Hurricane Electric, those IP addresses once belonged to its past customers and that these were not assigned to anyone particular at this point of time. Request to Hurricane electric to provide information regarding the customer was turned down.

I'm still not understanding the motivation behind all of this. Is this just your curiosity? If so, that's cool, nothing wrong with trying to learn about this stuff Or, is there an actual problem you are trying to solve?

The litmus test is this: if you can telnet to these ports from outside of your box with your firewall disabled and get a response, these ports are open to the world and are a potential problem. If you can't, they are bound to localhost and harmless unless you expect that your machine has been compromised. I would not worry about any of these ports that are not setup to listen to incoming traffic, they are pretty normal in all OSes and not worth losing sleep over.

[Baass]

Besson, do you have any idea about the connection getting times out in no time? Please comment on this part of the issue.

[Baass]

Networking folks please....

[besson3c]

A connection will time out immediately if it "hits" the firewall.

[Baass]

why would a connection that is not supposed to be pulverized by the firewall hit it and time out? My own Firewall is thoughtfully installed to accept the one and only one that is solicited. Rest of the hits get logged and the one that deserve no acknowledgment gets treated that way. Any unsolicited connection attempts from specific IPs when repeated over and over again gets a nice treatment with tcp, udp and syn floods.

[Baass]

I have decided to probe deep into the operating system firewall implementation.

[besson3c]

I have no idea what you are trying to do, what is going wrong, what your rules are, and what you are testing. Sorry, you've lost me!

[ghporter]

Baass, you have not provided important, highly relevant information that besson3c requested. Without that information, he can't give you any help. And you have side-stepped the most important question he's asked. What is it about the firewall that you're interested in? The "implementation" is the whole firewall-what about that implementation are you concerned about?

My concern here is that you're possibly looking at a specific situation with someone ELSE's firewall and looking for ways to poke through it. We certainly can't (and won't!) help you with that. Can you please explain what you're looking for, and then provide the rules and other information besson3c requested? Otherwise we just won't have the information we need to help you out.

[Cold Warrior]

A bit of packet capture would go a long ways to help you see MBP->LAN traffic and that it is innocuous. I'll reiterate my assessment that all the 'suspect' traffic in the dynamic range is ephemeral port usage for the MBP out to the gateway, both for http, https, DNS, and more. If you are looking for this stuff outside of that channel, for example from another machine or outside the LAN, you won't see it.

[Baass]

Connections from the 65.xxx.xxx.xxx range is blocked and the valid connections are not getting timed out now. Cold warrior, I will analyze the packets and what is and was going on.

[Baass]

I have very little information at present about what the OSX firewall on my notebook looks like. The firewall that I put into place works fine so far. 10.6.3 appfirewall and its implementation is not very clear to me and I will need to dig deep into the system to find that out.

[besson3c]

So, how about that local sports team?

[Baass]

Lets talk about the world cup soccer then.

[Baass]

Here is one.

00000 33 33 00 00 00 fb 00 19 e3 d9 ad e0 86 dd 60 00 33............`.
00010 00 00 00 62 11 ff fe 80 00 00 00 00 00 00 02 19 ...b............
00020 e3 ff fe d9 ad e0 ff 02 00 00 00 00 00 00 00 00 ................
00030 00 00 00 00 00 fb 14 e9 14 e9 00 62 a2 73 00 00 ...........b.s..
00040 00 00 00 05 00 00 00 00 00 00 0b 5f 61 66 70 6f ..........._afpo
00050 76 65 72 74 63 70 04 5f 74 63 70 05 6c 6f 63 61 vertcp._tcp.loca
00060 6c 00 00 0c 00 01 04 5f 73 6d 62 c0 18 00 0c 00 l......_smb.....
00070 01 04 5f 72 66 62 c0 18 00 0c 00 01 06 5f 61 64 .._rfb......._ad
00080 69 73 6b c0 18 00 0c 00 01 08 5f 61 69 72 70 6f isk......._airpo
00090 72 74 c0 18 00 0c 00 01 rt......

[Cold Warrior]

That's not a useful sample. It's just a hex/ascii dump of a particular packet. You're more interested in just the signaling between source IP, destination IP, source port, destination port.

[Baass]

afp over tcp & samba running?

[Baass]

Id = 1
Source = 65.49.90.120
Destination = 192.168.1.20
Captured Length = 74
Packet Length = 74
Protocol = TCP
Information = HTTP -> 50280 ([ACK, SYN], Seq=156233387, Ack=5300806860, Win=5792)
Date Received = 2010-06-25 16:43:54 -0700
Time Delta = 0

[Baass]

Id = 2
Source = 0.0.0.0
Destination = broadcasthost
Captured Length = 342
Packet Length = 342
Protocol = UDP
Information = BOOTPC > BOOTPS
Date Received = 2010-06-25 18:07:04 -0700
Time Delta = 2.078274011611938

[Cold Warrior]

Well this was really meant for you to help you see that the port enumeration isn't abnormal. In this example you can see that this LAN client (identifiable by its private IP 192.168.0.3) is communicating with a public IP. They chat back and forth in order to load a Google web page, and you can see that port 80 and an ephemeral port are used for the exchanges. Port 80 is on the public side since it's http; dynamic on the LAN side.

[Baass]

Thanks cold warrior. My connections are not timing out so quickly at present. I will keep looking at the traffick. I had not seen this port usage in tiger at all. Did you just open a port in that range?

[Cold Warrior]

Ephemeral ports are auto-negotiated for limited transactions. They're dumped after a while and not exclusive to all networked applications (meaning you'd likely see Mail or Thunderbird, both email apps, using different ephemeral ports).

Honestly I would scrap whatever port blocking you've done and use OS X's Firewall setup in Security preferences. If your needs are more advanced, we can help you find other options.

[Baass]

Cold warrior, thanks for the suggestions and advise. Probably, I just need to worry about the dropped connections, reverse DNS and unsolicited trouble maker connections. There was a bunch of requests from the range 65.49.xxx.xxx, which when allowed to connect caused a lot of problems that often seemed like a root access. Once this was taken care, connections are more stable and the pages that I am getting more frequently are actually from the IP addresses to which the primary request is made. OSX firewall does not seem to be fool proof. At least that's what I find with my system. Do you know where can I find documentation on applicationfirewall rules and script? Where are the rule and script files located in snow leopard?

I am logged into macnn and the ip address is corresponding to that of google 66.102.7.101. Is this the IP addres for macnn?