I’ve been around the Internet since long before the “Dot-Com Bubble,” when we had to get our MP3s from IRC and use Blade’s Encoder for the command line. Slashdot was just starting up, ICQ was the only instant messenger around, and Winamp really did whip the Llama’s ass. Those were the days…or were they?

Some colleagues and I were contemplating what exactly “ruined” the Internet for each of us. Depending on the era we each signed on to the Internet, we had different ideas of what ruined it. Here are 2 of my own.

1. Inexpensive Domain Name Registrations and the introduction of ICANN

History
Prior to 1999, the only .com registrar was Network Solutions. It was $100 US for a domain. Fast forward to today and there are thousands of ICANN approved registrars (although mostly resellers) selling domains for $5-$10 on average. GoDaddy seems to hover between $6.95 and $9.95.

Why this ruined the Internet
With the arrival of inexpensive domains, it allowed spammers and phishers to setup numerous and ever-changing websites quickly and cheaply. ICANN enforces a 5-day refund policy for domain holders and registrars. What this means is that many people register domain names, use them for phishing, and dump them after 5 days with a refund. Below are two graphs showing the total domains and hostnames registered as of Sept. 2008. According to Verisign – 22% of the registered domains are “parked domains” and roughly 10% are inactive.

2. Pay-Per-Click

History
Advertising agencies in the 90s like Doubleclick, Flycast and Burst paid website owners one of two ways – cost per thousand impressions or pay-per-click. To get approved by almost any agency you needed to prove your impressions and have them audited. Rates were high compared to today’s rates, upwards of $5 per 1000, or $0.10-$0.15 per click. Adwords was started in 2000 and Adsense was purchased shortly thereafter.

Why this ruined the Internet
Adsense is the gold rush of the Internet. If you write a blog, you’ll make money. The promise of almost guaranteed inclusion into the Adsense network by anyone who can cash a check has launched millions of useless websites and parked domains. Because of Adsense’s low payouts, site owners have become increasingly creative in how they manipulate ad space. Duplicate content, misleading ad placement, pop-ups, and pay-per-post blogging (fake reviews) have all contributed to the decline of the Internet and search relevancy. Hundreds of millions of made-for-adsense pages litter search engine results.

Some of the ideas my colleagues came up with were: Flash, RSS, “Cheap” Servers, Frontpage, Marquee/Blink, and anyone with a Slashdot ID over 1,000,000 (ouch!).

References:

http://www.verisign.com/Resources/Naming_Services_Resources/Domain_Name_Industry_Brief/page_002689.html
http://www.verisign.com/static/040767.pdf
http://news.netcraft.com/archives/web_server_survey.html

(No Ratings Yet)

4 Comments |  Print This Post |

The Cisco ASA and PIX line of devices have three independent vulnerabilities that have been discovered and patched a few days ago. Just finished up with my own devices and nothing bad to report. Here’s a summary if you don’t wish to read the long-winded Cisco one.

1. Windows NT Domain Authentication Bypass Vulnerability.

Does not affect IPSec and SSL using external authentication VPN. Only NT domain authentication.

2. IPv6 Denial of Service Vulnerability.

Affects devices configured with IPv6 (by itself or in addition to IPv4). Does not affect devices running versions 7.0, 7.1, 8.0, or 8.1. Devices with versions 7.2(4)9 or 7.2(4)10 are affected only if IPv6 is enabled. It is disabled on all devices by default.

3. Crypto Accelerator Memory Leak Vulnerability.

Memory leak triggered by a series of packets. Only packets destined for device trigger it. The leak occurs in the initialization code of the crypto accelerator. ASA devices running version 8.0.x are vulnerable. ASA devices running versions 7.0, 7.1, 7.2 and all Cisco PIX devices are not affected.

Get more of the details and patches here.

(No Ratings Yet)

No Comments |  Print This Post |

I recently moved iishacks.com to a dedicated server at a datacentre in Texas. I set it up without defining host headers – something I’ve always done because of a 1-to-1 site-to-IP ratio.

The site has been running on the server for a little over a week and my logs are roughly 17 times the size they were on the old server. Maybe iishacks.com got slashdotted? No. I’d have to say something really bad about Linux for that to happen.

When you provision a server from any datacentre they give you a block of IPs from their address pool – often IPs that have been used (and abused) in the past.

As it turns out, “spam bots” were attempting to login and/or post comments to various default Wordpress, Moveable Type, vBulletin and phpBB pages on my IP address. The IP address had once belonged to another site which garnered attention from “spam bots.” Since my site was responding to any host header on the IP address (by default since there are no defined host header values in IIS), it was responding to all these requests. It takes up processor cycles, memory and most importantly bandwidth. It also messes up your logs too.

By adding Host Header values, even when you have a single website on an IP, you deny any malformed and spam requests to your domain (or previous domains pointing to that IP address), and your IP address itself. In the past, IIS6 using SSL and Host Headers would not get along – the SSL site had to be hosted on a different IP than the non-SSL site. Since Windows 2003 SP1 was released it is no longer a problem. So sites with SSL can specify host headers as well.

How to setup Host Headers (bindings) on IIS6

1. Open Internet Information Services (IIS) Manager.
2. Expand the left-hand menu under Server Name and “Web Sites.”
3. Right-click on the website you wish to add a Host Header to and select “Properties.”
4. Under the “Web Site” tab there will be a “Web Site Identification” header, click on “Advanced.”
5. Under “Multiple Identities for this web site” click “Add.”
6. Add “www. yoursite .com” where it says “Host Header Value.”
7. Add another value with the same port number and IP address without the “www.”

How to setup Host Headers (bindings) on IIS7

1. Open Internet Information Services (IIS) Manager.
2. Expand the left-hand menu under the Server Name and “Sites.”
3. Right-click on the website you wish to add a Host Header to and select “Bindings.”
4. There will be a default binding on Port 80 with the IP address specified. Highlight it and click “edit.” Add “www. yoursite .com” to the Host Name field.
5. Add another site binding without the “www” in the Host Name.
6. For SSL specify HTTPS under “type” and be sure to assign the correct certificate.

(average: 5.00 out of 5)

1 Comment |  Print This Post |

Below are the steps required to move a website hosted on IIS6 to IIS7 (Internet Information Services 6 to 7). IIS7 replaces the aging metabase with a more convenient applicationHost.config which stores the configuration in XML.

There are two versions of MS Deploy, the program needed to migrate. Download the 32bit version here, and the x64 version here.

Installing MS Deploy on the Source IIS6 Server

1. You must have .NET Framework 2.0 SP1 or 3.5 installed on the server.
2. Download the file and open it. Choose Setup Type: Typical. Be sure to use the x64 version if you have Windows 2003 x64. There is no entry in the Start Menu; you need to start the program through the command prompt. C:\Program Files\Microsoft Web Deploy\msdeploy followed by the command.

Installing MS Deploy on the Destination IIS7 Server

1. Same as above. Be sure to use the x64 version if you have Windows 2008 x64.

Create a Backup of the IIS7 configuration

It is important to create a backup of the IIS7 configuration before you start. You never know when you’ll make a mistake, and restoring IIS to the default configuration without a backup isn’t fun.

IIS7 comes with the appcmd.exe command line tool, which is new for IIS7, and simplifies configuration backups immensely. It is located in the %windir%\system32\inetsrv\ folder, which isn’t in the path variables, so you’ll need to navigate to that path with the command prompt first.

1. Click Start -> Run -> type “cmd” and press OK.
2. At the command prompt, navigate to the %windir%\system32\inetsrv\ folder. (type “cd \” and then “cd C:\Windows\system32\inetsrv” if windows is in the default path)
3. Once in the target directory, type: appcmd add backup “BackupPreMigrate”
4. Press Enter. All done.
5. To display a list of previous backups type: appcmd list backup
6. To restore a backup, type: appcmd restore backup “BackupPreMigrate”

Verify Dependencies on Source IIS6 Server

Below is a screenshot of all the variables supported by the migrate tool. All instructions below assume you are in the C:\Program Files\Microsoft Web Deploy\ directory at the command prompt.

1. At the command prompt (In the C:\Program Files\Microsoft Web Deploy\ directory), type:
   
   msdeploy –verb:getDependencies –source:metakey=lm/w3svc/#siteidentifier

The list that is returned is fairly comprehensive as to what components are installed and available for use on the particular website. It does not, however, distinguish which components are actually in use.

Installing Required Components on Destination IIS7 Server

From the dependency list you can determine which roles need to be installed on the destination IIS7 Server. Any dependencies listed in the XML file that is saved during the migration will need to be installed on the destination server or else the migration will not complete. You can remove dependencies beforehand or from within the XML file found in the backup directory after the sync command.

Migrate Website

• On the source IIS6 Server type:
  
  msdeploy -verb:sync  -source:metakey=lm/w3svc/# siteidentifier -dest:archivedir=c:\backup_name

Move the backup folder (c:\backup_name) to the destination server, or if on a network simply backup to the final destination on the IIS7 server or SAN.

• On the destination IIS7 Server type:
  
  msdeploy -verb:migrate -source:archivedir=c:\backup_name -dest:metakey=lm/w3svc/# siteidentifier

After Migration

After the migration is complete, some elements will need to be re-configured. PHP, ASP.NET Ajax and others will need to be configured independently of the IIS migration to match the source server’s settings.

(average: 5.00 out of 5)

8 Comments |  Print This Post |