As some of you may already know, I launched a new business recently: https://vpnout.com. It is an anonymous VPN service that can break through firewalls and keep your data and IP address private. The feedback I’ve gotten so far has been extremely positive so I’ve decided to unleash it to the world at large.

We’re currently having some issues with Mac OS X so if you’re a Mac user and want to help me out, I’d be happy to give you free service if you’re willing to do some troubleshooting.

Please have a look and let me know what you think!

There’s an article at Treehugger that points to a recent presentation by Matthew Simmons (a member of the National Petroleum Council) regarding Peak Oil. Essentially he outlines the insanely dangerous situation we’re currently mired in, how we’re about to be seriously screwed regardless of what we do, and what businesses will suffer the most as a result (i.e. who not to invest in).

I read the entire presentation and I would sum it up the same way Treehugger did, “Everything you wanted to know about Peak Oil”. It is far more thorough and to-the-point than the Wikipedia page and if you thought I had some scary things to say about it then you need to read it and see what the most powerful investment bankers in the world were just informed of. If I were an investment banker that attended this presentation I’d be investing in bunker right now.

My prediction: The U.S. will get its first taste of what Peak Oil is like in August of this year with the oil flow resuming by the end of September. The real Peak Oil apocalypse will hit on the 4th of July, 2008 (a long weekend).

This morning I read that the House is considering a bill to make price gouging on gasoline a federal crime. It made me wonder if Congress knows that is not going to fix the problem or if they’re intentionally showboating. Then there’s the conspiracy theorist in me thinking, “I wonder if the oil and gas lobbying groups suggested it to them as a misdirection campaign?”

Just about everyone knows (now) that gas is expensive “because oil inventories are down.” It has been repeated in the news over & over. But what does that really mean? Is it really a simple problem of supply and demand?

The problem is the rate of consumption. Imagine a bucket being filled with water at the same time as water is being pumped out. As long as you pump out at the same rate as you’re filling the bucket everything is fine. If the rate of water going into the bucket is reduced while the amount you’re pumping out stays flat you’ll run out of water. How long it takes to run out of water in the bucket depends on the size of the bucket and the rate you pump it out.

U.S. gasoline inventories are that bucket and it isn’t a very big one. In a good week we have 10 days worth of gas waiting to be sold. Starting about March, gas inventories dropped every week to a low of about 8.8 days worth of gas (see this). Last week inventories started going up again so the price of gas might go down but then again, it might not because Memorial Day weekend is coming up and that means a lot of gas is about to be burned.

When oil inventories start dropping again and there isn’t an excuse like, “we had a fire at a major refinery” or, “it was a long weekend” you can be rest assured that the U.S. is entering what I’m calling, “the permanent oil crisis.” We may already be in a permanent crisis if you consider that the smallest little disruption causes oil speculators to jump and gas prices to skyrocket.

So the question remains: Will Congress ever work to solve the problem or will they just wait until the U.S. economy is destroyed by it? Don’t say “the market will solve the problem” because the “problem” is an externality outside of the control of the market. Does a shipping line wait until oil prices drop before they ship things? Do you decide to not drive to work because gas prices are high? Does the power company decide not to meet demand because oil prices went up? No. When the rate at which we can obtain and refine oil falls below demand it will already be too late for the market to adjust.

We need to forcibly diversify the U.S. energy portfolio now. Which would you rather have: An economy that suffers for a few years while we invest in alternative energy (particularly infrastructure) or an economy that is suddenly destroyed as a result of inaction? By doing nothing our government will ruin us. The market cannot correct itself without a catastrophe. No one in our present government at any level can say, “no one saw this coming.”

I recently wrote a custom script that works in conjunction with psad (Port Scan Attack Detector) to pop up a transient message on my screen when my machine is attacked. It looks like this:

So when some machine out on the network does a port scan or attacks/probes my laptop it alerts me in an unobtrusive manner with the pertinent details. The script also uses the espeak text-to-speech engine to say, “We’re under attack!” when such an attack occurs. It is pretty fun, actually.

Click the title to see the HOWTO.

< !-more->

Prerequisites:

• psad must be installed. On Ubuntu, “sudo apt-get install psad” should do (Here’s my config if you want).
• iptables logging must be turned on (see this).
• You must be running KDE (or at least have the dcop daemon running).
• sudo must be configured so that you can run the commands in my script as root without a password.
• You need my script

• Optional: Install espeak for a silly voice announcing that you’re under attack. On Ubuntu, “sudo apt-get install espeak” should do.
  

  Edit my script

  My script will probably run just fine without any modification. However, if your psad log directory is configured to something other than ”/var/log/psad” then you’ll need to edit my script and change the PSAD_LOG_PATH variable to match your environment.

  Configure psad

  psad has a straightforward configuration file that is typically located at /etc/psad/psad.conf. I edited my psad.conf so that it only alerts on “danger level 3” or higher and told it not to bother actually emailing out alerts (though, it still generates the email_alert files). However, the important part is near the end of the file: You must set the following options (telling it to run my script):

  ENABLE_EXT_SCRIPT_EXEC Y;
EXTERNAL_SCRIPT /home/riskable/bin/psad.sh SRCIP;

  Important: Make sure that EXTERNAL_SCRIPT includes the actual path to psad.sh.

  Next you need to setup your syslog daemon to log kern.info messages to the psadfifo file. If you’re using ksyslogd (i.e. Ubuntu) you can type the following:

  echo "kern.info |/var/lib/psad/psadfifo" >> /etc/syslog.conf

  Now restart psad (sudo /etc/init.d/psad restart).

  Configure sudo

  Make sure that you can run grep and sed as root using sudo without having to enter your password. If you don’t know how to do this, add the following line to the bottom of /etc/sudoers:

  
your_user ALL=(ALL) NOPASSWD: /bin/grep, /bin/sed


  Just make sure you replace “your_user” with your actual username and you should be all set.

  Testing

  A quick way to test psad is to nmap yourself from another host (I think it ignores localhost by default). If your machine’s IP was 192.168.0.2, from another machine run, “nmap 192.168.0.2” and you should get an alert within a few seconds. If not, something is wrong (obviously). Here’s how to troubleshoot:

  If psad is working properly, you should see a folder representing the IP address you were attacked from in /var/log/psad (i.e. ”/var/log/psad/192.168.0.1/”). Within this folder should be a file (or two) that end in _email_alert. These are the files that my script uses to gather information. If they don’t exist you probably have one of two problems:

  1. psad isn’t configured properly. Check the logs and your config file.

1. iptables logging isn’t enabled (did you run these two commands as root?)

   If you “cat whateverIP_email_alert” and see that it contains a legitimate alert then you probably have psad configured properly but double-check that the path to psad.sh is correct and that it is executable (i.e. “chmod 775 psad.sh”). If your iptables are setup properly you should see the following if you run the command, “sudo iptables -L”:

   Chain INPUT (policy ACCEPT)
   target     prot opt source               destination
   LOG        0    --  anywhere             anywhere            LOG level warning
   
   Chain FORWARD (policy ACCEPT)
   target     prot opt source               destination
   LOG        0    --  anywhere             anywhere            LOG level warning
   
   

   You can test the psad.sh directly by running it as root and passing it the IP address of one of the folders in /var/log/psad. For example:

   /path/to/psad.sh 192.168.0.1

   That should generate an alert. If it doesn’t, either dcop isn’t working properly or the _email_alert file isn’t interesting enough for my script to bother reporting (single port probes are ignored unless they match a signature). Time for some good old fashioned debugging at this point (hint: try running the script like so: “sh -x psad.sh 192.168.0.1”).

   Please leave a comment or trackback if you’re using this script. Enjoy!