Archive for April, 2006

Hard correctness, dorks, like totally

Thursday, April 27th, 2006

So, I read this article.

A startup funded by the U.S. government’s Defense Advanced Research Projects Agency is ready to emerge from stealth mode with hardware and software-based technologies to fight the rapid spread of malicious rootkits.

The company’s Copilot prototype is a high-assurance PCI card capable of monitoring the host’s memory and file system at the hardware level. It is specifically geared toward high-security servers and computers.

I remember talking with a person that worked on building hardware that verified the correct operation of hardware running firmware/software. There was additional hardware that checked the verifying hardware’s operation, which was a loop that could have gone on forever, but that was as far as they went. The design and implementation of this system involved formal modeling and generation of a finite state machine that was the size of a large encyclopedia, from which a picture of what correctness meant in this system was built.

Trusted hardware really is the only way to verify the correct operation of an IT system with any high degree of assurance (software is way too squishy), but, of course, there has to be an understanding of just what correct means in order to check correctness, which is what the work by the people discussed in this article seems to be exploring in terms of rootkits and how they subvert systems. Data forensics (briefing summaries) is a hardware world now as well.

Komoku’s long-term plan is to have both the hardware and software versions collect forensic data when a compromise is detected. Butler said both products are able to capture hidden malware in memory and send it back to a central management station when the products are running in enterprise mode.

Anyway, I wonder how these will fair against a Rutkowska. Oh, and the whole assurance thing comes to mind.

via this post to the Funsec mailing list

(Someone else posted “Remember Thunderbyte?” – I didn’t, but the web did.)

-

This person pointed me to an article on dorkbot at CNN.

NEW YORK (AP) — About 200 people crammed into a sleek SoHo art gallery on a recent weekday night, sitting on chairs, on radiators and on the floor. Others jammed the entrance to catch a glimpse of the unusual presentation unfolding on a projection screen in front of them.

Cool beans. My write-ups on a couple of dorkbot-nyc meetings can be found here and here. The meetings I attended were full of strange and interesting projects, packed with friendly people, and just a plain old good time.

-

For some reason, “OMG, like totally!” popped into my head when I read this.

Richard needed to dig through the code to see how to decrypt bank account numbers stored in the database. The search led him to H88493247329(), the method responsible for encrypting customer data. After spending a minute to add linebreaks and rename the variables, Richard asked his coworker why he obfuscated the code. His coworker scoffed, you should always encrypt your encryption functions — it’s completely insecure otherwise

Phish survey paper

Tuesday, April 25th, 2006

So, this paper was pointed out on the cryptography mailing list.

This paper provides the first empirical evidence about which malicious strategies are successful at deceiving general users. We first analyzed a large set of captured phishing attacks and developed a set of hypotheses about why these strategies might work. We then assessed these hypotheses with a usability study in which 22 participants were shown 20 web sites and asked to determine which ones were fraudulent. We found that 23% of the participants did not look at browser-based cues such as the address bar, status bar and the security indicators, leading to incorrect choices 40% of the time.

A shorter summary of this paper – our small survey says the majority of people out there can be fooled into trusting a web site based on visual cues (i.e., the site looked real). Anyway, it is a quick, good read.

From the paper,

Many users do not understand security indicators. For example, many users do not know that a closed padlock icon in the browser indicates that the page they are viewing was delivered securely by SSL.
[...]
Attackers can also exploit users’ lack of understanding of the verification process for SSL certificates. Most users do not know how to check SSL certificates in the browser or understand the information presented in a certificate.

I said something along those lines from my own experiences in this post,

In fact, most people have no idea what warning dialogs with relation to SSL/TLS negotiations or digital certificates mean, and, in many cases, they are false alarms anyway. So, virtually everyone has grown accustomed to just clicking through such warning dialogs. Worse yet, many times there are no warning dialogs, and only checking the certificate information everytime you negotiate a SSL/TLS session to see if it looks valid will help (Does the Common Name match the domain you were trying to reach? Does the Oragnization look appropriate? What about the Issuer information?).[...]

Which reminds me of this Schneier post I just read about Windows Vista and security warning dialog boxes,

The problem with lots of warning dialog boxes is that they don’t provide security. Users stop reading them. They think of them as annoyances, as an extra click required to get a feature to work. Clicking through gets embedded into muscle memory, and when it actually matters the user won’t even realize it.

Warning dialog boxes are only effective if the user has the ability to make intelligent decisions about the warnings. If the user cannot do that, they’re just annoyances. And they’re annoyances that don’t improve security.

Also from the paper,

One participant actually submitted her username and password to some websites in order to verify if it was a site at which she had an account. She stated that this is a strategy that she has used reliably in practice to determine site authenticity. Her reasoning was “What’s the harm? Passwords are not dangerous to give out, like financial information is”.

I commented that “Authentication information needs to hold the same importance to people as the keys to their homes or safety deposit boxes, and be just as easy to use” here, and I discussed passwords here. But, this reminded of one thing I failed to say – authentication mechanisms need to be of an appropriate type and strength to meet the security requirements of the system in which they will be employed (e.g., from the FIPS 140 world, do we need no authentication, role-based authentication, or identity-based authentication to meet our security requirements?), and the users of those authentication mechanisms will subsequently make choices about just how important their authentication information really is to them (e.g., revealing a password to a free account at the nytimes.com is not the same as revealing a password for an account loaded with cash at paypal.com). (I know a couple of people that always use roughly the same username and simple password on all those web sites that require registration for free access to their services, like online newspapers, but actually vary usernames and choose strong passwords for sites that provide services they deem sensitive, like online banking.)

Oh, and I mentioned using bookmarks as a simple way to help reduce phishing risks here, which I excerpt below.

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided – instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

via this post to the cryptography mailing list.

Geolocation ‘n TOR, silent patches, pennies

Monday, April 24th, 2006

So, this overview paper is making the rounds.

We begin with a state-of-the-art survey of IP geolocation techniques and limitations, and examine the specific problems of (1) approximating a physical location from an IP address; and (2) approximating the physical location of an end client requesting content from a web server. In contrast to previous work, we consider also an adversarial model: a knowledgeable adversary seeking to evade geolocation. Our survey serves as the basis from which we examine tactics useful for evasion/circumvention. The adversarial model leads us to also consider the difficulty of (3) extracting the IP address of an end client visiting a server.

The packet timing portion of this paper reminded me of a bunch of papers on location in ad hoc and/or sensor networks (that I chunked through recently), which took estimates of distance or angle, based on signal strength, time of arrival, angle of arrival, etc., between nodes with a known location and the node with an unknown location and combined them, based on tri-lateration, triangulation, etc., to calculate the geographic location of the node with unknown location.

For example,

    Let’s say A, B, and C are nodes of known location.
    Let’s say D is a node of unknown location.
    Let’s say a signal can travel between any two nodes at a speed of 10 feet per second.
    Let’s say we can measure how much time it takes for a signal to travel between any two nodes in seconds.

    In order to figure out the location of D, we first take time measurements of the signal traveling between A and D, B and D, and C and D. During our measurements, we discover it takes 3 seconds for that signal to travel between A and D, 4 seconds between B and D, and 6 seconds between C and D.

    Since we know that a signal can travel between two nodes at a speed of 10 feet per second, we can take these time measurements and compute how far A, B, and C are from D by mutiplying the speed (feet per second) by the time (seconds). So, the distance between A and D is 3 seconds multipled by 10 feet per second = 30 feet, the distance between B and D is (4 seconds * 10 feet per second =) 40 feet, and the distance between C and D is (6 seconds * 10 feet per second =) 60 feet.

    With our distance estimates done, we can now calculate the location of D using tri-lateration.

    We know where A is located and we know that A is 30 feet away from D, although we do not know in which direction – so, we can draw a circle around A with a radius of 30 feet and know that D has to be located at some point on that circle. We do the same for B by drawing a circle 40 feet in radius around it and for C by drawing a circle 60 feet in radius around it.

    The point where these three circles intersect is the location of D, as depicted in the following diagram (note: the diagram is just a quick sketch and not at all to scale).

    Simple Tri-Lateration Example

Back from that tangent, I noticed the following in the paper.

While proxies complicate the task of geolocating end-users, they do not necessarily preclude this. Here we
present a new method for extracting an end-user IP address even for end-users protected by Tor/Privoxy.

Suppose a Tor user downloads a web page containing a Java applet. The applet is permitted to open a network connection back to the server which originated it,15 e.g., by the Java code:

	int tcp_port = 80;
	Socket S = new Socket(getCodeBase().getHost(), tcp_port);

This connection is administered by the JRE, which by default should inherit any proxy settings from the browser (i.e., localhost:9050). However, Internet Explorer (IE 6.0 with SP1 running onWindows XP) – and possibly other browsers (but not Firefox, in our tests) – seem unable to communicate these preferences to the JRE. With such a browser, a Tor user’s real IP address is reported to the server by the code above. While this issue of proxy settings not being passed to the JRE is not widely known, it has been noted by some Tor enthusiasts.16

15This is allowed by the Java applet security model; see http://java.sun.com/sfaq/
16For example, see http://uk.geocities.com/osin1941/exposingtor.html.

Using modern web browsers in an anonymous manner is hard when someone is trying to penetrate that anonymity. All that scripting and dynamic content makes it even harder, as this example illustrates. And, given the vulnerabilities in web browsers that keep being discovered and actively exploited, the ability of an attacker to execute rogue code on an end-user’s machine simply by browsing a malicious web site seems like a given – in other words, no need for Java when you have document.getElementById().createTextRange() [e.g., 1, 2] (recently patched).

Also, it should be noted that this means of gathering an IP address is not an attack on TOR itself. The attack exploits tools being used outside of TOR, in particular a web browser with proxy support (somewhat) and enabled Java support – the end-user is not being protected by, or using, Tor and Privoxy, as their traffic is not being routed through these proxies on its way to the outside world. (Yeah right, crypto this?)

(I wrote this post a couple of months ago, which might be of interest.)

via a post to cypherpunks

-

There is a good discussion on DailyDave about vendors’ silently patching security issues and the impacts to companies’ patch management.

The following is a excerpt from this post in that discussion.

Corporation observes that Vulnerability A is difficult to exploit and
therefore lowers their internal risk rating and simply schedules the
patch for the next available change window. Signature based protections
are updated and false sense of security sets in… Beers are drank
everywhere.

Attacker (or anyone for that matter) reverse engineers the patch,
identifies Vulnerability B and realizes that it is much more reliable to
exploit than the publicly disclosed vulnerability.

Corporation gets owned. Hung over IT guy develops an ulcer if he didn’t
have one already.

What was it over at Apex Assurance? Oh yeah, “security is a business issue, not a technical issue.”

The thread can be found in the April 2006 DailyDave archives. This post started it off.

-

I found this (registration wall) to be interesting – pennies (US coin money) cost more than a penny (USD) to make.

This week the cost of the metals in a penny rose above 0.8 cents, more than twice the value of last fall. Because the government spends at least another six-tenths of a cent – above and beyond the cost of the metal – to make each penny, it will lose nearly half a cent on each new one it mints.

Soon the raw metal of the coin may be worth more than the face value of the coin as well – then it will be time to start melting those annoying critters down. :)

via a post to clips

-

Personal note,

Congratulations to AK2 and the newly born CK.

Auth, break, search

Wednesday, April 19th, 2006

So, I saw this headline.

Stupid People Alert: 81% Of UK Commuters Give Away Personal Information

Then, I read the referenced article.

Organisers of the annual information security event have been running a survey of this kind for a few years. Each time, the result is the same: whether the incentive is free theatre tickets or a free pen, people fall far too easily for these simple tricks of social engineering.

The type of information these people gathered is the same information we all give out all the time – it is not secret. Take someone like me – I can immediately think of two ways I commonly give out such personal information: when I order stuff online and when I meet new people that I want to keep in touch with. I am sure many others do the same, including the organizers of this event.

So, this article illustrates not that people are stupid, but that the information used to authenticate people is stupid. It shows that gathering the information necessary for identity theft is easy because the information considered to authenticate our identities is so public. What needs to change is the way we authenticate our identities, not people giving out public information publicly. And, there are many tools out there for doing just that, such as public key crypto, identity-based crypto, shared secrets, physical tokens/smartcards, biometrics, reputation, etc., but the incentive to change might not yet exist.

Unfortuately, until the day we authenticate our identities in a less stupid manner, I guess people still need to follow that old advice – keep the information that the credit card company and government asks you for when verifying your identity as much of a secret as you can (e.g., mother’s maiden name, birth date, social security number, etc.). Yes, it is silly and stupid, but maybe it buys you a slight speedbump of identity security.

A better article to read on that site is this one.

Workers were asked a series of questions which included, “What is your password?” – to which 37% immediately gave their password. If they initially refused, the researchers used social engineering tactics: “I bet it’s to do with your pet or child’s name” – at which a further 34% revealed their passwords.

One man said his office uses 10 different systems a day, so he and his colleagues share one password for each system so that they can remind each other if they forget.

Authentication information needs to hold the same importance to people as the keys to their homes or safety deposit boxes, and be just as easy to use – that can be hard to achieve. I posted on passwords a long while back.

Update: Catching up on my feeds, I see this post by Lindstrom. Essentially, he says keeping SSNs secret props up the authentication facade, so let’s just publish them all right now. That is one way to try and force a sensible change.

Oh, and I see this article, “The Laws of Identity”, via metafilter.

-

This reminds me of a comment I wrote a while back in response to this post.

How can one attempt to build things without first understanding how to break things? And, how can one fix something they do not know is broken in the first place?

[...]the crypto community is small, open, and homogeneous in a way that it generally uses cryptanalytic results to eliminate weaker crypto from the ballgame quite early on before its widespread adoption and use

[...]the publishing of security research leads to the ability to improve what is out there, whether by designing and building better primitives, protocols, and systems, or just fixing flaws in current deployments.

(One of the nice things about having a blog for a while is the ability to quote yourself rather than take the time to write new stuff.)

First you break em, then you build em. Whether boot camp, crypto, or security in general, that is the way of things.

(As for Flake, while I am not an academic, I do think people publish papers containing the partial results they have obtained thus far in a research effort. For example, a research project may take 10 years to complete, but each year a paper is published on the results obtained up to that point. I think you see this in the crypto community when the same people publish papers on a similar topics over and over, each paper advancing the results of the previous one. This can serve many purposes, such as letting people know what you are doing, pulling in outside opinions, sparking others to get involved, discovering other research that is relevant, learning new ways to apply the research, covering academic requirements, etc.)

-

I saw the following referer search terms in our logs,

=lounges+in+nyc+that+don%27t+id&

Sorry kids, none of those are listed here. Rififi, Lit, Fontanas, Happy Ending, Marquee, Heathers, Lotus Cafe, Annex, Beauty, Cielo, Fat Baby, Orchard, and all the other places I end up a bit less regularly all require ID until they get to know you. (I would know this because I still get ID’d – maybe that will finally change when I cross the 30 year old threshold.)

Then, I saw the following referer search terms in our logs,

=secured+hidden+ip+address+panty+sites&

So, it seems we turn up when people search for anonymous panties. Great. (That does remind me though, this Wednesday night is the next In The Flesh Reading Series at Happy Ending.)

And, by blogging these search terms, we will now get more hits for them – that is something to look forward to in future posts. ;)

List Update, Saltzar & Schroeder, Horde, and NMAP ASCII

Tuesday, April 18th, 2006

I made an update to the security blog list post that added a few more blogs. Of note, my favorite reads have not changed much over time.

-

I recently received an email pointing me to a copy of The Protection of Information in Computer Systems, and the tone of the email suggested surprise at the content of the paper given it was published back in 1974. This made me smile. (I like pointing people to Shannon’s work when applicable because of the date shock factor.)

Saltzar and Schroeder’s The Protection of Information in Computer Systems is a classic paper on information security. Virtually every information security person out there knows the oft cited eight principles described in section 1 of that paper, whether or not they know the paper itself. (For whatever reason, I always call this “the Saltzar paper,” even though it was co-authored.)

My favorite summary of the design principles discussed in that paper can be found here at the Matasano blog – that summary is extremely concise with real-world examples. A much larger write-up on the principles can be found at Emergent Chaos1,2,3,4,5,6,7,8 (if you like Star Wars, you will probably enjoy this one).

-

We had potential client work dealing with Horde, which made me take note of the recent Horde news and resulted in the following email.

Date: Tue, 04 Apr 2006 19:19:21 -0400
From: ad <xxxxxxxx @xxxxxxxxx.xxx>
[...]
Subject: Horde patch

I would have just glanced over this but for the fact we recently
discussed Horde.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1491

Like almost every other webapp, Horde has had its share of security
issues. This one is fixed by the latest patch.

http://lists.horde.org/archives/announce/2006/000271.html

[...]

Anyway, I just noticed this thread on the Incidents mailing list.

Date: Sun, 16 Apr 2006 12:04:04 +1200
From: “Jamie Riden” <xxxxxxxx@xxxxxxxxx.xxx>
To: incidents@securityfocus.xxx
Subject: Someone scanning for new PHP issues?

One of these might be the Horde exploit-
http://isc.sans.org/diary.php?storyid=1262 – any ideas on the other?
[...]

02:38:43.841958 IP compromised.com.1047 > www.example.com.www: P
1205950111:1205950537(426) ack 2648749032 win 65535
        0x0000:  4500 01d2 a2b9 4000 7206 4ef7 0ca2 a1a1  E.....@.r.N.....
        0x0010:  48e8 1e4a 0417 0050 47e1 569f 9de0 b3e8  H..J...PG.V.....
        0x0020:  5018 ffff 1fd8 0000 4745 5420 6874 7470  P.......GET.http
        0x0030:  3a2f 2fxx xx2e yyyy yy2e 3330 2e37 342f  ://xx.yyy.30.74/
        0x0040:  7765 626d 6169 6c2f 686f 7264 652f 7365  webmail/horde/se
        0x0050:  7276 6963 6573 2f68 656c 702f 3f73 686f  rvices/help/?sho
        0x0060:  773d 6162 6f75 7426 6d6f 6475 6c65 3d3b  w=about&module=;
        0x0070:  2532 322e 7061 7373 7468 7275 2825 3232  %22.passthru(%22
        0x0080:  6563 686f 2532 3049 524f 434b 5448 4557  echo%20IROCKTHEW
        0x0090:  4f52 4c44 2532 3229 3b27 2e20 4854 5450  ORLD%22);'..HTTP
        0x00a0:  2f31 2e30 0d0a 486f 7374 3a20 3732 2e32  /1.0..Host:.72.2
        0x00b0:  3332 2e33 302e 3734 0d0a 5265 6665 7265  32.30.74..

[...]

Fun stuff. milw0rm.com has exploits here and (for metasploit) here.

(What I remember most when I was first setting up Horde a few years ago was the advice I read on newgroups and/or mailing list archives as I trying to debug a few issues caused by file permissions – it was along the lines of “just make every file world rwx, it worked for me.”)

-

Finally, you hardcore ASCII artists might want to get in on this.

Date: Mon, 17 Apr 2006 16:22:37 -0700
From: Fyodor <xxxxxxxx@xxxxxxxx.xxx>
To: Goldstein101 <xxxxxxxx@xxxxxxxx.xxx>
Subject: Re: Nmap ASCII art?
[...]
Nice! The Dragon was just a starter, as I assumed someone with more
artistic and creative ability than me would come up with something
better. But these are the first new submissions I’ve seen. Does
anyone else here have other ideas? If so, please draw them up and
send to the list for comments. I plan to do a new Nmap release in the
next day or two.
[...]

|>00|>.

Date: Sat, 8 Apr 2006 16:38:06 +0200
From: Goldstein101 <xxxxxxxx@xxxxxxxx.xxx>
To: Fyodor <xxxxxxxx@xxxxxxxx.xxx>
Subject: Nmap ASCII art?
[...]

ooooo      ooo
`888b.     `8'
 8 `88b.    8  ooo. .oo.  .oo.    .oooo.   oo.ooooo.
 8   `88b.  8  `888P"Y88bP"Y88b  `P  )88b   888' `88b
 8     `88b.8   888   888   888   .oP"888   888   888
 8       `888   888   888   888  d8(  888   888   888
o8o        `8  o888o o888o o888o `Y888""8o  888bod8P'
                                            888
                                           o888o

[...]

5\^/33+.

(I just ate a “buttered popcorn” flavored jellybean – I plan on never doing so again.)

Glib?

Thursday, April 13th, 2006

I love the self-improvement suggestions in this post (e.g., practice, practice, pratice), as I do with virtually all of the Creating Passionate Users posts. I agree with the comments on glibness in general.

In way too many meetings, the fastest talkers win. And by “fastest talkers”, I mean those who are the first to articulate an idea, challenge, issue, whatever. Too many of us assume that if it sounds smart, it probably is, especially when we aren’t given the chance to think about it. The problem is, the guy with the “gut feeling”–the one who senses that something’s not right, but has no idea how to explain it, let alone articulate it on the spot–might be right. Too bad, though, because the glib usually rule.

My question – is glibness an issue in the technical arena (i.e., one techie communicating with other techies)?

My thought – no. Most techies are not glib – in fact, they probably look down on the glib. Bluntness seems to be much more standard, and this too can stifle dissent and just create a difficult discussion for those not used to it. Since I am naturally blunt, this does not bother me. For others, it can take some adjustment, but the important thing to keep in mind is, much like glibness, bluntness does not guarantee “bestness.”

Thinking back, I used to have to regularly walk into small rooms full of highly technical people that questioned why I was even there at first, and I had to prove myself to them everytime and build a working relationship. What worked best for me?

  1. Knowing what I was talking about, and learning (value: knowledge and/or expertise). That was why people were listening to me and looking for guidance about their particular needs in the first place. Being a curious geek helped here, especially with learning about customers’ systems and then analyzing them against requirements all on the fly.
  2. Being blunt, and having conviction (value: respect) – I needed to be able to hold my own and say what needed to be said, even if crudely. If I couldn’t, no matter what I knew, number 1 was not going to happen – respect must be earned. Keep in mind though, being blunt was not the same as being negative – I did not dismiss arguments, I recognized them – and I was generally positive.
  3. Telling relevant stories, and adding a touch of tech wit (value: rapport) – I needed to build relationships, which then made it easier to discuss hot topics and just generally be heard. This is a key to having a (amicable) discussion and being (favorably) remembered.

I think these work as well in technical presentations as they do in technical discussions, and they can get you heard rather than shot down by that person with the intelligence ego that everyone in the room fears.

Back to the broader arena, there is one example phrase in Sierra’s post that, while I took it as a paraphrase, I worry some might directly use it and I don’t think they should do so.

Memorize this: “I have some concerns, but I need a little time before I can really articulate them.”

That example statement has no passion, no force – it is just begging to be ignored, not respected. Back to the technical crowd for a second, if you are too “PC” in a technical crowd, you lose all credibility quite quickly, and, once that credibility is gone, good luck rebuilding it.

Here is what I tend to say,

    “Something about this idea just feels wrong, but I can’t say exactly what it is at the moment. <insert relevant fragments of evidence/discussion that are popping into your head, like you wrote some code that did this, you argued this before, you read something about this, etc. – who knows, those fragments might be enough to spark someone else with better insight and/or memory to speak up.>

    Let me poke around and get back to you by <firm date within reasonable timeframe, such as the end of the day or the next meeting/teleconference>.”

(Who here has not heard me say something along those lines at some point? It works.)

The most important thing is to speak up with conviction when you have genuine concerns. At a minimum, you have put your worries on the table.

NYC BUG Meeting April 2006, etc.

Monday, April 10th, 2006

I made it out to the NYCBUG meeting this month. The following is my raw notes from the meeting.

First off, I must say this meeting was full of optimism for the current boom in technology. And, BSD jobs seem to be quite common these days – OKCupid and Fotolog both announced the need for some strong BSD people during the meeting. (You might want to start shopping that resume.)

So, the point of this meeting and possible future meetings is to try to capture the dynamic of the NYCBUG talk mailing list in a face to face meeting. If you have not hit upon the NYCBUG talk mailing list before, it is basically a place where people can post questions, issues, and everything else BSD related and get informative and friendly feedback from others in the BSD community, including many well known names. (I note that “newbie” questions are not mocked on this list, which is quite rare in technical forums.)

Anyway, on to the content…

The meeting started out with a discussion from Bjorn about things he misses from FreeBSD when using GNU/Linux at work. These essentially boiled down to the ease of getting various statistics off the system.

For example,

  • “netstat -w 1″ versus “sar -n DEV” – no history

    (someone suggested trying “iptraf”)

  • “iostat 1″ versus the GNU/Linux version – no history
  • “vmstat” versus Linux version – less info
  • “ifconfig” versus Linux version – less info

    (someone suggested “mii-tool”)

Bjorn also discussed some configuration and logging features he misses. (These reminded me of when I first picked up FreeBSD again, which seemed much more GNU/Linux in configuration layout after I had been using OpenBSD for quite a while.)

-

(Interesting note, Theo apparently insulted the dmesgd feature of the NYCBUG web site because it was a webapp and he did not like webapps.)

-

Next up, Alfred Perlstein spoke about the infrastructure at OKCupid, which is a free online dating services. (I thought I had never heard of OKCupid, until he mentioned that they have all sorts of questionaires – then I remembered being sent a link to a political questionaire a while back that ended up telling me I was something along the lines of strongly libertarian. Sure enough, looking in my archives, it was OKCupid.)

Alfred started out by saying OKCupid is looking for some BSD people. If you are interested, send him your resume via email – being at the NYCBUG meeting earns extra credit.

OKCupid runs a 99% FreeBSD shop. They were running a flavor of 4 for a while, tried 5 and found it to be garbage (like every other FreeBSDer it seems – I never used FreeBSD 5 myself), and now are running 6 (6.1 currently).

OKCupid is built from mostly open source technology. Even their custom web server, OKWS created by Max Krohn, has been released to the public under GPL.

(Of note, Max Krohn is of fake CS paper fame.)

Apparently, there is some lore about just how much performance OKCupid squeezes out of their systems, so someone asked Alfred about it. Alfred said one of the keys here was a custom distributed memory cache, DSDc created by Krohn. He then went on to discuss their architecture at a very high, non-proprietary level, and it looked something like this.

OKC arch

(A fuller discussion of web service architectures built from OKWS can be found in papers [1, 2] by Krohn.)

The ability to build services for the OKWS framework is based upon SFS, which uses event-driven callbacks at its core and no threads. The tame framework is used to provide thread-like features such as blocking, but it should be noted that actual threads are not used in SFS.

Alfred also noted that they use “sup” to handle upgrades and installs for their systems.

OkCupid itself is free to use. It is ad and donation supported. (Give it a try – I may.)

-

After that, there was a question about active directory and samba integration. I did not actually catch the outcome of the discussion.

Audio of the meeting can be found here.

As for comments on the open format, I thought this meeting went well. Meetings need to have some structure, including an agenda and a leader. That happened. There should always be at least a couple of people that will be presentating some BSD topic of interest or concern to them, and these people should be prepared/able to speak on that topic – maybe not as formally as a normal meeting, but definitely showing they thought about what they is being presented or strong enough that they can wing it effectively. That happened. This could be followed by some general discussion that flows into after meeting bar talk. That also appeared to happen.

My main concern is that the open meetings could easily degenerate into an hour and a half of random questions better suited to the talk mailing list. The good thing about the talk list is that there is effective administration and most people formalize their questions/concerns a bit just to put them into a decent email message to the list – I think that type of effort needs to be translated into the open meeting as well.

Thanks to the NYCBUG team and all the speakers.

(Oh, and apologies to my “date” – I did not expect the meeting to last the full amount of time scheduled.)

——

In other (sorta BSD) news, this sounds like a DoS attack to me.

If I closed the GPS.dix.dk server right now, wrote off all the time I have spent myself, then my expenses would amount to between DKR 45.000,00 and DKR 99.000,00 (USD 7,300 to 16,000) and several hundered administrators throughout Denmark would have to spend time reconfiguring their servers.

If on the other hand we assume I leave the service running and that the unauthorized packets from D-Link products continue for the next five years, the total cost for me will be around DKR 115.000,00 + 54.000,00 per year (approx USD 18,500 + USD 8,800 per year) or DKR 385.000,00 over the next five years (USD 62,000).

Learn from your visitors, 10 second jobs

Saturday, April 8th, 2006

Although some people make fun of me, I find it to be a good thing that I have a tendency to subscribe to feeds and never unsubcribe/delete them – welcome to the age of cheap storage – as every once in a while you randomly stumble upon a gem of a post. One such gem is this post about the information a non-technical blogger is able to gather about their readers by using a free service to analyze the traffic to their blog.

1. Where you are in the world. There’s this handy report called “By Location” that allows me to quickly identify my readers’ location. For example, when a friend of mine is abroad in Saudi Arabia, my hits there go way up. I also tend to have long-distance paramours, so I always get a little thrill when their city shows up in the list.

2. Your IP address and, consequently, your place of business. I normally don’t pay attention to this. I don’t care where you work and I’m not going to do anything about it. But it helps me know when my family and friends have been on the site. [...]

3. How much time you spent here. Again, I don’t normally pay attention to this. But when I see people spending 30, 45, 75 minutes here… sometimes on separate occasions in the same day… several days in a row… I start wondering what’s up. Who are you, and why do you care so much about what I’m saying? Stalker red flag…

4. How you got here. This is one of my favorite reports – “By Referrals.” It’s how I can tell when new sites are linking to me, and go check them out. It’s how I find out DCist or Wonkette has picked up one of my posts. [...]

5. Pages you viewed. This is not very detailed. Mostly, when I see weird search strings like “visible panty lines,” I want to know what page you landed on. And I do.

(This is a baby version of what people like those at Google are doing.)

There is a perception that the virtual world is far more anonymous than the real world, but often the opposite is the case (just look at this in recent news). This easiest way to think of it in terms of web sites… that web site you are viewing needs to know how to reach you to send you its content – you send that site requests, and it sends back replies to those requests – so, the web server sending the web site’s content knows your (external IP) address and most likely logs every request it receives from that address, including those anonymous blog comment posts. Throw in referers, cookies, session identifiers, embedded links/javascript, link wrappers, and all sorts of other tracking mechanisms, and the window into your world grows quite large. Even those of us that take measures to be a bit more hidden leave traffic analysis and human fingerprints behind, like writing styles, browsing patterns, etc., which often leads to (unintended) pseudonymity or sometimes even true names.

Anyway, this type of data is quite useful feedback to a business’ online presence. It can tell you how people are finding your business online, what content they find interesting, and just generally what works and what doesn’t. If you are not putting this data to use for you, now is the time to start. From awstats to google analytics, start learning about who cares enough to pay you a visit. (I can’t tell you how often I talk with a small business with a web site and they don’t even know this information exists let alone how to harvest it.)

-

Unrelated, we perform the IT equivalent of these 10 second jobs quite a bit, especially for home users.

So, we called a Garage Master to come over. He spent about, oh, 10 seconds, analyzing the problem and then did two things that any homeowner with a brain would do:

1) He oiled the track. WD-40 all over that bastard

2) He turned a knob on the garage door opener

The difference, we normally don’t charge (with the exception of maybe travel costs if we had to go onsite to some out of the way location), we don’t cross sell, and we try to teach some basic debugging skills without making people think they lack brains.

(Not charging for these typical jobs is probably why I appreciate the “PK242″ so much when running around the city doing them. That is Papaya King’s two hotdogs for two dollars – please stop singing HeadHunter. ;) )

Outtage

Thursday, April 6th, 2006

This site experienced some downtime due to server hardware issues at our hosting provider.

April 6, 11:14 AM – Server work continues
[...]
We are working on replacing the disks that developed problems last night, and upgrading the servers.

Things appear to be back to normal at this point, well, maybe better than normal.

April 6, 2:25 PM – Almost done!
[...]
I just got a phone call from Tony, and he is nearing completion. It is all going very well; Tony is extremely pleased, and you should also notice an increase in speed once service is restored.

Swiped ID

Wednesday, April 5th, 2006

I entered a bar on Delancey in the Lower East Side a few nights back. When presenting my ID for verification of age, the bouncer quickly scanned the barcode of my license on a small device and verified my age on the screen of the device. This was without my consent and completely unexpected, as I had been there before and not encountered this behavior. So, I asked the bouncer what was going on, and he told me this was to help prevent fake IDs. I may just be paranoid, but I will not be going back to that establishment – unfortunately, it may be too late.

This site discusses the swiping of ID.

Businesses are also using driver’s license scanning equipment. The first businesses to start swiping were bars and convenience stores. They are doing this in the name of age verification and fraud detection. Businesses many times do not ask for consent from their customers-or even bother to notify them-before swiping a card. In most states it is legal to scan licenses and upload the data to a customer database for future analysis and use.

Reading along on that site,

Cigarette companies are also using driver’s license scanners for commercial benefit as part of promotional campaigns. Companies like R J Reynolds will send a young person equipped with a license scanner and free cigarettes into a popular bar on a weekend night. The company gives 1-2 packages of cigarettes to bar goers in exchange for a swipe of their driver’s license.

I encountered this one night, as discussed here. The funny thing, this event actually took place at this same bar.

The scanning of IDs is a hard practice to find even with the tons of bars/lounges in NYC. Most venues here respect the privacy of their patrons, which makes it easy to avoid the ones that don’t.

(My favorite bar is still Rififi.)

-

Side note, this is the best play on words I have seen in a long time.

There is a God: Alcohol cloud spotted in Deep Space

As the article says,

The vast bridge-shaped cloud of methyl alcohol has been spotted in a region of our galaxy, the Milky Way, that is called W3(OH), where stars are being formed by the gravitational collapse of concentrations of gas and dust, the discoverers said in a press release.

Around 130 organic molecules have also been identified so far in outer space, fuelling speculation that these complex molecules may have helped to sow the seeds for life on the fledgling Earth.