Currently Being ModeratedFeb 23, 2011 2:58 AM (in response to Chuck Risher)Your firewall is doing its job.A collection of clinking, clanking, clattering caliginous junk., Mac OS 8.6 or Earlier, PDP11
Currently Being ModeratedFeb 23, 2011 6:22 AM (in response to Chuck Risher)As DaddyPaycheck says.
My router's log is full of such messages. The attempts are thwarted by the firewall; nothing to worry about.iMac 24" 1.93GHz/620/4G, Mac OS X (10.6.4), Mac Book 2.4/250/2G, MacBook 2.4/160/2G, 10.6.5
Currently Being ModeratedFeb 23, 2011 8:32 AM (in response to DaddyPaycheck)Do this affect my speed or latency?MacBook, Mac OS X (10.6.6)
Currently Being ModeratedFeb 23, 2011 9:01 AM (in response to Chuck Risher)No effect whatever.iMac 24" 1.93GHz/620/4G, Mac OS X (10.6.4), Mac Book 2.4/250/2G, MacBook 2.4/160/2G, 10.6.5
Currently Being ModeratedFeb 23, 2011 10:56 AM (in response to Chuck Risher)Nope.A collection of clinking, clanking, clattering caliginous junk., Mac OS 8.6 or Earlier, PDP11
Currently Being ModeratedFeb 24, 2011 12:16 PM (in response to Chuck Risher)I am getting contra-indicatory info on my mac re stealth. I have it switched on and yet the system profiler says it is off. A Gibson research Shields up port scan indicates stealth mode is operative on the first 1056 ports and yet fails the ping test.
Anyone know what is happening here? Either the stealth mode or the profiler is at fault.
I am wondering whether the "flood" of connections attempts is because of the response to ping requests.
I have exactly the same problem on both of my macs.Macbook pro 13, Mac OS X (10.6.6)
Currently Being ModeratedFeb 24, 2011 1:12 PM (in response to adeypoos)Stealth mode means that the firewall (preferably at the hardware router) doesn't respond to those requests, so no matter how many log entries there are, none of the attempts are successful.
If the hardware firewall in your router/modem is operative and in stealth mode, the Mac's internal firewall is irrelevant.
The 'flood' of attempts is completely normal; they go on all the time, as my router's logs attest.iMac 24" 1.93GHz/620/4G, Mac OS X (10.6.4), Mac Book 2.4/250/2G, MacBook 2.4/160/2G, 10.6.5
Currently Being ModeratedMar 12, 2011 4:18 AM (in response to noondaywitch)There are several reasons for it. Most of them are not "your firewall is doing its job". I have a bunch of:
Mar 12 03:08:47 laptop Firewall: Stealth Mode connection attempt to UDP 192.168.0.23:63923 from 192.168.0.1:53
Notice that the IP address is the same for both of them. This is actually some stupidity on the part of some system software, specifically, the libinfo portion of libc, which has elected to send DNSResponder traffic to itself over the main network interface instead of the loopback. Looking in a Terminal window, I see the following:
% ifconfig en1 inet
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.23 netmask 0xffffff00 broadcast 192.168.0.255
% grep " 53/" /etc/services
domain 53/udp # Domain Name Server
domain 53/tcp # Domain Name Server
indicating its me talking to me about DNS stuff over my airport.
Technically, there's no good reason it should be using the more expensive physical network interface, rather than the loopback, or a UNIX domain socket. Someone is just not a great programmer (clearly, the firewall is blocking the request, so it's not like it's even marginally useful).
The real bogosity is the log message, however; the log message should not be claiming "connection attempt" -- UDP is a connectionless protocol.
Let's take another one...
Mar 12 03:30:07 laptop Firewall: Deny nmblookup data in from 192.168.0.1:137 to port 64558 proto=17
% grep "17" /etc/protocols
# from: @(#)protocols 5.1 (Berkeley) 4/17/89
udp 17 UDP # user datagram protocol
...this is amusing: it was too lazy to pull the protocol number out of /etc/protocols by using the C library function getprotobynumber(), and instead reports a numeric protocol. Technically, all of these examples should be calling the C library function getservbyport() as well, and telling us the service name from the /etc/services file as well; in this case, it's:
% grep " 137/" /etc/services
netbios-ns 137/udp # NETBIOS Name Service
netbios-ns 137/tcp # NETBIOS Name Service
Again, we have a work of genius here... my file sharing isn't enabled, and it isn't like I would use SMB/CIFS (Windows file sharing) in the first place... this isn't a Windows machine. So why the attempted request, and why the log message for it?
It turns out that 192.168.0.1 is my border rother: this is my DHCP server, and it's the computer which is sharing my network connection with the machine logging the message. Why is it trying to see what SMB shared I have available for it?
The answer is that Finder, in its infinite wisdom, attempts to populate the "Bonjour Computers" list when there are any "nearby" network servers. It does this by running the program nmblookup periodically as a directory services plugin when it polls directory services for nearby computers (SMB requires a poll request to the network). So it sends these packets out, and if the computer it sends to has its firewall up, you get the log message. This happens even if you have the sidebar item ticked closed because you don't want to see the servers coming and going, and it happens even if you don't have a Finder window open in the first place, so it's looking for something it's never going to display to anyone.
(Note to self: stealth firewalls: you're only as stealthy as keeping your mouth shut about sending unsolicited request packets; you can pretty much fingerprint "stealth" Mac computers on your network by listening for this and Bonjour traffic, and then attack them by DNS cache poisoning them when they check for a software update)
Let's take one of the cases from above now...
Mar 12 03:42:39 laptop Firewall: Stealth Mode connection attempt to TCP 192.168.0.23:52424 from 184.108.40.206:80
OMG! I'm being HACKED, right?!? Wrong.
First of all:
% grep " 80/" /etc/services
http 80/udp www www-http # World Wide Web HTTP
http 80/tcp www www-http # World Wide Web HTTP
...really, firewall, no reason to be all mysterious about the actual service/port # here... report it by name, please. Now let's see who is "hacking me":
% host 220.127.116.11
Host 18.104.22.168.in-addr.arpa. not found: 3(NXDOMAIN)
OMG! A fly-by-night-hacker! Wrong again:
% open -a Safari http://22.214.171.124/
...it's only my friendly neighborhood Google. But why is this getting logged?!?
The application firewall is not a stateful firewall; it can't tell the difference between a socket that was recently open and then closed, and a socket that was never open. So it reports it. But should it really be reporting this in this case? It turns out the answer is "no".
When a TCP packet is sent from you, it's a request. When a response is sent to you, it's not a request, it's a response. There's a bit in the TCP header for this, and it's set when someone is responding to a request you made. In this case, it's sending me page data for the Google search page, which is my default home page. I frequently start typing a URL, if I already know it, before that page finishes downloading, and with autocompletion from my browser history, I go a step further and hit return, navigating away from Google before it's finished sending me data. The rest of the response is sent after the socket that made the request has been closed.
Why it shouldn't log: it's not a connection attempt. You can't establish a new connection using a packet that has its response bit set anyway. Minimally, it should be complaining about spurious response packets. A better fix would be to ignore them if they have the response bit set. The best fix is to not log at all for packets that come in with the response bit set for no longer existing connections, since you are going to RST (send a reset to the responding machine telling it you don't love the connection any more, and they can quit doing work for you).
So overall: most of the stuff that's getting logged is not useful and noisy at best, the result of poor software on your machine or your gateway at second best, and unhelpful and misleading at worst.
NB: The reason this last is "at worst" is that it drowns out the legitimate log reports so that they are hard to see, even if you are like me and care about this sort of thing: too much information is as bad as no information, and you get a false sense that because you are getting any information at all, that there's nothing you should be worrying about, which isn't true.
Hope this answer helps!
Currently Being ModeratedMar 17, 2011 1:27 AM (in response to Chuck Risher)I figured out these connection attempts are from bittorrent clients. When I do not have Vuze running, I still get queries from other clients and they hit the firewall.MacBook, Mac OS X (10.6.6)
Currently Being ModeratedJul 19, 2011 10:51 AM (in response to Terry Lambert)
It's a noisy Apple network via things like Bonjour trying to find printers, shares, etc. - You can safely ignore these messages.
If you want to be really safe run Little Snitch, ClamAV and don't install nefarious MacDefender malware. You can do this by only getting apps from places like MacUpdate and Versiontracker (cnet) and read through the comments to verify not adware, malware, etc. If no comments at all, then be a little wary about running unknown apps.
Also, keep your apps up to date. Things like Skype, etc. often issue updates to address vulnerabilities. While the truth is, Macs are pretty secure and even the last Skype vulnerability required that you had to allow the attacker to be in your address book or whatever (IOW, yawn...), if there's ever a widespread attack like we see within Windows machines, you're better off with these best practices.
All that said, it's extremely unlikely anyone will do anything to your Mac from the outside. You should be much more concerned about what apps YOU install on your computer and from WHERE.
The main reason I even run my Mac's Firewall at all (at this point) is because I have various testing servers on my Mac for development purposes and want to keep those stealthy.
Currently Being ModeratedJan 2, 2012 6:15 AM (in response to Cowicide Moo)
It is normal that one side of the local-computer's numerical port should be at, or above, 49152, and the other side of the network's numerical port should be at, or below, 49151.
This numerical figure of 49152 is three-quarters of the way from 0 to 65535 (65535 is 2-raised-to-the-16th-power minus 1).
Anything at, or above, 49152, is a so-called "dynamic" "source port", and the number is assigned somewhat randomly by the local-computer (or the initiating side called the "client").
Anything at, or below, 49151, is the "destination port" on the non-initiating side (also called the "server").
The exception to these rules is "peer-to-peer" communication employed by processes like BitTorrent and Limewire, and the time-setting daemon called "ntpd" .
In these "peer-to-peer" communications, the "source port" is NOT "dynamic", and pretty-much mimics the "destination port" -- in the case of ntpd, both sides (both client, and server), have a numeric port value equal to 123.
Now comes the interesting part !
Domain Name Service invoves the translation of a URL-domain to that of an IP-address.
In the Summer of 2008, a DNS-poisioning Exploit was discovered that could have disrupted the entire internet.
Prior to the Summer of 2008, it turned-out that it was possible for a malicious man-in-the-middle to "spoof" DomainNameService requests (server destination port 53's) with a reply flood of combinations, to hit-upon the correct combination such that the local computer's DNS-cache accepted the bogus information, and thus, was poisoned.
Software Updates, amoungst other sites, would be re-directed to bogus sites.
The solution was to change the non-peer-to-peer communications (the one's involving dynamic ports on the client-side), so that there was a method to assigning the dynamic port's numerical value -- the practice (I think) was called "source-port-randomization".
How this "source-port-randomization" could possibly apply to peer-to-peer connections, however, is beyond me (since there is no dynamic port invoved, to be randomized).
(Note that DNS requests are NOT peer-to-peer).
You may want to avoid BitTorrent and Limewire.
Message was edited by: Randall Blanchard
Message was edited by: Randall Blanchard
Message was edited by: Randall Blanchard
Message was edited by: Randall Blanchard
Currently Being ModeratedMar 14, 2012 3:55 PM (in response to Terry Lambert)
Terry...if every response to technical questions on this forum went into as much detail as you did, the world would be an infinitely better place.
Thank you so much. You really need to write a book- especially because your response was not only inclusive and comprehensible but on top of it concisely providing an awesome amount of information, there was a hint of sarcastic, dry humor to it that actually made it easy to read and pay attention to.
Seriously. Write a book about security. I'll love you forever.