Granted I’m only a couple hundred miles away from my datacenter for this test, but I am loading a fairly typical page of content here in 128ms. That’s pretty sick. We’re talking a tenth of a second for a full page load.

Here’s how I did it.

::

These are the ones I often seem to need.

[bash]a2enmod headers a2enmod expires a2enmod rewrite[/bash]

Then bounce the service:

[bash]/etc/init.d/apach2 restart[/bash]

[ If it seems like this post is a note to myself, that's because it is. :) That's how the entire site got started, actually. ]

So, most of us have heard about Google offering public DNS services now. What most don’t know is that there are three (3) IPs available currently rather than just two (2). Here they are, in one place:

1. 8.8.8.8
2. 8.8.4.4
3. 4.3.2.1 // the one google hasn’t talked about yet

And, yeah, they’re fast. I’m pinging them sub 1.5ms from this server, and DNS responses from them are blazing.

::

* I’ll be updating this post as Google announces more IPs, as a reference for myself and anyone else.

So I’ve been messing with Splunk> a bit recently, and as part of that I’ve been sending logs from iptables, snort, and apache–not to mention the other stuff that naturally lands within /var/log/messages.

As you can see, the reason I’m doing this is to get a brutally powerful data view in one interface. Here I’m showing some GET requests within my Apache logs, but I currently have saved searches for all these various types of information:

• drops on my firewall
• accepts on my firewall
• successful SSH logins (password or key)
• failed SSH logins (password or key)
• associations to my wireless
• incoming GET requests to Apache
• user agents

The key with Splunk> is the quickness in which you can search raw data, and create powerful visualizations of the results.

firewall drops by port within 3 hours

Syslog Setup

So this all requires that Splunk> see your log data; here’s how to set up syslog-ng to forward your various log types to an arbitrary destination.

netfilter/iptables

Log your desired traffic (this is my default-deny at the bottom of my ruleset)

[bash]/sbin/iptables -A INPUT -i eth0 -d $SENECA -j LOG –log-level 7 –log-prefix "Firewall: Default Deny: "[/bash]

This will automatically go to syslog on most systems.

Apache

You don’t do anything specific in Apache, other than make sure you’re logging the stuff you want. I prefer to get user-agent and such in my logs:

[bash]LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined LogFormat "%h %l %u %t \"%r\" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-Agent}i" agent LogFormat "%v %h %l %u %t \"%r\" %>s %b %T" script LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" VLOG=%{VLOG}e" vhost[/bash]

syslog

Then for the most important piece you have to:

1. Tell syslog-ng to parse your Apache logs
2. Tell syslog-ng to send logs to your remote system (Splunk, in this case)

First, here’s how you get arbitrary, quickly expanding logs into syslog-ng:

[bash]source access { file("/var/log/apache2/access_log" <em>follow_freq</em>(1) flags(no-parse)); };[/bash]

This names a source access (for access_log) that will be harvested from a file. The file is my main Apache log. The important bit is the follow_freq(1), as it keeps you from having to do crazy tail / pipe tricks to get access_log's input into syslog-ng. The 1 says to parse the file for new content every second.

Then you need to define a destination for your logs:

[bash]destination logserver { udp("your.remote.logserver.dns" port(514)); };[/bash]

And then give the log command, which calls your custom source and your custom destination:

[bash]log { source(access); destination(logserver); };[/bash]

[ ** Don't forget to also add log lines for your default syslog source as well. ]

And that's pretty much it. Configure Splunk to listen on UDP/514 and you will have some decent data to start playing with. ::

Links

[ Splunk Search Syntax | splunk.com ]

My buddy at work asked me if I could find some location information for a list of IPs. I knew of the GeoIP / GeoLite project(s), so I said yes and then proceeded to put together the following quick hack in bash.

Here’s what it does:

1. Pull a list of IP addresses from your apache logs (you can get the list from anywhere, of course).
2. Strip the duplicates (using uniq)
3. Use host to get the DNS entry for the IP
4. Use the default geoiplookup to get the country for the IP.
5. Use geoiplookup with the city file passed to it to get the city (and other info) for the IP.
6. Output the whole thing into a .csv file that will import instantly into Excel.

[bash]#!/usr/bin/env bash cat /var/log/apache2/ | awk ‘{print $1}’ > ips.txt uniq ips.txt > uniques.txt IPS=’cat uniques.txt’ echo “” > ./ipinfo.csv for i in $IPS do echo “$i,’host $i | awk ‘{print $5}”,’geoiplookup $i | cut -d “,” -f2 | sed -e ‘s/^[ \t]//”,’geoiplookup -f /usr/share/GeoIP/GeoLiteCity.dat $i | cut -d “,” -f3 | sed -e ‘s/^[ \t]//”,’geoiplookup -f /usr/share/GeoIP/GeoLiteCity.dat $i | cut -d “,” -f4 | sed -e ‘s/^[ \t]*//”” >> ipinfo.csv done [/bash]

[ The backticks have been changed to single quotes so it would render correctly. Here's the original file. ]

Here’s what the output looks like:

[text]193.110.229.12,host12-193-110-229.limes.com.pl.,Poland,82,Gdansk
189.20.216.229,3(NXDOMAIN),Brazil,27,São Paulo
81.192.159.138,ll81-2-138-159-192-81.ll81-2.iam.net.ma.,Morocco,07,Casablanca
189.20.216.229,3(NXDOMAIN),Brazil,27,São Paulo
76.27.75.237,c-76-27-75-237.hsd1.ut.comcast.net.,United States,UT,South Jordan
189.20.216.229,3(NXDOMAIN),Brazil,27,São Paulo
123.125.66.70,3(NXDOMAIN),China,22,Beijing
70.183.232.136,wsip-70-183-232-136.pn.at.cox.net.,United States,FL,Pensacola
66.249.70.108,crawl-66-249-70-108.googlebot.com.,United States,CA,Mountain View
193.212.60.77,3(NXDOMAIN),Norway,01,Fornebu
189.20.216.229,3(NXDOMAIN),Brazil,27,São Paulo
193.110.229.12,host12-193-110-229.limes.com.pl.,Poland,82,Gdansk
83.16.251.58,ajr58.internetdsl.tpnet.pl.,Poland,82,Gdansk
193.110.229.12,host12-193-110-229.limes.com.pl.,Poland,82,Gdansk
212.247.189.113,3(NXDOMAIN),Sweden,25,Västerås[/text]

Setup

So there are a few quick things you need before this will work:

• geoip, which gives you the geopiplookup command.
  1. The GeoLiteCity.dat file manually, which you need to put somewhere. I put it next to the default one that comes with geoip, which is in /usr/share/GeoIP/.
  2. ensure the paths in your environment match the paths in the script.

Of course, if I were really cool I’d use a real programming language and one of the APIs, but this is quick, dirty and effective. I’m thinking about building a rails-based web service for doing it. If anyone’s interested or has any comments on this one, let me know in the comments or send me a mail at daniel@dmiessler.com. ::

There’s an issue with md5sum where it returns unexpected results due to the fact that appends a carriage return to what you’re trying to get a sum of.

So if you try and get a sum of “password” by summing a file with the word “password” as the only line in the file, you won’t actually be summing “password”, but rather “password[^M]“, which obviously won’t be the same.

The Fix

So a quick fix for this is to use echo to feed md5sum with the -n option, which removes the trailing carriage return:

[bash]echo -n “password” | md5sum[/bash]

::

find . -type d -name .svn -print0 | xargs -0 rm -rf

Links

[ Find and Xargs | dmiessler.com ]

Well, I’ve finally [fingers crossed] moved my site to my new host. I’m doing the most depressing of moves–going from colocation to “regular” hosting. But at least it’s good hosting. Rather than go the discount route I went with Media Temple (mt), which according to my research is just about as good as you can get without doing colo.

Anyway, I expect problems.

Please let me know if you see anything funky with the site itself or with my syndication feeds. And any input on differences noticed would be great, e.g. if the site is slower now, or faster, or whatever.

Here are my feeds in case you don’t have them…

[ dmiessler.com Syndication Feeds ]

My opinion on security and obscurity is that obscurity can in fact help improve an already sound security posture. That’s keeping in mind that it should never become security by obscurity — which is definitely bad.

Anyway, I’ve debated this issue for years with many people, and I remain convinced that my position on the matter is correct. But tonight I decided to do some very coarse testing of the idea using the SSH daemon.

I decided to configure my SSH daemon to listen on port 24 in addition to its regular port of 22 so I could see the difference in attempts to guess credentials on each. My expected result is far fewer attempts to access SSH on port 24 than port 22, which I equate to less risk to my, or any, SSH daemon.

It’s quite simple to set this up; you just put two port lines in your config instead of one, and then restart your daemon:

Port 22
Port 24

Then I added logging to a couple of my firewall rules:

-j LOG --log-level 7 --log-prefix "Logged port 22: "
-j LOG --log-level 7 --log-prefix "Logged port 24: "

(log rules go before their associated DROP, REJECT and ACCEPT rules, btw)

…and I’ve let that run for over 8 hours…on an unremarkable Saturday.

The Results

Well, it’s definitely true that very few people look for SSH on port 24. In the time that I gathered 7,025 connection attempts to my SSH daemon on port 22 I received 3 on port 24.

Three.

[UPDATE: The stats over the weekend were over 18,000 connections to port 22, and five (5) to port 24.]

That’s fine, but the real question is this: would it reduce my risk of being compromised remotely through my SSH daemon if I were to change the daemon’s port to 24? I think the answer is yes.

Let’s assume that there’s a new zero day out for OpenSSH that is just owning boxes with impunity. Is anyone willing to argue that someone unleashing such an attack would waste significant effort going for non-standard ports? Or are they more likely to stick with the default port where they’re guaranteed to find more daemons?

I think we do gain security by moving commonly-attacked listeners to non-standard ports. And yes, that extra security does come from obscurity. Remember, even tanks are painted with camouflage. ::

After over six (6) years of handling my domain’s email through self-built and administered Linux boxes, I just migrated all my email functionality over to Google. This has never been a solid option for me for one primary reason: the mixing of gmail.com with my own domain (danielmiessler.com). Forwarding and changing “reply to” settings has never been that attractive to me.

That problem has been solved. You can now let Google handle your domain’s email while keeping your existing addresses. That means you still get Google’s webmail interface (exactly like GMail) but everything is tied directly to your domain. It’s called Google Apps.

Google Apps allows those with their own domain to move their entire mail infrastructure to Google. That means keeping your email addresses exactly as they are today (e.g. daniel@danielmiessler.com) while gaining the benefit of being hosted by Google. Here are a few advantages to consider:

• Google uptime
• Google speed
• Long-term stability (they aren’t going anywhere)
• You can use the “GMail” interface as your domain’s webmail and/or use IMAP or POP (way better than most self-install webmail systems)
• You can point http://mail.yourdomain.com to your new GMail interface (like mine).
• You get to keep all of your addresses and present a clean identity to everyone (nobody will see gmail.com in from or reply to fields)
• Google’s industry-leading spam protection
• Full IMAP support (with IDLE)
• Full SMTP support (no need for a separate outgoing server)
• SSL support on both incoming and outgoing mail
• No more worrying about keeping your mail server up

All of Google’s mail power, but for your domain. Notice how I’m signing in below; I just enter my first name “daniel”, as my domain is already filled out for me. Way slicker than GMail.

And it’s simple to setup; I did the domain and two accounts in like 10 minutes (including DNS changes) Here are the basic steps:

1. Create a free account at Google Apps
2. Verify your domain ownership with Google (I did the file upload)
3. Change your MX records to point to Google’s mail servers (DynDNS makes this easy)
4. Wait for everything to update (for me, 10 minutes)
5. [optional] Pay the upgrade fee and import everything from another online mail account (GMail, Hotmail, Yahoo!, etc.)

That’s pretty much it. And keep in mind that Google Apps isn’t just for mail; you can also have Chat, Calendar, Docs, and even your main web page hosted by Google. And you can set up shortcuts so that you can get to your online Google Mail by going to http://mail.yourdomain.com. Mine is at http://mail.danielmiessler.com, for example. And you can do the same for your calendar, docs, etc.

So yeah, if you haven’t looked into Google Apps yet, it might be time to check it out. ::