I got my first snail-mail scam today. I won two round-trip airline tickets to anywhere in the United States!

The masterpiece arrived in a regular letter envelope and was addressed by hand. The regular first class self-stick stamp was postmarked in Phoenix, AZ

(Click on the pictures for full-size PDFs)

Inside, the document had a letterhead for 'US Airlines". I'm guessing this is to bank on the confusion between US Airways and American Airlines. The letter was addressed to me by name and was also signed by hand.

The letter reads as follows:

NOTE: You must respond no later than November 25th, 2011.

Dear Christopher,

I am pleased to inform you that you have qualified for an award of 2 roundtrip airline tickets. Congratulations. These tickets are valid for travel anywhere in the Continental U.S. from any major international airport. The retail value of this award is up to $1,400.00. Certain restrictions apply.

We have attempted contacting you several times without success. This is our last attempt. If we do not hear from you soon, we may need to issue the ticket vouchers to the alternate.

Please call me today at 1-866-351-2044

Regards,

 

Valerie Fay

Vice President

EO-20270

I'm sure anyone who reads my blog is smart enough to not fall for this anyway, but it was certainly an anomaly in my mail box.

UPDATE [11/19/2011]:

Commenter "Scmmer" did a little research and added:

I called the number.  Was transferred to a young sounding woman who essentially repeated everything in the letter then told me that its a new Travel Agency that is looking to build their business.  You have to visit their office located at 2002 N Lois Ave. in the Westwood Center.  Then she explianed that this was for married or cohabitating couples.  When I asked what the agency name was she pointed me to '"airfareanddealsdotcom".  Doing a quick google search turned up the IP address which turned up 4 entries on he BotScout website.

http://www.botscout.com/ipcheck.htm?ip=174.36.238.92

A Whois search shows they are out of Provo, Utah.

Thats about all I can find online but I am interested in seeing where this goes.

Today, several folks have tweeted & retweeted about an article written by "Adriano" at MyInfoSecJob.com. The original article may be read here: http://www.myinfosecjob.com/2011/08/6-reasons-why-you-should-not-work-with-information-security/

I'm not sure if the original post was meant to be funny or cynical. If it was, the intention did not translate very well into text.

I have been working as an infosec professional both in the public and private sector for over 10 years. I am by no means "seasoned" or an expert in anything. I've seen a lot of things, worked with a lot of people, and had my share of experiences both good and bad. I can't say that any of the points made in the original post ring true for me at any point in my career. I also think that the topics discussed can easily apply to anyone in any field of the service industry.

I will address each of the original topics one-by-one and provide my own commentary based on my experiences in the infosec field.

6. Working Long Hours, forever

I work hard every single day, and yes, sometimes I work extra hours. Things do go wrong. Security incidents do happen. This is why I have plans in place and teams on which I can rely. I go to sleep at night knowing my team and I have done the best job we could with the resources available to us. We have the detective controls in place to help ensure that if something does go wrong, we can quickly and efficiently respond to it. 

When I first started, I did work long hours. I did shift work on a 24/7 SOC watch floor. My shifts were 12 hours long, and often I would be back at work before the calendar flipped to the next day. Some might not like it, but I loved it. It allowed me to see everything and learn a whole lot. Having a good attitude early in my career is what allowed me to advance and not have to work long hours forever.

5. People Only Remember Of You When Things Go Wrong

If this is the culture you have bred, then I totally agree. Again, this goes back to attitude. You have a lot of control over how people remember you. Be a security catalyst. Be proactive. Build a culture in your organization where colleagues feel comfortable coming to you to ask questions before they do something or start a project. Help people. Save one group from audit-hell because you saw something and helped them do it the right way before a project went live. How will you be remembered then?

There's not a patch for everything, and you can never be 100% secure. You can however put forth your best effort by implementing good security programs and technology. Set management's expectations. Things will go wrong. Prepare your management so they judge you not on the fault, but rather on how well you respond to the fault. Many companies are in the news recently with breaches and other security issues. What's more interesting to follow… the actual breach, or how well (or bad) the company responded to it?

4. Study, Study and More Study

Why is this even part of the original post? The infosec field gives you an opportunity to continuously self-improve. Once again, it's about attitude. You could sit around, not read, not learn, not try for certifications or higher education. You'll be stuck doing the same thing every day, or worse, not having anything to do at all. 

My experience so far has been that companies are fairly generous when it comes to self improvement. Book reimbursement, on-site training, tuition assistance, certification vouchers are some of the perks I see. An uneducated you does no good for your company.

3. There Is A Limit For Growth To Your Career

Not true at all. Here I am again talking about attitude. Your career is not constrained to the company for which you work. Sometimes moving up means moving on. You probably can't do either if you're not doing point #4. The original post asks "What are your chances of becoming the CEO of the company you work for?" and "Now, let’s ask our CEO what sort of background he has." Do you really *want* to become the CEO of the company for which you work? Certainly not if you want to stay within the infosec field. Unless you work for a security company, the chances are probably pretty low that your CEO's background is in information security. If you *do* work for a security company and some day want to be the CEO, keep a good attitude and never stop learning. For the rest of us, finishing out your career as a CISO, CSO, CIO, or CTO is not too shabby either. Others are perfectly content staying in the weeds and remaining engineers. 

2. No Room For Mistakes

I don't know about you, but I make mistakes all the time. As a security professional (or just being a grownup for that matter), you have to make decisions and take responsibility for those decisions. There were only two months in my adult life when I didn't have to make any decisions. That was my Navy boot camp. Everything was decided for me.

Your attitude dictates how you deal with mistakes — made by you and others. The outcome of mistakes drive changes to your infosec program. You may never have considered something a possibility to defend against until someone in your environment did something wrong. Recognize the mistake. Adapt. Overcome. Adjust your security program to account for it. Everything bad that happens in this field is made possible due to someone's mistake. Patches correct programming mistakes. Baselines correct configuration mistakes.

1. People expect you to crack their exes Gmail passwords, wireless networks, and combination locks.

Really? This isn't 1995 anymore. I don't have much to say on this topic. Apart from skiddies on IRC, I can't say I've encountered this very much. I think it comes down to others' lack of understanding of what you do. Calmly explain what you do and they'll get bored and move on.

I guess you could say that the original post struck a nerve with me. My impression is that the author has a bad attitude and can't move up and hates his job. If the original post was meant to be satire, I was too thick to get it.

If you had a beefy Linux box with plenty of storage hanging on to your border router that can see all of your network’s ingress/egress traffic, what would you put on it? Why?

Let me know in the comments or via twitter!

I’m thinking some sort of netflow collector, maybe a layer 7 re-assembler. Full packet capture/logging perhaps?

I’m deviating from my SCAP posts a bit. I was looking at better ways to secure sites when I stumbled on this.

What is suPHP?

suPHP will execute php scripts as the user you specify. This enhances security by not running scripts as the web server user (nobody) or as root (really bad idea). So even if there is a vulnerable php script installed, it can at most execute with the permissions of the non-privileged user you choose for it to use.

How does it work?

PHP scripts are interpreted by suPHP and suPHP then calls the php interpreter as the specified user and interprets the scripts as that user.

Why am I writing this How-To?

I have found several guides that *almost* get it done, but then there are a few details that you have to go hunt for. Hopefully this guide is easy to use and can get you set up on the first try.

Installation and Configuration

First Steps

There is an suPHP package in the RPMForge repository. You will need this installed. Follow the guide on the CentOS Wiki: http://wiki.centos.org/AdditionalResources/Repositories/RPMForge
If you follow each step for CentOS 5, it will work. I guarantee it.

The RPMForge package you will need is called “mod_suphp” and as of this writing, here are the package details:
Name       : mod_suphp
Arch       : i386
Version    : 0.7.0
Release    : 1.el5.rf
Size       : 597 k
Repo       : rpmforge
Summary    : Apache module that enables running PHP scripts under different users

Install The Package

yum install mod_suphp

This will install a few configuration files:
/etc/suphp.conf – This is the configuration file for suPHP itself
/etc/httpd/conf.d/suphp.conf – This is the configuration file for the suPHP Apache module

Edit the suPHP Config file – /etc/suphp.conf

There are a few lines that need changd to make this work.

webserver_user=apache

Depending on what user you run your web server as, you may need to change this line.

x-httpd-php=php:/usr/bin/php

This line must be modified to put double quotes around the value. suPHP will not work without it. You must also change it to use the PHP commandline interpreter, php-cgi. It should look like this:

 x-httpd-php="php:/usr/bin/php-cgi"

x-suphp-cgi=execute:!self

The same applies with this line. Put double quotes around the value, so it looks like this:

x-suphp-cgi="execute:!self"

Edit the suPHP Apache Module Configuration File – /etc/httpd/conf.d/suphp.conf

This file loads the suPHP Apache module as well as sets global configuration for the module. On my server, different sites (VirtualHosts) on my server have files owned by different users. To allow each user/VirtualHost to run PHP as their user, we do not enable nor configure suPHP globally. To skip global configuration, I comment out every line in /etc/httpd/conf.d/suphp.conf except the LoadModule line.

Configuration of the suPHP module will be handled on a per-VirtualHost basis in the httpd.conf.

Edit the httpd config file to set up individual VirtualHosts – /etc/httpd/conf/httpd.conf

suPHP usage is defined per VirtualHost. An unchanged VirtualHost directive will still execute PHP, but as the web server user. You can change this so PHP will not execute at all unless it uses suPHP, but I don’t do that in my config.

Below is my unchanged VirtualHost directive for http://www.packetsense.net:

<VirtualHost *:80>

ServerName packetsense.net

ServerAlias www.packetsense.net

DocumentRoot /home/packetsense/www/

ScriptAlias /cgi-bin/ /home/packetsense/cgi-bin/

ScriptAlias /cgi-sys/ /home/packetsense/cgisys/

SetEnv PHPRC /home/packetsense/etc/

ErrorDocument 404 /404.html

php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fchris@packetsense.net"

ServerAdmin chris@packetsense.net

php_admin_flag allow_url_fopen off

</VirtualHost>

You may not have all those directives defined in your config, but that doesn’t really matter.
To set a VirtualHost to work with suPHP, you only need to add 4 lines.

suPHP_Engine on

suPHP_UserGroup username groupname

AddHandler x-httpd-php .php .php3 .php4 .php5

suPHP_AddHandler x-httpd-php

In my case, my files are owned by User: packetsense, and Group: packetsense.

My modified VirtualHost directive now looks like this:

<VirtualHost *:80>

ServerName packetsense.net

ServerAlias www.packetsense.net

DocumentRoot /home/packetsense/www/

suPHP_Engine on

suPHP_UserGroup packetsense packetsense

AddHandler x-httpd-php .php .php3 .php4 .php5

suPHP_AddHandler x-httpd-php

ScriptAlias /cgi-bin/ /home/packetsense/cgi-bin/

ScriptAlias /cgi-sys/ /home/packetsense/cgisys/

SetEnv PHPRC /home/packetsense/etc/

ErrorDocument 404 /404.html

php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fchris@packetsense.net"

ServerAdmin chris@packetsense.net

php_admin_flag allow_url_fopen off

</VirtualHost>

Finally: All that’s left is to restart the web server service.

Now: Test It

To see which user your PHP is running as, create a file in your web directory called whoami.php. Include this code:

<?php

echo "Output of the 'whoami' command:<br /><br />\n";

echo exec('/usr/bin/whoami');

?>

You should see something like this:
Output of the ‘whoami’ command:

packetsense

Common Problems

500 Internal Server Error

Check your /var/log/httpd/error_log. You might see something like this:

[Sun Oct 11 11:27:47 2009] [error] [client 72.185.236.25] SoftException in Application.cpp:249:
File "/home/packetsense/www/whoami.php" is writeable by group

[Sun Oct 11 11:27:47 2009] [error] [client 72.185.236.25] Premature end of script headers: whoami.php

In this case, just chmod 644 the file you’re working with. Alternatively, you can adjust the tolerance for file permissions by editing the /etc/suphp.conf file. Look at this section:

; Security options

allow_file_group_writeable=false

allow_file_others_writeable=false

allow_directory_group_writeable=false

allow_directory_others_writeable=false

Change them to true.

Another cause of the internal server error might be if you did not change the interpreter line in /etc/suphp.conf from:
x-httpd-php=”php:/usr/bin/php” to x-httpd-php=”php:/usr/bin/php-cgi”

Your PHP source code displays in the browser in Plain Text

Check your /etc/suphp.conf for proper quote marks and the php-cgi interpreter specified.

Problems with Sessions

If your scripts use PHP sessions, you may run into failures when PHP attempts to write to the /var/lib/php/session directory. By default, it is chmod 770, and owner is root, group is apache. I recommend adding your users to a phpsession group and then to chgrp the /var/lib/php/session directory to the phpsession group. I ran into this problem when trying to run PHPMyAdmin

Please let me know if this is helpful to you. Also, please leave any comments, corrections, or suggestions.