Private IP Addresses Showing In Public Webserver Logging

Today I was spelunking through some logging on the Squarespace backend, and found something peculiar.

The IP address marked by the red frame is a so-called private IP address.

In the Internet addressing architecture, a private network is a network that uses private IP address space, following the standards set by RFC 1918 and RFC 4193. These addresses are commonly used for home, office, and enterprise local area networks (LANs), when globally routable addresses are not mandatory, or are not available for the intended network applications.

These shouldn't show up in the logging of a webserver which is connected to the Internet. Further investigation revealed several other IP addresses;

07/29 at 10:29:20 AM 10.16.121.170
07/27 at 03:46:44 PM 10.31.238.253
07/27 at 08:27:18 AM 10.197.128.25
07/27 at 06:47:17 PM 10.31.245.14
07/25 at 02:08:42 PM 10.86.114.66
07/24 at 12:15:31 PM 10.71.209.105
07/28 at 02:27:47 AM 192.168.100.2
07/27 at 11:11:14 PM 192.168.14.63
07/27 at 03:28:20 PM 192.168.1.24
07/27 at 03:14:36 PM 192.168.7.17
07/27 at 08:25:04 AM 192.168.26.218
07/25 at 05:07:24 PM 192.168.10.2

I opened a support ticket @Squarespace to check if these might be internal addresses. If so, they are using a lot of internal networks.

Dissecting SRX RT_FLOW Logs with Splunk

Now that I have a SRX running at home and a syslog server powered by Splunk (free version) it's time to be able to understand the logging. The raw logging is pretty unreadable for the average Joe. Thankfully, Splunk can be used to make more sense of it.

Downside is that I haven't found any add-ons / plugins etc. for Splunk to analyze the logging of a Juniper SRX firewall. There is a post on the Splunk forum which offers two regular expression which can be used to define the RT_FLOW fields.

Click to read more ...

Enable Juniper SRX Firewall Logging

Juniper started to migrate their firewalls from Netscreen to the Junos environment 'a couple of' months back. The advantage is that there's a universal OS for routers, switches and firewalls. Just like Cisco IOS. The disadvantage is that the Junos OS is being adapted for the firewalls. So the foundations are there, but there are still lots of features missing and bugs are also still abundant.

The bugs are thankfully mostly related to the WebGUI. On the commandlinethe bugs are in the same league as the Cisco, Checkpoint and every other vendor bugs. No piece of software is perfect.

Click to read more ...

OS X Kerberos / Open Directory Logging

Ever since I switched to OS X server at home I use Splunk> to see what's happening 'underneath the hood'. This revealed that there's a lot (really a whole lot) of Kerberos logging going on. Each and every day I get thousands of log entries regarding krb5kdc which results in over 1 million log entries only for krb5kdc in little over a week.

These syslog messages only contain the following 'text';

krb5kdc[16179](debug): routing msg not interesting
krb5kdc[16179](info): got routing msg type 5(RTM_LOSING) v5
krb5kdc[16179](info): routing socket readable

Looks like that the debugging level is set to debug (why??). And why can't we change it? Others seem to have this problem as well.

Looks like that the following command seems to work:

sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" FALSE

After entering that 1 line I haven't seen any new logentries in the kdc logs. More info on that command can be found @ Apple.

Nevermind......