Flooded with "Stealth Mode connection attempt"s

Your firewall is doing its job.

As DaddyPaycheck says.

My router's log is full of such messages. The attempts are thwarted by the firewall; nothing to worry about.

No effect whatever.

Nope.

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.

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.

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[61]: 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[14550]: 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[14550]: Stealth Mode connection attempt to TCP 192.168.0.23:52424 from 74.125.224.213: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 74.125.224.213
Host 213.224.125.74.in-addr.arpa. not found: 3(NXDOMAIN)

OMG! A fly-by-night-hacker! Wrong again:

% open -a Safari http://74.125.224.213/

...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!
-- Terry