IP showing only as a dot . in access logs

IP field not filled

[Iskandrian]

Recently entries like the following have been appearing in my access logs

. - - [07/Jul/2014:02:07:41 -0700] "GET /page/70/?blog=wojrxunpshbxzs HTTP/1.1" 200 22226 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36"

where the only IP information is a single dot. My searches of WebmasterWorld point to this possibly being a host server problem, and so I've already presented the problem to them along with representative entries like the above and the corresponding logs they came from. The response to date has been that they can't reproduce the issue and ask if I know if one particular IP is causing this. I don't.

My question is twofold.

First, because there seems to be no sort of IP to communicate with, is this sort of thing necessarily a case where the visitor can at most just fill my logs with initial requests that go no further? If so, I can just ignore it.

Second, though, if the visitor is somehow able to transact business on my site (spam, hacking attempts), is there a method of denying access via .htaccess based on nothing but a . as the IP? I am so far unaware of one, and the UA in all of these cases seems to my ignorant eyes like a common browser, so I'm hesitant to use that as a variable. I have no interest in visitors from . dot.

I respect this site immensely and have learned much from reading it periodically. Thanks for any help you can give me now.

[lucy24]

based on nothing but a . as the IP

If that's actually the header they're sending, it would be

!^\d+\.\d+\.\d+\.\d+$

slotted into the "IP" section of whatever Apache mod you use for lockouts. (Uh... this is Apache, right?) That is, until you start getting IPv6 visitors; then you have to tweak it.

The UA looks legit, unless there's some tiny detail I don't see, like a spurious browser version number.

But it really seems like a logging issue.

[Iskandrian]

Thanks, Lucy; yes, Apache, 2.2 if I recall. As my original post may have indicated, results from my host support can be problematic, but I remain hopeful that they will soon grasp the nature of the problem presented to them and that it will just turn out to be a logging problem.

Should I implement that string in my mod_authz_host (Allow/Deny) section, what if any collateral damage could I do to anyone coming from anywhere other than . ? Thanks again.

[lucy24]

what if any collateral damage could I do to anyone coming from anywhere other than . ?

There shouldn't be any. A normal, correct IP is in the form
^\d+\.\d+\.\d+\.\d+$
(numerals, dot, numerals, dot, numerals, dot, numerals)
or technically
\d{1,3} et cetera
but let's not borrow trouble
and we're making a rule to lock out the ones that don't match. Since we're not sure what form is actually reaching the server, the rule is best expressed as a negative: "the IP is not in this acceptable form". This will only affect the unwanted visitors.

That's assuming you've got malign robots intentionally not sending an IP header. (Is this even possible?) If it's honest humans whose ISP and/or browser is acting up, then yes, there can be collateral damage. That's why it is important to have a friendly 403 page.

:: detour to test site because I'm making this up as I go along ::

Drat. mod_setenvif doesn't seem to recognize ! in patterns, so that leaves mod_rewrite:

RewriteCond %{REMOTE_ADDR} !^\d+\.\d+\.\d+\.\d+$
RewriteRule .? - [F]

As with any RewriteRule leading to the [F] lockout, make sure there is an exemption for your custom 403 page. Otherwise the server goes into an infinite loop resulting in a behind-the-scenes 500 error.

---

:: now waiting for punchline to reveal that the host's logging rule forgot to update itself for IPv6 requests, and that's what is happening here ::

[Iskandrian]

Ah, excellent.

:: now waiting for punchline to reveal that the host's logging rule forgot to update itself for IPv6 requests, and that's what is happening here ::

That very well may be the case. A big across the board upgrade to PHP 5.4 is planned, so they may be behind on IPv6 as well.

Thank you again for the useful, to the point info. So far nothing obviously troubling has appeared in the rest of the log entry, so for the moment I shall wait watchfully for further breakthroughs by all parties, support included. But I did want to position myself ahead of the curve if possible, because I prefer visitors to my house to wear faces.

[lucy24]

A big across the board upgrade to PHP 5.4 is planned

Oh, my, that sounds familiar. Either we're on the same host, or they're all racing to copy each other ;)

:: detour to check ::

Huh. When I wasn't looking, MAMP switched to 5.5 as its default, so a real-life move to 5.4 is high time. But my live sites are all 5.3,* so presumably they do it in overlapping waves. Wonder if we'll get Apache 2.4 before 2.6 comes out? :)


* Except the test site, which I've just changed to 5.4 to see if it explodes.

[Iskandrian]

For anyone chasing this issue in the future, I'm afraid all I have to offer at this point is this denouement. Beyond confirming it wasn't an IPv6 issue, there wasn't much interest on the host side itself in this anomaly. They did offer to move me from my shared server to VPS temporarily while they changed the Apache settings in order to see if they could track down the IP, then back again, but as I mentioned to them that process would have been more disruptive than the current issue itself.

Apparently a nextgen Ubuntu OS may provide better inherent logging capabilities than my current one. In the meantime, should things turn malicious I still have the kind Lucy's excellent remote address block.