Understanding the Dream

Just recently I've been getting a few emails that appear to be from folks who are my Facebook friends, however, these emails are short and only contain a short message and a link to a web site. Being the untrusting cautious type that I am, I do not trust these emails, and neither should you. The following describes how to test an email message to see if it's from your friend or from someone attempting to do you harm.

Important: Never EVER click on a link in an email that you're not absolutely certain is safe.

The following is an email message I received that appeared to come from my Aunt. I have been marking these messages as "junk" in thunderbird, so Thunderbird has learned that I consider messages like these junk, but when I first started getting them, they looked like normal messages.

The first thing I notice is that the email my "Aunt" is sending from looks like it is from someone named "Tracy". Why would my aunt be sending me email from Tracy's account? Yes, big red flag there.

Verify The Source

In the next few paragraphs I'm going to show you how to check ANY message you get to see where it came from. This is an incredibly accurate indication of if a message is safe to read or not.

First, you start out by looking at the email "Headers". The Headers are the bits of information that email servers tack on to an email message when it passes through them. SOME headers are created by the email client that sends it, so not all headers can be trusted, but most of the time the server traversal record can be used to make a fairly accurate decision about whether an email message is safe or not.

To view the message headers in Thunderbird, I clicked on "Other Actions", then selected "View Source" from the drop-down menu. Other email readers have different ways of showing you the headers, but in general it is pretty easy to find if you poke around a little.

So, now that we can see the source of the message, let's take a look at the server traversal record, which I've highlighted below:

The server traversal record headers, like any other header, can be forged. However, it takes some effort to forge the server traversal records, so these headers are *usually* trustworthy. In my example above, you can see that this email message originated from 82.211.142.40, and sent the message by logging in to smtpauth03.mfg.siteprotect.com.

So, since the email message came from the 82.211.142.40 IP address, let's take a look at that and see where that IP is located. We can see where an IP is assigned by doing what's called a "Who Is" on the IP Address. I like using ARIN's web site for this purpose, which you can find over at http://whois.arin.net/ui.

The "Who Is" search box is up in the top right. Let's enter the IP Address there and see where it came from:

The WhoIs will give us a lot of information about the IP Address, what networks it belongs to, and so forth, but the interesting information for most folks is at the very bottom of the results:

So, if my Aunt really did send this message, apparently she did so from Amsterdam, using someone elses email account. Yeah.... right....

Most likely, this is a case of a compromised email account (poor tracy) being used to send out phishing attacks. The web address in the email that was sent to me probably contained an "attack" of some sort - something Flash or Java-based probably - and the attacker probably got my name and the name of my Aunt from our public facebook accounts.

Hopefully you found some of the information here helpful, and you can use it yourself to check messages you get from your "friends" that contain nothing but links.

Hope this helps!

For those of you who may not follow these things, users of the open-source CFML context creation software known as "mod_cfml" should know that the latest release is actually pretty important with regards to security. The mod_cfml software is a group of programs that work together in order to automate the process of creating contexts within Tomcat. Usually the process of creating contexts is a manual job, which is accomplished by editing various configuration files in order to tell Tomcat where to find the files for specific sites and directories (or contexts) when Tomcat receives requests for them. The idea behind mod_cfml is to simplify server management, and make creating contexts in Tomcat happen automatically by passing off configuration information from Apache or IIS to Tomcat so a new context can be made if it doesn't exist yet. Pretty basic stuff.

The problem is that, before this latest release, this process of automating the context creation using mod_cfml could be exploited to create a Denial of Service attack on the system that is running mod_cfml. Using a specially crafted attack that is targeted at mod_cfml, an attacker could potentially issue multiple requests in rapid succession to a vulnerable system. This process would cause many contexts to be created simultaniously, and could potentially overload and/or crash the server.

The newest version of the mod_cfml Tomcat Valve corrects this problem by adding limitors to how quickly new contexts could be created, and how many contexts can be created within a single day time frame. These limitors protect users from the danger that previously existed and the possibility of a DoS attack that specifically targets this issue.

You can install the latest mod_cfml Tomcat valve by shutting down Tomcat, removing the mod_cfml Tomcat valve from the [tomcat]/lib/ directory, and dropping the latest mod_cfml Tomcat valve back into the [tomcat]/lib/ directory. Now, restart Tomcat and you're good to go. Documentation on adjusting the new limitors in the Tomcat valve can be found here:

http://www.modcfml.org/index.cfm/documentation/modcfml-tomcat-valve/config-options/

Railo users who have installed Railo 4.0.3 or newer will already have the latest version of mod_cfml, and OpenBD installers version 3.0 and up will have the latest release. If you are running with an earlier release and haven't updated your mod_cfml Tomcat Valve, you should consider doing so.

Just recently I encountered a situation where I was using a BASH script to evaluate some input and then pass a boat-load of parameters to another executable. It just so happened that one of the parameters I was pasisng was a variable that had a space in it. So... --myvar "my spacey attribute".

This command would work great when I ran the command myself, but as soon as I tried to execute the command in my BASH script, the blasted thing would not evaluate. The executable I was trying to pass the attribute with spaces totally ignored my quotes around the attribute value and evaluated my spaces as the beginning of another attribute. It was frustrating to the extreme! I tried all kinds of different quotation combinations. I re-wrote the same bit of code several different times in several different ways all with the same crappy results.

After much Google hunting, I came accross a post where someone suggested to another to use "eval" to correct a problem he was having with a parsed command (similar to what I was doing, but still quite different). The suggestion was shot down as being "too much" for that particular case, but I had never used "eval" before so I looked it up, and turns out it does exactly what I was needing and then some! "eval" is built int BASH so if you have BASH, you have eval. Here's my example...

Using this:

#!/bin/bash
myExecutable="myprogram.run"
myCommand="$myExecutable --mode install ";
myCommand+="--directory /path/to/mydir/ ";
myCommand+="--password 'my password' ";

This did NOT work:

# now run the command
$myCommand;

but this DID work:

# now run the command
eval $myCommand;

So, if you ever find yourself trying to figure out why your command isn't parsing correctly and pulling your hair out over it, try the "eval" command. I hope this helps someone and saves you the hours of frustration it would have saved me!!

I run Ubuntu 12.04 64-bit as my local Desktop OS. I've run the "SCP" command multiple times to multiple machines from my own PC when I'm moving files around, but for some reason when I tried to SCP, I got the following error:

dream@dream-C32A-H9:~/Downloads$ scp myfile.zip root@myserver.viviotech.net:/root
root@myserver.viviotech.net's password: 
bash: scp: command not found
lost connection

Okay... so that doesn't make any sense. I use SCP all the time. What is *really* going on here? To find out, I ran SCP in verbose mode, whcih you can do by adding the "-v" switch to your SCP command:

:::snip:::
debug1: Authentication succeeded (password).
Authenticated to myserver.viviotech.net ([255.255.255.255]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending command: scp -v -t -- /root
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Transferred: sent 2048, received 2104 bytes, in 0.0 seconds
Bytes per second: sent 60339.9, received 61989.9
debug1: Exit status 127
lost connection

Ah... see these two lines:

debug1: Sending command: scp -v -t -- /root
bash: scp: command not found

So, we see that it was the REMOTE server that's complaining about the "command not found". Well, that should be easy enough to fix. I SSH'd over to the remote server and I was going to install SCP on it but I couldn't remember what package SCP was in, so I looked for it using YUM (since the remote machine was a CentOS machine):

[root@myserver ~]# yum provides */scp
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.mirror.facebook.net
 * extras: ftp.osuosl.org
 * updates: mirrors.cat.pdx.edu
r1soft/filelists                                         |  14 kB     00:00     
updates/filelists_db                                     | 2.9 MB     00:01     
openssh-clients-5.3p1-81.el6.x86_64 : An open source SSH client applications
Repo        : base
Matched from:
Filename    : /usr/bin/scp

There we go. So the SCP command is provided by openssh-clients. I installed that by running the following:

yum -y install openssh-clients

Then I ran my SCP command again, and my file was uploaded without a hitch!

Hope this helps anyone else experiencing the same issues.

I've talked about this a lot in various places, but because I expect to get a few questions about this, I want to create a post where I could fully explain the decision to move from mod_jk to mod_proxy. As of Version 4 of the Railo Installer, mod_proxy_http will be configured by default in Linux Apache installations.

Current Installs Will Continue to Function

If you're comfortable using mod_jk, then there's no reason for you to migrate any of your existing installation to mod_proxy. mod_jk will continue to work just fine with Railo and Tomcat for as long as the Tomcat developer community continues to develop and improve mod_jk. There is no reason to switch if you're comfortable where you are.

Mod_proxy is Simpler to Configure

There are sevaral points to make within this overall "mod_proxy is simpler" point. First, it should be noted that mod_proxy is installed by default in nearly all modern Apache installs. Even Windows version. So as far as "installing" mod_proxy goes, it's incredibly easy because in most cases it's already there! Second, mod_proxy is configured purely by a few commands within the Apache configuration file. Mod_jk has several different configuration files you have to work with. These additional files are the cause for much confusion among users about what to edit, when to change it, and what to change it to in order to do what you want. Once you know the purpose of each file for mod_jk, it's really not very difficult, but it can be daunting to try to figure it out, or if you're on an unfamiliar system, find where those specific files are located. With mod_proxy, you can simply look at the proxy rules, and generally have a pretty good idea of what's going on without having to track down and review separate configuration files.

Mod_proxy is Recommended by Tomcat Dev Team

This article describes in detail the differences between the current connection methods: http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp

Note that the article was written by Mark Thomas, a member of the Apache Foundation and Tomcat Developer.

Mod_proxy Fits Better into Future of CFML

There are many features that would be very useful when connecting Apache to Tomcat with regards to the CFML development language. For example, it would be nice if users could have some built-in support for Search Engine Safe URL's without having to add complex mappings to their Apache configurations. It would also be nice to have the ability for Apache to pass on certain aspects of its configuration to Tomcat from within the HTTP protocol. Work in that area has started with the mod_cfml project, but it would be great if mod_cfml could run as a native Apache module instead of as a mod_perl module. Mod_perl is fantastic software, but some users resent having to install it in order to get mod_cfml working in Apache.

With mod_proxy, we can extend mod_proxy's existing functionality and add our own - in much the same way that mod_proxy_ajp and mod_proxy_html extend the base functionality of mod_proxy, we could potentially create a mod_cfml module that is simply an extension of mod_proxy where basic support for CFML pass-throughs are built in directly to the module. This would make installation and configuration even easier then it is currently.