Planet SysAdmin

O'Reilly Sysadmin: Protect Your Database From Your Webapp

Thu, 24 Jul 2008 13:49:18 +0000

I’ve been seeing this SQL Server code running wild for the past few days:

DECLARE @T varchar(255), @C varchar(255);
DECLARE Table_Cursor CURSOR FOR
SELECT a.name, b.name
FROM sysobjects a, syscolumns b
WHERE a.id = b.id AND a.xtype = 'u' AND
(b.xtype = 99 OR
b.xtype = 35 OR
b.xtype = 231 OR
b.xtype = 167);
OPEN Table_Cursor;
FETCH NEXT FROM Table_Cursor INTO @T, @C;
WHILE (@@FETCH_STATUS = 0) BEGIN
EXEC(
'update [' + @T + '] set [' + @C + '] =
rtrim(convert(varchar,[' + @C + ']))+
''Explot JavaScript goes here'''
);
FETCH NEXT FROM Table_Cursor INTO @T, @C;
END;
CLOSE Table_Cursor;
DEALLOCATE Table_Cursor;

Actually, the insertion of this code into web servers happens from a DECLARE statement that encodes the entire payload in hexadecimal characters, which is then helpfully translated into exploit code by your own database server. In a way, your SQL Server database hacks itself.

It’s been around since January, but the payloads have been different. Either multiple people are using the exploit, or the exploits are modified on a per-hire basis and delivered through the same bot network. One hacker with a client hack pays some other hacker with a server hack, and they go to town. The process attacks hundreds of insecure websites, which in turn attacks thousands of client hosts.

The interesting thing is that this code doesn’t really have a catchy name like all of the other exploits. Server exploits never get much attention in the media compared to viruses that attack millions of workstations at once, like Nimda, Melissa, or others.

DBA1: “Hey, did you hear that one website got compromised by ‘Column Smasher’?”

DBA2: “No, I thought it was called ‘Lemon Pledge’.”

DBA1: “Why would a database exploit be called ‘Lemon Pledge’?”

DBA2: “Because it cleans everything from your tables.”

There have been a few reports of these attacks hitting Cold Fusion servers. Thanks to Google and the .cfm file extension, it isn’t too hard to find a Cold Fusion server out there. And if someone is using Cold Fusion, they’re probably just coding in CFML, which isn’t a very robust language.

Remember FormMail? Formmail was that horrible CGI script that everyone abused to send out spam. Well, it seems like people haven’t taken the hint. All that information passed from a web client to the server through a GET or POST method should be considered dangerous. Web page constraints, JavaScript/AJAX validators, and hidden form fields can’t protect your database. Depending on how your web forms and server applications are written, you’re allowing outside input from unknown sources to be inserted into the middle of your humble SQL statement. The most important firewall to protect your database is your server side application.

Here’s a few things you can do to protect your database from SQL injection attacks. Suggestions 1 through 3 range from low level sanitation to high level extreme SQL programming. Suggestion 4 is geared more towards administrative efforts for a Database Administrator to protect their system from a web developers badly programmed application.

1. Sanitize the input. Run regular expresison filters that will ideally work on a pattern of allowed characters, Accept only alphabetical characters and numerals, but strip everything else out.

2. Use SQL bind variables to contain web application input, after it’s been filtered.

3. Using stored procedures can give you the benefit of limiting what statements your web application can execute on the database server. Keep in mind that stored procedures are still pretty complex, and unless they’re coded properly, they may not add additional security from the application.

4. Block select privileges to the sysobjects and other system tables. And just because you’re not running SQL Server, don’t assume you’re in the clear. Check with your DB vendor to see specific instructions on how your server handles the Information Schema portion of the SQL-92 standard.

TechRepublic Network Administrator: Get to know the Cisco IOS Feature Navigator

Thu, 24 Jul 2008 13:00:35 +0000

David Davis tells you how the Cisco IOS Feature Navigator can help you find the information you need, including what features your current IOS image has, what the differences are between two IOS images, and whether your router can support the latest IOS.

——————————————————————————-

What is the Cisco Feature Navigator?

This recently improved Cisco IOS Feature Navigator is set up to easily research and display available features in a certain version of the IOS, in a certain hardware platform, or working backward from features to IOS.

As the name implies, the Feature Navigator allows you to navigate through some simple screens to retrieve information on your Cisco IOS, IOS XE, and CatOS software releases. This is a free tool and a great resource that can save a network admin a lot of time and frustration.

With the Feature Navigator, you can easily research your Cisco IOS software for compatibility with other images, research software releases, and search for a particular feature. It even gives you an option to display the details on any feature that you pick.

How can the Cisco IOS Feature Navigator help me?

We are going to look at five different scenarios to show you how the Feature Navigator can assist you in gaining additional information about your IOS.

Scenario 1: Display features for a particular IOS

Let’s see how easy it is to display features that are available for a particular image.

Click on Search by Software to get started. You should see a screen like Figure A:

Figure A

You can now pick and choose which options you want. For our example, we’ll pick the following:

Software: IOS
Platform: 4500
Image Name: c7200-js56i-mz.12.0-1
Product Number: SF105CW4-11.3.9

Click the Continue button when completed.

You’ll see a screen like Figure B.

Figure B

The screen displays all the features that are available for this IOS image. The display also shows you the Release and Product information for that image: No more looking through the release notes and trying to figure out what features are included in your IOS.

Scenario 2: Compare IOS and CatOS image features

Another helpful use is comparing IOS images to see what features are supported. That’s handy if you want to update an image on your router. Click on the compare images link. You should see Figure C.

Figure C

(By the way, you might notice that Help is listed right on the screen, so you can readily see what options are required and which is optional.) I have filled in the options for this example comparing Cisco CatOS image to IOS XE image. Figure D and Figure E show the results of that query.

Figure D

Figure E

As you can see, there are a lot of features that are unique to the Cisco IOS XE image. By clicking on each feature link, you can learn the details of that feature.

Now, let’s look at researching by Feature. You can click on the Search By Feature link from the first screen of the Navigator or click on the Search By Feature tab on subsequent screens. This search looks a little different than the others (Figure F).

Figure F

There are a lot of ways to research from this screen. You can search through all features and only add or remove what you are interested in obtaining in a single IOS. Once you select those features, you are told what hardware platform is required, what RAM, what Flash, and what IOS version. You are also given the option to sort these or filter these by, say, the mature and stable releases only.

Conclusion

The Cisco IOS Feature Navigator is an invaluable tool to use for researching anything and everything about Cisco IOS releases, images, and platforms. It can be used to answer questions like, what features does my IOS support, what is the difference between these two IOS versions, and what would be required for me to run the new IOS? You’ll save yourself a lot of time by creating a browser Favorite to the Cisco Feature Navigator.

To use this tool and learn more about it, visit the Cisco IOS Feature Navigator Web Site.

David Davis has worked in the IT industry for 15+ years and holds several certifications, including CCIE, CCNA, CCNP, MCSE, CISSP, VCP. He has authored hundreds of articles and numerous IT training videos. Today, David is the Director of Infrastructure at Train Signal.com. Train Signal, Inc. is the global leader in video training for IT Professionals and end users.

Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!

number 9: second place in the arms race

Thu, 24 Jul 2008 12:03:31 +0000

Came across this on my travels last night. Like your style, girl. Posted without further comment (it might give the game away).

A Year in the Life of a BSD Guru: Survey on Women in Technology

Thu, 24 Jul 2008 10:08:54 +0000

Temple University has a survey to assist in their research on women who have careers in technology-related fields, specifically with the goal of trying to create more responsible policies toward women workers, and improving the educational opportunities of those girls who aspire to careers in technology-related fields.

A Year in the Life of a BSD Guru: Survey on Security Certification

Thu, 24 Jul 2008 09:33:35 +0000

The Open Web Application Security Project (OWASP) is in the very starting stages of creating a certification exam for security professionals. If you're a security professional, take a moment to complete their survey to better understand the needs that OWASP certification can satisfy.

Russell Coker: SE Linux Policy Loading

Thu, 24 Jul 2008 07:21:10 +0000

One of the most significant tasks performed by a SE Linux system is loading the “policy“. The policy is the set of rules which determine what actions are permitted by each domain.

When I first started using SE Linux (in 2001) the kernel knew where to find the policy file and would just read the data from disk as soon as it had mounted the root filesystem. Doing such things is generally considered to be a bad idea, but it was an acceptable mechanism for an early release.

One issue is that the policy needs to be loaded very early in the system boot process, before anything significant happens. In the early days the design of SE Linux had no support for a process to change it’s security context other than by executing another process (similar to the way a non-root process in the Unix access control system can not change it’s UID, GID, or groups). Although later on support for this was added, it was only available as the request of the application (an external process could not change the context of an application without using ptrace - a concept that is too horrible to contemplate) and I am not aware of anyone actually using it. So it’s almost a requirement that there be no more than one active process in the system at the time that policy is loaded, therefore it must be init or something before init that loads the policy.

When it was decided that a user-space program had to instruct the kernel to load the policy we had to determine which program should do it and when it should be done, with the constraint that it had to be done early. The most obvious solution to this problem was to load the policy in the initramfs (or initrd as it was known at the time). One problem with this is that the initramfs is limited in size by kernel compilation options and may need to be recompiled to fit a bigger policy. As an experiment to work around this limitation I had a small policy (which covered the domains for init and the scripts needed for the early stages for system boot) loaded in the initramfs and then later in the boot process (some time after the root filesystem was mounted read/write) the full policy was loaded.

A more serious problem with including policy in the initramfs was that it required rebuilding the initramfs every time the policy changed in a significant way, of course scripts could not determine when a change was significant (neither could most users) so that required needless rebuilds (which wastes time). Even with a small policy for early booting loaded it was still sometimes necessary to change it and update the initramfs. I believe that as a general rule an initramfs should only be rebuilt when a new kernel is installed or when a radical change is made to the boot process (EG moving from single disk to software RAID, changing between AMD and Intel CPU architecture, changing SCSI controller, or anything else that would make the old initramfs not boot the machine). The initramfs that was used to boot my machine is known to actually work, the same can not be said for any new initramfs that I might generate.

But the deciding factor for me was support of machines that did not use an initramfs or initrd (such as the Cobalt machines [1] I own).

To solve these problems I first experimented with a wrapper for init. The idea was to divert the real init to another file name (or use the init= kernel command-line option) and then have the wrapper load the policy before running the real init. I never intended that to be a real solution, just to demonstrate a point. Once I had proven that it was possible to load the policy from user-space before running the real init program it was a small step to patch init to do this.

One slightly tricky aspect of this was in getting the correct security context for init. The policy has always been written to allow a domain transition from kernel_t to init_t when a file of type init_exec_t is executed. The domain kernel_t is applied to all active processes (including kernel threads) at the time the policy is loaded. So init only has to re-exec itself to get the correct context. Fortunately init is designed to do this in the case of an upgrade so this was easy to manage.

Since that time every implementation of SE Linux apart from some embedded systems has used init to load the policy.

The latest trend in Linux distributions seems to be using upstart [2] as a replacement for the old SysV Init. The Fedora developers decided to make nash (a program that comes from the mkinitrd source tree in Fedora and is a utility program for a Red Hat based initramfs) load the SE Linux policy as it would apparently be painful to patch every init to load the policy.

As far as I am aware there are only three different init programs in common use in Linux, the old SysV Init (which used to be used by everyone), Busybox (for rescuing broken systems and for embedded systems), and now Upstart (used by Ubuntu and Red Hat since Fedora 9). Embedded systems need to work differently to other systems in many ways (having the one Busybox program supply the equivalent to most coreutils in one binary is actually a small difference compared to the other things), and modifying the policy load process for embedded systems is trivial compared to all the other SE Linux work needed to get an embedded system working well. There are at least two commonly used initramfs systems (the Debian and Red Hat ones) and probably others. As one init system (SysV Init) already has SE Linux support it seems that only one needs to be patched to have complete coverage. I’ve just written a patch for Upstart (based on the version in Debian/Experimental) and sent it to an Ubuntu developer who’s interested in such things. I also volunteer to patch any other init system that is included in Debian (I am aware of minit and will patch it as soon as it’s description does not include “this package is experimental and not easy to install and use“).

It seems to me that repeating the work which was done for SysV Init and upstart for any other init system will be little effort, at worst no greater than patching an initramfs systems (and I’ll do it). As the number of initramfs systems that would need to be patched would exceed the number of init systems it seems that less work is involved in patching the init systems.

The amount of RAM required by the initramfs is in some situations a limitation on the use of a system, when I recently did some tests on swap performance by reducing the amount of RAM available to a Xen DomU [3] it was the initramfs that limited how small I could go. So adding extra code to the initramfs is not desired. While this will be a small amount of code in some situations (when I patched /sbin/init from Upstart it took an extra 64 bytes of disk space on AMD64), dragging in the libraries can take a moderate amount of space (the fact that an LVM or encrypted root filesystem causes SE Linux libraries to be included in the initramfs is something that I consider to be a bug and plan to fix).

Finally not all boot loaders support an initrd or initramfs. I believe that any decision which prevents using such sweet hardware as Cobalt Qube and Raq machines from being used with SE Linux is a mistake. I have both Qube and Raq machines running fine with Debian SE Linux and plan to continue making sure that Debian will support SE Linux on such hardware (and anything with similar features and limitations).

[1] http://en.wikipedia.org/wiki/Cobalt_Networks

[2] http://upstart.ubuntu.com/

[3] http://etbe.coker.com.au/2008/05/22/xen-and-swap/

Last in, First out: Are we Outrunning the Bear?

noreply@blogger.com (Michael Janke) — Thu, 24 Jul 2008 06:45:13 +0000

Or wasting our time trying?

Amrit's latest post has me thinking about what's been one of our brew pub round table topics lately.

There is an old joke about the hikers who cross paths with a grizzly bear. The first hiker immediately takes off his hiking boots and puts on his running shoes.

The second hiker: “why are you doing that - you can’t out run the bear”.

First hiker: “I don’t need to out run the bear, I only need to outrun you”.

In a sense, if hacking today is focused on profit rather than challenge or ego, as perhaps it once was, then the miscreants will likely follow the least cost or least resistance path to their goal (marketable data, marketable botnets). If that is true, our goal needs to be to outrun the other hikers, not the bear.

Fortunately there appears to be a limitless supply of slow hikers (clueless developers, sysadmins, security people and their leadership, or more likely - competent developers, sysadmins and security people led astray by clueless leadership).

We need to focus on out running them, not the bear.

Adnans Sysadmin/Dev Blog: Links for 2008-07-23 [del.icio.us]

Thu, 24 Jul 2008 05:00:00 +0000

Chris Siebenmann: One thing that I dislike about typical debuggers

Thu, 24 Jul 2008 04:51:48 +0000

One thing that I dislike about typical debuggers

One of the things that I hate about typical debuggers is that they want me to hold their hand all the time. Okay, this is not entirely fair; they default to having me hold their hand, and generally don't do a really good job of supporting hands-off operation.

This is not really their fault, because debuggers have a different view of how they're going to be used than I do. A classical debugger (like gdb) expects to be used by people who are carefully narrowing in on the bug, taking cautious step after cautious step, and for this of course you want to interact with the debugger all the time (because ultimately you are looking for an anomaly, which requires a human's eye).

I don't use debuggers that way. Instead, I use them to extract a bunch of information from the program which I will then stare at for a while, so I want to set things up (simply, please) and then fire off a run without further intervention. The last thing I want to do is to slow down the process by having to interact with the debugger all the time.

Modern debuggers sort of support this; you can write command sets for breakpoints and so on that automatically dump information and then continue. But my impression is that both the command language and the interface is awkward, and in practice when I've tried to use gdb for this sort of thing I've wound up getting lost in the complexity of managing all of the breakpoints and so on by hand. I would actually rather have a script-driven debugger where I had to edit a file and then reload it to change what I was monitoring, because that's easier to keep track of and to modify.

(Having to keep changing a file and reloading it would of course be intolerable for the step by step 'narrowing in' style of debugging, which is why I don't expect debuggers to support it any time soon.)

TechRepublic Servers and Storage: Windows Home Server Power Pack 1 sees the light of day

Thu, 24 Jul 2008 03:40:55 +0000

Windows Home Server was released in 2007 to much fanfare, but had a few significant limitations and quickly fell victim to a serious data corruption bug. This week, Microsoft released Power Pack 1, the first update to Windows Home Server. Scott Lowe explains some of the update’s features.

——————————————————————————————————————-

I love my HP MediaSmart home server, even though I’ve had a few problems. I bought it in late 2007 for a project I needed to complete and have found it to be a very useful tool–after I upgraded the RAM to 2GB from the 512MB that was shipped with the server. Windows Home Server isn’t without its flaws, though. Most seriously was the product’s data corruption bug that, well, corrupted data. Unfortunately, I fell victim to this bug before it was publicly disclosed as a problem. I learned the hard way that OneNote 2007 and Windows Home Server didn’t make a good combination. I’m convinced that this data corruption bug has really hurt Microsoft’s efforts to infiltrate the home market with Windows Home Server.

This week, Microsoft finally released to manufacturing the first major update for Windows Home Server. Dubbed Power Pack 1, this update introduces a number of enhancements to the server product, not the least of which is a fix for the aforementioned data corruption bug. Additionally, Power Pack 1 includes the following major updates:

64-bit Windows Vista support. I run Windows Vista x64 at home, so this is a very welcome addition to the software! I have other computers in the home running 32-bit operating systems, so all of Windows Home Server’s features worked quite well with them, but on my 64-bit system, I was not able to use things like the integrated backup feature. Of course, I was able to browse directly to the home server just as is possible with any Windows server, but it’s nice to see that 64-bit support is now real.
Remote access has been improved. One compelling feature of Windows Home Server is remote access. Home Server makes it easy to remotely connect to and download your files and folders as needed. Microsoft has made a number of improvements to remote access, including providing more granular remote access security permissions and making it possible to download files in batch by compressing them into either an exe or zip archive.
Backup of the home server itself. One benefit to running a server in the home with integrated client backup is that you are then protected against catastrophic client failure. In fact, Windows Home Server’s client rebuild capability is really, really good. I’ve tested a bare metal restore using virtual machines and the process really works. But, what happens if the home server itself fails? Windows Home Server RTM did not include backup capability, although third parties did rush to fill the void. I subscribe to KeepVault’s Windows Home Server backup service, which backs up my home server to KeepVault’s servers. With PP1, Microsoft has made it possible to back up the contents of a home server to an external hard drive which can then be taken off-site for safe storage.
Data corruption bug fix. Did I mention this one already? This fix is that important and, I believe, will allow Microsoft to continue their push into the home.

These are the highlights of Power Pack 1. These may not seem like major improvements, but they are! I haven’t listed every single little update–and there are dozens–but these major items make Windows Home Server a much more robust solution. A complete list of changes introduced in Power Pack 1 can be downloaded from here.

iDogg: Encrypting single files

Thu, 24 Jul 2008 00:41:04 +0000

I forgot a username/password for a website that I needed access to. I had to wait until I got home to dig up a hard copy that had my account# on it. That’s a pain in the butt. Opensuse 11 comes preloaded with gpg. Below is a link to a quick tutorial on how to use it to encrypt single files. I’m thinking I’m going to put my obscure usernames/passwords in a file, encrypt it with gpg, and be able to access it whenever I have a machine with gpg on it.

On the other hand though, putting anything private in electronic form is a risk. Anyone ever do this? What are your opinions? Drop me a message.

http://www.cyberciti.biz/tips/linux-how-to-encrypt-and-decrypt-files-with-a-password.html

The Daily ACK: OSCON: Wednesday Morning Keynote

noreply@blogger.com (Al.) — Thu, 24 Jul 2008 00:35:55 +0000

My jet lag caught up with me last night and I ended not making it to the Tuesday Night Extravaganza, although other people did and cruelly didn't blog Damian's talk for the rest of us that didn't. So I don't get to find anything more about "Temporally Quaquaversal Virtual Nanomachine Programming In Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces", which is a pity...

The keynote kicked off with Allison Randall and Edd Dumbill, talking about the history of Open Source and OSCON. This is the first OSCON without Nat at the helm, and while I've seen him around, it's pretty weird not to have the keynote kick off with "...and here's your conference chair, Nat Torkington".

Update: Looks like I'll see you all next year. While I was in the keynote I got a phone call and I'm now heading back into the UK somewhat earlier than planned.

The Daily ACK: OSCON 2008

noreply@blogger.com (Al.) — Thu, 24 Jul 2008 00:32:25 +0000

Day one of OSCON 2008 here in Portland, Oregon. In my current jet lagged state it was actually fairly easy to haul myself out of bed early enough to make it down to the convention centre and grab morning coffee before everything kicks off for the day. For my body at least its just coming up to four o'clock in the afternoon...

View Larger Map

This year I've decided to take my own advice and keep clear of the Perl track, at least for the tutorials. So this morning I'm going to "Python in Three Hours", then this afternoon I'm going to, erm, "Perl Security". Which is about as far as I could pull myself away from the Perl track for today. Tomorrow I'm off to "An Open Source Startup in Three Hours" and "Practical Erlang Programming".

As always, I'll be blogging things, taking pictures and this year probably twittering the odd comment or two. That's if the fail whale isn't sighted...

Update: Steve Holden talking about Python in Three Hours.

Update: Paul Fenwick talking about Perl Security.

Update: Gavin Doughtie and Andrew Hyde talking about An Open Source Startup in Three Hours.

Update: Bailed out of An Open Source Startup in Three Hours after coffee and into Damian Conway's talk on Perl Worst Practices.

Update: Francesco Cesarini talking about Practical Erlang Programming.

Update: With the tutorials over, the conference is kicking off properly with the Wednesday Morning Keynote.

Update: Looks like I'll see you all next year. While I was in the keynote I got a phone call and I'm now heading back into the UK somewhat earlier than planned.

the life of a sysadmin.: aaaaaaaaaaaand there it is

Wed, 23 Jul 2008 23:00:19 +0000

the life of a sysadmin.: Two random tips

Wed, 23 Jul 2008 17:45:15 +0000

When trying to change an Exchange password using Outlook Web Access at $UNIVERSITY, a user got "Error number: -2147024891". winerror.h describes this as a General access denied error. In the end, it turned out that when the account was created, the "user cannot change password" option was checked. Hope that'll help someone else's google-fu…
I had managed to miss this quick command-line check for Dan Fucking Kaminsky's DNS bug, aka CERT VU#800113. Just run:

dig +short porttest.dns-oarc.net TXT

and watch the skies.

Standalone Sysadmin: Excellent Linux Command: dmidecode

noreply@blogger.com (Matt) — Wed, 23 Jul 2008 16:41:30 +0000

I can't believe I didn't know about this command. I mean, it's so simple, but it reveals SO much information.

As root, run "dmidecode" and pipe it to the pager of your choice, like this:

root@newcastle:/home/bandman# dmidecode | more
# dmidecode 2.9
SMBIOS 2.3 present.
72 structures occupying 2461 bytes.
Table at 0x000F0450.
--snip--

If you scroll down just a little ways, you start getting better information:

BIOS Information
Vendor: Dell Inc.
Version: A09
Release Date: 06/22/2005
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 512 kB
Characteristics:

There's more:

Base Board Information
Manufacturer: Dell Inc.
Product Name: 0M3918
Version:
Serial Number: ..CN7082154I04CU.

Handle 0x0300, DMI type 3, 13 bytes
Chassis Information
Manufacturer: Dell Inc.
Type: Mini Tower
Lock: Not Present
Version: Not Specified
Serial Number: CPJLT71
Asset Tag:
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None

You have to look at it yourself to believe all the information it provides. Never again will I wonder what the model number on one of my servers is:

[root@a-fs2 ~]# dmidecode --type 1
# dmidecode 2.7
SMBIOS 2.4 present.

Handle 0x0100, DMI type 1, 27 bytes.
System Information
Manufacturer: Dell Inc.
Product Name: PowerEdge 1955
Version: Not Specified
Serial Number: JJN2LF1
UUID: 44454C4C-4A00-104E-8032-CAC04F4C4631
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified

Read the manpage on it. I'm going to get right on a script to go pick up the information from remote servers and present it in a meaningful way. That should be an excellent way to provide information for the wiki

[EDIT]

As Brandon mentioned in the comments, "hwinfo" is another neat command that doesn't get installed by default (at least on my Ubuntu/RedHat systems), but definitely seems worth the time to get.

The Lone Sysadmin: links for 2008-07-23

Wed, 23 Jul 2008 16:33:11 +0000

Howto: Check if a LUN is being locked by the host? » Yellow Bricks

This is very useful if you are running a number of ESX servers, clustered.

ShareThis

The Daily ACK: Perl on Google App Engine

noreply@blogger.com (Al.) — Wed, 23 Jul 2008 14:48:34 +0000

I woke up this morning to some of the best news I've heard in a while, it looks like there is some progress with putting Perl onto Google App Engine.

More from Brad Fitzpatrick. If you'd like to discuss this or help out, join the perl-appengine mailing list, and submit code to the appengine-perl project on Google Code. For more information see the Perl-on-AppEngine FAQ.

Maybe I won't have to learn Python after all...

The Lone Sysadmin: First Decent Shot With My D80

Wed, 23 Jul 2008 13:36:41 +0000

I just bought a Nikon D80. I’ve wanted a digital SLR for ages, and with the help of my good friend Jon I finally sucked it up and bought one. Now I just have to figure out how to use it. Which means that, for a while, I’m going to take a photo of everything I see.

Lesson here: autofocus doesn’t work very well on fires.

ShareThis

TechRepublic Network Administrator: SolutionBase: Does the Cisco Self-Defending Network really work?

Wed, 23 Jul 2008 13:00:29 +0000

David Davis explains why the Cisco Self-Defending Network might be the right choice for your company.

———————————————————————

If you’re a cynical consumer, the Cisco Self-Defending Network (CSDN) solution probably begs the sarcastic question: “Yeah, right; the network that can just defend itself?” However, as Cisco typically makes quality products and solutions, I can’t believe that the self-defending network concept is all bad; actually, it may even be the best solution on the market today.

Why look at security solutions in the first place?

Since every business today depends on the Internet and LAN networks for some business-critical function, the need for security is more important than ever. A company that does not have strong security can end up on the news as being hacked, their stock can plummet, and they can be out of business in no time. Once released, viruses and worms can hit businesses and consumers around the world in a matter of seconds or minutes.

However, you and your company don’t have unlimited funds; you can’t just put in every solution you discover. You have to weigh the level of investment in security with the level of risk that is perceived by your business. It’s tough to decide how much to invest and what solutions to choose, but you must ensure that your network is reasonably secure.

What is the Self-Defending Network?

The CSDN is a large complex roadmap made up of many Cisco components. You aren’t required to have all the components. CSDN does its job using all these different components. Examples of these components are Cisco NAC (admission control), Cisco Security Agent (endpoint protection), Cisco MARS (event correlation), Network Intrusion Detection System (NIDS), authentication servers, Anti-X systems like ASA and Ironport, network and host-based firewalls, and antivirus.

The theory of CSDN is that the network has the ability and the intelligence to protect itself from threats. However, this can only happen if the components of the network are working together to ensure this level of security, intelligence, and adaptability.

How do the components of the CSDN work together?

In Figure A, you can see how the components of the CSDN are all over the network. Every link, piece of hardware, and operating system is somehow secured by the CSDN. By covering all the bases, CSDN attempts to thwart security issues wherever they crop up in the network. In addition, the attempt of the CSDN is to provide end-to-end visibility of the network’s security events and status.

Figure A

Graphic courtesy of Cisco.

Network devices must work together and be integrated in order for the CSDN to do its job. Therefore, you probably aren’t going to have third-party network components on your network participate in the CSDN.

Besides hardware components, what else is involved in CDSN?

While you can buy all the network hardware components you like, software and services are also a huge part of CSDN. Just as with anything else, without the people (services), the hardware isn’t going to implement itself. Once the CSDN is implemented and the servicemen are gone, the network will still need to be monitored and maintained.

Cisco offers a lot of services revolving around the Self-Defending Network. Figure B illustrates these offerings:

Figure B

Graphic courtesy of Cisco.

As you can see, Cisco offers services beginning with planning the network and moving through designing, implementing, and operating the network. Later, Cisco can come back and optimize the implemented security systems.

While this all sounds great, I would caution anyone evaluating a security solution to determine how much time and effort will be required to implement and maintain that solution. Undoubtedly, the long-term maintenance of any security system is far greater than the original price tag.

How are credentials fundamental for network security?

When it comes to the implementation of the CSDN, user and device credentials are very important. The user and device credentials are used to identify that device and to authenticate the user.

In Figure C, you can see how the device identification is checked, then the operating system and application posture, and the user identity, based on username, password, and security certificate keys.

Figure C

Graphic courtesy of Cisco.

As you can see, user and device credentials are critical to the success of CSDN.

Where are the security standards in CSDN?

There are a number of standards at work in the CSDN roadmap. One of the most crucial technologies related to the CSDN is Network Admission Control (NAC). NAC is used to review device security posture before admisson to the network. In many cases, this is done with 802.1X; however, that is only part of what NAC does and how it works.

The battle between Cisco’s NAC and Microsoft’s new Network Access Protection (NAP) is about to heat up. Fortunately for consumers, both companies have agreed that there will be some compatibilities and interoperability between these two technologies. In the end, there are many standards at work in creating this self-defending network.

What is the future of CSDN?

A complex framework, CDSN has a goal for all of their devices to communicate together, preventing any danger to the network. The theory is that the devices will collaborate, with one device telling another that it is in danger. In my mind, the thought of many different hardware and software network security devices all working together sounds almost too good to be true.

However, devices still don’t easily integrate with other Cisco security devices, as they aren’t easy to implement and are typically expensive. Even though the CSDN framework has been around for over six years, there’s still a lot of work left to be done before networks can truly be self-defending.

This SolutionBase article was originally published in December 2007.

Standalone Sysadmin: More on Admin Responsiblity

noreply@blogger.com (Matt) — Wed, 23 Jul 2008 12:52:17 +0000

Since the drama is over, I suppose I can finally touch on San Francisco's recent network issues, namely a network admin holding the network devices "hostage". Sort of.

If you aren't familiar with the story, here's a brief rundown.

Network admin Terry Childs built the San Francisco FiberWAN, the backbone that municipal data travels on. To say he was an insanely-protective admin is an insult to the insanely-protective admin community. According to one report, he was so secretive that he refused to write configs to flash. Now THAT, my friends, is being too paranoid. In the end, the city tried to fire him, and he refused to hand over the authentication information, and he booby-trapped the network so that he could disable it and erase the config from outside if necessary. The mayor of San Francisco eventually talked him from his proverbial ledge and coaxed the passwords out of him, as apparently the mayor was the only man Childs trusted.

The end result was that San Francisco went a week and a half without having access to their WAN equipment. Now, I imagine the remaining admins are scouring every line of configuration trying to make sure that Terry didn't leave any other backdoors or vulnerabilities. I don't envy their job at all.

You've probably realized how this relates to people like us, who admin small networks by ourselves. The major mistake San Francisco made was placing one (apparently unstable) person in charge of the infrastructure with no oversight. That sounds almost like my job.

We're in this position by design. By being the only admin of a small infrastructure, we have a high bus factor. Unnecessary secrecy has no business on our networks. We touched on this last month, after MSNBC reported on IT worker ethics. Nothing has changed since then. Being prepared as an organization means guarding against employees who get hit by buses or turn evil.

TechRepublic IT Security: The security control nobody used…

Wed, 23 Jul 2008 11:00:16 +0000

Not every security control is successful, particularly those not transparent to business users. This is the story of a failed attempt to encrypt email and the lessons learned.

——————————————————————————————————————-

The Story

Once upon a time, a large enterprise decided it was time to encrypt sensitive information sent via email. They were regulated by both HIPAA and SOX, so getting executive management on board was no problem. The security team practiced due diligence, reviewing multiple offerings, speaking with Gartner analysts, and discussing technical challenges with engineering. (Security and engineering are hereafter referred to as the “technical team.”) The proposal was completed, submitted, and approved.

The solution implemented included the following:

Automatic outbound message encryption. Messages were encrypted when the content filtering engine, referencing HIPAA and PII lexicons, calculated a score greater than the threshold set.
Encrypted messages could be delivered to recipients as password-protected attachments. The solution also supported sending affected messages to an online mailbox in the enterprise data center, forwarding a notification to the recipient, and requiring the recipient to log in to the online mailbox to retrieve the message. Remote access was via SSL. However, senior management thought this was too much trouble for vendors, customers, etc. They directed the technical team to go the attachment route.
Manual encryption was possible by marking the message “confidential.”

There were other features as well, but they’re not important to our story.

The pilot began, involving IS personnel only. Everyone thought it was a great product, except too many messages were being encrypted. This was inconvenient for the recipients. So, the technical team adjusted the lexicon scores and the overall message score threshold, trying to balance security with convenience. By the time they were done, the scale had shifted to allowing quite a few messages that should have been encrypted to pass in plain text.

The pilot finished with IS satisfied this was the right solution. Training videos had been distributed to all email users, with accompanying quick-reference cards. All was ready. So on a bright, sunny morning, they flipped the switch. Everyone now had encrypted email, and the fun began.

The first wave of complaints came from executive management. It was too inconvenient working with their intended recipients, getting them to understand how to receive their email. Further, certain senior managers didn’t believe their email should be subject to auto-encryption. The technical team responded, turning off auto-encryption, leaving executives to decide whether or not to encrypt each message.

This was followed by an upswell of frustration across the enterprise, as users rebelled against the oppressive tyranny of auto-encryption. So, without management support for auto-protection, the technical team turned it off, relying on users to encrypt when they thought it necessary to protect sensitive information.

Several quiet months passed. Then one day the Legal department called. It seemed they hadn’t been using the encrypted mail system, and they were concerned about possible ePHI compromise. Further investigation by the technical team revealed the encrypted email attachment, the protected message, was being stripped by most receiving email systems. It couldn’t be scanned for malware. Go figure.

Checking with other departments, the technical team discovered that, with the exception of a few people in IS, no one was actually using the system. New employees didn’t know it existed, management didn’t enforce compliance, and many outside entities wouldn’t accept encrypted attachments. The end.

The Moral
This story has a lesson… well maybe more than one.

Piloting a security control not transparent to business users, that significantly affects the way they do work, should actually be tested by business users. Restricting testing of such a solution to IS personnel is a big mistake.
Management must fully understand the business impact and be willing to enforce use of the control. This means the technical team should help management understand how the solution works, from the users’ perspective, before purchase and implementation. Expecting executive enforcement of a solution that results in a series of unwanted surprises is unreasonable.

There were probably other mistakes made, but these two were enough to render the message encryption solution a failure, a control nobody used.

The Blog of Ben Rockwood: DTrace IP Provider... Oh no you didn't....

Wed, 23 Jul 2008 09:01:00 +0000

In my previous post about the IP Provider I got the following comment: "There is nothing unpleasant about the wonderfulness that is tcpdump! You’ll need to put a lot of work in to match tcpdump’s usefulness with Dtrace…"

That just sounds like a challenge. Bring it on! Can snoop or tcpdump do this?

root@ultra ~$ ./ip_whosent.d 
Packet sent to 192.168.100.4: 88 byte packet on behalf of ssh (PID: 1075)
Packet sent to 192.168.100.4: 88 byte packet on behalf of ssh (PID: 1075)
Packet sent to 208.67.222.222: 56 byte packet on behalf of nscd (PID: 152)
Packet sent to 208.67.222.222: 71 byte packet on behalf of nscd (PID: 152)
Packet sent to 208.67.222.222: 56 byte packet on behalf of nscd (PID: 152)
Packet sent to 72.14.207.99: 52 byte packet on behalf of firefox-bin (PID: 1944)
Packet sent to 8.12.32.9: 52 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 8.12.32.9: 54 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 8.12.32.9: 87 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 8.12.32.9: 58 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 8.12.32.9: 64 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 8.12.32.9: 65 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 208.67.219.230: 644 byte packet on behalf of firefox-bin (PID: 1944)
Packet sent to 208.67.219.230: 637 byte packet on behalf of firefox-bin (PID: 1944)
Packet sent to 72.14.207.99: 660 byte packet on behalf of firefox-bin (PID: 1944)
Packet sent to 208.67.219.230: 52 byte packet on behalf of firefox-bin (PID: 1944)
Packet sent to 208.67.219.230: 664 byte packet on behalf of firefox-bin (PID: 1944)
Packet sent to 8.12.32.9: 48 byte packet on behalf of thunderbird-bin (PID: 1133)
Packet sent to 72.14.207.99: 40 byte packet on behalf of firefox-bin (PID: 1944)
^C

Here is the script:

#!/usr/sbin/dtrace -qs 



ip:ip:*:send
/execname != "sched"/
{ 
        printf("Packet sent to %s: %d byte packet on behalf of %s (PID: %d)n", 
                        args[2]->ip_daddr, args[4]->ipv4_length, execname, pid ); 
}

Oh but wait....... how about a full call stack on each sent packet? Just add a new line to the above script: stack();

root@ultra ~$ ./ip_sentstack.d 
Packet sent to 72.14.207.99: 84 byte packet on behalf of ping (PID: 2020)

              ip`ip_wput_ire+0x21f5
              ip`ire_send+0x1c9
              ip`ire_add_then_send+0x2b9
              ip`ip_newroute+0xa0a
              ip`ip_output_options+0x18c7
              ip`icmp_wput+0x44a
              unix`putnext+0x22b
              genunix`strput+0x1ad
              genunix`kstrputmsg+0x261
              sockfs`sosend_dgram+0x26e
              sockfs`sotpi_sendmsg+0x4a8
              sockfs`sendit+0x160
              sockfs`sendto+0x8e
              sockfs`sendto32+0x2d
              unix`sys_syscall32+0x101

Or check out one of the examples on the IP Provider wiki page (this is almost certainly by Brendan Gregg):

# ./ipio.d
 CPU  DELTA(us)          SOURCE               DEST      INT  BYTES
   1     598913    10.1.100.123 ->   192.168.10.75  ip.tun0     68
   1         73   192.168.1.108 ->     192.168.5.1     nge0    140
   1      18325   192.168.1.108 -     192.168.5.1     nge0    140
   1         69    10.1.100.123 -   192.168.10.75  ip.tun0     68
   0     102921    10.1.100.123 ->   192.168.10.75  ip.tun0     20
   0         79   192.168.1.108 ->     192.168.5.1     nge0     92

Here is the script:

#!/usr/sbin/dtrace -s

#pragma D option quiet
#pragma D option switchrate=10hz

dtrace:::BEGIN
{
        printf(" %3s %10s %15s    %15s %8s %6sn", "CPU", "DELTA(us)",
            "SOURCE", "DEST", "INT", "BYTES");
        last = timestamp;
}

ip:::send
{
        this->elapsed = (timestamp - last) / 1000;
        printf(" %3d %10d %15s -> %15s %8s %6dn", cpu, this->elapsed,
            args[2]->ip_saddr, args[2]->ip_daddr, args[3]->ill_name,
            args[2]->ip_plength);
        last = timestamp;
}

ip:::receive
{
        this->elapsed = (timestamp - last) / 1000;
        printf(" %3d %10d %15s - %15s %8s %6dn", cpu, this->elapsed,
            args[2]->ip_daddr, args[2]->ip_saddr, args[3]->ill_name,
            args[2]->ip_plength);
        last = timestamp;
}

Can DTrace decrypt IPsec ESP payloads? No. Ok, so tcpdump isn't dead yet, but the capabilities offered by DTrace are far deeper. I've got a ton of ideas more that I could put here, but don't have time atm. DTrace for the win!

Adnans Sysadmin/Dev Blog: Links for 2008-07-22 [del.icio.us]

Wed, 23 Jul 2008 05:00:00 +0000

Lazy Linux: 10 essential tricks for admins

Chris Siebenmann: Retracting blog entries in the face of syndication feeds

Wed, 23 Jul 2008 04:58:23 +0000

Retracting blog entries in the face of syndication feeds

Suppose that you have accidentally published a blog entry that you really didn't want to and now want to retract, unpublish, disappear, or the synonym of your choice the entry. You could just delete the entry, but this has a problem: your syndication feeds (RSS, Atom, et al).

Specifically, removing an entry from your blog and thus your feed doesn't remove it for people who've already fetched a version of your feed that included the entry. Feed readers keep their own copy of entries that they've seen (up to whatever expiry limit the user has set) and no common feed reader will remove an entry just because it's disappeared from a feed, because entries disappear from feeds all the time (since a feed only contains the N most recent entries).

(Feed readers could be coded to notice that an entry is missing at the front or between two others, instead of at the end, but that would take extra effort. And as far as I know there is no marker in any of the syndication formats for 'remove this entry now'.)

If you are quite fast and very lucky, you can catch the mistake and remove the entry before anyone has pulled a version of your blog's syndication feeds that has the entry in it. But you are probably not that fast, especially if you are a popular blog and thus people are pulling your syndication feed all the time.

However, you can take advantage of another feed reader feature: if you change the contents of an entry, pretty much every feed reader will update their copy of the entry with the new contents. So instead of removing the retracted entry, replace its contents with 'this entry has been retracted' or the like. If there's other parts of the entry that need similar retraction (the title, for example), do the same thing with them.

(In theory you could update the entry to have an empty contents and title, but I think that 'this entry has been retracted' looks better to your readers and runs less risk of feed readers deciding that something clearly has gone wrong with your feed and thus they aren't going to update their copy.)

Ideally there would be a way of publishing an entry just in your feed, so your main blog pages don't have a 'this entry has been retracted' entry. I suspect most blog software doesn't support this, so what you can do is first update the retracted entry with the retraction notice, then wait a day or so for everyone's feed readers to pull this updated version, and then remove the entry entirely.

(2 comments.)

Tech at Play: RFID technology at work

Wed, 23 Jul 2008 03:52:37 +0000

If you’re pardon the title, but I figured that “RFID technology at play” just sounds weird here — never mind that I named the site Tech at Play in the first place. Anyway, what I wanted to say is that I went over to the resort island of Sentosa over the weekend.

The company running the resort island issued an entrance card that serves as an electronic tag for its automated gantries. The technology is obviously RFID, though the interesting thing here is that their RFID card is made from cardboard instead of plastic. To verify my theory, I successfully ripped the card into two-halves — at the end of the day of course.

Note the outline of the RFID antenna in the second photo. Apologies if you’re wondering about the view outside my window, which, since I live on the 24th level, is really nice.

My RFID reader is nicely mothballed into a nice storage box, so I didn’t feel inclined to rig it up this time. This is assuming compatible standards in the first place, which seems too much to ask for. Despite all the noise over RFID lately however, I very much doubt that any form of encryption or challenge-response mechanism is even used here.

Then again, it does not make much sense to forge a SG$3 (~US$2.20) ticket either, does it?

The Daily ACK: OSCON: Practical Erlang Programming

noreply@blogger.com (Al.) — Wed, 23 Jul 2008 02:31:31 +0000

This afternoon I'm sitting in "Practical Erlang Programming" given by Francesco Cesarini. Erlang has been around for almost twenty years, and is a niche language. However we're increasingly starting to hear more about it due to the growth in the number of multi-core machines. So I figured I so go and find out what all the fuss was about...

Update: I think Francesco has really overestimated the capacity of the wireless network, he's just told ninety people to download the source bundle and install Erlang.

Update: Okay, we're kicking off with data types; integers, floats, atoms are the simple types. Then we have tuples and lists. Interestingly variables in Erlang are single assignment, an values of variables can not be changed once it has been bound. Puzzled, variables are not very variable at that point?

1> A = 123.
123
2> A.
123
3> A = 124.
** exception error no match of right hand
4> f().
ok
5> A = 124.
124

Update: Pattern matching is used for assigning vales to variables, controlling the executing flow of programs and extracting values.

Update: Moving onto to function calls, this looks, well. Odd.

area( {square, Side} )      ->
  Side * Side ;
area( {circle, Radius } )   ->
  3.14 * Radius * Radius;
area( {triangle, A, B, C} ) ->
  S = ( A + B + C )/2,
  math:sqrt(S*(S-A)*(S-B)*(S-C));
area( Other ) ->
  {error, invalid_object}.

Function have clauses separated by ';'. Erlang programs consist of a collection of modules that contain functions that call each other. Function and modules names must be atoms.

factorial(0) -> 
  1;
factorial(N) ->
  N * factorial(N-1).

Variables are local to functions and allocated and deallocated automatically.

Update: Modules are stored in files with the .erl suffix, module and file names must be the same. Modules are names with the -module(Name). directive.

-module(demo).
-export([double/1]).

% Exporting the function double with arity 1

double(X) ->
  times(X, 2).

times( X, N ) ->
  X * N.

compiling this from the command line

1> cd("/Users/aa/").
2> c(demo).
{ok,demo}
3> demo:double(10).
20
4> demo:times(1,2)
**exception error: undefined function demo:times

Update: We've now looked at the basics, we're moving on to sequential Erlang; Conditionals, guards and recursion.

case lists:members(foo, List) of
  true -> ok;
  false -> {error, unknown}
end

In a conditional one branch must always succeed, you can put the '_' or an unbound variable in the last clause to ensure this happens.

if
  X  1 -> smaller;
  X > 1 -> greater ;
  X == 1 -> equal
end

Again, one branch must always succeed, by using true as the last guard you ensure that the last clause will always succeed should previous ones evaluate to false, see it as an 'else' clause. So we can have,

factorial(N) when N > 0 ->
   N * factorial( N - 1 );
factorial(0) -> 
   1.

instead of having this,

factorial(0) -> 
  1;
factorial(N) ->
  N * factorial(N-1).

Of these two the top one is the faster one, but you really shouldn't really worry about that when using Erlang, apparently...

All variables in guards have to be bound. If all guards have to succeed, use ',' to seperate them, if one has to succeed, use ';' to separate them. Guards have to be free of side effects.

Update: On to recursion,

average(X) -> sum(X) / len (X).

sum([H|T) -> H + sum(T);
sum([]) -> 0.

len([_|T]) -> 1 + len(T);
len([]) -> 0.

Note the pattern of recursion is the same in both cases. Taking a list and evaluating an element is a very common pattern...

Update: Now onto Build In Functions (BIFs)...

date()
time()
length(List)
size(Tuple)
atom_to_list(Atom)
list_to_tuple(List)
integer_to_list(234)
tuple_to_list(Tuple)

BIFs are by convention regarded as being in the erlang module. There are BIFs for process and port handling, object access and examination, meta programming, type conversion, etc.

Update: We're running through all the possible run time errors.

Update: We're breaking (late!) for coffee...

Update: ...and we're back, and walking through some examples, and onwards to concurrent Erlang.

Pid2 = spawn(Mod, Func, Args)

Before the spawn code is executed by Pid1, afterwards a new process Pid2 is created. The identified Pid2 is only known to Pid1. A process terminates abnormally when run-time error occurs, and normally when there is no more code to execute. Processes do not share data, and the only way to do so is using message passing. Sending a message will never fail, messages sent to non existing processes are thrown away. Received messages are stored in a process mailbox, and will receive them inside a receive clause,

recieve
  {resetn, Board } -> reset(Board);
  {shut_down, Board{ -> {error, unknown_msg}
end

Unlike a case block, receive suspends the process until a message which matches a case is received. Message passing is asynchronous, one of the things you look for in stress testing Erlang systems is running out of memory because of full mailboxes.

Update: We're getting into a static versus dynamic typing argument, the bizarreness is that even the Francesco seems to think that static typing is a good thing. Why is that? I'm really surprised, after all I'd argue that there are a bunch of reasons to use loosely typed languages in preference to statically typed ones.

Update: It's also interesting that some people in the audience here aren't getting the "let it crash" mantra coming from Francesco. In a highly concurrent language where everything is a process, letting a process crash is just how you handle errors. A process crash is essentially the same as throwing an exception.

Update: I'm starting to loose the thread of the talk now. Pity, Francesco has just got to the interesting bit. It's been a long day...

Update: ...and we're done. Chris was also blogging the tutorial so head over to his post for more coverage.

The Daily ACK: OSCON: Perl Worst Practices

noreply@blogger.com (Al.) — Wed, 23 Jul 2008 02:31:20 +0000

So after coffee I've bailed from "An Open Source Startup in Three Hours" into "Perl Worst Practices" with Damian Conway, squeezing myself into one of the few empty seats.

Damian is going through his SelfGOL code, and oh boy has he done some evil things with Perl...

You have to minimise wear and tear on all parts of the keyboard

Just like Chris I'm looking forward to the prospect of putting these worst practices into my own code when I return to my work next week.

Far too few people are using their source code as their user interface

Brad has been sitting in this one since the beginning, so if you're really interested in what Damian has been saying then just jump over to his blog post for the principles of worst practice...

The Daily ACK: OSCON: An Open Source Startup in Three Hours

noreply@blogger.com (Al.) — Wed, 23 Jul 2008 02:31:11 +0000

The second day of OSCON, and this morning I'm sitting in "An Open Source Startup in Three Hours" given by Gavin Doughtie and Andrew Hyde.

It's an odd choice for an academic like me, but considering the current funding crisis perhaps not as inexplicable as all that...

Update: The trick to running a successful company is to work half a day, work the first twelve hours or the second twelve hours it doesn't matter. It's not about getting rich quick, or about pyramids. Andrew is talking about his startup weekends...

Our company was built in 3 hours, the rest was marketing bullshit - Bill Gates

Amazing product are never built in a long time. Just short, simple acid trips - Steve Jobs

He's talking about deliverables and paper prototyping. Obviously they're not going to code it up, launch a project and get acquired by lunch time, but hopefully they're going to give us the tools to think about how to do that.

Update: Paper prototyping allows you to see things quickly, and avoid those six month mistakes and to fail really fast. Startups succeed with the right team and a solid idea. But it comes down to timing and luck and good design. But good designers are hard to find.

Update: A startup has to solve problems, but it has to solve more than just your problem. You need to float your idea to as many people as possible, and as smart as people as you can find. Unlike a lot of people Andrew is arguing that if people tell you your going to fail, either your pitching your idea wrong, or you're working on the wrong thing.

Update: What not to do; think your idea is worth anything, build anything that is "neat" or "cute", define development or design early on, or pick a domain. If you pick up a domain before you talk to people you probably haven't developed your idea well enough. You have to define your goals, build stuff, launch it quickly and see what people think.

Update: Define what your idea is and isn't, define the problem and outline your solution to it. Andrew is really hitting on paper prototyping you idea, design and interface. I'm pretty surprised, while I've never heard it called that before this is something I always do for a project, he's also hitting on what he's calling 'moleskinning' which seems to be the equivalent of the good old laboratory note book. You write down ideas, steps you've taken, that sort of thing. Maybe a rigorous science background is a good thing for a startup?

Update: Design is important, and a lot of people get it wrong. Go to someplace like CSS Beauty and find out what's hot and what's not.

Update: Over to Gavin and implementation. Things you need before launch; source control, a sever, some programming and you need to deploy something. You might want to think about a 'light engineering' process. The lightest engineering Gavin can think of is '1-click installs' and content based startups.

Update: He's now talking about Amazon EC2. If anyone is sitting in a startup tutorial and doesn't know about EC2 (and S3) then they're in trouble. He's walking us through building an EC2 image though, which is quite interesting. I've played with S3, but not EC2 in any depth. He's pointing out that you when you're doing development you don't have to keep the instances running, Amazon will charge you for those running instances, just shut them down. However when you do shut them down, or they crash, any data in the instance is gone, so you have to push it off to long term storage like S3.

Update: Lighter weight than EC2 is Google App Engine, which (as we all know?) is a sandbox Python runtime... and now we're getting a demo. App Engine is actually something I've started to play with as I managed to pick up an invite...

Update: He's pointed us towards opendesigns.org for (free) design templates, and encouraging us to put real design into your startup as soon as possible because it'll help you think about it more seriously.

Update: Gavin's talking about Django,

The Django guys will say 'Don't say it's like rails,' but it is like rails.

Which reminds me, I must take a serious look at Catalyst at some point...

Update: After fiddling around with CSS templates and Dojo, which looks pretty cool by the way, Gavin is back deploying his prototype App Engine project and showing how the group development stuff works...

Update: Back to talking about startups. What you don't need is; scalability, performance or industrial strength anything, unless of course that's what your startup is about. Technological pitfalls; Java, no local expertise and being overambitious. No really, he's telling us not to use Java. There is lots of complexity in Java land, and he really would recommend looking at the LAMP stacks.

Update: Even though it's really obvious stuff a simple application may have some technical depth to it. So don't be overambitious...

Update: Remember your team is your technology. Don't be afraid to have a single point of failure if that gives you leverage. Spend a bit of time looking for leverage in your technology.

Update: Marketing is a big thing. If you build it, they won't necessarily come...

Update: Andrew is back and talking about feature creep, which is the number two killer of startups, right after running out of money. You need a kerbside pitch, and an elevator pitch. A kerbside pitch is real fast, essentially "I work at etc company, which is like foo except for bar". Every one on the team should be able to do the elevator pitch, the longer (slightly more involved) pitch.

Update: Back to tools, pointing us at JumpBox which isn't something I'd run across before...

Update: Over to talking about legal stuff. You need to get everyone that you've ever talked to about the project, that has ever given any input to it, to sign bits of paper and state their intent.

If you can't make it good, at least make it look good - Bill Gates

Intellectual property has the shelf life of a banana - Bill Gates

...and software patents are evil if you don't have them!

Update: We're breaking for coffee, I think I'm going to jump out of this tutorial and try and slip into the second half of Damian's Perl Worst Practices after coffee. This stuff is interesting, but they're really talking about startups as websites, which while okay wasn't really what I was here for...

Update: Jumped over into Damian's talk.

The Daily ACK: OSCON: Perl Security

noreply@blogger.com (Al.) — Wed, 23 Jul 2008 02:30:58 +0000

This afternoon I'm breaking my no Perl rule and I'm sitting in "Perl Security" given by Paul Fenwick. I'm sitting next to Brad and Chris, and Sam is supposedly in here somewhere...

From the looks of things, Paul is trying to pull a Dick Hardt with his talk. If you've ever seen Dick's Identity 2.0 talk you'll know that this tutorial is going to be virtually un-bloggable...

Update: First pointer is to his own autodie module, which was released onto CPAN (very) late last night. It's a lexical equivalent of Fatal for Perl 5.10, it also upgrades the Fatal module to contain better diagnostics and reporting.

Update: Paul is talking about exposing vulnerabilities in CGI code, and trying to emphasize that you must validate your input data, from users, from files and very much from the network. You need to use taint mode. He's also recommending that you don't use "baby taint" mode and call Perl with -t...

You may not use data derived from outside your program to affect something else outside your program - at least, not by accident. - perlsec

Update: Interesting he's just shown a three line example that will allow you to get root access by running any Perl script that respects the PERL5LIB environment variable.

Update: But there are problems with taint mode

my ($url, $file) = @ARGV;
$url =~ m/ pattern match /;
my $safe_url - $1;
$file =~ / pattern match /;
my $safe_file = $1;

If the regular expression match for $safe_file fails then $safe_file is set to $safe_url and that could easily be set to something like http://foo&/bin/sh, which would be bad. You always need to check for success, either use an if( ) block or by explicitly check the return value from the regular expression.

Update: One of the things that Perl is good for is making tasks easy. One of those things is opening a file. There are lots of ways to open files in Perl, which means there are lots of way to break things. If you are opening a file you should always specify a mode, and never use the two argument version of open which does much deep magic. Use the three argument version instead.

open($fh, "", $filename );

However this doesn't get you out of validating your input, you still need to do that...

Update: Symbolic links (are awesome but) can be used to do evil things. Don't use temporary files with predictable names, you could even use anonymous files

use autodie qw(open);
open($fh, "+>", undef );

or you could just use the Tim's File::Temp module instead...

Update: Now talking about system and back ticks, Paul really hates system. You really need to use the two argument version of system rather than the one argument version, except of course

@args = ();
system( $cmd, @args );

if @args is empty, then it calls the one argument version of system, which in turn calls the shell rather than executes the passed command directly. Which means that you can this happens,

system ( "finger $username; rm -rf *", ( ) );

which is rather bad.

Back ticks are worse; "this" is a string, 'this' is a string and `this` is executing arbitrary code on your system. Depending on your font, it's rather hard to tell the difference.

The alternative is IPC::System::Simple, which works all the way back to Pelr 5.6 and (magically) doesn't have any dependencies. Which from the sounds of it goes a long way to fixing a lot of the problems with system. It also provides capture which replaces back ticks.

Update: We're breaking for afternoon coffee...

Update: ...and we're back and talking about setuid and setgid programs. Apparently Perl is ignorant of the saved uid, which means that it's really hard to drop privileges and make it stick. Also a dark secret, Perl's $< and $> variables are cached. Ouch!

Update: On to database security and injection attacks. He's advising us not to do our own quoting and use instead use place holders. As I've mentioned before, I rarely have to do heavy weight database work, and I'd view my knowledge of DBI as only fairly sparse, and even I know about place holders. Why does everyone think they're worth talking about at length. Bemusing!

Update: On to tricks and tips... and the poisoned null byte. Strings in Perl (are awesome but) can contain any character you want, including control codes and null bytes. In Perl a null byte is just another character, but in C it represents the end of a string. So if you can get a null byte down to the C layer, bad things can happen, and it's easy to pass a null byte can be easily passed in URLs.

Update: ...and we're done (with the main material) about an hour ahead of time. The course notes, although not the slides, for the tutorial are available online. On to the 'bonus' material, random numbers and cryptography...

Update: ...we're done. Now go read Brad's and Chris' posts on the Perl Security tutorial as well.