[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.

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 ]

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]

::

Links

[ Find and Xargs | dmiessler.com ]

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. ::

IDLE is not — according to my definition above — a true push technology. IDLE actually requires an active connection in order to work, and that connection cannot be initiated by the server.

[Update]: Yahoo! uses P-IMAP, not IDLE to implement “push”…[ Link: An Introduction to IMAP IDLE ]

[ Link: Unix/Linux Permissions ]

• Arpwatch, used for mac anomaly detection.
• P0f, used for passive OS detection and os change analisys.
• Pads, used for service anomaly detection.
• Nessus, used for vulnerability assessment and for cross correlation (IDS vs Security Scanner).
• Snort, the IDS, also used for cross correlation with nessus.
• Spade, the statistical packet anomaly detection engine. Used to gain knowledge about attacks without signature.
• Tcptrack, used for session data information which can grant useful information for attack correlation.
• Ntop, which builds an impressive network information database from which we can get aberrant behaviour anomaly detection.
• Nagios. Being fed from the host asset database it monitors host and service availability information.
• Osiris, a great HIDS.

(thanks to Average Admins for the find)

I prefer to use Windows Server 2003 as a workstation instead. Why? Mostly because of raw socket limitations. I hate the fact that security software is hit or miss on XP. I simply lack the time to worry about whether or not XP will gimp up a given security tool.

So I’ve just built my latest Windows VMware image (for Outlook, Word and Visio) using Server 2003. Office 2007, by the way, is awesome. I very much like the ribbon concept, as well as the other more subtle improvements. And Office 2007 runs great on Server 2003, so this is a good thing.

It’s become very clear to me that XP is an OS designed for the masses. It’s edges have been rounded so that people don’t cut themselves, which is unfortunate since I was actually using them to get work done. Luckily for me there’s another Microsoft platform that runs Office, and until the next version of server comes out this is what I’ll be running as my Windows “desktop”.

Do you want to continue [Y/n]?

Just press enter. The “Y” being capitalized means it’s the default. :)

I think we all know this, but so many of us still type the “Y” out of habit. This is my attempt to free you from doing so.

What this means is that I can finally use real domain names in my certificates (self-signed) for two separate hostnames while avoiding the annoying prompts that OS X likes to throw when it senses tomfoolery.

Here are the steps:

• Create your Postfix certificates the way Weitse wants you to, using your SMTP hostname.
• Import both the CA cert and your actual Postfix certificate into OS X.
• For IMAP, edit your imapd.cnf file to reflect your IMAP hostname, etc.
• Run mkimapdcert.
• Import that certificate into OS X.

Now when you open Mail.app you should not get prompted to accept any certificates. The trick is that you need to import the CA’s cert on the Postfix side or it won’t work. But with courier this is not required. It has something to do with the format of the certificates being different.

It’s on my list of things to research, but for now I’m just happy I got it working exactly as I want it.

The Problem

The main issue we’re all grappling with is the number and complexity of the passwords we need to remember. Ideally, we would never share a password between any two sites. They would all be different and at the same time highly complex. Unfortunately, this doesn’t mesh well with reality. The human brain just isn’t up to the task.

Simplification Through Classification

The way we get around this limitation is to classify our online accounts according to risk. In other words, we’re going to determine how important each of our accounts are, and then put them into one of three (3) groups. For the purposes of this article we’ll use the military classifications.

1. Top Secret
2. Secret
3. Confidential

Next we’ll simply group your Internet account types into each of these categories:

• Top Secret Banking, brokerages, financially or identity-oriented sites. Think about your social security number and other sensitive personal data. Any accounts of this nature you want to protect with your strongest layer of security.
• Secret Personal email, blogging sites, important forums, etc. These are your main accounts that you use on a day-to-day basis. They aren’t ultra-sensitive, but they a huge part of your life and need to be secure.
• Confidential Product forums, mailing lists, etc. These are your low-risk accounts, meaning that if one were to be compromised it would be annoying but not a major problem. We’re still going to have relatively strong passwords here, but they’re going to be simple in comparison to the two higher levels.
** Also keep in mind whether or not a site supports encrypted logins or not when assigning your accounts to these groups. Never put an account into the top two groups (Top Secret or Secret) if that site doesn’t support encryption. We don’t want someone possibly intercepting one of your upper-level passwords.

Designing Our Password Schemes

Ok, now that you have your accounts grouped properly it’s time to design our three password systems. We’ll start with the Top Secret:

Level 1 — Top Secret: For this level we’re going to use a combination of upper-case, lower-case, numbers, and special characters. We’re also going to make the password at least 12 characters in length. You will be writing these passwords down on a card in your wallet or purse, so it doesn’t matter if you can’t remember the password at first. After you use it a few times it’ll become second nature regardless of how complex it is. Try something like this:

5PF.c9a8>12!

It looks pretty scary, but you’d be surprised how easy it is to remember once you type it a few times over a number of days. The point is that it’s not going to be guessed, and it’s not going to be tied to another account. If you absolutely have to, you can use a sentence algorithm to build the password, like so:

My Online Bank Password Is Not Simple To Guess At All, Julie.

M0bP1n5tGAAJ.

You will be writing these passwords down on a card in your wallet or purse, so it doesn’t matter if you can’t remember the password at first. After you use it a few times it’ll become second nature regardless of how complex it is.

One point on writing down passwords: Many people think this is a bad idea, but that fully depends on how you secure them once their written down. Sticky note on monitor? Bad. Wallet? Good. You have to balance the risk of strong passwords in your wallet vs. weak ones in your brain.

Regardless of the scheme you use to create your passwords, you want them to be a) pseudo-random/highly complex, b) over 10 characters in length, and d) absolutely unique. In short, we don’t want someone with your brokerage account password to be able to log into your bank with the same credentials.

Level 2 — Secret:

With the secret level accounts we’re going to introduce an aspect of simplicity/usability. We’ll do this by creating an algorithm for creating and varying passwords for various sites while still maintaining the appearance of randomness within each individual password.

In short, all level 2 (Secret) passwords will be generated by the same algorithm. As such, they’ll look very similar to you, but will look like random garbage when viewed independently by an outsider.

So let’s build your Level-2 (Secret) algorithm; we’ll use a Gmail account as a template:

[This is just a sample algorithm; you should make your own.]

1. First two letters + last letter of the account. GML
2. Add the three letters up and subtract your birthday. G (7) + M (13) + L (12) = 32 – 15 (if you’re born on the 15th) = 17 GML17
3. Add the two numbers you made to create a third number. 17 = 1 + 7 = 8 GML178
4. Add a word for length. Use character substitution for complexity if you want. GML178H0lid4y
5. Add special characters. !GML178H0lid4y#
6. Scramble as desired. !H0lid4y#GML178#

You now have a very solid password for your Gmail account. But it gets much better than that. You’re using the same algorithm for all your level 2 accounts. So do the same for your Hotmail account and you’ll end up with:

!H0lid4y#HOL358#

Level 3 — Confidential:

For our lowest security level (3) we’re going to use an algorithm similar to the secret level (2), only it’s going to be completely different and much simpler. Remember, these are your unimportant accounts; you wouldn’t want them to be compromised, of course, but if they were then it wouldn’t be that big of a deal.

Let’s make a level 3 algorithm for a site called cars.com:

1. Last letter then first letter of the site (cars). SC
2. A word to be used for all your low level accounts. Add a single character of number substitution (i to 1) SCPubl1c
3. Use a special character. SCPubl1c$
4. Scramble as desired. $Publ1cSC

Again, you now have a decent password that’s not easy to guess and will give a bit of difficulty if someone gets one and tries to guess others. Of course, if they get one of these level 3 passwords and try to break your Secret (2) or Top Secret (1) passwords, they’ll be unsuccessful.

Conclusion

Using this system can increase both security and usability when working with multiple accounts online. Here are a few additional guidelines about this technique and passwords in general:

• Vary your algorithm for level 2 and 3 accounts regularly (I recommend at least once a year)
• Memorize your algorithm and write down your passwords on a card in your wallet. Don’t write down the algorithm itself. Just seeing a password created with it should jar your memory.
• For an extra layer of security you can consider leaving out or modifying a crucial part of the passwords you write down. This way, even someone with the card will not be able to use it. Be warned that if you forget what you changed, however, you’ll be very upset.
• Change your level 1 passwords often as well. With the strength that we’re using in this article I’d advocate once every 6-months.
• Many also use what’s effectively a level 4 account, i.e. a throw-away password that is used for accounts even lower in importance than level 3. Usually this is a static password. Just be sure to be very selective about where you use such a password, and make it as complex and long as possible while retaining its benefit of simplicity.
• An encrypted database is another option for managing passwords. I advocate this method over that one due to issues with losing or damaging the portable storage that the DB is stored on, in addition to not being comfortable with using such a system on a foreign computer (where necessarily you open ALL of your passwords to the system being used). It’s really a matter of personal preference, however, as both systems have their strengths and weaknesses.

I hope this has been useful. For any questions or comments, please feel free to contact me directly.:

1. A blog to read.
2. Some primers and articles.
3. A way to check your external IP address.
4. Very accurate time (HTML).
5. A solid time server (204.11.219.126 UDP 123).
6. A solid DNS server (204.11.219.126 UDP 53).
7. A friend.

# watch -n1 "ifconfig eth0 | grep Mb"

RX bytes:105209490 (100.3 Mb)  TX bytes:448524558 (427.7 Mb)

What you end up with is a counter of your current bandwidth usage that gets updated every second. It’s not sexy but it gives you a decent feel for how much action your NIC is seeing.

Just change your network interface in the grep bit to the one you want and you’re all set. Oh, and if you’re using Debian or Ubuntu, you may want to try grepping for “Mib” instead of “Mb”.

Enjoy.: