Saturday, April 26, 2008

This blog is usually about technology, but this is a threat to all the good things that have come out of Western society's belief in free speech and freedom from oppression without which, nothing I talk about here would be possible:

Monday, April 21, 2008

The Net Neutrality Debate

It's been a while since I've posted. I have been working hard on my senior design project and my honors thesis, and I will have lots of new Perl tidbits as well as a few Java code pieces (mainly having to do with XML-RPC or eXtensible Markup Language - Remote Procedure Call) to blog about here pretty soon. In light of the Thursday (April 17) on-campus debate that Stanford held the other day, to which the ISPs failed to even show up, I wanted to write a bit. The Electronic Frontier Foundation has some good insite into why programmers and application developers like Net Neutrality. Stanford's Larry Downes has some good points from the opponents of Net Neutrality that make a lot of sense. In particular, he doesn't like the idea of government regulation in the private sector (particularly on a technical topic that few politicians can comprehend) that could lead to negative consequences and the law being interpreted in ways not imagined when it is put in place. He even makes what I think is probably a generally true assesment:

Privacy concerns aside, my guess is that many people who are in favor of net neutrality also think of themselves generally as libertarians, at least when it comes to the idea of government entities micromanaging information technology and its applications, especially the Internet

He also doesn't feel that the FCC has the capacity to regulate the ISPs, which is probably true.

I have drafted up an 8-page proposal on Internet Neutrality that I will post on here in some way when I have completed it. I fall into the libertarian category that Downes refers to, and I don't want to have legislation that will prevent the ISPs from operating their business effectively; however, we do need to keep them honest. I believe that a very limited form of government interference is necessary to keep the Internet functioning as consumers have come to expect it. This legislation would not have to in any way regulate the ISPs into an inflexible business model, nor would it require the FCC to monitor the ISPs. It would, however require that we enact law that legally defines the term "Internet access" as access to a 100% neutral network that will indiscriminately route information from and to any host that is also connected to the Internet. This along with some other non-government actions such as getting the word out on the benefits of a neutral Internet will be sufficient to allow market forces to shoot down a non-neutral Net. ISPs may freely offer whatever type of network they wish and discriminate all they wish; they simply can't call access to those networks "Internet access". If consumers know that they aren't on a free and open network, and they do have access to another truely free network, they would surely choose the open network. This may also require further miniciple goverment action to use tax dollars to build up Internet infrastructure so that consumers will have a choice of a free network when only 1 or 2 disciminatory ISPs offer service in their area, but once the infrastructure is in place, it could even be sold to private ISPs for management in the agreement that it remain a neutral network.

Thursday, April 10, 2008

A note on getting iwlwifi drivers to work on Ubuntu 7.10 Gutsy

Okay. Big thanks to Jun for getting me started on getting rid of my buggy ipw3945 driver that started crashing on me out of nowhere and installing the iwlwifi drivers to support my Intel 3945 wireless card. I am very appreciative of his helpful walk-through, however, I ran into several hitches along the way, so to save myself, and anyone else who may encounter the problem considerable time in the future, I am making a note of it. As an aside, I have my Dell Inspiron 1420 laptop dual booting into Backtrack, and I have previously gone through the installation of the iwlwifi drivers to get my card to do injection on that distro.

From Jun's blog:

1. Download the linux-ubuntu-modules source package

sudo apt-get source linux-ubuntu-modules-`uname -r`

2. Edit the iwlwifi download script to fetch the latest drivers from http://www.intellinuxwireless.org
cd linux-ubuntu-modules-2.6.22-2.6.22/ubuntu/wireless/iwlwifi
edit the BOM script file, set the correct versions and fix the firmware move, here is my diff:

@@ -4,10 +4,10 @@
# only need to do this when you are updating from one version
# if iwlwifi to the next.
#
-IVER=1.1.0
-MVER=10.0.0
-FW3945_VER=2.14.4
-FW4965_VER=4.44.17
+IVER=1.2.23
+MVER=10.0.4
+FW3945_VER=2.14.1.5
+FW4965_VER=4.44.1.20

if [ ! -f iwlwifi-${IVER}.tgz ] ; then wget http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-${IVER}.tgz; fi
if [ ! -f mac80211-${MVER}.tgz ] ; then wget http://intellinuxwireless.org/mac80211/downloads/mac80211-${MVER}.tgz; fi
@@ -24,13 +24,13 @@
# Note the '-1' in the new firmware file name.
#
tar xzf iwlwifi-3945-ucode-${FW3945_VER}.tgz
-mv iwlwifi-3945-ucode-${FW3945_VER}/iwlwifi-3945.ucode ../../../ubuntu-firmware/iwlwifi/iwlwifi-3945-1.ucode
+mv iwlwifi-3945-ucode-${FW3945_VER}/iwlwifi-3945-1.ucode ../../../ubuntu-firmware/iwlwifi/iwlwifi-3945-1.ucode
rm -rf iwlwifi-3945-ucode-${FW3945_VER}

#
# Note the '-1' in the new firmware file name.
#
tar xzf iwlwifi-4965-ucode-${FW4965_VER}.tgz
-mv iwlwifi-4965-ucode-${FW4965_VER}/iwlwifi-4965.ucode ../../../ubuntu-firmware/iwlwifi/iwlwifi-4965-1.ucode
+mv iwlwifi-4965-ucode-${FW4965_VER}/iwlwifi-4965-1.ucode ../../../ubuntu-firmware/iwlwifi/iwlwifi-4965-1.ucode
rm -rf iwlwifi-4965-ucode-${FW4965_VER}

3. Run the update script so it will fetch and patch the files.

./MUNGE

4. Rebuild the linux-unbuntu-modules, then reinstall the package.

fakeroot debian/rules binary-modules-generic
dpkg -i ../linux-ubuntu-modules-2.6.22-14-generic_2.6.22-14.37_i386.deb


Now my wireless is working flawlessly.

Not so easy for me.

First off when running the debian/rules you have to make sure you are in the top level directory "linux-ubuntu-modules-2.6.22-2.6.22/". This is probably obvious to some, and trivial, but it did trip me up so I am including it. (Also sudo before running "./MUNGE").

Next, I ran into a hiccup after the modules compiled when it tried to run a "dh_testdir". A quick google of the name, and I found that I needed to install the debhelper package which I remember from something else I did a while back is essential for building debian packages. I installed with

sudo apt-get install debhelper


and re-ran the debian/rules binary-modules-generic. This time, it created the .deb package smoothly (and it did not have to recompile all the modules).

The install of the deb package went fine as well, but then I ran into more problems.

1) You have to blacklist your ipw3945 drivers in /etc/modprobe.d/blacklist to keep it from starting every boot.
2) You need to add iwl3945 to /etc/modules so that it inserts the module on boot
3) To get rid of the funky crap you see when runing ifconfig (like eth1 showing up as Link encap: UNSPEC, and having the wlan0_ren as an additional interface) you need to open up /etc/udev/rules.d/70-persistent-net.rules and delete the two lines for the old interface using the ipw3945 driver. Mine looked like:
# PCI device 0x8086:0x4227 (ipw3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:02:4c:12:12",NAME="eth1
(Except for the mac address =P )

4) Unload and reload you iwl3945 module like:

sudo rmmod iwl3945
sudo modprobe iwl3945


Now you should have a new entry in your 70-persistent-net.rules file like:

# PCI device 0x8086:0x4222 (iwl3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:13:02:4c:12:12", ATTRS{type}=="1", NAME="wlan0"
And an ifconfig will show no more eth1 interface, but a wlan0, which should show up with the correct mac address. You will also have an additional entry called wmaster0, but this is normal. It is the same way for my Backtrack installation using the iwl3945 drivers. I have now spent quite a bit of time writing this as since I got the drivers working and I haven't had any problems. The ipw3945 drivers surely would have crashed by now, and I would have had to reboot.

Additional links I used in this process:

http://ubuntuforums.org/showthread.php?t=579742
http://wiki.debian.org/iwlwifi#head-c9ab967d827d9e5de52656b78edab5f349bc70f6

Performance Enhancing Drugs

Athletes aren't the only ones doing it. A WebMD article covers a poll by the Nature magazine whos readers are mostly scientists says that 1 in 5 of the 1400 responders admitted to using cognitive enhancing drugs to boost mental performance. Drugs included were Ritalin, Provigil, and Inderal. I've never tried any of those, but I have taken an Aderall before to gear me up for 12+ hours of working chemistry problems to prepare for a final. The only side affect I didn't like was that it made me clench my jaw hard the whole time I was zoned in. It didn't seem like the same affect as coffee gives; it lulls you into an almost zombie-like and passive state, yet extremly focused at the same time. Not as jumpy or alert as coffee. It actually made working chemistry problems fun, in the sense that I was not at all easily distracted or uninterested, so I was super-productive.

Caffeine from very strong coffee, is all I really need.

Pwning the Power Grid

It's been common knowledge in the security arena for some time that our power grids have been vulnerable to attack. This article definitively proves it. The reason these SCADA systems have become so vulnerable is because they were not originally designed to be networked to the internet. If you are networked to a machine that is connected to the internet through a gateway, then you are also accessable from the internet. The number one culprit in this attack, as in most others, was a social engineering attack. Well, that, and vulnerable software that hadn't been upgraded. Specifically, a phishing email was sent that directed employees of the power company to a website that exploited a vulnerability to install some malware on their machine. From that point, the pen testers had full access to SCADA. "We had to shut down within hours," Winkler says, "because it was working too well. We more than proved that they were royally screwed."

We might be royally screwed if we don't pay attention to this, and some Islamic extremists exploit the vulnerability. This brings up a good point however, the penetration testers' highlighting of the problem is very important. Note, that it does not alert terrorists to the fact that they can do this; you can be sure they have thought about it. What this does is get the rest of us aware of our vulnerability so we can start to take steps to correct the situation.

1) Train employees to not open up bogus emails, or at least check the headers to see if it was actually sent from where it claims it is from, and also check out any url for links before clicking them. Just be suspicious (paranoid) and smart.

2) It might also help to disallow Javascript, java applets, or other forms of client side browser controllers. They could have used an exploit in flash or some other browser plugin. That information is not included in the article, probably for safety reasons.

3) Make sure software is up-to-date on security patches.

Wednesday, April 9, 2008

SELinux

I found this article through Bruce Schneier's blog. He asks, "So, do you trust it or not?" implying that perhaps the NSA has put some sort of backdoors into the distro, or perhaps included some flavor of encryption algorithm to which they possess a master key. Schneier has covered topics like this before on the NSA's "recommended" encryption algorithm.

Sunday, April 6, 2008

Getting Programs to Run Automatically when Slackware Starts

I have recently cannibalized my old Linux server that was running Ubuntu Linux on a P3 933MHz machine and moved some of the parts over to a new machine with dual 800MHz P3 processors. I made the switch because my old machine just started acting weird, and got to where I could not even boot from a CD-ROM. I backed up all my files, bit the bullet, and got to work. I decided to install Slackware Linux on my new box. This was the first Linux distribution I ever used, and it is one that will teach you the most, because it does the least for you. Slackware is a hard core, roll-up-your-sleeves-and-get-down-to-the-nitty-gritty-details distribution of Linux, with the added benefit of being very stable and very fast, even on limited older hardware.

After setting up sshd server for remote login, I naturally wanted to harden it against attacks. A quick check of my logs after just 2 days of going live revealed that a host in Plano, Texas had already been attempting some basic dictionary attacks against my sshd server. They were just trying the usual bullshit, attempting to log in on names such as "user", "admin", "webmaster", and other typical names that no one with security in mind would ever actually set up on their server. The IP address of the offender is: 67.64.222.74, and a "whois" on www.dnsstuff.com will reveal that it is an IP address from Plano. A little more research told me that this IP belonged to Beaulieu Marketing Inc, so it is probably just a compromised box that they don't even realize has been hijacked.

Moving on, there is a great script out there written in Python by Phil Schwartz that scans your sshd log file for failed login attempts to your machine. You can configure it in different ways to ban the IP address of hosts that try to log in on different users. For instance, I have my denyhosts configuration file set up to ban immediately any user who attempts to log in on root (the superuser/administrator) and fails 1 time (this is a moot point anyway, as I disallow remote root login from my sshd config file). If they try to log in on an invalid user name, they only get 3 tries before they are banned. If it is a valid user name, then 10 tries. The script can be configured to run as often as you want in the background, e.g. every 10 minutes.

Another great program that I needed to get up and running is one called inadyn, which allows you to update you IP address with DynDNS service whenever it changes, so you can have a DNS name (e.g. google.com, telegraph.co.uk, etc) even when you don't pay your ISP for a static IP address. It will work behind a NAT router as well because it pings you from the outside. This is also a program that runs in the background and will connect to the DynDNS service and cause it to ping you from the outside , and if your IP address has changed and is different from what DynDNS has stored, it will update it in their system. This means that I can always access my home Linux server by using a dnsname like http://www.yourservername.com/ instead of having to remember my IP address whenever I leave my house. Plus, your IP address could change between the time you leave your house and try to access your server remotely leaving you SOL.

So, these two programs are great, but I needed to have them run automatically on boot, so I would not have manually restart them every time I reboot. Slackware uses a different system of starting programs and services at boot, than I was used to from Ubuntu. In Ubuntu, you simply make a symbolic link to the executable file you want to run in /etc/init.d/ with the appropriate prefix to dictate the order the programs are run at startup. Slackware, however, uses a BSD like system of rc.d, and this requires one to write shell scripts (#!/bin/sh NOT #!/bin/bash) to start your program up.

The execution chain starts with inittab still, so you have to make sure that, after you create your scripts in the /etc/rc.d directory, there is some chain of execution that eventually causes them to execute. And DO NOT add "exit 0" at the end of your scripts, as this will cause anything executed after them not to run because it closes the shell. Also the scripts must be made executable and must be owned by root:

$>chmod +x rc.inadyn
$>chown root rc.inadyn


and

$>chmod +x rc.denyhosts
$>chown root rc.denyhosts


These are the shell scripts I created:
rc.inadyn
**********************************
#!/bin/sh

case "$1" in
'start')
/usr/bin/inadyn
;;
'stop')
pkill inadyn
;;
'reload''restart')
$0 stop
$0 start
;;
*)
echo "Usage: $0 startstoprestartreload"
exit 1
esac

*********************************
rc.denyhosts
*********************************
#!/bin/sh

case "$1" in
'start')
/usr/share/denyhosts/daemon-control start
;;
'stop')
/usr/share/denyhosts/daemon-control stop
;;
'reload''restart')
/usr/share/denyhosts/daemon-control restart
;;
'status')
/usr/share/denyhosts/daemon-control status
;;
'debug')
/usr/share/denyhosts/daemon-control debug
;;
'condrestart')
/usr/share/denyhosts/daemon-control condrestart
;;
*)
echo "Usage: $0 startstoprestartreloadstatusdebugcondrestart"
exit 1
esac

*****************************

The following, I added to /etc/rc.M file which is run by init when multiuser mode starts:

# Start denyhosts.py to start scanning /var/log/messages
if [ -x /etc/rc.d/rc.denyhosts ]; then
echo "Starting Denyhosts daemon"
. /etc/rc.d/rc.denyhosts start
fi

# Start inadyn to update DynDNS
if [ -x /etc/rc.d/rc.inadyn ]; then
echo "Starting inadyn daemon"
. /etc/rc.d/rc.inadyn start
fi

Saturday, April 5, 2008

Deep Packet Inspection - An Assault on Individual Privacy and on the Purity of Internet Protocol

Here is a Washington Post article on deep packet inspection, a practice by which ISP's will actually open up internet protocol packets as they traverse the ISP's network and look inside at the data portion of the packet. You can think of internet protocol packets as wrappers, with metadata information, that tell internet routers where to carry the data that is inside the packet that is actually used by end applications such as a web browser or email client. An analogy that is often made is that the data portion of the packet is like a letter and the metadata wrapper is like an envelope. Deep packet inspection, then, is equivalent to the mail carrier opening up your envelope and reading your letter. The purpose of ISP's using this technology now is for targeted advertising. This is not so bad by itself, especially as it seems from the article that the companies providing the DPI take great pains to not actually include any personally identifying information. And it seems that they do allow a customer to opt out of the DPI, although it is stated that most customers don't even know that this is happening because the information is burried in a 27 page sign-up agreement with the ISP.

"Each company allows users to opt out of the monitoring, though that permission is buried in customer service documents. The opt-out systems work by planting a 'cookie,' or a small file left on a user's computer. Each uses a cookie created by NebuAd."

The main problem I have with this is that it can and will eventually be used for giving priority to certain packets based on what is inside them. I have a problem with this, because for one, the protocols that make up the internet were designed in a tiered manner, where each tier is designed to function completely independently of any layers that are on top of it and that depend on it. Internet Protocol is layer 3 and deep packet inspection is peeking at layer 5, or the application layer: also the highest layer. Tier 3 is just designed to get the packets where they need to go. It does not care what is inside them. Deep packet inspection blurs the well-defined line between the layers and pollutes a pristine protocol that was designed in a tiered manner for very good reasons. Upper layer protocols can rely on the lower layer protocols to do their jobs correctly every time. They do not need to implement or even understand all the complexity and details of having it function correctly. This functionality is abstracted and the higher levels trust the lower levels to "just work," and therefore, the higher levels can be much more productive because the wheel doesn't need to be reinvented for every application. The writer of a letter does not need to know exactly how his letter is transported from source to destination. The writer just trusts the mail system. Also, as any programmer (or anyone who has ever had to solve a problem) knows, abstraction of details into discreet and separate components helps in debugging and troubleshooting problems because the exact location of an error or problem can be much more effectively isolated than when everything is just garbled together in an unintelligable mass. It just makes it harder to deal with!

Secondly, deep packet inspection is evil because it threatens Net Neutraility
in a big way. Eventually, if not already in practice, ISP's will start giving lower priority to internet traffic based on content. They will slow down the packets transporting internet game data, torrent data, and possibly even any type of traffic that is negative toward, cable, if you use cable, or satellite, if you use satellite.

The point is, do you really want your ISP spying onto you by reading your traffic? I would suggest that everyone call their ISP and find out if they use deep packet inspection techniques, and if so, find out how you can opt out of this discraceful privacy infringing practice.

Thursday, April 3, 2008

TSA

This is ridiculous. I don't know about the rest of the world, but it really doesn't make me any less stressed out in an airport to know I am being carefully scrutinized by Behavior Detection Officers. What would happen if I fart in the middle of a crowd and start looking around nervously to see if my chemical release has been detected by the cute airplane screener lady? Will the Behavior Detection Officers notice this shifty behavior and arrest me?

An Analogy or a Metaphor

I am currently in my senior year of my undergraduate curriculum and I have been taking a substantial load this semester. I am developing a project for my Senior Design class, one for Honors Thesis, and another for AI (I will possibly post on these at a later date). In addition to these senior level courses, I am also taking a freshmen level course. That's right, I did something I will not recommend to anyone entering college: put off freshmen English courses until the last minute. I often think of a metaphor to describe my current course load.

"I am ascending a large hill at the apex of which is my goal: graduation and my BS in computer science. My honors thesis is a heavy backpack full of books. It would not be hard trying to climb this hill with only the backpack. But alas, I also have my Artificial Intelligence project which is a large duffle bag I am carrying under one arm. This slows my progress slightly, but it is not a journey-ending hindrance. Then my Senior Design project is a large ball and chain straight out of a Bugs Bunny episode clamped firmly around my right foot, and I am just dragging that son-of-a-bitch with all my might. Now I am still creeping up the hill, making it one inch at a time. On top of all this, my English course is this really fucking small dog that keeps running up and biting the shit out of my left Achilles tendon. This would just be an annoyance, but with all the weight I am carrying up the hill, it is threatening to topple me over."

Moral of the metaphor:

Don't put off your freshman English courses, boys and girls. I am not intending to imply that these courses are unimportant; simply that it is not an ideal situation to be taking a class that, while not necessarily difficult, requires substantial outside time to invest in writing papers, etc. This is time taken away from working on projects. It seems like every time I turn around, I have another assignment in English.

Regular Languages

This will be a blog containing my thoughts on programming techniques, languages, and projects, as well as my random thoughts on science of all kinds (mainly physics of the really small and really big). I will cover some aspects of information security, as I am very interested in the subject. I may also cover politics from time to time as it relates to my other interests. I will probably also post current events that I am experiencing and feel like writing about at any given time.

The reason for the title is that I will express myself in a regular fashion, much like a regular language. For any who don't know what a regular language is, it is a language that can be accepted by a DFA, an NFA (as in my display name), or an e-NFA. It is also a language that can be expressed by a regular expression or generated by a regular grammar. That is as far as I am prepared to go into that subject at this time. Wikipedia is great if you want to learn more. I often find myself recursively searching wikipedia; digging down into tangential subjects before coming back to the original thing I was reading.